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@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
smime.p7s
Description: S/MIME Cryptographic Signature
