Bug 154618

Created attachment 113076 [details]
proposed new wxGTK.spec ideas

I find the high number of Obsoletes/Provides/Requires confusing. Here's the
rationale, one by one:

> Requires:       %{name}-common = %{version}-%{release}

Here you require wxGTK-common, but a few lines below you:

> Obsoletes:      wxGTK-common < 2.5.4
> Provides:       wxGTK-common

Effectively, the package requires itself via a versioned dependency on a
non-versioned "Provides". The "Requires" is not needed and wrong.

[...]

> # provides generic-name
> Provides:       wxWidgets

> Provides:       wxWidgets-devel

This looks wrong. The goal of a generic name--a virtual capability--is that
*any* package, which "provides" it, is sufficient. But, for instance, you could
not "Buildrequires: wxWidgets-devel" if multiple packages did "Provides:
wxWidgets-devel". Hence the concept behind this generic name is doubtful.

[...]

> # all of these are for previous Fedora Extras sub-packages
> Obsoletes:      wxGTK2 < 2.5.4
> Provides:       wxGTK2

The version here and in all the other Obsoletes is too low. In wxGTK = 2.5.5,
you would need to either

  Obsoletes: wxGTK2 < 2.5.5

or

  Obsoletes: wxGTK2 <= 2.5.4

so any 2.5.4 package would be obsoleted, too, and

  Provides: wxGTK2 = %version-%release

as else you could not reintroduce wxGTK2 > %version-%release without increased
package update efforts. Same for all other pairs of Obsoletes/Provides. The
Provides ought to be versioned:

  Obsoletes: oldname < %version-%release
  Provides: oldname = %version-%release

The first one is a mistake, which I just noticed myself.

The second: why couldn't you "Buildrequires: wxWidgets-devel" if multiple
packages  provide it? I'm not particularly attached this one, though.

The third: yep. The 2.5.4s are a result of not looking carefully enough when
updating to the new version. I thought I had a good reason for not using
%version when I first made it, but I can't think of it now.

Thanks for the feedback -- here's a version fixing the first and third issue.

Created attachment 113103 [details]
updated updated wxGTK.spec

Assume we have wxGTK-devel and wxMotif-devel and both "Provides:
wxWidgets-devel". Which one would a package with "Buildrequires:
wxWidgets-devel" build against?

Obviously the specific one it is set up to support. If the package picked up a
generic wxWidgets implementation (which would be possible with an API framework
like wxWidgets), the build would not be reproducible.

Hence the purpose of a generic wxWidgets and wxWidgets-devel is doubtful. The
individual implementations of wxWidgets are not interchangeable. Only the
wxWidgets API is the same, the ABI of the individual ports is not.

Created attachment 113124 [details]
updated, updated updated wxGTK.spec :)

Okay, I can buy that. I guess I had just assumed that they'd be ABI compatible
without looking or thinking about it hard enough. :)

Thanks again for looking at this.

Created attachment 113125 [details]
proposed updated wxGTK.spec

(sorry, forgot to actually increase the release number in that one.)

Created attachment 113745 [details]
proposed wxGTK.spec for 2.6.0

wxWidgets 2.6.0 is out. Here's the updated spec file -- only minor changes.

Wait, there's a problem with that one -- sorry, jumping the gun. Fixed update
coming soon. :)

Created attachment 113746 [details]
correct proposed wxGTK.spec for 2.6.0

PS: I have no strong opinion about whether the package should be called wxGTK as
in the spec file attached to this bug or wxGTK2 to match wxPythonGTK2 (and the
gtk2 package itself). The main suggestion is dropping the complication required
by including both old gtk+ 1.x and gtk2 support. (And also consolidating the
subpackages.)

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

Note that this fixes bug #159511 -- wxrc is correctly in the devel package.

Created attachment 116759 [details]
updated to 2.6.1

* Thu Jul 14 2005 Matthew Miller <mattdm> - 2.6.1-0.1
- update to 2.6.1
- from Michael Schwendt in 2.4.2-11 package: build-require
  xorg-x11-Mesa-libGL and xorg-x11-Mesa-libGLU (the libGL and libGLU
  deps aren't provided in FC3, so not using that).
- from Thorsten Leemhuis in 2.4.2-12 package: sed -i -e
  's|/usr/lib\b|%%{_libdir}|' in configure also to fix x86_64
- properly include older 2.4.x changelog

Notes on 2.6.1-0.1 package: haven't tested with gcc4 or on FC4 yet; will do that
soon. Also, only tested on i386.

I assume the new packages will come with unicode support enabled?

I tried compiling poEdit to use for localizing Fedora, but it's a no go with
current wxGTK2 packages.

Yes, the proposed spec file has --enable-unicode.

So, since wxGTK in Extras is officially "orphaned", we need a different
approach:

Do we have a volunteer package maintainer? Matthew?

In case we don't, how about the following? Create an ordinary CVS-style
branch in Extras CVS where we check in the proposed changes, and then
continue from there. Thoughts?

I can take official responsibility for it. But I have Death Plague Cough right
now (it's going around at work) so it may be a few days before I gather my
strength to do it. :)

/me fears impending move to Boston area.

Oh, it's great! A few Death Plagues a year builds character.

wxPython 2.6 wants us to also run:

make %{?_smp_mflags} -C contrib/src/animate
%makeinstall -C contrib/src/animate

(this adds /usr/lib/libwx_gtk2u_animate-2.6.so.0
/usr/lib/libwx_gtk2u_animate-2.6.so.0.0.0 and /usr/lib/libwx_gtk2u_animate-2.6.so)

I can add that.

License:        wxWindows Library Licence

I think that this should be changed to wxWidgets prior to the OSI approval of
the licence - simple reason is down to the amount of grief the wx people had
from a certain company.

Release:        0.1

Should really be

Release:        0.1%{?dist}

(little thing)

We need to go ahead and bite the bullet on this. I'm willing to maintain the old
compat-wxGTK and compat-wxPython 2.4 bits.

Sorry I've been out of touch -- 8 month old child + start of school year at work
= crazy. Will work on this RSN, for real.

Created attachment 119633 [details]
Updated spec file

Here's an update of Matthew's spec file.
Changelog:
- Update to 2.6.2.
- Include the sample wx bakefiles.
- Include new .mo files.
- From Paul Johnson:
  Change license to wxWidgets due to concerns over trademark infringement.
  Add dist tag.
- From Tom Callaway: Build and include libwx_gtk2u_animate-2.6.

I'm not prepared to take on this package but I hope this can help you, Matthew,
catch up.  I'm hoping to see a pgadmin that's useful for the present postgresql
so I thought I'd give a little help here.

SPEC and SRPM in:
http://www.tiki-lounge.com/~toshio/fedora/

Thank you very much. This is still large on my radar but I've continued to be
swamped....

Is there any sign of movement on this? I have a couple of packages waiting for
submission which need wx2.6

Will work on it this weekend. Need to get myself caught up on current FE
procedures. Sorry again for the delay.

Minor change to the spec at http://www.tiki-lounge.com/~toshio/fedora/ - there
is a small remarked piece about wxWindows and OSI licence. From what I gather,
it's now been okayed.

Currently building it - looks fine.

Yes, looks good to me too -- thanks, Toshio. Since this isn't a new package, but
a new maintainer, should this go through further review, or should I go ahead
and check it in?

Test-built on FC4, and seems otherwise ok, but shouldn't the BR be  
libgnomeprintui22-devel, not libgnomeprint22-devel?  

Possibly. :)

That last spec file will need to be updated slightly for the new modular X.

I'd really like to see this update out ASAP, as many recent releases of projects
using wxWindows fail to build against the current 2.4.x packages (VLC, xMule).

Minor suggestions :
- %setup -q -n %{name}-%{version} : -n not needed
- %{summary}. as %description should be avoided. Spec file grammar doesn't say
  if it'll be the main or the sub-package summary.
- export CC and CXX are useless, add a comment to the spec otherwise.
- same for export CFLAGS and CXXFLAGS, as %configure is used and sets them
- %dir %{_libdir}/wx should be part of the devel sub-package, not the main

Matthias -- thanks. The modular update suggestion was already done; see
http://www.mattdm.org/misc/fedoraextras/

I'll include your other ones too. Any suggestions on the wxPython packages
there, by the way?

I just tried rebuilding wxGTK 2.6.2 on FC4 and got :
/usr/bin/ld: cannot find -lwxregexu-2.6
That lib didn't get compiled, although configure wrote :
[...]
checking for glibc 2.1 or later... yes
configure: WARNING: Defaulting to the the builtin regex library for Unicode
build.
[...]
  Which libraries should wxWidgets use?
                                       jpeg               sys
                                       png                sys
                                       regex              builtin
                                       tiff               sys
                                       zlib               sys
[...]

Possibly a bug in 2.6.2.
Has anyone recompiled it successfuly on FC4?

Hmmm. I'm only intending to target this for FC5, since it's such a big jump. We
should, however, find out why it's failing and add the proper buildrequires.

I don't have a handy FC4 test machine though....

I found the problem : A leftover "\" at the end of the last configure option, so
the make command was being appended on the same line, because I had removed the
empty line between the two sections (from Toshio's 2.6.2 spec file, still in
yours). Please fix, it bites! ;-)

From there, VLC and xMule rebuild fine. I'll test aMule and Audacity, and
probably push this 2.6 package into freshrpms.net for FC4... as the benefit for
users who have enabled the freshrpms.net repository seems worth the minor
breakage it'll cause with Extras packages depending on some older wxGTK.

Matthias,

Why not just push it into extras for FC-4 and 5? I've got those "compat-"
packages ready to go, we will very quickly see which packages need the compat-*
versions in order to rebuild, and I can patch them up easily.

I'm all for pushing 2.6 to Extras FC4 & FC5, with the appropriate compat-*
packages (I think that a single one based on the current FC4 2.4 package would
be enough, since it contains both gtk1 and gtk2 libs).

Matthew, are you going to be the new wxGTK owner? If so, please update
owners.list, and if no one objects, go ahead and do the update, having Spot
introduce the compat package at the same time (or shortly after, since things
should get held back in a non-breaking matter anyway).

Here are the packages that might need a rebuild (if ever we just want to avoid
the whole compat approach, might be doable as there aren't that many) :

$ for file in *.i386.rpm; do rpm --nogpg -qp --requires $file | grep libwx
>/dev/null && echo $file; done
audacity-1.2.3-5.i386.rpm
bochs-2.2.1-1.fc4.i386.rpm
bochs-2.2-2.i386.rpm
comical-0.4-9.fc4.i386.rpm
pgadmin3-1.0.2-5.i386.rpm
scorched3d-37.2-2.i386.rpm
wxPythonGTK2-2.4.2.4-7.i386.rpm

In addition to these, I've got VLC, aMule and xMule, which all build fine with
2.6, so I won't be needing the compat package for freshrpms.

wxPythonGTK2 needs to be bumped to 2.6 at the same time as wxGTK2 (but I see
Matthias has a package for that too).

Audacity, Bochs, comical, and scorched3d won't work with unicode enabled wxGTK,
gentoo works around this issue by building both the unicode and the non-unicode
wxGTK libs and config. Then, they patch applications to call $WX_CONFIG instead
of wx-config, and set WX_CONFIG=wx-gtk2-unicode-config or
WX_CONFIG=wx-gtk2-config as needed.

pgadmin3 needs the stc package, which is only found in 2.4.

Matthias -- updated with your suggestions / fixes at
http://www.mattdm.org/misc/fedoraextras/

Spot -- Yeah, I have wxPython packages too. The current audacity won't work with
the new wxGTK, but the CVS version will *only* work with the new one.

I'm not terribly keen on building both versions of the library; seems like the
applications ought to get fixed. (Maybe build them against your compat packages
in the meantime?)

Also, wxPython 2.6.2.x isn't out yet, causing it to spit out a warning at
runtime when built against this version. Ugly.

OK, the last thing I haven't mentionned about the spec file are the
obsoletes : I find it smarter to hardcode the version when the obsoletes
happened instead of putting the "dynamic" %{version}-%{release}.

For instance :
Obsoletes:      wxGTK2 < %{version}-%{release}
Would be replaced by :
Obsoletes:      wxGTK2 < 2.6.2-1

That way you have a fixed limit on what you're obsoleting, which is
IMHO a good thing.

Okay, this is done and in tree. (Without Matthias's latest change -- I'll
remember that for next time I do an update, though.)

On to wxPython....

Spot, you wanna add the compat package now?

FYI, I've gotten a bunch of reports from this morning about aMule crashing
for some users with this wxGTK 2.6.2. One pointed me to this bug report :

http://bugs.gentoo.org/show_bug.cgi?id=109483

Which includes a patch to fix the issue. I guess I didn't notice the problem
since I use the default en_US or C pretty much everywhere.

This definitely needs to be included in the 2.6.2 packages before they're
pushed out for FC-4.

Matthias -- thanks, working on that now. Any comments on the wxPython packages?
(should go in bug #163440)

I don't have anything to actually test wxPython with, so all I'll do is a quick
review of the spec, but no deeper testing.
Spot: Got those compat-* libs ready? Time to roll out wxGTK 2.6? With the above
patch, it's working great with aMule and VLC.

For audacity, which was mentioned, the 1.3.0 (beta) works great for me with
wxGTK 2.6.2 too. You can find my spec file and patches here :
http://svn.rpmforge.net/svn/trunk/rpms/audacity/
(quite a few workarounds are needed)
Might be a good candidate for Extras devel.

Is there not going to be 2.6.2 for FC4? If not, then someone else
must take over the task of building audacity (1.3.0) for devel.

I think that the holdup is actually on me at this point to push the compat
packages into Extras.

I'll start that review process this week.

Compat packages are pending review at 175500.

What about adding support for databases? This needs --with-odbc in configure,
adding additional BuildRequires and Requires, maybe creating a specific subpackage.

Nicola -- please file a separate bug request for that. Thanks.

(In reply to comment #54)
> Nicola -- please file a separate bug request for that. Thanks.

Ok, see bug 176950.

Turns out I actually need wxGTK 2.6 in FC-4 for comical, as the most recent
versions don't build with 2.4.2. I see 2.6 in devel, are we still holding on it
in FC-4 for this patch:

http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/src/common/intl.cpp.diff?r1=1.166&r2=1.166.2.1&diff_format=u

I'd like to see it go in, now that the compat-* packages are in as well.

*nod*

Wife and baby going out of town next week -- ideal time to get this wrapped up. :)

Has that patch gone in would be nice to test wxWidgets 2.6 on FC-4.  I would
like to test the musicbrainz tagger, picard, which requires wxPython 2.6:

http://musicbrainz.org/wd/PicardDownload

Okay, working on the final touches here.

To my joy, the current package now doesn't build on FC5-rawhide. *sigh*.

Hey, still no news about pushing the 2.6 update to FC-4?

I want to get the wxPython thing sorted out first. Sorry it's all taking so long.

wxGTK 2.6.3 should be out any day now. That will resolve the wxPython issue,
allowing bug #163440 to go forward, and at that point I'll push this back to
FC4. Just in time for FC5. :)

At last, great! Please let us know as soon as wxGTK 2.6.3 goes into FC5 Extras
and FC4 Extras, as I'll have some cleaning up and rebuilding to do.

Ping?

Looks like wxwidgets.org 2.6.3 is out (as well as wxPython 2.6.3.0
http://wxpython.org/recentchanges.php).

Buildsystem has been broken. wxGTK package has been ready to go for days. I'll
try again right now.

Looks like devel has succeeded, so 'bout those FC-4 & FC-5 builds?

Sorry for the lack of communication -- I'm overbooked. :) There's a couple of
patches that need to go in before the FC4/5 ones go out.

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

Okay. This is building in FC4 and should be available soon. If that turns out to
be All Horribly Broken, please reopen this. For other issues, file new, specific
bugs. Thanks!