[00:39] <doko> if we want the breaks, then the breaks should be against the binary package that all other binaries built from the same source depend on
[00:40] <doko> so we have to wait for the build until Thu evening, and we don't want to copy these to -security on Friday? Does this mean the copy won't happen before Monday?
[00:45] <vorlon> Thursday evening> it wouldn't be Thursday evening here, if it's a 12h build
[00:46] <vorlon> 10h from now would be mid-morning European time
[00:50] <doko> let's see
[00:50] <doko> I'll join the meeting tonight
[13:33] <tdaitx> "then the breaks should be against the binary package that all other binaries built from the same source depend on" ok, but why? where I can see more of that, I did search but I don't remember seeing how Breaks should be written
[13:33] <tdaitx> in our particular case, the other binaries do not use the conffiles, so when loading eg libjetty9-java one needs to provide the configuration to it
[13:33] <tdaitx> libjetty9-java is not going to look at /etc/jetty/blah, and if it did then we would have to move the conffile to it
[13:33] <tdaitx> whatever is loading libjetty9-java should not expect to be able to use the conffile if it does not depend on jetty9 (which is the package with the conffiles)
[13:39] <tdaitx> thus, why breaks on any other package? it would make sense if we were adding the breaks because of code incompatibility, but we never tested if the previous libjetty9-java would or would not load with our new openjdk-11, we only know that for sure about jetty9 itself (same for all other packages in this list)
[15:11] <tdaitx> doko: vorlon: ^ so what should be done about Breaks?
[15:12] <doko> tdaitx: I copied your upload to the proposed pockets
[15:13] <tdaitx> yeah I saw that and it does not match what you said earlier
[15:14] <tdaitx> so I am a bit confused =)
[15:21] <doko> ?
[16:11] <vorlon> tdaitx: we're ok as long as u-u does not calculate (based on package relationships) that it is allowed to upgrade openjdk-lts, while holding back a package with a conffile conflict, resulting in the old version of that package being broken due to runtime incompatibilities
[16:11] <vorlon> so a direct Breaks: against the packages shipping the conffiles should suffice
[16:29] <tdaitx> yes, that was my understanding, but that is not the same as "then the breaks should be against the binary package that all other binaries built from the same source depend on"
[16:35] <tdaitx> what I mean is, the Breaks that I proposed and were uploaded:
[16:35] <tdaitx> 1) do satisfy "u-u does not calculate (based on package relationships) that it is allowed to upgrade openjdk-lts, while holding back a package with a conffile conflict, resulting in the old version of that package being broken due to runtime incompatibilities"
[16:35] <tdaitx> 2) do *not* satisfy "then the breaks should be against the binary package that all other binaries built from the same source depend on"
[16:39] <vorlon> tdaitx: right. I'm saying that I think what you've done is fine, and if there is any case where users still end up broken, that means the inter-binary dependencies within the other packages are wrong and we should fix those instead of having to re-upload openjdk-lts
[16:40] <tdaitx> yeah, that
[16:40] <tdaitx> yeah, that is what I was thinking about
[16:40] <tdaitx> thanks
[18:08] <sbeattie> vorlon: if we wait until monday to publish, is that going to mess with the disco release freeze?
[18:09] <vorlon> sbeattie: no, it just shortens the runway between this going out and the next openjdk security update having to follow
[18:11] <vorlon> sbeattie: I have no concerns from this side about pushing it out today, however, provided we get to the end of the list of checks. do you?
[18:12] <vorlon> I'm manually retriggering the libreoffice/bionic autopkgtests now
[18:13] <vorlon> (they had to be manually retriggered for the last one, so that's nothing I'm concerned about)
[18:13] <sbeattie> if there are regressions we've overlooked, I'm a little leery of trying to hurridly push fixes on a friday, for as large a transition as we are doing.
[18:13] <vorlon> ok, I'd defer to you
[18:14] <vorlon> for SRUs we treat Thursday as the cutoff in order to give us Friday as margin
[18:14] <vorlon> (with the weekend in extraordinary cases)
[18:18] <sbeattie> vorlon: yeah, same for security team; however, the scale here is a little larger than normal, and I'd really rather none of us were working over the weekend on it.
[18:31] <huehner> tdaitx: i just notice finally you reverted the tomcat8.service topic? and went back to init-script for the bionic sru?
[19:24] <tdaitx> huehner: yes, we decided to revert it, bionic was initially released with the initd script and never got the systemd service (compared to cosmic which had the systemd update)
[19:26] <tdaitx> this makes the update much less disruptive (for users) and easier to handle (for us)
[19:34] <vorlon> gaughen: ^^ note the preference from sbeattie for deferring the release until Monday
[19:46] <tdaitx> vorlon: gaughen: sbeattie: that and the fact that we wanted to give people some heads up before the actual change, right?
[19:46] <tdaitx> but that means the notice would have to be released either today or tomorrow
[20:12] <sbeattie> advance warning would be good, too, yes.
[20:15] <huehner> tdaitx: better for sru i agree. maybe i should been a bit louder about same topic (see pasetbin link from yesterday i send you) some weeks ago ;)
[20:15] <huehner> tdaitx: will try to retest on latest proposed tomorrow or over the weekend fomr our side
[20:40] <tdaitx> huehner: ok, thanks, indeed, eveything you addressed on that pastebin is fixed by removing the systemd.service and relying on the initd script
[20:43] <huehner> tdaitx: seen, thanks for the work. than we can revisit that more calmly for 20.04