Re: wxwindows2.4 is scheduled to be removed
On Apr 23, 2009, at 12:53 AM, Andreas Tille wrote:
I wonder whether it might be a good idea to spend all effort on wx2.8
exclusively given the fact that wx2.6 is outdated as well.
That might be reasonable. They're are many changes between wx2.6 and
wx2.8 in
terms of eliminating compiler errors. However, as far as dealing with
runtime differences,
it'll likely be easier to get it working on wx2.6 first.
While I havn't any experience with wx and my GTK experience is only
from very outdated GTK 1.2 I think it is a good strategy to track down
problems like this to make a copy of your program and remove part by
part so long as the error occures. Try to get the smallest piece of
code which showas the problem - which should not be that much
considering the fact that you said it is at font initialisation
which should be quite at the beginning. When doing so in most cases
I have seen the problem myself and in the remaining cases this small
testcase is an easy target for helpers hanging around on relevant
mailing lists
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. 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.
Any logs / extract of this discussion to not waste time on reproducing
just the same? I'd suggest to CC Debian Med mailing list for such
discussions - the list is not that much crowded that it can not bear
some extra technical discussion.
I'm fairly sure that I no longer have a record of those messages with
Barry, but I will check.
Which tool did you use? valgrind?
Yes.
2) I had the minor changes for Homepage, Vcs, Standards-Version --
but haven't uploaded them since the main issue is that I've not
been able
to successfully port to wx2.6 or 2.8.
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.
As I said above if I where you I would try to force 2.8 to become main
branch to make sure not to lag behind up to date libraries. The
burden
to maintain 3 branches in parallel using outdated libraries for two of
them does not sound like a good strategy from an outsiders point of
view.
My guess is that you have to keep a working installation running for
your local uses and so you are bound to the old wx2.4 based version -
but if I were you I would put all effort into the wx2.8 based version.
That would certainly simplify the git repository branch issues, though
it'd leave
code that doesn't work as the head of the master branch. But, I can
tag the wx2.4
working code so that someone could go back to that tag for working code.
Well, there are different steps inbetween if you are not completely
happy
with the way we agreed upon working together in the Debian Med team.
Given the fact that it is generally a good idea to let the world know
about the current status of your work - in our case related to Debian
packaging - we invented the Debian Med svn[2]. There is actually no
need
to group maintain the package to use the SVN - single maintainers are
welcome as well even it has turned out to be easier to apply such kind
of changes like Homepage and Policy. We might be perfectly able to
take
this "burden" from you - I admit it is not much of a burden but Free
Software more or less works that way that those people do the job who
are at most interested to get it done. So group maintenance would
have
ensured that CTSim would look better on the tasks pages even now
without draining any time of yours. It is your choice whether you
think this is important for you or not.
I'm not familiar with the policies of the Debian Med Team (I know, I
know, as
an M.D. I should be). I'll read the link that you provided for the
Debian-Med
Group Policy.
I admit your situation being upstream and Debian maintainer in one
person is a bit specific and makes your view on group maintenance a
bit different. It's finally your choice.
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
What do you think about the following to enhance your workflow (as
upstream
*and* Debian developer): Considering you are maintain CTSim in a Git
repository anyway and given the fact that you are upstream and Debian
maintainer in one person the Debian Med policy for group maintenance
[2]
just does not make much sense for you. There is no reason to maintain
any patches for your upstream code using a patch system - you'd rather
release a new upstream version. Also committing just the Debian
directory
to our SVN might not be the most clever solution - even if it might
make
a point because you should not deliver the debian directory inside
your
upstream tarball. So you might consider splitting the technical way
of maintaining the debian directory into a different repository. But
I doubt you will like this idea (but see below).
My local build scripts build both the debian packages as well as the
upstream tarballs
without the Debian directory.
The Debian Science team (and IMHO CTSim would fit into the science
scope as well) does offer the option to either use Git or SVN to
maintain packages. The Git adictives explained that it conflicts to
the Git philosophy to only maintain the debian directory + patches
in the repository. They are maintaining a copy of the source tarball
in the Git repository using pristine-tar enable obtaining the original
upstream code. Just have a look into Debian Science policy[3]. It
is not my personal way of thinking - but hey it is Free Software.
I'll take a look at the Debian Science Polcy.
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.
So why not using the Debian Science Git repository to maintain CTSim?
This would enable commiting patches for people in the Debian Science
team (and several people of Debian Med are in this team as well).
This
would be a technical approach to group maintenance which should fit
the best into your workflow.
That'd be fine if I got some real help dealing with the underlying
problem: the reliance
on wx2.4.
Upstream part:
Just try to strip down your code as much as possible leaving a
small chunk of code featuring the problem. Raise this issue in
relevant mailing lists and keep Debian Med in CC.
I think as I strip down the code, I will find the problem and it will be
self-evident. I just don't have time to do so atm.
Debian part:
Consider using Debian Science Git repository to maintain your
package and follow the advises of Debian Science policy[3].
I'll check out the policy.
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.
Again, thanks for your time and thoughts, Andreas.
Kevin
Reply to: