[17:33] <gaughen> hey tdaitx - checking in on the open items for openjdk11 - what's left to do?
[17:43]  * sbeattie was trying to figure out the same
[18:42] <tdaitx> I was reviewing and testing the uploads we just did
[18:45] <tdaitx> there was a small difference in tomcat8 that I hadn't realized before, but I believe I actually got it right
[18:45] <tdaitx> the diff I had done when writing the document was based on the versions that balint used for the "bb to bb-proposed" u-u test
[18:45] <tdaitx> but what we probably missed is that we actually cared about "bb-security to bb-proposed"
[18:46] <tdaitx> so while the initial diff suggested that tomcat8 lacked proper support for openjdk 11 (and 10) in the init file, that was fixed on a security update
[18:46] <tdaitx> fortunately I reverted tomcat8's initd script to the one from bionic-security, not bb, so we have the sane update
[18:48] <sbeattie> oh cool
[18:48]  * sbeattie was playing around with u-u last night, too, but is not sure he was driving it correctly.
[18:49] <tdaitx> at the same time it means that 8.5.30-1ubuntu1.3 was not upgraded for users that had local changes to its initd
[18:49] <tdaitx> * automatically upgraded by u-u
[18:50] <tdaitx> anyhow, now that is done, I'm looking over a few autopkgtests that were marked as failed and a couple updates from debian
[18:51] <tdaitx> sbeattie: meanwhile, how long do you want to let the new uploads bake in -proposed?
[18:53] <sbeattie> given that the recent changes should not have touched code, I don't think they need to do the 7 day wait.
[18:54] <tdaitx> ok
[18:55] <tdaitx> the updates on debian that I am looking into are https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925071 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925586
[18:55] <tdaitx> * am planning to look into
[18:56] <tdaitx> the first bug would affect xenial to bionic updates, but I haven't tested that
[18:59] <tdaitx> the second is reported against android-sdk-helper which we did not rebuild, but could possibly cause other packages to fail as well (the ones we uploaded were not affected by that issue)
[19:00] <tdaitx> so neither feel like an actual blocker
[19:01] <tdaitx> doko: sbeattie: vorlon: let me know if any of you disagree with that assumption ^
[19:28] <vorlon> tdaitx: so one last question, do the new binary packages from openjdk-lts declare Breaks: on older versions of the packages that are runtime-incompatible with the new jre?
[19:29] <tdaitx> vorlon: we only have that "Breaks: clojure1.8 (<= 1.8.0-7ubuntu1~)"
[19:29] <tdaitx> in openjdk-11-jre-headless
[19:29] <vorlon> tdaitx: I was just chatting w/ sarnold and it occurred to me that this might matter, in particular for packages that could be held back in some cases by u-u (AIUI: netbeans, visualvm, jetty9, tomcat8)
[19:31] <tdaitx> hmm, yeah, we didn't update it to add the "Breaks" clause for those
[19:31] <tdaitx> netbeans never worked afaik, so we could ignore that one
[19:34] <tdaitx> oh well, maybe somebody got netbeans working with _some_ jdk by playing around the conffiles, so yeah, we might want to add it anyway
[19:38] <vorlon> sbeattie: ^^ do you think we should do a rebuild of openjdk-lts to add these breaks before pushing out, or do you think we should bundle that fix (which is correct but probably only helps a very small number of people) with the subsequent openjdk-lts security upload?
[19:40]  * sbeattie hrms.
[19:44] <tdaitx> wth, why does openjdk in bionic-proposed (11.0.2+9-3ubuntu1~18.04.2) shows the armhf as failed while the armhf build page says all was fine?
[19:46] <vorlon> tdaitx: https://launchpad.net/ubuntu/+source/openjdk-lts/11.0.2+9-3ubuntu1~18.04.2/+publishinghistory shows doko had to delete it and recopy it because it was "copied without armhf binaries" the first tiem
[19:47] <vorlon> so the binaries made it across the second time, but unfortunately the web ui gives you links to the build record for this archive instead of for the source archive, for armhf
[19:47] <tdaitx> we could rebuild it, just consider that armhf takes ~12 hours (and arm64 about 11h)
[19:47] <vorlon> tdaitx: it doesn't need rebuilt
[19:47] <vorlon> for this
[19:47] <tdaitx> I meant for the breaks =)
[19:47] <vorlon> right
[19:50] <sbeattie> I'm less concerned about netbeans, visualvm, and jetty9, but potentially breaking people's tomcat8 in the middle of the night seems ill-advised.
[19:52] <sbeattie> so my inclination is to lean towards adding the breaks
[21:28] <tdaitx> sbeattie: vorlon: is this good enough: "Breaks: clojure1.8 (<= 1.8.0-7ubuntu1~), jetty9 (<< 9.4.15-1~), netbeans (<< 10.0-3~), tomcat8 (<< 8.5.39-1ubuntu1~), visualvm (<< 1.4.2-2~)"?
[21:28] <tdaitx> do we want it for cosmic as well? disco?
[21:28] <vorlon> tdaitx: are those the correct binary package names for each case?
[21:29] <vorlon> and is it the case that each of those 4 packages is included in the update due to runtime breakage?
[21:29] <vorlon> but e.g. maybe you should have libjetty9-java instead of jetty9
[21:30] <tdaitx> vorlon: yes they are, I think libjetty9-java does not ship any of the conf files
[21:30] <tdaitx> they were all in jetty9 iirc, let me double check that
[21:32] <tdaitx> libjetty9-java only has the jar and maven files
[21:33] <tdaitx> vorlon: is my assumption correct that we want the binary that carries the actual conffiles?
[21:34] <vorlon> tdaitx: the breaks: should be against whichever packages are actually broken at runtime, and *might* be held back by u-u
[21:34] <tdaitx> so, libjetty9-java does not depend on the conffiles afaik, it is just the shared classes
[21:35] <tdaitx> jetty9 does use those shared classes to get the server setup and then uses the conffiles for configuration
[21:49] <vorlon> tdaitx: right, so that makes sense for jetty9
[21:50] <vorlon> if the other packages fit in the same category, then all good
[21:50] <tdaitx> yep, all of the same
[21:59] <tdaitx> oh lintian, oh joy
[22:05] <tdaitx> uploaded new openjdk-lts into stage5 for bionic
[22:16] <tdaitx> same for cosmic, if we don't want the breaks in cosmic for any reason feel free to stop the builders and delete it
[22:17] <tdaitx> afk, back in ~2.5h