mupPR snapd#8854 closed: sysconfig/cloudinit: make callers of DisableCloudInit use WritableDefaultsDir <Simple πŸ˜ƒ> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8854>05:02
mupPR snapd#8850 closed: dirs: delete unused Cloud var, fix typo <Cleanup :broom:> <Simple πŸ˜ƒ> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8850>05:12
mvohey mborzecki05:25
mborzeckimvo: hey05:26
mborzeckihttps://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1858636 is interesting05:36
mupBug #1858636: snapd generates incomplete fontconfig caches, result in emoji rendering issue in chromium <apport-collected> <eoan> <focal> <rls-ff-incoming> <snap> <wayland-session> <chromium-browser (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed for anonymouse67> <https://launchpad.net/bugs/1858636>05:36
mupPR snapd#8837 closed: snap: add an activates-on property to apps for D-Bus activation <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8837>05:42
zygaHey guys06:25
zygaUnclear if I will work today, depending on ability06:25
mborzeckizyga: hey06:27
zygaHey :-)06:28
mvozyga: good morning06:32
zygaHey mvo06:43
zygaI will file time of for Friday06:44
mvozyga: yeah, please do06:48
mborzeckiheh, even without font cache, spotify snap still segfaults on my host07:17
pedronispstolowski: hi, I left some comments/questions in #881207:24
mupPR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services βš™οΈ> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>07:24
pedronispstolowski: on a different note: is/can be #8532 useful or should we just close it?07:25
mupPR #8532: tests: install new snapd deb into preseed image <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8532>07:25
pstolowskipedronis: saw your comments, thanks for looking at it!07:26
pstolowskipedronis: 8532 might be useful, i need to think07:27
pedronispstolowski: ok, on a 3rd note: do you want to look at #8823 more ?07:28
mupPR #8823: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823>07:28
pstolowskipedronis: yes, i'll conclude this review today07:29
pedronismvo: mborzecki: hi, we were having issues with centos on Fri, are we looking into it?07:30
mborzeckipedronis: what kind of issues?07:30
mborzeckilet me check the most recent prs07:31
pedronismborzecki: https://github.com/snapcore/snapd/pull/8855/checks?check_run_id=766170841 selinux/package related07:31
mupPR #8855: cmd,many: move Version and bits related to snapd tools to snapdtool, merge cmdutil <Cleanup :broom:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8855>07:31
mborzeckipedronis: yeah, it's the same as https://forum.snapcraft.io/t/snapd-updates-in-fedora-epel-for-enterprise-linux/8310/28?u=mborzecki07:32
pedronismborzecki: do we need to mark them unstable?07:33
pedronis7 is also failing and marked required07:34
mborzeckipedronis: maybe, i need to poke around a bit more, had some trouble refreshing rhel vms in the morning07:34
mupPR snapd#8858 opened: asserts,daemon: add support for "serials" field in system-user assertion <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>07:38
=== alazred_ is now known as alazred
mborzeckiheh, so centos is lagging behind again07:49
mborzeckiand snapd 2.45 installs fine on rhel807:50
mborzeckihm a build of selinux-policy for centos in a sufficient version was done a couple of days ago https://koji.mbox.centos.org/koji/buildinfo?buildID=11412 but no clue where to find it08:01
mupPR snapd#8859 opened: tests: enable snap-auto-mount test on core20 <Simple πŸ˜ƒ> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8859>08:08
mborzeckipedronis: mvo: yeah, so with some info from folks in #centos it is lagging behind, 8.2 is in the oven so no updates are being pushed, and in general there is no clear solution for the latency of updates from rhel (which is used for epel builds) appearing in centos08:19
pedronismborzecki: mvo: so short term we shoul mark both centos unstable?08:20
mborzeckiperhaps we should make that test smarter, rather than dumping whole centos to unstable08:20
pedronismborzecki: that sounds ok, but if is not trivial we should first unblock landings08:21
pedronismborzecki: also it's a bit unclear is a good use of time, I don't know. I agree that the fact that we have fully unsable systems, instead of unstable tests is a bit of a problem08:22
mborzeckiotoh, how do we mark the system unstable right now?08:23
mvomborzecki: I can mark it unstable (I uncheck "required test" in the settings box for this)08:26
mborzeckimvo: please do08:26
mvomborzecki: done, centos-7 is no longer required08:30
mborzeckimvo: centos-8 :)08:30
mvomborzecki: that is already not-required08:31
mvomborzecki: should I make -7 required again?08:31
mborzeckimvo: yeah, sorry, centos-7 is good, only 8 needs to be non-mandatory08:31
mvomborzecki: updated again, thank you :)08:32
mborzeckisil2100: hey, can you take a look at https://github.com/CanonicalLtd/ubuntu-image/pull/189 ?08:45
mupPR CanonicalLtd/ubuntu-image#189: ubuntu_image: do not overwrite the files that snap prepare-image has created <Created by bboozzoo> <https://github.com/CanonicalLtd/ubuntu-image/pull/189>08:45
mupPR snapd#8823 closed: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8823>08:48
mupPR snapd#8860 opened: overlord: refuse to install snaps whose activatable D-Bus services conflict with installed snaps <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8860>08:53
mborzeckiquick errand08:59
zygastarting work08:59
zygapedronis: thank you for the changes to https://github.com/snapcore/snapd/pull/8829 - they look good09:01
mupPR #8829: sandbox/cgroup: add tracking helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/8829>09:01
zygapedronis: I will prepare the next chunk in a moment09:01
zygamborzecki: what is up with centos-8?09:02
zyga Problem: package snapd-2.45-1.el8.x86_64 requires snapd-selinux = 2.45-1.el8, but none of the providers can be installed09:02
* zyga reads backlog09:04
pedronispstolowski: thanks, I expanded a bit my considerations: https://github.com/snapcore/snapd/pull/8812#discussion_r44003875909:15
mupPR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services βš™οΈ> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>09:15
pstolowskipedronis: thank you09:17
zygamborzecki: do you think you could do a 2nd review for 8829?09:21
zygait's the same code, just split out and polished a little09:21
mborzeckipstolowski: which snap did you try to debug with --gdbserver?09:36
pstolowskimborzecki: hello-world09:36
mborzeckiok, let me try that09:37
mborzeckimeh, python 3.5 vs 3.809:38
mupPR snapd#8861 opened: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>09:38
mborzeckizyga: centos-8 should be marked as unstable, even if it fails it should be possible to merge a PR09:40
zygaI see09:40
zygaare we waiting for something to migrate?09:40
mborzeckizyga: and i'll be adding some details about centos-8 and epel to the standup docs09:40
pedronismborzecki: hi, I updated https://github.com/snapcore/snapd/pull/8844 to keep only the benchmarks as we discussed previously09:44
mupPR #8844: asserts/internal: add some iteration benchmarks <Created by pedronis> <https://github.com/snapcore/snapd/pull/8844>09:44
mborzeckipedronis: thanks!09:48
pedronismvo: I reviewed #8858, missing some bits (format is a bit complicated)09:54
mupPR #8858: asserts,daemon: add support for "serials" field in system-user assertion <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8858>09:54
mvopedronis: thank you, looking09:55
pstolowskimborzecki: are you checking my remark about seond 'continue'?10:00
mborzeckipstolowski: yeah, that was my intention, but got into a fight with py35 in ubuntu-image :/10:01
=== pedronis_ is now known as pedronis
mupPR snapd#8784 closed: snap: add new `snap run --experimental-gdbserver` option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8784>10:44
jameshmborzecki: would you have any idea of what sort of changes I'd need to fix this error? https://github.com/snapcore/snapd/pull/8861#issuecomment-64404883310:55
mupPR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>10:55
mborzeckijamesh: looking10:55
jameshmborzecki: in short, I need to make a couple of directories under /var/lib/snapd readable by dbus-daemon10:56
jameshwhile being writable by snapd10:56
mborzeckijamesh: should be fairly simple, i can push a patch there10:57
jameshmborzecki: thanks.  That seemed like the only legitimate failure in the logs so far.10:58
jameshgood thing you added that regression test :-)10:58
mborzeckijamesh: mhm, yeah we need to updae the policy, system_dbusd_t (used dbus-daemon) does not have read access to /var/lib/snapd10:59
jameshmborzecki: I suppose we can't just label /var/lib/snapd/dbus in a way to give it access if it can't read /var/lib/snapd :(11:00
jameshor traverse it at least11:00
popeyI have updated a snap (atom) which now complains that "- Mount snap "atom" (256) (cannot find required base "core")" - but i have core installed. https://paste.ubuntu.com/p/kMNzw3Jj8v/   any ideas?11:01
popeyyou can "snap install atom --edge --classic" to try for yourself.11:01
mborzeckijamesh: we could use the same label as /usr/share/dbus/services.d but then quite likely we'd need to update the snapd policy to allow snapd write access there11:02
mborzeckijamesh: either way, a change is needed11:02
mborzeckii wonder why there was no error on fedora though11:02
zygajamesh: hi11:04
zygasorrym I'm not around during the calls much11:04
zyganot the best moment in my life11:04
jameshmborzecki: it should be similar label to /usr/share/dbus-1/{services,system-services} -- not sure if that differs to session.d/system.d11:04
zygaI left a pair of small comments on https://github.com/snapcore/snapd/pull/886111:04
mupPR #8861: data,packaging,wrappers: extend D-Bus service activation search path <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8861>11:04
jameshzyga: no problem11:04
zygajamesh: sorry to nickpick about the name but I really wonder why we use "services" and not "session-services"11:05
jameshzyga: I followed the naming scheme that D-Bus uses, as mentioned in the comment.  I'm not sure it is worth being different11:06
zygaI see, I missed that when jumping through the diff11:07
jameshzyga: and as always, thanks for the review feedback :-)11:11
mborzeckijamesh: do we need to reload dbus-daemon to have it pick up those extra conf files?11:15
mborzeckii would guess that system dbus got reloaded/restarted on centos 7 and that triggered the denial11:15
zygaInteresting, I recall a bug where it would only work if a directory was present to start with11:17
zygaas otherwise dbus would not establish some inotify watch11:17
zygaI don't recall the details11:17
jameshmborzecki: there is a restart method you can send, but I think it generally picks things up via inotify these days11:18
jameshmborzecki: we don't currently do it when adding/removing system bus policy, but probably should.11:19
jameshperhaps that should be a new PR11:19
mborzeckijamesh: isn't inotify only for service.d system.d directories?11:19
jameshmborzecki: once it reads the new config file from /usr/share/dbus-1/system.d or session.d, it should start monitoring the new directory for service activation files11:22
zygacore20 prepare fails, has anyone looked at that?11:34
pedronisthat's recent11:44
mborzeckijamesh: heh, the test is fine in isolation as suspected11:56
clmsyhi everyone, quick question, were there any known changes to gadget structure for core20 builds?  my ubuntu-image cli fails on the last step of building a core20 based image with "cant find boot config".12:09
clmsyin the gadget's stage folder i can see all the grub related files12:09
clmsyooh one sec i realized something... snapcraft clean actually never removes gadget and parts folder somehow, i manually deleted them, did another build and the gadget snap is created but there is no stage or parts folder hmm12:16
zygamborzecki: o/12:18
zygamborzecki: I opened a small tweak and another chunk carved out of the refresh tracking logic12:18
zygamborzecki: the tweak is https://github.com/snapcore/snapd/pull/8862 and is really small apart from mv'ing some code around - I did this to allow the diff in cgroup.go (in subsequent branches) to be readable12:19
mborzeckizyga: trading PR for PR https://github.com/snapcore/snapd/pull/8864 :)12:19
mupPR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>12:19
mupPR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>12:19
zygamborzecki: and to make sure I didn't break anything in conflict resolution12:19
mupPR snapd#8862 opened: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>12:19
mupPR snapd#8863 opened: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>12:19
zygamborzecki: gladly :)12:19
mupPR snapd#8864 opened: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>12:19
zygamborzecki: the only new change is that I simplified PidsInGroup12:19
zygacompare https://github.com/snapcore/snapd/pull/8862/files#diff-a44752c174bd4af51ccc892ed5bc15b4L212 and https://github.com/snapcore/snapd/pull/8862/files#diff-a5c0640204de19f988a6d5446e6108e6R3212:20
zygait was a simple code reuse as everything was exactly the same12:20
zygathe https://github.com/snapcore/snapd/pull/8863 is a bigger PR that involves one main new function in the form taken verbatim out of refresh app awareness v2 branch - again split to a new file for readability12:20
mupPR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>12:20
zygacomments there probably need tweaking but the logic is what I wanted it to be12:21
zygathe comment on the PR is more accurate than than the comments inside12:21
zygaok, that's that12:21
zygagoing to look at your PR :)12:21
zygamborzecki: is there a spread test that shows this warning?12:23
mborzeckizyga: afaik there isn't one12:24
zygabtw, I found one thing over weekend12:25
zygagrep -x12:25
zygavery useful for line matches12:25
zygaespecially as grep -qFx12:25
zygaquiet, literal, whole line matches12:25
zygait's essentially a line in open("fname").splitlines() in shell12:25
zygamborzecki: could you add a test, I think it's going to be useful to let us know the list is stale12:26
zygaapart from that and the nitpick inline +112:26
* zyga reviews services changes from pawel12:47
mupPR snapcraft#3170 closed: repo: decouple fetch and unpack stage-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3170>12:50
pedronisclmsy: yes, gadget look different/have different details in UC20 (and some details are still in flux), I recommend ATM looking at the 20 branches of https://github.com/snapcore/pi-gadget and https://github.com/snapcore/pc-amd64-gadget for an idea12:55
* zyga lunch break (ha ha, in bed :()13:28
roadmrzyga!!! hope you get better! I'm too far to help but let me know if I can in any way13:35
zygathanks Daniel, being here and working keeps me sane13:39
roadmrjust don't work too much :)13:41
Saviqijohnson: confirmed the classic β†’ strict refresh issue https://bugs.launchpad.net/snapd/+bug/188353813:41
mupBug #1883538: Classic to strict refresh requires manual intervention <snapd:New> <https://launchpad.net/bugs/1883538>13:41
Saviqalmost looks like staged refresh…13:42
Saviqwe only have about 10% of the people tracking stable on the most recent revision (that's out for a week now)13:43
Saviqmvo: FYI ↑13:43
mvoSaviq: oh, interessting. thank you, will look after my current meeting13:45
ijohnsonthanks Saviq14:00
ijohnsonwe will look in a bit, I too have a meeting now :-)14:00
zygapstolowski: https://github.com/snapcore/snapd/pull/8812#pullrequestreview-43067335414:02
mupPR #8812: o/snapstate: service-control task handler (4/N) <Needs Samuele review> <Services βš™οΈ> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8812>14:02
pstolowskizyga: thank you14:02
* zyga debugs the core 20 prepare failure14:06
abeatohas anybody tried running UC20 on kvm + TPM (simulated or passthrough) for disk encryption?14:12
ijohnsonabeato: yes not passthrough, but simulated14:12
abeatoijohnson, cool - any special issue with that or things just work?14:12
ijohnsonabeato: yes it should just work, what issues are you running into?14:13
abeatoijohnson, none, just double checking before I enter a rabbit hole :)14:13
ijohnsonabeato: for now, I use the swtpm-mvo snap + socket to provide to qemu14:13
abeatoijohnson, will try that, thanks14:13
ijohnsonabeato: this is my qemu cmdline I use with a copy of the OVMF_VARS.ms.fd from the ovmf package:14:14
mborzeckizyga: should probbaly land https://github.com/snapcore/snapd/pull/8863 first14:53
mupPR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>14:53
mborzeckizyga: w8, not this one, this one: #886214:54
mupPR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>14:54
zygawith one review?14:55
zygamaybe pawel can do a quick one14:55
zygait's just moving a few lines around14:55
zygamborzecki: thanks for this!14:55
mborzeckizyga: or ijohnson/cmatsuoka maybe?14:56
zygaanyone who's around14:56
zygasorry, I'm kind of out of touch14:56
zygaah I see ijohnson is around14:56
ijohnsonwhats up14:56
cmatsuokawhich PR?14:56
mupPR #8862: sandbox/cgroup: improve pid parsing code <Created by zyga> <https://github.com/snapcore/snapd/pull/8862>14:56
zyga2nd review, just moving code around _and_ simplifying the main function since it had a common implementation with a private function already present14:57
zygait's good to chat to you guys btw14:57
zygaI'm sorry for not joining the standups now14:57
zygaI really want to get over this part of my life14:57
mborzeckiijohnson: zyga: if https://github.com/snapcore/snapd/pull/8864 is green, i'll merge it and add a test in a follow up14:57
mupPR #8864: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple πŸ˜ƒ> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>14:57
ijohnsonk, sounds good to me14:58
zygamborzecki: that's okay14:58
zygamborzecki: the test is mainly to see it break over time14:58
zygakind of distro-sensors14:58
pedronisis spread on core 20 working now?15:00
ijohnsonpedronis: it seems that preparing it intermittently fails because there are snaps in the classic 20.04 image we use to prepare it15:00
ijohnsonI saw some reds preparing on Friday, some greens preapring on Friday15:00
zygaI'm running a loop to get a shell and look around15:00
pedronisis this the issue that we seem not to get the same image all the time?15:01
ijohnsonI think it's really the problem that mvo described is that we don't get the same image all the time15:01
ijohnsonpedronis: yes15:01
ijohnsonat least afaict15:01
ijohnsonmaybe it's something else too15:01
zygado we have hard proof that this happens?15:03
zyga(!same image)15:03
ijohnsonzyga: the hard proof is that we sometimes get an image with snaps installed in it, and sometimes we get an image without snaps installed in it15:03
zygamaybe we always get an image with a seed inside15:04
ijohnsoniirc mvo added a check to make preparing fail if it detects snaps installed in the image15:04
zygaand we sometimes manage to seed15:04
zygaand sometimes dont15:04
ijohnsonzyga: you approved the PR :-)15:05
mupPR #8849: tests: fail in setup_reflash_magic() if there is snapd state left <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8849>15:05
zygayeah but I didn't know it turned something up15:05
cmatsuokazyga: so from what I see 8862 is just reorganization, without any feature changes?15:07
zygacmatsuoka: yes15:07
zygacmatsuoka: one tiny code change, if you look at the public function15:07
zygabut it's 100% identical after, just calls a helper that happens to do the common tail15:07
cmatsuokazyga: yes, I noticed that, and it looks better this way15:08
zygayeah, it's easy to follow top to bottom15:08
zygathanks guys!15:10
cmatsuokazyga: how are you feeling? getting better?15:12
zygacmatsuoka: not actually15:12
zygacmatsuoka: more news on Wednesday after doc visit15:12
cmatsuokazyga: I hope you get well soon15:16
zygathanks, I really want to15:16
mupPR snapd#8865 opened: workflow <missing-colon> test PR title as part of the static checks again <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8865>15:50
zygahttps://github.com/snapcore/snapd/pull/8863 is now ready for review16:10
mupPR #8863: sandbox/cgroup: allow discovering PIDs of given snap <Created by zyga> <https://github.com/snapcore/snapd/pull/8863>16:10
zygabroken out of the refresh-app-awareness-v2 branch16:10
mupPR snapd#8862 closed: sandbox/cgroup: improve pid parsing code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8862>16:10
ijohnsonhey folks, could I get reviews on https://github.com/snapcore/snapd/pull/8519, it is green now after I debugged it more and fixed the test16:59
mupPR #8519: tests/special-home-can-run-classic-snaps: re-enable <Test Robustness> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8519>16:59
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
mupPR snapd#8844 closed: asserts/internal: add some iteration benchmarks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8844>18:31
mupPR snapd#8864 closed: cmd/snap: do not show $PATH warning when executing under sudo on a known distro <Simple πŸ˜ƒ> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8864>19:01
mupPR snapd#8866 opened: tests/main: add spread test for running svc from install hook <Services βš™οΈ> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8866>19:06
mupPR snapd#8867 opened: interfaces: add uinput interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8867>19:41
mupPR snapd#8868 opened: interfaces: add system-source-code for access to /usr/src <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8868>20:06
mupPR snapd#8869 opened: asserts/internal: expand errors about invalid serialized grouping labels <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8869>20:46
mupPR snapd#8317 closed: many: make sure ephemeral failover snapd does not open sockets <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8317>20:51
mupPR snapd#8870 opened: interfaces: add gconf interface <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8870>21:27
mupPR snapd#8871 opened: tests/prepare-restore.sh: reset-failed systemd-journald before restarting <Simple πŸ˜ƒ> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8871>21:32
mupPR snapd#8872 opened: tests/lib/prepare-restore.sh: if we failed to purge snapd deb, ls /var/lib/snapd <Simple πŸ˜ƒ> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8872>21:42
mupPR snapd#8873 opened: interfaces: misc small interface updates <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8873>22:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!