[02:52] <mup> PR snapcraft#2909 closed: elf: search for host libraries within search paths <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2909>
[06:07] <mborzecki> morning
[06:40] <mborzecki> driving kids to school, back in 30
[07:09] <mborzecki> re
[07:55] <mborzecki> pstolowski: hey
[07:55] <pstolowski> mornings
[07:56] <mup> PR snapd#8090 closed: randutil,o/snapstate,-mkauthors.sh: follow ups to randutil introduction <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8090>
[08:21] <mborzecki> mvo: hey
[08:21] <mvo> hey mborzecki
[08:37] <zyga> Still sick. Lucy has 39C all evening. Today somewhat better but we are all still out :/
[08:37] <zyga> I filed paperwork for yesterday till tomorrow
[08:37] <zyga> Fingers crossed it passes
[08:38] <mvo> zyga: I got it now too
[08:40] <pedronis> our tests seem to ger red easily again
[08:40] <zyga> Specific test or all over?
[08:44] <mvo> hm, I see failures in the se-linux-clean test
[08:47] <mborzecki> mvo: meh cannot find any Google image matching "ubuntu-2004-64-uefi-enabled"
[08:47] <mvo> mborzecki: booo :(
[08:47] <mborzecki> mvo: which PR?
[08:48] <mvo> mborzecki: https://travis-ci.org/snapcore/snapd/builds/645891245?utm_source=github_status&utm_medium=notification
[08:48] <mvo> - google:fedora-30-64:tests/main/selinux-clean
[08:48] <mvo>     - google:fedora-31-64:tests/main/selinux-clean
[08:48] <pedronis> mborzecki: did you the notes by Ian
[08:48] <pedronis> he worked on someting based on a snap
[08:48] <mborzecki> pedronis: i'm looking into it already ;)
[08:49] <pedronis> mborzecki: what should we do about #7414 ?
[08:49] <mup> PR #7414: tests: keep track of installed packages and restore the state after the test <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7414>
[08:50] <pedronis> it seems there are request to merge something with *-tool but the tool it mentions don't even exists in master
[08:50] <mborzecki> pedronis: needs reviews, there were some comments about a distro-tool from zyga but i'm not sure we want another *-tool for that, and it's more effort to write one
[08:51] <pedronis> I have mixed feelings about *-tool because quite a few seem to have just one action, so beind called -tool seems obfuscating a bit
[09:09] <zyga> https://forum.snapcraft.io/t/snap-is-updating-off-schedule/15323/2 is interesting - any idea why it might trigger off time
[09:25] <pedronis> we need to investigate, that code is very organic
[09:25] <mborzecki> zyga: two thins we could do, make the log message about the next refresh time be 'info' rather than 'debug', and actually log why refresh is triggered (i.e. by timer, by user request etc.)
[09:26] <mborzecki> heh objcopy --update-section corrupts the initrd :/
[09:31]  * zyga tries to get some sleep
[09:31] <zyga> Have a good day guys
[09:31] <pstolowski> pedronis: hi, Ian found a problem with snap disconnect --forget if only a single arg is given; my implementation of resolvedisconnect over conns is not sufficient, the one from repo is smarter. i need to enhance my variant of resolve - unless we want to require both plug & slot to be passed with --forget. wdyt?
[09:32] <pedronis> pstolowski: they should behave the same
[09:32] <pedronis> but it also sounds that repo code is confusing
[09:33] <pedronis> pstolowski: is there something we can improve overall?
[09:33] <pedronis> pstolowski: my worry here is to have to write clever/confusing code twice as well
[09:34] <pedronis> pstolowski: do you want to chat quickly on this?
[09:36] <pstolowski> pedronis: yes let's chat
[09:37] <pstolowski> pedronis: standup ho?
[09:37] <pedronis> yes, one sec
[10:23] <mborzecki> can snapcraft build a snap with base: core20 in multipass?
[10:25] <pedronis> mvo: sorry for my comment, I will ignore 8085 until you tell me to look again
[10:31] <mvo> pedronis: my bad, sorry! I pused last night but it was not ready
[10:32] <mvo> pedronis: I should have marked that in the PR
[11:24] <mup> Bug #1862007 opened: 'aws-iot-greengrass' snap fails to start due to apparmor <apparmor> <aws> <core> <greengrass> <iot> <libcontainer> <runc> <snap> <ubuntu> <Snappy:New> <https://launchpad.net/bugs/1862007>
[11:37] <pedronis> mvo: do you understand this bug:  https://bugs.launchpad.net/snapd/+bug/1861901 ? is it a misdetection of the change of base?
[11:37] <mup> Bug #1861901: Refreshing a snap using core18 to one using core16 confuses the snap apps <snapd:New> <https://launchpad.net/bugs/1861901>
[11:42] <zyga> pedronis: yes
[11:45] <pedronis> zyga: should I assign it to you, then?
[11:45] <zyga> pedronis: reproduced, there's a mis-detection
[11:48] <mup> Bug #1862007 changed: 'aws-iot-greengrass' snap fails to start due to apparmor deny on mounting of "/proc/latency_stats". [interface/greengrass-support] <apparmor> <aws> <core> <greengrass> <iot> <libcontainer> <runc> <snap> <ubuntu> <snapd:New> <https://launchpad.net/bugs/1862007>
[11:50] <zyga> pedronis: updated the bug
[11:51] <zyga> pedronis: I'll look, it should not be happening
[11:51] <zyga> pedronis: I can look while lucy is sleeping
[11:53] <mvo> thanks pedronis and zyga
[11:57] <zyga> diagnosed, updated the bug as well
[12:05] <zyga> mvo: while the TODO fix is still hard we now have an easy way out
[12:06] <zyga> mvo: I believe this is sufficient to resolve this
[12:06] <zyga> https://www.irccloud.com/pastebin/llLwEMeL/
[12:06] <zyga> I'll add a spread test first, curious why the existing one doesn't spot this
[12:07] <mup> PR snapd#8091 opened: Bug #1862007: 'aws-iot-greengrass' snap fails to start due to apparmo… <Created by dostiharise> <https://github.com/snapcore/snapd/pull/8091>
[12:07] <zyga> perhaps it is a result of our core test setup and repacking
[12:25] <zyga> pedronis, mvo: wrote a regression test, started and going to check on lucy
[12:38] <pedronis> pstolowski: reviewed 7705, some final comments, also it conflicts ATM
[12:38] <pstolowski> pedronis: ah, thanks
[12:38] <mup> PR snapd#8092 opened: timeutil: add a unit test case for trivial schedule <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8092>
[12:46] <mborzecki> cachio: hi
[12:46] <cachio> mborzecki, hi
[12:46] <mborzecki> cachio: can you create a 20.04 uefi enabled image for use in core-20 tests? right not we're using 18.04 but need to pull in some updated packages
[12:47] <cachio> mborzecki, we already have this ubuntu-2004-64-virt-uefi-enabled
[12:47] <cachio> do you need a pr ?
[12:47] <cachio> or you need it in a pr?
[12:47] <mborzecki> no that's fine i can set it locally and check whether the code works
[12:47] <cachio> that you are already coding
[12:54] <mborzecki> cachio: yay, and it works, thanks!
[12:55] <cachio> mborzecki, yaw
[13:20]  * zyga gets back to bed
[13:20] <mup> PR snapd#8093 opened: cmd/snap-confine: detect base transitions on core16 <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8093>
[13:20] <zyga> pedronis, mvo: ^
[13:20] <zyga> mvo: I marked this as aiming at 2.44
[13:20] <zyga> mvo: but feel free to retarget
[13:57] <ijohnson> mborzecki: so are you still going to use the ubuntu-core-initramfs snap I made or is the plan still to use your manual object manipulation unpacking/repacking ?
[13:59] <mvo> zyga: thank you
=== ricab is now known as ricab|lunch
[14:26] <zyga> https://www.irccloud.com/pastebin/cBgVrHKy/
[14:27] <zyga> mvo: ^
[14:32] <mborzecki> cachio: can you point me to the logs with the link-snap problem?
[14:32] <cachio> https://paste.ubuntu.com/p/TYVdsbbCQm/
[14:32] <ijohnson> mborzecki: I merged your PR to ubuntu-core-initramfs-snap and it's been released on edge now
[14:33] <pstolowski> cachio: #8046 is ready for re-view if you have some time
[14:33] <mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[14:33] <cachio> https://paste.ubuntu.com/p/sPZCNnXMcr/
[14:33] <cachio> mborzecki, I already have a debug session here
[14:33] <mborzecki> ijohnson: cool, thanks
[14:33] <cachio> mborzecki, if you need any other info just ping me
[14:33] <cachio> pstolowski, nice, I'll take a look
[14:34] <mvo> zyga: importing internal yield an error for me
[14:34] <zyga> mvo: my point was the docstring, not the code, the code is used internally anyway
[14:36] <mvo> zyga: aha, I see
[14:38] <mborzecki> cachio: can you paste the contents of /var/lib/snapd/sequence/snapd.json?
[14:38] <mborzecki> ijohnson: trying with `rm -rf firmware/*` xD
[14:41] <ijohnson> mborzecki: :-) good luck!
[14:41] <sdhd-sascha> Hi, does anybody has an idea, how to push/delete an git tag on github. With the name of "refs/heads/master" ?
[14:42] <cachio> mborzecki, {"sequence":[{"name":"snapd","snap-id":"PMrrV4ml8uWuEUDBT8dSGnKUYbevVhc4","revision":"6240","channel":"beta"}],"current":"6240"}
[14:42] <sdhd-sascha> To delete other git tags, on remote git, was no problem...
[14:45] <sdhd-sascha> Not sure, how i could create a tag with this name ... "refs/heads/master"
[14:46] <sdhd-sascha> https://github.com/sd-hd/termite-snap/tree/refs/heads/master
[14:49] <cjwatson> sdhd-sascha: git push --delete <name of remote that you normally use to push> refs/tags/refs/heads/master
[14:50] <roadmr> jdstrand: yay, tools 20200203-1915UTC are now in production in the store
[14:50] <cjwatson> remote name might be "origin", dunno, depends how your local tree is set up
[14:50] <jdstrand> roadmr: thanks! :)
[14:51] <sdhd-sascha> cjwatson: thank you :-) seems to work
[14:51] <mup> PR snapd#8094 opened:  tests: repack thethe initramfs + kernel snap for UC20 spread tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8094>
[14:52] <mborzecki> ijohnson: opened to #8094 to see if it makes a difference, something must start t work at some point :)
[14:52] <mup> PR #8094:  tests: repack thethe initramfs + kernel snap for UC20 spread tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8094>
[14:52] <mborzecki> ijohnson: it'd be better to make 8069 work though
[14:53] <ijohnson> mborzecki: did that get you a booting image on gce though?
[14:53] <ijohnson> or is this just to try
[14:53] <mborzecki> ijohnson: it's still running here
[14:53] <ijohnson> mborzecki: ah
[14:54] <mborzecki> it'd be nice to just go with the necessary modules, drop the rest and depmod to make sure what's left is consistent
[15:04] <ijohnson> oh also mborzecki re: building core20 snaps, snapcraft doesn't support it right now unfortunately
[15:04] <mborzecki> ijohnson: so the image boots and seeds fine without firmware locally under qemu
[15:04] <mborzecki> ijohnson: figured, i built eventually in 20.04 vm with --provider=host --destructive-sthsth
[15:05] <ijohnson> what I do is a bit tricky is `lxc launch ubuntu-daily:20.04 snapcraft-$SNAP_NAME` and then on your host do `snapcraft --use-lxd` and snapcraft will bootstrap the lxc container but still fail somewhere, but then your host tree is mounted inside the container and you can modify stuff on the host and build within the container with just `lxc exec snapcraft-$SNAP_NAME cd project && snapcraft --destructive-mode`
[15:06] <mborzecki> ijohnson: heh, spread timeout, maybe it's seeding that long after all
[15:07] <ijohnson> mborzecki: hmm can you try changing the timeout? spread should be able to ssh into it even if seeding fails IIUC
[15:07] <mborzecki> ijohnson: removing firmware makes the time from `Preparing google:ubuntu-core-20-64` to rebooting go down from 13minutes to just under 7 minutes
[15:07] <ijohnson> wow nice!
[15:10] <pedronis> mborzecki: #7588 is the PR I mentioned that needs a 2nd review
[15:10] <mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
[15:11] <mborzecki> pedronis: cool, thanks
[15:16] <ijohnson> cachio: is there a way to see the console when we reboot on gce via spread ? i.e. see early boot messages and the like before the machine is available via SSH
[15:21] <cachio> ijohnson, yes
=== ricab|lunch is now known as ricab
[15:26] <mborzecki> ijohnson: hm got the kernel snap down to 29MB, still booting and seeding
[15:27] <mborzecki> cachio: about that failure, it looks like this failed while installing snapd for the first time
[15:27] <mborzecki> cachio: was it past seeding?
[15:32] <cachio> mborzecki, you mean snapd snap could not be installed correctly initially?
[15:33] <cachio> mborzecki, should wait until snapd is fully seeded to run the tests?
[15:34] <ijohnson> mborzecki: nice, I'm looking at your spread run for that new PR, cachio got me logs, doesn't look like it's tried to reboot yet
[15:46] <mborzecki> cachio: can you access the console of feb051525-057526 node?
[15:47] <cachio> mborzecki, yes
[15:48] <cachio> mbI am already connected
[15:48] <cachio> mborzecki,  I am already connected
[15:48] <mborzecki> cachio: to the device?
[15:48] <cachio> mborzecki, yes
[15:48] <cachio> I see -> flash-all-snaps
[15:49] <cachio> in the menu
[15:49] <cachio> grub version 2.04
[15:50] <mborzecki> cachio: screenshot?
[15:51] <cachio> mborzecki, sent
[15:51] <cachio> check telegram :)
[15:53] <ijohnson> mborzecki: I noticed this in the console after it tries to reboot: `error: file '/vmlinuz' not found.`
[15:54] <ijohnson> why would it be trying to boot /vmlinuz ?
[15:55] <ijohnson> cachio: do you know if gce uefi first boots it's own grub then chainloads to our grub?
[15:56] <mborzecki> hmmmm unexpected, and flash-all-snaps?
[15:56] <cachio> ijohnson, no idea
[15:56] <ijohnson> yeah I dunno what this flash-all-snaps is
[15:56] <mborzecki> is it using the right gadget?
[15:56] <ijohnson> ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
[15:56] <ijohnson> it's mvo's fault :-)
[15:57] <ijohnson> the reflash magic script has a miny grub.cfg that tries to load /vmlinuz but that's not there now
[15:57] <ijohnson> see line 793ish of prepare.sh
[15:57] <cachio> :)
[15:58] <ijohnson> hmm I wonder what the right thing to do now then is
[15:58] <mborzecki> pffff
[15:58] <mborzecki> hmmmmm we coudl do soemthing weird
[15:59] <mborzecki> like pivot to a tmpfs rootfs, wipe and reboot?
[15:59] <ijohnson> I think all we need to do is probably just to change the linux and initrd parameters for uc20 in that mini grub.cfg
[16:02]  * cachio lunch
[16:03] <jdstrand> ijohnson: re test-snapd-ubun
[16:03] <jdstrand> meh
[16:03] <jdstrand> ijohnson: re test-snapd-ubuntu-core-initramfs: wouldn't kernel-module-observe be sufficient for reading kernel modules?
[16:04] <mvo> ijohnson: oh, fun!
[16:04] <mvo> ijohnson: nice catch
[16:05] <ijohnson> jdstrand: well so the snap doesn't actually need to read the system's kernel modules, I think it will most of the time be reading modules that are put somewhere in $HOME, etc. because it's a dev tool used on already assembled kernel snaps, but the denial I was seeing was from using depmod or some other tool which wanted to read some things from the host system
[16:06] <ijohnson> jdstrand: I did add a layout for one thing that it was trying to read so it read the thing I wanted it to and not the host system's, so perhaps that should be done for the other access as well and then it doesn't need hardware-observe
[16:06] <mup> PR snapcraft#2875 closed: split debug information <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2875>
[16:06] <mup> PR snapcraft#2910 opened: [experimental] debug splitting <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2910>
[16:06] <ijohnson> jdstrand: but this is just a test snap to try and unblock uc20 spread testing, but there is a longer term plan on what to do with the ubuntu-core-initramfs snap from xnox and foundations, so perhaps they would be better suited to answer whether kernel-module-observe makes sense for that snap
[16:07] <ijohnson> mvo: :-) yes it all makes sense now
[16:07] <jdstrand> ijohnson: what is the denial that you saw that made you want to use hardware-observe? the justification in the forum was "This package requires access to reading kernel modules on the system". That is what kernel-module-observe is for
[16:08] <jdstrand> ijohnson: I'm prepared to grant the request immediately. I just want to know if there is a bug in the kernel-module-observe interface
[16:08] <ijohnson> jdstrand: tbh I don't remember, something that was only found in hardware-observe like /etc/modprobe.d maybe ?
[16:08] <mborzecki> ijohnson: i'm leaving for a meetup, can you push the update to both PRs?
[16:08] <jdstrand> ijohnson: that is in kernel-module-observe
[16:08] <ijohnson> mborzecki: yes I'll sort out what to do about that when I figure out the right thing to do
[16:09] <mborzecki> ijohnson: got some tweaks that drop firmware and modules if you want to try that https://paste.ubuntu.com/p/zmBfpZYWNs/, prepare -> reboot takes 4 minutes now
[16:09] <jdstrand> ijohnson: I'm willing to fast track this, but it puts me in an awkward position that the justification is for something that is supposed to be handled by another interface
[16:10] <ijohnson> jdstrand: it's entirely possible that I went searching for an interface that unblocked the snap and just found hardware-observe first and went with that
[16:10] <ijohnson> jdstrand: if you'd rather I use kernel-module-observe I can do that instead
[16:11] <jdstrand> ijohnson: please do and I'll grant it. I'll comment in the topic. if you need something more, post in the topic and we can go from there (allowing auto-connect of hardware-observe if needed until the bug is fixed)
[16:12] <ijohnson> jdstrand: one more wrinkle that perhaps you'd rather deal with now, is that I named the snap test-snapd-ubuntu-core-initramfs because ubuntu-core-initramfs is reserved, and I just wanted to get it working ASAP and so didn't go through the process of requesing that name, would you rather we try to go through that process before granting kernel-module-observe instead?
[16:13] <jdstrand> ijohnson: I don't have a problem with the name
[16:13] <ijohnson> jdstrand: ok give me a few minutes to re-build the snap, not sure if upload to the store will get blocked on kernel-module-observe or not
[16:13] <jdstrand> ijohnson: I'll unblock you. if you end up renaming it for your own reasons, just ping me
[16:14] <jdstrand> ijohnson: it won't
[16:14] <jdstrand> (it isn't superprivileged)
[16:14] <ijohnson> jdstrand: thanks
[16:14] <jdstrand> ijohnson: but you also now have auto-connect
[16:16] <ijohnson> jdstrand: alright it's building somewhere up in the clouds now and should be released shortly, I guess the declaration doesn't need a revision uploaded with that plug in order to be granted then?
[16:16] <jdstrand> ijohnson: nope
[16:16] <ijohnson> cool
[16:18] <mup> PR snapd#7490 closed: interfaces/app-launch: support confined snaps launching other snaps <Needs Samuele review> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7490>
[16:19] <pedronis> cachio: what's the status of #7983
[16:19] <mup> PR #7983: tests: adding more tests to core20 test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7983>
[16:22] <cachio> pedronis, needs reviews
[16:22] <cachio> I already answer the questions on that one
[16:48] <ijohnson> pstolowski: do I need to review #8046 before #7705 or vice versa?
[16:48] <mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
[16:48] <mup> PR #7705: o/devicestate: handle preseed in firstboot <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7705>
[16:48] <ijohnson> not sure which PR I should start with
[16:48] <pstolowski> ijohnson: #7705 first
[16:48] <ijohnson> pstolowski: ack thanks
[16:48] <pstolowski> thank you!
[17:24] <pedronis> mvo: should I re-review 8085, or is not ready yet? skimming it still looks disaligned from udevmonitor
[17:27] <mvo> pedronis: it's still a bit disalinged my feeling is that udevmonitor could be simplified but maybe worth a look, then you can tell me what I missed in 8085 :)
[17:28] <mvo> pedronis: what I mean is that if 8085 looks reaonable I could simplify udevmonitor
[17:30] <pedronis> mvo: I made some comments in 8085
[17:30] <pedronis> feel free to counter-comment, though the point on Stop waiting is kind what we always do
[17:33] <pedronis> mvo: actually I'm quite confused by the new code
=== ijohnson is now known as ijohnson|lunch
[17:51] <pedronis> mvo: I added a comment that maybe helps, sorry if I was confusing before
[18:13] <mup> PR snapd#8008 closed: render: add the render package and basic widgets <Needs Samuele review> <⛔ Blocked> <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8008>
[18:17] <pedronis> mvo: did you see this comment: https://github.com/snapcore/snapd/pull/8085#discussion_r375410680 ?
[18:17] <mup> PR #8085: [RFC] netutil: add default gateway monitor <Created by mvo5> <https://github.com/snapcore/snapd/pull/8085>
=== ijohnson|lunch is now known as ijohnson
[19:02] <mvo> pedronis: thank you, having a look now
[19:02] <pedronis> mvo: I'm trying locally, and what I have in mind doesn't quite work
[19:02] <mvo> pedronis: yeah, this puzzled me
[19:03] <mvo> pedronis: I assumed (naively) that closing the fd would stop the read
[19:03] <mvo> pedronis: but this does not work, hence the comment, but maybe I'm just missing something
[19:04] <mvo> pedronis: fwiw, it seems it's similar in C (https://gist.github.com/mvo5/902a2bedd201cf4670a630b8db4f9171) but again, I'm not at my best today so maybe it's something else. in any case, I suspect that the netlink code we already have has the same issue but we never tested for this
[19:04] <mvo> pedronis: (and sorry that this is a bit of a rathole :(
[19:04] <pedronis> mvo: well, man of close kind of says not to do this (close from different thread)
[19:05] <mvo> pedronis: it does but it's also a bit vague. anyway, a net.FileCon solves this nicely but it's not supported for netlink sockets :(
[19:06] <mvo> pedronis: (AIUI net uses epoll internally so they notice the change in the fd)
[19:06] <mvo> pedronis: the alternative would be to use syscall.Select() on the ns.netlinkFd but that quite annoying to do in go it seems
[19:06] <mvo> pedronis: anyway, sorry for my rambling
[19:07] <pedronis> mvo: why FileConn doesn't work?
[19:07] <mvo> pedronis: it checks internally for the type of connection, let me try to find you the code
[19:07] <mvo> pedronis: https://golang.org/src/net/file_unix.go?s=1840:1887 (line 42ff)
[19:08] <mvo> pedronis: it checks the peer and the netlink connection is syscall.SockaddrNetlink which is not covered there
[19:08] <mvo> pedronis: it's annoying because my testcode (the mock uses a AF_UNIX) works fine with the FileConn just not the real thing
[19:33] <mup> PR snapd#8095 opened: snap-bootstrap: add tpm support <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8095>
[19:51] <mup> PR snapcraft#2904 closed: meta: move Snap's from_dict() system-username parsing into SystemUser <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2904>
[20:26] <mup> PR snapd#8096 opened: tests: skip itnerfaces-udisks on ubuntu-20.04-64 due to timing issue <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8096>
[21:27] <mup> PR snapcraft#2880 closed: package management repository configuration <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2880>
[21:30] <mup> PR snapcraft#2911 opened: [experimental] package-management repository configuration <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2911>
[21:59] <diddledan> I made a thing to work alongside jamesh's build and publish GitHub Actions: https://github.com/diddlesnaps/snapcraft-review-action