- Aur-general - lists.archlinux.org

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