[01:08] <RAOF> cyphermox: Ok.
[01:08] <cyphermox> RAOF: just in case, dpkg -l libdbus-1-3 libdbus-glib-1-2 libglib2.0-0 ?
[01:08] <cyphermox> (from past experience, glib bugs have affected NM in mysterious ways before)
[01:09] <RAOF> http://paste2.org/p/1592325
[01:10] <cyphermox> ahah. I have reason to believe I may be on to something. I'll give it a shot ;)
[01:11] <RAOF> cyphermox: I'm now ready to test whatever you want to throw at me.
[01:12] <cyphermox> RAOF: will try to break NM here first; I should be able to reproduce it
[01:13] <cyphermox> just need to download packages to revert if updating just glib does make NM fail, I only get wifi here :/
[01:18] <RAOF> Hah!
[01:20] <desrt> RAOF: so i've semi-resolved my optimus nightmare
[01:20] <RAOF> desrt: Oh?
[01:20] <cyphermox> RAOF: I haven't rebooted but it doesn't seem to be glib, restarting NM should have triggered it to behave badly already, I think
[01:20] <desrt> i have a pair of scripts to switch between nvidia and intel chips
[01:20] <RAOF> Bonus points if the solution involves a soldering iron.
[01:20] <desrt> run script + logout
[01:20] <desrt> sucks, but works
[01:21] <desrt> did you hear about this virtualGL thing?
[01:21] <cyphermox> RAOF: care to try nmcli con list and let me know if it answers, and what it answers with?
[01:22] <RAOF> desrt: Yeah, that's basically bumblebee, right?
[01:22] <desrt> RAOF: it was actually designed to be used for remote X purposes
[01:22] <RAOF> It's run-a-fake-Xserver on your nvidia card and blit across, right?
[01:22] <desrt> not exactly...
[01:23] <desrt> it's more like run-a-normal-X-server on your terminal server and redirect the GLX commands to it
[01:23] <desrt> then use a hacked up VNC to get the images to the remote X thinclient
[01:23] <desrt> i'm sure you can see how its use applies in the bumblebee case, though
[01:23] <RAOF> Yeah.
[01:24] <RAOF> cyphermox: http://paste2.org/p/1592348
[01:24] <desrt> the cool thing about it is that it doesn't just redirect the entire app at the other Xserver -- *only* the GL commands
[01:24] <cyphermox> RAOF: and you got that relatively fast?
[01:25] <RAOF_> Yeah.
[01:25] <RAOF_> But now, not so much.
[01:25] <RAOF_> Now it hangs, as is everything else which touches the network.
[01:25] <cyphermox> right
[01:26] <cyphermox> messages in /var/log/syslog, e.g. something about dbus rejecting the message?
[01:27] <RAOF_> Nope.
[01:27] <cyphermox> mmkay
[01:27] <cyphermox> well, brb, rebooting. then if it still works I'll do the remaining updates I have one by one to try and see which one bombs
[01:28] <RAOF_> dmesg is happily spewing "Task blocked" messages, though :)
[01:28] <cyphermox> never seen that before
[01:28] <cyphermox> just "Task blocked"?
[01:29] <RAOF_> No; the "INFO: task $NAME:$PID blocked for 120 seconds..." plus the kernel traceback.
[01:29] <RAOF_> Those messages.
[01:29] <cyphermox> ok. for NM?
[01:29] <cyphermox> that's pretty cool
[01:29] <cyphermox> except for the whole no connection for you part
[01:30] <RAOF_> For nm, ip, wpa_supplicant, and anything else that's tried to touch the network.
[01:30] <RAOF_> So firefox, ssh, evolution.  Oh, and, for some reason, irqbalance :)
[01:31] <cyphermox> yuck
[01:31] <cyphermox> let me check something
[01:32] <cyphermox> nothing clearly network-related being updated here; unless you're on kubuntu
[01:33] <RAOF_> Nope.
[01:35] <RAOF_> Hm.  Interestingly, my ssh connection *in* to faye is still working.
[01:39] <cyphermox> when you said ip, like ip route list or something?
[01:39] <cyphermox> does that just fail or take a long time to respond or something else?
[01:39] <RAOF_> ip addr.
[01:39] <RAOF_> It hangs.
[01:40] <cyphermox> yuck
[01:41] <RAOF_> It's blocked in the kernel, in nltl_lock
[01:41] <RAOF_> Along with everything else; sudo, firefox, evolution, ssh, …
[01:41] <cyphermox> ok
[01:44] <RAOF_> Ok.  I've restarted with the wireless killswitch enabled.  That seems to not do the same thing.
[01:57] <cyphermox> finishing up with upgrades now
[02:39] <RAOF> cyphermox: Anything else you'd like me to do?  Disabling the wireless with the killswitch has made everything work, at the obvious cost of disabling the wireless.  But I've got cat5 here, so that's fine.
[03:00] <cyphermox> RAOF: no idea; here with what looks like full updates, things work
[03:00] <cyphermox> or more precisely, haven't catastrophically failed in the way you described, yet
[03:01] <RAOF> Heh.
[03:01] <cyphermox> maybe it's a driver thing?
[03:02] <RAOF> That's possible.
[03:02] <cyphermox> here it's ath9k
[03:02] <RAOF> But it's obviously not solely a driver thing; the -7 kernel also doesn't work.
[03:03] <cyphermox> doesn't really explain why it blocks in rtnl_lock either
[03:03] <RAOF> bcma here.
[03:04] <cyphermox> ah
[03:06] <cyphermox> this isn't shipped in the kernel though, isn't it the new broken^H^Hproprietary broadcom driver?
[03:07] <cyphermox> ah, no, I think it's probably shipped in the kernel and not so proprietary
[03:10] <RAOF> Yeah, it's the broadcom driver that was (is?) in staging; it's now shipped in the kernel.
[03:11] <Sarvatt> RAOF: the staging broadcom driver has always given me corruption problems
[03:12] <Sarvatt> apt-get update always gave hash sum mismatch problems and crap
[03:12] <RAOF> Sarvatt: It's worked fine for me; at least until today.
[03:14] <Sarvatt> ath9k was worse, it started corrupting data after about 2GB transferred
[03:14] <Sarvatt> RAOF: this is on the E6420 with the dell 1501 I gave you isnt it? thats the exact machine it didnt work on
[03:14] <RAOF> Sarvatt: Yup, it's that exact model.
[03:15] <RAOF> Sarvatt: Now that the system doesn't dependably die within 5 minutes of power up I've not had wireless problems before today.
[03:15] <Sarvatt> sudo apt-get install bcmwl-kernel-source!
[03:16] <cyphermox> guess that's an option
[03:17] <cyphermox> RAOF: have you opened a bug too? if I put my hands on a system that has a similar chip I'll test oneiric... I suspect there may be such a device in Montreal
[03:17] <RAOF> cyphermox: I have not yet; I'll do so now.
[03:17] <cyphermox> thanks; then I or one of the certification guys will be able to follow up if we have a device
[03:18] <cyphermox> for now, I won't be able to do anything until monday
[04:05] <pitti> Good morning
[04:05] <pitti> ayan: ah, looking
[04:08] <TheMuso> Morning pitti.
[04:09] <pitti> hey TheMuso, how are you?
[04:09] <TheMuso> pitti: Not too bad thanks, yourself?
[04:09] <pitti> feeling much better again, thanks
[04:10] <pitti> TheMuso: for bug 828105, which package would need to grow a dependency to at-spi2-core?
[04:10] <ubot2> Launchpad bug 828105 in at-spi2-core "at-spi2-core not installed during upgrade from Natty" [High,New] https://launchpad.net/bugs/828105
[04:11] <TheMuso> pitti: I don't know, because at-spi2-core is seeded as a recommends in desktop.
[04:11] <TheMuso> Should we probably bump those to a depends?
[04:11] <pitti> hm, that ought to be enough for a dist-upgrade
[04:13] <pitti> dear apport, compiz quitting is not really "unexpected" any more..
[04:14] <TheMuso> pitti: My thoughts exactly.
[04:14] <pitti> I'll ask mvo about it then
[04:14] <pitti> we have a lot of recommends in meta packages, this stuff needs to work
[04:15] <TheMuso> I've even checked in the ubuntu-meta package now as well, and at-spi2-core is indeed listed.
[04:15] <TheMuso> Agreed.
[04:16] <TheMuso> On upgrade, at-spi2-core, libatspi2.0-0, gir1.2-atspi-2.0, and python-pyatspi2 should all be installed, and at-spi, libatspi1.0-0 should be removed.
[04:16] <pitti> TheMuso: did we already have at-spi2 in natty?
[04:17] <pitti> ah, no
[04:17] <TheMuso> pitti: Universe.
[04:17] <jbicha> we were using the old at-spi
[04:17] <jbicha> good morning
[04:19] <pitti> TheMuso: oh, why removed?
[04:19] <pitti> hey jbicha
[04:19] <TheMuso> pitti: at-spi, i.e at-spi v1 should get removed on upgrade.
[04:20] <pitti> ooh
[04:21] <pitti> Conflicts: at-spi
[04:21] <pitti> it might not like to remove packages to satisfy a recommends
[04:21] <pitti> so I think in this case we need a depends:
[04:21] <TheMuso> Ok, will fix the seeds now.
[04:22] <TheMuso> And will retarget that bug.
[04:22] <pitti> ^ I'm doing that part ATM
[04:23] <pitti> TheMuso: ok, retargetted; let's try this again with a depends
[04:23] <TheMuso> WHich part?
[04:24] <pitti> TheMuso: the upgrade
[04:24] <TheMuso> Ok, pushing the seed update now.
[04:27] <pitti> thanks
[04:28] <pitti> ayan: the udisks part is already in -proposed, see the bug trail
[04:32] <jbicha> My sbuild chokes on this line in Metacity's controlfile Breaks: compiz (0.9.2.1+glibmainloop4-0ubuntu2)
[04:32] <jbicha> http://fpaste.org/jxqA/raw/
[04:34] <RAOF> That should surely be either (= 0.9.2.1...) or (<= 0.9.2.1...)
[04:34] <pitti> jbicha: you need an operator
[04:34] <pitti> right, what RAOF sais
[04:34] <pitti> "said", uh
[04:35] <jbicha> not my fault, I just have to fix it :-) I think I'll do the <=
[04:35] <pitti> Breaks: usually only make sense with <<
[04:35] <pitti> = might have some use cases, <= sounds weird
[04:36] <jbicha> ok I'll do << then
[04:37] <jbicha> actually I think I can just drop it since it was an early natty development thing
[04:40] <pitti> jbicha: sounds fine
[06:06] <pitti> rodrigo_: good morning
[06:07] <pitti> rodrigo_: it seems that gnome-session-properties doesn't show up in the control center; do you want a bug for this, or is this already being tracked somewhere?
[06:08] <pitti> TheMuso: is https://blueprints.launchpad.net/ubuntu/+spec/desktop-dx-o-unity-a11y still realistic in any way, or should I just move it to the p series wholesale?
[06:08] <pitti> TheMuso: it has 3/3 open items
[06:08] <TheMuso> pitti: Oh right, meant to look at them the other day but got side tracked. WIll take a look now.
[06:10] <TheMuso> Oh yeah, they're all done, at least in terms of unity-2d.
[06:10] <pitti> TheMuso: ah, I thought this was (also) about 3d
[06:11] <pitti> TheMuso: or do we solve this by forcing 2d when you select the visual a11y profiles?
[06:11] <TheMuso> pitti: It probably is re 3d too. I really wish we didn't hae 2 separate code bases at times like this.
[06:11] <pitti> (which would make sense entirely)
[06:11] <pitti> fading windows are a lot less cool when you can't see them
[06:11] <TheMuso> pitti: 2d will be forced when a11y profiles are selected. I should do that as soon as I know whether this is done any differently from last cycle.
[06:12] <pitti> TheMuso: so should these three be set to done, and we'll add another WI to ensure that 2D is selected for a11y?
[06:12] <pitti> or should 3d work as well?
[06:12] <TheMuso> pitti: I am on the page now, so I can do that.
[06:12] <pitti> TheMuso: good, thanks
[07:24] <Sweetshark> morning, all!
[07:24] <pitti> hey Sweetshark
[07:37] <jbicha> is there anything preventing the new clutter from landing in Oneiric?
[07:44] <pitti> jbicha: aside from FF, I don't think so; we try to keep it out of the CD wherever we can
[07:46] <seb128> hey
[07:46] <seb128> hi pitti
[07:46] <jbicha> well, it's a requirement to get gnome-shell past 3.1.3, do I need to file a FFE then?
[07:46] <seb128> keep what out?
[07:46] <seb128> shell?
[07:46] <seb128> ups, clutter?
[07:46] <jbicha> clutter
[07:47] <seb128> new gnome-shell will need the new clutter serie and cogl though, right?
[07:48] <mvo> hey desktopers! if someone has a bit of time it would be nice if you could play with software-center-gtk3 a bit and let me know how stable it is for you
[07:48] <seb128> mvo, hey, will do, where should we get it from?
[07:48] <mvo> just run "software-center-gtk3"
[07:48] <seb128> ok
[07:48] <mvo> its part of the package
[07:48] <seb128> mvo, are you thinking about making it default for Oneiric?
[07:48] <mvo> yeah
[07:48] <seb128> you will make Didier unhappy
[07:49] <mvo> lots of good fixes went in
[07:49] <jbicha> mvo: the first day was pretty rough, but it's sort of usable now
[07:49] <mvo> *urgh* yeah - oneconf
[07:49] <seb128> mvo, he ported oneconf to gtk2 before his holidays because he was told that we would stay on gtk2 for Oneiric
[07:49] <mvo> jbicha: what are the missing bits that make it "sort of"? performance
[07:49] <mvo> seb128: I said its 50/50, but yeah, I can see that he will be not happy :(
[07:50] <mvo> seb128: when will he come back?
[07:50] <seb128> mvo, well during your meeting gary hinted that it was late and it was 90% chance we wouldn't switch
[07:50] <seb128> mvo, in 2 weeks
[07:50] <seb128> 29th of august
[07:52] <mvo> hm, hm, ok
[07:53] <mvo> so I guess in order to make him happy this stuff needs to be ported too, a good point
[07:53] <seb128> mvo, well I think he was stopped on getting a design which work with the new version
[07:53] <seb128> mvo, we shouldn't take the decision based on oneconf though
[07:54] <mvo> right
[07:54] <mvo> still, a good point and something to consider
[07:54] <pedro_> good morning
[07:54] <seb128> hey pedro_
[07:54] <mvo> hey pedro_! are you sprinting?
[07:54] <pedro_> hello seb128, mvo
[07:55] <pedro_> mvo, yeah, in london, today is my last day here
[07:55] <pedro_> leaving tomorrow morning
[07:56] <RAOF> mvo: It's quite easy to hit unimplemented edges in software-centre-gtk3.  What sort of feedback are you after?
[07:57] <seb128> jbicha, did you talk to ricotz? he got cogl and new clutter packaged and was looking for a sponsor in Debian
[07:58] <jbicha> seb128: not yet, I sent him an email though this morning
[08:01] <pitti> mvo: the top toolbar looks quite hard to read (light gray on different light gray), is that intended?
[08:01] <mvo> RAOF: exactly this
[08:01] <mvo> pitti: it tries to derive the color from the theme, I think it may not work so well on the light theme I guess
[08:01] <pitti> mvo: ah, I see
[08:01] <mvo> RAOF: like what cases you hit
[08:01] <pitti> mvo: here it looks like disabled buttons
[08:01] <mvo> pitti: ok
[08:01] <seb128> jbicha, pitti: not sure if clutter as a standing ffe as a GNOME component, likely not since it's not part of the GNOME set but an external depends
[08:02] <pitti> mvo: and reducing the banner by 90% would be a lot more small screen friendly :)
[08:02] <seb128> mvo, should we just open bugs with [gtk3] in the title? or do you prefer IRC pings?
[08:03] <fredp> seb128: it's not an external dep anymore.
[08:03] <RAOF> mvo: Hitting "more" on the top-rated category on the front page does nothing; after pressing "more" on the "new" category, pressing the back button results in a blank pane, and none of the buttons under the "All software" dropdown do anything.
[08:03] <seb128> fredp, thanks
[08:04] <pitti> mvo: clicking on any app in the "top rated" container doesn't do anything; i. e. start -> click "games" in left list -> click on any app in top rated box
[08:04] <RAOF> mvo: But pressing "back" a second time takes you back to the homepage, and the "Installed" and "History" buttons do the right thing.  But perhaps a bit slow.
[08:05] <mvo> RAOF: thanks, I think that is indeed a performance issue we currently having, let me look and try to reproduce. but yeah, that feels rather unpolished
[08:06] <mvo> pitti: thanks, I can reproduce and will fix now
[08:06]  * pitti hugs mvo
[08:06] <jbicha> mvo: I don't like the toolbar, it doesn't display right on gnome shell for one, and why do all Ubuntu apps have to look a bit different
[08:06] <pitti> mvo: want a bug for the theme issue?
[08:07] <jbicha> it should use the primary-toolbar class that gnome-control-center uses
[08:07] <RAOF> jbicha: I actually rather like the toolbar.  That said, we really should whip up a *standard* funky-toolbar and use that everywhere.
[08:07] <mvo> jbicha: *cough* different look> indeed, its something I am concerned about as well. I
[08:08] <jbicha> if we theme the gtk class, it would be used everywhere, creating something brand new everywhere isn't the Right Way
[08:08] <mvo> pitti: not needed, I put it in my note (unless you want to open one :)
[08:08] <jbicha> along with that, the search icon should be on the right side of the search box
[08:08] <pitti> mvo: so much the better :)
[08:08] <nzmm> jbicha: perhaps mpt's pov in this? i think for the time being i prefer consistency
[08:09] <pitti> I still wonder how you guys all can live with the dark theme -- it's so uncomfortable in bright environments
[08:09] <pitti> do you all work in darkness in window-less rooms? :-)
[08:09]  * mvo works in a dungeon
[08:09] <nzmm> jbicha: and yes i have also noticed some oddities when in gnome-shell with usc
[08:09] <pitti> *cling* *hammer* *forging python code* *melting iron*
[08:10] <seb128> ;-)
[08:10] <mvo> jbicha: I guess part of the reason why consitency is no longer that imporant is that poeple are used to it from using website. but I am a bit torn here myself, I do really like consistency
[08:10] <seb128> dunno what's the hype for those themes either
[08:10] <seb128> mvo, consistency is important still on the desktop I think
[08:10] <pitti> the irony is, in the age where we all still used CRTs, and dark themes would actually have made _sense_, we used bright themes
[08:11] <pitti> and now with LCDs, which work so much better with bright themes, they get out of fashion
[08:11] <jbicha> the All Software button doesn't bring you back to All Software when you're looking at an app
[08:11] <pitti> mvo: ... you asked for the storm, now you get one apparently :)
[08:12] <nzmm> pitti: better here than omgubuntu ;)
[08:12] <mvo> jbicha: indeed! but only when clicking it the second time, the first time worked for me. a funny bug
[08:12] <mvo> pitti: heh :) keep them coming
[08:13] <pitti> mvo: is it possible to sort by popularity?
[08:13] <jbicha> the gray star / yellow star thing annoys me
[08:13] <RAOF> Why do some categories go directly to a package list, and others go to a category landing-page with "top rated"?
[08:13] <RAOF> eg: Graphics vs Accessories
[08:14] <pitti> RAOF: appareently the latter have subcategories
[08:14] <pitti> there's Games -> Arcade
[08:14] <pitti> but no subsections for education
[08:14] <pitti> (which is a shame, of course)
[08:14] <mvo> pitti: yes, but the branch has not landed yet in the archive. its the last missing bit
[08:14] <jbicha> and the "top rated" app buttons don't work in places like Developer Tools and Games
[08:14] <RAOF> So education doesn't get any top-rated?
[08:14] <pitti> mvo: oh, nice!
[08:14] <mvo> jbicha: gray because you would prefer yellow?
[08:14] <jbicha> clicking Eclipse from the Developer Tools screen does nothing
[08:14] <jbicha> mvo: I'd prefer that they pick one color and stick with it :-)
[08:15] <pitti> mvo: science & engineering is empty
[08:15] <mvo> RAOF: that is a design decision, some have sub-categories. but I agree that its not obvious
[08:15] <nzmm> i think stars should be all yellow
[08:15] <RAOF> Yeah.  Why are the stars yellow in some places and grey in others?
[08:16] <mvo> yeah, that is a good point, concistency++
[08:16] <mvo> that we will fix
[08:16] <mvo> or "fix that we will, yesssss"
[08:17] <pitti> oh, mvo moved to Master Yoda now?
[08:18]  * RAOF heard gollum
[08:18] <pitti> ah
[08:18]  * pitti sends a s-c-gtk3 crash report launchpadwards
[08:18] <mvo> it eas meant to be yoda, but my impersonation is not perfect and there is a certain similarity between yoda and gollum now that I think about it
[08:19] <mvo> thanks guys, that was really valuable feedback! nzmm and I will now go and fix the mentioned issues :)
[08:20] <pitti> mvo: just filed bug 828553, should be trivial to fix as well
[08:20] <jbicha> as a design thing, the full-length status bar is used only to tell you how many apps are in the current category
[08:20] <pitti> (probably just missing .encode('UTF-8') )
[08:21] <jbicha> I don't know if it's possible to do a mini-statusbar like Chromium
[08:21] <nzmm> nzmm: thanks guys!
[08:21] <seb128> pitti, why do we need those encode() calls?
[08:22] <seb128> mvo, btw did you figure the software-properties issues I tried to debug for a bit before the desktop summit?
[08:22] <seb128> the one with chinese that was worked around by adding a .encore() as well
[08:22] <mvo> seb128: pitti merged a fix from a contributor for this, it was a missing encdode too
[08:22] <pitti> seb128: I haven't looked at that particualr bug, but in python2 you often get these crashes when you mix UTF-8 byte arrays with unicode strings with % or _()
[08:23] <pitti> it's really quite annoying
[08:23] <mvo> annoying++
[08:23] <pitti> I'm looking forward to python3, where the separation is a lot cleaner
[08:23] <pitti> str, period
[08:23] <jbicha> I like to test keyboard accessibility, using ctrl+f to search for an app works but once you are on the app info page
[08:23] <jbicha> Ctrl+F won't return the focus back to the search box
[08:23] <seb128> pitti, mvo: well in the software-properties case the string was coming from gettext, aren't those supposed to be utf8 strings?
[08:24] <rodrigo_> morning
[08:24] <seb128> mvo, yeah, it seems the fix he uploaded is similar to the workaround I suggested you
[08:24] <seb128> but you said it was wrong because the string was coming from gettext and should be utf encoded
[08:24] <mvo> seb128: oh, maybe I am thinking of a different one then, yes, in gettext as they should all be utf8
[08:28] <nzmm> jbicha: is control+F standard, control+S seems normal that said usc doesnt have this accel either afaik...
[08:29] <pitti> seb128: that's the thing, it seems to vary
[08:29] <pitti> seb128: depending on what you stuff into it
[08:29] <seb128> pitti, so it's not deterministic?
[08:30] <seb128> how can you decide to call encode() or not if different po might use different encodings?
[08:30] <pitti> it certainly isn't random
[08:30] <pitti> seb128: it's not a matter of different encodings
[08:30] <pitti> it's a matter of encoded byte arrays (UTF-8) vs. unicode strings
[08:30] <seb128> pitti, btw can you bump the build scores for https://launchpad.net/~unity-team/+archive/compiz-testing
[08:30] <mpt> pitti, hi, the grey on grey is bug 828092
[08:30] <ubot2> Launchpad bug 828092 in software-center "[GTK3] Navigation bar is ugly in Radiance and other light themes" [Undecided,New] https://launchpad.net/bugs/828092
[08:30] <seb128> pitti, dbarth and dx are waiting on it to test the compiz candidate for oneiric
[08:31] <pitti> seb128: nudged
[08:31] <pitti> mpt: ah, thanks
[08:31] <seb128> pitti, thanks
[08:31] <seb128> pitti, unicode against utf, bah :p
[08:32] <pitti> e. g. you get crashes with
[08:32] <pitti> >>> 'ä%sb' % u'ä'
[08:32] <pitti> or >>> u'ä%sb' % 'ä'
[08:32] <pitti> >>> u'ä%sb' % u'ä'
[08:32] <pitti> that works properly
[08:32] <pitti> >>> print 'ä%sb' % 'ä'
[08:32] <pitti> as does this
[08:33] <pitti> i. e. working with byte arrays or unicode only is fine, but not mixing the two
[08:33] <pitti> seb128: I think gettext returns the type you stuff in
[08:33] <seb128> ok
[08:34] <seb128> still seems quite error prone to me
[08:34] <pitti> it is
[08:34] <pitti> because in py2, you usually work with both without knowing it
[08:34] <pitti> and most people test in English only
[08:34] <pitti> and then you get these crashes for locales which happen to have non-ascii translations
[08:34] <pitti> that's why python3 is better
[08:34] <pitti> you get the crashes in all cases ;)
[08:35] <seb128> ;-)
[08:35] <seb128> pitti, thanks for the explanations
[08:35] <pitti> oh no
[08:35] <pitti> gettext is even more evil
[08:35] <pitti> >>> type(gettext.dgettext('apport', u'(binary data)'))
[08:35] <pitti> <type 'str'>
[08:36] <pitti> >>> type(gettext.dgettext('apport', '(binary data)'))
[08:36] <pitti> <type 'str'>
[08:36] <pitti> that's a string which does have a translation
[08:36] <pitti> i. e. regardless whether you stuff in unicode or byte array, it always returns byte array
[08:36] <pitti> >>> type(gettext.dgettext('apport', u'xxx'))
[08:36] <pitti> <type 'unicode'>
[08:36] <pitti> >>> type(gettext.dgettext('apport', 'xxx'))
[08:36] <pitti> <type 'str'>
[08:36] <pitti> but for strings without a translations it returns the original
[08:39] <seb128> great...
[08:39] <pitti> py3 has that fixed apparently
[08:40] <pitti> it always returns the type you stuff into it
[08:40] <pitti> and since you need to explicity create binary data (b'foo'), it should always be 'str' then (which is the equivalent of 'unicode' in py2)
[08:41] <seb128>  >>> type(gettext.dgettext('apport', u'xxx'))
[08:41] <seb128>  <type 'unicode'>
[08:42] <seb128> seems like a bug in some way
[08:42] <pitti> well, it's the underlying implementation
[08:42] <pitti> if gettext() doesn't find a translation, it returns its input verbatim
[08:42] <seb128> I guess it does make sense like that
[08:42] <pitti> well, in C
[08:42] <seb128> it's just really error prone to have the return type of a function changing like that
[08:43] <pitti> python could do the .encode() call for you in this case
[08:43] <pitti> if you told it which encoding it should use
[08:43] <seb128> yeah, I would argue it should
[08:43] <seb128> seeing the number of bugs we got where I saw people adding some .encode() to strings returned by gettext
[08:43] <seb128> anyway not something we will change today
[08:43] <pitti> yeah, it didn't really happen in a systematic way
[08:44] <pitti> in jockey I fixed a ton of those, and some of the fixes then caused new bugs to appear for other cases
[08:44] <pitti> I guess that was the reason py3 has this strict separation now
[08:48] <huats> Morning !
[08:49] <seb128> lut huats
[08:59] <pitti> seb128: in fact, I'm struggling with such a bug right now, bug 760883 and a million dupes
[08:59] <ubot2> Launchpad bug 760883 in jockey "jockey-text crashed with UnicodeEncodeError in write(): 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)" [High,Triaged] https://launchpad.net/bugs/760883
[08:59] <pitti> I can't reproduce it :/
[09:00]  * pitti mumbles some curses pythonwards
[09:00] <seb128> pitti, the one I got recently happened only with chinese there
[09:00] <seb128> no with english french or german
[09:00] <seb128> was trying a liveCD in chinese for another bug
[09:00] <pitti> there are dupes for French, Russian, etc.
[09:00] <seb128> pitti, try with russian or chinese locale
[09:00] <seb128> ok
[09:00] <pitti> I already tried with russian
[09:00] <seb128> dunno then
[09:00] <pitti> with terminal, through pipe, etc.
[09:01] <pitti> maybe it's because of that very bug, it's all happening with jockey-text --no-dbus
[09:01] <pitti> perhaps that happens at a time when there are no langpacks yet
[09:01]  * pitti tries that
[09:06] <pitti> nope, no luck
[09:06] <pitti> it just doesn't crash here
[09:15] <jbicha> 70 duplicates is pretty impressive
[09:15] <pitti> yeah, I have to use /+text on that bug to even see it
[09:21] <pitti> aaah
[09:22] <pitti> bug in locale.getpreferredencoding()
[09:24] <pitti> or maybe in our installer environment; anyway, I'll fix it
[09:52] <seb128> bah, hate source v3 and vcs-es
[09:53] <seb128> .pc/debian-changes-0.9.3-0ubuntu4/greeters/gtk/lightdm-gtk-greeter.c
[09:53] <seb128> .pc/debian-changes-0.9.3-0ubuntu4/src/lightdm.c
[09:53] <seb128> If some of these files are left out on purpose then please add them to
[09:53] <seb128> POTFILES.skip instead of POTFILES.in.
[09:53] <seb128> I just bzr merged some upstream revisions in the packaging vcs
[09:59] <pitti> seb128: that's not related to v3 or VCS, it's the autoconf stuff being silly
[09:59] <pitti> it should not count files in .pc/ as source files
[09:59] <pitti> or intltool rather
[09:59] <seb128> right, that as well
[09:59] <seb128> still without source v3 I wouldn't have a .pc :p
[10:00] <pitti> well, apparently you have a debian-changes.patch there
[10:00] <seb128> because of source v3
[10:00] <pitti> if that's a bzr maintained source, I'd suggest to use 1.0
[10:00] <seb128> right, that's what I did now
[10:00] <seb128> it's lightdm
[10:00] <pitti> vcs maintained source and 3.0 don't go well together
[10:00] <seb128> the packaging vcs is derived from the upstream one, full source in vcs
[10:00] <pitti> *nod*
[10:00] <seb128> so I did cd ubuntu; bzr merge lp:lightdm -c rev
[10:01] <seb128> which lead to a debian-changes
[10:01] <seb128> pitti, <pitti> vcs maintained source and 3.0 don't go well together
[10:01] <seb128> right, which was my "<seb128> bah, hate source v3 and vcs-es"
[10:11] <Trewas> am I missing some configuration software in oneiric for unity? for example appearance (themes/fonts) used to be configurable with gnome-control-center but not so anymore
[10:11] <Trewas> gnome-tweak-tool works for fonts and gtk-theme, but not for window borders
[10:13] <seb128> Trewas, no, GNOME upstream decided to drop those options
[10:15] <Trewas> but unity is not gnome and configuring compiz is quite out of scope for them anyway... but oh well, I guess the options are still there somewhere in gconf/dconf
[10:38] <rodrigo_> seb128, g-c-m ready for sponsoring at lp:~rodrigo-moya/ubuntu/oneiric/gnome-color-manager/3_1_2_release
[10:38] <seb128> ok
[10:39] <seb128> you don't have access to it?
[10:39] <seb128> can you email cjwatson to have it added to the desktop set?
[10:39] <rodrigo_> seb128, it's in universe, isn't it?
[10:39] <rodrigo_> seb128, sure
[10:39] <seb128> you should run for motu ;-)
[10:39] <seb128> rodrigo_, btw what do you work on this week?
[10:40] <seb128> rodrigo_, the g-c-c bug stack isn't moving, we should start tackling some of those
[10:41] <rodrigo_> seb128, I have been working on new feature stuff, like g-contacts, g-c-m, some g-s-d and g-c-c things
[10:41] <seb128> oh right
[10:41] <rodrigo_> seb128, will move now to bug fixing, I think I'm done with the new stuff
[10:41] <seb128> yeah, let's finish the features first
[10:41] <seb128> great
[10:41] <rodrigo_> well, nothing new missing, right?
[10:42] <rodrigo_> afaik, I had g-contacts and g-c-m and the g-c-c stuff
[11:03] <seb128> pitti, help
[11:03] <seb128> pitti, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1882045/+listing-archive-extra
[11:03] <seb128> pitti, can you bump the build score?
[11:03] <pitti> seb128: done
[11:03] <seb128> pitti, danke
[11:12] <rodrigo_> hmm, is not using 'debian/tmp' prefix in .install files correct?
[11:12] <rodrigo_> like in https://code.launchpad.net/~jbicha/ubuntu/oneiric/metacity/metacity-2.34.1/+merge/71982
[11:13] <pitti> rodrigo_: with dh compat level 7 and up it automatically tries debian/tmp/ if the given path isn't found
[11:13] <pitti> so in general, it's correct, and more convenient
[11:13] <rodrigo_> ah, ok
[11:13] <rodrigo_> yes, debian/compat is 8, so yes
[11:18] <cjwatson> seb128: for the record, I'm only prepared to add ->ubuntu-desktop package set exceptions for packages that are in core or desktop-core, not for packages that are in universe.  for the latter case, you can just seed them.
[11:19] <cjwatson> the "mail cjwatson" manual exceptions mechanism only exists because seeding doesn't work to "demote" something from core/desktop-core to ubuntu-desktop
[11:19] <cjwatson> and I don't want to be in a bottleneck position unless I have to be
[11:42] <seb128> cjwatson, ok, sorry about that, I was unsure if a set could include universe sources or not
[11:42] <seb128> which probably means rodrigo_ should apply to motu for those
[11:43] <rodrigo_> right, I should
[11:44] <ayan> pitti: okay -- thanks.  i didn't notice (re: udisks & proposed)
[11:59]  * Sweetshark dances
[11:59] <Sweetshark> libreoffice-l10n finally builds again
[12:16]  * desrt starts to wonder if libreoffice's build system is some kind of a job security scam
[12:17]  * rodrigo_ lunch
[12:22] <dpm> hi pitti, can the oneiric langpack generation be reenabled?
[12:24] <alex3f> hi mvo
[12:25] <cjwatson> seb128: well, that's different, (a) yes a set can include universe sources although in the case of ubuntu-desktop that should generally only be temporary, (b) it's a management-efficiency thing rather than a technical restriction as such, (c) rodrigo probably ought to apply to motu anyway :-)
[12:28] <mvo> hey alex3f
[12:28] <alex3f> regarding your last email, got to my natty laptop
[12:28] <alex3f> still far away from the jhbuild powered desktop
[12:29] <alex3f> segfaults come from pygobject, not from PK
[12:29] <seb128> cjwatson, ok, thanks, and yeah, (c) is the way to go ;-)
[12:29] <alex3f> is this patch https://bugzilla.gnome.org/show_bug.cgi?id=652256 that is in 2.90
[12:29] <ubot2> Gnome bug 652256 in introspection "GPtrArray support is missing" [Normal,Resolved: fixed]
[12:29] <mvo> alex3f: awsome, let me check
[12:29] <alex3f> mvo: what about s-c-gtk3 and pygobject 2.90.1?
[12:30] <alex3f> I think I saw a commit log saying it is broken
[12:30] <mvo> alex3f: that should be fixed AFAICT
[12:31] <alex3f> cool, I'm now trying to run it on natty
[12:33] <mvo> alex3f: do you think that http://bugzilla-attachments.gnome.org/attachment.cgi?id=189598 will apply on 2.28.6 ?
[12:33] <mvo> seb128, pitti: are there plans for a new pygobject?
[12:33] <seb128> mvo, it's in debian, I guess pitti is waiting to sync for a reason
[12:33] <seb128> it might need a ffe?
[12:33] <alex3f> mvo, no, it is against an "invoke-rewrite" branch, which is quite different from the last release, 2.28
[12:34] <mvo> ok
[12:34] <mvo> I just get it from debian then
[12:34] <seb128> mvo, wait for pitti to reply
[12:35] <seb128> not sure what they are doing, but I think he wanted to build pygobject without gir and add a new pygobject3 with the new gir stuff
[12:36] <seb128> mvo, http://packages.qa.debian.org/p/pygobject/news/20110817T101759Z.html
[12:36] <seb128> well I guess you can try it
[12:36] <seb128> mvo, http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/pygobject-2/
[12:36] <seb128> I guess that needs to go with it
[12:37] <mvo> thanks seb128, I give it a try
[12:37] <seb128> yw
[12:51] <alex3f> mvo, any ideea about: "python: symbol lookup error: /usr/lib/gio/modules/libgiobamf.so: undefined symbol: g_desktop_app_info_launch_handler_get_type
[12:51] <alex3f> "?
[12:52] <pitti> dpm: oh, yes, do you want to?
[12:52] <pitti> mvo: waiting for pygobject-2 to get through debian NEW
[12:53] <pitti> mvo: the new pygobject version has quite a lot of changes indeed; my original plan is to only sync it if some GNOME update actually requires it
[12:53] <pitti> most stuff should work quite well with 2.28, too
[12:53] <pitti> mvo: I just did all these uploads and the s-c MP to be prepared in that case
[12:53] <pitti> mvo: do you need/want it?
[12:53] <pitti> seb128: ^ FYI
[12:54] <pitti> (sorry, was AFK for lunch)
[12:56] <pitti> seb128: is it worth trying the new compiz in that PPA? is it any more stable?
[12:57] <seb128> pitti, check with dbarth
[12:57] <seb128> the ppa is candidate for oneiric
[12:57] <mvo> pitti: well, yes and no, it contains a fix for the s-c PK backend
[12:57] <seb128> it's supposed to be better than what we have before landing but I'm not sure about the current version
[12:58] <dbarth> pitti: no, not yet
[12:59] <pitti> mvo: I'm a bit torn -- OTOH the invoke-rewrite part is sooo much better, it catches a lot of bugs as proper exceptions which previously went unnoticed and caused crashes later on, etc.
[12:59] <dbarth> pitti: it has regressions compared to the version currently in O
[12:59] <pitti> and is also quite a lot faster
[12:59] <pitti> dbarth: ah, thanks
[12:59] <mvo> pitti: can I get the version from experimental and just build it locally? will that work?
[12:59] <pitti> mvo: but due to the much stricter "static or GI" it also breaks a lot of things
[12:59] <pitti> mvo: yes, it does; I built and tested it under Ubuntu
[12:59] <pitti> mvo: I can stuff it into the u-desktop or my own PPA if you want
[13:00] <dobey> hi pitti
[13:00] <pitti> hey dobey
[13:01] <seb128> pitti, how much python-gobject clients do we have in Oneiric?
[13:01] <pitti> seb128: around 7 or so
[13:01] <mvo> pitti: hm, it complains here it needs python-gobject-2 ?
[13:01] <seb128> pitti, seems like the sort of changes we would benefit getting in Oneiric because that's what stable users will use a platform to write new code
[13:01] <pitti> maybe 10 now
[13:02] <pitti> mvo: right, you need the pygobject-2 source as well
[13:02] <mvo> aha, ok
[13:02] <seb128> pitti, i.e will minimize the churn for next cycle
[13:02] <dobey> how do you use gir in python without python-gobject? :)
[13:03] <pitti> dobey: ? you don't?
[13:03] <mvo> pitti: where can I find pygobject-2?
[13:03] <pitti> mvo: in svn; hang on, I'll put both into my PPA
[13:03] <seb128> mvo, I gave you the url before
[13:04] <seb128>  mvo, http://anonscm.debian.org/viewvc/pkg-gnome/desktop/unstable/pygobject-2/
[13:04] <seb128>  I guess that needs to go with it
[13:04] <pitti> or can also use the u-desktop PPA, if you guys want to do more testing
[13:04] <mvo> seb128: ups, sorry
[13:04] <pitti> seb128: ^ WDYT?
[13:04] <seb128> pitti, ppa works for me
[13:04] <seb128> it's a "testing ppa"
[13:04] <mvo> yeah, sounds good to me
[13:05] <seb128> pitti, as said before I would prefer to land that in Oneiric
[13:05] <kenvandine> good morning everyone
[13:05] <seb128> so people write code ready for the new version and test with it on stable Oneiric
[13:05] <kenvandine> davmor2, ping
[13:05] <seb128> hey kenvandine, how are you?
[13:05] <kenvandine> great
[13:05] <kenvandine> and you?
[13:05] <pitti> seb128: I went through all packages that I touched recently yesterday, and fixed them up
[13:05] <seb128> kenvandine, I'm fine thanks
[13:06] <davmor2> kenvandine: much better thanks or at least so far :)
[13:06] <seb128> pitti, yeah, so seems like it should be fine to do the update, anyway let's see how ppa goes to start
[13:06] <pitti> seb128, mvo: so, if both of you prefer the new one, I'm happy with that; most fallout is easy to fix
[13:06] <seb128> pitti, I do prefer take on new things this cycle to increase our lts stability
[13:07] <kenvandine> davmor2, last nights upload shouldn't have fixed whatever had failed, but it would make it log the error and not hang
[13:07] <kenvandine> davmor2, so i would like to see your gwibber.log again
[13:07] <pitti> seb128, mvo: both uploaded, I'll ping you when it's built/published
[13:07] <seb128> \o/
[13:07] <pitti> seb128, mvo: so how about this:
[13:08] <davmor2> kenvandine: right give me 5 mins
[13:08] <pitti> - the three of us run these versions for a couple of days
[13:08] <kenvandine> davmor2, cool
[13:08] <kenvandine> thx
[13:08] <pitti> - I wait for pygobject-2 to get through Debian NEW (day or two)
[13:08] <pitti> - I file an FFE now
[13:08] <pitti> - we stuff it into oneiric next Monday?
[13:08] <seb128> pitti, sounds like a plan!
[13:08] <pitti> personally I'd of course love to see the new version go in
[13:08] <mvo> sounds good
[13:09] <pitti> but I felt biased to do the request myself
[13:09] <seb128> pitti, I can file the ffe if you want
[13:09] <pitti> I'll do it, and point out the caveats
[13:09] <pitti> you guys can then chime in
[13:09] <seb128> ok
[13:09] <seb128> will do
[13:13] <Sweetshark> pitti: https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/828724 ... I will proceed with that one, once the libreoffice-l10n-3.4.1-4ubuntu1 upload in https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-oneirictest-20110718/+packages succeeds.
[13:13] <ubot2> Ubuntu bug 828724 in libreoffice "[FFE] LibreOffice 3.4 for Oneiric" [Undecided,Confirmed]
[13:14] <davmor2> kenvandine: http://paste.ubuntu.com/669216/
[13:14] <dpm> pitti, yeah, I can do it myself, just checking out if they weren't still disabled for anything in particular
[13:33] <pitti> bah, seems that the PPA uploads failed
[13:37] <seb128> \o/
[13:37] <seb128> lightdm fixed
[13:38] <pitti> seb128, mvo: bug 828751  FYI
[13:39] <ubot2> Launchpad bug 828751 in pygobject "[FFE] update pygobject to 2.90.1" [Undecided,New] https://launchpad.net/bugs/828751
[13:39] <pitti> seb128: oh, with ecryptfs?
[13:39] <seb128> pitti, yes
[13:39] <seb128> pitti, danke
[13:39] <pitti> cool
[13:39] <pitti> I can log in without tearing apart a chicken?
[13:39] <seb128> indeed you can
[13:40] <pitti> compiz/lightdm FTBFS in the PPA, FTR
[13:40] <seb128> yes, lightdm that was another stupid side effect for the source v3
[13:40] <pitti> pygobject-2_2.28.6-6_amd64.changes ACCEPTED into experimental
[13:40] <pitti> yay, Debian NEW is really fast!
[13:43] <mvo> thanks
[13:52] <seb128> mterry, hey, thanks for fixing lightdm login!
[13:52] <mterry> seb128, :)  i was happy too
[13:52] <seb128> mterry, I did a trunk snapshot to oneiric btw
[13:52] <pitti> mterry: my hero!
[13:52] <seb128> which robert_ancell somewhat suggested, he didn't have time to do a proper tarball but said trunk is good to use
[13:53] <mterry> seb128, I see, thanks!
[13:53] <mterry> seb128, btw, I can't reproduce your bad-PATH-for-gnome-session issue
[13:53] <mterry> seb128, maybe I was running trunk and it fixed things?  If you can try again with new lightdm...
[13:53] <seb128> mterry, it's working now for me, weird
[13:53] <mterry> seb128, awesome
[13:53] <seb128> just tried with the snapshot
[13:53] <seb128> it works
[13:58] <alex3f> mvo, have you got pygobject working?
[13:59] <pitti> pygobject still building in the ppa
[13:59] <alex3f> for me, it depends on python-gobject-2, but I cannot find it
[13:59] <alex3f> ah, thanks pitti
[13:59] <smspillaz> desrt: ping
[14:00] <alex3f> pitti, which ppa?
[14:00] <pitti> alex3f: https://launchpad.net/~ubuntu-desktop/+archive/ppa/+packages
[14:00] <pitti> alex3f: that's the new pygobject 2.90.1
[14:00] <pitti> if you are talking about that
[14:00] <alex3f> pitti, yes, thank you
[14:01] <pitti> alex3f: just got accepted into expeprimental, too
[14:01] <alex3f> I saw it, have been waiting some time for this release :)
[14:02] <alex3f> can it make it to oneiric?
[14:02] <pitti> alex3f: feel free to chime in at bug 828751 :)
[14:02] <ubot2> Launchpad bug 828751 in pygobject "[FFE] update pygobject to 2.90.1" [Undecided,New] https://launchpad.net/bugs/828751
[14:06] <mvo> alex3f: not yet, once its ready I will
[14:10] <davmor2> kenvandine: was that alright for you?
[14:11] <kenvandine> davmor2, yup... thx!
[14:11] <davmor2> cool
[14:16] <desrt> smspillaz: hihi
[14:17] <smspillaz> desrt: heya
[14:17] <smspillaz> desrt: maybe you might know the answer to this
[14:17] <smspillaz> desrt: is there any reason why I might get an event twice in a GdkFilterFunc ?
[14:17] <smspillaz> (like, exact same, including serial)
[14:18] <smspillaz> I initially thought it could have been because I had more than one filter on a window, but I tried it with just gdk_window_add_filter (NULL, event_handler, NULL); and that didn't seem to help too much
[14:18] <pitti> mvo, seb128: pygo stuff all built and ready for testing
[14:19] <seb128> pitti, great
[14:19] <desrt> smspillaz: are you in a process with two connections to the X server, by chance? :)
[14:19] <desrt> smspillaz: if not, i'm going to assume it has something to do with adding the filter more than once
[14:19] <desrt> or that it's not really the same event
[14:20] <desrt> serial numbers are not unique to events coming from the X server
[14:20] <smspillaz> desrt: ah, I thought they were
[14:20]  * smspillaz dumps that assumption
[14:20] <desrt> they are, rather, a strange mix of the serial number of the last message the server saw from the client and/or the request that the message is a reply to
[14:20] <davmor2> kenvandine: I still have the huge amount of duplicates of a post in FB :(
[14:20] <desrt> depending on the type of event
[14:21] <smspillaz> desrt: makes sense
[14:22] <smspillaz> I guess it still puzzles me as to why I get 5 ReparentNotify events for one XReparentWindow but I guess it could be because I've got SubstructureNotifyMask set on the frame window
[14:23] <smspillaz> and then Gtk might automatically set StructureNotifyMask on the toplevel it created
[14:23] <smspillaz> I miss being able to use X directly :)
[14:23] <kenvandine> davmor2, indeed, i need to work on that
[14:24] <jibel> pitti, mvo latest dependency changes to ubuntu-meta broke the upgrade from natty to oneiric bug 828759
[14:24] <ubot2> Launchpad bug 828759 in ubuntu-meta "package ubuntu-desktop 1.240 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/828759
[14:24] <desrt> does anyone have a T420?
[14:25] <jibel> I have not investigated very far but last lines of apt.log look suspect.
[14:25] <desrt> (or know anyone who does?  somewhat urgent...)
[14:26] <seb128> desrt, no
[14:26]  * desrt just learnt that he has a 2-day window to return this 420s mistake
[14:26] <desrt> but i want to make damn sure that the 420 is actually want i want
[14:26] <desrt> *what
[14:26] <seb128> what is wrong with the one you got?
[14:26] <desrt> optimus graphics
[14:27] <desrt> if you ever see these words, RUN
[14:27] <seb128> lol
[14:27] <desrt> and if the sales reps tell you "you can just turn it off and the laptop will behave like it has integrated graphics" tell them "you lie."
[14:29] <smspillaz> desrt: doesn't bumblebee handle that?
[14:29] <smspillaz> I know that bumblebee is a hack
[14:29] <desrt> bumblebee makes things worse
[14:29] <smspillaz> ok, not surprised then
[14:30] <desrt> the issue is that i want to use my laptop as a desktop
[14:30] <desrt> then pop it off the dock and run
[14:30] <desrt> and have all my apps follow me
[14:31] <desrt> it's currently approximately impossible to take apps that are on the nvidia X server (ie: external outputs) and migrate them to the intel X server (LCD screen)
[14:31] <desrt> particularly since said apps are actually dynamically linked against the wrong libGL
[14:32] <smspillaz> desrt: nouveau ?
[14:32] <desrt> doesn't support this chip yet :)
[14:32] <smspillaz> damn
[14:32] <desrt> and wouldn't really solve too many problems anyway
[14:32] <desrt> since you'd still need to migrate all the GL state
[14:32] <smspillaz> desrt: well it would solve the libGL issue
[14:32] <smspillaz> indeed
[14:32] <desrt> bumblebee is based on this weird thing called VirtualGL which implements something that it calls 'glx forking'
[14:32] <smspillaz> desrt: though, I'm surprised that the crtc's for the extra monitors aren't exposed to the intel card
[14:33] <desrt> this technique could be an interesting possibility to move towards some sort of way of abstracting GL
[14:33] <smspillaz> desrt: yeah, I know about the insanity of VirtualGL
[14:33] <desrt> smspillaz: apparently it's quite common for vendors to do whateverthefucktheywant when wiring this monstrosity up
[14:33] <smspillaz> desrt: kill me
[14:34] <smspillaz> desrt: ok, T420 is now on the list of machines to avoid
[14:34] <desrt> T420 is fine, i think
[14:34] <desrt> since you can get it without optimus
[14:34] <desrt> T420s is the trouble machine
[14:34] <desrt> if you want the core i7 option then optimus is mandatory
[14:35] <smspillaz> desrt: that's really weird though, I thought they actually had the standard in place which required that the intel board was in charge of the memory and framebuffers and then there was an nvidia or ati coprocessor on top of that
[14:35] <mvo> jibel: can you reproduce it?
[14:35] <desrt> smspillaz: that's how it works for the internal LCD
[14:35] <mdeslaur> desrt: my T510 with optimus works great
[14:35] <desrt> but apparently the nvidia card makes a better driver of the external ports
[14:35] <smspillaz> desrt: so they basically just violated their own design
[14:35] <desrt> due to supporting hdmi audio, 'deep colour' and so on
[14:36] <desrt> so they wire it up that way
[14:36] <jibel> mvo, I haven't try, I'm on something else. I can do that later today and let you know the result.
[14:36] <smspillaz> *groans*
[14:36] <desrt> mdeslaur: are you using external connectors?
[14:36] <mdeslaur> desrt: you got me curious, so I just plugged in an external monitor, and it just worked
[14:36] <mdeslaur> desrt: I have the nvidia stuff disabled in the bios
[14:36] <desrt> mdeslaur: VGA or displayport?
[14:36] <mdeslaur> desrt: VGA
[14:36] <desrt> VGA is fine...
[14:37] <desrt> does the displayport connector show up in your xrandr output?
[14:37] <smspillaz> desrt: http://images.memegenerator.net/instances/500x/9450166.jpg
[14:37] <mdeslaur> desrt: I guess not: http://paste.ubuntu.com/669282/
[14:37] <jibel> mvo, I have a machine available and ready, I can run the test on it.
[14:37] <desrt> mdeslaur: you have the same problem that i do, then -- you just don't care :)
[14:37] <mdeslaur> smspillaz: lol
[14:37] <mdeslaur> desrt: well, I just hadn't noticed yet :P
[14:38] <seb128> desrt, you just ruined mdeslaur's day :p
[14:38] <desrt> smspillaz: ya... pretty much sums it up
[14:38] <mdeslaur> hehe
[14:38] <desrt> i'd have used 'PROBLEM?' personally...
[14:38] <desrt> anyway...
[14:39] <desrt> if i get the straight-intel version
[14:39] <desrt> i want to be damn sure that it will actually drive my monitors
[14:39] <desrt> and lenovo doesn't have a great track record for telling me true things pre-sales
[14:39] <mvo> jibel: I ask because I don't see it in the auto upgrade tester
[14:40] <smspillaz> desrt: the problem with intel is that their max texture size limits are quite low
[14:40] <mdeslaur> desrt: dual monitors are overrated anyway...with unity, you don't need all of that :P
[14:40] <desrt> smspillaz: 8k here
[14:40] <smspillaz> desrt: oh, they've fixed that one I see
[14:40] <desrt> smspillaz: the combined horizontal resolution of my monitors is a bit over 5k
[14:40] <desrt> so i think i'm okay
[14:41] <smspillaz> desrt: I remember the good old days when it used to be 2048 or bust
[14:41] <smspillaz> incidentally, we have a workaround for that in compiz now
[14:41] <smspillaz> just don't tfp textures > mts and use XGetImage instead
[14:42] <jibel> mvo, the upgrade tester upgraded to 1.239 and the change is in 1.240
[14:42] <jibel> mvo, just different timing.
[14:42] <jibel> don't worry, you should get it tomorrow :)
[14:43] <seb128> pitti, oneconf have issues with the new gobject
[14:43] <mvo> oh, ok
[14:43] <pitti> seb128: oneconf source?
[14:44] <pitti> seb128: how to reproduce? I never used oneconf
[14:44] <seb128> pitti, no, the service, it exit on a stacktrace saying to not use "import gobject"
[14:44] <seb128> pitti, install oneconf, start s-c
[14:44] <pitti> ah, that's the very thing we need to fix indeed
[14:44] <seb128> pitti, it's a s-c component
[14:44] <seb128> pitti, or just run /usr/share/oneconf/oneconf-service
[14:45] <pitti> uh
[14:45] <pitti> oneconf-service calls gobject.*, but I don't see an import statement for that
[14:45] <pitti> funky
[14:46] <pitti> ah, nevermind, found it
[14:48] <seb128> pitti, update-manager has an error
[14:48] <pitti> ah, another one I forgot about yesterday
[14:49] <seb128> TypeError: second argument not callable
[14:49] <seb128> in UpdateManager.py l679 update_count
[14:49] <pitti> can reproduce both
[14:49] <seb128> great
[14:50] <pitti> ah, u-m seems easy
[14:50] <pitti> GLib.timeout_add_seconds
[14:50] <pitti> that's GObject.timeout_add_seconds
[14:50] <pitti> (it shouldn't be, but known issue)
[14:50] <pitti> hm, that's not it, though
[14:50] <pitti> perhaps GLib.timeout_add_seconds is actually fixed now with 2.90.1
[14:51] <pitti> ah, indeed
[14:51] <pitti> this doesn't accept a priority
[14:51] <pitti> perhaps mvo meant timeout_add_full
[14:51] <pitti> that's the kind of hidden errors that 2.28 had
[14:51] <mvo> pitti: let me check
[14:52] <pitti>           GLib.timeout_add_seconds(10, self.update_last_updated_text)
[14:52] <pitti> that works
[14:52] <pitti> mvo: nice that GLib. actually works now, the previous requirement to use GObject was quite confusing (same for MainLoop)
[14:52] <pitti> mvo: do you want to do that fix, or want me to?
[14:53] <mvo> pitti: I can fix this one, thats trivial
[14:53] <pitti> it's a miracle how this ever worked with 2.28
[14:53] <pitti> presumably it just silently was ignored
[14:53] <pitti> and the timer never fired?
[14:55] <alex3f> pitti, running pygobject 2.90 from the ppa, I'm running into this: http://pastebin.ubuntu.com/669292/
[14:55] <mvo> I think it did fire, there is one test at least the uses it
[14:55] <alex3f> I'm on natty, and have installed oneiric packages by hand
[14:55] <seb128> pitti, I get a "TypeError: glib.markup.escape_text() takes at most 1 argument (2 given)" from apport
[14:55] <pitti> alex3f: yep, I fixed that in a MP yesterday
[14:55] <pitti> alex3f: try lp:software-center trunk
[14:55] <seb128> pitti, in ui.py l246
[14:56] <alex3f> ok, thanks!
[14:56] <pitti> seb128: whoa, I fixed that yesterday
[14:56] <seb128> pitti, hum, I just dist-upgraded that box
[14:56] <pitti> but apparently not hard enough yet
[14:56] <seb128> it's uptodate
[14:58] <pitti> seb128: I see one more glib instance in hookutils, not more
[14:58] <pitti> but that's only for attach_gconf
[14:58] <pitti> this is obviously broken now
[14:58] <pitti> adding to my list
[14:59] <pitti> seb128: which version do you have?
[14:59] <seb128> pitti, of what? apport?
[14:59] <pitti> yes
[14:59] <seb128> 1.21.3-0ubuntu4
[15:00] <pitti> that seems current
[15:00] <pitti> $ grep glib apport/ui.py
[15:00] <pitti> $
[15:00] <pitti> WTH
[15:00] <pitti> $ grep escape apport/ui.py
[15:00] <pitti> $
[15:01] <OwaisL> Hey guys, I'm getting this weird thing with GtkSwitch. "activate" signal fires on hitting return/space on widget but doesn't fire when clicked. Any Ideas?
[15:07] <seb128> pitti,
[15:07] <seb128> apport-1.21.3/gtk/apport-gtk:            n = GLib.markup_escape_text(n, -1).decode('UTF-8')
[15:07] <seb128> hum
[15:07] <seb128> pitti, let me clean my .xsession-errors
[15:07] <pitti> right, I got the crash there yesterday, and fixed it for that
[15:07] <seb128> I wonder if some old iinstance was running
[15:08] <seb128> pitti, gnome-sudoku does
[15:08] <seb128> TypeError: 'Color" object does not support indexing
[15:09] <pitti> added to my list
[15:10] <seb128> pitti, ubuntuone-control-panel-gtk doesn't start
[15:10] <seb128> import gobject error
[15:11] <seb128> pitti, let me know if you prefer me to dump those elsewhere than IRC
[15:11] <pitti> seb128: I just put them into a text file for now, but perhaps just keep adding them to the FFE?
[15:11] <seb128> pitti, can you maybe add the one you noted already?
[15:11] <seb128> I will complete later
[15:11] <pitti> sure
[15:12] <seb128> pitti, ubuntuone-control-panel didn't go to gir, I'm wondering if that's an issue from using python-aptdaemon from a static gtk2 code
[15:12] <pitti> from gi.repository import GLib
[15:12] <pitti> right, that ought to be "import glib"
[15:13] <pitti> already fixed locally with that
[15:13] <pitti> so that's trivial
[15:13] <seb128> pitti, gnome-language-selector fails on an import gobject as well
[15:13] <seb128> ok
[15:14] <seb128> pitti, I'm done with those, sorry for the spamming ;-)
[15:14] <pitti> that's fine, thanks
[15:14] <seb128> I will do another round of testing later
[15:14] <seb128> need to test unity a bit now
[15:14] <pitti> added to FFE bug
[15:28] <mvo> pitti: hm, software-center trunk is now complaining that Gio.File.new_for_path() is not there? did something change with the new gobject there?
[15:30] <pitti> sounds like missing annotations, hang on
[15:30] <mvo> pitti: well, Gio.file_new_for_path works
[15:31] <mvo> pitti: but that is not compatible with the previous version of the Gio interface :/
[15:31] <pitti> mvo: that used to do new_for_commandline_argument() or so, right?
[15:31] <pitti> you could use that, too
[15:31] <mvo> or maybe I'm just using it for the first time now. the last version was "Gio.File.new_for_path"
[15:32] <pitti> mvo: it runs fine in jhbuild, so I suppose our glib typelib is out of date
[15:32]  * mvo checks
[15:32] <pitti> yep
[15:32] <pitti> diff -u /usr/share/gir-1.0/Gio-2.0.gir /home/martin-scratch/gnome/share/gir-1.0/Gio-2.0.gir
[15:32] <pitti> -> all the File.new_for() added
[15:33] <alex3f> pitti, hmm, it's the same in up-to-date master http://pastebin.ubuntu.com/669329/
[15:33] <pitti> mvo: unfortunately that's only my local update, this needs to happen upstream
[15:33] <pitti> alex3f: yeah, just realized that I updated the Gio annotations in my own branch
[15:33] <pitti> alex3f: oh, that crash; I don't get that with my PPA packages, though
[15:33] <pitti> mvo: I'll ask upstream and see to get that updated
[15:34]  * alex3f scans pitti's branches
[15:34] <mvo> pitti: ok, so the correct way is Gio.File.new_for_path() ?
[15:34] <pitti> mvo: yes, the code in s-c is fine
[15:34] <mvo> ok
[15:34] <pitti> mvo: just needs a glib update
[15:34] <pitti> mvo: yesterday I mainly tested it in jhbuild, sorry
[15:35] <seb128> pitti, there is only 4 commits in git since the version we use
[15:35] <mvo> right, any eta for this? I guess I could just disable dynamic Gio for now
[15:35] <seb128> pitti, none seems gir business
[15:35] <pitti> soren: they are built from the gobject-introspection source
[15:35] <pitti> seb128: and as I said, it's just a local refresh
[15:35] <pitti> I'll see to doing that upstream now
[15:35] <seb128> soren, ^ that was for me
[15:35] <pitti> and backport the change
[15:35] <seb128> pitti, oh ok
[15:35] <pitti> sorry soren
[15:36] <pitti> seb128: glib doesn't build its own typelibs, presumably they want to avoid the mutual build dep
[15:36] <seb128> pitti, if you do a glib upload please add a conflicts to wncksyncdaemon
[15:36] <seb128> ok
[15:36] <pitti> seb128: no, I'd do a g-i update
[15:36] <seb128> ok, good
[15:36] <seb128> I will just commit the wncksyncdaemon thing to vcs
[15:36] <seb128> it's on my list for the next update, I just didn't come to do it yet ;-)
[15:40] <pitti> mvo: http://git.gnome.org/browse/gobject-introspection/commit/?id=73077ec28b79c8c3ced2d1ec40255fbf51728817
[15:40] <pitti> mvo: it's been a while since someone did that, unfortunately :/
[15:44] <mvo> uh, ok
[15:44] <mvo> thanks
[15:45] <mvo> could this be automatically run e.g. on build?
[15:45] <pitti> unfortunately not
[15:45] <pitti> it needs the glib sources
[15:50] <pitti> hm, WTH
[15:56] <alex3f> pitti, so the Gio.File.new_for_uri needs newer glib?
[15:59] <pitti> I'm a bit confused; I refreshed the stuff in g-i, but it's still not coming out right
[15:59] <pitti> my stuff in jhbuild is still newer
[16:02] <pitti> ok, seems we need a newer g-i snapshot
[16:04] <seb128> pitti, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1882264/+listing-archive-extra
[16:04] <seb128> pitti, can you score it for me?
[16:05] <pitti> seb128: done
[16:06] <seb128> pitti, danke
[16:09] <smspillaz> desrt: got another question for ya
[16:10] <smspillaz> desrt: gdk_pixbuf_get_from_surface - was that removed in gdk3?
[16:10] <smspillaz> or was it added then
[16:10] <pitti> mvo: aah, I know
[16:10] <pitti> mvo: darn, chicken & egg problem
[16:10] <smspillaz> getting some weird warning when I include gdk/gdk.h saying that this function isn't declared anywhere
[16:10] <pitti> mvo: in our g-i package we have an older version of the glib annotations which work around a bug in pygobject 2.28
[16:11] <pitti> mvo: i. e. I can only fix that by breaking pygobject 2.28
[16:11] <pitti> mvo: I'll upload it to the PPA then
[16:12]  * pitti adds a breaks there then
[16:38] <pitti> seb128: want me to nudge nux in the PPA?
[16:38] <pitti> mvo: uploaded gobject-introspection_1.29.16+git20110818-0ppa1 to ubuntu-desktop PPA which fixes this
[16:39] <seb128> pitti, you mean?
[16:39] <seb128> pitti, you did half an hour ago already?
[16:39] <pitti> seb128: do you need https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719479 urgently/
[16:40] <pitti> ah, so I did
[16:40] <pitti> still 8 mins to go
[16:40] <seb128> pitti, it built on amd64 and i386 builds start in 5 minutes
[16:40] <pitti> nevermind
[16:40] <seb128> pitti, will need an unity nudge soon though ;-)
[16:40] <mvo> pitti: thanks
[16:40] <pitti> well, time to say goodbye now
[16:40] <pitti> 11 hours are 'nuff
[16:41] <pitti> seb128: I'll leave the computer running and check IRC from time to time, to nudge stuff
[16:41] <seb128> pitti, hum ok, well if you are still around in 10 minutes to bump the unity score in the ppa that would be welcome
[16:41] <seb128> pitti, after this one we should be good for today
[16:41] <pitti> seb128: yep, should be fine
[16:41] <seb128> pitti, danke
[16:42] <pitti> so, good night everyone!
[16:42] <seb128> 'night pitti
[16:42] <alex3f> good night Pici
[16:42] <alex3f> *pitti
[16:46] <dupondje> mmmm, last upgrades seems to removed my gtk theme ... any idea ?
[16:52] <dupondje> gnome-themes-standard is installed, but it doesn't seem to work :(
[17:00] <seb128> pitti, https://launchpad.net/~ubuntu-desktop/+archive/ppa/+sourcepub/1882327/+listing-archive-extra bump please
[17:00] <seb128> pitti, then I'm done for the requests for the day ;-)
[17:01] <desrt> so lenovo++
[17:02] <desrt> or (canadian consumer protection laws)++
[17:02] <desrt> not sure which one :)
[17:02] <Pici> goodnight alex3f
[17:03] <seb128> desrt, what did you get them to do? accept to refund you?
[17:03] <desrt> yup.  100% refund.
[17:03] <desrt> ordered a T420 instead
[17:03] <desrt> with straight-up intel
[17:03] <seb128> ;-)
[17:03] <desrt> and a slice battery
[17:03] <desrt> 30 hours, bitches!
[17:04] <desrt> (ha.. ya right)
[17:04] <seb128> impressive ;-)
[17:04]  * desrt does the usual 'divide by 2' estimate and still arrives at an epic 15 hours
[17:11] <mterry> Anyone else having 'failed to execute /lib/udev/input_id' errors on boot (and thus no X) after recent updates?
[17:12] <desrt> mterry: i think jorge was complaining about this yesterday
[17:13]  * mterry checks logs, thanks desrt
[17:13] <mterry> desrt, (in this room by any chance?)
[17:13] <desrt> must have been
[17:13] <desrt> i don't know if it was related
[17:13] <desrt> he was just complaining that his X was borked
[17:13] <seb128> mterry, is that bluetooth input devices?
[17:14] <mterry> I don't know
[17:14] <seb128> ok, there was an udev upload today to fix bluetooth mouse and keyboard handling
[17:14] <seb128> so I figured I would mention it
[17:14] <mterry> Hmm
[17:14] <pitti> seb128: done
[17:14] <seb128> pitti, \o/
[17:15] <seb128> mterry, lp #827489
[17:15] <ubot2> Launchpad bug 827489 in udev "Bluetooth keyboards and mice stopped working in X server" [Undecided,Fix released] https://launchpad.net/bugs/827489
[17:17] <mterry> seb128, hm.  my X doesn't start at all
[17:21] <desrt> has anyone seen ted lately?
[17:24] <seb128> desrt, he timeouted on this channel an hour ago it seems
[17:24] <seb128> desrt, he probably will be back, he might be at lunch
[17:24] <desrt> true.
[17:24]  * desrt is wondering why he hasn't heard anything lately
[17:25] <om26er> seb128, i386 build gave some "chroot problem" :/ https://launchpad.net/~ubuntu-desktop/+archive/ppa/+build/2719587
[17:25] <seb128> om26er, yeah, gobject-introspection had the same issue
[17:26] <seb128> not sure what's going on
[17:26] <seb128> I did a retry
[17:27] <om26er> ok :)
[17:28] <seb128> pitti, if you are still walking by can you rescore unity and gobject-introspection on i386 in the ppa, they failed to build on buildds issues
[17:30] <mterry> heh, nevermind about my X problems, it was my own damn fault, running with a broken custom unity-greeter that I had forgot I had installed
[17:31] <seb128> mterry, ok
[17:31] <seb128> mterry, btw is the current greeter supposed to tell the indicators that they are in greeter mode?
[17:31] <seb128> mterry, seems it doesn't there
[17:31] <mterry> seb128, that's in trunk
[17:32] <seb128> mterry, ok, I will check with robert_ancell if he thinks we should do a tarball
[17:32] <seb128> or maybe I will just snapshot that as well
[17:33] <seb128> seems like trunk doesn't have scary changes
[17:33] <seb128> pitti, unping, got other buildd admins to rescore it ;-)
[17:34] <jcastro> desrt: mine was a glib bug that Sarvatt found, I just needed an update after RAOF uploaded it.
[17:35] <seb128> jcastro, it was not a glib bug, don't scare desrt
[17:36] <seb128> it was one leftover package with a broken .so which was taking glib down
[17:38] <jcastro> oh ok
[17:41] <desrt> seb128: thanks for stepping up =)
[17:42] <seb128> it sucks that any broken gio .so can take your system down though
[17:42] <desrt> same is true for random files in quite a lot of places
[17:43] <desrt> like /usr/share/X11/xorg.conf.d/ i recently discovered =)
[18:08] <micahg> Sweetshark: you forgot to subscribe ubuntu-release to bug 828724, done now
[18:08] <ubot2> Launchpad bug 828724 in libreoffice "[FFE] LibreOffice 3.4 for Oneiric" [Undecided,Confirmed] https://launchpad.net/bugs/828724
[18:19] <dobey> chrisccoulson: so i guess the bindwood update on 11.04 still hasn't made it out of proposed? :(
[18:21] <micahg> dobey: no one has tested it, I requested again someone to verify it
[18:22] <micahg> dobey: if you can get someone to test it, I"ll get it moved to -security/-updates
[18:24] <dobey> micahg: what was the bug # for that? i can't seem tofind it
[18:24] <micahg> dobey: bug 798484
[18:24] <ubot2> Launchpad bug 798484 in moon "Tracking bug for Firefox 5 transition in Natty" [Medium,Fix committed] https://launchpad.net/bugs/798484
[18:27] <dobey> micahg: verified
[18:27] <micahg> dobey: thank you
[18:29] <jbicha> bummer, I had a PPA build fail because of some chroot problem, so I have to wait a dozen more hours...
[18:29] <micahg> dobey: pushed
[18:30] <dobey> thanks
[18:32] <chrisccoulson> dobey, oh, it seems micah already answered
[18:32] <chrisccoulson> micahg, bug 828981
[18:32] <ubot2> Launchpad bug 828981 in firefox "This is a test" [Undecided,New] https://launchpad.net/bugs/828981
[18:32] <chrisccoulson> although, the plugin information is missing atm
[18:32] <chrisccoulson> but most of it is there
[18:32] <dobey> chrisccoulson: yeah, there was a bug about it not working after the firefox 6 update, that came in today :P
[18:33] <micahg> chrisccoulson: wow, that's a lot of info
[18:33] <chrisccoulson> micahg, i'll probably get rid of most of the hardware info
[18:33] <chrisccoulson> i just want the output of lspci really
[18:33] <micahg> dobey: for Firefox 7, can I ping you to test the update and we'll get it pushed on release day?
[18:33] <micahg> if we need one that is
[18:34] <dobey> we'll need one
[18:34] <dobey> chrisccoulson: did you ever get round to trying bindwood on firefox 7? i think you said you were going to
[18:35] <chrisccoulson> micahg, the interesting fields are the "IncompatibleExtensions" ones
[18:35] <chrisccoulson> dobey, not yet
[18:35] <chrisccoulson> that's on my list though, as i'm going to upload the first 7.0 beta to oneiric this week ;)
[18:35] <micahg> chrisccoulson: ooh, I like :)
[18:35] <dobey> chrisccoulson: ok, great
[19:00] <kenvandine> seb128, did you see i fixed the count issue?
[19:00] <seb128> kenvandine, yeah, I saw the upload before going for dinner
[19:00] <seb128> kenvandine, \o/ well done!
[19:00] <kenvandine> should be all around more accurate now
[19:09] <pitti> seb128: back again for a bit, do you still need kicks?
[19:10] <seb128> pitti, no, I'm fine, thanks
[19:10] <seb128> pitti, I will keep it in the ppa for the night
[19:10] <seb128> if people want to run it and tell me tomorrow morning how it goes please do
[19:13]  * pitti dist-upgrades again, so that he'll test it tomorrow morning
[19:15] <pitti> seb128: uh, that wants to remove unity-2d
[19:16] <seb128> pitti, right, because nux broke abi again and we didn't get an unity-2d update yet
[19:16] <seb128> pitti, which is part of the reason it stays in the ppa for today
[19:16] <pitti> I see
[19:17] <seb128> if you use 3d feel free to just upgrade
[19:17] <pitti> yep, will do
[19:17] <pitti> meh, just crashed again anyway..
[19:32] <seb128> pitti, btw you might want to rescore the gobject-introspection i386 build
[19:32] <seb128> pitti, the broken builder got put on manual since
[19:32] <pitti> yep, already done
[19:33] <seb128> great
[19:33] <seb128> pitti, <pitti> meh, just crashed again anyway..
[19:33] <pitti> but even with a higher build score it's still 35 mins
[19:33] <seb128> pitti, was that the new unity?
[19:33] <pitti> no, old one stlil
[19:33] <pitti> still
[19:33] <pitti> now I just need to wait for another crash
[19:33] <pitti> actually, I have nothing running right now
[19:33]  * pitti kills it
[19:35] <pitti> there, that should be the new one
[19:35] <seb128> pitti, easy way to see it, the new dash have most used applications etc under its icons
[19:35] <pitti> hm, the typeahead search is weird now
[19:35] <pitti> "d-f", displays one result (d-feet), but enter doesn't run it
[19:36] <pitti> seb128: hm, I don't see a new icon
[19:36] <pitti> looks exactly like the old one
[19:37] <seb128> pitti, I mean the grid with 6 icons you get when clicking the ubuntu launcher
[19:37] <seb128> you should be able to scroll down and have other things under it
[19:38] <pitti> 6 icons?
[19:38] <pitti> so, the dash has 8 icons
[19:38] <pitti> and my launcher some more
[19:38] <dobey> i think it varies
[19:38] <seb128> do you have a scrollbar on the right of the dash?
[19:38] <pitti> no
[19:39] <seb128> hum
[19:39] <pitti> I'll probably have to restart this sesssion
[19:39] <pitti> killall unity-applications-daemon unity-files-daemon unity-panel-service compiz
[19:39] <seb128> pitti, just run "unity"
[19:39] <pitti> that probably wasn't enough
[19:39] <pitti> alt+f2 "unity" doesn't work, meh
[19:39] <seb128> should have been
[19:39] <seb128> well old unity didn't react to enter, you had to click on the icon
[19:40] <pitti> ok, restarted
[19:40] <pitti> seb128: still looks the same
[19:40] <pitti> seb128: perhaps I use a bigger screen? I have 8 icons in the dash, no scrollbar
[19:41] <pitti> multimedia apps, internet apps, more apps, find files
[19:41] <pitti> second row: surf net, show photos, email, music
[19:42] <seb128> pitti, ok, weird, I've most used applications under those icons on the dash screen
[19:42] <seb128> with most used files
[19:42] <pitti> I have three smaller white icons, too
[19:42] <seb128> those are the lenses
[19:42] <pitti> home, search files/folders, search apps
[19:42] <seb128> those which were in the launcher in natty
[19:42] <pitti> right
[19:42] <seb128> pitti, well anyway, let's see tomorrow
[19:43] <seb128> we need an unity-2d before upload anyway
[19:49] <seb128> pitti, yeah, doesn't work on my 10v either, I wonder why it worked on my laptop earlier
[19:52] <kenvandine> seb128, would it be helpful if i tested from the ppa?
[19:52] <seb128> kenvandine, you are welcome to, it will uninstall unity-2d but otherwise it's a candidate for Oneiric
[19:52] <kenvandine> ok
[19:52] <seb128> so I'm happy to take feedback before the update
[19:52] <seb128> it's supposed to fix a few bugs
[19:56] <pitti> good night
[19:58] <seb128> 'night pitti
[20:27] <jbicha> Sweetshark: are you trying to LO 3.4.1 or 3.4.2 in the archives first?
[20:29] <jbicha> Sweetshark: are you trying for LO 3.4.1 or 3.4.2 in the archives first?
[23:06] <desrt> chrisccoulson_: ping
[23:06] <chrisccoulson_> hi desrt
[23:06] <desrt> there seems to be an extremely critical bug with firefox
[23:06] <desrt> 97/100 on acid 3 :(
[23:07] <chrisccoulson_> desrt, http://robert.ocallahan.org/2010/06/not-implementing-features-is-hard_03.html ;)
[23:08] <desrt> ah
[23:08] <desrt> so those 3 missing points are official policy
[23:14] <desrt> wow
[23:14] <desrt> apple hacked up safari to pass acid 3
[23:14] <desrt> macos has whacked out font antialiasing, and they disable it in safari for a specific font just because they know this font is used in the acid test
[23:15] <desrt> that's pretty lame
[23:27] <lifeless> desrt: WIN :(
[23:28] <desrt> lifeless: does YOUR browser score 100/100 on acid 3?
[23:28]  * desrt almost feels dirty for asking chrisccoulson_ now
[23:29] <chrisccoulson_> heh :)
[23:29] <desrt> chrisccoulson_: how are the toronto boys doing, anyway?
[23:29] <chrisccoulson_> desrt, yeah, pretty good i think
[23:30] <desrt> definitely ready in time?
[23:32] <chrisccoulson_> desrt, they have a new office, so they must be doing good :)
[23:32] <desrt> i mean in terms of meeting the goals for thunderbird
[23:32] <lifeless> desrt: no idea
[23:32] <desrt> lifeless: it was asked in jest...
[23:32] <lifeless> :)
[23:33] <chrisccoulson_> desrt, oh, yeah. thunderbird is the default for oneiric already :)
[23:33] <desrt> how the hell did you find the space, anyway?
[23:34] <chrisccoulson_> desrt, the CD was still a bit oversized when i checked last ;)
[23:34] <chrisccoulson_> but not too bad
[23:34] <chrisccoulson_> desrt, do you read omgubuntu? http://www.omgubuntu.co.uk/2011/08/thunderbird-confirmed-default-mail-app-ubuntu-11-10/ ;)
[23:34] <desrt> no.  not usually :)
[23:35] <chrisccoulson_> heh
[23:35] <chrisccoulson_> that's where i get all my news from now!
[23:35] <desrt> i figure it's a good source
[23:35] <desrt> they often have the scoop about what's going on at UDS before the decision is even made ;)
[23:35] <chrisccoulson_> yeah, that's a problem sometimes ;)
[23:36] <desrt> in fact, for next UDS we should just skip the sessions
[23:36] <desrt> and schedule a time at which we will check OMG ubuntu in order to find out what we will do
[23:36] <chrisccoulson_> lol
[23:37] <bryceh> desrt, :-)