[06:13] Hello [06:43] mborzecki: today is the switch day [06:44] zyga: hey [06:44] zyga: 'the switch day' ? [06:44] Hi :-) [06:44] from/to what? [06:44] Check my PRs [06:44] snaps on the Nintendo Switch? [06:44] hahah ;) [06:44] Haha [06:44] That would be fun [06:44] zyga: didn't look yet, responding to some posts in the forum [06:45] Ok [06:45] I’m on a walk [06:45] Will start as usual [06:48] jamesh: but I want to mention something [06:48] Imagine if we embedded desktop metadata in an early block in each snap [06:48] Name, icon, etc [06:50] can you meaningfully control order in the squashfs? [06:51] or are you thinking of something outside of the squashfs structure? [06:52] Outside [06:52] You can make the FS leave a hole up front [06:52] It could be the same data we have later [06:52] But easier to extract for preview [06:54] So this would just be for the case of a user browsing a snap file in Nautilus? [06:54] For the most part [06:54] for installed snaps, we can just go through the mount point, and stuff in the store we can depend on store APIs [06:55] Well, I would love not having to mount unused snaps [06:55] Imagine we have 100s of revisions around [06:55] Or it is a phone again [06:55] You run only some at a time [06:55] Having access to metadata without mounting would be good [06:56] Mounting is costly and racy [06:56] so, icons could be many files if the snap takes advantage of icon theming [06:56] (We still tracks bugs in loop back devices and mount races) [06:56] I could definitely see other metadata be interesting [06:56] Yeah [06:57] I’m not super keen on theming. [06:57] I see this as a small container [06:57] A zip probably [06:57] Easy to discover and reas [06:57] Read* [06:57] That has some sort of meta/ directory copy [06:57] the icon theming is both to provide icons at multiple sizes and icons that look at home in different themes [06:58] I strongly believe in apps with curated icons that are never themed [06:58] Skype logo, ff logo [06:58] Etc [06:58] So I’m not focusing on that [06:58] right, but you may still want a different shape for 16x16 vs. 512x512 [06:58] We could presumably have several icons and enough information to use them [06:59] remove details, align to pixel grid, etc [06:59] Yes, agreed [06:59] I would love for snap list to. It have to mount snaps [06:59] *not [06:59] Anyway, just an idea [07:00] Some snaps would have to be mounted presumably [07:00] But most would not IMO [07:00] the current handling of desktop files and themed icons rely on copying data out of the snap during the install process [07:01] so could allow the shell to display launchers for snaps before they're mounted [07:01] Sure but snapd heavily relies on access to snap metadata directory of each revision [07:01] Yeah, that too [07:01] Like app image a little [07:01] (e.g. if the mount was delayed until "snap run" [07:01] Exactly! [07:02] You're probably going to need to temporarily mount the snap during the install process anyway though, right? [07:02] During install yes [07:02] Well [07:02] Maybe [07:02] For store snap not really [07:03] If we have assertions I don’t see why we would have to [07:03] Unless they have hooks [07:03] My point is that snapd would not need to anymore [07:03] Snap run would [07:03] So that is transparent [07:06] zyga: while you're playing around with github actions, a spread problem matcher could be a good addition [07:07] Oh yeah! [07:07] Jump right to the errors in the log [07:07] Indeed === mborzeck1 is now known as mborzecki [07:07] I need to make spread and action anyway [07:08] zyga: so your basement data center is up and operational now? :) [07:08] To handle post [07:09] mborzecki: not required [07:09] I'm not sure we'd be able to link the errors to files, but at least it would recognise that there were errors in the log [07:09] btw. now that spread is part of thw tests workflow, if one job fails we'll restart the whole forkflow right? unit tests and all [07:10] (if the full file name isn't in the log message, then it's not there to extract via a regexp) [07:10] Yeah we can do that [07:14] zyga: heh ok i see why you're doing this in #8363 [07:14] PR #8363: github: combine tests into one workflow [07:16] zyga: so we need the ability to restart single job in workflow or dependencies between workflows right (then spread workflow* would depend on unit tests succeeding) [07:18] re [07:19] mborzecki: that's already done [07:19] mborzecki: restarting single jobs is coming in next actions release IIRC [07:19] mborzecki: so we can just wait [07:19] mvo: good morning [07:19] I love how our PRs that move workload from travis to github actions are blocked by travis [07:20] zyga: good morning [07:20] mvo: could you please look at 8362, 8364 and 8364 [07:20] mvo: I think you will find there's a logical progression towards the result there [07:21] mvo: this doesn't change the status quo yet, I'll make one shortly that does [07:21] zyga: checkin [07:21] mvo: switching off travis entirely in the process [07:21] g [07:21] thank you very much sir :) [07:26] PR snapd#8362 closed: github: fix order of go get caches [07:27] * zyga politely asks for reviews of a +3,-2 PR: https://github.com/snapcore/snapd/pull/8089 [07:27] PR #8089: features: enable robust mount ns updates [07:27] PR snapd#8363 closed: github: combine tests into one workflow [07:30] mvo: jamesh gave me an idea, we could use a feature of github actions to spot errors in spread [07:30] there's a way to run a scanner over the log [07:30] and say "here, there is something interesting here' [07:30] and this is the label" [07:31] we could extract each error even without looking at the logs ourselves [07:31] it requires some javascript to be written though [07:31] so not today [07:31] but it's totally doable and many actions use this [07:31] zyga: shouldn't require any javascript [07:31] jamesh: oh? [07:31] IIRC most actions require that [07:31] but maybe I missed something [07:32] I need to use javascript anyway, to implement post: ... [07:32] mvo: please check my comment on -abend [07:32] you just need a json file containing the problem matcher, and you can issue a command to enable it with the appropriate "echo" incatation [07:32] jamesh: but that requires a proper action [07:32] zyga: no [07:32] or are you saying this is something any run: ... thing can do? [07:33] that would be amazing, can you point me to any examples or docs for this? [07:33] I didn't know about this [07:33] all the javascript does is print a specially formatted command to stdout [07:33] let me see [07:33] jamesh: do you know if there is something like "fail-ok" like on travis? we have som eunstable systems that we consider failures to be ok but the summary on the /pulls list has a red "x" once one action fails [07:33] zyga: problem matcher json example: https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md [07:33] zyga: command to enable problem matcher: https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers [07:34] ah [07:34] that's super useful [07:34] thank oyu [07:34] I wonder what's that weird ::foo syntax they have [07:34] I've seen it used to set env variables [07:34] but I didn't find a reference of what else you can do [07:34] it's the syntax for steps to issue commands to the runner [07:35] thank you :) [07:35] there's similar stuff in Travis with different syntax [07:35] (for e.g. reporting timing or folding sections of output) [07:38] The main reason they push JS for reusable actions is because it is portable across linux, macosx, and Windows [07:39] It doesn't actually have any special powers you can't do through a simple shell script "run:" step [07:40] mvo: pushed [07:40] jamesh: my view on that https://twitter.com/zygoon/status/1243239498101768192 [07:41] zyga: I did "snap install node" [07:42] I will try [07:42] actually, "snap install --channel 13/stable node" [07:42] I suspect I still need to get the million shitty dependencies from non [07:42] Npm [07:42] --classic too, actually [07:42] each project is going to install its own dependencies [07:43] the same as go projects [07:43] this is just the way the world works these days :-) [07:43] Except go has a stdlib [07:43] so does node [07:43] Maybe go has a better one :-) [07:44] I meant almost 300 dependencies [07:44] Each one with a small lib [07:44] the node one has some serious warts [07:44] Yeah, I think node itself is just one big wart with smaller warts you can add on top :-) [07:44] (I don’t like that stack) [07:46] I'm not sure why the .deb version is pulling in so many dependencies [07:48] zyga: I'd recommend taking Github's typescript-action template and work from there [07:49] that'll give you a working npm project with code reformatting and linting built in, plus TypeScript's type annotation checking [07:49] makes things slightly less error prone [07:49] Good idea [07:50] That's what I did, and then just pretended it was weird looking Python [08:01] morning [08:04] good morning pawel [08:06] pstolowski: hey! [08:24] PR snapd#8367 closed: cmd/snap: the model command needs just a client, no waitMixin [08:37] PR snapd#8368 opened: github: goodbye travis [08:48] mvo: heh [08:49] mvo: spread without -v prints preparing, restoring [08:49] and executing too [08:49] * zyga wonder if something is broken [08:49] it's not any more quiet for sure [08:51] we need --quiet then :/ [08:57] zyga: hm iirc -v only adds some extra bits about packing the tarball [08:57] uh? [08:57] weird [08:57] pstolowski: is 8270 ready? it's still mark blocked but got a +1 from samuele already? [08:57] and -vv does the backend query dumps [08:57] so we need -q [08:58] or something like that [08:59] mvo: yes it's ready, it was only blocked because of endpoint name change (which was done). we can contemplate specializing some errors based on the list from Tony, but I think it can be a followup [09:00] mvo: and maybe it won't be needed (i haven't analyzed the list yet) [09:00] pstolowski: ok, please remove the blocked label then and I will try to get to it later today (but tons of meetings) [09:01] mvo: sure, done [09:01] and thanks\ [09:02] ta [09:06] our static checks run slower than our unit tests [09:06] needs some polish there [09:27] mborzecki: check out 8368 [09:28] static checks, then unit tests, then two canary spread runs (16.04 and core16) then all remaining stable spread systems then unstable (non-failing) [09:42] PR snapd#8369 opened: boot, overlord/devicestate, daemon: [09:42] mvo: ^^ [09:42] zyga: some static checks could be written in go linters, but hard to say whether that'd make them faster [09:42] mborzecki: no, it's mostly silliness in how we run them [09:43] mborzecki: we can make it near-instant [09:43] mborzecki: need to decouple from run-checks monster [09:43] run-monster-checks [09:43] mborzecki: but not super priority, I wanted to switch over away from travis [09:43] so nobody has to wait [09:43] then we can polsh [09:43] so people are amazed that we didn't do it earlier [09:43] f... travis build failed again [09:44] google:debian-9-64:tests/main/interfaces-packagekit-control failed https://www.irccloud.com/pastebin/RJNxNY3y/ [09:45] please review https://github.com/snapcore/snapd/pull/8364 :) [09:45] PR #8364: github: offload self-hosted workers [09:46] hmm spread-shellcheck could run the MATCH -v and multiline checks, and it's already parallel, so at least locally there could be a difference [09:55] mborzecki: we need to break down big chunks into separate steps [09:55] then we see time [09:55] then we optimize [09:55] then we win [09:56] mborzecki: we should aim to get both get better total throughput and responsiveness - I think careful decomposition, dependencies and not duplicating work gets us there [09:56] also, not running things over and over and over and over and over again like often do [09:57] brb, need tissue, my nose is running like crazy (each spring the same story) [09:57] sorry :| [10:19] re [10:34] I'd like to merge https://github.com/snapcore/snapd/pull/8364 [10:34] PR #8364: github: offload self-hosted workers [10:34] to make my home network more compatible with home learning [10:34] mvo: ^ [10:34] mborzecki: ^ [10:41] zyga: was in a meeting, looking [10:41] ta [11:00] are snapcraft forum notifications working for anyone here? I neither get push notifications in the browser, nor the email notifications. Didn't change my settings. [11:04] dot-tobias: they are [11:06] Hi. What plugs do I need to declare for access to /dev/uinput and /sys/bus/usb/devices/ ? [11:13] mcphail: hello, currently nothing exposes /dev/uinput [11:13] mcphail: as for /sys/bus/usb/devices therer are a few depending on what you need (read/write?) [11:13] you can use hardware-observe or raw-usb or a few others [11:14] zyga: aargh. That's a shame. Trying to get sc-controller to run confined. I think I just need read to the usb devices [11:14] sc-controller? [11:14] mcphail: new interfaces can be added [11:14] app to get steam controllers running on non-steam games. Doesn't work on 20.04 because of no real python2 support [11:15] I'm trying to debug something now but if you leave us the details, ideally on the forum, a new interface can be crafted rather quickly [11:15] Will do. Thanks zyga [11:55] brb [11:56] PR snapd#8364 closed: github: offload self-hosted workers [11:56] ta! [11:56] mvo: I will do more about gh actions over weekend [11:56] mvo: but not today [11:56] mvo: some preview is in that draft branch that has proper sequencing and no longer uses travis [11:56] mvo: but I need to port misc stuff and improve things [11:57] mvo: unless you say this is a priority [12:16] mvo: you're right lzo compressed snaps get held for review. https://paste.ubuntu.com/p/Z7YnNPKd3h/ [12:36] re [12:41] mborzecki: I want to add a parser for /proc/PID/cgroup [12:41] mborzecki: shall the parser to to osutils and the high-level use to sandbox/cgroup? [12:42] mborzecki: https://github.com/snapcore/snapd/pull/8369 has a weird title (empty) [12:42] PR #8369: boot, overlord/devicestate, daemon: [12:44] zyga: hmm sandbox/cgroup feels like a better fit [12:58] spread feature I would kill for (not really): preserving history [13:27] popey: yeah, the review is expected, should be possible to manually override I hope [13:28] zyga: not a priority, we need to make sure we also have the static tetss etc [13:28] mvo: I ported static tests over, I need to port CLA check and some misc bits though [13:29] zyga: nice [13:35] * zyga figured out how to handle session-tool reliably, more so than before :) [13:35] ha, and also for root user [14:54] mborzecki: https://github.com/snapcore/snapd/pull/8370 [14:54] PR #8370: snap-bootstrap: fix disk layout sanity check [14:54] PR snapd#8370 opened: snap-bootstrap: fix disk layout sanity check [14:55] cmatsuoka: thanks! [14:56] mborzecki: hopefully this will solve the issue and the crash-before-mkfs scenario as well [15:01] zyga: https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1869332 is what I reported [15:01] Bug #1869332: Fails to launch correctly with gnome-shell in focal [15:01] zyga: what bugreport did you see? [15:01] mvo: the bug I ran into was different, it was locale dependent [15:02] the .mo file contained a translation that segvfaulted [15:02] but [15:02] the locale was different in the session and in the terminal somehow [15:02] in the end I fixed that one, but that was years ago and I stopped using xchat since [15:02] oh well [15:07] PR snapd#8371 opened: overlord/devicestate, daemon: record the seed current system was installed from [15:55] * cachio lunch [15:57] cmatsuoka: just before i leave, some good news, the branch seems to work [15:58] \o/ [15:58] cmatsuoka: i was able to reboot form run to install again, get eveyrthing reinstalled and back to new run ;) [15:58] great! thanks [15:59] cmatsuoka: thanks for the patch! [15:59] and time to EOD [15:59] lunch time for me, bbl [16:13] * zyga tries to get stuff finished [16:13] no weekend yet :) [16:21] zyga: could you quick re-review #8365 ? it would be great to get that in today [16:21] PR #8365: seed: add Info() method for seed.Snap [16:21] sure [16:21] thanks! [16:22] +1 [16:22] but red on travis :/ [16:22] yeah needs some travis wrangling [16:23] mvo: one more suprpsing advantage of github actions - virtually no time limit [16:23] mvo: jobs can run up to 72 hours IIRC [16:24] wow that's both awesome and a bit scary [16:31] zyga: woah [16:32] mvo: ? :-) [16:32] ah [16:32] ;D [16:32] yeah [16:32] it was a surprise to me :) [16:32] no more 50 minute death === genii_ is now known as genii [16:36] zyga: yeah, very cool [17:45] mvo: have we switched to the key for c20? [17:45] cmatsuoka: do you know if systemd reads any configuration from EFI? [17:45] stracing a random busctl tool revealed [17:45] openat(AT_FDCWD, "/sys/firmware/efi/efivars/SystemdOptions-8cf2644b-4b0b-428f-9387-6d876050dc67", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT ( [17:45] it would be unfortunate if our secure boot + encryption scheme was foiled by a debug=1 in EFI var somewhere [17:45] zyga: mm interesting [17:45] cmatsuoka: do we measure EFI? [17:46] xnox: ^ FYI [17:47] anyway, now you know [17:47] * zyga is back to digging [17:47] it's measured, I believe [17:47] zyga: why are you pinging me? [17:48] xnox: sorry, you are someone who I associate with systemd knowledge [17:48] zyga: but what is your ping? it has no context, and no questions =) [17:48] ah, sorry [17:48] zyga: just because i idle in the channel, i don't actually read it =) [17:49] xnox: the question is this, is there any EFI variable that could, unmeasured, defeat the encryption in core 20 [17:49] i just camp out for pings [17:49] e.g. something that could give you systemd debug shell [17:49] zyga: nothing to do with me, is it? [17:49] or similar [17:49] debug-shell.service will not start, if measurements are bad [17:50] that's reassuring [17:50] xnox: also didn't you just disable debug-shell entirely unless dangerous is on the cmdline ? [17:50] thanks, I just bumped into this in a strace [17:50] and was surprised [17:50] EFI firmware is measured, but currently is not part of the sealing policy => ask security about that [17:50] (i.e. we don't seal to it) [17:50] ijohnson: yes [17:50] right [17:50] and we do seal keys to the cmdline measurement [17:50] right, I remember cmdline [17:51] I was worried that EFI is a hidden 'cmdline' that's not measured somehow [17:51] (EFI == EFI variables) [17:52] zyga: I'm not sure what c20 is? uc20? and what key? [17:53] core 20 [17:53] mvo: the signing key for the kernel [17:53] zyga: aha, not yet [17:53] zyga: do you know what broken seed pawel was using? [17:53] yes I do [17:53] zyga: for bug https://bugs.launchpad.net/snapd/+bug/1868706 [17:53] Bug #1868706: Snapd postinst script hangs [17:53] mine :) [17:53] zyga: nice, can you mail/make this available? [17:53] zyga: trying to write a regression test right now [17:53] can I TG it? [17:54] sure [17:54] it's 350MB tarball [17:54] whatever works for you [17:54]