/srv/irclogs.ubuntu.com/2020/08/27/#snappy.txt

mupPR snapcraft#3265 closed: colcon v2 plugin: honour http(s) proxy for stage-runtime-dependencies <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3265>00:19
mupPR snapcraft#3266 closed: cli: add --enable-experimental-extensions option for expand-extensions <enhancement> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3266>00:19
* zyga-x240 debugs failing core/apt test05:20
mborzeckimorning05:24
zyga-x240hey05:27
zyga-x240something broke, new core18 has apt-get05:27
zyga-x240I've adjusted a test and will push a branch soon05:27
zyga-x240master is red currently05:27
zyga-x240mborzecki: I have something for you05:27
zyga-x240https://github.com/snapcore/snapd/pull/921205:27
mupPR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>05:27
zyga-x240can you quickly look please, it's very small apart from extra tests05:27
mborzeckizyga-x240: hey05:28
mborzeckimaster red? ehh05:28
zyga-x240yep05:28
zyga-x240but fix is coming05:28
zyga-x240mborzecki: https://github.com/snapcore/snapd/pull/922905:55
mupPR #9229: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>05:55
zyga-x240this should fix master05:55
mupPR snapd#9229 opened: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>05:55
zyga-x240mborzecki: so your question was on the right track06:09
zyga-x240mborzecki: hooks were tracked in the root session06:09
zyga-x240mborzecki: that is fixed with that PR06:09
zyga-x240mborzecki: the next step is to rebase the selinux patches, this change made them useless06:10
zyga-x240mborzecki: when mvo is around we can start making progress06:10
zyga-x240mvo: hey06:28
zyga-x240mvo: good morning06:28
zyga-x240mvo: I have a few things for you06:29
mvogood morning zyga-x24006:34
zyga-x240mvo: hello06:34
zyga-x240mvo: so first thing first, master is broken because core18 now ships the apt-get wrapper script06:34
zyga-x240mvo: because we no longer maintain core18 I chose to adjust tests instead of chasing the snap06:34
zyga-x240mvo: this is https://github.com/snapcore/snapd/pull/922906:35
mupPR #9229: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/9229>06:35
zyga-x240mvo: second thing, the bug you poked me about last night06:35
zyga-x240mvo: it's very embarrassing as I wrote that code06:35
zyga-x240mvo: the fix is in https://github.com/snapcore/snapd/pull/9228 and should be merged to 2.46 if we are getting a .106:35
mupPR #9228: interfaces/systemd: compare dereferenced Service <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/9228>06:35
* zyga-x240 goes to review https://github.com/snapcore/snapd/pull/909806:36
mupPR #9098: tests: new organization for nested tests <Run nested> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9098>06:36
zyga-x240and then other things06:36
mvozyga-x240: thank you!06:36
* mvo hugs zyga-x240 for 922806:36
zyga-x240mvo: it never failed before because our tests and our customers never had a case where a gpio was used by more than one plug at a time06:38
zyga-x240mvo: anyway, it's fixed now06:38
mvozyga-x240: great job06:39
mvozyga-x240: also good timing as 2.46.1 will happen very soon06:39
zyga-x240that's great06:39
zyga-x240mvo: I would also like to include one more thing06:39
zyga-x240https://github.com/snapcore/snapd/pull/921206:39
mupPR #9212: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/9212>06:39
zyga-x240it's only for people who enabled r-a-a06:39
zyga-x240this corrects a mistake in how we track hooks06:39
mborzeckimvo: hey06:39
zyga-x240it should be better even if root logs out06:39
mvogood morning mborzecki and welcome back06:39
zyga-x240(right now the hook might get killed if root logs out after the hook starts running)06:40
zyga-x240not a must but I'd love to get it in, it's only used for feature flag users anyway06:40
mvozyga-x240: re core18> looking now but there are some messages that core18 is held in the review queue, maybe related06:42
zyga-x240mvo: maybe it got unblocked?06:42
zyga-x240in any case, master is broken now so we should probably do something to the test, other ideas are welcome06:43
mvozyga-x240: yeah, probably, but in any case, it's fine that apt-get exists06:43
zyga-x240yeah, I think so06:43
mvozyga-x240: so your fix is probably right, looking at it now06:43
zyga-x240mvo: meh06:44
zyga-x240I botched the fix06:44
zyga-x240sorry06:44
mvozyga-x240: which one?06:44
zyga-x240the one for apt06:45
zyga-x240I forgot *06:45
zyga-x240ubuntu-core-16-*06:45
mvozyga-x240: no worries, just force push06:45
zyga-x240done06:45
mupPR snapd#9228 closed: interfaces/systemd: compare dereferenced Service <Bug> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9228>06:45
mborzeckizyga-x240: nice 9212 is green, selinux does not complain06:48
zyga-x240mborzecki: not really06:49
zyga-x240mborzecki: selinux is not tested there06:49
zyga-x240mborzecki: the other PR enabled tracking to get more coverage06:50
zyga-x240mborzecki: this one just prepares for that, selinux still needs changes06:50
zyga-x240at some point we should run all tests with selinux checks06:50
zyga-x240but that would be a lot of work today, I fear06:50
zyga-x240mborzecki: would you mind if I make those changes in a follow-up06:51
zyga-x240the PR is green now06:51
mborzeckizyga-x240: it's fine06:51
zyga-x240ok06:51
zyga-x240merging then, thank you06:51
zyga-x240and we have more tests for tracking now as well, thank you for reviewing :)06:52
* zyga-x240 runs for quick breakfast06:53
mupPR snapd#9212 closed: cgroup,snap: track hooks on system bus only <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/9212>06:55
mupPR snapd#9223 closed: mkversion.sh: simple hack to include dirty in version if the tree is dirty <Bug> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9223>07:00
pstolowskimorning07:02
mvogood morning pstolowski07:02
mborzeckipstolowski: heya07:03
pedronismborzecki: hi, I added this comment: https://github.com/snapcore/snapd/pull/9201#discussion_r478204904, not sure it's clear07:19
mupPR #9201: [RFC] boot: observe update & rollback of trusted assets <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9201>07:19
zyga-x240back from breakfast07:21
pedronisI tweaked #922707:36
mupPR #9227: snap: add size to the random access file return interface <Simple 😃> <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9227>07:36
zyga-x240ta07:40
* zyga-x240 goes for the desktop call07:50
mborzeckipedronis: yes, i think it makes sense, i need to think a bit how to do it reliably for newly added assets though07:50
mborzeckipedronis: and i've updated the PR since the tweaks for install observer landed07:50
pedronismborzecki: we are holding the state lock during the whole gadget assets update right?07:55
mborzeckipedronis: let me double check, i don't think so08:05
mborzeckipedronis: we don't, there's an explicit unlock/lock around call to gadget.Update08:06
Chipacaullo ullo08:10
mborzeckiChipaca: heya08:10
Chipacazyga: snapd.socket is dead right now, want to know more?08:10
zygaChipaca yes08:10
zygamborzecki ^^^08:10
zygaI'm in a call08:10
zygaplease use this opportunity to learn more08:10
zygaChipaca did snapd snap refresh or did the classic package update?08:10
zygamvo ^08:10
zygacould be pretty serious08:11
Chipacaneither afaik, but i'll check08:11
Chipacalogs are swamped by microk8s poking snapctl (and failing) all the time08:11
mborzeckiChipaca: systemctl status snapd.socket please08:11
Chipacamborzecki: https://paste.ubuntu.com/p/K87wFBQwt3/08:12
mborzeckiChipaca: heh interesting, Transaction for snapd.service/start is destructive (systemd-suspend.service has 'start' job queued, but 'stop' is included in transaction)08:13
mborzeckithe system is suspending so systemd won't start the socket or what?08:13
zygawoah08:14
zygainteresting08:14
zygaChipaca are you suspending your computer often?08:14
Chipaca21.55.20 is a 'reached target Sleep'08:15
Chipacazyga: when i don't use it08:15
Chipacazyga: so, no :-) but daily for sure08:15
Chipacazyga, mborzecki, anything else you want to get out of this, or should i go ahead and restart the socket?08:25
zygaChipaca I think restarting the socket is ok08:25
mborzeckiChipaca: hm maybe snap changes and snap change if there's something relevan tin there08:25
Chipacamborzecki: can't do that without restarting the socket :-)08:25
Chipacamborzecki: no changes newer than yesterday at 18:5408:26
Chipacaand that was core18 refreshing08:26
mborzeckiChipaca: ha, you actually can now, snap debug state08:27
Chipacaoooh, schmancy!08:27
zygaChipaca haha, yeah08:27
mborzeckisnap debug state /var/lib/snapd/state.json [--change=<id> if there's anything relevant]08:27
* zyga reboots for upgrade quickly08:59
mupPR snapd#9226 closed: cmd/snap-bootstrap/initramfs-mounts: compute string outside of loop <Cleanup :broom:> <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9226>09:11
mupPR snapd#9229 closed: tests: account for apt-get on core18 <Test Robustness> <⚠ Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9229>09:11
zygamvo do you need a backport of the GPIO bug fix?09:15
mvozyga: I already cherry-picked it09:15
zygasuperb, thanks!09:15
zygamvo it's such a terrible bug, I'm sorry for causing this09:15
mvozyga: don't worry09:16
pedronismborzecki: there's probably a bad idea at this point, we need to rethink that09:22
pedronismborzecki: that's probably a bad idea at this point09:23
mborzeckipedronis: not locking state?09:23
pedronismborzecki: I mean releasing the lock09:23
pedronisyes09:23
pedronisit's not clear that that op should so slow to matter09:23
pedronisand now we are playing with modeenv without a lock09:23
pedronisnot a good idea09:23
mborzeckiah right09:23
mborzeckipedronis: hm thre's some unclear scenarios, can you request a reboot to recovery when assets update is in progress?09:24
pedronismborzecki: well, if we hold the lock you won't be able to09:25
pedronisno?09:25
pedronismborzecki: RequestSystemAction asks for the lock09:26
mborzeckipedronis: yeah09:27
mborzeckipedronis: otoh, it's not like there's going to be GBs of assets being updated, so holding a lock during the update isn't too bad09:28
pedronisyes09:28
pedronisand the new code is reading modeenv once and then writing it multiple times09:28
pedronisso we really need some kind of lock09:29
pedronisI don't think it's very explicit but in general the assumption is that we hold the lock09:29
pedroniswhen manipulating modeenv09:29
mborzeckipedronis: would a boot package level modeenv lock work?09:31
pedronismborzecki: yes, but I think it will be messy, I wouldn't do that unless we have a strong reason to09:32
mborzeckipedronis: hm state lock also has some nice checks built in already09:32
pedronislike the code as is would have to old for the existence of the observer09:33
pedronisyou need to unlock at the right times also on error paths etc etc09:33
* zyga quick break for something warm (temperature dropped by 15C) and back to reviews10:21
pedronismvo: seems 20.04 is failing degraded with secureboot-db.service loaded failed failed Secure Boot updates for DB and DBX11:00
mvopedronis: fun, I saw this too11:02
mvopedronis: do you plan to review 9227 or shall I do that ? the size() helper one11:02
pedronismvo: I touched it myself now so a review from somebody else is better11:03
mvopedronis: sure thing, doing that now11:03
mvopedronis: similar question about 921311:03
pedronismvo: 9213, it looks okish, I'm not sure it makes 100% sense but I'm also not sure this the last version of that code we need11:06
pedronismvo: it looks too much like guessing to me11:08
mvopedronis: thanks11:12
pedronismvo: should I leave a comment there?11:15
mvopedronis: I think that would be good11:16
mupPR snapd#9209 closed: daemon: correctly parse Content-Type HTTP header <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9209>11:16
mvopedronis: I also looked at 9227 and added a possible suggestion11:17
pedronismvo: done https://github.com/snapcore/snapd/pull/9213/files#r47834362311:23
mupPR #9213: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>11:23
mvopedronis: ta11:25
pedronismvo: your suggestion is exactly what I undid , see my new comment11:25
pedronisthe code originally had the error and use stat11:25
pedronisin Size11:25
pedronismvo: sorry, you wasted a bit of time, your suggesting is exactly the reverse of my last commit11:27
mvopedronis: aha, then I misunderstood your comment, I thought you said too much stuff in stat is ill-defined. but this variation is only returning size not the full stat info11:27
pedronismvo: sorry, that was the original comment, my motivation for my last change is its commit11:28
mvopedronis: I see it there now, that's fine then. thank you11:28
pedronismvo: snaps are meant to be immutable (notwithstanding all the fun of try and snapdir) so the size shouldn't really be variable11:28
mvopedronis: yeah, it makes sense11:30
mupPR snapd#9227 closed: snap: add size to the random access file return interface <Simple 😃> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9227>11:31
=== msalvatore_ is now known as msalvatore
zygapedronis: while reviewing validation sets and refreshing my memory, I came across a TODO and wrote https://github.com/zyga/snapd/commit/76049517f35f25e68b165fe0f427555fb790bf93 -- should I propose it later?11:52
pedroniszyga: I don't know, I expect there are changes needed also outside of asserts11:54
zygaah, I didn't think about that11:54
zygaanyway, it's not a big thing, just something I noticed while reviewing11:54
pedronisyes, is something to do11:55
pedronisat least seed and seedwrite needs changes as well11:55
pedronisdon't know if there are other places11:55
pedronisnaive grepping says likely only seed and seed/seedwriter12:00
zygapedronis validation sets have perfect test coverage, nice12:08
cachiozyga, hey12:10
zygahey!12:10
zygaI had a quick look at your branch12:10
zygaI left some comments,12:10
cachioso, yesterday tried everything12:10
cachioto make work the user session for root12:11
zygacachio did you get a logind session?12:11
cachioalso tried the change in spread12:11
cachiono12:11
zygacachio ok, I'll try to help after the standup12:11
cachiozyga, thnanks12:12
ijohnsonmorning folks12:25
pedronispstolowski: hi, I re-reviewed #921112:26
mupPR #9211: o/snapstate: disk space check with InstallMany <Disk space awareness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/9211>12:26
pstolowskipedronis: thank you!12:27
pstolowskiwill push the tweaks in a moment12:27
zygapedronis https://github.com/snapcore/snapd/pull/9155#pullrequestreview-47667722612:42
mupPR #9155: asserts/snapasserts: introduce ValidationSets <validation-sets :white_check_mark:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/9155>12:42
mupPR snapd#9230 opened: overlord/devicestate: do not release the state lock when updating gadget assets <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9230>13:27
zygacachio I'll look at the external thing in a moment, let me grab some food13:43
cachiozyga, sure, thanks a lot13:43
ijohnsonpedronis: actually sorry I forgot I need to step out for a few minutes, can we chat in like 15 minutes or later today about the ensure boot problem ?13:43
mupPR snapd#9213 closed: secboot: read kernel efi image from snap file <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/9213>13:47
pedronisijohnson: I have meetings in 10 mins for 1h13:50
pedronisI can chat after that13:50
zygacachio back with food, let me tinker a little and I'll get back to you13:54
cachiozyga, sure13:58
ijohnsonpedronis: ack I'll send a meeting invite just to be sure14:01
zygacachio I have something that works14:30
zygalet me minimize it14:30
cachiogreat14:30
jdstrandmvo: hey, so I addressed all feedback in PR 8920 quite some time ago and this is one of the items that I milestoned for 2.46. I'm not sure if people are waiting on pedronis because it has his tag, but I addressed all his feedback so I think really anyone could review14:32
mupPR #8920: interfaces: update cups-control and add cups for providing snaps <Needs Samuele review> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8920>14:32
jdstrandmvo: zyga did review and approve the now closed PR 9194 (with some non-blocking comments), but 8920 doesn't have reviews14:34
mupPR #9194: interfaces: update cups-control and add cups for providing snaps - 2.46 <Created by jdstrand> <Closed by zyga> <https://github.com/snapcore/snapd/pull/9194>14:34
jdstrands/reviews/approvals/14:34
zygammm14:34
zygaI should review those14:34
zygacachio ok14:43
zygacachio try this: sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --pipe sh -c "loginctl"14:43
zygaworks on 18.04 for sure, I can look at older systems too14:44
zygayou can drop the sh -c thing, just give it a path to a script14:44
cachiook14:45
cachiosystemd-run: unrecognized option '--pipe'14:46
zygacachio 16.04?14:46
cachiozyga, core1614:46
zygacan you try on newer system14:46
zygaI will adjust it to core1614:46
zygatry core18 for now14:46
cachiosure, let me get the image14:47
zygacachio for 16.0414:52
zygasudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --tty  sh -c "loginctl"14:52
zygait's not the best but meh14:52
zygait probably is enough14:52
cachiozyga, works14:55
zyganote that --pty may be problematic14:55
zygaso we may need something slightly different like a hand-rolled code that does this and bridges stdin/stdout14:55
zygawithout making a pty14:55
zygaptys are problematic14:55
cachioso, we a new unit that runs this?14:56
cachioto keep the session up during the test?14:56
zygacachio this runs a program with a PAM name14:57
zygain isolation from the session of the calling user14:57
zygathat's enough14:57
cachiohttps://paste.ubuntu.com/p/WsPfXcfTH8/14:58
cachioI see this14:58
cachiosame if I run with a test user14:59
zygaright14:59
zygaon core16 with core18 snap installed:15:00
zyganah, that doesn't work15:02
zygatry what I gave you15:02
zygaand I'd like to know what you tried15:02
zygasince it didn't work for you before15:03
ijohnsonpedronis: ready ?15:03
pedronisijohnson: finishing previous meeting15:03
ijohnsonsure let me know when you're ready15:04
cachiozyga, just tried manually with the command you sent15:04
zygawhich command?15:04
cachio<zyga> sudo systemd-run --unit "spread-$RANDOM" --property=User=root --property=PAMName=runuser-l --tty  sh -c "loginctl"15:04
cachiothat one15:04
pedronisijohnson: ready now, sorry15:04
zygaI mean before, when it failed?15:04
cachioyesterday tried updating spread to use runuser instead of sudo -i15:05
cachioto run the script15:05
cachioalso tried manually to start the session for root using runuser15:05
cachioI created a systemd unit with that15:06
cachiosomething similar to what you just passed but without --property=PAMName15:07
cachioI manually created the unit15:07
cachioI tried to make the unit sleep forlong time15:08
cachioto it was going to be running15:08
cachiozyga, does it make sense?15:09
zygacachio I wonder why that didn't work15:09
zygabut anyway15:09
zyganow you have something to work with15:09
cachiozyga, yes, I'll try with this15:10
cachioI think I can make it work15:10
cachiozyga, thanks15:11
cachioI'll try again after lunch15:12
* cachio lunch15:12
ijohnsonjdstrand: rebuilding a snap with go 1.15, I see a seccomp denial that isn't there when compiled with go 1.14 for copy_file_range, and that is only allowed for docker-support currently15:45
ijohnsonjdstrand: is it possible / feasible / sensible to add that to the default template ?15:46
ijohnsonthe denial looks like this: `audit: type=1326 audit(1598542961.776:12423): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=157684 comm="security-secret" exe="/snap/edgexfoundry/x1/bin/security-secrets-setup" sig=0 arch=c000003e syscall=326 compat=0 ip=0x47b5ea code=0x50000`15:46
ijohnsonjdstrand: see also this update in the go 1.15 release notes:15:50
ijohnson> The os.File type now supports a ReadFrom method. This permits the use of the copy_file_range system call on some systems when using io.Copy to copy data from one os.File to another.15:51
ijohnsonjdstrand: ah apparently there is an upstream fix for this where if copy_file_range returns EPERM then Go falls back to an alternate impl that should work in confinement see https://go-review.googlesource.com/c/go/+/249257/15:53
ijohnsonso I guess this problem will just go away with the next Go release, but is there a security reason not to allow copy_file_range in the default profile ?16:06
* zyga goes to work upstairs 16:07
ijohnsoncachio: the regexp in ubuntu-core-20-64:tests/main/listing needs to be updated too to account for pre versions16:16
ijohnsoncachio: see the failure here: https://pastebin.ubuntu.com/p/MBG5Crr8bC/16:16
cachioijohnson, ah, yes, I'll do it today16:19
cachioijohnson, thanks for the heads up16:20
ijohnsoncachio: np16:20
* cachio afk 30 minues17:14
jdstrandijohnson: sorry, was in a meeting17:31
ijohnsonjdstrand: no worries, if you prefer I can open a PR tagged with security review and discussion can take place there17:34
jdstrandijohnson: reading the man page, it seems like a reasonable addition for the default template since a) you are giving it open fds that should be mediated by apparmor and b) this is not dissimilar to write()17:41
jdstrandijohnson: so, logically, it makes sense but would need to look deeper into how the LSM handles it17:41
jdstrandijohnson: that sounds fine17:42
ijohnsonjdstrand: ack I can certainly throw up a PR for you to look at eventually17:42
ijohnsonjdstrand: they are unblocked since go 1.15 will be updated to fix the problem sometime soon, so it's not a rush to fix anymore17:42
ijohnsonthanks!17:42
mupPR snapd#9230 closed: overlord/devicestate: do not release the state lock when updating gadget assets <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/9230>17:43
mupPR snapd#9231 opened: tests: update listing test for "-dirty" versions <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9231>17:48
mupPR snapd#9232 opened: run-checks: check for dirty build tree too <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9232>19:03
mupPR snapd#9231 closed: tests: update listing test for "-dirty" versions <Test Robustness> <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/9231>19:18
mupPR snapd#9233 opened: vendor: run ./get-deps.sh to update the secboot hash <Skip spread> <Created by mvo5> <https://github.com/snapcore/snapd/pull/9233>19:23
mupPR snapcraft#3268 opened: v2 plugins: add catkin plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/3268>22:02
mupPR snapd#9234 opened: systemd/systemd.go: support journald JSON messages with arrays for values <Bug> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/9234>22:44
=== chesty_ is now known as chesty

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