| zyga | Hello | 06:13 |
|---|---|---|
| zyga | mborzecki: today is the switch day | 06:43 |
| mborzecki | zyga: hey | 06:44 |
| mborzecki | zyga: 'the switch day' ? | 06:44 |
| zyga | Hi :-) | 06:44 |
| mborzecki | from/to what? | 06:44 |
| zyga | Check my PRs | 06:44 |
| jamesh | snaps on the Nintendo Switch? | 06:44 |
| mborzecki | hahah ;) | 06:44 |
| zyga | Haha | 06:44 |
| zyga | That would be fun | 06:44 |
| mborzecki | zyga: didn't look yet, responding to some posts in the forum | 06:44 |
| zyga | Ok | 06:45 |
| zyga | I’m on a walk | 06:45 |
| zyga | Will start as usual | 06:45 |
| zyga | jamesh: but I want to mention something | 06:48 |
| zyga | Imagine if we embedded desktop metadata in an early block in each snap | 06:48 |
| zyga | Name, icon, etc | 06:48 |
| jamesh | can you meaningfully control order in the squashfs? | 06:50 |
| jamesh | or are you thinking of something outside of the squashfs structure? | 06:51 |
| zyga | Outside | 06:52 |
| zyga | You can make the FS leave a hole up front | 06:52 |
| zyga | It could be the same data we have later | 06:52 |
| zyga | But easier to extract for preview | 06:52 |
| jamesh | So this would just be for the case of a user browsing a snap file in Nautilus? | 06:54 |
| zyga | For the most part | 06:54 |
| jamesh | for installed snaps, we can just go through the mount point, and stuff in the store we can depend on store APIs | 06:54 |
| zyga | Well, I would love not having to mount unused snaps | 06:55 |
| zyga | Imagine we have 100s of revisions around | 06:55 |
| zyga | Or it is a phone again | 06:55 |
| zyga | You run only some at a time | 06:55 |
| zyga | Having access to metadata without mounting would be good | 06:55 |
| zyga | Mounting is costly and racy | 06:56 |
| jamesh | so, icons could be many files if the snap takes advantage of icon theming | 06:56 |
| zyga | (We still tracks bugs in loop back devices and mount races) | 06:56 |
| jamesh | I could definitely see other metadata be interesting | 06:56 |
| zyga | Yeah | 06:56 |
| zyga | I’m not super keen on theming. | 06:57 |
| zyga | I see this as a small container | 06:57 |
| zyga | A zip probably | 06:57 |
| zyga | Easy to discover and reas | 06:57 |
| zyga | Read* | 06:57 |
| zyga | That has some sort of meta/ directory copy | 06:57 |
| jamesh | the icon theming is both to provide icons at multiple sizes and icons that look at home in different themes | 06:57 |
| zyga | I strongly believe in apps with curated icons that are never themed | 06:58 |
| zyga | Skype logo, ff logo | 06:58 |
| zyga | Etc | 06:58 |
| zyga | So I’m not focusing on that | 06:58 |
| jamesh | right, but you may still want a different shape for 16x16 vs. 512x512 | 06:58 |
| zyga | We could presumably have several icons and enough information to use them | 06:58 |
| jamesh | remove details, align to pixel grid, etc | 06:59 |
| zyga | Yes, agreed | 06:59 |
| zyga | I would love for snap list to. It have to mount snaps | 06:59 |
| zyga | *not | 06:59 |
| zyga | Anyway, just an idea | 06:59 |
| zyga | Some snaps would have to be mounted presumably | 07:00 |
| zyga | But most would not IMO | 07:00 |
| jamesh | the current handling of desktop files and themed icons rely on copying data out of the snap during the install process | 07:00 |
| jamesh | so could allow the shell to display launchers for snaps before they're mounted | 07:01 |
| zyga | Sure but snapd heavily relies on access to snap metadata directory of each revision | 07:01 |
| zyga | Yeah, that too | 07:01 |
| zyga | Like app image a little | 07:01 |
| jamesh | (e.g. if the mount was delayed until "snap run" | 07:01 |
| zyga | Exactly! | 07:01 |
| jamesh | You're probably going to need to temporarily mount the snap during the install process anyway though, right? | 07:02 |
| zyga | During install yes | 07:02 |
| zyga | Well | 07:02 |
| zyga | Maybe | 07:02 |
| zyga | For store snap not really | 07:02 |
| zyga | If we have assertions I don’t see why we would have to | 07:03 |
| zyga | Unless they have hooks | 07:03 |
| zyga | My point is that snapd would not need to anymore | 07:03 |
| zyga | Snap run would | 07:03 |
| zyga | So that is transparent | 07:03 |
| jamesh | zyga: while you're playing around with github actions, a spread problem matcher could be a good addition | 07:06 |
| zyga | Oh yeah! | 07:07 |
| jamesh | Jump right to the errors in the log | 07:07 |
| zyga | Indeed | 07:07 |
| === mborzeck1 is now known as mborzecki | ||
| zyga | I need to make spread and action anyway | 07:07 |
| mborzecki | zyga: so your basement data center is up and operational now? :) | 07:08 |
| zyga | To handle post | 07:08 |
| zyga | mborzecki: not required | 07:09 |
| jamesh | 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 |
| mborzecki | 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:09 |
| jamesh | (if the full file name isn't in the log message, then it's not there to extract via a regexp) | 07:10 |
| zyga | Yeah we can do that | 07:10 |
| mborzecki | zyga: heh ok i see why you're doing this in #8363 | 07:14 |
| mup | PR #8363: github: combine tests into one workflow <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8363> | 07:14 |
| mborzecki | 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:16 |
| zyga | re | 07:18 |
| zyga | mborzecki: that's already done | 07:19 |
| zyga | mborzecki: restarting single jobs is coming in next actions release IIRC | 07:19 |
| zyga | mborzecki: so we can just wait | 07:19 |
| zyga | mvo: good morning | 07:19 |
| zyga | I love how our PRs that move workload from travis to github actions are blocked by travis | 07:19 |
| mvo | zyga: good morning | 07:20 |
| zyga | mvo: could you please look at 8362, 8364 and 8364 | 07:20 |
| zyga | mvo: I think you will find there's a logical progression towards the result there | 07:20 |
| zyga | mvo: this doesn't change the status quo yet, I'll make one shortly that does | 07:21 |
| mvo | zyga: checkin | 07:21 |
| zyga | mvo: switching off travis entirely in the process | 07:21 |
| mvo | g | 07:21 |
| zyga | thank you very much sir :) | 07:21 |
| mup | PR snapd#8362 closed: github: fix order of go get caches <Simple 😃> <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8362> | 07:26 |
| * zyga politely asks for reviews of a +3,-2 PR: https://github.com/snapcore/snapd/pull/8089 | 07:27 | |
| mup | PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089> | 07:27 |
| mup | PR snapd#8363 closed: github: combine tests into one workflow <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8363> | 07:27 |
| zyga | mvo: jamesh gave me an idea, we could use a feature of github actions to spot errors in spread | 07:30 |
| zyga | there's a way to run a scanner over the log | 07:30 |
| zyga | and say "here, there is something interesting here' | 07:30 |
| zyga | and this is the label" | 07:30 |
| zyga | we could extract each error even without looking at the logs ourselves | 07:31 |
| zyga | it requires some javascript to be written though | 07:31 |
| zyga | so not today | 07:31 |
| zyga | but it's totally doable and many actions use this | 07:31 |
| jamesh | zyga: shouldn't require any javascript | 07:31 |
| zyga | jamesh: oh? | 07:31 |
| zyga | IIRC most actions require that | 07:31 |
| zyga | but maybe I missed something | 07:31 |
| zyga | I need to use javascript anyway, to implement post: ... | 07:32 |
| zyga | mvo: please check my comment on -abend | 07:32 |
| jamesh | 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 |
| zyga | jamesh: but that requires a proper action | 07:32 |
| jamesh | zyga: no | 07:32 |
| zyga | or are you saying this is something any run: ... thing can do? | 07:32 |
| zyga | that would be amazing, can you point me to any examples or docs for this? | 07:33 |
| zyga | I didn't know about this | 07:33 |
| jamesh | all the javascript does is print a specially formatted command to stdout | 07:33 |
| jamesh | let me see | 07:33 |
| mvo | 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 |
| jamesh | zyga: problem matcher json example: https://github.com/actions/toolkit/blob/master/docs/problem-matchers.md | 07:33 |
| jamesh | zyga: command to enable problem matcher: https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers | 07:33 |
| zyga | ah | 07:34 |
| zyga | that's super useful | 07:34 |
| zyga | thank oyu | 07:34 |
| zyga | I wonder what's that weird ::foo syntax they have | 07:34 |
| zyga | I've seen it used to set env variables | 07:34 |
| zyga | but I didn't find a reference of what else you can do | 07:34 |
| jamesh | it's the syntax for steps to issue commands to the runner | 07:34 |
| zyga | thank you :) | 07:35 |
| jamesh | there's similar stuff in Travis with different syntax | 07:35 |
| jamesh | (for e.g. reporting timing or folding sections of output) | 07:35 |
| jamesh | The main reason they push JS for reusable actions is because it is portable across linux, macosx, and Windows | 07:38 |
| jamesh | It doesn't actually have any special powers you can't do through a simple shell script "run:" step | 07:39 |
| zyga | mvo: pushed | 07:40 |
| zyga | jamesh: my view on that https://twitter.com/zygoon/status/1243239498101768192 | 07:40 |
| jamesh | zyga: I did "snap install node" | 07:41 |
| zyga | I will try | 07:42 |
| jamesh | actually, "snap install --channel 13/stable node" | 07:42 |
| zyga | I suspect I still need to get the million shitty dependencies from non | 07:42 |
| zyga | Npm | 07:42 |
| jamesh | --classic too, actually | 07:42 |
| jamesh | each project is going to install its own dependencies | 07:42 |
| jamesh | the same as go projects | 07:43 |
| jamesh | this is just the way the world works these days :-) | 07:43 |
| zyga | Except go has a stdlib | 07:43 |
| jamesh | so does node | 07:43 |
| zyga | Maybe go has a better one :-) | 07:43 |
| zyga | I meant almost 300 dependencies | 07:44 |
| zyga | Each one with a small lib | 07:44 |
| jamesh | the node one has some serious warts | 07:44 |
| zyga | Yeah, I think node itself is just one big wart with smaller warts you can add on top :-) | 07:44 |
| zyga | (I don’t like that stack) | 07:44 |
| jamesh | I'm not sure why the .deb version is pulling in so many dependencies | 07:46 |
| jamesh | zyga: I'd recommend taking Github's typescript-action template and work from there | 07:48 |
| jamesh | that'll give you a working npm project with code reformatting and linting built in, plus TypeScript's type annotation checking | 07:49 |
| jamesh | makes things slightly less error prone | 07:49 |
| zyga | Good idea | 07:49 |
| jamesh | That's what I did, and then just pretended it was weird looking Python | 07:50 |
| pstolowski | morning | 08:01 |
| zyga | good morning pawel | 08:04 |
| mborzecki | pstolowski: hey! | 08:06 |
| mup | PR snapd#8367 closed: cmd/snap: the model command needs just a client, no waitMixin <Simple 😃> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8367> | 08:24 |
| mup | PR snapd#8368 opened: github: goodbye travis <Created by zyga> <https://github.com/snapcore/snapd/pull/8368> | 08:37 |
| zyga | mvo: heh | 08:48 |
| zyga | mvo: spread without -v prints preparing, restoring | 08:49 |
| zyga | and executing too | 08:49 |
| * zyga wonder if something is broken | 08:49 | |
| zyga | it's not any more quiet for sure | 08:49 |
| pstolowski | we need --quiet then :/ | 08:51 |
| mborzecki | zyga: hm iirc -v only adds some extra bits about packing the tarball | 08:57 |
| zyga | uh? | 08:57 |
| zyga | weird | 08:57 |
| mvo | pstolowski: is 8270 ready? it's still mark blocked but got a +1 from samuele already? | 08:57 |
| mborzecki | and -vv does the backend query dumps | 08:57 |
| zyga | so we need -q | 08:57 |
| zyga | or something like that | 08:58 |
| pstolowski | 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 | 08:59 |
| pstolowski | mvo: and maybe it won't be needed (i haven't analyzed the list yet) | 09:00 |
| mvo | pstolowski: ok, please remove the blocked label then and I will try to get to it later today (but tons of meetings) | 09:00 |
| pstolowski | mvo: sure, done | 09:01 |
| pstolowski | and thanks\ | 09:01 |
| mvo | ta | 09:02 |
| zyga | our static checks run slower than our unit tests | 09:06 |
| zyga | needs some polish there | 09:06 |
| zyga | mborzecki: check out 8368 | 09:27 |
| zyga | 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:28 |
| mup | PR snapd#8369 opened: boot, overlord/devicestate, daemon: <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8369> | 09:42 |
| mborzecki | mvo: ^^ | 09:42 |
| mborzecki | zyga: some static checks could be written in go linters, but hard to say whether that'd make them faster | 09:42 |
| zyga | mborzecki: no, it's mostly silliness in how we run them | 09:42 |
| zyga | mborzecki: we can make it near-instant | 09:43 |
| zyga | mborzecki: need to decouple from run-checks monster | 09:43 |
| mborzecki | run-monster-checks | 09:43 |
| zyga | mborzecki: but not super priority, I wanted to switch over away from travis | 09:43 |
| zyga | so nobody has to wait | 09:43 |
| zyga | then we can polsh | 09:43 |
| zyga | so people are amazed that we didn't do it earlier | 09:43 |
| zyga | f... travis build failed again | 09:43 |
| zyga | google:debian-9-64:tests/main/interfaces-packagekit-control failed https://www.irccloud.com/pastebin/RJNxNY3y/ | 09:44 |
| zyga | please review https://github.com/snapcore/snapd/pull/8364 :) | 09:45 |
| mup | PR #8364: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364> | 09:45 |
| mborzecki | 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:46 |
| zyga | mborzecki: we need to break down big chunks into separate steps | 09:55 |
| zyga | then we see time | 09:55 |
| zyga | then we optimize | 09:55 |
| zyga | then we win | 09:55 |
| zyga | 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 |
| zyga | also, not running things over and over and over and over and over again like often do | 09:56 |
| zyga | brb, need tissue, my nose is running like crazy (each spring the same story) | 09:57 |
| zyga | sorry :| | 09:57 |
| zyga | re | 10:19 |
| zyga | I'd like to merge https://github.com/snapcore/snapd/pull/8364 | 10:34 |
| mup | PR #8364: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364> | 10:34 |
| zyga | to make my home network more compatible with home learning | 10:34 |
| zyga | mvo: ^ | 10:34 |
| zyga | mborzecki: ^ | 10:34 |
| mvo | zyga: was in a meeting, looking | 10:41 |
| zyga | ta | 10:41 |
| dot-tobias | 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:00 |
| mborzecki | dot-tobias: they are | 11:04 |
| mcphail | Hi. What plugs do I need to declare for access to /dev/uinput and /sys/bus/usb/devices/ ? | 11:06 |
| zyga | mcphail: hello, currently nothing exposes /dev/uinput | 11:13 |
| zyga | mcphail: as for /sys/bus/usb/devices therer are a few depending on what you need (read/write?) | 11:13 |
| zyga | you can use hardware-observe or raw-usb or a few others | 11:13 |
| mcphail | 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 |
| zyga | sc-controller? | 11:14 |
| zyga | mcphail: new interfaces can be added | 11:14 |
| mcphail | app to get steam controllers running on non-steam games. Doesn't work on 20.04 because of no real python2 support | 11:14 |
| zyga | 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 |
| mcphail | Will do. Thanks zyga | 11:15 |
| zyga | brb | 11:55 |
| mup | PR snapd#8364 closed: github: offload self-hosted workers <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8364> | 11:56 |
| zyga | ta! | 11:56 |
| zyga | mvo: I will do more about gh actions over weekend | 11:56 |
| zyga | mvo: but not today | 11:56 |
| zyga | mvo: some preview is in that draft branch that has proper sequencing and no longer uses travis | 11:56 |
| zyga | mvo: but I need to port misc stuff and improve things | 11:56 |
| zyga | mvo: unless you say this is a priority | 11:57 |
| popey | mvo: you're right lzo compressed snaps get held for review. https://paste.ubuntu.com/p/Z7YnNPKd3h/ | 12:16 |
| zyga | re | 12:36 |
| zyga | mborzecki: I want to add a parser for /proc/PID/cgroup | 12:41 |
| zyga | mborzecki: shall the parser to to osutils and the high-level use to sandbox/cgroup? | 12:41 |
| zyga | mborzecki: https://github.com/snapcore/snapd/pull/8369 has a weird title (empty) | 12:42 |
| mup | PR #8369: boot, overlord/devicestate, daemon: <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8369> | 12:42 |
| mborzecki | zyga: hmm sandbox/cgroup feels like a better fit | 12:44 |
| zyga | spread feature I would kill for (not really): preserving history | 12:58 |
| mvo | popey: yeah, the review is expected, should be possible to manually override I hope | 13:27 |
| mvo | zyga: not a priority, we need to make sure we also have the static tetss etc | 13:28 |
| zyga | mvo: I ported static tests over, I need to port CLA check and some misc bits though | 13:28 |
| mvo | zyga: nice | 13:29 |
| * zyga figured out how to handle session-tool reliably, more so than before :) | 13:35 | |
| zyga | ha, and also for root user | 13:35 |
| cmatsuoka | mborzecki: https://github.com/snapcore/snapd/pull/8370 | 14:54 |
| mup | PR #8370: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8370> | 14:54 |
| mup | PR snapd#8370 opened: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8370> | 14:54 |
| mborzecki | cmatsuoka: thanks! | 14:55 |
| cmatsuoka | mborzecki: hopefully this will solve the issue and the crash-before-mkfs scenario as well | 14:56 |
| mvo | zyga: https://bugs.launchpad.net/ubuntu/+source/xchat/+bug/1869332 is what I reported | 15:01 |
| mup | Bug #1869332: Fails to launch correctly with gnome-shell in focal <xchat (Ubuntu):New> <https://launchpad.net/bugs/1869332> | 15:01 |
| mvo | zyga: what bugreport did you see? | 15:01 |
| zyga | mvo: the bug I ran into was different, it was locale dependent | 15:01 |
| zyga | the .mo file contained a translation that segvfaulted | 15:02 |
| zyga | but | 15:02 |
| zyga | the locale was different in the session and in the terminal somehow | 15:02 |
| zyga | in the end I fixed that one, but that was years ago and I stopped using xchat since | 15:02 |
| zyga | oh well | 15:02 |
| mup | PR snapd#8371 opened: overlord/devicestate, daemon: record the seed current system was installed from <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8371> | 15:07 |
| * cachio lunch | 15:55 | |
| mborzecki | cmatsuoka: just before i leave, some good news, the branch seems to work | 15:57 |
| cmatsuoka | \o/ | 15:58 |
| mborzecki | cmatsuoka: i was able to reboot form run to install again, get eveyrthing reinstalled and back to new run ;) | 15:58 |
| cmatsuoka | great! thanks | 15:58 |
| mborzecki | cmatsuoka: thanks for the patch! | 15:59 |
| mborzecki | and time to EOD | 15:59 |
| cmatsuoka | lunch time for me, bbl | 15:59 |
| * zyga tries to get stuff finished | 16:13 | |
| zyga | no weekend yet :) | 16:13 |
| ijohnson | zyga: could you quick re-review #8365 ? it would be great to get that in today | 16:21 |
| mup | PR #8365: seed: add Info() method for seed.Snap <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8365> | 16:21 |
| zyga | sure | 16:21 |
| ijohnson | thanks! | 16:21 |
| zyga | +1 | 16:22 |
| zyga | but red on travis :/ | 16:22 |
| ijohnson | yeah needs some travis wrangling | 16:22 |
| zyga | mvo: one more suprpsing advantage of github actions - virtually no time limit | 16:23 |
| zyga | mvo: jobs can run up to 72 hours IIRC | 16:23 |
| ijohnson | wow that's both awesome and a bit scary | 16:24 |
| mvo | zyga: woah | 16:31 |
| zyga | mvo: ? :-) | 16:32 |
| zyga | ah | 16:32 |
| zyga | ;D | 16:32 |
| zyga | yeah | 16:32 |
| zyga | it was a surprise to me :) | 16:32 |
| zyga | no more 50 minute death | 16:32 |
| === genii_ is now known as genii | ||
| mvo | zyga: yeah, very cool | 16:36 |
| zyga | mvo: have we switched to the key for c20? | 17:45 |
| zyga | cmatsuoka: do you know if systemd reads any configuration from EFI? | 17:45 |
| zyga | stracing a random busctl tool revealed | 17:45 |
| zyga | openat(AT_FDCWD, "/sys/firmware/efi/efivars/SystemdOptions-8cf2644b-4b0b-428f-9387-6d876050dc67", O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT ( | 17:45 |
| zyga | it would be unfortunate if our secure boot + encryption scheme was foiled by a debug=1 in EFI var somewhere | 17:45 |
| cmatsuoka | zyga: mm interesting | 17:45 |
| zyga | cmatsuoka: do we measure EFI? | 17:45 |
| zyga | xnox: ^ FYI | 17:46 |
| zyga | anyway, now you know | 17:47 |
| * zyga is back to digging | 17:47 | |
| cmatsuoka | it's measured, I believe | 17:47 |
| xnox | zyga: why are you pinging me? | 17:47 |
| zyga | xnox: sorry, you are someone who I associate with systemd knowledge | 17:48 |
| xnox | zyga: but what is your ping? it has no context, and no questions =) | 17:48 |
| zyga | ah, sorry | 17:48 |
| xnox | zyga: just because i idle in the channel, i don't actually read it =) | 17:48 |
| zyga | xnox: the question is this, is there any EFI variable that could, unmeasured, defeat the encryption in core 20 | 17:49 |
| xnox | i just camp out for pings | 17:49 |
| zyga | e.g. something that could give you systemd debug shell | 17:49 |
| xnox | zyga: nothing to do with me, is it? | 17:49 |
| zyga | or similar | 17:49 |
| xnox | debug-shell.service will not start, if measurements are bad | 17:49 |
| zyga | that's reassuring | 17:50 |
| ijohnson | xnox: also didn't you just disable debug-shell entirely unless dangerous is on the cmdline ? | 17:50 |
| zyga | thanks, I just bumped into this in a strace | 17:50 |
| zyga | and was surprised | 17:50 |
| xnox | EFI firmware is measured, but currently is not part of the sealing policy => ask security about that | 17:50 |
| xnox | (i.e. we don't seal to it) | 17:50 |
| xnox | ijohnson: yes | 17:50 |
| ijohnson | right | 17:50 |
| xnox | and we do seal keys to the cmdline measurement | 17:50 |
| zyga | right, I remember cmdline | 17:50 |
| zyga | I was worried that EFI is a hidden 'cmdline' that's not measured somehow | 17:51 |
| zyga | (EFI == EFI variables) | 17:51 |
| mvo | zyga: I'm not sure what c20 is? uc20? and what key? | 17:52 |
| zyga | core 20 | 17:53 |
| zyga | mvo: the signing key for the kernel | 17:53 |
| mvo | zyga: aha, not yet | 17:53 |
| mvo | zyga: do you know what broken seed pawel was using? | 17:53 |
| zyga | yes I do | 17:53 |
| mvo | zyga: for bug https://bugs.launchpad.net/snapd/+bug/1868706 | 17:53 |
| mup | Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706> | 17:53 |
| zyga | mine :) | 17:53 |
| mvo | zyga: nice, can you mail/make this available? | 17:53 |
| mvo | zyga: trying to write a regression test right now | 17:53 |
| zyga | can I TG it? | 17:53 |
| mvo | sure | 17:54 |
| zyga | it's 350MB tarball | 17:54 |
| mvo | whatever works for you | 17:54 |
| zyga | and it's already on telegeram | 17:54 |
| mvo | *cough* | 17:54 |
| zyga | done | 17:54 |
| zyga | check your TG please | 17:54 |
| mvo | zyga: and I just unpack it over the existing /var/lib/snapd/seed ? | 17:54 |
| zyga | enjoy :) | 17:54 |
| zyga | I think so | 17:54 |
| zyga | stop snapd | 17:54 |
| zyga | stash your seed | 17:54 |
| zyga | unpack this | 17:55 |
| zyga | and marvel at the bugs | 17:55 |
| mvo | zyga: nice | 17:55 |
| mvo | zyga: if you have a system in that state, what do you see in snap changes? | 17:55 |
| zyga | (I would not overwrite your current seed) | 17:55 |
| zyga | no, I don't | 17:55 |
| mvo | zyga: do you actually see a failed seeding change? | 17:55 |
| zyga | I fixed it long ago :/ | 17:55 |
| mvo | zyga: ok, no worries | 17:55 |
| zyga | you see an endless list of seeding things | 17:55 |
| zyga | I forgot, pawel fixed that | 17:55 |
| zyga | but the broken seed was still, at the time, not allowing snapd do do anything else | 17:55 |
| zyga | is there a shell set option that would quote strings? | 17:56 |
| zyga | like set -x | 17:56 |
| zyga | echo " surprise " | 17:56 |
| zyga | and see " surprise " back? | 17:56 |
| mvo | zyga: hrm, I can't break the right way in my tests it's very annoying | 18:07 |
| zyga | did you break it at all? | 18:07 |
| zyga | as in did it get to a snapd that's not seeded? | 18:07 |
| zyga | remember you need to move your state aside too | 18:07 |
| mvo | zyga: working with your state in a vm right now | 18:07 |
| mvo | zyga: but what I mean is that I struggle right now with a spread test that breaks it | 18:08 |
| mvo | zyga: I can break it but then the change is never in error state, it's very annoying | 18:08 |
| zyga | just to be clear: you are trying to reproduce this as a spread test? | 18:08 |
| zyga | if it helps you in any way | 18:09 |
| mvo | zyga: yes | 18:09 |
| zyga | I just discovered a whole new layer of quoting in shell I never knew about | 18:09 |
| mvo | zyga: without the need for a 350mb tarfile ideally :) | 18:09 |
| zyga | sure | 18:09 |
| zyga | do you know why the seed in that tarball is broken? | 18:09 |
| mvo | zyga: not yet | 18:10 |
| zyga | I could remember wrong | 18:10 |
| zyga | but IIRC it was either wrong order | 18:11 |
| zyga | or missing base | 18:11 |
| zyga | or something like that | 18:11 |
| zyga | what happens when you seed with it? | 18:11 |
| zyga | what does snapd say? | 18:11 |
| zyga | and if I get hit by a bus | 18:11 |
| zyga | foo=" surprise " | 18:11 |
| zyga | echo "${foo@Q}" | 18:11 |
| zyga | (insert appropriate emoji) | 18:11 |
| ijohnson | cmatsuoka: so we are entirely blocked on the latest uc20 changes | 18:28 |
| ijohnson | none of the uc20 spread tests can pass on travis | 18:28 |
| ijohnson | I'm not sure which snap changed recently, but we need to revert something because master will be entirely red until it's fixed | 18:29 |
| ijohnson | cc mvo if you're still around | 18:30 |
| cmatsuoka | ouch | 18:30 |
| mvo | ijohnson: hi | 18:31 |
| ijohnson | hey | 18:31 |
| mvo | ijohnson: uh, that's sad | 18:31 |
| mvo | ijohnson: so all uc20 tests are failing right now? | 18:32 |
| ijohnson | I'm looking into it now, and xnox said he's working on it | 18:32 |
| mvo | ijohnson: thank you so much | 18:32 |
| ijohnson | mvo: yes all uc20 tests fail because we can't get out of the initrd | 18:32 |
| ijohnson | so basically the kernel snap is to blame here I guess | 18:32 |
| mvo | ijohnson: so the rebuild of the kernel broke things? so our initrmafs-mounts may have changed in a way that broke it? | 18:33 |
| ijohnson | mvo: we don't even get to the point where snap-bootstrap runs | 18:33 |
| mvo | ijohnson: uh, woah | 18:33 |
| ijohnson | mvo: xnox said that there's another kernel cmdline or something that needs to be added due to a newer systemd ? | 18:33 |
| mvo | ijohnson: keep me updated, I have dinner and check back | 18:33 |
| ijohnson | I'm looking into building with an older ubuntu-core-initramfs instead of what's currently there | 18:34 |
| ijohnson | okay so the version of ubuntu-core-initramfs that went into pc-kernel 431 is fine, the problem is when we re-pack the initrd we use the ubuntu-core-initramfs from the archive, which is newer and has the problem | 18:36 |
| cmatsuoka | ijohnson: did you see this happening on a local boot? | 18:36 |
| ijohnson | cmatsuoka: yes I can reproduce | 18:36 |
| ijohnson | if you do like the repack-kernel script from maciej does and use the skeleton of the initramfs from the ubuntu-core-initramfs package that exists right now, you will be broken | 18:37 |
| cmatsuoka | mm, so we can use an older version when we repack and we don't need to wait for a fix? | 18:37 |
| ijohnson | I am going to try and look into a way to fully extract the skeleton from the kernel snap instead of the using the one from the distro package | 18:37 |
| ijohnson | yes an older version of ubuntu-core-initramfs package is what we need to boot with | 18:38 |
| cmatsuoka | ok thanks ian | 18:38 |
| cmatsuoka | do you need any help/assistance there? | 18:38 |
| ijohnson | I'm good for now I think, but thanks for the offer | 18:39 |
| * ijohnson also needs to get lunch soon | 18:39 | |
| mup | PR snapcraft#2996 opened: requirements: uprev mypy to 0.770 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2996> | 18:41 |
| mup | Bug #1867090 opened: IBus 1.5.21 Chinese input in Ubuntu 19.10 not working with Atom 1.45.0 as snap <chinese> <Snappy:New> <ibus (Ubuntu):Confirmed> <https://launchpad.net/bugs/1867090> | 18:51 |
| mup | Bug #1867090 changed: IBus 1.5.21 Chinese input in Ubuntu 19.10 not working with Atom 1.45.0 as snap <chinese> <ibus (Ubuntu):Confirmed> <https://launchpad.net/bugs/1867090> | 18:54 |
| * zyga EOWs | 19:24 | |
| xnox | ijohnson: why are you using a different ubuntu-core-initramfs when repacking? | 19:30 |
| xnox | (during spread tests) | 19:31 |
| ijohnson | xnox: we use the one from the distro package | 19:31 |
| ijohnson | I am testing using the one from the kernel snap instead | 19:31 |
| xnox | ijohnson: again, why? | 19:31 |
| ijohnson | tbh I don't know why we use the distro skeleton instead of the initrd from the kernel snap, mborzecki would know the details as he last touched that code | 19:31 |
| ijohnson | but he already EOD'd | 19:32 |
| xnox | ijohnson: back when we talked about repacking kernel.snap, we did talk about unpacknig kernel.efi, unpacking initrd, upacking initrd, updating anyting one wants to update, and reusing that as the skeleton dir again. | 19:32 |
| xnox | ijohnson: cause otherwise, one is not introducing "just the new snap-bootstrap" one upgrades all the other things too. | 19:33 |
| xnox | ijohnson: plus i only have the one PPA at the moment, so I don't have anywhere else to upload ubuntu-core-initramfs as edge and then promote somewhere else as beta | 19:33 |
| ijohnson | xnox yes if the run I have right now works with just replacing snap-bootstrap we will do that | 19:42 |
| mup | PR snapd#8372 opened: devicestate: generate warning if seeding fails <Created by mvo5> <https://github.com/snapcore/snapd/pull/8372> | 19:45 |
| === probono2 is now known as probono | ||
| xnox | ijohnson: awesome! because that is closer in spirit what you want to do longer term too. | 19:47 |
| mup | PR snapd#8373 opened: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <⚠ Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8373> | 21:06 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!