I have been taking care of periodic mass stabilization of Python packages in Gentoo for some time already. Per Guilherme Amadio‘s suggestion, I’d like to share the workflow I use for this. I think it could be helpful to others dealing with large sets of heterogeneous packages.
The workflow requires:
– app-portage/mgorny-dev-scripts, v10
– dev-util/pkgcheck
Grabbing candidate list from pkgcheck
One of the features of pkgcheck is that it can report ebuilds that haven’t been changed in 30 days and therefore are due for stabilization. This isn’t perfect but in the end, it gets the job done.
I start by opening two terminals side-by-side and entering the clone of ::gentoo on both. On one of them, I run:
stablereq-eshowkw 'dev-python/*'On the other, I do:
stablereq-find-pkg-bugs 'dev-python/*'
stablereq-make-list 'dev-python/*'
This gets me three things:
1. An open Bugzilla search for all stabilization candidates.
2. A script to call file-stablereq for all stabilization candidates open in the editor.
3. eshowkw output for all stabilization candidates in the other terminal.
The three scripts pass their arguments through to pkgcheck. Instead of passing package specifications directly, you can use a simple pipeline to grab all packages with a specific maintainer:
git grep -l python@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 | xargs stablereq-eshowkwFiltering the candidate list
The candidate list given by pkgcheck is pretty rough. Now it’s time to mangle it a bit.
For a start, I go through the eshowkw list to see if the packages have any newer versions that can be stabilized. Roughly speaking, I ignore all packages that have only one stabilization candidate and I check the rest.
Checking usually means looking at git log and/or pkgdiff to see if a newer version would not be a better stabilization candidate. I update the list in the editor accordingly, either changing the desired version or removing some packages altogether (e.g. because they are release candidates or to go straight for a newer version later).
I close the eshowkw results then and do the next round of filtering via Bugzilla search. I look at the Bugzilla search for bugs affecting the stabilization candidates. Once again, I update the list accordingly. Most importantly, this means removing packages that have their stablereq filed already. This is also a good opportunity to resolve obsolete bugs.
I close the search result tabs but leave the browser open (e.g. with an empty tab) for the next step.
Filing the stablereqs
Now I save the list into a file, and run it via shell. This generally involves a lot of file-stablereq calls that open lots of browser tabs with pre-filled stablereqs. I suppose it would be much better to use Bugzilla API to file bugs directly but I’ve never gotten around to implement that.
I use bug-assign-user-js to assign the bugs, then submit them. With some skill, you can do it pretty fast. Point the mouse at the ‘A’ box for the package, click, shift-tab, enter, ctrl-tab, repeat.
If everything went correctly, you get a lot of new bugs filed. Now it’s a good time to look into your e-mail client and mark the mails for newly filed bugs read, before NATTkA starts processing them.
Post-processing the bugs
The last step is to go through bug mail resulting from NATTkA operations.
If sanity check fails, it is necessary to either add dependencies on other bugs already filed, add additional packages to the package list or file additional stablereqs.
For more complex problems, app-portage/nattka 0.2.15 provides a nattka make-package-list -s CATEGORY/PACKAGE-VERSION subcommand that can prepare a package list with dependencies. However, note that it unconditionally takes newest versions available, so you will need to verify the result and replace versions whenever necessary.
Additionally, I generally look at ALLARCHES keyword being added to bugs. If a bug is missing it, I verify whether the package is suitable, and add <stabilize-allarches/> to its metadata.xml.