/srv/irclogs.ubuntu.com/2021/10/08/#snappy.txt

mborzeckimorning05:45
flotter<ijohnson[m]> - Great. No issues. Yes, testing will be next.05:48
mardyhi mborzecki!06:04
mborzeckimardy: hey06:04
mborzeckimeh, the opensuse i586 build on obs fails on go-efilib, unclear why07:20
mborzeckiunless the source tarball is missing dependencies maybe?07:21
mupPR 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>07:32
mupPR snapd#10899 opened: packaging: fixes for building on openSUSE <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899>08:22
mborzeckitrivial PR ^^08:28
mvomborzecki: thanks!08:29
jameshmvo: 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
mupPR #10173: interfaces: add polkit security backend <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/10173>08:32
mvojamesh: sure08:32
jameshthank you08:32
mupPR 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:37
flotterHACKING.md: Note that if you are using go 1.16 or newer you need to disable the08:59
flottergo modules feature. Use: export GO111MODULE=off08:59
flotterIs 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
mvoflotter: that is no longer true I think, it might be a overlook09:00
mvoflotter: we moved to 1.13 recently so this may be outdated09:00
flotterok thx, this is what I thought.09:02
flotterThe HACKING.md guide attempts help users for 3 cases: "From snapd 2.52, snapd supports Go 1.13 and onwards. From snapd 2.3809:04
flotterto 2.52, snapd requires Go 1.9+. Versions before 2.38 support Go 1.6+."09:04
flotterDo 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
flotterWould 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 clear09:05
mborzeckizyga-mbp: hi, can you take a look at https://build.opensuse.org/request/show/924171 ?09:16
mborzeckimardy: can you take a look at https://github.com/snapcore/snapd/pull/10899 ?10:06
mupPR #10899: packaging: fixes for building on openSUSE <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899>10:06
mardymborzecki: +1, minor suggestion11:16
mupPR 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>11:58
miguelpiresmvo: can you merge https://github.com/snapcore/snapd/pull/10897, please? spread failures seem unrelated12:17
mupPR #10897: osutil: ensure parent dir is opened and sync'd <Simple πŸ˜ƒ> <Created by MiguelPires> <https://github.com/snapcore/snapd/pull/10897>12:17
zyga-mbpgood morning12:23
zyga-mbpmvo: rpi4 now supports secure boot12:24
ograzyga-mbp, you mean they added a proper TPM?12:24
zyga-mbpmvo: I've got a working low cost automation solution for rpi4 (extensible to all versions), off the shelf components and low complexity12:24
zyga-mbpogra nope12:24
zyga-mbpmvo: 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:24
zyga-mbpmvo: 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-mbpogra: https://github.com/raspberrypi/usbboot/pull/93/files12:25
mupPR 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-mbpthis is better12:25
zyga-mbpogra: one-time programmable though12:26
zyga-mbpogra but has a nice test mode to check it works before going in with the fuse burner12:26
ograzyga-mbp, OOOH ! signing the EEPROM itself !!12:26
zyga-mbpeeprom, eeprom config and the image12:26
zyga-mbp(booted image)12:26
ograyeah12:26
zyga-mbpread that, it's cool12:26
ogravery nice12:27
* zyga-mbp will write control software to spread-automate pi4 at home and in his office lab12:28
zyga-mbphappy to share and co-develop if you have interest and cycles12:29
* zyga-mbp reboots, back after update12:33
mupPR snapd#10900 opened: o/devistate: introduce DeviceManager.Unregister <Created by pedronis> <https://github.com/snapcore/snapd/pull/10900>12:43
mupPR 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>13:43
mupPR 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:23
mupPR snapd#10902 opened: interfaces/apparmor: allow read access to random files for haveged <Created by snowsky> <https://github.com/snapcore/snapd/pull/10902>15:48
mupPR 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>16:59
mupPR snapd#10904 opened: osutil/disks, many: switch to defining Partitions directly for MockDiskMapping <Simple πŸ˜ƒ> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10904>17:24
holmanbQuestion 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
holmanbIs this the primary reason?18:06
mupPR 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:24
ograholmanb, 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 packages18:26
holmanbogra: 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:33
ograwell, 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 the18:39
ogra(you nearly seen no boot impact on NVME disks, SSDs and the like)18:39
holmanbogra: I was testing in lxd, would that affect it perhaps?18:40
holmanbI'm on NVME18:40
ograhmm, it might 18:40
ograi rarely have snaps in my lxd containers (i use them to build snaps though πŸ™‚ )18:41
ograthough lxd usually does not do an actual boot unless you use a VM backend of it18:41
holmanbogra: checked how system, snapd time in critical-chain is negligable (150ms)18:42
holmanb*host18:43
ograyeah, thats typical18:43
ograogra@acheron:~$ systemd-analyze critical-chain|grep snapd18:44
ogra              β””─snapd.socket @13.583s πŸ‘ms18:44
ogra                  β””─snapd.apparmor.service @13.089s +488ms18:44
ograogra@acheron:~$ snap list | wc -l18:44
holmanbin lxd snapd took up over half the total boot time18:44
ogra10318:44
ograheh18:44
ogramy emoji plugin thought it shuld give the 1ms a thumbs up πŸ™‚18:45
holmanbXD18:45
holmanb```18:45
holmanbroot@me:~/cloud-init-logs-2021-10-08# systemd-analyze critical-chain | grep snapd18:45
holmanb  β””─snapd.seeded.service @9.679s +6.108s18:45
holmanb    β””─snapd.service @7.639s +2.036s18:45
holmanb          β””─snapd.socket @7.586s +2ms18:45
holmanbroot@me:~/cloud-init-logs-2021-10-08# snap list | wc -l18:45
holmanb418:45
holmanbroot@me:~/cloud-init-logs-2021-10-08# systemd-analyze 18:45
holmanbStartup finished in 17.694s (userspace) 18:45
holmanbgraphical.target reached after 15.791s in userspace18:45
holmanb```18:46
holmanbin case that's of any value ^^18:46
ograthat soounds rather normal ... 18:46
ograyou can technically disable the snapd.service unit, a use of any snap command should launch it via the socket anyway18:47
ograsnap seeding usually only happens on first boot, i wonder why you see it there 18:48
holmanbSure, 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 snaps18:49
holmanbThanks for answering some newbie questions :)18:49
ogranp ... we've all been newbies once πŸ˜‰18:49
mupPR snapcraft#3589 opened: snap: correct patch apply for patchelf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589>19:18
mupPR snapcraft#3589 closed: snap: correct patch apply for patchelf <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589>20:53
=== not_phunyguy is now known as phunyguy

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!