[05:24] <mborzecki> morning
[05:43] <zyga> Hey
[05:44] <zyga> mborzecki: I will be around in about an hour
[05:44] <mborzecki> zyga: hey
[06:02] <mup> PR snapd#8745 closed: tests: port xdg-open-compat to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8745>
[06:03] <mup> PR snapd#8746 closed: tests: port xdg-open to session-tool <Test Robustness> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8746>
[06:21] <zyga> thanks!
[06:21] <zyga> mborzecki: it would be good to review the f32 branch from sergio
[06:21] <zyga> once merged we should have those green ticks again
[06:21] <mborzecki> zyga: yeah, i'll be pushing some fixes there
[06:21] <zyga> ok
[06:24] <zyga> brb again
[06:33] <mborzecki> mvo: hey
[06:35] <mvo> good morning mborzecki
[06:39] <mup> PR snapd#8743 closed: tests: cherry-pick test fixes from master (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8743>
[06:46] <mvo> 8351 needs a second review
[06:48] <mup> PR snapd#8661 closed: configcore: add "service.console-conf.disable" config option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8661>
[07:03] <pstolowski> mornings!
[07:04] <mup> PR snapd#8748 opened: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8748>
[07:09] <pstolowski> #8533 has been unblocked and needs 2nd review
[07:09] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[07:18] <mup> PR snapd#8749 opened: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>
[07:36] <zyga> jamesh: https://github.com/snapcore/snapd/pull/8748#pullrequestreview-418929307
[07:36] <mup> PR #8748: overlord: refuse to install snaps providing user daemons on Ubuntu 14.04 <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8748>
[07:36] <pstolowski> mvo: thank you for 8749!
[07:39] <pedronis> pstolowski: hi, could you review #8351 ? also do poke Sergio about your #8533
[07:39] <mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
[07:39] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[07:39] <pstolowski> pedronis: yes
[07:41] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8709#pullrequestreview-418926302
[07:41] <mup> PR #8709: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8709>
[07:41] <pstolowski> zyga: thanks!
[07:43] <jamesh> zyga: thanks.  I guess one difference is that the systemd in CentOS 7 supports user units, but they just don't run the instance.
[07:44] <zyga> jamesh: what do you mean by supports?
[07:44] <jamesh> whereas 14.04's systemd doesn't support them at all
[07:44] <zyga> ah
[07:44] <zyga> centos 7 is compiled without that IIRC
[07:44] <zyga> (explicitly disabled)
[07:44] <zyga> but those are shades of gray I suppose
[07:44] <jamesh> zyga: as in "systemctl --user --global enable some-user-unit.service" succeeds on Centos 7
[07:44] <zyga> Ah, that's weird, perhaps not fully disabled
[07:45] <zyga> but officially disabled per RH design
[07:46] <jamesh> zyga: I guess in some ways it is similar to Ubuntu Core, where it is technically possible to set up a user session but it is rarely done
[07:47] <jamesh> (granted that will probably change in future)
[07:56] <zyga> brb, small breakfast
[07:58] <ogra> hmm ... is there a snapctl command that can tell me if seeding is done ?
[08:04] <zyga> ogra: snapctl?
[08:04] <zyga> or snap?
[08:07] <ogra> zyga, snapctl (or the rest API)
[08:07] <ogra> a customer wants to check the state from inside a snap
[08:08] <ogra> i know he could loop over the changes output via the API until "Initialize device" is marked "done" but wanted to know if there is a more integrated and less hackish way
[08:08] <zyga> I don't think this is supported
[08:08] <zyga> let me look
[08:09] <zyga> nope
[08:09] <zyga> not supported
[08:10] <ogra> ok, then looping over changes it is ...
[08:18] <jamesh> ogra: the snapd.seeded.service systemd service runs "snap wait system seed.loaded".  If you've got access to the REST API, you could presumably do the same
[08:20] <ogra> jamesh, hmm, how would i get that info from the api beyond looping over the changes ?
[08:21] <ogra> i dont see any rest endpoint that could give me that info beyond the chnages output
[08:21] <jamesh> ogra: check what /usr/bin/snap does?
[08:22] <jamesh> ogra: looks like it's effectively doing "snap get system seed.loaded" every 500 milliseconds until it returns true
[08:22] <ogra> oh, its aconfig option !!!
[08:22] <ogra> thanks ! i totally forgot about that bit
[08:23] <ogra> so there *is* a snapctl way in the end :)
[08:23] <jamesh> snapctl will only give you your own config though, right?
[08:24] <jamesh> not the system snap's configuration
[08:24] <ogra> it queries "system" in that case
[08:24] <ogra> well, a gadget can do that
[08:24] <ogra> iirc
[08:24] <jamesh> you'd know more about that than me :-)
[08:26] <zyga> ogra: snap and snapctl have different APIs
[08:27] <ogra> zyga, well, he has the API ... so using "GET /v2/snaps/[name]/conf" should be able to get him "system" configs, no ?
[08:28] <zyga> what do you mean by "he has the API"
[08:28] <jamesh> presumably he has snapd-control level access
[08:28] <zyga> ah
[08:28] <zyga> in that case then yes
[08:28] <ogra> teh question comes from a customer with brand store
[08:28] <ogra> right
[08:28] <ogra> geez, we need customer docs for this 1
[08:28] <ogra> !
[08:28]  * ogra makes note
[08:29] <ogra> i know some that *actually* loop over the changes output to find out :)
[08:48]  * zyga debugs with -seed= again
[08:55] <zyga> hey, reproduced
[08:56] <zyga> ha
[08:56] <zyga> funny
[08:56] <zyga> let's write an invariant to find the culprit
[08:57] <zyga> some test nukes some packages but doesn't reload systemd
[08:57] <zyga> so the invariant will find systemd that complains abou "some units changed on disk"
[08:57] <zyga> and this will lead us to the test breaking stuff
[09:27] <zyga> eureka
[09:27] <zyga> tests/upgrade/basic user unit snapd.session-agent.socket changed on disk
[09:29] <zyga> in fact
[09:29] <zyga> it keeps getting changed
[09:29] <zyga> hmmmm
[09:29] <zyga> I wonder why
[09:29] <zyga> maybe we should not be agressively rewriting it
[09:30] <zyga> but that's just noise
[09:31] <zyga> there's another test that breaks dbus.socket
[09:53] <zyga> fortunately not that many tests need fixes
[09:53] <zyga> about half a dozen one liners
[09:53] <zyga> mvo: ^ another lesson learned
[09:53] <zyga> systemd units have state in memory and on disk
[09:54] <zyga> and in memory state is the one that counts
[09:54] <zyga> units are modified by tests and left stale in memory after "restoring" the disk state
[09:56] <mvo> zyga: oh, woah, nice catch
[09:56] <zyga> yeah, it manifested as a random failure that I managed to reproduce with -seed
[09:56] <zyga> and ended up being a dbus.socket that's only in memory because the disk file is gone
[09:56] <zyga> and cannot be activated (because no .service because also gone)
[09:57] <zyga> so some test removes dbus.socket/service but the bigger find is that the in-memory state matters
[09:57] <zyga> writing and running tests is useful but I think we could write a boot about integration testing now
[10:03] <zyga> *book :)
[10:04] <mup> PR snapd#8747 closed: tests: port snap-routine-portal-info to session-tool <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8747>
[10:15] <mborzecki> reading bug reports, it's amazing how people quickly jump to reinstalling the system whenever even a smallest issue pops up
[10:16] <zyga> mborzecki: do you know windows made that super easy?
[10:16] <zyga> maybe it's something they learned and apply to other OSes
[10:16] <mborzecki> zyga: seriously? my experience with windows reinstall was that it was a huge waste of time
[10:17] <zyga> mborzecki: why?
[10:17] <mborzecki> though it did fix issues there ;)
[10:17] <zyga> mborzecki: btw, windows 10 reinstall is super easy
[10:17] <zyga> it's literally 4 clicks from the start menu
[10:17] <zyga> and the experience is quite nice
[10:17] <mborzecki> haven't reinstalled 10 yet, maybe i'm not using it enough
[10:17] <zyga> (can preserve apps or just data, entirely unattended)
[10:18] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8693/files has some spurious changes
[10:18] <mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
[10:18] <zyga> are they relevant or can we nuke them?
[10:18] <mborzecki> zyga: yeah, noticed them after i pushed the changes, don't think it's worth another spread run though
[10:18] <zyga> ok
[10:18] <zyga> I resolved a conflict
[10:19] <zyga> but didn't notice this until after
[10:19] <mborzecki> hah ;)
[10:19] <zyga> one thing that I miss on !windows is family management
[10:19] <mborzecki> once it's green, we should land it
[10:19] <zyga> yeah
[10:19] <zyga> control over time, app access and even browser page access
[10:20] <mborzecki> haha i talked with mvo about a killed linux app that could do that
[10:20] <zyga> I really wish we had something comparable
[10:20] <mborzecki> which would be great, and we probably have the right technology to do it already
[10:20] <zyga> yeah but it's either really well done and useful or it's not useful at all :/
[10:20] <zyga> loopholes => not useful, poor UX => not useful, not localized => not usefl
[10:20] <zyga> though I bet it would be good to have something and work from there
[10:21] <zyga> I think one major problem is that it requires central authority and accounts to be easy to use
[10:21] <mborzecki> well, we don't have anything there yet, so ;)
[10:21] <zyga> yeah
[10:21] <mborzecki> pedronis: added some comments under https://github.com/snapcore/snapd/pull/8569
[10:21] <mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
[10:21] <zyga> even limiting time is hard
[10:21] <zyga> gdm would have to cooperate
[10:22] <mborzecki> pedronis: is that the last PR in that series?
[10:22] <pedronis> mborzecki: I saw, thx
[10:22]  * zyga needs to manage browser tabs, brb
[10:22] <pedronis> mborzecki: it's the main one, but no, as the description says there will be a couple more follow ups, one is almost ready, but is not proposed yet
[10:22] <mborzecki> ok
[10:24] <pstolowski> zyga: can you take another look at #8639?
[10:24] <mup> PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
[10:24] <zyga> ha
[10:24] <zyga> sure
[10:24] <zyga> I just looked at another branch and though that was the same one :)
[10:26] <mborzecki> heh, something weird about go compiler
[10:26] <zyga> hmm?
[10:27] <mborzecki> took #8749, dropped the default: case like so https://paste.ubuntu.com/p/NJSFCQkF8N/, then compiler complains about ./services.go:90:1: missing return at end of function
[10:27] <mup> PR #8749: configcore: show better error when disabling services <Created by mvo5> <https://github.com/snapcore/snapd/pull/8749>
[10:28] <mborzecki> by looking at the code i see that there always is a return in the switch cases there
[10:30] <mup> PR core20#69 opened: hooks: remove redundancy from timezone settings <Created by mvo5> <https://github.com/snapcore/core20/pull/69>
[10:30] <mborzecki> heh this is weird https://play.golang.org/p/-Bxl-hPNAeu
[10:31] <mvo> mborzecki: heh, this looks familiar
[10:31] <zyga> mborzecki: go doesn't do proper analysis
[10:31] <mborzecki> mvo: yup, the pr you opened
[10:31] <zyga> erring on the "compile quickly"
[10:31] <mvo> mborzecki: I was surprised as well
[10:31] <zyga> it sucks but it's a known issue
[10:32] <mborzecki> mvo: wonder whether the compiler would even determine that panic code is unreachable
[10:32] <mvo> mborzecki: if it can it should be easy to fix the bug :)
[10:32] <mvo> mborzecki: I mean, the bug/issue that this requires a return still
[10:32] <mborzecki> famous last words :P
[10:32] <mvo> lol
[10:32] <mvo> actually rofl
[10:33] <mvo> yeah, I will not try or I get sucked into a black hole
[10:33] <zyga> mborzecki: I wonder if: if false { println("DUPA") }
[10:33] <zyga> mborzecki: compiles in a way where DUPA is gone from the binary
[10:34] <mborzecki> haha if works https://play.golang.org/p/j2VSn1xex7K
[10:34] <mvo> mborzecki: woah, that's "funny
[10:34] <mvo> "
[10:35] <zyga> it's weird especially considering that go's switch/case degenerates to if-then-else tree
[10:37] <mup> PR snapd#8351 closed: config: apply vitality-hint immediately when the config changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8351>
[10:38] <mborzecki> funny that it's quite happy when there's a default case
[10:41] <mborzecki> so bools in a switch are tri-state, true, false, something-in-between
[10:41] <pstolowski> pedronis: is #8569 ready to be reviewed?
[10:41] <mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
[10:42] <pstolowski> mborzecki: that's peculiar
[10:45] <mup> PR core20#69 closed: hooks: remove redundancy from timezone settings <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/69>
[10:47] <zyga> mvo: thank you for that test btw
[10:47] <zyga> mvo: I wonder if we could integrate some other things there
[10:47] <zyga> like timedatectl
[10:47] <mborzecki> time to file a bug in go
[10:47] <zyga> setting timezone
[10:47] <zyga> setting NTP
[10:47] <zyga> all super basic stuff
[10:47] <zyga> but it was broken on more than one occasion
[10:48] <mup> PR snapd#8750 opened: tests: improve oom-vitality tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8750>
[10:49] <mvo> zyga: you mean 69?
[10:49] <zyga> mvo: you proposed something relevant yesterday
[10:49] <zyga> to snapd
[10:49] <mvo> zyga: aha, yes - we can, it's strange, partly this is covered by interface tests
[10:49] <mvo> zyga: but I suspect it's much cleaner to have a dedicated test
[10:50] <zyga> yeah but I think there's a difference, those tools often use DBus APIs
[10:50] <zyga> and perhaps there's some factor where a tool modifies something directly vs issues a call
[10:50] <zyga> so good to have a dedicated basic-management test like that
[10:51] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8351#discussion_r431028861
[10:51] <mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8351>
[10:52] <mvo> zyga: cool, thanks, I will work on the system-settings a bit more I guess
[10:52] <zyga> I actually wonder
[10:52] <zyga> in your core system deployments
[10:52] <zyga> did you set things like hostname, timezone and ntp manually?
[10:54]  * zyga breaks focus to finish some reviews
[10:57] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8639#pullrequestreview-419079982
[10:57] <mup> PR #8639: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services ⚙️> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
[11:00]  * zyga found the broken test
[11:03] <mup> PR core20#70 opened: Fix localtime <Created by xnox> <https://github.com/snapcore/core20/pull/70>
[11:06] <mup> PR core20#71 opened: tests: support test_etc-writable-symlinks.sh outside snapcraft <Created by mvo5> <https://github.com/snapcore/core20/pull/71>
[11:13] <zyga> brb, coffee
[11:14] <zyga> it's hard to use the coffee machine
[11:14] <zyga> when one kid is constantly remote-schooling in the kitchen :D
[11:21] <pedronis> pstolowski: zyga: I asked a new question in #8691
[11:22] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[11:24] <pedronis> pstolowski:  #8569, yes
[11:24] <mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
[11:24] <pedronis> there are some open questions and tweaks but in itself is good to go
[11:24] <zyga> pedronis: looking
[11:26] <zyga> replied
[11:29] <zyga> gah, I wish spread used mosh instead of ssh
[11:29] <zyga> mosh is so nice for roaming
[11:30] <mup> PR core18#154 opened: Test timezone contents and symlink <Created by xnox> <https://github.com/snapcore/core18/pull/154>
[11:35] <mup> PR core20#71 closed: tests: support test_etc-writable-symlinks.sh outside snapcraft <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core20/pull/71>
[11:38] <zyga> pedronis: testing.global.session testing.netgate testing.global.invariant
[11:38] <zyga> pedronis: how do those sound to you?
[11:42] <pedronis> zyga: I'm thinking, I'm actually starting to think that for most of them the problem is a bit self-inflicted
[11:48] <zyga> pedronis: because they have before/after parts?
[11:48]  * zyga probably doesn't follow
[11:49] <pedronis> no, because it's not clear why we need most of them on PATH, they aren't used enough to justify that and the naming problem it creates
[11:50] <zyga> pedronis: they are on PATH so that they do not require sourcing via $TESTSLIB
[11:50] <zyga> in the past we had functions that were bad for other reasons
[11:50] <pedronis> what it has to do with sourcing
[11:51] <zyga> but required sourcing and this was tedious
[11:51] <zyga> ah, because they were functions and not on path, you had to get them somehow
[11:51] <pedronis> these are not functions
[11:51] <zyga> right
[11:51] <pedronis> also as I said, the tedious argument doesn't apply to many of them
[11:51] <pedronis> they are not used enough to make it a good reason
[11:51] <zyga> sure but some are super common, are you suggesting to drop them from path/
[11:51] <pstolowski> i think part of the reason they are in PATH is to make them usable to debug tests easily when in spread shell
[11:51] <zyga> oh, that's useful as well
[11:51]  * zyga didn't think about that
[11:52] <zyga> you can paste stuff from a test and it mostly works
[11:52] <zyga> (depending on how much you paste)
[11:53] <pedronis> pstolowski: again, I don't thinkt that argument applies equally
[11:53] <pedronis> to all of them
[11:53] <zyga> I don't see a problem with them being on path
[11:54] <zyga> testing.foo is a good solution if we need to have unique prefix
[11:54] <pstolowski> yes. i'm not even too concerned about testing.not tbh, it's just a prefix
[11:57] <pedronis> at some we can't start to explain that we did something to avoid tedious, and then circle back there, testing.negate is fairly tedious
[11:57] <pedronis> tbh
[11:58] <zyga> pedronis: not is not tedious :)
[11:58] <pedronis> exactly
[11:58] <zyga> pedronis: but importing something or $TESTSLIB/tools/not is also a bit tedious
[11:58] <zyga> but not might be a special case
[11:58] <pedronis> my point is that I don't trying to find a solution that works for all of them
[11:58] <pedronis> is a goal
[11:58] <zyga> as it's super short and small and frankly not related to snapd
[11:58] <zyga> I think handling session-tool and retry-tool should be the goal
[11:59] <zyga> as those are used fairly often
[11:59] <zyga> the rest can be another class that doesn't need the same solution
[12:00] <pedronis> also shellcheck is not helping here
[12:00] <zyga> in which sense?
[12:01] <pedronis> that it forces quotes, I understand where it comes from
[12:01] <pedronis> but sometimes you know what is in your env var
[12:02] <zyga> one more idea is to multiplex everything through one tool that is on path
[12:03] <zyga> snapd-testing ...
[12:03] <zyga> snapd-test-helper ... or whatever we name it
[12:03] <pedronis> that might be part of the solution
[12:03] <zyga> then it's one item on path and pretty easy to even handle migrations
[12:03] <pstolowski> yes that's an interesting idea
[12:03] <zyga> (assuming we migrated to the tool in the first place)
[12:04] <zyga> we could even call it
[12:04] <zyga> "the-tool"
[12:04] <zyga> except that's for core 20
[12:04] <pedronis> no
[12:04] <zyga> I was totally kidding :)
[12:04] <zyga> testctl sounds like systemd thing
[12:05] <zyga> though "testctl foo" could invoke "testctl-$foo" so we'd have a simple way to use various languages (like we do now)
[12:05] <zyga> so I kind of like that more and more
[12:06] <zyga> and the rest would not need to be on path eventually
[12:09]  * zyga is surprised
[12:09] <zyga> -.mount unit changed on disk https://www.irccloud.com/pastebin/oVaMhye7/
[12:09] <zyga> how is this even possible?!?
[12:09] <zyga> mborzecki: ^ any ideas?
[12:10] <zyga> ah, we modify fstab
[12:10] <zyga> fun
[12:10] <zyga> fixed now
[12:11] <mborzecki> zyga: yup, the test touches fstab
[12:11] <mborzecki> and -.mount is autogenerated
[12:12] <zyga> yeah
[12:12] <zyga> another one from another test
[12:12] <zyga> rtkit-daemon.service changed on disk https://www.irccloud.com/pastebin/JCg4YEkc/
[12:12] <zyga> the test installs/removes that
[12:20] <zyga> pedronis: do you have a feeling on what to do with test names then?
[12:20] <zyga> pedronis: which way do we go
[12:21] <pedronis> not yet
[12:21] <zyga> s/test names/test tool names/
[12:21] <zyga> ok
[12:21] <zyga> I'm happy to apply the change, when you make up your mind
[12:21] <zyga> I think we could also have a two-tier system, where some rarely used tools can have different properties
[12:22] <zyga> as some are indeed used a few times in the entire project
[12:22] <zyga> cachio: is the ubuntu 16.04-32 (note -32) image using EFI?
[12:23] <cachio> zyga, it supports uefi, not really sure if it is using it, I suppose that yes
[12:23] <zyga> ok
[12:23] <zyga> I think it boots in legacy mode
[12:23] <zyga> but that's fine
[12:24] <zyga> I was just curious
[12:24] <pedronis> zyga: when do you want to discuss refresh awareness, tomorrow morning after the desktop meeting?
[12:24] <cachio> zyga, we are not enabling any security feature, so by default iirc the systems use the legacy mode
[12:24] <zyga> pedronis: that sounds great
[12:24] <zyga> pedronis: I will push all my changes by then
[12:25] <zyga> pedronis: I took a small detour to fix various random issues I ran into but test coverage is close to being good now and I still have a few more patches to send
[12:25] <cachio> zyga, but it is managed by the gce hypervisor and there is not details in the docs about  it
[12:25] <zyga> cachio: ok, I guess it's uncommon to use 32 bit systems so maybe they don't boot them with uefi
[12:25] <cachio> zyga, just few line explaining the high level
[12:25] <zyga> cachio: I only noticed because boot/efi was missing
[12:28] <pstolowski> cachio: hi! could you take a look at https://github.com/snapcore/snapd/pull/8533 ? also updated #8710
[12:28] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[12:28] <mup> PR #8710: tests: spread test for preseeding in lxd container (3/3) <Preseeding 🍞> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8710>
[12:28] <cachio> pstolowski, sure
[12:32] <zyga> pstolowski: do you need any reviews for the preseeding changes?
[12:33] <jdstrand> mvo: hey, fyi I approved PR 8706
[12:33] <mup> PR #8706: interfaces/serial-port: add NXP SC16IS7xx (ttySCX) to allowed devices <Created by tsunghanliu> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8706>
[12:33] <zyga> jdstrand: \o/
[12:34] <jdstrand> mvo: I looked for another PR for it against 2.45.1 but didn't see it
[12:34] <zyga> jdstrand: if you are doing reviews, could you look at the /usr/share/doc interface again? It has +2 and just needs your final ack
[12:34] <zyga> nothing changed wrt permissions
[12:34] <jdstrand> zyga: heh, yes. that was the next one
[12:34] <zyga> super!
[12:35] <zyga> fedora 32 PR is almost entirely there, just one test queued and it will be entirely green
[12:35] <zyga> bringing average green levels up by a large margin
[12:36] <cachio> pstolowski, I left few comments
[12:41] <zyga> brb
[12:44] <zyga> re
[12:45] <cachio> mvo, hey, https://paste.ubuntu.com/p/hFFjC3Nwj3/
[12:45] <cachio> I see this error to build
[12:45] <cachio> mvo, is any dep missing?
[12:48] <mup> PR core18#154 closed: Test timezone contents and symlink <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core18/pull/154>
[12:49] <mup> PR core20#70 closed: Fix localtime <Created by xnox> <Merged by mvo5> <https://github.com/snapcore/core20/pull/70>
[12:50] <mvo> cachio: hm, is sbuild installed ?
[12:52] <cachio> mvo, yes
[12:52] <pstolowski> cachio: ty
[12:52] <cachio> pstolowski, reviewing the other one
[12:54] <zyga> mvo: can you please force merge https://github.com/snapcore/snapd/pull/8693 - it failed on a snap run --strace timeout that's random and known
[12:54] <mup> PR #8693: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8693>
[12:54] <zyga> and I'd like to avoid an hour of testing xenial again, it's not related to the PR
[12:57] <mup> PR snapd#8693 closed: tests: add fedora 32 to spread.yaml <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8693>
[12:57] <zyga> \o/
[12:58] <cachio> yesss
[12:58] <zyga> thanks!
[12:59] <mup> PR snapd#8751 opened: tests: reload systemd after editing /etc/fstab <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8751>
[12:59] <mup> PR snapd#8752 opened: tests: reload systemd after removing pulseaudio <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8752>
[12:59] <zyga> standup!
[13:22] <mvo> cachio: please try installing "schroot"
[13:26] <zyga> not sure how you work but using a pair of laptops to run tests in one checkout while another is busy editing works for me
[13:40] <roadmr> I use a hand-cranked OLPC to ssh into an old mainframe in the basement I got from ebay
[13:41] <ogra> only works if you have kids to operate the crank, no ?
[13:42]  * cmatsuoka looks in ebay for a new basement
[13:42] <zyga> haha
[13:42] <mup> PR snapd#8753 opened: tests: reload systemd --user for root, if present <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8753>
[13:42] <zyga> cmatsuoka: buy two
[13:42] <zyga> ogra: do you have any music equipment?
[13:43] <ogra> zyga, do you mean soundcards (a few) or instruments (none) ?
[13:43] <zyga> midi synth
[13:43] <roadmr> ogra: right, so I have the kid crank it for a while, then work a while, then cranking break... and so on
[13:43] <ogra> nah ... but i guess one of the soundcards i have could do midi stuff
[13:44] <cmatsuoka> zyga: I'm considering a korg wavestate, but it's not available here yet
[13:44] <zyga> cmatsuoka: I'd like to find either an MT32 for some dos games or SC-D70 for some other dos games
[13:45] <mup> PR snapd#8750 closed: tests: improve oom-vitality tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8750>
[13:45] <cmatsuoka> zyga: the canvas sounds much better
[13:45] <zyga> it's also a bit more modern, has pc style AC input and even usb port
[13:45] <zyga> but only available in japan
[13:46] <zyga> so.... bummer
[13:46] <cmatsuoka> zyga: a friend of mine had both in the 90s, but I doubt they're still in working conditions
[13:46] <zyga> there are some on ebay, they seem to be in great shape
[13:46] <zyga> the only thing that may need replacement is a CR32 battery
[13:46] <cmatsuoka> I mean, the canvas was the SC-55 I think
[13:47] <pstolowski> cachio: updated #8533
[13:47] <mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[13:47] <zyga> cmatsuoka: ah, that's a good unit as well
[13:48] <zyga> I guess anything after SC-55 is good for games that used general midi, not the preceeding mt32 de-facto standard
[13:49] <ogra> my biggest soundcard i have is a Xonar DX virtuoso 100 ...
[13:49] <mup> PR snapd#8742 closed: snap-mgmt: perform cleanup of user services (2.45) <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8742>
[13:49] <ogra> but my focus was more on high bitrate playback and surround for gaming
[13:49] <ogra> less on producing music
[13:50] <cmatsuoka> zyga: I specifically remember that Sierra's Dagger of Amon Ra sounded so much better in it compared to Adlib/Sound Blaster, except for the archeologist song which only played in the Sound Blaster
[13:50] <zyga> huh? :)
[13:51] <zyga> I find it fascinating that each game was composed for a particular hardware stack as all the midi synthesizers were not really backwards compatible
[13:51] <cmatsuoka> zyga: https://en.wikipedia.org/wiki/The_Dagger_of_Amon_Ra
[13:51] <zyga> so you may need a few to have the correct unit for each game
[13:52] <zyga> I never played it, looks interesting (all sierra games are)
[13:52] <zyga> https://www.gog.com/game/the_dagger_of_amon_ra :)
[13:53] <cmatsuoka> it looks reasonably priced :)
[13:53] <zyga> for me the price is ~3 euro
[13:54] <cmatsuoka> listed as 3.39 euro here
[13:54] <zyga> yep
[13:54] <mup> PR snapd#8667 closed: interfaces/fwupd: allow bind mount to /boot on core <:secret: Needs security review> <Security-High> <Created by woodrow-shen> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8667>
[13:54] <zyga> you can easily extract it with innoextract and play on any system
[13:56] <ogra> there is also https://snapcraft.io/gog-galaxy-wine
[13:57] <zyga> ogra: nah, too many layers: )
[13:57] <ogra> heh
[13:57] <zyga> I'm somewhat sceptical about snaps like that
[13:57] <zyga> would be a totally different story if it was endorsed by gog
[13:58] <ogra> well, make diddledan talk them into endorsing it 😉
[14:01] <zyga> I think that won't be easy
[14:01] <zyga> gog is a huge company now
[14:01] <zyga> I doublt they would +1 it
[14:01] <zyga> *doubt
[14:01] <ogra> why ? it is spreading their stuff
[14:01] <zyga> quality and support
[14:01]  * ogra taps foot ... why are LP builders so slow today ...
[14:01] <ogra> i need an s390x or ppc64el ... they are always first while the other arches still "pending build"
[14:07] <roadmr> mainframe in the basement ;)
[14:08] <ogra> 😄
[14:08] <zyga> brb for lunch
[14:19] <mup> PR snapd#8709 closed: cmd/snap-preseed, systemd: fix handling of fuse.squashfuse when preseeding (2/3) <Preseeding 🍞> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8709>
[14:36] <jdstrand> mvo, pedronis, zyga: hey, so now that the security team is ramping up the people that can help (eg, amurray and emitorino, though currently things ultimately go through me still), I think it would be better to use the 'Needs security review' tag going forward. In this manner, a member of our team can go to
[14:36] <jdstrand> https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+review-requested%3A%40me+label%3A%22%3Asecret%3A+Needs+security+review%22
[14:36] <zyga> +1
[14:36] <zyga> sounds great to me
[14:36] <pedronis> jdstrand: works for me
[14:36] <jdstrand> mvo, pedronis: and see what is what. I'm not sure why that tag as a non-ascii symbol in it...
[14:37] <jdstrand> mvo, pedronis: if people forget and just add me, I'll add that tag
[14:37] <jdstrand> so we can all work together on it
[14:37]  * jdstrand does that now
[14:37] <jdstrand> ijohnson: you probably are interested in that too ^
[14:38]  * mvo is in a meeting
[14:39] <jdstrand> emitorino: fyi, https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+review-requested%3A%40me+label%3A%22%3Asecret%3A+Needs+security+review%22 (though you don't need to do anything with that now)
[14:39] <emitorino> ack jdstrand
[14:39] <mvo> jdstrand: I can remove the strange non-ascii thing in there if you want
[14:40] <pedronis> jdstrand: there are some PRs that are changes request by you, don't know if you want the tag on those, or you will track them yourself given you started the conversations
[14:40] <jdstrand> mvo:
[14:40] <jdstrand> mvo: please if you don't mind :)
[14:40] <jdstrand> pedronis: I will continue to track those myself
[14:40] <jdstrand> I think it is on the person to track things they requested changes on
[14:40] <pedronis> jdstrand: ok
[14:41] <jdstrand> I need to step away for a bit, but will read backscroll
[14:41] <mvo> jdstrand: removed
[14:42] <mvo> zyga: do you mind if I remove the per-user mount ns tag?
[14:42] <zyga> not at all
[14:42] <zyga> let's nuke it
[14:43] <jdstrand> emitorino: here is a better link: https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+label%3A%22Needs+security+review%22+ (cc amurray)
[14:43] <jdstrand> (that will still show open ones where we've commented)
[14:43] <emitorino> jdstrand, yeah figured out the label, thanks anyway!
[14:44] <jdstrand> emitorino: you might want to peruse what I've commented on today for questions for tomorrow, but only if you have time
[14:44] <emitorino> sure thing jdstrand, thanks!
[14:44] <mup> PR snapd#8754 opened: tests: add missing dependencies needed for sbuild test on debian <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8754>
[14:46] <pedronis> jdstrand: emitorino: we will also still use Security-High for things that have some urgence, we'll give things both tags I suppose (cc mvo)
[14:46] <mvo> +1
[14:46] <mvo> yeah
[14:46] <mvo> mostly added the other one to avoid accidents
[14:47] <mvo> where stuff gets merged too early
[14:47] <mvo> (as hapend with the serial port fix)
[14:47] <pedronis> jdstrand: emitorino: also as usual things that have a milestone are usually higher priorities than ones that don't
[14:47] <zyga> mvo: we have green ticks on github now :)
[14:48] <mvo> zyga: we do - it's magic!
[14:48] <emitorino> ack pedronis
[14:48] <niemeyer> issue #123
[14:48] <mup> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
[14:49] <niemeyer> mup_: You there?
[14:49] <mup_> niemeyer: I apologize, but I'm pretty strict about only responding to known commands.
[14:49] <niemeyer> mup_: issue #123
[14:49] <mup> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
[14:49] <mup_> niemeyer: PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
[14:50] <niemeyer> It's not overhearing..
[14:50] <niemeyer> Ah, I know why
[14:51] <niemeyer> issue #123
[14:51] <mup_> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
[14:51] <mup> PR #123: partition/bootloader_grub.go: pass the correct grub path to newBootLoader() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/123>
[14:51] <niemeyer> issue #200
[14:51] <mup_> PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>
[14:51] <mup> PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>
[14:52] <niemeyer> issue #8558
[14:52] <mup_> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[14:52] <mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
[14:52] <niemeyer> Sorry, will stop now :)
[14:53] <pedronis> :)
[14:54] <mup> PR snapd#8578 closed: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>
[14:54] <mup_> PR #8578: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>
[14:54] <mup> PR #8578: interfaces: add system-packages-doc interface <Needs security review> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8578>
[14:54] <zyga> niemeyer: while you are looking, mup had a bug where it would give a link to "issue" vs "issues" (or the other way around)
[14:54] <akik> kernel/os snaps? weren't snaps for application containment?
[14:54] <zyga> niemeyer: not sure if you noticed or if you fixed that now
[14:54] <niemeyer> zyga: Should be fixed on the new instance
[14:54] <zyga> ah, superb :)
[14:54] <niemeyer> There are several other changes as well, big and small
[14:54] <zyga> akik: kernel snaps are used on core devices where snapd manages the entire OS
[14:54] <mvo> yeah, nice!
[14:54] <mvo> thanks niemeyer !
[14:54] <niemeyer> mvo: np, sorry it took a while
[14:55] <akik> zyga: core devices?
[14:55] <zyga> akik: there are other snap types used there, that are not seen on regular (non-iot) systems
[14:55] <zyga> akik: ubuntu core is a full OS for IOT systems
[14:55] <akik> zyga: is that only for ubuntu core then?
[14:56] <zyga> akik: we use "core" to describe them, vs "classic" for all other systems with other package managers and typical behavior
[14:56] <ogra> akik, snap is a fully fledged package format, you can package services (daemons), cli apps, kernels, bootloaders and desktop apps
[14:56] <zyga> akik: kernel snaps? yes, they are only used for core devices
[14:56] <zyga> akik: a core device has at minimum, a kernel snap, a base snap used for booting (e.g. core20) and a gadget snap
[14:56] <zyga> akik: and any number of application snaps
[14:56] <ogra> ubuntu core is completely built from snap packages, no apt, deb, dfn, rpm support on them
[14:57] <zyga> jdstrand: will review-tools need changes to know about new interfaces? (like system-packages-doc) or is that automatic?
[14:59] <zyga> akik: you can use it on a raspberry pi, for example
[14:59] <zyga> akik: if you are not familiar that is a great way to learn
[15:00] <akik> zyga: i'm a classic kinda guy
[15:01] <ogra> you dont know what you'Re missing then :)
[15:02] <akik> i don't want to see the linux landscape fragment any more
[15:03] <ogra> fragment ?
[15:04] <ogra> i doubt anything like core exists anywhere else, not sure what would be fragmented here
[15:05] <akik> kernel/libs/desktop environments/application containers
[15:05] <akik> that's what i meant with fragmentation
[15:05] <akik> somebody might not want to run snaps if they are slower to start
[15:05]  * zyga really goes for lunch
[15:06] <zyga> akik: it's temporary, we'll get it fixed
[15:06] <akik> heh
[15:06] <akik> doubt it
[15:06] <akik> oh that slow start?
[15:06] <akik> sorry i understood wrong
[15:06] <zyga> ?
[15:06] <akik> i thought you meant fixing the fragmentation
[15:07] <ogra> well, thats not up to us
[15:07] <ogra> when we started doing snaps in 2014 nothing like this existed
[15:07] <ogra> you cant blame us for innovating really
[15:07] <zyga> I'm unsure what kind of fragmentation you are talking about
[15:07] <zyga> that different people do different things?
[15:07] <akik> kernel/libs/desktop environments/application containers
[15:08] <akik> some company might package their application only to some certain format
[15:08] <zyga> what about them
[15:08] <akik> that's fragmentation
[15:08] <zyga> I still don't get it
[15:08] <ogra> akik, but thats not our fault !
[15:08] <zyga> that desktop environments exists?
[15:08] <zyga> *exist
[15:08] <zyga> or that libraries exist?
[15:08] <zyga> what is fragmented?
[15:09] <ogra> probably kernels 🙂
[15:09]  * zyga would like to know what akik meant
[15:09] <akik> that some application might not run if the environment that is available does not match what the application needs
[15:09] <zyga> akik: can you give me an example please?
[15:11] <akik> vendor a packages the app in a snap only. the user is not able to run the snap
[15:11] <ogra> then we need to fix that for the user
[15:11] <ogra> and he should tell us ... file a bug etc
[15:12] <ogra> i dont see what this has to do with fragmentation though
[15:12] <akik> different distros have different kernels and library versions
[15:13] <ogra> yes, and snapd takes that into account for most of them
[15:13] <akik> yes this was just about fragmentation
[15:13] <ogra> take a look at the distro list over therehttps://snapcraft.io/zoom-client
[15:13] <ogra>  bah
[15:16] <ogra> https://snapcraft.io/zoom-client
[15:16] <akik> fragmentation regarding application containers means that there are snap, flatpak, appimage
[15:16] <ogra> does allowing all of these different distros to use the same app really look like fragmentation ?
[15:16] <akik> ogra: i didn't mean snap when talking about fragmentation
[15:16] <ogra> note that these 55 different distros are not all of the,
[15:16] <ogra> them
[15:16] <akik> i meant these -> kernel/libs/desktop environments/application containers
[15:16] <akik> the 3 first ones
[15:16] <ogra> well, you wont use a kernel or gadget snap outside of an ubuntu core system
[15:17] <ogra> snaps have a builtin self-test and roll-back mechanism, they guarantee you that your kernel automatically goes back to the former version if an upgrade fails, your new version causes an OOPS etc etc ... this is very unique but utterly needed in IoT, embedded and industrial
[15:18] <ogra> if you'D use a deb you would have to send out a technician to your 3G tower in the woods to fix the device that hung with a kernel OOPS
[15:18] <ogra> kernl snaps solve that elegantly
[15:18] <ogra> there is no "fragmentation" here it is innovation 😉
[15:20] <ogra> and if you mean missing kernel security features that cause distros to not adopt snapd to have snap support ... well, thats on them ... there isnt much we can do about, if you look at the zoom-client link i gave you above, there are 55 different distros listed that *are* able to install and use it
[15:21] <ogra> if there are any that can not people like zyga and his team will happily help the distro devs to make it work
[15:23] <ogra> actually ... looking at that distro list makes me wonder ... what the heck is "windowsfx 10"
[15:26] <pedronis> zyga: the new interface will need to be documented
[15:40] <zyga> re
[15:40] <zyga> pedronis: good point, I'll do it now
[15:41] <zyga> ackk: note that snap isolates you from everything but kernel and services and their IPC api
[15:41] <zyga> akik: ^
[15:41] <zyga> sorry ack
[15:41] <zyga> tab eager complete ;)
[15:41] <ogra> use hexchat !
[15:42] <zyga> akik: so no matter what libs you are using, you should be able to use the snap
[15:42] <zyga> akik: if you think this is fragmentation, package an app for 4-5 distributions
[15:42] <zyga> then after a month, do an update
[15:42] <zyga> that's fragmentation
[15:43] <akik> yes that's what i meant
[15:43] <zyga> akik: I see now
[15:43] <zyga> "akik> ogra: i didn't mean snap when talking about fragmentation"
[15:45] <ogra> well, hard to avoid ...
[15:45] <ogra> different distros (need to) stabilize on top of different releases of software ...
[15:46] <mup> PR snapcraft#3145 closed: cli: migrate upload and release to new channel-map <maintenance> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3145>
[15:47] <ogra> often driven by the distros purpose (my distro only wants to use LTS upstream kernels because enterprises use it ... your distro being a desktop focused thing probably wants the very latest cool kernel graphics improvements so you pick the latest tip kernel)
[15:49] <ogra> i remember that when we started in 2004 there were not even upstream release schedules for most things ... Xorg, kernel, gnome ... all released on their own schedules and things were massively varying across distros ... that has changed over the years
[15:49] <ogra> so it got a lot better already ...
[15:55]  * zyga ran back to the office
[15:55] <zyga> my kids are behaving like crazy today
[16:00] <zyga> degville: hi, I sketched a small document for the new interface: https://forum.snapcraft.io/t/the-system-packages-doc-interface/17788
[16:00] <zyga> advise and comments are appreciated
[16:13] <mup> PR snapd#8755 opened: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>
[16:13]  * cachio lunch
[16:37]  * zyga cachio: https://github.com/snapcore/snapd/pull/8755#pullrequestreview-419410456 (first comment is the one I'm interested in)
[16:37] <mup> PR #8755: tests: fix classic ubuntu core transition auth <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8755>
[16:48] <jdstrand> zyga: yes, the review-tools need a change (and snappy-debug). it is already on my todo
[16:49] <jdstrand> cc emitorino ^
[16:51] <zyga> jdstrand: ack
[16:54] <jdstrand> pedronis: yep
[16:54] <jdstrand> pedronis: (security high and milestone)
[16:54] <pedronis> jdstrand: ack
[16:54] <jdstrand> it would be nice if the milestone was more prominent, but easy to see once know what to look for
[16:54] <jdstrand> fyi, there are no milestoned PRs waiting on us now
[16:55] <jdstrand> I'm continuing to go through the list though
[17:17] <mup> PR snapcraft#3146 closed: build providers: snap sw to channels if injecting <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3146>
[18:02] <mup> PR snapd#8756 opened: tests: skip interfaces-openvswitch for centos 8 in nightly suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8756>
[18:07] <mup> PR snapd#8691 closed: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[18:12] <mup> PR snapd#8691 opened: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[19:06]  * cachio afk
[19:24]  * zyga EODs
[19:31] <zyga> pedronis: https://github.com/snapcore/snapd/pull/8691#pullrequestreview-419542230
[19:31] <mup> PR #8691: tests/lib/bin: a TODO to improve the naming and uniformity of utilities <Skip spread> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8691>
[19:31]  * zyga really EODs :)
[20:18] <mup> PR snapd#8533 closed: image, tests: core18 early config <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8533>
[20:55] <jdstrand> ijohnson (cc emitorino): fyi, https://forum.snapcraft.io/t/nvme-block-devices-support/17736/3
[20:55] <jdstrand> ijohnson: I'm also reviewing the PR and will comment there as well
[21:00] <ijohnson> Nice thanks jdstrand also FYI I'm off today/tomorrow
[21:00]  * ijohnson will remember to silence IRC notifications next time :-) 
[21:00] <jdstrand> ijohnson: enjoy your time off! you now have a short story to read :)
[21:01] <jdstrand> ijohnson: not sure how much you like reading short stories on deep technical debugging :P
[21:01] <jdstrand> ijohnson: sorry for the interuption
[21:01] <diddledan> I think we should ping ijohnson, too ;-p
[21:43] <mup> PR snapd#8751 closed: tests: reload systemd after editing /etc/fstab <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8751>
[21:43] <mup> PR snapd#8752 closed: tests: reload systemd after removing pulseaudio <Test Robustness> <Created by zyga> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8752>
[21:43] <mup> PR snapd#8754 closed: tests: add missing dependencies needed for sbuild test on debian <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8754>