[00:35] <seb128> ok, time to go to bed
[00:35] <seb128> robert_ancell: do you have specific plans for the day?
[00:36] <robert_ancell> seb128: trying to reproduce bug 349009... And then just general bug hunting
[00:36] <seb128> ok thanks
[00:36] <seb128> totem could do with some active bug triage if you want to have a go to it during the day
[00:36] <robert_ancell> seb128: ok, will do
[00:37] <seb128> there is no specific issue on my list right now so I think bug triage is a good plan for today ;-)
[00:37] <seb128> thanks
[00:37] <seb128> have a nice day, time to sleep here ;-)
[00:37] <robert_ancell> good night!
[01:38] <bryce> heya robert_ancell
[01:40] <robert_ancell> bryce: hello
[01:41] <robert_ancell> bryce: do you know much about X keyboard events?
[01:42] <bryce> robert_ancell: a little
[01:43] <robert_ancell> bryce: I'm looking at bug 300954 and how gnome-settings-daemon uses XGrabKey
[01:44] <robert_ancell> bryce: I'm just wondering if GNOME should be sniffing the ctrl key rather than stealing it?  Or if that is possible in X
[01:45] <bryce> hmm
[01:46] <bryce> robert_ancell: were you able to narrow in on what update led to the problem?  Appears there is a narrow enough window (Nov 14-22)
[01:47] <bryce> robert_ancell: also, are you familiar with the new fangled hotkey troubleshooting guide?  (At http://wiki.ubuntu.com/Hotkeys/)
[01:47] <robert_ancell> bryce: haven't tried that yet - good point I should look into that first.  Haven't seen the hotkeys, thanks.
[01:48] <bryce> interesting that enabling the locate mouse pointer feature triggers it... that sounds really familiar
[01:48]  * bryce ponders
[01:48] <bryce> ok here's a wild guess
[01:48] <bryce> we've found that with certain hardware, some hotkeys are "owned" by the mouse input device
[01:49] <bryce> for whatever reason, the manufacturer didn't have a better place for them (since they're handled by ACPI) so stuff them into the mouse device
[01:49] <bryce> perhaps this mouse pointer feature thingee is stealing the entire device
[01:50] <bryce> and since those keys are keys, not mouse stuff, they aren't passed along properly
[01:50] <bryce> robert_ancell: so... if my theory is right, this might be a tough thing to fix for intrepid
[01:51] <robert_ancell> bryce: cool, thanks for the idea
[01:51] <bryce> robert_ancell: I would suggest starting by familiarizing yourself with that troubleshooting guide, then speak with pitti and slangasek; I think the fixes can be had in certain acpi handling code.
[01:51] <bryce> it likely is already fixed in jaunty, so maybe one of them knows what to look at backporting, if it definitely needs fixed in intrepid.
[01:51] <robert_ancell> bryce: I can reproduce on my system in Jaunty
[01:52] <robert_ancell> bryce: anyway, got to head out - thanks for the pointers, hopefully have some more idea by tomorrow :)
[01:52] <bryce> robert_ancell: aha that's actually good!  So yes, follow the hotkeys troubleshooting guide and it'll help walk you through identifying where the error is showing up
[01:52] <bryce> great, cya
[06:49] <pitti> Good morning
[06:49] <ajmitch> hi pitti
[06:50] <pitti> hey ajmitch, how are you?
[07:30] <ajmitch> pitti: good, sorry I got distracted :)
[08:18] <pitti> hey seb128
[08:18] <seb128> good morning pitti
[08:19] <pitti> seb128: still remember me whining about gpg and seahorse yesterday?
[08:19] <seb128> yes
[08:19] <pitti> seb128: bug 352180
[08:19] <seb128> I've noticed issues too
[08:19] <pitti> seb128: fixed, and won us 1.3 MB of CD space
[08:19] <seb128> waouh!
[08:19] <seb128> how much CD space do we have nowadays? ;-)
[08:20] <pitti> GIBIBYTES!
[08:20] <seb128> ;-)
[08:22]  * Amaranth had to download an xubuntu livecd to do work on a computer today
[08:22] <Amaranth> didn't have 3 hours to get the dvd :P
[08:22] <seb128> how is xubuntu nowadays?
[08:22] <Amaranth> well, half the panel fell over when I clicked on it
[08:23] <Amaranth> Probably because libxfce4menu 4.6 doesn't support <MergeFile> and that's the first thing alacarte creates
[08:29] <pitti> seb128: wow, we have 11 MB on i386 and 7 MB on amd64
[08:30] <seb128> pitti: good good ;-)
[08:41] <seb128> mvo: hey
[08:41] <seb128> mvo: could you look at bug #344019?
[08:49] <mvo> seb128: sure
[08:49] <seb128> we get so many weird upgrade bugs that's annoying
[08:50] <robert_ancell> mvo seb128: Bug thieves!  No, I was going to ask you guys about that one as I'm not an expert on update-alternatives
[08:50] <seb128> hey robert_ancell, how did the bug triage day go?
[08:51] <robert_ancell> seb128: slower than I hoped.  I've been trying to track down bug 300954 but not having a lot of luck.  And when I made changes to gnome-settings-daemon it kept crashing my X :)
[08:51] <seb128> urg
[08:51] <seb128> bad X, no cookie
[08:53] <robert_ancell> what do people think about merging bugs, I've been looking at bug 346664 and bug 323649 -
[08:54] <robert_ancell> they're both due to totem-youtube not being able to download links.  But there's no way totem can tell the difference.
[08:54] <seb128> looking
[08:54] <robert_ancell> I was thinking of pushing upstream as "error message is misleading/confusing"
[08:55] <seb128> agreed
[08:55] <seb128> you can duplicate those and upstream the error message not being clear
[08:55]  * robert_ancell finds seb128 a good bouncing board
[08:56] <seb128> lol
[08:56] <seb128> did you figure what commit broke the g-s-d pointer thing?
[09:04] <robert_ancell> seb128: no, I tried rolling back g-s-d but it didn't seem to fix it
[09:08] <seb128> robert_ancell: weird
[09:08] <robert_ancell> seb128: it's also weird as I can reproduce it but I find the keys work maybe 5% of the time so there's some weird race going on
[09:09] <seb128> we should just drop this locate pointer thing ;-)
[09:15] <robert_ancell> does anyone know in what module the subtitles get rendered in totem?
[09:15] <seb128> what do you mean? that's a plugin there
[09:16] <robert_ancell> totem or gstreamer?
[09:16] <seb128> the video rendering is done using gstreamer
[09:17] <robert_ancell> and that includes subtitles? or are they overlaid by totem?
[09:17] <seb128> there is python code in totem to get the subtitles
[09:17] <seb128> not sure about the on screen part, likely using some gstreamer pipeline for that
[09:17] <seb128> I've not looked at this code yet
[09:24] <seb128> ok, I did catch up with my bugmails already
[09:24] <seb128> that was quick today
[09:24] <seb128> robert_ancell: you didn't flood it with triaged totem bugs as I expected ;-)
[09:25] <robert_ancell> seb128: i tried!! :P
[09:29] <seb128> robert_ancell: useful hint, triage by newer bugs first listing only new, confirmed and triaged not sent upstream yet
[09:29] <seb128> robert_ancell: that gives you a decent list of what needs to be triaged
[09:31] <robert_ancell> seb128: through "advanced search"?  I've been trying to sort the columns
[09:31] <seb128> yes
[09:31] <seb128> https://launchpad.net/ubuntu/+source/totem/+bugs?advanced=1
[09:31] <seb128> select "newest first" in the combo
[09:31] <seb128> check new confirmed triaged
[09:32] <seb128> and at the bottom of the page
[09:32] <seb128> "Show bugs that need to be forwarded to an upstream bug tracker "
[09:32] <seb128> "Show bugs that are not known to affect upstream "
[09:32] <seb128> you can probably do a smart bookmark for that url
[09:32] <seb128> with the package name replaced by a keyword
[09:33] <seb128> so you can list easily what is triage for whatever package
[09:55] <seb128> didrocks: hello
[09:57] <seb128> didrocks: do you think you could have a go to bug #182345? it's supposed to be fixed in svn so a backport would be nice there
[10:18] <seb128> robert_ancell: we usually assign desktop bugs to "desktop-bugs", not very important but we got used to that, it makes those lists in the +bugs page for the desktop-bugs team on launchpad
[10:18] <seb128> so if you could do the same ... ;-)
[10:20] <seb128> robert_ancell: oh and you might want to subscribe to upstream bugs when you add a patch, ie http://bugzilla.gnome.org/show_bug.cgi?id=576022 got some new comments
[10:43] <robert_ancell> night all
[11:44] <asac> ArneGoetje: there? can you give me the ffox xpi's you last imported?
[11:44] <asac> i need to update them in on rookery as well
[12:03] <pitti> seb128: argh, you gave me a hard time with notify-osd
[12:03] <seb128> re
[12:03] <seb128> pitti: how so?
[12:04] <pitti> seb128: it seems you didn't merge from trunk when updating to notify-osd, and didn't use bzr bd
[12:04] <pitti> I wondered why stracciatella-session broke
[12:04] <seb128> I don't know about all those things
[12:04] <pitti> and noticed that our .service patch was missing
[12:04] <seb128> I take tarballs
[12:04] <seb128> bzr get
[12:04] <seb128> copy the debian directory and use that
[12:04] <pitti> ok, sorry
[12:04] <pitti> ah, I see
[12:05] <seb128> I think I start disliking bzr again
[12:05] <seb128> everybody has a different workflow
[12:05] <seb128> and it's such annoying to figure what you are supposed to do
[12:05] <seb128> such -> so
[12:05] <pitti> well, it's the bzr bd workflow as documented on the wiki
[12:05] <seb128> we only have the debian directory in bzr as documented on the wiki
[12:06] <seb128> I don't know how to magically switch from a checkout which has a source which is not the source we want to use
[12:07] <seb128> ie why having everything in bzr if we just use the debian directory over tarballs?
[12:07] <seb128> or should I not use tarballs but run autogen.sh by hand?
[12:07] <seb128> and then bzr-buildpackage?
[12:07] <pitti> so, for the 0.9.7 update:
[12:08] <pitti> bzr merge lp:notify-osd
[12:08] <pitti> ^ trunk
[12:08] <pitti> dch
[12:08] <pitti> debcommit
[12:08] <pitti> then dch -r/debcommit -r
[12:08] <pitti> and bzr bd -S
[12:08] <seb128> hum
[12:08] <seb128> and that will use the tarball automagically?
[12:09] <pitti> yes, if changelog says 0.9.7, bzr will fetch the orig.tar.gz from LP
[12:09] <seb128> I still understand why we have the full source in bzr is we use tarballs or if we should not use tarballs but trunk
[12:09] <pitti> I added a working debian/watch
[12:09] <seb128> +don't
[12:09] <pitti> well, I use the orig.tar.gz because the DX guys publish them
[12:09] <pitti> so I don't see a reason why not to use them
[12:09] <seb128> I would like much better if we had only the debian directory in bzr
[12:09] <seb128> that would be much less confusing
[12:09] <pitti> but having the full source in bzr makes it easier to merge/cherrypick changes
[12:10] <pitti> seb128: I see; I'm not objecting to debian/ only
[12:10] <seb128> then you have changes out of the debian directory
[12:10] <seb128> which I try to avoid usually
[12:10] <pitti> yeah, there are some, like our stracciatella fix
[12:10] <seb128> that's a totally different workflow than everything else
[12:10] <seb128> we usually add patches in the debian directory
[12:10] <pitti> seb128: when I started the branch, we didn't get frequent upstream releases yet
[12:10] <seb128> rather than messing with the diff.gz
[12:10] <pitti> so it was painful to only use tarballs
[12:11] <seb128> we never did snapshot to jaunty either ...
[12:11] <pitti> we did in the beginning
[12:12] <seb128> https://edge.launchpad.net/ubuntu/+source/notify-osd has only -0ubuntu<n> uploads but ok
[12:12] <pitti> yeah, some without orig.tar.gz
[12:12] <seb128> anyway sorry for the mess
[12:12] <pitti> seb128: no problem, not your fault
[12:13] <pitti> it was good to understand where the confusion came from
[12:13] <seb128> I think I will just avoid touching it and let you deal with it so I don't break anything next time
[12:13] <pitti> I'm so used to native packages and working with VCS that I'm not aware of the problems
[12:13] <seb128> or try what you described before and see if I confuse somebody again ;-)
[12:13] <pitti> so if you prefer, we can convert this to debian/ only
[12:13] <seb128> well, I will try what you described before
[12:13] <pitti> but given that our long-term goal is actually into the other direction (full source in bzr), that would feel weird
[12:13] <seb128> maybe you could add that to DesktopTeam/Bzr
[12:13] <seb128> "cases when the full source is in bzr"
[12:13] <pitti> will do
[12:14] <seb128> thanks!
[12:14] <seb128> I was not aware of "bzr bd" which is what confused me there I think
[12:14] <seb128> I was copying the debian directory by hand in an unpacked tarball...
[12:14] <pitti> it's bzr-builddeb
[12:14] <seb128> well for me you should be in the source you want to build ;-)
[12:15] <seb128> not in a directory which has an autogen and no configure
[12:15] <seb128> I didn't figure it would get the tarball and not use the bzr source
[12:15] <pitti> yeah, sorry, it's merge mode
[12:15] <pitti> much like debian/ only
[12:15] <seb128> I've learnt something today ;-)
[12:15]  * pitti hugs seb128
[12:15]  * seb128 hugs pitti
[12:16] <pitti> seb128: we can avoid autoconfiscation because the orig.tar.gz has them, so in the merged package it's all there
[12:16] <james_w> pitti: I was a bit confused when you set up a package as merge mode, but made it full source. I don't understand what that buys you.
[12:16] <seb128> well as said I though it would do the equivalent of "debuild" in the bzr get dir
[12:16] <seb128> ie there is no configure there
[12:17] <pitti> james_w: well, it's "full source" in the "trunk" sense, but not in the "orig.tar.gz with autoconfiscation" sense
[12:17] <pitti> james_w: it's convenient for me to being able to just merge new versions/fixes from trunk
[12:17] <pitti> james_w: you think I should avoid this mode?
[12:18] <james_w> hmm
[12:18] <james_w> which package was it, I'd like to look at the branches
[12:18] <pitti> oh, lasagne is ready .. /me -> lunch
[12:18] <james_w> enjoy :-)
[12:18] <pitti> james_w: lp:~ubuntu-desktop/notify-osd/ubuntu/
[12:20] <pitti> james_w: so perhaps it's cleaner to not use merge mode, and do autoconfiscation ourselves? and ignore upstream orig.tar.gz?
[12:20] <pitti> james_w: what way would you recommend if upstream has a bzr trunk, and releases tarballs?
[12:20] <james_w> you want to use the "merge-upstream" command
[12:21] <james_w> you give that the upstream branch and the tarball and it merges them in
[12:22] <james_w> you end up with 3 branches in essence, the pure upstream trunk, the Ubuntu "upstream" branch, which corresponds to the .orig.tar.gz, so contains the autoconf stuff
[12:22] <james_w> and then the packaging branch
[12:22] <james_w> and since Jaunty pristine-tar is used, so you can build the package without download the tarball using the watch file even
[12:23] <james_w> unfortunately we don't have good docs on it yet, as it's quite new, but it is the way I would recommend, as it most closely represents what is happening, and gives you the flexibility to cherry-pick etc.
[12:24] <james_w> like seb128 some people don't like changing things outside of debian/, but you don't have to do that really.
[12:25] <james_w> I disagree, but I can understand the reasons
[12:26] <james_w> seb128: on an unrelated note, I have a dual screen issue. When the second screen is placed "below" the primary one, fullscreen apps end up underneath the bottom panel.
[12:27] <james_w> it seems that they don't detect the width of the panel as usual, and draw to the bottom of the primary screen
[12:27] <james_w> do you know what component would be at fault there?
[12:29] <james_w> it happens with both compiz and metacity fwiw
[12:31] <seb128> james_w: sorry I was writting my activity report for the week ;-)
[12:32] <james_w> np
[12:32] <seb128> no real idea about this one, multiscreen is still quite buggy, I would say either gtk or the wms there though
[12:38] <pitti> re
[12:39] <pitti> james_w: ah, thanks; I'll read about merge-upstream
[12:39] <pitti> james_w: so far I was just using the "merge" workflow in jockey: fix three bugs in trunk, merge into ubuntu, debuild, done
[12:39] <pitti> james_w: with that I didn't need to do a new upstream release for every fix, and neither did I have to mess with debian/patches
[12:40] <james_w> yep
[12:40] <pitti> I think I just adopted this workflow 1:1 to notify-osd
[12:40] <pitti> and I would *really* like to avoid getting back to using a patch system if we already have everything in bzr
[12:40] <pitti> that would be so backwards..
[12:40] <james_w> I agree
[12:42] <pitti> james_w: while we are at it, is there a reason why I can do "bzr bd -S", but have to do "bzr bd -- -b"?
[12:43] <james_w> not really a good one
[12:44] <pitti> ok; it's just a tiny nitpick anyway
[12:44] <james_w> "-S" is implemented as an option to bd
[12:44] <james_w> "--" means pass everything else to debuild
[12:44] <pitti> right, I know
[12:44] <pitti> my q was why -S is passed, but not -b
[12:44] <james_w> I didn't want to implement every debuild option
[12:44] <pitti> yeah, true that
[12:44] <seb128> james_w: the gnome-panel multimonitor change would be nice to have I think if you want to give it some testing and work on a debdiff ;-)
[12:44] <james_w> -S because that was the first that was added
[12:45] <james_w> so as I said, not a good one
[12:45] <james_w> I'd like to extend bzr to just ignore options it doesn't recognise for specific commands, which would make "--" go away
[12:47] <james_w> seb128: I'll have a look
[12:47] <seb128> james_w: thanks
[12:57] <seb128> pitti:
[12:57] <seb128>   File "/usr/lib/python2.6/UserDict.py", line 22, in __getitem__
[12:57] <seb128>     raise KeyError(key)
[12:57] <seb128> KeyError: 'Stacktrace
[12:57] <seb128> pitti: that's the 3 retracer crash on a similar error since yesterday do you know what's going on?
[12:57] <pitti> hm, not really
[12:57] <pitti> seb128: do you have a minute to file a bug against apport with the output and the crashed bug?
[12:58] <seb128> yes
[12:58] <pitti> merci
[12:58] <pitti> please assign it to me
[12:58] <seb128> will do, thanks
[12:59]  * pitti hugs seb128
[12:59] <pitti> sorry for all those new retracer problems
[12:59] <pitti> seems whenever I fix one, the next one comes out of thin air
[13:00]  * seb128 hugs pitti
[13:00] <seb128> pitti: not your fault
[13:00] <seb128> bug #352331 assigned to you
[13:01] <pitti> I think the dup db lock timeouts are gone for good, consolidation just takes one hour now
[13:01] <seb128> excellent
[13:01] <pitti> I need to find a day to switch those over to launchpadlib
[13:01] <pitti> to fix that for good, and consolidation only taking like 5 minutes
[13:01]  * pitti args at p-lp-bugs
[13:01] <pitti> seb128: thanks
[13:01] <seb128> urg
[13:01] <seb128> there is still quite some backlog
[13:02] <seb128> around 150 bugs waiting for i386 retracing
[13:02] <seb128> pitti: I rm the lock just to see if it crashes again on the same issue
[13:02] <pitti> if it happens again, just untag the bug
[13:03] <pitti> seb128: I need to run out for about 2 hours in 15 minutes, so I'm afraid I won't have time for retracer shepherding today
[13:03] <seb128> yeah, that's what I did for the other ones yesterday ;-)
[13:03] <seb128> pitti: that's ok, I can just untag those which are an issue
[13:03] <seb128> pitti: hum, at what time is the meeting today european time?
[13:03] <seb128> did we stick to same european or same utc time?
[13:03] <pitti> seb128: 18:30
[13:03] <seb128> ok
[13:03] <pitti> I have an agenda topic "meeting time"
[13:03] <pitti> for now we should stick to the wiki which says 1630 UTC
[13:03] <seb128> good thanks
[13:04] <seb128> yeah, usually we just used to shift the meeting time
[13:04] <seb128> but let's discuss that during the meeting
[13:04] <seb128> we might also want to reconsider the current one is really late or early for robert_ancell
[13:05] <pitti> right
[13:09] <seb128> mvo: bug #344019 got a reply
[13:09] <james_w> that patch doesn't apply it seems
[13:10] <james_w> where was that page with the GNOME patches from suse?
[13:10] <james_w> perhaps it depends on one of those
[13:10] <james_w> ah, http://tmp.vuntz.net/opensuse-packages/browse.py
[13:12] <mvo> seb128: thanks, strange, that is a pretty unclear report, either a dpkg bug, the user removing stuff in the file or something strange in our packaging scripts
[13:13] <seb128> mvo: or local disk corruption or something similar ...
[13:13] <mvo> seb128: yes
[13:13] <seb128> mvo: want to reassign the bug somewhere else?
[13:14] <mvo> not sure, maybe dpkg - but then those bugs do not get that much attention :/
[13:14] <seb128> mvo: because you think he will get higher attention on totem? ;-)
[13:15] <seb128> I still think we should have an installation-issues components
[13:15] <seb128> at least there would be a place for people to triage those
[13:15] <seb128> nobody is going to chase them on random packages and maintainers will not care about weird dpkg issues and just ignore it too
[13:15] <mvo> true
[13:16] <seb128> anyway I will let you do what you think best and stand on my "let's ignore weird dpkg issues" ;-)
[13:16] <pitti> off for ~ 2 hours, see you later; if anyone has an urgent question, please ring my mobile
[13:17] <chrisccoulson> i have to admit - i often have no idea what do with those installation issue bug reports
[13:19] <mvo> *gar* bug #352317 *gar*
[13:20] <tseliot> seb128: have you seen federico recently? The final version of my patch for this bug is ready: http://bugzilla.gnome.org/show_bug.cgi?id=568160
[13:22] <seb128> chrisccoulson: same here ;-)
[13:22] <seb128> tseliot: no I didn't, is that something we should use?
[13:23] <tseliot> seb128: we have a previous version that works well in Ubuntu. This one is ready to be accepted by upstream though
[13:23] <seb128> tseliot: ok good ;-)
[13:23] <seb128> good job!
[13:23] <tseliot> thanks :-)
[14:24] <rickspencer3> seb128: my calendar got all screwed up this week for some reason
[14:24] <rickspencer3>  some appointments are accounting for dls, and some aren't :(
[14:24] <seb128> rickspencer3: dst?
[14:24] <rickspencer3> yes
[14:25] <seb128> rickspencer3: I'm not picking just tell what about for our call
[14:25] <rickspencer3> in any case, is our call in 1 hour or two hours?
[14:25] <seb128> as you want
[14:25] <seb128> I'm available for any of those times
[14:26] <dobey> pitti: ping
[14:29] <rickspencer3> calc: ping?
[14:33] <asac> hi rickspencer3
[14:33] <rickspencer3> hi asac
[14:36] <seb128> vuntz: is there a way to have an autostart desktop used but not listed in the capplet dialog?
[14:44] <chrisccoulson> seb128 - if i understand you correctly, you can just specify it in /desktop/gnome/session/required_components if you don't want it to appear in the capplet
[14:44] <chrisccoulson> of course, if i've misunderstood you, please ignore me ;)
[14:44] <seb128> chrisccoulson: we have this /etc/xdg/autostart/indicator-applet.py which is there for upgrade reasons
[14:45] <seb128> I'm not sure if that should be listed in the capplet or not
[14:45] <seb128> mpt: ^ opinion?
[14:45] <chrisccoulson> you could give it a desktop file in /usr/share/applications, then list it in /desktop/gnome/session/required_components
[14:45] <chrisccoulson> just like with nautilus and gnome-panel
[14:45] <chrisccoulson> it won't show up in the capplet then
[14:45] <mpt> seb128, what's "the capplet dialog"?
[14:46] <mpt> (... what's a capplet?)
[14:46] <seb128> mpt: gnome-session-properties
[14:46] <dobey> we need something like autostart, but for first-run
[14:46] <seb128> chrisccoulson: thanks for the hint
[14:46] <seb128> dobey: right
[14:47] <dobey> or rather, something more like the RunOnce thing in windows
[14:49] <mpt> seb128, I'm sorry, I don't understand the problem
[14:49] <mpt> seb128, what does indicator-applet.py do?
[14:49] <seb128> mpt: in the gnome-session-properties you have an "Indicator applet" line
[14:49] <seb128> mpt: it does add the indicator applet after upgrade to the gnome-panel configuration
[14:50] <seb128> mpt: we got a bug pointing that this entry was not translatable, which made me thing we should maybe not have listed at all or at least have a better description for it there
[14:52] <mpt> seb128, I agree it should not be listed
[14:53] <mpt> the same way gnome-panel itself isn't
[14:53] <seb128> mpt: ok thanks
[15:06] <james_w> seb128_: wow, thanks. That was quick
[15:06] <seb128_> james_w: you're welcome, thanks for working on it ;-)
[15:07] <james_w> seb128_: would you be willing to provide sponsor feedback on https://wiki.ubuntu.com/JamesWestby/CoreDevApplication ?
[15:07] <james_w> don't worry if you are not
[15:07] <asac> my panel died ;)
[15:07] <seb128_> james_w: I will but not right now
[15:07] <james_w> thanks
[15:07] <seb128_> you're welcome
[15:07] <asac> doesnt even restart ;)
[15:07] <asac> hmm ... seems to be still alive process wise; but not displaying
[15:07] <seb128> asac: does it crash? gdb is your friend there ;-)
[15:08] <asac> seb128: i dont hink i can reproduce
[15:08] <asac> it happened when hitting enter in pinentry
[15:08] <seb128> what did you do?
[15:08] <seb128> weird
[15:08] <asac> let me attach to the running process
[15:08] <seb128> does alt-f1 or alt-f2 does something?
[15:09] <asac> gdb shows me that the only thing left is a running mainloop
[15:09] <asac> no alt-f1 doesnt do anything
[15:09] <asac> nor f2/3/4
[15:10] <asac> oh
[15:10] <seb128> weird
[15:10] <asac> sorry
[15:10] <asac> alt-f1 opens menu ;)
[15:10] <seb128> the mainloop seems to be normal running case
[15:10] <asac> seems something had the focus before
[15:10] <asac> so yeah. its invisible ;)
[15:10] <seb128> could be your wm or theme or something
[15:10] <asac> alt-f2 works too
[15:10] <asac> window decorations still exist
[15:10] <seb128> it seems to be running
[15:10] <seb128> or those would not work
[15:10] <asac> yeah sure
[15:11] <asac> the process is reawlly there i see it ;)
[15:11] <seb128> does the menu open in the middle of nowhere?
[15:11] <asac> herh
[15:11] <asac> so i can even click it
[15:11] <asac> its just transparent ;)
[15:11] <asac> metacity bug i guess
[15:11] <seb128> could be
[15:11] <seb128> using the composite manager there?
[15:11] <asac> yeah
[15:11] <asac> i think its the second time that happened to me
[15:11] <seb128> I would blame it then
[15:12] <asac> the other incident was weeks ago
[15:12] <asac> does metacity log somewhere?
[15:12] <asac> just .xsession-erors?
[15:12] <seb128> just .xsession-errors I think yes
[15:13] <asac> seb128: http://paste.ubuntu.com/141445/
[15:13] <asac> unfortunately i saw a audacious crash before (20 minutes)
[15:13] <asac> so i think its not the event that killed the panel
[15:13] <seb128> I think those warning are frequent and don't lead to such issues usually
[15:13] <seb128> I would really blame the composite manager there
[15:14] <asac> any forensics we can do?
[15:14] <asac> or just let it go? ;)
[15:14] <asac> asac     24713     1  0 Mar28 ?        00:44:58 metacity --replace
[15:14] <seb128> not that I know
[15:14] <asac> does metacity usually run with 1 as parent process?
[15:14] <seb128> let it go I would say, at least I'm not interested to debug it, enough to do without debugging experimental compositors ;-)
[15:15] <asac> hey. without compisiting manager the notifications are really a regression ;)
[15:15] <calc> rick wants to know when do you think the meeting is today? :)
[15:15] <seb128> I doubt that, gnome-session is starting it
[15:15]  * calc notes that when it normally is scheduled is not what it shows on the calendar
[15:15] <asac> calc: 1h 15 minutes
[15:15] <seb128> asac: no, meeting is in 2h15
[15:15] <asac> so 4:30 UTC i think
[15:16] <calc> normallly it is 16:30 UTC which is 2h15m from now
[15:16] <asac> seb128: err. not according to platform calendar
[15:16] <seb128> asac: we are utc+2 now
[15:16] <seb128> asac: 4:30utc is in 2 hours
[15:16] <asac> seb128: well. we usually keep it
[15:16] <calc> however the calendar is screwed up apparently and is shifted due to euro dst starting
[15:16] <asac> seb128: i mean we adjust to daylight saving
[15:16] <seb128> asac: we didn't this time, pitti added that to the agenda
[15:16] <asac> the meeting is definitly in 1:15 according to calendar here ... not for you?
[15:16] <calc> we can have it either time (i think) rick just wants to know what people think about it
[15:16] <seb128> asac: I asked pitti some hours ago and he said 4:30utc
[15:17] <seb128> asac: which is 18:30 local
[15:17] <asac> he should look at his calendar
[15:17] <asac> pitti: ^^
[15:17] <seb128> asac: I say the calendar is buggy ;-)
[15:17] <asac> heh
[15:17] <calc> asac: i think rick's point about it is whether we like what the calendar says or should we fix it, since it appears to not actually be based off GMT/UTC but london time(?)
[15:18] <asac> it does the right thing ... we always did it that way. the base is london time not UTC ;)
[15:18] <seb128> I don't care either way
[15:18] <asac> most folks have daylight saving
[15:18] <asac> so using london time makes the meeting a constant thing (except for those that dont have daylight issues)
[15:18] <seb128> as said pitti said we stick to 4:30utc today
[15:18] <seb128> and we will discuss it during the meeting
[15:19] <asac> yeah. he should have sent a mail too then ;) ... now i know
[15:19] <seb128> we need to discuss it anyway it's middle of the night for robert_ancell
[15:19] <rickspencer3> ok
[15:19] <asac> hmm. thought that was understood before ;)
[15:19] <seb128> so we might night to pick a different time
[15:19] <asac> ok. lets check then
[15:20] <seb128> asac: well the issue with your constant london time is ... do you expect all the calendar events to shift the same way, ie weekly calls, etc
[15:20] <asac> seb128: given that google calendar does the wrong thing, i would think that everything does that shift yes.
[15:21] <cody-somerville> seb128, Can you make the gnome terminal not show up in Xfce anymore?
[15:21] <cody-somerville> doh
[15:22]  * asac kills his gnome-panel now
[15:22] <asac> \o/ resurrection ;)
[15:22] <asac> magic
[15:22] <seb128> what did you do?
[15:22] <seb128> nothing it just came back?
[15:22] <cody-somerville> seb128, Can you make the gnome terminal not show up in Xfce anymore?
[15:22] <seb128> cody-somerville: no
[15:22] <cody-somerville> Whys?!
[15:23] <seb128> because I don't maintain that software?
[15:23] <seb128> open a bug or a sponsor request having a debdiff on launchpad
[15:23] <cody-somerville> You don't maintain the gnome terminal package?
[15:23] <seb128> no
[15:23] <seb128> we have several people in this team, I'm not looking to this one for a while
[15:23] <asac> cody-somerville: feel free to give me the debdiff
[15:24] <seb128> see the recent uploaders
[15:24] <cody-somerville> asac, okay :)
[15:24] <asac> cody-somerville: please with bug and main-sponsors subscription though
[15:24]  * asac karma whore
[15:24]  * cody-somerville nods.
[15:26] <pitti> hey dobey
[15:26] <pitti> seb128, asac: well, our wiki says 1630 UTC, so I just assume that
[15:28] <rickspencer3> pitti: good point, the wiki shall be the canonical reference
[15:32] <kenvandine_wk> rickspencer3: I haven't been able to get pidgin to crash since our call yesterday
[15:39] <rickspencer3> kenvandine_wk: that's good news
[15:39] <kenvandine_wk> is it working for you now?
[15:40] <rickspencer3> yes
[15:40] <rickspencer3> kenvandine_wk: starting yesterday
[15:40]  * kenvandine_wk isn't happy about it... damn thing crashed for me 3 times... and magically healed itself
[15:40] <kenvandine_wk> although... i never noticed until you pointed it out :)
[16:02] <seb128> kenvandine_wk: do you watch the ekiga bugs?
[16:07] <kenvandine_wk> seb128: not specifically...
[16:07] <seb128> ok
[16:07] <seb128> would you be interested to give an hand on triaging those?
[16:08] <seb128> the bug list has lot of crashers since the 3.2 update
[16:08] <seb128> would be nice to have somebody using ekiga looking at some and sending that upstream if required
[16:08] <kenvandine_wk> sure
[16:08] <cody-somerville> asac, bug #352451
[16:10] <asac> cody-somerville: why not "dontshowin"?
[16:12] <cody-somerville> Either or meets my purpose. However, I imagine the situation is similar in other desktop environments.
[16:26] <rickspencer3> kenvandine_wk: pidgin seems to working perfectly normally for me now
[16:26]  * rickspencer3 tries to repro pidgin bug
[16:29] <mvo> rickspencer3: any luck in reproducing the restart required icon that apparently appread last friday? or more informaton?
[16:29] <rickspencer3> mvo: nope
[16:29] <rickspencer3> no one could repro, so no bug
[16:30] <mvo> heh :) ok
[16:30] <rickspencer3> Desktop team meeting?
[16:31] <rickspencer3> mvo: I'll let sabdfl know
[16:31] <seb128> rickspencer3: phone call rather and meeting in one hour no?
[16:31] <seb128> rickspencer3: it's 15:30utc
[16:31] <rickspencer3> d'ph!
[16:31] <mvo> rickspencer3: ok, if more info becomes available, I'm happy to debug that further
[16:31] <rickspencer3> what a morning!
[16:31] <mvo> rickspencer3: but my look at the code does not showed anything
[16:32] <seb128> mvo: is update-manager auto opening after using synaptic when there is pending uploads a known bug?
[16:33] <mvo> seb128: no, what is the chain of events there? you open synaptic, apply changes and late u-m auto-opens?
[16:33] <seb128> mvo: open synaptic, install a specific upgrade using it and then when the update is installed I get update-manager auto-open
[16:46]  * mvo tests
[16:48] <mvo> seb128: if that is reproducable for you, could you please open a terminal and run "killall update-notifier; update-notifier --debug-inotify --debug-updates"  and send me the logs?
[16:49] <seb128> mvo: I guess I will not get it today, I had it yesterday on my desktop which was not updated for > 7 days since I was in London for a week
[16:50] <seb128> mvo: I will try to get details next time it happens
[16:50] <seb128> mvo: the > 7 days is just a guess
[16:52] <mvo> seb128: right, but the version running there was recent? or was the desktop not restarted for some time too?
[16:52] <mvo> seb128: I can check what version exactly added the code that also checks the timestamps for the last dpkg operations
[16:53] <mvo> seb128: but it should not auto-open if any dpkg operation ran within the last 7 days (unless there are security updates pending)
[16:53] <james_w> is anyone else seeing tracker-indexer running again?
[16:53] <james_w> I presume it is still disabled by default
[16:56] <seb128> james_w: it's not installed by default in jaunty
[16:56] <james_w> ah
[16:56] <james_w> well I still have it installed
[16:56] <seb128> mvo: sorry I was away for some minutes
[16:56] <james_w> but it never ran until recently as far as I know
[16:56] <seb128> mvo: I did boot my desktop yesterday after a week being away, there was too many updates available to download everything in one go so I did open synaptic and picked some
[16:57] <seb128> mvo: and update-manager started auto-opening after each round of installs (I did "select, install" a bunch of times on series of packages)
[16:57] <seb128> james_w: it's running but should not be indexing
[16:58] <james_w> well, it seems to be indexing as well, suddenly takes a lot of CPU and freezes evolution
[16:58] <seb128> james_w: ie it's in the process list but should not take your disk under ios load
[16:58] <mvo> seb128: what version of update-notifier was running? a older one?
[16:58] <seb128> mvo: I would say a 10 days old one, I upgraded before going to London
[16:59] <seb128> mvo: don't bother to much I will keep an eye on it and ping you if it happens again
[17:00] <seb128> mvo: just curious what timestamp doesn't it watch? ie what should I trick if I want to recreate the > 7 days situations?
[17:01] <mvo> seb128: 10 days should have the right version
[17:01] <mvo> seb128: hrm, I check the code
[17:23] <bryce> morning
[17:24] <seb128> hello bryce
[17:25] <pitti> hey bryce
[17:25] <rickspencer3> Desktop team meeting in 5 minutes (for real this time :) )
[17:27] <rickspencer3> pitti: mvo: thanks for digging into davidm's upgrade breakage
[17:27] <pitti> just read davidm's last response
[17:27] <pitti> weird
[17:28] <rickspencer3> I was hoping that we'd get at least one computer that could be well diagnosed
[17:28] <pitti> I haven't run out of questions yet :)
[17:29] <rickspencer3> oh well
[17:29] <rickspencer3> hopefully it won't turn out to be an uninteresting corner case :)
[17:30] <rickspencer3> let's go
[17:30] <ArneGoetje> hi all
[17:30]  * pedro_ waves
[17:30] <rickspencer3> hi desktopppers!
[17:30] <asac> hi
[17:30] <calc> hi
[17:30] <rickspencer3> hi pedro
[17:30]  * kenvandine_wk was planning to upgrade his intrepid VM to jaunty today... but my partition table got whacked :/
[17:30] <bryce> heya
[17:30] <rickspencer3> interesting greeting from kenvandine_wk there
[17:30] <seb128> hello
[17:30] <kenvandine_wk> :)
[17:31] <kenvandine_wk> i spent my evening reinstalling jaunty on my new laptop... after an apparent ext4 bug
[17:31] <rickspencer3> so I'm sensing that team members are feeling pretty good about the beta, but that also team members have some tasks that they are anxious to take care of
[17:31] <calc> kenvandine_wk: that's why i am staying away from ext4 until 2.6.30+
[17:31] <kenvandine_wk> calc: yeah... i will file the bug anyway :)
[17:32] <kenvandine_wk> it was *nasty*
[17:32] <rickspencer3> pursuant to that, I'd like to see if we can compress the meeting to 30 minutes, and move some of the agenda items to email/wiki
[17:32] <rickspencer3> *ahem*
[17:32] <rickspencer3> https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-03-31
[17:33] <rickspencer3> so may I suggest that we follow up on Desktop Summit, Karmic Sprint Dates, and Meeting time outside of the meeting?
[17:33] <pitti> desktop summit is quick
[17:33] <pitti> whoops, sorry
[17:33] <pitti> ignore me, mixed that up
[17:33] <pitti> +1
[17:33] <rickspencer3> k
[17:33] <rickspencer3> pedro_: Hug/Bug Day?
[17:34] <pedro_> yeap, just passing the word
[17:34] <pedro_> The Thursday 02 April the Ubuntu BugSquad is going to celebrate a hug day based on xorg-server and xserver-xorg-video-intel for helping out bryce with the bugs he's getting there
[17:34] <bryce> \o/
[17:34] <pedro_>  bryce polished the page (thanks!) and there's already people working on it as you can see per https://wiki.ubuntu.com/UbuntuBugDay/20090402 so please feel free to join us if you have some time during that day
[17:34] <pedro_> also, if you want us to organize a hug day to help you with the bugs in the product you're responsible for
[17:34] <pedro_> just contact me so we can start to organize it
[17:35] <rickspencer3> btw ... bryce's triaging guidelines are really specific and actionable
[17:35] <pitti> these pages rock indeed
[17:35] <rickspencer3> pedro_: thanks for organizing this
[17:35] <rickspencer3> anything else we should/could do to make the day a success?
[17:35] <pedro_> rickspencer3: always a pleasure
[17:35] <pedro_> yeah, if you have a blog added to planet ubuntu would be nice to post something there
[17:36] <pedro_> same for identi.ca or twitter, etc
[17:36] <bryce> pedro_: thanks, I've got high hopes we'll make a good dent in the triaging work with this
[17:36] <rickspencer3> ACTION: everyone to blog on hug day
[17:36] <pedro_> bryce: you're welcome, i'm sure it's going to rock ;-)
[17:37] <rickspencer3> next is linux foundations summit
[17:37] <rickspencer3> pitti: ...
[17:37] <pitti> I'll be in San Francisco at the LF summit next week
[17:37] <rickspencer3> ?
[17:37] <pitti> thus, if you need anything urgent from me, please mail me ASAP, so that I can get it done this week
[17:37] <pitti> also, if you want me to talk to anyone there, mail me as well
[17:37] <pitti> [done, just announcement]
[17:37] <rickspencer3> kewl
[17:38] <rickspencer3> anyone else going to be there?
[17:38] <pitti> not from desktop, but from other teaks
[17:38] <pitti> kirkland, rtg at least
[17:38] <pitti> davidm as well, I believe
[17:38] <rickspencer3> oh
[17:38] <rickspencer3> cool
[17:38] <rickspencer3> next is Release Bugs/Release Status
[17:38] <pitti> https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus is pretty current
[17:39] <pitti> kudos everyone, we made great progress
[17:39] <pitti> I don't have anything which needs discussion in the meeting
[17:39] <rickspencer3> okay
[17:39] <pitti> except..
[17:39] <pitti> bryce: for the 8x5 one, do we have a "last resort" fallback?
[17:40] <pitti> bryce: could we transition those folks to vesa, if we don't find a better solution?
[17:40] <bryce> pitti: yeah I've got a "Disable DRI" patch ready in this case
[17:40] <pitti> ah, it's only DRI?
[17:40] <bryce> it's in my ppa.
[17:40] <pitti> I've been running without DRI since this morning as well
[17:40] <pitti> definitively better than vesa
[17:40] <pitti> bryce: and we can disable that option based on chipset family?
[17:40] <pitti> i. e. "<= 855" or so?
[17:41] <bryce> we may also need to disable 2D accel (NoAccel)
[17:41] <ArneGoetje> 855 works fine with UXA
[17:41] <bryce> some report that's necessary to get video
[17:41] <pitti> ok, rest is for #u-devel, I think
[17:41] <bryce> however, with no DRI and NoAccel, the driver is barely better than vesa, so those are sort of the nuclear option...
[17:42] <pitti> I can sleep better now, knowing that we have *some* fallback to not completely hose upgrades for those folks
[17:42] <rickspencer3> right
[17:42] <rickspencer3> I posted the current set of targeted bugs to the wiki
[17:43] <rickspencer3> today, only bryce, pitti, and asac have any that are targetted
[17:43] <rickspencer3> I suppose if anyone sees one that they could help out with, that could be appreciated
[17:43] <rickspencer3> Everyone sent an activity report, so thanks for that
[17:43] <pitti> kenvandine_wk: could you go through the indicator test cases and file bugs for everything that doesn't work yet?
[17:44] <kenvandine_wk> pitti: doing that now
[17:44] <pitti> I'm a bit concerned about i-a, it still has lots of weirdness
[17:44] <pitti> kenvandine_wk: cool, thanks
[17:44] <rickspencer3> pitti: yes
[17:44] <seb128> rickspencer3: I've several desktop bugs milestoned, not blocker for jaunty but "would be nice to fix" sort of bugs
[17:44] <kenvandine_wk> i think it has less weirdness today than yesterday :)
[17:44] <seb128> pitti: I'm a bit concerned about notify-osd being crash land for some users too
[17:44] <asac> a genle reminder to post activities in proper wiki format ;)
[17:44] <pitti> kenvandine_wk: one of them being that I still see two icons (pidgin and m-i)
[17:44] <asac> gentle
[17:45] <seb128> asac: what is wiki format? I don't use wiki enough to know
[17:45] <asac> kenvandine_wk: and seb128
[17:45] <asac> seb128: you just need a space before the *
[17:45] <asac> then you are done ;)
[17:45] <seb128> ok, I can do that
[17:45] <kenvandine_wk> pitti: you mean pidgin icon in the notifcation area?
[17:45] <pitti> speaking about that, did anyone figure out how to break lines in itemizations in a way that moin doesn't consider a line break in the output?
[17:45] <kenvandine_wk> asac: i did that in my email to rickspencer3
[17:45] <pitti> kenvandine_wk: yes
[17:45] <kenvandine_wk> pitti: that doesn't happen in a fresh install
[17:45] <asac> kenvandine_wk: you didnt have spaces before the "*" right?
[17:45] <pitti> so far I avoid line breaks in * (it worked in old moin, but not in ucrrent)
[17:45] <rickspencer3> no worries, I normally go through and clean it up a little :)
[17:46] <rickspencer3> seb128: in terms of milestoned but not targetted bugs
[17:46] <kenvandine_wk> asac: i did before emailing it :)
[17:46] <rickspencer3> we have quite a few of those
[17:46] <asac> kenvandine_wk: ok ... then its probably a rickspencer3 bug :-P
[17:46] <rickspencer3> hey!
[17:46] <rickspencer3> I just copy and pasted strait in
[17:47] <rickspencer3> :)
[17:47] <kenvandine_wk> i think evo "html'd it "
[17:47] <asac> kenvandine_wk: bah. disable html ;)
[17:47] <rickspencer3> kenvandine_wk: please don't use html format in your emails!
[17:47] <rickspencer3> in any case, back to work here ...
[17:47] <asac> ack
[17:47] <rickspencer3> I see 15 bugs that are not targetted, but are milestoned for 9.04 (or 9.04 beta) and are importance = High
[17:48] <asac> you have a link at hand?
[17:48] <rickspencer3> I presume that these are the priority bugs, right?
[17:48] <rickspencer3> asac: sorry, I use a hand-rolled for this
[17:48] <asac> i was told to do that when bugs are opportunities but shouldnt hold back release
[17:49] <rickspencer3> asac: I think that's what it means if they are not targeted for the release, yes
[17:49]  * rickspencer3 pastes bug table into the wiki
[17:49] <asac> great. thanks
[17:49] <pitti> milestones on non-targetted bugs are for personal prioritization, yes
[17:49] <pitti> only jaunty-targetted bugs are on the release team radar
[17:50] <rickspencer3> any other business?
[17:51] <seb128> not really for the meeting
[17:51] <rickspencer3> if not, please keep in mind that Final Freeze is April 9th
[17:51] <asac> ok
[17:51] <seb128> but /etc/gdm/locale.conf could be updated, not sure if we have a reference list of locales somewhere
[17:51] <rickspencer3> as we run up to that, I will be striving to minimize distractions
[17:51] <seb128> we have 2 bugs about locales not being available in gdm right now
[17:51] <rickspencer3> so please ping me if you need help with something, as I will be predisposed to inaction
[17:51] <seb128> ArneGoetje, pitti: could you have a look to that?
[17:51]  * rickspencer3 sorry to stomp on seb128
[17:52] <pitti> seb128: /usr/share/i18n/SUPPORTED
[17:52] <pitti> seb128: looking at the april 9 date I probably won't have time for that any more
[17:52] <seb128> ok
[17:52] <seb128> ArneGoetje: how busy are you?
[17:52] <seb128> I guess I could try adding that to my todolist but I'm not sure I will come to it before freeze either
[17:53] <ArneGoetje> seb128: I ried already to add the crh entry manually and recompile the package, but that didn't help. So, maybe the bug is somewhere else.
[17:53] <pitti> you don't need recompilation for testing, just changing the /etc/ file should work
[17:53] <seb128> weird
[17:53] <seb128> ok, I will try to have a look
[17:54] <rickspencer3> sounds like you guys need to talk, but otherwise, no other business?
[17:54] <rickspencer3> I'll be following up with the three postponed items in email
[17:54] <seb128> right, nothing worth a meeting action or discussion
[17:54] <seb128> ok good
[17:55] <rickspencer3> thanks all!
[17:55] <pitti> thanks all
[17:55] <ArneGoetje> thanks
[17:55]  * pitti disappears for today, cu tomorrow
[17:55] <rickspencer3> post meeting comment: I am really liking Jaunty
[17:55] <seb128> thanks
[17:55] <pedro_> thanks you
[17:55] <seb128> pitti: have fun
[17:55] <rickspencer3> it looks good, works good
[17:55]  * kenvandine_wk tries to crash pidgin
[17:55] <pitti> so am I, it rocks
[17:55] <kenvandine_wk> it rocks!
[17:55] <ArneGoetje> pitti: still need to talk to you... have some minutes?
[17:55] <seb128> yeah jaunty will be a great ubuntu version ;-)
[18:00] <kenvandine_wk> rickspencer3: well i crashed it :)
[18:01] <rickspencer3> kenvandine_wk: ok, at least I'm not crazy
[18:01] <rickspencer3> :)
[18:01] <seb128> playing pidgin crash? ;-)
[18:01] <kenvandine_wk> now that i am attached to it with strace, i can't get it to crash again
[18:01] <rickspencer3> seb128: lol
[18:01] <kenvandine_wk> hehe
[18:01] <asac> did you manage to get a backtrace?
[18:01] <rickspencer3> it's 30 love, pidgin
[18:01] <kenvandine_wk> no... it doesn't create a crash file or anything
[18:02] <seb128> kenvandine_wk: strace is of no use for crashes, use gdb
[18:02] <asac> kenvandine_wk: so its a clean exit ;)
[18:02] <asac> ?
[18:02] <kenvandine_wk> maybe...
[18:02] <rickspencer3> kenvandine_wk: I'm wondering if it's not crashing, but rather some settings are confused
[18:02] <seb128> what are the steps to get it?
[18:02]  * rickspencer3 gets bug #
[18:02] <kenvandine_wk> it clearly happens when you check and uncheck the libnotify plugin
[18:02] <kenvandine_wk> sometimes
[18:02] <kenvandine_wk> uncheck libnotify
[18:02] <kenvandine_wk> and check it again
[18:03] <rickspencer3> http://bugs.launchpad.net/bugs/349009
[18:03] <rickspencer3> lol
[18:03] <rickspencer3> I guess kenvandine_wk was able to repro it again
[18:03] <rickspencer3> seb128: kenvandine_wk is crashing it differently than the repro steps I put in the bug
[18:04] <seb128> different bug for sure
[18:04] <kenvandine> ok, i got a SIGABRT
[18:05] <kenvandine> after toggling libnotify plugin 17 times
[18:05] <asac> that should produce a core i think at least you can attach gdb to it
[18:06] <kenvandine> asac: nope...
[18:06] <kenvandine> weird
[18:06] <asac> kenvandine: werll. but gdb should work ;)
[18:06] <kenvandine> yeah... i am running it now
[18:07] <kenvandine> damn... need the dbg package for it
[18:09] <kenvandine> and of course now when i am running with gdm i can't crash it!
[18:12] <asac> kenvandine: please reset your gconf ... maybe that reproduces it on first start
[18:13] <kenvandine> you mean shut it down?
[18:13] <kenvandine> i did that
[18:13] <kenvandine> seb128: did you reproduce it?
[18:13] <seb128> rickspencer3: I did catch an error in the IRC code using valgrind, copied the log to the bug
[18:13] <kenvandine> it is solid for me now...  i hate bugs like this :)
[18:13] <seb128> rickspencer3: I'm looking upstream now
[18:13] <kenvandine> great
[18:14] <kenvandine> what is the bug # again?
[18:14] <seb128> kenvandine: https://bugs.edge.launchpad.net/ubuntu/+source/pidgin/+bug/349009
[18:15] <seb128> I'm not sure there error is the same though
[18:15] <seb128> and I really dislike pidgin.im and their bug tracker ;-)
[18:16] <kenvandine> for me it isn't a SIGSEGV, it is a SIGABRT
[18:17] <kenvandine> i also can't repro it with the same steps as rick
[18:17] <kenvandine> for me it is just toggling the libnotify plugin
[18:18] <seb128> kenvandine: yours is a different bug for sure
[18:18] <seb128> I don't understand rickspencer3's steps
[18:19] <seb128> but I think that's because I don't find how to autojoin a channel
[18:20] <kenvandine> seb128: it is in the add chat interface
[18:24] <seb128> ok, I stop there
[18:24] <seb128> that code has lot of issues
[18:24] <seb128> running it under valgrind for some minutes lists several errors which lead to crashes
[18:25] <Ng> ooh, is the notification area icon of CD burning progress new?
[18:25] <kenvandine> seb128: pidgin is scary... i know :0
[18:25] <Ng> that's *very* cute :)
[18:25] <kenvandine> Ng: no, that is a brasero thing
[18:25] <Ng> do like :)
[18:26] <seb128> you would think pidgin has a viewvcs thing
[18:26] <chrisccoulson> more clutter in the notification area ;)
[18:26] <seb128> but not way to find it
[18:26] <Ng> chrisccoulson: it's not clutter, it appears when I start burning, and disappears when I close the burning window. it's exactly the kind of thing that area should be used for
[18:26] <Ng> I can keep an eye on the progress without looking for the window :)
[18:26] <Ng> (imho)
[18:28] <asac> seb128: i wondered about the pidgin upstream facilities too a few days ago ;)
[18:28] <asac> seb128: maybe we should send our launchpad marketing droids to them ;)
[18:29] <seb128> I did try to sell them launchpad when they were using sf still
[18:29] <seb128> but they prefered their track and monotone integration
[18:29] <asac> sounds lame
[18:51] <seb128> rickspencer3: upstream says it's not a crash but due to the ubuntu changes
[18:51] <seb128> rickspencer3: you don't have a tray icon do you?
[18:51] <rickspencer3> that has been my assumption
[18:51] <seb128> rickspencer3: if there is no tray icon it just exit
[18:51] <rickspencer3> seb128: right
[18:52] <rickspencer3> I have not tray icon, because I am using indicator-applet
[18:52] <rickspencer3> however, it does create a crash report
[18:53] <seb128> rickspencer3: right, seems it doesn't handle the no icon case correctly
[18:53] <seb128> I'm wondering how many people gave testing to this "no tray icon"
[18:53] <seb128> that makes me feel uncomfortable that we got no feedback about it out of you
[18:53] <rickspencer3> it should be everyone who didn't upgrade
[18:54] <seb128> right, and I expect most of our users are upgrading
[18:54] <rickspencer3> the default Jaunty install has pidgin defaults set to not use their tray icon
[18:54] <seb128> or at least the category who reports bugs
[18:54] <rickspencer3> seb128: true
[18:54] <rickspencer3> however, every oem deal, etc... will be a fresh install
[18:55] <asac> did you guys see the bug report about the tray being too difficult to resurrect if user accidentially removed it?
[18:55] <seb128> rickspencer3: http://developer.pidgin.im/ticket/8774 is your bug
[18:55] <seb128> asac: yes I commented on it
[18:55] <asac> did you invalidate the gnome-panel task?
[18:56] <seb128> no
[18:56] <seb128> but I don't think we are going to change anything
[18:56] <seb128> dxteam plan to redo the panel
[18:56] <seb128> the only change I could see useful until then is "locked should mean not deletable"
[18:56] <asac> bug 351482
[18:56] <asac> yeahz
[18:56] <seb128> which we already have a bug about
[18:56] <asac> thats what i thought
[18:56] <asac> so lets wont fix it saying that dxteam will reinvent stuff anyway
[18:57] <seb128> right
[18:57] <asac> seb128: whats the "panel redo" bug?
[18:57] <seb128> and we have a bug about "don't allow deleting locked items"
[18:57] <seb128> asac: I don't think there is a bug, that's dxteam discussions rather ;-)
[18:57] <asac> seb128: you think you can find the bug numbers and close the bug wontfix giving those?
[18:57] <asac> ah
[18:59] <seb128> dinner time bbl
[18:59] <asac> seb128: enjoy
[19:00] <rickspencer3> kenvandine_wk: did you see that seb128 tracked down my pidgin crash upstream?
[19:00] <kenvandine_wk> no
[19:00] <kenvandine_wk> rickspencer3: buy i think my crash is different
[19:01] <kenvandine_wk> mine is an abort
[19:01] <rickspencer3> kenvandine_wk: yes, exactly
[19:01] <kenvandine_wk> running in gdb now... waiting for a crash :)
[19:01] <rickspencer3> so:
[19:01] <rickspencer3> 1. lots of people will run into mine, as a fresh Jaunty install will lack the panel
[19:02] <asac> rickspencer3: ah resh install lacks which panel?
[19:02] <asac> fresh
[19:02] <kenvandine_wk> oh geez
[19:02] <rickspencer3> 2. you should probably separate the bugs to be tracked seperately, if you haven't already
[19:02] <rickspencer3> asac: I mean panel icon
[19:02] <asac> oh right
[19:02] <asac> let me check that ;)
[19:04] <asac> yeah it exists, but doesnt crash. seems like expected behaviour based on the patches we have
[19:07] <asac> if i have a conversation open it stays alive and i can make pidgin reappear through the messaging indicator
[19:07] <asac> hmm
[19:07] <rickspencer3> asac: that's the desired behavior
[19:08] <asac> yeah but on first start or so it doesnt work
[19:08] <rickspencer3> asac: right
[19:08] <asac> err if i dont hide and unhide it manually before closing first time
[19:08] <rickspencer3> if you close the buddy list before you activate the conversation window, it crashes
[19:08] <rickspencer3> seems the bug is well understood upstream
[19:09] <kenvandine_wk> rickspencer3: that is strange behavior :)
[19:09] <rickspencer3> kenvandine_wk: what is?
[19:09] <asac> i dont see the crash
[19:09] <kenvandine_wk> your bug :)
[19:09] <rickspencer3> that you can access the buddy list via the applet
[19:09] <kenvandine_wk> no... that is cool
[19:09] <rickspencer3> ?
[19:10] <kenvandine_wk> the fact that it crashes if you close it before any messages
[19:10] <rickspencer3> well, software is like that :)
[19:10] <rickspencer3> It would be great if we could fix this, and get the fix upstream before April 9th
[19:11] <kenvandine_wk> does it crash if someone messages you before you close it?
[19:11] <rickspencer3> as it will be less of a corner case with Jaunty
[19:11] <rickspencer3> I'm not sure, it crashes if I close the buddy list before I touch the conversation window
[19:11] <kenvandine_wk> i immediately get pounced on everytime i open it
[19:11] <rickspencer3> I get pounced by irc.canonical.com for instance
[19:12] <rickspencer3> but it still crashes
[19:12] <rickspencer3> looks like ken reproed it again ;)
[19:13] <rickspencer3> kenvandine_wk: how are the test cases going?
[19:16] <kenvandine_wk> i am through most of them
[19:17] <kenvandine_wk> i have a couple that really needs a pristine new user
[19:17] <kenvandine_wk> waiting for pidgin to crash again before i do that :)
[19:24] <kenvandine_wk> crashed and i got a backtrace :)
[19:24] <didrocks> seb128: hey
[19:25] <sabdfl> how do i know how long i've been logged in?
[19:25] <didrocks> seb128: can it wait for Friday? I am at Solution Linux those 3 days and can't have a real network :)
[19:25] <sabdfl> last?
[19:25] <didrocks> hi kenvandine_wk & sabdfl :)
[19:25] <sabdfl> hi didrocks
[19:25] <kenvandine_wk> hey didrocks
[19:25] <cody-somerville> sabdfl, 'w' works
[19:25] <kenvandine_wk> sabdfl: or w
[19:28] <tedg> sabdfl: If you don't know how long anymore, it's time to take a break :)
[19:30] <sabdfl> tedg: alzheimers is fun!
[19:30] <didrocks> he is a very good friend of mine :)
[19:31] <kenvandine_wk> sabdfl: clearly not enough crashers :)
[19:33] <sabdfl> kenvandine_wk: this linux thing is *awesome*
[19:34] <tedg> Someone should like make CDs of it and hand them out to people or something.
[19:34] <kenvandine_wk> :-D
[19:34] <kenvandine_wk> tedg: great idea
[19:41] <asac> tedg: whats the official way to check whether a indicator applet is running?
[19:41] <tedg> asac: Don't really have a way.  What is it that you're trying to do?
[19:43] <asac> tedg: decide whether a using indicator makes sense
[19:43] <tedg> asac: There's no cost to always indicate what you're application is thinking, so I'd say do it always, never stop :)
[19:44] <asac> well.
[19:44] <asac> i need to decide whether to use custom notification or indicator api
[19:44] <tedg> The issue is that it's designed to be listener independent.  So there could be more than one listener, and if you're looking for a particular implementation of a listener, that's not really useful.
[19:44] <asac> i cannot just use both ;)
[19:45] <tedg> Do you mean the notification area, or a notification like notify-osd?
[19:46] <asac> no really custom notifications like in tbird
[19:46] <tedg> Oh, never use those.  They're complete and utter fail.  I get offended for people when I see that pop up on their screen.
[19:47] <asac> sorry, thats not a pragmatic approach ;)
[19:47] <tedg> On a practical note, I'd say always indicate.  And then allow users to turn those on if they really want them.
[19:48] <asac> why cant we have something like NameOwnerChange that you can use in dbus to see whether a server is available
[19:48] <asac> that would really help
[19:48] <asac> e.g. when there is a listener -> use indicate; otherwise fallback and do something different
[19:48] <tedg> That doesn't really answer the question though.  That just says that someone is listening, it doesn't say that there's an indicator applet.
[19:49] <asac> tedg: thats ok imo
[19:49] <tedg> And, there will be a name, but that just didn't make it in 0.1.  0.2 will have a name for the first listener on the bus.
[19:49] <asac> if ther is a server that listens for "message.im" and eats the message its broken
[19:50] <tedg> Well, they're not messages.  They're state.  The application holds them up like flags.
[19:51] <tedg> Notifications (notify-osd style) are messages, these are different.
[19:51] <asac> ok then that. shouldnt be much different. if there is a listener that feels reponsible for message.im getting that info similar to NameOwnerChange would be great
[19:51] <tedg> BTW, it shouldn't be message.im for Thunderbird, it should be message.mail :)
[19:52] <asac> details :-P
[19:53] <tedg> Okay, I'll put a wishlist bug in and milestone it for 0.2 to make a way for applications to determine if there is a listener on the bus.
[19:53] <asac> tedg: its not really about tbird, its about getting infrastrcuture into xulrunner for indicators
[19:53] <asac> ok good
[19:55] <dobey> do none of you guys have ssh-agent randomly disappear when you're trying to work?
[19:55] <asac> works here reliably
[19:56] <tedg> asac: bug 352616
[19:56] <tedg> asac: Comment if you have any ideas/features you need.
[19:57] <davidbarth> join #ubuntu-mobile
[19:58] <tedg> davidbarth: Hello and welcome to ubuntu-mobile :)
[19:58] <asac> tedg: yep. thanks
[20:11] <davidbarth> tedg: <grin>
[20:51] <bryce> pitti, rickspencer3: after reading through all of the comments on bug 304871 and putting all the commenters into a big table, I see what's going on
[20:51] <bryce> pitti, rickspencer3: Ironically the original issue on 845 seems to have long since been solved, the last few reporters with 845 cards say the issue went away after a kernel update
[20:52] <bryce> pitti, rickspencer3: But what happened was 865 users with a somewhat similar bug started commenting heavily, and redirected the bug report towards their issue (which made it very confusing)
[20:53] <rickspencer3> interesting
[20:53] <bryce> so I'm splitting out the 865 stuff into two separate bugs, 317457 and 328528
[20:53] <rickspencer3> bryce, is there a fix for 865 usrs?
[20:53] <rickspencer3> (great work, btw)
[20:54] <bryce> there are also some 855 users reporting a similar issue but their workaround, symptoms, and fix are quite different, so I'll handle that with 322646
[20:54] <bryce> rickspencer3: yeah the patch I proposed earlier to disable DRI works around the issue on 865
[20:54] <rickspencer3> ok
[20:54] <rickspencer3> so 855 gets one set of tweaks, 865 another
[20:55] <bryce> I was getting really confused though because 845, 855, and 865 each need different kinds of fixes
[20:55] <rickspencer3> 845, there a vanilla install works fine
[20:55] <bryce> so I need to redo the patch to only apply to 865
[20:56] <bryce> rickspencer3: anyway the upside is that finally this targeted bug 304871 can be closed as fixed
[20:56] <rickspencer3> sweet
[20:56] <bryce> the downside is that I have 3 more bugs to work on ;-)
[20:57] <jcastro> bryce: except each bug will end up spawning 3 more bugs until it's the apocalypse
[20:57] <rickspencer3> lol
[20:57] <bryce> jcastro: likely so
[21:01] <kenvandine_wk> rickspencer3: https://wiki.ubuntu.com/DesktopTeam/Meeting/JauntyIndicatorAppletTestCases/KenVanDine/20090331
[21:02] <rickspencer3> kenvandine_wk: sweet
[21:04] <kenvandine_wk> rickspencer3: reload that page, i updated a comment in there on test case 7
[21:05] <kenvandine_wk> i think i can fix that one myself very easily
[21:07] <kenvandine_wk> humm... maybe not that easily... it loops through all the windows from evo_shell
[21:07] <kenvandine_wk> so i guess that dialog isn't a window :)
[21:09] <rickspencer3> kenvandine_wk: +1 on completeness and attention to detail ...
[21:09] <rickspencer3> but sounds like a fairly low priority to me
[21:09] <rickspencer3> perhaps just log the bug and move on to importance=High issues
[21:09] <seb128> re
[21:09] <seb128> rickspencer3: what bug?
[21:09] <kenvandine_wk> ok, but i think this is one that people might hit often...
[21:10]  * kenvandine_wk frequently hits send and receive while passing through evo :)
[21:10] <kenvandine_wk> seb128:  https://wiki.ubuntu.com/DesktopTeam/Meeting/JauntyIndicatorAppletTestCases/KenVanDine/20090331
[21:10] <kenvandine_wk> test case 7
[21:11] <seb128> not really clear what you mean there
[21:11] <kenvandine_wk> if you have evo focused, and a new mail comes in you don't get notified
[21:11] <kenvandine_wk> but
[21:11] <kenvandine_wk> if you hit send and receive, you do
[21:11] <kenvandine_wk> when evo is in focus you shouldn't get notifications for mail
[21:15] <kenvandine_wk> rickspencer3: so overall far better than last round of testing :)
[21:15] <rickspencer3> kenvandine_wk: great
[21:16]  * kenvandine_wk moves on
[21:17] <rickspencer3> kenvandine_wk: come back :)
[21:17] <seb128> kenvandine_wk: right
[21:17] <kenvandine_wk> hehe
[21:17] <rickspencer3> I think we need need a new test case to describe what the buddy list should do
[21:18] <rickspencer3> seb128: correct me if I'm wrong ...
[21:18] <kenvandine_wk> oh... i have a grievance with that...
[21:18] <rickspencer3> i think the user should go Aplications->Internert->Pidgin
[21:18] <rickspencer3> buddy list opens
[21:18] <rickspencer3> user closes buddy list
[21:18] <rickspencer3> user looks in indicator applet and see pidgin is running
[21:19] <rickspencer3> user closes indicator applet
[21:19] <kenvandine_wk> closes the applet?
[21:19] <rickspencer3> user gets an im, conversation window opens
[21:19] <rickspencer3> dismisses the menu, not closes the applet
[21:19] <kenvandine_wk> ok
[21:19] <rickspencer3> just does nothing with the applet
[21:19] <rickspencer3> the point being that pidgin only quits if the user chooses "quit" from the buddy list
[21:19] <rickspencer3> file menu. Otherwise, keeps running
[21:20] <kenvandine_wk> rickspencer3: yes... that is how it works now
[21:20] <rickspencer3> good
[21:20] <kenvandine_wk> but
[21:20] <rickspencer3> could I ask you to create a test case for that and confirm that it continues to work that way?
[21:20] <seb128> kenvandine_wk: what rick gets has been described as a crash on exit by upstream ... are you sure it doesn't try to exit?
[21:20] <kenvandine_wk> this is very annoying... now that i have lived for 2 hours without the icon in the systray
[21:20] <kenvandine_wk> seb128: i can repro his crash too
[21:20] <seb128> when not having the icon?
[21:20] <kenvandine_wk> but when it doesn't crash, it does that :)
[21:20] <kenvandine_wk> yes
[21:21] <kenvandine_wk> so when you click on pidgin in the indicator applet, and the buddy list isn't minimized
[21:21] <kenvandine_wk> it doesn't focus it
[21:21] <kenvandine_wk> you have to click it a second time
[21:22] <rickspencer3> kenvandine_wk: after you get the test case written up, could you ping me?
[21:22] <kenvandine_wk> if it is minimized it does the right thing the first click
[21:22] <kenvandine_wk> but if not it minimizes it on the first click
[21:22] <kenvandine_wk> yeah
[21:22] <kenvandine_wk> i need to file a bug for that
[21:22] <rickspencer3> we should be very crisp about how it should work, and have a very actionable set of bugs for the delta between actual and desired behavior
[21:23] <rickspencer3> now is the time to nail this down
[21:23] <rickspencer3> pidgin is an essentially element of the Ubuntu desktop, we must ensure that it behaves predictably for users
[21:26] <seb128> kenvandine_wk: hum I can't confirm what you said
[21:26] <seb128> I run pidgin on a command line
[21:26] <seb128> turn off the notification icon
[21:26] <seb128> click on the X in the right corner
[21:26] <seb128> pidgin exit
[21:28] <rickspencer3> *sigh*
[21:28] <rickspencer3> that's very maddening
[21:28] <rickspencer3> I just closed the buddy window, and it closed my active conversations
[21:28] <seb128> what I said
[21:29] <seb128> closing the buddylist exit when you have no notify icon
[21:29] <rickspencer3> exactly
[21:29] <rickspencer3> but it doesn't alway happen
[21:29] <rickspencer3> but it didn't seem like a crash
[21:29] <seb128> well I was writting that before you left
 kenvandine_wk: hum I can't confirm what you said
[21:29] <seb128>  I run pidgin on a command line
[21:29] <seb128>  turn off the notification icon
[21:29] <seb128>  click on the X in the right corner
[21:29] <seb128>  pidgin exit
[21:29] <seb128> every time here
[21:29] <rickspencer3> seb128: what I'm not clear on is:
[21:30] <rickspencer3> is this a bug? or the result of the settings?
[21:30] <rickspencer3> it seems like I would have noticed this long ago
[21:30] <seb128> well, when you have no remaining component on screen it exit
[21:30] <seb128> the conversations count and the notify icon count
[21:30] <seb128> you probably don't notice because you have IRC running all day
[21:30] <seb128> if you would do jabber only you would quickly notice
[21:31] <seb128> talking to nobody and closing the buddylist
[21:31] <seb128> -> exit
[21:31] <rickspencer3> so it's a bug, as I have the conversation window open, and it closes the conversation window
[21:31] <seb128> right it probably doesn't detect it as active for some reason
[21:31] <rickspencer3> (when I close the buddy list)
[21:31]  * rickspencer3 tries a few things
[21:31] <seb128> but you pinpointed what I expect will be a huge flamefest from IM users who don't do IRC
[21:32] <seb128> in fact no
[21:32] <seb128> it just exit there
[21:32] <rickspencer3> it's a crash
[21:32] <seb128> open conversations or not
[21:32] <rickspencer3> when I run from the command line, it says:
[21:32] <rickspencer3> Segmentation fault (core dumped)
[21:32] <seb128> right
[21:33] <kenvandine_wk> it is working in my VM
[21:33] <seb128> that's probably still the same crash on exit you are having for a while
[21:33] <kenvandine_wk> which only has one gtalk account enabled
[21:33] <seb128> weird
[21:33] <rickspencer3> d;uh
[21:33] <kenvandine_wk> i think that crash is irc specific, right?
[21:33] <seb128> not clear but the upstream bug suggests you need several accounts
[21:34] <seb128> well, I'm using pidgin for jabber
[21:34] <seb128> I run it on a command line
[21:34] <seb128> double click on a contact
[21:34] <seb128> say hello
[21:34] <seb128> click on the X in the buddylist
[21:34] <seb128> pidgin exit
[21:34] <seb128> every time
[21:34] <seb128> and that's not a crash
[21:34] <seb128> I think it's designed to exit if there is notification icon
[21:34] <seb128> which makes sense because how would you unhidde otherwise
[21:35] <dobey> if there's no notification icon, yeah it just exits
[21:35] <rickspencer3> 8arg*
[21:35] <seb128> I expect that to be a massive issue for our userbase if we don't do something
[21:35] <rickspencer3> seb128: ack
[21:35] <rickspencer3> kenvandine_wk: obviously this needs to be addressed asap
[21:35] <rickspencer3> thoughts?
[21:35] <seb128> and I'm a bit concerned than we didn't detect the issue until now
[21:35] <Amaranth> you didn't?
[21:36] <seb128> the whole message indicator part of the dxteam work didn't get lot of testing apparently
[21:36] <Amaranth> maybe I should have filed that bug report...
[21:36] <seb128> Amaranth: no, nobody opened a bug or mentioned it on any list I'm reading
[21:36] <Amaranth> they were talking about it on the forums, I think
[21:36] <seb128> and I still have the notification icon since it's not removed on upgrade
[21:36] <kenvandine_wk> humm
[21:36] <Amaranth> and people mention it in #ubuntu+1 sometimes
[21:36] <seb128> I don't read forums
[21:36] <kenvandine_wk> it isn't exiting here
[21:36] <seb128> and i'm not on #ubuntu+1
[21:37] <seb128> kenvandine_wk: are you sure you desactivated the notification icon in pidgin's option?
[21:37] <seb128> kenvandine_wk: you didn't delete the notification area right?
[21:37] <chrisccoulson> it's exiting here for me like seb128 says, but i'm certain that I've seen it not exit sometimes too
[21:37] <tedg> I just did it, and I'm still here :)
[21:37] <rickspencer3> hehe
[21:37] <rickspencer3> well, no such luck for chris
[21:38] <seb128> tedg: IRC could keep it running
[21:38] <seb128> it seems people who use pidgin for IRC manage to get it still running
[21:38] <rickspencer3> seb128: I *only* have irc
[21:38] <kenvandine_wk> seb128: this is a pristine jaunty install
[21:38] <seb128> so maybe IRC is a special case
[21:38] <seb128> kenvandine_wk: jaunty is not available yet
[21:38] <chrisccoulson> seb128 - i'm using IRC and it still exits ;)
[21:38] <seb128> kenvandine_wk: what alpha, beta, daily?
[21:38] <kenvandine_wk> hehe
[21:38] <kenvandine_wk> beta
[21:39] <seb128> exit and crash when using IRC
[21:39] <rickspencer3> there are two seperable issues:
[21:39] <chrisccoulson> i don't see a crash either :/
[21:39] <rickspencer3> #1: pidgin quits when it shouldn't
[21:39] <rickspencer3> #2 pidgin crashes when it quits
[21:39] <seb128> right
[21:40] <seb128> I'm not concerned about #2
[21:40] <kenvandine_wk> ok... interesting
[21:40] <seb128> that's a well understood issue
[21:40] <rickspencer3> bratsche is working on #2, but #1 is the much more serious problem
[21:40] <seb128> indeed
[21:40] <rickspencer3> so ...
[21:40] <kenvandine_wk> if i start pidgin and immediately close it with the X
[21:40] <kenvandine_wk> it does exit
[21:40] <kenvandine_wk> but
[21:40] <kenvandine_wk> if i click on it in the indicator first
[21:40] <kenvandine_wk> it doesn't
[21:40] <tedg> So, the way that it works now is that Pidgin will close if you don't use the indicator applet to close it.  But, if you do start using the indicator applet, it assumes that's what you want to do.
[21:40] <tedg> yeah, what kenvandine_wk said.
[21:41] <chrisccoulson> that's really confusing behaviour
[21:41] <rickspencer3> tedg: so this bahvior is by design?
[21:41] <kenvandine_wk> it is :)
[21:41] <rickspencer3> because it's kicking our asses as users
[21:41] <tedg> It was a compromise for the non-Ubuntu case where they wanted X to close.
[21:41] <seb128> nobody will figure that
[21:41] <chrisccoulson> when i click the X, i expect it to do the same thing every time ;)
[21:41] <seb128> I never used the indicator to hide my buddy list
[21:41] <kenvandine_wk> rickspencer3: it isn't that terrible if you use the indicator a ton... but we need it to be better
[21:41] <rickspencer3> it explains the whole "sometimes" factor
[21:41] <seb128> it's far away from the list and I don't see the point
[21:41] <rickspencer3> kenvandine_wk: it's terrible
[21:42] <rickspencer3> none of us could figure out what the heck was going on
[21:42] <tedg> So, the idea was to make it so that if you didn't use it, it wouldn't keep the window open.
[21:42] <rickspencer3> after heavy, repeated use, heavily skilled desktop users were hopelessly confused
[21:42] <rickspencer3> tedg: are we talking about the same thing?
[21:42] <kenvandine_wk> it would really suck for jaunty... since people aren't used to using the indicator yet
[21:42] <dobey> i just never hide my buddy list
[21:43] <dobey> if i want to hide it, i switch desktops
[21:43] <kenvandine_wk> so hurts the learning process a great deal
[21:43] <rickspencer3> what we are saying is that if we close the buddy window and there is a conversation open, we expect the conversation window to stay open
[21:43] <dobey> i use the tray icon to queue messages when i'm away, and to mute the sounds if i'm on the phone or something
[21:43] <rickspencer3> even if there isn't a conversation window open, we expect pidgin to keep running (as it always has)
[21:44] <kenvandine_wk> rickspencer3: yes... that is what it needs to do... but only if the indicator applet is available
[21:44] <seb128> users expect simply an IM to always run
[21:44] <seb128> they change to status to offline or busy sometime
[21:44] <kenvandine_wk> yeah
[21:44] <tedg> Let me step back, what happens is that Pidgin has the ability to have people inhibit the exit when the buddy list is closed.  So if we set ourselves up as an inhibitor, then when you hit the X the buddy list will close, but not the app.
[21:44] <seb128> but it should be running
[21:44] <tedg> The question is should the plugin inhibit close or not.
[21:44] <kenvandine_wk> i think it should
[21:44] <seb128> pidgin should never close when clicking on the X
[21:45] <rickspencer3> I think you could infer from experience as users here, that it absolutely should
[21:45] <tedg> Okay, so if there is no messaging indicator, how do you get the buddy list back?
[21:45] <seb128> whatever is the configuration you are using and your workflow
[21:45] <dobey> how do you open the buddy list if there are no current "indicators" for pidgin then?
[21:45] <dobey> heh
[21:45] <seb128> well obviously it should close if there is no notify icon or indicator
[21:45] <rickspencer3> we just spent like 45 minutes with multiple engineers trying to track down the "bug" that was making the windows close
[21:45] <kenvandine_wk> tedg: it should be conditional
[21:45] <rickspencer3> right
[21:45] <kenvandine_wk> if the indicator isn't running... don't inhibit
[21:45] <rickspencer3> there are three cases
[21:46] <rickspencer3> well four cases
[21:46] <tedg> So, we dont' really know if the indicator is running.
[21:46] <rickspencer3> #1 indicator-applet, no pidgin icon
[21:46] <rickspencer3> #2 pidgin icon, no indicator applet
[21:46] <rickspencer3> #3 indicator-applet, pidgin icon
[21:46] <rickspencer3> #4 no icons
[21:46] <seb128> tedg: it seems to me that this while indicator thing is not ready to be used
[21:46] <rickspencer3> in cases 1-3 pidgin should keep running
[21:47] <rickspencer3> mat_t: hi
[21:48] <rickspencer3> mat_t: ted: all I'm saying is, if you look at the users in this room, trying to use pidgin to get work done, if you look at us as a usability test session
[21:48] <tedg> rickspencer3: I don't disagree, the problem is that there's no good way to detect whether the indicator applet is running, or if it's concerned with Pidgin.  We could check to see if there's a listener on the bus, but that doesn't mean it's interested in us.
[21:48] <rickspencer3> it's obvious that the indicator should inhibit pidgin closing
[21:48] <tedg> rickspencer3: I'm not disagreeing.
[21:50] <rickspencer3> so the current behavior is an artifact of implementation constraints?
[21:50] <tedg> Yes, I'd say that's fair.
[21:50] <rickspencer3> I don't understand the constraint
[21:51] <rickspencer3> does the pidgin plugin not register with the indicator-applet?
[21:51] <seb128> there is no public interface between those applications you can query, ie pidgin has nowhere to ask what to do
[21:51] <tedg> pidgin-libnotify effectively has no way to determine whether indicator-applet is running.  There is no registration.  But, it has to choose whether to inhibit the exit.
[21:51] <bratsche> rickspencer3: You need to be using irc with pidgin to reproduce this crasher?
[21:51] <tedg> seb128: No, indicator-applet does all the asking.  It doesn't have it's own API.
[21:52] <rickspencer3> bratsche: not sure, but can we table the crash discussion for a few minutes?
[21:52] <bratsche> Sure.
[21:52] <seb128> bratsche: yes, try having a jabber and a IRC account, disable the notification area icon in the pidgin preference dialog and close it using the x in the corner
[21:52] <bratsche> Okay cool, thanks.
[21:52] <rickspencer3> can we patch pidgin to detect the indicator-applet?
[21:52] <rickspencer3> in the same way it detects the panel icon?
[21:53] <tedg> rickspencer3: We could detect whether the process is running... but that doesn't mean a whole lot.  It doesn't detect the panel icon, the panel icon is in process for Pidgin.  It's XEmbed.
[21:53] <seb128> well, let's be pragmatic
[21:53] <tedg> It would work in the basic case, but if something like the indicator-applet got hung, we'd still hide the buddy list.
[21:54] <seb128> if we have to screw a case screw the user who have neither the indicator nor the notify icon
[21:54] <seb128> and let's never close it
[21:54] <rickspencer3> I would take that trade-off over what we have today
[21:54] <rickspencer3> seb128: good idea
[21:54] <seb128> I doubt many user will have neither the indicator or icon and what to close it anyway
[21:54] <seb128> what -> want
[21:55] <tedg> That's fine with me.
[21:55] <rickspencer3> in any case, it must work very well in the default desktop that we ship
[21:55] <tedg> The problem is that Pidgin, by default, defaults to having no icon on Kubuntu.
[21:55] <tedg> So effectively, on non Ubuntu desktops, we've got the case where there is no indicator and no icon.
[21:56] <seb128> ok, I'm not going to make friends in the dxteam but I'm near of suggesting that we add the notification area icon back by default in jaunty if we can't figure something better
[21:57] <kenvandine_wk> i would say a user wanting the X to close their im session is a corner case
[21:57] <rickspencer3> I think we are all agreed on the desired behavior, yes?
[21:57] <kenvandine_wk> we always inhibit?
[21:57] <rickspencer3> The question is how to respond to the implementation constraints
[21:58] <tedg> Can other flavors ship different Pidgin defaults XML file?
[21:58] <rickspencer3> dunno
[21:58] <seb128> no
[21:58] <seb128> other flavor are ubuntu
[21:59] <rickspencer3> Kubuntu, xubuntu, studio, etc...
[21:59] <seb128> you can install xfce and GNOME on a same box and let user log into whatever desktop they want
[21:59] <seb128> and we have no mechanism right now to divert pidgin configs this way
[21:59] <rickspencer3> what are the consequences of making the close button just "hide" the buddy window, and never exit?
[21:59] <rickspencer3> (or hiding the "x" button)
[22:00] <tedg> You can't get the buddy list back.
[22:00] <seb128> it would screw other desktop environment which have no indicator
[22:00] <rickspencer3> scratch that last one
[22:00] <seb128> since we disable the icon by default
[22:00] <rickspencer3> tedg: could you not go Applciations->Internet->Pidgin?
[22:00] <rickspencer3> to get it back
[22:00] <chrisccoulson> that doesn't work
[22:00] <chrisccoulson> pidgin just exits immediately
[22:00] <seb128> no, it would start a new one which would detect a running instance and exit
[22:00] <rickspencer3> hmmm
[22:01] <rickspencer3> could it not detect the running instance, and then force that instance to show the buddy window?
[22:01] <tedg> We could probably shell script that...  it could find the pidgin instance running and send it the dbus command to open the buddy list.
[22:02] <rickspencer3> or could we figure out some other way for pidgin to detect if it should be inhibited from exiting?
[22:02] <rickspencer3> for instance, it could check for a file on disk?
[22:03] <rickspencer3> (or does this fall foul to the "what if indicator-applet hangs" problem?)
[22:03] <seb128> we don't care about the indicator hanging
[22:03] <seb128> what if the notification area is screwed since warty
[22:04] <seb128> just make there that doesn't happen ;-)
[22:04] <rickspencer3> so pidgin checks if the indicator-applet process is running, and if so, the buddy list hides without exiting?
[22:05] <rickspencer3> and if indicator-applet is hung, so be it
[22:05] <rickspencer3> ?
[22:05] <tedg> This should always show the buddy list: dbus-send --session --dest="im.pidgin.purple.PurpleService" /im/pidgin/purple/PurpleObject im.pidgin.purple.PurpleInterface.PurpleBlistShow
[22:05] <seb128> I think that would work
[22:07] <kenvandine_wk> if it doesn't... there are bigger problems :)
[22:07] <tedg> If that was just in the desktop file in general, it seems like you'd either get an error from dbus-send or show the buddy list no matter what.  Something like "pidgin ; <above>"
[22:07] <kenvandine_wk> tedg: humm... that isn't working for me
[22:08] <tedg> kenvandine_wk: Hmm, for some reason you need a "--print-reply"
[22:09] <tedg> Heh, it seems to bring it forward, but not-unhide it.
[22:09] <tedg> That's odd.
[22:09] <seb128> $ dbus-send --print-reply --session --dest="im.pidgin.purple.PurpleService" /im/pidgin/purple/PurpleObject im.pidgin.purple.PurpleInterface.PurpleBlistShow
[22:09] <seb128> method return sender=:1.204 -> dest=:1.226 reply_serial=2
[22:09] <seb128> but that doesn't show the list
[22:09] <kenvandine_wk> yeah
[22:09] <kenvandine_wk> only focuses it
[22:10] <rickspencer3> (01:44:22 PM) tedg: Let me step back, what happens is that Pidgin has the ability to have people inhibit the exit when the buddy list is closed.  So if we set ourselves up as an inhibitor, then when you hit the X the buddy list will close, but not the app.
[22:10] <rickspencer3> (01:44:38 PM) tedg: The question is should the plugin inhibit close or not.
[22:10] <rickspencer3> tedg: I'm still on clear on how "set ourselves up as an inhibitor"
[22:10] <rickspencer3> do we patch pidgin with code that checks what we want?
[22:10] <kenvandine_wk> rickspencer3: that is the libnotify plugin
[22:10] <tedg> rickspencer3: The pidgin-libnotify plugin calls a function in the API to say "I inhibit things"
[22:10] <kenvandine_wk> not pidgin
[22:11] <rickspencer3> calls a function on the pidgin API
[22:11] <rickspencer3> so the plugin detects (in some way) the presence of the indicator-applet?
[22:11] <tedg> rickspencer3: Effectively yes.
[22:12] <tedg> No the plugin can not detect the applet.
[22:12] <rickspencer3> it doesn't seem complex to me ... if we accept that the process may be hung
[22:12] <rickspencer3> can it not detect a process by a canonical name, etc...
[22:12] <tedg> It could do that, look for the binary name.
[22:12] <rickspencer3> can the applet write a file with it's pid in a defined place, for the plugin to read?
[22:14] <tedg> I think that works for our standard cases, the thing I'm concerned about is things like AWN.  AWN could very easily use the indicator API to work with Pidgin and do the same behaviors.  I'm not sure how we all work together and be friends.
[22:15] <rickspencer3> not sure how that interacts
[22:15] <rickspencer3> I don't see the issue there
[22:16] <tedg> I think that, for 0.2, we need to add having listeners who are interested tell the servers.  I think that can all be in the library, so no app changes.
[22:16] <kenvandine_wk> good
[22:16] <tedg> This buddy list management was added so late, it really isn't in the design.
[22:17] <rickspencer3> okay
[22:17] <rickspencer3> so, what should we do next?
[22:17] <tedg> Cry :)
[22:17] <rickspencer3> tedg: can you add the inhibiting behavior
[22:17] <rickspencer3> lol
[22:18] <tedg> Yes, I'm trying to think whether it's worth spec'ing out and putting in the library now.
[22:18] <rickspencer3> kenvandine_wk: I think we need a very clear bug that describes the desired behvior
[22:19] <rickspencer3> like, zero ambiguity :)
[22:19] <kenvandine_wk> yeah :)
[22:19] <kenvandine_wk> so a bug that describes the behavior we want in all cases :)
[22:19] <kenvandine_wk> that should be *easy*
[22:19] <tedg> I think I'd need one signal, which would change the class size... but, we could rebuild pidgin-libnotify, evolution-indicator and the python bindings.
[22:20] <tedg> That's not too bad.
[22:20] <rickspencer3> kenvandine_wk: not all cases, just the case when the user has the indicator applet open, and clicks "x" on the buddy list
[22:20] <kenvandine_wk> ok
[22:20] <rickspencer3> oops, not open, I mean on their panel
[22:20] <kenvandine_wk> i will do that
[22:21] <kenvandine_wk> yeah
[22:21] <rickspencer3> the bug is that it currently sometimes exits (depending on whether it's been touched through the indicator-applet or not)
[22:21] <rickspencer3> thanks tedg
[22:21] <kenvandine_wk> yeah, i can describe the current behavior as well as the desired behavior
[22:21] <seb128> tedg: rebuilding the few clients of the lib is no issue
[22:21]  * kenvandine_wk needs to go take baby duty for a little bit... will file it after dinner :)
[22:22] <kenvandine_wk> later folks
[22:22]  * kenvandine_wk is glad we caught this now
[22:22] <seb128> kenvandine_wk: see you later
[22:22] <tedg> Okay, so that'll have to be a tomorrow project.  I won't get it done today.
[22:22] <rickspencer3> tedg: I'm disappointed, I would have thought you would have been coding while we discussed
[22:22] <rickspencer3> :)
[22:23] <tedg> seb128: I'll ping you to figure out how to do the rebuilds when I get there.  I'm not sure how that works, just reupload everything at once?
[22:23] <tedg> rickspencer3: I was coding, different bugs ;)
[22:25] <seb128> tedg: do you plan to break ABI? in which case change the soname
[22:25] <seb128> tedg: the old soname will still be there until we rebuild everything against the new one
[22:26] <tedg> seb128: Yes, we'll have to.  The size of the class will change with the signal addition.  I realized that a while ago, but I didn't want to break things by adding "reserved" entires :)  I'll add them now :)
[22:26] <rickspencer3> tedg: I suggest you now run away as fast as you can, before we make more work for you!
[22:26] <seb128> ok, I guess you know what to do
[22:27] <seb128> let me know tomorrow if you need sponsoring for the changes and rebuilds I can do that
[22:28] <seb128> and I will call it a day now, that was enough discussions for this evening ;-)
[22:28] <rickspencer3> night seb128
[22:28] <seb128> 'night rickspencer3
[22:28] <seb128> see you tomorrow
[23:13] <RobLoach> Installing Ubuntu 9.04 Netbook Remix.