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

[Hans-Christoph Steiner]

We are only talking about official packages. I think some of the
confusion stems from there being an "android-tools" team which manages
many packages and an "android-tools" source package, which is the old
deprecated approach for building adb, fastboot, and fsutils.

I didn't realize that the android-tools source package was ported to all
the other arches. We haven't updated the android-tools source package,
we have created a whole new set of source packages that are much closer
to upstream than the android-tools package. Those new source packages
are what would have to be ported.

On amd64 and i386, the new team source packages have completely replaced
the original android-tools source package. What we can do for the other
arches is just keep the android-tools source package as it is. We have
no plans to update or maintain it though, so it would be orphaned.

here are all the team packages:
https://qa.debian.org/developer.php?email=android-tools-devel%40lists.alioth.debian.org

.hc

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.
>