=== user8394 is now known as user8393 === user8394 is now known as user8393 === user8394 is now known as user8393 [07:54] good morning desktoppers! [08:16] Morning oSoMoN [08:20] good morning [08:23] hey duflu [08:23] salut didrocks [08:23] how was the week-end? [08:28] salut oSoMoN, week-end was uneventful, visited a place where we could build a house though and it looks nice :) [08:28] and you? [08:28] good morning desktopers [08:28] lut oSoMoN, re didrocks [08:28] re seb128 [08:29] salut seb128 [08:29] didrocks, nice! [08:30] Bonjour desktopers [08:30] hey flexiondotorg [08:30] hey flexiondotorg [08:30] hey flexiondotorg [08:31] Morning didrocks, seb128, flexiondotorg [08:31] I had a really good week-end, went to the theater on Saturday and cycling with my daughter and cooked tartiflette for friends yesterday [08:31] nice [08:32] hey hey duflu ;) [08:32] you like cheese-based meals on sunday :) [08:32] sounds nice oSoMoN! [08:32] hey duflu [08:32] duflu: Morning [08:32] seb128, I do :) [08:39] good morning ricotz [09:01] morning all [09:01] hey willcooke [09:06] hey willcooke, had a good w.e? how is u.k today? [09:07] hi chaps. Chilly but sunny [09:07] So pretty nice [09:09] nice [09:11] Morning willcooke [09:16] https://community.ubuntu.com/t/call-for-participation-an-ubuntu-default-theme-lead-by-the-community/1545/477 [09:16] "I think it was a very good decision to lock some threads to designers only" -> Yes! especially from some people frowning upon it at first :p) [09:17] haha [09:27] hey desktopers [09:27] oSoMoN, hi [09:28] hey ricotz [09:35] Good morning seb128! [09:39] ogra_, thanks for replying to that dude who had desktop file issues. [09:39] np :) [09:40] seb128: Your eyes on bug #1707898 would be much appreciated. [09:40] bug 1707898 in systemd (Ubuntu) "systemd translations are not synced with upstream" [Medium,In progress] https://launchpad.net/bugs/1707898 [09:41] hey GunnarHj [09:42] GunnarHj, yeah, you said so on friday :) [09:42] I'm going to have a look, I've just been busy (and sick/a bit slow on friday) [09:45] Anyone know which airport I want for easy transfers to downtown Berlin? [09:45] Tegel looks like the closest [09:46] both work [09:46] cool, thanks doko [09:47] hey guys [09:47] anyone with multi-monitor setup can verify this SRU bug (one of the latest remaining): https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1671432 [09:47] Ubuntu bug 1671432 in unity (Ubuntu Xenial) "Global application menu does not follow mouse move for displaying submenus in multi-monitor setups" [Undecided,Fix committed] [09:53] Trevinho, trying now via a VM... [09:54] oh thanks, let's hope it ueses multi-monitor correclty [09:55] bah, it doesnt [09:59] no good, sorry Trevinho, I'd have to reinstall Xenial to test [09:59] willcooke: no worries, let's see if someone else can do it [09:59] Trevinho, maybe a post to the hub and we can share on socials [10:04] Trevinho, willcooke, I can give it a try [10:04] Trevinho, good morning btw :) [10:04] HI! [10:04] :D [10:04] lol [10:33] Hi and bye [10:33] Hi and bye, Trevinho [10:33] hi and bye duflu :) [10:33] hi seb128 [10:33] thanks [10:41] ricotz, have you pushed all your changes to ubuntu-bionic-6.0 ? [10:43] I'll run autopkgtests for 1:6.0.1~rc1-0ubuntu0.18.04.1~lo1 in a VM [10:49] oSoMoN, yes [10:49] excellent, thanks! [10:49] and thanks for figuring out that missing translations bug, that was nasty [10:50] yeah buried deep in the buildsystem :( [13:41] oSoMoN, hi [13:42] oSoMoN, I talked with you in NYC about the print dialog of LibreOffice. [13:48] tkamppeter, ack, I'm having lunch now, I'll ping you when I'm back at the desk to chat [13:48] oSoMoN, OK. [14:31] tkamppeter, I'm back [14:32] can you refresh my memories of the print dialog? I remember you talking to me about it, but quite vaguely tbh [14:33] tkamppeter, is it https://trello.com/c/TxIN7fGQ/1-make-all-print-dialogs-use-current-printing-technologies-via-common-backends-cpdb ? [14:35] Yes, exactly this. the backend libraries and the backends are now packaged and in Universe and MIRs are posted. [14:37] This would mean that if you let LO build-depend on the backend libraries (cpdb-libs) the need of the MIR will get evident. [14:39] oSoMoN, ^^ [14:41] tkamppeter, so what's needed exactly? a simple additional build-depend is enough, or also patches to LO ? [14:41] Laney: for when you're back, what is needed to update appstream-generator / libappstream to refresh the data for Bionic? Newer generators are able to be a bit more relaxed when finding icons, which might be very beneficial to find new apps [14:41] they also support fonts a bit better and add support for webapps [14:45] ximion, he's back on wednesday [14:45] oSoMoN, you need to check whether said change is already in the LO version which you are usinng. If not, yoiu need to backpoort the change as distro patch. In addition, you need to build-depend on cpdb-libs so that ./configure will setup for building with cpdb-libs support. [14:45] tkamppeter, do you have an upstream bug reference? [14:46] seb128, upstream bug reference for what? [14:46] tkamppeter, well, were those print dialog changes proposed upstream? if so there must be a bug report/merge request? [14:47] tkamppeter, when was it merged upstream? do you have the commit ids ? [14:50] tkamppeter: you shouldn't add the Build-Depends until the MIR is approved since it will just cause LO to get stuck in bionic-proposed [14:51] jbicha, he said was was needed to build with it, not that it needs to be done now [14:51] jbicha, hey btw [14:51] howdy [14:55] oSoMoN, seb128: Here we go: https://gerrit.libreoffice.org/#/c/40565 [14:56] tkamppeter, do you know if any distribution is enabling that backend yet? can it be split into a new binary that is installed only why those who want to test it? [15:00] seb128, do not know about adoption by other distros. [15:01] seb128: yet another MIR needs a bug subscriber :| LP: #1748905 [15:01] Launchpad bug 1748905 in libdazzle (Ubuntu) "[MIR] libdazzle" [Undecided,New] https://launchpad.net/bugs/1748905 [15:01] seb128, the principle is that on the system backends for each print technology (currently CUPS and Google Clkoud Print) will get installed separately. [15:02] seb128, by a D-Bus broadcast call the print dialog finds the backend and listed the printers supplied through each of them so that the user can use them. [15:02] seb128, Immediate advantage for LO user is: [15:03] 1. Google Cloud Print support just out of the dialog. [15:03] 2. Support for the newest CUPS printing technology, especially CUPS' ability to auto-create queues for network printers. [15:04] Future advantages will be: [15:04] 1. All apps (GTK, Qt, LO, ...) will use these backends, so they will all have complete printing supports. [15:05] 2. Modifying one backend, for example for advances in its print technology, security fixes, ... will make the changes available for all apps immediately. [15:05] seb128, ^^ === ChrisTownsend1 is now known as ChrisTownsend [15:15] jbicha, did you notice that n-m hit failing autopkgtest issues? [15:17] seb128: yes but I'm hoping someone else can look into those autopkgtests :| [15:20] oSoMoN, still any questions? [15:24] jbicha, lol, that's why I asked [15:24] tkamppeter, sorry I was in an hangout [15:25] tkamppeter, I know the advantages of the common backend, but it's new and not well tested and might have crashes and bugs that the current libreoffice backend doesn't have [15:25] tkamppeter, so I checked and your code is in 6.0, which will make its way to bionic this week, but until that MIR for cpdb-libs is approved it is premature to add a build-depends in libreoffice [15:26] tkamppeter, which is why I'm asking if it can be optional/installed as an extra file [15:26] if no new backends are installed by default, and LO falls back graciously to cups as it works today, that should be fine [15:28] so those are extra files? [15:28] which means you could build-depends on it even if it's universe as long as the result deb is in universe [15:28] if you create a new binary for it I mean [15:30] seb128: I'm not exactly a network guy, I just have helped with updates since I guess I cared more about NM than others :( [15:30] seb128, AFAIK the student has also put a fallback that if there are no backends installed on a system that LO will use the old method, but for the automatic change support LO needs to get built with cpdb-libs. [15:32] jbicha, yeah, thanks for that, no problem, it's just than now we need to find somebody who is wanting to figure those issues out [15:32] we are a bit all busy atm [15:33] tkamppeter, and that fallback mechanism has been well tested I assume? [15:35] for nm, where do I see autopkg test failures for dev? [15:36] gQuigs, people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#network-manager [15:36] gQuigs, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#network-manager [15:38] ty [15:39] gQuigs: congratulations on becoming the new NM maintainer 😉 [15:40] lol [15:43] :) [15:48] pitti, hey, do you still work on systemd packaging? Do you have any opinion on https://launchpadlibrarian.net/356559238/systemd-translations-2.debdiff ? [15:49] the polkit part seems hackish domain one probably makes sense and maybe xgettext as well [15:49] wdyt? [15:49] GunnarHj, ^ [15:50] GunnarHj, I don't really understand the sed hack for the actions files but that should probably be fixed upstream and not in a rules hack [15:52] jbicha, oh, and for libdazzle / subcribed, ack [15:52] kenvandine, do you know what's up with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1746710 ? [15:52] Ubuntu bug 1746710 in snapd (Ubuntu) "Snap creates redundant duplicate directories in home folder" [Undecided,Confirmed] [15:53] some snaps seems to create untranslated xdg dirs [15:54] seb128: I forgot whether the gettext support for polkit was something ubuntu specific or actually in debian/upstream [15:54] hum, good question [15:54] seb128: if it's upstream, then this should just be done upstream [15:54] I don't understand the --gettext-package=systemd bit [15:54] I think gettext upstream learnt to do that [15:54] it's not explained in the changelog [15:55] pitti, the bug claims the build is currently generating an untitled.pot [15:55] pitti: policykit-1 changelog says the gettext support is a backport from master [15:56] which intltool-update usually does if you don't give it the domain to use [15:58] pitti, systemd-237/po$ intltool-update --pot --verbose [15:58] ... [15:58] Wrote untitled.pot [15:59] static void get_localized_data_for_challenge() [15:59] gettext_domain = polkit_details_lookup (details, "polkit.gettext_domain"); [15:59] message_to_use = polkit_details_lookup (details, "polkit.message"); [15:59] right, so the .policy file needs to specify the gettext domain [15:59] pitti, it was working/generating the right filename in 229 from xenial though, unsure what changed [16:00] and it seems they don't, and that patch doesn't add it there either [16:01] oh, it actually does [16:01] so I'd suggest to instead file a systemd upstream PR that does this (replace translations with the gettext-domain="systemd" attribute [16:01] seb128, pitti: I built the patch successfully locally. Just bothered by the hackishness. [16:02] the first hunk seems fine for Debian as well at first sight [16:02] pitti, that makes sense to me [16:02] I'm happy to review/land it upstream [16:02] pitti, should it be send to the BTS for review? [16:02] the first hunk I mean [16:02] (the second part, I mean) [16:02] right [16:03] pitti, danke! [16:03] for the first hunk, I'm okay with committing it directly [16:03] nice [16:03] GunnarHj, ^ [16:03] it just seems a little too borad [16:03] GunnarHj, does that sounds good to you? [16:03] broad [16:04] the explicit xgettext is only meant to extract translatable bits from the .policy files, right? [16:04] as the rest should be done by intltool-update? [16:04] I guess [16:04] GunnarHj, ^ [16:05] pitti, seb128: Is the "first hunk" equal to the first patch I submitted to the bug report? Yes, xgettext is there only to include the strings from .policy files. [16:06] GunnarHj: right; I wondered if that can be called on src/*/*.policy.in instead of everything? [16:06] just to avoid second-guessing the build system too much and extracting it twice [16:06] GunnarHj: no, a "hunk" in a patch is a part that is separated by @@ [16:06] i. e. the smallest "atom" of a patch [16:07] GunnarHj: i. e. in https://launchpadlibrarian.net/356559238/systemd-translations-2.debdiff [16:07] GunnarHj: the first hunk is the --gettext-package=systemd/xgettext part [16:07] the second the mangling of the .policy files [16:07] which should be fixed in the upstream build system rather -- there's little point in having them work against each other [16:08] and this is useful for other distros too [16:08] pitti: Right, I got that, just mentioning that the bug report includes a first debdiff with only that. [16:08] GunnarHj: right; just wanted to clarify what "hunk" means, as you asked [16:09] . o O { takes a while to revive memory of all this ☺ } [16:10] pitti: Would you suggest that I change the xgettext call to include "called on src/*/*.policy.in" instead of pointing to POTFILES.in? [16:10] GunnarHj: oh, nevermind me - POTFILES.in is already just the "extra" files [16:11] so that part is fine, I'll commit it now [16:11] pitti: Actually it includes one .c file (two after the patches have been applied.) OTOH it ignores those. [16:12] s/it/xgettext/ [16:12] GunnarHj: right, but that's acceptable noise :) [16:12] pitti: Ok, that was the main reason for my concern. [16:12] so I figure meson figures out the bulk of *.c files to look at automatically [16:13] pitti: Actually I don't think other .c files include translatable strings. [16:14] pitti: At least no such strings appear in the .po files. [16:16] GunnarHj, seb128: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1707898/comments/18 [16:16] Ubuntu bug 1707898 in systemd (Ubuntu) "systemd translations are not synced with upstream" [Medium,In progress] [16:16] thanks! [16:17] pitti, seb128: So, if I understand it correctly, you would suggest that I file an upstream bug, where "gettext-domain="systemd" is added to the .policy files instead of the translations? [16:17] right [16:17] as support for that is in polkit, I see no reason to not fix that upstream [16:18] pitti, seb128: Ok, got it. Thanks for helping out with this! [16:18] I'm happy to immediately backport that afterwards [16:18] to avoid having to wait fort 238 [16:18] GunnarHj: thanks to you for spotting and fixing! [16:19] pitti, thx! :-) [16:20] pitti: Just one problem: I'm not able to provide a patch for that change. Don't know how to make meson do what we want. [16:21] should I have squashfs/nsfs mounts active per every snap installed? [16:21] GunnarHj: let's discuss that on the upstream issue; Zbigniew might actually know [16:21] pitti: Ok. Just file a verbal issue for now. [16:22] tjaalton, likely yes but that's rather a question for #snappy [16:22] alright [16:22] seb128, i actually thought all snaps created untranslated xdg dirs :) [16:22] i have a branch for the helpers to try to address it [16:23] kenvandine, if they do it's buggy see the launchpad bug reports and screenshots [16:23] but it didn't work :/ [16:23] good [16:23] less good :( [16:23] I can help you debug later if you want [16:23] GunnarHj: please mention me with @martinpitt somewhere, so that I get mailed [16:23] but for now I need to step out for a bit [16:24] pitti: Will do. [16:24] seb128, https://github.com/kenvandine/snapcraft-desktop-helpers/commit/9be256f76362a4f109890e033d9fc5467144f715 [16:24] seb128, if you have ideas [16:30] didrocks, gnome-shell fails to start, if one has upstart removed, but in "rc" state with config files not purged =( i think maybe gnome-shell / ubuntu-session or some such should force remove things. [16:33] xnox: is that due to gdm? [16:33] like, does the gdm "gdm" session even starts? [16:34] (maybe, let's try to find the root cause rather than forcing purging) [16:34] didrocks, gdm starts, but I am failing to login. There may have been a couple of issues 1) somehow my login got reset to "GNOME" instead of "Ubuntu" session -> changed that by hand [16:35] 2) in .xsession-errors I saw that /sbin/upstart is being executed by /etc/X11/Xsession.d/ scripts, but is not there, noticed that upstart is removed, but not purged (hence the left over config file) [16:35] so I purged upstart, and then logging in started to work. [16:35] it should be reproducible by installing upstart, removing it, but not purging, and trying to login. [16:35] * xnox think upstart Xsession.d scripts are not designed to work sensibly when upstart is uninstalled.... [16:36] xnox: the "GNOME" reset is due to wayland transition, but it's only cosmetic, the fallback default is ubuntu [16:37] ack [16:39] for the session part, it sounds like more an upstart integration issue for user session [17:33] tjaalton: Ping, did you see my ping from Friday?n [18:10] tsimonq2: and replied, but didn't have time to fix that yet [18:32] ricotz, FYI, I just pushed https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?id=cb98b45509c8fe810daba893e56df2003466e02a [18:34] xnox: We have made some progress on systemd translations (bug #1707898). p_itti committed one part to Debian, and I have files an upstream issue about the rest. [18:34] oSoMoN, I noticed :), make sure to request a cherry-pick to libreoffice-6-0 branch [18:34] bug 1707898 in systemd (Ubuntu) "systemd translations are not synced with upstream" [Medium,In progress] https://launchpad.net/bugs/1707898 [18:36] ricotz, where do I request a cherry-pick? [18:36] oSoMoN, there is a button in gerrit for it [18:38] ah, right, I needed to log in to the gerrit webui to reveal it [18:39] ello, does anyone here use Zoom for video conferencing ? [18:40] czajkowski: occasionally.. why? [18:41] oSoMoN: I'm going to need a 5.4.5 LO package for artful to fix CVE-2018-6871...is that available somewhere? [18:42] mdeslaur, not yet, 5.4.4 just made its way to artful-proposed today, I'll prepare 5.4.5 tomorrow [18:42] oSoMoN: ok, let me know when you have it, I'll release 5.4.5 directly as a security update over 5.4.4 [18:42] I need to build it in the security pocket [18:42] ok [18:44] oSoMoN: thanks! :) [18:44] mdeslaur, what about xenial and trusty, should we cherry-pick the fix for the CVE and SRU just that? [18:44] oSoMoN: I grabbed the backported fixes from debian, and am preparing trusty and xenial updates now [18:44] excellent, thanks! [18:51] gQuigs: not working on 17.10 so filed a bug with them but wondered was anyone else running into the same issues. cannot screen share [18:52] czajkowski, do you use an xorg or wayland session? screen sharing isn't going to work under wayland (dunno if that's your issue) [18:52] I use it on 17.10 on Xorg [18:52] but not for screen share [18:58] seb128: yes it's wayland is the issue, but when I flip over to xorg or unity on login, I still am only able to screen share on Chrome not on FF [18:58] so debugging with the zoom folks [18:58] k [18:59] could be a firefox bug if it's only in that webbrowser [18:59] seb128: they ack over wayland being the issue and know it's an issue. [18:59] czajkowski, right, reason for https://community.ubuntu.com/t/xorg-will-be-the-default-in-18-04-lts/3623 as well or at least one [19:00] seb128: ah so maybe if I upgrade... [19:00] seb128: thanks for the link [19:00] we only just switched from GoTo meeting where it just worked [19:00] czajkowski, no need to upgrade to change the session, you can pick "Ubuntu on xorg" [19:00] it's just the default that changed [19:02] seb128: seems to really muck about with my display when I change things about, it could just be this laptop. plus nice to have things just working. Will point the zoom folks at the link you pasted, thank you though [19:02] yw! [19:30] hey robert_ancell! === ayan is now known as Guest19170 [19:58] robert_ancell, even after reboot gnome-software isn't showing anything :/ [20:15] tjaalton: ack, thanks [20:33] night all