Re: wxwindows2.4 is scheduled to be removed
On Wed, 22 Apr 2009, Kevin Rosenberg wrote:
1) It's stored in a local git repository. I've made local git branches
for porting to wx2.6 and wx2.8
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.
with the main changes being conversions of all strings to Unicode. The
source compiles without warnings, but segfaults during GTK font
initialization.
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
I've worked a bit with the wx maintainer so took a look at the
error, but no solution has been found.
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 went as fair as to comment
out all the application-specific code from the wx startup function, but it
still segfaults. I looked for
string overflows, but didn't find any.
Which tool did you use? valgrind?
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.
That's fine. Also there is no real need to upload such kind of cosmetics
if you know that there are more pressing problems in the code. The problem
regarding a missing Homepage tag is that there are different points of
view: From a single package point of view it is a minor problem whether
the homepage information is given in long description or in a separate
field. From a distributors point of view (or from the blends perspective)
information is harvested and used for a larger set of packages and it
makes a more important point to provide a complete set of information
fields. New techniques evolved since the last upload of CTSim for instance
the Debian Med tasks pages and if you look at the CTSim entry[1] it looks
foolisch to say that there is no homepage avialable and mention this page
later in the long description.
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.
Plus, I made those changes to the 2.6 or 2.8 branch and haven't quite
figured out how to apply that patch to the wx2.4 (main) branch.
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.
3) I'd welcome help with the wx port and fixing current bugs. If group
maintenance is the best way to achieve that, then I'm agreeable to that.
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.
Alternately, I can handle all of the sophisticated
mathematics in the program, so perhaps one time help on the wx port would be
all would be necessary.
Well, the Debian maintenance is not so much about your upstream code.
We most probably will leave it untouched (as long as it works). I have
no idea whether we do have wx porting experts in the crew - if you ask
me I just would try. ;-)
I prefer the latter, but, as above, I'm agreeable to the former.
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 it seems helpful, I can tarball my current git development repository and
post it on my web server.
(Since I'm not that familiar with dealing with branches between a development
repository and my
master git repository, I've not pushed the wx2.6 and wx2.8 local branches to
ctsim's master public
repository which is git://git.b9.com/ctsim.git.) If someone could help with
pushing my local porting branches
to a master git repository, that might be best so that everyone submit
patches relative to the master
repository.
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).
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.
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.
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.
Thanks for your interest, Andreas,
Well, that's what I call Debian Med work - just care for *every* part
in the system. To sum up the longish mail:
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.
Debian part:
Consider using Debian Science Git repository to maintain your
package and follow the advises of Debian Science policy[3].
Kind regards
Andreas.
[1] http://debian-med.alioth.debian.org/tasks/imaging#ctsim
[2] http://debian-med.alioth.debian.org/docs/policy.html
[3] http://debian-science.alioth.debian.org/debian-science-policy.html
--
http://fam-tille.de
Reply to: