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