[07:11] good morning [07:12] doko: fyi - all adt tests on snapd are green except s390x, I take care of this one today [07:12] hey zyga, good morning [07:50] :) [08:09] morning [09:33] mo'in [09:33] mvo: EHLO [09:33] PR snapcraft#2394 opened: build providers: fix osx non base and injection [09:34] mvo: I haven't merged #6093 because I hear it's wanted in 2.36 and don't know if we still need to squash-merge things that need that [09:34] PR #6093: daemon: spool sideloaded snap into blob dir [09:34] mvo: or should I write a separate PR and target it at the release branch? [09:41] Chipaca: thats fine, pedronis wanted to have a quick look at 6093 before it is merged [09:41] Chipaca: and once its in (ideally via squash merge) we can cherry pick [09:42] ok [09:44] Chipaca: hey! one question to your userid&snapshots fix, ready to re-approve once clarified [09:47] mvo: Chipaca: looking at it now [09:51] PR snapcraft#2393 closed: lifecycle: make snapcraft init template use > not | [10:00] PR snapd#6102 closed: overlord/snapshots: survive an unknown user [10:02] mvo: Chipaca: commented. mostly nitpicks that could go in a follow up but a bit worried at the cost vs frequency of cleanupOldTemps [10:04] pedronis: ah, I'll add a time check thing [10:04] pedronis: i got confused because i have a different pr that has this already :-) [10:04] not pr, a commit [10:04] a stash even [10:04] the one with warnings for devmode things :-) [10:11] morning [10:15] hey mborzecki [10:17] hey mborzecki [10:18] stuck in a slightly boring talk, doing reviews :) [10:19] haha [10:19] mvo: Chipaca: https://github.com/snapcore/snapd/pull/6101 is green but doesn't have a description/motivation [10:19] PR #6101: switch travis unit tests to xenial [10:19] btw. there should be some video streams at http://codedive.pl/ in case anyone is interested [10:26] desktop helpers part for the post-remote-parts world https://www.irccloud.com/pastebin/fwLMLqKc/ [10:33] PR snapcraft#2395 opened: Fixed Errors of macOS environment [10:40] pedronis: i'll add motivation [10:40] pedronis: it's not a strong one right now :-) but will be someday [10:40] soon i hope [10:43] Chipaca: thx [10:57] Chipaca: ah, dist: xenial wasn't a thing until now [10:57] ? [10:57] pedronis: it's not a thing until tomorrow, officially [10:57] heh [10:57] ok [10:57] Chipaca: so we should not merge it until tomorrow? [11:00] pedronis: up to us :-) [11:00] pedronis: it's no big secret, tomorrow is when it's supported officially but we're sitting next to them today and tomorrow :-) [11:00] pedronis: we can also say "nah not worth it" and close the pr [11:01] Chipaca: no, it's fine, just trying to understand [11:33] PR snapcraft#2394 closed: build providers: fix osx non base and injection [11:36] mvo: https://forum.snapcraft.io/t/lack-of-compiled-locales-breaks-gettext-based-localisation/3758/16 [11:36] locale strikes back [11:37] I would love for us to include locale in core instead of having layers of hacks like that [11:40] br [11:40] brb [11:48] PR snapcraft#2395 closed: Fixed Errors of macOS environment [11:51] Chipaca: I'm going to review your epochs PR, but if I understand correctly is not the full story, we should chat about epochs next week [11:53] mvo, hey, I see this often on core 18 [11:53] https://paste.ubuntu.com/p/G6GFxSphzs/ [11:58] pedronis: +1 [11:58] pedronis: AIUI the bit missing is the refresh revving, but I might've missed something else [11:58] PR snapd#6104 opened: snapctl: add "services" [11:58] pstolowski: ^^^ might be of interest to you. [11:59] also, hm, wut, missing services in -h [12:00] * Chipaca investigates [12:01] oh d'oh [12:01] also, also, d'oh² broke unit tests [12:05] Chipaca: thanks, will take a look [12:05] cachio: when you see this, what is the status of "systemctl status snapd"? [12:05] cachio: did you managed to reproduce it? [12:05] mvo, no [12:05] I cant reproduce it [12:06] :/ [12:06] ok [12:06] I just see the error on travis [12:06] I can create a PR to force it [12:06] I need to look at this then and try to understand how it can happen, if its frequent it might be worthwhile to add debug: | for that [12:06] mvo, which debug info do yo uneed [12:07] just status for snapd¡ [12:07] cachio: systemctl status snapd would be good for a start [12:07] cachio: maybe journalctl -u snapd as well just to be on the safe side [12:07] cachio: it might be that its just running too early and no snapd is around at all yet [12:07] cachio: in which case its probably harmless but let me look at the test again after lunch with fresh eyes [12:07] ok, I'll create a PR to for that [12:08] sure [12:19] PR snapd#6105 opened: NOT REVIEW: New task to force error on degraded test [12:28] zyga, on fedora with core18, xdg-open doesn't work, is that a known issue? [12:28] "/usr/bin/xdg-open: 2: exec: snapctl: not found" [12:28] oSoMoN: no, I don't believe this is know [12:28] which snapd version? [12:29] there is an update: https://bodhi.fedoraproject.org/updates/FEDORA-2018-48cc10ba1d [12:29] could you please test it [12:29] and report on the update page [12:29] zyga, ack, will do just after lunch and will keep you posted [12:29] thank you [12:32] mvo: I added some comments to the originally dotfiles PR, about the name and the base declaration bits [12:34] PR snapd#6106 opened: overlord/ifacestate: Handler for hotplug-update-slot tasks [13:22] zyga, the update fixes my issue with xdg-open \o/ [13:22] I'll report on the test page [13:22] whee, that's great [13:22] thank you [13:28] pedronis: thank you! [13:41] flock unit test randomly failing https://www.irccloud.com/pastebin/eL5WynJ7/ [13:45] do snaps have access to /run ? [13:47] andyrock: to some parts of run, yes [13:47] it depends on specific path [13:49] zyga: e.g. if there is a snap called "random-snap" can I access /run/random-snap ? [13:49] otherwise how does it work? [13:51] andyrock: are you asking if some snap can access /run/random-snap? [13:51] in general the answer is no [13:51] in specific case the answer may be yes [13:51] it is defined by the snap interface system [13:51] by the set of plugs, slots and the connections between them [13:52] zyga, the real question is "what would it take to let the livepatch snap write it's status file in /run (so it's auto-cleaned on reboot)" I think [13:52] andyrock, ^ right? [13:52] jdstrand, ^ [13:53] zyga: yes, livepatch snap write a status file to communicate with update-notifier [13:54] seb128, andyrock a trivial tweak to the interface I suspect [13:54] * zyga looks [13:54] andyrock: the snap already has access to XDG_RUNTIME_DIR, if that is helpful: [13:54] $ sudo hello-world.env |grep XDG_RUNTIME_DIR [13:54] XDG_RUNTIME_DIR=/run/user/0/snap.hello-world [13:54] right now that file is in /var/snapd/canonical-livepatch/current/status [13:54] ah, there's no live patch interface [13:55] * jdstrand is assuming it is the daemon that needs write access to it [13:55] but considering that files applies to a boot session would be nice to have it under a "run" directory [13:55] XDG_RUNTIME_DIR still isn't created by anything, byt you can mkdir it and write it there [13:56] *considering that the status file [13:56] andyrock: I suggest looking at XDG_RUNTIME_DIR. you don't need any changes to snapd for that [14:00] jdstrand: is that directory accessible by the system? [14:00] andyrock: yes [14:01] jdstrand: kk. It looks like it's what we need [14:01] thx [14:03] oh hrmm, /run/user/0 doesn't exist and the snap can't create it. zyga, that really needs to be fixed somewhere [14:03] andyrock: ^ [14:04] PR snapd#6107 opened: cmd/snap, snapctl: add column selectors to services [14:04] (standup) [14:04] zyga: I've always argued that the session manager (ie, systemd) should do it, but it isn't [14:04] jdstrand: I think we can do it now [14:04] for non-root it all works. we should probably have snapd just create it [14:05] or snap-confine, which is where I think you are going [14:05] yes [14:05] snap-update-ns specifically [14:05] andyrock: you will need some snapd support after all [14:05] anyway, I will think about it [14:05] andyrock, seb128: can you please file a bug on this [14:05] OR find one that exists [14:05] about XDG_RUNTIME_DIR for root [14:05] I'll assign that to myself [14:05] zyga: note, it needs to preserve the property that the host can see it [14:05] right === matteo| is now known as matteo [14:05] zyga: thanks! [14:07] jdstrand, zyga, those are created/destroyed with the corresponding user session, if root has no login/session that's why it doesn't exist [14:08] it would make more sense to have a /run/livepatch-status [14:09] but that might require a custom interface for livepath then... [14:09] unless there is a new rule to allow using "/run/" [14:17] seb128: I think we could do a custom interface as well [14:18] jdstrand: ^ [14:18] seb128: there is no such rule today [14:18] right [14:18] seb128: perhaps we could add /run/snap.$SNAP_NAME [14:18] well either way it seems it needs changes in snapd [14:18] that might be a nice default [14:18] right [14:18] seb128: yes, for sure [14:18] I think it would be useful [14:18] for others snaps as well [14:18] I agree [14:18] and would be easier than a new interface [14:18] indeed [14:18] something for 2.36.1 perhaps [14:18] I like it [14:19] where should that wishlist be reported? github? forum? [14:19] seb128: I actually prefer a bug report but it can also be a forum [14:19] seb128: bug is something I can assign to myself [14:19] seb128: forum is nicer for discussion [14:19] k, so basically you want both :) [14:20] andyrock, want me to open those? [14:20] seb128: as you prefer, otherwise I'll do that once I finish what I'm currently working on [14:20] andyrock, I'm doing it [14:22] thank you! [14:33] zyga, https://forum.snapcraft.io/t/snaps-can-not-write-to-run-by-default/8367 and https://bugs.launchpad.net/snapd/+bug/1802112 [14:33] Bug #1802112: Snaps can't write to /run by default [14:33] thank you [14:34] pedronis: ^ can you look at this please - if there's agreement to allow snaps to write to /run/snap.$SNAP_NAME then it could be a trivial one liner change for 2.36.1 - the use case is live patch dropping a status file that some part of classic world can look at [15:16] zyga: it does sound reasonable and aligned to other things we do, we do need jdstrand input on it tough [15:19] jdstrand: is there a way in which a snap can set network configuration? Specifically setting a static IP address? On core? [15:21] zyga: I answered in the bug [15:22] thank you [15:22] * pedronis break [15:23] jdstrand: can you please look at https://bugs.launchpad.net/snapd/+bug/1802112 [15:23] Bug #1802112: Snaps can't write to /run by default [15:25] popey: network-control gives all the raw lowlevel stuff (eg, use of 'ip') [15:26] jdstrand: even on core? [15:26] popey: yes [15:26] awesome [15:26] popey: if you want netplan configuration, then look at network-setup-control [15:27] popey: or if they have network-manager installed, plugs network-manager [15:27] jdstrand: thanks, this is a 'legacy' [15:28] popey: there may be some interplay with netplan that they'll need to work through when using network-control, but network-control will definitely allow them to do stuff. ogra might have tips [15:29] ok, ta [15:29] popey, https://github.com/ogra1/dashkiosk-image-config netplan-import might be interesting [15:30] the problem is this snap needs to run on core and non-core [15:30] and could run on non-ubuntu [15:30] so needs to special case all the random nonsense ways people set IP addresses etc [15:30] (copies any "netplan.yaml" file from a USB device you plug into the device and reboots with new network config) [15:30] oh, ok [15:31] popey, in any case network-setup-control is enough to replace the config in /etc/netplan ... you want the shutdown interface too and trigger a reboot for it to take effect (netplan generate/apply are not allowed atm) [15:32] Chipaca: is #6107 something that was discussed at the summit? [15:32] to check for core just look for snap_core= in /proc/cmdline (shouldnt be restricted) [15:32] PR #6107: cmd/snap, snapctl: add column selectors to services [15:32] pedronis: yes [15:33] pedronis: gustavo's suggestion actually [15:33] pedronis: reasoning being that the table output isn't too script-friendly [15:35] Chipaca: I see, that's a bit true of a lot of our commands tough [15:35] Chipaca: is this one particurly egregious? [15:37] Chipaca: I mean, do we need a choose your column general strategy instead? [15:37] pedronis: this one is the only one in snapctl afaik [15:37] pedronis: I asked the same thing though, --column=foo [15:37] pedronis: but, translations [15:38] Chipaca: the only one, doesn't sound a statement that will be true forever [15:38] * Chipaca nods [15:39] Chipaca: I understand that we tried something for snap list and it was a quagmire [15:39] pedronis: with --format you mean? yes [15:39] yes [15:41] Chipaca: I understand I'm not being super constructive, but I'm trying to understand if it's the start of a slippery slope [15:41] pedronis: I understand :-) [15:45] zyga: ping [15:45] yes sir [15:45] zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1802124 [15:45] Bug #1802124: Error installing chromium-mir-kiosk on RPi3/edge [15:46] zyga: does this mean we need to move those to per-arch code? [15:46] yes [15:46] zyga: note the lookup table thing is already per-arch [15:46] I though that was exactly what you did [15:46] aaah [15:46] zyga: ah indeed [15:46] I thought it was all per-arch [15:46] yes, I'm afraid that's needed [15:46] Chipaca: while I have you [15:46] * Chipaca is had by very few people [15:47] does the snap environment use the core system's ld-linux-x86-64.so.2 or can you ship your own? having glibc version issues [15:47] quick question about this particular piece of code https://github.com/snapcore/snapd/blob/master/run-checks#L180 [15:47] zyga: shoot [15:48] Croepha: why are you having glibc version issues [15:48] Chipaca: is it legitimately complaining about this usage: https://github.com/snapcore/snapd/pull/6095/files#diff-36a23153f5bbd7bffd11c24597ac50fdR238 [15:48] PR #6095: packaging/opensuse: stop using golang-packaging [15:48] Croepha: is your snap classic, or strict? [15:51] Chipaca: im shipping a newer version of libpython and it requires a newer version of glibc than what is in core, I wasn't using strict, I was using try, right now im just using a chroot directory in my home while I do some development iterations [15:52] Croepha: you get glibc mismatches because you build against a different glibc than the one in the core you specify [15:53] Croepha: I seriously doubt libpython requires a particular glibc version, although it's quite likely that a particular version of libpython is only available in a distribution with a newer glibc [15:53] Croepha: you can probably build the newer libpython against the older glibc [15:53] Croepha: or you can use a newer base [15:54] Croepha: or you can tell snapcraft to ship your own libc in the snap [15:54] Croepha: in general the last one is not a good idea [15:54] but, it's there if you need it [15:54] mvo: question, do we check when installing if bases have actually type: base, I looked around and didn't find such a check [15:54] (you probably don't need it) [15:54] ok, thanks Chipaca [15:54] zyga: thinking about it [15:54] yes? [15:55] zyga: i mean, the usage is ok, although I don't know what an empty entry in GOPATH does [15:55] in this specific case it's never empty [15:55] suse is a bit looney that it sets GO{ARCH,OS,PATH,ROOT} for all users [15:55] there's a /etc/profile.d/go.sh [15:56] that contains values matching some compiler (via alternatives) [15:56] zyga: are these layout docs: https://forum.snapcraft.io/t/snap-layouts/7207 ? does it need to mention that the experimental flag is no more now [15:56] pedronis: not sure, I need to look. will do so after the meeting [15:56] mvo: thank you [15:56] pedronis: that's correct, [15:56] pedronis: I will amend it to say that since snapcraft 3.0 that uses bases and since snapd 2.36 it is not experimental anymore [15:57] thanks [15:59] zyga: so, i've got a fix for you [16:00] pedronis, degville: I edited https://forum.snapcraft.io/t/snap-layouts/7207 to account for the new reality (enabled since 2.36 and since snapcraft 3.0 with bases) [16:00] zyga: http://paste.ubuntu.com/p/zJPFQnRgX8/ [16:00] zyga: bundle that in if you can [16:00] thank you! [16:00] yep, I will [16:01] zyga: thanks for the heads-up! [16:01] zyga: degville: should layout be a top level topic in the docs? either way I think snap format doc should mention them and link to this [16:02] I'm talking about https://docs.snapcraft.io/the-snap-format/698 -> layout docs [16:02] zyga: the hint was in what exactly was getting highlighted in the output :-) [16:03] pedronis: I think it should be referenced from the format spec [16:03] not otherwise top-level IMO [16:03] ok [16:04] pedronis, zyga : yep, I agree. [16:05] zyga: degville: I left a note for you in the forum topic about this [16:05] thanks! [16:05] thank you [16:10] Hello folks; we're currently investigating a snap store outage, snap requests may be slow or fail intermittently. [16:10] oh, thank you for the note roadmr === sparkieg` is now known as sparkiegeek [16:41] * zyga needs coffee [16:43] roadmr, thanks [16:48] snap store should be back to normal now, folks. Thanks for your patience [16:55] Chipaca: re 6104, making it 2 separate PRs (1 PR to just move the old code around) would make review easier [17:10] mvo, https://travis-ci.org/snapcore/snapd/jobs/451975712#L1234 [17:10] this is the error on degraded with extended debug info [17:12] mvo, I see some retries to get the catalod [17:13] mvo: snapd failed to build on amd64 [17:13] mvo, but nothins weird apart fo that [17:14] re [17:14] roadmr: thank you! [17:14] * zyga got involved in some homework === pstolowski is now known as pstolowski|afk [17:28] doko: looking [17:29] cachio: if you are on the system, can you please paste the output of "journalctl -u snapd.seeded.service" and "systemctl status snapd.seeded" ? [17:32] pstolowski|afk: noted [17:34] cachio, I am not but I'll trigger it again [17:38] zyga, updating scripts to create tumbleweed image [17:39] pstolowski|afk: not sure i'll be able to do it tonight though but i'll try [17:39] zyga, it should be ready soon [17:39] yesterday i fell asleep on the train and stuff [17:39] * Chipaca really tired by all this weird "human" interaction [17:39] PR snapd#6108 opened: many: apparmor support for rpm distros [17:39] :) [17:40] cachio: super, thanks === shaner is now known as shaner2_ === shaner2_ is now known as shaner [19:10] PR snapd#6108 closed: many: apparmor support for non-AA rpm distros [19:36] jdstrand: FYI https://github.com/snapcore/snapd/pull/6108#issuecomment-436750366 [19:36] PR #6108: many: apparmor support for non-AA rpm distros [19:36] jdstrand: sorry, if I knew you were interested in packaging I would have said something [19:36] I'm working on packaging for a few days now [19:37] jdstrand: I will propose the stuff I have as soon as https://github.com/snapcore/snapd/pull/6095 lands [19:37] PR #6095: packaging/opensuse: stop using golang-packaging [19:53] PR snapd#6095 closed: packaging/opensuse: stop using golang-packaging [19:59] PR snapd#6108 opened: many: apparmor support for non-AA rpm distros [20:02] zyga, finally the image ready [20:02] zyga, and I could create a script to automate the process [20:02] cachio: super [20:03] I can run a tumbleweed test quickly [20:03] yes [20:03] just use image: opensuse-tumbleweed-64 [20:04] thank you, I will report back [20:04] zyga, great, thanks === chrisccoulson_ is now known as chrisccoulson [23:37] what's the story about running external executables inside a snap? I'd like to publish a couple of snaps that work on Go source code, and these days the only way to do that is by invoking the go command. Should I package up the go compiler into my snaps too?