[Debian-med-packaging] Bug#798167: camitk and vtk/itk transitions

Thu Apr 28 09:18:23 UTC 2016

On 27/04/16 02:03, Mattia Rizzolo wrote:
>> From there I am not quite sure how to ask for an upload using the
>> "experimental" branch (or should experimental be first merged to master?)
>
> Not sure what Gianfranco already told you, but the "experimental" branch
> was created mainly to allow the maintainers (=> you) to check it out
> before putting it to master.
> And let me say, that you shouldn't really be afraid to commit stuff to
> the git repository!  It's just a git repository, after all: very easy to
> revert or discard even.

Understood. It is just that in the private (well inferred!) follow-up 
with Gianfranco (which was very useful to me), I send an email to ask 
him if he was ok with the idea of me commiting directly to the origin 
experimental branch. Once I realized that he would most certainly not 
object, it was too late: I had asked him, and felt bound to my question.
I will not hesitate next time.

>> Lintian still gives two types of warnings (repeated multiple times):
>> 1) libcamitk4-data: package-contains-timestamped-gzip
>> For these ones, I think the best is to redo the gzip upstream (and therefore
>> wait for the next upstream to clean this)
>
> This is weird.  That warning is produced only for tarballs with a gzip
> timestamp that is after the date in d/changelog: that means that the .gz
> is created at build time.
> I couldn't find any gzip(1) call in all the sources of camitk, but:
>
> mattia at chase ~/devel/TEAM/camitk/camitk (git)-[master] % rgrep --exclude-dir=.git 'tar '
> sdk/cmake/ctest/nightly.cmake:    # %APPDATA%\MySoft\Star Runner.ini
> sdk/cmake/ctest/nightly.cmake:    # $HOME/.config/MySoft/Star Runner.ini
> sdk/cmake/modules/macros/camitk/packaging/CamiTKOpenSourcePackaging.cmake:#! To make a source tar ball, just use the custom target camitk_package_sourc
> sdk/cmake/modules/macros/camitk/packaging/CamiTKCEPPackaging.cmake:    COMMAND ${CMAKE_COMMAND} -E tar cvz "${CMAKE_BINARY_DIR}/${CEP_PACKAGE_NAME}"  "${CEP_PACKAGING_DIR}/"
> sdk/cmake/modules/CamiTKConfig.cmake.in:    # %APPDATA%\MySoft\Star Runner.ini
> sdk/cmake/modules/CamiTKConfig.cmake.in:    # $HOME/.config/MySoft/Star Runner.ini
> sdk/libraries/qtpropertybrowser/INSTALL.TXT:	tar xvf some-package.tar
>
> Of those, this one is relevant, I think:
> sdk/cmake/modules/macros/camitk/packaging/CamiTKCEPPackaging.cmake:    COMMAND ${CMAKE_COMMAND} -E tar cvz "${CMAKE_BINARY_DIR}/${CEP_PACKAGE_NAME}"  "${CEP_PACKAGING_DIR}/"
>
> There, iit creates a tar.gz at build time, I think.
> See https://wiki.debian.org/ReproducibleBuilds/TimestampsInGzipHeaders
> for some bits on that.  Basically you need to pass the -n option to
> gzip, which can be done either by setting the GZIP variable, or by
> piping the tar output through gzip, like
>     tar cv blabla_stuff_to_tar_up | gzip -n -f blalba_tarball.tar.gz
>
> the GZIP variable has (sadly) been declared obsolete by upstream, and we
> don't know for how long it'll be around, therefore I suggest to
> implement the piping thing, but YMMV.

This is weird, you are right, because:
1) the affected gzip files are just .gz (not tar.gz) provided in the 
upstream tarball and are not modified at build time. They are just 
copied to share/
2) CamiTKCEPPackaging.cmake is not called during build, so we can rule 
this out.
And in fact this tar command is a cmake function (it is not the tar from 
the command line, although it probably call it in the end).

Running:
file imaging/components/itkimage/testdata/BigEndianCompressed.img.gz
returns:
imaging/components/itkimage/testdata/BigEndianCompressed.img.gz: gzip 
compressed data, last modified: Tue Mar  4 17:11:43 2003, max 
compression, from Unix

So I suppose that as this gzip files were produced back in 2003, they 
are time stamped, which probably
I did not found the code exected by lintian to produce this warning, 
which could have confirmed this.

I ran:
gzip -9n imaging/components/itkimage/testdata/BigEndianCompressed.img
and then
file imaging/components/itkimage/testdata/BigEndianCompressed.img.gz
returns:
imaging/components/itkimage/testdata/BigEndianCompressed.img.gz: gzip 
compressed data, max compression, from Unix

(with no time stamp)

Then, after temporarily adding the file in source/include-binaries, the 
package build correctly and the error disappeared.

The gzip will be cleaned in the next upstream version, so the lintian 
warning should disappear.

>> 2) debug-file-with-no-debug-symbols for all *-dbgsym package
>> For this one, I am a bit puzzled. I am not sure at all what causes this
>> error. Is it because the package is build using the "--builddirectory"
>> option:
>> dh $@ --builddirectory=camitk-build
>> and all the .debug files end up in another (non default) directory?
>
> no, it's not that.  It's usually because one builds with -g or something
> like that.  I'm sorry I can't give more directions on this right now.

Ok, I will try to find information about this (any hint welcome).

> And you also have a bunch of informational tags (mostly related to
> hardening not being enabled, and a lot of spelling errors) and pedantic
> tags (no-upstream-changelog is actually the only one i can see).

Yes. Spelling errors will be fixed upstream. I will try to remove the 
hardening error (at one stage of this package there was some overrides 
for previous hardening).

>> Note: I tried to use dh $@ with the --parallel option in d/r, but gbp
>> buildpackage seemed oblivious to it.
>
> what do you mean with this?  To actually perform a parallel build you
> need to set 'parallel=n', with n maximum number of parallel jobs inside
> the DEB_BUILD_OPTIONS env variable.

Ok, sorry about that, I completely forgot that --parallel option would 
work only if DEB_BUILD_OPTIONS variable was properly set.

> WRT this: I saw your comment about not putting --parallel in the default
> dh invocation; following that comment I explicitly put --no-parallel to
> be forward compatible with compat level 10 (which defaults to
> --parallel), but during the build it doesn't seem to use an exaggerate
> amount of memory, maybe just 3 GB top.  IMHO it can be build parallel
> without any troubles.  What architectures did had issues with this?
> maybe using --max-parallel would be better here instead.

Thanks for the --no-parallel flag.

I removed the --parallel build back in 2013 (commit 
1b06ed6477e778e3aa448f3bf6a45292fa365673) for camitk-3.2.2-1 as there 
was some "out of memory" error on some architectures when compiling itk 
filters. See [1] (with --parallel on mips) and [2] (without the flag).
See also bug #747421 [3]

The best might be to try again now with the --parallel option and see if 
some architecture still fail.
What do you think?
If there are some failure, would it be then possible to add the 
--max-parallel only for these arch?

> I'm uploading it right now.
Thank you!

> I noticed nobody pushed the pristine-tar branch, so I did it.  Also, it
> would have been impossible for me to find out the tarball without
> Gianfranco linking it to me (and checking that indeed the content of the
> git repo is the same).
> Well..

I am new to using git and to using git in the packaging process (and did 
not take the time, considering the urgency, to try to understand all 
about it). Sorry about that.

> I also committed some other bits that there are no way you can be
> against.  I'm all for being nice and tidy on the code/packaging, and I'm
> particularly picky also with trailing whitespaces, so...
> Please pull them (with my *signed* (Gianfranco, at least you!  Please
> sign yours:P) tag) :D

Thanks!
At one stage I did try a "cme fix dpkg-control" as suggested in the 
debian-med policy, but it does not seem to remove trailing spaces.

> Thanks for your cooperation!
Thanks to you again for all help and understanding!

Emmanuel

[1] 
https://buildd.debian.org/status/fetch.php?pkg=camitk&arch=mips&ver=3.2.1-1&stamp=1373432553
[2] 
https://buildd.debian.org/status/fetch.php?pkg=camitk&arch=mips&ver=3.2.2-1&stamp=1374435972
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747421

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