Bug 205844

This sort of issue is best handled by contacting the upstream developers to see
if this is a known issue.  It's very difficult to imagine that a packaging
specific issue could cause this sort of problem with a python based program such
as istanbul, especially when there aren't any patches being applied to the
package in question.

I would have thought the about dialog would be created and controlled via a
rather standardish pygtk or python-gnome binding that all python programs would
be using, so I would be interested to know if other python based programs on
your system with about dialogs experience the same problem.  Which may point to
a problem with a lower level dependancy.  

I will do my best to find the time to confirm this problem on my available
systems, but I don't have a fedora-devel box up and running currently, so I will
have to attempt to confirm this on an fc5 box with added -devel components which
may complicate a comparison to you.  In the meantime feel free to post to the
fedora-extras-list  or fedora-test-list asking for other people to confirm the
problem and to help figure out exactly where the problem is in the codebase. If
this is an istanbul specific problem, I cheerfully accept patches.  

-jef

The best way to handle bugs in my experience is filing them with the packager in
case of distribution specific issues. The packager can close the bug as upstream
problem is needed. Requiring bug filers to carry accounts every single upstream
project is insane, that is one of the things downstream package maintainers can
be helpful with. File a bug upstream with a link to this report if it is indeed
an upstream issue or pie in the sky fix bugzilla to do it all for us (kinda like
Ubuntus Malone does).

I also took your advice and tested with another pygtk program
(system-config-users which I believe is python based) and that about dialog
closes, this sounds like an istanbul issue.

Okay.. how about you hold your breathe instead?  

here's the deal... I have specifically asked other people in the Extras
community to take over maintainership of this package. If you don't think the
way I'm handling bugreports is appropriate... take maintainership of this
package.  Anymore rants about the insanity of asking filers to help do due
diligence to confirm if this is a known issue and I put this package up as an
orphan and I walk away from it.  No one has made a peep for months about taking
over maintainership of this. So you will either play ball my way, or you will
not have a ball to play with.  I will say that your little diatribe has inspired
me to lower this particular issue on my personal priority list. Congrats, you
are an expert in destructive social engineering.

And I just want to point out that I did not in fact ask you to file anything
upstream.. I asked you to contact the developers to see if this is a known
issue. I also asked you to contact other people in the community to confirm
this. At no point did i demand you file a bug upstream. How you interpret my
request for you contact upstream is your business.  

Take your rants about the limitations of this bug tracking system to link
upstream and downstream bugs up with the people who control the available
project infrastructure, because I have zero ability to influence that.  I won't
go as far as to suggest you file a bug about extending this bugzilla's ability..
because clearly that would be too much of a burden for you... and I'd hate to
put you over the edge.

good day

http://bugzilla.gnome.org/show_bug.cgi?id=349226

Summary:
Mixed reports about reproducibility of the experienced behavior, and the main
developer can not confirm the problem which is definitely going to hamper
finding a fix.  Multiple people experiencing this will need to get together and
dig into this to pinpoint the problem.  I dare not suggest that the reporter on
this report contact the reporter of the upstream report, hopefully other
afflicted users will commune to divine a causal relationship with a coding defect. 

This was not meant as an attack on you in any way, however I was trying to point
out that asking people to take bugs upstream should be done with great care and
that the standard approach for most bugfilers is to go to their distribution
first for many reasons. All bugreporters do is find a problem and inform who is
in charge of the package. Then work with that person to resolve it by providing
information.

I am sorry to hear you downgraded the issue because of me, however this is just
an about dialog I doubt it was that high on anyone list not even mine, never the
less it is a bug.

As for maintainership, I would love to take the package but as I'm not very good
with python I fear it would be doing the users a disfavor. I will ask around to
see if anyone wants to take it off your shoulders.

Now since I checked with another pygtk program I do believe the chances of this
being an istanbul issue are somewhat higher than expected, even though like you
I was under the impression that kind of thing was all standardise code which was
reused over and over. I'll see if I can't find someone on FC6 to confirm it.

If I understand you correctly then this is likely to be a combinatory issue with
underlying libraries on FC6 and I will track down someone to test it on a
different FC6 system.

"If I understand you correctly then this is likely to be a combinatory issue with
underlying libraries on FC6 and I will track down someone to test it on a
different FC6 system."

My gut tells me its an interaction problem with a version specific dependancy,
most likely the pygtk bindings. Hopefully as more comments roll in in the
upstream report the specific set of conditions which trigger this will become
clearer. Luckily, we can all read the comments or search for additional
bugreports about this without having to register an account in upstream's
bugzilla.  I would suggest looking for python backtraces by running istanbul in
a terminal as suggested by the developer in the upstream bugreport.

  

Thank you for pointng out the upstream report, I jumped on that one as well,
since this is apparently an upstream to ease your load I'm closing as UPSTREAM.

I have attempted to reproduce this with my local build of 0.2.1 running on a
slightly modified fc5 to include the necessary gstreamer versioning. This is the
 package that I did my initial istanbul 0.2.1 package testing with.  I can not
reproduce the about box behavior bug. Unfortunately the actual fc6 build won't
install on fc5 without some significant surgery on an fc5 install due to the 
rtld(GNU_HASH) dependancy.

And taking a look at the python code... istanbul is using a standard pygtk
widget to construct the about dialog, the gtk.AboutDialog() function. I am using
pygtk2-2.8.6-0.fc5.1 

For reference the tray_popup.py file has:

    def _setup_about(self):
        self.popupmenu_aboutitem = gtk.ImageMenuItem(gtk.STOCK_ABOUT)
        self.popupmenu_aboutitem.connect('activate', self._about)
        self.popupmenu.add(self.popupmenu_aboutitem)

    def _about(self, button):
        aboutdialog = gtk.AboutDialog()
        aboutdialog.set_name(_('istanbul'))
        aboutdialog.set_version(config.version)
        aboutdialog.set_comments(_('Records a video of your desktop session'))
        aboutdialog.set_copyright(_('Copyright (c) 2005-6 Zaheer Abbas Merali,
John N. Laliberte\nPortions Copyright (C) Fluendo S.L.'))
        aboutdialog.set_authors(['Zaheer Abbas Merali','John N. Laliberte'])
        aboutdialog.set_website('http://live.gnome.org/Istanbul')
        aboutdialog.set_license('GPL-2')
        aboutdialog.set_translator_credits(_(''))
        aboutdialog.show_all()

A toy example of the AboutDialog can be found in 
/usr/share/doc/pygtk2-2.8.6/examples/pygtk-demo/demos/appwindow.py

A similiar toy example for fc6 pygtk should be available. You could play around
with the toy examples AboutDialog settings to see if you can reproduce the
behavior outside istanbul. Newer pygtk may require an explicit .connect
statement or the show_all() may be deprecated.