[05:04] <mup> PR snapd#9413 closed: tests/lib/nested.sh: more little tweaks <Run nested> <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9413>
[05:09] <mup> PR snapd#9408 closed: tests/core/snap-debug-bootvars: spread test for snap debug boot-vars <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9408>
[05:14] <mup> PR snapd#9412 closed: many/apparmor: adjust rules for reading profile/ execing new profiles for new kernel <Bug> <Needs security review> <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9412>
[05:16] <mborzecki> morning
[05:16] <mvo> hey mborzecki
[05:16] <mborzecki> mvo: hey!
[05:16] <mvo> mborzecki: https://github.com/snapcore/snapd/pull/9408#discussion_r494363642 is something to consider for a followup, I merged the PR anyway so this is just FYI :)
[05:16] <mup> PR #9408: tests/core/snap-debug-bootvars: spread test for snap debug boot-vars <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9408>
[05:17] <mborzecki> mvo: ah, cool, thanks!
[05:35] <mborzecki> mvo: opened, #9415
[05:35] <mup> PR #9415: tests/core/snap-debug-bootvars: also check snap_mode <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9415>
[05:35] <mborzecki> ok, off to school, back in 30 or os
[05:35] <mborzecki> so
[05:39] <mup> PR snapd#9415 opened: tests/core/snap-debug-bootvars: also check snap_mode <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9415>
[05:50] <zyga> good morning
[05:50] <zyga> jamesh: o/
[05:50] <zyga> jamesh: I sent the fdo binding yesterday
[05:51] <zyga> jamesh: if you have the time, I would love a quick look
[05:51] <zyga> mvo: o/
[05:51] <zyga> mborzecki: hey
[05:51] <zyga> mborzecki: I need your help today
[05:52] <zyga> mborzecki: do you have 30 minutes for a review of the other project PRs
[06:12] <mborzecki> back, and ofc there was a short power outage
[06:18] <jamesh> zyga: I'll check it out
[06:29] <zyga> mborzecki: ooops
[06:29] <zyga> jamesh: thank you
[06:59] <pstolowski> morning
[07:09]  * zyga-x240 needs to spend time with lucy now
[07:17] <zyga-x240> I guess I will be partially online until 11
[07:18] <zyga-x240> I'm working on user agent sending notifications now
[08:11] <pstolowski> hmm i think we might have an issue with presseding on 20.10 soon, currently manifesting in our spread test but may be real soon
[08:12] <pstolowski> due to glibc abi change
[08:16] <pstolowski> unless i'm missing something; actually i'm surprised it's not failing already
[08:17] <zyga-x240> pstolowski: is it a real issue or just an issue with our tests?
[08:20] <pstolowski> zyga-x240: snap-preseed runs snapd in a chroot either from the deb of the chroot system, or from snapd snap of the seeded system (by mounting snapd snap directly)
[08:20] <pstolowski> zyga-x240: whichever is newer
[08:20] <zyga-x240> pstolowski: I see
[08:20] <zyga-x240> pstolowski: can we link snap-preseed statically?
[08:20] <pstolowski> zyga-x240: it doesn't mount snapd over core18, just runs the binary directly, so it depends on the libs of host system
[08:21] <pstolowski> zyga-x240: it's not snap-preseed problem
[08:21] <pstolowski> zyga-x240: it is the way it runs snapd binary under chroot
[08:22] <pstolowski> zyga-x240: do you have a sec for HO?
[08:22] <zyga-x240> pstolowski: I have a call in a moment, I need to prepare, can we do it in ~ 45 minutes?
[08:22] <pstolowski> sure
[08:36] <pstolowski> hmm it may be a quirk of our spread builds. i can't reproduce with snapd from real snap
=== seb128_ is now known as seb128
[09:18] <pedronis> pstolowski: the snapd from a real snap is built for xenial, but in the test it's built with the newest stuff
[09:23] <mborzecki> really trivial PR: https://github.com/snapcore/snapd/pull/9416 (cc pstolowski zyga-x240)
[09:23] <mup> PR #9416: boot: use test helpers <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9416>
[09:24] <pstolowski> pedronis: yes, but somehow with real snapd snap i'm not hitting /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /tmp/snapd-preseed/usr/lib/snapd/snapd, only with the one from test
[09:25] <mup> PR snapd#9416 opened: boot: use test helpers <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9416>
[09:26] <zyga-x240> mborzecki: ack
[09:27] <zyga-x240> mborzecki: done
[09:27] <mborzecki>  thx
[09:55] <pstolowski> pedronis: ok, mystery solved (thanks to zyga's hunch), the image inside is outdated and we 're building with newer glibc (and then injecting into the image)
[09:55] <pstolowski> it's about 20.10 to be clear
[10:05] <mup> PR snapd#9415 closed: tests/core/snap-debug-bootvars: also check snap_mode <Simple 😃> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/9415>
[10:55] <mup> PR snapd#9416 closed: boot: use test helpers <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9416>
[11:55]  * pstolowski lunch
[11:56] <mup> PR snapd#9417 opened: [RFC] o/snapshotstate: set snapshot set id from its filename <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9417>
[12:21] <cachio> zyga, hey, I addressed comments on #8986
[12:21] <mup> PR #8986: tests: new snaps-state command - part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8986>
[12:21] <zyga-mbp> cachio looking
[12:21] <cachio> zyga-mbp, tx
[12:23] <zyga-mbp> cachio +1 :)
[12:24] <cachio> zyga-mbp, nice thanks
[12:32] <pstolowski> cachio: hey, cloud image used  for preseed test is older than the spread host image and causes glibc error, can we update it?
[12:32] <pstolowski> cachio: see my standup notes
[12:33] <cachio> pstolowski, hey, sure, let me check
[12:34] <cachio> pstolowski, job retriggered
[12:35] <pstolowski> cachio: did you upgrade the image already? it has been failing like this for a few days on various PRs
[12:35] <pstolowski> cachio: and i've tested manually this morning
[12:35] <cachio> the last upgrade was on Monday
[12:35] <pstolowski> cachio: so it's going to fail
[12:36] <cachio> pstolowski, now it is updating the images again
[12:36] <pstolowski> cachio: i've compared glibc versions this morning
[12:36] <mup> PR snapd#9400 closed: o/assertstate: support refreshing any number of snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/9400>
[12:37] <cachio> let see in few minutes with the new image
[12:39] <cachio> pstolowski, the new image is deployed
[12:39] <pstolowski> cachio: great,thanks
[12:45] <ijohnson> cachio: did the 18.04 images on spread change recently?
[12:45] <ijohnson> I see the mount-ns:inherit task failed on 18.04 this morning, with the /boot/efi mountpoint disappearing
[12:46] <ijohnson> cachio: zyga-mbp: see https://pastebin.ubuntu.com/p/k57sf9X5Zp/
[12:47] <zyga-mbp> mmm
[12:47] <ijohnson> afair this was from an upstream image change wasn't it?
[12:47] <zyga-mbp> did we drop /boot/efi?
[12:47] <ijohnson> that's what I'm wondering
[12:47] <zyga-mbp> it looks like it
[12:47] <zyga-mbp> cachio ^
[12:47] <zyga-mbp> did the  18.04 image change?
[12:48] <cachio> let me check which image is used onthat test
[12:48] <ijohnson> cachio: it very recently failed, like 15 minutes ago
[12:49] <cachio> that image didnt change since Monday
[12:49] <cachio> ijohnson, I just updated the image we use for preseed
[12:51] <zyga-mbp> huh
[12:51] <ijohnson> cachio: mmm so why did the /boot/efi mount disappear
[12:51] <zyga-mbp> are we getting a random image or perhaps are we getting something that unmounts /boot/efi?
[12:51] <zyga-mbp> ijohnson is any test doing anything with /boot that you recall
[12:52] <ijohnson> I wonder if this is our eternal "maybe we got a random image on gce" problem
[12:52] <ijohnson> zyga-mbp: let me take a look but not on classic I'm pretty sure
[12:53] <cachio> ijohnson, I am starting a fresh image
[12:53] <cachio> to check if it is either something on the image or something produced by another test
[12:54] <cachio> ls /boot/efi/
[12:54] <cachio> EFI  boot
[12:54] <cachio> ijohnson, I see that in the image
[12:54] <ijohnson> cachio: yeah that's expected
[12:55] <ijohnson> cachio: actually wait can you do `cat /proc/self/mountinfo | grep /boot` ?
[12:56] <cachio> 98 30 8:15 / /boot/efi rw,relatime shared:37 - vfat /dev/sda15 rw,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
[12:56] <zyga-mbp> looks sensible
[12:56] <zyga-mbp> weird right?
[14:12]  * zyga-mbp lunch
[14:34] <mborzecki> pedronis: some trivial comment tweaks https://github.com/snapcore/secboot/pull/116#pullrequestreview-496467458
[14:34] <mup> PR secboot#116: Have a single ActivateVolumeOptions struct for the ActivateVolumeWith* family <Created by pedronis> <https://github.com/snapcore/secboot/pull/116>
[14:51]  * cachio lunch
[14:55] <pedronis> mborzecki: thanks, yes I agree about the comment wrapping but is a bit its own problem, at some point we might go ahead and rewrap everything
[14:55] <pedronis> we need a time where things are a bit calm
[14:56] <mborzecki> yup, it's all cosmetics so no ruch really
[15:02] <mup> PR snapcraft#3296 closed: meta: write stubs for command-chain using hooks when needed <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3296>
[15:02] <mup> PR snapcraft#3297 opened: cli: support snap --output <directory> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3297>
[15:20] <ijohnson> pedronis: sorry I have some nitpicks/suggestions on that secboot pr
[15:21] <pedronis> ijohnson: it's fine, I don't think I'll apply at this time the suggestions about the field names though, those field names had names like that in the old code.
[15:22] <ijohnson> ok, fair enough
[15:22] <pedronis> I don't feel strong enough either way.
[15:22] <pedronis> ijohnson: the improvement to the comments are welcome though
[15:22] <ijohnson> that's fair
[15:31] <pedronis> ijohnson: pushed, can you checked I applied the feedback correctly ?
[15:31] <pedronis> *check
[15:31] <ijohnson> pedronis: sure
[15:31] <pedronis> thx
[15:34] <ijohnson> pedronis: one suggestion seems to have been missed, unclear if it was intentional or not https://github.com/snapcore/secboot/pull/116#discussion_r495037072
[15:34] <mup> PR secboot#116: Have a single ActivateVolumeOptions struct for the ActivateVolumeWith* family <Created by pedronis> <https://github.com/snapcore/secboot/pull/116>
[15:35] <pedronis> ijohnson: I misread it, sorry
[15:47] <ijohnson> pedronis: thoughts about making `snap watch` work on multiple changes or introducing a `snap watch-all`? I'm wondering about what the interface could look like in the case that console-conf is going to wait for refreshes to be done
[15:47] <ijohnson> pedronis: alternatively we could have a `snap routine console-conf-refresh-done` which just returns exit codes depending on whether it's ready or not
[15:48] <ijohnson> s/it's ready/refresh changes are done/
[15:48] <pedronis> ijohnson: I thought we would wait in our own console-conf-start
[15:48] <ijohnson> pedronis: ah hmm do we do a simple UI then of just "System is updating please wait" or something?
[15:49] <ijohnson> pedronis: I guess I have the preference to let console-conf do nice looking UI things
[15:49] <ijohnson> but for 1.0 perhaps a simple message while waiting inside snapd is fine
[15:49] <pedronis> do we know they will do them though?
[15:49] <ijohnson> no I guess we don't know that
[15:50] <pedronis> to be clear, I would prefer a nicer UI, but my plan was to be able to just add a line to the wrapper for now
[15:51] <ijohnson> pedronis: ok so if snapd does the waiting should we  wait in the snap client re-trying to get a lock and have things done or should we return a change ID and essentially have the snap client call "watch" or some such on the change ID ?
[15:51] <ijohnson> I guess plural as there could be multiple change ID's
[15:53] <pedronis> ijohnson: sorry, I probably forgot that is not always reboot, but also waiting in some cases
[15:54] <ijohnson> right I was going to do the simple thing and just treat any snap refreshes as something that console-conf should wait for
[15:54] <ijohnson> pedronis: also is it okay to ignore gadget defaults for refresh related settings for now?
[15:55] <pedronis> ijohnson: can we chat for a moment in the standup ?
[15:55] <ijohnson> pedronis: seems highly unlikely that a gadget with default settings for refresh things will actually be used with console-conf irl
[15:55] <ijohnson> pedronis: sure one moment
[15:57] <ijohnson> pedronis: in the SU
[16:08] <pstolowski> ijohnson: i've set milestone to 2.49 on https://github.com/snapcore/snapd/pull/8960 after discussing with mvo, with the idea of landing it right after branching 2.48; it would be great to have it ready and reviewed by then and just waiting for merging, so pretty please ;)
[16:08] <mup> PR #8960: o/snapstate,servicestate: use service-control task for service actions (9/9) <Needs Samuele review> <Services ⚙️> <⛔ Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8960>
[16:15] <ijohnson> pstolowski: yes of course, may not get to it today like I planned, trying to wrap up uc20 1.0 things for 2.47 today but definitely early next week
[16:15] <pstolowski> ijohnson: sure, sounds good
[17:57] <mup> PR snapcraft#3298 opened: [WIP] lxd remote build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3298>
[18:44]  * cachio -> kinesiologist
[18:50] <cmatsuoka> ijohnson: hmm, how do you recreate the pi initramfs on amd64? I tried the simple approach and got an invalid magic error
[18:51] <ijohnson> cmatsuoka what do you mean recreate it?
[18:51] <cmatsuoka> ijohnson: I need to inject a new snap-bootstrap into it
[18:52] <cmatsuoka> ijohnson: so I opened it, replaced the snap-bootstrap binary and repacked it, but probably my repacking isn't that good
[18:53] <ijohnson> ah one minute
[18:56] <ijohnson> cmatsuoka: so I haven't done this recently but I think it works to just call ubuntu-core-initramfs directly to rebuild just the initrd, without building the efi
[18:56] <ijohnson> alternatively what I definitely remember doing is to call ubuntu-core-initramfs from the same arm architecture to just rebuild the initrd itself
[18:57] <ijohnson> so for armhf, get an armhf 20.04 env and install ubuntu-core-initramfs there and call it directly
[18:58] <cmatsuoka> hmm interesting, I didn't try to use it because I thought it would place an amd64 skeleton there
[18:58] <cmatsuoka> anyway, I'll try that, thanks
[18:59] <cmatsuoka> well I can extract the skeleton from the existing initramfs
[18:59] <ijohnson> cmatsuoka: right that's the thing is that you have to use the armhf skeleton
[18:59] <ijohnson> and just use ubuntu-core-initramfs to package it up
[18:59] <ijohnson> but I may be wrong here
[19:00] <cmatsuoka> we'll soon find out :)
[19:01] <ijohnson> what the only script I have from before was doing is cross-compiling snap-bootstrap for arm64, then scp it to my other pi, then call ubuntu-core-initramfs on it from there and scp the initrd.img back to my desktop for assembly into the kernel snap and resultant image
[20:07] <mup> PR snapcraft#3299 opened: extensions: configure hook for fonts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3299>
[20:08] <mup> PR snapd#9418 opened: [WIP] many: add routine command + REST API to delay refreshes while running console-conf <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9418>