Hi, Andreas. I've been working on integrating the work from your branch in a way I'm happy with. This is now complete and I have uploaded the package.
David, are you able to test it conveniently? It should build on trixie with `dgit clone` and `dpkg-buildpackage -uc -b`. But I noticed a few things where you might want to reconsider your practice. 1. Approach to adopting Salsa CI I see you configures Salsa to use, directly, the pipeline from recipes/debian.yml@salsa-ci-team/pipeline This is contrary to the recommendation from the Salsa CI Team. They suggest creating debian/salsa-ci.yml with some formulaic contents: https://salsa.debian.org/salsa-ci-team/pipeline/#enable-feature-cicd-in-settings I agree with this recommendation. It is better practice than directly configuring the Salsa CI pipeline. One reason is that if the pipeline configuration should need to be adjusted this can then be done with normal commits to debian/salsa-ci.yml, and does not need configuration changes on Salsa (and therefore does not need coordination of such configuraion changes which the in-tree pipeline file, possibly in many outstanding branches). 2. DEB_BUILD_MAINT_OPTIONS=hardening=+all You added this to d/rules. I could find no documentation in Debian Policy to support this change. I found documentation of the behaviour in dpkg-buildflags. I think you may be following the advice in https://wiki.debian.org/HardeningWalkthrough which talks says things like "Since Debian 7 ("wheezy"). It is unclear to me why we would want -z now, and PIE executables. Are you sure this information is up to date? If we want to make a change to the usual compiler flags, I doubt that making this change to every package, piecemeal, is a sensible way to go about it. Policy should be updated. We have transition arrangements to deal with build breakages, or this could be done by dh in newer compat level, or something. 3. debian/.gitignore. You removed this. Why? This file is useful. 4. watch file doesn't seem to work. I cherry-picked that commit from your branch but it caused this error uscan warn: In debian/watch no matching files for version 0.2017-08-30.3c40fd3 in watch line (visible in Salsa CI, for example). Perhaps this is expected in situations where the upstream "publish" only one version at a time. But in that case this combination of Salsa CI job and watch file is broken, because upstream changes will cause our CI to start failing. I don't think the watch file is very useful really since Simon (the upstream here) doesn't generally make releases very much, and we probably don't want to release to Debian sid every time he does a push. 5. DEP-5 copyright file I think this is makework. ISTM that the machine-readable copyright files have very little benefit to Debian and to the software freedom of our users. Using the current copyright file makes it easy to update, because it's simply a case of copying in a new upstream LICENCE as needed. 6. Date-based version number You changed the version number from 0.<date> to <date>. Date-based version numbers should start with 0. so that if upstream adopts a proper release scheme in future, we don't need an epoch. I have filed a bug suggestion this should be mentioned in policy, #1135785. (There's discussion there, and it turns out that my approach wasn't the best one.) I was surprised to find that you basically overrode this decision of mine without giving any kind of rationale. Especially since once we've uploaded a with a version starting with a year, there's no going back. Also, when choosing the version number you should choose the commit date of the git commit, not the date of the download. In this case that's 2024-09-08, not any date in 2026. Conclusion: I'm giving you this feedback because I know you do a lot of QA work and I hope I can help improve the quality of your output. Thanks for your attention. Since I've now incorporated from your proposed changes what I felt was valuable, I have removed that from Salsa. If there's anything you'd like to re-propose, I'm sure you have a copy locally. If not, I do. Regards, Ian. -- Ian Jackson <[email protected]> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
