[00:00] <chrisccoulson> oh, it's changed? i've not used it yet
[00:00] <rickspencer3> hi robert_ancell
[00:01] <RAOF> chrisccoulson: It's changed since last I used it, which may have been Karmic
[00:01] <RAOF> :)
[00:02] <chrisccoulson> i might have to try it next time i do an upgrade
[00:04] <Amaranth> dang I need a longer scrollback
[00:04] <Amaranth> If my scrollback can't make it through a line in _this_ channel it's way to short :P
[00:06] <TheMuso> RAOF: BTW were you able to confirm either the pulse behavior I told you about the other day, or my theory?
[00:07] <RAOF> TheMuso: When I tried running “pulseaudio -k” before shutting down the behaviour remained, but my system was moderately messed up at that point.
[00:08] <RAOF> Now that gdm is actually working, so I'm in a real, live GNOME session, I'll try again.  In ~50minutes, when these 80 updates will have finished installing :(
[00:08] <TheMuso> RAOF: ah ok
[00:08] <TheMuso> Is it possible to monitor the signals a process receives, and log them?
[00:10] <RAOF> You could attach gdb and have it log the signals
[00:11] <RAOF> “handle SIGFOO nostop print”
[00:12] <chrisccoulson> you can use strace as well can't you?
[00:12] <RAOF> robert_ancell: Hey, is there a vala PPA somewhere where I could install valac 0.9.5 so I could build shotwell from trunk so I could confirm that their fix fixes my bug?
[00:12] <chrisccoulson> -esignal=....
[00:12] <RAOF> chrisccoulson: Yeah.  Probably neater.
[00:16] <TheMuso> Thanks guys.
[00:19] <robert_ancell> RAOF, on phone, be back in a bit
[00:53] <robert_ancell> RAOF, so no PPA, but I was planning on updating to 0.9.5 if dx is ok with it
[00:53] <robert_ancell> I'll do the update and push to the desktop ppa
[00:53] <RAOF> Ta.
[00:54] <RAOF> Then I'll see if shotwell still takes 7 minutes to import 7 photos :)
[01:00] <robert_ancell> RAOF, I'm still not seeing that problem...
[01:02] <RAOF> robert_ancell: The hypothesis is that it's a side-effect of a gphoto bug (where gphoto is unable to extract the thumbnails from my raw files) which results in shotwell re-copying all the files from my sd card every import, hashing them, then rejecting the duplicates.
[01:03] <rickspencer3> good night guys
[01:03] <rickspencer3> have a good day!
[01:03] <robert_ancell> RAOF, ah
[01:04] <RAOF> rickspencer3: Good night!
[01:11] <RAOF> TheMuso: So, the thinking is that running “pulseaudio -k” then shutting down should result in me coming back with non-muted audio?  Does it matter that pulse will immediately get respawned, or do I also need to turn of autospawn?
[01:12] <TheMuso> RAOF: Probalby easiest to log out, then go into a VT and check to see whether pulse is still running as you. If it is, kill it, then restart.
[01:12] <RAOF> k.
[01:15] <Keybuk> thank god Pulse is well maintained ;-)
[01:16] <TheMuso> Keybuk: heh
[01:16] <TheMuso> But I don't think the bug RAOF and I are talking about is a pulse bug, however this is yet to e 100% proven.
[01:20] <Keybuk> did you see the discovery that Pulse's bugs in RH's Bugzilla have gone untouched for >6 months
[01:21] <Keybuk> http://lists.fedoraproject.org/pipermail/devel/2010-August/140095.html
[01:24] <Sarvatt> RAOF: forget to pull xorg-server first? :)
[01:24] <Sarvatt> sorry about that
[01:27] <Sarvatt> Keybuk: dang, guess that explains why there were hardly any pulse uploads in maverick
[01:29] <TheMuso> Keybuk: Lennart is obsessed with systemd I dare say.
[01:29] <TheMuso> Sarvatt: This is true.
[01:29] <Keybuk> yes
[01:29] <Keybuk> it's his new "thing"
[01:30] <Sarvatt> "Would "Fix your existing broken crap before taking up something new." be less antagonistic?" :D
[01:30] <micahg> I think we got a poke: http://lists.fedoraproject.org/pipermail/devel/2010-August/140170.html
[01:31]  * TheMuso sighs. Lennart, that was not a flame war post.
[01:32] <Keybuk> of course
[01:32] <Keybuk> Lennart is ... consistent
[01:33] <RAOF> TheMuso: Logging out, switching to a VT and running pulseaudio -k didn't change the behaviour; I still logged in to a muted system.
[01:33] <robert_ancell> Packaging question:  I'm packaging the latest vala and they've versioned the binaries so you can have multiple versions installed, i.e. valac-0.10.  There are provided symlinks (valac->valac-0.10).  If I install vala 0.11 at a later date will dpkg "do the right thing" with these duplicate symlinks?
[01:34] <TheMuso> RAOF: Right, I'll have to try it again myself, it worked for me...
[01:34] <RAOF> Why is pulseaudio hanging around after I've logged out, anyway?
[01:36] <RAOF> Sarvatt: Actually, no.  I forgot to *push* xorg-server first :/
[01:37] <TheMuso> RAOF: It shouldn't...
[01:37] <TheMuso> The only pulse you should see is gdm...
[01:38] <RAOF> Let me try that again, then.
[01:40] <rickspencer3> micahg, don't let those pokes bother you
[01:41] <micahg> rickspencer3: just wanted to point it out, reading this thread makes me feel good about the distro I chose :)
[01:41]  * TheMuso hoes Lennart doesn't get all snarky and antagonistic at plumbers.
[01:41] <TheMuso> hopes
[01:41] <Keybuk> of course he will
[01:41] <rickspencer3> that's his way
[01:41] <Keybuk> he didn't get his way about the track leaderships, for a start
[01:41] <rickspencer3> we can still love him for all that he does
[01:42] <TheMuso> Indeed, he is very smart and has good ideas.
[01:42] <rickspencer3> just whatever happens, don't let a guy like that drag you into name calling matches
[01:42] <devildante> micahg: what's the problem with pulseaudio? (just curious)
[01:42] <rickspencer3> if you take the bait, no one wins
[01:43] <micahg> devildante: people are jumpy :)
[01:43]  * rickspencer3 goes away to have a life again
[01:43] <TheMuso> rickspencer3: Yeah I know, I will have to be up to the task.
[01:43] <devildante> micahg: indeed :p
[01:43] <rickspencer3> TheMuso, just don't forget, we do what we do, and we do it well!
[01:43] <TheMuso> rickspencer3: Yep
[01:43] <rickspencer3> maybe not everyone can understand it, but the results speak for themselves
[01:43]  * rickspencer3 really leaves this time ;)
[01:44] <Sarvatt> RAOF: audio muted on startup? is that the old alsa-utils bug rearing its head again? try commenting out line 385 of /sbin/alsa-utils?
[01:44] <TheMuso> Sarvatt: no its not
[01:44] <TheMuso> Sarvatt: at least for me
[01:45] <Sarvatt> ah ok, i had that problem for a long time during jaunty and karmic
[02:04] <RAOF> TheMuso: Ok.  The reason why pulseaudio stuck around the first time was that I logged in to the VT before logging out of my X session.
[02:05] <RAOF> The second time around I logged out first, there was no stray pulse process, but restarting still left me logging in to a muted session.
[02:07] <TheMuso> RAOF: hrm
[02:07] <TheMuso> I'll do some more testing of my own a bit later.
[03:41] <robert_ancell> RAOF, uploaded new vala now - the package is now called valac0.10
[03:42] <RAOF> robert_ancell: Ta.  Is that to the archive, or desktop-team PPA?
[03:44] <robert_ancell> RAOF, desktop-team PPA, I want to get it reviewed by seb, slomo and the dx team first.  Please look over it too if you're keen (lp:~ubuntu-desktop/vala/ubuntu)
[03:45] <RAOF> I don't think I'm *that* keen.  I'd prefer to play chase-the-free'd-pointer through X/ati/drm/kernel/drm/ati/X.
[03:46] <RAOF> :)
[03:55] <TheMuso> heh
[04:43] <TheMuso> RAOF: A question about your pulse test earlier. Prior to logging out and killing pulse, did you unmute/adjust audio volume so you could hear stuff?
[04:43] <RAOF> Yes.
[04:47] <TheMuso> RAOF: Ok, because When I do the following, I get correct volume settings when logging back in: 1) log out 2) kill pulseaudio for my user if it is still running with pulseaudio -k 3) restart 4 ) log back in. I hear the startup sound/other sounds without needing to set volume again.
[04:48] <RAOF> Let me try again...
[05:18] <RAOF> TheMuso: Nope.  Still comes back muted.
[05:19] <TheMuso> RAOF: hrm sounds like alsa may be doing something funky as well. This is weird, because I can reproduce the symptoms I get on 2 machines.
[05:20] <RAOF> I also don't seem to get the drums sound for gdm on this machine, which is probably related.
[05:20] <TheMuso> RAOF: Very possibly.
[05:21] <TheMuso> RAOF: in fact yes that is related.
[05:23] <pitti> Good morning
[05:26] <TheMuso> Morning pitti..
[05:30] <pitti> hello TheMuso, how are you?
[05:30] <TheMuso> pitti: Not too bad thanks, yourself?
[05:31] <pitti> pretty well, getting used again to getting up at 6 :)
[05:32] <ajmitch> 6 is just far, far too early :)
[05:35] <RAOF> I might get up that early in summer.
[05:51] <TheMuso> I certainly will be getting up that early in Summer.
[06:57] <robert_ancell_> pitti, hey, why did you update to gnome-power-manager 2.31.1 and not 2.31.6?
[06:58] <pitti> robert_ancell: because .2 ports to gtk3 and gsettings, etc.
[06:58] <robert_ancell> pitti, are we ok to stay on a 31.1 release for maverick final?
[06:59] <pitti> robert_ancell: I guess we have to..
[06:59] <pitti> we can backport important fixes of course
[06:59] <pitti> but I thought seb said that we don't want to pull gtk3 stuff into maverick
[07:00] <robert_ancell> yeah, gtk3 is out for maverick (though we want it in universe for trying out)
[07:00]  * micahg thought they reverted everything for 2.31.6
[07:00] <robert_ancell> I wonder if they are planning on making it work with gtk2 for 2.32
[07:01] <robert_ancell> micahg, cool, I'll have a look
[07:01] <micahg> robert_ancell: the announcement said they pulled 2.30 versions for some components, so I'm not 100% sure
[07:08] <pitti> robert_ancell: oh, indeed
[07:08] <pitti> robert_ancell: there's now a gnome-2-32 branch with gtk2 again
[07:08] <pitti> robert_ancell: I guess last time I looked at it we still were at .5
[07:09] <pitti> robert_ancell: so, want me to update?
[07:09] <robert_ancell> pitti, sure, I think you're more familiar with it than me
[07:15] <pitti> robert_ancell: argh, that appindicator patch is a bitch to port across releases
[07:16] <robert_ancell> pitti, heh, we have a number of those :)
[07:18] <robert_ancell> RAOF, if you have a package that needs GL/gl.h, what is the correct package dependency? mesa-common-dev?
[07:40] <RAOF> robert_ancell: You're after libgl1-mesa-dev
[07:42] <robert_ancell> RAOF, thanks
[08:15] <didrocks> morning
[08:15]  * didrocks likes to begin the day with a broken X :)
[08:16] <RAOF> didrocks: Oh?
[08:16] <pitti> hey didrocks
[08:16] <didrocks> RAOF: nvidia card and still no nvidia driver, I tried to add:
[08:16] <pitti> didrocks: btw, tseliot fixed jockey to add a magic option to the nvidia-current driver, so that it  works with 1.9
[08:16] <didrocks> Section "ServerFlags"
[08:16] <didrocks>     Option "IgnoreABI" "True"
[08:16] <didrocks> EndSection
[08:16] <pitti> right, that
[08:16] <didrocks> but doesn't seem to work :/
[08:17] <didrocks> pitti: oh, really? (hey btw! had a safe travel?)
[08:17] <didrocks> hum, I'm trying the jockey way so
[08:17] <pitti> didrocks: yes, I arrived Wednesday; I've been here all yesterday :)
[08:17] <didrocks> (still on nouveau driver)
[08:17] <pitti> didrocks: tried the experimental nouveau 3D?
[08:17] <RAOF> didrocks: Where nature intended!
[08:17] <didrocks> RAOF: haha :-)
[08:17] <didrocks> how can I trigger the experimental nouveau 3D?
[08:18] <RAOF> Install libgl1-mesa-dri-experimental
[08:18]  * didrocks is in the last day before vacation, can experiment :)
[08:18] <RAOF> And Watch Your Friends Be Amazed!
[08:18] <didrocks> heh, let's try
[08:18] <didrocks> RAOF: nothing in xorg.conf?
[08:18] <RAOF> Nope.
[08:18] <RAOF> It's the free driver; it Just Works™ :P
[08:18] <RAOF> (When it works :)
[08:19] <didrocks> ahah :-)
[08:19] <didrocks> let's see
[08:19]  * pitti declares victory over gpm's appindicator patch and uploads
[08:19] <RAOF> You should be able to play around with a very-nearly-flawless unity, too.
[08:19] <didrocks> oh, the nouveau driver fix unity bugs too?
[08:19] <didrocks> awesome ;)
[08:20] <didrocks> ok, restarting X, see you :)
[08:20] <pitti> it fixes everything, including the stale taste of your morning coffee!
[08:20] <pitti> (... right?)
[08:21] <RAOF> My morning coffee is never stale!
[08:21] <RAOF> Maybe it's because I run nouveau :)
[08:21] <pitti> RAOF: that's because you are running nouveau
[08:21] <pitti> ah
[08:23] <pitti> RAOF: hm, seems that didn't go quite so well for Didier then..
[08:23] <pitti> ooh, he's back!
[08:23]  * pitti sees a three-dimensional didrocks
[08:23] <didrocks> RAOF: I'm really sorry to tell you I'm not amazed nor impressed :p
[08:23] <RAOF> pitti: Man, it'd be *awesome* if my laptop booted in under 3 minutes!
[08:23] <didrocks> pitti: it's a fake, still didrocks 2D :)
[08:24] <pitti> RAOF: *shrug* 8 seconds, what's the problem :) http://people.canonical.com/~pitti/bootcharts/donald-maverick-20100805-1.png
[08:24] <baptistemm> ssd ftw
[08:24] <baptistemm> :)
[08:24] <pitti> RAOF: seriously, 3 mins? my old Latitude D430 with the world's slowest-ever HDD booted in one min
[08:24] <RAOF> 5400 RPM laptop drive + broken btrfs partition FTL
[08:25] <pitti> oh
[08:25] <pitti> I'm on btrfs, too
[08:25] <didrocks> one min here too, but two restart of gdm, trying to a load a unity session and so on :)
[08:25] <pitti> and it didn't break yet, and that after a whole week
[08:26] <RAOF> pitti: Try a couple of unclean restarts.  I'm sure you can get btrfsck to segfault while checking consistency!
[08:26] <pitti> urgh
[08:26] <baptistemm> pitti: what is your ssd?
[08:26] <didrocks> pitti: I'll be trying the jockey way, uninstalling/reinstalling the nvidia driver should do it, right?
[08:26] <pitti> baptistemm: ... awesome!
[08:26] <pitti> baptistemm: erm, how can I find out? intel-something-crazy-fast
[08:26] <baptistemm> and the brand and model ?
[08:26]  * pitti pokes /sys
[08:26] <baptistemm> x25-m ?
[08:27] <didrocks> oh intel-something-*, good choice :)
[08:28] <baptistemm> this is certainly btrfs which gives you the 250 MB/s where I top to 150 with ext4
[08:28] <pitti> well, I'm not sure
[08:28] <pitti> $ cat /sys/block/sda/device/model
[08:28] <pitti> SAMSUNG MMCRE28G
[08:28] <pitti> baptistemm: would this be the correct file?
[08:29] <RAOF> baptistemm: Oh, so you haven't noticed the performance regression under write loads in 2.6.35?
[08:29] <baptistemm> it seems so I have INTEL SSDSA2M160
[08:29] <baptistemm> I still run lucid
[08:29] <pitti> RAOF: hm, as far as I can remember, Linux got utterly slow and stuttering under heavy IO load since about dapper
[08:30] <pitti> RAOF: but then again, my Dell never saw maverick, I kept it on lucid
[08:30] <baptistemm> I didn't know samsung was a ssh manufacturer
[08:30] <RAOF> Ah.  That might be part of it.  There's apparently a ~10x performance regression under write-heavy loads in 2.6.35
[08:30] <pitti> so it could have gotten even worse for sure
[08:30] <pitti> RAOF: oh, hang on; I recently read something like that
[08:30] <pitti> RAOF: but only for btrfs, right?
[08:30] <RAOF> pitti: Indeed, yes.
[08:30] <RAOF> pitti: Yeah.  It'd be interesting to see whether those desktop-interactivity patches are backportable.
[08:31] <RAOF> I think they're in 2.6.36 now.
[08:31]  * pitti fainlty remembers something like "*mutter mutter* doesn't allocate new blocks fast enough yadayada"
[08:31] <RAOF> Yeah, something like that.
[08:31] <pitti> I think the general stuttering on IO is rather a scheduler problem
[08:31] <RAOF> Which I think is what the interactivity patches claim to fix.
[08:32] <pitti> wasn't there a CFQ->BFQ patch mentioned on the list the other day?
[08:32] <pitti> E: ID_MODEL=SAMSUNG_MMCRE28G8MXP-0VBL1
[08:32] <pitti> baptistemm: ^ udev seems to confirm
[08:33] <pitti> palimpsest says it's 250 MB/s avg
[08:33] <baptistemm> wow
[08:33] <pitti> where my old disk was a mere 20
[08:33] <baptistemm> mehh, it's only 140MB for me
[08:33] <pitti> so in another three year's time it will be 5000, right?
[08:33]  * didrocks puts all his trust in jockey now :)
[08:34] <pitti> didrocks: it doesn't do much else than setting the ignoreabi flag
[08:34] <didrocks> pitti: the one in the section I listed? weird it didn't work
[08:34]  * pitti checks
[08:34] <pitti> oh, oops
[08:34] <pitti> seems that tseliot didn't actually commit it yet
[08:35] <didrocks> ahah, false hope so :-)
[08:35]  * didrocks checks what he saw on the Internet
[08:35] <pitti> self.xorg_conf.addOption('ServerFlags', 'IgnoreABI', 'True', optiontype='Option', position=0)
[08:35] <pitti> didrocks: but seems it's exactly the same
[08:35] <didrocks> why why why nvidia is so evil with me so…
[08:35] <baptistemm> damn palimpsest says I have feunct sectors :/
[08:35] <baptistemm> defunct
[08:36] <didrocks> I've waited for the update on purpose and saw this workaround
[08:36] <baptistemm> seb128 is off ?
[08:36] <didrocks> so, settings this and rebooting :)
[08:36] <didrocks> baptistemm: he arrived more at 10 as he is working late
[08:36] <didrocks> arrives*
[08:36] <baptistemm> k
[08:36] <RAOF> didrocks: How was nouveau 3D failing for you?
[08:37] <didrocks> RAOF: like a failing :-)
[08:37] <RAOF> Or we can investigate after exhausting the binary possibilities :)
[08:37] <didrocks> RAOF: unity didn't start, I'm still in low graphic resolution
[08:37] <RAOF> Oh, so even the 2d driver isn't working properly?
[08:37] <didrocks> RAOF: yeah, I always have low resolution with it
[08:38] <RAOF> Oh!
[08:38] <didrocks> well, low resolution beeing 1280x1024, but I have 1900x normally :)
[08:38] <RAOF> Smells like VESA?
[08:38] <tseliot> pitti, didrocks: I didn't have the time to test jockey, therefore I haven't committed my changes yet. I'll do it today
[08:38] <RAOF> Care to pastebin /var/log/Xorg.0.log?
[08:39] <didrocks> RAOF: sure
[08:39] <didrocks> tseliot: ok, thanks :)
[08:39] <didrocks> RAOF: all for you pleasure :) http://paste.ubuntu.com/477333/
[08:40] <RAOF> Incidentally, having the timestamps on Xorg.0.log has been immensely useful.
[08:40] <RAOF> didrocks: Yup, there it is.  VESA.
[08:40] <RAOF> didrocks: Hows about dmesg, too? :)
[08:40] <didrocks> to see that I'm failing in 17seconds ? :)
[08:41] <didrocks> RAOF: one sec, which part do you need of dmesg?
[08:41] <tseliot> RAOF, didrocks: it looks like vesa with the nvidia libraries
[08:41] <didrocks> tseliot: hum, sounds a good mixture :-)
[08:41] <tseliot> in the X log, that is
[08:41] <baptistemm> is it safe to switch to maveick now, is X upgrade 's done ?
[08:41] <RAOF> didrocks: Could I just have all of it?
[08:41] <didrocks> http://paste.ubuntu.com/477334/
[08:41] <didrocks> all is there :)
[08:41] <RAOF> baptistemm: As long as you're not reliant on nvidia or fglrx X is golden in Maverick.
[08:42] <RAOF> Well, also as long as you don't want to play around with GNOME screensaver preferences on -radeon.
[08:42] <tseliot> yep, the nvidia kernel module is there too
[08:42] <baptistemm> RAOF: okay I'm on Intel so it'll  be good I assume
[08:43] <RAOF> baptistemm: Should be. 2.12 is a bit faster and seems to work slightly better on the old, troublesome cards too.
[08:43] <baptistemm> pitti: Could you help me to review bluez from debian, the bluetooth dbus policy is not the same.
[08:43] <didrocks> baptistemm: I confirm, apart from nvidia, all is good :)
[08:44] <RAOF> Apart from the general tendency of intel GPUs to mysteriously hang, all is well on intel :)
[08:45] <tseliot> didrocks: you'll need 2 things: 1) my nvidia package with the updated dependency on xserver 1.9 (not uploaded yet) 2) my new code for jockey both of which I will commit today
[08:45] <baptistemm> pitti: http://paste.ubuntu.com/477336/
[08:45] <didrocks> tseliot: are there some branches somewhere or source package? I can gladely test them (still need 3D for unity update :))
[08:46] <tseliot> didrocks: the nvidia driver (at least the packaging scripts) is here: http://github.com/tseliot/nvidia-graphics-drivers
[08:46] <baptistemm> I guess we should keep our policy
[08:47] <RAOF> didrocks: The other option would be to properly remove nvidia, but it might be worth you testing the new binary drivers.
[08:47] <pitti> baptistemm: looks fine; we never used netdev, so if Debian dropped it as well now, so much the better
[08:47] <pitti> baptistemm: or is it the other way aroud and they added netdev?
[08:48] <didrocks> tseliot: RAOF: as you wish, tell me what I should do to help you too if I can test something with nouveau and such :)
[08:48] <tseliot> didrocks: I think it's also available in the xorg-edgers PPA and I can should you how to configure it if you're in a hurry
[08:48] <pitti> baptistemm: OTOH we don't use the "bluetooth" group either
[08:48] <tseliot> (I'm not sure about xorg-edgers though)
[08:48] <pitti> baptistemm: it might be best to just use at_console for now, if bluez still doesn't use PolicyKit
[08:48] <didrocks> tseliot: I tried xorg-edgers and it didn't work as well (with the same IgnoreABI bits)
[08:48] <baptistemm> pitti: netdev was from our package
[08:49] <pitti> baptistemm: ah, I see; our's already has at_console, so it should be fine
[08:49] <baptistemm> pitti: do you have an example to look at for at_console policy ?
[08:49] <baptistemm> ah okay
[08:49] <pitti> baptistemm: please do drop netdev then, and "bluetooth" along with it
[08:49] <pitti>         <policy at_console="true">
[08:49] <tseliot> didrocks: do you have the X log with nvidia from xorg-edgers?
[08:50] <pitti> baptistemm: ^ it's nothing more
[08:50] <didrocks> tseliot: I can reinstall it and try
[08:50] <didrocks> let's do that
[08:50] <tseliot> didrocks: ok
[08:50] <baptistemm> pitti: and what the lp group? I guess we should keep it.
[08:51] <pitti> baptistemm: yes, I think so
[08:54] <baptistemm> I need to update again the hal patch, pitti whould be better with upstream if we could have a hal witch at configure ?
[08:54] <baptistemm> *switch*
[08:55] <pitti> baptistemm: what is "the hal patch"?
[08:55] <pitti> we don't use hal any more..
[08:56] <baptistemm> pitti: a patch you did to remove hal call in bluez
[08:56] <pitti> ah
[08:56] <pitti> baptistemm: I don't think a switch makes sense at this point -- it should just disappear for good
[08:56] <pitti> but if other people want to keep it, then a configure option might do, yes
[08:57] <baptistemm> better I could just the patch upstream and see the reaction :)
[08:57] <baptistemm> *send*
[09:00] <seb128> hey
[09:01] <baptistemm> 10 o'clock just ring and seb128 is here didrocks was true
[09:01] <baptistemm> hello seb128
[09:01] <pitti> hey seb128, bonjour
[09:01] <seb128> lut baptistemm
[09:02] <seb128> hey pitti
[09:02] <seb128> baptistemm, ?
[09:02] <seb128> in fact I would have been a bit earlier today if I didn't run into a fsck after restart
[09:02] <baptistemm> I just asked if you were off, and didrocks told me you arrived at 10
[09:02] <baptistemm> *arrive*
[09:02] <seb128> do you need me for something?
[09:02] <pitti> we always need you, seb!
[09:02] <baptistemm> not at all, at least for now
[09:03]  * pitti hugs seb128
[09:03]  * seb128 hugs pitti
[09:03] <seb128> baptistemm, I did the bluez update btw
[09:03] <seb128> since your update had a conflict and was an outdated version now
[09:03] <seb128> lut didrocks
[09:03] <pitti> didrocks: what happened to your proxy?
[09:03] <didrocks> ahah, driver acceleration again \o/
[09:03] <didrocks> hey seb128
[09:04] <pitti> didrocks: ooh! with nvidia?
[09:04] <didrocks> pitti: well, my proxy is at home and for a month, I prefered to shutdown the power there :)
[09:04] <didrocks> pitti: yeah ;)
[09:04] <pitti> didrocks: oh, right, where are you again?
[09:04] <didrocks> tseliot: xorg-edgers fixed it. I was pretty sure to had a try earlier but it was before the coffee
[09:04] <didrocks> pitti: I'm in the Alps, near Annecy
[09:04] <tseliot> didrocks: I can understand ;)
[09:05] <didrocks> tseliot: heh, thanks a lot for your support. So hopefully, next update will fix that for nvidia user. Will you readd the dummy dep to avoid breaking on apt-get upgrade btw?
[09:05] <didrocks> RAOF: thanks to you too  :)
[09:06] <RAOF> ;)
[09:06] <didrocks> (first thing to do now: disabling xorg-edgers to avoid cry and sadness in the near futur :-))
[09:06] <tseliot> didrocks: are you referring on the video abi thing=
[09:06] <tseliot> ?
[09:06] <tseliot> np
[09:07] <didrocks> tseliot: I don't remember what exactly, RAOF told me there where a dummy dep to avoid this kind of thing happening for each new Xorg-server update (surely a dep having the video abi in the name)
[09:08] <RAOF> Yeah, it needs to have a dependency on xserver-xorg-video-$CURRENT_ABI; tseliot's on it.
[09:08] <tseliot> didrocks: I guess it's bug #616214 (a fix is available in my git branch)
[09:08] <ubot2> Launchpad bug 616214 in nvidia-graphics-drivers (Ubuntu) "Should Depend: on appropriate xserver-xorg-video-$ABI (affects: 2) (heat: 10)" [Medium,In progress] https://launchpad.net/bugs/616214
[09:08] <RAOF> tseliot: Did you notice the equivalent one for fglrx?
[09:08] <didrocks> tseliot: exactly, great to know it will be fixed when you push that! thanks :)
[09:08] <tseliot> np
[09:09] <tseliot> RAOF: I don't remember if something like that was in place in fglrx. Let me check
[09:09] <didrocks> RAOF: tseliot: later, if you want to have more try on a clean machine on the nouveau 3D, I can deserve a little time testing (not today but after my holidays)
[09:10] <RAOF> didrocks: Eh, not really.  I'd expect the 3D to work, but I *don't* plan to do anything more vigorous than ensure it builds; it's named “libgl1-mesa-dri-experimental” for a reason :)
[09:10] <didrocks> RAOF: ok, make sense :-)
[09:10] <tseliot> RAOF: there's no such thing in fglrx
[09:11] <RAOF> tseliot: Right, but there should be.  I'm sure I filed a bug last night about it?
[09:11] <didrocks> waow, the links are blue again in evolution now
[09:12] <tseliot> RAOF: right, bug #616215
[09:12] <ubot2> Launchpad bug 616215 in fglrx-installer (Ubuntu) "Should Depend: on appropriate xserver-xorg-video-$ABI (affects: 1) (heat: 6)" [Medium,Confirmed] https://launchpad.net/bugs/616215
[09:13] <RAOF> Ah, yeah.  There it is.
[09:13] <tseliot> RAOF: I think I'll just commit my changes in the upstream git branch for fglrx as the driver isn't ready for the new X yet
[09:14] <tseliot> oh, and I'll have to be backward compatible with the old xserver
[09:14] <vish> seb128: hi , about Bug #615793 , looks like making this change upstream would be nice?  shall i forward this upstream? or is this because of our notify-osd changes?
[09:14] <ubot2> Launchpad bug 615793 in gnome-bluetooth (Ubuntu) (and 2 other projects) "For each file received over bluetooth, a dialog is opened and must be dismissed (affects: 1) (heat: 8)" [Low,New] https://launchpad.net/bugs/615793
[09:15] <vish> seb128: mpt mentions to use the normal window there
[09:15] <kiwinote> mvo: goodmorning! atm in the appdetailsview the action button grabs focus. Is it ok to let the application name grab focus instead for a better a11y experience?
[09:15] <seb128> I guess upstream will blame it on our notifications
[09:15] <vish> yeah.
[09:17] <RAOF> tseliot: The -geode driver recently got some work to make it do the right thing against both old and new xservers; you might want to look at that.
[09:17] <tseliot> RAOF: ah, great, thanks for mentioning that
[09:20] <seb128> urg
[09:26] <Sarvatt> didrocks: you want ppa:ubuntu-x-swat/x-updates not xorg-edgers if you just want nvidia :)
[09:26] <didrocks> Sarvatt: well, too late, I just apt-get install the right pieces (apparently ;)), but thanks :-)
[09:30] <baptistemm> bluez is a pain to maintain due to init compatibity ...
[09:31] <didrocks> baptistemm: lot of diff there?
[09:31] <baptistemm> yep ...
[09:34] <seb128> arg
[09:34] <seb128> who gave robert_ancell upload rights
[09:38] <seb128> pitti, how crazy is today for you?
[09:38] <tseliot> maybe seb128 needs a holiday ;)
[09:38] <pitti> seb128: need to spend some hours on a project, but what's up?
[09:39] <seb128> pitti, robert_ancell just screwed poppler
[09:39] <seb128> he put soname7 in libpoppler6
[09:39] <pitti> 14.2 bumped ABI again?
[09:40] <pitti> *sigh*
[09:40] <seb128> and I'm on fire to get dx and touch changes in and reviewed and release updates for the meeting today etc
[09:40] <pitti> oh, maybe that explains the sudden segfaults in latex
[09:40] <seb128> pitti, yes, that's why I didn't do the update
[09:40] <pitti> http://launchpadlibrarian.net/53623740/buildlog_ubuntu-maverick-i386.gnome-power-manager_2.31.6-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:40] <seb128> I would really appreciate if somebody could sort that
[09:40] <pitti> seb128: I can just revert it for now
[09:41] <seb128> pitti, or rename the binary
[09:41] <seb128> but then we need a transition
[09:41] <pitti> I don't have time to do a full ABI bump today with a million rdepends, I'm afraid
[09:41] <seb128> the api change is small it's only one function
[09:41] <pitti> seb128: well, we need to fix libpoppler6 first, so we need a reversion first
[09:41] <seb128> pitti, ok please get the reversion
[09:41] <seb128> we will deal with the update later on
[09:42] <seb128> pitti, or rather "if you could revert his changes while I'm sorting those other things that would be great"
[09:42]  * seb128 hugs you
[09:42] <pitti> sure
[09:43] <seb128> pitti, thanks a lot
[09:49] <huats> morning
[09:49] <seb128> lut huats
[09:49] <seb128> huats, did you fix your build yet? ;-)
[09:49] <huats> salut seb128
[09:49] <huats> seb128, I couldn't find tim yet :(
[09:50] <huats> this moring
[09:50] <huats> I hope
[09:50] <huats> seb128, on the other hand it is quite tricky to fix something to you cannot reproduce :)
[09:51] <seb128> huats, I'm sure you can reproduce it
[09:51] <seb128> get the maverick source
[09:52] <huats> seb128, I am sure it is not doing it on my pbuilder
[09:52] <huats> I have rebuilt it since the fail
[09:53] <huats> seb128, just to please you, I am doing it right now :)
[09:54] <seb128> ;-)
[09:54] <seb128> no need to use pbuilder
[09:54] <baptistemm> pitti: Should we carry patch provided by http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535075
[09:54] <ubot2> Debian bug 535075 in bluez "bluez: Udev rules for hid2hci do not match any event" [Important,Fixed]
[09:54] <huats> seb128, well it is the way I build my stuffs :)
[09:55] <huats> seb128, so once again it might be related to that (we have faced that in the past already)
[09:55] <baptistemm> pitti: the patch is http://patch-tracker.debian.org/patch/series/view/bluez/4.69-1/010_udev_rules_agent.patch
[09:57] <baptistemm> hmmm, we don't have any /lib/udev/bluez
[10:00] <pitti> baptistemm: presumably the new bluez ships that itself?
[10:00] <pitti> baptistemm: not sure, if we can stop using this silly hid2hci thing, so much the better
[10:00] <pitti> but it'd be interesting to know what /usr/lib/bluez does
[10:00] <pitti> (which is not a good name at all)
[10:01] <seb128> baptistemm, pitti: the rules is in /lib/udev/rules.d in ubuntu no?
[10:02] <pitti> right, in Debian as well
[10:02] <pitti> but /lib/udev/bluez is apparently a new callout
[10:03] <seb128> hum, does anybody know what create debhelpers logs?
[10:03] <seb128> I couldn't get bluez to build a source package without those in the diff.gz yesterday
[10:04] <seb128> it's ridiculous
[10:04] <pitti> debhelper logs?
[10:04] <pitti> uh
[10:04] <pitti> those shold be temporary only
[10:05] <huats> seb128, I don't understand : the sources in maverick fails to build, while the sources I have uploaded (I still have them here) builds fine :(
[10:05] <huats> seb128, I have to dig :)
[10:05] <seb128> huats, debdiff those?
[10:06] <seb128> pitti, apt-get source bluez
[10:06] <huats> that was my next move
[10:06] <huats> :)
[10:06] <seb128> pitti,
[10:06] <seb128> $ cat debian/bluez.debhelper.log
[10:06] <seb128> dh_autoreconf_clean
[10:06] <seb128> for example
[10:06] <seb128> I rm debian/*.log
[10:06] <seb128> debuild -S -sa
[10:06] <seb128> and the logs are in back and in the diff.gz
[10:06] <mvo> kiwinote: I think changing that makes sense for a11y
[10:06] <pitti> seb128: maybe it wasn't cleaned at all?
[10:06] <pitti> seb128: debclean shold remove them?
[10:07] <kiwinote> mvo: great, thanks
[10:07] <seb128> pitti, it doesn't
[10:07] <seb128> I just ran debclean and they are still there
[10:08] <pitti> seb128: hm, does it have debian/compat?
[10:08] <mvo> kiwinote: I had this idea to create failing tests for some of the bugs I'm aware of so that noone is bored while I'm away for a week, do you think that would be interesstng?
[10:08] <seb128> pitti, yes, set to 7
[10:08] <mvo> we could have little prices even :)
[10:09] <kiwinote> mvo: yeah, that could sound interesting
[10:09] <mvo> nice
[10:10] <mvo> I will give it a go and commit something to trunk soonish
[10:10] <kiwinote> mvo: I think next week I will also look at the startup-speed branch as well, to try and win back some time
[10:11] <kiwinote> mvo: then there is the history pane which also needs a bit of care. I started on that a little while back, but got stuck when the treeview started lagging
[10:12] <kiwinote> mvo: I haven't looked at it yet, but I think I'll be able to use some of the branched installed pane code for that
[10:12] <baptistemm> sorry I have to go
[10:15] <sabdfl> seb128: non-feature-freeze question for you: in gnome-terminal, when you add a second tab, you get borders left right and bottom of the window. can those be suppressed? np to reply next week when the dust has settled :-)
[10:16] <seb128> hey sabdfl
[10:17] <seb128> I don't know offhand, would need to check the code but I guess that should be possible yes
[10:17] <seb128> I will let you know after checking but probably not today, today is going to be busy ;-)
[10:17] <pitti> seb128: poppler reversion uploaded and building, and fixed 0.14.2 prep'ed; I'll upload this once the reversion has built (otherwise they'll fail to upload)
[10:17] <seb128> pitti, thanks a lot
[10:18] <seb128> pitti, you can wait next week to upload the new version if you want then we can deal with the soname change in a better way
[10:18] <pitti> seb128: well, we can just leave it in NEW a bit
[10:19] <pitti> seb128: and even if it is accepted, it doesn't really hurt, just some NBS, right?
[10:19] <seb128> right
[10:19] <pitti> I can deal with some rebuilds
[10:19] <seb128> thanks for fixing that mess today
[10:20] <sabdfl> seb128: thanks very much
[10:20] <pitti> bbiab
[10:22] <didrocks> pitti: take care, there are a lot of them (just look at the activity report from this week, most of the rebuild are listed there). As I first built all locally, it took times :(
[10:26] <mvo> kiwinote: the stuff that nzmm was working on? to show a treeview in the installed pane?
[10:26] <kiwinote> mvo: yep, I haven't looked at it yet, but I presume it is that same as what the history pane should use
[10:31] <mvo> ok
[10:42] <seb128> mvo, update manager buttons are weird since a recent update, is that a design change or a bug?
[10:42] <seb128> they are thin
[10:43] <pitti> confirmed here
[10:43] <pitti> if that is a design change, it's a very strange and objectionable one
[10:46] <mvo> seb128: a bug, or rather the result of changing a different bit of the UI
[10:47] <seb128> ok
[10:47] <seb128> mvo, I also get package description displayed in german!?
[10:47] <mvo> seb128could you file a bug and target it for beta
[10:47] <seb128> some of those at least
[10:47] <mvo> seb128: oh?
[10:47] <seb128> but I'm using a french locale
[10:47] <mvo> seb128: woah
[10:48] <seb128> but that's not really new I think
[10:48] <mvo> seb128: could you please check if /var/lib/apt/lists/ has some *de* translations
[10:48] <seb128> mvo, it has
[10:48] <mvo> seb128: for what packages
[10:49] <mvo> seb128: what is your "echo $LANGUAGE" output?
[10:49] <seb128> $ echo $LANGUAGE
[10:49] <seb128> fr_FR:fr:de:en_US:de_AT:de_BE:de_CH:de_DE:de_LI:de_LU:en
[10:49] <mvo> seb128: there you go
[10:49] <seb128> so it means it will do french, german then english?
[10:49] <mvo> seb128: yes
[10:49] <seb128> ok
[10:49] <seb128> I never set that
[10:50] <seb128> I guess it's another language selector thing
[10:50] <mvo> yeah, could you open it and check ?
[10:50] <mvo> its really a odd setting
[10:51] <seb128> I had german before english
[10:51] <mvo> show that apt is cleve ;)
[10:51] <mvo> clever even
[10:51] <seb128> I might have played with the thing trying to figure how the ui was working and inverted german and english
[10:51] <seb128> thanks
[10:51] <mvo> cheers
[10:51] <mvo> the UI is a problem in itself :(
[10:51] <mvo> its not a11y friendly at all
[10:52] <mvo> so if someone has spare cycles it would be awsome to add "up" and "down" buttons
[10:52] <mvo> so that people without mouse can actually drive the UI
[10:53] <mvo> mpt: see above, I think you talked with arne about the a11y problem, not sure if there is a solution yet (design-wise)
[10:55] <mpt> mvo, yes, you should be able to Ctrl+Up or Ctrl+Down to move the selected language
[10:55] <mpt> but it looks like you can't even select a language in the list
[10:56] <mvo> ok, if those keys are known to people who needs them, I'm of course fine with that solution
[10:56] <seb128> mvo, pitti: bug #617295
[10:56] <ubot2> Launchpad bug 617295 in update-manager (Ubuntu) "buttons are thin since recent changes (affects: 1) (heat: 6)" [Low,New] https://launchpad.net/bugs/617295
[10:57] <mvo> thanks seb128
[10:57] <seb128> np
[11:00]  * mpt wonders idly if today is a good day to upgrade to Maverick
[11:04] <pitti> uh, oh, it's Friday the 13th
[11:04] <pitti> seb128: ^ that might explain a few things :)
[11:21] <seb128> rodrigo_, could you drop the couchdb-glib json-glib libubuntuone ubuntuone-client build-depends on gir-repository-dev?
[11:22] <seb128> rodrigo_, I think it should not be required nowadays
[11:22] <mpt> mvo, are apturl and gdebi removed from the seed now?
[11:22] <seb128> rodrigo_, the gir are coming from the independent sources now
[11:31] <mvo> mpt: no, not yet
[11:31] <mvo> mpt: let me do that now
[11:35] <mpt> mvo, and the Provides: and Replaces: marked?
[11:35] <mvo> chrisccoulson: hi, apturl should no longer be needed for ubufox, you can remove that dependency, software-center will deal with that
[11:36] <mvo> mpt: replaces means something different (file replaces). provides is appropriate, but I think we don't need it, the amount of rdepends is very small
[11:36] <chrisccoulson> mvo - for the plugin installer part?
[11:37] <mvo> mpt: also, s-c does not provide gdebi in the sense that it has all the same features, e.g. showing the filelist etc is not support (intentionally) in s-c so a providesis not quite right
[11:37] <mvo> chrisccoulson: I guess, I don't know what ubufox is using it for
[11:37] <chrisccoulson> mvo - yeah, it's for that. so, calling apturl will invoke SC?
[11:37] <mpt> mvo, so is it possible to configure it so that (a) upgrading to Maverick uninstalls apturl and gdebi by default, but (b) it's still possible to reinstall them (without uninstalling software-center) later?
[11:38] <kiwinote> chrisccoulson: s-c doesn't support plugin finding
[11:38] <chrisccoulson> i'm confused now
[11:38] <chrisccoulson> :)
[11:39] <mpt> ... plugin finding?
[11:39] <mvo> mpt: yes, we can do that via the upgrader. also for upgrade we can simply give s-c a higher priority in the deb handling than gdebi so that all debs are opened by default iwth it. but users who look for it can still find it easily
[11:39] <chrisccoulson> mpt - yes, ubufox calls apturl to install browser plugins
[11:39] <mpt> mvo, brilliant.
[11:39] <chrisccoulson> ubufox provides our plugin finder for firefox
[11:39] <mvo> mpt: gdebi is now unseeded
[11:40] <mvo> mpt: from ubuntu, the other seeds/flavours will make the decision about this on their own (but I think they will just follow suit)
[11:40] <mpt> chrisccoulson, are you making a distinction between finding and installing?
[11:41]  * mpt is disappointed he can't upgrade to Maverick today
[11:42] <mvo> mpt: whats wrong? do you get a error messgae?
[11:42] <chrisccoulson> mpt - i was just trying to understand mvo's suggestion that apturl is no longer needed for ubufox ;)
[11:42] <chrisccoulson> but now i've just got confused instead
[11:42] <mpt> mvo, "An unresolvable problem occurred while calculating the upgrade: E:Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages."
[11:43] <kiwinote> chrisccoulson: if a user browses to apt:pkgname, then s-c will take care of the rest
[11:43] <mpt> chrisccoulson, so software-center replaces apturl as the handler for apt: links. Is there anything else apturl did that I didn't know about?
[11:43] <chrisccoulson> kiwinote, ok, that's orthogonal to the plugin installer, which is what ubufox really needs apturl for
[11:43] <kiwinote> chrisccoulson: I'm not quite sure precisely how the plugin finder code works
[11:44] <chrisccoulson> the plugin installer calls apturl directly
[11:44] <chrisccoulson> mpt - how does SC replace apturl as the hanlder for apt: links? it needs to register the handler in firefox first
[11:44] <kiwinote> chrisccoulson: that's what we do atm
[11:44] <chrisccoulson> currently, apturl does that itself (registers itself as a handler)
[11:45] <chrisccoulson> ok, i see
[11:45] <mpt> So is this just a search-and-replace needed in ubufox?
[11:45] <chrisccoulson> so, what we really need is to update apturl to not register itself as a handler
[11:45] <chrisccoulson> ubufox still needs apturl until it's ported to something else
[11:46] <kiwinote> chrisccoulson: so does the plugin finding itself happen in apturl or ubufox?
[11:46] <mpt> chrisccoulson, until *what* is ported to something else?
[11:46] <kiwinote> chrisccoulson: I had thought the latter..
[11:46] <chrisccoulson> kiwinote, in ubufox
[11:46] <chrisccoulson> mpt - ubufox
[11:46] <chrisccoulson> ubufox calls apturl specifically to install browser plugins ;)
[11:47] <chrisccoulson> that's separate to the handling of apt: links in firefox
[11:47] <kiwinote> chrisccoulson: does ubufox call apturl with a pkgname, or with a mimetype request?
[11:47] <chrisccoulson> kiwinote, with a packagename
[11:48] <kiwinote> chrisccoulson: if that is the case, then we can just replace that call with a s-c call for a pkgname if s-c is installed
[11:49] <chrisccoulson> ok, that's easy enough
[11:49] <kiwinote> chrisccoulson: nice ;)
[11:49] <kiwinote> chrisccoulson: were there any other things ubufox relies on apturl for, or is that it?
[11:50] <mpt> Is this a case where we really should use Provides:, then? i.e. software-center intercepts the call for "apturl package-name" if apturl isn't installed
[11:50] <chrisccoulson> kiwinote, that's all IIRC
[11:50] <kiwinote> chrisccoulson: great, thanks!
[11:59] <chrisccoulson> kiwinote, is there a minimum version of software-center required to be able to use it from ubufox to install plugins?
[11:59] <chrisccoulson> i'd like to ensure it's still possible to backport ubufox to older ubuntu versions and still work properly
[12:00] <kiwinote> chrisccoulson: yes, 2.1.9
[12:00] <chrisccoulson> kiwinote, thanks
[12:01]  * kiwinote -> lunch
[12:18] <dpm> hi mvo, the translation for the "Distribution updates" message in update-manager does not seem to be loaded (see http://imagebin.ca/view/h_QyhW.html). Before I file a bug, would you know off the top of your head if that message is supposed to come from somewhere else (e.g. aptdaemon, python-apt, etc.)?
[12:19] <pitti> seb128: oh, the small buttons also affect firefox -- itz gtk bug?
[12:21] <seb128> pitti, where?
[12:21] <seb128> pitti, could be iz light-themes bug
[12:21] <pitti> seb128: open a LP bug page
[12:21] <pitti> the "Send reply" or "Save changes" button
[12:21] <pitti> sorry, "Post comment", not "send reply"
[12:22]  * pitti lunches
[12:22] <seb128> pitti, hum indeed, weird
[13:19] <mvo> dpm: update-manager should be the one
[13:20] <asac> didrocks: are you there? or on vacation this week?
[13:23] <didrocks> asac: I'm on vacation starting next week
[13:24] <mvo> dpm: odd, is the other stuff translated ? like Recommended upgrades for example?
[13:24] <mvo> dpm: it should be all the same code
[13:24] <mvo> dpm: the other headers I mean
[13:24] <asac> didrocks: kk. enjoy. in the meantime we will probably rape clutter as projected in the mail ;)
[13:25] <asac> seems we will have to take it over until it flows upstream. the approach keeps it as compatible as possible to debian (e.g. by keeping same package name etc)
[13:29] <didrocks> asac: as some packaging system? did you discuss more with debian, (that means, reping pochu about it, and such?)
[13:29] <asac> didrocks: we cant wait for debian
[13:29] <didrocks> asac: still didn't have the time to came to your email, very busy day
[13:30] <didrocks> asac: as long as you ensure merges, no pb for me :)
[13:30] <didrocks> but I don't want to merge such high gap
[13:30] <asac> pochu: are you there?
[13:31] <seb128> asac, if you want to do clutter changes please talk to me while didrocks will be on holidays
[13:34] <asac> seb128: sure. you can review the package in alfs repository
[13:35] <asac> i dont see debian to be flexibile enough to take this atm as they are already in freeze
[13:35] <asac> we made it so that there are zero changes for GL/intel stack
[13:35] <didrocks> asac: at least, they can upload to experimental, what they would have done in any case
[13:36] <asac> didrocks: yeah, though imo we are not in the position to drive this in debian. if pochu wants to take it now i would be happy. if not we cannot block on that anymore. its getting far too late
[13:37] <didrocks> asac: as long as you handle futur merge, again, no pb on my side :)
[13:37] <seb128> asac, I want their opinion at least on the change before uploading
[13:37] <asac> right. thats clear.
[13:38] <seb128> asac, they don't need to upload
[13:38] <asac> seb128: the change is done in a way that doesnt change anything for you guys ;)
[13:38] <asac> but ok ... if pochu doesnt reply we cant wait for him though
[13:38] <seb128> asac, well it change the packaging system
[13:38] <asac> let me reply to the mail and ask pochu to review
[13:39] <seb128> asac, but right, we will not block on that
[13:39] <asac> i will CC you
[13:39] <seb128> thanks
[13:39] <asac> whats pochus email?
[13:39] <asac> pochu@debian.org?
[13:39] <seb128> yes
[13:40] <seb128> asac, can you unblock didrocks' mir requests btw?
[13:40] <seb128> I will make sure clutter goes in in exchange ;-)
[13:40] <didrocks> ahah, the tradeoff :-)
[13:41] <asac> right. thats my bargain
[13:41] <pochu> hey guys
[13:41] <asac> i am preparing MIR rush
[13:41] <asac> pochu: whats your email=
[13:41] <asac> ?
[13:41] <asac> pochu@debian.org ?
[13:41] <pochu> yup
[13:41] <pochu> is this about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588244 ?
[13:41] <ubot2> Debian bug 588244 in clutter-1.0 "Clutter eglx packaging" [Wishlist,Open]
[13:42] <asac> right. though we have a much better approach now
[13:42] <asac> pochu: give me your email and i will forward you the stuff
[13:42] <pochu> sorry for not looking at that yet, didn't know you were blocked on it
[13:42] <pochu> asac: you've said it twice already ;)
[13:42] <asac> no problem
[13:42] <asac> let me also include the bug in the CC ;)
[13:42] <pochu> ty
[13:44] <asac> pochu: ok sent ;)
[13:44] <asac> its a reply to a mailthread ... so read all the inlines etc ;)
[13:44] <asac> pochu: if you have questions we are here
[13:45] <asac> pochu: what we did is leave the glx packaging as much as possible untouched. ensuring the the eglx build has a compatibile api and us the fake soname there to ensure that we can drop-in replace it ;)
[13:45] <asac> but read the mail
[13:45] <pochu> ok
[13:45] <asac> missing api element in eglx was just one function which we implemented in software for now (hooking up the x11 function)
[13:46] <asac> and after that we add code that will pick up egl/gles extension from hw if implemented
[13:46] <asac> pochu: that part we will get into clutter 1.3 too ... since everyone agrees that its the right thing to do apparnelty
[13:46] <asac> and intel with moorsetown probably will see that as well soon ;)
[13:47] <pochu> asac: there's no patch in your mail AFAICS ?
[13:48] <asac> pochu: not included because its too big ... let me get you the .dsc
[13:48] <kenvandine> seb128, good morning
[13:49] <kenvandine> seb128, can you restart https://edge.launchpad.net/ubuntu/+source/libgwibber/0.0.3-0ubuntu1/+build/1916895
[13:49] <pochu> asac: I'd rather look at a debdiff if possible
[13:49] <asac> https://edge.launchpad.net/~afrantzis/+archive/clutter-1.2-unified/+files/clutter-1.0_1.2.12-0ubuntu4unified1.dsc
[13:49] <asac> alf__: can you reply to the mail i just sent and attach the debdiff
[13:49] <dpm> mvo, I'm not sure if the other headers in u-m manager are translated, that's the only one I saw. I think I'll file a bug.
[13:49] <asac> pochu: debian vs. our proposal?
[13:49] <pochu> asac: is there an upstream bug for the upstream 1.3 bits?
[13:50] <pochu> asac: or the current unpatched Ubuntu package vs the proposed package
[13:50] <pochu> to keep the diff minimal
[13:50] <mvo> dpm: ok, I have a look now
[13:50] <asac> ok let me see
[13:50] <pochu> asac: or if Ubuntu has the same clutter version, Debian vs. proposed package is fine too
[13:50] <seb128> kenvandine, hey
[13:51] <seb128> kenvandine, retried
[13:51] <seb128> hey nessita
[13:51] <kenvandine> thx
[13:51] <dpm> thanks mvo :)
[13:51] <seb128> yw
[13:52] <kenvandine> hopefully whatever broken  depends are all published now
[13:52] <seb128> kenvandine, can you drop the libgwibber build-depends on gir-repository-dev
[13:52] <seb128> ?
[13:53] <seb128> I'm trying to get gir-repository back to universe
[13:53] <seb128> now that the useful gir come from sources
[13:53] <kenvandine> i'll try
[13:53] <seb128> thanks
[13:53] <seb128> if you lack a gir let me know which one
[13:53] <seb128> but I doubt you do
[13:53] <kenvandine> /usr/share/gir-1.0/DBus-1.0.gir
[13:53] <kenvandine> i probably need that
[13:53] <chaotic> ah you are :)
[13:54] <seb128> hum
[13:55] <asac> alf__: please collapse changelogs to the topmost when rebasing to latest in future ;)
[13:56] <alf__> asac: sure :)
[13:56] <asac> pochu: ok sent debdiff ... because we had to do a two run build, we moved to dh7 ... and also added .symbols for tracking abi etc.
[13:57] <asac> alf__: also can you file a bug against upstream clutter to add the texture_pixmap to the eglx api?
[13:57] <nessita> hi seb128, how are you?
[13:57] <asac> pochu probably feels more comfortable about that
[13:57] <seb128> nessita, I'm a bit tired but otherwise rather fine, thanks, what about you?
[13:58] <nessita> I'm great, is FRIDAY! :-)
[13:58] <alf__> asac: I can do that, but they will probably not do it as it is not needed any more for 1.3.x
[13:58] <kenvandine> nessita, it's friday the 13th!
[13:58] <kenvandine> :-D
[13:59] <nessita> kenvandine: the best friday ever ;-)
[13:59] <kenvandine> :-D
[13:59] <asac> alf__: well. there still is a frontend api isnt there?
[13:59] <asac> for texture_to_pixmaps?
[14:00] <asac> or is there approach to use cogl directly?
[14:00] <asac> their
[14:01] <asac> or did they drop the clutter*pixmap symbols alltogether?
[14:01] <kenvandine> seb128, i think i can drop that
[14:01] <alf__> asac: in 1.3.x one can call clutter_x11_texture_pixmap, and it does all the magic depending on the cogl variant that is used.
[14:02] <kenvandine> if i convert it from a --includes DBus to --pkg
[14:02] <asac> alf__: ok so all this goes away? what changes do we need for 1.3 to work as we want?
[14:02] <seb128> kenvandine, we should maybe have a try to get dbus building a gir
[14:02] <asac> alf__: i doubt its just ready (TM)
[14:03] <seb128> kenvandine, I will add that to my todolist
[14:03] <kenvandine> thx
[14:03] <asac> alf__: whatever we need to do on 1.3 we would have to file an upstream bug
[14:03] <asac> or it just a packaging thing by then? e.g. two run build, hack soname, put into two packages?
[14:05] <kenvandine> seb128, ok, that works... i can drop it
[14:05] <alf__> asac: packaging thing, plus handling (or not) of extra variant symbols eg clutter_eglx_display
[14:06] <seb128> kenvandine, no hurry, whenever you do the next uploads
[14:06] <seb128> kenvandine, there is a lot of rdepends to clean it will not be done this week
[14:06] <alf__> asac: of course, programs should be changed to use clutter_x11_texture_pixmap and just ignore clutter_glx_texture_pixmap
[14:07] <asac> alf__: right. but unless upstream drops clutter_glx_texture_pixmap completely we have to add it to eglx
[14:07] <asac> still
[14:07] <asac> just as a convenience func
[14:07] <kenvandine> seb128, yeah, it'll require a release of libgwibber anyway
[14:08] <kenvandine> needed to change the Makefile a bit
[14:09] <asac> alf__: so if clutter_glx_texture_pixmap isnt dropped in 1.3 upstream we have to file that upstream bug ;)
[14:09] <alf__> asac: they won't drop it, but i doubt they will want an api called clutter_glx_texture_pixmap to the *eglx* variant
[14:09] <pochu> asac: I added a symbols file in Debian too
[14:09] <alf__> asac: i will file the bug but i don't expect much
[14:09] <pochu> asac, alf__: yeah, I'd rather API additions go upstream
[14:10] <pochu> asac, alf__: what are the tests binary packages needed for?
[14:10] <asac> pochu: ok thats good. you should definitly take our patch that hides the backend symbols though
[14:10] <asac> e.g. the one replacing cluter  with _clutter
[14:10] <asac> otherwise you cannot have same API for egl/glx afaict
[14:10] <pochu> asac, alf__: gtg for lunch, I'll finish looking at it after it
[14:10] <asac> pochu: we have those test binaries to allow easy testing
[14:10] <asac> pochu: also as benchmarks etc.
[14:11] <asac> pochu: also for egl we have the embedded world with all the drivers not being ready ... so its convenient to tell them: look at those tests and make them work ;)
[14:11] <alf__> asac, pochu: do you still need that debdiff?
[14:11] <asac> pochu: you rock.
[14:11] <asac> alf__: i sent it already
[14:11] <alf__> asac: ok, thanks!
[14:12] <asac> alf__: its definitly dirty, so if pochu really reviews it this way we should send him a beer or something
[14:12] <pochu> heh
[14:12] <asac> but otoh its a few month of work, so its expected to be large
[14:12] <asac> but we can probably better tell him what changes are for what topic
[14:12] <asac> like the backend symbol hiding bits etc.
[14:12] <pochu> asac: well, can't you tell them to make 'make check' pass?
[14:13] <asac> pochu: its really convenient to have the test cases packaged. why is that a problem ;)?
[14:13] <asac> make check runs all those tests?
[14:13] <pochu> asac, alf__: it would also be great if you can send the upstream patches upstream
[14:13] <asac> at least the SGX from TI passes make check, but the tests are buggy iirc ... also some stuff is slow and you dont see that in make check
[14:13] <pochu> asac: I dunno, I'd hope so :)
[14:14] <asac> pochu: yes, but upstream doesnt reply to us
[14:14] <asac> pochu: i dont think it does that. those tests are running infititely so you need human interaction to check etc.
[14:14] <pochu> asac: I've sent 3 patches upstream already and they've replied to all of them, 2 are already committed
[14:14] <pochu> asac: ah ok
[14:15] <asac> pochu: right. we can send paches upstream, but for 1.2 its too late and as alf__ explained above a bunch of things changed in 1.3 ... but yes, we should send the backend hiding patch at least
[14:15] <pochu> asac: you can also prod ebassi on #gnome-hackers (I needed to do that)
[14:15] <asac> great
[14:15] <asac> alf__: ^^
[14:15] <pochu> I'd rather there's a bug report without replies, than none because you think they won't reply at all :-)
[14:15] <asac> alf__: is the backend hiding symbols patch still neede din 1.3 ?
[14:15] <pochu> anyway, lunch
[14:15] <asac> pochu: enjoy
[14:16] <pochu> (also they probably want bug fixes for 1.2.x)
[14:16] <alf__> asac: I am not sure, I haven't checked in a while
[14:16] <asac> alf__: i think we should file two bugs: a) backend symbols need to be hidden (i know they already said they dont care, but still)
[14:16] <asac> b) add clutter_glx_texture_pixmap that calls the x11 function for eglx
[14:16] <alf__> pochu: have a nice lunch
[14:16] <asac> (unless they killed clutter_glx_texture_pixmap altogether)
[14:17] <alf__> asac: do you mean for 1.3?
[14:17] <asac> yes, everything we talk about here for upstream is 1.3 (or rather trunk)
[14:19] <alf__> asac: ok, i'll file them, but as I said don't expect much for (b)
[14:22] <asac> alf__: why? if upstream does not drop clutter_glx_texture_pixmap for 1.3 we still should add it to allow drop-in ... even if its just a simple wrapper around x11
[14:22] <asac> if they dropped it from 1.3 then its indeed a null op ;)
[14:24] <alf__> asac: they can't drop it because of backwards compatibility (clutter 1.3.x is still "clutter-1.0")
[14:25] <alf__> asac: What i meant is that is not likely that they will wan't to accept the patch for (b) upstream
[14:25] <asac> alf__: right. so we want to add it for egl
[14:26] <asac> alf__: we should try. we have strong argument as we can then drop-in replace which will also come handy for other distributions etc.
[14:26] <alf__> asac: we will try :)
[14:27] <asac> alternatively they could make a good pluggable backend architecture ;)
[14:27] <asac> but even then you would need that symbol for -1.0
[15:05] <seb128> pitti, do you update the team members in the workitems tracker?
[15:05] <seb128> pitti, how often?
[15:08] <mvo> kiwinote: thanks for oyur work on the a11y, I just merged your branch
[15:09] <kiwinote> mvo: thanks
[15:09] <mvo> kiwinote: is there more come? otherwise I will upload it soonish into maverick
[15:09] <kiwinote> mvo: you can do the upload whenever
[15:09] <mvo> kiwinote: ok, thanks!
[15:10] <kiwinote> mvo: there is still more to come, don't worry ;) I'm just working out how to get the pkgstatusbar accessible without changing too much of the gtk structure..
[15:11] <kiwinote> mvo: but that can wait until after the upload
[15:14] <fta> it seems empathy is not reporting the proper status to gtalk, is that known?
[15:14] <fta> or am i missing something?
[15:16] <pitti> seb128: every day
[15:16] <seb128> pitti, hum, it didn't pick it up today
[15:17] <seb128> pitti, we still have server specs on http://people.canonical.com/~pitti/workitems/maverick/canonical-desktop-team-ubuntu-10.10-beta.html
[15:18] <pitti> seb128: but perhaps that's broken; asac also pointed out a problematic one
[15:18] <pitti> I have that on my TODO, just no time to get to that yet
[15:18] <seb128> pitti, ok thanks
[15:22] <chrisccoulson> mvo - software-center isn't actually registering as a handler for apt url's yet (it's missing some keys in software-center.js)
[15:23] <mvo> chrisccoulson: oh, what is missing?
[15:24] <chrisccoulson> mvo - it's missing the network.protocol-handler.app.apt key, which is the one which tells it to use software-center
[15:25] <devildante> mvo: here?
[15:25] <mvo> hey devildante
[15:25] <devildante> mvo: hi :)
[15:26] <mvo> hey devildante
[15:26] <devildante> mvo: what's the state of affairs? (slept really late, sorry I wasn't present earlier :( )
[15:27] <mvo> devildante: no worries, FFe is filed and under investigation
[15:27] <mvo> chrisccoulson: thanks, fixed now
[15:27] <devildante> mvo: thanks :)
[15:27] <chrisccoulson> mvo - thanks
[15:27] <devildante> mvo: can we still fix bugs in trunk?
[15:28] <mvo> devildante: absolutely
[15:28] <mvo> devildante: we can and should do that :)
[15:28] <mvo> devildante: do you have something pending?
[15:28] <devildante> mvo: nah, just curious
[15:28] <mvo> ok
[15:28] <mvo> :)
[15:28] <devildante> mvo: but do you have a nasty bug you want to get rid of? I can fix it if you want :)
[15:29] <mvo> devildante: there is one  where the viewswitcher behaves oddly when channels get added, but I don't have found a reliable way to reproduce yet
[15:30] <mvo> devildante: there is also bug #613928
[15:30] <ubot2> Launchpad bug 613928 in software-center (Ubuntu) "Install/Remove button is missing in app details view whenever another install/remove is in-progress (affects: 1) (heat: 6)" [Medium,Fix released] https://launchpad.net/bugs/613928
[15:30] <mvo> that is a bit anoying and would be nice to get fixed (shouldn't actually be too hard)
[15:31] <devildante> mvo: hey, that's fix released!
[15:31] <mvo> devildante: oh! lalala
[15:32] <devildante> mvo: "don't fix what ain't broken" :p
[15:32] <mvo> devildante: heh :)
[15:33] <mvo> devildante: even bettter,!
[15:33] <devildante> mvo: for the first bug, how can you even add channels right now?
[15:33] <mvo> devildante: yeah, that happens e.g. when something is purchased and that makes it so tricky to reproduce
[15:33] <devildante> oh
[15:34] <devildante> mov: so you purchased something? in secret? :p
[15:34] <devildante> mvo*
[15:34] <mvo> devildante: its all dummy code currently and dummy packages, you can purchase the "hello" package (apt-cache show hello)
[15:35]  * mvo needs to run out for some minutes
[15:36] <devildante> okay, take your time :)
[15:39] <chrisccoulson> mvo - if ubufox is using software-center to install the plugins, is there any way of knowing when the install is finished? (apturl just used to exit, which is easy to detect)
[15:41] <kiwinote> chrisccoulson: no, there isn't atm, as the user may already have s-c open or may keep it open. we could use a dbus signal for that perhaps
[15:41] <chrisccoulson> kiwinote, that's pretty difficult to pick up from a browser plugin though :/
[15:42] <devildante> kiwinote: just by curiosity, shouldn't we just open the firefox appdetailsview in the future? (if my addons branch ever get merged)
[15:44] <kiwinote> devildante: by the looks of it your current firefox screen doesn't actually list any addons..
[15:44] <kiwinote> devildante: ah, wait, it crashed
[15:46] <devildante> kiwinote: http://i.imgur.com/FW1TI.png
[15:48] <kiwinote> devildante: thanks, the plugins we are referring to are things like flash and totem plugins which don't seem to be in that list
[15:48] <pitti> good bye, have a nice weekend!
[15:48] <seb128> pitti, thanks, have a nice weekend as well
[15:48] <devildante> kiwinote: oh
[15:48] <kiwinote> devildante: in the future it would be nice to build 'search for mimetype' functionality straight into s-c
[15:49] <devildante> kiwinote: maybe we could have explicit add-ons in sc, and I mean add-ons manually added, and not automatically added via Recommended and stuff
[15:49] <mvo> devildante: there is one bug in the back-forward handling in the addons, for some reason show_applicaton does not properly register so going back from a details view in a plugin does not return to the original app (e.g. app is gimp, click on gimp-gutenprint, click back)
[15:50] <mvo> devildante: if you are keen on work on on another one :)
[15:50] <devildante> mvo: okay :)
[15:50] <kiwinote> devildante: I've had a quick look at the branch
[15:50] <kiwinote> devildante: great work, just a few minor points i found
[15:51] <kiwinote> devildante: http://paste.ubuntu.com/477481/
[15:52] <kiwinote> devildante: missed one: if the big icon in the detailsview is meant to be a missing_pkg_icon then it isn't displayed
[15:52] <devildante> kiwinote: mvo: thanks for the infos, will take care of this now :)
[15:53] <devildante> mvo: aren't you supposed to be on vacation? :P
[15:53] <mvo> devildante: tomorrow :)
[15:53] <devildante> mvo: okay :)
[16:10] <devildante> kiwinote: the big icon bug has been fixed :p
[16:10] <kiwinote> devildante: nice ;)
[16:13] <alf__> asac, pochu: http://bugzilla.clutter-project.org/show_bug.cgi?id=2267
[16:13] <ubot2> bugzilla.clutter-project.org bug 2267 in General "Hide internal glx and egl(x) backend symbols." [Normal,New]
[16:20] <pochu> alf__: cool
[16:21] <asac> pochu: any first complaints ;)
[16:21] <asac> ?
[16:21] <asac> thanks alf__ !!
[16:23] <pochu> asac: I'm looking at it, looks good generally
[16:23] <pochu> alf__: shouldn't eglx_texture_pixmap.patch go upstream too?
[16:23] <pochu> I'm not comfortable adding APIs downstream
[16:23] <asac> pochu: so i see we killed the control.in feature ... is it a problem for you to a) move to dh7 like suggested and b) to readd the control.in feature for your@GNOME_TEAM@ tag?
[16:23] <seb128> kenvandine, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-social-api
[16:23] <asac> pochu: yes, he will submit that now
[16:23] <seb128> kenvandine, can you postpone all the items about api and widgets that didn't land?
[16:24] <asac> pochu: but its essential to add to keep both APIs drop in replace for the glx one
[16:24] <asac> so its not really extending api ... just synching api ;)
[16:24] <asac> so with this change you can build against glx and run with egl lib ;)
[16:25] <kenvandine> seb128, yeah, will do
[16:25] <pochu> asac: dh7 -> I'd rather stay with CDBS, the latest versions have support to build different flavours quite easily, but I can probably handle that when merging the changes if you don't want to do it
[16:25] <asac> but still. alf will submit it
[16:25] <seb128> kenvandine, thanks
[16:25] <asac> pochu: we need a two run build which is awful with cdbs in my way. if you want to stick i would be really happy if you could implement it there ;)
[16:25] <pochu> ok, np
[16:25] <asac> if you say latest cdbs is better, then go for it ;)
[16:26] <asac> how is that done now?
[16:26] <asac> pochu: i assume you also dont need the control.in fix for dh7 then? ;) ... can you copy the rest of control file over to the control.in ?
[16:26] <pochu> asac: sure
[16:26] <alf__> asac: actually, we need a three run build ;)
[16:27] <asac> alf__: heh :)
[16:27] <asac> or that
[16:30] <alf__> asac, pochu: I will submit the eglx_texture_pixmap.patch on Monday because I want to prepare both a 1.2 and 1.3 version (as I did with the previous patch)
[16:30] <pochu> shouldn't these patches go upstream too? fix_gles1_detection.patch, fix_motion_events.patch, fix_po_makefile_out_of_tree_build.patch, fix_SIGSEGV_clutter_stage_has_full_redraw_queued.patch, remove_gl_dep_for_gles.patch
[16:30] <asac> alf__: i think just 1.3 is enough ... noone will pick things like that for 1.2 i guess upstream. but since we have that already we can do that
[16:31] <pochu> also I'm not sure I get the point of x11-unified.patch
[16:31] <asac> pochu: yes, if they still apply for 1.3
[16:31] <asac> pochu: thats most likely soname hacking. we want to use the same soname for the eglx build
[16:31] <asac> but i havent looked ... so i might be wrong ;)
[16:31] <pochu> it's stuff like
[16:31] <pochu> +-libclutter_@CLUTTER_WINSYS@_@CLUTTER_API_VERSION@_la_LIBADD = \
[16:31] <alf__> asac: you are correct
[16:31] <pochu> ++libclutter_glx_@CLUTTER_API_VERSION@_la_LIBADD = \
[16:32] <asac> alf__: why is WINSYS replaced by a fixed glx?
[16:32] <asac> ah now i see
[16:32] <alf__> pochu: to force the soname
[16:33] <alf__> asac: ^
[16:33] <asac> right.
[16:33] <pochu> why would you do that?
[16:33] <asac> pochu: so you can drop in replace
[16:33] <pochu> didn't you say you have compatibility symlinks for that?
[16:33] <pochu> though it makes sense now anyway
[16:33] <asac> right. but in this way you can also build against that
[16:33] <asac> and still flip back ;)
[16:34] <asac> otherwise you always have to painfully switch to the real glx package to compile
[16:34] <pochu> ah right
[16:34] <asac> and then switch back
[16:35] <pochu> ok
[16:35] <asac> alf__: you should check what makes sense to upstream for 1.2 from the patches above though
[16:35] <pochu> maybe it would be better to just remove CLUTTER_WINSYS, without adding _glx_ ?
[16:36] <asac> pochu: that would change the upstream soname
[16:36] <pochu> so you have libclutter-1.0.so everywhere
[16:36] <asac> which we felt would have been quite a bold step if we do that in ubuntu
[16:36] <asac> sure. i think that would be the right step upstream
[16:36] <asac> but i dont think we should make our glx SONAME incompatible with the rest of the world
[16:37] <asac> upstream should do that next time they break abi
[16:37] <pochu> oh, right
[16:37] <asac> and then maybe have supplementary libs for just egl/glx funcs with a shared and useful api in that libclutter...so
[16:38] <asac> but upstream didnt reply to that suggestion a while back ;)
[16:38] <pochu> file a bug :)
[16:38] <asac> so we adapted to try the best we can do downstream ;)
[16:38] <asac> yeah
[16:38] <alf__> pochu: one note, the fix_motion_events.patch fix_SIGSEGV_clutter_stage_has_full_redraw_queued.patch are not currently used (not in series)
[16:38] <asac> i think we should use the x11-unified.patch to trigger this discussion
[16:38] <pochu> I guess so, it feels awkward we need such a hack to have the different builds compatible
[16:39] <asac> e.g. file a bug to take that for 1.3 ... and then they probably dont like it and then suggest the right approach and ask for help to implement that ;)
[16:39] <didrocks> alf__: fix_motion_events should be used
[16:39] <didrocks> alf__: let me check
[16:39] <pochu> asac: yup
[16:39] <alf__> pochu: i just forgot to remove the files. they were superseeded by 01_speed_current_position_detection.patch
[16:39] <didrocks> same for fix_SIGSEGV_clutter_stage_has_full_redraw_queued.patch
[16:39] <didrocks> pochu: those are upstreamaed btw ^
[16:39] <didrocks> pochu: no reply on the patch
[16:40] <pochu> didrocks: bug# ?
[16:40] <didrocks> pochu: let me ask to Jason, he most of the time file the bug upstream after I apply them to ubuntu, hence the lack of reference
[16:41] <alf__> didrocks: debian/patches/01_fix_motion_events.patch, 02__fix_SIGSEGV_clutter_stage_has_full_redraw_queued.patch: removed, included in 01_speed_current_position_detection.patch
[16:41] <didrocks> hum, he is not there today
[16:41] <didrocks> alf__: right
[16:41] <didrocks> alf__: on the current version in maverick (and no quilt, so no debian/patches/series)
[16:42] <didrocks> pochu: I'll get back to you ASAP Jason answered me, but I told Jason to file them upstream (what he has at least for the two previous 01_fix… and 02_fix…) not sure about the latest one because I didn't check
[16:43] <didrocks> I know he spoke about it with upstream at least (it's a huge speed improvment)
[16:43] <pochu> didrocks: ok, let me know about it
[16:44] <pochu> JFYI, I'm OK with shipping patches that make sense and are not committed upstream, but I want them to at least be forwarded
[16:44] <didrocks> pochu: note that I'll be on vacation next two weeks, so that can take time. I would say, if you want to take something in the meantime, you can discard that patch: no API or anything added IIRC
[16:44] <asac> right. i understand ... and it makes sense to push them there at least
[16:44] <didrocks> pochu: they are, just need to find the reference :)
[16:46] <pochu> didrocks:
[16:46] <pochu> +  * debian/*.symbols:
[16:46] <pochu> +    - Add symbols introduced by 01_speed_current_position_detection.patch.
[16:46] <pochu> so it seems it adds API...
[16:46] <didrocks> pochu: ok, I didn't remember that sorry, too old now :)
[16:46] <pochu> I've done a quick look on bugzilla.c-p, no luck, but that's probably my fault for not using the right search terms ;)
[16:47] <didrocks> pochu: let me have a look
[16:47] <seb128> chrisccoulson: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-chromium
[16:47] <seb128> I think the new documentation system will be delayed to next cycle for GNOME3
[16:48] <seb128> so you can probably postpone that work item
[16:49] <seb128> RAOF, https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-maverick-xorg-in-mm, should the remaining alpha3 items be closed or moved to beta?
[16:49] <pochu> I have to go now, bbl
[16:49] <seb128> RAOF, (letting that in backlog for next week)
[16:53] <seb128> Riddell, do you have some minutes for NEW reviewing?
[16:53] <seb128> Riddell, i've some stuff to finish and I'm running late
[16:53] <didrocks> pochu: http://bugzilla.clutter-project.org/show_bug.cgi?id=2237
[16:53] <ubot2> bugzilla.clutter-project.org bug 2237 in General "[PATCH] Optional picking mode which does not utilize glReadPixels" [Enhancement,New]
[16:53] <Riddell> seb128: what's needed?
[16:53] <didrocks> pochu: it is so :)
[16:54] <seb128> didrocks, can you tell Riddell what is still in new that you uploaded?
[16:54] <didrocks> Riddell: seb128: let me have a look. I think there is at leat utouch
[16:54] <didrocks> least*
[16:55] <seb128> Riddell, that's a dummy one to install other things should be easy to review ;-)
[16:55] <seb128> Riddell, can you bin NEW the other touch ones?
[16:55] <seb128> Riddell, thanks a lot
[16:55] <Riddell> ok
[16:55]  * seb128 hugs Riddell
[16:56]  * seb128 goes to finish release status update before having to run out
[17:00] <didrocks> Riddell: there is also utouch-geis for your great pleasure ;)
[17:03] <mpt> mvo, hi, did you get the FFe?
[17:13] <didrocks> Riddell: thanks :)
[17:21] <devildante> hi mpt :)
[17:21] <mpt> hi
[17:22] <mpt> devildante, are you fixing the FIXMEs? :-)
[17:23] <devildante> kiwinote made me a list here: http://paste.ubuntu.com/477481/ :p
[17:24] <chrisccoulson> seb128 - yeah, i'll postpone that one. thanks
[17:30] <seb128> chrisccoulson: thanks
[17:44] <mpt> devildante, good good. mvo's on holiday next week, but you get those fixed early we could line up some other reviews on the merge proposal
[18:13] <devildante> mpt: okay :)
[18:27] <didrocks> Riddell: can you bin new utouch, please? :)
[18:27] <Riddell> jdstrand is doing New.  it's his archive day
[18:28] <didrocks> oh ok, thanks :)
[18:37] <devildante> mpt: meh, there's an outstanding bug
[18:37] <mpt> ?
[18:38]  * mpt wonders how it's possible for software-center.pot to be the only file containing a particular string
[18:40] <devildante> mpt: when clicking on an add-on pkgname, it shows up, but there's no way to return to the original app
[18:41] <mpt> devildante, because Back goes to the wrong place?
[18:41] <devildante> mpt: yes, it returns at "Get software"
[18:42] <mpt> mhm
[18:42] <devildante> mpt: I tried to fix this, but for now, I didn't find a solution :(
[18:42] <devildante> mpt: if this persists, we'll have to disable clicking of pkgnames
[18:42] <mpt> devildante, that's something tremolux (Gary Lasker) would need to fix, I think. He knows the Back/Forward code.
[18:43] <devildante> mpt: so I can just leave it as-is until tremolux fixes it?
[18:43] <mpt> devildante, I guess you'd better disable the links until then. He won't be working next week either.
[18:43] <devildante> mpt: okay
[18:44] <mpt> I'm going home now, ttyl
[18:44] <mpt> thanks again for your work
[18:44] <devildante> argh, too late for a goodbye :p
[18:53]  * didrocks waves goodbye and see you in two weeks!
[18:54] <devildante> kiwinote: selecting an add-on is now snappier than ever ;)
[18:55] <kiwinote> devildante: great!
[18:55] <devildante> kiwinote: and the cancel button works :)
[18:55] <mvo> devildante: nice, what did you do to make it faster?
[18:56] <devildante> put update_totalsize() into a gobject.idle_add
[18:56] <mvo> devildante: nice
[18:57] <devildante> mvo: I also wanted to put set_addons() into a thread, but it causes problem when going to another app
[18:57] <devildante> kiwinote: I can't reproduce the firefox details crash
[18:59] <kiwinote> devildante: you may have fixed it in your current revision, I'm still running the last one you pushed
[18:59] <vish> looks like everyone is going on a vacation leaving seb128 all alone to have fun ;)
[18:59] <devildante> kiwinote: I pushed my latest rev, go test it :)
[18:59] <devildante> I mean I'll push it :p
[19:00] <kiwinote> devildante: hehe, will do, once lp has updated
[19:00] <devildante> vish: can I have fun too? :p
[19:00] <vish> heh..
[19:00] <devildante> kiwinote: pushed :)
[19:01] <vish> hrm , why dont i get a stack for this gdb! :(
[19:01] <devildante> mvo: did the build-dep issue get fixed?
[19:01] <mvo> devildante: yes, just uploaded the fix (10min ago)
[19:01] <devildante> mvo: is it in maverick now?
[19:02] <mvo> yes
[19:02] <mvo> devildante: probably not build yet
[19:02] <mvo> devildante: but uploaded
[19:02] <devildante> mvo: okay :)
[19:03] <devildante> hmm, seems that debian bug watches aren't working
[19:08] <kiwinote> devildante: you can change line 815 of details_gtk to "if not icon or not icons.has_icon(icon):"
[19:08] <devildante> kiwinote: nice catch, thanks :)
[19:08] <kiwinote> devildante: an app_details object returns none if it has no icon
[19:09] <devildante> kiwinote: yeah
[19:09] <devildante> kiwinote: oh, and good work on .deb handling :)
[19:09] <mvo> kiwinote, devildante: you guys rock! really cool to see this buzz :)
[19:09] <mvo> I will miss the fun of looking for nice new branches in the week I'm away
[19:09] <devildante> mvo: just make sure we don't go on vacation ;)
[19:10] <kiwinote> mvo: all the more fun when you get back ;)
[19:10] <devildante> mvo: is there someone who will replace you? (so I can bug him with fixes :p)
[19:11] <vish_> hmm , what am i doing wrong? http://pastebin.com/ZQjzavPS there is no stack for this unity crash.. bah..! no didrocks :(
[19:11] <mvo> devildante: usually its tremolux, but he is away as well
[19:11] <mvo> devildante: just bug kiwinote ;)
[19:12] <kiwinote> hehe
[19:12] <devildante> mvo: thanks for the info
[19:12] <devildante> now I can do "kiwinote: ping pang pong" :p
[19:12] <mvo> heh :)
[19:14]  * mvo is afk again for a little bit
[19:26] <Sarvatt> vish_: looks like you're using a GPU without NPOT support?
[19:28] <vish_> Sarvatt: hmm , not sure what that means , i was testing unity ppa but it kept crashing and didrocks wanted a gdb from a live cd.. so ran the gdb
[19:29] <vish_> Sarvatt: mutter works fine , only unity keeps crashing
[19:32] <vish_> Sarvatt: its an ATI X1400, iirc its an rv515 /
[19:33] <devildante> kiwinote: do you know the exact color for the "Version", "License"... labels?
[19:34] <kiwinote> devildante: in the details_gtk file there is a class for a infotable
[19:34] <Sarvatt> the invalid value error is probably from it trying to use a texture thats not power of two sized and its just hanging instead of crashing, i can't  use unity on intel either at the moment because of a bad renderbuffer format error
[19:34] <devildante> kiwinote: yeah, I copied the "dark" color, but it's not applied correctly on the "Total size" label
[19:35] <kiwinote> devildante: hm, let me look
[19:36] <vish_> Sarvatt: so we just need to wait for better drivers ?   :)
[19:36] <Sarvatt> vish_: install the clutk debug package and break on ctk_render_target_resize and check out the dimensions
[19:37]  * devildante will be afk for an hour or two, just leave a message
[19:38] <vish_> Sarvatt: but that doesnt allow me to install: "  libclutk-0.3-0-dbgsym:   Depends: libclutk-0.3-0 (=0.3.48-0ubuntu1) but 0.3.50-0ubuntu2 is to be installed"  :(
[19:40] <vish_> oh , wait there is another dbg package!
[19:41]  * devildante is no longer afk :p
[19:54] <kiwinote> devildante: it seems to be that the self.style object is different. The correct one returns <__main__.MurrineStyle object at 0x2d0f6e0 (MurrineStyle at 0x2ee6e30)>, the 'wrong' one returns <gtk.Style object at 0x3871280 (GtkStyle at 0x2c62020)>
[19:55] <kiwinote> devildante: it probably has to do with that the correct one is set on the 'realize' signal, and the 'wrong' one is set straight away
[19:56] <kiwinote> devildante: but that would need investigation.. ;)
[20:14] <kiwinote> devildante: anyway, I'm off now. Have fun ;)
[20:22] <Sarvatt> before i dig into the bugs does anyone know if there are known issues? every software-center upgrade gives a huge spam of - WARNING:softwarecenter.db.update:error processing: /usr/share/app-install/desktop/ubuntu-restricted-extras.desktop 'catalogedtime' and using add-apt-repository gives a spam of .save extensions being invalid for files in /etc/apt/sources.list.d/?
[20:36] <Sarvatt> vish_: I can reproduce that crash with MESA_EXTENSION_OVERRIDE=-GL_ARB_texture_non_power_of_two unity
[20:36] <Sarvatt> oops he isn't in here
[20:39] <Sarvatt> shouldn't unity detect if GL_ARB_texture_non_power_of_two is available and not run before trying to use it?
[20:47] <Sarvatt> vish_: there are probably tons  of bugs with the same problem already if its broken on all <= r500 radeons
[20:49] <vish_> Sarvatt: yeah.. there are a lot of people saying unity doesnt start and they have the same symptoms , but didrocks mentioned that they didnt really know what was the exact cause
[20:49] <vish_> one problem was the gnome-panel systray conflit
[20:51] <Sarvatt> unconditionally using NPOT textures when its not supported is why
[20:51] <vish_> then a few other the problemwas solved using export CLUTTER_VBLANK=none
[20:52] <Sarvatt> did you see if you had GL_ARB_texture_non_power_of_two advertised in glxinfo?
[20:52] <Sarvatt> (enable universe and install mesa-utils on that livecd)
[20:52] <vish_> yeah doing that now..
[20:53] <vish_> doh! i had already checked it : http://paste.ubuntu.com/476865/
[20:53] <vish_> thats the glxinfo^
[20:54] <Sarvatt> oh dang not even advertised?
[20:54] <vish_> totally forgot that i had pasted the glxinfo yesterday :D!
[20:57] <vish_> Sarvatt: with the latest mesa,Mesa 7.8.2 : http://paste.ubuntu.com/477605/
[20:57] <Sarvatt> any difference if you run MESA_EXTENSION_OVERRIDE=GL_ARB_texture_non_power_of_two unity
[20:57]  * vish_ tries
[20:59] <Sarvatt> if r300 from xorg-edgers doesn't work it looks like its going to need r300g to run unity on r300-r500 :(
[21:00] <vish_> oh! i saw a hint of unity and it disapeared!
[21:00] <vish_> using the override..
[21:01] <Sarvatt> yeah try edgers for sure, if that does work you can use Option "Gallium" "True" with edgers to make it work with r300g. switching to r300g by default was a goal for maverick but r300g in mesa 7.8.x isn't good enough
[21:03] <vish_> http://paste.ubuntu.com/477608/ when i tried ~$ MESA_EXTENSION_OVERRIDE=GL_ARB_texture_non_power_of_two mutter --replace --mutter-plugins=libunity-mutter
[21:03]  * vish_ installs edgers
[21:03] <Sarvatt> 7.9 is very different than 7.8.x, glxinfo/glxgears needs to be packaged seperately and all of the egl/opengles/openvg stuff is very different so it didn't get packaged yet. they didn't release it on schedule and are waiting to add more features and it wont be released until october so its risky :(
[21:12] <devildante> vish_: got time?
[21:12] <vish_> hmm! october..! :(
[21:12] <vish_> devildante: heh , i'm still sctatching my head or unity :D
[21:12] <vish_> s/or/over
[21:13] <devildante> vish_: okay, just ping me when you're finished :)
[21:13] <vish_> devildante: sure..
[21:14] <vish_> Sarvatt: restarting X should be sufficeint right, to use the edgers update?  where/when do i set the "Gallium" "True" option ?
[21:15] <Sarvatt> yup
[21:16] <Sarvatt> try without the gallium too though to see if the normal r300 dri driver works if ya can
[21:17] <vish_> ok..
[21:17]  * vish_ re-starting x
[22:35] <vish> Sarvatt: around? with the -edgers the problem is even worse , mutter too [which works with the daily] just hangs and i can see nothing but the wallpaper : http://paste.ubuntu.com/477636/
[22:36] <devildante> vish: still having problems? :p
[22:36] <vish> Sarvatt: unity segfaults : http://paste.ubuntu.com/477637/
[22:36] <vish> devildante: yup , the fun kind ;)
[22:37] <devildante> vish: about bug 399591 (which you reported), is there still time so I can work on it?
[22:37] <ubot2> Launchpad bug 399591 in update-notifier (Ubuntu) (and 1 other project) "Rename Update-notifier > update-manager-daemon (affects: 4) (heat: 21)" [Undecided,Confirmed] https://launchpad.net/bugs/399591
[22:38] <vish> devildante: yup , thats not affected by FF, its just a renaming
[22:38] <devildante> vish: can I work on it?
[22:38] <vish> devildante: sure..
[22:38] <devildante> vish: thanks :)
[22:39] <vish> devildante: thanks :) ,
[22:39] <devildante> vish: np
[22:39] <vish> devildante: oh wow! thats exactly 1yr since me and mpt discussed about it! :D
[22:39] <devildante> vish: yeah :P
[22:41] <vish> Sarvatt: how do i try the Gallium option?
[22:41]  * vish not really comfortable with webcaht! ;)  needs to boot back to xchat :D
[22:56] <Sarvatt> vish: http://paste.ubuntu.com/477646/ -- make that your /etc/X11/xorg.conf
[22:57] <vish> Sarvatt: cool! , thanks! :)
[23:06]  * vish tires again...
[23:08] <devildante> vish: you are tired again? :p
[23:25] <vish> Sarvatt: that dint help either :(  : http://paste.ubuntu.com/477654/ , unity just freezes..
[23:25]  * vish brb , re-booting 
[23:32]  * vish re..
[23:38] <bdrung> the ubuntu-desktop team needs to improve in regard of sponsoring. there are 18 sponsor request for ubuntu-desktop packages.
[23:38] <bdrung> source: http://qa.ubuntu.com/reports/sponsoring/