[00:00] <bryce> chrisccoulson, yep that'd do it :-)
[00:01] <bryce> RAOF, interestingly, I think I'm coming to the conclusion that those false gpu lockups no longer exist
[00:01] <bryce> RAOF, we've only had a small handful reported, and after going through them I think they're all mis-reported real gpu lockups
[00:01] <bryce> so, wee
[00:02] <RAOF> :)
[06:01] <BigWhale> Good Morning.
[06:39] <chilicuil> Nice day BigWha.le =)
[06:41] <BigWhale> chilicuil, this is yet to be seen. ;)
[07:16] <didrocks> good morning
[07:49] <pitti> RAOF: colord> ah, thanks
[07:50] <RAOF> If it's a performance problem we could probably delay colord startup.
[07:50] <pitti> RAOF: not a particular one, I'm just on a mission to kill everything from startup which we don't need, and I just wondered
[07:51] <RAOF> It'd need cupsd to not query colord on startup and instead lazy-load stuff, and a patch for gnome-settings-daemon to not query colord if stuff hasn't been set.
[07:57] <pitti> RAOF: so, that's an option we should keep in mind once the more CPU intense stuff (nautilus, notify-osd) have been fixed
[08:04] <pitti> TheMuso: what's the current status of switching openjdk to the apt-spi2 bridge?
[08:04] <pitti> TheMuso: IIRC that mostly needed testing whether it works, right?
[08:07] <didrocks> pitti: are you feeling better, btw?
[08:07] <pitti> didrocks: oh, yes; first night without having to take a decongestant
[08:07] <pitti> didrocks: bonjour
[08:08] <didrocks> pitti: guten morgen!
[08:08] <didrocks> pitti: ah, nice. Hope you will have some restfull night again before the rally :)
[08:13] <TheMuso> pitti: Haven't tested yet, I actually need to find a java app to test with.
[08:15] <pitti> TheMuso: any particular requirements? should be easy to grab a .jar from somewhere and run it
[08:17] <pitti> TheMuso: apt-get install cronometer -> relatively small, but full swing GUI
[08:17] <pitti> and runs without any setup
[08:33] <rickspencer3> hey guys, is any one else getting gsd crashes on Precise?
[08:48] <didrocks> rickspencer3: do you have any issue with your connection?
[08:49] <didrocks> rickspencer3: re your gsd crash: I read some people got some. chrisccoulson was looking at it yesterday
[09:13] <chrisccoulson> good morning everyone
[09:13] <chrisccoulson> the gsd crash could be bug 903973
[09:13] <ubot2`> Launchpad bug 903973 in xorg-server "gnome-settings-daemon crashed with signal 5 in _XReply()" [High,In progress] https://launchpad.net/bugs/903973
[09:14] <chrisccoulson> didrocks, rickspencer3 ^^
[09:14] <didrocks> good morning chrisccoulson, how are you?
[09:15] <TheMuso> pitti: Ok cool, will test next week.
[09:16] <rickspencer3> hi chrisccoulson
[09:16] <rickspencer3> thanks for the link
[09:18] <BigWhale> sudo rm -rf usr/lib/python2.7/dist-packages/kazam/
[09:18] <BigWhale> whoops
[09:23] <seb128> hey
[09:23] <didrocks> salut seb128, ça va ?
[09:24] <seb128> lut didrocks, ca va et toi ?
[09:24] <didrocks> seb128: ça va bien :)
[09:25] <pitti> hey seb128
[09:26] <seb128> hey pitti, wie gehts?
[09:27] <pitti> seb128: je suis bien, merci!
[09:28] <BigWhale> What is this? I can't even ... :>
[09:28] <pitti> BigWhale: C'est un langage drôle!
[09:29] <seb128> pitti, how is your cold? getting better?
[09:29] <pitti> seb128: oh yes, a lot, thanks; should be fine by Sunday :)
[09:32] <didrocks> BigWhale: see, pitti's cold makes him speaking a weird language :)
[09:33] <BigWhale> didrocks, :)) I speak weird language even when I am not cold! ;)
[09:33] <pitti> bazillus frankophonus
[09:33] <BigWhale> :))
[09:50] <tkamppeter> pitti, Bon jour
[09:51] <pitti> tkamppeter: Germans talking French to other Germans? /me quickly checks whether Napoleon is back :)
[09:51] <tkamppeter> pitti, kennst Du Dich mit Python aus?
[09:52] <pitti> tkamppeter: I do a lot in Python, yes
[09:52] <tkamppeter> pitti, can you install hplip-gui on Precise and then run "hp-toolbox"?
[09:53] <seb128> mvo, hey
[09:53] <tkamppeter> pitti, this happens only on Precise, on Oneiric there is no problem. So something is wrong with Python on Precise.
[09:54] <pitti> tkamppeter: what exactly?
[09:54] <tkamppeter> I get
[09:54] <pitti> I get a dialog "No Installed HP Devices Found." which is not quite surprising
[09:54] <pitti> tkamppeter: i. e. what should I look out for?
[09:54] <tkamppeter> Traceback (most recent call last):
[09:54] <tkamppeter>   File "/usr/bin/hp-toolbox", line 37, in <module>
[09:54] <tkamppeter>     from base.g import *
[09:54] <tkamppeter> ImportError: No module named base.g
[09:55] <tkamppeter> The file /usr/share/hplip/base/g.py is there and in HPLIP nothing changed compared to Oneiric.
[09:55] <pitti> hm, where does it set sys.path, though?
[09:55] <mvo> hey seb128, I think I found the solution for my problem, the window is not displayed anymore when the crash happens
[09:58] <pitti> tkamppeter: I added a "print sys.path" right before the import, and /usr/share/hplip is the first entry; so looks ok from here
[09:58] <pitti> tkamppeter: ooh, it's because /usr/bin/hp-toolbox is a symlink to ../share/hplip/toolbox.py
[09:58] <pitti> tkamppeter: it always adds the directory of the program to the library path
[09:59] <tkamppeter> pitti, can it be that Precise's has a bug? The symlink was always there, also in Oneiric and older.
[09:59] <pitti> tkamppeter: perhaps you have a local version where /usr/bin/hp-toolbox is not a symlink/
[09:59] <pitti> ?
[09:59] <pitti> tkamppeter: what does ls -l /usr/bin/hp-toolbox say for you?
[10:00] <tkamppeter> pitti, yes, it is a real copy in Precise.
[10:00] <pitti> tkamppeter: I just installed the package in precise, and it's a link
[10:00] <seb128> mvo, ok, great, ken find the issue in gwibber as well, it doesn't seem a bug in gtk after all, just that the new code is less tolerant to those errors
[10:00] <tkamppeter> pitti, does "perl -p -i -e 's/.../.../' <symlinkk>" turn the symlink into a copy?
[10:01] <pitti> $ dpkg -c /var/cache/apt/archives/hplip-gui_3.11.10-1ubuntu3_all.deb | grep hp-toolbox
[10:01] <pitti> lrwxrwxrwx root/root         0 2012-01-06 01:27 ./usr/bin/hp-toolbox -> ../share/hplip/toolbox.py
[10:01] <pitti> tkamppeter: the .deb is okay
[10:01] <seb128> mvo, in gwibber he didn't cancel a callback which was making it update an image sometime while it was been disposed
[10:01] <pitti> tkamppeter: are you sure that you don't have a local version, or a "make install" or so?
[10:01] <pitti> tkamppeter: sounds possible
[10:01] <tkamppeter> pitti, I am testing the not yet uploaded 1ubuntu4.
[10:03] <tkamppeter> pitti, There I have added
[10:03] <tkamppeter> perl -p -i -e 's:^\s*\#\!/usr/bin/env\s+python.*:#!/usr/bin/python:' ./\
[10:03] <tkamppeter> debian/tmp/usr/bin/* ./debian/tmp/usr/sbin/* ./debian/tmp/usr/lib/cups/*/*
[10:03] <tkamppeter> to debian/rules, to fix bug 912625.
[10:04] <ubot2`> Launchpad bug 912625 in hplip "#!/usr/bin/env python breaks Python-based Ubuntu packages in the presence of virtualenvs, local installations" [Medium,In progress] https://launchpad.net/bugs/912625
[10:04] <pitti> tkamppeter: yep
[10:04] <pitti> $ echo hello > real
[10:04] <pitti> $ ln -s real link
[10:04] <pitti> $ perl -pi -e 's/hello/goodbye/' link
[10:04] <pitti> -rw-rw-r-- 1 martin martin 8 Jan  6 11:04 link
[10:05] <tkamppeter> pitti, this is a bug in perl
[10:05] <mvo> seb128: yeah
[10:05] <pitti> tkamppeter: try perl -pi -e .... `readlink -f file`
[10:05] <seb128> mvo, I knew it, it's all your fault and not gtk's one!!! ;-)
[10:06] <seb128> mvo, you are always trying to drag the good gtk name in the mud! ;-)
[10:07] <tkamppeter> pitti, yes, that's it. Thank you.
[10:10] <mvo> seb128: … ;)
[10:19] <pitti> didrocks: I'm trying to test the upstream nm-applet; I already added it to the panel whitelist, but I get a message
[10:19] <pitti> ** Message: applet now removed from the notification area
[10:19] <pitti> didrocks: this string is not from nm-applet itself; does it ring a bell?
[10:20] <pitti> didrocks: if not, don't worry, I'll investigate (or just start the fallback session)
[10:21] <pitti> ah, I can just run gnome-panel in my unity session to see it
[10:21] <didrocks> hum, yeah, it rings a bell
[10:21] <pitti> didrocks: so, nevermind
[10:21] <didrocks> isn't it the indicator?
[10:21] <didrocks> with fallback
[10:21] <pitti> didrocks: upstream doesn't have indicator support, I guess
[10:21] <pitti> I'm running from upstream trunk
[10:21] <didrocks> pitti: oh, it's without the indicator
[10:21] <didrocks> ok
[10:21] <didrocks> so, let me have a quick look at gnome-panel
[10:22] <pitti> I usually develop fixes in upstream trunk first, and then port them to ubuntu
[10:22] <pitti> better revision control, easier to forward upstream, and faster build cycles
[10:22] <pitti> didrocks: don't worry, I'll just run it from gnome-panel
[10:22] <pitti> I just need to see the applet
[10:22] <seb128> pitti, what name did you whitelist?
[10:22] <pitti> (working on boot speed, not visual)
[10:22] <pitti> seb128: "nm-applet"
[10:23] <seb128> pitti, check the .xsession-errors log
[10:23] <didrocks> seb128: it's not that message anyway with the reject
[10:23] <pitti> seb128: nothing there
[10:23] <seb128> didrocks, didn't it use to tell the name of what got blocked?
[10:24] <didrocks> seb128: yeah, it's something like "rejecting (Xwindoname)"
[10:24] <didrocks> but not "applet now removed…"
[10:24] <seb128> didrocks, right, I was looking for where "nm-applet" is the correct name
[10:25] <seb128> where->whether
[10:25] <didrocks> yeah, it's not easy to get the right Xwindow name
[10:25] <didrocks> but if there is nothing in .xsession-errors about a reject
[10:25] <seb128> well seems like it stopped printing rejects
[10:25] <didrocks> http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg2566236.html
[10:25] <seb128> I just tried with vino
[10:25] <didrocks> -> seems to be an icon theme issue
[10:26] <didrocks> http://ubuntuforums.org/showthread.php?t=1602997 as well
[10:26] <didrocks> pitti: don't you have the icon missing as in the thread?
[10:27] <didrocks> oh nevermind, I misread
[10:27] <pitti> didrocks: well, it does work fine in gnome-panel, so I think not
[10:29] <didrocks> pitti: ok, it's maybe just rejected and unity stopped printint the name, as seb told
[10:29] <didrocks> Nm-Applet or nm-applet to whitelist
[10:29] <didrocks> (need the X window info)
[10:30] <pitti> didrocks: is there a magic "whitelist all" entry, for testing whether it's that or something else, OOI?
[10:30] <pitti> didrocks: tried these and Nm-applet, no change
[10:30] <didrocks> pitti: indeed, just set ['all']
[10:30] <didrocks> pitti: you need to restart unity
[10:31] <didrocks> the new setting is not picked up
[10:31] <pitti> ah
[10:31] <pitti> hm, not just unity-panel-service
[10:31] <pitti> didrocks: ok, rebooting then (want to test the new polkit anyway)
[10:32] <didrocks> pitti: no, libunity-misc is in the compiz process
[10:32] <didrocks> not in the panel service, unfortunately
[10:33] <didrocks> pitti: seb128: FYI, it's not under the debug magic variable
[10:33] <didrocks> s/not/now/
[10:33] <didrocks> so yeah, not printed by default
[10:34] <pitti> anyway, no need to waste more time on this -- this can just be tested in gnome-panel
[10:34] <pitti> which is painless and quick
[10:36] <rickspencer3> pitti, hey
[10:38] <rickspencer3> pitti, I'm seriously confused ...
[10:38] <rickspencer3> I just updated my laptop to 12.04 ...
[10:38] <rickspencer3> and I can't find *anything* wrong with it
[10:39] <rickspencer3> pitti, any issues I should check for?
[10:39] <pitti> rickspencer3: did you actually upgrade? :-)
[10:39] <chrisccoulson> if (username == "rickspencer3") { dontbreak(); }
[10:39] <tkamppeter> pitti, all working with HPLIP on Precise now, thanks for the help.
[10:39] <rickspencer3> lol
[10:39] <rickspencer3> well done
[10:39] <chrisccoulson> :)
[10:40]  * rickspencer3 tries user switching
[10:40] <pitti> rickspencer3: oh, there's this release critical bug!
[10:40] <pitti> rickspencer3: the unity-greeter wallpaper says "11.10"!!!111!!
[10:40] <pitti> tkamppeter: gern geschehen :)
[10:41] <rickspencer3> pitti, STOP THE LINE!
[10:42] <pitti> rickspencer3: seriously, we do have a couple of upgrade bugs still, and some RC bugs as well (https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus#rcbugs)
[10:43] <rickspencer3> pitti, I don't recall having an upgrade to a *stable* release going this smoothly
[10:43] <pitti> rickspencer3: but I don't think we actually _introduced_ a lot of major bugs into precise so far, most of above are already from previous releases
[10:43] <rickspencer3> does this mean that we haven't actually changed anything? ;)
[10:43] <pitti> rickspencer3: we actually did
[10:43] <ogra_> should we just stop here and release precise next week ?
[10:43] <pitti> but the new automatic upgrade tests, also with main-all, helped immensely
[10:43] <pitti> we fixed a ton of upgrade bugs
[10:43] <rickspencer3> ogra_, yeah, I am wondering that ;)
[10:44] <ogra_> :)
[10:45] <pitti> didrocks: FTR, 'all' helped, I see it now; thanks!
[10:45] <didrocks> pitti: great! yw ;)
[10:47] <pitti> didrocks: oh, I know
[10:47] <pitti> WM_CLASS(STRING) = "lt-nm-applet", "Lt-nm-applet"
[10:47] <pitti> didrocks: running from trunk, it's the libtool wrapper :)
[10:47] <didrocks> pitti: ahah, funny :-)
[10:48] <didrocks> you can chase for a long time for the right name to put!
[10:48] <pitti> 'all' is much easier indeed
[10:51] <didrocks> yeah ;)
[10:54] <pitti> ok, notify-osd killed harder
[10:54] <rickspencer3> pitti, nice!
[10:55] <pitti> it already fell out of the boot sequence on my thinkpad, but was still on my dell mini for some reason
[11:08] <seb128> pitti, wifi against eth?
[11:08] <pitti> nope, both system-wide wifi connection
[11:09] <pitti> seb128: I'm actually not sure how I evaded notify-osd on my laptop
[11:09] <pitti> it queries server caps right at startup
[11:09]  * pitti adds another noWerror.patch to fix FTBFS, *sigh*
[11:27] <pitti> cyphermox: argh, I can't push to n-m-applet bzr; can you please pull lp:~pitti/network-manager-applet/precise into lp:~network-manager/network-manager-applet/ubuntu.head ?
[11:29]  * ogra_ wonders why all the -common packages from the desktop seed suddenly take over 20min to unpack on arm 
[11:29] <pitti> lots of help files, I guess?
[11:29] <ogra_> evo-common took even 45min
[11:29] <ogra_> pitti, that wasnt the case on oneiric, ubuntu-docs and gnome-user-docs were the only two that did that
[11:30] <ogra_> but suddenly i see it in evince-common and evo-common too
[11:30] <pitti> hmm; they didn't really change a lot since oneiric
[11:30] <pitti> different kernel sync behaviour?
[11:30] <ogra_> did they switch to some evil compression mechanism ?
[11:30] <ogra_> like xz
[11:30] <pitti> ogra_: is it any better with eatmydata?
[11:30] <pitti> ogra_: no
[11:30] <ogra_> kernel is the same as in oneiric
[11:30] <pitti> try unpacking the oneiric .deb and compare?
[11:31] <pitti> evolution-common | 3.2.2-0ubuntu0.1 | oneiric-proposed | all
[11:31] <pitti> evolution-common | 3.2.2-0ubuntu3 |       precise | all
[11:31] <pitti> not much diff there
[11:31] <ogra_> well, i cant play with eatmydata atm, system needs all resources (i'm happy i can still type on IRC)
[11:31] <ogra_> i'll try that for the next update
[12:06] <pitti> mvo: do we also set $RELEASE_UPGRADE_IN_PROGRESS for lucid->precise upgrades?
[12:06] <pitti> mvo: I'm pondering bug 911813
[12:06] <ubot2`> Launchpad bug 911813 in lightdm "Lucid to Precise: debconf prompt about which DM to use during upgrade" [Medium,New] https://launchpad.net/bugs/911813
[12:06] <pitti> if [ -z "$2" -a -n "$RELEASE_UPGRADE_IN_PROGRESS" ]; then
[12:06] <pitti> mvo: ^ if that's true, we don't ask
[12:06] <pitti> mvo: and lightdm is new, so -z "$2" ought to be true
[12:07] <pitti> log has "Selecting previously unselected package lightdm." which confirms this
[12:08] <pitti> mvo: and history.log has it in "install", not in "upgrade"
[12:10] <mvo> pitti: hm, odd. we do set this when the release upgrader is used:         os.environ["RELEASE_UPGRADE_IN_PROGRESS"] = "1"
[12:10] <pitti> mvo: oh, wait -- this might actually be a debconf question from gdm, not from lightdm
[12:11]  * pitti checks gdm
[12:12] <pitti> mvo: yeah, I think that's it
[12:12] <pitti> mvo: sorry for disturbing, thinko :)
[12:13] <pitti> mvo: seems the upgrade logs don't show which debconf questions are asked and shown, do they?
[12:23] <mvo> pitti: unfortuantely not, but that would be a neat addition
[12:26] <pitti> mvo: btw, do you plan an apt upload before a2?
[12:29] <mvo> pitti: yes, I was talking to slangasek about it, but there are some issues in the current bzr that needs to get resolved first
[12:39] <stgraber> mvo: I'm also looking forward to a newer apt (for multi-arch reasons), I currently have a custom build in my PPA to be able to install an i386 upstart in an armel container, though there are still bugs in apt preventing it to work as well as it should
[12:40] <stgraber> IIRC mostly has to do with considering provides of another architecture (for upstart-jobs for example)
[12:41] <stgraber> oh and we have that other bug currently affecting ia32-libs where apt doesn't consider winbind:amd64 as a potential candidate to meet the dependencies and so fails to install ia32-libs unless you explicitly ask for "ia32-libs winbind:amd64"
[12:48] <mvo> stgraber: is that fixed with trunk?
[12:49] <stgraber> mvo: last time I cherry-picked a commit from the experimental bzr branch
[12:49] <stgraber> mvo: well, for the one commit I needed, I don't know if the ia32-libs problem has been fixed in trunk
[12:50] <stgraber> mvo: might be worth building the current trunk so everyone who's been having multi-arch related weirdness can check if that's fixed
[12:52] <stgraber> mvo: I believe the commit I had to cherry pick to be able to install upstart:i386 on armel was this one http://bazaar.launchpad.net/~donkult/apt/experimental/revision/2187.1.6
[12:53] <stgraber> so yeah, that specific one seems to be in the trunk (according to the comment in that commit, rev2189 of mainline)
[13:42] <Beret> hi all
[13:45] <cjwatson> Can anyone help me with bug 912563?  I'm disregarding the NM crash for now and looking at the partman part of the crash (see near the end of the syslog) because I know that better and it looks similar; I'm as certain as I can be that ubiquity never stores None into that column of the tree model, because it would crash immediately afterwards if it did, but pygobject seems to be returning None
[13:45] <ubot2`> Launchpad bug 912563 in ubiquity "ubiquity crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Confirmed] https://launchpad.net/bugs/912563
[13:46] <cjwatson> In particular I believe that the only code that ever adds rows to that model is ubiquity/plugins/ubi-partman.py lines 1208 and 1215, which are immediately followed by code that would crash if None:
[13:46] <cjwatson>                 partition_tree_model.append([item, disk_cache[item]])
[13:46] <cjwatson>                 dev = disk_cache[item]['device']
[13:46] <cjwatson>                 partition_tree_model.append([item, partition_cache[item]])
[13:46] <cjwatson>                 size = int(partition_cache[item]['parted']['size'])
[13:46] <cjwatson> is it possible that pygobject is losing references somewhere or something?
[13:48] <seb128> pitti, ^ seems something pygobjectish, you are probably the best placed there to have a clue about it ;-)
[13:51] <seb128> cjwatson, are you sure you don't have null values in a column of the model which is supposed to have strings?
[13:52] <seb128> cjwatson, it seems that pygobject was tolerant to that but that http://git.gnome.org/browse/pygobject/commit/gi/overrides/Gtk.py?id=654711d0f940d7480d0f1cdb25a3dc9996f7a706 made it not like it
[13:52] <seb128> you could argue that there is a pygobject bug that null values should be supported
[13:52] <pitti> re (sorry, was at lunch)
[13:52] <pitti> looking
[13:52] <seb128> cjwatson, the s-c pointed which had a similar bt was fixed by https://code.launchpad.net/~kiwinote/software-center/bug905605/+merge/87257 which sets '' rather that nothing
[13:52] <seb128> s-c bug
[13:53] <pitti> but None values in models ought to work
[13:53] <seb128> pitti, than pygobject bug
[13:53] <seb128> pitti, http://git.gnome.org/browse/pygobject/commit/gi/overrides/Gtk.py?id=654711d0f940d7480d0f1cdb25a3dc9996f7a706 makes it not work
[13:53] <pitti> where?
[13:53] <seb128> it should check for None
[13:53] <pitti> type_ == GObject.TYPE_STRING should be false then
[13:53] <seb128> + value = value.decode('UTF-8')
[13:53] <cjwatson> seb128: (a) I'm as certain as I can be, and yes I did read that commit (b) the partman part of this bug isn't a case of a string column anyway
[13:53] <pitti> for None
[13:54] <seb128> pitti, it's the column type
[13:54] <seb128> not the field type
[13:54] <cjwatson> it's an object column that apparently contains None and ubiquity itself crashes on that because that's supposed to be impossible heree
[13:54] <cjwatson> *here
[13:54] <seb128> pitti, if you have a string column and a None value in the model you get value = Nanoe.decode('UTF-8')
[13:55] <pitti> oh, right
[13:55] <pitti> that's a bug indeed
[13:55] <cjwatson> the NM part of the bug is a case of None in a string column; again, as far as I can tell ubiquity never stores that, but I'm deferring looking at that for now since I don't know the client code there as well
[13:55] <pitti> so yes, I think we should fix that in pygobject
[13:55] <cjwatson> I agree, but that isn't all of this bug
[13:55] <pitti> need to condense it to a small test case
[13:57] <seb128> cjwatson, sorry I looked to backtrace on the bug first, that's one valid bug even if that's not the one you asked about ;-)
[13:57] <seb128> looking to the other one...
[13:57] <jbicha> pitti: did you experience this week's sudoku crash on oneiric also or just precise?
[13:57] <pitti> jbicha: haven't tried on oneiric
[13:58] <cjwatson> seb128: a pygobject change would make the NM-related backtrace go away, but I'm still not sure None is supposed to be there in the first place ...
[14:00] <seb128> pitti, do you have any clue about the "TypeError: argument of type 'NoneType' is not iterable" errors in https://launchpadlibrarian.net/89179568/syslog?
[14:01] <seb128> cjwatson, do you have a testcase out of running easier than trying to do an install from a liveCD?
[14:01] <seb128> (just in case)
[14:01] <cjwatson> I wish I did :-(
[14:01] <pitti> seb128: partition == None
[14:01] <seb128> -"out of running"
[14:01] <pitti> you can't iterate over None
[14:01] <cjwatson> pitti: see what I wrote above
[14:02] <cjwatson> pitti: as far as I can tell, ubiquity can never store None into that model in that column.  If it ever did, it would crash immediately after doing so, and it is not doing that.
[14:02] <pitti> right, that's the other part
[14:02] <cjwatson> pygobject is giving back None when that's not what ubiquity put into the model
[14:02] <cjwatson> that's *the* part :-)
[14:10] <pitti> ok, have a test case for the pygobject None mishandling, will continue on that later
[14:11]  * pitti boots daily image to reproduce
[14:18] <pitti> cjwatson: I tried the back button a few times, but I don't seem to get _this_ crash (trying to delete an unknown partition got me another, but let's stay on this one for the moment)
[14:18] <pitti> cjwatson: do you know how to reproduce this?
[14:19] <cjwatson> afraid not :-(
[14:19] <pitti> and clicking "New partition table" doesn't do anything, hmm
[14:20] <cjwatson> unless Kate's thing about having a chkdsk-requiring Windows partition is implicated someho
[14:20] <cjwatson> w
[14:38] <pitti> cjwatson: in fact, I think the software-properties crash is exactly the same (also not supposed to be None), and trivial to reproduce
[14:38] <pitti> it should be _("Other...") and is None
[14:39] <pitti> cjwatson: so it looks like a dupe of bug 905602
[14:39] <ubot2`> Launchpad bug 905602 in pygobject "software-properties-gtk crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,In progress] https://launchpad.net/bugs/905602
[14:39] <cjwatson> phew
[14:39] <pitti> (I reassigned the s-props one to pygobject, working on that now)
[14:49] <cyphermox> pitti: thanks, I merged it
[14:49] <pitti> cyphermox: ah, "pull" for better history and correct tags, but *shrug*; thanks!
[14:50] <cyphermox> pitti: yeah, I had some stuff on my local branch too :/
[14:50] <cyphermox> dah, I should have pulled and then merged my changes on top, d'oh
[14:50] <pitti> rebase FTW
[14:51] <cyphermox> I'll say, "moo"?
[14:51] <cyphermox> didn't know there was rebase for bzr
[15:20] <pitti> cjwatson: hm, back to square one, I think; I analyzed the s-properties problem, and it's because that pygobject patch always changes the returned data type, so a previously working comparison against a str value doesn't work any more
[15:20] <pitti> cjwatson: I think this patch should be reverted completely, as the original justification was wrong (will talk to upstream about it)
[15:20] <pitti> cjwatson: but that still doesn't explain why there are None values
[15:21] <pitti> cjwatson: they might be None values because somewhere the ubiquity code runs into the same trap (expecting str where it now gets unicode)
[15:21] <pitti> but for that it would really be helpful to be able to reproduce this, so maybe skaet still remembers how to do that
[15:22] <pitti> skaet: ^ if you have a way to reproduce which I can't easily replicate here, I'd like to walk you through a few tests
[15:22]  * skaet looking
[15:22] <pitti> skaet: bug 912563 I mean
[15:22] <ubot2`> Launchpad bug 912563 in ubiquity "ubiquity crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Confirmed] https://launchpad.net/bugs/912563
[15:23] <skaet> pitti, cjwatson,  I think I can.   I'll be bringing the system to budapest with me.
[15:24] <skaet> monday ok?
[15:24] <pitti> skaet: sure
[15:24] <cjwatson> the objects in question shouldn't be either str or unicode
[15:24] <cjwatson> at least for the partman bit of the bug
[15:25] <pitti> cjwatson: ah, interesting; then it's completely unrelated to that pygobject commit
[15:25] <cjwatson> ah well; note I won't be in Budapest, but maybe Evan can help out with ubiquity-specific bits
[15:25] <pitti> ok, I'll revert that one then, and investigate the ubiquity one in Budapest then
[15:25] <cjwatson> thanks
[15:31] <pitti> cjwatson: still curious, though; if the affected column type is not a string, then I really don't see how it should get past the type_ == GObject.TYPE_STRING check (as it crashes in the then clause)
[15:34] <pitti> mvo: so, I'll upload a pygobject which should also fix the software-center crash, in case you want to revert the workaround
[15:36] <cjwatson> pitti: I think you're looking at a different traceback
[15:37] <pitti> cjwatson: I thought we were talking about bug 912563 ; you mean something else then?
[15:37] <ubot2`> Launchpad bug 912563 in ubiquity "ubiquity crashed with AttributeError in _decode_value(): 'NoneType' object has no attribute 'decode'" [High,Confirmed] https://launchpad.net/bugs/912563
[15:37] <jibel> mvo, https://jenkins.qa.ubuntu.com/job/precise-softwarecenter-amd64/lastCompletedBuild/testReport/
[15:38] <jibel> mvo, I skipped test_downloader and will add gtk3 tests.
[15:43] <pitti> didrocks: when is the next unity SRU round planned?
[15:44] <mvo> pitti: aha, nice, I'm curious about the diff that fixed it
[15:44] <mvo> jibel: thanks
[15:44] <cjwatson> pitti: look at the partman tracebacks in the UbiquitySyslog attachment
[15:44] <pitti> mvo: reverted http://git.gnome.org/browse/pygobject/commit/gi/overrides/Gtk.py?id=654711d0f940d7480d0f1cdb25a3dc9996f7a706
[15:45] <pitti> mvo: it's breaking existing behaviour, inconsistent with the rest of Gtk, and the original test case in the bug was invalid
[15:46] <didrocks> pitti: it's pushed in the ubuntu-desktop ppa right now (like 30 minutes ago)
[15:46] <didrocks> pitti: will be pushed in -proposed next week, once we will have the precise unity release
[15:48] <pitti> cjwatson: ah, so let's retitle the bug accordingly?
[15:48]  * pitti does
[16:14] <BigWhale> A question!
[16:14] <dobey> *gasp*
[16:14] <dobey> :)
[16:14] <BigWhale> http://gstreamer.freedesktop.org/wiki/GStreamerHackfest2012 Will gstreamer1.0 land in Pangolin?
[16:14] <dobey> ah that i do not know
[16:15] <dobey> pitti, seb128: ^^ have we decided on gstreamer versions?
[16:15] <dobey> skaet: ^^
[16:16] <pitti> there was no explicit discussion/decision for this
[16:16] <pitti> if it lands well before FF and doesn't cause major issues, it's fine to update
[16:16] <seb128> no plan concerning gstreamer
[16:17] <seb128> we didn't "maintain" it for years, slomo is doing good work maintaining it in Debian and we sync what they use
[16:17] <dobey> pitti: i think it's parallel installable, so i'd guess there'd be gstreamer1.0 source vs gstreamer0.10, in debian?
[16:17] <seb128> he's part of the upstream teams
[16:17] <dobey> right
[16:18] <seb128> well it's seems not likely that we will use by default for the lts
[16:18] <pitti> dobey: right, but we wouldn't want to have two sources
[16:18] <dobey> and i suspect even if it landed, there'd be a period where some things haven't ported yet, so you'd have to keep both versions around, just like gtk2 vs gtk3
[16:18] <seb128> it seems incompatible and it's late to land a new serie and port the code
[16:18] <dobey> pitti: not on the CD, surely
[16:18] <pitti> if we switch, then everything should be switched over IMHO, otherwise it's a mess
[16:18] <seb128> not for the lts then...
[16:18] <pitti> at least for main/default install
[16:18] <dobey> yeah
[16:18] <pitti> that's my gut feeling anyway
[16:18] <seb128> we can probably get it in universe for people who want to use it
[16:18] <pitti> ^ sure
[16:19] <seb128> well I'm sure slomo will get it in Debian when it's time
[16:19] <seb128> then we can sync
[16:19] <dobey> seb128: question is if some of gnome 3.4 stuff we ship, will require it, i guess
[16:19] <seb128> no
[16:19] <pitti> I think we'd rather stay at the gnome 3.2 version in that case
[16:19] <seb128> we stay on totem 3.0 to avoid clutter
[16:19] <dobey> oh
[16:20] <dobey> totem uses clutter now?
[16:20] <seb128> yes
[16:20] <seb128> clutter-gst instead of xv for rendering
[16:20] <dobey> ugh
[16:20] <seb128> since 3.2
[16:21] <BigWhale> crap ... why do I have to give names to milestones? :/
[16:21] <dobey> well you have to call a milestone something
[16:22] <dobey> they don't have to be names like "Ed" or anything
[16:22] <dobey> they can be versions
[16:22] <BigWhale> yeah I know
[16:22] <BigWhale> still :>
[16:22] <dobey> like, for ubuntu one, we have milestones for all our releases throughout the whole precise cycle
[16:22] <dobey> our next one is 2.99.2 on jan 17
[16:23] <BigWhale> it's like hostnames.... 10% of time you spent on installing new computer, 90% of the time you spent on thinking about which hostname to pick ...
[16:23] <dobey> i really don't spend that much time thinking about hostnames
[16:24] <dobey> and it's fairly easy to deal with, if you have a theme
[16:24] <dobey> which most people do :)
[16:24]  * BigWhale cringes.
[16:24] <BigWhale> now you're expecting me to have a theme!? :>
[16:31] <dobey> well you could name them after different species of sea mammals, for all i know :)
[16:35] <BigWhale> dobey, that would be a little too self centered ;)
[16:35] <BigWhale> even for me :P
[16:44] <pitti> good night everyone!
[16:47] <didrocks> good night pitti! see you in budapest!
[16:47] <pitti> yay, you too!
[16:47] <pitti> will arrive Sunday early evening
[16:47] <pitti> looking forward to a relaxed and uninterrupted 8 hour train ride
[16:48] <cyphermox> nice
[16:48] <cyphermox> pitti: good night, see you sunday
[16:49] <pitti> have a nice (half) weekend and safe travels everyone!
[16:52] <seb128> 'night pitti, see you there!
[17:19] <dobey> well, they are *your* computers, no? :)
[17:22] <dobey> err
[17:22] <dobey> BigWhale: ^^
[17:22] <dobey> has anything changed recently with zeitgeist in precise?
[17:22] <seb128> that's a question for mhr3
[17:22] <seb128> define "recently"
[17:22] <seb128> what is your issue?
[17:24] <BigWhale> dobey, oh ... computers perhaps, but not software milestones. :))
[17:24] <dobey> in the past few days i guess, we have started having ubuntuone-client tests freezing for a long time, in ppa builds
[17:24] <dobey> seb128: https://launchpadlibrarian.net/89241325/buildlog_ubuntu-precise-i386.ubuntuone-client_3.1%2Br1176-47~precise1_FAILEDTOBUILD.txt.gz
[17:25] <BigWhale> dobey, my computers are currently thefish, ocean and squid :)
[17:25] <BigWhale> oh and pinky :>
[17:26] <dobey> seb128: and it was sat at "test_log_records_the_event ...                                         [OK]" for over an hour before whatever finally killed the process
[17:27] <seb128> hum, "fun"
[17:27] <seb128> dobey, no zg for around a month
[17:27] <seb128> but maybe something due to the new glib? which knows... or a race
[17:27] <seb128> hard to tell without a stacktrace of the hang
[17:28] <dobey> yeah, it's odd, because the tests pass fine for me just running them on my laptop
[17:28] <mhr3> dobey, seb128, i blame gvfs for any such issues
[17:29] <mhr3> i pushed just today a patch that disables any volume monitoring in zeitgeist
[17:31] <dobey> that wouldn't be it
[17:33] <dobey> could be glib i guess
[17:35] <mhr3> you'd be surprised about the "fun" bugs it caused
[17:35] <dobey> not really
[17:36] <dobey> it's glib and everything uses it. no surprise at all if it causes weird bugs in random things :)
[17:37] <didrocks> ok, time for sport and half week-end there. Have a safe travel and see you in budapest!
[17:38] <BigWhale> is there a wordpress plugin that would automatically create links to launchpad bug entries?
[17:38] <dobey> probably
[17:41] <dobey> https://launchpad.net/wordpress-launchpad-integration
[17:41] <BigWhale> yeah I've found that one
[17:42] <BigWhale> but I am not sure it does what I want it to do
[17:42] <dobey> oh, it's auth
[17:42] <BigWhale> yeag
[17:44] <dobey> so perhaps not
[17:45] <dobey> probably easy to write something that does, though
[18:01] <seiflotfy> seb128: rodrigo_: how do i turn off the deprecation flags in clutter-gtk
[18:01] <seb128> seiflotfy, grep DEPRECATED *
[18:01] <seb128> it's likely set in configure.ac or Makefile.am
[18:01] <seb128> then edit it out
[18:01] <seb128> run autoreconf and build again
[18:01] <seb128> ?
[18:02] <rodrigo_> seiflotfy, yes, probably what seb128 says
[18:04] <kenvandine> hey rodrigo_!
[18:04] <rodrigo_> hi kenvandine
[18:04] <rodrigo_> kenvandine, happy new year :)
[18:05] <kenvandine> happy new year to you too
[18:05] <kenvandine> :)
[18:06] <dobey> hola rodrigo_
[18:06] <rodrigo_> hey dobey
[18:06] <dobey> seb128: are they the new style, or the old style?
[18:06] <dobey> err
[18:06] <dobey> seiflotfy: ^^
[18:07] <seiflotfy> dobey: what style what huh?
[18:08] <dobey> seiflotfy: in new versions of gtk+, deprecations are done differently, so i was wondering if clutter-gtk was switched as well. they use attributes on functions now, instead of blocks of #ifndef in the headers
[18:08] <dobey> seiflotfy: is api missing, or are you trying to get rid of warnings?
[18:08] <seiflotfy> i am compiling clutter-gtk 0.12
[18:08] <seiflotfy> whihc is kinda old but i have to
[18:09] <dobey> oh
[18:09] <seiflotfy> let me show you the error
[18:10] <seiflotfy> dobey: http://pastebin.com/D91SnS6c
[18:11] <seiflotfy> grep for deprecated doesnt return anything
[18:11] <dobey> seiflotfy: add "-Wno-error=deprecated-declarations" to CFLAGS
[18:12] <kenvandine> seiflotfy, or fix gtk-clutter-viewport.c
[18:12] <kenvandine> looks like just one thing
[18:12] <dobey> or yeah, patch it
[18:12] <kenvandine> use g_type_init
[18:13] <dobey> kenvandine: well, gcc stops on the first file with errors :)
[18:13] <dobey> or just don't use -Werror
[18:13] <kenvandine> that is evil
[18:13] <dobey> the gcc thing, or not using -Werror?
[18:14] <kenvandine>  -Werror
[18:14] <dobey> most people don't use it
[18:14] <dobey> we have to use -Wno-error=deprecated-declarations in u1 stuff, actually
[18:15] <dobey> or write a crapload of #ifdef using code
[18:15] <kenvandine> sure
[18:15] <dobey> and frankly, i don't want to write a crapload of code :)
[18:16] <seiflotfy> kenvandine: thanks :)
[18:20] <BigWhale> and I'm back ... I have to do something about my cat ... :/
[18:20] <dobey> sell it
[18:20] <mdeslaur> get it it's own computer
[18:20] <BigWhale> or just prevent Mr. Spock sleeping on my modem ...
[18:21] <dobey> removal of the problem is the surest way to solve it :)
[18:22] <dobey> sigh
[18:22] <dobey> and building this source in pbuilder works correctly
[18:23] <dobey> so wtf is going on
[19:04] <aquarius> in the Power Settings in Precise, "Hibernate" is available as an option for "when the lid is closed", but disabled. Can I enable it? (I'd much rather use suspend, but suspend doesn't work on this laptop yet, and hibernate does.)
[19:10] <cyphermox> aquarius: just guessing, but I'd say hibernate is disabled because there are probably tests running to check whether that's supported on your hardware, and those tests possibly fail. but I haven't looked
[19:10] <aquarius> cyphermox, I can imagine that, yeah; I'm happy to update those tests, or feed back information... but I don't know where to look.
[19:10] <cyphermox> ok
[19:10] <cyphermox> now that I'm looking at it I see hibernate is disabled here too
[19:11] <dobey> aquarius: it appears that something in precise has broken hibernate pretty much everywhere. it doesn't show up in the shutdown dialog for me either.
[19:12] <dobey> i guess maybe it's a kernel bug?
[19:13] <kenvandine> i am not certain, but i know at one point there was talk about disabling it because we couldn't reliably know if hibernate would work
[19:13] <cyphermox> kenvandine: yeah, I remember that too
[19:13] <cyphermox> aquarius: fwiw: http://paste.ubuntu.com/795199/
[19:13] <cyphermox> that's in gnome-control-center, panels/power/cc-power-panel.c
[19:13] <dobey> kenvandine: which sucks, because you can't reliably know if *anything* is going to work
[19:13] <kenvandine> and i think someone was pushing the idea of making it use a whitelist, so it was only enabled on certified hardware
[19:13] <dobey> kenvandine: so we might as well just disable boot too :)
[19:14] <cyphermox> kenvandine: interesting
[19:14] <kenvandine> hibernate has been a particularly problematic thing though
[19:14] <cyphermox> yup
[19:14] <aquarius> kenvandine, yeah, I remember reading about that; I'm happy to say "look, my laptop's on the list" :)
[19:14] <cyphermox> support gets called for hibernate not working on certified hardware, that's guaranteed
[19:14] <kenvandine> cyphermox, well i think the whitelist idea had lots of opposers
[19:14] <aquarius> but suspend definitely doesn't work (cking's looking at it) and in the interim... I can't close the lid of my laptop. Which is mot annoying :(
[19:15] <cyphermox> kenvandine: yeah, I think the more safe idea was to disable it altogether, based on how boot should normally be fast enough, and suspend "usually works", iirc
[19:15] <dobey> kenvandine: so has suspend to ram :-/
[19:15] <cyphermox> aquarius: let me check if I can make some sense of the test, and maybe tell you why it fails
[19:15] <cyphermox> (hibernate)
[19:16] <dobey> hibernate worked perfectly fine on my u820 in oneiric
[19:16] <cyphermox> aquarius: worst case though, I guess you could try to use pm_hibernate on the cli and then close the lid
[19:16] <dobey> but neither nibernate nor suspend works now in precise on it
[19:16] <aquarius> cyphermox, that's exactly what I *am* doing
[19:17] <aquarius> cyphermox, which I can live with if I have to
[19:17] <cyphermox> ok :)
[19:17] <cyphermox> well, the exact test is somewhere in upower
[19:17] <dobey> guess i should make a launcher for pm_hibernate
[19:17] <aquarius> but it's a lot easier to just shut the lid, which I'd do if I wasn't explicitly blocked from turning on hibernate as an action there :(
[19:17] <cyphermox> ah but
[19:17] <dobey> and i can call it "Go the Fuck to Sleep"
[19:17] <cyphermox> nothing happens at all if you close the lid or is it that suspend starts and crashes ?
[19:18] <dobey> for me, nothing happens at all if i just close the lid
[19:18] <dobey> because i closed it to test suspend after upgrading
[19:19] <dobey> lit up the keyboard pretty well though
[19:19] <aquarius> cyphermox, suspend does not work (that is: the machine hangs when trying to suspend. Bug already reported and the kernel team are looking at it). I have not closed the lid exactly because lid-close is set to "suspend", and suspend doesn't work.
[19:19] <cyphermox> ok
[19:19] <cyphermox> There used to be the "don't do anything" option
[19:19] <cyphermox> wonder why that's no longer there
[19:20] <cyphermox> oh, I'm not looking at the right place
[19:20] <dobey> yeah, i'm pretty sure that's still there
[19:20] <cyphermox> it is
[19:20] <cyphermox> I was looking at my desktop -- no lid
[19:20] <dobey> heh
[19:20] <cyphermox> so no lid actions :)
[19:22] <cyphermox> ok, so the checks seem to be this:  can the kernel hibernate, is there enough swap, and !(swap is encrypted) || allow hibernate on encrypted swap
[19:23] <dobey> hmm
[19:24] <cyphermox> swap needs to be less than 98% used or something
[19:26] <cyphermox> and whether kernel support is available is based on the output of pm-is-supported --hibernate
[19:26] <aquarius> top says that there's 4GB of swap and it's 0k used
[19:26] <cyphermox> huh, same on my desktop
[19:26] <aquarius> pm-is-supported --hibernate doesn't output anything.
[19:26] <cyphermox> and clearly it's supported
[19:26] <cyphermox> return code, I meant
[19:27] <kenvandine> aquarius, echo $?
[19:27] <aquarius> kenvandine, 0
[19:27] <aquarius> I tried that :)
[19:29] <dobey> aquarius: how much RAM does that machine have?
[19:30] <cyphermox> wait, this doesn't make sense
[19:30] <aquarius> Mem:   3952048k total / Swap:  4094972k total,        0k used
[19:30] <aquarius> there is sufficient swap to contain all the memory.
[19:30] <cyphermox> upower reports canHibernate = 1 on my desktop, but the item is disabled anyway
[19:30] <cyphermox> d-feet on the system bus can tell you that
[19:33] <aquarius> did we just, like, disable it regardless of whether the system says it can support it? I remember reading a bug where design said "well, hibernate doesn't work all that well so we should turn it off"
[19:33] <dobey> yeah, i have 2GB swap and 1GB RAM on this laptop
[19:33] <dobey> aquarius: it would appear to be the case
[19:34] <aquarius> But if that were the case, I could understand removing it from the menu. But leaving something in the menu which is disabled almost always means that users think (me included) that there's some way to *enable* that menu item
[19:34] <aquarius> hence me asking: how do I enable that menu item ;)
[19:36] <dobey> ugh, but pm-{suspend,hibernate} requires root
[19:36] <cyphermox> aquarius: still looking, but I can't find where it might have been disabled
[19:37] <aquarius> mysterious.
[19:37] <aquarius> looks like I'll have to continue with "sudo pm-hibernate" from a terminal then :(
[19:37] <dobey> of course, now i've done pm-suspend, and i can't make it un-suspend
[19:40] <cyphermox> pitti would probably be the best person to tell you why it's disabled, given his involvement in upower and patches to g-c-c, etc.
[19:41] <aquarius> cyphermox, thanks; that gives me somewhere else to look
[19:48] <dobey> well that UI is added with a patch. but it's odd, since i don't see in that patch any code that checks if hibernate is available, and it doesn't seem to set it to insensitive by default