[00:48] <jdstrand> 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] <jdstrand> well, the solution to the problem is tractable. anyhoo. goodnight!
[00:51] <joedborg> Thanks jdstrand! Have a good one
[07:18] <mup> PR snapd#7439 closed: packaging: remove obsolete usr.lib.snapd.snap-confine in postinst <Bug> <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7439>
[07:18] <mup> PR snapd#7478 closed: snapstate: increase settleTimeout in TestRemodelSwitchToDifferentKernel <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7478>
[07:50] <mup> PR snapd#7473 closed: sanity: sanity check cgroup probing <Simple 😃> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7473>
[07:56] <mborzecki> 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] <pstolowski> mborzecki: thanks!
[09:02] <zyga> dot-tobias: hello
[09:02] <zyga> are you around?
[09:02] <dot-tobias> zyga: hi, yes I am
[09:02] <zyga> dot-tobias: about https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/12
[09:02] <zyga> I'm trying to expand my test to reproduce this issue
[09:03] <zyga> when it occurred, was the application running?
[09:03] <zyga> or alternatively, was there a service that was running?
[09:04] <dot-tobias> 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] <zyga> dot-tobias: daemon written in which language?
[09:04] <zyga>  I'll try to do the same
[09:05] <dot-tobias> 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] <zyga> ok
[09:06] <zyga> I'll try with a simple shell daemon
[09:06] <roadmr> 😷
[09:07] <dot-tobias> zyga: Ok, I'll test if removing the daemon stanza (i.e. making it a regular app) produces different results
[09:07] <roadmr> jdstrand: new review-tools is now in production 👍
[09:08] <zyga> dot-tobias: that doesn't reproduce it for me
[09:08] <zyga> dot-tobias: my attempt is on https://github.com/snapcore/snapd/pull/7486
[09:08] <mup> PR #7486: tests: add regression test for lp: #1844496 <Created by zyga> <https://github.com/snapcore/snapd/pull/7486>
[09:09] <zyga> dot-tobias: this reliably passes for me
[09:09] <zyga> dot-tobias: so there must be something missing still
[09:12] <dot-tobias> 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] <zyga> I can try
[09:13] <dot-tobias> 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] <zyga> no, that's not the case
[09:13] <zyga> the variable is only meaningful to snapcraft
[09:13] <zyga> snapd doesn't expand it
[09:13] <zyga> it is expanded in snap.yaml
[09:13] <zyga> if you use snapcraft it gets expanded but I only care about the layer below
[09:14] <dot-tobias> Ah, just noticed that it's snap.yaml and not snapcraft.yaml 😊 My bad
[09:14] <zyga> no worries
[09:14] <dot-tobias> zyga: Will run some more tests and get back to you
[09:16] <zyga> dot-tobias: I just reproduced it
[09:16] <zyga> dot-tobias: it was the extra layout entries
[09:16] <zyga> I will investigate now, you can wait until I get some results
[09:20] <jamesh> 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] <mup> PR snapd#7487 opened: interfaces/udev: account for cgroup version when reporting supported features <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7487>
[09:34] <jdstrand> 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] <mup> PR snapcraft#2727 opened: storeapi: use the channels attribute in push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2727>
[09:35] <jamesh> jdstrand: okay.  This is for the fwupd interface changes I was working on: https://github.com/snapcore/snapd/pull/7454
[09:35] <mup> PR #7454: interfaces: extend the fwupd slot to be implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7454>
[09:35] <zyga> dot-tobias: I managed to reduce the case further, it should be easier to understand
[09:36] <jamesh> jdstrand: the spread tests I added end up trying to activate fwupd (it isn't initially running), so fail on Ubuntu backends
[09:37] <jdstrand> jamesh: unfortunately, we need SRUs for whatever ships those service files :\
[09:37] <jdstrand> jamesh: I mean, you could sed them for the test, but... ;)
[09:38] <jamesh> 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] <jamesh> and then look at the SRUs later
[09:38] <jamesh> jdstrand: thanks.
[09:39] <dot-tobias> 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] <zyga> I have a hunch I know what is the problem now
[09:39] <mup> PR snapd#7488 opened: docs: Update README.md <Created by degville> <https://github.com/snapcore/snapd/pull/7488>
[09:39] <jdstrand> jamesh: np
[09:47] <ijohnson> zyga: did you want to look at https://github.com/snapcore/snapd/pull/7409 again or can we merge it?
[09:47] <mup> PR #7409: interfaces/wayland: allow a confined server running in a user session to work with Qt, GTK3 & SDL2 clients <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7409>
[09:49] <jdstrand> 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] <jdstrand> (that's what we recommended before)
[09:50] <jamesh> jdstrand: perhaps an AppArmor rule specifically covering D-Bus activation of a name would make sense
[09:50] <jamesh> although that would be a multi-year project to roll out :-(
[09:51] <jdstrand> I think that was something tyhicks also suggested when we upstreamed
[09:54] <dot-tobias> 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] <jdstrand> dot-tobias: it can be done per snap(s) or globally
[09:57] <jdstrand> dot-tobias: it would apply to all revisions of your snaps
[10:05] <dot-tobias> jdstrand: Great, thanks!
[10:09] <mup> PR snapd#7489 opened: store, ..., client: add a "website" field <Created by chipaca> <https://github.com/snapcore/snapd/pull/7489>
[10:09] <zyga> dot-tobias: I update the thread as I go if you are curious
[10:09] <zyga> ijohnson: in a moment
[10:29] <dot-tobias> zyga: *grabs popcorn*
[11:51] <mup> PR snapd#7490 opened: interfaces/shell-support: support confined snaps launching other snaps <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7490>
[14:53] <mup> PR snapcraft#2728 opened: Base bare <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2728>
[19:39] <joedborg> zyga: are you around?
[22:08] <zyga> joedborg: yes but heading to bed
[22:09] <joedborg> zyga: no worries!