[00:52] <mup> PR snapcraft#3694 opened: autotools v1 plugin: fix fatal crash when running autogen.sh or bootstrap <Created by mtmiller> <https://github.com/snapcore/snapcraft/pull/3694>
[06:14] <mborzecki> morning
[06:28] <mup> PR snapd#11688 closed: tests/nested/manual/core20-early-config: disable netplan checks <Simple 😃> <Run nested> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11688>
[06:47] <amurray> 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] <zyga[m]> As a means for "advice"
[06:49] <zyga[m]> I think it is not very useful bit IIRC that was the original rationale
[06:50] <amurray> 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] <amurray> 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] <zyga[m]> I think it was not for the system but instead for the developer
[06:53] <zyga[m]> That decision predates portals
[06:53] <zyga[m]> We also had an idea for some sort of classic interfaces so, whatever that might be, if my memory serves me right
[06:54] <zyga[m]> Perhaps there is more in the git history
[06:54] <zyga[m]> I think it would be good to unconfine all classic snaps as that goes against portal detection logic
[07:00] <amurray> zyga[m]: cool - thanks for your help mate, I think this may be a worthwhile change - hope all is well
[07:00] <zyga[m]> Yeah I think the chance for regression is low
[07:01] <zyga[m]> What was the original motivation unconfining emacs? Is it the cost of the audit messages?
[07:02] <amurray> 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] <amurray> so the easiest fix for this is to have emacs itself run unconfined and then anything it spawns will also be unconfined
[07:04] <zyga[m]> Oh that is even more the reason to change this
[07:04] <zyga[m]> I think this will also help vocode
[07:05] <amurray> yep - basically any dev tool which launches other things, esp desktop apps, would benefit from this
[07:05] <zyga[m]> Indeed
[07:06] <zyga[m]> I would love if apps switched to some xdg app launcher portal but that will take a decade to address
[07:07] <zyga[m]> Thank you for looking into this Alex
[07:07] <pstolowski> morning
[07:17] <amurray> no worries zyga[m]  - thanks again for your guidance :)
[07:22] <zyga[m]> :-)
[07:23] <pstolowski> mborzecki: hey, can you take a look at https://github.com/snapcore/snapd/pull/11644 ?
[07:23] <mup> PR #11644: image, store: move ToolingStore to store/tooling package <Created by stolowski> <https://github.com/snapcore/snapd/pull/11644>
[07:23] <mup> PR snapd#11666 closed: i/b/custom_device: fix generation of udev rules <Needs Samuele review> <Created by mardy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11666>
[07:28] <mup> PR snapd#11654 closed: seed: return all essential snaps found if no types are given to LoadEssentialMeta <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/11654>
[07:54] <mup> PR snapd#11691 closed: HACKING: update info for snapcraft remote build <Simple 😃> <Skip spread> <Created by mardy> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11691>
[07:54] <mup> PR snapd#11692 opened: gadget: drop unused code in unit tests <Simple 😃> <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/11692>
[08:04] <mup> PR snapd#11644 closed: image, store: move ToolingStore to store/tooling package <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/11644>
[08:07] <bdmurray> What is the status bug 1969162?
[08:07] <mup> Bug #1969162: bad interaction between snapd and update-notifier when snapd package is being upgraded <snapd (Ubuntu):In Progress by mardy> <update-notifier (Ubuntu):Confirmed> <https://launchpad.net/bugs/1969162>
[08:08] <bdmurray> If that isn't fixed I think we'd want to delay release upgrades to Jammy.
[08:12] <mardy> bdmurray: thanks for the heads up, I pinged Samuele to review it
[08:15] <mardy> 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] <mup> PR snapd#11692 closed: gadget: drop unused code in unit tests <Simple 😃> <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/11692>
[12:10] <mup> PR snapd#11693 opened: tests: add invariant check for leftover cgroup scopes <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/11693>
[12:52] <jdstrand_> 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
[12:55] <jdstrand> 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> 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] <jdstrand> zyga[m]: ^
[12:58] <jdstrand> s/If you did/if you did remove it/
[13:13] <jdstrand> 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] <jdstrand> s/will/well/
[14:20] <mup> PR snapd#11694 opened: i/apparmor: remove leftover comment <Simple 😃> <Skip spread> <Created by mardy> <https://github.com/snapcore/snapd/pull/11694>
[14:41] <mup> PR snapd#11695 opened: libsnap-confine-private: show proper error when aa_change_onexec() fails <Simple 😃> <Created by mardy> <https://github.com/snapcore/snapd/pull/11695>
[15:06] <mup> PR snapd#11694 closed: i/apparmor: remove leftover comment <Simple 😃> <Skip spread> <Created by mardy> <Merged by MiguelPires> <https://github.com/snapcore/snapd/pull/11694>
[15:13] <mup> PR snapcraft#3692 closed: legacy storeapi: use craft-store <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3692>
[16:16] <mup> PR snapd#11696 opened: tests: test fresh install of core22-based snap <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/11696>
[16:23] <mup> PR snapcraft#3693 closed: projects: adoptable fields are optional if adopt-info used <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3693>
[19:12] <mup> PR snapd#11697 opened: seed: support parallelism when loading/verifying snap metadata <Preseeding 🍞> <Created by pedronis> <https://github.com/snapcore/snapd/pull/11697>
[21:19] <mup> PR snapcraft#3695 opened: meta: add appstream metadata extractor <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/3695>


[01:56] <mikefeign> Anyone can confirm we Ubuntu on Raspberry Pi has a proper hardware acceleration for video (VC4)
[15:41] <rrr> after a rather intensive upgrade, some of my network devices are not activating and error with a state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') error. I believe I encountered and resolved this once before, but don't know what I tried.