[03:33] PR snapcraft#1948 closed: tests: move test files out of the snapcraft dir [06:05] morning [07:25] mvo: morning [07:28] mvo: someone on arch tried to use `snap run --gdb` to debug a segfault with nvidia, they had some problems though so i'm trying to find out more [07:30] mborzecki: aha, interessting. yeah, this is super new. keen to learn more about the exact issues [07:37] zyga: hey, feeling better? [07:37] mborzecki hey [07:37] yeah I feel better [07:37] I think the worst is over now, I'll try to help as much as I can now [07:39] zyga: take it easy ;) no use if end up getting worse [07:40] thanks, I'm wrapped in blanket and dressed like an onion [07:42] zyga: hey, welcome back. yeah, be careful and take it easy. I wonder how long I will last, my kids are sick too [07:42] is it flu as well? [07:43] I had fever for a few days but now it's (almost) good, I hope your kids are better quickly [07:45] zyga: yeah, fever and all that [07:50] good morning [07:51] zyga: are you using tor as well? ;-) [07:52] kalikiana, no I don't use tor [07:52] Just thinking you are dressed accordingly at least [07:52] aahh [07:52] :D [07:52] sorry, I'm slow on jokes today [07:53] yeah, I wish there was a flu firewall ;) [07:55] Avoid touching your face with your own hands ever unless you cleaned your hands [07:55] can I git push? :) [07:56] You can you the keyboard, it's the dirtiest thing around you anyways [07:56] *touch [07:56] I clean my keyboard regularly but yeah [08:12] snap download going extremely slowly for me for some reason :/ [08:13] 35 kB/s [08:20] morning! [08:26] hey pawel [08:26] mwhudson are you being redirected to some CDN on the other side of the planet? [08:26] zyga: how would i tell? [08:26] it was fast yesterday i think... [08:26] mwhudson mmm, good question [08:26] I don't know [08:26] pstolowski: hey [08:26] but that might have been office vs home [08:26] mwhudson btw, kudos on the installer work, it's stellar! [08:30] zyga: thanks, it's ok :) [08:35] zyga, hey, can you revoke your approval of #4358 (I don't seem to be able to)? there were many additions that it mandates 2 reviews again I'm afraid [08:35] PR #4358: interfaces: interface hooks implementation [08:35] sure [08:36] thankx [09:03] travis jobs timing out again? [09:09] *yawn* [09:14] hey John [09:21] Chipaca: hi [09:22] zyga: pedronis: hiya [09:22] zyga: are you back amongst the living? [09:22] hey pedronis :-) [09:22] Chipaca yeah, more or less [09:28] * Son_Goku rises from the dead [09:54] guys, should we have a content snap with debugging symbols for the core? [09:54] PR snapd#4715 opened: store: reorg auth refresh [09:54] Chipaca: this ^ might be something for you to review [09:55] mborzecki very interesting and big problem to solve correctly (ideally with gdb support for snap run --gdb) [09:55] an example, a user found a segfault that happens with nvidia drivers and snaps that require acceleration, he tried to use snap run --gdb, got this https://hastebin.com/sutuguquxu backtrace points to libc (probably something corrupt) but it's hard to discern what has really happened [09:57] hrm, a pastebin that requires javascript to display text *grumpf* [10:09] mvo: I +1ed #4103, but there were quite a few changes since Gustavo's +1, I think it needs a 2nd review again, not sure if by Gustavo or somebody else, maybe pawel [10:09] PR #4103: snapstate: auto install default-providers for content snaps [10:17] Chipaca: mvo: what do you think of a PR that does s/remoteRepoTestSuite/storeTestSuite/ s/UbuntuStoreRepository// in store/store_test.go [10:17] pedronis: +33 [10:18] Chipaca: ok, once a couple of other PRs touching store have landed I can do that, seems a clean up that is quite overdue [10:24] pedronis, mvo curious about your opinion on https://forum.snapcraft.io/t/snap-set-xxx-requires-configure-hook/4134 [10:25] pstolowski: my impression is that is something we could revisit when we have configuration schemas [10:26] pedronis, right, good idea. that will ensure people don't add more config garbage [10:27] once we have schemas to say what is the config/who can read it, then it might make sense to make configure optional [10:28] +1 [10:28] hmm: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/main/binary-amd64/Packages Hash Sum mismatch [10:32] mvo: there's a failure of tests/main/snap-service-refresh-mode on suse here: https://travis-ci.org/snapcore/snapd/builds/344719396?utm_source=github_status&utm_medium=notification [10:32] plus the Hash Sum mismatch stuff [10:36] zyga, mvo: new errors from gcc [10:36] libsnap-confine-private/locking-test.c: In function 'sc_test_use_fake_lock_dir': [10:36] libsnap-confine-private/locking-test.c:53:24: error: cast between incompatible function types from 'int (*)(const char *)' to 'void (*)(void *)' [-Werror=cast-function-type] [10:36] g_test_queue_destroy((GDestroyNotify) unsetenv, [10:36] ^ [10:36] cc1: all warnings being treated as errors [10:36] make[1]: *** [Makefile:1571: libsnap-confine-private/libsnap_confine_private_unit_tests-locking-test.o] Error 1 [10:36] Son_Goku oho, thanks I will fix that shortly [10:38] PR snapd#4716 opened: tests: make sure snapd is running before attempting to remove leftover snaps [10:56] PR snapd#4717 opened: cmd/snap-update-ns,testutil: move syscall testing helpers [10:57] PR snapd#4718 opened: tests: disable interfaces-location-control on s390x [10:58] mvo ^ this is the first chunk of the move, it turned out to be pretty harmless actually, the diff is mostly caused by me writing tests for the testing helperrs [10:59] * zyga -> break for lunch and meds [11:04] PR core#81 opened: 14-set-motd.chroot: updated based on the suggestions from Mark [11:19] * pstolowski lunch [11:23] * pstolowski lunch === wiking_ is now known as wiking === stokachu_ is now known as stokachu [11:34] Heya [11:35] chipaca, mvo: Around? [11:35] niemeyer: o/ [11:35] Hey [11:36] hey niemeyer [11:36] Chipaca: did you catch up with mvo about command not found? [11:37] niemeyer: a little last night; last i heard there was more discussion to be had [11:37] We said we'd have a call yesterday and I missed it.. Want to make sure you are in sync about the discussion in the meeting yesterday before spending time in a diff direction [11:37] niemeyer: i am not spending time on it, pending those discussions [11:38] Mark suggested a simpler approach, which looks fine to me [11:38] Has less data [11:38] We didn't agree on an output for the fuZy case but it should be easy to extrapolate [11:39] He also recommended c-nf to be its own tool for the output to not go out of sync between the different backends [11:40] Which is also fine since he understands we won't be able to change the output so easily [11:41] PR snapd#4719 opened: timeutil: account for 24h wrap when flattening clock spans [11:41] I would like to preserve the idea of us using a command on our end, though, instead of having c-n-f coonsulting a file by itself.. The command can put json out [11:42] The rationale for that is being able to evolve the implementation without having to keep historical data around that arbitrary tools depend on [11:42] Chipaca: Those are the main points, I think [11:43] Or at least the main points that seem worth typing on a phone :) [11:48] niemeyer: ack. Not much for me in that; will await further news. === cjwatson_ is now known as cjwatson [12:04] PR snapd#4720 opened: interfaces: add xdg-desktop-portal support to desktop interface [12:17] mvo: need to go to the school for a meeting, probably won't make it back for the standup [12:26] mborzecki can you please have a look at https://github.com/snapcore/snapd/pull/4717 [12:26] PR #4717: cmd/snap-update-ns,testutil: move syscall testing helpers [12:26] mvo, is there anything wrong with the PPA seems all nightly core snap builds failed with PPA errors ... https://launchpadlibrarian.net/357979314/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz [12:26] most of the diff is just new unit tests [12:26] zyga: ok [12:26] but have a look at the API in general, I'd like to turn it from "locally crafted helper" to "semi reusable helper" [12:26] hey ogra_ [12:26] * zyga looks [12:27] hmm, ut different PPA issues in the different arches [12:27] launchpad was offline for some maintenance lately, maybe that is related [12:27] thats weird [12:27] ah [12:27] yeah, that might be it [12:27] though not really sure [12:27] does it happen now or is that log from last night [12:28] thats from 5:20 this morning [12:29] but arm64 has an internal server error for the PPA https://launchpadlibrarian.net/357979358/buildlog_snap_ubuntu_xenial_arm64_core_BUILDING.txt.gz [12:29] so i guess it was that maintenance window [12:29] yeah, could be [12:36] There were some reboots which weren't completely perfectly coordinated. Just retry those. [12:39] mborzecki: wasn't the issue here addressed: https://travis-ci.org/snapcore/snapd/builds/344749295?utm_source=github_status&utm_medium=notification [12:40] I merged master in that branch [12:41] pedronis: looking [12:43] mvo, "mainframe does not change location that often", love that :D [12:44] mborzecki: ah, the test seems to need to be fixed too [12:44] pedronis: hah right [12:45] pedronis: are you fixing this or should i? [12:45] I can fix it I suppose [12:53] mborzecki: I find the original code a bit strange to be honest [12:53] pedronis: you mean globbing & stuff? [12:53] I mean all this replacing [12:54] but not your fault [12:54] seems just odd [13:02] ogra_: thanks, I have not seen this error yet, hope its transient? [13:17] re [13:36] mvo, i fired off a new auto-build, then we will know soon [13:36] hi, is something special required in the snap to make xdg-open work? I have the snapd-xdg-open package installed (this is artful) [13:37] has the snap store died a death? [13:37] ackk it depends on what you want to open [13:37] zyga, web url [13:37] ackk then it should just work [13:37] what happens when you try? [13:38] zyga, https://pastebin.canonical.com/p/WhvMqTgCDx/ [13:38] zyga, note that is a --devmode snap installed via snap try [13:38] (if it makes a difference) [13:38] ah [13:38] don't ship xdg-open [13:39] ah you mean it's trying to use the wrong one? [13:39] kalikiana ^ snapcraft should not bundle xdg-open deb as it will just break things [13:39] yes, it's using the regular one and that's shadowing the magic one [13:39] magicaltrout what are you seeing? [13:39] api.snapcraft.io is 503ing [13:40] can't install anything [13:41] mvo: the 2.31-maybe PR I mentioned: https://github.com/snapcore/snapd/pull/4594 [13:41] PR #4594: systemd, wrappers: start all snap services in one systemctl call [13:42] magicaltrout: confirmed [13:42] lovely [13:42] I pinged staff [13:42] thanks [13:43] https://status.snapcraft.io is useful [13:43] ah [13:43] cool [13:43] 99.57% [13:43] how rubbish! ;) [13:45] zyga, fwiw we don't pull it in explicitly, it's pulled as a dep [13:50] jdstrand: hey, quick question - do we want settimeofday in time_control.go (in the time-control inteface). I think we do and we did in 2.31 but for some reason its not there in master afaict. I noticed when doing the merge of 2.31 back into master (c.f. https://github.com/snapcore/snapd/pull/4712/files#diff-398a6a1ea514e53bd322812b60f02924R111 ) [13:50] PR #4712: release: version 2.31.1 [13:51] zyga, i guess we can strip it manually from the snap [13:51] ackk yes, please try to remove it, I think you can do that with one of the organize features of snapcraft [13:51] kalikiana may be able to help, I don't remember the syntax for them [13:51] zyga, yeah, thanks for the info [13:52] error: unable to contact snap store [13:53] zyga, does the base snap provide xdg-open? [13:53] yes [13:53] I wonder if base-18 has it [13:53] ackk it is a part of snapd now [13:54] but ... hmm [13:54] mvo ^ perhaps omission [13:54] zyga, it's not there in base-18 fwiw [13:54] yeah, base-18 does not have it just yet [13:54] mvo: it was in https://github.com/snapcore/snapd/pull/4687 [13:54] PR #4687: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al [13:54] mvo: which says it was merged... [13:54] * jdstrand scratches head [13:54] jdstrand: yeah, I'm puzzled [13:55] mvo: but looking at https://github.com/snapcore/snapd/pull/4687/files, it isn't in there [13:55] PR #4687: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al [13:56] but there it is: https://github.com/snapcore/snapd/pull/4687/commits/c1093d46437a33d60d7378b1c6676818655bc359 [13:58] Hello, is the snapcraft downtime planned? [13:58] b4nt no, https://status.snapcraft.io [13:58] it should be back [13:58] * jdstrand verifies the others [13:59] ok, weird... [13:59] jdstrand: yeah, its there and the log says it is mereged but https://github.com/snapcore/snapd/blob/master/interfaces/builtin/time_control.go#L109 in master does not have it and I'm puzzled why [13:59] mvo: this reverted it: https://github.com/snapcore/snapd/pull/4687/commits/cc5dcd8cd8879f81d9077b8300b36dd1db2224eb [13:59] PR #4687: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al [13:59] b4nt it's down but not on purpose [13:59] jdstrand: ohhhh [13:59] jdstrand: accidently? [14:00] jdstrand: if it got reverted by mistake I will just pull it back in via the 2.31 merge [14:00] mvo: I know there was a conflict in that file. I may have done a rebase somewhere and reorganized and messed it up [14:00] mvo: definitely a mistake [14:00] jdstrand: no worries! [14:00] jdstrand: thank you for helping solve this mystery :) [14:00] heh [14:01] jdstrand: its back now! [14:01] mvo: sorry :) and thank you for pulling that in and noticing it in the first place! :) [14:01] is api.snapcraft.io down? [14:01] I'm getting 403 [14:01] PR snapd#4712 closed: release: version 2.31.1 [14:01] jdstrand: np! [14:02] aah, I'm behind - I see yes it is [14:02] PR snapd#4718 closed: tests: disable interfaces-location-control on s390x [14:03] bonus points for zyga sharing the status.snapcraft.io page which I didn't know existed [14:07] ackk: zyga: what do you need to know for organize? to exclude a binary? [14:07] kalikiana yes, get rid of xdg-open [14:07] and it should _probably_ be excluded by default [14:08] what's pulling it in? desktop helpers? [14:08] kalikiana unclear, ackk can share his snapcraft yaml [14:09] I'd recommend `snapcraft help plugins` to learn about he syntax in general. There's a section about "organize" as well as the other generic keywords [14:09] Okay, looking at the YAML would be best to see what's needed here [14:10] off to pick up the kids [14:11] kalikiana, amtterm is pulling it in as a dependency [14:12] kalikiana, zyga: https://git.launchpad.net/maas/tree/snap/snapcraft.yaml [14:15] ackk: Ah. By the looks of it, you can probably just add -usr/bin/xdg-open to the existing "remove" fileset. Note the leading - in addition to the - for each item in the list. That's how you exclude. [14:15] kalikiana, ah yeah, thanks [14:16] kalikiana, I'll try that === leftyfb_ is now known as leftyfb [14:21] PR snapd#4717 closed: cmd/snap-update-ns,testutil: move syscall testing helpers [14:29] mvo, looks like the builds succeeded, so it was transient indeed [14:30] sergiusens: hi! not sure you saw, but https://github.com/snapcore/snapcraft/pull/1945#pullrequestreview-98350157 [14:30] PR snapcraft#1945: elf: clear execstack by default [14:31] ogra_: puh, thanks [14:31] zyga: hi! would you mind briefly looking at https://github.com/snapcore/snapd/pull/4714, and responding to my questions? that way I can finish the PR for a proper review [14:31] PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd [14:31] gladly, looking [14:31] zyga: thanks! [14:32] I'm doing some cleanups in that area actually [14:32] this should address point 10 [14:32] 1) [14:32] zyga: fs_detect.go could be detect.go? [14:33] zyga: ah, ok [14:34] jdstrand I'll probably merge overlay, nfs into mount.go later [14:36] thanks jdstrand [14:40] jdstrand reviewed [14:40] zyga: fyi, willcooke asked about the per-user mounts feature yesterday (I heard you were out. hope you're feeling better). I tried to summarize it as best I could that you are actively looking at it with priority [14:41] PR snapd#4721 opened: tests: update interface tests to remove extra checks and normalize tests [14:42] zyga: thanks! [14:53] jdstrand does this look sane, as a list of mount constraints for user mounts: https://pastebin.ubuntu.com/p/V6zXf9wWkd/ [15:06] Chipaca: the snap pack validation saved my bacon a couple of times today when creating test snaps, nice job [15:07] zyga: looking [15:07] jdstrand thanks [15:13] zyga: I'd love for point '3' to be enforceable because then this could be bulletproof. unfortunately '3' can't be a constraint for portals to work (see https://github.com/snapcore/snapd/pull/3963#discussion_r164623540) [15:13] PR #3963: cmd/snap-confine: add support for per-user mounts [15:14] aha, in that case 3 has to fly off the list [15:14] zyga: yeah. otherwise +1 [15:14] jdstrand btw, I was thinking about traversing the filesystem (descending from /) and then doing mount ., this would halve the attack surface [15:14] for bind mounts that is [15:15] for normal mounts it would make it race-free [15:15] (whee) [15:15] (well, assuming /dev doesn't race0 [15:17] zyga: that's an interesting idea [15:17] we could also do one more crazy thing [15:17] for bind mounts [15:17] but that's not for today [15:18] mvo, is there a place to file bugs about things that are missing in base-18, or is it too early? [15:19] jdstrand do you think it is worth it? [15:19] zyga: if you do ConservativeMount, then I think that should be sufficient for portals for now since the setuid process (which dropped, but retains enough privilege to mount) will fail if mismounted [15:19] we have to get that detection right though [15:19] (mismount detection) [15:19] right [15:19] I think that's quite easy but maybe I miss something [15:19] we can consider hardening after [15:20] because of rule 4) we can simply look for the mount point in mountinfo _after_ [15:20] so before we mount we ensure that mountinfo doens't contain the mount point [15:20] and after mount we ensure that it does [15:20] this means that we managed to mount exactly where we intended [15:20] zyga: james h had trouble with it, but he didn't write all the mount code you did. it seemed like something that would be easy for you :) [15:21] I wrote some test code for that [15:22] PR snapd#4599 closed: many: send new Snap-CDN header with none or with cloud instance placement info as needed [15:22] zyga: hmm. actually I was thinking of '4' as 'a snapd managed mountpoint', not an 'absolute mountpoint' [15:23] zyga: because XDG_RUNTIME_DIR (/run/user/uid) *is* a mountpoint [15:23] aha [15:23] so that's good feedback, I didn't realise that [15:23] zyga: *perhaps* for just portals it is ok because XDG_RUNTIME_DIR will *not* be a mountpoint [15:23] I will have to adjust the verification logic accordingly [15:24] mmm, one sec [15:24] zyga: but we will want to mount on XDG_RUNTIME_DIR to cleanup the wayland compat symlinks in XDG_RUNTIME_DIR/snap.foo/wayland -> ../wayland [15:25] (ie, get rid of wrappers) [15:25] jdstrand so for portals we'll have the equivalent of: mount --bind $XDG_RUNTIME_DIR/doc/by-app/snap.pkg.$SNAP_NAME $XDG_RUNTIME_DIR/doc [15:25] jdstrand and what's the value of $XDG_RUNTIME_DIR we want? [15:25] jdstrand /run/user/1234 or something else/ [15:26] zyga: re equivalent> that is my understanding [15:26] zyga: with XDG_RUNTIME_DIR, it will be /run/user/, which is a mountpoint, but /run/user//doc will not be [15:26] zyga: so '4' [15:26] pedronis: thanks again for the review. I added a unit and spread test for circular content providers and I think this is good for a review by e.g. pstolowski [15:26] meh [15:26] zyga: so '4' should be ok for portals [15:27] mvo, sure [15:27] zyga: but it won't be for the XDG_RUNTIME_DIR cleanup (if you recall, XDG_RUNTIME_DIR as /run/user/uid/snap.foo has been problematic for some snaps) [15:28] zyga: and to be even more clear, XDG_RUNTIME_DIR in this context is what the host sees as XDG_RUNTIME_DIR, not what the snap sees. portals won't bind mount into /run/user/uid/snap.foo/doc [15:28] aiui [15:29] we might need jamesh for that bit if we want to keep '4' as a constraint [15:30] I think I can answer definitively though. while we could distro patch portals to do what we want, we can't distro patch all the distros, so it needs to operate the way it does, which is /run/user/uid/doc [15:30] jamesh: can you comment ^ [15:32] jdstrand thanks for explaining this, I'm still a bit slow on the logic (I'm still a little sick) [15:32] zyga: regardless. we do know that we want to eventually have a per snap mount of: mount --bind /run/user/uid/snap.foo -> /run/user/uid, with bind-file mounts for the wayland and pulse sockets [15:32] the per snap mount is okay as that can be done with non-conservative mount [15:33] zyga: I think the question is, do we plan for this now or do we do the 'whatever makes portals work today' [15:33] I think we make portals work while considering what will be needed eventually [15:33] where 'this' is the bind mount for /run/user/uid [15:34] pstolowski: thank you! [15:34] zyga: if that is the constraint, then '4' can remain, but we need to comment that we'll need to lift this restriction at some point [15:37] ok [15:37] I'll get to work [15:41] PR snapd#4722 opened: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references === lool- is now known as lool [15:58] mvo: Chipaca: #4722 is the cleanup I was talking about, prereq has not landed though, anyway probably easist to look at each commit by itself [15:58] PR #4722: store: cleanup test naming, dropping remoteRepo and UbuntuStore(Repository)? references [16:46] mvo, reviewed, great stuff! some nitpicks/suggestions + one question [16:47] PR snapd#4723 opened: Translate polkit strings [16:53] #4716 needs 2nd review (and is trivial) [16:53] PR #4716: tests: make sure snapd is running before attempting to remove leftover snaps [16:55] pstolowski: I myself forgot about Attrer, thanks for the review [16:55] I mean for mvo's PR [16:58] pedronis, np [17:01] pstolowski: thanks, I have a look and will fixup things [17:03] yw [17:17] * kalikiana wrapping up for today [17:38] PR snapd#4724 opened: osutil: aggregate mockable symbols