[00:02] PR snapcraft#3375 closed: [wip] ci: migrate spread tests to github actions [03:29] huh i wonder what is breaking here https://launchpad.net/~mwhudson/+snap/go115/+build/1203801 [03:29] i guess i should look at the diff to the previous version ... but not today [06:11] PR snapd#9747 closed: interfaces/builtin/log_observe.go: allow controlling apparmor audit levels [06:56] morning [07:16] PR snapd#9746 closed: bootloader: add check for prepare-image time and more tests validating options [08:01] morning [08:58] looked at the layout docs again, we do not prohibit using $SNAP as a target right? [09:22] PR snapd#9736 closed: o/devicestate: save model with serial in the device save db

[09:27] PR snapd#9742 closed: gadget,o/devicestate: hybrid 18->20 ready volume setups should be valid [09:45] pedronis: hey, i've introduced naming.SnapRef and SnapSet in #9732, turned out nicely i think, also local snaps are now handled [09:45] PR #9732: asserts: snapasserts method to validate installed snaps against validation sets === pedronis_ is now known as pedronis [09:52] pstolowski: thx, not sure I can look at it today but Monday [09:52] pstolowski: about #9429, does it need a master merge and then it's ready to review or is there more to that? [09:52] PR #9429: [RFC] o/daemon: validation sets api and basic spread test [09:54] pedronis: yes needs master merge and maybe update of error messages after previous PR, will do shortly [11:17] PR snapd#9748 opened: gadget: start separating rule/convention validation from basic soundness [11:18] mvo: mborzecki: baby steps ^ [11:18] pedronis: thanks [11:22] PR snapd#9590 closed: tests: download timeout spread test [11:45] pedronis: i've updated #9429 [11:45] PR #9429: o/daemon: validation sets api and basic spread test [12:05] pstolowski: thx, I put it into my queue [12:29] mvo: I reviewed the fde PRs, some questions there [12:30] pedronis: thank you! [12:58] PR snapd#9749 opened: tests: fix lp-1899664 test when snapd_x1 is not installed in the system [13:25] ijohnson: hey [13:27] morning mborzecki! [13:35] Hey hey [13:36] Quickie, probably for mborzecki [13:36] We never went past after/stop [13:37] Erm, sorry.. I mean, we never went past after/before.. the original design had the idea of starts-with [13:38] I suppose we never needed that because the snap generally starts everything [13:38] Has our understanding of the problem changed since then? [13:38] PR snapd#9750 opened: tests: fix the scenario when the "$SRC".orig file does not exist [13:39] niemeyer: we didn't, iirc there was no agreement about keywords and the discussion got derailed with cross snap dependencies at some point [13:41] niemeyer: if it's just about start-with within a single snap it should be easy enough to do ;) [13:43] Yeah, I'm mainly wondering if anything has changed, as I'm about to replicate the design on something where different startup settings will be more common, so this will come at play quickly [13:43] So just checking if we've learned anything since the discussed this, and whether we still have the same design, meaning after/before do not imply start/stop-with [13:44] Ideally we can use the exact same design, so people learning about one mechanism already know the other [13:53] PR snapd#9751 opened: cmd/snap-update-ns: fix sorting of overname mount entries wrt other entries [14:48] PR snapd#9743 closed: daemon: split unsupported buy implementation to its own api_*.go files [15:01] mborzecki interesting bug [15:26] pedronis, mborzecki: I wonder if there's a reason for it to be "starts-with" vs. "start-with" [15:28] Yeah, I think "start-with" is actually more natural... there are several "start-" and "restart-" prefixes [15:30] they have a bit of a different role [15:30] there start/restart are nouns [15:32] here start would be a verb [15:32] start-with and starts-with have a bit of different connotation, the first is command/order, the second more declarative [15:36] for this kind of settings systemd itself prefers the indicative over the imperative: BindsTo JoinsNamespaceOf [15:37] Indeed, but I wonder if consistency would win [15:37] Let me look again at the docs [15:37] I think consistency would be easier for non-native speakers, but conceptually is a bit off [15:38] for this [15:38] Seems analogous to start-timeout [15:39] Again, I get that in terms of grammar it's slightly different, but I'm not sure people would understand that rather than just finding it inconsistent [15:40] Is there a better term to use instead of -with that would make it a more natural noun [15:43] to have a name, you would need some like start-companions or something, it gets odd I think [15:45] PR snapcraft#3375 opened: ci: migrate spread tests to github actions [15:47] pedronis: start-friends [15:47] :P [15:48] start-buddy [15:49] pedronis: "start-group" is not too bad [15:49] * cachio lunch [15:49] that could work [15:50] and the semantics seems right.. it's really a group. The statement binds them bilaterally [16:15] pedronis: ok, I addressed your comments on #9695 [16:15] PR #9695: bootloader/lk: add support for UC20 lk bootloader with V2 lkenv structs === JanC is now known as Guest22061 === JanC_ is now known as JanC [16:53] Hey folks, got a question about snap and apparmor profiles. I'm getting some apparmor denials in my logs from the spotify snap, which would be fixed by adding some extra allows (or silent denies) in /var/lib/snapd/apparmor/profiles/snap.spotify.spotify. Now my question is: Where does the content of that file come from? Is that shipped as part of the snap? Or is it generated by snapd based on snap metadata? [16:53] blathijs: it's generated by snapd based on snap metadata [16:53] (and the underlying question is: Where should I be asking to get this fixed, in snap or in spotify?) [16:54] blathijs: I would recommend starting a forum topic at forum.snapcraft.io, it's unclear whether it's something that the snap author (i.e. spotify) needs to adjust or whether it's something that snapd would need to adjust, but it's easier to gather such details in a more persistent setting [16:56] ijohnson: Will do, thanks for the quick reply :-) [16:57] pedronis: also regarding the degraded mode pr that failed, from the log in install mode there is this bit: https://pastebin.ubuntu.com/p/RNqY5vDPBT/ [16:57] so the degraded mode itself wasn't flaky, it was the installation that was flaky [16:57] unfortunately without an active shell I can't tell what went wrong to cause "device /dev/vda4 not available" [17:05] PR snapcraft#3390 opened: project_loader, meta, formatting_utils: account for empty env [17:32] ijohnson: Created a post, thanks again: https://forum.snapcraft.io/t/apparmor-related-denials-for-spotify-snap/21479 [17:32] np [17:54] ijohnson: zyga: thanks for reviews, i've updated https://github.com/snapcore/snapd/pull/9751 [17:54] PR #9751: cmd/snap-update-ns: fix sorting of overname mount entries wrt other entries [17:55] Nice thanks mborzecki ! [17:55] * ijohnson lunches [19:00] ijohnson hi [19:00] ijohnson should I apply s/!/not / suggestions I've made to https://github.com/snapcore/snapd/pull/9751 [19:00] PR #9751: cmd/snap-update-ns: fix sorting of overname mount entries wrt other entries [19:06] re, I must say this agresive suspend is annoying [19:07] hey zyga [19:07] hey :) [19:07] do you have perms to apply the suggestions ? [19:07] yeah [19:07] if so I'd say go for it [19:08] cool, doing that now [19:08] if you end up backdooring snapd with your spread test changes though I will be very sad [19:08] should have used the batch thing but its' done [19:08] not that you couldn't have added backdoors to snapd through any of the other super low level code you worked on throughout the years :-) [19:08] I would ! do that :) [19:08] :-D [19:09] I have a secret plan [19:09] to develop changes to spread that you end up using :) [19:09] I have some yocto builds to set up first, [19:09] haha nice [19:09] and muxpi and flashing [19:09] all the usual suspects [19:10] I want to teach spread to run drive metal directly, though some API that matches muxpi and several other things [19:10] poor you [19:10] hehe [19:10] (yocto) [19:10] yeah, it's a different planet [19:10] but I'm not touching yocto myself; I'm the CI guy [19:10] that bit is fun, I've learned a lot in just one month already [19:10] interesting, did you ever play with testflinger ? [19:11] seems similar in purpose [19:11] ijohnson somewhat, I watched its development from the side [19:11] though I guess testflinger integration with spread is more like, spread sends bits to some server, then the server does the metal bits and returns some IP address [19:11] it sounds like you would be eliminating that middle server bit [19:11] yeah, I want spread metal: [19:11] ijohnson actually [19:11] let me show you [19:12] tests: use not instead of ! [19:12] er [19:12] bad paste [19:12] https://git.ostc-eu.org/docs/ci [19:12] it's WIP, there are issues and there are PRs that change bits [19:12] but you can find the general idea here https://git.ostc-eu.org/docs/ci#test-process [19:13] * ijohnson reads the README and sees mention of kubernetes [19:13] * ijohnson squints [19:13] ijohnson gitlab does k8s [19:13] it's super cool actually [19:13] remember how we have github workers [19:13] yep [19:13] gitlab has runners, different name, but also different model [19:13] you set up a runner [19:13] and configure a runner executor [19:14] there's a dozen of those [19:14] from virtualization stuff like qemu or virtualbox [19:14] to dockers [19:14] to k8s [19:14] including auto-scaling [19:14] to simple shell and custom [19:14] you can have one runner that spawns new containers in an auto-scaling k8s cluster [19:14] it's veeeeery nice [19:14] and extremely fast [19:14] PR snapd#9752 opened: gadget,o/devicestate: set implicit values for schema and role directly instead of relying on Effective* accessors [19:15] so you can have really high throughput quickly [19:15] and since for most of the tests you don't need a VM this is really faster [19:15] s/tests/tasks/ [19:15] that does sound nice [19:15] e.g. building [19:15] gitlab has some nice bits [19:15] I was surprised by how small this difference is and how big impact it makes [19:16] so anyway, I want to extend spread, perhaps so that I can make spread a gitlab executor [19:16] gitlab runner is written in go [19:16] so ... that's really close :) [19:16] so that I can have pipelines that run on metal [19:16] (pipelines are like actions, somewhat) [19:16] and that the metal deployment can use an OS image build by an earlier pipeline [19:17] I need an API because one worker will "see" many devices [19:17] that does sound really cool, I oftentimes have had this desire to hook up some extra machines I have to maas to do a similar kind of thing [19:17] so that in the end one test can be really spread across several devices [19:17] but really to do spread tests directly that way would be nice [19:18] would cut out the middle man again, this time a different middle man [19:18] I need to think about the API, should be both simple and match spread [19:18] it will probably be some local or network IPC because I want those jobs to come in and run in the sandbox provided by gitlab [19:19] so probably like a very simple cloud api: allocate, deploy, connect, etc [19:19] I'm not there yet [19:19] PR snapd#9753 opened: daemon: split aliases support to its own api_*.go files [19:19] so small bits of spread, packaging, and I can share the design as it's fully public :) [19:20] maybe some of that can help you [19:21] yeah if you have spread pr's I'd be interested to see [19:22] ijohnson I'll start with a for but I will upstream them (that's even in the spec already) when I think they are good and we have something to show [19:22] ijohnson: given I work on muxpi I think those may really apply [19:22] there are also some bits that are not described here but may apply to even wider audience [19:23] where a pi can drive simpler boards without any other help [19:23] ijohnson: I need to write some flashing tools as well [19:23] ijohnson: I'm very keen to get boot-from-usb to work [19:23] ijohnson: did you know raspberry pi can power down USB ports? [19:23] you can boot many devices by powering them from usb and talking to the on-chip bootloader [19:24] ijohnson: feed a 2nd stage bootloader and you are good, no need for muxpi if you have network [19:24] (you can fetch stuff from uboot, for example) [19:24] and write to SD directly [19:24] even if you only fetch and boot a small kernel [19:24] right [19:25] then you can eventually get to the right stage where your card is ready and you just ... power cycle [19:25] all over usb [19:25] you should talk to ondra, he has all sorts of flashing tools [19:25] ondra ^^ hey [19:25] ondra I'm working with someone who used to work with _you_ as a customer btw [19:25] he's at H now [19:25] from e.on IIRC [19:26] weird small world [19:29] PR snapd#9754 opened: o/devicestate: save model with serial in the device save db (2.48) [19:42] ijohnson: I re-reviewed the lk PR [19:44] thanks pedronis [19:44] * ijohnson looks [19:46] pedronis: do you want me to address that point in the pr or can it be a follow up ? [19:47] I guess I would prefer a followup since it's green except for debian with dbus problems [19:48] ijohnson: a follow up is ok [19:48] great, do you want to squash merge it for me then? [19:50] PR snapd#9753 closed: daemon: split aliases support to its own api_*.go files [19:51] ijohnson: #9705 needs your review btw [19:51] PR #9705: devicestate: add runFDESetupHook() helper [19:51] yes I'm working on that today [19:51] almost done with it [19:55] PR snapd#9695 closed: bootloader/lk: add support for UC20 lk bootloader with V2 lkenv structs [19:55] * cachio afk [20:05] PR snapd#9755 opened: daemon: split aliases support to its own api_*.go files [20:10] ijohnson: do you need anything else from me? [20:11] pedronis no I'm good but nezt week we should talk about the devmode snaps stuff [20:11] Have a good weekend pedronis [20:11] yes about devmode. thanks, same to you [20:21] PR snapcraft#3375 closed: ci: migrate spread tests to github actions [21:05] PR snapd#9756 opened: bootloader/{lk,lkenv}: followups from #9695