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