[00:52] PR snapcraft#3694 opened: autotools v1 plugin: fix fatal crash when running autogen.sh or bootstrap [06:14] morning [06:28] PR snapd#11688 closed: tests/nested/manual/core20-early-config: disable netplan checks [06:47] jdstrand_ zyga[m]: hey am wondering if either of you could give any background as to why we run classic snaps in complain mode? why not just run them unconfined? [06:48] As a means for "advice" [06:49] I think it is not very useful bit IIRC that was the original rationale [06:50] you mean to advise the user/system that the process is a snap etc? ie to label it as such? I ask since I am hitting a weird issue with the emacs snap https://github.com/alexmurray/emacs-snap/issues/36 [06:50] I am planning to "fix" this by making the emacs snap unconfine itself but I am wondering if it would be worth doing this for all classic snaps? [06:53] I think it was not for the system but instead for the developer [06:53] That decision predates portals [06:53] We also had an idea for some sort of classic interfaces so, whatever that might be, if my memory serves me right [06:54] Perhaps there is more in the git history [06:54] I think it would be good to unconfine all classic snaps as that goes against portal detection logic [07:00] zyga[m]: cool - thanks for your help mate, I think this may be a worthwhile change - hope all is well [07:00] Yeah I think the chance for regression is low [07:01] What was the original motivation unconfining emacs? Is it the cost of the audit messages? [07:02] no, it seems that if emacs spawns say firefox, the firefox window gets associated with the emacs icon on the dock - and this all comes down to firefox then running under the "snap.emacs.emacs (complain)" profile [07:03] so the easiest fix for this is to have emacs itself run unconfined and then anything it spawns will also be unconfined [07:04] Oh that is even more the reason to change this [07:04] I think this will also help vocode [07:05] yep - basically any dev tool which launches other things, esp desktop apps, would benefit from this [07:05] Indeed [07:06] I would love if apps switched to some xdg app launcher portal but that will take a decade to address [07:07] Thank you for looking into this Alex [07:07] morning [07:17] no worries zyga[m] - thanks again for your guidance :) [07:22] :-) [07:23] mborzecki: hey, can you take a look at https://github.com/snapcore/snapd/pull/11644 ? [07:23] PR #11644: image, store: move ToolingStore to store/tooling package [07:23] PR snapd#11666 closed: i/b/custom_device: fix generation of udev rules [07:28] PR snapd#11654 closed: seed: return all essential snaps found if no types are given to LoadEssentialMeta [07:54] PR snapd#11691 closed: HACKING: update info for snapcraft remote build [07:54] PR snapd#11692 opened: gadget: drop unused code in unit tests [08:04] PR snapd#11644 closed: image, store: move ToolingStore to store/tooling package [08:07] What is the status bug 1969162? [08:07] Bug #1969162: bad interaction between snapd and update-notifier when snapd package is being upgraded

[08:08] If that isn't fixed I think we'd want to delay release upgrades to Jammy. [08:12] bdmurray: thanks for the heads up, I pinged Samuele to review it [08:15] bdmurray: maybe you can help me with this: do you know if it's possible to test this without actually running a downgrade followed by an upgrade? Maybe there's a way to trigger the dh_systemd_start behaviour manually? [08:44] PR snapd#11692 closed: gadget: drop unused code in unit tests === alan_g_ is now known as alan_g === bandali_ is now known as bandali [12:10] PR snapd#11693 opened: tests: add invariant check for leftover cgroup scopes [12:52] amurray: hey, I recall it was so that they had a label and thus could be tracked by the system like other snaps. It also affords putting guardrails on classic snaps ("I know you could break out of this, but you can do everything except ...", though we aren't taking advantage of that === jdstrand_ is now known as jdstrand [12:55] jdstrand: when classic snaps were introduced, many concepts were not yet in place and we felt that the apparmor label could help tie things together and help with consistency. new concepts like cgroups and systemd scopes were introduced into snapd that can be and are used for tracking snaps. iirc, we aren't taking advantage of the apparmor label with classic snaps [12:57] jdstrand: (eg, snapd isn't using it for lifecycle management or anything). It was thought early on that it would use it. It's possible the profile could be removed, but someone would have to verify we aren't using it for anything. If you did, you'd lose the ability to add guardrails. [12:57] zyga[m]: ^ [12:58] s/If you did/if you did remove it/ [13:13] do note that the exec rules use pix, so the system is keeping tracking of everything the snap is doing (will unless the classic snap exec something that triggered the 'p' transition and that new profile has a Ux/ux rule [13:16] s/will/well/ [14:20] PR snapd#11694 opened: i/apparmor: remove leftover comment [14:41] PR snapd#11695 opened: libsnap-confine-private: show proper error when aa_change_onexec() fails [15:06] PR snapd#11694 closed: i/apparmor: remove leftover comment [15:13] PR snapcraft#3692 closed: legacy storeapi: use craft-store === popey0 is now known as popey [16:16] PR snapd#11696 opened: tests: test fresh install of core22-based snap [16:23] PR snapcraft#3693 closed: projects: adoptable fields are optional if adopt-info used [19:12] PR snapd#11697 opened: seed: support parallelism when loading/verifying snap metadata [21:19] PR snapcraft#3695 opened: meta: add appstream metadata extractor