[02:13] <Burgundavia> hey popey
[06:03] <boredandblogging> alright, I'm gonna see if I can find some more stuff for the 7.10 post
[06:19] <boredandblogging> the folks at desktoplinux.com love ubuntu
[06:48] <boredandblogging> added a link to release party flickr images
[07:54] <Burgundavia> boredandblogging: which post
[07:54] <Burgundavia> ?
[08:07] <boredandblogging> Burgundavia: to the release one
[08:07] <boredandblogging> just added a couple of links
[08:07] <boredandblogging> and I posted to a couple of lists suggesting they tag their release party pictures
[08:09] <Burgundavia> ahh, ok
[08:09] <Burgundavia> I am currently editing that
[08:09] <boredandblogging> cool
[08:10] <Burgundavia> I am going to nuke the gobuntu story
[08:11] <boredandblogging> good idea
[08:11] <Burgundavia> we can do a full story on gobntu later
[08:12] <Burgundavia> alright, can you do a read through?
[08:13] <boredandblogging> yeah, hold on
[08:14] <Burgundavia> should we make the dell story a separate article?
[08:17] <boredandblogging> probably, but no harm in mentioning it in the review post.
[08:17] <boredandblogging> its looks good
[08:18] <Burgundavia> well, if we are going to pull it out, lets just do it
[08:20] <Burgundavia> are you editing the story?
[08:20] <boredandblogging> in that case, lets pull the flickr link too, once there are more pictures, we can post it separately
[08:20] <boredandblogging> no, not editing it
[08:21] <Burgundavia> right, that is a good story as well
[08:22] <Burgundavia> what a bout the debian stuff?
[08:22] <Burgundavia> is that worth another story?
[08:22] <boredandblogging> ehh, I'm not sure its worth a story at all
[08:23] <Burgundavia> I think it is, but I will yank it for another story which we can talk about on fiidge-devel
[08:23] <boredandblogging> might be better for the blog section in the UWN
[08:24] <Burgundavia> http://www.itwire.com/content/view/14937/53/
[08:24] <Burgundavia> there is a good one for the uwn
[08:25] <boredandblogging> yeah, got that one
[08:25] <Burgundavia> http://www.news.com/8301-10784_3-9799636-7.html?tag=nefd.only
[08:25] <Burgundavia> that is a good one for the UWN as well
[08:25] <boredandblogging> got that one too
[08:26] <boredandblogging> the ITN/ITB are going to be long in the UWN this week
[08:27] <Burgundavia> ok, writing Dell story right now
[08:27] <Burgundavia> that can go up tomorrow
[08:27] <Burgundavia> can you rereview
[08:27] <Burgundavia> http://fridge.ubuntu.com/node/1182
[08:27] <boredandblogging> lemme look
[08:28] <Burgundavia> if you think it is ready, it can go live
[08:29] <boredandblogging> yeah, its ready
[08:31] <boredandblogging> its live
[08:33] <boredandblogging> if you need, i can read the dell story in the morning
[08:34] <Burgundavia> sounds good
[08:34] <Burgundavia> are we live with the review story?
[08:34] <boredandblogging> Burgundavia: yeah
[08:41] <Burgundavia> ok, http://fridge.ubuntu.com/node/1184
[08:42] <Burgundavia> that needs some work, but can go live tomorrow sometime
[08:45] <Burgundavia> geez, 90% of the fr\ont page is me
[10:42] <mdke> i've tweaked that one a bit


[00:09] <TheMuso> D/c
[01:30] <veebers> Hi all, I'm having an issue with the latest quantal installer (Desktop, amd64) on the 3 machines I've tried it on it gives me this error:
[01:30] <veebers>  'The installer encountered an unrecoverable error . . .'
[01:30] <veebers> There is nothing obvious in the syslog, who would I talk to that might be able to shed some light on this?
[02:35] <thumper> veebers: so... no help then?
[02:35] <veebers> thumper: none as of yet
[03:37] <hyperair> did gvfs change its dbus method signature or somethign?
[03:37] <hyperair> https://launchpadlibrarian.net/90782792/Screenshot%20at%202012-01-22%2019%3A16%3A20.png
[05:13] <pitti> Bonjour
[05:24] <didrocks> good morning
[05:27] <pitti> bonjour didrocks! comment e'tait ton weekend?
[05:27] <pitti> err, était; compose key, wake up!
[05:29] <didrocks> guten morgen pitti! Bon week-end ici, reposant! Et toi?
[05:30] <pitti> didrocks: ici aussi; I had a kind of flashback on my cold, so again some light fever, so I spent Saturday with mostly reading and some extra sleep
[05:31] <robru> didrocks, I am just heading to bed for the night. sorry I didn't do that review that you asked, it took me longer than anticipated to get my little netbook set up with precise. it's ready to go though so I promise first thing tomorrow morning (~8hrs from now) I will do that review.
[05:31] <pitti> but felt much better yesterday, so we went to a mineral trade show (nous achetons quatre nouvelles piéces), and went for some mini-golf and table tennis
[05:33] <didrocks> pitti: urgh, at least, happy that you feel better yesterday and still could enjoy a little bit your week-end :)
[05:33] <didrocks> hey robru
[05:33] <robru> hey
[05:33] <didrocks> robru: ok, no worry, do you think you will have a look tomorrow?
[05:34] <didrocks> robru: but first, good night of sleep :)
[05:34] <robru> didrocks, yeah, first thing tomorrow. I literally just spent the last 5 hours downloading precise and installing updates. my internet was really slow today.
[05:34] <robru> g'night ;-)
[05:34] <didrocks> have a good night :)
[06:35] <pitti> didrocks: do you know whether 'myunity' is still relevant and being developed?
[06:44] <didrocks> pitti: I don't see any commit since march, let me see what they use to change the configuration keys
[06:44] <didrocks> argh, they are using gconf
[06:45] <didrocks> pitti: so, no, still using manual gconf shell, no gsettings
[06:45] <didrocks> not relevant anymore I think, why?
[06:46] <pitti> it's the only package which still holds gambas2 in the archive (which is obsolet)
[06:46] <pitti> didrocks: so, I'll remove it
[06:47] <pitti> $ remove-package -m 'does not work for current unity any more (gsettings), holds obsolete gambas2 in the archive' myunity
[06:47] <pitti> didrocks: ^ sounds ok?
[06:47] <didrocks> pitti: sounds good to me
[06:47] <didrocks> they also committed in the vcs some binary files (the myunity one)
[06:48] <ricotz> good morning
[06:49] <pitti> hey ricotz, guten Morgen
[06:49] <ricotz> pitti, hi
[06:49] <ricotz> i noticed unity-lens-applications still uses libgnome-menu instead of libgnome-menu-3-0
[06:50] <didrocks> hey ricotz
[06:50] <ricotz> didrocks, hi
[06:50] <didrocks> ricotz: let me have a look
[06:53] <didrocks> ricotz: will need some refactoring for it I guess
[06:53] <didrocks> let me check if it's feasable, thanks for the notice!
[06:53] <ricotz> didrocks, porting it would drop this library
[06:53] <ricotz> didrocks, yw
[06:53] <didrocks> ricotz: yeah, I know, checked the rdepends ;)
[07:34] <robru> didrocks, actually I can't sleep so I did that review. looks all good ;-)
[07:36] <didrocks> robru: excellent! but you should have watch tv/serie :-)
[07:36] <didrocks> robru: so, all looking good? I can push to -proposed?
[07:37] <pitti> meh, the broken type-ahead search and "enter" in unity is really annoying
[07:37] <robru> didrocks, well, I installed it and it ran well. I couldn't reproduce that bug so it looks fixed to me. I'm worried that maybe my review wasn't very thorough. is there anything specific you want me to test? any specific action or command?
[07:40] <didrocks> pitti: it doesn't do it for everyone (and not for me it seems), do you have specifics?
[07:40] <didrocks> pitti: you are the second one to mention it
[07:41] <robru> didrocks, I skimmed the diff and didn't see any version bumps (95% of the 30,000 lines was just documentation changes...), and I also used pbuilder to confirm no version bumps in build-deps at least.
[07:41] <didrocks> robru: I'll review the code itself, thanks for checking and testing the program :)
[07:41] <didrocks> excellent, perfect!
[07:41] <pitti> didrocks: I type ahead a program name ("scan"), get the correct match (simple-scan), press enter, and it opens archive-manager with some postgresql tar.gz I opened last week
[07:41] <robru> didrocks, yeah, no obvious problems to me.
[07:41] <robru> you're welcome ;-)
[07:41] <didrocks> robru: now take a shower/relax/get sleep! ;)
[07:41] <robru> didrocks, haha, ok, goodnight again ;-)
[07:41] <pitti> didrocks: it seems to pick a random result from the "previous files" matches
[07:41] <pitti> not the top left one
[07:42] <pitti> didrocks: and that postgresql.tar.gz isn't even in the displayed matches
[07:42] <didrocks> pitti: I'll ping mhr3 once he's around
[07:42] <didrocks> pitti: only on the dash home?
[07:42] <pitti> I just tried it again, now it opens rhythmbox
[07:42] <pitti> didrocks: yes
[07:42] <didrocks> ok, so it pick the files instead of applications result
[07:42] <pitti> now it plays Queen's "the miracle"
[07:42] <pitti> WTH
[07:42] <didrocks> exactly the same case xclaesse described me last friday
[07:42] <pitti> I haven't listened to that in ages
[07:43] <didrocks> pitti: you wanted that without knowing it! :)
[07:43] <pitti> didrocks: and not even matches that apply to the search apparently
[07:43] <didrocks> defintively can't reproduce that, I think mhr3 will need to debug that with you
[07:43] <pitti> I'd be happy to
[07:46] <xclaesse> ah cool, I'm not the only one :D
[07:46] <pitti> drives me nuts :)
[07:50] <pitti> mvo: guten Morgen!
[07:50] <pitti> mvo: https://code.launchpad.net/~mvo/software-properties/dep8/+merge/121378 LGTM now, do you want to upload yourself?
[07:50] <mvo> pitti: sure, will do, thanks!
[08:03] <Laney> ahoy
[08:03] <pitti> hey Laney, how are you/
[08:03] <pitti> ?
[08:03] <Laney> good!
[08:03] <Laney> went to the London office this weekend for global jam, was fun
[08:04] <Laney> you?
[08:07] <pitti> Laney: quite okay; had a rather quiet weekend, still fighting the leftovers from my cold; but we had marvellous summer weather, so went for some mini-golf, table tennis, and enjoying the sun
[08:11] <Laney> ah, nice, we had a lot of sun too
[08:16] <czajkowski> morning
[08:16] <didrocks> mhr3: hey hey!
[08:16] <mhr3> didrocks, hola
[08:16] <didrocks> mhr3: I have to both you for 2 reasons this morning :)
[08:16] <czajkowski> jibel: is it you I should poke over the power icon ?
[08:17] <mhr3> didrocks, /me waves hand "no you dont"
[08:17] <czajkowski> *indicator
[08:17] <didrocks> mhr3: your jedi power are weaks apparently :)
[08:17] <pitti> hey mhr3, how are you?
[08:17] <didrocks> mhr3: first thing: bug #1048503
[08:17] <ubot2> Launchpad bug 1048503 in unity-lens-applications "Transition to libgnome-menu-3-0" [Undecided,New] https://launchpad.net/bugs/1048503
[08:17]  * pitti moves that "s" a little to the left
[08:17] <didrocks> mhr3: the API changed a lot :/
[08:17] <didrocks> so I guess too late for quantal
[08:17] <jibel> czajkowski, you can alway poke me, not sure I'd be of any help though :)
[08:18] <czajkowski> jibel: https://bugs.launchpad.net/ubuntu/+source/indicator-power/+bug/1048041
[08:18] <ubot2> Launchpad bug 1048041 in indicator-power "Power icon doesn't show it is charging when it's plugged in" [Undecided,Confirmed]
[08:18] <czajkowski> Laney: Avi also lost his window management during the upgrade, I don't feel as special any more :)
[08:18] <mhr3> uh oh, pitti pinging dash
[08:18] <Laney> heh
[08:19] <pitti> mhr3: it seems pressing enter on the dash is now a Roulette game? :-)
[08:19] <jibel> not me. I'm just a tester. anyone else to help czajkowski ?
[08:19] <czajkowski> ah ok
[08:19] <czajkowski> was sure I heard a J to be poked oh well.
[08:19] <czajkowski> Laney: at least he knew to go to tty1 to continue so all was not lost
[08:19] <Laney> upstream probably hang out in #ubuntu-unity
[08:20] <Laney> czajkowski: which bug is that?
[08:20] <Laney> bug #
[08:20]  * Laney will rls-q-incoming it
[08:20] <didrocks> mhr3: did you see my question?
[08:21] <didrocks> mhr3: or really ignoring me now? ;-)
[08:21] <czajkowski> Laney: never reported the having to go to tty1 to continue the upgrade as loss of window management as not sure how or what to report it against
[08:21] <Laney> probably compiz
[08:21] <czajkowski> ah logged all of them
[08:21] <didrocks> pitti: come on! I started to go fishing for mhr3 with an easy one first, don't jump to the second one :)
[08:22] <pitti> didrocks: I didn't! I was only saying hi :)
[08:22] <didrocks> heh
[08:25] <didrocks> pitti: see, we lost him now, we have to change our bait ;)
[08:28] <mhr3> sorry guys, we're dismantling the office here :)
[08:29] <mhr3> pitti, so yea, it is you guys didn't apply me patch
[08:29] <mhr3> didrocks, so what's up with gnome-menu?
[08:29] <pitti> mhr3: office> err, what? underneath your feet and workstation? :-)
[08:29] <mhr3> you want to get rid of it and apps lens is using it?
[08:30] <mhr3> pitti, /me in london ;)
[08:30] <didrocks> mhr3: would be cool to transition to gnome-menu3 at some point, unity-lens-application is the latest thing retaining libgnome-menu2 on the default install
[08:30] <mhr3> didrocks, i actually think we might be able to use gio itself, in the past it was missing some apis, but they should be there by now
[08:31] <didrocks> mhr3: ok, well, 13.04 materials I guess
[08:31] <mhr3> didrocks, your call :)
[08:31] <didrocks> mhr3: I think you have better to do
[08:31] <didrocks> like… fixing pitti's and xclaesse's issues :)
[08:31] <didrocks> which are the same (can't reproduce there though)
[08:32] <pitti> mhr3 | pitti, so yea, it is you guys didn't apply me patch
[08:32] <didrocks> (I hope you liked the transition!)
[08:32] <pitti> seems there might already be a solution?
[08:32] <mhr3> pitti, https://bugs.launchpad.net/unity/+bug/1041583
[08:32] <ubot2> Launchpad bug 1041583 in unity "[regression] Dash - Hitting enter after opening Lens or searching no longer opens first item" [High,Fix committed]
[08:32] <pitti> mhr3: cheers!
[08:33] <didrocks> ok, was committed during my holidays :)
[08:33] <didrocks> pitti: xclaesse: I'm backporting it
[08:33] <mhr3> didrocks, it even got linked to the ffe branch, so i thought it's cherrypicked, but apparently it isn't
[08:34] <didrocks> mhr3: hum, ffe branch?
[08:34]  * didrocks wasn't here, remember…
[08:34] <mhr3> didrocks, Related branches: lp:~sil2100/unity/ubuntu_ffe1
[08:35] <didrocks> mhr3: hum, this branch is merged
[08:36] <didrocks> mhr3: but your commit in unity is post-release?
[08:36]  * didrocks looks
[08:36] <mhr3> didrocks, it was in between sil making tarball and the release
[08:37] <didrocks> argh, and as there is no tag on the mainline
[08:37] <didrocks> sil2100: do you have any input here? ^
[08:37] <didrocks> I don't know how they could have released that, without tag on mainline…
[08:37] <didrocks> so confusing
[08:38] <didrocks> mhr3: I confirm the branch merge successfully in the packaging
[08:38] <didrocks> so it wasn't bundled in…
[08:38] <didrocks> mhr3: as it seems you are more aware on what happens than popey's team, do you know of any other post/pre-release fixes?
[08:38] <didrocks> mhr3: so that I can check if there are in or not
[08:42] <mhr3> didrocks, there were a few of them, duflu was tagging them as fix released, and then reverting to fix committed
[08:42] <mhr3> not all are that critical though
[08:42] <didrocks> so only this one to really backport for now?
[08:43] <mhr3> no other issues come to mind atm
[08:43] <didrocks> mhr3: trusting you, thanks! :)
[08:43] <mhr3> didrocks, you shouldn't here, really :P
[08:43] <mhr3> it's not like i'm running the Q version :)
[08:44] <didrocks> mhr3: well, if things go bad, I'll ask for the people dismantling the office to break the ground you are on :)
[08:45] <mhr3> uh oh :)
[08:50] <sil2100> didrocks: yes, that's a mess as well :( Since the tag was supposed to get merger into trunk from the release-quantal branch, but then Mirv wanted to quickly fix the tagging and just tagged the last commit from the tarball
[08:51] <sil2100> So, in the end, the release branch wasn't really merged in, since then there was a conflict in tags
[08:52] <didrocks> ok, I'm testing this branch with the fix
[08:52] <didrocks> but I don't get the issue personnaly
[08:54] <psivaa> hello, we are getting the crash https://pastebin.canonical.com/74102/ often during our p2q desktop upgrade tests, could some one tell me if there already a bug for it so that i could attach the crash log/ or if there isn't i could report a new bug
[08:58] <didrocks> psivaa: the heap doesn't help a lot, can you let apport reporting the crash?
[08:58] <didrocks> so that it will get retraced and so on
[08:59] <psivaa> didrocks,  ok, i could try that, but this is an automated test so not sure how we'll be able to do that
[08:59] <didrocks> psivaa: after the upgrade, you should have a /var/crash/*colord*crash
[09:00] <didrocks> report this one with ubuntu-bug -c <file>
[09:00] <psivaa> didrocks, https://jenkins.qa.ubuntu.com/view/Quantal/view/Upgrade%20Testing%20Dashboard/job/quantal-upgrade-precise-desktop/139/ARCH=i386,LTS=non-lts,PROFILE=desktop,label=upgrade-test/ is the jenkins job for that
[09:01] <psivaa> didrocks, ill try that, thanks
[09:03] <dpm> hi pitti, good morning. I just noticed that banshee appears untranslated in quantal. Looking at the langpack export tarball from the full langpack we shipped recently, the .po file is there. But it seems to disappear from the generated source packages langpack-o-matic generates. Banshee is using the 'enable universe translations' feature, which seems to be working for LP imports and exports.
[09:04] <dpm> Do you know if there is anywhere in langpack-o-matic where universe .po files are discarded or blocked?
[09:07] <pitti> dpm: hm, not off-hand, let me look
[09:07] <dpm> thanks
[09:08] <pitti> hm, no, it reads universe package lists, too
[09:08] <pitti> dpm: perhaps it's not in the domain map that LP exports?
[09:08] <pitti> WARNING: unknown translation domain: banshee
[09:08] <pitti> yep
[09:09] <pitti> (from the log file)
[09:09] <dpm> pitti, I'm not familiar with the domain map. Do you know off the top of your head which file from the export is?
[09:09] <pitti> so it's missing in domain_map.txt in the LP tarball
[09:09] <dpm> ok
[09:09] <pitti> that maps package names to domains
[09:10] <dpm> pitti, bummer, so this would require a change in LP
[09:10] <pitti> hang on, I'll see whether we can hack around it
[09:11] <dpm> pitti, excellent, thanks. If it proves to be difficult to hack around it, I think we've got more chances to get this fixed if we disable Banshee translations in LP and ship them in the package.
[09:11] <pitti> we need it mostly to determine whether a domain should go into -gtk, -kde, or the normal ones
[09:12] <pitti> dpm: we have a classify-overrides for packages; we could add a similar one for domains, but that's just playing catch-up when we'll get more of those packages; so it needs to be fixed in LP eventually
[09:13] <pitti> dpm: but I'm fine with adding a hack for banshee so that we don't need to revert this again
[09:15] <dpm> pitti, sounds good to me. If we need to add more, then we should look into fixing it in LP. I think if it's doable to do the override for banshee, I'd suggest that, as we already talked to upstream about enabling translations in LP and they were fine with it. I'd rather keep it like that if possible, than telling them that it actually doesn't work
[09:15] <didrocks> pitti: I don't see any regression with the patch backported, do you want to gibe it a run (amd64)?
[09:15] <pitti> didrocks: sure, I'd love to
[09:16] <didrocks> pitti: http://people.canonical.com/~didrocks/unity/
[09:17] <pitti> dpm: done, see "bzr diff" on macquarie in langpack-o-matic/
[09:17] <dpm> cool, thanks pitti!
[09:26] <dpm> pitti, filed bug 1048556 about it
[09:26] <ubot2> Launchpad bug 1048556 in launchpad "Language pack translations export needs to add universe packages to domain map" [Undecided,New] https://launchpad.net/bugs/1048556
[09:28] <pitti> dpm: thanks, subscribed and added a coment
[09:28] <dpm> cool
[09:31] <didrocks> dpm: tell me once you got a chance to test it
[09:32] <pitti> mhr3, didrocks: il fonctionne trés bien, merci beaucoup!
[09:32] <didrocks> pitti: super! je le pousse dans la distro :-)
[09:32] <didrocks> xclaesse: FYI ^
[09:33] <didrocks> thanks mhr3 :)
[09:33] <xclaesse> didrocks, I'm back on gnome-shell /o\
[09:33] <didrocks> xclaesse: come on! with all the good things you told the other day on unity? :)
[09:34] <xclaesse> a bug count as a "good thing" ?
[09:34] <dupondje> xclaesse: try locking your screen with lightdm as wm :p
[09:34] <dpm> didrocks, that will probably be in the next full language pack export. New delta language pack builds are scheduled for Wednesday and Friday (https://dev.launchpad.net/Translations/LanguagePackSchedule), but new templates are only exported in full language packs. We should probably do a full langpack soon, as I approved a bunch of new templates recently
[09:35] <xclaesse> dupondje, I've switched to gdm since I've heard gnome-shell needs it
[09:35] <didrocks> dpm: I think you wanted to talk to pitti :) (otherwise, I don't konw what you mean by "that")
[09:36] <pitti> dpm: ack, thanks
[09:36] <dpm> didrocks, ah, then I think you pinged the wrong person ;) ^^
[09:36] <pitti> yeah, I think dpm wanted to ping xclaesse and me
[09:36] <dpm> and me too, as I wanted to also ping Martin :)
[09:36] <didrocks> dpm: oh right, d is so close to p
[09:37] <didrocks> hem :)
[09:37] <didrocks> dpitti? ;)
[09:37] <pitti> ... on any weird French keyboard layout near you, presumably!
[09:37] <dpm> :-)
[09:38] <didrocks> you meant, "amazing", not "weird" I guess, let me fix that for you :)
[09:42] <pitti> j'aime apprende français, mais pas le clavier français -- c'est mauvais!
[09:43] <didrocks> :)
[10:42] <Laney> can we silence the warnings from glib's trigger now?
[10:43] <Laney> I don't see that any of them are going to be fixed from nwo to release
[10:44] <pitti> is that FFE material? I thought it was just fixing an internal string?
[10:45] <Laney> I mean the schema warnings
[10:45] <pitti> yes, me too
[10:45] <Laney> I hadn't anticipated it needing FFe
[10:49] <pitti> right
[10:49] <pitti> but anyway, no objection (and I think that's fine for Debian experimental as well)
[10:51] <Laney> yeah
[11:06] <xnox> Any plans to upgrade gnome-settings-daemon?
[11:06]  * xnox should check latest version first, one sed.
[11:06]  * xnox should check latest version first, one sec
[11:07] <Laney> no
[11:07] <xnox> Laney: ok, the atk-bridge warning is comming from it, because in gtk3.5 it's a shared lib.
[11:07] <xnox> Laney: Can we cherry-pick a patch to fix that up?
[11:08] <Laney> sure, do you have one in mind?
[11:08] <xnox> hmm... let me look.
[11:08] <Laney> you might be able to try gsd from ricotz's ppa
[11:11] <chrisccoulson> pitti, remember our conversation in orlando about supporting firefox on the LTS, wrt new dependencies added by upstream?
[11:11] <chrisccoulson> i just saw this: https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.platform/djN02O03APc
[11:11] <chrisccoulson> bumping the minimum python version to 2.7 ;)
[11:11] <chrisccoulson> (which doesn't exist in 10.04)
[11:13] <xnox> Laney: hmm...
[11:17] <MCR1> ricotz: AFAIR you are the xorg expert - Are you aware of constant visual lockups on Quantal ?
[11:18] <MCR1> ricotz: Hi, btw. :)
[11:18] <MCR1> didrocks: Do you know about this ^^
[11:19] <Laney> #ubuntu-x is the X channel ;-)
[11:19] <ricotz> MCR1, hi, i am not a xorg expert ;)
[11:19] <ricotz> yeah, what Laney said
[11:19] <didrocks> MCR1: you should try #ubuntu-x as Laney told you :)
[11:19] <MCR1> okidoki, thx
[11:19] <didrocks> MCR1: and not that I know of (for those lockups) ;)
[11:21] <MCR1> didrocks: They are hardcore critical - the display completely locks mainly when doing larger file operations - those continue to work in the background at least, sound etc. all continues to run, but the display freezes except for the mousepointer
[11:21] <ricotz> didrocks, btw, i hope the mesa revert can be reverted again ;)
[11:21] <didrocks> ricotz: not until the fix is in :)
[11:21] <MCR1> didrocks: all you can do is reboot via VT
[11:21] <didrocks> MCR1: please, discuss that with RAOF and bryceh, and keep me in touch
[11:21] <MCR1> ok
[11:21] <ricotz> didrocks, so the problem is properly reported and known to upstream?
[11:22] <ricotz> didrocks, irc, some netbooks failing?
[11:22] <didrocks> ricotz: tjaalton is working on it to see what commit broke it first
[11:22] <ricotz> didrocks, ok, thanks
[11:22] <didrocks> yw :)
[11:43] <pitti> chrisccoulson: uh, firefox needs python?
[11:44] <pitti> chrisccoulson: so we'll need to get that into lucid-updates?
[11:44] <chrisccoulson> pitti - yeah, only for building though. the build system has a lot of python now
[11:45] <MCR1> didrocks: I've reported it now (the visual lockup).
[11:45] <didrocks> MCR1: thanks! :)
[11:45] <MCR1> didrocks: Another question: How can I get in touch with the kernel team ?
[11:45] <didrocks> MCR1: #ubuntu-kernel should be the more straightforward way
[11:46] <MCR1> ok, thx - Kernel 3.6 breaks SSL completely (tried 3.6-RC1 and RC4)
[12:36] <pitti> is that just me, or is "online accounts" bothering other people about re-logging into Google twice a day?
[12:37] <larsu> pitti, twice? It's asking me ever 2h or so :-/
[12:37] <pitti> or that
[12:37] <larsu> does it open a browser tab for you too?
[12:38] <pitti> yes, some 5
[12:38] <larsu> yeah, it seems to open one for every failed attempt until you log in again
[12:39] <larsu> I recently switched to two-factor auth - maybe that's it?
[12:40] <pitti> no, when I go to online accounts and re-login, I just need to click "ok", not enter any creds
[12:40] <pitti> that works fine
[13:15] <dpm> pitti, I was just going to ask the same about online accounts opening tabs. For me it opens a http://gwibber.com/0/auth.html#access_token=... tab, which loads a blank page, so there's not much that I can do.It wouldn't bother me much if it didn't happen that frequently and especially if it didn't steal the focus. Does anyone knows a workaround? I'll disable the online accounts for now
[13:16] <dpm> actually, it's not a blank page, it says "Authorization complete."
[13:16] <dobey> pitti: hey, does distutils-extra auto.setup() support multiple po directories?
[13:17] <pitti> dobey: no, not right now
[13:17] <pitti> and that sounds a bit complex to automatically figure out?
[13:18] <dobey> well, i haven't looked at the code yet, so i don't know how it currently determines what to use for the GETTEXT_DOMAIN
[13:19] <dobey> but probably not that hard to do if the code is already reasonably smart
[13:19] <dobey> i was just wondering because if it did support it, then it'd be easier than merging 2 sets of po files into one set
[13:20] <pitti> dobey: you can specify it as an option of the build_i18n command class; if not given, it defaults to the project name
[13:26] <didrocks> jdstrand: hey, are you around?
[14:08] <davidcalle> dednick, hey, I don't know if you have noticed, but I've added some precise info on what triggers : https://bugs.launchpad.net/unity/+bug/1039437
[14:08] <ubot2> Launchpad bug 1039437 in unity "[previews] Previews text is blank or black, when some characters are present" [Undecided,New]
[14:09] <didrocks> MCR1: you are using unity staging, right?
[14:09] <MCR1> didrocks: yep
[14:09] <dednick> davidcalle: thanks. I'll take a look at it when i get a chance.
[14:09] <didrocks> MCR1: your freezes started today?
[14:10] <davidcalle> dednick, np
[14:10] <MCR1> nope, yesterday or the day before (not 100% sure)
[14:10] <MCR1> but it started with the latest xorg and mesa updates
[14:10] <didrocks> MCR1: the 2912-09-07? :)
[14:10] <didrocks> I wonder if it's not unity which is guilty
[14:11] <MCR1> 2912 ?
[14:11] <didrocks> MCR1: can you try to revert that one: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/2673
[14:11] <didrocks> rev 2673
[14:11] <didrocks> 2012*
[14:11] <didrocks> same ;) 2912 isn't that far away :-)
[14:11] <didrocks> so revert rev 2673 in trunk
[14:11] <didrocks> and tell me if it's any better
[14:12] <MCR1> didrocks: Sorry I have already updated mesa and libdrm, so I won't be able to tell if it was r2673...
[14:13] <didrocks> MCR1: well, you can revert unity and rebuild it, right?
[14:13] <didrocks> pretty sure it's the cause, and not mesa, nor libdrm
[14:14] <MCR1> didrocks: If I do nothing then and still will experience lock-ups we will know that it is not mesa's and libdrm's fault...
[14:15] <didrocks> hum?
[14:15] <didrocks> I don't get you
[14:15] <didrocks> some other people reported that the a11y on by default in unity is the cause
[14:15] <didrocks> I want to confirm that it's what you are experiencing
[14:15] <didrocks> hence, if you can try to revert this revision, build unity and try with it, it would be helpful :)
[14:16] <didrocks> (as you contributed quite a lot to unity, I assume you know how to build it :))
[14:16] <MCR1> didrocks: I have already updated mesa and libdrm, so if I will still experience the lockups we will know that something else is causing them
[14:16] <didrocks> MCR1: like unity :)
[14:16] <MCR1> Sure, but since a few days I have trouble with some new Compiz dependency when compiling Unity and my script fails
[14:17] <didrocks> MCR1: please, keep me posted!
[14:17] <MCR1> didrocks: I will reboot and ofc keep you informed - brb
[14:18] <MCR1> didrocks: and if the lockups are still reproducable I will revert 2673 and try that...
[14:18] <didrocks> excellent!
[14:18] <MCR1> brb
[14:20] <MCR1> back
[14:21] <didrocks> wb
[14:28] <MCR1> didrocks: One big thing that stops me from contributing larger fixes which need testing is that I have not found an ideal workflow to replace the running versions of Compiz/Unity with my compiled ones...
[14:29] <didrocks> MCR1: yeah, I know, there is no good way to not screw your install, please make the unity team aware about that
[14:32] <MCR1> didrocks: Seems you were right again - just experienced another lockup with the new mesa libdrm installed...
[14:32] <MCR1> didrocks: So it is probably Unity (like you suspected)
[14:33] <MCR1> didrocks: I can verify this by for example disabling unityshell in ccsm and then starting my build scripts again...
[14:33] <MCR1> didrocks: If they fail again it is not Unity's fault
[14:33] <didrocks> MCR1: yeah, or just switch to another session like classic GNOME…
[14:33] <didrocks> indeed
[14:33] <MCR1> if then else is quite easy
[14:33] <MCR1> :)
[14:33] <didrocks> heh ;)
[14:33] <MCR1> good idea
[14:35] <MCR1> once you disable Unity Compiz speeds up massively
[14:38] <MCR1> didrocks: Just had another lockup with unityshell disabled via CCSM
[14:38] <MCR1> so it is not Unity either
[14:38] <didrocks> ok, worthed a try
[14:38] <MCR1> sure
[14:38] <MCR1> but grmpf
[14:38] <didrocks> MCR1: thanks for the testing, wait for bryce_h and raof now I guess
[14:38] <MCR1> np, yw
[14:54] <jcastro> hey didrocks
[14:55] <jcastro> can gsettings keys be language specific?
[14:55] <jcastro> so like, if it's english, turn on the AU scope?
[14:55] <didrocks> jcastro: not really, apart if we make a package per distro and have the langpack dep on it
[14:55] <jcastro> ok
[14:55] <jcastro> just wondering
[14:55] <didrocks> jcastro: but it seems worse than having the gsettings key to override the automatic detection
[14:55] <jcastro> but you probably already had thought of that
[14:56] <didrocks> yeah, I would say:
[14:56] <didrocks> - automatic language detection for askubuntu.com
[14:56] <didrocks> - and a gsettings key to "force" showing it
[14:56] <dobey> oh great
[14:57] <dobey> firefox stopped pretending i was in AU, and instead decided that now my spelling should be en_CA
[14:57] <dobey> at least it's geographically closer, i guess
[14:57] <didrocks> dobey: congratulation for moving :-)
[15:01] <doko> pitti, cyphermox, who can I pester about telepathy-glib requiring a valac version not yet in quantal?
[15:02] <Laney> urgh
[15:02] <cyphermox> that's going to be fun :)
[15:02] <Laney> no, that's not true
[15:02] <Laney> he just should have BDed on valac-0.18
[15:03] <Laney> doko: change that, then it should work
[15:06] <micahg> can libpeas and zeitgeist-datahub switch to vala 0.16 or 0.18 so 0.14 can drop out of main?
[15:07] <didrocks> micahg: libpeas -> needs testing, zg-datahub: mhr3?
[15:07] <didrocks> micahg: if you can perform the test for those, you are welcomed
[15:08] <didrocks> doko: telepathy-glib trunk requires 0.17.6, isn't it?
[15:08] <didrocks> so yeah, build-dep on valac-0.18, I ensured and checked that with upstream before they did the change in trunk
[15:08] <didrocks> so nobody to pester :)
[15:08] <doko> didrocks, well, the buildds do think otherwise ...
[15:09] <Laney> no they don't
[15:09] <Laney> it build-deps on vala (>= 0.18)
[15:09] <Laney> valac*, which is not the same as valac-0.18
[15:09] <doko> http://qa.ubuntuwire.com/ftbfs/ shows a dep-wait
[15:09] <didrocks> isntead of valac-0.18
[15:09] <didrocks> Laney: doko: I'm handling it
[15:09] <didrocks> packaging error simply
[15:09] <didrocks> doko: vala is versionned in its binary name
[15:09] <doko> didrocks, hmm, too late, already uploaded after Laney's hint
[15:09] <didrocks> (package binary name)
[15:10] <didrocks> ah perfect then :)
[15:10] <Laney> there's a 'default' real package valac
[15:10] <Laney> but 0.18 doesn't provide it yet
[15:10] <didrocks> yeah, which is 0.16
[15:11] <didrocks> Laney: not even sure we can switch to 0.18 this cycle as "valac" TBH, seems as usual, the new vala brings some changes, and not sure we can rebuild everything valac rdepends
[15:11] <didrocks> I mean we can, but we have better to do IMHO :)
[15:11] <Laney> no I wasn't expecting to do so
[15:11] <didrocks> yeah, let's stay on the safe side
[15:11] <Laney> 0.14 still provides the unversioned one though; should drop that
[15:12] <didrocks> right, can do it if you want
[15:12] <Laney> will do
[15:12] <didrocks> perfect, thanks Laney :)
[15:12] <Laney> pretty sure it would cause problems if 0.14 had to be uploaded for some reason
[15:12] <didrocks> Laney: you meant "wouldn't"?
[15:12] <Laney> no
[15:12] <didrocks> ah
[15:12] <didrocks> after the fact
[15:13] <didrocks> yeah
[15:13] <didrocks> it will override 0.16
[15:13] <didrocks> thanks for spotting btw :)
[15:13] <micahg> no, it would just fail to upload due to a higher binary version being in the archive
[15:13] <Laney> indeed
[15:13] <Laney> that's a problem in my opinion :P
[15:13] <micahg> yes, it is :)
[15:13] <didrocks> yeah, it's a pb :)
[15:14] <didrocks> micahg: btw, what about chromium update in precise?
[15:14] <didrocks> micahg: I saw a lot of users on forums complaining about the outdated version
[15:14] <micahg> didrocks: I think I found a regression
[15:14] <micahg> 20 is in the security proposed PPA, but it looks broke
[15:14] <didrocks> even at the time of chromium 19? (it's still on 18, right?)
[15:16] <mhr3> didrocks, datahub trunk is using 0.16 iirc
[15:17] <mhr3> might be working without any changes even, i dont remember
[15:17] <mhr3> if not, then a single patch will be needed
[15:18] <didrocks> ok, thanks mhr3, we'll do next upload with the switch I guess :)
[15:19] <mhr3> didrocks, good luck, we have the vala+makefile-distropatch for datahub :)
[15:20] <didrocks> mhr3: I like challenges ;)
[15:20] <didrocks> but when I'll have time for it
[15:21] <mhr3> didrocks, plus john wants changes to that patch
[15:21] <didrocks> so you want to make my life hard? anyway, let's see if I have time for this… ;)
[15:22] <didrocks> mhr3: which changes btw?
[15:22] <mhr3> didrocks, https://bugs.launchpad.net/ayatana-design/+bug/1045257
[15:22] <ubot2> Launchpad bug 1045257 in ayatana-design "Dash - Pre-populate app usage history in zeitgeist, so that when the Dash home is opened for the first time after a fresh install, all apps that are not pinned to Launcher and displayed under the 'Applications' category header." [Medium,Fix committed]
[15:22] <micahg> didrocks: meh, can't reproduce, I'm copying it to proposed now
[15:22] <micahg> *chromium 20 that is
[15:22] <didrocks> sweet :)
[15:23] <Laney> is this going to break webapps ;-)
[15:23] <micahg> idk, it's precise and webapps isn't in the archive ;)
[15:30] <doko> didrocks, hmm, think, still wants the unversioned valac package. maybe just change the order of the alternatives?
[15:31] <micahg> yeah, that's the OR bug in launchpad-buildd
[15:32] <Laney> yeah just get rid of the alternative
[15:32] <micahg> bug 594916
[15:32] <ubot2> Launchpad bug 594916 in launchpad-buildd "buildd does not install alternate dependency for versioned ORed build-dependencies" [Low,Triaged] https://launchpad.net/bugs/594916
[15:32] <didrocks> doko: yeah, it's looking weird. I would go for removing the alternative as well
[15:33] <didrocks> but build-dep valac-0.18 on 0.17.6 please
[15:33] <didrocks> micahg: nice catch!
[15:34]  * micahg should just buy infinity some cookies at UDS and get it fixed
[15:34] <didrocks> cookies are enough for infinity? He's cheap :)
[15:35] <jbicha> mterry: I'm curious what ubuntuone recommends deja-dup really needs, deja-dup is part of ubuntu-gnome-desktop but we're not including the u1 qt control panel
[15:35]  * Laney giggles at the optimistic comment about using a new, normal sbuild
[15:37] <mterry> jbicha, so the deal there is that deja-dup detects if U1 is installed, and if it is, will default to it.  If it is installed, it uses several bits of it (asks it how much free space is there) and has duplicity use its python bindings for logging in and uploading/downloading.
[15:37] <mterry> jbicha, the (I think 3?) Recommends it currently has are sufficient and necessary for its U1 support
[15:38] <mterry> jbicha, if any of them aren't installed, it won't offer the option in the UI (unless you've explicitly told it to use U1 I believe)
[15:39] <mterry> jbicha, what was your question?
[15:46] <jbicha> mterry: because we include deja-dup, we get all of deja-dup's recommends too; but since we aren't installing the normal U1 control panel, the U1 dependencies may not be needed
[15:46] <micahg> mterry: I think that qualifies as suggests + add to desktop seed, there doesn't seem to be anything unusual about not having U1
[15:46] <mterry> jbicha, we is the GNOME remix team?  Well, do you want U1 support at all?
[15:47] <jbicha> yes
[15:47] <mterry> micahg, tend to agree
[15:47] <jbicha> maybe U1 should depend on those bits that deja-dup wants then?
[15:47] <mterry> jbicha, sorry, yes to first or both questions?
[15:47] <jbicha> sorry, yes to first, not really for second
[15:49] <mterry> jbicha, OK, but you might want another default.  Like Amazon S3 support?  I believe otherwise it just defaults ~/deja-dup.  Neither S3 or ~/deja-dup are terribly user friendly defaults.  That's one reason I was so excited to add U1 support, because it is a cloud DD's target audience can use
[15:49] <mterry> jbicha, if you want to enable S3 by default, you'd just have to add that Suggests from deja-dup to your seed
[15:49] <micahg> mterry: would installing those options on demand be possible (maybe not this cycle as it's late), I forget what that tool is called
[15:51] <mterry> micahg, sure...  it's possible...  But I think mpt or someone requested that we don't do that, as it clutters the menu with possible-but-disabled options
[15:51] <mterry> micahg, that's what the Add-Ons section in Software Center is for
[15:52] <micahg> well, addons != built-in but disabled functionality
[15:52] <micahg> mterry: but in that light, you could create a U1 dep meta package with enhances: deja-dup
[15:52] <jbicha> mterry: ok, ubuntu-gnome-desktop can depend on python-cloudfiles like Fedora does
[15:52] <mpt> micahg, installing things on demand = sessioninstaller?
[15:53] <mterry> jbicha, yeah, S3 by default is (IMO) better than ~/deja-dup by default
[15:53] <micahg> mpt: yeah, that's the one :)
[15:53] <jbicha> I have to admit I haven't really used deja-dup much, but besides U1, it can also do local or SSH or that other cloud stuff
[15:54] <mterry> jbicha, right.  It supports U1, S3, and rackspace as clouds.  Plus anything GNOME can connect to
[15:54] <mterry> (and has special support for removable drives)
[15:55] <mterry> jbicha, OK, so anyway, sounds like we agree.  GNOME remix adds python-cloudfiles, I drop the recommends to suggests and add them to the desktop seed
[15:55] <jbicha> mterry: that would be great, thanks!
[15:56] <jbicha> Ubuntu GNOME's bumping up against the 800MB line so I'm verifying what we want and need
[15:57] <micahg> jbicha: Ubuntu GNOME isn't required to stay at 800MB
[15:57] <jbicha> micahg: right but it's a nice size for now
[16:10] <mterry> jbicha, is there a way for your seed to ignore a recommends like U1 for deja-dup?  I'm thinking about it, and let's say you're in some Xubuntu or something.  And you install Deja Dup.  I'd still like U1 to be the default in such cases
[16:11] <micahg> xubuntu doesn't ship U1 since it uses Qt
[16:12] <jbicha> mterry: I don't think the seeds & metapackages allow for blacklists like that :(
[16:13] <micahg> mterry: I think a metapackage like deja-dup-ubuntuone with the deps + enhances is the best option for that short of using sessioninstaller
[16:13] <mterry> micahg, fair, it's not by default.
[16:13] <mterry> micahg, but U1 is really the best cloud offering for consumers, which DD targets.
[16:14] <mterry> micahg, I understand that GNOME remix wants to ship DD by default and use a default I don't personally recommend, but I'd like the rest of Ubuntu (the project)'s users to get the best default
[16:14] <jbicha> mterry: not for Fedora users ;)
[16:14] <mterry> jbicha, right, and they have to slum it with S3 by default.  But Fedora can run U1 on the client if they really wanted to
[16:14] <mterry> jbicha, that's neither here nor there though
[16:15] <mterry> This is about what Ubuntu's packaging defaults to
[16:16] <mterry> micahg, I also agree little baby metapackages like deja-dup-backend-u1 or deja-dup-backend-s3 would be nice.  But never got around to it.  That's just syntactic sugar here though, and wouldn't help with seeding blacklisting
[16:16] <jbicha> U1 is great but personally I don't like its UI, no other flavor ships U1 either
[16:17] <mterry> jbicha, again, that's fine.  But I'm considering the case of the many flavors (all others really) that don't ship deja-dup
[16:17] <micahg> mterry: it would help to drop it to a suggests, looking at the UI, what if you kept all the options in the backup location drop down, but offered to install the needed packages with sessioninstaller when selected (I guess you still need a sane default though which U1 does seem to be the best option for)
[16:17] <mterry> jbicha, when a user installs deja-dup in such a case, I don't see what's wrong with pulling in U1 client support?
[16:18] <mterry> micahg, so that's just an end run around having U1 in the install image?  I'd rather things just work when the user selects them
[16:18] <micahg> mterry: edubuntu and ubuntu are the only flavors shipping U1
[16:18] <mterry> micahg, sure.  And Ubuntu is the only flavor shipping deja-dup
[16:18] <jbicha> U1 won't just work until it is configured any way
[16:19] <mterry> jbicha, yeah, deja-dup points the user at that.  If they try to back up, a dialog comes up and starts the U1 config process
[16:19] <jbicha> so you could say that the current recommends are insufficient since they don't actually make sure the U1 Qt control panel gets installed
[16:19] <mterry> jbicha, they do
[16:20] <micahg> mterry: well, I don't see a problem with it being on the Ubuntu image, but for anyone else wanting to use deja-dup, it doesn't force them to install U1 where it might not be desired, but I see your point about a sane default which U1 seems to be the best option, so idk here
[16:20] <mterry> jbicha, I guess I'm saying is that U1-by-default is the best match with DD's mission statement.  So I'd like to not compromise that for all other users in ubuntu land
[16:21] <mterry> micahg, but I'm saying, in all other flavors, if they are already choosing to download and install deja-dup, it doesn't seem so bad to install U1 support packages along with it.  Recommends pull in stuff all the time when opting in to a packageinstalling
[16:22] <mterry> micahg, and just because U1 doesn't come by default in a flavor doesn't mean users of that flavor would actively dislike it being installed or available to use if a package can use it
[16:22] <mterry> (in the context of manually installing a 3rd party package)
[16:23] <micahg> mterry: sure, that's fine, originally I thought it didn't meet the criteria of needed in all but unusual circumstances (which is what Recommends is), but it does seem to in this case
[16:23] <mterry> micahg, well, "needed" is a strong word.  But "strongly desired by mterry"  :)
[16:24] <mterry> And best meets https://live.gnome.org/DejaDup/Mission
[16:24] <micahg> The Recommends field should list packages that would be found together with this one in all but unusual installations.
[16:26] <mterry> micahg, upstream (me) wants U1-by-default in all but unusual situations.  And in any standalone context (like, if deja-dup wasn't shipped by default), that would be sufficient.  Now, flavor owners and upstream are conflicting about what they view as unusual
[16:26] <micahg> mterry: right, as I said, I agree with you at this point that U1 is the best by default option
[16:27] <mterry> micahg, sorry I didn't mean to sound like I was beating a dead horse.  Just interested in this situation we've found.  I wish seeds allowed blacklisting in such cases.  I'm not sure how to best let everyone get what they want
[16:28] <micahg> well, if ubuntu-gnome-desktop conflicts with those recommends, they won't be installed (and never could be though)
[16:28] <mterry> Wait... Don't the meta packages have blacklist support?  I know seeds don't, but I thought the metas did
[16:29] <mterry> hm, no i guess ot
[16:29] <mterry> not
[16:29] <jbicha> mterry: ubuntu-gnome could just not recommend deja-dup too ;)
[16:29] <mterry> jbicha, that's another possibility.  It's not a GNOME project
[16:30] <mterry> jbicha, I'd love it to be in more hands, but wouldn't be upset if you didn't include it.  Though I wish inclusion merits didn't depend on the technical detail of blacklist support
[16:31] <micahg> if xubuntu wasn't so short on space, I'd suggest adding deja-dup
[16:35] <mterry> micahg, jbicha: I suppose in this case, where upstream has a strongly-favored-default-if-distributor-doesn't-care-more, what I should do is what micahg suggested (show it in drop down and install if necessary) but to assuage concerns about menu bloat, just do it for the preferred option.  That would let Ubuntu and GNOME spins work as they want, and let other flavors work well in the user-downloads-it case
[16:36] <mterry> and designers would be happy to
[16:36] <mterry> o
[16:36] <mterry> But it's too late for this cycle for that
[16:36] <jbicha> ok
[16:37] <mterry> But that doesn't give us great guidance for this cycle
[16:38] <mterry> I guess I'd weigh the number of people that get DD via GNOME remix installs vs the number of people that manually install it and see which is larger.  Not sure how to do that though
[16:40] <jbicha> I think I'm fine with waiting until next cycle for a fix
[16:41] <mterry> :)  fine
[16:41] <jbicha> since we're not using official infrastructure, I can always add a line to my build script to remove recommended packages if I really didn't want them
[16:41] <mterry> jbicha, (meaning no DD in GNOME remix?)
[16:42] <mterry> jbicha, oh really?  interesting
[16:52]  * didrocks waves good evening
[17:35] <tedg> kenvandine, Is there a way to get Gwibber to always show the images by default?
[17:36] <tedg> kenvandine, It's okay, I have enough bandwidth :-)
[17:40] <kenvandine> it isn't about that
[17:40] <kenvandine> it makes scrolling suck much more
[17:41] <tedg> Ah, hmm.
[17:43] <mterry> tedg, was it jdstrand that originally mentioned the issues with remote login by default?
[17:49] <mterry> jdstrand, I recall "the security team" saying that remote login should be disabled by default in Ubuntu installs.  Was that from you or do you know who did say that?
[18:05] <tedg> mterry, We give him 5 more minutes, if he doesn't respond it goes in ;-)
[18:06] <mterry> tedg, who else would have been involved?
[18:06] <mterry> dbarth, do you know who on the security team told us to disable remote login by default?
[18:06] <tedg> mterry, I thought it was mdeslaur, but apparently I was wrong.
[18:07] <mdeslaur> mterry, tedg: jdstrand isn't available today
[18:07] <mdeslaur> tedg: no, I only discussed NM with you
[18:07] <tedg> mdeslaur, I'm just used to you saying no to me ;-)
[18:07] <mdeslaur> what's the impact of turning this on? does it need extra packages to be installed for it to actually turn something on?
[18:08] <tedg> mdeslaur, It's more "another way to use guest accounts"
[18:08] <mdeslaur> tedg: that's because you tend to only ask when you know deep down it will be no :)
[18:08] <tedg> mdeslaur, http://gould.cx/ted/blog/Desktop_in_the_cloud
[18:10] <mdeslaur> tedg: so once you enable that, what provides the list of extra stuff in the greeter?
[18:11] <mterry> mdeslaur, those packages are already on the image.  It's remote-login-service and libpam-freerdp and friends
[18:11] <chrisccoulson> bug 969777 highlights the absolute ridiculousness of the auto-confirm feature in launchpad :/
[18:11] <ubot2> Launchpad bug 969777 in firefox "Crashed while checking pictures on yahoo groups" [Undecided,Confirmed] https://launchpad.net/bugs/969777
[18:12] <chrisccoulson> people are clearly clicking "affects me too" on any bug report, without even reading the descriptions :(
[18:13] <mdeslaur> mterry: whoa...those packages are _installed_ by default on the desktop?
[18:14] <mdeslaur> mterry, tedg: I'm going to have to defer to jdstrand on this, I believe his understanding of the packages when doing the MIR was that the packages were opt-in.
[18:14] <tedg> mdeslaur, So if it is enabled, and there is networking, then they'll see a box in the list of users that is "remote login"
[18:14] <mterry> mdeslaur, yes, but not used unless a gsettings key is on.  They've gone through MIR and security checks by jdstrand
[18:14] <mdeslaur> mterry: and this is the gsettings that tedg has proposed to turn on by default?
[18:15] <tedg> Yes
[18:15] <mterry> mdeslaur, yes.  Right now the feature is opt-in.  I recall hearing that someone from security requested it be opt-in, but we're trying to find out who
[18:15] <mterry> Because from a feature perspective, it would be neat if it was opt-out
[18:17] <mdeslaur> mterry: sure, but we need to make sure this won't be used maliciously first
[18:17] <mterry> mdeslaur, sure...  you mean above and beyond the MIR security checks?
[18:17] <mdeslaur> the MIR security checks weren't done with having this on by default in mind
[18:18] <mdeslaur> ie: we were assuming people who turn it on would be using computers as terminals
[18:18] <tedg> Seems like there is no way to use it maliciously more than having a guest account feature at all.
[18:18] <mdeslaur> tedg: if that's the case, then it won't be a big deal...but I want to get input from jdstrand as he actually did the review of them
[18:19] <tedg> You could, with a guest account, just run xfreerdp full screen.
[18:19] <tedg> mdeslaur, Makes sense.  I'll put him on review for the merge request.
[18:19] <mdeslaur> tedg: thanks
[18:22]  * tedg said that, but can't seem to make LP do it...
[18:25] <mdeslaur> tedg: file a bug, and assign jdstrand to it, and subscribe ubuntu-security please if you can't flag him on the review
[18:25] <tedg> mdeslaur, I got it, I for some reason had to resubmit it.
[18:25] <tedg> No clue why.
[18:26] <mdeslaur> tedg: cool
[21:29] <thumper> bryceh: morning
[21:30] <thumper> bryceh: re bug 1043562, shall I try editing the xorg.conf?
[21:30] <ubot2> Launchpad bug 1043562 in xserver-xorg-video-intel "[gm45] GPU lockup EIR: 0x00000010 PGTBL_ER: 0x00000001 IPEHR: 0x60020100" [High,Triaged] https://launchpad.net/bugs/1043562
[21:30] <thumper> bryceh: what is UXA and SNA?
[21:30] <thumper> bryceh: this is for my now-testing laptop, so happy to break it (ish)
[21:54] <LLStarks> thumper, sna is the new acceleration
[21:54] <LLStarks> ridiculously fast on older hardware
[21:55] <thumper> hmm... perhaps I'll try it on the old laptop
[21:57] <bryceh> thumper, should be something like this:
[21:57] <bryceh> cat /etc/X11/xorg.conf.d/20-sna.conf
[21:57] <bryceh> Section "Device"
[21:57] <bryceh> # Identifier not significant
[21:57] <bryceh>     Identifier "Integrated intel graphics"
[21:57] <bryceh>     Driver "intel"
[21:57] <bryceh>     Option "AccelMethod" "SNA"
[21:57] <bryceh> EndSection
[22:12] <thumper> bryceh: I don't have an /etc/X11/xorg.conf.d directory, should I?
[22:12] <thumper> bryceh: also I don't seem to have an xorg.conf
[22:15] <bryceh> yeah normally you don't need either so no stubs are put in
[22:15] <bryceh> you can create the dir and stick in the snippet in a new file.  Or construct your own xorg.conf.  There's a skeleton in the ubuntu-x wiki pages.
[22:19] <jdstrand> mterry: it was mdeslaur who recommended the remote desktop login be disabled by default
[22:20] <mdeslaur> jdstrand: me?
[22:20] <jdstrand> I thought so. am I misremembering? I thought you and tedg talked about it and this is what you landed on. I happen to agree (and think you asked me about it at the time)
[22:21] <mdeslaur> jdstrand: that was for the NM applet
[22:21] <jdstrand> oh, so I am misremembering
[22:21] <mdeslaur> jdstrand: I don't remember discussing the remote desktop login. I'm not sure what the impact of turning it on is, and figured you would know better since you did the MIR review
[22:22] <jdstrand> mterry: ok, it wasn't mdeslaur. I don't think there was an official recommendation from the team, but it seems it is rather specialized and not something to have enabled by default
[22:22] <jdstrand> mdeslaur: well, it is in main and supported. I think now it is in the realm of what makes the most sense
[22:23] <mdeslaur> jdstrand: so it's limited like a guest account? ie: it can't be used to subvert local login or anything?
[22:25] <jdstrand> mdeslaur: now, granted, at the time I reviewed it things barely worked and there was nothing to authenticate to, but there are different backends available. one is 'uccs' (the landscape bit), and if you setup your account to allow remote login, then you can login with that. it doesn't change your password or anything
[22:26] <jdstrand> then there is a citrix one and a freerdp one-- I didn't have servers to test those. I think we need tedg here
[22:26] <mdeslaur> jdstrand: oh hrm, I didn't know you could set up your account to log in using that...how does that work with encrypted home and stuff?
[22:26] <mdeslaur> I thought it was dynamic guest account only
[22:27] <jdstrand> it won't work with encrypted home. maybe it is only for a guest account-- like I said, I had basically only code to look at
[22:27] <jdstrand> no big picture or documentation
[22:28] <mdeslaur> awesome
[22:29] <mdeslaur> ok, well, let's let them turn it on then, and then poke holes into it afterwards I guess
[22:30] <mdeslaur> It's hard to evaluate the security of something based on code repos alone :P
[22:33] <jdstrand> indeed
[22:33] <jdstrand> we could wait on tedtooo
[22:36] <thumper> bryceh: so just creating that file will be enough?
[22:40] <thumper> bryceh: ok, have that snippet in the file, just updating and I'll reboot, and let you know if it fixes the hang
[22:44] <bryceh> thumper, you can verify by grepping your /var/log/Xorg.0.log for SNA
[22:45] <thumper> ah FFS
[22:46] <thumper> python-compizconfig fails to install
[22:46] <thumper> and is blocking any dist-upgrade
[22:46] <thumper> sub-process dpkg returned error code 1
[22:46] <thumper> and apport is telling me MaxReports is reached already


[10:55] <cjwatson> ogra_: FYI, proposed-migration only cares about regressions in installability.  Since I forced ubuntu-touch-meta to be uninstallable (by proposed-migration's definition) once, it won't require further forcing unless it becomes installable again at some point in the meantime.
[10:56] <ogra_> ah, perfect, thanks !
[10:56] <cjwatson> (And indeed AFAICS it didn't require forcing at the weekend.)
[12:52] <ogra_> sigh, seems cadejo is dead again
[12:53] <ogra_> this is getting old :/
[16:23] <cjwatson> I've added stgraber to ~ubuntu-archive, mainly on the basis that everyone already thinks he is and I'm quite confident he knows his way around.
[16:24] <Laney> nice
[19:30] <blitzkrieg3> hi, I've verified bug 887446, would someone please move it over to -updates?
[19:30] <ubot2> Launchpad bug 887446 in mtools (Ubuntu Precise) "mlabel: renaming USB stick appends "nA" to name" [Medium,Fix committed] https://launchpad.net/bugs/887446
[19:32] <stgraber> blitzkrieg3: any reason to rush it to -updates? packages are typically moved 7 days after they get into -proposed (assuming the fix is confirmed and no regression found)
[19:32] <stgraber> so in the case of this package, it'd likely be released to -updates on Wednesday
[19:33] <blitzkrieg3> stgraber: oh I didn't know it was automatic...
[19:33] <blitzkrieg3> stgraber: thanks for the clarification, Wed is fine
[19:33] <stgraber> it's not automatic, but there's still a default 7 days waiting period
[19:33] <stgraber> so SRU members don't usually look at copying things that are less than 7 days old
[19:33] <blitzkrieg3> okay, that works for me
[22:41] <phillw> hi good people, would the fix for bug 880493 be sitting in the 7 day queue, or does it need a nudge? (Obviously not for me, I'm asking on behalf of a tester).
[22:41] <ubot2> Launchpad bug 880493 in synaptic (Ubuntu Raring) "Synaptic crashes in vfprintf() with Norwegian locale" [Medium,Confirmed] https://launchpad.net/bugs/880493
[22:47] <cjwatson> No, it's waiting for manual review by ~ubuntu-sru before entering -proposed
[22:48] <cjwatson> The 7-day queue is during the verification step after it's in -proposed
[22:50] <phillw> cjwatson: so, I should ask the OP to wait 7 days and then check to see if it has arrived in proposed? (my first translations bug, as you can tell!).
[22:51] <stgraber> phillw: there's no fixed amount of time before something gets into -proposed, it'll get in there when someone has the time to review it
[22:51] <cjwatson> 7 days is irrelevamt
[22:51] <cjwatson> s/m/n/
[22:51] <phillw> ah, so it could take some time for a manual review. Sorry, I mis-read what you wrote.
[22:51] <stgraber> once it's in there, a comment will be posted to the bug report asking you to test the fix, and it's 7 days after THAT, that it'll be copied to -updates
[22:52] <cjwatson> ... if it's verified
[22:52] <stgraber> right
[22:53] <phillw> stgraber: cjwatson do you have any sort of idea of a bug with that many dupes and heat may get reviewed (obviously after vUDS!) ?
[22:53] <cjwatson> No idea sorry
[22:54] <stgraber> sorry, can't really parse that sentence, assuming the missing word is "when", then no
[22:54] <cjwatson> The SRU queue is rarely processed in any kind of order relating to dupes or heat
[22:54] <phillw> okies, thanks. at least I can tell the OP to subscribe to 'master' bug, as he quoted me one of the dupes.
[22:54] <cjwatson> Not least because we have no way to see it in that order
[22:55] <phillw> I can imagine... and translation bugs must a royal pain to check out!
[22:56] <cjwatson> Not usually
[22:56] <cjwatson> But I'm not going to look now since bed
[23:26] <infinity> Gah.
[23:26] <infinity> cjwatson: Since when do we allow people to upload directly to *-updates? :/
[23:26] <infinity> wgrant: ^
[23:27]  * infinity is kicking himself for not noticing the wrong target in the unity-tweak-tool upload.
[23:27] <wgrant> infinity: Always AFAIK
[23:27] <infinity> wgrant: Huh.  A bit odd, given that we don't let people upload to devel-release. :P
[23:27] <infinity> (I could have sworn direct uploads to -updates used to get rejected)
[23:27] <wgrant> Back in the old days you could upload to just release, or you could upload to all the pockets except release, depending on series status.
[23:28] <infinity> Yeah, but when we brought in -proposed, -updates should have been locked off.
[23:28] <wgrant> Certainly
[23:28] <infinity> If it hasn't been, we've just been remarkably good about people not uploading to the wrong target most of the time.
[23:28] <wgrant> But "should" is very very broad :)
[23:29] <infinity> I'm suspicious that this might be a regression since the mapping magic landed.
[23:29] <infinity> But maybe not.  Maybe people really have been that well-behaved.
[23:30] <infinity> Anyhow, now I get to decide if I copy/delete that from updates to proposed, or just handwave and not care.
[23:30] <wgrant> It's not a regression.
[23:30] <infinity> Fair enough.  People are better behaved than I give them credit for.
[23:39] <wgrant> infinity: Yeah, not a regression. There've been about 100 -updates uploads since 2009, spread over all the years since then.
[23:39] <infinity> wgrant: Kay.  Guess I just wasn't the one who accepted any of them.  Or I didn't notice until today. :P
[23:40] <infinity> wgrant: I'm guessing it would be trivial to rewrite s/updates/proposed/ the same as release is done (with the same ACL check for bypassing)?
[23:40] <wgrant> infinity: Probably.
[23:41] <wgrant> Though in this case I'd just reject...
[23:41] <infinity> I see no reason to hard reject, when a rewrite would DTRT.  But today's behaviour is clearly wrong one way or the other, since it relies on a human to be able to read. ;)
[23:41] <wgrant> There's no backward compat issue.
[23:41] <infinity> Rejecting works too, not picky.
[23:41] <wgrant> We should look for reasons *to* not do what people say, not reason not to not do it :)
[23:42] <infinity> Rejecting still needs the ACL check, of course.
[23:43] <infinity> (The argument for the rewrite is that it's a DWIM sort of thing, I don't really care about teaching uploaders about what magic they need in their changelog)
[23:43] <infinity> If I cared about said magic, I'd insist they always write "series" unqualified, and have the upload email tell them so. :P