[01:06] <mup> PR snapcraft#2406 closed: project_loader: add git to build-packages for version: git (#2403) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2406>
[04:43] <mup> PR core18#91 opened: Make /etc/default/swapfile be writable <Created by musicguitar> <https://github.com/snapcore/core18/pull/91>
[06:03] <mborzecki> morning
[06:35] <zyga> good morning
[06:36] <zyga> more red in tests
[06:36] <zyga> oh well
[06:36] <mborzecki> zyga: hey
[06:36] <zyga> :-)
[06:41] <mborzecki> zyga: looking into some opencl stuff from the forum, looks like none of the interfaces allows accessing /etc/OpenCL to read icd files, and then there's libnvidia-opencl which we do not pick up in s-c
[06:41] <zyga> oh man
[06:41] <zyga> another file to add
[06:41] <mborzecki> i'll rebuild my debugging snap with clinfo and see how far i get there
[06:41] <zyga> looking forward to removing that mess
[06:42] <zyga> good luck!
[06:42] <mborzecki> idk maybe we should have a 'compute' interace to cover cuda and opengl
[06:42] <zyga> opencl?
[06:42] <mborzecki> opencl right
[06:42] <mborzecki> too many open suffixes :P
[06:42] <mborzecki> prefixes
[06:42] <mborzecki> damn
[06:42] <zyga> open wtf :)
[06:42] <mborzecki> should get coffee
[06:42] <zyga> I'll take the dog out and focus on snap-update-ns and snapd feature flag for per user mouts
[06:43] <zyga> i have plenty of PRs that depend on each other
[06:43] <mborzecki> zyga: i'll have some questions about mount and MNT_DETACH that we do
[06:43] <zyga> need to add some leafs :)
[06:43] <zyga> yes?
[06:43] <zyga> shoot, I'll answer
[06:43] <mborzecki> zyga: we can do HO later
[06:43] <zyga> ok
[06:43] <zyga> mborzecki: can we aim for 9:00?
[06:43] <zyga> for the talk
[06:43] <mborzecki> sure
[06:44] <zyga> otherwise I'll be in my pijamas ;)
[06:59] <icey> where should I take a slightly comical snapcraft.io bug? doesn't hinder functionality but would probably be something we want to get fixed (we call French Guiana France in the map showing snap distribution)
[07:35] <mborzecki> hmm 'Download snap "core" (5940) from channel "edge" (received an unexpected http response code (503) when trying to download https://fastly.cdn.snapcraft.io/download-origin/fastly/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_5940.snap?token=1542276000_dc14a149f1c3974949f187187a7bfd71ceacfad9)'
[07:50] <mborzecki> snapcraft does not allow layouts?
[07:51] <mvo> mborzecki: I saw the fastly 503 error in spread, probably something for the store team to look at (cc sparkiegeek maybe?)
[07:52] <mvo> mborzecki: it looks like layout: was added to git Oct 10 in snapcraft but I doubt this is released yet
[07:52]  * mvo checks
[07:52] <mborzecki> mvo: found some info in https://forum.snapcraft.io/t/snap-layouts/7207
[07:52] <mvo> mborzecki: I wish we had the "published-into-channel" metadata already :)
[07:59] <zyga> It allows layouts since 3.x but you must also use a base
[08:04] <mborzecki> so mesa OpenCL implementation is listed by clinfo now
[08:06] <mborzecki> and no denials, that's probably because layouts opens up /etc/OpenCL/vendor
[08:07] <pstolowski> morning
[08:09] <mborzecki> pstolowski: hey
[08:09] <Chipaca> moin moin
[08:12] <mvo> hey Chipaca and pstolowski !
[08:13] <pedronis> morning (me is up since a bit for a meeting)
[08:15] <pedronis> zyga: mborzecki: hi, we should just close #6099 for now? right?
[08:15] <mup> PR #6099: cmd/snap-confine: always put the snap process under a device cgroup <⛔ Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
[08:15] <mborzecki> pedronis: yes, let me close it
[08:15] <pedronis> thx
[08:17] <mup> PR snapd#6099 closed: cmd/snap-confine: always put the snap process under a device cgroup <⛔ Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6099>
[08:17] <pedronis> Chipaca: hi, you are already working on the sanity check for epochs?
[08:17] <pedronis> Chipaca: I reviewed the send epochs one
[08:19] <Chipaca> pedronis: I am
[08:19] <Chipaca> pedronis: saw the review, will circle back in a bit
[08:19] <Chipaca> got distracted by the forum
[08:20] <Chipaca> and reddit
[08:20] <Chipaca> https://www.reddit.com/r/Ubuntu/comments/9x0b5r/and_this_is_one_reason_why_i_dislike_snaps/
[08:20] <Chipaca> somebody asks why we don't use a private mount namespace to hide these
[08:20] <Chipaca> I dunno if that'd work, but if it did, and it made people happy, maybe we should
[08:20] <pedronis> Chipaca: what are these?  (me not sure I want to get lost in reddit right now)
[08:21] <Chipaca> pedronis: nah, not worth your time, nothing actionable for us beyond the mount namespace question
[08:21] <pedronis> Chipaca: could you convert the card for the sanity check to doing otherwise I'll do it
[08:21] <Chipaca> uh, isn't it there already
[08:21] <Chipaca> i thought i'd put it in doing yesterday during the meeting
[08:22] <Chipaca> ah no 'send epoch' is doing
[08:22] <Chipaca> done
[08:23] <mborzecki> zyga: i got opencl & mesa to work, but there's some trouble with opencl and nvidia, i can get the libraries in, but the icd file is /etc/OpenCL/vendor/nvidia.icd in the host filesystem
[08:23] <Chipaca> done moving it to doing
[08:23] <Chipaca> not done done
[08:23] <mborzecki> zyga: though tbh as a workaround a snap could generte the file itself and use layouts to put it under /etc/OpenCL/vendor
[08:24] <pedronis> Chipaca: thank you
[08:31] <pedronis> pstolowski: hi, thanks for the checklist, making some cards for hotplug
[08:31] <pstolowski> pedronis: sure; i think we're stumbling on each other's feet right now, something unexpected just happend ;)
[08:32] <pedronis> pstolowski: oops, sorry
[08:32] <pstolowski> np
[08:32] <zyga> re
[08:32] <zyga> now to work :)
[08:32] <pedronis> mborzecki: I added some info to the "snap connections" card, I will look at plan/review the PR when I have gone through some slightly higher prio stuff
[08:33] <mborzecki> pedronis: thanks
[08:33] <zyga> mborzecki:I like the idea of snapd generating config files for hardware and injecting them in /etc
[08:33] <pstolowski> pedronis: can you explain "Doing" lane in the rules.. card? i'm abit unclear on that one (vs upcoming)
[08:34] <Chipaca> pedronis: I'm not sure I understand your comment on 6142: isn't amend _already_ an "install"?
[08:34] <pedronis> pstolowski: Doing means you are working on it,  upcoming for things you are planning to do but not working on yet
[08:34] <pedronis> some things might go straight to doing
[08:35] <Chipaca> pedronis: uh, now I see it
[08:35] <Chipaca> will fix
[08:35] <pedronis> Chipaca: :)
[08:35] <mup> PR snapd#6151 closed: snapd: allow snap-update-ns to read /proc/version <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6151>
[08:35] <pstolowski> pedronis: ok, thanks
[08:35] <Chipaca> pedronis: so the amend check is wrong in store
[08:35] <Chipaca> and maybe the amend test is also wrong
[08:35] <Chipaca> hmm hmm
[08:35]  * Chipaca stashes the checking work
[08:35] <pedronis> Chipaca: store as in our store package?
[08:36] <pedronis> or store store?
[08:36] <pedronis> anyway I'm quite sure we want that change
[08:36] <pedronis> and the rest should follow
[08:36] <zyga> one small trello tip
[08:36] <zyga> you can use the menu on the right to filter cards
[08:36] <zyga> e.g. to show all the cards you are a member of
[08:36] <zyga> very useful IMO
[08:36] <pedronis> yup
[08:37] <Chipaca> pedronis: the amend test i added in the store package
[08:37] <Chipaca> pedronis: sends the snap id (d'oh)
[08:38] <pstolowski> pedronis: ok, i created a couple of cards and left some in the checklist for hotplug for the time being
[08:38] <pedronis> pstolowski: thanks
[08:40] <pedronis> pstolowski: it looks reasonable, I think it matches what PR you have up etc, but indeed doesn't make sense having too much in doing or also in upcoming
[08:41] <pedronis> Chipaca: I admit I didn't look super closely at tests in the first pass
[08:41] <pedronis> also because I'm sure we were missing some or something (because of amend)
[08:43] <mborzecki> heh rebuilt my snap with core18 clinfo stopped working :/
[08:44] <mborzecki> anyone on 18.04?
[08:46] <zyga> mmm, no, 18.10
[08:47] <mborzecki> zyga: can you install clinfo package and run it?
[08:47] <zyga> sure
[08:48] <zyga> mvo: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4
[08:48] <mup> PR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
[08:49] <mvo> zyga: oh, looks like there is a leftover [Install] - thanks for spotting
[08:49] <zyga> mvo: I left a suggestion to apply
[08:49] <mvo> zyga: yeah, like it
[08:50] <mvo> zyga: https://github.com/snapcore/snapd/pull/6153/files#diff-0eac7194db86098b8f1b2084fb732ec4L5 is also wrong, I need to fix/revert this
[08:50] <mup> PR #6153: tests: use mock-gpio.py in enable-disable-units-gpio test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6153>
[08:50] <zyga> oh
[08:50] <zyga> I didn't notice
[08:50] <zyga> yeah
[08:51] <zyga> mborzecki: clinfo has one line of output
[08:51] <zyga> "Number of platforms"
[08:51] <zyga> what did you want from that?
[08:52] <mborzecki> hm so it must be one of the libs
[08:52] <zyga> 	linux-vdso.so.1 (0x00007ffda4f1c000)
[08:52] <zyga> 	libOpenCL.so.1 => /usr/lib/x86_64-linux-gnu/libOpenCL.so.1 (0x00007f45ae00e000)
[08:52] <zyga> 	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f45ae008000)
[08:52] <zyga> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f45ade1e000)
[08:52] <zyga> 	/lib64/ld-linux-x86-64.so.2 (0x00007f45ae453000)
[08:52] <zyga> ldd ^
[08:53] <mborzecki> zyga: i've installed beignet and pocl opencl implementations in the snap and opencl exits with an error from llvm now :/ probably one of the libs is doing something wrong or loading both of them breaks things
[08:54] <mvo> zyga: does lp 1786889 is something we fixed recently? I vaguely remember this error
[08:54] <zyga> mvo: yes
[08:54] <mvo> zyga: I will set to fix commited then
[08:54] <zyga> 4.18.0-041800-generi
[08:54] <zyga> this is a mainline kernel
[08:54] <mvo> oh
[08:54] <mvo> zyga: so this is just not supported?
[08:55] <zyga> not exactly, it should work with 2.36.x
[08:55] <zyga> we added some extra rules for that
[08:55] <zyga> same thing was affecting TW
[08:55] <mvo> zyga: ta
[08:57] <mborzecki> zyga: btw. generating vulkan icd file for nvidia looks tricky, there is an api version listed in the file, need to check if it's required, but from the looks of it the drivers declare different versions (eg. nvidia 1.1.82, intel 1.1.80)
[08:58] <zyga> it depends on how we generate  them
[08:58] <zyga> I think this is something we should take from a driver snap
[08:58] <mborzecki> sholud probably summarize the vulkan/opencl/glvnd craziness in a forum topic
[09:09] <mborzecki> mvo: have you tried to run core18 base snap apps with --strace ?
[09:12] <mvo> mborzecki: I don't know - does it fail?
[09:12] <mvo> mborzecki: never conciously tried it
[09:12] <mborzecki> mvo: it's getting stuck, can you try snap install test-snapd-tools-core18 and then snap run --strace test-snapd-tools-core18.echo foo ?
[09:13] <mborzecki> mvo: maybe we need to update th list of skipped syscalls
[09:13] <mvo> mborzecki: let me try that - I bet we need to blacklist one more systemcall :/
[09:14] <mup> PR snapd#6082 closed: overlord/ifacestate: set hotplug-key of the connection when connecting hotplug slots <Hotplug 🔌> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6082>
[09:17] <mup> PR snapd#6146 closed: ifacestate/helpers: added SystemSnapName mapper helper method <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6146>
[09:20] <mvo> mborzecki: fun, when I try to run tests-napd-tools.echo I get "unexpected wait status 0x8b"
[09:20] <mborzecki> mvo: adding -e !nanosleep unblocks it here
[09:21] <mvo> mborzecki: cool! will you do a PR or shall I?
[09:21] <pstolowski> Saviq: hey, it seems that installing/refreshing/removing multipass snap disconnect network for a short moment (or at least NM thinks it does); i suppose it's brige setup or something?
[09:21] <mborzecki> mvo: zyga pasted me a log from his run, and teher's no nanosleep there, i'm probably running a newer kernel so maybe something new was added to vdso
[09:21] <mborzecki> mvo: i'll open a PR
[09:21] <mvo> mborzecki: ok
[09:27] <Chipaca> mborzecki: pedronis: Thank you for your reviews of #6142! I believe I've addressed your concerns.
[09:27] <mup> PR #6142: overlord/snapstate, store: always send epochs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6142>
[09:27] <Chipaca> let me know if I should pull out any of those commits into their own PR
[09:28] <Chipaca> at least Epoch.Unset would stand alone if needed (but it's pretty trivial)
[09:29]  * Chipaca -> more coffee
[09:32] <pedronis> Chipaca: Unset is like Revision.Unset right? anyway the PR doesn't seem that big even after the changes
[09:36] <mup> PR snapd#6155 opened: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6155>
[09:36] <mborzecki> mvo: ^^
[09:37] <mvo> mborzecki: ta
[09:42] <pedronis> zyga: is there a easy way to use layouts to turn a read-only directory from the base into a writable directory into which things can get added?
[09:43] <Chipaca> pedronis: yes, exactly like Revision.Unset semantically
[09:43] <Chipaca> internal is different because different
[09:43] <Chipaca> also we had two places already doing that check so it's really less code :-p
[09:43] <zyga> pedronis: yes
[09:43] <Chipaca> anyway. I'd said I was getting more coffee and didn't. I shall now.
[09:44] <zyga> That’s available since improved content interface
[09:44] <pedronis> zyga: do you need to actually add a file in the layout? or just need to specify the directory?
[09:47] <mvo> hrm, it looks like our strace is not compatible with libnss-systemd, when I have this is installed the straced apps will segfault. oh well
[09:51] <zyga> pedronis: a directory is sufficient
[09:51] <zyga> We support both file and directory layout items
[09:51] <pedronis> zyga: apparmor would still need to le us through right, though. I'm thinking something like /etc/foo
[09:52] <pedronis> where foo exist in the base
[09:52] <Saviq> pstolowski: yeah, if NM is dumb enough
[09:52] <zyga> Yes, though the layout code does that too
[09:52] <Saviq> pstolowski: I never noticed it though, care to file a bug please?
[09:53] <pstolowski> Saviq: sure. could as well be a Mate NM indicator thing
[09:57] <Saviq> yeah if it doesn't filter the interfaces
[09:58] <Chipaca> hmmm. ssh -nNT -L ~/.snap/${remote}.snapd:/run/snapd.socket $remote
[09:58] <Chipaca> hmm
[10:00] <niemeyer> Guten Morgen
[10:01] <sparkiegeek> moin moin
[10:08] <pedronis> niemeyer: hi
[10:09] <pedronis> Chipaca: niemeyer: given that you worked/discussed this initially I would be interested in your input on this:  https://bugs.launchpad.net/snapd/+bug/1803212
[10:09] <mup> Bug #1803212: snap restart starts disabled services <snapd:New> <https://launchpad.net/bugs/1803212>
[10:09] <ondra> zyga about avahi, stable is one to use. I made pull request to upstream, but it has not been accepted yet, that's why git commit in version
[10:09] <Chipaca> pedronis: I think we fixed this recently
[10:10] <pedronis> Chipaca: ?
[10:10] <pedronis> Chipaca: fixed which way?
[10:10] <Chipaca> ah sorry no
[10:10] <ondra> zyga and once 2.36 lands, I current beta will go to stable to align it with classic, so clients can works same way on core and classic
[10:10] <Chipaca> pedronis: we fixed the "snap refresh restarts disabled services" one :-)
[10:10] <Chipaca> so close
[10:10] <pedronis> heh
[10:10] <pedronis> anyway
[10:11] <pedronis> I can think about it, but input from original design sources could be useful
[10:12] <niemeyer> pedronis: The way we cooked the commands gives a hint about what's reasonable there.. we can start something without it being enabled:
[10:12] <niemeyer>       --enable       As well as starting the service now, arrange for it to be started on boot.
[10:13] <Chipaca> why is launchpad so horrible at whitespace
[10:13] <niemeyer> ... for so long
[10:13] <sparkiegeek> Chipaca: because HTML, and backwards compatibility is hard?
[10:13] <niemeyer> pedronis: So IMO restart should not touch disabled services either
[10:14] <Chipaca> sparkiegeek: I've never not been frustrated by its handling of whitespace, so at least it's consistent
[10:14] <niemeyer> sparkiegeek: Given how many systems get this right, I don't buy it
[10:15] <pedronis> niemeyer: start should do though?
[10:15] <niemeyer> pedronis: If you specifically name it, yes
[10:15]  * Chipaca changes a <div> to a <pre> and is happier
[10:15] <niemeyer> pedronis: Sorry, let's explore this better:
[10:15] <pedronis> niemeyer: no, we are talking about <snap> here
[10:15] <pedronis> not single services
[10:16] <niemeyer> pedronis: If a service is running, it seems reasonable for it to be restarted
[10:16] <niemeyer> pedronis: No matter hwat
[10:16] <pedronis> I think the issue is what makes sense for restart <snap> vs overall consistency
[10:16] <niemeyer> pedronis: Same is true for stop
[10:16] <pedronis> niemeyer: what if something is not enabled but running, and one uses stop <snap>
[10:17] <niemeyer> pedronis: There's only one option that sounds sane from a user perspective, right?
[10:17] <pedronis> stopping it
[10:17] <niemeyer> Yep
[10:17] <pedronis> so we are left with snap start <snap>
[10:18] <niemeyer> That's the slightly tricky one, as there are two potentially valid expectations
[10:18] <pedronis> yes
[10:18] <pedronis> start everything (mimic stop), start only enabled
[10:18] <pedronis> (more like restart)
[10:19] <niemeyer> Yeah, except restart clearly makes some sense even for disabled services,  as long as they are running
[10:20] <pedronis> yes
[10:20] <pedronis> so stop stops everything running
[10:20] <pedronis> restart, restart everything running
[10:20] <pedronis> but start is trickier
[10:21] <niemeyer> I think there's way to define it
[10:21] <pedronis> notice also that the user asked for different behavior that these
[10:21] <niemeyer> There's one option which is more reasonable when running "snap stop" + "snap start"
[10:22] <niemeyer> Which is a pretty reasonable pair
[10:23] <niemeyer> I think we should make "snap start <snap>" only act on enabled services, and error out if all services are disabled
[10:23] <pedronis> ok
[10:23] <niemeyer> This way "snap stop <snap>" followed by "snap start <snap>" will tend to do the right thing
[10:24] <niemeyer> But "snap start <snap>.<app>" should work always, since it's a more clear request
[10:24] <pedronis> I can write something there, I also need to ask again if the user really meant what he wrote about restart disabled running doing nothing
[10:24] <pedronis> yes
[10:24] <niemeyer> snapctl should match
[10:24] <niemeyer> Otherwise it's error prone
[10:24] <pedronis> yea
[10:25] <Chipaca> should we add flags for the complimentary option?
[10:25] <Chipaca> ie snap start --all
[10:25] <Chipaca> or sth
[10:25] <Chipaca> snap restart --only-the-odd-numbered-ones
[10:25] <Chipaca> :)
[10:25] <Chipaca> complementary*
[10:25] <pedronis> Chipaca: snap start --enable <snap>  will imply all I think
[10:26] <pedronis> not sure it's enough
[10:26] <niemeyer> pedronis: What the user is asking for has little bearing unless the argument comes with rationale similar to the discussion we had above
[10:26] <pedronis> niemeyer: sorry, I'm not saying we should do what he says, but I just want to dig into the bit where il would diverge
[10:26] <niemeyer> pedronis: For example, the very first case suggested in the bug is already breaking reasonable expectations
[10:27] <niemeyer> pedronis: With a running service, having "snap restart <snap>" doing nothing is super awkward
[10:27] <niemeyer> pedronis: Yeah, makes sense
[10:30] <pedronis> Chipaca: given you worked on this how complicated would be restart only running ones?
[10:31] <mvo> mborzecki: when you have a moment I would love to talk about LP: #1791182 - I started a PR but your input would be great as this is something that happend with parallel installs changes
[10:31] <mup> Bug #1791182: Okular launcher present in Apps menu after removing Okular snap app <apps> <launcher> <menu> <okular> <snap> <snapd:In Progress> <https://launchpad.net/bugs/1791182>
[10:31] <Chipaca> pedronis: not too hard
[10:31] <Chipaca> pedronis: TOCTOU prone though
[10:32] <pedronis> Chipaca: mmh, there's try-restart (oddly named)
[10:33] <pedronis> which seems to do that
[10:35] <Chipaca> pedronis: and try-reload-or-restart
[10:35] <Chipaca> pedronis: this could work, for restart
[10:35] <Chipaca> if that's what's wanted :)
[10:36] <pedronis> Chipaca: just exploring
[10:37] <pedronis> no immediate action
[10:37] <pedronis> I need to answer/write a bit more in the bug
[10:37] <niemeyer> Chipaca: Yeah, given the name, try-reload-or-restart sounds like the right thing
[10:37] <niemeyer> Chipaca: It's the kind of command that likely made an appearance when people realized the default behavior was not the best one
[10:37] <mup> PR snapd#6156 opened: [RFC] wrappers: remove all desktop files from a snap on removal <Created by mvo5> <https://github.com/snapcore/snapd/pull/6156>
[10:38] <niemeyer> But it was too late to change get the default
[10:38] <Chipaca> to be clear: we'd do try-restart or try-reload-or-restart depending on whether --reload was given
[10:39] <Chipaca> on the other hand
[10:39] <Chipaca> if a service failed
[10:39] <Chipaca> 'snap restart' will stop starting it up again
[10:39] <pedronis> mmh
[10:42] <mvo> zyga: you mentioned you worked on a followup test in 6128 - is that in progress or shall I have a look at this?
[10:42] <mup> PR snapd#6127 closed: overlord/ifacestate: setup systemd backend in separate pass <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6127>
[10:42] <mup> PR snapd#6128 closed: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[10:43] <zyga> mvo: I'm working on that
[10:43] <zyga> mvo: just talking to maciej on HO now
[10:43] <mvo> zyga: cool
[10:46] <pedronis> Chipaca: restart if running, or enabled but failed doesn't roll on the tongue
[10:51] <Chipaca> so it'd be try- only if not specifying services (ie if specifying snaps)
[10:52] <Chipaca> i guess that's reasonable. We'd have to announce the behaviour change.
[10:52] <pedronis> yes
[10:56] <mup> PR snapd#6143 closed: cmd: install snap-discard-ns in "make hack" <Simple 😃> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6143>
[10:57] <Chipaca> pedronis: https://pastebin.ubuntu.com/p/tcgQXFcvmC/ <- is this something we'd want?
[10:57] <Chipaca> pedronis: or should we consider adding a column?
[10:57] <pedronis> Chipaca: I would put it only in info for now
[10:57] <Chipaca> (adding a column sounds perilous)
[10:58] <Chipaca> pedronis: I'd thought maybe add it in notes if != "0"
[10:58] <pedronis> it can get complicated/long
[10:58] <Chipaca> yes
[10:58] <Chipaca> almost arbitrarily long
[10:59] <pedronis> yea
[10:59] <pedronis> epochs should be fairly transparent to the user in the normal case
[10:59] <pedronis> unless one is debugging or it's a db snap or something
[10:59] <pedronis> but then info seems ok
[11:01] <pedronis> Chipaca: I mean we might end up doing something in list but I wouldn't start there before we have snaps using this around
[11:01] <pedronis> to think about
[11:02] <pedronis> showing the whole epoch doesn't seem an option there
[11:02] <Chipaca> ok
[11:02] <Chipaca> FWIW the max epoch currently would have len 240
[11:03] <pedronis> Chipaca: you are not making your case, if you are making one to put it there :)
[11:03] <Chipaca> pedronis: no i'm explaining that I understand the problems
[11:03] <pedronis> ok
[11:03] <Chipaca> pedronis: today epoch isn't seen by the client at all, fwiw
[11:04] <pedronis> a saving grace actually
[11:04] <pedronis> so far
[11:05] <pedronis> I know
[11:05] <pedronis> if we want to show in info we need to change that
[11:08] <Chipaca> :)
[11:09] <pstolowski> pedronis: described autoconnect difficulties https://forum.snapcraft.io/t/hotplug-autoconnect/8526 ; i only mentioned 3 interfaces as i'm not sure what else that we currently have makes sense for hotplug
[11:11] <pedronis> pstolowski: thanks
[11:12] <pedronis> pstolowski: I'll do a pass myself over the interface types and see if I find others relevant to this
[11:14] <mup> PR snapd#6157 opened: userd: force zenity width if the text displayed is long <Simple 😃> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6157>
[11:15] <clobrano> Hi all :), could anybody tell me whether the "version-script" stage is still supported (even if deprecated)? I'm having a weird Yaru build failure on Travis
[11:16] <mup> PR snapcraft#2402 closed: packaging: update requests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2402>
[11:23] <clobrano> ^ here is the log https://travis-ci.org/ubuntu/yaru/builds/454222505
[11:27] <cachio> zyga, hey
[11:27] <zyga> hi
[11:27] <cachio> after the images for bionic and cosmic were updated
[11:28] <cachio> systemd was upgraded
[11:28] <cachio> and now we can see the mount issue on those systems too
[11:28] <cachio> :(
[11:29] <cachio> zyga, most of the red builds are because of that issue
[11:29] <zyga> oh fun
[11:29] <zyga> I will be busy today
[11:29] <zyga> thanks for letting me know
[11:29] <mborzecki> yay
[11:29] <zyga> I will prioritise this
[11:29] <mborzecki> now we'll have to fix it :)
[11:30] <mvo> degville: hi, I subscribed you to bug lp 1745037 - hope you don't mind, looks like a relatively straightforward docs fix
[11:30] <cachio> mborzecki, sadly yes
[11:30] <cachio> :)
[11:33] <pstolowski> pedronis: in theory we could maybe have hotplug for e.g. removable media, but i'm not sure if it makes sense in practice
[11:34] <mup> PR snapd#6069 closed: ifacestate/hotplug: removeDevice helper <Hotplug 🔌> <Simple 😃> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6069>
[11:38] <Chipaca> mvo: cachio: do any of our test-snapd- snaps have branches ?
[11:39] <cachio> cachio, no
[11:39] <cachio> at least mine
[11:39] <cachio> Chipaca,
[11:39] <Chipaca> cachio: ta
[11:39] <Chipaca> cachio: is test-snapd-tools one of yours?
[11:39] <cachio> Chipaca, no
[11:39] <Chipaca> cachio: ok
[11:40] <degville> mvo: thanks - I'll take a look!
[11:40] <mup> PR snapcraft#2404 closed: cli: handle yaml errors for cleanbuild <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2404>
[11:40] <mvo> 5845 is green! a second review would be great (maybe from jdstrand  ?)
[11:41] <mvo> Chipaca: they are all(?) owned by the canonical account and shared
[11:41] <mvo> Chipaca: aren't branches not long lived? or is that controlled easily server side?
[11:42] <zyga> fun
[11:42] <Chipaca> um
[11:42] <zyga> two bugs
[11:42] <Chipaca> mvo: i meant tracks
[11:42] <zyga> well, two *new* bugs
[11:42] <Chipaca> cachio: sorry i meant tracks :-)
[11:42] <zyga> one in snap-confine and one in snap-update-ns
[11:44] <mvo> Chipaca: not afaik - lets create one for test-snapd-tools?
[11:45] <Chipaca> mvo: +1
[11:45] <Chipaca> mvo: i'm wanting to have something to test epochs from the store with
[11:45] <Chipaca> easiest, other than having a  snap just for that, is adding a track
[11:45] <Chipaca> otherwise I could just make a test-snapd-epoch snap
[11:46]  * mvo nods
[11:46] <Chipaca> mvo: which would you rather?
[11:52] <zyga> mborzecki: fixed
[11:52] <zyga> mborzecki: the 2nd bug
[11:52] <zyga> the 1st bug will be next shortly
[11:52] <mborzecki> zyga: ok, ping me for reviews, i'm keen to try it out on centos
[11:53] <sergiusens> icey: you might want to report an issue for the webteam
[11:58] <mvo> Chipaca: ups, missed the quesiton - either way is fine, sorry. maybe test-snapd-epoch is simpler as we don't need to ask the store for creating of a track
[12:04] <mvo> cachio: hey, so I would like to write a spread test for {personal,system}-files it needs a snap declaration to connect the interface, do we have test for similar interfaces already that I could use as a blueprint?
[12:06] <zyga> mborzecki: spread test in flight
[12:12] <mborzecki> are interface hooks supported by snapcraft?
[12:14] <Chipaca> mvo: can you register test-snapd-epoch and invite me to collaborate on it?
[12:14] <Chipaca> mvo: (in the Canonical account i mean)
[12:14] <mvo> Chipaca: sure
[12:14] <Chipaca> mvo: if you need to push a revision to collaborate, rename tests/lib/snaps/basic :-)
[12:14] <Chipaca> I don't intend it to do anything (for now at least)
[12:15] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/6158
[12:15] <zyga> 2nd bug
[12:15] <zyga> now looking at 1st
[12:15] <mup> PR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
[12:15] <mup> PR snapd#6158 opened: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
[12:16] <cachio> mvo, and what does it do?
[12:16] <cachio> sh?
[12:16] <mvo> Chipaca: you should have mail
[12:16] <mvo> cachio: it allows access to files outside of the regular confinmement
[12:16] <mvo> cachio: e.g. $HOME/.my-folder
[12:17] <cachio> ok, so you can use the sh snap
[12:17] <cachio> one sec
[12:17] <cachio> mvo, test-snapd-sh
[12:18] <cachio> just add the app there
[12:18] <cachio> with the plug you want
[12:18] <cachio> and that's it
[12:19] <cachio> mvo, in the test then you can do test-snapd-sh.<your-app> "ls <path>"
[12:19] <cachio> i.e. test-snapd-sh.with-broadcom-asic-control-plug -c "cat /dev/$device"
[12:20] <cachio> mvo, does it work for you?
[12:23] <mvo> cachio: I will look into it some more after lunch, thanks
[12:23] <cachio> mvo, ok, I can create the test if you want
[12:23] <cachio> mvo, so you can take other stuff
[12:24] <cachio> I created many similar tests before
[12:25] <zyga> mvo: can you please review https://github.com/snapcore/snapd/pull/6123
[12:25] <mup> PR #6123: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <https://github.com/snapcore/snapd/pull/6123>
[12:25] <zyga> -4029
[12:25] <zyga> -402 +8 changes
[12:26] <Chipaca> mvo: thanks
[12:26] <mvo> cachio: that would be great, I'm not sure though if "deny-connection: true" will make things more complicated for the test
[12:26] <mvo> cachio: but either way, help with the spread test would be great
[12:26] <mvo> zyga: gladly
[12:27] <mvo> zyga: whats not to like about this amount of "-"
[12:30] <cachio> mvo, nice, I'll start with it today
[12:30] <cachio> mvo, "deny-connection: true" shouldn't be a problem
[12:51] <zyga> if anyone has review time, this is the only feature PR to review from my stuff: https://github.com/snapcore/snapd/pull/6145
[12:51] <zyga> +87 -10 so not terrible
[12:51] <zyga> mostly just tests
[12:51] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[12:51] <zyga> actually not mostly just tests
[12:51] <zyga> but not much anyway :)
[13:10] <mborzecki> off to pick up the kids
[13:34] <pstolowski> Chipaca: i'd be happy to approve #6107 when you add the missing test case, then it could land
[13:34] <mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
[13:37] <pedronis> pstolowski: I was a bit surprised that it really did show the column, not even name
[13:37] <pedronis> I mean 6107
[13:40] <pedronis> also the prereq doesn't have two reviews
[13:40] <pedronis> Chipaca: I left a note in #6107, we should talk a sec on it
[13:40] <mup> PR #6107: cmd/snap, snapctl: add column selectors to services <Created by chipaca> <https://github.com/snapcore/snapd/pull/6107>
[13:41] <mborzecki> re
[13:42] <zyga> mborzecki: first bug also fixed, spread test took longer to write
[13:42] <zyga> but I'm happy with the outcome
[13:42] <mborzecki> pstolowski: question about interface hooks, is the hooks executed under the security profile that comes from the interface?
[13:42] <zyga> much better than the original unit test
[13:42] <zyga> fired it up now, should be ready by standup
[13:42] <mborzecki> zyga: thanks for the fixes :)
[13:42] <zyga> thank you for finding bugs :)
[13:43] <mborzecki> heh
[13:43] <pstolowski> mborzecki: depends, prepare-slot-*, prepare-plug-* - are not. connect-plug-*, connect-slot-* yes
[13:43] <pstolowski> pedronis: hmm, i see what you mean
[13:44] <mborzecki> pstolowski: i'm using connect-plug-opengl, hm maybe i need to look into that further
[13:47] <pstolowski> mborzecki: let me know the details if you obseve anything suspicious. you might be the first one to make use of interface hooks..
[13:48] <mborzecki> pstolowski: i don't need to declare plugs for interface hooks, do I? i mean it's it's a connect-plug-opengl hook then it runs with opengl plug implicitly, doesn't it?
[13:53] <zyga> mborzecki: interesting but doubtful
[13:53] <zyga> mborzecki: the hooks have the snap-level interfaces only
[13:53] <sergiusens> zyga: I am getting this cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied when I try to run a snap try inside lxd
[13:53] <zyga> anything scoped will *not* affect hooks
[13:53] <zyga> sergiusens: what's the kernel version and snapd version?
[13:54] <zyga> sergiusens: please report a bug, I will investigate
[13:54] <pedronis> mborzecki: there is no code to make that implicit afaik, so either global plug, or the hook needs to list the plug
[13:54] <zyga> sergiusens: (we're now using bugs for ... bugs) :-)
[13:54] <sergiusens> https://www.irccloud.com/pastebin/SoCmFTkp/
[13:54] <sergiusens> zyga: I do not believe you!
[13:55] <sergiusens> I have been conned into reporting bugs before ;-)
[13:55] <zyga> sergiusens: thank you, the host is ~~~ 18.04 or newer, I presume?
[13:55] <zyga> sergiusens: and the host is xenial container, right?
[13:55] <sergiusens> yes, xenial
[13:55] <sergiusens> also, the snap uses bases
[13:55] <mborzecki> pedronis: yup, adding plug explicitly made it work
[13:56] <zyga> sergiusens: please report it, I'll check it out after writing tests for another fix
[13:59] <pstolowski> zyga: one question re 6145, otherwise +1
[13:59] <zyga> looking
[14:01] <zyga> pstolowski: replied
[14:01] <zyga> thank you for the review, this PR is the most important to move other mount stuff forward
[14:02] <pedronis> Chipaca: standup ?
[14:02] <pedronis> zyga: ^
[14:02] <zyga> oh, joining
[14:03] <sergiusens> zyga: got it to work by installing core...
[14:03] <zyga> sergiusens: interesting
[14:05] <mup> PR snapd#6159 opened: cmd/snap-confine: handle mounted shared /run/snapd/ns <Created by zyga> <https://github.com/snapcore/snapd/pull/6159>
[14:14] <om26er> popey: ping
[14:14] <popey> PONG!
[14:15] <zyga> echo echo echo
[14:15] <om26er> popey: the asciinema upstream wants to update its snap to latest version but the snap was uploaded by MarkS, so wanted to know what's the procedure to get that snap uploaded from their official account ?
[14:16] <om26er> https://github.com/asciinema/asciinema/issues/296#issuecomment-438025083
[14:16] <popey> Wimpress is about to be in the same physical location as sabdfl, maybe he could mention it :)
[14:17] <om26er> so basically they are willing to move the packaging under their github org and I am committing to maintenance there.
[14:17] <popey> (I think transferring the snap upstream is the best course of action)
[14:17] <om26er> yep
[14:18] <popey> i have let wimpy know, he's on a plane right now, but I'm sure he'll pass the message on when he gets there :)
[14:18] <popey> thanks for letting us know om26er
[14:18] <om26er> popey: sounds good to me, cheers!
[14:22] <mup> PR snapd#6160 opened: nvidia, interfaces/builtin: OpenCL fixes <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6160>
[14:57]  * cachio lunch
[14:58] <Wimpress> At the airport. I'll mention to Mark.
[15:08] <zyga> quick break
[15:17]  * pedronis mostly eods (will be back for some meeting later)
[15:20] <mvo> mborzecki: heh, I was about to ask about 6160 and if we should pull it into 2.36 and then you added the milestone. thanks for this!
[15:21] <mup> PR snapd#6160 closed: nvidia, interfaces/builtin: OpenCL fixes <Simple 😃> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6160>
[15:21] <mvo> mborzecki: could you please create a pr based on 2.36 for this? I tried to cherry-pick but the second commit does not apply cleanly
[15:22] <mborzecki> mvo: sure
[15:22] <mvo> ta
[15:24] <mborzecki> mvo: i think we shoud also pick https://github.com/snapcore/snapd/pull/5696
[15:24] <mup> PR #5696: interfaces/opengl: add additional accesses for cuda <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5696>
[15:24] <mvo> mborzecki: ok, let me see if I can cherry pick this
[15:25] <mborzecki> also that's what 6160 is conflicting with
[15:25] <mvo> mborzecki: done, this is in 2.36 now
[15:25] <mborzecki> mvo: ta
[15:26] <mborzecki> mvo: 6160 will now apply cleanly on top of 2.36, do you want to me open a PR?
[15:27] <mvo> mborzecki: no, thats fine then
[15:27] <mborzecki> ok
[15:28] <mvo> mborzecki: done, thanks again
[15:28] <mborzecki> np
[15:57] <zyga> re
[15:57] <zyga> taht was a longer quick break but I did handle both lunch and the dog :)
[15:57] <sparkiegeek> ate the dog and fed the lunch?
[15:58] <zyga> unfortunately no hot-dogs :)
[15:59]  * zyga sighs seeing a test fail on 14.04 
[15:59] <zyga> "fun"
[15:59] <zyga> they said crying ;)
[15:59] <zyga> let's see
[16:01] <pstolowski> zyga: #6158 can land?
[16:01] <mup> PR #6158: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <https://github.com/snapcore/snapd/pull/6158>
[16:01] <zyga> pstolowski: yes, please
[16:01] <mup> PR snapd#6158 closed: cmd/snap-update-ns, tests: clean trespassing paths <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6158>
[16:02] <zyga> mvo: can we have milestones on launchpad?
[16:03] <zyga> now that we have bugs we could do that too :)
[16:03] <mvo> zyga: yeah
[16:03]  * zyga could use a 2nd review on https://github.com/snapcore/snapd/pull/6145
[16:03] <mborzecki> zyga: 6158 for 2.36 too?
[16:03] <zyga> mvo: I looked but I cannot add any
[16:03] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[16:03] <zyga> mborzecki: so that's a good question, I can make a backport if mvo agrees
[16:04] <zyga> it's fairly simple and significant
[16:04] <mvo> zyga: I created one, how do you want to use it?
[16:04] <zyga> one sec
[16:04] <mvo> zyga: backport for what? sorry, miss context
[16:04] <zyga> mvo: sorry, two topics
[16:05] <zyga> mvo: one topic: the milestone, on lauchpad, I'd love to be able to set milestone for this bug: https://bugs.launchpad.net/snapd/+bug/1803535
[16:05] <mup> Bug #1803535: Certain layouts cannot be constructed correctly <snapd:Fix Committed by zyga> <https://launchpad.net/bugs/1803535>
[16:05] <mvo> zyga: added the milestone, go wild
[16:05] <zyga> mvo: topic two, shall I create a backport for this issue and propose it for 2.36 release branch?
[16:05] <zyga> mvo: I don't have the permission
[16:05] <mvo> zyga: yes please, also no need for a backport if it can be cherry-picked cleanly
[16:05] <zyga> mvo: so shall I just push into the release branch?
[16:05] <mvo> zyga: I created the milestone in LP now, do you need more?
[16:05] <zyga> it should be clean
[16:06] <mvo> zyga: yeah, if its clean cherry picks thats fine
[16:06] <zyga> mvo: yes, I cannot assign the milestone to the bug
[16:06] <zyga> not sure which LP permission governs that
[16:06] <mvo> zyga: I targed it to the series
[16:07] <mvo> zyga: but you should also be able to do that
[16:07] <zyga> milestone column was empty for me
[16:07] <zyga> thanks for doing that
[16:07] <zyga> I see "target to series"
[16:07] <zyga> and I can target it for "trunk"
[16:09] <mvo> zyga: that is confusing, let me check
[16:09] <zyga> mvo: cherry picked and pushed to the 2.36 release branch
[16:09] <zyga> mvo: I TG a screenshot of what I see
[16:10] <mborzecki> zyga: findmnt in ubuntu 14.04 cannot do --output=PROPAGATION
[16:14] <zyga> mborzecki: yeah, I just installed it to play
[16:14] <zyga> blast from the past :)
[16:14] <zyga> unity
[16:15] <zyga> mborzecki: there's RHEL 8 beta!
[16:16] <mborzecki> zyga: heh, which kernel version? 3.17? :)
[16:16] <zyga> hold on :)
[16:19] <zyga> mborzecki: downloading, I will let you know
[16:20] <mborzecki> zyga: hm don't see it on developers.redhat.com
[16:21] <zyga> you need to opt into the beta
[16:21] <zyga> hold on
[16:21] <mborzecki> aah there it is
[16:21] <zyga> https://access.redhat.com/products/red-hat-enterprise-linux/beta?extIdCarryOver=true&sc_cid=70160000000dJVaAAM
[16:22] <zyga> mborzecki: boot iso or binary dvd?
[16:22] <zyga> I'll get both
[16:22] <zyga> but weird...
[16:23] <mborzecki> zyga: signed up just now
[16:23] <thresh> at least 4 something cause it says bbr everywhere
[16:24] <thresh> you need binary
[16:24] <thresh> at least thats what they say in the mail
[16:25] <mborzecki> zyga: hm ppc64le, aarch64 :)
[16:25] <zyga> mborzecki: and there's a new raspberry pi!
[16:25] <zyga> Pi 3 A+
[16:25] <zyga> no eth, just wifi
[16:25] <zyga> 119PLN
[16:25] <mborzecki> no emmc?
[16:25] <ogra> yeah ... as poorly designed as the b+
[16:25] <zyga> 512MB ram
[16:25] <zyga> WTF
[16:25] <ogra> (high speed networking on a USB2 hub)
[16:26] <zyga> no emmc
[16:26] <ogra> indeed
[16:26] <zyga> I'll pass
[16:26] <ogra> only the cm3 has MMC
[16:26] <mborzecki> so still nothing more than a curiosity ;)
[16:26] <ogra> yeah
[16:27] <mborzecki> wish i could do something useful with my CHIP though
[16:27] <ogra> port core to it !
[16:27] <mborzecki> iirc there was a gadget for it
[16:28] <zyga> what's the HW inside the chip?
[16:28] <ogra> there is a chip inside the chip ;)
[16:29] <zyga> yes :D
[16:29] <mborzecki> zyga: https://en.wikipedia.org/wiki/CHIP_(computer)
[16:29] <mborzecki> the company went belly up :)
[16:30] <zyga> making products for $9 tends to make that happen
[16:31] <zyga> I think I know how to use findmnt and not cry a river over 14.04
[16:31]  * zyga tweaks
[16:34] <ogra> well, marketing it for $9 and producing it for $30 or so ...
[16:34] <ogra> wasnt the cleverest strategy :)
[16:35] <mup> PR snapcraft#2409 opened: python plugin: process deps before and separately from setup.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2409>
[16:43]  * zyga -> school 
[17:02] <zyga> ok, fixed 14.04 tests (hopefully)
[17:08] <mup> PR snapd#6155 closed: cmd/snap: add nanosleep to blacklisted syscalls when running with --strace <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6155>
[17:10] <cachio> mvo, sorry, is it .dot files interface already merged?
[17:12] <mvo> cachio: it is still in review, one sec, let me find the pr number
[17:13] <mvo> cachio: 5845
[17:13] <cachio> mvo, I just discovered that
[17:13] <cachio> thanks
[17:14] <mvo> yw
[17:14] <mvo> thanks for looking into it
[17:15] <cachio> I could add the test to that PR, or create a new branch, what do you prefrer?
[17:16] <mup> PR snapd#6123 closed: cmd/snap-confine,snap-update-ns: discard quirks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6123>
[17:25] <zyga> mvo: I didn't notice https://github.com/snapcore/snapd/pull/6128 is merged!
[17:25] <mup> PR #6128: overlord/ifacestate: setup security backends phased by backends first <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6128>
[17:25] <zyga> I'll push tests to a follow-up
[17:25] <zyga> can we get an edge build
[17:25] <zyga> and let the customer know
[17:34] <zyga> anyone for a 2nd review of https://github.com/snapcore/snapd/pull/6145 ?
[17:34] <mup> PR #6145: cmd/libsnap: add sc_verify_snap_lock <Per-user mount ns  🐎> <Created by zyga> <https://github.com/snapcore/snapd/pull/6145>
[17:42]  * zyga considers wrapping up
[17:43] <zyga> mvo: do you think you could look at https://github.com/snapcore/snapd/pull/6111 tomorrow, nothing binding, just tell me what you think
[17:43] <mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
[17:43] <zyga> mainly at the makefile path
[17:43] <zyga> as spec file is probably not terribly interesting
[19:09] <popey> Is there some env var I need to set for classic snaps to 'find' GL drivers? Where do I point it?
[19:09] <popey> (not using desktop helpers)
[20:02] <mup> PR snapd#6161 opened: tests: new test suite to run snapd tests on a google remote instance <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6161>
[20:22] <zyga> popey: dunno
[20:22]  * zyga came to check on PRs
[21:48] <mup> PR snapd#6162 opened: interfaces/greengrass_support: update accesses for GGC 1.6 <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6162>