[05:12] morning [05:47] mborzecki: hi! [05:57] mardy: heya [06:40] hmm hmm [06:42] good morning [06:42] mborzecki one thing I miss about spain is that at night, it's still 21C [06:54] meh, lp builds are unhappy about go module [06:55] PR snapcraft#3578 opened: Fix: files starting with '.' are not organized and also not caught by filesets [06:58] reproduced the build problem from lp at least :) [07:00] mborzecki: \o/ [07:01] mborzecki: any more info yet? [07:01] mvo: hey, so i think we're missing this: https://paste.ubuntu.com/p/BkGRc5QQYW/ [07:01] morning [07:01] mvo: also github.com/boltdb/... is listed in go.mod but does not really appear in vendor directory anywhere [07:03] mvo: do you remember why we have a fork of boltdb? [07:03] mborzecki: do you know why it started just now? [07:03] mborzecki: iirc to fix build problems on trusty, let me quickly check [07:04] mborzecki: build on 32bit systems and riscv [07:04] mborzecki: https://github.com/snapcore/bolt/commits/master [07:04] mvo: afaiu lp builders run with disabled network, our go.mod listst github.com/boltdb/.. and thus go build attempts to fetch the module [07:05] mborzecki: ohhhhh, that makes sense. wonder why it ever worked but maybe it never did inside a buildd [07:05] mvo: maybe we could just replace that bolt with our fork using https://golang.org/ref/mod#go-mod-file-replace for deb builds? [07:05] mborzecki: I think so, iirc ian had something like this [07:06] mborzecki: https://github.com/snapcore/snapd/pull/10559/files#diff-33ef32bf6c23acb95f5902d7097b7a1d5128ca061167ec0716715b0b9eeaa5f6R36 <- looks like not for bolt but he looked at it for other things [07:06] PR #10559: many: move to go modules <⛔ Blocked> [07:06] mborzecki: thanks *so* much for finding this [07:06] mvo: i'll open a pr in a bit [07:17] PR snapd#10609 closed: interfaces/desktop: mount system fonts via app desktop slot [07:17] PR snapd#10753 opened: interfaces/desktop: allow snaps to provide a desktop slot, granting access to system fonts [07:30] hi zyga-mbp, mvo, pstolowski [07:30] hey :) [07:30] impish is close to release [07:30] I remember before snaps, everything was very stressful at this time [07:31] I guess now it's more of a mixed set, with some things still having to make it on time [07:31] but some things having the luxury of releasing on time when they are ready [07:37] do you guys see any value in this? https://github.com/snapcore/snapd/pull/10751 I started it yesterday, but today I seem to realize that it's already relatively easy to mock the snapd responses, so maybe I should drop it. [07:37] PR #10751: client: turn the Client type into an interface [07:56] mvo: heh so not sure what to make of it, snapd imports snapcore/bolt which has some *_test.go files that improt boltdb/bolt and that makes it an indirect dependency, adding a replace directive confuses go as there are 2 modules doing the same now? [07:56] mvo: also, we're not setting GO111MDOULE so dh_golang defaults to GO111MODULE=off [07:56] but we do pass -mod vendor sometimes? [08:04] mborzecki: ohhh, maybe we need to just set go111module globally in the debian build rules then? [08:04] mborzecki: sorry that I did not explore that, between the different dh-golang versions I got lost a bit but the env might be enough to give us the desired behavior [08:06] I wonder if we can somehow make the package build inside spread networkless, if there is a clever "nsenter" to archive that [08:27] mvo: yeah, that's what im doing right now, added unshare -n around all calls to rpmbuild/debuild/makepkg [08:28] mborzecki: \o/ [08:28] mborzecki: should I fix the testfiles in boltdb ? or are you on it alredy? [08:29] mvo: added something like this locally: https://paste.ubuntu.com/p/Csg5JpZTZH/ [08:30] mvo: but i guess the imports need to be fixed anyway as replace are package local iirc [08:47] PR snapd#10754 opened: tests/lib/prepare-restore: make sure that package build is done without network access [08:48] mvo: ^^ [08:48] mborzecki: nice [08:53] pstolowski, mvo: hey hey! Just poking around to see if there's any progress with the snapd focal riscv64 situation? Is there an upload planned for temporarily skipping the failing tests? [08:54] sil2100: my PR for disabling the failing suite on riscv landed yesterday in master [08:57] PR snapd#10717 closed: tests: fix interfaces-libvirt test [08:58] sil2100: it was https://github.com/snapcore/snapd/pull/10736 [08:58] PR #10736: tests: skip overlord tests on riscv64 due to timeouts [09:00] is it possible for a snap to control (stop, start, restart) its own services, without needing the user to be root? ("snapctl stop", for example, requires root) [09:10] \o/ [09:24] mardy IIRC yes [09:24] mardy snapctl is accessible from the inside of the snap [09:29] pstolowski: do you know when this change will be uploaded to focal? [09:30] mvo: meh, as expected the deb builds are failing without network [09:32] mborzecki module "fun"? [09:32] sil2100: dunno, mvo may know [09:32] zyga-mbp: yeah unforunately [09:33] it's a really hard problem :/ [09:33] I have a path to fix that in my yocto builds but nothing fixed yet [09:33] the complete module system is elaborate and complex [09:33] zyga-mbp: also dh-* is really getting into the way [09:36] hmm [09:39] zyga-mbp: there's a check there, and the stop, start and restart commands are allowed only for root: https://github.com/snapcore/snapd/blob/master/overlord/hookstate/ctlcmd/ctlcmd.go#L148-L150 [09:43] sil2100: uh, right, sorry, I wanted to do it today/yesterday but 360 :( [10:20] uh [10:20] popsulem sobie system [10:20] pstolowski uzywasz czegos do kopii zapasowych wirtualek? [10:21] zyga-mbp: did you mean it for #snappy? ;) [10:22] pstolowski bad channel :) [10:22] sorry [10:51] PR snapcraft#3579 opened: snap: move base to core20 [11:27] mvo: no worries! That reminds me... need to fill in out my 360! [12:15] heh cryptic errors: `devicemgr: cannot update revisions after boot changes: empty snap file name` [12:43] PR snapd#10743 closed: tests: fix fakedevicesvc service already exists [12:58] PR snapd#10755 opened: client: introduce mocking of the Client interface [13:32] mborzecki: should I commit the boltdb imoport fixes or are you on it alredy? [13:32] mvo: please do if you can, still fighting managers test suite [13:32] mborzecki: sure, doing this now [13:41] mborzecki: fix pushed [13:41] thanks [13:41] mborzecki: let's see if it helps :) [13:41] i'm confused, did old model assertions not require a "base" header? [14:03] PR snapd#10756 opened: cmd/snap: only log translation warnings in debug/testing [14:41] I very welcome reviews on https://github.com/snapcore/snapd/pull/10628, if someone has a few minutes to spare [14:41] PR #10628: usersession/xdgopenproxy: move PortalLauncher class to own package [14:45] cachio: could https://github.com/snapcore/snapd/pull/10561 land now (once reviewed)? [14:45] PR #10561: tests: revert revert manuall lxd removal [14:45] or are we still waiting for lxd fix? [14:53] pstolowski, thanks, the fix is already applied, so it is good time to land this one [14:53] cachio: ok, +1 from me [14:58] tx [15:58] need 2nd review for https://github.com/snapcore/snapd/pull/10725 [15:58] PR #10725: o/hookstate: require snap-refresh-control interface for snapctl refresh --proceed [16:54] ijohnson[m], hi, I see the recover issue again on uc20 [17:05] cachio: did you see it with the debug kernel command line branch or with what's on master? [17:08] ijohnson[m], I saw that on maste [17:08] now I am running tests to see if I can reproduce it and get some extra info [17:08] I am using your pr [17:09] ack === E_Eickmeyer is now known as Eickmeyer [18:56] I have some questions about Full Disk Encryption on Ubuntu Core. Is this the right place to ask, or is there a more appropriate support channel? [18:57] ledhed yeah this is the right place [18:57] Either here or the snapcraft forum on the channel header [19:00] thanks, I have a project coming up and would like to use Ubuntu Core, but my understanding is that FDE only works (at least out of the box) on certified devices. The hardware I need for my project (CompuLab Fitlet2, AMD64) appears to have all the requirements to support FDE. I'm just not clear if I can build my own image and enable FDE, or if [19:00] FDE is strictly for certified devices and I would need to get the Fitlet2 certified. [19:02] ledhed FDE for amd64 platforms works out of the box on devices that meet the requirements, i believe the fitlet2 meets the requirements [19:05] when I run: ls /dev/disk/by-partlabel/ | grep enc nothing is returned. Which implies its not encrypted. [19:06] I checked the bios and confirmed that Secure Boot is enabled, as is the TPM [19:52] I was able to get it to encrypt the disk, seems I had to clear the TPM. The problem I'm running into now is that after it encrypts the disks, on the next boot it asks for the recovery key. Then errors out and says "cannot activate with TPM sealed key (cannot unseal key: invalid data file: cannot complete authorization policy assertions: cannot [19:52] complete OR assertions: current session digest not found in policy data) and activation with recovery key failed (cannot obtain recovery key: /usr/sbin/systemd-ask-password failed: exit status 1)" [20:26] * cachio afk [22:41] hello, what version of go is the snapd snap built with? [22:42] mwhudson 1.13 currently [22:42] ok [22:43] from my snap or do we have that in the archive for xenial now? [22:43] (it is still built on xenial, right? is there a plan to change that?) [22:43] ah yeah we do have 1.13 on xenial [22:56] ijohnson[m]: anyway https://bugs.launchpad.net/snapd/+bug/1943077 [22:56] Bug #1943077: snapd fails to autopkgtest on mksquashfs, which is looking for libgcc_s

[22:57] if you have questions, I filed that monstrosity [22:58] the summary would be "snapd seems to need libraries outside of itself to pass autopkgtest" [23:10] dbungert: i think the fix is pretty trivial luckily [23:12] dbungert, ijohnson[m]: to whit https://github.com/snapcore/snapd/pull/10757 [23:12] PR #10757: build-aux: stage libgcc-s1 library into snapd snap [23:15] PR snapd#10757 opened: build-aux: stage libgcc-s1 library into snapd snap [23:15] Failed to fetch stage packages: Error downloading packages for part 'libc6': The package 'libgcc-s1' was not found.. [23:17] oh really [23:17] mwhudson: libgcc1? [23:18] yes probably [23:20] yes [23:20] ok force pushing that [23:21] package name changed somewhere between bionic and focal it seems