From: Colin Watson Date: Thu, 18 Dec 2025 13:22:44 +0000 (+0000) Subject: Preparing a transition in Debusine X-Git-Url: https://www.chiark.greenend.org.uk/ucgi/~cjwatson/git?a=commitdiff_plain;h=1eda7313f49847f7a2d78df6054162cd001c72cf;p=blog.git Preparing a transition in Debusine --- diff --git a/content/debusine-transitions.md b/content/debusine-transitions.md new file mode 100644 index 00000000..9bd1b4e3 --- /dev/null +++ b/content/debusine-transitions.md @@ -0,0 +1,162 @@ +Title: Preparing a transition in Debusine +Slug: debusine-transitions +Date: 2025-12-18 13:21:19 +00:00 +Category: debusine +Tags: debusine, freexian, planet-debian +Summary: A walk-through of preparing changes to multiple packages using Debusine. +Mastodon-ID: 115740777003298023 + +We announced a public beta of +[Debusine](https://freexian-team.pages.debian.net/debusine/) repositories +recently ([Freexian +blog](https://www.freexian.com/blog/debusine-repositories-beta/), +[debian-devel-announce](https://lists.debian.org/debian-devel-announce/2025/12/msg00003.html)). +One thing I'm very keen on is being able to use these to prepare +"transitions": changes to multiple packages that need to be prepared +together in order to land in testing. As I said in my [DebConf25 +talk](https://meetings-archive.debian.net/pub/debian-meetings/2025/DebConf25/debconf25-398-using-debusine-to-pre-test-your-unstable-uploads.av1.webm): + +> We have distribution-wide CI in unstable, but there's only one of it and +> it's shared between all of us. As a result it's very possible to get into +> tangles when multiple people are working on related things at the same +> time, and we only avoid that as much as we do by careful coordination such +> as transition bugs. Experimental helps, but again, there's only one of it +> and setting up another one is far from trivial. +> +> So, what we want is a system where you can run experiments on possible +> Debian changes at a large scale without a high setup cost and without fear +> of breaking things for other people. And then, if it all works, push the +> whole lot into Debian. + +Time to practice what I preach. + +## Setup + +The setup process is documented on the [Debian +wiki](https://wiki.debian.org/DebusineDebianNet#Repositories). You need to +decide whether you're working on a short-lived experiment, in which case +you'll run the `create-experiment` workflow and your workspace will expire +after 60 days of inactivity, or something that you expect to keep around for +longer, in which case you'll run the `create-repository` workflow. Either +one of those will create a new workspace for you. Then, in that workspace, +you run `debusine archive suite create` for whichever suites you want to +use. For the case of a transition that you plan to land in unstable, you'll +most likely use `create-experiment` and then create a single suite with the +pattern `sid-`. + +The situation I was dealing with here was moving to +[Pylint](https://pylint.readthedocs.io/en/stable/) 4. Tests showed that we +needed this as part of adding Python 3.14 as a supported Python version, and +I knew that I was going to need newer upstream versions of the `astroid` and +`pylint` packages. However, I wasn't quite sure what the fallout of a new +major version of `pylint` was going to be. Fortunately, the Debian Python +ecosystem has pretty good autopkgtest coverage, so I thought I'd see what +Debusine said about it. I created an experiment called `cjwatson-pylint` +(resulting in +`https://debusine.debian.net/debian/developers-cjwatson-pylint/` - I'm not +making that a proper link since it will expire in a couple of months) and a +`sid-pylint` suite in it. + +## Iteration + +From this starting point, the basic cycle involved uploading each package +like this for each package I'd prepared: + + :::console + $ dput -O debusine_workspace=developers-cjwatson-pylint \ + -O debusine_workflow=publish-to-sid-pylint \ + debusine.debian.net foo.changes + +I could have made a new `dput-ng` profile to cut down on typing, but it +wasn't worth it here. + +Then I looked at the workflow results, figured out which other packages I +needed to fix based on those, and repeated until the whole set looked +coherent. Debusine automatically built each upload against whatever else +was currently in the repository, as you'd expect. + +I should probably have used version numbers with tilde suffixes (e.g. +`4.0.2-1~test1`) in case I needed to correct anything, but fortunately that +was mostly unnecessary. I did at least run initial test-builds locally of +just the individual packages I was directly changing to make sure that they +weren't too egregiously broken, just because I usually find it quicker to +iterate that way. + +I didn't take screenshots as I was going along, but here's what the list of +top-level +[workflows](https://freexian-team.pages.debian.net/debusine/explanation/concepts.html#workflows) +in my workspace looked like by the end: + +![Workflows]({static}/images/debusine-transitions-workflows.png) + +You can see that not all of the workflows are successful. This is because +we currently just show everything in every workflow; we don't consider +whether a task was retried and succeeded on the second try, or whether +there's now a newer version of a reverse-dependency so tests of the older +version should be disregarded, and so on. More fundamentally, you have to +look through each individual workflow, which is a bit of a pain: we plan to +add a dashboard that shows you the current state of a suite as a whole +rather than the current workflow-oriented view, but we haven't started on +that yet. + +Drilling down into one of these workflows, it looks something like this: + +![astroid workflow]({static}/images/debusine-transitions-astroid.png) + +This was the first package I uploaded. The first pass of failures told me +about `pylint` (expected), `pylint-flask` (an obvious consequence), and +`python-sphinx-autodoc2` and `sphinx-autoapi` (surprises). The slightly odd +pattern of failures and errors is because I retried a few things, and we +sometimes report retries in a slightly strange way, especially when there +are workflows involved that might not be able to resolve their input +parameters any more. + +The next level was: + +![pylint workflow]({static}/images/debusine-transitions-pylint.png) + +Again, there were some retries involved here, and also some cases where +packages were already failing in unstable so the failures weren't the fault +of my change; for now I had to go through and analyze these by hand, but +we'll soon have regression tracking to compare with reference runs and show +you where things have got better or worse. + +After excluding those, that left `pytest-pylint` (not caused by my changes, +but I fixed it anyway in unstable to clear out some noise) and `spyder`. +I'd seen people talking about `spyder` on #debian-python recently, so after +a bit of conversation there I sponsored a `rope` upload by Aeliton Silva, +upgraded `python-lsp-server`, and patched `spyder`. All those went into my +repository too, exposing a couple more tests I'd forgotten in `spyder`. + +Once I was satisfied with the results, I uploaded everything to unstable. +The next day, I looked through the tracker as usual starting from +[astroid](https://tracker.debian.org/pkg/astroid), and while there are some +test failures showing up right now it looks as though they should all clear +out as pieces migrate to testing. Success! + +## Conclusions + +We still have some way to go before this is a completely smooth experience +that I'd be prepared to say that every developer can and should be using; +there are all sorts of fit-and-finish issues that I can easily see here. +Still, I do think we're at the point where a tolerant developer can use this +to deal with the common case of a mid-sized transition, and get more out of +it than they put in. + +Without Debusine, either I'd have had to put much more effort into searching +for and testing reverse-dependencies myself, or (more likely, let's face it) +I'd have just dumped things into unstable and sorted them out afterwards, +resulting in potentially delaying other people's work. This way, everything +was done with as little disruption as possible. + +This works best when the packages likely to be involved have reasonably good +[autopkgtest](https://wiki.debian.org/autopkgtest) coverage (even if the +tests themselves are relatively basic). This is an [increasingly good +bet](https://trends.debian.net/#test-suite) in Debian, but we have plans to +add installability comparisons (similar to [how Debian's testing suite +works](https://www.debian.org/devel/testing)) as well as optional rebuild +testing. + +If this has got you interested, please [try it out for +yourself](https://wiki.debian.org/DebusineDebianNet) and [let us know how it +goes](https://wiki.debian.org/DebusineDebianNet#Where_to_get_help.3F)! diff --git a/content/images/debusine-transitions-astroid.png b/content/images/debusine-transitions-astroid.png new file mode 100644 index 00000000..3e6774ca Binary files /dev/null and b/content/images/debusine-transitions-astroid.png differ diff --git a/content/images/debusine-transitions-pylint.png b/content/images/debusine-transitions-pylint.png new file mode 100644 index 00000000..d700a617 Binary files /dev/null and b/content/images/debusine-transitions-pylint.png differ diff --git a/content/images/debusine-transitions-workflows.png b/content/images/debusine-transitions-workflows.png new file mode 100644 index 00000000..7c07dfe0 Binary files /dev/null and b/content/images/debusine-transitions-workflows.png differ diff --git a/posted_on_Mastodon.txt b/posted_on_Mastodon.txt index 019e093a..2a451a8e 100644 --- a/posted_on_Mastodon.txt +++ b/posted_on_Mastodon.txt @@ -34,6 +34,7 @@ cve-2015-1336.html debconf-cdebconf-coinstallable.html debhelper-statistics-redux.html debhelper-statistics.html +debusine-transitions.html deploying-swift.html desktop-automount-pain.html dgit-dichotomies.html