[00:20] hm [00:20] i thought as a developer of a snap i could download it by revision? [00:23] ah https://forum.snapcraft.io/t/as-a-snap-owner-not-able-to-download-a-snap-by-revision/10062/2 === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [05:56] morning [06:08] new kernel 5.0.0-arch1-1-ARCH [06:37] a lot of ubuntu-16.04-32 prepare jobs failed [07:10] mvo: morning [07:16] hey mborzecki ! good morning [07:19] i'll be out for a while, left a note in the forum [07:21] mborzecki: thanks for letting me know [07:21] mborzecki: s/me/us/ :) [07:22] mvo: sure [07:22] mvo: i've restarted some travis jobs, seems like ubuntu-16.04-32 was reaching a kill timeout in prepare [07:23] but i'd guess it's repos being slow === chihchun_afk is now known as chihchun [08:01] PR snapd#6569 opened: tests: check that apt works before using it [08:03] heyas === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:20] PR snapd#6570 opened: snapstate: only keep 2 snaps on classic [08:29] mvo: hi, I created a card about that ^ [08:30] mvo: see bottom of upcoming [08:31] pedronis: thanks [08:39] pedronis: I added the PR to the card [08:40] mvo: I'm not seeing it [08:43] pedronis: hm, trello acted up, should be there now [08:44] mvo: yes, probably the if it's kept open for too long it needs a reload (sometimes) [08:44] yeah, I think that was what happend [08:44] (reload "fixed" it) === tobias is now known as Guest42681 [09:19] mvo: there's a lot red in tests [09:19] anything clear about why? [09:20] good morning [09:22] pedronis: yes, working on it - 6569 should fix it [09:22] hey zyga - good morning [09:23] ah [09:24] hey, sorry, long night, starting late to be awakee [09:25] mvo: I replied to https://github.com/snapcore/snapd/pull/6498 [09:25] PR #6498: cmd/libsnap: add cgroup-pids-support module [09:25] oh, tests are red today [09:26] zyga: thanks, I see - yeah, +1 then on the PR. thanks for explaining the difference [09:27] go.googlesource.net 502 :/ https://www.irccloud.com/pastebin/dHeNm5vD/ [09:27] mvo: we use the freezer to track snap-wide scope and pid to track security-tag scope [09:28] mvo: in v2 we can design a nicer hierachy where snapd/foo.snap/bar.app/ is used, for example [09:29] zyga: 6569 should make tests green again [09:29] fun :) [09:29] thank you [09:30] last night was hours and hours of homework [09:30] followed by some more hackng but I finished late after midnight [09:33] mvo: wow, thank you for https://github.com/snapcore/snapd/pull/6570 [09:33] PR #6570: snapstate: only keep 2 snaps on classic [09:33] my pleasure [09:33] zyga: i think we need to have a package that wraps calls to snap-seccomp [09:34] zyga: added some code to interrogate snap-seccomp when building the system-key and it's a bit awkward [09:34] mborzecki: can you tell me more about this idiea [09:34] *idea [09:34] mborzecki: I _may_ have something better soon [09:34] mborzecki: but for 2.39 at earliest [09:35] mborzecki: snap-seccomp won't need to exist as a binary anymore [09:35] zyga: ah, your custom bpf compiler? :) === tobias is now known as Guest33668 [09:35] mborzecki: just really a super simple assembler [09:35] mborzecki: all I need is the syscall tables now [09:36] mborzecki: the advantage is that we have less C code, no need for a standalone binary and one less depednency [09:36] mborzecki: given that we use snap-seccomp for a very simple task it is not hard to reproduce that [09:37] but anyway, let me know more about your current idea [09:37] zyga: ho? [09:37] mborzecki: sure, gimme a sec [09:38] mborzecki: I'm in standup [09:38] zyga: joining [09:38] mborzecki: hey, what was the outcome of the parallel install gnome discussion yesterday? [09:39] mvo: i did no see anything off int he mounts, also couldn't reproduce that locally [09:39] mvo: when ken discarded the mount ns and run the snap again, everything was ok [09:40] mvo: so either some sort of race, or soemthing nonobvious in mount ns setup [09:40] mborzecki: hm, ok - and also worrying we should try to get to the bottom of this, I have the feeling it will come back [09:47] zyga: I did a pass on #6502 [09:47] PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks [10:02] pedronis: thank you! I will iterate on it now [10:02] mvo: hey, we figured out why mborzecki's branch is failing [10:02] zyga: tell me more please [10:02] mvo: well, partially figured out: it is due to the service that bootstraps snapd from snap [10:02] mvo: we run the compiler before snapd.snap is installed [10:03] mvo: i had the a quick and dirrty install gedit_master && run && remove gedit_master gnome-... gtk-common-themes loop running for a while, but was not able to reproduce the problem [10:03] zyga: btw, any idea about why the namespace reset yesterday helped with the gnome issue yesterday? [10:03] mvo: so a quick question: how does the service operate? where is the snapd.snap mounted during the bootstrap process? [10:03] mvo: oh? I don't know anything about that [10:03] mvo: I recall some people discussing snap-discard-ns but not sure if that's the topic you refer to [10:04] zyga: https://irclogs.ubuntu.com/2019/03/05/%23snappy.html ~16:25 [10:04] zyga: when snapd is run it will bootstrap itself, i.e. it will read seed and perform the actions [10:04] zyga: so the bootstrap is literally just "mount snapd snap, run snapd and let it run" [10:04] zyga: once the snapd snap is installed by the snapd binary it will restart itself and all is well defined [10:04] mvo: right, but before seeding backends will initialize, snap-seccomp will be invoked from a path that doesn't (apparently, this is still a theory) does not exist yett [10:04] mvo: when snapd is run, snap-seccomp will be in the same directory as /proc/self/exe of snapd, right? [10:05] mborzecki: yes [10:05] mborzecki: we actually should run snap-seccomp always from that dir, no? [10:05] mvo: yes, just confirming things [10:05] cool [10:05] I see the conversation now: interesting, I would have to check some things [10:05] mvo: seccomp backend initialization calls to snap-seccomp, we have a feeling that this fails, so backend fails to initialize and things break down [10:06] perhaps interplay with mounting the instance name, the non-instatnce name and the content [10:06] mvo: ken said it was the oldest parallel installed snap he had [10:06] I have a test in spread that shows how something similar fails [10:06] zyga: something similar, as in mounts or snap-seccomp during bootstrap? [10:06] is it reproducible? [10:06] mborzecki: as in mounts [10:07] zyga: i was not able to reproduce it yesterday [10:07] https://github.com/snapcore/snapd/blob/master/tests/main/layout-symlink-bind-revert/task.yaml [10:07] this encodes some of the problem (but you have to read deeply about what goes on in an associated commit message) [10:07] 6569 is green and should make tests green again [10:07] (needs a second review) [10:08] https://github.com/snapcore/snapd/commit/adf75238b85540d19027dc2f1c576bd266641af2#diff-a6e200ddb24754df8611a002020deccd [10:08] mvo: anyway, I will investigate [10:08] thank you zyga [10:10] ogra@nanopc-t4:~$ uname -a [10:10] Linux nanopc-t4 4.19.20-dirty #1 SMP PREEMPT Tue Mar 5 16:58:29 CET 2019 aarch64 aarch64 aarch64 GNU/Linux [10:10] ogra@nanopc-t4:~$ cat /proc/cpuinfo |grep -c ^processor [10:10] 6 [10:10] ogra@nanopc-t4:~$ free -h | grep ^Mem [10:10] Mem: 3.8G 124M 3.4G 11M 280M 3.5G [10:10] :D [10:14] ogra: raspberry pi 4? :D [10:14] haha, no ... a rockchip 3399 board ... but it not only has 6 2GHz cores and 4G, it also has an M.2 SATA connector :D [10:15] just trying to get lxd armhf images up and running ... then i'll likely have a home-builder thats as fast as the LP buildds ;) [10:15] (minus the queue ;) ) [10:18] ogra: build libreoffice then :) [10:19] once i have everything up i will ... images are here in case someone else has such a board http://people.canonical.com/~ogra/snappy/nanopc-t4/ :) [10:21] mvo: so seems we have the problem that on a classic system with reexec getting a base: core18 snap doesn't get you an auto-updating snapd [10:21] because we don't get core (nor the snapd snap) [10:22] mvo: https://forum.snapcraft.io/t/core18-snap-fails-to-run-on-16-04-cannot-locate-the-core-snap/10292/10 [10:23] PR snapd#6569 closed: tests: check that apt works before using it [10:23] pedronis: yeah, still no 2.37.x in xenial :/ [10:23] pedronis: our SRU process is still slow [10:23] mvo: does 2.37 pull in core though? [10:24] it will fix that problem [10:24] but not the stale snapd [10:24] pedronis: right [10:25] pedronis: let me read the full thing, I thought this was about the bug that without core snaps won't run. but yeah, with only core18 we lose the re-exec right now [10:31] how am I supposed to pass stuff between an unconfined app's /tmp/ and a confined app, like vlc? https://trac.videolan.org/vlc/ticket/21558 is the ticket we got for VLC, where user wants to open an attachment from Thunderbird in a confined VLC. [10:31] thresh: this would only work through XDG portals, something that is not widely available yet [10:34] zyga: yay, no more import cycles, https://paste.ubuntu.com/p/X4vqjPsj85/ that's with the seccomp compiler wrapper under sandbox/seccomp [10:35] mborzecki: nice, I think this is what we need :) [10:35] zyga, ok, can you point me to the docs? [10:35] zyga: similar wrapper for apparmor under sandbox/apparmor would be trivial too :P [10:35] afaics, most of my users are on ubuntu 18.04 [10:36] thresh: there are no docs for this issue per-se, there's the movement to get document portal in place with snapd and with snaps but it is far from complete [10:36] zyga, ah, I see, thank you. [10:58] PR core#102 closed: hooks: add force_turbo to PI_CONFIG_KEYS [11:16] zyga: https://github.com/bboozzoo/snapd/commit/07f3aeab765514a1e8e5501fb4490ffca273a1e2 [11:16] mmm [11:17] tiny :) [11:18] i'm finishing fixing up the tests and will stat looking into the spread test of core18 [11:19] zyga: got your comment, will add that [11:19] mborzecki: +1 [11:19] mborzecki: I left one comment [11:19] thanks! [11:22] i'm heading home [11:24] mo'in all [11:25] back earlier than i feared, although I'll have to go out again this afternoon [11:25] meanwhile, there's a user out there wondering why 'sudo umount -a' causes their snaps to stop working [11:29] pstolowski: I added some more highlevel considerations to 6562 [11:30] Chipaca: hi, sorry for the slightly grumpy review of #6564 , the diff there is very hard to read [11:30] PR #6564: cmd/snap, tests: refactor info to unify handling of 'direct' snaps [11:30] pstolowski: let me know if you have questions, need to lunch now though [11:31] pedronis: yep, looking, thanks! [11:32] pedronis: yeah [11:50] mvo: any particular reason to push #6570 to 2.38 ? [11:50] PR #6570: snapstate: only keep 2 snaps on classic [11:53] pedronis: just to make foundations happy [11:53] pedronis: fine to remove the milestone [11:53] mvo: I don't think it's risky, but is not a bug fix either [11:54] mvo: I removed it [11:54] mvo: we have just one thing open for 2.38 [11:54] now [12:02] pedronis: why is 'load' wrong, and why is 'examine' better, for a function that does cmd.ClientSnapFromSnapInfo(snap.ReadInfoFromSnapFile(snap.Open(...))) ? [12:03] pedronis: having it in 2.38 makes sure it lands in time for 19.04 - but we can always pull it into 2.38.N if 2.39 does not make it in time [12:03] mvo: I understand [12:03] Chipaca: are we loading the snap? [12:03] do we use load for this anywhere? [12:04] Chipaca: the line you pasted has no verb load in it [12:04] it has a read [12:06] Chipaca: it would be good also to find something else than "direct" [12:07] Chipaca: examine had "?" after it, it was a proposal [12:10] to me "load" is pretty close to "open and read", but I recognise that this might be a 'me' thing [12:10] Chipaca: yes, I think you tried to sneak it in somewhere else, but we don't use it that way [12:10] Chipaca: to me load sounds like bring this entire thing into memory [12:12] Chipaca: I suppose the problem of that direct is shared by the other ones "local" and "remote", they are adjective used as names, I think of the bunch direct is the one that sounds the most like it would be a bool [12:13] but maybe that's me === ricab is now known as ricab|lunch [12:14] Chipaca: maybe we should turn them all into remoteSnap, localSnap and diskSnap ? don't lnow [12:59] Chipaca: I commented on this a bit more in the PR itself [13:41] Chipaca: wasn't this fixed already https://bugs.launchpad.net/snapd/+bug/1818306 ? [13:41] Bug #1818306: disabled daemons are started after refresh === ricab|lunch is now known as ricab [13:46] pedronis: yes [13:48] Chipaca: the report is recent [13:54] PR snapd#6570 closed: snapstate: only keep 2 snaps on classic [13:56] 6418 needs a second review [13:58] pedronis: we fixed it for refresh, not for install i guess? [13:58] pedronis: what's the right behaviour for install? [13:59] for install? [13:59] yes [14:00] degville: 3 is actually mentioned here https://forum.snapcraft.io/t/getting-started/3876 under "snap revert" docs [14:00] mvo: ^ [14:00] thanks pedronis! [14:01] pedronis: actually I see the same behaviour on refresh [14:01] need to dig a bit [14:01] Chipaca: ok [14:01] Chipaca: I think internally that install is a refresh [14:01] or not different to a refresh [14:01] it should be, yes [14:02] Chipaca: anyway don't dig too much if you are doing something else [14:02] Chipaca: we made a card [14:02] dunno if i'd complicate the services handling over it though [14:03] pedronis: also https://forum.snapcraft.io/t/disabled-snap-gets-enabled-after-a-refresh/7457 [14:03] Chipaca: standup or are you skipping? [14:03] going [14:08] pedronis: #5777 was never merged [14:08] PR #5777: wrappers/services.go: don't start disabled services [14:15] Chipaca: ah, so it's rally all tangled together as we discussed in Malta [14:15] *really [14:19] Hello! is there a Snap store besides Snapcraft's website? i thought Snap software can be distributed anywhere. [14:24] feelextra: what made you think that? [14:34] I watched this video that says: "snap stores are basically software repositories. of course canonical has their own snap store but anybody can have a snap store, and assuming your snap store is signed and secure you could technically pass it around in a PPA very similar to the way Ubuntu distros work today" source: https://www.youtube.com/watch?v=ixWuE1hhZfw [14:35] at around 1:00 into the video [14:36] feelextra: there is no currently available snap store implementation besides the official store which is proprietary. [14:37] you _can_ reimplement it but you also need to modify the snapd to be able to recognise the alternative store location [14:37] diddledan: thank you, that adds to my understanding of Snap! [14:38] at the moment snapd is hardcoded to only use the canonical-sponsored store [14:38] until there are alternative software to run your own store that's likely to remain as is [14:39] i see. [14:41] there was a store implementation out there, but it lagged [14:41] and pointing snapd at a different store is reasonably straightforward [14:41] but it's not a federated system, at all [14:41] you choose one store and stick to it [14:41] using our staging store, for example, requires everything from scratch, even core [14:42] (because the assertions are all different) === chihchun is now known as chihchun_afk === tobias is now known as Guest42027 [15:37] stepping out for a while === tobias is now known as Guest33922 === tobias is now known as Guest8608 [15:47] PR snapd#6566 closed: interface: avahi-observe: Fixing socket permissions on 4.15 kernels (2.38) === chihchun_afk is now known as chihchun [16:13] zyga: i've updated #6485 [16:13] PR #6485: interfaces/seccomp: regenerate changed profiles only [16:13] looking [16:13] zyga: our mocking setup feels super fragile [16:14] mborzecki: yes [16:14] especially across packages [16:17] zyga: btw. https://forum.snapcraft.io/t/plans-for-sharing-a-gl-lib/10298 [16:18] oh, fun [16:18] will you reply or shall I? [16:29] zyga: go ahead [16:30] zyga: oh, and core18 works now, but I haven't confirmed that we suspected was actually the problem [16:30] what [16:30] did you change anything relevant? [16:31] zyga: there were some changes in the code that finds where snap-seccomp is [16:31] zyga: the test is running now, i'll let it finish [16:32] damn, Failed for "golang.org/x/crypto/cast5" (failed to clone repo): exit status 128, rly? [16:33] heh [16:34] zyga: heh, it's only rebooting the node now, so maybe it still doesn't work === tobias is now known as Guest51748 [16:43] archive woes :/ https://www.irccloud.com/pastebin/amKlkAyM/ [16:43] Chipaca: let's add ubuntu to the list of distros without reliable archives [16:43] zyga: please undo your change to 6418 [16:43] it doesn't achieve the goal of the PR [16:44] oh? can you tell me more? [16:44] zyga: we want to pivot [16:44] that code won't [16:45] zyga: I also tried to answer your other comments in the PR [16:48] pedronis: I agree about the pivoting aspect [16:48] pedronis: shall I revert or force push? [16:48] zyga: what is more convenient [16:48] zyga: anyway one of the comment explain a refactoring that is useful either way [16:48] for the clarity of snap-confine [16:49] this change (in principle) should be simple either place [16:49] it isn't [16:51] about pivot, I'm again not sure what should happen, it's complex [16:51] zyga: it's not complex [16:51] or shouldn't be [16:52] the code doesn't need to pivot if boot base is core16-like and base snap is core16-like [16:52] for the maximum compatibility between core and core16 [16:52] we don't want that [16:52] core16 is accepting to move forward [16:52] as a base [16:52] I'm not sure of that, if you think about what happens in core today it may break working snaps [16:52] othewise those snaps will fail on core18 devices [16:53] in unexpected ways [16:53] and I don't think we will give people to option to stay on pure core? (or will we?) [16:53] zyga: we are introducing "base: core" as well, remember [16:53] core18 devices are new, those may not work _yet_, this may break stuff that does work now [16:53] zyga: ? [16:53] if a snap puts base: core16 [16:53] in itself [16:54] is getting places [16:54] (that doesn't even work right now, remember, there is no stable core16) [16:54] pedronis: if this changes pivot semantics (when we pivot vs when we not pivot); the deployed base of snaps on core devices (with core as boot base), however wrong or correct, function now. If we migrate those to core16+snapd over time their semantics will change [16:55] zyga: if you put base: core or no base [16:55] you'll get the previous semantics [16:55] core16 was about unbundling snapd from core, this seems to make an extra assumption developers must be ok with [16:56] it's not, we cannot really let people make core16 based snaps [16:56] that don't work on core16 devices [16:56] sorry on core18 devices [16:56] no base snaps [16:56] are a greyer area [16:56] because of the choices we made [16:56] I agree but they are a grey area that is yet unexplored [16:57] I see your point of view but I'm worried core16 will break people more than it will help [16:57] we could discard the non-pivoting mode entirely and see what happens [16:57] that is a different issue [16:57] perhaps the whole argument is moot, I think we don't really know [16:58] anyway I don't see how making base: core16 potentially let you build snaps that don't work on core18 [16:58] be progress [16:58] toward the goal or turning off pivoting completely [16:59] pedronis: I think nobody will ship something that doesn't work [16:59] pedronis: the difference is who pulls the trigger, is it us for the developers (core -> core16 + snapd) or themselves [16:59] pedronis: I pushed a revert to the branch now [16:59] we will still pivot if the snap has no base [16:59] even on core16+snapd [16:59] pedronis: I will look at making a refactor you suggested [16:59] (we'll need to code for that) [17:00] or might pivot [17:00] anyway that's part of the discussion how to get there [17:00] pedronis: snaps always have a base as far as snap-confine is concerned, it is just the string "core" when it is not explicitly defined [17:00] option for base: core16 early [17:00] means something else [17:00] zyga: I know [17:00] another aspect is that the branch feels like an optimization [17:00] and we don't know what the correct mode is (or is it just me?) [17:01] if this never lands we just pull in core16 in addition to core [17:01] and then use base core16 [17:01] when snaps use core16 as their explicit base we will always pivot [17:01] zyga: we need to decide, we need a correct implementation either way to let people play [17:01] (in the current code) [17:01] zyga: anyway my main take away for all of this, is this comment: https://github.com/snapcore/snapd/pull/6418#discussion_r263027927 [17:01] PR #6418: many: allow core as a fallback for core16 <⛔ Blocked> [17:01] we should do either way [17:02] because the current layering is not good(tm) [17:02] yeah [17:02] I agree [17:03] so that should be a separate prereq PR either way [17:04] zyga: mvo: you need to decide who would tackle that [17:04] I'm attempting that refactor now [17:12] don't know what the ettiguette is for this, but I posted a question https://forum.snapcraft.io/t/is-there-a-list-of-currently-enabled-ubuntu-core-boards-by-architecture-and-model-number/10263 [17:13] i read something in the forums that its the preferred approach to capture and discussions and answers. ty [17:14] carif: the best people to answer that were at some events last week [17:15] pedronis, ack, i can be patient. just wanted to learn the protocol, ty. [17:25] zyga: thanks for tackling this [17:30] pedronis, mvo: I pushed a small branch that begins the refactoring while remaining readable https://github.com/snapcore/snapd/pull/6571 [17:30] PR #6571: cmd/snap-confine: introduce sc_invocation [17:30] PR snapd#6571 opened: cmd/snap-confine: introduce sc_invocation [17:41] zyga: the user/groups ids vs the rest seems a bit different concerns (I see 3 calls to getresuid atm) [17:41] PR snapd#6572 opened: cmd/snap-confine: populate enter_non_classic_execution_environment [17:42] PR pc-i386-gadget#8 opened: Adding empty configure hook to enable configuration for gadget [17:42] PR pc-i386-gadget#9 opened: Adding empty configure hook to enable configuration for gadget [17:42] PR pc-amd64-gadget#12 opened: Adding empty configure hook to enable configuration for gadget [17:42] PR pc-amd64-gadget#13 opened: Adding empty configure hook to enable configuration for gadget [17:42] pedronis: I wanted to keep the property of a refactor, I'm neither addnig nor removing more calls [17:43] pedronis: but I see your point, perhaps we should evacuate them from the struct [17:43] pedronis: and pass them around separately? [17:44] zyga: yes, I just a fear getting that struct to the few other places that care will need huge changes [17:44] seems a separate concern [17:44] I mean care about those [17:45]