[04:56] <pitti> Good morning
[05:11] <Mirv> pitti: morning! could you add ps-jenkins to https://launchpad.net/~canonical-platform-qa/+members ? cmake-extras would like to merge back from CI Train.
[05:14] <pitti> Mirv: err, that sounds weird; that team isn't supposed to hand out development rights for projects, it's a "people" team
[05:15] <pitti> Mirv: but I believe some "cmake"ish team was created recently, and ~canonical-platform-qa was put into that, sec
[05:16] <pitti> Mirv: so ps-jenkins should perhaps be added to https://launchpad.net/~cmake-extras/+members ?
[05:16] <pitti> (I can't do that, though)
[05:20] <Mirv> pitti: right, maybe the code branch is then wrong where it's trying to push (https://code.launchpad.net/~canonical-platform-qa/cmake-extras/trunk)
[05:20] <pitti> Mirv: oh yes, this should almost certainly be owned by ~cmake-extras
[05:21] <pitti> Mirv: I think https://code.launchpad.net/~cmake-extras/cmake-extras/trunk is the real trunk, and Allan just forgot to delete the ~c-p-qa one
[05:21] <Mirv> but there's also https://code.launchpad.net/~cmake-extras/cmake-extras/trunk which looks identical, so I can just push manually to there
[05:21] <Mirv> indeed :)
[05:21] <pitti> I can delete the c-p-qa one if you want
[05:22] <pitti> Mirv: I think what happened is that he started with that one first, people complained about spam (and such a team is really a bad owner for projects anyway), and then created the ~cmak-eextras one
[05:23] <Mirv> pitti: sure, go ahead. I'll ask eg. satoris to pull the temporary branch pushed by ps-jenkins to the trunk.
[05:23] <pitti> Mirv: ah, there's a pending MP on the c-p-qa one; I think we should better ask allan to deal with that, he'll know for sure
[05:24] <Mirv> ok, makes sense
[06:28]  * didrocks implements mock ssl server now that the http is done and found http://www.piware.de/2011/01/creating-an-https-server-in-python/ which seems to be perfect for my needs!
[06:28]  * didrocks hugs pitti
[06:31] <larsu> good morning!
[06:31]  * pitti hugs didrocks back, bonjour!
[06:31] <pitti> hey larsu, guten Morgen
[06:31] <didrocks> hey larsu, pitti! :)
[08:04] <Laney> morning!
[08:04] <larsu> hi Laney
[08:04] <seb128> good morning desktopers!
[08:05] <seb128> hey Laney, wb! had good days off work?
[08:05] <seb128> hey larsu ;-)
[08:05] <didrocks> good morning Laney!
[08:06] <Laney> seb128: yep, very nice thank you
[08:06] <larsu> hi seb128 :)
[08:06] <Laney> climbing & bought a new suit ;-)
[08:06] <seb128> what's the occasion? ;-)
[08:07] <Laney> going to a wedding in a few weeks
[08:07] <Laney> I still had the same one that I bought 10 years ago in school ...
[08:07] <seb128> cool
[08:07] <seb128> doesn't fit you anymore? ;-)
[08:07] <pitti> hey Laney, bonjour seb128
[08:08] <Laney> not sure it ever did :P
[08:08] <seb128> pitti, lut, wie gehts?
[08:08] <Laney> hey pitti larsu et didrocks!
[08:08] <pitti> seb128: très bien, danke !
[08:08] <pitti> or perhaps..
[08:08] <pitti> je vais very gut, dankon !
[08:09] <seb128> lol
[08:10] <Laney> stgraber: We don't have tracker in desktop, I'm happy for it to be processed as a normal gnome bugfix SRU personally
[08:12] <seb128> Laney, what was the question?
[08:12] <Laney> tracker sru
[08:12] <seb128> I'm unsure tracker follows the GNOME releases rules
[08:14] <Laney> I thought it was by what's in the core (or whatever the name is) moduleset for jhbuild
[08:14] <Laney> which tracker is afaik
[08:15] <seb128> k, I'm unsure where tracker is nowadays
[08:16] <seb128> the spirit of the standing exception was to trust things that follow the GNOME feature/UI/... freeze
[08:16] <seb128> since that defines "stable" updates
[08:16] <seb128> tracker might be part of that
[08:25] <Laney> anyways even without exceptions I tend to like upstream bugfix releases going in
[08:25] <Laney> oh hey, the desktop-session mp was approved
[08:26] <seb128> Laney, yeah, speaking of which we should SRU stuff to trusty when we can ... like there is a new webkitgtk point release, and a new rhythmbox one
[08:27] <Laney> yep
[08:27] <Laney> the last webkit only got released yesterday
[08:27] <seb128> do you want to do the webkit one?
[08:27] <Laney> ok
[08:27] <seb128> thanks
[08:28] <seb128> oh ok, I just noticed because it's red on versions
[08:28] <Laney> into trusty-updates i mean
[08:28] <seb128> oh, ok
[08:28] <seb128> yeah, I know, I marked it verification-done on monday
[08:28] <Laney> cool, thanks for that
[08:29] <seb128> yw!
[08:42] <didrocks> pitti: would you know by hard how with nosetests to be able to print debug logging statement? I'm trying to use --nologcapture --logging-level=debug, but only logger.warn() and logger.info() are printed, not the debug one (like when a test fails)
[08:44] <pitti> didrocks: sorry, I don't know; I hardly ever use nose
[08:44] <didrocks> no worry, thanks! :)
[08:44] <pitti> didrocks: but I doubt that you can control logger with environment variables; usualy you have to call logging.basicConfig() yourself and set the log level
[08:46] <didrocks> pitti: seems that --logging-level=INFO from nose resets the logging level to what you want (even for dynamically created logger). The only "issue" is that it doesn't display them until a test fails. For debugging, I would like them to be displayed anyway
[08:46] <didrocks> --nologcapture prevents nose to capture them, but don't display them either
[09:07] <didrocks> ok, seems to work well now :)
[09:07]  * didrocks drops a nose configuration files for easier loading later as well
[09:36] <didrocks> waow, awesome to see that python-mock documentation also covers my cornercase and have an example for it: https://docs.python.org/3.5/library/unittest.mock-examples.html#coping-with-mutable-arguments :)
[09:40] <mvo> didrocks: mock is the bomb
[09:40] <larsu> mvo: nice picture, thanks ;)
[09:41] <mvo> larsu: your very welcome, I like it too!
[09:41] <didrocks> mvo: I'm using it for a while already, but didn't get to that case yet. Nice to see it being covered by the documention :)
[09:41] <didrocks> documentation*
[09:41] <mvo> didrocks: yeah, my experience exactly, its not only great, its also very well documented
[09:43] <didrocks> indeed, enjoyed a lot. Unfortunatly, most of the time, I end up in readthedoc which is slightly outdated since mock entered the python library
[11:10] <pitti> seb128: mind having a quick look at https://code.launchpad.net/~3v1n0/gnome-session/remove-compiz-requiriment/+merge/216236 ? does that make sense?
[11:10] <pitti> seb128: (I'll merge it to the correct branch and upload, just wanted to get a second opinion)
[11:13] <seb128> pitti, looks good to me in principle, I didn't look at the login sequence to see if that creates flickering issues or such though ... but I guess we can fix those later if needed
[11:13] <seb128> well, Trevinho claims compiz is already started by upstart in most cases atm, so should not have that of an impact
[11:13] <pitti> thanks
[11:13] <seb128> pitti, +1 from me, thanks for the sponsoring ;-)
[12:26] <om26er> if system-settings is started by autopilot on the phone it seems the settings are not saved in accountservice for ringtone etc, does anyone have clues on what could be wrong ?
[12:27] <om26er> the same thing if done on the desktop works fine
[12:36] <popey> Could someone point me in the direction of the thing that generates the xdg folders in $HOME? The ~/Music, ~/Downloads etc folders
[12:37] <seb128> popey, xdg-user-dirs-gtk
[12:37] <popey> thank you seb128!
[12:37] <seb128> popey, on desktop at least (/etc/xdg/autostart/xdg-user-dirs-gtk-update.desktop is the thing run on login)
[12:38] <popey> perfect! thanks.
[12:39] <seb128> yw
[12:39] <seb128> om26er, could be that the dbus env is wrong? (similar to recent issues with the split greeter)
[12:41] <daveyesdave> I'm looking for a way to colour code nautilus when connected to a remote server, for example red background when connected to live server etc...
[12:41] <pp20> daveyesdave: funny that! I asked the same yesterday... if you find out, let me know :)
[12:44] <om26er> seb128, that could be the case do you have any workarounds/suggestions ?
[12:45] <om26er> because when autopilot changes the tone and get backs to the sounds panel the ringtone remains the same
[12:46] <seb128> om26er, just make sure the dbus environment for those jobs is the same as the one from the user session
[13:11] <daveyesdave> pp20, great minds and all that...
[13:13] <seb128> daveyesdave, seems like a wishlist to report on https://bugzilla.gnome.org/enter_bug.cgi?product=nautilus
[13:18] <daveyesdave> seb128, do you know an alternative file manager that might already offer this function? commander etc?
[13:18] <seb128> daveyesdave, no idea, try #ubuntu for user questions
[13:19] <daveyesdave> seb128, I'll give them a go, thanks
[13:19] <seb128> yw!
[13:53] <Laney> new webkit switches to geoclue 2 in Debian
[13:53] <Laney> should we do this too?
[13:53] <seb128> tedg, ^ do you know?
[13:54] <seb128> Laney, do you know what changed in the new one? are the providers the same?
[14:01] <Laney> it looks like the API has been trimmed
[14:01] <Laney> but the two versions are parallel installable
[14:01] <seb128> +1 for following Debian on webkit
[14:01] <seb128> we can still change back later if it turns out to be problematic
[14:01] <Laney> so we'd have to promote the new one
[14:01] <Laney> should be ok I guess
[14:02] <seb128> that's a new codebase I think
[14:02] <seb128> so maybe stick to the old one until we SRU the new webkit/get the MIR reviewed
[14:02] <Laney> http://www.hadess.net/2013/04/geocluing-desktop-slowly.html
[14:03] <Laney> don't know how the ubuntu geoip stuff will fit in there
[14:03] <seb128> yeah, me neither, why is why I pinged tedg ;-)
[14:04] <tedg> Sorry, OTP.
[14:04]  * tedg reads backlog
[14:05] <tedg> seb128, Laney, well my understanding is that there are no plugable providers in GeoClue 2.
[14:05] <tedg> But that's kinda a moot point in that we'll probably move things to location service.
[14:05] <seb128> tedg, do we need one?
[14:05] <tedg> So I don't think that it matters really.
[14:06] <tedg> If we wanted to use our GeoIP service, we'd need something plugable. But, not sure that we need one for generic webkit.
[14:06] <tedg> We'll probably just end up working with Oxide there.
[14:07] <seb128> tedg, what is our provider doing that the upstream one isn't?
[14:07] <seb128> tedg, we don't want to regress unity7, not sure where we use geoclue ... we probably don't care much about webkitgtk, but we do care about ubiquity and the indicator I guess?
[14:08] <tedg> seb128, I think that we can have both, no? We can stick with GeoClue 1 for those while having GeoClue 2 for webkit GTK.
[14:09] <tedg> I think the issue is the service being free to use or needing API keys and the such.
[14:09] <seb128> tedg, sure, but it means we have 2 versions supported/installed
[14:09] <tedg> For the interim releases, but I'm sure we'll be off GeoClue by the next LTS for those.
[14:10] <seb128> k
[14:10] <seb128> tedg, thanks
[14:10] <seb128> Laney, ^ makes sense to you?
[14:11] <Laney> do you have to explicitly ask for ubuntu geoip with geoclue 1?
[14:13]  * xnox is pretty sure ubiquity uses geoclue 1 against our canonical hosted server
[14:13]  * xnox goes to check
[14:14] <xnox> actually, no we don't. We just do a GET request to http://geoname-lookup.ubuntu.com/?query=%s&release=%s
[14:16] <Laney> I think it's alright to use both for now I guess
[14:16] <Laney> if I was curious I'd ask about the origins of location-service
[14:16] <Laney> but I'm alright not knowing for now actually ;-)
[14:24] <xnox> Laney: when location-service first came up, i thought it was related to cellphone-tower possition, which geoclue1 did not do....
[14:24] <seb128> Laney, you don't want to ask, that's another "cpp is better than g"
[14:24] <seb128> like we could have contributed to the geoclue rewrite with the GNOME guys
[14:25] <Laney> xnox: I think there was an opportunity to influence geoclue :)
[14:25] <Laney> seb128: yeah let's move on :P
[14:25] <xnox> seb128: qt5 has a hard-dep on gtk2 still, i think we know what's better =)
[14:25]  * xnox all Qt5 on Linux is delivered to you by Gtk+2 =)
[14:26] <xnox> same like it used to be the case with all Airbus planes to be delivered by a Boeing cargo transporter.
[14:31] <Laney> symbiosis
[14:35] <Trevinho> pitti: on that patch it's probably the case also to remove unity-settings-daemon as well
[14:35] <Trevinho> pitti: as it's using upstart
[14:39] <didrocks> ok, seems the rain ended outside, time for a run!
[14:40] <seb128> didrocks, enjoy!
[14:41] <didrocks> thanks, wish me luck to avoid any rain shower :)
[14:41] <didrocks> (at least, temperature is nice)
[15:57] <sil2100> kgunn: hey! Did you guys propose your blueprints for the UOS already?
[18:08] <rickspencer3> hey all, mediascanner-service is using a lot of resources on my desktop :(
[18:09] <rickspencer3> and it keeps respawning if I kill it
[18:11] <rickspencer3> seb128, still around at all?
[18:21] <Laney> rickspencer3: Looks like it has an upstart job which will restart it
[18:21] <Laney> stop mediascanner-2.0 should do it
[18:21] <rickspencer3> Laney, yeah, I finally figured that out
[18:21] <Laney> ah
[18:21] <rickspencer3> it was not in the list of upstart jobs
[18:21] <rickspencer3> but, I am probably just super confused
[18:22] <rickspencer3> I thought service --status-all would show me what it is called
[18:22] <rickspencer3> Laney, popey hooked me up (along with tab completion) :)
[18:22] <Laney> I don't know what that does
[18:22] <rickspencer3> Laney, I assumed it would show all the services and their current status
[18:22] <Laney> initctl list is that one that I know
[18:23] <Laney> anyway I would hope that it's running at a low enough priority to not impact the usage of your system
[18:23] <Laney> did you notice it being slow?
[23:02] <xnox> Laney: service command only ever operates on system-init (if it doesn't / leaks user-session info, it's a bug)
[23:02] <xnox> Laney: indeed initctl commands should have been used instead...
[23:34] <thumper> Trevinho: around?
[23:34] <thumper> Trevinho: because you work crazy hours...
[23:35] <Trevinho> thumper: hi :)
[23:35] <thumper> Trevinho: hey there
[23:35] <thumper> Trevinho: I have some unity weirdness...
[23:35] <Trevinho> thumper: tell me...
[23:35] <thumper> Trevinho: I have five emails open, so lots of pips next to thunderbird
[23:36] <thumper> if I alt-` I get the tab spread, right?
[23:36] <Trevinho> thumper: you should yes
[23:36] <thumper> however, the images in the spread flicker
[23:36] <thumper> going from shaded to not, to shaded
[23:36] <Trevinho> thumper: yes, that's a known issue...
[23:36] <thumper> ok
[23:36] <thumper> Trevinho: is it an issue that is likely to be fixed soon?
[23:37] <Trevinho> thumper: I also know how to prevent it, but it's not an optimal fix, so I avoided it for now... but it's something we should avoid asap
[23:37]  * thumper nods
[23:38] <Trevinho> thumper: basically there's one-line change that fixes it (damaging the switcher area when painting these windows), but it would cause too many redraws also when not needed... and although I didn't notice any slow-down I didn't like the idea :)
[23:38] <thumper> :)
[23:38] <Trevinho> anyway... yeah a better solution is in my list for some time
[23:52] <robert_ancell> RAOF, is there any logical reason why in X you can have a depth=32 window with bpp=24?
[23:53] <RAOF> robert_ancell: Hm. I thought it would be the other way around.
[23:53] <RAOF> robert_ancell: But, sure! Drivers want 32 bits per pixel, because 4 bytes is a nice round number.
[23:54] <RAOF> robert_ancell: So basically it's a “pixels are 32bits, of which 24 are actually significant”
[23:54] <robert_ancell> RAOF, so it should be allowed?
[23:54] <RAOF> Yeah. But from memory depth is the number of significant bits and bpp is the total number of bits; are you sure you're not getting those reversed?
[23:55] <robert_ancell> RAOF, I'm chasing down an assertion that's hit in X when running under qemu - the root window is 24bpp and if you use  the depth=32 visual on the window and render to it using RENDER it doesn't render/renders wrong
[23:56] <robert_ancell> So I'm not 100% sure where the bug is, but the fact the drawable is set that way suggests something went wrong at window creation
[23:56] <RAOF> Ah.
[23:56] <robert_ancell> which might be the fb backend, because I think that's what qemu is using; at least on my system
[23:57] <RAOF> I'm not entirely sure if RENDER handles that case correctly. It's possible to do correctly.
[23:57] <robert_ancell> RAOF, yeah, so RENDER should be dropping some bits somewhere to make it fit?
[23:57] <RAOF> Yeah. The 8 bits of alpha would be a prime candidate :)
[23:57] <robert_ancell> yep
[23:58] <robert_ancell> RAOF, and a follow up there. Is there anything that actually specifies in a depth=32 visual that the remaining 8 bits is actually alpha? Is that just a convention?
[23:58] <RAOF> As far as I can tell, convention. :(
[23:59] <robert_ancell> yeah, the spec mentions nothing. I was wondering if it got specified in a an extension somewhere
[23:59] <robert_ancell> There really should be a XALPHA extension that turns this on