For Debian package maintainers, the wrap-and-sort tool is one of those nice tools that I use once in a while, and every time have to re-read the documentation to conclude that I want to use the --wrap-always --short-indent --trailing-comma --sort-binary-package options (or -satb for short). Every time, I also wish that I could automate this and have it always be invoked to keep my debian/ directory tidy, so I don’t have to do this manually once every blue moon. I haven’t found a way to achieve this automation in a non-obtrusive way that interacts well with my git-based packaging workflow. Ideally I would like for something like the lintian-hook during gbp buildpackage to check for this – ideas?
Meanwhile, I have come up with a way to make sure I don’t forget to run wrap-and-sort for long, and that others who work on the same package won’t either: create an autopkgtest which is invoked during the Salsa CI/CD pipeline using the following as debian/tests/wrap-and-sort:
#!/bin/sh
set -eu
TMPDIR=$(mktemp -d)
trap "rm -rf $TMPDIR" 0 INT QUIT ABRT PIPE TERM
cp -a debian $TMPDIR
cd $TMPDIR
wrap-and-sort -satb
diff -ur $OLDPWD/debian debian
Add the following to debian/tests/control to invoke it – which is intentionally not indented properly so that the self-test will fail so you will learn how it behaves.
Tests: wrap-and-sort
Depends: devscripts, python3-debian
Restrictions: superficialNow I will get build failures in the pipeline once I upload the package into Salsa, which I usually do before uploading into Debian. I will get a diff output, and it won’t be happy until I push a commit with the output of running wrap-and-sort with the parameters I settled with.
While autopkgtest is intended to test the installed package, the tooling around autopkgtest is powerful and easily allows this mild abuse of its purpose for a pleasant QA improvement.
Thoughts? Happy hacking!
This means that if wrap-and-sort changes it’s behavior by one bit, your package in testing become RC buggy, unless you disable the autopkgtest in the real upload.
Good point, although doesn’t this always hold? If some dependency of a autopkgtest changes its ABI that interacts negatively to the test, the package will be RC-buggy. I’ve uploaded priv-wrapper and pam-wrapper with this autopkgtest now, so we’ll see how it plays out.
/Simon
Pondering more about this, I think I would like to use debci/autopkgtest to run this test and report failures about it (so I will notice it), but failures should not be considered a RC bug nor be used to gate continous integration in Debian. Reading https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.package-tests.rst suggests the ‘flaky’ restriction could be (ab)used to get this effect. If this debci/autopkgtest ever causes real RC bugs or CI holdups to occur, we can consider to use it.
/Simon
flaky
The test is expected to fail intermittently, and is not suitable for gating continuous integration. This indicates a bug in either the package under test, a dependency or the test itself, but such bugs can be difficult to fix, and it is often difficult to know when the
bug has been fixed without running the test for a while. If a flaky test succeeds, it will be treated like any other
successful test, but if it fails it will be treated as though it had been skipped.
Have you considered using a pre-commit hook, e.g. with https://pre-commit.com/ (also packaged in Debian)? You’d probably want to enforce that in CI as well, but it’d mean that you’d get quick feedback locally without having to go through a remote CI cycle.
Thanks for the idea. I put it into my gbp workflow and included it like lintian. In .gbp.conf I added it to the postbuild hook with:
postbuild = lintian -IEvi –show-overrides –color auto $GBP_CHANGES_FILE && echo “Lintian OK”; debtest-wrap-and-sort && echo “wrap-and-sort OK”
debtest-wrap-and-sort is just a script including your above test code.