[04:57] <mup> PR snapd#7796 closed: overlord/snapstate: make sure configuration defaults are applied only once <⚠ Critical> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7796>
[04:57] <mup> PR snapd#7811 closed: cmd/snap-bootstrap: some small naming and code org tweaks <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7811>
[04:58] <mup> PR snapd#7814 closed:  overlord/snapstate: make sure configuration defaults are applied only once (2.42) <⚠ Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7814>
[06:30] <mup> PR snapd#7816 opened: release: 2.42.4 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7816>
[07:26] <pedronis> mvo: hi, I made some (further) comments in #7810, hope they make sense
[07:26] <mup> PR #7810: devicestate: add reading of modeenv to uc20 firstboot code <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7810>
[07:28] <mvo> pedronis: good morning
[07:28] <mvo> pedronis: looking, thanks a lot for the feedback
[07:33] <pedronis> 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] <mvo> 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)
[08:03] <pstolowski> morning
[08:03] <marcustomlinson> morning :)
[08:08] <mvo> pedronis: thanks and I updated 7810 - hope I captured what you suggested there
[08:10] <mvo> pstolowski, marcustomlinson good morning!
[08:25] <pedronis> mvo: reviewed
[08:42] <mvo> pedronis: thank you!
[09:01] <mup> PR snapd#7817 opened: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7817>
[09:03] <zyga> Good morning
[09:03] <zyga> Working till 1am
[09:03] <zyga> Will start in an hour
[09:04] <zyga> mvo: is the release successful?
[09:06] <mvo> zyga: so far it looks good, we need sergio to do the validations now but stuff is in beta
[09:16] <zyga> Ack
[09:18] <pedronis> mvo: did a pass on 7817
[09:20] <mvo> pedronis: thank you!
[09:28] <mup> PR snapd#7818 opened: cmd-boostrap: write /var/lib/snapd/modeenv to the right place <Simple 😃> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7818>
[09:29] <pedronis> mvo: let me know if you have questions
[09:33] <mup> PR snapd#7750 closed: sanity: check /dev/loop-control device as part of sanity checks <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7750>
[09:34] <mvo> pedronis: looks good, will work on this next
[09:35] <mup> PR snapd#7819 opened: boot: add boot.Modeenv.Base support <Simple 😃> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7819>
[09:35] <mvo> pedronis: thank you so much for the review of the uc20 booting spec!
[09:43] <mborzecki> morning
[09:44] <pstolowski> hey mborzecki
[09:51] <mvo> hey mborzecki
[09:52] <pstolowski> pedronis: reviewing your plug/slot name cstrs
[09:55] <pedronis> pstolowski: thx,  I asked a question in the is-connected one
[09:55] <pstolowski> ty
[10:13] <mborzecki> heh, switching to OneTab is kind of difficult, i don't feel this workflow yet
[10:17] <pstolowski> mborzecki: it's a pitty firefox dropped the tab groups feature, it was cool
[10:18] <mborzecki> pstolowski: not the only useful thing they dropped (or are dropping)
[10:18] <mborzecki> iirc scratchpad is next to go
[10:19] <mborzecki> as mus as i dislike js scratchpad was kind of useful to testing stuff out
[10:20] <zyga> hey mborzecki
[10:20]  * zyga is back now
[10:20] <zyga> but feeling so so still
[10:41] <pstolowski> pedronis: updated #7771
[10:41] <mup> PR #7771: o/hookstate/ctlcmd: snapctl is-connected command <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7771>
[10:44] <pedronis> pstolowski: mmh, did you try it?
[10:45] <pstolowski> pedronis: i've run the spread test
[10:45] <pstolowski> pedronis: why?
[10:45] <pedronis> I'm confused by our code then
[10:48] <ondra> zyga hey
[10:48] <zyga> hey
[10:48] <zyga> I just wanted to ensure you know that to use the fix you need to enable the experimental option
[10:48] <ondra> zyga sorry I was out yesterday, still something I can help today?
[10:48] <zyga> and that the gadget will enable it
[10:48] <zyga> no worries :)
[10:49] <ondra> zyga for refresh bug?
[10:49] <zyga> yes
[10:49] <ondra> zyga what is config option, so I can make sure it's in our gadget
[10:50] <zyga> ondra: it's exactly the same one as was given in all the bug reports
[10:50] <ondra> zyga cool, let me check
[10:50] <zyga> snap set core experimental.robust-mount-namespace-updates=true
[10:53] <pstolowski> pedronis: my bad, the error is actually "error: error running snapctl: plug is not connected" (i misread the output)
[10:53] <pstolowski> pedronis: that's a byproduct of our error propagation
[10:54] <pstolowski> pedronis: was that the confusing bit?
[10:55] <pedronis> pstolowski: yes
[10:55] <pedronis> pstolowski: I think we need to decide what to do, that's kind of a not great error for this
[10:56] <pedronis> also the double error... : is bad in general
[10:57] <mup> PR snapd#7816 closed: release: 2.42.4 <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7816>
[10:57] <pstolowski> 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] <pedronis> pstolowski: I don't think that's true
[10:58] <pedronis> pstolowski: anyway, let me think a bit
[11:01] <zyga> ok, only one more thing to write
[11:04] <pstolowski> 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] <mup> PR snapd#7820 opened: [RFC] boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7820>
[11:08] <pedronis> mvo: ^ we need to discuss this, is unexpected
[11:09] <mvo> 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] <mup> PR snapd#7706 closed: overlord/snapstate: install task edges <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7706>
[11:09] <mvo> pedronis: that's the reaosn for this PR but I'm probably missing something
[11:11] <mvo> pedronis: happy to chat (here or HO) in a bit, just need a short break
[11:11] <pedronis> mvo: I need to have lunch
[11:14] <zyga> tracking is now tested to work across all systems except 14.04
[11:14] <zyga> need to rewrite snap-run patch not to shell out to busctl
[11:14] <zyga> then it will work faster and on all of them
[11:15] <zyga> whee
[11:15] <mborzecki> zyga: does it work on centos/amazon too?
[11:16] <zyga> yes
[11:16] <mborzecki> cool
[11:16] <zyga> https://github.com/snapcore/snapd/compare/master...zyga:feature/sub-cg-wip-v2?expand=1
[11:17] <zyga> mborzecki: early review welcome
[11:17] <zyga> mborzecki: I need to move some things to sandbox/
[11:17] <zyga> mborzecki: and add more tests as indicated by TODOs
[11:38] <pedronis> pstolowski: I made some initial suggestions
[11:39] <pstolowski> pedronis: ty
[11:43] <mborzecki> 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] <pstolowski> mborzecki: great, thanks
[11:47] <Chipaca> i so want to throw away all stringy channels and replace them with a type
[11:48] <zyga> Chipaca: \o/
[11:48] <zyga> yay for types
[11:49] <pedronis> Chipaca: we have a type, no, snap/channel.Channel ?
[11:49] <Chipaca> pedronis: yes, but most of the time we pass around strings
[11:49] <pedronis> well, because the type came later
[11:50] <pedronis> also we have risk only vs full
[11:50] <pedronis> also some channels come from assertions these days
[11:53] <Chipaca> pedronis: risk vs full, imho, is an argument for structured, not against
[11:54] <pedronis> Chipaca: we started in a world where channels were opaque to us, we cannot live there anymore sadly
[11:55] <pedronis> Chipaca: do you have a sense of how big a change it would be ?
[11:55] <pedronis> (I fear too big for right now, but maybe I'm wrong)
[11:55] <Chipaca> rather big, especially in tests
[12:09] <zyga> re
[12:09] <zyga> coffee is badly needed
[12:34] <mup> PR snapd#7818 closed: cmd/snap-bootstrap: write /var/lib/snapd/modeenv to the right place <Simple 😃> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7818>
[12:34] <mup> PR snapd#7819 closed: boot: add boot.Modeenv.Base support <Simple 😃> <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7819>
[13:02] <zyga> eh
[13:02] <zyga> d-feet hangs when you pick systemd1 on session bus
[13:03] <zyga> ah, actually it's just *very* slow
[13:03] <zyga> but it works
[13:15] <mup> PR snapd#7821 opened: interfces/seccomp: parallelize secomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821>
[13:23] <pedronis> mborzecki: ^  I asked a question there
[13:24] <mborzecki> pedronis: cpu bound, but the compilation is single threaded
[13:25] <pedronis> mborzecki: do we want really to spawn that many processes on low end devices?
[13:25] <mborzecki> pedronis: we could as go about NumCPU(), but not i wanted to get a feeling whether anything breaks right away
[13:25] <pedronis> mborzecki: yes, I think we should use NumCPU() somehow
[13:26] <pedronis> mborzecki: it wasn't clear it's a draft
[13:26] <mborzecki> pedronis: ah, let me add [RFC] in the title
[13:39] <sdhd-sascha> is there a working weston snap ?
[13:46] <pedronis> 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
[13:48] <pedronis> Chipaca: I mean this: https://github.com/snapcore/snapd/pull/7373
[13:48] <mup> PR #7373: overlord/snapstate: revert track-risk behavior change and validation on install <Needs Samuele review> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7373>
[13:48] <Chipaca> pedronis: yes
[13:49] <Chipaca> pedronis: i assume it's because of the other changes in this area
[13:49] <pedronis> but master is green
[13:49] <Chipaca> ...?
[13:50] <pedronis> I mean I don't understand why the semantics change would now cause a cascade of spread failure
[13:50] <pedronis> when it didn't originally
[13:50] <Chipaca> ah
[13:50] <Chipaca> well, because we were over-normalising channels
[13:50] <Chipaca> and testing for that
[13:51] <Chipaca> so stable would become latest/stable before snapstate got to see it
[13:51] <pedronis> ?
[13:52] <mup> PR snapd#7806 closed: tests/lib/prepare: drop workarounds for rpmbuild rewriting /bin/sh <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7806>
[13:52] <pedronis> the changes were all in snapstate in pawel PR
[13:52] <pedronis> I'm still missing something
[13:52] <Chipaca> pedronis: was pawel's change sufficient to effect the behaviour change we wanted
[13:53] <Chipaca> pedronis: because testing locally, with master today, it would not have been
[13:53] <Chipaca> in particular cnd/snap's setChannelFromCommandline sets channel to the parsed short name
[13:53] <Chipaca> so there an explicit latest/ would be lost
[13:54] <Chipaca> and then daemon's snapRevisionOptions's validate would set channel to the parsed channel's name
[13:54] <Chipaca> so, again
[13:54] <pedronis> Chipaca: this is pawel main PR: https://github.com/snapcore/snapd/pull/7199
[13:54] <mup> PR #7199: overlord/snapstate: keep current track if only risk is specified <Created by stolowski> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7199>
[13:54] <pedronis> notice that I didn't review it
[13:54] <mborzecki> pstolowski: btw. didn't snap debug timings show the sum of doing-time at some point?
[13:56] <mborzecki> pstolowski: had to resort to some jq trickery :/
[13:56] <pstolowski> mborzecki: heh. no
[13:57] <Chipaca> pedronis: I did, and the change is necessary but not sufficient with today's master
[13:57] <Chipaca> pedronis: but, note both those things that over-normalize might be newer than pawel's pr
[13:58] <pedronis> Chipaca: yea, I woudl try to fix cmd/snap to stop changing latest/foo
[13:58] <pedronis> we don't want that anyway
[13:58] <pedronis> for default tracks
[13:58] <pedronis> Chipaca: it should try to pass as much as possible what the user gave
[13:59] <Chipaca> I know
[14:00] <pedronis> Chipaca: seems like a good separate PR
[14:01] <Chipaca> hmm
[14:01] <Chipaca> pedronis: i could make a separate pr from both un-over-normalisation changes
[14:01] <Chipaca> i'll do that
[14:01] <pedronis> but I missed something when I reviewed, I though we would use full only if errors
[14:02] <pedronis> ah
[14:02] <pedronis> I see
[14:02] <pedronis> the joy of ParseChannel vs Verbatim
[14:02] <pedronis> grumble
[14:03] <pstolowski> pedronis: standup?
[14:03] <pedronis> maybe
[14:04] <Chipaca> nice, half my system froze
[15:01] <zyga-laptop> hmm
[15:01] <zyga-laptop> ok, I pushed an update to the draft
[15:02] <zyga-laptop> mborzecki do you have a moment to just go over it with me
[15:02] <zyga-laptop> mborzecki I'm looking for advice on what to move or change ahead of proper PR
[15:02] <zyga-laptop> just a quick look
[15:02]  * cachio lunch
[15:04] <mborzecki> zyga-laptop: sure
[15:04] <mborzecki> zyga-laptop: meet?
[15:04] <zyga> yep
[15:04] <zyga> https://meet.google.com/eyi-xjto-svg?authuser=1
[15:21]  * zyga EODs
[15:39] <Chipaca> pedronis: FWIW the under-over PR does not break the spread tests
[15:39] <Chipaca> pedronis: https://github.com/snapcore/snapd/compare/master...chipaca:under-over-normalise
[15:40] <pedronis> good, you mentioned also SetChannelFromCommandline ?
[15:40] <pedronis> is that a different thing
[15:41] <Chipaca> pedronis: that's the first chunk in that diff
[15:42] <pedronis> ah, sorry
[15:44] <pedronis> Chipaca: is that a good thing or a bad thing that the spread tests don't break?
[15:44] <Chipaca> pedronis: i'm going with 'bad'
[15:44] <pedronis> ok, same as me then
[15:44] <Chipaca> :)
[15:44] <pedronis> still not sure why the other change would break lots of spread test
[15:44] <pedronis> s
[15:44] <pedronis> sound some subtle thing gone awry
[15:45] <pedronis> mvo: anything I need to re-review still today? I was considering eoding soon
[16:26] <mvo> pedronis: should be fine, thank you
[16:39] <mup> PR snapd#7822 opened: devicestate: ensure system installation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7822>
[16:55] <mup> PR snapd#7823 opened: snap-bootstrap: implement "run" mode in snap-bootstrap initramfs-mounts <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7823>
[16:59] <kjackal> 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] <kjackal> I build there with --use-lxd
[17:00] <mvo> cmatsuoka: reviewed your PR, super close! thanks for this
[17:01] <cmatsuoka> mvo: thanks for the review, fixing it now
[17:04] <mvo> cmatsuoka: I also marked the stuff that is done green in the gdoc
[17:04] <mvo> cmatsuoka: there is a lot of not-green stuff :/ oh well :)
[19:30] <sdhd-sascha> 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] <sdhd-sascha> i want to disable these mount. And have already removed all plugs.
[19:32] <sdhd-sascha> ogra: is this the right place for this question? because it needs go-lang programming knowledge. and knowlege of internals of snapd
[19:39] <mup> PR snapcraft#2827 opened: build providers: only set the snapd flag when installing snapd <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2827>
[19:56] <sdhd-sascha> Or, how can the snap mounts be shown ? losetup and /run/mount/utab doesn't show /etc/fonts
[19:59] <sdhd-sascha> Ok, inside the snap, the mounts are visible. (snap run --shell <snap> ; mount )    I look for a way, from outside...
[19:59]  * cachio afk
[20:14] <sdhd-sascha> hmm, seems that starting a snap, forks into a new namespace, and the mounts are under /proc/<snap pid>/mounts
[20:33] <zyga> sdhd-sascha: hey
[20:33] <zyga> sdhd-sascha: I know some things about how snap runtime works
[20:33] <zyga> sdhd-sascha: please feel free to ask me any questions you may have
[20:33] <sdhd-sascha> :-)
[20:34] <sdhd-sascha> 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] <sdhd-sascha> thank you ;-)
[20:35] <zyga> sdhd-sascha: I'm such a noob at many things
[20:35] <zyga> sdhd-sascha: please don't worry, ask away :)
[20:36] <zyga> sdhd-sascha: snapd uses mount namespaces
[20:36] <sdhd-sascha> 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] <zyga> sdhd-sascha: and many mounts within per-snap mount namespaces
[20:36] <zyga> sdhd-sascha: look at cmd/snap-confine/
[20:36] <zyga> sdhd-sascha: that part is implemented in C
[20:36] <zyga> sdhd-sascha: there's a document that explains, though older, version of snap-confine
[20:37] <sdhd-sascha> zyga: great :-)
[20:37] <zyga> sdhd-sascha: as a super-simple overview each non-classic snap runs in a new mount namespace
[20:37] <sdhd-sascha> i read a lot about "seccomp". what does this "abbrev" stand for ?
[20:37] <zyga> sdhd-sascha: seccomp is a feature of the linux kernel
[20:38] <zyga> 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] <sdhd-sascha> ah, ok
[20:38] <zyga> sdhd-sascha: snap-confine creates a new mount namespace
[20:39] <zyga> sdhd-sascha: which is essentially a new mount table that is no longer always identical to the one you see normally
[20:39] <zyga> sdhd-sascha: then it performs a number of operations to change that mount table
[20:39] <zyga> 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] <zyga> sdhd-sascha: I can tell you all the details about that if you have specific questions
[20:40] <sdhd-sascha> zyga: understood ;-)
[20:40] <zyga> sdhd-sascha: snaps using classic confinement (those that need snap install --classic something to install) are somewhat different
[20:40] <zyga> sdhd-sascha: they also use a mount namespace but the mount table is very similar to the host mount table
[20:41] <zyga> 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] <zyga> sdhd-sascha: snap-confine does a few more things but that's about it for the mount parts
[20:41] <zyga> 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] <sdhd-sascha> zyga: thank you again
[20:42] <sdhd-sascha> currently sway runs in "devmode", so i concentrate on that now
[20:43] <zyga> sdhd-sascha: devmode is a concept where the snap runs in a mount namespace but the confinement is not enforced
[20:43] <zyga> sdhd-sascha: so it can do operations that normally are not allowed
[20:43] <zyga> sdhd-sascha: or are only allowed if a specific interface is connected
[20:43] <zyga> 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] <sdhd-sascha> 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] <zyga> sdhd-sascha: file descriptors are shared across fork
[20:45] <zyga> sdhd-sascha: but not always across exec
[20:45] <sdhd-sascha> some days later i surely know what api-call snapd uses and if it can set similiar inheritence options
[20:45] <zyga> sdhd-sascha: typically library code will set the equivalent of O_CLOEXEC on each file descriptor opened
[20:46] <zyga> sdhd-sascha: and only clear that for things that need to be explicitly passed to executed program
[20:46] <sdhd-sascha> zyga: it's many years ago, i read about linux-/unix-systemprogramming ;-)
[20:47] <zyga> sdhd-sascha: manual pages are a great place to start
[20:47] <zyga> sdhd-sascha: though they can be somewhat dense at first
[20:47] <zyga> sdhd-sascha: cross-referencing each other
[20:48] <zyga> sdhd-sascha: feel free to ask, I'm here most of the time
[20:48] <sdhd-sascha> you are right. I'm the guy who read source, then open for 3 seconds the manual ...
[20:49] <sdhd-sascha> zyga: "snap-confine", was a super hint. great :-)
[20:50] <zyga> sdhd-sascha: oh, I forgot to share that link
[20:50] <zyga> one sec
[20:51] <zyga> sdhd-sascha: https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843
[20:51] <zyga> it's not super up-to-date with latest changes but it's very good no-code overview
[20:53] <sdhd-sascha> Good to know. Will read this maybe tomorrow. and try to delete the flock :-D
[20:53] <sdhd-sascha> [20:54] <sdhd-sascha> One thing: can i access the X11 socket from the host - without mount /etc/font/fonts.conf
[20:55] <zyga> sdhd-sascha: those are unrelated
[20:55] <zyga> sdhd-sascha: the X socket is, on some systems, an abstract unix socket
[20:55] <zyga> sdhd-sascha: so it's not a filesystem object, even though it has "path" like name
[20:55] <sdhd-sascha> yes, here it is unix
[20:55] <zyga> 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] <zyga> sdhd-sascha: and given the x11 interface is connected, the application process will have rights to open and use it
[20:56] <zyga> sdhd-sascha: fonts are entirely unrelated
[20:57] <zyga> 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] <sdhd-sascha> interfaces/builtin/desktop.go:284:              // Since /etc/fonts/fonts.conf in the snap mount ns is the same
[20:58] <sdhd-sascha> interfaces/builtin/desktop.go-285-              // as on the host, we need to preserve the original directory
[20:58] <sdhd-sascha> zyga: i found only this, so i started to understand the namespaces.
[20:59] <sdhd-sascha> and now i want to find, the interface which mounts this thing
[20:59] <zyga> sdhd-sascha: that's "desktop"
[21:00] <sdhd-sascha> zyga: it don't want to mention you any longer. You was a great help. I will figure it out by myself.
[21:01] <zyga> sdhd-sascha: this is a place to start https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go
[21:01] <zyga> snap interfaces provide "specifications"
[21:01] <zyga> to various parts of the sandbox setup
[21:01] <zyga> e.g. mount specification describes what to mount
[21:01] <zyga> apparmor specification describes apparmor-level permisions (that's part of the sandbox)
[21:01] <zyga> and so on
[21:02] <zyga> various parts of snapd understand that and implement the policy described by the specifications
[21:04] <sdhd-sascha> Have three more questions now:
[21:04] <sdhd-sascha> * which part/source parse and execute this specs?
[21:04] <sdhd-sascha> * what is the minimal way to clone an interface, modify it and register it into snapd.
[21:04] <sdhd-sascha> * Okay, this one, i can ask google... How set snapd into the most verbose debug mode.
[21:06] <sdhd-sascha> zyga: sorry. if you don't have time. Than i can wait and looking around by myself for today
[21:07] <zyga> sdhd-sascha: it's all internally done by snapd
[21:07] <zyga> sdhd-sascha: snapd passes each spec to a "backend" of a given kind (e.g. apparmor backend in snapd)
[21:08] <zyga> 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] <zyga> 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] <zyga> sdhd-sascha: you can set SNAPD_DEBUG=7 or SNAP_DEBUG=7 (I always forget which)
[21:09] <zyga> but but but
[21:09] <zyga> be careful :)
[21:09] <zyga> because snapd re-executes itself
[21:09] <zyga> so you will not run your own code changes most of the time
[21:09] <zyga> you can disable that by setting and exporting SNAP_REEXEC=0
[21:09] <zyga> you can then define a new interface, even a dummy empty one
[21:10] <zyga> and see that "snap interface --all" reports it
[21:10] <sdhd-sascha> allright ;-)
[21:10] <zyga> sdhd-sascha: there are lots of merged pull requests that show how an interface looks like
[21:11] <zyga> sdhd-sascha: and what needs changing to add one
[21:11] <zyga> sdhd-sascha: apart from adding the new .go file in the right spot there are a few small changes elsewhere
[21:11] <zyga> sdhd-sascha: but that's not something you will need soon
[21:11] <zyga> sdhd-sascha: some things are related to the so-called default policy and some more with integration tests
[21:11] <sdhd-sascha> there are enough interfaces. i compare these, then i will see what is possible with interfaces...
[21:12] <sdhd-sascha> you mean, desktop_test.go ?
[21:12] <sdhd-sascha> e.g.
[21:12] <zyga> no, those are unit tests
[21:12] <zyga> integration tests are in tests/main/ in the top-level
[21:13] <zyga> there are lots of those but there's one specific one that checks each interface type
[21:13] <zyga> and it requires small change each time a new interface is defined
[21:13] <sdhd-sascha> normally, i will found them
[21:14] <sdhd-sascha> i always start with grep'ping the template interface. and look where it's name is used
[21:15] <sdhd-sascha> usally i would take a interface with a random name, so i could find all places faster
[21:15] <zyga> if there's something specific you'd like an interface to allow an app to do you can ask on the forum
[21:15] <zyga> or ask here now
[21:16] <sdhd-sascha> thanks :-)
[21:18] <sdhd-sascha> Compliments to all Snapd developers, the source looks clean and structed!
[21:19] <zyga> it's not all rosy but we do our best to keep it tidy :)
[21:20] <mup> PR snapd#7810 closed: devicestate: add reading of modeenv to uc20 firstboot code <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7810>
[21:20] <zyga> and my colleague is still working
[21:21] <sdhd-sascha> :-)
[21:22] <sdhd-sascha> how many core developer are in the snapd team ? In my past, i was mostly a one-man team :-( There was often no time to cleanup, or rewrite the code
[21:23]  * cachio afk
[21:25] <zyga> sdhd-sascha: ten-ish
[21:25] <zyga> sdhd-sascha: though it's not all the same, we specialize and some members have different roles
[21:27] <sdhd-sascha> oh, i am too exhausted for today. I will be there tomorrow
[21:27] <zyga> good luck, stick around :)
[21:27] <sdhd-sascha> :-)
[21:28] <sdhd-sascha> i will. makes fun
[21:29] <sdhd-sascha> hope i can soon adapt the code from alan_g and start another snap from wayland
[21:29] <sdhd-sascha> ;-)
[21:31] <sdhd-sascha> in some days, i will maybe have another question: How to start a console-command from another snap ? Because of the termite snap https://snapcraft.io/termite
[21:41] <zyga> sdhd-sascha: can you be more specific?
[21:41] <zyga> do you want to run one snap from another snap?
[21:41] <zyga> or something else
[21:44] <sdhd-sascha> alan has some repo with snapd in the mirServer repo
[21:45] <sdhd-sascha> there are some modifications to start a snap "B" from snap "A"
[21:45] <zyga> ah
[21:45] <zyga> yeah, I know that branch
[21:46] <zyga> it's not merged yet, I need to review it
[21:46] <sdhd-sascha> at first glance, it looks like it can only start other desktop-applicaionts
[21:46] <zyga> yes
[21:46] <sdhd-sascha> now, i wonder, if we have some terminal-snap (e.g. gnome-terminal)
[21:46] <zyga> starting arbitrary things is complicated
[21:47] <zyga> there are technical reasons why it doesn't work
[21:47] <sdhd-sascha> how could we launch "tig", "conjure-up" or other curses-application
[21:47] <zyga> it's late, come back tomorrow and I can explain, ok?
[21:47] <zyga> it _can_ be done
[21:47] <zyga> but one must accept the limitations of what the resulting process is
[21:48] <zyga> it won't be a descendant of the process requesting to launch it
[21:48] <sdhd-sascha> yes :-) i will ask in some days, if i understood the current solution
[21:49] <sdhd-sascha> another thought that I had,
[21:50] <sdhd-sascha> Is it possible to create a master-snap template, and embed other snap's inside of them ?
[21:50] <zyga> like a "fat" snap that has many snaps inside?
[21:50] <zyga> yes
[21:50] <sdhd-sascha> so anybody could create a snapcraft.yaml with, e.g. this desktop , this terminal, this app and combine them
[21:50] <zyga> but there are limitations, some permissions are special
[21:50] <sdhd-sascha> yes
[21:50] <zyga> and we don't grant them easily
[21:51] <zyga> only specific snaps can have powerful interfaces
[21:51] <zyga> because we trust those publishers
[21:51] <zyga> sometimes it's better to be interconnected with interfaces
[21:51] <zyga> than to bundle and ask for the same interfaces that the originals had
[21:51] <sdhd-sascha> But could there be a master-namespace ... and each embedded part of the snap, has an sub-ns ?
[21:51] <zyga> it's not a namespace thing
[21:51] <zyga> namespaces are one aspect
[21:52] <zyga> it's really late, let's carry on tomorrow please
[21:52] <sdhd-sascha> yes, it's late
[21:52] <zyga> e.g. seccomp cannot be removed
[21:52] <zyga> or lessend
[21:52] <zyga> it can only be constrained
[21:52] <zyga> think about that
[21:52] <sdhd-sascha> And it's better to talk about it, when i have learned this in more depth
[21:52] <zyga> if you cannot use syscall X because of a seccomp profile
[21:52] <zyga> you cannot remove that constraint from a process, or its children
[21:53] <zyga> this complicates things that involve one snap launching another snap
[21:53] <zyga> (that constraint is enforced by the kernel)
[21:53] <sdhd-sascha> good night ;-)
[23:10] <Chipaca> sdhd-sascha: without reading the _whole_ backlog, about just executing arbitrary things, note https://forum.snapcraft.io/t/how-to-confine-a-desktop-shell/6561
[23:11] <Chipaca> sdhd-sascha: and there are newer forum topics continuing this subject but i can't find them right now probably because it's late:)
[23:11] <Chipaca> sdhd-sascha: https://forum.snapcraft.io/t/how-to-confine-a-desktop-shell/6561
[23:11] <Chipaca> wait that's the same one
[23:12] <Chipaca> ok i'm officially eod