Arch Linux User Repository

Awesome, I've tried my reproduction method and it looks like it fixed that, so I think it's a good bet that it'll work in general. Thanks for being so responsive on this!

Yes, of course, thanks. You're right. I had never noticed that folder/filename change pattern.

I've uploaded a new PKGBUILD that I believe should prevent the issue from occurring again.

Also, here's a way to reproduce the problem. In an empty directory:

git clone https://aur.archlinux.org/plex-media-player.git
cd plex-media-player
git checkout 6d9fda0623e768cabd3e32997712a62bb5701d7a # 2.45 commit
makepkg # Build to get the previous sources
git checkout e9c4976314dae7e2d4057b78f5b2d07e893df09b # 2.46 commit
makepkg # Build without cleaning previous sources

In the second makepkg you should see the following logs:

  -> Found web-client-desktop-3.104.2-1b12c68.tar.xz
  -> Found web-client-desktop-3.104.2-1b12c68.tar.xz.sha1

Indicating it thinks it already has those sources, so it doesn't need to re-download them. Then later on it will fail on the validity check of both those files.

I think you're missing the fact that the URLs of the tarballs are changing, even though their file name is not. These are the checksums of the web-client-desktop tarball for the current and previous PKGBUILDs:

 curl https://artifacts.plex.tv/web-client-pmp/156-e1595151b12c68/web-client-desktop-3.104.2-1b12c68.tar.xz -o desktop-2.46.0-1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 3621k  100 3621k    0     0  3610k      0  0:00:01  0:00:01 --:--:-- 3610k

sha512sum desktop-2.46.0-1 
383c1ca84e537677ec8f07ac2e2c908437ae165cf87e1893affd60b2dd6679bf2ffde1d7cdd978357da53b4aa09f23caed07a6cb5aaad71976bd2350f72d4268  desktop-2.46.0-1

curl https://artifacts.plex.tv/web-client-pmp/153-f23008b1b12c68/web-client-desktop-3.104.2-1b12c68.tar.xz -o desktop-2.45.0-1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 3624k  100 3624k    0     0  3365k      0  0:00:01  0:00:01 --:--:-- 3365k

sha512sum desktop-2.45.0-1 
afc8aba11de16e3a7f8f2be79281106842e0d5a9a614033f5423513ad5fbdb7ae11d5a2476998f2de033df7db7643b5ec3773cb1303b20abca9c326447da8d0b  desktop-2.45.0-1

As you can see, the URLs have different paths, though the end part, which gets treated as the filename, is the same. The files themselves are different, and they each match the (different) checksums in the PKGBUILDs for those versions.

I'm not sure that's the problem. I've previously checked the upstream files against the checksums I put in the PKGBUILD-file after people reported checksum mismatches, and my original checksums still matched. I also did it a few minutes ago before updating the PKGBUILD from 2.45.0 to 2.46.0 based on your report, and the checksums I had put in the PKGBUILD definitely still matched the files that were downloaded using makepkg. As far as I can tell, the files on the server didn't change since i put the checksums in the PKGBUILD.

@degeberg, the failed checksums happens because the contents of the tarballs sometimes change while the file name does not. I presume this is because there are two different sources (web-client-tv and web-client-desktop) that are probably managed in separate version control repos, and when either one changes the other one's name does not. This wouldn't be a problem except that apparently the contents do change slightly (probably there's some sort of time dependency when generating the tarballs). This causes an update where one of the sources has the same name as a previous update, but a different checksum.

That causes a problem with AUR helpers that cache previous sources by filename. They don't download the new file, and when makepkg does the validation the old file doesn't match the new checksum.

My patch (linked below, but here it is again: http://ix.io/23lz) fixes this by incorporating the name of the overall build ID in the downloaded file names. This means that when a new build is made, the helper will look for a unique name, not find it, and download it, ensuring it matches the checksum.

Edit: actually, thinking about it, it's makepkg that does the downloading, right? So it's actually a problem with AUR helpers that support caching at all: i.e. they keep previous sources and allow makepkg to use them if they haven't changed.

Regarding failed checksums:

For some reason, the checksums will sometimes fail to validate if there are previous build artifacts in the build directory. This will usually be the case when using an AUR helper. I don't really know why this happens, but suggestions are welcome.

Cleaning the build directory should resolve the issue when it happens.

Ah damnit, I had a typo in the noextract section. Here's the update patch: http://ix.io/23lz

I also have been getting errors for invalid checksums every time I tried to update this package. Today, I finally got frustrated enough to do something about it. This patch should fix it: http://ix.io/23lw

@degeberg please consider applying this fix to the repo. Thanks for maintaining this BTW!

Just tried to build this and sha512sums in Build file were wrong for web-client-desktop-3.104.2-1b12c68.tar.xz and web-client-desktop-3.104.2-1b12c68.tar.xz.sha1. Worked fine when I corrected these. Thanks for maintaining this.