| stgraber | sergiusens: around by any chance? | 01:02 |
|---|---|---|
| stgraber | ah, I think I may have figured out my issue | 01:05 |
| sergiusens | stgraber: I sort of am | 01:18 |
| 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:19 |
| 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:24 |
| 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:25 |
| sergiusens | stgraber: vcs triggered builds dtrt | 01:26 |
| stgraber | got a link to the LP bug by any chance | 01:27 |
| stgraber | if not, I can go dig | 01:27 |
| zyga | good morning! | 06:56 |
| zyga | I'm off today, just need to do the paperwork | 06:56 |
| zyga | ok, paperwork done | 07:21 |
| === pstolowski|afk is now known as pstolowski | ||
| pstolowski | morning | 07:30 |
| pedronis | pstolowski: hi, are you working today? | 07:41 |
| pstolowski | pedronis: yes | 07:52 |
| 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:53 |
| pstolowski | pedronis: uhm, thank you | 07:55 |
| pstolowski | i'm having a slow start today, switching ISP this morning and still having a technican here | 07:56 |
| zyga | Hey hey | 08:10 |
| zyga | I will do some reviews today | 08:10 |
| zyga | 7 hours more to go today | 08:11 |
| zyga | I will look at the race PR from pedronis now | 08:14 |
| 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:15 |
| 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:16 |
| zyga | pedronis: question about https://github.com/snapcore/snapd/pull/7018/commits/3ff9725feb595f78d8bcbee0df3c621af9de6419 | 08:24 |
| 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:25 |
| pedronis | zyga: it fixing go test -race | 08:26 |
| pedronis | to be honest for those tests I mostly looked at making it happy | 08:26 |
| 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:27 |
| zyga | mmm, indeed | 08:28 |
| zyga | pedronis: reviewed, 7018, looking at the other oen | 08:40 |
| zyga | *one | 08:40 |
| 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:41 |
| pedronis | @zyga: Wait exists basically only for tests | 08:45 |
| zyga | aha | 08:45 |
| 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:04 |
| 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:07 |
| cjwatson | I have a branch in progress to fix that exception that I started in Lyon, so I should probably finish that off | 09:09 |
| cjwatson | That branch will mean that if you explicitly select architectures then they get passed through and intersected with any other applicable constraints | 09:10 |
| pedronis | Chipaca: hi, did that comment pointer help? | 10:11 |
| Chipaca | pedronis: i think so yes | 10:14 |
| pedronis | pstolowski: 6960 is green | 10:15 |
| pstolowski | pedronis: great, ty, landing | 10:16 |
| 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:38 |
| Chipaca | pedronis_: are we done wrt simplifying retries? | 11:58 |
| Chipaca | pedronis: are we done wrt simplifying retries? | 11:59 |
| Chipaca | :) | 11:59 |
| pedronis | Chipaca: I cannot post anymore as pedronis_ and then it's a dance | 12:00 |
| pedronis | Chipaca: you mean https://trello.com/c/9GcOfcEG/32-improvement-to-retries-and-request-patterns-for-store ? | 12:01 |
| 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:02 |
| 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:03 |
| pedronis | therefore | 12:04 |
| Chipaca | pedronis: right, but that's the WIP, isn't it? | 12:05 |
| 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:06 |
| abeato | it looks like the size is one page | 12:07 |
| abeato | ok, let me do that | 12:07 |
| abeato | (the buffer size) | 12:07 |
| abeato | pedronis, pstolowski https://bugs.launchpad.net/snapd/+bug/1833707 | 12:10 |
| pstolowski | abeato: interesting, thank you | 12:13 |
| pstolowski | abeato: when you see it happening, can you also run 'udevadm monitor -p' and capture corresponding event(s)? | 12:14 |
| 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:15 |
| abeato | 128*1024*1024 | 12:16 |
| 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:17 |
| 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! | 12:18 |
| pedronis | Chipaca: standup? | 13:01 |
| Chipaca | ye | 13:01 |
| stgraber | cjwatson: thanks! | 13:25 |
| zyga | online again, will do another review | 14:07 |
| * cachio lunch | 14:55 | |
| * Chipaca weeps at today's xkcd | 15:08 | |
| 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:15 |
| 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 | 16:19 |
| === pstolowski is now known as pstolowski|afk | ||
| 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:56 |
| albertosottile | jdstrand: the snap should be released on the store now -> https://snapcraft.io/syncplay | 17:57 |
| 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:43 |
| 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? | 18:45 |
| 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:03 |
| jdstrand | albertosottile: nice! | 19:20 |
| jdstrand | popey_: does your user have access to the device? | 19:20 |
| popey_ | jdstrand: the same user using qemu-virgil works though. | 19:54 |
| 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:02 |
| 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) | 21:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!