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

[Emmanuel Promayon]

On 24/04/16 18:30, Mattia Rizzolo wrote:
> On Sun, Apr 24, 2016 at 05:56:00PM +0200, Emmanuel Promayon wrote:
> > I checked Gianfranco's experimental branch and his work is great!
> > There is few build-depend packages that can be removed (and I noticed
> > the problem with the pixmaps), but this would be my pleasure to fix
> > that very soon.
>
> cool!
> If you could fine some minutes to trimmer the build-deps, etc would be
> awesome.
>

I managed to do some work on polishing the package, and once Gianfranco 
has agree, I will pull everything to the "experimental" branch.

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

Thanks to Gianfranco tip, I used
gbp buildpackage --git-debian-branch=experimental --git-ignore-new

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)

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

Note: I tried to use dh $@ with the --parallel option in d/r, but gbp 
buildpackage seemed oblivious to it.

> > I agree that the display bug, although a priority for upstream,
> > should not delay any debian cleaning up.
>
> 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...

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

OK. I will wait to Gianfranco agreement before I pull my commits to the 
experimental branch (I asked him if he was ok with it).

> > In the next few weeks, hopefully upstream 4.0.1 will solve the display
> > bug and I can polish the packaging.
>
> In the meantime I'll file a RC bug for it, so it'll stay out of testing,
> and all the involved parties can notice this version is partially not
> working.

Great! Thanks.

> > Thanks you again all for your work, it is amazing how every time
> > there is something new to learn!
>
> There is still more ;)
>

:-)


-------------- 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/20160425/3934c00b/attachment-0001.bin>