mupPR snapd#7917 opened: snap-bootstrap: trigger udev for new partitions <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7917>01:37
mupBug #1846894 changed: Cannot use PulseAudio in classic confinement <Snappy:Expired> <https://launchpad.net/bugs/1846894>04:19
mupPR snapd#7909 closed: snap: improve squashfs.ReadFile() error <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7909>05:53
mupPR snapd#7911 closed: systemd: fix uc20 shutdown <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7911>05:53
mupPR snapd#7912 closed: boot: write modeenv when creating the run mode <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7912>05:53
mupPR snapd#7915 closed: lkenv.go: adjust for new location of include file <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7915>06:12
mupPR snapd#7918 opened: boot: copy kernel/base to data partition in makeBootable20RunMode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7918>06:13
mupPR snapd#7914 closed: bootstrap: reduce runmode mounts from 5 to 2 steps <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7914>06:14
mvohey mborzecki06:48
mupPR snapd#7919 opened: snapstate: do not try up update bootloader in ephemeral mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7919>06:49
mborzeckimvo: hey, any interesting PRs to look at?06:50
mvomborzecki: 7918,7919 are hopefully interessting06:53
mborzeckimvo: ok, let me see, i saw some chatter yesterday about that but i may not be familiar with the details06:56
mupPR snapd#7920 opened: snapstate: do not try to detect rollback in ephemeral modes <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7920>07:11
mvomborzecki: yeah, all pretty straightforward but probably needs samuele anayway07:13
mborzeckimvo: #7916 is quite trivial07:19
mupPR #7916: interfaces/browser-support: add more product/vendor paths <Created by Erick555> <https://github.com/snapcore/snapd/pull/7916>07:19
mborzeckipstolowski: hey08:02
mupPR snapd#7921 opened: devicestate: run boot.MakeBootable in doSetupRunSystem <Created by mvo5> <https://github.com/snapcore/snapd/pull/7921>08:21
=== niemeyer_ is now known as niemeyer
=== nniehoff_ is now known as nniehoff
=== plars_ is now known as plars
=== souther_ is now known as souther
=== blackboxsw_ is now known as blackboxsw
=== bloodearnest_ is now known as bloodearnest
=== stoopkid_ is now known as stoopkid
=== cydizen_ is now known as cydizen
=== davecore_ is now known as davecore
=== coreycb_ is now known as coreycb
=== nottrobin_ is now known as nottrobin
mupPR snapd#7905 closed: cmd/snap-bootstrap: actually parse snapd_recovery_system label <UC20> <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7905>09:15
pedronisdegville: I don't have enough access to make comments or suggestions to the assertions doc09:23
degvillepedronis: sorry - fixed now. I keep expecting docs to default to edit in share mode.09:24
Chipacadegville: 👋09:25
Chipacadegville: I noticed while on holiday that in the glossary we were mixing up core and core1609:25
Chipacadegville: if nobody brought that to your attention, here is me doing so :)09:25
degvilleChipaca: thanks! pedronis did indeed point it out - hopefully fixed now.09:26
Chipacadegville: good good :)09:26
pedronisdegville: thank you, I did a pass09:42
degvillepedronis: thank you!09:42
mupPR snapd#7922 opened: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>10:12
pedronisdegville: I did some edits to the glossary, please look at the last diff, feel free to reedit if needed10:17
pedronisdegville: we also should tweak the assertions entry once we have agreement in the main doc10:17
pedronisdegville: weird, seems for reasons discourse merged my update with your last one10:24
pedronis(that is confusing (tm))10:24
pedronisdegville: pstolowski: I made a couple of suggestions in the preseed help doc10:29
degvillepedronis: thanks! I'll take a look at the glossary diff and your other comments!10:30
pstolowskipedronis: thanks!10:30
pedronispstolowski: the help texts are good for me now10:31
pstolowskipedronis: +1, i can prep a PR once degville makes a pass10:33
degvillepstolowski: looking now, but they're good for me too.10:33
degvillepstolowski: +1 from me too...  thanks for creating the docs.10:36
pstolowskinp, thanks for feedback!10:37
mupPR snapd#7923 opened: snap-bootstrap: mount filesystems after creation <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7923>10:56
=== cjwatson_ is now known as cjwatson
cachioChipaca, hey11:12
Chipacacachio: 'sup11:12
cachiolast week there was a problem with the apt-hooks test11:12
cachiostore started rejecting calls to /names api11:13
cachioI had to set as manual the test11:13
cachioChipaca, this is the log https://paste.ubuntu.com/p/JY69dz4vwP/11:14
cachioChipaca, do you know if anything chante in snapd that could be causing this?11:14
Chipacacachio: nothing changed in snapd no11:15
mupPR snapd#7924 opened: tests: fix use of MATCH -v <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7924>11:15
cachioChipaca, so, somethings changed in the store11:16
Chipacacachio: probably11:17
Chipacacachio: how often were we getting this, and in what timeframe?11:17
mborzeckiChipaca: ^^11:17
mborzeckifun PR11:17
Chipacamborzecki: yep, nice11:17
cachioChipaca, almost all the runs were failing11:17
cachioChipaca, and if you run now the whole suite it fails too11:18
mborzeckicachio: 429 Too Many Requests, store doesn't like us anymore?11:18
cachioyesterday I rna the checks pr which wasn't merged to master nad apt-hooks failed11:19
cachiomborzecki, aparently not :)11:19
Chipacacachio: when did this start?11:19
cachiotuesday / wednesday11:20
mborzeckilogger.go:74: DEBUG: < "HTTP/1.0 429 Too Many Requests\r\nCache-Control: no-cache\r\nConnection: close\r\nContent-Type: text/html\r\n\r\n"11:21
mborzeckiit'd be nice to see the content11:21
cachioChipaca, reviewed the google docs and I see the error started on tuesday11:22
mborzeckicachio: this happens when running on gcp?11:22
cachiomborzecki, yes11:22
mborzeckicachio: ok, trying out something11:27
cachiomborzecki, nice, thanks11:30
mvo7904 needs a second review11:30
mborzeckicachio: heh, i suppose i can stop spamming api.snapcraft.io, can't reproduce this, maybe curl takes too long between requests11:37
cachiomborzecki, perhaps I could add extra logging and run apt hooks test11:38
cachiodoes it make sense?11:38
mborzeckicachio: have you seen it pop up in PR travis jobs?12:01
mupPR pc-amd64-gadget#29 opened: grub.cfg-normal: go back to the UC16 way of loading the kernel <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/29>12:01
mupPR snapd#7925 opened: cmd/snap-preseed: update help strings <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7925>12:01
mborzeckicmatsuoka: question for you in 791712:06
cmatsuokamborzecki: sure12:06
mborzeckicmatsuoka: maybe worth trying, provided the spread tests pass12:07
cmatsuokamborzecki: let me check what that does exactly...12:08
cmatsuokamborzecki: so you mean calling it after all nodes are there (and it would act on all block devices, not only the ones we just created)?12:09
mborzeckicmatsuoka: no, just adding --subsystem-match=block to the udevadm trigger call12:10
cachiomborzecki, yes12:10
pstolowskipedronis, degville #7925 is up12:10
mupPR #7925: cmd/snap-preseed: update help strings <Simple 😃> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7925>12:10
cachiomborzecki, initially I saw that in travis12:10
degvillepstolowski: thank you!12:10
cachiothen I could reproduce it manually here12:11
cmatsuokamborzecki:  since we're already calling it with a block device target, I think it wouldn't change what it's doing12:11
cmatsuokamborzecki: I'll have a look at the source code to be sure12:12
mborzeckicachio: ah, right12:12
mborzeckicachio: yeah, so it's fine12:12
cachiomborzecki, which should be the best configuration for adding more debug info ?12:25
cachiotrying to add more debug without touching the code12:25
cachiomborzecki, currently we use SNAPD_DEBUG_HTTP=7 SNAPD_DEBUG=112:26
mupPR pc-amd64-gadget#29 closed: grub.cfg-normal: go back to the UC16 way of loading the kernel <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/29>12:28
mborzeckicachio: i think that we only dump the outgoing request data12:33
cachiomborzecki, now is not failing anymore apt-hooks12:37
mupPR snapd#7926 opened: cmd/snap-bootstrap: xxx todos about kernel cross-checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/7926>12:45
cachiomvo, about 2.43 on arm6412:47
cachioit is not in beta the snapd snap12:47
mvocachio: oh, let me check. maybe there was a mistake :( sorry for that12:49
mvocachio: should be fixed now12:50
cachiomvo, thanks12:50
=== ricab is now known as ricab|lunch
mborzeckicachio: pushing some patches to reset the state of failed services after each test run in a couple of minutes13:00
cachiomborzecki, nice, I am going to the hospital now, I'll review it there13:02
* cachio afk13:06
mupPR snapcraft#2845 opened: remote-build: configurable timeout/deadline for starting and monitoring build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2845>13:43
mupPR snapd#7925 closed: cmd/snap-preseed: update help strings <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7925>13:52
mupPR snapd#7924 closed: tests: fix use of MATCH -v <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7924>14:03
=== stgraber_ is now known as stgraber
=== ricab|lunch is now known as ricab
=== heather is now known as hellsworth
mvohrm, lot's of reds in snapd already14:47
mvoeh, travis - has anyone looked?14:47
threshhello. can someone explain to me why I can not see "real" hostfs root from my VLC snap, but still can access it via /var/lib/snapd/hostfs/ ?  i'm on debian, snap/snapd 2.42.5, kernel 5.3.0.  vlc is installed in "strict" mode.14:48
cachiomvo, any test that I could take a look?15:01
cachioof those reds?15:01
pstolowskithresh: the filesystem that snaps see is composed on the fly from core snap (or core18) and various bind-mounted dirs, so it's completely different from the host fs. hostfs is mounted on the side under /var/lib/snapd/hostfs/ for some interfaces (such as system-observer or opengl), but access is controlled by apparmor (which i suppose you don't have)15:07
threshthanks pstolowski15:08
threshI do have apparmor though, and aa-status reports VLC as enforced mode, as well as ps auxZ: snap.vlc.vlc (enforce)          thresh     70717 24.0  0.4 1002360 71556 pts/1   Sl+  18:09   0:00 /snap/vlc/1049/usr/bin/vlc --config=/home/thresh/snap/vlc/common/vlcrc15:09
mvocachio: I have not investigated, just noticed in recent PR runs15:11
cachiomvo, ok, your PRs right?15:11
cachioI am gonna take a look15:11
pstolowskithresh: do you have vlc's opengl plug connected?15:13
threshpstolowski, yes15:13
mupPR snapcraft#2846 opened: base plugin: use shlex quoting for logged command in run() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2846>15:13
pstolowskithresh: opengl interface gives access to portion of hostfs - see https://github.com/snapcore/snapd/blob/702a637803b1da7f55596e6de3d76057929e5f78/interfaces/builtin/opengl.go#L3815:15
threshpstolowski, I can reproduce the same behaviour e.g. with "jq" snap, which doesnt have any plugs15:17
pstolowskithresh: do you mean the snap can access entire var/lib/snapd/hostfs ?15:17
threshand this doesnt really explain why opengl plug allows access to /data/1.mkv in my case15:17
threshwell, rather /var/lib/snapd/hostfs/data/1.mkv15:18
threshI mean, it's probably due to debian, and confinement being not full15:21
threshbut I'd rather like to understand what exactly causes that15:21
mvocachio: yeah, it may well be it all real, i was too busy to check15:21
cachiozyga, could you please take a quick look to #787715:24
mupPR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>15:24
cachioit is failing in many prs15:24
pstolowskithresh: most likely yes.. i cannot confirm this observation with ubuntu. could you please show the output of:snap debug confinement15:26
pstolowskithresh:  snap debug confinement15:26
pstolowskithresh: and 'snap debug sandbox-features'15:26
threshpstolowski, https://code.videolan.org/snippets/1118 there you go15:27
cjp256anyone have a good example on how to configure opengl for `classic`?15:27
cjp256i built an opengl app that just works without any special casing on my nvidia graphics system, but fails on intel.   Interesting that nvidia just works in the classic case?15:29
pstolowskithresh: right. that's it15:29
pstolowskithresh: on ubuntu it is strict, and for apparmor it's apparmor:             kernel:caps kernel:dbus kernel:domain kernel:file kernel:mount kernel:namespaces kernel:network kernel:policy kernel:ptrace kernel:query kernel:rlimit kernel:signal parser:unsafe policy:default support-level:full15:29
pstolowskithresh: and also confinement-options:  classic devmode strict (yours is missing strict)15:31
threshright, so the differences are: missing kernel:dbus, and policy:downgraded vs policy:default15:33
threshthere is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923500 but that seems to be forgotten, too15:33
cjp256zyga: ^ maybe you have some thoughts wrt opengl? :D15:33
pstolowskicjp256: zyga is off this week; perhaps mborzecki ? ^15:35
mborzeckihm hm?15:35
cjp256ah, thanks!15:35
mborzeckicjp256: does the snap include relvant mesa libs and drivers?15:36
cjp256it does not (yet) - but I assume it should, and should do something like found https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L8115:37
cjp256while I'm doing this for specific snap right now, my ultimate goal is to add an "opengl" extension which should just work for classic or strict15:38
cjp256though it was interesting that without any mesa stuff, nvidia worked15:39
pstolowskithresh: right.. and the last comment there is from zyga.. he may know more where we are with this, but as i just said, he is off15:39
mborzeckicjp256: nvidia is handled slightly differently, especially for confined snaps15:39
=== AdmWiggin is now known as tianon
mborzeckicjp256: fwiw that should be transparent for the snap15:40
cjp256yeah, this one is classic (alacritty terminal).15:40
cjp256the mesa packages should also be staged with classic, correct? don't attempt to use the host's?15:43
mborzeckicjp256: looked ad the code again, for classic we don't set up anything nvidia specific, it's only done when snap is confined, but mesa should be part of the snap in both scenarios15:44
mborzeckiwish we had some time allocated for the gpu support proposal zyga had, but maybe next cycle15:45
mborzeckicjp256: if you have thoughts/ideas feel free to review https://forum.snapcraft.io/t/gpu-support-proposal/11247/13 and share them15:46
cachiopstolowski, could you take a quick look to #7877 please?15:47
mupPR #7877: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>15:47
cjp256ah, was not aware of that.  thanks mborzecki :)15:47
cachiothis is constantly failing on master15:47
pstolowskicachio: sure15:47
cachiopstolowski, thanks15:48
* cachio lunch15:53
pstolowskicachio: a general question there, i'm confused by this change, need more info. if you can provide a more elaborate description it would be super helpful (the sentence "The idea os this test is the rsyslog service when it does not exist." needs fixing)16:20
tomwardillhello! Store team here, downloads are currently having a bad time, and you might get errors. We're looking at it :)16:21
cachiopstolowski, sure16:22
pstolowskicachio: thanks!16:22
cachiopstolowski, yaw16:22
tomwardilldownloads should now be working again!16:46
cachiopstolowski, description updated16:58
pstolowskicachio: the description is fine. have you seen my reply re uc18?17:17
cachiopstolowski, yes, I am making hte change17:20
pstolowskicachio: i'm about to EOD but don't want to block this PR17:20
cachio1 sec17:20
cachiopstolowski, nice, thanks17:20
pstolowskicachio: i can approve, just push the change to limit it to uc1817:20
pstolowskibefore merging17:21
cachiopstolowski,  pushed17:24
vidal72[m]why in snap users aren't allowed to manually connect slots that aren't declared in manifest?17:28
cachiopstolowski, is it ok there or it is better to put is at the begining of the prepare phase?17:29
cachioperhaps that's more clear17:29
vidal72[m]when some slot is missing and snap maintainer is afk then it's a dead end...17:29
pstolowskividal72[m]: well, that's deliberate, snaps must know what they need and must be upfront about that. otherwise people would start connecting random slots in a hope of getting a broken snap to work. if a snap is missing a slot it should have, it's a bug of the snap like any other bug..17:34
pstolowskicachio: yes i think beginning would be better17:36
pstolowskicachio: also made one small remark17:36
vidal72[m]pstolowski: yes but the bug remains unfixable by user if publisher doesn't cooperate17:37
cachiopstolowski, nice, already pushed the change17:39
cachiopstolowski, thanks for the review!!!17:39
cachiopstolowski, thanks for the +117:43
cachioI'll merge it once it is in gree17:43
pstolowskividal72[m]: yeah, but that's no different than any other software bug. what you propose has secruity implications. nb, you can try repack that snap yourself and change its manifest, then install it with --dangerous17:43
cachiosee you tomorrow17:43
pstolowskiyep, eod, cu!17:44
mupPR snapd#7877 closed: tests: avoid mask rsyslog service in case is not enabled on the system <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7877>18:42
bdxI have just registered the snap name "munge"19:09
bdxhere is the repo for the snap https://github.com/omnivector-solutions/snap-munge19:10
bdxOmnivector is going to be maintaining this snap19:10
bdxCan I request an approval on the name please?19:11
bdx(the snap store wont let me push to "munge" until its approved by someone)19:11
roadmrhi bdx19:27
bdxroadmr: how's it going?19:27
roadmrbdx: to be clear, are you as a snap developer going to be maintaining the snap, or do you envision transferring it to another Omnivector account?19:27
bdxthe https://github.com/omnivector-solutions github account is where it will live as far as I can see19:29
bdxthere will be others that contribute to the project, but the upstream will always remain https://github.com/omnivector-solutions/snap-munge19:30
roadmrbdx: right, I'm thinking in terms of snap store accounts here19:31
bdxahh yes, I dont think I have created a snap store account for omnivector yet19:31
roadmrbdx: and no worries, we can approve for your account and then transfer to a more project-centric account19:31
roadmr(if desired, of course)19:31
bdxok, I see19:31
bdxshould I just create the omnivector snap store account now in that case?19:31
roadmrbdx: you could, and then I can transfer the name (which I've just granted to you anyway).19:33
roadmrbdx: the typical pattern is for the snap to be registered under an e.g. "omnivector" account (for the org/project) which is tied to an e-mail address controlled by the project itself, and then individual people (e.g. you) are attached to the snap as collaborators19:34
bdxahh I see - I was just going to ask abou thtat19:34
roadmrbdx: this helps in the case of a snap maintainer not being able to maintain the snap for some reason - it can then be transferred away from that person but it's easier if the transfer is avoided altogether :)19:35
bdxentirely - is there a way for me to create the "omnivector" org in the snap store?19:35
roadmrbdx: there's no concept of organizations in the snap store :( what you'd do is register an "omnivector" developer account (i.e. set that as the username)19:35
roadmrbdx: it does have to have an e-mail address different from yours, though19:36
bdxok, np19:36
bdxso, the snapstore wants to use my ubuntu one user19:36
bdxshould I create the ubuntuone user "omnivector" then19:37
roadmrbdx: yes, you'd need to create an altogether new ubuntuone user :/ sorry for the extra hoops19:37
bdxroadmr: np19:41
bdxroadmr: I've created a snapstore user "omnivector-solutions"19:41
bdxis it possible for you to transfer the registered name to this user?19:42
roadmrbdx: I'll do so right away :)19:44
roadmrbdx: done!19:46
bdxroadmr: thats awesome! many thanks!19:46
roadmrnp, happy to help :)19:46
bdxroadmr: I was able to upload a release to stable and install from the snap store!19:48
bdxone small quirk ....19:49
bdxI think its related to the build functionality19:49
bdxIf I click into the "build" tab in the web ui19:50
bdxI am presented with a page that asks me to login with github19:50
bdxafter I login with github I am redirected to the jamesbeedy snapstore account19:51
roadmrbdx: hmm.19:52
bdxso, I get here https://imgur.com/a/HfjbnBJ19:52
mupIssue pc-amd64-gadget#30 opened: Git tags and versioning <Created by eslopez92> <https://github.com/snapcore/pc-amd64-gadget/issue/30>19:52
roadmrbdx: I'm not super familiar with the build service :/ not sure how it establishes who you are from your github login19:52
roadmroh but that says you're omnivector, right?19:52
bdxsee in the img ^ it says omnivector19:53
bdxbut when I click the login weith github button19:53
bdxit seems to login my jamesbeedy user https://imgur.com/a/lwQZ6Hk19:54
bdxeither way, not a big deal for me19:54
roadmroh I see19:54
bdxjust thought I would mention it19:54
roadmrright, we'd have to ask the build service folks, most of them in Europe so probably sleeping now heh19:54
bdxyeah no worries19:54
bdxI can file a bug for it19:54
bdxroadmr: thanks again for your help here19:55
roadmrbuild service issues here: https://github.com/canonical-web-and-design/snapcraft.io/issues19:56
mupPR snapd#7927 opened: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>20:50
mupPR snapcraft#2847 opened: Catkin plugin: consider only 'local' workspaces <Created by artivis> <https://github.com/snapcore/snapcraft/pull/2847>21:17
bdxI have a few questions about socket-directories using the content interface21:26
bdxI have one snap that provides a socket-directory plug https://paste.ubuntu.com/p/N7wchfdYhM/21:28
roadmrbdx: (in case you don't get a reply here, you can always post in the forum :) a bit easier for people to see that asynchronously)21:28
bdxok, will do - thx21:28
=== gurmble is now known as grumble
bdxwe can see the socket that the munge process creates here https://paste.ubuntu.com/p/FwvQ7JQNZw/ in SNAP_DATA21:29
bdxI create another snap to test with munger21:30
bdx^I have one snap that provides a socket-directory slot*21:32
bdxthe other snap creates the plug21:32
bdxI install both of the snaps and connect the content interface plug of one to the content-interface slot of the other https://paste.ubuntu.com/21:35
* cachio eod21:36
bdxonce both the snaps are connected, I can see the socket in the snap that creates it, but I can't see my socket in the snap that has the consuming plug https://paste.ubuntu.com/p/6tJPVs7x9s/21:39
bdxerr .. that didn't come across so well21:48
bdxI've rephrased it a bit on discourse here https://forum.snapcraft.io/t/the-content-interface/1074/9?u=jamesbeedy21:48
mupPR snapd#7928 opened: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7928>22:31
mupPR snapd#7926 closed: cmd/snap-bootstrap: xxx todos about kernel cross-checks <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7926>22:35
=== ahayzen_ is now known as ahayzen

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