[05:48] morning [07:11] hi mborzecki, mvo [07:14] mardy: heya [07:14] good morning mardy and mborzecki ! [07:15] good morning :) [07:24] good morning zyga-mbp ! [07:24] * zyga-mbp hey :) [07:24] I'm venturing into automation land [07:24] with industrial control boxes and what not [07:24] it's a weird place [07:24] how are you doing mvo? [07:24] Impish is almost upon us [07:25] zyga-mbp: woah, nice. I'm doing fine but not really as exciting things as you, trying to make sure things are delivered on time currently [07:26] serious things are meant to be like that [07:26] I'm very happy to see you and samuele manage snapd [07:52] PR snapd#10888 closed: tests: support running all spread tests with experimental features [08:02] 'morning zyga-mbp [08:03] hey mardy :) [08:08] find squashfs-root/ -name configure [08:09] squashfs-root/hooks/configure [08:09] squashfs-root/meta/hooks/configure [08:09] squashfs-root/snap/hooks/configure [08:09] I guess I'll edit all of them :-D [08:10] woah [08:10] that's a lot of hooks :) [08:10] technically snapd needs meta/hooks/ [08:10] snap/hooks is probably (guessing) from snapcraft [08:10] the top-level is dunno [08:11] zyga-mbp: thanks, I'll ask the developers of the snap to do some housecleaning :-) [08:13] at least configure is not a directory :) [08:13] that would confuse snapd [08:13] or a socket ;-) [08:39] mvo: hi, can you merge https://github.com/snapcore/snapd/pull/10875 please? [08:39] PR #10875: client: fail fast on non-retryable errors [08:41] ty [08:42] PR snapd#10875 closed: client: fail fast on non-retryable errors [09:00] mvo: hi, do you have the source tarballs to pus on the github releases page? [09:05] mborzecki: for 2.53? not yet, sry! I can upload after the meeting [09:07] mvo: that's fine, i'll update the arch and opensuse packages when the sources are available [09:23] mborzecki: yeah, sry again, will get to it later but in meetings this morning [09:43] got an errand, back in 1,5h or so [10:21] mborzecki: tarfiles updated [11:02] re [11:02] mvo: thanks! [11:14] mvo: we have a tests/smoke/ directory, should I move the microk8s test there? [11:21] meh lxd broke tests https://paste.ubuntu.com/p/2nsXcy5Fyg/ [11:28] mardy: the name is a bit misleading, that testsuite is really for smoke testing snapd itself and it is expected to be quick(ish) [11:29] mardy: maybe I should document this :/ [11:38] PR snapd#10827 closed: fde: add new device-setup support to fde-setup [11:38] PR snapd#10830 closed: gadget: add `encryptedDevice` and add encryptedDeviceLUKS [11:38] PR snapd#10854 closed: spread: use `bios: uefi` for uc20 [12:01] PR snapcraft#3588 closed: snap: patch patchelf on riscv64 (CRAFT-566) [13:08] PR snapd#10896 opened: tests: remove "features" from fde-setup.go example [13:22] mwhudson, are you still doing console-conf ? i'm running into a weird bug here ... after installing network-manager on a fully set up UC20 the screen shows "" afterwards while the device actually *does* have an IP ... does console-conf not simply use "ip addr" to find the default IP ? [13:23] mvo pedronis is not around today? [13:23] * zyga-mbp mvo I ran into an issue where snapd cannot remove the core snap (on focal) because it's a part of the model [13:23] but on classic that is mostly meaningless [13:24] and it's also a very confusing error message, models are relatively unknown to general public [13:24] is this by design? [13:24] The exact interaction is: [13:25] * zyga-mbp $ sudo snap remove core [13:25] * zyga-mbp error: cannot remove "core": snap "core" is not removable: snap is used by the model [13:32] mwhudson, ah, ian pointed me to https://bugs.launchpad.net/subiquity/+bug/1898583 (which is sadly still not fix-released thanks to core20 stable not having been updated since april (!!!)) [13:32] Bug #1898583: console-conf with wlan connection does not ever report ip via tty message, even though it does have ip [13:36] ogra: this one may also be relevant LP: #1903050 [13:36] Bug #1903050: consoleconf main is broken (core22)

[13:38] dbungert, well, it is fixed in core20 candidate (just confirmed) ... the shocking bit is that core20 has not been released to stable since april ... which means there might be a gazillion open CVEs out there on devices 😞 [13:38] that bug is for UC22 ... [13:39] (which is still a year away, luckily 🙂 ) [13:42] oh, weird ... after the switch to candidate snap info core20 shows something completely different for the stable channel ... the stable image i downloaded had an april-released core20 [13:42] (and did not see an update for it with snap refresh) [13:45] zyga-mbp: in a meeting but pedronis should be around [13:46] perhaps not on irc [13:46] ogra: snap info core20 shows july which is not much better but a bit [13:46] ogra: I think sil2100 knows when core20 is promoted to stable, I expect RSN [13:47] mvo, yeah, this is really weird, i am on a freshly installed UC20 stable image where snap list showed "core20 20210429 1030 latest/stable canonical✓ base" even after several snap refresh runs that i manually did ... switching the channel to candidate and back for core20 now gives me the correct one [13:48] ogra: oh, that is odd. what image did you use, I would love to test this [13:48] http://cdimage.ubuntu.com/ubuntu-core/20/stable/current/ubuntu-core-20-arm64+raspi.img.xz [13:48] on a Pi4 [13:48] ogra: ta [13:49] We are phasing out core20 right now [13:50] sil2100 phasing out as in replacing it with something or phase upgrade? [13:50] We're using automated progressive releases for core20, and it's being phased out right now - the new version that is [13:50] nice [13:50] But yeah, 20210429 seems like something VERY old [13:50] ogra: there you go, I guess the phasing is the reason you did not get hte update [13:50] So that shouldn't have been listing at all [13:51] mvo, ah, okay ... though april still seems a bit oldish for the image (which has an image timestamp from june) [13:52] i'd have expected a newer core20 on that image [13:52] ogra: I think we had this big jump https://people.canonical.com/~mvo/core20-changes/html/stable/ [13:53] oha ! [13:53] okay [13:53] ogra: I guess we need to make sure to keep an eye on this and make sure we release more often [13:53] yeah, we need to make sure CVEs are closed in time 🙂 [13:54] else i'll have some customers with torches and pitchforks showing up at my doorstep i fear [13:55] +100 [13:56] nah, i dont want more than 100 customers with pitchforks 😛 [13:56] -95 [13:56] 5 customers with pitchforks seems like a reasonable bunch to manage [13:56] yeah, 5 i can handle with a garden hose [13:56] hahaha [14:16] Following HACKING.md to go build snap: I feel like I am missing something, as I have two broken deps. (1) secboot - which I was able to bypass with a -tag and (2) dbus *Match* functions, which does not appear to exist in godbus. Any hints - sorry im new [14:16] invoking `/snap/snapd/current/lib/x86_64-linux-gnu/ld-2.23.so --library-path /snap/snapd/current/usr/local/lib:/snap/snapd/current/lib/x86_64-linux-gnu:/snap/snapd/current/usr/lib/x86_64-linux-gnu /snap/snapd/current/usr/bin/mksquashfs` fails on opensuse [14:17] the usual: libgcc_s.so.1 must be installed for pthread_cancel to work [14:17] bboozzoo: hey funny you mention ld [14:17] I just pinged you on MM about libc haha [14:17] fwiw i think we should not invoke the tooling mksquashfs in tests [14:17] I think we need another change to the snap-confine profile for s390x [14:18] GOFLAGS='-tags=nosecboot' go build -o /tmp/snap github.com/snapcore/snapd/cmd/snap [14:19] fdo.go:127:18: undefined: dbus.MatchOption [14:41] flotter: is this a new checkout? go.mod should already mention the right version of go-dbus [14:42] and that version should have been fetched when go build was invoked [14:42] I did find the functions exist in the downloaded godbus repo [14:42] I did a fresh go get, an hour ago [14:44] go: extracting github.com/godbus/dbus v4.1.0+incompatible [14:45] The name is not very inspiring :D [14:45] The name is not very inspiring :) [14:47] work/pkg/mod/github.com/snapcore/snapd@v0.0.0-20210902070205-9fe87efa1b36/desktop/notification/fdo.go:127:18: undefined: dbus.MatchOption [14:48] flotter that's not right [14:48] you should not do that manually [14:48] go build ./... should do it [14:48] you're not supposed to compete with go.mod by checking out things by hand [14:48] here you are running into module versions that use a somewhat elaborate scheme, snapd uses /v5 [14:49] flotter git clone && go build ./... should be enough [14:49] * zyga-mbp (apart from C world) [14:50] I only did the go get command (from HACKING.md) and then "GOFLAGS='-tags=nosecboot' go build -o /tmp/snap github.com/snapcore/snapd/cmd/snap" [14:50] * zyga-mbp most likely hacking is stale [14:50] it predates go-mod days [14:50] understood [14:51] so you are saying just check out the git, and build [14:51] yes, at least that's the start [14:51] once you check out _and_ are on a debian-like distro you can apt-get build-dep . [14:51] to get C world side [14:51] you will be much closer to being able to iterate [14:51] OK let me try, thanks! [14:52] send patches to fix HACKING.md [14:52] I will do! [14:52] * zyga-mbp loves the go.mod world where $GOPATH/src is gone [14:53] * zyga-mbp thank you :) [15:09] PR snapd#10897 opened: osutil: ensure parent dir is opened and sync'd [15:17] PR core20#116 closed: hooks: adjtime: add adjtime file to etc [15:34] PR snapd#10896 closed: tests: remove "features" from fde-setup.go example [15:37] so the LP: #1943077 saga continues - I'm trying to judge if snapd from the deb having problems with `snap pack` is release critical for impish. Retesting adt with snapd from impish-proposed still shows the problem with libgcc. [15:37] Bug #1943077: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s

[15:39] PR snapd#10881 closed: tests: merge coverage results [17:17] Hi. GOOS=linux GOARCH=arm64 go build -v -a -o /tmp/build/arm64 ./... [17:17] I am attempting to cross compile snapd for arm and arm64. [17:19] I get a compiler failure for golang-evdev - undefined: ioctl [17:19] flotter: golang-evdev is only necessary for building snap-bootstrap which is only used on Ubuntu Core so you should just skip building that binary [17:20] ijohnson[m]: may I get your thoughts on the matter above? [17:20] dbungert: sorry I missed your message above let me re-read the bug again [17:21] buried in bot updates :) [17:23] yeah it gets annoying since the links get expanded and so I don't see individual messages as clearly, meh communication is hard [17:24] If I do want to build the snap-bootstrap, any tip(s) on what I should be looking at to get the deps resolved? [17:29] flotter: you need to setup a C cross compiler and use it when compiling, something like this [17:29] oh hmm I don't seem to have that in my bash history anymore, darn [17:34] flotter: this is what you want essentially [17:34] CC=aarch64-linux-gnu-gcc GOARCH=arm64 CGO_ENABLED=1 go build -o snap-bootstrap-arm64 ./cmd/snap-bootstrap/ [17:35] dbungert: so the situation really hasn't changed at all on our side as it pertains to snap pack and impish, one wrinkle that I wasn't aware of (or more accurately I had forgotten) is that `snap pack` will always unconditionally attempt to re-exec to use mksquashfs from the core/snapd _snaps_ even when the version of snapd itself from the debian package is newer. This is to ensure that snaps that are created are always created with a [17:35] supported and working mksquashfs [17:36] so this means that we need to have the fix you landed in the snapd/core snaps before it can work in these autopkgtests [17:36] and also that any impish users who try to use `snap pack` from i.e. snapcraft will be broken and it won't work until the core/snapd snaps are updated [17:37] that part I'm not so wild about, but I don't have a feel for how common it would be [17:37] unfortunately, while the fix is in the pipeline as part of snapd 2.52.1, it is probably 2 weeks away now I think from going to stable for all users to be able to get that fix [17:39] we have 2.52 ready to go to stable very shortly, and the next release after 2.52 will be 2.52.1, but we need to let 2.52.1 bake a bit in the beta channel before we can push it through [17:40] and in the meantime, real users trying to use snapcraft on impish can use the edge (possibly beta) channel of the snapd snap until the fix has made its way through the pipeline [17:42] Thank you very much, understood [17:43] dbungert: does that make sense? [17:43] It does, yes. The real question here is - do we believe action needs taken prior to impish release, and I think the answer is "no". We plan to point affected people to snapd edge/beta. [17:44] yeah there is no action to be taken at this time unfortunately other than to wait [17:45] would we have expected the snapd in impish-proposed to have the libgcc_s fix? [17:47] dbungert: the issue is that snapd as a feature will purposefully execute mksquashfs from the snap ignoring whatever version is in the deb world [17:47] ok, so no change to the deb can conceivably help [17:49] ijohnson[m]: appreciate the feedback, I think we're good [17:49] well we could disable re-exec in the deb so it stops doing that, but it's sort of a feature, so we would want to disable it in a very specific manner, like basically "try re-exec, it if fails specifically because of segfaulting, then use mksquashfs from the host", but that would take time that we don't have a lot of at the moment unfortunately [17:50] fair [20:19] x86_64 (native) [20:19] ~/snapd$ CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -a -o /tmp/build/amd64 ./... [20:19] ARMv8_64 (crosscompile) [20:19] ~/libseccomp$ ./configure --host=aarch64-linux-gnu --prefix=/home/flotter/libseccomp/root [20:19] ~/libseccomp$ make && make install [20:19] ~/snapd$ CC=aarch64-linux-gnu-gcc CGO_ENABLED=1 CGO_LDFLAGS="-L/home/flotter/libseccomp/root/lib" GOOS=linux GOARCH=arm64 go build -a -o /tmp/build/arm64 ./... [20:19] ARMv7 (crosscompile) [20:19] ~/libseccomp$ ./configure --host=arm-linux-gnueabihf --prefix=/home/flotter/libseccomp/root [20:19] ~/libseccomp$ make && make install [20:19] ~/snapd$ CC=arm-linux-gnueabihf-gcc CGO_ENABLED=1 CGO_LDFLAGS="-L/home/flotter/libseccomp/root/lib" GOOS=linux GOARCH=arm go build -a -o /tmp/build/arm ./... [20:20] I have been able to now build snapd on amd64 / arm and arm64. The only dependency was libseccomp, which I cross-compiled for the to non-native builds. [20:21] Is there anything I have done wrong here (conceptionally) ? I verified the ELF files and the headers match the target arch. [20:22] I am asking in the context of trying to update HACKING.md with steps that could help others. [20:49] flotter: did you have any problems? I don't see anything conceptually wrong there but the best test would be to see if it just works [21:35] PR snapd#10898 opened: cmd/snap-confine/snap-confine.apparmor.in: update ld rule for s390x impish <⚠ Critical> === cjp256_ is now known as cjp256