| mup | PR snapcraft#3157 opened: spread: use absolute path to lxd <tooling> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3157> | 01:07 |
|---|---|---|
| mup | PR snapd#8817 opened: tests: new test to validate refresh and revert of kernel and gadget on uc20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8817> | 03:46 |
| mborzecki | morning | 06:40 |
| zyga | Hey | 06:42 |
| mborzecki | zyga: hey hey | 06:44 |
| mvo | hey mborzecki and zyga | 06:46 |
| pstolowski | morning | 07:02 |
| zyga | hey, I just had to do something weird to log in | 07:03 |
| zyga | can you guys please check if you are a member of group "video" | 07:04 |
| zyga | and if /dev/dri/card0 is group-owned by that file | 07:04 |
| zyga | er | 07:04 |
| zyga | group | 07:04 |
| zyga | I had to add myself to the video group | 07:05 |
| zyga | as otherwise gdm would fail to start the session for my account | 07:05 |
| mvo | zyga: I'm not in video | 07:12 |
| mvo | zyga: on 20.04 | 07:12 |
| zyga | thanks | 07:12 |
| zyga | hmm (I'm on 20.10) | 07:12 |
| zyga | what's the ownership of /dev/dri/card0? | 07:12 |
| mvo | zyga: root:video | 07:36 |
| zyga | thanks | 07:36 |
| zyga | I talked in #ubuntu-devel a little and normally logind would grant extra permissions to my account | 07:36 |
| zyga | so something on that line is broken | 07:36 |
| zyga | oh well, the fun of running devel :) | 07:36 |
| zyga | thank you for checking | 07:37 |
| zyga | I will finish coffee and jump into PRs | 07:37 |
| mborzecki | zyga: funny, i'm in video group | 07:41 |
| mborzecki | wonder what happens when i drop that | 07:41 |
| mborzecki | 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 |
| zyga | looking | 07:42 |
| zyga | mborzecki: /tmp as seen by a snap is not discarded on refresh | 07:43 |
| mborzecki | zyga: ha, so maybe that could be used then | 07:44 |
| mborzecki | anyways, this feels like thin ice | 07:45 |
| ackk | hi, how do I get a snap out of --devmode without reinstalling? | 07:45 |
| zyga | mborzecki: yeah, I replied | 07:46 |
| zyga | ackk: hmmm good question | 07:46 |
| mborzecki | zyga: thanks! | 07:46 |
| zyga | I think there's no way actually, maybe refresh --strict but I don't remember if we forward that | 07:46 |
| pedronis | ackk: maybe snap revert --revision but not sure | 07:47 |
| pstolowski | 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 | |
| ackk | --strict is not accepted by refresh | 07:47 |
| ackk | revert also doesn't seem to work if you try to revert to the same revision | 07:48 |
| pedronis | pstolowski: it's a good idea, but we would need to think a bit how to tackle it | 07:50 |
| pstolowski | pedronis: how about if i propose just a few obvious ones? do you have particular concern in mind? | 07:51 |
| pedronis | pstolowski: mostly conflict for wip work | 07:52 |
| mborzecki | mvo: https://github.com/snapcore/snapd/pull/8722#issuecomment-639319127 heh a bit unexpected | 07:52 |
| mup | PR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722> | 07:52 |
| pedronis | also there might be some corner cases where is not clear but maybe that isn't true | 07:52 |
| mvo | pedronis: I updated the netplan thing | 07:54 |
| mvo | mborzecki: oh, woah, unexpected indeed! | 07:54 |
| pstolowski | 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 | 07:59 |
| zyga | mborzecki: updated https://github.com/snapcore/snapd/pull/8815 | 08:00 |
| mup | PR #8815: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815> | 08:00 |
| pedronis | pstolowski: I would start with snapstate_install_test.go I suppose ? | 08:04 |
| pedronis | that would be tests that involve mainly snapstate.Install and snapstate.InstallPath | 08:04 |
| pedronis | I suppose | 08:05 |
| pstolowski | pedronis: yes, that's a good candidate | 08:05 |
| pedronis | notice though sometimes they are used to setup conflicts for other things, but hopefully the test name/content makes that clear | 08:06 |
| ackk | 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:11 |
| pedronis | seems so, though is a legitimate request (not super high prio) to have a local way | 08:13 |
| zyga | perhaps snap switch could grow an option | 08:14 |
| pedronis | mabye but switch never unlink/link atm | 08:15 |
| pedronis | and this would need to | 08:15 |
| pedronis | or some subset of that | 08:16 |
| zyga | mmmm | 08:16 |
| zyga | why would we have to unlink? | 08:17 |
| pedronis | well, it would need to stop all services for example | 08:17 |
| pedronis | it's refresh like in some ways | 08:17 |
| zyga | yeah, stop, flip flags, setup security, start | 08:17 |
| pedronis | just saying it's not super clear that switch is a good syntax for it | 08:18 |
| zyga | ackk: I think filing a bug and letting us eventually get to it is the way forward | 08:19 |
| ackk | zyga, ok, thanks | 08:19 |
| pedronis | given how it works, I actually switch would probably just change the flag for the next refresh | 08:19 |
| pedronis | *actually think | 08:19 |
| zyga | pedronis: ideed, you are right | 08:19 |
| pedronis | that would break some invariants though, so not sure we can add it to switch | 08:20 |
| pedronis | anyway some form of revert or refresh would do | 08:21 |
| * zyga afk for a moment, I'll try to move to the office today | 08:23 | |
| zyga | maybe no | 08:29 |
| zyga | I cannot stand for a while even | 08:29 |
| === diddledan0 is now known as diddledan | ||
| zyga | mvo: updated https://github.com/snapcore/snapd/pull/8804 | 08:39 |
| mup | PR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804> | 08:39 |
| ackk | zyga, filed https://bugs.launchpad.net/snapd/+bug/1882214 | 08:41 |
| mup | Bug #1882214: No way to move out of devmode without updates or reinstall <snapd:New> <https://launchpad.net/bugs/1882214> | 08:41 |
| zyga | thanks! | 08:41 |
| mup | PR snapd#8819 opened: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8819> | 08:42 |
| pstolowski | ^ for obvious reason would be nice to land it soon ;) | 08:45 |
| pedronis | pstolowski: verifyInstallTasks should move too? | 08:47 |
| pedronis | or is it used for update as well? | 08:48 |
| pstolowski | pedronis: it's used by transition and installmany tests | 08:48 |
| pstolowski | pedronis: and by gadgetupdate tests | 08:48 |
| pedronis | pstolowski: I think I would move it anyway, also move the InstallMany ones | 08:49 |
| pedronis | I forgot about them | 08:49 |
| pstolowski | okay | 08:49 |
| pedronis | of course git diff is weird and looks like you changed things and not just removed them :/ | 08:51 |
| mborzecki | heh all spread jobs passed, but the travis job failed on osx :P | 08:53 |
| pstolowski | pedronis: heh, indeed, complete mess | 08:54 |
| zyga | mborzecki: how? | 08:55 |
| pedronis | pstolowski: I'm busy now, but I'll try to look at it again immediately after lunch | 08:55 |
| zyga | mborzecki: maybe spend a moment to port the macos job over | 08:55 |
| mborzecki | zyga: some random bit about osx host not coming up | 08:55 |
| zyga | even more reason to do it | 08:56 |
| zyga | just add a new job for it and that should be it | 08:56 |
| mborzecki | iirc we saw this happen couple of times | 08:56 |
| mborzecki | zyga: gh can do osx too? | 08:56 |
| zyga | I used this in libzt if that helps: https://github.com/zyga/libzt/blob/master/.github/workflows/build.yml#L18 | 08:56 |
| zyga | yes :) | 08:56 |
| zyga | go is preinstalled IIRC | 08:57 |
| zyga | mborzecki: and it's macos for a few years now :) | 08:57 |
| zyga | osx was the old name | 08:57 |
| pedronis | mborzecki: yes, it has different limits than other jobs, not sure it/how it matters | 08:57 |
| pstolowski | pedronis: thanks | 08:58 |
| zyga | pedronis: there are no different limits *but* a macos job is like 2 other jobs | 08:58 |
| mborzecki | pedronis: zyga: i can try and port it over, should be a quick job | 08:58 |
| zyga | but it shold not matter much as our tests are quick and won't use the slots for long | 08:58 |
| mborzecki | mvo: can you cherry-pick https://github.com/snapcore/snapd/pull/8798 to 2.45? should apply cleanly | 08:59 |
| mup | PR #8798: data/selinux: allow checking /var/cache/app-info <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8798> | 08:59 |
| mvo | mborzecki: sure, will do | 09:00 |
| mborzecki | mvo: thanks! | 09:00 |
| mup | PR snapd#8798 closed: data/selinux: allow checking /var/cache/app-info <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8798> | 09:03 |
| zyga | if you encounter a "cancelled" test just restart, sorry my fault | 09:03 |
| === ricab__ is now known as ricab | ||
| mvo | mborzecki: meh, 7 commit, I will create a 2.45 branch for this | 09:03 |
| * mvo should have marked this squash-merge | 09:04 | |
| mborzecki | mvo: i can do that | 09:04 |
| mvo | mborzecki: yes please! | 09:04 |
| zyga | mvo: I need to show you how to cherry pick ranges | 09:05 |
| zyga | it's not a problem really | 09:05 |
| mvo | zyga: :) | 09:05 |
| mborzecki | 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:10 |
| mborzecki | (probably because i list commits that are not part of a branch, and once landed that no longer lists anything) | 09:11 |
| zyga | mborzecki: look at the branch, get the base and the tip, | 09:11 |
| zyga | I did it a few times | 09:11 |
| zyga | worked okay | 09:11 |
| mup | PR snapd#8820 opened: data/selinux: allow checking /var/cache/app-info (2.45) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8820> | 09:13 |
| mborzecki | zyga: at the base i use `git log --oneline --decorate HEAD '^<other-branch|rev>'`, but the helpers i use cannot automatically figure out to use the the commit before the merge that included the changes upstream | 09:13 |
| mup | Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:15 |
| mup | Bug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:18 |
| mup | Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:21 |
| zyga | mborzecki: huh | 09:26 |
| zyga | https://bugs.launchpad.net/snappy/+bug/1882221 is bad | 09:26 |
| mup | Bug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:26 |
| zyga | I need to go afk, I'll look soon | 09:26 |
| mborzecki | hmm | 09:27 |
| mup | Bug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:27 |
| mup | Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:30 |
| mup | Bug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:33 |
| mup | Bug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 09:39 |
| mup | PR snapd#8821 opened: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 09:48 |
| pstolowski | mborzecki: do you have any fail logs for ^ / | 09:51 |
| pstolowski | ? | 09:51 |
| pstolowski | i have homebrew locally and can check something out, but don't know yet how it maps to github actions | 09:52 |
| zyga | mborzecki: https://formulae.brew.sh/formula/squashfs is the forumla | 09:53 |
| zyga | I' -1 on using a 3rd party action | 09:54 |
| zyga | especially if it is just "brew install" | 09:54 |
| zyga | mborzecki: maybe you need brew install --with-xz --with-zstd | 09:54 |
| zyga | pstolowski: ^ can you check | 09:54 |
| zyga | I should just install brew I guess | 09:55 |
| pstolowski | ah, the question is about how to install manually | 09:56 |
| pstolowski | brew install squashfs | 09:56 |
| pstolowski | works | 09:56 |
| zyga | so that's all we need | 09:56 |
| zyga | brew is preinstalled in those images | 09:56 |
| zyga | right/ | 09:56 |
| pstolowski | installs squashfs-4.4 | 09:56 |
| pstolowski | no args needed | 09:56 |
| zyga | pstolowski: maybe check if it has xz and zstd | 09:56 |
| zyga | can it unsquash a test .snap | 09:56 |
| pstolowski | zyga: Installing dependencies for squashfs: lz4, lzo and zstd | 09:56 |
| pstolowski | no mention of xz | 09:56 |
| zyga | maybe xz is preinstalled | 09:56 |
| zyga | anyway | 09:56 |
| zyga | just check with any snap if you can | 09:57 |
| zyga | btw, I just noticed brew works on linux | 09:57 |
| zyga | maybe a nice way to build ... snaps | 09:57 |
| pstolowski | interesting | 09:57 |
| zyga | just bake a custom prefix, something brew can do | 09:57 |
| mborzecki | hm looks like you can fix whatever needed there ;) | 09:57 |
| pstolowski | zyga: i find brew a must on mac | 09:57 |
| mborzecki | hmmm | 09:58 |
| mborzecki | w8, why there's no job there? | 09:58 |
| mborzecki | does mvo need to enable something? | 09:58 |
| zyga | because you called this job cla-check | 09:58 |
| zyga | :) | 09:59 |
| mvo | hm? | 09:59 |
| mborzecki | w8, wat? | 09:59 |
| mborzecki | pfff | 09:59 |
| zyga | hah | 09:59 |
| zyga | look at the PR | 09:59 |
| mborzecki | hhahah | 09:59 |
| zyga | I commented | 09:59 |
| zyga | a sneaky way to pass cla checks;D | 10:00 |
| pstolowski | zyga, mborzecki i'll check if ^ works on mac after 1-1 | 10:00 |
| zyga | https://github.com/snapcore/snapd/actions/runs/125815205 | 10:00 |
| zyga | it's also wrong | 10:00 |
| zyga | IIRC args are [] | 10:01 |
| zyga | but check the docs please | 10:01 |
| zyga | mborzecki: some early opinion on https://github.com/snapcore/snapd/pull/7700 would be great | 10:05 |
| mup | PR #7700: cmd/snap: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700> | 10:05 |
| zyga | it's WIP code | 10:05 |
| zyga | pedronis: and for you https://github.com/snapcore/snapd/pull/8573 -- equally WIP and super tiny - just to start the conversation | 10:05 |
| mup | PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573> | 10:05 |
| zyga | mborzecki: did you see https://github.com/snapcore/snapd/pull/8821/files#r435820550 | 10:06 |
| mup | PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 10:06 |
| zyga | mborzecki: this is what GH says https://github.com/snapcore/snapd/actions/runs/125824530 | 10:07 |
| mborzecki | zyga: yeah, but i'm not sure what's wrong there, yaml is valid, the entrypoint in the action is basically `brew $*` | 10:07 |
| zyga | yeah but that's not the right yaml | 10:07 |
| zyga | there's a different way to say that | 10:07 |
| zyga | let me find that | 10:07 |
| mborzecki | hm maybe it shoudl be under `with:` | 10:07 |
| zyga | look at https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions | 10:07 |
| zyga | yeah | 10:07 |
| zyga | exactly :) | 10:07 |
| zyga | I think you can also drop the "" | 10:07 |
| zyga | hmm | 10:10 |
| zyga | maybe just do that manually | 10:10 |
| zyga | I don't know what that action does | 10:10 |
| zyga | did you read the code? | 10:10 |
| mborzecki | zyga: yeah, it literally calls brew $* | 10:11 |
| mborzecki | https://github.com/artemnovichkov/action-homebrew | 10:11 |
| zyga | then really just do it yourself | 10:11 |
| zyga | less magic | 10:11 |
| mborzecki | in the meantime, i'm not sure how https://bugs.launchpad.net/snappy/+bug/1882221 happened | 10:14 |
| mup | Bug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 10:14 |
| ijohnson | zyga: hey o/ | 10:14 |
| ijohnson | zyga: should snap-seccomp re-exec ? | 10:14 |
| zyga | hey ian :) | 10:14 |
| mborzecki | ijohnson: snapd should call it from the same location as the snapd binary is running | 10:14 |
| ijohnson | mborzecki: but what about for folks that are developing their own profiles | 10:14 |
| zyga | IIRC we call it with full path | 10:15 |
| ijohnson | i.e. you are hacking on a seccomp / apparmor snapd profile to test things | 10:15 |
| mborzecki | ijohnson: what do you mean? | 10:15 |
| zyga | jamesh: are you asking about https://bugs.launchpad.net/snappy/+bug/1882221? | 10:15 |
| mup | Bug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221> | 10:15 |
| zyga | er | 10:15 |
| zyga | ijohnson: ^ | 10:15 |
| ijohnson | like locally changing the profile.bin in /usr/lib/snapd/seccomp/snap....src | 10:15 |
| ijohnson | and then compiling it | 10:15 |
| ijohnson | zyga: yes | 10:16 |
| ijohnson | also https://forum.snapcraft.io/t/cannot-parse-seccomp-profile-in-snapd-update/18007/5 | 10:16 |
| zyga | right | 10:16 |
| zyga | so no | 10:16 |
| ijohnson | I can reproduce the error here | 10:16 |
| mborzecki | ijohnson: they should call whatever version is appropriate i suppose | 10:16 |
| zyga | how? | 10:16 |
| ijohnson | right but how would they know which version is appropriate ? | 10:16 |
| mborzecki | ijohnson: they're already ahcking the profile so i would guess they can figure that out ? :) | 10:16 |
| zyga | developing a profile is something like what developers do | 10:17 |
| zyga | so minimal requirement is probably awareness of snapd source / build | 10:17 |
| ijohnson | 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 |
| zyga | though | 10:17 |
| zyga | I'm really curious | 10:17 |
| zyga | ah | 10:17 |
| zyga | ok | 10:17 |
| ijohnson | but snapd re-exec semantics can be quite confusing | 10:17 |
| mborzecki | ijohnson: so snap-seccomp from 2.37 then? | 10:17 |
| zyga | you answered my question | 10:17 |
| ijohnson | mborzecki: yes | 10:17 |
| ijohnson | before we supported chown stuff for system-usernames | 10:17 |
| zyga | ijohnson: my answer is don't do that I think | 10:17 |
| ijohnson | :-( | 10:18 |
| mborzecki | hm it might have been built with a different libseccomp version even | 10:18 |
| zyga | ijohnson: don't do development on top of really old snapd | 10:18 |
| mborzecki | (and probably was) | 10:18 |
| ijohnson | zyga: they are not on an old version of snapd | 10:18 |
| ijohnson | zyga: they have the core / snapd snap installed and have 2.45 | 10:18 |
| zyga | 2.37 is old | 10:18 |
| ijohnson | but the deb on their system is old | 10:18 |
| zyga | that's what I mean | 10:18 |
| ijohnson | zyga: but `snap version` says 2.45 ? | 10:18 |
| zyga | I think we should move everone over to snapd.snap, then the anwer is really easy | 10:19 |
| ijohnson | 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 |
| ijohnson | zyga: tbc, this person's machine only has bionic-security pocket enabled | 10:19 |
| ijohnson | zyga: so they won't ever get the deb unless they upgrade out of that pocket | 10:20 |
| mborzecki | w8, something is weird i think | 10:20 |
| ijohnson | (or we push an update to the bionic-security pocket with a new snapd I suppose) | 10:20 |
| ijohnson | I think the user experience here is quite poor | 10:20 |
| ijohnson | 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 |
| mborzecki | 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 |
| ijohnson | mborzecki: yes all the snaps work on their system right now | 10:21 |
| ijohnson | mborzecki: but they are developing changes to an interface in snapd | 10:22 |
| ijohnson | mborzecki: and the documented best practice to change seccomp is broken | 10:22 |
| mborzecki | ijohnson: where's that doc? maybe we need to update it | 10:22 |
| ijohnson | mborzecki: but what would you update it to ? | 10:22 |
| zyga | to tell people re-exec happens | 10:23 |
| mborzecki | ijohnson: use snapd from the ppa/roll out your own & disable reexec | 10:23 |
| ijohnson | 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 |
| mborzecki | ijohnson: i mean that's what i do :P | 10:23 |
| zyga | and the snap-seccom binary is in /snap/{snapd,core}/current/usr/lib/snapd/snap-seccomp | 10:23 |
| ijohnson | but I mean you see how that's a frustrating and confusing user experience | 10:23 |
| ijohnson | right? | 10:23 |
| mborzecki | ijohnson: it's should probably be look at /proc/<snapd-pid>/exec to find out which snapd binary is runnig, call snap-seccomp from the same location | 10:23 |
| mborzecki | (this is what snapd does iirc) | 10:24 |
| zyga | IMO that's all a bit too magic | 10:24 |
| zyga | I would not do that | 10:24 |
| ijohnson | zyga: it's not too magic to you because you've worked on snapd too long :-D | 10:25 |
| zyga | I mean, it is too magic | 10:25 |
| zyga | the re-exec logic is complex | 10:25 |
| zyga | I would not teach people about it | 10:25 |
| mborzecki | a snap debug command then? | 10:25 |
| ijohnson | right so why shouldn't we just make snap-seccomp do the same magic ? | 10:25 |
| zyga | I would rather have them know where the tools come from | 10:25 |
| zyga | ijohnson: because not all tools re-exec | 10:25 |
| ijohnson | a snap debug command makes sense to me | 10:25 |
| zyga | I really would not go overboard with this | 10:25 |
| ijohnson | zyga: but why don't all tools re-exec though | 10:26 |
| zyga | because it's hard and they cannot for other reasons | 10:26 |
| ijohnson | if some things re-exec and some things don't re-exec that is confusing and unexpected | 10:26 |
| zyga | snap-update-ns and snap-confine probably never well | 10:26 |
| zyga | *will | 10:26 |
| zyga | ijohnson: that's just the nature of the beast | 10:26 |
| ijohnson | :-( | 10:26 |
| zyga | I would argue that re-exec could be a helper tool that is used by everything | 10:27 |
| zyga | (that re-execs) | 10:27 |
| zyga | not by everything | 10:27 |
| zyga | so then this is more visible | 10:27 |
| zyga | maybe with maciek's idea to merge snapd and snap | 10:27 |
| mborzecki | 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 |
| zyga | snapd is just "snap <debug> snapd" | 10:27 |
| zyga | or snap exec-tool snapd | 10:28 |
| zyga | or something similar | 10:28 |
| mborzecki | snap debug exec-tool ? | 10:28 |
| zyga | it's not debug if we'd use it to run snapd :) | 10:28 |
| zyga | I would actually call it something else | 10:28 |
| zyga | snap exec-tool ... | 10:29 |
| zyga | and not reexec or debug | 10:29 |
| zyga | it's just a way to run a tool | 10:29 |
| zyga | a bit like snapd.tool | 10:29 |
| mborzecki | anyways, for starters we cold probably document the 'magic' thing first to make it clear | 10:29 |
| zyga | then it could do the right thing | 10:29 |
| mborzecki | ijohnson: do you know where the istructions for compiling profiles are? | 10:30 |
| zyga | mborzecki: offtopic: https://github.com/snapcore/snapd/pull/8821/checks?check_run_id=741848615 | 10:30 |
| mup | PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 10:30 |
| ijohnson | mborzecki: let me find it it was on docs.ubuntu.com/core somewhere | 10:30 |
| mborzecki | ijohnson: the search on docs.snapcraft.io comes up empty | 10:30 |
| zyga | I think some environment is not set up right | 10:30 |
| zyga | or perhaps something else is wrong | 10:31 |
| zyga | look at the import failures | 10:31 |
| mborzecki | ijohnson: there's some tips towrads the end of this page https://docs.ubuntu.com/core/en/guides/intro/security | 10:32 |
| ijohnson | mborzecki: yes that page | 10:32 |
| ijohnson | mborzecki: there's also https://github.com/snapcore/snapd/wiki/snap-confine-Overview | 10:33 |
| zyga | 2017 | 10:33 |
| pstolowski | mborzecki: unsquashfs from homebrew seems to work fine | 10:33 |
| mborzecki | ijohnson: cool, we can talk with degville to add something to the tips section in the core docs | 10:34 |
| ijohnson | mborzecki: yeah I marked the bug as confirmed and low priority, and added reproducer instructions | 10:38 |
| ijohnson | mborzecki: degville: also it would be good to move the snap-confine wiki page to the forum too, doesn't need a doc page, but that is the only place we have the snap-seccomp input format documented and also it should be updated to mention the new system-usernames changes for i.e. `chown -1` | 10:40 |
| pedronis | mvo: have we setup the meeting about REST docs? | 10:41 |
| degville | ijohnson / mborzecki: yes, I totally agree. I didn't know about that page until I just saw the link. | 10:41 |
| degville | pedronis / mvo: not yet. | 10:41 |
| zyga | more random failures shows service leaks | 10:49 |
| zyga | I see two at least: broken document portal still mounted | 10:50 |
| zyga | and a service that sleeps for 3133731337 | 10:50 |
| zyga | randomly breaking totally unrelated test | 10:50 |
| zyga | ok, let's fix those | 10:50 |
| mborzecki | degville: a little bit of text with examples you could use for the doc https://paste.ubuntu.com/p/TMHPJwd85W/ | 10:53 |
| mborzecki | ijohnson: ^^ please take a look too | 10:53 |
| degville | mborzecki: that's brilliant, thanks - I'll just push some changes to the core docs and create a new forum post for the seccomp stuff. | 10:54 |
| ijohnson | mborzecki: looks good to me | 10:54 |
| === facundo__ is now known as facubatista | ||
| zyga | degville: there's a second snap-confine doc | 10:56 |
| zyga | but it's much more raw | 10:56 |
| zyga | though more up-to-date | 10:56 |
| mborzecki | pstolowski: thanks for checking, looks like the GOPATH is messed up in the PR though | 10:56 |
| degville | zyga: oh, thanks - have you got a link? I'll try to merge the two? | 10:58 |
| zyga | sure, one sec | 10:58 |
| zyga | https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843 | 10:59 |
| zyga | I forgot it is on the forum | 10:59 |
| degville | zyga: thank you! | 10:59 |
| pstolowski | mborzecki: where do you see that? have you just pushed another chage? | 11:03 |
| pstolowski | *change | 11:03 |
| mborzecki | pstolowski: yeah, force pushed it | 11:03 |
| zyga | mborzecki: we set GOPATH in the other yaml IIRC | 11:03 |
| * pstolowski lunch | 11:05 | |
| sergiusens | zyga: ijohnson cachio hey, asking you as the most knowledgeable spread people, can you tell me what is going on on https://travis-ci.org/github/snapcore/snapcraft/jobs/694864341#L433 ?... started last Monday evening | 11:11 |
| zyga | looking | 11:11 |
| zyga | stat: cannot stat '/snap/bin/lxd': No such file or directory hmm | 11:12 |
| zyga | *hmm* | 11:13 |
| zyga | no idea, can you add a debug section that does "snap changes" and "ls -l /snap" - you may also want to hash -r after setting PATH | 11:13 |
| sergiusens | zyga: only on core20 and non deterministic | 11:13 |
| zyga | ah wait, this is *core* 20 | 11:13 |
| zyga | no, sorry | 11:13 |
| zyga | classic | 11:13 |
| zyga | I think I know | 11:14 |
| sergiusens | zyga: well, yeah, sorry, 20.04 | 11:14 |
| zyga | we see it too | 11:14 |
| zyga | ubuntu 20.04 only too | 11:14 |
| zyga | we get an error from install | 11:14 |
| zyga | "not ready for operation yada yada" | 11:14 |
| zyga | even though we do an explicit "snap wait system seeded" | 11:14 |
| zyga | also random | 11:14 |
| zyga | no idea why, but look like a real bug | 11:14 |
| zyga | I did not debug it more | 11:14 |
| zyga | perhaps escalate to mvo | 11:14 |
| sergiusens | zyga: you just did :-) | 11:14 |
| sergiusens | this is sort of blocking our releases and we are blocking the multipass release I just heard | 11:15 |
| zyga | mvo: ^ | 11:15 |
| * zyga runs | 11:15 | |
| sergiusens | lol | 11:16 |
| mvo | I heard my name? | 11:16 |
| sergiusens | only because it is Friday https://www.youtube.com/watch?v=H9vHwW9_1Oo | 11:17 |
| mvo | sergiusens: heh - I can look at the backlog but I need to have lunch (have a meeting soon) | 11:19 |
| sergiusens | mvo: so, our issue, which is more prominent since last Monday evening (no single test of ours has passed since then) is that on the 20.04 spread/google images, after we install LXD we get stat: "cannot stat '/snap/bin/lxd': No such file or directory" | 11:19 |
| zyga | mvo: we seem to have a bug in seeding on ubuntu 20.04 | 11:19 |
| mborzecki | zyga: it's green ;) | 11:19 |
| mborzecki | https://github.com/snapcore/snapd/pull/8821/checks?check_run_id=742006278 | 11:19 |
| mup | PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 11:19 |
| zyga | we wait for seeding | 11:19 |
| mvo | sergiusens: oh? is that reproducible? i.e. can I spread -debug that? | 11:19 |
| zyga | then snap install fails on "not ready yet" | 11:19 |
| zyga | mvo: it's reproducible on our tree but not frequently | 11:20 |
| zyga | I've seen it maybe 5-8 times | 11:20 |
| zyga | always ubuntu-20.04-64 | 11:20 |
| sergiusens | mvo: it is non deterministic, but we setup N instances and one of those always fails | 11:20 |
| mvo | zyga: but this "cannot stat /snap/bin/lxd" sounds very different | 11:20 |
| ijohnson | mborzecki: does that mean we don't need travis for anything any more ? | 11:20 |
| zyga | it'd be super hilarious if it was related to https://github.com/snapcore/snapd/pull/8814 | 11:20 |
| mup | PR #8814: sanity: check for unsynchronized real time clock <⛔ Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8814> | 11:20 |
| zyga | mvo: no, it just says lxd did not install | 11:20 |
| zyga | mvo: we snap install core in our case | 11:21 |
| zyga | or core20 maybe, sorry | 11:21 |
| mvo | sergiusens: do you have a log for me ? | 11:21 |
| mvo | zyga: shouldn't this error already on the "snap install lxd" then? | 11:21 |
| sergiusens | mvo: "spread -debug google:ubuntu-20.04-64:" | 11:21 |
| mvo | zyga: maybe I just need to see a log | 11:21 |
| zyga | mvo: maybe they don't check | 11:21 |
| zyga | we set -e in various helpers | 11:21 |
| sergiusens | mvo: https://travis-ci.org/github/snapcore/snapcraft/jobs/694864341#L433 | 11:21 |
| zyga | but set -e is easily lost | 11:21 |
| mborzecki | ijohnson: right, we can dro the extra cla check that runs on travis and were fully vendor locked to gh :) | 11:22 |
| ijohnson | \o/ | 11:22 |
| mvo | zyga, sergiusens ohhh: "snap "lxd" is already installed, see 'snap help refresh'" | 11:22 |
| mup | PR snapcraft#3158 opened: spread: add snap watch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3158> | 11:23 |
| mvo | zyga, sergiusens so the snap is installed but maybe not working yet - so this indicates that we are indeed not finished seeding yet and ssh just comes in too quickly | 11:23 |
| zyga | ah, interesting | 11:23 |
| zyga | mborzecki: reviewed | 11:23 |
| mvo | sergiusens: can you try to add "snap wait system seed.loaded" ? | 11:24 |
| mvo | sergiusens: to your prepare? | 11:24 |
| * mvo really needs to have a lunch now, will read backlog | 11:24 | |
| ijohnson | does this ubuntu 20.04 image maybe not even have the snapd deb | 11:24 |
| ijohnson | and just the snapd snap ? | 11:24 |
| sergiusens | mvo: sure | 11:25 |
| zyga | ijohnson: ohhh | 11:25 |
| zyga | interesting | 11:25 |
| zyga | ijohnson: but... | 11:25 |
| zyga | how? | 11:25 |
| zyga | actually I don't think we can do that | 11:26 |
| * ijohnson doesn't know just throwing random guesses over the wall | 11:26 | |
| zyga | yeah but that might explain things | 11:26 |
| cjp256 | is the deb required? | 11:26 |
| sergiusens | ijohnson: it is the one cachio maintains | 11:27 |
| ijohnson | hmm let me look at the spread output again | 11:28 |
| cjp256 | actually the deb is explicitly installed: https://github.com/snapcore/snapcraft/pull/3158/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R203 | 11:28 |
| mup | PR snapcraft#3158: spread: add snap watch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3158> | 11:28 |
| zyga | sergiusens: btw, you should look at our actions | 11:28 |
| ijohnson | ah nvm | 11:28 |
| zyga | they seriously rock | 11:28 |
| zyga | way better than travis now | 11:28 |
| ijohnson | https://www.irccloud.com/pastebin/Yrvil8sI/ | 11:28 |
| sergiusens | zyga: I asked ijohnson to document, if there is a place we can run spread without needing to maintain infra I am all for it | 11:29 |
| zyga | sergiusens: there is | 11:29 |
| zyga | sergiusens: our place :) | 11:29 |
| mborzecki | pstolowski: can you do one more pass over https://github.com/snapcore/snapd/pull/8821 ? | 11:29 |
| mup | PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 11:29 |
| sergiusens | zyga: how do you build Windows binaries though? Or when is the snap command coming to Windows for us to passthrough "snap pack"? :-) | 11:29 |
| zyga | sergiusens: you can also use github actions directly without our ifra | 11:29 |
| zyga | sergiusens: I don't know, though actions supports both macos and windows | 11:30 |
| sergiusens | zyga: we are using actions for release drafter | 11:30 |
| zyga | mborzecki: wow and it passed now :) | 11:30 |
| zyga | hmm | 11:31 |
| zyga | mborzecki: I'm confused | 11:31 |
| sergiusens | zyga: in any case, our issue today does not involve Travis at all | 11:31 |
| zyga | mborzecki: did you change get-deps? | 11:31 |
| zyga | sergiusens: that's true | 11:31 |
| zyga | mborzecki: ah, sorry, I misread bits | 11:31 |
| zyga | you said "done" https://github.com/snapcore/snapd/pull/8821/files#r435859512 | 11:31 |
| mup | PR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 11:31 |
| zyga | but I guess not on the right comment | 11:31 |
| zyga | anyway +1 | 11:32 |
| zyga | it's much nicer now | 11:32 |
| mborzecki | haha right | 11:32 |
| * zyga afk | 11:53 | |
| jdstrand | degville: note, https://bugs.launchpad.net/bugs/1874156. I was planning on doing it but it sounds like you are? (which is fine) | 12:03 |
| mup | Bug #1874156: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:Confirmed for jdstrand> <https://launchpad.net/bugs/1874156> | 12:03 |
| * jdstrand isn't here yet | 12:03 | |
| degville | jdstrand: ah, I hadn't seen that. I don't mind making the first attempt and bringing it all over to the forum, but it would be great to have your review/edit when it's in place. | 12:05 |
| mup | PR snapd#8821 closed: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8821> | 12:13 |
| clmsy | hi everyone | 12:42 |
| clmsy | i have a question about using snapctl manually | 12:42 |
| clmsy | we use this in prepare-device script : snapctl set device-service.headers='{"api-key": "redacted"}' | 12:42 |
| clmsy | to set api key for serial vault integration etc | 12:42 |
| clmsy | can i change the api key on a provisioned device | 12:43 |
| clmsy | when i manually run this command i receive an error saying snapctl cannot set without context | 12:43 |
| ijohnson | clmsy: no you can't change the api key on a device that already has a serial assertion | 12:43 |
| ijohnson | clmsy: can you explain your use case a bit more why do you want to change the api key ? | 12:43 |
| mup | PR snapcraft#3159 opened: cli: improve sudo detection with euid check for warnings/errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3159> | 12:43 |
| clmsy | there was a mistake on setting the api key, it was set to the wrong value | 12:45 |
| ijohnson | clmsy: does the device have a serial ? | 12:47 |
| ijohnson | clmsy: err rather does the device with the incorrect api key have a serial assertion ? | 12:48 |
| ogra | you can surely easily use snap set to change the variable value ... but that wont gain you much since the value has already been used/processed during first boot | 12:49 |
| ijohnson | ogra: but if the device already has a serial assertion then changing the api key won't re-trigger that iiuc | 12:49 |
| ogra | ijohnson, i wonder if re-modeling might help here | 12:49 |
| ogra | yes, thats what i said 🙂 | 12:49 |
| ijohnson | ogra: remodeling only would help if it had a serial assertion | 12:49 |
| ogra | you can change it but it wont have much effect | 12:49 |
| ogra | ah, right | 12:50 |
| clmsy | ok thank you! | 12:57 |
| mup | PR snapcraft#3157 closed: spread: use absolute path to lxd <tooling> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3157> | 13:03 |
| mup | PR snapcraft#3158 closed: spread: add snap watch <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3158> | 13:03 |
| mup | PR snapd#8820 closed: data/selinux: allow checking /var/cache/app-info (2.45) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8820> | 13:14 |
| zyga | mborzecki: found a curious bug | 13:17 |
| mborzecki | hm? | 13:17 |
| zyga | context is tests/main/services-stop-mode-sigkill | 13:18 |
| zyga | we issue snap remove test-snapd-service | 13:18 |
| zyga | that works | 13:19 |
| zyga | but leaves this | 13:19 |
| zyga | ├─snap.test-snapd-service.test-snapd-sigterm-service.service | 13:19 |
| zyga | │ ├─12053 sleep 3133731337 | 13:19 |
| zyga | │ └─12660 sleep 3133731337 | 13:19 |
| zyga | (that is systemctl status) | 13:19 |
| zyga | if you ask systemd about the unit it doesn't know anything (due to daemon reload) | 13:19 |
| zyga | the service is defined as | 13:19 |
| zyga | test-snapd-sigterm-service: | 13:19 |
| zyga | command: bin/start-stop-mode-sigterm | 13:19 |
| zyga | daemon: simple | 13:19 |
| zyga | stop-mode: sigterm | 13:19 |
| zyga | which means it should not do anything fancy and should really stop | 13:19 |
| zyga | and go away | 13:19 |
| zyga | this is on arch | 13:20 |
| zyga | and I think it's not deterministic | 13:20 |
| zyga | I ran this test a few times already | 13:21 |
| zyga | logs are super spammy | 13:21 |
| zyga | hmm, too large for pastebin | 13:22 |
| zyga | how do I lift a meg of logs off a spread vm | 13:23 |
| zyga | mborzecki: https://pastebin.com/Fv3Y364F gzipped | 13:24 |
| zyga | nah, broken | 13:24 |
| zyga | https://pastebin.com/RQhRtfJz | 13:25 |
| zyga | eh | 13:25 |
| zyga | that's base64 | 13:25 |
| zyga | so triggered spam detection | 13:25 |
| zyga | https://paste.ubuntu.com/p/jJf77HTTdc/ | 13:27 |
| mborzecki | zyga: wormhole? | 13:27 |
| zyga | that last link worked | 13:27 |
| zyga | but good idea | 13:27 |
| zyga | ugh, damn pain | 13:27 |
| zyga | had to reach for 2fa to get this | 13:28 |
| zyga | the log contains this: | 13:29 |
| zyga | Jun 05 13:15:26 jun051257-936988 systemd[1]: Stopping Service for snap application test-snapd-service.test-snapd-sigterm-service... | 13:29 |
| zyga | Jun 05 13:15:26 jun051257-936988 systemd[1]: snap.test-snapd-service.test-snapd-sigterm-service.service: Succeeded. | 13:29 |
| zyga | Jun 05 13:15:26 jun051257-936988 systemd[1]: Stopped Service for snap application test-snapd-service.test-snapd-sigterm-service. | 13:29 |
| zyga | what do you make of this? | 13:30 |
| zyga | should this happen? | 13:30 |
| === hggdh is now known as hggdh-msft | ||
| zyga | the processes are still alive and their cgroup data clearly shows they belong to the snap | 13:31 |
| * zyga looks at the systemd code | 13:31 | |
| zyga | huh | 13:32 |
| zyga | Jun 05 13:06:14 jun051257-936988 systemd[1]: snap.test-snapd-service.test-snapd-sigterm-service.service: Found left-over process 12053 (sleep) in control group while starting unit. Ignoring. | 13:32 |
| zyga | WHAT?! | 13:32 |
| zyga | Jun 05 13:06:14 jun051257-936988 systemd[1]: This usually indicates unclean termination of a previous run, or service implementation deficiencies. | 13:33 |
| ogra | ... or a really tired service ... | 13:33 |
| * zyga goes to trim that test to bare essentials | 13:33 | |
| zyga | so the test re-installs the snap | 13:34 |
| zyga | I think what happens is that stop doesn't really finish | 13:34 |
| zyga | before we continue | 13:34 |
| zyga | otherwise I cannot explain this | 13:34 |
| zyga | ah, wait | 13:35 |
| zyga | I think this is actually correct | 13:35 |
| zyga | the service doesn't terminate all the processes | 13:35 |
| zyga | this is expected | 13:35 |
| zyga | mborzecki: sorry, alarm over | 13:35 |
| mborzecki | ijohnson: did you try btrfs too? | 13:37 |
| ijohnson | mborzecki: no | 13:37 |
| zyga | but oddly it happened only on some systems, indicating that there's still something racy there | 13:38 |
| zyga | https://github.com/snapcore/snapd/pull/8815 needs a 2nd review | 13:48 |
| mup | PR #8815: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815> | 13:48 |
| zyga | pstolowski: https://github.com/snapcore/snapd/pull/8819#pullrequestreview-425315738 | 13:49 |
| mup | PR #8819: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8819> | 13:49 |
| pedronis | zyga: sorry, had other things this morning, if I understand I should look at #8573? I put it in my queue, likely monday at this point | 13:50 |
| mup | PR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573> | 13:50 |
| zyga | pedronis: yes, getting some advice on how to proceed would help with the front-end side | 13:50 |
| zyga | thanks, Monday is fine | 13:51 |
| zyga | with some luck I will be feeling better as well | 13:51 |
| zyga | mvo: would you mind a quick look at https://github.com/snapcore/snapd/pull/8804 | 13:54 |
| mup | PR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804> | 13:54 |
| zyga | dbus-daemon clean is so close | 13:55 |
| mup | PR snapcraft#3160 opened: project loader: fix v1 plugin repository installation on host <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3160> | 14:08 |
| sergiusens | mvo: just to circle back, the seed wait did seem to work | 14:11 |
| zyga | is there a simrefinery snap yet? | 14:23 |
| mvo | sergiusens: \o/ thank you | 14:24 |
| jdstrand | degville: emitorino and I are happy to review. are you planning on updating https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 (ie, the Tips section) or writing something new? if new, keep in mind https://forum.snapcraft.io/t/security-policy-and-sandboxing/554 seems to be used by a lot of people, so we'll need to adjust that accordingly to read the new doc | 14:33 |
| jdstrand | degville: s/if new/or are you planning on writing a new doc? if new/ | 14:33 |
| mup | PR snapcraft#3154 closed: cmake v2 plugin: take source-subdir into account <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3154> | 14:38 |
| degville | jdstrand: (sorry, just in a meeting). I was only planning to update it, but I often end up re-writing large sections when I get into it. I'll definitely ping you, and please let me know if there's bits you know will need special attention. I'll make sure they're fixed. | 14:40 |
| jdstrand | degville: cool, I preferred updating. yes, happy to review :) | 14:40 |
| pedronis | pstolowski: I reviewed #8819 | 14:51 |
| mup | PR #8819: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8819> | 14:51 |
| pstolowski | pedronis: ty | 14:53 |
| mup | PR snapd#8819 closed: tests: move install tests from snapstate_test.go to snapstate_install_test.go <Test Robustness> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8819> | 14:54 |
| mup | PR snapcraft#3159 closed: cli: improve sudo detection with euid check for warnings/errors <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3159> | 15:08 |
| * cachio lunch | 15:13 | |
| mup | PR snapd#8780 closed: tests: core20 early defaults spread test <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8780> | 15:14 |
| pstolowski | finally | 15:16 |
| mvo | pstolowski: nice weekend gift \o/ | 15:29 |
| pstolowski | yes indeed :) | 15:29 |
| === facundo__ is now known as facubatista | ||
| mup | PR snapcraft#3161 opened: npm v2 plugin: always include $SNAPCRAFT_PART_INSTALL/bin in $PATH <bug> <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3161> | 15:59 |
| ijohnson | cachio: is #8816 ready to review ? | 16:22 |
| mup | PR #8816: tests: port 2 uc20 part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8816> | 16:22 |
| cachio | ijohnson, yes | 16:41 |
| cachio | ijohnson, thanks | 16:41 |
| sergiusens | mvo: did you in the past 4 hours change any github permissions? Our Travis<->GH link just broke too | 16:49 |
| mup | PR snapcraft#3160 closed: project loader: fix v1 plugin repository installation on host <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3160> | 16:49 |
| mvo | sergiusens: I did not change anything | 17:10 |
| === KindTwo is now known as KindOne | ||
| mup | PR snapd#8822 opened: release: 2.45.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8822> | 17:19 |
| mup | PR snapcraft#3161 closed: npm v2 plugin: always include $SNAPCRAFT_PART_INSTALL/bin in $PATH <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3161> | 17:49 |
| mup | PR snapd#8786 closed: arch: add riscv64 <Created by xnox> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8786> | 18:05 |
| mup | PR snapcraft#3162 opened: tests: remove scenario usage from lifecycle order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3162> | 18:09 |
| mup | PR snapd#8823 opened: asserts/internal: limit Grouping size switching to a bitset representation <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8823> | 18:10 |
| mup | PR snapcraft#3163 opened: cli: remove the hidden inspect command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3163> | 18:34 |
| mup | PR snapcraft#3164 opened: cli: remove enable-ci command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3164> | 18:34 |
| === KindTwo is now known as KindOne | ||
| mup | PR snapd#8824 opened: many: move encryption and installer from snap-boostrap to gadget <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8824> | 21:46 |
| === hggdh-msft is now known as hggdh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!