mborzecki | morning | 05:45 |
---|---|---|
flotter | <ijohnson[m]> - Great. No issues. Yes, testing will be next. | 05:48 |
mardy | hi mborzecki! | 06:04 |
mborzecki | mardy: hey | 06:04 |
mborzecki | meh, the opensuse i586 build on obs fails on go-efilib, unclear why | 07:20 |
mborzecki | unless the source tarball is missing dependencies maybe? | 07:21 |
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> | 07:32 |
mup | PR snapd#10899 opened: packaging: fixes for building on openSUSE <Simple π> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10899> | 08:22 |
mborzecki | trivial PR ^^ | 08:28 |
mvo | mborzecki: thanks! | 08:29 |
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:32 |
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:37 |
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 | 08:59 |
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:00 |
flotter | ok thx, this is what I thought. | 09:02 |
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:04 |
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:05 |
mborzecki | zyga-mbp: hi, can you take a look at https://build.opensuse.org/request/show/924171 ? | 09:16 |
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> | 10:06 |
mardy | mborzecki: +1, minor suggestion | 11:16 |
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> | 11:58 |
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:17 |
zyga-mbp | good morning | 12:23 |
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:24 |
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:25 |
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:26 |
ogra | very nice | 12:27 |
* zyga-mbp will write control software to spread-automate pi4 at home and in his office lab | 12:28 | |
zyga-mbp | happy to share and co-develop if you have interest and cycles | 12:29 |
* zyga-mbp reboots, back after update | 12:33 | |
mup | PR snapd#10900 opened: o/devistate: introduce DeviceManager.Unregister <Created by pedronis> <https://github.com/snapcore/snapd/pull/10900> | 12: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> | 13:43 |
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:23 |
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> | 15:48 |
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> | 16:59 |
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> | 17:24 |
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:06 |
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:24 |
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:26 |
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:33 |
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:39 |
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:40 |
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:41 |
holmanb | ogra: checked how system, snapd time in critical-chain is negligable (150ms) | 18:42 |
holmanb | *host | 18:43 |
ogra | yeah, thats typical | 18:43 |
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:44 |
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:45 |
holmanb | ``` | 18:46 |
holmanb | in case that's of any value ^^ | 18:46 |
ogra | that soounds rather normal ... | 18:46 |
ogra | you can technically disable the snapd.service unit, a use of any snap command should launch it via the socket anyway | 18:47 |
ogra | snap seeding usually only happens on first boot, i wonder why you see it there | 18:48 |
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 π | 18:49 |
mup | PR snapcraft#3589 opened: snap: correct patch apply for patchelf <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3589> | 19:18 |
mup | PR 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!