[Debian-med-packaging] New CamiTK 4.1.2 release

[Andreas Tille]

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

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

> 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. ;-)
 
> > Thanks for your preparation
> And to you for your patience!

Kind regards

    Andreas.

-- 
http://fam-tille.de