| === zyga|afk is now known as zyga | ||
| * RAOF grumbles about writing symbols files for C++ | 07:31 | |
| 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:01 |
|---|---|---|
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| tjaalton | right | 09:07 |
| 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:32 |
| * cpaelzer knows hope dies last, but prepares for that to happen soon :-) | 09:33 | |
| 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:35 |
| cpaelzer | lol - that list even passes the limit of the IRC channels spam detection :-) | 09:36 |
| cpaelzer | since systemd/239-7ubuntu12 (and on ppc64 before that) it seems to always hit testcase boot-and-services | 09:37 |
| doko | and add linux to that list of packages ... | 09:39 |
| cpaelzer | doko: to the list of packages people hit retry too often? | 09:40 |
| 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:55 |
| 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:56 |
| 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:57 |
| xnox | cpaelzer, opening bugs about individual bits that fail is good. I have been playing wack-a-mole with some of these. | 09:58 |
| 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:02 |
| doko | apw: linux autopkg fail ping | 10:08 |
| apw | doko, yeah i think i asked sforshee to have a look | 10:10 |
| 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. | 10:47 |
| cpaelzer | hiho ahasenack | 11:06 |
| ahasenack | hi | 11:06 |
| 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:10 |
| 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:11 |
| jbicha | LocutusOfBorg: link-grammar is a QA package so feel free to upload if you figure out how to fix the tests | 12:14 |
| tjaalton | jbicha: ah, indeed | 12:17 |
| 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:19 |
| jbicha | LocutusOfBorg: I didn't look closely at all but maybe those files are only needed by the tests? | 12:30 |
| 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: ^ | 12:58 |
| LocutusOfBorg | jbicha, it might be, however I don't know how to exclude it... | 13:13 |
| 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:14 |
| sforshee | sbeattie: how about this (untested) - http://paste.ubuntu.com/p/sf6DGqHQr7/ | 13:17 |
| 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? | 14:02 |
| vorlon | seb128: dnsmasq appears to be owned in main by the server team | 16:10 |
| seb128 | vorlon, do you now who from the server team can be appropriate to nag about that? | 16:15 |
| vorlon | rbasak, smoser, powersj: ^^ who could help with dnsmasq-induced regressions in NM autopkgtests? | 16:23 |
| rbasak | FYI, I wondered why the server team had dnsmasq. Answers are libvirt, fan, nova and neutron. | 16:24 |
| 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:25 |
| rbasak | (from http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.disco/rdepends/dnsmasq/dnsmasq-base) | 16:26 |
| 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:36 |
| sforshee | sbeattie: in that case it would revert back to actually doing the test, which seems fine imo | 16:37 |
| rbasak | vorlon, seb128: it'll be me. | 16:40 |
| 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:44 |
| 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:45 |
| 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:46 | |
| 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:47 |
| 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:53 |
| teward | not sure if it's still a requisite | 16:54 |
| rbasak | teward: lxd only exists as a transitional (to snap) package in Disco now. | 17:16 |
| teward | ack | 17:18 |
| 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:17 |
| 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:18 |
| 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:23 |
| rbasak | I think this might be the actual failure: https://paste.ubuntu.com/p/C8XCX8wzn5/ | 18:24 |
| 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:25 |
| 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:26 |
| 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 | 18:28 |
| === zyga is now known as zyga|afk | ||
| 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:35 |
| rbasak | Yes, but I need to run, sorry. Back later. | 18:36 |
| cyphermox | ok | 18:36 |
| 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 | 18:37 |
| 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:01 |
| rbasak | cyphermox: still around? | 20:34 |
| === zyga|afk is now known as zyga | ||
| seb128 | vorlon, rbasak, thx for dnsmasq | 20:54 |
| === zyga is now known as zyga|afk | ||
| cyphermox | rbasak: yes | 21:21 |
| cyphermox | vorlon: I understand. screwing up is made easy by installing dnsmasq, instead of dnsmasq-nase | 21:22 |
| cyphermox | *base | 21:22 |
| 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? | 21:23 |
| === karimsye is now known as karimsye-food | ||
| 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? | 21:40 |
| === karimsye-food is now known as karimsye | ||
| 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:41 |
| seb128 | he's also hinting that upgrading from bionic doesn't pull that package in, which is worth checking | 22:42 |
| cyphermox | rbasak: nah, I can run the tests here later | 22:47 |
| cyphermox | mmkay | 22:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!