On Mon, 28 Mar 2016 10:19:45 +0200 Hans-Christoph Steiner <[email protected]> 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/
pgpNtvwwtOfV0.pgp
Description: OpenPGP digital signature
