[02:00] PR snapcraft#1879 opened: extractors: replace desktop file ids with paths [05:42] Morning all [05:42] Saviq: I've added the additional machines you requested on Spread, should be accessible to you already === chihchun_afk is now known as chihchun [06:26] niemeyer: fantastic, thank you [06:31] morning [07:40] PR snapd#4464 closed: overlord/snapstate: do a minimal sanity check on containers [07:45] cachio: everything ready in the beta channel for validation. as yesterday no new snapd, just package updates (see http://people.canonical.com/~mvo/core-changes/html/beta/ for details) [07:47] mvo_: morning [07:49] hey mborzecki ! [07:49] mvo_: do you know if snapcraft also needs to do some work on https://forum.snapcraft.io/t/snap-service-start-ordering/1470/ ? [07:50] mvo_: that's also what pedronis suggested, what leaves me wondering if i should poke someone from the snapcraft [07:50] team [07:53] mborzecki: I think it does, it has a yaml schema for everything that can go into snapcraft.yaml. so the new things need to be added there iirc [07:53] mborzecki: you can poke sergiusens (at a sprint) or kalikiana [07:53] ok, thanks [07:53] mborzecki: probably relatively easy, you could give it a stab yourself [07:55] good morning [07:55] zyga-ubuntu: hey [07:55] how are you all feeling? :) [07:58] hey mborzecki [07:59] I can give you some pointers if needed [07:59] adding that should be pretty straightforward [08:00] assuming you'll want basically the same yaml as in the snap.yaml [08:05] mvo_ mborzecki we got guidance at the sprint that the user docs need to be written first before proceeding on features so a PR against the docs would be nice to see [08:05] sergiusens: interesting, thanks for sharing [08:06] * zyga-ubuntu enjoys morning coffee [08:08] mornings! [08:08] o/ [08:39] PR snapd#4492 closed: spread: try to enable Fedora once more [08:39] PR snapd#4504 opened: snap, wrappers: systemd WatchdogSec support [08:40] figured i might as well add support for the watchdog if i'm to update snapcraft and the docs [08:44] mborzecki: +1 [09:13] PR snapd#4500 closed: snapstate: make no autorefresh message clearer [09:13] 4499 needs a 2nd review [09:14] pstolowski: perhaps? [09:14] trivial [09:16] loooooking, but github is sooo slooow atm [09:16] * Chipaca waves [09:17] mborzecki: does this need a gustavo approval? https://github.com/snapcore/snapd/pull/4487 [09:17] PR #4487: cmd/snap: snap refresh --timer, hide --time [09:17] Chipaca: o/ \o \o/ [09:17] zyga-ubuntu: yes, probably [09:17] mvo_: I'd added the "sleep 1" thinking that the reason it wasn't seeing the messages in the journal was a race, when in the end it was git being a git [09:17] k [09:17] mvo_: so i was able to drop the sleep 1 \o/ [09:18] asked niemeyer to take a look at both #4487 and #4476 [09:18] PR #4487: cmd/snap: snap refresh --timer, hide --time [09:18] PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule [09:22] uhm no github for me atm, anyone else having problems? [09:24] pstolowski: works for me [09:25] Chipaca: yeah, I noticed [09:25] * zyga-ubuntu solicits reviews for https://github.com/snapcore/snapd/pull/4471 [09:25] PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS [09:26] mborzecki: I added a suggestion to the 4467, maybe a personal thing, but I found it slighly easier this way. please check it out. [09:28] mvo_: it's much cleaner indeed, thanks [09:33] hurray for enabling opensuse spread tests again, but … they're failing again? :-( [09:37] mborzecki: thank you [09:37] Chipaca: yeah, tests are a bit unstable again :/ [09:37] with the EOF thing I thought was my fault in the user pr! [09:37] that one was driving me crazy(er) [09:37] good luck :-D [09:39] mborzecki: thanks for working on 4504! quick question: aiui for watchdogSec to work the app must call sd_notify() which needs to talk to a system socket - does that mean this pr also needs apparmor rules so that the app can access this socket? [09:40] mvo_: hah! i just commented trying to point mborzecki along those lines :-D [09:40] get out of my head :-p [09:40] mvo_: yeah, this was mentioned by Chipaca in https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268 [09:40] * mvo_ hugs Chipaca (from the inside) [09:40] anways, i'm about to find out the hard way :) [09:40] mborzecki: haaha [09:42] * Chipaca installing every app in /var/cache/snapd/names to check for validation problems [09:43] s|app|snap with type:app| [09:43] mborzecki: its slightly annoying that the NOTIFY_SOCKET is set via an env, it seems it is currently /run/systemd/notify it seems there is no grantee about this === chihchun is now known as chihchun_afk [09:49] Chipaca: what is annoying is that 4503 failed three times already for different reasons :( [09:53] mvo_: if you've restarted it 3 times, then it's been restarted at least 5 [09:55] oh, I restarted it too [09:55] Chipaca: *weep* [09:55] lol [09:55] that's one unlucky bastard then [09:55] and also *moreweep* [09:55] maybe it will be around when we hit PR 10K [09:55] PR #10: Update README.md [09:55] we should have a 'carbon footprint per PR' competition [09:55] pr #100 [09:55] PR #100: Ongoing work on the capability APIs [09:55] pr #1000 [09:55] PR #1000: debian: use sudo in setup of the proxy environment [09:56] pr #1 [09:56] showoff [09:56] :-) [09:56] Chipaca: heh, pretty even, no? 10: you, 100: zyga, 1000: me [09:56] pr 1 [09:56] *pff* no pr 1? [09:57] nope [09:57] it was probably an issue [09:57] bug #1 ;-) [09:57] Bug #1: Microsoft has a majority market share

[09:57] tinarussell>

[09:57] [09:57] * zyga-ubuntu gets back to work [10:03] jdstrand: fwiw, it's just a case of installing xrdp and a desktop environment, and putting the session name (like "mate-session") in ~/.xsession [10:15] kind ping about 4471 [10:15] it's blocking everything for me [10:15] please halp [10:17] mvo_, i have some weird behaviour of core on one of my boards here, seems it auto-refreshed to the beta one even though it tracks edge [10:19] ogra: what do you see in "snap changes"? [10:19] mvo_, https://paste.ubuntu.com/26409733/ [10:19] tracking: edge [10:19] installed: 16-2.30 (3872) 71MB core [10:19] ogra: I switched edge/beta around a bit in the morning, so maybe you see effects from this [10:20] in the morning ? ... thats 3:30am ! [10:20] ogra: this an non i386/amd64 system, right? [10:20] (admittedly in technical sense that is "morning" indeed :P ) [10:21] mvo_, armhf [10:21] ogra: heh :) yeah, I did not mess around with things at this time [10:21] ogra: when is the next auto-refresh (snap refresh --time)? [10:21] $ snap refresh --time [10:21] schedule: 00:00-05:59/6:00-11:59/12:00-17:59/18:00-23:59 [10:21] last: 2018-01-18T06:21:00Z [10:21] next: 2018-01-18T15:55:00Z [10:21] ogra: I wonder if the next auto-refresh will push you back to a +git version [10:22] the revision is lower now ... [10:22] (in edge( [10:22] i could run a manual refresh ... [10:22] ogra: yeah, this is what I did this morning, moved edge back to a git version [10:22] ogra: yeah, just snap refresh should bring you back. I think its "expected" (in an unexpected way) [10:22] (should not be different from auto, right ?) [10:23] and so it does ... [10:23] Make snap "core" (3852) available to the system [10:23] ... [10:23] ogra: i.e. yesterday edge was "2.30" and there was a core snap build in the night which also had 2.30, then later your board refrehsed to 2.30 and in my morning I pushed edge back into +git land and now it should refresh to this (does that make sense) [10:24] yeah, makes complete sense [10:24] thanks for clearing the myth :) [10:25] ogra: its all (more) confusing because no auto-builds, everything need to be manually approved for building [10:25] (i only noticed because i had put the revision into a release note for a customer ... and was just shocked that i typoed 3852 for 3872 when i looked at it this morning :P ) [10:26] mean that the revisions were so similar :) [10:26] heh [10:26] ok [10:51] Speaking of `beta`s...the beta is a different revision to candidate/stable but the same version number? Seems confusing...what happened there? [10:51] Was it just because you were switching them around? : [10:51] * :P [10:54] version numbers in snaps are shallow [10:54] they are just a string in snapcraft.yaml ... [10:54] revisions are what counts [10:54] well [10:54] that said ... [10:55] versions are for human consumption :-) [10:55] it is likely the content is actually the same in the case of core [10:55] and are merely descriptive [10:55] (unless some of the additional packages changed ... the core snapcraft.yaml actually generates the version from the snapd version) [11:16] Chipaca: it failed again [11:16] on fedora [11:27] PR snapd#4503 closed: osutil/sys: ppc has 32-bit getuid already [11:31] mvo_: was it green in the end/ [11:31] zyga-ubuntu: no, i merged it anyway [11:32] zyga-ubuntu: I need to get a deb build to see if it fixes the build failure [11:33] "contact develper" [11:33] * Chipaca looks for a brown paper bag [11:33] *cough* [11:34] and i only realised when writing https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/3566 [11:47] hmm? [11:47] what is contact developer about? [11:51] zyga-ubuntu: "develper" [11:51] ah [11:51] typo [11:54] zyga-ubuntu: fyi, I reviewd 4472 [11:54] reviewed even [11:58] thank you!@ [11:59] thanks! I'll update the rules and merge [11:59] jdstrand: I'm working on layouts now, while they won't work (apparmor) they are now applied to mount profile, the PR will need some discussion but it looks like a good start [12:01] * pstolowski lunch [12:02] greyback: ok, so, in thinking about this, I think we want to adjust the *mir*ConnectedPlugAppArmor policy to have '/{dev,run}/shm/\#* mrw,', then have your snap plugs mir and x11 [12:04] greyback: the idea is that if your snap snips xwayland, it is a mir client, so needs to 'plugs: [mir]', then the thing that talks to x11 needs to 'plugs: [x11]' [12:05] jdstrand: xwayland is a wayland client, it's not using the mirclient libraries [12:05] greyback: this is slightly odd because the app is really the slot for x11 though [12:05] yeah I know [12:05] greyback: the shm access is really a mir thing though, no? [12:06] is having a separate xwayland snap, which has the x11 slot, too much? [12:06] jdstrand: that is something I've never quite figured out [12:06] perhaps I should, to get things straight [12:06] greyback: in terms of policy, the shm access is only in mir [12:07] true [12:07] I was extrapolating from there when I suggested adjusting mir [12:07] yep, understood [12:07] I also understand the the shm access within the context of mir is considered safe [12:08] let me ask around and try verify that [12:08] or at least figure out exactly what in /dev/shm is needed [12:08] and by what [12:09] greyback: ftr, having a separate xwayland snap would not be required. you could embed it; your snap would just slots x11 (assuming we had that policy) [12:09] so you slot it to yourself [12:09] but, let me read something back you said a minute ago [12:09] I didn't know you could slot to yourself [12:10] that would do the trick [12:10] let's assume that xwayland is one command in your snap and chromium another [12:10] (for clarity) [12:10] if xwaland is a wayland client, it should plugs wayland (let's not worry about shm for the moment) [12:11] chromium is not a wayland client, so it should plugs x11 [12:11] xwayland command is providing x11 [12:11] so xwayland slots x11 [12:11] so [12:12] the x11 interface grows the slot side (perhaps we can put the shm access in PermanentSlotAppArmor...) [12:12] right so ar [12:12] far [12:12] the you have [12:12] name: foo [12:12] apps: [12:13] chromium: [12:13] plugs: [ x11 ] [12:13] xwayland: [12:13] slots: [ x11 ] [12:13] plugs: [ wayland ] [12:14] greyback: I think that aligns with how you described how xwayland works [12:14] Chipaca: and another ppc failure: https://paste.ubuntu.com/26410328/ - this time in boltdb [12:14] jdstrand: yes that makes sense [12:15] I'll give that a go [12:15] jdstrand: thanks for the advice [12:15] greyback: *today* a full on Xorg xserver wouldn't be able to run with the slot policy you right for x11, but that is ok. if that ever comes up, we can adjust the policy. this way you can focus just on the xwayland bits [12:15] PR snapd#4505 opened: interfaces/mount,snap: early support for snap layouts [12:15] right? [12:16] s/right/write/? [12:16] (what an ugly typo) [12:16] Chipaca: ^ early PR for layouts, [12:16] mvo_: ^ [12:16] ta [12:16] jdstrand: heh, silly english with homonyms [12:17] small, just for quick feedback on the idea [12:19] greyback: for your testing, perhaps just tuck the shm access into the PermamentSlotAppArmor bit of x11 and add a TODO comment to investigate. before we merge, you investigate. it might be that we adjust mirConnectedPlugAppArmor to have the shm access and xwayland to plugs: [ wayland, mir ] since *this* wayland client happens to need it cause of some mir thing [12:19] obviously depending on your investigation [12:19] jdstrand: *nod* [12:19] that's a plan [12:19] greyback: ok, sorry for the lagginess on this. I'll be back from sprinting next week [12:20] jdstrand: not at all, thank you for the help [12:20] np [12:51] PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack [12:55] Chipaca: sorry to bug you but could you please (perhaps) split that PR into distinct commits that can be reviwed earliy [12:55] *easily [12:56] Chipaca: maybe one for typo, one for mv, more for extra features [12:56] otherwise that's a 1K diff [12:56] zyga-ubuntu: I can. Most of the diff is the move from snapstate to snap, i guess [12:56] lemme close that [12:56] before it chomps up a travis [12:57] thanks [12:57] oh drat, standup [12:57] ... quick coffeee [12:57] eeeeeeeeeeee [12:58] PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack [13:01] zyga-ubuntu: there you go [13:02] PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack [13:06] PR snapd#4499 closed: packaging/14.04: move linux-generic-lts-xenial to recommends [13:16] cachio: do you the version of fedora kernel used on linode? [13:32] * kalikiana time for lunch [13:34] woot, one branch merged :) [13:35] PR snapd#4472 closed: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP [13:35] pstolowski: about 4358, how to approach it? [13:35] pstolowski: any advice on how to review it? [13:40] zyga-ubuntu: hey - I never saw if you got the apparmor label query issue straightened out? [13:41] tyhicks: yes and no [13:41] tyhicks: I drowned in dbus, iteration is a pain [13:42] tyhicks: but mvo added a label that jdstrand suggested that fixed the problem [13:42] tyhicks: (labeling the snap userd service as unconfined) [13:42] zyga-ubuntu: do I need to fix a bug caused by that upstream change? [13:42] tyhicks: it looks like the bug is real but it's not a pressing issue for us now [13:42] tyhicks: I think so, it will affect other things [13:42] (not just snapd) [13:43] zyga-ubuntu: what's a simple reproducer? attempt to query a label of a peer connection in bionic? [13:44] tyhicks: on bionic, revert mvo's change (I'll give you a link in a moment), install gimp (probably works with other snaps but this works for sure); snap run --shell gimp; xdg-open http://example.org [13:44] tyhicks: the logs indicate that there's no peer label information and thus the rule for peer=unconfined doesn't apply and the activation is denied [13:44] zyga-ubuntu, it would probably make sense to start by getting the understanding of the associated spread test and its 2 test snaps and their hooks [13:44] tyhicks: it's *just* activation that is broken [13:45] tyhicks: once activated it works correctly [13:45] pstolowski: thank you, let's see [13:46] tyhicks: I attached logs on the forum if you need those [13:46] (and some advice on how to collect them) [13:46] tyhicks: I think activation should happen regardless and not bail out on lack of the label [13:47] tyhicks: or activation should carry implicit confinement "unconfined" [13:47] tyhicks: reading the code it seems that activation should fail (by design) only on explicit deny rules [13:47] tyhicks: that was the intent [13:47] tyhicks: but this is not how it behaves [13:48] zyga-ubuntu, then repo.go and doConnect handler. policy and connection.go changes last [13:51] zyga-ubuntu: thanks - that helps a lot to understand the problem [13:51] zyga-ubuntu: I have some ideas about how to do this correctly [13:54] tyhicks: the branch to revert, once it lands, is https://github.com/snapcore/snapd/pull/4495 [13:54] PR #4495: data/dbus: add AssumedAppArmorLabel=unconfined [13:55] tyhicks: bug #1742687 [13:55] Bug #1742687: Launching URLs in snapped applications no longer works in 18.04

[14:05] jdstrand, zyga-ubuntu, is there really a bug there? to be it looks like that dbus/apparmor enforces more checking that it used to and that the autoactivated services that AssumedAppArmorLabel info by design [14:06] * zyga-ubuntu lunch [14:06] seb128: yes, I think so [14:06] seb128: reading the code and patch descriptions seems to imply it should not behave this way [14:06] seb128: I'll defer to tyhicks's decision [14:07] zyga-ubuntu, you should report it upstream, they might just fix it for us [14:08] seb128: yeah, I can do that, good idea [14:10] zyga-ubuntu, thanks [14:31] ok, let's review things [14:31] then let's file that bug [14:31] and then, let's ... not sure yet :) [14:31] re [14:31] mborzecki: https://github.com/snapcore/snapd/pull/4505 [14:31] PR #4505: interfaces/mount,snap: early support for snap layouts [14:31] mborzecki: would the group / user thing be a problem on arch? [14:33] zyga-ubuntu: there's a 'nobody' group around here only [14:37] zyga-ubuntu: the uids in tests are hardcoded too [14:39] zyga-ubuntu: maybe it would be best to guess nobody/nogroup the same way we deal with directories [14:40] zyga-ubuntu: li.Group is coming from the snap right? [14:41] mborzecki: hymm [14:42] mborzecki: yes [14:42] mborzecki: I think that I need to tweak that to contain a fixed mapping [14:42] mborzecki: this mapping must make sense on the inside, not for classic host [14:42] mborzecki: and we only support 'root' and 'nobody' [14:56] Chipaca: did you see 4506 failures? [14:56] zyga-ubuntu: i saw your comment [14:56] i'll dig in a bit [14:57] (that pr is a backburner one) [14:57] seb128 (cc zyga-ubuntu and tyhicks): tyhicks and I talked about it. it is fine that dbus is offering more mediation, but the way it is doing it is a bit weird. tyhicks will comment in the bug [14:57] k [14:58] jdstrand, thanks [15:24] * kalikiana really, really hates regex today [15:24] * kalikiana getting more tea [15:31] kalikiana: regex is your friend, imagine if you had to do it by hand [15:32] kalikiana: btw, do you knof about regex derivatives? [15:32] kalikiana: I found that interesting a while back [15:32] kalikiana: https://en.wikipedia.org/wiki/Brzozowski_derivative [15:36] Chipaca: looks like we need https://paste.ubuntu.com/26411304/ in upstream bolt (funny enough this seems to be not fixed in the coreos fork either - ppc seems to be not super popular) [15:36] mvo_: before it blows up, can we check if this builds on other fringe arches? [15:38]