Bug 16397

I can reproduce it too.

Looks like the binary is missing the executable bit, but after adding it the program is still broken:

$ coban
/usr/lib64/python2.7/site-packages/coban ~
Traceback (most recent call last):
  File "coban.py", line 4, in <module>
    main.main()
  File "/usr/lib64/python2.7/site-packages/coban/main.py", line 726, in main
    app = Coban(False)
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", line 8628, in __init__
    self._BootstrapApp()
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", line 8196, in _BootstrapApp
    return _core_.PyApp__BootstrapApp(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/coban/main.py", line 136, in OnInit
    frame = Principale("Coban")         
  File "/usr/lib64/python2.7/site-packages/coban/main.py", line 214, in __init__
    u"Calcul de section de c�ble")
  File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py", line 12003, in Append
    return _core_.Menu_Append(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "Assert failure" failed at ./src/common/stockitem.cpp(213) in wxGetStockLabel(): invalid stock item ID


I think Coban is not compatible with wxPython 3.0 but expects version 2.8.

Assignee: bugsquad => dmorganec

 invalid stock item ID error is not necessarily a sign that it need wxPython2.8  but if no or an empty label is given to wx.MenuItem it assumes
to use a stock item
where is upstream ?

CC: (none) => makowski.mageia

Created attachment 6859 [details]
test for the wxPython issue

I can reproduce the bug and even do a simple test case.
Seems that we have a wxPython issue, may be we should build it against gtk3, not gtk2

I read in http://bugs.x2go.org/cgi-bin/bugreport.cgi?msg=5;bug=769 and the x2go guys said:

>>
I believe this is because we are mixing a gtk2 based notify-python module with
the gtk3 wxPython module. This seems like further impetus to move to a modern
python libnotify interface, either notify2 or gobject introspection Notify.
<<

It will be fixed in version 0.5.0.5

Perhaps that is the source of all that bugs.

CC: (none) => jemartins

(In reply to José Eduardo Martins from comment #4)
> I read in http://bugs.x2go.org/cgi-bin/bugreport.cgi?msg=5;bug=769 and the
> x2go guys said:
> 
> >>
> I believe this is because we are mixing a gtk2 based notify-python module
> with
> the gtk3 wxPython module. This seems like further impetus to move to a modern
> python libnotify interface, either notify2 or gobject introspection Notify.
> <<
> 
> It will be fixed in version 0.5.0.5
> 
> Perhaps that is the source of all that bugs.

Please don't mix with x2go, what you are reporting about notify is fixed for us by a patch 
# Use pygobject3 libnotify bindings with wxPython 3.0
# http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=769
Patch1:         pyhoca-gui-notify.patch

but unfortunately we in Mageia did someting wrong with wxPython, I'm working on it

In cauldron with wxPython-3.0.2.0-3.mga6 built with gtk3 the bug is solved, there are some graphics display issues, but it's working so that's really our wxPython that is bad.

I have uploaded a patched/updated package for Mageia 5.


Suggested advisory:
========================

Updated wxgtk, wxPython, coban and  packages fix bugs:

/usr/bin/coban was not executable.

wxgtk, wxPython did not handle correctly not ascii characters, and raised a "Assert failure" error when using non ascii characters in menu items.


Updated packages in {core,tainted}/updates_testing:
========================
coban-1.2.0-6.1.mga5

lib(64)wxgtku3.0-devel-3.0.2-1.1
wxgtk-3.0.2-1.1.mga5
lib(64)wxgtkugl3.0_0-3.0.2-1.1.mga5
wxgtk-debuginfo-3.0.2-1.1.mga5
lib(64)wxgtku3.0_0-3.0.2-1.1.mga5

wxPython-wxversion-3.0.2.0-1.mga5
wxPython-tools-3.0.2.0-1.mga5
wxPython-debuginfo-3.0.2.0-1.mga5
lib(64)wxPython3.0-devel-3.0.2.0-1.mga5
wxPython-3.0.2.0-1.mga5


Source RPMs: 
coban-1.2.0-6.1.mga5.src 
wxgtk-3.0.2-1.1.mga5.src
wxPython-3.0.2.0-1.mga5.src

Source RPM: (none) => coban-1.2.0-6.1.mga5 wxgtk-3.0.2-1.1.mga5 wxPython-3.0.1.1-1.mga5
Assignee: dmorganec => qa-bugs

Is there a risk of regression for other wxgtk or wxPython applications? If so, could you provide a list of applications that would be worth testing before validating this update?

I tested the update candidate on Mageia 5 64bit, coban works fine and playonlinux too (using wxPython), but as expected some wxgtk applications are broken.

filezilla gives:
filezilla: relocation error: filezilla: symbol _ZN22wxStringOperationsUtf816ms_utf8IterTableE, version WXU_3.0 not defined in file libwx_baseu-3.0.so.0 with link time reference

Whiteboard: MGA5-64-OK => feedback

I rebuilt filezilla against the updated wxgtku3.0-devel, and it installs and work fine. I think it even fixed a major issue I had with Filezilla where I could not connect to my TuxFamily FTP.

Playonlinux is not go to be no long use wxpython when they get ready that java based playonlinux 5. You remi should build it to testing anyway you fix playonlinux 4. 

https://www.playonlinux.com/en/comments-1295.html

CC: (none) => ozkyster

Assigning back to Philippe as per comment 9.

Assignee: qa-bugs => makowski.mageia

I think that filezilla is not the only one that must be rebuilt for the new fix of wxgtk-3.0.2, see the others one that need lib64wxgtku3.0_0:

$ urpmq --whatrequires lib64wxgtku3.0_0
aegisub
ariamaestosa
dolphin-emu
filezilla
freedink-dfarc
freedv
freefilesync
golly
hugin
lib64plplotwxwidgetsd0
megaglest
mkvtoolnix
openbabel
poedit
springlobby
tintii
urbanlightscape
wxPython
wxhexeditor
wxmaxima

So what is the best to do for this point?

CC: (none) => geiger.david68210

wxPython is rebuilt for others a rebuild would certainly not hurt. Too bad that we didn't saw this bug before release...

Please do not assign it to the QA team, this update is NOT ready as the packages listed in comment 13 will likely all be broken if the update is pushed.

The update candidate should include all rebuilt packages, not only wxgtk, wxpython and coban.

Assignee: qa-bugs => bugsquad

(In reply to Rémi Verschelde from comment #15)
> The update candidate should include all rebuilt packages, not only wxgtk,
> wxpython and coban.

Just we fork this bug into a new one against wxgtk, for clarity? It might be a bit confusing to updating two dozens of packages to fix a bug about coban lacking execution bit :)

s/Just/Should/

@Rémi: +1

I think it is better to file a new bug for new wxgtk fix and all rebuilt packages + the associates bug 16397 and bug 8198.

For the record : springlobby is ready in testing (bug 8198).

CC: (none) => yann.cantin

Revised advisory now that the wxgtk update is handled in bug 16560:


Suggested advisory:
========================

Updated coban package fixing missing execution bit

The /usr/bin/coban was not set as executable, and could therefore not be run.


Updated packages in core/updates_testing:
========================
coban-1.2.0-6.1.mga5

Source RPMs: 
coban-1.2.0-6.1.mga5.src

Assignee: bugsquad => qa-bugs
Source RPM: coban-1.2.0-6.1.mga5 wxgtk-3.0.2-1.1.mga5 wxPython-3.0.1.1-1.mga5 => coban-1.2.0-6.1.mga5

mga5 64 LANG=fr_FR.UTF-8

Installed :
wxgtk-3.0.2-1.1.mga5
lib64wxgtku3.0-devel-3.0.2-1.1.mga5
lib64wxgtkugl2.8_0-2.8.12-16.mga5
lib64wxgtku3.0_0-3.0.2-1.1.mga5
wxPython-3.0.2.0-1.mga5
wxPython-wxversion-3.0.2.0-1.mga5

coban-1.2.0-6.1.mga5.x86_64.rpm

Program start, no error.

Update OK.

Whiteboard: (none) => MGA5-64-OK

Validating, advisory uploaded.

Keywords: (none) => validated_update
Whiteboard: MGA5-64-OK => MGA5-64-OK advisory
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2015-0108.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED