[00:21] <robert_ancell> bdmurray, I fixed the SRU template in https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1738164 - please release that SRU! Needed because the reviews server is going to be disabled soon.
[08:42] <dupondje> https://people.canonical.com/~ubuntu-security/cve/2019/CVE-2019-0211.html -> I would have expected to see patches for this already?
[08:44] <sbeattie> dupondje: mdeslaur has packages available for testing https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages ; feedback welcome
[13:32] <rbasak> sil2100: on non-SRU editing the template, there was also https://wiki.ubuntu.com/StableReleaseUpdates?action=diff&rev1=290&rev2=292
[13:32] <rbasak> I didn't mention it before because I didn't find that change objectionable.
[13:38] <sil2100> rbasak: hey, thanks for watching those changes, makes me feel better that there's someone subscribed and monitoring those
[13:38] <sil2100> rbasak: yeah, I wouldn't think this one is something I'd personally require, but it certainly is a bit less 'invasive' (but I guess that's just my feeling)
[13:39] <cpaelzer> cjwatson: I did not mean to stress the openssh bug or you, I just didn't know what feedback times to expect on that list and therefore pinged for you
[13:39] <sil2100> rbasak: although this one I'm less keen on reverting since that's what all the kernel SRUs were following anyway
[13:39] <cpaelzer> but the TL;DR for me is that you seem to have it under control and that is enough for me
[13:40] <cpaelzer> I was only concerned to miss getting into Disco in time
[13:41] <cjwatson> cpaelzer: Yep - I've had a private response FWIW
[14:34] <sil2100> mvo: hey! Did you take a look at bionic/xenial test regressions triggered by systemd?
[14:34] <sil2100> mvo: I'd like to release it to -updates today, was wondering if you checked if those are related/unrelated etc.
[14:35] <sil2100> mvo: the xenial ones seem unrelated, guess I can just hint some of those and let it in
[14:35] <sil2100> mvo: there seems to be a bit more for bionic though
[14:36] <sil2100> mvo: ok, anyway, I'll look at those now
[14:53] <doko> rbalint: xnox says the tomcat9 fix should be ok. could you upload that today, then I'll take care about bionic and cosmic
[14:55] <mvo> sil2100: I did look
[14:55] <mvo> sil2100: sorry for the late reply
[14:56] <mvo> sil2100: I did look and all the ones I looked at had a long history of failures, I did not spot anything that looked like a "new" thing, but let me double check again. iirc there was something (libglib?) that I had to restart but then it went away
[14:57] <rbalint> doko, already uploaded, it is in unapproved
[14:57] <rbalint> doko, pinged sil2100 on #ubuntu-release
[14:58] <rbalint> doko, cosmic is already ok
[14:58] <rbalint> doko, (and up)
[14:58] <doko> rbalint: cosmic-proposed?
[15:00] <doko> hmm, don't see anything ini c or d
[15:00] <rbalint> doko, cosmic's systemd supports the syntax used in tomcat9.conf
[15:00] <doko> ahh, ok
[15:02] <doko> rbalint: I'm rejecting it, and uploading to the ppa, because we must not build against -updates, just security
[15:04] <sil2100> mvo: ACK!
[15:05] <rbalint> doko, ack
[15:05] <rbalint> doko, thanks
[15:26] <rbasak> sil2100: why not accept britney hints for SRUs via MPs? Or are you only saying that it hasn't been discussed?
[15:28] <sil2100> rbasak: I'm saying it's not a requirement
[15:28] <sil2100> rbasak: at least I never actually required anyone to do that for me - I appreciate it, but it's actually not much 'less' work for me to get that merged
[15:28] <doko> rbasak, sil2100: that should be documented, and then it should be ensured that these are regularily/daily addressed
[15:29] <sil2100> Yeah, currently it is not and I am not monitoring MPs for hints
[15:29] <sil2100> As this is not part of our official processes
[15:29] <rbasak> doko: I agree. First we need consensus on what the process should be though, which is what we're doing now. Then it can be documented.
[15:29] <sil2100> The only thing official part of the process so far is: for each failing autopkgtest we should have hints committed if we let the upload land
[15:30] <doko> sure, but the current practice of ignoring hints on #u-r isn't ideal either
[15:30] <sil2100> I personally just do it myself, or if someone pokes me with an MP I can use it instead
[15:30] <rbasak> sil2100: IMHO it is less work - because I can start my shift by looking for the MPs, and then the person on the next shift (after the report is regenerated) won't have to trawl through a rather large list of bugs looking for autopkgtest false positive explanations when the majority of bugs don't have those. IMHO that's a waste of time.
[15:30] <rbasak> If instead we use MPs, then I only need to pay attention to the bugs that are clean on the report.
[15:31] <rbasak> Separately, I'd like to make sure that bugs make it clear what is blocking SRU progress. I have thoughts on writing a bot for othat.
[15:31] <sil2100> rbasak: well, as I mentioned in the thread, there is tooling for that 'almost there'
[15:31] <sil2100> I don't want a separate bot for that
[15:31] <sil2100> It'll be part of britney
[15:32] <sil2100> It was reviewed recently and needs a few cleanups that I just need to get to finally
[15:33] <sil2100> Anyway, I'm open to suggestions, I can add checking for hint MPs as part of my general SRU shift if that's what we decide, but I would prefer a discussion before we do that
[15:35] <sil2100> I'm a bit worried that people would then blindly just submit MPs for hints without explaination of the failures, we'd have to formalize how such MPs should be formalized
[15:36] <sil2100> Since I'd like to know that someone did actually check the failure, identified why it's failing and leave it as a comment in the hint+MP-description, while right now it's obvious they have to 'convince us' that the hint is needed
[15:37] <rbasak> I feel that the same applies to an MP - no justification given, no approval - but sure, we can document that.
[15:38] <sil2100> Yeah, since like a half of the hint MPs I get are completely blank as far as context is concerned, so yeah, I have bad experiences + what x_nox already mentioned, people putting hints in bad places, merge conflicts etc.
[15:38] <sil2100> So usually for me it's not much less work
[15:42] <sil2100> (context: this is about SRUs)
[15:49] <mdeslaur> dupondje: https://usn.ubuntu.com/3937-1/
[15:54] <rbasak> sil2100: on the bot, I just meant that we need to ensure that bugs don't languish with nobody understanding that we're waiting on a hints MP (if that's what we decide the process should be). If your tooling enhancements can do that, then great.
[15:54] <rbasak> sil2100: separately, I want to write a bot that maintains a section in the bug description explaining exactly what the next step is, who needs to do it, etc.
[15:54] <rbasak> By looking at the unapproved queue, pending-sru report, tag status, dep8 status, etc.
[15:54] <rbasak> This would be for people unfamiliar with the SRU process, such as non-Ubuntu-developer community contributors.
[15:55] <rbasak> It'd also explain FAQ items such as "yes it's verified but not aged yet"
[15:56] <rbasak> Because otherwise the SRU workflow is quite convoluted and unfathomable to outsiders, IMHO, because it involves various different reports, queues, tags, workflow, paperwork, etc, all interacting in quite a complex way.
[16:07] <ddstreet> sil2100 is your tooling in lp, somewhere i can peek at?
[16:54] <pedahzur> Good morning (from my time zone)! I have an issue in Launchpad that affects 18.04 (and probably after). It has a link to the upstream bug, and a link to the patch that fixes the issue. How do I go about getting some attention on it so we could get a new version of the package released? https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1821242 Thanks!
[16:58] <sarnold> pedahzur: probably the next step is to attach a debdiff for the fix, fill in the SRU bug template in the bug report, and subscribe ubuntu-sponsors to the bug; the full details are on https://wiki.ubuntu.com/StableReleaseUpdates
[16:59] <pedahzur> sarnold: Thanks! Never done that before. Will be a learning experience. :)
[17:01] <sarnold> pedahzur: the one wrinkle that I don't understand is that you usually have to arrange for the bug to be fixed in -devel, too; I *think* this should just be a bug fix for that, too, and it's not a huge patch, so probably doesn't need the feature freeze exception dance.. but that's outside my usual experience
[17:15] <rbasak> sarnold, pedahzur: right - feature freeze doesn't apply to bugfixes that don't involve feature changes.
[17:16] <sarnold> rbasak: good good :)
[21:11] <LeoB> hello! I am trying to compile libvirt for ubuntu from the git repo (https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt, branch ubuntu/bionic) but 'fakeroot debian/rules binary' fails, with messages about moving files
[21:11] <LeoB> https://paste.ubuntu.com/p/N4YN6p8KFk/
[21:11] <LeoB> is this the right procedure?
[21:12] <LeoB> (I am testing a patch backport)
[21:15] <rbasak> LeoB: https://git.launchpad.net/~libvirt-maintainers/ubuntu/+source/libvirt/tree/debian/rules?h=ubuntu/bionic-4.0#n182
[21:15] <rbasak> I suspect that's a bug in packaging because DEB_HOST_MULTIARCH isn't set but your entry point should work.
[21:16] <rbasak> What you're doing is reasonable I think, but to work around te bug you might try https://wiki.ubuntu.com/SimpleSbuild
[21:16] <rbasak> sbuild is what Ubuntu developers usually use to build in a clean and reproducible environment
[21:18] <rbasak> Oh, and usually you'd run the build target first without fakeroot.
[21:23] <LeoB> rbasak,this sbuild seems very complicated
[21:24] <rbasak> Yes, it is unfortunately. Once set up it's not too bad.
[21:24] <rbasak> We're working on a much easier (one command) way to build debs reliably from a git checkout, but it's quite buggy right now I'm afraid.
[21:25] <LeoB> well, ok
[21:25] <LeoB> thanks for helping