[00:11] man, im liking the feel of the 20.04 desktop rn [00:13] ik its just dailies, but still. if this is any hint at what we have to look forward to in the actual stable release, then i think the talk where people are saying stuff like "Ubuntu doesnt care about its desktop users anymore" has no merit whatsoever [00:15] as a new user to the Linux world (almost a year now and ive used many distros), this is what kind of a fresh desktop i want, and i believe that this is the desktop that (if pushed out into the open enough and marketing was strategically done) could bring in a whole new wave of users [00:15] at any rate, thanks to the desktop devs. ill be sending my thanks soon, actually [00:15] ;) [02:03] robert_ancell: hi. I was having a discussion about theme snap installation last night, and how it will probably require some background service in the desktop session to monitor changes [02:04] robert_ancell: there was some questions about where to host the code for such a daemon since it will probably have to be written in C, and one option proposed was to ship it with snapd-glib. Do you have any thoughts on that? [02:23] jamesh, I would think it would make sense for it to be a separate project, but I'd have to look at more details on the service. [02:27] robert_ancell: it would be a background service that monitors GtkSettings to watch GTK, icon, and sound theme names, and trigger installation of a snap if there are no installed snaps providing that theme, probably via snapd-glib [02:28] Yeah, that definitely sounds like it should be a separate project. Why would it be part of snapd-glib? [02:30] there was some concern about hosting it in the snapd repo itself due to the extra build dependencies, and that if it uses snapd-glib it might cause a dependency loop (even if just for testing) [02:31] I guess the suggestion for snapd-glib was to make it easier to get the thing rolled out [02:32] That's what it sounded like :) [02:33] It sounds like a 'snap-desktop-support' project to me. [02:33] That would contains any services that a desktop might require. [02:35] that's probably a good idea. [02:36] I think there was agreement that this can't easily be written in Go, and specifically can't easily be a subcommand of /usr/bin/snap [02:59] jamesh, does it use dbus? [03:00] robert_ancell: it would be using libgtk [03:01] oh, yeah, that would be a pain in go. [03:01] gtk_settings_get_default() and then get properties on that GtkSettings object plus notification of changes [03:02] we want the current theme as GTK understands it, which means doing XSETTINGS on X11, dconf on Wayland, etc [03:03] and Wimpress pointed out that e.g. Mate uses different gsettings keys to store the user's preferred themes [03:03] so we can't ignore XSETTINGS [06:38] good morning [06:39] hi didrocks [06:41] salut jibel [06:46] Search Results [06:46] Web results [06:47] arrrgh, middle button click :-/ [06:47] but, anyways, while still here ... [06:47] ça va didrocks, jibel ... [06:48] good morning fidencio :) [07:13] good morning desktoppers [07:13] and happy Friday! [07:13] happy Friday oSoMoN :) [07:14] jibel: and tests pass, easy one to merge if you may: https://github.com/ubuntu/zsys/pull/29 :) [07:14] ubuntu issue (Pull request) 29 in zsys "Remove dead code in i18n which lower coverage" [Open] [07:16] didrocks, merged [07:16] thx! [07:17] Hi fidencio [07:37] Morning desktoppers o/ [07:38] FYI, I'm out of the office today. Have a good weekend and see you all next week :-) [07:40] Wimpress, hi and bye, enjoy your week end :) [07:44] hey Wimpress :) see you next week! [07:46] oSoMoN: why is Thunderbird still hanging in proposed? :) [07:47] Seems like verified already [07:49] didrocks: I know it would only bring more workload to your back, but ... I'd like to have you as part of libosinfo maintainers, specifically taking care of ubuntu stuff [07:51] didrocks: the idea (which is still in a quite early stage) would be to have people involved with the distro applying/reviewing the patches without having to wait for me to come back from vacation / other stuff to review / apply patches [07:51] didrocks: does that make sense? or is that something not desired in your opinion? [07:53] fidencio: sure, as long as it's about watching/updating xml files for the ubuntu area, I think that's not that much additional work and I would be able to handle it. [07:54] didrocks: yeah, it'd be for ubuntu *only* [07:55] didrocks: I do believe that by taking such move and starting with you (from the really big distros) will make other distro maintainers okay to jump in and take care of their side as well (thinking mainly about opensuse here, for instance) [07:55] didrocks: wjt, from endless, is already doing such for endlessos [07:55] didrocks: he even wrote a script to entirely automate the addition of files [07:55] fidencio: yeah, that makes sense that every distro takes their own part in this. I hope as well that it will help others to get motivated [07:56] I would love to see that script if we can tweak it for ubuntu [07:56] didrocks: https://gitlab.com/libosinfo/osinfo-db/blob/master/scripts/updates/endlessos.py [07:56] thx! :) [07:57] didrocks: thank you. And I really like how easy is to work with your guys! :-) [07:58] fidencio: no worry! Thanks for reaching out :) I'll probably update the script/prepare for the LTS in January [07:58] (end of year, tight deadlines I want to achieve before) === pstolowski|afk is now known as pstolowski [08:08] good morning didrocks, Wimpress, jibel [08:09] dupondje, it needs to be published by the security team, I'm guessing this should happen soon [08:21] hey oSoMoN [08:22] (well, hey again) [08:24] salut didrocks (twice is better than none :)) [08:25] heh, indeed! [08:25] morning desktoppers [08:25] hey marcustomlinson [08:33] hey marcustomlinson [08:36] hi oSoMoN, didrocks [09:49] please don't mark sru bugs 'fix committed', that's reserved for the sru tools to set [09:49] 'in progress' seems better? === ecloud_ is now known as ecloud_wfh [16:27] good late morning desktopers [16:27] hey hellsworth [16:27] hey marcustomlinson [16:27] sorry I never got around to your cherrytree snap [16:27] no problem [16:27] it's super not urgent :) [16:27] and i can take a deeper look too, once i have time [16:28] it's on my todo - just keeps getting bumped :) [16:28] i've been hunting down a bug in snapcraft, found another bug and fixed it, and then had a solution dream last night [16:28] so maybe i'll finish my thing and get to look at cherrytree today :) [16:28] also it's great when solutions come in dreams :) [16:28] haha, indeed [16:28] and then i shoveled snow today [16:28] i'm quite proud of myself :) [16:29] and sore :) [16:29] lol ok time to do all the things!! [16:29] though solution dreams are not usually so refreshing [16:29] usually feel like crap the morning after from my brain being on overdrive [16:29] well yes that is where coffee can help make up though [16:30] hmm, that could be my problem. my wife switched the coffee for decaf [16:30] taht dream was in the night and then i got up at 5 to feed the baby and slept another 2 hours so i did get some good sleep [16:30] omg that's not right [16:31] good morning hellsworth [16:31] hi oSoMoN ! [16:32] i'm having some friends over this evening where we're going to sample the beer you gave me (and some cured meats i brought back) [16:32] so cheers :) [16:32] cheers! [16:32] i wish i would have bought more of that bandolera beer. it was so tasty === pstolowski is now known as pstolowski|afk [17:41] marcustomlinson: do you have any test snaps that use either of the build snaps and also use vala? [17:44] kenvandine: hey, I was looking at https://bugs.launchpad.net/ubuntu/+source/gnome-system-monitor/+bug/1778332/comments/5 [17:44] Ubuntu bug 1778332 in gnome-system-monitor (Ubuntu) "Apparmor Permission Denied (apparmor="DENIED")" [Low,Expired] [17:45] kenvandine: I don't have a good place to put the access for this denial. I suggest your use system-files. let me try something [17:51] kenvandine: it is fixed with https://paste.ubuntu.com/p/jG7CHKvFxF/ [17:51] kenvandine: is this something you could request in the forum and fix in the snap? [17:51] jdstrand: sure [18:07] jdstrand: https://forum.snapcraft.io/t/requesting-autoconnect-of-system-files-for-gnome-system-monitor/14280 [18:11] kenvandine: responded, thanks! [18:13] jdstrand: once autoconnect is granted, does snapd autoconnect on refresh? [18:29] jdstrand: ok, built and in the review queue [18:37] kenvandine: gnome-calculator [18:37] https://code.launchpad.net/~marcustomlinson/+git/gnome-calculator [18:40] marcustomlinson: when i tried to use the build snap for gnome-2048 meson failed with "Compiler not found: valac" [18:40] kenvandine: can I see your yaml? [18:40] which build snap? [18:43] with the gnoem-3-34-1804-sdk? [18:44] gnome-3-32-1804 [18:45] +-sdk [18:45] because gnome-3-32-1804 is autoconnected [18:45] sound like something may be missing from your build-environment [18:46] i'm comparing [18:46] i don't think i am [18:46] can I see your gnome-2048 yaml [18:47] yeah [18:47] https://paste.ubuntu.com/p/Yc6w6qShSz/ [18:48] /snap/gnome-3-32-1804-sdk/nt/usr/lib/vala-current [18:48] '/nt' [18:49] marcustomlinson: you found that quick! [18:50] * kenvandine wonders where i got that form [18:50] current [18:50] -curre [18:50] but there's also $SNAPCRAFT_STAGE in your env [18:51] i dropped LDFLAGS and now it works :) [18:52] :) [18:52] why would that make it work though? [18:53] the LDFLAGS didn't include paths to what was in the build snap [18:53] both of those LDFLAGS are in the LD_LIBRARY_PATH [18:53] LDFLAGS are used at build time [18:53] LD_LIBRARY_PATH are for runtime [18:54] we need both though [18:54] you shouldn't need LDFLAGS if the pkgconfigs are correct [18:54] I SEE [18:54] oh caps [18:56] yeah, the danger of copy/paste :) [18:56] marcustomlinson: thanks! [18:56] np [19:06] how do i know what env vars i could use in the environment section? [19:06] like in gimp, i see that there is GIMP2_LOCALEDIR that is defined and used. how the heck would i know that GIMP2_LOCALEDIR is even an option to use? [19:06] reading the gimp source [19:07] i'd bet [19:07] hmm [19:07] that's a gimp specific env variable [19:07] right [19:07] ok i'll go take a look at the glimpse source to see if this is used or something similar [19:07] grep for LOCALEDIR [19:07] they might have just renamed it GLIMPSE_LOCALEDIR [19:08] but hopefully they made it smarter :) [19:08] it is apparently still GIMP2_LOCALEDIR [19:08] there's still quite a bit of rebranding that needs to be done [19:08] thanks kenvandine [19:42] have a good week-end all!