[01:55] PR snapd#10675 opened: tests: migrate tests that are only executed on xenial to bionic [03:10] PR snapd#10676 opened: cmd/snap-update-ns/change.go: sort needed, desired and not reused mount entries [05:27] 'morning! [05:28] question of the day: what is the snappy-hub? https://code.launchpad.net/~alexmurray/snappy-hub/update-for-snapd-2.51.6/+merge/407651 [05:28] is it the base-set of apparmor templates, starting from which snapd composes the final profiles? [05:32] morning [05:34] mardy: look like amurray's private of snappy-debug snap [05:34] private copy ofc [05:34] mardy: fwiw the base template which snapd uses is right here: https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go [05:42] mborzecki: good morning! Thanks, so I guess it's not for us to review? [05:44] mardy: no, i don't think so, i've never reviewed anythign there, but you can always ask amurray about snappy-debug [06:18] good morning :) [06:18] hello mvo [06:19] zyga: hey [06:19] hey zyga and mborzecki [06:19] mvo, it's gotten cold here [06:20] when I was leaving the house today it was just 9C outside [06:20] brr [06:21] morning [06:21] hey pawel! [06:21] mvo: pstolowski and hey [06:21] yeah, it's cold here too, 10C at most [06:21] and it's not even september :/ [06:22] hi zyga, mvo, pstolowski :-) [06:22] hey mardy [06:22] mborzecki: ah! it's 11C here, so we win today :-) [06:34] good morning pstolowski and mardy [06:34] zyga: yeah, same here (but I don't think 9C just yet), feels like the summer is on the way out [06:35] indeed :/ [06:51] PR snapd#10644 closed: o/snapstate: don't hold some snaps if not all snaps can be held by the given gating snap [06:51] PR snapd#10673 closed: .github/workflows/test.yaml: fix logic [06:56] PR snapd#10647 closed: o/snapstate: fail remove with invalid snap names [06:56] PR snapd#10669 closed: o/hookstate/ctlcmd: correct err message if missing root [07:15] mardy: 10606 is ready it seems, just needs a master merge to resolve a conflict and (maaaaaybe) consider my diff in there but that would be one more merged PR :) [07:16] PR snapd#10107 closed: packaging: stop snapd.{socket,service} before purging data [07:19] mvo: I'll see if I can apply your suggestion without major changes (but I can't foresee any) [07:21] mardy: I tested locally and it seems unit tests are still happy [07:22] mardy: but I only looked very briefly :) [07:29] mvo: thanks, I applied it and also rebased+squashed the branch on top of the latest master, since it already got a few approvals [07:31] it's "funny", that on github you can make any changes to your branch, and you do not lose the approvals. On Gitlab one generally loses them (though it can also be configured to retain them) [07:31] PR snapd#10677 opened: snapstate: fix misleading `assumes` error message [07:46] PR snapd#10671 closed: o/assertstate,snapstate: refresh validation set assertions with snap declarations

[08:31] PR snapd#10678 opened: o/snapstate: enforce validation sets assertions when removing snaps

[08:33] mardy: yes it's a bit controversial [08:33] we should use common sense and if changes are not trivial, re-request reviews for already approved [08:38] mvo: quick question about remodel since pedronis isn't around yet and maybe you remember what the agreement was, we update the tracking channel of kernel and gadget snaps, do you think the tracking channel of application snaps should be updated too? [08:42] mborzecki: I think so, if it has changed we should probably do the same [08:43] mvo: well, i extended the uc20 managers test that i have and we're not updating it ;) [08:43] i don't think that we do it for 18 remodels either [08:44] mvo: fwiw, we only add install tasks, but otoh it wasn't really possible to specify tracking channel in 18 remodels [08:44] mborzecki: but I also have a question for you: in https://github.com/snapcore/snapd/pull/10634 I made some progress and debian/ubuntu seems to be in reasonable shape with go-modules. but the rpm is giving me a bit of trouble, it looks when I run "spread fedora-34-64:tests/main/listing" locally that it still tries to GO111MODULES=off things even though in this branch there should be no GO111MODULE=off left. so it seems this is somehow implicit from the rpm macros? [08:44] PR #10634: many: move to go modules gradually <⛔ Blocked> [08:44] mborzecki: woah, thanks for finding this [08:45] mborzecki: I guess that is something we need to fix eventually [08:45] mborzecki: :/ [08:45] mvo: it may be the case that the go rpm packaging sets that, let me check [08:52] mvo: go packaging in fedora sets that [08:53] mvo: https://paste.ubuntu.com/p/CKTWyCGD2W/ [08:58] mborzecki: hm, so it looks like this needs some deeper dive :/ [08:58] mborzecki: thanks, good to know where to look [09:02] mvo: it's part of the distro marcos https://paste.ubuntu.com/p/hdKZZZvGYs/ [09:03] so unless you redefine the marco it's not possible to drop it? [09:05] still, do we need to drop that? [09:06] hey miguelpires [09:08] Hi =) [09:23] mvo: any clue who can fix/update the docs index while degville is away? some links are bad eg. https://snapcraft.io/docs/snapcraft-extensions [09:24] miguelpires: hi, if you could address the last remaining comment from https://github.com/snapcore/snapd/pull/10584 that would be great, would love to see it landed today [09:24] PR #10584: o/assertstate: fix missing 'scheduled' header when auto refreshing assertions [09:26] @psto [09:26] pstolowski pushing it now =) [09:27] miguelpires: awesome! thanks [09:54] mborzecki / mvo: having a look at that issue now (I can spare some time). [09:54] degville: hey, no worries, you're on vac 😉 do you know who i can poke to take a look at this? [09:55] mborzecki: first glance, and it looks like the webteam have swapped out the old table of contents again. [09:55] mborzecki: Fran on the webteam made the change. [09:56] they're now using this as the source for all pages: https://forum.snapcraft.io/t/snap-documentation-pages/25750 [09:57] degville: cool, i'll ping jkfran in the web channel [09:59] mborzecki: thanks! worst case is he'll need to revert to the old style. It's very annoying they make these changes like without tests or letting us know. [09:59] miguelpires: +1, but I think there is a small vet problem [10:00] degville: yeah, thank you for looking into this 🙂 [10:02] pstolowski Yeah, the static checks are failing but I can't reproduce it locally. Strange [10:02] mborzecki: no problem, sorry you had to get involved. Thank you! [10:03] miguelpires: different go vet versions probably [10:25] hey degville :) [10:25] long time no see [10:35] pstolowski: can https://github.com/snapcore/snapd/pull/10243 be closed or do you plan to update the test? [10:35] PR #10243: tests: failure of prereqs on content interface doesn't prevent install [10:37] zyga: hello!! yeah, it has been a while. Hope you're doing well. [10:38] :) [10:38] yeah, I'm fine [10:38] I miss sprints [10:38] and the people [10:40] yeah. I think we all do, although we can hopefully get back to them next year. I really miss travelling too - stayed at home this year, which has been fun too, but I'm already looking forward to exploring further afield. [10:42] no Frankfurt in Sept? [10:52] mborzecki: no, it was unexpected discovery to me but works as designed, if you mean updating XXX comment then yes, i should update it. i think it makes sense to have this test [10:53] ok, sgtm [10:53] lemme do this right now [10:58] mborzecki: updated PR description as well [10:58] anyone using `hub` tool? damn thing doesn't want to checkout PRs anymore, getting 404 [11:00] mborzecki: i do from time to time, let me check [11:01] mborzecki: works, hub 2.14.2 [11:01] pstolowski: hm same version :/ [11:02] mborzecki: hub pr checkout 10676, that's what i tried [11:14] pstolowski: ok, i'm a muppet, was calling that in a different repository [11:14] lol [11:21] mvo: can you land https://github.com/snapcore/snapd/pull/10617? random failures [11:21] PR #10617: cmd/snap: add Size column to refresh --list [11:45] i saw some PRs failing with https://codecov.io: 404 on CodeCov [11:52] PR snapd#10679 opened: tests: fix restore in snapfuse spread tests [12:19] miguelpires: hm something went south a bit: https://paste.ubuntu.com/p/9z2R25ZtSX/ can you check whether this happens on master too? [12:19] (that's after mergin master to #10241) [12:19] Bug #10241: readline5: FTBFS: Missing Build-Depends on 'texinfo' [12:19] PR #10241: tests: set memory limit for snapd [12:23] mborzecki: do you mean the error itself or the weird whitespace? I opened a PR to fix the spread test: https://github.com/snapcore/snapd/pull/10679 [12:23] PR #10679: tests: fix restore in snapfuse spread tests [12:24] miguelpires: the spread test, thanks for pushing a fix! [12:29] miguelpires: haha, funny how ---purge went unnoticed because of that other problem you fixed [12:38] are your PRs also affected by spread timeouts, or is it only mine? :-) https://github.com/snapcore/snapd/pull/10606 [12:38] PR #10606: o/hookstate/ctlcmd: unify the error message when context is missing [12:42] haha, I guess now we know the remove validation really works! [12:44] miguelpires: \o/ [12:49] :) [12:53] HI, I am working on a project to setup a hotspot and do a lot more things. So, I am using wifi-ap to create hotspot. I add it to stage snaps. How am I supposed to run a snap installed in my snap? [12:53] i try running the executable in the $SNAP/bin folder but it does not work, am I missing something? [12:55] mardy: I noticed the same "cannot provision XYZ: quota 'CPUS' exceeded" [12:55] ares1256, do you want to run an exported snap application from the system or an internal binary from a snap command [12:56] yeah I want to run an exported snap from my snap command [12:56] ? [12:56] wait, what is an exported snap? [12:56] do you want to run an app published by your own snap from another app in your own snap? [12:56] like a snap which is already on the store' [12:56] ah [12:56] that's not possible unless your snap is using classic confinement [12:56] ohh [12:56] that would introduce a dependency [12:57] and those must be modeled with interfaces [12:57] but technically it's just hard/impossible to run an app from another app [12:57] mainly because seccomp, by design, does not allow a process to shed past restrictions [12:58] and that would also mean that the snap should have interfaces available to interact with it right?like slots availble to connect to... [12:58] and technically your snap sandbox would combine with the sandbox of the other app, resulting in breakage at best [12:58] right but even then you have to explicitly design for that [12:58] ohh... [12:58] e.g. by offering a socket and having an interface that lets one of the snaps talk to the other [12:58] services are hard [12:59] the socket model is really the way forward but it requires some preparation [12:59] as each service runs with its own confinement [12:59] so lets say there is a snap wifi-ap [12:59] and technically the interface is not about snap-to-snap communication [12:59] but about a snap-to-service [12:59] and i can start wifi-sp by command start [12:59] and the service _can_ be replaced by another snap [12:59] so i cant have a shell file saying "start"? [13:00] to begin that wifi-ap snap? [13:00] no [13:00] ohh [13:00] well, I can explain why [13:00] but no [13:00] for both technical and design reasons [13:00] you can run any command from the unconfined host process [13:01] but once you are inside a snap application, you are confined and you cannot, by design, execute apps from other snaps [13:01] (or most of the host apps for that matter) [13:01] on ubuntu-core devices this is strict, on classic devices you may use classic confinement to do more free-form snaps but those are notoriously hard to get right [13:01] (with apologies to sergiusens) [13:02] yeah i was able to do it in devmode...but when i came to starict.....nothing was working [13:02] right [13:02] that's expecte [13:02] *expected [13:02] even in devmode you could easily hit a wall where it breaks though [13:02] because unless both snaps are in devmode [13:03] the "other" snap is still using normal confinement [13:03] so my only option is to create my own hotspot snap? [13:03] or bundle both into one larger snap [13:03] if i need full control over it [13:03] ares1256, have a look at https://github.com/ogra1/nm-wifi-hotspot-snap [13:04] (also in the store already) [13:04] or work with the author of the other snap to create a control interface [13:04] (a socket and a matching snapd interface that allows you to use it) [13:04] hey ogra :-) [13:04] yo ! [13:04] how have you been? [13:04] playing with kiosks recently again [13:05] thanks, i wil look into this @o [13:05] (trying to convince a browser to use accelerated video playback on a PI ... with a fun 5000 line patch to chromium 😛 ) [13:05] thanks ogra and zyga i will look into this [13:06] ares1256, good luck! [13:06] ogra, raspberry pi, how we all have to deal with it :) [13:06] ares1256, also, in case you are interested in a captive-portal setup https://github.com/ogra1/opennds-snap ... (https://snapcraft.io/opennds and https://snapcraft.io/nm-wifi-hotspot are the store pages for them) [13:07] zyga, yeah ... its a blessing and a curse at the same time 🙂 [13:07] Alright(y) [13:07] ogra, I was looking for CM4 modules but availability is well into the Q2 2022 [13:07] yeah, chip shortage [13:08] at some point I can switch to pico :) [13:08] and play with zephyr [13:08] but not yet [13:08] i luckily got my CM4 half a year ago ... running fine, booting off NVME PCIe 😉 [13:09] ogra, I was looking for a model that doesn't suck, some ram, emmc and wifi [13:09] no luck [13:09] base boards are plentiful though [13:09] yeah [13:10] i guess the chip shortage will still last a while 😞 [13:11] how come we have chip shortage and not beer shortage [13:11] can people really consume more silicon than alcohol? ;-) [13:12] lol [13:25] hi ogra , just to be sure. If i can use nm-wifi-hotspot. I have to include the app inside my snap right? [13:25] *inside my snapcraft.yaml [13:25] ares1256, as you like, you can just use the existing snap but will need to manually set the SSID and password [13:26] yeah thats fine [13:26] ok thanks [13:26] or you can include my snap via stage-snaps [13:26] or you can just copy/paste the part and app bits from my snapcraft.yaml into yours [13:26] all three should work [13:26] if i stage snaps, can i run this command then " snap set nm-wifi-hotspot ssid="My Cool SSID"" [13:27] it will be slghtly different since you likely wont call it nm-wifi-hotspot ... but yeah, the basics should be the same [13:27] ohk(y) [13:28] if you have any issues down the road, feel free to ask [13:29] ok, thanks [13:32] just another small question of a different topic [13:32] i want to modify a config file that i stored in $snap_data directory [13:32] so i add a plug [13:32] config-files: [13:32] interface: system-files [13:32] read: [13:32] - $SNAP_DATA/AP_config [13:32] - $SNAP_DATA/lte_config [13:33] when i compile this, it always gives an erro that it requires "/" first [13:34] you do not need an interface for accessing $SNAP_DATA ... [13:34] that is always rw for the snap [13:35] ohh [13:35] ok [13:35] and yes, system-files requires a full path on the filesystem, it is usually used to i.e. access something on the host filesystem you normally can not get access to with any existing interface [13:41] mvo: can you merge https://github.com/snapcore/snapd/pull/10584 ? [13:41] PR #10584: o/assertstate: fix missing 'scheduled' header when auto refreshing assertions [13:48] pstolowski: sure [13:48] thanks pstolowski and miguelpires [13:52] PR snapd#10584 closed: o/assertstate: fix missing 'scheduled' header when auto refreshing assertions [14:22] PR snapd#10680 opened: o/assertstate,daemon: refresh validation sets assertions with snap declarations

[14:28] ijohnson[m]: a second review for 10666 would be great [14:29] mvo: could you please use your magic powers on https://github.com/snapcore/snapd/pull/10606 ? [14:29] PR #10606: o/hookstate/ctlcmd: unify the error message when context is missing [14:29] mvo: can you merge #10617 as well? [14:29] PR #10617: cmd/snap: add Size column to refresh --list [14:29] Bug #10617: Multiple cd burning problems [14:42] my old PR that is test-only needs a 2nd review: https://github.com/snapcore/snapd/pull/10243 [14:42] PR #10243: tests: failure of prereqs on content interface doesn't prevent install [14:47] cachio_: could you merge master into #10443 to ensure it still passes (i was last executed 1 month ago) [14:47] PR #10443: tests: check files and dirs are cleaned for each test [14:47] Bug #10443: X pointer persistent in middle of screen on login [15:49] mvo: can you merge #10679 please? [15:49] PR #10679: tests: fix restore in snapfuse spread tests [15:49] Bug #10679: Use xdelta binary diffs in Ubuntu unstable release? [15:50] miguelpires: sure [15:53] PR snapd#10679 closed: tests: fix restore in snapfuse spread tests [16:46] PR snapcraft#3571 opened: [WIP] offline [20:36] PR snapcraft#3572 opened: cli & providers: pass part names for lifecycle commands [20:46] * cachio_ afk [23:59] PR snapd#10681 opened: interfaces/hardware-observe: add some dmi properties