Hi,
I have a software (not free) which depends on compat-wxGTK-2.4.2. Apparently the rpm has been set obsolete. Do you want to keep it that way ? I can keep wxgtk2 on my repo with my non free software but if you are interesed, I can maintain this package for centos and fedora (32 bits only).
I have never contributed on a fedora/centos repository.
Regards, Pascal Parois
On Sat, Apr 19, 2008 at 11:22:43AM +0100, Pascal wrote:
Hi,
I have a software (not free) which depends on compat-wxGTK-2.4.2. Apparently the rpm has been set obsolete. Do you want to keep it that way ?
The latest 2.4 release dates back from 2003-09-21. So it is not very likely to lead to much developper support. But you could submit it to fedora, if you are ready to do all the backporting of serious bugs, especially security bugs.
You could read: http://fedoraproject.org/wiki/BrianPepple/DraftCompatPackages
In that it is told that 'the primary package maintainer' should not be against. I am not sure it should be mandated, but at least you should contact the primary maintainer and discuss with him about the compat package.
I can keep wxgtk2 on my repo with my non free software but if you are interesed, I can maintain this package for centos and fedora (32 bits only).
It is EPEL here, not centos (though EPEL can be used with centos or RHEL).
I have never contributed on a fedora/centos repository.
You can read http://fedoraproject.org/wiki/PackageMaintainers/Join http://fedoraproject.org/wiki/PackageMaintainers/HowToGetSponsored
The front page is at http://fedoraproject.org/wiki/PackageMaintainers
-- Pat
On Sat, 2008-04-19 at 13:12 +0200, Patrice Dumas wrote:
But you could submit it to fedora, if you are ready to do all the backporting of serious bugs, especially security bugs.
Actually, speaking as the former maintainer for compat-wxGTK-2.4*... I would really advise against it. In the wx space, this ancient piece of unmaintained junk conflicts heavily with the later wxGTK releases, to the point where you cannot effectively have the 2.4 compat package and any later wx packages on a system at the same time without both sets of wx dependent applications either failing to work entirely or randomly crashing.
Tell upstream for this proprietary bomb that 2003 has long since moved on, and they should port to either a more modern version of wx, or a different toolkit.
~spot
Le Sat, 19 Apr 2008 10:09:33 -0400, "Tom "spot" Callaway" tcallawa@redhat.com a écrit :
On Sat, 2008-04-19 at 13:12 +0200, Patrice Dumas wrote:
But you could submit it to fedora, if you are ready to do all the backporting of serious bugs, especially security bugs.
Actually, speaking as the former maintainer for compat-wxGTK-2.4*... I would really advise against it. In the wx space, this ancient piece of unmaintained junk conflicts heavily with the later wxGTK releases, to the point where you cannot effectively have the 2.4 compat package and any later wx packages on a system at the same time without both sets of wx dependent applications either failing to work entirely or randomly crashing.
Not good, even though I never found such problem.
Tell upstream for this proprietary bomb that 2003 has long since moved on, and they should port to either a more modern version of wx, or a different toolkit.
Impossible. This is an old fortran 77 / wxGTK software. It's barely alive and many people need it including me :)
http://www.xtl.ox.ac.uk/crystals.html
Regards, Pascal
On Sat, 2008-04-19 at 17:28 +0100, Pascal wrote:
Impossible. This is an old fortran 77 / wxGTK software. It's barely alive and many people need it including me :)
Given that this app isn't going in Fedora anyways, perhaps you can bundle the ancient wxGTK bits inside of its RPM?
~spot
Le Sat, 19 Apr 2008 18:55:50 -0400, "Tom "spot" Callaway" tcallawa@redhat.com a écrit :
On Sat, 2008-04-19 at 17:28 +0100, Pascal wrote:
Impossible. This is an old fortran 77 / wxGTK software. It's barely alive and many people need it including me :)
Given that this app isn't going in Fedora anyways, perhaps you can bundle the ancient wxGTK bits inside of its RPM?
It's what I am doing, well not in a bundle, I keep the compat-wxGTK rpm alone. But as wxGTK is GPL, I asked the question here just in case :)
Pascal
On Sat, Apr 19, 2008 at 05:28:37PM +0100, Pascal wrote:
This is an old fortran 77 / wxGTK software. It's barely alive and many people need it including me :) http://www.xtl.ox.ac.uk/crystals.html
Does the Windows verison work under wine? (I'm half-serious.)
If it's really important, are you sure resources can't be found somewhere to update the software?
Le Sat, 19 Apr 2008 21:59:15 -0400, Matthew Miller mattdm@mattdm.org a écrit :
On Sat, Apr 19, 2008 at 05:28:37PM +0100, Pascal wrote:
This is an old fortran 77 / wxGTK software. It's barely alive and many people need it including me :) http://www.xtl.ox.ac.uk/crystals.html
Does the Windows verison work under wine? (I'm half-serious.)
Yes, it's what I did at the begining.
If it's really important, are you sure resources can't be found somewhere to update the software?
chemistry updates get the priority. It's a huge work to port it to wxGTK 2.8. Anyway I still have the dependency on g77.
Resources are used for the cctbx toolbox, but it's just a "library" for now. I need to package this one as well.
Pascal
On Sun, Apr 20, 2008 at 10:07:17AM +0100, Pascal wrote:
chemistry updates get the priority. It's a huge work to port it to wxGTK 2.8. Anyway I still have the dependency on g77.
g77 is still in fedora. I have one package I rebuild with g77 and gfortran (cernlib). Though lately, gfortran has been much better with regard with g77 compatibility.
-- Pat
On Sat, Apr 19, 2008 at 01:12:58PM +0200, Patrice Dumas wrote:
I have a software (not free) which depends on compat-wxGTK-2.4.2. Apparently the rpm has been set obsolete. Do you want to keep it that way ?
The latest 2.4 release dates back from 2003-09-21. So it is not very
And, I'm building the current wxGTK with "--enable-compat24". The application must require wxGTK 2.4's compatibility with a *previous* version, not merely 2.4 itself.
On Sat, 19 Apr 2008 21:58:08 -0400, Matthew Miller wrote:
On Sat, Apr 19, 2008 at 01:12:58PM +0200, Patrice Dumas wrote:
I have a software (not free) which depends on compat-wxGTK-2.4.2. Apparently the rpm has been set obsolete. Do you want to keep it that way ?
The latest 2.4 release dates back from 2003-09-21. So it is not very
And, I'm building the current wxGTK with "--enable-compat24". The application must require wxGTK 2.4's compatibility with a *previous* version, not merely 2.4 itself.
wxGTK source-level (API-) compatibility doesn't give you ultimate ABI compatibility.
On Sun, Apr 20, 2008 at 09:48:10AM +0200, Michael Schwendt wrote:
wxGTK source-level (API-) compatibility doesn't give you ultimate ABI compatibility.
But in that case the proprietary app could be rebuilt against the new ABI, if it is API compatible, so it is much less problematic than if it was api incompatible. I mean, rebuilding the application is certainly much less resource consuming than packaging old libraries, in fedora or embedded in the rpm.
-- Pat
Le Sun, 20 Apr 2008 10:13:05 +0200, Patrice Dumas pertusus@free.fr a écrit :
On Sun, Apr 20, 2008 at 09:48:10AM +0200, Michael Schwendt wrote:
wxGTK source-level (API-) compatibility doesn't give you ultimate ABI compatibility.
But in that case the proprietary app could be rebuilt against the new ABI, if it is API compatible, so it is much less problematic than if it was api incompatible. I mean, rebuilding the application is certainly much less resource consuming than packaging old libraries, in fedora or embedded in the rpm.
I tried with the enable-compat whitout any success and I havn't got the knowledge to see what's wrong. I don't know if the API is compatible.
Pascal
On Sun, 20 Apr 2008 10:13:05 +0200, Patrice Dumas wrote:
On Sun, Apr 20, 2008 at 09:48:10AM +0200, Michael Schwendt wrote:
wxGTK source-level (API-) compatibility doesn't give you ultimate ABI compatibility.
But in that case the proprietary app could be rebuilt against the new ABI, if it is API compatible, so it is much less problematic than if it was api incompatible. I mean, rebuilding the application is certainly much less resource consuming than packaging old libraries, in fedora or embedded in the rpm.
Sure, it *could* be rebuilt, provided that the developer is not so focused on building for Windows only. Perhaps he just needs some feedback (and support)? It *could* have been rebuilt already a few years ago. We still have compat-wxGTK26, which is source-compatible with 2.4 and even 2.2.
Le Sun, 20 Apr 2008 11:09:53 +0200, Michael Schwendt mschwendt@gmail.com a écrit :
Sure, it *could* be rebuilt, provided that the developer is not so focused on building for Windows only.
He is a windows developer, the linux developer has left years ago.
Perhaps he just needs some feedback (and support)? It *could* have been rebuilt already a few years ago. We still have compat-wxGTK26, which is source-compatible with 2.4 and even 2.2.
Is there any documentation/help somewhere to do such work ? Source compatible ? Do you mean that is should compile whitout changing anything ?
Pascal
On Sun, 20 Apr 2008 10:28:02 +0100, Pascal wrote:
Perhaps he just needs some feedback (and support)? It *could* have been rebuilt already a few years ago. We still have compat-wxGTK26, which is source-compatible with 2.4 and even 2.2.
Is there any documentation/help somewhere to do such work ?
Point the source to /usr/bin/wx-2.6-config instead of /usr/bin/wx-config that is one way, provided that wx-config is used to retrieve the wxGTK setup. Give it a try, see whether the compiler complains.
Source compatible ? Do you mean that is should compile whitout changing anything ?
That's what we do with Audacity, which was developed for wxGTK <= 2.4. The wxGTK 2.6.x series is the last that was also used by upstream developers to build with (if we didn't upgrade to the very latest beta or cvs snapshots which receive fixes for wxGTK 2.8.x). Later versions of wxGTK, e.g. the 2.8 series, changed the feature set and sometimes the run-time behaviour. One cannot be sure that its --enable-compat24 mode leads to full compatibility. And it wouldn't be the first time that application developers used an older API in unintended ways or accessed non-public values/methods which were removed/changed later.