[03:32] <tdaitx> doko: took me a while to get my qemu updated, test the whole stuff, retest with patches applied, various LaF/swing/gtk settings, screenshots, and bug reports, but I believe that while upstream has fixed some issues (upcoming openjdk 11.0.4) the GTK2 experience is way better and seems to be working fine on bionic
[03:32] <tdaitx> should we maybe revert openjdk-11 in bionic to rely on gtk2 by default? gtk+2.0 has about 38 reverse (b)deps in Bionic (and 37 in Disco)
[06:57] <doko> tdaitx: sure, we can. not sure about disco yet, because we will get these updates for disco. should be optional
[16:02] <doko> tdaitx: what exactly is this android build tools problem in disco?
[16:09] <tdaitx> doko: jh_build is no longer respecting the --release flag for some reason, I believe it is related to the changes in javatools 0.72.3
[16:09] <doko> ahh, the perl conversion
[16:10] <tdaitx> yeah, when they moved from bash to perl
[16:10] <tdaitx> it is setting -source 7 since then
[16:11] <tdaitx> on bionic:
[16:11] <tdaitx> jh_build --javacopts="--release 8 -sourcepath src/main/java" --no-javadoc \
[16:11] <tdaitx> 	--main=com.android.apksigner.ApkSignerTool \
[16:11] <tdaitx> 	apksigner.jar src/apksigner/java
[16:11] <tdaitx> find src/apksigner/java -name *.java -and -type f -print0 | xargs -s 512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp /usr/share/java/apksig.jar:debian/_jh_build.apksigner -d debian/_jh_build.apksigner -encoding ISO8859-1 --release 8 -sourcepath src/main/java
[16:11] <tdaitx> on disco:
[16:11] <tdaitx> jh_build --javacopts="--release 8 -sourcepath src/main/java" --no-javadoc \
[16:11] <tdaitx> 	--main=com.android.apksigner.ApkSignerTool \
[16:11] <tdaitx> 	apksigner.jar src/apksigner/java
[16:11] <tdaitx> jh_build: find src/apksigner/java -name '*.java' -and -type f -print0 | xargs -s 512000 -0 /usr/lib/jvm/default-java/bin/javac -g -cp /usr/share/java/apksig.jar:debian/_jh_build.apksigner -d debian/_jh_build.apksigner -encoding ISO8859-1 -source 1.7 -target 1.7
[16:13] <doko> tdaitx: but it works in unstable
[16:14] <tdaitx> I got an email from Bart Martens that my proposed update in debian failed to build
[16:14] <tdaitx> with basically the same error as disco
[16:15] <doko> and setting source and target instead of release?
[16:16] <tdaitx> back then I only build it locally on bionic, it worked so I uploaded to bionic, cosmic, disco, and debian (mentors)... I was not expecting the problem in disco
[16:16] <tdaitx> we shouldn't really be using -source -target with openjdk-11
[16:16] <tdaitx> if any package fails to build with that, it is because it is probably a package that is made to work with (at most) openjdk-8
[16:17] <tdaitx> if any package fails to build with --release 8, it is because it is probably a package that is made to work with (at most) openjdk-8
[16:19] <doko> the logic is wrong
[16:19] <doko> if (not _has_java_option(\@javac_opts, '--release') and not _has_java_option(\@javac_opts, '-source')) {
[16:19] <doko>         # If neither --release nor -source is set, then set -source (and -target if also absent)
[16:19] <doko>         if (not _has_java_option(\@javac_opts, '-target')) {
[16:19] <doko>                 push(@javac_opts, '-source', DEFAULT_JAVA_RELEASE, '-target', DEFAULT_JAVA_RELEASE);
[16:19] <doko> it defaults to DEFAULT_JAVA_RELEASE, not the --release value
[16:21] <tdaitx> yeah, but I did set the --release, it should not be using -source -target there
[16:22] <tdaitx> I didn't look into that, just saw that this javatools change is what probably broke the build with --release
[16:24] <doko> tdaitx: what should it do? just pass --release 8, and not adding -source 1.7 -target 1.7?
[16:24] <tdaitx> yeah
[16:26] <tdaitx> from a quick look over that patch I have to say that I don't understand why it is even going into the if clause to set default
[16:26] <tdaitx> it should only go into that if neither --release and -source are set, but in the FTBFS --release is actually set
[16:27] <tdaitx> s/and/nor/
[16:29] <tdaitx> doko: look at this:
[16:29] <tdaitx> +	# Space-separated list of options
[16:29] <tdaitx> +	'javacopts|o=s' => sub { @javadoc_opts = split(' ', $_[1])},
[16:29] <tdaitx> +	'javadoc-opts=s' => sub { @javadoc_opts = split(' ', $_[1])},
[16:29] <tdaitx> it is not parsing the options correctly, there is a typo there
[16:31] <tdaitx> the sub call should be setting the javac_opts array:
[16:31] <tdaitx> -        'javacopts|o=s' => sub { @javadoc_opts = split(' ', $_[1])},
[16:31] <tdaitx> +        'javacopts|o=s' => sub { @javac_opts = split(' ', $_[1])},
[16:33] <doko> found it
[16:33] <doko> yep
[17:22] <doko> tdaitx: gtk2 for disco seems to be fine as well, no plan yet for demotion
[17:24] <tdaitx> doko: ok, I was going to test a build that depended on gtk2 for bionic and gtk3 for disco+ (similar to openjdk-8 xenial/bionic), should I default to gtk2 as a dependency then? do we want to have it as an alternate dependency default to gtk2?
[17:26] <doko> yes, the latter please
[17:27] <doko> I just confirmed that gtk3 support will still take some time
[17:28] <tdaitx> doko: ok, so depends "libgtk2.0-0 | libgtk-3-0", but what about b-dep?
[17:29] <doko> tdaitx: what did you remove? ;p
[17:29] <tdaitx> well building with libgtk-3-dev allows us to run with gtk2 (since it dinamically loaded)
[17:29] <doko> b-d should be the default as well
[17:30] <doko> I didn't look at the build system. if it has consequences
[17:30] <tdaitx> I never tested if b-deps on libgtk2.0-dev works the same way (it should, but)
[17:31] <tdaitx> ok, I had some hope you had looked at this back on the openjdk-8 change =)
[17:31] <tdaitx> in that case I will check how they use the headers
[17:34] <tdaitx> doko: I copied android-platform-tools-apksig from our ppa (bionic) into cosmic-proposed, it needs approval... it got rejected earlier this week, I assume because disco failed(?) but the bionic copy was approved later o_O
[17:35] <doko> tdaitx: accepted
[17:36] <tdaitx> btw,  android-platform-tools-apksig rebuild ok on disco after the javatools fix, tks doko!
[17:48] <tdaitx> doko: the upstream bug report for "defaulting to GTK3 instead of GTK2" mentions that the change should be coordinated with javafx
[17:49] <tdaitx> https://bugs.openjdk.java.net/browse/JDK-8198649
[17:50] <tdaitx> javafx was tracked in https://bugs.openjdk.java.net/browse/JDK-8198654 and commited to http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3e6c9b6db694
[17:50] <tdaitx> so we might want to update javafx as well and revert/update this: http://hg.openjdk.java.net/openjfx/jfx-dev/rt/rev/3e6c9b6db694
[19:26] <tdaitx> interesting, gtk dev packages are not actually required for building openjdk-11, I removed that build dependency and set the runtime alternatives for jre... uploading for a test build in a ppa now