/srv/irclogs.ubuntu.com/2020/05/05/#snappy.txt

=== diddledan6 is now known as diddledan
mborzeckimorning05:51
zygahey06:09
zygamborzecki: I'm fixing the tumbleweed degraded test now06:09
mborzeckizyga: hey, it's failing?06:09
zygayeah, some vty thing is complaining06:09
zyganothing relevant06:09
zygahttps://github.com/snapcore/snapd/pull/8596 needs a review06:09
mupPR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>06:09
zygamborzecki: we have a problem with journal test but let's do one thing at a time06:10
zyga(and the feature, not just the test)06:10
mborzeckipersistent journal test?06:10
zygayes06:10
zygait's soaky wet ouside, my dog will not be happy06:10
zygamborzecki: look at the test if you are curious06:10
zygait has some countermeasures06:10
zygabut it's a real problem06:10
zygaand they are insufficinent apparently, it failed again on the unprotected "snap set" code path at the end of the test06:11
zygahow was the long weekend?06:16
mborzeckizyga: it was ok, but felt a bit weird since everyone else had friday off and i swapped for monday ;)06:22
mborzeckizyga: btw. our fonts cache handling is broken i think, we'll need to discuss what to do about that, but the current observation is that we should not trust the font cache generated on the host to be compatible06:24
zygamborzecki: happy to06:24
zygamborzecki: can we stop sharing caches06:24
zygacaches belong to /var/snap/$BASE/06:24
zygaanything else is broken06:24
mborzeckihm idk, caches belog to whatever fontconfig is used06:24
mborzeckithat can be base, gnome/kde/freedesktop runtime, or the snap06:25
mborzeckianyways, desktop apps render boxes or straight out segfault on fedora 32 now06:26
zygamborzecki: I'm only talking about the fonconfig managed by snapd06:26
mborzeckizyga: but none of the bases we have ship fontconfig06:31
zygabut each of them has an associated gnome06:32
mborzeckizyga: idk, we need to think this though, it was a nice idea for an optimization, but it looks like it's misplaced and doing harm to the cross distro story06:32
zygaand derived fontconfig06:32
zygabut yeah06:32
zyganeeds thought06:32
mborzeckizyga: the snap can ship a different fontconfig, or not not use the gnome runtime at all06:32
zygamborzecki: snaps may ship it, we can just disable the shared (base) cache then06:34
zygamborzecki: if they do the simple thing, the use the same version that's in the base06:34
zygamborzecki: either via bundling or via content to gnome runtime06:34
zygamborzecki: base is just the easiest sharing "key"06:34
mborzeckizyga: kenvandine had an idea for per snap cache, with fc-cache getting called in the configure hook06:36
zygamborzecki: that will work but it it would be *very* costly IMO06:37
zygaand the cache has non-insignificant size06:37
mborzeckiin the meantime, i need to think of a way to disable mounting of cache from hsot on arch and fedora, i'd rather have a longer statup than a segfaulting app06:37
zygamborzecki: +106:37
zygamborzecki: that should be easy06:37
zygamborzecki: where is the cache again?06:37
mborzeckizyga: the configure hook runs during install, so it's just the snap install that takes longer06:38
zygamborzecki: that is true, I do like that part06:38
zygamborzecki: but does it mean all snaps get a virtual hook06:38
mborzeckizyga: /var/cache/fontconfig and ~/.cache/fontconfig06:38
zygamborzecki: or do they need to explicitly cooperate?06:38
mborzeckizyga: well, if we make it a gnome extention, then snaps need to be rebuilt/cooperate06:39
mborzeckimvo: hey!06:39
mvomborzecki: good morning06:40
zygamvo: hey06:40
mvozyga: and good morning to you as well!06:40
zygahttps://github.com/snapcore/snapd/pull/8598 <- last of the always-happening failures06:41
mupPR #8598: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8598>06:41
mvozyga: looking06:41
mupPR snapd#8598 opened: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8598>06:41
zygamvo, mborzecki <- please look at https://github.com/snapcore/snapd/pull/8596 as well06:41
mupPR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8596>06:42
zygaok, I need to take the dog out06:43
zygaonto the rain :|06:43
zygaor maybe into the rain actually06:43
mupPR snapd#8593 closed: image: stub implementation of image.Prepare for darwin <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8593>06:46
mupPR snapd#8596 closed: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8596>06:46
jameshzyga: re. your questions about me trying to use session-tool: https://github.com/snapcore/snapd/pull/5822#discussion_r41990162107:02
mupPR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>07:02
pstolowskimorning07:02
zygajamesh: good morning07:11
zygalookijg07:11
zygajamesh: I ported user-mounts to session-tool yesterday07:11
jameshzyga: the problems seem to suggest that sessions are not being cleaned up between tests07:12
zygajamesh: I think https://github.com/snapcore/snapd/pull/8596 may address this07:13
zygawhich just landed07:13
mupPR #8596: tests: session-tool --restore -u stops user-$UID.slice <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8596>07:13
zygahave a look, it's still a bit murky07:13
zygaI will look at logind changes07:13
zygaas it definitely behaves differently from one version to another07:13
jameshzyga: okay.  I'll give it another try.07:13
zygathanks07:14
jameshzyga: overall, I like what you've done.07:14
zygaI think we are not quite fully there yet, with groking various quirks in session handling across time07:15
zygabut I feel we are much closer to actually running representative tests07:15
zygaand getting familiar with bugs that may also impact us07:15
jameshhopefully we don't end up with anything that depends on systemd environment vs. login shell environment...07:16
zygajamesh: login shell environment?07:16
jameshzyga: the environment you get in a login shell, which could be different to the one systemd units are launched in07:16
zygaoh, it is07:17
zygabut we use runuser -l07:17
zygawhich gives us /etc/pam.d/runuser-l07:17
zygabut it's a good point that we should understand that difference better and see what's different still07:17
zygadue to runuser-l we get a real logind session and we get a few more pam modules07:18
jameshzyga: it's probably not an issue07:18
jameshsince a test can add anything extra it needs in the env07:19
zygalooking just now, I see we don't get this pam module:07:19
zygasession required        pam_env.so readenv=1 user_readenv=1 envfile=/etc/default/locale07:19
zygasurreal, we will have first green PR in a week, I think07:21
zygaor more perhaps07:21
zygamvo: thank you07:34
zygamvo: I was waiting for that green tick07:34
zygabut let's see it on ALL THE BRANCHES now :)07:34
mupPR snapd#8598 closed: tests/degrated: ignore failure in systemd-vconsole-setup.service <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8598>07:34
mvozyga: yeah, this looks super nice now07:35
mvozyga: I hope we overcame most of the flakiness for now07:35
zygacheckSnapSuite.TestCheckSnapSystemUsernamesCalls fails if you have daemon users installed07:41
mborzeckizyga: slightly tweaked #858008:01
mupPR #8580: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8580>08:01
Chipacahehe, booting old work laptop -> log in to old irc channels08:10
Chipacamorning all08:11
mborzeckiChipaca: morning sir!08:11
Chipaca:-)08:11
mborzeckizyga: the pulseaudio test is still kinda flaky, https://github.com/snapcore/snapd/pull/8537/checks?check_run_id=645190804 recording failed on 19.10 and pulseaudio iface test failed on 18.0408:13
mupPR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>08:13
pstolowskii'm seeing new selinux denials on centos 7 & fedora, not sure if this is my branch onl08:15
pstolowski*only08:15
pstolowskihowdy Chipaca!08:16
Chipacapstolowski: how're things going?08:16
pstolowskiChipaca: red color has been dominant recently. otherwise - excellent :)08:18
zygaChipaca: did you see my poem? :)08:44
zygamborzecki: looking08:44
zygamborzecki: oh, it's in the old style with manual masking and all the hacks08:46
zygamborzecki: let me fix it08:46
Chipacazyga: yep :) 'twas good. Also wondering what the background you were talking about looked like.08:46
zygaChipaca: a week+ of master red08:46
zygaChipaca: and mvo (who can override) being at a sprint08:47
zygaChipaca: but it was good, vast majority was fixed already08:47
zygamborzecki: testing now08:53
pstolowskimvo: hi, can the initrd PRs for early config land?08:54
mvopstolowski: I think so09:00
mvopstolowski: would be nice to get a review from xnox onhttps://github.com/snapcore/core20/pull/4609:01
mupPR core20#46: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>09:01
mvopstolowski: but yeah, I think the code is good now09:01
xnoxmvo:  looks good, two minor unresolved conversations on it.09:04
mvoxnox: aha, thank you, I will check what's missing there09:04
zygabrb09:11
zygare09:39
zygaman, it's surely raining today09:39
zygasoaky day09:40
zygatoday is a tea day09:41
pedronismvo: hi, the travis test for core20 in your PR failed09:46
mborzeckipedronis: i've added some reviews for the bulk assertions PR, we should probably land the ones that precede #856409:46
mupPR #8564: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8564>09:46
mvopedronis: checking09:46
mvopedronis: and hello :)09:46
pedronismborzecki: yes, trying but red and queueing atm09:47
pedronismborzecki: thanks for the reviews btw, same pstolowski09:48
pstolowskipedronis: yw. i'm keen to review the others but would be nice to land the prereqs, it was kinda confusing to review stacked PRs09:49
pedronispstolowski: yes, agree09:50
mvopedronis: fun "--2020-05-05 09:45:09--  http://cdimage.ubuntu.com/ubuntu-base/daily/current/focal-base-amd64.tar.gz is 404 now", I guess that needs an update first :)09:50
zygaoh about focal, mvo do you remember that bug where hardlinking on livecd used 400MB?09:51
zygawe got a comment that apparently the releaes iso shipped with that bug :|09:51
zygaso maybe something was off09:51
mvozyga: oh, I thought we fixed this09:52
zygawe did but maybe didn't really09:53
mvozyga: https://bugs.launchpad.net/snapd/+bug/186741509:53
mupBug #1867415: Hardlinking snaps wastes 400 MB tmpfs RAM in live CDs <rls-ff-incoming> <snapd:New for mvo> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1867415>09:53
zygamvo: comment #609:53
mvozyga: yeah, just saw it09:53
mupPR core20#51 opened: Makefile: updated now that focal is released <Created by mvo5> <https://github.com/snapcore/core20/pull/51>10:10
mupPR snapd#8599 opened: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8599>10:11
pedronisfwiw it seems we hit queuing quite a bit atm with actions, have things queued for many hours now10:44
zygapedronis: result of fixing most of master annoyances10:45
zygapedronis: I think it will clear in a few hours, let me look at the state10:45
zygapedronis: yeah, we have a few branches queued and lots running as well10:46
zygamvo: I got a weird email about authorization refresh11:19
zygaLaunchpad failed to refresh the authorization tokens used to upload this snap package to the store:11:19
zyga(then) Provided email/password is not correct.11:19
zygathis is from test-snapd-sh-core1811:19
mborzeckizyga: got one too11:20
mborzeckizyga: do you remember a change where we checked whwether the system is going down? was that in snap run?11:39
zygayes I do, yes it is11:39
zygacmd_run.go11:39
zygaisSystemStopping IIRC11:39
zygawhy?11:39
mborzeckizyga: if the logs ehere are to be belived: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1873550/comments/3 we may need to check if system is shutting down in snap-failure11:40
mupBug #1873550: Snappy daemon reaches 1min30s timeout during shutdown process <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1873550>11:40
zygaha11:40
zygafun11:40
zygawhy does OnFailure trigger?11:40
mborzeckizyga: because we hit the stop timeout, there's a wait for api clients to shut down, hits a 25s timeout, then before snapd stopped systemd killed it?11:41
zygaI see11:42
mborzeckihm maybe that client shutdown timeout is too long still11:42
mborzecki25s is pretty log for any api activity11:42
mborzeckibtw. pretty lame that systemd triggers onfailure when the system is shutting down11:44
mborzeckistill, why is there a 5s break between snapd logging the warning and being killed by systemd11:45
zygamborzecki: I think systemd.exec knows12:09
mborzeckizyga: yeah, noticed a log that there's a stop action queued, so it's not going to enqueue start12:10
mborzeckianyways, one of the commenters clearly had a newer snapd version12:10
zygahmm, nothing useful in the man page12:12
zygathere's also systemd.kill12:13
zygamaybe it's one of the defaults12:13
pstolowskiijohnson: hey, i've checked your hotplug + greedy plugs issue, replied to your bug report, does it make sense?12:34
mupPR snapcraft#3107 opened: fix yarn version url <Created by fkromer> <https://github.com/snapcore/snapcraft/pull/3107>12:55
mupPR snapd#8600 opened: tests: run smoke test with different bases <Created by mvo5> <https://github.com/snapcore/snapd/pull/8600>12:58
mupPR snapd#8580 closed: data/completion: add `snap` command completion for zsh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8580>13:50
* zyga -> errand13:58
mupPR snapd#8601 opened: Adds missing paths to apparmor, solves lp:1876804 <Created by sklei4> <https://github.com/snapcore/snapd/pull/8601>14:13
zygahttps://github.com/snapcore/snapd/pull/8597 is green :)D14:18
mupPR #8597: tests: port user-mounts test to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8597>14:19
ijohnsonzyga: that's great14:19
zygawait, is there a bzr tree of snapd?!?14:20
zygahttps://bugs.launchpad.net/snapd/+bug/1876804/comments/114:20
mupBug #1876804:  apparmor logs filled when ubuntu store launches  <snapd:New> <https://launchpad.net/bugs/1876804>14:20
ijohnsonzyga: I'm still a little confused though, does the old test really have coverage of something we care about on 14.0414:20
ijohnsonzyga: haha yeah I was confused too14:20
zygaijohnson: I'm slowly inclined to restore 14.04 support by writing a 14.04 version of session-tool14:20
ijohnsonzyga: I'm fine if you want to do a followup to re-add 14.0414:20
ijohnsonzyga: but I don't feel comfortable just dropping coverage for 14.04 yet as afaik the policy is don't break it if we don't have to14:21
zygaijohnson: I think it's preferable to be able to fix issues globally by changing session-tool14:21
ijohnsonzyga: maybe a followup to add  TODO to that test to say "re-add 14.04 when session-tool is updated"14:21
zygaijohnson: sure,14:21
ijohnsonok, I will +1 your PR14:22
zygaI can bundle that with something else not to clog the pipe today14:22
zygawith the next -porting-NNN branch14:22
ijohnsonright14:22
pedronismvo: #8537, please double check but I think can probably be force landed14:32
mupPR #8537: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>14:32
pstolowskizyga: do you know what was the first good systemd version wrt to persistent journal issue?14:34
* zyga is in the car14:34
zygapstolowski: yes, one sec14:34
zygahttps://github.com/snapcore/snapd/pull/8594#issuecomment-62358479814:35
zygapstolowski: ^14:35
mupPR #8594: tests: work around journald bug in core16 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8594>14:35
pstolowskizyga: thanks!14:38
* zyga is in the car, delivering supplies 14:38
zygaand reading about how to send the control bugs to BTS14:38
mborzeckiwhcih package ships translations for snapd?14:45
mborzeckiin ubuntu14:45
zygamborzecki: ubuntu uses a special langpack system14:46
zygaapt-cache search langpack14:46
ijohnsonpedronis: 8557 lgtm, thanks for the changes14:47
zygamborzecki: translations are extracted from individual packages (in main)14:47
zygamborzecki: and bundled into language-specific package14:47
mborzeckizyga: ok, installing bits for uk_UA14:48
zygaharaszo14:48
mborzeckihaha14:48
mborzeckizyga: hmm there does not seem to be a gettext file for snap tho14:52
pedronisijohnson: thanks14:52
pedronis#8557 needs a 2nd review, it's mostly a test refactoring14:53
mupPR #8557: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>14:53
mborzeckizyga: heh, so we ignore LC_ALL and just use LC_MESSAGES and LANG (a bug then?)14:56
mborzeckihaa15:05
mborzeckigot it15:05
mupPR snapd#8602 opened: configcore: only reload journald if systemd is new enough <Created by stolowski> <https://github.com/snapcore/snapd/pull/8602>15:10
mvopedronis: in various meeting, will check in a wee bit15:29
zygamborzecki: re15:32
zygamborzecki: there are two langpacks, base and "graphical"15:32
zyganot sure which one you checked15:32
* cachio lunch15:32
ijohnsonzyga: shall I merge #8599 since it's green (except unstable system) ?15:52
ijohnsonI just approved it15:52
mupPR #8599: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8599>15:52
zygalooking15:52
zygaijohnson: oh, there's a small comment15:52
zygaI guess, yes15:52
zygaI will follow up in a moment15:52
zygathanks!15:52
* ijohnson just wants to see green PR's get merged 15:52
ijohnson:-)15:52
zygayeah, that's the spirit!15:52
zygakeep master rolling15:53
zygawanna press the button or shall I?15:53
pedronis#8557 is completely green, incredibly, but needs a 2nd review15:53
mupPR #8557: c/snap-bootstrap: check mount states via initramfsMountStates <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>15:53
zygapedronis: it feels good, right? :)15:53
ijohnsonI pressed the button15:53
mupPR snapd#8599 closed: tests: port interfaces-audio-playback-record to session-tool <Test Robustness> <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8599>15:53
zyga\o/15:54
zygaI will read it on my way back15:54
zygawill be heading back home soon15:54
mvopedronis: merged, sorry for the delay16:02
mupPR snapd#8537 closed: store: handle error-list in fetch-assertions results  <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8537>16:03
pedronismvo: thanks, I need to deconflict the next one now16:03
mupPR snapd#8597 closed: tests: port user-mounts test to session-tool <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8597>16:06
mupPR pc-amd64-gadget#46 opened: gadget.yaml: bump edition <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/46>16:14
ijohnsonmmm should we be installing snap-failure service on systems that only have the core snap ?16:44
ijohnsonmvo: pedronis: should we have the snapd.failure service when only the core snap (or only the snapd distro pkg) is installed (and thus no snapd snap?)16:49
ijohnsonseems like `snap-failure snapd` just no-ops if there is no snapd snap installed, so probably yes it seems16:50
=== ijohnson is now known as ijohnson|lunch
mupPR snapcraft#3102 closed: build providers: prevent snap refreshing in build environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3102>17:38
mupPR snapcraft#3104 closed: packaging: use git-based versioning for python package <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3104>17:41
=== ijohnson|lunch is now known as ijohnson
cachiocmatsuoka, hey18:32
cachiocmatsuoka, for testing pi3 with uc20 do we need to use the model signed by canonical?18:33
cachioor we can use a model signed by me?18:33
cmatsuokacachio: afaik you can use your model18:33
cachioah, ok18:34
cachiocmatsuoka, I wanted to make sure it was not going to produce an problem with tpm/secboot18:34
cmatsuokawe don't have it in arm yet so you'll install unencrypted18:35
cachiocmatsuoka, good18:35
ijohnsoncachio: we also have dangerous models signed by canonical you can use too18:35
cmatsuokawell unless you have an arm board with tpm, but we never tested that18:35
cachioijohnson, yes19:00
cachioI'll test new images signed by me first19:01
cachiothen canonical19:01
jdstrandijohnson: I think I fixed your serial-port issue (see the bug)19:06
ijohnsonjdstrand: nice! I was going to look at pawel's response and ping you about it but you saw it first, thanks!19:07
ijohnsonjdstrand: re: including the snapd snap type, I'm not sure, on your system you tested it are you using the snapd snap?19:07
jdstrandijohnson: it isn't installed, no19:08
ijohnsonI have it installed, let me see if your new declaration works19:08
ijohnsonjdstrand: it seems to have auto-connected anyways19:12
jdstrandI just installed it and am trying19:13
jdstrandthe slot comes up as snapd:ft232serialuartic19:14
ijohnsonyes I see snapd:unor3cdcacm but it still auto-connected19:14
jdstrandserial-port             arduino:serial-port      :ft232serialuartic                -19:14
jdstrandbut it connected19:14
jdstrandok. as it happens, a different store bug prevents me from specifying 'snapd' for slot-snap-type, so, glad this worked :)19:15
ijohnsonjdstrand: and just to double confirm, when I disconnect the raw-usb interface and just use the serial-port hotplug interface I can upload a sketch / use the serial-port for the arduino and it works perfectly19:15
ijohnsonand then disconnecting the serial-port hotplug interface, it no longer is able to upload19:16
ijohnsonso this looks to "just work" when the declaration is good :-)19:16
ijohnsonthanks jdstrand19:16
jdstrandijohnson: np. sorry for the bug and thanks for reporting it. fyi, I commented on the 'snapd' slot-snap-type bits in the bug19:17
ijohnsonno problem, happy to know that it was an easy thing to fix :-)19:17
jdstrandindeed! :)19:18
ijohnsonI'm sure galgalesh will be happy as well (not sure if they are on IRC or not)19:18
mupPR snapd#8539 closed: tests: update encrypted partition creation test <UC20> <⛔ Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/8539>19:28
mupPR core20#52 opened: Makefile: only use focal from now on for core20 <Created by xnox> <https://github.com/snapcore/core20/pull/52>20:06
mupPR core20#51 closed: Makefile: updated now that focal is released <Created by mvo5> <Closed by xnox> <https://github.com/snapcore/core20/pull/51>20:10
mupPR core20#52 closed: Makefile: only use focal from now on for core20 <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/52>20:10
mupPR core20#46 closed: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/46>20:11

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