| 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:04 |
|---|---|---|
| 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:09 |
| 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:14 |
| 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:16 |
| mborzecki | mvo: ah, cool, thanks! | 05:17 |
| 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:35 |
| 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:39 |
| zyga | good morning | 05:50 |
| zyga | jamesh: o/ | 05:50 |
| zyga | jamesh: I sent the fdo binding yesterday | 05:50 |
| 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:51 |
| zyga | mborzecki: do you have 30 minutes for a review of the other project PRs | 05:52 |
| mborzecki | back, and ofc there was a short power outage | 06:12 |
| jamesh | zyga: I'll check it out | 06:18 |
| zyga | mborzecki: ooops | 06:29 |
| zyga | jamesh: thank you | 06:29 |
| pstolowski | morning | 06:59 |
| * zyga-x240 needs to spend time with lucy now | 07:09 | |
| zyga-x240 | I guess I will be partially online until 11 | 07:17 |
| zyga-x240 | I'm working on user agent sending notifications now | 07:18 |
| 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:11 |
| pstolowski | due to glibc abi change | 08:12 |
| pstolowski | unless i'm missing something; actually i'm surprised it's not failing already | 08:16 |
| zyga-x240 | pstolowski: is it a real issue or just an issue with our tests? | 08:17 |
| 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:20 |
| 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:21 |
| 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:22 |
| pstolowski | hmm it may be a quirk of our spread builds. i can't reproduce with snapd from real snap | 08:36 |
| === seb128_ is now known as seb128 | ||
| pedronis | pstolowski: the snapd from a real snap is built for xenial, but in the test it's built with the newest stuff | 09:18 |
| 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:23 |
| 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:24 |
| mup | PR snapd#9416 opened: boot: use test helpers <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9416> | 09:25 |
| zyga-x240 | mborzecki: ack | 09:26 |
| zyga-x240 | mborzecki: done | 09:27 |
| mborzecki | thx | 09:27 |
| 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 | 09:55 |
| 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:05 |
| 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> | 10:55 |
| * pstolowski lunch | 11:55 | |
| 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> | 11:56 |
| 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:21 |
| zyga-mbp | cachio +1 :) | 12:23 |
| cachio | zyga-mbp, nice thanks | 12:24 |
| 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:32 |
| cachio | pstolowski, hey, sure, let me check | 12:33 |
| cachio | pstolowski, job retriggered | 12:34 |
| 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:35 |
| 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:36 |
| cachio | let see in few minutes with the new image | 12:37 |
| cachio | pstolowski, the new image is deployed | 12:39 |
| pstolowski | cachio: great,thanks | 12:39 |
| 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:45 |
| ijohnson | cachio: zyga-mbp: see https://pastebin.ubuntu.com/p/k57sf9X5Zp/ | 12:46 |
| 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:47 |
| cachio | let me check which image is used onthat test | 12:48 |
| ijohnson | cachio: it very recently failed, like 15 minutes ago | 12:48 |
| cachio | that image didnt change since Monday | 12:49 |
| cachio | ijohnson, I just updated the image we use for preseed | 12:49 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| ijohnson | cachio: actually wait can you do `cat /proc/self/mountinfo | grep /boot` ? | 12:55 |
| 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? | 12:56 |
| * zyga-mbp lunch | 14:12 | |
| 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:34 |
| * cachio lunch | 14:51 | |
| 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:55 |
| mborzecki | yup, it's all cosmetics so no ruch really | 14:56 |
| 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:02 |
| ijohnson | pedronis: sorry I have some nitpicks/suggestions on that secboot pr | 15:20 |
| 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:21 |
| 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:22 |
| 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:31 |
| 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:34 |
| pedronis | ijohnson: I misread it, sorry | 15:35 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| pedronis | ijohnson: sorry, I probably forgot that is not always reboot, but also waiting in some cases | 15:53 |
| 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:54 |
| 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:55 |
| ijohnson | pedronis: in the SU | 15:57 |
| 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:08 |
| 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 | 16:15 |
| mup | PR snapcraft#3298 opened: [WIP] lxd remote build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3298> | 17:57 |
| * cachio -> kinesiologist | 18:44 | |
| cmatsuoka | ijohnson: hmm, how do you recreate the pi initramfs on amd64? I tried the simple approach and got an invalid magic error | 18:50 |
| ijohnson | cmatsuoka what do you mean recreate it? | 18:51 |
| cmatsuoka | ijohnson: I need to inject a new snap-bootstrap into it | 18:51 |
| cmatsuoka | ijohnson: so I opened it, replaced the snap-bootstrap binary and repacked it, but probably my repacking isn't that good | 18:52 |
| ijohnson | ah one minute | 18:53 |
| 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:56 |
| ijohnson | so for armhf, get an armhf 20.04 env and install ubuntu-core-initramfs there and call it directly | 18:57 |
| 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:58 |
| 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 | 18:59 |
| cmatsuoka | we'll soon find out :) | 19:00 |
| 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 | 19:01 |
| mup | PR snapcraft#3299 opened: extensions: configure hook for fonts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3299> | 20:07 |
| 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> | 20:08 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!