- Aur-general - lists.archlinux.org

RFC / RFO: Extra (CI) files in AUR packages
by Knut Ahlers 16 Sep '22

16 Sep '22

Hey there, I'd like to fetch some comments / opinions regarding maintaining AUR packages with the help of automated build systems. I do maintain several packages in the AUR containing the typical files as `PKGBUILD`, `.SRCINFO`, files referenced in the `source()` section and a special script `update-version.sh`. This script is not mentioned in the PKGBUILD and not used during the build process. It contains the required steps to figure out the latest version of the package and to patch the PKGBUILD. This script is a) used to document how the package is updated and b) is used by my CI system (atm Jenkins) to check for updates and update the package. (Extra steps to verify the package is still building fine before doing any update are common to all packages and are executed after this package-specific script.) For most of my packages there were no complaints about this and users seem to be happy to get the updates usually delivered within an hour after release. Though in one package (librespeed-cli) I got two comments asking me to remove that script. Now I found no explicit statement in the package / AUR submission guidelines against this. Therefore I'd like to ask other maintainers / TUs for your opinions: Are you strictly against adding a script which documents / is used for the update? Is it fine to keep it there? Shall it be removed though doing no harm? Cheers Knut -- Knut Ahlers Software & Infrastructure Developer Web & Blog: https://ahlers.me/ GPG-Key: 0xD215AD7D (https://knut.in/gpg)

2 1

Re: [aur-general] Why was xenia-git orphaned immeditately?
by Sandy Carter 11 Sep '22

11 Sep '22

Glad to hear it wasn't intentional. I find it very strange indeed that the system accepted the request. I don't remember it being flagged OOD but that's on me. Would you mind orphaning xenia-git so I can pick it up again? It would require some rebasing of the patch branches. On Sun, Sep 11, 2022 at 7:36 PM Alessandro Marchioro < marciozgaming(a)gmail.com> wrote: > Hi, I had the same question, I was trying to get an update to the package > without orphaning but by clicking the link it was automatically orphaned by > the system in no time, instead of respecting the time as per the page > suggestion, is this because it was out of date for over a year? > > I wasn't trying to get access as a maintainer other than make it build > again with a simple patch of the PKGBUILD, due to the fact that I was > trying out the emulator with the latest builds on Arch and saw it on a bad > state. > > I too wanna be sure that you are the maintainer, it wasn't my intention in > being the one for this package. > > Hope you'll understand, > > Alessandro > Il 12 set 2022, 01:30 +0200, Sandy Carter <bwrsandman(a)gmail.com>, ha > scritto: > > Hello, > > I used to maintain xenia-git [1] and have since its creation. I am also > the author of the Linux threading, windowing, debug and other patches that > the package uses. > > At *19:20:00 UTC* today, an orphan request was submitted and immediately > orphaned by user ilbuonmarcio. The user made no attempt to contact me about > the issue either by email or in the comments. If they had, I would have > responded as I usually do to issues in my packages. > > I am active on AUR and have been for over 10 years now. I usually can fix > a package issue in a day to a week. > > According to the arch wiki: > > Orphan requests will be granted after two weeks if the current > maintainer did not react > > I was not given the time to react as it is now a few hours later. > > I would like to request this orphaning be undone and steps can be taken to > avoid this happening again. > > Thank you, > -- > Sandy > > [1] https://aur.archlinux.org/packages/xenia-git > >

1 0

[aur-general] Why was xenia-git orphaned immeditately?
by Sandy Carter 11 Sep '22

11 Sep '22

Hello, I used to maintain xenia-git [1] and have since its creation. I am also the author of the Linux threading, windowing, debug and other patches that the package uses. At *19:20:00 UTC* today, an orphan request was submitted and immediately orphaned by user ilbuonmarcio. The user made no attempt to contact me about the issue either by email or in the comments. If they had, I would have responded as I usually do to issues in my packages. I am active on AUR and have been for over 10 years now. I usually can fix a package issue in a day to a week. According to the arch wiki: > Orphan requests will be granted after two weeks if the current maintainer did not react I was not given the time to react as it is now a few hours later. I would like to request this orphaning be undone and steps can be taken to avoid this happening again. Thank you, -- Sandy [1] https://aur.archlinux.org/packages/xenia-git

1 0

[aur-general] Compiling with CMake
by Guilhem Saurel 08 Sep '22

08 Sep '22

Hi, In AUR, there are many packages with an old-school > mkdir build && cd build > cmake -DCMAKE_INSTALL_PREFIX=/usr .. > make Other packages say they require ninja and use > mkdir build && cd build > cmake -DCMAKE_INSTALL_PREFIX=/usr -G Ninja .. > ninja But I think we should let the end user choose if they want make or ninja, by letting them configure their CMAKE_GENERATOR environment variable¹ Currently if someone has CMAKE_GENERATOR=Ninja in their environment, many AUR packages in the first category will fail, because eg.: > […] > -- Configuring done > -- Generating done > -- Build files have been written to: /home/nim/.cache/paru/clone/octomap/src/octomap-1.9.8/octomap/build > make: *** No targets specified and no makefile found. Stop. And on the other hand for the second case, packages say they require ninja while they would work as well with make. Therefore I think we should ask CMake to compile, no matter which generator is available on the machine and/or was chosen by the user, with: > mkdir build && cd build > cmake -DCMAKE_INSTALL_PREFIX=/usr .. > cmake --build . Or even better > cmake -B build -S . -DCMAKE_INSTALL_PREFIX=/usr > cmake --build build Any opinions ? Should we put that on the wiki² ? Or write an RFC, like ³ ? Cheers ! Guilhem, aka. Nim65s ¹: https://cmake.org/cmake/help/latest/envvar/CMAKE_GENERATOR.html ²: https://wiki.archlinux.org/title/CMake_package_guidelines ³: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/10

2 2

[aur-general] TU Application - blakkheim
by T.J. Townsend 06 Sep '22

06 Sep '22

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello. I'd like to apply to become a trusted user. I started using Arch around 2009 when we still had the curses installer, rc.conf, hal... the good old days. I left at some point and came back as a full-time user about three years ago. You can find me on IRC under the name blakkheim, usually in #archlinux-security since that's my main area of interest. I'm the maintainer or co-maintainer for a few OpenBSD-derived packages in the AUR: openiked, rpki-client, and openbgpd. I've been involved with OpenBSD since 2014 and became a project committer there in early 2016. In the last two years I've submitted just over 150 patches to the Arch bug tracker: https://bugs.archlinux.org/index.php?opened=32638&status[]= Some community packages I'd like to co-maintain are openntpd, opensmtpd, libressl, sndio, mandoc, signify, dnscrypt-proxy, bmake, scrot, firejail, xcalib, mktorrent, parallel, ncmpcpp... And more (frankly, lots more) in the core/extra repos if that option opens up in the future. I keep up with many software projects via their mailing lists and RSS/atom feeds. If I'm accepted, one of my goals will be to get missing security fixes into Arch's repository shortly after their upstream release. The sponsors of my application are dvzrv, kpcyrd, and anthraxx. (yep, three) -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQRUwf0nM2HqUUojd5Pylr3lA2jGzgUCYvuMwwAKCRDylr3lA2jG zvh9AQDOvEQbJdu3vfoPUY+Q+amtiwOatfD7nHje2XcviXF82gD/SL2aw0SNm9/Q sxcT+MltS0EoPTyR+OwOU9lHkpyuFQw= =4mzL -----END PGP SIGNATURE-----

9 16

[aur-general] My package is being flagged as out-of-date falsely by a specific user repeatedly
by Reza Jahanbakhshi 06 Sep '22

06 Sep '22

Hi, This user https://aur.archlinux.org/account/bittin is flagging https://aur.archlinux.org/packages/mesa-git as out-of-date repeatedly. I asked him not to do so in the package page comments section. I also tried to email him directly and explained to him that this is a git package and it's not necessary to update it with every version. But, the package is still being flagged. What should I do? Thanks,

2 1

[aur-general] Spam in AUR comments
by hawkeye116477＠gmail.com 31 Aug '22

31 Aug '22

Welcome, I'd like to report spam in AUR comments at aur.archlinux.org/packages/waterfox-classic-bin#comment-879702, written by user Shijrat62. (I haven't previously subscribed, so I'm sending again)

2 1

[aur-general] package splitting
by Thomas 29 Aug '22

29 Aug '22

Hi, I have 2 questions: 1) when is it allowed and / or good practice to split multiple packages by 1 PKGBUILD? For example I have created a package which pulls 3 debian packages and creates 3 Arch packages from it. I want to do that in 1 PKGBUILD by package splitting. Is that a good idea or should this avoided (if so why..)? 2) I found a bug in package splitting regarding the variable "pkgdesc" - when in AUR: it simply gets ignored when used in package_<pkgname> functions. Example: https://aur.archlinux.org/packages/systemd-libs-git -> Line 220: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=systemd-git#n220 It should work though according to: https://archlinux.org/pacman/PKGBUILD.5.html#_package_splitting It seems to work when in the regular package database - which is using the same PKGBUILD as the AUR ofc: https://archlinux.org/packages/core/x86_64/systemd-libs/ -> Is this the right place to report an issue like that? Thanks in advance Thomas

4 4

[aur-general] ungoogled-chromium-bin package submission
by networkException 27 Aug '22

27 Aug '22

Hello, I maintain / administer the ungoogled-chromium project and its Arch Linux packaging. Last year I asked[1] about the submission rules for an ungoogled-chromium-bin package as previous packages have all been removed. Since then our GitHub Actions workflow for releases has been adjusted to hopefully comply with the requirements[2]. At the moment updates will be handled manually by me but the code for automating this already exists. Now it has come to my attention that the ungoogled-chromium-bin package is blacklisted due contentious violations by people not affiliated with the project itself. Would it be possible to remove this blacklist entry to be able to submit our binaries? I imagine that providing an official package will also stop people submitting packages with workaround names. Kind regards, networkException 1: The previous conversation regarding this topic https://lists.archlinux.org/pipermail/aur-general/2021-September/036581.html 2: The commit updated our release workflow https://github.com/ungoogled-software/ungoogled-chromium-archlinux/commit/8…

2 1

[aur-general] Using the bug tracker to patch outdated packages (was: TU Application - blakkheim)
by Claudia Pellegrino 25 Aug '22

25 Aug '22

Hi Leonidas, > What stops you from opening bug report and submitting patches for those > now without being a TU? If these are in core/extras your options would > be the same as you have now, right? Wait, is this actually a thing? As a non-TU, one thing that has deterred me from using the bug tracker to submit patches for outdated packages is this warning: > Do NOT report bugs when a package is just outdated, or it is in the AUR. > Use the 'flag out of date' link on the package page, or the Mailing List. followed by: > REPEAT: Do NOT report bugs for outdated packages! and similarly, on the wiki: > Reasons for not being a bug > […] > A package which is not-up-to-date. Use the Flag Package Out-of-Date feature on Arch's packages website. That’s a total of three warnings. Enough for me to decide to not take chances. Your suggestion seems to contradict those warnings though. What am I missing? Regards Claudia (aka Auerhuhn)

3 2