- Aur-general - lists.archlinux.org

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