[05:10] <didrocks> good morning
[05:43] <pitti> Godo morning
[05:46] <didrocks> guten morgen pitti :)
[05:57] <pitti> hey didrocks
[05:57] <pitti> err, and I can't type
[05:59] <didrocks> :)
[06:08] <pitti> anyone who knows about webapps-applications? we need a new upload to fix bug 1065246 (fixed in trunk apparently)
[06:08] <ubot2> Launchpad bug 1065246 in webapps-applications "Strings not extracted for translation because of single quotation marks" [Undecided,Fix committed] https://launchpad.net/bugs/1065246
[06:12] <didrocks> pitti: let me look at it
[06:12] <chrisccoulson_> good morning everyone
[06:12] <micahg> hi chrisccoulson_
[06:12] <pitti> didrocks: bug 1064576 as well; shall I ping Ken about it?
[06:12] <ubot2> Launchpad bug 1064576 in webapps-applications "Gmail webapp needs internationalization" [Undecided,Confirmed] https://launchpad.net/bugs/1064576
[06:12] <didrocks> pitti: ok, it seems safe enough to simply backport, want me to do it? (we had in the past few days some features+bug fixes mixed, hence my frightening moment ;))
[06:12] <pitti> hey chrisccoulson_, good morning
[06:13] <chrisccoulson_> hi micahg. how did the testing go overnight?
[06:13] <pitti> didrocks: oui, merci!
[06:13] <didrocks> pitti: if it can wait for ken, sure, but isn't that more urgent?
[06:13] <didrocks> how are you chrisccoulson_?
[06:13] <chrisccoulson_> hi pitti, how are you?
[06:13] <chrisccoulson_> hi didrocks. i'm good thanks, but a bit tired
[06:13] <micahg> chrisccoulson_: we're in progress, quantal is ready to roll morning US time once arm* finishes, I'm finishing up firefox
[06:13] <pitti> didrocks: not sure when the release team shuts the doors this time
[06:13] <chrisccoulson_> had quite a late night last night
[06:13] <pitti> chrisccoulson_: quite fine, thanks!
[06:13] <chrisccoulson_> micahg, cool, thanks!
[06:14] <micahg> chrisccoulson: thanks for getting the builds up so quickly
[06:14] <didrocks> pitti: bug #1064576 seems to only have been a missing translation template approval, right?
[06:14] <ubot2> Launchpad bug 1064576 in webapps-applications "Gmail webapp needs internationalization" [Undecided,Confirmed] https://launchpad.net/bugs/1064576
[06:14] <chrisccoulson> heh, no worries :)
[06:15] <pitti> didrocks: perhaps; it's a universe package, but due to a LP bug I'd advise against using X-Ubuntu-Use-Langpack: yes for now
[06:15] <didrocks> I don't really understand dpm's "Would it be possible to give translators a day or two and then do a
[06:15] <didrocks> translations-only upload?
[06:15] <didrocks> "
[06:15] <pitti> so we'll need to use the upstream translations in the .debs
[06:16] <didrocks> pitti: ah -gmail
[06:16]  * didrocks is lost in all those webapps* :p
[06:16] <didrocks> ok, yeah ;)
[06:16] <didrocks> pitti: so keeping on the radar and waiting dpm green flag for fetching the translation and uploading
[06:16] <didrocks> backporting the other one
[06:19] <pitti> didrocks: ok, thanks; these are all universe, so I guess we can handle them next week still
[06:19] <didrocks> pitti: not unity-webapps-common
[06:20] <didrocks> with the Amazon and Twitter scripts
[06:21] <pitti> oh, right
[06:23]  * didrocks grumbles something about people using source 3 and merge-upstream
[06:39] <didrocks> pitti: argh, latest webapps-applications is not in the vcs :/
[06:40]  * didrocks sees at least 3 uploads missing the vcs
[06:40] <didrocks> I checked the vcs, but did se 2.4.6-0ubuntu3 and distro has 2.4.7-0ubuntu3
[06:40] <didrocks> juts looked at ubuntu3, didn't saw the 6 > 7
[06:48] <jibel> good morning
[06:49] <didrocks> hey jibel, how are you?
[06:49] <jibel> Bonjour didrocks , ça va et toi ?
[06:50] <didrocks> ça va bien :)
[07:25] <chrisccoulson> hmmmm, i've got to go through the "deleting packages dance" again with my PPA :/
[07:25] <chrisccoulson> (ie, delete packages and then wait for the rest of the day for the space to clear)
[07:58] <seb128> hey
[07:58] <didrocks> hey seb128
[07:58] <seb128> hey didrocks ;-)
[07:59] <mvo> hey seb128 and didrocks
[07:59] <didrocks> morning mvo :)
[07:59] <seb128> hey mvo, wie gehts?
[07:59] <mvo> seb128: its release week
[08:00] <seb128> mvo, iz crazy week for you right? ;-)
[08:00] <mvo> seb128: its ok but I had several small heart attacks in the last couple of days
[08:01] <mvo> seb128: is it calmer for you?
[08:01] <seb128> mvo, yeah, they won't let me work after hard freeze :p
[08:02] <mvo> haha
[08:02] <seb128> ;-)
[08:12] <chrisccoulson> hey seb128, how are you?
[08:15] <seb128> chrisccoulson, hey, I'm good, how are you?
[08:15] <chrisccoulson> seb128, yeah, not too bad thanks, but quite tired
[08:15] <seb128> chrisccoulson, late hacking again?
[08:16] <chrisccoulson> seb128, late firefox release ;)
[08:17] <seb128> chrisccoulson, oh, I think firefox was released on wednesday
[08:17] <seb128> ups
[08:17] <seb128> tuesday
[08:17] <chrisccoulson> seb128, yeah, but then http://www.thespanner.co.uk/2012/10/10/firefox-knows-what-your-friends-did-last-summer/ ;)
[08:17] <chrisccoulson> and https://bugzilla.mozilla.org/show_bug.cgi?id=799991
[08:18] <ubot2> Mozilla bug 799991 in Release Engineering "Please pull FF16.0 off the wire completely" [Normal,Resolved: fixed]
[08:20] <seb128> chrisccoulson, *fun*
[08:23] <seb128> chrisccoulson, no cookie for the mozilla guys on that one
[08:23] <chrisccoulson> seb128, no cookie for the guy who blogged about it without warning them ;)
[08:23] <seb128> that as well
[08:23] <seb128> chrisccoulson, so did they roll a 16.1?
[08:23] <chrisccoulson> seb128, yeah, they did that fairly quickly
[08:25] <seb128> chrisccoulson, where is the release for us?
[08:25] <chrisccoulson> seb128, https://launchpad.net/~ubuntu-mozilla-security/+archive/ppa/+packages
[08:25] <chrisccoulson> (just waiting on arm builds)
[08:26] <seb128> chrisccoulson, what about quantal? did you guys talk to the release guys?
[08:26] <Laney> that'll be the 10 source packages we had to keep the buildds clear for yesterday eh
[08:26] <Laney> morning :-)
[08:26] <chrisccoulson> infinity and cjwatson helped last night to make sure we had build capacity for them all
[08:26] <seb128> Laney, hey
[08:26] <chrisccoulson> seb128, yeah, they're aware of it already :)
[08:26] <seb128> great
[08:26] <Laney> quantal is finishing right now
[08:29] <mlankhorst> only 2180 packages remaining on arm :p
[08:29] <Laney> that's just the test rebuild
[08:29] <mlankhorst> ah
[08:30] <Laney> bit late ...
[08:30] <mlankhorst> it's been going for a few weeks now
[08:30] <Laney> there was supposed to be one around FF-ish IIRC, but it didn't happen
[08:31] <Laney> then we had the arm builders being offlined every 5 minutes until earlier this week
[08:31] <mlankhorst> yeah was wondering why there were so few around
[08:41] <pitti> wow -- patch review in 3 minutes! gnome bug 685936
[08:41] <ubot2> Gnome bug 685936 in plugins "gsd-test-* programs miss notify_init()" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=685936
[08:48] <seb128> pitti, nice!
[09:40] <doko> here are some desktop'ish build failures (all universe) ...
[09:40] <doko> epiphany-extensions
[09:41] <doko> vala-0.10, valatoys
[09:48] <seb128> doko, is there anything still using vala-0.10? seems like a source we might want to drop from the archive
[09:48] <seb128> we have 5 versions of vala in the archive still? (current is 0.18)
[09:48] <Laney> there is already an RM bug for that
[09:49] <Laney> but it still has rdepends
[09:49] <doko> I would love it ...
[09:49] <Laney> cf avant-window-navigator on #-devel kust now
[09:49] <doko> Colin mentioned this one yes
[10:04] <seb128> Laney, how busy are you? want to have a look to awn?
[10:04] <Laney> seb128: sure, I'll take a look in a bit
[10:04] <seb128> Laney, thanks
[10:06] <Laney> is geary any good?
[10:09] <Sweetshark> moin!
[10:09] <RAOF> Laney: I dunno; it can't actually access any of my mail.
[10:10] <RAOF> Laney: I'm hugely supportive of the concept, however.
[10:11] <Laney> haha, well I got a listing of my inbox and then it segfaulted
[10:13] <RAOF> Laney: Well, that's one up on me then :)
[10:13] <RAOF> Woah! We've got geary in Universe?
[10:13] <Laney> now I'm getting mail :-)
[10:13] <Laney> yeah that's what reminded me of it
[10:13] <Laney> (reviewing seb128's upload)
[10:14] <tsdgeos> any help in finding which branch in lp has our patches for accountsservice?
[10:15] <tsdgeos> i know there's a command that tells me that
[10:15] <tsdgeos> i just don't remember it :D
[10:15] <Sweetshark> seb128: but a session restart solved the issue for me yesterday (like comment 5 said) .... *sigh*
[10:15] <Sweetshark> seb128: I see the issue again now though.
[10:19] <Laney> tsdgeos: you're probably referring to the Vcs- fields in apt-cache showsrc accountsservice
[10:20] <tsdgeos> pprobably
[10:20] <Laney> but those point to Debian, so it's probably not right
[10:20] <tsdgeos> let me chec
[10:20] <tsdgeos> +k
[10:20] <tsdgeos> right, not correct
[10:20] <tsdgeos> Laney: any idea how to find out the branch then?
[10:21] <Laney> tsdgeos: If there's not one under ~ubuntu-desktop then there might not be a dedicated branch
[10:21] <Laney> apt-get source accountsservice will get you what's in the archive
[10:22] <tsdgeos> Laney: there is a dedicated one
[10:22] <tsdgeos> since we have lots of extra patches
[10:22] <tsdgeos> it has to be somewhere :D
[10:23] <Laney> that doesn't mean there is a VCS branch
[10:23] <Laney> we have the archive
[10:23] <tsdgeos> oh wait, just relaized the patches are also in the debian thingie
[10:24] <tsdgeos> Laney: what does "we have the archive" mean?
[10:25] <tsdgeos> do we do changes in stuff and not store them on VCS?
[10:44] <seb128> Sweetshark, it's happening consistently across reboot here... let me know if you need debug infos
[10:44] <seb128> Laney, RAOF: hey, geary in universe ;-)
[10:44] <seb128> Laney, they focussed mostly on gmail I think, works fine with it there, but it segfaults with my french provider account
[10:45] <Laney> it pretty much works on subsequent launches
[10:45] <Laney> I managed to send a mail with it :-)
[10:46] <Laney> not really doing threading right yet though
[10:46] <davidcalle> seb128, I had a segfault too (ovh mail account) on the first two launches, but it works now (without my folders, which make it a bit useless, though).
[10:46] <Laney> folders are under "Labels" here
[10:46] <seb128> yeah, I guess they really focussed on the gmail experience ;-)
[10:47] <davidcalle> Laney, empty for me :)
[10:47] <Laney> :(
[10:48] <davidcalle> But proper mail notifications with the sender's face on it is nice :)
[11:59] <Laney> seb128: how much effort do you think it's worth spending on awn?
[11:59] <Laney> it needs quite a bit more porting AFAICS
[11:59] <seb128> Laney, 2-3 hours
[12:00] <Laney> ok then
[12:01] <Laney> I'll push at it a bit more after lunch
[12:03] <doko> one more glib related ftbfs: https://launchpad.net/ubuntu/+source/libio-async-loop-glib-perl/0.20-2/+build/3868386
[12:03] <seb128> Laney, how much time did you spend, how much do you think it will take? that's assuming also that you don't higher priority (like default install issues) things you want to work on
[12:03] <doko> looks i386 only
[12:24] <seb128> doko, sorry, we don't have really resources,time for universe build issues
[12:25] <chrisccoulson> hah, http://www.thespanner.co.uk/2012/10/10/firefox-knows-what-your-friends-did-last-summer/#comment-2287
[12:25] <chrisccoulson> "Why did you disclose this before Mozilla was able to fix this?"
[12:26] <chrisccoulson> "He missed out on a 3000 USD bug bounty by doing so"
[12:26] <chrisccoulson> unlucky!
[12:26] <doko> seb128, however you should have resources for archive maintenance. the pointer just to universe becomes boring over time
[12:26] <seb128> doko, talk to jasoncwarner_ or rickspencer3
[12:26] <seb128> but I'm not the one settings up the resources or priorities and we haven't been allocated resources to fix the universe builds
[12:46] <xnox> seb128: FTBFS is kind of broken windows for us. They eventually creep up and catch us unexpectedly (e.g. apt-get holding back, sru not building, etc. ). It is technical dept. https://en.wikipedia.org/wiki/Broken_windows_theory
[12:47] <xnox> if the resources are not there, that needs fixing.
[12:51] <seb128> xnox, if I had my say I would agressively drop unmaintained stuff, I think universe is not the solution anyway, it's not flexible enough and in the hands of wrong people
[12:51] <seb128> xnox, we should just let app writers maintain their stuff out of our release cycle and freezes in extras.ubuntu.com,s-c
[12:51] <seb128> xnox, it's like asking google or apple to debug,maintain all the apps in their appstore
[12:51] <seb128> it doesn't make sense
[12:53] <xnox> seb128: the counter argument (tongue in cheek is): there are many employees maintaining macports are constantly rebuilding $universe ports archive on mac os x. how else would apple developers know that their base system works, if it can't even compile simple apps.
[12:53] <seb128> xnox, "wrong people"... nothing against MOTU but you can't ask a small group of people (as amazing that they can be) to be responsible for all the bugs of softwares written by others around the glob
[12:54] <xnox> seb128: and if not universe, where else would we promote stuff up into main when we need it for one reason or another.
[12:54] <seb128> xnox, I'm fine having an universe, I'm not just fine saying we need to fix any non maintained software there
[12:54] <seb128> stuff non maintained can be dropped as far as I'm concerned
[12:54] <seb128> they can also come back if somebody cares enough to fix them and bring them back
[12:55] <xnox> seb128: true, but transitions affect the archive. when boost1.49 happened, I did drive it to the conclusion of removing boost1.46/1.42 from the archive. Including all stale optional or dependencies.
[12:55] <seb128> xnox, well, we can spend our life fixing universe unmaintained stuff and we would do nothing else and it wouldn't be enough
[12:56] <seb128> xnox, or we can spend that time making a really solid rocking system app writers can develop for
[12:56] <xnox> seb128: there is chicken and egg there, nobody knows that stuff is "unmaintained" until new stack gets uploaded and full archive rebuild happens. It's not unmaintained there is latency which doesn't fit that well with 6 months release cycle.
[12:57] <seb128> xnox, well, fine, let's see it's not part of my job mission to save the world and fix every bug in every app written on earth or elsewhere in the universe
[12:57] <seb128> ;-)
[12:57] <seb128> let's say*
[12:57] <xnox> ok.
[12:57] <seb128> xnox, if somebody else want to do that please do
[12:57] <seb128> but I'm focussed on making our default desktop work great
[12:58] <seb128> and that's enough work to keep me busy (and I think it impacts on more people that fixing vala-10 in universe when we are using vala-0.18)
[12:58] <xnox> but I don't see the difference between extras.u.c and universe thogh. If half of the apps are ported to new glib _well after quantal_ release and the other half isn't.... will you force users to install one app at a time and remove the other apps?
[12:58] <seb128> you have to pick your battles
[12:58] <seb128> xnox, e.u.c targets the platform defined
[12:59] <seb128> for an appdeveloper to send an app for quantal that has to build on quantal
[12:59] <seb128> so you never get a "non building source" in
[13:01] <xnox> seb128: are you telling me all apps will be removed on user's machine on upgrade if the app is not in quantal? that's not what happens ...
[13:02] <seb128> xnox, no, why would you need to remove anything because it fails to build?
[13:02] <seb128> libs are forward compatible
[13:02] <seb128> or change soname
[13:02] <seb128> in which case you can still have the old soname installed
[13:02] <seb128> I just don't believe that "the world should be fixed to build on quantal on release day" is a valid goal
[13:03] <seb128> we should focus on the release
[13:03] <seb128> and if "awn is made available for quantal" in 3 weeks that's fine
[13:27] <xnox> seb128: if it was forward compatible, it would not cause rdeps to FTBFS.
[13:28] <xnox> anyway enough of this. you made it clear that although you care, it's not a goal you have time to work on.
[13:28] <Laney> this is us trying to deprecate an old version of vala
[13:28] <Laney> more than deprecate, remove
[14:18] <tsdgeos> mterry: ping when you have a second
[14:18] <tsdgeos> actually more like 5 min :d
[14:18] <mterry> tsdgeos, hi!  :)  what's up?
[14:19] <tsdgeos> mterry: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1043349
[14:19] <ubot2> Ubuntu bug 1043349 in accountsservice "User Accounts reports wrong "Automatic Login" status when upgading from 12.04" [Undecided,In progress]
[14:19] <tsdgeos> mterry: pitti told me you might know what to do with that patch
[14:19] <tsdgeos> i was unable to find if we have launchpad branches for it or we just use directly the debian package or what
[14:20] <rodrigo_> hmm, what's up with ia32-libs, it seems to be uninstallable here
[14:20] <tsdgeos> mterry: though now i see the unref may be a bit too soon
[14:21] <mterry> tsdgeos, we aren't in sync with debian and we don't have a packaging branch
[14:21] <mterry> tsdgeos, so it's just apt-get source, apply patch, dput it
[14:21] <tsdgeos> mterry: that confuses me :D
[14:21] <tsdgeos> i see
[14:23] <mterry> tsdgeos, so you're saying this patch needs some more work?
[14:23] <tsdgeos> mterry: i need to verify one thing, give me 3 minutes
[14:26] <tsdgeos> mterry: yep, it needs a change, i'll ping you in 30 or so again, sorry for the noise, but good to know you can handle it
[14:30] <seb128> rodrigo_, why do you need it? with multiarch it has been deprecated
[14:30] <rodrigo_> seb128, seems my android emulator needs it, as I've found googling
[14:30] <seb128> do you know for which lib?
[14:31] <seb128> you should be able to install 32bit versions of those libs through apt
[14:48] <tsdgeos> mterry: ok, new versions of the patches up at https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/1043349
[14:48] <ubot2> Ubuntu bug 1043349 in accountsservice "User Accounts reports wrong "Automatic Login" status when upgading from 12.04" [Undecided,In progress]
[14:51] <didrocks> kenvandine: hey, FYI, I just uploaded a fix for bug #1065246 this morning
[14:51] <ubot2> Launchpad bug 1065246 in webapps-applications "Strings not extracted for translation because of single quotation marks" [Undecided,Fix committed] https://launchpad.net/bugs/1065246
[14:51] <kenvandine> didrocks, thanks!
[14:51] <didrocks> kenvandine: I noticed afterward that the vcs was 4 version behind (and got a reject the first time), would you mind reconciling it?
[14:51] <kenvandine> sure....
[14:51] <kenvandine> ubuntu:webapps-applications ?
[14:52] <mterry> tsdgeos, ok.  So this is too late to actually make 12.10, but it could be SRUd
[14:53] <tsdgeos> works for me
[14:53] <didrocks> kenvandine: seems it's under ~ubuntu-desktop?
[14:53] <kenvandine> oh... i need to delete that :)
[14:53] <kenvandine> we are using ubuntu branches for all those now
[14:53] <kenvandine> -ETOOMANYBRANCHES
[14:54] <kenvandine> damn... i need to remove that from the control file
[14:54] <kenvandine> didrocks, sorry!
[14:55] <didrocks> yep ;)
[14:55] <didrocks> no worry!
[14:59] <Laney> hah
[14:59] <Laney> that pesky "no online results" option
[15:00] <Laney> "WHY ISN'T THE GDOCS SCOPE WORKING?!?!?!?!"
[15:01] <tsdgeos> mterry: so how do we proceed from here, assign the bug to you? keep it on me?
[15:47] <didrocks> Laney: mardy did a patch though
[15:47] <didrocks> Laney: it's the only lens I didn't patch directly :)
[15:48] <didrocks> mterry: your nux branch, if hacked, you want then to backport to nux/3.0 for a quantal SRU :)
[15:48] <didrocks> (thanks!)
[15:49] <Trevinho> Sweetshark: hey, I was looking at the unity/bamf side of bug #1064962
[15:49] <ubot2> Launchpad bug 1064962 in libreoffice "Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed] https://launchpad.net/bugs/1064962
[15:49] <Sweetshark> Trevinho: oh?
[15:50] <Trevinho> but it seems that unity is not the bad guy here
[15:50] <Sweetshark> k
[15:50] <Trevinho> actually even after some time we have opened libreoffice, doing a resync with the panel service, still I get no menus
[15:50] <Sweetshark> Trevinho: yes, I have seen something odd happening in LO ...
[15:50] <Trevinho> so it seems that the panel-service does not get the new entries when LO adds them trough indicator-appmenu
[15:51] <Trevinho> tedg: ^
[15:52] <tedg> Trevinho, Hmm, that's odd.  Do you think it's a race with getting the atom on the window?
[15:53] <Trevinho> tedg: it could be... for sure the panel service does not get any entry-added signal
[15:53] <Sweetshark> Trevinho: It seems to me that when that happens, the gtk main loop (which is a slave to the LibreOffice main loop in LO) sometimes gets choked (that is: it does not handle the stufff added with g_timeout_add)
[15:55] <tedg> Trevinho, I guess I was worried that we were checking the window to see if it has the menu path too early.
[15:55] <tedg> Trevinho, Are the menus exported?
[15:57] <Trevinho> tedg: looking
[15:59] <tedg> So it looks like the menus are exported
[15:59] <tedg> But Appmenu doesn't know about the menu.
[15:59] <Trevinho> tedg: yes _GTK_MENUBAR_OBJECT_PATH(UTF8_STRING) = "/window/92274785/menus/menubar"
[16:00] <tedg> For the log: gdbus call --session --dest com.canonical.AppMenu.Registrar --object-path /com/canonical/AppMenu/Registrar --method com.canonical.AppMenu.Registrar.GetMenus
[16:02] <Sweetshark> tedg: Well, I had it yesterday (very late on a very hackish modified codebase) that the gmenuexporter callback "piled up" in LibreOffice.
[16:03] <Sweetshark> tedg: that is -- they were added to the main loop, but never got a chance to be executed.
[16:03] <tedg> Sweetshark, Never ever, or just were in a backlog?
[16:04] <Sweetshark> tedg: so I added a 1 second tick callback to see if those where executed. And I found that they where not executed ... until I opened a new menu/
[16:05] <Sweetshark> so when I waited 20 seconds and then opened a new menu, I had 20 ticks on the console.
[16:06] <Sweetshark> tedg: here is my current diff: http://paste.ubuntu.com/1273513/
[16:08] <Sweetshark> tedg: with that I see the ticks all the time as they should. Is still need to un-/refocus the window, when opening a document directly, but I see the ticks happening just fine with that.
[16:09] <tedg> Sweetshark, Why are you looking for the name on DBus instead of the item on the root window?
[16:11] <Sweetshark> tedg: I have no idea ;) -- the interaction with unity was mostly done by desrt and afernandez. I am only trying to clean up the threading issues (both on the glib as on the LO side).
[16:12] <tedg> Sweetshark, Heh, okay.  Just adding the check for the registrar name isn't the way that other GMenu applications work.
[16:12] <Sweetshark> tedg: but the watch executes just fine.
[16:14] <Sweetshark> tedg: well (I might be talking out of my a** here), the watch has the advantage that it would toggle if the regristrar disappears (cant that happen in e.g. KDE4, when somebody removes the widget)
[16:15] <tedg> Sweetshark, Sure, it's also better if something crashes.
[16:16] <tedg> Sweetshark, But this was built without my input.
[16:16] <tedg> Sweetshark, We're apparently assuming that software doesn't crash.
[16:17] <Sweetshark> tedg: I never ever saw a LibreOffice stacktrace. true dat.
[16:18] <Sweetshark> .oO(we should kill that useless document recovery dialog ASAP)
[16:18] <Sweetshark> tedg: my problem right now is: this is a heisenbug, and just because I dont see it anymore doesnt mean it is not there anymore.
[16:18] <tedg> Yup, just fix all the bugs.  No issue there, right?
[16:19] <Sweetshark> tedg: fixing all the bugs has to wait for the weekend. I gotta prepare for the LO conference.
[16:19] <tedg> Sweetshark, Yeah, for sure.  Hate those.
[16:19] <tedg> (heisenbugs)
[16:24] <tedg> Trevinho, Does BAMF send a signal when the XAtoms change on windows?
[16:25] <Trevinho> tedg: no... it could, but probably it is just better if you add a window_filter there.. to avoid all the dbus overhead...
[16:26] <tedg> Trevinho, Yes, except that we don't connect to X11 in any significant way.
[16:26] <tedg> Trevinho, The goal is to leave indicator-appmenu as independent
[16:26] <Trevinho> tedg: yeah... so
[16:27] <tedg> Trevinho, I think the issue is that BAMF gives us the window before it has the property set when it opens a document.  So we don't recognize it as a GMenu'd window.
[16:27] <Trevinho> tedg: oh, i see...
[16:28] <Trevinho> tedg: I would add it to bamf, but early this cycle was added a getter to retrieve any atom value, not a specific one for menus...
[16:28] <tedg> Trevinho, Well, last cycle, but yes :-)
[16:28] <Trevinho> so, or we add a specific one and we send signals, for that, or we add signals for every atom change, but it would increase our dbus traffic
[16:28] <tedg> Trevinho, It's only supposed to send updates for ones that have been previously requested.
[16:30] <Trevinho> tedg: mh, we can do that... or... we just move to one single dbus method for menus...
[16:31] <tedg> Trevinho, It's kinda hard to do that as there are several different pieces...
[16:31] <tedg> Trevinho, With having something atom independent means it could be used in other places as well.
[16:32] <tedg> Trevinho, I know that jassmith and I had discussed this, I guess it fell through the cracks.
[16:32] <tedg> I don't even see a bug number :-/
[16:33] <Trevinho> tedg: mh, I don't know... I just remember that I implemented that, but I was not informed about the reasons...
[16:34] <tedg> Trevinho, How hard do you think it'd be to add the signal?  SRU'able?
[16:35] <mterry> didrocks, re: my nux branch, you mean you want me to propose a merge against nux/3.0 too?  OK
[16:35] <Trevinho> tedg: however yeah, I think is nice to have an atom getter, it can just cause some more dbus chat to have signals for all them btw
[16:35] <didrocks> mterry: well, maybe wait for it to be approved on lp:nux
[16:35] <didrocks> mterry: just a warning for later :)
[16:35] <mterry> k
[16:35] <Trevinho> tedg: mhmh, sruable...
[16:36] <Trevinho> tedg: the problem is that I need to add a new signal both on the dbus API and on the library, I don't think this is exactly sru-able
[16:36] <tedg> Trevinho, Perhaps we should discuss this in another channel... don't want those pesky desktop people knowing the truth.
[16:36] <Trevinho> eheh :)
[16:36] <tedg> Trevinho, Say it with me "OF COURSE IT IS SRUABLE"
[16:36] <tedg> ;-)
[16:37] <tedg> I think the bug may be bad enough though...
[16:37] <Trevinho> tedg: oooooooooooooh, yeah... I misunderstood your request, of course adding that very internal signal is SRUable!
[16:37] <tedg> Trevinho, It looks like BamfWindowClass has some padding, so we wouldnt' be breaking ABI.
[16:38] <Trevinho> tedg: yes
[16:38] <Trevinho> on that side we are quite protected
[16:38] <tedg> seb128, kenvandine, so we're talking about bug 1064962, and it looks like the fix might be slightly involved, but it's kinda bad.  Thoughts?
[16:38] <ubot2> Launchpad bug 1064962 in libreoffice "Global menubar items do not work when opening a document directly from nautilus with no LibreOffice instance running" [High,Confirmed] https://launchpad.net/bugs/1064962
[16:40] <seb128> tedg, I would like to see the fix before commenting but my gut feeling is that we can find a way to SRU that
[16:40] <seb128> tedg, not for release at this point though I fear
[16:40] <Trevinho> tedg: of coruse for now there's no hope that the LO window would add this value earlier, right?
[16:40] <Trevinho> course*
[16:41] <tedg> seb128, Sure, I understand, just trying to get some guidance.
[16:41] <tedg> Trevinho, No, I dont' think so.  And I'm guessing on things like ARM machines it might even happen without the doc.
[16:41] <seb128> tedg, what sort of change are we talking about?
[16:41] <tedg> Trevinho, It is, effectively, a race.
[16:42] <tedg> seb128, Adding a new signal in BAMF, which would add it to the dbus interface and the lib.  Then consuming that signal in indicator-appmenu.
[16:42] <seb128> tedg, additions shouldn't be an issue, that tends to not break working code ;-)
[16:43] <seb128> tedg, so yeah, let's aim at an SRU if we can, would be good to have it ready soon so it's available just after release
[16:43] <Trevinho> seb128: working code should not be touched at all
[16:43] <seb128> Trevinho, excellent
[16:43] <seb128> Trevinho, can you talk to sil2100 to get the bamf side included in the unity SRU0
[16:43] <seb128> didrocks, ^
[16:43] <tedg> Trevinho, Okay, so what do I need to do to get your time for it?  :-)
[16:44] <seb128> kenvandine or I can deal with the indicator-appmenu SRU
[16:44]  * tedg is going to rework the bug to explain things better
[16:44] <Trevinho> tedg: sending me a cheque? ;D
[16:45] <Trevinho> tedg: jocking... I'll start that in few minutes...
[16:45] <tedg> Trevinho, Great!
[16:45] <didrocks> Trevinho: tedg: can you just ensure in your code that if one side doesn't have the new API (still on older version), the world doesn't collapse?
[16:46] <Trevinho> tedg: so you'd suggest that the method to retrieve an atom, also implicitly registers a request to signal the changes to that given atom?
[16:46] <tedg> didrocks, Do I look like Atlas here?  ;-)
[16:46] <tedg> Trevinho, That makes sense to me, work for you?
[16:47] <didrocks> tedg: my memory is weak, I don't even remember your face! I assumed you looked like Atlas :p
[16:47] <tedg> Trevinho, In the signal can you send the updated value, just so we don't have to do another round trip?
[16:47] <Trevinho> tedg: yeeah, the only thing that is not so cool is that this can't be unregistered...
[16:47] <seb128> tedg, I can see the eagle
[16:47] <Trevinho> tedg: yes, that was intended
[16:47] <seb128> tedg, just saying, just saying :p
[16:47] <tedg> Heh
[16:48] <tedg> Trevinho, I have no issue adding an explicit unsubscribe/subscribe mechanism, I just figured that was more difficult.
[16:48] <Trevinho> tedg: so mabe.... bamf_window_subscribe_on_change....
[16:49] <tedg> Trevinho, Yeah, it'd be nice if we could pass a list.
[16:49] <Trevinho> tedg: yeah, but this could also protect us in case of bamfdaemon crash (so that we can re-register the requested signals)
[16:49] <tedg> GStrv or something.
[17:01] <seb128> cyphermox, hey, is there anything that happened in your networking (n-m, proxy, etc) world this cycle which is worth mentioning on https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop
[17:01] <seb128> cyphermox, if so could you edit the wiki to add that?
[17:02] <cyphermox> yeah, there are some minimal changes from precise; I'll start thinking of a text for it
[17:02] <seb128> cyphermox, thanks
[17:03] <cyphermox> i was trying to fix up evo and the folder deletion thing, but now I just keep having it freeze up
[17:03] <seb128> tkamppeter, hey, is there anything in quantal which happened in regard of printing which is worth release noting? can you add that to https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/UbuntuDesktop if you see anything that should be there (in the "Common Infrastructure" section)
[17:12] <tkamppeter> seb128, I am looking into that.
[17:13] <seb128> tkamppeter, thanks
[17:17] <tkamppeter> seb128, in the instructions for upgrading you should tell that in the upgrade manager you also need to change the upgrade policy from LTS-only to all releases.
[17:18] <seb128> tkamppeter, indeed, thanks for pointing it
[17:27] <BigWhale> Anyone knows what is the status of proprietary AMD drivers for 12.10?
[17:27] <seb128> BigWhale, what about them?
[17:29] <BigWhale> seb128, it seems that 'alternative drivers' notification in the panel is gone and it's not available in system settings either?
[17:31] <seb128> BigWhale, the driver stuff is in software-properties
[17:31] <seb128> jockey got deprecated
[17:32] <BigWhale> oh
[17:32] <BigWhale> ok
[17:32] <BigWhale> a bit too subtle
[17:32] <BigWhale> :)
[17:32] <seb128> yeah...
[17:33] <BigWhale> let's see if this works :>
[17:33] <tkamppeter> seb128, Release Notes updated: https://wiki.ubuntu.com/QuantalQuetzal/ReleaseNotes/CommonInfrastructure
[17:33] <ogra_> nah, its just for decoration purposes
[17:33] <bcurtiswx> are we going to need to go through more of a hastle for GNOME SRU's when SRU in Ubuntu ?
[17:33] <bcurtiswx> or was that all fixed?
[17:33] <seb128> tkamppeter, thanks
[17:34] <seb128> bcurtiswx, you mean?
[17:34] <seb128> bcurtiswx, GNOME point updated a valid SRU candidates, they still need to follow the SRU process
[17:35] <bcurtiswx> seb128, the SRU team has a form pre-made for SRU's but for GNOME SRU's we were exempt IIRC
[17:35] <seb128> bcurtiswx, no, the exception just states those are valid SRU candidates, they still have to follow the rules
[17:35] <Trevinho> Sweetshark: one other thing I would like to have next cycle for LO-unity integration, would be to remove some specific code we have in BAMF... A quick change you should do is setting the proper StartupWMClass= value per each LO .desktop file, so that it should match the WM_CLASS name of the relative LO window...
[17:36] <bcurtiswx> seb128, yes sorry for not being specific. I mean including the basic SRU procedure
[17:36] <seb128> tkamppeter, thanks ... is there anything user visible that happened in quantal? the release notes are supposed to list what changed, not to describe technical details of our work
[17:36] <seb128> tkamppeter, e.g what you wrote basically sounds like "things broke and we fixed it, nothing changed for you"... which is true but not an information end users care about
[17:37] <seb128> bcurtiswx, you still need to impact,regression potential,test cases if that's the question
[17:37] <bcurtiswx> bcurtiswx, nope, questions already answered :)
[17:38] <seb128> bcurtiswx, stop talking to yourself :p
[17:38] <bcurtiswx> lol, im literally juggling like three things. Apparently proving i can't do it..
[17:38] <bcurtiswx> well juggling in the metaphorical sense
[17:39] <seb128> hehe, it has been proved men can't do that indeed :p
[17:44] <BigWhale> seb128, if I'm not back in five minutes, driver update failed. ;)
[17:45] <tkamppeter> seb128, for end users actually nothing changed, I was perhaps more worried about that someone sees some "bad press" about CUPS 1.6.x and could perhaps refrain from Quantal due to that.
[17:46] <seb128> tkamppeter, ok, thanks, I will move those out of the main page of the release notes since that's not really something worth reading for the end users upgrading from 12.04 to 12.10 (e.g not a noticable change or feature for them)
[17:53] <BigWhale> seb128, awesome.
[17:53]  * BigWhale approves! :)
[17:53] <robru> pitti: ping
[18:33] <didrocks> have a good evening everyone :)
[18:56] <s9iper1> didrocks: good evening :)
[19:02] <bcurtiswx> robru, are you going to PPA your new code or I can just build it locally?
[19:03] <robru> bcurtiswx: not really ready for ppa yet. We are considering lp:~barry/gwibber/py3 to be the 'trunk' of the py3 port. If you want to play with the latest facebook code, that's at lp:~robru/gwibber/facebook
[19:03] <bcurtiswx> gwibber-facebook?
[19:04] <robru> and there's nothing to 'build', but you're welcome to checkout those branches and play with them. look for the directory that contains setup.py, and look at the Makefile in that dir. You can also play with ./tools/debug_live.py to see how things run.
[19:11] <bcurtiswx> robru, thx
[19:11] <robru> yw
[20:51] <chrisccoulson> sigh, my daughter is not very well
[20:52]  * ogra_ hugs chrisccoulson 
[20:52] <seb128> chrisccoulson, oh, what does she has?
[20:52]  * chrisccoulson hugs ogra_
[20:52] <chrisccoulson> seb128, her temperature is 39C
[20:52] <seb128> have
[20:52] <ogra_> oh my
[20:52] <seb128> :-(
[20:52] <chrisccoulson> she's been really sleep all afternoon too
[20:52]  * seb128 hugs chrisccoulson as well
[20:52] <chrisccoulson> she fell over and banged her head yesterday, and we didn't realize until now that the 2 might be connected
[20:53] <chrisccoulson> so jo's taking her to hospital now on the advice of NHS direct
[20:53] <seb128> urg
[20:54] <ogra_> hospital++
[20:55] <seb128> chrisccoulson, let us know how it goes
[21:02] <xnox> chrisccoulson: =( doesn't sound good. hope everything will be fine.
[21:04] <kenvandine> chrisccoulson, good luck!
[21:11] <czajkowski> anyone any idea if this will be fixed for 12.10 for sure? https://bugs.launchpad.net/ubuntu/+source/gmtp/+bug/903422
[21:11] <ubot2> Ubuntu bug 903422 in gvfs "Mount / Provide access to Android 4.x (Ice Cream Sandwich and above) MTP devices" [Wishlist,In progress]
[21:13] <seb128> czajkowski, it will not be fixed for 12.10 for sure rather
[21:13] <seb128> czajkowski, we are hard frozen for release
[21:13] <seb128> czajkowski, or maybe in a SRU
[21:14] <seb128> well, new backend in a SRU is not likely...
[21:14] <czajkowski> :/
[21:15] <czajkowski> seb128: thanks
[21:15] <xnox> czajkowski: do you have a device to test this with?
[21:15] <czajkowski> bit of a pain cant sync phone to laptop any more or tether it
[21:15] <czajkowski> xnox: yup
[21:16] <xnox> czajkowski: cause ogra_ said that there is a project with all the needed magical udev rules for all the latest and greatest ice cream sandwich and jelly bean androids
[21:16] <xnox> czajkowski: so, i'd recommend pestering ogra_ about it =)
[21:16] <ogra_> huh, what where when ?
[21:16] <czajkowski> ogra_: if you make magic happen I shall buy you whiskey!
[21:17] <xnox> ogra_: remember when we were looking at the filesystem issues you said there are all the mtp / udev rules for e.g. nexus7 and other newer android devices?!
[21:17] <xnox> ogra_: somewhere on github?!
[21:17] <ogra_> err, yes
[21:18] <xnox> ogra_: do you still have a link handy for me to look at?
[21:18] <ogra_> nope, i found it googling for something related
[21:19] <xnox> czajkowski: also is the quantal state wrong on that bug? it says fix released for quantal for libmtp but you say it's not working for you...
[21:20]  * xnox feels like invalidating gmtp tasks and marking libmtp tasks as confirmed.
[21:20] <czajkowski> xnox: Sorry, could not display all the contents of "Galaxy Nexus": Timeout was reached  still broken
[21:22] <thomi> RAOF: I wonder if you're able to make some sense out of this stack trace? https://bugs.launchpad.net/xserver-xorg-driver-vesa/+bug/1065733
[21:22] <ubot2> Ubuntu bug 1065733 in xserver-xorg-driver-vesa "X Server crash" [Undecided,New]
[21:22] <thomi> RAOF: X server has started crashing for us during an autopilot test run...
[21:23] <xnox> czajkowski: can you pastebin the output from `mtp-detect` onces it's plugged in?
[21:23]  * RAOF looks
[21:25] <bryceh> RAOF, looks like another signal handling failure
[21:27] <bryceh> or at least that explains the crash; why it's aborting to begin with may be something separate
[21:27] <czajkowski> xnox: http://paste.ubuntu.com/1273842/
[21:27] <RAOF> bryceh: No, that looks to me like an everyday, regular nouveau-crash-in-EXA
[21:27] <xnox> czajkowski: cool thanks.
[21:29] <RAOF> bryceh: Xserver stack traces should now always have the top couple of frames being FatalError / AbortServer / ddxGiveUp / OsAbort / abort()
[21:29] <bryceh> yeah, src=0x0 to the memcpy
[21:29] <RAOF> thomi: That's misfiled - why did you assign it to vesa?
[21:29] <bryceh> RAOF, ah.  weird.
[21:29] <RAOF> thomi: What I mean is - were you expecting to use the VESA driver? That stacktrace is from nouveau.
[21:31] <thomi> RAOF: no, I filed against Xorg, I think launchpad tricked me, sorry
[21:35] <Chipaca> davidcalle: thanks :)
[21:36] <davidcalle> Chipaca, np :)
[21:40] <bryceh> thomi, yeah I fixed it.  You might run 'apport-collect <bug-num>' from the crashing machine, to put the usual set of logs on there
[21:41] <bryceh> thomi, and for future reference, 'ubuntu-bug xorg' is a recommended way to file X bugs, since it'll grab all the logs and file it in the right place
[21:41] <thomi> bryceh: I don't have Internet access from the crashing machine - can I still do that?
[21:41] <bryceh> thomi, yes, although there's a couple more steps involved
[21:42] <bryceh> apport lets you generate the bug report 'blob', then copy that to another machine, and finish the filing from there
[21:42] <thomi> are those logs going to be useful in this case do you think? If they are I'll go and get them. If not...
[21:56] <czajkowski> xnox: should fix released be removed from that bug for Q
[22:10] <xnox> czajkowski: let me do it, to get the blame.
[22:12] <bjf> bryceh, i've shot myself in the foot. do you have time to help (i'm limping by ok right now)
[22:13] <czajkowski> xnox: cheers
[22:13] <bryceh> bjf, sure, what's up?
[22:14] <bryceh> (I hope that's figurative rather than literal)
[22:14] <bjf> bryceh, i installed the lts-quantal from q-lts-backport on my desktop. life was good.
[22:14] <mlankhorst> bjf: it's broken a bit though
[22:15] <bjf> bryceh, no it was working quite well. the problem is that i uninstalled it and then reinstalled it.
[22:15] <bryceh> hmm
[22:15] <bjf> bryceh, now i'm stuck in 2d
[22:15] <bjf> bryceh, nvidia hw
[22:16] <bryceh> bjf, blob or nouveau?
[22:16] <bjf> bryceh, nouveau
[22:17] <bryceh> mlankhorst, do we have a tool or process for debugging these kinds of misinstallations?
[22:17] <mlankhorst> bryceh: not currently, but switching stack is broken atm
[22:17] <bryceh> bjf, let's start with dmesg and Xorg.0.log
[22:17] <bjf> bryceh, ack
[22:17] <mlankhorst> try installing xserver-xorg-video-all-lts-quantal
[22:17] <mlankhorst> and input
[22:18] <bryceh> libdrm?
[22:19] <bryceh> mlankhorst, broken to what degree?
[22:19] <bryceh> (i.e. can we document our way around it for now)
[22:20] <mlankhorst> bryceh: switching stack explodes somewhere in the middle due to an apt bug, hard to recover from
[22:21] <bryceh> mlankhorst, got any details on the explosion?  think that might be what bit bjf?
[22:22] <bjf> bryceh, files are in people.canonical.com:~bradf/help/
[22:22] <mlankhorst> bryceh: bug in ubuntu apt
[22:22] <bryceh> mlankhorst, ok do we have a bug # for that?
[22:22] <mlankhorst> basically leaves your repository skewed
[22:23] <mlankhorst> bryceh: looking but panda is slow
[22:23] <xnox> czajkowski: cleaned up https://bugs.launchpad.net/libmtp/+bug/903422 can you please remove the "upstream project libmtp" task from it. As it is bogus & lacks sourceforge bug link.
[22:23] <ubot2> Ubuntu bug 903422 in gvfs "Ubuntu does not work with Samsung Galaxy phones (needs update to libmtp)" [Wishlist,In progress]
[22:24] <mlankhorst> bryceh: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1062503
[22:24] <ubot2> Ubuntu bug 1062503 in apt "apt fails to install libglapi-mesa-lts-quantal correctly on switching x stacks" [High,New]
[22:24] <bryceh> bjf, looks like drm loaded nouveau ok.
[22:25] <bryceh> mlankhorst, thanks
[22:25] <czajkowski> xnox: done
[22:25] <bryceh> [    17.103] (II) NOUVEAU(0): Loaded DRI module
[22:26] <xnox> czajkowski: you are a star.
[22:26] <xnox> czajkowski: now thanks for your output I may hack something up for you ;-)
[22:26] <bryceh> [    17.269] (II) GLX: Initialized DRI2 GL provider for screen 0
[22:26] <xnox> czajkowski: but i am off to read hunger games and fall asleep now =)
[22:26]  * xnox laters ;-)
[22:26] <bcurtiswx> what tool will remove old Kernel Images ?
[22:26] <czajkowski> xnox: no worries off to watch NCIS here
[22:26] <bryceh> bjf, hmm looks like X is reasonably happy with itself
[22:26] <bryceh> bjf, glxinfo output ?
[22:27] <bjf> bryceh, sure
[22:28] <sarnold> bcurtiswx: I occasionally run 'apt-get purge ...' on the kernel images I'm certain I'll never use again.
[22:28] <bjf> bryceh, it's there now
[22:28] <bryceh> bjf, also check your dpkg log files for any errors, particularly any relating to libglapi-mesa*
[22:29] <bryceh> hmm, glx looks happy too
[22:29] <bjf> bryceh, no errors that i see
[22:30] <bryceh> ok how about /usr/lib/nux/unity_support_test -p
[22:30] <mlankhorst> bryceh: it's only a multilib issue, but it prevents some testing
[22:31] <bjf> bryceh, Error: no composite extension
[22:31] <bryceh> aha
[22:31] <mlankhorst> basically should have xorg, xorg-server-lts-quantal and xserver-xorg-core-lts-quantal installed
[22:31] <bjf> mlankhorst, i'll reinstall them
[22:32] <bryceh> maybe mesa too?
[22:32] <mlankhorst> bryceh: well if one of them wasn't installed libgl1 is likely missing..
[22:32] <mlankhorst> or something else went wrong
[22:32] <bryceh>  ls -l /etc/alternatives/*gl*
[22:33] <bjf> bryceh, you want to see that before i reinstall the pkgs?
[22:34] <bryceh> bjf, sure
[22:35] <bjf> bryceh, i don't have any of the xorg*lts* pkgs installed. i did not uninstall any but don't remember if i had installed them the first time
[22:36] <bjf> bryceh, file: ls-gl.log in the same url
[22:37] <bryceh> bjf, ok, so then were you using ppa-purge to uninstall it?
[22:37] <bjf> bryceh, i did "apt-get purge linux-image-lts-quantal"
[22:38] <bryceh> ah
[22:38] <bjf> bryceh, and did that nail the xorg pkgs as well?
[22:39] <bryceh> bjf, well we can check  - chuck your /var/log/dpkg.log up on that dir as well
[22:40] <bryceh> /etc/alternatives/x86_64-linux-gnu_gl_conf -> /usr/lib/x86_64-linux-gnu/mesa/ld.so.conf
[22:40] <bjf> bryceh, done
[22:40] <bryceh> should that be pointed into /usr/lib/x86_64-linux-gnu/mesa*lts* ?  Is there such a thing?
[22:42] <bjf> bryceh, no, just a mesa directory
[22:43] <bryceh> install  linux-image-3.5.0-17-generic   2012-10-08   10:31:14     <none>                         3.5.0-17.26~precise1
[22:43] <bryceh>  remove   linux-image-3.5.0-17-generic   2012-10-11   14:03:19     3.5.0-17.26~precise1           <none>
[22:43] <bryceh>   install  linux-image-3.5.0-17-generic   2012-10-11   14:51:22     <none>                         3.5.0-17.28~precise1
[22:43] <bryceh> upgrade  linux-image-generic-lts-quantal 2012-10-02   18:30:33     3.5.0.15.21                    3.5.0.16.22
[22:43] <bryceh>  upgrade  linux-image-generic-lts-quantal 2012-10-08   10:31:47     3.5.0.16.22                    3.5.0.17.23
[22:43] <bryceh>   remove   linux-image-generic-lts-quantal 2012-10-11   13:59:01     3.5.0.17.23                    <none>
[22:43] <bryceh> bjf, looks like your lts-quantal downgrade/upgrade only changed the kernel; doesn't look like any X packages got changed
[22:43] <bjf> bryceh, i had been running it for a couple of weeks before today
[22:44] <bryceh> upgrade  xorg-server                    2012-10-08   10:32:08     2:1.11.4-0ubuntu10.8           2:1.13.0-0ubuntu5~precise1~ppa6.3
[22:44] <bjf> bryceh, i haveno xorg*lts* pkgs installed
[22:44] <mlankhorst> figures...
[22:45] <mlankhorst> xorg-server should conflict with all lts packages, so try installing it
[22:46] <bjf> mlankhorst, what's the actual pkg name?
[22:46] <mlankhorst> xserver-xorg?
[22:46] <bjf> xserver-xorg is already the newest version.
[22:47] <bryceh> bjf, apt-cache policy xserver-xorg-core
[22:48] <bryceh> your Xorg.0.log suggests you're on 1.11.3
[22:48] <bryceh> no
[22:48] <bryceh> xorg-server 2:1.11.4-0ubuntu10.8
[22:48] <bjf> http://pastebin.ubuntu.com/1274008/
[22:49] <bryceh> yep
[22:49] <bryceh> wonder why dpkg.log thinks you moved to 1.13.
[22:50] <bryceh> bjf, heh, so I think we've proved your system is working perfectly.  :-P
[22:50] <bjf> LOL
[22:50] <mlankhorst> oh
[22:50] <bryceh> bjf, ok back to square one - can you describe the symptoms again?  maybe you're seeing a bug unrelated to the lts shuffling
[22:50] <mlankhorst> do you have xorg-edgers enabled?
[22:50] <mlankhorst> that would explain things
[22:51] <bjf> mlankhorst, meaning, do i have the ppa added?
[22:51] <mlankhorst> hm maybe not, ppa6.3 would be correct version for what i have
[22:51] <mlankhorst> it's just rename/replace
[22:52] <bjf> so i "accidentally" installed the q-lts-backport kernel from ubuntu-x-swat a couple weeks ago
[22:52] <bryceh> [    17.077] (==) ModulePath set to "/usr/lib/x86_64-linux-gnu/xorg/extra-modules,/usr/lib/xorg/extra-modules,/usr/lib/xorg/modules"
[22:52] <bryceh> [    17.077] (**) Extension "Composite" is disabled
[22:53] <bjf> this caused some issues but after fully embracing nouveau, all was good. i had 3d and unity looked spiffy
[22:53] <bryceh> [    17.066] (==) Using config file: "/etc/X11/xorg.conf"
[22:53] <bryceh> bjf, paste up that xorg.conf
[22:54] <bjf> however, when switching between inputs, from dvi to displayport nouveau would shit itself
[22:54] <bjf> bryceh, i copied it to the same url
[22:55] <bryceh> bjf, aha
[22:55] <bryceh> bjf, delete your /etc/X11/xorg.conf
[22:56] <bjf> done
[22:56] <bryceh> sudo service lightdm restart
[22:56] <bryceh> should put you back in business
[22:57] <bjf> bryce, life is good! i'm have 3d
[22:57] <bryceh> \o/
[22:57] <bryceh> ftr, last 3 lines of your xorg.conf:
[22:57] <bryceh> Section "Extensions"
[22:57] <bryceh>     Option         "Composite" "Disable"
[22:57] <bryceh> EndSection
[22:57] <bjf> many many thanks. if you do beers with the kernel team at CPH i'll buy you a couple
[22:58]  * mlankhorst too tired to figure that one out, eod anyway :)
[22:58] <bjf> nvidia-settings did me in (actually it was all self inflicted)
[22:59] <mlankhorst> why would nvidia-settings disable composite? even their drivers use it :/
[22:59] <bjf> mlankhorst, i can't say, when i uninstalled and reinstalled nvidia-current i tried to get my dual monitors working again
[22:59] <bjf> mlankhorst, so there were some mucking around with it, just assumed
[23:00] <bjf> mlankhorst, anyway, thanks for the help
[23:00] <mlankhorst> presumably, im using nouveau at the moment, only way to shut down the gpu fan  to audible levels (and bake some eggs) :)
[23:00] <mlankhorst> np
[23:07] <bryceh> I think it turns off composite when using dual head.  don't think it works with xinerama
[23:07] <bryceh> or twin view or whatever.
[23:07] <mlankhorst> xinerama kills all aceleration so doubtful
[23:07] <mlankhorst> composite works just fine though?
[23:08] <mlankhorst> at least i dont need a separate config file for that, probably
[23:08] <bryceh> yeah, dunno.  it used to be a common problem
[23:16] <mlankhorst> maybe because of legacy drivers