mupPR snapcraft#3157 opened: spread: use absolute path to lxd <tooling> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3157>01:07
mupPR 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
mborzeckizyga: hey hey06:44
mvohey mborzecki and zyga06:46
zygahey, I just had to do something weird to log in07:03
zygacan you guys please check if you are a member of group "video"07:04
zygaand if /dev/dri/card0 is group-owned by that file07:04
zygaI had to add myself to the video group07:05
zygaas otherwise gdm would fail to start the session for my account07:05
mvozyga: I'm not in video07:12
mvozyga: on 20.0407:12
zygahmm (I'm on 20.10)07:12
zygawhat's the ownership of /dev/dri/card0?07:12
mvozyga: root:video07:36
zygaI talked in #ubuntu-devel a little and normally logind would grant extra permissions to my account07:36
zygaso something on that line is broken07:36
zygaoh well, the fun of running devel :)07:36
zygathank you for checking07:37
zygaI will finish coffee and jump into PRs07:37
mborzeckizyga: funny, i'm in video group07:41
mborzeckiwonder what happens when i drop that07:41
mborzeckizyga: do you have any other ideas about https://forum.snapcraft.io/t/notification-on-reboot-initiation-or-coming-up-from-reboot/18005 ?07:42
zygamborzecki: /tmp as seen by a snap is not discarded on refresh07:43
mborzeckizyga: ha, so maybe that could be used then07:44
mborzeckianyways, this feels like thin ice07:45
ackkhi, how do I get a snap out of --devmode without reinstalling?07:45
zygamborzecki: yeah, I replied07:46
zygaackk: hmmm good question07:46
mborzeckizyga: thanks!07:46
zygaI think there's no way actually, maybe refresh --strict but I don't remember if we forward that07:46
pedronisackk: maybe snap revert --revision but not sure07:47
pstolowskipedronis: 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 tries07:47
ackk--strict is not accepted by refresh07:47
ackkrevert also doesn't seem to work if you try to revert to the same revision07:48
pedronispstolowski: it's a good idea, but we would need to think a bit how to tackle it07:50
pstolowskipedronis: how about if i propose just a few obvious ones? do you have particular concern in mind?07:51
pedronispstolowski: mostly conflict for wip work07:52
mborzeckimvo: https://github.com/snapcore/snapd/pull/8722#issuecomment-639319127 heh a bit unexpected07:52
mupPR #8722: tests: check that host settings like hostname are settable on core <Created by mvo5> <https://github.com/snapcore/snapd/pull/8722>07:52
pedronisalso there might be some corner cases where is not clear but maybe that isn't true07:52
mvopedronis: I updated the netplan thing07:54
mvomborzecki: oh, woah, unexpected indeed!07:54
pstolowskipedronis: 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.go07:59
zygamborzecki: updated https://github.com/snapcore/snapd/pull/881508:00
mupPR #8815: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815>08:00
pedronispstolowski: I would start with snapstate_install_test.go I suppose ?08:04
pedronisthat would be tests that involve mainly snapstate.Install and snapstate.InstallPath08:04
pedronisI suppose08:05
pstolowskipedronis: yes,  that's a good candidate08:05
pedronisnotice though sometimes they are used to setup conflicts for other things, but hopefully the test name/content makes that clear08:06
ackkzyga, 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
pedronisseems so, though is a legitimate request (not super high prio) to have a local way08:13
zygaperhaps snap switch could grow an option08:14
pedronismabye but switch never unlink/link atm08:15
pedronisand this would need to08:15
pedronisor some subset of that08:16
zygawhy would we have to unlink?08:17
pedroniswell, it would need to stop all services for example08:17
pedronisit's refresh like in some ways08:17
zygayeah, stop, flip flags,  setup security, start08:17
pedronisjust saying it's not super clear that switch is a good syntax for it08:18
zygaackk: I think filing a bug and letting us eventually get to it is the way forward08:19
ackkzyga, ok, thanks08:19
pedronisgiven how it works, I actually switch would probably just change the flag for the next refresh08:19
pedronis*actually think08:19
zygapedronis: ideed, you are right08:19
pedronisthat would break some invariants though, so not sure we can add it to switch08:20
pedronisanyway some form of revert or refresh would do08:21
* zyga afk for a moment, I'll try to move to the office today08:23
zygamaybe no08:29
zygaI cannot stand for a while even08:29
=== diddledan0 is now known as diddledan
zygamvo: updated https://github.com/snapcore/snapd/pull/880408:39
mupPR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>08:39
ackkzyga, filed https://bugs.launchpad.net/snapd/+bug/188221408:41
mupBug #1882214: No way to move out of devmode without updates or reinstall <snapd:New> <https://launchpad.net/bugs/1882214>08:41
mupPR 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
pedronispstolowski: verifyInstallTasks should move too?08:47
pedronisor is it used for update as well?08:48
pstolowskipedronis: it's used by transition and installmany tests08:48
pstolowskipedronis: and by gadgetupdate tests08:48
pedronispstolowski: I think I would move it anyway, also move the InstallMany ones08:49
pedronisI forgot about them08:49
pedronisof course git diff is weird and looks like you changed things and not just removed them :/08:51
mborzeckiheh all spread jobs passed, but the travis job failed on osx :P08:53
pstolowskipedronis: heh, indeed, complete mess08:54
zygamborzecki: how?08:55
pedronispstolowski: I'm busy now, but I'll try to look at it again immediately after lunch08:55
zygamborzecki: maybe spend a moment to port the macos job over08:55
mborzeckizyga: some random bit about osx host not coming up08:55
zygaeven more reason to do it08:56
zygajust add a new job for it and that should be it08:56
mborzeckiiirc we saw this happen couple of times08:56
mborzeckizyga: gh can do osx too?08:56
zygaI used this in libzt if that helps: https://github.com/zyga/libzt/blob/master/.github/workflows/build.yml#L1808:56
zygayes :)08:56
zygago is preinstalled IIRC08:57
zygamborzecki: and it's macos for a few years now :)08:57
zygaosx was the old name08:57
pedronismborzecki: yes, it has different limits than other jobs, not sure it/how it matters08:57
pstolowskipedronis: thanks08:58
zygapedronis: there are no different limits *but* a macos job is like 2 other jobs08:58
mborzeckipedronis: zyga: i can try and port it over, should be a quick job08:58
zygabut it shold not matter much as our tests are quick and won't use the slots for long08:58
mborzeckimvo: can you cherry-pick https://github.com/snapcore/snapd/pull/8798 to 2.45? should apply cleanly08:59
mupPR #8798: data/selinux: allow checking /var/cache/app-info <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8798>08:59
mvomborzecki: sure, will do09:00
mborzeckimvo: thanks!09:00
mupPR 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
zygaif you encounter a "cancelled" test just restart, sorry my fault09:03
=== ricab__ is now known as ricab
mvomborzecki: meh, 7 commit, I will create a 2.45 branch for this09:03
* mvo should have marked this squash-merge09:04
mborzeckimvo:  i can do that09:04
mvomborzecki: yes please!09:04
zygamvo: I need to show you how to cherry pick ranges09:05
zygait's not a problem really09:05
mvozyga: :)09:05
mborzeckizyga: 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 upstream09:10
mborzecki(probably because i list commits that are not part of a branch, and once landed that no longer lists anything)09:11
zygamborzecki: look at the branch, get the base and the tip,09:11
zygaI did it a few times09:11
zygaworked okay09:11
mupPR 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
mborzeckizyga: 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 upstream09:13
mupBug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:15
mupBug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:18
mupBug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:21
zygamborzecki: huh09:26
zygahttps://bugs.launchpad.net/snappy/+bug/1882221 is bad09:26
mupBug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:26
zygaI need to go afk, I'll look soon09:26
mupBug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:27
mupBug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:30
mupBug #1882221 changed: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:33
mupBug #1882221 opened: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>09:39
mupPR snapd#8821 opened: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>09:48
pstolowskimborzecki: do you have any fail logs for ^ /09:51
pstolowskii have homebrew locally and can check something out, but don't know yet how it maps to github actions09:52
zygamborzecki: https://formulae.brew.sh/formula/squashfs is the forumla09:53
zygaI' -1 on using a 3rd party action09:54
zygaespecially if it is just "brew install"09:54
zygamborzecki: maybe you need brew install --with-xz --with-zstd09:54
zygapstolowski: ^ can you check09:54
zygaI should just install brew I guess09:55
pstolowskiah, the question is about how to install manually09:56
pstolowskibrew install squashfs09:56
zygaso that's all we need09:56
zygabrew is preinstalled in those images09:56
pstolowskiinstalls squashfs-4.409:56
pstolowskino args needed09:56
zygapstolowski: maybe check if it has xz and zstd09:56
zygacan it unsquash a test .snap09:56
pstolowskizyga:  Installing dependencies for squashfs: lz4, lzo and zstd09:56
pstolowskino mention of xz09:56
zygamaybe xz is preinstalled09:56
zygajust check with any snap if you can09:57
zygabtw, I just noticed brew works on linux09:57
zygamaybe a nice way to build ... snaps09:57
zygajust bake a custom prefix, something brew can do09:57
mborzeckihm looks like you can fix whatever needed there ;)09:57
pstolowskizyga: i find brew a must on mac09:57
mborzeckiw8, why there's no job there?09:58
mborzeckidoes mvo need to enable something?09:58
zygabecause you called this job cla-check09:58
mborzeckiw8, wat?09:59
zygalook at the PR09:59
zygaI commented09:59
zygaa sneaky way to pass cla checks;D10:00
pstolowskizyga, mborzecki i'll check if ^ works on mac after 1-110:00
zygait's also wrong10:00
zygaIIRC args are []10:01
zygabut check the docs please10:01
zygamborzecki: some early opinion on https://github.com/snapcore/snapd/pull/7700 would be great10:05
mupPR #7700: cmd/snap: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>10:05
zygait's WIP code10:05
zygapedronis: and for you https://github.com/snapcore/snapd/pull/8573 -- equally WIP and super tiny - just to start the conversation10:05
mupPR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>10:05
zygamborzecki: did you see https://github.com/snapcore/snapd/pull/8821/files#r43582055010:06
mupPR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>10:06
zygamborzecki: this is what GH says https://github.com/snapcore/snapd/actions/runs/12582453010:07
mborzeckizyga: yeah, but i'm not sure what's wrong there, yaml is valid, the entrypoint in the action is basically `brew $*`10:07
zygayeah but that's not the right yaml10:07
zygathere's a different way to say that10:07
zygalet me find that10:07
mborzeckihm maybe it shoudl be under `with:`10:07
zygalook at https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions10:07
zygaexactly :)10:07
zygaI think you can also drop the ""10:07
zygamaybe just do that manually10:10
zygaI don't know what that action does10:10
zygadid you read the code?10:10
mborzeckizyga: yeah, it literally calls brew $*10:11
zygathen really just do it yourself10:11
zygaless magic10:11
mborzeckiin the meantime, i'm not sure how https://bugs.launchpad.net/snappy/+bug/1882221 happened10:14
mupBug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>10:14
ijohnsonzyga: hey o/10:14
ijohnsonzyga: should snap-seccomp re-exec ?10:14
zygahey ian :)10:14
mborzeckiijohnson: snapd should call it from the same location as the snapd binary is running10:14
ijohnsonmborzecki: but what about for folks that are developing their own profiles10:14
zygaIIRC we call it with full path10:15
ijohnsoni.e. you are hacking on a seccomp / apparmor snapd profile to test things10:15
mborzeckiijohnson: what do you mean?10:15
zygajamesh: are you asking about https://bugs.launchpad.net/snappy/+bug/1882221?10:15
mupBug #1882221: Cannot parse seccomp profile in snapd update <Snappy:New> <https://launchpad.net/bugs/1882221>10:15
zygaijohnson: ^10:15
ijohnsonlike locally changing the profile.bin in /usr/lib/snapd/seccomp/snap....src10:15
ijohnsonand then compiling it10:15
ijohnsonzyga: yes10:16
ijohnsonalso https://forum.snapcraft.io/t/cannot-parse-seccomp-profile-in-snapd-update/18007/510:16
zygaso no10:16
ijohnsonI can reproduce the error here10:16
mborzeckiijohnson: they should call whatever version is appropriate i suppose10:16
ijohnsonright but how would they know which version is appropriate ?10:16
mborzeckiijohnson: they're already ahcking the profile so i would guess they can figure that out ? :)10:16
zygadeveloping a profile is something like what developers do10:17
zygaso minimal requirement is probably awareness of snapd source / build10:17
ijohnsonzyga: 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-seccomp10:17
zygaI'm really curious10:17
ijohnsonbut snapd re-exec semantics can be quite confusing10:17
mborzeckiijohnson: so snap-seccomp from 2.37 then?10:17
zygayou answered my question10:17
ijohnsonmborzecki: yes10:17
ijohnsonbefore we supported chown stuff for system-usernames10:17
zygaijohnson: my answer is don't do that I think10:17
mborzeckihm it might have been built with a different libseccomp version even10:18
zygaijohnson: don't do development on top of really old snapd10:18
mborzecki(and probably was)10:18
ijohnsonzyga: they are not on an old version of snapd10:18
ijohnsonzyga: they have the core / snapd snap installed and have 2.4510:18
zyga2.37 is old10:18
ijohnsonbut the deb on their system is old10:18
zygathat's what I mean10:18
ijohnsonzyga: but `snap version` says 2.45 ?10:18
zygaI think we should move everone over to snapd.snap, then the anwer is really easy10:19
ijohnsonzyga: 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
ijohnsonzyga: tbc, this person's machine only has bionic-security pocket enabled10:19
ijohnsonzyga: so they won't ever get the deb unless they upgrade out of that pocket10:20
mborzeckiw8, something is weird i think10:20
ijohnson(or we push an update to the bionic-security pocket with a new snapd I suppose)10:20
ijohnsonI think the user experience here is quite poor10:20
ijohnsoneither 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 using10:21
mborzeckiijohnson: 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 that10:21
ijohnsonmborzecki: yes all the snaps work on their system right now10:21
ijohnsonmborzecki: but they are developing changes to an interface in snapd10:22
ijohnsonmborzecki: and the documented best practice to change seccomp is broken10:22
mborzeckiijohnson: where's that doc? maybe we need to update it10:22
ijohnsonmborzecki: but what would you update it to ?10:22
zygato tell people re-exec happens10:23
mborzeckiijohnson: use snapd from the ppa/roll out your own & disable reexec10:23
ijohnsonmborzecki: 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
mborzeckiijohnson: i mean that's what i do :P10:23
zygaand the snap-seccom binary is in /snap/{snapd,core}/current/usr/lib/snapd/snap-seccomp10:23
ijohnsonbut I mean you see how that's a frustrating and confusing user experience10:23
mborzeckiijohnson: 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 location10:23
mborzecki(this is what snapd does iirc)10:24
zygaIMO that's all a bit too magic10:24
zygaI would not do that10:24
ijohnsonzyga: it's not too magic to you because you've worked on snapd too long :-D10:25
zygaI mean, it is too magic10:25
zygathe re-exec logic is complex10:25
zygaI would not teach people about it10:25
mborzeckia snap debug command then?10:25
ijohnsonright so why shouldn't we just make snap-seccomp do the same magic ?10:25
zygaI would rather have them know where the tools come from10:25
zygaijohnson: because not all tools re-exec10:25
ijohnsona snap debug command makes sense to me10:25
zygaI really would not go overboard with this10:25
ijohnsonzyga: but why don't all tools re-exec though10:26
zygabecause it's hard and they cannot for other reasons10:26
ijohnsonif some things re-exec and some things don't re-exec that is confusing and unexpected10:26
zygasnap-update-ns and snap-confine probably never well10:26
zygaijohnson: that's just the nature of the beast10:26
zygaI would argue that re-exec could be a helper tool that is used by everything10:27
zyga(that re-execs)10:27
zyganot by everything10:27
zygaso then this is more visible10:27
zygamaybe with maciek's idea to merge snapd and snap10:27
mborzeckiijohnson: 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 binary10:27
zygasnapd is just "snap <debug> snapd"10:27
zygaor snap exec-tool snapd10:28
zygaor something similar10:28
mborzeckisnap debug exec-tool ?10:28
zygait's not debug if we'd use it to run snapd :)10:28
zygaI would actually call it something else10:28
zygasnap exec-tool ...10:29
zygaand not reexec or debug10:29
zygait's just a way to run a tool10:29
zygaa bit like snapd.tool10:29
mborzeckianyways, for starters we cold probably document the 'magic' thing first to make it clear10:29
zygathen it could do the right thing10:29
mborzeckiijohnson: do you know where the istructions for compiling profiles are?10:30
zygamborzecki: offtopic: https://github.com/snapcore/snapd/pull/8821/checks?check_run_id=74184861510:30
mupPR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>10:30
ijohnsonmborzecki: let me find it it was on docs.ubuntu.com/core somewhere10:30
mborzeckiijohnson: the search on docs.snapcraft.io comes up empty10:30
zygaI think some environment is not set up right10:30
zygaor perhaps something else is wrong10:31
zygalook at the import failures10:31
mborzeckiijohnson: there's some tips towrads the end of this page https://docs.ubuntu.com/core/en/guides/intro/security10:32
ijohnsonmborzecki: yes that page10:32
ijohnsonmborzecki: there's also https://github.com/snapcore/snapd/wiki/snap-confine-Overview10:33
pstolowskimborzecki: unsquashfs from homebrew seems to work fine10:33
mborzeckiijohnson: cool, we can talk with degville to add something to the tips section in the core docs10:34
ijohnsonmborzecki: yeah I marked the bug as confirmed and low priority, and added reproducer instructions10:38
ijohnsonmborzecki: 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
pedronismvo: have we setup the meeting about REST docs?10:41
degvilleijohnson / mborzecki: yes, I totally agree. I didn't know about that page until I just saw the link.10:41
degvillepedronis / mvo: not yet.10:41
zygamore random failures shows service leaks10:49
zygaI see two at least: broken document portal still mounted10:50
zygaand a service that sleeps for 313373133710:50
zygarandomly breaking totally unrelated test10:50
zygaok, let's fix those10:50
mborzeckidegville: a little bit of text with examples you could use for the doc https://paste.ubuntu.com/p/TMHPJwd85W/10:53
mborzeckiijohnson: ^^ please take a look too10:53
degvillemborzecki: 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
ijohnsonmborzecki: looks good to me10:54
=== facundo__ is now known as facubatista
zygadegville: there's a second snap-confine doc10:56
zygabut it's much more raw10:56
zygathough more up-to-date10:56
mborzeckipstolowski: thanks for checking, looks like the GOPATH is messed up in the PR though10:56
degvillezyga: oh, thanks - have you got a link? I'll try to merge the two?10:58
zygasure, one sec10:58
zygaI forgot it is on the forum10:59
degvillezyga: thank you!10:59
pstolowskimborzecki: where do you see that? have you just pushed another chage?11:03
mborzeckipstolowski: yeah, force pushed it11:03
zygamborzecki: we set GOPATH in the other yaml IIRC11:03
* pstolowski lunch11:05
sergiusenszyga: 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 evening11:11
zygastat: cannot stat '/snap/bin/lxd': No such file or directory hmm11:12
zygano idea, can you add a debug section that does "snap changes" and "ls -l /snap" - you may also want to hash -r after setting PATH11:13
sergiusenszyga: only on core20 and non deterministic11:13
zygaah wait, this is *core* 2011:13
zygano, sorry11:13
zygaI think I know11:14
sergiusenszyga: well, yeah, sorry, 20.0411:14
zygawe see it too11:14
zygaubuntu 20.04 only too11:14
zygawe get an error from install11:14
zyga"not ready for operation yada yada"11:14
zygaeven though we do an explicit "snap wait system seeded"11:14
zygaalso random11:14
zygano idea why, but look like a real bug11:14
zygaI did not debug it more11:14
zygaperhaps escalate to mvo11:14
sergiusenszyga: you just did :-)11:14
sergiusensthis is sort of blocking our releases and we are blocking the multipass release I just heard11:15
zygamvo: ^11:15
* zyga runs11:15
mvoI heard my name?11:16
sergiusensonly because it is Friday https://www.youtube.com/watch?v=H9vHwW9_1Oo11:17
mvosergiusens: heh - I can look at the backlog but I need to have lunch (have a meeting soon)11:19
sergiusensmvo: 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
zygamvo: we seem to have a bug in seeding on ubuntu 20.0411:19
mborzeckizyga: it's green ;)11:19
mupPR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>11:19
zygawe wait for seeding11:19
mvosergiusens: oh? is that reproducible? i.e. can I spread -debug that?11:19
zygathen snap install fails on "not ready yet"11:19
zygamvo: it's reproducible on our tree but not frequently11:20
zygaI've seen it maybe 5-8 times11:20
zygaalways ubuntu-20.04-6411:20
sergiusensmvo: it is non deterministic, but we setup N instances and one of those always fails11:20
mvozyga: but this "cannot stat /snap/bin/lxd" sounds very different11:20
ijohnsonmborzecki: does that mean we don't need travis for anything any more ?11:20
zygait'd be super hilarious if it was related to https://github.com/snapcore/snapd/pull/881411:20
mupPR #8814: sanity: check for unsynchronized real time clock <β›” Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8814>11:20
zygamvo: no, it just says lxd did not install11:20
zygamvo: we snap install core in our case11:21
zygaor core20 maybe, sorry11:21
mvosergiusens: do you have a log for me ?11:21
mvozyga: shouldn't this error already on the "snap install lxd" then?11:21
sergiusensmvo: "spread -debug google:ubuntu-20.04-64:"11:21
mvozyga: maybe I just need to see a log11:21
zygamvo: maybe they don't check11:21
zygawe set -e in various helpers11:21
sergiusensmvo: https://travis-ci.org/github/snapcore/snapcraft/jobs/694864341#L43311:21
zygabut set -e is easily lost11:21
mborzeckiijohnson: right, we can dro the extra cla check that runs on travis and were fully vendor locked to gh :)11:22
mvozyga, sergiusens ohhh: "snap "lxd" is already installed, see 'snap help refresh'"11:22
mupPR snapcraft#3158 opened: spread: add snap watch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3158>11:23
mvozyga, 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 quickly11:23
zygaah, interesting11:23
zygamborzecki: reviewed11:23
mvosergiusens: can you try to add "snap wait system seed.loaded" ?11:24
mvosergiusens: to your prepare?11:24
* mvo really needs to have a lunch now, will read backlog11:24
ijohnsondoes this ubuntu 20.04 image maybe not even have the snapd deb11:24
ijohnsonand just the snapd snap ?11:24
sergiusensmvo: sure11:25
zygaijohnson: ohhh11:25
zygaijohnson: but...11:25
zygaactually I don't think we can do that11:26
* ijohnson doesn't know just throwing random guesses over the wall11:26
zygayeah but that might explain things11:26
cjp256is the deb required?11:26
sergiusensijohnson: it is the one cachio maintains11:27
ijohnsonhmm let me look at the spread output again11:28
cjp256actually the deb is explicitly installed: https://github.com/snapcore/snapcraft/pull/3158/files#diff-3c11e56e5f7f82b0f352d0fe1851a107R20311:28
mupPR snapcraft#3158: spread: add snap watch <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3158>11:28
zygasergiusens: btw, you should look at our actions11:28
ijohnsonah nvm11:28
zygathey seriously rock11:28
zygaway better than travis now11:28
sergiusenszyga: I asked ijohnson to document, if there is a place we can run spread without needing to maintain infra I am all for it11:29
zygasergiusens: there is11:29
zygasergiusens: our place :)11:29
mborzeckipstolowski: can you do one more pass over https://github.com/snapcore/snapd/pull/8821 ?11:29
mupPR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>11:29
sergiusenszyga: how do you build Windows binaries though? Or when is the snap command coming to Windows for us to passthrough "snap pack"? :-)11:29
zygasergiusens: you can also use github actions directly without our ifra11:29
zygasergiusens: I don't know, though actions supports both macos and windows11:30
sergiusenszyga: we are using actions for release drafter11:30
zygamborzecki: wow and it passed now :)11:30
zygamborzecki: I'm confused11:31
sergiusenszyga: in any case, our issue today does not involve Travis at all11:31
zygamborzecki: did you change get-deps?11:31
zygasergiusens: that's true11:31
zygamborzecki: ah, sorry, I misread bits11:31
zygayou said "done" https://github.com/snapcore/snapd/pull/8821/files#r43585951211:31
mupPR #8821: github: port macOS sanity checks from travis <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8821>11:31
zygabut I guess not on the right comment11:31
zygaanyway +111:32
zygait's much nicer now11:32
mborzeckihaha right11:32
* zyga afk11:53
jdstranddegville: note, https://bugs.launchpad.net/bugs/1874156. I was planning on doing it but it sounds like you are? (which is fine)12:03
mupBug #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 yet12:03
degvillejdstrand: 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
mupPR 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
clmsyhi everyone12:42
clmsyi have a question about using snapctl manually12:42
clmsywe use this in prepare-device script : snapctl set device-service.headers='{"api-key": "redacted"}'12:42
clmsyto set api key for serial vault integration etc12:42
clmsycan i change the api key on a provisioned device12:43
clmsywhen i manually run this command i receive an error saying snapctl cannot set without context12:43
ijohnsonclmsy: no you can't change the api key on a device that already has a serial assertion12:43
ijohnsonclmsy: can you explain your use case a bit more why do you want to change the api key ?12:43
mupPR 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
clmsythere was a mistake on setting the api key, it was set to the wrong value12:45
ijohnsonclmsy: does the device have a serial ?12:47
ijohnsonclmsy: err rather does the device with the incorrect api key have a serial assertion ?12:48
ograyou 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 boot12:49
ijohnsonogra: but if the device already has a serial assertion then changing the api key won't re-trigger that iiuc12:49
ograijohnson, i wonder if re-modeling might help here12:49
ograyes, thats what i said πŸ™‚12:49
ijohnsonogra: remodeling only would help if it had a serial assertion12:49
ograyou can change it but it wont have much effect12:49
ograah, right12:50
clmsyok thank you!12:57
mupPR 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
mupPR snapcraft#3158 closed: spread: add snap watch <tooling> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3158>13:03
mupPR 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
zygamborzecki: found a curious bug13:17
zygacontext is tests/main/services-stop-mode-sigkill13:18
zygawe issue snap remove test-snapd-service13:18
zygathat works13:19
zygabut leaves this13:19
zyga             β”œβ”€snap.test-snapd-service.test-snapd-sigterm-service.service13:19
zyga             β”‚ β”œβ”€12053 sleep 313373133713:19
zyga             β”‚ └─12660 sleep 313373133713:19
zyga(that is systemctl status)13:19
zygaif you ask systemd about the unit it doesn't know anything (due to daemon reload)13:19
zygathe service is defined as13:19
zyga    test-snapd-sigterm-service:13:19
zyga        command: bin/start-stop-mode-sigterm13:19
zyga        daemon: simple13:19
zyga        stop-mode: sigterm13:19
zygawhich means it should not do anything fancy and should really stop13:19
zygaand go away13:19
zygathis is on arch13:20
zygaand I think it's not deterministic13:20
zygaI ran this test a few times already13:21
zygalogs are super spammy13:21
zygahmm, too large for pastebin13:22
zygahow do I lift a meg of logs off a spread vm13:23
zygamborzecki: https://pastebin.com/Fv3Y364F gzipped13:24
zyganah, broken13:24
zygathat's base6413:25
zygaso triggered spam detection13:25
mborzeckizyga: wormhole?13:27
zygathat last link worked13:27
zygabut good idea13:27
zygaugh, damn pain13:27
zygahad to reach for 2fa to get this13:28
zygathe log contains this:13:29
zygaJun 05 13:15:26 jun051257-936988 systemd[1]: Stopping Service for snap application test-snapd-service.test-snapd-sigterm-service...13:29
zygaJun 05 13:15:26 jun051257-936988 systemd[1]: snap.test-snapd-service.test-snapd-sigterm-service.service: Succeeded.13:29
zygaJun 05 13:15:26 jun051257-936988 systemd[1]: Stopped Service for snap application test-snapd-service.test-snapd-sigterm-service.13:29
zygawhat do you make of this?13:30
zygashould this happen?13:30
=== hggdh is now known as hggdh-msft
zygathe processes are still alive and their cgroup data clearly shows they belong to the snap13:31
* zyga looks at the systemd code13:31
zygaJun 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
zygaJun 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 essentials13:33
zygaso the test re-installs the snap13:34
zygaI think what happens is that stop doesn't really finish13:34
zygabefore we continue13:34
zygaotherwise I cannot explain this13:34
zygaah, wait13:35
zygaI think this is actually correct13:35
zygathe service doesn't terminate all the processes13:35
zygathis is expected13:35
zygamborzecki: sorry, alarm over13:35
mborzeckiijohnson: did you try btrfs too?13:37
ijohnsonmborzecki: no13:37
zygabut oddly it happened only on some systems, indicating that there's still something racy there13:38
zygahttps://github.com/snapcore/snapd/pull/8815 needs a 2nd review13:48
mupPR #8815: tests: port snap-handle-link test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8815>13:48
zygapstolowski: https://github.com/snapcore/snapd/pull/8819#pullrequestreview-42531573813:49
mupPR #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
pedroniszyga: sorry, had other things this morning, if I understand I should look at #8573? I put it in my queue, likely monday at this point13:50
mupPR #8573: overlord/snapstate: inhibit startup while unlinked <Created by zyga> <https://github.com/snapcore/snapd/pull/8573>13:50
zygapedronis: yes, getting some advice on how to proceed would help with the front-end side13:50
zygathanks, Monday is fine13:51
zygawith some luck I will be feeling better as well13:51
zygamvo: would you mind a quick look at https://github.com/snapcore/snapd/pull/880413:54
mupPR #8804: tests: port xdg-settings test to tests.session <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8804>13:54
zygadbus-daemon clean is so close13:55
mupPR snapcraft#3160 opened: project loader: fix v1 plugin repository installation on host <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3160>14:08
sergiusensmvo: just to circle back, the seed wait did seem to work14:11
zygais there a simrefinery snap yet?14:23
mvosergiusens: \o/ thank you14:24
jdstranddegville: 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 doc14:33
jdstranddegville: s/if new/or are you planning on writing a new doc? if new/14:33
mupPR 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
degvillejdstrand: (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
jdstranddegville: cool, I preferred updating. yes, happy to review :)14:40
pedronispstolowski: I reviewed #881914:51
mupPR #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
pstolowskipedronis: ty14:53
mupPR 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
mupPR 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 lunch15:13
mupPR snapd#8780 closed: tests: core20 early defaults spread test <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8780>15:14
mvopstolowski: nice weekend gift \o/15:29
pstolowskiyes indeed :)15:29
=== facundo__ is now known as facubatista
mupPR 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
ijohnsoncachio: is #8816 ready to review ?16:22
mupPR #8816: tests: port 2 uc20 part1 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8816>16:22
cachioijohnson, yes16:41
cachioijohnson, thanks16:41
sergiusensmvo: did you in the past 4 hours change any github permissions? Our Travis<->GH link just broke too16:49
mupPR 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
mvosergiusens: I did not change anything17:10
=== KindTwo is now known as KindOne
mupPR snapd#8822 opened: release: 2.45.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8822>17:19
mupPR 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
mupPR snapd#8786 closed: arch: add riscv64 <Created by xnox> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8786>18:05
mupPR snapcraft#3162 opened: tests: remove scenario usage from lifecycle order <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3162>18:09
mupPR 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
mupPR snapcraft#3163 opened: cli: remove the hidden inspect command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3163>18:34
mupPR 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
mupPR 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!