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. -- https://fam-tille.de
