[05:45] <mborzecki> morning
 - Great. No issues. Yes, testing will be next.
[06:04] <mardy> hi mborzecki!
[06:04] <mborzecki> mardy: hey
[07:20] <mborzecki> meh, the opensuse i586 build on obs fails on go-efilib, unclear why
[07:21] <mborzecki> unless the source tarball is missing dependencies maybe?
[07:32] <mup> PR snapd#10898 closed: cmd/snap-confine/snap-confine.apparmor.in: update ld rule for s390x impish <⚠ Critical> <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10898>
[08:22] <mup> PR snapd#10899 opened: packaging: fixes for building on openSUSE <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899>
[08:28] <mborzecki> trivial PR ^^
[08:29] <mvo> mborzecki: thanks!
[08:32] <jamesh> 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] <mup> PR #10173: interfaces: add polkit security backend <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/10173>
[08:32] <mvo> jamesh: sure
[08:32] <jamesh> thank you
[08:37] <mup> PR snapd#10173 closed: interfaces: add polkit security backend <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10173>
[08:59] <flotter> HACKING.md: Note that if you are using go 1.16 or newer you need to disable the
[08:59] <flotter> go modules feature. Use: export GO111MODULE=off
[09:00] <flotter> Is this still (was it ever) true? I installed go v1.16.x and things for me work fine with modules enabled ?
[09:00] <flotter> (it builds fine)
[09:00] <mvo> flotter: that is no longer true I think, it might be a overlook
[09:00] <mvo> flotter: we moved to 1.13 recently so this may be outdated
[09:02] <flotter> ok thx, this is what I thought.
[09:04] <flotter> 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] <flotter> to 2.52, snapd requires Go 1.9+. Versions before 2.38 support Go 1.6+."
[09:05] <flotter> 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] <flotter> 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] <mborzecki> zyga-mbp: hi, can you take a look at https://build.opensuse.org/request/show/924171 ?
[10:06] <mborzecki> mardy: can you take a look at https://github.com/snapcore/snapd/pull/10899 ?
[10:06] <mup> PR #10899: packaging: fixes for building on openSUSE <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899>
[11:16] <mardy> mborzecki: +1, minor suggestion
[11:58] <mup> PR snapd#10891 closed: gadget: add mapping trait types + functions to save/load <Simple 😃> <Needs Samuele review> <Skip spread> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/10891>
[12:17] <miguelpires> mvo: can you merge https://github.com/snapcore/snapd/pull/10897, please? spread failures seem unrelated
[12:17] <mup> PR #10897: osutil: ensure parent dir is opened and sync'd <Simple 😃> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10897>
[12:23] <zyga-mbp> good morning
[12:24] <zyga-mbp> mvo: rpi4 now supports secure boot
[12:24] <ogra> zyga-mbp, you mean they added a proper TPM?
[12:24] <zyga-mbp> 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] <zyga-mbp> ogra nope
[12:24] <zyga-mbp> mvo: the system can automate 4 x rpi4 boards 
[12:24] <ogra> (pi has always supported "secure" boot through i2c or spi attached key storages)
[12:25] <zyga-mbp> mvo: or 3 x rpi4 and auto-recover itself 
[12:25] <ogra> (but thats only FSVO secure ... since you can tap into the buses and sniff they keys)
[12:25] <zyga-mbp> ogra: https://github.com/raspberrypi/usbboot/pull/93/files
[12:25] <mup> PR raspberrypi/usbboot#93: WIP: Add support for secure-boot - see Readme.md <Created by ghollingworth> <https://github.com/raspberrypi/usbboot/pull/93>
[12:25] <zyga-mbp> this is better
[12:26] <zyga-mbp> ogra: one-time programmable though
[12:26] <zyga-mbp> ogra but has a nice test mode to check it works before going in with the fuse burner
[12:26] <ogra> zyga-mbp, OOOH ! signing the EEPROM itself !!
[12:26] <zyga-mbp> eeprom, eeprom config and the image
[12:26] <zyga-mbp> (booted image)
[12:26] <ogra> yeah
[12:26] <zyga-mbp> read that, it's cool
[12:27] <ogra> very nice
[12:28]  * zyga-mbp will write control software to spread-automate pi4 at home and in his office lab
[12:29] <zyga-mbp> happy to share and co-develop if you have interest and cycles
[12:33]  * zyga-mbp reboots, back after update
[12:43] <mup> PR snapd#10900 opened: o/devistate: introduce DeviceManager.Unregister <Created by pedronis> <https://github.com/snapcore/snapd/pull/10900>
[13:43] <mup> PR snapd#10901 opened: overlord: add managers unit test demonstrating cyclic dependency between gadget and kernel updates <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10901>
[15:23] <mup> PR snapd#10879 closed: gadget/ondisk.go: add listBlockDevices() to get all block devices on a system <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10879>
[15:48] <mup> PR snapd#10902 opened: interfaces/apparmor: allow read access to random files for haveged <Created by snowsky> <https://github.com/snapcore/snapd/pull/10902>
[16:59] <mup> PR snapd#10903 opened: gadget/ondisk.go: include the filesystem UUID in the returned OnDiskVolume <Simple 😃> <Skip spread> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10903>
[17:24] <mup> PR snapd#10904 opened: osutil/disks, many: switch to defining Partitions directly for MockDiskMapping <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10904>
[18:06] <holmanb> 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] <holmanb> Is this the primary reason?
[18:24] <mup> PR snapd#10902 closed: interfaces/apparmor: allow read access to random files for haveged <Needs security review> <Created by snowsky> <Closed by snowsky> <https://github.com/snapcore/snapd/pull/10902>
[18:26] <ogra> 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] <holmanb> 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] <ogra> 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] <ogra> *that the
[18:39] <ogra> (you nearly seen no boot impact on NVME disks, SSDs and the like)
[18:40] <holmanb> ogra: I was testing in lxd, would that affect it perhaps?
[18:40] <holmanb> I'm on NVME
[18:40] <ogra> hmm, it might 
[18:41] <ogra> i rarely have snaps in my lxd containers (i use them to build snaps though 🙂 )
[18:41] <ogra> though lxd usually does not do an actual boot unless you use a VM backend of it
[18:42] <holmanb> ogra: checked how system, snapd time in critical-chain is negligable (150ms)
[18:43] <holmanb> *host
[18:43] <ogra> yeah, thats typical
[18:44] <ogra> ogra@acheron:~$ systemd-analyze critical-chain|grep snapd
[18:44] <ogra>               └─snapd.socket @13.583s 👍ms
[18:44] <ogra>                   └─snapd.apparmor.service @13.089s +488ms
[18:44] <ogra> ogra@acheron:~$ snap list | wc -l
[18:44] <holmanb> in lxd snapd took up over half the total boot time
[18:44] <ogra> 103
[18:44] <ogra> heh
[18:45] <ogra> my emoji plugin thought it shuld give the 1ms a thumbs up 🙂
[18:45] <holmanb> XD
[18:45] <holmanb> ```
[18:45] <holmanb> root@me:~/cloud-init-logs-2021-10-08# systemd-analyze critical-chain | grep snapd
[18:45] <holmanb>   └─snapd.seeded.service @9.679s +6.108s
[18:45] <holmanb>     └─snapd.service @7.639s +2.036s
[18:45] <holmanb>           └─snapd.socket @7.586s +2ms
[18:45] <holmanb> root@me:~/cloud-init-logs-2021-10-08# snap list | wc -l
[18:45] <holmanb> 4
[18:45] <holmanb> root@me:~/cloud-init-logs-2021-10-08# systemd-analyze 
[18:45] <holmanb> Startup finished in 17.694s (userspace) 
[18:45] <holmanb> graphical.target reached after 15.791s in userspace
[18:46] <holmanb> ```
[18:46] <holmanb> in case that's of any value ^^
[18:46] <ogra> that soounds rather normal ... 
[18:47] <ogra> you can technically disable the snapd.service unit, a use of any snap command should launch it via the socket anyway
[18:48] <ogra> snap seeding usually only happens on first boot, i wonder why you see it there 
[18:49] <holmanb> 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] <holmanb> Thanks for answering some newbie questions :)
[18:49] <ogra> np ... we've all been newbies once 😉
[19:18] <mup> PR snapcraft#3589 opened: snap: correct patch apply for patchelf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589>
[20:53] <mup> PR snapcraft#3589 closed: snap: correct patch apply for patchelf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589>