[Debian-med-packaging] New CamiTK 4.1.2 release

[Emmanuel Promayon]

Hi Andreas

On 24/07/18 09:02, Andreas Tille wrote:
> On Tue, Jul 24, 2018 at 08:44:47AM +0200, Emmanuel Promayon wrote:
>>> reject.  Foreign is only for Multi-arch field.
>> OK. Thanks again.
>> So for the next time, does this mean I should leave "Architecture: all" and
>> add "Multi-arch: foreign" for the doc and data package?
> Yes.  Hmmm, I admit I have not checked.  If Multi-arch was deleted than
> its probably good to re-add this for the next package revision.

OK. I will. (probably my mistake: I accidentally delete the 
"Architecture" line, when I added the "MultiArch" line)

>
>> Another thing that I did (on the same commit that I later erased), is to
>> downgrade to standard version 4.1.4. As it is at the moment, the standard
>> version is 4.1.5 (which is still "experimental" from what I can gather in
>> the man page).
>> Is that all right?
> Not really but no real harm is done.  In debian-devel-announce the new
> policy version was announced and than it is not experimental any more.
> You can always check this by checking the current version of the package
> debian-policy in unstable (either in tracker.d.o or as I prefer on
> command line via
>
> apt-cache policy debian-policy
> debian-policy:
>    Installed: 4.1.5.0
>    Candidate: 4.1.5.0
>    Version table:
>   *** 4.1.5.0 605
>           50 http://httpredir.debian.org/debian unstable/main amd64 Packages
>
> I'd recommend
>
> cat >> /etc/apt/preferences.d/01-debian-policy.pref <<EOT
> Package: debian-policy
> Pin: release a=unstable
> Pin-Priority: 605
> EOT
>
> to make sure the policy package on your system is always taken from
> unstable (and thus per definition up to date).

Thanks for the trick. I suppose also that lintian would have warned 
about using an old version as well (and maybe "cme check dpkg-control" 
would have says something as well).

>   
>>> I also remember there were lintian information about mis-spellings but
>>> I incidentally removed the binary packages on my side.  I'd recommend
>>> to run `lintian -I camitk*.changes` to learn about spelling mistakes
>>> in your upstream code.
>> Thanks. You are right, there are a lot of misspellings detected by lintian,
>> some of them would benefit from an API change (two class names are
>> misspelled!), some of them were taken into account in the debian/patch 0001
>> and 0002.
>> This will be taken care of in upstream for the next version.
> I do not think that lintian detects misspellings in functions - so I'd
> not recommend to change the API simply because of some wrong spelling.
> This just creates more hasle than it solves and is not exposed to the
> end user.  As far as I understand lintian only cares about wrong
> spellings in strings.
Yes you are right, it is only in the text string (including visible 
strings in the GUI, for instance here it was in Qt ".ui" files). I think 
it also checks the translation files as well (but I am not so sure).

>> I am also trying to set a continuous integration stage so that upstream code
>> is also checked regularly for packaging on sid (including lintian -iIE and
>> autopkgtest), which might simplify the publication of a new release.
> Very sensible.  I'd applause this. ;-)
If I manage to do that, I will let you know! FYI, we are using gitlab ci 
on the upstream gitlab server.

That leads to my new question about the good usage of the salsa git. 
Imagine that we need to update some file in order to build a package 
from the current upstream (unreleased) version (e.g., debian/control).

In this case do you think it is ok to "pollute" salsa with an extra 
"upstream-ci/master" branch?

When a new version would be released, "upstream-ci/master" should 
contain everything required, and it can be merged directly to "master" 
(and then started afresh).

Kind regards
Emmanuel