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

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

Addition of Support Staff - wahrwolf
by Anton Hvornum 18 Jan '24

18 Jan '24

Hi! I'd like to start the on-boarding process for wahrwolf[1] as a support staff and mirror admin. I hereby sing off as a sponsor with my reasoning below. Wahrwolf, or Vincent, has shown great dedication and engagement with myself and other staff. Vincent has also been a integral part of making progress on several Mirror improvements such as: * A new Mirror definition RFC[2] * A new mirror tooling called 'mirrorctl'[3] (work in progress, but work being done nevertheless) * Several on-line meetings regarding mirrors and mirror management Vincent also graciously hosted 2023's Arch Linux Summit. Overall my experience with Vincent has been good and I think Vincent would make a great addition to the support staff and especially the mirror admins. [1] https://gitlab.archlinux.org/wahrwolf [2] https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29 [3] https://gitlab.archlinux.org/archlinux/mirrorctl

1 0

changing name
by james smith 18 Jan '24

18 Jan '24

when you open the aur page it says "Some packages may be provided as binaries in [community]." That should be changed to say "Some packages may be provided as binaries in [extra]."

2 1

What to do with oh-my-zsh-git, a package people might not know how to start using
by Aaron Liu 14 Jan '24

14 Jan '24

Greetings AUR users, (hmm I sound like an alien) This package on the AUR called oh-my-zsh-git has been occasionally flagged by people who do not understand that you have to add a line to zshrc to start using it. I suggested a clearer and less suspicious postinstall message, which the package's current maintainer and another user in the comments denied as Arch users should know their system and inspect the PKGBUILD. The package's maintainer then suggested a counterproposal of shipping a symlink of /usr/bin/ohmyzsh-install to "install.sh", which I presume is the name of the official install script. I don't think we should symlink that to oh-my-zsh-something. At most, it should echo the instructions. Plus, I think this is a worse solution than simply putting a message in the postinstall on both merits and practicality. No matter how much people try it, there will be less people who try to tab-complete than those who read the postinstall messages, and nowhere in "know your system" do I see "blindly try tab-completions"; not to mention this package's name is oh-my-zsh-git, not ohmyzsh-git. Yes, ohmyzsh is the official name, but I don't expect users to know that. We cannot rely on users having hyphen completions enabled. This entire exchange occurred in the comments of that package. What do you guys think? -- Cheers, Aᴀʀᴏɴ

2 1

wiringX-git PKGBUILD Review Request
by David C. Rankin 09 Jan '24

09 Jan '24

All, I'm thinking of adding a wiringX-git package to AUR and wanted to put the PKGBUILD out for comment and help. It's a simple tiny package used for embedded development to manipulate GPIO pins. What I've cobbled together is: pkgname=wiringX-git _gitname=wiringX pkgver=251.54030cd pkgrel=1 pkgdesc="wiringX is a modular approach to several GPIO interfaces." url="httpx://wiringx.org/" arch=('i686' 'x86_64' 'armv6h' 'armv7h' 'aarch64') license=('MPL-2.0') makedepends=('git' 'cmake') source=('git+https://github.com/wiringX/wiringX.git') md5sums=('SKIP') pkgver() { cd "${srcdir}/$_gitname" echo $(git rev-list --count HEAD).$(git rev-parse --short HEAD) } prepare() { cd "${srcdir}/$_gitname" mkdir -p build cd build msg2 "Cmake..." cmake .. } build() { cd "${srcdir}/$_gitname/build" msg2 "Building wiringX..." make } package() { cd "${srcdir}/$_gitname/build" msg2 "Packaging wiringX..." make DESTDIR="$pkgdir/" install mv "$pkgdir/usr/local/"* "$pkgdir/usr" rm -r "$pkgdir/usr/local" install -Dm644 "${srcdir}/$_gitname/LICENSE" "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" } And it produces: $ pacman -Qpl wiringX-git-251.54030cd-1-x86_64.pkg.tar.zst wiringX-git /usr/ wiringX-git /usr/include/ wiringX-git /usr/include/wiringx.h wiringX-git /usr/lib/ wiringX-git /usr/lib/libwiringx.so wiringX-git /usr/sbin/ wiringX-git /usr/sbin/wiringx-blink wiringX-git /usr/sbin/wiringx-interrupt wiringX-git /usr/sbin/wiringx-read wiringX-git /usr/share/ wiringX-git /usr/share/licenses/ wiringX-git /usr/share/licenses/wiringX-git/ wiringX-git /usr/share/licenses/wiringX-git/LICENSE We may also want to include the static library. Thoughts? -- David C. Rankin, J.D.,P.E.

6 19