[03:49] <pitti> Good morning
[04:44] <TheMuso> ~/c -all
[04:51] <RAOF> Wow. The archive's pretty unstable after B2 release.
[04:54] <TheMuso> I guess thats one drawback of everything being held in the queue... You don't see any breakage for a few days, and then it all hits...
[04:55] <pitti> but still http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html shouldn't look like this
[04:55] <pitti> the plan is to eventually redirect _all_ uploads to -proposed, let them build on all arches, and only auto-migrate them to -release once everything is built and installable
[04:56] <TheMuso> Yep.
[05:15] <didrocks> good morning
[05:59] <pitti> bonjour didrocks!
[06:02] <didrocks> guten morgen pitti!
[06:45] <jibel> good morning
[06:51] <bryceh> Sawubona
[06:51] <didrocks> seems already EOD for jibel :)
[07:06] <pitti> didrocks: mais oui -- c'est vendredi!
[07:06] <didrocks> pitti: héhé, vive le week-end! (bientôt ;))
[08:02] <Laney> hey
[08:02] <Laney> happy friday!
[08:02] <didrocks> hey Laney :)
[08:02] <didrocks> happy friday!
[08:03] <didrocks> Laney: just rejected PS ubuntu-font-family change FYI. See https://code.launchpad.net/~timo-jyrinki/ubuntu/quantal/ubuntu-font-family-sources/manual_fix_ubuntu_M/+merge/126647
[08:03] <Laney> didrocks: hmm, don't we need the Qt change too?
[08:04] <Laney> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.3+dfsg-0ubuntu2 this one
[08:04] <didrocks> Laney: seb is just telling me that
[08:04] <didrocks> but it seems PS didn't test Qt apps first (see the comments)
[08:04] <didrocks> weird, I've upgraded this morning
[08:05] <seb128> didrocks, you use proposed?
[08:05] <seb128> hey didrocks, Laney
[08:05] <Laney> moin
[08:05] <didrocks> seb128: still in -proposed, devs are not supposed to use it :)
[08:05]  * didrocks cherry-pick it from -proposed
[08:05] <seb128> didrocks, right, post beta2 churns
[08:05] <didrocks> I would have thought all -proposed would be copide
[08:05] <didrocks> copied*
[08:05] <seb128> it was only accepted in proposed yesterday evening
[08:06] <seb128> did it even build on slow arches yet?
[08:06] <didrocks> ah maybe
[08:06] <Laney> I don't know though, because https://code.launchpad.net/~timo-jyrinki/ubuntu/quantal/ubuntu-font-family-sources/manual_fix_ubuntu_M/+merge/126647/comments/273105 refers to that proposed upload
[08:06] <seb128> no
[08:06] <Laney> and calls the font fix a workaround?!
[08:06] <seb128> it's still building on arm*
[08:06] <didrocks> Laney: yeah, I don't understand :)
[08:06] <didrocks> Laney: proposing a fix and then rejecting himself :)
[08:06] <Laney> maybe it refers to the /proper/ fix in Qt
[08:06] <didrocks> and not testing on Qt where it's asked to do it
[08:06] <Laney> which is an API,ABI break
[08:06] <Laney> weird
[08:06] <didrocks> Laney: I'll try both
[08:07] <didrocks> new Qt with patched font packaged
[08:07] <didrocks> and then new Qt only
[08:07] <Laney> I wouldn't be too upset if that ended up being an R thing
[08:07] <seb128> bryceh, "-1" ... can I get a  --verbose?
[08:07] <seb128> bryceh, or did you typo "+1"? ;-)
[08:07] <didrocks> Laney: seb128: vlc is still bold on my system
[08:08] <didrocks> even with the patched font and patched Qt
[08:08] <seb128> :-(
[08:08] <didrocks> oh dist-upgrade hold a Qt package
[08:08] <didrocks> let's try getting this one :)
[08:08] <didrocks> (upgrade gave a bunch of Qt packages, but one)
[08:09] <didrocks> ah better \o/
[08:09] <didrocks> let me try to downgrade the font now to quantal version
[08:09] <Laney> maybe confirm with sladen
[08:10] <didrocks> ok, so no difference with old and new font package
[08:10] <didrocks> so we can put it in
[08:10] <didrocks> get medium font size
[08:10] <didrocks> but I would put it into -proposed so that it's copied at the same time than qt
[08:10] <Laney> https://launchpad.net/~laney/+archive/webkit/+build/3858769 :(
[08:11] <bryceh> seb128, no typo.  -1 to eliminating fallback.
[08:11] <seb128> bryceh, oh, that's not the suggestion, I'm just saying that the code we build over is going away, no our choice and nothing we can do about it
[08:12] <bryceh> seb128, regardless, -1 to that.
[08:12] <seb128> bryceh, GNOME consider it legacy code and want to drop it to focus on gnome-shell
[08:12] <seb128> bryceh, ok, fair enough, we can discuss it at UDS, if you have better suggestions on what we should do with e.g the keyboard indicator if the code we patch goes away
[08:13] <bryceh> seb128, understood.  And fair enough; their choice.  But I will consider it a Bad Idea.
[08:13] <seb128> well, it's just that we have to deal with it, if the code is going away either we loose the function or we figure the best way to bring it back
[08:14] <bryceh> seb128, yep.  f*ck*ng gnome.
[08:15] <bryceh> seb128, btw s/loose/lose/.
[08:15] <seb128> bryceh, thanks ;-)
[08:16] <bryceh> I suppose no one will actually care until we get to 14.04.
[08:25] <mlankhorst> ricotz: why is cairo in xorg-edgers?
[08:31] <ricotz> mlankhorst, is is pretty much rendering related like pixman and fits in there
[08:32] <mlankhorst> ricotz: oh was wondering since it might be useful to backport in that case
[08:32] <seb128> I'm out for some hours, will we back in the afternoon
[08:32] <ricotz> mlankhorst, then you should consider cairo and pixman
[08:33] <bryceh> seb128, *waves*
[08:34] <bryceh> mlankhorst, there is a small bit of cairo that sometimes overlaps with X and ends up being a dependency for the X stack.  I'm guessing that's to blame here.
[08:34] <bryceh> this = the 2d cairo vector drawing "driver" that's contained in cairo
[08:35] <ricotz> weston in its earlier stage was a reason to have it too (not really anymore since cairo-gl isnt mandatory anymore)
[08:37]  * ricotz wonders if cairo master is getting in a snapshot state already
[08:37] <ricotz> snapshot *worth* state
[08:52] <chrisccoulson> good morning everyone
[08:53] <didrocks> hey chrisccoulson! how are you?
[08:53] <chrisccoulson> didrocks, yeah, not too bad thanks, although i'm getting a cold now
[08:53] <chrisccoulson> how are you?
[08:54] <didrocks> a little bit better, still coughing, but at least, I can start to be hopeful to be in shape next week :)
[11:10] <tjaalton> didrocks: hum, looks like there was a clash with the xterm m-a foreign bug
[11:10] <tjaalton> we'll see which uploads end up in the archive
[11:10] <didrocks> tjaalton: ah? ok, yeah, let's see :)
[11:11] <tjaalton> I assigned it to myself 4min before your comment :)
[11:11] <Laney> the one without the random whitespace change :-)
[11:12] <tjaalton> I pushed it to git too
[11:12] <tjaalton> both debian & ubuntu
[11:12] <didrocks> tjaalton: ah excellent!
[11:12] <mlankhorst> bryceh: ah good to know :) (missed it earlier)
[11:12] <tjaalton> so it's there in any case
[11:12] <Laney> dunno which one I just accepted
[11:12] <Laney> guess you'll get mail :P
[11:12] <didrocks> tjaalton: that's the important one :)
[11:13] <tjaalton> I lost :/ :)
[11:13] <didrocks> \o/
[11:13]  * didrocks hugs tjaalton
[11:13] <tjaalton> hehe
[11:13] <didrocks>  /msg Laney: I'll pay you back at UDS, as we talked about :)
[11:13] <didrocks> oups ;)
[11:14] <Laney> the secret's out
[11:14]  * Laney screams and runs away
[11:14] <didrocks> zomg!
[11:14] <didrocks> :)
[11:14] <tjaalton> :)
[12:59] <didrocks> pitti: \o/
[12:59] <pitti> didrocks: BBT? already watched it?
[13:00] <pitti> I just did over lunch
[13:00] <didrocks> pitti: not yet ;)
[13:00] <didrocks> but I know what I'll do this evening :)
[13:00]  * pitti hugs didrocks
[13:00]  * didrocks hugs pitti back
[13:10] <Trevinho> desrt: hey, found anything about the gsettings trouble on saving too many things on startup (breaking some migration scripts)?
[13:11] <desrt> Trevinho: i think the problem was gnome-session lacking ordering, no?
[13:11] <desrt> ie: migration should be moved to before gnome-session
[13:11] <Trevinho> didrocks: ^
[13:12] <didrocks> desrt: well, not really possible as we need the env?
[13:12] <desrt> what env?
[13:12] <didrocks> desrt: gnome-session launch the migration script sync
[13:12] <didrocks> what is the issue with it?
[13:13] <desrt> didrocks: someone (ted?) discovered that that doesn't really work
[13:13] <desrt> that there is no 'wait until this is done'
[13:13] <desrt> and it actually ends up running everything at once
[13:13] <desrt> you should put migration in /etc/x11/xsession.d/ or whatever
[13:14] <didrocks> desrt: interesting
[13:14] <didrocks> it's a synced called though, let's see what tedg can come up with :)
[13:15] <didrocks> Trevinho: anyway, too late for Q
[13:23] <Trevinho> didrocks: ok..
[14:02] <seb128> back
[14:03] <ogra_> front
[14:05] <seb128> right
[14:05] <ogra_> left
[14:05] <ogra_> :)
[14:06] <kenvandine> forward
[14:08] <mdeslaur> you desktop folks are weird :P
[14:08] <kenvandine> mdeslaur, why yes... yes we are
[14:08] <kenvandine> :-D
[14:14] <seb128> mdeslaur, come on, it's friday, it has been a long week!
[14:15] <mdeslaur> :)
[14:29] <seb128> desrt, hey
[14:29] <desrt> seb128: hey
[14:29] <seb128> desrt, sudo apt-get install libpam-xdg-support
[14:29] <desrt> ooo
[14:29] <seb128> desrt, should give you XDG_RUNTIME_DIR
[14:29] <seb128> if you want to test
[14:29] <desrt> that's some welcome good news :)
[14:30] <desrt> vorlon to thank, i suppose?
[14:30] <seb128> desrt, and FFE got granted to have it installed by default
[14:30] <seb128> desrt, yes
[14:30] <desrt> good man :)
[14:30] <desrt> i'll have to beerify him at UDS
[14:30] <desrt> lemme logout/in to see if it's working
[14:32] <desrt> desrt@moonpix:~$ echo $XDG_RUNTIME_DIR
[14:32] <desrt> /run/user/desrt
[14:33] <desrt> oldschool
[14:34] <seb128> desrt, what are the new cool kids doing? ;-)
[14:34] <desrt>  /run/user/1000/
[14:34] <seb128> open a bug I guess ;-)
[14:34] <desrt> it really doesn't matter
[14:34] <desrt> the spec leaves the name/location of the directory as a choice of the implementation
[14:35] <seb128> so it works, but breaks in a guest session
[14:35] <desrt> why?
[14:35] <seb128> I guess the apparmor profile needs updating to give access to the /run/user/$user
[14:35] <seb128> dconf-editor complains about permissions
[14:35] <desrt> fucking apparmor....
[14:35]  * desrt mumble mumble
[14:35] <seb128> hehe
[14:36] <desrt> first thing i uninstall
[14:36] <desrt> followed shortly by apport :)
[14:36] <seb128> let's not restart that discussion today ;-)
[14:36] <seb128> I know it's friday but still :p
[14:36] <desrt> that discussion was actually really productive last time, i think
[14:36] <desrt> and we continued it a bit at plumbers
[14:36] <seb128> it seemed to be, I admit I didn't read the whole backlog though
[14:36] <seb128> great ;-)
[14:37] <desrt> anyway
[14:37] <desrt> please let me know if you're seeing anymore SIGBUS from dconf on ecryptfs
[14:37] <desrt> assuming the new package is installed
[14:37] <desrt> is there any way we get that information from apport bugs?
[14:38] <desrt> i guess we would see the environment of the running process?
[14:38] <desrt> i _think_ there is still a situation where that bug can come up
[14:39] <desrt> but it should be a really really thin race now -- and i already have a plan for fixing it
[14:39] <seb128> desrt, we don't have the full environment, apport only collect some selection variables I think
[14:39] <desrt> seb128: any way we can get XDG_RUNTIME_DIR onto that list?
[14:39] <seb128> will let you know if it keeps being an issue
[14:39] <seb128> desrt, poke pitti I guess ;-)
[14:39] <desrt> pitti: poke :)
[14:39] <seb128> I mean open a bug on apport :p
[14:39] <seb128> (I guess pitti tell you to do that)
[14:39] <desrt> hm
[14:40] <desrt> pitti just made a very nice blogpost
[14:40] <pitti> back from meeting, what's up/
[14:40] <pitti> ?
[14:40] <pitti> hey desrt
[14:41] <seb128> desrt, dbusmock you mean?
[14:41] <desrt> pitti: hey.  can we get XDG_RUNTIME_DIRS on the list of envvars that apport puts in reports?
[14:41] <desrt> seb128: ya.  looks nice :)
[14:41] <seb128> pitti, keep the good work, loving to read your progresses in testing land ;-)
[14:41] <pitti> desrt: we need to be a bit careful about not exposing potentially private stuff there
[14:41] <pitti> seb128: :)
[14:41] <desrt> pitti: XDG_RUNTIME_DIR is the name of a directory in /run
[14:41] <pitti> desrt: but I guess XDG_RUNTIME_DIRS should be okay
[14:42] <desrt> the only potential privacy leak is their username :)
[14:42] <pitti> desrt: stuff like user names, project names, etc.
[14:42] <desrt> username is seriously a problem?
[14:42] <pitti> right, but we coudl ask the anonymizer to change it
[14:42] <desrt> well
[14:42] <pitti> yes, I had people complain about it loudly
[14:42] <desrt> i'm mostly interested in knowing if it is set or not
[14:42] <pitti> desrt: but do you really need to know the actual value?
[14:42] <pitti> right, that's what I figured
[14:42] <pitti> a simple "is set or not" has no privacy problems at all, and is easy to do
[14:43] <desrt> do you need a bug?
[14:43] <pitti> if you want one to track it
[14:43] <desrt> i don't really care
[14:43] <desrt> i will only care the next time we see a new report of dconf SIGBUS issues
[14:43] <desrt> and i want to know if it 'should' have been fixed yet or not
[14:44] <desrt> seb128: btw... about all those bugs before... anything that's having a SIGBUS on accessing anything about 'shm' is now officially fixed
[14:44] <pitti> desrt: so is it _DIR or _DIRS?
[14:44] <desrt> pitti: _DIR
[14:44] <desrt> echo $XDG_RUNTIME_DIR -> /run/user/desrt
[14:45] <desrt> seb128: the shm part is the one that is now in the XDG_RUNTIME_DIR
[14:45] <desrt> interesting to note that already gnome-keyring and gvfs have put files there as well...
[14:45] <pitti> desrt: testing http://paste.ubuntu.com/1247632/ now
[14:46] <desrt> pitti: would be great to know as well if it is unset
[14:46] <pitti> then the line wouldn't be there
[14:46] <desrt> ie: tell the difference of "it is not set" and "apport is too old"
[14:46] <seb128> desrt, ok
[14:46] <pitti> desrt: you could tell from the ApportVersion: field
[14:46] <desrt> pitti: perfect
[14:49] <pitti> desrt: committed to trunk
[14:49] <desrt> pitti: great.  i guess it will see a release by Q?
[14:49] <pitti> c'est ça, bon week-end tout le monde!
[14:49] <pitti> desrt: oui, Monsieur
[14:50] <desrt> pitti: bonan semajnfino
[14:50] <desrt> +n
[14:51] <pitti> c'est l'heure de tennis de table et pour du glace!
[14:51] <desrt> glace!
[14:51] <pitti> yeah, enjoying the last sun rays :)
[14:51] <seb128> pitti, bon weekend !
[14:52] <seb128> pitti, bonne partie et bonne glace ;-)
[15:55] <seb128> Laney, hey
[15:55] <Laney> ho
[15:55] <seb128> Laney, if you want to do the backport and now what to do feel free to go for it
[15:55] <seb128> but if you prefer me to have a look that's fine
[15:55] <Laney> well I don't know what to do, but I see the MP
[15:55] <Laney> if it's more than taking that as a distro patch ...
[15:58] <seb128> Laney, yeah, it's basically backporting that revision, the packaging changes are already in lp:ubuntu/unity-lens-shopping
[15:58] <seb128> Laney, you can do it?
[15:58] <Laney> sure
[16:00] <seb128> Laney, mhr3 says you need r21 if you want it to apply cleanly, we can probably backport both
[16:00] <seb128> the other one was a FFe as well so would be good to have it landing,tested as well
[16:02] <Laney> seb128: isn't that one that got nacked by scottk?
[16:02] <Laney> mhr3: ^ ?
[16:03] <seb128> Laney, no, that's r23 which got reverted in r24
[16:03] <seb128> Laney, https://code.launchpad.net/~unity-team/unity-lens-shopping/trunk
[16:03] <seb128> bah
[16:03] <seb128> 24,25 I meant there
[16:03] <mhr3> Laney, what seb128 said
[16:03] <Laney> oh, no, that's a good link
[16:03] <Laney> it takes me to the bugs
[16:04] <Laney> nope, I still don't see it being approved
[16:04] <Laney> https://bugs.launchpad.net/unity-lens-shopping/+bug/1055684
[16:04] <ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress]
[16:04] <Laney> ScottK and stgraber collided but I don't see an approval yet
[16:05] <mhr3> oh, i thought it's already ack
[16:05] <mhr3> ed
[16:05] <mhr3> so... yey for conflicts?
[16:06] <stgraber> Laney: current status is a nack in current form, maybe Kate will +1 or we'll just go with the disabling previews option
[16:07] <mhr3> seb128, Laney, actually you can merge it from my branch, i was based on 6.0.0 tag
[16:07] <mhr3> so the merge with trunk is last rev
[16:07] <mhr3> https://code.launchpad.net/~mhr3/unity-lens-shopping/secure-connection
[16:07] <mhr3> stgraber, previews aren't disablable
[16:08] <mhr3> i mean... can't be disabled :)
[16:09] <stgraber> mhr3: surely you must have a "No preview available" or similar string that you could show
[16:11] <mhr3> stgraber, but we can't lie to the users, the server does send the preview
[16:16] <mterry> pitti, do you know why update-manager and ubuntu-release-upgrader have been failing on amd64 jenkins jobs due to dependency installation failure?  Log isn't very clear.  https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-adt-update-manager/61/ARCH=amd64,label=albali/artifact/results/log
[16:45] <popey> seb128, mhr3, https://bugs.launchpad.net/unity-lens-shopping/+bug/1055684 updated
[16:45] <ubot2> Launchpad bug 1055684 in unity-lens-shopping "[FFE] Use music lens details page for music store results" [High,In progress]
[16:47] <Laney> shopping uploaded for SSL
[16:48] <didrocks> Laney: you updated lp:ubuntu/unity-lens-shopping isn't it?
[16:48] <Laney> will push when it's accepted
[16:48]  * Laney has a fear of pushing tags which then turn out to be wrong
[16:48] <didrocks> Laney: just to ensure, you bzr merge? :)
[16:49] <Laney> bzr merge -r<revision> <branch>
[16:49] <Laney> is that right?
[16:49] <Laney> the debdiff looked good to me
[16:49] <didrocks> Laney: -rrevstart..revend :)
[16:49] <didrocks> Laney: as long as you are sure you didn't pick my change
[16:50] <didrocks> (I think it was just merge some minutes after it)
[16:50] <didrocks> so should be fine :)
[16:50] <didrocks> because you know the famous story of gsettings and schemas not there :)
[16:52] <chrisccoulson> sigh :(
[16:53] <chrisccoulson> 2 bugs identical to bug 1058209 since the webapps addons were seeded
[16:53] <ubot2> Launchpad bug 1058209 in firefox "firefox re-installs Add-ons every couple of starts" [Undecided,New] https://launchpad.net/bugs/1058209
[17:04]  * didrocks waves good evening
[17:04] <didrocks> and good week-end!
[17:21] <Laney> have a nice weekend everyone!
[17:21] <Laney> enjoy your secure dash shopping experience :-)
[17:25] <popey> :)
[18:04] <desrt> seb128: is it possible to disable the accounts-crap integration with empathy?
[18:04] <seb128> desrt, you are always having nice words right? ;-)
[18:04] <desrt> i prefer the ability to actually use jabber...
[18:04] <seb128> desrt, dunno, ask kenvandine
[18:05] <desrt> kenvandine: poke?
[18:05] <seb128> desrt, uoa fail to configure your jabber account?
[18:05] <desrt> yes
[18:05] <desrt> i click done.  nothing happens (at all)
[18:05] <xnox> and fail to migrate them as well.
[18:05] <seb128> desrt, I would rather to see that fixed that worked around
[18:05] <desrt> the button clicks in, then it clicks out
[18:05] <seb128> desrt, do you have account-plugin-jabber installed?
[18:05] <desrt> i can click it again if i like...
[18:05] <seb128> xnox, bug number?
[18:05] <desrt> yes
[18:05] <desrt> it's on the list as well
[18:05] <desrt> but it doesn't work
[18:05] <seb128> :-(
[18:06] <desrt> i'd like to get the normal epiphany accounts dialog
[18:06] <desrt> i'm sure that would work properly
[18:06] <xnox> seb128: does my housemate swearing at me counts as a bug number?
[18:06]  * desrt is about to start swearing as well
[18:06] <seb128> xnox, not very helpful for tracking and getting resolved
[18:06] <seb128> desrt, empathy you mean? isn't empathy-accounts still there?
[18:07] <desrt> ahah!
[18:07] <jbicha> xnox: get your housemate to file a bug report ;)
[18:07] <desrt> seb128: thanks :)
[18:07] <seb128> desrt, yw
[18:07] <seb128> desrt, please talk to amigadave on monday if you can
[18:07] <seb128> desrt, that uoa bug should be fixed
[18:07] <desrt> sigh.
[18:07] <desrt> the normal dialog is working
[18:07] <seb128> :-(
[18:08] <desrt> but it immediately forgets my password
[18:08] <seb128> xdg-runtime-dir fallout?
[18:08] <desrt> no doubt due to the uoa cancer
[18:08] <seb128> can you try without the runtime dir in case?
[18:08] <desrt> i get really annoyed when people butcher gnome packages non-conditionally
[18:08] <seb128> you are speaking without knowing at this point
[18:08] <seb128> it could be the runtime stuff as well
[18:09] <seb128> empathy-account is not patched afaik
[18:09]  * desrt removes xdg, logout/in
[18:09] <seb128> it could be an upstream bug for what we know
[18:09] <desrt> empathy-accounts is fine
[18:09] <desrt> it's empathy that's the problem
[18:09] <seb128> you said it forgets your password
[18:11] <jbicha> desrt: I think we'll drop gnome-online-accounts from the Remix if ubuntu-online-accounts can handle Contacts, Documents, & Evolution next cycle
[18:11] <desrt> seb128: problem is not related to the xdg runtime stuff
[18:11] <desrt> but logging out and back in again seems to make it work
[18:12] <jbicha> seeing as how Empathy hard-depends on u-o-a any way
[18:12] <desrt> the uoa dialog is still stuck, though
[18:12] <seb128> desrt, hum, k
[18:12] <desrt> but at least configuring via the empathy-accounts dialog is working
[18:12] <seb128> desrt, you would need to talk to David but I think he's eod(w)
[18:13] <seb128> desrt, can you do that next week?
[18:13] <desrt> sure
[18:13] <seb128> thanks
[18:13] <desrt> meanwhile we should probably fix the empathy package to emable the uoa stuff only under unity...
[18:13] <desrt> *enable
[18:14] <desrt> running empathy-accounts from the commandline isn't exactly discoverable...
[18:15] <desrt> also seems a bit twisted that empathy now has a qt dependency....
[18:15] <seb128> we need to discuss how to make the GNOME remix more vanilla at UDS
[18:15] <seb128> shame that jbicha will not be there
[18:15] <seb128> jbicha, you will not be there right?
[18:15] <desrt> seb128: jbicha is all-american
[18:15] <seb128> (just checking if I got a wrong info)
[18:15] <desrt> all america, all the time :)
[18:16] <seb128> desrt, he said he was in Brussels' UDS IIRC
[18:16] <seb128> well anyway
[18:16] <seb128> no jbicha, no robert_ancell
[18:16] <seb128> desrt, hope you will be there to defend GNOME interests :m
[18:16] <seb128> :p
[18:20] <desrt> i get so sick of all the patching....
[18:20] <jbicha> yeah, empathy depending on qt is annoying
[18:20] <seb128> use ostree ;-)
[18:20] <desrt> jbicha: https://bugs.launchpad.net/ubuntu/+source/empathy/+bug/1058250
[18:20] <ubot2> Launchpad bug 1058250 in empathy "conditionalise empathy u-o-a dependency" [Undecided,New]
[18:21] <jbicha> lol
[18:21] <seb128> but honestly I think over time we are getting close of distros really supporting one desktop with the increase hard depends on stack choices
[18:21] <seb128> e.g "need gdm to lock your screen"
[18:22] <desrt> ya.  that's somewhat obnoxious, imho
[18:22] <desrt> but from gnome's standpoint, lightdm was seen as a fork
[18:22] <desrt> so blame all around, i guess?
[18:22] <seb128> well it has nothing to do with lightdm
[18:22] <seb128> what about kubuntu, they used kdm for years
[18:22] <desrt> lightdm is the reason that ubuntu is still not using gdm
[18:23] <desrt> and nobody expects to use a system with gnome and kdm...
[18:23] <seb128> no, gdm is the reason why ubuntu is not using gdm anymore
[18:23] <desrt> seb128: touché :)
[18:23] <seb128> ;-)
[18:23] <seb128> but well, lubuntu used  lxce, kubuntu kdm, etc
[18:23] <desrt> unfortunately this is one of those cases where the fork convinces the original maintainers to start paying attention again and make their product better
[18:24] <desrt> so you end up with no clear winner
[18:25] <seb128> well, the point remain
[18:25] <desrt> ya.  i agree
[18:25] <seb128> desktops start depending on a specific login manager, init system, etc
[18:25] <desrt> and it's not clear that gdm would have gotten better on its own
[18:26] <desrt> maybe lightdm was necessary one way or the other...
[18:26] <seb128> so the old "you can have <n> desktop and let users log into whichever they want" is sort of over
[18:26] <desrt> seb128: ya.  i agree with that.
[18:26] <seb128> well to be fair I'm glad we have lightdm
[18:26] <desrt> it's why i think we should stop trying to support (for example) parallel installable unity/gnome
[18:26] <seb128> the other way would have been to patch gdm to no end to have an unity like look
[18:26] <seb128> which would have pissed me off for the patch and you off as a GNOME user ;-)
[18:27] <desrt> imho the unity greeter is not as smooth of an experience (to unity) as gdm is to gnome these days...
[18:27] <desrt> it's too different
[18:27] <seb128> I like it, I think it looks very nice
[18:27] <desrt> it does look nice
[18:27] <desrt> absolutely
[18:27] <desrt> but it doesn't look like unity
[18:27] <desrt> not even a little
[18:27] <seb128> but yeah, it's not the same UI as the desktop
[18:27] <desrt> well, i guess i already said that when i said "it looks nice" ;)
[18:29] <seb128> ok, on that it's time for dinner and calling it a week
[18:29] <seb128> have a good w.e everyone
[18:29] <seb128> see you next week!
[18:29] <desrt> seb128: see you monday
[18:29] <desrt> jbicha: ready to cancel gnomebuntu? :)
[18:30] <jbicha> I turn away from the computer for a minute and the conversation took a sharp detour...
[18:31] <desrt> seb makes a good point...
[18:32] <jbicha> which?
[18:32] <desrt> 14:26 < seb128> so the old "you can have <n> desktop and let users log into whichever they want" is sort of over
[18:33] <jbicha> how is it over? just because gnome-shell now hard-depends on gdm being installed?
[18:34] <desrt> jbicha: plus the systemd dependencies, plus the accounts services, plus the control center, plus the settings daemon
[18:35] <mterry> jbicha, you won't be at UDS?  bummer
[18:36] <jbicha> mterry: yeah, I wish I could go
[18:38] <jbicha> maybe I should go to Boston, I didn't apply for sponsorship though
[18:41] <desrt> pfft
[18:41] <desrt> it's in the same country
[18:41] <desrt> surely you can walk, right?
[18:54] <jbicha> lol, you're almost twice as close as I am, but it's the hotel cost I'm more concerned with
[21:24] <chrisccoulson> ah, congratulations unity webapps for being the only thing doing main-thread sqlite in firefox now
[21:24] <chrisccoulson> on every page load!
[21:24] <chrisccoulson> grrrrrrrr
[21:59] <desrt> chrisccoulson: i assume sqlite has slow blocking APIs?
[21:59] <desrt> fsync() issues?
[21:59] <chrisccoulson> desrt, that's why upstream have spent a significant amount of time removing it's use from the UI thread :)
[21:59] <chrisccoulson> and then we add it straight back again....