Hi Ian, Am Tue, May 05, 2026 at 10:45:04PM +0100 schrieb Ian Jackson: > 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.
Cool. Thanks a lot. > 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. I also agree with this and inside the teams I can influence the policy its even scripted to make sure every package is configured like this[1] > 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). I absolutely get this point. It just turned out that it is less "invasive" to other teams / maintainers not to add the debian/salsa-ci.yml file. In your case this is not the case but its to complex to know what people think in advance. I could for sure just follow the recommendation of the Salsa CI Team but I decided what I consider the "second best option" and leave it to the maintainer. > 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. I absolutely agree that its a nuisance to add this manually. The thing is that for nearly all packages you would need blhc: allow_failure: true in debian/salsa-ci.yml to pass Salsa CI. As a consequence of my decision to not use salsa-ci.yml and by considering passing all tests a sensible goal I added the hardeing options. I personally understood the Wiki page in a way that we want this and have not seen this questionable. I've seen *many* packages where just adding this to d/rules did not helped and extra patches to the build system were needed. Since I considered it important that the build system is supporting all options we set in d/rules I've seen this as some valid test to confirm that the build system is correct (not every package was featuring the according bug about not supporting all build flags). > 3. debian/.gitignore. > > You removed this. Why? This file is useful. Sorry - I should probably not have removed it. > 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. The watch file worked for the proposed new version (see below). The new Salsa CI test seems to be broken and fails in all cases. I prefer to have a watch file even if you are very close to the maintainer or are the maintainer yourself and know what to do. You might even consider the following watch file: Version: 5 Untrackable: Deactivated for REASON Source: https://www.chiark.greenend.org.uk/~sgtatham/ipbt/ Matching-Pattern: .*/ipbt-@ANY_VERSION@@ARCHIVE_EXT@ > 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. I disagree here. My workflow includes running lrc[2]. This raises a signal even if I overlook some new license. Automating things where humans might fail makes perfectly sense to me. > 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. I've choosen this version based on the result of the watch file *and* the upstream tarball which seemed consistent. I do not intend to question your version scheme which is based upon internal knowledge. If I where you I would adopt a d/watch with `Mode: git` that might enable a commit based date. However, currently the link to the Git repository ends up in "Forbidden". > 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. This is absolutely welcome and I appreciate this feedback. > 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. I'm absolutely happy with seeing its-playback-time maintained on Salsa now. My initial commits do not matter at all. Thanks a lot for your cooperation. Unfortunately its really rare to see productive responses like this. Kind regards Andreas. [1] https://salsa.debian.org/debian/routine-update/-/blob/master/routine-update?ref_type=heads#L885-899 [2] https://salsa.debian.org/debian/routine-update/-/blob/master/routine-update?ref_type=heads#L1093 -- https://fam-tille.de
