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