[Android-tools-devel] Building Jack/Jill and other Android build tools from source

Thu Dec 29 12:32:28 UTC 2016

Wolfgang Wiedmeyer:
> Hi 殷啟聰,
> 
> 殷啟聰 writes:
> 
>> Hi Wolfgang,
>>
>> Sorry for my very late reply!
>>
>> I haven't started the packaging of Jack until recently. The packaging
>> is still not finished and the code can be found at [1], in case you
>> are interested. My package is based on ub-jack-douarn-b8, and AOSP
>> 7.0.0 has been using ub-jack-douarn-a8, so I think it is stable
>> enough, though I haven't tested it.
> 
> Thanks for working on this! Have you verified that the jar file in AOSP
> 7.0.0 was build using ub-jack-douarn-a8? As I already wrote in my first
> mail, I found the sha hash of the commit in the version.properties file
> in the jar. The commit was not tagged and there was otherwise no hint
> that this commit would be used for the binary. This was on the
> ub-jack-brest branch and the commit was a few commits after the commit
> that did the version bump to 1.1-mr2. If I had not found the hash, I
> probably would have given up, because other versions were too unstable
> to build Replicant.
> 
> I noticed that code that put the hash there is gone for ub-jack-douarn:
> https://android.googlesource.com/toolchain/jack/+/44df9f39a03d5045c5ee2da40ff876337ecb818c%5E!/#F0
> I don't know if there's a different way to be sure that the binary is
> coming from a certain commit/tag.
> 
>> About the backports, I myself won't have time for it because we have
>> been working on updating the packages to Nougat, but unfortunately it
>> is still stuck because one of the key packages
>> android-platform-libcore are still waiting in Debian's NEW package
>> queue. I'm afraid Nougat (and Jack) won't be available in Stretch.
>> Besides, Stretch is coming soon, there's not much time for backporting
>> to Jessie, I think.
> 
> As I managed to get the build working on Stretch, I don't need the
> Jessie backports anymore. But it would obviously be awesome if Jack would
> be available in Stretch backports then.

This is all great news!  We can of course get jack into
stretch/backports.  Do you need Nougat in Stretch in the near future?
That'd be a lot more work.

.hc

> Best regards,
> Wolfgang
> 
>> For now NDK is too big for us, your work on building NDK from source
>> will definitely us!
>>
>> [1]: https://gitlab.com/seamlik/debianpkg_android-toolchain-jack
>>
>> 2016-09-05 20:35 GMT+08:00 Hans-Christoph Steiner <hans at at.or.at>:
>>>
>>>
>>> Wolfgang Wiedmeyer:
>>>>
>>>> Hans-Christoph Steiner writes:
>>>>
>>>>> Wolfgang Wiedmeyer:
>>>>>> Sorry for my late reply!
>>>>>>
>>>>>> Hans-Christoph Steiner writes:
>>>>>>
>>>>>>> We're interested in packaging as much of the Android tools as possible,
>>>>>>> we'd also be interested in the manifest-merger.  We have manifest-merger
>>>>>>> built as a JAR in the android-platform-tools-base package, but we
>>>>>>> haven't really exposed it.  You can see it listed here:
>>>>>>>
>>>>>>> https://packages.debian.org/stretch/all/android-platform-tools-base/filelist
>>>>>>
>>>>>> Awesome! Are there any plans to do a backport to Jessie?
>>>>>>
>>>>>>> If you are interested in basing your ROM builds on Debian, then we can
>>>>>>> shift priorities some to work on fixing issues related to ROM builds.
>>>>>>> We're currently focused on getting app building working with the Debian
>>>>>>> packages.
>>>>>>
>>>>>> I'm very interested in that and I already try to use everything that is
>>>>>> available in Jessie. It would be great to have all host tools either
>>>>>> build from source as part of Replicant or getting them from Jessie. I'm
>>>>>> already pretty close to that. In fact, I'm only aware of the
>>>>>> manifest-merger and some binaries from the NDK repo that run on the
>>>>>> build host and are not yet from Jessie or build from source. This is for
>>>>>> building a ROM image, to build the SDK a lot more is needed. I'm
>>>>>> focusing on the host tools for now to make the build itself more
>>>>>> trustworthy, but the goal is to get rid of all the prebuilts.
>>>>>>
>>>>>> Replicant needs to be buildable on a GNU FSDG-compliant
>>>>>> distribution. While I think it's fine that my focus is currently on
>>>>>> Debian, it should be possible to build it on a FSDG-compliant distro
>>>>>> like Trisquel in the future. A dependence on the backports repo could
>>>>>> make this more difficult, but I don't see an other option at the moment.
>>>>>>
>>>>>> Thanks,
>>>>>> Wolfgang
>>>>>
>>>>> We're still focused on getting everything working in testing.  Backport
>>>>> to jessie is feasible, but its a chunk of work.  How essential is it for
>>>>> you?  It would make the workflow a lot easier if you work on stretch,
>>>>> since we can then make updates and fixes in one place.
>>>>
>>>> Stretch is not really an option right now. I'm already mirroring all the
>>>> repos from CyanogenMod to have everything in a "freezed" state. A
>>>> running target like Stretch would result in a lot of additional work to
>>>> keep up with the changes. Google seems to target an older Ubuntu LTS
>>>> release for building their native toolchain (compilers etc.). Debian
>>>> Stable is a much better fit for that. I already tried to help someone to
>>>> get everything build on Stretch until this person gave up. There were
>>>> quite some new build errors.
>>>>
>>>> Maybe this is something where I could get involved? I backport a few
>>>> things for personal use: https://packages.fossencdi.org/
>>>> I could do some quick and dirty backports of needed packages and see how it works
>>>> out. Then, with your help and Debian Mentors, I could try to get them in
>>>> the official backports repos.
>>>
>>> Yeah, that would certainly help.  The painful part is the staged
>>> uploads, meaning that you first have to upload a partial version of
>>> android-platform-build and android-platform-system-core, then upload
>>> other things that depend on those, then upload the full versions.
>>> That's because of circular dependencies between the git repos/source
>>> packages.
>>>
>>> https://wiki.debian.org/AndroidTools#Updating_the_source_packages
>>>
>>> I propose a much easier way to use the android-tools packages from
>>> stretch: add testing as a package source, but pin it at very low
>>> priority so you have to manually install packages from that repo.   This
>>> is the same setup as jessie-backports.  Then you can start working with
>>> the stretch versions of the packages while on jessie.  I think the 7.0
>>> SDK packages will be easier to backport since there is only one circular
>>> dep: android-platform-system-core.  We're aiming to have those included
>>> in stretch's final release.
>>>
>>> Also, FYI, stretch will freeze in November, so it will be soon not
>>> changing very much.
>>>
>>>
>>>>> We already have the bulk of the SDK tools packaged.  Its really just the
>>>>> odd things like renderscript that are not.  As for building the NDK from
>>>>> source, that's a whole other question.  It would probably be pretty easy
>>>>> to package ndk-build since its just a collection of Make scripts.  But
>>>>> actually building the compilers would be a large project.
>>>>
>>>> Building the compilers works fine, but some binaries like a minimal
>>>> Android libc is needed. I also have to check what else is needed for
>>>> building a ROM, but it doesn't seem to be much.
>>>>
>>>> Wolfgang
>>>
>>> Ok, at least its easy to build.  There are still a lot of issues related
>>> to the packaging and integrating with the compilers already in Debian.
>>>
>>> .hc
>>>
> 
> 