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 `-
signature.asc
Description: PGP signature