[05:06] <mborzecki> morning
[06:05] <zyga> Good morning
[06:05] <zyga> I will have to swap today
[06:06] <jamesh> hi zyga.  How was Montreal?
[06:06] <zyga> Too many things overlap (passport, doctor, another doctor)
[06:06] <zyga> jamesh: hello!
[06:06] <zyga> Very successful
[06:06] <zyga> Unbelievably so I would say
[06:07] <mborzecki> zyga: jamesh: hi
[06:07] <jamesh> that's good to hear
[06:08] <mborzecki> zyga: you're swapping today?
[06:08] <zyga> Yes
[06:08] <zyga> I have to
[06:09] <mborzecki> zyga: ack
[06:09] <zyga> jamesh: there are details on the forum
[06:09] <zyga> Mborzec mborzecki during last week we noticed that bash completion is broken on centos
[06:10] <zyga> No bug report yet because the principal centos user is from Australia and I believe has even more jet lag
[06:11] <mborzecki> zyga: hah ok, i can look into this
[06:12] <mborzecki> zyga: could have gone unnoticed, i'm using zsh usually and the cloud images don't come with bash completion installed
[06:12] <mborzecki> hmm but we have sprewa tests for this
[06:13] <zyga> Maybe is is not broken per se
[06:13] <zyga> Just not working something
[06:13] <zyga> Somehow
[06:13] <zyga> Worth just trying it out interactively
[06:14] <mborzecki> zyga: yeah, will do
[06:15] <zyga> I have some thoughts to share about other topics but I am too jet lagged now I
[06:17] <mborzecki> zyga: bash completion for snap command or snaps?
[06:22] <mborzecki> mvo: morning
[06:22] <mborzecki> btw. does completion ignore hidden flag of commands?
[06:23] <mvo> hey mborzecki !
[06:23] <mvo> mborzecki: idk, john probably does
[06:23] <mborzecki> mvo: try snap remo<tab><tab>
[06:23] <mvo> mborzecki: I just did a quick test - it does not afaict
[06:24] <mborzecki> mvo: mhm, remodel pops up :/
[06:26] <mvo> mborzecki: yeah, annoying
[06:26] <mvo> mborzecki: we could could into an upstream fix for this one
[06:27] <zyga> mborzecki: I think for the snap command
[06:27] <zyga> Hey mvo
[06:28] <mvo> hey zyga ! how are you?
[06:28] <zyga> mvo: I am sorry but I need to swap today out, two doctor visits and passport (in person) pick ups
[06:28] <zyga> mvo: apart from jet lag
[06:29] <mvo> zyga: sure, thats fine, good luck
[06:29] <zyga> And +15C
[06:29] <zyga> Okay :-)
[06:29] <mvo> zyga: woah, yeah
[06:29] <zyga> I have some things to share from last week
[06:29] <zyga> (As in *additional* +15C)
[06:32] <mvo> zyga: looking forward to hear what you have to share
[06:32] <mvo> zyga: good luck adjusting to the new climate :)
[06:39] <mborzecki> mvo: looks better now https://paste.ubuntu.com/p/DGT6k9DhhW/
[06:41] <mvo> mborzecki: oh, what did you do?
[06:43] <mborzecki> mvo: https://paste.ubuntu.com/p/vXZYYy7C9m/
[06:44] <mborzecki> 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] <mvo> mborzecki: aha, I see! thanks. will you submit upstream?
[06:49] <mborzecki> mvo: yes
[06:49] <mvo> ta
[06:49] <mborzecki> mvo: fwiw they fixed it for options back in 2016: https://github.com/jessevdk/go-flags/commit/32811b87051d3e1dc77d2c9925473f2a4a07abdf
[07:04] <mborzecki> mvo: https://github.com/jessevdk/go-flags/pull/312
[07:06] <mvo> mborzecki: cool, thanks!
[07:06] <mvo> mborzecki: funny how sort the test is :)
[07:08] <pstolowski> mornings
[07:09] <mborzecki> pstolowski: hey
[07:09] <mvo> hey pstolowski ! good morning
[07:11] <mborzecki> zyga: hm completion seems to work on centos just fine
[07:41] <pedronis> mvo: hi, I proposed the re-registration PRs
[07:53] <mvo> pedronis: nice!
[08:15] <Chipaca> 👋
[08:20] <Chipaca> pedronis: you around?
[08:21] <pedronis> Chipaca: yes
[08:21] <Chipaca> pedronis: can we talk about the direction for health?
[08:22] <Chipaca> pedronis: (or schedule it)
[08:22] <pedronis> Chipaca: we can do a quick chat yes
[08:23] <Chipaca> 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] <Chipaca> pedronis: anything else?
[08:24] <pstolowski> ha, 'Invalid PR title: "state-inspect debug utility"'. it works :)
[08:24] <pedronis> Chipaca: not particularly
[08:27] <pedronis> 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] <pedronis> the first approach means the systema always sees health immediately
[08:27] <pedronis> the 2nd means for hooks is set only once at the end
[08:28] <pedronis> *two options:
[08:30] <Chipaca> pedronis: hmm
[08:37] <pedronis> Chipaca: I think I prefer the 2nd option
[08:38] <Chipaca> pedronis: i'll dig into what it entails
[08:38] <Chipaca> pedronis: should be simple enough (famous last words)
[08:39] <pedronis> Chipaca: yes, it should be simple,  for why I prefer it, a bit more consistent with how snapctl set works
[08:39] <pedronis> also not sure we want people to rely on set-health being immediate
[08:40] <Chipaca> yeah, we're not a cheap message passing thing :)
[08:44] <mborzecki> opensuse repos broken again?
[08:46] <pedronis> 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] <pedronis> but should be workable
[08:46]  * Chipaca adds a note to have check-health look at the weather
[08:47] <Chipaca> pedronis: :) no worries, i think i got what you mean
[08:47] <pedronis> *wether
[08:48] <Chipaca> :)
[08:48] <Chipaca> pedronis: *whether
[08:49] <Chipaca> pedronis: a wether is a castrated ram
[08:49] <Chipaca> pedronis: probably not what you meant
[08:50] <Chipaca> cf widder vs weder
[08:51]  * Chipaca shuts up and goes to work hacking health into submission
[08:52] <Chipaca> 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] <Chipaca> pedronis: any opinion on snapd-hook-no-health-set vs snapd-no-health-set-in-hook?
[08:55] <zyga> mborzecki: https://bugs.launchpad.net/bugs/1833043 from cmake developer on centos
[08:56] <zyga> Completion inside sandbox, not for snap itself
[08:56] <mborzecki> zyga: ah, so it's completion for snap apps
[08:57] <Chipaca> looks like a tweak's needed in complete.sh
[08:58] <Chipaca> although it already tries to grab it from core
[08:58] <Chipaca> … with the wrong path for it there
[08:58] <Chipaca> sigh
[08:58] <Chipaca> so it's a bug :)
[09:01] <Chipaca> no, sorry, misread, it's something else
[09:05] <Chipaca> gah, CoreLibExecDir
[09:05] <Chipaca> … but that's ok, right? it should be 'inside'?
[09:06] <mborzecki> Chipaca: CoreLibexecDir should be fine
[09:07] <Chipaca> mborzecki: should it still be fine in a classic snap?
[09:10] <mborzecki> 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] <mborzecki> "], 0xc00006b080 /* 45 vars */ <unfinished ...>
[09:11] <mborzecki> Chipaca: hm that should prepend snap mount path for classic, shouldn't it?
[09:12]  * Chipaca has 0.0…0 idea
[09:16] <mborzecki> 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] <mborzecki> Chipaca: we should probably have CompletionHelperInCore and CompletionHelper, then looking at NeedsClassic() pick the right one
[09:20] <mborzecki> Chipaca: i can look into the fix
[09:20] <mborzecki> shoudl be quite simple
[09:20] <Chipaca> mborzecki: thanks
[09:39] <mborzecki> Chipaca: yay, seems to work now
[09:39]  * Chipaca hugs mborzecki 
[10:16] <mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7008
[10:17] <Chipaca> mborzecki: thank you
[10:18] <mborzecki> Chipaca: wondering whether we should assume core/current, what if snap has a different base?
[10:19] <Chipaca> mborzecki: magic pixies fly in the window and fix it?
[10:19] <mborzecki> xD
[10:49]  * pstolowski lunch
[12:12] <pstolowski> pedronis: thanks for the 2nd pass over base validation PR
[12:12] <pedronis> np, thank you
[12:14] <mborzecki> off to pick up the kids
[12:17] <pedronis> Chipaca: I reviewed #7001, thank you
[12:35] <pedronis> Chipaca: I asked you for another pass in #6680
[14:06] <diddledan> 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] <kenvandine> diddledan: i don't think so
[14:06] <diddledan> ok, cool
[14:59] <Chipaca> pedronis: thanks for the review, will fix that messaging
[15:56] <diddledan> 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] <jdstrand_> 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] <diddledan> I'm not sure
[16:02] <diddledan> this is the message I get in a dialog when I try to open the internal help:
[16:02] <diddledan> 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] <diddledan> (uid=1000 pid=8614 comm="/usr/lib/gvfs/gvfsd-http --spawner :1.22 /org/gtk/" label="unconfined")
[16:03] <diddledan> it looks like it's using gvfs to download the help document
[16:04] <jdstrand_> 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
[16:05] <jdstrand> diddledan: gimp should be adjusted to use xdg-open
[17:02] <mborzecki> opensuse repos still flaky
[17:32] <Chipaca> mborzecki: <surprised electric mouse poket monster>
[17:32] <mborzecki> Chipaca: sounds like you caught a pikachu :)
[17:33] <Chipaca> mborzecki: more like a dedenne
[17:34] <mborzecki> hahaha
[17:34] <Chipaca> * this conversation is being supervised by 14-year-olds
[17:45] <Pharaoh_Atem> mborzecki: openSUSE's mirrorbrain crashed and burned this morning
[17:46] <mborzecki> Pharaoh_Atem: as in literally or just some random outage?
[17:46] <Pharaoh_Atem> random outage
[17:47] <mborzecki> hah, there it is: https://status.opensuse.org/
[17:52] <Chipaca> Pharaoh_Atem: if it's any consolation, so did all of Uruguay, most of Argentina, and a good chunk of Brazil
[18:19] <mborzecki> Chipaca: still around? can you take another look at https://github.com/snapcore/snapd/pull/6680 ?
[19:13] <albertosottile> jdstrand: sorry to bother you, are we supposed to do anything else for the alias request?
[20:04] <jdstrand> 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] <albertosottile> jdstrand: thanks :)