[03:10] <mup> PR snapd#10758 opened: image/image_linux.go: add newline <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10758>
[05:00] <mborzecki> morning
[05:43] <mardy> 'morning!
[06:04] <mborzecki> what a mess with boltdb, upstream was forked once, then since coreos became part of rh, it got moved again
[06:05] <mborzecki> some distros have packages of the intermediate location (at github/coreos), but not the new one at etcd
[06:05] <mborzecki> and ofc go get github.com/coreos/bbolt fails because github redirects coreos to etcd-io for this repo go get github.com/coreos/bbolt
[06:05] <mborzecki> https://paste.ubuntu.com/p/nHbSR4V5qK/
[06:26] <mardy> mborzecki: about your suggestion for the systemdTooOldError: should I actually make it public (and probably call it TooOldError, since we have the package prefix anyway)?
[06:28] <mborzecki> mardy: probably doesn't need to be public, if you really want to check if it's that specific error you can have `func IsSystemdTooOld(err error) { _, ok := err.(*systemdTooOldError); return ok }` ?
[06:28] <mardy> mborzecki: your suggestion would actually allow us to use systemd.EnsureAtLeast() here too: https://github.com/snapcore/snapd/blob/master/usersession/userd/privileged_desktop_launcher.go#L98-L110
[06:28] <mardy> but that requires the error to be public, I guess
[06:29] <mardy> mborzecki: ah, ok, if you think that IsSystemdTooOld() is better, I'll go with that
[06:53] <mborzecki> hmm broke remodel, fixed remodel
[07:04] <pstolowski> morning
[07:14] <mardy> pstolowski: hi!
[07:16] <mvo> good morning pstolowski and mardy and mborzecki 
[07:16] <mborzecki> mvo: pstolowski heya
[07:21] <mup> PR snapd#10688 closed: configcore: add read-only netplan support <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10688>
[07:21] <mup> PR snapd#10757 closed: build-aux: stage libgcc1 library into snapd snap <cherry-picked> <Created by mwhudson> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10757>
[08:12] <mardy> mvo: hi!
[08:18] <mborzecki> even dropped a little reactor of remodel tasks, meh that code was nasty, still is but a just a little less
[08:38] <mwhudson> mvo, mborzecki: how often does the snapd snap get updated in stable, out of curiousity?
[08:39] <mvo> mwhudson: in theory every 4 weeks, in pratice it's a lot more volatile because we recently got a lot "dot" releases for customers
[08:39] <mwhudson> mvo: ok
[08:40] <mvo> mwhudson: why (just out of curisoity)
[08:40] <mwhudson> mvo: somehow that libgcc_s.so.1 thing is making snapd autopkgtests fail
[08:41] <mwhudson> https://autopkgtest.ubuntu.com/packages/s/snapd/impish/amd64
[08:41] <mvo> mwhudson: oh, we will do a new 2.52 soon, I can also upload out-of-band releases to impish if that is needed (but in a meeting right now so let's chat in a bit what I can do to help :)
[08:41] <mwhudson> mvo: it's really the snapd snap, not the package in impish (afaict)
[08:42] <mvo> mwhudson: uh, ok
[08:45] <mwhudson> at least that's what https://bugs.launchpad.net/snapd/+bug/1943077 says
[08:45] <mup> Bug #1943077: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s <update-excuse> <snapd:New> <openssh (Ubuntu):New> <squashfs-tools (Ubuntu):New> <https://launchpad.net/bugs/1943077>
[09:11] <mup> PR snapd#10725 closed: o/hookstate: require snap-refresh-control interface for snapctl refresh --proceed <Needs Samuele review> <Refresh control> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/10725>
[09:41] <mborzecki> mvo: thanks for updating snapcore/bolt, i've updated https://github.com/snapcore/snapd/pull/10754 and we'll see how it fares now
[09:41] <mup> PR #10754: tests/lib/prepare-restore: make sure that package build is done without network access <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10754>
[09:47] <mup> PR snapd#10759 opened: tests: be more robust against a new day stepping in <Created by mardy> <https://github.com/snapcore/snapd/pull/10759>
[09:48] <mvo> mborzecki: \o/
[09:48] <mvo> mborzecki: our of curiosity, was a "go get -u" enough for tihs?
[09:49] <mborzecki> mardy: cannot approve your pr sorry 🙂 you're missing a reference to https://www.youtube.com/watch?v=NaGLVS5b_ZY
[09:49] <mborzecki> mvo: heh no, had to go get -u github.com/snapcore/bolt@master otherwise it just picked another tag with v1.3.x
[09:50] <mvo> mborzecki: oh nice, good to know!
[10:01] <laney> quick one (I'm ok filing a bug if there isn't one). seeding is failing on a new impish install like this: https://paste.debian.net/1211056/ - is this known, and can anyone provide me with a workaround for now? :-)
[10:02] <mborzecki> laney: does /etc/apparmor.d/abstractions/base exist?
[10:04] <laney> mborzecki: erm WTF
[10:04] <laney> laney@sherwood:/etc/apparmor.d/abstractions$ ls -l
[10:04] <laney> ls: cannot access 'base': No such file or directory
[10:05] <laney> and... -????????? ? ?    ?       ?            ? base
[10:05] <mborzecki> laney: hmm https://packages.ubuntu.com/impish/amd64/apparmor/filelist there is /etc/apparmor.d/abstractions/base, borked fs?
[10:06] <laney> looks like something weird happening here
[10:06] <laney> let me poke, thanks for the pointer
[10:08] <mborzecki> mvo: so not it's looking for: https://github.com/canonical/go-sp800.90a-drbg
[10:10] <mborzecki> apparently it's needed by secboot, but it's listed in go.mod, so why earlier go mod vendor did not fill that dependency?
[10:10] <mvo> mborzecki: that is interessting, I have no idea why it's missing from go mod :/
[10:11] <mvo> mborzecki: maybe conditional somehow via buildflags?
[10:11] <mborzecki> mvo: well it's listed there as an indirect dependency, but i'm not sure why go mod vendor has not fetched the repo
[10:11] <mardy> mborzecki: :-D
[10:57] <mup> PR snapd#10760 opened: o/snapstate: support ignore validation flag on install/update <⛔ Blocked> <Needs Samuele review> <validation-sets :white_check_mark:> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10760>
[11:17] <mborzecki> mvo: ok, so i got something about that build problem, we have a buch of `//go:generate` which invokes go run, or runs a script (update-pot) which in turn runs go install without all the flags
[11:22] <jdstrand> amurray: hey, mentioning this as a reminder to folks of why we might not autoconnect something that most snaps don't need even if on the surface it seems like it wouldn't be a problem: https://ubuntu.com/security/CVE-2021-3612 (joystick interface)
[11:34] <mardy> mvo: can you merge this? https://github.com/snapcore/snapd/pull/10653 Or should I rather retry the build, since if failed on so many machines (looks like I hit a multitude of unlucky situations :-D)
[11:34] <mup> PR #10653: mount-control: step 1 <Needs Samuele review> <Created by mardy> <https://github.com/snapcore/snapd/pull/10653>
[11:47] <amurray> hey jdstrand :) - that is a great example - I recall asking you that very question once and you explained it really well at the time
[11:47] <mup> PR snapd#10761 opened: o/snapstate: optimize conflicts around snaps stored on conditional-auto-refresh task <Refresh control> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10761>
[12:27] <mup> PR snapd#10762 opened: o/servicestate: Update task summary for restart action <Created by mardy> <https://github.com/snapcore/snapd/pull/10762>
[12:57] <mup> PR snapd#10763 opened: tests: pre-cache snaps in classic and core systems <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10763>
[13:34]  * pstolowski lunch
[13:43] <jdstrand> amurray: oh, heh, I forgot we discussed that, hehe. Yeah, any device is kernel attack surface. I can't recall a CVE in the joystick driver before this one, but I'm always like "but what if there was one?" :)
[14:05]  * cachio afk
[14:07] <mup> PR snapd#10741 closed: interfaces/block-devices: support to access the state of block devices <Skip spread> <cherry-picked> <Created by woodrow-shen> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10741>
[14:13] <ijohnson[m]> @bboozzoo hey I was wondering would it "simplify" things if we just imported github.com/etcd.io/bolt directly in our go.mod, then used the "replace" directive on specific distros that don't have a package for that module to redirect our import of that module to one that is installed locally via distro pkg? I don't recall the semantics around replace working with modules that declare themself as a differently named module
[14:15] <mborzecki> ijohnson: yeah, that could work, we may need to patch some things on fedora maybe?
[14:15] <mborzecki> worth a try anyway
[14:15] <ijohnson[m]> yeah I was just wondering if that would be easier to add/remove that go.mod line than to mess around with the fork and things
[14:19] <mborzecki> ijohnson: also, despite having go.mod inside the repo, we can build without modules for now, tbh i don't see how go upstream will make building packages across various linux distros withouth either patching go.mod to update versions automatically or allowing people to disable modules altogether
[14:20] <mborzecki> especially as some distros are really adamant to vendoring random dependencies
[14:28] <mborzecki> ijohnson: (cc mvo) i've pushed a patch to https://github.com/snapcore/snapd/pull/10754 please take a look, once it lands LP builds will hopefully be fine again
[14:28] <mup> PR #10754: packaging, tests/lib/prepare-restore: build packages without network access, fix building debs with go modules <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10754>
[14:28] <ijohnson[m]> @bbo
[14:29] <ijohnson[m]> gah
[14:29] <mvo> mborzecki: nice, thank you
[14:29] <ijohnson[m]> @bboozzoo thanks will take a look
[14:29] <ijohnson[m]> I like fluffychat as a snap matrix client but it doesn't seem to do username autocomplete via the tab key which is unfortunate
[14:30] <mborzecki> ijohnson: i use element web interface, and sometimes gnome client called 'fractal'
[14:31] <ijohnson[m]> I used to use element but I wanted to try out something else, element works pretty well though
[14:31] <ijohnson[m]> I'll have to give fractal a try though
[14:34] <ijohnson[m]> ah nice well fractal does seem to do username autocomplete with tab key so that's nice, but fluffychat looks a bit nicer IMHO
[14:37] <mardy> pstolowski: you are the servicestate expert, I guess: do you know what I should do in the unit tests, so that snapstate.Get() will return a snap? (it returns err here)
[14:38] <pstolowski> mardy: sure. snapstate.Set(...), you will find plenty of that in other unit tests
[14:39] <pstolowski> mardy: sometimes some tests have helpers that create snap.yaml on the disk *and* entry in the state, but often it needs to be done manually
[14:40] <mardy> pstolowski: thanks, I'll try with snapstate.Set() first
[14:43] <mup> PR snapd#10758 closed: image/image_linux.go: add newline <Simple 😃> <Skip spread> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10758>
[14:46] <ijohnson[m]> @cachio hey is the snap run failure you were mentioning only happening on impish + debian sid or is it happening on other systems too?
[15:13] <mup> PR snapd#10742 closed: tests: update nested tool - part1 <Run nested> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10742>
[15:21] <ijohnson[m]> @mvo can you land https://github.com/snapcore/snapd/pull/10732? the failures are unrelated
[15:21] <mup> PR #10732: tests/lib/nested.sh: split out additional helper for adding files to VM imgs <Simple 😃> <Run nested> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10732>
[15:21] <mvo> ijohnson[m]: sure
[15:21] <ijohnson[m]> thanks
[15:23] <mup> PR snapd#10732 closed: tests/lib/nested.sh: split out additional helper for adding files to VM imgs <Simple 😃> <Run nested> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10732>
[15:44] <miguelpires> cachio hey, can you help me with the translation linting spread test? https://github.com/snapcore/snapd/pull/10756/files#diff-5720a79fd79b88cebcc680e6914186981e330df7bc933261176bed1f42a1fb1d
[15:44] <mup> PR #10756: cmd/snap: only log translation warnings in debug/testing <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10756>
[15:48] <miguelpires> I installed language-pack-pt to reproduce the issue so I guess that's what's missing from the spread env. But in the same test there's a test with "LANG=de", not sure why one works and the other doesn't
[16:43] <ijohnson[m]> /nick ijohnson|lunch
[16:44] <ijohnson[m]> well that didn't work
[16:45] <ijohnson[m]> /nick ijohnson|lunch
[16:45] <ijohnson[m]> hmm so only element seems to know about /nick it seems :-/
[16:47] <ijohnson[m]> huh so actually all this time, element was just changing the matrix display name in the matrix bridged room, that never actually propagated to IRC at all
[16:56] <ogra> ijohnson[m], so no lunch ofr you then ... 
[16:57] <cachio> miguelpires, hi, sorry for the delay, I was having lunch
[16:57] <cachio> let me take a look
[16:58] <cachio> ijohnson[m], I saw that on debian sid and also in uc20 tests when I run beta validation
[17:02] <cachio> miguelpires, so, in which system is it failing?
[17:03] <cachio> because I don'r see error in the execution logfs
[17:08] <cachio> ijohnson[m], have you seen that one?
[17:08] <cachio> https://paste.ubuntu.com/p/9nJv3W46M7/
[17:11] <miguelpires> cachio no worries, thanks for helping me with this. It's not failing but I expected it to. It fails locally because I have the language pack with a incorrect translation and I assume the spread env doesn't have it. But the same spread test also expects assumes that LANG=de works, so I'm not sure
[17:13] <cachio> miguelpires, what should can do there is to add "exit 1" before the line echo "Lint translated commands" 
[17:13] <cachio> and yo uexecute spread -deubg
[17:14] <cachio> so then you will have a debug session and you can run the line and see the output
[17:15] <cachio> I see that you are redirecting the output to /dev/null 
[17:15] <cachio> but the best you can do there is to debug the line
[17:15] <cachio> does it make sense?
[17:17] <miguelpires> Yes, I'll try that then. Thanks! 
[17:24] <cachio> I would try without redirecting to /dev/null the output 
[17:24] <cachio> so NOMATH receives the input
[17:25] <cachio> miguelpires, still don't know why it fails locally
[17:25] <cachio> perhaps could be because another error?
[17:27] <ijohnson[m]> @cachio I've only seen the snap-run failure on sid and impish, I haven't seen it on uc20, do you have logs of the uc20 failure ? 
[17:27] <cachio> ijohnson[m], yes, one second
[17:27] <ijohnson[m]> @cac
[17:28] <ijohnson[m]> @cachio the issue with uc20-create-partitions is known it just randomly happens sometimes
[17:28] <mup> PR snapd#10763 closed: tests: pre-cache snaps in classic and core systems <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10763>
[17:31] <cachio> ijohnson[m], https://paste.ubuntu.com/p/9jBtBNfnng/
[17:31] <ijohnson[m]> thanks looking now
[17:31] <cachio> it is a log from a rpi4
[17:36] <ijohnson[m]> hmm I can't reproduce that in a uc20 amd64 VM
[17:36] <ijohnson[m]> I wonder if it's arm specific
[17:37] <cachio> ijohnson[m],  let me check other logs
[17:39] <cachio> ijohnson[m], in amd64 is working properly
[17:40] <cachio> specifically in pi4
[18:03] <ijohnson[m]> @cachio I can't reproduce that issue on my arm64 rpi4
[18:04] <ijohnson[m]> https://pastebin.ubuntu.com/p/Kr8SgXpfNZ/
[18:04] <ijohnson[m]> granted that's edge snapd not beta
[18:04] <ijohnson[m]> let me try with beta channel snapd
[18:05] <ijohnson[m]> same onbeta channel too
[18:12] <miguelpires> @cachio I used -debug like you mentioned and there were only a couple of language-pack installed. After installing all, the linting worked and caught the bad translation so it's working as  Thanks =)
[18:29] <cachio> miguelpires, nice
[18:30] <cachio> miguelpires, so
[18:30] <cachio> to install dependencies you cant do apt install 
[18:31] <cachio> because that won't work on other oss than ubuntu or debian
[18:32] <cachio> you need to add that here https://github.com/snapcore/snapd/blob/master/tests/lib/pkgdb.sh#L537
[18:32] <cachio> and also the fedora package in pkg_dependencies_fedora function 
[18:33] <cachio> and the same for amazon, opensuse and arch
[18:33] <cachio> so this will be installed when the test start
[18:35] <cachio> ijohnson[m],  I use image from stable but update snapd to beta
[18:35] <cachio> refresh
[18:35] <ijohnson[m]> hmm
[18:35] <ijohnson[m]> I'm not sure what image that was on
[18:35] <ijohnson[m]> (for my run)
[18:35] <cachio> https://storage.googleapis.com/snapd-spread-tests/images/pi4-20-beta/pi.img.xz
[18:36] <cachio> this is the image 
[18:36] <cachio> this is where it fails
[18:37] <cachio> pi 107
[18:37] <cachio> core20 1084
[18:37] <cachio> pi-kernel 339
[18:37] <cachio> snapd 13269
[18:37] <ijohnson[m]> cachio: oh wait my device was on uc18 not uc20
[18:37] <cachio> this is the last image for 2.52
[18:37] <ijohnson[m]> I'll have to reflash with uc20 to test
[18:37] <cachio> ok
[18:37] <ijohnson[m]> cachio: so is it reproducible just running that snap run command ?
[18:38] <ijohnson[m]> or is there more setup needed to make it fail with the segfault?
[18:41] <cachio> ijohnson[m], just running -> snap run --strace="invalid" test-snapd-sh.sh -c 'echo hello'
[18:42] <cachio> so having that snpa installed
[18:42] <cachio> should be enough
[18:42] <ijohnson[m]> ok, that's what I was trying but obviously I wasn't hitting the bug as I was actually on uc18 not uc20
[18:42] <cachio> hehe
[18:42] <cachio> np
[18:43] <ijohnson[m]> I'll try again with a uc20 image later, I need to work on 360s now
[19:10] <mborzecki> heh, sid still failed in https://github.com/snapcore/snapd/pull/10754/ the package built successfuly but prepare failed anyway :/
[19:10] <mup> PR #10754: packaging, tests/lib/prepare-restore: build packages without network access, fix building debs with go modules <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10754>
[19:12] <mborzecki> ehh it's because i disabled the generator, so somehow the package still ended up with unknown version, even though mkversion is ran earlier :/
[19:33]  * cachio afk