[Debian-med-packaging] updating camitk package

[Emmanuel Promayon]

Thank you again for your time and your very clear answers.

On 03/10/16 23:46, Mattia Rizzolo wrote:
> 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...)


Thank you! I changed the gbp configuration for future usage and did the 
pristine-tar commits. I do prefer lengthy answers, so do not hesitate in 
the future to do so!

As you probably noticed, I completely messed up the pristine-tar branch 
by doing the commit as root, push them to origin and then unsuccesfully 
tried to amend the user name and email (where I messed up the git 
repository even more).
Hope this will not be a problem in the future.
Sorry about that!
My git experience is very poor...

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

In fact, I just figured out that it might come from the CMake tweaking 
(as all the other packages that were based on CMake did not have this 
error)... and I found the culprit! The CXX flags were overwritten in the 
top-level CMakeLists.txt, so no flags were given to the compiler.
I commited the change and add the corresponding debian/patches.

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

Great. Thanks again.

Mahnu

PS: I am going to check your other answer and come back to you about the 
d/control file quickly.

-------------- 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/20161004/564a5933/attachment-0001.bin>