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

[Mattia Rizzolo]

On Thu, Apr 28, 2016 at 11:18:23AM +0200, Emmanuel Promayon wrote:
> > > Lintian still gives two types of warnings (repeated multiple times):
> > > 1) libcamitk4-data: package-contains-timestamped-gzip
> 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).

oh.
I'm sorry, I clearly did not do my homework that well here...

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

lintian's code related to this tag is in the block starting at line 1521
of files.pm (lintian structure is pretty simple: the check name is in
the long description of the tag, and that is in the checks/ directory,
so package-contains-timestamped-gzip has 'Check: files', so the the code
is in checks/files.pm, then you grep for the tag name).
https://sources.debian.net/src/lintian/2.5.44/checks/files.pm/#L1521

            if ($fname =~ m/\.gz$/) {
        [...   more code here   ...]
                            # see https://bugs.debian.org/762105
                            my $diff= $file->timestamp - $changelog_timestamp;
                            if ($diff > 0) {
                                tag 'package-contains-timestamped-gzip',$file;
                            }

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

This is still so weird.
I'd probably file a bug to lintian to have the lintian maintainers look
at that.

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

I see.  Bloody mips always causing boring problems.

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

It sure is possible, after all d/rules is just a makefile.
You just do something like the following (if you want to exclude more
archs just use ifeq with findstring).

I think here you want to check for the build architecture (the arch the
package is built *on*) and not the host architecture (the arch the
package is built *for*) (this can differ if you do a cross compiling).
Most of the checks involving varying build flags between archs is done
checking for the host architecture, but here you just change how you are
going to compile it.  I'm no cross build expert, so I can't really say
something definitive, but I'm positive.
See dpkg-architecture(1) for more info.

DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
ifeq ($(DEB_BUILD_ARCH),mips)
P := --no-parallel
else
P := --parallel
fi

%:
	dh $@ $P

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

well, it did, actually, but only in d/control :)
wrap-and-sort(1) works on a bit more files, but does a lot less checks
and output slightly different styled files.

-- 
regards,
                        Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540      .''`.
more about me:  https://mapreri.org                             : :'  :
Launchpad user: https://launchpad.net/~mapreri                  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20160428/1d30dd96/attachment.sig>