Change:
<del> { lib, stdenv, fetchFromGitLab, fetchpatch, ncurses, libtool, gettext, autoconf, automake, pkgconfig }: </del> <ins> { lib, stdenv, fetchurl, ncurses, libtool, gettext, autoconf, automake, pkgconfig }: </ins> stdenv.mkDerivation rec { name = "procps-${version}"; <del> version = "3.3.13"; </del> <ins> version = "3.3.14"; </ins> <del> src = fetchFromGitLab { owner ="procps-ng"; repo = "procps"; rev = "v${version}"; sha256 = "0r3h9adhqi5fi62lx65z839fww35lfh2isnknhkaw71xndjpzr0q"; </del> <ins> src = fetchurl { url = "https://gitlab.com/procps-ng/procps/-/archive/v${version}/procps-v${version}.tar.bz2"; sha256 = "0igvsl3s7m5ygxgypzksk4cp2wkvv3lk49s7i9m5wbimyakmr0vf"; </ins> }; buildInputs = [ ncurses ]; nativeBuildInputs = [ libtool gettext autoconf automake pkgconfig ]; <del> # https://gitlab.com/procps-ng/procps/issues/88 # Patches needed for musl and glibc 2.28 patches = [ (fetchpatch { url = "https://gitlab.com/procps-ng/procps/uploads/f91ff094be1e4638aeffb67bdbb751ba/numa.h.diff"; sha256 = "16r537d2wfrvbv6dg9vyfck8n31xa58903mnssw1s4kb5ap83yd5"; extraPrefix = ""; }) (fetchpatch { url = "https://gitlab.com/procps-ng/procps/uploads/6a7bdea4d82ba781451316fda74192ae/libio_detection.diff"; sha256 = "0qp0j60kiycjsv213ih10imjirmxz8zja3rk9fq5lr5xf7k2lr3p"; }) ]; </del> # autoreconfHook doesn't quite get, what procps-ng buildprocss does # with po/Makefile.in.in and stuff. preConfigure = ''

Discussion:
Building procps-ng from current master gives: Just updating the sha256 in the fetch leads to a patch error later on, so it seems like the source must have changed. system: host os: multi-user?: sandbox: (not really -- not sure why nix-info thinks otherwise) version:
I too get .
/cc maintainer
(I did the update to 3.3.13, so I am also somewhat responsible O:)) Curiously: When forcing a refetch, I too get the new hash. Noticing 3.3.14 is available (including patches we were applying ourselves), I bumped the version... but the hash is still the same--the new one ()!! Perhaps is broken, at least for this repository?? FWIW their website offers the following as the download URL: (compared to what we're using: ) Hmm....
Update: Here's our definition for : Interesting bits are: procps-ng sets (as it should, since version tags are not revisions!) which AFAICT our .. happily ignores? :(
looks weird. I just set to pin the commit, and got the hash as well.
If is broken let's fix that, instead of working around this.
is broken, you can just try different (even nonsense) values for the URL parameter and you will always get an archive for HEAD of master branch. I will dig up the documentation of gitlab on how to fetch archives for specific commits.
Few related-maybe issues upstream, investigating... And apparently ~5 days ago there is this comment that suggests the "new" URL format as I stumbled across as part of the PR moving to the next version: EDIT: Wouldn't mind second pair of eyes, esp if someone knows how to find the actual documentation instead of my issue-tracker-search approach xD.
Extracting the URL from a working button in there UI seems to work .... That is the format mentioned in the issues found, but it doesn't seem to be properly documented. Should we still use that?
This is really , please close this issue.