=== dps_ is now known as dps [05:14] morning everyone [06:52] good morning desktoppers [07:05] good morning [07:09] salut didrocks & oSoMoN [07:09] salut jibel [07:19] meh don't know how to use bzr anymore :/ [07:28] heh, using git too much :) [07:28] jibel: when you got a sec: https://github.com/ubuntu/zsys/pull/26 [07:28] ubuntu issue (Pull request) 26 in zsys "Fix many ineffectual assignments and typos" [Open] [07:31] salut jibel et didrocks [07:31] hey oSoMoN === pstolowski|afk is now known as pstolowski [08:29] didrocks, merged [08:29] thx! [08:29] gooood morning desktopers [08:30] salut les frenchies :-) [08:38] salut seb128 [08:39] lut didrocks, comment ça va aujourd'hui ? [08:40] ça va, et toi ? [08:44] ça va bien, entrain d'essayer de finir les formations :-/ [08:50] good morning desktoppers [08:51] hey marcustomlinson [08:52] salut seb128 [08:52] good morning marcustomlinson [08:52] lut oSoMoN, hey marcustomlinson, how are you today? [08:53] feeling good, you? [08:53] feeling better thanks [08:54] I'm good thx [08:56] brb, changing location === jdstrand_ is now known as jdstrand [15:34] oSoMoN, just as a FYI, that librsvg build issue with rustcc 1.38 should be fixed by https://gitlab.gnome.org/GNOME/librsvg/commit/de26c4d8 [15:34] but it requires an update of the cssparser vendor copy included and I'm unsure how to properly do that [15:36] I downloaded a newer version, diffed the dir and added as a patch for testing but that fails because a .cargo-checksum is missing [15:39] good morning folks [15:39] seb128, thanks, I'll take care of it [15:40] hey Heather! how are you today? [15:40] good morning hellsworth! [15:40] oSoMoN, thx, I'm not saying that it will fix the ppc64el issue though but let's see === heather is now known as hellsworth === pstolowski is now known as pstolowski|afk [20:28] hi folks, I'm investigating slow startup performance in gnome snaps like gnome-calculator and I'm wondering what the purpose of the /usr/bin/gjs file being linked from the gnome-3-28-1804 content snap? [20:28] hmm good question, let me go take a look at the content snap [20:29] Specifically, I'm wondering: [20:29] 1. can this file instead be located at /snap/gnome-calculator/current/usr/bin/gjs instead of /usr/bin/gjs? [20:29] 2. that file in gnome 3.28 1804 content snap is a symlink to gjs-console, will it always be a symlink like that or could gjs point to something else like gjs-console2 ? [20:30] thanks hellsworth [20:31] where do you find gjs being linked? i mean where do you see this /usr/bin/gjs? [20:31] hellsworth: it's in the gnome-3-28-1804 content snap at /snap/gnome-3-28-1804/current/usr/bin/gjs [20:32] err that's the source [20:32] it's being used in a layout in the gnome-calculator snap like this: [20:32] https://www.irccloud.com/pastebin/ZfgDkUNp/ [20:34] what that layout amounts to in the snap is that a symlink shows up at /usr/bin/gjs which points to `$SNAP/gnome-platform/usr/bin/gjs` [20:34] (also sorry I had a typo in that snippet I pasted above, I updated it [20:38] can you point me to the snapcraft yaml you're looking at? If I look at the gnome-calculator snapcraft in master and then do `snapcraft expand-extensions` there is no gjs mentioned: https://gitlab.gnome.org/GNOME/gnome-calculator/blob/master/snap/snapcraft.yaml [20:38] so i'm wondering how gjs got in there [20:39] ijohnson: this is wild-guess territory as I don't know much about any of these tools -- my guess is this is to allow all the gnome snaps to share the same javascript interpreter, so that you don't have to have a dozen different JS interpreters loaded at once, but can share the memory for these processes (SHR column in top) [20:40] hmm that would make sense [20:42] sarnold: yes that makes sense, my question is more about why it needs to be mounted at /usr/bin/gjs and not at $SNAP/usr/bin/gjs or even just at $SNAP/gnome-platform/usr/bin/gjs [20:42] hellsworth: I just ran `snap download gnome-calculator` and am looking at the file `meta/snap.yaml` from the snap [20:43] unsquashed with `unsquashfs gnome-calculator_544.snap` [20:43] ijohnson: hmm. compounding my guesses at this point, in case something within the application tries to use the interpreter in a funny fashion? maybe libraries to spawn different things would call gjs directly through its well-known-location? [20:44] sarnold: yeah that is usually why folks use layouts, but it's unfortunate here because this layout leads to 500-1000ms of snap-update-ns setting up various mounts [20:44] hellsworth: indeed the snapcraft.yaml at that gitlab repo looks much different from what's on stabl in gnome-calculator indeed [20:46] hellsworth: looks like gnome-calculator edge has the same as stable basically [20:46] ijohnson: ouch :( that's really painful for an interactive app. [20:46] not a big deal for IOT usecases, but .. ouch. [20:46] sarnold: yes, hence why I'm looking into it :-| [20:47] ijohnson: maybe snapd could pre-create all the namespaces when snaps are installed or when snapd is started, and reuse those namespaces for execution? [20:47] the namespaces do get re-used for subsequent launches, but for the first launch either right after install or first launch after boot [20:48] for those cases we have to create these mounts [20:52] well gjs is placed there because of this commit: https://github.com/snapcore/snapcraft/commit/55bfb2dfcf5f604ee2ebbf3970a4fd846b021771 [20:54] i don't know why this was added tbh though [20:56] hellsworth: thanks for that pointer, this at least gives me a test case I can look at for why the gjs binary is needed at all, because gnome-calculator doesn't seem to need it at all [20:56] nice find hellsworth [20:57] makes sense to me now why this doesn't make sense to me now :P [20:57] lol [20:58] lol [21:00] * ijohnson be back in a bit [21:01] https://github.com/snapcore/snapcraft/commit/55bfb2dfcf5f604ee2ebbf3970a4fd846b021771#r36058007 [21:01] maybe the commiter can comment on why gjs was added. it looks very deliberate so there must have been some strong reason [21:01] and that reason can be weighed with the 500-1000ms expense [21:06] gnome-characters could use it [21:06] But many other gjs apps [21:07] It's for convenience [21:07] Most gjs hard code the interpretor path for gjs [21:08] So all gjs have to be patched without the layout [21:08] Not just using the content snap [21:08] Even trying to bundle gjs, they still needed patching [21:09] ijohnson: ^^ [21:22] kenvandine: hmm that's unfortunate, is this a script type situation like with python paths in the shebang where snapcraft could autonatically fix the location of gjs to somewhere else or even better just to search on $PATH? [21:24] people, we'd like to update the GNOME Boxes' recommended downloads so it shows the latest ubuntu release [21:24] however, in order to so, I really would need a review on https://gitlab.com/libosinfo/osinfo-db/merge_requests/54 [21:24] libosinfo issue (Merge request) 54 in osinfo-db "ubuntu: Add 19.10 entry" [Opened] [21:24] would be possible to have someone from canonical to take a look at that and tell me that I'm not missing something? [21:26] jbicha: ^^ [21:26] and didrocks isn't online atm [21:27] hellsworth: I've marked them on the MR when I opened it (a few weeks ago) [21:27] i know but maybe they forgot so maybe it's time to ping them again :) [21:28] hellsworth: let's hope they see it (if not, I'll ping Didier Tomorrow on our timezone) [21:29] good plan [21:31] hellsworth: thanks for the help! [22:24] marcustomlinson: i finally got around to testing cherrytree with gtk2 stuff like gimp has and it doesn't look any different than it did when i was using the gnome extension [22:25] https://github.com/hellsworth/cherrytree/tree/add-snap [22:25] i really just don't know why the snap package looks different from the deb [22:26] any thoughts you have are welcome :) [22:29] hellsworth: have you tried deleting ~/snap/cherrytree and re running [22:32] hmm no [22:32] i should try that :) [22:33] yeah even that didn't change things [22:33] Interesting, I’m not at a computer right now, I can take a look tomorrow [22:35] no rush. i could use your expertise when you have time :)