August 2023 - Aur-general - lists.archlinux.org

[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

[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

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