[00:03] <mup> PR snapcraft#3323 opened: electron-builder spread test: sync expected snapcraft.yaml <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3323>
[00:13] <mup> PR snapcraft#3311 closed: storeapi: add releases endpoint <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3311>
[00:18] <mup> PR snapcraft#3306 closed: storeapi: add support for reporting status of progressive releases <Created by maxiberta> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3306>
[01:28] <mup> PR snapcraft#3323 closed: electron-builder spread test: sync expected snapcraft.yaml <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3323>
[06:05] <mborzecki> morning
[06:39] <zyga> good morning
[07:04] <pstolowski> morning
[07:05] <mvo> pstolowski: good morning
[07:13] <zyga> hey mvo
[07:13] <mvo> good morning zyga
[07:14] <zyga> sorry for the lag, a bit ucooperative kids today
[07:14] <zyga> *uncooperative
[07:14] <mvo> zyga: no worries
[07:27] <zyga> mborzecki can you approve https://github.com/snapcore/snapd/pull/9499 - it'd be my most approved change ever ;-)
[07:27] <mup> PR #9499: tests: add tests for fsck; cmd/s-b/initramfs-mounts: fsck ubuntu-seed too <UC20> <Created by zyga> <https://github.com/snapcore/snapd/pull/9499>
[07:27] <zyga> also reviewing ijohnson's fsck change for uc20 would be really good
[07:35] <zyga> I've de-conflicted and updated https://github.com/snapcore/snapd/pull/9422
[07:35] <mup> PR #9422: overlord: add link participant for linkage transitions <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9422>
[07:35] <zyga> I hope it's in a good shape now and we can make progress on the export manager
[07:35] <mborzecki> zyga: hm am i missing something? https://github.com/snapcore/snapd/pull/9499#discussion_r508273373
[07:35] <mup> PR #9499: tests: add tests for fsck; cmd/s-b/initramfs-mounts: fsck ubuntu-seed too <UC20> <Created by zyga> <https://github.com/snapcore/snapd/pull/9499>
[07:35] <zyga> whooops
[07:35] <zyga> how did I do that
[07:35] <zyga> sorry
[07:36] <zyga> drat
[07:36] <zyga> I understand what my editor asked me to save now
[07:36] <zyga> meh
[07:36] <zyga> I resolved and closed without saving
[07:37] <zyga> ushed
[07:37] <zyga> pushed
[07:49] <zyga> pedronis good morning
[07:49] <zyga> pedronis I've updated https://github.com/snapcore/snapd/pull/9422
[07:49] <mup> PR #9422: overlord: add link participant for linkage transitions <Needs Samuele review> <Created by zyga> <https://github.com/snapcore/snapd/pull/9422>
[07:50] <zyga> pedronis I think it should be good now, at least in principle
[07:51] <pedronis> thx, I put it back into my queue
[07:53] <pstolowski> lxd snap was fixed yesterday,  #9468 is unblocked
[07:53] <mup> PR #9468: tests: lxd smoke test <Simple 😃> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9468>
[07:56] <zyga> pedronis thanks :)
[07:56]  * zyga warmed up the tea
[07:56] <zyga> it's still very cold in the office, heating up slowly
[07:57] <zyga> pstolowski reviewed
[07:59] <zyga> I'll work on the pi kerenl thing now
[08:18] <pstolowski> zyga: thanks, adding some comments. not sure about restore, snap remove is the main check, i think the new comments will make it clear
[08:50] <mborzecki> pedronis: i've updated #9476 with some additional tweaks to make nosecboot happy
[08:50] <mup> PR #9476:  many: have install return encryption keys for data and save, improve tests <Run nested> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9476>
[09:19] <zyga> google:ubuntu-20.10-64:tests/main/snapd-reexec-snapd-snap fails on something silly, probalby assumes core is installed
[09:19] <zyga> 20.10 has snapd preinstalled
[09:19] <zyga> should we disable that test there?
[09:19] <zyga> mvo ^
[09:19] <mvo> zyga: in a meeting right now
[09:19] <zyga> k
[09:20] <mvo> zyga: sorry, can think in a bit but not right now
[09:20] <zyga> ok
[09:21] <mup> PR snapd#9499 closed: tests: add tests for fsck; cmd/s-b/initramfs-mounts: fsck ubuntu-seed too <UC20> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9499>
[09:21] <mup> PR snapd#9522 opened: o/snapstate: ignore remove errors in clear-snap handler, only log them <Created by stolowski> <https://github.com/snapcore/snapd/pull/9522>
[09:23] <zyga> pstolowski: check my comment please
[09:34] <pstolowski> pedronis: hi, if you have a moment, what's your take on warnings vs task log in #9522?
[09:34] <mup> PR #9522: o/snapstate: ignore remove errors in clear-snap handler, only log them <Created by stolowski> <https://github.com/snapcore/snapd/pull/9522>
[09:44] <zyga> booting rogrer's configuration now
[09:44] <zyga> gosh I love serial lines
[09:44] <zyga> is this a bug: /init: /scripts/init-bottom/ORDER: line 3: /scripts/init-bottom/disable-getty: Permission denied
[09:44] <zyga> ?
[09:44] <zyga> that's from initrd
[09:44] <zyga> seems like missing +x
[09:45] <zyga> second error: /usr/share/subiquity/console-conf-wrapper: line 13: snap: command not found
[09:47] <zyga> third error (trying to use wifi) https://pastebin.ubuntu.com/p/qXbB66tfjz/
[09:52] <zyga> hmmm
[09:52] <zyga> I cannot get past this
[09:53] <zyga> mborzecki do you recall this subiquity erorr ^ /
[09:53] <amurray> zyga: thanks for finishing off the snapd/apparmor3 stuff :)
[09:54] <zyga> amurray you were right after all :)
[09:55] <zyga> hmm, I wonder if subiquity will refresh
[09:57] <zyga> does anyone know if there's something I can set in uboot to bypass subiquity on core18?
[09:58] <zyga> hmmmm
[09:58] <zyga> I think the snapd snap I'm getting crashes on startup
[09:58] <zyga> [FAILED] Failed to start /tmp/tmp.spBbI7OTQH/usr/lib/snapd/snapd.
[09:58] <zyga> eh
[09:58] <zyga> pstolowski ^ any ideas?
[09:58] <zyga> ideally on how to debug any of this
[10:00] <pstolowski> zyga: is this a private build of snapd?
[10:01] <zyga> pstolowski nope
[10:01] <zyga> pstolowski ubuntu-image with the three snaps I got from mvo
[10:01] <zyga> and snapd downloaded from the store (automatically)
[10:01] <mvo> zyga: still in a meeting but i can give you more snaps if you need them
[10:02] <zyga> mvo: I think whatever is wrong here also is interesting
[10:02] <pstolowski> zyga: maybe mount the image and see if the snaps looks sane ?
[10:02] <zyga> yeah, trying now
[10:02] <pstolowski> seems like something fundamental failed
[10:06] <zyga> I think snapd did not seed
[10:06] <zyga> I've enabled journal
[10:06] <zyga> let's see what we get
[10:07] <pstolowski> mborzecki: do you have a moment for #9468?
[10:07] <mup> PR #9468: tests: lxd smoke test <Simple 😃> <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9468>
[10:08] <mborzecki> pstolowski: sure, will take a look
[10:08] <zyga> huh
[10:08] <zyga> Oct 20 10:05:57 localhost run-snapd-from-snap[607]: /usr/lib/core18/run-snapd-from-snap: 42: /usr/lib/core18/run-snapd-from-snap: /usr/bin/snap: not found
[10:08] <zyga> pstolowski I'd like to "reset" seeding
[10:09] <zyga> can I just remove state json?
[10:09] <zyga> hmmm
[10:09] <zyga> wait there is no state.json
[10:09] <zyga> I only see this
[10:09] <zyga> https://pastebin.ubuntu.com/p/MCX46Dnsf2/
[10:09] <zyga> pstolowski note that the snaps/* are symlink
[10:09] <zyga> *symlinks
[10:09] <zyga> and there are only two
[10:12] <mborzecki> zyga: try talking to ondra, he probably has some hacks for postprocessing the image to add users etc
[10:13] <zyga> I've added a ssh key for root
[10:13] <zyga> should be enough
[10:14] <mborzecki> pstolowski: does the test need to launch a container?
[10:14] <pstolowski> yes, symlinks are expected, this is what makes runnable on first boot, but i'm not sure why snapd isn't symlinked; indeed it seems seeding did't run
[10:15] <pstolowski> mborzecki: no
[10:15] <pstolowski> mborzecki: it was failing pretty reliably with these steps
[10:15] <mborzecki> ok
[10:16] <zyga> I'm in
[10:16] <zyga> fuuuck
[10:16] <pstolowski> mborzecki: thanks!
[10:16] <mup> PR snapd#9468 closed: tests: lxd smoke test <Simple 😃> <Test Robustness> <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/9468>
[10:16] <zyga> exec format error
[10:16] <zyga> ubuntu image pulled x86-64 snapd!??!
[10:17] <pstolowski> woot
[10:17] <zyga> no sorry
[10:17] <zyga> well
[10:17] <zyga> I have arm7l kernel
[10:17] <zyga> and aarch64 snapd
[10:17] <zyga> that's fun
[10:18] <zyga> my fault
[10:21] <zyga> booting fixed image
[10:21] <zyga> eh
[10:21] <zyga> :D
[10:24] <zyga> reported https://github.com/snapcore/pi-gadget/issues/53
[10:30] <zyga> I went for coffee
[10:30] <zyga> and the device is updating and rebooting
[10:30] <zyga> but still no console-conf
[10:31] <zyga> I'll keep it running
[10:31] <zyga> weird
[10:32] <zyga> it's progressing
[10:32] <zyga> it's mounting snapd now
[10:33] <zyga> hmmm
[10:33] <zyga> weird
[10:33] <zyga> https://pastebin.ubuntu.com/p/jpPTtCDsc8/
[10:33] <zyga> this is what I got on the serial log so far
[10:33] <zyga> I've hit newline a few times when it took a long time to make any progerss
[10:34] <zyga> all this time no console conf
[10:34] <zyga> more getty changes
[10:35] <zyga> hmmm hmm
[10:35] <zyga> I wonder if this makes any sense to anyone
[10:36] <zyga> getty changes again
[10:36] <zyga> I'll reboot
[10:36] <zyga> this makes zero sense
[10:37] <zyga> ok, I have console conf now
[10:37] <zyga> and it crashes like before
[10:37] <zyga> heh
[10:37] <zyga> WTF
[10:37]  * zyga debugs
[10:40] <zyga> the system cannot seed
[10:40]  * zyga looks at why
[10:43] <zyga> ok, I'll enable journal and ssh and try again
[10:43] <zyga> there's nothing I can see that explains what failed
[10:43] <zyga> state.json doesn't have any useful messages
[10:46] <zyga> trying again
[10:53] <zyga> ok, I'm in while it's still trying to seed
[10:54] <zyga> snapd is not seeded correctly again
[10:55] <zyga> this is so weird
[10:56] <zyga> huh
[10:56] <zyga> pstolowski
[10:56] <zyga> Oct 20 10:56:31 localhost snapd[750]: taskrunner.go:271: [change 2 "Make snap \"snapd\" (9731) available to the system" task] failed: open /etc/dbus-1/session.d/snapd.session-services.conf.7PTDJQPMf
[10:56] <zyga> it fails on this!
[10:57] <mup> PR snapd#9523 opened: store, snap-repair: fix use of retry strategies <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9523>
[10:57] <zyga> right, because the fixed snapd is only later
[10:57] <zyga> (edge)
[10:57] <pstolowski> huh
[10:57] <pstolowski> but wait
[10:57] <pstolowski> with old core18 it should be fine?
[10:57] <zyga> btw
[10:57] <zyga> but this is old core18 and new snapd
[10:57] <pstolowski> only a problem once you refresh no?
[10:57] <zyga> btw, offtopic, why do we have to seeding services?
[10:57] <zyga>   snapd-seeding.service                                                                                loaded    active     running         /tmp/tmp.jFHQH5ZiJr/usr/lib/snapd/snapd
[10:57] <zyga>   snapd.seeded.service                                                                                 loaded    active     exited          Wait until snapd is fully seeded (core18)
[10:57] <zyga> perhaps we should give them better names (cc mvo)
[10:58] <pstolowski> "two"?
[10:58] <pstolowski> mvo: i've set 2.47 milestone on #9523
[10:58] <mup> PR #9523: store, snap-repair: fix use of retry strategies <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9523>
[10:58] <zyga> pstolowski one with dot, one with dash
[10:58] <zyga> pstolowski snapd-seeding and snapd.seeding
[10:59] <pstolowski> zyga: yeah, got it, you said "to", wasn't sure
[10:59] <zyga> ah, sorry
[10:59] <zyga> switching between macbook and hacker keyboard
[10:59] <zyga> mind confused :)
[10:59] <pedronis> ? one is "seeded" not seeding
[11:00] <zyga> ah
[11:00] <zyga> that's right
[11:02] <pedronis> they do very different things
[11:02] <zyga> yes, just have inconsistent naming
[11:04] <zyga> Oct 20 11:03:20 localhost systemd[1]: snapd.socket: Socket unit configuration has changed while unit has been running, no open socket file descriptor left. The socket unit is not functional until restarted.
[11:05] <zyga> snap tasks NNN is super slow due to locks
[11:05] <zyga> it's not a good experience :/
[11:05] <zyga> it's practically unusable when there are changes in progress downloading snaps
[11:06] <mvo> pstolowski: thank you
[11:07] <mvo> zyga: still in meeting :/ but +1 to anything that adds clarity
[11:07] <zyga> mvo hard to change that
[11:07]  * mvo has not read backlog :/
[11:08] <zyga> managed to get snap tasks after several minutes of waiting
[11:08] <zyga> refreshing core18 explicitly
[11:08] <zyga> let's see if we learn something
[11:10] <zyga> I've set refresh time now
[11:11] <zyga> so no auto updates for a while
[11:11] <zyga> I'll get core18 refreshed in a few minutes
[11:11] <zyga> with a bit of luck that will show what was failing for Roger
[11:16] <zyga> here we go, rebooting
[11:17] <zyga> [ 1839.110777] systemd-shutdown[1]: Failed to wait for process: Protocol error
[11:17] <zyga> ha
[11:17] <zyga> reproduced
[11:17] <zyga> pstolowski, mborzecki
[11:18] <zyga> mvo I've reproduced the failure on that pi
[11:18] <mborzecki> yay
[11:18] <mborzecki> zyga: so old kernel/gadget?
[11:19] <zyga> check this out
[11:20] <zyga> https://pastebin.ubuntu.com/p/JVW6c3kZK2/
[11:21] <zyga> mborzecki but before rebooting
[11:21] <zyga> there was a message about system-shutdown
[11:21] <zyga> it seems it really did fail
[11:21] <zyga> and now fat is fcks up
[11:21] <mvo> zyga: \o/ you rock!
[11:21] <zyga> let me plug the device back
[11:22] <mborzecki> zyga: you think that boot may be corrupted?
[11:22] <zyga> ha
[11:22] <zyga> fuck yeah
[11:22] <zyga> two power cycles
[11:22] <zyga> and it's back
[11:22] <zyga> I'm not kidding
[11:22] <zyga> this is exactly what happened on that other pi
[11:22] <zyga> I'll paste the more complete log now
[11:23] <zyga> https://pastebin.ubuntu.com/p/hmYzXHW4rf/
[11:24] <zyga> so now, some research time
[11:25] <zyga> I'll install core to have fsck available
[11:27] <zyga> https://www.raspberrypi.org/forums/viewtopic.php?t=242510
[11:27] <mborzecki> hm what mounts /run/mnt/ubuntu-seed on /var/lib/snapd/seed?
[11:28] <zyga> mborzecki dunno
[11:28] <zyga> core20 bit for sure
[11:30] <mborzecki> haha :P
[11:31] <zyga> yeah, this is totally reproducible
[11:31] <zyga> core18 cannot refresh, we shutdown uncleanly
[11:31] <zyga> w[FAILED] Failed to start Ubuntu core (all-sn…tem shutdown helper setup service.
[11:31] <zyga> See 'systemctl status snapd.system-shutdown.service' for details.
[11:32] <mborzecki> hmm
[11:33] <zyga> I'll report a detailed bug capturing this
[11:33] <zyga> I think core18 is good later
[11:33] <zyga> but not yet
[11:33] <mborzecki> so i mount ubuntu-save under /run/mnt/ubuntu-save, and bind mount it under /run/data/system-data/var/lib/snapd/device/save
[11:33] <zyga> remember this is old coe18
[11:33] <zyga> mborzecki it's a propagating mount
[11:34] <mborzecki> quite sure there's some rbind missing somewhere
[11:35] <mborzecki> probably sysroot-writable.mount (in core20-initrds aka ubuntu-core-initramfs), or/and handle-writable-paths
[11:35] <mborzecki> but i see /var/lib/snapd/seed is mounted, and maybe we could do the same instead, not sure though what mounts it there
[11:39] <pstolowski> zyga: amazing stuff!
[11:39] <zyga> https://bugs.launchpad.net/snapd/+bug/1900693
[11:39] <mup> Bug #1900693: snapd cannot refresh on some SD cards due to uboot bug <snapd:New> <https://launchpad.net/bugs/1900693>
[11:39] <pedronis> mborzecki: is done here I think (via fstab): https://github.com/snapcore/core20/blob/master/static/usr/lib/core/handle-writable-paths#L183
[11:39] <zyga> ok, I'll try to update uboot now
[11:40] <mborzecki> pedronis: thanks!
[11:41] <zyga> mborzecki who is our PI maintainer?
[11:41] <mborzecki> heh, noticed it's at the end of the file and was looking for something that may modify fstab after populate-writable runs
[11:41] <mborzecki> zyga: try poking waveform
[11:41] <zyga> thanks
[11:42] <zyga> I suspect we could use a repair assertion
[11:43] <zyga> well, we can see
[11:43] <pstolowski> dang, i'm not sure my diagnosis re retry strategies was correct
[12:01] <mborzecki> meh, shellcheck is unhappy about handle-writable-paths
[12:10] <cachio> mborzecki, hey
[12:10] <cachio> about the tumbleweed image
[12:10] <mborzecki> cachio: hey
[12:11] <cachio> mborzecki, this is the script we use to create that image
[12:11] <cachio> https://github.com/snapcore/spread-images/blob/master/tasks/google/add-opensuse-tumbleweed-64/task.yaml
[12:11] <cachio> mborzecki, what could we do about that to make tumbleweed work better?
[12:11] <mborzecki> cachio: we start from leap?
[12:12] <cachio> mborzecki, yes opensuse-15.2
[12:13] <cachio> mborzecki, I am importing this image opensuse-cloud/opensuse-leap-15-2-v20200702
[12:13] <mborzecki> cachio: i guess there's no tumbleweed image we could use?
[12:14] <cachio> mborzecki, no
[12:14] <cachio> let me check again
[12:14] <cachio> just to make sure
[12:17] <cachio> mborzecki, 15 15.1 and 15.2
[12:17] <zyga> FYI I asked in #opensuse-admin
[12:18] <mborzecki> that sucks a bit
[12:18] <zyga> I asked sysrich about this a while ago
[12:18] <zyga> and he did produce a link to TW images
[12:18] <zyga> but said they are not QAd
[12:18] <zyga> hmm
[12:19] <mborzecki> i mean, upgrading from a stable release is supposed to be supported so maybe we just need to figure out which pacakges are incorrect?
[12:19] <mborzecki> zyga: got link?
[12:19] <zyga> searching
[12:19] <mborzecki> cachio: when was the last time you built an image?
[12:19] <zyga> https://twitter.com/zygoon/status/1098257262102106112
[12:19] <zyga> my memory was rusty
[12:20] <cachio> mborzecki, the current tumbleweed is  opensuse-tumbleweed-64-v20200923
[12:20] <cachio> and the base we use  opensuse-tumbleweed-64-base-v20200831	
[12:20] <cachio> so 1 month ago is the last one
[12:21] <zyga> cachio IIRC the problem was that it had a leap kernel
[12:21] <zyga> and was some sort of frankenstein that should not be needed if we had a real TW system
[12:21] <zyga> (real = vanilla)
[12:21] <cachio> zyga, yes
[12:21] <mborzecki> so i ran zypper dup and it wants to install this kernel: `kernel-default   5.8.14-1.2           x86_64  repo-oss  openSUSE`
[12:22] <mborzecki> which is tw
[12:23] <mborzecki> cachio: so maybe the image build should actually run more often (weekly?), and run zypper dup once more after the first reboot?
[12:23] <cachio> it runs weekly
[12:24] <cachio> but it is failing with differnet errors
[12:24] <cachio> I can trigger a new one
[12:24] <zyga> maybe we could work through those errors
[12:24] <zyga> are you talking about test failures?
[12:24] <zyga> or about upgrade failures
[12:25] <cachio> zyga, upgrade failures
[12:25] <cachio> some incompatibilities with google packages
[12:25] <cachio> etc
[12:25] <cachio> this is the kernel in tumbleweed now
[12:25] <cachio> 5.3.18-lp152.19-default
[12:25] <zyga> pstolowski: upgrading the kernel is equally futile
[12:26] <zyga> pstolowski and as I discussed with maciek, upgrading the gadget is impossible now
[12:26] <zyga> mvo: pi is busted :P
[12:26] <zyga> mvo: needs some coordination to unbreak
[12:27] <cachio> zyga, mborzecki this is the last error upgrading
[12:27] <cachio> https://paste.ubuntu.com/p/sbNgmZgyrH/
[12:27] <pstolowski> zyga: that's really terrible
[12:28] <pstolowski> zyga: maybe add your findings under the original bug from Roger?
[12:28] <zyga> yeah, I will, still looking at some ideas
[12:34] <mborzecki> cachio: hm not sure why you're seeing those, i'm running zypper dup on the tw image we have and it seems tow ork
[12:35] <cachio> mborzecki, I think it is because we force the leap 15.2 kernel
[12:35] <mborzecki> cachio: why do we have that?
[12:35] <zyga> mborzecki, cachio: https://download.opensuse.org/tumbleweed/appliances/
[12:35] <cachio> this is because of a bug
[12:35] <zyga> I think we want to try https://download.opensuse.org/tumbleweed/appliances/openSUSE-Tumbleweed-JeOS.x86_64-kvm-and-xen.qcow2
[12:36] <cachio> mborzecki, https://github.com/snapcore/spread-images/blob/master/tasks/google/update-opensuse-tumbleweed/task.yaml
[12:36] <cachio> it used to get stuck when doing govendor sync
[12:36] <cachio> so we had to force that kernel
[12:37] <mborzecki> cachio: hm can we try with the current kernel?
[12:37] <cachio> mborzecki, yes
[12:55] <cachio> mborzecki, in few minutes the new image will be available
[13:38] <zyga> cachio: perhaps missing call to lxd cleanup
[13:52]  * zyga breaks for lunch 
[13:52] <zyga> cachio I can talk later
[13:52] <cachio> zyga, sure, I am reviewing the code now
[13:52] <zyga> after lunch I will fix xdg-settings
[13:52] <cachio> thanks
[13:52] <zyga> the test fails for real with app tracking on fedora
[13:52] <zyga> but probably for good reasons
[13:59] <mborzecki> off to pick up the kids
[14:20]  * zyga is back and looks at xdg-settings
[14:20] <mup> PR snapcraft#3322 closed: package repositories: drop $SNAPCRAFT_APT_HOST_ARCH variable <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3322>
[14:27] <pedronis> ijohnson: I did a pass on both #9418 and #9489 now
[14:27] <mup> PR #9418: many: implement snap routine console-conf-start for synchronizing auto-refreshes <Needs Samuele review> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9418>
[14:27] <mup> PR #9489: daemon,client: write and read a maintenance.json file for when snapd is shut down <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9489>
[14:28] <ijohnson> pedronis: thanks I'm still on lk this morning but will take a quick look now
[14:30] <mup> PR # closed: snapcraft#3303, snapcraft#3308, snapcraft#3310, snapcraft#3313
[14:35]  * zyga errand 
[15:03] <pstolowski> pedronis: interesting issue with assertions rest api  - https://bugs.launchpad.net/snapd/+bug/1899154
[15:03] <mup> Bug #1899154: importing assertions in snapd: no errors reported <snapd:Triaged> <https://launchpad.net/bugs/1899154>
[15:27] <pedronis> pstolowski: probably easy to fix if we have a reproducer ?
[15:27] <pstolowski> pedronis: for missing/bad body yes, i haven't checked other cases
[15:28] <pstolowski> maybe errors do not bubble up somewhere
[15:29] <pedronis> that sound strange, but easy to check
[15:30] <pstolowski> pedronis: yes i can get back to it later, just triaging now
[15:31] <pedronis> we do have unit tests for the basic stuff fwiw
[15:31] <pedronis> maybe a problem in client
[15:32] <pedronis> but they were using the api directly?
[15:33] <pstolowski> pedronis: yes, that's my understanding
[15:33] <pstolowski> pedronis: anyway, i'll add to my list to look at later
[15:34] <pstolowski> pedronis: btw, wrt another bug, do you know if it was intentional that we do not automatically carry-over devmode flag when you manually refresh a snap that was previously installed with --devmode?
[15:35] <pstolowski> seems to me like this could be by design
[15:37] <pedronis> that is intentional I think
[15:39] <pstolowski> ok, i think it's sensible given that devmode is cleary described in our docs as special mode for developers etc
[15:41] <pedronis> we don't even auto-refresh devmode snaps iirc
[15:43] <pstolowski> yes
[15:58]  * cachio lunch
[16:05] <mup> PR snapcraft#3324 opened: set ROS_PYTHON_VERSION for rosdep <Created by artivis> <https://github.com/snapcore/snapcraft/pull/3324>
[16:18] <mup> PR snapd#9422 closed: overlord: add link participant for linkage transitions <Needs Samuele review> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9422>
[16:21] <mup> Bug #1900730 opened: "snap list" hangs if snapd.socket service isn't running <Snappy:New> <https://launchpad.net/bugs/1900730>
[16:50] <mup> PR snapcraft#3325 opened: snapcraftctl: add checks for empty string for set-version & set-grade <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3325>
[16:53] <zyga> thank you mvo
[17:20] <zyga> rebased the export manager
[17:20] <zyga> running a few smoke tests now
[17:20] <zyga> but should be good
[17:20] <zyga> and I thought of a new test to write
[17:20] <zyga>  to ensure the fallback is not wrong
[17:45] <mup> PR snapcraft#3326 opened: lxd unit tests: simplify command checking pattern <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3326>
[18:18] <zyga> I've tested that we can disable the export manager, and use the corresponding old logic and apparmor profiles
[18:19] <zyga> I think it's not worth the cost of a full duplication of all tests but it was a useful run
[18:32] <zyga> https://github.com/snapcore/snapd/pull/9384 needs review
[18:32] <mup> PR #9384: overlord: export and use snapd tools <Created by zyga> <https://github.com/snapcore/snapd/pull/9384>
[18:32]  * zyga EODs
[19:11] <cachio> ijohnson, hi
[19:11] <cachio> quick question
[19:12] <ijohnson> hey cachio
[19:12] <cachio> uboot is used just in arm devices right'
[19:12] <cachio> ?
[19:13] <cachio> ijohnson, is there any other device where is it used like some amd64 once?
[19:13] <ijohnson> cachio: uboot as we use it is just for armhf / arm64 devices
[19:14] <ijohnson> cachio: but I mean maybe it could be used for other arches, I honestly don't know I've never tried it, I believe actually it works also for riscv64 and mips and such but we don't support ubuntu core on those architectures
[19:14] <ijohnson> cachio: why do you ask ?
[19:14] <cachio> ijohnson, ok, thanks, that answer my question
[19:14] <cachio> it is just for a test
[19:19] <ijohnson> ok
[19:21] <mup> PR snapcraft#3327 opened: Fix use case when multiple packages are compiled with catkin <Created by facontidavide> <https://github.com/snapcore/snapcraft/pull/3327>
[19:46] <mup> PR snapcraft#3328 opened: package repositories: drop $SNAPCRAFT_APT_RELEASE variable <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3328>
[21:36] <mup> PR snapcraft#3328 closed: package repositories: drop $SNAPCRAFT_APT_RELEASE variable <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3328>
[21:46] <mup> PR snapcraft#3317 closed: plugin handler: properly handle snapcraftctl errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3317>
[23:15] <mup> PR snapd#9524 opened: tests: new boot state tool <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9524>