[06:11] <mborzecki> morning
[06:20] <mborzecki> driving the kids to school, back in 30
[06:23] <mvo> mborzecki: good morning
[06:32] <zyga> good morning
[06:40] <mvo> hey zyga
[06:40] <zyga> hey
[06:40] <zyga> somewhat early start for me
[06:40] <zyga> kids were incredibly efficient today
[06:41] <mvo> nice
[06:45] <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:46] <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:47]  * mvo nods
[06:55]  * zyga notices it's 15C in the office and switches on heating...
[06:59] <mborzecki> re
[06:59] <mborzecki> zyga: mvo: hey
[07:00] <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:01] <mvo> mborzecki: woah, nice! we have +5°C here
[07:02] <zyga> mborzecki: yeah, it will snow here as well soon
[07:02] <zyga> mborzecki: but it's too warm for the snow
[07:04] <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:05] <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:07] <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:08] <zyga> this is what triggered this whole branch originally
[07:20]  * zyga reboots for updates
[07:54] <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:59] <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
[08:00] <mborzecki> mvo: no i did not, i'll be running those tests again with the changes so i'll probably stumble upon that
[08:01] <mvo> mborzecki: it's probably something silly, I poke at it a little bit
[08:04] <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:05] <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:06] <mvo> zyga: sounds good
[08:12] <zyga> hmm
[08:12] <zyga> unit test failure of 2.43.2 in opensuse
[08:12] <zyga> https://www.irccloud.com/pastebin/j6YvQeQb/
[08:13] <mvo> zyga: oh, what version of go is there?
[08:13] <zyga> 1.12
[08:15] <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:16] <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:17] <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:20] <zyga> setting HOME=/inexisting doesn't break the test
[08:20]  * zyga wonders what's going on
[08:21] <zyga> ahh
[08:24] <mvo> zyga: there was a PR about rebooting from spread too early, do you remember that? or am I misremembering?
[08:26] <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:27] <zyga> mvo: not sure if that's what you mean
[08:27] <zyga> mvo: but while working on some leaks last week
[08:28] <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:30] <mvo> zyga: yeah, that was kind of my question
[08:30] <mvo> zyga: was just curious about this
[08:31] <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:32] <zyga> brb
[08:43] <zyga> mvo: so, I added printf to the test
[08:43] <zyga> and now it passes :?
[08:44] <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:46] <zyga> indeed, replied now
[08:47] <mborzecki> zyga: thanks!
[08:57] <mvo> zyga: a race?
[08:59] <mup> PR snapd#8064 opened: boot: add Device iface to coreKernel <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8064>
[09:06] <Chipaca> mborzecki: topic title and category plz
[09:08] <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:10] <mborzecki> duh, still snowing :/
[09:14] <Chipaca> mborzecki: https://forum.snapcraft.io/t/nvidia-libraries-not-accessible-inside-snaps/15227
[09:14] <mborzecki> Chipaca: thanks!
[09:15] <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:16] <Chipaca> the small one from hampshire, not the regular one from buenos aires
[09:17] <mborzecki> hahah
[09:18] <zyga> hmmmmm
[09:19] <mborzecki> wow, huuge snowflakes
[09:20] <zyga> yeah
[09:20] <zyga> I took some photos
[09:20] <zyga> same here
[09:20] <zyga> too bad it's not -10
[09:27] <mborzecki> mvo: which remodel test was hanging for you?
[09:31] <mvo> mborzecki: in a meeting right now, get back to you in a wee bit
[09:33] <Chipaca> zyga: I could've also moved your comment instead of you deleting and recreating it fwiw :-)
[09:34] <zyga> that's fine, thanks :)
[09:38] <zyga> mvo: did you invite me to a meeting that was just finished?
[09:39] <mvo> zyga: for next week
[09:39] <zyga> ah, cool
[09:39] <mvo> zyga: did it in a rush, all good
[09:42] <mborzecki> quick errand, back in 30 or so
[09:43] <pedronis> mvo: what's the relation between 8064 and Ian stuff ?
[09:47] <pedronis> mvo: are you trying to split out bits from it?
[09:48] <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:49] <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:50] <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:51] <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)
[10:04]  * Chipaca → orthopedist 
[10:25] <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:26] <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:27] <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:28] <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:29] <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:30] <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:31] <kbroulik> yup, works, lovely
[10:32] <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:33] <kbroulik> I dont see anything in git grep using notifications at least other than the rules file
[10:34] <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:35] <zyga> ideally just run go test ./interfaces/builtin
[10:35] <kbroulik> apparently the go in bionic (both repo and snap) is too old
[10:36] <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:37] <zyga> correct
[10:37] <kbroulik> righty-o
[10:40] <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:41] <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:42] <kbroulik> desktop_legacy doesnt have org.freedesktop.notifications mention, only desktop and unity7
[10:43] <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:46] <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:47] <zyga> kbroulik: just try it, the check is automatic
[10:47] <kbroulik> ok
[10:48] <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:54] <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
[11:09] <kbroulik> zyga: for the CLA it wants a phone number (which I'm not keen on giving them) and a canonical project contact..
[11:10] <zyga> mvo: ^ can you please help
[11:12] <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:13] <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:14] <kbroulik> zyga: alright, can you re-run the ci check
[11:14] <zyga> sure
[11:15] <zyga> mvo: is it approved?
[11:17] <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:25]  * 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:26] <mvo> zyga: good that you are fixing this, yes :) ?
[11:35] <mborzecki> re
[12:18] <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:19] <zyga> mborzecki: snapd is out of date in aur
[12:20] <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:21] <mborzecki> kbroulik: LP hasn't been updated yet, but no worries, i'll try restarting the travis job periodically
[12:36] <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:51] <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:52] <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:57] <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:58] <zyga> mvo: we have some in unstable
[12:58] <zyga> which is not flagging anything
[13:00] <mborzecki> zyga: btw. do you know which library pulls in pcre?
[13:03] <zyga> mborzecki: checking
[13:05] <zyga> mborzecki: no idea?
[13:05] <zyga> maybe dlopen somewhere, it's not in NEEDED
[13:07] <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:08] <mborzecki> zyga: can you try with LD_DEBUG=all ?
[13:11] <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:12] <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:13]  * 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:27] <kbroulik> mborzecki: okay, cool
[13:37] <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:38] <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:39]  * Chipaca looks around for things to set on fire
[13:40] <zyga> Chipaca: bugs, burn them all
[13:41] <cmatsuoka> Chipaca: RGB fans!
[13:42]  * Chipaca sets all RGB fans on fire
[13:42] <Chipaca> we could package an RGB fan controller as a snap
[13:43] <Chipaca> and then one day update it without the --avoid-being-on-fire flag
[13:43] <Chipaca> build flag*
[13:46] <zyga> Chipaca: I'm so into RGB fans
[13:47] <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:48] <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:49] <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:50] <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:51] <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:52] <zyga> imagine a PSU without any cables on it, just a card that slots into the board
[13:56] <zyga> and the kernel now has time namespaces
[13:56] <zyga> yay
[14:24]  * zyga goes for a snow walk
[14:53] <kbroulik> cool, ci passed \o/
[15:23] <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:35] <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:36] <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:38] <mvo> kbroulik: nice, great to hear!
[15:40] <zyga> mvo: https://forum.snapcraft.io/t/winter-2020/15231
[15:41] <mvo> zyga: nice one!
[16:05] <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:06]  * zyga is cold
[16:06] <zyga> tea
[16:06] <mvo> pedronis: thank you so much!
[16:08] <mborzecki> pedronis: cool, thanks, looks like i can address most of it in the morning
[16:11] <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:13] <pedronis> Chipaca: there isn't a GET on /users right ?
[16:15] <Chipaca> pedronis: yes there is
[16:16] <Chipaca> pedronis: returns a []userResponseData of all users
[16:16] <Chipaca> pedronis: from state, that is
[16:18] <mborzecki> damn, i'm late to a meetup
[16:21] <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:28] <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:29] <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:32] <Chipaca> sil2100: maybe coordinate with mvo as we're just wrapping up a release?
[16:33] <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:36] <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:37] <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:38] <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:39] <Chipaca> pedronis: I will address this shortly
[16:39] <Chipaca> i think i'll go to the gym first
[16:40] <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:41] <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:42] <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:43] <pedronis> Chipaca: thank you
[16:43] <Chipaca> ok
[16:43] <Chipaca> but first, ex er ci ses
[16:43]  * Chipaca goes
[16:47] <sil2100> zyga, Chipaca: thanks guys ;)
[16:48] <sil2100> Yeah, we'll probably be building image candidates Friday or Monday already
[16:55] <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:56] <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:57] <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:58] <pedronis> I'm probably misunderstanding what you said then
[18:20] <mup> PR snapd#8059 closed: daemon: implement user removal <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8059>
[18:36] <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:39] <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:40] <Chipaca> zyga: weeₔₔₘ
[19:14] <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:15] <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:23] <Chipaca> pedronis: fixed
[19:24] <zyga> brb
[19:25] <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:39] <pedronis> Chipaca: do I understand correctly that we let you remove users we didn't create?
[21:41] <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>
[22:42] <sdhd-sascha> hmm
[23:37] <sdhd-sascha> hmm