- Aur-general - lists.archlinux.org

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

Re: pkgbuild
by Robin Candau 03 Jul '23

03 Jul '23

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

1 0

Re: pkgbuild
by Robin Candau 02 Jul '23

02 Jul '23

/Transferring OP's reply to the proper mailing list/. > On Sun, Jul 2, 2023 at 6:59 PM Robin Candau <antiz(a)archlinux.org> wrote: > > Le 02/07/2023 à 04:20, james smith a écrit : >> I am trying to package this https://github.com/lemmygtk/lemoa >> this is my pkgbuild any tips on how to improve it before I send >> it to aur is appreciated > > Hi James, > > _/Quick note before reviewing your PKGBUILD:/_ > /When asking for a review, try to make your PKGBUILD publicly > readable somewhere (by posting it in paste service for instance, > like https://bpa.st/ or https://gist.github.com/) This is way > easier to track as the discussion progresses and way more "trust > worthy" than an attached file sent to a mailing list. > //For everyone's context, here's the initial PKGBUILD provided for > a review:/ > https://bpa.st/TXEW2 > > In it's current state, your PKGBUILD won't work and needs some > modifications and improvements. > Here's what I can list after a quick review: > > - The comments at the top provided by the PKGBUILD example file > should be removed. > > - You can remove variables/arrays that are empty/unused in your > PKGBUILD (epoch, groups, checkdepends, etc...). > > - Consider filling out the maintainer info at the top of the > PKGBUILD. This isn't mandatory but it is recommended and appreciated. > > - The pkgname you chose refers to a VCS package ("lemoa*-git*"). > If you indeed want your package to be a VCS package (meaning that > it relies on the latest upstream commit instead of a specific > tag/release) then you have to adapt your PKGBUILD accordingly with > a proper "pkgver()" function [1]. > Otherwise, switch your "pkgname" to "lemoa" and update the rest of > the PKGBUILD accordingly. > > - 'GNU' isn't a valid license. The correct license for "lemoa" > currently is 'GPL3' [2]. See also the license section of the > PKGBUILD wiki page for more information [3]. > > - The 'Gtk' package listed in the "depends" array isn't a valid > package. "Lemoa" seems to depends on GTK-4 [4] which can be > installed via the "gtk4" package in Arch [5]. > > - Upstream documentation also lists "rust, cargo and pkg-config" > as "Build dependencies" [4]. According to that, you should add the > "cargo" package (which also provides "rust") to your "makedepends" > array. > However, you don't have to explicitly list the "pkg-config" > package (provided by the "pkgconf" package in Arch [6]) because it > is a member of the "base-devel" meta-package [7] which is assumed > installed during build-time [8]. > > - The "install" variable expects the name of an optional > ".install" script used to perform tasks before or after the > install, the upgrade and/or the removal of the package [9], it > isn't meant to store a "raw" command like you did. At first > glance, there's no need for an install script in your case so you > can remove that variable. > > - The "source" array is wrong and will fail to download the repo. > It should be "git*+*$url" instead of "git*=*$url". See the VCS > sources section of the wiki for more information [10]. Just for > the sake of it, I'll add the usual trailing ".git" at the end, > like so: source=("git+${url}.git") > > - Because the sources are not static in a VCS package, you have > to explicitly skip the checksum by adding 'SKIP' to the "md5sums" > array [11]. Letting it empty will not work. > On a side note, I recommend switching to a more modern and secure > hash algorithm generally speaking ("sha256sums" for instance). > > - You shouldn't "git clone" the repo inside the "build()" > function. This is implicitly done beforehand by filling the > correct/proper sources in the "source" array. > > - The "ninja -C _build install" part as to be called within the > "package()" function. You'll also need to setup the destination > directory to "$pkgdir" which is the temporary directory where > "makepkg" builds and bundles the package [12]. See the "package()" > section of the Meson packaging guidelines for more information [13]. > > Overall, I advice you to read closely the three following Arch > wiki pages which should contain most of the information you'll > need to write a proper PKGBUILD for "lemoa-git": > - PKGBUILD [14] > - VCS Packaging Guidelines [15] > - Meson Packaging Guidelines [16] > > I hope this helps :) > Don't hesitate to ask for details or further questions if needed! > > [1] > https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_functi… > [2] https://github.com/lemmygtk/lemoa/blob/main/LICENSE > [3] https://wiki.archlinux.org/title/PKGBUILD#license > [4] https://github.com/lemmygtk/lemoa#build-dependencies > [5] https://archlinux.org/packages/extra/x86_64/gtk4/ > [6] https://archlinux.org/packages/core/x86_64/pkgconf/ > [7] https://archlinux.org/packages/core/any/base-devel/ > [8] https://wiki.archlinux.org/title/PKGBUILD#makedepends > [9] https://wiki.archlinux.org/title/PKGBUILD#install > [10] > https://wiki.archlinux.org/title/VCS_package_guidelines#VCS_sources > [11] > https://wiki.archlinux.org/title/VCS_package_guidelines#Authentication_and_… > [12] > https://wiki.archlinux.org/title/Creating_packages#Defining_PKGBUILD_variab… > [13] > https://wiki.archlinux.org/title/Meson_package_guidelines#package() > [14] https://wiki.archlinux.org/title/PKGBUILD > [15] https://wiki.archlinux.org/title/VCS_package_guidelines > [16] https://wiki.archlinux.org/title/Meson_package_guidelines > > -- > Regards, > Robin Candau / Antiz > Le 02/07/2023 à 21:26, james smith a écrit : fixed some of the suggestions you had https://mystb.in/AuroraStreamAdjacent is it ok that my email is md5 hashed instead of just the email? Well, according to the fact that filling your email address at the top of the PKGBUILD isn't mandatory per say, this is better than nothing but not so "accessible". If this is a matter of protecting yourself from eventual bots or something, you could do something like "address[at]mail[dot]com" which is eventually more accessible. But the final decision is up to you, no obligation there. Regarding your PKGBUILD, there are still some modifications to make as far as I can see: - The maintainer information has to be contained inside a comment, otherwise your PKGBUILD won't work: # Maintainer: Your Name <Your email address> - The "pkgver()" function does not replace the "pkgver" variable, it just updates it automatically each time makepkg is ran against the PKGBUILD (according to the latest upstream commit). You should put back the "pkgver" variable where it was and put the "pkgver()" function before the "build()" function. Once done, building the package against the PKGBUILD will automatically update the "pkgver" value. - Generally speaking, you should list every first level dependencies even if some are already implicitly satisfied by another package. However, some exceptions can be done when you're absolutely sure that a package cannot ever stop pulling another one as a dependency. According to that, you don't necessarily have to explicitly list "rust" as a dependency as it is already pulled by "cargo" and we're sure that "cargo" won't ever stop pulling "rust" as a dependency since "cargo" is the "rust package manager". See the "depends" section of the PKGBUILD wiki page for more information [1]. - No need to keep the empty "noextract" array. - One thing I forgot to mention in my initial reply is that your package has to "conflict" and "provide" the "lemoa" package in order to avoid issues if someone tries to install both on the same system (even though the "lemoa" package does not exists */yet/*). To do so you have to use a "provides" and "conflicts" arrays in your PKGBUILD. See the related section of the PKGBUILD arch wiki page [2] [3]. [1] https://wiki.archlinux.org/title/PKGBUILD#depends [2] https://wiki.archlinux.org/title/PKGBUILD#provides [3] https://wiki.archlinux.org/title/PKGBUILD#conflicts -- Regards, Robin Candau / Antiz

1 0

Re: pkgbuild
by Robin Candau 02 Jul '23

02 Jul '23

Also, the proper mailing list to ask for a PKGBUILD review is aur-general(a)lists.archlinux.org. I haven't noticed you used aur-dev(a)lists.archlinux.org instead when I replied the first time so I forwarded the discussion to the proper mailing list this time via this reply. Let's continue this discussion here please :) For everyone's context, here's the initial PKGBUILD provided for a review: https://bpa.st/TXEW2 -- Regards, Robin Candau / Antiz Le 02/07/2023 à 20:59, Robin Candau a écrit : > Le 02/07/2023 à 04:20, james smith a écrit : >> I am trying to package this https://github.com/lemmygtk/lemoa this is >> my pkgbuild any tips on how to improve it before I send it to aur is >> appreciated > > Hi James, > > _/Quick note before reviewing your PKGBUILD:/_ > /When asking for a review, try to make your PKGBUILD publicly readable > somewhere (by posting it in paste service for instance, like > https://bpa.st/ or https://gist.github.com/) This is way easier to > track as the discussion progresses and way more "trust worthy" than an > attached file sent to a mailing list. / > > In it's current state, your PKGBUILD won't work and needs some > modifications and improvements. > Here's what I can list after a quick review: > > - The comments at the top provided by the PKGBUILD example file should > be removed. > > - You can remove variables/arrays that are empty/unused in your > PKGBUILD (epoch, groups, checkdepends, etc...). > > - Consider filling out the maintainer info at the top of the PKGBUILD. > This isn't mandatory but it is recommended and appreciated. > > - The pkgname you chose refers to a VCS package ("lemoa*-git*"). If > you indeed want your package to be a VCS package (meaning that it > relies on the latest upstream commit instead of a specific > tag/release) then you have to adapt your PKGBUILD accordingly with a > proper "pkgver()" function [1]. > Otherwise, switch your "pkgname" to "lemoa" and update the rest of the > PKGBUILD accordingly. > > - 'GNU' isn't a valid license. The correct license for "lemoa" > currently is 'GPL3' [2]. See also the license section of the PKGBUILD > wiki page for more information [3]. > > - The 'Gtk' package listed in the "depends" array isn't a valid > package. "Lemoa" seems to depends on GTK-4 [4] which can be installed > via the "gtk4" package in Arch [5]. > > - Upstream documentation also lists "rust, cargo and pkg-config" as > "Build dependencies" [4]. According to that, you should add the > "cargo" package (which also provides "rust") to your "makedepends" array. > However, you don't have to explicitly list the "pkg-config" package > (provided by the "pkgconf" package in Arch [6]) because it is a member > of the "base-devel" meta-package [7] which is assumed installed during > build-time [8]. > > - The "install" variable expects the name of an optional ".install" > script used to perform tasks before or after the install, the upgrade > and/or the removal of the package [9], it isn't meant to store a "raw" > command like you did. At first glance, there's no need for an install > script in your case so you can remove that variable. > > - The "source" array is wrong and will fail to download the repo. It > should be "git*+*$url" instead of "git*=*$url". See the VCS sources > section of the wiki for more information [10]. Just for the sake of > it, I'll add the usual trailing ".git" at the end, like so: > source=("git+${url}.git") > > - Because the sources are not static in a VCS package, you have to > explicitly skip the checksum by adding 'SKIP' to the "md5sums" array > [11]. Letting it empty will not work. > On a side note, I recommend switching to a more modern and secure hash > algorithm generally speaking ("sha256sums" for instance). > > - You shouldn't "git clone" the repo inside the "build()" function. > This is implicitly done beforehand by filling the correct/proper > sources in the "source" array. > > - The "ninja -C _build install" part as to be called within the > "package()" function. You'll also need to setup the destination > directory to "$pkgdir" which is the temporary directory where > "makepkg" builds and bundles the package [12]. See the "package()" > section of the Meson packaging guidelines for more information [13]. > > Overall, I advice you to read closely the three following Arch wiki > pages which should contain most of the information you'll need to > write a proper PKGBUILD for "lemoa-git": > - PKGBUILD [14] > - VCS Packaging Guidelines [15] > - Meson Packaging Guidelines [16] > > I hope this helps :) > Don't hesitate to ask for details or further questions if needed! > > [1] > https://wiki.archlinux.org/title/VCS_package_guidelines#The_pkgver()_functi… > [2] https://github.com/lemmygtk/lemoa/blob/main/LICENSE > [3] https://wiki.archlinux.org/title/PKGBUILD#license > [4] https://github.com/lemmygtk/lemoa#build-dependencies > [5] https://archlinux.org/packages/extra/x86_64/gtk4/ > [6] https://archlinux.org/packages/core/x86_64/pkgconf/ > [7] https://archlinux.org/packages/core/any/base-devel/ > [8] https://wiki.archlinux.org/title/PKGBUILD#makedepends > [9] https://wiki.archlinux.org/title/PKGBUILD#install > [10] https://wiki.archlinux.org/title/VCS_package_guidelines#VCS_sources > [11] > https://wiki.archlinux.org/title/VCS_package_guidelines#Authentication_and_… > [12] > https://wiki.archlinux.org/title/Creating_packages#Defining_PKGBUILD_variab… > [13] https://wiki.archlinux.org/title/Meson_package_guidelines#package() > [14] https://wiki.archlinux.org/title/PKGBUILD > [15] https://wiki.archlinux.org/title/VCS_package_guidelines > [16] https://wiki.archlinux.org/title/Meson_package_guidelines > > -- > Regards, > Robin Candau / Antiz

1 0

Rename AUR package
by Aditya Mahajan 29 Jun '23

29 Jun '23

Hi, I am the maintainer of the AUR package [luametatex](https://aur.archlinux.org/packages/luametatex) which provides the luametatex binary + the context macro package. Recently, a new package named [luametatex](https://archlinux.org/packages/extra/x86_64/luametatex/) was added to extra, which provides the luametatex binary. I realize now that the name of my AUR package is not appropriate and I should have used a more elaborate name (either context-luametatex or context-lmtx). Is it possible to rename the package? Or should I delete the current package and simply create a new one with a more elaborate name? Thanks, Aditya

3 3

llvm 16.x
by Mohan R 24 Jun '23

24 Jun '23

Hi, What happened to llvm 16.x? It was released three months ago. I tried to update the PKGBUILD locally to 16.x, this is what I got https://paste.rs/9R0Mk This issue should have been prevented if we used Source.tar.gz with a single PKGBUILD and should build different packages from this single source (like clang, lld, llvm, llvm-libs etc). Instead, we have three different PKGBUILD files (one for clang, one for lld, one for llvm+llvm-libs). why? I'm a long time arch user, when I started arch, I loved it because of how easy it was to take an official PKGBUILD file for an upstream project, bump the version and get the latest binaries in a single package, it was fairly simple. Now, lot of upstream projects was split into multiple packages (eg: qemu), I can understand the reason for the qemu package split, at least we have a single PKGBUILD to generate multiple qemu packages but this llvm split with multiple PKGBUILD is not helping us to move forward easily. It is stuck at 15.x. I think this is not supposed to be Arch's way. Thanks, Mohan R

3 4

API for AUR?
by Polarian 21 Jun '23

21 Jun '23

Hello, I am not sure if it exists, but if there is an API for the AUR could someone link me to the documentation on it? I am aware there is an rss feed for package updates, but I want to be able to parse information about a package. I assume there isn't and the only way to do it is to clone the repository and parse the .SRCINFO or PKGBUILD file for the information? Any pointers would be useful. Thanks, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

7 10

Conflicting go package naming
by Polarian 19 Jun '23

19 Jun '23

Hello, The naming for go packages seems inconsistent, I can see both go-* and golang-* on official and AUR packages, which am I meant to use as go-* seems to be more popular but according to the guidelines golang-* is what is meant to be used. So which should be used? and why are they differing? is either accepted? I do not know which to use, and I don't want to push a new package until I know, sorry for the noise for such a simple question but better do it right the first time, so I don't need to fix it in the future :) Thank you in advance, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

9 32

package aid - tmpfiles.d problems
by Polarian 15 Jun '23

15 Jun '23

Hello, So I have been attempting to package an irc bot for the aur, because I know a good 3 people or more now who are manually installing it on their arch servers so I decided to attempt to package it. I decided to use gitea as a good reference as it contains the sysusers configuration and also tmpfiles configuration as well. However for some reason when I attempt to adapt it, I get an error, I have not yet pushed the package to the aur and won't until its working so please check it here: https://git.polarian.dev/AUR/irc-uberbot-git I am aware for those rust packagers out there that I have not included "--locked" when fetching the crates, unfortunately upstream has not maintained their dependencies therefore cargo will not build unless "--locked" is removed, I will probably patch this shortly. The following error when I attempt to install this package which I need help in fixing: Detected unsafe path transition /etc/uberbot (owned by uberbot) → /etc/uberbot/config.toml (owned by root) during canonicalization of etc/uberbot/config.toml. error: command failed to execute correctly I do not see why this is happening for me but when I install gitea it works just fine :/ Its probably something really obvious, but I would still appreciate an explanation as I have not worked with tmpfiles very much so I am very naive, so please play nice :P Thanks in advance, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 11

VCS package check - chuncord-git
by Polarian 10 Jun '23

10 Jun '23

Hello, I just want some quick feedback on a package I made a few days ago, this was my first time writing a VCS package, so I want to make sure I have done everything properly: https://aur.archlinux.org/packages/chuncord-git Please let me know if I have done anything wrong. Thank you, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

2 2

Autobot caught in use?
by Polarian 03 Jun '23

03 Jun '23

Hello, I was looking at the AUR today and I have realised a ton of packages with the prefix r-<package name> being updated within a minute of each other, and then found the user to be publishing them: https://aur.archlinux.org/account/BioArchLinuxBot By the name it seems this is a Bot, Anthraxx and Jelle have already discussed how this is not acceptable in a previous thread, see: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/m… A draft has also been submitted on the ArchWiki to set this into stone: https://wiki.archlinux.org/title/Talk:AUR_submission_guidelines#Automation_… Therefore I am bringing this user, and the packages which this has occurred on to the TUs here. I have also attached an image to this email which is a screenshot of the recently updated packages, you can use the rss feeds to back this up as well, it clearly shows that a large number of r packages were updated BY THE SAME USER within the span of 10 minutes. Let me know what you think :) Have a good day, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian(a)polarian.dev

6 7

Questions on JDK naming
by Tommaso Dordoni 02 Jun '23

02 Jun '23

Hello, I recently started contributing to the AUR and I have some questions on JDK naming. I submitted a package called “jdk17-azul-prime-bin” yesterday, but then I realized that other Zulu jdk packages follow a different naming convention, such as “zulu-8-bin”, “zulu-17-bin”, “zulu-20-bin”... For consistency, I requested a merge to rename my package as “zulu-prime-17-bin”. Was that a good decision? In general, what is the best way to name JDK and JRE packages? For instance, how should I name the JDK and JRE Zulu Prime packages for Java 8 to differentiate them? Thank you

2 1

Harrassment?
by Pellegrino Prevete 13 May '23

13 May '23

the "xiota" aur user, I never talked even once as far as I remember, and who somehow came to maintain "gnome-contact-git", defined me "a squatter who has never pushed an update to packages" in an orphan request. I'm notifying him I have reported the issue here. Cheers

3 2

Binary AUR packages when associated packages exist in the repos
by é 12 May '23

12 May '23

I would like to reopen the discussion to delete a package (yuzu-mainline-bin) that exists in [community] (yuzu). As per AUR guidelines [1]: >The submitted PKGBUILDs must not build applications already in any of >the official binary repositories under any circumstances. Check the >official package database for the package. If any version of it exists, >do not submit the package. If the official package is out-of-date, flag >it as such. If the official package is broken or is lacking a feature, >then please file a bug report. > >Exception to this strict rule may only be packages having extra >features enabled and/or patches in comparison to the official ones. In >such an occasion the pkgname should be different to express that >difference. For example, a package for GNU screen containing the >sidebar patch could be named screen-sidebar. Additionally the >provides=('screen') array should be used in order to avoid conflicts >with the official package. yuzu-mainline-bin provides zero extra features or functionality compared to the repo build, at least, no one has yet mentioned such. The name itself refers to yuzu-mainline which is exactly what the repo package is building. As a result I filed a deletion request, but this was apparently rejected [2] with the reasoning that "Yuzu only seems to support binaries", along with some links to comments from upstream as well as a link to a previous thread [3] on the ML from 2021 where this topic was mentioned before. The other point mentioned in the AUR package comments [4] is that the repo version can be out of date frequently. Again, that is addressed in the quote above, still doesn't justify the AUR package. To me, the entire purpose of having the official repos is to have binary builds (presumably done in a clean environment with some minimal source verification), so we don't have to rely on arbitrary developers to have clean environments and only really need to trust the TUs who build that package. If there are issues with a package, they are first reported to Arch maintainers via bug report (this is in accordance with the "please file a bug report" in the quoted passage above). This applies to any package, and yuzu is neither an exception nor special case here. Also the entire point of having distros in the first place is that you have someone (who is usually not upstream) maintaining the package and making sure it slots well into your system. I don't know of any package in any distro where the distro builds the package, but upstream is expected to support it. So why should a specific -bin package exist in the AUR just because upstream is in accordance with decades of tradition? Either way they clearly do not want unnecessary bug reports from inexperienced users [5], so any Arch user reporting a bug with the repo package upstream would be unhelpful to both Arch and Yuzu. Best, éclairevoyant [1] https://wiki.archlinux.org/title/AUR_submission_guidelines#Rules_of_submiss… [2] https://lists.archlinux.org/archives/list/aur-requests@lists.archlinux.org/… [3] https://lists.archlinux.org/pipermail/aur-dev/2021-December/005056.html [4] https://aur.archlinux.org/packages/yuzu-mainline-bin#comment-913540 [5] https://github.com/yuzu-emu/yuzu/blob/master/.github/ISSUE_TEMPLATE/bug_rep…

4 4

Re: Broken Package
by paul.mirkwood 09 May '23

09 May '23

Thanks artafinde for the clarification, and thanks also Polarian, your explanations were worth reading! > As an additional sidenode, if the issue you want to report is that the package is > broken because it can't be built, the maintainer has already highlighted that it is due > to gcc update, and they are awaiting upstream to patch the issue. That was posted 3 > days ago so I assume it is still valid right now as I do not see any recent commits to > the AUR for this package. (not since 2023-04-18) This is indeed what I'm talking about, sorry I should've read the comments on Aurweb before posting here. Since the problem has already been reported, I feel like there's no more to do but waiting if the maintainer is willing to backport the patch. I totally understand that packages may break, I was kind of wondering why upstream would have released a non-compiling version, but I have the explanation now. Have a good day/night, Mirkwood

2 2

Broken package
by paul.mirkwood 09 May '23

09 May '23

Hello everyone, I'm pretty new here so I hope you will forgive me if my question isn't appropriate. I don't want to blame anyone, but is it normal that non -git packages may be broken? (maybe it is, I genuinely don't know) Currently, the mangohud package is broken even though upstream has fixed the bug. The mangohud-git package is also fine. Best regards, and thanks for your answers, Mirkwood ------- Forwarded Message ------- De : paul.mirkwood <paul.mirkwood(a)protonmail.com> Date : mardi 9 mai 2023 à 10:51 PM Objet : Broken package À : aur-general(a)lists.archlinux.org <aur-general(a)lists.archlinux.org> > Hello everyone, > > I'm pretty new here so I hope you will forgive me if my question isn't appropriate. > I don't want to blame anyone, but is it normal that non -git packages may be broken? > (maybe it is, I genuinely don't know) > Currently, the mangohud package is broken even though upstream has fixed the bug. > The mangohud-git package is also fine. > > Best regard, and thanks for your answers, > Mirkwood

3 3