- Aur-general - lists.archlinux.org

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