Debian Bug report logs - #462189
wxwindows2.4 is scheduled to be removed

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Barry deFreese <bddebian@comcast.net>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: wxwindows2.4 is scheduled to be removed

Date: Tue, 22 Jan 2008 22:09:00 -0500

Package: ctsim
Version: 4.5.5-1
Severity: serious


Hi,

This is a heads up bug that we are attempting to get wxwindows2.4 
removed from the archive (Hence the serious severity).  I know we have 
spoken in the past you aren't particularly interested in transitioning 
to wx2.6 but hopefully we will get 2.8 or 3.0 in.

Please let me know if I can help in any way.

Thank you,

Barry deFreese

Message #12 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Kevin Rosenberg <kevin@rosenberg.net>

To: 462189@bugs.debian.org

Subject: Preliminary wx2.6 port done -- not working

Date: Mon, 2 Jun 2008 16:20:07 -0600

I've uploaded a preliminary port of ctsim to wx2.6 to
http://files.b9.com/testing/

The port compiles without warnings, but faults during gtk font
initialization code before any of the ctsim code is executed.

If any wx wizards have an idea how to fix this, that'd be great!

-- 
Kevin Rosenberg
kevin@rosenberg.net

Message #17 received at 462189@bugs.debian.org (full text, mbox, reply):

From: "Kevin M. Rosenberg" <kevin@tiger.med-info.com>

To: 462189@bugs.debian.org

Date: Mon, 2 Jun 2008 18:56:40 -0600

tag 462189 help

Message #22 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Charles Plessy <plessy@debian.org>

To: Barry deFreese <bddebian@comcast.net>, 462189@bugs.debian.org, dato@net.com.org.es

Subject: ctsim and wxwidgets2.8

Date: Tue, 22 Jul 2008 00:39:24 +0900

Hello,

Barry deFresse suggested me to help for the porting of ctsim to
wxwidgets 2.8. I am affraid that I do not know enough of C for this, but
nevertheless I have written a short summary of the current situation
that I hope can help to resume the work undertook so far.

Current version of ctsim in Debian is 4.5.5-1. The maintainer is Kevin
M. Rosenberg and he is also upstream. Although it is not documented on
the PTS, he has a git repository with the sources plus the debian
directory at the following adress:

git://git.b9.com/ctsim.git

ctsim is built in Debian against wxwidgets 2.4, and for this reason has
been removed from Lenny:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=462189

Kevin tried to port ctsim to wxwidgets 2.6 and at the beginning of this
month posted some preliminary work in an independant tarball:

http://files.b9.com/testing/ctsim-4.5.5-2+beta.5.0.0.tar.bz2

For git enthousiasts, it is easy to load this into a clone of the
repository I cited above: you have to create an upstream branch first
(`git branch upstream'), and then you can use `git-import-orig
../ctsim-4.5.5-2+beta.5.0.0.tar.bz2 -u 4.5.5+beta.5.0.0'
(`git-import-orig' is part of the package `git-buildpackage')

According to Kevin in his reply to the bug report, the package compiles on 2.6
but segfaults. I compiled the package locally and confirm the problem.

Here is the tail of the strace:

writev(3, [{"2\0\0\22\0\1\0=-monotype-arial-medium-r"..., 72}], 1) = 72
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1=\0R\0\0\0_\377\377\0\0\0\3\377\376\377\363\v\270\1\2"..., 4096) = 472
read(3, 0x101b8fa4, 4096)               = -1 EAGAIN (Resource temporarily unavailable)
read(3, 0x101b8fa4, 4096)               = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"2\0\0\22\0\1\0=-monotype-arial-medium-r"..., 72}], 1) = 72
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1=\0S\0\0\0_\377\377\0\0\0\3\377\376\377\363\v\270\1\2"..., 4096) = 472
read(3, 0x101b8fa4, 4096)               = -1 EAGAIN (Resource temporarily unavailable)
read(3, 0x101b8fa4, 4096)               = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [3], NULL, NULL)         = 1 (out [3])
writev(3, [{"2\0\0\22\0\1\0>-monotype-arial-medium-r"..., 72}], 1) = 72
select(4, [3], [], NULL, NULL)          = 1 (in [3])
read(3, "\1>\0T\0\0\0_\377\365\0\0\0\0\0\21\0\5\0\0\1\2\0\0\0\6"..., 4096) = 472
read(3, 0x101b8fa4, 4096)               = -1 EAGAIN (Resource temporarily unavailable)
read(3, 0x101b8fa4, 4096)               = -1 EAGAIN (Resource temporarily unavailable)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

I am too uncomfortable with the autotools to convert the package to wx2.8, but
I can try if somebody sends me instructions. Or maybe one of you noticed
something obvious in the strace ?

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan

Message #27 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Kevin Rosenberg <kevin@rosenberg.net>

To: Charles Plessy <plessy@debian.org>, 462189@bugs.debian.org

Cc: Barry deFreese <bddebian@comcast.net>, dato@net.com.org.es

Subject: Re: Bug#462189: ctsim and wxwidgets2.8

Date: Mon, 21 Jul 2008 09:58:44 -0600

Charles Plessy wrote:
> Barry deFresse suggested me to help for the porting of ctsim to
> wxwidgets 2.8. I am affraid that I do not know enough of C for this, but
> nevertheless I have written a short summary of the current situation
> that I hope can help to resume the work undertook so far.

Thanks for the summary, Charles. It is accurate. I can modify the
autotools to use wx2.8. Are there known problems with wx2.6 where
modifying ctsim to use wx2.8 will really solve any problems?

Kevin

Message #30 received at 462189-submitter@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@ubuntu.com>

To: 462189-submitter@bugs.debian.org

Subject: wxwindows2.4 is scheduled to be removed

Date: Thu, 27 Nov 2008 19:51:08 +0100

Hi,

Has there been any progress on this, now that wxwidgets2.8 is in unstable?

Cheers,
Emilio

Message #35 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Moritz Muehlenhoff <jmm@inutil.org>

To: Kevin Rosenberg <kevin@rosenberg.net>

Cc: Charles Plessy <plessy@debian.org>, 462189@bugs.debian.org, Barry deFreese <bddebian@comcast.net>, dato@net.com.org.es

Subject: Re: Bug#462189: ctsim and wxwidgets2.8

Date: Sun, 15 Mar 2009 14:59:59 +0100

On Mon, Jul 21, 2008 at 09:58:44AM -0600, Kevin Rosenberg wrote:
> Charles Plessy wrote:
> > Barry deFresse suggested me to help for the porting of ctsim to
> > wxwidgets 2.8. I am affraid that I do not know enough of C for this, but
> > nevertheless I have written a short summary of the current situation
> > that I hope can help to resume the work undertook so far.
> 
> Thanks for the summary, Charles. It is accurate. I can modify the
> autotools to use wx2.8. Are there known problems with wx2.6 where
> modifying ctsim to use wx2.8 will really solve any problems?

What's the status of the port of ctsim to a more recent wxwindows?

GTK 1.2 is scheduled for removal (and wx2.4 along with it)

Cheers,
        Moritz

Message #40 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tillea@rki.de>

To: Debian Med Project List <debian-med@lists.debian.org>

Cc: Kevin Rosenberg <kevin@rosenberg.net>, 462189@bugs.debian.org, Moritz Muehlenhoff <jmm@inutil.org>

Subject: Re: wxwindows2.4 is scheduled to be removed

Date: Tue, 21 Apr 2009 00:42:39 +0200 (CEST)

On Sun, 15 Mar 2009, Moritz Muehlenhoff wrote:

> What's the status of the port of ctsim to a more recent wxwindows?
> 
> GTK 1.2 is scheduled for removal (and wx2.4 along with it)

Kevin, IMHO it would be a good idea if you would keep the Debian Med
list informed about the current state of ctsim.  The package is in
danger to be removed, has some easy to fix wishlist bugs with patches,
contains outdated (Standards-Version) and incomplete information
in debian/control (Homepage, Vcs is missing).  You did not answered
my question [1] whether you agree to group maintenance.  If you would
I might try to upgrade the package to current policy and fix the
bugs with patches.  While doing so I might give recent wx stuff a
try.  Just give us an update please.

Kind regards

      Andreas.


[1] http://lists.debian.org/debian-med/2008/03/msg00085.html

-- 
http://fam-tille.de

Message #45 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Kevin Rosenberg <kevin@rosenberg.net>

To: Andreas Tille <tillea@rki.de>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 462189@bugs.debian.org, Moritz Muehlenhoff <jmm@inutil.org>

Subject: Re: wxwindows2.4 is scheduled to be removed

Date: Wed, 22 Apr 2009 15:03:18 -0600

The current status of CTSim is:

1) It's stored in a local git repository. I've made local git branches  
for porting to wx2.6 and wx2.8
with the main changes being conversions of all strings to Unicode. The  
source compiles
without warnings, but segfaults during GTK font initialization. I've  
worked a bit with the wx
maintainer so took a look at the error, but no solution has been  
found. 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.

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. 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.

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. 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.
I prefer the latter, but, as above, I'm agreeable to the former.

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.

Thanks for your interest, Andreas,

Kevin

On Apr 20, 2009, at 4:42 PM, Andreas Tille wrote:

> On Sun, 15 Mar 2009, Moritz Muehlenhoff wrote:
>
>> What's the status of the port of ctsim to a more recent wxwindows?
>> GTK 1.2 is scheduled for removal (and wx2.4 along with it)
>
> Kevin, IMHO it would be a good idea if you would keep the Debian Med
> list informed about the current state of ctsim.  The package is in
> danger to be removed, has some easy to fix wishlist bugs with patches,
> contains outdated (Standards-Version) and incomplete information
> in debian/control (Homepage, Vcs is missing).  You did not answered
> my question [1] whether you agree to group maintenance.  If you would
> I might try to upgrade the package to current policy and fix the
> bugs with patches.  While doing so I might give recent wx stuff a
> try.  Just give us an update please.
>
> Kind regards
>
>      Andreas.
>
>
> [1] http://lists.debian.org/debian-med/2008/03/msg00085.html
>
> -- 
> http://fam-tille.de
>

Message #50 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tillea@rki.de>

To: Kevin Rosenberg <kevin@rosenberg.net>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 462189@bugs.debian.org, Moritz Muehlenhoff <jmm@inutil.org>

Subject: Re: wxwindows2.4 is scheduled to be removed

Date: Thu, 23 Apr 2009 08:53:59 +0200 (CEST)

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

Message #55 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Kevin Rosenberg <kevin@rosenberg.net>

To: Andreas Tille <tillea@rki.de>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 462189@bugs.debian.org, Moritz Muehlenhoff <jmm@inutil.org>

Subject: Re: wxwindows2.4 is scheduled to be removed

Date: Sun, 26 Apr 2009 16:46:21 -0600

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

Message #60 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Andreas Tille <tillea@rki.de>

To: Kevin Rosenberg <kevin@rosenberg.net>

Cc: Debian Med Project List <debian-med@lists.debian.org>, 462189@bugs.debian.org, Moritz Muehlenhoff <jmm@inutil.org>

Subject: Re: wxwindows2.4 is scheduled to be removed

Date: Mon, 27 Apr 2009 07:58:33 +0200 (CEST)

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

Message #65 received at 462189-close@bugs.debian.org (full text, mbox, reply):

From: kmr@debian.org (Kevin M. Rosenberg)

To: 462189-close@bugs.debian.org

Subject: Bug#462189: fixed in ctsim 5.0.0-1

Date: Sat, 01 Aug 2009 19:02:04 +0000

Source: ctsim
Source-Version: 5.0.0-1

We believe that the bug you reported is fixed in the latest version of
ctsim, which is due to be installed in the Debian FTP archive:

ctsim-doc_5.0.0-1_all.deb
  to pool/main/c/ctsim/ctsim-doc_5.0.0-1_all.deb
ctsim-help_5.0.0-1_all.deb
  to pool/main/c/ctsim/ctsim-help_5.0.0-1_all.deb
ctsim_5.0.0-1.diff.gz
  to pool/main/c/ctsim/ctsim_5.0.0-1.diff.gz
ctsim_5.0.0-1.dsc
  to pool/main/c/ctsim/ctsim_5.0.0-1.dsc
ctsim_5.0.0-1_amd64.deb
  to pool/main/c/ctsim/ctsim_5.0.0-1_amd64.deb
ctsim_5.0.0.orig.tar.gz
  to pool/main/c/ctsim/ctsim_5.0.0.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 462189@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Kevin M. Rosenberg <kmr@debian.org> (supplier of updated ctsim package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Sat, 01 Aug 2009 10:56:41 -0600
Source: ctsim
Binary: ctsim ctsim-help ctsim-doc
Architecture: source all amd64
Version: 5.0.0-1
Distribution: unstable
Urgency: low
Maintainer: Kevin M. Rosenberg <kmr@debian.org>
Changed-By: Kevin M. Rosenberg <kmr@debian.org>
Description: 
 ctsim      - Computed tomography simulator
 ctsim-doc  - Documentation for ctsim package
 ctsim-help - Online help file for CTSim
Closes: 462189
Changes: 
 ctsim (5.0.0-1) unstable; urgency=low
 .
   * New upstream, ported to wxwidgets 2.8 (closes:462189)
Checksums-Sha1: 
 fe174b3cd0c41dd082060dc780afd35304e72f90 1177 ctsim_5.0.0-1.dsc
 63e5d2ff060bd0774ba1b0cb7bc9c9f85e32c497 2336415 ctsim_5.0.0.orig.tar.gz
 0a3aca6b22d0daac41ffada649236ab61fc9a418 7313 ctsim_5.0.0-1.diff.gz
 1335945236223152f04fb7c42de659b539cc38d8 137106 ctsim-help_5.0.0-1_all.deb
 0dada44c8b61a6ae3aa8c721f09a8b2025464530 346078 ctsim-doc_5.0.0-1_all.deb
 a299f89fc4ec2ae55d00b150ed64b24249430568 647176 ctsim_5.0.0-1_amd64.deb
Checksums-Sha256: 
 f5fd4ddc763caf0389de6c11331b0792780f72719f9b481d4b0ec3d778e4e12c 1177 ctsim_5.0.0-1.dsc
 7b998b011027e139e836ed730767a4717d01174d8d58363324d5f32845d881d5 2336415 ctsim_5.0.0.orig.tar.gz
 603a3bc47240175600dda18d0c5696cb791a1aa35545ac7989e82bfbcab24b1b 7313 ctsim_5.0.0-1.diff.gz
 666e18fe6cd9e31f7bf166fafd60cce1acba0f9689bfad5d830374f5efbc658d 137106 ctsim-help_5.0.0-1_all.deb
 3af8c878b28be2b47e40e5a03589643459ba9287f9fc1ec9b0f351aa795137b9 346078 ctsim-doc_5.0.0-1_all.deb
 6f31e998c036d5a65a3a9567fbd051b05a3f7f864cbcf5cd733c4fe4e17b49a0 647176 ctsim_5.0.0-1_amd64.deb
Files: 
 17a78bf25e58bd53522c7c0021400c40 1177 science extra ctsim_5.0.0-1.dsc
 cc285f4ecc7b36fe803ae798dd7842ab 2336415 science extra ctsim_5.0.0.orig.tar.gz
 2ebd5c97154b2da17f2dfb5c308d789e 7313 science extra ctsim_5.0.0-1.diff.gz
 f17af5c4d546d324ca0070f9a91e1978 137106 science extra ctsim-help_5.0.0-1_all.deb
 61b8c7c12e099242f0fa5ed6aaa3c0ec 346078 doc extra ctsim-doc_5.0.0-1_all.deb
 8f1b27c258f0ecd86b0671fdc188a3ba 647176 science extra ctsim_5.0.0-1_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkp0jrIACgkQES7N8sSjgj5ieACfUzjjbLM8EwlWNvMBzuty+m9C
4s4An26RAJ5WewXzChwThLUlzgvhCieD
=kmWO
-----END PGP SIGNATURE-----

Message #70 received at 462189@bugs.debian.org (full text, mbox, reply):

From: Kevin Rosenberg <kevin@rosenberg.net>

To: 462189@bugs.debian.org

Subject: The Fix

Date: Sat, 1 Aug 2009 13:51:48 -0600

The problem of the segv on startup was due to ctsim being linked  
against the older libgtk1.2 package. Updating to libgtk2.0
fixed the problem and a new version of ctsim has been uploaded.

Send a report that this bug log contains spam.