- Aur-general - lists.archlinux.org

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

Submission rules unclear
by hirecguiihricy 19 Nov '25

19 Nov '25

Hey everyone, So I noticed some sandbox packages are being deleted — surprise — and the usual justification is “Personal configuration should be covered in ArchWiki.” Meanwhile, when I suggested merging linuxqq-nt-bwrap into the main linuxqq package (because of that Package Manager's action), that request got turned down — apparently it’s “popular.” Consistency much? This double standard and murky rule enforcement is confusing. Please fix the guidelines and explain exactly what’s allowed so people don’t waste time guessing which rules apply.

1 0

Fwd: How To Handle Hostile Maintainer w/out Dup AUR Packages
by Pranav Sharma 18 Nov '25

18 Nov '25

Hello all, I was wondering how to deal with a hostile maintainer who is squatting on a set of packages, but refuses to update them in a timely manner or to make improvements / fixes to the packages. The packages in question are wlcs, mir, and miracle-wm. I have been the one to update the packages this year, after a previous conflict where the current maintainer added me as a co-maintainer. They only did so when I opened an orphaned request after weeks of not updating the package, with zero communication. This person doesn't communicate, doesn't make sense when they are forced to, and acts down right hostile. I don't think they even use the packages, rather is interested in collecting AUR packages like they are pokemon, as they currently post on github "maintainer of 450+ AUR packages". They actually swooped in to claim the mir package after I sent in an orphan request so I could adopt it. Best, Pranav

1 0

naming: does minified code count as "source-based"?
by Christopher Cooper 11 Nov '25

11 Nov '25

Hi all, I maintain the claude-code package [1] on AUR along with ticpu. Claude Code is not an open source project. For most of the project's lifespan, it has been distributed only as an npm package [2], which contains only minified javascript. Recently, a "binary" version was released which appears to use the same code as released on npm, but bundled into a standalone executable using `bun build --compile` [3]. The official docs [4] now seem to prefer installing the standalone binary, though the option to install through npm is still available. I recently switched the package to use the distributed bun binary, rather than the minified npm package, since this seems to now be the installation method preferred by upstream. However, this raises an interesting question - should the package now be called "claude-code- bin" instead of "claude-code"? The logic here is that the "-bin" suffix should be used if a source- based package is available. In this case, the npm package would be such a "source-based" package. I personally find this argument uncompelling, as minified code doesn't really seem comparable to actual source code. The npm package and the distributed binary have essentially the same visibility into the underlying code that is being run - you could use `strings` or other methods to extract the minified code from the binary version. There's a second argument which is more compelling to me, that some users may prefer the npm-based installation, so it would be useful to have two different AUR packages. In this case, the new binary-based package could be called "claude-code-bin", and the previous npm-based package could be just "claude-code". (Of course, other naming schemes could be used, e.g. "claude-code" and "claude-code-npm".) Personally, I don't see great value in having two separate packages and the opportunity for user disruption seems high, but I'd love to hear people's opinions on this. This boils down to two questions: 1. Is it _against the package naming rules_ to call this package "claude- code" rather than "claude-code-bin"? 2. Do people think that this package _should_ be split into separate packages for the two installation methods, and if so, what should the packages be called? Thanks for your consideration, Christopher [1]: https://aur.archlinux.org/packages/claude-code [2]: https://www.npmjs.com/package/@anthropic-ai/claude-code [3]: https://bun.com/docs/bundler/executables [4]: https://code.claude.com/docs/en/overview

2 1