=== mvo_ is now known as mvo
[09:05] <mantas-baltix> Hi, could someone nominate this bug for fixing in LTS releases - bug #1644996 ?
[09:05] <ubottu> bug 1644996 in logrotate (Ubuntu) "logrotate config uses syslog group" [Undecided,Fix released] https://launchpad.net/bugs/1644996
[09:06] <seb128> mantas-baltix, you can probably nominate it so it's on the list to review
[09:07] <mantas-baltix> seb128: I don't have enough rights - link "nominate" dissapears when I login into launchpad.net
[09:08] <mantas-baltix> seb128: my launchpad login name is mantas
[09:09] <seb128> I meant propose for nomination
[09:09] <seb128> but yeah, accepting nominates require special team permission
[09:15] <mantas-baltix> seb128: how to propose for nomination?
[09:18] <seb128> mantas-baltix, I though that people had an action bellow the bug table for that but I can't confirm since my account has the acl to do the nomination ... anyway, tag it rls-bb-incoming then then it's on the rls bugs review list
[09:18] <seb128> mantas-baltix, I'm not nominating it directly because wtihout an assignee it's not really useful to do that
[09:18] <seb128> or ask directly x_nox if he wants to handle the SRU since he did the fix in disco?
[09:24] <mantas-baltix> xnox: it seems you fixed bug #1644996 in development release, could you backport to LTS ?
[09:24] <ubottu> bug 1644996 in logrotate (Ubuntu) "logrotate config uses syslog group" [Undecided,Fix released] https://launchpad.net/bugs/1644996
[09:28] <mantas-baltix> seb128: what about bug #1781746 and bug #1811447 ? One simple 3 lines patch from Debian and Ubuntu users with SSD will be hapier ;)
[09:28] <ubottu> bug 1781746 in Default settings and artwork for Baltix OS "[SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap" [High,Confirmed] https://launchpad.net/bugs/1781746
[09:28] <ubottu> bug 1811447 in initramfs-tools (Ubuntu) "update-initramfs generates wrong RESUME if no swap + zram" [Undecided,Confirmed] https://launchpad.net/bugs/1811447
[09:32] <seb128> mantas-baltix, that sounds like something foundations would know better than me, anyway as mentioned before, the proper process to have those reviexwed is to rls-<nn>-incoming tag them
[09:32] <mantas-baltix> tag rls-bb-incoming in bug 1781746 was added long time ago, but no reaction from Ubuntu developers :(
[09:32] <ubottu> bug 1781746 in Default settings and artwork for Baltix OS "[SRU] Slow startup with zram-config installed (/dev/zram0) or encrypted swap" [High,Confirmed] https://launchpad.net/bugs/1781746
[09:34] <seb128> bdmurray, ^ do you know why that one is not showing up on the report?
[09:35] <seb128> mantas-baltix, thx for pointing that out, it's not being picked up, either I'm overlooking something or there is a bug in the tool generating the report
[12:02] <mantas-baltix> xnox: thanks
=== ricab is now known as ricab|lunch
[13:30] <cjwatson> infinity: Would you like to state an opinion on https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/361825, since your name was mentioned in a review?
=== ricab|lunch is now known as ricab
=== ricab is now known as ricab|brb
=== ricab|brb is now known as ricab
[15:06] <bdmurray> seb128: I see it on the report for rls-bb-incoming
[15:07] <seb128> bdmurray, hey, right it's listed now, I wonder if that was a transient issue
[15:07] <seb128> bdmurray, also how often does foundations review that list? seems several of those bugs have been sitting there for a while
[15:08] <bdmurray> seb128: the -bb one we review less often but did look at a couple of weeks ago for the point release
[15:09] <seb128> bdmurray, I guess you just did skip over the ones which you didn't want to consider but didn't try to triage those/comment/whatever?
[15:12] <bdmurray> seb128: ah, I misspoke / typed. We looked at rls-bb-tracking not rls-bb-incoming, I'll have a look at those this week. Also there are hundreds so its a lot to triage.
[15:17] <seb128> bdmurray, only 32 for foundations :) and yeah, that's what you get for not looking at that list regularly :p
[15:18] <seb128> bdmurray, we review our rls<nn>-incoming list every week in our team meeting for desktop since that's how issues are supposed to be escalated etc
[15:59] <rbasak> If I lxc launch ubuntu-daily:disco and then upgrade it up to proposed, then after a reboot /etc/resolv.conf is missing and therefore an apt update fails. This is causing autopkgtest -U --apt-pocket=proposed to fail.
[16:05] <rbasak> Actually it doesn't disappear; it's the symlink target(../run/systemd/resolve/stub-resolv.conf) that doesn't seem to get recreated after reboot.
[16:06] <rbasak>   Process: 290 ExecStart=/lib/systemd/systemd-resolved (code=exited, status=226/NAMESPACE)
[16:14] <TJ-> rbasak: could it be related to the systemd unified cgroup hierarchy? I'm not familiar with what may have changed in that area for 19.04 though
[16:16] <rbasak> I pinned systemd when upgrading to proposed and the problem doesn't reproduce.
[16:16] <rbasak> So I'm pretty sure it's a regression in systemd from 239-7ubuntu15 to 240-5ubuntu1
[16:18] <rbasak> Yes unholding and upgrading to systemd 240-5ubuntu1 breaks it.
[16:20] <TJ-> rbasak: related to systemd 5f086dc7db possibly?
[16:20] <TJ-> "cgroup: Imply systemd.unified_cgroup_hierarchy=1 on cgroup_no_v1=all"
[16:55] <rbasak> I filed bug 1813622
[16:55] <ubottu> bug 1813622 in systemd (Ubuntu) "systemd-resolved fails to start in a container" [Critical,New] https://launchpad.net/bugs/1813622
[16:56] <rbasak> xnox: FYI ^
[17:35] <xnox> rbasak, yeah, intersting
[17:35] <xnox> rbasak, i wonder if it's been crazy since v239 or only just regressed in the last upload.
[17:35] <xnox> it would make more sense if this is a regression since the release pocket (v239->v240) jump. Rather than the relatively minor 240-2ubuntu2 -> 240-5ubuntu1 jump.
[17:36] <xnox> well, my lxd is busted
[17:36] <xnox> $ sudo lxc launch ubuntu-daily:disco
[17:36] <xnox> cannot read mount namespace identifier of pid 1: Permission denied
[17:38] <teward> rbasak: confirmed the same behavior, should I mark that as "Confirmed"?
[17:38] <xnox> rbasak, symlink target ../run/systemd/resolve/stub-resolv.conf is generated/written by systemd-resolved.... so if that unit fails, one will not have resolved today.
[17:39] <xnox> rbasak, teward - and i cannot run lxd at all.... what is your host os?
[17:39] <xnox> bionic?
[17:39] <teward> xnox: rbasak replicated with a Disco host, my host is Bionic
[17:39] <teward> running the LXD Snap
[17:40] <teward> same version of the snap too :P
[17:41] <teward> xnox: do you want me to mark the bug as confirmed in the interim?
[17:41] <xnox> probably
[17:41] <xnox> i want to know if my lxd is busted, or snapd is busted
[17:41] <xnox> $ lxc list
[17:41] <xnox> cannot read mount namespace identifier of pid 1: Permission denied
[17:41] <xnox> is very odd.
[17:42] <teward> that is very odd but my guess is the mount namespace would be snapd
[17:42] <teward> since IIRC doesn't that do the mounting?
[17:48] <xnox> all other snaps fail too.
[17:49] <xnox> so now i'm not sure how come it's broken for me. and got to run to volleyball
[17:50] <teward> xnox: sudo apt install --reinstall snapd?
[17:50] <teward> since it sounds more like a permissions problem than it does a systemd one
[17:50] <xnox> teward, heh worth it!
[17:50] <teward> (maybe)
[17:50] <teward> *watches xnox torch snapd on their system with his suggestion* oopsies :P
[17:51] <xnox> teward, it helped!
[17:52] <xnox> teward, you are genious! thanks =)
[17:52] <teward> wait that worked?  :P
[17:52] <xnox> yes!
[17:52] <teward> i was just totally throwing a random "Maybe this will work!" out there, but I guess it did work xD
[17:53] <teward> xnox: next task is to see whether a snapd regression happened :p
[17:53] <teward> because maybe snapd is horibly borken xD
[17:53] <teward> ... in this case my keyboard is but meh
[17:53] <xnox> still can't launch a container, but at least it is executing the lxc client
[17:54] <teward> xnox: maybe you have to uninstall and reinstall the snap too?
[17:54] <teward> sounds like your snapd got recursively screwed by something :P
[17:57] <xnox> ok, rbasak testing if v240-4ubuntu1 was busted too
[18:02] <teward> xnox: so you got it working again?  xD
[18:02] <teward> did you have to delete and install the snap again :p
[18:07] <rbasak> teward: thank you for reproducing!
[18:09] <xnox> rbasak, and yeah this is a v240 regression.
[18:09] <xnox> rbasak, lovely how most of our tests manage to pass on most architectures...... i really need an autopkgtest which pulls things from proposed, and ensures that lxd guests remain non-degraded.
[18:09] <xnox> systemd-networkd is also affected
[18:09] <xnox> fun
[18:10] <xnox> rbasak, do you have powers to RM systemd from disco-proposed for now?
[18:10] <rbasak> xnox: I do not, sorry.
[18:10] <xnox> doko, vorlon - if you are around please RM systemd from disco-proposed
[18:10] <xnox> it's batshit crazy =)
[18:10] <rbasak> Removal would be very helpful to me, thanks.
[18:10] <rbasak> (saves me working around)
[18:17] <vorlon> xnox: done
[18:17] <vorlon> xnox: should the version previously in -proposed be restored?
[18:58] <teward> vorlon: was it v240?  because I think xnox just confirmed this is a v240-wide regression
[18:58] <teward> (I don't have a say in removal / restoration I know but :P)
[19:01] <rbasak> !dmb-ping
[19:01] <ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
[19:02] <cyphermox> ye[
[23:42] <xnox> vorlon, do not restore anything, thanks =)