[04:57] PR snapd#7796 closed: overlord/snapstate: make sure configuration defaults are applied only once <⚠ Critical> [04:57] PR snapd#7811 closed: cmd/snap-bootstrap: some small naming and code org tweaks [04:58] PR snapd#7814 closed: overlord/snapstate: make sure configuration defaults are applied only once (2.42) <⚠ Critical> [06:30] PR snapd#7816 opened: release: 2.42.4 [07:26] mvo: hi, I made some (further) comments in #7810, hope they make sense [07:26] PR #7810: devicestate: add reading of modeenv to uc20 firstboot code [07:28] pedronis: good morning [07:28] pedronis: looking, thanks a lot for the feedback [07:33] mvo: that final note probably means we should tweak the boot pkg interface for modeenv to avoid errors, but can be done a bit later [07:34] pedronis: ok, the comment makes sense, I will work on this in a wee bit (after some baby-sitting for 2.42.4, the review tools are acting up or something else is blocking reviews) === pstolowski|afk is now known as pstolowski [08:03] morning [08:03] morning :) [08:08] pedronis: thanks and I updated 7810 - hope I captured what you suggested there [08:10] pstolowski, marcustomlinson good morning! [08:25] mvo: reviewed [08:42] pedronis: thank you! [09:01] PR snapd#7817 opened: boot,bootloader: make MakeBootable() uc20 aware [09:03] Good morning [09:03] Working till 1am [09:03] Will start in an hour [09:04] mvo: is the release successful? [09:06] zyga: so far it looks good, we need sergio to do the validations now but stuff is in beta [09:16] Ack [09:18] mvo: did a pass on 7817 [09:20] pedronis: thank you! [09:28] PR snapd#7818 opened: cmd-boostrap: write /var/lib/snapd/modeenv to the right place [09:29] mvo: let me know if you have questions [09:33] PR snapd#7750 closed: sanity: check /dev/loop-control device as part of sanity checks [09:34] pedronis: looks good, will work on this next [09:35] PR snapd#7819 opened: boot: add boot.Modeenv.Base support [09:35] pedronis: thank you so much for the review of the uc20 booting spec! [09:43] morning [09:44] hey mborzecki [09:51] hey mborzecki [09:52] pedronis: reviewing your plug/slot name cstrs [09:55] pstolowski: thx, I asked a question in the is-connected one [09:55] ty [10:13] heh, switching to OneTab is kind of difficult, i don't feel this workflow yet [10:17] mborzecki: it's a pitty firefox dropped the tab groups feature, it was cool [10:18] pstolowski: not the only useful thing they dropped (or are dropping) [10:18] iirc scratchpad is next to go [10:19] as mus as i dislike js scratchpad was kind of useful to testing stuff out [10:20] hey mborzecki [10:20] * zyga is back now [10:20] but feeling so so still === pedronis_ is now known as pedronis [10:41] pedronis: updated #7771 [10:41] PR #7771: o/hookstate/ctlcmd: snapctl is-connected command [10:44] pstolowski: mmh, did you try it? [10:45] pedronis: i've run the spread test [10:45] pedronis: why? [10:45] I'm confused by our code then [10:48] zyga hey [10:48] hey [10:48] I just wanted to ensure you know that to use the fix you need to enable the experimental option [10:48] zyga sorry I was out yesterday, still something I can help today? [10:48] and that the gadget will enable it [10:48] no worries :) [10:49] zyga for refresh bug? [10:49] yes [10:49] zyga what is config option, so I can make sure it's in our gadget [10:50] ondra: it's exactly the same one as was given in all the bug reports [10:50] zyga cool, let me check [10:50] snap set core experimental.robust-mount-namespace-updates=true [10:53] pedronis: my bad, the error is actually "error: error running snapctl: plug is not connected" (i misread the output) [10:53] pedronis: that's a byproduct of our error propagation [10:54] pedronis: was that the confusing bit? [10:55] pstolowski: yes [10:55] pstolowski: I think we need to decide what to do, that's kind of a not great error for this [10:56] also the double error... : is bad in general [10:57] PR snapd#7816 closed: release: 2.42.4 [10:57] pedronis: true. slightly annoying is the fact that the only way for reporting non-zero status from this corner of the code is via non-empty error message [10:58] pstolowski: I don't think that's true [10:58] pstolowski: anyway, let me think a bit [11:01] ok, only one more thing to write === ricab_ is now known as ricab [11:04] pedronis: ok, looking at api - runSnapctl we could special case this like we do for ForbiddenCommandError; on the client we always append "error: ", that way we would have "error: plug is not connected" [11:07] PR snapd#7820 opened: [RFC] boot: add boot.Modeenv.Kernel support [11:08] mvo: ^ we need to discuss this, is unexpected [11:09] pedronis: yeah, happy to - this is why its RFC :) I'm pondering how to link from the static kernel.img back to the right kernel snap that needs to get mounted in initramfs [11:09] PR snapd#7706 closed: overlord/snapstate: install task edges [11:09] pedronis: that's the reaosn for this PR but I'm probably missing something === ricab_ is now known as ricab [11:11] pedronis: happy to chat (here or HO) in a bit, just need a short break [11:11] mvo: I need to have lunch [11:14] tracking is now tested to work across all systems except 14.04 [11:14] need to rewrite snap-run patch not to shell out to busctl [11:14] then it will work faster and on all of them [11:15] whee [11:15] zyga: does it work on centos/amazon too? [11:16] yes [11:16] cool [11:16] https://github.com/snapcore/snapd/compare/master...zyga:feature/sub-cg-wip-v2?expand=1 === ricab_ is now known as ricab [11:17] mborzecki: early review welcome [11:17] mborzecki: I need to move some things to sandbox/ [11:17] mborzecki: and add more tests as indicated by TODOs [11:38] pstolowski: I made some initial suggestions [11:39] pedronis: ty [11:43] pstolowski: rebased by old branch about parallel seccomp profile compiles since we now know that it takes much longer to execute https://paste.ubuntu.com/p/NwxKtFtSJQ/ [11:43] mborzecki: great, thanks [11:47] i so want to throw away all stringy channels and replace them with a type [11:48] Chipaca: \o/ [11:48] yay for types [11:49] Chipaca: we have a type, no, snap/channel.Channel ? [11:49] pedronis: yes, but most of the time we pass around strings [11:49] well, because the type came later [11:50] also we have risk only vs full [11:50] also some channels come from assertions these days [11:53] pedronis: risk vs full, imho, is an argument for structured, not against [11:54] Chipaca: we started in a world where channels were opaque to us, we cannot live there anymore sadly [11:55] Chipaca: do you have a sense of how big a change it would be ? [11:55] (I fear too big for right now, but maybe I'm wrong) [11:55] rather big, especially in tests [12:09] re [12:09] coffee is badly needed [12:34] PR snapd#7818 closed: cmd/snap-bootstrap: write /var/lib/snapd/modeenv to the right place [12:34] PR snapd#7819 closed: boot: add boot.Modeenv.Base support [13:02] eh [13:02] d-feet hangs when you pick systemd1 on session bus [13:03] ah, actually it's just *very* slow [13:03] but it works [13:15] PR snapd#7821 opened: interfces/seccomp: parallelize secomp backend setup [13:23] mborzecki: ^ I asked a question there [13:24] pedronis: cpu bound, but the compilation is single threaded [13:25] mborzecki: do we want really to spawn that many processes on low end devices? [13:25] pedronis: we could as go about NumCPU(), but not i wanted to get a feeling whether anything breaks right away [13:25] mborzecki: yes, I think we should use NumCPU() somehow [13:26] mborzecki: it wasn't clear it's a draft [13:26] pedronis: ah, let me add [RFC] in the title [13:39] is there a working weston snap ? [13:46] Chipaca: can you explain the stack of failing spread tests? pstolowski had that landed at some point and we reverted it, so I think the spread tests were passing === ricab is now known as ricab|bbl [13:48] Chipaca: I mean this: https://github.com/snapcore/snapd/pull/7373 [13:48] PR #7373: overlord/snapstate: revert track-risk behavior change and validation on install [13:48] pedronis: yes [13:49] pedronis: i assume it's because of the other changes in this area [13:49] but master is green [13:49] ...? [13:50] I mean I don't understand why the semantics change would now cause a cascade of spread failure [13:50] when it didn't originally [13:50] ah [13:50] well, because we were over-normalising channels [13:50] and testing for that [13:51] so stable would become latest/stable before snapstate got to see it [13:51] ? [13:52] PR snapd#7806 closed: tests/lib/prepare: drop workarounds for rpmbuild rewriting /bin/sh [13:52] the changes were all in snapstate in pawel PR [13:52] I'm still missing something [13:52] pedronis: was pawel's change sufficient to effect the behaviour change we wanted [13:53] pedronis: because testing locally, with master today, it would not have been [13:53] in particular cnd/snap's setChannelFromCommandline sets channel to the parsed short name [13:53] so there an explicit latest/ would be lost [13:54] and then daemon's snapRevisionOptions's validate would set channel to the parsed channel's name [13:54] so, again [13:54] Chipaca: this is pawel main PR: https://github.com/snapcore/snapd/pull/7199 [13:54] PR #7199: overlord/snapstate: keep current track if only risk is specified [13:54] notice that I didn't review it [13:54] pstolowski: btw. didn't snap debug timings show the sum of doing-time at some point? [13:56] pstolowski: had to resort to some jq trickery :/ [13:56] mborzecki: heh. no [13:57] pedronis: I did, and the change is necessary but not sufficient with today's master [13:57] pedronis: but, note both those things that over-normalize might be newer than pawel's pr [13:58] Chipaca: yea, I woudl try to fix cmd/snap to stop changing latest/foo [13:58] we don't want that anyway [13:58] for default tracks [13:58] Chipaca: it should try to pass as much as possible what the user gave [13:59] I know [14:00] Chipaca: seems like a good separate PR [14:01] hmm [14:01] pedronis: i could make a separate pr from both un-over-normalisation changes [14:01] i'll do that [14:01] but I missed something when I reviewed, I though we would use full only if errors [14:02] ah [14:02] I see [14:02] the joy of ParseChannel vs Verbatim [14:02] grumble [14:03] pedronis: standup? [14:03] maybe [14:04] nice, half my system froze [15:01] hmm [15:01] ok, I pushed an update to the draft [15:02] mborzecki do you have a moment to just go over it with me [15:02] mborzecki I'm looking for advice on what to move or change ahead of proper PR [15:02] just a quick look [15:02] * cachio lunch [15:04] zyga-laptop: sure [15:04] zyga-laptop: meet? [15:04] yep [15:04] https://meet.google.com/eyi-xjto-svg?authuser=1 [15:21] * zyga EODs [15:39] pedronis: FWIW the under-over PR does not break the spread tests [15:39] pedronis: https://github.com/snapcore/snapd/compare/master...chipaca:under-over-normalise [15:40] good, you mentioned also SetChannelFromCommandline ? [15:40] is that a different thing [15:41] pedronis: that's the first chunk in that diff [15:42] ah, sorry [15:44] Chipaca: is that a good thing or a bad thing that the spread tests don't break? [15:44] pedronis: i'm going with 'bad' === ricab|bbl is now known as ricab [15:44] ok, same as me then [15:44] :) [15:44] still not sure why the other change would break lots of spread test [15:44] s [15:44] sound some subtle thing gone awry [15:45] mvo: anything I need to re-review still today? I was considering eoding soon [16:26] pedronis: should be fine, thank you [16:39] PR snapd#7822 opened: devicestate: ensure system installation [16:55] PR snapd#7823 opened: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts [16:59] did we change anything recently in snapcraft? Builds are failing on travis with: An error occurred when trying to execute 'snap set system experimental.snapd-snap=true' with 'LXD': returned exit code 1. [16:59] I build there with --use-lxd [17:00] cmatsuoka: reviewed your PR, super close! thanks for this [17:01] mvo: thanks for the review, fixing it now [17:04] cmatsuoka: I also marked the stuff that is done green in the gdoc [17:04] cmatsuoka: there is a lot of not-green stuff :/ oh well :) [19:30] hi, does anybody know, where in the golang code inside of snapd (snap+d - deamon) the mount for the /etc/fonts directory happens ? [19:30] i want to disable these mount. And have already removed all plugs. [19:32] ogra: is this the right place for this question? because it needs go-lang programming knowledge. and knowlege of internals of snapd [19:39] PR snapcraft#2827 opened: build providers: only set the snapd flag when installing snapd [19:56] Or, how can the snap mounts be shown ? losetup and /run/mount/utab doesn't show /etc/fonts [19:59] Ok, inside the snap, the mounts are visible. (snap run --shell ; mount ) I look for a way, from outside... [19:59] * cachio afk [20:14] hmm, seems that starting a snap, forks into a new namespace, and the mounts are under /proc//mounts [20:33] sdhd-sascha: hey [20:33] sdhd-sascha: I know some things about how snap runtime works [20:33] sdhd-sascha: please feel free to ask me any questions you may have [20:33] :-) [20:34] zyga: for me it's sometimes very awkward to ask some noob question, and then the next day or the next 10 minutes i found the answer :-o [20:34] thank you ;-) [20:35] sdhd-sascha: I'm such a noob at many things [20:35] sdhd-sascha: please don't worry, ask away :) [20:36] sdhd-sascha: snapd uses mount namespaces [20:36] i just found git:/snapd/snap/cmd/cmd_run.go ... now i want to find the place where the namespace (or others) are created, to have a look at the linux-api. So i can then read about the api to understand snapd better... [20:36] sdhd-sascha: and many mounts within per-snap mount namespaces [20:36] sdhd-sascha: look at cmd/snap-confine/ [20:36] sdhd-sascha: that part is implemented in C [20:36] sdhd-sascha: there's a document that explains, though older, version of snap-confine [20:37] zyga: great :-) [20:37] sdhd-sascha: as a super-simple overview each non-classic snap runs in a new mount namespace [20:37] i read a lot about "seccomp". what does this "abbrev" stand for ? [20:37] sdhd-sascha: seccomp is a feature of the linux kernel [20:38] sdhd-sascha: you can read about it by in many places, man pages are a good start, but it's essentially a way to control which system calls a given program may use [20:38] ah, ok [20:38] sdhd-sascha: snap-confine creates a new mount namespace [20:39] sdhd-sascha: which is essentially a new mount table that is no longer always identical to the one you see normally [20:39] sdhd-sascha: then it performs a number of operations to change that mount table [20:39] sdhd-sascha: one thing it does is perform a super-charged version of chroot, called pivot, to change what the snap sees as the root filesystem [20:40] sdhd-sascha: I can tell you all the details about that if you have specific questions [20:40] zyga: understood ;-) [20:40] sdhd-sascha: snaps using classic confinement (those that need snap install --classic something to install) are somewhat different [20:40] sdhd-sascha: they also use a mount namespace but the mount table is very similar to the host mount table [20:41] sdhd-sascha: and it is set up in a way that shares changes, so things mounted in one place show up in the other (e.g. you mount a drive on the system and the snap would see it) [20:41] sdhd-sascha: snap-confine does a few more things but that's about it for the mount parts [20:41] sdhd-sascha: oh, such mount tables are "persisted" so multiple processes started independently see the same mount table if they belong to the same snap [20:42] zyga: thank you again [20:42] currently sway runs in "devmode", so i concentrate on that now [20:43] sdhd-sascha: devmode is a concept where the snap runs in a mount namespace but the confinement is not enforced [20:43] sdhd-sascha: so it can do operations that normally are not allowed [20:43] sdhd-sascha: or are only allowed if a specific interface is connected [20:43] sdhd-sascha: this involves system calls that can be used, files and sockets that can be accessed as well as DBus messages that can be sent or received [20:44] from the past, i can remember, that with "fork" or a similar call, you can give a parameter which says, to e.g. share some file-descriptors with the child or leave it [20:45] sdhd-sascha: file descriptors are shared across fork [20:45] sdhd-sascha: but not always across exec [20:45] some days later i surely know what api-call snapd uses and if it can set similiar inheritence options [20:45] sdhd-sascha: typically library code will set the equivalent of O_CLOEXEC on each file descriptor opened [20:46] sdhd-sascha: and only clear that for things that need to be explicitly passed to executed program [20:46] zyga: it's many years ago, i read about linux-/unix-systemprogramming ;-) [20:47] sdhd-sascha: manual pages are a great place to start [20:47] sdhd-sascha: though they can be somewhat dense at first [20:47] sdhd-sascha: cross-referencing each other [20:48] sdhd-sascha: feel free to ask, I'm here most of the time [20:48] you are right. I'm the guy who read source, then open for 3 seconds the manual ... [20:49] zyga: "snap-confine", was a super hint. great :-) [20:50] sdhd-sascha: oh, I forgot to share that link [20:50] one sec [20:51] sdhd-sascha: https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843 [20:51] it's not super up-to-date with latest changes but it's very good no-code overview [20:53] Good to know. Will read this maybe tomorrow. and try to delete the flock :-D [20:53] ============ [20:54] One thing: can i access the X11 socket from the host - without mount /etc/font/fonts.conf [20:55] sdhd-sascha: those are unrelated [20:55] sdhd-sascha: the X socket is, on some systems, an abstract unix socket [20:55] sdhd-sascha: so it's not a filesystem object, even though it has "path" like name [20:55] yes, here it is unix [20:55] sdhd-sascha: on other systems it's a unix socket that is mounted in a location that is visible from the snap and from the host [20:56] sdhd-sascha: and given the x11 interface is connected, the application process will have rights to open and use it [20:56] sdhd-sascha: fonts are entirely unrelated [20:57] sdhd-sascha: not sure why you mentioned /etc/font/font.conf but there are a number of interfaces for desktop interaction, specifically "desktop" is one such generic and broad interface that provides useful desktop-y things like font support, sharing of fonts from the host and more [20:58] interfaces/builtin/desktop.go:284: // Since /etc/fonts/fonts.conf in the snap mount ns is the same [20:58] interfaces/builtin/desktop.go-285- // as on the host, we need to preserve the original directory [20:58] zyga: i found only this, so i started to understand the namespaces. [20:59] and now i want to find, the interface which mounts this thing [20:59] sdhd-sascha: that's "desktop" [21:00] zyga: it don't want to mention you any longer. You was a great help. I will figure it out by myself. [21:01] sdhd-sascha: this is a place to start https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go [21:01] snap interfaces provide "specifications" [21:01] to various parts of the sandbox setup [21:01] e.g. mount specification describes what to mount [21:01] apparmor specification describes apparmor-level permisions (that's part of the sandbox) [21:01] and so on [21:02] various parts of snapd understand that and implement the policy described by the specifications [21:04] Have three more questions now: [21:04] * which part/source parse and execute this specs? [21:04] * what is the minimal way to clone an interface, modify it and register it into snapd. [21:04] * Okay, this one, i can ask google... How set snapd into the most verbose debug mode. [21:06] zyga: sorry. if you don't have time. Than i can wait and looking around by myself for today [21:07] sdhd-sascha: it's all internally done by snapd [21:07] sdhd-sascha: snapd passes each spec to a "backend" of a given kind (e.g. apparmor backend in snapd) [21:08] sdhd-sascha: then the backend does some processing on all the specs combined (spec is for a specific interface, snaps may have many) and applies that in the system [21:09] sdhd-sascha: all interfaces are declared inside snapd, so you'd have to create a new file in interfaces/builtin and define stuff there, the magic happens when the interface is registered, e.g. here: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go#L293 [21:09] sdhd-sascha: you can set SNAPD_DEBUG=7 or SNAP_DEBUG=7 (I always forget which) [21:09] but but but [21:09] be careful :) [21:09] because snapd re-executes itself [21:09] so you will not run your own code changes most of the time [21:09] you can disable that by setting and exporting SNAP_REEXEC=0 [21:09] you can then define a new interface, even a dummy empty one [21:10] and see that "snap interface --all" reports it [21:10] allright ;-) [21:10] sdhd-sascha: there are lots of merged pull requests that show how an interface looks like [21:11] sdhd-sascha: and what needs changing to add one [21:11] sdhd-sascha: apart from adding the new .go file in the right spot there are a few small changes elsewhere [21:11] sdhd-sascha: but that's not something you will need soon [21:11] sdhd-sascha: some things are related to the so-called default policy and some more with integration tests [21:11] there are enough interfaces. i compare these, then i will see what is possible with interfaces... [21:12] you mean, desktop_test.go ? [21:12] e.g. [21:12] no, those are unit tests [21:12] integration tests are in tests/main/ in the top-level [21:13] there are lots of those but there's one specific one that checks each interface type [21:13] and it requires small change each time a new interface is defined [21:13] normally, i will found them [21:14] i always start with grep'ping the template interface. and look where it's name is used [21:15] usally i would take a interface with a random name, so i could find all places faster [21:15]