- Aur-general - lists.archlinux.org

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 11 Feb '24

11 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

My account suspended (MarsSeed) without reason - which PM abused their power?
by Marcell Meszaros 28 Jan '24

28 Jan '24

Dear PM's, Please kindly look into which PM chose to abuse their power to suspend my account without any reason. Please also kindly sanction such unacceptable behavior by said PM. Thank you very much. Yours, Marcell Mészáros (MarsSeed)

11 39

Postorius configuration help
by Georg 28 Jan '24

28 Jan '24

Hi list, I'm looking for a good description for postorius configuration. The Arch wiki is unclear to me, and the mailman documentation points to postorius.org configuration, who then points to another mailman doc providing little info on the actual configuration. Long story short, I'm failing to set up postorius so I can create users and let them log in. It would be highly appreciated if someone proficient in this topic is willing to walk me throuh. I'd then amend the wiki for more clarity. Thanks in advance Georg

1 1

Comment spam
by Mark Wagie 22 Jan '24

22 Jan '24

I've been going through my 400+ AUR packages updating the license to match SPDX license requirements. xiota has decided a pkgrel bump is required if one updates the license. He has begun spamming the same comment on 9 of my AUR packages so far. I've already told him to stop here: https://aur.archlinux.org/pkgbase/qtscrcpy#comment-952888. I imagine he's doing it on other packages as well if he's doing it for mine. This is not the first time someone has complained about xiota's behavior. I've had quite enough of it. His email is private, so I can't CC him here. Sent with [Proton Mail](https://proton.me/) secure email.

4 4

Re: xen moving to [extra]
by Sam Mulvey 22 Jan '24

22 Jan '24

On 1/21/24 22:19, Daurnimator wrote: > There's not really any ongoing discussions. > > For what it's worth, my personal motivation is to package qubes guest > packages into the Arch [extra] repo, of which qubes-libvchan will > depend on shared library from xen > (https://github.com/QubesOS/qubes-core-vchan-xen/blob/6427a74060dccf0baa34e3…) > > As an official package, it wouldn't have build options like your > current AUR package. So I think you'd have to maintain an AUR > xen-stubdom package separately. This package is currently more about being a hypervisor rather than being a guest of one, and includes bootable kernels and infrastructure for such. If this package is going to make it to official status with this functionality, the qemu package would have to be modified to support xen and likely a subpackage for it. The Xen codebase will build it's own copy of qemu unless told otherwise, and until a couple years ago that was what the PKGBUILD did. I eventually had to spin off qemu into it's own package to avoid having to build an increasingly aging version of qemu with it's increasing number of compiler errors. That package is here: https://aur.archlinux.org/packages/xen-qemu Without that functionality, it would be necessary to continue maintaining these packages in AUR. In which case I would make effort to work with what exists in the repos. Previous maintainers have attempted to rid themselves of the stubdom functionality, but as of now it's the only consistent way to allow GPU pass-through. I personally do not use this functionality, but I maintain it for those that do with an eye towards deprecating it as soon as newer PVH infrastructure is in place. That should be very soon. For completeness, there's also the xen-pvhgrub package which is a copy of GRUB that runs under PVH domUs, allowing us to boot using Arch's standard kernel packages in that context. > > Are you able to share why OCaml was disabled in your AUR package > recently? > (https://aur.archlinux.org/cgit/aur.git/commit/PKGBUILD?h=xen&id=e9890b16a54…) > Sure! The immediate cause was that the ocaml bindings were not building properly. It was easier to remove them than try to repair them, especially as I have zero knowledge of ocaml. There is some nuance to that, however: - The OCaml bindings are generally not well maintained upstream, afaik - The serially previous maintainers were working towards a minimum viable build, which I've tried to respect as much as I can - The flag to disable OCaml support was already in the ./configure stanza, but that flag had since been renamed - Apparently, no one was using it. I hope that helps explain things! -Sam

1 0

xen moving to [extra]
by Sam Mulvey 22 Jan '24

22 Jan '24

Hello! I've been maintaining xen and associated packages for a few years. This relative evening the package got the following comment: https://aur.archlinux.org/pkgbase/xen#comment-952940 I think it'd be a great idea to include xen in [extra], and I'm wondering if there's some way I could be of assistance or part of any ongoing discussion about it, if any. Thanks! -Sam

2 1