[06:07] <mborzecki> morning
[06:25] <zyga> goood morning
[06:25]  * zyga is back after the long weekend
[06:57] <mardy> hi all :-)
[06:58] <mardy> mborzecki: do you think I can merge https://github.com/snapcore/snapd/pull/10245? I cannot understand if the spread failures are related to my changes or not
[06:58] <mup> PR #10245: cmd/snap: exit normally if "snap changes" has no changes <Created by mardy> <https://github.com/snapcore/snapd/pull/10245>
[07:00] <mborzecki> mardy: hey, let me look at the spread logs
[07:01] <mborzecki> mardy: looks like it was store issues, so i've restarted the tests workflow
[07:02] <pstolowski> morning
[07:02] <mborzecki> mardy: oh, and it's only possible to merge if the required workflows are successful
[07:02] <mborzecki> pstolowski: hey
[07:24] <mup> PR snapd#10250 opened: interfaces/camera: allow devices in /sys/devices/platform/**/usb* <Created by tsunghanliu> <https://github.com/snapcore/snapd/pull/10250>
[07:36] <zyga> hey pstolowski, mborzecki
[07:36] <mborzecki> zyga: hey, back from vacation?
[07:36] <zyga> yep
[07:36] <pstolowski> hey zyga
[07:36] <zyga> perfect for the one day of work left :D
[07:41] <mborzecki> haha, yeah friday is a good choice of a day to start your work week with
[07:41] <mardy> degville: hi, I'm not sure you are the right person for this topic, but after reading https://snapcraft.io/docs/base-snaps it's still not clear to me what core and core16 are (and how they differ)
[07:46] <zyga> mardy core and core16 are the same
[07:46] <zyga> core is the initial base snap
[07:46] <zyga> (nee ubuntu-core)
[07:46] <zyga> core16 never happened, it was supposed to be core without snapd
[07:46] <zyga> like core18 was
[07:48] <mardy> zyga: mmm... thanks. https://snapcraft.io/docs/glossary explains them a bit better, but says that core16 is still in development (which somehow sounds to me it's something new)
[07:49] <zyga> it's not really
[07:49] <zyga> not a priority
[07:49] <zyga> core is good enough
[07:49] <zyga> core16 may never happen
[07:50] <mardy> and core18, does it ship snapd?
[07:50] <zyga> nope
[07:50] <zyga> that's the entire point
[07:50] <zyga> snapd is a separate snap
[07:50] <zyga> so many possible bases can use it
[07:51] <mardy> mmm... so, the reason why "core" ships snapd, is that because "core" is more than a base snap, but rather a complete OS?
[07:51] <mardy> I hope I'm not shaming myself with silly questions :-D
[07:52] <zyga> core is the initial base snap
[07:52] <zyga> so it was easier to start with one image that has everything except for the kernel and bootloader
[07:52] <zyga> over time, it was clear this is not maintainable
[07:52] <zyga> so core18 was different
[07:52] <zyga> at the time we hoped to make core16 but we never managed to
[07:52] <zyga> (no time)
[07:53] <zyga> having core16 might have allowed us to transition everyone to base+snapd model and simplify some code
[07:53] <mardy> I see. So "core" is kind of not recommended anymore?
[07:53] <zyga> but this never happened and it would also require epochs to really work
[07:53] <zyga> and those were not implemented at the time
[07:53] <zyga> so no code/complexity saving was possible
[07:53] <zyga> core is just old, most people are much better off with core18 or core20
[07:53] <zyga> core is derived from ubuntu 16.04
[07:54] <mardy> got it, now it's more clear, thanks :-)
[07:55] <zyga> (epochs would allow us to remove support code from snapd and force everyone through a version of snapd that still supports both core and the new core16 and upgrade before going to a revision that would no longer understand core as a snap)
[07:55] <zyga> cheers :)
[07:55] <zyga> it's possible now but I don't think it's realistically going to happen
[08:13] <degville> mardy: I'm definitely the right person, and it's great you're bringing these things up - it's really valuable. I'll try and clear up the core core16 confusion. It's actually something I'm touching on with the end of standard support for 16.04, but it's never been clear.
[08:13] <zyga> hey degville :-)
[08:13] <degville> hello zyga!! lovely to see you! :)
[08:15] <zyga> it's been a while :)
[08:19] <mardy> mborzecki: after re-running the CI, more tests are passing, but threre's still some required test failing. Should I just keep retrying?
[08:21] <mardy> https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/25434/signedlogcontent/70
[08:22] <mborzecki> mardy: nah, it looks ok, that failure in snap-advise is related to snap store returning 403 unexpectedly
[08:23] <mborzecki> mardy: i've pinged mvo and pedronis to land the PR, they are the only ones with github permissions who can land prs into master when required systems failed the test workflow
[08:31] <mardy> mborzecki: thanks
[08:33] <mardy> one more question: is "privileged interface" a synonym for "interface with auto-connect=no"?
[08:36] <pedronis> mborzecki: hi, should https://github.com/snapcore/snapd/pull/9005 be closed?
[08:36] <mup> PR #9005: boot: support setting extra command line argument, bootloader interface tweaks <UC20> <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/9005>
[08:37] <mborzecki> pedronis: ah, thanks, i've closed it now
[08:37] <mardy> degville: when I'm in https://snapcraft.io/docs/process-for-aliases-auto-connections-and-tracks and click on the "@reviewers" link, I get to a 404. Is there a way to report such issues, or is it fine if I just ping you?
[08:39] <mup> PR snapd#9005 closed: boot: support setting extra command line argument, bootloader interface tweaks <UC20> <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/9005>
[08:40] <degville> mardy: it's absolutely fine to ping me. But (for reference), as everything's published on the forum, you can edit and write things directly my following the link to the forum post at the bottom. We don't typically have a formal process as I try to track edits.
[08:40] <degville> s/my/by
[08:42] <mardy> degville: ok, then I can try to fix this myself. Just I'm not sure what is the correct link for the reviewers group :-)
[08:43] <degville> mardy: I've fixed it. That's a weird one as it's forum-specific.
[08:44] <degville> mardy: updates can take a few minutes to propagate to the docs site, but it's done automatically.
[08:44] <mup> PR snapd#10245 closed: cmd/snap: exit normally if "snap changes" has no changes <Created by mardy> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/10245>
[08:56] <zyga> good morning mvo
[08:57] <mvo> good morning zyga !
[09:43] <mardy> pstolowski: Hi! Can you please re-review https://github.com/snapcore/snapd/pull/10242?
[09:43] <mup> PR #10242: overlord: fix errors reported by linter <Created by mardy> <https://github.com/snapcore/snapd/pull/10242>
[09:43] <pstolowski> mardy: sure
[09:46] <pstolowski> +1, thank you
[11:20] <mup> PR snapd#10226 closed: interfaces/udisks2: Allow access to the login manager via dbus <Created by alexmurray> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10226>
[11:23] <mardy> this is up for early feedback: https://github.com/snapcore/snapd/pull/10251
[11:23] <mup> PR #10251: interfaces/builtin: introduce raw-input interface <Created by mardy> <https://github.com/snapcore/snapd/pull/10251>
[11:24] <mardy> and to see if someone has any suggestion on which snap I could use as a starting point to test this interface
[11:25] <mup> PR snapd#10251 opened: interfaces/builtin: introduce raw-input interface <Created by mardy> <https://github.com/snapcore/snapd/pull/10251>
[12:10] <mup> PR snapd#10252 opened: boot: reseal given keys when the respective boot chain has changed <Needs Samuele review> <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10252>
[12:10] <mup> PR snapd#10253 opened: boot: helpers for manipulating current and good recovery systems list <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10253>
[12:29] <pstolowski> re
[12:30] <mup> PR snapd#10254 opened: [RFC] overlord/devicestate: tasks for creating recovery systems at runtime <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10254>
=== dob1_ is now known as dob1
[13:47] <mardy> it's me again :-) I've made a snap of libinput's debug-events tool, I installed it in --devmode, and I see these messages in the log: https://paste.ubuntu.com/p/QTTDvMrxmB/
[13:47] <mardy> I understand the last two, but why all the network ones?
[13:47] <mardy> are they really required, in order to talk to udevd?
[14:00] <mup> PR snapd#10250 closed: interfaces/camera: allow devices in /sys/devices/platform/**/usb* <Created by tsunghanliu> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/10250>
[14:15] <mup> PR snapd#10255 opened: tests/nested/core/core20-create-recovery: verify that recovery system can be created at runtime <Run nested> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/10255>
[15:05]  * cachio lunch
[16:42] <ijohnson> cachio: can you take a look at #10099 again when you have a chance?
[16:42] <mup> Bug #10099: paul: new changes from Debian require merging <Ubuntu:Fix Released by cjwatson> <https://launchpad.net/bugs/10099>
[16:42] <mup> PR #10099: tests/main/snapd-snap: build the snapd snap on all platforms with lxd <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10099>
[16:46] <mup> PR snapd#9477 closed: tests/lib/fakestore: some improvements for testing console-conf things <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9477>
[17:06] <mup> PR snapd#9396 closed: snapstate/check_snap: add snap_docker to shared system-usernames <Needs security review> <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9396>
[17:06] <mup> PR snapd#9701 closed: snapcraft.yaml: allow configuring the snapd snap build via dev options files <Needs Samuele review> <Skip spread> <⛔ Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/9701>
[17:14] <mup> PR snapcraft#3519 opened: requirements: correct setup.py install_requires and add tooling to freeze reqs <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3519>
[17:17] <cachio> ijohnson, left few questions there
[17:17] <ijohnson> cachio: thanks let me take a look
[17:18] <cachio> ijohnson, do we need also to run snapcraft clean?
[17:18] <cachio> from the project path
[17:18] <ijohnson> hmm, yeah probably not a bad idea to run snapcraft clean too
[17:19] <cachio> I mean, which is hte pwd when we run a command through defer
[17:19] <ijohnson> yeah let me think about this, I think the main reason I used $PROJECT_PATH as the pwd for tests.cleanup was because it's awkward to change dir in the command we use with `tests.cleanup`
[17:22] <cachio> let me make a quick test
[17:22] <cachio> to check that
[17:22] <cachio> I supose that just on restore is needed
[17:23] <cachio> I think the CD PROJ... needed is in restore
[17:24] <cachio> it is where we call tests.cleanup restore
[17:24] <cachio> there the deferred commands are executed
[17:25] <cachio> ijohnson, looking the code, I think we could avoid prepare and restore
[17:25] <cachio> it could be an improvement for tests cleanup
[19:06] <mup> PR snapd#10247 closed: tests: update spread url <Run nested> <Simple 😃> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10247>
[20:31] <mup> PR snapd#10256 opened: snapstate: do not allow installing the same snap revision via IntallPath <Created by mvo5> <https://github.com/snapcore/snapd/pull/10256>
[21:01] <mup> PR snapd#10257 opened: tests: remove old fedora systems from tests <Simple 😃> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/10257>