Re: wxwindows2.4 is scheduled to be removed
On Sun, 26 Apr 2009, Kevin Rosenberg wrote:
Yes, that's a reasonable plan. I eliminated all my initialization code, but
the segv still occurs on startup. The next step would be to start removing
other,
non-initializing code and declarations.
Could you push this to a publicly avialable repository to?
However, at this time I don't have
time to work on further efforts to port to a new version of wx. For my own
needs,
I can use CTSim on wx2.4, even if the package does not stay in Debian.
I can perfectly this works-for-me-no-time-for-more-effort attitude but
there are chances at some point in time you are forced to change even in
yourprivate environment. I learned that such changes sometimes might
even come with more time preasure than expected. So it is a good investment
into the future to keep track with up to date libs.
Considering the fact that new users are approaching from the distributors
side and look at the large image before they dive into specific packages
it would serve our users better if we would care better for things like
this and so from a users perspective an updated package (even if it is
rather cosmetics than technical progress) might make sense.
Okay, it'd be no trouble to upload a package for wx2.4 that updates those
minor, Debian specific metadata.
That's nice.
If the benefits of group maintenance outweighs the cost of segmenting my
open-source
packages from my own code server to an outside server, then I'm in favor of
it. As for what
would make the switch worthwhile, from my perspective, if a volunteer to work
on the wx2.8
port
I can not promise anything but as I said the strip down to bare minimum
strategy and than ask for help might be reasonable. IMHO a branch like
svn://svn.debian.org/svn/debian-med/trunk/packages/ctsim/branch
might be used (and dropped once the problem might be solved). This gives
Debian Med people easy access.
Regarding pristine-tar I'd like to come back to my arguing above:
If you consider my suggestion interesting please make sure that the
debian directory will not be include into pristine tarball.
As I mentioned, my build scripts clean the git repository (which has debian/
integrated
in the directory structure), so the upstream tarballs are without any
Debian-specific files.
That's fine.
That'd be fine if I got some real help dealing with the underlying problem:
the reliance
on wx2.4.
There is no guarantee - but chances are better if you push the problem to
more helpers.
As for the package, I'll fix and upload the minor issues, then tag the
repository as wx2.4. Then
copy over the wx2.8 port code in the repository in case someone wants to try
cracking the problem.
Just keep us informed if there is something to test.
Again, thanks for your time and thoughts, Andreas.
You are welcome
Andreas.
--
http://fam-tille.de
Reply to: