[Debian-med-packaging] packaging for camitk 3.3.1 ready

[Emmanuel Promayon]

Hello Andreas,

> Good.  THe package now builds without lintian errors and I could
> upload (after reaching to some better network connection than I
> currently have).
Great!

>> I do not dare to say "packaging for 3.3.2 is ready for upload"
>> anymore! So I will just say "would you please consider the
>> sponsoring of CamiTK 3.3.2 packaging if you think everything is
>> ok?"
>
> I'm a bit curious what the following lintian message:
>
> I: camitk source: tar-errors-from-source Ignoring unknown extended
> header keyword 'SCHILY.fflags' N: N:    tar produced an error while
> unpacking this source package. This probably N:    means there's
> something broken or at least strange about the way the N:    upstream
> tar file was constructed. You may want to report this as an N:
> upstream bug. N: N:    Severity: normal, Certainty: wild-guess N: N:
> Check: cruft, Type: source
 > might mean.

It might come from the way I recompress 3.3.1 after removing the file 
without sources (I used a GUI tool). I checked the web for this before 
commiting, but did not find a very clear answer about it.
This should not be the case for the next "normal" release.

> I also think that you somehow missed the chance to fix several
> spelling errors claimed by lintian:
>
> I: libcamitk3: spelling-error-in-binary
> ...
> I'd recommend fixing these in upstream VCS to make sure the next
> release will be cleaned from this.

The 3.3.2 version of the tarball is just a 3.3.1 version without the 
incriminated files (because upstream had moved too much between). This 
is why the spelling errors are not fixed in 3.3.2
But they will be fixed in the next release, I already commited the 
spelling errors in the upstream trunk when they first appeared in 
lintian (back in the time where I was trying to package 3.3.0!) [1].

> Finally I'm wondering whether this could be fixed as well:
>
> I: libcamitk3-data: duplicated-compressed-file
> usr/share/camitk-3.3/testdata/BigEndianCompressed.img.gz N: N:    The
> given, apparently compressed, file is shipped in the package in N:
> addition to another file with the same name without the N:
> compression-method extension. Normally this indicates a mistake in
> the N:    installation process of the package. N: N:    Severity:
> minor, Certainty: possible N: N:    Check: files, Type: binary, udeb

BigEndianCompressed.img and BigEndianCompressed.img.gz are parts of the 
test data for the itkimage component. This plugin can open images in 
CamiTK using ITK ImageIO factory. This CamiTK plugins supports the 
following image file formats: hdr, spr, gipl, pic, lsm, nrrd, nii, img, 
as well as their compressed forms: hdr.gz, nii.gz, and img.gz.
We therefore included both BigEndianCompressed.img and 
BigEndianCompressed.img.gz for test reason.

Do you think it will be a good idea to rename the 
BigEndianCompressed.img to something like BigEndianCompressed-ori.img in 
order to "artificially" suppress the warning?
Or is it better to leave the warning so that people are aware the two 
files provide the same data?
Or maybe adding a lintian override is the best?


> So nothing to really bother about for the current upload but lintian
> has some intersting hints for you as upstream. :-)

Just FYI: after the struggle we had with the packaging of this release, 
we (upstream) decided to change the way we tests the code before 
release. We are very pleased about the fact that the debian packaging 
strengthen the quality of CamiTK (and not only on the spelling error 
front, there was a lot of potential problems that were detected during 
the preparation of the package).
Therefore, we are now going to prepare all the packaging work before the 
release of the source (using a sid VM and compile using the debian rules 
for instance). If we had done that for this release, there would have 
been no patches and no spelling errors, no swf file without sources etc...
Beside improving the unit tests (and make them all relevants), we are 
going to try also to implement the autopkgtest in cmake and add more 
post-installation tests (implementing them in cmake means they can be 
used independently from adt and on other plateforms as well).

> Thanks for your work on this
Thanks to you!

Best regards,
Mahnu

[1] 
http://lists.forge.imag.fr/pipermail/camitk-commits/2014-April/001381.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2947 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20140507/6ea2431f/attachment.bin>