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