[07:55] <fta2> hi, do I have to remove half of gnome to complete the upgrades (oneiric) or is that libgnome-desktop-3-2 transition still a WIP?
[07:56] <fta2> the former seems a bad idea to me
[07:58] <ricotz> fta2, hi, the transition should be done
[08:00] <fta2> ricotz, really? http://paste.ubuntu.com/634826/
[08:04] <ricotz> fta2, hmm, i am using aptitude
[08:05] <ricotz> but the old libpanel-applet package can be removed
[08:06] <ricotz> aptitude should give you more solutions where you should get a better one
[08:06] <fta2> nope, they are all worse
[08:09] <fta2> they all imply removing a part of gnome and leaving most new stuff un-upgraded
[08:09] <fta2> it's been like that for a week
[08:10] <ricotz> perhaps there is some "custom" package which holds the old stuff
[08:10] <ricotz> i havent used a unity session lately, but my installation seems consistent
[08:12] <ricotz> so i think i should everything needed installed, there were updates which needed some tweaking -- meaning aptitude gave me like 10+ solutions
[08:12] <fta2> i don't think i have anything custom related to this
[08:13] <ricotz> for example the deskbar-applet
[08:14] <fta2> auto-installed, removing...
[08:14] <ricotz> probably aptitude shows you a lot local/old packages
[08:16] <ricotz> if there are mark them to purge, select an upgrade and browse the solutions
[08:19] <fta2> ricotz, nada, (and i've used debian/ubuntu for ~15y now, so i'm usually used to this stuff)
[08:20] <fta2> it all seems to be related to   libgnome-desktop-3-0: Depends: gnome-desktop3-data (= 3.0.2-2) but 3.1.2-0ubuntu1 is to be installed.
[08:22] <ricotz> fta2, did you used the gnome3-ppa?
[08:22] <fta2> no
[08:22] <ricotz> if you have cheese installed
[08:22] <ricotz> ok
[08:22] <fta2> http://paste.ubuntu.com/634839/
[08:25] <ricotz> apt-cache rdepends libgnome-desktop-3-0
[08:25] <ricotz> E: Keine Pakete gefunden
[08:28] <ricotz> http://paste.debian.net/plain/121355
[08:33] <ricotz> desrt, hello, i had to override the eventfd check since it only checks the installed kernel headers (right?) and not capability of the actual running kernel
[09:05] <desrt> ricotz: the bug is fixed upstream now
[09:10] <ricotz> desrt, https://launchpadlibrarian.net/74258089/buildlog_ubuntu-oneiric-amd64.glib2.0_2.29.9~git20110628.315210ec-0ubuntu1~11.10~ricotz0_FAILEDTOBUILD.txt.gz
[09:16] <desrt> ricotz: is that with the changes to git master as of yesterday evening?
[09:17] <ricotz> desrt, yes, commit 315210ec
[09:17] <fta2> hm, the preview pane in evo3 is broken (nvidia), it's either always blank/empty or corrupted (no refresh when scrolled)
[09:17] <fta2> ricotz, i managed to complete my upgrade
[09:17] <desrt> ricotz: huh.
[09:17] <ricotz> fta2, good :)
[09:18] <fta2> ricotz, i had to help apt* and drop all indicators-applet-*
[09:18] <ricotz> desrt, as i asked, it is checking the installed kernel headers but not the running kernel, so tests are failing
[09:18] <desrt> ricotz: something doesn't stack up here
[09:19] <desrt> ricotz: the error in your build log should be impossible with the new code
[09:19] <desrt> take a look at the patch in commit 1b0e5e7683148f769189fc82ab731ee25d06c04c
[09:19] <desrt> +    if (efd == -1 && (errno == ENOSYS || errno == EINVAL))
[09:19] <desrt> "Invalid argument" (shown in your message) is EINVAL
[09:20] <desrt> so it should hit that branch of the 'if'
[09:20] <desrt> the error message that i see is on the 'else'
[09:21] <desrt> are you 100% sure you got that commit in the upload?
[09:21] <ricotz> let me double check, but i am sure
[09:23] <desrt> i have a doubt :)
[09:23] <ricotz> desrt, it is, https://edge.launchpad.net/~ricotz/+archive/staging/+files/glib2.0_2.29.9%7Egit20110628.315210ec.orig.tar.xz
[09:26] <desrt> ricotz: i am quite confused
[09:27] <desrt> ricotz: i'll check something locally
[09:27] <desrt> i still don't believe my eyes :P)
[09:28] <ricotz> ;)
[09:31] <ricotz> desrt, again, the check in configure.ac is only a compile check not a runtime check, right?
[09:31] <desrt> it shouldn't matter
[09:32] <desrt> the check in gmain.c itself is a runtime check
[09:32] <desrt> with a fallback
[09:32] <ricotz> ok
[09:44] <ricotz> fta, do you have time to update the gnome3 ppa stats again?
[09:44] <fta2> ricotz, sure
[09:44] <ricotz> fta2, thanks
[09:44] <desrt> ricotz: i found a machine with a .25 kernel
[09:45] <desrt> gonna take your tarball for a spin
[09:45] <fta2> uh, my evo3 corruption is caused by liboverlay-scrollbar*
[09:46] <ricotz> desrt, looks like it is time to update the builders to lucid (.32) ;)
[10:00] <desrt> ricotz: i tried building your tarball on my 2.6.25 machine. no problems.
[10:00] <desrt> after _installing dbus_ it passes the tests
[10:00] <desrt> rodrigo_: hey.  how you been lately?
[10:01] <ricotz> desrt, hmm, the builders are running 2.6.24, but shouldnt make a difference since .27 is the requirement
[10:01] <desrt> indeed
[10:02] <desrt> what the heck are the builders running?
[10:02] <desrt> my 2.6.25 system is hardy
[10:02] <desrt> ah.  but it's a custom linode kernel
[10:03] <desrt> they probably went with a point release higher than the distro
[10:04] <ricotz> alright, but still it should work code-wise
[10:05] <desrt> i'm digging deeper
[10:10] <desrt> ricotz: i can't match your whacky combination of shiny-new-buildroot vs. ancient-kernel
[10:10] <desrt> can i give you a patch that will add some printf() and get you to apply it and try again?
[10:13] <ricotz> desrt, also i am only able to reproduce this in the ppa, so i would need to upload it there, but i can do
[10:14] <desrt> ricotz; http://fpaste.org/6S3L/
[10:15] <desrt> uh wait
[10:15] <desrt> no.  that's correct.  continue. :)
[10:15] <ricotz> ok
[10:15] <desrt> talk to you in a few hours, i guess :)
[10:15] <ricotz> probably
[10:18] <fta2> ricotz, done (your g3 stats)
[10:18] <fta2> ricotz, fyi, there's taking 15min to fetch now, against 8min ~2w ago
[10:19] <fta2> ricotz, feel free to go blame lp
[10:20] <ricotz> fta2, thank you -- you are indeed a statistics fan :P
[10:21] <seb128> seems you are both statistics fan ;-)
[10:22] <ricotz> desrt, https://edge.launchpad.net/~ricotz/+archive/staging/+build/2599672
[10:23] <ricotz> seb128, fta2, remembering the buildtime ;)
[10:23] <desrt> ricotz: let me know when it's done
[10:24] <ricotz> desrt, ok, probably in 1 hour
[10:26] <mterry> vuntz, hello!  I'm about to work on adding support for OnlyShowIn=Unity/NotShowIn=Unity to gnome-menus.  Would you like me to send that patch to bugzilla when done?
[10:27] <fta2> ricotz, well, the reason i remember your stats fetch time is that i found it absolutely slow to fetch ~5000 rows of a table in 8min, even worse now in 15 min
[10:28] <fta2> ricotz, and to get my daily dose of chromium stats, it now takes 5h+ :P
[10:29] <ricotz> fta2, alright :), this sounds horrible slow
[10:34] <seb128> ricotz, why do you do oneiric uploads in the ppa?
[10:35] <ricotz> seb128, just to have a working package until the MIR is done
[10:35] <seb128> ricotz, hum, ok
[10:35] <seb128> we should demote cheese to universe
[10:39] <vuntz> mterry: there's already a patch in bugzilla for something like this
[10:39] <vuntz> mterry: and it's waiting for a big branch to get merged, so... I'd advise you to wait a bit, actually :)
[10:40] <mterry> vuntz, oh!  didn't know.  let me see how that patch was done
[10:42] <seb128> vuntz, is the gobject friendly refactoring going to land soon?
[10:42] <mterry> vuntz, you're talking about the XDG_CURRENT_DESKTOP support I gather
[10:42] <mterry> didrocks, hah, see -- an environment variable for it ^
[10:43] <didrocks> mterry: nice! not sure how it will work if you explictely ask for fallback then
[10:45] <vuntz> mterry: yeah, that'd be based on that
[10:45] <vuntz> seb128: soonish, yes
[10:45] <mterry> vuntz, one problem with that patch is it doesn't support "blended desktops" where Unity also shows things that say OnlyShowIn=GNOME.  Maybe the environment variable could be a list?  Or special support for Unity could be added?  /me looks for spec for that variable
[10:45] <vuntz> seb128: we need an API addition in glib
[10:46] <vuntz> mterry: that sounds like you want something which isn't supported in the spec
[10:46] <vuntz> mterry: there's no notion of "blended desktops"
[10:48] <mterry> vuntz, I know, for OnlyShowIn.  But I didn't know how XDG_CURRENT_DESKTOP was spec'd.  Seems like it's not yet?
[10:49] <mterry> Just a conversation on the xdg list
[10:49] <vuntz> yeah, it's not
[10:50] <Tommeh> Why on earth does smartmontools depend on postfix :/
[10:50]  * mterry knows that "blended desktops" is a bad idea as long as there isn't a "GNOMEShell" OnlyShowIn value, but doesn't want to go and add "Unity;" to all the desktops in the world
[10:50] <vuntz> but my other idea was to add some API like gmenu_set_desktop(), and that's not really better
[10:51] <mterry> vuntz, I assume there is no intention to add a "GNOMEShell" OnlyShowIn value?  That the intention is that the future will be shell only?
[10:53] <mterry> vuntz, but with an environment variable...  that won't work with running "other-desktop --replace" or launching things from VT1 with "DISPLAY=:0.0" right?
[10:54] <mdeslaur> pitti: do you know of any reason we shouldn't replace gksu with something like "pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY synaptic"?
[10:54] <mdeslaur> pitti: we really want to remove gksu as it doesn't support pam/two factor auth correctly
[10:54] <seb128> mdeslaur, did anyone look at gksu-polkit?
[10:55] <mdeslaur> seb128: yeah, but it currently has security issues, and they haven't been fixed
[10:55] <seb128> ok
[10:55] <seb128> I was just mentioning it in case, I would like to get ride of gksu as well
[10:55] <mdeslaur> seb128: I'd rather just use something that's already in main
[10:55] <mdeslaur> (and maintained)
[10:55] <seb128> (for different reasons, what bothers me in the different user experiences between gksu and polkit prompts)
[10:56] <mdeslaur> yes
[11:06] <vuntz> mterry: no plan for GNOMEShell value, indeed
[11:06] <vuntz> mterry: and --replace is really not a good way to start another desktop
[11:06] <vuntz> mterry: doing this between gnome 3 & unity won't 100% work, for instance
[11:09] <cyphermox> kenvandine: your calendar crash might be fixed by http://git.gnome.org/browse/evolution/commit/?id=46eec90c098d5b239035568ae5c25ae9127a8373
[11:12] <mterry> vuntz, and VT1 apps aren't a concern?
[11:13] <mterry> vuntz, (just thinking that maybe a dbus way of querying which desktop one is on would be more foolproof)
[11:15] <pitti> mdeslaur: pkexec env seems like a nice trick indeed
[11:15] <pitti> mdeslaur: I'd love to get rid of gksu as well
[11:16] <mdeslaur> pitti: the only inconvenience is the message that gets displayed in the policykit window is less than ideal, we could either write a small wrapper for each app, or add a --title option to pkexec or something similar
[11:16] <pitti> mdeslaur: the dialog is rather nasty, though; it says it needs your password to run /usr/bin/env
[11:17] <mdeslaur> yeah, a wrapper could be used to get "pkexec synaptic-root $DISPLAY $XAUTHORITY"
[11:17] <mdeslaur> which would make the window better
[11:17] <mdeslaur> or, we could add a new option...something like --title "Synaptic package manager"
[11:17] <pitti> mdeslaur: it might be more palatable for upstream to actually add an option to set an env var
[11:18] <pitti> mdeslaur: hm, perhaps --title is better indeed
[11:18] <pitti> then we could write a generic wrapper which takes a .desktop file, grabs the translated name from it, uses that as --title, and runs the Exec= line through pkexec DISPLAY..
[11:18] <mdeslaur> yes
[11:19] <vuntz> mterry: a dbus way would be nice
[11:19] <pitti> mdeslaur: would you mind opening an upstream bugzilla for the --title thing, and then I'll grab davidz this afternoon and discuss it with him?
[11:20] <mdeslaur> pitti: sure, I'll do it in the next hour, and I'll let you know the bug number
[11:20] <pitti> thanks!
[11:20] <pitti> so we could call this wrapper "pkexecdesktop"
[11:23] <desrt> robert_ancell: hey.  how's the dbus stuff going?
[11:24] <desrt> robert_ancell: i love you
[11:24] <desrt> robert_ancell: but i'm ashamed to say it to you in person
[11:24] <seb128> robert_ancell, is it ready yet? can I try it?
[11:24] <robert_ancell> desrt, sorry, the feeling's not mutual
[11:24] <desrt> :~(
[11:24] <robert_ancell> seb128, no, and it's not getting any closer with you continuously asking me
[11:25] <desrt> robert_ancell: i'm glad it's not just me that you hate
[11:25] <robert_ancell> that's it, i'm stopping the car! EVERYONE OUT!
[11:25]  * pitti holds up the "Equal hate for everyone!!" cardboard sign
[11:25] <desrt> hm.  we didn't get that
[11:25] <desrt> we got "if you ask one more time, we're turning around and going home"
[11:26] <desrt> come to think about it, i guess i should have asked "are we there yet?" more often on the way to school
[11:27] <mpt> mdeslaur, we should add that option to USC as well: software-center --title "Synaptic Package Manager"
[11:27] <mpt> just to mess with people
[11:27] <mdeslaur> mpt: hehe, that was just an example :)
[11:28] <Sweetshark> desrt and seb128 seem to have found a fancy new way to communicate via audio ...
[11:29] <desrt> mumble mumble
[11:29] <seb128> can't hear you!
[11:29] <pitti> Sweetshark: really badly greppable, though
[11:29] <Sweetshark> desrt: lies! almost nobody on the mumble server!
[11:29] <desrt> pitti: google is working on something, i'm sure
[11:30] <mpt> mdeslaur, PolicyKit is just one of the things that would benefit from being able to get an application name and icon from a binary name. Others include System Monitor, gnome-session (these applications are blocking logout), and whatever it is that tries and fails to eject disks (this file is in use by this application).
[11:32] <mdeslaur> mpt: oh, interesting...then we probably should be looking at a proper way of doing this instead of just the specific use case I was thinking of
[11:35] <mpt> mdeslaur, yes, that would be cool. It seems like the kind of thing that the maintainers of those individual pieces don't do because from their p.o.v. it's too hard
[11:36] <mpt> There's a similar problem in getting from a package name to an application name+icon, needed by both USC and Update Manager. The API for that should look similar.
[11:39] <mpt> kenvandine, https://wiki.ubuntu.com/SoftwareCenter?action=AttachFile&do=view&target=menu-go.png
[11:40] <mpt> (initial sketch)
[11:40] <kenvandine> thx
[11:41] <seb128> pitti, https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/785680
[11:41] <ubot2> Ubuntu bug 785680 in accountsservice "[MIR] accountsservice" [Undecided,New]
[11:42] <kenvandine> mpt, those make sense, and i like ][ as a next/prev
[11:46] <kenvandine> vuntz, you are my hero!
[11:47] <kenvandine> vuntz, your fix for bgo 652769 worked
[11:47] <vuntz> kenvandine: :-)
[11:47] <kenvandine> vuntz, thx!
[12:08] <mdeslaur> pitti: https://bugs.freedesktop.org/show_bug.cgi?id=38769
[12:08] <ubot2> Freedesktop bug 38769 in libpolkit "Allow specifying user friendly application name when using pkexec" [Enhancement,New]
[12:13] <pitti> mdeslaur: cheers!
[13:56] <ricotz> desrt, https://launchpadlibrarian.net/74290372/buildlog_ubuntu-oneiric-amd64.glib2.0_2.29.9~git20110628.315210ec-0ubuntu1~11.10~ricotz2_FAILEDTOBUILD.txt.gz
[13:56] <ricotz> seems like there is no output :\
[13:57] <desrt> ricotz: i repeat my assertion that you must be compiling the wrong thing
[13:59] <desrt> that failure is quite interesting, though
[14:00] <desrt> i do believe it could be caused by the eventfd thing though
[14:00] <desrt> looks like the mainloop is failing to wake up
[14:01] <ricotz> desrt, you looked at the tarball and it includes the fixes
[14:02] <desrt> there is clearly some inconsistency here
[14:02] <desrt> since i didn't modify anything except for the g_error codepath
[14:02] <desrt> i think you hit the opposite side of a race
[14:02] <desrt> is there any way you can send the same build unmodified?
[14:02] <desrt> in hopes of seeing it go the other way...
[14:02] <ricotz> desrt, use "dget https://edge.launchpad.net/~ricotz/+archive/staging/+files/glib2.0_2.29.9%7Egit20110628.315210ec-0ubuntu1%7E11.10%7Ericotz2.dsc"
[14:04] <seb128> desrt, ricotz: you can retry the build yes
[14:05] <desrt> chrisccoulson: what did this 'kill -11 `pidof xchat`' thing that i saw you typing mean?
[14:05] <ricotz> seb128, could this be something similar to the gnome-keyring build failures which looked up
[14:05] <desrt> i want to learn more about the things that you do
[14:05] <ricotz> seb128, * locked up
[14:05] <seb128> ricotz, not sure, it would need debugging to say
[14:05] <chrisccoulson> lol
[14:08] <ricotz> desrt, seb128 i could restart them but both amd64 and i386 stopping at the same position
[14:09] <ricotz> which is quite unlikely to be random
[14:10] <desrt> ricotz: by looking at my patch do you agree that i only modified the g_error() statement?
[14:10] <ricotz> desrt, yes
[14:11] <desrt> so why should the result change from last time being a g_error to this time being not a g_error?
[14:11] <desrt> other than by chance
[14:17] <ricotz> desrt, ok, restarted
[14:19] <desrt> sorry :/
[14:19] <desrt> hopefully this time we get a different result
[14:26] <fta2> dpm, hi, I just landed ca@valencia in the last chromium update (M12)
[14:27] <ricotz> desrt, i hope so too
[14:28] <dpm> fta2, awesome, thanks! :)
[14:29] <seb128> ricotz, your glib upload built on natty and not oneiric?
[14:29] <seb128> that's weird
[14:30] <ricotz> seb128, this is a patched one to force the success
[14:30] <seb128> ricotz, oh, that's cheating! ;-)
[14:34] <ricotz> seb128, could you look at webkit to fix headers with G_CONST_RETURN?
[14:34] <seb128> ricotz, is that an issue for any build currently?
[14:34] <seb128> it's all desrt's fault again!
[14:35] <ricotz> probably everything which want to build against it ;) -- i just looked at rhythmbox git
[14:37] <seb128> ricotz, well, they put compat defines, so only things that build with G_DISABLE_DEPRECATED
[14:37] <seb128> you can build without that define as a workaround
[14:38] <ricotz> right, same goes for the gtkbox stuff
[14:38] <seb128> grrrr desrt grrrr!
[14:42] <seb128> ricotz, pitti: ok, http://trac.webkit.org/changeset/88872 should do the trick
[14:43] <seb128> I'm pondering doing the "if it applies it's good enough to be uploaded" ;-)
[14:48] <TheMuso> ronoc: What time is the GVC meeting?
[14:48] <ronoc> TheMuso, 4pm
[14:48] <TheMuso> ronoc: Cheers.
[14:48] <ronoc> TheMuso, np
[14:48] <TheMuso> ronoc: Where abouts?
[14:50] <ronoc> TheMuso, in the indicators room, down the other end of the same floor you are on. At Marianna and co take a right instead of a left and walk all the way down (around the corner) we are on the right at the bottom of the hall
[14:50] <ronoc> TheMuso, Dawson suite - indicators room
[14:54] <mvo> nessita: if you are fine with https://code.launchpad.net/~mvo/ubuntu-sso-client/dh_python2/+merge/66304 I can upload it
[14:54] <mvo> (or wait and let someone else upload it)
[14:54] <nessita> mvo: seems ok :-)
[14:55] <seb128> go mvo go!
[14:55] <mvo> thanks nessita I will just upload then
[14:55] <nessita> thanks!!!
[14:55] <mvo> yw
[14:55] <TheMuso> ronoc: Thanks.
[15:08] <ricotz> seb128, then go for the upload ;)
[15:08] <seb128> yeah, will do in a bit
[15:08] <ricotz> great
[15:11] <ricotz> desrt, seb128, i386 gone through (https://edge.launchpad.net/~ricotz/+archive/staging/+build/2599673/+files/buildlog_ubuntu-oneiric-i386.glib2.0_2.29.9%7Egit20110628.315210ec-0ubuntu1%7E11.10%7Ericotz2_BUILDING.txt.gz), but the amd64 stopped again (https://edge.launchpad.net/~ricotz/+archive/staging/+build/2599672)
[15:12] <desrt> ricotz: this is extremely frustrating
[15:12] <desrt> at this point, if i had to guess i'd guess that
[15:13] <desrt>  a) the upload that you did first somehow didn't include the patch
[15:13] <desrt>  b) these new uploads (which do include the patch) have the bug fixed, but now there is a new bug
[15:14] <ricotz> desrt, this tarball includes the fix since the beginning, ~ricotz0 both failed, ~ricotz1 patched configure.ac, ~ricotz2 dont patch configure.ac include your debug
[15:15] <desrt> what configure.ac patch?
[15:15] <ricotz> which mean if i had restarted ~ricotz0 sometimes it might/should succeeded too
[15:16] <ricotz> desrt, https://edge.launchpad.net/~ricotz/+archive/staging/+files/glib2.0_2.29.9%7Egit20110628.315210ec-0ubuntu1%7E11.10%7Ericotz0_2.29.9%7Egit20110628.315210ec-0ubuntu1%7E11.10%7Ericotz1.diff.gz
[15:16] <ricotz> https://edge.launchpad.net/~ricotz/+archive/staging/+files/glib2.0_2.29.9%7Egit20110628.315210ec-0ubuntu1%7E11.10%7Ericotz1_2.29.9%7Egit20110628.315210ec-0ubuntu1%7E11.10%7Ericotz2.diff.gz
[15:18] <ricotz> desrt, so it is random :\
[15:59] <fta> is anyone able to create/add an imap account in evo3 (oneiric)?
[15:59] <seb128> fta, details?
[15:59] <seb128> what issue do you get?
[15:59] <fta> the dialog box is totally broken here, after the 1st forward, it goes back to the 1st step, and loops
[16:00] <seb128> right, that's a known issue and due to the gtkassistant refactoring in 3.1
[16:01] <seb128> bug #799469
[16:01] <ubot2> Launchpad bug 799469 in evolution "evolution 3.0 setup assistant jump step with new gtkassistant (3.1)" [High,Triaged] https://launchpad.net/bugs/799469
[16:01] <fta> ok, thanks
[16:01] <fta> (once again, i'm not crazy)
[16:03] <fta> seb128, the bug says evo 3.0, same with 3.1.* (in case it matters)
[16:04] <seb128> fta, right, I can confirm and the bug didn't get any recent update upstream either
[16:31] <seb128> TheMuso, there is a sponsoring request for a new onboard version, maybe you could have a look to it?
[16:58] <seb128> cyphermox, http://cgit.freedesktop.org/geoclue/commit/?id=f2f988bfdda6a347a8190612af1501466b64d76b
[17:03] <pitti> seb128, mdeslaur: david and I just discussed the pkexec X11ification, and came to a workable agreement
[17:04] <mdeslaur> pitti: I just saw your notes in the bug, sounds great
[17:04] <seb128> pitti, great
[17:05] <pitti> mdeslaur: it would also be a security improvement, as with .policy files you can't spoof the title any more (which you can with gksu)
[17:06] <mdeslaur> pitti: yes, that's a good idea
[17:07] <mdeslaur> pitti: I wonder if there would be a reason to limit the DISPLAY and XAUTHORITY passing of variables to only when you try to run as root
[17:07] <mdeslaur> meh, maybe not
[17:10] <seb128> pitti, robert_ancell's bug is https://bugzilla.gnome.org/show_bug.cgi?id=596260
[17:10] <ubot2> Gnome bug 596260 in authentication dialog "Make authentication dialogs system-modal and improve wording/design" [Major,Assigned]
[17:11] <mterry> robert_ancell, I opened https://bugs.launchpad.net/nautilus/+bug/803519 btw
[17:11] <ubot2> Ubuntu bug 803519 in nautilus "Use Unity as a registered XDG environment" [Undecided,New]
[17:15] <agateau> hey, libgtest-dev apparently misses /usr/lib/libgtest.so, is it a known problem?
[17:16] <agateau> didrocks: ^
[17:17] <seb128> agateau, hey
[17:17] <didrocks> agateau: hum, not really, we are in sync with debian though
[17:17] <didrocks> agateau: but it doesn't have the right versionning from my discussion with Tim
[17:17] <didrocks> so it needs update at least, and maybe fixing that at the same time
[17:17] <agateau> didrocks: the -dev only contains the .a files
[17:18] <agateau> didrocks: unity test do not build on oneiric because of that
[17:18] <didrocks> agateau: ok, it's screwed then, would be nice to fix that in debian directly
[17:18] <didrocks> agateau: hum, wasn't a missing release the cause? like the .6 version?
[17:18] <didrocks> (from what Tim told me)
[17:19] <seb128> didrocks, agateau: do you want me to fix it and open a debian bug?
[17:19] <didrocks> seb128: that would be awesome!
[17:19] <agateau> didrocks: I haven't talked about that with Tim, all I know is make complains with "No rule to make target `/usr/lib/libgtest.so', needed by `tests/test-gtest'.  Stop."
[17:19] <seb128> didrocks, agateau: on it
[17:19] <didrocks> seb128: thanks a lot :)
[17:19] <agateau> seb128: great :)
[17:19] <seb128> yw
[17:21] <agateau> seb128: while you're at it, it's also missing /usr/lib/libgtest_main.so
[17:23] <seb128> agateau, I will fix it to install everything which is missing, no worry
[17:23] <agateau> seb128: ok
[17:24] <seb128> agateau, didrocks: you tricked me!
[17:24] <seb128> that thing is using cmake!
[17:25] <agateau> seb128: mmm... there seems to be another problem: after manually creating the symlinks I get a link error, but I guess providing the missing files is still a good idea :)
[17:25] <didrocks> \o/
[17:25] <agateau> seb128: ah!
[17:25] <didrocks> agateau: nicely done :)
[17:25] <agateau> resistence is futile
[17:25] <agateau> *resistance
[17:26] <seb128> didrocks, neil got the gtk3 indicator loader landed
[17:26] <seb128> didrocks, do you want to backport it or should kenvandine or I do it?
[17:27] <didrocks> seb128: I would prefer a proper unity release with the dialog stuff tested as well, so that we can have both (and do it tomorrow)
[17:27] <seb128> ok
[17:27] <didrocks> seb128: I'll poke him directly for this
[17:27] <seb128> I'm not sure I want to delay the indicators to be back on the unity dialog to be working though
[17:28] <seb128> agateau, didrocks: gtest is not a packaging error, I'm not going to fix cmake build but if you give me a patch I can add it to the package
[17:29] <agateau> seb128: I can have a look
[17:29] <seb128> hum
[17:29] <seb128> debian did
[17:29] <seb128>   * control: Switch to cmake (upstream deprecated autoconf build).  Build
[17:29] <seb128>     only static library (remove libgtest0 package).  Install full source
[17:29] <seb128>     and example files.
[17:29] <seb128> I'm wondering why
[17:29] <agateau> oh
[17:29] <agateau> seb128: shouldn't it conflicts/replaces with libgtest0 then?
[17:30] <agateau> that explains the linking error
[17:30] <seb128> agateau, it should
[17:30] <seb128> didrocks, he doesn't want to roll a tarball, let's talk about that tonight
[17:31] <didrocks> seb128: who "he"?
[17:31] <seb128> didrocks, he said that he would need a new nux, etc if he rolled a tarball from trunk and he don't want to start tarballing the stack
[17:31] <seb128> didrocks, njpatel
[17:31] <didrocks> hum… and when will we have a working dialogs then?
[17:31] <didrocks> let's talk about that tonight then…
[17:31] <seb128> not today or tomorrow apparently
[17:31] <seb128> right
[17:32] <jbicha> seb128: howdy
[17:32] <seb128> hey jbicha, how are you?
[17:32] <jbicha> https://code.launchpad.net/~jbicha/ubuntu/oneiric/gnome-applets/gnome-applets-3.1.2/+merge/66232
[17:32] <didrocks> seb128: are we sure those are tested?
[17:32] <didrocks> like the dialog, which wasn't?
[17:32] <seb128> didrocks, let's discuss tonight
[17:32] <seb128> jbicha, thanks
[17:32] <jbicha> I'm doing fine, how's Dublin?
[17:33] <agateau> seb128: mmm can't uninstall libgtest0, google-mock depends on it
[17:33] <seb128> agateau, yeah, I don't know why the debian maintainer did that
[17:33] <seb128> he didn't explain
[17:34] <agateau> seb128: maybe upstream did the change?
[17:35] <seb128> not sure
[17:36] <agateau> seb128: mmm upstream provides both autotools and cmake,
[17:36] <agateau> seb128: but the cmake version only builds static libs and does not provide install targets!
[17:36] <seb128> agateau, http://anonscm.debian.org/gitweb/?p=collab-maint/gtest.git;a=blob;f=debian/README.Debian;h=15381ee64ee60750dfd019dd58d4c267351254b4;hb=fced3a5054fcdf6a891d9c9f9a32fa7e13802263
[17:37] <seb128> agateau, http://groups.google.com/group/googletestframework/browse_thread/thread/668eff1cebf5309d
[17:37] <pedro_> so who is working on metacity ? bug 802747 :-)
[17:37] <ubot2> Launchpad bug 802747 in metacity "window redraw glitches caused by ubuntu patch" [Undecided,New] https://launchpad.net/bugs/802747
[17:37] <agateau> wow
[17:38] <agateau> seb128: they want people to build it with the same compiler flags, but using static libs does not mean same compiler flags, so it's not really a solution I would say
[17:40] <agateau> seb128: you can still force the build of shared libs, though
[17:40] <agateau> seb128: not sure we want to go that way
[17:40] <seb128> agateau, I would prefer not taking decisions over Debian for a project I don't know or work with
[17:40] <agateau> seb128: makes sense
[17:40] <seb128> I will assume the Debian maintainer has a better clue than me
[17:42] <mterry> tremolux, when does oneiric get for-purchase apps?
[17:42] <tremolux> mterry: it usually happens quite late in the cycle
[17:43] <mterry> tremolux, <whine>I want it now!</whine>
[17:43] <tremolux> mterry: you could check with iamfuzz to see when he plans it for O
[17:44] <mterry> tremolux, all us devs would love to buy stuff, but we can't!
[17:44] <agateau> seb128: I am going to try to make unity tests use the static gtest libs
[17:44]  * mterry just noticed Bridge Construction Set in the store
[17:44] <seb128> agateau, thanks
[17:46] <tremolux> mterry: yeah!  me wants all the good stuff too!
[18:04] <jasoncwarner_> test
[18:04] <jasoncwarner_> test
[18:05] <seb128> jasoncwarner_, test!
[18:05] <jasoncwarner_> seb128: TEST!!!!
[18:05] <seb128> jasoncwarner_, STEAK?!
[18:05] <seb128> ;-)
[19:22] <DOOD> can i have help with a wirless stick please
[19:23] <DOOD> hello
[19:31] <dobey> i ♥ impatient people in the wrong channel :)
[19:51] <awe_> cyphermox, congrats, just the saw the email on ubuntu-desktop!  Well deserved!
[23:23] <cyphermox> awe_: thanks
[23:23] <awe_> your welcome!