On August 5, 2025 3:11:28 PM EDT, Robin Candau <antiz@archlinux.org> wrote:

Hi everyone,

We are very happy to announce the addition of a new member to the "buddy" family: bumpbuddy! [1]

We can always use a new buddy!

Initially introduced to Arch staff during last year's Arch Summit as the "nvchecker-poc" [2], bumpbuddy is now (a)live and ready to assist our package maintainers and users in monitoring new upstream releases for our packages.

## What is bumpbuddy?

Bumpbuddy is a daemon watching for new upstream releases for our packages.

It automatically opens GitLab issues for out of date packages [3], keep them updated if needed (e.g. if a newer upstream release supersedes the initially reported one) [4] and closes them once the matching version has been pushed [5].

It intends to fill the gaps in current methods for new upstream release tracking and reporting by proposing a centralized and automated solution.

This is awesome. I have some packages that don't get updated often and don't have enough users to get flagged quickly, so this will make it way easier to get new versions into [extra] in a timely manner!

## Benefits for package maintainers

Bumpbuddy takes advantage of the `.nvchecker.toml` file from GitLab's packages repo to perform automated tracking of new upstream releases. Therefore, Package Maintainers won't need to rely on manual `pkgctl version check` runs or "homemade" solutions to track new upstream releases for their packages anymore.

The reporting of new upstream releases being done via GitLab issues offers a (public) place to discuss and collaborate around eventual problems or blocking points preventing a new release from being packaged [6].

Assignment to those "out of date" issues is opt-in and can be enabled by reacting with the "package" emoji from bugbuddy's user settings [7]. Note that such issues are automatically opened as "confirmed", so bug-wranglers will not get assigned.

## Benefits for users

Thanks to bumpbuddy automated tracking and reporting, our package maintainers should now be aware of new upstream releases without requiring users to manually flag packages out of date via the dedicated button on Archweb (which we actually intend to get rid of at some point, more on that in the next chapter).

Another benefit for users is that, as opposed to the current "flag out of date" feature, GitLab issues offer a public place to look for (or ask for) the state of a pending update. This should hopefully allow for more transparency towards users wondering why a specific update is taking some time to be packaged.

## Current specifications and future work

Bumpbuddy currently runs every 3 hours, which means that it may take up to 3 hours for new releases to be reported and for the associated GitLab issue to be automatically close once the matching version has been pushed.

3 hours is a pretty wide interval so this isn't a significant issue but I should mention anyway: only concern here is that some smaller upstream code hosting sites may flag this scraping as malicious. Again, though, 3 hours is a pretty wide interval and I doubt it'll cause any problems.

It's also worth reminding that the version tracking is based on the `.nvchecker.toml` configuration file of packages repo, meaning that an erroneous configuration file may result in erroneous version reporting and that packages that miss a configuration file will not be monitored.

Here are a few mid / long term goals we have for bumpbuddy:

- Provide a web overview for reports [9]. - Provide an API endpoint for `pkgctl version check` (to produce faster results). - Manage "out of date" status for packages on Archweb and get rid of the "flag out of date" button; which is manual (and therefore error prone), may be used wrongly/abusively (e.g. to report bugs or send some spam), is highly dependent on packages popularity and lacks transparency (as it doesn't provide a public place to discuss eventual blocking points). - Open merge requests rather than (or in addition of) GitLab issues, including the result of `pkgctl version upgrade` (regarding our future goal to adopt a gitops workflow for packaging). - And more... [10].

## Conclusion

This is the first iteration of bumpbuddy and things are still at a fairly early stage, so bear with us and don't hesitate to open issues [10] to submit bug reports or suggesting improvements.

I would like to thank everyone who helped us improving bumpbuddy so far by opening issues, sharing opinions and opening merge requests. I would also like to give a special thank to Segaja, mh4ckt3mh4ckt1c4s and yan12125, who have been (beta) testing bumpbuddy for the past few months, as well as a huge thanks to klausenbusk & gromit for their amazing work and precious help on that project!

[1] https://gitlab.archlinux.org/archlinux/bumpbuddy [2] https://pkgbuild.com/~antiz/presentations/Nvchecker_PoC/ [3] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues... [4] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues... [5] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues... [6] https://gitlab.archlinux.org/archlinux/packaging/packages/timeshift/-/issues... [7] https://gitlab.archlinux.org/archlinux/bugbuddy/-/issues/1 [8] https://archlinux.org/packages/extra/x86_64/timeshift/flag/ [9] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/10 [10] https://gitlab.archlinux.org/archlinux/bumpbuddy/-/issues/

Great work all! I'm looking forward to the arrival of bumpbuddy issues in my package repos. Best, Campbell