| mup | PR snapd#8429 opened: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429> | 03:39 |
|---|---|---|
| mborzecki | morning | 05:40 |
| mborzecki | mvo: hey | 06:20 |
| zyga | Hey | 06:21 |
| zyga | Please merge my last PR into master and merge master into your branches. | 06:21 |
| mborzecki | zyga: hey | 06:21 |
| jamesh | zyga: here's a simple one porting another job off Travis: https://github.com/snapcore/snapd/pull/8429 | 06:22 |
| mup | PR #8429: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429> | 06:22 |
| mborzecki | zyga: which one is that? this one https://github.com/snapcore/snapd/pull/8428 | 06:22 |
| mup | PR #8428: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428> | 06:22 |
| mborzecki | jamesh: thanks! | 06:22 |
| jamesh | zyga: also, I'm not convinced that the use of actions/cache@v1 for the apt cache actually works | 06:23 |
| jamesh | (the way it is written, I don't think it will ever get a cache hit) | 06:23 |
| zyga | That one | 06:23 |
| zyga | jamesh: I noticed | 06:24 |
| zyga | Something is off | 06:24 |
| zyga | Do you know what the issue is? | 06:24 |
| mvo | hey mborzecki, good morning | 06:24 |
| mborzecki | jamesh: quick question about gtk2, we have gtk2-common-themes snap, but one would still need the right theme engine to render those, isn't that right? | 06:25 |
| mborzecki | jamesh: asking in the context of https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3 which looks like the snap plugs gtk2-common-themes, but when starting there's a log about missing pixbuf engine to render the adwaita-like theme with gtk2 | 06:26 |
| jamesh | zyga: ah. you're doing the chown on /var/cache/apt after calling actions/cache, so the action does not have permission to write to that location | 06:28 |
| zyga | Mmmmm | 06:29 |
| zyga | So we need two chowns | 06:30 |
| jamesh | zyga: It's not obvious that it is a good use of caching anyway: the cache key you're using doesn't specify exact revisions of packages, so each user could be testing against a different set of packages | 06:30 |
| zyga | Or update the action to a version that fixed this and uses sudo | 06:30 |
| zyga | We rarely rev our dependencies | 06:30 |
| jamesh | mborzecki: gtk2-common-themes only contains theme engines. We left the actual theme data files in gtk-common-themes, since most GTK 2 themes are distributed beside their GTK 3 counterpart these days | 06:31 |
| zyga | So it is not a perfect set but a sufficient set | 06:31 |
| mborzecki | jamesh: so gtk2-common-themes is effectively dead? | 06:31 |
| jamesh | mborzecki: no. You need theme data files plus any engines the theme uses | 06:32 |
| jamesh | mborzecki: this is also a split between platform independent data files (gtk-common-themes), and platform dependent engines (gtk2-common-themes) | 06:32 |
| jamesh | maybe we should have named the second package gtk2-common-engines | 06:33 |
| jamesh | zyga: It might also be a good idea to combine some of the spread tests back into fewer jobs: it's nice not having mingled output, but we're obviously hitting Github's runner limits now | 06:39 |
| zyga | jamesh: I will surely consider that but over weekend we also hit limits on our account in GCE | 06:40 |
| zyga | now that we actually run spread when we push stuff | 06:40 |
| zyga | we run out of capacity quickly | 06:40 |
| zyga | we need to measure and count and decide | 06:40 |
| mborzecki | jamesh: hmm so the gtk2-common-themes engines part content is connected, the snap sets GTK_PATH in meta/snap.yaml, but once the process runs GTK_PATH is set to a different path :/ looks like it's coming from desktop-launch | 06:41 |
| * zyga breakfast | 06:45 | |
| mborzecki | jamesh: looks like GTK_PATH ends up without the location where the engines from gtk2-common-themes snap are, i added a note under https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3 | 06:48 |
| mvo | zyga: when you have a moment, a look/merge of https://salsa.debian.org/debian/snapd/-/merge_requests/5 would be great | 06:56 |
| mborzecki | ehh 1080p is such a downgrade from 4k | 06:58 |
| zyga | o/ | 06:58 |
| zyga | at my desk | 06:58 |
| zyga | mvo: looking | 06:58 |
| zyga | mborzecki: display change? | 06:59 |
| pstolowski | morning | 06:59 |
| mborzecki | zyga: yeah, had to rma the 4k one, so i'm using my old 1080p display now | 06:59 |
| mvo | zyga: not ugent but it will bring the packaging git trees in sync again | 07:00 |
| mborzecki | pstolowski: hey | 07:00 |
| zyga | ta | 07:00 |
| zyga | good morning pawel | 07:00 |
| mborzecki | zyga: which is ironic, since it's also lg, 10+ years and not a single bad pixel | 07:00 |
| zyga | hmm, salsa doesn't load for me, feels like none of the JS bits are getting loaded | 07:00 |
| zyga | mvo: commits 8482? is this bundled with development history? | 07:03 |
| zyga | (this explains why js is slow to load) | 07:04 |
| mvo | zyga: yes, I think that's how we setup our branch | 07:05 |
| mvo | zyga: it contains all the history | 07:05 |
| zyga | ta | 07:05 |
| mvo | zyga: TBH i have no idea why this style is popular, I think it's kinda useless | 07:06 |
| zyga | maybe easier for cherry picking patches | 07:07 |
| zyga | libzt uses separate history | 07:07 |
| zyga | anyway | 07:07 |
| zyga | approved | 07:07 |
| mup | PR snapd#8430 opened: packaging: use debian/not-installed to ignore snap-preseed <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8430> | 07:07 |
| zyga | mvo: I see you have two more extra PRs there | 07:08 |
| zyga | but I guess they are obsolete now | 07:08 |
| zyga | mvo: closed both, please shout at me if I was meant to land them instead | 07:09 |
| mvo | zyga: probably fine, I forgot those | 07:10 |
| mvo | zyga: that was when we were not directly involved I think | 07:10 |
| zyga | aha | 07:10 |
| zyga | looking at 8430 | 07:10 |
| zyga | do you know what's broken in our sid tests? | 07:10 |
| zyga | mvo: can you review and land https://github.com/snapcore/snapd/pull/8428 please | 07:11 |
| mup | PR #8428: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428> | 07:11 |
| zyga | it will prevent random failures on centos 7 | 07:11 |
| zyga | looking at this branch I also wonder if we should do a pass and review the timers and background services in our images | 07:11 |
| zyga | who knows what else is randomly running | 07:11 |
| mvo | zyga: yeah, I have a look soon, just need to finish my current task | 07:12 |
| zyga | thanks | 07:12 |
| mvo | zyga: is there anything like "skip-spread" in the new gh-actions world? just an idle thought | 07:13 |
| zyga | mvo: not yet, we can certainly code it | 07:13 |
| zyga | actions has enough logic for it | 07:13 |
| zyga | https://github.community/t5/GitHub-Actions/Labeled-action-on-pull-request/m-p/37839#M3093 has some ideas | 07:14 |
| zyga | we can just get the context as a json object, select the labels and skip the whole spread part if a particular one is set | 07:14 |
| zyga | mvo: if it's not urgent I'll do it in the evening | 07:14 |
| zyga | actually | 07:15 |
| mvo | zyga: nice, not urgent at all | 07:15 |
| zyga | https://stackoverflow.com/questions/59588605/how-to-check-for-a-label-in-a-github-action-condition | 07:15 |
| zyga | is even easier | 07:15 |
| zyga | if: contains( github.event.pull_request.labels.*.name, 'My Label') | 07:15 |
| zyga | we could just do | 07:15 |
| zyga | if: !contains( github.event.pull_request.labels.*.name, 'Skip Spread') | 07:15 |
| mup | PR snapd#8428 closed: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8428> | 07:16 |
| zyga | thanks for that mvo ^ ! | 07:16 |
| zyga | pstolowski, jamesh, mborzecki, mvo: gentle reminder to merge master into any branches you push or iterate on | 07:17 |
| zyga | mainly to get the fail-fast: false part | 07:17 |
| pstolowski | ack | 07:17 |
| zyga | I will share details at the standup | 07:17 |
| pedronis | mvo: pstolowski: hi, I would appreciate reviews for https://github.com/snapcore/snapd/pull/8427 it's huge but is splitting files up basically, except for reorganizing things such that we can have mutiple store* test suites | 07:22 |
| mup | PR #8427: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427> | 07:22 |
| zyga | over weekend I noticed the ubuntu archive was failing again, I reported this to IS but they asked for more details. If this happens frequently we should cook a patch that prints the IP address of the node in case "apt-get *" fails | 07:23 |
| pstolowski | pedronis: sure, will do | 07:23 |
| mvo | pedronis: ok, thanks, I have a look. so this is no code change, just reorg? | 07:38 |
| pedronis | mvo: yes | 07:38 |
| pedronis | mvo: description and commit summary should hopefully be understandable | 07:40 |
| mvo | ta | 07:40 |
| mborzecki | mvo: can you take another look at https://github.com/snapcore/snapd/pull/8415 ? | 07:42 |
| mup | PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415> | 07:42 |
| mvo | mborzecki: sure thing! | 07:43 |
| mborzecki | mvo: thanks! | 07:43 |
| mborzecki | hehe firefox chokes on the full diff in #8427 | 07:48 |
| mup | PR #8427: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427> | 07:48 |
| zyga | brb | 07:51 |
| mvo | fwiw, I updated the branch protection rules for master so that all stable gh actions need to be successful | 07:55 |
| jamesh | The GH Actions workflow should probably also be updated to run on pushes to master and release branches. At present, only the unit tests are being run for pushes to master | 08:31 |
| zyga | re | 08:48 |
| zyga | jamesh: we had something similar but I agree, we wanted not to test a push and a PR at the same time | 08:48 |
| zyga | jamesh: but I think we should do tests on PRs for both master and release branches | 08:48 |
| mup | PR snapd#8431 opened: github: give jobs shorter names <Created by zyga> <https://github.com/snapcore/snapd/pull/8431> | 08:53 |
| mup | PR snapd#8427 closed: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8427> | 09:04 |
| pedronis | mvo: mborzecki: thanks | 09:08 |
| mup | PR snapd#8218 closed: [RFC] cmd/snapd, daemon/snapd: use multi call binary <â›” Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8218> | 09:14 |
| mup | Bug #1871058 opened: Tell how many bytes "install" will take <Snappy:New> <https://launchpad.net/bugs/1871058> | 09:16 |
| mup | Bug #1871060 opened: Don't hide each step after it completes <Snappy:New> <https://launchpad.net/bugs/1871060> | 09:19 |
| mup | PR snapd#8432 opened: travis.yml: disable unit tests on travis <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8432> | 09:28 |
| pedronis | #8411 needs 2nd reviews | 09:32 |
| mup | PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411> | 09:32 |
| zyga | jamesh: https://github.com/snapcore/snapd/pull/8429#issuecomment-609683448 | 09:33 |
| mup | PR #8429: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429> | 09:33 |
| zyga | mvo: https://github.com/snapcore/snapd/pull/8432#pullrequestreview-388082166 | 09:34 |
| mup | PR #8432: travis.yml: disable unit tests on travis <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8432> | 09:34 |
| mborzecki | hmm seems like ijohnson's standup notes were cut short or he didn't manage to publish the snapd branch of grub.cfg on friday | 09:36 |
| mvo | zyga: thanks, replied | 09:38 |
| zyga | mvo: I replied twice there, weird stuff | 09:39 |
| zyga | I think we are leaking session from tests/main/snap-session-agent-service-control | 09:42 |
| zyga | they break tests/main/snap-confine-undesired-mode-group | 09:43 |
| mborzecki | pedronis: mvo: looking into adding 'recover' and 'run' modes into system actions, and actually i'm wondering a bit about run, it doesn't make sense to have run for other system than current, does it? | 09:47 |
| pedronis | mborzecki: no, it's only for current | 09:49 |
| pedronis | we discussed that in Frankfurt | 09:50 |
| mborzecki | pedronis: ok, let me check the notes | 09:50 |
| mvo | mborzecki: +1 - nly relevent for current | 09:50 |
| mborzecki | mvo: pedronis: doesn't look like we put that down in the notes, nevertheless i take that recover applies to the current system only too | 10:05 |
| jamesh | zyga: that seems like a good idea, especially since we can't use the job as a prereq for jobs that should run on pushes | 10:11 |
| zyga | +1 | 10:11 |
| jamesh | zyga: the macos test should be fairly easy to move over to GH Actions too. At that point, the main thing the Travis job is doing is coverage | 10:12 |
| zyga | yeah | 10:12 |
| zyga | the test coverage provider we use has a dedicated action IIRC - we could adopt it | 10:13 |
| jamesh | and codecov's first party action also downloads and executes a shell script... | 10:19 |
| zyga | of course it does :) | 10:19 |
| zyga | brb | 10:26 |
| zyga | re | 10:55 |
| mborzecki | zyga: hm that centos7 session-tool restore is still failing | 11:17 |
| mborzecki | and travis is green fwiw | 11:17 |
| zyga | mborzecki: same was as you showed me? | 11:18 |
| mborzecki | yeah | 11:18 |
| zyga | session that was running before the test closes during the test | 11:18 |
| zyga | ok, I'll switch gears to that in a moment | 11:18 |
| zyga | ta | 11:18 |
| mborzecki | tbh making gh actions spread jobs as require feels a bit premature | 11:18 |
| zyga | why? | 11:19 |
| zyga | note that travis doesn't run spread anymore | 11:19 |
| mborzecki | zyga: bc we cannot restart just one job | 11:20 |
| zyga | I see | 11:20 |
| zyga | I disagree but I wanted to understand | 11:20 |
| zyga | note that we can collapse all spread runs into one big run | 11:20 |
| zyga | and have that instea | 11:20 |
| zyga | *instead | 11:20 |
| mborzecki | zyga: that'd make it the same as it is now | 11:23 |
| zyga | we've traded ability to restart half the workers for being able to get tests started faster | 11:24 |
| zyga | (and having control over how many workers we can run) | 11:24 |
| morphis | mvo: hey! do you guys saw issues with a not existing /run/snapd-snap.socket on configure hook execution recently? Running quite frequently into https://paste.ubuntu.com/p/qQGSQjRjM7/ with snapd 2.44.1 | 11:25 |
| morphis | to be precise, snapd isn't restart and was active all time. | 11:27 |
| zyga | morphis: what is the status of the socket? | 11:27 |
| zyga | I suspect it's in CI but perhaps you know | 11:27 |
| morphis | I have a shell active so happy to debug | 11:28 |
| zyga | please start with systemctl status snapd.socket | 11:28 |
| morphis | zyga: socket is active and happy for >1h | 11:28 |
| zyga | morphis: both? | 11:28 |
| zyga | Listen: /run/snapd.socket (Stream) | 11:29 |
| zyga | /run/snapd-snap.socket (Stream) | 11:29 |
| zyga | ^ that's what I get on my box | 11:29 |
| morphis | https://paste.ubuntu.com/p/phZ4H7SGXb/ | 11:29 |
| morphis | jepp, same here | 11:29 |
| zyga | ok | 11:29 |
| zyga | and is /run/snapd-snap.socket really there on disk? | 11:29 |
| morphis | yes, touched an hour ago | 11:29 |
| zyga | ok | 11:29 |
| zyga | can you jump into the mount namespace of lxd | 11:29 |
| zyga | and then check if the socket is there | 11:29 |
| zyga | sudo nsenter -m/run/snapd/ns/lxd.mnt | 11:30 |
| zyga | this will give you a shell in the mount namespace of lxd | 11:30 |
| zyga | just check if the sockets are there as well | 11:30 |
| morphis | yes, exists there too | 11:31 |
| zyga | can you CURL to it? | 11:31 |
| zyga | or maybe instead | 11:31 |
| zyga | can you snapctl to it? | 11:31 |
| morphis | ah, I think I know what happens here | 11:33 |
| morphis | it's a race between `snap install lxd` and `snap set ..` | 11:34 |
| morphis | something we should prevent from the charm side | 11:34 |
| morphis | that matches with the dates the socket within the lxd ns is created and the snap got installed and the last time the error occurred in the juju output | 11:35 |
| zyga | morphis: cool | 11:37 |
| zyga | morphis: are you saying lxd doesn't really work after snap install lxd | 11:37 |
| zyga | in the sense that snap set is invoked too early? | 11:37 |
| mup | PR snapd#8433 opened: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433> | 11:37 |
| morphis | it looks like we invoke `snap set` while performing `snap install` | 11:38 |
| zyga | as in during? | 11:38 |
| zyga | yeah that would not work | 11:38 |
| morphis | jepp | 11:38 |
| morphis | makes sense that it doesn't work | 11:38 |
| morphis | zyga: is there a simple `snap wait-until-install lxd` thing? | 11:40 |
| zyga | I don't think there is | 11:40 |
| morphis | ok | 11:41 |
| ogra | well, the configure hook runs after install | 11:42 |
| ogra | perhaps move your stuff over to it ? | 11:42 |
| mborzecki | morphis: hmm snap watch --last=install? could work | 11:42 |
| morphis | mborzecki: interesting | 11:42 |
| mborzecki | morphis: though it's still racy, since you'd expect the install to be started already to watch it | 11:44 |
| zyga | morphis: may I ask how do you run the two operations concurrenctly? | 11:44 |
| morphis | zyga: it's a problem in our charms I can fix on that level, was just looking for a hotfix | 11:48 |
| zyga | I see | 11:48 |
| zyga | ok | 11:48 |
| zyga | mborzecki: testing a fix for what you found now | 11:54 |
| mborzecki | zyga: cool thanks | 11:54 |
| zyga | cachio: hey | 11:55 |
| zyga | cachio: are you around? | 11:55 |
| cachio | zyga, yes | 11:55 |
| cachio | hi | 11:55 |
| zyga | hey | 11:55 |
| ijohnson | hey mborzecki sorry I didn't finish putting the snapd branch for grub.cfg things in the SU doc | 11:57 |
| ijohnson | I just put it in there if you wanted to take a look, it's quite simple | 11:57 |
| mborzecki | ijohnson: no biggie, i worked on adding the recovery/run modes to devicemgr | 12:05 |
| mup | PR snapd#8431 closed: github: give jobs shorter names <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8431> | 12:08 |
| * zyga breaks for a moment, | 12:10 | |
| zyga | mborzecki: I've started reviewing 8433 | 12:11 |
| mborzecki | zyga: thanks | 12:15 |
| ijohnson | hi pedronis did you have a chance to look at how I organized things in #8424 at all ? | 12:16 |
| mup | PR #8424: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8424> | 12:16 |
| mup | PR snapd#8434 opened: systemd: move the doc comments to the interface so their are visible <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8434> | 12:17 |
| pedronis | pstolowski_: ^ | 12:17 |
| pedronis | ijohnson: I skimmed it, I didn't see anything unreasonable... but there's some comments about details from others | 12:20 |
| ijohnson | pedronis: ok, sure I will continue on with it | 12:21 |
| ijohnson | pedronis: I just didn't know if you would have opinions on having stuff in the boot package vs in the partition package of snap-bootstrap, etc. | 12:21 |
| ijohnson | pedronis: I assume you will have opinions on the names of things and that's fine to rename later :-) | 12:21 |
| * zyga breaks for lunch, see you soon | 12:28 | |
| mup | PR snapcraft#3013 closed: plugins: use v1 import path for all plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3013> | 12:29 |
| mup | PR snapcraft#3014 opened: meta: migrate get_build_base to Snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3014> | 12:38 |
| ijohnson | hey ogra, is your zoom-client snap supposed to work with nvidia drivers? I tried it with 440 drivers on Sunday and it crashed on me | 12:50 |
| mup | PR snapd#8430 closed: packaging: use debian/not-installed to ignore snap-preseed <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8430> | 12:51 |
| mup | PR snapd#8432 closed: travis.yml: disable unit tests on travis <Simple 😃> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8432> | 12:51 |
| ogra | ijohnson, works gret with everything but nvidia-440 | 13:34 |
| ogra | *great even | 13:34 |
| ogra | ijohnson, https://github.com/ogra1/zoom-snap/issues/2 | 13:35 |
| diddledan | is this an issue with the 440 drivers in general with snaps? | 13:36 |
| ogra | due to the awful nature of the zoom binary (forcefully setting LD_LIBRARY_PATH to ./zoom (and ./zoom only) on app startup) i actually need to LD_PRELOAD the drivers ... and -440 somehow refuses to load libOpenGL.so for no apparent reason | 13:37 |
| ogra | diddledan, there used to be one but zyga has fixed that ... i asked people to try snapd from edge but that didnt help | 13:37 |
| ijohnson | ogra: ack I can try with 390 or 435 then instead | 13:37 |
| ogra | -400 has a new directory structure and seemingly the linkage between the libs is differet | 13:37 |
| ogra | err | 13:38 |
| ogra | -440 indeed | 13:38 |
| diddledan | aah, yeah, I see that message now on https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/15 - I must have overlooked it | 13:39 |
| ogra | right ... but that is supposed to be fixed | 13:39 |
| diddledan | gotcha :-) | 13:39 |
| * diddledan goes snooping to see what the fix was | 13:39 | |
| ogra | and according to the logs users actually have the proper content in /var/lib/snapd/lib/gl ... | 13:39 |
| ogra | so it is something with the LD_PRELOAD load order that i need to research to get t going (but for that i need a system that runs -440 ... my nvidia equipped desktop is still on 16.04 for which that driver doesnt exist) | 13:40 |
| diddledan | I just took my nvidia card out to move it into my plex server | 13:41 |
| diddledan | I now have reasonable transcoding on the fly for plex though, so WINNING | 13:41 |
| ogra | but you cant use zoom-client on it ! | 13:42 |
| ogra | :D | 13:42 |
| diddledan | I had to install the deb variant of plex though. something in the snap config is unable to do hardware transcoding | 13:42 |
| zyga | mvo: so I guess this means you approve of my incoming valve index :D | 13:43 |
| zyga | and on the upside - everyone can then test on their nvidia GPUs | 13:43 |
| mvo | zyga: haha | 13:43 |
| zyga | man, we will catch all the bugs this way | 13:43 |
| ijohnson | the quality of nvidia support will skyrocket after this happens | 13:43 |
| zyga | snapd: add half life alyx support | 13:43 |
| zyga | snapd: fix level 3, achievement #42 | 13:43 |
| diddledan | I vote for leaving a few gotchas to keep the users on their toes | 13:44 |
| zyga | snapd: fix 2nd playthrough ... | 13:44 |
| zyga | ;-) | 13:44 |
| mup | PR #42: rework filelock to make it less surprising wrt flock(2) semantics <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/42> | 13:44 |
| mup | PR core20#35 opened: run-snapd-from-snap: log first snap watch better <Created by xnox> <https://github.com/snapcore/core20/pull/35> | 13:53 |
| mup | Issue core20#36 opened: SSH login shell says the system was minimized and to run "unminimize", but should not <Created by anonymouse64> <https://github.com/snapcore/core20/issue/36> | 13:55 |
| mup | PR pc-amd64-gadget#38 closed: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/38> | 13:56 |
| kenvandine | jdstrand: where's the trello card for the appstream-metadata inteface fixes? I want to link it to mine card, but must be looking at the wrong board | 14:00 |
| mup | Issue pc-amd64-gadget#41 opened: Hide the menu by default <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/issue/41> | 14:24 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/8433#pullrequestreview-388194361 | 14:30 |
| mup | PR #8433: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433> | 14:30 |
| zyga | mvo: I wonder if we should add some of my hosted workers to the pool | 14:39 |
| zyga | to spread the load | 14:39 |
| ogra | spread the spread ? | 14:40 |
| zyga | exactly | 14:40 |
| jdstrand | kenvandine: hey, I privmsg'd you | 14:50 |
| zyga | jdstrand: hello :) | 14:57 |
| zyga | jdstrand: thank you for the review from Friday | 14:57 |
| jdstrand | sure, I need to finish and followup | 14:57 |
| zyga | jdstrand: the tracking PR will be ready soon, there's a core20 issue still, where some packages related to dbus are missing, but it should be ready soon | 14:57 |
| jdstrand | and hi | 14:57 |
| jdstrand | ok | 14:57 |
| zyga | jdstrand: not end of the story but looking like something we could look at merging soon | 14:57 |
| zyga | jdstrand: I'll spend some more time on your feedback tomorrow, today I'm trying to wrap up that core20 problem first | 14:58 |
| jdstrand | great! :) | 14:59 |
| * cachio lunch | 15:02 | |
| mup | PR snapd#8435 opened: configcore,tests: fix setting watchdog options on UC18/20 <Created by pedronis> <https://github.com/snapcore/snapd/pull/8435> | 15:06 |
| jdstrand | mvo: hey, so it sounds like you will roll another 2.44 point release for some policy updates? | 15:13 |
| mvo | jdstrand: if it's just safe policy updates I can do that | 15:14 |
| mvo | jdstrand: at this point I want to keep the risk minimal | 15:14 |
| jdstrand | mvo: is later today ok? | 15:14 |
| mvo | jdstrand: yeah | 15:14 |
| jdstrand | ok, I'll do a couple low risk PRs then | 15:15 |
| jdstrand | I'll target 2.44, 2.45 and master | 15:15 |
| mvo | jdstrand: or in my morning tomorrow | 15:15 |
| mvo | jdstrand: ok | 15:15 |
| mvo | jdstrand: 2.44 and master is fine, 2.45 is not branched yet | 15:15 |
| jdstrand | mvo: ah, ok, thanks | 15:22 |
| * zyga runs an errand in the office | 15:35 | |
| roadmr | running in place, zyga? 🤔 | 15:36 |
| zyga | roadmr: mainly cleaning and that one box that's open because a cable went loose and I need to solder the power switch back on | 15:36 |
| diddledan | just rebooted.. getting: `cannot change profile for the next exec call: No such file or directory \n snap-update-ns failed with code 1: File exists` from running _any_ snaps | 15:37 |
| zyga | diddledan: I think we debugged that recently | 15:38 |
| zyga | diddledan: can you please collect your journal and pastebin it | 15:38 |
| zyga | diddledan: to fix your machine restart apparmor.service | 15:38 |
| zyga | diddledan: it's *not* fixed though | 15:38 |
| zyga | popey: ^ can you recall if you reported that on launchpad? | 15:38 |
| diddledan | is this enough journal, or more needed? https://paste.ubuntu.com/p/RBc2r4xqJY/ | 15:43 |
| mup | PR snapd#8436 opened: configcore,tests: use daemon-reexec to apply watchdog config <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436> | 15:44 |
| diddledan | this is everything for this boot: https://paste.ubuntu.com/p/Jyx6gfFc3q/ | 15:44 |
| zyga | diddledan: looking | 15:45 |
| zyga | diddledan: when you said "just rebooted", roughly what time was there for you? | 15:46 |
| zyga | is that the start of your log? | 15:46 |
| diddledan | I used journalctl --no-pager -b | pastebinit | 15:46 |
| zyga | ok, so 16:32~~ | 15:46 |
| diddledan | yup | 15:47 |
| mborzecki | /quit/quit | 15:47 |
| zyga | so I see | 15:47 |
| zyga | Apr 06 16:32:58 defiant lxd.activate[3329]: cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_Iq23MU//dev: No such file or directory | 15:47 |
| zyga | 16:32:58 - we use snaps already | 15:47 |
| zyga | and then Apr 06 16:35:02 defiant audit[12031]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.lxd.daemon" pid=12031 comm="apparmor_parser" | 15:47 |
| zyga | at 16:35 we load the releated profile | 15:48 |
| zyga | FYI: stgraber ^ (lxd runs before apparmor profiles of snapd are loaded) | 15:48 |
| zyga | diddledan: please report a bug "services start before apparmor profiles are loaded" | 15:48 |
| zyga | we have a race | 15:48 |
| diddledan | ok | 15:48 |
| zyga | include this journal if you don't mind, please highligh the two lines I mentioned above | 15:48 |
| zyga | popey: ^ if you reported a bug this this is a dupe, if not please track the one diddledan will open | 15:48 |
| zyga | mvo: ^ FYI | 15:48 |
| zyga | mvo: system startup races startup of services and apparmor.service loading profiles | 15:49 |
| zyga | mvo: observed for LXD here and for a lot of snaps (half of stuff IIRC) on popey's laptop | 15:49 |
| zyga | FYI: ^ jdstrand | 15:49 |
| zyga | though not a security issue, more a "it doesn't work" issue | 15:49 |
| zyga | diddledan: can you confirm that restarting apparmor.service fixed the issue? | 15:51 |
| diddledan | yes, restarting apprmor fixes it - I've put that info in the bug: #1871148 | 15:53 |
| mup | Bug #1871148: services start before apparmor profiles are loaded <snapd:New> <https://launchpad.net/bugs/1871148> | 15:53 |
| zyga | thank you | 15:53 |
| pedronis | #8390 and #8411 need 2nd reviews | 16:04 |
| mup | PR #8390: state: add state.CopyState() helper <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390> | 16:05 |
| mup | PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411> | 16:05 |
| stgraber | zyga: oh, interesting, good that it's not something I have to fix for once ;) | 16:10 |
| zyga | stgraber: yeah, in case someone comes along and says this is broken on their fast server, it's on ous | 16:11 |
| zyga | *us | 16:11 |
| diddledan | #blamepopey | 16:16 |
| * zyga hugs popey | 16:18 | |
| popey | sorry, been in meetings | 16:18 |
| * popey confirmificates the bug | 16:19 | |
| * diddledan watching terminiser black inevitibility | 16:20 | |
| mup | PR core20#35 closed: run-snapd-from-snap: log first snap watch better <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/pull/35> | 16:26 |
| mup | PR snapd#8437 opened: tests/session-tool: collect information about services on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/8437> | 16:28 |
| mup | PR snapd#8438 opened: tests/session-tool: stop anacron.service in prepare <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8438> | 16:29 |
| mvo | zyga: uh, is this a new thing? | 16:31 |
| zyga | mvo: no | 16:32 |
| jdstrand | mvo, zyga: https://bugs.launchpad.net/snapd/+bug/1871148/comments/6 | 16:32 |
| mup | Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148> | 16:32 |
| zyga | jdstrand: isn't that the message that is printed from /etc/apparmor.d | 16:32 |
| zyga | there's a separate one for /var/... | 16:32 |
| zyga | IIRC | 16:32 |
| * zyga checks | 16:32 | |
| jdstrand | zyga: what are you talking about? | 16:33 |
| mvo | zyga: if it's not new I wonder why it's happening now? | 16:33 |
| jdstrand | zyga: 'Finished loading...'? | 16:33 |
| mvo | jdstrand: should we have an "After=apparmor" in all our snaps? | 16:33 |
| zyga | please forgive me for being unclear, let me check and show | 16:33 |
| jdstrand | mvo: please see my comment | 16:33 |
| jdstrand | mvo: apparmor was already finished. something else seems to be going on | 16:34 |
| mvo | oh, ok | 16:34 |
| ijohnson | mvo will there be a 2.44.3 ? | 16:35 |
| mvo | zyga: it can't be snapd rebuilding the profiles, right? we stop/disable services before we do that iirc | 16:35 |
| ijohnson | $CUSTOMER would like https://github.com/snapcore/snapd/pull/8426 asap, but not like super asap | 16:35 |
| mup | PR #8426: interfaces/docker-support: add overlayfs file access <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8426> | 16:35 |
| mvo | ijohnson: yes, jdstrand needs some interface updates | 16:35 |
| zyga | mvo: this is during system boot | 16:35 |
| ijohnson | mvo: ack cool this is just an interface update too | 16:35 |
| mvo | ijohnson: yeah | 16:36 |
| ijohnson | thanks mvo! | 16:36 |
| jdstrand | oh, that was in my list for today. thanks :) | 16:36 |
| jdstrand | ijohnson: note, for the other policy updates, mvo asked me to target 2.44 too. can you do the same? | 16:37 |
| ijohnson | jdstrand: mvo already milestonned 8426 to 2.44 | 16:37 |
| ijohnson | jdstrand: or did you mean to open a release/2.44 PR for 8426 ? | 16:37 |
| jdstrand | ijohnson: the latter | 16:38 |
| * ijohnson didn't open a 2.44 PR, but can if desired | 16:38 | |
| ijohnson | ok, I will open a 2.44 PR then | 16:38 |
| mvo | ijohnson: if it's just a cherry pick I can do that, no need for a PR then | 16:38 |
| ijohnson | zyga: we have to restart all github actions jobs, right? we can't just restart one ? | 16:38 |
| zyga | correct | 16:38 |
| ijohnson | mvo: ok I think a cherry pick should be fine it's literally 1 line change | 16:38 |
| ijohnson | ok, thanks zyga | 16:39 |
| mvo | ijohnson: ta, just let me know when i landed and I cherry pick (or feel free to just cherry-pick yourself) | 16:39 |
| mvo | ijohnson: 8426? | 16:39 |
| mvo | ijohnson: I think that is green, I can merge now | 16:39 |
| ijohnson | mvo: oh | 16:39 |
| ijohnson | mvo: it wasn't green there was a spread failure for nfs-support, which is unrelated | 16:40 |
| mvo | ijohnson: yeah, I will merge anyway | 16:40 |
| ijohnson | mvo: I just restarted them, but I suppose you could use your magic powers to merge anyways | 16:40 |
| mvo | ijohnson: sorry, I meant "green" as in "green-enough" | 16:40 |
| ijohnson | :-D | 16:40 |
| zyga | diddledan: can you ls -ld /var/lib/snapd/apparmor/profiles/snap-update-ns.telegram-desktop | 16:40 |
| mvo | ijohnson: and merged and cherry-picked, thank you! | 16:41 |
| ijohnson | thanks mvo! | 16:41 |
| mup | PR snapd#8426 closed: interfaces/docker-support: add overlayfs file access <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8426> | 16:41 |
| diddledan | zyga: -rw-r--r-- 1 root root 53984 Apr 5 19:53 /var/lib/snapd/apparmor/profiles/snap-update-ns.telegram-desktop | 16:41 |
| zyga | april 5 19:53 | 16:41 |
| zyga | thanks | 16:41 |
| zyga | diddledan: do you have /var/lib/snapd mounted on external disk? | 16:42 |
| zyga | or something of this kind | 16:42 |
| diddledan | nopep | 16:42 |
| zyga | k | 16:42 |
| diddledan | it's on a fairly normal setup except 20.04.. I do have root-on-zfs as installed by ubiquity's new feature | 16:43 |
| jdstrand | diddledan: what is the ls -l output for /var/lib/snapd/apparmor/profiles/snap.multipass.* | 16:43 |
| jdstrand | popey: do you have root on zfs? | 16:43 |
| zyga | diddledan: you you remember when you ran the command that restarted apparmor.service? | 16:43 |
| popey | i do | 16:43 |
| diddledan | https://paste.ubuntu.com/p/cJ8bxBjRjq/ | 16:43 |
| diddledan | zyga, not precisely, no | 16:43 |
| * ijohnson remembers zyga asked us to setup tests to use zfs when 19.10 was released | 16:44 | |
| zyga | indeed | 16:44 |
| zyga | popey: are you using zfs on your machine that exhibited this problem? | 16:44 |
| popey | yes | 16:45 |
| zyga | (restarting apparmor.service) | 16:45 |
| zyga | aha | 16:45 |
| zyga | I feel a trend | 16:45 |
| diddledan | rpool/ROOT/ubuntu_t60y5t/var/snap on /var/snap type zfs (rw,relatime,xattr,posixacl) | 16:45 |
| zyga | diddledan: can you provide your /etc/fstab | 16:45 |
| diddledan | /var/snap is a separate mount from the zfs | 16:45 |
| diddledan | https://paste.ubuntu.com/p/Z7TJpV5TmT/ | 16:45 |
| jdstrand | diddledan: /var/snap is a separate thing | 16:46 |
| jdstrand | diddledan: /var/lib/snapd is the thing | 16:46 |
| diddledan | oops, sorry, misread | 16:46 |
| jdstrand | diddledan: can you attach to the bug: sudo systemd-analyze plot > ./1871148.svg | 16:46 |
| diddledan | rpool/ROOT/ubuntu_t60y5t/var/lib on /var/lib type zfs (rw,relatime,xattr,posixacl) | 16:46 |
| zyga | jdstrand: great idea | 16:46 |
| zyga | hmm | 16:46 |
| * zyga also uses zfs on his 20.04 desktop but that machine sees very little use | 16:47 | |
| jdstrand | diddledan: can you also attach: sudo systemd-analyze dot snap.multipass.multipassd.service > ./1871148-multipass.dot | 16:49 |
| diddledan | both added | 16:50 |
| zyga | hmm | 16:50 |
| zyga | no apparmor.service at all?? | 16:51 |
| zyga | WAT? | 16:51 |
| jdstrand | zyga: which are you looking at? | 16:51 |
| zyga | jdstrand: the .svg | 16:51 |
| zyga | full system stuff | 16:51 |
| zyga | diddledan: can you journalctl -u apparmor.service | 16:52 |
| zyga | I wonder if it ran once or twice | 16:52 |
| zyga | (during this boot) | 16:52 |
| jdstrand | uh | 16:53 |
| zyga | maybe I should boot that desktop | 16:53 |
| jdstrand | that is real weird | 16:53 |
| zyga | jdstrand: if you don't have ZFS I can try that | 16:53 |
| diddledan | looks like it only ran once until I restarted it manually: https://paste.ubuntu.com/p/W8bzwDpcR3/ | 16:53 |
| jdstrand | I do not | 16:53 |
| zyga | !!! | 16:53 |
| zyga | diddledan: can you reboot | 16:54 |
| zyga | diddledan: and see if it starts then | 16:54 |
| zyga | diddledan: if no, do not start it please | 16:54 |
| diddledan | roger. gimme a sec | 16:54 |
| zyga | thank you | 16:54 |
| zyga | jdstrand: I guess it didn't run and why is the whole mystery | 16:54 |
| jdstrand | zyga: it did run | 16:54 |
| jdstrand | Apr 06 16:32:56 defiant systemd[1]: Finished Load AppArmor profiles. | 16:54 |
| zyga | jdstrand: yeah but it was invoked manually | 16:55 |
| zyga | or could have been | 16:55 |
| zyga | why is it not in the .svg file? | 16:55 |
| jdstrand | zyga: the restarting apparmor was the manual one | 16:55 |
| diddledan | ok. back. snaps are broken :-) | 16:55 |
| jdstrand | zyga: the one I pointed at is from the paste in the bug that I mentioned | 16:56 |
| jdstrand | but why isn't it in the svg file, indeed | 16:56 |
| zyga | diddledan: ok | 16:56 |
| zyga | please don't restart apparmor.service | 16:56 |
| zyga | diddledan: systemctl status apparmor.service | 16:56 |
| zyga | diddledan: I bet there's a reason it was not started | 16:56 |
| zyga | and that's the big mystery | 16:56 |
| jdstrand | yeah | 16:57 |
| diddledan | https://paste.ubuntu.com/p/h69jvBV6Kd/ | 16:57 |
| zyga | huh | 16:57 |
| zyga | jdstrand: is there some debug switch to get a list of things loaded? | 16:57 |
| zyga | diddledan: can you edit /lib/apparmor/apparmor.systemd and add set -x up top | 16:58 |
| zyga | and restart apparmor.service | 16:58 |
| diddledan | that'll make everything start working, remember.. | 16:58 |
| zyga | yes but we will see that it works and the log of what happened | 16:59 |
| zyga | if that log is useful | 16:59 |
| zyga | then let's reboot again | 16:59 |
| zyga | and see the early -boot log | 16:59 |
| jdstrand | I still suspect the profiles weren't there at the time the service was start | 16:59 |
| jdstrand | wait!! | 16:59 |
| zyga | then we might know what to do | 16:59 |
| jdstrand | don't reboot yet | 16:59 |
| zyga | ok | 16:59 |
| jdstrand | diddledan: can you update /lib/apparmor/rc.apparmor.functions to comment out: | 16:59 |
| jdstrand | if [ "${QUIET:-no}" = yes ] || [ "${quiet:-n}" = y ]; then | 16:59 |
| jdstrand | PARSER_OPTS="$PARSER_OPTS --quiet" | 16:59 |
| jdstrand | fi | 16:59 |
| jdstrand | diddledan: then reboot | 17:00 |
| diddledan | restarting apparmor with those changes BEFORE rebooting: https://paste.ubuntu.com/p/HHQsFPZpYP/ | 17:01 |
| jdstrand | diddledan: actually | 17:01 |
| * diddledan holds | 17:01 | |
| jdstrand | diddledan: let's change that to be: | 17:01 |
| jdstrand | #if [ "${QUIET:-no}" = yes ] || [ "${quiet:-n}" = y ]; then | 17:01 |
| jdstrand | # PARSER_OPTS="$PARSER_OPTS --quiet" | 17:01 |
| jdstrand | #fi | 17:01 |
| jdstrand | PARSER_OPTS="$PARSER_OPTS -k" | 17:01 |
| jdstrand | that will show cache hits and misses | 17:02 |
| zyga | mmm | 17:02 |
| diddledan | ok. made the change. going for reboob | 17:02 |
| zyga | jdstrand: like a good mystery novel | 17:03 |
| zyga | the murderer is about to be revealed | 17:03 |
| diddledan | here we go: https://paste.ubuntu.com/p/dMMdZRZBbN/ | 17:04 |
| zyga | Apr 06 18:03:26 defiant apparmor.systemd[2717]: + [ -d /var/lib/snapd/apparmor/profiles ] | 17:04 |
| zyga | it didn't find snapd profiles | 17:05 |
| zyga | PROFILE_DIRS is only assigned to once | 17:05 |
| jdstrand | huh | 17:05 |
| zyga | wow | 17:05 |
| zyga | right/ | 17:05 |
| zyga | diddledan: can you pastebin /proc/self/mountinfo please | 17:05 |
| zyga | maybe there's some zfs magic we didn't anticipate | 17:05 |
| jdstrand | why isn't /var/lib/snapd/apparmor/profiles being looked at | 17:05 |
| zyga | jdstrand: ^ because it's not there at the time | 17:05 |
| diddledan | https://paste.ubuntu.com/p/7783bjqXNF/ | 17:05 |
| zyga | line 13 of the paste | 17:06 |
| jdstrand | oh, yes | 17:06 |
| jdstrand | ok, that part of the mystery is solved | 17:06 |
| zyga | 143 31 0:53 / /var/lib rw,relatime shared:79 - zfs rpool/ROOT/ubuntu_t60y5t/var/lib rw,xattr,posixacl | 17:06 |
| zyga | it's a separate volume | 17:06 |
| zyga | we don't have requires mounts for | 17:06 |
| zyga | so ... bummer | 17:06 |
| zyga | we need to rev apparmor.service | 17:06 |
| zyga | to have that | 17:06 |
| jdstrand | that is probably not satisfied by local-fs | 17:06 |
| zyga | diddledan: can you please create | 17:07 |
| zyga | diddledan: /etc/systemd/system/apparmor.service.d | 17:07 |
| zyga | diddledan: there create a file fixes.conf | 17:07 |
| zyga | with contents: | 17:07 |
| zyga | [Unit] | 17:07 |
| zyga | RequiresMountsFor=/var/lib/snapd/apparmor/profiles | 17:07 |
| zyga | then reboot | 17:07 |
| zyga | that should be it | 17:07 |
| zyga | I wonder what local fs thing is | 17:08 |
| diddledan | ok. rebooting | 17:08 |
| zyga | or what makes that zoo of pools | 17:08 |
| zyga | do we know someone in foundations that works on zfs? | 17:08 |
| zyga | I wonder why is everything in /var/* a separate pool | 17:09 |
| zyga | and how does zfs interact with local-fs.target | 17:09 |
| zyga | it feels like a bug that's deeper than RequiresMountsFor | 17:09 |
| diddledan | dingdingding! we have a weiner! | 17:10 |
| zyga | xnox: (sorry for pinging you, I just recall you as a foundations member that's very well connected), do you know who works on zfs on ubuntu? | 17:10 |
| zyga | diddledan: cool! | 17:10 |
| jdstrand | zyga: we definitely need foundations to advise | 17:10 |
| zyga | jdstrand: agreed | 17:10 |
| zyga | mvo: ^ it's a bug introduced by zfs | 17:10 |
| zyga | popey: ^ a workaround for you is spelled out above | 17:10 |
| jdstrand | fyi, I summarized in https://bugs.launchpad.net/snapd/+bug/1871148/comments/10 | 17:10 |
| mup | Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148> | 17:10 |
| zyga | super, thanks! | 17:10 |
| jdstrand | I did not put in the workaround | 17:11 |
| zyga | I read | 17:11 |
| zyga | ok, I need to take the dog out | 17:11 |
| zyga | it's been hours now | 17:11 |
| zyga | but we should definitely ask foundations to help | 17:11 |
| zyga | it's a RC blocker IMO | 17:11 |
| jdstrand | RequiresMountsFor=/var/lib/snapd/apparmor/profiles is probably fine | 17:11 |
| zyga | god knows what else is broken | 17:11 |
| zyga | yeah, I think we should have that | 17:11 |
| jdstrand | I can do a quick upload | 17:11 |
| zyga | jdstrand: can you upload new apparmor package to add that? | 17:12 |
| zyga | super ^ 2 | 17:12 |
| zyga | :D | 17:12 |
| Saviq | zyga, jdstrand: didrocks / jibel are your zfs-on-root / zsys experts | 17:12 |
| xnox | zyga: we don't do zfs on ubuntu-core today, nor in cloud. the only place it's available is on ubuntu desktop => which is desktop team stuff, i.e. jibel and friends. Not foundations thing =) | 17:12 |
| zyga | jibel: ^ | 17:12 |
| zyga | thanks guys! | 17:12 |
| jdstrand | xnox: do you agree that RequiresMountsFor=/var/lib/snapd/apparmor/profiles is reasonable to upload? | 17:12 |
| zyga | jibel: we may have a problem with zfs-on-root and local-fs.target | 17:12 |
| Saviq | let's ping jibel again so he doesn't get a heart attack at all :D | 17:13 |
| zyga | the details are in https://bugs.launchpad.net/snapd/+bug/1871148 | 17:13 |
| mup | Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148> | 17:13 |
| xnox | jdstrand: complete context switch =) que? =) | 17:13 |
| diddledan | should we ping jibel? | 17:13 |
| zyga | diddledan: I did :) ^ | 17:13 |
| diddledan | :-p | 17:13 |
| zyga | super | 17:13 |
| zyga | I'll leave you guys to it | 17:13 |
| diddledan | yeah I was trolly | 17:13 |
| zyga | my dog is looking at me with those puppy eyes | 17:13 |
| xnox | jdstrand: you probably want rbalint | 17:13 |
| diddledan | what idiot gave puppies puppyeyes?! | 17:14 |
| jdstrand | xnox: so, zfs-on-root does different pools for /var such that local-fs.target is satisfied but /var/lib/snapd/apparmor/profiles does not exist at the time the service starts | 17:14 |
| zyga | diddledan: puppy conspiracy :) | 17:14 |
| zyga | jdstrand: I wonder if zfs mounts are done by systemd | 17:14 |
| diddledan | it's the poopscoop industrial complex! | 17:14 |
| zyga | I guess it must be | 17:14 |
| zyga | because the requirement was enough to fix it | 17:14 |
| * zyga afk | 17:15 | |
| zyga | o/ | 17:15 |
| jdstrand | xnox: ack | 17:15 |
| * jdstrand -> ubuntu-devel | 17:15 | |
| xnox | jdstrand: and AppArmorProfile= key doesn't synthesize such a dep already? it should? | 17:15 |
| xnox | &> #ubuntu-devel | 17:15 |
| Saviq | zyga: https://github.com/openzfs/zfs/tree/master/etc/systemd/system | 17:16 |
| mup | PR snapd#8439 opened: [RFC] secboot: import secboot on ubuntu, provide dummy on !ubuntu <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8439> | 17:16 |
| mvo | pedronis: I started looking into the tpm PR finally and the above is a first RFC to help moving it into master (cc cmatsuoka). hope this is vaguely the right direction, please let me know if you would like to see tags used differently or some totally different approach | 17:17 |
| zyga | https://github.com/openzfs/zfs/blob/5a42ef04fd390dc96fbbf31bc9f3d05695998211/etc/systemd/system/zfs-mount.service.in#L8 | 17:17 |
| mvo | cmatsuoka: feel free to pickup/improve 8439, I have dinner now | 17:19 |
| jdstrand | xnox: it might be able to synthesize it, but that is in the snapd units. by that time, the apparmor unit already ran and finished, ignoring the dir | 17:19 |
| jdstrand | xnox: but, we aren't using AppArmorProfile in the units anyway (snap-confine handles it) | 17:20 |
| cmatsuoka | mvo: ack | 17:25 |
| pedronis | mvo: that looks painful once types enter the picture | 17:29 |
| pedronis | but I'm probably missing something | 17:31 |
| xnox | jdstrand: hm, apparmor.service (or whatever it is) really should require mounts for dirs it uses, i.e /var/lib/foo/bar/baz/ which systemd will correctly resolve as to which ones are needed (i.e. /var, or /var/lib, or /varlib/foo, etc.) | 17:34 |
| xnox | jdstrand: and units that use ApparmorProfile should like synthese dep+after apparmor.service (whatever it is called) | 17:35 |
| pedronis | cmatsuoka: I made some comments there | 17:35 |
| cmatsuoka | pedronis: thanks, will check asap | 17:35 |
| mup | PR snapd#8415 closed: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8415> | 17:36 |
| jdstrand | xnox: ok, so it sounds like you answered my question about RequiresMountsFor=/var/lib/snapd/apparmor/profiles | 17:36 |
| * zyga EODs and goes to set up some DNS at home | 17:50 | |
| === Trevinho_ is now known as Trevinho | ||
| pedronis | jdstrand: so this needs both an apparmor package fix and a snapd snap services fix? | 18:11 |
| jdstrand | pedronis: no. snapd does not need a change. I am going to make a change to apparmor since it is the correct thing for it. it should address this issue. it sounds like jibel is going to perhaps adjust zsys in some manner | 18:23 |
| mvo | pedronis: re 8439> it should be enough to get the current tpm PR in progress working everywhere but yes, will not scale well. I guess it all depends on how much of the secboot code will be used outside of cmd/snap-bootstrap (which is skipped entirely on !ubuntu) | 18:23 |
| mvo | pedronis: anyway, totally happy about idea, just wanted to help unblock things | 18:23 |
| cmatsuoka | mvo: ok, working on that. I refactored it a little bit to have CheckEncryptionAvailability() in different versions | 18:23 |
| mup | PR pc-amd64-gadget#40 closed: gadget.yaml: reduce data partition size to 1G <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/40> | 18:24 |
| pedronis | jdstrand: don't we need this: <xnox> jdstrand: and units that use ApparmorProfile should like synthese dep+after apparmor.service (whatever it is called) | 18:25 |
| mvo | cmatsuoka: sounds great | 18:25 |
| mvo | cmatsuoka: fwiw, I'm not attached to this at all, just wanted to draft something to help us moving forward which can land in isolation to unblock the rest of the tpm work | 18:25 |
| cmatsuoka | mvo: shall I push my version to the same PR so we can discuss it better? | 18:26 |
| mvo | cmatsuoka: it looks also like my govendor changes are busted, sorry for that (https://travis-ci.org/github/snapcore/snapd/jobs/671744586?utm_medium=notification&utm_source=github_status) - I can look at it now unless you are already on this | 18:26 |
| mvo | cmatsuoka: yeah, go for it! | 18:26 |
| mvo | cmatsuoka: just push to the open PR or open a new one, like I said, no attachment to htis partical version :) | 18:27 |
| cmatsuoka | mvo: pushed it, we can always revert it if necessary | 18:30 |
| mvo | cmatsuoka: thanks! appreciated | 18:31 |
| cmatsuoka | oops, I didn't read the last comment from pedronis before pushing it | 18:32 |
| mvo | cmatsuoka: I ran "govendor remove +unused" just now | 18:32 |
| mvo | cmatsuoka: it seems like you adressed his comment, no? | 18:33 |
| cmatsuoka | I think it's in the same line | 18:33 |
| cmatsuoka | I renamed the function but ok, it's not important now | 18:33 |
| mvo | cmatsuoka: aha, I see | 18:34 |
| ijohnson | mvo I see that google:ubuntu-core-20-64:tests/core/writablepaths failed because /etc/machine-id was not writable, do we need to port that patch to release/2.44 ? | 18:35 |
| ijohnson | i.e. https://github.com/snapcore/snapd/pull/8422 might not have been applied to 2.44 iiuc | 18:36 |
| mup | PR #8422: tests: skip "/etc/machine-id" in "writablepaths" test <Simple 😃> <⚠Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8422> | 18:36 |
| mvo | ijohnson: in 2.44? yeah, I think there is a cherry pick missing | 18:38 |
| ijohnson | mvo: yes | 18:38 |
| ijohnson | I don't see that commit on 2.44 | 18:38 |
| ijohnson | and the 2.44 travis run failed on that | 18:39 |
| mvo | ijohnson: just picked it | 18:39 |
| mvo | ijohnson: *hopefully* that's enough | 18:39 |
| ijohnson | cool :-) | 18:39 |
| mvo | ijohnson: thanks for noticing! | 18:39 |
| * ijohnson crosses fingers | 18:39 | |
| mup | PR snapd#8440 opened: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440> | 18:39 |
| cmatsuoka | ijohnson: did you work with the microk8s snap recently? | 20:11 |
| cmatsuoka | ijohnson: you may want to have a look at https://bugs.launchpad.net/snapd/+bug/1871189 | 20:11 |
| mup | Bug #1871189: Snapd `cannot update snap namespace` when connecting / disconnecting interfaces <snapd:New> <https://launchpad.net/bugs/1871189> | 20:11 |
| ijohnson | cmatsuoka: yes I will add a reproducer there today, it is what was reported in #snappy-internal the other day | 20:13 |
| cmatsuoka | ijohnson: ah ok, should I assign that to you then? | 20:13 |
| ijohnson | sure | 20:14 |
| cmatsuoka | thanks | 20:14 |
| cmatsuoka | zyga: have you seen trap invalid opcode error messages in xdg-open invoked from a snap? | 20:38 |
| mup | PR snapd#8441 opened: interfaces: add case for rootWritableOverlay + NFS <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8441> | 20:56 |
| mup | PR snapd#8442 opened: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442> | 21:03 |
| mup | PR snapcraft#3015 opened: [WIP] ros2 (colcon) extension preview <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3015> | 21:06 |
| pedronis | ijohnson: I marked #8442 blocked, *util packages should really depend only on stdlib or other util packages (there might be counterexamples but we should fix them), so importing dirs into osutil is not a solution as is to your conundrum | 21:46 |
| mup | PR #8442: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <â›” Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442> | 21:46 |
| mup | PR snapd#8434 closed: systemd: move the doc comments to the interface so they are visible <Reviewed> <Simple 😃> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8434> | 21:51 |
| zyga | cmatsuoka: not that I recall | 22:19 |
| mup | PR snapd#8443 opened: interfaces/many: miscellaneous policy updates xliv <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8443> | 22:43 |
| mup | PR snapd#8444 opened: interfaces/many: miscellaneous policy updates xliv - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8444> | 22:48 |
| cmatsuoka | zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1870861 shows some instances of that happening | 23:03 |
| mup | Bug #1870861: chromium-browser is unable to open downloads <snapd (Ubuntu):New> <https://launchpad.net/bugs/1870861> | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!