jdstrandjoedborg: 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 tractable00:48
jdstrandwell, the solution to the problem is tractable. anyhoo. goodnight!00:48
joedborgThanks jdstrand! Have a good one00:51
mupPR 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
mupPR snapd#7478 closed: snapstate: increase settleTimeout in TestRemodelSwitchToDifferentKernel <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7478>07:18
mupPR snapd#7473 closed: sanity: sanity check cgroup probing <Simple šŸ˜ƒ> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7473>07:50
mborzeckipstolowski: the simple one https://paste.ubuntu.com/p/z3kmnrq22b/ one i use for setting up fedora https://paste.ubuntu.com/p/gJgf4ms36c/07:56
pstolowskimborzecki: thanks!07:57
zygadot-tobias: hello09:02
zygaare you around?09:02
dot-tobiaszyga: hi, yes I am09:02
zygadot-tobias: about https://forum.snapcraft.io/t/snap-does-not-start-after-reboot/5750/1209:02
zygaI'm trying to expand my test to reproduce this issue09:02
zygawhen it occurred, was the application running?09:03
zygaor alternatively, was there a service that was running?09:03
dot-tobiaszyga: My test app is just a daemon running ā€œpwdā€, so I guess yes, but I can't imagine that this affects file handles09:04
zygadot-tobias: daemon written in which language?09:04
zyga I'll try to do the same09:04
dot-tobiaszyga: 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
zygaI'll try with a simple shell daemon09:06
dot-tobiaszyga: Ok, I'll test if removing the daemon stanza (i.e. making it a regular app) produces different results09:07
roadmrjdstrand: new review-tools is now in production šŸ‘09:07
zygadot-tobias: that doesn't reproduce it for me09:08
zygadot-tobias: my attempt is on https://github.com/snapcore/snapd/pull/748609:08
mupPR #7486: tests: add regression test for lp: #1844496 <Created by zyga> <https://github.com/snapcore/snapd/pull/7486>09:08
zygadot-tobias: this reliably passes for me09:09
zygadot-tobias: so there must be something missing still09:09
dot-tobiaszyga: 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
zygaI can try09:12
dot-tobiaszyga: 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 too09:13
zygano, that's not the case09:13
zygathe variable is only meaningful to snapcraft09:13
zygasnapd doesn't expand it09:13
zygait is expanded in snap.yaml09:13
zygaif you use snapcraft it gets expanded but I only care about the layer below09:13
dot-tobiasAh, just noticed that it's snap.yaml and not snapcraft.yaml šŸ˜Š My bad09:14
zygano worries09:14
dot-tobiaszyga: Will run some more tests and get back to you09:14
zygadot-tobias: I just reproduced it09:16
zygadot-tobias: it was the extra layout entries09:16
zygaI will investigate now, you can wait until I get some results09:16
jameshjdstrand: 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:20
mupPR snapd#7487 opened: interfaces/udev: account for cgroup version when reporting supported features <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7487>09:23
jdstrandjamesh: 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
mupPR snapcraft#2727 opened: storeapi: use the channels attribute in push <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2727>09:34
jameshjdstrand: okay.  This is for the fwupd interface changes I was working on: https://github.com/snapcore/snapd/pull/745409:35
mupPR #7454: interfaces: extend the fwupd slot to be implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7454>09:35
zygadot-tobias: I managed to reduce the case further, it should be easier to understand09:35
jameshjdstrand: the spread tests I added end up trying to activate fwupd (it isn't initially running), so fail on Ubuntu backends09:36
jdstrandjamesh: unfortunately, we need SRUs for whatever ships those service files :\09:37
jdstrandjamesh: I mean, you could sed them for the test, but... ;)09:37
jameshjdstrand: 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
jameshand then look at the SRUs later09:38
jameshjdstrand: thanks.09:38
dot-tobiaszyga: Great, excited to see what you dig up šŸ˜Š and a reminder for me that I wanted to check out spread for testing ā€¦09:39
zygaI have a hunch I know what is the problem now09:39
mupPR snapd#7488 opened: docs: Update README.md <Created by degville> <https://github.com/snapcore/snapd/pull/7488>09:39
jdstrandjamesh: np09:39
ijohnsonzyga: did you want to look at https://github.com/snapcore/snapd/pull/7409 again or can we merge it?09:47
mupPR #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:47
jdstrandjamesh: 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:49
jameshjdstrand: perhaps an AppArmor rule specifically covering D-Bus activation of a name would make sense09:50
jameshalthough that would be a multi-year project to roll out :-(09:50
jdstrandI think that was something tyhicks also suggested when we upstreamed09:51
dot-tobiasjdstrand: 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:54
jdstranddot-tobias: it can be done per snap(s) or globally09:55
jdstranddot-tobias: it would apply to all revisions of your snaps09:57
dot-tobiasjdstrand: Great, thanks!10:05
mupPR snapd#7489 opened: store, ..., client: add a "website" field <Created by chipaca> <https://github.com/snapcore/snapd/pull/7489>10:09
zygadot-tobias: I update the thread as I go if you are curious10:09
zygaijohnson: in a moment10:09
dot-tobiaszyga: *grabs popcorn*10:29
mupPR snapd#7490 opened: interfaces/shell-support: support confined snaps launching other snaps <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7490>11:51
mupPR snapcraft#2728 opened: Base bare <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2728>14:53
joedborgzyga: are you around?19:39
=== msalvatore_ is now known as msalvatore
zygajoedborg: yes but heading to bed22:08
joedborgzyga: no worries!22:09

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!