[01:32] <tdaitx> doko: sbeattie: regarding the bug report LP: #1797761, do you see any problem on having gradle binaries depending on an earlier java version?
[01:32] <tdaitx> for example groovy has: default-jre-headless (>= 2:1.7) | java7-runtime-headless
[01:32] <tdaitx> while gradle is using: default-jre-headless (>= 2:1.9) | java9-runtime-headless
[01:32] <tdaitx> looking upstream our gradle is in fact compatible with openjdk-8, not openjdk-11 - we had to actually backport patches to have it working with 11
[01:32] <tdaitx> so I believe we could easily have it depend on the 8-ish versions: default-jre-headless (>= 2:1.8) | java8-runtime-headless
[01:33] <tdaitx> https://launchpad.net/bugs/1797761
[01:36] <tdaitx> yeah, I know, everything has been build with 11 which means we didn't get our java toolchain actually tested with 8, thus we could introduce some problems by allowing users to run it with 8 but overall I think it should be ok
[01:37] <tdaitx> another tool is ant, it also depends on java 8+
[01:37] <tdaitx> maven is still on 7
[01:44] <tdaitx> I believe gradle was set to depend on java 9 (changelog for version 4.4.1-1) because that was when debian introduced the patch to fix the classloader issue on 11, but instead of using the upstream commit that maintened compatibility with 8 they decided to go with a smaller change that would only work with 9+
[01:44] <tdaitx> this is the patch that I fixed for LP: #1820389, thus I could also have reverted the dependency back to java 8
[09:33] <huehner> tdaitx: ant 1.10.x requirs java8 as per upstream
[09:34] <huehner> tdaitx: with that patch we added a few days ago we tested both 11 and also 8
[09:54] <doko> tdaitx: java7-runtime-headless is provided by every openjdk package. probably gradle should be relaxed to that or have java8-runtime-headless as an alternative
[11:34] <huehner> doko: the timing you had in mind from the u-d-a mail still stands (around Last week or March)?
[11:41] <doko> huehner: yes, we will re-evaluate on Monday
[12:06] <huehner> doko: thanks, if it changes would be great if you could let me know here
[12:44] <tdaitx> huehner: yeah, I was just mentioning that other java tools had their runtime dependency set according to upstream requirements, and so should gradle =)
[12:44] <tdaitx> we will let you know if the date changes
[13:02] <tdaitx> doko: sbeattie: uploaded new gradle into stage5 for bionic and cosmic, it just has the new Depends on java 8 (instead of java 9), needs review or is ok to copy?
[13:11] <doko> I would say it's ok
[13:13] <tdaitx> doko: I also believe so... well, we can revert to the old version if this reach proposed, right?
[13:42] <tdaitx> sil2100: I copied gradle source+binaries to bionic and cosmic
[13:43] <doko> tdaitx: why is debian/tests messing around with JT_JAVA?  I removed that in 11, 12 and 13. Left it in 8 for now
[13:43] <doko> and why stamps/prune-build-dir ? is it necessary to remove that?
[13:45] <tdaitx> doko: stamps/prune-build-dir was to remove the test artifacts, but they were only being kept because of the jtreg retain setting at the time
[13:45] <tdaitx> so you can very well remove it now
[13:46] <doko> ok
[13:47] <tdaitx> doko: as for JT_JAVA, if not set it depends on the default-jdk package, but we build depend only on openjdk-11-jdk-headless
[13:49] <doko> but your assumption breaks for 12 and 13
[13:49] <sil2100> tdaitx: on it in some minutes o/
[13:51] <tdaitx> doko: well, unless we get default-jdk as b-deps we either have to manually maintain JT_JAVA or find a way to automatically detect which jvm to use
[13:52] <tdaitx> at the time I considered that the less intrusive way was to hardcode it into the scripts, as we rarely change the control file
[13:54] <doko> I think it's wrong to run jtreg with the jdk you want to test itself
[14:02] <tdaitx> oh, that... indeed, we could let the autopkg scripts use their hardcoded JT_JAVA instead
[14:59] <sbeattie> gradle updated dependencies is +1 from me