[06:13] <mborzecki> morning
[07:17] <zyga> o/
[07:18]  * zyga had a hard night
[07:19] <mborzecki> zyga: hey
[07:20] <zyga> hey
[07:20] <zyga> mborzecki: janek is 13 today
[07:21] <mborzecki> zyga: wow nice, best wishes for him :)
[07:22] <zyga> and iza turned her room upside down
[07:22] <zyga> being upset and angry well into midnight
[07:22] <zyga> because she wanted to have something for the sims and we said no, and it went downhill from there
[07:22] <mborzecki> hahaha ;)
[07:22]  * zyga is sleeeeeepy
[07:22] <zyga> (literally half of her stuff is downstairs as it slid down the stairs)
[07:23] <mborzecki> quick errand, need to drop by the town hall, back in 1h or so
[07:23] <zyga> she also tore our bed apart
[07:23] <zyga> good luch
[07:23] <zyga> luck I mean
[07:23] <zyga> I need to wake up
[07:45] <mborzecki> re for a little bit
[07:48] <mborzecki> i keep forgetting, why do we avoid using x/sys/unix?
[07:50] <zyga> mborzecki: no idea
[07:52] <zyga> I think it used to not support ppc
[07:52] <zyga> but now we don't support ppc eiter
[08:05] <pstolowski> mornings
[08:05] <mborzecki> pstolowski: hey
[08:06] <mborzecki> ok, trying the town hall once again
[08:16] <zyga> Hey
[08:16] <zyga> Is town hall today?
[08:18] <pstolowski> hey zyga
[08:18] <zyga> :-)
[08:19] <pstolowski> yeah i asked mborzecki the same, i don't have anything in my calendar
[08:22] <zyga> I see Oct 24th
[08:23] <zyga> nothing more?
[08:28] <pstolowski> zyga: same here
[08:33] <mborzecki> re
[08:34] <mborzecki> zyga: no, i mean my local council ;) dealing with some beaurocracy stuff here
[08:45] <zyga> ah ;D
[09:20]  * Chipaca coffees up
[09:32] <zyga> hey Chipaca  :)
[09:46] <Chipaca> zyga: 'sup :)
[09:46] <zyga> good, sleepy
[09:46] <zyga> slow day
[09:47] <Chipaca> zyga: yup
[09:47] <Chipaca> zyga: feels like a saturday, here
[09:51] <pstolowski> Chipaca: hey, i'll re-request a review for snapctl is-connected from you; the core implementation didn't change, but there is new stuff wrt error propagation between api and client
[09:51] <pstolowski> Chipaca: and i feel it's a bit of muddy waters :}
[09:51] <Chipaca> pstolowski: ok
[09:52] <pstolowski> i'm going to push in a moment
[10:05] <zyga-laptop> Chipaca http://asciicker.com/y0/
[10:05] <zyga-laptop> Chipaca try f1 / f2
[10:12] <ppd1990> Hi. Isn't snapcraft 3.9.2 supposed to be in the stable channel already?
[10:17] <pstolowski> zyga-laptop: wow @asciicker
[10:22] <Chipaca> ppd1990: supposed by who?
[10:23] <ppd1990> Chipaca: https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-9/13944/26
[10:26] <Chipaca> ppd1990: hm. Maybe it's phasing, or maybe somebody found an issue and it had to be rolled back?
[10:26] <zyga> pstolowski: right? :)
[10:26] <zyga> brb
[10:27] <mup> PR snapd#7824 opened: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
[10:27] <mborzecki> just when i thought mpt doesn't work again
[10:27] <mpt> ?
[10:28] <mborzecki> mpt: sorry, meant mup :)
[10:28] <Chipaca> mborzecki: no rebooting mpt
[10:28] <Chipaca> without their consent at least
[10:29] <mborzecki> should rename mup to something more bot-like
[10:29] <mpt> 😴
[10:29] <ppd1990> Chipaca: Probably :)
[10:29] <Chipaca> ppd1990: ask sergiusens in a few hours
[10:30] <Chipaca> ppd1990: (or, ask in that forum thread)
[10:30] <pstolowski> ppd1990: or ask on the forum
[10:34] <Chipaca> wow, the models used for CV are yuge
[10:34] <Chipaca> it's like 4GB of just models
[10:35] <zyga> what are you doing with CV?
[10:35] <mborzecki> osutil/stat.go:106:9: undefined: syscall.Faccessat on osx :/
[10:36] <zyga> mborzecki: heh
[10:36] <zyga> mborzecki: one sec
[10:37] <zyga> yeah, no such syscall
[10:38] <zyga> mborzecki: macos doesn't have a stable syscall layer
[10:38] <zyga> so we should probably not use it
[10:38] <zyga> it only has a stable .dylib layer
[10:45] <mborzecki> zyga: can you check what value does R_OK have on osx?
[10:52] <mborzecki> heh it's in x/sys/unix
[10:53] <mborzecki> i mean, the Faccessat on osx
[10:55] <Chipaca> zyga: just trying to get https://github.com/sniklaus/3d-ken-burns to work, for now
[10:58] <zyga> aha
[11:26] <mup> PR snapd#7825 opened: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[11:26] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/7825
[11:26] <zyga> I decided to open it without larger changes
[11:26] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[11:27] <zyga> mborzecki: I think landing and iterating will be just easier
[11:27] <zyga> mborzecki: and will unlock more things to land in parallel
[11:27] <zyga> (smaller things)
[11:39]  * zyga is baby-sitting lucy 
[12:02] <mborzecki> time for some reviews
[12:24] <cachio> cmatsuoka, hey
[12:24] <cachio> there is a bug that perhaps you could take a look https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852544
[12:24] <mup> Bug #1852544: uc20 grubenv block seems odd <core20> <Gadget snap for Personal Computers using Intel or AMD processors:New> <Ubuntu Image:Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852544>
[12:24] <cachio> it is related to UC20
[12:26] <cmatsuoka> cachio: checking that
[12:26] <cachio> cmatsuoka, thanks
[12:27] <cmatsuoka> cachio: we're already working on that
[12:27] <cachio> cmatsuoka, nice
[12:27] <cachio> cmatsuoka, good to know
[12:27] <cachio> cmatsuoka, is there a priority to assign to  the bug?
[12:27] <cmatsuoka> I believe it's already fixed but I didn't check the latest image to see how it's going
[12:29] <cmatsuoka> xnox: did we fix  https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852544 already? I believe so since you have a booting image (which I didn't check yet but's in my todo list for this morning)
[12:29] <mup> Bug #1852544: uc20 grubenv block seems odd <core20> <Gadget snap for Personal Computers using Intel or AMD processors:New> <Ubuntu Image:Invalid> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1852544>
[12:30] <xnox> cmatsuoka:  i believe that is still wrong
[12:30] <xnox> cmatsuoka:  in the gadget snap, i'm importing all the environment blocks, both good and bad.
[12:31] <cmatsuoka> xnox: humm ok I'll check the plans with Michael
[12:31] <cmatsuoka> xnox: thanks
[12:50] <cachio> kenvandine,  hi
[12:51] <cachio> kenvandine, I see and error when installing gimp in i386
[12:51] <cachio> kenvandine, https://travis-ci.org/snapcore/spread-cron/builds/618422327#L3292
[12:51] <cachio> is it being supoported right?
[13:02] <mup> PR snapcraft#2827 closed: build providers: only set the snapd flag when installing snapd <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2827>
[13:09] <sergiusens> ppd1990: there was an issue, I had to roll back temporarily https://github.com/snapcore/snapcraft/commit/1eebc27968e20e63ead11f7214c655284357fef2
[13:09] <ppd1990> sergiusens: Thanks a lot for the info. Much appreciated!
[13:11] <sergiusens> getting a bug (in my human body) did not help in making this go faster, sorry about that
[13:28] <mup> PR snapd#7726 closed: RFC: change how snapd tracks processes <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7726>
[13:29] <mup> PR snapd#7722 closed: cmd/snap-confine: add sc_join_sub_group <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7722>
[13:32] <mup> PR snapd#7486 closed: tests: add regression test for lp: #1844496 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7486>
[13:32] <mborzecki> zyga: we don't have a type for security tags do we?
[13:33] <mborzecki> zyga: i'm looking at #7825, and thiking that we may need a package to encode the ideas about naming things, like snap related cgroup, security tag and so on
[13:33] <mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
[13:33] <zyga> mborzecki: nope
[13:34] <zyga> mborzecki: security tag is more of an interface
[13:34] <zyga> mborzecki: with a String() method
[13:34] <mborzecki> zyga: for instance, right now the scope name is in snap run where it's created, and then some bits are in snapstate where the cgroup name is interpreted
[13:34] <zyga> and a InstanceName() method
[13:34] <zyga> I think we can clean it up a lot but ... it's a long path
[13:34] <zyga> mborzecki: can you do a quick review on https://github.com/snapcore/snapd/pull/7784
[13:35] <zyga> I can land it and iterate perhaps
[13:35] <mup> PR #7784: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <https://github.com/snapcore/snapd/pull/7784>
[13:35] <zyga> mborzecki: back to security tag, I think it ought to be an interface
[13:35] <zyga> mborzecki: because we have several kinds of security tags that are not alike
[13:35] <zyga> mborzecki: the concrete type of each could be string
[13:36] <zyga> mborzecki: but the wrapper type would be more useful .e.g. hook security tag, app security tag, that weird non-app-non-hook security tag for some udev things
[13:36] <zyga> mborzecki: it could have methods like SnapWideGlob()
[13:36] <mborzecki> zyga: and then the scope & cgroup names
[13:36] <zyga> and we could have a helper like GenrateScopeName(tag SecurityTag)
[13:37] <zyga> *Generate
[13:38] <zyga> mborzecki: how does that sounD?
[13:38] <mborzecki> sounD :) like systemD? :P
[13:41] <zyga> mborzecki: btw, offtopic, on fedora 31 I don't get snap icons in alt-tab in gnome
[13:41] <zyga> probably related to the centos bug
[13:41] <mborzecki> zyga: do you get them in the activities view?
[13:41] <zyga> yes i do
[13:42] <mborzecki> zyga: i suppose nothing in the logs?
[13:42] <mborzecki> zyga: btw. wayland or xorg?
[13:43] <zyga> wayland
[13:43] <zyga> logs are always full of garbage
[13:43] <zyga> lis 29 14:43:04 x240 gnome-shell[2041]: value "nan" of type 'gdouble' is invalid or out of range for property 'vignette-sharpness' of type 'gdouble' ;-)
[13:43] <zyga> lis 29 14:43:10 x240 systemd[1841]: dbus-:1.2-org.gnome.Boxes.SearchProvider@14.service: Succeeded. ;)
[13:44] <zyga> but nothing about the fact icons are gone
[13:44] <mborzecki> heh, at least it's no spamming the logs like it did a month ago
[13:44] <zyga> weirdish
[13:44] <zyga> oh it's full of junk really
[13:44] <mborzecki> right after 3.34 there'd be a constant 1-2kB/s of logs going to journal
[13:45] <zyga> heh
[13:45] <zyga> nvme pays for itself ;)
[13:53] <mup> PR snapd#7784 closed: cmd/snap-update-ns: adjust debugging output for usability <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7784>
[14:01] <zyga> mborzecki: I cannot join yet
[14:01] <zyga> lucy is waking up now
[14:01] <zyga> mborzecki: my update is simple: working on more testing and follow-ups
[14:01] <zyga> I'll update the doc shortly
[14:11] <xnox> cmatsuoka:  i did snap refresh of ubuntu-image & snapd
[14:12] <xnox> cmatsuoka:  created a fresh image
[14:12] <xnox> it still has two copies of core & pc-kernel snaps
[14:12] <xnox> once in /snaps and ones in /var/lib/snapd/snaps/
[14:12] <xnox> the second location is not used on UC20 seed partition
[14:12] <xnox> and grubenv is still in the wrong location at /boot/grub/ instead of at /EFI/ubuntu/
[14:14] <kenvandine> cachio: afaik.  diddledan see the question about gimp?
[14:19] <mborzecki> zyga: left some comments under 7825, need to play with this locally
[14:19] <cachio> kenvandine, taj, ok, thanks
[14:20] <diddledan> what's the spread test trying to do with gimp?
[14:22] <zyga> mborzecki: sure, thank you
[14:25] <zyga> thanks, replied to most
[14:25] <zyga> I'll apply the trivials shortly
[14:25] <zyga> mborzecki: note, I'm running this on F31 and it's not exploding :)
[14:28] <zyga> it's pretty cool that I can see memory usage of my app
[14:28] <zyga> mborzecki: sublime-text instance from a snap https://www.irccloud.com/pastebin/M8V1r6t3/
[14:33] <cachio> diddledan, it just installs gimp
[14:35] <diddledan> are you sure that's _all_ it is doing? because there's weird messages about "Match"ing stuff
[14:38] <cachio> diddledan, this is the test https://github.com/snapcore/snapd/blob/master/tests/nightly/install-snaps/task.yaml
[14:38] <cachio> diddledan, the MATCH is used to detect the channel and other info about the snap to isntall
[14:39] <diddledan> so what is the actual failure condition then?
[14:41] <cachio> diddledan, the test tries to install gimp in ubuntu 16.04 32bits
[14:41] <cachio> and this is happening
[14:41] <cachio> + snap install gimp --stable
[14:41] <cachio> error: cannot perform the following tasks:
[14:41] <cachio> - Ensure prerequisites for "gimp" are available (cannot install prerequisite "gtk2-common-themes": no snap revision available as specified)
[14:42] <zyga> cachio: that's weird, I'm not getting that
[14:42] <diddledan> yes, well that's not my fault then. that's down to whoever unpublished gtk2-common-themes from the 32bit stable channel :-)
[14:42] <diddledan> it affects other snaps too
[14:42] <diddledan> e.g. audacity
[14:43] <cachio> diddledan, yes
[14:43] <diddledan> (another of mine :-)
[14:44] <diddledan> gtk2-common-themes is still available in 64bit so I'm assuming closing the 32bit stable channel was either a mistake or someone wasn't thinking things through
[14:44] <cachio> I could include audacity to the test if you want
[14:44] <cachio> to we detect this kind of errors on important snaps
[14:45] <diddledan> in fact, gtk2-common-themes is _only_ availeble for amd64 now - it used to be available for i386.. https://snapstats.org/snaps/gtk2-common-themes
[14:46] <diddledan> kenvandine: is this something for you to look into?
[14:48] <kenvandine> Not sure what happened to i386
[14:49] <diddledan> it is probably worth investigating adding armhf and arm64 too
[14:50] <diddledan> for those of us that insist on using a pi as their desktop :-p
[14:50] <kenvandine> Yeah
[14:50] <kenvandine> I can't look at it today, but will on Monday
[14:51] <diddledan> coolbeans :-)
[14:51] <zyga> ah, 32bit systems
[14:51] <zyga> interesting
[14:54]  * cachio lunch
[14:58] <mborzecki> zyga: 130MB for sublime?
[14:58] <diddledan> all the MB!
[15:00] <mborzecki> heh, actually my emacs is using 250MB of heap so, maybe 130 isn't that much after all
[15:12] <zyga> mborzecki: yeah
[15:12] <zyga> mborzecki: I guess that's all the .so's loaded and stuff
[15:12] <zyga> mborzecki: but it's really neat
[15:12] <zyga> because we _can_ measure it
[15:21] <mborzecki> finally #7824 is green
[15:21] <mup> PR #7824: snap/squashfs, osutil: verify files/dirs can be accessed by mksquashfs when building a snap <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7824>
[16:05]  * zyga participated in his son's birthday
[16:07] <pstolowski> cachio: 2 questions to #7815, once clarified i can +1 it
[16:07] <mup> PR #7815: tests: reduce the complexity of the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7815>
[17:33] <Chipaca> i'ma gonna go ahead and EOW
[17:33]  * Chipaca just broke all the tests
[17:33] <Chipaca> see y'all monday
[17:49] <sdhd-sascha> zyga: hi, Hope your day was better than the night.
[18:23] <zyga> sdhd-sascha: it was pretty calm :)
[18:25] <sdhd-sascha> :) I had to help the in-laws today.
[18:26] <sdhd-sascha> I had two small question, if you have time ?
[18:27] <zyga> sure
[18:29] <sdhd-sascha> Is it possible to use a part only on a specific release (e.g. only on bionic) ?
[18:30] <zyga> are you asking about building in snapcraft?
[18:30] <sdhd-sascha> i found the advanced-grammer - but until now no source code
[18:30] <sdhd-sascha> yes
[18:30] <zyga> yeah
[18:30] <zyga> the source code is in a sister project, there are tests for this feature
[18:30] <zyga> which can be used as quick documentation
[18:30] <zyga> it's github.com/snapcore/snapcraft
[18:31] <sdhd-sascha> ok, i have it already here
[18:31] <zyga> I don't know the details, I think it's meant for system packages that can be injected into a snap package
[18:31] <zyga> you can vary those depending on build architecture IIRC
[18:31] <zyga> but it's not for this-or-that release
[18:31] <zyga> because the release is fixed by the selection of the base snap
[18:31] <zyga> inside snap.yaml and snapcraft.yaml you can say base: foo
[18:31] <zyga> and foo is a base snap name that defines how to build it
[18:31] <zyga> and how to run it
[18:31] <zyga> there are two commonly used base snaps now
[18:32] <zyga> core, which is derived from ubuntu 16.04
[18:32] <zyga> and core18 which is derived from ubuntu 18.04
[18:32] <sdhd-sascha> yes :-)
[18:32] <zyga> if you say base: core18 you will get binary packages from the matching architecture of that release
[18:32] <sdhd-sascha> i found it inside git:snapcraft/internal/project_loader/grammer/_on.py
[18:33] <sdhd-sascha> https://www.irccloud.com/pastebin/UecwmS5C/
[18:34] <sdhd-sascha> my problem is, that fontconfig of my 19.04 host is incompatible, with core18 ... Ok, i will try if a newer fontconfig inside a part is backward compatible
[18:34] <zyga> yeah, as I said it's for things like "on arm64 use this package" on "amd64 use that package"
[18:34] <zyga> wait wait
[18:34] <zyga> your host should not be a part of the build
[18:34] <zyga> when you build with snapcraft your tree should be transferred to a pristine vm managed by multipass
[18:34] <zyga> and built there
[18:34] <sdhd-sascha> Yes, but /etc/fonts/font.conf is from the host and mounted inside the snap
[18:34] <zyga> the vm will match the base you picked
[18:34] <zyga> ah, yes
[18:34] <zyga> and what are you seeing?
[18:34] <zyga> we have some special handling for fontconfig
[18:35] <zyga> perhaps there's a bug or the current system is insufficient
[18:35] <sdhd-sascha> i see:
[18:35] <sdhd-sascha> Fontconfig error: "/etc/fonts/fonts.conf", line 6: invalid attribute 'translate'
[18:35] <zyga> can you please report that, along with the output of "snap version" on bugs.launchpad.net/snapd
[18:35] <zyga> we'll have a look on Monday
[18:35] <zyga> I have a plan to stop sharing /etc
[18:35] <zyga> as it was a mistake
[18:36] <zyga> but it's not urgent enough to push through
[18:36] <zyga> (there are higher priority topics first)
[18:36] <zyga> once that is done we can synthesize correct /etc/fonts and anything else that matches the base snap
[18:38] <sdhd-sascha> ok. Also the goal is to not share /etc. right? (only i ask only for me, because i will experiment on this weekend)
[18:38] <zyga> that's my goal
[18:38] <zyga> it's not on the product roadmap
[18:38] <zyga> it will likely happen during the cycle
[18:39] <sdhd-sascha> Why would it be bad, to build fontconfig into the snap? (not urgent this question, i will try this too)
[18:39] <zyga> you can
[18:39] <zyga> but it's just bigger
[18:40] <zyga> and usually there's a fontconfig around from other places
[18:40] <zyga> e.g. the gnome runtime content snap
[18:40] <sdhd-sascha> ok
[18:40] <zyga> snaps don't have a "you must" policy usually
[18:41] <zyga> so if you want to showcase a cool feature of patched fontconfig
[18:41] <zyga> go for it :)
[18:41] <zyga> it's not like classic packaging
[18:41] <sdhd-sascha> The second question was: What is the difference of plugs/slot inside apps and inside global?
[18:41] <zyga> right
[18:41] <zyga> so, in general, each app and hook can have any number of plugs and slots
[18:41] <zyga> if you define a plug at a level of a specific app or hook it is "bound" there
[18:42] <zyga> if you define it globally you add it to all the apps and hooks
[18:42] <zyga> except if you define it globally but then only mention it in a specific app or hook
[18:42] <sdhd-sascha> ok. i understand.
[18:42] <zyga> the reason to define plugs and slots globally is so that you can use the richer syntax that has attributes
[18:42] <zyga> some interfaces require that
[18:42] <zyga> at app/hook level you can only use the abbreviated syntax
[18:42] <zyga> where just the name is given
[18:43] <zyga> and it defines a plug or slot with the same name and type
[18:43] <zyga> one example that is very common, that requires global definitions is the content interface
[18:43] <zyga> because it always requires some attributes
[18:43] <zyga> that's that
[18:43] <zyga> I think it's fairly documented on snapcraft.io/docs
[18:43] <zyga> but if you find something is missing or unclear please just say so
[18:44] <sdhd-sascha> The docs have also hidden pages, which are not in the menu, only in the text...
[18:44] <sdhd-sascha> About plugs/slots:
[18:44] <zyga> missing links are easy to fix
[18:44] <zyga> you can just go to the forum
[18:45] <zyga> and comment on the thread
[18:45] <zyga> there's a link on each doc page
[18:45] <sdhd-sascha> Now if a snap provide wayland and can also run under wayland, how should this be defined ? I got a error, if i use the wayland plug/slot as both
[18:45] <zyga> or ping @degville about it, he's managing documentation
[18:45] <zyga> so interfaces have two sides, plugs and slots
[18:45] <sdhd-sascha> :)
[18:45] <zyga> slots are the "providing" part, and plugs are the "consuming" side
[18:45] <zyga> having a plug or slot may already give you some permission
[18:46] <zyga> having a plug or slot connected to another slot or plug usually gives even more permissions
[18:46] <zyga> are you asking what is needed to run a wayland _server_?
[18:47] <sdhd-sascha> Both, wayland as client under wayland. And wayland as server, and later as client for other snaps.
[18:47] <zyga> ahj
[18:47] <zyga> I see
[18:47] <zyga> so you need two interfaces
[18:47] <sdhd-sascha> But we can delay this question.
[18:47] <zyga> plug and slot of wayland
[18:47] <zyga> they just need to have different names
[18:47] <sdhd-sascha> Ah
[18:47] <zyga> plugs: wayland-client: interface: wayland
[18:47] <zyga> slots: wayland-server: interface: wayland
[18:47] <sdhd-sascha> okay, then copy, paste the interface
[18:47] <zyga> (insert tabs and newlines as required)
[18:48] <zyga> yeah
[18:48] <sdhd-sascha> i understand
[18:48] <zyga> we added a requirement for plugs and slots to have unique names
[18:48] <zyga> to avoid confusing situations
[18:49] <sdhd-sascha> zyga: thank you. Now i have enough task, for the weekend ;-)
[18:49] <zyga> enjoy :)
[18:51] <sdhd-sascha> :)
[18:54]  * cachio afk
[23:51] <mup> PR snapd#7826 opened: tests: use on spread tests the test-snapd-sh snap <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7826>