Arch Linux User Repository

@lucaswerkmeister, there's no hard and fast rule, but it's generally considered better to always build each time in a clean environment, so that artifacts from the previous run don't mess with the current build. I've encountered and heard of multiple times that that occurred.

Also, in this case specifically, since we're building the newer version's wheel, imo it doesn't make much sense to keep the older version's wheel around, we are building the newer version, after all. If one wanted the older wheel version, one could always go to the previous version's PKGBUILD and build again.

ngl, I've set my build-dir to /tmp/makepkg and I've set my AUR helper to 'CleanAfter' meaning I always clean-build since so long ago, I forgot the makepkg default behaviour.

But anyway, as stated in my previous comment's edit, the 2.5.0-2 pkgrel bump should ensure that no such errors occur again.

I don’t really follow (who’s not supposed to keep the stale wheels lying around? it’s makepkg’s default behavior without -c/-C…), but alright.

@lucaswerkmeister, I'm not sure if your suggested fix specifically is a good fix to the underlying issue, because you're technically not supposed to keep the stale wheels lying around, when building a new version. I can push an pkgrel bump that cleans up anything that's not supposed to be there.

Edit: 2.5.0-2 pushed that does exactly that.

I just got this error while trying to update the package:

==> Starting package()...                                                                                                                                                                                                                                                                             
usage: python -m installer [-h] [--destdir path] [--prefix path] [--compile-bytecode level] [--no-compile-bytecode] wheel                                                                                                                                                                             
python -m installer: error: unrecognized arguments: dist/git_review-2.5.0-py3-none-any.whl                                                                                                                                                                                                            
==> ERROR: A failure occurred in package().                                                                                                                                                                                                                                                           
    Aborting...                                                                                                                                                                                                                                                                                       

I assume this is because I still have a previous wheel lying around in the source directory:

$ ls src/git-review/dist/*.whl
src/git-review/dist/git_review-2.4.0-py3-none-any.whl  src/git-review/dist/git_review-2.5.0-py3-none-any.whl

Consequently, python -m installer --destdir="$pkgdir" dist/*.whl expands to a faulty command with an extra argument. Suggested fix:

diff --git i/PKGBUILD w/PKGBUILD
index f9a2988463..279e80be05 100644
--- i/PKGBUILD
+++ w/PKGBUILD
@@ -54,6 +54,6 @@ build() {

 package() {
   cd $pkgname
-  python -m installer --destdir="$pkgdir" dist/*.whl
+  python -m installer --destdir="$pkgdir" dist/git_review-"$pkgver"-py3-none-any.whl
   install -Dm644 git-review.1 "$pkgdir"/usr/share/man/man1/git-review.1
 }

@lucaswerkmeister, I can't reproduce your problem, it downloads fine here for me, but I guess I can switch to get the source from git tags, shouldn't be a difference in the overall package.

I haven’t been able to download the 2.4.0 tarball from Gitea since the 2.4.0 release came out (both when building the package and when trying to open it manually); getting the sources from Git instead seems to work:

diff --git a/PKGBUILD b/PKGBUILD
index c31b17afc0..ef41a67d75 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -13,9 +13,9 @@ license=('APACHE')
 depends=('git' 'python-requests')
 makedepends=('python-pbr' 'python-build' 'python-installer' 'python-setuptools' 'python-wheel')
 #checkdepends=('java-runtime=11' 'libcups' 'openssh' 'procps-ng' 'python-stestr' 'python-mock')
-source=("$pkgname-$pkgver.tar.gz::https://opendev.org/opendev/git-review/archive/$pkgver.tar.gz"
+source=("git+https://opendev.org/opendev/git-review.git#commit=b65c3c201c0a495f19cc4757f969119f8a65385a"  # 2.4.0 tag
         'https://gerrit-releases.storage.googleapis.com/gerrit-3.4.4.war')
-sha512sums=('acbfde06a03776494f1506355d837111305c45cd9424aed4b852ebb5c496a83184eb7d515425b48317d9e0858021f8bd78b6c2184fc1d4655d00ca2ade244532'
+sha512sums=('SKIP'
             'bb7d54585d16a3a4c2660d1e4cdfe193164f4f18e24a2d5df147936023a237332b1c1e1e21198c2f4216935e37fd3dc1494a0c1aa41c6dcf6b966f19c9f976ce')

 prepare() {

@bkazmierczak, @buovjaga, Noted, and they have been disabled since the last pkgrel bump, i.e. 2.3.1-3.

@mistersmee I agree with @buovjaga on this. The tests take a significant amount of time and load the CPU to the point older machines are unusable while an upgrade is ongoing.

@buovjaga, you can disable them, if you want to, of course, by commenting the corresponding lines out of the PKGBUILD before building, but I don't think it's a good idea to remove them, the tests have been there since before I started maintaining this package and probably there for a good reason.

Is it necessary to run the tests as part of the build? It's quite expensive as they run for a couple of hours and leave behind dozens of hanging Gerrit instances that take 100% of CPU.