[01:11] <kenvandine> Trevinho, i can
[01:12] <kenvandine> Trevinho, so you're going to fix that issue separately?
[01:36] <tsimonq2> Can I please get a review on this from the Desktop Team? https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1699216
[01:36] <ubot5`> Ubuntu bug 1699216 in gnome-initial-setup (Ubuntu) "Encrypted home support" [Wishlist,Confirmed]
[02:04] <duflu> Hmm, I've lost my Wayland login options
[02:05] <duflu> I think that usually means gdm is configured to use Xorg
[02:37] <RAOF> How does one configure that?
[02:51] <gQuigs> duflu: doing a fresh install to confirm https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1715527 ?
[02:51] <ubot5`> Ubuntu bug 1715527 in ubiquity (Ubuntu) "The installation option to install third-party software doesn't install any third-party software" [Undecided,New]
[02:52] <duflu> gQuigs, thanks. Perhaps my expectations are wrong? I never checked that's what happened before
[02:52] <gQuigs> or just check to see if you got Flash with it - which means it's the old ubuntu-restricted-addons package
[02:52] <gQuigs> duflu: nah, for me it installs those packages
[02:52] <duflu> gQuigs, definitely installed the vaapi stuff when I installed it manually
[02:53] <duflu> gQuigs, I let it install without network access, if that matters
[02:53] <gQuigs> duflu: oh, yea, it can't pull those without network access
[02:53] <gQuigs> none are on the image
[02:54] <duflu> gQuigs, oh great. Another reason for bug 694328
[02:54] <ubot5`> bug 694328 in ubiquity (Ubuntu) "Third-party software option is confusing and misleading" [Medium,Confirmed] https://launchpad.net/bugs/694328
[02:55] <gQuigs> duflu: I was looking at how odd it is phrased while looking to remove Flash
[02:55]  * duflu reinstalls again
[02:56] <duflu> Well we only have ourselves to blame. We've had years to change those sentences :)
[02:57] <gQuigs> well, mp3 suppport hopefully will be native in 18.04, so that seems like the best time to redo it..
[02:59] <duflu> Still in a state where it's easier and more reliable to direct people to the wiki page than to use the checkbox
[03:00] <duflu> (my goal is to declare out of box support is now working)
[03:08] <gQuigs> duflu: then get vaapi in main :), otherwise either way it's not true oob
[03:09] <gQuigs> the checkbox works for a lot ofpeople fine
[03:09] <duflu> gQuigs, yeah I understand. I'll adjust expecations...
[03:10] <gQuigs> duflu: IIRC it is technically possible to have the packages on the ISO but not installed by default so they can be installed offline
[03:11] <gQuigs> but that's usually reserved for wifi drivers, etc IIRC
[03:11] <gQuigs> likely easier to try to drop the small gstreamer-bad dependency and get it in main
[03:14] <duflu> gQuigs, yes I was confused because I knew broadcom wifi was one such exception where it existed in the ISO but only gets installed if you choose thirdparty software
[03:15] <gQuigs> indeed, I was looking at the code and I think the checkbox both installs the restricted package - and might turn on some settings to let drivers like that work
[03:17] <duflu> Verified with a re-re-install, everything is OK
[03:17] <duflu> OK enough :)
[03:17] <gQuigs> :)
[03:21] <duflu> gQuigs, that's actually good. It means I still need to give the same post-install instructions regardless of what boxes were ticked during install.
[03:23] <gQuigs> duflu: shouldn't it just work if they clicked the box and were on the internet?
[03:24] <duflu> gQuigs, yes it does, _if_ you connected to the internet/wifi on the previous screen. If not then the tickbox is silently ignored
[03:24] <duflu> Even after subsequent updates
[03:26] <gQuigs> hmm.. I wonder if it should be grayed out like install latest updates..
[03:30] <duflu> gQuigs, yes for most of the packages, and no for wifi because those are in the iso
[03:31] <gQuigs> right,duh.. hmm that doesn't work :/
[03:33] <duflu> I'm trying not to get distracted by mentally redesigning the GUI right now :)
[03:34] <gQuigs> right
=== micahg_ is now known as micahg
[04:23] <ijash> where is the most crowded irc channel for ubuntu user with the quickest response?
=== Guest16793 is now known as fredp
=== fredp is now known as Guest12174
[05:41] <didrocks> good morning
[07:10] <seb128> good morning desktopers
[07:24] <didrocks> re seb128
[07:36] <duflu> Hi didrocks, seb128
[07:37] <didrocks> hey duflu, how are you?
[07:38] <duflu> didrocks, alright. You?
[07:39] <didrocks> I'm good, thanks!
[07:45] <duflu> didrocks, did you see this? :) https://git.gnome.org/browse/mutter/tree/cogl/cogl/cogl-xlib-renderer.c#n306
[07:47] <duflu> ie. pointless switch statement and explanation of why things look nice on X
[07:47] <duflu> Possibly
[07:52] <didrocks> duflu: oh, that would make sense…
[07:53] <duflu> didrocks, yeah I knew at a kernel level I should get "unknown" so HRGB was being inserted by X
[07:53] <duflu> -by +for
[07:55] <didrocks> do you think we should do the same hack?
[07:55] <duflu> didrocks, no I think we should fix it upstream. But do a hack where unknown = HRGB
[07:56] <duflu> Unless there's a handy gsettings that the shell can pick from
[07:57] <duflu> It's possible but unlikely one will encounter a non-HRGB display that also returns "unknown"
[07:57] <didrocks> duflu: yeah, that makes sense
[07:58] <duflu> I think Windows does the same from memory. But I think in Windows you can also configure it
[08:00] <didrocks> I don't see anything to configure it in mutter or the shell code after some quick greps
[08:01] <willcooke> morning all
[08:01] <duflu> didrocks, probably not. Only in apps
[08:01] <duflu> Morning willcooke
[08:01] <didrocks> morning willcooke
[08:02] <duflu> didrocks, apps I think use:
[08:02] <duflu> org.gnome.settings-daemon.plugins.xsettings rgba-order 'rgb'
[08:02] <duflu> org.gnome.settings-daemon.plugins.xsettings antialiasing 'rgba'
[08:02] <duflu> The "x" is just historical obviously
[08:03] <Laney> ahihiruahuireh
[08:03] <Laney> just stepped on an upturned plug
[08:03] <Laney> hi...
[08:04] <didrocks> duflu: yeah, unsure the plugin is doing anything in wayland, didn't check, but anyway, that would be only limited for apps as the Shell has very few interactions with g-s-d
[08:04] <didrocks> hey hey Laney
[08:05] <didrocks> urgh Laney, feeling awake at least, I guess?
[08:05] <duflu> Hi Laney
[08:08] <Laney> didrocks: whether I wanted to or not
[08:08] <Laney> hi didrocks hi duflu
[08:10] <duflu> didrocks, if you did get it from some settings somewhere, it would have to be _before_ those rotation transformations seen in the above git code
[08:10] <duflu> ideally
[08:32] <Tribaal> good morning everyone
[08:32] <Tribaal> I still cannot login to my gnome3 session, however I don't get a segfault in libmutter anymore ! \o/
[08:33] <Tribaal> a new user profile logs in perfectly well, so:
[08:33] <Tribaal> what should I nuke to emulate a new user profile? :)
[08:40] <didrocks> Tribaal: some people reported issues on multimonitor configuration
[08:40] <didrocks> so maybe logout and remove ~/.config/monitors.xml before logging back in again?
[08:40] <Tribaal> ah
[08:40]  * Tribaal tries
[08:43] <Tribaal> didrocks: it worked! \o/ ~/.config/monitors.xml was the problem
[08:43] <Tribaal> didrocks: thanks a lot!
[08:44] <didrocks> yw ;)
[09:11] <colinl> Hi everybody!
[09:11] <colinl> I'm dropping by in hope of drawing a bit of maintainer attention on a problem I face with 16.04 LTS.
[09:11] <colinl> At work I'm the sysadmin for about 50 users. Their workflow heavily involves web-based back-offices and network shares.
[09:11] <colinl> When we upgraded from 14.04 to 16.04, they got a bit annoyed because Firefox's file chooser stopped displaying the network shares in the location bar.
[09:11] <colinl> This is filed against Firefox here: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1579543
[09:11] <ubot5`> Ubuntu bug 1579543 in Mozilla Firefox "Firefox 46 is missing network shares in file selector" [Medium,In progress]
[09:11] <colinl> We worked around the problem by switching the company-approved browser to Chromium.
[09:11] <colinl> But in the last weeks, Chromium got upgraded from 58 to 60 and... the network shares disappeared from its filechooser too.
[09:11] <colinl> Because the Chromium build switched to GTK+3 from GTK+2
[09:11] <colinl> This forces my users to "buffer" files from/to network shares locally before being able to upload/save from their browser.
[09:12] <colinl> A workaround exists: I can symlink /run/user/{ID}/gvfs/* to a directory like ~/NETSHARES/; but it scales really bad.
[09:12] <colinl> I investigated the bug and found out that in was, in reality, a regression in GTK+3.
[09:12] <colinl> Their documentation for gtk_file_chooser_set_local_only() (which is the default, and used by most applications that use the filechooser with POSIX paths) still states that "On some systems non-native files may still be available using the native filesystem via a userspace filesystem (FUSE)"
[09:12] <colinl> But this isn't implemented.
[09:12] <colinl> I have submitted a patch to the GTK+ upstream team at https://bugzilla.gnome.org/show_bug.cgi?id=787128
[09:12] <ubot5`> Gnome bug 787128 in Widget: GtkFileChooser "Re-add FUSE network mounts in local-only mode" [Normal,New]
[09:12] <colinl> and reported the regression on Launchpad too: https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1714518
[09:12] <ubot5`> Ubuntu bug 1714518 in gtk+3.0 (Ubuntu) "GTK+3 doesn't show FUSE network shares in file chooser" [Undecided,Confirmed]
[09:12] <colinl> I (and my users) would really love to see this regression fixed in 16.04 LTS.
[09:12] <colinl> Can someone help ?
[09:21] <duflu> colinl, it's hard to predict if/when upstream Gnome will step in. However Ubuntu is able to pre-empt them and fix it early. You just need to ensure the fix exists in the current dev release first (17.10) and then follow the rest of the steps to get in into 16.04: https://wiki.ubuntu.com/StableReleaseUpdates
[09:22] <duflu> I know features gone AWOL was a common thing in the jump from Gnome/GTK 2 to 3
[09:24] <colinl> Thanks for the help duflu
[09:24] <colinl> so I should adapt & submit my patch to 17.10's version of GTK+ :)
[09:24] <colinl> I'm going to do that
[09:25] <duflu> colinl, yes as a first step. Some sponsors will also ask you to do 17.04 too, but realistically that will be EOL early next year so it's debatable whether to do 17.04
[09:25] <colinl> (I just made a sweep on Launchpad and marked the reports I found about this functionality breaking as duplicates to the root cause)
[09:26] <duflu> colinl, thanks, yes de-duplicating is helpful
[09:26] <colinl> No problem, I think I can do both. The code didn't change much and my patch applies with various fuzz to GTK+3.14, GTK+3.18 and their git master
[09:27] <colinl> Yeah, also these bugreports were filed against the wrong culprit :)
[09:30] <colinl> duflu: is a single patch preferred or a debdiff ?
[09:30] <jamesh> Interestingly it looks like GTK 4 defaults to local_only=false
[09:31] <colinl> I submitted both to my BR but am unsure I'll be able to build the more recent versions without installing a full 17.10 Ubuntu somewhere
[09:32] <jamesh> https://git.gnome.org/browse/gtk+/commit/?id=5b3b11126037f0c5468afcc6da856060ca36184e
[09:33] <jamesh> (that doesn't help much for Ubuntu 16.04 though)
[09:33] <colinl> nor for apps relying on FUSE mounts to access shares using POSIX APIs
[09:35] <duflu> colinl, yep; reformat the bug description, attach a debdiff for 17.10, and then subscribe ubuntu-sponsors to the bug
[09:36] <colinl> thanks. How should I reformat the description ? :)
[09:36] <duflu> Actually for 17.10 you don't even need the SRU description
[09:36] <duflu> colinl, per the wiki page
[09:36] <colinl> indeed. Thanks!
[09:36] <duflu> colinl, so first step is just debdiff for 17.10 and then subscribe ubuntu-sponsors
[09:36] <colinl> 17.10 is Artful, isn't it ?
[09:36] <duflu> Yes
[09:37] <colinl> Thanks :)
[09:37] <colinl> your help's very appreciated :)
[09:39] <duflu> Not a problem
=== JanC is now known as Guest49554
=== JanC_ is now known as JanC
[09:51] <colinl> hehe I got to install a 17.10 to satisfy build dependencies. :)
[10:16] <flexiondotorg> seb128 didrocks jibel Bonjour la France! Je suis à Paris aujourd'hui.
[10:17] <jibel> Bonjour flexiondotorg et bienvenue à Paris!
[10:23] <seb128> salut flexiondotorg
[10:24] <flexiondotorg> Le temps est délicieux, mais la bière est bonne.
[10:24] <popey> Bonjour!
[10:25] <flexiondotorg> popey: It that the best you can do?
[10:25] <popey> I only did GCSE french, sorry john
[10:25] <popey> (and that was a hundred years ago)
[10:25] <popey> Are we really going to do this "talking on irc" while sat at the same table?
[10:26] <flexiondotorg> Il y a de l'argent dans l'arbre!
[10:36] <didrocks> flexiondotorg: enjoy it :)
[10:43] <sunweaver> flexiondotorg: there are agents in the woods? Go and hide, then...
[11:24] <casey> On a similar note to colinl's comment, GtkPlacesSidebar does not show the desktop folder in the default Wayland session. By default, GtkPlacesSidebar appears to query some  property of the desktop environment ("gtk-shell-shows-desktop") to determine whether to display the desktop folder.
[11:25] <casey> The Ubuntu Xorg session shows the desktop folder as expected; however, since Wayland has no support for desktop icons, that property is probably False in the default Ubuntu session
[11:26] <casey> However, since artful enables desktop icons by default, it may make sense to patch the gtk_places_sidebar_init function to enable the desktop manually
[11:28] <casey> or at least query whether "show desktop icons" is enabled in tweak tool
[11:30] <casey> or rather, in GtkSettings
[11:31] <casey> GSettings
[11:47] <jamesh> casey: looking at the GTK source, that one is actually managed by a Wayland protocol extension: https://git.gnome.org/browse/gtk+/tree/gdk/wayland/protocol/gtk-shell.xml?h=gtk-3-22
[11:48] <jamesh> so the question would be how gnome-shell handles it
[11:53] <jamesh> and looking at the mutter source, it only sends the global_app_menu capability
[11:55] <jamesh> hah.  capabilities is treated as a flag set, but the values defined for the three flags are 1, 2, and 3
=== alan_g is now known as alan_g|lunch
[12:27] <jamesh> casey: just filed that upstream in case you want to follow it: https://bugzilla.gnome.org/show_bug.cgi?id=787407
[12:27] <ubot5`> Gnome bug 787407 in Backend: Wayland "wayland: gtk_shell1 capability enumeration badly numbered" [Normal,New]
[12:29] <casey> jamesh: thanks! looking forward to the updates.
[12:30] <jamesh> casey: as I said earlier, I don't know how quickly it will be fixed: there doesn't seem to be any code in gnome-shell/mutter to send the desktop_icons capability
[12:31] <jamesh> so it is kind of academic that the enum is borked
[12:31] <casey> jamesh: that's not too surprising since upstream GTK developers seem to regard desktop icons as a "legacy" or "classic" feature
[12:32] <casey> desktop icons were restored only by forcing nautilus to run in XWayland
[12:32] <casey> so they're really a hack at this point
[12:33] <casey> (e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1280195)
[12:33] <ubot5`> bugzilla.redhat.com bug 1280195 in nautilus "If running "gnome on wayland" desktop session, nautilus won't show the desktop icons" [High,Closed: upstream]
[12:37] <casey> would it be feasible to maintain an Ubuntu patch to manually enable desktop icons in GtkPlacesSidebar?
[12:42] <jamesh> I wouldn't want to change the Wayland protocol without agreement from upstream.  It might be possible to just have GTK unconditionally set gtk-shell-shows-desktop on Wayland, but that would also change the behaviour if someone is trying to get a "vanilla GNOME"
[12:59] <kenvandine> Trevinho, did you see i approved your better-destructive-action branch last night?
[12:59] <kenvandine> Trevinho, don't forget to fix the issue didrocks pointed out in a new branch :)
=== alan_g|lunch is now known as alan_g
[13:12] <colinl> damn. I fail to build gtk+3 on Artful
[13:12] <colinl> make check-recursive fails on a test
[13:12] <colinl> ERROR:/home/colin/gtk+3.0-3.22.19/./testsuite/gtk/treeview.c:234:test_row_separator_height: assertion failed (rect.height == height): (15 == 2)
[13:13] <colinl> could it be due to some other package having changed since the last build of the package?
[13:25] <tseliot> Laney: hey, I have updated my patch following your suggestions, except for the static variable. Are we going to include it in 17.10? https://bugzilla.gnome.org/show_bug.cgi?id=784470
[13:25] <ubot5`> Gnome bug 784470 in general "X11 sessions fail to start when KMS is enabled in the nvidia driver" [Normal,Needinfo]
[14:28] <Laney> tseliot: it's uploaded, just blocked in proposed for some annoying reason
[14:29] <Laney> thx for following up
[14:31] <kenvandine> sigh... my gnome-logs snap works fine on 16.04 but not on 17.10, i guess the journal API in libsystemd0 has changed :/
[14:43] <tseliot> Laney: thanks! Shall I create a different merge proposal with the new patch?
[14:45] <Laney> tseliot: if you like, or maybe it's better to keep the current one and just get the final version via upstream
[14:45] <Laney> up to you
[14:48] <tseliot> Laney: ok, I'll ping again upstream soon, then I'll decide what to do. Thanks
[15:06] <didrocks> stupid question, but where is the internet connectivity enable/disable toggle?
[15:06] <didrocks> we received https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1715662 and I wanted to check with the new g-c-c (if it was there) + our theme fixes
[15:06] <ubot5`> Ubuntu bug 1715662 in gnome-control-center (Ubuntu) "Network Connectivity Checking does not turn gray when toggle is set to Off" [Undecided,New]
[15:07] <willcooke> didrocks, privacy
[15:07] <didrocks> that's where I looked first
[15:07] <didrocks> and not in 3.26 at least
[15:07] <didrocks> jbicha: did you drop that patch? ^
[15:08]  * didrocks reinstalls old g-c-c
[15:08] <didrocks> it can be as well upstream new privacy panel vs our one, which is external?
[15:09] <Laney> it's the upstream privacy panel
[15:09] <jbicha> didrocks: it works here fine with g-c-c from gnome3-staging ppa but maybe you're using a different version of g-c-c?
[15:09] <jbicha> verify that network-manager-config-connectivity-ubuntu is installed
[15:09] <didrocks> ah
[15:09] <didrocks> that might be it
[15:09] <didrocks> because I only have 4 options in privacy
[15:10] <jbicha> but yes, I experience 1715662, I mentioned it to jamesh as I was packaging his patches
[15:10] <didrocks> mind confirming thebug?
[15:11] <didrocks> I don't have the option in the privacy panel, do I need to reboot after intalling network-manager-config-connectivity-ubuntu?
[15:11] <didrocks> or I guess restarting n-m
[15:11] <jbicha> yes, restarting NM will work
[15:12] <didrocks> ah, better :)
[15:12] <jbicha> check if you still have ubuntu-desktop installed too since that pkg should have been installed automatically
[15:12] <jbicha> it's only a recommends (although I asked if it could be a depends)
[15:12] <didrocks> I guess recommends isfine
[15:12] <jbicha> not when you don't have it installed! :)
[15:13] <didrocks> and yes, I did an experiment a couple of weeks ago leading u-d to be uninstalled
[15:13] <didrocks> all good then!
[15:13]  * didrocks tried in new g-c-c now
[15:14] <didrocks> all good and rolling!
[15:14] <didrocks> and yes, the bug is still there :p
[15:16] <didrocks> thanks willcooke, jbicha!
[15:16] <willcooke> yw!
[15:52] <kenvandine> Laney, any opinions on a backport of systemd for xenial in the gnome-3-24 PPA?  I need a newer libsystemd for the gnome-logs snap
[15:52] <Laney> O_O
[15:52] <kenvandine> Laney, built with the backported libsystemd gnome-logs works fine on xenial and artful :)
[15:52] <kenvandine> and since it's in a snap, it should be safe :)
[15:52] <Laney> what happens if you run new libsystemd on old systemd?
[15:52] <kenvandine> works fine in my snap
[15:53] <kenvandine> at least the journal works, which is all i need for gnome-logs
[15:53] <kenvandine> the old libsystemd on the new systemd does not work though :)
[15:54] <kenvandine> so it looks like the lib is backwards compatible at least as far as what we have in 16.04
[15:54] <Laney> that's weird though
[15:54] <Laney> it means that if you built something back then it would have broken at some point?
[15:54] <kenvandine> the soname of the lib hasn't changed
[15:55] <kenvandine> but i guess systemd has had a change
[15:55] <kenvandine> at least to the journal api
[15:56] <Laney> that might be a bug
[15:56] <jbicha> maybe recent gnome-logs is just using newer features?
[15:56] <kenvandine> and i guess that'll always work since systemd depends on libsystemd binary:Version
[15:56] <kenvandine> that could be too
[15:56] <kenvandine> jbicha, you are probably right, must use newer API?
[15:56] <Laney> well, it's probable not everything is exposed in the C API
[15:57] <jbicha> I'm just guessing though
[15:57] <Laney> so gnome-logs probably has an insufficient dependency
[15:57] <Laney> if that's true
[15:57] <jbicha> yes
[15:57] <kenvandine> i think since the backports PPA is just intended for snaps, it should be safe to include that backport
[15:57] <kenvandine> it's not like the system's systemd will get replaced
[15:58] <Laney> it's that the programs might try to do something to it which won't work
[15:58] <Laney> I'd ask xnox :P
[16:00] <kenvandine> xnox, ^^ thoughts on including a backport of libsystemd0 for xenial in the gnome-3-24 backports PPA which we use for building gnome 3.24 snaps?
[16:00] <kenvandine> xnox, users shouldn't be installing debs from that PPA
[16:00] <kenvandine> we just need a newer libsystemd0 than xenial has
[16:01] <kenvandine> xnox, and the newer libsystemd0 in a snap works fine on a 16.04 desktop
[16:01] <xnox> kenvandine, this sounds scary.
[16:01] <Laney> it's things like: systemd from artful exposes a new D-Bus API from pid 1
[16:01] <Laney> libsystemd0 from artful wraps that
[16:02] <Laney> you call that on 16.04
[16:02] <Laney> ???????????????
[16:02] <xnox> kenvandine, what exacatly do you need? and maybe we can just cherry-pick that?
[16:02] <kenvandine> xnox, that was my first thought
[16:02] <kenvandine> gnome-logs snap
[16:02] <kenvandine> it uses the journal API
[16:02] <xnox> libsystemd0 is fairly stable.
[16:02] <kenvandine> maybe uses api that has been added since the version in 16.04
[16:02] <kenvandine> the systemd binary is not included in the snap
[16:02] <kenvandine> just libsystemd0
[16:03] <kenvandine> and it works for the journal on a 16.04 host
[16:03] <kenvandine> as well as on an artful host
[16:11] <kenvandine> xnox, libsystemd0 229 doesn't work and 232 does.  I can try to see what commits in there might introduce something gnome-logs needs and cherry pick just that
[16:13] <xnox> kenvandine, i can look into gnome-logs code too. you say snap? but i can just pull artful package too right?
[16:13] <kenvandine> xnox, yup
=== JanC_ is now known as JanC
[16:20] <Laney> :3
[16:54] <willcooke> Anyone seeing odd suspend/resume behavour when open/closing the laptop lid?
[16:54] <Laney> seb128 was complaining about something
[16:54] <Laney> I didn't see any problems myself
[17:07] <Laney> however I am about to suspend after a dist-upgrade / reboot
[17:07] <Laney> maybe the laptop will explode
[17:07] <Laney> night!
[17:09] <kenvandine> boom
[17:14] <willcooke> heh
[17:47] <willcooke> night all
[18:01] <Beret> how's the hidpi fixes going, anyone know?
[18:06] <xnox> kenvandine, note that there was library consolidation. whilst on 232 one may only need to link in libsystemd0 on 229 one may need to link both libsystemd0 and libsystemd-journal0
[18:08] <kenvandine> i think i've traced this down to iterating the journal for boot ids
[18:08] <xnox> oooh, sounds interesting
[18:09] <kenvandine> in gl_journal_get_boots it has a break if sd_journal_previous was 0
[18:10] <kenvandine> so if it successfully moves to the previous, it breaks out of the loop and never appends the boot id to an array
[18:10] <kenvandine> not sure why that would behave differently in 229 vs 232
[18:13] <xnox> 232, not 234?
[18:13]  * xnox sees some fixes in 234
[18:14] <kenvandine> yeah, 232
[18:14] <kenvandine> i built 232 from zesty for xenial
[18:14] <kenvandine> 234 bumped debhelper to 10
[18:14] <kenvandine> so it was easier to toss up a rebuild from zesty's package :)
[18:15] <kenvandine> xnox, actually, the host is running 234 though
[18:15] <xnox> sure.
[18:15] <kenvandine> so libsystemd0 from 229 fails when talking to systemd 234
[18:15] <kenvandine> but 232 doesn't fail to talk to 234
[18:16] <xnox> the thing about sd-journal.h stuff is that it is actually journald code, thus any backports to fix those api calls, will mean backporting and fixes for journald and/or changing journald behaviour
[18:16] <xnox> diffing sd-journal.c alone doesn't show anything of great interest =/
[18:16] <kenvandine> yeah, i did that too :/
[18:16] <xnox> oh oh oh
[18:16] <xnox> we compile v232+ journals with more features, hence older stuff should not be able to open it.
[18:17] <kenvandine> ah
[18:17] <xnox> however, i guess format issues is not the problem here.
[18:17] <kenvandine> that might do it
[18:17] <xnox> not sure, but would be interesting theory to test.
[18:17] <xnox> i think seb128 complaint about it too.
[18:18] <xnox> in essence e.g. journalctl --file system.journal -> will fail if e.g. journalctl is from xenial, and system.journal is from artful.
[18:18] <xnox> kenvandine, can you open a new bug against systemd, subscribe me, and i will investigate if this is the same thing, or not.
[18:18] <xnox> kenvandine, also you can build your snaps with 17.04 targetting core 16.04
[18:18] <xnox> in ppa, i beleive, have you tried that?
[18:19] <kenvandine> i don't think we want to do that?
[18:19] <kenvandine> we have a backport ppa for gnome-3-24 built for 16.04
[18:19] <kenvandine> that we use to build 3.24 snaps from
[18:20] <kenvandine> building with 17.04 would probably cause issues
[18:26] <kenvandine> xnox, bug 1715719
[18:26] <ubot5`> bug 1715719 in systemd (Ubuntu) "systemd v232+ journals aren't compatible with journalctrl from 229" [Undecided,New] https://launchpad.net/bugs/1715719
[18:41] <kenvandine> xnox, thx!
[18:47] <kenvandine> sigh... gnome-software is sucking my laptop dry again
[19:21] <xnox> kenvandine, nah... that's not the bug  i wanted.
[19:21] <xnox> kenvandine, i wanted a bug / description of what is failing for you in gnome-logs and how to reproduce it.
[19:21] <kenvandine> :)
[19:21] <kenvandine> i'll update it
[19:21] <kenvandine> although i think the summary is basically accurate
[19:22] <kenvandine> xnox, would it be helpful to attach a snap that doesn't work on an artful host?
[19:22] <xnox> kenvandine, i'm still confused why you use a backport ppa to build things from zesty on xenila to be run with artful.
[19:22] <kenvandine> the snaps run on ubuntu core 16
[19:22] <kenvandine> so the same snap runs on 16.10, 17.04 and 17.10
[19:23] <kenvandine> the PPA is really just xenial builds of gnome libs from 3.24
[19:23] <kenvandine> it's not generally anything to do with zesty
[19:24] <kenvandine> i just chose to rebuild the source from zesty instead of artful because of the debhelper build dep
[19:24] <kenvandine> i could just build the zesty source in a xenial chroot without changes
[19:28] <xnox> kenvandine, it feels strange that the snap cannot link and use libsystemd0 from the host, rather than the one in the core or in the snap.
[19:29] <kenvandine> xnox, snapd is designed to prevent that
[19:29] <kenvandine> all it's depends need to be in the snap
[19:32] <kenvandine> xnox, updated the description, perhaps that helps
[19:33] <xnox> kenvandine, i guess doing lp:ubuntu-archive-tools/copy-package of src:systemd with binaries from ubuntu archive zesty into your ppa, and staging just libsystemd0 into your snap maybe the faster solution fo ryou.
[19:33] <kenvandine> xnox, well we need to pull the dep from the PPA for the automated builds
[19:33] <kenvandine> the snaps we upload to the store are built on LP
[19:34] <xnox> launchpad automated snap builds can be done with ppa sources....
[19:34] <kenvandine> xnox, yes
[19:34] <kenvandine> xnox, the PPA is only meant to be used for snaps, so the actual systemd binary shouldn't ever end up on a host from that PPA
[19:34] <kenvandine> we use the PPA to pull depends, which is just pulling in the lib
[19:35] <xnox> such that when you do build of xenial, to 16.04 LTS with PPA it can pull and stage the libsystemd0 which you published in your ppa for the xenial suite; even thought that was a binary copy form Ubuntu Archive zesty release
[19:35] <xnox> you should be able in your snapcraft.yaml to just stage the /lib/<tripplet>/libsystemd0.so.* stuff cause you don't want your snaps to be fatter than they really need to be.
[19:36] <kenvandine> xnox, yeah, that's basically what i would do but I had planned to copy the source and let it rebuild
[19:36] <kenvandine> xnox, yes
[19:36] <kenvandine> my snap is only 7M :)
[19:37] <xnox> you don't have to rebuild, binary copy saves you backport work.
[19:37] <xnox> but ideally xenial's libsystemd0 would just work for gnome-logs case.
[19:37] <kenvandine> xnox, that would be better, yes
[19:38] <xnox> also confused why it's a binary interface rather than a dbus interface =/
[19:38] <kenvandine> i used dbus-monitor, didn't see any dbus traffic
[19:39] <xnox> yeah, annoying.
[19:50] <mark__> Greetings, I have been testing 17.10 and Ubuntu Dock is broken on my Ubuntu session.   I also can't open the Dock settings under displays.  It just closes the settings window when I click on Displays.  Any ideas on how I can correct this?
[21:46] <jdstrand> kenvandine: fyi, https://forum.snapcraft.io/t/the-desktop-interfaces/2042
[22:03] <jdstrand> kenvandine: and hi!
[22:03] <jdstrand> kenvandine: also, https://github.com/ubuntu/snapcraft-desktop-helpers/pull/73 (updates for new interfaces)
[22:49] <Beret> so
[22:49] <Beret> somehow in a recent update my artful machine has managed to revert to X rather than wayland
[22:49] <Beret> even if I choose the default (non X) when logging in
[22:49] <Beret> is that a known issue?
=== Guest12174 is now known as fredp
=== fredp is now known as Guest2791