[00:23] <foo> Fixed.
[00:24] <foo> Trying to increase swap. Getting this: "swapoff: /swapfile: swapoff failed: Cannot allocate memory" -> I imagine this is because swap is being used and I need to clear it somehow?
[00:24] <foo> I suspect a reboot might fix this? 
[00:27] <foo> ah, had to stop docker, heh.
[06:11] <cpaelzer> good morning
[06:12] <utkarsh2102> cpaelzer: \o
[06:12] <cpaelzer> hi utkarsh2102
[07:02] <utkarsh2102> why is docker.service masked when installed in a container (LXD VM in this case)?
[07:28] <cpaelzer> utkarsh2102: for a start LXD-VM isn't a container or it isn't a -VM - so which one is it?
[07:28] <cpaelzer> if it is a normal container then maybe to avoid container stacking in some incompatible cases (just guessing) ?
[07:31] <cpaelzer> utkarsh2102: the d/rules says there is a debconf defining all that
[07:32] <cpaelzer> utkarsh2102: they use --no-start --no-stop-on-upgrade to not have devhelper unmask/start/enable it and refer to debconf
[07:33] <cpaelzer> utkarsh2102: https://git.launchpad.net/ubuntu/+source/docker.io/tree/debian/rules#n104
[07:34] <cpaelzer> utkarsh2102: but with all default in jammy for me it ends up after install as
[07:34] <cpaelzer> Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
[07:34] <cpaelzer> is it different for you utkarsh2102?
[08:22] <utkarsh2102> cpaelzer: ah, thanks, sorry for the mixup with LXD VM and an LXD container.
[08:23] <utkarsh2102> cpaelzer: in an LXD VM (Bionic), when I install docker, the docker.service is masked. But when I unmask and start, it works just fine.
[08:23] <utkarsh2102> so I was wondering why do we mask in the first place? or if we don't, then I'll check what's up here.
[08:24] <utkarsh2102> simultaneously, in an LXD container (Jammy), when I install docker, the docker.service is active and running.
[08:24] <utkarsh2102> which is weird and interesting! :)
[08:29] <cpaelzer> utkarsh2102: as I said for me it was unmasked and started right away
[09:14] <utkarsh2102> ok, thanks!
[11:56] <athos> good morning!
[11:57] <utkarsh2102> hello! \o
[12:00] <cpaelzer> hi athos
[12:28] <paride> utkarsh2102, hey! you run Jammy on your laptop, do I remember correctly?
[12:46] <athos> paride: I do run jammy here as well :)
[12:47]  * athos recalls the time spent with initramfs boot issues; goes grab coffee :|
[12:47] <paride> athos, can you please do a sanity check for me? What does `systemctl --user is-active graphical-session.target` return for you?
[12:50] <athos> paride: inactive
[12:56] <paride> athos, thanks
[13:15] <utkarsh2102> paride: I run Focal! :D
[13:46] <bbezak> fnordahl: Hello. Is it possible to bump OVN to 21.09.1 in ubuntu cloud-archive for openstack xena release? https://openstack-ci-reports.ubuntu.com/reports/cloud-archive/xena_versions.html - I've seen some bug fixes around loadbalancers there
[14:21] <fnordahl> bbezak: Thank you for reaching out. Updating Ubuntu Impish and subsequently the Xena UCA pocket with a new OVN point release is definitively something we should consider. I have created a SRU bug: https://bugs.launchpad.net/cloud-archive/+bug/1960827 and I'll bring in up when planning short term work items.
[14:22] <bbezak> lovely thank you! fnordahl:
[14:23] <bbezak> fnordahl: thank you! :)
[16:23] <bryceh> followup from standup - if you're seeing frequent Firefox crashes (I get them ~daily), if you navigate in the browser to about:crashes, it brings up a page where you can submit the crash reports, and it will helpfully suggest possibly related bug reports
[16:24] <bryceh> mine appears to be https://bugzilla.mozilla.org/show_bug.cgi?id=1743386, which seems specific to radeon and potentially fixed with a pending libx11 sru (LP: #1782984)
[16:56] <bryceh> @rbasak, regarding +1 maintenance tips and tricks, I make reference of prior +1 maintenance reports posted to ubuntu-devel@ to get a sense of history for a package, and I try to file update-excuse tagged bugs for anything I look at but don't fix, in order to at least help with ongoing status tracking
[16:59] <rbasak> ack, thanks
[17:24] <ahasenack> TIL about:crashes
[17:37] <utkarsh2102> me, too
[17:58] <ahasenack> athos: was there any reply in the debian bug about rm_conffile for the local apparmor profile?
[18:13] <athos> ahasenack: not really
[18:13] <ahasenack> athos: I was just checking the version listed in that rm_conffile call
[18:13] <ahasenack> it's 1:9.11.4+dfsg-1~
[18:13] <ahasenack> that still covers bionic iiuc
[18:13] <ahasenack> 1:9.11.3+dfsg-1ubuntu1.16    | bionic-updates
[18:14] <ahasenack> did you test the upgrade with bionic as the base?
[18:24] <athos> ahasenack: not really. Since the bionic package (1:9.11.3+dfsg-1ubuntu1.16) already uses dh_apparmor, it should behave as the recent ones (no-op from the rm_conffile snippet since the local profile does not belong to the package). The Xenial one is the one which would cause issues, as I described in my last comment
[18:24] <athos> dh-apparmor was introduced in 1:9.11.2+dfsg-5 in Debian
[19:28] <ahasenack> athos:  ensure_package_owns_file "$PACKAGE" "$CONFFILE" || return 0
[19:28] <ahasenack> indeed