February 2024 - Aur-general - lists.archlinux.org

AUR Orphan Purge
by arch＠serebit.com 01 Mar '24

01 Mar '24

Hello all, Over the past few days, about 3,000 packages were removed from the Arch User Repository as part of a larger cleanup effort. These packages all fit the following criteria: - No maintainer - Popularity equal to 0.00000 - 3 or fewer total votes - Most recent update before 2019-01-01 If a package that you actively use has been removed, and you are willing to maintain it, feel free to resubmit the package. The Git repositories of all deleted packages are still accessible[1]. Any future large-scale cleanup efforts will be preceded by an announcement on the mailing lists to avoid blindsiding users and maintainers. Best, Campbell Jones [1] https://wiki.archlinux.org/title/Arch_User_Repository#Acquire_build_files

2 1

Re: powertabeditor - request for PKGBUILD review
by Jonas Serych 21 Feb '24

21 Feb '24

Hi, thanks for your comments. Lone_Wolf wrote: > timidity++ and fluidsynth are the 2 most common software midi > synthesizers on archlinux. > I suggest you list them as optdepends . Thanks, I did that (and also checked that it works with both of these). Polarian wrote: > Appreciate it if you paste the PKGBUILD into the email body, and not > attach it. Would also make it easier to quote. Here is the updated PKGBUILD: --8<---------------cut here---------------start------------->8--- # Maintainer: Jonas Serych <jonas(a)sery.ch> pkgname='powertabeditor' pkgver='2.0.0_alpha19' pkgrel=1 pkgdesc="Guitar tablature viewer and editor" arch=('x86_64') url="https://powertab.github.io/" license=('GPL-3.0-only') depends=('boost-libs' 'boost' 'doctest' 'minizip' 'pugixml' 'rtmidi' 'alsa-lib' 'nlohmann-json' 'qt5-base' 'qt5-tools') optdepends=('timidity++: MIDI playback support' 'fluidsynth: MIDI playback support') makedepends=('cmake') source=("https://github.com/powertab/${pkgname}/archive/refs/tags/${pkgver//_/-}.tar…") sha256sums=('318e14370bd60670dadfe70d2f124d817d51017ec13011f577080633d83f41d4') build() { cmake -B build -S "${pkgname}-${pkgver//_/-}" \ -DCMAKE_BUILD_TYPE='None' \ -DCMAKE_INSTALL_PREFIX=/usr cmake --build build } check() { ctest --test-dir build --output-on-failure } package() { DESTDIR="$pkgdir" cmake --install build } --8<---------------cut here---------------end--------------->8--- Any other things to improve? Or can I put it to AUR? Best, Jonas Serych

1 0

Moving from binary to from source, can we delete bin version
by Mek Yt 20 Feb '24

20 Feb '24

Hi, I first created AUR packages from binary file (`dagu-bin`, `oathkeeper-bin` and `kratos-bin`) but it is best to build them from source. I recreated them from source, I would like to know if it is possible to delete the binary version. I would like to maintain only the one from source. I could disown and wait for them to disappear but it looks cleaner to directly delete them and direct potential users to the correct/maintain one. Thanks, Mek Yt AUR to delete: https://aur.archlinux.org/packages/dagu-bin https://aur.archlinux.org/packages/oathkeeper-bin https://aur.archlinux.org/packages/kratos-bin PS: - `oathkeeper-bin` and `kratos-bin` use `ory-` namespace now (`ory-kratos` and `ory-oathkeeper`) - `oathkeeper-bin` and `kratos-bin` where duplicate (with service files) of orphan `ory-oathkeeper-bin` and `ory-kratos-bin`

4 3

Is including GPG keys in an AUR package for verifying sources a good idea?
by Wilhelm Schuster 20 Feb '24

20 Feb '24

Hi, I maintain the AUR package for wget2 [0] (which has `validgpgkeys()` populated) and have recently been contacted by a user that has trouble with GPG signature verification when building the package in a Docker container (using aurutils apparently). Their first suggestion was for me to drop the validpgpkeys section to make it easier for them to build the package. This is not something I'm willing to implement as that means downgrading security for other users of the package. makepkg provides an escape hatch for users who don't care about signature verification via the `--skippgpcheck` flag. Their second suggestion was for me to add the GPG public keys directly to AUR package. My first thought was that this is also not a good idea, but I'm not sure I can come up with convincing arguments. My reason against it is, that the PGP key allows for a user of my PKGBUILD to verify that I only include sources which have been signed by the maintainer of the software. As packager, I can control the source and hashes for a package, so if I want to use a malicious source, I can just update the hash to match, but I can't easily change the upstream signing key. However, if the users relies on the key included with the package, then I could use my own malicious key, so the user should compare the key with upstream sources anyway. On the other hand retrieving keys from the keyservers can be a crapshoot. I certainly have been bitten by that brittle infrastructure in the past, and having a copy of the key can alleviate that. That seems also the reason, why Arch proper has started including copies of GPG keys with their packages (see for example glibc [1]). This has been codified in RFC0011 [2] and is managed via the `export-pkgbuild-keys` script included in devtools. There doesn't seem to be any discussion of downsides of this approach in the RFC and accompanying Merge Request. Users, who wish to make sure that the used GPG keys are the ones published by upstream can always ignore the included key files and grab the keys directly from the keyservers. Do you think including GPG keys with AUR packages to make it easier for some users is a good idea? Or should they just use `--skippgpcheck`? Are there any glaring issues I'm missing here? Do you know of AUR packages that include the GPG keys for source verification similar to what Arch packages do? [0]: https://aur.archlinux.org/packages/wget2 [1]: https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/tree/2.39… [2]: https://rfc.archlinux.page/0011-store-source-signing-keys/ Cheers, Wilhelm.

11 17

powertabeditor - request for PKGBUILD review
by Jonas Serych 19 Feb '24

19 Feb '24

Hi, this is my first time creating a PKGBUILD. I tried to follow the guidelines and the recommended practices for cmake packages, but not sure I didn't miss something. Thanks for any suggestions. I checked that it builds in clean chroot. The software seems to work well, except for JACK server not running error (for playback of midi). I am not sure if this should be somehow solved in the PKGBUILD, or if it should be left to the user. When I run qsynth alongside the powertabeditor the playback works just fine. Somehow setting up timidity++ daemon would work too, I guess. Best regards, Jonas Serych

3 3

Package maintainer for vinegar-git & vinegar is malicious.
by sewn 17 Feb '24

17 Feb '24

Hi. I am the primary developer of Vinegar (sewn(a)disroot.org, see commits and members of GitHub organization vinegarhq with repository vinegar). The AUR package maintainer for my software has defaced me [1], my software, and patched Vinegar maliciously [2]. I have not appreciated the direct insults at me. They have also added a .install hook file to direct installers of the package to another piece of software, which is biased and uncalled for. Additionally, i have asked the maintainer various times to remove the insult directed at me, and to update the package - to which they have not responded for days. They have then maliciously modified the description and changed the code of Vinegar to remove a feature which was announced in our communication channels. I would like to request an urgent removal of the package maintainer DodoGTA from maintaining the AUR packages for my software, they cannot be trusted and are malicious. [1]: https://aur.archlinux.org/cgit/aur.git/commit/?h=vinegar&id=2abcbe54f64c748… [2]: https://aur.archlinux.org/cgit/aur.git/commit/?h=vinegar&id=aa3b4dcad2a67e4…

2 2

tor-browser depublication and replacment
by Zehka 10 Feb '24

10 Feb '24

Hello everyone, Today i noticed by chance that the aur/tor-browser package is gone and replaced by extra/torbrowser-launcher That worries me a bit because as a user of an aur helper i did either not receive or see a notice about that so i stayed on version 12.5.3-1 that was the last one on aur without noticing it was getting outdated. I just wonder if that's common practice? This case is particularly unlucky in my eyes because tor browser has a special role in the security concepts of many people and because the new package is spelled torbrowser-launcher a search in both databases with "yay tor-browser" in september only showed me the aur result. So i just wanted to ask if there is any possibility to make that transition better because i assume i'm not the only user out there who didn't notice. And more thought that i had even though i didn't want to check in order to cause unnecessary chaos: Is the name tor-browser now blocked in aur or could anyone just upload a malicious package to that name and until somebody notices that everyone who has the old tor browser and uses an aur helper for updates gets a malicious version? Regards Zehka

6 5