[01:02] <stgraber> sergiusens: around by any chance?
[01:05] <stgraber> ah, I think I may have figured out my issue
[01:18] <sergiusens> stgraber: I sort of am
[01:19] <stgraber> sergiusens: looks like I got confused by LP deciding to use the snapcraft deb when manually triggering builds, making me wonder wth was happening to my arm builds
[01:24] <sergiusens> stgraber: oh, there's an lp-build-snap snap that makes it easy to trigger if interested and LP has a bug where you MUST set the channel for core and snapcraft for the snap to be used.
[01:25] <stgraber> ah, interesting. We don't seem to have the issue when the builds are triggered by git commits though, will just have to keep in mind for when doing manual builds.
[01:26] <sergiusens> stgraber: vcs triggered builds dtrt
[01:27] <stgraber> got a link to the LP bug by any chance
[01:27] <stgraber> if not, I can go dig
[06:56] <zyga> good morning!
[06:56] <zyga> I'm off today, just need to do the paperwork
[07:21] <zyga> ok, paperwork done
=== pstolowski|afk is now known as pstolowski
[07:30] <pstolowski> morning
[07:41] <pedronis> pstolowski: hi, are you working today?
[07:52] <pstolowski> pedronis: yes
[07:53] <pstolowski> pedronis: thanks for udevmonitor stop PR, will review in a bit
[07:53] <pedronis> pstolowski: thx, was about to ask about that
[07:53] <pedronis> pstolowski: also I tried to land #6960, fixed some GetType issues but it seems to be red always for unrelated reasons :/
[07:55] <pstolowski> pedronis: uhm, thank you
[07:56] <pstolowski> i'm having a slow start today, switching ISP this morning and still having a technican here
[08:10] <zyga> Hey hey
[08:10] <zyga> I will do some reviews today
[08:11] <zyga> 7 hours more to go today
[08:14] <zyga> I will look at the race PR from pedronis now
[08:15] <pedronis> zyga: pstolowski will look at it
[08:15] <zyga> aha, it already has one review
[08:15] <zyga> good
[08:15] <zyga> I'm still interested, things like that are tricky and I could learn a thing or two
[08:16] <pedronis> zyga: not stopping you, 6959 is probably something that would be good to unblock
[08:16] <pstolowski> pedronis: +1 for 7018
[08:16] <zyga> pedronis: indeed, I'll look at that too
[08:24] <zyga> pedronis: question about https://github.com/snapcore/snapd/pull/7018/commits/3ff9725feb595f78d8bcbee0df3c621af9de6419
[08:25] <zyga> pedronis: is this where a thread will see the channel IO arriving but not yet see the value being set to "opinion"?
[08:25] <zyga> pedronis: or did I misunderstood it?
[08:25] <zyga> did I misunderstand*
[08:26] <pedronis> zyga: it fixing go test -race
[08:26] <pedronis> to be honest for those tests I mostly looked at making it happy
[08:27] <pedronis> sometimes tests get extra locking for free that make some things work even if they strictly shouldn't
[08:27] <pedronis> but those weren't that lucky
[08:28] <zyga> mmm, indeed
[08:40] <zyga> pedronis: reviewed, 7018, looking at the other oen
[08:40] <zyga> *one
[08:41] <cjwatson> sergiusens: Could you explain the bug you're describing here?  AFAIK you don't have to explicitly set channels if you're using a base, unless you're using obsolete API methods
[08:45] <pedronis> @zyga: Wait exists basically only for tests
[08:45] <zyga> aha
[09:04] <sergiusens> cjwatson this was the question I asked in Lyon. If channel setting is now longer required that is great and maybe stgraber was using the obsolete API. Does the launchpad webui use the new API?
[09:07] <cjwatson> sergiusens: There's much confusion because there are various different paths (because bases were retrofitted).  The Launchpad web UI uses the new interfaces *unless* you explicitly select architectures
[09:09] <cjwatson> I have a branch in progress to fix that exception that I started in Lyon, so I should probably finish that off
[09:10] <cjwatson> That branch will mean that if you explicitly select architectures then they get passed through and intersected with any other applicable constraints
[10:11] <pedronis> Chipaca: hi, did that comment pointer help?
[10:14] <Chipaca> pedronis: i think so yes
[10:15] <pedronis> pstolowski: 6960 is green
[10:16] <pstolowski> pedronis: great, ty, landing
[11:38] <cjwatson> sergiusens: OK, https://code.launchpad.net/~cjwatson/launchpad/snap-request-build-explicit-arch-consistency/+merge/369162 should fix this weirdness (just FYI, not asking you to review it)
[11:38] <cjwatson> stgraber: ^-
[11:58] <Chipaca> pedronis_: are we done wrt simplifying retries?
[11:59] <Chipaca> pedronis: are we done wrt simplifying retries?
[11:59] <Chipaca> :)
[12:00] <pedronis> Chipaca: I cannot post anymore as pedronis_ and then it's a dance
[12:01] <pedronis> Chipaca: you mean https://trello.com/c/9GcOfcEG/32-improvement-to-retries-and-request-patterns-for-store ?
[12:02] <Chipaca> pedronis: I meanthttps://trello.com/c/e5wx44jZ/151-simplify-our-retries-for-auto-refreshes-so-not-to-have-fleet-stampeding-at-regular-intervals-on-store-errors
[12:02] <Chipaca> pedronis: but i think i must've been mistaken about it being in Doing
[12:03] <pedronis> Chipaca: but yes, there is still work in that area, if nothing else because as I mentioned retry.v1 works a bit differently than we though it seems and our current param are a bit silly
[12:04] <pedronis> therefore
[12:05] <Chipaca> pedronis: right, but that's the WIP, isn't it?
[12:06] <pedronis> yes
[12:06] <pedronis> if you mean that's why the card I referenced is still in WIP
[12:06] <abeato> pedronis, hey, I am seeing these errors lately: "udevmon.go:146: udev event error: Unable to parse uevent, err: no buffer space available". Is it worth opening a bug?
[12:06] <pedronis> abeato: yes, please
[12:06] <pedronis> ^ pstolowski
[12:07] <abeato> it looks like the size is one page
[12:07] <abeato> ok, let me do that
[12:07] <abeato> (the buffer size)
[12:10] <abeato> pedronis, pstolowski https://bugs.launchpad.net/snapd/+bug/1833707
[12:13] <pstolowski> abeato: interesting, thank you
[12:14] <pstolowski> abeato: when you see it happening, can you also run 'udevadm monitor -p' and capture corresponding event(s)?
[12:15] <abeato> pstolowski, sure I can do that
[12:15] <abeato> pstolowski, also, I actually have run in this sort of issues long time ago. The size for these buffers tend to be huge: https://github.com/systemd/systemd/blob/master/src/udev/udevadm-monitor.c#L73
[12:16] <abeato> 128*1024*1024
[12:17] <pstolowski> abeato: oh wow, indeed. fwtw the go module we use for this is from 3rd party
[12:17] <abeato> I remember of an issue in Android init related to udev rx buffer size in the UT times :D
[12:18] <pstolowski> abeato: thanks, we can patch it locally quickly since we have own copy of the module, and i'll also report this upstream
[12:18] <abeato> pstolowski, awesome, thanks!
[13:01] <pedronis> Chipaca: standup?
[13:01] <Chipaca> ye
[13:25] <stgraber> cjwatson: thanks!
[14:07] <zyga> online again, will do another review
[14:55]  * cachio lunch
[15:08]  * Chipaca weeps at today's xkcd
[16:15] <albertosottile> jdstrand: thanks for granting us the syncplay-server alias. Just a quick question: do I have to update our snapcraft recipe or is the alias automatically installed now that it’s granted?
[16:19] <jdstrand> albertosottile: you're welcome! you don't have to do anything. I'm stepping away for a little bit but feel free to ask other questions if you have them and I'll answer when I get back
=== pstolowski is now known as pstolowski|afk
[17:56] <popey_> ogra: ok, I have forked your qemu-virgil, added a vm to the snap and updated to core 18, and even after connecting kvm, it refuses to work, permission denied on KVM kernel module
[17:56] <popey_> jdstrand: is there anything weird about the kvm interface that would prevent a 'side-loaded' snap from working?
[17:56] <popey_> (ogras qemu-virgil snap works fine when loaded from the store, but my side-loaded fork of it doesn't work)
[17:56] <popey_> Could not access KVM kernel module: Permission denied
[17:56] <popey_> qemu-system-x86_64: failed to initialize KVM: Permission denied
[17:57] <albertosottile> jdstrand: the snap should be released on the store now -> https://snapcraft.io/syncplay
[18:43] <kyrofa> zyga, I understand that snaps on Debian aren't confined (at least, not with apparmor). However, even in a snap that sets the PATH in apps, the snap ends up running stuff off the host
[18:43] <kyrofa> zyga, like snapd doesn't reset the PATH like it does elsewhere
[18:43] <kyrofa> Is that possible?
[18:45] <kyrofa> zyga, specifically Nextcloud will run mysql from the host if it's installed on Debian, and I have no idea why
[18:45] <kyrofa> Shouldn't the hostfs be isolated off in /var/lib/snapd/ or something?
[19:03] <kyrofa> zyga, anyway, it's been biting us since the beginning, some love on this bug would be great: https://bugs.launchpad.net/snapd/+bug/1819734
[19:20] <jdstrand> albertosottile: nice!
[19:20] <jdstrand> popey_: does your user have access to the device?
[19:54] <popey_> jdstrand: the same user using qemu-virgil works though.
[21:02] <jdstrand> popey_: the interface is incredibly simple. the is one apparmor rule and one udev rule, and some logic for loading the right kernel module. that's it
[21:05] <jdstrand> popey_: make sure the interface is connected; look at ls -l /dev/kvm and see the perms and if your user is in that group (use 'id'); see if there are any policy violations; see if the snap is in the device cgroup with udevadm info /dev/kvm (look at the TAGS)