[Debian-med-packaging] updating camitk package

[Mattia Rizzolo]

On Sat, Oct 01, 2016 at 12:12:39PM +0200, Emmanuel Promayon wrote:
> > On Fri, Sep 30, 2016 at 11:27:04PM +0200, Emmanuel Promayon wrote:
> > > I am not sure I did the right thing for the tags (please let me know).
> > 
> > looks so, yes.  Though you didn't push the upstream branch, nor
> > pristine-tar, please push those too.
> 
> I just pushed the upstream branch, but I don't have any pristine-tar
> locally. How can I fix this?

pristine-tar is a branch that is updated by the pristine-tar(1) tool,
which is packaged in a package named pristine-tar, so no so many chances
to confuse :)

gbp makes use of pristine-tar in a pretty seamless way, though for some
odd reason it's not enabled by default.  I suggest you edit/add your
~/.gbp.conf and add
    pristine-tar = True
in an approrpriate section, the DEFAULT section is cool for it usually.
So if you don't have that file at all, just create it and write:
    [DEFAULT]
    pristine-tar = True
Then any other `gbp import-orig` (and some other commands) will take
care of updating that branch.  Also (if you use it, I don't) the
`gbp buildpackage` command will use the data extracted from there to
recreate the tarball if not present in the parent directory.


Now, given that you didn't have the option turned on on import time, you
need to manually import the pristine-tar data, which you can do with
    pristine-tar commit <path to tarball> [<tree-ish>]
where "path to the tarball" is the path to the tarball, and "tree-ish"¹
is a git object identifier identifying a tree that has to match as
closely as possible to the tarball you're committing; in your case this
will be "upstream/4.0.2" for the 4.0.2 tarball, and "upstream/4.0.3" for
the 4.0.3 one.
So, summing up you will probably have to run:
    pristine-tar commit ../camitk_4.0.2.orig.tar.gz upstream/4.0.2
    pristine-tar commit ../camitk_4.0.3.orig.tar.gz upstream/4.0.3
(assuming a gzip compression).

¹ https://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git


(ok, I should have probably be less lengthy...)

[ about lintian's debug-file-with-no-debug-symbols ]
> > Those are usually due to the building not using -g, or for the file
> > being stripped before dh_strip can do it (and put the debugging info
> > into the -dbgsym packages).
> 
> I checked the d/r files in vtk6 and insighttoolkit packages, which also use
> CMake and it seems that I am doing similar things. There is no -g flags in
> the three d/r files.
> They also all use a specific build directory (which I first thought was the
> problem with the camitk package).
> 
> I just tried the two following in d/r thing but to no avail:
> - removing -DCMAKE_BUILD_TYPE:STRING=None flag (it is not present in the
> insighttoolkit d/r)
> - adding "export DEB_CFLAGS_MAINT_APPEND  = -g" at the top of d/r
> 
> Do you have any other idea?

No, it really usually is such a thing.  I'll check this up myself soon.

> > lintian overrides are not a solution.  At least, in nearly all cases I
> > came across, overrides were used mostly only as a mean to hide issues.
> 
> I understand. There is one lintian-overrides for libcamitk4, I hope it fall
> in the exception cases...

Yeah, well, I think it's ok for this case.

-- 
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: 801 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-med-packaging/attachments/20161003/c2f62ae5/attachment.sig>