[00:07] <ceti331> hi, i'm trying to compile 'expo' in ubuntu - i get as far a linker error "cannot find -lcomposite" "cannot find -lopengl" ... any suggestions? i've already done sudo apt-get install build-deps compiz or whatever
[00:07] <ceti331> any assistance welcome
[00:07] <cyphermox> smspillaz:  ^ I mentioned you might be the best person to help out
[00:09] <cyphermox> ceti331: expo itself I'm not sure how to build separately, or if you even can. but you should mentioned if that's still the errors you get after installing the build-dependencies for compiz (what apt-get build-dep does)
[00:10] <ceti331> ah. i should try to build the whole thing
[00:10] <ceti331> thanks, i will try that
[00:10] <ceti331> yes , it seems quite possible that trying to build the whole thing would setup something taht the plugins depend on
[00:11] <cyphermox> most assuredly yes, the toplevel cmakefile does magic
[00:14] <ceti331> building now; (i've got a warning from cmake about something it can't find .. not a good sign)
[00:28] <ceti331> Thanks! - it built
[00:29] <ceti331> <now back to compiz peeps - how do i install/run ..>
[00:42] <RAOF> make install
[00:46] <smspillaz> ah, sorry missed that
[00:46] <smspillaz> yeah just make install
[00:46] <smspillaz> you might want to rebuild unity though
[00:50] <ceti331> rebuild unity .. is that a compiz plugin or what
[00:50] <ceti331> is unity the window-manager
[00:51] <ceti331> ouch just running unity didn't go well
[00:54] <RAOF> Unity is indeed a compiz plugin.
[00:55] <ceti331> ah i recall.. "compiz fusion" = merge of beryl window manager and compiz compositor..
[00:55] <ceti331> is that right, compiz IS the window manager?
[00:56] <RAOF> compiz is the window manager, yes.
[00:56] <RAOF> Unity is implemented as a compiz plugin.
[03:45] <pitti> Good morning
[03:46] <RAOF> Hey pitti!
[03:48] <RAOF> Bah! Stupid add-apt-repository/ppa-purge interaciton.
[04:01] <robert_ancell> RAOF, hey, I'm getting a crashy X server when I try and stick it in the compositor.  Log is http://paste.ubuntu.com/1077534/ but probably not that useful
[04:01] <robert_ancell> what's the best way to diagnose?
[04:03] <robert_ancell> http://paste.ubuntu.com/1077537/ is the bigger log
[04:03] <RAOF> There's a big song and dance you can do with gdb and judicious use of “follow-fork-mode child” to get a proper gdb session.
[04:05] <RAOF> But I think the actual problem is that the intel DDX in the PPA has skewed somehow; I'll track it down.
[04:18] <robert_ancell> RAOF, is it skewed?  or should I keep trying here
[04:18] <RAOF> robert_ancell: I think it's skewed. My local builds work, but trying from the ppa fails.
[04:18] <RAOF> Bah.
[04:19] <robert_ancell> aha!
[04:19] <robert_ancell> you've poisioned my machine with your PPA!
[04:19] <RAOF> In my defence, I *did* say that I disclaim all responsibility for setting fire to your cat :P
[04:21] <RAOF> I think I'll update the PPA to a newer xwayland snapshot and upload a matching intel DDX at the same time.
[04:23] <RAOF> robert_ancell: Have you got something else you could usefully be doing? I'll fix this up in the next couple of hours, but it might be a bit of a fiddle.
[04:24] <robert_ancell> RAOF, yeah, I just was just at the stage of running my actual session in weston in lightdm but I guess I'll have to pick it up next week
[04:25] <RAOF> Sorry. I'll make sure it works out of the box for you on monday.
[04:27] <robert_ancell> RAOF, np!
[04:27] <robert_ancell> RAOF, is there anything I can build locally to work around it?
[05:27] <didrocks> good morning
[05:45] <pitti> bonjour didrocks, ca va?
[05:45] <didrocks> pitti: ça va bien, et toi?
[05:45] <pitti> je vais bien
[05:45] <pitti> I'm back at home, spent the last few days in Leuven, Belgium
[05:46] <pitti> and worked from my friend's place
[05:46] <didrocks> oh, I didn't know they were living in Belgium :)
[05:46] <didrocks> had a nice week there?
[05:46] <pitti> only Monday to Thursday
[05:46] <pitti> but yes, was nice to see them again
[05:46] <pitti> he became a PhD on Monday, so we went to his defense
[05:48] <didrocks> excellent! in what domain?
[05:49] <pitti> https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CFsQFjAB&url=https%3A%2F%2Flirias.kuleuven.be%2Fbitstream%2F123456789%2F262298%2F2%2Fpaper.pdf&ei=OXz2T_2KBtHbsgbAg9CiBQ&usg=AFQjCNGDWoOxjhpAE1KYf4Na2RRq5fE-1A&sig2=qwoJNoHjwOjPrwp_yDfghg&cad=rja
[05:49] <pitti> err
[05:49] <pitti> https://lirias.kuleuven.be/bitstream/123456789/262298/2/paper.pdf
[05:50] <pitti> didrocks: he does measurements on patients with cochlear implants, to understand better how these implants can be configured properly to patients who cannot give direct feedback
[05:50] <pitti> as they are usually implanted when you are still a baby, so that it is a lot easier to learn hearing with them
[05:51] <pitti> so they can't tell you "this appears too loud to me" or "I don't recognize this yet", you have to get that information (threshold/comfort/pain levels) from the EEG
[05:52] <didrocks> pitti: yeah, indeed, it's a tricky question :)
[05:52] <didrocks> should have been an interesting PhD
[05:52] <didrocks> is he in post-doc now?
[05:52] <pitti> yes, he continues to work on that project
[05:53] <didrocks> or already titular in an university?
[05:53] <RAOF> Incidentally, the fact that we need to *learn* how to hear is awesome. :)
[05:53] <pitti> the presentation was indeed interesting, and I could understand 95% of it
[05:53] <pitti> the following Q&A with the six professors was waaay above my head, though
[05:53] <didrocks> heh ;)
[05:53] <didrocks> interesting that the presentation can still be accessible to non expert
[05:54] <didrocks> RAOF: indeed :)
[05:54] <pitti> RAOF: with those implants you have to; the normal hearing sense has several thousand thin frequency bands, while those implants only provide 24 bands
[05:54] <pitti> I guess it sounds more like chirping and buzzing, which you have to learn to interpret
[05:54] <pitti> didrocks: non-expert> that's the point of the presentations; they are open to the public
[05:54] <pitti> same as with diploma thesis
[05:55] <RAOF> My understanding is that you need to learn how to hear with regular human ears; certainly you need to learn how to *see* (as the awesome experiment with kittens that couldn't see horizontal lines demonstrates ☺)
[05:55] <pitti> it's indeed quite a challenge, but at the same time very important, to present scientific matters in a manner that non-experts can understand what this is good for (and where all the tax money goes, too)
[05:55] <didrocks> pitti: defending a thesis == diploma thesis, isn't it?
[05:55] <pitti> didrocks: PhD thesis in this case, yes
[05:56] <didrocks> oh, we are only using "thesis" in France for PhD ;)
[05:56] <pitti> same form (presentation and then discussion with the profs), except that PhD is on a much higher scientific level and there are six professors (of which three were from universities in Cambridge and the US) which grill you
[05:56] <pitti> err, s/which/who/
[05:57] <pitti> oh, wow -- http://packages.qa.debian.org/a/apport.html
[05:58] <didrocks> pitti: you didn't know it was in debian before today? :)
[05:58] <RAOF> How does apport work in Debian?
[05:58] <pitti> no, I wasn't
[05:58] <RAOF> I guess the local stuff is still useful.
[05:58] <pitti> I just got a ton of bug mail with "Branch linked: lp:debian/experimental/apport"
[05:58] <didrocks> yeah, my second question is how does it work :)
[05:58] <didrocks> ahah :)
[05:58] <pitti> well, .crash files and apport-retrace would work
[05:58] <pitti> but there is no crashdb implementation for the Debian BTS
[05:59] <pitti> and given how it works it would be rather challenging to write one
[05:59] <pitti> but I guess they could just as well use launchpad or set up a whoopsie instance
[05:59] <pitti> the latter might probably be even better
[06:00]  * pitti chuckles at http://anonscm.debian.org/gitweb/?p=collab-maint/apport.git;a=shortlog
[06:00] <pitti> "how many commits do you need to fix a path"
[06:01] <didrocks> ahah, indeed :)
[06:02] <pitti> niice!
[06:33] <tkamppeter> pitti, hi
[06:36] <pitti> hey tkamppeter
[06:42] <tkamppeter> pitti, I have switched s-c-p from libusb 0.1.x to 1.0.x yesterday. On my machine it builds perfectly also after uninstalling the old libusb-dev, but on the buildds it does not build.
[06:43] <tkamppeter> pitti, see https://launchpadlibrarian.net/109398307/buildlog_ubuntu-quantal-i386.system-config-printer_1.3.8%2B20120201-0ubuntu10_FAILEDTOBUILD.txt.gz
[06:44] <tkamppeter> pitti, the builds installs correctly the new libusb-1.0-0-dev and pkg-config (was already used before the change) is installed, too.
[06:44] <tkamppeter> pitti, but it still behaves as libusb was not there.
[06:44] <pitti> tkamppeter: have you uninstalled libusb-dev on your machine?
[06:44] <pitti> it looks like configure is trying to detect that, not -1.0
[06:48] <tkamppeter> pitti, I have changed ./configure (configure.in, Makefile.am) to check for libusb-1.0 and locally I can build with libusb-dev installed and with libusb-dev removed.
[06:48] <pitti> tkamppeter: I guess you mean with libusb-1.0-dev installed
[06:49] <pitti> tkamppeter: this kind of failure really ought to be reproducible in a pbuilder
[06:49] <pitti> tkamppeter: if it really isn't, I suggest to cat config.log if configure fails, to see what it's stumbling over
[06:51] <tkamppeter> pitti, libusb-1.0-dev I had always installed, it is a build dependency. theold libusb-dev I had once installed and once not.
[06:51]  * pitti bbl
[07:18] <rickspencer3> aaaah, ,where is seb128?
[07:21] <didrocks> rickspencer3: he's normally around in ~ 40 minutes
[07:21] <rickspencer3> thanks didrocks
[07:21] <didrocks> de rien ;)
[07:35] <Sweetshark> g'mooorning!
[07:36] <pitti> hey Sweetshark, how are you?
[07:36] <pitti> Sweetshark: what better thing to start a Friday with than a passing https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/job/quantal-pkg-libreoffice/ ?
[07:36] <pitti> Sweetshark: congrats :)
[07:37] <didrocks> hey Sweetshark!
[07:39] <Sweetshark> pitti: ;)
[07:39] <Sweetshark> pitti: are you sure this isnt just luck?
[07:40] <pitti> no, I'm not
[07:40] <pitti> I'm fully expecting this thing to fail again in the next couple of runs, but it's always a great milestone to see that at least all the tests _can_ succeed
[07:40] <Sweetshark> pitti: buy 1017125 is a heisenbug, so it might pass today, fail tomorrow ;)
[07:41] <Sweetshark> pitti: sure they can -- just give me precise as platform and everything is stable :P
[07:42] <Sweetshark> pitti: but still: yeah, we are getting there.
[07:42] <Sweetshark> didrocks: heya!
[07:42] <pitti> so that means from now on failures indicate actual bugs, not test suite probs? that's perfect then
[07:43] <Sweetshark> pitti: yes, the tests in 3.6 are really reliable. if they fail it is some real indication of something being odd.
[07:44] <pitti> so that's precisely what we want
[08:06] <Sweetshark> pitti: wait - you mean that is quantally what we want?
[08:06]  * Sweetshark *confused*
[08:07] <pitti> Sweetshark: not quite -- in quantal it will only succeed if nobody watches the result
[08:07] <seb128> hey desktopers (and qa friends)
[08:09] <Sweetshark> pitti: that can be helped with some cats in a box added to the compile usually.
[08:09] <pitti> Sweetshark: I see you have studied the matter thoroughly
[08:09] <pitti> bonjour seb128, ca va?
[08:10] <seb128> pitti, hey pitti, ca va bien, merci! wie gehts?
[08:10] <Sweetshark> and now that we know about the higgs-boson we can make the results gravitate towards lets failures ...
[08:10]  * pitti really hopes that this will be confirmed
[08:11] <pitti> the last really meaningful advancements were some 40 years ago, time to get some actual data to the theorists
[08:11] <pitti> seb128: sehr gut, danke! I enjoyed my time in Leuven, and had a rather productive train ride back yesterday
[08:12] <tkamppeter> pitti, I have done a new s-c-p upload with an explicit build system rebuild and this works now. Before I forgot this rebuild but it built locally because I did the rebuild manually and forgot to puit it properly into the package.
[08:12] <seb128> pitti, good ;-)
[08:12] <pitti> tkamppeter: ah; dh_autoreconf for the win?
[08:14] <tkamppeter> pitti, as it is cdbs format still and I do not want to dive deeply into the deprecated format (looking into switch to Quilt for Quantal) I have simply added a patch to update the build system files, as a temporary fix.
[08:15] <pitti> tkamppeter: ah, just include /usr/share/cdbs/1/rules/autoreconf.mk and add a dh-autoreconf build dep
[08:17] <tkamppeter> pitti, thanks, will do.
[08:17] <dupondje> There was something to do in Leuven? :)
[08:18] <pitti> dupondje: a friend of mine lives there
[08:18] <dupondje> ah :)
[08:18] <dupondje> so you enjoyed the belgian beer! :d
[08:19] <pitti> dupondje: you bet!
[09:15] <didrocks> waow, nautilus is regularly going crazy here
[09:19] <mpt> smspillaz, sorry, by "30-second alert" I meant an alert that appears after the program is hung for 30 seconds, not one that asks you if you want to wait for 30 seconds. I'm trying to avoid giving users the impression that we think they need the computer's permission to wait. :-)
[09:27] <smspillaz> mpt: right, I guess the money question is this
[09:27] <smspillaz> mpt: if its hung > 30 seconds, does it force you to close or restart it ?
[09:28] <seb128> didrocks, going crazy like? spinning cpu?
[09:28] <didrocks> seb128: yeah, I'm under the impression that at regular intervals, it's hitting the CPU badly
[09:29] <didrocks> (that's when I hear my fans ;))
[09:30] <mpt> smspillaz, if it later unhangs then the alert would go away by itself, so if you want to wait longer you can just leave the alert alone. But I'm not sure whether that's obvious enough, or whether it does need an explicit Wait alternative. (And if it was explicit, then how could change your mind later?)
[09:31] <seb128> didrocks, can you attach gdb to it when it happens to try to figure what it's doing?
[09:33] <didrocks> seb128: yeah, it's doing that regularly, so I need to find a spot, I installed the -dbgsym already, but was too late
[09:34] <smspillaz> mpt: hit close again
[09:34] <smspillaz> mpt: it will give you the option to close or restart
[09:34] <smspillaz> mpt: I'm just trying to find a balance here beacuse I know there are cases where you will get false positives
[09:35] <mpt> smspillaz, this is not the case where you tried to close it, this is the case where it just hung
[09:35] <smspillaz> mpt: right
[09:35] <smspillaz> so
[09:35] <mpt> but, maybe that's a decent answer anyway
[09:35] <smspillaz> "it just hung" -> 30 seconds later still hanging -> alert pops up "close, restart, wait"
[09:35] <smspillaz> if the user hits wait, close the alert
[09:36] <smspillaz> if at any point while the application is still hung the user tries to close it
[09:36] <smspillaz> pop up the alert again with "close, restart"
[09:36] <smspillaz> mpt: also, I already get too many apport dialogs :P
[09:36] <smspillaz> I have to swat them away every time I boot :P
[09:36] <mpt> Graphics card problem?
[09:38] <mpt> smspillaz, so you wouldn't recommend showing the alert again after another 30 seconds? :-)
[09:39] <smspillaz> if it were me, no, probably not
[09:39] <smspillaz> I'm already cussing when the first apport dialog comes up
[09:39] <smspillaz> "oh f*** that's the first of many MANY more"
[09:40] <smspillaz> mpt: usually its all the times I restart compiz and then some unity service crashes, or unity is buggy and crashes when compiz is restarted
[09:40] <smspillaz> and apport buffers them all up to assault me on a random day
[09:54] <mpt> smspillaz, ah, we'll be grouping near-simultaneous crashes into a single alert soon
[09:57] <smspillaz> *grin*
[10:01] <didrocks> seb128: seems it's totem video thumbnailer, but I got an update to it, let's see how it goes now
[10:02] <seb128> didrocks, do you have a video downloading in an folder actually displayed by nautilus?
[10:02] <seb128> currently*
[10:02] <didrocks> seb128: yeah
[10:02] <didrocks> it's weird that it tries to refresh it that often
[10:03] <didrocks> (well not anymore, but I had when I saw nautilus going crazy)
[10:03] <didrocks> so should be that
[10:03] <seb128> didrocks, well, downloading files keep changing and the thumbnail are refreshed on such events
[10:04] <seb128> didrocks, though nautilus used to be clever, I wonder if that stopped working
[10:04] <didrocks> seb128: yeah, but I never saw that going so dramatically before
[10:04] <seb128> didrocks, like it would only update the thumbnail if the file changed but stopped changing for 30s
[10:04] <didrocks> yeah, seems saner
[10:05] <seb128> i.e it tried to be smart about waiting the end of download
[10:05] <didrocks> not sure it's still doing that, I'll have to get a look
[10:05] <seb128> which doesn't always work fine for i.e torrents
[10:05] <didrocks> yeah
[10:20] <tkamppeter> pitti, ping
[10:24] <tkamppeter> I get a FTBFS on system-config-printer with
[10:24] <tkamppeter> dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
[10:24] <tkamppeter> dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
[10:24] <tkamppeter> SDoes someone know what is wrong here?
[10:25] <Laney> dpkg broke; they were just talking about that in #-devel
[10:25] <seb128> tkamppeter, a fixed dpkg got uploaded, just retry the build in a bit
[10:26] <tkamppeter> seb128, Laney, thanks.
[10:34] <tkamppeter> seb128, amd64 build restarted and built correctly now, the other builds started automatically now.
[10:34] <seb128> ok
[10:37] <pitti> *phew*
[10:43] <zyga> mvo, hey, I think there are some strange bugs in the way update manager allows you to select particular packages for upgrade
[10:44] <zyga> mvo, I cannot explain it but it feels like it remembers where you have clicked last and toggles  that item as well
[10:44] <zyga> mvo, also, a separate bug, the section header (such as 'proposed') does not turn on-and-off but really toggle so if you have one item selected and nine unselected then clicking on the section header toggles them back and forth, I don't know if that is expected
[10:44] <zyga> mvo, do you want bugs for both?
[10:46] <chrisccoulson> hmmm, this new eds API is a pita
[10:47] <chrisccoulson> i didn't realize the contacts addon in thunderbird is using a lot of API that has been removed :(
[11:30] <desrt> happy friday!
[11:31] <didrocks> hey desrt, happy friday to you too! :)
[11:33] <Chipaca> is gucharmap completely unresponsive in Q for anybody else?
[11:34] <pitti> Chipaca: WFM
[11:34] <Chipaca> pitti: you can click around, etc?
[11:34] <pitti> yes
[11:34] <Chipaca> here it's just completely dead
[11:35] <Chipaca> strace shouls a nonstop stream of gettimeofday()s
[11:35] <pitti> I dist-upgraded this morning, but haven't rebooted yet; that shoudl not make much difference for newly started programs, though
[11:35] <Chipaca> it draws itself, and then died
[11:35] <Chipaca> by died i mean does nothing
[11:36] <Chipaca> pitti: i update/upgraded earlier today too
[11:36] <Chipaca> pitti: anything i can do to debug?
[11:37] <pitti> does it show anything on stderr when you launch it from a terminal?
[11:37] <Chipaca> not a thing
[11:37] <Chipaca> let me set G_DEBUG
[11:37] <Chipaca> nope
[11:38] <pitti> ITYM G_MESSAGES_DEBUG=all
[11:38] <pitti> anyway, does it affect other programs as well? gedit, etc.?
[11:38] <Chipaca> gucharmap:20735): Gtk-DEBUG: Connecting to session manager
[11:38] <Chipaca> and that's all
[11:38] <pitti> no off-hand idea otherwise, except for gdb'ing the thing
[11:38] <Chipaca> i've got a much smaller program of my own making that gets something similar, where 1/3 of the time it doesn't process events
[11:39] <Chipaca> slightly different, but same flurry of gettimeofday()s when it doesn't work
[11:39] <Chipaca> lp:~chipaca/+junk/onmon
[11:39] <Chipaca> under gdb, works every time
[11:39] <Chipaca> from the commandline, a significant number of times you get no status icon
[11:40] <Chipaca> and no events from dbus
[11:40] <Chipaca> (it listens to and prints out events from network manager)
[13:05] <jibel> mterry, good morning. any ETA to get a fix for bug 1020462 ?
[13:05] <ubot2> Launchpad bug 1020462 in ubuntu-release-upgrader "Precise to Quantal upgrade failed: do-release-upgrade -d failed with ImportError: No module named janitor.plugincore.manager in DistUpgradeQuirks.py" [Critical,In progress] https://launchpad.net/bugs/1020462
[13:06] <mterry> jibel, I have a fix, waiting on review.  I can poke people if it's important to fix soon
[13:07] <jibel> mterry, it's important, upgrade to quantal fails with both GUI and CLI
[13:08] <mterry> jibel, people don't just edit sources.list anymore?  :)  OK
[13:08] <mterry> hrm, no patch pilots...
[13:11] <mterry> mvo, you around?  I have a relatively simple ubuntu-release-upgrader branch that needs a review, and it comes with a question on best way to test the upgrade tarball
[13:11] <mvo> mterry: hello, yes! what is the url for the review?
[13:12] <mvo> mterry: as for testing, one way is to simply run "sudo ./dist-upgrade.py" as a smoke test
[13:12] <mvo> mterry: for the full test I used the automatic-upgrade-tester for a full upgrade test with the non-interactive frontend
[13:13] <mterry> mvo, ah yes, the a-u-t!  I had forgot that existed after it got split out.  :)
[13:13] <mterry> url coming
[13:13] <mterry> mvo, https://code.launchpad.net/~mterry/ubuntu-release-upgrader/u-m-symlinks
[13:14] <mvo> mterry: I'm not sure if the current version has a feature to get the release-upgrader from a branch location, it used to be all bundled (as you know :) so there was a option to use the local version instead of the archive version for the test
[13:16] <ricotz> Chipaca, hi, is this happening on a clean Q without any PPAs?
[13:17] <Chipaca> ricotz: yup
[13:17] <Chipaca> well
[13:17] <Chipaca> "clean"
[13:17] <Chipaca> it's my main notebook
[13:17] <ricotz> ok, i can confirm this gucharmap hanging
[13:18] <Chipaca> \o/
[13:22] <ricotz> Chipaca, since it is looks like a "short" endless loop, did you wait long enough?
[13:22] <Chipaca> ricotz: how long?
[13:23] <ricotz> Chipaca, run it from terminal and look at a running "top"
[13:23] <ricotz> it took a while here
[13:23] <ricotz> probably another atk-bridge thing :\
[13:35] <Chipaca> ricotz: 25 seconds
[13:41] <ricotz> Chipaca, can you use it afterwards?
[13:43] <Chipaca> ricotz: yup
[13:44] <ricotz> Chipaca, ok, then you might want to find out what it is doing in all this time ;)
[13:44] <Chipaca> ricotz: you mean, other than a bunch of gettimeofday()s?
[13:49] <ricotz> Chipaca, this is just a symptom imo
[13:49] <Chipaca> ricotz: ok sure, but i have no idea how to "find out what it is doing"
[13:52] <seb128> Chipaca, use gdb and get a backtrace?
[13:54] <Chipaca> http://pastebin.ubuntu.com/1078074/
[13:54] <Chipaca> if that tells you anything, good :)
[13:57] <ricotz> Chipaca, please install libgtk-3-0-dbg too
[13:58] <ricotz> and libatk-bridge2.0-0-dbg
[13:58]  * Chipaca dutifully installs
[13:58] <ricotz> ;)
[13:59] <Chipaca> doing this in unity3d with the task switcher doing its usual "ooh, now i'm going to be *under* the other windows" is not fun
[13:59] <Chipaca> (i switched to 3d to see if was a 2d-ism)
[14:00] <Chipaca> ricotz: and now just repeat the gdb run?
[14:01] <ricotz> Chipaca, yeah, this would get a better idea about the source location
[14:01] <Chipaca> http://pastebin.ubuntu.com/1078092/
[14:03] <bcurtiswx> good morning
[14:06] <ricotz> seb128, http://git.gnome.org/browse/at-spi2-atk/commit/?id=6fbb1ba2c5281706525ae93bd78ee6cd1f1c9bc8 \o/
[14:07] <ricotz> seb128, this gucharmap problem might be another ref problem in atk-bridge? do you know if cosimoc is still suspecting more of these?
[14:08] <seb128> ricotz, no idea
[14:08] <ricotz> the first ones caused a huge slowdown of nautilus for me
[14:08] <seb128> ricotz, is that commit useful? like are those dirs visible to users in any way?
[14:08] <ricotz> seb128, look into .cache/ :\
[14:09] <ricotz> i just deleted like 200 folders
[14:09] <seb128> ricotz, right, what I'm saying, what user is looking into that dir? ;-)
[14:09] <ricotz> i guess not tough
[14:09] <seb128> but yeah, nice to see it fixed, I'm just sure it justify an upload by itself, I will include it with the next one
[14:10] <seb128> ricotz, did the refleaks fixes solve the segfaults in nautilus?
[14:10] <ricotz> seb128, no, the crashes still occur, but it responses way faster here while using it a while
[14:11] <seb128> ok
[14:11] <ricotz> but seeing this gucharmap trace (and a valgrind log) and this know behavior indicates to me there might be more of these
[14:13] <ricotz> seb128, just starting up gucharmap results in many of these http://paste.debian.net/177965/
[14:14] <ricotz> ah nevermind
[15:08] <seb128> kenvandine, bcurtiswx: could you get the SRU infos on bug #1018784? i.e Impact,Test Case, Regression potential?
[15:08] <ubot2> Launchpad bug 1018784 in empathy "[SRU Precise] update to 3.4.2.3" [Wishlist,In progress] https://launchpad.net/bugs/1018784
[15:09] <ricotz> seb128, could you please sponsor http://people.ubuntu.com/~ricotz/gnome-screensaver/
[15:10] <seb128> ricotz, did you see bug #1018710?
[15:10] <ubot2> Launchpad bug 1018710 in gnome-screensaver "Update to 3.4.2" [Wishlist,Triaged] https://launchpad.net/bugs/1018710
[15:11] <seb128> ricotz, invisible unlock screen issue under unity with that version
[15:11] <ricotz> seb128, ah i see, this fixes the white screen issue with g-s
[15:12] <ricotz> (the commit Laney mentioned there)
[15:26] <dobey> seb128: can you accept my uploades to precise-proposed please? :)
[15:27] <seb128> dobey, I'm not part of the SRU team, I've been trying to push on the SRU guys to get ubuntu-sso-client at least reviewed without luck so far but they said they will have a look soon
[15:27] <jbicha> ricotz: by the way, tracker doesn't build yet with evolution 3.5.3
[15:28] <ricotz> jbicha, i knwo
[15:28] <ricotz> *know
[15:28] <jbicha> quite a few things don't build yet :(
[15:29] <ricotz> jbicha, i pinged you before e-d-s landed ;)
[15:29] <ricotz> jbicha, i guess tracker git doesnt even compile
[15:29] <dobey> seb128: ok, thanks
[15:32] <didrocks> seb128: you don't pay enough :) dpm got Quickly to get reviewed in less than an hour :p
[15:33] <seb128> didrocks, he has a lame excuse about appdeveloper contest or something :p
[15:33] <didrocks> heh ;)
[15:33] <dpm> wait, did I have to pay? Can someone roll back the upload? ;)
[15:34] <seb128> dpm, done
[15:34] <dobey> lol
[15:34] <didrocks> dobey: to late, already delivered, no refund
[15:34] <didrocks> too*
[15:34] <dpm> hahaha
[15:34] <didrocks> dpm: ^
[15:34] <seb128> didrocks, you should see if you can get a refund for your IRC client so you can buy one with working completion ;-)3
[15:35] <dobey> benefits of being in universe
[15:35] <didrocks> seb128: I think we should limit every channels to 26 people
[15:35] <didrocks> one per character
[15:35] <didrocks> too much d here
[15:35] <didrocks> I can go on week-end to make room for others :p
[15:35] <dobey> how very un-french of you
[15:35] <seb128> lol
[15:35] <didrocks> :)
[15:36] <dobey> surely there are more than 26 letters :P
[15:36] <didrocks> dobey: well, if you start to use è, you are sure you will never get pinged by english people :)
[15:36] <didrocks> maybe it's a good idea in fact… ;)
[15:37] <dobey> heh
[15:37] <dobey> an èclaire would be a good snack right now :P
[15:38] <dobey> oh i guess that needs the accent going the other way though
[15:42] <didrocks> dobey: yeah, "éclair"
[15:45] <dobey> lacking any of those though, i should go have some real food for lunch :)
[15:45] <dobey> bbl
[16:13] <mpt> didrocks, hi. Is <https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-upgrade-user-config> about avoiding the kind of dialog shown in <http://imgur.com/XoCao>? Or is it something else?
[16:14] <didrocks> mpt: no, it's about have a facility for upgrading user configuration automatically (without hacks) when we need to
[16:14] <didrocks> mpt: like silently adding a plugin to compiz
[16:14] <didrocks> or adding/removing a launcher icon
[16:14] <didrocks> and so on :)
[16:14] <didrocks> (unity-related or not)
[16:14] <didrocks> mpt: one illustration was the change from applet to indicators in the past, we had to do back hacks for that. The spec is to have a cleaner implementation to support this
[16:16] <mpt> didrocks, ok, so for "[mpt] define an interface for backing out a configuration and restarting fresh", is this a specific set of known configurations, or for any configuration that is stored in gsettings?
[16:16] <didrocks> mpt: for any configuration
[16:16] <mpt> hrmm
[16:16] <didrocks> mpt: the idea is "reset me fresh" :)
[16:17] <mpt> That makes things trickier in two ways
[16:17] <desrt> how fresh is fresh?
[16:17] <desrt> what if i mungled something up in /etc?
[16:18] <mpt> First, finding a place to put that button (or whatever) where people would actually find it if they needed it
[16:18] <didrocks> desrt: yeah, I guess what we discussed in the session was for user key only IIRC
[16:18] <didrocks> mpt: I think the idea just came into the session from the audience, not sure if it's a good idea
[16:18] <mpt> Second, explaining why it fixes your gsettings but not (as desrt says) your /etc, or your muddled /etc/apt/sources.list, or whatever else.
[16:23] <mpt> Any ideas? :-)
[16:26] <didrocks> mpt: well, I have no strong feeling about it. It's true that we can't reset everything (system keys most of the time) or do we want to reset your thunderbird, credentials, history? As I said, it was raised during the session and if you think it will bring more confusion than anything, feel free to discare it :)
[16:28] <mpt> didrocks, I think I will ... If it was something limited to a particular schema, for example Unity Launcher settings, that would be understandable and have an obvious home ("Reset My Launcher" with the rest of the Launcher settings).
[16:29] <didrocks> mpt: yeah, I guess it wasn't that (and I don't see any use of a "Reset My Launcher" or reset other unity settings)
[16:29] <didrocks> people who can google and use CLI for that are using unity --reset which does that
[16:30] <mpt> But otherwise there'd be no way to explain what it does. "Well you see, kid, there are some programs that use something called gsettings, and some that don't..."
[16:30] <didrocks> mpt: I agree, it will bring some confusion
[16:31] <mpt> didrocks, now, about the other one: "Design to decide what should be presented to user on logout (red too much?)"
[16:31] <didrocks> even if I'm sure desrt would want everyone to know about gsettings :)
[16:31] <mpt> Do you know what that is about?
[16:31] <didrocks> I think I remember even if I didn't write it myself
[16:31] <mpt> I don't see any other mention of logout in the whiteboard
[16:32] <didrocks> I guess, google came with the "a reboot cost 1 million" or something like that
[16:32] <didrocks> and they wanted to separate when an upgrade only need a logout
[16:32] <mpt> oh, "Indicator session to prompt for logout when new applicable migration scripts are available"
[16:32] <mpt> ah
[16:32] <didrocks> mpt: I'm 90% sure it was thing. It was mentionned during the session
[16:32] <didrocks> this*
[16:33] <mpt> didrocks, so I am told there is a flag you can put on updates in the archive to say that "this update requires a restart"
[16:33] <mpt> I haven't seen it myself, but I suspect it's not widely used because update-manager doesn't expose it
[16:34] <didrocks> mpt: it's used during kernel upgrade
[16:34] <didrocks> mpt: but I think google was raising that if we can separate logout update, that would be better
[16:34] <mpt> didrocks, that could be extended to "this update requires logging out"
[16:34] <didrocks> indeed
[16:34] <didrocks> when we have a user migration configuration script
[16:34] <didrocks> an*
[16:35] <mpt> yes
[16:35] <mpt> The complication being that someone else might stay logged in while you're installing the update, even if you log out
[16:35] <mpt> whereas they can't do that if you restart
[16:35] <mpt> (and that someone else might not be an admin, so might not be used to seeing update-manager UI at all)
[16:36] <didrocks> agreed
[16:36] <didrocks> mpt: the reboot required is still update-manager, or just the session indicator?
[16:36] <didrocks> I think that the "reboot required" dialog doesn't exist anymore and I just see the session indicator turning red IIRC
[16:37] <mpt> Huh, there's no work item status for "DROPPED"
[16:38] <didrocks> mpt: rephrase it as "investigate" and mark it DONE I guess?
[16:38] <didrocks> you investigated
[16:38] <didrocks> and told, it's not needed :p
[16:38] <mpt> Moved it to the whiteboard :-)
[16:38] <didrocks> saw that ;)
[16:39] <mpt> didrocks, <https://wiki.ubuntu.com/SoftwareUpdates#After_installing>
[16:41] <mpt> (I haven't seen yet whether mterry got to that part)
[16:41] <didrocks> mpt: so you need to take into account into that design "logout only" and if someone is logged and isn't the admin (for logging out or reboot case)
[16:41] <mpt> didrocks, do migration scripts run at logout only, login only, or either?
[16:42] <mpt> (or at any time?)
[16:42] <mterry> didrocks, mpt: the restart needed dialog still exists.  But the icons next to updates to tell you that an update will need a restart doesn't exist
[16:42] <didrocks> mpt: only on login
[16:42] <mterry> yet
[16:43] <mpt> didrocks, do you know of an example where delaying logout might cause weird stuff to happen?
[16:43] <mpt> when there's a migration script waiting
[16:43] <mterry> mpt, btw, according to the spec, we only show restart-needed after installing updates.  So if a user dismisses that dialog, later starts u-m again, but doesn't see any updates, they just get the "up to date" dialog, *not* the restart-needed dialog.  Is that what you envisioned, or should we show them the restart-needed dialog there too?
[16:44] <didrocks> mpt: hum, I don't think I can think of a case where we really *had to migrate* right now (even if the application crashes and respawn), but some people raised the case of people who just suspend and never restart and so can't get access to a potential new setting without knowing
[16:44] <didrocks> mpt: well, in fact, if unity dependends on a new plugin
[16:44] <didrocks> and we really need it
[16:44] <didrocks> if compiz crashes, without the setting being updated
[16:44] <didrocks> then, we can be in a cycle of "can't start compiz"
[16:45] <didrocks> very rare, but can still occur
[16:45] <mpt> I see
[16:45] <mpt> mterry, thanks. I didn't envision them being able to dismiss the dialog without restarting (it has no close button), but I suppose it might crash or be force-quit.
[16:46] <mterry> mpt, oh, currently it does have a close button in the window decoration...
[16:46] <mterry> mpt, but I suppose that is a bug then  :)
[16:46] <mpt> mterry, so I guess we should show the restart-needed alert on launch as well in that situation
[16:54] <mpt> mterry, specification updated: <https://wiki.ubuntu.com/SoftwareUpdates?action=diff&rev2=73&rev1=72>
[16:54] <mterry> mpt, ok, thanks!
[17:00] <tkamppeter> pitti, I have pushed up CUPS 1.5.3-3. Can you upload it to Debian and Quantal? Thanks.
[17:03]  * didrocks waves good evening. Have a nice week-end everyone :)
[18:52] <dupondje> [19791.949944] type=1400 audit(1341594600.411:356): apparmor="DENIED" operation="exec" parent=2235 profile="/usr/lib/telepathy/telepathy-*" name="/usr/bin/gsettings" pid=14420 comm="telepathy-haze" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0
[18:52] <dupondje> hmz :)
[18:53] <jdstrand> dupondje: please file a bug
[18:58] <dupondje> jdstrand: https://bugs.launchpad.net/ubuntu/+source/telepathy-mission-control-5/+bug/1021876
[18:58] <ubot2> Ubuntu bug 1021876 in telepathy-mission-control-5 "Apparmor needs execute rights on /usr/bin/gsettings" [Undecided,New]
[18:58] <dupondje> there :)
[19:26] <jdstrand> thanks
[19:33] <dupondje> jdstrand: apport info added
[20:22] <dobey> mlankhorst: if you're still around, just filed bug #1021924 about my intel graphics weirdness :)
[20:22] <ubot2> Launchpad bug 1021924 in xorg "Multiple Displays not working on Core i7 3770S + Intel DQ77MK motherboard" [Undecided,New] https://launchpad.net/bugs/1021924
[20:23] <mlankhorst> you could try xorg-edgers for fun btw
[20:24] <dobey> is there a trivial way to revert in the event it totally hoses my system? :)
[20:24] <dobey> hrmm, i should probably remove all the unneeded xorg packages, to make such a thing easier to do
[20:25] <dobey> pretty sure i don't have a voodoo monster or rage 128 in here :)
[20:28] <dupondje> jdstrand: nothing special that I know in telepathy
[20:28] <dupondje> 3 msn accounts, 1 jabber account
[20:28] <Laney> replying on IRC to comments in a bug?
[20:30] <mlankhorst> Laney: well I suppose I can mark it as resolved won't fix
[20:31] <mlankhorst> dobey: nvidia + intel is going to take a while, I'm working on it for quantal but until then I'll defer it to 12.04.2 for now
[20:31] <Laney> mlankhorst: hmm? I was referring to dupondje
[20:37] <dobey> mlankhorst: this isn't nvidia + intel. it's intel only
[20:39] <mlankhorst> dobey: no I see a nvidia binary driver loaded
[20:39] <mlankhorst> [   26.972573] nvidia: module license 'NVIDIA' taints kernel.
[20:39] <mlankhorst> [   26.972576] Disabling lock debugging due to kernel taint
[20:39] <dobey> mlankhorst: i used to have an nvidia card, but recently upgraded the hardware. there is no nvidia hardware in my system now
[20:40] <dobey> hrmm
[20:40] <mlankhorst> then by no means should the nvidia driver be loaded and is that the real bug
[20:40] <dobey> let me purge the nvidia driver and try without
[20:41] <mlankhorst> there should be no mention of nvidia in xorg.0.log or dmesg
[20:41] <mlankhorst> else it's screwed up
[20:41] <dobey> but either way, it wouldn't be getting loaded in the quantal daily image
[20:41] <mlankhorst> or you could consider the possibility it would work on precise but broke on quantal
[20:42] <mlankhorst> which wouldn't surprise me
[20:43] <dobey> sure, possible; albeit the secondary screen is showing the same issue on both currently
[20:43] <dobey> but let me reboot real quick and try without nvidia binary installed
[20:49] <dobey> hmm, secondary still all red, and lightdm was behaving weird
[20:49] <dobey> and gl stuff is still crashy :-/
[20:51] <mlankhorst> if you do a print screen, does the second screen show correct?
[20:53] <dobey> mlankhorst: yes it does
[20:53] <mlankhorst> what if you switch to a virtual console?
[20:53] <mlankhorst> control alt shift 1
[20:53] <mlankhorst> erm control alt f1
[20:54] <dobey> nothing, second screen stays red
[20:54] <mlankhorst> so it's probably a kernel bug then
[20:56] <dobey> probably the cause of the gl crashiness too?
[20:57] <mlankhorst> [   28.997472] colord[1258]: segfault at 4 ip b689397a sp bfa7ef20 error 6 in libdbus-1.so.3.5.8[b686a000+47000]<<<< whats that?
[20:58] <dobey> interesting
[20:59] <mlankhorst> if you nuke colord what happens?
[20:59] <dobey> nuke? as in apt-get purge?
[20:59] <mlankhorst> yeah
[21:06] <dobey> mlankhorst: purging colord and reboot seems to have glxgears working now at least
[21:06] <dobey> but second screen is still all red
[21:07] <mlankhorst> does it get initialized as red before Xorg starts?
[21:07] <dobey> yes
[21:07] <dobey> while plymouth is running
[21:08] <dobey> when plymouth starts i guess
[21:08] <mlankhorst> id give xorg-edgers ppa a shot if I were you
[21:08] <dobey> you think it's not a kernel issue?
[21:09] <mlankhorst> i don't know, it has the renamed kernel too though
[21:48] <dobey> no dice. 3.5 locks up when X boots up, can't use keyboard or mouse, or soft-button power off. password entry cursor keeps blinkin, and it doesn't appear to even poke the second display. 3.2 + edgers also still has the secondary screen in a lovely crimson
[21:48] <dobey> but i have to go now
[21:48] <dobey> later
[21:48] <dobey> thanks mlankhorst
[22:35] <micahg> anyone familiar with lo-menubar still around?
[22:41] <ceti331> anyone here familiar with compiling and running compiz;
[22:41] <ceti331> i built it yesterday, but it doesn't run;
[22:42] <ceti331> what version of the source should i take
[22:42] <ceti331> what affects it
[22:53] <micahg> jasoncwarner_: are you around?
[23:00] <jasoncwarner_> hey micahg what's up?
[23:01] <micahg> jasoncwarner_: we have a regression in lo-menubar we're discussing in -devel, was looking for someone familiar, I called kenvandine and he said he'd have a look later
[23:02] <jasoncwarner_> thanks micahg is blocking something? also tedg would be someone to talk to about it
[23:02] <micahg> jasoncwarner_: well, we don't like regressions in -updates and this update already made it there, this is precise
[23:03] <jasoncwarner_> micahg: ah, ok