[06:07] <mup> PR snapd#8068 closed: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8068>
[06:10] <mvo> hey mborzecki
[06:10] <mborzecki> mvo: hey
[07:46] <zyga> Hey mvo
[07:46] <mborzecki> mvo: pushed the change with link structure to #7972
[07:46] <mborzecki> zyga: hey
[07:46] <mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
[07:46] <zyga> I was woeking till 2am
[07:46] <zyga> Somewhat sleepy still
[07:46] <zyga> Kids woke me up
[07:46] <zyga> Sick and staying at home
[07:46] <mborzecki> zyga: i know you were playing c&c red alert :P
[07:46] <zyga> I wish :-)
[07:47] <zyga> I went for a walk at 2am
[07:47] <zyga> With my sleeping dog in my hand :]
[07:48] <zyga> He dislikes water so much I had to carry him for a while to convince him to walk
[07:48] <zyga> I wrote first spread tests for apparmor prompting
[07:51] <zyga> I’ll start later today
[07:51] <zyga> Need to wake up first
[07:57] <pedronis> mborzecki: mvo: hi, is one of you going to work on #8064 this morning?
[07:57] <mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[08:02] <mborzecki> pedronis:  i was thinking about #8001 but i can look into 8064 first
[08:02] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[08:03] <pedronis> mborzecki: I made comment there and I didn't make on 8001
[08:03] <pedronis> mvo extracted it
[08:16] <mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
[08:17] <mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58
[08:23] <mvo> mborzecki: thank you, I check 7972
[08:33] <mup> PR snapd#8070 opened: dirs: fixlet for XdgRuntimeDirGlob <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8070>
[09:04]  * Chipaca returns from the doctor's and has breakfast
[09:05] <mup> PR snapd#8071 opened: o/auth,daemon: do not remove unknown user <Created by pedronis> <https://github.com/snapcore/snapd/pull/8071>
[09:05] <pedronis> Chipaca: ^
[09:06] <Chipaca> pedronis: you ok with the toctou race there?
[09:06] <pedronis> Chipaca: for now yes
[09:07] <pedronis> the current behavior is kind of worse
[09:07] <Chipaca> pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the system user, remove the home and spool
[09:07] <Chipaca> your question last night left me thinking and that's what i thought we'd do
[09:07] <Chipaca> er
[09:08] <Chipaca> insert 'release the lock' after 'remove system user'
[09:08] <pedronis> Chipaca: well, if you think is doable simply enough you can do it on top of my PR
[09:08] <pedronis> otherwise leave possible todo
[09:08] <Chipaca> gah i made a mess
[09:08] <Chipaca> pedronis: the alternative would be to hold the lock, check, remove the system user without --remove, remove the auth user, release the lock, remove the home and spool
[09:08] <Chipaca> ^ there better
[09:09] <Chipaca> the split of the current remove-user-and-home being so as not to hold the lock for ages
[09:09] <pedronis> yes, I understand that
[09:11] <pedronis> Chipaca: I also think that snap remove-user email should do something, given create-user email
[09:11] <pedronis> but that we can deal with it
[09:11] <Chipaca> pedronis: given we're looking it up anyway, sure :-)
[09:11] <pedronis> (it's a bit of a mess of its own)
[09:12] <pedronis> because there might many users with the email and some might not have a username
[09:24] <zyga> o/
[09:24] <zyga> how are you guys
[09:28] <Chipaca> zyga: we're latest/edgy
[09:29] <pedronis> could be better
[09:29] <zyga> tired?
[09:29] <zyga> I'm energized, despite not sleeping much
[09:39] <mborzecki> mvo: pedronis: i've updated #8064
[09:39] <mup> PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[09:41] <mvo> mborzecki: thank you!
[09:44] <Chipaca> did the change to warn about invalid seeds get done?
[09:51] <Chipaca> kenvandine: where should bugs for desktop-launcher go, on launchpad?
[09:52] <pedronis> mborzecki: thanks, small remark
[09:53] <Chipaca> mvo: maybe you know ^^
[09:54] <mvo> Chipaca: do you know the package name? I guess not :) or a binary name in /usr or something?
[09:54] <mborzecki> pedronis: ack
[09:54] <Chipaca> mvo: i mean the snapcraft desktop laucnher helper thing
[09:55] <Chipaca> desktop-helper? worker-dancer? warrior-priest?
[09:55] <mvo> Chipaca: haha - sorry, now I get what you mean
[09:56] <mvo> Chipaca: my guess is snapcraft itself but I'm not super confident, kenvandine will know but it's very early for him I guess
[09:57] <Chipaca> you mean kenvandine isn't a robot?
[09:57] <Chipaca> mvo: I think I'm leaving #1861177 as New so either you or Ian take a look at it when it's your triage day
[09:57] <mup> Bug #1861177: seccomp_rule_add is very slow <patch> <server-next> <snapd:New> <libseccomp (Ubuntu):Triaged> <https://launchpad.net/bugs/1861177>
[09:59] <mvo> Chipaca: nice! let me check that
[09:59] <mvo> Chipaca: that looks pretty neat
[09:59] <Chipaca> mvo: i'm assuming the <patch> bit :-)
[09:59] <Chipaca> not the actual 'iz slow' bit
[10:03] <mvo> Chipaca: yeah, the patch bit
[10:10] <mvo> mborzecki: feedback in 7972, looks very nice now
[10:11] <Chipaca> pedronis: I hope https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1860769/comments/3 isn't too much of a lie :-)
[10:11] <mup> Bug #1860769: should record changes after snap transactions <etckeeper (Ubuntu):Confirmed> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1860769>
[10:14] <ogra> Chipaca, https://github.com/ubuntu/snapcraft-desktop-helpers/issues
[10:14] <Chipaca> ogra: what part of 'on launchpad' is that
[10:16] <Chipaca> also why is that still pointing people to rocketchat
[10:16] <Chipaca> is rocketchat/snapcraft still a thing?
[10:18] <ogra> o idea, but that tree is the source people typically include in their snapcraft.yaml to get the launchers
[10:18] <ogra> s/o/no/
[10:29] <mborzecki> mvo: can you take a look at #8064 ?
[10:29] <mup> PR #8064: boot: add bootloader options to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[10:29] <pedronis> mvo: #8064 needs some kind of 2nd review
[10:29] <mborzecki> if it's ok, i'll land it an update 8001 accordingly
[10:31] <mvo> pedronis, mborzecki sure, on it
[10:33] <pedronis> #8071 also needs a 2nd review
[10:33] <mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <https://github.com/snapcore/snapd/pull/8071>
[10:34] <mvo> pedronis: was looking at this one as we speak :)
[10:36] <pedronis> mborzecki: 8064 should be ok to land once gree and then we can pick up 8001
[10:36] <pedronis> green
[10:36] <mup> PR snapd#8071 closed: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
[10:36] <zyga> pedronis: (post merge) https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285
[10:36] <mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
[10:36] <mborzecki> pedronis: ok
[10:37] <pedronis> Chipaca: #8071 is in, you might want to update your PRs also consider zyga suggestion but I thought of it myself and not sure whether it makes the message too clunky
[10:37] <mup> PR #8071: o/auth,daemon: do not remove unknown user <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8071>
[10:38] <Chipaca> pedronis: which suggestion would that be?
[10:38] <pedronis> Chipaca: https://github.com/snapcore/snapd/pull/8071#pullrequestreview-350723285
[10:38] <Chipaca> grah, it now conflicts
[10:38] <Chipaca> not fair
[10:39] <pedronis> Chipaca: not suprising though, no
[11:00]  * Chipaca takes a break
[11:14] <mup> PR snapd#8064 closed: boot: add bootloader options to coreKernel <UC20> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8064>
[11:21] <juliank> Hey folks, I ended up with 6 loop devices with deleted snap squashfs: https://paste.ubuntu.com/p/ry5ZKGqxCS/
[11:21] <zyga> hey
[11:21] <juliank> This machine has an uptime of 9 days
[11:21] <juliank> It's running focal
[11:21] <zyga> this is a known issue, it feels like a systemd / libmount bug
[11:21] <zyga> we never manage loop devices ourselves
[11:22] <zyga> it is reported on launchpad
[11:22] <juliank> hmm
[11:23] <juliank> The problem is that, as mentioned on #ubuntu-devel, these now show up in nautilus, confusing users (in this case, me)
[11:23] <juliank> Not sure how to solve that
[11:24] <juliank> Probably udisks should look if backing file is in /var/lib/snapd/snaps, and then set HintIgnore to true
[11:31] <zyga> there's logic like that
[11:31] <zyga> it's a different problem
[11:31] <zyga> it shows up as deleted, unmounted loop device you can mount (??) by clicking on it
[11:31] <zyga> but it isn't possible because it is deleted
[11:32] <zyga> I really don't know what to do about it, apart from chasing kernel/libmount/systemd internals
[11:32] <zyga> I think we used to have a reproducer script
[11:32] <zyga> but perhaps I'm confusing this with another issue
[11:40] <juliank> zyga: Oh you can absolutely mount them, the loop device still has an open file descriptor, so the inode is never actually freed
[11:41] <zyga> the loop devices, yes
[11:41] <zyga> the backing file they used is not linked to the filesystem anymore (but still takes space)
[11:41] <juliank> yes
[11:43] <juliank> Couldn't snapd like look once each hour / after it updates a snap for loop devices that point to deleted snap files and delete them?
[11:44] <juliank> Hah no
[11:44] <juliank> If I losetup -d the loop device it remains active
[11:45] <ogra> well, effectively systemd should do this
[11:45] <juliank> ogra: But I can't even do it manually, so something is off there
[11:45] <juliank> Ah
[11:46] <juliank> So closing my telegram window removed the loop device
[11:46] <juliank> Which I guess means the loop device is used in a different mount namespace?
[11:47] <ogra> hmm, doesnt for me .... but then ... unity7 here ...
[11:47] <juliank> OK, I also ran losetup -d multiple times before, it might have marked it for dettachment
[11:47] <ogra> yeah, that might be
[11:51] <juliank> Confirmed
[11:52] <juliank> The lxd snap still has deleted loop devices mounted
[11:52] <juliank> /proc/1425517/mounts:/dev/loop53 /bin/kmod squashfs ro,nodev,relatime 0 0
[11:53] <juliank> and various other processes
[11:55] <juliank> I don't understand why the mount point is listed as /bin/kmod, though
[11:57] <juliank> Running unmount /bin/kmod inside the namespace a few times made all except one lxd snap loop device go away
[11:57] <ogra> lxd modprobing something inside the container ?
[11:58] <ogra> probably squashfuse related ?
[11:59] <zyga> juliank: if you come up with a reliable way to reproduce
[11:59] <zyga> we can start chasing this more aggresively
[12:00] <zyga> aggressively
[12:08] <juliank> hmm I'm not sure I have time to come up with a reproducer
[12:09] <juliank> Given the number of lxd in there, I'd sort of expect that just switching around lxd versions should trigger this, but not tried it
[12:17] <mup> PR snapd#8070 closed: dirs: fixlet for XdgRuntimeDirGlob <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8070>
[12:57] <pedronis> mvo: is #7999 ready for re-review?
[12:57] <mup> PR #7999: devicestate: allow encryption regardless of grade <UC20> <⛔ Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999>
[13:11] <mvo> pedronis: yes, I think so
[13:13] <pedronis> mvo: it's failing though? it's a new initramfs to land?
[13:13] <pedronis> *it needs
[13:25] <mvo> pedronis: yeah, I pinged dimitri earlier
[13:26] <mvo> pedronis: but yeah, this will only work once the initrd can open it
[13:32] <zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8067#discussion_r372947893 please
[13:32] <zyga> is that sensible?
[13:32] <zyga> if so I'll make that happen and we can merge this
[13:32] <zyga> maybe for .3?
[13:32] <mup> PR #8067: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067>
[13:32] <zyga> mvo: we will have .3 - correct?
[13:33] <mvo> zyga: well, maybe
[13:33] <mvo> zyga: there is a (small) chance that we can get away witout
[13:33] <mvo> without
[13:44] <zyga> brb
[13:44] <zyga> see you at the standup
[13:55] <ijohnson> morning folks
[13:58] <mborzecki> ijohnson: hey
[13:58] <ijohnson> hey mborzecki
[13:58] <mborzecki> ijohnson: 8064 landed, i've pushed some updates to #8001 and doing a little cleanup now, i'll push it after the standup hopefully
[13:58] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[13:59] <ijohnson> mborzecki: ack thanks for doing that
[13:59] <mborzecki> ijohnson: or maybe i should push it to my fork, in case it's too dramatic :)
[13:59] <ijohnson> mborzecki: how dramatic of a change is it ?
[14:00] <mborzecki> ijohnson: splitting the boot state update 20 commit() into separate successful/candidate kernel code paths
[14:01] <ijohnson> mborzecki: you meant a separate commit for setNext and markSuccessful ?
[14:01] <ijohnson> err commit() method I mean
[14:01] <mborzecki> ijohnson: yeah, actually doing that via 2 separate types, each implementing bootStateUpdate
[14:01] <ijohnson> mborzecki: smells a lot like my rewrite I have locally for the next step with base snaps
[14:02] <mborzecki> hahah ;)
[14:02] <ijohnson> mborzecki: but sure feel free to push it, I can always re-work mine on top of yours
[14:26] <sdhd-sascha> Hi, should i ask here, or on #maas, about:
[14:26] <sdhd-sascha> # snap install maas
[14:26] <sdhd-sascha> 2020-01-30T14:25:28Z INFO Waiting for restart...
[14:26] <sdhd-sascha> error: cannot perform the following tasks:
[14:26] <sdhd-sascha> - Run configure hook of "maas" snap if present (run hook "configure": chown: changing ownership of '/var/snap/maas/common/log/proxy': Operation not permitted)
[14:38] <ijohnson> mborzecki: let me know when you've pushed that up
[14:38] <mborzecki> ijohnson: sure
[14:38] <zyga> sdhd-sascha: chown is usually not allowed, the exception is chown to a special snapd daemon user
[14:39] <zyga> sdhd-sascha: I'm not sure if that's what maas is doing
[14:41] <sdhd-sascha> zyga: i just installed the `apt` version. I tried the snap inside of lxd ...
[14:42] <sdhd-sascha> maybe, i look later deeper into the script.
[14:42] <zyga> sdhd-sascha: I don't know how that's related
[14:43] <pedronis> mvo: Chipaca: I'm having a break, ping me later when you want to chat about download
[14:43] <zyga> I'll grab lunch/dinner now
[14:43] <zyga> and finish my cold soup :)
[14:52] <mvo> pedronis: are you ok with picking 8067 for 2.43? if we have to do a release it seems like a nice and simple fix
[15:02] <ijohnson> pedronis: mvo: mborzecki: sorry I forgot to inquire during SU, but shall I go with mvo's suggestion and extract the initramfs-mounts bits from #8001 into a separate pre-req PR, or are we looking okay to merge with that in there?
[15:02] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[15:04] <zyga> mmm
[15:04] <zyga> yummy food today :)
[15:04] <zyga> polish salad and veggie soup :)
[15:04] <zyga> mvo: you should try the polish salad one day
[15:05] <zyga> mborzecki: ^ do you know how it's called in English?
[15:11] <zyga> random falures
[15:11] <zyga> just love'm
[15:11] <Eighth_Doctor> mmm failure :D
[15:12] <zyga> just slower, travis stopped
[15:12] <zyga> eh
[15:30] <mborzecki> ijohnson: meh, i don't think i'll push it anytime today, got more complicated that i hoped
[15:31] <pedronis> ijohnson: well, I reviewed that code and what it needs is really to be some kind of helper, I don't think splitting helps at this point
[15:31] <pedronis> but maybe other reviewers have other preferences
[15:36] <mborzecki> zyga: polish salad?
[15:36] <zyga> mborzecki: yeah... geez how to explain that
[15:36] <mborzecki> zyga: photo?
[15:36] <zyga> https://www.google.com/search?q=sa%C5%82atka+jarzynowa
[15:36] <zyga> something like this?
[15:40] <mborzecki> zyga: ah, well, no clue whether there's an generally accepted english name for it, veggie salad? boiled veggie sald?
[15:40] <zyga> but it's nothing like I've seen in other countries
[15:40] <zyga> anywy
[15:40] <zyga> we need a sprint in poland
[15:40] <zyga> lodz would be great
[15:41] <zyga> :)
[15:47] <Chipaca> mvo: pedronis: shared a doc with you about download. GOing to step out for ~40 minutes, let's talk when i get back?
[15:48] <pedronis> Chipaca: ok
[15:48] <mup> PR snapcraft#2894 closed: Fix issue with multipass mount on win32 <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2894>
[15:48] <mup> PR snapcraft#2895 closed: lifecycle: raise detailed error if mksquashfs fails <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2895>
[15:54] <mup> PR snapcraft#2897 closed: meta: include environment in hook wrappers <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2897>
[16:00] <mup> PR snapcraft#2898 closed: meta: remove dead code from snap packaging <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2898>
[16:07] <ijohnson> pedronis: ok I asked mvo about splitting it and I think it's best to leave it in for now, and I can refactor the bootloader kernel bits in initramfs-mounts into a helper later
[16:09] <ijohnson> mborzecki: sure, I will go through the rest of the comments in 8001 and address them then, perhaps you can cleanup anything else you need tomorrow AM
[16:40] <sdhd-sascha> how can i debug or step this process:
[16:40] <sdhd-sascha> ```
[16:40] <sdhd-sascha> $ sudo snap refresh lxd
[16:40] <sdhd-sascha> error: snap "lxd" has "auto-refresh" change in progress
[16:40] <sdhd-sascha> ```
[16:40] <sdhd-sascha> stop
[16:45] <pedronis> Chipaca: back?
[16:49] <Chipaca> pedronis: back
[16:49] <Chipaca> sdhd-sascha: snap watch --last auto-refresh
[16:51] <sdhd-sascha> Chipaca: thank you. It's seems to hang
[16:51] <Chipaca> sdhd-sascha: snap tasks --last auto-refresh would be the next thing to look at
[16:55] <pedronis> Chipaca: should we have the chat?
[16:55] <sdhd-sascha> Is it normal, that three times `snap-confine` runs, like this:
[16:55] <sdhd-sascha> ```
[16:55] <sdhd-sascha> $ ps -Af | grep lxd
[16:55] <sdhd-sascha> root        3504       1  0 Jan29 ?        00:00:49 lxcfs /var/snap/lxd/common/var/lib/lxcfs -p /var/snap/lxd/common/lxcfs.pid
[16:55] <sdhd-sascha> root      264698    2355  0 05:10 ?        00:00:02 systemctl start snap.lxd.activate.service
[16:55] <sdhd-sascha> root      264699       1  0 05:10 ?        00:00:00 /bin/sh /snap/lxd/13073/commands/daemon.activate
[16:55] <sdhd-sascha> root      264758  264699  0 05:10 ?        00:00:00 lxd activateifneeded
[16:55] <sdhd-sascha> root     2561183       1  0 17:53 ?        00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
[16:55] <sdhd-sascha> root     2561205 2561183  0 17:53 ?        00:00:00 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
[16:55] <sdhd-sascha> root     2561206 2561183 98 17:53 ?        00:00:21 /snap/core/8592/usr/lib/snapd/snap-confine snap.lxd.daemon /usr/lib/snapd/snap-exec lxd.daemon
[16:55] <sdhd-sascha> root     2561767 2554559  0 17:53 pts/7    00:00:00 sudo systemctl restart snap.lxd.daemon.service
[16:55] <sdhd-sascha> root     2561768 2561767  0 17:53 pts/7    00:00:00 systemctl restart snap.lxd.daemon.service
[16:56] <Chipaca> pedronis: I'll ping mvo and get a cuppa and yes
[16:56] <pedronis> Chipaca: I'm in the standup
[16:56] <mvo> Chipaca: here
[16:57]  * sdhd-sascha I killed all the process. Now it seems to work
[17:40]  * Chipaca resumes all the downloads
[17:45] <mup> PR snapd#8067 closed: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8067>
[18:27] <mup> PR snapcraft#2900 opened: Travis pr snapstore <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2900>
[18:51] <pedronis> Chipaca: I added to your doc
[18:52] <Chipaca> pedronis: thanks
[18:52] <Chipaca> pedronis: I don't think I can wrangle that in tomorrow tho
[18:52] <Chipaca> pedronis: that == the hmac option
[18:52] <pedronis> Chipaca: that's fine, it's not hard to add once we have the basics
[18:52] <pedronis> of the rest
[18:52] <pedronis> HEAD support and resume params
[18:52] <Chipaca> that one i probably can get up tomorrow :)
[18:57] <pedronis> ijohnson: as far as I can tell this are the not yet applied/answered things in #8001: https://github.com/snapcore/snapd/pull/8001#discussion_r368975082 , https://github.com/snapcore/snapd/pull/8001#discussion_r372449659 , https://github.com/snapcore/snapd/pull/8001#discussion_r372451326
[18:57] <mup> PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
[18:58] <ijohnson> pedronis: this is what I have that I'm doing now https://pastebin.ubuntu.com/p/YsN6rDWqq4/
[18:59] <pedronis> sounds right
[18:59] <ijohnson> so I think your 3 things are contained in that
[19:01] <ijohnson> good that we found the same things just about
[21:01] <mup> PR snapcraft#2899 closed: ci: publish the CI built snap to the Snap Store <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2899>