Arch Linux User Repository

I already advised you to use git if you don't have the time for hash thing. You may take a look at gotop-git (https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gotop-git) and just use stable tag instead of HEAD.

Which tutorial should I follow? The one I found and used was saying to use makepkg -g.

This confuses me; the binaries and the archives containing them are built by an automated CI system. So, what am I supposed to be not trusting here? I don't understand the "accepting whatever you just downloaded" comment.

Signing the packages is easily done, but harder to automate. What I'm having difficulty understanding is that what I think I'm hearing is that someone is actually advocating an entirely manual process for building packages, and that can't be right.

I think a pointer to a best-practices page would be great. Keep in mind that I'm not only upstream, but I'm also trying to help multiple distributions, of which Arch is only one. The fact that I'm an Arch user myself does not lessen the amount of work necessary to package a release, so while I'm happy to follow best practices, it needs to be automate-able.

@serxxx well, it's not recommended to use makepkg -g to calculate hash, especially if you are the upstream. The hashes should be calculated independently, otherwise you are accepting whatever you just downloaded.

If you don't care enough for calculating hashes upstream then you may switch to git sources instead of tarballs which use hashes internally. It would be best to sign tags/tarballs with gpg.

See also https://git.archlinux.org/pacman.git/commit/?id=21af79860403f9120d2c0412a95ec97d06368e11

@egrupled There was no decision; it's what makepkg -g and makepkg --printsrcinfo produce by default in the official @latest archlinux container. https://hub.docker.com/_/archlinux. I replaced a hand-rolled script with an official tool, and accepted what it generated.

Why?

@serxxx what was the reason behind changing sha256sum to md5sum in https://aur.archlinux.org/cgit/aur.git/commit/?h=gotop&id=0e5001a04dd82b1f41a54f7f494484a51c57369f ?

Thanks folks. I appreciate the smooth transition.

Yeah that sounds fair. It would be good then to switch the upstream in all of the gotop packages. It may also be good to add serxxx as a co-maintainer of the packages. I can add him to gotop-bin but he'll have to request co-maintainership for the other packages.

I've looked into this a bit and don't see any reason this package shouldn't be updated to follow @serxxx's fork. The original upstream is clearly deprecated, and clearly that fork in particular is where development activity is and I don't see any reason not to trust it. I think keeping this package name but pointing to the fork as the current upstream is the best outcome. I would only recommend a new package name if the original upstream might keep putting out releases which does not seem to be the case here.

@serxxx I'm not really sure what the AUR policy is about changing the upstream of a package. It might be fine but I think it would be best if we got an expert opinion about it first, since the recommended approach might be to actually create a different package for the fork.

@FabioLolix, cjbassi has stopped working on gotop and has deprecated his (original) fork of the project. I'd like to change the upstream URL on this package to an actively maintained fork, and change the package maintainer. While I've been using Arch for a number of months, I haven't contributed to Aur, so what's the process here?