[07:12] <mborzecki> morning
[07:46] <mup> PR snapd#9921 closed: boot: helper for setting up a try recover system  <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9921>
[07:49] <zyga> good morning
[08:04] <pstolowski> morning
[08:05] <mborzecki> pstolowski: mvo: hey
[08:08] <mvo> good morning pstolowski and mborzecki ! happy monday
[08:11] <pstolowski> o/
[08:18] <zyga> good morning mvo :)
[08:29] <mvo> good morning zyga, happy monday to you as well!
[08:36] <zyga> going downstairs to set up some recording, I'll be back in the afternoon
[09:18] <pstolowski> oh well, snapshot tests mock too much...
[09:57] <mborzecki> anyone seen this? https://paste.ubuntu.com/p/Vb9jzgR5Zx/
[10:16] <mborzecki> mvo: ^^ looks like core-initrd was changed and our kernel repacking is broken now
[10:16] <mvo> mborzecki: it was changed, yes
[10:17] <mvo> mborzecki: check https://github.com/snapcore/core-initrd/commits/main
[10:17] <mborzecki> that's probably the changes for having more modules in the server builds
[10:17] <mborzecki> mvo: yeah, i suspect it's this commit: https://github.com/snapcore/core-initrd/commit/9ca7436f821f0e2d37874fd217407275f1e24e3c
[10:18] <mvo> mborzecki: yeah
[10:37] <mup> PR snapd#10008 opened: tests/lib/prepare: fix repacking of the UC20 kernel snap for with ubuntu-core-initramfs 40 <Run nested> <Simple 😃> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10008>
[10:39] <mborzecki> mvo: ^^
[10:45] <mvo> mborzecki: thanks, checking
[10:46] <mvo> mborzecki: I cced you on a question about appamror confinement partil vs full, I think I got the right answer but if it looks strange let me know (no need to deep dive)
[10:47] <mvo> mborzecki: \o/ thanks for the fix!
[10:59] <mborzecki> mvo: it looks correct
[11:13] <mup> PR snapcraft#3464 closed: meta: add support for `kernel.yaml` for kernel snaps <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3464>
[11:37] <mup> PR snapd#9994 closed: tests: improve tests documentation - part 2 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9994>
[11:49] <mborzecki> mvo: pushed a couple more fixes to #10008
[11:49] <mup> Bug #10008: Automatic configuration of wireless pcmcia card does not work <pcmcia-cs (Ubuntu):Invalid> <https://launchpad.net/bugs/10008>
[11:49] <mup> PR #10008: tests/lib/prepare: fix repacking of the UC20 kernel snap for with ubuntu-core-initramfs 40 <Run nested> <Simple 😃> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10008>
[12:13] <mup> PR snapcraft#3465 opened: [backport] store: improve platform detection (#2931) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3465>
[12:19] <pstolowski> mvo:  #10007 is ready for reviews
[12:19] <mup> Bug #10007: HD drive very slow when no cd inserted whith kernel 2.6 and Gnome 2.6 or 2.8 <linux-source-2.6.15 (Ubuntu):Invalid> <https://launchpad.net/bugs/10007>
[12:19] <mup> PR #10007: o/configstate, o/snapshotstate: fix handling of nil snap config on snapshot restore <Bug> <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10007>
[12:35] <ijohnson> morning folks
[12:36] <diddledan> o/
[12:36] <ijohnson> hey diddledan
[12:37] <diddledan> the snap store is being a pain (has been for days) https://usercontent.irccloud-cdn.com/file/Jf25WrzK/image.png
[12:38] <ijohnson> yeah entirely possible, we had to push out a new snapd/core snap which has a tendency to slow down things, hopefully this week it is better though
[12:38] <diddledan> I'm sure my snap being 2.5 GB isn't helping
[12:39] <diddledan> (CUDA libraries are huge!)
[12:39] <ijohnson> oh yeah that definitely is a problem, I seem to recall that snaps over 1 GB are very finnicky to upload
[12:46] <diddledan> tis a good job I don't have a data cap with the number of times I've got to 99%
[12:47] <ijohnson> haha yeah that would really sting if you had a data upload cap too
[12:47] <ijohnson> mvo: not sure when I mentioned it last week, but for example today I see we only have one single PR running via github actions workers: https://github.com/snapcore/snapd/actions?query=is%3Ain_progress but many, many queued jobs
[12:47] <ijohnson> I think we have some github actions self hosted runners offline
[12:49] <diddledan> self-hosted runners for the win though (I have one here at home ;-))
[12:49] <ijohnson> yeah they are great except when you realize you now are doing devops :-|
[12:50] <diddledan> true
[12:50] <diddledan> <insert yo dawg, I heard you like devops meme here>
[12:51] <ijohnson> haha
[13:13] <mborzecki> ijohnson: yeah, not sure how to even see how many runners are up at this point
[13:13] <mborzecki> mvo: can you see it?
[13:13] <ogra> diddledan, you should try to find that norwegian guy (peer) that resets your connection and tell him to stop that !
[13:13] <ijohnson> mborzecki: yeah real annoying with that u-c-i bug you found this morning too
[13:13] <mborzecki> ijohnson: and it's stuck in the actions queue ;)
[13:13] <diddledan> peer is an ass
[13:13] <ogra> totally !
[13:18] <cachio_> ijohnson, hi
[13:19] <cachio_> ijohnson, did you see this error= https://github.com/snapcore/snapd/pull/9997/checks?check_run_id=2055837552#step:5:547
[13:19] <mup> PR #9997: tests: update details on task.yaml files <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9997>
[13:19] <ijohnson> hey cachio_ let me have a look
[13:20] <cachio_> it started on friday I think
[13:20] <ijohnson> cachio_: that is the issue that mborzecki is fixing, but we are stuck waiting for github actions workers to run this PR: https://github.com/snapcore/snapd/pull/10008
[13:20] <mup> PR #10008: tests/lib/prepare: fix repacking of the UC20 kernel snap for with ubuntu-core-initramfs 40 <Run nested> <Simple 😃> <⚠ Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10008>
[13:20] <cachio_> I already fixed the github actions agents
[13:20] <cachio_> mvo, hi, is any of the agents offline?
[13:21] <cachio_> ijohnson, ah, nice
[13:22] <cachio_> I'll check again the workers
[13:22] <cachio_> I fixed that on friday
[13:23] <ijohnson> thanks cachio
[13:32] <mvo> cachio_: I see a lot of prodstack offline, eg prodstack-a-45 to 76 (some isolted idle ones in their though)
[13:33] <cachio_> mvo, thnaks
[13:33] <cachio_> qc
[13:34] <mvo> ijohnson, mborzecki I can see some stat about the runners but not super many, I see a good bunch of stuff online but also quite a few offline
[13:34] <ijohnson> mmm that's unfortunate
[13:36] <zyga> hey guys
[13:37] <zyga> oh, workers down?
[13:37] <ijohnson> something like that
[13:37] <zyga> I learned one interesting thing the other day
[13:38] <zyga> gitlab can run CI for projects that are hosted on githu
[13:38] <zyga> *github
[13:38] <zyga> so you can use the somewhat more powerful pipeline system and easily host your workers (and scale them)
[13:38] <zyga> as the provisioning process is a bit better there
[13:38] <zyga> you could even auto-scale with juju
[13:55] <ijohnson> yeah maybe gitlab is nice, but I doubt we have any time to switch
[13:56] <diddledan> a downside of gitlab-ci is there is no inbuilt concept of a `matrix`
[14:00] <zyga> diddledan that's true but I don't see that as a major flaw or limitation
[14:00] <zyga> you can easily create that with .extends
[14:00] <zyga> I think that having a native matrix would be nice to unclutter more complex pipelines
[14:01] <zyga> but I'm still learning that, and there are parts I did not explore
[14:01] <zyga> like pipeline triggering and subscription, that allow for even more composition
[14:02] <diddledan> I like the ability to include/import pipeline stuff from external files/repos
[14:02] <diddledan> that really helps when you have multiple projects that all need the same or similar pipelines
[14:04] <zyga> yeah, that's true
[14:04] <zyga> salsa has a very nice and featureful pipeline for packaging
[14:04] <zyga> in my current work I'm setting up reusable pipelines that are easy to include into various repos
[14:05] <zyga> it's not far off from github actions
[14:05] <zyga> but actions are not so composable as you can only define one step, and not a larger chunk
[16:10]  * cachio lunch
[17:55] <cachio> ijohnson, hey, about the PR #9960 do you have any update?
[17:55] <mup> PR #9960: tests: update permission denied message for test-snapd-event on ubuntu 2104 <⛔ Blocked> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9960>
[17:55] <cachio> should we skip that test?
[17:55] <ijohnson> cachio: no not yet, but we should not skip that test on 21.04
[17:55] <ijohnson> cachio: is that test blocking beta certification of 2.49.1 ?
[17:56] <cachio> ijohnson, no
[17:56] <ijohnson> yeah let's leave the test as-is for now, I will check in on it today after lunch
[17:56] <cachio> as 21.04 is in red
[17:56] <cachio> I want to know what to do with that one
[17:56] <cachio> ijohnson, I'll wait in that case, thanks
[18:39] <diddledan> popey: if I register cuda-runtime-11-2-1804, would it be ok to organise to add it to snapcrafters with a view to making it a content-snap for anybody to use?
[18:40] <diddledan> (I'm trying to work around the store bailing out because my snap is huge)
[18:42] <diddledan> well I registered it anywho :-p
[19:49] <cachio> ijohnson, hi
[19:49] <cachio> quick question
[19:49] <ijohnson> hey cachio
[19:49] <cachio> I install the snap test-snapd-sh and then I remove it
[19:50] <cachio> it is ok if:
[19:50] <cachio> ls /sys/fs/cgroup/devices/snap.test-snapd-sh.sh/
[19:50] <cachio> cgroup.clone_children  cgroup.procs           devices.allow          devices.deny           devices.list           notify_on_release      tasks
[19:50] <cachio> it remains there?
[19:51] <ijohnson> cachio: that's a bug where we don't remove/cleanup the device cgroup for a snap after it's removed
[19:51] <ijohnson> I filed that a while ago, let me see if I can find the bug
[19:52] <ijohnson> cachio: see https://bugs.launchpad.net/snapd/+bug/1803210
[19:52] <mup> Bug #1803210: snap's device cgroup is not discarded upon uninstall <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1803210>
[19:52] <cachio> ijohnson, ok, because I have a test failing and not sure if it could be related to that
[19:53] <ijohnson> cachio: how is the test failing?
[19:53] <cachio> ijohnson, https://paste.ubuntu.com/p/nWQS6DnZFd/
[19:54] <cachio> don't know if the test clean up is bad
[19:54] <ijohnson> cachio: yeah we probably need that test to clean itself up
[19:54] <cachio> or something is not working properly when we remove a snap
[21:58] <mup> PR snapcraft#3466 opened: store: do not unnecessarily catch/rewrite exceptions <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3466>
[22:55] <mup> PR snapd#10009 opened: boot: export bootAssetsMap as AssetsMap <Simple 😃> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10009>
[22:55] <mup> PR snapd#10010 opened: boot/assets.go: add InstallObserverOptions to allow providing previous assets <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10010>
[23:58] <mup> PR snapcraft#3467 opened: gitignore: sort list <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3467>
[23:59] <diddledan> well fooey