mupPR 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
mupPR 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
mupPR 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
mvohey mborzecki05:16
mborzeckimvo: hey!05:16
mvomborzecki: 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
mupPR #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
mborzeckimvo: ah, cool, thanks!05:17
mborzeckimvo: opened, #941505:35
mupPR #9415: tests/core/snap-debug-bootvars: also check snap_mode <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9415>05:35
mborzeckiok, off to school, back in 30 or os05:35
mupPR 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
zygagood morning05:50
zygajamesh: o/05:50
zygajamesh: I sent the fdo binding yesterday05:50
zygajamesh: if you have the time, I would love a quick look05:51
zygamvo: o/05:51
zygamborzecki: hey05:51
zygamborzecki: I need your help today05:51
zygamborzecki: do you have 30 minutes for a review of the other project PRs05:52
mborzeckiback, and ofc there was a short power outage06:12
jameshzyga: I'll check it out06:18
zygamborzecki: ooops06:29
zygajamesh: thank you06:29
* zyga-x240 needs to spend time with lucy now07:09
zyga-x240I guess I will be partially online until 1107:17
zyga-x240I'm working on user agent sending notifications now07:18
pstolowskihmm i think we might have an issue with presseding on 20.10 soon, currently manifesting in our spread test but may be real soon08:11
pstolowskidue to glibc abi change08:12
pstolowskiunless i'm missing something; actually i'm surprised it's not failing already08:16
zyga-x240pstolowski: is it a real issue or just an issue with our tests?08:17
pstolowskizyga-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
pstolowskizyga-x240: whichever is newer08:20
zyga-x240pstolowski: I see08:20
zyga-x240pstolowski: can we link snap-preseed statically?08:20
pstolowskizyga-x240: it doesn't mount snapd over core18, just runs the binary directly, so it depends on the libs of host system08:20
pstolowskizyga-x240: it's not snap-preseed problem08:21
pstolowskizyga-x240: it is the way it runs snapd binary under chroot08:21
pstolowskizyga-x240: do you have a sec for HO?08:22
zyga-x240pstolowski: I have a call in a moment, I need to prepare, can we do it in ~ 45 minutes?08:22
pstolowskihmm it may be a quirk of our spread builds. i can't reproduce with snapd from real snap08:36
=== seb128_ is now known as seb128
pedronispstolowski: the snapd from a real snap is built for xenial, but in the test it's built with the newest stuff09:18
mborzeckireally trivial PR: https://github.com/snapcore/snapd/pull/9416 (cc pstolowski zyga-x240)09:23
mupPR #9416: boot: use test helpers <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9416>09:23
pstolowskipedronis: 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 test09:24
mupPR snapd#9416 opened: boot: use test helpers <Simple 😃> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9416>09:25
zyga-x240mborzecki: ack09:26
zyga-x240mborzecki: done09:27
mborzecki thx09:27
pstolowskipedronis: 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
pstolowskiit's about 20.10 to be clear09:55
mupPR 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
mupPR 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 lunch11:55
mupPR 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
cachiozyga, hey, I addressed comments on #898612:21
mupPR #8986: tests: new snaps-state command - part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8986>12:21
zyga-mbpcachio looking12:21
cachiozyga-mbp, tx12:21
zyga-mbpcachio +1 :)12:23
cachiozyga-mbp, nice thanks12:24
pstolowskicachio: hey, cloud image used  for preseed test is older than the spread host image and causes glibc error, can we update it?12:32
pstolowskicachio: see my standup notes12:32
cachiopstolowski, hey, sure, let me check12:33
cachiopstolowski, job retriggered12:34
pstolowskicachio: did you upgrade the image already? it has been failing like this for a few days on various PRs12:35
pstolowskicachio: and i've tested manually this morning12:35
cachiothe last upgrade was on Monday12:35
pstolowskicachio: so it's going to fail12:35
cachiopstolowski, now it is updating the images again12:36
pstolowskicachio: i've compared glibc versions this morning12:36
mupPR 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
cachiolet see in few minutes with the new image12:37
cachiopstolowski, the new image is deployed12:39
pstolowskicachio: great,thanks12:39
ijohnsoncachio: did the 18.04 images on spread change recently?12:45
ijohnsonI see the mount-ns:inherit task failed on 18.04 this morning, with the /boot/efi mountpoint disappearing12:45
ijohnsoncachio: zyga-mbp: see https://pastebin.ubuntu.com/p/k57sf9X5Zp/12:46
ijohnsonafair this was from an upstream image change wasn't it?12:47
zyga-mbpdid we drop /boot/efi?12:47
ijohnsonthat's what I'm wondering12:47
zyga-mbpit looks like it12:47
zyga-mbpcachio ^12:47
zyga-mbpdid the  18.04 image change?12:47
cachiolet me check which image is used onthat test12:48
ijohnsoncachio: it very recently failed, like 15 minutes ago12:48
cachiothat image didnt change since Monday12:49
cachioijohnson, I just updated the image we use for preseed12:49
ijohnsoncachio: mmm so why did the /boot/efi mount disappear12:51
zyga-mbpare we getting a random image or perhaps are we getting something that unmounts /boot/efi?12:51
zyga-mbpijohnson is any test doing anything with /boot that you recall12:51
ijohnsonI wonder if this is our eternal "maybe we got a random image on gce" problem12:52
ijohnsonzyga-mbp: let me take a look but not on classic I'm pretty sure12:52
cachioijohnson, I am starting a fresh image12:53
cachioto check if it is either something on the image or something produced by another test12:53
cachiols /boot/efi/12:54
cachioEFI  boot12:54
cachioijohnson, I see that in the image12:54
ijohnsoncachio: yeah that's expected12:54
ijohnsoncachio: actually wait can you do `cat /proc/self/mountinfo | grep /boot` ?12:55
cachio98 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-ro12:56
zyga-mbplooks sensible12:56
zyga-mbpweird right?12:56
* zyga-mbp lunch14:12
mborzeckipedronis: some trivial comment tweaks https://github.com/snapcore/secboot/pull/116#pullrequestreview-49646745814:34
mupPR secboot#116: Have a single ActivateVolumeOptions struct for the ActivateVolumeWith* family <Created by pedronis> <https://github.com/snapcore/secboot/pull/116>14:34
* cachio lunch14:51
pedronismborzecki: thanks, yes I agree about the comment wrapping but is a bit its own problem, at some point we might go ahead and rewrap everything14:55
pedroniswe need a time where things are a bit calm14:55
mborzeckiyup, it's all cosmetics so no ruch really14:56
mupPR 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
mupPR snapcraft#3297 opened: cli: support snap --output <directory> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3297>15:02
ijohnsonpedronis: sorry I have some nitpicks/suggestions on that secboot pr15:20
pedronisijohnson: 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
ijohnsonok, fair enough15:22
pedronisI don't feel strong enough either way.15:22
pedronisijohnson: the improvement to the comments are welcome though15:22
ijohnsonthat's fair15:22
pedronisijohnson: pushed, can you checked I applied the feedback correctly ?15:31
ijohnsonpedronis: sure15:31
ijohnsonpedronis: one suggestion seems to have been missed, unclear if it was intentional or not https://github.com/snapcore/secboot/pull/116#discussion_r49503707215:34
mupPR secboot#116: Have a single ActivateVolumeOptions struct for the ActivateVolumeWith* family <Created by pedronis> <https://github.com/snapcore/secboot/pull/116>15:34
pedronisijohnson: I misread it, sorry15:35
ijohnsonpedronis: 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 done15:47
ijohnsonpedronis: alternatively we could have a `snap routine console-conf-refresh-done` which just returns exit codes depending on whether it's ready or not15:47
ijohnsons/it's ready/refresh changes are done/15:48
pedronisijohnson: I thought we would wait in our own console-conf-start15:48
ijohnsonpedronis: ah hmm do we do a simple UI then of just "System is updating please wait" or something?15:48
ijohnsonpedronis: I guess I have the preference to let console-conf do nice looking UI things15:49
ijohnsonbut for 1.0 perhaps a simple message while waiting inside snapd is fine15:49
pedronisdo we know they will do them though?15:49
ijohnsonno I guess we don't know that15:49
pedronisto be clear, I would prefer a nicer UI, but my plan was to be able to just add a line to the wrapper for now15:50
ijohnsonpedronis: 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
ijohnsonI guess plural as there could be multiple change ID's15:51
pedronisijohnson: sorry, I probably forgot that is not always reboot, but also waiting in some cases15:53
ijohnsonright I was going to do the simple thing and just treat any snap refreshes as something that console-conf should wait for15:54
ijohnsonpedronis: also is it okay to ignore gadget defaults for refresh related settings for now?15:54
pedronisijohnson: can we chat for a moment in the standup ?15:55
ijohnsonpedronis: seems highly unlikely that a gadget with default settings for refresh things will actually be used with console-conf irl15:55
ijohnsonpedronis: sure one moment15:55
ijohnsonpedronis: in the SU15:57
pstolowskiijohnson: 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
mupPR #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
ijohnsonpstolowski: 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 week16:15
pstolowskiijohnson: sure, sounds good16:15
mupPR snapcraft#3298 opened: [WIP] lxd remote build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3298>17:57
* cachio -> kinesiologist18:44
cmatsuokaijohnson: hmm, how do you recreate the pi initramfs on amd64? I tried the simple approach and got an invalid magic error18:50
ijohnsoncmatsuoka what do you mean recreate it?18:51
cmatsuokaijohnson: I need to inject a new snap-bootstrap into it18:51
cmatsuokaijohnson: so I opened it, replaced the snap-bootstrap binary and repacked it, but probably my repacking isn't that good18:52
ijohnsonah one minute18:53
ijohnsoncmatsuoka: 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 efi18:56
ijohnsonalternatively what I definitely remember doing is to call ubuntu-core-initramfs from the same arm architecture to just rebuild the initrd itself18:56
ijohnsonso for armhf, get an armhf 20.04 env and install ubuntu-core-initramfs there and call it directly18:57
cmatsuokahmm interesting, I didn't try to use it because I thought it would place an amd64 skeleton there18:58
cmatsuokaanyway, I'll try that, thanks18:58
cmatsuokawell I can extract the skeleton from the existing initramfs18:59
ijohnsoncmatsuoka: right that's the thing is that you have to use the armhf skeleton18:59
ijohnsonand just use ubuntu-core-initramfs to package it up18:59
ijohnsonbut I may be wrong here18:59
cmatsuokawe'll soon find out :)19:00
ijohnsonwhat 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 image19:01
mupPR snapcraft#3299 opened: extensions: configure hook for fonts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3299>20:07
mupPR 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!