[01:01] Anybody have a good idea how to reset a 'frozen' session? I'm running TeamViewer to one account/desktop and that session is frozen, where I get X for cursor [01:02] However in second session I can log in via RSH and get console [01:02] No process is really pegging the CPU or memory? [01:06] Hello.... anybody free? [05:48] good morning desktoppers! [05:52] Hello oSoMoN [05:52] Hmm, curious how many Gnome Tweaks don't actually work... [05:53] hey duflu, good afternoon! [06:34] good morning [07:01] Morning didrocks [07:01] hey duflu [07:02] hey duflu didrocks desktopers [07:03] re seb128 [07:03] lo seb128 [07:03] hi seb128 [07:04] duflu, how are you? having a good friday? ready for the w.e? [07:06] seb128: More VAAPI debugging. Not fun. And I'm not sure about being ready for the weekend :) How are you? [07:07] I had a good 7 hours sleep, feeling good [07:07] let's see what friday brings now [07:26] salut didrocks, seb128 [07:27] joyeux vendredi oSoMoN [07:27] :) [07:32] seb128, I’m reconsidering the move to a classic snap for LO, thinking it’s not such a good idea after all. Built a strict snap with the desktop-gtk3 launcher, and that fixes most of the known issues \o/ [07:32] only bug #1665106 requires a patch, but it’s trivial, and I’ll see if I can upstream it, given how similar it is to https://github.com/LibreOffice/core/commit/28a03248b1d1649e157b788e43dfe8326f165379 [07:32] bug 1665106 in libreoffice (Ubuntu) "[Snap] Ctrl+click on a link doesn't open the link" [Medium,In progress] https://launchpad.net/bugs/1665106 [07:33] lut didrocks, bon vendredi ! [07:33] oSoMoN, oh, nice [07:34] oSoMoN, oh, right, we also have a fake xdg-open calling a dbus method, only it's under /usr/local/bin/xdg-open for us [07:35] oSoMoN: I'm opening a donation page for the launcher ;) [07:35] lol [07:36] seb128, yep, so the patch looks like this: http://paste.ubuntu.com/24987313/ [07:36] oSoMoN, looks good, the other alternative would be to tell them to call "xdg-open" rather than "/usr/bin/xdg-open" [07:36] didrocks, will the donations pay for all those extra hours you put into it? ;) [07:37] so local versions take over [07:37] including the snap one [07:37] oSoMoN: hem, "funds repartitions need to be decided and voted on" :p [07:38] seb128, yes that’s another option, I’ll see what upstream prefers [07:38] hum [07:38] /usr/local/bin was in $PATH [07:38] then removed by upstream [07:38] but ogra told he would reinclude it IIRC [07:38] (some months ago) [07:39] that's a snap issue to be resolved yeah [07:39] I was talking about the libreoffice side [07:39] that was in the snap-confine related change IIRC (the move to snap run) [07:40] good morning [07:41] buon giorno andyrock [07:41] hey andyrock, happy friday! [07:42] hey andyrock [07:43] tjaalton, when do you think llvm-toolchain-4.0 will migrate to xenial-updates? I’ve tested a build of chromium-browser (dev branch) with clang-4.0 from -proposed, and that works well [07:44] oSoMoN: along with the rest of the 16.04.3 hwe stack [07:44] next month [07:44] best guess [07:44] good, looking forward to it [07:46] didrocks, it should be in the launchers afaik ... [07:46] also ... we moved xdg-open inside core to a sane path [07:46] ogra_: changing PATH to a system one? [07:46] I don't understand why the PATH was removed without warning btw [07:46] yeah [07:46] it's a behavior change [07:46] and core 16 was already released [07:47] (the fact that it was independent of snapd was requested by the snap team btw when designed) [07:47] ogra_, what do you mean by a sane path? it's currently /usr/local/bin/xdg-open, right? is this going to change? [07:47] https://github.com/snapcore/core/pull/35/files [07:48] nothing changed PATH though ... the in-core xdg-open was just moved around so the PATH hack wouldnt be needed anymore [07:48] oh! that means I can drop my LO snap patch then, that’s good \o/ [07:48] yeah :) [07:49] ogra_, when is that landing in a snap store near me? [07:49] now ... thats a merge to master though [07:49] not sure if thats already in a relese [07:49] i would guess with the next stable core snap ... mvo should know when that happens [07:49] good, I’ll ask mvo [07:50] hrm, he doesn't appear to be around [07:51] he sits next to me ... one sec [07:51] heh, even better :) [07:51] he says next week [07:51] excellent, say hi for me btw [08:02] hi, happy friday! [08:02] happy Friday to you too! [08:03] hey Laney! morning pitti [08:03] ah, pitti, a nice Friday treat! [08:03] how's it going? [08:04] hey didrocks, how are you? [08:04] Laney: good, thanks! Yourself? [08:07] didrocks: good! [08:08] off on holiday next week ;-) [08:08] nice! :) [08:10] hey Laney, how are you? [08:10] oh, off next week, any nice plan ? [08:11] going to surf? ;-) [08:16] seb128: I'm grrrrrrrrrrrrreat, what about you? [08:16] maybe, it is near a surfing place [08:41] Laney, I'm great as well, just got a nice cappuccino :-) [08:41] there is a new coffee place that opened just next street [08:42] easy walk to get some coffee to go, it's nice [08:48] morning all [08:48] broken down train today \o/ [08:49] * willcooke also has an ethernet cable today [08:49] tintou Hi [08:49] didrocks Morning [08:50] didrocks Have you seen any reports about desktop-gtk3 snaps not using localisation? [08:50] good morning flexiondotorg [08:50] flexiondotorg: I didn't, but if it's related to gettext, we know the issue and nothing that desktop-gtk3 can fix [08:51] OK. related to gettext how? Bug? [08:51] Anything an application author can work around? [08:51] gettext doesn't let you using relocatable path [08:51] it's based on --prefix [08:51] Oooh [08:51] so, you can --prefix=/snap//current [08:51] we raised that multiple times on the ML [08:52] Right, I remember now. [08:52] apparently, this path is supposed to be stay stable ^ [08:52] I've used that myself. [08:52] stay* [08:52] I'm sat with the elementary guys. [08:52] They've bumped into this. [08:52] I hope it's cross-distro, we were told that shouldn't change [08:52] and don't have any other way to make it work [08:56] didrocks Well, seem to be consistent on GNOME, Unity, MATE and Pantheon so far. I'll check with the KDE guys. [09:21] Laney, great blog post! [09:21] Sorry for ignoring everyone in here this week, been crazy busy here [09:23] robert_ancell, hey [09:24] good decisions? [09:24] what are the news on the desktop side [09:30] seb128, we have a title field from snapd, so snaps should start looking nicer [09:30] We have a plan for the license field to pass through, though we need to wait for support from the store [09:31] We've fixed a bunch of small issues that block us from having Snap support in Fedora. These are mostly solved so just tidying up loose ends. [09:31] KDE Discover is now using snapd-qt, and the MATE Software Botique is using snapd-glib GIR bindings. These shook out some bugs in snapd-glib. [09:32] nice [09:32] We are all in agreement that snapd / store should return translated fields, though no ETA for it [09:32] We have a plan to get basic AppStream information through the store and snapd so G-S etc can show things better. [09:33] We'll make a snapcraft plugin to pull out that data and populate the Snap YAML - so it should be easier to snap existing projects [09:33] hey robert_ancell [09:33] thanks! [09:34] a summary mail next week would be nice ;-) [09:34] We have a plan to make an snap interfaces tool that will be shipped as a Snap (i.e. available for all systems) and will be linked to from G-S and/or G-C-C. It's a highly questionable UI so there will be ongoing discussions I'm sure... [09:34] Laney, yep, will do [09:35] We have a plan to install/remove snaps on a GUI without a store login, which is awaiting confirmation by the Snappy designer [09:40] willcooke: do you know if xdg-desktop-portal issues have been discussed at the sprint? (allowing per-user bind mounts) [09:41] jamesh, not yet I'm afraid. [09:41] I'll try and grab m_vo later on and see if he's got any thoughts [09:42] willcooke: the main things I'd want are an agreement that snapd should switch to per-user per-snap mount namespaces, and a basic sketch of how they should be managed. [09:43] willcooke: with that, it we might be able to help with the implementation [09:43] jamesh, ack, thanls [10:52] robert_ancell: gnome-software/zesty was just pushed to updates and got stuck in phased-updates again: https://errors.ubuntu.com/problem/f4d12cec512c23a979e3ccd1f0dc94fd8b406007 [10:53] jbicha, yeah, I saw :( [10:53] anyway, for next week :| [10:54] oh weird. An icon issue. [10:54] I wonder if that's always existed [10:55] Perhaps there's an out of memory issue and I'm not checking for the buffer being NULL [10:56] I had someone from Azerbaijan tell me the polkit message was not Azerbaijani, it was Turkish [10:58] I think the problem we saw before is that it was picking the last message from the file [10:59] that was in Fedora - in Ubuntu we had some patch somewhere (awesome level of recall) that made the translations work [11:10] Laney, I've been looking through the Polkit docs and existing programs and still scratching my head how the locale is supposed to work there [11:10] It either "just works" for other prompts or they aren't currently translated [11:19] arhghghaoih [11:19] rob taB TAB TAB T [12:29] oSoMoN, hi, fun fact about https://bugs.launchpad.net/bugs/1700692 -- it built on trusty ;) [12:29] Ubuntu bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,New] [13:09] ricotz, interesting, do you know what kernel was used for the build? [13:09] jbicha, btw did you see my comments on bug #1700692 ? [13:09] bug 1700692 in libreoffice (Ubuntu) "FTBFS on i386: dbaccess_RowSetClones unit test segfaults" [Critical,New] https://launchpad.net/bugs/1700692 [13:15] bah [13:15] this gst <-> packagekit stuff is annoying [13:15] gstreamer1.0-packagekit feeds different fields into the backend compared to sessioninstaller [13:16] * Laney cries at ximion [13:16] Laney: is that a problem? as long as packagekitd does the right thing, it shouldn't be an issue... [13:17] it ends up in that regex of doom [13:17] or is the gstreamer plugin itself also broken? [13:17] yeah, urgh... [13:17] which isn't that tolerant [13:17] although in this case it's actually nicer [13:17] because gst-packagekit gives you "64bit" so we are able to use that to filter out some results [13:20] I wonder whether using libappstream + the new components in there would make some sense [13:20] (bypassing PKs own detection) [13:20] alternatively, making the regex more tolerant or using string operations instead might make sense [13:22] we need to specify AS so that type=codec is good enough to do this [13:23] have a look at apt show gstreamer1.0-plugins-bad - those caps are the things it searches on [13:24] oSoMoN: could you ask someone that can update the LP builders about that then? [13:25] oh, that's the stack clash regression [13:25] maybe next week then [13:30] oSoMoN, of course 4.4.0-81 like all builders ;) [13:30] oSoMoN, maybe there is even another factor like glibc, but I guess the kernel is still the culprit after all [13:31] ricotz: yes, there's a known regression affecting java [13:32] jbicha, I know, surprisingly a build on trusty/i386 succeeded [15:55] seb128 didrocks Can you point me at the yaml for the current GNOME platform snap? [15:55] ANd an example application snapcraft.yaml that uses it please? [15:56] flexiondotorg, ken has been working on that but [15:56] http://bazaar.launchpad.net/~ubuntu-desktop/+junk/snap-gnome-3-24/view/head:/snapcraft.yaml [15:57] and http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gedit/view/head:/snapcraft.yaml [15:57] and using it is like any other traditional app using the launcher: http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghex-snap-gnome-3-24/view/head:/snapcraft.yaml [15:59] hum, ken is adding another path for gsettings: http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gedit/view/head:/snapcraft.yaml#L44 [15:59] chrisccoulson, hey, have you had a chance to test chromium-browser 59.0.3071.109 in https://launchpad.net/~canonical-chromium-builds/+archive/ubuntu/stage/+packages ? [15:59] * didrocks looks at the launcher, we should probably factor that in [15:59] GS_SCHEMA_DIR=$XDG_DATA_HOME/glib-2.0/schemas [16:00] I bet the additional export doesn't work ^ [16:00] kenvandine[m][m]: FYI ^ [16:00] seb128 didrocks Thanks! Sat here with elementary. [16:00] are they snapping things? [16:09] seb128 Yes. [16:09] ANd we are now looking at using a content snap for their SDK. [16:33] seb128, problems with the gedit snap? [16:39] * oSoMoN ⒺⓄⓌ [16:39] have a great week-end everyone! [17:10] have a nice we :D [17:16] have a nice w.e everyone [17:16] & good holidays Laney [17:16] laters seb128! [17:16] happy week to you [17:16] kenvandine, not that I know, flexiondotorg was asking for an example for snap using the platform [17:16] seb128, ok [17:17] Didier was pointing something, maybe ask him on monday if you don't understand what he meant [17:17] I'm not sure what was the issue [17:17] it was working fine [17:17] yeah, saw that but didn't understand [17:17] I think he just pointed out that your env hack was unrequired/probably not doing anythin [17:17] it was needed :) [17:17] like the desktop helper set that [17:17] or should set [17:17] or override your def [17:17] well then the launcher should be fixe [17:17] d [17:17] desktop helper probably would be better [17:17] yes [17:18] that's probably what he meant [17:18] that's supposed to work without the hack [17:18] so if that's needed there is a bug in the helper we should look at [17:23] night! see you in a week! [17:23] break all the things === Cimi_ is now known as cimi [20:04] sarnold, any updates on the gdm3 security review? [22:38] Hello, I have a unity desktop question... any takers? === JanC_ is now known as JanC [23:46] hey kenvandine, still in progress. I gotta say I wish we were sticking with lightdm.