[07:16] <zyga> Good morning
[08:21] <zyga> a bit empty today...
[08:21] <zyga> wonder if netsplit
[08:21] <zyga> or flu
[08:31] <mvo> zyga: vacation, swap days, ...
[08:31] <zyga> hey :)
[08:31] <zyga> mvo: indeed
[08:31] <zyga> mvo: welcome back!
[08:31] <mvo> zyga: I will probably also swap at least half a day but wanted to double check how things are
[08:31] <zyga> mvo: we had some humps
[08:32] <mvo> zyga: yeah, was reading what you did on friday
[08:32] <zyga> mvo: lxd candidate started handing out i386 containers
[08:32] <mvo> zyga: thanks for digging into all this!
[08:32] <zyga> mvo: one test needs investigation as it breaks on core20
[08:32] <mvo> zyga: yeah, read that too, that was hillarious
[08:32] <zyga> mvo: I'm just looking at results
[08:32] <mvo> zyga: yeah, I suspect we stopped using shadow for the user tools
[08:32] <zyga> mvo: and I found a few leaks
[08:32] <zyga> mvo: no progress on reviews from security team yet
[08:33] <mvo> zyga: I remember there was a switch planned to something else that also provides userdel but a) I may misremember b) I can't remember what the other source package was :/
[08:33] <zyga> hmm
[08:33] <zyga> I see
[08:33] <zyga> I tried to make all of my branches green though I didn't manage to for the few oldest
[08:33] <mvo> zyga: nice
[08:33] <mvo> zyga: I investigate this userdel issue
[08:36] <mvo> zyga: what is confusing is that this test fails on core20 but not on ubuntu-20.04-64
[08:36] <zyga> oh, indeed
[08:36] <zyga> ppa skew?
[08:37] <mvo> zyga: could be, I will just try to reproduce, also strange that it just started recently to fail - oh well
[08:38] <zyga> yeah, it failed on Friday
[08:53] <zyga> mvo: skipping 1:1 today?
[08:53] <mvo> zyga: see /msg
[09:01] <mup> PR snapd#8050 opened: tests: add marker tag for core 20 test failure <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8050>
[09:02] <zyga> mvo: given that you are here still - can I merge https://github.com/snapcore/snapd/pull/8047
[09:02] <mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
[09:05] <mup> PR snapd#8034 closed: overlord/snapstate: fix for lp:1860324 for 2.43 <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8034>
[09:06] <zyga> mvo: any news about 2.43 revert for /writable?
[09:06] <zyga> mvo: should we revert?
[09:06] <mvo> zyga: no update yet so I think we should
[09:07] <mvo> zyga: or I missed a mail which is quite possible
[09:07] <mvo> zyga: I think I will do 2.43.2 tomorrow morning
[09:07] <zyga> the branch is sitting green, let's wait until we get some news today
[09:07] <zyga> and pick the decision tomorrow
[09:07] <zyga> I'll check the bug report
[09:08] <mvo> zyga: thank you!
[09:09] <zyga> mvo: the customer is okay with the workaround but the timing is that they would rather have a revert now
[09:10] <mvo> zyga: sure thing
[09:10] <zyga> mvo: I'll grab a coffee and do some reviews and merges
[09:11] <mvo> zyga: sounds great, I will leave irc for a bit, availalbe on tg for emergencies
[09:16] <sdhd-sascha> hey, zyga - "markstos" seems to be very interrested in termite on classic. And also likes sway and i3. Maybe we can bring the gnome-extension into classic-mode, so the termite's snapcraft.yaml didn't need to much environments and scripts...
[09:16] <sdhd-sascha> (just for your information. )
[09:25] <Chipaca> 👋
[09:36] <zyga> re
[09:36] <zyga> sdhd-sascha: it's probably silly but I don't follow - gnome-extension classic mode?
[09:36] <zyga> Chipaca: hello
[09:37] <zyga> how are you? are you off today or working>.
[09:39] <sdhd-sascha> zyga: i know. What i want to say is, that there are some one more, which could help. And i know you are good in social connections. So i just want inform you. Nothing more ;-)
[09:40] <Chipaca> zyga: working today
[09:45]  * zyga nods
[09:48] <Chipaca> not sure when I'm going to get a break tbh :)
[09:48] <mup> PR snapd#8022 closed: cmd/snap-confine: Revert #7421 (unmount /writable from snap view) <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8022>
[09:48] <zyga> Chipaca: anytime you feel like it
[09:48] <zyga> it's a bit of tumbleweed territory here today
[09:48] <zyga> maciek and pawel are off
[09:48] <Chipaca> s/break/swap/
[09:48] <zyga> mvo and samuele are off too
[09:48] <zyga> cachio is off
[09:49] <zyga> ian will come around in a few hours
[09:49] <Chipaca> zyga: I've come back from za with a rather hard deadline for some things i need to get done :)
[09:49] <zyga> I see
[09:50] <Chipaca> zyga: thank you for the note on #7421
[09:50] <mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7421>
[11:17] <zyga> Chipaca: I sent small tweaks to https://github.com/snapcore/snapd/pull/8045
[11:17] <zyga> Chipaca: and removed my review since I changed it now
[11:17] <mup> PR #8045: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8045>
[11:17] <zyga> Chipaca: do you want to do a second review?
[11:17] <zyga> I tried to document my patches as best as I could
[11:19] <Chipaca> zyga: will do in a bit
[11:19] <zyga> thank you, it's not urgent though
[11:19] <Chipaca> "a bit" → a while (knee-deep in users right now, and then have a manpages meeting, and then standup...)
[11:19] <Chipaca> zyga: speaking of which, do you want to come to the manpages meeting?
[11:20] <zyga> yeah
[11:20] <zyga> I was about to ask
[11:20] <Chipaca> is that something that interests you?
[11:20] <Chipaca> ok :)
[11:20] <zyga> yeah, greatly
[11:20] <zyga> over the past few weekends I've been hand-writing manual pages :)
[11:20] <zyga> (seriously)
[11:20] <mup> PR snapd#8050 closed: tests: add marker tag for core 20 test failure <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8050>
[11:20] <Chipaca> zyga: FWIW manpages is black, so unless I can do it this week it's not getting done, but I'd rather somebody else in the snapd team knew about what needed to be done
[11:28] <sdhd-sascha> Is it a goal, that classic and strict snaps should work the same in future ?
[11:28] <zyga> sdhd-sascha: in which sense
[11:28] <zyga> sdhd-sascha: there's a fundamental difference between them
[11:30] <sdhd-sascha> For the user, who creates a snap.
[11:30] <zyga> no, they will always be different then
[11:31] <sdhd-sascha> Oh :-( Then it would be nice, if a git-branch can be used as a track on snapstore, at least.
[11:31] <zyga> git branch?
[11:34] <mup> PR snapd#8051 opened: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <https://github.com/snapcore/snapd/pull/8051>
[11:36] <sdhd-sascha> zyga: i mean - the store people. Could implement a feature, that per "github" branch, a automated build and publish pipeline to a "track" exist. So, in git there is a "classic", "devmode" and "strict" branch.
[11:36]  * sdhd-sascha afk
[11:36] <Chipaca> sdhd-sascha: the ability to be classic is a per-snap attribute
[11:36] <Chipaca> sdhd-sascha: so tracks for classic are not typically approved
[11:36] <Chipaca> sdhd-sascha: recommendation is to use a different name for classic vs non-
[11:37]  * Chipaca takes a break
[11:37] <sdhd-sascha> Chipaca: i know. That's why i started to upload snaps on github... Would it make sense to have a community store, with lesser restrictions ?
[11:38] <zyga> sdhd-sascha: no, because that would be an enormous effort and why?
[11:38] <zyga> community store becomes curl | sudo sh
[11:38] <zyga> that's not useful
[11:38] <zyga> and not responsible
[11:39] <sdhd-sascha> hmm, maybe a case for a cmdline option for `snap install <url>`
[11:39] <zyga> classic?
[11:39] <zyga> wget && snap install --dangerous
[11:39] <zyga> but that's not better either
[11:40] <sdhd-sascha> zyga: like it is now. `--dangerous` makes sense
[11:40] <zyga> this is not a technical limitation, it's a design that prioritizes safety
[11:40] <sdhd-sascha> yes
[11:58] <Chipaca> zyga: added you to the manpages meet, but it has not meet url atm
[11:58] <zyga> Chipaca: is there a video ?
[11:58] <zyga> aj
[11:58] <zyga> ah
[11:58] <zyga> ok
[11:58] <Chipaca> zyga: cjwatson can add that, i can't
[11:58] <Chipaca> :-)
[11:59] <Chipaca> cjwatson: thanks
[11:59] <cjwatson> I just did
[12:18] <mup> PR snapcraft#2895 opened: lifecycle: raise detailed error if mksquashfs fails <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2895>
[12:24] <zyga> that was fun :)
[12:25] <Chipaca> zyga: actually i said wednesday but pedronis is back tomorrow afaik so i'll chat then
[12:25] <Chipaca> calendar allowing
[12:25] <Chipaca> zyga: you want in on that meeting as well?
[12:25] <zyga> yeah
[12:26]  * Chipaca adds
[12:28] <cjwatson> Chipaca,zyga: https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb
[12:29] <zyga> Chipaca: check out the standup doc please
[12:29] <zyga> Chipaca: I added one bit that we didn't discuss
[12:30] <zyga> highlighted now
[12:30]  * Chipaca looks
[12:31] <zyga> Chipaca: if we go and model manual pages, I wonder if this is a one-off
[12:31] <zyga> or is this "snap ships content to unconfined world"
[12:31] <Chipaca> zyga: meta/man would also be backwards compatible :)
[12:31] <zyga> Chipaca: yes
[12:31] <zyga> Chipaca: but not $SNAP/man (that was my only point)
[12:32] <Chipaca> zyga: updated the meeting description with this as well
[12:33] <Chipaca> cjwatson: <3
[12:34] <Chipaca> ok, i need to go get veggies to go with my lunch
[12:34]  * Chipaca vegs out
[12:34] <zyga> o/
[12:35] <cmatsuoka> Chipaca: interesting test error in the users refactoring PR
[12:39] <cjwatson> Chipaca,zyga: Hm, I forgot to check, does the name mediation bit require any store changes?
[12:39] <cjwatson> I never found out how that worked before I mostly stopped working on the store
[12:39] <zyga> cjwatson: I suspect it would - which is also easier if it's explicit rather than fished from the filesystem structure
[12:41] <cjwatson> Somebody who has a clue what's involved should loop in Bret ASAP then
[12:41] <zyga> cjwatson: I think we should do that after the call tomorrow
[12:41] <cjwatson> But if that doesn't happen then <snap-name> and <snap-name>.* will still work, right?
[12:41] <zyga> it's probably not the store as much as review tools
[12:41] <cjwatson> Er right, maybe Jamie then
[12:42] <cjwatson> I won't release man-db for a week or so, just in case
[12:48] <zyga> Chipaca: daemon/api_users_test.go:220:42: "potatos" is a misspelling of "potatoes"
[12:48] <zyga> 862
[13:03] <Chipaca> cjwatson: re name mediation, if it goes beyond what aliases does, yes -- i'll add that to the meeting with samuele tomorrow
[13:03] <cjwatson> Ta
[13:04] <Chipaca> I expect it'd look like another assertion type, with snapd needing to do some work but not the store
[13:05] <zyga> I think so too
[13:05] <Chipaca> but I might be over-optimistic wrt the store side of assertions
[13:13] <zyga> I'm off for a walk with Bit
[13:16] <cmatsuoka> Chipaca: could you have a look at https://bugs.launchpad.net/snapd/+bug/1860773? It seems that we have a problem in default track error messages
[13:16] <mup> Bug #1860773: Default track not in error message when branch requested <snapd:New> <Snap Store:New> <https://launchpad.net/bugs/1860773>
[13:16] <Chipaca> cmatsuoka: that was filed at my behest
[13:17] <cmatsuoka> Chipaca: ah good, thanks
[13:17] <Chipaca> cmatsuoka: IOW, yes yes we do -- I knew we did, although I didn't predict this exact flavour
[13:18] <cmatsuoka> Chipaca: should I assign it to you, or leave it unassigned?
[13:18] <Chipaca> cmatsuoka: there's a store-side component to that because the error from the store doesn't let us tell the user the right thing
[13:18] <cmatsuoka> hmm
[13:18] <Chipaca> cmatsuoka: leave it unsigned -- i doubt i'll have time to get to it
[13:18] <cmatsuoka> ok
[13:19] <Chipaca> cmatsuoka: the quick fix would be to make snapd not tell the user the channel it was looking for
[13:19] <Chipaca> cmatsuoka: the better fix would be to make the channel mapper default-track-aware, and pass in the default track from the error response (that's the bit that's missing)

[13:21] <Chipaca> cjwatson: about https://git.savannah.gnu.org/cgit/man-db.git/commit/?id=81dc1ae9bd2d99a264bcf79ea76902e5db02aadb
[13:22] <Chipaca> cjwatson: note in redhat etc that'd be /var/lib/snapd/snap/man
[13:23] <Chipaca> "redhat etc" is release.DistroLike("fedora", "arch", "archlinux", "manjaro", "antergos")
[13:23] <cjwatson> Chipaca: I'll try to remind those packagers that they need to patch that
[13:23] <Chipaca> cjwatson: 👍
[13:23] <cjwatson> I think it's reasonable for upstream man-db to refer to upstream snapd's path, though
[13:24] <Chipaca> cjwatson: fair
[13:25] <Chipaca> cjwatson: also while those distros don't like /snap/, most of their users will have it anyway because without it they don't get classic snaps
[13:27]  * Chipaca looks athttps://github.com/rydal/tuxconfig-frontend and is terrified
[13:58] <zyga> re
[14:01] <zyga> Chipaca: standup?
[14:01] <Chipaca> zyga: omw
[14:48] <ijohnson> hmm one of the case fans on my desktop has stopped spinning :-/
[14:48]  * ijohnson reboots
[15:09] <ackk> hi, does anyone have an opinion on https://bugs.launchpad.net/snapcraft/+bug/1860884 ?
[15:09] <mup> Bug #1860884: Python plugin: paths for from the snapcraft snap in sys.pat break dependencies <Snapcraft:New> <https://launchpad.net/bugs/1860884>
[15:22] <zyga> Chipaca: quick review on https://github.com/snapcore/snapd/pull/8051#pullrequestreview-348743013
[15:22] <mup> PR #8051: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <https://github.com/snapcore/snapd/pull/8051>
[15:31] <mup> PR snapcraft#2896 opened: Fix the package 'python3-distutils' not found on Ubuntu Xenial <Created by khiemdoan> <https://github.com/snapcore/snapcraft/pull/2896>
[15:41] <mup> PR snapd#8045 closed: osutil: add helpers for creating symlinks and renaming in an atomic manner <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8045>
[15:43] <ijohnson> cmatsuoka: mind giving a quick re-review to #8044 ? I merged master so the diff should is pretty small now
[15:43] <mup> PR #8044: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
[15:43]  * zyga looks as well
[15:46] <cmatsuoka> ijohnson: sure, checking it now
[15:46] <ijohnson> thanks!
[15:56] <cmatsuoka> ijohnson: done
[15:59] <Chipaca> zyga: thank you for the review
[15:59] <zyga> :)
[16:04] <mup> PR snapd#8052 opened: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8052>
[16:04] <ijohnson> thanks cmatsuoka, I just opened ^ which is the followup you requested
[16:05] <zyga> the leftovers would be the temporary files, right
[16:05] <zyga> ?
[16:14] <Chipaca> zyga: pushed changes you suggested to the 8051
[16:14] <zyga> mmm
[16:27] <ijohnson> zyga: yes that's what I meant by leftovers
[16:27]  * ijohnson is bad at puns
[16:37] <zyga> ijohnson: https://github.com/snapcore/snapd/pull/8052#pullrequestreview-348804159
[16:37] <mup> PR #8052: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple 😃> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8052>
[16:40] <ijohnson> zyga: thanks, I think I'll leave it as is (but also I responded in the PR)
[16:40] <zyga> that's fine
[17:53] <mup> PR snapd#8044 closed: grub: support atomically renaming kernel symlinks <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8044>
[18:27] <mup> PR snapd#8052 closed: osutil/tests: check there are no leftover symlinks with AtomicSymlink <Simple 😃> <Test Robustness> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8052>
[18:38]  * zyga goes to install focal on bare metal
[18:38] <zyga> with nvidia
[18:38] <zyga> this will be fun
[18:55] <zyga> bah, contention
[18:56] <zyga> popey: is the new shiny theme hitting the daily anytime soon?
[18:57] <zyga> jdstrand_: hey, how is the review queue looking this week?
[18:58] <jdstrand_> zyga: same as last week since I haven't started the push yet
[18:58] <zyga> jdstrand_: but you still plan to this week?
[18:59] <jdstrand> zyga: that is still my plan, yes
[18:59] <zyga> good, that's all I wanted to check
[19:06]  * zyga has focal usb but goes for supper first
[20:06] <mup> PR snapd#8051 closed: daemon: refactor create-user to a user action & hide behind a flag <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8051>
[21:15] <cmatsuoka> ijohnson: are we still packing .go files inside the snapd snap? if so, there's an easy way to fix that
[21:15] <ijohnson> cmatsuoka: you mean in the snapd snap in the store?
[21:15] <ijohnson> cmatsuoka: I hope we aren't
[21:16] <cmatsuoka> ijohnson: I think we were, many months ago, let me check that...
[21:17] <ijohnson> cmatsuoka: I don't see any .go files in the snapd snap
[21:17] <cmatsuoka> ijohnson: we're still doing it. look what's inside the snap directory in the snapd snap
[21:17] <ijohnson> cmatsuoka: that dir is empty for me
[21:18] <ijohnson> cmatsuoka: actually you know what I'm looking at a snapd snap I built myself, not one from the store
[21:18] <cmatsuoka> hmm, I just ran snap download snapd and unsquashed the snap
[21:19] <cmatsuoka> ijohnson: could you try it and check the snap subdir for a bunch of .go files?
[21:20] <ijohnson> cmatsuoka: yeah I see it with what's built from the store
[21:20] <ijohnson> FWIW, I have been building local snapd snaps with my branch: https://github.com/snapcore/snapd/pull/7904 which doesn't suffer this problem
[21:20] <mup> PR #7904: snapcraft.yaml: add type, build-base and adopt-info, rm builddeb plugin <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
[21:22] <cmatsuoka> ijohnson: ah ok, then it was fixed in snapcraft and the fix was used when you added base: core
[21:22] <ijohnson> cmatsuoka: yes IIUC the current snapd snap is still built with legacy snapcraft
[21:22] <cmatsuoka> ijohnson: it used to happen because snap/ is special and one way to fix that was to use build-aux/snap but if it's not necessary it's even better
[21:23] <ijohnson> cmatsuoka: my branch also uses build-aux/snap so perhaps that's why
[21:23] <cmatsuoka> ah right ok, you already have the fix then :D
[22:51] <mup> PR snapd#8053 opened: osutil: implement deluser <Created by chipaca> <https://github.com/snapcore/snapd/pull/8053>