| === zigford_ is now known as zigford | ||
| mborzecki | morning | 06:31 |
|---|---|---|
| mborzecki | wow, forum got updated? | 06:31 |
| mvo | hey mborzecki | 06:31 |
| mborzecki | mvo: hey | 06:31 |
| mup | PR snapd#7752 closed: tests: enable degraded test on arch linux after latest image updates <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7752> | 06:32 |
| mborzecki | mvo: https://github.com/snapcore/snapd/pull/7751 simple one, could land easily | 06:34 |
| mup | PR #7751: cmd: fix the get command help message <Simple 😃> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7751> | 06:34 |
| mvo | mborzecki: sure | 06:36 |
| mup | PR snapd#7751 closed: cmd: fix the get command help message <Simple 😃> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7751> | 06:39 |
| mup | PR snapd#7753 opened: po: sync translations from launchpad <Created by mvo5> <https://github.com/snapcore/snapd/pull/7753> | 07:03 |
| mup | PR snapd#7754 opened: release: 2.42.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7754> | 07:30 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 08:03 |
| mborzecki | pstolowski: hey | 08:50 |
| pstolowski | o/ | 08:50 |
| mup | PR snapd#7755 opened: cmd/snap-failure: fallback to snap from core, extend tests <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7755> | 08:50 |
| mborzecki | mvo: ^^ | 08:50 |
| mvo | mborzecki: nice | 08:52 |
| mvo | can someone please sanity check 7754, should be super simple | 09:22 |
| mvo | single review for this is enough | 09:23 |
| mup | PR snapd#7713 closed: seed: Core 20 seeds channel overrides support for grade dangerous <Priority 🏇> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7713> | 09:36 |
| mup | PR snapd#7754 closed: release: 2.42.2 <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7754> | 09:42 |
| mborzecki | zyga: when you're around https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635 looks to me like the default mount options changed for the virtual filesystems, maybe some systemd updated triggered that? | 10:11 |
| mup | Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1852635> | 10:11 |
| pstolowski | mborzecki, zyga : i'm on it | 10:15 |
| pstolowski | 2 hrs in, almost finished | 10:16 |
| pstolowski | a couple of changes affecting it | 10:16 |
| pstolowski | zyga: btw, i'd drop the debug section (for fname in ./*.deterministic.txt...) from this test.. it produces walls of text which is not helping. actual diff that failed is most useful to understand what changes | 10:18 |
| pstolowski | *changed | 10:18 |
| zyga | good morning | 11:39 |
| zyga | sorry for starting late, I still cannot sleep at night | 11:39 |
| zyga | mborzecki: looking | 11:39 |
| zyga | pstolowski: that debug section is useful when there are larger changes and the diff is not something you want to work with | 11:40 |
| zyga | pstolowski: perhaps put it behind an environment variable test? | 11:41 |
| pstolowski | zyga: good idea | 11:50 |
| zyga | pstolowski: I released 2.42.1 to tw yesterday, did you update to it? | 12:02 |
| pstolowski | zyga: yes, i'm on it | 12:05 |
| pstolowski | why? | 12:05 |
| zyga | good, just wanted to know if you see anything wrong | 12:08 |
| zyga | it worked ok for me | 12:08 |
| Chipaca | zyga: silly question, where can i see the apparmor profile that is actually loaded? e.g. the profile in /var says 'include abstractions/foo', where can i see the pre-processed(?) one? | 12:15 |
| zyga | Chipaca: those are in /etc/apparmor.d | 12:16 |
| Chipaca | zyga: I know, which /etc tho | 12:17 |
| Chipaca | zyga: :) | 12:17 |
| Chipaca | i have four of 'em | 12:17 |
| Chipaca | outer /etc, core /etc (twice), and core18 /etc | 12:17 |
| Chipaca | and they're different in important ways :) | 12:17 |
| zyga | Chipaca: in the one seen when you log in | 12:17 |
| zyga | Chipaca: if you are talking about core that's the /etc from the boot base snap | 12:17 |
| zyga | Chipaca: on classic that's the classic /etc | 12:18 |
| zyga | Chipaca: sorry, I didn't understand your question initially | 12:18 |
| zyga | mvo: do you sleep normally now? | 12:18 |
| Chipaca | so, say, a core18 snap will use abstractions/python from the host? | 12:18 |
| zyga | yes | 12:18 |
| zyga | Chipaca: that's correct | 12:18 |
| Chipaca | that's bad and wrong | 12:18 |
| zyga | Chipaca: as in, that's what happens, your understanding is correct | 12:18 |
| zyga | indeed, it can cause syntax from apparmor 3 to interfere, for example | 12:18 |
| Chipaca | or, we need to retro-tweak it :) | 12:18 |
| zyga | Chipaca: what are you seeing? | 12:19 |
| Chipaca | it means a core18-based python snap on 1604 might not work | 12:19 |
| Chipaca | zyga: i'm not, but somebody else is seeing an issue | 12:19 |
| Chipaca | where it doesn't load a .so | 12:19 |
| Chipaca | https://forum.snapcraft.io/t/ubuntu-16-04-host-denies-core18-snap-python-3-6-library-import/14247 | 12:19 |
| Chipaca | now, i'm on 1604 and i can load that .so without issue, but my system might be "special" | 12:20 |
| Chipaca | so i dunno | 12:20 |
| cachio | mvo, hey | 12:20 |
| cachio | mvo, sru almost ready but 1 test failing on bionic | 12:20 |
| cachio | https://paste.ubuntu.com/p/dKrJRZb7Jb/ | 12:20 |
| zyga | Chipaca: one more reason why sharing /etc was a mistake | 12:20 |
| zyga | and we need to work towards undoing that | 12:20 |
| cachio | mvo, the test is snap-seccomp-syscalls | 12:21 |
| cachio | mvo, I remmeber we fixed it weeks ago but not sure if it is something we need to address | 12:22 |
| mvo | cachio: yeah, this is fixed in 2.42.2 I think its fine to ignore this failure | 12:23 |
| cachio | mvo, perfect | 12:23 |
| mvo | cachio: 2.42.2 will not need a sru I think, the re-exec is fine, this is only important for lxd-support | 12:23 |
| mup | PR snapd#7749 closed: tests: restart the snapd service in the snapd-failover test <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7749> | 12:23 |
| cachio | mvo, ok | 12:23 |
| cachio | makes sense | 12:23 |
| mup | PR snapd#7756 opened: tests: update mount-ns test for bionic image changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/7756> | 12:44 |
| pstolowski | cachio, zyga ^ | 12:44 |
| zyga | ack | 12:44 |
| cachio | pstolowski, nice, I'll take a look | 12:44 |
| zyga | pstolowski: what is the test-bionic image? is that the image we are going to upgrade to? | 12:45 |
| mborzecki | pstolowski: do we know which packages are responsible for those changes? | 12:46 |
| zyga | reading the diff I would love for the .expected.txt files to use delta encoding, so all numbers would be like +1 instead of 12 (even after renumbering) | 12:47 |
| zyga | it would remove most of the diff | 12:47 |
| zyga | pstolowski: I agree with mborzecki that we should know what's the origin of the change | 12:47 |
| zyga | but other than that +1 | 12:47 |
| pstolowski | zyga. mborzecki i don't know what package is the origin of them | 12:48 |
| pstolowski | zyga: the image name will probably change, i will update once cachio has it | 12:48 |
| zyga | cachio: is there a manifest of changes to the bionic image? | 12:48 |
| cachio | zyga, I attached that to the bug | 12:49 |
| cachio | let me see | 12:49 |
| zyga | thanks, let me find it | 12:49 |
| jdstrand_ | Chipaca: hey, fyi, apparmor_parser -p /path/to/profile will show the profile with all the includes in it | 12:49 |
| === jdstrand_ is now known as jdstrand | ||
| zyga | 237-3ubuntu10.31 -> 237-3ubuntu10.29 ? | 12:50 |
| zyga | cachio: can you attach an unified diff before/after | 12:50 |
| zyga | it looks like the diff is after -> before now | 12:50 |
| cachio | zyga, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1852635/+attachment/5305454/+files/bionic-diff.txt | 12:50 |
| mup | Bug #1852635: mount-ns test failing with latest bionic updates <snapd (Ubuntu):Confirmed for stolowski> <https://launchpad.net/bugs/1852635> | 12:51 |
| mborzecki | does https://packages.ubuntu.com/ 500 for you too? | 12:51 |
| cachio | zyga, sure, on sec | 12:52 |
| zyga | thanks | 12:52 |
| zyga | mborzecki: no | 12:52 |
| cachio | zyga, https://launchpadlibrarian.net/452319755/bionic-diff2.txt | 12:53 |
| zyga | unified :) | 12:54 |
| zyga | but ok | 12:54 |
| zyga | unified diffs are easier to read | 12:54 |
| === ricab is now known as ricab|lunch | ||
| cachio | zyga, ahh, ok ,one sec | 12:54 |
| cachio | zyga, https://launchpadlibrarian.net/452319957/bionic-diff-unified.txt | 12:55 |
| zyga | pstolowski: ^ given this can you check if the systemd changelog explains what we are seeing please? | 12:56 |
| zyga | pstolowski: in addition, can you please add a "Fixes: <URL>" line to the commit message, | 12:57 |
| zyga | it helps with tracking things | 12:57 |
| pstolowski | zyga: sure | 12:57 |
| zyga | reviewed now | 12:58 |
| Chipaca | jdstrand: dunno if you saw that forum topic, do we need to tweak /etc/apparmor.d/abstractions/python so people can use core18-based python snaps? | 12:59 |
| Chipaca | jdstrand: using the python from the base i mean | 12:59 |
| pedronis | mvo: I left some initial comments and a question in 7746 | 12:59 |
| jdstrand | Chipaca: I haven't yet, but hope to start my misc policy updates today and can add that to the list of investigations | 13:02 |
| Chipaca | jdstrand: k | 13:02 |
| jdstrand | Chipaca: thanks! | 13:03 |
| pstolowski | zyga: systemd changes looks completely innocent and unrelated, must be something else | 13:16 |
| pstolowski | i looked at debian changelog and patches listed there | 13:17 |
| zyga | pstolowski: would you mind looking at what the cause may be for some more time? I would like to at least know that it's not a mistake that the changes exist | 13:17 |
| pstolowski | yeah i will | 13:17 |
| zyga | pstolowski: perhaps ask foundations for ideas | 13:19 |
| zyga | pstolowski: xnox may know something about this | 13:19 |
| xnox | can i please have context summary? also possibly you want rbalint | 13:24 |
| pstolowski | xnox: sure. we have a pedantic test that checks mount tables and namespaces. it picked changes after latest bionic upgrade, and we'd like to understand if the changes are legit | 13:25 |
| pstolowski | xnox: https://github.com/snapcore/snapd/pull/7756 - see PR description for summary of the changes | 13:25 |
| mup | PR #7756: tests: update mount-ns test for bionic image changes <Created by stolowski> <https://github.com/snapcore/snapd/pull/7756> | 13:25 |
| xnox | it looks harmless, yet it odd | 13:30 |
| xnox | it looks harmless, yet it is odd | 13:30 |
| xnox | there might be CPC image changes too (as in the base image itself, rather than an sru of something) | 13:30 |
| pstolowski | aha | 13:32 |
| pstolowski | cachio: do you know what versions of images we should be comparing? | 13:33 |
| zyga | brb | 13:34 |
| Eighth_Doctor | degville: hey, your CentOS 8 instructions for installing EPEL are can be simplified to just `dnf install epel-release` | 13:37 |
| Eighth_Doctor | for this page, I mean: https://snapcraft.io/docs/installing-snap-on-centos | 13:37 |
| Eighth_Doctor | `epel-release` is in the default repos for CentOS 8 | 13:37 |
| degville | Eighth_Doctor: ah, thank you! I'll update them! | 13:38 |
| cachio | pstolowski, those images are using the same base image | 13:38 |
| pstolowski | uhm | 13:38 |
| cachio | fir older one was created by updating and upgrading one month ago | 13:39 |
| cachio | the newer it was created following the same procedure 1 week ago | 13:39 |
| mborzecki | cachio: pstolowski: zyga: nothing obvious in https://changelogs.ubuntu.com/changelogs/pool/main/s/systemd/systemd_237-3ubuntu10.31/changelog | 13:39 |
| pstolowski | xnox: we also have the list of packages that got updated - https://launchpadlibrarian.net/452319957/bionic-diff-unified.txt - anything worth checking? | 13:40 |
| pstolowski | mborzecki: yes, i checked that too, plus patches in the source package | 13:40 |
| pstolowski | mborzecki: as long as changelos is thruthful about what patches were applied, they look innocent | 13:42 |
| zyga | if it is the cloud images | 13:47 |
| zyga | could it be something that is not a package that is changed there | 13:47 |
| pstolowski | cachio says the base image is the same. that means changes can only come from updated packages afaiu? | 13:52 |
| zyga | that's weird | 13:53 |
| zyga | I don't mean to block you, perhaps ask mvo for advice | 13:53 |
| pstolowski | let's check on standup. if anything, it's blocking bionic update for our tests | 13:54 |
| mvo | zyga: what is this about? | 13:57 |
| zyga | mvo: standup | 13:57 |
| zyga | let's chat there? | 13:57 |
| mvo | zyga: 1min, need to prepare a cup of tea | 13:58 |
| === ricab|lunch is now known as ricab | ||
| mborzecki | zyga: ijohnson: irc or meet? | 14:36 |
| zyga | ijohnson: so I have an idea where we could optimize away snap-update-ns for _some_ snaps | 14:36 |
| zyga | let's do it here | 14:36 |
| zyga | my network is busy today | 14:36 |
| ijohnson | sure works for me | 14:36 |
| zyga | part of the work will involve snap-update-ns working on slightly different basis | 14:36 |
| zyga | and if we can statically detect from snapd that the fstab profile to apply doesn't need sophistication (more on what that means in a moment) | 14:37 |
| zyga | we could implement that in snap-confine like before | 14:37 |
| zyga | sophistication is specifically needing to create mimics | 14:37 |
| zyga | without mimics input profile is the output profile | 14:37 |
| zyga | and we can just execute mounts in order and be done with it | 14:37 |
| zyga | we could detect if mimics are needed with a simulation approach, that plans what it would take to apply a mount profile we generate for a snap | 14:38 |
| zyga | right now we don't know until runtime | 14:38 |
| zyga | last week I was experimenting a little, extending the Assumptions struct with knowledge about the base snap | 14:38 |
| zyga | so that we could simulate application and know if mimic is needed or not | 14:38 |
| zyga | it's a bit hand wave-y at the moment *but* we could optimize away snap-update-ns in many cases, I believe | 14:39 |
| ijohnson | related question: when we preserve a mount ns, does that persist across boots, or is it just valid for the current boot? I think it's not persistent since it's in /run, correct? | 14:39 |
| zyga | ijohnson: no, it's just a memory construct | 14:39 |
| ijohnson | right | 14:39 |
| zyga | it's only in kernel memory | 14:39 |
| zyga | ijohnson: even outside of /run | 14:39 |
| ijohnson | oh right cause it's just a fd got it | 14:40 |
| zyga | it's a nsfs filesystem object we are saving | 14:40 |
| ijohnson | do we create mimics for content interfaces as well as layouts? I think yes? | 14:41 |
| zyga | ijohnson: yes | 14:41 |
| zyga | ijohnson: there's no difference between them | 14:41 |
| ijohnson | hmm I guess I'm not quite following which information we're missing when snap-confine runs that currently we have to wait until runtime for | 14:42 |
| zyga | ijohnson: let's have a call :") | 14:42 |
| zyga | it could be faster than me typing | 14:42 |
| ijohnson | haha ok | 14:43 |
| ijohnson | mborzecki did you want to join as well? | 14:43 |
| zyga | https://meet.google.com/nbn-avuw-zwh?authuser=1 | 14:43 |
| * zyga breaks for lunch | 15:01 | |
| * cachio lunch | 15:03 | |
| ogra | ijohnson, FYI ... https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/mangling.py#L28 | 15:10 |
| ijohnson | ... of course | 15:10 |
| ogra | not sure that is still used though ... but it used to re-write all python shebangs in all python scripts during snap build | 15:10 |
| ogra | (that is why i suggested the change in the forum) | 15:11 |
| ijohnson | well I suggest snapcraft not do that in the name of performance, but perhaps there's a good reason why snapcraft used to do that | 15:12 |
| ogra | yes, because you cant be sure core/core18 has the same interpreter as the snap | 15:12 |
| ogra | (someone might pull python 3.9 from a PPA r whatnot) | 15:12 |
| ogra | but yeah, the performance impact is quite significant ... i noticed that with my little robot arm when i tried to snap some movement scripts (shell wrappers that then call a python script ... the moves got seriously slower) | 15:14 |
| ogra | less than half the speed in the end ... | 15:15 |
| ijohnson | ogra: but even if you pull python 3.9 from a PPA into your snap, you would know that you want your python script to use python 3.9, so you would set that up? | 15:15 |
| ijohnson | i.e. $SNAP/usr/bin/python3.9 or some such | 15:15 |
| ogra | sure, if i only have one .py script and have full control over the upstream source ... | 15:16 |
| ijohnson | do any of your python scripts need to load C libraries? | 15:16 |
| ogra | if you pull in multiple scripts from external parts/sources it gets more tricky | 15:16 |
| ijohnson | err just dynamic libraries in general ? | 15:16 |
| ogra | it might make sense to keep this shebang rewrite but make it configurable ... | 15:17 |
| ijohnson | sure I could see making it configurable | 15:17 |
| ogra | so you can actually give the target shebang in a snapcraft.yaml option | 15:17 |
| ogra | and let it default to /usr/bin/env ... | 15:17 |
| ogra | but thats for the snapcraft team | 15:18 |
| ijohnson | why is the forum so slow now, I know it was updated but it feels like it takes much longer to load just small pages | 15:19 |
| ogra | i use an electron app for the frum ... and noticed wiping all the app cache gets it back to being normally responsive | 15:20 |
| ogra | perhaps try wiping the cache for snapcraft.io in your browser ? | 15:20 |
| ijohnson | hmm good idea | 15:23 |
| mborzecki | ijohnson: missed that, went for lunch | 15:23 |
| ijohnson | mborzecki: np main conclusion was that I was going to do some profiling of snap-update-ns and zyga had some ideas on how to make it quicker | 15:24 |
| zyga | indeed | 15:24 |
| zyga | mborzecki: you didn't miss anything new | 15:25 |
| zyga | mborzecki: we can have another chat about the details that relate to robustness later next week | 15:25 |
| mborzecki | ijohnson: cool, there's a bunch of operations triggered by the themes, wonder if skipping themes snap would show a significant change | 15:25 |
| ijohnson | yeah there is a lot from the themes snap, so that's an interesting thing to try as well | 15:25 |
| ijohnson | though with themes that's only gonna get worse as we get greedy plugs :-( | 15:25 |
| mborzecki | ijohnson: discarding the mount ns and disconnecting the contnt interface should be enough | 15:26 |
| ijohnson | well it's a bit more tricky since the theme interface auto-connects and I'm testing first launch, so there's a bit of caching that the desktop-launch helper does as well that's a bit tedious to cleanup | 15:27 |
| ijohnson | but just removing the plug from snap.yaml is probably sufficient | 15:27 |
| mborzecki | ijohnson: rm -rf ~/snap/gnome-calculator make it pretty much like the first run | 15:28 |
| * pstolowski lunch | 15:28 | |
| zyga | mborzecki: for the purpose of helpers, yes | 15:28 |
| ijohnson | yes but I still think it's a more accurate representation to remove the whole snap and try | 15:28 |
| zyga | ijohnson: you can rm snap user data and discard | 15:28 |
| zyga | ijohnson: it's really a good performance reset method, especially if you drop disk caches | 15:29 |
| zyga | ijohnson: otherwise installation may mask some of that | 15:29 |
| ijohnson | yes I know about all of this, my scripts will delete all of $SNAP_USER_DATA, remove the snap, discard the ns, drop all caches then reinstall and measure performance | 15:29 |
| ijohnson | I just think it's easier to just remove the snap to measure performance data | 15:30 |
| zyga | ijohnson: that's okay but keep the fact that installation absorbs some of first run cost | 15:30 |
| zyga | ijohnson: so you may masking part of the measurement | 15:30 |
| ijohnson | that's my whole point | 15:30 |
| zyga | ijohnson: yes but it's not representative | 15:30 |
| zyga | ijohnson: it depends of what the snap is looking | 15:30 |
| ijohnson | it is representative of a user who runs the software | 15:30 |
| zyga | er | 15:30 |
| zyga | doing | 15:30 |
| zyga | ijohnson: not quite, it's only representative of that snap alone | 15:31 |
| zyga | ijohnson: e.g. presence of install or configure hook will skew results | 15:31 |
| ijohnson | this is why I am doing these tests across multiple different kinds of snaps | 15:31 |
| zyga | ijohnson: this is why I emphasize it matters what happens during installation | 15:31 |
| zyga | ijohnson: to get realistic results neuter install and configure hooks (remove them entirely) | 15:31 |
| ijohnson | yes I understand all of what you're saying and it's all being taken into account, I am taking these things into account | 15:32 |
| zyga | great | 15:32 |
| zyga | ijohnson: looking forward to what you find, let's talk about it tomorrow | 15:33 |
| mborzecki | zyga: ijohnson: looking at both snaps, connecting gnome-platform shouldn't generate many 'actions' in snap-update-ns, so it's just themes really | 15:35 |
| zyga | mborzecki: one thing worth of note | 15:36 |
| mborzecki | and wonder if that's a dynamic cost incurred by actual layout ops, or a static cost due to just forking & running snap-update-ns | 15:36 |
| zyga | mborzecki: is the mimic cost | 15:36 |
| zyga | mborzecki: I think it's both | 15:36 |
| zyga | mborzecki: static cost is fixed and should be good to compare huge layout/content vs empty one that is there so that we fork anyway | 15:37 |
| mup | PR snapd#7757 opened: devicestate: rename ensureSeedYaml -> ensureSeeded <Created by mvo5> <https://github.com/snapcore/snapd/pull/7757> | 15:37 |
| zyga | mborzecki: dynamic cost largely depends on where we mount stuff, as mimic cost varies hugely | 15:37 |
| mborzecki | yeah, we might need to rebind lots of stuff if it hits at the wrong place :/ | 15:37 |
| zyga | yes | 15:38 |
| ijohnson | zyga, mborzecki: just with the measurements I already have, if I run `sudo snap run --shell gnome-calculator -c "echo"` (note the sudo so we are just setting up the per-snap ns and not the per-user ns), then when I run `snap run gnome-calculator`, the time for the first launch of snap-update-ns is 406ms vs 9ms so I really don't think that just forking/execing a go binary is adding that much | 15:44 |
| zyga | ijohnson: hmm? | 15:45 |
| zyga | ijohnson: I could be misunderstanding things | 15:45 |
| zyga | but the first invocation, as root, cached everything | 15:45 |
| zyga | ijohnson: and the second one reused that | 15:45 |
| ijohnson | well the second one had to still do the per-user ns | 15:45 |
| ijohnson | it still ran snap-update-ns | 15:45 |
| zyga | ijohnson: yes but it's running a binary that was just invoked | 15:46 |
| zyga | ijohnson: not saying it's wrong | 15:46 |
| zyga | ijohnson: it would be good to get the SNAP_CONFINE_DEBUG=yes timings | 15:46 |
| ijohnson | I drop all caches between these two runs | 15:46 |
| ijohnson | yes will provide that later, still catching up on some things this morning | 15:46 |
| zyga | ijohnson: that will show us how long it takes to mount everything | 15:46 |
| zyga | ok | 15:46 |
| mborzecki | btw. thinking we could strace it ;) just the mounts | 15:47 |
| mup | PR snapd#7758 opened: devicestate: add reading of modeenv to uc20 firstboot code <Created by mvo5> <https://github.com/snapcore/snapd/pull/7758> | 15:48 |
| mborzecki | ijohnson: zyga: totally unscientific: https://paste.ubuntu.com/p/txq2Z3Zj59/ | 15:50 |
| zyga | that's realistic, cost of crafting a large mimic | 15:51 |
| mborzecki | zyga: ijohnson: https://paste.ubuntu.com/p/STzxjc9htm/ wait4 is really high, is that the deskotp helpers? | 16:01 |
| zyga | dunno | 16:01 |
| zyga | could that be snap-confine waiting for snap-update-ns? | 16:01 |
| zyga | or desktop helpers and their shelly nature | 16:02 |
| mborzecki | zyga: ijohnson: /snap/gnome-calculator/544/snap/command-chain/desktop-launch is at the top when running with --trace-exec, so meh | 16:03 |
| zyga | so that's that | 16:03 |
| zyga | not doing a gazillion mounts would be a good optimization | 16:04 |
| ijohnson | Unclear, the go runtime does do lots of wait4 for it's threads and such | 16:04 |
| zyga | kernel work upstream to get apparmor and overlayfs to talk to each other would remove the need for virtually all of those | 16:04 |
| ijohnson | But also the shell desktop helpers are really slow too | 16:04 |
| * ijohnson has no unread emails, will commence investigations after some toast | 16:05 | |
| === heather is now known as hellsworth | ||
| * ogra sets up his spam filter to re-direct some of the mails to ijohnson so he doesnt run out of mails to read | 16:07 | |
| mup | PR snapd#7758 closed: devicestate: add reading of modeenv to uc20 firstboot code <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7758> | 16:10 |
| mup | PR snapd#7759 opened: devicestate: add reading of modeenv to uc20 firstboot code <Created by mvo5> <https://github.com/snapcore/snapd/pull/7759> | 16:24 |
| mup | PR snapcraft#2814 opened: Remove gsettings from comment in kde extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2814> | 16:29 |
| mup | PR snapd#7760 opened: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7760> | 16:47 |
| jdstrand | zyga: well, 'yes' but we also need the gagillion mounts cause overlayfs in the form needed to play well with LSMs is not in supported kernel versions either | 16:57 |
| jdstrand | (assuming it and apparmor did play well together, which they eventually will) | 16:58 |
| zyga | jdstrand: totally, just as an optimization | 16:58 |
| zyga | (eventually) | 16:58 |
| jdstrand | it will be nice to have that, yes | 16:59 |
| mup | PR snapd#7761 opened: devicestate: make /var/lib/snapd/seed available in install mode <Created by mvo5> <https://github.com/snapcore/snapd/pull/7761> | 17:16 |
| mvo | xnox: I would love to talk about pr #7744 tomorrow, essentially just double checking if the approach works for you etc. maybe we can chat tomorrow morning about this? | 17:18 |
| mup | PR #7744: snap-bootstrap: set expected filesystem labels <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7744> | 17:18 |
| xnox | ok | 17:19 |
| zyga | I'll grab some drinks and be back soon | 17:23 |
| pstolowski | mvo, zyga: i asked cachio to run updated bionic against old 4.15 kernel, and the mount-ns test passed. so it means it's 5.0 kernel indeed | 17:37 |
| pstolowski | xnox: ^ also fyi | 17:37 |
| mvo | pstolowski: thank you! | 17:39 |
| pstolowski | mvo: credit goes to Sergio! | 17:39 |
| pstolowski | mvo: and thanks for hinting at the kernel! | 17:40 |
| === pstolowski is now known as pstolowski|afk | ||
| zyga | pstolowski|afk: thank you | 17:50 |
| cmatsuoka | mvo: what would be a good place to add a kernel cmdline parser? osutil maybe? | 17:53 |
| zyga | cmatsuoka: osutil is becoming dense, perhaps a sub-package? though I believe pedronis has an opinion on that too | 18:34 |
| mvo | cmatsuoka: I think we may not need one actually - please check https://github.com/snapcore/snapd/pull/7760 | 18:46 |
| mup | PR #7760: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7760> | 18:46 |
| mvo | cmatsuoka: this will add the "mode=install" to /var/lib/snapd/modenv | 18:47 |
| mvo | cmatsuoka: AIUI you use the cmdline to get the snapd_recovery_mode? | 18:47 |
| mvo | cmatsuoka: or for something else? if for snapd_recovery_mode modeenv is probably the easiest way | 18:47 |
| cmatsuoka | mvo: yes, it was for snapd_recovery_mode | 18:53 |
| cmatsuoka | mvo: I'll check #7760 | 18:53 |
| mup | PR #7760: snap-bootstrap: write /run/mnt/ubuntu-data/var/lib/snapd/modeenv <Created by mvo5> <https://github.com/snapcore/snapd/pull/7760> | 18:53 |
| mvo | cmatsuoka: https://github.com/snapcore/snapd/pull/7759 is probably slightly simpler | 18:56 |
| mvo | cmatsuoka: it contains just the reading part | 18:56 |
| mup | PR #7759: devicestate: add reading of modeenv to uc20 firstboot code <Created by mvo5> <https://github.com/snapcore/snapd/pull/7759> | 18:56 |
| mvo | cmatsuoka: not yet pedronis approved so be warned :) | 18:56 |
| mvo | cmatsuoka: I added a question in the https://docs.google.com/document/d/1UZm-Eis2p9owBpskuwxPjMqKYHq9zm2hUGP_VD0w9Rw/edit# | 18:59 |
| mvo | cmatsuoka: hopefully this does not block you? | 19:00 |
| cmatsuoka | mvo: don't worry, it doesn't | 19:03 |
| mvo | excellent | 19:05 |
| cmatsuoka | mvo: is there a more direct way to get a gadget MountDir() than getting the snap name and then getting the info from snapstate.CurrentInfo()? | 19:05 |
| mvo | cmatsuoka: I think that's the quickest way currently | 19:07 |
| cmatsuoka | mvo: ok, thanks | 19:07 |
| * cmatsuoka still a bit confused with the data structures | 19:07 | |
| zyga | I've implemented the new systemd thing and it seems to be okay | 19:18 |
| zyga | I'll try to propose it tomorrow, there are a few details I want to get nicer before I open it so nothing tonight | 19:18 |
| zyga | I'll call it a day | 19:19 |
| zyga | see you all tomorrow | 19:19 |
| ijohnson | have a good evening zyga! | 19:31 |
| mup | PR snapd#7702 closed: tests: adding fedora 31 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7702> | 20:02 |
| mup | PR snapcraft#2815 opened: minor developer env/doc updates <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2815> | 20:12 |
| ijohnson | hey kenvandine, are you a good person to ask about gnome snaps such as gnome-calculator? | 20:24 |
| kenvandine | ijohnson: yes | 20:24 |
| kenvandine | however i'm not really here today :) | 20:24 |
| kenvandine | i'm off and about to run out to pick up kids | 20:25 |
| ijohnson | ah ok, is there someone who is really here who might know more? | 20:25 |
| kenvandine | hellsworth maybe | 20:25 |
| kenvandine | or marcustomlinson in #ubuntu-desktop | 20:25 |
| kenvandine | ijohnson: or i can help tomorrow | 20:25 |
| ijohnson | ack I'll see if anybody in ubuntu-desktop can help, otherwise I'll catch you tomorrow | 20:26 |
| ijohnson | thanks! | 20:26 |
| marcustomlinson | I'm barely here | 20:26 |
| marcustomlinson | :P | 20:26 |
| kenvandine | marcustomlinson: oh... tab complete didn't find you :) | 20:26 |
| kenvandine | thanks | 20:26 |
| * kenvandine runs out | 20:26 | |
| ijohnson | haha, well I'll just throw out my question in ubuntu-desktop anyways | 20:26 |
| hellsworth | ijohnson: what's your question | 20:26 |
| hellsworth | i can try to help | 20:26 |
| hellsworth | either here or in ubuntu-desktop | 20:27 |
| hellsworth | actually, ubuntu-desktop is prob best | 20:27 |
| kyrofa | zyga, I know you're probably out but maybe I can catch you in the morning: do you have any clues about this? https://bugs.launchpad.net/snapd/+bug/1847673 | 22:35 |
| mup | Bug #1847673: Nextcloud snap auto-updated a few days ago. Since then, I've had 100% CPU use by snapfuse. <snapd:Invalid> <https://launchpad.net/bugs/1847673> | 22:35 |
| kyrofa | I'm getting more reports of it for Nextcloud, and I'm the one who told them to file against snapd. snapfuse is just uncompressing the snap, right? Why should it be eating so much CPU? Is there something the snap could be doing to cause it? | 22:36 |
| mup | PR snapd#7762 opened: Core 20 install mode handling <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7762> | 22:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!