[07:17] <pstolowski> morning
[07:18] <mvo> hey pstolowski, good morning
[07:24] <mvo>  
[07:56] <Chipaca> moin moin
[07:58] <Chipaca> ...rude.
[07:59] <mvo> Chipaca: hey good morning!
[08:00] <mvo> Chipaca: rude?
[08:01] <Chipaca> mvo: joke about somebody leaving without a word just after I said hello
[08:01] <mvo> haha
[08:31] <Chipaca> mvo: do you ready z_yga's "+1 but" as an actual +1, i.e. can I merge #5524?
[08:31] <mup> PR #5524: cmd/snap: check for typographic dashes in command <Created by chipaca> <https://github.com/snapcore/snapd/pull/5524>
[08:31] <Chipaca> read*
[08:32] <Chipaca> mvo: also, did we reach a consensus on the flag to watch for "do not error if none found"? I know we agreed it wasn't --oknodo :-)
[08:33] <Chipaca> was thinking of --no-error-on-empty taking a page from xargs, but it does seem a bit verbose
[08:35] <Chipaca> alternatively, and perhaps more naturally given the flag is only for use with --last, we could add syntax to --last, e.g. «--last=foo?» vs «last=foo»
[08:35] <mvo> Chipaca: I'm not great with names but --no-error-on-empty seems to be ok (yes verbose but). alternatives might be "--empty-ok"
[08:35] <mvo> Chipaca: I like "foo?"
[08:36] <mvo> Chipaca: not sure about zygas +1, but he should be online soon(ish)
[08:36] <Chipaca> sorted :-)
[08:36] <mvo> Chipaca: ta
[08:36] <Chipaca> mvo: ah, i thought they were further west
[08:40] <mvo> Chipaca: its 6h from here, so I would expect (jetlag and all that) in ~2h
[08:52] <zyga> 4am-orning
[08:53]  * ogra_ grumbles about his kiosk app being rejected because of missing .desktop file ... how pointless
[08:54] <Chipaca> hehe
[08:54] <Chipaca> zyga: morning
[08:54] <Chipaca> zyga: we were just talking about you and jetlag
[08:54] <Chipaca> ogra_: wat?
[08:55] <Chipaca> ogra_: what's rejecting your app because of that?
[08:55] <zyga> Store Review tools
[08:55] <zyga> How are you guys doing?
[08:55] <ogra_> yeah ... it uses an x11 loopback interface to itself ... the review tools block if you dont have a .desktop file when this interface is found
[08:55] <Chipaca> zyga: in #5224, does your "+1 but" mean an actual +1?
[08:55] <Chipaca> wait
[08:55] <Chipaca> zyga: #5524
[08:55]  * Chipaca kicks mup
[08:56] <zyga> Mup is partially off
[08:56] <ogra_> jetlag
[08:57] <zyga> Chipaca: that depends, if you agree then you can tweak the feature, if you don’t you can treat my review as +1
[08:57] <Chipaca> zyga: I disagree (explained a bit why on the pr)
[08:57] <zyga> Ok
[08:57] <Chipaca> zyga: (also i brought this other approach up with Juanreal before implementing it)
[08:57] <zyga> I haven’t read that yet
[08:58] <mup> PR #5224: interfaces: remove Plug/Slot types <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5224>
[08:58] <mup> PR #5524: cmd/snap: check for typographic dashes in command <Created by chipaca> <https://github.com/snapcore/snapd/pull/5524>
[09:00] <zyga> mvo: how is core18?
[09:15] <mvo> zyga: mostly happy, the snap-stop-mode test was still racy though, looks like output related, I added marker files and with that I got no failures yet (running with -repeat 100)
[09:16] <mvo> zyga: the integration PR is failing with what looks like unrelated issues
[09:16] <zyga> Thank you! That is good news
[09:16] <mvo> zyga: I am discussing kernel track names right now, I added you to the mail thread and maybe you can ask Gustavo to have a look so that we can make a decision. its one of the blockers for the model assertion for core18
[09:17] <zyga> How about the core18 snapd hosting  slots?
[09:17] <mvo> zyga: you mean 5527? or something else?
[09:19] <zyga> Yes
[09:19] <Chipaca> snap set system refresh.hold=+2h
[09:19] <zyga> I saw it was red
[09:19] <Chipaca> why can't we do that :-)
[09:19] <zyga> Didn’t check deeper yet
[09:33] <pedronis> Chipaca: the plan is to have a command to do that sort of stuff, was blocked on deciding how to call it and the fact we have too many commands
[09:34] <Chipaca> pedronis: I could add it to corecfg (if we ignore that the function is called 'validate' and not 'validate-and-normalise'
[09:34] <Chipaca> )
[09:35] <pedronis> please don't
[09:35]  * Chipaca quietly does 'git reset --hard'
[09:36] <mvo> zyga: aha, indeed, its red because settle is not converging
[09:36] <mvo> zyga: we need to either fake the production snapd id
[09:36] <mvo> zyga: or add the test snapd-id to the detection if its the snapd snap, we had this issue before I think
[09:36] <zyga> Ah, I remember now
[09:37] <zyga> Can you patch that in some acceptable way
[09:37] <zyga> I’d love to say “we can boot core18 and it works”
[09:39] <mvo> zyga: I can add a patch, we will see if that is "acceptable" ;)
[09:39] <mvo> zyga: just working on the sru for 2.34.1 will do in a little bit
[09:39] <zyga> Thank you :-)
[09:39] <zyga> Ok
[10:01]  * Chipaca steels himself to go to the dentist
[10:08] <zyga> mvo: feedback from the field: we should have a workflow where developers can copy a new kernel, snap install it and reboot
[10:09] <mvo> zyga: to test new kernels?
[10:09] <zyga> currently that doesn't work and requires time-consuming workarounds or use of ubuntu classic
[10:09] <zyga> yes
[10:09] <zyga> to do kernel development
[10:09] <zyga> (driver etc)
[10:09] <mvo> makes sense, we have some restrictions here currently mostly to avoid users doing strange things
[10:10] <zyga> mhm
[10:10] <zyga> maybe just --dangerous --very
[10:11] <zyga> or something like this
[10:19] <pstolowski> --scary
[10:23] <zyga> --I-know-what-you-did-last-summer
[10:24] <pstolowski> zyga: how is the sprint going?
[10:24] <zyga> very good so far
[10:24] <zyga> we have one interesting thing that was discussed yesterday evening
[10:24] <zyga> we will change how refresh works
[10:24] <zyga> I will share all the details later today/tomorrow (as time permits)
[10:24] <zyga> it will involve a new hook as well
[10:25] <pstolowski> interesting
[10:54] <pstolowski> pedronis: RFC - https://github.com/snapcore/snapd/pull/5532
[10:54] <mup> PR #5532: api/connect: report "nothing to do" if attempting to re-connect <Created by stolowski> <https://github.com/snapcore/snapd/pull/5532>
[10:56] <pedronis> pstolowski: mmh,   that's a change of behavior
[10:56] <pedronis> I think the old code just did nothing, not an error
[10:58] <pstolowski> pedronis: indeed, the old code would just do nothing in the handler, but created the change etc.
[10:58] <pedronis> pstolowski: we have  a similar case already
[11:01] <pedronis> pstolowski: we do this:   https://github.com/snapcore/snapd/blob/master/daemon/api.go#L1436 but I think Connect shoudl return either an empty ts or some kind of error
[11:01] <pedronis> to trigger that behavior
[11:03] <pstolowski> pedronis: yes i considered empty ts, but wasn't sure a dummy change with 'done' status was a good idea (forgot we have a case already)
[11:05] <pstolowski> pedronis: okay, i will do it that way then
[11:46]  * Chipaca lunch
[11:48] <Chipaca> hmm, clearing refresh.hold with "" seems to be broken
[11:49] <Chipaca> 2018/07/18 12:48:39.556782 stateengine.go:101: state ensure error: internal error: cannot unmarshal snap "core" option "refresh.hold" into *time.Time: parsing time """" as ""2006-01-02T15:04:05Z07:00"": cannot parse """ as "2006", json: ""
[11:49] <Chipaca> hmm
[11:57]  * ogra_ curses loudly ... 
[11:58] <ogra_> the damned review tools are making me mad today
[11:58] <popey> Don't get mad, get even.
[11:58] <ogra_> i think i tried evyery possible way to ship a pointless .desktop file for my kiosk daemon app now
[11:58] <ogra_> but they all got rejected
[11:59]  * ogra_ has no idea how to proceed with that
[11:59] <ogra_> snap/gui/ doesnt work, specifying it in snapcraft.yaml and shipping it doesnt ... not sure what else to try
[12:00] <popey> why not just put a valid desktop file?
[12:00] <ogra_> ?
[12:00] <popey> youre talking about a "pointless" desktop file
[12:00] <popey> why don't you do what we do for every other snap and put a valid one in there
[12:00] <ogra_> well, i use an IMHO valid file
[12:00] <ogra_> the point is that this is a daemon
[12:00] <ogra_> it doesnt need a desktop file since it cant be run from it
[12:00] <popey> can I see the project/yaml/desktop file?
[12:01] <ogra_> https://github.com/ogra1/xdmcp-client
[12:01] <popey> i always put the desktop file in snap/gui/foo.desktop
[12:01] <ogra_> (i originally shipped it in snap/gui, just moved it arouond to toplevel and defined it via deskto: )
[12:01] <popey> and never mention it in the yaml
[12:01] <popey> it gets automatically found
[12:01] <ogra_> yes
[12:01] <ogra_> thats what  did first
[12:02] <ogra_> *I
[12:02] <popey> your icon path is invalid
[12:02] <popey> in the desktop file
[12:02] <popey> put .desktop and .png in snap/gui, and make sure they are both called <snapname>.*
[12:02] <ogra_> yeah, now it is :( ... (wasnt when it was in snap/gui
[12:02] <ogra_> 9
[12:02] <ogra_> thats what i had in the former revision ...
[12:03] <ogra_> like in all other desktop snaps i create ...
[12:03] <ogra_> but that just caused the very same review error
[12:03] <ogra_> popey, https://github.com/ogra1/xdmcp-client/tree/c70eafedf3ea751730677a843782f567d7c2d816 was my last revision
[12:04] <popey> filename is wrong
[12:04] <popey> for the icon, make it xdmcp-client.png
[12:04] <ogra_>  <snapname>.desktop
[12:04] <popey> and refer to it as such in the desktop file
[12:04] <ogra_> well, icon.png works for all other desktop snaps i have ... but happy to try
[12:05] <niemeyer> mvo, nessita: Heya
[12:05] <popey> you can run the snap review tools locally to test it
[12:05] <popey> rather than do the store turn around time
[12:05] <niemeyer> snap info on snaps published by canonical is showing that long email address instead of snaps@canonical..
[12:06] <niemeyer> nessita: What do we need to do to fix that?
[12:06] <nessita> niemeyer, we should reindex the snaps, let me do that
[12:07] <niemeyer> nessita: Thanks!
[12:09] <nessita> niemeyer, have an example of a snap showing the wrong email address?
[12:25] <zyga> nessita: core
[12:27] <nessita> zyga, I see. That's the contact url of a snap which is set by the publisher and is not automatically changed when SSO profile data changes
[12:28] <popey> https://snapcraft.io/core could do with a metadata update too! as could https://snapcraft.io/canonical-livepatch
[12:31] <ogra_> the core text came originally from mark FWIW
[12:31] <ogra_> (i had a way longer text for the initial uploads)
[12:37] <popey> That was when we only had "snap info" though, the web store needs more text to make it look compelling.
[12:38] <Chipaca> not sure core needs to be compelling :-)
[12:38] <nessita> zyga, niemeyer I filed an RT to have the contact_url changed for every snap
[12:40] <ogra_> popey, true
[12:41] <popey> people link to it, it needs more than one line
[12:41] <ogra_> popey, so ... whatever i try i still get the same denial even with local review-tools
[12:41] <ogra_> ogra@acheron:~/Devel/xdmcp-client:master$ review-tools.snap-review xdmcp-client_0.1_amd64.snap
[12:41] <ogra_> Errors
[12:41] <ogra_> ------
[12:41] <ogra_>  - declaration-snap-v2:slots_deny-connection:xephyr:x11
[12:41] <ogra_> 	human review required due to 'deny-connection' constraint for 'on-classic' from base declaration
[12:41] <popey> thats not the same error
[12:41] <popey> that's not a desktop file issue
[12:41] <ogra_> (actually it doesnt look like the desktop file thing at all that i get by mail)
[12:41] <ogra_> no
[12:42] <popey> one for jamies
[12:42] <ogra_> the desktop file is what i got by mail from the review
[12:43] <ogra_> popey, hmm
[12:43] <ogra_> ogra@acheron:~/Devel/xdmcp-client:master$ review-tools.snap-review xdmcp-client_0.1_amd64.snap
[12:43] <ogra_> Errors
[12:43] <ogra_> ------
[12:43] <ogra_>  - declaration-snap-v2:slots_deny-connection:xephyr:x11
[12:43] <ogra_> 	human review required due to 'deny-connection' constraint for 'on-classic' from base declaration
[12:43] <ogra_> err
[12:43] <ogra_> one sec, wrong paste
[12:43] <ogra_> The reviewer provided the following feedback:
[12:43] <ogra_> desktop interfaces (x11) specified without a corresponding meta/gui/*.desktop file. If using snapcraft, please see https://snapcraft.io/docs/build-snaps/metadata#fixed-assets. Otherwise, please provide a desktop file in meta/gui/*.desktop (it should reference one of the &#39;apps&#39; from your snapcraft/snap.yaml)
[12:43] <ogra_> thats what i get by mail ...
[12:43] <mup> PR #39: Login integration test closes #38 <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/39>
[12:44] <ogra_> seems slightly contradicting to what the review tools tell
[12:46] <ogra_> popey, is there a way to find out who did the manual review ?
[12:46] <ogra_> https://dashboard.snapcraft.io/snaps/xdmcp-client/revisions/12/review/ would be one that caused the mail
[12:47] <popey> Jamie
[12:47] <ogra_> oh, yeah, i didnt know i could open that link even !
[12:48] <ogra_> heh
[12:49] <ogra_> well, the tools definitely reject it because the app needs to declare a " slots: [ x11 ]" in the apps: section
[12:49] <ogra_> (to provide an x11 loopback interface for using XWayland under mir-kiosk)
[12:49] <ogra_> geez .... i didnt expect that to be this complicated ....
[12:49] <ogra_> yay ... new technology :)
[12:57]  * ogra_ updates https://forum.snapcraft.io/t/review-tools-forcing-desktop-file-for-kiosk-apps/6436
[13:28] <Chipaca> ogra_: "i didnt expect that to be this complicated" --napoleon, somewhere around sepember 1812
[13:28] <kjackal> hi everyone. I am a bit confused. Is it possible to have the launchpad builders build and release snaps on a few different tracks? Can we have lp builders build from branch A and release to track A and at the same time have other(?) builders build from branch B and release to track B?
[13:29] <roadmr> hello folks, there's currently an outage in the snap store, we're working to solve it, I'll update when it's fixed
[13:29] <kjackal> I may be missing some button
[13:29] <Chipaca> kjackal: I thought the builders only released to [foo?]/edge
[13:30] <Chipaca> kjackal: but https://docs.snapcraft.io/build-snaps/ci-integration seems to imply you should be able to choose branches
[13:31] <Chipaca> oh wait
[13:31] <Chipaca> those are lp branches :-)
[13:31] <Chipaca> kjackal: but in that same page, step 11
[13:33] <kjackal> I think I understand it now. I have to start with the branch on LP and then create the builders. let me try that
[13:34] <roadmr> store outage should now be resolved, thanks for your patience
[13:41] <pstolowski> pedronis: if you have some time for reviews, https://github.com/snapcore/snapd/pull/4940 needs re-reviewing; and i'm waiting for spread test run of #5532
[13:41] <mup> PR #4940: overlord: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
[13:41] <mup> PR #5532: api/connect: ignore connect if already connected <Created by stolowski> <https://github.com/snapcore/snapd/pull/5532>
[13:45] <ogra_> Chipaca, lol
[13:58] <pedronis> Chipaca: hi, could you look at #5515
[13:58] <mup> PR #5515: daemon: make sure most change generating handlers can produce errors with kinds <Created by pedronis> <https://github.com/snapcore/snapd/pull/5515>
[14:09] <Chipaca> pedronis: looking
[14:09] <zyga> how are things going?
[14:10] <zyga> or doing actually
[14:11] <oSoMoN> I've added plugs for gtk-3-themes, icon-themes and sound-themes to the libreoffice snap like was done for a bunch of gnome app snaps, but I'm getting the following error and don't know what's causing it:
[14:11] <oSoMoN> main.go:192: cannot change mount namespace of snap "libreoffice" according to change mount (/snap/gtk-common-themes/319/share/icons/Adwaita /snap/libreoffice/x1/data-dir/icons/Adwaita none bind,ro 0 0): cannot create writable mimic over "/snap/libreoffice/x1": permission denied
[14:11] <oSoMoN> can anyone enlighten me?
[14:12] <Chipaca> pedronis: youch
[14:12] <oSoMoN> (this is what I added to snapcraft.yaml: https://git.launchpad.net/~libreoffice/+git/libreoffice-snap/commit/?id=0e58538d71af93eef00c6d73b7767a548208e30d)
[14:12] <oSoMoN> and the bug report with all the details is https://github.com/ubuntu/gtk-communitheme/issues/350
[14:12] <zyga> oSoMoN: hey
[14:13] <zyga> oSoMoN: can you share the snap yaml's of the two snaps and the output of "dmesg | grep DENIED" please
[14:13] <zyga> oSoMoN: also snap version but I suspect you are just on the latest stable
[14:15] <oSoMoN> zyga, snapcraft.yaml: https://git.launchpad.net/~libreoffice/+git/libreoffice-snap/tree/snap/snapcraft.yaml?h=6.0
[14:15] <oSoMoN> $ snap version
[14:15] <oSoMoN> snap    2.33.1
[14:15] <oSoMoN> snapd   2.33.1
[14:15] <oSoMoN> series  16
[14:15] <oSoMoN> ubuntu  18.04
[14:15] <oSoMoN> kernel  4.15.0-23-generic
[14:15] <zyga> ok
[14:16] <zyga> oSoMoN: can you tell me if $SNAP/data-dir/{themes,icons,sounds} all exist in the snap?
[14:16] <zyga> I assume they don't
[14:16] <oSoMoN> zyga, they don't
[14:16] <zyga> ok
[14:16] <zyga> please share the denial
[14:16] <zyga> and /var/lib/snapd/apparmor/profiles/snap-update-ns.libreoffice from the affected machine
[14:17] <oSoMoN> zyga, there are multiple denials, most of them are similar to this:
[14:17] <oSoMoN> juil. 18 16:17:04 bribon audit[4274]: AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.libreoffice" name="/tmp/.snap/snap/libreoffice/69/" pid=4274 comm="3" srcname="/snap/libreoffice/69/" flags="rw, rbind"
[14:18] <oSoMoN> zyga, https://paste.ubuntu.com/p/HhXgw52vzY/
[14:18] <zyga> ok
[14:19] <zyga> this is https://github.com/snapcore/snapd/pull/5395
[14:19] <mup> PR #5395: interfaces: generalize writable mimic profile <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
[14:19] <zyga> I will try to land this branch
[14:19] <zyga> as a workaround please create, inside the libreoffice snap, the data-dir/
[14:19] <zyga> then the rest should work
[14:20] <zyga> it's the extra level of nesting that is breaking this
[14:20] <Chipaca> pedronis: is sideloadCheck just moved?
[14:21] <oSoMoN> zyga, thanks! I'll test creating the data-dir/ inside the snap
[14:21] <oSoMoN> I wonder why this is working for other snaps, like evince or gedit, though
[14:21] <oSoMoN> those don't have a data-dir/ directory either
[14:24] <zyga> I don't know
[14:24] <zyga> I will study the rules you gave me to see if this is the same thing I think for sure
[14:24] <oSoMoN> thanks!
[14:28] <zyga> oSoMoN: please let me know if this works for you
[14:28] <oSoMoN> zyga, yes, I'm repacking the snap with an additional data-dir/ directory, will let you know
[14:28] <zyga> oSoMoN: thank you
[14:28] <zyga> you can just unsquash it, mkdir and snap pack it
[14:30] <oSoMoN> zyga, yep, that's what I did
[14:30] <oSoMoN> but same error
[14:30] <oSoMoN> I verified that $SNAP/data-dir exists after installing
[14:30] <zyga> can you be more specific please, what is the error you are getting now
[14:30] <oSoMoN> cannot create writable mimic over "/snap/libreoffice/x1/data-dir": permission denied
[14:31] <zyga> that is more curious
[14:31] <zyga> hold on
[14:31] <zyga> well, add the extra three directories and that will go away
[14:31] <zyga> but I really need to get to the bottom of this
[14:31] <oSoMoN> ok, adding those
[14:31] <zyga> and please dmesg the denial that you saw now
[14:32] <oSoMoN> AVC apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="snap-update-ns.libreoffice" name="/tmp/.snap/snap/libreoffice/x1/data-dir/" pid=8248 comm="3" srcname="/snap/libreoffice/x1/data-dir/" flags="rw, rbind"
[14:33] <zyga> thank you
[14:33] <pedronis> Chipaca: yes
[14:33] <oSoMoN> repacking with all three directories now, let's see if that works
[14:33] <Chipaca> pedronis: ah yes i edited locally to confirm :-)
[14:34] <Chipaca> pedronis: before +1'ing it (without the edit it would've taken me a lot longer to review)
[14:34] <pedronis> Chipaca: was moved far for some reason from either it's first or last usage
[14:34] <pedronis> so I moved it
[14:34] <zyga> ah
[14:34] <zyga> I know why it didn't help
[14:34] <pedronis> Chipaca: that test file is too long (tm) :(
[14:34] <zyga> but it's still that bug
[14:34] <Chipaca> pedronis: as is api.go itself
[14:35] <zyga> oSoMoN: the reason is that gtk-common-themes is actually exportng a number of items that are nested themselves
[14:36] <zyga> the branch I referenced fixes this but, as I said, it's on me to land
[14:42] <oSoMoN> zyga, I can confirm that creating the missing dirs works around the issue
[15:18] <abeato> jdstrand, mind taking a look at https://github.com/snapcore/snapd/pull/5469 when you can?
[15:18] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[15:23] <zyga> oSoMoN: thank you
[16:18] <mvo> zyga: pr#5533  allows creating images with the new kernel-track feature of the model assertion. if Gustavo has a free minute it would be great to get his opinion on what kernel track name to pick. having one soon would be really great, then I can start writing an integration test
[16:23] <mvo> hm, no mup currently?
[17:54] <cachio> zyga, https://paste.ubuntu.com/p/BQHWShC7Zv/
[17:55] <cachio> I see these denials executing a test for daemon-notify interface
[17:55] <cachio> zyga, any idea why it could be happening
[17:55] <cachio> =
[18:35] <zyga> cachio: yes, it is not auto-connected
[18:35] <zyga> you have a slot but it's not connected
[18:35] <cachio> zyga, I manually connected it
[18:35] <zyga> I wrote a thread about this on the forum
[18:35] <zyga> it's too late
[18:35] <zyga> you cannot connect it fast enough
[18:35] <zyga> well
[18:36] <zyga> I'd have to see your test service
[18:36] <zyga> but in general you cannot use that from non-service started by systemd
[18:36] <zyga> and you cannot connect it fast enough
[18:36] <zyga> so in practice it's not really usable
[18:36] <zyga> please read my forum post about this
[18:37] <zyga> https://forum.snapcraft.io/t/its-a-little-bit-hard-to-use-daemon-notify-for-sd-notify/6366
[18:37] <zyga> mvo: the github part of mup is off because of the github availability issue
[18:37] <cachio> zyga, what I did is to connect it and the install it again
[18:38] <cachio> zyga, but same issue
[18:38] <zyga> that doesn't help
[18:38] <zyga> it's not auto-connected
[18:38] <zyga> because the install would likely fail
[18:38] <zyga> because the daemon: notify cannot be installed without successfully talking to systemd
[18:38] <zyga> can you show me the test please
[18:39] <cachio> zyga, https://paste.ubuntu.com/p/rkf8VXVg5K/
[18:39] <cachio> https://paste.ubuntu.com/p/wrmrZz2rNY/
[18:39] <zyga> ok, and what did you expect to happen?
[18:40] <cachio> zyga, I am checking logs to see I there is any denial
[18:40] <cachio> zyga, still doing it manually
[18:41] <zyga> the interface is not auto-connected so as soon as you start the service it is attempting to use a program it cannot use
[18:41] <zyga> you can connect it
[18:41] <zyga> restart the service
[18:41] <zyga> but then it may not work _anyway_ depending on what systemd does
[18:41] <cachio> ok
[18:41] <zyga> if it allows you to talk over the socket (separately from our permission)
[18:45] <cachio> zyga, I'll try that, thanks
[19:43] <thiras> hello
[19:44] <thiras> discord and spotify are broken
[19:44] <thiras> $ snap run discord
[19:44] <thiras> ln: failed to create symbolic link '/home/thiras/snap/discord/69/.config/gtk-2.0/gtkfilechooser.ini': File exists
[19:44] <thiras> Gtk-Message: Failed to load module "gail"
[19:44] <thiras> Gtk-Message: Failed to load module "atk-bridge"
[19:45] <thiras> ubuntu 18.04
[19:45] <jdstrand> abeato: yes. it is on my list. I looked at it and am ok with the approach, but I wanted to check a few things before giving my ack. I apologize for the delay. I've been meaning to get to it and am sprinting this week
[19:47] <thiras> spotify has quite similar error log
[20:04] <cachio> zyga, I have updated the PR #5535
[20:04] <mup> PR #5535: tests: fix tests expecting old email address <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5535>
[20:13] <zyga> cachio: I saw just now, thank you!
[20:13] <cachio> zyga, np