[02:22] <TheMuso> rickspencer3: Seems the accessibility live CD stuff is odd, it sometimes works, and sometimes doesn't Booted on a couple of machines, with varying results.
[02:22] <rickspencer3> TheMuso, unfortunate
[02:22] <rickspencer3> those can be the hardest to debug
[02:22] <TheMuso> rickspencer3: I am going to see if I can make it more reliable, but not sure exactly how I might accomplish that at this point.
[02:23] <TheMuso> rickspencer3: Hopefully the new gnome updates next week may help, but I really don't know.
[02:50] <rickspencer3> robert_ancell, kenvandine, TheMuso anybody available to quickly confirm a bug for me?
[02:50] <kenvandine> rickspencer3, sure
[02:50] <robert_ancell> rickspencer3, yes
[02:50] <rickspencer3> kenvandine, ok, basically, desktopcouch is completely crapping out on me
[02:50] <kenvandine> :/
[02:51] <rickspencer3> https://bugs.edge.launchpad.net/ubuntu/+source/desktopcouch/+bug/451809
[02:51] <rickspencer3> so start a python session
[02:52] <kenvandine> ok
[02:52] <rickspencer3> >>> import desktopcouch.records
[02:52] <rickspencer3> >>> desktopcouch.records.server.CouchDatabase("boo")
[02:52] <rickspencer3> this throws a 401 for me
[02:53] <rickspencer3> I'm on Version: 0.4.4-0ubuntu1
[02:54] <robert_ancell> rickspencer3, so you created "boo" before hand right?
[02:54] <rickspencer3> robert_ancell, nope
[02:55] <robert_ancell> rickspencer3, I get NoSuchDatabase exception
[02:55] <rickspencer3> bit if you want, you can go CouchDatabase("boo", create=True) and that also blows up for me
[02:55] <rickspencer3> robert_ancell, so you are getting the correct exception
[02:55] <robert_ancell> (I just installed desktopcouch then)
[02:55] <rickspencer3> robert_ancell, are you on the same version of desktopcouch?
[02:55] <robert_ancell> yes
[02:56] <rickspencer3> well, that's good, so you couldn't repro it
[02:56] <rickspencer3> robert_ancell, do you have any data in your CouchDB?
[02:56] <robert_ancell> no
[02:56] <kenvandine> i get NoSuchDatabase too
[02:56] <robert_ancell> fresh install
[02:57] <kenvandine> rickspencer3, with create=True it worked for me
[02:57] <kenvandine> with 0.4.4
[02:57] <rickspencer3> well well well
[02:58] <rickspencer3> kenvandine, robert_ancell would one you mind mentioning on the bug report that you couldn't confirm?
[02:58] <kenvandine> sure
[02:59] <rickspencer3> so I did something really weird tonight
[02:59] <rickspencer3> I installed netbook-launcher
[02:59] <kenvandine> rickspencer3, what version of couchdb-bin do you have?
[02:59] <kenvandine> rickspencer3, i commented
[03:00] <rickspencer3> Version: 0.10.0-0ubuntu1
[03:00] <rickspencer3> and then I removed my Applications/Places/System Menu
[03:00] <rickspencer3> and replaced it with a "show my desktop" panel icon
[03:01] <rickspencer3> kenvandine, I'll try removing and reinstalling dekstopcouch, maybe something got configured funny
[03:06] <rickspencer3> how do you make gnome-do show up like a little dock at the bottom?
[03:06] <rickspencer3> jono, ^
[03:07] <kenvandine> go to the preferences
[03:07] <rickspencer3> did that
[03:07] <kenvandine> and change the interface to "Docky"
[03:07] <rickspencer3> thanks kenvandine
[03:07] <kenvandine> np
[07:50] <albasheers1> converting flv file to avi using ffmpeg gives this error "Cannot allocate temp picture, check pix fmt" can  anybody help
[08:21] <didrocks> good morning
[08:21] <mvo> hey didrocks
[08:22] <didrocks> hi mvo
[08:22] <didrocks> lut seb128
[08:22] <seb128> good morning there
[08:22] <mvo> good morning seb128
[08:23] <seb128> hey didrocks mvo, how are you?
[08:23] <didrocks> seb128: busy as the last two weeks, but fine, thanks :) You?
[08:23] <seb128> busy and a bit tired but fine otherwise
[08:23] <seb128> will be better after coffee
[08:23] <seb128> ;-)
[08:24] <didrocks> hehe :-)
[08:25]  * mvo is already sipping some tea
[08:26] <seb128> so pitti joined to club of those who work until unreasonable hours
[08:26] <seb128> he did uploads at 1:30am this night
[08:26] <slomo> mvo: ping? :)
[08:26] <seb128> 1:45
[08:27] <bryce_> hi tseliot
[08:28] <tseliot> hey bryce_
[08:35] <mvo> slomo: pong
[08:38] <slomo> mvo: did you decide that gnome-codec-install 0.4.x is not going to be in karmic?
[08:40] <mvo> slomo: I have it merged, I want to do a bug triage run (LP has quite a few) and see what other low hanging fruits there are that can be fixes
[08:40] <mvo> slomo: sorry that I have not accted yet, its on my list for tihs week
[08:40] <slomo> mvo: oh, i didn't notice there were LP bugs... thanks for looking through them :)
[08:41] <mvo> I have not started that yet (I don't enjoy bug triage much), but I will (and send patches)
[08:41] <mvo> or should I commit directly ?
[08:41] <slomo> commit directly and feel free to upload it to unstable when you're done :)
[08:43] <mvo> thanks
[08:51] <seb128> slomo, https://edge.launchpad.net/ubuntu/+source/gnome-codec-install/+bugs
[08:51] <baptistemm> good morning
[08:51] <seb128> slomo, I asked you the other day if you looked at those or wanted them forwarded somewhere
[08:51] <seb128> slomo, but you probably didn't read the question
[08:51] <seb128> lut baptistemm
[08:51] <baptistemm> salut seb128
[08:51] <slomo> seb128: debian bug tracker would be nice, yes... or telling me about them here :)
[08:52] <seb128> slomo, you can https://edge.launchpad.net/ubuntu/+source/gnome-codec-install/+subscribe
[08:52] <seb128> slomo, seeing the number of bugs that shouldn't be too much spamming
[08:52] <seb128> slomo, but I can ping you when I notice annoying issues
[08:54] <slomo> thanks
[08:54] <slomo> :)
[08:57] <seb128> ups
[08:58] <seb128> archive is already frozen for karmic
[09:01] <chrisccoulson> hello everyone
[09:03] <seb128> hey chrisccoulson
[09:03] <chrisccoulson> hey seb128
[09:03] <chrisccoulson> we're frozen already?
[09:03] <chrisccoulson> (i was hoping it would be a bit later on) ;)
[09:04] <seb128> yes
[09:04] <seb128> same here
[09:06] <jbicha> is it too late to get bug 451792 fixed?
[09:06] <chrisccoulson> i attached a patch for bug 409621 last night, but that's not really release critical
[09:06] <seb128> chrisccoulson, I will sponsor
[09:07] <chrisccoulson> seb128 - thanks
[09:07] <seb128> chrisccoulson, the second one fix the first one?
[09:07] <chrisccoulson> i didn't get as much done last night as i'd hoped, with this screensaver issue thats appeared
[09:08] <seb128> chrisccoulson, you could have made one patch with both changes ;-)
[09:08] <chrisccoulson> i suppose so, but i did it as 2 as they are 2 separate upstream commits ;)
[09:13] <seb128> ok
[09:14] <seb128> I tend to use 1 patch by logical changeset
[09:14] <seb128> not by commit ;-)
[09:15] <chrisccoulson> seb128 - yeah, that makes more sense
[09:15] <seb128> brb
[09:25] <chrisccoulson> seb128 - did you plan to make any gdm changes to fix the upgrade issue, or is there anything you want from me for that issue?
[09:25] <seb128> chrisccoulson, it's on my list for this morning
[09:26] <seb128> though I'm not sure why the chown is there to start
[09:26] <chrisccoulson> no, i'm not too sure about that either
[09:26] <seb128> I will use sudo dbus-launch || true for the gconf call
[09:26] <seb128> but the .gvfs issue is due to
[09:26] <seb128> if [ -d /var/lib/gdm ]; then
[09:26] <seb128>   chown -R gdm:gdm /var/lib/gdm
[09:26] <seb128>   chmod 0750 /var/lib/gdm
[09:27] <seb128> which I'm not sure why it's there
[09:27] <seb128> either it's required one at install
[09:27] <seb128> or at every run
[09:27] <seb128> it doesn't make sense to just do it on upgrades
[09:27] <seb128> mvo, pitti, lool: ^ opinion?
[09:37] <pitti> Good morning
[09:37] <pitti> sorry for being so late
[09:37] <pitti> *brrrr* it's snowing already
[09:37] <seb128> hey pitti
[09:37] <seb128> it was freezing there too
[09:37] <chrisccoulson> really? i wouldn't mind some snow:)
[09:37] <chrisccoulson> all we get is grey clouds and drizzle...
[09:37] <seb128> right, no snow there either
[09:39] <pitti> seb128: hours> well, wanted to get a reasonably clean slate before the freeze :)
[09:39] <pitti> (but yes, I slept pretty badly)
[09:39] <seb128> I should have done that
[09:39] <seb128> slangasek frozen this morning already, grrrr
[09:39] <seb128> -n
[09:39] <pitti> seb128: eww, sudo dbus-launch gconf-tool?
[09:39] <seb128> I was expecting being able to push pending this this morning
[09:40] <seb128> pitti, you are the one who recommended no using su but sudo?
[09:40] <pitti> seb128: you can still; frozen != "don't change anything any more"
[09:40] <seb128> pitti, why eww now?
[09:40] <pitti> seb128: right, but launching dbus?
[09:40] <seb128> pitti, gconftool needs a dbus session to talk to the gconf server
[09:40] <seb128> it leads to many installation failure now
[09:40] <seb128> because it doesn't find it
[09:41] <pitti> I thought we could use --direct if gconfd wasn't running already?
[09:41] <pitti> it just doesn't seem to be a step which improves robustness to me
[09:41] <seb128> "if gconfd wasn't running already"
[09:41] <seb128> but it is if you have a gdm greater running...
[09:41] <seb128> pitti, I'm open to better suggestions
[09:41] <seb128> see bug #441028
[09:41] <pitti> seb128: oh, you are saying that if it's running you need dbus, because in the sudo session you don't get the already running dbus address?
[09:42] <pitti> seb128: so we can't just ship a .gtkrc or ~/.gconf tree then, I suppose
[09:42] <pitti> seb128: ok, so obviously the two of you discussed that already, if that's considered robust, then go ahead
[09:42] <seb128> it's not considered robust
[09:42] <pitti> I just wonder what happens if you then get two session dbuses, or launching one fails, etc.
[09:42] <seb128> > <pitti> seb128: oh, you are saying that if it's running you need dbus, because in the sudo session you don't get the already running dbus address?
[09:43] <seb128> not sure, it fails to contact the gconf server right now
[09:43] <seb128> but it could be that the su call doesn't get the right environment variables
[09:43] <seb128> I didn't investigate
[09:44] <seb128> the dbus-launch way seemed cheap and easy
[09:44] <seb128> pitti, .gconf, not really, if there is a running instance it could lead to write races between the running gconf and the manual change
[09:45] <seb128> pitti, .gtkrc I didn't try but it would work for some of the keys anyway
[09:45] <seb128> and I'm not sure if would win over g-s-d keys
[09:45] <seb128> ie which settings would be used
[09:45] <pitti> ok
[09:45] <pitti> well, if it works, go ahead
[09:46] <seb128> I don't manage to get it work due to your <<EOF hack
[09:46] <seb128> still fighting that
[09:46] <seb128> seems to not be working with sudo -u gdm
[09:46] <seb128> my bash foo is not good
[09:47] <seb128> $     sudo -u gdm <<EOF
[09:47] <seb128> > dbus-launch gconftool --set /desktop/gnome/background/picture_filename --type string /usr/share/images/xsplash/bg_2560x1600.jpg || true
[09:47] <seb128> > EOF
[09:47] <seb128> usage: sudo [-n] -h | -K | -k | -L | -V | -v
[09:47] <seb128> gnagnagna
[09:48] <pitti> $ sudo -u postgres -s <<EOF
[09:48] <pitti> > whoami
[09:48] <pitti> > EOF
[09:48] <pitti> postgres
[09:48] <seb128> oh, "-s"
[09:48] <pitti> seb128: add an "-s"
[09:48] <pitti> that shouldn't start PAM (I think -i might)
[09:48] <seb128> thanks
[09:48] <seb128> pitti, btw any opinion about the chown call?
[09:49] <pitti> seb128: how is it related to .gvfs ?
[09:49] <seb128> pitti, .gvfs is a fuse mount and the chown breaks
[09:50] <seb128> bug #438561
[09:50] <seb128> pitti, the fuse mount is only accessible to the user
[09:50] <seb128> "chown: cannot access '/var/lib/gdm/.gvfs': Permission denied"
[09:51] <seb128> that's a design decision for fuse I think
[09:52] <pitti> oh, "chown -R", WTH
[09:52] <pitti> that seems weird to me
[09:52] <pitti> shouldn't it rather do something like
[09:52] <pitti> if ! [ -d /var/lib/gdm ]
[09:53] <pitti> and mkdir/chown (no -R) it then?
[09:53] <seb128> I'm not sure what was the intend
[09:53] <seb128> as said before
[09:53] <seb128> " either it's required one at install
[09:53] <seb128>  or at every run
[09:53] <seb128>  it doesn't make sense to just do it on upgrades"
[09:54] <pitti> we don't chown /home/* in case the user's uid changes either..
[09:54] <pitti> seb128: my gut feeling is that this should just be ripped out
[09:54] <pitti> seb128: at least the -R
[09:54] <pitti> at initial install the dir does need to get chowned to gdm
[09:55] <pitti> seb128: ooh, hang on
[09:55] <pitti> $ dpkg -L gdm|grep var/lib
[09:55] <pitti> /var/lib
[09:55] <pitti> /var/lib/gdm
[09:55] <pitti> /var/lib/gdm/.gconf.path
[09:55] <pitti> /var/lib/gdm/.gconf.mandatory
[09:55] <pitti> /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml
[09:55] <pitti> that's probably it
[09:55] <seb128> no
[09:55] <seb128> that call was there before having gdm using gconf
[09:55] <pitti> I mean, they intended to own those files to gdm
[09:55] <pitti> so what about
[09:55] <pitti> chown gdm:gdm /var/lib/gdm
[09:56] <pitti> chown -R gdm:gdm /var/lib/gdm/.gconf*
[09:56] <pitti> ?
[09:56] <seb128> I'm wondering why those gconf file are shipped in the binary
[09:56] <pitti> seb128: and I'm wondering whether we cuold ust change /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml to have our theme keys, and drop all the su/dbus-launch stuff
[09:58] <seb128> pitti, that would remove the possibility for users to change those settings
[09:58] <pitti> seb128: well, right now we gconfify it on every installation anyway
[09:58] <seb128> right
[09:58] <seb128> but users can do a sudo -u gdm gconftool call to change it
[09:59] <seb128> see /etc/gconf/2/path
[09:59] <pitti> I agree that we need a better solution for themeability eventually, but we don't have  it either way right now
[09:59] <seb128> .gconf.mandatory is used before .gconf
[09:59] <seb128> which means values set with gconftool would not be used
[09:59] <pitti> I see
[09:59] <seb128> the mandatory is meant as a sysadmin way to impose things you can't change
[10:00] <pitti> seb128: at this point, I'd rather have ***buntu-default-settings divert the file, though
[10:00] <pitti> I really don't feel comfortable about all this sudo dbus-launch gconftool stuff, sooner or later it will blow upp
[10:00] <seb128> that's why I added || true
[10:00] <albasheers> mplayer is not able flv
[10:00] <seb128> if it blow up you will just not get the theme set
[10:01] <seb128> albasheers, try #ubuntu for user questions
[10:01] <albasheers> ok
[10:01] <pitti> seb128: ok, another question
[10:01] <seb128> why is it so difficult to see some gconf keys
[10:02] <pitti> seb128: if we ship /var/lib/gdm/.gconf.defaulttheme with those keys
[10:02] <pitti> seb128: and add that path to /var/lib/gdm/.gconf.path early
[10:02] <pitti> so that people can override it?
[10:02] <seb128> hum
[10:03] <seb128> # default path for sabayon
[10:03] <seb128> include "$(HOME)/.gconf.path.defaults"
[10:03] <seb128> we can abuse this one?
[10:03] <seb128> /var/lib/gdm/.gconf.path.defaults
[10:03] <seb128> I would like to avoid adding yet another item to the lookup list
[10:03] <seb128> it cost for every gconf lookup for every user
[10:03] <pitti> but it'd just be locally for gdm, no?
[10:04] <seb128> /var/lib/gdm/.gconf.path.defaults
[10:04] <seb128> yes
[10:04] <pitti> what's the difference to /var/lib/gdm/.gconf.path ?
[10:04] <seb128> see /etc/gconf/2/path
[10:04] <seb128> .gconf.path is used before .gconf
[10:05] <seb128> and .gconf is where user change go
[10:05] <seb128> I'm not sure why .gconf.path is there
[10:05] <seb128> I'm not sure why .gconf.path is there but it will be used before user changes
[10:05] <seb128> ie break the possibility to use gconftool to do your own changes
[10:05] <seb128> ok
[10:05] <seb128> pitti, let me play with a /var/lib/gdm/.gconf.path.defaults static %gconf
[10:07] <lool> seb128: I dont see why chown would be required at every run?  If the goal is to fix permissions from previous versions of the package, then running this on upgrade seems ok
[10:07] <pitti> seb128: oh, it's "first match wins", not "later matches can override"?
[10:07] <lool> seb128: I dont know what the intent is either, sorry
[10:07] <seb128> pitti, right
[10:07] <seb128> lool, that's ok, thanks
[10:07] <pitti> seb128: ok, then can we just add it to /var/lib/gdm/.gconf.path as last item then?
[10:12] <seb128> pitti, you mean?
[10:13] <pitti> seb128: so that users can overwrite it?
[10:13] <pitti> if the last one has the lowest priority
[10:13] <seb128> pitti, I didn't get what you mean by as last item there
[10:13] <seb128> as said
[10:13] <seb128>  pitti, let me play with a /var/lib/gdm/.gconf.path.defaults static %gconf
[10:14] <pitti> seb128: ok, nevermind
[10:14] <pitti> seb128: you said that the first match in the search list will win
[10:14] <seb128> ie ship /var/lib/gdm/.gconf.path.defaults with some xml to set those values
[10:14] <pitti> seb128: then I don't understand why having xml:readonly:$(HOME)/.gconf.mandatory is the last one in /var/lib/gdm/.gconf.path
[10:15] <pitti> seb128: ok, so it's that (so that gconftool will still work), and then drop all teh gconftool stuff from postinst, and finally fix the chown calls
[10:15] <pitti> then it should be robust and working and customizable?
[10:15] <seb128> DOH
[10:15] <seb128> pitti, I didn't know about /var/lib/gdm/.gconf.path
[10:15] <seb128> sorry about that
[10:15] <seb128> I was looking at the system default path
[10:15] <seb128> not at the custom gdm one
[10:16] <seb128> I'm confused now
[10:17] <seb128> pitti, I read what you wrote too quickly
[10:19]  * pitti hugs seb128
[10:19]  * seb128 hugs pitti
[10:19] <seb128> I'm not sure how the local .gconf.path works now
[10:20] <seb128> ie if those are used after or before the system list
[10:27] <mvo> Amaranth: I just checked compiz bzr - does gconf really have to be removed? it means users will always have to install cpp if they don't want to use the ini backend?
[10:30] <joaopinto> hum, shouldn't pidgin have transparent tray icons ?
[10:32] <seb128> transparent?
[10:37] <joaopinto> yes, unlike all the other tray icons on the notification are pidgin overrides my background
[10:38] <joaopinto> I meam the icon's background should be transparent
[10:41] <seb128> dunno about this one, look on launchpad and upstream bugs?
[10:42] <joaopinto> erm, pidgin is main, no core dev using it :P ?
[10:43] <joaopinto> ok, searching
[10:43] <pitti> joaopinto: empathy FTW :)
[10:43] <joaopinto> pitti, right, but pidgin is still main :P
[10:44] <joaopinto> but yes, I shoud also sart using empathy
[10:45] <seb128> joaopinto, I use pidgin most of the time but I'm too busy to look to such details today
[10:45] <joaopinto> it's already reported, bug 447548
[10:45] <seb128> good
[10:47] <joaopinto> seb128, you could you just set your panel bar to transparent to confirm, it could be config specific
[10:47] <seb128> joaopinto, I'm running empathy right now and I don't fancy to close to try
[10:48] <seb128> joaopinto, and to be honest I don't really care about transparency or not right now
[10:48] <seb128> I've other higher issue on my karmic list
[10:48] <joaopinto> ok ok, easy :P
[10:48] <seb128> there thousand of tiny details like that in launchpad we will not fix those for karmic now
[10:49] <seb128> but you found a bug so it's tracked
[10:51] <joaopinto> I am checking upstream, it's also reported there, I am not sure yet if it's fixed because it was set as a duplicate of a much complex bug
[10:51] <seb128> hate gconf
[10:52] <seb128> pitti, I can't get it working and I don't know why
[10:52] <pitti> seb128: it's not just because of the now existing ~/.gconf from the gconftool settings?
[10:52] <seb128> pitti, no, I did rm -rf that one
[10:52] <seb128> I did strace it
[10:53] <seb128> it doesn't try to stat the dirs I add to /var/lib/gdm/.gconf.path
[10:53] <seb128> nor use system list ones
[10:53] <seb128> ie .gconf.path.defaults
[10:53] <seb128> and I do restart gconfd-2 between tries
[10:53] <pitti> seb128: hm, I wonder if /var/lib/gdm/.gconf.mandatory/%gconf-tree.xml actually works then
[10:54] <pitti> does it work to merge the keys there?
[10:54] <seb128> pitti, it does
[10:54] <seb128> if I copy my %gconf-tree.xml there it's used
[10:54] <seb128> I tried both merged and non merged ways
[10:59] <seb128> pitti, ok that works
[10:59]  * seb128 kicks gedit
[10:59] <seb128> it was in a mode were ctrl-s was not storing the changes
[10:59] <seb128> but not saying it was not either
[11:00] <pitti> seb128: "saying"?
[11:00] <seb128> pitti, no error, it was acting like ctrl-s was working
[11:00] <seb128> but it was not, the file on disk was not updated
[11:00] <pitti> ah
[11:00] <pitti> how weird
[11:00] <seb128> yes
[11:00] <seb128> anyway it works
[11:00] <pitti> you rock
[11:01] <seb128> pitti, I will put that in bzr for review soon
[11:01] <seb128> pitti, what did we say we would do with the chown?
[11:01] <pitti> seb128: IMHO:
[11:01] <pitti> chown gdm:gdm /var/lib/gdm
[11:01] <pitti> chown -R gdm:gdm /var/lib/gdm/.gconf*
[11:01] <seb128> is there any need for that?
[11:01] <pitti> so that we don't catch /var/lib/gdm/.gvfs
[11:02] <seb128> chown gdm:gdm /var/lib/gdm
[11:02] <pitti> seb128: well, I don't know what gconf thinks if .gconf.mandatory is root owned (as shipped in the .deb)
[11:02] <seb128> should that be the case anyway?
[11:02] <pitti> seb128: yes, otherwise gdm can't write into its home dir
[11:02] <seb128> ok
[11:02] <seb128> works for me
[11:02] <seb128> pitti, I'm putting that in bzr and pinging you for review in a bit
[11:02] <seb128> thanks!
[11:02] <pitti> but we only ship that dir and .gconf*, so we shouldn't need to chwon anything else
[11:02] <pitti> seb128: merci
[11:03] <seb128> does chown stops on errors?
[11:03] <seb128> I was wondering if adding || true would work
[11:04] <pitti> seb128: if the chown fails, we have a problem, though
[11:48] <seb128> pitti, the changes are in gdm r144 if you want to review
[12:12] <pitti> seb128: looks good to me, thank you! please go ahead and upload
[12:12] <seb128> pitti, ok thanks!
[12:32] <diverse_izzue> why is the package gstreamer0.10-schrodinger suddenly marked as obsolete?
[12:52] <diverse_izzue> When I pair my Nokia E51 with Karmic over Bluetooth, should I not be offered to use it as a modem with NetworkManager?
[12:54] <davidbarth> seb128: on #436975 we have resolved the configurability issue; while the confusion may remain with n-daemon settings
[12:54] <davidbarth> seb128: (hi, btw)
[12:54] <davidbarth> seb128: can i add a task to notification-daemon (ubuntu) to track that issue post karmic?
[12:57] <seb128> hey davidbarth
[12:57] <seb128> bug #436975
[12:59] <seb128> davidbarth, I think there is already some bugs about that
[12:59] <seb128> davidbarth, the bug has also been taken over by people confused by the 2 slots
[13:02] <davidbarth> seb128: ok, i'll try to find the one on the settings dialog; i will close this one and call for the 2-slots discussion to happen on the ayatana list
[13:02] <seb128> davidbarth, I'm surprised nobody did seen the number of comments about that on other bugs
[13:03] <dpm> hi all
[13:03] <seb128> davidbarth, see bug #438536
[13:03] <seb128> hey dpm
[13:03] <dpm> hey seb128
[13:04] <dpm> could anyone perhaps look at bug 451673?
[13:04] <seb128> dpm, it's just a matter to get an extra from rosetta and to build with it
[13:04] <seb128> dpm, it's already on my list for today
[13:04] <dpm> seb128, ok, thanks
[13:05] <seb128> dpm, the translated xml are in the source so it doesn't use language packs there
[13:05] <seb128> davidbarth, some people did a ppa with the 2 slots change undone see the bug ;-)
[13:06] <dpm> seb128, yes I know. It only seems to affect the first help page, though. Other sections seem to be translated as usual
[13:06] <seb128> dpm, the documentation content is in the ubuntu documentation package, only the index is in the browser
[13:07] <dpm> ah, ok
[13:08] <seb128> davidbarth, MacSlow|lunch: you might also want to review the change from asac to use correct icon prefix in notify-osd
[13:08] <seb128> davidbarth, MacSlow|lunch: or karmic will use what mac_v call incorrect icons
[13:11] <mac_v> davidbarth: seb128: MacSlow|lunch :  *i* dont call the incorrect but rather... they are incorrect ;) well as far as the https://wiki.ubuntu.com/NotifyOSD#Icon documentation says ;)
[13:14] <mac_v> davidbarth: regarding the 2 slots , it is something new .. some users *will* find weird... IMO , doesnt seem like a wrong choice... ayatana discussion is good though :)
[13:14] <seb128> mac_v, I find it confusing, not nice looking and unefficient
[13:14] <seb128> I'm pretty sure we will get a gconf key for that next cycle
[13:14] <mac_v> ;)
[13:15] <seb128> but seems some people need to make mistake, get really unhappy users complaining to then make things how they should ;-)
[13:18] <asac> seb128: you think there would be time to do any major icon shuffeling in karmic?
[13:18] <asac> i thought not ... whihc is why i pushed this back to lucid in my personal plans atm
[13:19] <asac> but if we want to do something ... lets talk ;)
[13:19] <seb128> asac, I don't know, I guess it's late now yes
[13:22] <asac> i dont see that there is something really urgent besides general confusion about the fdo icon name spec and a bunch of hacks in the theme
[13:24] <seb128> right
[13:24] <seb128> it's just that what we have doesn't match what the design says
[13:24] <seb128> and we try to follow design team recommendations
[13:24] <seb128> but I don't really care either which icon is used
[13:25] <mac_v> asac: this wouldnt be much of an icon reshuffling , this is probably a high priority bug from the UX team's perspective , which two dev teams didnt want to fix from their ends ;)  the notify-osd icons were supposed to be greyscale to re-enforce the concept of the bubbles being non-interactive... or maybe mpt can waive it and postpone this for Lucid ;)
[13:26] <asac> in what sense are we not matching what they suggestd?
[13:26] <asac> i think we should come up with a list of problems
[13:26] <asac> maybe we can address some of them still ... even if not proper
[13:27] <asac> mac_v: right. but was there ever a bug filed?
[13:27] <asac> i had the feeling this just came up recently
[13:27] <mac_v> asac: no one knew where to file it ;)
[13:27] <asac> at least bringing on topic during a desktop meeting would have helped
[13:28] <mac_v> asac: the gpm change [to show the notifications] was done recently and probably that was why this didnt come up earlier
[13:28] <mac_v> jaunty was just blocking the gpm notifications
[13:30] <mac_v> asac: kwwii has been asking about this for nearly 2 weeks :(   mat_t *probably* has more info why the bug wasnt filed
[13:31] <asac>  mac_v so my suggseted patch for notify-osd tries first to get icons with notification- prefix
[13:31] <asac> i felt that the current notification names have not much in common with the icon names used by the apps
[13:31] <asac> so imo that wouldnt really help without theme reshuffeling
[13:32] <asac> like: nm applet used nm-wired .... and the icon is named notification-wireless etc.
[13:32] <asac> so even with my patch the notification-nm-wired wouldnt have been there
[13:33] <mac_v> asac: i agree , that the patch would be the right way to go , though i havent tested the patch to see if it works
[13:33] <mac_v> asac: oh , so that means the notification icons have to be renamed.. that shouldnt be a problem
[13:33] <asac> mac_v: it works. it just requires that the notification theme ships the same icons names used by apps ... just with notification- prefix
[13:33] <asac> i want to celan the patch up to make it even less regression risky. but you can try as it is
[13:34] <asac> mac_v: well. thats what i meant with "icon name reshuffeling"
[13:34] <mac_v> kwwii:  ^ renaming the notify-osd icons as asac mentions  , is there a problem with that?
[13:34] <asac> i am not sure why the current names were choosen ...
[13:34] <asac> i always felt like the idea was to invent a complete new icon name space/standard
[13:35] <asac> anyway. i am recharging my batteries today a bit ;) ... so either lets discuss this later this evening or tomorrow
[13:36] <kwwii> asac, mac_v: not sure if we can get taht in efore release
[13:36] <kwwii> before
[13:36] <asac> kwwii: davidbarth: mat_t: mac_v: we can have a call tomorrow
[13:36] <asac> to see what we can do or not do still
[13:36] <kwwii> asac: ok
[13:37] <asac> anyone in US ... or would 11000 Berlin time work?
[13:38] <asac> 1100 ;)
[13:38] <jcastro> vuntz|away: are you guys shipping gwibber by default?
[13:38] <davidbarth> asac: i'm chatting with kwwii atm
[13:39] <asac> ok thanks.
[13:40] <asac> davidbarth: the notify-osd patch i suggsted would prefer a requested icon name prefixed with notification- ... so gpm sends: gpm-battery-low ... notify-osd would first try notification-gpm-batter-low
[13:41] <asac> if we want to do something like that i will resubmit the patch in a safe fashion
[13:41] <asac> ok ... bb in 2hours
[13:42] <mac_v> asac: just a min
[13:42] <asac> hmm
[13:42] <asac> quick
[13:42] <asac> my body-gpm tells me that i have only 2 minutes battery left ;)
[13:42] <mac_v> asac: why isnt it > gpm-battery-low-notification
[13:42] <asac> mac_v: because its a notify-osd specific thing
[13:42] <asac> mac_v: the suffix would be something upstream source would use
[13:43] <mac_v> asac: oh ,  ok.. i just thought if it was that way the fallbacks should work .. but anyways thanks :)
[13:44] <asac> mac_v: well. appending -notification would be a "normal" way to do it upstream. so we cannot just append that as it might conflict with existing upstream stuff
[13:44] <asac> so upstream ships a gpm-notification icon for something else
[13:45] <mac_v> true
[13:45] <asac> and we tell notify-osd to show "gpm" ... that would make notify-osd to display the gpm-notification icon ...
[13:45] <asac> which might be right ... or wrong ... prefixing is the safe way forward imo
[13:45] <asac> at best not notification- .... but even "notify-osd"
[13:45] <asac> as prefix
[13:46] <asac> also i have to check the fallback mechanism
[13:46] <asac> i tried it in gnome-bluetooth and it seems that it does not work in gtk
[13:46] <asac> e.g. it doesnt do the specced fallback automatically
[13:47] <mac_v> asac: tedg had a similar problem with indicator-session , he's filed a bug in bgo too
[13:47] <asac> i think it should be easy to fix
[13:48] <asac> question is more why it wasnt implemented yet
[13:48] <asac> as it feels to easy ... so it might have been not done for some reason
[13:49] <seb128> asac, it does but not for all functions getting an image
[13:49] <seb128> asac, and you have to set a flag
[13:50] <seb128> asac, ie gtk_icon_theme_load_icon does it
[13:50]  * mac_v doesnt understand why all upstream apps need a patch in the ubuntu versions to use the notify-osd properly , whatever the reasons ;)
[13:52] <seb128> mac_v, because you want to use a different icon that the one used now?
[13:54] <mac_v> seb128: still that doesnt meant something like asac's solution should have been implemented/speced in the start itself
[13:54] <mac_v> mean*
[13:54] <asac> seb128: ok i will check that. i now reread the spec and fallbacks are a bit differently handled than i thought (e.g. no fallback on sppliction level ... only theme level)
[13:54] <seb128> mac_v, right, I agree with that
[13:54] <asac> i think notifiy-osd wants to use special icons ... so it should also try the prefixing as i suggested
[13:55] <seb128> +1
[13:55] <asac> but rather than notification- ... actually notify-osd
[13:55] <asac> and since we need e to shuffle names anyway then we can just do that in the same turn
[13:57]  * mac_v notes asac's body-gpm has extra/hidden battery life ;p 
[14:01] <asac> i am at -20% ;)
[14:01] <asac> anyway ... off for a few hours ... then back checking on bugs and icons :)
[14:06] <hyperair> can anyone running compiz with desktop wall test out something?
[14:06] <hyperair> wall with a 3x2 layout
[14:06] <hyperair> or even 2x2
[14:07] <mac_v> mvo: hi , the "packages out of date" icon in the notification are of the panel , what icon name does it use? is it gtk-warning?
[14:08] <mac_v> or stock_dialog-warning
[14:09] <mat_t> asac: hi
[14:09] <mat_t> asac: what would the call be about?
[14:10] <asac> 15:01 < asac> anyway ... off for a few hours ... then back checking on bugs and icons :)
[14:10] <asac> mat_t: about what to do about notify-osd icons ... and if something in karmic still
[14:11] <mat_t> asac: ok, any specific issues?
[14:11] <asac> read backlog ;)
[14:11] <mat_t> uh
[14:11] <asac> i am out now ... we can chat in 2h ;)
[14:12] <mvo> mac_v: gtk-dialog-warning
[14:12] <mat_t> asac: ok, am quite busy with other stuff atm, but we can chat in 2h (just ping me)
[14:12] <asac> mat_t: you were just named as one pushing hard for getting notify-osd icons
[14:12] <asac> thx
[14:12] <mat_t> heh
[14:12] <mat_t> cool, speak later
[14:13] <mac_v> mat_t: mvo says its the "gtk-dialog-warning" icon , but if it needs a panel icon , "gtk-dialog-warning-panel" would be an ideal... you need to convince mvo :)
[14:13] <mac_v> or kwwii ^
[14:14] <mvo> mac_v: I can change the name is there is a matching icon already
[14:14] <mac_v> mvo: awesome... icon will be ready very soon :)
[14:14] <mvo> eh?
[14:14] <mvo> aren't we in a deep freeze
[14:15] <mvo> and way after ui freeze?
[14:15] <kwwii> mvo: yes, but this can as an email from mark to me just now
[14:15] <kwwii> mvo: asking me to please correct it
[14:15] <kwwii> ;)
[14:15] <kwwii> anyway, there are still other icons issues open :p
[14:17] <mvo> kwwii: aha, thats different than
[14:17] <mvo> kwwii: this paricular icon?
[14:17] <mvo> kwwii: please mail it to me once its there, I upload it today
[14:18] <mac_v> mvo: its this icon > http://imgur.com/O491D , the orange /!\ one
[14:18] <kwwii> mvo: ok, I'll get the icon from mac_v and add it to the theme
[14:18] <kwwii> if we need to rename anything for notify-osd it would make sense to do this as one update
[14:21] <mvo> hm, but this will require a icon theme with this icon name, its not a standard one
[14:21] <mvo> (a standard name)
[14:21] <mvo> that is a bit ugly, I would rather like to include it in u-n then
[14:22] <mvo> so that I have a fallback
[14:22] <mac_v> kwwii: mvo: so the name "gtk-dialog-warning-panel" would be ok ? this allows fallbacks if themes dont have the icon
[14:23] <kwwii> mac_v: yes, that sounds correct
[14:24] <mvo> ok, sorry for my ignorance - you will add somewhere that the fallback for that is gtk-dialog-warning ? so that e.g. xubuntu does get a icon as well?
[14:25] <mvo> or will I have to add this in my code?
[14:25]  * mvo smells its the later
[14:25] <kwwii> mvo: naming the icon that way allows for the other themes to fallback to gtk-dialog-warning
[14:25] <kwwii> you need to add it to your code
[14:26] <kwwii> if *-panel doesn't exist it should fall back to gtk-dialog-warning
[14:26] <mac_v> mvo: it think > <seb128> asac, ie gtk_icon_theme_load_icon does it
[14:26] <mac_v> i*
[14:26] <mvo> I just tried that with a bit of python and I don't get a icon in this case
[14:27] <mvo> >>> import gtk
[14:27] <mvo> >>> icons = gtk.icon_theme_get_default()
[14:27] <mvo> >>> icons.load_icon("gtk-dialog-warning-panel", 16, 0)
[14:27] <mvo> Traceback (most recent call last):
[14:27] <mvo>   File "<stdin>", line 1, in <module>
[14:27] <mvo> glib.GError: Symbol »gtk-dialog-warning-panel« nicht im Thema vorhanden
[14:29] <mvo> seb128: am I using it incorrectly?
[14:32] <seb128> mvo, there is a fallback lookup flag you need to use
[14:33] <mvo> seb128: aha, not exposed in python (or the docs) - thanks
[14:34] <seb128> mvo, http://library.gnome.org/devel/gtk/unstable/GtkIconTheme.html
[14:34] <mvo> yeah, I have it now
[14:34] <seb128> mvo, lookup flags
[14:34] <seb128> ok, good
[14:40] <mvo> kwwii: is there a open bug for this?
[14:47] <pitti> hey rickspencer3
[14:48] <rickspencer3> hi pitti
[14:49] <rickspencer3> we are getting quite close, are we not?
[14:49] <pitti> *shudder* :-)
[14:49] <kwwii> mvo: not sure, I will check
[14:49] <seb128> rickspencer3, hey
[14:49] <seb128> rickspencer3, karmic frozen if that's what you mean
[14:50] <rickspencer3> hi guys
[14:50] <Amaranth> mvo: The gconf plugin interferes with the ccp plugin due to the new system where compiz forces plugins loaded on the command line to stay loaded
[14:50] <seb128> so I'm running with the indicator applet since yesterday just to try again
[14:50] <rickspencer3> seb128, frozen, and looking good
[14:50] <seb128> is anybody else getting the buddy list of messages often not getting focus with compiz?
[14:50] <Amaranth> mvo: and ccsm and such don't work without ccp anyway
[14:50] <kenvandine> rickspencer3, i am getting that crash in desktopcouch now
[14:50] <seb128> ie they open with the request for attention blinking
[14:50] <kenvandine> the 401
[14:50] <kenvandine> debugging with chad now
[14:51] <rickspencer3> kenvandine, oh, other people hit that?
[14:52] <kenvandine> i did now
[14:57] <mvo> kwwii: I commited the change
[14:58] <Amaranth> "Gdk motion event changed behavior in 2.18"
[14:58] <Amaranth> hmm, perhaps that is the problem with flash
[14:58] <Amaranth> If I had the source I could test it :P
[14:59] <kwwii> mvo: ok, so all we need is the icon in the theme named *-panel.png, right?
[15:12] <pitti> seb128: hm, did you tag empathy as uploaded, but forgot to actually upload?
[15:12] <pitti> I don't see 2.28.0.1-1ubuntu6 in karmic or the queue
[15:12] <seb128> pitti, no, I did first thing today
[15:13] <seb128> I must have screwed something
[15:13] <seb128> let me look
[15:13]  * \sh hugs kwwii for giving us users such a nice l&f 
[15:15] <seb128> pitti, I apparently forgot the dput or typoed it
[15:15] <seb128> pitti, doing that now
[15:15] <seb128> kenvandine, pitti: do you know why we have this 30_raise_not_toggle.patch change btw?
[15:16]  * seb128 ponders dropping it
[15:16] <pitti> seb128: I find it confusing, not sure
[15:16] <seb128> I hate it
[15:17] <seb128> I will just roll back to pidgin because of it
[15:17] <seb128> pitti, empathy uploaded btw
[15:18] <pitti> seb128: merci
[15:18] <kenvandine> seb128, that is based on design team
[15:18] <seb128> pitti, it was in my upload queue but with no .upload so I guess I screwed the put call
[15:18] <seb128> kenvandine, do you have a bug about it? do you know who in the design team I should talk with about that?
[15:19] <kenvandine> mpt
[15:19] <kenvandine> there was a bug... pidgin has the same change
[15:19] <seb128> thanks
[15:19] <kenvandine> in pidgin-libnotify
[15:19] <seb128> no pidgin doesn't
[15:19] <seb128> I'm using pidgin because it doesn't
[15:19] <kenvandine> humm
[15:19] <kenvandine> well probably not on the icon
[15:19] <kwwii> mvo: ok, the icon is added to the humanity package at lp:~ubuntu-art-pkg/humanity/release/
[15:19] <kenvandine> but in the indicator it does
[15:20] <seb128> ah could be
[15:20] <kwwii> mvo: can you upload the icon theme when you include your changes?
[15:20] <seb128> anyway not karmic material now
[15:20] <kenvandine> it isn't trivial to split that out in empathy atm
[15:20] <seb128> I will bring that as uds topic
[15:20] <seb128> it breaks upstream behaviour for those who don't use the indicator
[15:21] <seb128> kenvandine, do you know about the buddy list opening non focused and flashing using compiz?
[15:22] <seb128> kenvandine, not sure if that's a compiz bug
[15:22] <seb128> Amaranth, ^
[15:22] <seb128> that happens only when using the indicator though
[15:22] <seb128> not when clicking on the notification area icon
[15:22] <kenvandine> seb128, i have seen that happen with the icon
[15:22] <seb128> so could be a tedg bug
[15:22] <seb128> it happens almost every time with the indicator there
[15:23] <mpt> I reported a bug of that form
[15:23] <Amaranth> if it's not presenting the window correctly compiz will block it
[15:23] <mpt> bug 444467
[15:24] <Amaranth> actually metacity would too but it seems to have a race condition of sorts so it only blocks it every so often
[15:24] <Amaranth> like the polkit window getting focus
[15:24] <kwwii> mvo, pitti: if not, can someone else see that the humanity icons are updated...I just told mark that we got it done ;)
[15:24] <tedg> seb128: I think it may be something related to XEmbed.  I think that the focus stealing protection notices that as a "click in the application" vs. "the application asking to be raised."  I'm thinking we should turn of focus stealing protection by default.
[15:24] <Amaranth> but I don't use empathy (or any other IM program) so this is hard to test
[15:25] <pitti> kwwii: "if not"?
[15:25] <tedg> off that is
[15:25] <seb128> tedg, because having focus stealing your input is so nice?
[15:25] <Amaranth> tedg: And I think you're crazy, that is not happening
[15:25] <seb128> tedg, or because you like to type your password to your im contacts?
[15:25] <tedg> Because fixing it in the Window Manager creates really bad behavior with everything else.
[15:25] <seb128> where?
[15:26] <seb128> the only thing misbehaving there is the indicator
[15:26] <Amaranth> Not having focus stealing prevention creates really bad behavior with everything else
[15:26] <seb128> I've never an issue using launcher, menus, etc
[15:27] <tedg> Okay, the code that we had to steal to make it every reasonable is insane.  We're doing things like resetting event timers, and it still doesn't work right.
[15:27] <kwwii> pitti: if not, please explain to mark why it didn't happen, it was formed as a statement to me from him, not a question
[15:27] <pitti> kwwii: sorry, first time I hear about it
[15:27] <pitti> kwwii: so shall I review the branch and upload?
[15:27] <kwwii> pitti: yeah, I only bugged you cause mvo was busy and hadn't responded yet
[15:28] <kwwii> pitti: just trying to make sure that someone takes care of it
[15:28] <tedg> I think that we should turn off focus stealing protection, and fix the bugs.  I think there are fewer than most people think.
[15:28] <pitti> kwwii: the changelog says "added", but it really changed the icon; isn't that used somewhere else, too? (the name sounds fairly generic)
[15:29] <pitti> kwwii: oops, no; the commit changes Humanity/actions/48/document-export.svg, but the changelog says "Added gtk-dialog-warning-panel.svg"
[15:30] <kwwii> pitti: lol, I forgot to bzr add the icons :)
[15:30] <kwwii> sorry
[15:30] <pitti> kwwii: please pull before, I fixed the changelog
[15:30] <pitti> kwwii: (to "unreleased", and broke long line)
[15:30] <pitti> kwwii: what changed in document-export.svg?
[15:31] <superm1> pitti, i just wanted to make sure that you did see bug 448988, correct?  no one confirmed/triaged or anything and i'm still seeing it with daily builds as far as 10/15
[15:31] <tedg> seb128: The reason that it happens with the indicator is that the indicator isn't doing the action, it's the application getting a signal over dbus and doing it.  Other things like the wnck pager tell the window manager that they're special and thus it should actually listen to them.  So, probably the solution there is to have every app tell the WM that they're panels :)
[15:33] <Amaranth> tedg: are you going to patch every IM app to open their IM windows without focus?
[15:33] <Amaranth> tedg: including skype?
[15:33] <pitti> superm1: I tested it with today's image, and it works fine for me; not for you?
[15:33] <mpt> tedg, I don't think focus stealing prevention is a matter of hiding bugs. As long as we have windows we'll have windows opening at arbitrary times, so we'll need heuristics to guess whether they should be focused or not.
[15:34] <Amaranth> mpt: we have such heuristics
[15:34] <tedg> Amaranth: We've already patched all the default ones...
[15:34] <mpt> Amaranth, indeed
[15:34] <superm1> pitti, i had tested a 10-15 mythbuntu iso in virtualbox.  is it possible that this functionality is just not working in virtualbox then?
[15:34] <Amaranth> tedg: but you can't fix skype
[15:34] <seb128> tedg, to not steal focus? how so?
[15:34] <Amaranth> or any other closed source apps
[15:34] <kwwii> pitti: it was a minor outstanding change which I didn't notice at first
[15:34] <Amaranth> seb128: just change the IM windows to now have focus on map
[15:35] <tedg> mpt: The problem is how little information we have on why the window was opened.  Only the application really knows that.
[15:35] <pitti> superm1: it doesn't work for me in kvm either, but on real iron it does; no clue yet
[15:35] <pitti> (just tried)
[15:35] <Amaranth> s/now/not/
[15:35] <seb128> tedg, why can't you pass the timestamp for the action over dbus?
[15:35] <tedg> seb128: No, mostly we've patched them to try to get focus ;)
[15:35] <kwwii> pitti: ok, now they are included...thanks for checking that
[15:35] <seb128> so the application which get the dbus signal can do it using a correct timestamp
[15:35] <Amaranth> you can set the timestamp in the future before popping up the window
[15:36] <superm1> pitti, interesting.  okay, i'll get some real hardware to try on.  if i have anything that fails, i'll add it to the bug
[15:36] <seb128> which should trigger focus stealing prevention only if you have new events
[15:36] <pitti> superm1: thanks
[15:36] <mpt> tedg, yes, it would be nice to have an API for "this window opened from this object in this window" (not to be confused with transient-for). That could be used for zooming animation for opening the window, as well as for improving the heuristic.
[15:36] <Amaranth> because the main test is "was the last user event before or after this window popped up?"
[15:36] <Amaranth> mpt: that'd be an EWMH addition
[15:37] <tedg> seb128: Hmm, interesting.  Because I hadn't thought of it :)
[15:37] <tedg> I wonder if that'd work.
[15:37] <seb128> why wouldn't it work?
[15:38] <mclasen> Amaranth: I believe the ewmh has stuff for that
[15:38] <seb128> the focus stealing only compare timestamps
[15:39] <tedg> seb128: Well, that's not all it does.  It does things like whether the applications is running and what type of window it is as well.
[15:39] <tedg> Obviously this wouldn't be for Karmic :)
[15:40]  * tedg imagines trying to get that exception through.
[15:40] <Amaranth> tedg: it's simple code, really
[15:41] <superm1> mpt, when you looked at mcc yesterday, were there icons on the buttons on the right?  there was a bug w/ it running in gnome that the icons didn't show up (and it looked like junk in that scenario).  it's been fixed now, and is much prettier
[15:41] <tedg> Amaranth: Uhm, really?  I mean, two dbus interfaces have to change.
[15:41] <Amaranth> tedg: i meant the focus stealing prevention
[15:41] <tedg> Ah, okay.
[15:41] <Amaranth> if you want to see how to get around it
[15:42] <Amaranth> http://git.compiz.org/compiz/core/tree/src/window.c?h=compiz-0.8#n5026
[15:46] <tedg> Amaranth: Simple except that "evalMatch" pretty much has it's own source file as well ;)
[15:47] <mpt> superm1, yes, the buttons were there
[15:47] <mpt> superm1, the icons were there, I mean
[15:47] <superm1> mpt, okay cool
[15:48] <mpt> superm1, but it was still quite confusing, because as soon as I clicked somewhere else in the window I could no longer see which category I was in
[15:48] <superm1> mpt, yeah a bit of deficiency of using buttons since you can't keep the focus on the button and elsewhere in the window
[15:49] <superm1> each of those buttons is actually a separate plugin
[15:50] <rickspencer3> sweet, bughugger works again
[15:50] <rickspencer3> thanks kenvandine
[15:51] <seb128> rickspencer3, is that another tool of yours?
[15:51] <rickspencer3> seb128, yes ... it used to be "bug-zapper" but bdmurray didn't like that name
[15:52] <rickspencer3> all of my apps use desktopcouch, but due to the "bug" that kenvandine and the U1 crew just solved, it couldn't start
[15:53] <seb128> oh ok
[15:55] <diverse_izzue> when i spawn a guest session, my xorg process uses loads of CPU and the systems is extremely sluggish. is that a known bug?
[15:57] <pitti> Riddell: argh, bug 339313 is alive again?
[16:00] <Riddell> pitti: works for me
[16:00] <pitti> Riddell: so should this be downgraded perhaps?
[16:00] <Riddell> pitti: looking at comment 88 it seems to be a problem with the type of password
[16:00] <pitti> yeah, WEP has 3 different password types AFAIR
[16:01] <Riddell> the dialogue only offers two options
[16:01] <tedg> rickspencer3: No PPA? :(  https://launchpad.net/~bug-zapper/+ppa-packages
[16:01] <rickspencer3> tedg, use bughugger in my ppa
[16:02] <rickspencer3> bug-zapper is dead, but I haven't had a chance to bury the body yet
[16:02] <tedg> rickspencer3: Ah, okay, found it.
[16:02] <tedg> rickspencer3: Thanks!
[16:02] <rickspencer3> ted, it's a quickly app now
[16:03] <rickspencer3> so you can use quickly edit, quickly glade, quickly package, quickly release, etc...
[16:04] <Riddell> pitti: I'll confirm with upstream but I think that bug should be closed and another one opened for this paticular problem
[16:04] <pitti> Riddell: *nod*; thanks
[16:07] <jbicha> is xforcevesa broken in Karmic?
[16:07] <superm1> jbicha, it should work as of the dailies about a week ago
[16:07] <jbicha> ok I'll try again, thanks
[16:08] <superm1> jbicha, just checked, 10-09 or later will have it
[16:08] <andreasn> mpt, quick software center question. Where does this dialog come from? http://dl.getdropbox.com/u/184285/Screenshot-softwcenter.png
[16:08] <superm1> jbicha, (bug 423969)
[16:09] <superm1> andreasn, python-aptdaemon-gtk isn't it?
[16:09] <jbicha> I thought I had tried after that date, but I'll try again with today's build & see if I still have issues, thanks
[16:09] <mpt> andreasn, policykit-gnome, via aptdaemon
[16:09] <mpt> andreasn, and what superm1 said
[16:09] <andreasn> mpt, thanks!
[16:11] <mpt> andreasn, I redesigned the policykit-gnome alert a bit, but Robert Ancell didn't have time to implement it
[16:11] <mvo_> kwwii: hey, sorry, disconnected - shoudl I sponsor the iocn theme update? what is the lp url?
[16:12] <awe> pitti: do we ever spin a development release between beta & final?
[16:12] <andreasn> mpt, oh, that's great! because I can't really understand what it says
[16:12] <pitti> awe: just a release candidate (next Thursday)
[16:12] <awe> pitti, can people download it?
[16:13] <kwwii> mvo_: lp:~ubuntu-art-pkg/humanity/release but you might want to check with pitti, after I couldn't find you I bugged him ;)
[16:13] <mpt> andreasn, unfortunately, I never specified the primary text for that particular alert
[16:13] <kwwii> mvo_: I take that back, pitti just uploaded it
[16:13]  * kwwii *hugs* pitti, mvo_ 
[16:13]  * pitti hugs kwwii
[16:14] <mvo_> kwwii: cool, I upload update-notifier then too
[16:15]  * \sh looks for a documentation about the contents of get_style().base[gtk.STATE_NORMAL] looks like that this is the cause for bug #440030
[16:15] <kwwii> mvo_: excellent, thanks
[16:16] <andreasn> mpt, is there a bug open about it?
[16:16] <mpt> andreasn, not that I know of, you're welcome to report it
[16:16] <andreasn> sure
[16:18] <awe> pitti: the new pulseaudio drops rtkit as a recommends, but it doesn't actually get removed unless you explicitly do so; or install from scratch
[16:19] <pitti> awe: hm, I guess apt-get autoremove will?
[16:19] <mpt> Sounds like another case for ... Recommends-Removing :-)
[16:19] <pitti> mpt: that's called "autoremove" :)
[16:19] <awe> pitti: just wanted to make sure some folks besides myself, TheMuso, and Daniel run it.  ;)
[16:19] <awe> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/406702
[16:26] <dtchen> alternately, we could do crummy things with versioned conflicts (ugh)
[16:28] <seb128> is there any issue to have it installed?
[16:29] <awe> seb128, yea...it fills your daemon.log with InvalidParam log messages & wastes cycles ( it's a daemon )
[16:30] <seb128> use a conflicts
[16:32] <awe> ok.  that might not be a bad idea for now, just to get the testing coverage.  I'll ping TheMuso.  dtchen, what do you think?
[16:35] <awe> seb128: asac asked me to ping you re: your nm-connection-editor re-connect problem.  are you still seeing it, and if so, is there a bug #?
[16:37] <seb128> awe, yes
[16:38] <seb128> awe, I've no bug number
[16:38] <seb128> I just tried though and NetworkManager segfault
[16:38] <awe> seb128, can you explain then?  ;)
[16:38] <seb128> NetworkManager segfaults when I start the editor
[16:38] <seb128> let me get you the stacktrace
[16:39] <awe> can you give me a quick re-cap of the scenario?  I thought it was nm-connection-editor -> wired tab -> select eth0 -> click edit?
[16:39] <seb128> no
[16:40] <seb128> it's right click on the notification area, edit -> nm crash
[16:41] <awe> hmm, that's bad...  i assume you updated this morning?
[16:41] <seb128> no
[16:41] <seb128> did you fix a such bug?
[16:41] <awe> nope
[16:41] <awe> send me the stack trace though, and i'll take a look
[16:42] <awe> i've been looking at that code recently
[16:43] <awe> seb128, does it crash *every* time?
[16:43] <seb128> yes
[16:43] <seb128> #0  IA__g_type_check_instance_cast (type_instance=0x9ca1520, iface_type=80)
[16:43] <seb128>     at /build/buildd/glib2.0-2.22.2/gobject/gtype.c:3728
[16:43] <seb128> #1  0x00ecd0c8 in polkit_authority_check_authorization_async (
[16:43] <seb128>     authority=0x9ca1520, subject=0x9c9c190,
[16:43] <seb128>     action_id=0x80c5e60 "org.freedesktop.network-manager-settings.system.modify", details=0x0, flags=POLKIT_CHECK_AUTHORIZATION_FLAGS_NONE, cancellable=0x0,
[16:43] <seb128>     callback=0x80accf0, user_data=0x9ce3428) at polkitauthority.c:348
[16:43] <seb128> hum
[16:44] <seb128> awe, http://paste.ubuntu.com/294059/
[16:46] <seb128> awe, bug #434391
[16:46] <awe> seb128, ok, thanks!
[16:46] <seb128> bug #438574
[16:46] <seb128> those are similar
[16:46] <seb128> awe, let me know if you need details
[16:46] <awe> ok
[16:46] <dtchen> awe: if you have to use Conflicts, then you have to use it (:
[16:47] <awe> dtchen, I think it just might be the best way to get testing coverage before final.  sigh...
[17:05] <mac_v> seb128: hadness has replied on the volume mute bug report > https://bugzilla.gnome.org/show_bug.cgi?id=598459
[17:09]  * mpt growls at djsiegel1 because gnome-do is using 196% CPU
[17:10] <djsiegel1> mpt: please talk to the current maintainer of GNOME Do. Do was a mean lean machine when I handed over the project, thank you very much.
[17:10] <bratsche> Hey, anyone know what's up with bug #197290?  Is there some way to see the configure output where this gets built for i386 and see if the "_FILE_OFFSET_BITS value needed for large files..." line says 64?
[17:11] <djsiegel1> mpt: but word on the street is that the Firefox plugin is affected by a nasty SQL bug, so disabling that should restore normalcy.
[17:11] <\sh> bratsche, use the source?
[17:11] <rickspencer3> seb128, pitti - imagine this situation ...
[17:12] <rickspencer3> you buy a dell mini10v with windows on it ...
[17:12]  * seb128 almost did
[17:12] <rickspencer3> a friend convinces you to try Ubuntu on it ...
[17:12]  * djsiegel1 sees that GNOME Do is running at 0% CPU, 27mb of RAM on my machine :)
[17:12] <rickspencer3> you install Ubuntu ...
[17:12] <rickspencer3> because we disabled tap to click by default, it is all but unusable
[17:12] <rickspencer3> thoughts?
[17:13] <Laney> the mouse button on my macbook is broken
[17:13] <pitti> rickspencer3: "all but unusable" sounds "good" to me
[17:13] <pitti> rickspencer3: is that a praise or a bug report?
[17:13] <Laney> which wil make it difficult to try karmic ;)
[17:13] <rickspencer3> pitti, as in "you can't click with the mouse as there is no physical mouse button"
[17:13] <pitti> rickspencer3: uh?
[17:14] <rickspencer3> there is no separate mouse button
[17:14] <bratsche> \sh: My systems are both x86-64 and this only affects i386, so I don't think I can check here.  I was hoping the configure output would be logged on a build server somewhere I could look or something.
[17:14] <rickspencer3> (some macbooks are like this too)
[17:14] <pitti> who in the world builds stuff like that?
[17:14] <kklimonda> pitti, it's the new trend - saves them a few bucks ;)
[17:14] <\sh> bratsche, on launchpad you will find all build logs for evolution
[17:14] <rickspencer3> uh, one of the strongest proponents of pre-installing linux in the world?
[17:14] <Laney> the macbooks have mouse buttons
[17:14] <Laney> well, just one
[17:15] <pitti> kklimonda: and costs the user tons of headache and frustration?
[17:15] <rickspencer3> I <3 Dell, so I;'m not going to diss them
[17:15] <rickspencer3> well, in any case, it is what it is
[17:15] <pitti> rickspencer3: and I thought Apple was bad for just having one button; but seems you can top even that :)
[17:15] <pitti> rickspencer3: do you have such a  machine at hand?
[17:15] <rickspencer3> pitti, I would not be surprised if this continues
[17:15] <bratsche> Launchpad is a big place.  That's why I was asking.
[17:15] <rickspencer3> pitti, no
[17:15] <pitti> rickspencer3: I wonder whether we can enable it by default if the device says that it doesn't have buttons
[17:15] <\sh> bratsche, http://launchpadlibrarian.net/33091255/buildlog_ubuntu-karmic-i386.evolution_2.28.0-0ubuntu4_FULLYBUILT.txt.gz <- latest evolution build on i386
[17:15] <bratsche> Thanks.
[17:16] <rickspencer3> pitti, http://arstechnica.com/open-source/news/2009/08/quickly-new-rails-like-rapid-development-tools-for-ubuntu.ars
[17:16] <rickspencer3> in this case, it is enabled by default because it is pre-installed
[17:16] <rickspencer3> oops, wrong link
[17:16] <seb128> rickspencer3, tseliot had a patch for that
[17:16] <rickspencer3> http://arstechnica.com/open-source/news/2009/10/pygmy-portable-dell-mini-10v-with-the-ubuntu-moblin-remix.ars
[17:16] <seb128> rickspencer3, 2 days ago or something
[17:16] <seb128> tseliot, did that got uploaded?
[17:16] <rickspencer3> well, I am opening discussion because I think we need to reconsider our position
[17:17] <pitti> rickspencer3: if it's built with any sanity, "lsinput" would say that the mouse can't do EV_KEY, then we could enable it based on that
[17:17] <kklimonda> pitti, I guess it depends on how well tap to click works - on OSX it's really good so you don't miss buttons :)
[17:17] <seb128> rickspencer3, pitti: guys, that's a bug with a patch
[17:17] <rickspencer3> well, I guess it is technically enabled to click, but:
[17:17] <rickspencer3> Although the keyboard in the 10v is a laudable improvement, the touchpad is a pitiful failure. The design is so fundamentally flawed that I can't believe it ever made it off the drawing board and into a product.
[17:17]  * seb128 search for bug number
[17:17] <pitti> kklimonda: well, from my POV can't work well, ever; it's a pain in the butt
[17:17] <rickspencer3> so essentially, you *can* tap, if you can figure it out
[17:18] <rickspencer3> pitti, personally, I hate tap to click, and turn it off first thing
[17:18] <seb128> rickspencer3, https://bugzilla.gnome.org/show_bug.cgi?id=598287
[17:18] <rickspencer3> and I know it is confusing to users ...
[17:18] <rickspencer3> but in terms of Ubuntu working universally, I think we may need to reconsider this
[17:18] <pitti> seb128: yay, that's pretty much what I had in mind
[17:18] <seb128> rickspencer3, do you read me? ;-)
[17:19] <pitti> rickspencer3: sure, if there are no buttons, enabling it is a no-brainer
[17:19] <rickspencer3> seb128, yes, reading the bug
[17:19] <rickspencer3> seb128, is that already in?
[17:19] <seb128> tseliot, any reason you didn't upload to karmic?
[17:19]  * rickspencer3 wonders if the dell reports that it has buttons
[17:19] <seb128> rickspencer3, no, it's not
[17:19] <seb128> rickspencer3, tseliot came with it 2 days ago
[17:20] <seb128> but didn't upload apparently
[17:20] <kklimonda> pitti, your main concern about tap to click is the user's confusion or the precision of the tap itself?
[17:20] <pitti> kklimonda: it's "it exists"
[17:20] <rickspencer3> seb128, if this works on the 10v, could we consider it, or is it too risky?
[17:21] <pitti> kklimonda: I keep tapping on the thing while typing, or you accidentally tap when you don't mean to, etc.
[17:21] <pitti> rickspencer3: it doesn't look risky to me; the drawback is that you can't manually disable it any more
[17:21] <pitti> rickspencer3: although disabling it is probably like "shooting yourself in the foot"
[17:21] <seb128> rickspencer3, the patch? I though it was uploaded already, we want it for karmic
[17:21] <rickspencer3> oh
[17:22] <seb128> but I'm fine changing the default too if you want
[17:22] <kklimonda> pitti, btw, if you are already here - could you comment on https://bugs.edge.launchpad.net/transmission/+bug/451554/comments/4 ?
[17:22] <rickspencer3> seb128, could I ask you to follow up with tseliot and let me know the status
[17:22] <seb128> it's one of those things I'm a bit nervous about
[17:22] <seb128> seems every other os has that on by default
[17:22] <seb128> and I'm wondering if we should not to be in the less surprise case
[17:22] <kklimonda> pitti, you don't have to comment there, you can answer me here and I'll forward it :)
[17:22] <seb128> rickspencer3, will do
[17:22] <rickspencer3> well, if the patch is too risky, maybe we should joust turn tap to click on by default
[17:22] <rickspencer3> again
[17:23]  * rickspencer3 shudders
[17:23] <pitti> rickspencer3: I'd prefer the case-by-case basis TBH
[17:24] <rickspencer3> pitti, right, but it seems to me that simply switching the default is easy and low risk (consider this will be after freeze)
[17:25]  * ccheney catching up on the backscroll, yea mini 10v has 'buttons' but they are so hideous you want to die before using them
[17:25] <ccheney> because they are part of the touchpad itself and so you can't click without moving your cursor
[17:25] <rickspencer3> ccheney, apparantly they are confusing too, people can't figure out to click
[17:25] <pitti> rickspencer3: I'd like the patch to be confirmed to work on the 10v, yes
[17:26] <seb128> rickspencer3, the consensus on the list at beta time seemed seem to be: tap-to-click on + the option to disable on typing
[17:26] <seb128> no?
[17:26] <ccheney> rickspencer3: heh, you have to press down on the touchpad hard enough to actually click it, its physical click on the touchpad itself
[17:26] <pitti> rickspencer3: it looks safe, but it's not obvious whether it will actually work
[17:26] <rickspencer3> I think we should go with what seb128 said
[17:26] <ccheney> not like tap to click which all touchpads do (outside ubuntu)
[17:26] <rickspencer3> we could do that with like two gconf changes I think
[17:26] <rickspencer3> and satisfy most users
[17:26] <rickspencer3> thoughts?
[17:27] <seb128> ok, I suggest:
[17:27] <pitti> rickspencer3: so, I don't have a strong enough opinion on "on by default" to fight for it (I know where to disable it, after all)
[17:27] <ccheney> so with tap to click disabled did we also disable multitouch (eg scrolling etc as well)?
[17:27] <seb128> -  adding tseliot patch it's correct
[17:27] <seb128> - enable tap-on-lick
[17:27] <pitti> rickspencer3: I don't know whether it's "most users", it seems people complain either way
[17:27] <rickspencer3> pitti, correct
[17:27] <pitti> seb128: both?
[17:27] <seb128> - enable "don't allow tapping while typing"
[17:27] <rickspencer3> well, people complain when it's off, and file bug reports when it is on
[17:27]  * pitti chuckles, "tap on lick"
[17:27] <pitti> now, that will look funny
[17:27] <seb128> pitti, well tseliot's change is a "don't shot you in the foot"
[17:28] <seb128> pitti, lol
[17:28] <rickspencer3> ok, seb128 can I ask you a favor?
[17:28] <pitti> seb128: an absolute "yay" for disabling the touchpad completly while you are typing
[17:28] <pitti> that's actually my biggest concern about it as well
[17:28] <rickspencer3> assume that we would like people installing Ubuntu on a 10v to have a good experience
[17:28] <rickspencer3> despite what some may consider not so great hardware
[17:29] <ccheney> and maybe even disable the physical buttons on the 10v, if anything :)
[17:29] <rickspencer3> can you make a recommendations for how to accommodate that in a low risk fashion in Karmic if possible?
[17:29] <seb128> rickspencer3, ok
[17:29] <rickspencer3> seb128, like get back to us tomorrow on what you think we should do?
[17:29] <rickspencer3> seb128, thanks
[17:29] <seb128> will do
[17:29] <rickspencer3> pitti, does that sound ok?
[17:29] <ccheney> i have a 10v if anything needs to be tested
[17:29] <seb128> rickspencer3, you're welcome
[17:30] <pitti> rickspencer3: absolutely
[17:30] <pitti> rickspencer3: so, I'm all for enabling that on the 10v, I don't have a very strong opinion about "enable generally" or "apply patch"
[17:30] <ccheney> also have a regular old style 10 but i think those aren't supported by karmic
[17:31] <rickspencer3> "enabling generally" seems to be what the community suggests (though not in 100% universally)
[17:34] <tseliot> seb128: I'm here
[17:34] <seb128> right, community argued that it's the less surprising behaviour
[17:34] <ccheney> enabling generally does keep us with what users except (whether they actually like that default or not)
[17:34] <ccheney> seb128: yea
[17:34] <seb128> since any other os does that
[17:34] <seb128> and it will look broken hardware otherwise
[17:34] <seb128> tseliot, hey, any reason you didn't get your g-s-d fix in karmic?
[17:35] <jbicha> superm1: I tried booting with today's daily-live CD & I got all sorts of squashfs errors and it refuses to load X
[17:35] <seb128> jbicha, try #ubuntu
[17:35] <jbicha> from USB
[17:35] <tseliot> seb128: the one which enables tap-to-click when no physical buttons are available?
[17:35] <seb128> tseliot, yes
[17:36] <jbicha> but isn't it a problem if the daily CD builds don't work?
[17:36] <tseliot> seb128: no, I filed a bug report upstream but I didn't uploaded. I thought you wanted some kind of confirmation from upstream
[17:36] <seb128> tseliot, oh no, could you upload?
[17:37] <seb128> tseliot, the change looks fine, I just wanted to make sure it goes upstream too
[17:37] <seb128> tseliot, the change looks fine, I just wanted to make sure it goes upstream too
[17:37] <seb128> ups, focus issues
[17:37] <tseliot> seb128: ah, ok
[17:37] <tseliot> here's the debdiff http://albertomilone.com/ubuntu/karmic/distro/gnome-settings-daemon_2.28.0-0ubuntu4.debdiff
[17:37] <seb128> tseliot, thanks
[17:37]  * tseliot is not a core-dev yet and can't upload packages
[17:38] <tseliot> np
[17:38] <seb128> tseliot, right, I forgot about that, thanks
[17:38] <tseliot> :-)
[17:41] <pitti> kklimonda: in general, for SRU we prefer cherrypicked patches for data loss/security/very important bugs only
[17:41] <pitti> kklimonda: we made some concessions in the past for updating to microversions (especially for LTSes), but since karmic isn't LTS we'll be pretty strict
[17:44] <asac> seb128: the other bug you had before was that it reconnects when you open the editor
[17:44] <seb128> asac, well it seems to reconnect but it's nm crashing
[17:44] <asac> seb128: the connection editor crashes? or the nm-applet (those are different processe)
[17:44] <seb128> asac, see IRC log
[17:44] <Amaranth> hrm, no more tedg
[17:45] <seb128> asac, /usr/sbin/NetworkManager
[17:45] <seb128> asac, I didn't notice before because it just makes the applet spin and connect again
[17:45] <asac> oh
[17:45] <asac> even the backend
[17:45] <asac> k
[17:45] <Amaranth> evalMatch is for skipping focus stealing prevention, not important for what he is trying to do
[17:45] <asac> yeah
[17:45] <seb128> but apport triggered at the same time today
[17:45] <asac> that explains it a bit
[17:45] <seb128> cf the 2 bugs I gave before
[17:45] <mvo_> Amaranth: did you see my earlier question re> gconf module?
[17:45] <seb128> they have the same stacktrace
[17:46] <Amaranth> mvo_: yeah, but gconf interferes with ccp on upgrades (even though gnome-wm was fixed) and the rest of our tools only work with ccp
[17:46] <Amaranth> mvo_: and ccp just uses the same gconf keys/layout as the gconf plugin anyway so it's an easy transition for anyone who was actually patching compiz-wrapper to not use ccp before
[17:47] <mvo_> Amaranth: ok, I guess its ok to let people use ini otherwise - what was the output from the -unsupported discussion?
[17:47] <kklimonda> pitti: ok, thanks.
[17:47] <mvo_> Amaranth: should we have it in the compiz ppa ? or just not at all
[17:48] <pitti> kenvandine: are you working on bug 438365? If you are over-busy, need help with that?
[17:50] <Amaranth> mvo_: I would say not at all
[17:50]  * mvo_ nods
[17:50] <Amaranth> mvo_: only thing in there is useless eyecandy that is often broken
[17:50] <mvo_> but *atlantis* ;)
[17:51] <Amaranth> mvo_: I don't want anymore compiz crash reports :P
[17:51] <mvo_> heh :)
[17:51] <mvo_> yeah, I figured that
[17:51] <mvo_> since you are the bugmaster its your decision, I'm fine with that
[17:51]  * mvo_ hugs Amaranth
[17:51] <Amaranth> mvo_: if they're worth having they move to extras or main :)
[17:51] <mvo_> sounds like its time for compiz sponsoring
[17:51] <Amaranth> although I don't think any have yet
[17:52] <mvo_> did you upgrade the plugins bzr tree too?
[17:52] <Amaranth> I updated everything except python-ccs, ccsm, and emerald
[17:52] <Amaranth> kconfig didn't actually get an update and I don't think those did either
[17:52] <Amaranth> mvo_: they all have working watch files now too so it makes it easier for you to get them ready to upload :)
[17:53] <mvo_> great, many thanks
[17:53] <mvo_> I noticed the watchfile update in core
[18:01] <seb128> mvo_, waouh
[18:01] <seb128> mvo_, 1.0!
[18:01] <seb128> champagne ;-)
[18:01]  * seb128 hugs mvo_
[18:01] <kenvandine> pitti, well Rick had volunteered me for that one
[18:01] <kenvandine> but i know nothing about erlang :)
[18:01] <kenvandine> or if we care to build it with wxWidgets
[18:02] <pitti> kenvandine: ok, please assign to me if you are overloaded
[18:02] <kenvandine> i feel pretty good about empathy now though, could probably look at it
[18:02] <\sh> hmmm...my ejabberd written in erlang doesn't have any gui ;)
[18:02] <kenvandine> but i suspect you could make a call on it better than me :)
[18:02] <pitti> kenvandine: yeah, I guess it ends up with "disable wx support"
[18:03]  * kenvandine really doesn't like empathy for irc
[18:03] <kenvandine> and it really doesn't play well with the indicator
[18:03] <kenvandine> pitti, that was what i was thinking
[18:03] <\sh> kenvandine, empathy just parts  all channels on my dircproxy
[18:04] <mvo_> seb128: haha - I though people would like it :)
[18:05] <kenvandine> \sh, it is working ok for me, i use znc
[18:05] <kenvandine> but
[18:05] <seb128> mvo_, btw your schemas typo fix, did you unfuzzy the translations?
[18:05] <kenvandine> i get indicator events constantly
[18:05] <kenvandine> cause we just see those as incoming events
[18:05] <mvo_> seb128: no :(
[18:05] <seb128> mvo_, :-(
[18:05] <mvo_> seb128: its "just" internal in gconf, its still bad
[18:05] <kenvandine> not sure if we can selectively only add the indicator for highlights
[18:06] <seb128> mvo_, so you fix a typo to break all translations
[18:06] <seb128> doesn't seem a good deal
[18:06] <\sh> kenvandine, yepp...but parting channels from a proxy is not ok, too..but this could be a general design bug regarding connecting to irc services
[18:06] <seb128> mvo_, well you trade an english typo against no translation
[18:06] <seb128> but your call
[18:06] <kenvandine> \sh, it doesn't part mine
[18:06] <mvo_> seb128: now I sleep bad at night
[18:06] <mvo_> seb128: I will unfuzzy manually
[18:06] <\sh> kenvandine, hmmm...-ESTRANGE
[18:08]  * \sh can't change irc proxies every day ;) but I could test it locally at home
[18:09] <kenvandine> znc seemed to keep me joined
[18:09] <kenvandine> perhaps it just ignores the clients request to part :)
[18:10] <\sh> kenvandine, good point ;)
[18:10]  * seb128 hugs mvo_
[18:11] <\sh> am I wrong, or was the last upload/sync  of erlang during hardy time?
[18:11] <seb128> mvo_, don't bother that's just a gconf description
[18:11] <seb128> mvo_, to be fair none of those were translatable in jaunty and karmic
[18:11] <seb128> mvo_, we tracked the bug a week ago, nobody noticed
[18:11] <seb128> mvo_, or rather they were translatable but the gettext change were buggy so no translation
[18:12] <mvo_> seb128: ha! ok
[18:13] <asac> seb128: hah. found the bug i think ;)
[18:13] <asac> preparing a polkit patch
[18:13] <\sh> kenvandine, erlang source needs wxwidgets because of wxerlang, regarding some changelog entries of erlang
[18:13] <seb128> asac, thanks
[18:14] <davidbarth> asac: just a note to say that MacSlow is on your patch and integrates that now to deal with the gpm/nm icon naming issue
[18:14] <seb128> I'm off for sport soon but I can test later
[18:14] <\sh> erlang-wx is the result of all this
[18:15] <asac> davidbarth: oh ... i wanted to submit a safer approach
[18:15] <asac> with less potential for regressions
[18:15] <asac> (not that its risky)
[18:15] <kenvandine> \sh, yeah... but that means we need to move wx to main
[18:16] <davidbarth> asac: there are some corner cases, but MacSlow spotted them and will have a test to catch that
[18:16] <MacSlow> asac, I'm about to push a new branch updated to apply cleanly to notiyf-osd/karmic
[18:16] <MacSlow> asac, sofar intended test-cases work as intended now
[18:17] <MacSlow> asac, I've yet to put that through "make distcheck"
[18:17] <asac> MacSlow: i ran both iirc
[18:17] <asac> MacSlow: one second
[18:17] <asac> let me tell you what improvement i wanted to resubmit
[18:18] <asac> http://bazaar.launchpad.net/~asac/notify-osd/theme-icon-prefix/revision/407
[18:18] <asac> that was the patch
[18:18] <asac> the idea was to use "notify-osd-" as the prefix
[18:18] <asac> and
[18:19] <asac> more important, dont put the _from_path logic in a separate function
[18:19] <asac> but rather introduce _from_theme
[18:19] <asac> in that way there is no contract change
[18:19] <asac> so no regressions as we explicitly move those few calls to the new _from_theme function
[18:19] <davidbarth> asac: we discussed with kwwii and want to stick to the notification-* prefix to keep things simple
[18:20] <asac> davidbarth: MacSlow: ^^ ... if you want me to resubmit that branch
[18:20] <asac> davidbarth: ok. though we need to reshuffle quite a lot
[18:20] <davidbarth> asac: but that does not impact upstream keeping its naming convention
[18:20] <asac> in the long run the notification- prefix should be a proper fdo namespace though ... so we should move to notify-osd- at some point
[18:20] <asac> i dont care if that happens for this cycle or next :)
[18:20] <asac> i just thought that you have all icons in names that are != PREFIX-upstream-name
[18:21] <asac> so you have to rename all anyway
[18:21] <davidbarth> asac: ie, gpm and nm can keep the same names, and we can have n-osd map that on the fly with specific icons if the names match (with the notification- prefix)
[18:21] <asac> that was just my thought. reality can diverge - havent checked how well the current notification- names match upstream names
[18:21] <asac> davidbarth: yes. my point was, that the notification- prefix is unlikely to match atm ... and you have to rename most notification- icons anyway
[18:21] <asac> so you can directly use notifiy-osd- prefix
[18:22] <davidbarth> asac: that's a different problem, but that we cannot remap on the fly without a translation table
[18:22] <asac> which would be much cleaner and would keep the way open to get notification- namespace an official fdo thing
[18:22] <davidbarth> asac: we cannot rename all our n-osd specific icons at this stage
[18:22] <asac> davidbarth: right. you need links
[18:22] <asac> so i say: create those links with notify-osd prefix
[18:22] <asac> not notification- ... and then next cycle think about what to do in long run
[18:23] <davidbarth> asac: do you have a list of the required links, ie the mismatches between icons that are not patched anymore (or that where never patched, but for which we had no particular icons)
[18:24] <davidbarth> asac: ? ^^
[18:24] <\sh> going home
[18:25] <asac> davidbarth: i do not have that. but someone has to do that anyway ... not a notification- vs. notify-osd- issue
[18:25] <asac> i think at this time in cycle we should pick the most important apps
[18:25] <asac> and do it for those
[18:26] <asac> seb128: http://people.canonical.com/~asac/tmp/0001-authority-g_object_ref-authority-when-returning-sing.patch
[18:33] <asac> seb128: update again please ;)
[18:33] <asac> that patch
[19:02] <hyperair> does compiz randomly switch your windows' workspaces if you switch workspaces rapidly?
[19:02] <hyperair> something like ctrl+alt+left<hold> or the other way
[19:14] <Amaranth> hyperair: never seen that, no
[19:14] <hyperair> Amaranth: could you try reproduce it?
[19:15] <hyperair> 3x2 desktop wall layout
[19:15] <Amaranth> hyperair: if I window wants your attention it may get pulled on to the current workspace
[19:15] <Amaranth> s/I/a/
[19:15] <hyperair> nono that's not what i meant
[19:15] <hyperair> i've a terminal open
[19:15] <hyperair> in the middle top workspace
[19:15] <hyperair> i move to the lower row
[19:15] <hyperair> and i hold down ctrl+alt+rightarrow
[19:15] <hyperair> note that desktop wall's preview is enabled
[19:16] <hyperair> after a while i notice my terminal shifts to the left or right
[19:16] <hyperair> if i use ctrl+alt+up/down, my terminal shifts to the top or bottom
[19:16] <hyperair> and back
[19:16] <hyperair> strange behaviour
[19:16] <hyperair> i just tried again with more windows
[19:17] <hyperair> terminal on top left, firefox on top middle, dia on bottom middle. then i pressed ctrl+alt+up and held it.
[19:17] <hyperair> i noticed that they flip rows together
[19:17] <Amaranth> you have wraparound enabled then?
[19:18] <hyperair> yes i have
[19:18] <hyperair> does the issue not occur without?
[19:18] <Amaranth> obviously not, you can't move enough :)
[19:18] <hyperair> oh right
[19:18] <hyperair> hahahah
[19:19] <Amaranth> hyperair: The pager and the live preview sometimes show them moving but when I stop they didn't actually move
[19:19] <hyperair> try again
[19:19] <hyperair> if you stop at the correct time, it'll move =\
[19:19] <hyperair> it really depends when you stop imo
[19:19] <Amaranth> ah, I just got it to flip from top to bottom
[19:19] <Amaranth> but I can't get it to flip horizontally
[19:19] <hyperair> hmm
[19:20] <hyperair> try putting a window on the top row
[19:20] <hyperair> and going to the bottom row
[19:20] <Amaranth> it only does it for a single viewport change somewhat randomly and when holding you're doing about 5 of those a second
[19:20] <Amaranth> I did that
[19:20] <hyperair> and then hold ctrl+alt+left/right
[19:20] <Amaranth> I did that
[19:20] <Amaranth> it only does it for a single viewport change somewhat randomly and when holding you're doing about 5 of those a second
[19:21] <hyperair> 5 a sec?
[19:21] <hyperair> hmm
[19:21] <hyperair> seems to require more for me
[19:21] <Amaranth> at least
[19:21] <hyperair> ah
[19:21] <Amaranth> well I just got it to flip them horizontally too
[19:21] <hyperair> haha
[19:21] <Amaranth> they were all on the bottom row and I was on the bottom row
[19:21] <hyperair> i see
[19:21] <Amaranth> when they're on top and I'm on bottom it doesn't happen
[19:21] <hyperair> maybe i should just go back to using the cube for the time being =\
[19:22] <Amaranth> file a bug but I'm not going to look into it for karmic
[19:22] <hyperair> o noes
[19:22] <Amaranth> Who uses live preview and wraparound? You and onestone :P
[19:22] <hyperair> onestone?
[19:22] <Amaranth> compiz developer, he added those features :P
[19:22] <hyperair> ahahah
[19:22] <hyperair> well i like wraparound
[19:23] <hyperair> this way, i get to have one-key access to all workspaces in the same row
[19:23] <Amaranth> Does it happen if you move slowly?
[19:23] <hyperair> and at most two key accesses to workspaces on the lower row
[19:23] <hyperair> no it doesn't
[19:23] <hyperair> it doesn't happen unless i hold it down
[19:23] <hyperair> i guess it's kinda minor then
[19:23] <Amaranth> yeah
[19:24] <Amaranth> something to fix but not something people are actually going to run into (99% of the time)
[19:24] <hyperair> yeah
[19:24] <hyperair> say, since compiz is moving to c++ maybe i should go dig in the code and take a look sometime
[19:24] <hyperair> hahah
[19:24] <hyperair> another thing for my already loaded todo list
[19:24] <Amaranth> we won't have a C++ version in Ubuntu until 10.10
[19:25] <hyperair> wow two releases down the road eh
[19:25] <Amaranth> hyperair: yeah, unless they can guarantee 0.10.2 will be out before lucid
[19:25] <hyperair> has it achieved feature parity yet?
[19:25] <Amaranth> 0.9 is going to be a bumpy ride, 0.10 will almost certainly have regressions from 0.8.x (or be late)
[19:25] <Amaranth> no
[19:25] <hyperair> yowch
[19:26] <Amaranth> still a few plugins missing
[19:26] <hyperair> which ones?
[19:26] <Amaranth> I think mainly cube, all plugins using cube, and group
[19:26] <hyperair> heh?
[19:26] <hyperair> does cube get ignored that much?
[19:26] <Amaranth> The guy that was porting it got it supposedly done then disappeared
[19:26] <hyperair> D=
[19:26] <Amaranth> So no one else working on it waiting for him
[19:26] <hyperair> what a waste!
[19:27] <Amaranth> and compiz itself has been pretty much ignored from about february of this year until 2 months ago...
[19:27] <hyperair> hmm
[19:27] <Amaranth> everyone got busy
[19:27] <hyperair> what will become of compiz once gnome-shell takes over, though?
[19:28] <Amaranth> right now the hope is that it doesn't ;)
[19:28] <Amaranth> gnome-shell is going to be pain on LTSP and such
[19:28] <Amaranth> and nvidia and newer ati users will get a broken experience at least until they install proprietary drivers
[19:30] <Amaranth> and I don't like the activities thing
[19:30] <Amaranth> I used gnome-shell for a couple days, felt just as jarring at the end as the beginning
[19:30] <hyperair> i agree
[19:31] <hyperair> well i didn't use it for a couple of days
[19:31] <hyperair> just one hour or so
[19:31] <Amaranth> I do like what they're doing with zeitgeist integration though
[19:32] <Amaranth> but there are only two things gnome-shell does that would need interaction between the WM and the panel like they claim
[19:32] <Amaranth> and I don't think they even do the second one yet (or even plan to)
[19:32] <hyperair> what are they?
[19:32] <Amaranth> so only two things I can think of :)
[19:32] <Amaranth> hyperair: the activities view and having their "app menu" have a force quit option when an app freezes
[19:33] <Amaranth> since apps will have client side decorations if the app freezes you can't click the close button to force quit it but if the panel is the WM it can use the same functionality the decorations are using to add a force quit option to the app menu
[19:34] <hyperair> hmmm
[19:34] <hyperair> wait a sec. what client side decorations?
[19:35] <Amaranth> bratsche is adding client side decorations to GTK+
[19:35] <hyperair> also, the activities view is.. somewhat annoying
[19:35] <hyperair> what are client side decorations exactly?
[19:35] <hyperair> as in, window decorations no longer handled by window manager?
[19:35] <Amaranth> hyperair: right now the WM draws the decorations (the title, close button, etc)
[19:35] <Amaranth> right
[19:36] <hyperair> that sounds like a bad idea to me.
[19:36] <hyperair> an *extremely* bad idea
[19:36] <Amaranth> so GTK+ could theme the decorations and such
[19:36] <hyperair> hmm
[19:36] <Amaranth> hyperair: I said as much when I talked into the UDS session about it when it was half over :)
[19:36] <Amaranth> but they'd already discussed all my points and decided they weren't so bad
[19:36] <hyperair> the last thing i want is my window decorations to hang along with my windows =.=
[19:37] <Amaranth> afaik the current plan is to have an EWMH hint for where GTK+ is showing the close button so when the app locks up the WM can take over clicks for that button
[19:37] <Amaranth> Windows has client side decorations but will draw them itself when the app freezes
[19:37] <hyperair> i like being able to minimize my hung windows =\
[19:37] <hyperair> i see
[19:37] <Amaranth> so when iTunes freezes it suddenly grows a regular windows style decoration :)
[19:37] <hyperair> that manner eh..
[19:37] <hyperair> yes yes i noticed
[19:38] <Amaranth> regular windows you can't even tell the difference though because it just draws over the client one
[19:38] <hyperair> same goes for all office 07 things
[19:38] <Amaranth> That's a very ugly solution though
[19:38] <hyperair> agreed.
[19:38] <Amaranth> our apps tend to freeze a lot
[19:38] <hyperair> agreed.
[19:39] <hyperair> especially liferea
[19:39] <hyperair> liferea *always* freezes =.=
[19:39] <Amaranth> We used to get a lot of compiz bugs filed because firefox would freeze the UI while doing IO
[19:39] <hyperair> hmm firefox eh
[19:39] <Amaranth> and sometimes firefox would from that point on stop responding to ping events so it would stay gray even though it worked
[19:39] <hyperair> ouch
[19:39] <hyperair> that sucks
[19:39] <hyperair> huh come to think of it my windows don't gray out when they hang
[19:39] <hyperair> O_o
[19:40] <hyperair> where's the option for that?
[19:40] <Amaranth> did you disable the fade plugin?
[19:40] <hyperair> yeah
[19:40] <Amaranth> don't do that :)
[19:40] <hyperair> but it conflicts with animations
[19:40] <Amaranth> I tried to tell people fade wasn't useless
[19:40] <Amaranth> no it doesn't...
[19:40] <hyperair> oh it doesn't?
[19:40]  * hyperair tries to enable
[19:41] <Amaranth> it used to conflict but that was fixed long ago
[19:42] <hyperair> i see
[19:55] <bratsche> I haven't worked on client-side-decorations recently, but I'm hoping to get back to it soon and finish it.
[19:55] <bratsche> We talked about it at Boston Summit a bit.  There are still several things that need to be done.
[20:45] <dobey> seb128: around?
[21:02] <chrisccoulson> hey Amaranth - do you know what is causing issues like bug 452417?
[21:02] <Amaranth> chrisccoulson: should be fixed in the 0.8.4 packages
[21:02] <chrisccoulson> Amaranth - you rock:)
[21:02] <chrisccoulson> thanks
[21:03] <dashua> Amaranth, Any chance of ever getting "0" max waves for the magic lamp animation by default without hacking libanimation.so and animation.xml
[21:03] <Amaranth> chrisccoulson: bug 444836 btw
[21:03] <Amaranth> dashua: I don't like being sued by Apple so no
[21:03] <dashua> Ha, good point :)
[21:03] <chrisccoulson> excellent, thanks Amaranth
[21:04] <chrisccoulson> seb128 - did you say that you could reliably trigger this screensaver crash yesterday?
[21:04] <chrisccoulson> i can only trigger it occasionally which is a real pain for debugging
[21:07]  * Amaranth stabs launchpad
[21:07] <Amaranth> it may be my connection but launchpad seems to always stall
[21:13]  * Amaranth reboots modem
[21:21] <seb128> re
[21:21] <seb128> dobey, now yes
[21:21] <seb128> chrisccoulson, not really, but it took me 1 minute to trigger it 3 times in a row
[21:22] <coderminus> how do I make task switcher show tasks from all workspaces?
[21:22] <chrisccoulson> seb128 - thanks. i can trigger it occasionally but not when i really want to ;)
[21:22] <dobey> seb128: hey. i was going to ask what all one needs to do to get an update into Karmic before release now. statik suggested i should talk to slangasek. should i just ping him?
[21:22] <chrisccoulson> i think i know what's going on now anyway
[21:30] <Amaranth_> yeah, that's great freenode and xchat-gnome, I can totally lag for 15 minutes without being disconnected
[21:31] <dobey> heh
[21:31] <dobey> not even a ping timeout
[21:32] <seb128> chrisccoulson, oh?
[21:32] <seb128> dobey, bug fixes are fine if those are really issues to fix for karmic
[21:33] <seb128> dobey, what change do you want to get there?
[21:33] <chrisccoulson> seb128 - the gnome-screensaver-dialog exits after the 5th login attempt whilst the gnome-screensaver process is still shaking it, and that can cause it to access resources that have already been destroyed
[21:33] <chrisccoulson> at least that's what i seem to be seeing in xtrace
[21:34] <dobey> seb128: just landed a critical fix in trunk (that i need to backport to stable branch). i was just wondering about the process right now
[21:34] <seb128> oh ok
[21:34] <seb128> dobey, the process is upload and wait to get approval
[21:34] <seb128> ie I'm fine sponsoring a bug fix for you
[21:34] <dobey> seb128: and nominate the bugs for karmic?
[21:35] <seb128> then it needs to be accepted, ie pitti or slangasek will review it
[21:35] <seb128> well theorically only karmic blocker bugs should justify uploads now
[21:35] <seb128> ie you think you have a bug to fix that should be fixed in karmic prepare the update
[21:35] <seb128> you can backport the fix to current karmic package
[21:36] <seb128> no need to roll a new tarball
[21:36] <seb128> then find a sponsor and wait for r-t to approve the upload
[21:36] <dobey> well, i'd rather avoid sticking patches in stuff we maintain. it's a bit messy
[21:37] <seb128> why?
[21:37] <dobey> so new tarball is actually easier, but if the standard process is ship as patches, i can work to get that done
[21:37] <seb128> ie should just be applying a bzr commit to the source
[21:37] <seb128> well the less change the easier to review
[21:38] <seb128> can you bzr merge the commit to the packaging bzr there?
[21:38] <seb128> and build
[21:38] <seb128> the change will go in the diff.gz
[21:38] <dobey> well for one, we pull the debian dir from the same bzr tree for building PPA packages, to minimize differences between PPA and downstream packages
[21:41] <dobey> the source pkg branch isn't based off the trunk tree, no. it's tarball contents + debian dir
[21:41] <seb128> ok
[21:41] <seb128> whatever is easier
[21:41] <dobey> ok
[21:41] <seb128> if you don't have other changes that the one you need
[21:41] <seb128> just roll a new tarball
[21:41] <seb128> it's not always the case
[21:42] <dobey> don't i know it
[21:42] <dobey> but i wanted to make sure of the process at this point in the cycle first
[21:42] <seb128> ok
[21:42] <seb128> distro guy will usually backport the change
[21:42] <seb128> ie add the bzr diff -c rev to the patches dir
[21:43] <seb128> but a new tarball with only bug fixes is fine too
[21:43] <dobey> i'll bug people on ubuntuone team, to make sure what we need to get in
[21:43] <seb128> we will get GNOME 2.28.1 on monday
[21:43] <dobey> seb128: i've branched our code for stable releases, so only bug fixes will go on that branch
[21:43] <seb128> so you still have some margin, but having your upload ready before weekend would be nice though
[21:44] <dobey> seb128: yeah, i plan to get it done tomorrow
[21:45] <dobey> seb128: and we're working to have people on our team become ubuntu developers. so we're trying to maintain package branches, and such, to work on getting those credentials :)
[21:56] <seb128> chrisccoulson, I get try a patch if you want though
[22:12] <seb128> re
[22:12] <seb128> asac, the policykit fix is working
[22:12] <seb128> tedg, is that normal that pidgin is not listed in my indicator?
[22:13] <tedg> tedg: No, it shouldn't be unless you disable the libnotify plugin.  If you disable it, it'll put itself in the blacklist.
[22:13] <tedg> seb128: ^
[22:13] <tedg> :)
[22:13] <tedg> seb128: Do an ls ~/.config/indicators/messages/application-blacklist
[22:13] <seb128> it's there
[22:14] <tedg> Did you disable the plugin?
[22:14] <seb128> weird
[22:14] <seb128> no
[22:14] <tedg> Hmm, what's the timestamp on the file?
[22:14] <seb128> 9 minutes ago
[22:15] <seb128> weird
[22:15] <seb128> I will keep looking for it
[22:15] <tedg> Hmm, okay.
[22:15] <seb128> I think I did play with the option to show the notification area icon though
[22:16] <seb128> hum, no, that was in a guest user session
[22:22] <tedg> It does a timeout to see if you don't have it enabled at startup.  Like if it gets loaded, but is not configured (for things like sysadmins changing the default).  That could be over-sensitve perhaps.
[22:23] <seb128> how does the timeout thing works?
[22:23] <tedg> I haven't seen it go off though.
[22:23]  * tedg looks to be sure before replying :)
[22:24] <tedg> seb128: yeah, it adds a 30 second timeout when the plugin gets pulled in.  If the plugin isn't init'd in that time it assumes that it won't be.
[22:24] <tedg> Does it take longer than 30 seconds for Pidgin to load on your machine?
[22:25] <seb128> no, but I might have started and closed pidgin immediatly
[22:25] <seb128> since I decided to run empathy today
[22:25] <seb128> could that trigger your code?
[22:25] <tedg> I don't think so...  I don't think that'd force a timer to run.
[22:26] <seb128> ok
[22:26] <seb128> well, what does start the timer?
[22:26] <seb128> I did start pidgin
[22:26] <seb128> and close it, ie there was a few seconds between run and close
[22:26] <seb128> so maybe it did start registration but exited before
[22:26] <tedg> When it pulls in the .so it runs a small registration.  That starts the timer.
[22:27] <seb128> ok, let's not bother
[22:27] <seb128> I will ping you back if I find what trigger the change
[22:28] <tedg> Okay, the mainloops don't say anything about it.  They say that things that are already dispatched should run, but it shouldn't have been dispatched.
[22:28] <tedg> (the docs that is)
[22:34] <Amaranth> tedg: evalMatch in compiz is to check which windows the user wants to skip focus stealing prevention completely, btw
[22:35] <Amaranth> not important for what you're looking at
[22:35] <tedg> Amaranth: Ah, okay.  It was just the first function, so I started digging :)
[22:36] <Amaranth> tedg: there is really only one part of it should worry about, the XSERVER_WHATEVER macro
[22:36]  * Amaranth forgets the name
[22:38] <tedg> Amaranth: Yeah, but for a lot of apps the fact that it's calling "onCurrentDesktop" will probably block things first :(
[22:38] <Amaranth> tedg: perhaps
[22:39] <Amaranth> tedg: except you mean the viewport check since we don't use desktops :)
[22:39] <TheMuso> awe: I will get to your merge proposal once I'm through my morning's email log. I agre its worth forcing it off people's systems for now. Good thing is that for lucid, this can go away as the kernel as of 2.6.32 will have the bits we need.
[22:39] <Amaranth> tedg: but gtk_window_present should move it to the current viewport as well, iirc
[22:39] <awe> TheMuso, np
[22:39] <tedg> Amaranth: I think it only does if no window is focused on the current viewport.
[22:40] <Amaranth> tedg: that's where gtk_window_present_with_time comes in :)
[22:40] <Amaranth> tedg: and the macro bit I was talking about
[22:41] <awe> TheMuso, fyi, I did a release commit as I haven't had many uploads sponsored lately, and I need to get my MOTU one of these days...
[22:41] <Amaranth> tedg: you could just make the time in the future instead of changing the dbus interfaces
[22:41] <awe> TheMuso, that said, feel free to re-do that part if you want
[22:41] <Amaranth> tedg: so long as the time in the future part is only used when the indicator applet is opening the window and not when you get a new message
[22:42] <tedg> Amaranth: Seems like it'd protect against that, no?
[22:42] <TheMuso> awe: Ok thanks for the heads up.
[22:42] <awe> anytime!
[22:42] <Amaranth> tedg: actually setting time to zero should work
[22:43] <Amaranth> tedg: since we use low level instead or normal
[22:43] <Amaranth> s/or/of/
[22:43] <tedg> Amaranth: Hmm, okay.  Zero is *really* easy to figure out :)
[22:44] <Amaranth> tedg: see the comment on line 5075 of that file
[22:44] <Amaranth> 0 will pass the !timestamp check so you'll end up there
[22:45] <rickspencer3> akgraner, hi, what was your question?
[22:46] <tedg> Amaranth: Hmm, wouldn't that lead to returning CompFocusPrevent, which would be 1?
[22:46] <akgraner> rickspencer3, I upgraded to Karmic on the machine I use everyday..  It is my understanding that the old notifier (the one with the orange burst and the red arrow) won't work anymore is that true?
[22:46] <Amaranth> tedg: the function is named isWindowFocusAllowed
[22:46] <rickspencer3> orange burst, and red arrow, not sure what you mean exactly?
[22:46] <Amaranth> tedg: returning TRUE is good :)
[22:46] <akgraner> the update notifier
[22:46] <rickspencer3> aah
[22:47] <Amaranth> tedg: you're looking at the function below that
[22:47] <tedg> Amaranth: Ah, okay.
[22:47] <rickspencer3> akgraner, this was turned off in Jaunty, though I think there is "secret" setting that you can use to bring it back
[22:47] <Amaranth> tedg: oh, crap
[22:47] <Amaranth> but you're right
[22:47] <akgraner> yeah..I had that..
[22:47] <Amaranth> when did that change? :/
[22:47] <akgraner> wrote a post on it...:-)
[22:47] <rickspencer3> so the secret setting is gone now
[22:47] <rickspencer3> ?
[22:48] <Amaranth> tedg: I guess it's time to use MAXINT or so :)
[22:48] <tedg> Amaranth: I *really* want it, I'll use MAXINT + 1 ;)
[22:49] <akgraner> rickspencer3, let me try it now that I upgraded.. ..  I just wanted to make sure it wasn't going to break something, b/c I was told a few months ago I wouldn't be able to do that anymore...
[22:49] <akgraner> I thought you would know..:-)
[22:49] <akgraner> I'll go away and let you know if it works or not..:-)
[22:49] <Amaranth> hmm, is there a MAXINT32?
[22:49] <rickspencer3> akgraner, sorry to be dense, but I'm still not 100% clear what you are asking
[22:50] <Amaranth> because you don't want a 64-bit one since the X protocol is always 32-bit
[22:50] <tedg> Amaranth: There is a G_MAXINT32
[22:50] <rickspencer3> are you asking if something will break if you try the gconf key to make your old behavior?
[22:50] <Amaranth> there you go
[22:50] <akgraner> rickspencer3, you aren't dense...  I'm just not technical... let me try to put it back (I should have done that before I asked)... :-(
[22:51] <rickspencer3> akgraner, it's not you, it's me
[22:51] <rickspencer3> I don't think anything bad will happen if you try
[22:51] <akgraner> rickspencer3, dang it sounds like a breakup now...:-)
[22:51] <rickspencer3> but mvo may have made it not work anymore
[22:51] <rickspencer3> lol
[22:51] <chrisccoulson> akgraner - /apps/update-notifier/auto_launch ?
[22:51]  * rickspencer3 is glad pgraner is not here
[22:51] <rickspencer3> oops
[22:51] <pgraner> rickspencer3: I am
[22:52] <pgraner> rickspencer3: you can have her, but you get the bills AND the kids
[22:52] <rickspencer3> :)
[22:53] <akgraner> rickspencer3, let me go try this and I will let you know.. well if you want to know that is
[22:53] <rickspencer3> akgraner, I want to know
[22:53] <rickspencer3> thanks
[22:53] <akgraner> if it breaks I'm blaming the kernel guy.. and I'll launch my computer at him  :-)
[22:54] <chrisccoulson> it's still possible to enable the pre-jaunty behaviour for update-notifier
[22:54] <chrisccoulson> thankfully ;)
[22:59]  * tedg is so happy that icon is gone.  And wishes he could remember how to disable the apport one too.
[22:59] <akgraner> rickspencer3, ok it didn't break anything...:-)
[22:59] <rickspencer3> hehe
[23:00] <rickspencer3> akgraner, ok, that's step 1
[23:00] <rickspencer3> step2 is that it works
[23:00]  * rickspencer3 bets it does
[23:01] <akgraner> :-)  sorry I bugged you.. why do I listen to people without just trying something 1st... :-/
[23:02] <akgraner> Nothing is broken for long and it's all fixable..:-)  you all rock!!:-)
[23:02]  * akgraner goes away now...
[23:02] <rickspencer3> akgraner, it's not bugging me
[23:02] <rickspencer3> I hope I didn;t seem annoyed
[23:02] <akgraner> no not at all..
[23:03] <chrisccoulson> tedg - i must be the opposite to you then ;)
[23:05] <tedg> chrisccoulson: Heh, you're my evil twin! ;)
[23:05] <chrisccoulson> lol
[23:05] <tedg> Anyway, need to run.  Have a good night folks!
[23:06] <rickspencer3> bye tedg
[23:10]  * rickspencer3 can't figure out how to hide a gtk window in c :(
[23:10]  * rickspencer3 dons tall pointed cap
[23:11] <robert_ancell> rickspencer3, gtk_widget_hide ?
[23:11] <rickspencer3> hmmm
[23:11] <rickspencer3> can I cast my window pointer to a widget pointer?
[23:11]  * rickspencer3 tries
[23:11] <robert_ancell> rickspencer3, yes
[23:12] <rickspencer3> man this takes me back
[23:12] <robert_ancell> :)
[23:12] <seb128> hey robert_ancell
[23:13] <seb128> robert_ancell, I didn't upload your gvfs and rhythmbox changes
[23:13] <seb128> those are non trivial and we are frozen for karmic now
[23:13] <robert_ancell> seb128, :( I hoped I got them in on time...
[23:13] <robert_ancell> they work really well...
[23:14] <Amaranth> rickspencer3: GTK_WIDGET(window) is the proper way to do it
[23:14] <seb128> you think it's worth having for karmic?
[23:14] <seb128> robert_ancell, is that an issue with any podcast?
[23:14] <Amaranth> or is it GTKWIDGET?
[23:14]  * Amaranth fails too
[23:14] <robert_ancell> seb128, it depends on the podcast but I think a lot of big names use a particular service to serve their podcasts and one of those servers has the problem
[23:15] <robert_ancell> pheedo.com is the service, and the example is Scientific American which I expect a number of people subscribe to
[23:15] <robert_ancell> I think Banshee had the same problem when I checked
[23:15] <seb128> robert_ancell, ok, I will upload and let the other guys (slangasek and pitti) decide
[23:16] <seb128> since they are the one reviewing the uploads
[23:16] <robert_ancell> seb128, cool, thanks
[23:16] <seb128> you're welcome
[23:16] <seb128> otherwise I think we are good for karmic
[23:16] <robert_ancell> did the printing issues get resolved?
[23:16] <seb128> I didn't spot real issue to bounce your way yesterday or today
[23:16] <seb128> I did upload the git change undo
[23:16] <seb128> did you read my summary on the bug?
[23:17] <robert_ancell> not yet
[23:17] <seb128> the pdf is generated by cairo
[23:17] <robert_ancell> you stole my bug, sniff. ;)
[23:17] <seb128> but works fine in acroread and evince
[23:17] <dtchen> awe: have you uploaded this change to the archive?
[23:17] <seb128> robert_ancell, I'm sorry, but I can give you a new one if you want ;-)
[23:17] <seb128> robert_ancell, anyway the pdf is valid for cairo guys since it works fine in viewer and they don't have other validators
[23:17] <robert_ancell> seb128, no it's freeze time now, I *can't* have any more :)
[23:18] <rickspencer3> riiiight
[23:18] <seb128> robert_ancell, you wish
[23:18] <robert_ancell> rickspencer3, back to widget hiding! Nothing to see here
[23:18] <awe> dtchen: no.  i created a bzr branch and proposed a merge request, but i'm not core-dev, so i need someone to sponsor.
[23:18]  * rickspencer3 pictures robert_ancell sitting in a rocking chair, smoking a pipe
[23:18] <bryce_> heh
[23:18] <seb128> robert_ancell, I assigned another podcast issue for you if you want to look at it, an user claiming it file to download podcasts with identic names
[23:18] <awe> TheMuso, said he'd take a look as soon in a bit
[23:19] <dtchen> awe: ok, 'cause Luke usually requests that we not actually put karmic in the distribution (debian/changelog)
[23:19] <awe> s/as soon in a bit/soon/
[23:19] <dtchen> awe: UNRELEASED, usually
[23:19] <robert_ancell> seb128, ah, I was thinking about that when in the code, I think it saves it locally using the basename not the full path
[23:19] <robert_ancell> seb128, I'm not suprised if that fails
[23:19] <awe> dtchen: yea, i wasn't sure about that... but also gave him a heads up
[23:19] <dtchen> awe: i need to roll in another patch, so i was wondering why it was marked karmic ;)
[23:19] <seb128> robert_ancell, ok, good, so you are welcome to fix that too if you want ;-)
[23:19] <awe> dtchen: my bad...  ;(
[23:20] <dtchen> awe: no prob
[23:20] <robert_ancell> seb128, so those sorts of fixes - do we patch the stable uploads or only allow them if we convince upstream to put them in 2.28.1?
[23:20] <seb128> robert_ancell, we patch
[23:27] <robert_ancell_> wow, upstreams can be pedantic... I was told off for not providing a git formatted patch.  The patch only inserted a single '!'
[23:27] <Laney> git patches provide the metadata they need to merge it in properly
[23:28] <chrisccoulson> robert_ancell - i always submit git formatted patches now
[23:28] <chrisccoulson> no matter how trivial ;)
[23:28] <robert_ancell_> yeah, but one character?  I would have expected them to insert the character manually
[23:28] <Laney> audit trail :)
[23:28] <robert_ancell_> ok, I will be less lazy in the future :)
[23:30] <chrisccoulson> robert_ancell_ - in my job, you'd need to go get approval from a dozen other people and have several reviews over a few weeks before making a change as big as that ;)
[23:30] <robert_ancell_> chrisccoulson, you remind me of the reason I stopped working for a government department :)
[23:31] <chrisccoulson> heh. i don't work for a government department though ;)
[23:31] <chrisccoulson> i work in automotive, which is probably worse!
[23:31] <chrisccoulson> ;)
[23:31] <seb128> robert_ancell_, by upstream you mean bastien I guess?
[23:31] <robert_ancell_> seb128, yup
[23:31] <TheMuso> If an upstream uses git, I love submitting git formatted patches, to get correct attribution. :)
[23:31] <TheMuso> Or more to the point, to make sure attribution is given.
[23:31] <seb128> he can be somewhat rude in his comment sometimes yes
[23:31] <robert_ancell_> chrisccoulson, oh, yes I have heard stories from automotive :)
[23:31] <TheMuso> correctly
[23:32] <chrisccoulson> robert_ancell - i've had to suffer working in aerospace too ;)
[23:32] <chrisccoulson> they're both as bad as each other!
[23:32] <robert_ancell_> chrisccoulson, I was just going to say they're one step from aerospace, you love punishment!
[23:32] <chrisccoulson> maybe i'll work for the government next then;)
[23:33] <robert_ancell_> chrisccoulson, I know people who've done medical - that sounds just as bad
[23:33] <seb128> robert_ancell_, the work is not the char change it's to write the commit message with credit for you etc ;-)
[23:33] <robert_ancell_> chrisccoulson, I did mostly telco so that was easier
[23:33] <chrisccoulson> robert_ancell - i was looking at some medical electronics jobs as my next career move ;)
[23:34] <TheMuso> awe, dtchen. I am about to take care of the merge proposal now.
[23:34] <chrisccoulson> maybe i should give it a miss
[23:34] <robert_ancell_> chrisccoulson, the great thing about the government is you go through all that effort to get approved then they'll probably just can the project when the next government gets voted in
[23:34] <robert_ancell_> seb128, yeah, I'm happy to waive credit for a trivial bug :)
[23:34] <chrisccoulson> lol, yeah, i can imagine that happening here
[23:35] <awe> TheMuso, cool
[23:36] <awe> TheMuso, sorry about the release commit...
[23:36] <TheMuso> awe: re the karmic release commit, I don't need to merge that, so all is well.
[23:36] <awe> cool
[23:36] <dtchen> TheMuso: i have one pending commit; shall i wait on your push?
[23:36] <TheMuso> dtchen: Sure.
[23:37] <dtchen> (ok, waiting)
[23:37] <dtchen> awe: do we really intend to Conflict all versions greater than or equal to rtkit?
[23:38] <rickspencer3> robert_ancell http://bugs.launchpad.net/bugs/449582
[23:38] <rickspencer3> care to take a look today?
[23:38] <TheMuso> dtchen: pushing now
[23:38] <dtchen> awe: i.e., i'm thinking it's better to do something like <= 0.4-0ubuntu2
[23:39] <TheMuso> dtchen: pushed
[23:39] <awe> dtchen: yea, that probably makes more sense...
[23:39] <dtchen> awe: i suppose in the end it doesn't really matter, since arguably one could just remove the conflicts from PA
[23:40] <awe> dtchen: right...that's what i was thinking
[23:40] <awe> dtchen: that way we make the change in lockstep
[23:40] <awe> ...and make sure to get it right for lucid.  ;)
[23:40] <awe> kernel & all
[23:41] <TheMuso> I'm actually hoping we can possibly get jack to play nice with rtkit for lucid. Now that would be awesome.
[23:41] <awe> +10
[23:41] <TheMuso> Have rtkit be responsible for realtime app performance.
[23:41] <robert_ancell_> hey, I have one more Google Wave invitation, anyone want it?
[23:41] <TheMuso> If its all web based, I'll pass, thanks anyway. :)
[23:42] <awe> robert_ancell_, is it worth it?
[23:42] <robert_ancell_> awe, it's interesting to play with, needs a lot of work before it is really useful
[23:42] <awe> i've heard it's amusing, but nobody really knows what to do with it...
[23:42] <robert_ancell_> sounds like an apt summary
[23:42]  * TheMuso is not convinced that everything being web based is the way forward.
[23:42] <awe> yea, i guess i'll pass too.  i have more than enough to keep me busy. ; )
[23:42] <robert_ancell_> TheMuso, google is :)
[23:43] <TheMuso> robert_ancell_: Yes but if its all web based, I am not going to be won over. Web content is becoming even more of a pain for people like myself than ever.
[23:43] <awe> TheMuso, hey, meant to ask you... are there any instructions posted anywhere on how to enable jack on top of karmic right now ( ie. if I want to play with ardour )?
[23:43] <seb128> good night everybody
[23:43] <TheMuso> awe: Not so far as I know, other than how its been done in the past. Load qjackctl, start jack, start ardour, connect jack prts etc.
[23:44] <robert_ancell_> TheMuso, there must be some progress being made on a11y for web right?
[23:44] <robert_ancell_> seb128, night
[23:44] <TheMuso> robert_ancell_: Yes there is, but if others think like I do, its often more efficient to have a well written client app than use a website that can be hard to get around, even if designed well.
[23:45] <awe> TheMuso, are there any pulse bits I need to tweak?  I recall hearing that there's a jack plugin that detects jack and release the default ASLA dev?
[23:46] <TheMuso> awe: Qjackctl should suspend pulse activity on the sound hardware while jack is running. Other than that, the only other way for pulse to relinquish the audi ohardware is for jack to communicate via dbus, which is not set up in karmic. I would like to get jack2 and have that set up for lucid however.
[23:48] <dtchen> TheMuso: thanks, pushed
[23:48] <awe> ok, thanks for the explanation...
[23:50] <TheMuso> awe: np