- Aur-general - lists.archlinux.org

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