@TravisWhitaker, thanks for your PR! By analyzing the history of the files in this pull request, we identified @bluescreen303, @lovek323 and @bjornfor to be potential reviewers.

Note that two reverse dependencies already fail to build, ultrastardx (#20568) and octaveFull (#20589) and so can't be tested for compatibility.

@vcunat also a potential reviewer.

The source hash wasn't changed!

Meaning you most likely haven't tested building from the new source at all.

Reverted for now.

Oh dear, I did neglect to update the source hash. However, in my branch nix-build ./default.nix -A portaudio fetches and builds portaudio-19-20161030 without complaining about a hash mismatch.

Can anyone else confirm this?

@vcunat the build is tested and reverse dependencies pass tests, with the exception of ultrastardx and octaveFull whose derivations are broken.

It fetches the old source, as we employ hash-addressing to find cached sources on tarballs.nixos.org

Meaning it builds (and tests) the old version.

For prefetching sources I recommend

$ nix-prefetch-url -A portaudio.src
downloading ‘http://www.portaudio.com/archives/pa_stable_v190600_20161030.tgz’... [831/1417 KiB, 708.3 KiB/s]
path is ‘/nix/store/6lvv07wxgwi6641jkqbb11s20qdk3b7f-pa_stable_v190600_20161030.tgz’
04qmin6nj144b8qb9kkd9a52xfvm0qdgm8bg8jbl7s3frmyiv8pm

Ah, that explains it then. My apologies.

For which derivations does tarballs.nixos.org cache the source? Typically if I forget to update the hash an error is generated.

@vcunat thanks for the catch, and thanks for the nix-prefetch-url tip!

It's not fully automatic (see e.g. #11782), but all default fetchurl invocations check the location.

The mistake is relatively common; unfortunately I don't know a good way to prevent it from happening (meaning especially people who don't know about it).

Oops. Don't know how I missed that, I did look. Oh, well