[06:44] <RAOF> I AM VICTORIOUS OVER C++
[07:09] <cpaelzer> but not yet over capslock :-P
[09:51] <jamespage> xnox: https://launchpad.net/ubuntu/+source/ceph/13.2.2+dfsg1-0ubuntu1 python 2 -less ceph :-)
[09:56] <brainwash> seb128: hi. re libxklavier I'm not sure if reporting it upstream will do anything, because it seems to abandoned.
[09:56] <brainwash> https://cgit.freedesktop.org/libxklavier/
[09:56] <seb128> brainwash, well, we don't have good knowledge of that code so I doubt we are going to do a distro patch hack
[09:57] <brainwash> this patch was used before
[09:57] <seb128> doesn't hurt much also to upstream a report/revert suggestion, maybe someone still read reports there even if they are no active
[09:57] <brainwash> but then dropped without any reason
[09:57] <brainwash> at least I cannot find anything in the changelog
[09:58] <brainwash> I can create an upstream report
[09:59] <seb128> thx
[09:59] <brainwash> I guess I want at least the reason for why it was dropped in the debian sync
[10:01] <seb128> brainwash, doko did that sync https://launchpad.net/ubuntu/+source/libxklavier/5.4-1 so maybe check with him why he dropped it
[10:01] <brainwash> will do
[10:01] <seb128> https://lists.ubuntu.com/archives/yakkety-changes/2016-September/008523.html
[10:01] <seb128> thx
[10:01] <brainwash> already subscribed him to the report
[10:01] <seb128> thx
[14:44] <rbasak> seb128, cc: cyphermox: I filed https://code.launchpad.net/~racb/network-manager/+git/network-manager/+merge/359837
[14:44] <seb128> rbasak, thx
[14:45] <rbasak> seb128: should we sync on the n-m vs. dnsmasq dep8 issue? I don't think I can go any further without help at the moment - I understand what the n-m dep8 test is failing on, but not why or whether it's correct or how it's an issue with dnsmasq.
[14:46] <seb128> rbasak, I'm not really familiair with n-m nor this tests, maybe let's wait if cyphermox has an input on that?
[14:46] <cyphermox> already approved the MP
[14:46] <rbasak> cyphermox: thanks!
[14:47] <seb128> we should create the disco branch
[14:47] <seb128> rbasak, do you have the details on what the failure is due to?
[14:47] <rbasak> Yes, one moment.
[14:48] <rbasak> seb128: I believe it's this: https://paste.ubuntu.com/p/C8XCX8wzn5/
[14:48] <rbasak> LOWERLAYERDOWN instead of DOWN
[14:48] <rbasak> I think it's a race, since I've also seen it pass (just once though) with the supposedly failing dnsmasq.
[14:49] <rbasak> Though I tried an assertEventually and that didn't work, so I don't think the race is just that it's going to get to DOWN eventually.
[14:49] <rbasak> Howver I don't know what LOWERLAYERDOWN means in the context of n-m and these tests.
[14:52] <rbasak> seb128: to get that result I further used https://paste.ubuntu.com/p/gF6k4WRr8D/ together with the patch from my MP and running "sudo python3 -m unittest nm.ColdplugWifi.test_open_b_ip6_raonly_no_pe" from a VM inside debian/tests/ with the test deps installed from disco and only dnsmasq-base updated from disco-proposed
[14:53] <rbasak> seb128: and https://paste.ubuntu.com/p/Vv447HKJMJ/ didn't fix the problem
[14:53] <seb128> rbasak, and it works without the older version of dnsmasq?
[14:53] <rbasak> That's as far as I've got.
[14:53] <rbasak> Yes. It seems to reliably work if I downgrade back to dnsmasq-base from disco release pocket (I needed to reboot the VM for cleanup after the test fails)
[14:54] <rbasak> It almost reliably fails if I use dnsmasq-base from the disco proposed pocket, except that it worked once (not reproducible but I was convinced at the time it wasn't a mistake), which is why I think it's a race.
[14:58] <rbasak> To be clear, I'm not ruling out a regression in dnsmasq. Just that it seems more likely to be a race in n-m (or most likely its tests) to me right now, triggered by some related timing change in dnsmasq.
[14:59] <rbasak> Uh, _un_related timing change in dnsmasq.
[15:03] <seb128> rbasak, thx for the investigation, I'm busy on something else atm but almost done with that, I read properly what you wrote then
[15:04] <seb128> I don't know now much about those tests though, we really need a n-m maintainer
[15:04] <seb128> maybe cyphermox has an opinion on the tests/issues though?
[15:04] <rbasak> seb128: no problem. Shall I close down my trello card for now then? Let me know if you need anything though.
[15:06] <seb128> rbasak, unsure what's the trello card is about, if it is to get n-m unblocked/the autopkgtest test issue resolved, it's not really closed imho
[15:06] <rbasak> seb128: it is about that, but on the server team's daily board
[15:07] <seb128> rbasak, so your position is basically that you did the investigation, believe at this point that the issue on the n-m tests side and not dnsmaq and such your side is done?
[15:08] <rbasak> seb128: that's right. I'm happy to look again once you've looked and if you disagree. This is definitely one of those ones where it's unclear until someone figures out the actual root cause. It seems less productive for me to learn n-m internals to get to the root cause though, which is why I want to hand it over for now at least.
[15:09] <seb128> rbasak, if so that seems fair enough that you close the card yes, thanks for the work you did on it. It would be nice if maybe you could dump your summary/what you wrote before in a https://bugs.launchpad.net/ubuntu/+source/network-manager/+filebug report?
[15:09] <seb128> rbasak, ack
[15:09] <rbasak> Sure I'll do that.
[15:09] <seb128> thx!
[15:09] <seb128> we can pick up from there
[15:09] <seb128> and maybe bounce you back to you at some point, who knows ;)
[15:17] <cyphermox> fwiw I'm starting an autopkgtest run locally for NM, see what happens
[15:20] <rbasak> seb128, cyphermox: I filed bug 1805857
[15:21] <seb128> rbasak, great, thx
[15:21] <seb128> cyphermox, thx
[15:23] <cyphermox> autopkgtest -U --apt-pocket proposed=dnsmasq -s network-manager -- qemu ~u/autopkgtest-disco-amd64.img <3
[15:24] <seb128> cyphermox, could be easier to just install the new dnsmasq on your system/a vm and use the command Robie used in that bug report?
[15:25] <cyphermox> this should work
[15:26] <cyphermox> or not at all
[15:45] <murthy> will opencv libs be updated to v4 in 18.10?
[15:46] <tkamppeter> doko, possibly the complaining users have this proprietary plugin.
[15:48] <rbasak> murthy: seems unlikely given that https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913330 remains open, unless someone volunteers to do the work.
[15:51] <murthy> rbasak: right
[15:51] <teward> rbasak: 3.4.4 is in new up in Debian heh.
[15:51] <teward> so someone attempted to do the work :P
[15:52] <teward> but I doubt it'll get to v4 :P
[15:52] <Faux> (Way too late for 18.10.)
[15:52] <teward> ^ that
[15:52] <rbasak> Oh
[15:52] <teward> rbasak: rmadison -u debian opencv
[15:52] <teward> :P
[15:52] <teward> (easy query 123 :P)
[15:52] <rbasak> Yeah. I didn't pay attention and thought murthy was talking about Disco
[15:52] <Faux> Me too! :)
[15:52] <teward> rbasak: nope, 18.10, not 19.04 (they asked in #ubuntu first)
[15:53] <rbasak> murthy: see https://wiki.ubuntu.com/StableReleaseUpdates - 18.10 almost certainly will not be updated even if someone volunteers to do the work.
[15:53] <teward> rbasak: know anyone on the backoports team who's alive recently to do some backport work?
[15:54] <murthy> rbasak: I keep forgetting that
[15:54] <teward> because there's a nasty thing that i would like to have backported for this ancient 14.04 mail gateway I have to support (postgrey in Universe)
[16:08] <Bluefoxicy> oh for.
[16:08] <Bluefoxicy> "/boot must be on a partition of a local disk"
[16:09] <Bluefoxicy> no, /boot shall be an LVM partition if I have to mount the damned thing by hand through the console before installation begins
[16:09] <Bluefoxicy>  /dev/mapper/root-boot   2064208 1010780    948572  52% /boot
[16:09] <Bluefoxicy> who put this in the 18.04 installer?
[16:16] <Bluefoxicy> haha
[16:16] <Bluefoxicy> "Same problem here, this new installer is really bad. :(
[16:16] <Bluefoxicy> https://bugs.launchpad.net/subiquity/+bug/1785332
[16:17] <rbasak> teward: I don't know, sorry. Ask on ubuntu-devel@ if you're struggling?
[16:18] <rbasak> A few (able) people volunteered IIRC last time, so if you can't find someone, the team should be able to grow.
[16:18] <Bluefoxicy> aaaaaand I crashed the subiquity installer trying to edit a partition.
[16:18] <teward> rbasak: indeed.  I'm not a coredev or MOTU or I'd volunteer to be on the backporters team
[16:18] <teward> but meh.
[16:19] <teward> i have enough crap to deal with currently :P
[16:19] <teward> (firewall appliance migration at work >.<)
[16:19] <Bluefoxicy> crashes if you try to edit a logical volume, too!
[16:20] <teward> rbasak: though I could probably in theory argue that this should just be straight SRU'd, but there's a few new feature changes in there :|
[16:20] <teward> minor but still (this hasn't changed upstream it seems since 2016 o.O)
[17:05] <Bluefoxicy> debconf-get-selections in 18.04.1 says to install debconf-utils
[17:05] <Bluefoxicy> apt says that doesn't exist, and debconf-i18n replaces it
[17:07] <Bluefoxicy> wow that's broken
[17:09] <juliank> Bluefoxicy: debconf-utils does exist
[17:09] <juliank> Bluefoxicy: sounds like you don't have universe enabled
[17:09] <Bluefoxicy> aha!  I don't.
[17:09] <Bluefoxicy> are preseeds replaced by this curtain.conf thing?
[17:31] <nacc> Bluefoxicy: do you want #ubuntu-server?
[17:42] <xnox> Bluefoxicy, preseeds?!
[17:43] <xnox> Bluefoxicy, you can use classic d-i based server iso with preseeds; subiquity is interactive only.
[17:43] <xnox> (the new server installer)
[17:43] <xnox> Bluefoxicy, if you want to autoinstall your servers -> use $ apt install maas
[19:19] <ddstreet> xnox i have lp #1804487 to patch systemd that is rather urgent, i see you just uploaded systemd to disco today; would you prefer to roll this patch into the next systemd upload if you have one already going, or do you mind if i prepare an upload and ask you to sponsor/upload to disco (as i can only SRU, not upload to disco)
[19:20] <xnox> ddstreet, where are you SRUing that to?
[19:20] <xnox> ddstreet, there are blocked up systemd updates in _all_ releases at the moment =)
[19:20] <ddstreet> xnox it's just accepted upstream; it needs to go into disco, then sru to b/c
[19:20] <ddstreet> doesn't apply to x
[19:20] <xnox> ack
[19:20] <xnox> ddstreet, i am past EOD, i will look into that bug report tomorrow.
[19:21] <xnox> ddstreet, a straight up SRU of just that, will fail to SRU because of botched up security update that is in bionic & cosmic =/
[19:21] <ddstreet> thanks, let me know if you'd like me to handle any part of the upload to disco (or sruing)
[19:22] <ddstreet> yeah, i figure it will take a bit longer for sru'ing...but will be good to get into disco whenever possible so it's ready to sru when that path is clear