| mup | PR core20#53 opened: Add secureboot-db <Created by xnox> <https://github.com/snapcore/core20/pull/53> | 00:54 |
|---|---|---|
| mup | PR snapd#8611 opened: tests: not fail when boot dir cannot be determined <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8611> | 02:04 |
| mborzecki | morning | 05:20 |
| jamesh | Wow. I've got a green tick on PR 5822 | 05:53 |
| mup | PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822> | 05:53 |
| mborzecki | wow, that PR is old :P | 06:11 |
| jamesh | zyga's session-tool work has made the tests a lot more reliable | 06:12 |
| mborzecki | eagerly waiting for something else to break, at times it really feels like we're only maintaining the ci system | 06:13 |
| mborzecki | quick errand, back in 30 | 06:32 |
| mup | PR snapd#8610 closed: many: use /run/mnt/data over /run/mnt/ubuntu-data for uc20 (2.45) <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8610> | 06:42 |
| zyga | jamesh: woot | 06:44 |
| zyga | :-) | 06:45 |
| jamesh | zyga: needed a minor change to session-tool to get things working on 16.04 | 06:45 |
| zyga | Good morning everyone | 06:45 |
| zyga | Cool, what was it? | 06:46 |
| jamesh | zyga: "session-tool --has-session-systemd-and-dbus" returns false on 16.04, yet it has a working user instance of systemd | 06:46 |
| jamesh | you don't need a systemd controlled session bus to talk to systemd | 06:47 |
| zyga | Ah, bit that is real | 06:47 |
| zyga | You indeed a package installed | 06:47 |
| zyga | Some of our tests do that | 06:47 |
| zyga | Dubs-user-session or something like that | 06:47 |
| zyga | Dubs-session-bus maybe | 06:47 |
| zyga | After you install that package, session to gives you a green light | 06:48 |
| jamesh | zyga: try running "strace --trace=connect systemctl --user status default.target" locally, and find out where it connects to the session bus :-) | 06:48 |
| zyga | Where does it connect? | 06:48 |
| jamesh | a socket at "$XDG_RUNTIME_DIR/systemd/private", which talks directly to the systemd instance | 06:49 |
| zyga | Iirc the package ships usr lib systemd user dbus.socket | 06:49 |
| jamesh | yes, but "systemctl --user" doesn't rely on it | 06:49 |
| zyga | Oh. Interesting | 06:49 |
| zyga | But we kind of do, you don’t get the environment variable without it | 06:50 |
| jamesh | and it just so happens 16.04 is a system where it makes a difference | 06:50 |
| zyga | I worked kind of late yesterday | 06:51 |
| zyga | I’ll wake up and gladly look at changes | 06:51 |
| jamesh | zyga: Here's the change I made: https://github.com/snapcore/snapd/pull/5822/commits/043ba49f8f95d5111875f99e34425e52674c88cd | 06:51 |
| mup | PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822> | 06:51 |
| jamesh | it's sitting at the tail end of my user-daemons PR at the moment | 06:51 |
| jamesh | I can cherry pick it out into an independent PR, but my preference would be to just land user-daemons :-) | 06:52 |
| zyga | Does it pass on centos-8 | 06:52 |
| zyga | 7 | 06:52 |
| jamesh | It passed everywhere | 06:52 |
| zyga | Mmmm | 06:52 |
| jamesh | I'm doing a "systemctl --user is-enabled default.target" call first, which should only fail if we can't talk to systemd | 06:53 |
| zyga | The reason I ask is that centos 7 disabled systemd —user explicitly | 06:53 |
| zyga | Ahh | 06:53 |
| zyga | Perhaps that is the trick then | 06:53 |
| zyga | Cool | 06:53 |
| zyga | Looking forward to having this all merged :-) | 06:54 |
| jamesh | if there is a simpler availability check, we can use that | 06:54 |
| zyga | I need a coffee though | 06:54 |
| zyga | Few hours of sleep today | 06:54 |
| zyga | I’m very happy all this work is paying off | 06:55 |
| mborzecki | re | 06:58 |
| mborzecki | zyga: i'm glad it's seems to be working now, but i'm also amazed how complicated user session setup is | 07:03 |
| pstolowski | morning | 07:03 |
| mborzecki | makes me wonder whether it really has to be that complicated | 07:03 |
| mborzecki | pstolowski: hey | 07:03 |
| mvo | good morning pstolowski | 07:07 |
| mvo | and morning to mborzecki and zyga :) | 07:07 |
| zyga | mborzecki: I can gladly pass the baton | 07:11 |
| mborzecki | zyga: nah, thanks :) | 07:13 |
| zyga | at my desk | 07:14 |
| zyga | green ticks | 07:14 |
| zyga | not everyone | 07:15 |
| zyga | but man :) | 07:15 |
| zyga | call me eco-friendly ;D | 07:15 |
| zyga | mvo: I worked to like 2AM | 07:15 |
| zyga | mvo: I kind of feel tired today | 07:15 |
| zyga | I will probably just attend meetings | 07:15 |
| zyga | and not do much meanwhile | 07:15 |
| zyga | maybe push some small fixes | 07:16 |
| zyga | and two claudio's branches are green too | 07:16 |
| jamesh | mborzecki: just wait until we try to set up a working user session on a real Ubuntu Core system, rather than just in the test environment... | 07:16 |
| zyga | mborzecki: rebase / merge master | 07:16 |
| zyga | :D | 07:16 |
| zyga | jamesh: btw, did you notice that core 20 seems to have everything required for user services already? | 07:16 |
| jamesh | zyga: more so than core18? | 07:17 |
| zyga | yes | 07:17 |
| zyga | check this out | 07:17 |
| zyga | https://github.com/snapcore/snapd/blob/master/tests/main/session-tool-support/task.yaml | 07:17 |
| zyga | core 20 ships /lib/systemd/user/dbus.socket | 07:18 |
| jamesh | zyga: ah. I agree that makes a difference for D-Bus services, yes :-) | 07:19 |
| jamesh | user services are working all the way back to core16 | 07:20 |
| zyga | indeed | 07:20 |
| zyga | jamesh: one relevant aspect that I didn't explain properly before | 07:20 |
| zyga | because I was typing from a phone | 07:20 |
| zyga | was that dbus.socket unit injects DBUS_SESSION_BUS_ADDRESS into session environment | 07:21 |
| zyga | and .e.g. snap run checks for it | 07:21 |
| zyga | so it's plausible that other programs also check for it | 07:21 |
| zyga | and not fall back to other locations | 07:21 |
| zyga | but in general, having dbus in the session is desired | 07:21 |
| jamesh | definitely | 07:21 |
| jamesh | and maybe in a year we can pretend that it is always true | 07:21 |
| jamesh | once 16.04 goes EOL | 07:22 |
| zyga | jamesh: well, that 10 year support probably means my kids can gro up to become engineers and support it | 07:22 |
| mborzecki | hahah | 07:23 |
| zyga | (for the record, my son is almost 14 now) | 07:23 |
| jamesh | neither the desktop or snapd were included in 14.04's ESM | 07:24 |
| jamesh | snapd might not be so lucky for 16.04, but you might not need to care about desktop sessions there any more | 07:24 |
| zyga | jamesh: so about that | 07:25 |
| zyga | there's some discussion to extend session-tool to 14.04 | 07:25 |
| zyga | so that we have better coverage | 07:25 |
| zyga | I _might_ just do it | 07:25 |
| jamesh | there's no user instance of systemd on 14.04, so it will probably look like CentOS 7 | 07:26 |
| zyga | I was thinking about emulating all the upstart-goodies there | 07:26 |
| zyga | so not based on systemd | 07:26 |
| zyga | but stil following PAM | 07:26 |
| zyga | and doing "something" that is representative | 07:27 |
| pedronis | the agreement on 14.04 is mostly livepatch should install and work | 07:29 |
| zyga | mmm, I see | 07:29 |
| zyga | maybe it's just not worth it then | 07:29 |
| pedronis | afaiu no | 07:30 |
| mup | PR snapd#8606 closed: progress: fix progress bar with multibyte duration units <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8606> | 07:46 |
| mborzecki | yay | 07:46 |
| zyga | see you at the code review meetign! | 07:52 |
| zyga | *meeting | 07:52 |
| pedronis | mvo: I did a pass on #8334 | 07:57 |
| mup | PR #8334: many: add core.resiliance.vitality-hint config setting <Needs Samuele review> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8334> | 07:57 |
| mvo | pedronis: \o/ thank you | 07:57 |
| mup | PR snapd#5822 closed: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5822> | 08:06 |
| mup | PR core20#53 closed: Add secureboot-db <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core20/pull/53> | 08:14 |
| zyga | I identified and fixed the tests that were breaking the pulseaudio test before | 08:46 |
| zyga | it was the portal and xdg-open tests | 08:46 |
| zyga | they created ~test/.config as root | 08:47 |
| zyga | and that was enoguh | 08:47 |
| zyga | I'll send patches shortly | 08:47 |
| Mirv | hi I'm once again searching for bug which may or may not be a bug.. after Tumbleweed upgrade to GNOME 3.36 on two machines, the other one is missing snap in XDG_DATA_DIRS and also missing snap_bin_path and snap_xdg_path - what should be setting those? and I wonder if there's anything that could be made bullet proof regarding setting them. | 08:50 |
| zyga | Mirv: hello | 08:50 |
| Mirv | I can obviously workaround by setting the missing parts manually | 08:50 |
| zyga | those are set by IIRC the environment generator | 08:51 |
| zyga | (systemd env generator) | 08:51 |
| zyga | Mirv: do you have ... | 08:52 |
| zyga | Mirv: /usr/lib/systemd/system-environment-generators/snapd-env-generator | 08:53 |
| Mirv | yes I have on both machines. I'm doing random grepping but not finding differences between the machines yet | 09:00 |
| zyga | mborzecki: ^ | 09:03 |
| * zyga needs to go afk for a moment | 09:03 | |
| mborzecki | zyga: snapd-env-generator is for services iirc | 09:07 |
| zyga | what? why? | 09:07 |
| pedronis | pstolowski: is #8533 really just the test? does it need master merge? | 09:07 |
| mup | PR #8533: image, tests: core18 early config test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533> | 09:07 |
| mborzecki | zyga: for user sessions there's systemd-environment-d-generator | 09:08 |
| mborzecki | zyga: and as for why, i have no clue ;) | 09:08 |
| mborzecki | Mirv: does /usr/lib/environment.d/990-snapd.conf exist in your system? does `systemctl --user show-environment | grep '^XDG_DATA_DIRS='` list /var/lib/snapd/desktop ? | 09:09 |
| pstolowski | pedronis: ah, no, it's also actual image.go change, i will update the desc | 09:09 |
| pedronis | pstolowski: ah, ok | 09:09 |
| Mirv | mborzecki: exists on both, on the affected system however /var/lib/snapd/desktop is missing while on the working system it's there | 09:13 |
| Mirv | (ie 990-snapd.conf exists on both) | 09:13 |
| zyga | Mirv: any chance you are using zsh? | 09:13 |
| Mirv | bash on both | 09:13 |
| pedronis | pstolowski: maybe the configcore changes should be in their own PR? | 09:16 |
| mborzecki | hmm looks like the issue we had on centos and rhel, where it worked in my vm, but didn't work in degville's | 09:16 |
| degville | mborzecki: I think I'll try a fresh install and see what happens. | 09:17 |
| pstolowski | pedronis: sure, i can extract them | 09:18 |
| pedronis | pstolowski: if it's not too annoying | 09:18 |
| pstolowski | pedronis: it shouldn't | 09:18 |
| pedronis | thank you | 09:18 |
| Mirv | anyway, the problem seems a bit more like systemd problem now that it is in environment.d correctly, not snap problem | 09:19 |
| Mirv | erh... I noticed there is also 99-environment.conf symlink to /etc/environment , so out of interest I tried to copy-paste the content of 990-snapd.conf into /etc/environment and rebooted.. upon login, it seemed like I could not launch any apps, and no extensions were loaded. so I removed the lines from /etc/environment and rebooted again and... now, for some reason XDG_DATA_DIRS has the snapd dir! | 09:22 |
| Mirv | maybe it's a systemd bug | 09:23 |
| Mirv | before this I had used the system with multiple reboots since last week | 09:23 |
| mborzecki | perhaps some race condition | 09:24 |
| mborzecki | Mirv: is there a /usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator in your system? | 09:25 |
| mborzecki | btw. noticed therels /usr/lib/systemd/user-environment-generators/60-flatpak that runs after, but it seems to be handling the XDG_DATA_DIRS path correctly | 09:28 |
| mborzecki | Mirv: if you have that 60-flatpak file ^^ can you run `XDG_DATA_DIRS=/var/lib/snapd/desktop /usr/lib/systemd/user-environment-generators/60-flatpak` and make sure that output contains /var/lib/snapd/desktop path? | 09:30 |
| Mirv | mborzecki: yes there is 30-systemd-environment-d-generator on both machines, and yes the output contains snapd/desktop path. but as said, after I made something error out by modifying /etc/environment and then reverting that change, now the /var/lib/snapd/desktop is correctly there also on this system that didn't have it for the past week, so I can't reproduce the problem anymore. | 09:35 |
| Mirv | mborzecki: .. I rebooted again, and now the problem is again there .. still the output containts the desktop path | 09:37 |
| Mirv | it's something causing the systemd not generate the environment correctly, quite consistently on this machine but not the other | 09:38 |
| mborzecki | Mirv: are you using gdm? | 09:39 |
| Mirv | mborzecki: yes | 09:39 |
| mborzecki | Mirv: ok, can you `cat /usr/share/gdm/env.d/flatpak.env`? | 09:40 |
| mborzecki | if it exists | 09:40 |
| Mirv | -> XDG_DATA_DIRS=$HOME/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/ | 09:42 |
| mborzecki | Mirv: heh ok, can you mv that file to say $HOME for a bit, and then reboot/relogin? | 09:42 |
| mborzecki | jamesh: are you familiar with gdm internals by any chance? | 09:44 |
| jamesh | mborzecki: not deeply, but maybe I can help? | 09:45 |
| mborzecki | jamesh: when the user session starts up, are env files from /usr/share/gdm/env.d/ applied, and if so would that happen to run after/before systemd user env generators? | 09:46 |
| mup | PR snapd#8612 opened: sysconfig: use new _writable_defaults dir to create cloud config <⛔ Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8612> | 09:46 |
| mborzecki | jamesh: from the code i see it's in the worker https://github.com/GNOME/gdm/blob/2155ffa023d94fd269cf01d69d897ebe9a63a386/daemon/gdm-session-worker.c#L1633 but does it run when user logs in or is it only for the actual gdm process? | 09:47 |
| mup | PR core20#54 opened: static: switch /etc/cloud from synced to persistent <Blocked> <Created by mvo5> <https://github.com/snapcore/core20/pull/54> | 09:47 |
| jamesh | mborzecki: I'm not sure | 09:48 |
| Mirv | mborzecki: I've moved that away and the problem is gone for at least two subsequent boots (more than ever before).. so maybe it's a race condition | 09:48 |
| Mirv | anyway, I'll need to go now for a bit | 09:49 |
| mborzecki | jamesh: hmm the call chain goes up to do_start_session() https://github.com/GNOME/gdm/blob/2155ffa023d94fd269cf01d69d897ebe9a63a386/daemon/gdm-session-worker.c#L2764 | 09:51 |
| zyga | I found and fixed a bug affecting all portals tests | 09:58 |
| zyga | that should remove some more random failures | 09:58 |
| zyga | two PRs to go though | 09:58 |
| mborzecki | wtf is /usr/lib/systemd/user/dbus.service.d/flatpak.conf ? why are all 3 ways of injecting environment used by flatpak? | 10:09 |
| zyga | lol | 10:10 |
| zyga | what? | 10:10 |
| mborzecki | at least 2 of those just override whatever is set via user env generators | 10:11 |
| zyga | what's there? | 10:11 |
| jamesh | are you sure it is only 3? | 10:11 |
| mborzecki | # /usr/lib/systemd/user/dbus.service.d/flatpak.conf | 10:11 |
| mborzecki | [Service] | 10:11 |
| mborzecki | Environment=XDG_DATA_DIRS=%h/.local/share/flatpak/exports/share/:/var/lib/flatpak/exports/share/:/usr/local/share/:/usr/share/ | 10:11 |
| zyga | heh | 10:11 |
| zyga | so kind | 10:11 |
| mborzecki | jamesh: skipped pam_env since we know it's off limits :P | 10:11 |
| jamesh | it's not using /etc/profile.d too? | 10:11 |
| zyga | maybe we should file a bug? | 10:11 |
| mborzecki | that file and /usr/share/gdm/env.d/flatpak.env just set XDG_DATA_DIRS | 10:12 |
| jamesh | unilaterally overriding (rather than appending/prepending) is bad manners | 10:12 |
| zyga | mborzecki: just ship aaa-snapd and zzz-snapd.conf | 10:12 |
| zyga | and set it again | 10:12 |
| mborzecki | also found this comment https://bugzilla.gnome.org/show_bug.cgi?id=766176#c11 there's like 4 possible scenarios how env is injected | 10:13 |
| * zyga queues for the best tech solution award ;) | 10:13 | |
| zyga | jokes aside | 10:13 |
| zyga | it's a bug | 10:13 |
| zyga | and a bit eivl | 10:13 |
| zyga | *evil | 10:13 |
| jamesh | we've definitely had problems where the environment injection methods we thought we universal turn out not to be | 10:14 |
| jamesh | they're probably just adding new ones as they find new corner cases | 10:14 |
| mborzecki | we are seriously doomed | 10:15 |
| mup | PR snapd#8613 opened: o/configcore: pass extra options to FileSystemOnlyApply <Created by stolowski> <https://github.com/snapcore/snapd/pull/8613> | 10:16 |
| mborzecki | well the linux desktop is xD | 10:16 |
| pedronis | zyga: I did a pass on #7825 | 10:23 |
| mup | PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825> | 10:23 |
| zyga | pedronis: thank you! | 10:23 |
| pedronis | zyga: I should look at 8566 next, is that right? | 10:24 |
| zyga | yes please | 10:24 |
| pedronis | ok, lunch first | 10:25 |
| zyga | pedronis: the main remark about the transient unit code is that test tests will be probably 500+ lines and I just didn't want to do them all here (behind a feature flag) - the main innovation is being able to do the tests in the first place (but that has since landed to master) | 10:27 |
| zyga | pedronis: I'm happy to do the tests in the same PR if people are ok with that | 10:27 |
| pedronis | zyga: tbh, I think it makes more sense to split out the helper to meaningful packages and do the tests there | 10:28 |
| pedronis | *helpers | 10:28 |
| zyga | pedronis: sure, just tell me where | 10:28 |
| pedronis | zyga: I made some suggestions in the comments | 10:28 |
| zyga | pedronis: cmd/dbusutil? dbusutil top level... somewhere else? | 10:28 |
| pedronis | zyga: I think some bits belong to systemd, some bits might belong to a dbusutil package | 10:29 |
| pedronis | and some bits belong to sandbox/cgroup | 10:29 |
| pedronis | the latter point is the more unclear | 10:29 |
| pedronis | I have a comment with a question about it | 10:29 |
| zyga | so should I split that into bits that can be discussed | 10:30 |
| zyga | or do you suggest to continue in the branch, just iterating on the parts there | 10:30 |
| zyga | (the branch has the advantage of having spread tests to check things end to end) | 10:31 |
| mup | PR core20#55 opened: hooks: make systemd-modules-load depend on mounts at /usr/lib/{firmware,modules} <Created by anonymouse64> <https://github.com/snapcore/core20/pull/55> | 10:32 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/8614 | 10:35 |
| mup | PR #8614: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614> | 10:35 |
| mup | PR snapd#8614 opened: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614> | 10:35 |
| * zyga needs to run an errand for his parents, I will probably miss standup as we need to drive around | 10:35 | |
| zyga | the portal tests are still not reliable, I found one more bug that is fixed locally | 10:36 |
| zyga | but there is more, I just cannot understand why it fails | 10:36 |
| pedronis | zyga: you can do the work in the branch and then split it, atm it has the problem that is both too big and not big enough (missing coverage, too much code directly in cmd_run.go) | 10:42 |
| zyga | Ok, sounds good | 10:43 |
| zyga | And I agree | 10:43 |
| pedronis | mborzecki: mvo: seems #8464 can be merged | 11:03 |
| mup | PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <Squash-merge> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464> | 11:03 |
| mvo | pedronis: thank you, merged | 11:06 |
| mvo | pedronis: I updated the vitality-score PR | 11:06 |
| mup | PR snapd#8464 closed: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <Squash-merge> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8464> | 11:06 |
| mborzecki | yay | 11:06 |
| ijohnson | thanks folks | 11:06 |
| ijohnson | and g'morning | 11:06 |
| zyga | ijohnson: hey :) | 11:07 |
| ijohnson | hey zyga | 11:07 |
| ijohnson | I had a look at your session-tool pulseaudio PR that you merged last night, it all looked good to me | 11:07 |
| zyga | ijohnson: I fixed that bugger and found the cause for the failure | 11:07 |
| ijohnson | very nice | 11:07 |
| zyga | https://github.com/snapcore/snapd/pull/8614 | 11:07 |
| mup | PR #8614: tests: don't create root-owned things in ~test <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8614> | 11:08 |
| ijohnson | zyga: nice | 11:10 |
| ijohnson | it feels good to see master very green | 11:10 |
| zyga | it is not over | 11:11 |
| zyga | I found two more bugs in portal tests | 11:11 |
| zyga | fixed one | 11:11 |
| zyga | investigated the other but cannot grok it yet | 11:11 |
| zyga | race | 11:11 |
| zyga | but cannot grok why | 11:11 |
| zyga | but little by little : | 11:11 |
| zyga | :) | 11:11 |
| * mvo hugs zyga | 11:12 | |
| mup | PR snapd#8615 opened: github: register the problem matcher in a separate step to running spread <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8615> | 11:12 |
| mvo | thank you ijohnson and good morning as well :) | 11:12 |
| ijohnson | o/ mov | 11:13 |
| ijohnson | ah typing is hard | 11:13 |
| ijohnson | o/ mvo | 11:13 |
| zyga | oho | 11:13 |
| zyga | kid invasion | 11:13 |
| ogra | dont call ian a kid ! | 11:13 |
| zyga | I have a sleeping lucy hugging me now | 11:13 |
| ijohnson | haha | 11:14 |
| ijohnson | mborzecki: just noticed this unit test failure from one of my runs where I merged master: https://pastebin.ubuntu.com/p/RbzqwMKSbP/ | 11:27 |
| ijohnson | I'm a bit unclear what went wrong in the regex there, but it looks related to your change | 11:27 |
| ijohnson | it came from https://github.com/snapcore/snapd/pull/8559/checks | 11:28 |
| mup | PR #8559: boot, bootloader: adjust comments, expand tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8559> | 11:28 |
| mborzecki | ijohnson: hmm yeah, 0B/s weird | 11:28 |
| mborzecki | maybe something needs tweaking | 11:28 |
| zyga | https://github.com/snapcore/snapd/pull/8602 is green | 11:38 |
| mup | PR #8602: configcore: only reload journald if systemd is new enough <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8602> | 11:38 |
| zyga | and +3 | 11:38 |
| zyga | pstolowski: ^^ | 11:38 |
| pstolowski | grea, and it's green finally | 11:39 |
| mup | PR snapd#8602 closed: configcore: only reload journald if systemd is new enough <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8602> | 11:41 |
| mup | PR snapd#8616 opened: progress: tweak multibyte label unit test data <Simple 😃> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8616> | 11:42 |
| mborzecki | ijohnson: this should fix it ^^ | 11:42 |
| mborzecki | (or at least make it more robust) | 11:42 |
| pedronis | cmatsuoka: hi, I wanted to review #8577 but it has conflicts atm | 12:10 |
| mup | PR #8577: secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8577> | 12:11 |
| cmatsuoka | pedronis: yes, I'm fixing the conflicts but then in a test installation broke for some reason, I'm checking with ian | 12:11 |
| cmatsuoka | pedronis: I'm retesting installation with pure master now | 12:12 |
| cmatsuoka | pedronis: resolved | 12:17 |
| pedronis | thx | 12:17 |
| cmatsuoka | pedronis: there's a handle type there I couldn't come with a good name for, suggestions welcome | 12:18 |
| cachio | pstolowski, hi | 12:40 |
| cachio | pstolowski, I see an error in preseed test https://paste.ubuntu.com/p/j5x2pHBH9m/ | 12:40 |
| ogra | have there been any snapd changes to make anything talk to avahi via dbus recently ? | 12:41 |
| cachio | pstolowski, is it familiar for you? | 12:41 |
| ogra | seems oSoMoN and I both see avahi denials for apps that did not have them before ... but funnily we see similar denials for different apps | 12:41 |
| ogra | msg='apparmor="DENIED" operation="dbus_method_call" bus="system" path="/" interface="org.freedesktop.DBus.Peer" member="Ping" mask="send" name="org.freedesktop.Avahi" pid=431942 label="snap.chromium.chromium" | 12:41 |
| ogra | (i see it for chromium, olivier for libreoffice ... neither app has used avahi before) | 12:42 |
| zyga | chrome is pinging avahi | 12:42 |
| ogra | zyga, well ... here it is | 12:42 |
| ogra | seems for oSoMoN libreoffice is all of a sudden pinging avahi :) | 12:43 |
| ogra | hmm, could that be portal integration stuff? | 12:43 |
| oSoMoN | to be fair I don't know whether it was doing it before, I never noticed but then again I'm not watching denials all day long | 12:43 |
| ogra | i tend to have a terminal with journalctl -f while trying our new snaps or fixing something ... i dont run my logs regulary though, but every now and then ... and i thinnk i'D have noticed Avahi denials | 12:44 |
| ogra | s/our/out/ | 12:45 |
| ogra | for me this is definitely new ... though i have only upgraded to focal end of last week | 12:45 |
| ogra | perhaps it is focal related | 12:46 |
| zyga | pedronis: updated https://github.com/snapcore/snapd/pull/8566 | 12:56 |
| mup | PR #8566: cmd/cmdutil: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566> | 12:56 |
| * zyga -> standupo | 12:56 | |
| zyga | standup even | 12:56 |
| pstolowski | cachio: looks like deb is old and doesn't ship snap-preseed binary? | 13:02 |
| mup | PR snapd#8615 closed: github: register the problem matcher in a separate step to running spread <Created by jhenstridge> <Closed by jhenstridge> <https://github.com/snapcore/snapd/pull/8615> | 13:24 |
| mup | PR snapd#8617 opened: tests: new directory used to store the cloud images on gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8617> | 13:29 |
| seb128 | bah, don't use --gdb it screws up configs/application | 13:32 |
| seb128 | I just spent an hour figuring out my snap-store was b0rked because I tried to get a bt a few weeks ago | 13:32 |
| seb128 | (thanks Ken for helping debugging ;-) | 13:32 |
| pstolowski | cachio: the preseed nested test fails because of these changes made recently to nested suite, where current snapd deb is not installed on the host. if you install it it will have snap-preseed command | 13:44 |
| cachio | pstolowski, ah | 13:44 |
| pstolowski | cachio: so solution is to install snapd.deb from /home/hopath | 13:45 |
| pstolowski | *gopath | 13:45 |
| cachio | is that part of a PR right? | 13:45 |
| cachio | which is not merged yet? | 13:45 |
| pstolowski | cachio: no | 13:45 |
| cachio | ah, ok | 13:45 |
| cachio | in that caase I'll add that to my current pr | 13:46 |
| pstolowski | cachio: you probably confused it with another test that I've in a PR where I hit similiar problem | 13:46 |
| cachio | pstolowski, right | 13:46 |
| cachio | I'll fix that | 13:46 |
| cachio | Could you please take a look #8558 | 13:48 |
| mup | PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558> | 13:49 |
| cachio | pstolowski, I already included that | 13:49 |
| pstolowski | cachio: ok | 13:49 |
| cachio | pstolowski, I am running tests here | 13:49 |
| cachio | pstolowski, I see error now https://paste.ubuntu.com/p/489MC2WnNw/ | 14:08 |
| cachio | seccomp-compiler-version is different | 14:09 |
| pstolowski | cachio: yes | 14:11 |
| mup | PR snapd#8618 opened: gadget: fix fallback device lookup for 'mbr' type structures <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8618> | 14:14 |
| mborzecki | cmatsuoka: mvo: ^^ this will fix gadget updates to rev 100 of pc gadget | 14:14 |
| mvo | mborzecki: do we need this in snapd beta for uc20 beta? | 14:15 |
| mvo | mborzecki: also if that is a problem, why did we not see this earlier? also thanks for the fix :) | 14:16 |
| mvo | mborzecki: if we need it for 2.45 then let's add a tag | 14:16 |
| mborzecki | mvo: it'd be nice, otherwise if `update.edition:` is bumped again, the update will fail until one updates snapd first | 14:16 |
| mborzecki | mvo: and we did not see this earlier because pc gadget started using assets update in rev 100, the spread test we have did not update mbr because if we screed that up the spread node would be inaccessible, and there was no unit test :) | 14:17 |
| mborzecki | (or there was a unit test but not for this particular 'mbr' type) | 14:17 |
| mvo | mborzecki: aha of course - that's fine then | 14:18 |
| mvo | mborzecki: so not criticial for beta, that's good | 14:18 |
| mvo | mborzecki: but nice to have | 14:18 |
| mborzecki | mvo: verified this locally in qemu updating pc gadget from 96 -> 100 | 14:18 |
| mborzecki | (still wodnering whether updating the boostrap bit in mbr is a good idea) | 14:19 |
| mborzecki | if this goes bad the chances of bricking the device is high | 14:20 |
| pstolowski | cachio: i need to think about this test | 14:20 |
| cachio | pstolowski, sure, thanks for checking it | 14:21 |
| pedronis | jdstrand: hi, irrespective of detailed review, I think in https://github.com/snapcore/snapd/pull/8592 a more specific interface would be better, do you have (different) input on that? | 14:29 |
| mup | PR #8592: Add initial support for the hardware-control interface <Created by devec0> <https://github.com/snapcore/snapd/pull/8592> | 14:29 |
| mborzecki | hmm session agent unit test panicked https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/3849/signedlogcontent/3?urlExpires=2020-05-07T14%3A34%3A52.7708746Z&urlSigningMethod=HMACV1&urlSignature=Cu8PuD6tbXaeK9XSQWsuVXqbd8jH%2B62vrOPPofc0KA0%3D | 14:34 |
| mborzecki | a better link https://paste.ubuntu.com/p/Cc4YQ4tCPQ/ | 14:34 |
| pedronis | mborzecki: it's actually wrappers that paniced, no? | 14:39 |
| mborzecki | more like it hit a timeout and go-check aumatically panicked | 14:41 |
| mborzecki | but it's weird why it'd timeout | 14:41 |
| pedronis | something deadlocked | 14:41 |
| pedronis | or didn't Stop | 14:41 |
| pedronis | seems the tests are running usersession for real | 14:41 |
| pedronis | and stop didn't work | 14:41 |
| pedronis | github.com/snapcore/snapd/usersession/agent.(*SessionAgent).Stop(0xc4204222d0, 0x0, 0x0) | 14:42 |
| pedronis | is sitting there for 4 minutes | 14:42 |
| pedronis | the http server bits are in Accept | 14:44 |
| mborzecki | mhm | 14:44 |
| pedronis | actualy there's a workaround added recently about this | 14:48 |
| pedronis | that doesn't seem to help | 14:48 |
| pedronis | mborzecki: what go version is that on? | 14:48 |
| mborzecki | pedronis: 1.9 | 14:49 |
| * zyga is still helping his parents | 14:51 | |
| pedronis | mborzecki: this is annoying(tm) | 14:55 |
| mborzecki | failed again | 14:56 |
| mborzecki | https://github.com/snapcore/snapd/runs/653302161 | 14:56 |
| mborzecki | at laest it's consistent | 14:56 |
| mborzecki | need to run an errand with the kids, bbl | 14:57 |
| pedronis | trying to run it locally with 1.9 | 15:02 |
| pedronis | a bunch of times | 15:02 |
| pstolowski | cachio: that tests passes on master for me (but i had to add installation of the .deb on the host) | 15:03 |
| cachio | pstolowski, works well on 20.04? | 15:05 |
| pstolowski | cachio: ah, i only checked 19.10 that was failing for you. let me run on 20.04 | 15:05 |
| cachio | pstolowski, sorry, 19.10 is working well now | 15:06 |
| cachio | 20.04 is failing with that error | 15:06 |
| pstolowski | aah | 15:06 |
| ijohnson | mborzecki: mvo: can't we avoid putting that into the beta by having the gadget snap just use assumes on a new snapd version? | 15:18 |
| mvo | ijohnson: oh, nice, yeah, that should work. I'm not sure we have assumes for pre versions yet :) | 15:19 |
| ijohnson | True that would only work 2.45 -> 2.46 right now | 15:19 |
| pedronis | mborzecki: it's not blocking here with 1.9.3, we are missing something | 15:27 |
| mup | PR snapd#8619 opened: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8619> | 15:34 |
| cmatsuoka | ijohnson, mvo: a quick fix for the recover mode cmdline: https://github.com/snapcore/snapd/pull/8619/files | 15:35 |
| mup | PR #8619: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8619> | 15:35 |
| ijohnson | cmatsuoka: ack looking now | 15:35 |
| cmatsuoka | ijohnson: feel free to push any fixes, I'll be back after lunch | 15:35 |
| cmatsuoka | ijohnson: I didn't actually test it in a real image | 15:40 |
| ijohnson | cmatsuoka: I'll test it out here for ya | 15:40 |
| ijohnson | hmm didn't work ootb | 15:59 |
| pstolowski | cachio: ok, i investigated (20.04 test fails for me too) | 16:01 |
| pstolowski | cachio: and i understand the issue | 16:01 |
| cachio | pstolowski, good, thanks for digging | 16:03 |
| pstolowski | cachio: is the .deb on the nested vm the official one from the distro? i assume so since it is version 2.44.3? | 16:04 |
| cachio | yes | 16:04 |
| pstolowski | right | 16:05 |
| pstolowski | cachio: so the issue is: the deb in the 20.04 image has a newer version of snapd than the one that is in seeds/ | 16:06 |
| pstolowski | cachio: snap-preseed mounts the vm image and runs snapd from seeds (the old one) | 16:06 |
| cachio | ahhh | 16:06 |
| pstolowski | cachio: then the vm is started, but since snapd from deb is newer it doesn't re-exec | 16:07 |
| cachio | pstolowski, is it easy to fix it? | 16:07 |
| pstolowski | cachio: so everything runs as expected, but the test expects that the snapd from seeds was used | 16:07 |
| pstolowski | cachio: the fix will be in test. we should probably inject latest snapd into seeds/ of the image (which i was doing intially in these tests some time ago) | 16:11 |
| cachio | pstolowski, right | 16:11 |
| pstolowski | i wonder if this is a valid scenario that we should handle better in preseeding, need to talk to pedronis | 16:11 |
| cachio | pstolowski, download snapd from beta/edge and copy it right? | 16:12 |
| pstolowski | cachio: that could work, or repack | 16:13 |
| pstolowski | yeah, edge would do | 16:13 |
| cachio | pstolowski, nice | 16:16 |
| cachio | are you testing this? | 16:16 |
| cachio | to see if it works? | 16:16 |
| pstolowski | cachio: no, not now, i can look at it tomorrow | 16:16 |
| cachio | pstolowski, ok, if I finish a fix I am doing I'll try to make it | 16:17 |
| pstolowski | cachio: it's a bit annoying as you need to mount the image, modify seed.yaml etc | 16:17 |
| cachio | pstolowski, ah, ok, well, in case you know the details you can do it :) | 16:18 |
| pstolowski | cachio: it was implemented initially in preseed.sh helpers, you can find it in git history | 16:18 |
| cachio | no hurry | 16:18 |
| pstolowski | cachio: ok, sure, i can do it | 16:19 |
| cachio | pstolowski, thanks | 16:19 |
| pstolowski | yw | 16:20 |
| * cachio lunch | 16:22 | |
| mup | PR core20#56 opened: Revert "Add secureboot-db" <Created by xnox> <https://github.com/snapcore/core20/pull/56> | 16:36 |
| mup | PR core20#56 closed: Revert "Add secureboot-db" <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/56> | 16:39 |
| mup | PR pc-amd64-gadget#47 opened: gadget: bump edition to 2, using production signing keys for everything <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/47> | 17:25 |
| mup | PR snapcraft#3109 opened: pcache: introduce persistent cache decorator <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3109> | 17:58 |
| cachio | zyga, hey, I see this error in un18 https://paste.ubuntu.com/p/7yxW5zcspd/ | 18:06 |
| cachio | uc18 | 18:06 |
| cachio | zyga, is this something that you have change right? Initially the test fails like this https://paste.ubuntu.com/p/tM9HDxWsMp/ | 18:08 |
| mup | PR snapcraft#3110 opened: repo: use persistent cache for fetching stage packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3110> | 18:13 |
| mup | PR pc-amd64-gadget#47 closed: gadget: bump edition to 2, using production signing keys for everything <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/47> | 18:30 |
| jdstrand | pedronis: re 8592. yes, 'hardware-control' is way too general. also, it says it is for 'lspci -A linux-sysfs', but that command is read-only (and the r access is in hardware-observe) | 18:40 |
| jdstrand | pedronis: beyond the name, 'w' access over a huge swath of /sys is too general | 18:41 |
| pedronis | jdstrand: yes, that's what I thought as well | 18:41 |
| pedronis | I asked to propose something more specific to the use case, it will be also clearer what the access really is | 18:41 |
| jdstrand | pedronis: we have a cpu-control interface that this might fit in, or perhaps fan-control. I think we need to understand all the desired accesses. running lm-sensors to configure the host from a snap... ehh | 18:42 |
| jdstrand | pedronis: but we can look at it | 18:42 |
| pedronis | jdstrand: yes, I also mentioned that maybe there is one were it can fit already | 18:43 |
| pedronis | *where | 18:43 |
| jdstrand | tbc, we have cpu-control, fan-control would be new, but the submitter likely wants a lot of different accesses. we should look at them all specifically to decide how to organize | 18:44 |
| jdstrand | emitorino: fyi ^ | 18:45 |
| mup | PR snapd#8620 opened: Adds GPL-3.0-or-later license <Created by prabhu> <https://github.com/snapcore/snapd/pull/8620> | 19:15 |
| === KindTwo is now known as KindOne | ||
| mup | PR snapd#8618 closed: gadget: fix fallback device lookup for 'mbr' type structures <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8618> | 19:52 |
| mup | PR snapd#8619 closed: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline <Squash-merge> <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8619> | 19:53 |
| mup | PR snapd#8616 closed: progress: tweak multibyte label unit test data <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8616> | 19:55 |
| mup | PR snapd#8621 opened: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline, unlock in recover mode initramfs <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8621> | 20:00 |
| mup | PR snapd#8622 opened: cmd/snap-bootstrap/initramfs-mounts: add sudoers to dirs to copy as well <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8622> | 20:32 |
| mup | PR snapd#8621 closed: o/devicestate,cmd/snap-bootstrap: seal to recover mode cmdline, unlock in recover mode initramfs <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8621> | 20:40 |
| om26er | Hi! How does the Snap Store calculate "territory" matrix ? Is there a place where I could read about the technical information about that ? Is that anonymous ? | 21:22 |
| om26er | https://snapcraft.io/docs/snap-store-metrics -- The page I found, does not answer my question | 21:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!