[wxPython] Experimental RPMs available, feedback desired

Hi,

I've taken the plunge and finally read "Maximum RPM" and have uploaded to SF
a set of experimental RPMs that I would like people to try out and give
feedback about. Only for Python 2.2 so far, I'l do 2.1 RPMs for the final
release. You can get them here:

http://sf.net/project/showfiles.php?group_id=10718&release_id=83146

These RPMs contain both wxPython as well as the wxGTK runtime libraries. (I
know, I said that I wouldn't do it but the idea kept nagging at me even
without Kevin's help.)

They will conflict with any wxGTK or wxPython packages you already have
installed, but I think I have the 'Obsoletes' tags set right to handle that
so if you are feeling adventurous go ahead and try installing one of these
without uninstalling the old ones first.

I've tried to minimize the dependencies that these packages have, so I will
also be interested in seeing how many RPM-based Linux distros and versions
they can install on.

The wxPythonGTK-py2.2-dbg package is similar to the hybrid builds on MSW in
that __WXDEBUG__ is defined for the C/C++ compiles, which will turn on an
assortment of runtime checks that generate wxASSERT messages when the checks
fail. (Eventually I hope to be able to turn those into Python
Exceptions...) I didn't upload the SRPM for the -dbg package because there
is only a one line difference in the spec file between the two so it seemed
a bit of a waste of bandwidth to me.

Anyway, let me know what you think about the combined RPM approach. If need
be I can change it so this one Spec will generate multiple RPMs, so we won't
have to go back to the standard wxGTK RPM and lose the __WXDEBUG__ setting.

Also, those of you familiar with building RPM spec files please take a look
and ensure I didn't do something truly stupid. (I already know that I don't
have any %doc files, and I need to do a -devel subpackage...)

BTW, should the "-py2.2" be part of the package name, version or release?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Hi,

Robin Dunn wrote:

They will conflict with any wxGTK or wxPython packages you already
have installed, but I think I have the 'Obsoletes' tags set right

Aaaagh!
I haven't checked the packages yet, but I really thing this is not a
good idea (the conflict with wxGTK). What if somebody wants to
install a wxGTK-based C++ app (say, poEdit) that requires wxGTK RPM?
Even if this maxi-wxPython package has Provides: wxGTK etc., it would
be counterintuitive to install wxPython if I only need wxGTK.
Moreover, what about wxGTK-static (which requires wxGTK)?

I think a much better approach would be to install independent
(=non-conflicting) version of wxGTK for the needs of this wxPython
package. For example, it could be in /usr/lib/wxPython and your .spec
file would install it like this:
  cd wxGTK-*
  ./configure --prefix=/usr/lib/wxPython --disable-soname
  make && make install
The important part is --disable-soname, Python module will then always
look for /usr/lib/wxPython/lib/libwxgtk-2.3.so.1 and _not_ for
libwxgtk-2.3.so.1 in LD_LIBRARY_PATH or /etc/ld.so.conf paths.

The RPM would then contain only the necessary runtime:
  %dir /usr/lib/wxPython
  /usr/lib/wxPython/lib/lib*.so.*
  /usr/lib/wxPython/share/wx
  /usr/lib/wxPython/share/locale

(I'm checking in a trivial modificiation to wxWin's
src/common/intl.cpp to allow reading locales from the location
specified by --prefix argument to configure right now.)

What do you think?

BTW, should the "-py2.2" be part of the package name, version or
release?

The name, I'd say.

Regards,
Vaclav

I think a much better approach would be to install independent
(=non-conflicting) version of wxGTK for the needs of this wxPython
package. For example, it could be in /usr/lib/wxPython and your .spec
file would install it like this:
  cd wxGTK-*
  ./configure --prefix=/usr/lib/wxPython --disable-soname
  make && make install
The important part is --disable-soname, Python module will then always
look for /usr/lib/wxPython/lib/libwxgtk-2.3.so.1 and _not_ for
libwxgtk-2.3.so.1 in LD_LIBRARY_PATH or /etc/ld.so.conf paths.

Thanks. I was trying to figure out something similar to this but got stuck.
This is definitly a better idea.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

This sounds absolutely great for my purposes! We have had a lot of issues with
end users trying to get up and running with wxPython before even diving into
our software. This scheme would solve almost all of the problems it seems.

Karl

···

On Saturday 20 July 2002 03:03 pm, Robin Dunn wrote:

> I think a much better approach would be to install independent
> (=non-conflicting) version of wxGTK for the needs of this wxPython
> package. For example, it could be in /usr/lib/wxPython and your .spec
> file would install it like this:
> cd wxGTK-*
> ./configure --prefix=/usr/lib/wxPython --disable-soname
> make && make install
> The important part is --disable-soname, Python module will then always
> look for /usr/lib/wxPython/lib/libwxgtk-2.3.so.1 and _not_ for
> libwxgtk-2.3.so.1 in LD_LIBRARY_PATH or /etc/ld.so.conf paths.

Thanks. I was trying to figure out something similar to this but got
stuck. This is definitly a better idea.

--
Karl MacMillan
Digital Knowledge Center
Johns Hopkins University
karlmac@jhu.edu
(410)516-6217

EVIL BUG IN PRERELEASE:

  wxPythonGTK-py2.2-dbg-2.3.3pre5-1

···

---------------------------------------------------------------------------------
from wxPython.wx import *

COUNT=3
class Dialog(wxDialog):
  def __init__(self):
    wxDialog.__init__(self,None,-1,"hallo",size=(400,400))
    self.bt=wxButton(self,-1,"click",pos=(0,0))
    self.lv=wxListView(self,-1,style=wxLC_REPORT,pos=(0,30),size=(400,200))
    self.lv.InsertColumn(0,"sepp",width=400)
    EVT_BUTTON(self,self.bt.GetId(),self.onTest)
  def onTest(self,event):
    d=wxMessageDialog(self,"message","caption",wxOK|wxCENTER)
    d.ShowModal()
    d.Destroy()
    for i in xrange(COUNT):
      self.lv.InsertStringItem(i,"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"+str(i))

class App(wxApp):
  def OnInit(self):
    f=Dialog()
    f.ShowModal()
    f.Destroy()
    return 1

app=App()
app.MainLoop()
---------------------------------------------------------------------------------
1. Click on the button
2. Be sure that the messagedialog is over the ListCtrl Items
3. Confirm the messagedialog

-> error:
Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 1987 error_code 8 request_code 59 minor_code 0
Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 1988 error_code 8 request_code 59 minor_code 0

Program exit...

Seems like a refresh problem of the ListCtrl in combination with the MessageDialog,
but only if the MessageDialog overlaps the listitems and if COUNT>=3!!!

P.S.: This does NOT occur with version: wxPython-2.3.2.1-1-Py21.i386.rpm

Thank you very much, Greetings, Andre'

--
_____________________________________________
inworks GmbH Andre Reitz
Magirusstrasse 44 Tel. 0731/93 80 7-21
89077 Ulm http://www.inworks.de

Vaclav,

I think a much better approach would be to install independent
(=non-conflicting) version of wxGTK for the needs of this wxPython
package. For example, it could be in /usr/lib/wxPython and your .spec
file would install it like this:
  cd wxGTK-*
  ./configure --prefix=/usr/lib/wxPython --disable-soname
  make && make install
The important part is --disable-soname, Python module will then always
look for /usr/lib/wxPython/lib/libwxgtk-2.3.so.1 and _not_ for
libwxgtk-2.3.so.1 in LD_LIBRARY_PATH or /etc/ld.so.conf paths.

I've been playing with this but had to do a bit more to get it working.
When built as described above the wxPython binaries are still trying to load
the wxGTK libs from the LD_LIBRARY_PATH or ld.so.conf paths.

What is needed is that the wxPython .so's need to be linked with the -rpath
option to prepend /usr/lib/wxPython/lib to the search path at runtime. I've
verified that adding "-Wl,-rpath -Wl,/usr/lib/wxPython/lib" does work, but
does it make sense to do it this way?

Anyway, I've made some simple changes to configure.in and wx-config.in but
since I've avoided that as much as possible in the past I'm hoping that you
would take a quick look at it. Patches attached. Should it also check that
the compiler/linker supports -rpath or just trust the user running
configure?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

begin 666 rpath.patch
M26YD97@Z(&-O;F9I9W5R92YI;@H]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]"E)#
M4R!F:6QE.B O:&]M92]W>&-V<R]W>%=I;F1O=W,O8V]N9FEG=7)E+FEN+'8*
M<F5T<FEE=FEN9R!R979I<VEO;B Q+C4X-@ID:69F("UU("TT("UB("UR,2XU
M.#8@8V]N9FEG=7)E+FEN"BTM+2!C;VYF:6=U<F4N:6X),3D@2G5L(#(P,#(@
M,3DZ,C$Z-#D@+3 P,# ),2XU.#8**RLK(&-O;F9I9W5R92YI;@DS,"!*=6P@
M,C P,B P,3HP,CHQ-R M,# P, I 0" M-S,V+#@@*S<S-BPQ-2! 0 H@"B!7
M6%]!4D=?14Y!0DQ%*&-O;7!A=#(P+" @(" @(%L@("TM96YA8FQE+6-O;7!A
M=#(P(" @(" @(&5N86)L92!W>%=I;F1O=W,@,BXP(&-O;7!A=&EB:6QI='E=
M+"!76%=)3E]#3TU0051)0DE,25197S(I"B!76%]!4D=?14Y!0DQ%*&-O;7!A
M=#(R+" @(" @(%L@("TM9&ES86)L92UC;VUP870R,B @(" @(&1I<V%B;&4@
M=WA7:6YD;W=S(#(N,B!C;VUP871I8FEL:71Y72P@5UA724Y?0T]-4$%424))
M3$E465\R7S(I"B **T%#7T%21U]%3D%"3$4H<G!A=&@L(" @(" @(" @6R @
M+2UE;F%B;&4M<G!A=&@]1$E2(" @(" @;W5T<'5T('1H92!R<&%T:"!F;&%G
M(&9R;VT@=W@M8V]N9FEG72P@6W=X55-%7U)0051(/2(D96YA8FQE=F%L(ETI
M"BL**VEF('1E<W0@(B1W>%5315]24$%42"(@(3T@(B([('1H96X**R @(%=8
M0T].1DE'7U)0051(/2(M5VPL+7)P871H("U7;"PD=WA54T5?4E!!5$@B"BMF
M:0HK"BL*(&1N;" M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2T*(&1N
M;" H<VUA;&PI(&]P=&EO;F%L(&YO;B!'54D@8VQA<W-E<PH@9&YL("TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM
M+2TM+2TM+2TM+2TM+2TM+2TM+2TM+2TM+0H@"D! ("TT.3<R+#@@*S0Y-SDL
M.2! 0 H@04-?4U5"4U0H5UA#3TY&24=?3$E"4U]'3"D*($%#7U-50E-4*%=8
M0T].1DE'7TQ)0E-?4U1!5$E#*0H@04-?4U5"4U0H5UA#3TY&24=?3$E"4U]3
M5$%424-?1TPI"B!!0U]354)35"A76$-/3D9)1U])3D-,541%*0HK04-?4U5"
M4U0H5UA#3TY&24=?4E!!5$@I"B *(&1N;"!T:&4@;&ES="!O9B!F:6QE<R!T
M;R!C;VUP:6QE+VEN<W1A;&P*($%#7U-50E-4*$%,3%]/0DI%0U13*0H@04-?
M4U5"4U0H04Q,7TA%041%4E,I"DEN9&5X.B!W>"UC;VYF:6<N:6X*/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
M/3T]/3T]/3T]/3T]/3T]/0I20U,@9FEL93H@+VAO;64O=WAC=G,O=WA7:6YD
M;W=S+W=X+6-O;F9I9RYI;BQV"G)E=')I979I;F<@<F5V:7-I;VX@,2XT-0ID
M:69F("UU("TT("UB("UR,2XT-2!W>"UC;VYF:6<N:6X*+2TM('=X+6-O;F9I
M9RYI;@DQ.2!!<'(@,C P,B Q.#HS.3HP-B M,# P, DQ+C0U"BLK*R!W>"UC
M;VYF:6<N:6X),S @2G5L(#(P,#(@,#$Z,#(Z,3<@+3 P,# *0$ @+3$P,RPQ
M,2 K,3 S+#$Q($! "B @(" @(" @(" @;&EB<STB+4Q ;&EB9&ER0"(*(" @
M(" @(&9I"B *(" @(" @(&EF('1E<W0@)'-T871I8U]F;&%G(#T@>65S(#L@
M=&AE;@HM(" @(" @(" @(&5C:&\@(B1L:6)S($!,1$9,04=30"! ;&EB9&ER
M0"] 5UA#3TY&24=?3$E"4U]35$%424- ($!,24)30"! 1$U!3$Q/0U],24)3
M0"(**R @(" @(" @("!E8VAO("(D;&EB<R! 3$1&3$%'4T @0%=80T].1DE'
M7U)0051(0"! ;&EB9&ER0"] 5UA#3TY&24=?3$E"4U]35$%424- ($!,24)3
M0"! 1$U!3$Q/0U],24)30"(*(" @(" @(&5L<V4*+2 @(" @(" @("!E8VAO
M("1L:6)S($!,1$9,04=30"! 5UA#3TY&24=?3$E"4T @0$1-04Q,3T-?3$E"
M4T **R @(" @(" @("!E8VAO("1L:6)S($!,1$9,04=30"! 5UA#3TY&24=?
M4E!!5$A ($!76$-/3D9)1U],24)30"! 1$U!3$Q/0U],24)30 H@(" @(" @
?9FD*( H@(" @(" @.SL*(" @(" M+6=L+6QI8G,I"@``
`
end

Hi,

Robin Dunn wrote:

I've been playing with this but had to do a bit more to get it
working. When built as described above the wxPython binaries are
still trying to load the wxGTK libs from the LD_LIBRARY_PATH or
ld.so.conf paths.

Weird... (Or, rather, lack of understanding on my side :frowning: I'm sure it
does work with wxWin samples, which is probably because it uses
explicit filename of the library:
  c++ -o menu menu.o ../../lib/libwx_gtkd-2.3.so.2.0.0
instead of -l argument:
  c++ -o menu menu.o -L../../lib -lwx_gtkd-2.3

What is needed is that the wxPython .so's need to be linked with
the -rpath option to prepend /usr/lib/wxPython/lib to the search
path at runtime. I've verified that adding "-Wl,-rpath
-Wl,/usr/lib/wxPython/lib" does work, but does it make sense to do
it this way?

I think so.

Anyway, I've made some simple changes to configure.in and
wx-config.in but since I've avoided that as much as possible in the
past I'm hoping that you would take a quick look at it. Patches
attached. Should it also check that the compiler/linker supports
-rpath or just trust the user running configure?

I think it's ok as it is -- although it is a bit misleading to have
directory name store in a variable named wxUSE_RPATH (and not, say,
wxRPATH_DIRECTORY). It took me a while to understand that it is _not_
a bug :wink: It may be worth checking for $wxUSE_RPATH != "disable",
too...

HTH,
Vaclav

I think it's ok as it is -- although it is a bit misleading to have
directory name store in a variable named wxUSE_RPATH (and not, say,
wxRPATH_DIRECTORY). It took me a while to understand that it is _not_
a bug :wink:

Right. That's what I get for just doing a copy/paste without thinking
through it.

It may be worth checking for $wxUSE_RPATH != "disable",
too...

Thanks. I'll do that and check in the changes.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!