Re: Any software package for Radiation Oncology Contouring?
On Sat, Mar 19, 2011 at 01:19:15PM -0500, Adit Panchal wrote:
> > http://people.debian.org/~tille/packages/dicompyler/
>
> Looks ok to me, but I didn't get a chance to test it as there is a
> show-stopper bug that if running with pydicom 0.9.4-1, the application
> cannot open DICOM files.
Ahh, OK. You always kann install python-dicom from experimental - I
just wanted to spare this dependency for the purpose of packaging
without relying on experimental. I just kept NeuroDebian team in CC to
let them comment on the python-dicom situation and whether we might
expect an upload of >= 0.9.5 to unstable soon(ish).
> I fixed the source to support pydicom 0.9.4-1. Features-wise nothing
> changes, but there are bugs in that version that have been fixed in
> 0.9.5 to allow better compatibility with more types of DICOM files.
Ahh - this was a missunderstanding. I do not really waste your time to
backport dicompyler to a broken python-dicom. I just wanted to verify
that packaging itself works. Once we have the proper version in
unstable everything will be fine and your should be able to use the
version from experimental for testing the package.
> The prior revision was specifically looking for a feature in 0.9.5 and
> would not allow the user to open any DICOM files if they are running
> 0.9.4-1. The change that has been made will allow the user to have
> 0.9.4-1 installed and still use dicompyler.
That's a quite nice habit to be so quickly for support - but as I tried
to line out it is probably not urgently needed and I'm sorry that my
mail triggered you to do some work which can probably soonish be
dropped.
> Thus again, I have uploaded a new tarball (same file name) with the
> latest source.
So I wonder whether it makes sense to reward your fine work with a new
test package or whether it makes more sense to wait for an answer of the
python-dicom packagers. Considering that we will probable not go for
uploading a dicompyler alpha version but rather try to move a more
stabelised version (according to your decision what you would call
stabelised) I think it is not worth the effort. I'd rather would do the
resume: Packaging dicompyler seems not to be a challenge at all and the
problem is solved. If you as upstream would consider it in some kind of
release candidate state just ping the list again. We will than go for
an upload into Debian new queue. Passing new seems to take 1-2 monthes
of time anyway. Once this is done we can soonish push your latest
version to unstable.
> > BTW, you said this tarball does not contain testcases / examples etc.
> > In the final tarball it would make perfectly sense to provide the user
> > with some test cases as examples which sometimes is a good addition to
> > the docs.
>
> We do have a zip file of test data available on the project website,
> however it is 24 MB zipped. The data in the repository was quite
> limited, so it was confusing to users to have both. Additionally, the
> binary distributions don't come with data as it makes the download
> quite large, so it made sense to have a separate zip file of test data
> for the user to download if they so choose.
>
> If there is any way to add that zipfile as a separate sub-package, we
> could go down that route.
While this is definitely possible in principle we should decide how
important these are for the user. If a proper description what exactly
to do to fetch and run the examples can be provided it makes probably
sense to just add this as documentation and be done.
> Also we do not have test cases at the moment, but they are in the
> pipeline to be written. At that time we may consider adding back
> specific DICOM files for each test.
Just keep me informed if this is ready.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: