[00:02] That type of thing has been pretty handy for me in the past, I'd rather not lose it [00:05] 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] (from the point of view of a user of the snapcraft CLI) [00:12] kyrofa: Historically that was actually the case in the design we discussed at least [00:12] kyrofa: It's trivial to have any content inside a script [00:13] kyrofa: And the path of the command being relative to the snap just means you know what you are calling [00:14] kyrofa: Instead of trusting on the environment of the snap to define what a command even means [00:14] kyrofa: The application stanza was supposed to be a way to hook up a script, not be the script [00:15] 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] 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] hey guys, does vulkan work with snap packages? [01:27] 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] I figured I'd check here before continuing to bang my head against it [01:29] it looks like libvulkan1 is getting included properly... === epod is now known as luk3yx === pstolowski|afk is now known as pstolowski [07:02] morning [07:31] hey hey [07:31] boy, what a damp morning it is [08:03] moin moin [08:04] have you seen https://launchpadlibrarian.net/378130619/journalctl_-u_snapd.txt ? [08:04] not sure what to make of it [08:05] good morning Chipaca [08:05] * zyga looks [08:06] Chipaca: hmm, we are type: notify [08:07] and it seems we didn't respond in time [08:07] zyga: yeah, this is attached to the #1779948 so maybe it's just that [08:07] Bug #1779948: Snapd gets stuck when starting Ubuntu.

[08:07] zyga: the dns thing threw is what puzzles me though [08:08] that dns thing looks like resolved [08:08] zyga: did they call it that just to make conversation about its bugs harder [08:08] Chipaca: could it be first boot and seeding and what not on an offline system with super laggy dns [08:08] like I have a dns at home that doesn't work over tcp [08:09] and doesn't work over udp with packet fragmentation [08:09] so stuff keeps falling back to older/crappier version [08:09] but it takes time each time [08:09] actually [08:09] about that: [08:09] zyga: it's not first boot (earlier in the log output you see things being fine) [08:09] Chipaca: I read that you can tell systemd that you are alive and still starting [08:09] but not ready yet [08:09] zyga: yes [08:09] and then systemd extends the startup timeout [08:09] anyway reaching notify shouldn't involve seeding or any task really [08:09] maybe we should? [08:10] zyga: problem is that the random drain was done from an init() i think, so too early for us [08:10] early and in arbitrary order i think (but i'm not sure) [08:10] pedronis: mo'in! how're you doing today? [08:10] could be better, could be worse [08:11] Chipaca: could you look at #5473 when you have a bit of time [08:11] PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord [08:12] pedronis: yep [08:12] Chipaca: I suppose, I should look at the warnings PR when I have a bit of time [08:13] pedronis: no rush [08:32] afk, bbiab (need to go to the boys' school) [09:07] need to take my daughter to the doctor, bbiab [09:15] PR snapd#5499 opened: interfaces: fix typo "daemonNotify" (add missing "n") [09:17] PR snapd#5500 opened: interfaces: tweak tests of daemon-notify, use common naming [09:23] PR snapd#5501 opened: interfaces: allow invoking systemd-notify when daemon-notify is connected [09:34] * Chipaca returns [09:35] zyga: did you see what i said yesterday about not trying to start an app with an unconnected daemon-notify? [09:37] mmmj [09:37] maybe/ [09:37] I thought that was Samuele [09:37] can you repeat please? [09:40] 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] that last 'it' is the daemon-notify interface [09:42] mmm [09:42] I didn't see that [09:42] not sure if I agree, we should generalize that to be able to say [09:42] this snap cannot be installed (or perhaps activated) when {set of interfaces} are not connected [09:48] Chipaca: something like: plugs: daemon-notify: required: true [09:51] zyga: the problem with generalising it is that then you need to make it general [09:52] well, the problem of specializing it is that then you need to make it general too ;) [09:52] zyga: first of all, required:true sounds wrong, like the snap won't install [09:52] zyga: but that's just a name [09:52] zyga: what happens if you put required:true on an app? [09:52] on a plug on an app i mean [09:52] Chipaca: one of the questions is if we want to have partially enabled snaps [09:52] like you have app1 and app2 but not app3 [09:53] zyga: and it starts to seem more masturbatory than practical [09:53] 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] zyga: I didn't follow that last bit [09:54] defining a plug or slot on an app does two things: [09:54] defines the plug or slot [09:54] indicates association with an app [09:54] my point was that the attribute ought to be associated with the interface, not with the association [09:54] my gut feeling is this: [09:54] let's sleep over it, think and come up with brainstorm material [09:55] we can implement the subset for daemon-notify once we know where we want to go to [09:55] so that we can implement a slice of the bigger cake [10:00] zyga: where is this cake, and does it go well with coffee [10:00] Chipaca: you are tempting me sir ;) [10:00] zyga: cakes that don't go well with coffee: https://en.wikipedia.org/wiki/Yellowcake [10:00] there is raspberry cake indoors [10:01] it's raining all night and all morning here [10:01] so mood is perfect for cake [10:03] zyga: nice gentle rain in the middle of a forest? heck yea [10:03] Chipaca: heck ...bzzzz (mosquito) yeah :( [10:03] cake and spiced tea, or spiced cake and tea [10:03] it's okay but at most 2/3 days a week [10:04] I recall summer holidays when there was really no day without this never-ending rain [10:04] zyga: ah, yes, after the second night it suddenly becomes a dystopia [10:04] it's supposed to rain for the next 10 days [10:04] "la ciénaga" but with rain [10:05] zyga: "oops they moved my flight i need to leave right now to make it byeeeee" [10:05] hahah [10:05] montreal feels like going to the other hemisphere now [10:06] zyga: almost but not quite [10:06] vancouver would be [10:07] zyga: bah, even montreal gets you from positive to negative longitudes [10:07] so technically yes :-) [10:12] Mornings [10:14] [citation needed] [10:19] my LTE link is down [10:19] not sure if I can do standup video today [10:19] if the weather continues like that [10:20] It surprises me that there are no separate ways to flag an issue with the developer with snap - except github or launchpad. [10:23] AuroraAvenue: do you have a specific issue to report? [10:31] popey, well I am tired, very tired, but if its an issue ya want then its an issue I'll grant you. [10:31] Xonotic doesn't open on Solus Os. [10:31] is there any kind of error message? [10:32] (if launched from the command line) [10:32] erm, hangon #fatfingers (me). [10:33] https://paste.ubuntu.com/p/Vhs5CgqK2J/ [10:34] interesting. what's the output of `snap version` please? [10:35] I type > snap xonotic , right ? [10:35] `snap version` [10:35] oh sorry [10:36] I just installed it on Solus here and it works. [10:37] https://paste.ubuntu.com/p/PdDgrwtjCd/ [10:37] must be my crud laptop, then. [10:38] popey, this isnot a pressing issue by the way. [10:38] it is more likely a kernel issue [10:38] popey, AuroraAvenue: That looks like a confinement issue.. from the error message, looks like it cannot change to another apparmor profile [10:38] zyga ^ [10:38] zyga: Any ideas? [10:38] looking [10:38] right - originally install from solus 3.999 - its updated to past v.4 now - all upto date though. [10:39] AuroraAvenue: hey [10:39] I reported this issue to ikey a few weeks ago [10:39] hello [10:39] AuroraAvenue: please run: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/* [10:39] right-oh [10:39] and see if this fixes the issue [10:39] 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] AuroraAvenue: More recent versions (as of several months now) can tell that, and will recompile things automatically when necessary [10:40] it seems that apparmor in solus stopped loading profiles generated by snapd on boot [10:40] AuroraAvenue: But it may always be an unrelated bug, obviously [10:40] popey: what was the name of that better zenity you were using for i-don't-remember-which-snap? [10:40] yad [10:40] (used in tmnationsforever) [10:40] popey: care to comment on https://forum.snapcraft.io/t/zenity-dialogs-in-a-snap/6359 about the why? [10:41] popey: otherwise I will, and steal your karma [10:41] Okay - were rockin' xonotic now :D [10:41] woohoo [10:41] AuroraAvenue: now put down the fps and get some sleep [10:41] yeah - must go to bed, your very true. [10:41] okay bye then. [10:41] :) [10:41] & thank-you [10:42] thanks for the report [10:46] I'll ask ikey again [10:50] zyga: does this only affect new installs? [10:50] my vm works fine, and it's up to date [10:53] 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] may I know if there's anything he missed? [10:54] https://github.com/dj3500/hightail/pull/105#issuecomment-349701547 [10:54] PR dj3500/hightail#105: Add snapcraft [10:54] daniellimws: he probably got multiple emails over a few days [10:54] one for libjpeg and another for libcups2 and libpng12 [10:55] oh, so he does not need to do anything right? it will stop soon? [10:55] No, it will not stop. [10:55] He only gets one mail per security update. [10:55] but there were likely two security mails for different libraries. [10:55] He needs to trigger a rebuild and publish it [10:55] ok thanks! [10:56] no problem [10:57] i wonder if anything in the mail text isnt clear enough [10:57] but re-reading the ones i got i personally find it pretty clear and understandable [10:59] perhaps some hint that this can happen frequently and even frequently in succession might be helpful ? [11:03] popey: I don't know [11:03] popey: perhaps? [11:03] popey: but it was clearly the case that on reboot profiles were not loaded [11:03] Strange. [11:04] and the command I gave above was fixing it [11:08] pedronis, pstolowski: #4767 reviewed [11:08] PR #4767: interfaces: disconnect hooks

[11:09] niemeyer: thank you [11:09] pedronis, pstolowski: If possible, please have a look soon over the comments so we can discuss further today [11:17] I added some more thoughts on one of the main comments [11:24] niemeyer: I pushed to https://github.com/snapcore/snapd/pull/5410 [11:24] running with --repeat 50 here [11:24] PR #5410: tests: update tests to work on core18 [11:24] so far so good [11:26] pedronis: +1 on the general idea there [11:27] Chipaca: hey, what's the back story for https://github.com/snapcore/snapd/pull/5494 [11:27] PR #5494: snap/squashfs, tests: pass -n[o-progress] to {mk,un}squashfs [11:27] it looks ok but curious? [11:31] zyga: ? [11:31] pedronis: ? [11:31] are you asking about 5494 [11:31] yes, John said the progress bar messes up the logs [11:32] not sure what is curious about that [11:33] pedronis: well, that's what I was after [11:34] there was no commit message that would say as much [11:36] he staid that at standup [11:36] *said [11:37] must have slipped my mind, thank you [11:38] pedronis: can you have a 2nd look on https://github.com/snapcore/snapd/pull/5492 [11:38] PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots [11:38] I dropped the functions that were problematic now; because of the re-factor in master they are no longer needed [11:53] zyga: what pedronis said [11:53] zyga: what's the commit message say? [11:53] * Chipaca looks [11:53] it says what's changed (-n) not why [11:54] zyga: oops. fixed. [11:54] thank you :) [11:54] np [11:54] I'll get some warm tea and be back shortly [11:54] lunch [11:54] it's so cold and humid today :/ [11:55] is damp the best way to express that? [11:55] not sure, i only begin to scratch the surface of the weather vocabulary [11:59] pstolowski: hi, could you finish looking at #5473 ? [11:59] PR #5473: overlord: have SnapManager use a passed in TaskRunner created by Overlord [12:04] pedronis: will do [12:24] pstolowski: I think you would be a good person to co-review https://github.com/snapcore/snapd/pull/5492 [12:24] PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots [12:24] https://github.com/snapcore/snapd/pull/5499 is trivial an green [12:24] PR #5499: interfaces: fix typo "daemonNotify" (add missing "n") [12:25] https://github.com/snapcore/snapd/pull/5500 is very simple and green [12:25] PR #5500: interfaces: tweak tests of daemon-notify, use common naming [12:40] pedronis: I pushed a fix to one of the core18 PRs you reviewed https://github.com/snapcore/snapd/pull/5401 [12:40] PR #5401: [RFC] asserts: add (optional) kernel-track to model assertion [12:42] zyga: sure [12:43] zyga: ah, thanks also for checking for classic (it doesn't make sense there) [13:23] jdstrand: hey, can you please enqueue https://github.com/snapcore/snapd/pull/5469 [13:23] PR #5469: interfaces/apparmor: (un)load profiles in one apparmor_parser call [13:30] does vulkan work with snap packages? [13:56] 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] jdstrand: super, thank you [14:01] hunterk: hey, I believe it may but we don't have an end-to-end test for that [14:01] hunterk: if you plan to make a snap with vulkan support please stay in touch [14:01] hunterk: if you know of one please share it and try it out [14:02] 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] but I figured it might need a plug or something, like the way there are Wayland and X11 plugs [14:02] https://github.com/libretro/retroarch-snap [14:03] btw, thanks popey for the recent PR! [14:03] np :) [14:05] 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] s/bugs/bug fixes/ [14:05] hi jdstrand [14:05] sure, I'll do that [14:06] roadmr: thanks! :) [14:13] 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] 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] jdstrand: surely launchpad is faster? [14:15] popey: no, it isn't. my builds won't start for an hour atm for both armhf and arm64 [14:15] 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] Sure. [14:15] I tend to use a Pi running classic [14:16] not core [14:16] that's the same question essentially [14:17] I don't have vms of armhf and arm64, so what will I have to do in the new world? [14:20] hunterk: do you get any apparmor denials? missing so files on startup? [14:20] 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] PR snapd#5501 closed: interfaces: allow invoking systemd-notify when daemon-notify is connected [14:24] 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] 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] 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] 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] PR snapd#5502 opened: many: streamline the generic conflict check mechanisms [14:35] Chipaca: pstolowski: ^ [14:36] thanks [14:36] pedronis: ack [14:37] PR snapd#5503 opened: tests: add missing slots in classic and core provider test snaps [14:41] hunterk: hmm, can you wait till next week, we have one person on the team that worked on vulkan lately [14:41] hunterk: just show up on Monday and ask mborzecki here [14:42] sure thing. I'll just idle in here and they can ping me or I'll ping them [14:43] hunterk: thank you, and welcome :) [14:44] hunterk: we cannot fix and find everything outselves so hands on experiments and feedback like yours is crucial [14:44] my pleasure. I've been enjoying the snap format so far [14:45] <3 [14:46] I imagine it's quite like the 0.x days of dpkg :) [14:46] just with different set of issues [14:51] niemeyer: can you have a look at https://github.com/snapcore/snapd/pull/5410 please [14:51] PR #5410: tests: update tests to work on core18 [14:56] zyga: is some kind of follow up using #5492 up for review? [14:56] PR #5492: overlord/ifacestate: add re-mapping function for plugs and slots [14:56] pedronis: yes, there's a PR with everything remaining ... [14:57] zyga: ? [14:57] pedronis: here [14:57] https://github.com/snapcore/snapd/pull/5491 [14:57] PR #5491: overlord,daemon: re-map interface plugs and slots around the edges of snapd [14:58] zyga: why is it blocked and not marked core18 ? [14:59] 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] as for core18, yeah, it should be marked [14:59] if you prefer to review the whole lot we can do that too [14:59] it's the same code [15:00] zyga: I don't prefer the whole lot, but I prefere something with a bit of usage [15:00] before approving the other one [15:00] that's why I cross-linked them [15:01] so reviewers can see the code in context [15:01] ? [15:01] an integration branch might or might not be context [15:01] it depends how close to final it is [15:02] I'm just a bit confused atm [15:02] sorry about that, the cross linked branch is the complete use case [15:02] everything I intended this for [15:02] this is not the huge core18 integration branch that mvo opened, it's scoped and focused for interface remapping alone [15:03] ok, then there is nothing to split out of it, no? [15:03] that's correct [15:03] it needs to be marked core18 and reviewed? [15:03] it's just the first patch out of the set [15:03] which one? [15:03] are you talking 5491 or 5492 or both? [15:04] the small PR (5492) is just the first patch of the whole feature (5491) [15:04] in reality we could close 5492 and review 5491 but I thought this would be harder [15:04] but you said there is nothing more to split out of 5491 ? [15:04] I'm missing what "first" means here [15:05] nothing to split as in split one patch into two [15:05] it's just a way to review patch-by-patch on github [15:05] you lost me [15:05] what more patches are coming? [15:05] things before 5491 or after? [15:05] there are two branches, one with 5 patches, one with 2 patches that are the 2 oldest of the 5 [15:05] before nothing [15:06] 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] are you saying you will make a PR for each patch in 5491 ? [15:06] that was my plan, yes [15:06] ???? [15:07] it doesn't seem that big [15:07] but maybe I'm missing something [15:07] no, that's all really, if you think reviewing 5491 is okay we can just do that instead [15:07] yes, might be simpler [15:07] I tend do to this because shorter reviews are easier to collect [15:08] pedronis: feel free to close 5492 and let's focus on 91 then :) [15:08] 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] understood [15:08] I should have communicated that clearer in the PRs [15:10] yes, the fact that they are obviously out of order and not all tagged confused things a bit more [15:11] zyga: I'll try to go over 5492 in my morning tomorrow [15:11]