Bug 502608

This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

still get this problem! help!

wxBase.i586          2.8.10-1.fc11   installed
wxPython.i586        2.8.9.2-2.fc11  @fedora
wxPython-devel.i586  2.8.9.2-2.fc11  @fedora
python.i586          2.6-9.fc11      @updates


Already update to fedora11. 
still have this problem

(In reply to comment #1)
> This bug appears to have been reported against 'rawhide' during the Fedora 11
> development cycle.
> Changing version to '11'.
> 
> More information and reason for this action is here:
> http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Cheng: It _is_ just a warning. It seems to work OK for me anyway, but it might be coincidence. 

Does it cause you ane real trouble?

Yes, I write a very simple program for test. 

#!usr/bin/env python

"""Spare.py is a starting point for a wxPython program."""

import wx
class Frame(wx.Frame):
    pass
class App(wx.App):
    def OnInit(self):
        self.frame = Frame(parent=None, title='Spare')
        self.frame.Show()
        self.SetTopWindow(self.frame)
        return True
if __name__=='__main__':
    app=App()
    app.MainLoop()

However, a error occurs like this 

Traceback (most recent call last):
  File "/home/freakrobot/Code/python/minwx26.py", line 5, in <module>
    import wx
  File "/home/freakrobot/Code/python/wx.py", line 2, in <module>
    class App(wx.App):
AttributeError: 'module' object has no attribute 'App'

Does this mean that "wx" does not work properly?

(In reply to comment #4)
> Cheng: It _is_ just a warning. It seems to work OK for me anyway, but it might
> be coincidence. 
> 
> Does it cause you ane real trouble?

Cheng: Your test program doesn't crash here. But notice how the stacktrace shows that your "import wx" imported "wx.py" in your local folder, not the one from the Fedora rpm.

I don't see how this is related to the release number mismatch and this issue at all.

Oh,sorry to waste time of you. I see, it works all right now.Thank you very much!

Sorry for posting here, it may not be an issue, but a wxpython application i'm using (enthought traits) gives segfault under some circumstances on my machine, and the enthought developers say they don't have problems on their machine. It may not be caused by this version mismatch issue, but still it gives them a reason to claim so, and i can never be sure. So it'd help if you could update the wxpython version.
Thanks a lot

pankaj: I suggest that you file a new issue and attach a minimal testcase for reproducing the segfault. We don't know if your issue is related to this issue, so discussing both at the same time might not be efficient.

Thanks Mads for the quick response. I'm sorry for causing the trouble, actually the enthought developers are not using the latest wxwidgets version, and the segfault is probably related to me using a newer wxwidgets version.
http://comments.gmane.org/gmane.comp.python.enthought.devel/20381
But now that traits is packaged in Fedora as python-Traits package, do you think i should take this issue with the python-Traits maintainer for him to consult with upstream.
Thanks again,

pankaj: If your conclusion is that a downgrade of wxPython from 2.8.9.2 to 2.8.9.1 solves your problem then I don't think it is related to this issue.

And it is far easier to mark a bugzilla entry as a duplicate (if that is the conclusion) than it is to ignore the "noise" of different issues being discussed at the same time. So please file another issue and attach a self-contained test case.

I don't know what role python-Traits or wxPython has for you, so I can't say which one is most relevant. Again: Please file a new issue. It can be reassigned if necessary.

I've seen this one too, while setting up a buildbot for Task Coach (http://www.fraca7.net:8010/waterfall/). Unit tests for Fedora 11 randomly crash, whereas they work fine on FC8, Ubuntu, Windows and MacOS. Fedora 11 is the only platform with the version mismatch problem.

It's quite difficult, if not impossible, to come up with a minimal test case, since the crash happens randomly and in different places each time.

Overall, I don't think it's a good idea to mix different versions of wxWidgets/wxPython since even minor version changes may imply different method signatures/additional methods in classes/etc. There's a reason why the wxPython source download includes the full wxWidgets source.

To make things worse, I just installed the latest upgrades on my Fedora 11, and it bumped up wxGTK to 2.8.10 while letting wxPython at 2.8.9.2. I'm expecting even more random crashes, but maybe it's just me.

I installed GRASS GIS (http://grass.itc.it/) on Fedora 11 64 bit compiling the sources. The compilation went fine, but each time I start the software the following warning is appearing:
GRASS 6.4.0svn (DEM):~ > /usr/lib64/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py:14450: UserWarning: wxPython/wxWidgets release number mismatch
  warnings.warn("wxPython/wxWidgets release number mismatch")

Some features of the software (3d and digitize modules) are not working. Then it is not just a question of a warning but something that is limiting the use of the software itself. This is happening only on Fedora 11, I have a version perfectly working on fedora 10 and, from the mailing list, it seems other distribution are not affected.

Laura: The warning is definitely real and the cause should be fixed, and I have no doubt that your program fails seriously, but to be fair you don't provide any evidence that your problem is related to the warning. It could just as well be caused by any other of its dependencies.

(In reply to comment #14)
Thank you for the prompt answer and sorry if I am not expressing myself properly, it is the first time I am dealing with a bug report.
I do not have any formal evidence that the problem is caused by the warning, but:
1) the two modules that are not working are heavily depending on wxPython/wxWidgets
2) the problems I am encountering are only happening on the system(s) were the warning is issued
I will try to investigate further.

I also see this issue -- as far as I can tell it's a warning, but the Python program I'm testing doesn't do that much yet so issues may well show up later.

Are the following version numbers relevant?
wxBase-2.8.10-2.fc11.x86_64
wxPython-2.8.9.2-2.fc11.x86_64

Note 2.8.10 vs. 2.8.9 in the above ...

Some news: I removed the wxPython/wxWidgets packages and rebuilt them from source, version 2.8.10.2 for both. The crash still happens. So I guess the sigsegv are not due to the version mismatch but rather by a bug down in GTK itself (or Pango, or another dependency).

Would the bugbuddy crash report be of any use ? Is so, I'll attach it.

Jérôme: No matter what: If your problem isn't related to "wxPython/wxWidgets release number mismatch" then it doesn't belong on this bug.

If the crash happens in wxPython/wxWidgets but built from source (not from Fedora package) then you should probably report it at the wxPython/wxWidgets project and not here in the Fedora tracker.

If it comes down to being a problem with Fedoras gtk/pango/whatever packages then a bug should be filed for these packages here in the tracker.

Right, but at first I thought the version mismatch was the cause for the crash, so I wanted to inform you it wasn't. Forget the crash report stuff :)

*** Bug 529090 has been marked as a duplicate of this bug. ***

*** Bug 509982 has been marked as a duplicate of this bug. ***

When will the package become an upgrade??

The problem is : 

Some python devs check wxpython availability by trying to import wx and this warning trigger an exception and make this check useless.
Ok, this can be done otherwise but currently, this bug break a common behaviour and break compatibility.

Cheers.

New new about the rfe here?

> There's a reason why the wxPython source download includes the full wxWidgets source.

And that reason is basically that the upstream wxPython developer snapshots wxWidgets at random points which may or may not be official wxWidgets releases and develops against that random snapshot. So this causes problems.

(14-May-2009) wxPython 2.8.10.1 This release fixes the problem with using Python 2.6's default manifest, and updates wxcairo to work with the latest PyCairo. More details are in the Recent Changes document.

It give an offical release of this version. Why you don´t update to it?

Re #26:
wxPython 2.8.10.1 doesn't compile with wx 2.8.10 which is included in Fedora:

src/gtk/_core_wrap.cpp:28693: error: 'const class wxShowEvent' has no member named 'IsShown'

That method can be found in http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/include/wx/event.h?annotate=62691 but not in http://svn.wxwidgets.org/viewvc/wx/wxWidgets/tags/WX_2_8_10/include/wx/event.h?annotate=59585

I don't see how Fedora can make a good solution to this problem. Fedora can/will not allow two different versions of wx at the same time, and Fedora cannot let the lack of a usable wxPython release prevent an upgrade to the latest wx version. Hacking and patching wxPython and maintaining that seems to be the only option. Any volunteers?

I am not familiar with wxPython upstream, but this mess alone makes it look like wxPython isn't mature and suitable for use in Fedora. Too bad for a fine project.

The only good solution would be if upstream made releases which didn't include wx, but worked with the latest wx release (or with the last n releases for bonus points).

> The only good solution would be if upstream made releases which didn't include
wx, but worked with the latest wx release (or with the last n releases for
bonus points).  

Amen to that.

What I've done in the past is backport all of the changes from wxPython to the wxGTK package as a patch, effectively making a non-official 2.8.10.1.

This works for wxPython, but isn't necessarily good for other users of wxWidgets, and it's a large package maintenance burden.

Hmm. 

Looking at http://packages.ubuntu.com/source/lucid/wxwidgets2.8 it seems like Ubuntu uses the wxPython releases as upstream for all their wx packages! Their wxwidgets2.8_2.8.10.1.orig.tar.gz is just wxPython-src-2.8.10.1.tar.bz2 with som extra files. An interesting example of how not to do it.

This may be related.  I'm getting problems running, audacity, python and gnuplot with similar errors.

Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import wx
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/__init__.py", line 45, in <module>
    from wx._core import *
  File "/usr/lib/python2.6/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 4, in <module>
    import _core_
ImportError: /usr/lib/libwx_gtk2u_core-2.8.so.0: symbol _ZN12wxAppConsole15CreateLogTargetEv, version WXU_2.8 not defined in file libwx_baseu-2.8.so.0 with link time reference


audacity: relocation error: /usr/lib/libwx_gtk2u_core-2.8.so.0: symbol _ZN5wxLog5DoLogEmPKwl, version WXU_2.8 not defined in file libwx_baseu-2.8.so.0 with link time reference

Recompiling gnuplot with wxSources compiled to /usr/local/... works OK so not sure if issue is with applications or wxLibs from Fedora.  I can't see any relevant tickets in the wxWidgets site.

System is Fedora 11 with latest updates.

audacity-1.3.9-0.3.beta.fc11.i586.rpm                                                 
wxPython-2.8.9.2-2.fc11.i586.rpm
wxBase-2.8.10-5.fc11.i586.rpm
wxGTK-2.8.10-5.fc11.i586.rpm  
wxGTK-media-2.8.10-5.fc11.i586
wxGTK-gl-2.8.10-5.fc11.i586

Re comment #30:
FWIW I don't get any errors with "import wx" on Fedora 12, just the warning.

You mention that you have been compiling from source. Could you verify that rpm -qV for the packages you mention is silent?

rpm -qV for all the WX packages is silent.
rpm -qV gnuplot
package gnuplot is not installed.


I only managed to get gnuplot to compile, Audacity wouldn't.  Wx libs were installed to /usr/local/lib.  Trouble is now I have two sets of wx libs.

Mike, If you have installed something manually then I think that somehow caused your problems. Perhaps something somehow picks up something from /usr/local - or perhaps something has put something in /usr/lib/python2.6/site-packages/ . In either case it is due to the manual installation and not related to the rpm packages.

So, to answer comment #30: No, I don't think it is related. If you can reproduce the problem on another clean machine then please file another issue.

Mads.  Update:  I removed all the wx rpms.  Which left some libwx* files in /usr/lib so I deleted those too.  Re-installed audacity with yum, which of course resolved the dependencies.  Audacity now working.  Installed wxPython and now just get a warning but OK.  Installed gnuplot, working fine too. 

I can only assume that a yum auto-update didn't properly remove older versions of the wx libs.  Still counts as a bug I guess, but with the update process.

Thanks.

Mike, I am very very very confident that no yum/rpm update/deletion left any spurious files in /usr/lib, so I will not allow your assumption to be the last word on this case ;-) If you think there is a bug then collect some evidence and file a new report.

wxPython-2.8.10.1-1.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/wxPython-2.8.10.1-1.fc12

wxPython-2.8.10.1-1.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/wxPython-2.8.10.1-1.fc11

FYI, regarding the wxPython-2.8.10.1-1 update: Dan Horák took the official wxPython-2.8.10.1 release and made a patch to "backport to wxGTK 2.8.10 API". The patch removes everything (new) that needs the unofficial wxWidget snapshot and thus doesn't work with the official wxWidget 2.8.10.

That seems to solve this issue - thanks. I have however not been able to test it yet. Anybody else?

(In reply to comment #38)

> That seems to solve this issue - thanks. I have however not been able to test
> it yet. Anybody else?    

yap works for me ! 


thanks,

wxPython-2.8.10.1-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

wxPython-2.8.10.1-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.