[07:18] <pitti> Good morning
[07:49] <didrocks> morning pitti
[08:17] <crevette> hello
[08:25] <didrocks> Hi seb128, crevette
[08:25] <crevette> salut didrocks
[08:25] <seb128> lut crevette didrocks
[08:25] <didrocks> seb128: gtkmm2.4 is ready (https://bugs.edge.launchpad.net/ubuntu/+source/gtkmm2.4/+bug/328251)
[08:25] <crevette> salut seb128 & andreasn
[08:25] <andreasn> hallo crevette
[08:25] <seb128> didrocks: good thanks
[08:25] <crevette> didrocks is already on the run
[08:26] <didrocks> but has gnome-python, it doesn't show up in dholbach page
[08:26] <seb128> ok
[08:26] <crevette> seb128: you can "apt-get install nautilus-sendto-universe" now :) thanks for driving me
[08:26] <didrocks> (indeed, it show in "The following bugs have not been parsed")
[08:26] <seb128> I'm not sure we want to use bzr for this one
[08:26] <didrocks> seb128: really?
[08:27] <seb128> crevette: you're welcome
[08:27] <seb128> didrocks: well, gtkmm2.4 is often in sync with debian so I'm not sure how to manage that and keep the bzr uptodate, that seems extra work rather than win
[08:27] <didrocks> seb128: ok :)
[08:27] <seb128> didrocks: let me talk to mvo when he will be around
[08:28] <mvo> hm?
[08:28] <didrocks> seb128: ok. So, I have only python-gnome-extras waiting for libgda
[08:28] <seb128> crevette: was that bug #327747?
[08:28] <didrocks> and nothing else to do o/
[08:28] <crevette> seb128: yes
[08:28] <seb128> mvo: didrocks is putting everything in bzr nowadays thanks to your guidance ;-)
[08:28] <didrocks> (pidgin has been taken by alessio)
[08:28] <mvo> heh :)
[08:28] <seb128> didrocks: ok
[08:28] <crevette> seb128: oups I didn't read that last comment
[08:29] <mvo> I like that
[08:29] <crevette> seb128: I hope this is a type
[08:29] <crevette> typo
[08:29] <seb128> mvo: but gtkmm2.4 is often in sync with debian, not sure how to keep bzr uptodate in such case, that seems rather extra work
[08:29] <seb128> crevette: I think that's a bug triager closing the bug wrongly, let me reopen
[08:29] <seb128> crevette: the bug should not be on nautilus-sendto but on ubuntu
[08:29] <crevette> ah I didn't know
[08:30] <mvo> seb128: hm, good point. when its in sync with debian it will not have a vcs-bzr header, and when we de-sync it, we can do that from the bzr tree. but its a bit ugly to keep the tree around when its not up-tp-date
[08:30] <mvo> OTOH this way we will have full ubuntu changelogs
[08:30] <mvo> (something I sometimes miss)
[08:31] <seb128> what do you mean by full changelog?
[08:31] <didrocks> that's right that the vcs-bzr header can be an issue :/
[08:31] <seb128> there is no ubuntu change, we are just sometime faster to package unstable versions
[08:31] <crevette> need to go
[08:31] <crevette> bye
[08:33] <mvo> seb128: hm, right
[08:34] <seb128> didrocks: can you drop the vcs-bzr line in control? we will just upload, using bzr is just extra work there, we will likely be using the debian again in next versions
[08:34] <didrocks> seb128: sure
[08:35] <didrocks> seb128: do you I put a debdiff?
[08:35] <didrocks> (so, I think I have to revert the debian/watch change)
[08:35] <seb128> didrocks: you can use your bzr, I will use if for sponsoring but just not push that to the ubuntu-desktop codepage
[08:36] <seb128> didrocks: the watch file is no issue
[08:36] <seb128> just let's not bother with bzr there
[08:36] <didrocks> ok, thanks, it will be easier for me with push/pull :)
[08:36] <didrocks> ok
[08:44] <seb128> vuntz: there?
[08:44] <seb128> vuntz: are you running gtk 2.15.n?
[08:49] <didrocks> seb128: done, rev 3 pushed
[10:02] <asac> mvo: see msg
[10:06]  * huats notices that seb128 is on "clear gnome-keyring bugs" mode 
[10:06] <huats> :)
[10:06] <seb128> huats: yeah, you are welcome to do that too if you want ;-)
[10:06] <huats> :)
[10:07] <seb128> not on gnome-keyring though since it's mostly cleaned now
[10:07] <huats> I am a bit on a rush at the moment for my day work
[10:07] <huats> but I wll try to help outµ...
[10:07] <seb128> no hurry you already did a lot recently
[10:18] <didrocks> seb128: if you have something that I can handle, it will be with pleasure :)
[10:18] <seb128> didrocks: http://download.gnome.org/sources/gnome-icon-theme/2.25/gnome-icon-theme-2.25.90.tar.gz
[10:19] <seb128> didrocks: http://download.gnome.org/sources/seahorse-plugins/2.25/seahorse-plugins-2.25.90.tar.gz
[10:19] <didrocks> seb128: ok, I take them :)
[10:19] <seb128> cool
[10:20] <didrocks> seb128: I checked withc check-symbols the ABI differences in gtkmm2.4
[10:21] <didrocks> seb128: there is only added symbols, so, it's ok, but I wonder why all libraries still have the same name *.1.0.30
[10:21] <didrocks> and not bump a minor version like *.1.0.31
[10:21] <seb128> because upstream didn't upgrade the number correctly
[10:21] <didrocks> (without changing the SONAME as there is no ABI breakage)
[10:21] <seb128> that should not make a real difference though
[10:22] <didrocks> ok, but theorically, this change has to be done, right?
[10:22] <didrocks> is it this? change the minor revision?
[10:22] <seb128> right
[10:22] <didrocks> it was just to confirm ^^ thanks
[10:58] <mvo> seb128: hi, how is compiz behaving today?
[10:59] <seb128> mvo: hello, not, I'm on my desktop right now which has a recent ati card and doesn't work on compiz
[11:00] <seb128> mvo: I will try again the laptop later and let you know
[11:00] <mvo> seb128: aha, no problem
[11:00] <seb128> mvo: you don't get the issue by running gnome-screenshot?
[11:00] <mvo> seb128: no :/
[11:00] <seb128> you have a tasklist and use the option to list only things on the current workspace?
[11:01] <seb128> it's weird it was doing it for evolution and gnome-screenshot for example
[11:01] <seb128> but not for gedit, xchat-gnome, etc
[11:01] <seb128> didrocks: ups, there was a bug in your gtkmm update
[11:02] <seb128> didrocks: SHVER in rules should be updated to 2.15.3 since there is new functions in this version
[11:02] <mvo> seb128: I tried it with evo and gnome-screenshot and the "workspace switcher" and the tasklist show them only on the current one
[11:03] <seb128> the workspace switcher and alt tab are not issue
[11:03] <seb128> that's the flat list of tasks which was
[11:03] <seb128> anyway will try a bit later and let you know
[11:04] <mvo> seb128: "window list" and "show windows from current workspaces=yes" - looks ok for me, when I switch its gone from the window list
[11:05] <mvo> seb128: let me check if I have the latest gnome panel applets
[11:05] <seb128> those didn't change recently
[11:41] <asac> mvo: did you figure how to enable NM system connections in upgrade tester?
[11:41] <asac> or do you need more info?
[11:49] <mvo> asac: not yet, sorry. need to get back to this
[11:50] <seb128> mvo: the synaptic quick search thing is not really smart
[11:50] <mvo> asac: how can I detect if its restarted? do I need some sort of monitoring process?
[11:50] <mvo> seb128: no?
[11:50] <seb128> I guess that's a known issue?
[11:52] <seb128> mvo: well it tends to list lot of things which don't match the filter, or it tries to be too smart and match in depends and descriptions too and score that quite high
[11:53] <mvo> seb128: what search did you do that was not good?
[11:53] <seb128> mvo: try typing gnome-applets in the entry
[11:54] <seb128> gnome-applets-data is listed first
[11:54] <seb128> gnome-applets is several screens after that
[11:54] <seb128> it lists
[11:54] <seb128> gnome-applets-data
[11:54] <seb128> capplets-data
[11:54] <seb128> bluez-gnome
[11:54] <seb128> etc etc etc
[11:54] <seb128> and then gnome-applets
[11:55] <mvo> seb128: yeah, I see the same here, I have a look, its xapian smartness, the amount of influcence I have is not that great into the scoring
[11:55] <seb128> mvo: usually have the exact name match first would be cool ;-)
[11:55] <seb128> having
[11:55] <seb128> or that's what I would expect when I type a binary name correctly
[11:56] <seb128> do you want a bug about that?
[11:56] <mvo> yep
[11:57] <seb128> it's a detail probably not worth the trouble
[11:57] <seb128> I was just pointing it in case you were interested ;-)
[11:58] <didrocks> seb128: you're right. I didn't checked what it is used for. New version pushed
[11:59] <seb128> didrocks: you need to update the changelog to 0ubuntu2 I did sponsor the previous revision a bit quickly, did test build, install, try gnome-system-monitor and upload
[12:00] <didrocks> oh crap
[12:00] <seb128> ie, you can't reupload using the same number
[12:00] <didrocks> ok
[12:00] <didrocks> I didn't see you uploaded a new version
[12:01] <didrocks> sorry for that
[12:01] <didrocks> how did you see that, for information?
[12:01] <seb128> didrocks: see what?
[12:02] <seb128> didrocks: I didn't upload a new version, I just sponsored your update
[12:02] <didrocks> that I forgot to change this value, afterwards
[12:02] <seb128> I did bzr diff to see what you did exactly
[12:02] <didrocks> because once sponsored, I think you don't look at the rules file :)
[12:03] <seb128> as said I did sponsor too quickly, I just test built and uploaded
[12:03] <seb128> then I went "ups, maybe I should review the changes too"
[12:03] <didrocks> yes yes, but how did you see the mistake, once sponsored?
[12:03] <didrocks> ok
[12:03] <seb128> that's what you get after sponsoring some good work ;-)
[12:03] <seb128> you just trust the updater ;-)
[12:03] <didrocks> sorry for the mistake, I should have looked at the rules file :/
[12:04] <didrocks> next time, I will grep for version, to be sure :)
[12:04] <seb128> that's just a small mistake, but since you told me they added functions but didn't change the soname I decided to check that you updates the shver
[12:04] <seb128> well, new function = shlibs update
[12:04] <seb128> it can be a .shlibs or in the rules
[12:05] <didrocks> ok, I just looked for .shlibs :/
[12:05] <vuntz> seb128: gtk 2.15.n: yes, partly (didn't log out)
[12:05] <didrocks> seb128: so, rev 5 is pushed
[12:05] <asac> seb128: hmm yesterdays seahorse (ssh agent) has issues?
[12:06] <asac> slogin senica -lalex
[12:06] <asac> buffer_get_ret: trying to get more bytes 4 than in buffer 0
[12:06] <asac> buffer_get_int: buffer error
[12:09] <seb128> vuntz: that's ok, I don't need testing out of ubuntu after all I think ;-)
[12:09] <seb128> asac: gnome bug #571060
[12:10] <seb128> vuntz: btw since you are there, did you ever looked at vertical gnome-panel freeze when there is over 8 tasks in the list?
[12:10] <seb128> vuntz: and to the gnome-panel not matching the screen after using xrandr?
[12:10] <vuntz> seb128: hrm, no
[12:10] <vuntz> didn't know about the second issue
[12:10] <seb128> vuntz: try switching to a lower resolution using xrandr and back to your current one
[12:11] <asac> seb128: thanks. CCed me
[12:11] <seb128> vuntz: and let me know if it goes back to the correct value
[12:11] <seb128> asac: you use a dsa key right?
[12:11] <vuntz> seb128: why do you always ask me to test stuff that will break my config?
[12:11]  * vuntz tries in xephyr
[12:12] <seb128> vuntz: that will not break, just restart gnome-panel
[12:12] <asac> seb128: i dont use it, but i have a key still yes.
[12:12] <seb128> asac: try moving it somewhere else?
[12:13] <seb128> didrocks: you did change the timestamp of the previous changelog entry, can you revert to the correct value? ;-)
[12:13] <vuntz> seb128: definitely works in xephyr
[12:13] <vuntz> seb128: can you try there?
[12:14] <asac> seb128: i think i have to relogin ... let me check
[12:14] <asac> (now getting wierd "cannot sign error")
[12:14] <seb128> asac: otherwise you can workaround by using ssh agent
[12:14] <didrocks> seb128: of course, I can do. For information, why is this really important for some automation tools)?
[12:14] <didrocks> or just for consistency?
[12:14] <seb128> just export SSH_AUTH_SOCK= to the ssh-agent socket and ssh-add
[12:15] <seb128> didrocks: for consistency, no reason to change things in the previous revision
[12:15] <asac> seb128: well so seems we have a dejavu ;)
[12:15] <seb128> didrocks: you usually try to not change things which have already been uploaded
[12:15] <asac> i removed my dsa stuff .... relogged in
[12:15] <asac> now i get:
[12:15] <asac> Agent admitted failure to sign using the key.
[12:15] <asac> Permission denied (publickey).
[12:15] <asac> thats the error i had in intrepid for quite a while ;)
[12:15] <didrocks> seb128: some kind of "don't change the past", ok :)
[12:16] <seb128> asac: well to gnome bug #571422
[12:16] <seb128> asac: btw I opened gnome bug #571423 too for you
[12:16] <seb128> didrocks: right
[12:17] <asac> seb128: cool. could you reproduce outside of NM?
[12:18] <seb128> asac: I could, that's not trivial though (need to write some code to trigger that I guess) and I'm working on other things right now, will try later
[12:18] <seb128> vuntz: ups sorry, busy replying to other people, how do I use xephyr? I'm using this new gdm which has no gdmflexiserver --xnest on this box
[12:18] <asac> seb128: sorry "could" wasnt clear. i asked whether you reproduced it already. dont need to try for now
[12:19] <seb128> asac: no, I didn't try but I figured that letting upstream know about the issue can't hurt
[12:19] <seb128> if they don't do anything about it that will make no change
[12:19] <seb128> if they know what is wrong and fix it that's a win for everybody ;-)
[12:20] <vuntz> seb128: launch Xephyr :1 -ac -br -screen 1024x768
[12:20] <vuntz> seb128: and then DISPLAY=:1 gnome-session
[12:21] <didrocks> seb128: hopefully, commit 6 will be the right one :)
[12:23] <seb128> vuntz: no I don't get the issue in xephyr
[12:27] <seb128> didrocks: uploaded
[12:29] <vuntz> seb128: ah, interesting.
[12:29] <vuntz> seb128: intel driver?
[12:29] <seb128> vuntz: yes
[12:29] <seb128> well I got the issue during the sprint on my laptop which is intel
[12:29] <seb128> I'm on my desktop right now which is ati
[12:30] <didrocks> seb128: thanks seb :)
[12:30] <seb128> let me try in my session
[12:30] <vuntz> seb128: can you reproduce with ati?
[12:30]  * vuntz is pretty sure it's one intel driver bug
[12:30] <seb128> I don't get it
[12:30] <seb128> ok, why would the driver create the issue?
[12:30] <seb128> some xevent not triggered?
[12:31] <seb128> compiz gets confused too on that box, it consider the screen limits to be where they were before the xrandr switch
[12:31] <seb128> bryce: ^ iz intel bog?
[12:31] <vuntz> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=523408
[12:31] <vuntz> seb128: my guess
[12:31] <seb128> vuntz: ok thanks
[12:32] <vuntz> metacity works because we fixed it, iirc ;-)
[12:33] <seb128> mvo: fix compiz!
[12:33] <mvo> seb128: its not broken ;)
[12:33] <seb128> vuntz: but that bug would also make gnome-panel being wrongly fit for the screen on normal session not only after xrandr changes no?
[12:34] <seb128> vuntz: we had bugs were people have an output enable and it's broken all the time for them I think
[12:34] <seb128> vuntz: where the xrand bug is only after switching modes, or that trigger the vga by some way but calling xrand doesn't list the vga as being enabled
[12:34] <seb128> mvo: do you have intel video cards? ;-)
[12:35] <mvo> seb128: I can get hold of a machine with hintel
[12:35] <seb128> mvo: don't bother, I was just curious to know if you were getting the issue too there
[12:36] <vuntz> seb128: I don't know what's wrong. I just know that it's likely not a panel bug ;-)
[12:36] <seb128> vuntz: it seems weird to me that the bug is an xorg one since restarting gnome-panel makes it work correctly
[12:37] <seb128> vuntz: why would it behave correctly after a restart if xorg was reporting wrong informations?
[12:37] <seb128> that's not consistent, it seems that it rather doesn't detect that xrandr has been used and that it should refresh the screen infos or something
[12:39] <seb128> vuntz: other small thing, do you get the clock tooltip displayed on the other side of the screen when clicking on the clock applet to display the calendar?
[12:40] <vuntz> seb128: got a report of this. And then the guy told me it happened in evo too. So gtk+ bug :-)
[12:40] <seb128> ok what I was assuming, gnome-panel didn't change a lot this cycle
[12:40] <vuntz> seb128: if it doesn't work in compiz, is it really a panel bug? ;-)
[12:40] <vuntz> oh, it did have some change
[12:40] <vuntz> not for this kind of stuff
[12:41] <seb128> vuntz: compiz can be buggy too ;-)
[12:41] <seb128> vuntz: I'm just wondering what layer in xorg is wrong
[12:41] <seb128> because as said restart gnome-panel works
[12:41] <seb128> which means there is a way to get correct informations from xorg
[12:41] <seb128> so I'm wondering if there is some sort of update signal that should be sent and is not
[12:42] <seb128> or something around those lines
[12:42] <seb128> if I can get details I can try to ping bryce about the issue
[12:44] <vuntz> seb128: the panel gets a signal from gtk+, fwiw
[12:44] <vuntz> so if there's someone to blame it's between xorg and gtk+
[12:44] <seb128> ok
[12:45] <seb128> so either it doesn't get the signal
[12:45] <seb128> or the geometry query is not correct
[12:45] <seb128> I tend to lean toward a driver bug too if that's intel specific
[12:45] <seb128> vuntz: thanks for the informations there ;-)
[12:48] <seb128> vuntz: other quick question, do you know if something started looking at why the gnome-session dialog are not themed in the current 2.25 version?
[12:48] <seb128> vuntz: I might try to look at this afternoon if nobody else is on it yet
[12:49] <vuntz> seb128: didn't look at it, but I was wondering if this was because of g-s-d is launched
[12:49] <vuntz> "how g-s-d..."
[12:49] <seb128> well xsettings should apply dynamically
[12:50] <seb128> starting gnome-settings-daemon manually after the session doesn't workaround the issue
[12:50] <seb128> the settings apply to normal gtk applications but not to gnome-session
[12:51] <vuntz> seb128: right, but something changed
[12:51] <vuntz> and I'm not sure what it could be :-)
[12:53]  * seb128 grrrrs a no gnome-session-remove in the rewrite
[12:53] <seb128> a-> at
[12:57] <crevette> yeah I was unable to remove nautilus yesterday from the session to test something,
[13:05] <vuntz> it's quite easy to remove apps
[13:05] <vuntz> pkill $app; pkill $app; pkill $app; etc.
[13:07] <mvo> while true; do pill $app; done ;) ?
[13:07] <vuntz> mvo: that's advanced shell usage. I'm not that clever
[13:07] <mvo> lol
[13:09] <pochu> bash: pill: command not found
[13:09] <pochu> :)
[13:10]  * mvo can do shell, but he can not type!
[13:11] <seb128> vuntz: gnome-session respawn those automatically though
[13:11] <seb128> vuntz: ie nautilus
[13:12] <seb128> brb
[13:13] <dholbach> hello my desktop friends
[13:14]  * pochu waves at dholbach :)
[13:14] <dholbach> can somebody tell me how I can debug what's happening with my ssh connection
[13:14] <dholbach> ?
[13:14] <dholbach> I have a hunch that something's wrong with seahorse or something
[13:15] <dholbach> ssh -v  gives me "Agent admitted failure to sign using the key"
[13:16] <ember> http://bugzilla.gnome.org/show_bug.cgi?id=571422
[13:16] <dholbach> thanks a bunch ember
[13:16] <dholbach> strangely enough it still works on my i386
[13:16] <dholbach> just not on my amd64
[13:16]  * ember hugs dholbach
[13:17] <rickspencer3> asac: ping
[13:17] <asac> rickspencer3: pong
[13:17] <rickspencer3> asac: msg?
[13:18] <dholbach> ember: followed up on the bug
[13:18] <dholbach> muchas gracias
[13:18] <dholbach> when I log into my amd64 from the i386, I can still ssh without problems
[13:18] <dholbach> makes using bzr a bit of a pain
[13:19]  * dholbach hugs seb128
[13:19] <seb128> dholbach: what?
[13:19]  * seb128 hugs dholbach
[13:19] <seb128> dholbach: use ssh-add
[13:19] <dholbach> seb128: talking about gnome bug 571422
[13:19] <seb128> right
[13:19] <dholbach> other than that... how's the desktop world ticking along? all good?
[13:20] <seb128> set SSH_AUTH_SOCK= to the ssh-... directory
[13:20] <seb128> and use ssh-add
[13:20] <seb128> yes, we are mostly uptodate and not too buggy ;-)
[13:20] <seb128> and how is the community world?
[13:20] <dholbach> busy, busy as always
[13:20] <seb128> the sponsoring queue seems reasonable again now
[13:20] <dholbach> today's loco docs day
[13:21] <dholbach> seb128: main yes, universe not yet :)
[13:21] <dholbach> but a lot of people put some more effort into it, which is nice
[13:21] <seb128> I was pondering doing some work there or letting motu clean it
[13:21] <dholbach> if you see something interesting and have a little bit of time, consider doing it :)
[13:21] <dholbach> it makes me a happy man :)
[13:21] <dholbach> not only you, but everybody else too
[13:22]  * huats hugs seb128 and dholbach (advantage of having long arm)
[13:22] <dholbach> hiya huats
[13:22] <dholbach> haha
[13:22] <dholbach> a lot of people put good efforts into merging important fixes from debian which is fantastic
[13:22]  * dholbach is happy with the new people in MOTU land
[13:22] <seb128> dholbach: let's wait for tomorrow
[13:23] <seb128> then huats and didrocks can clean the universe sponsoring list ;-)
[13:23]  * dholbach goes back to 5aday-automation :)
[13:23] <dholbach> haha
[13:23] <dholbach> exactly
[13:23] <huats> ;)
[13:23] <dholbach> the French mafia
[13:23] <huats> well
[13:23] <didrocks> seb128: :p
[13:23] <huats> i am sure didrocks and I will be happy to help
[13:23] <huats> :)
[13:23] <didrocks> for sure
[13:23] <huats> (but before there is the MC :))
[13:24] <didrocks> (and to have to wake up early, hey huats ;))
[13:24] <dholbach> yes, and as it's going to be 7:00 UTC and everybody will be grumpy, we'll grill you properly
[13:24] <huats> btw dholbach in the new process, do we need to prepare anything ?
[13:24] <seb128> ;-)
[13:24] <huats> I am sure you will dholbach
[13:24] <didrocks> great \o/
[13:24] <seb128> dholbach: do I need to be there?
[13:24] <didrocks> I love to be grilled ;)
[13:24] <dholbach> no, you guys sent in good applications, you're fine
[13:24] <dholbach> seb128: no
[13:24] <seb128> cool
[13:24] <huats> usually I am the cooker :)
[13:24] <seb128> it's way too early ;-)
[13:25] <huats> seb128:  lucky you :)
[13:25] <didrocks> seb128: lucky man, you can sleep during this time :)
[13:25] <huats> seb128: if you want we can give you wake up call ;)
[13:25] <dholbach> seb128: so you prefer writing a bit more text on the application to getting up early for a meeting? :)))
[13:25] <seb128> vuntz: I found the commit which broke the gnome-session theming
[13:25] <dholbach> hiya vuntz!
[13:25]  * seb128 hugs dholbach
[13:26] <huats> pochu: I sent you the check-symbol stuff
[13:26] <dholbach> I see... lots of stuff going on in Desktop land
[13:26] <dholbach> rickspencer3: you have a great community in here! :-)
[13:26] <didrocks> huats: you have to explain me again what you added, because I used the old one yesterday ;)
[13:26] <huats> didrocks: the idea, with my stuff
[13:26] <rickspencer3> dholbach: there is a great community here, yes
[13:27] <huats> is that you can run it on your intrepid, even to test a jaunty stuff
[13:27] <dholbach> rock on my desktop friends and thanks again for the pointer for the broken seahorse
[13:27] <rickspencer3> but I think I don't think it's mine :) I think I joined a great community ;)
[13:27] <didrocks> huats: using pbuilder login (I was thinking about using this trick)
[13:27] <vuntz> seb128: oh, cool. Which one?
[13:27] <didrocks> dholbach: see you tomorrow :)
[13:27] <dholbach> didrocks: yeah :)
[13:28] <seb128> vuntz: 5192 and 5193, ie the one which added the presence api
[13:29] <pochu> huats: thanks! I'll look at it later :)
[13:29] <huats> didrocks: it is a possibility also
[13:31] <seb128> vuntz: not a small commit, trying to figure what is creating the issue there
[13:41] <ember> is anybody working on tracker? mvo or pochu perhaps?
[13:41] <mvo> not me
[13:41] <pochu> ember: not me either, feel free to do the merge ;)
[13:42] <ember> hmm ok i will have a look
[13:42] <ember> btw mvo thanks for gtsharp2 it was blocking tomboy
[13:45] <mvo> ember: thank you work doing the update
[14:08] <huats> seb128: I am testing the gnome-doc-utils update... the documentation created by it, is the one used by yelp right ?
[14:08] <seb128> huats: correct
[14:08] <seb128> hey hggdh
[14:09] <huats> seb128: ok great
[14:09] <huats> :)
[14:21] <seb128> hggdh: there?
[14:27] <hggdh> seb128, yes
[14:27] <hggdh> hi
[14:28] <seb128> hggdh: so if you run seahorse, go to the password tab it's empty?
[14:28] <seb128> you don't have default or login lines?
[14:29] <hggdh> seb128, no, no keyring lines at all
[14:29] <seb128> and nothing typed in the filter there?
[14:29] <hggdh> nope
[14:29] <seb128> weird
[14:29] <seb128> so your bug is basically similar to bug #327481?
[14:30] <hggdh> looking it up
[14:30] <hggdh> seb128, indeed. File/New/Password Keyring does not do anything
[14:31] <hggdh> so mine can be set as a dup of this one
[14:31] <seb128> ok, doing that
[14:31] <seb128> the new doing nothing is yet another issue
[14:31] <seb128> seahorse lists my keyrings and password correctly but new doesn't do anything there
[14:31] <hggdh> ah
[14:32] <seb128> perhaps you could open the bug on bugzilla since you get the issue?
[14:32] <hggdh> yes, will do
[14:32] <seb128> it's working for me so I can't reply to the upstream questions if there is any there
[14:32] <seb128> thanks
[14:32] <hggdh> seb128, welcome
[14:33] <mclasen> file/new/ssh is bizarre
[14:34] <hggdh> ?
[14:34] <mclasen> that help button is really misplaced
[14:35] <hggdh> oh
[14:35] <hggdh> perhaps a new bug on it would be good
[15:35] <bryce> seb128: re the panel bug, it'd be helpful to have a simple test case to demonstrate the issue.  Offhand it's not obvious to me at what level the breakage could be happening.
[15:35] <seb128> bryce: if you read the discussion it's not obvious to me either ;-)
[15:35] <seb128> bryce: but I don't get the issue in xephyr or using an ati driver
[15:35] <bryce> seb128: the patch by federico sounds like it is against Xinerama rather than Xrandr, and in reading it I'm not sure it would solve the problem.  Good to have for reference just in case though.
[15:36] <seb128> right I don't think that's the exact same issue
[15:36] <seb128> but gtk and gnome-panel don't change between those installations and the issue seems to be intel specific
[15:36] <seb128> so xorg behaves differently on intel in some way
[15:36] <bryce> mm
[15:37] <seb128> compiz is buggy on intel too btw
[15:37] <vuntz> bryce: I think you should blame seb128. It's the easy way, really
[15:37] <bryce> intel is buggy too all by itself ;-)
[15:38] <bryce> anyway, if we have steps to reproduce, I can push it upstream as an -intel bug and see what happens
[15:38] <bryce> they're pretty responsive, including if it's an xserver bug rather than -intel
[15:39] <bryce> my worry is that it's going to be more of an xrandr protocol level issue... like some functionality not yet provided for setting/getting the primary display
[15:39] <bryce> which would be tough to get a fix for
[15:39] <bryce> but if it is confirmed to work on -ati, then that suggests it's not a protocol issue
[15:39] <seb128> well at least we would know what the issue is
[15:39] <bryce> right
[15:39] <seb128> well, it works fine on ati and xephyr for me
[15:40] <seb128> and vuntz suggested from start that would be an intel bug
[15:40] <bryce> did you also reproduce without xephyr?
[15:41] <seb128> no, only on intel
[15:41] <seb128> ati and xephyr work fine
[15:41] <bryce> is there a bug id#?  And steps to reproduce written down?
[15:43] <seb128> let me look, I did got a lot of comment about that during the sprint
[15:43] <seb128> bug #325800 that you open is around those lines but slightly different
[15:46] <bryce> yeah might be related but not the exact issue
[15:46] <bryce> fwiw that is davidm's eeepc that he has promised to help do testing with
[15:53] <seb128> bryce: ok, no bug that I can found describing the issue, I will try to debug a bit and open one later
[15:53] <rickspencer3> bryce: https://bugs.edge.launchpad.net/xorg-server/+bug/327175
[15:53] <bryce> excellent; subscribe me to it once it's open
[15:54] <seb128> ok
[15:54] <seb128> brb doing a new bootchart
[16:16] <andreasn> mpt, ping
[17:29] <seb128> vuntz: btw, http://bugzilla.gnome.org/show_bug.cgi?id=570765
[17:30] <seb128> vuntz: you were asking for a stacktrace of clock applet hanging gnome-panel in 2.25
[17:34] <vuntz> seb128: added a comment
[17:35] <seb128> vuntz: thanks ;-)
[17:35] <seb128> vuntz: it does happen with 2.25.90
[17:36] <vuntz> ah. Well. No luck. I blame eds
[17:38] <seb128> well, e-d-s is likely crashing
[17:38] <seb128> still the clock should not hang
[17:42] <crevette> I did had this bug yesterday evening I guess
[17:48] <mvo> seb128: let me know when you are close to your laptop again (no rush), I have a theory about the compiz bugs you mentioned the other day
[17:49] <seb128> mvo: ok, that will probably be in 15 minutes but I'll not be around it for long tonight since I go to sport soon after that, other that's for tomorrow
[17:49] <seb128> mvo: do you want me to try something?
[17:49] <seb128> ups
[17:49] <mvo> seb128: just a gconf dump of your plugin settings
[17:49] <seb128> ok
[17:49] <mvo>  /apps/compiz/general/allscreens/options/active_plugins
[17:49] <mvo> that is all I need
[17:49] <seb128> that's probably the default set
[17:50] <seb128> or rather select normal in the appareance capplet
[17:50] <mvo> I think that the crucial bit, it seems like there is some reordering going on and that makde the default not the gconf default
[17:50] <seb128> I did that after the abi breakage issue
[17:50] <mvo> and to confirm I want to see yours :)
[17:50] <seb128> ok
[17:52] <vuntz> seb128: hope your question in the bug is not for me ;-)
[17:52] <seb128> vuntz: you or mbarnes whoever want to reply
[17:57] <seb128> time for sport and dinner bbl
[18:47] <mvo> maxb: you had the compiz issues with gnomecompat too, right? is your system still in this state? if so, I would like to ask for debugging help :)
[20:31] <maxb> mvo: Hi, just saw bugmail. Is your info request still useful after I've manually ticked the gnomecompat plugin on?
[20:33] <mvo> maxb: I guess, please put it into the report that you did that :)
[20:33] <mvo> maxb: a vanialla one would be better, but I'm sure I find someone with one (or I can try to reproduce it with some livecd magic)
[20:33] <mvo> maxb: I have a theory about the problem at least
[20:34] <maxb> Hmm.. I'm reading the debdiff now.... won't that solution fail if the user has played around in ccsm at all?
[20:37] <maxb> w.r.t. the addition of "gnome-terminal" as the terminal command line (in the debdiff) - somehow it was figuring that out anyway - my problem turned out to be that the gnomecompat plugin defaults the "terminal" keybinding to disabled
[20:56] <maxb> Hmm... So gnome-keybinding-properties syncs the settings it makes into compiz's gconf area?