Hi all, I've just rolled out a new updated archlinux.org, notable changes are: * Developer reports now contain a link to a list of pkgbases * bumpbuddy out of date data import support The bumpbuddy import has now been deployed and is running. See for example aws-vault being flagged by bumpbbuddy. Note that the automatic import doesn't send any email notification like the manual flagging out of date does. [1] In the future the flag out of date button will be disabled in favor of importing bumpbuddy out of date data. Note that we still lack nvchecker integration in packages in this To-Do. [2] [1] https://archlinux.org/packages/extra/x86_64/aws-vault/ [2] https://archlinux.org/todo/add-nvchecker-integration/
On 5/15/26 3:41 PM, Jelle van der Waa wrote:
I've just rolled out a new updated archlinux.org, notable changes are:
* Developer reports now contain a link to a list of pkgbases * bumpbuddy out of date data import support
The bumpbuddy import has now been deployed and is running. See for example aws- vault being flagged by bumpbbuddy. Note that the automatic import doesn't send any email notification like the manual flagging out of date does. [1]
In the future the flag out of date button will be disabled in favor of importing bumpbuddy out of date data. Note that we still lack nvchecker integration in packages in this To-Do. [2] Very nice! :)
Is there a good way forward with the (old) Gitlab email notifications? I currently receive one email when the package is detected as out-of-date, and then two additional ones when the package is updated (one for the comment, one for the status change to "closed"). I guess at this point of the integration I would be fine with just monitoring the developer dashboard on archlinux.org myself, without needing extra emails. That would also solve the problem of stale notifications when a co-maintainer updates the package before I even see the out-of-date email. When a user explicitly flags I'd be fine with receiving one. Thanks for working on this, to everybody involved! cheers, kpcyrd
On 5/15/26 6:23 PM, kpcyrd wrote:
On 5/15/26 3:41 PM, Jelle van der Waa wrote:
I've just rolled out a new updated archlinux.org, notable changes are:
* Developer reports now contain a link to a list of pkgbases * bumpbuddy out of date data import support
The bumpbuddy import has now been deployed and is running. See for example aws- vault being flagged by bumpbbuddy. Note that the automatic import doesn't send any email notification like the manual flagging out of date does. [1]
In the future the flag out of date button will be disabled in favor of importing bumpbuddy out of date data. Note that we still lack nvchecker integration in packages in this To- Do. [2] Very nice! :)
Is there a good way forward with the (old) Gitlab email notifications? I currently receive one email when the package is detected as out-of-date, and then two additional ones when the package is updated (one for the comment, one for the status change to "closed").
I guess at this point of the integration I would be fine with just monitoring the developer dashboard on archlinux.org myself, without needing extra emails. That would also solve the problem of stale notifications when a co-maintainer updates the package before I even see the out-of-date email. When a user explicitly flags I'd be fine with receiving one.
Thanks for working on this, to everybody involved!
cheers, kpcyrd
Hey, Regarding email notifications, here's a quick sum up of how things currently work and future changes on that front: - Automated "out of date" reports on Archweb from bumpbuddy's data do *not* send an email, so there shouldn't duplicate notifications. GitLab remains the place to manage email notifications for "out of date" reports (which are opt-in and can be controlled from bugbuddy user's settings [1]) - The two additional emails when the package is updated are indeed noisy, this is unfortunately due to limitations of the GitLab API. However, this should be addressed in the next `devtools` release! I've opened a related merge request which is scheduled for the future 1.6.0 devtools release. The change aims to automatically close bumpbuddy "out of date" issues when the matching version is released via `pkgctl release`, by automatically adding the "closes <issue_url>" to the commit message. This has multiple benefits: - Instant closing of the issue (while it is only closed at the next bumpbuddy run currently) - Issue being closed with linking to the actual commit that pushed the relevant version - No additional notification for the person that closed the issue by releasing the matching version (as you don't get a mail for issues that you closed yourself) - Only a single notification for other assignes (e.g. co-maintainer) like "Person X closed issue Y with commit Z", as a way to know that someone else bumped the package I think this setup should be much more relevant in terms of notification. - Monitoring the developer dashboard on archlinux.org yourself without opting-in to the notification is indeed a possibility. Alternatively (and also as a reminder for everyone else reading this mail), bumpbuddy data are publicly exposed on a web dashboard [3] and as json [4]. The former allows for a graphical & global monitoring of data with easy filtering (e.g. searching for your nick in the search bar and sort the "Up to date" column) and the later can eventually serve as an endpoint for API calls / custom scripts. Hopefully this covers your questions? Let me know otherwise :) [1] https://gitlab.archlinux.org/archlinux/bugbuddy/-/work_items/1 [2] https://gitlab.archlinux.org/archlinux/devtools/-/merge_requests/338 [3] https://bumpbuddy.archlinux.org [4] https://bumpbuddy.archlinux.org/data.json -- Regards, Robin Candau / Antiz
On 15.05.26 at 19:38 (UTC+0200), Robin Candau wrote:
On 5/15/26 6:23 PM, kpcyrd wrote:
I guess at this point of the integration I would be fine with just monitoring the developer dashboard on archlinux.org myself, without needing extra emails. That would also solve the problem of stale notifications when a co-maintainer updates the package before I even see the out-of-date email. When a user explicitly flags I'd be fine with receiving one.
[...]
- Monitoring the developer dashboard on archlinux.org yourself without opting-in to the notification is indeed a possibility. Alternatively (and also as a reminder for everyone else reading this mail), bumpbuddy data are publicly exposed on a web dashboard [3] and as json [4]. The former allows for a graphical & global monitoring of data with easy filtering (e.g. searching for your nick in the search bar and sort the "Up to date" column) and the later can eventually serve as an endpoint for API calls / custom scripts.
How often is the out-of-date info updated on archweb? Are there some webhooks set up or does it run a job periodically? In case of the latter, I'd expect a rather long delay between updating a package and clearing the out-of-date flag on archweb, so monitoring the dashboard would not prevent the problem when "a co-maintainer updates the package before I even see the out-of-date package".
On 5/16/26 9:17 AM, Jakub Klinkovský wrote:
On 15.05.26 at 19:38 (UTC+0200), Robin Candau wrote:
On 5/15/26 6:23 PM, kpcyrd wrote:
I guess at this point of the integration I would be fine with just monitoring the developer dashboard on archlinux.org myself, without needing extra emails. That would also solve the problem of stale notifications when a co-maintainer updates the package before I even see the out-of-date email. When a user explicitly flags I'd be fine with receiving one.
[...]
- Monitoring the developer dashboard on archlinux.org yourself without opting-in to the notification is indeed a possibility. Alternatively (and also as a reminder for everyone else reading this mail), bumpbuddy data are publicly exposed on a web dashboard [3] and as json [4]. The former allows for a graphical & global monitoring of data with easy filtering (e.g. searching for your nick in the search bar and sort the "Up to date" column) and the later can eventually serve as an endpoint for API calls / custom scripts.
How often is the out-of-date info updated on archweb? Are there some webhooks set up or does it run a job periodically? In case of the latter, I'd expect a rather long delay between updating a package and clearing the out-of-date flag on archweb, so monitoring the dashboard would not prevent the problem when "a co-maintainer updates the package before I even see the out-of-date package".
I will let Jelle correct me if needed but, as far as I'm aware, out-of-data from bumpbuddy are imported in Archweb every 2 hours by a periodic job. However, Archweb only uses bumpbuddy's data to flag the package, not to clear the flag. The flag on Archweb is still being cleared automatically / instantly when the package is released, the mechanism didn't change on that front. I'm also assuming that there is some logic to prevent stale / outdated bumpbuddy data to re-flag the package wrongly until the next run of the periodic job. So a little delay between the package being detected as out-of-date by bumpbuddy and the package being flagged accordingly on Archweb is likely expected. But flag clearing should still be as fast as it is today. Again, I let Jelle correct me if needed :) -- Regards, Robin Candau / Antiz
On 5/16/26 11:21, Robin Candau wrote:
On 5/16/26 9:17 AM, Jakub Klinkovský wrote:
On 15.05.26 at 19:38 (UTC+0200), Robin Candau wrote:
On 5/15/26 6:23 PM, kpcyrd wrote:
I guess at this point of the integration I would be fine with just monitoring the developer dashboard on archlinux.org myself, without needing extra emails. That would also solve the problem of stale notifications when a co-maintainer updates the package before I even see the out-of-date email. When a user explicitly flags I'd be fine with receiving one.
[...]
- Monitoring the developer dashboard on archlinux.org yourself without opting-in to the notification is indeed a possibility. Alternatively (and also as a reminder for everyone else reading this mail), bumpbuddy data are publicly exposed on a web dashboard [3] and as json [4]. The former allows for a graphical & global monitoring of data with easy filtering (e.g. searching for your nick in the search bar and sort the "Up to date" column) and the later can eventually serve as an endpoint for API calls / custom scripts.
How often is the out-of-date info updated on archweb? Are there some webhooks set up or does it run a job periodically? In case of the latter, I'd expect a rather long delay between updating a package and clearing the out-of-date flag on archweb, so monitoring the dashboard would not prevent the problem when "a co-maintainer updates the package before I even see the out-of-date package".
I will let Jelle correct me if needed but, as far as I'm aware, out-of- data from bumpbuddy are imported in Archweb every 2 hours by a periodic job. However, Archweb only uses bumpbuddy's data to flag the package, not to clear the flag. The flag on Archweb is still being cleared automatically / instantly when the package is released, the mechanism didn't change on that front. I'm also assuming that there is some logic to prevent stale / outdated bumpbuddy data to re-flag the package wrongly until the next run of the periodic job.
Archweb just imports bumpbuddy out of date data. In a separate job it watches the repository databases and once they change imports new packages and clears the flagged updated packages.
So a little delay between the package being detected as out-of-date by bumpbuddy and the package being flagged accordingly on Archweb is likely expected. But flag clearing should still be as fast as it is today. Yes, this is expected and I don't think it is bad as its purely more aimed at our users now. The limitation here is that bumpbuddy only generates the data every 2 hours.
Greetings, Jelle
Hi all, On 15/05/2026 15:41, Jelle van der Waa wrote:
Hi all,
I've just rolled out a new updated archlinux.org, notable changes are:
* Developer reports now contain a link to a list of pkgbases * bumpbuddy out of date data import support
The bumpbuddy import has now been deployed and is running. See for example aws-vault being flagged by bumpbbuddy. Note that the automatic import doesn't send any email notification like the manual flagging out of date does. [1]
In the future the flag out of date button will be disabled in favor of importing bumpbuddy out of date data. Note that we still lack nvchecker integration in packages in this To-Do. [2] Manual flagging packages out of date has now been disabled. So all flagging is done automatically via bumpbuddy, please make sure your packages have a valid nvchecker.toml configuration.
Additionally the devel reports now filter on username again.
participants (4)
-
Jakub Klinkovský
-
Jelle van der Waa
-
kpcyrd
-
Robin Candau