[Android-tools-devel] arm64 & armhf builds?

[Neil Williams]

On Mon, 28 Mar 2016 10:19:45 +0200
Hans-Christoph Steiner <hans at at.or.at> wrote:

> Hey Neil,
> 
> Sounds like you are in the perfect position to do this porting and
> maintenance since you are working with lots of ARM hardware, and want
> to use the Android SDK on ARM as part of your regular work.

No, not the porting and I am not able to be a maintainer of any
android packages - I have quite enough Debian work to do already. I'm
offering the validation, at no point did I offer to do the porting.
That would be with the help of the ARM porters, as usual for packages
using official Debian architectures.

This isn't about adding an unofficial port. This is about *restoring*
previously *supported* architectures to the relevant packages. There's
no evidence of a FTBFS bug affecting previous versions of these
packages - it makes no sense to treat official Debian architectures in
this way. Why do you think that architecture-specific patches are going
to be necessary?

The new version of the package introduces a regression - this bug would
not be necessary otherwise. I am providing a use case for the
*existing* maintainers to limit the impact of that regression and
provide *some* of the support available with previous versions of the
same packages.

By all means, if there are concerns about running the entire SDK then
the SDK support can be i386 only (as upstream don't support amd64 for
the SDK either) - but the arm64 and armhf packages providing adb and
fastboot should not be dropped as there is a clear use case for these
to exist in Debian provided that these packages are built using the
standard buildd framework and on the official mirrors.

> So I
> think the best workflow here is if you start building the
> android-tools packages on ARM, and submitting fixes/patches as you
> go. 

Why should it require me to build unofficial packages? We have the
buildd framework for that. This is about validation of packages in
Debian, not random manual builds on hardware outside the control of DSA.

> If you are committed to doing this work, then I think it makes
> the most sense for you to join the android-tools team, then directly
> commit to the git repos. Otherwise, if you have just bits of time
> here and there, then submitting patches in bug reports is probably
> the best way.

Sorry, that's impossible. I have time to work with using adb and
fastboot on arm64 hardware in LAVA when that hardware becomes available
and provide data to the android maintainers on the performance of the
supported arm64 (and possibly armhf) packages.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20160328/0d034a39/attachment.sig>