[Android-tools-devel] fdroidserver on plain debian report
Hans-Christoph Steiner
hans at at.or.at
Wed Feb 1 15:53:10 UTC 2017
If these packages can't build an app, then that counts as an RC bug,
which we can fix in stretch. So I think we just need to figure out what
needs doing with the "You have not accepted the license" code. I'm
thinking we should just disable it in a patch, its for proprietary
licenses which I'm not so keen on supporting.
About the `android` command, I think we should ultimately package it as
a standalone package, if that's not too much work. There are lots of
old but useful apps that are still built using the old ant style that
requires that command.
.hc
殷啟聰:
> Hi Chrysn,
>
> Thank you for sharing with us the experience of building Android apps
> with Debian packages! Let me reply to some of the problem you (and I)
> have hit:
>
> "Could not find `android` on your system.":
>
> Not only Ant build system relies on the presence of this command line
> program but also Apache Cordova (and probably PhonGap?). The problem
> is that the `android` program has been abandoned by upstream and AOSP
> is replacing it with a `sdkmanager` [1]. Bad news is that the source
> of neither of this 2 program is available to us. I don't know why they
> keep such secret to us, but if it becomes necessary, we will have to
> place an empty script serving as a decoy of the `android` program.
> Once the source of `sdkmanager` is out, is shoud be easy to rewire
> `android` commands to `sdkmanager`.
>
> "Gradle version incorrect.":
>
> Gradle is 3.2.1 in Stretch and the Gradle plugin is 2.2.2 in Sid (will
> hopefully be in Stretch before Full Freeze), so if Debian's Gradle
> plugin is used in F-Droid's building process the version problem is
> gone. However, in this version of the Gradle plugin, Lint always fails
> [2].
>
> "You have not accepted the license."
>
> After you accept the SDK's license when you are downloading the SDK
> components using the upstream SDK manager, the SDK manager stores the
> hash of the licese text in ${ANDROID_HOME}/licenses. In the next
> release of android-sdk-meta, the "licenses" directory will be included
> [3]. Looks like there's already no time for it to enter Stretch...
>
> Cheers,
> Kai-Chung Yan
>
> [1]: https://developer.android.com/studio/command-line/sdkmanager.html
> [2]: https://anonscm.debian.org/cgit/android-tools/android-platform-tools-base.git/tree/debian/patches/disable_lint-cli_psi.patch?h=debian/2.2.2-1
> [3]: https://anonscm.debian.org/cgit/android-tools/android-sdk-meta.git/commit/?id=f127dc01c0857bad69c91a75e3e0e9f57e94adf5
>
> 2016-11-21 21:03 GMT+08:00 Hans-Christoph Steiner <hans at at.or.at>:
>>
>> Hey chrysn,
>>
>> This is great, thanks for this! Hello list, chrysn tried to build all
>> of the apps in F-Droid using only the Debian packages.
>>
>> chrysn:
>>> hi,
>>>
>>> some assorted observations from getting things on:
>>>
>>> * fdroidserver should probably recommend android-sdk now that it exists;
>>> git-svn should be added too. python-gpg (or python3-gpg?) is also a
>>> build dependency of some (projectmaxs) packages. is svn actually still
>>> needed? (it seems that git-svn is used instead)
>>
>> Makes sense for fdroidserver to suggest or recommend android-sdk. I
>> don't think fdroidserver should deal with specific app dependencies
>> (e.g. projectmaxs), only the common basics.
>>
>>> * com.afollestad.cabinet, com.as.anagramsolver and others want user
>>> input for `git clone`. setting GIT_ASKPASS=true made them at least
>>> fail instead of hanging indefinitely.
>>
>> GIT_ASKPASS=true is a great tip for adding to the fdroid build tools
>> somehow.
>> https://gitlab.com/fdroid/fdroidserver/issues/240
>>
>>
>>> dereferencing their github urls showed that these projects have gone
>>> 404 in the meantime.
>>>
>>> were upstream repositories clean (ha! distributions would be so much
>>> easier), fdroid could mirror upstream repos as debian does with
>>> .orig.tar.gz, but due to checked-in whatevers, du -sch `**/.git`
>>> amounts to 34gb, with no single big offenders.
>>
>> Every app built by f-droid.org also then includes a source tarball, so
>> those are available. At this point, I'm not too worried about building
>> apps with missing source, since there are much bigger fish to try.
>>
>>
>>> * at least for me in the situation of not yet having seen ano obviously
>>> functional build, it's hard to tell which packages worked (or whether
>>> any worked at all), because lots of .apk are around in build/ (eg
>>> ./build/de.dotwee.micropinner/archive/release_v1.1.apk) which are just
>>> checked-in upstream builds (philistines!), and because many (1463 of
>>> 1776) build scripts returned successfully even though they gave "BUILD
>>> FAILED" or similar responses. (not sure how much fdroid can do about
>>> that; possibly it's upstream scripts misbehaving).
>>
>> Yeah, we need to improve the CLI error reporting. The full fdroid build
>> process has mostly just been used for f-droid, where the error logs are
>> posted on the wiki there.
>>
>>
>>> * typical build problems were: "Could not find 'android' on your system"
>>> (610), The Gradle Version Thing (740), "You have not accepted the
>>> license agreements of the following SDK components" (174; i thought i
>>> could fix it but all details to it assume the presence of an `android`
>>> executable), ndk missing (101); easily fixable for me are missing
>>> python-gpg (22), bzr (17).
>>
>> * we still need to package the `android` tool, which is required for the
>> old ant build system.
>>
>> * there are a couple of workarounds for the gradle version bug, it seems
>> like the fdroid tools should handle this, the workarounds are described
>> here:
>> https://gitlab.com/fdroid/fdroidserver/issues/184
>>
>> * packaging the NDK looks like a large project which we have not started
>> yet, unfortunately
>>
>>
>>> the counts may be off by a factor of 2 some times because i only
>>> counted occurrences in the typescript, but give an idea.
>>>
>>> * curious findings: org.poirsouille.tinc_gui seems to try to write to
>>> SDK: "Exception while marshalling
>>> /usr/lib/android-sdk/build-tools/23.0.2/package.xml. Probably the SDK
>>> is read-only". won't bug you in production, but might be worth a
>>> warning when a setup is not fully virtualized.
>>
>> As you know from Debian, we see all sorts of "tricks" in apps that are
>> included in F-Droid. That looks like one we should not support.
>>
>> .hc
>>
>>> does any of the build problems ring a bell with you that sound like
>>> low-hanging-fruit you could give me a pointer to? is there anyone else
>>> or a list i should cc on this (maybe with the context they're missing
>>> from debienna) working on fdroid in debian?
>>>
>>> liebe gruesze
>>> christian
>>>
>>>
>>> Versions of packages fdroidserver depends on:
>>> ii default-jdk 2:1.8-57
>>> ii python3-clint 0.5.1-1
>>> ii python3-git 2.1.0-1
>>> ii python3-libcloud 1.3.0-1
>>> ii python3-paramiko 2.0.0-1
>>> ii python3-pil 3.4.2-1
>>> ii python3-pyasn1 0.1.9-2
>>> ii python3-pyasn1-modules 0.0.7-0.1
>>> ii python3-requests 2.11.1-1
>>> ii python3-yaml 3.12-1
>>> pn python3:any <none>
>>> ii rsync 3.1.2-1
>>>
>>> Versions of packages fdroidserver recommends:
>>> ii aapt 1:6.0.1+r55-1
>>> ii adb 1:6.0.1+r55-1
>>> ii git 1:2.10.2-2
>>> ii opensc 0.16.0-1+b1
>>> ii zipalign 1:6.0.1+r55-3
>>>
>>> Versions of packages fdroidserver suggests:
>>> pn bzr <none>
>>> ii gradle 3.1-2
>>> pn maven <none>
>>> pn mercurial <none>
>>> pn php5 <none>
>>> ii ruby 1:2.3.0+4
>>> pn subversion <none>
>>> pn vagrant <none>
>>> pn vagrant-cachier <none>
>>> pn vagrant-libvirt <none>
>>> pn virtualbox <none>
>>>
>>
>> _______________________________________________
>> 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
>
> _______________________________________________
> 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
>
More information about the Android-tools-devel
mailing list