| mwhudson | hm | 00:20 |
|---|---|---|
| mwhudson | i thought as a developer of a snap i could download it by revision? | 00:20 |
| mwhudson | ah https://forum.snapcraft.io/t/as-a-snap-owner-not-able-to-download-a-snap-by-revision/10062/2 | 00:23 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mborzecki | morning | 05:56 |
| mborzecki | new kernel 5.0.0-arch1-1-ARCH | 06:08 |
| mborzecki | a lot of ubuntu-16.04-32 prepare jobs failed | 06:37 |
| mborzecki | mvo: morning | 07:10 |
| mvo | hey mborzecki ! good morning | 07:16 |
| mborzecki | i'll be out for a while, left a note in the forum | 07:19 |
| mvo | mborzecki: thanks for letting me know | 07:21 |
| mvo | mborzecki: s/me/us/ :) | 07:21 |
| mborzecki | mvo: sure | 07:22 |
| mborzecki | mvo: i've restarted some travis jobs, seems like ubuntu-16.04-32 was reaching a kill timeout in prepare | 07:22 |
| mborzecki | but i'd guess it's repos being slow | 07:23 |
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#6569 opened: tests: check that apt works before using it <Created by mvo5> <https://github.com/snapcore/snapd/pull/6569> | 08:01 |
| pstolowski | heyas | 08:03 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#6570 opened: snapstate: only keep 2 snaps on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6570> | 08:20 |
| pedronis | mvo: hi, I created a card about that ^ | 08:29 |
| pedronis | mvo: see bottom of upcoming | 08:30 |
| mvo | pedronis: thanks | 08:31 |
| mvo | pedronis: I added the PR to the card | 08:39 |
| pedronis | mvo: I'm not seeing it | 08:40 |
| mvo | pedronis: hm, trello acted up, should be there now | 08:43 |
| pedronis | mvo: yes, probably the if it's kept open for too long it needs a reload (sometimes) | 08:44 |
| mvo | yeah, I think that was what happend | 08:44 |
| mvo | (reload "fixed" it) | 08:44 |
| === tobias is now known as Guest42681 | ||
| pedronis | mvo: there's a lot red in tests | 09:19 |
| pedronis | anything clear about why? | 09:19 |
| zyga | good morning | 09:20 |
| mvo | pedronis: yes, working on it - 6569 should fix it | 09:22 |
| mvo | hey zyga - good morning | 09:22 |
| pedronis | ah | 09:23 |
| zyga | hey, sorry, long night, starting late to be awakee | 09:24 |
| zyga | mvo: I replied to https://github.com/snapcore/snapd/pull/6498 | 09:25 |
| mup | PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498> | 09:25 |
| zyga | oh, tests are red today | 09:25 |
| mvo | zyga: thanks, I see - yeah, +1 then on the PR. thanks for explaining the difference | 09:26 |
| zyga | go.googlesource.net 502 :/ https://www.irccloud.com/pastebin/dHeNm5vD/ | 09:27 |
| zyga | mvo: we use the freezer to track snap-wide scope and pid to track security-tag scope | 09:27 |
| zyga | mvo: in v2 we can design a nicer hierachy where snapd/foo.snap/bar.app/ is used, for example | 09:28 |
| mvo | zyga: 6569 should make tests green again | 09:29 |
| zyga | fun :) | 09:29 |
| zyga | thank you | 09:29 |
| zyga | last night was hours and hours of homework | 09:30 |
| zyga | followed by some more hackng but I finished late after midnight | 09:30 |
| zyga | mvo: wow, thank you for https://github.com/snapcore/snapd/pull/6570 | 09:33 |
| mup | PR #6570: snapstate: only keep 2 snaps on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6570> | 09:33 |
| mvo | my pleasure | 09:33 |
| mborzecki | zyga: i think we need to have a package that wraps calls to snap-seccomp | 09:33 |
| mborzecki | zyga: added some code to interrogate snap-seccomp when building the system-key and it's a bit awkward | 09:34 |
| zyga | mborzecki: can you tell me more about this idiea | 09:34 |
| zyga | *idea | 09:34 |
| zyga | mborzecki: I _may_ have something better soon | 09:34 |
| zyga | mborzecki: but for 2.39 at earliest | 09:34 |
| zyga | mborzecki: snap-seccomp won't need to exist as a binary anymore | 09:35 |
| mborzecki | zyga: ah, your custom bpf compiler? :) | 09:35 |
| === tobias is now known as Guest33668 | ||
| zyga | mborzecki: just really a super simple assembler | 09:35 |
| zyga | mborzecki: all I need is the syscall tables now | 09:35 |
| zyga | mborzecki: the advantage is that we have less C code, no need for a standalone binary and one less depednency | 09:36 |
| zyga | mborzecki: given that we use snap-seccomp for a very simple task it is not hard to reproduce that | 09:36 |
| zyga | but anyway, let me know more about your current idea | 09:37 |
| mborzecki | zyga: ho? | 09:37 |
| zyga | mborzecki: sure, gimme a sec | 09:37 |
| zyga | mborzecki: I'm in standup | 09:38 |
| mborzecki | zyga: joining | 09:38 |
| mvo | mborzecki: hey, what was the outcome of the parallel install gnome discussion yesterday? | 09:38 |
| mborzecki | mvo: i did no see anything off int he mounts, also couldn't reproduce that locally | 09:39 |
| mborzecki | mvo: when ken discarded the mount ns and run the snap again, everything was ok | 09:39 |
| mborzecki | mvo: so either some sort of race, or soemthing nonobvious in mount ns setup | 09:40 |
| mvo | 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:40 |
| pedronis | zyga: I did a pass on #6502 | 09:47 |
| mup | PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502> | 09:47 |
| zyga | pedronis: thank you! I will iterate on it now | 10:02 |
| zyga | mvo: hey, we figured out why mborzecki's branch is failing | 10:02 |
| mvo | zyga: tell me more please | 10:02 |
| zyga | mvo: well, partially figured out: it is due to the service that bootstraps snapd from snap | 10:02 |
| zyga | mvo: we run the compiler before snapd.snap is installed | 10:02 |
| mborzecki | 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 |
| mvo | zyga: btw, any idea about why the namespace reset yesterday helped with the gnome issue yesterday? | 10:03 |
| zyga | mvo: so a quick question: how does the service operate? where is the snapd.snap mounted during the bootstrap process? | 10:03 |
| zyga | mvo: oh? I don't know anything about that | 10:03 |
| zyga | mvo: I recall some people discussing snap-discard-ns but not sure if that's the topic you refer to | 10:03 |
| mborzecki | zyga: https://irclogs.ubuntu.com/2019/03/05/%23snappy.html ~16:25 | 10:04 |
| mvo | zyga: when snapd is run it will bootstrap itself, i.e. it will read seed and perform the actions | 10:04 |
| mvo | zyga: so the bootstrap is literally just "mount snapd snap, run snapd and let it run" | 10:04 |
| mvo | zyga: once the snapd snap is installed by the snapd binary it will restart itself and all is well defined | 10:04 |
| zyga | 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 |
| mborzecki | mvo: when snapd is run, snap-seccomp will be in the same directory as /proc/self/exe of snapd, right? | 10:04 |
| mvo | mborzecki: yes | 10:05 |
| mvo | mborzecki: we actually should run snap-seccomp always from that dir, no? | 10:05 |
| mborzecki | mvo: yes, just confirming things | 10:05 |
| mvo | cool | 10:05 |
| zyga | I see the conversation now: interesting, I would have to check some things | 10:05 |
| mborzecki | 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:05 |
| zyga | perhaps interplay with mounting the instance name, the non-instatnce name and the content | 10:06 |
| pedronis | mvo: ken said it was the oldest parallel installed snap he had | 10:06 |
| zyga | I have a test in spread that shows how something similar fails | 10:06 |
| mborzecki | zyga: something similar, as in mounts or snap-seccomp during bootstrap? | 10:06 |
| zyga | is it reproducible? | 10:06 |
| zyga | mborzecki: as in mounts | 10:06 |
| mborzecki | zyga: i was not able to reproduce it yesterday | 10:07 |
| zyga | https://github.com/snapcore/snapd/blob/master/tests/main/layout-symlink-bind-revert/task.yaml | 10:07 |
| zyga | this encodes some of the problem (but you have to read deeply about what goes on in an associated commit message) | 10:07 |
| mvo | 6569 is green and should make tests green again | 10:07 |
| mvo | (needs a second review) | 10:07 |
| zyga | https://github.com/snapcore/snapd/commit/adf75238b85540d19027dc2f1c576bd266641af2#diff-a6e200ddb24754df8611a002020deccd | 10:08 |
| zyga | mvo: anyway, I will investigate | 10:08 |
| mvo | thank you zyga | 10:08 |
| ogra | ogra@nanopc-t4:~$ uname -a | 10:10 |
| ogra | 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 | ogra@nanopc-t4:~$ cat /proc/cpuinfo |grep -c ^processor | 10:10 |
| ogra | 6 | 10:10 |
| ogra | ogra@nanopc-t4:~$ free -h | grep ^Mem | 10:10 |
| ogra | Mem: 3.8G 124M 3.4G 11M 280M 3.5G | 10:10 |
| ogra | :D | 10:10 |
| zyga | ogra: raspberry pi 4? :D | 10:14 |
| ogra | 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:14 |
| ogra | 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 |
| ogra | (minus the queue ;) ) | 10:15 |
| zyga | ogra: build libreoffice then :) | 10:18 |
| ogra | 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:19 |
| pedronis | 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 |
| pedronis | because we don't get core (nor the snapd snap) | 10:21 |
| pedronis | mvo: https://forum.snapcraft.io/t/core18-snap-fails-to-run-on-16-04-cannot-locate-the-core-snap/10292/10 | 10:22 |
| mup | PR snapd#6569 closed: tests: check that apt works before using it <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6569> | 10:23 |
| mvo | pedronis: yeah, still no 2.37.x in xenial :/ | 10:23 |
| mvo | pedronis: our SRU process is still slow | 10:23 |
| pedronis | mvo: does 2.37 pull in core though? | 10:23 |
| pedronis | it will fix that problem | 10:24 |
| pedronis | but not the stale snapd | 10:24 |
| mvo | pedronis: right | 10:24 |
| mvo | 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:25 |
| thresh | 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 |
| zyga | thresh: this would only work through XDG portals, something that is not widely available yet | 10:31 |
| mborzecki | zyga: yay, no more import cycles, https://paste.ubuntu.com/p/X4vqjPsj85/ that's with the seccomp compiler wrapper under sandbox/seccomp | 10:34 |
| zyga | mborzecki: nice, I think this is what we need :) | 10:35 |
| thresh | zyga, ok, can you point me to the docs? | 10:35 |
| mborzecki | zyga: similar wrapper for apparmor under sandbox/apparmor would be trivial too :P | 10:35 |
| thresh | afaics, most of my users are on ubuntu 18.04 | 10:35 |
| zyga | 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 |
| thresh | zyga, ah, I see, thank you. | 10:36 |
| mup | PR core#102 closed: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/core/pull/102> | 10:58 |
| mborzecki | zyga: https://github.com/bboozzoo/snapd/commit/07f3aeab765514a1e8e5501fb4490ffca273a1e2 | 11:16 |
| zyga | mmm | 11:16 |
| mborzecki | tiny :) | 11:17 |
| mborzecki | i'm finishing fixing up the tests and will stat looking into the spread test of core18 | 11:18 |
| mborzecki | zyga: got your comment, will add that | 11:19 |
| zyga | mborzecki: +1 | 11:19 |
| zyga | mborzecki: I left one comment | 11:19 |
| zyga | thanks! | 11:19 |
| mborzecki | i'm heading home | 11:22 |
| Chipaca | mo'in all | 11:24 |
| Chipaca | back earlier than i feared, although I'll have to go out again this afternoon | 11:25 |
| Chipaca | meanwhile, there's a user out there wondering why 'sudo umount -a' causes their snaps to stop working | 11:25 |
| pedronis | pstolowski: I added some more highlevel considerations to 6562 | 11:29 |
| pedronis | Chipaca: hi, sorry for the slightly grumpy review of #6564 , the diff there is very hard to read | 11:30 |
| mup | PR #6564: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/6564> | 11:30 |
| pedronis | pstolowski: let me know if you have questions, need to lunch now though | 11:30 |
| pstolowski | pedronis: yep, looking, thanks! | 11:31 |
| Chipaca | pedronis: yeah | 11:32 |
| pedronis | mvo: any particular reason to push #6570 to 2.38 ? | 11:50 |
| mup | PR #6570: snapstate: only keep 2 snaps on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6570> | 11:50 |
| mvo | pedronis: just to make foundations happy | 11:53 |
| mvo | pedronis: fine to remove the milestone | 11:53 |
| pedronis | mvo: I don't think it's risky, but is not a bug fix either | 11:53 |
| pedronis | mvo: I removed it | 11:54 |
| pedronis | mvo: we have just one thing open for 2.38 | 11:54 |
| pedronis | now | 11:54 |
| Chipaca | pedronis: why is 'load' wrong, and why is 'examine' better, for a function that does cmd.ClientSnapFromSnapInfo(snap.ReadInfoFromSnapFile(snap.Open(...))) ? | 12:02 |
| mvo | 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 |
| pedronis | mvo: I understand | 12:03 |
| pedronis | Chipaca: are we loading the snap? | 12:03 |
| pedronis | do we use load for this anywhere? | 12:03 |
| pedronis | Chipaca: the line you pasted has no verb load in it | 12:04 |
| pedronis | it has a read | 12:04 |
| pedronis | Chipaca: it would be good also to find something else than "direct" | 12:06 |
| pedronis | Chipaca: examine had "?" after it, it was a proposal | 12:07 |
| Chipaca | to me "load" is pretty close to "open and read", but I recognise that this might be a 'me' thing | 12:10 |
| pedronis | Chipaca: yes, I think you tried to sneak it in somewhere else, but we don't use it that way | 12:10 |
| pedronis | Chipaca: to me load sounds like bring this entire thing into memory | 12:10 |
| pedronis | 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:12 |
| pedronis | but maybe that's me | 12:13 |
| === ricab is now known as ricab|lunch | ||
| pedronis | Chipaca: maybe we should turn them all into remoteSnap, localSnap and diskSnap ? don't lnow | 12:14 |
| pedronis | Chipaca: I commented on this a bit more in the PR itself | 12:59 |
| pedronis | Chipaca: wasn't this fixed already https://bugs.launchpad.net/snapd/+bug/1818306 ? | 13:41 |
| mup | Bug #1818306: disabled daemons are started after refresh <snapd:New> <https://launchpad.net/bugs/1818306> | 13:41 |
| === ricab|lunch is now known as ricab | ||
| Chipaca | pedronis: yes | 13:46 |
| pedronis | Chipaca: the report is recent | 13:48 |
| mup | PR snapd#6570 closed: snapstate: only keep 2 snaps on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6570> | 13:54 |
| mvo | 6418 needs a second review | 13:56 |
| Chipaca | pedronis: we fixed it for refresh, not for install i guess? | 13:58 |
| Chipaca | pedronis: what's the right behaviour for install? | 13:58 |
| pedronis | for install? | 13:59 |
| Chipaca | yes | 13:59 |
| pedronis | degville: 3 is actually mentioned here https://forum.snapcraft.io/t/getting-started/3876 under "snap revert" docs | 14:00 |
| pedronis | mvo: ^ | 14:00 |
| degville | thanks pedronis! | 14:00 |
| Chipaca | pedronis: actually I see the same behaviour on refresh | 14:01 |
| Chipaca | need to dig a bit | 14:01 |
| pedronis | Chipaca: ok | 14:01 |
| pedronis | Chipaca: I think internally that install is a refresh | 14:01 |
| pedronis | or not different to a refresh | 14:01 |
| Chipaca | it should be, yes | 14:01 |
| pedronis | Chipaca: anyway don't dig too much if you are doing something else | 14:02 |
| pedronis | Chipaca: we made a card | 14:02 |
| Chipaca | dunno if i'd complicate the services handling over it though | 14:02 |
| Chipaca | pedronis: also https://forum.snapcraft.io/t/disabled-snap-gets-enabled-after-a-refresh/7457 | 14:03 |
| zyga | Chipaca: standup or are you skipping? | 14:03 |
| Chipaca | going | 14:03 |
| Chipaca | pedronis: #5777 was never merged | 14:08 |
| mup | PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/5777> | 14:08 |
| pedronis | Chipaca: ah, so it's rally all tangled together as we discussed in Malta | 14:15 |
| pedronis | *really | 14:15 |
| feelextra | Hello! is there a Snap store besides Snapcraft's website? i thought Snap software can be distributed anywhere. | 14:19 |
| roadmr | feelextra: what made you think that? | 14:24 |
| feelextra | 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:34 |
| feelextra | at around 1:00 into the video | 14:35 |
| diddledan | feelextra: there is no currently available snap store implementation besides the official store which is proprietary. | 14:36 |
| diddledan | you _can_ reimplement it but you also need to modify the snapd to be able to recognise the alternative store location | 14:37 |
| feelextra | diddledan: thank you, that adds to my understanding of Snap! | 14:37 |
| diddledan | at the moment snapd is hardcoded to only use the canonical-sponsored store | 14:38 |
| diddledan | until there are alternative software to run your own store that's likely to remain as is | 14:38 |
| feelextra | i see. | 14:39 |
| Chipaca | there was a store implementation out there, but it lagged | 14:41 |
| Chipaca | and pointing snapd at a different store is reasonably straightforward | 14:41 |
| Chipaca | but it's not a federated system, at all | 14:41 |
| Chipaca | you choose one store and stick to it | 14:41 |
| Chipaca | using our staging store, for example, requires everything from scratch, even core | 14:41 |
| Chipaca | (because the assertions are all different) | 14:42 |
| === chihchun is now known as chihchun_afk | ||
| === tobias is now known as Guest42027 | ||
| Chipaca | stepping out for a while | 15:37 |
| === tobias is now known as Guest33922 | ||
| === tobias is now known as Guest8608 | ||
| mup | PR snapd#6566 closed: interface: avahi-observe: Fixing socket permissions on 4.15 kernels (2.38) <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6566> | 15:47 |
| === chihchun_afk is now known as chihchun | ||
| mborzecki | zyga: i've updated #6485 | 16:13 |
| mup | PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485> | 16:13 |
| zyga | looking | 16:13 |
| mborzecki | zyga: our mocking setup feels super fragile | 16:13 |
| zyga | mborzecki: yes | 16:14 |
| zyga | especially across packages | 16:14 |
| mborzecki | zyga: btw. https://forum.snapcraft.io/t/plans-for-sharing-a-gl-lib/10298 | 16:17 |
| zyga | oh, fun | 16:18 |
| zyga | will you reply or shall I? | 16:18 |
| mborzecki | zyga: go ahead | 16:29 |
| mborzecki | zyga: oh, and core18 works now, but I haven't confirmed that we suspected was actually the problem | 16:30 |
| zyga | what | 16:30 |
| zyga | did you change anything relevant? | 16:30 |
| mborzecki | zyga: there were some changes in the code that finds where snap-seccomp is | 16:31 |
| mborzecki | zyga: the test is running now, i'll let it finish | 16:31 |
| mborzecki | damn, Failed for "golang.org/x/crypto/cast5" (failed to clone repo): exit status 128, rly? | 16:32 |
| zyga | heh | 16:33 |
| mborzecki | zyga: heh, it's only rebooting the node now, so maybe it still doesn't work | 16:34 |
| === tobias is now known as Guest51748 | ||
| zyga | archive woes :/ https://www.irccloud.com/pastebin/amKlkAyM/ | 16:43 |
| zyga | Chipaca: let's add ubuntu to the list of distros without reliable archives | 16:43 |
| pedronis | zyga: please undo your change to 6418 | 16:43 |
| pedronis | it doesn't achieve the goal of the PR | 16:43 |
| zyga | oh? can you tell me more? | 16:44 |
| pedronis | zyga: we want to pivot | 16:44 |
| pedronis | that code won't | 16:44 |
| pedronis | zyga: I also tried to answer your other comments in the PR | 16:45 |
| zyga | pedronis: I agree about the pivoting aspect | 16:48 |
| zyga | pedronis: shall I revert or force push? | 16:48 |
| pedronis | zyga: what is more convenient | 16:48 |
| pedronis | zyga: anyway one of the comment explain a refactoring that is useful either way | 16:48 |
| pedronis | for the clarity of snap-confine | 16:48 |
| pedronis | this change (in principle) should be simple either place | 16:49 |
| pedronis | it isn't | 16:49 |
| zyga | about pivot, I'm again not sure what should happen, it's complex | 16:51 |
| pedronis | zyga: it's not complex | 16:51 |
| pedronis | or shouldn't be | 16:51 |
| zyga | the code doesn't need to pivot if boot base is core16-like and base snap is core16-like | 16:52 |
| zyga | for the maximum compatibility between core and core16 | 16:52 |
| pedronis | we don't want that | 16:52 |
| pedronis | core16 is accepting to move forward | 16:52 |
| pedronis | as a base | 16:52 |
| zyga | I'm not sure of that, if you think about what happens in core today it may break working snaps | 16:52 |
| pedronis | othewise those snaps will fail on core18 devices | 16:52 |
| pedronis | in unexpected ways | 16:53 |
| zyga | and I don't think we will give people to option to stay on pure core? (or will we?) | 16:53 |
| pedronis | zyga: we are introducing "base: core" as well, remember | 16:53 |
| zyga | core18 devices are new, those may not work _yet_, this may break stuff that does work now | 16:53 |
| pedronis | zyga: ? | 16:53 |
| pedronis | if a snap puts base: core16 | 16:53 |
| pedronis | in itself | 16:53 |
| pedronis | is getting places | 16:54 |
| pedronis | (that doesn't even work right now, remember, there is no stable core16) | 16:54 |
| zyga | 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:54 |
| pedronis | zyga: if you put base: core or no base | 16:55 |
| pedronis | you'll get the previous semantics | 16:55 |
| zyga | core16 was about unbundling snapd from core, this seems to make an extra assumption developers must be ok with | 16:55 |
| pedronis | it's not, we cannot really let people make core16 based snaps | 16:56 |
| pedronis | that don't work on core16 devices | 16:56 |
| pedronis | sorry on core18 devices | 16:56 |
| pedronis | no base snaps | 16:56 |
| pedronis | are a greyer area | 16:56 |
| pedronis | because of the choices we made | 16:56 |
| zyga | I agree but they are a grey area that is yet unexplored | 16:56 |
| zyga | I see your point of view but I'm worried core16 will break people more than it will help | 16:57 |
| zyga | we could discard the non-pivoting mode entirely and see what happens | 16:57 |
| pedronis | that is a different issue | 16:57 |
| zyga | perhaps the whole argument is moot, I think we don't really know | 16:57 |
| pedronis | anyway I don't see how making base: core16 potentially let you build snaps that don't work on core18 | 16:58 |
| pedronis | be progress | 16:58 |
| pedronis | toward the goal or turning off pivoting completely | 16:58 |
| zyga | pedronis: I think nobody will ship something that doesn't work | 16:59 |
| zyga | pedronis: the difference is who pulls the trigger, is it us for the developers (core -> core16 + snapd) or themselves | 16:59 |
| zyga | pedronis: I pushed a revert to the branch now | 16:59 |
| pedronis | we will still pivot if the snap has no base | 16:59 |
| pedronis | even on core16+snapd | 16:59 |
| zyga | pedronis: I will look at making a refactor you suggested | 16:59 |
| pedronis | (we'll need to code for that) | 16:59 |
| pedronis | or might pivot | 17:00 |
| pedronis | anyway that's part of the discussion how to get there | 17:00 |
| zyga | 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 |
| pedronis | option for base: core16 early | 17:00 |
| pedronis | means something else | 17:00 |
| pedronis | zyga: I know | 17:00 |
| zyga | another aspect is that the branch feels like an optimization | 17:00 |
| zyga | and we don't know what the correct mode is (or is it just me?) | 17:00 |
| zyga | if this never lands we just pull in core16 in addition to core | 17:01 |
| zyga | and then use base core16 | 17:01 |
| zyga | when snaps use core16 as their explicit base we will always pivot | 17:01 |
| pedronis | zyga: we need to decide, we need a correct implementation either way to let people play | 17:01 |
| zyga | (in the current code) | 17:01 |
| pedronis | zyga: anyway my main take away for all of this, is this comment: https://github.com/snapcore/snapd/pull/6418#discussion_r263027927 | 17:01 |
| mup | PR #6418: many: allow core as a fallback for core16 <â›” Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418> | 17:01 |
| pedronis | we should do either way | 17:01 |
| pedronis | because the current layering is not good(tm) | 17:02 |
| zyga | yeah | 17:02 |
| zyga | I agree | 17:02 |
| pedronis | so that should be a separate prereq PR either way | 17:03 |
| pedronis | zyga: mvo: you need to decide who would tackle that | 17:04 |
| zyga | I'm attempting that refactor now | 17:04 |
| carif | 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:12 |
| carif | i read something in the forums that its the preferred approach to capture and discussions and answers. ty | 17:13 |
| pedronis | carif: the best people to answer that were at some events last week | 17:14 |
| carif | pedronis, ack, i can be patient. just wanted to learn the protocol, ty. | 17:15 |
| mvo | zyga: thanks for tackling this | 17:25 |
| zyga | pedronis, mvo: I pushed a small branch that begins the refactoring while remaining readable https://github.com/snapcore/snapd/pull/6571 | 17:30 |
| mup | PR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571> | 17:30 |
| mup | PR snapd#6571 opened: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571> | 17:30 |
| pedronis | zyga: the user/groups ids vs the rest seems a bit different concerns (I see 3 calls to getresuid atm) | 17:41 |
| mup | PR snapd#6572 opened: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572> | 17:41 |
| mup | PR pc-i386-gadget#8 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8> | 17:42 |
| mup | PR pc-i386-gadget#9 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9> | 17:42 |
| mup | PR pc-amd64-gadget#12 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-amd64-gadget/pull/12> | 17:42 |
| mup | PR pc-amd64-gadget#13 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-amd64-gadget/pull/13> | 17:42 |
| zyga | pedronis: I wanted to keep the property of a refactor, I'm neither addnig nor removing more calls | 17:42 |
| zyga | pedronis: but I see your point, perhaps we should evacuate them from the struct | 17:43 |
| zyga | pedronis: and pass them around separately? | 17:43 |
| pedronis | zyga: yes, I just a fear getting that struct to the few other places that care will need huge changes | 17:44 |
| pedronis | seems a separate concern | 17:44 |
| pedronis | I mean care about those | 17:44 |
| zyga | pedronis: so, what to do? | 17:45 |
| pedronis | zyga: pass them separetly | 17:45 |
| pedronis | as you said | 17:45 |
| pedronis | in snap-confine.c | 17:45 |
| pedronis | itself | 17:45 |
| pedronis | at least for now | 17:45 |
| zyga | ok | 17:45 |
| pedronis | zyga: also do we use saved_uid/gid except printing them for debug? | 17:50 |
| zyga | we use only three of those | 17:50 |
| pedronis | seems down in the working bits we use only real_uid/gid | 17:52 |
| pedronis | in snap-confine.c | 17:52 |
| pedronis | itself | 17:52 |
| zyga | pedronis: pushed | 17:53 |
| zyga | the format is silly, sorry about that, it's the indent style we use | 17:53 |
| pedronis | zyga: thanks | 17:54 |
| zyga | pedronis: I also merged this into https://github.com/snapcore/snapd/pull/6572 | 17:56 |
| mup | PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572> | 17:57 |
| pedronis | zyga: is apparmor passed around a lot? | 18:07 |
| zyga | it's passed in a few places | 18:07 |
| zyga | we need it to run helpers | 18:07 |
| pedronis | zyga: grepping my feeling would be to carry it separately as well | 18:08 |
| pedronis | so invocation is really things derived from arguments | 18:09 |
| pedronis | (and further derived from those) | 18:09 |
| pedronis | zyga: not a strong opinion either way | 18:14 |
| zyga | pedronis: let's keep it inside for the purpose of this mini patch-series, I can move it out after we start to pass invocation around mount-support and ns-support | 18:17 |
| zyga | pedronis: by then will have useful data | 18:17 |
| pedronis | zyga: isn't it easier the other way around? I suppose it depends a bit how we got about it | 18:17 |
| pedronis | zyga: the question is really is whether the depth sc_invocation should go is about the same of apparmor or deeper | 18:18 |
| pedronis | as well | 18:18 |
| zyga | pedronis: right now we pass it as a separate argument but the number of arguments to enter_ is already pretty large | 18:18 |
| mup | PR snapd#6573 opened: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <https://github.com/snapcore/snapd/pull/6573> | 18:18 |
| zyga | pedronis: I don't mind removing it if it makes sense, just wanted to reach the point of the refactoring we were discussing initially | 18:19 |
| zyga | pedronis: I think invocation should go as deep as it makes sense to avoid passing the same arguments over and over | 18:19 |
| pedronis | zyga: well, as long as the target uses at least two things from it | 18:20 |
| pedronis | zyga: I'm a bit surprised about the last patch | 18:21 |
| zyga | I knew some of this code was a bit rusty but I was reluctant to change it without a path for rapid review and feedback cycle | 18:21 |
| zyga | pedronis: I started using the invocation but it grew bigger so I proposed the intermediate step first | 18:21 |
| pedronis | zyga: that's not the issue, can't we call sc_should_use_normal_mode in main ? | 18:22 |
| pedronis | and put it in sc_invocation | 18:22 |
| pedronis | we can then extract it down for now | 18:22 |
| zyga | pedronis: ah, yeah | 18:22 |
| zyga | pedronis: that won't explode the size of -3 yet | 18:22 |
| zyga | actually | 18:23 |
| zyga | pedronis: no :/ | 18:23 |
| pedronis | why ? | 18:23 |
| pedronis | (genuine question) | 18:23 |
| zyga | pedronis: because it must be probed after reassociate_with_pid1_mount_ns | 18:23 |
| zyga | I can move that to main | 18:23 |
| zyga | then move the check along with it | 18:23 |
| zyga | the thing is, we only did this in the non-classic path for now | 18:24 |
| pedronis | zyga: you can keep in the else path for now | 18:24 |
| zyga | which I think should remain so | 18:24 |
| pedronis | (but we have plans to make classic more like the rest) | 18:24 |
| zyga | yeah, that's true | 18:24 |
| zyga | just trying to limit possibility of fallout | 18:24 |
| pedronis | yes, I agree | 18:25 |
| zyga | one more idea | 18:25 |
| pedronis | but we can find a middle ground | 18:25 |
| zyga | we can make a classic invocation | 18:25 |
| zyga | and a strict invocation (for lack of a better name) | 18:25 |
| zyga | where classic is no-op empty | 18:25 |
| zyga | and strict has more things inside and is intialized at the right time | 18:25 |
| pedronis | do we need to? | 18:26 |
| pedronis | I'm not sure it helps in itself | 18:26 |
| zyga | I think it won't help much, just may make it clear that some fields are only used for strict path | 18:27 |
| pedronis | yea, we can set normal_mode to false on the classic path | 18:28 |
| pedronis | that's not the issue I think | 18:28 |
| zyga | mmm, yeah | 18:29 |
| zyga | let's do that | 18:29 |
| zyga | it will also means the functions start to change the invocation but I think that's ok | 18:29 |
| zyga | I started off with const because that's safer to explore | 18:30 |
| pedronis | zyga: we could also have sc_invocation exist only in the else path | 18:34 |
| zyga | yeah | 18:34 |
| pedronis | given is the other path does nothing | 18:34 |
| pedronis | and the code after calls just a couple of things | 18:34 |
| pedronis | that could use it (but also not) | 18:34 |
| zyga | we can solve it later when we do classic mount instances | 18:34 |
| pedronis | yes | 18:34 |
| zyga | I pushed the earlier suggestion to -3 | 18:35 |
| zyga | is_normal_mode is now in the struct | 18:35 |
| zyga | https://github.com/snapcore/snapd/pull/6573/commits/c7633e9debfebe64dd320996c5ae4a373e0ea25e | 18:35 |
| mup | PR #6573: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <https://github.com/snapcore/snapd/pull/6573> | 18:35 |
| zyga | pedronis: are you happy with the direction so far in -1, -2 and -3? | 18:36 |
| pedronis | zyga: yes | 18:38 |
| zyga | pedronis: I think we can pass the invocation to the main places that currently carry the chain of arguments like snap name, base snap name, etc | 18:38 |
| zyga | pedronis: we may (perhaps) split the invocation so that things that are static and dynamic are not mixed as much but we shall see how this looks like | 18:38 |
| pedronis | as I said I think it should be fine to send to anything that was taking at least two of the members | 18:39 |
| zyga | pedronis: I would love to eventually marry this with the idea that for each security tag we can ask the system, reliably and without user injections, what is the base snap, classic confinement mode | 18:39 |
| zyga | and drop the need for environment variables and arguments as trusted input | 18:39 |
| zyga | which we do our best to validate but still cannot prove correct (e.g. call one snap's app with another snap's confinement) | 18:40 |
| zyga | I need to break now, ttyl! | 18:43 |
| mvo | Chipaca: can I interest you in the review of 6381? second review, hopefully boring :) | 18:44 |
| zyga | stuff is failing on fatal: unable to access 'https://go.googlesource.com/net/': The requested URL returned error: 502 | 19:18 |
| zyga | any ideas? | 19:18 |
| zyga | I need to EOD | 19:18 |
| zyga | but if anyone is trying to land stuff, that's breaking all builds now | 19:19 |
| ogra | zyga, FYI https://github.com/snapcore/pi3-gadget/pull/20 ... open since Nov | 19:31 |
| mup | PR pi3-gadget#20: dots in interface names are not allowed, fix spi <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/20> | 19:31 |
| ogra | just merge it (or make sil2100 merge it ... ) | 19:32 |
| dot-tobias | Is there an ETA when snapcraft 3.2 will be available on launchpad builders? | 21:32 |
| dot-tobias | (for core16-based snaps) | 21:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!