Arch Linux User Repository

@ntfc I was going to go the other way (update to 9.0.1 instead of reverting back to 8.11.1).

P.S. postman are pretty bad at updating their release notes page (even after a new version is out).

If you want to revert to any previous version you can do so by cloning the aur repo and changing the version in the PKGBUILD file and using makepkg to build it (it will download and install that version for you). E.g.:

git clone https://aur.archlinux.org/postman-bin.git
cd postman-bin

Edit the PKGBUILD file with whatever editor you like: edit line 4 to be pkgver=8.11.1 or whatever version you like, then save and exit out of the editor and run

updpkgsums
makepkg -sif

updpkgsums will download the file and update sha for file in PKGBUILD so it will install with makepkg

Just to give an update on this – the problem is gone for my case. I think the CDN is progressively updating their caches. Maybe they deployed a wrong version and immediately fixed it in the primary source and that update needs to ripple through the CDN nodes. Thanks for your quick responses btw!

Well crap, must be an issue on their mirroring or CDN nodes end.

wget gets me the correct file (note the download address resolves differently - looks like they're using cloudfront, not synced up properly?):

$wget https://dl.pstmn.io/download/version/7.17.0/linux64                                                                                                                                           
--2020-02-09 21:59:33--  https://dl.pstmn.io/download/version/7.17.0/linux64
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving dl.pstmn.io (dl.pstmn.io)... 13.225.146.93, 13.225.146.112, 13.225.146.10, ...
Connecting to dl.pstmn.io (dl.pstmn.io)|13.225.146.93|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 80973216 (77M) [application/gzip]
Saving to: ‘linux64’

linux64                                                     100%[==========================================================================================================================================>]  77.22M  2.76MB/s    in 26s     

2020-02-09 22:00:01 (2.97 MB/s) - ‘linux64’ saved [80973216/80973216]

$md5sum linux64                                                                                                                                                                                     
b5dcca9c97c0dbc06e0ae1e0507d772f  linux64

P.S. don't laugh at my download speeds (blimmin` Australia...)

Downloading the file from https://dl.pstmn.io/download/version/7.17.0/linux64 with Mozilla Firefox gets me the correct file.

Doing the same with wget gets me the wrong canary file

$ wget <https://dl.pstmn.io/download/version/7.17.0/linux64>
--2020-02-09 11:53:00--  <https://dl.pstmn.io/download/version/7.17.0/linux64>
Loaded CA certificate '/etc/ssl/certs/ca-certificates.crt'
Resolving dl.pstmn.io (dl.pstmn.io)... 99.84.156.61, 99.84.156.52, 99.84.156.45, ...
Connecting to dl.pstmn.io (dl.pstmn.io)|99.84.156.61|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 81058216 (77M) [application/gzip]
Saving to: ‘linux64’

linux64                       100%[=================================================>]  77,30M  11,7MB/s    in 6,6s

2020-02-09 11:53:07 (11,7 MB/s) - ‘linux64’ saved [81058216/81058216]

$ tar -zxf linux64 && ls
linux64  PostmanCanary

Thanks pythoneer. That's definitely a different file that the same makepkg downloads for me (even though download link is the same). Any thoughts here?

Only thing I can think of is some CDN / mirror issue (e.g. CDN node closest to where you are has an issue where it's pointing to the canary builds?). I'm in Australia btw and can confirm installing via yay downloads and checkums the correct file...

Haven't seen this issue before.

ls ~/.cache/yay/
completion.cache  postman-bin  vcs.json

rm -rf ~/.cache/yay/postman-bin

ls ~/.cache/yay/
completion.cache  vcs.json

yay -S postman-bin
:: Checking for conflicts...
:: Checking for inner conflicts...
[Aur: 1]  postman-bin-7.17.0-1

:: Downloaded PKGBUILD (1/1): postman-bin
  1 postman-bin                              (Installed) (Build Files Exist)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> 
:: Parsing SRCINFO (1/1): postman-bin
==> Making package: postman-bin 7.17.0-1 (So 09 Feb 2020 11:41:38 CET)
==> Retrieving sources...
  -> Downloading Postman-linux-x64-7.17.0.tar.gz...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 77.3M  100 77.3M    0     0  11.3M      0  0:00:06  0:00:06 --:--:-- 11.5M
  -> Found postman.desktop
==> Validating source files with md5sums...
    Postman-linux-x64-7.17.0.tar.gz ... FAILED
    postman.desktop ... Passed
==> ERROR: One or more files did not pass the validity check!
Error downloading sources: postman-bin

md5sum ~/.cache/yay/postman-bin/Postman-linux-x64-7.17.0.tar.gz 
bfebe8d41369d074cbef60ce04ee8ddc  /home/naikon/.cache/yay/postman-bin/Postman-linux-x64-7.17.0.tar.gz

tar -zxvf ~/.cache/yay/postman-bin/Postman-linux-x64-7.17.0.tar.gz

cd ~/PostmanCanary/ && ls
app  PostmanCanary

Could one of you (who is having the issue re checksums - and as pythoneer mentioned: retrieving the wrong file) test removing any yay cached download by deleting the ~./.cache/yay/postman-bin folder and try install via yay again?

e.g.

rm -rf ~/.cache/yay/postman-bin

yay -S postman-bin

Cheers, Jay.

Thanks pythoneer. Canary builds designed for early adopters - seems it's downloading a canary build instead - which is whack (shouldn't happen). I'm trying to understand why that happens when the download link should explicitly be https://dl.pstmn.io/download/version/7.17.0/linux64.

I am having the same problem with the md5sum of bfebe8d41369d074cbef60ce04ee8ddc . i have uploaded the file from my cache here https://filebin.net/lwwknqp2tu1ghbsb

downloading the file directly from my browser is getting me the "correct" file and md5sum.

I have binary compared the *.tar.gz files (cmp command) and they are in fact different. i extracted both and the one from the aur differs in the overall extracted top folder and the executable file name. In the archive directly downloaded from the website the top folder is called "Postman" and the executable is called "Postman" whereas the top folder from the aur is called "PostmanCanary" and the executable is called "PostmanCanary".

That was the immediate difference i have noticed without investigating the binaries further – i think the aur script somehow downloads a "canary" version of Postman?

Thanks all for the feedback. This is very strange - md5sum for file download should be b5dcca9c97c0dbc06e0ae1e0507d772f (which differs from the download file you are getting). Only thing I can think of is if postman is using a CDN or something for the download and nodes haven't been synced?

Same problem as @lfkeitel , with the md5sum bfebe8d41369d074cbef60ce04ee8ddc