[00:57] <TheMuso> robert_ancell: DId pygtk get sponsored from yesterday for you? if not, I'll take care of it.
[00:59] <robert_ancell> TheMuso, hasn't been sponsored, thanks
[00:59] <TheMuso> robert_ancell: ok
[01:37] <TheMuso> robert_ancell: uploaded
[01:37] <robert_ancell> TheMuso, thanks
[01:46] <robert_ancell> Does anyone know how the the /usr/share/gnome/wm-properties/*.desktop files work? RAOF perhaps?
[01:47] <RAOF> Not I, said the RAOF.
[01:48] <TheMuso> Sorry no idea.
[06:50] <robert_ancell> Amaranth, ping
[06:50] <Amaranth> robert_ancell: pong
[06:51] <robert_ancell> Amaranth, hey, I've been merging the compiz packaging with the Debian package, but the one problem I have is when I start compiz the decorator doesn't start.  Any ideas where to look for problems?
[06:51] <Amaranth> robert_ancell: If you're not using the wrapper you need to modify the default settings to put something in the decorator plugin to start
[06:52] <Amaranth> The plugin has an option to run a command to start a decorator if it doesn't detect one running already
[06:52] <robert_ancell> Amaranth, I am using the wrapper (it should work as it did before, I
[06:52] <robert_ancell> 'm just not sure what I've broken)
[06:53] <Amaranth> oh, hmm
[06:53] <Amaranth> Wait, you're giving up the startup gain and going back to the wrapper?
[06:54] <robert_ancell> oh, no, I meant I was using the decorator wrapper
[06:54] <robert_ancell> I've just pushed the changes to lp:~ubuntu-desktop/compiz/ubuntu if you want to look
[06:57] <Amaranth> I actually just pointed the debian maintainer to my 0.9 package recently as well, I have a feeling you porting to their package and them (possibly) porting some of the way to mine is going to make more work for everyone
[06:57] <Amaranth> But for the decorator you should make it log something so you can see what it is doing, I guess
[06:58] <Amaranth> I'm actually not booted in to Ubuntu right now since I needed an app for webOS development so I can't test the packaing
[06:58] <robert_ancell> Amaranth, oh, you have 0.9 packages ready?  I'm hoping by porting to the debian package it will be easier to use their changes
[06:59] <Amaranth> robert_ancell: Yeah, I did core and libcompizconfig packages, https://code.edge.launchpad.net/~amaranth
[07:00] <Amaranth> The debian maintainer was looking in to use git submodules to package core and the plugin packs together so we don't have to worry about them getting out of sync so I think he is going to basically redo the packaging
[07:00] <Amaranth> Hopefully he does it somewhat like I have already
[07:01] <robert_ancell> right
[07:02] <Amaranth> Also we already have bzr branches for compiz packages. If you move them to ~ubuntu-desktop I can't commit
[07:06] <robert_ancell> Amaranth, right, I'll move them back
[07:15] <robert_ancell> Amaranth, oh, that was a typo, I just did a push and they went to the right place anyway
[07:15] <Amaranth> hehe
[07:19] <Amaranth> robert_ancell: Hrm, the whole reason I didn't want to merge with Debian was compiz-gtk
[07:19] <Amaranth> I got rid of it after a few people complained that we didn't ship a gtk-window-decorator without GNOME dependencies
[07:19] <Amaranth> (which we can't do without configuring and building compiz twice)
[07:20] <robert_ancell> Amaranth, oh, so that is a change worth keeping?
[07:21] <robert_ancell> What is Debian planning on doing?
[07:21] <Amaranth> I dunno, I haven't been able to have much communication with them
[07:21] <Amaranth> Been rather busy working and trying to make apps for my new phone :)
[07:21] <robert_ancell> I figured it was a useful package for non-gnome distros, e.g. xfce
[07:26] <Amaranth> robert_ancell: It would be if we actually made it
[07:26] <Amaranth> But compiz-gtk just contains gtk-window-decorator which in our build almost literally depends on every part of GNOME
[07:44] <robert_ancell> Amaranth, do you have compiz upload privileges?
[07:45] <Amaranth> robert_ancell: Yeah but I wouldn't be able to upload until tomorrow
[07:45] <Amaranth> About to head for bed, it's almost 2am
[07:45] <robert_ancell> Amaranth, np, I can't upload, but if you're happy to I'd like you to look over the changes in bzr and upload them if you're happy with them
[07:45] <robert_ancell> (no rush)
[07:47]  * TheMuso sighs with relief.
[07:47] <robert_ancell> TheMuso, good news?
[07:47] <TheMuso> Thats one package I'd rather not touch.
[07:47] <robert_ancell> hehe
[08:02] <didrocks> good morning
[08:28] <pitti> Good morning
[08:28] <seb128> hey pitti
[08:29] <pitti> bonjour seb128
[08:32] <didrocks> good morning pitti, seb128
[08:32] <seb128> lut didrocks
[08:32] <pitti> hey didrocks!
[08:32]  * pitti looks at NEW, sees that it's 520 entries long, and cleans up a bit
[08:37] <seb128> urg
[08:38] <seb128> pitti, it's for sure coming from de debian sync run?
[08:38] <pitti> certainlz
[08:38] <seb128> lol
[08:38] <pitti> I'm running new-binary-debian-universe
[08:38] <seb128> pitti, thanks for cleaning ;-)
[08:38] <pitti> sorry, accidentally had German keyboard layout enabled :)
[08:50] <baptistemm> heya
[08:50] <seb128> lut baptistemm
[08:53] <baptistemm> salut seb128
[08:57] <didrocks> salut baptistemm
[08:58] <baptistemm> salut didrocks
[08:59] <seb128> I guess we will not get a new gdm version in lucid
[08:59] <seb128> jmccann seems to not have the same notion of stable serie as we have
[09:00] <seb128> he backported a zillion trunk change to stable
[09:00] <seb128> lot of those not being really needed in a stable, ie code refactoring
[09:00] <robert_ancell> pitti, are your sane-backends udev changes still applicable?
[09:00] <seb128> robert_ancell, hey
[09:00] <seb128> robert_ancell, you might want to send our changes to the debian bts when we have only small depends etc changes
[09:00] <pitti> robert_ancell: good morning
[09:00] <pitti> robert_ancell: the ones from 1.0.20-13ubuntu1 ?
[09:01] <robert_ancell> pitti, yes
[09:01] <seb128> robert_ancell, I noticed on some of the merges you did the diff could almost be dropped or easily included in debian
[09:01] <pitti> robert_ancell: yes, they look fine
[09:01] <robert_ancell> seb128, yeah, I've been opening a bunch of bugs against debian
[09:01] <pitti> I wonder why Debian doesn't switch over to the current udev world
[09:01] <seb128> robert_ancell, excellent ;-)
[09:01] <robert_ancell> I don't have much hope they'll be taken though :)
[09:02] <robert_ancell> pitti, that was what I was going to ask!
[09:03] <robert_ancell> Debian needs a GnomeGoal type projects to unify a lot of things...
[09:05] <didrocks> seb128: there are some XDMCP fixes that can be interested to take, maybe?
[09:07] <seb128> didrocks, I've a bunch of commits in my backport queue yes
[09:07] <seb128> didrocks, I'm just saying it will be difficult to update the version
[09:07] <seb128> didrocks, ie we should rather backport fixes we want
[09:08] <didrocks> seb128: right, cherry picking is harder for maintainance, but it's clearly safer in that case
[09:08] <seb128> didrocks, well seeing the number of commits...
[09:08] <seb128> we already rolled back from 2.30.2 due to new bugs
[09:09] <seb128> I've little confidence in the new hundred commits to not have new bugs
[09:09] <didrocks> yeah, it's the right decision :)
[09:09] <seb128> especially that they did some refactoring and changes in the user loading and greater animations codes
[09:09] <didrocks> I was just hilighting the XDMCP fix (some discussion on gdm ML)
[09:10] <didrocks> urgh? that's risky…
[09:11] <seb128> didrocks, see http://git.gnome.org/browse/gdm/log/?h=gnome-2-30 commits
[09:11] <seb128> especially the serie 6 days ago there
[09:12] <didrocks> seb128: yeah, I was just looking at it, that's crazy for a stable release…
[09:12] <seb128> it goes over 2 screens
[09:13] <didrocks> so gdm 2.30.2 for maverick and cherrypicking for lucid?
[09:13] <seb128> right
[09:13] <seb128> that's what we have now
[09:14] <seb128> on the nice side if means we will get lot of those fixes in the 2.30 update
[09:14] <seb128> ie we will get the change without having to take the GNOME3 version
[09:14] <didrocks> right :)
[09:20] <didrocks> ok, so I can switch between the two banshee interfaces reliably now, choose which interface to start, and add a button to main interface only if the netbook interface is installed \o/
[09:37] <robert_ancell> seb128, pitti, can one of you have a look at sponsoring sane-backends?
[09:41] <seb128> didrocks, great work
[09:41] <didrocks> seb128: thanks :)
[09:41] <seb128> didrocks, ^ can you do robert_ancell sponsoring?
[09:41] <seb128> I'm on SRU mode for now
[09:41] <didrocks> seb128: do, you know where is his branch? ~ubuntu-desktop?
[09:42] <didrocks> no, it's not
[09:42] <seb128> didrocks, let me check
[09:43] <seb128> didrocks, lp:~ubuntu-desktop/sane-backends/ubuntu
[09:43] <seb128> didrocks, seems it is?
[09:44] <seb128> didrocks, it changed 19 minutes ago it seems
[09:44] <didrocks> yeah, missing the final s probably :)
[09:44] <didrocks> launchpad it great for having a view on it
[09:44] <didrocks> ok, doing it
[09:44] <seb128> thanks
[09:45] <seb128> pitti, do you think we could move gdm in updates with 3 bugs confirmed fixed on 5?
[09:45] <seb128> pitti, if I get somebody to ack that gdm still works on the other 2 bugs?
[09:45] <pitti> it seems to work fine here, anyway, and it should avoid the new crash
[09:45] <pitti> seb128: sounds fine
[09:45] <seb128> pitti, I would like to move to another round of fixes backport
[09:45] <seb128> pitti, thanks
[09:46] <pitti> seb128: the .Xresources stuff is easy enough to test, I believe I added test cases
[09:47] <seb128> pitti, bug #586503 will fail verification
[09:47] <ubot2> Launchpad bug 586503 in gdm (Ubuntu Lucid) (and 2 other projects) "/etc/gdm/PostLogin/Default file not run if automatic login is enabled (affects: 1) (heat: 10)" [Low,Fix committed] https://launchpad.net/bugs/586503
[09:47] <seb128> it fixes the Init script use not the PostLogin ones
[09:47] <seb128> it's not a regression but fixes a similar case not the bug one
[09:47] <pitti> ah, ok; so we'd leave that open
[09:47] <seb128> bug #518810 is similar to one of the fixes verified
[09:47] <ubot2> Launchpad bug 518810 in gdm (Ubuntu Lucid) (and 2 other projects) "gdm monitors for $HOME/.face even when IncludeAll is false (affects: 1) (heat: 14)" [Low,Fix committed] https://launchpad.net/bugs/518810
[09:48] <seb128> it's the one robert_ancell fixed
[09:48] <seb128> EtienneG confirmed the updated version fixes their issue
[10:00] <Sarvatt> \o/ http://cgit.freedesktop.org/cairo/commit/?id=7a023a62f7517ad0d54f4d59c99909fadcc05e82
[10:07] <slomo> pitti: ping? :)
[10:07] <pitti> hello slomo
[10:13] <seb128> Sarvatt, well done!
[10:16] <Sarvatt> woohoo so gtk app x errors go to the gdm log again now? thats been a big pet peeve of mine since it changed to have x's stdout/stderr and only had the log
[10:19] <RAOF> Sarvatt: Rock on!
[10:19] <RAOF> Hm.  That “amd64 users, don't update due to broken initramfs-tools” would have been much more useful if I'd read it about 15 minutes ago :)
[10:20] <hyperair> now don't reboot =p
[10:20] <RAOF> Yah.
[10:20] <seb128> is that still an issue?
[10:20] <seb128> the fix has been uploaded 15 hours ago
[10:20] <seb128> it built 7 hours ago and should be published for a while
[10:21] <Sarvatt> i got a crapload of errors when i updated i386 earlier but they were for a kernel i dont have installed anymore, hope its not a problem :D
[10:21] <RAOF> ubuntu4 is fixed?
[10:21] <seb128> yes
[10:21] <seb128> ubuntu3 was the buggy one
[10:22] <RAOF> Failing to call dh_install seems unlikely to result in a working package :)
[10:22] <seb128> if you want to check look if initramfs-tools-bin has binaries
[10:22] <seb128> if not you are in trouble ;-)
[10:23] <Sarvatt> wow is gdm 2.30 branch right? that looks like he pushed master to it a few days ago too :)
[10:23] <seb128> Sarvatt, see backlog
[10:23] <Sarvatt> yeah thats why i was looking at it
[10:23] <seb128> the redhat guys don't have the same opinion that us of what stable means it seems
[10:24] <Sarvatt> oh they do for RHEL
[10:24] <seb128> ok, the fedora guys don't ;-)
[10:24] <Sarvatt> yeah they like to break everyone else and do the stable stuff internally it seems :)
[10:24] <RAOF> Rollingish release for the strange.
[10:25] <seb128> Sarvatt, so where is your cairo update? want me to push it to the ubuntu-desktop ppa?
[10:26] <Sarvatt> really though it looks like that guy pushed master to 2.30 branch by mistake a few days ago and noone fixed it up
[10:27] <seb128> somebody raised it on their IRC channel
[10:27] <seb128> seems it's not an error
[10:28] <seb128> lot of those changes are required to get the new user account dialog fedora is using to work with gdm or something
[10:30] <Sarvatt> http://sarvatt.com/downloads/merges/cairo/ i'm still trying to track down why it breaks chrome/chromium though, it looks like it draws the icons on the tabs as a crapload of animated cursors digging into the trace
[10:30] <seb128> Sarvatt, thanks
[10:31] <Sarvatt> watch it be fixed when i restart into the non CSD gtk :)
[10:31] <seb128> Sarvatt, lol
[10:31] <seb128> chrisccoulson, hey
[10:32] <seb128> urg
[10:32] <chrisccoulson> hi seb128, how are you?
[10:32] <Sarvatt> chrisccoulson: ever heard of xtruss?
[10:33] <seb128> chrisccoulson, I'm fine thanks, how are you?
[10:33] <chrisccoulson> Sarvatt - i'd not heard of that until just now
[10:34] <chrisccoulson> seb128 - i'm good thanks
[10:34] <chrisccoulson> i think the karmic updates are ready to test now :)
[10:34] <Sarvatt> you got me hooked on xtrace and i found this other project that has a ton more options but it's lacking a bunch of protocols, i've been updating them here - http://sarvatt.com/git/cgit.cgi/xtruss/log/?h=working
[10:34] <chrisccoulson> i fixed a couple of upgrade issues last night
[10:34] <chrisccoulson> Sarvatt - that looks interesting
[10:34] <Sarvatt> like you can hook into an existing window ala xwininfo, or launch an app as an arguement
[11:03] <chrisccoulson> hi ara, do you want to send out a call for testing karmic this morning?
[11:03] <ara> chrisccoulson, sure, it is everything in place in your PPA?
[11:04] <ara> mozilla's ppa, sorry
[11:05] <chrisccoulson> yeah, everything is in there now with the exception of any xulrunner rdepends (we don't need those just yet for karmic, so i will port those once I have jaunty ready)
[11:06] <ara> chrisccoulson, OK, I will prepare the tracker and the call and will send it out in the next hour
[11:06] <chrisccoulson> ara - excellent, thanks
[11:07] <ara> chrisccoulson, do you want me to hide Hardy on the tracker to avoid confusion? is the hardy testing done? are you happy with it? or you prefer to keep it active just in case someone wants to test it as well?
[11:07] <chrisccoulson> i think we should keep it active for now
[11:08] <ara> OK
[11:08] <Sarvatt> hah! the chrome/chromium issues I was having *were* caused by the CSD stuff
[11:09] <chrisccoulson> ara - we should probably reiterate too that there are still quite a lot of applications on https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list which need testing for hardy
[11:09] <Sarvatt> so much for that 6 hours or so of debugging :)
[11:10] <chrisccoulson> i've been testing most of them myself, but i haven't had very much feedback on them
[11:10] <ara> chrisccoulson, ok
[11:24] <seb128> Sarvatt, ok, your cairo is in the ubuntu-desktop ppa now
[11:25] <seb128> Sarvatt, can you open a bug on launchpad about the chrome issue and tag it gtk-csd so it's tracked?
[11:33] <seb128> asac, ogra: hey
[11:33] <ogra> yes ?
[11:33] <seb128> asac, ogra: who cares about armel builds?
[11:34] <seb128> the gobject-introspection build failure impacts on other things
[11:34] <seb128> ie the telepathy stack is failing behind now
[11:34] <ogra> seb128, NCommander and me
[11:34] <seb128> I'm just raising it in case you do care for alpha2
[11:34] <seb128> ogra, https://edge.launchpad.net/ubuntu/+source/gobject-introspection/0.6.14-1ubuntu1
[11:34] <seb128> ogra, that makes telepathy-glib being outdated
[11:34] <seb128> which breaks telepathy-mission-control now
[11:35] <ogra> oh, wait, thats on dyfet's list+
[11:35] <seb128> ogra, ok, I'm just telling you it has impact on other components
[11:35] <seb128> you do what you want with the information ;-)
[11:39] <Sarvatt> seb128: I was wrong, you need to have a ton of tabs open to trigger it :(
[11:39] <asac> ok seems maverick will not produce images soon then ;)
[11:39] <Sarvatt> still getting it
[11:39] <asac> (armel)
[12:44] <seb128> slomo, there?
[12:44] <didrocks> slomo: hey, I'm having troubles in patching valac to build it (bootstrap issues)
[12:44] <seb128> slomo, there for a vala build question?
[12:50] <chrisccoulson> hmmm, i just set up my new network scanner, and simple-scan crashes when i try to scan from it :(
[13:07] <RAOF> Woo!  Compiz works pretty nicely as a WM for Unity.  I can have my <Super> key back!
[13:07] <didrocks> RAOF: you mean, you have mutter -> unity plugin and compiz ?
[13:09] <RAOF> didrocks: No, just Compiz.  So unity's WM integration - presenting the windows on pressing the Ubuntu icon, presenting the app windows on right click of their icon - doesn't work.  But that's moderately well handled by existing compiz plugins anyway.
[13:12] <didrocks> RAOF: oh nice
[13:13] <RAOF> And I prefer compiz as a window manager :)
[13:31] <tseliot> RAOF: how did you do that? compiz --replace?
[13:31] <RAOF> tseliot: Yup.  Followed by running /usr/bin/unity
[13:31] <tseliot> ok
[13:42] <slomo> seb128, didrocks: yes?
[13:43] <Sarvatt> so are we going back to having a compiz wrapper again?
[13:43] <seb128> Sarvatt, no, why?
[13:43] <seb128> slomo, the changes are applied to the source
[13:43] <slomo> to the .vala files?
[13:43] <Sarvatt> i just read the scrollback from yesterday and robert_ancell talking about merging it from debian
[13:43] <seb128> slomo, or if you change a vapi it tries to call valac on build to update the .c
[13:43] <seb128> slomo, or valac is not available, at least not in the first build
[13:43] <seb128> which is trying to build it for the second build
[13:44] <seb128> slomo, how do you solve this?
[13:44] <seb128> slomo, should changes be applied only to the normal build?
[13:44] <slomo> either that or patch the .c/.h files too
[13:44] <seb128> Sarvatt, right, merging means taking what debian has and applying our changes over that no?
[13:44] <Sarvatt> the wrapper has a plus side, gtk-window-decorator actually stops when you switch away from compiz with it, we could just leave the checks in compiz and make a minimal wrapper or something
[13:45] <seb128> slomo, we tried that but it triggers some valac call during the first build
[13:45] <seb128> slomo, the .vapi was before the .c in the patch so the timestamp should have been correct
[13:45] <slomo> seb128: gnar, AM_MAINTAINER_MODE :)
[13:45] <slomo> ok, only apply those changes to the builds after bootstrapping
[13:45] <seb128> ;-)
[13:45] <Sarvatt> or else make disabling effects in the capplet forcibly stop gtk-window-decorator
[13:46] <seb128> slomo, that's why I was thinking as well
[13:46] <seb128> didrocks, ^
[13:46] <slomo> seb128: not sure how to do that with the quilt source format though
[13:46] <slomo> you probably have to add a second patches directory and call quilt by hand
[13:46] <seb128> sabdfl, but Amaranth said the decorator should not do anything if compiz is not running
[13:46] <seb128> ups
[13:46] <seb128> sabdfl, sorry that was for Sarvatt
[13:47] <seb128> Sarvatt, ^
[13:47] <seb128> slomo, right, it's a bit hackish, other option is to build-depends on valac
[13:47] <seb128> slomo, now that vala is available I'm not sure how much of an issue that is ;-)
[13:47] <Sarvatt> one sec, let me trace it and see what its doing when its on after disabling compiz
[13:48] <slomo> seb128: that would be like gcc then, not too bad ;)
[13:48] <slomo> do you have 0.9.1 in ubuntu btw? or 0.8.1?
[13:48] <seb128> slomo, 0.9.1
[13:49] <slomo> ok
[13:54] <Sarvatt> its sure as heck not not doing anything - http://sarvatt.com/downloads/gtkdecorator.txt
[13:56] <seb128> we should fix that
[13:56] <seb128> but having a slow wrapper running at login is not the way to go
[14:02] <Sarvatt> just making it stop when effects are disabled in the appearance preferences would probably be the best bet, but i dont think the wrapper is that bad of an idea if the checks could be kept in compiz since those are what made it slow
[14:03] <Sarvatt> but right now its kind of sketchy, compiz starts and starts gtk-window-manager before the checks are done
[14:04] <Sarvatt> so if compiz fails its still running, and you get bug reports from people with crappy video like mga with the panel disappearing :)
[14:05] <Sarvatt> anyway with compiz 0.9 it wont really be a problem anymore since GL is optional
[14:10] <didrocks> seb128: slomo: ok, thanks :)
[14:11] <slomo> didrocks: please send me a diff with your changes or file a debian bug :)
[14:12] <didrocks> slomo: it's already in trunk and I guess you don't use dbus wrapper yet (it fixes that), do you think it worth patching it for you or wait for next upstream release?
[14:12] <didrocks> slomo: it's just that our dx team needs it, that's why we can't wait :)
[14:12] <Sarvatt> compiz is on life support in debian though, it hasn't really been updated outside of taking patches from ubuntu since october which is why we're on this old 0.8.4 still
[14:13] <seb128> didrocks, I guess he was saying that rather for the packaging changes we do
[14:13] <seb128> didrocks, not especially for the one diff we apply now to the code
[14:13] <slomo> yes
[14:14] <seb128> Sarvatt, there is a newer 0.8?
[14:14] <didrocks> seb128: yeah, I have to sent the LD_PRELOAD in debian/rules/ (not sure about how it work though), as its in "if ubuntu" already
[14:14] <slomo> didrocks: fwiw, i'd prefer to not b-d on valac but call quilt with a different patch directory ;)
[14:14] <Sarvatt> yeah 0.8.6 came out 3 months ago
[14:15] <slomo> didrocks: i'll include that patch with the next upload, i already wanted it in the last one but forgot about it :(
[14:19] <didrocks> slomo: do you understand what it does? I don't understand how "LD_PRELOAD= make check" call the testsuite not under fakeroot. The fakeroot is a library which is added as LD_PRELOAD for each call? (or it's just for this testsuite?)
[14:19] <didrocks> slomo: right now, I'm build-dep on vala, but next time we will have a patch needed for a vala file, I'll do a separate patch directory
[14:20] <slomo> didrocks: yes, fakeroot is a library added by LD_PRELOAD
[14:20] <didrocks> slomo: ok, that explains it so, thanks :)
[14:26] <seb128> didrocks, <didrocks> seb128: yeah, I have to sent the LD_PRELOAD
[14:26] <seb128> didrocks, the patch is waiting in the bts, I already pinged slomo about it but it seems he forgot to ship it in the update yesterday
[14:27] <didrocks> seb128: he just told me that above, I was surprized if didn't send that :)
[14:27] <didrocks> seb128: sorry for the wrong ping :)
[14:27] <seb128> np
[14:27] <slomo> seb128: yes, sorry... i remembered that there was a patch while dput was running :(
[14:27] <seb128> slomo, that's ok no hurry ;-)
[14:45] <didrocks> seb128: I'll probably have to ship some additional desktop files for evolution and banshee, launching them with different parameters for UNE, how do you want we handle that?
[14:46] <didrocks> I mean, UNE is a gnome session, so OnlyShowIn won't work
[14:46] <didrocks> dealing with applications.menu for not showing them in GNOME for instance (I don't like that idea)?
[14:47] <seb128> didrocks, is unity using gnome-menus?
[14:48] <didrocks> seb128: not sure about that, but I'm thinking about gnome first there
[14:48] <didrocks> seb128: if I had some .desktop file, they will show up
[14:48] <seb128> if you use GNOME you can have normal modes for those
[14:49] <seb128> well use desktop with NotShowIn=GNOME
[14:49] <didrocks> ok, if unity isn't going to use gnome-menus
[14:49] <seb128> well in any case standard launcher are optin
[14:49] <didrocks> njpatel_: btw, will you use gnome-menus for showing applications ? ^
[14:49] <seb128> they should probably display what they are asked to list
[14:49] <seb128> not respect ShowOnlyIn
[14:50] <didrocks> seb128: right, but it will be so "hide normal evolution and show evolution for UNE" in unity, doesn't sound good
[14:51] <njpatel_> didrocks, erm, probably
[14:51] <njpatel_> didrocks, actually, yes, we will
[14:51] <didrocks> njpatel_: ok, thanks :)
[14:51] <didrocks> so, that's an issue
[14:52] <njpatel_> heh, I just seem to cause issues these days :)
[14:52] <didrocks> njpatel: heh :-)
[14:53] <seb128> didrocks, I don't understand
[14:53] <didrocks> seb128: will it be unreasonable to hack gnome-menus to say "add UNE session and consider UNE derived from GNOME"
[14:53] <didrocks> well, consider evolution
[14:53] <seb128> didrocks, do you have a menu displayed?
[14:53] <seb128> I though you just listed some desktop names
[14:53] <seb128> you could list evolution-express.desktop
[14:53] <didrocks> seb128: I'm speaking about the places to launch applications
[14:53] <seb128> what is that?
[14:53] <seb128> I can't comment I've not seen that yet and I don't know how it works
[14:53] <didrocks> one sec
[14:54] <seb128> I guess you can have a new desktop value
[14:54] <seb128> like GNOME XFCE LXDE etc
[14:54] <didrocks> seb128: http://www.markshuttleworth.com/archives/383
[14:54] <seb128> and have NotShowIn=UNE
[14:54] <seb128> for normal evo
[14:54] <didrocks> 3rd mockup
[14:55] <seb128> and get UNE to respect it
[14:55] <didrocks> but is it possible to say the "UNE" is GNOME + UNE
[14:55] <didrocks> because I guess we want to take as well OnlyShowIn=GNOME
[14:55] <didrocks> and not patching the whole world
[14:55] <seb128> it's not the world
[14:56] <seb128> it's only your launcher that need to get the UNE variants no?
[14:56] <didrocks> the launcher needs to show UNE and GNOME variants
[14:56] <didrocks> (I don't know the gnome-menus API, can you say "show me UNE and GNOME" or is it internal?)
[14:57] <seb128> seems there is no clear way to solve what you try to do
[14:57] <seb128> you say you have 2 GNOME sessions
[14:57] <seb128> they both are GNOME
[14:57] <seb128> and they should display different things
[14:57] <didrocks> right, that's the issue
[14:57] <seb128> I need to think about it
[14:57] <seb128> I don't see a clean way to do it right now
[14:58] <didrocks> apart from patching gnome-menus, which should be doable, I don't see with what I know from GNOME. That's why I prefer some brainstorming on it first. No hurry though :)
[14:59] <seb128> I'm still unsure why you can't have both listed
[14:59] <seb128> and pick the UNE variant to list it in the launcher
[15:00] <didrocks> so, for UNE, we will have in UNE: OnlyShowIn=GNOME -> Show; OnlyShowIn=UNE -> Show; (OnlyShowIn=GNOME and) NotShowIn=UNE -> Don't show
[15:01] <didrocks> seb128: let me look at gnome-menus API, I don't know if it filters itself all "GNOME", or if you can give it a name of a session
[15:03]  * ayan waves.
[15:06] <seb128> hey ayan
[15:10] <didrocks> hey ayan
[15:19] <tremolux> hello seb128, I'd like to do a software-center upload today; do you think you may have time to sponsor?
[15:20] <seb128> tremolux, hey, sure, is it ready now or do you want an upload later?
[15:20] <tremolux> seb128: cool, thx!  ok, I just need to update the changelog for the release
[15:21] <tremolux> seb128: I'm not sure of the process - so I can upload to bzr trunk, can you take it from there?
[15:21] <seb128> tremolux, ok, let me know when it's ready for upload
[15:21] <seb128> tremolux, yes, I will roll the update from bzr when bzr is ready
[15:21] <tremolux> seb128: awesome, thanks a lot
[15:22] <seb128> you're welcome
[15:46] <fta> Sarvatt, if you pull my dashboard branch, you'll get more readable big tables (hopefully)
[16:08] <tremolux> seb128: ok, everything's all ready in trunk at lp:software-center
[16:08] <tremolux> seb128: please let me know if there's anything else I need to do
[16:08] <seb128> tremolux, ok, let me check that
[16:08] <tremolux> seb128: k
[16:34] <seb128> tremolux, do you know if s-c should build on lucid?
[16:34] <seb128> tremolux, I've current aptdeamon from the ppa
[16:34] <seb128> tremolux, I get
[16:34] <seb128> Testing ./test_apthistory.py
[16:35] <seb128> [Errno 2] No such file or directory: '/history.log'
[16:35] <tremolux> seb128: hmm, I haven't tried building on lucid, I build in a maverick chroot
[16:36] <seb128> tremolux, does that test work for you?
[16:36] <seb128> tremolux,
[16:36] <seb128> cd tests
[16:36] <seb128> ./test_apthistory.py
[16:39] <tremolux> seb128: hmm, it doesn't when run standalone, I get that error
[16:39] <tremolux> seb128: let me look at this
[16:39] <seb128> tremolux, thanks
[16:39] <seb128> tremolux, the package build target does run the tests and break on that
[16:41] <tremolux> seb128: ok, thanks for letting me know
[16:43] <seb128> tremolux, ./test_software_channels.py fails as well
[16:43] <seb128> tremolux, out of those I can build and run it fine
[16:45] <seb128> tremolux, in fact it works now, dunno why it broke before, so only the history one is an issue
[16:46] <tremolux> seb128: yeah, it's test problems, we added some new ones very recently and all the kinks aren't worked out yet clearly
[16:46] <seb128> tremolux, I can skip the test if you want
[16:46] <seb128> tremolux, I don't know what the policy is for those usually, I guess mvo try to get those to work before rolling a new version usually knowing him
[16:47] <tremolux> seb128: yes, it'd be best
[16:56] <tremolux> seb128: hrm, getting the same error at -r837 (which was the 2.1.2 release)
[16:56] <tremolux> seb128: (just wanted to make sure it wasn't new code breaking it legitimately)
[16:57] <seb128> tremolux, ok, so let's assume the test is buggy and skip it?
[16:57] <tremolux> seb128: yes, I think that'd be fine; and I will fix the test after
[16:57] <seb128> ok
[16:58] <tremolux> seb128: also, the case is for a *very* corner condition
[16:58] <tremolux> seb128: but somebody out there hit it so we added the case
[16:59] <tremolux> seb128: thanks again, sorry for the trouble
[17:02] <tremolux> seb128: (and I know the fix works in the code, it's a test case problem)
[17:10] <seb128> tremolux, uploaded
[17:10] <tremolux> seb128: thanks!  \o/
[17:39] <jcastro> didrocks: I think it would be handy if apport kept track of wether a person is in UNE or desktop. Does it do that and I'm just not seeing it?
[17:39] <jcastro> didrocks: for example appmenu bugs, they could be in unity or normal GNOME for all I know
[17:39] <didrocks> jcastro: no, but that can be a good idea to do at apport level
[17:40] <didrocks> jcastro: we have the GDMSESSION variable for that
[17:40]  * didrocks adds to TODO, shouldn't be hard
[17:41] <jcastro> didrocks: if you file a bug pls sub me to it!
[17:43] <didrocks> jcastro: done
[17:44] <chrisccoulson> yay, jaunty langpacks uploaded :)
[17:44] <jcastro> didrocks: yeah I think it will be useful too when we triage bugs from banshee-meego vs. normal banshee, etc.
[17:44] <chrisccoulson> i bet my ISP hates me, i was only 2GB under my bandwidth limit last month
[17:44] <didrocks> jcastro: maybe add it as a tag?
[17:45] <jcastro> didrocks: yeah, I see people adding "ubuntu-une" tags already
[17:46] <didrocks> jcastro: right, ubuntu-une and ubuntu-desktop can be good :)
[17:46] <jcastro> sounds good to me
[17:51] <htorque> jcastro: i think the ubuntu-une tag already gets added automatically
[17:51] <jcastro> htorque: oh ok, so you didn't add that by hand on the bugs you just filed?
[17:51] <htorque> jcastro: nope
[17:52] <jcastro> didrocks: wow, you fixed the bug already! :)
[17:52] <didrocks> jcastro: false alert? I'm working on banshee now ;)
[17:53] <didrocks> maybe that can have an incidence on apport, but it wasn't intentional :-)
[17:56] <pitti> good night everyone!
[17:57] <didrocks> enjoy your evening pitti
[18:00] <seb128> 'night pitti
[18:02] <dobey> seb128: hey
[18:02] <dobey> seb128: do i actually need to put python-support in the Build-Depends-Indep? Or does it really only need to be in the Depends: on the binary package (and i presume cdbs adds it to python:Depends automatically anyway)
[18:05] <seb128> dobey, it needs to be in the build-depends
[18:05] <seb128> dobey, since it ships dh_pysupport
[18:05] <seb128> which is used in the rules at build time
[18:06] <dobey> ah ok
[18:06] <dobey> thanks
[18:37] <Sarvatt> fta: looks great! http://sarvatt.com/xorg-edgers/
[18:37] <Sarvatt> definitely a lot better at 1024x600 :)
[18:38] <fta> \o/
[20:49] <rickspencer3> didrocks, around at all?
[20:49] <didrocks> rickspencer3: yeah
[20:49] <rickspencer3> hey didrocks I have a totally random question for you
[20:49] <rickspencer3> I'm trying to figure some stuff out about the Ubuntu work items
[20:49] <didrocks> rickspencer3: do you want random answers too? ;)
[20:50] <rickspencer3> a whole bunch looked like they were added on June 1th
[20:50] <didrocks> oh really?
[20:50] <didrocks> for alpha2?
[20:50] <rickspencer3> June 15th, that is
[20:50] <rickspencer3> didrocks, well, according to the database
[20:51] <rickspencer3> didrocks never mind
[20:51] <didrocks> rickspencer3: I'm looking
[20:51] <rickspencer3> didrocks, don't
[20:51] <didrocks> rickspencer3: ok ;)
[20:51] <rickspencer3> there's something weird in the data, but it's not because of you
[20:52] <didrocks> rickspencer3: I didn't add anything or target a spec IIRC
[20:52] <rickspencer3> well .. I never thoguht it was "because of you"
[20:52] <rickspencer3> but I mean .. nm
[20:52] <didrocks> or maybe, my "evil me" :-)
[20:52]  * rickspencer3 pulls on clumps of hair
[20:53] <rickspencer3> didrocks, I only asked you specifically because I knew you would answer
[20:53] <rickspencer3> :)
[20:53] <didrocks> rickspencer3: heh :-)
[22:27] <fta> Sarvatt, versions should now be properly sorted (it was a basic string sort before), let me know if you notice something weird
[22:47] <Sarvatt> fta: are 502: bad gateway errors common? :)
[22:48] <fta> Sarvatt, no, i run it every 15min, i just get a handful per week
[22:48] <fta> but it's often slow :(
[22:49] <fta> i will add caching soon
[22:49] <Sarvatt> i'm just updating it locally, my server is limited to jaunty because of upstart and haven't gotten around to building everything from bzr
[22:50] <Sarvatt> darn 3 in a row, takes 10 minutes to time out
[23:07] <fta> Sarvatt, go complain to #lp ;)
[23:09] <fagan> fta: I thought its #launchpad
[23:09] <fta> yep
[23:09] <fagan> oh you just shortened it :)
[23:14] <fta> Sarvatt, fixed the css in my last commit for today.
[23:15] <fta> i like chromium's inspector to debug css
[23:28] <fagan> fta: ive been using the opera one its really nice
[23:32] <Sarvatt> fta: btw does this make any sense for chromium? http://sarvatt.com/downloads/patches/chromium-colormap-fix.patch
[23:39] <fta> Sarvatt, iirc, bratsche discussed about that with upstream (evmar), i don't remember how it ended
[23:41] <bratsche> Sarvatt: What is that colormap for?
[23:42] <bratsche> fta: btw, I think the rgba stuff is temporarily out of gtk+ in Meerkat for now.  I will be reintroducing it I think, but I'd like to create a different environment variable than the one you were using.
[23:43] <Sarvatt> looks like video controls
[23:44] <fta> bratsche, noted. this rgba thing's been causing me lots of issues (with no visible benefits) but as long as there's a workaround, i'm fine.
[23:44] <bratsche> Sarvatt: Do you still have the rgba patch in your gtk+?  Does this patch actually make a difference?
[23:45] <Sarvatt> i'm test building it, and yep i have the previous 12 gtk's in archives
[23:45] <fta> Sarvatt, just one comment about chromium patches, i use the same packaging from maverick to hardy, so all patches are shared. i hope it won't break backports
[23:46] <bratsche> Sarvatt: Cool, let me know how it works out.  And make sure you remove fta's patch which sets the environment to disable rgba colormaps.
[23:46] <bratsche> Is there a url to view this source file online?  I don't have the Chromium code on my machine and I don't really want to pull it down.
[23:47] <fta> http://src.chromium.org/svn/trunk/src/
[23:47] <Sarvatt> yeah i'm trying to track down a problem with chromium with cairo 1.9.8
[23:47] <Sarvatt> http://sarvatt.com/downloads/RenderThemeGtk.cpp
[23:48] <bratsche> Thanks.
[23:48] <Sarvatt> http://sarvatt.com/downloads/RenderThemeGtk.cpp.txt
[23:48] <Sarvatt> easier :)
[23:49] <Sarvatt> thats the patched one, sorry
[23:49] <bratsche> This looks like it's just going to revert all drawing to using the system colormap instead of the default one.
[23:49] <bratsche> I don't see anything specific to plugins or video here.
[23:49] <fta> iirc, the rgba patches caused two issues in chromium: 1/ flash crashing and 2/ the tab transparency gone when dragged
[23:50] <bratsche> Or maybe I don't understand which situations drawable == NULL and which it's not NULL.
[23:50] <fta> (well, 2/ is caused by the workaround)
[23:50] <bratsche> fta: The tab transparency being gone was a result of your patch, because you disabled all RGBA colormaps.  That's why I am going to introduce a toolkit-level environment variable.
[23:51] <fta> yep
[23:51] <bratsche> So when this lands again, it will have an environment that reverts the behavior of gdk_screen_get_default_colormap().
[23:51] <bratsche> And we can use that until evmar gets us a real fix.
[23:57] <Sarvatt> tab transparency being gone? thats actually somewhat like what i'm seeing with the new cairo, by patch do you mean just the XLIB_SKIP_RGBA_VISUALS in the wrapper?
[23:58] <fta> yes
[23:59] <Sarvatt> ah ok not the same thing thing, i'm getting screwed up loading animations on the tab icons and the tabs themselves disappear when i open enough tabs to make the icons go away