[01:07] PR snapcraft#3157 opened: spread: use absolute path to lxd [03:46] PR snapd#8817 opened: tests: new test to validate refresh and revert of kernel and gadget on uc20 [06:40] morning [06:42] Hey [06:44] zyga: hey hey [06:46] hey mborzecki and zyga [07:02] morning [07:03] hey, I just had to do something weird to log in [07:04] can you guys please check if you are a member of group "video" [07:04] and if /dev/dri/card0 is group-owned by that file [07:04] er [07:04] group [07:05] I had to add myself to the video group [07:05] as otherwise gdm would fail to start the session for my account [07:12] zyga: I'm not in video [07:12] zyga: on 20.04 [07:12] thanks [07:12] hmm (I'm on 20.10) [07:12] what's the ownership of /dev/dri/card0? [07:36] zyga: root:video [07:36] thanks [07:36] I talked in #ubuntu-devel a little and normally logind would grant extra permissions to my account [07:36] so something on that line is broken [07:36] oh well, the fun of running devel :) [07:37] thank you for checking [07:37] I will finish coffee and jump into PRs [07:41] zyga: funny, i'm in video group [07:41] wonder what happens when i drop that [07:42] zyga: do you have any other ideas about https://forum.snapcraft.io/t/notification-on-reboot-initiation-or-coming-up-from-reboot/18005 ? [07:42] looking [07:43] mborzecki: /tmp as seen by a snap is not discarded on refresh [07:44] zyga: ha, so maybe that could be used then [07:45] anyways, this feels like thin ice [07:45] hi, how do I get a snap out of --devmode without reinstalling? [07:46] mborzecki: yeah, I replied [07:46] ackk: hmmm good question [07:46] zyga: thanks! [07:46] I think there's no way actually, maybe refresh --strict but I don't remember if we forward that [07:47] ackk: maybe snap revert --revision but not sure [07:47] pedronis: hey, wdyt about mechanical splitting of snapstate_test.go by "topics", e.g. snapstate_install_test.go, snapstate_update_test.go, snapstate_try_test.go etc? no new test suites to be clear. it's 16K+ lines, very hard to navigate :( [07:47] * ackk tries [07:47] --strict is not accepted by refresh [07:48] revert also doesn't seem to work if you try to revert to the same revision [07:50] pstolowski: it's a good idea, but we would need to think a bit how to tackle it [07:51] pedronis: how about if i propose just a few obvious ones? do you have particular concern in mind? [07:52] pstolowski: mostly conflict for wip work [07:52] mvo: https://github.com/snapcore/snapd/pull/8722#issuecomment-639319127 heh a bit unexpected [07:52] PR #8722: tests: check that host settings like hostname are settable on core [07:52] also there might be some corner cases where is not clear but maybe that isn't true [07:54] pedronis: I updated the netplan thing [07:54] mborzecki: oh, woah, unexpected indeed! [07:59] pedronis: yes, would be good to avoid conflicts with wip. and i suppose we will have some tests that cross many boundaries, in which case they fall into a "generic" category, i.e. snapstate_test.go [08:00] mborzecki: updated https://github.com/snapcore/snapd/pull/8815 [08:00] PR #8815: tests: port snap-handle-link test to tests.session [08:04] pstolowski: I would start with snapstate_install_test.go I suppose ? [08:04] that would be tests that involve mainly snapstate.Install and snapstate.InstallPath [08:05] I suppose [08:05] pedronis: yes, that's a good candidate [08:06] notice though sometimes they are used to setup conflicts for other things, but hopefully the test name/content makes that clear [08:11] zyga, pedronis so I guess the only way to get out of devmode is to wait for an update and then refresh without devmode, right? [08:13] seems so, though is a legitimate request (not super high prio) to have a local way [08:14] perhaps snap switch could grow an option [08:15] mabye but switch never unlink/link atm [08:15] and this would need to [08:16] or some subset of that [08:16] mmmm [08:17] why would we have to unlink? [08:17] well, it would need to stop all services for example [08:17] it's refresh like in some ways [08:17] yeah, stop, flip flags, setup security, start [08:18] just saying it's not super clear that switch is a good syntax for it [08:19] ackk: I think filing a bug and letting us eventually get to it is the way forward [08:19] zyga, ok, thanks [08:19] given how it works, I actually switch would probably just change the flag for the next refresh [08:19] *actually think [08:19] pedronis: ideed, you are right [08:20] that would break some invariants though, so not sure we can add it to switch [08:21] anyway some form of revert or refresh would do [08:23] * zyga afk for a moment, I'll try to move to the office today [08:29] maybe no [08:29] I cannot stand for a while even === diddledan0 is now known as diddledan [08:39] mvo: updated https://github.com/snapcore/snapd/pull/8804 [08:39] PR #8804: tests: port xdg-settings test to tests.session [08:41] zyga, filed https://bugs.launchpad.net/snapd/+bug/1882214 [08:41] Bug #1882214: No way to move out of devmode without updates or reinstall [08:41] thanks! [08:42] PR snapd#8819 opened: tests: move install tests from snapstate_test.go to snapstate_install_test.go [08:45] ^ for obvious reason would be nice to land it soon ;) [08:47] pstolowski: verifyInstallTasks should move too? [08:48] or is it used for update as well? [08:48] pedronis: it's used by transition and installmany tests [08:48] pedronis: and by gadgetupdate tests [08:49] pstolowski: I think I would move it anyway, also move the InstallMany ones [08:49] I forgot about them [08:49] okay [08:51] of course git diff is weird and looks like you changed things and not just removed them :/ [08:53] heh all spread jobs passed, but the travis job failed on osx :P [08:54] pedronis: heh, indeed, complete mess [08:55] mborzecki: how? [08:55] pstolowski: I'm busy now, but I'll try to look at it again immediately after lunch [08:55] mborzecki: maybe spend a moment to port the macos job over [08:55] zyga: some random bit about osx host not coming up [08:56] even more reason to do it [08:56] just add a new job for it and that should be it [08:56] iirc we saw this happen couple of times [08:56] zyga: gh can do osx too? [08:56] I used this in libzt if that helps: https://github.com/zyga/libzt/blob/master/.github/workflows/build.yml#L18 [08:56] yes :) [08:57] go is preinstalled IIRC [08:57] mborzecki: and it's macos for a few years now :) [08:57] osx was the old name [08:57] mborzecki: yes, it has different limits than other jobs, not sure it/how it matters [08:58] pedronis: thanks [08:58] pedronis: there are no different limits *but* a macos job is like 2 other jobs [08:58] pedronis: zyga: i can try and port it over, should be a quick job [08:58] but it shold not matter much as our tests are quick and won't use the slots for long [08:59] mvo: can you cherry-pick https://github.com/snapcore/snapd/pull/8798 to 2.45? should apply cleanly [08:59] PR #8798: data/selinux: allow checking /var/cache/app-info [09:00] mborzecki: sure, will do [09:00] mvo: thanks! [09:03] PR snapd#8798 closed: data/selinux: allow checking /var/cache/app-info [09:03] if you encounter a "cancelled" test just restart, sorry my fault === ricab__ is now known as ricab [09:03] mborzecki: meh, 7 commit, I will create a 2.45 branch for this [09:04] * mvo should have marked this squash-merge [09:04] mvo: i can do that [09:04] mborzecki: yes please! [09:05] mvo: I need to show you how to cherry pick ranges [09:05] it's not a problem really [09:05] zyga: :) [09:10] zyga: what do you use for that? it's easy for a branch that was not landed, but my usual incantation is not useful when a branch got merged upstream [09:11] (probably because i list commits that are not part of a branch, and once landed that no longer lists anything) [09:11] mborzecki: look at the branch, get the base and the tip, [09:11] I did it a few times [09:11] worked okay [09:13] PR snapd#8820 opened: data/selinux: allow checking /var/cache/app-info (2.45) [09:13] zyga: at the base i use `git log --oneline --decorate HEAD '^'`, but the helpers i use cannot automatically figure out to use the the commit before the merge that included the changes upstream [09:15] Bug #1882221 opened: Cannot parse seccomp profile in snapd update [09:18] Bug #1882221 changed: Cannot parse seccomp profile in snapd update [09:21] Bug #1882221 opened: Cannot parse seccomp profile in snapd update [09:26] mborzecki: huh [09:26] https://bugs.launchpad.net/snappy/+bug/1882221 is bad [09:26] Bug #1882221: Cannot parse seccomp profile in snapd update [09:26] I need to go afk, I'll look soon [09:27] hmm [09:27] Bug #1882221 changed: Cannot parse seccomp profile in snapd update [09:30] Bug #1882221 opened: Cannot parse seccomp profile in snapd update [09:33] Bug #1882221 changed: Cannot parse seccomp profile in snapd update [09:39] Bug #1882221 opened: Cannot parse seccomp profile in snapd update [09:48] PR snapd#8821 opened: github: port macOS sanity checks from travis [09:51] mborzecki: do you have any fail logs for ^ / [09:51] ? [09:52] i have homebrew locally and can check something out, but don't know yet how it maps to github actions [09:53] mborzecki: https://formulae.brew.sh/formula/squashfs is the forumla [09:54] I' -1 on using a 3rd party action [09:54] especially if it is just "brew install" [09:54] mborzecki: maybe you need brew install --with-xz --with-zstd [09:54] pstolowski: ^ can you check [09:55] I should just install brew I guess [09:56] ah, the question is about how to install manually [09:56] brew install squashfs [09:56] works [09:56] so that's all we need [09:56] brew is preinstalled in those images [09:56] right/ [09:56] installs squashfs-4.4 [09:56] no args needed [09:56] pstolowski: maybe check if it has xz and zstd [09:56] can it unsquash a test .snap [09:56] zyga: Installing dependencies for squashfs: lz4, lzo and zstd [09:56] no mention of xz [09:56] maybe xz is preinstalled [09:56] anyway [09:57] just check with any snap if you can [09:57] btw, I just noticed brew works on linux [09:57] maybe a nice way to build ... snaps [09:57] interesting [09:57] just bake a custom prefix, something brew can do [09:57] hm looks like you can fix whatever needed there ;) [09:57] zyga: i find brew a must on mac [09:58] hmmm [09:58] w8, why there's no job there? [09:58] does mvo need to enable something? [09:58] because you called this job cla-check [09:59] :) [09:59] hm? [09:59] w8, wat? [09:59] pfff [09:59] hah [09:59] look at the PR [09:59] hhahah [09:59] I commented [10:00] a sneaky way to pass cla checks;D [10:00] zyga, mborzecki i'll check if ^ works on mac after 1-1 [10:00] https://github.com/snapcore/snapd/actions/runs/125815205 [10:00] it's also wrong [10:01] IIRC args are [] [10:01] but check the docs please [10:05] mborzecki: some early opinion on https://github.com/snapcore/snapd/pull/7700 would be great [10:05] PR #7700: cmd/snap: wait while inhibition file is present [10:05] it's WIP code [10:05] pedronis: and for you https://github.com/snapcore/snapd/pull/8573 -- equally WIP and super tiny - just to start the conversation [10:05] PR #8573: overlord/snapstate: inhibit startup while unlinked [10:06] mborzecki: did you see https://github.com/snapcore/snapd/pull/8821/files#r435820550 [10:06] PR #8821: github: port macOS sanity checks from travis [10:07] mborzecki: this is what GH says https://github.com/snapcore/snapd/actions/runs/125824530 [10:07] zyga: yeah, but i'm not sure what's wrong there, yaml is valid, the entrypoint in the action is basically `brew $*` [10:07] yeah but that's not the right yaml [10:07] there's a different way to say that [10:07] let me find that [10:07] hm maybe it shoudl be under `with:` [10:07] look at https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions [10:07] yeah [10:07] exactly :) [10:07] I think you can also drop the "" [10:10] hmm [10:10] maybe just do that manually [10:10] I don't know what that action does [10:10] did you read the code? [10:11] zyga: yeah, it literally calls brew $* [10:11] https://github.com/artemnovichkov/action-homebrew [10:11] then really just do it yourself [10:11] less magic [10:14] in the meantime, i'm not sure how https://bugs.launchpad.net/snappy/+bug/1882221 happened [10:14] Bug #1882221: Cannot parse seccomp profile in snapd update [10:14] zyga: hey o/ [10:14] zyga: should snap-seccomp re-exec ? [10:14] hey ian :) [10:14] ijohnson: snapd should call it from the same location as the snapd binary is running [10:14] mborzecki: but what about for folks that are developing their own profiles [10:15] IIRC we call it with full path [10:15] i.e. you are hacking on a seccomp / apparmor snapd profile to test things [10:15] ijohnson: what do you mean? [10:15] jamesh: are you asking about https://bugs.launchpad.net/snappy/+bug/1882221? [10:15] Bug #1882221: Cannot parse seccomp profile in snapd update [10:15] er [10:15] ijohnson: ^ [10:15] like locally changing the profile.bin in /usr/lib/snapd/seccomp/snap....src [10:15] and then compiling it [10:16] zyga: yes [10:16] also https://forum.snapcraft.io/t/cannot-parse-seccomp-profile-in-snapd-update/18007/5 [10:16] right [10:16] so no [10:16] I can reproduce the error here [10:16] ijohnson: they should call whatever version is appropriate i suppose [10:16] how? [10:16] right but how would they know which version is appropriate ? [10:16] ijohnson: they're already ahcking the profile so i would guess they can figure that out ? :) [10:17] developing a profile is something like what developers do [10:17] so minimal requirement is probably awareness of snapd source / build [10:17] zyga: to reproduce, launch a bionic VM/lxd container, then downgrade snapd as a deb to bionic-security, (and ensure all snaps are removed), then try to use snap-seccomp [10:17] though [10:17] I'm really curious [10:17] ah [10:17] ok [10:17] but snapd re-exec semantics can be quite confusing [10:17] ijohnson: so snap-seccomp from 2.37 then? [10:17] you answered my question [10:17] mborzecki: yes [10:17] before we supported chown stuff for system-usernames [10:17] ijohnson: my answer is don't do that I think [10:18] :-( [10:18] hm it might have been built with a different libseccomp version even [10:18] ijohnson: don't do development on top of really old snapd [10:18] (and probably was) [10:18] zyga: they are not on an old version of snapd [10:18] zyga: they have the core / snapd snap installed and have 2.45 [10:18] 2.37 is old [10:18] but the deb on their system is old [10:18] that's what I mean [10:18] zyga: but `snap version` says 2.45 ? [10:19] I think we should move everone over to snapd.snap, then the anwer is really easy [10:19] zyga: so what you're saying is that if folks are developing they need to keep both their normal snapd version up to date AND also keep the deb up to date even though no actual snaps / snapd the daemon are using the deb? [10:19] zyga: tbc, this person's machine only has bionic-security pocket enabled [10:20] zyga: so they won't ever get the deb unless they upgrade out of that pocket [10:20] w8, something is weird i think [10:20] (or we push an update to the bionic-security pocket with a new snapd I suppose) [10:20] I think the user experience here is quite poor [10:21] either snap-seccomp should re-exec or we should have snap-seccomp complain when it is not a matching version to the one that snapd the daemon is using [10:21] ijohnson: hm or no, so snapd is updated to 2.45, snapd and snap rexxec, snapd gnerates the profile that can be complied by snap-seccomp from the snapd/core snap, but it does not imply that the old snap-seccomp from the deb can do that [10:21] mborzecki: yes all the snaps work on their system right now [10:22] mborzecki: but they are developing changes to an interface in snapd [10:22] mborzecki: and the documented best practice to change seccomp is broken [10:22] ijohnson: where's that doc? maybe we need to update it [10:22] mborzecki: but what would you update it to ? [10:23] to tell people re-exec happens [10:23] ijohnson: use snapd from the ppa/roll out your own & disable reexec [10:23] mborzecki: say "if you have snapd snap use /snap/snapd/current/... if you have core snap use /snap/core/current/... if you have snapd distro pkg, use /usr/lib/snapd/..." [10:23] ijohnson: i mean that's what i do :P [10:23] and the snap-seccom binary is in /snap/{snapd,core}/current/usr/lib/snapd/snap-seccomp [10:23] but I mean you see how that's a frustrating and confusing user experience [10:23] right? [10:23] ijohnson: it's should probably be look at /proc//exec to find out which snapd binary is runnig, call snap-seccomp from the same location [10:24] (this is what snapd does iirc) [10:24] IMO that's all a bit too magic [10:24] I would not do that [10:25] zyga: it's not too magic to you because you've worked on snapd too long :-D [10:25] I mean, it is too magic [10:25] the re-exec logic is complex [10:25] I would not teach people about it [10:25] a snap debug command then? [10:25] right so why shouldn't we just make snap-seccomp do the same magic ? [10:25] I would rather have them know where the tools come from [10:25] ijohnson: because not all tools re-exec [10:25] a snap debug command makes sense to me [10:25] I really would not go overboard with this [10:26] zyga: but why don't all tools re-exec though [10:26] because it's hard and they cannot for other reasons [10:26] if some things re-exec and some things don't re-exec that is confusing and unexpected [10:26] snap-update-ns and snap-confine probably never well [10:26] *will [10:26] ijohnson: that's just the nature of the beast [10:26] :-( [10:27] I would argue that re-exec could be a helper tool that is used by everything [10:27] (that re-execs) [10:27] not by everything [10:27] so then this is more visible [10:27] maybe with maciek's idea to merge snapd and snap [10:27] ijohnson: the reexec thing is a tad complicated imo, it looks at the env, then at the distro, we'd ahve to bake it into each binary [10:27] snapd is just "snap snapd" [10:28] or snap exec-tool snapd [10:28] or something similar [10:28] snap debug exec-tool ? [10:28] it's not debug if we'd use it to run snapd :) [10:28] I would actually call it something else [10:29] snap exec-tool ... [10:29] and not reexec or debug [10:29] it's just a way to run a tool [10:29] a bit like snapd.tool [10:29] anyways, for starters we cold probably document the 'magic' thing first to make it clear [10:29] then it could do the right thing [10:30] ijohnson: do you know where the istructions for compiling profiles are? [10:30] mborzecki: offtopic: https://github.com/snapcore/snapd/pull/8821/checks?check_run_id=741848615 [10:30] PR #8821: github: port macOS sanity checks from travis [10:30] mborzecki: let me find it it was on docs.ubuntu.com/core somewhere [10:30] ijohnson: the search on docs.snapcraft.io comes up empty [10:30] I think some environment is not set up right [10:31] or perhaps something else is wrong [10:31] look at the import failures [10:32] ijohnson: there's some tips towrads the end of this page https://docs.ubuntu.com/core/en/guides/intro/security [10:32] mborzecki: yes that page [10:33] mborzecki: there's also https://github.com/snapcore/snapd/wiki/snap-confine-Overview [10:33]