=== led_dark_2 is now known as led_dark_1
[09:59] <doko> tsimonq2: https://bugzilla.opensuse.org/show_bug.cgi?id=1121214 seen in libqt
[09:59] <ubottu> bugzilla.opensuse.org bug 1121214 in Basesystem "GCC 9: libqt4 build fails" [Normal,New]
[10:17] <doko> jamespage: murano-agent fails autopkg tests (with python 3.7.2)
[12:01] <rbasak> juliank: why the dnsmasq upload? I thought Laney was sorting it in the network-manager autopkgtests?
[12:02] <juliank> rbasak: i don't know, Laney asked me if I'd upload it
[12:03] <Laney> The dnsmasq upload was the failure; my changes to n-m fixed some other ones, but not those which were failing on autopkgtest.u.c
[12:04] <rbasak> I feel that this just kicks the can down the road, and I'm not keen on having to maintain this patch :-/
[12:05] <rbasak> (based on my current and rather incomplete knowledge of the actual problem; but I suspect that's the case with everyone else involved too)
[12:07] <Laney> Second best approach that I could see given that we don't know how to fix it
[12:08] <Laney> Changing the tests in network-manager to work around a bug in dnsmasq would not have been right, IMO
[12:08] <Laney> and I *did* do some analysis and post on the upstream list, which I still hope/expect to result in a proper fix
[12:10] <rbasak> I agree with the general principle of not having to change the tests in N-M to work around a bug in dnsmasq.
[12:11] <rbasak> But it seemed to me that n-m tests weren't actually testing the right thing?
[12:11] <rbasak> In that the failure couldn't identify a specific buggy use case in dnsmasq?
[12:11] <rbasak> In that case narrowing down the n-m tests seems like a good idea.
[12:12] <Laney> what do you mean?
[12:12] <Laney> It was always a specific few tests that were failing in the same way
[12:13] <rbasak> But AIUI we haven't been able to say to dnsmasq upstream "here's a bug: when we do <valid use case> it results in <incorrect behaviour> instead of <expected behaviour>"
[12:15] <Laney> I think my thread was fine in that sense
[12:16] <Laney> Upstream attempted to come up with a patch but it didn't work
[12:16] <rbasak> I appreciate your work in analysis and talking to upstream btw. Hopefully that'll lead to a proper fix and we'll be able to drop the patch. I'm just concerned in case that doesn't happen, we'll end up stuck.
[12:16] <Laney> If someone else wants to help out and create a more minimal reproducer, that would be welcome. I was suffering from a lack of knowledge.
[12:16] <rbasak> I got the impression that upstream haven't identified a specific bug either. We only have your successful bisection, and we're all still blind to the underlying cause.
[12:17] <rbasak> (and blind to even what the bug actually is)
[12:18] <Laney> That's... why you post a bug report?
[12:19] <rbasak> We know that an upstream commit caused a change in behaviour that broke us.
[12:19] <rbasak> We don't know that there's actually a bug in upstream dnsmasq...do we?
[12:19] <Laney> I'm confident enough.
[12:19] <Laney> But if you're unhappy with my call, it's your team's package.
[12:20] <rbasak> I'm not sure I agree. But anyway, I appreciate your time on this. It's probably not worth us spending more time on discussing this more unless something further happens.
[12:20] <Laney> Put the change back in, it'll get blocked in proposed because of breaking network-manager's tests.
[12:21] <Laney> And then, well, we can argue about who gets to debug it.
[12:25] <juliank> That seems reasonable
[12:26] <juliank> We really need to have a convention for changes we made that we do not want to stop syncing. So something between ubuntu and build
[12:27] <juliank> So that I could have uploaded that hack with that version, and then a later sync would still happen and we'd see it being broken again (or it's fixed and migrates)
[12:27] <rbasak> Something that starts with 'l' or 'm' then :-P
[12:28] <juliank> Well, it could be any string lower than ubuntu
[12:28] <juliank> like buntu
[12:28] <juliank> 1.0-1buntu1
[12:28] <juliank> that was my silly string
[12:28] <Laney> I should mail the person who wrote the patch in question in the first place and see what they think
[12:29] <juliank> 1.0-1ubuntmp1
[12:29] <juliank> ubuntmp sorts well, but is not entirely obvious
[12:38] <Amnesia> question, I'm trying to create a cosmic chroot, but debootstrap is stating that the InRelease file has expired: E: InRelease file http://archive.ubuntu.com/ubuntu/dists/cosmic/InRelease is expired since (Wed, 09 Jan 2019 00:00:00 +0100)
[12:38] <Amnesia> does anyone have a clue what's goin on?
[12:40] <juliank> So, haproxy and wget are stuck in proposed as they built against pcre2. I patched wget to use pcre3 again
[12:40] <juliank> Not sure about haproxy
[12:40] <juliank> Amnesia: What do you see when you open http://archive.ubuntu.com/ubuntu/dists/cosmic/InRelease (wget, curl, or browser, whatever)
[12:41] <Amnesia> juliank: Date: Thu, 18 Oct 2018 15:17:19 UTC
[12:41] <juliank> Amnesia: Right, but no valid-until line, right?
[12:41] <Amnesia> correct
[12:43] <juliank> Amnesia: so, it works for me in disco, which release are you trying that on? Also, I think you can check in the target directory you specified and look at release files there
[12:44] <Amnesia> I'm trying it on arch..
[12:44] <juliank> Amnesia: ok, that's trickier
[12:44] <juliank> Amnesia: that's debootstrap 1.0.113?
[12:44] <Amnesia> yep
[12:45] <Amnesia> https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/debootstrap&id=03584f10a9edb8de54c6417f133ecea5862f4ff3
[12:46] <juliank> Amnesia: So, I don't see how this happens
[12:46] <juliank> Amnesia: I think you can run debootstrap as sh -x <path to>/debootstrap
[12:47] <juliank> that should give you a verbose log
[12:48] <Amnesia> yep, going through it atm..
[12:48] <juliank> Amnesia: No, I see how this happens
[12:48] <Amnesia> you do?
[12:49] <juliank> Amnesia: Passing --no-check-valid-until should make it work
[12:49] <juliank> The code assumes that Valid-Until is in the release file, which it is not for ubuntu
[12:50] <Amnesia> hm seems to work indeed
[12:51] <Amnesia> https://github.com/felixonmars/debootstrap/blob/4f6c6c0ccfd15145bae94b204056be3f78b08670/functions#L632
[12:51] <Amnesia> looks like you're right yes
[12:52] <juliank> That's https://bugs.debian.org/918722
[12:52] <ubottu> Debian bug 918722 in debootstrap "debootstrap: says InRelease file expired" [Normal,Open]
[12:53]  * Amnesia facepalms
[12:53] <Amnesia> I should've checked the bug tracker
[12:53] <Amnesia> sorry for the hassle juliank
=== Serge is now known as hallyn
[17:01] <seb128> bdmurray, hey. Could you help with https://launchpad.net/ubuntu/+source/gvfs/1.38.1-0ubuntu1.1 ? It includes 3 fixes, 2 have been verified and the 3rd one isn't working because it's relying on a samba change which we don't have in our version. The non-verified one is basically equivalent of no-change, can we validate the SRU as it? or do you want another upload with that change removed? (but then we need to revalidate the other fix/delay?)
[17:03] <seb128> vorlon, how did you manage to get a SRU in without bug reference? ;) (https://launchpad.net/ubuntu/+source/livecd-rootfs/2.542.1)
[17:04] <seb128> bdmurray, https://launchpad.net/ubuntu/+source/fontconfig/2.12.6-0ubuntu2.3 should also probably be deleted from bionic-proposed, it failed verification and it was decided that SRU was not needed after all so no fixed version has been uploaded
[17:05] <vorlon> seb128: well, I didn't accept it, ask whoever did :)
[17:05] <vorlon> seb128: (livecd-rootfs is a special case, but having an SRU with no linked bugs at all risks foundering on the process)
[17:15] <seb128> vorlon, right, unsure if the "who accepted" info is available somewhere? anyway, I mentioned it in case that was an overlook because it looks like the sort of isse that could lead the SRU to be stucked because ti's never marked as green/verified on the report page
[17:15] <vorlon> seb128: nope, we record that information in comments on the linked bugs ;-)
[17:16] <seb128> k, well that usually doesn't work for me :p
[17:16] <vorlon> well in this case there's no linked bug, hence the ';-)'
[17:16] <seb128> right
[17:16] <seb128> anyway
[17:16] <seb128> thx for the reply :)
[17:22] <vorlon> bdmurray: ^^ does that happen to have been your accept?
[18:09] <bdmurray> vorlon: Yeah, it was I who accepted the package. I imagine you or Cody will nag about getting it released.
[18:09] <vorlon> bdmurray: ok :)
[18:11] <bdmurray> although I guess I misremembered what you'd added to the SRU page about it.
[18:12] <bdmurray> I blame Santa for that.
[18:15] <bdmurray> seb128: fontconfig will require an AA which I am not
[18:20] <bdmurray> seb128: I'm fine with letting gvfs into cosmic-updates.
[18:35] <seb128> bdmurray, thx, I can do fontconfig, I was just unsure if that needed some sort of SRU team ack first
[18:37] <bdmurray> seb128: Well I'll ack it just in case