- Aur-general - lists.archlinux.org

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