[00:48] joedborg: ok, I responded to zyga's bug and your email. I'm crashing now :) do let me know in the email if you need more immediately, but the problem is totally tractable [00:48] well, the solution to the problem is tractable. anyhoo. goodnight! [00:51] Thanks jdstrand! Have a good one [07:18] PR snapd#7439 closed: packaging: remove obsolete usr.lib.snapd.snap-confine in postinst [07:18] PR snapd#7478 closed: snapstate: increase settleTimeout in TestRemodelSwitchToDifferentKernel [07:50] PR snapd#7473 closed: sanity: sanity check cgroup probing [07:56] pstolowski: the simple one https://paste.ubuntu.com/p/z3kmnrq22b/ one i use for setting up fedora https://paste.ubuntu.com/p/gJgf4ms36c/ [07:57] mborzecki: thanks! [09:02] dot-tobias: hello [09:02] are you around? [09:02] zyga: hi, yes I am [09:02] dot-tobias: about https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/12 [09:02] I'm trying to expand my test to reproduce this issue [09:03] when it occurred, was the application running? [09:03] or alternatively, was there a service that was running? [09:04] zyga: My test app is just a daemon running “pwd”, so I guess yes, but I can't imagine that this affects file handles [09:04] dot-tobias: daemon written in which language? [09:04] I'll try to do the same [09:05] zyga: See https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/13?u=tobias → FYI: This refers to the *test* snap you asked me for, which does not contain any real code. The issue first came up with a kiosk snap running a daemonized WPE Webkit launcher (cog) [09:05] ok [09:06] I'll try with a simple shell daemon [09:06] 😷 [09:07] zyga: Ok, I'll test if removing the daemon stanza (i.e. making it a regular app) produces different results [09:07] jdstrand: new review-tools is now in production 👍 [09:08] dot-tobias: that doesn't reproduce it for me [09:08] dot-tobias: my attempt is on https://github.com/snapcore/snapd/pull/7486 [09:08] PR #7486: tests: add regression test for lp: #1844496 [09:09] dot-tobias: this reliably passes for me [09:09] dot-tobias: so there must be something missing still [09:12] zyga: Hm. I tested all the layouts iteratively and none came up with this error *except* the one I thought was the culprit, so I put that front and center. But the snapcraft.yaml (https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/13?u=tobias) contains all of them … maybe copy all of those over to your test because I made a mistake during tests and it's a combination? [09:12] I can try [09:13] zyga: Ah, also your test has a fixed layout /usr/lib/x86_64 … whereas I'm using $SNAPCRAFT_ARCH_TRIPLET. Should produce the same result, but there's a difference too [09:13] no, that's not the case [09:13] the variable is only meaningful to snapcraft [09:13] snapd doesn't expand it [09:13] it is expanded in snap.yaml [09:13] if you use snapcraft it gets expanded but I only care about the layer below [09:14] Ah, just noticed that it's snap.yaml and not snapcraft.yaml 😊 My bad [09:14] no worries [09:14] zyga: Will run some more tests and get back to you [09:16] dot-tobias: I just reproduced it [09:16] dot-tobias: it was the extra layout entries [09:16] I will investigate now, you can wait until I get some results [09:20] jdstrand: do you know if there are any ways to allow D-Bus activation for services without an AssumedAppArmorLabel key in their service activation file? [09:23] PR snapd#7487 opened: interfaces/udev: account for cgroup version when reporting supported features [09:34] jamesh: for a confined application to talk to it, no. have I mentioned how much I hate this dbus upstream misfeature (we argued against it) [09:34] PR snapcraft#2727 opened: storeapi: use the channels attribute in push [09:35] jdstrand: okay. This is for the fwupd interface changes I was working on: https://github.com/snapcore/snapd/pull/7454 [09:35] PR #7454: interfaces: extend the fwupd slot to be implicit on classic [09:35] dot-tobias: I managed to reduce the case further, it should be easier to understand [09:36] jdstrand: the spread tests I added end up trying to activate fwupd (it isn't initially running), so fail on Ubuntu backends [09:37] jamesh: unfortunately, we need SRUs for whatever ships those service files :\ [09:37] jamesh: I mean, you could sed them for the test, but... ;) [09:38] jdstrand: fair enough. I might adjust the spread test for now to manually start the service first, with a comment about why it is doing that. [09:38] and then look at the SRUs later [09:38] jdstrand: thanks. [09:39] zyga: Great, excited to see what you dig up 😊 and a reminder for me that I wanted to check out spread for testing … [09:39] I have a hunch I know what is the problem now [09:39] PR snapd#7488 opened: docs: Update README.md [09:39] jamesh: np [09:47] zyga: did you want to look at https://github.com/snapcore/snapd/pull/7409 again or can we merge it? [09:47] PR #7409: interfaces/wayland: allow a confined server running in a user session to work with Qt, GTK3 & SDL2 clients [09:49] jamesh: really, AssumedAppArmorLabel should default to unconfined imo. I mean, I know why they didn't do it that way, but the default deny is onerous (you would always need corresponding rules for the communication that are default deny...) [09:49] (that's what we recommended before) [09:50] jdstrand: perhaps an AppArmor rule specifically covering D-Bus activation of a name would make sense [09:50] although that would be a multi-year project to roll out :-( [09:51] I think that was something tyhicks also suggested when we upstreamed [09:54] jdstrand: Just to confirm: The only way to get a DBus interface between two of my snaps (same publisher) auto-connected is through a store assertion *if* my application in the forum is granted – correct? Would that also apply to new revisions of already installed snaps – i.e. would existing users benefit from auto-connection after a refresh? [09:55] dot-tobias: it can be done per snap(s) or globally [09:57] dot-tobias: it would apply to all revisions of your snaps [10:05] jdstrand: Great, thanks! [10:09] PR snapd#7489 opened: store, ..., client: add a "website" field [10:09] dot-tobias: I update the thread as I go if you are curious [10:09] ijohnson: in a moment [10:29] zyga: *grabs popcorn* [11:51] PR snapd#7490 opened: interfaces/shell-support: support confined snaps launching other snaps [14:53] PR snapcraft#2728 opened: Base bare [19:39] zyga: are you around? === msalvatore_ is now known as msalvatore [22:08] joedborg: yes but heading to bed [22:09] zyga: no worries!