[05:06] morning [06:05] Good morning [06:05] I will have to swap today [06:06] hi zyga. How was Montreal? [06:06] Too many things overlap (passport, doctor, another doctor) [06:06] jamesh: hello! [06:06] Very successful [06:06] Unbelievably so I would say [06:07] zyga: jamesh: hi [06:07] that's good to hear [06:08] zyga: you're swapping today? [06:08] Yes [06:08] I have to [06:09] zyga: ack [06:09] jamesh: there are details on the forum [06:09] Mborzec mborzecki during last week we noticed that bash completion is broken on centos [06:10] No bug report yet because the principal centos user is from Australia and I believe has even more jet lag [06:11] zyga: hah ok, i can look into this [06:12] zyga: could have gone unnoticed, i'm using zsh usually and the cloud images don't come with bash completion installed [06:12] hmm but we have sprewa tests for this [06:13] Maybe is is not broken per se [06:13] Just not working something [06:13] Somehow [06:13] Worth just trying it out interactively [06:14] zyga: yeah, will do [06:15] I have some thoughts to share about other topics but I am too jet lagged now I [06:17] zyga: bash completion for snap command or snaps? [06:22] mvo: morning [06:22] btw. does completion ignore hidden flag of commands? [06:23] hey mborzecki ! [06:23] mborzecki: idk, john probably does [06:23] mvo: try snap remo [06:23] mborzecki: I just did a quick test - it does not afaict [06:24] mvo: mhm, remodel pops up :/ [06:26] mborzecki: yeah, annoying [06:26] mborzecki: we could could into an upstream fix for this one [06:27] mborzecki: I think for the snap command [06:27] Hey mvo [06:28] hey zyga ! how are you? [06:28] mvo: I am sorry but I need to swap today out, two doctor visits and passport (in person) pick ups [06:28] mvo: apart from jet lag [06:29] zyga: sure, thats fine, good luck [06:29] And +15C [06:29] Okay :-) [06:29] zyga: woah, yeah [06:29] I have some things to share from last week [06:29] (As in *additional* +15C) [06:32] zyga: looking forward to hear what you have to share [06:32] zyga: good luck adjusting to the new climate :) [06:39] mvo: looks better now https://paste.ubuntu.com/p/DGT6k9DhhW/ [06:41] mborzecki: oh, what did you do? [06:43] mvo: https://paste.ubuntu.com/p/vXZYYy7C9m/ [06:44] mvo: hoped we could do it in custom CompletionHandler but there does not seem to be a way to tell what is the kind the completion (commmand, argument etc.) [06:49] mborzecki: aha, I see! thanks. will you submit upstream? [06:49] mvo: yes [06:49] ta [06:49] mvo: fwiw they fixed it for options back in 2016: https://github.com/jessevdk/go-flags/commit/32811b87051d3e1dc77d2c9925473f2a4a07abdf [07:04] mvo: https://github.com/jessevdk/go-flags/pull/312 [07:06] mborzecki: cool, thanks! [07:06] mborzecki: funny how sort the test is :) === pstolowski|afk is now known as pstolowski [07:08] mornings [07:09] pstolowski: hey [07:09] hey pstolowski ! good morning [07:11] zyga: hm completion seems to work on centos just fine [07:41] mvo: hi, I proposed the re-registration PRs [07:53] pedronis: nice! [08:15] 👋 [08:20] pedronis: you around? [08:21] Chipaca: yes [08:21] pedronis: can we talk about the direction for health? [08:22] pedronis: (or schedule it) [08:22] Chipaca: we can do a quick chat yes [08:23] pedronis: ok. AIUI what we want is to be able to call set-health in an arbitrary hook, and when not in a hook [08:23] pedronis: anything else? [08:24] ha, 'Invalid PR title: "state-inspect debug utility"'. it works :) [08:24] Chipaca: not particularly [08:27] Chipaca: about the other point, I see two options always writing to state directly, or set an OnDone if the context doesn't have a "health" entry yet [08:27] the first approach means the systema always sees health immediately [08:27] the 2nd means for hooks is set only once at the end [08:28] *two options: [08:30] pedronis: hmm [08:37] Chipaca: I think I prefer the 2nd option [08:38] pedronis: i'll dig into what it entails [08:38] pedronis: should be simple enough (famous last words) [08:39] Chipaca: yes, it should be simple, for why I prefer it, a bit more consistent with how snapctl set works [08:39] also not sure we want people to rely on set-health being immediate [08:40] yeah, we're not a cheap message passing thing :) [08:44] opensuse repos broken again? [08:46] Chipaca: you'll need to see how interacts with setting of the check-health hook also based on weather it was set at all or the hook failed [08:46] but should be workable [08:46] * Chipaca adds a note to have check-health look at the weather [08:47] pedronis: :) no worries, i think i got what you mean [08:47] *wether [08:48] :) [08:48] pedronis: *whether [08:49] pedronis: a wether is a castrated ram [08:49] pedronis: probably not what you meant [08:50] cf widder vs weder [08:51] * Chipaca shuts up and goes to work hacking health into submission [08:52] mvo: btw I re-opened #6582 and tagged it for 2.40, robert_ancell confirmed (as you can read in the pr) that things are ready for this [08:54] pedronis: any opinion on snapd-hook-no-health-set vs snapd-no-health-set-in-hook? [08:55] mborzecki: https://bugs.launchpad.net/bugs/1833043 from cmake developer on centos [08:56] Completion inside sandbox, not for snap itself [08:56] zyga: ah, so it's completion for snap apps [08:57] looks like a tweak's needed in complete.sh [08:58] although it already tries to grab it from core [08:58] … with the wrong path for it there [08:58] sigh [08:58] so it's a bug :) [09:01] no, sorry, misread, it's something else [09:05] gah, CoreLibExecDir [09:05] … but that's ok, right? it should be 'inside'? [09:06] Chipaca: CoreLibexecDir should be fine [09:07] mborzecki: should it still be fine in a classic snap? [09:10] Chipaca: [pid 11525] execve("/bin/bash", ["/bin/bash", "/usr/lib/snapd/etelpmoc.sh", "/var/lib/snapd/snap/cmake/12/sha"..., "9", "9", "11", "2", " ", "cmake -G Ni", "cmake", "-G", "Ni [09:11] "], 0xc00006b080 /* 45 vars */ [09:11] Chipaca: hm that should prepend snap mount path for classic, shouldn't it? [09:12] * Chipaca has 0.0…0 idea [09:16] Chipaca: hm so snap run will run snap-confine --classic --base .. snap.cmake.cmake /usr/libexec/snapd/snap-exec .. , but then snap-exec calls etelpmoc.sh as if it is inside the mount ns, which it isn't [09:18] Chipaca: we should probably have CompletionHelperInCore and CompletionHelper, then looking at NeedsClassic() pick the right one [09:20] Chipaca: i can look into the fix [09:20] shoudl be quite simple [09:20] mborzecki: thanks [09:39] Chipaca: yay, seems to work now [09:39] * Chipaca hugs mborzecki [10:16] Chipaca: https://github.com/snapcore/snapd/pull/7008 [10:17] mborzecki: thank you [10:18] Chipaca: wondering whether we should assume core/current, what if snap has a different base? [10:19] mborzecki: magic pixies fly in the window and fix it? [10:19] xD [10:49] * pstolowski lunch === ricab is now known as ricab|lunch [12:12] pedronis: thanks for the 2nd pass over base validation PR [12:12] np, thank you [12:14] off to pick up the kids [12:17] Chipaca: I reviewed #7001, thank you [12:35] Chipaca: I asked you for another pass in #6680 === ricab|lunch is now known as ricab [14:06] kenvandine: or willcooke: with the snapd support for fontconfig caches being build up-front, do we need to change the desktop-helpers and the gnome extension PR to match? [14:06] diddledan: i don't think so [14:06] ok, cool === apw_ is now known as apw [14:59] pedronis: thanks for the review, will fix that messaging [15:56] jdstrand_: gimp requires gvfs access (over dbus) to org.gtk.vfs.Daemon which I think is on the session bus in order to open it's internal help documents. I don't see from a quick glance any interfaces covering this [15:59] diddledan: there is some stuff for gvfs in desktop-legacy, but not org.gtk.vfs.Daemon. why is it talking to the daemon? what is it trying to access? [16:00] I'm not sure [16:02] this is the message I get in a dialog when I try to open the internal help: [16:02] Could not open 'https://docs.gimp.org/2.10/en/gimp-help.xml' for reading: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.448" (uid=1000 pid=13202 comm="/usr/lib/gimp/2.0/plug-ins/help/help -gimp 14 13 -" label="snap.gimp.gimp (enforce)") interface="org.gtk.vfs.Daemon" member="GetConnection" error name="(unset)" requested_reply="0" destination=":1.95" [16:02] (uid=1000 pid=8614 comm="/usr/lib/gvfs/gvfsd-http --spawner :1.22 /org/gtk/" label="unconfined") [16:03] it looks like it's using gvfs to download the help document [16:04] diddledan: ok, right, it is using gvfs for http access. that is indeed not currently supported. the Daemon apis give a sandbox escape since you can specify a (file) url on the command line and gvfsd, which is unconfined, will give the snap the file === jdstrand_ is now known as jdstrand [16:05] diddledan: gimp should be adjusted to use xdg-open === pstolowski is now known as pstolowski|afk [17:02] opensuse repos still flaky [17:32] mborzecki: [17:32] Chipaca: sounds like you caught a pikachu :) [17:33] mborzecki: more like a dedenne [17:34] hahaha [17:34] * this conversation is being supervised by 14-year-olds [17:45] mborzecki: openSUSE's mirrorbrain crashed and burned this morning [17:46] Pharaoh_Atem: as in literally or just some random outage? [17:46] random outage [17:47] hah, there it is: https://status.opensuse.org/ [17:52] Pharaoh_Atem: if it's any consolation, so did all of Uruguay, most of Argentina, and a good chunk of Brazil [18:19] Chipaca: still around? can you take another look at https://github.com/snapcore/snapd/pull/6680 ? [19:13] jdstrand: sorry to bother you, are we supposed to do anything else for the alias request? [20:04] albertosottile: no. there is a 7 day voting period. people were travelling thu/fri so just haven't gotten the votes yet is all [20:32] jdstrand: thanks :)