[00:23] Fixed. [00:24] 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] I suspect a reboot might fix this? [00:27] ah, had to stop docker, heh. === peninsularshabbz is now known as shabbz [06:11] good morning [06:12] cpaelzer: \o [06:12] hi utkarsh2102 [07:02] why is docker.service masked when installed in a container (LXD VM in this case)? [07:28] utkarsh2102: for a start LXD-VM isn't a container or it isn't a -VM - so which one is it? [07:28] if it is a normal container then maybe to avoid container stacking in some incompatible cases (just guessing) ? === JanC_ is now known as JanC [07:31] utkarsh2102: the d/rules says there is a debconf defining all that [07:32] utkarsh2102: they use --no-start --no-stop-on-upgrade to not have devhelper unmask/start/enable it and refer to debconf [07:33] utkarsh2102: https://git.launchpad.net/ubuntu/+source/docker.io/tree/debian/rules#n104 [07:34] utkarsh2102: but with all default in jammy for me it ends up after install as [07:34] Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled) [07:34] is it different for you utkarsh2102? [08:22] cpaelzer: ah, thanks, sorry for the mixup with LXD VM and an LXD container. === peninsularshabbz is now known as shabbz === shabbz is now known as peninsularshabbz [08:23] 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] 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] simultaneously, in an LXD container (Jammy), when I install docker, the docker.service is active and running. [08:24] which is weird and interesting! :) [08:29] utkarsh2102: as I said for me it was unmasked and started right away [09:14] ok, thanks! === person_x is now known as personx_ [11:56] good morning! [11:57] hello! \o [12:00] hi athos [12:28] utkarsh2102, hey! you run Jammy on your laptop, do I remember correctly? [12:46] paride: I do run jammy here as well :) [12:47] * athos recalls the time spent with initramfs boot issues; goes grab coffee :| [12:47] athos, can you please do a sanity check for me? What does `systemctl --user is-active graphical-session.target` return for you? [12:50] paride: inactive [12:56] athos, thanks [13:15] paride: I run Focal! :D [13:46] 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 === lotuspsychje_ is now known as lotuspsychje [14:21] 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:21] Launchpad bug 1960827 in ovn (Ubuntu Impish) "[SRU] OVN 21.09.1 point release" [Undecided, New] [14:22] lovely thank you! fnordahl: [14:23] fnordahl: thank you! :) === genii-core is now known as genii [16:23] 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] 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:24] Launchpad bug 1782984 in libx11 (Ubuntu Focal) "Assertion `!xcb_xlib_threads_sequence_lost' failed with multiple applications" [High, Fix Committed] https://launchpad.net/bugs/1782984 [16:24] Mozilla bug 1743386 in Core "Crash in [@ mozilla::ScopedXErrorHandler::ErrorHandler]" [S2, New] [16:56] @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] ack, thanks [17:24] TIL about:crashes [17:37] me, too [17:58] athos: was there any reply in the debian bug about rm_conffile for the local apparmor profile? [18:13] ahasenack: not really [18:13] athos: I was just checking the version listed in that rm_conffile call [18:13] it's 1:9.11.4+dfsg-1~ [18:13] that still covers bionic iiuc [18:13] 1:9.11.3+dfsg-1ubuntu1.16 | bionic-updates [18:14] did you test the upgrade with bionic as the base? [18:24] 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] dh-apparmor was introduced in 1:9.11.2+dfsg-5 in Debian [19:28] athos: ensure_package_owns_file "$PACKAGE" "$CONFFILE" || return 0 [19:28] indeed === ThomasSjgren[m] is now known as konstruktoid[m]