[06:11] morning [06:20] driving the kids to school, back in 30 [06:23] mborzecki: good morning [06:32] good morning [06:40] hey zyga [06:40] hey [06:40] somewhat early start for me [06:40] kids were incredibly efficient today [06:41] nice [06:45] mvo: I forgot to metion this [06:45] *mention [06:45] mvo: I think there's something seriously broken with lxd [06:45] install lxd, start a container and shut the host down [06:45] it doesn't shut down cleanly [06:46] it takes 10 minutes for LXD to stop (on system timeout where it just ignores it) [06:46] it's been like that for three weeks at least (I reboot infrequently) [06:46] zyga: oh? did you mention this to stgraber or cbrauner? [06:46] no, I only remember this when I reboot :/ [06:46] (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] re [06:59] zyga: mvo: hey [07:00] it's snowing today, as in properly snowing [07:00] otoh, the forecast for tomorrow is +4 and +10 over the weekend xD [07:01] mborzecki: woah, nice! we have +5°C here [07:02] mborzecki: yeah, it will snow here as well soon [07:02] mborzecki: but it's too warm for the snow [07:04] mborzecki: is https://github.com/snapcore/snapd/pull/7614 something you can review today? [07:04] PR #7614: cmd/snap-confine: implement snap-device-helper internally [07:04] I would really like to move on with that topic [07:05] zyga: sure, let me grab some coffee [07:05] thanks [07:05] I think it's close [07:05] I have a follow up that I wrote months ago [07:05] that adds most of the support for cgroup v2 [07:05] and one that fixes v1 flip flop issue [07:05] (where the cgroup must change from open to closed and back) [07:07] flip flip issue? [07:07] cgroup having open access + default rules [07:07] vs closed access + explicit rules [07:07] as in [07:07] ah, ok [07:07] nothing tagged - defaults without constraints [07:07] something tagged - some implicitly allowed, some explicitly allowed, rest denied [07:08] this is what triggered this whole branch originally [07:20] * zyga reboots for updates [07:54] mborzecki: another thing that you could review, that is smaller, is https://github.com/snapcore/snapd/pull/7980 [07:54] PR #7980: packaging,snap-confine: stop being setgid root [07:54] mborzecki: the setgid code changes [07:59] 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] mvo: no i did not, i'll be running those tests again with the changes so i'll probably stumble upon that [08:01] mborzecki: it's probably something silly, I poke at it a little bit [08:04] mvo: hey, just a note from my backlog, solus maintainer expressed desire for changelogs for full releases [08:04] mvo: like what you do for point releases [08:04] mvo: it helps them write their own release notes [08:04] mvo: and to do some testing [08:05] mvo: I promised to relay this [08:05] zyga: uh, ok. the changelogs will be huge but I can do this [08:05] yeah but we can edit them (I offer my help) to highlight interesting things [08:06] zyga: sounds good [08:12] hmm [08:12] unit test failure of 2.43.2 in opensuse [08:12] https://www.irccloud.com/pastebin/j6YvQeQb/ [08:13] zyga: oh, what version of go is there? [08:13] 1.12 [08:15] zyga: strange, we have 1.12 on eoan as well [08:15] I think it's something else [08:15] * zyga digs [08:15] it writes a file to HOME [08:16] but HOME doesn't exist during package build [08:16] zyga: uh, that's unfortunate [08:16] same as in debian [08:16] remember /inexisting? [08:16] yeah [08:16] oh well [08:16] I hope it's not a .3 [08:16] but we run this stuff in sbuild, I wonder why this wasn't caught [08:17] our sbuild config is not the same as buildd [08:17] (ran into this countless times with other packages) [08:17] there's always something different [08:17] let me tweak the test and see if that passes [08:17] and if so, I'll sent the patch back [08:20] setting HOME=/inexisting doesn't break the test [08:20] * zyga wonders what's going on [08:21] ahh [08:24] zyga: there was a PR about rebooting from spread too early, do you remember that? or am I misremembering? [08:26] mvo: so [08:26] mvo: ... HOME is set by go-test or perhaps go-check [08:26] mvo: rebooting from spread too early? [08:27] mvo: not sure if that's what you mean [08:27] mvo: but while working on some leaks last week [08:28] mvo: I changed a test so that it would just wait for the system to reboot by itself [08:28] mvo: rather than issuing a REBOOT [08:28] mvo: and that didn't work because spread didn't expect this [08:28] mvo: I'm not sure if that is related [08:28] mvo: but I was thinking it would be good if spread had an ANTICIPATE_REBOOT thing [08:28] mvo: that would allow regular reboot to just work [08:30] zyga: yeah, that was kind of my question [08:30] zyga: was just curious about this [08:31] mvo: perhaps there's a trick but it would be hard with spread design now [08:31] mvo: because there's no side channel [08:31] mvo: REBOOT relies on special exit code [08:31] zyga: yeah [08:32] brb [08:43] mvo: so, I added printf to the test [08:43] and now it passes :? [08:44] 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] zyga: ^^ some trouble with nvidia, wonder what driver version this guy has [08:46] indeed, replied now [08:47] zyga: thanks! [08:57] zyga: a race? [08:59] PR snapd#8064 opened: boot: add Device iface to coreKernel [09:06] mborzecki: topic title and category plz [09:08] Chipaca: category snapd, title: 'nvidia libraries not accessible inside snaps' ? cc zyga [09:08] re [09:08] +1 [09:08] SNOW [09:08] jon? [09:08] Chipaca: you should move your edit rights to someone, maybe mackiek? [09:08] :P [09:08] *maciek [09:10] duh, still snowing :/ [09:14] mborzecki: https://forum.snapcraft.io/t/nvidia-libraries-not-accessible-inside-snaps/15227 [09:14] Chipaca: thanks! [09:15] mborzecki: zyga: I a mod, not an admin, so i can't make people mods (nor admins) [09:15] mborzecki: zyga: you want to ask gustavo, or the pope [09:16] the small one from hampshire, not the regular one from buenos aires [09:17] hahah [09:18] hmmmmm [09:19] wow, huuge snowflakes [09:20] yeah [09:20] I took some photos [09:20] same here [09:20] too bad it's not -10 [09:27] mvo: which remodel test was hanging for you? [09:31] mborzecki: in a meeting right now, get back to you in a wee bit [09:33] zyga: I could've also moved your comment instead of you deleting and recreating it fwiw :-) [09:34] that's fine, thanks :) [09:38] mvo: did you invite me to a meeting that was just finished? [09:39] zyga: for next week [09:39] ah, cool [09:39] zyga: did it in a rush, all good [09:42] quick errand, back in 30 or so [09:43] mvo: what's the relation between 8064 and Ian stuff ? [09:47] mvo: are you trying to split out bits from it? [09:48] pedronis: I was wondering if that's possible [09:48] pedronis: it's a bit long [09:48] pedronis: this one is a straight cherry pick [09:48] pedronis: but I was wondering if e.g. just the extraction of the kernel plus symlinking could land [09:49] pedronis: and then the more delicate bits, mostly wondering at this point, no super strong opinion [09:49] mvo: I don't know, we turned on a lot of spread tests, will the ypass? [09:49] pedronis: I think this one will, it just adds the kernel to the /boot/grub/pc-kernel_123.snap/kernel.efi [09:50] pedronis: if we have the symlink too we would have something that could in theory boot an encrypted ubuntu-data [09:50] maybe [09:50] my impression was that Ian was fighting the fact that a lot of things dont' work [09:50] 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] unless everything works [09:50] mvo: I'm not against [09:50] but consider that spread test might fail [09:51] pedronis: yeah, I will keep this in mind [09:51] pedronis: I poke it a bit more, but it might be this is the only thing that can easily extracted [09:51] (assuming spread works) [10:04] * Chipaca → orthopedist [10:25] 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] Is a change to the builtin/desktop.go recipe to add NotificationReplied something you'd accept? [10:25] ftr this signal: https://cgit.kde.org/plasma-workspace.git/tree/libnotificationmanager/dbus/org.freedesktop.Notifications.xml#n12 [10:25] zyga, Chipaca ^ [10:26] kbroulik: hey [10:26] kbroulik: let me look [10:26] I think it could go to desktop and desktop-legacy [10:26] and perhaps unity7 as well, for completeness [10:27] kbroulik: would you mind opening a forum thread, I'll patch things [10:27] kbroulik: can you check that editing the dbus rules is enough for this? [10:27] mostly asking because it's "not standard", otherwise I would have just submitted a pull request :) [10:27] kbroulik: I can guide you how, if required [10:27] kbroulik: yeah but practicality [10:27] plus [10:27] standard/ [10:27] what is standard in linux [10:27] and from what I reckon getting things into freedesktop is also easier if you have "prior art" ;) [10:28] so we can tell "yo, it's already used by Telegram and others, so please accept, thanks" [10:28] s/standard/freedesktop [10:28] zyga: is editing my local apparmor policy thing enough? [10:28] so +1 from me [10:28] yeah [10:28] what forum thread do you want me to open? [10:28] kbroulik: just look at /var/lib/snapd/apparmor/profiles/snap.telegram.* [10:28] there's a line that says [10:29] member={GetCapabilities,GetServerInformation,Notify,CloseNotification} [10:29] kbroulik: just a forum thread about this change, so that it can be referenced in the patch [10:29] kbroulik: where you say who you are and that you are adding this to kde and telegram [10:29] kbroulik: that should be enough [10:29] I'm such a noob - how do I have it reload the apparmor policies? [10:30] you need to run sudo apparmor_parser /var/lib/snapd/apparmor/profiles/fname [10:30] (replace the fname) [10:30] er [10:30] apparmor_parser -r [10:30] sorry ;) [10:30] :) [10:30] ok, let's see if it works now [10:31] yup, works, lovely [10:32] so basically [10:32] -member={ActionInvoked,NotificationClosed} [10:32] +member={ActionInvoked,NotificationClosed,NotificationReplied} [10:32] there may be some tests that need changing [10:32] "go test" should tell you [10:33] I dont see anything in git grep using notifications at least other than the rules file [10:34] can't load package: package .: no Go files [10:34] (I havent built it yet) [10:34] you can run tests with go test ./... [10:34] just go to the project tree [10:35] ideally just run go test ./interfaces/builtin [10:35] apparently the go in bionic (both repo and snap) is too old [10:36] no worries, I can make the patch [10:36] ok, well, 13 is > 6, so I'll give the snap a go then [10:36] just start a forum thread please [10:36] https://forum.snapcraft.io/ this forum I guess? [10:37] correct [10:37] righty-o [10:40] https://forum.snapcraft.io/t/kde-plasma-quick-reply-support/15229 is this alright? [10:40] yes [10:40] that's great [10:40] thanks [10:40] do you want to send the patch or shall I? [10:41] I can do it [10:41] should I then just put also a link to that forum thread in the commit message? [10:41] yeah, add Forum: ... [10:41] at the bottom [10:42] desktop_legacy doesnt have org.freedesktop.notifications mention, only desktop and unity7 [10:43] ah right [10:43] I misread grep output [10:43] I'll add it to the latter two [10:43] thanks! [10:46] oof, CLA, I think it's better if you do the patch then [10:46] (I'm sure I had a launchpad/ubuntu one thing at some point) [10:47] kbroulik: just try it, the check is automatic [10:47] ok [10:48] PR snapd#8065 opened: interfaces/builtin: Allow NotificationReplied signal on org.freedesktop.Notifications [10:54] mborzecki: I will have two small patches for you soon [10:54] mvo: snapd doesn't work at all on focal :D [10:54] mvo: patch soon [10:54] mvo: trivial [11:09] zyga: for the CLA it wants a phone number (which I'm not keen on giving them) and a canonical project contact.. [11:10] mvo: ^ can you please help [11:12] mborzecki: https://github.com/snapcore/snapd/pull/8066 [11:12] PR #8066: cmd/snap-confine: allow snap-confine to link to libpcre2 <⚠ Critical> [11:12] mvo: in case we do .3 please include this ^ [11:12] 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] kbroulik: I can also pass this on to the relevant people [11:12] zyga: it does not work on focal? I'm on focal, curious [11:12] PR snapd#8066 opened: cmd/snap-confine: allow snap-confine to link to libpcre2 <⚠ Critical> [11:13] mvo: old builds are ok but new builds link to liprce2 [11:13] build on focal and you're sol [11:13] zyga: ta! [11:14] zyga: alright, can you re-run the ci check [11:14] sure [11:15] mvo: is it approved? [11:17] mborzecki, hi, to confirm https://bugs.launchpad.net/snapd/+bug/1831473 is not yet released, right? [11:17] Bug #1831473: Can't run /usr/bin/systemd-detect-virt from inside snap [11:25] * zyga goes for tea [11:25] https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/12 [11:25] :D [11:26] zyga: good that you are fixing this, yes :) ? [11:35] re [12:18] re [12:18] mvo: yeah, I need to tweak the fix after doing it for real [12:18] mvo: but it works [12:18] mvo: man [12:18] version strings like 123.435.02 SUCK [12:19] mborzecki: snapd is out of date in aur [12:20] zyga: mhm, got an email ;) [12:20] yeah [12:20] I find them funny [12:20] zyga: weird version string `123.435.02 SUCK` [12:20] OMFGOUTOFDATEEEEEEE [12:20] mborzecki: :D [12:21] kbroulik: LP hasn't been updated yet, but no worries, i'll try restarting the travis job periodically [12:36] mvo: replying to your review of #7972 and realized that poking current is actually unreliable [12:36] PR #7972: overlord/snapstate, wrappers: undo of snapd on core [12:51] 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] mvo: comment on #8064 [12:51] PR #8064: boot: add Device iface to coreKernel [12:51] I tried snapname/latest/edge but it didn't like that [12:52] 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] ok [12:52] thanks [12:57] mborzecki: https://github.com/snapcore/snapd/pull/8066 [12:57] PR #8066: cmd/snap-confine: allow snap-confine to link to libpcre2 <⚠ Critical> [12:57] mvo: we don't have 20.04 systems, do we? [12:58] mvo: we have some in unstable [12:58] which is not flagging anything [13:00] zyga: btw. do you know which library pulls in pcre? [13:03] mborzecki: checking [13:05] mborzecki: no idea? [13:05] maybe dlopen somewhere, it's not in NEEDED [13:07] 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] zyga: that's on focal right? [13:07] yes [13:08] zyga: can you try with LD_DEBUG=all ? [13:11] PR snapd#7942 closed: snap-confine: support nvidia driver microversion string [13:11] PR snapd#8067 opened: cmd/snap-confine,tests: support x.y.z nvidia version [13:11] mborzecki: looking but I cannot find it [13:11] it's so weird? [13:11] zyga: aha, still in unstable, ok ! [13:11] it's not there [13:12] mborzecki: thanks, looking [13:12] pedronis: also looking :) [13:12] mvo: quick HO? [13:12] * mborzecki wonders if it's a larger problem [13:12] mborzecki: what problem? [13:12] mborzecki: give me 2min to make a cup of tea, but then yes [13:12] pedronis: looking at generateWrappers for snapd snap [13:13] * zyga can join as well [13:13] standup? [13:13] mborzecki: I should probably join as well [13:13] pedronis: ack [13:27] mborzecki: okay, cool [13:37] 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] kbroulik: snap version [13:37] kbroulik: it's not 2.42.1 in practice [13:37] kbroulik: it will use snapd from a snap (either core or snapd) [13:37] ok, cool [13:37] kbroulik: we regularly do updates of the classic package [13:38] I have 2.42.5, so my patch will end up reaching bionic users, too, I guess :) [13:38] kbroulik: but on some systems we also have this mechanism where you can get most of the new release without that [13:38] kbroulik: yes, even 14.04 [13:38] cool [13:39] * Chipaca looks around for things to set on fire [13:40] Chipaca: bugs, burn them all [13:41] Chipaca: RGB fans! [13:42] * Chipaca sets all RGB fans on fire [13:42] we could package an RGB fan controller as a snap [13:43] and then one day update it without the --avoid-being-on-fire flag [13:43] build flag* [13:46] Chipaca: I'm so into RGB fans [13:47] I plan to buy a few [13:47] to compare them [13:47] there are those magnetic levitation fans [13:47] * Chipaca sets zyga on fire as a preventive measure [13:47] that are supposedly quiet [13:47] Chipaca: can it be RGB fire? :D [13:47] I would only wish if the vendors did more work in the open [13:47] to put the protocol of their things out [13:47] so that people can write nice foss integration [13:48] gnome-rgb-fan-omg-panel anyone? [13:48] 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] s/fans/fires/ also [13:49] Chipaca: all RGB fans can be turned off, you know [13:49] it's not like RGB is powered by the same cable [13:49] (or if it is, I haven't seen those) [13:49] hmmm [13:49] though [13:49] to be fair [13:49] I would rather see another development [13:49] steal a design idea from the mac pro [13:49] and design towards cable-free systems [13:49] mac pro has zero cables inside the case [13:49] nothing is connected by a cable [13:49] that's a lot of work [13:50] but it's super clean and nice if you can have that [13:50] even fans are powered by a contact connector [13:50] *connector [13:50] PCI graphics - bus powered using new high-current connectors [13:50] power switch - pogo pins [13:50] it's a lot of tweaking but I would love to see corsair or other vendors go that way [13:50] e.g. case with contact connectors that can be used for front / rear fans [13:51] with one cable that goes to the mobo [13:51] instead of a zoo [13:51] aaanyway [13:51] not snapd :) [13:52] imagine a PSU without any cables on it, just a card that slots into the board [13:56] and the kernel now has time namespaces [13:56] yay === ricab is now known as ricab|lunch [14:24] * zyga goes for a snow walk [14:53] cool, ci passed \o/ === ricab|lunch is now known as ricab [15:23] PR snapd#8065 closed: interfaces/builtin: Allow NotificationReplied signal on org.freedesktop.Notifications [15:35] kbroulik: thank you for the contribution! [15:35] * zyga is back [15:35] it's dark now [15:35] alright, thanks zyga, mborzecki, and mvo. that went a lot more smoothly than I would have thought! :) [15:35] :D [15:35]