[05:45] morning [05:48] - Great. No issues. Yes, testing will be next. [06:04] hi mborzecki! [06:04] mardy: hey [07:20] meh, the opensuse i586 build on obs fails on go-efilib, unclear why [07:21] unless the source tarball is missing dependencies maybe? [07:32] PR snapd#10898 closed: cmd/snap-confine/snap-confine.apparmor.in: update ld rule for s390x impish <⚠ Critical> [08:22] PR snapd#10899 opened: packaging: fixes for building on openSUSE [08:28] trivial PR ^^ [08:29] mborzecki: thanks! [08:32] mvo: could you merge https://github.com/snapcore/snapd/pull/10173 for me? The spread failures looks spurious, as the PR only adds infrastructure to support other PRs rather than change any existing behaviour. [08:32] PR #10173: interfaces: add polkit security backend [08:32] jamesh: sure [08:32] thank you [08:37] PR snapd#10173 closed: interfaces: add polkit security backend [08:59] HACKING.md: Note that if you are using go 1.16 or newer you need to disable the [08:59] go modules feature. Use: export GO111MODULE=off [09:00] Is this still (was it ever) true? I installed go v1.16.x and things for me work fine with modules enabled ? [09:00] (it builds fine) [09:00] flotter: that is no longer true I think, it might be a overlook [09:00] flotter: we moved to 1.13 recently so this may be outdated [09:02] ok thx, this is what I thought. [09:04] The HACKING.md guide attempts help users for 3 cases: "From snapd 2.52, snapd supports Go 1.13 and onwards. From snapd 2.38 [09:04] to 2.52, snapd requires Go 1.9+. Versions before 2.38 support Go 1.6+." [09:05] Do we really want to support those historic cases in this guide? It feels like it is opening up a can of worms, with module support and not. [09:05] Would it not make sense to draw a line in the sand and make the guide apply only to the commit point and later ? then we can make it very clear [09:16] zyga-mbp: hi, can you take a look at https://build.opensuse.org/request/show/924171 ? [10:06] mardy: can you take a look at https://github.com/snapcore/snapd/pull/10899 ? [10:06] PR #10899: packaging: fixes for building on openSUSE [11:16] mborzecki: +1, minor suggestion [11:58] PR snapd#10891 closed: gadget: add mapping trait types + functions to save/load [12:17] mvo: can you merge https://github.com/snapcore/snapd/pull/10897, please? spread failures seem unrelated [12:17] PR #10897: osutil: ensure parent dir is opened and sync'd [12:23] good morning [12:24] mvo: rpi4 now supports secure boot [12:24] zyga-mbp, you mean they added a proper TPM? [12:24] mvo: I've got a working low cost automation solution for rpi4 (extensible to all versions), off the shelf components and low complexity [12:24] ogra nope [12:24] mvo: the system can automate 4 x rpi4 boards [12:24] (pi has always supported "secure" boot through i2c or spi attached key storages) [12:25] mvo: or 3 x rpi4 and auto-recover itself [12:25] (but thats only FSVO secure ... since you can tap into the buses and sniff they keys) [12:25] ogra: https://github.com/raspberrypi/usbboot/pull/93/files [12:25] PR raspberrypi/usbboot#93: WIP: Add support for secure-boot - see Readme.md [12:25] this is better [12:26] ogra: one-time programmable though [12:26] ogra but has a nice test mode to check it works before going in with the fuse burner [12:26] zyga-mbp, OOOH ! signing the EEPROM itself !! [12:26] eeprom, eeprom config and the image [12:26] (booted image) [12:26] yeah [12:26] read that, it's cool [12:27] very nice [12:28] * zyga-mbp will write control software to spread-automate pi4 at home and in his office lab [12:29] happy to share and co-develop if you have interest and cycles [12:33] * zyga-mbp reboots, back after update [12:43] PR snapd#10900 opened: o/devistate: introduce DeviceManager.Unregister [13:43] PR snapd#10901 opened: overlord: add managers unit test demonstrating cyclic dependency between gadget and kernel updates [15:23] PR snapd#10879 closed: gadget/ondisk.go: add listBlockDevices() to get all block devices on a system [15:48] PR snapd#10902 opened: interfaces/apparmor: allow read access to random files for haveged [16:59] PR snapd#10903 opened: gadget/ondisk.go: include the filesystem UUID in the returned OnDiskVolume [17:24] PR snapd#10904 opened: osutil/disks, many: switch to defining Partitions directly for MockDiskMapping [18:06] Question about "why are snaps loop devices"? -> from https://snapcraft.io/docs/snap-format: "This method delivers fast and extremely predictable installations, with no installation remnants, and no way for a snap’s content to be mutated or interfered with. A snap is either installed and available as originally built, or it is not available at all." [18:06] Is this the primary reason? [18:24] PR snapd#10902 closed: interfaces/apparmor: allow read access to random files for haveged [18:26] holmanb, yes, snaps are gpg signed readonly squashfs images that support binary deltas (so downloads are small) ... you cn not tinker with the content but squashfs also uses compression so a snap is usually smaller than the same contnet installed as other packages [18:33] ogra: Thanks :) That makes sense. Last night I was just looking at boot time in systemd-analyze critical-chain and went down the rabbit hole of "why is snap taking so much of this time?" -> "loop devices are slow" -> "start playing with perf and get frustrated with ubuntu's perf packaging" -> "why snap use loop devices anyways?" [18:39] well, loop devices (or mounting filesystem images in general) is slow on rotary disks ... i think that assumption is that these are rare nowadays for boot media 🙂 [18:39] *that the [18:39] (you nearly seen no boot impact on NVME disks, SSDs and the like) [18:40] ogra: I was testing in lxd, would that affect it perhaps? [18:40] I'm on NVME [18:40] hmm, it might [18:41] i rarely have snaps in my lxd containers (i use them to build snaps though 🙂 ) [18:41] though lxd usually does not do an actual boot unless you use a VM backend of it [18:42] ogra: checked how system, snapd time in critical-chain is negligable (150ms) [18:43] *host [18:43] yeah, thats typical [18:44] ogra@acheron:~$ systemd-analyze critical-chain|grep snapd [18:44] └─snapd.socket @13.583s 👍ms [18:44] └─snapd.apparmor.service @13.089s +488ms [18:44] ogra@acheron:~$ snap list | wc -l [18:44] in lxd snapd took up over half the total boot time [18:44] 103 [18:44] heh [18:45] my emoji plugin thought it shuld give the 1ms a thumbs up 🙂 [18:45] XD [18:45] ``` [18:45] root@me:~/cloud-init-logs-2021-10-08# systemd-analyze critical-chain | grep snapd [18:45] └─snapd.seeded.service @9.679s +6.108s [18:45] └─snapd.service @7.639s +2.036s [18:45] └─snapd.socket @7.586s +2ms [18:45] root@me:~/cloud-init-logs-2021-10-08# snap list | wc -l [18:45] 4 [18:45] root@me:~/cloud-init-logs-2021-10-08# systemd-analyze [18:45] Startup finished in 17.694s (userspace) [18:45] graphical.target reached after 15.791s in userspace [18:46] ``` [18:46] in case that's of any value ^^ [18:46] that soounds rather normal ... [18:47] you can technically disable the snapd.service unit, a use of any snap command should launch it via the socket anyway [18:48] snap seeding usually only happens on first boot, i wonder why you see it there [18:49] Sure, I don't really need it running but I figured I'd dig in a little and learn more since I don't know much about snaps [18:49] Thanks for answering some newbie questions :) [18:49] np ... we've all been newbies once 😉 [19:18] PR snapcraft#3589 opened: snap: correct patch apply for patchelf [20:53] PR snapcraft#3589 closed: snap: correct patch apply for patchelf === not_phunyguy is now known as phunyguy