| 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:57 |
| 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> | 04:58 |
| mup | PR snapd#7816 opened: release: 2.42.4 <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7816> | 06:30 |
| 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:26 |
| mvo | pedronis: good morning | 07:28 |
| mvo | pedronis: looking, thanks a lot for the feedback | 07:28 |
| 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:33 |
| 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) | 07:34 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 08:03 |
| marcustomlinson | morning :) | 08:03 |
| mvo | pedronis: thanks and I updated 7810 - hope I captured what you suggested there | 08:08 |
| mvo | pstolowski, marcustomlinson good morning! | 08:10 |
| pedronis | mvo: reviewed | 08:25 |
| mvo | pedronis: thank you! | 08:42 |
| mup | PR snapd#7817 opened: boot,bootloader: make MakeBootable() uc20 aware <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7817> | 09:01 |
| zyga | Good morning | 09:03 |
| zyga | Working till 1am | 09:03 |
| zyga | Will start in an hour | 09:03 |
| zyga | mvo: is the release successful? | 09:04 |
| mvo | zyga: so far it looks good, we need sergio to do the validations now but stuff is in beta | 09:06 |
| zyga | Ack | 09:16 |
| pedronis | mvo: did a pass on 7817 | 09:18 |
| mvo | pedronis: thank you! | 09:20 |
| 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:28 |
| pedronis | mvo: let me know if you have questions | 09:29 |
| 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:33 |
| mvo | pedronis: looks good, will work on this next | 09:34 |
| 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:35 |
| mborzecki | morning | 09:43 |
| pstolowski | hey mborzecki | 09:44 |
| mvo | hey mborzecki | 09:51 |
| pstolowski | pedronis: reviewing your plug/slot name cstrs | 09:52 |
| pedronis | pstolowski: thx, I asked a question in the is-connected one | 09:55 |
| pstolowski | ty | 09:55 |
| mborzecki | heh, switching to OneTab is kind of difficult, i don't feel this workflow yet | 10:13 |
| pstolowski | mborzecki: it's a pitty firefox dropped the tab groups feature, it was cool | 10:17 |
| mborzecki | pstolowski: not the only useful thing they dropped (or are dropping) | 10:18 |
| mborzecki | iirc scratchpad is next to go | 10:18 |
| mborzecki | as mus as i dislike js scratchpad was kind of useful to testing stuff out | 10:19 |
| zyga | hey mborzecki | 10:20 |
| * zyga is back now | 10:20 | |
| zyga | but feeling so so still | 10:20 |
| === pedronis_ is now known as pedronis | ||
| 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:41 |
| pedronis | pstolowski: mmh, did you try it? | 10:44 |
| pstolowski | pedronis: i've run the spread test | 10:45 |
| pstolowski | pedronis: why? | 10:45 |
| pedronis | I'm confused by our code then | 10:45 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:53 |
| pstolowski | pedronis: was that the confusing bit? | 10:54 |
| 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:55 |
| pedronis | also the double error... : is bad in general | 10:56 |
| 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:57 |
| pedronis | pstolowski: I don't think that's true | 10:58 |
| pedronis | pstolowski: anyway, let me think a bit | 10:58 |
| zyga | ok, only one more thing to write | 11:01 |
| === ricab_ is now known as ricab | ||
| 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:04 |
| mup | PR snapd#7820 opened: [RFC] boot: add boot.Modeenv.Kernel support <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7820> | 11:07 |
| pedronis | mvo: ^ we need to discuss this, is unexpected | 11:08 |
| 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:09 |
| === ricab_ is now known as ricab | ||
| 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:11 |
| 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:14 |
| zyga | whee | 11:15 |
| mborzecki | zyga: does it work on centos/amazon too? | 11:15 |
| 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:16 |
| === ricab_ is now known as ricab | ||
| 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:17 |
| pedronis | pstolowski: I made some initial suggestions | 11:38 |
| pstolowski | pedronis: ty | 11:39 |
| 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:43 |
| Chipaca | i so want to throw away all stringy channels and replace them with a type | 11:47 |
| zyga | Chipaca: \o/ | 11:48 |
| zyga | yay for types | 11:48 |
| 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:49 |
| pedronis | also we have risk only vs full | 11:50 |
| pedronis | also some channels come from assertions these days | 11:50 |
| Chipaca | pedronis: risk vs full, imho, is an argument for structured, not against | 11:53 |
| pedronis | Chipaca: we started in a world where channels were opaque to us, we cannot live there anymore sadly | 11:54 |
| 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 | 11:55 |
| zyga | re | 12:09 |
| zyga | coffee is badly needed | 12:09 |
| 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> | 12:34 |
| zyga | eh | 13:02 |
| zyga | d-feet hangs when you pick systemd1 on session bus | 13:02 |
| zyga | ah, actually it's just *very* slow | 13:03 |
| zyga | but it works | 13:03 |
| mup | PR snapd#7821 opened: interfces/seccomp: parallelize secomp backend setup <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7821> | 13:15 |
| pedronis | mborzecki: ^ I asked a question there | 13:23 |
| mborzecki | pedronis: cpu bound, but the compilation is single threaded | 13:24 |
| 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:25 |
| pedronis | mborzecki: it wasn't clear it's a draft | 13:26 |
| mborzecki | pedronis: ah, let me add [RFC] in the title | 13:26 |
| sdhd-sascha | is there a working weston snap ? | 13:39 |
| 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:46 |
| === ricab is now known as ricab|bbl | ||
| 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:48 |
| 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:49 |
| 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:50 |
| Chipaca | so stable would become latest/stable before snapstate got to see it | 13:51 |
| pedronis | ? | 13:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| mborzecki | pstolowski: had to resort to some jq trickery :/ | 13:56 |
| pstolowski | mborzecki: heh. no | 13:56 |
| 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:57 |
| 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:58 |
| Chipaca | I know | 13:59 |
| pedronis | Chipaca: seems like a good separate PR | 14:00 |
| 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:01 |
| pedronis | ah | 14:02 |
| pedronis | I see | 14:02 |
| pedronis | the joy of ParseChannel vs Verbatim | 14:02 |
| pedronis | grumble | 14:02 |
| pstolowski | pedronis: standup? | 14:03 |
| pedronis | maybe | 14:03 |
| Chipaca | nice, half my system froze | 14:04 |
| zyga-laptop | hmm | 15:01 |
| zyga-laptop | ok, I pushed an update to the draft | 15:01 |
| 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:02 | |
| 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:04 |
| * zyga EODs | 15:21 | |
| 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:39 |
| pedronis | good, you mentioned also SetChannelFromCommandline ? | 15:40 |
| pedronis | is that a different thing | 15:40 |
| Chipaca | pedronis: that's the first chunk in that diff | 15:41 |
| pedronis | ah, sorry | 15:42 |
| 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 |
| === ricab|bbl is now known as ricab | ||
| 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:44 |
| pedronis | mvo: anything I need to re-review still today? I was considering eoding soon | 15:45 |
| mvo | pedronis: should be fine, thank you | 16:26 |
| mup | PR snapd#7822 opened: devicestate: ensure system installation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7822> | 16:39 |
| 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:55 |
| 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 | 16:59 |
| mvo | cmatsuoka: reviewed your PR, super close! thanks for this | 17:00 |
| cmatsuoka | mvo: thanks for the review, fixing it now | 17:01 |
| 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 :) | 17:04 |
| 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:30 |
| 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:32 |
| 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:39 |
| sdhd-sascha | Or, how can the snap mounts be shown ? losetup and /run/mount/utab doesn't show /etc/fonts | 19:56 |
| 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 | 19:59 | |
| sdhd-sascha | hmm, seems that starting a snap, forks into a new namespace, and the mounts are under /proc/<snap pid>/mounts | 20:14 |
| 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:33 |
| 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:34 |
| zyga | sdhd-sascha: I'm such a noob at many things | 20:35 |
| zyga | sdhd-sascha: please don't worry, ask away :) | 20:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| sdhd-sascha | zyga: thank you again | 20:42 |
| sdhd-sascha | currently sway runs in "devmode", so i concentrate on that now | 20:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| sdhd-sascha | zyga: "snap-confine", was a super hint. great :-) | 20:49 |
| zyga | sdhd-sascha: oh, I forgot to share that link | 20:50 |
| zyga | one sec | 20:50 |
| 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:51 |
| sdhd-sascha | Good to know. Will read this maybe tomorrow. and try to delete the flock :-D | 20:53 |
| sdhd-sascha | ============ | 20:53 |
| sdhd-sascha | One thing: can i access the X11 socket from the host - without mount /etc/font/fonts.conf | 20:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| sdhd-sascha | and now i want to find, the interface which mounts this thing | 20:59 |
| zyga | sdhd-sascha: that's "desktop" | 20:59 |
| 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:00 |
| 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:01 |
| zyga | various parts of snapd understand that and implement the policy described by the specifications | 21:02 |
| 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:04 |
| sdhd-sascha | zyga: sorry. if you don't have time. Than i can wait and looking around by myself for today | 21:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| sdhd-sascha | i always start with grep'ping the template interface. and look where it's name is used | 21:14 |
| 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:15 |
| sdhd-sascha | thanks :-) | 21:16 |
| sdhd-sascha | Compliments to all Snapd developers, the source looks clean and structed! | 21:18 |
| zyga | it's not all rosy but we do our best to keep it tidy :) | 21:19 |
| 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:20 |
| sdhd-sascha | :-) | 21:21 |
| 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:22 |
| * cachio afk | 21:23 | |
| 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:25 |
| 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:27 |
| sdhd-sascha | i will. makes fun | 21:28 |
| sdhd-sascha | hope i can soon adapt the code from alan_g and start another snap from wayland | 21:29 |
| sdhd-sascha | ;-) | 21:29 |
| 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:31 |
| 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:41 |
| sdhd-sascha | alan has some repo with snapd in the mirServer repo | 21:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| sdhd-sascha | another thought that I had, | 21:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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 ;-) | 21:53 |
| 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:10 |
| 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:11 |
| Chipaca | ok i'm officially eod | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!