[07:09] <pitti> Good morning
[07:18] <and471> goooooood morning!
[08:31] <devildante> hi all
[08:42] <pitti> vish: btw, I uploaded a new gnome-power-manager to maverick yesterday, which moved to a more standard icon naming schema; but that means that we need to update our ubuntu icons accordingly
[08:42] <pitti> presumably renaming them
[09:05] <pitti> seb128: gnome-session> sure, my pleasure
[09:06] <fta2> hi
[09:06] <fta2> seb128, d'oh! http://launchpadlibrarian.net/53152059/buildlog_ubuntu-maverick-i386.chromium-codecs-ffmpeg_0.6%2Bsvn20100730r54382%2B54907-0ubuntu1~ucd1_CHROOTWAIT.txt.gz
[09:06] <seb128> pitti, thanks
[09:07] <seb128> fta2, yes, we are discussing it on #ubuntu-devel
[09:07] <seb128> robert_ancell uploaded a broken glib
[09:07] <fta2> k
[09:34] <pitti> seb128, robert_ancell: (low-prio) do you know about gnome-session's 80_new_upstream_session_dialog.patch ? it's not really documented in the changelog and doesn't have patch headers
[09:35]  * pitti monkey-ports it for now
[09:35] <seb128> pitti, it's a different design of the session dialog
[09:36] <seb128> which is coming from vuntz and opensuse and was supposed to go upstream but didn't
[09:36] <pitti> I think I ported it now; I'll test it
[09:37] <seb128> thanks
[09:37] <seb128> you can display it if you don't have the indicator session by using the gnome-panel logout items
[09:37] <seb128> or press the power button
[09:38] <seb128> should display it as well
[09:38] <pitti> right, ctrl+alt+del does
[09:38] <pitti> ok, I'll make sure it still looks alright
[09:43] <robert_ancell> seb128, no
[09:46] <vish> pitti: hi , actually it was broken earlier [i think in gpm] , the icons were named according to the standard scheme.. but not sure what might have changed recently , can i see a diff to check what changed and name it accordingly?
[09:50] <pitti> vish: hang on, I'll collect them
[09:51] <vish> thanks..
[10:00] <pitti> vish: so, http://git.gnome.org/browse/gnome-power-manager/commit/?id=52821a4b944a69a6eaca420ecce1f9e65ebd6891 is the main one
[10:01] <pitti> http://git.gnome.org/browse/gnome-power-manager/commit/?id=1d893d3b8825e1df6401ec95e4af2252a9d6ae37
[10:01] <pitti> http://git.gnome.org/browse/gnome-power-manager/commit/?id=e97f8b11d0ac0870d7c29ee444fc1764a30e38ee
[10:01] <pitti> those are the other ones
[10:01] <pitti> the third is probably irrelevant, though
[10:01] <vish> pitti: cool , thanks ,i'll check them
[10:15] <and471> mpt, hey, are you still busy or can you test a fix for the software list view? I think I have it sussed :)
[10:16] <mpt> and471, ok, what's the branch?
[10:17] <and471> mpt, ah mvo just merged it so it should be in trunk
[10:18] <and471> mpt, I also fixed the partner logo bug (where it seemed bigger than the other icons) and redid the ppa icon :)
[10:19] <mpt> and471, cool, I didn't know you were a graphic designer too
[10:19] <and471> mpt, well from time to time.... :D
[10:30] <mpt> and471, that selection fix looks good, well done
[10:31] <and471> mpt, thankyou :)
[10:31] <and471> mpt, I'm gonna write a test now so that it doesn't regress :)
[10:31] <mpt> good good
[10:32] <mpt> Hm, has it always been impossible to expand "Get Software" and "Installed Software" with the Right arrow key?
[10:43] <and471> mpt, I don't know, never tried to
[10:43] <and471> mpt, why, do you want it to be able to?
[10:45] <mpt> and471, yes
[10:45] <mpt> for accessibility
[10:46] <and471> mpt, let me check if this is possible
[10:46] <pitti> seb128: new gnome-session works well, uploading now
[10:47] <and471> mpt, do you mean expand with right key when the + icon is clicked, or expand with right key when the whole row is clicked?
[10:47] <pitti> seb128: so gdm is the last thing which still needs libdevkit-power-gobject1; I'll have a look at this
[10:47] <seb128> pitti, thanks
[10:47] <pitti> since this library has been dropped upstream now
[10:47] <mpt> and471, I don't understand the question
[10:47] <pitti> and thus blocks upower upgrades
[10:48] <mpt> and471, I mean when any item that has children is selected (e.g. "Get Software" or "Installed Software"), Right should expand it and Left should collapse it
[10:48] <mpt> If the + icon is clicked you're not using the keyboard anyway :-)
[10:49] <and471> mpt, ah sorry, I see in the scrollback you said 'arrow key'
[10:49] <and471> mpt, I read 'right click' :)
[10:49] <pitti> seb128: any idea why 2.30.4 wasn't uploaded yet?
[10:50] <and471> mpt, ok so when I have selected 'Installed Software' and I click the right arrow key, it should expand, and when I click the left arrow key it should collapse?
[10:50] <seb128> pitti, I got some race issues leading to have no user shown sometime
[10:50] <seb128> but I guess we should upload and deal with those
[10:50] <seb128> feel free to upload
[10:50] <seb128> other people have been running it without issue
[10:50] <mpt> and471, exactly
[10:50] <seb128> and it didn't happen to all my boxes
[10:51] <pitti> seb128: ok; I'll check 2.31 if it introduces gsettings or gtk3 (or did you already?)
[10:51] <and471> mpt, and what happens if I expand 'Installed Software', go down to 'Provided by Ubuntu' and then click the right arrow key/left arrow key?
[10:51] <seb128> I didn't
[10:51] <seb128> pitti, but I would stay away from 2.31 for now
[10:51] <pitti> seb128: oh? ok
[10:51] <seb128> since we don't know if gdm guys plan to roll a tarball from the 2.30 series for 2.32
[10:52] <seb128> options for 2.32 with the delay are to roll from 2.30 and keep working toward 3 in trunk
[10:52] <seb128> or do a 2.32 series
[10:52] <seb128> it's up to the maintainers
[10:52] <seb128> a bit of a mess...
[10:53] <seb128> but that's sorting up itself now that a decision has been taken
[10:53] <seb128> let's wait for the next tarball though
[10:53] <pitti> seb128: ok, going with 2.30.4 then
[10:53] <seb128> thanks
[10:53] <pitti> no upower port in upstream git head, anyway
[10:53] <pitti> so I'll check the fedora package/bugzilla/etc.
[10:54] <seb128> ok
[10:54] <seb128> pitti, so can we sort the buildds or do we need to wait for lamont to be there?
[10:54] <pitti> seb128: well, anyone with buildd chroot handling powers
[10:54] <pitti> but AFAIK that's by and large lamont (and maybe elmo)
[10:54] <seb128> that's different from buildd admin?
[10:55] <pitti> as buildd-admin I can rescore builds, stop/start buildds, etc.
[10:55] <pitti> but I don't have access to the actual servers, to manage the chroot tarballs
[10:55] <seb128> ok
[10:55] <pitti> and if I had, I wouldn't know how/what to do, sorry :/
[10:55] <seb128> that's ok
[10:56] <seb128> is there any chance one of the buildds doesn't have dconf installed?
[10:56] <seb128> ie is it worth retrying to get a different machine picked for the build?
[10:56] <pitti> seb128: no, it's not
[10:56] <seb128> ok
[10:56] <pitti> seb128: the chroots as they are don't have dconf and still have the old glib
[10:56] <pitti> seb128: the problem is that the chroot tarball is unpackaged, and then it runs a dist-upgrade before it starts the package build
[10:57] <pitti> that dist-upgrade picks up the new glib and dconf,
[10:57] <pitti> and it's the dist-upgrade that breaks
[10:57] <seb128> ok
[10:57] <pitti> so either we need to do a build without dist-upgrade
[10:57] <pitti> or do a dist-upgrade in the chroots and hit them over the head to work
[10:57] <seb128> ok, let's wait for lamont then
[10:57] <pitti> porting gdm to libupower seems trivial, I'll have a go at it
[10:57] <seb128> thanks
[10:58] <pitti> I did my share of work this week (due to long hours on release), so I might as well do something fun today :)
[10:58] <seb128> ;-)
[10:59] <asac> seb128 killed the archive/builders again ;)?
[10:59] <asac> what gcc bug id is that?
[10:59] <asac> "- use -O0 to workaround compiler bug leading to crashes
[10:59] <asac> "
[11:00] <asac> i guess someone from our toolchain folks needs to look at that?
[11:02] <mpt> and471, that should still collapse it, I think
[11:05] <ronoc> seb128: hey, has anyone else had X troubles after a distupgrade this morning
[11:05] <ronoc> I can't get X running on maverick
[11:06] <seb128> ronoc, I guess you got the buggy glib which makes everything crash on i386
[11:06] <ronoc> nice :)
[11:06] <seb128> asac, it was not me, I even sent an email yesterday to say to not upload glib until that's sorted
[11:06] <ronoc> seb128: is there any work around ?
[11:06] <seb128> but apparently the issue doesn't happen on amd64
[11:06] <seb128> ronoc, downgrade glib
[11:07] <ronoc> seb128: to which version ?
[11:07] <seb128> 2.25.11-1ubuntu3
[11:07] <ronoc> thx seb
[11:07] <seb128> ronoc, sorry about that
[11:07] <ronoc> back shortly hopefully on maverick
[11:08] <ronoc> no worries, part and parcel of software dev
[11:11] <pitti> . o O { make -j4 on a fast quad-core is fun! }
[11:12] <seb128> asac, I'm trying to build on gcc-4.5 now
[11:14] <seb128> pitti, same issue with gcc-4.5
[11:15] <pitti> seb128: so, might be a glib regresssion after all?
[11:16] <seb128> could be
[11:16] <asac> seb128: ok. if you have a gcc bug or something i can ask someone from our toolchain hackers to maybe look
[11:16] <seb128> asac, debian bug #591075
[11:16] <ubot2> Debian bug 591075 in libglib2.0-0 "libglib2.0-0: segfaults in postinst script (i.e. installation fails), reportbug/python, emacs, etc." [Grave,Open] http://bugs.debian.org/591075
[11:17] <seb128> asac, see current comment
[11:17] <asac> oh its not only us
[11:17] <asac> hmm
[11:18] <seb128> right
[11:18] <asac> seems lool is aware
[11:18] <asac> so they are probably on it
[11:18] <seb128> is he?
[11:18] <seb128> thanks
[11:20] <seb128> brb
[11:24] <asac> seb128: lool filed the debian bug ;)
[11:25] <seb128> oh, right ;-)
[11:29] <asac> seb128: maybe it would be good to add this problem to topic or send email to -devel?
[11:29] <asac> or is all fine now that buidlers are stopped?
[11:29] <seb128> we blocked the binaries on the mirrors
[11:29] <seb128> and the builders are stopped
[11:29] <seb128> couldn't hurt to message the issue as well I guess
[11:29] <seb128> I will drop an email on ubuntu-devel
[11:34] <and471> mpt, fixed, could you test? https://code.launchpad.net/~and471/software-center/fix-keypresses-on-viewswitcher
[11:44] <ronoc> seb128: apt-get install libglib2.0.0=2.25.11-1ubuntu3 couldn't find that version ?
[11:45] <seb128> ronoc, you need to get on launchpad it's not on the mirror now since it has been replaced
[11:45] <ronoc> seb128: manually install it ?
[11:47] <seb128> ronoc, yes, get the debs from launchpad
[11:47] <seb128> ronoc, https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.11-3ubuntu1/+build/1879944
[11:47] <seb128> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.11-3ubuntu1/+build/1879944/+files/libglib2.0-0_2.25.11-3ubuntu1_i386.deb
[11:47] <seb128> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.11-3ubuntu1/+build/1879944/+files/libglib2.0-bin_2.25.11-3ubuntu1_i386.deb
[11:47] <seb128> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.11-3ubuntu1/+build/1879944/+files/libglib2.0-bin_2.25.11-3ubuntu1_i386.deb
[11:47] <seb128> https://edge.launchpad.net/ubuntu/+source/glib2.0/2.25.11-3ubuntu1/+build/1879944/+files/libglib2.0-data_2.25.11-3ubuntu1_all.deb
[11:47] <seb128> you might need the -dev as well for your box
[11:50] <didrocks> good morning (well, sort of ;)) there!
[11:51] <ronoc> seb128: thx
[11:52] <Riddell> gnome dudes: does evolution show HTML e-mails by default?
[11:52] <pitti> hey didrocks; late morning for you :)
[11:53] <pitti> Riddell: yes; I certainly didn't enable it manually, and I see HTML mails
[11:53] <and471> pitti, Riddell, yep it is on by default
[11:54] <Riddell> is this controvertial at all?  does it lead to security problems?
[11:55] <pitti> it didn't come up so far; but HTML email should be relatively harmless
[11:55] <pitti> it would be a huge risk if it would run JavaScript by default
[11:56] <didrocks> pitti: heh, right, I'm in the Alps, at my parent's home
[11:57] <Riddell> pitti: what about phishing attacks?  wouldn't it make that much easier?
[11:58] <pitti> Riddell: by being colorful?
[11:58] <pitti> what do you mean?
[11:59] <Riddell> by making an e-mail use the logo and branding of your bank
[12:01] <seb128> hey didrocks, you missed all the fun today
[12:01] <didrocks> seb128: which means? real fun or bad news? :)
[12:02] <seb128> didrocks, broken glib segfaulting on i386
[12:02] <seb128> still being dealt with
[12:02] <didrocks>  seb128: urgh, yeah, that's some definition of "fun" :)
[12:02] <seb128> just for the record I'm not to blame
[12:03] <pitti> sudo dpkg -P libdevkit-power-gobject1
[12:03] <seb128> I even dropped an email before going to bed to say the new version was crashing for me and in debian
[12:03]  * pitti whistles
[12:04] <didrocks> seb128: when did the issue happened? yesterday evening? (as I dist-upgraded and don't get any issue there)
[12:04] <seb128> didrocks, no, this morning around 9
[12:04] <seb128> robert_ancell did the upgrade
[12:04] <seb128> didrocks, we blocked the binaries to be downloaded now
[12:05] <didrocks> seb128: ok, so not a lot of people had the time to download it, fortunately
[12:05] <seb128> right
[12:05] <seb128> and it's only 32bits arch
[12:05] <seb128> "only"
[12:05] <asac> lol
[12:05] <asac> all builders got disabled though ;)
[12:05] <didrocks> ahah "only" ;)
[12:05] <asac> err not only i396 i mean
[12:06] <asac> so really all 32-bit
[12:13] <seb128> didrocks, btw your new clutter -dev should depends on json-glib-dev
[12:14] <seb128> didrocks, seems kamstrup had issues with that today
[12:14] <didrocks> seb128, oh yeah, I only fixed the build-dep, not the -dev
[12:14] <kamstrup> seb128, didrocks: yeah
[12:14] <didrocks> kamstrup,  seb128, thanks, I'm finishing backlogging email and will work on that
[12:14] <kamstrup> pkg-config --cflags clutter-1.0 doesn't work unless json-glib is installed
[12:14] <didrocks> (and fixing weechat to connect directly to IRC as I turned my server off)
[12:15] <kamstrup> didrocks, ok, no problem
[12:15] <didrocks> kamstrup, yeah, we switched to system one now
[12:15] <didrocks> sorry about that :)
[12:16] <kamstrup> didrocks, no problem, I figured it out eventually! But autotools was screwing me over, because they failed silently, giving me an empty CFLAGS variable, causing my builds to fail with "No such file glib.h"
[12:16] <didrocks> kamstrup, argh, that was the trap :-)
[12:16] <kamstrup> so I scrutinized glib packaging, until I started suspecting autotools, which lead me to clutter
[12:17] <kamstrup> yeah, that's autohell for you :-)
[12:17] <didrocks> heh
[12:49] <and471> hi nessita, how is the dialog coming along?
[12:54] <nessita> hello and471!
[12:54] <nessita> I though you were off today :-)
[12:54] <nessita> thought*
[12:55] <and471> nessita, yeah, turns out I am off tomorrow :)
[12:55] <nessita> and471: the dialog is coming very good :-)
[12:55] <nessita> how are you?
[12:56] <and471> nessita, good :) getting stuck in with some testing and other bug fixes for SC
[12:56] <and471> nessita, I have started doing gui tests for SC, as my teacher could you mark my homework? https://code.launchpad.net/~and471/software-center/dont-test-me
[13:03] <nessita> and471: I will indeed, but I'm not sure I'd be able today
[13:04] <nessita> and471: we're running against the clock with USC (ubuntu-sso-client)
[13:04] <and471> nessita, ah ok sorry, I will let you get on :)
[13:04] <nessita> and471: is ok :-)
[13:05] <didrocks> chrisccoulson: hey, any idea about bug #576991? It makes gnome-shell not able to be launched (see bug #611262)
[13:05] <ubot2> Launchpad bug 576991 in gnome-shell (Ubuntu Maverick) (and 5 other projects) "Add a wrapper for LD_LIBRARY_PATH to gnome-shell so we don't have to rebuild gjs for xulrunner updates (affects: 4) (heat: 58)" [Medium,In progress] https://launchpad.net/bugs/576991
[13:05] <ubot2> Launchpad bug 611262 in gnome-shell (Ubuntu) "[Maverick] Mutter warning - Could not load /usr/lib/mutter/plugins/libgnome-shell.so (affects: 1) (heat: 482)" [Undecided,New] https://launchpad.net/bugs/611262
[13:08] <seb128> Riddell, hey, do you have time for a quick newing?
[13:08] <Riddell> seb128: if you ask nicely
[13:09] <seb128> Riddell, could you please review zeitgeist-extensions for didrocks?
[13:09] <seb128> I'm still fighting the glib breakage
[13:09] <Riddell> let me look
[13:09] <didrocks> seb128: Riddell: thanks :)
[13:09] <didrocks> seb128: good luck!
[13:10] <seb128> Riddell, I've reviewed it before upload so it should be ok, newing to main if you can, it's a split of zg code
[13:10] <seb128> didrocks, thanks
[13:10] <chrisccoulson> didrocks - yeah, i've been meaning to get around to it at some point
[13:10] <didrocks> Riddell: just for the record, we only ship the fts extension right now (as discussed with kamstrup)
[13:10] <chrisccoulson> we break gnome-shell with every firefox upload
[13:10] <didrocks> chrisccoulson: yeah, GS is "broken" for people, and it seems to hide an other break because of my clutter update with system js :)
[13:11] <didrocks> json*
[13:13] <nessita> seb128: hello there! have a few minutes?
[13:13] <Riddell> didrocks: accepted
[13:13] <didrocks> Riddell: thanks a lot :)
[13:13] <Riddell> the source anyway, binaries still to come I expect
[13:14] <didrocks> Riddell: do you want me to ping you once built?
[13:14] <seb128> nessita, hey
[13:14] <Riddell> didrocks: I don't mind, you're the one who wants it approved :)
[13:15] <didrocks> Riddell: hehe, I will so. Thanks :)
[13:15] <seb128> nessita, sort of, I'm trying to sort the glib breakage in maverick, but you can ask your question ;-)
[13:15] <nessita> seb128: I just wanted to confirm if you could build the 0.0.4 version of ubuntu-sso-client that I sent at the end of the platform sprint
[13:16] <seb128> nessita, you want me to test if it builds fine there or to get it uploaded?
[13:17] <seb128> nessita, I tried the deb you sent me, I can try to build the source now if you want
[13:17] <nessita> seb128: I want to know if you uploaded to the repo
[13:18] <seb128> I didn't
[13:18] <seb128> you want me to do it?
[13:18] <nessita> seb128: hum.... no thanks, we'll be releasing another package today or Monday, so it's fine
[13:18] <seb128> ok
[13:19] <seb128> sorry I though it was just meant for me to test locally
[13:19] <seb128> I didn't get that you wanted it uploaded
[13:19] <nessita> seb128: is ok :-)
[13:19] <nessita> I wasn't clear enough
[13:20] <seb128> nessita, you should practice your french so I can understand you better next time ;-)
[13:20] <nessita> jajaja
[13:20]  * nessita writes down
[13:20] <seb128> nessita, ;-)
[13:21] <nessita> seb128: "s'il vous plait, je veux le .deb subie a le repositorie"
[13:21] <didrocks> seb128: you see, she even speaks "your French" (which is kind of Deutsch were you live ;))
[13:21]  * didrocks runs away
[13:21] <nessita> didrocks: well said! :-D
[13:22]  * seb128 slaps didrocks
[13:22] <seb128> nessita, I understand the start of what you wrote then you became lazy and it makes no sense
[13:23] <seb128> that's the issue with you I think, you should try to not be lazy ;-)
[13:23] <nessita> seb128: how do you say "upload to the repository"?
[13:23] <and471> nessita, I think it is along the lines of 'google translate'
[13:23] <and471> XD
[13:23] <nessita> and471: but that takes all the fun away
[13:23] <nessita> this way I get to invent tn
[13:24] <nessita> tons of words*
[13:24] <and471> nessita, my french teacher would be horrified if she knew what I just said xD
[13:24] <and471> nessita, a bit of espanfranglais?
[13:25] <nessita> and471: tried that, but seb128 is too picky :-P
[13:26] <seb128> nessita, try "pousser dans l'archive"
[13:29] <seb128> pitti, glib crashes without any distro change as well
[13:30] <pitti> sounds like gdb time then?
[13:30] <seb128> the compiler knows about the issue, it's annoying "//usr/include/bits/string3.h:86:3: warning: call to __builtin___memset_chk will always overflow destination buffer"
[13:30] <pitti> seb128: aah -fstack-protector
[13:30] <pitti> I bet that building with -fno-stack-protector will not crash then
[13:31] <seb128> that would explain why the ./configure && make works
[13:31] <pitti> yep
[13:31] <seb128> still an upstream bug I guess
[13:31] <pitti> sometimes I wish we would use -Werror more :)
[13:32] <pitti> seb128: yes, absolutely; in which file does that happen?
[13:32] <seb128> gobject/gsignal.c:77
[13:32] <seb128> 5:49:
[13:32] <seb128> /usr/include/bits/string3.h:86:3: warning: call to __builtin___memset_chk will always overflow destination buffer
[13:33] <seb128>  
[13:33] <seb128> pitti,
[13:33] <seb128> In file included from //usr/include/string.h:642:0,
[13:33] <seb128>                  from gobject/gsignal.c:29:
[13:33] <seb128> In function ‘memset’,
[13:33] <seb128>     inlined from ‘g_bsearch_array_create’ at glib/gbsear
[13:33] <seb128> charray.h:137:10,
[13:33] <seb128>     inlined from ‘g_signal_init’ at gobject/gsignal.c:77
[13:33] <seb128> 5:49:
[13:33] <seb128> /usr/include/bits/string3.h:86:3: warning: call to __builtin___memset_chk will always overflow destination buffer
[13:33] <seb128>  
[13:33] <seb128> that's from the build log
[13:34]  * pitti git clones
[13:35] <seb128> but those functions didn't change between 2.25.11 and 2.25.12
[13:35] <pitti> hm, gsignal.c:29 is #include <string.h>
[13:35] <seb128> those sources didn't change
[13:36] <pitti> hm, so maybe that was a red herring then
[13:37] <pitti> seb128: where does the segfault actually happen? do you have a gdb trace?
[13:38] <seb128> yes, one sec
[13:40] <seb128> pitti, http://paste.ubuntu.com/474018/
[13:40] <seb128> #6  0x008b3ac2 in memset () at //usr/include/bits/string3.h:86
[13:40] <seb128> #7  g_bsearch_array_create ()
[13:40] <seb128>     at glib2.0-2.25.12/glib/gbsearcharray.h:137
[13:40] <seb128> #8  g_signal_init () atglib2.0-2.25.12/gobject/gsignal.c:775
[13:45]  * pitti tries to have two debugging conversations at the same time; back now
[13:50] <pitti> seb128: hm, I have stared at that code for 5 mins now, and I don't see what's wrong
[13:51] <pitti> -  barray = (GBSearchArray *) g_realloc (NULL, size);
[13:51] <pitti> +  barray = (GBSearchArray *) g_malloc (size);
[13:51] <pitti> that was the code change, which presumably led to the crash
[13:51] <seb128> when did that change?
[13:51] <pitti> ba6be2035d9bd43b1a873492e189d0bccbd20178
[13:51] <pitti> Fri Jun 5 23:24:28 2009 -0400
[13:51] <seb128> I doubt it
[13:51] <pitti> .11 was after that?
[13:51] <and471> don't know if you got this : <and471> mpt, fixed, could you test? https://code.launchpad.net/~and471/software-center/fix-keypresses-on-viewswitcher
[13:52] <seb128> pitti, it was on Jul 11
[13:52] <pitti> ok
[13:52] <pitti> seb128: but that's the only difference to gbsearcharray.h
[13:52] <seb128> yeah, I don't get it either
[13:53] <pitti> size should always be > sizeof (GBSearchArray)
[13:53] <seb128> the debian bug suggests it's a compiler issue
[13:54] <mpt> and471, sorry, I got as far as branching it but then forgot it
[13:54] <pitti> seb128: I can't explain it otherwise; the code looks fie
[13:54] <pitti> seb128: then again, why does .11 work??
[13:54] <seb128> replacing the g_malloc, memset with a g_malloc0 workaround the warning but it still crashes
[13:55] <and471> mpt, no problem, there is no rush
[13:56] <seb128> pitti, the 2.25.11 log has no "overflow destination buffer" for some reason
[13:56] <pitti> seb128: ok, maybe the code is organized slightly different there, so that it doesn't trigger the bug
[13:58] <mpt> and471, perfect.
[13:58] <mpt> and471, works exactly as expected
[13:59] <mpt> and471, bwahaha, I just discovered another selection bug
[13:59] <seb128> http://launchpadlibrarian.net/53144885/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu1_FULLYBUILT.txt.gz is the buggy build log
[13:59] <pitti> seb128: oh, wait
[13:59] <pitti> seb128: perhaps G_BSEARCH_UPPER_POWER2(n) produces the wrong result here?
[14:00] <and471> mpt, you evil genius... ;)
[14:00] <mpt> and471, select an item in a software list view, then use Ctrl+click to deselect it. The "More Info" and "Install"/"Remove" buttons should disappear, but they don't.
[14:01]  * and471 goes back to the software-center code...
[14:01] <seb128> pitti, but that didn't change between 2.25.11 and 2.25.12 either
[14:01] <pitti> seb128: no, wrt. compiler bug
[14:01] <pitti> seb128: do you have a built tree?
[14:01] <seb128> yes
[14:01] <pitti> seb128: if you drop teh G_BSEARCH_ARRAY_ALIGN_POWER2 from static const GBSearchConfig g_signal_key_bconfig, does it still crsah?
[14:02] <pitti> i. e. replace it with 0
[14:02] <seb128> pitti, let me try
[14:06] <seb128> pitti, sorry taking a bit, my machine starts being loaded with builds
[14:06] <and471> mpt, If you Ctrl+Click on any item in the software list view it will pseudo-select it as well :(
[14:12] <seb128> pitti, ok, that sort of fix it
[14:14] <pitti> seb128: does that still produce the fortify warning?
[14:14]  * pitti is curious what "sort of" means
[14:14] <seb128> no it doesn't
[14:14] <seb128> in fact it has the same effect that the -O0 build I did early
[14:14] <seb128> it fixes that crash
[14:14] <seb128> but I get another one
[14:14] <pitti> but that's interesting data
[14:14] <pitti> so we can conclude that DISABLE_MEM_POOLS is not set
[14:15] <pitti> and more importantly that
[14:15] <pitti> #define G_BSEARCH_UPPER_POWER2(n)       ((n) ? 1 << g_bit_storage ((n) - 1) : 0)
[14:15] <pitti> returns a smaller value than its input
[14:15] <pitti> and since the compiler could figure this out at compile time, perhaps g_bit_storage always returns 0?
[14:15] <seb128> pitti, http://paste.ubuntu.com/474034/
[14:16] <pitti> seb128: it might stumble over the misaligned buffer now?
[14:16] <seb128> could be
[14:16] <pitti> seb128: I wonder if you could gdb this, and check what this actually does to size:
[14:16] <pitti> size = G_BSEARCH_UPPER_POWER2 (size);
[14:16] <pitti> (with turning the option back on)
[14:17] <seb128> what option?
[14:17] <pitti> seb128: sorry, not aligment
[14:17] <seb128> you mean undoing the change?
[14:17] <pitti> seb128: the G_BSEARCH_ARRAY_ALIGN_POWER2 which you replaced with 0
[14:18] <pitti> seb128: ah, sorry, not alignment; that constant is mislabeled
[14:18] <pitti> it's filling up the size up to the next power of 2, not the alignment
[14:18] <pitti> seb128: I'd bet that G_BSEARCH_UPPER_POWER2 (size) returns 0, or 1, or something very small with -O2, and works with -O0
[14:19] <pitti> aaah
[14:20] <pitti> seb128: glib/gutils.h, g_bit_storage() indeed has completely different code with defined(__OPTIMIZE__)
[14:20] <seb128> I need to break at the right place in gdb
[14:20] <seb128> trying to do that
[14:20] <pitti> seb128: I'll boot my i386 VM and check the g_bit_storage() implementation while you do that gdbing, ok?
[14:20] <seb128> ok
[14:21] <and471> mpt, if I right click on an item in the software list view, should it select the item?
[14:21] <pitti> seb128: bingo!
[14:22] <pitti> http://git.gnome.org/browse/glib/commit/?id=a1b015f7b70b3851d5a6e45fd4114c7723b4f1ea
[14:22] <pitti> seb128: that's worth a try
[14:22] <pitti> seb128: it's exactly the code path that is taken with -O2, and which fails
[14:24] <mpt> and471, I guess so, but that should be default behavior for GTK lists already
[14:24] <seb128> pitti, building...
[14:25] <and471> mpt, yeah it is that is fine
[14:26] <pitti> argh, 403
[14:26] <seb128> pitti, the buggy version?
[14:26] <pitti> yeah
[14:26]  * pitti grabs it from LP
[14:27] <seb128> takes ages to build, I should switch to my new laptop
[14:27] <seb128> I didn't install build environment etc there
[14:27] <pitti> seb128: why ages? changing a single file should build in like 10 sec?
[14:27] <seb128> pitti, seems every .c include that one
[14:28] <seb128> so makes is rebuilding everything
[14:28] <seb128> "make"
[14:28] <pitti> seb128: ah, I thought you just replaced G_BSEARCH_ARRAY_ALIGN_POWER2, in gobject/gsignal.c
[14:28] <seb128> I'm trying to revert the commit you pointed
[14:28] <pitti> seb128: you are trying Hannes Mueller's patch?
[14:28] <pitti> seb128: "revert"?
[14:29] <seb128> ups
[14:29] <seb128> "apply"
[14:29] <pitti> seb128: did that go into .12?
[14:29] <pitti> ah :)
[14:29] <Riddell> kenvandine: did you manage to poke the ubuntu one people about those merges?
[14:29] <seb128> pitti, no it didn't
[14:30] <and471> mpt, I think I shall fix that next week, I need to pack :)
[14:31] <Riddell> kenvandine: currently apachelogger is wanting to upload this directly http://people.ubuntu.com/~apachelogger/tmp/u1.debdiff
[14:32] <seb128> pitti, that change doesn't fix the crash
[14:32] <seb128> pitti, trying the G_BSEARCH_UPPER_POWER2 now
[14:37] <kenvandine> Riddell, i did, let me poke again
[14:38] <seb128> pitti, g_bsearch_array_create() is called twice
[14:38] <seb128> pitti, G_BSEARCH_UPPER_POWER2 (size) = 32 then 0
[14:38] <pitti> hm, I see it once per config
[14:39] <pitti> seb128: are both from g_signal_init()?
[14:39] <seb128> lemme check, that was from g_print in the code
[14:40] <seb128> LD_LIBRARY_PATH=../../install/deb/usr/lib/ gtk-demo
[14:40] <seb128> 32 (20)
[14:40] <seb128> 0 (20)
[14:40] <seb128>   g_print ("%u (%u)\n", G_BSEARCH_UPPER_POWER2 (size), size);
[14:40] <Riddell> kenvandine: what would be the consequences if he just uploaded the package with that patch?
[14:40] <pitti> seb128: gsignal.c has three different search configs and arrays
[14:40] <kenvandine> Riddell, they approved the branches :)
[14:41] <kenvandine> Riddell, just talked to josh, he will get someone to merge them asap
[14:41] <kenvandine> Riddell, but i am ok with distro patch if that unblocks anything
[14:41] <seb128> pitti, I've added the print in g_bsearch_array_create (const GBSearchConfig *bconfig)
[14:42] <kenvandine> merging the branches doesn't mean they will release
[14:42] <pitti> seb128: gdb doesn't work for this? to see where it's coming from?
[14:42] <kenvandine> although we might not want to upload a change like that on a friday :-D
[14:42]  * pitti currently tries to create a small test program to isolate this
[14:42] <seb128> pitti, on what do you want me to break?
[14:42] <seb128> pitti, I don't think I can break on an inline
[14:42] <pitti> seb128: g_signal_init()
[14:42] <seb128> pitti, I did that
[14:42] <pitti> seb128: or put a print there, before and after the g_bsearch_array_create()
[14:42] <seb128> I get the
[14:42] <seb128> 32 (20)
[14:42] <seb128> before the break
[14:42] <seb128> then if I c
[14:42] <seb128> I get
[14:42] <seb128> 0 (20)
[14:42] <seb128> and it crashes
[14:43] <seb128> G_BSEARCH_UPPER_POWER2 (20) -> 0
[14:43] <seb128> it means
[14:43] <pitti> right, that's the interesting bit
[14:43] <seb128> which is weird
[14:46] <pitti> $ pkg-config --cflags glib
[14:46] <pitti> sh: glib-config: not found
[14:46] <pitti> $ gcc -c -I/usr/include/glib-2.0 test.c
[14:46] <pitti> /usr/include/glib-2.0/glib/gtypes.h:34: fatal error: glibconfig.h: No such file or directory
[14:46] <pitti> WTH?
[14:47] <pitti> glib, don't resist against debugging like that!
[14:47] <mclasen> pitti: glibconfig.h has always been in $libdir/glib-2.0/include
[14:47] <pitti> ah
[14:47] <pitti> mclasen: thanks
[14:47] <pitti> so our pkg-config is broken right now, but let's look at that later
[14:47] <mclasen> not sure about your pkg-config problem, though
[14:48] <mclasen> Istr running into a problem like that at some point
[14:48] <seb128> http://git.gnome.org/browse/glib/commit/?id=83d67bf2e79e1cb984e398b218cedd0b1e50bd1f
[14:48] <seb128> could be due to that change?
[14:48] <mclasen> pkg-config may be falling back to trying $foo-config if it cant find foo.pc
[14:48] <mclasen> try pkg-config --cflags glib-2.0
[14:49] <seb128> right
[14:49] <pitti> I got it to build with the extra -I
[14:49] <seb128> $ pkg-config --cflags glib
[14:49] <seb128> sh: glib-config: not found
[14:49] <seb128> pitti, you probably meant glib-2.0 before
[14:51] <pitti> seb128: hm, I tried http://paste.ubuntu.com/474053/
[14:51] <pitti> works as expected
[14:51] <pitti> with -O0 and -O2
[14:51] <pitti> so there's more context involved
[14:52] <seb128> right
[15:04] <and471> tremolux, hey, I fixed the selection thing :) and also added to ability to expand/collapse the viewswitcher toplevel nodes with the right and left arrow key, when you have an opportunity, could you merge? :)
[15:04] <seb128> pitti, I don't get how gcc can know that G_BSEARCH_UPPER_POWER2 () will be 0 at build time
[15:04] <pitti> seb128: hm, slightly bigger test case now, but still doesn't crash
[15:05] <pitti> seb128: it's all just a single expression in __OPTIMIZE__
[15:05] <tremolux> and471: coolness!
[15:05] <pitti> seb128: without -O2 it's a real loop
[15:05] <pitti> seb128: but yeah, it's quite impressive
[15:06] <seb128> pitti, still that expression takes a argument
[15:06] <seb128> it doesn't have a fixed value
[15:06] <pitti> seb128: if you fancy another build test (can't do on a live system, sorry), drop the #if OPTIMIZE call in glib/gutils.h' g_bit_storage() and test again
[15:06] <pitti> ah, but then you said it would crash later on
[15:06] <tremolux> and471: thanks a lot!  I'll take a look now  :)
[15:07] <seb128> pitti, I've a build running for 2 minutes with that
[15:07] <seb128> pitti, well could be another sideeffect of g_bit_storage () borkage
[15:07] <and471> tremolux, (mvo merged the selection thing already, so it is just the viewswitcher thing that needs merging)
[15:07] <seb128> pitti, but I don't get why that's an issue in 2.25.12 and not 2.25.11
[15:07] <pitti> seb128: well, it's all static really, the compiler knows sizeof (GBSearchArray) and bconfig->sizeof_node (since that's a static variable using sizeof())
[15:07] <tremolux> and471: ok, I'll coordinate with mvo
[15:08] <pitti> it's impressive that gcc can decompose all that into a single static value
[15:08] <pitti> it eliminates variables, an if clause, etc.
[15:08] <and471> tremolux, I don't know whether you know, but mvo is on holiday today
[15:08] <tremolux> and471: ahh, that's right
[15:09] <and471> tremolux, btw the reaosn for the viewswitcher thing is due to accessibility which was pointed out to me by mpt :)
[15:09] <tremolux> and471: and I am actually getting ready to get on a plane myself  :)
[15:09] <and471> tremolux, hehe really? I am going on holiday tomorrow :)
[15:10] <tremolux> and471: nice!
[15:13] <seb128> pitti, right, changing the g_bit_storage() leads to the other crash
[15:16] <pitti> seb128: ok, but that other crash seems to be independent?
[15:16] <seb128> yes
[15:16] <seb128> it's http://paste.ubuntu.com/474034/
[15:16] <pitti> now, if only his would be reproducible in a small test case..
[15:17] <seb128> I still don't get it
[15:17] <seb128> none of this code changed between .11 and .12
[15:18] <seb128> desrt, what did you break!
[15:18] <mpt> tremolux, hi, do you know how to try out the buy-stuff code?
[15:19] <desrt> uh oh
[15:19] <desrt> what's up?
[15:19] <seb128> pitti, I think I will try undoing commits and rebuilding until I figure something
[15:19] <seb128> desrt, http://paste.ubuntu.com/474016/
[15:19] <desrt> wow.  crash inside the dynamic linker
[15:19] <seb128> desrt, http://launchpadlibrarian.net/53144885/buildlog_ubuntu-maverick-i386.glib2.0_2.25.12-1ubuntu1_FULLYBUILT.txt.gz
[15:19] <desrt> that's a nice one :)
[15:19] <seb128> "In function 'memset',
[15:19] <seb128>     inlined from 'g_bsearch_array_create' at /build/buildd/glib2.0-2.25.12/glib/gbsearcharray.h:137,
[15:19] <seb128>     inlined from 'g_signal_init' at /build/buildd/glib2.0-2.25.12/gobject/gsignal.c:775:
[15:19] <seb128> /usr/include/bits/string3.h:86: warning: call to __builtin___memset_chk will always overflow destination buffer
[15:19] <seb128> mv -f .deps/gparamspecs.Tpo .deps/gparamspecs.Plo
[15:19] <seb128> "
[15:19] <tremolux> mpt: I do, but as of yesterday there was a problem on the staging server; I can check to see if it's resolved
[15:19] <seb128> desrt, i386 specific, happen with 2.25.12 and not .11
[15:20] <tremolux> mpt: and I'll give you instructions to access it
[15:20] <pitti> (32 bit specific, to be precise)
[15:20] <mpt> tremolux, brilliant, thanks
[15:20] <desrt> fascinating.
[15:20] <tremolux> mpt: sure thing!
[15:20] <seb128> desrt, for some definition of it yes
[15:20] <desrt> lemme try kicking off a 32bit build of glib here
[15:20] <seb128> desrt, I can't figure wth changed between 2.25.11 and 12 that could create that issue
[15:21] <seb128> desrt, when disabling the optimization in g_bit_storage() I get
[15:22] <seb128> http://paste.ubuntu.com/474034/
[15:22] <seb128> desrt, ^ which might be another crash
[15:22] <seb128> but still doesn't explain why g_bit_storage() is busted
[15:22] <seb128> it didn't change between versions
[15:22] <seb128> and rebuilding .11 doesn't lead to the same warnings
[15:23] <desrt> btw: fedora multilib is really awesome compared to ubuntu
[15:23] <desrt> you guys need to get on that :p
[15:23] <desrt> do you get the crash during make check or what?
[15:24] <seb128> desrt, no, we get the crash after installation
[15:24] <desrt> oh
[15:24] <desrt> on many programs?
[15:24] <seb128> everything
[15:24] <desrt> nevermind
[15:25] <seb128> well anything graphical I tried
[15:25] <desrt> i just got a failure in a testcase
[15:25] <seb128> gtk-demo for example
[15:25] <seb128> desrt, do you get the build warning as well?
[15:25] <seb128> desrt, do you build with -O2?
[15:25] <desrt>  /error/prefix: *** glibc detected *** /home/desrt/code/glib/glib/tests/.libs/lt-error: double free or corruption (fasttop): 0x080a3f18 ***
[15:25] <desrt> not good.
[15:25] <seb128> desrt, well it might not crash for you
[15:26] <seb128> desrt, it bails out due to the fstack-protect
[15:26] <pitti> presumably it only crashes with -fstack-protector
[15:26] <desrt> uh.  this is a new test case
[15:26] <desrt> probably just this testcase is broken :p
[15:28] <desrt> false alarm. this is just a buggy testcase.
[15:30] <desrt> okay.  i see the stack protector and i should or should not have O2?
[15:31] <desrt> also: did you try to kick off a rebuild of .11 to see if it also ends up faulty?
[15:31] <seb128> build with O2
[15:31] <desrt> ie: maybe something in the builders changed
[15:31] <seb128> yes, .11 rebuild is fine
[15:31] <desrt> hmm
[15:31] <seb128> no
[15:31] <desrt> damn
[15:31]  * desrt always tries to blame the compiler first :)
[15:31] <seb128> we tried as well
[15:32] <pitti> desrt: we still do, sorta
[15:32] <and471> tremolux, just going offline for a bit but I will be back on
[15:32] <seb128> I built with gcc-4.4 and 4.5 as well
[15:32] <desrt> oh.  that's good news
[15:32] <desrt> it means i'm likely to be able to reproduce it here
[15:32] <desrt> OH
[15:32] <desrt> OH OH OH
[15:32] <desrt> i know what the problem is
[15:32] <desrt> :)
[15:32] <seb128> oh?
[15:32] <desrt> at least i think i do
[15:32] <seb128> it's due to your build system tweaks? ;-)
[15:33] <seb128> tell me!
[15:33] <desrt> no
[15:33] <desrt> make a vendorpatch that does nothing except to nuke glib/glibconfig.h
[15:33] <desrt> we're disting that by accident at the moment
[15:33] <desrt> and since i type 'make dist' on a 64bit system, it ends up being correct for 64bits
[15:33] <seb128> bah
[15:34] <desrt> we've been disting it forever, i think
[15:34] <desrt> but we recently moved it from the top srcdir to glib/
[15:34] <desrt> and i bet that has somehow changed things
[15:34] <desrt> blame gtk-doc for requiring us to do this :p
 http://git.gnome.org/browse/glib/commit/?id=83d67bf2e79e1cb984e398b218cedd0b1e50bd1f
[15:34] <seb128>  could be due to that change?
[15:34] <seb128> I was right maybe :p
[15:35] <desrt> yes.  i think that is the one.
[15:35] <desrt> is that what you meant by "build tweaks"?
[15:35] <seb128> yes
[15:35] <desrt> yes.  that's what i think it is.
[15:35] <seb128> I was trying to figure if that could set different build flag or options
[15:36] <desrt> just make a hook that erases that file before you run ./configure
[15:36] <desrt> i bet it works
[15:36] <seb128> trying
[15:36] <desrt> hm.  that's really bad.
[15:36] <desrt> if i wasn't directly in the middle of replacing GApplication i'd make a new release
[15:39] <desrt> actually, i suspect the build may break
[15:39] <desrt> should also nuke glibconfig-stamp (incase you didn't see that for yourself)
[15:40] <desrt> the thing is... i don't fully understand how it's possible that that file would not be rebuilt
[15:40] <jcastro> didrocks: -meego comes from the banshee source package?
[15:40] <desrt> since unless there is some very serious clock skew between us, the stamp would be out-of-date with respect to your config.status
[15:40] <jcastro> I am confused on where exactly to file this bug
[15:41] <jcastro> didrocks: (just realized I was asking you on the wrong channel)
[15:41] <seb128> desrt, it might not be the issue
[15:41] <desrt> it just fits so well....
[15:41] <didrocks> jcastro: yeah, it's on the banshee package
[15:41] <desrt> ahah
[15:41] <desrt> SUBDIRS = libcharset $(PRINTF_SUBDIR) $(MAYBE_PCRE) update-pcre . tests
[15:42] <desrt> from what i know of automake that means that libcharset/ and pcre/ get built before glibconfig would be updated
[15:43] <desrt> ah no.  BUILT_SOURCES first.
[15:43] <desrt> ya. maybe it's something else?
[15:43] <desrt> walters: hey.  good to have you back.
[15:43] <seb128> desrt, there is no glibconfig-stamp in the source
[15:44] <desrt> seb128: huh.  probably this isn't the problem, then
[15:44] <desrt> that would almost ensure that it gets rebuilt.
[15:44] <desrt> :(
[15:44] <walters> desrt: howdy, thanks!  good to see you btw
[15:44] <seb128> but build fails on a missing glibconfig.h now
[15:44] <desrt> walters: i released 0.9.3 of go-i.  hope you don't mind.
[15:44] <desrt> seb128: :)
[15:44] <desrt> i actually don't understand that at all.
[15:45] <seb128> walters, hey
[15:45] <and471> alecu, hey, did that gnome-keyring stuff help?
[15:45] <desrt> seb128: can you see any way that, if the stamp is missing, that file should not be regenerated?
[15:45] <seb128> walters, is the gir abi stabilizing, we are still on 0.6 waiting to update
[15:45] <jcastro> didrocks: easy one I think: https://bugs.edge.launchpad.net/ubuntu/+source/banshee/+bug/614387
[15:45] <ubot2> Ubuntu bug 614387 in banshee (Ubuntu) "Ship a "Purchased from Ubuntu One Music Store" smart playlist by default (affects: 1) (heat: 6)" [Undecided,New]
[15:45] <walters> seb128: not yet, sorry
[15:45]  * desrt does a tarball build
[15:45] <seb128> desrt, it's generated in builddir and not srcdir
[15:45] <seb128> desrt, we build out of source
[15:46] <desrt> ohh
[15:46] <desrt> that makes things more interesting
[15:46] <seb128> desrt, I've copied it for now and resumed build to see how it goes
[15:46] <desrt> that means we'd end up with a copy in srcdir and one in builddir
[15:46] <seb128> right
[15:46] <seb128> the srcdir being wrong
[15:46] <desrt> and i know from a fact (a releated bug we got recently) that some parts of glib are not looking at the one in the builddir
[15:46] <seb128> you get the updated version at the wrong location
[15:46] <desrt> which means that they would see the wrong one
[15:47] <didrocks> jcastro: who willl work on that? I don't really know about smart playlist and how they integrate into banshee
[15:47] <seb128> desrt, now it makes sense
[15:47] <seb128> desrt, double bug for the win
[15:47] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=626107
[15:47] <ubot2> Gnome bug 626107 in general "glibconfig.h is being disted" [Normal,New]
[15:47] <seb128> desrt, it also explain why a tarball build works fine
[15:47] <desrt> https://bugzilla.gnome.org/show_bug.cgi?id=625988
[15:47] <ubot2> Gnome bug 625988 in general "builddir != srcdir issues" [Normal,Resolved: fixed]
[15:47] <desrt> those two bugs tell the story fairly completely
[15:47] <jcastro> didrocks: it's U1MS related, I think rodrigo_?
[15:47] <desrt> this will definitely be fixed for .13
[15:47] <lool> asac: I didn't file the debian glib bug, Axel Beckert did
[15:48] <lool> asac: But yes, I've seen the bug fly through
[15:48] <didrocks> jcastro: should be yeah, as they did for rhythmbox
[15:48] <rodrigo_> jcastro, what, sorry?
[15:48] <desrt> seb128: #625988 tells why you were getting missing glibconfig.h after you deleted the srcdir one
[15:48] <seb128> desrt, ok, I clean the src one from the rules now and I will apply the second change
[15:48] <jcastro> rodrigo_: https://bugs.edge.launchpad.net/ubuntu/+source/banshee/+bug/614387
[15:48] <ubot2> Ubuntu bug 614387 in banshee (Ubuntu) "Ship a "Purchased from Ubuntu One Music Store" smart playlist by default (affects: 1) (heat: 6)" [Undecided,New]
[15:48] <desrt> seb128: the patch from the original reporter missed some files
[15:49] <seb128> desrt, I will get the git commit
[15:49] <desrt> i committed the patch as-is
[15:49] <rodrigo_> jcastro, can you create smart playlists from banshee plugins?
[15:49] <desrt> some stuff with inotify and fam and so on is broken
[15:49] <seb128> desrt, you mean it's not fixed in git yet?
[15:49] <desrt> can you give me an hour or so to come up with a proper solution for you?
[15:49] <desrt> yes.  not fixed in git yet
[15:49] <seb128> desrt, yes
[15:49] <desrt> k
[15:49]  * desrt gets some coffee :)
[15:49] <jcastro> rodrigo_: I don't know, let me ask
[15:50] <seb128> desrt, thanks a lot, still building to validate the glibconfig is the issue
[15:50] <seb128> walters, how often with the gir format change still? when do you think it will stabilize?
[15:50] <seb128> walters, I'm pondering just going for 0.9 and do rebuilds when required but I would like to avoid doing that every week
[15:50] <walters> seb128: hopefully within the month
[15:51] <and471> jcastro, that would be quite useful, I have created one myself for AmazonMP3 and 7digital :)
[15:51] <desrt> i may do a .13 today and leave the gapplication for .14
[15:51] <desrt> probably the easiest way
[15:51] <jcastro> and471: yep!
[15:52] <and471> tremolux, (if you have checked it yet) was everything okay in the branch?
[15:54] <tremolux> and471: I didnt' check it out yet, sorry!  lots of things going on atm  :)
[15:55] <and471> tremolux, thats fine no rush
[15:55] <seb128> desrt, pitti: ok, that fixes it
[15:55] <desrt> :)
[15:55] <tremolux> and471: ok, I will check it tho, first chance I get
[15:55] <seb128> desrt, thanks a lot
[15:55] <desrt> sorry for breaking it :X
[15:56] <alecu> and471, it surely did help! It's already merged on ubuntu-sso-client: https://code.edge.launchpad.net/~alecu/ubuntu-sso-client/credentials-interface/+merge/31896
[15:56] <and471> alecu, ah good :)
[15:57] <seb128> desrt, np, glad we found what the issue is
[16:05]  * pitti hugs desrt and seb128
[16:05]  * seb128 hugs desrt pitti
[16:05] <pitti> so which build flag was the culprit then?
[16:06] <seb128> pitti, no, build flag, see glibconfig.h
[16:07] <seb128> lot of types definition, etc
[16:07] <pitti> aah, the length of the types
[16:07] <pitti> niiice
[16:07] <pitti> seb128: still, impressive that gcc spotted that
[16:07] <seb128> yes
[16:07] <pitti> looks like it already does half of the computations :)
[16:07] <seb128> less impressive that it didn't stop the build
[16:08] <pitti> well, from gcc's POV it's YAFIYGI
[16:08] <pitti> seb128: -Werror would have, I guess
[16:08] <pitti> perhaps we should use that more often
[16:09] <pitti> great, so this is sorted out, gpm works again as well, sounds like Friday evening
[16:09] <pitti> tremolux: oh, enjoy your holidays!
[16:10] <tremolux> pitti: thank you!
[16:10] <pitti> tremolux: do you think you can test the dapper-proposed tzdata still, so that we can push this?
[16:10] <tremolux> pitti: yes, I went to test, but I'm not yet seeing the new version in the archive
[16:11] <tremolux> pitti:  I will try again in a little while
[16:11] <pitti> langpack-locales |  2.3.18.37 | dapper-proposed | source
[16:11] <pitti>    locales |  2.3.18.37 | dapper-proposed | all
[16:11] <pitti> tremolux: I thought that was the right version?
[16:11] <pitti> maybe your mirror is lagging
[16:11] <tremolux> pitti: yep, that is the right version
[16:12] <tremolux> pitti: ok, I'll check it now  :)
[16:12]  * pitti hugs tremolux
[16:12] <tremolux> pitti: :)
[16:12]  * tremolux hugs pitti
[16:18] <tremolux> pitti: yep, it's good, I'll comment bug 613691, thanks again!
[16:18] <ubot2> Launchpad bug 613691 in tzdata (Ubuntu Karmic) (and 6 other projects) "2010k available (affects: 1) (heat: 10)" [Undecided,Fix committed] https://launchpad.net/bugs/613691
[16:22] <pitti> tremolux: sweet!
[16:28] <pitti> good night everyone! 'nuff for the week
[16:28] <seb128> 'night pitti
[16:32] <fta> seb128, is it safe to upgrade glib now?
[16:32] <seb128> fta, yes
[16:33] <fta> ok, thanks
[16:33] <fta> oh, 2.25.12.is.2.25.11 :)
[16:54] <slomo> seb128: any news on the glib crash? seems to happen on x86 only...
[16:54] <seb128> slomo, yes
[16:55] <seb128> the glib crash in experimental is due to glibconfig.h
[16:55] <seb128>  the version disted with the tarball is a 64 bits one
[16:55] <seb128> there is a bug also which makes it use the srcdir one and not the builddir one
[16:55] <seb128> so basically 32 bits build use the tarball one
[16:56] <slomo> seb128: great, i assume this is trivial to fix? :)
[16:56] <slomo> this one i guess http://git.gnome.org/browse/glib/commit/?id=9f6faaffb6491a8de5508b7678ab48fee4f59efa
[16:57] <seb128> slomo, right, it misses the gio subdirs though
[16:57] <slomo> do you already have a fixed package in ubuntu?
[16:59] <seb128> slomo, not really, still working on it
[17:00] <slomo> seb128: ok, i'll wait for you then and take your diff ;)
[17:00] <seb128> slomo, https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+files/glib2.0_2.25.12.is.2.25.12-0ubuntu1~ppa1.dsc
[17:00] <seb128> is a candidate one
[17:00] <seb128> I've added 90_git...
[17:00] <seb128> which also has an autoreconf run
[17:00] <seb128> and a rm line in the rules
[17:01] <seb128> slomo, I'm still waiting for build to confirm it works
[17:01] <seb128> slomo, otherwise you might want to add dh_installdirs call in the rules
[17:01] <seb128> the .dirs are not used because those are not listed
[17:02] <slomo> seb128: thanks
[17:03] <slomo> i'll wait until you said that the fix works, i can't easily test it here...
[17:04] <seb128> slomo, ok
[17:06] <desrt> seb128: do you generate the gtk-doc when pbuilding?
[17:06] <seb128> desrt, no
[17:06] <desrt> just use the one we dist?
[17:06] <seb128> desrt, yes
[17:06] <desrt> nice
[17:06] <desrt> i just found out that gtk-doc building is totally broken for out-of-tree builds
[17:06] <seb128> ;-)
[17:06] <desrt> and almost impossible to fix :p
[17:13] <lool> seb128: I see you guys had LP #614240 on i386, this is likely caused by the same issue as the armel issue (32-bits arches don't have 8 bytes long)
[17:13] <ubot2> Launchpad bug 614240 in glib2.0 (Debian) (and 2 other projects) "libglib2.0-0 2.25.12-1ubuntu1 failed to install: *** buffer overflow detected ***: /usr/lib/glib-2.0/gio-querymodules terminated (affects: 20) (dups: 2) (heat: 121)" [Unknown,New] https://launchpad.net/bugs/614240
[17:15] <seb128> dunno what was the armel issue
[17:15] <seb128> but the i3
[17:16] <seb128> but the i386 one is the the glibconfig.h shipped with the tarball
[17:16] <seb128> it has 64 bits types
[17:16] <seb128> and the build doesn't regenerate it
[17:16] <seb128> cf backlog
[17:16] <lool> Yes
[17:16] <lool> It's the same as the armel issue
[17:16] <lool> seb128: but no upstream bug for it?
 seb128: #625988 tells why you were getting missing glibconfig.h after you deleted the srcdir one
 https://bugzilla.gnome.org/show_bug.cgi?id=625988
[17:17] <ubot2> Gnome bug 625988 in general "builddir != srcdir issues" [Normal,Resolved: fixed]
 https://bugzilla.gnome.org/show_bug.cgi?id=626107
[17:17] <ubot2> Gnome bug 626107 in general "glibconfig.h is being disted" [Normal,New]
[17:17] <seb128> that's basically those bugs combined
[17:17] <seb128> we discussed it with desrt earlier
[17:18] <seb128> basically upstream dist a 64 bits one and the build use the srcdir before the builddir one
[17:18] <seb128> so the updated one written in builddir is not used
[17:18] <lool> seb128: Why do they dist it?
[17:18] <seb128> it's one of the 2 bugs I just pointed
[17:18] <seb128> not on purpose
[17:18] <seb128> it's a bug
[17:20] <lool> seb128: well apparently it's a req of gtk-doc, but seems like a bogus one to me
[17:20] <seb128> right
[17:20] <lool> gtk-doc might run the code built with this header, this code might be broken
[17:20] <seb128> in any case we understand the issue now and it's being worked
[17:20] <lool> seb128: ok, who's preparing an upload?
[17:21] <seb128> https://edge.launchpad.net/~ubuntu-desktop/+archive/ppa/+files/glib2.0_2.25.12.is.2.25.12-0ubuntu1~ppa1.dsc
[17:21] <seb128> there is one from me there
[17:21] <seb128> I'm waiting to confirm my local build is fine before uploading to maverick
[17:21] <seb128> I gave the dsc to slomo as well for debian
[17:21] <lool> Ok, excellent, thanks!
[17:21] <seb128> np
[17:21] <lool> I'm assigning LP #614240 to you -- I've added the upstream bug ids now
[17:21] <ubot2> Launchpad bug 614240 in glib2.0 (Debian) (and 2 other projects) "libglib2.0-0 2.25.12-1ubuntu1 failed to install: *** buffer overflow detected ***: /usr/lib/glib-2.0/gio-querymodules terminated (affects: 20) (dups: 2) (heat: 121)" [Unknown,New] https://launchpad.net/bugs/614240
[17:22] <seb128> you can close it if you want
[17:22] <seb128> current maverick is 2.25.12.is2.25.11 which fixed the crash
[17:22] <lool> Well not until you upload?
[17:22] <lool> Oh ok
[17:22] <seb128> we revert mid-day
[17:22] <seb128> and blocked the bogus binaries from being downloaded this morning
[17:22] <seb128> we reverted mid-day
[17:24] <and471> seb128, you deserve a weekend break ;)
[17:24] <seb128> ;-)
[17:24] <seb128> at least that pushed us to figure what was wrong
[17:24] <seb128> I adviced other people to not upload yesterday but somebody on amd64 didn't notice the bug and went ahead with the upload
[17:25] <seb128> anyway it's sorted now
[17:25] <seb128> (I should really skip the glib testsuite for local rebuilds tests, it takes days)
[17:29] <seb128> slomo, it works
[17:32] <slomo> seb128: thanks, could you give me the debdiff? :)
[17:35] <seb128> slomo, ok
[17:39] <seb128> slomo, http://people.canonical.com/~seb128/glibupdate.debdiff
[17:39] <seb128> slomo, 90_... has an autoreconf run as well
[17:40] <slomo> ok, i'll put it into two patches if you don't mind :) but thanks, i'll get this into debian later
[17:41] <seb128> slomo, np, I figured that for one upload I could just use one patch
[17:41] <seb128> we should really move to run autoreconf at build time ;-)
[17:41] <seb128> we have been doing that for most of the sources in maverick it works great
[17:43] <slomo> it scares me a bit :)
[17:43] <slomo> but you're right, it would be easier and probably fix some build bugs too
[17:48] <slomo> seb128: what's 71_gio_launch_handler.patch ?
[17:53] <seb128> slomo, https://bugzilla.gnome.org/show_bug.cgi?id=606960
[17:53] <ubot2> Gnome bug 606960 in gio "Patch to add new extension point in GIO for use with multiple applications." [Enhancement,Unconfirmed]
[17:54] <seb128> slomo, unity is using it atm
[17:56] <seb128> session restart brb
[18:04] <kenvandine> anyone else having a problem with telepathy connecting?
[18:07] <kenvandine> wondering if it has anything to do with my hacking on the telepathy indicator...
[18:07] <kenvandine> or if it is a real bug
[18:14] <didrocks> time for week-end there!
[18:14] <didrocks> enjoy everyone, see you on Monday :)
[18:22] <huats> does anyone have faced some segfaults on maverick lately ? I assume it is related to doxygen
[18:22] <huats> geser, yeah I try to find some help here too :)
[18:23] <huats> a pacakge that builds fine on lucid, fails to build on maverick during the processing of the doc with a doxygen segfaults
[18:48] <and471> see ya everyone have a great weekend
[20:20] <desrt> mccann: greets :)
[20:20] <mccann> hey
[20:22] <vish> pitti: re: the icons , looks like gpm implemented fallbacks and it should be working
[20:22] <vish> but will add symlinks too anyway..