[05:10] I'm almost done snapping up qbittorrent but I'm running into an issue where it's showing no network connection. I fed it a torrent via a url and it fetched that fine. It's on strict confinement and I've attached network, network-bind, and network-manager and connected the last one. [05:11] Fetched the torrent metadata* it hasn't been able to start downloading it [06:23] arnatious: this is insufficient information to debug, do you see any confinement denials in you log files? [06:48] morning [06:57] out for a bit to do groceries, before there's more people arriving at the store [07:04] mborzecki: o/ [07:10] mvo: good morning :) [07:11] zyga: good morning [07:12] how are you feeling today? [07:13] zyga: good, thanks [07:13] zyga: you? [07:13] yeah, I'm trying to sleep more recently [07:13] I think it works [07:14] zyga: totally agreed, the right sleep is important :) [07:14] zyga: what's new? how are the gh actions doing? [07:14] I'm looking at https://github.com/snapcore/snapd/pull/8350 [07:14] PR #8350: github: cache Debian dependencies for unit tests [07:15] mvo: not much new yet, I would like to work on feature stuff today [07:15] mvo: and squeeze one more github action that runs C unit tests and various misc chcecks [07:15] mvo: and combine the actions into dependency chains, so that we don't spin up spread for sure-failing PRs [07:16] mvo: I was also wondering if we could move one of the non-failing spread runs over, something that would help others with quick feedback [07:16] core20? [07:16] or something like that [07:17] mvo: apart from that I need to just focus on stuff I have pending [07:17] zyga: yeah, I think dep-chain is super welcome [07:18] I noticed that each .yaml file is a separate workflow [07:18] and you can only have dependency chains within one [07:19] hm, slightly sad [07:19] why? [07:19] it's okay, just splice yaml together [07:20] speaking about load, I was wondering if having a master commit action useful [07:20] we test each PR [07:20] then it lands and gets tested again [07:20] probably not useful [07:20] I would much rather have this on the release branches [07:20] where it is more prudent to be careful [07:21] zyga: yeah, the master merge test is mostly wasteful [07:24] PR snapd#8337 closed: cmd/snap-bootstrap/initramfs-mounts/tests: use dirs.RunMnt over s.runMnt [07:25] mvo: https://github.com/snapcore/snapd/pull/8354 quick one to start the day then [07:25] PR #8354: github: run spread tests on PRs only [07:26] PR snapd#8354 opened: github: run spread tests on PRs only [07:28] PR snapd#8339 closed: dirs: rm RunMnt; boot: add vars for early boot env layout; sysconfig: take targetdir arg [07:33] PR snapd#8344 closed: overlord/devicestate,boot: do not hold to the originally read modeenv [07:34] PR snapd#8349 closed: tests: cleanup security-private-tmp properly [07:40] PR snapd#8353 closed: interfaces/docker-support: make containerd abstract socket more generic [07:41] zyga: hm, I just noticed something like "skip-spread" would be nice in the actions :) [07:41] yeah [07:41] but it couldn't have been in the initial run which also set skip :) [07:41] you can read labels [07:41] PR snapd#8355 opened: github: run C unit tests [07:41] let me just check the syntax on how to skip jobs that have a label [07:41] it's nice that this doesn't have the API bottleneck problem [07:41] we can just check whatever property we need to [07:44] yeah [07:58] PR snapd#8354 closed: github: run spread tests on PRs only [07:59] thanks :) [08:01] mvo: I replied on https://github.com/snapcore/snapd/pull/8350 [08:01] PR #8350: github: cache Debian dependencies for unit tests [08:09] PR snapd#8356 opened: cmd/snap: Implement a "snap routine file-access" command [08:13] jamesh: ^ reviewed [08:13] jamesh: if you rebase on master there will be less failing tests [08:17] zyga: thanks. I think it already is instance aware though [08:17] ah, snap.Name has both parts? [08:18] yeah. see cmd/snapinfo.go [08:21] re [08:21] turns out there was more people than i anticipated [08:31] morning [08:35] pstolowski: hey [08:37] zyga: when you restart the spread workflow in gh action, does it restart all jobs or just one? [08:37] zyga: i mean all jobs of that workflow (if it's a matrix) [08:39] damn, my trackball buttons are malfunctioning [08:40] zyga: btw failure in spread test that checks file group ownership https://paste.ubuntu.com/p/Y5RrfjxhY6/ [08:44] mvo has fixed that one [08:44] Currently everything is restarted. Restarting fine grained bits is on the roadmap [08:44] aah [08:45] uh, that's bit of a downer [08:45] what if we use separate workflows for each system instead of matrix? [08:45] Same [08:45] All fine grained bits are coming [08:45] Although [08:46] You may be right with separate workflows [08:46] But then no dependencies [08:51] hmm bummer [08:51] thn maybe we should wait a bit before doing a complete switch [08:51] trading some for some :) [08:51] if spread is one big fat target we could restart that [08:57] hi everyone [08:57] so, wrt https://bugs.launchpad.net/snapd/+bug/1868706 i've tested with lxd & microk8s snaps installed and snapd deb upgraded without issues (along with lots of other debs as i was again testing with a slightly outdated focal). also, Mark wrote that there were no snaps installed [08:57] Bug #1868706: Snapd postinst script hangs [09:02] so perhaps it's something with one of snapd's own services [09:03] interesting [09:23] re [09:23] okay let's get to coding [09:24] mvo: can I convince you to +1 https://github.com/snapcore/snapd/pull/8350 ? [09:24] PR #8350: github: cache Debian dependencies for unit tests [09:24] it saves a little bit of time [09:24] and will be more prominent with the next cache PR where go unit tests runtime will shrink [09:24] (so go tests << 1 minute) [09:27] uh, I need to pick up a delivery [09:27] AFK for 15 [09:27] wrt 1868706 just tested without any snaps (snap-mgmt purge, and removed all seeds), the upgrade worked as well [09:50] back now [09:50] pstolowski: I saw a police patrol checking why people are outdoors [09:50] that's a new for me! [09:51] zyga: right, they announced it yesterday [09:52] too bad they are ignoring the hobos hanging around benches :P [10:00] PR snapd#8355 closed: github: run C unit tests [10:05] mborzecki: do you think 8342 needs a samuele review? it looks pretty good from my pov [10:05] PR snapd#8309 closed: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) [10:06] mvo: we can always tweak the naming later, but the endpoint and data POSTed there was discussed and agreed on, so i think it's fine to land it with another review [10:06] pstolowski: maybe you could take a look at #8342 as well? [10:06] PR #8342: client, daemon, overlord/devicestate: request system action API and stubs [10:06] mborzecki: +1 [10:07] mborzecki: sure [10:07] pstolowski: thanks! [10:14] mvo: I've changed how we cache .deb files, seems to be passing; [10:14] mvo: I'll send one more patch that runs spread after unit tests [10:14] mvo: and that's all from me on gh actions today [10:20] zyga: ok [10:21] * zyga pushes to see if it uses the cache [10:21] PR snapd#8335 closed: many: introduce naming.WellKnownSnapID [10:22] mvo: quick ping about zyga's https://github.com/snapcore/snapd/pull/8089#issuecomment-599914100 from affected snap developer :) [10:22] PR #8089: features: enable robust mount ns updates [10:22] dot-tobias: what about it? [10:24] dot-tobias: it needs to be reviewed and merged [10:31] PR snapd#8277 closed: asserts,o/devicestate: support model specified alternative serial-authority [10:33] pstolowski: ping [10:33] zyga: pong [10:33] pstolowski: should I push a tiny branch with this change: https://github.com/snapcore/snapd/pull/8352/files#diff-08088787360fb3ca74a0aed4c6103b22R264 [10:33] PR #8352: wrappers: generate service files with EnsureDirState [WIP] [10:33] the part after, and including && [10:36] zyga: yeah, jsut had to restart the spread run on opensuse-15 and all spread jobs in gh action got restarted :( [10:36] zyga: ah, this is the err cleanup bug you pinged me about some time ago? yes, it's fine, thank you! [10:36] mborzecki: right [10:36] pstolowski: k, doing so [10:36] zyga: it escaped me [10:37] zyga: so the question now is, can we still merge the PRs when one of the unstable systems fails? [10:37] zyga: Yes, maybe I should've been more elaborate: Just wanted to ask if that's on the plate for 2.44, as I'm getting quite a few requests from wpe-webkit-mir-kiosk users after the last snap revision release. Most of them struggle with the required console commands to discard the namespace and refresh again, but at least I could tell them that this won't be an issue after snapd 2.44. Sorry if I came across bugging! I know that things slip under the [10:37] mborzecki: note that those are not mandatory [10:37] radar quickly, and thought like with 7655 a friendly ping might help 😊 [10:38] mborzecki: you can totally ignore it [10:38] ah ok [10:38] dot-tobias: I don't know, it's a question to mvo [10:38] dot-tobias: maybe? [10:38] mborzecki: there's a way to set passing/failing status and other thing via actions but I didn't go that deep yet [10:38] mborzecki: so we could have a run matrix that chooses what must pass [10:38] mborzecki: or what cannot fail [10:39] mborzecki: but instead of having YAML for it there's just the API you can reach [10:39] zyga: That's who the ping msg was intended for, should've left out your handle – sorry [10:39] mborzecki: one wondering re your PR, otherwise +1 [10:39] dot-tobias: no worries, I hope you can get it in [10:40] pstolowski: https://github.com/snapcore/snapd/pull/8357 [10:40] PR #8357: wrappers: respect pre-seeding in error path [10:40] mvo: ^ for 2.44 [10:40] PR snapd#8357 opened: wrappers: respect pre-seeding in error path [10:45] man, this is so weird [10:45] you push something [10:45] and green tick shows up a moment later [10:45] that's too werid [10:45] can we go back to days of waiting for the red cross? [10:46] zyga: you mean the 1940s? [10:47] mborzecki: is that what travis is? [10:47] zyga: it feels like it at times [10:52] pstolowski: hmm good question about the label, right now we only check whether it's not empty [10:52] mborzecki: a-zA-Z check or some such would do [10:53] pstolowski: we should probably enforce some validity checks, probably [a-zA-Z0-9]+ [10:53] yeah [10:53] zyga, mvo, should i make a minor commit (adding a full stop to the end of the comment or whatnot) to the usbprinter PR so the auto-testing kicks in again ? [10:53] ogra: please do [10:53] ok [10:53] I was unable to restart testing [10:53] ogra: or better [10:53] ogra: merge master [10:53] pstolowski: looked at seed, but there's no checks either [10:55] pstolowski: hm it probably makes most sense to add it in the seed 'seed' packge, in a follow up though [10:56] zyga, bah i hadn't reloaded the page ... seems mborzecki already managed to restart the test anyway [10:56] cool, that's ok [10:56] I need to improve caching today [10:56] ogra: yeah, though i doubt it stated given the usual job queue length [10:56] most of the extra waste is each spread run checking out a git tree [10:57] it seems to be running [10:57] I need to just have a local copy as accelerator [10:57] interesting though that you are the only one being able to trigger them [10:57] ogra: me or maciek? [10:57] maciek [11:11] mvo: fyi, checks for https://github.com/snapcore/snapd/pull/8289 have passed except for OpenSUSE 15.1 -- there it is the unrelated session-tool spread test that failed [11:11] PR #8289: xdgopenproxy: forward requests to the desktop portal [11:16] jamesh: I am close to fixing the session-tool issue [11:16] jamesh: please just ignore that test failure [11:17] jamesh: also, sessions are hard :) [11:17] zyga: I wonder if it would be better to implement this kind of thing in spread itself? [11:18] jamesh: not sure, it's a bit of a volatile problem [11:18] jamesh: only if we can be perfect about it [11:18] zyga: e.g. have a task marked as requiring a user session, and have its prepare/execute/restore run as a user in a session [11:18] jamesh: and I doubt we can [11:18] jamesh: that would be nice but that's a bigger change and it's still unclear how to _get_ a user session reliably [11:19] PR snapd#8358 opened: seed: validate UC20 seed system label [11:19] pstolowski: mvo: ^^ [11:19] ty [11:24] mborzecki: https://github.com/snapcore/snapd/pull/8358#pullrequestreview-381913798 [11:24] PR #8358: seed: validate UC20 seed system label [11:57] PR snapd#8359 opened: config: add new Transaction.GetPristine{,Maybe}() function [12:18] xnox, hey [12:21] cachio: hi! did you have time to try reproduce https://bugs.launchpad.net/snapd/+bug/1868706 ? [12:21] Bug #1868706: Snapd postinst script hangs [12:22] pstolowski, yesterday I ran lot of tests but no luck [12:22] now I am going to run in a desktop vm [12:22] pstolowski, this test https://paste.ubuntu.com/p/FxXDys9KkT/ [12:23] hmm [12:23] pstolowski, if you want to take a look and propose anything else should be great [12:23] we cannot create warnings through the API, can we? [12:23] cachio: ok. note Mark said in the comments that there are no snaps when this happened [12:24] pstolowski: could it be seeding [12:24] pstolowski: when using focal you may end up with bad seeding [12:24] pstolowski: and then snap update from the deb archive will indeed "hang" [12:24] pstolowski: as the postinst script waits for seeding to complete [12:24] zyga: it's an existing system afaiu [12:24] pstolowski: I know [12:24] pstolowski: but think if this is possible [12:24] pstolowski, ah, yerday I cloneed a vm [12:24] and started upgrading [12:24] pstolowski: normally seeding being broken shows up as 1) no snaps 2) hang during update [12:24] like 10 times [12:24] but coulnd reproduce [12:26] zyga, something that I noticed is that postinst script tahngs like 1 minute or more until it finishes [12:26] it happened many times [12:26] but then it finishes [12:26] cachio: did you check what was going on then? [12:26] zyga: hmm that's an interesting observation. i thought about seeding but then the fact it wasn't a new installation (apparently) confused me. otoh, no snaps at all looks weird as well nowadays. indeed if seeding never completed then perahps it's causing an issue [12:27] yeah [12:27] I'm 90% sure that's that [12:27] 0 snaps [12:27] yes, but didnt see the error reported by mark [12:27] unless he actually removed snaps [12:27] I can check that again [12:33] mvo: can we land https://github.com/snapcore/snapd/pull/8350 now? [12:33] PR #8350: github: cache Debian dependencies for unit tests [12:33] all green and adjusted [12:38] zyga: thanks for the idea, i'll try to break seeds and see [12:38] pstolowski: I have 20.04 seed that's broken [12:38] if you want it [12:38] tarballed it u0 [12:38] in case I needed to :) [12:38] it's the one from one of the broken dailies [12:38] daily images [12:39] zyga: thanks, i'll quickly try to break it myself, will ask you for image if that doesn't work ;) [12:39] k [12:58] PR snapd#8360 opened: tests: adding more workers for ubuntu 20.04 [13:03] zyga: hmm i cannot provoke seed error, i'm probably breaking it wrong ;). share your tarball pls [13:03] pstolowski: sure [13:03] pstolowski: it's ~300MB [13:03] pstolowski: let me try something [13:03] zyga: it's fine, i'm on fiber here [13:03] man really? [13:03] you should run the spread cluster then ;D [13:03] I'm on LTE [13:04] 300Mb/s, from orange [13:04] I wish it was on my street [13:04] anyway [13:04] I have the file now [13:05] sending away [13:10] PR snapd#8342 closed: client, daemon, overlord/devicestate: request system action API and stubs [13:17] brb [13:21] zyga, when postinit script runs I see this [13:21] root 10026 9998 0 10:20 pts/0 00:00:00 /bin/systemd-tty-ask-password-agent --watch [13:21] it hangs for some seconds [13:21] cachio: ha [13:21] that's polkit [13:21] mborzecki: ^ [13:21] remember what you told me yesterday [13:21] is that what you saw? [13:21] ouch [13:21] wow [13:22] perhaps it's always started (doesn't make sense though?) [13:22] cachio: have you seen it on focal only? [13:23] also I see this [13:23] message+ 429 1 0 10:08 ? 00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only [13:23] just checked that on focal [13:24] mborzecki: mvo told us recently that apt (or dpkg) always creates a pty [13:24] so perhaps systemd thinks, gee let me ask the user [13:24] and spawns some text polkit prompt [13:24] anyway [13:24] I need to brb [13:24] for real [13:24] * zyga afk [13:30] hm idk, maybe it systemctl shoudl be called with --no-ask-password? [13:31] zyga: looking at the code it's started always if you're on local bus (i.e. talking to the local systemd) and there wa no --no-ask-password [13:31] hmmmm [13:37] zyga: you were right!! [13:38] how can i buy you a beer? ;) [13:38] mvo: ^ mistery of Mark's bug solved i think [13:39] pstolowski: ha [13:39] pstolowski: I could use a coffee :D [13:39] I just tried making one [13:39] but my son, Janek, is upstairs with remote teacher video call [13:40] I guess it's the age were everyone pretty much does what I do, sit in front of a screen all day [13:40] write type talk to people [13:40] I need to move the coffee machine here :D [13:40] apt is now hanging on snapd debs [13:40] lovely [13:40]