mborzecki | morning | 06:11 |
---|---|---|
mborzecki | driving the kids to school, back in 30 | 06:20 |
mvo | mborzecki: good morning | 06:23 |
zyga | good morning | 06:32 |
mvo | hey zyga | 06:40 |
zyga | hey | 06:40 |
zyga | somewhat early start for me | 06:40 |
zyga | kids were incredibly efficient today | 06:40 |
mvo | nice | 06:41 |
zyga | mvo: I forgot to metion this | 06:45 |
zyga | *mention | 06:45 |
zyga | mvo: I think there's something seriously broken with lxd | 06:45 |
zyga | install lxd, start a container and shut the host down | 06:45 |
zyga | it doesn't shut down cleanly | 06:45 |
zyga | it takes 10 minutes for LXD to stop (on system timeout where it just ignores it) | 06:46 |
zyga | it's been like that for three weeks at least (I reboot infrequently) | 06:46 |
mvo | zyga: oh? did you mention this to stgraber or cbrauner? | 06:46 |
zyga | no, I only remember this when I reboot :/ | 06:46 |
zyga | (and I reboot now to shut down everything to upgrade macos) | 06:46 |
* mvo nods | 06:47 | |
* zyga notices it's 15C in the office and switches on heating... | 06:55 | |
mborzecki | re | 06:59 |
mborzecki | zyga: mvo: hey | 06:59 |
mborzecki | it's snowing today, as in properly snowing | 07:00 |
mborzecki | otoh, the forecast for tomorrow is +4 and +10 over the weekend xD | 07:00 |
mvo | mborzecki: woah, nice! we have +5°C here | 07:01 |
zyga | mborzecki: yeah, it will snow here as well soon | 07:02 |
zyga | mborzecki: but it's too warm for the snow | 07:02 |
zyga | mborzecki: is https://github.com/snapcore/snapd/pull/7614 something you can review today? | 07:04 |
mup | PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614> | 07:04 |
zyga | I would really like to move on with that topic | 07:04 |
mborzecki | zyga: sure, let me grab some coffee | 07:05 |
zyga | thanks | 07:05 |
zyga | I think it's close | 07:05 |
zyga | I have a follow up that I wrote months ago | 07:05 |
zyga | that adds most of the support for cgroup v2 | 07:05 |
zyga | and one that fixes v1 flip flop issue | 07:05 |
zyga | (where the cgroup must change from open to closed and back) | 07:05 |
mborzecki | flip flip issue? | 07:07 |
zyga | cgroup having open access + default rules | 07:07 |
zyga | vs closed access + explicit rules | 07:07 |
zyga | as in | 07:07 |
mborzecki | ah, ok | 07:07 |
zyga | nothing tagged - defaults without constraints | 07:07 |
zyga | something tagged - some implicitly allowed, some explicitly allowed, rest denied | 07:07 |
zyga | this is what triggered this whole branch originally | 07:08 |
* zyga reboots for updates | 07:20 | |
zyga | mborzecki: another thing that you could review, that is smaller, is https://github.com/snapcore/snapd/pull/7980 | 07:54 |
mup | PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980> | 07:54 |
zyga | mborzecki: the setgid code changes | 07:54 |
mvo | mborzecki: I was looking at the remodel code again (and added some comments to your undo PR). when playing with it I noticed that it seems like "snap remodel" is now hanging instead of exiting when we have a pending reboot, did you notice this as well? this means one of the pending spread tests is no longer quite working | 07:59 |
mborzecki | mvo: no i did not, i'll be running those tests again with the changes so i'll probably stumble upon that | 08:00 |
mvo | mborzecki: it's probably something silly, I poke at it a little bit | 08:01 |
zyga | mvo: hey, just a note from my backlog, solus maintainer expressed desire for changelogs for full releases | 08:04 |
zyga | mvo: like what you do for point releases | 08:04 |
zyga | mvo: it helps them write their own release notes | 08:04 |
zyga | mvo: and to do some testing | 08:04 |
zyga | mvo: I promised to relay this | 08:05 |
mvo | zyga: uh, ok. the changelogs will be huge but I can do this | 08:05 |
zyga | yeah but we can edit them (I offer my help) to highlight interesting things | 08:05 |
mvo | zyga: sounds good | 08:06 |
zyga | hmm | 08:12 |
zyga | unit test failure of 2.43.2 in opensuse | 08:12 |
zyga | https://www.irccloud.com/pastebin/j6YvQeQb/ | 08:12 |
mvo | zyga: oh, what version of go is there? | 08:13 |
zyga | 1.12 | 08:13 |
mvo | zyga: strange, we have 1.12 on eoan as well | 08:15 |
zyga | I think it's something else | 08:15 |
* zyga digs | 08:15 | |
zyga | it writes a file to HOME | 08:15 |
zyga | but HOME doesn't exist during package build | 08:16 |
mvo | zyga: uh, that's unfortunate | 08:16 |
zyga | same as in debian | 08:16 |
zyga | remember /inexisting? | 08:16 |
mvo | yeah | 08:16 |
zyga | oh well | 08:16 |
zyga | I hope it's not a .3 | 08:16 |
mvo | but we run this stuff in sbuild, I wonder why this wasn't caught | 08:16 |
zyga | our sbuild config is not the same as buildd | 08:17 |
zyga | (ran into this countless times with other packages) | 08:17 |
zyga | there's always something different | 08:17 |
zyga | let me tweak the test and see if that passes | 08:17 |
zyga | and if so, I'll sent the patch back | 08:17 |
zyga | setting HOME=/inexisting doesn't break the test | 08:20 |
* zyga wonders what's going on | 08:20 | |
zyga | ahh | 08:21 |
mvo | zyga: there was a PR about rebooting from spread too early, do you remember that? or am I misremembering? | 08:24 |
zyga | mvo: so | 08:26 |
zyga | mvo: ... HOME is set by go-test or perhaps go-check | 08:26 |
zyga | mvo: rebooting from spread too early? | 08:26 |
zyga | mvo: not sure if that's what you mean | 08:27 |
zyga | mvo: but while working on some leaks last week | 08:27 |
zyga | mvo: I changed a test so that it would just wait for the system to reboot by itself | 08:28 |
zyga | mvo: rather than issuing a REBOOT | 08:28 |
zyga | mvo: and that didn't work because spread didn't expect this | 08:28 |
zyga | mvo: I'm not sure if that is related | 08:28 |
zyga | mvo: but I was thinking it would be good if spread had an ANTICIPATE_REBOOT thing | 08:28 |
zyga | mvo: that would allow regular reboot to just work | 08:28 |
mvo | zyga: yeah, that was kind of my question | 08:30 |
mvo | zyga: was just curious about this | 08:30 |
zyga | mvo: perhaps there's a trick but it would be hard with spread design now | 08:31 |
zyga | mvo: because there's no side channel | 08:31 |
zyga | mvo: REBOOT relies on special exit code | 08:31 |
mvo | zyga: yeah | 08:31 |
zyga | brb | 08:32 |
zyga | mvo: so, I added printf to the test | 08:43 |
zyga | and now it passes :? | 08:43 |
mborzecki | Chipaca: hi, can you split this to a separate topic? https://forum.snapcraft.io/t/snapped-application-wont-start-for-nvidia-graphic-card/13342/6 | 08:44 |
mborzecki | zyga: ^^ some trouble with nvidia, wonder what driver version this guy has | 08:44 |
zyga | indeed, replied now | 08:46 |
mborzecki | zyga: thanks! | 08:47 |
mvo | zyga: a race? | 08:57 |
mup | PR snapd#8064 opened: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064> | 08:59 |
Chipaca | mborzecki: topic title and category plz | 09:06 |
mborzecki | Chipaca: category snapd, title: 'nvidia libraries not accessible inside snaps' ? cc zyga | 09:08 |
zyga | re | 09:08 |
zyga | +1 | 09:08 |
zyga | SNOW | 09:08 |
mborzecki | jon? | 09:08 |
zyga | Chipaca: you should move your edit rights to someone, maybe mackiek? | 09:08 |
mborzecki | :P | 09:08 |
zyga | *maciek | 09:08 |
mborzecki | duh, still snowing :/ | 09:10 |
Chipaca | mborzecki: https://forum.snapcraft.io/t/nvidia-libraries-not-accessible-inside-snaps/15227 | 09:14 |
mborzecki | Chipaca: thanks! | 09:14 |
Chipaca | mborzecki: zyga: I a mod, not an admin, so i can't make people mods (nor admins) | 09:15 |
Chipaca | mborzecki: zyga: you want to ask gustavo, or the pope | 09:15 |
Chipaca | the small one from hampshire, not the regular one from buenos aires | 09:16 |
mborzecki | hahah | 09:17 |
zyga | hmmmmm | 09:18 |
mborzecki | wow, huuge snowflakes | 09:19 |
zyga | yeah | 09:20 |
zyga | I took some photos | 09:20 |
zyga | same here | 09:20 |
zyga | too bad it's not -10 | 09:20 |
mborzecki | mvo: which remodel test was hanging for you? | 09:27 |
mvo | mborzecki: in a meeting right now, get back to you in a wee bit | 09:31 |
Chipaca | zyga: I could've also moved your comment instead of you deleting and recreating it fwiw :-) | 09:33 |
zyga | that's fine, thanks :) | 09:34 |
zyga | mvo: did you invite me to a meeting that was just finished? | 09:38 |
mvo | zyga: for next week | 09:39 |
zyga | ah, cool | 09:39 |
mvo | zyga: did it in a rush, all good | 09:39 |
mborzecki | quick errand, back in 30 or so | 09:42 |
pedronis | mvo: what's the relation between 8064 and Ian stuff ? | 09:43 |
pedronis | mvo: are you trying to split out bits from it? | 09:47 |
mvo | pedronis: I was wondering if that's possible | 09:48 |
mvo | pedronis: it's a bit long | 09:48 |
mvo | pedronis: this one is a straight cherry pick | 09:48 |
mvo | pedronis: but I was wondering if e.g. just the extraction of the kernel plus symlinking could land | 09:48 |
mvo | pedronis: and then the more delicate bits, mostly wondering at this point, no super strong opinion | 09:49 |
pedronis | mvo: I don't know, we turned on a lot of spread tests, will the ypass? | 09:49 |
mvo | pedronis: I think this one will, it just adds the kernel to the /boot/grub/pc-kernel_123.snap/kernel.efi | 09:49 |
mvo | pedronis: if we have the symlink too we would have something that could in theory boot an encrypted ubuntu-data | 09:50 |
pedronis | maybe | 09:50 |
pedronis | my impression was that Ian was fighting the fact that a lot of things dont' work | 09:50 |
mvo | pedronis: yeah, it's fine if you think it's a waste of effort, I will try to review in one go then | 09:50 |
pedronis | unless everything works | 09:50 |
pedronis | mvo: I'm not against | 09:50 |
pedronis | but consider that spread test might fail | 09:50 |
mvo | pedronis: yeah, I will keep this in mind | 09:51 |
mvo | pedronis: I poke it a bit more, but it might be this is the only thing that can easily extracted | 09:51 |
mvo | (assuming spread works) | 09:51 |
* Chipaca → orthopedist | 10:04 | |
kbroulik | Hi. I'm the maintainer of KDE Plasma's notification service. Recently we introduced a quick reply feature by adding a new signal on the FDO notification interface. This one isn't standard (yet) but I patched Telegram to use it. I now realized the AppArmor policy in snapd prevents it from connecting to this signal. | 10:25 |
kbroulik | Is a change to the builtin/desktop.go recipe to add NotificationReplied something you'd accept? | 10:25 |
kbroulik | ftr this signal: https://cgit.kde.org/plasma-workspace.git/tree/libnotificationmanager/dbus/org.freedesktop.Notifications.xml#n12 | 10:25 |
sitter | zyga, Chipaca ^ | 10:25 |
zyga | kbroulik: hey | 10:26 |
zyga | kbroulik: let me look | 10:26 |
zyga | I think it could go to desktop and desktop-legacy | 10:26 |
zyga | and perhaps unity7 as well, for completeness | 10:26 |
zyga | kbroulik: would you mind opening a forum thread, I'll patch things | 10:27 |
zyga | kbroulik: can you check that editing the dbus rules is enough for this? | 10:27 |
kbroulik | mostly asking because it's "not standard", otherwise I would have just submitted a pull request :) | 10:27 |
zyga | kbroulik: I can guide you how, if required | 10:27 |
zyga | kbroulik: yeah but practicality | 10:27 |
zyga | plus | 10:27 |
zyga | standard/ | 10:27 |
zyga | what is standard in linux | 10:27 |
kbroulik | and from what I reckon getting things into freedesktop is also easier if you have "prior art" ;) | 10:27 |
kbroulik | so we can tell "yo, it's already used by Telegram and others, so please accept, thanks" | 10:28 |
zyga | s/standard/freedesktop | 10:28 |
kbroulik | zyga: is editing my local apparmor policy thing enough? | 10:28 |
zyga | so +1 from me | 10:28 |
zyga | yeah | 10:28 |
kbroulik | what forum thread do you want me to open? | 10:28 |
zyga | kbroulik: just look at /var/lib/snapd/apparmor/profiles/snap.telegram.* | 10:28 |
zyga | there's a line that says | 10:28 |
zyga | member={GetCapabilities,GetServerInformation,Notify,CloseNotification} | 10:29 |
zyga | kbroulik: just a forum thread about this change, so that it can be referenced in the patch | 10:29 |
zyga | kbroulik: where you say who you are and that you are adding this to kde and telegram | 10:29 |
zyga | kbroulik: that should be enough | 10:29 |
kbroulik | I'm such a noob - how do I have it reload the apparmor policies? | 10:29 |
zyga | you need to run sudo apparmor_parser /var/lib/snapd/apparmor/profiles/fname | 10:30 |
zyga | (replace the fname) | 10:30 |
zyga | er | 10:30 |
zyga | apparmor_parser -r | 10:30 |
zyga | sorry ;) | 10:30 |
zyga | :) | 10:30 |
kbroulik | ok, let's see if it works now | 10:30 |
kbroulik | yup, works, lovely | 10:31 |
kbroulik | so basically | 10:32 |
kbroulik | -member={ActionInvoked,NotificationClosed} | 10:32 |
kbroulik | +member={ActionInvoked,NotificationClosed,NotificationReplied} | 10:32 |
zyga | there may be some tests that need changing | 10:32 |
zyga | "go test" should tell you | 10:32 |
kbroulik | I dont see anything in git grep using notifications at least other than the rules file | 10:33 |
kbroulik | can't load package: package .: no Go files | 10:34 |
kbroulik | (I havent built it yet) | 10:34 |
zyga | you can run tests with go test ./... | 10:34 |
zyga | just go to the project tree | 10:34 |
zyga | ideally just run go test ./interfaces/builtin | 10:35 |
kbroulik | apparently the go in bionic (both repo and snap) is too old | 10:35 |
zyga | no worries, I can make the patch | 10:36 |
kbroulik | ok, well, 13 is > 6, so I'll give the snap a go then | 10:36 |
zyga | just start a forum thread please | 10:36 |
kbroulik | https://forum.snapcraft.io/ this forum I guess? | 10:36 |
zyga | correct | 10:37 |
kbroulik | righty-o | 10:37 |
kbroulik | https://forum.snapcraft.io/t/kde-plasma-quick-reply-support/15229 is this alright? | 10:40 |
zyga | yes | 10:40 |
zyga | that's great | 10:40 |
kbroulik | thanks | 10:40 |
zyga | do you want to send the patch or shall I? | 10:40 |
kbroulik | I can do it | 10:41 |
kbroulik | should I then just put also a link to that forum thread in the commit message? | 10:41 |
zyga | yeah, add Forum: ... | 10:41 |
zyga | at the bottom | 10:41 |
kbroulik | desktop_legacy doesnt have org.freedesktop.notifications mention, only desktop and unity7 | 10:42 |
zyga | ah right | 10:43 |
zyga | I misread grep output | 10:43 |
kbroulik | I'll add it to the latter two | 10:43 |
zyga | thanks! | 10:43 |
kbroulik | oof, CLA, I think it's better if you do the patch then | 10:46 |
kbroulik | (I'm sure I had a launchpad/ubuntu one thing at some point) | 10:46 |
zyga | kbroulik: just try it, the check is automatic | 10:47 |
kbroulik | ok | 10:47 |
mup | PR snapd#8065 opened: interfaces/builtin: Allow NotificationReplied signal on org.freedesktop.Notifications <Created by kbroulik> <https://github.com/snapcore/snapd/pull/8065> | 10:48 |
zyga | mborzecki: I will have two small patches for you soon | 10:54 |
zyga | mvo: snapd doesn't work at all on focal :D | 10:54 |
zyga | mvo: patch soon | 10:54 |
zyga | mvo: trivial | 10:54 |
kbroulik | zyga: for the CLA it wants a phone number (which I'm not keen on giving them) and a canonical project contact.. | 11:09 |
zyga | mvo: ^ can you please help | 11:10 |
zyga | mborzecki: https://github.com/snapcore/snapd/pull/8066 | 11:12 |
mup | PR #8066: cmd/snap-confine: allow snap-confine to link to libpcre2 <âš Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8066> | 11:12 |
zyga | mvo: in case we do .3 please include this ^ | 11:12 |
mvo | kbroulik: I'm your contact and feel free to not give a phone number - Ithink that's new, I don't remember this as a requirement. sorry for that | 11:12 |
mvo | kbroulik: I can also pass this on to the relevant people | 11:12 |
mvo | zyga: it does not work on focal? I'm on focal, curious | 11:12 |
mup | PR snapd#8066 opened: cmd/snap-confine: allow snap-confine to link to libpcre2 <âš Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8066> | 11:12 |
zyga | mvo: old builds are ok but new builds link to liprce2 | 11:13 |
zyga | build on focal and you're sol | 11:13 |
mvo | zyga: ta! | 11:13 |
kbroulik | zyga: alright, can you re-run the ci check | 11:14 |
zyga | sure | 11:14 |
zyga | mvo: is it approved? | 11:15 |
ackk | mborzecki, hi, to confirm https://bugs.launchpad.net/snapd/+bug/1831473 is not yet released, right? | 11:17 |
mup | Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap <maas> <snapd:Fix Committed by jdstrand> <https://launchpad.net/bugs/1831473> | 11:17 |
* zyga goes for tea | 11:25 | |
zyga | https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/12 | 11:25 |
zyga | :D | 11:25 |
mvo | zyga: good that you are fixing this, yes :) ? | 11:26 |
mborzecki | re | 11:35 |
zyga | re | 12:18 |
zyga | mvo: yeah, I need to tweak the fix after doing it for real | 12:18 |
zyga | mvo: but it works | 12:18 |
zyga | mvo: man | 12:18 |
zyga | version strings like 123.435.02 SUCK | 12:18 |
zyga | mborzecki: snapd is out of date in aur | 12:19 |
mborzecki | zyga: mhm, got an email ;) | 12:20 |
zyga | yeah | 12:20 |
zyga | I find them funny | 12:20 |
mborzecki | zyga: weird version string `123.435.02 SUCK` | 12:20 |
zyga | OMFGOUTOFDATEEEEEEE | 12:20 |
zyga | mborzecki: :D | 12:20 |
mborzecki | kbroulik: LP hasn't been updated yet, but no worries, i'll try restarting the travis job periodically | 12:21 |
mborzecki | mvo: replying to your review of #7972 and realized that poking current is actually unreliable | 12:36 |
mup | PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel 🚋> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972> | 12:36 |
popey | With ubuntu-image and the json "required-snaps" - is it possible to specify that the snap needs to come from a particular channel? | 12:51 |
pedronis | mvo: comment on #8064 | 12:51 |
mup | PR #8064: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064> | 12:51 |
popey | I tried snapname/latest/edge but it didn't like that | 12:51 |
pedronis | popey: no, you can specify that with --snap to ubuntu-image but not in the model itself, that will be possible with Core 20 models, but the syntax is quite different there | 12:52 |
popey | ok | 12:52 |
popey | thanks | 12:52 |
zyga | mborzecki: https://github.com/snapcore/snapd/pull/8066 | 12:57 |
mup | PR #8066: cmd/snap-confine: allow snap-confine to link to libpcre2 <âš Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8066> | 12:57 |
zyga | mvo: we don't have 20.04 systems, do we? | 12:57 |
zyga | mvo: we have some in unstable | 12:58 |
zyga | which is not flagging anything | 12:58 |
mborzecki | zyga: btw. do you know which library pulls in pcre? | 13:00 |
zyga | mborzecki: checking | 13:03 |
zyga | mborzecki: no idea? | 13:05 |
zyga | maybe dlopen somewhere, it's not in NEEDED | 13:05 |
zyga | sty 29 11:33:59 fx kernel: audit: type=1400 audit(1580294039.867:53): apparmor="DENIED" operation="file_mmap" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/x86_64-linux-gnu/libpcre2-8.so.0.9.0" pid=74460 comm="snap-confine" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0 | 13:07 |
mborzecki | zyga: that's on focal right? | 13:07 |
zyga | yes | 13:07 |
mborzecki | zyga: can you try with LD_DEBUG=all ? | 13:08 |
mup | PR snapd#7942 closed: snap-confine: support nvidia driver microversion string <Created by zhuker> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7942> | 13:11 |
mup | PR snapd#8067 opened: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067> | 13:11 |
zyga | mborzecki: looking but I cannot find it | 13:11 |
zyga | it's so weird? | 13:11 |
mvo | zyga: aha, still in unstable, ok ! | 13:11 |
zyga | it's not there | 13:11 |
mvo | mborzecki: thanks, looking | 13:12 |
mvo | pedronis: also looking :) | 13:12 |
mborzecki | mvo: quick HO? | 13:12 |
* mborzecki wonders if it's a larger problem | 13:12 | |
pedronis | mborzecki: what problem? | 13:12 |
mvo | mborzecki: give me 2min to make a cup of tea, but then yes | 13:12 |
mborzecki | pedronis: looking at generateWrappers for snapd snap | 13:12 |
* zyga can join as well | 13:13 | |
zyga | standup? | 13:13 |
pedronis | mborzecki: I should probably join as well | 13:13 |
mborzecki | pedronis: ack | 13:13 |
kbroulik | mborzecki: okay, cool | 13:27 |
kbroulik | what's the update policy for snapd on older ubuntu? Bionic seems to have the same 2.42.1, so it's safe to assume it is still being updated? | 13:37 |
zyga | kbroulik: snap version | 13:37 |
zyga | kbroulik: it's not 2.42.1 in practice | 13:37 |
zyga | kbroulik: it will use snapd from a snap (either core or snapd) | 13:37 |
kbroulik | ok, cool | 13:37 |
zyga | kbroulik: we regularly do updates of the classic package | 13:37 |
kbroulik | I have 2.42.5, so my patch will end up reaching bionic users, too, I guess :) | 13:38 |
zyga | kbroulik: but on some systems we also have this mechanism where you can get most of the new release without that | 13:38 |
zyga | kbroulik: yes, even 14.04 | 13:38 |
kbroulik | cool | 13:38 |
* Chipaca looks around for things to set on fire | 13:39 | |
zyga | Chipaca: bugs, burn them all | 13:40 |
cmatsuoka | Chipaca: RGB fans! | 13:41 |
* Chipaca sets all RGB fans on fire | 13:42 | |
Chipaca | we could package an RGB fan controller as a snap | 13:42 |
Chipaca | and then one day update it without the --avoid-being-on-fire flag | 13:43 |
Chipaca | build flag* | 13:43 |
zyga | Chipaca: I'm so into RGB fans | 13:46 |
zyga | I plan to buy a few | 13:47 |
zyga | to compare them | 13:47 |
zyga | there are those magnetic levitation fans | 13:47 |
* Chipaca sets zyga on fire as a preventive measure | 13:47 | |
zyga | that are supposedly quiet | 13:47 |
zyga | Chipaca: can it be RGB fire? :D | 13:47 |
zyga | I would only wish if the vendors did more work in the open | 13:47 |
zyga | to put the protocol of their things out | 13:47 |
zyga | so that people can write nice foss integration | 13:47 |
zyga | gnome-rgb-fan-omg-panel anyone? | 13:48 |
Chipaca | zyga: as long as the RGB aspect can be bought separately, and the market isn't inundated with cheap rgb fans such that the only way to get a no-nonsense one is to pay for a fancy one (or worse, a fancy one that actually allows you to turn it off), I don't really mind | 13:48 |
Chipaca | s/fans/fires/ also | 13:48 |
zyga | Chipaca: all RGB fans can be turned off, you know | 13:49 |
zyga | it's not like RGB is powered by the same cable | 13:49 |
zyga | (or if it is, I haven't seen those) | 13:49 |
Chipaca | hmmm | 13:49 |
zyga | though | 13:49 |
zyga | to be fair | 13:49 |
zyga | I would rather see another development | 13:49 |
zyga | steal a design idea from the mac pro | 13:49 |
zyga | and design towards cable-free systems | 13:49 |
zyga | mac pro has zero cables inside the case | 13:49 |
zyga | nothing is connected by a cable | 13:49 |
zyga | that's a lot of work | 13:49 |
zyga | but it's super clean and nice if you can have that | 13:50 |
zyga | even fans are powered by a contact connector | 13:50 |
zyga | *connector | 13:50 |
zyga | PCI graphics - bus powered using new high-current connectors | 13:50 |
zyga | power switch - pogo pins | 13:50 |
zyga | it's a lot of tweaking but I would love to see corsair or other vendors go that way | 13:50 |
zyga | e.g. case with contact connectors that can be used for front / rear fans | 13:50 |
zyga | with one cable that goes to the mobo | 13:51 |
zyga | instead of a zoo | 13:51 |
zyga | aaanyway | 13:51 |
zyga | not snapd :) | 13:51 |
zyga | imagine a PSU without any cables on it, just a card that slots into the board | 13:52 |
zyga | and the kernel now has time namespaces | 13:56 |
zyga | yay | 13:56 |
=== ricab is now known as ricab|lunch | ||
* zyga goes for a snow walk | 14:24 | |
kbroulik | cool, ci passed \o/ | 14:53 |
=== ricab|lunch is now known as ricab | ||
mup | PR snapd#8065 closed: interfaces/builtin: Allow NotificationReplied signal on org.freedesktop.Notifications <Created by kbroulik> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8065> | 15:23 |
zyga | kbroulik: thank you for the contribution! | 15:35 |
* zyga is back | 15:35 | |
zyga | it's dark now | 15:35 |
kbroulik | alright, thanks zyga, mborzecki, and mvo. that went a lot more smoothly than I would have thought! :) | 15:35 |
zyga | :D | 15:35 |
zyga | kbroulik: it's even better | 15:35 |
zyga | kbroulik: because of the distribution system you can enjoy it from edge in a few hours :) | 15:36 |
zyga | take that classic packaging! | 15:36 |
kbroulik | heh | 15:36 |
mvo | kbroulik: nice, great to hear! | 15:38 |
zyga | mvo: https://forum.snapcraft.io/t/winter-2020/15231 | 15:40 |
mvo | zyga: nice one! | 15:41 |
pedronis | mvo: mborzecki: I did a pass on #8001 | 16:05 |
mup | PR #8001: boot: enable UC20 kernel extraction and bootState20 handling <Needs Samuele review> <UC20> <â›” Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001> | 16:05 |
* zyga is cold | 16:06 | |
zyga | tea | 16:06 |
mvo | pedronis: thank you so much! | 16:06 |
mborzecki | pedronis: cool, thanks, looks like i can address most of it in the morning | 16:08 |
mup | PR snapd#8066 closed: cmd/snap-confine: allow snap-confine to link to libpcre2 <âš Critical> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8066> | 16:11 |
pedronis | Chipaca: there isn't a GET on /users right ? | 16:13 |
Chipaca | pedronis: yes there is | 16:15 |
Chipaca | pedronis: returns a []userResponseData of all users | 16:16 |
Chipaca | pedronis: from state, that is | 16:16 |
mborzecki | damn, i'm late to a meetup | 16:18 |
pedronis | Chipaca: it's RootOnly though, ok | 16:21 |
Chipaca | pedronis: yep | 16:21 |
Chipaca | pedronis: all of these are | 16:21 |
Chipaca | pedronis: and in fact that's probably the strongest argument for _not_ making login/logout also go via /v2/users | 16:21 |
sil2100 | Hey! Just wanted to touch base and make sure that the current snapd snap in stable is good for our ubuntu-core 18 18.04.4 images next week | 16:28 |
sil2100 | mvo, pedronis, zyga: ^ can I use the current snapd safely for new images? | 16:28 |
sil2100 | (uc18) | 16:29 |
zyga | ymmmm | 16:29 |
zyga | stable is always good | 16:29 |
zyga | or we change what it points at | 16:29 |
zyga | I think the answer is "always yes" | 16:29 |
Chipaca | sil2100: maybe coordinate with mvo as we're just wrapping up a release? | 16:32 |
zyga | Chipaca: yeah but that's coming in like ... two weeks :/ | 16:33 |
zyga | (to stable) | 16:33 |
Chipaca | aw | 16:33 |
Chipaca | i thought it was also next week | 16:33 |
Chipaca | (it was two weeks two weeks ago :-P) | 16:33 |
zyga | I think it's after sergio is back plus then some | 16:33 |
zyga | for validation | 16:33 |
Chipaca | right | 16:33 |
zyga | but yeah | 16:33 |
zyga | sil2100: do wait for mvo's response | 16:33 |
pedronis | Chipaca: in #8059 Maciek's comment looks reasonable, I made some comments in #8061 | 16:36 |
mup | PR #8059: daemon: implement user removal <Created by chipaca> <https://github.com/snapcore/snapd/pull/8059> | 16:36 |
mup | PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061> | 16:36 |
Chipaca | pedronis: the more i think about the latter, the more i favour a boolean flag | 16:36 |
Chipaca | pedronis: digging into Response is nassty | 16:36 |
zyga | https://github.com/snapcore/snapd/pull/8067 is green :) | 16:36 |
mup | PR #8067: cmd/snap-confine,tests: support x.y.z nvidia version <Created by zyga> <https://github.com/snapcore/snapd/pull/8067> | 16:36 |
Chipaca | pedronis: wrt the former, i'll push those changes at the bottom of the pile if that's ok | 16:37 |
pedronis | Chipaca: I don't have a strong feeling, but the current code is maximally opaque | 16:37 |
pedronis | because it depends too much on knowing exactly what the other function does | 16:37 |
Chipaca | pedronis: not maximally! it no longer has resp.(*resp).Result.([]userResponseData) ! | 16:38 |
pedronis | heh | 16:38 |
Chipaca | pedronis: thank you for your reviews | 16:38 |
Chipaca | pedronis: I will address this shortly | 16:39 |
Chipaca | i think i'll go to the gym first | 16:39 |
pedronis | Chipaca: the stuff in #8063 itself looks alright | 16:40 |
mup | PR #8063: many: remove users [DRAFT] <Created by chipaca> <https://github.com/snapcore/snapd/pull/8063> | 16:40 |
pedronis | nothing too surprising afaict | 16:40 |
Chipaca | pedronis: pushing that into individual PRs is still the right approach tho, right? | 16:41 |
pedronis | Chipaca: any particular reasons to do that? | 16:41 |
pedronis | it's not very big | 16:41 |
Chipaca | pedronis: keeping things easily reviewable | 16:42 |
pedronis | Chipaca: you can split client vs cmd/snap if you prefer | 16:42 |
pedronis | I don't have a strong feeling either way | 16:42 |
Chipaca | yeah that was the split i meant | 16:42 |
Chipaca | client, and then cmd/snap + spread | 16:42 |
pedronis | Chipaca: thank you | 16:43 |
Chipaca | ok | 16:43 |
Chipaca | but first, ex er ci ses | 16:43 |
* Chipaca goes | 16:43 | |
sil2100 | zyga, Chipaca: thanks guys ;) | 16:47 |
sil2100 | Yeah, we'll probably be building image candidates Friday or Monday already | 16:48 |
zyga | mvo: the unit test that does go fmt checks needs to go :/ | 16:55 |
zyga | it just doesn't pass anymore | 16:55 |
pedronis | zyga: where? | 16:55 |
zyga | pedronis: tests/unit/go on 20.04 | 16:56 |
zyga | it fails and shows a diff about gofmt differences | 16:56 |
pedronis | I think we had the idea to use a specific go version with it | 16:56 |
pedronis | there's a go snap with quite a few tracks | 16:57 |
zyga | pedronis: yeah, but it's not used here, I think we should only fmtcheck on 16.04 or something | 16:57 |
zyga | the rest can just run unit tests | 16:57 |
pedronis | I'm probably misunderstanding what you said then | 16:58 |
mup | PR snapd#8059 closed: daemon: implement user removal <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8059> | 18:20 |
Chipaca | pedronis: I think I've made #8061 saner | 18:36 |
mup | PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061> | 18:36 |
Chipaca | zyga: pedronis: I think the right thing is to skip it of running on non-<whatever gofmt we decided on> | 18:39 |
zyga | Chipaca: that's exactly what I did | 18:39 |
Chipaca | zyga: ah ok | 18:39 |
zyga | Chipaca: branch is coming up soon, all of 20.04 passes | 18:39 |
zyga | just one more run before I open | 18:39 |
Chipaca | zyga: weeₔₔₘ | 18:40 |
pedronis | Chipaca: thanks, comment on #8061 | 19:14 |
mup | PR #8061: daemon: make users result more consistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/8061> | 19:14 |
zyga | Chipaca: https://github.com/snapcore/snapd/pull/8068 :) | 19:15 |
mup | PR #8068: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <https://github.com/snapcore/snapd/pull/8068> | 19:15 |
mup | PR snapd#8068 opened: tests: tweak and enable tests on ubuntu 20.04 <Created by zyga> <https://github.com/snapcore/snapd/pull/8068> | 19:15 |
Chipaca | pedronis: fixed | 19:23 |
zyga | brb | 19:24 |
zyga | I need a coffee | 19:25 |
zyga | or maybe | 19:25 |
zyga | a coffee and a short break | 19:25 |
zyga | I'll be back to that OMG cool thing I'm doing :) | 19:25 |
zyga | o/ | 19:25 |
pedronis | Chipaca: do I understand correctly that we let you remove users we didn't create? | 19:39 |
mup | PR snapd#8069 opened: tests: build the initramfs + kernel snap for UC20 spread tests <Precious Logs> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8069> | 21:41 |
sdhd-sascha | hmm | 22:42 |
=== JanC is now known as Guest16482 | ||
=== JanC_ is now known as JanC | ||
sdhd-sascha | hmm | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!