[06:01] morning [06:48] mvo: morning [06:52] mvo: do you know the story behind disabling setting up XDG_RUNTIME_DIR? i'm looking at https://bugs.launchpad.net/snappy/+bug/1738197 and the dir is not created [06:52] Bug #1738197: Daemons do not have an /run/user/* dir created [06:53] the piece of code that created runtime dir was disabled with this commit https://github.com/snapcore/snapd/commit/7ea43f1c74e1e056250359031cb715cb85adb349 but there's no message or anything [06:59] hey mborzecki good morning [07:00] mborzecki: I don't remember the backstory :( and the commit description does not help much. I think zyga will remember [07:01] mvo: i also found this PR https://github.com/snapcore/snap-confine/pull/195 [07:01] PR snap-confine#195: Fix creation of $XDG_RUNTIME_DIR and $SNAP_USER_DATA [07:01] opened and closed by zyga, i suppose there were some security concerns raised by jdstrand [07:03] mvo: switched to bug report to confirmed for now [07:08] ta [07:24] PR snapd#4519 opened: arch: add "armv8l" to ubuntuArchFromKernelArch table [07:31] Bug #1738222 changed: FAIL: main_test.go:769: snapSeccompSuite.TestCompatArchWorks [07:40] Bug #1705220 changed: Removing desktop-ubuntu-app-platform broke any app relying on the webapp-helper

[07:54] o/ [08:00] moin moin [08:01] zyga-ubuntu: kalikiana: morning [08:01] what is armv8l? [08:03] mornings! [08:04] can anyone please do 2nd review for https://github.com/snapcore/snapd/pull/3963 [08:04] PR #3963: cmd/snap-confine: add support for per-user mounts [08:07] pstolowski, mvo: can you please give concrete votes on 4505, I'd like to know if there's more work there or can I iterate on top [08:08] PR snapd#4519 closed: arch: add "armv8l" to ubuntuArchFromKernelArch table [08:13] o/ mborzecki pstolowski zyga-ubuntu [08:15] zyga-ubuntu, looking [08:15] PR snapd#4520 opened: daemon: unlock state even if RefreshSchedule() fails [08:16] mvo: you didn't add the mount unit [08:16] thanks! [08:20] zyga-ubuntu: meh, sorry and thanks [08:20] zyga-ubuntu: are the spread tests under cmd/snap-confine still run? [08:21] zyga-ubuntu: I ask because there is one that is concerned with snappy-app-dev and this needs to move to /usr/lib/snapd to work with bases [08:22] 4520 ^^ trivial review [08:38] PR snapd#4521 opened: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev [08:40] mvo: no, only those in tests/ are used [08:40] mvo: there are probably a few stale tests under snap-confine [08:40] zyga-ubuntu: do you mind if I remove at least the one dealing with snappy-app-dev? [08:41] mvo: do they hurt? I think those should be (eventually) ported and re-enabled [08:42] mvo: is that test actually running now? [08:42] mvo: and relevant to the discussion is https://github.com/snapcore/snapd/pull/4399 [08:42] PR #4399: rewrite snappy-app-dev [08:43] zyga-ubuntu, reviewed, some tiny remarks [08:44] pstolowski: thank you! looking [08:47] zyga-ubuntu: that traceback and error, is that fedora in our tests, or in the wild? [08:47] Chipaca: I think that was in the tests that cachio ran [08:47] the net.Error case is new, but the tricky code existed before [08:48] I'll push something [08:50] question [08:50] when you hack on go [08:50] do you keep a symlink in ~ to the $GOPATH/src/yadayadayada directory? [08:50] I ask because I do and I hate how go fmt is stupid and doesn't cope with that [09:08] zyga-ubuntu: I don't understand what you symlink [09:09] zyga-ubuntu: in any case, no i don't keep a symlink in ~ to that :-) [09:10] Chipaca: ~/snapd -> ~/go/src/github.com/snapcore/snapd [09:10] pstolowski: updated [09:10] zyga-ubuntu, k, looking [09:11] zyga-ubuntu: I just ^R cd ~ and it completes that :-) [09:12] zyga-ubuntu: but it helps that I just have two go workspaces i work in with any frequency, snapd and my personal one [09:12] if i had more i'd need to get inventive [09:13] zyga-ubuntu, thanks for the helpers! looks very nice! [09:14] +1 [09:19] pstolowski: thank you for the idea, I will use them in the rest of the code next [09:19] Chipaca: I see, thanks [09:20] did we have a checker for "it's one of these two"? [09:20] Chipaca: so, I feel like I could benefit from your walker and container validation thing [09:21] Chipaca: I could use it to validate that the layout makes sense [09:21] Chipaca: you could abuse "contains" checker in reverse, I presume [09:22] offtopic: my new favourite theme: agola green [09:22] zyga-ubuntu: ebola green? [09:22] https://packagecontrol.io/packages/Agola%20Color%20Schemes [09:23] zyga-ubuntu: i'll push this pr and then fix my container thing [09:26] Chipaca: thanks, it's not urgent, just something I realized [09:28] aaand i've just done the old "committed to my master and pushed" idiocy [09:28] Chipaca: classic, I do that all the time [09:28] * Chipaca now needs to go to github, flip a flag, push force, flip it back [09:28] pstolowski: can you look at https://github.com/snapcore/snapd/pull/4502 please, it's related [09:28] PR #4502: interfaces/builtin: add support for content "source" section (v2) [09:28] pstolowski: probably will do a round of similar changes there [09:29] PR snapd#4520 closed: daemon: unlock state even if RefreshSchedule() fails [09:30] mvo: https://github.com/snapcore/snapd/pull/4516 is green now but I'm not sure if we want to merge it yet [09:30] PR #4516: spread: setup machine creation on Linode [09:30] zyga-ubuntu, sure [09:31] PR snapd#4522 opened: daemon: avoid panic'ing building an error response w/no snaps given [09:31] zyga-ubuntu: ^ should address the issue [09:33] Chipaca: +1 [09:37] mvo: commented on 4517 [09:44] zyga-ubuntu: thanks, I am not hopefully for any of these approaches [09:44] mvo: what do you think will happen? [09:44] zyga-ubuntu: I have the feeling we need something more fundamental or more targeted, the problem is right now e.g. apt remove snapd fails because /snap is probably busy [09:45] mvo: yuck, that's indeed bad [09:45] mvo: so [09:45] zyga-ubuntu: so something more fundamental would be good except that we can't ship it in other distros :/ [09:45] mvo: maybe time to share one (very weird and crazy) idea [09:45] zyga-ubuntu: more targeted may mean to just run this bind,share if condition=virtual is meet [09:45] zyga-ubuntu: sure, share! [09:45] mvo: you can do this: [09:45] mvo: mkdir foo [09:46] mvo: in one terminal unshare, mount --bind foo foo [09:46] mvo: in another terminal, afterwards, rmdir foo [09:46] mvo: this works [09:46] mvo: now, this lets us make a namespace where a bind mount is present and where we can do whatever we want [09:46] mvo: here's a crazy idea [09:46] mvo: what if we did all the rsharing in a mount namespace snap-confine implicitly joins as soon as it starts [09:47] zyga-ubuntu: hm, if that works, +1 [09:47] mvo: that ns could be a slave of the real thing [09:47] mvo: and it could do all the magic needed that wouldn't leak outside [09:47] mvo: so apt and friends can remove things as they usually do [09:47] mvo: not sure, just thought about it, I can give it a try [09:48] zyga-ubuntu: please, I will poke around a bit more but I doubt the current mount unit approach is feasible [09:51] mvo: I wonder if this can be fixed in containers [09:51] mvo: maybe lxd can just do the right thing === chihchun_afk is now known as chihchun [09:57] Failed to issue method call: Unit snap.mount.service failed to load: No such file or directory. See system logs and 'systemctl status snap.mount.service' for details. [09:57] is it snap.mount or snap.mount.service? [09:57] looks like a simple error there mvo [09:59] PR snapd#4505 closed: interfaces/mount,snap: early support for snap layouts === chihchun is now known as chihchun_afk [10:07] zyga-ubuntu: indeed, let me fix, it should be snap.mount only [11:00] Chipaca: hey [11:00] your change broke one very unexpected place [11:00] + echo 'error: cannot install ["test-snapd-classic-confinement"]: classic confinement [11:00] requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap' [11:00] error: pattern not found, got: [11:00] see ["foo"] vs "foo" [11:00] error: cannot install ["test-snapd-classic-confinement"]: classic confinement requires snaps under /snap or symlink from /snap to /var/lib/snapd/snap [11:00] zyga-ubuntu: hah. Not _that_ unexpected [11:00] zyga-ubuntu: in fact i was wondering if that'd come up [11:00] zyga-ubuntu: I can fix :-) [11:00] thanks for the heads-up [11:01] mvo: snap.mount doesn't work :/ [11:01] Removing snapd (1337.2.30) ... [11:01] Job for snap.mount failed. See "systemctl status snap.mount" and "journalctl -xe" for details. [11:01] dpkg: error processing package snapd (--purge): [11:01] :-( [11:05] zyga-ubuntu: yeah, I was afraid this would happen [11:05] zyga-ubuntu: snap.mount cannot be stopped as the mount point is busy. but we cannot make it not-busy unless we purge [11:06] hmm hmm hmm [11:06] but why is it busy [11:06] it is busy because it is a mount point? [11:06] maybe what we need is a bind mount from /var/lib/snapd/snap to /snap [11:06] maybe it's a systemd bug [11:06] I would presume systemd would stop all the snap mount units inside first [11:06] then stop snap.mount [11:07] niemeyer: you mentioned yesterday that you want to learn more about the writable handling for etc and var, I wrote a summary of the status now and a proposal into https://forum.snapcraft.io/t/writing-to-etc-and-var-from-the-core-snap/3653 [11:08] zyga-ubuntu: I think it is because /snap/* is still available on remove, we only get rid of the actual snaps on purge [11:08] mvo: hmmm, [11:08] mvo: but if dpkg starts this, dpkg first should run prerm script [11:09] mvo: do we stop services and unmount snaps in prerm? [11:09] iff we do, it could just work [11:10] zyga-ubuntu: can you try to use snap-mgmt in prerm? [11:11] mborzecki: I think we should unify script management but it's hard due to way dpkg handles files [11:11] mborzecki: it'd be easier if our build system split snap-mgmt and injected it into actual dpkg management scripts [11:11] zyga-ubuntu: we could do that, yes. it would be different from what we are doing currently. i.e. we leave the snaps and only purge on purge [11:11] mborzecki: as those have differnet lifecycle from the other package files [11:12] mvo: actually... [11:12] mvo: we only have to unmount /snap on purge too [11:12] mvo: can we make dpkg ingore /snap? [11:12] mvo: if we don't ship it [11:12] mvo: just create it in a script:? [11:12] zyga-ubuntu: yeah, we would have to create it in postinst and manage it manually [11:13] zyga-ubuntu: ugly as **** but worth a try [11:15] zyga-ubuntu: tweaked #4522 a little, should address that failure you saw (and be a little nicer) [11:15] PR #4522: daemon: avoid panic'ing building an error response w/no snaps given [11:15] Chipaca: nice, looking [11:16] when it's just one snap, error message should now be identical to what it was before [11:16] ++ [11:16] yep [11:16] when it's something else, it'll be something else :-) but nicer [11:17] also less duplication, in exchange for some shenaniganry [11:19] (take *that*, branch predictor!) [11:33] hmmmmm [11:33] * Chipaca fixes the fix [11:58] PR snapd#4522 closed: daemon: avoid panic'ing building an error response w/no snaps given [12:05] is raspbian always armel? [12:07] kalikiana, hi, do you think https://github.com/snapcore/snapcraft/pull/1617 can be merged now? [12:07] PR snapcraft#1617: Add options to configure applications socket activation [12:13] cachio: observation: go test ./... is far far far faster than our run checks --unit [12:14] actually, can you guys please: time go test ./... [12:14] from the top of the tree [12:15] zyga-ubuntu, I'll try it [12:19] pstolowski: Attr() cannot be used to check if an attribute of _any_ type exists [12:19] passing interface{} won't cut it [12:19] ideas? [12:19] pstolowski: I'd like to add HasAttr() [12:20] zyga-ubuntu, I know. I've addressed this in #4510 [12:20] PR #4510: asserts: use Attrer in policy checks [12:20] ah, nice [12:20] hmm hmm [12:21] ok, I'll add a todo and wait [12:21] zyga-ubuntu, note, attributes can be nested. in 4510 I've also added support for dotted paths. HasAttr() will only make sense with dotted paths I guess [12:21] ackk: I'd suggest to check with kyrofa - I don't have merge powers :-D [12:22] zyga-ubuntu, 4510 needs Samuele's review.. not sure if you can wait till he is back? [12:22] PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack [12:23] pstolowski: I think this is fine, I added a TODO note to use Lookup [12:23] zyga-ubuntu: snap.ValidateContainer on master [12:23] Chipaca: I saw, thank you! [12:23] k [12:23] zyga-ubuntu, k [12:24] Chipaca: so with that, I will probably look at making it useful for validating layout [12:24] https://github.com/snapcore/snapd/pull/4329 needs a 2nd review [12:24] PR #4329: cmd/snap-confine: discard stale mount namespaces (v2) [12:33] PR snapd#4523 opened: interfaces/builtin: allow introspecting UDisks2 [12:38] mborzecki: about 4523 [12:38] mborzecki: does the new xml snippet mean anyone can introspect udisks? [12:39] I think the plug apparmor part must define something like that too [12:39] ah, it already does that [12:39] zyga-ubuntu: yeah, it was missing from the slot [12:40] zyga-ubuntu: once i got that, the dbus rule was disallowing calls to Introspectable :/ [12:40] dbus snakepit [12:54] hmm [12:54] Chipaca: so, for containers, did you come up with a practical way to mock them? [12:54] zyga-ubuntu: simplest way is to use a snapdir [12:55] zyga-ubuntu: look at the tests of validate container in snap/container_test.go [12:55] mmm [12:55] yeah, I just need to tweak my code to accept a container [12:55] and not attempt to derive one from snap info [12:55] that will be much nicer for testing [13:26] PR snapd#4515 closed: tests: new spread test for netlink-audit interface === ogasawara_ is now known as ogasawara === ogasawara is now known as Guest58359 [13:44] * zyga-ubuntu jumps for quick lunchj [13:51] * kalikiana going for lunch (and yay, a little bit of sun) [13:53] niemeyer: https://forum.snapcraft.io/t/snapshots-implementation-details/3656 [13:54] niemeyer: i think that touches on the bits that were making you nervous, or for which you were lacking context [13:55] getting it working so you can play with it is what i'm working towards, eta tomorrow [13:55] notably the switch to zip at the toplevel was painless :-) [13:56] Chipaca: Thanks! I'm actually kinda nervous that we didn't talk much about the overall design.. I'm worried of introducing late suggestions that would make you cringe [13:57] niemeyer: I know you'll persevere and do it anyways :-) [13:57] niemeyer: (i'm joking; bring on the suggestions) [13:57] Chipaca: I'll try to see that as a compliment :D [14:02] niemeyer: are those suggestions going to be on the forum? [14:03] Chipaca: We should definitely at least have a summary there, but depending on the topics to be covered a call might be nice.. I'll ping you this afternoon in either case [14:08] cachio: That unit test takes about 10 minutes alone [14:09] cachio: This is definitely making a significant impact on the overall test, because it's mixed in with all the other tests [14:10] Imagine what happens if systems are all happy churning, and then at the 20 minutes mark they start running unit tests, for example [14:11] That's probably one of the reasons why we fail to improve the overall test performance.. I'll have a look into this today [14:11] In any case, " Ran for 25 min 49 sec" [14:12] * pstolowski lunch [14:17] niemeyer, ok, I'm researching that as well [14:17] niemeyer, thanks for the heads-up [14:25] * cachio afk [14:40] * Chipaca afk for a bit [14:46] re [14:52] jdstrand: question on an x11 slot. The X socket is hardcoded to /tmp/.X11-unix/X*. If X server is snapped, that /tmp is actually a private subdir of /tmp/$SNAP. I'm struggling to see a nice way to share the socket path with another snap that plugs in. Would the config system be a sensible way? [14:53] so the plug would call "snap get x11 socket" and get a path to the socket back [14:54] greyback: this is something that will be done via interface hooks [14:54] greyback: please look at this PR, the tests do something quite like this [14:55] zyga-ubuntu: interesting, looking... [14:55] https://github.com/snapcore/snapd/pull/4358 [14:55] PR #4358: interfaces: interface hooks implementation [14:55] specifically... [14:56] https://github.com/snapcore/snapd/pull/4358/files#diff-1ee943f85f142e4019d5625a0045a88dR7 [14:56] jdstrand: https://github.com/snapcore/snapd/pull/4523 needs your 2nd review (very short) [14:56] PR #4523: interfaces/builtin: allow introspecting UDisks2 [14:57] PR snapd#4502 closed: interfaces/builtin: add support for content "source" section (v2) [14:59] greyback, sounds like a good use case for interface hooks indeed. basically, on 'snap connect..' hooks are executed on plug and slot sides, and they can exchange data before connection is finalized [15:01] jdstrand: this PR https://github.com/snapcore/snapd/pull/4521 is related to your work [15:01] PR #4521: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev [15:01] pstolowski: yeah it sounds like it. Does it look far from landing? [15:01] mvo: https://github.com/snapcore/snapd/pull/4512 is green and needs a 2nd review [15:01] PR #4512: tests: new spread test for ssh-public-keys interface [15:02] (we are getting close to having 3X reviews rather than 4X [15:03] zyga-ubuntu: re 4523, done. re 4521, ack (note that I put that on the backburner for the moment to get to other higher priority items) [15:04] greyback, my guess is probably a few weeks as there is some followup stuff that needs to land before we can enable the feature [15:04] pstolowski: ack, thanks [15:05] Hello! [15:06] jdstrand: ack [15:06] PR snapd#4523 closed: interfaces/builtin: allow introspecting UDisks2 [15:07] niemeyer: can we land https://github.com/snapcore/snapd/pull/4516 or do you need to do more tweaking on it? [15:07] PR #4516: spread: setup machine creation on Linode [15:07] (alternatively close it) [15:08] zyga-ubuntu: Still working on it [15:09] ack [15:11] cachio: https://github.com/snapcore/snapd/pull/4511 is failing for real [15:11] PR #4511: tests: new spread test for ssh-keys interface [15:16] ackk, indeed, it seems that feature is contained in 2.30, which has made it to stable, in my mind it can be merged [15:16] I've updated it to bring it inline with master, the tests are running once more [15:16] kyrofa, cool, thanks [15:28] ackk, see sergio's comment on the PR. Are you up for that? [15:28] zyga-ubuntu, yes [15:29] also the issue that was seen in fedora should be considered, it failed to read ssh config file [15:29] zyga-ubuntu, now as we are not executing ssh to coonect any more the error is not being reproduced [15:31] cachio: not sure about fedora, the only thing I recall was an error in daemon/api.go - [15:32] cachio: there's ssh_config in the core snap so it should be there [15:32] cachio: did you investigate why it failed? [15:32] zyga-ubuntu, running it now [15:32] thank you! [15:33] Hey guys! I need a little help from you. I'm snapcrafting my application into a snap and I'm getting some errors importing a package I called bridge. The error is: "package bridge: unrecognized import path "bridge" (import path does not begin with hostname)" [15:38] brunosfer: that error looks like app specific thing [15:38] PR snapcraft#1873 closed: elf: cleaner patchelf experience [15:39] zyga-ubuntu: I think the snapcraft is trying to compile the package. However that package is a dependency of the project. [15:39] zyga-ubuntu: Is there a way in the yaml file where I can specify that the specific package is a dependency and it should not be compiled? [15:40] kyrofa: ^ [15:40] Hmm [15:41] PR snapcraft#1865 closed: lxd: always (re-)injects snaps [15:41] brunosfer, I'm afraid I don't quite understand the issue. Any chance you can share your YAML? [15:43] kyrofa: How do you suggest to share? [15:43] brunosfer, pastebin.ubuntu.com works pretty well [15:44] Unless you already have it in e.g. github [15:44] kyrofa: I'm gonna use pastebin, I don't have the project on github. [15:44] brunosfer, sure thing [15:47] kyrofa: Please check https://pastebin.ubuntu.com/26444892/ [15:48] zyga-ubuntu, https://paste.ubuntu.com/26444896/ [15:49] brunosfer, the `bridge` part is being built because you specified it as a part. Is that the one that's failing? [15:50] zyga-ubuntu, so, the file does not exist as part of the /etc/ssh/ [15:51] kyrofa: yes it is [15:51] kyrofa: yes it is [15:51] kyrofa: how should I specify it? [15:52] brunosfer, you mention that it's a dependency. A dependency of what? [15:52] cachio: hmm [15:52] cachio: that's interesting [15:52] cachio: maybe some kind of writable path magic? not sure [15:53] kyrofa: The package `bridge` is imported by the main package. [15:54] brunosfer, you probably don't need to specify it as a part, then [15:54] zyga-ubuntu, yes, not sure why it is there [15:54] mvo, any idea? [15:54] brunosfer, just specify the main part [15:57] cachio: probably because of this [15:57] https://github.com/snapcore/core-build/blob/master/config/etc/system-image/writable-paths#L50 [15:58] zyga-ubuntu, ouch [16:00] zyga-ubuntu, ok, in that case I could either to check on the core snap or skip it for core [16:02] zyga-ubuntu, I dont understand why is not mounting just 3 files [16:02] cachio: sorry, I miss context - you don't see a file or what is going on? [16:03] the ssh-config file is on /snap/core/x1/etc/ssh/ssh_config [16:03] and we are checking the file in /etc/ssh [16:03]