[07:37] <alkisg> Hi, where can I report the #ubuntu IRC operator Flannel?
[07:38] <Flannel> alkisg: You want #ubuntu-ops
[07:38] <alkisg> Thank you
[14:49] <tkamppeter> xnox, hi
[16:42] <juliank> Can anyone think of a reason _not_ to merge gnutls28 3.5.16?
[16:43] <ogra> it is work :P
[16:45] <juliank> ogra: other than that.
[16:45] <juliank> :D
[16:45] <ogra> yeah, i knew it would be a lame reason :)
[16:51] <juliank> ogra: You know what they say: one merge a day keeps the doctor away
[16:51] <ogra> haha
[17:31] <tsimonq2> juliank: The only reason I see is that a bunch of builders are still down, so I wouldn't expect it to build on a lot of arches
[17:32] <xnox> xnox_konversatio, heya!
[17:33] <xnox> xnox_konversatio, heya again
[17:33] <ogra> he doesnt want to talk to you it seems :P
[17:34] <xnox_konversatio> ogra: not happy with hexchat under gnome-shell, trying a few irc clients, and they all seem to suck w.r.t. gnome-shell notifications....
[17:34] <xnox_konversatio> i think i will have to get down and dirty and fix hexchat....
[17:34] <ogra> +1
[17:35] <tsimonq2> xnox_konversatio: psst, switch to irssi, we have cookies :P
[17:35] <ogra> do you also have tea to dip them into ?
[17:36] <tsimonq2> If you want :D
[17:38] <xnox> tsimonq2, i only do biscuits!
[17:42] <tsimonq2> xnox: We have those too ;D
[17:43] <xnox> tsimonq2, do you have gnome-shell notifications that i can click and would take me into the right view? (the right window/tab/chat screen of the person/channel with the highlight?
[17:43] <xnox> )
[17:44] <tsimonq2> xnox: Ah, no, not *that* advanced, sorry
[17:45] <cjwatson> builders> I can push through primary archive stuff on request, although autopkgtests still won't run
[17:46] <tsimonq2> cjwatson: autopkgtests> But amd64 and i386 will still run, right?
[17:47] <tsimonq2> cjwatson: builders> What qualifies to be pushed through?
[17:47] <cjwatson> amd64/i386> I think so, though that won't be enough for proposed-migration
[17:48] <cjwatson> Things that would previously have been eligible for building on non-virtualised builders when those were a thing; i.e. primary archive or PPAs exclusively uploadable by Canonical staff
[17:48] <cjwatson> (also it's a bit clickyclicky right now so I'm only doing things that are actually worth bothering with)
[17:49] <tsimonq2> Ok
[17:49] <tsimonq2> Is there any sort of ETA for these builders to return?
[17:49] <cjwatson> Not yet, sorry
[17:50] <tsimonq2> Alright.
[17:50] <cjwatson> Everything apart from ARM might be relatively soon since I noticed kernel updates today
[17:50] <cjwatson> Haven't been able to find out the ARM state yet
[17:50] <tsimonq2> Alright.
[17:51] <xnox> tsimonq2, is it for webkit with spectre fixes? or was that pushed through already?
[17:51]  * tsimonq2 hopes it's done in time to get Qt and nodejs transitions done before A2 freeze
[17:51] <cjwatson> For transitions in the primary archive you can absolutely ask me
[17:52] <cjwatson> Though as mentioned that won't help with the autopkgtest bit
[17:52] <cjwatson> Anyway, going out now
[17:52] <tsimonq2> cjwatson: Alright, I was just hoping to stage it in Bileto though.
[17:53] <tsimonq2> xnox: I'll look into it, although you might be interested in joining #ubuntu-qt and asking there ;)
[17:53] <tsimonq2> (other people might have better answers)
[17:53] <seb128> cjwatson, hey, do you know if we considered enabling the "download updates" option by default in the installer in the past? or what had been the reasons to not do it?
[17:54] <cjwatson> seb128: Sorry, I don't remember :-/
[17:54] <xnox> (note, these days, with ssd drives, install finished before one manages to download any meaningful amount of updates, and they are not applied - just cached in target for install post boot, as far as i recall)
[17:55] <tsimonq2> (I wonder if Lubuntu could figure something like that out for Calamares...)
[17:57] <seb128> cjwatson, no worry, I was asking in case since we are being requested to change the default for that option
[18:30] <infinity> tsimonq2, cjwatson: Are there any plans to fix the publisher explosion brought on by the cart-before-horse lubuntu seed git transition?
[18:48] <tsimonq2> infinity: ...there was a publisher explosion?
[18:48] <tsimonq2> infinity: I'll be happy to send code.
[18:52] <tsimonq2> (you know, as soon as someone tells me what exploded so I can investigate...)
[18:53] <juliank> tsimonq2: I found out in the meantime that it needs a new unistring version. I have a merge ready for this, but it breaks API (not sure how much. probably not a lot) and ABI, so I'll wait with that until the builds and tests run again. Or I just build with the bundled libunistring as it does now.
[18:53] <tsimonq2> juliank: Ok.
[18:54] <tsimonq2> juliank: (you're talking about gnutls28?)
[18:54] <juliank> yeah
[18:54] <tsimonq2> Ok
[18:54] <infinity> tsimonq2: Well, the explosion is that it's trying to germinate based on the bzr branch that now contains no seeds.  I'm not sure what needs to be done to make it look at the git bits instead.
[18:54] <juliank> tsimonq2: sorry ofr the confusion
[18:55] <tsimonq2> infinity: Can I get a link to what you're referring to here? I thought that particular element was fixed.
[18:55] <tsimonq2> juliank: np ;)
[19:06] <infinity> tsimonq2: No link to logs, but I'm trying to unwind this.  Kinda figured Colin would chime in by now. :P
[19:07] <sarnold> tsimonq2: what'd you break that needs both infinity *and* colin? :)
[19:08] <tsimonq2> sarnold: The thing is, I don't know :P
[19:08] <sarnold> tsimonq2: hah :) well done :)
[19:08] <infinity> tsimonq2: Well, the first thing you broke was deleting your seeds.
[19:09] <tsimonq2> infinity: That shouldn't have done anything wrong if the tooling knew Lubuntu seeds were in Git now.
[19:09] <tsimonq2> sarnold: heh
[19:09] <infinity> tsimonq2: Yes, and how was "the tooling" meant to know that? :P
[19:09] <infinity> (hence my "cart-before-horse" comment)
[19:10] <tsimonq2> Right, I sent MPs.
[19:10] <tsimonq2> cdimage knows, archive tools know, what did I miss?
[19:10] <infinity> launchpad.
[19:10] <tsimonq2> Aah.
[19:10] <tsimonq2> Ok.
[19:11]  * tsimonq2 loops slangasek in either way. :P
[19:12] <tsimonq2> infinity: I'll throw an MP at LP when I get home unless another kind soul feels inclined.
[19:12] <infinity> tsimonq2: Well, I'm still trying to unwind where this goes wrong...
[19:13] <infinity> It was obvious when you replaced your seed with a text file and the error was "no STRUCTURE file", it's less obvious now that the branch is deleted entirely.
[19:16] <tsimonq2> infinity: I'm confused. Why would Launchpad itself ever need to call germinate directly?
[19:17] <infinity> tsimonq2: The publisher germinates on every run to update overrides and task headers.
[19:20] <tsimonq2> infinity: Oh,
[19:21] <tsimonq2> infinity: I imagine it might just need a repo location update and a s/bzr/vcs=auto/ in the Germinate call.
[19:22] <tsimonq2> I could be totally wrong though.
[19:22] <infinity> tsimonq2: That would be true if it forked germinate, but it imports it in-process, which is more fun.
[19:23] <tsimonq2> infinity: Interesting. How is the VCS passed then?
[19:23] <infinity> So far, I'm going with "it's not".
[19:24] <infinity> Since the internal defaults worked fine right up until a few weeks ago.
[19:27] <tsimonq2> Hm.
[19:27] <infinity> Meh, this probably means diving into germinate itself so I can figure out what method(s) take vcs arguments so I can mangle the LP bits.
[19:27] <infinity> I'll save that for when I care a bit more.
[19:42] <tsimonq2> I can look into it later; I've already had to dig in there a bit.
[19:43] <tsimonq2> Colin might know more as well when he comes around.
[19:59] <infinity> kees, slangasek, stgraber, mdeslaur: TB.
[20:57] <nacc> slangasek: is there a way with sysv to say that if corosync starts that it should start pacemaker, if pacemaker is available? The phrasing of "Should-Start" is close, but then I think it's semantics don't make a ton of sense (or I misunderstand them)
[21:25] <cjwatson> tsimonq2: you want to look in lp:ubuntu-archive-publishing rather than LP itself (it was split out a while back)
[21:25] <cjwatson> hmm, but I didn't think that cared about the seed source.  lemme check
[21:26] <cjwatson> OK, no, the problem is surely the seed checkouts on snakefruit
[21:29] <cjwatson> infinity: tsimonq2 has done their bit here; the problem is that we need to switch some things over on snakefruit.  I'm busy just now but I'll sort it out.
[21:30] <tsimonq2> cjwatson: OK, cool.
[21:31] <tsimonq2> Thanks.
[21:32] <infinity> cjwatson: Yeah, the snakefruit hint was just given to my by cyphermox who pointed out that a tool looking at "people" was failing.
[21:32] <infinity> cjwatson: And then I remembered from firewall rule discussions when we set up archive-team.internal that the publisher probably looks at that same goop.
[21:45] <slangasek> nacc: not really any primitives for that in sysv, no.  you can have one init script manually call the other...
[21:48] <tsimonq2> Oh hey slangasek :D
[22:04] <rlink> In response to https://shibboleth.net/community/advisories/secadv_20180112.txt (CVE-2018-0486), is a patch preferred, or a pull from Debian (which is how it appears Shibboleth-related updates have gotten into Ubuntu previously)?
[22:06] <tsimonq2> rlink: Is there an Ubuntu delta on the stable release and are there more changes than just security updates between the versiom in the stable release and Debian?
[22:07] <tsimonq2> If the answer is no to both, then yeah, fakesyncing seems like the best option.
[22:07] <tsimonq2> Otherwise a patch is probably needed.
[22:08] <tsimonq2> Regardless rlink, you're likely looking for the person in the topic of #ubuntu-hardened. :)
[22:28] <sarnold> rlink: for devel release, a sync from debian is best; for supported releases, a debdiff with smallest feasible patch is best
[22:29] <sarnold> rlink: there's some description of the update process in https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
[22:37] <rlink> So, this is fun.  Trusty got a fakesync from Debian in July 2016, explicitly to pick up the backported patch that allows disabling DTD parsing (which conveniently also negates this new bug).  Xenial never got any such thing.
[22:38] <sarnold> yes, that can happen :(
[22:40] <nacc> slangasek: ok, that might be what need to do, i assume with a [ -f ... ] check tha thte other init script exists?
[22:54] <nacc> slangasek: and different question, how do I check, if it's sensible, in sysv that a given init script is enabled? Is it sufficient to look for a symlink in the appropriate /etc/rc*.d directory?
[23:25] <cjwatson> infinity,tsimonq2: Should all be sorted out now.  The update-seeds changes were fine, but they needed to be deployed, and I had to move the existing branches aside.
[23:28] <tsimonq2> cjwatson: Thanks!