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

Wed Apr 27 00:03:22 UTC 2016

On Mon, Apr 25, 2016 at 10:05:29PM +0200, Emmanuel Promayon wrote:
> I managed to do some work on polishing the package, and once Gianfranco has
> agree, I will pull everything to the "experimental" branch.

I infer you had a private follow-up with Gianfranco and pushed
everything :)
Thank you!

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

> I used a docker sid image (which might not be the best, but was at hand on
> my machine)... and the packages were build.
> All the 441 post-build tests passed as well. I also updated the autopkgtest
> script, and it should work as well (although I could not run adt-run or
> puiparts in docker)

cool.

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

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

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

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

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.

> >everything started by wanting to remove libpng12.  And then we noticed
> >in how such a bad state unstable was wrt cruft.
> >For some reason or the other, camitk is entangled in *all* of them; we
> >have a pad where we are tracking everything, and camitk is on all the
> >sections :\
> 
> Wooah... No pressure then!
> Your explanation has accelerated the process and put this packaging task on
> top of my urgent task list... Hope this will help remove camitk from the bad
> books...

\o/

> >> Therefore, I hereby declare that what Gianfranco did is great and
> >> blessed! Thanks you very much!
> >> If Gianfranco and everyone else is ok with it (I did not have time to
> >> check the packaging here), it would be great if it can be uploaded
> >> directly in unstable.
> >
> >\o/
> >
> >Great!  One of us will get to it very soon :)
> >(guess Gianfranco, as he did most/all of the work)

I'm uploading it right now.
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 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 for your cooperation!
-- 
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/20160427/eb9b570c/attachment-0001.sig>