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

[Hans-Christoph Steiner]

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

.hc

Neil Williams:
> On Sun, 27 Mar 2016 00:36:37 +0800
> 殷啟聰 <seamlikok at gmail.com> wrote:
> 
>> So, looks like the LAVA team does need adb & fastboot on all ARM
>> platforms, right? :)
> 
> It would be useful and IMHO that is sufficient reason to keep arm64 and
> probably armhf in the architecture list of the source package. The need
> isn't immediate but as the architecture was previously supported and
> the new upstream could soon be supported on arm64, it makes sense to
> address this now instead of needing to add it back later.
> 
> The LAVA team would be a user of adb and could assist in validation
> that it works (hardware for that is coming soon) but problems with
> architecture-specific FTBFS would be investigated with the debian-arm
> porters as normal.
> 
>> I was wrong about android-libunwind. Actually I remember it was
>> android-libbacktrace, which is needed by adb, who FTBFS in the other
>> platforms. What if android-libbacktrace still FTBFS on ARM? 
> 
> Has it been tried with the new upstream version? By dropping the
> architecture from the list with the first upload, it didn't get tried.
> 
>> In that
>> case, adb won't be built either, and I fear this will even further
>> prevent our packages from migrating to testing. Actually, this bug
>> #817823 is already pulling it from migrating.
> 
> 817823 can be retitled to not affect selected architectures, those
> binaries would then be replaced with the migration as normal, once the
> other architecture binaries are removed. ftp.debian.org bugs like this
> only occur when architectures previously supported get dropped by a
> package, leaving cruft behind. Mark those architectures as supported
> and the binaries are no longer cruft. What's blocking the migration is
> the change in the list of architectures supported.
> 
>> _hc, did you remember libbacktrace FTBFS on ARM or MIPS? Do you think
>> it's OK to build adb/fastboot and their dependencies on ARM and/or
>> MIPS?
> 
> I can't see a bug report for an ARM-specific FTBFS:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=1;src=android-platform-system-core
> or
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;repeatmerged=on;src=android-tools
> 
> 
> 
> 
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
> 

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