- Aur-general - lists.archlinux.org

Add detail to deletion emails due to TU adoption
by Gesh 20 Jan '26

20 Jan '26

Hi, TL;DR: the notification emails when AUR packages are adopted by TUs are indistinguishable from deletions, and communications norms around them makes it hard to discover otherwise. Please change either or both. I recently was notified that three packages I was monitoring had been deleted from AUR, with no further detail beyond eg > grawlinson [1] deleted python-markdownify [2]. > > You will no longer receive notifications about this package. > > [1] https://aur.archlinux.org/account/grawlinson/ > [2] https://aur.archlinux.org/pkgbase/python-markdownify/ Concerned, I checked whether I was still using them, and indeed I was -- python-markdownify is an optdepend of papis. I was just about to contact the previous maintainer about the abrupt deletion (instead of disownment) -- I'd checked the ML archives and couldn't find any mention of such plans -- when I realised grawlinson is actually a TU. On a hunch, since this isn't the first time this has happened, I checked > $ pacman -Si python-markdownify > Repository : extra > Name : python-markdownify > Version : 1.2.2-2 > Description : Convert HTML to Markdown > Architecture : any > URL : https://github.com/matthewwithanm/python-markdownify > Licenses : MIT > Groups : None > Provides : None > Depends On : python python-beautifulsoup4 > Optional Deps : None > Conflicts With : None > Replaces : None > Download Size : 30.74 KiB > Installed Size : 128.32 KiB > Packager : George Rawlinson <grawlinson(a)archlinux.org> > Build Date : Thu 15 Jan 2026 03:48:32 > Validated By : SHA-256 Sum Signature Of course, once the package updates and pacman notices a newer version exists in extra, it *will* notify me of that. However, in the absence of that, I needed to luck into guessing what had happened. Instead, the following three possibilities suggest themselves to avoid this situation again: - Have moving from AUR to repos be a change warranting a pkgrel bump. - Change TU adoption policy to require a form announcment to aur-general. - Have TU adoption trigger a distinct automated email from aurweb to listeners. Any or all of these would've been enough to save me the detective work. Thanks, Gesh

1 0

Request: Package Removal: alterfalter
by linux_service＠gmx.de 15 Jan '26

15 Jan '26

Please remove this package: alterfalter This software is not helping any one. It is a shame, that this software is still available in the AUR. If you want war, I can recommned the french legion etrangère. Merci beaucoup

1 0

Request: Package Removal: whisparr-nightly-bin
by linux_service＠gmx.de 15 Jan '26

15 Jan '26

Please remove this package: whisparr-nightly-bin This software is not helping any one. Every one who has adultmovies and feels the need to organize them has lost the connection to real life. Do yourself a favour and delete this package. I guess you can see yourself now, what pornofication did to humanity.

1 0

Guidance on renaming helium-browser-bin
by Sam Sinclair 02 Jan '26

02 Jan '26

Hello everyone, I maintain the /helium-browser-bin/ packaging, and I'm considering a rename to /helium-bin/, which I've also put forward to the community in the comments. This consideration comes as upstream Linux packaging matures [1]. When I submitted the package initially, my thinking was to append /-browser/ to avoid potential naming conflicts, but it now seems unnecessary and isn't consistent with upstream. I was hoping to get some guidance on whether a rename is reasonable in this case, and if so, how to best go about it while minimising problems for end users. My current plan is: 1. Submit the /helium-bin/ package to the AUR as normal 2. Add `conflicts=('helium-browser-bin')' to /helium-bin/ PKGBUILD to allow users to cleanly remove the old version on install 3. Push existing package to the new repo to preserve git history 4. Initiate a merge request for /helium-browser-bin/ to /helium-bin/ to preserve comments and remove the old package I would do this after the next release at the time while keeping users up to date. I've tested packaging locally with success, and impacts to users should be constrained to the package name and install paths removing the 'browser' suffix. The entry point remains `/usr/bin/helium-browser'. Questions :: - Is this the correct/preferred method? - While in between merge requests, which repo should I treat as the source of truth in the case of updates? - Anything that I've missed? Thanks very much in advance! Cheers, Sam [1]: https://github.com/imputnet/helium-linux/pull/149

1 0

Anyone built package with libboost 90 yet?
by David C Rankin 31 Dec '25

31 Dec '25

AUR packagers, This is just a question looking for a heads-up on how bad libboost 90 breakage in apps using boost will be. I've read though the libboost 90 report and individual library changes and on it's face doesn't look that bad, but the mongodb44 package I maintain has a long, long line of boost patches that are necessary with just about every minor version update. Currently libboost 90 is in testing. My build box is also a production box, so it is difficult to switch to testing to check. Has anybody run into boost 90 build failures, and if so, based on past experience, does this require significant patching, or just run of the mill, handful of lines to fix? Just trying to get an idea whether I need to set time aside for the update. Thanks! -- David C. Rankin, J.D.,P.E.

1 0

Suspicious links to binaries in aur:linux-cnc comments
by Fermín Olaiz 24 Dec '25

24 Dec '25

Hey there! Would anyone mind taking a look at the comments in linux-cnc? [1] There are two comments with links to binaries that called my attention. I can't say there's ill intent but given all that's been happening with attempts of distributing malware through the AUR it's better to be safe than sorry. Maybe the comments could be sanitized? I don't think there's a specific rule regarding this. Thank you all! :) Fermín Olaiz. [1] https://aur.archlinux.org/packages/linuxcnc

1 0

AUR request processing delay
by 이 종효 21 Dec '25

21 Dec '25

A large number of AUR requests are currently sitting unprocessed. Is there an internal issue?

1 0

AUR request processing delay
by 이 종효 21 Dec '25

21 Dec '25

Currently, AUR requests are sitting in the queue and not being processed. Is there an internal issue?

1 0

First AUR package pre-push questions
by Conor C. Peterson 21 Nov '25

21 Nov '25

Greetings folks, I've just created a small and simple package for a font that I like to use that isn't already available in the AUR --- [Inclusive Sans]( https://github.com/LivKing/Inclusive-Sans) [My PKGBUILD source]( https://privatebin.net/?3107c3b826818881#8F7zgoCiQFPJwpRBzYBb21JH1H6RPQHx38… ) After reading through [AUR submission guidelines | ArchWiki]( https://wiki.archlinux.org/title/AUR_submission_guidelines) I'm following the recommendations and asking two things on here: 1. Are there any improvements I should make to my PKGBUILD? - This is the first package I've ever created - I've mostly looked at the PKGBUILDs for `ttf-merriweather-sans` (linked in the wiki) and `ttf-rubik-vf` (as a more recent example) and created a new PKGBUILD based on those two existing ones. - Made sure `namcap` was reporting no errors/warnings. 2. Is this a worthwhile package to submit to the AUR? - After creating it and reading through the wiki, I realized this may be insufficiently useful to submit. Could it be useful to others? Certainly, as much as any font. But it _is_ quite a niche font, I guess. Thanks in advance, C. C. Peterson

3 3

Package deletion
by Gonsolo 21 Nov '25

21 Nov '25

Hi! I am the package maintainer of https://aur.archlinux.org/packages/openlane2 which is obsolete. How can I delete it? Thanks -- g

2 1