[05:10] <arnatious> 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] <arnatious> Fetched the torrent metadata* it hasn't been able to start downloading it
[06:23] <zyga> arnatious: this is insufficient information to debug, do you see any confinement denials in you log files?
[06:48] <mborzecki> morning
[06:57] <mborzecki> out for a bit to do groceries, before there's more people arriving at the store
[07:04] <zyga> mborzecki: o/
[07:10] <zyga> mvo: good morning :)
[07:11] <mvo> zyga: good morning
[07:12] <zyga> how are you feeling today?
[07:13] <mvo> zyga: good, thanks
[07:13] <mvo> zyga: you?
[07:13] <zyga> yeah, I'm trying to sleep more recently
[07:13] <zyga> I think it works
[07:14] <mvo> zyga: totally agreed, the right sleep is important :)
[07:14] <mvo> zyga: what's new? how are the gh actions doing?
[07:14] <zyga> I'm looking at https://github.com/snapcore/snapd/pull/8350
[07:14] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[07:15] <zyga> mvo: not much new yet, I would like to work on feature stuff today
[07:15] <zyga> mvo: and squeeze one more github action that runs C unit tests and various misc chcecks
[07:15] <zyga> mvo: and combine the actions into dependency chains, so that we don't spin up spread for sure-failing PRs
[07:16] <zyga> 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] <zyga> core20?
[07:16] <zyga> or something like that
[07:17] <zyga> mvo: apart from that I need to just focus on stuff I have pending
[07:17] <mvo> zyga: yeah, I think dep-chain is super welcome
[07:18] <zyga> I noticed that each .yaml file is a separate workflow
[07:18] <zyga> and you can only have dependency chains within one
[07:19] <mvo> hm, slightly sad
[07:19] <zyga> why?
[07:19] <zyga> it's okay, just splice yaml together
[07:20] <zyga> speaking about load, I was wondering if having a master commit action useful
[07:20] <zyga> we test each PR
[07:20] <zyga> then it lands and gets tested again
[07:20] <zyga> probably not useful
[07:20] <zyga> I would much rather have this on the release branches
[07:20] <zyga> where it is more prudent to be careful
[07:21] <mvo> zyga: yeah, the master merge test is mostly wasteful
[07:24] <mup> PR snapd#8337 closed: cmd/snap-bootstrap/initramfs-mounts/tests: use dirs.RunMnt over s.runMnt <Simple 😃> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8337>
[07:25] <zyga> mvo: https://github.com/snapcore/snapd/pull/8354 quick one to start the day then
[07:25] <mup> PR #8354: github: run spread tests on PRs only <Created by zyga> <https://github.com/snapcore/snapd/pull/8354>
[07:26] <mup> PR snapd#8354 opened: github: run spread tests on PRs only <Created by zyga> <https://github.com/snapcore/snapd/pull/8354>
[07:28] <mup> PR snapd#8339 closed: dirs: rm RunMnt; boot: add vars for early boot env layout; sysconfig: take targetdir arg <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8339>
[07:33] <mup> PR snapd#8344 closed: overlord/devicestate,boot: do not hold to the originally read modeenv <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8344>
[07:34] <mup> PR snapd#8349 closed: tests: cleanup security-private-tmp properly <Simple 😃> <Test Robustness> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8349>
[07:40] <mup> PR snapd#8353 closed: interfaces/docker-support: make containerd abstract socket more generic <Simple 😃> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8353>
[07:41] <mvo> zyga: hm, I just noticed something like "skip-spread" would be nice in the actions :)
[07:41] <zyga> yeah
[07:41] <zyga> but it couldn't have been in the initial run which also set skip :)
[07:41] <zyga> you can read labels
[07:41] <mup> PR snapd#8355 opened: github: run C unit tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8355>
[07:41] <zyga> let me just check the syntax on how to skip jobs that have a label
[07:41] <zyga> it's nice that this doesn't have the API bottleneck problem
[07:41] <zyga> we can just check whatever property we need to
[07:44] <mvo> yeah
[07:58] <mup> PR snapd#8354 closed: github: run spread tests on PRs only <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8354>
[07:59] <zyga> thanks :)
[08:01] <zyga> mvo: I replied on https://github.com/snapcore/snapd/pull/8350
[08:01] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[08:09] <mup> PR snapd#8356 opened: cmd/snap: Implement a "snap routine file-access" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8356>
[08:13] <zyga> jamesh: ^ reviewed
[08:13] <zyga> jamesh: if you rebase on master there will be less failing tests
[08:17] <jamesh> zyga: thanks.  I think it already is instance aware though
[08:17] <zyga> ah, snap.Name has both parts?
[08:18] <jamesh> yeah.  see cmd/snapinfo.go
[08:21] <mborzecki> re
[08:21] <mborzecki> turns out there was more people than i anticipated
[08:31] <pstolowski> morning
[08:35] <mborzecki> pstolowski: hey
[08:37] <mborzecki> zyga: when you restart the spread workflow in gh action, does it restart all jobs or just one?
[08:37] <mborzecki> zyga: i mean all jobs of that workflow (if it's a matrix)
[08:39] <mborzecki> damn, my trackball buttons are malfunctioning
[08:40] <mborzecki> zyga: btw failure in spread test that checks file group ownership https://paste.ubuntu.com/p/Y5RrfjxhY6/
[08:44] <zyga> mvo has fixed that one
[08:44] <zyga> Currently everything is restarted. Restarting fine grained bits is on the roadmap
[08:44] <mborzecki> aah
[08:45] <mvo> uh, that's bit of a downer
[08:45] <mborzecki> what if we use separate workflows for each system instead of matrix?
[08:45] <zyga> Same
[08:45] <zyga> All fine grained bits are coming
[08:45] <zyga> Although
[08:46] <zyga> You may be right with separate workflows
[08:46] <zyga> But then no dependencies
[08:51] <mborzecki> hmm bummer
[08:51] <mborzecki> thn maybe we should wait a bit before doing a complete switch
[08:51] <zyga> trading some for some :)
[08:51] <zyga> if spread is one big fat target we could restart that
[08:57] <dot-tobias> hi everyone
[08:57] <pstolowski> 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] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Confirmed> <systemd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1868706>
[09:02] <pstolowski> so perhaps it's something with one of snapd's own services
[09:03] <mborzecki> interesting
[09:23] <zyga> re
[09:23] <zyga> okay let's get to coding
[09:24] <zyga> mvo: can I convince you to +1 https://github.com/snapcore/snapd/pull/8350 ?
[09:24] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[09:24] <zyga> it saves a little bit of time
[09:24] <zyga> and will be more prominent with the next cache PR where go unit tests runtime will shrink
[09:24] <zyga> (so go tests << 1 minute)
[09:27] <zyga> uh, I need to pick up a delivery
[09:27] <zyga> AFK for 15
[09:27] <pstolowski> wrt 1868706 just tested without any snaps (snap-mgmt purge, and removed all seeds), the upgrade worked as well
[09:50] <zyga> back now
[09:50] <zyga> pstolowski: I saw a police patrol checking why people are outdoors
[09:50] <zyga> that's a new for me!
[09:51] <pstolowski> zyga: right, they announced it yesterday
[09:52] <zyga> too bad they are ignoring the hobos hanging around benches :P
[10:00] <mup> PR snapd#8355 closed: github: run C unit tests <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8355>
[10:05] <mvo> mborzecki: do you think 8342 needs a samuele review? it looks pretty good from my pov
[10:05] <mup> PR snapd#8309 closed: o/configcore: FilesystemOnlyApply method for early configuration of core (1/N) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8309>
[10:06] <mborzecki> 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] <mborzecki> pstolowski: maybe you could take a look at #8342 as well?
[10:06] <mup> PR #8342: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
[10:06] <mvo> mborzecki: +1
[10:07] <pstolowski> mborzecki: sure
[10:07] <mborzecki> pstolowski: thanks!
[10:14] <zyga> mvo: I've changed how we cache .deb files, seems to be passing;
[10:14] <zyga> mvo: I'll send one more patch that runs spread after unit tests
[10:14] <zyga> mvo: and that's all from me on gh actions today
[10:20] <mvo> zyga: ok
[10:21]  * zyga pushes to see if it uses the cache
[10:21] <mup> PR snapd#8335 closed: many: introduce naming.WellKnownSnapID <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8335>
[10:22] <dot-tobias> mvo: quick ping about zyga's https://github.com/snapcore/snapd/pull/8089#issuecomment-599914100 from affected snap developer :)
[10:22] <mup> PR #8089: features: enable robust mount ns updates <Created by zyga> <https://github.com/snapcore/snapd/pull/8089>
[10:22] <zyga> dot-tobias: what about it?
[10:24] <zyga> dot-tobias: it needs to be reviewed and merged
[10:31] <mup> PR snapd#8277 closed: asserts,o/devicestate: support model specified alternative serial-authority <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8277>
[10:33] <zyga> pstolowski: ping
[10:33] <pstolowski> zyga: pong
[10:33] <zyga> pstolowski: should I push a tiny branch with this change: https://github.com/snapcore/snapd/pull/8352/files#diff-08088787360fb3ca74a0aed4c6103b22R264
[10:33] <mup> PR #8352: wrappers: generate service files with EnsureDirState [WIP] <Created by zyga> <https://github.com/snapcore/snapd/pull/8352>
[10:33] <zyga> the part after, and including &&
[10:36] <mborzecki> zyga: yeah, jsut had to restart the spread run on opensuse-15 and all spread jobs in gh action got restarted :(
[10:36] <pstolowski> zyga: ah, this is the err cleanup bug you pinged me about some time ago? yes, it's fine, thank you!
[10:36] <zyga> mborzecki: right
[10:36] <zyga> pstolowski: k, doing so
[10:36] <pstolowski> zyga: it escaped me
[10:37] <mborzecki> zyga: so the question now is, can we still merge the PRs when one of the unstable systems fails?
[10:37] <dot-tobias> 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] <zyga> mborzecki: note that those are not mandatory
[10:37] <dot-tobias>  radar quickly, and thought like with 7655 a friendly ping might help 😊
[10:38] <zyga> mborzecki: you can totally ignore it
[10:38] <mborzecki> ah ok
[10:38] <zyga> dot-tobias: I don't know, it's a question to mvo
[10:38] <zyga> dot-tobias: maybe?
[10:38] <zyga> 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] <zyga> mborzecki: so we could have a run matrix that chooses what must pass
[10:38] <zyga> mborzecki: or what cannot fail
[10:39] <zyga> mborzecki: but instead of having YAML for it there's just the API you can reach
[10:39] <dot-tobias> zyga: That's who the ping msg was intended for, should've left out your handle – sorry
[10:39] <pstolowski> mborzecki: one wondering re your PR, otherwise +1
[10:39] <zyga> dot-tobias: no worries, I hope you can get it in
[10:40] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8357
[10:40] <mup> PR #8357: wrappers: respect pre-seeding in error path <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8357>
[10:40] <zyga> mvo: ^ for 2.44
[10:40] <mup> PR snapd#8357 opened: wrappers: respect pre-seeding in error path <Bug> <Simple 😃> <Created by zyga> <https://github.com/snapcore/snapd/pull/8357>
[10:45] <zyga> man, this is so weird
[10:45] <zyga> you push something
[10:45] <zyga> and green tick shows up a moment later
[10:45] <zyga> that's too werid
[10:45] <zyga> can we go back to days of waiting for the red cross?
[10:46] <mborzecki> zyga: you mean the 1940s?
[10:47] <zyga> mborzecki: is that what travis is?
[10:47] <mborzecki> zyga: it feels like it at times
[10:52] <mborzecki> pstolowski: hmm good question about the label, right now we only check whether it's not empty
[10:52] <pstolowski> mborzecki: a-zA-Z check or some such would do
[10:53] <mborzecki> pstolowski: we should probably enforce some validity checks, probably [a-zA-Z0-9]+
[10:53] <pstolowski> yeah
[10:53] <ogra> 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] <zyga> ogra: please do
[10:53] <ogra> ok
[10:53] <zyga> I was unable to restart testing
[10:53] <zyga> ogra: or better
[10:53] <zyga> ogra: merge master
[10:53] <mborzecki> pstolowski: looked at seed, but there's no checks either
[10:55] <mborzecki> pstolowski: hm it probably makes most sense to add it in the seed 'seed' packge, in a follow up though
[10:56] <ogra> zyga, bah i hadn't reloaded the page ... seems mborzecki already managed to restart the test anyway
[10:56] <zyga> cool, that's ok
[10:56] <zyga> I need to improve caching today
[10:56] <mborzecki> ogra: yeah, though i doubt it stated given the usual job queue length
[10:56] <zyga> most of the extra waste is each spread run checking out a git tree
[10:57] <ogra> it seems to be running
[10:57] <zyga> I need to just have a local copy as accelerator
[10:57] <ogra> interesting though that you are the only one being able to trigger them
[10:57] <zyga> ogra: me or maciek?
[10:57] <ogra> maciek
[11:11] <jamesh> 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] <mup> PR #8289: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8289>
[11:16] <zyga> jamesh: I am close to fixing the session-tool issue
[11:16] <zyga> jamesh: please just ignore that test failure
[11:17] <zyga> jamesh: also, sessions are hard :)
[11:17] <jamesh> zyga: I wonder if it would be better to implement this kind of thing in spread itself?
[11:18] <zyga> jamesh: not sure, it's a bit of a volatile problem
[11:18] <zyga> jamesh: only if we can be perfect about it
[11:18] <jamesh> 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] <zyga> jamesh: and I doubt we can
[11:18] <zyga> 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] <mup> PR snapd#8358 opened: seed: validate UC20 seed system label <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8358>
[11:19] <mborzecki> pstolowski: mvo: ^^
[11:19] <pstolowski> ty
[11:24] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8358#pullrequestreview-381913798
[11:24] <mup> PR #8358: seed: validate UC20 seed system label <Simple 😃> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8358>
[11:57] <mup> PR snapd#8359 opened: config: add new Transaction.GetPristine{,Maybe}() function <Created by mvo5> <https://github.com/snapcore/snapd/pull/8359>
[12:18] <cachio> xnox, hey
[12:21] <pstolowski> cachio: hi! did you have time to try reproduce https://bugs.launchpad.net/snapd/+bug/1868706 ?
[12:21] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
[12:22] <cachio> pstolowski, yesterday I ran lot of tests but no luck
[12:22] <cachio> now I am going to run in a desktop vm
[12:22] <cachio> pstolowski, this test https://paste.ubuntu.com/p/FxXDys9KkT/
[12:23] <zyga> hmm
[12:23] <cachio> pstolowski, if you want to take a look and propose anything else should be great
[12:23] <zyga> we cannot create warnings through the API, can we?
[12:23] <pstolowski> cachio: ok. note Mark said in the comments that there are no snaps when this happened
[12:24] <zyga> pstolowski: could it be seeding
[12:24] <zyga> pstolowski: when using focal you may end up with bad seeding
[12:24] <zyga> pstolowski: and then snap update from the deb archive will indeed "hang"
[12:24] <zyga> pstolowski: as the postinst script waits for seeding to complete
[12:24] <pstolowski> zyga: it's an existing system afaiu
[12:24] <zyga> pstolowski: I know
[12:24] <zyga> pstolowski: but think if this is possible
[12:24] <cachio> pstolowski, ah, yerday I cloneed a vm
[12:24] <cachio> and started upgrading
[12:24] <zyga> pstolowski: normally seeding being broken shows up as 1) no snaps 2) hang during update
[12:24] <cachio> like 10 times
[12:24] <cachio> but coulnd reproduce
[12:26] <cachio> zyga, something that I noticed is that postinst script tahngs like 1 minute or more until it finishes
[12:26] <cachio> it happened many times
[12:26] <cachio> but then it finishes
[12:26] <zyga> cachio: did you check what was going on then?
[12:26] <pstolowski> 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] <zyga> yeah
[12:27] <zyga> I'm 90% sure that's that
[12:27] <zyga> 0 snaps
[12:27] <cachio> yes, but didnt see the error reported by mark
[12:27] <zyga> unless he actually removed snaps
[12:27] <cachio> I can check that again
[12:33] <zyga> mvo: can we land https://github.com/snapcore/snapd/pull/8350 now?
[12:33] <mup> PR #8350: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8350>
[12:33] <zyga> all green and adjusted
[12:38] <pstolowski> zyga: thanks for the idea, i'll try to break seeds and see
[12:38] <zyga> pstolowski: I have 20.04 seed that's broken
[12:38] <zyga> if you want it
[12:38] <zyga> tarballed it u0
[12:38] <zyga> in case I needed to :)
[12:38] <zyga> it's the one from one of the broken dailies
[12:38] <zyga> daily images
[12:39] <pstolowski> zyga: thanks, i'll quickly try to break it myself, will ask you for image if that doesn't work ;)
[12:39] <zyga> k
[12:58] <mup> PR snapd#8360 opened: tests: adding more workers for ubuntu 20.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8360>
[13:03] <pstolowski> zyga: hmm i cannot provoke seed error, i'm probably breaking it wrong ;). share your tarball pls
[13:03] <zyga> pstolowski: sure
[13:03] <zyga> pstolowski: it's ~300MB
[13:03] <zyga> pstolowski: let me try something
[13:03] <pstolowski> zyga: it's fine, i'm on fiber here
[13:03] <zyga> man really?
[13:03] <zyga> you should run the spread cluster then ;D
[13:03] <zyga> I'm on LTE
[13:04] <pstolowski> 300Mb/s, from orange
[13:04] <zyga> I wish it was on my street
[13:04] <zyga> anyway
[13:04] <zyga> I have the file now
[13:05] <zyga> sending away
[13:10] <mup> PR snapd#8342 closed: client, daemon, overlord/devicestate: request system action API and stubs <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8342>
[13:17] <zyga> brb
[13:21] <cachio> zyga, when postinit script runs I see this
[13:21] <cachio> root       10026    9998  0 10:20 pts/0    00:00:00 /bin/systemd-tty-ask-password-agent --watch
[13:21] <cachio> it hangs for some seconds
[13:21] <zyga> cachio: ha
[13:21] <zyga> that's polkit
[13:21] <zyga> mborzecki: ^
[13:21] <zyga> remember what you told me yesterday
[13:21] <zyga> is that what you saw?
[13:21] <mborzecki> ouch
[13:21] <mborzecki> wow
[13:22] <mborzecki> perhaps it's always started (doesn't make sense though?)
[13:22] <mborzecki> cachio: have you seen it on focal only?
[13:23] <cachio> also I see this
[13:23] <cachio> message+     429       1  0 10:08 ?        00:00:01 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
[13:23] <cachio> just checked that on focal
[13:24] <zyga> mborzecki: mvo told us recently that apt (or dpkg) always creates a pty
[13:24] <zyga> so perhaps systemd thinks, gee let me ask the user
[13:24] <zyga> and spawns some text polkit prompt
[13:24] <zyga> anyway
[13:24] <zyga> I need to brb
[13:24] <zyga> for real
[13:24]  * zyga afk
[13:30] <mborzecki> hm idk, maybe it systemctl shoudl be called with --no-ask-password?
[13:31] <mborzecki> 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] <mborzecki> hmmmm
[13:37] <pstolowski> zyga: you were right!!
[13:38] <pstolowski> how can i buy you a beer? ;)
[13:38] <pstolowski> mvo: ^ mistery of Mark's bug solved i think
[13:39] <zyga> pstolowski: ha
[13:39] <zyga> pstolowski: I could use a coffee :D
[13:39] <zyga> I just tried making one
[13:39] <zyga> but my son, Janek, is upstairs with remote teacher video call
[13:40] <zyga> I guess it's the age were everyone pretty much does what I do, sit in front of a screen all day
[13:40] <zyga> write type talk to people
[13:40] <zyga> I need to move the coffee machine here :D
[13:40] <pstolowski> apt is now hanging on snapd debs
[13:40] <zyga> lovely
[13:40] <pstolowski> pstree shows similiar output
[13:43] <zyga> pstolowski: what does pstree show?
[13:44] <pstolowski> zyga: it matches the one from bug report https://pastebin.ubuntu.com/p/74XywhJfwc/
[13:44] <zyga> yeah
[13:44] <pstolowski> snapd.seeded.service makes it wait i presume
[13:44] <zyga> the problem is that we should not start the seeding unit
[13:45] <zyga> it's a debhelper thing
[13:45] <zyga> it's not sane in our case
[13:45] <pstolowski> mhm. we should probably do something sane
[13:45] <zyga> I think we need to adjust that debhelper line
[13:50] <pstolowski> cachio: so, problem understood ^
[13:51] <zyga> mvo: 2.44.1 is failing to build in the edge ppa
[13:52] <mvo> zyga: uh, all of it?
[13:52] <zyga> https://www.irccloud.com/pastebin/yjTrMeXv/
[13:52] <zyga> just this test
[13:52] <zyga> we've seen it before, didn't you say it was some package in the archive thing?
[13:52] <mvo> pstolowski: oh, mystery solved? I like that!
[13:53] <mvo> pstolowski: can you give me the tl;dr summary please? or explain in the standup maybe
[13:56] <ijohnson> good work pstolowski
[13:56] <ijohnson> and zyga too :-)
[13:56] <ijohnson> and morning folks
[13:57] <zyga> good morning :)
[13:57] <zyga> oh
[13:57] <zyga> standup time
[13:57] <pstolowski> mvo: focal image with broken seeds; seeds never completes; snapd deb update blocks on snapd.seeded.service
[13:58] <pstolowski> i've updated https://bugs.launchpad.net/snapd/+bug/1868706
[13:58] <mup> Bug #1868706: Snapd postinst script hangs <snapd:Triaged> <dpkg (Ubuntu):Invalid> <systemd (Ubuntu):Invalid> <https://launchpad.net/bugs/1868706>
[13:58] <pstolowski> hey ijohnson
[13:59] <mvo> pstolowski: ha! fun, just like last time. also *so* sad
[13:59]  * ijohnson stands up while sitting down
[14:03] <zyga> mvo: /dev/fuse has a new meaning
[14:03] <zyga> there's an IOCTL to explode the pC
[14:14] <mvo> zyga: haha
[15:18] <zyga> I wrote the instructions for github actions runner
[15:18] <zyga> who wants to work with me to try it ouy?
[15:19] <zyga> degville: perhaps you? (it's a wall of text)
[15:19] <zyga> but anyone who wants to is totally welcome to
[15:19] <degville> zyga: yes, of course.
[15:22] <zyga> mvo: ok, it's in progress :)
[15:26] <ijohnson> mvo is it okay for me to de-conflict #8010 now ?
[15:26] <mup> PR #8010: snap-bootstrap: add support for "recover" mode <Needs Samuele review> <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
[15:29] <mvo> ijohnson: sure
[15:29] <ijohnson> ack
[15:44]  * zyga -> food
[15:58] <mup> PR snapd#8358 closed: seed: validate UC20 seed system label <Simple 😃> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8358>
[15:59] <mup> PR snapd#8357 closed: wrappers: respect pre-seeding in error path <Bug> <Simple 😃> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8357>
[16:00] <mup> PR snapd#8361 opened: o/devicestate: rename readMaybe* to maybeRead* <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8361>
[16:00] <zyga> re
[16:02] <mup> PR snapd#8350 closed: github: cache Debian dependencies for unit tests <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8350>
[16:02] <zyga> ta!
[16:02] <zyga> I'll propose the last step in a sec, let me just organize myself after the break
[16:10] <mup> PR snapd#8362 opened: github: fix order of go get caches <Simple 😃> <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8362>
[16:14] <mup> PR snapd#8363 opened: github: combine tests into one workflow <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8363>
[16:17] <ijohnson> mborzecki: is #8305 ready to review now?
[16:17] <mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
[16:18] <mborzecki> ijohnson: yes, there will be some tweaks to the data that's passed back, but the overall shape should not change at this point
[16:18] <ijohnson> ack I'll review that today then
[16:19] <Saviq> zyga: you should know this… following https://snapcraft.io/docs/installing-snap-on-fedora on F31
[16:19] <zyga> yeah?
[16:19] <Saviq> $ snap install hello-world
[16:19] <Saviq> error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount:
[16:19] <Saviq>        /tmp/sanity-mountpoint-444060033: unknown filesystem type 'squashfs'.
[16:19] <zyga> yeah
[16:19] <zyga> also known as rpm sucks at dependencies
[16:20] <zyga> you are installing the modules for the kernel
[16:20] <zyga> but not the one you are running
[16:20] <zyga> IIRC rebooting will fix it
[16:20] <zyga> because now kernel and modules match
[16:20] <Saviq> DUH
[16:21] <Saviq> https://forum.snapcraft.io/t/installing-snap-on-fedora/6755/9?u=saviq
[16:22] <zyga> Saviq: try rebooting and tell me if that helped
[16:22] <Saviq> nope
[16:23] <Saviq> zyga: ↑
[16:23] <zyga> Saviq: hmmmmmm
[16:23] <zyga> Saviq: is that a cloud vm?
[16:23] <zyga> or a desktop system
[16:23] <Saviq> zyga: cloud
[16:23] <zyga> ah
[16:24] <zyga> so cloud is more complex - their kernel seems to lack that
[16:24] <zyga> and we cannot express the dependency clearly IIRC
[16:24] <zyga> there's a package you should be able to install though, one moment
[16:24] <Saviq> zyga: ack, I will reply to the forum thread with a reproducer
[16:24] <zyga> Saviq: try installing kernel-modules
[16:24] <Mirv> you may be interested in checking if this is something on snap side or fwupd side: https://github.com/fwupd/fwupd/issues/1915
[16:25] <Saviq> whois Mirv
[16:25] <Saviq> Timo!
[16:25] <Saviq> o/
[16:25] <Mirv> (likely fwupd, as it's a regression, but I guess something in snap when using classic mode could also assume ubuntuish ca-certifates)
[16:25] <Mirv> :D Saviq!!
[16:25] <zyga> Mirv: opensuse uses different /etc/ssl layout than debian
[16:26] <zyga> Mirv: perhaps we need to look
[16:26] <zyga> it' a classic snap?
[16:26] <zyga> so it should be less so but still
[16:26] <Mirv> zyga: yes it does, I haven't bumped into such problem before with any snap though, and fwupd also used to work correctly
[16:26] <zyga> can you reproduce that or is that someone else reporting?
[16:26] <Mirv> it's my report
[16:26] <zyga> does /etc/ssl/certs/ca-certificates.crt exist?
[16:27] <Mirv> so simply installing fwupd currently on Tumbleweed shows it
[16:27] <Mirv> no, there's no such thing on openSUSE
[16:27] <zyga> do you know what is trying to read that file?
[16:27] <zyga> is it some kind of hard-coded feature of the library bundled in the snap/
[16:27] <zyga> I'm also surprised it worked before
[16:27] <zyga> nothing changed in that regard in many months
[16:28] <Mirv> not really.
[16:29] <Mirv> it was my guess it'd be something changed in fwupd, but thought to mention here too if it'd immediately ring some bell
[16:30] <Mirv> strace https://pastebin.ubuntu.com/p/FRzNVPM9QJ/
[16:30] <zyga> Mirv: where are the certs on your system?
[16:30] <zyga> Mirv: IIRC it's just a "hard thing" to make classic snaps
[16:31] <zyga> I don't think snapd can do anything about this
[16:34]  * cachio lunch
[16:34] <mup> PR snapd#8364 opened: github: offload self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8364>
[16:35] <Mirv> zyga: around /usr/share/pki/trust/ , the system is very different from Debian/Ubuntu indeed
[16:35] <zyga> Mirv: can you try to summarize how it looks like, perhaps it will allow us to come up with some ideas
[16:35] <Mirv> zyga: right, thanks, that's mostly what I wanted to hear that it's up to snap package to (try to) keep cross-distro compatibility in a classic snap
[16:35] <zyga> Mirv: and it is also useful because mvo is working on a ssl-related feature CC mvo  ^
[16:36] <Mirv> zyga: I'm not very familiar with that either https://unix.stackexchange.com/questions/80131/how-do-i-install-a-system-wide-ssl-certificate-on-opensuse
[16:38] <zyga> Mirv: can you respond to https://github.com/fwupd/fwupd/issues/1915
[16:38] <zyga> Mirv: I'm not familiar with the snap
[16:41] <Mirv> Access by specifying a revision is not allowed for this Snap. ... hmm, ok, I'd have liked to triage
[16:42] <Mirv> answered yes, maybe superm1 can debug it if he's maintaining the snap
[16:51] <ijohnson> zyga: have you ever looked at `spread -abend` ?
[16:51] <ijohnson> seems to do what you were wanting in this morning's SU
[16:51] <zyga> yeah
[16:52] <zyga> can you remind me?
[16:52] <zyga> ah
[16:52] <zyga> the log?
[16:52] <zyga> or ... no?
[16:52] <zyga> I don't recall
[16:52] <ijohnson> you wanted a way to stop the spread run on the first failure
[16:52] <zyga> ah
[16:52] <zyga> oh!
[16:52] <zyga> then I must have not remembered the name right, I dind't know it exits
[16:53] <zyga> oh that's perfect
[16:53] <zyga> I'll use that
[16:53] <zyga> thank you  :)
[16:53] <ijohnson> :-)
[16:59] <Mirv> zyga: turns out I was able to install older versions after all, which also failed.. so then it turned out it's actually openSUSE bug of some sort, to which I documented a workaround
[17:00] <cachio> zyga, did yo usee the values I left in the standup doc?
[17:00] <zyga> cachio: yes but they are too opaque, we should check out what's taking that time
[17:00] <zyga> yes numbers are bigger
[17:00] <zyga> why?
[17:01] <cachio> zyga, do you know a way to trace systemd and get times?
[17:02] <zyga> cachio: I would look at perf
[17:02] <zyga> I think it is not systemd
[17:02] <zyga> but many components of the system and their interaction
[17:02] <zyga> cachio: if you work with maciek on this he should be able to help you, he's pretty good at using perf
[17:02] <cachio> zyga, sure
[17:03] <zyga> ok, I need to EOD soon
[17:03] <cachio> mborzecki, do you have any suggestion to see what's going on with systemd calls?
[17:03] <mup> PR snapcraft#2984 closed: plugins: move the existing plugin to a new package <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2984>
[17:06] <mup> PR snapcraft#2993 closed: repo: remove dead code from deb implementation <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2993>
[17:06] <mup> PR pc-amd64-gadget#35 closed: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
[17:07] <mborzecki> cachio: not really, probably we'd have to start with a single call, eg systemctl <some>.service and then observe the bus traffic between the old version and new one, probably gather a bunch of samples too
[17:08]  * zyga EODs
[17:08] <mborzecki> yeah, me too
[17:09] <mborzecki> now the 'home schooling' shift starts :/
[17:09] <mup> PR snapcraft#2994 closed: repo: move filtered package list from manifest.txt into a python list <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2994>
[17:40] <mup> PR snapd#8361 closed: o/devicestate: rename readMaybe* to maybeRead* <Simple 😃> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8361>
[17:41] <mup> PR snapd#8359 closed: config: add new Transaction.GetPristine{,Maybe}() function <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8359>
[18:15] <mup> PR snapcraft#2995 opened: Add gcc to the build-packages for the gnome-3-34 extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2995>
[20:26] <mup> PR snapd#8365 opened: seed: add Info() method for seed.Snap <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8365>
[20:26] <mup> PR snapd#8366 opened: cmd/snap-bootstrap/initramfs-mounts: verify the seed snap matches bootloader env <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8366>
[20:59] <mup> PR snapd#8367 opened: snap/cmd: the model command needs just a client, no waitMixin <Simple 😃> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8367>
[21:33] <mup> PR snapd#8345 closed: boot,overlord: rename operating mode to system mode  <Reviewed> <Skip spread> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8345>
[22:17] <mup> PR snapd#8360 closed: tests: adding more workers for ubuntu 20.04 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8360>