Re: [MoM] CTK

Hi Fernando,

Am Thu, Aug 13, 2026 at 10:20:04AM +0200 schrieb Fernando Hueso Gonzalez:
> thanks for the guidance.

You are welcome.
 
> Question about preexisting commits:
> 
> https://salsa.debian.org/med-team/ctk/-/commit/8298dbaa253707c19713444b2c838ed55377ff4d
> I imagine that this commit is coming from a migration from CVS to Git or sth like that ? The commit message is not very detailed.

Most probably.  When I recommended to ask for commit details I was
thinking about todays commits. ;-)

> debian/changelog : do we need a separate paragraph for each commit or Pull Request, or can we keep adding bullet points to a preexisting section as long as it has not been released? Also I see sth like unstable; urgency=low, do we set all this by hand and how or who to decide the urgency level ?

What is *really* important:  Just keep the traget distribution at
UNRELEASED (not unstable!) as long as you are not uploading.  This is
the signal for your team mates that the package is not released and we
continue working on the actual release.  Also we have *always*

   urgency=medium

not low or anything else.  You are well advised to use

    dch

when creating a changelog entry.  Whether you prefer changelog entries
for every single change or let git create all changelog entries at once
is a style question.  I think the culture in Debian Med is:

    do some changes
    $ dch "my changes"
    $ debcommit -a
    do more changes
    $ dch "more changes"
    $ debcommit -a
    ...

I prefer this workflow.  There is another option which is leading to the
same effect

    for changes
       do some changes
       # git commit -a -m"my changes"
    gbp dch
    git commit debian/changelog -m"List of my changes"

Gbp will create the changelog based upon the Git commit messages.  My
preference for the first workflow is that I sometimes use different text
inside the changelog than in the commit.

> https://salsa.debian.org/med-team/ctk/-/commit/ba389fc366c730b616abc5e04442261921f6f1ed
> Sometimes unstable, sometimes unreleased or experimental, how to decide among these options?

My guess is at that commit experimental was choosen by accident.  I
repeat:  Just use UNRELEASED.  You have no upload permissions so this is
very easy.  You will tell your sponsor whether you consider this release
as a candidate for experimental.  A good reason for experimental is for
instance a SOVERSION bump and than see how reverse dependencies might
behave in the isolated experimental environment.  Otherwise your sponsor
will set this to unstable.
 
> https://salsa.debian.org/med-team/ctk/-/commit/90a0668f80f4387edcadea500de0ef041de4d0b6
> Do we set this git/tagname manually? Any directions on what to write? Current date? 

We do not set the version manually.  I've added a watch file which picks
the latest tag from upstream.  This is always the prefered way to go.
There are upstreams who do not consider the good habbit to add tags.
Than its strongly recommended to rely on uscan (which parses the watch
file) as well.  Our package template has a paragraph for this:

   https://salsa.debian.org/med-team/community/package_template/-/blob/master/debian/watch?ref_type=heads#L38-42

The result is a version
     UPSTREAMVERSION_IF_EXISTS+gitDATE.COMMITID
Here is some random example:
     https://salsa.debian.org/med-team/mcaller/-/blob/master/debian/watch?ref_type=heads
 
> https://salsa.debian.org/med-team/ctk/-/commit/5a4346abe5549bb2efd7b62c4e8cf20567dd2633
> I see a patch for overwriting the default library folder. Why not just calling cmake -DCTK_INSTALL_LIB_DIR=lib in the debian/rules? Or are patches better for this?

I just refreshed the patch and unfortunately its not properly
documented.  If you find a good solution without any need for a patch
just go for it.  The less patching the better!
 
> https://salsa.debian.org/med-team/ctk/-/commit/4ced85699f1f5ff8070515e4f5fc01335a2ec71d
> What does team-upload mean?

    https://www.debian.org/doc/manuals/developers-reference/pkgs.html#collaborative-maint
    (For history see https://wiki.debian.org/TeamUpload )
 
> https://salsa.debian.org/med-team/ctk/-/commit/fa4c30739689df5a37359532c059e9d098a4206e
> what does watch do? It creates automatic notifications when something is updated upstream?

    man uscan

There is a cron job checking *all* Debian packages with watch file and
if there is a new upstream version it will be announced on the tracker
page.  Our example mcaller is up to date

    https://tracker.debian.org/pkg/mcaller

in contrast for instance to

    https://tracker.debian.org/pkg/adapterremoval

(argh, we are lagging so much behind.  That's a shame but I hope we can
catch up soon.)

> Should it notify about tag releases or for every commit?

As I tried to explain above:  Usually the watch file should fetch tags.
If there are "good reasons" (no tags at all / other reasons) the watch
file can point to latest Git commit.

 
> https://salsa.debian.org/med-team/ctk/-/commit/a87cbba59fbfc66589153e6e4dfe26eb9d8ac713
> What is the implication of the priority keyword? Do you need to change it or it will be always optional?

The lintian tool tells you whether your package is policy compliant.
Just run it after every package build!  Lintian would have told you that
Priority extra is outdated.  I used lintian-brush to fix this
automatically.

Recently the Priority field became obsolete for *all* Debian Med
packages since we do not have any packages with Priority higher than
optional.  Our tooling is removing this field!  Just ignore it.
 
> https://salsa.debian.org/med-team/ctk/-/commit/5987f918c7ce4d9476d59d237f8f69877844b029
> I see that CTK uses an Apache 2.0 license. Does that map to not-using-common license?

I did not checked this commit.  You have to *carefully review* (!!!!)
the debian/copyright file.  Its most probably outdated / invalid /
wrong!  The tool

   lrc

is of really great help to review a debian/copyright file.
 
> https://salsa.debian.org/med-team/ctk/-/commit/e3d397f94a31112f6478493d317c91d09c2f0c2e
> What is this update meaning? Was it done by a script called routine-update or manually?

This was done by routine-update.  It always updates to the latest
Standards-Version and this is nearly always fine.  Lintian will tell you
if not.

> https://salsa.debian.org/med-team/ctk/-/commit/70884a68ee51653325e7eee225c76c5febaf2f4a
> How do you deal with debian/copyright, a script puts files there automatically, or you do it manually?

I would love if there would be a script.  Crafting a debian/copyright
file is a process which is not fun but it is important anyway.  The
commands:

   $ grep -Ri copyright # possibly with some following `grep -v` for things that are covered in d/copyright
   $ lrc

are your friends.

Back to your actual build log
    https://salsa.debian.org/med-team/ctk/-/jobs/10127898
says

    dh_missing: error: missing files, aborting

Dh-missing defaults to --fail-missing (see `man dh_missing`).  It found
out upstream wants to install some files which are possibly not yet in
the binary package target.  CMake files probably should go to the
libctk-dev package.  I have *NOT* tried this but my gut feeling says
you want to add a file

   $ cat debian/libctk-dev.install
   usr/lib/CMake/ctk       usr/lib/${DEB_HOST_MULTIARCH}/

Feel free to push this directly to the team repository if it works for you.

Hope this helps
      Andreas.