[00:02] <kyrofa> That type of thing has been pretty handy for me in the past, I'd rather not lose it
[00:05] <kyrofa> Suddenly all commands must be 1) binaries within the snap, and 2) be paths relative to the root of the snap, when historically neither was the case
[00:06] <kyrofa> (from the point of view of a user of the snapcraft CLI)
[00:12] <niemeyer> kyrofa: Historically that was actually the case in the design we discussed at least
[00:12] <niemeyer> kyrofa: It's trivial to have any content inside a script
[00:13] <niemeyer> kyrofa: And the path of the command being relative to the snap just means you know what you are calling
[00:14] <niemeyer> kyrofa: Instead of trusting on the environment of the snap to define what a command even means
[00:14] <niemeyer> kyrofa: The application stanza was supposed to be a way to hook up a script, not be the script
[00:15] <niemeyer> kyrofa: EIther way, we have what we have.. let's catch up next week and spend some quality time to agree on a way to move forward that has more pros than cons
[00:16] <niemeyer> kyrofa: By the way, that's always been part of the reason why I have a deep dislike for wrappers.. it makes it all magical and hard to understand a consistent design
[01:19] <hunterk> hey guys, does vulkan work with snap packages?
[01:27] <hunterk> I ask because I make the snap package for RetroArch and I've been trying to get our vulkan driver to work with it but it's just not coming together
[01:28] <hunterk> I figured I'd check here before continuing to bang my head against it
[01:29] <hunterk> it looks like libvulkan1 is getting included properly...
[07:02] <pstolowski> morning
[07:31] <zyga> hey hey
[07:31] <zyga> boy, what a damp morning it is
[08:03] <Chipaca> moin moin
[08:04] <Chipaca> have you seen https://launchpadlibrarian.net/378130619/journalctl_-u_snapd.txt ?
[08:04] <Chipaca> not sure what to make of it
[08:05] <zyga> good morning Chipaca
[08:05]  * zyga looks
[08:06] <zyga> Chipaca: hmm, we are type: notify
[08:07] <zyga> and it seems we didn't respond in time
[08:07] <Chipaca> zyga: yeah, this is attached to the #1779948 so maybe it's just that
[08:07] <mup> Bug #1779948: Snapd gets stuck when starting Ubuntu. <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1779948>
[08:07] <Chipaca> zyga: the dns thing threw is what puzzles me though
[08:08] <zyga> that dns thing looks like resolved
[08:08] <Chipaca> zyga: did they call it that just to make conversation about its bugs harder
[08:08] <zyga> Chipaca: could it be first boot and seeding and what not on an offline system with super laggy dns
[08:08] <zyga> like I have a dns at home that doesn't work over tcp
[08:09] <zyga> and doesn't work over udp with packet fragmentation
[08:09] <zyga> so stuff keeps falling back to older/crappier version
[08:09] <zyga> but it takes time each time
[08:09] <zyga> actually
[08:09] <zyga> about that:
[08:09] <Chipaca> zyga: it's not first boot (earlier in the log output you see things being fine)
[08:09] <zyga> Chipaca: I read that you can tell systemd that you are alive and still starting
[08:09] <zyga> but not ready yet
[08:09] <Chipaca> zyga: yes
[08:09] <zyga> and then systemd extends the startup timeout
[08:09] <pedronis> anyway reaching notify shouldn't involve seeding or any task really
[08:09] <zyga> maybe we should?
[08:10] <Chipaca> zyga: problem is that the random drain was done from an init() i think, so too early for us
[08:10] <Chipaca> early and in arbitrary order i think (but i'm not sure)
[08:10] <Chipaca> pedronis: mo'in! how're you doing today?
[08:10] <pedronis> could be better, could be worse
[08:11] <pedronis> Chipaca: could you look at #5473 when you have a bit of time
[08:11] <mup> PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
[08:12] <Chipaca> pedronis: yep
[08:12] <pedronis> Chipaca: I suppose, I should look at the warnings PR when I have a bit of time
[08:13] <Chipaca> pedronis: no rush
[08:32] <Chipaca> afk, bbiab (need to go to the boys' school)
[09:07] <pstolowski> need to take my daughter to the doctor, bbiab
[09:15] <mup> PR snapd#5499 opened: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
[09:17] <mup> PR snapd#5500 opened: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
[09:23] <mup> PR snapd#5501 opened: interfaces: allow invoking systemd-notify when daemon-notify is connected <Created by zyga> <https://github.com/snapcore/snapd/pull/5501>
[09:34]  * Chipaca returns
[09:35] <Chipaca> zyga: did you see what i said yesterday about not trying to start an app with an unconnected daemon-notify?
[09:37] <zyga> mmmj
[09:37] <zyga> maybe/
[09:37] <zyga> I thought that was Samuele
[09:37] <zyga> can you repeat please?
[09:40] <Chipaca> zyga: “what we should do in snapd is not try to start a service if it's type:notify and it's not connected”
[09:40] <Chipaca> that last 'it' is the daemon-notify interface
[09:42] <zyga> mmm
[09:42] <zyga> I didn't see that
[09:42] <zyga> not sure if I agree, we should generalize that to be able to say
[09:42] <zyga> this snap cannot be installed (or perhaps activated) when {set of interfaces} are not connected
[09:48] <zyga> Chipaca: something like: plugs: daemon-notify: required: true
[09:51] <Chipaca> zyga: the problem with generalising it is that then you need to make it general
[09:52] <zyga> well, the problem of specializing it is that then you need to make it general too ;)
[09:52] <Chipaca> zyga: first of all, required:true sounds wrong, like the snap won't install
[09:52] <Chipaca> zyga: but that's just a name
[09:52] <Chipaca> zyga: what happens if you put required:true on an app?
[09:52] <Chipaca> on a plug on an app i mean
[09:52] <zyga> Chipaca: one of the questions is if we want to have partially enabled snaps
[09:52] <zyga> like you have app1 and app2 but not app3
[09:53] <Chipaca> zyga: and it starts to seem more masturbatory than practical
[09:53] <zyga> Chipaca: the syntax won't allow that AFAIK but even if it did my point was to indicate a given plug or slot as required, not the association
[09:53] <Chipaca> zyga: I didn't follow that last bit
[09:54] <zyga> defining a plug or slot on an app does two things:
[09:54] <zyga> defines the plug or slot
[09:54] <zyga> indicates association with an app
[09:54] <zyga> my point was that the attribute ought to be associated with the interface, not with the association
[09:54] <zyga> my gut feeling is this:
[09:54] <zyga> let's sleep over it, think and come up with brainstorm material
[09:55] <zyga> we can implement the subset for daemon-notify once we know where we want to go to
[09:55] <zyga> so that we can implement a slice of the bigger cake
[10:00] <Chipaca> zyga: where is this cake, and does it go well with coffee
[10:00] <zyga> Chipaca: you are tempting me sir ;)
[10:00] <Chipaca> zyga: cakes that don't go well with coffee: https://en.wikipedia.org/wiki/Yellowcake
[10:00] <zyga> there is raspberry cake indoors
[10:01] <zyga> it's raining all night and all morning here
[10:01] <zyga> so mood is perfect for cake
[10:03] <Chipaca> zyga: nice gentle rain in the middle of a forest? heck yea
[10:03] <zyga> Chipaca: heck ...bzzzz (mosquito) yeah :(
[10:03] <Chipaca> cake and spiced tea, or spiced cake and tea
[10:03] <zyga> it's okay but at most 2/3 days a week
[10:04] <zyga> I recall summer holidays when there was really no day without this never-ending rain
[10:04] <Chipaca> zyga: ah, yes, after the second night it suddenly becomes a dystopia
[10:04] <zyga> it's supposed to rain for the next 10 days
[10:04] <Chipaca> "la ciénaga" but with rain
[10:05] <Chipaca> zyga: "oops they moved my flight i need  to leave right now to make it byeeeee"
[10:05] <zyga> hahah
[10:05] <zyga> montreal feels like going to the other hemisphere now
[10:06] <Chipaca> zyga: almost but not quite
[10:06] <Chipaca> vancouver would be
[10:07] <Chipaca> zyga: bah, even montreal gets you from positive to negative longitudes
[10:07] <Chipaca> so technically yes :-)
[10:12] <niemeyer> Mornings
[10:14] <Chipaca> [citation needed]
[10:19] <zyga> my LTE link is down
[10:19] <zyga> not sure if I can do standup video today
[10:19] <zyga> if the weather continues like that
[10:20] <AuroraAvenue> It surprises me that there are no separate ways to flag an issue with the developer with snap - except github or launchpad.
[10:23] <popey> AuroraAvenue: do you have a specific issue to report?
[10:31] <AuroraAvenue> popey, well I am tired, very tired, but if its an issue ya want then its an issue I'll grant you.
[10:31] <AuroraAvenue> Xonotic doesn't open on Solus Os.
[10:31] <popey> is there any kind of error message?
[10:32] <popey> (if launched from the command line)
[10:32] <AuroraAvenue> erm, hangon #fatfingers (me).
[10:33] <AuroraAvenue> https://paste.ubuntu.com/p/Vhs5CgqK2J/
[10:34] <popey> interesting. what's the output of `snap version` please?
[10:35] <AuroraAvenue> I type > snap xonotic , right ?
[10:35] <popey> `snap version`
[10:35] <AuroraAvenue> oh sorry
[10:36] <popey> I just installed it on Solus here and it works.
[10:37] <AuroraAvenue> https://paste.ubuntu.com/p/PdDgrwtjCd/
[10:37] <AuroraAvenue> must be my crud laptop, then.
[10:38] <AuroraAvenue> popey, this isnot a pressing issue by the way.
[10:38] <popey> it is more likely a kernel issue
[10:38] <niemeyer> popey, AuroraAvenue: That looks like a confinement issue.. from the error message, looks like it cannot change to another apparmor profile
[10:38] <niemeyer> zyga ^
[10:38] <niemeyer> zyga: Any ideas?
[10:38] <zyga> looking
[10:38] <AuroraAvenue> right - originally install from solus 3.999 - its updated to past v.4 now - all upto date though.
[10:39] <zyga> AuroraAvenue: hey
[10:39] <zyga> I reported this issue to ikey a few weeks ago
[10:39] <AuroraAvenue> hello
[10:39] <zyga> AuroraAvenue: please run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/*
[10:39] <AuroraAvenue> right-oh
[10:39] <zyga> and see if this fixes the issue
[10:39] <niemeyer> AuroraAvenue: Depending on the version of snapd you are using, the snapd there may not be able to tell that the world shifted around it
[10:39] <niemeyer> AuroraAvenue: More recent versions (as of several months now) can tell that, and will recompile things automatically when necessary
[10:40] <zyga> it seems that apparmor in solus stopped loading profiles generated by snapd on boot
[10:40] <niemeyer> AuroraAvenue: But it may always be an unrelated bug, obviously
[10:40] <Chipaca> popey: what was the name of that better zenity you were using for i-don't-remember-which-snap?
[10:40] <popey> yad
[10:40] <popey> (used in tmnationsforever)
[10:40] <Chipaca> popey: care to comment on https://forum.snapcraft.io/t/zenity-dialogs-in-a-snap/6359 about the why?
[10:41] <Chipaca> popey: otherwise I will, and steal your karma
[10:41] <AuroraAvenue> Okay - were rockin' xonotic now :D
[10:41] <popey> woohoo
[10:41] <Chipaca> AuroraAvenue: now put down the fps and get some sleep
[10:41] <AuroraAvenue> yeah - must go to bed, your very true.
[10:41] <AuroraAvenue> okay bye then.
[10:41] <popey> :)
[10:41] <AuroraAvenue> & thank-you
[10:42] <popey> thanks for the report
[10:46] <zyga> I'll ask ikey again
[10:50] <popey> zyga: does this only affect new installs?
[10:50] <popey> my vm works fine, and it's up to date
[10:53] <daniellimws> hi, I know someone that recently received emails regarding snapcraft saying packages from the Ubuntu archive have received security updates, and even after making a small commit to rebuild the snap, he still receives these emails
[10:53] <daniellimws> may I know if there's anything he missed?
[10:54] <daniellimws> https://github.com/dj3500/hightail/pull/105#issuecomment-349701547
[10:54] <mup> PR dj3500/hightail#105: Add snapcraft <Created by daniellimws> <Merged by dj3500> <https://github.com/dj3500/hightail/pull/105>
[10:54] <popey> daniellimws: he probably got multiple emails over a few days
[10:54] <popey> one for libjpeg and another for libcups2 and libpng12
[10:55] <daniellimws> oh, so he does not need to do anything right? it will stop soon?
[10:55] <popey> No, it will not stop.
[10:55] <popey> He only gets one mail per security update.
[10:55] <popey> but there were likely two security mails for different libraries.
[10:55] <popey> He needs to trigger a rebuild and publish it
[10:55] <daniellimws> ok thanks!
[10:56] <popey> no problem
[10:57] <ogra_> i wonder if anything in the mail text isnt clear enough
[10:57] <ogra_> but re-reading the ones i got i personally find it pretty clear and understandable
[10:59] <ogra_> perhaps some hint that this can happen frequently and even frequently in succession might be helpful ?
[11:03] <zyga> popey: I don't know
[11:03] <zyga> popey: perhaps?
[11:03] <zyga> popey: but it was clearly the case that on reboot profiles were not loaded
[11:03] <popey> Strange.
[11:04] <zyga> and the command I gave above was fixing it
[11:08] <niemeyer> pedronis, pstolowski: #4767 reviewed
[11:08] <mup> PR #4767: interfaces: disconnect hooks <Complex> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
[11:09] <pstolowski> niemeyer: thank you
[11:09] <niemeyer> pedronis, pstolowski: If possible, please have a look soon over the comments so we can discuss further today
[11:17] <pedronis> I added some more thoughts on one of the main comments
[11:24] <zyga> niemeyer: I pushed to https://github.com/snapcore/snapd/pull/5410
[11:24] <zyga> running with --repeat 50 here
[11:24] <mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
[11:24] <zyga> so far so good
[11:26] <niemeyer> pedronis: +1 on the general idea there
[11:27] <zyga> Chipaca: hey, what's the back story for https://github.com/snapcore/snapd/pull/5494
[11:27] <mup> PR #5494: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs <Created by chipaca> <https://github.com/snapcore/snapd/pull/5494>
[11:27] <zyga> it looks ok but curious?
[11:31] <pedronis> zyga: ?
[11:31] <zyga> pedronis: ?
[11:31] <zyga> are you asking about 5494
[11:31] <pedronis> yes, John said the progress bar messes up the logs
[11:32] <pedronis> not sure what is curious about that
[11:33] <zyga> pedronis: well, that's what I was after
[11:34] <zyga> there was no commit message that would say as much
[11:36] <pedronis> he staid that at standup
[11:36] <pedronis> *said
[11:37] <zyga> must have slipped my mind, thank you
[11:38] <zyga> pedronis: can you have a 2nd look on https://github.com/snapcore/snapd/pull/5492
[11:38] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[11:38] <zyga> I dropped the functions that were problematic now; because of the re-factor in master they are no longer needed
[11:53] <Chipaca> zyga: what pedronis said
[11:53] <Chipaca> zyga: what's the commit message say?
[11:53]  * Chipaca looks
[11:53] <zyga> it says what's changed (-n) not why
[11:54] <Chipaca> zyga: oops. fixed.
[11:54] <zyga> thank you :)
[11:54] <Chipaca> np
[11:54] <zyga> I'll get some warm tea and be back shortly
[11:54] <Chipaca> lunch
[11:54] <zyga> it's so cold and humid today :/
[11:55] <zyga> is damp the best way to express that?
[11:55] <Chipaca> not sure,  i only begin to scratch the surface of the weather vocabulary
[11:59] <pedronis> pstolowski: hi, could you finish looking at #5473 ?
[11:59] <mup> PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord <Created by pedronis> <https://github.com/snapcore/snapd/pull/5473>
[12:04] <pstolowski> pedronis: will do
[12:24] <zyga> pstolowski: I think you would be a good person to co-review https://github.com/snapcore/snapd/pull/5492
[12:24] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[12:24] <zyga> https://github.com/snapcore/snapd/pull/5499 is trivial an green
[12:24] <mup> PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
[12:25] <zyga> https://github.com/snapcore/snapd/pull/5500 is very simple and green
[12:25] <mup> PR #5500: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
[12:40] <zyga> pedronis: I pushed a fix to one of the core18 PRs you reviewed https://github.com/snapcore/snapd/pull/5401
[12:40] <mup> PR #5401: [RFC] asserts: add (optional) kernel-track to model assertion <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5401>
[12:42] <pstolowski> zyga: sure
[12:43] <pedronis> zyga: ah, thanks also for checking for classic (it doesn't make sense there)
[13:23] <zyga> jdstrand: hey, can you please enqueue https://github.com/snapcore/snapd/pull/5469
[13:23] <mup> PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5469>
[13:30] <hunterk> does vulkan work with snap packages?
[13:56] <jdstrand> zyga: yes (it's on the list already). I looked at it but want to check out a few things
[14:00]  * zyga -> coffee
[14:01] <zyga> jdstrand: super, thank you
[14:01] <zyga> hunterk: hey, I believe it may but we don't have an end-to-end test for that
[14:01] <zyga> hunterk: if you plan to make a snap with vulkan support please stay in touch
[14:01] <zyga> hunterk: if you know of one please share it and try it out
[14:02] <hunterk> eyy, thanks for the response! I added the dependencies to the RetroArch snap and it fails to load. Self-compiled (i.e., non-snap) works
[14:02] <hunterk> but I figured it might need a plug or something, like the way there are Wayland and X11 plugs
[14:02] <hunterk> https://github.com/libretro/retroarch-snap
[14:03] <hunterk> btw, thanks popey for the recent PR!
[14:03] <popey> np :)
[14:05] <jdstrand> roadmr: hey, can you pull r1102? this has the epochs changes and two other bugs reported by the store team (and a fix for arm64)
[14:05] <jdstrand> s/bugs/bug fixes/
[14:05] <roadmr> hi jdstrand
[14:05] <roadmr> sure, I'll do that
[14:06] <jdstrand> roadmr: thanks! :)
[14:13] <jdstrand> sergiusens_: hey, can you remind me about something with the vm work? I have little armhf and arm64 boards with Ubuntu Core that I 'snap install classic' and then install the snapcraft deb in them, then run 'snapcraft'. this has been the recommended way to build snaps for architectures that don't match one's laptop/desktop
[14:13] <jdstrand> sergiusens_: while it is possible to use qemu to fully emulate armhf or arm64, that is painfully slow. will the new vm require a slow vm or can I still use the classic snap in this manner?
[14:14] <popey> jdstrand: surely launchpad is faster?
[14:15] <jdstrand> popey: no, it isn't. my builds won't start for an hour atm for both armhf and arm64
[14:15] <jdstrand> that is pretty common in my experiencce. plus, sometimes you don't want to push something to edge. you want to test before pushing to edge
[14:15] <popey> Sure.
[14:15] <popey> I tend to use a Pi running classic
[14:16] <popey> not core
[14:16] <jdstrand> that's the same question essentially
[14:17] <jdstrand> I don't have vms of armhf and arm64, so what will I have to do in the new world?
[14:20] <zyga> hunterk: do you get any apparmor denials? missing so files on startup?
[14:20] <jdstrand> s/will the new vm/will the new vm work/
[14:21]  * zyga finished some life interrupts and returns to coffee and another patch
[14:23] <mup> PR snapd#5501 closed: interfaces: allow invoking systemd-notify when daemon-notify is connected <Created by zyga> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5501>
[14:24] <sergiusens_> jdstrand: there is going to be a I know what I doing kind of toggle where you won't be forced into a VM
[14:25] <sergiusens_> jdstrand: the "I know what I am doing" and the implications of that (also related to buildd, docker and what not) has a session setup for the sprint next week; I suggest you attend :-)
[14:26] <sergiusens_> jdstrand: we have two follow up stories wrt cross compiling and native building which aren't ironed out completely; as a personal sidenote, building using qemu-system-aarch64 for me was faster tha building on a rpi with its really slow i/o.
[14:29] <hunterk> zyga: no, it just says it can't find the vulkan loader, though the vulkan loader lib (libvulkan1) is indeed in the snap's libs
[14:34] <mup> PR snapd#5502 opened: many: streamline the generic conflict check mechanisms <Created by pedronis> <https://github.com/snapcore/snapd/pull/5502>
[14:35] <pedronis> Chipaca: pstolowski:  ^
[14:36] <pstolowski> thanks
[14:36] <Chipaca> pedronis: ack
[14:37] <mup> PR snapd#5503 opened: tests: add missing slots in classic and core provider test snaps <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5503>
[14:41] <zyga> hunterk: hmm, can you wait till next week, we have one person on the team that worked on vulkan lately
[14:41] <zyga> hunterk: just show up on Monday and ask mborzecki here
[14:42] <hunterk> sure thing. I'll just idle in here and they can ping me or I'll ping them
[14:43] <zyga> hunterk: thank you, and welcome :)
[14:44] <zyga> hunterk: we cannot fix and find everything outselves so hands on experiments and feedback like yours is crucial
[14:44] <hunterk> my pleasure. I've been enjoying the snap format so far
[14:45] <popey> <3
[14:46] <zyga> I imagine it's quite like the 0.x days of dpkg :)
[14:46] <zyga> just with different set of issues
[14:51] <zyga> niemeyer: can you have a look at https://github.com/snapcore/snapd/pull/5410 please
[14:51] <mup> PR #5410: tests: update tests to work on core18 <Core18> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5410>
[14:56] <pedronis> zyga: is some kind of follow up using #5492 up for review?
[14:56] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[14:56] <zyga> pedronis: yes, there's a PR with everything remaining ...
[14:57] <pedronis> zyga: ?
[14:57] <zyga> pedronis: here
[14:57] <zyga> https://github.com/snapcore/snapd/pull/5491
[14:57] <mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
[14:58] <pedronis> zyga: why is it blocked and not marked core18 ?
[14:59] <zyga> because that is my integration PR and as I said in the description there the point is to review this patch by patch to avoid one big PR it was before
[14:59] <zyga> as for core18, yeah, it should be marked
[14:59] <zyga> if you prefer to review the whole lot we can do that too
[14:59] <zyga> it's the same code
[15:00] <pedronis> zyga: I don't prefer the whole lot, but I prefere something with a bit of usage
[15:00] <pedronis> before approving the other one
[15:00] <zyga> that's why I cross-linked them
[15:01] <zyga> so reviewers can see the code in context
[15:01] <pedronis> ?
[15:01] <pedronis> an integration branch might or might not be context
[15:01] <pedronis> it depends how close to final it is
[15:02] <pedronis> I'm just a bit confused atm
[15:02] <zyga> sorry about that, the cross linked branch is the complete use case
[15:02] <zyga> everything I intended this for
[15:02] <zyga> this is not the huge core18 integration branch that mvo opened, it's scoped and focused for interface remapping alone
[15:03] <pedronis> ok, then there is nothing to split out of it, no?
[15:03] <zyga> that's correct
[15:03] <pedronis> it needs to be marked core18 and reviewed?
[15:03] <zyga> it's just the first patch out of the set
[15:03] <pedronis> which one?
[15:03] <pedronis> are you talking 5491 or 5492 or both?
[15:04] <zyga> the small PR (5492) is just the first patch of the whole feature (5491)
[15:04] <zyga> in reality we could close 5492 and review 5491 but I thought this would be harder
[15:04] <pedronis> but you said there is nothing more to split out of 5491  ?
[15:04] <pedronis> I'm missing what "first" means here
[15:05] <zyga> nothing to split as in split one patch into two
[15:05] <zyga> it's just a way to review patch-by-patch on github
[15:05] <pedronis> you lost me
[15:05] <pedronis> what more patches are coming?
[15:05] <pedronis> things before 5491 or after?
[15:05] <zyga> there are two branches, one with 5 patches, one with 2 patches that are the 2 oldest of the 5
[15:05] <zyga> before nothing
[15:06] <zyga> after all of this lands we need to actually enable "snapd" to host implicit slots, this is not proposed yet as that was blocked by a number of other branches
[15:06] <pedronis> are you saying you will make a PR for each patch in 5491 ?
[15:06] <zyga> that was my plan, yes
[15:06] <pedronis> ????
[15:07] <pedronis> it doesn't seem that big
[15:07] <pedronis> but maybe I'm missing something
[15:07] <zyga> no, that's all really, if you think reviewing 5491 is okay we can just do that instead
[15:07] <pedronis> yes, might be simpler
[15:07] <zyga> I tend do to this because shorter reviews are easier to collect
[15:08] <zyga> pedronis: feel free to close 5492 and let's focus on 91 then :)
[15:08] <pedronis> to be clear  I like patches <300,  I can live with 500+, I find stuff over 600 large, but also dislike reviewing stuff without context
[15:08] <zyga> understood
[15:08] <zyga> I should have communicated that clearer in the PRs
[15:10] <pedronis> yes, the fact that they are obviously out of order and not all tagged confused things a bit more
[15:11] <pedronis> zyga: I'll try to go over 5492 in my morning tomorrow
[15:11] <zyga> pedronis: thank you
[15:12] <zyga> shall I close https://github.com/snapcore/snapd/pull/5492 ?
[15:12] <mup> PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5492>
[15:12] <mup> PR snapcraft#2179 opened: cli: SNAPCRAFT_BUILD_ENVIRONMENT isn't deprecated <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2179>
[15:12] <pedronis> zyga: yes
[15:12] <pedronis> sorry, I mean going over 5491
[15:13] <zyga> ah, yes
[15:13] <mup> PR snapd#5492 closed: overlord/ifacestate: add re-mapping function for plugs and slots <Core18> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5492>
[15:13] <zyga> since the history is the same you can look at how the usage is on either "end" of snapd by looking at
[15:13] <zyga> https://github.com/snapcore/snapd/pull/5491/commits/0a53fdc733ffe1d1ca0fc0bf0d619e333ac73e3b
[15:13] <mup> PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/5491>
[15:13] <zyga> https://github.com/snapcore/snapd/pull/5491/commits/24c2448b880321f6bf28da24b3cc7bedfef06ece
[15:14] <zyga> the API tests in the latter patch are interesting, I used a case-swapping mapper to show how things like "snap connect PLUG:SLOT" are handled
[15:15] <zyga> similar approach was used in the state tests
[15:15] <zyga> though there the change is smaller
[15:19] <zyga> thank you pedronis!
[15:19] <zyga> I need to break for a walk with Bit soon
[15:19] <zyga> but expect one more PR from me
[15:19] <zyga> pedronis: and if we can land a support branch for tests I will also have the patch that enables implicit slots on snapd snap
[15:41] <mup> PR snapd#5504 opened: interfaces/pulseaudio: be clear that the interface allows playback and record <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5504>
[16:17] <jdstrand> niemeyer: fyi, https://forum.snapcraft.io/t/pulseaudio-recording/6361. It would be good if someone (I've requested the desktop team) to drive this, but want you to be aware
[16:20] <Saviq> kyrofa: hey, is `snapcraftctl set-version` a thing yet?
[16:50] <niemeyer> jdstrand: Thanks, looking
[16:56] <niemeyer> jdstrand: Commented
[17:07] <jdstrand> niemeyer: thanks, I responded
[17:07] <kyrofa> Saviq, yessir, https://forum.snapcraft.io/t/extracting-information-from-sources-in-snapcraft-parts/4642
[17:10] <sergiusens_> Saviq: kyrofa for an easier to read version of that https://snapdocs.labix.org/extracting-information-from-sources-in-snapcraft-parts/4642
[17:11] <niemeyer> jdstrand: re-replied
[17:21] <Saviq> kyrofa, sergiusens_: thanks :)
[17:21] <Saviq> store folk, can you say what does this store upload fail mean: https://launchpad.net/~mir-team/+snap/mir-kiosk-edge/+build/276950 ?
[17:57] <jdstrand> niemeyer: and so did I, twice. and will replied
[18:20]  * zyga returned from a 10km walk :)
[19:19] <zyga> jdstrand: https://lwn.net/Articles/759499/ (!!!)
[19:20] <jdstrand> apparently my subscription has expired
[19:33] <zyga> feels like I could write snap-confine again with those new syscalls
[19:53] <zyga> jdstrand: can you ack trivial https://github.com/snapcore/snapd/pull/5500 and even more so https://github.com/snapcore/snapd/pull/5499
[19:53] <mup> PR #5500: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5500>
[19:53] <mup> PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5499>
[20:14] <jdstrand> zyga: done
[20:22] <zyga> thank you
[20:23] <mup> PR snapd#5500 closed: interfaces: tweak tests of daemon-notify, use common naming <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5500>
[20:24] <mup> PR snapd#5499 closed: interfaces: fix typo "daemonNotify" (add missing "n") <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5499>