[04:50] <didrocks> good morning
[04:52] <duflu> Morning didrocks
[04:52] <duflu> Huh? The only working call to vaCreateSurfaces is the one where we pass the parameters in the wrong order (!?)... where working means status=0 but still corruption
[04:54] <duflu> Oh... macro magic to rearrange parameters
[04:59] <didrocks> hey duflu, good Monday? Sounds some wayland fights ;)
[05:00] <duflu> didrocks, It is Monday at least. Yes, Wayland :)
[05:00] <didrocks> heh :)
[05:35] <duflu> \o/ Hardware decoding under Wayland to Clutter!
[05:35] <duflu> (with many hacks that now need eliminating)
[06:40] <duflu> didrocks, Yes it is now a good Monday :)
[06:40] <duflu> How are you?
[06:41] <didrocks> duflu: I'm good, thanks! What happened so that it became a good Monday? :p
[06:41] <duflu> didrocks, I finally got hardware video decoding on Wayland fixed. Only took a week
[06:42] <didrocks> oh, that will be a great enhancement :)
[07:00] <andyrock> good morning!
[07:01] <didrocks> hey andyrock, good week-end?
[07:01] <duflu> Morning andyrock
[07:01] <andyrock> hey didrocks
[07:01] <andyrock> hey duflu
[07:01] <andyrock> good enough
[07:01] <andyrock> spend the we in Bologna with my brother
[07:02] <didrocks> sounds great ;)
[07:07] <seb128> good morning desktopers!
[07:09] <seb128> hey andyrock duflu, re didrocks
[07:09] <duflu> Hi seb128
[07:09] <andyrock> hey seb128
[07:09] <didrocks> re seb128
[08:03] <Laney> what's up
[08:04] <willcooke> morning all!
[08:04] <willcooke> Doing a pretty good impression of winter here today
[08:08] <seb128> hey Laney, willcooke, how is u.k today?
[08:09] <seb128> more automn like here
[08:11] <Laney> hey seb128
[08:11] <Laney> yeah quite grey, wet and windy
[08:12] <flexiondotorg> Morning seb128 Laney willcooke andyrock duflu
[08:12] <duflu> Hi flexiondotorg
[08:13] <seb128> hey flexiondotorg
[08:16] <alexarnaud> good morning all :) !
[08:17] <seb128> hey alexarnaud
[08:17] <alexarnaud> seb128: how are you today?
[08:19] <seb128> good! you?
[09:21] <alexarnaud> seb128: good :)
[10:41] <infinity> seb128: Who do I complain to that since rebooting from unity to gnome-shell, I can no longer disable my touchpad?
[10:42] <didrocks> infinity: could be the -synaptics vs libinput transition?
[10:42] <infinity> I don't think my driver changed.
[10:42] <infinity> But the mouse/keyboard options sure did.
[10:42] <seb128> infinity, uninstall synaptic if it's installed
[10:42] <didrocks> bug #1686081
[10:43] <infinity> Hrm.  Will try and report back.
[10:43] <seb128> seems didrocks is on the case, /me goes back to what he was doing
[10:47] <infinity> didrocks: You win.  How very unintuitive.
[10:47] <infinity> didrocks: But thanks for saving me from going insane with accidental palm drags.
[10:48] <didrocks> infinity: let's say "have experience with it" :-)
[10:48] <didrocks> happy that it helped!
[10:49] <willcooke> didrocks, do we have a "proper" solution to that, like can we forcibly remove synaptics or something?
[10:50] <infinity> didrocks: I assume there's still ongoing work to make the default theme less... Fedora?
[10:50] <infinity> (All the blue is rather jarringly unUbuntu)
[10:50] <willcooke> infinity, yeah we do - got a hackfest kinda thing planned for end of August
[10:51] <willcooke> infinity, I made a start. kinda.  http://imgur.com/a/NjUXa
[10:51] <willcooke> few things to fix there ;)
[10:51] <infinity> willcooke: Cool.  I think in the interim, only a few colours need changing to make it at least kinda look right (the +/- bars in the panel, and the default lock screen colour)
[10:51] <didrocks> willcooke: there is a trello card for it: https://trello.com/c/9GI3EFh2/122-bug1686081-if-synaptics-is-installed-gnome-mouse-touchpad-settings-doesnt-work, discussed about it with seb128, not trivial, but really annoying
[10:51] <infinity> willcooke: Oh, and maybe the top bar slightly less absolute black. :P
[10:52] <willcooke> infinity, yeah totally agree.  Thats what I was trying to fix actually.  global search and replace was a bad idea it seems.  who knew?!
[10:52] <infinity> (ie: same background as our gnome-terminal)
[10:52] <willcooke> didrocks, thanks!
[10:52] <didrocks> infinity: I guess we all are in favor of blackless top bar (at least, with our theme :p)
[10:52] <seb128> willcooke, it's the same old "need to port u-c-c to libinput" that oem wants and we are talking about for some cycles
[10:53] <infinity> didrocks: I actually like the default GNOME theme, I just don't want it identical to Fedora.  And we don't use true black anywhere, so that same "purplish almost-black" that we use in the terminal background would be appropriate.
[10:54] <didrocks> infinity: could be, we'll experiment (and maybe provide 2 sessions: gnome upstream one with default themes et our own "ubuntu experience"), that's still to be discussed :)
[10:54] <infinity> And, of course, something orangeish to replace the blue +/- bars.
[10:54] <infinity> I'm going to miss menus in my window titlenbars.
[10:54] <infinity> titlebars, too.
[10:55] <didrocks> (same)
[10:55] <infinity> As horrible hacks go, when it finally worked how I wanted it, it was niceish.
[10:55] <didrocks> what have you changed?
[10:55] <didrocks> just curious, could be useful feedbacks
[10:55] <didrocks> any extensions/anything?
[10:55] <infinity> Basically nothing.  Literally just logged into the fresh session a few hours ago.
[10:56] <infinity> I assume it migrated over some generic settings from unity (ie: it's still got my wallpaper selection), but for the most part, it looks very Fedora.
[10:56] <didrocks> apart from the launcher and some icon renames, nothing is ported, the keys were still the generic one
[10:56] <didrocks> so nothing to port was the net benefit :)
[10:57] <infinity> Right, I didn't mean to imply there was actual migration, just that it's obvious some stuff went unchanged, like who renders the root window (nautilus?)
[10:58] <infinity> Oddly enough, that's sort of comforting.  Even when your whole workflow goes to crap, having the wallpaper consistent feels like not all is lost. :P
[10:58] <didrocks> ahah :)
[10:58] <didrocks> that familiar feeling…
[11:02] <infinity> didrocks: Anyhow, I won't be shy about providing some feedback as I find things that rub me the wrong way.
[11:02] <willcooke> thanks infinity, all feedback gratefully received
[11:02] <infinity> didrocks: First thing I noted (other than the synaptics bug) was that Super-L wasn't bound to lock screen anymore.  That must have been a Unity special.
[11:02] <didrocks> I'm sure you won't be shy ;) and yeah, please feel free :)
[11:03] <willcooke> haha!  Told you so seb128 & Laney ;D  ^
[11:03] <infinity> didrocks: But given that binding also works in Windows, I found it a pleasant analog.
[11:03] <didrocks> yeah, their default is the old ctrl+alt+l?
[11:03] <infinity> *nod*
[11:03] <infinity> I think both worked for me in Unity because I got Super+L from Unity and Ctrl-Alt-L from the gnome keyboard settings.
[11:03] <infinity> On relog, of course, I only had the latter.
[11:04] <infinity> And since they don't seem allow binding two things to one action, I now have the former. :P
[11:04] <didrocks> yeah, I never left Ctrl+Alt+l, the other one was added to compiz as a secondary action
[11:04] <infinity> I use a Windows desktop for gaming, and Super-L is the shortcut there, and I dig consistency.
[11:05] <infinity> But also, it's the binding that makes more sense when Super is "they key to manage overall desktop stuff".
[11:05] <didrocks> willcooke: can you add it to your special list of polish that we can discuss about?
[11:05] <infinity> (Though, I guess maybe GNOME people still live in a pretend world where some people's keyboards were made prior to 1997?)
[11:05] <infinity> Or Happy Hackers.
[11:05] <didrocks> but worskpace changes are still Ctrl+Alt + something
[11:06] <infinity> Yeah.  True.  But also no analog there on other OSes, which may be why I care less. ;)
[11:06] <didrocks> I remeber we had the plan for super + anything on unity, we only did half of it though
[11:06] <didrocks> ;)
[11:06] <willcooke> didrocks, I'll create a trello card to track
[11:06] <didrocks> great ;)
[11:06] <seb128> I think we should have both keybindings to lock working
[11:06] <infinity> ^
[11:06] <infinity> I'd agree with that.
[11:06] <seb128> if we pick one we are going to piss half of the users either way
[11:06] <infinity> Is there a way under the hood to make GNOME take two bindings?
[11:06] <infinity> The UI sure won't let you.
[11:06] <seb128> I don't think so
[11:06] <seb128> which is the issue
[11:06] <infinity> Ick.
[11:07] <seb128> we might need to hack and special case ctrl-alt-L or something
[11:07] <infinity> I guess you could just add a second binding "Alternate Desktop Lock".
[11:07] <willcooke> I think I found an old patch to move the gsetting to an array
[11:07] <infinity> Which calls the same thing.
[11:07] <seb128> or that
[11:07] <seb128> willcooke, right, that's more work/incompatible changes though
[11:07] <didrocks> willcooke: the issue isn't doing it, it's more about exposing it with minimal changes in g-c-c
[11:07] <willcooke> ack
[11:07] <infinity> I mean, I think it would be stellar to allow an array for ANY binding, but a second binding would be a reasonable hack for this one small regression.
[11:08] <infinity> And simple.
[11:08] <didrocks> yeah, but as seb128 told, it means we need to change all gesttings keys from string to list of array
[11:08] <didrocks> and patch every apps which are using them
[11:08] <infinity> Right, that's a mess.
[11:08] <infinity> Hence the other thing.
[11:08] <didrocks> doesn't seem minimal, not going to work in the snap world sharing the same keys from other code
[11:08] <didrocks> yeah
[11:08] <seb128> but yeah, having "lock screen" and "alternative lock screen" lines wouldn't be the end of hte world
[11:08] <didrocks> I guess making that one special is fine as well
[11:08] <seb128> the other way would be to special case one in the shell
[11:09] <seb128> which is what we did in unity it looks like
[11:09] <seb128> and we never got a complain about it
[11:09] <infinity> Special casing one makes it effectively invisible to the user.
[11:09] <infinity> But fair play, since that's how it was before too. :P
[11:09] <seb128> right
[11:09] <seb128> and you could say that the documented one is the one in the settings
[11:09] <infinity> (Though it did show up in the Unity help screen, I think, so only "invisible" fromthe POV of the keyboard bindings screen)
[11:09] <seb128> and the other one is the compat one of people who are too used to the old keybinding
[11:11] <infinity> seb128: I think one of my favourite things about having a Unity7 and Windows7 (now Win10) desktop side-by-side was that all the important bindings were effectively identical.
[11:12] <infinity> Super+Num to pick from the launcher, Super+L to lock, etc.
[11:12] <infinity> I suspect that wasn't an accident.
[11:13] <infinity> Really, the only noticeable difference between them is that one of them can play more video games, and WINDOWS UPDATE IS STILL A FLAMING HEAP OF OH GOD HOW HAVE THEY NOT IMPROVED THIS IN TWENTY YEARS ARGH.
[11:13] <infinity> Otherwise, they're hard to tell apart.
[11:14] <infinity> (Seriously, the next time you're hating on the performance of dpkg and apt, go update a fresh Windows installation and get some perspective)
[11:20] <infinity> Oh nice, Firefox seems to have survived the transition.  It only shows me a menu bar when I press Alt, like the upstream builds do.
[11:21] <infinity> (PS: I took your survery, please don't switch the default browser, kthx)
[11:23] <seb128> infinity, we wouldn't have to deal with builds on weird archs if chromium was our default :p
[11:23] <infinity> I'm pretty sure I've had to fix Chromium on armhf in the past.
[11:24] <seb128> right, armhf is something we need to deal with
[11:25] <seb128> ppc64el or s390x not so much
[11:25] <infinity> If we get no commitment from IBM on those, we'll drop them.
[11:26] <infinity> I don't object to dropping things with zero upstream support, I object to the knee-jerk "it didn't build, so let's not look into it and discuss dropping it".
[11:26] <infinity> Since there have been many times in the past when it was a simple 1-liner.
[11:27] <infinity> Well, s390x is already dropped, so that's a red herring people keep bringing up.
[11:27] <seb128> it's not "it didn't build", it's "firefox is outdated for most of the cycle and our unstable users have a version with security issues"
[11:27] <infinity> But I'll talk to the POWER guys about ppc64el.
[11:27] <seb128> and that has been the case for at least 3 cycles now
[11:28] <seb128> it's not a one time thing
[11:28] <seb128> it has been pretty much a permanent situation since xenial
[11:28] <infinity> It's not a 1-time thing, but it's also different arches each time.
[11:28] <ricotz> jfyi, current failures of firefox 55 https://launchpad.net/%7Emozillateam/+archive/ubuntu/firefox-next/+sourcepub/8091927/+listing-archive-extra
[11:29] <seb128> so arm64 in addition of what artful currently has
[11:29] <infinity> In xenial, it's currently armhf and ppc64el.  In trusty, it's arm64 and ppc64el.  Which is curious.
[11:29] <ricotz> ff 56 for comparsion https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+sourcepub/8099928/+listing-archive-extra
[11:30] <infinity> Given identical upstream codebases, if armhf fails on one series and arm64 on another, it might be our bug, not upstream's.
[11:30] <ricotz> (arm64 is happy there)
[11:31] <ricotz> (some failures are rust related)
[11:31] <seb128> 56 is missing cargo on ppc64el
[11:32] <ricotz> seb128, I know, I hacked some packages myself
[11:32] <ricotz> I think chrisccoulson is onto updating those officially
[11:33] <ricotz> https://bugs.launchpad.net/ubuntu/+source/cargo/+bug/1701556
[11:35] <infinity> didrocks: So, plugins.  Is there anything (you know of) that will restore my ability to see several timezones in my clock applet?
[11:38]  * infinity decides that maybe trying to sleep is smarter than worrying about what timezone he's in.
[11:38] <infinity> Oh, I like the virtual desktop upper bound just being "one more than you're using" instead of a static number.
[11:39] <seb128> infinity, you can add locations from gnome-clocks and they should be listed
[11:39] <seb128> (we currently don't pre-install gnome-clocks though)
[11:39] <jbicha> good morning
[11:39] <seb128> hey jbicha
[11:39] <infinity> seb128: Ahh.  I was going to say "That's not a command I have". :P
[11:41] <infinity> seb128: Hrm.  I have them in gnome-clocks, but that doesn't change the applet drop-down in any meaningful way.
[11:41] <jbicha> I proposed a gjs SRU … which resulted in this email: https://lists.ubuntu.com/archives/ubuntu-release/2017-July/004163.html
[11:42] <infinity> jbicha: Robie's very much a letter of the law guy.  Which isn't the worst thing ever (I'd rather that than the opposite), but yeah, probably means we need more law for him to follow.
[11:43] <infinity> jbicha: FTR, if he'd passed on it, you could have poked me directly.
[11:43] <seb128> infinity, right, it isn't working for me either but jbicha said that was supposed to do that iirc, I didn't have time to debug/have a look yet
[11:44] <jbicha> the current status is that Robie added the GNOME microrelease exception to the SRU wiki page
[11:44] <infinity> GNOME's always had an MRE, literally since we first had SRUs.
[11:44] <infinity> But we may have undocumented it when we went to the new blanket statements.
[11:44] <infinity> Oops.
[11:45] <jbicha> yes, it was removed from the wiki but it's back now
[11:45] <jbicha> so assuming there are no objections, it should be a bit smoother for GNOME SRUs now :)
[11:47] <seb128> infinity, in fact it works today for me, maybe it needed a session restart after installing gnome-clocks or something... it's listed in the popup you get when clicking on the date in the top panel
[11:47] <infinity> seb128: Ahh, lemme log out, I guess.
[11:49] <infinity> seb128: Well, one bug down, one new one discovered.
[11:50] <infinity> seb128: Seems on a fresh boot, Ctrl-Alt-T gives me terminals in a snappy and quick timeframe.  When I log out and back in (WTF?), Ctrl-Alt-T has a delay of some 10-20 seconds.
[11:50] <infinity> seb128: Thought this was a 1-time weirdness last time I did a log out dance, but it just reproduced this time too.
[11:50] <seb128> dunno about this one
[11:51] <infinity> seb128: Have you seen that, or am I special/insane?
[11:51] <infinity> I guess I'm special.
[11:51] <seb128> I didn't see it
[11:52] <infinity> seb128: Must be something long-running between sessions, but I kinda assumed logins would be under a systemd user session and the cgroup blown away on logout (maybe I'm wrong there)
[11:54] <infinity> In fact, all keyboard shortcuts have that massive delay.  Lock screen was the same.
[11:54] <infinity> Weeeeeird.
[11:55] <infinity> I wonder if it's some conflict between the two gsd-keyboard sessions running.  Though, they should both be running on a fresh boot/login too.
[11:55] <jbicha> if there was a cgroup that was killed on logout, maybe we wouldn't have had LP: #1610944
[11:55] <jbicha> upstream has a different workaround as of last week but not in artful yet https://bugzilla.gnome.org/764029
[11:56] <infinity> jbicha: Ahh, hrm.  Well, that is probably related to the bug I'm seeing now.
[11:57] <jbicha> is one of the gsd-keyboard's from gdm3? because that would make sense since gdm3 itself runs a minimal gnome-shell session
[11:57] <infinity> I find it strange that the distro that foisted systemd on us isn't using it correctly.
[11:58] <infinity> jbicha: Yeah, one's gdm, and one's me.  Like I said, I'm sure they're always both running, so that's a red herring.
[11:58] <infinity> jbicha: But clearly, some state is breaking on log out/in.
[11:58] <jbicha> that GOA bug was a release blocker for much of Fedora 26's release cycle
[11:58] <infinity> jbicha: And it's odd breakage, since I'd expect shortcut keys to either work or not work, rather than working after a 15s delay. :P
[12:00] <ogra_> just add a splash screen :P
[12:01] <infinity> A nice modal dialog that says "GNOME has detected you used a keybinding shortcut, we'll process your request and act on it shortly..."
[12:01] <ogra_> :)
[12:02] <infinity> Oh well, for now I'll reboot.  That one will surely drive me batty in short order and I'll file a bug and/or debug it myself.
[12:02] <infinity> But yes, it would almost certainly "just go away" if we used a proper user session.
[12:02] <infinity> Murdering all the things is a simple fix for so many bugs.
[13:03] <jbicha> willcooke: wow https://imgur.com/a/NjUXa is very orange
[13:03] <willcooke> jbicha, ha!  I got a bit carried away
[13:08] <ogra_> we'll just ship sunglasses along with the isos
[13:09] <willcooke> lol
[13:15] <seb128> Laney, https://trello.com/c/9kiXF8rW/134-systemd-user-session-for-gnome-shell ... do we have no systemd user session at all in GNOME atm? how did it start under unity/would it be difficult to do the same for the GNOME session?
[13:15] <seb128> I don't remember the details
[13:16] <Laney> seb128: Exec=/usr/lib/gnome-session/run-systemd-session unity-session.target
[13:17] <seb128> so we "just" need an equivalent target under GNOME I guess?
[13:18] <Laney> dunno
[13:18] <Laney> that would be the first thing to try
[13:18] <Laney> I'm not sure if there would be issues or not
[13:18] <seb128> do we feel like we need that for 17.10?
[13:19] <seb128> I wonder if we have things that got made systemd user jobs that are not going to work anymore without that
[13:19] <Laney> that was all downstream stuff, so I doubt it
[13:22] <seb128> hum, k
[13:22] <seb128> going to keep investigating why file sharing over bluetooth is not working then
[13:22] <seb128> it looked like it could be due to that but maybe not
[13:22] <seb128> thanks Laney
[13:23] <Laney> there could be issues like things not being killed when you log out
[13:24] <seb128> Laney, fedora has http://pkgs.fedoraproject.org/cgit/rpms/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch
[13:25] <seb128> Laney, I don't think logout is the issue there, I think bluez just expect the user session to be there
[13:25] <seb128> I guess we could use the fedora workaround
[13:25]  * seb128 tries that
[13:29] <Laney> seb128: that SystemdService specified unit doesn't exist
[13:30] <Laney> Failed to introspect object / of service org.bluez.obex: Unit dbus-org.bluez.obex.service not found.
[13:31] <Laney> https://paste.ubuntu.com/25162502/
[13:32]  * mancman3 waves @ the good non ms winshit users
[13:36] <seb128> Laney, you are right
[13:37] <Laney> seb128: bluetooth.service has Alias=dbus-org.bluez.service
[13:38] <seb128> Laney, typo you think?
[13:38] <Laney> maybe?
[13:39] <Laney> not sure what it's supposed to be
[13:39] <Laney> but maybe it's a missing alias on obex.service?
[13:40] <Laney> no, that is there
[13:40] <Laney> I think the obex package should enable the unit (or create that symlink)
[13:41] <seb128> hum, ctrl-R at the wrong place
[13:42] <seb128> Laney, I'm a bit confused now, isn't it simply the SystemdService being wrong as your sed-ed earlier?
[13:42] <seb128> or is that not enough?
[13:42] <Laney> seb128: the value it had should work because obex.service has an alias for it
[13:43] <Laney> but it doesn't because the unit isn't enabled by the package
[13:43] <Laney> you can fix it by making a symlink
[13:45] <seb128> Laney, thanks
[13:50] <seb128> ricotz, hey, did you get any reply from meson upstream about the armhf issue?
[13:52] <ricotz> seb128, no, I guess since doko proposed the other arm fixes, he pretty sure knows how to fix the remaining ones
[13:52] <seb128> ricotz, did you ask him about it?
[13:53] <ricotz> seb128, no
[13:53] <seb128> ricotz, could you? ;-)
[13:53] <ricotz> seb128, you are afraid? ;)
[13:54] <seb128> no but you are the one that asked for that version to be synced and you seem to understand the issue
[14:18] <seb128> Laney, sorry but I'm going to bother you again about that systemd thing, the right way to enable it would be to create a symlink to the service in a <service-used-by-default>.wants?
[14:18] <seb128> Laney, is there a standard "service-used-by-default" we use for such cases? I tried to look for examples and failed to find some
[14:19] <seb128> well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764678 has sockets.target.want but it's for a socket unit
[14:19] <seb128> didrocks, ^ or maybe you know?
[14:20] <Laney> seb128: just in /usr/lib/systemd/user/
[14:20] <didrocks> depends, user services or system service?
[14:21] <seb128> didrocks, systemd --user
[14:21] <didrocks> system services should use dh_systemd to enable it, indeed
[14:21] <Laney> it doesn't need to be in wants of anything
[14:21] <didrocks> ah
[14:21] <seb128> how do you call that?
[14:21] <Laney> this is dbus activation
[14:21] <didrocks> I don't know if dh_systemd has the support for it, I would say no
[14:21] <seb128> didrocks, cf the bug I just mentioned
[14:21] <seb128> it doesn't
[14:21] <seb128> that's why I'm asking about the symlink ;-)
[14:21] <ricotz> seb128, regarding meson, basically https://paste.debian.net/plain/977929
[14:22] <didrocks> seb128: symlink is fine, it's basically what dh_systemd does (+ service start/restart) if you are in the systemd case
[14:22] <seb128> ricotz, can you send that upstream? (and maybe a debdiff to Debian or us for packaging)
[14:22] <didrocks> it doesn't use systemctl enable, because of systemd bootstrapping issue
[14:22] <didrocks> (like, when you get to your first release with systemd, but it's not installed yet, so you don't have systemctl, and so on…)
[14:23] <seb128> hum
[14:23] <seb128> I'm getting confused
[14:24] <didrocks> if it's an user service, a symlink to the corresponding .wants to enable it is enough
[14:24] <seb128> Laney, there is a obex.service already in that dir but you said the issue is that it's not enabled and would need a symlink?
[14:24] <Laney> yes
[14:24] <Laney> but not to wants
[14:24] <seb128> to where?
[14:24] <didrocks> ah, I see, Laney says it's dbus activated
[14:24] <seb128> right
[14:24] <Laney> the value specified in alias=
[14:24] <Laney> that's what systemctl --user enable foo would do
[14:24] <Laney> you have to do that manually, that's what didrocks is saying
[14:25] <seb128> why do we need an alias at all here?
[14:25] <seb128> things seems more complicated that they should be
[14:25] <Laney> because the dbus service file is asking for that unit to be started
[14:25] <seb128> why don't we just the dbus service start the right unit?
[14:25] <didrocks> (I'm having the same, probably stupid question than seb)
[14:26] <Laney> they expect the unit to be enabled
[14:26] <Laney> that is a fair expectation
[14:26] <seb128> what unit?
[14:26] <didrocks> there are multiple provider?
[14:26] <didrocks> (hence the alias?)
[14:26] <Laney> don't know
[14:26] <Laney> but it is fair enough for something to rely on a unit being enabled
[14:26] <seb128> I guess I don't understand why we need an alias
[14:26] <seb128> rather than having 1 unit
[14:26] <seb128> and the dbus activation used that 1 unit
[14:26] <seb128> using
[14:27] <Laney> no idea, it wasn't any of us that developed this
[14:27] <Laney> I'm telling you how to make it work with how it is set up now
[14:27] <seb128> k, so you are not suggesting the design is better
[14:27] <didrocks> Laney: where is dbus activation file btw which reference that alias? (just curious)
[14:27] <seb128> just hitting on what to do with what upstream is providing?
[14:27] <Laney> /usr/share/dbus-1/services/org.bluez.obex.service
[14:27] <seb128> Laney, gotcha, sorry for being slow to get it
[14:27] <Laney> I have no idea if that design is optimal or not
[14:27] <seb128> Laney, thanks again!
[14:27] <Laney> presumably there is a reason they did it this way
[14:27] <Laney> np!
[14:27] <didrocks> maybe they want a non version alias where maybe there will be versioned one
[14:27] <ricotz> seb128, https://paste.debian.net/plain/977932
[14:27] <didrocks> or multiple prociders
[14:28] <didrocks> providers*
[14:28] <seb128> jbicha, do you think you could get that patch from Rico in debian ^?
[14:29] <seb128> didrocks, it's a bit difficult to get proper context on bluez bugs, they don't have proper bug tracking&such
[14:29] <didrocks> do you know how this dbus activation is working, as there is no service, it seems as you get the bug it doesn't fallback to Exec=
[14:29] <didrocks> correct?
[14:29] <Laney> that's right
[14:30] <ricotz> seb128, jbicha, note this an attempt
[14:30] <didrocks> ok, so there is no point in keeping the Exec= as soon as you have SystemdService=
[14:30] <didrocks> oh, or maybe dbus is smart enough to say "no systemd running, I'm ignoring SystemdService and only using Exec="
[14:31] <Laney> yep
[14:31] <seb128> didrocks, http://pkgs.fedoraproject.org/cgit/rpms/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch suggests it does
[14:31] <didrocks> interesting, didn't follow those user sessions changes
[14:31] <seb128> (the comment/description)
[14:31] <Laney> it's for if you don't have systemd --user
[14:31] <didrocks> yeah, making sense
[14:31] <Laney> yeah you can see that the old file in that patch was buggy in that case
[14:32] <didrocks> oh ok, so yeah, disabling it unconditionnally ofc is wrong
[14:32] <didrocks> thanks for the quick tech catchup Laney, seb128 ;)
[14:32] <seb128> thanks didrocks Laney ;-)
[14:32] <Laney> #ubuntu-desktop Tech Talks
[14:33] <didrocks> :-)
[14:33] <Laney> /m/me needs a tech talk
[14:33] <Laney> ffs
[14:33] <Laney> and better wifi
[14:34] <didrocks> not a better keyboard? :)
[14:34] <Laney> or mosh or something
[14:34] <didrocks> heh
[14:35] <Laney> trying to work with GMainContext, threads and such
[14:35] <Laney> it's confusing
[14:36] <didrocks> another threading bug your are fighting against?
[14:36] <Laney> same
[14:36] <didrocks> argh, good luck :(
[14:37] <Laney> sendto(3<socket:[2178330]>, "GET /v2/system-info HTTP/1.1\r\nHost: \r\nConnection: keep-alive\r\nUser-Agent: snapd-glib/1.16\r\n\r\n", 93, MSG_NOSIGNAL, NULL, 0) = 93
[14:37] <Laney> poll([{fd=3<socket:[2178330]>, events=POLLIN}, {fd=6<anon_inode:[eventfd]>, events=POLLIN}], 2, -1
[14:37] <Laney> why does that poll block?
[14:37] <Laney> there should be shit coming back from snapd
[14:38] <didrocks> I guess you can't mock easily the daemon-side of the API because there are other exchanges first?
[14:38] <Laney> nah
[14:38] <Laney> I made a minimal version that does the same thing
[14:38] <Laney> works ofc
[14:38] <didrocks> so, snapd doesn't answer?
[14:39] <didrocks> or sounds like it doesn't
[14:39] <jbicha> seb128: the Debian maintainer of meson == meson upstream maintainer
[14:39] <Laney> pretty sure it does
[14:39] <didrocks> hum
[14:39] <Laney> but for some reason I don't get it
[14:39] <seb128> jbicha, but he refuses to get fixes in Debian?
[14:39] <Laney> it's all GSocket and stuff at the application level of course
[14:39]  * Laney shrugs
[14:40] <Laney> back in a min
[14:41] <seb128> jbicha, the issue is that the meson updates are blocked in artful-proposed due to armhf autopkgtest issues, I asked rico if he could ping upstream about it and he came with that patch but I don't think he upstreamed it
[14:41] <jbicha> seb128: I don't think he's really refusing, it's just the patches need to be proposed and maybe pushed a bit
[14:41] <ricotz> seb128, https://github.com/mesonbuild/meson/pull/2110
[14:41] <seb128> ricotz, thanks
[14:41] <seb128> jbicha, seems ricotz did upstream it now, so unping
[14:42] <jbicha> :)
[14:42] <ricotz> as said I haven't/can't confirmed that it actually fixes it
[14:42] <seb128> it's fine
[14:42] <seb128> now that it's upstreamed maybe Jussi looks at it
[14:45] <jbicha> ricotz: if you push it to a PPA, I can run an autopkgtest on it to test the fix
[14:46] <jbicha> because autopkgtests can be run from a PPA but it needs to be run by someone with upload rights
[14:47] <ricotz> jbicha, ok, should appear here https://launchpad.net/~ricotz/+archive/ubuntu/staging/+packages?field.name_filter=&field.status_filter=published&field.series_filter=artful
[14:48] <ricotz> seb128, that reminds me, what happened with poppler?
[14:49] <seb128> ricotz, I said I would wait for libreoffice to migrate to not makie it part of another transition
[14:49] <ricotz> seb128, ok
[14:49] <seb128> ricotz, or libreoffice is having failing autopkgtests now so it's not migrating (maybe it's also blocked by other things)
[14:50] <jbicha> should we ignore the LO autopkgtests on i386 too (and maybe s390x?)?
[14:50] <ricotz> jbicha, interesting so it would be possible to autopkgtests on libreoffice of ppa:libreoffice/libreoffice-prereleases ?
[14:51] <seb128> jbicha, why?
[14:51] <ricotz> java-stack kernel bug ;)
[14:51] <jbicha> seb128: for the same reason we ignored build tests on i386 :(
[14:52] <jbicha> ricotz: yes but neither you nor Sweetshark had upload rights…
[14:52] <seb128> jbicha, is the failure due to the i386/kernel/java segfault?
[14:53] <ricotz> jbicha, ok
[14:53] <seb128> jbicha, s390x is green after my retry from earlier
[14:53] <seb128> not on -l10n though
[14:53] <seb128> but yeah, +1 to skip on i386
[14:53] <seb128> who can do that? L_aney?
[14:54] <jbicha> oh, now LO is stuck because of python-defaults
[14:55] <seb128> bah
[15:43] <ricotz> jbicha, the meson package is built
[15:53] <jbicha> ricotz: autopkgtest succeeds on amd64 and armhf, only 2 arches I tried
[15:53] <jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-ricotz-staging/artful/armhf/m/meson/20170724_155058_dbc59@/log.gz
[15:53] <jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-ricotz-staging/artful/amd64/m/meson/20170724_154005_dbc59@/log.gz
[15:55] <jbicha> we can push that update to artful but I'd prefer to wait for Jussi's review since I don't think it's very urgent
[15:56] <ricotz> jbicha, ok
[16:18] <ricotz> jbicha, it got merged
[16:20] <jbicha> yes, could you ask him whether he'll do a Debian upload for it or if we should just upload to Ubuntu directly if we want the fix sooner?
[16:36] <Laney> /run-snapctl/basic: OK
[16:36] <Laney> laney@raleigh (master↑1|✚3)> echo $?                                                                                                                       ~/dev/canonical/upstream/random/snapd-glib
[16:36] <Laney> 0
[16:36]  * Laney dies
[16:41] <Laney> the testsuite's mock was relying on the library using main contexts in a particular way that I had changed
[16:51] <ricotz> jbicha, since you are in the meson channel you can read the response
[16:58] <ricotz> seb128, jbicha, so basically if you want meson to be fixed asap, just push my package
[18:51] <ricotz> jbicha, could you run the autopkgtest for this amd64 build https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-prereleases/+build/13139327 ?
[18:57] <jbicha> done
[18:58] <jbicha> to find the results for the earlier test you can visit
[18:58] <jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-ricotz-staging
[18:59] <jbicha> look for the <name> field with the log you want to see, like
[18:59] <jbicha> artful/armhf/m/meson/20170724_155058_dbc59@/log.gz
[18:59] <jbicha> then add that to the end of the original URL
[18:59] <jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-ricotz-staging/artful/armhf/m/meson/20170724_155058_dbc59@/log.gz
[19:00] <jbicha> it won't be live until the test finishes, but I believe the URL should be
[19:00] <jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-libreoffice-prereleases
[19:02] <ricotz> jbicha, thanks!
[19:03] <jbicha> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-libreoffice-libreoffice-prereleases
[19:03] <jbicha> better URL ^
[19:05] <jbicha> ok, trying again with all-proposed because of the python3 transition fun
[19:06] <jbicha> my 2nd try probably will fail too, it was my 3rd try that used all-proposed
[19:08] <ricotz> jbicha, http://autopkgtest.ubuntu.com/running#pkg-libreoffice
[20:41] <willcooke> night all