=== zyga|afk is now known as zyga
[07:31]  * RAOF grumbles about writing symbols files for C++
[09:01] <tjaalton> will meson get updated in bionic for new features? mesa is about to drop support for autotools, and that's an issue for hwe backports..
[09:03] <seb128> tjaalton, we don't have anyone "owning" it that I know, it's going to be updated if there is a need for it and someone works on the SRU ... which could be you :)
[09:03] <seb128> tjaalton, was your question rather to know is we had already planned to update or has someone working on that update?
[09:04] <tjaalton> seb128: just a general question, it'd mean backporting a new upstream version from disco
[09:04] <tjaalton> later on
[09:04] <seb128> well, it's a bit a question in the air :)
[09:04] <tjaalton> or backporting just what's needed (binary overrides)
[09:05] <seb128> I think it's up to who does the SRU and the SRU team to accept the update or not (depending on motivation vs risk)
[09:05] <tjaalton> oh well, I guess we can fix meson one way or another, so I don't need to raise this on mesa-dev
[09:05] <seb128> yeah, I think it's not their problem
[09:05] <seb128> well it could be raised that it would be nice if they built on older versions/distros
[09:06] <seb128> then whether they want to be nice to those usecase or not it's up to them...
[09:06] <tjaalton> this one feature is needed for overriding which llvm-config is used, and support for binary overrides will be in meson 0.49.0
[09:06] <seb128> k
[09:06] <seb128> I guess for us it also depends on how complex/safe to backport those changes are
[09:07] <tjaalton> right
[09:32] <cpaelzer> xnox: the "efficiency" of http://autopkgtest.ubuntu.com/packages/s/systemd/disco/ppc64el (and other arches) to succeed is really §$%&! , is there anything ongoing already that we can hope for to improve on those tests?
[09:33]  * cpaelzer knows hope dies last, but prepares for that to happen soon :-)
[09:35] <cpaelzer> seeing doko, vorlon, jbicha, LocutusOfBorg and seb128 in the list of people who currently hit retry on it indicates I might not be alone with my feelings :-)
[09:36] <cpaelzer> lol - that list even passes the limit of the IRC channels spam detection :-)
[09:37] <cpaelzer> since systemd/239-7ubuntu12  (and on ppc64 before that) it seems to always hit testcase boot-and-services
[09:39] <doko> and add linux to that list of packages ...
[09:40] <cpaelzer> doko: to the list of packages people hit retry too often?
[09:55] <doko> cpaelzer: to the list of packages with unreliable autopkg tests which never get fixed
[09:55] <cpaelzer> I saw xnox fixing another one just in the last upload
[09:56] <cpaelzer> and the current breakage on ppc seems so "reliable" that it must be fixed
[09:56] <cpaelzer> but yeah - some packages are just known to be that way
[09:56] <cpaelzer> never the less migration will only happen when things are green
[09:57] <cpaelzer> so I opened bug 1805358 and take a naive look if I can reproduce it here somehow
[09:57] <ubottu> bug 1805358 in systemd (Ubuntu) "autopkgtest boot-and-services fails on many architectures very often since systemd/239-7ubuntu12" [Undecided,New] https://launchpad.net/bugs/1805358
[09:58] <xnox> cpaelzer, opening bugs about individual bits that fail is good. I have been playing wack-a-mole with some of these.
[10:02] <cpaelzer> yeah I'll give it a try to reproduce it since it is in like 14/14 of the last tests
[10:02] <cpaelzer> but a local repro in KVM of course worked, so I'll try on ppc64 now
[10:08] <doko> apw: linux autopkg fail ping
[10:10] <apw> doko, yeah i think i asked sforshee to have a look
[10:47] <blackflow> Hello, question about initramfs-tools scrips and hooks. the manpage (and pretty much every script in /usr/share/initramfs-tools/...) contains the PREREQ stanza. Why is that stanza done in that particular (a bit convoluted) way?  PREREQ var + function that echoes it + case switch that calls the function. looking at the code, PREREQ is not used anywhere else.
[11:06] <cpaelzer> hiho ahasenack
[11:06] <ahasenack> hi
[12:10] <LocutusOfBorg> jbicha, link-grammar seems broken?
[12:10] <LocutusOfBorg> the new sql file is not installed in the package? https://ci.debian.net/packages/l/link-grammar/testing/amd64/
[12:10] <LocutusOfBorg>  /usr/bin/install -c -m 644 dict.db 4.0.affix 4.0.constituent-knowledge 4.0.knowledge 4.0.regex '/<<PKGBUILDDIR>>/debian/tmp/usr/share/link-grammar/demo-sql'
[12:10] <LocutusOfBorg> but those files are not ship
[12:11] <jbicha> tjaalton: it might be safer to have a new source package for a backported meson so that it's opt-in & won't affect other packages that build with meson
[12:14] <jbicha> LocutusOfBorg: link-grammar is a QA package so feel free to upload if you figure out how to fix the tests
[12:17] <tjaalton> jbicha: ah, indeed
[12:19] <LocutusOfBorg> jbicha, I prefer to ask you, because I'm not sure about where to ship such files
[12:19] <LocutusOfBorg> the change is trivial, but I don't know even how to test it
[12:30] <jbicha> LocutusOfBorg: I didn't look closely at all but maybe those files are only needed by the tests?
[12:58] <sforshee> doko: looks like "proc: restrict kernel stack dumps to root" got backported to 4.18 and qrt needs to be updated accordingly
[12:58] <sforshee> sbeattie: ^
[13:13] <LocutusOfBorg> jbicha, it might be, however I don't know how to exclude it...
[13:14] <TJ-> cyphermox: would you consider re-opening #1798171 or suggesting a workaround (see my comment at the end of the bug). We've had 2 users report they are now unable to even boot the installer and there's no obvious way for them to clear the Mok* variables
[13:17] <sforshee> sbeattie: how about this (untested) - http://paste.ubuntu.com/p/sf6DGqHQr7/
[14:02] <seb128> xnox, cyphermox, vorlon, the dnsmaq update in disco seems to create issues for n-m's autopkgtests, who would be the right person to look at that?
[16:10] <vorlon> seb128: dnsmasq appears to be owned in main by the server team
[16:15] <seb128> vorlon, do you now who from the server team can be appropriate to nag about that?
[16:23] <vorlon> rbasak, smoser, powersj: ^^ who could help with dnsmasq-induced regressions in NM autopkgtests?
[16:24] <rbasak> FYI, I wondered why the server team had dnsmasq. Answers are libvirt, fan, nova and neutron.
[16:25] <rbasak> (and network-manager which is !server)
[16:25] <rbasak> I believe lxd was formally needed but it's a snap now I think.
[16:26] <rbasak> (from http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/rdepends/dnsmasq/dnsmasq-base)
[16:36] <sbeattie> sforshee: yeah, that's probably fine. I had been trying to make sure the script caught it if we ever reverted the patch that made /proc/self/stack readable only by root...
[16:37] <sforshee> sbeattie: in that case it would revert back to actually doing the test, which seems fine imo
[16:40] <rbasak> vorlon, seb128: it'll be me.
[16:44] <xnox> rbasak, eh, dnsmasq is our dns server, no?! as in the one and only, default one, if one wants to run a nameserver, no? irrespective of libvirt/fan/nova/neutron/etc.
[16:45] <xnox> or do we recommend something else as the primary dns servers?
[16:45] <rbasak> xnox: bind9 is still in main and has always been "the" DNS server for Ubuntu since before dnsmasq existed I suspect.
[16:46] <xnox> rbasak, ah, right, yes "bind9" is still a thing.
[16:46] <xnox> hmmm....
[16:46] <sbeattie> sforshee: applied and pushed, thanks!
[16:46]  * xnox doesn't like this duplication, but oh well.
[16:47] <rbasak> I've always seen dnsmasq as a swiss army knife for "special" setups, rather than as a production DNS server. Perhaps that view is wrong now.
[16:53] <teward> xnox: check lxd deps
[16:53] <teward> IIRC there used to be a dnsmasq requirement for LXD to work for internal .lxd definitions
[16:54] <teward> not sure if it's still a requisite
[17:16] <rbasak> teward: lxd only exists as a transitional (to snap) package in Disco now.
[17:18] <teward> ack
[18:17] <rbasak> seb128, xnox, cyphermox, vorlon: seems to me to be be a race in n-m dep8 tests. I've reproduced locally, but seen the failing test pass once (and fail the rest of the time). If it loses the race it (n-m) seems to get stuck in a loop. I'll carry on looking tomorrow.
[18:17] <rbasak> (and it never fails with release pocket dnsmasq-base that I've seen)
[18:18] <vorlon> rbasak: ack, thanks for looking
[18:18] <vorlon> xnox: dnsmasq is definitely not recommended as a general-purpose DNS server, any more than we recommend using it in place of systemd-resolved
[18:18] <xnox> ok
[18:23] <cyphermox> vorlon: to be fair, any DNS server you install has the potential to screw things up if you don't know what you're doing
[18:23] <cyphermox> that's not only true of dnsmasq
[18:24] <rbasak> I think this might be the actual failure: https://paste.ubuntu.com/p/C8XCX8wzn5/
[18:25] <rbasak> and I think that @network_test_base.run_in_subprocess is hanging on the assertion failure (ie. being unhelpful in the failure case)
[18:26] <cyphermox> what release are we looking at?
[18:26] <rbasak> Disco
[18:26] <rbasak> This is an autopkgtest regression triggered by the dnsmasq that is in disco-proposed
[18:26] <rbasak> On the existing n-m dep8 tests in disco
[18:26] <rbasak> What does LOWERLAYERDOWN mean?
[18:26] <rbasak> Is it some kind of precursor to DOWN?
[18:28] <cyphermox> it's a special state for some interfaces, to say that a dependent part is down
[18:28] <cyphermox> in this case, it would be the veth42 half
=== zyga is now known as zyga|afk
[18:35] <cyphermox> rbasak: you ran that test locally?
[18:35] <rbasak> Yes
[18:35] <rbasak> (in a VM)
[18:35] <cyphermox> if so, could you check under /tmp for a dnsmasq.log if you still ahve the VM?
[18:36] <rbasak> Yes, but I need to run, sorry. Back later.
[18:36] <cyphermox> ok
[18:37] <juliank> huh, I suddenly stopped sharing via smb today
[18:37] <juliank> I think there was an option in settings to enable file sharing or something, but I don't see it
[20:01] <vorlon> cyphermox: we weren't talking in the context of installing a dns server and it screwing things up; we were talking in the context of installing dnsmasq to be a public DNS server, which itself constitutes screwing up ;)
[20:34] <rbasak> cyphermox: still around?
=== zyga|afk is now known as zyga
[20:54] <seb128> vorlon, rbasak, thx for dnsmasq
=== zyga is now known as zyga|afk
[21:21] <cyphermox> rbasak: yes
[21:22] <cyphermox> vorlon: I understand. screwing up is made easy by installing dnsmasq, instead of dnsmasq-nase
[21:22] <cyphermox> *base
[21:23] <cyphermox> I suspect there's some kind of subtle small change in how dnsmasq starts that breaks the NM tests?
[21:23] <cyphermox> OTOH, why do we bother with dnsmasq in there now that we no longer use it as a caching nameserver?
=== karimsye is now known as karimsye-food
[21:40] <rbasak> cyphermox: I couldn't get a log file, but that may because of what I did. I do get a stdout/err dump though. Got time for a HO and I'll explain where I'm up to?
=== karimsye-food is now known as karimsye
[22:41] <seb128> cyphermox, hey, did you see on bug #1794292 that it turned out that the user was missing cryptsetup-initramfs which makes plymouth use vesa/hit the bug?
[22:41] <ubottu> bug 1794292 in plymouth (Ubuntu Cosmic) "plymouthd crashed with SIGSEGV in /sbin/plymouthd:11 in ply_renderer_set_handler_for_input_source -> ply_keyboard_stop_watching_for_renderer_input -> ply_keyboard_stop_watching_for_input -> ply_device_manager_deactivate_keyboards -> on_deactivate" [High,Confirmed] https://launchpad.net/bugs/1794292
[22:42] <seb128> he's also hinting that upgrading from bionic doesn't pull that package in, which is worth checking
[22:47] <cyphermox> rbasak: nah, I can run the tests here later
[22:47] <cyphermox> mmkay