What system are you running into this problem on? We can update curl in stdenv-updates (the branch for changes that will cause a rebuild of pretty much every package), but unless you absolutely can't use nix on your system it will be some time until stdenv-updates is merged.

@edolstra: If this can only be worked-around by @gitfoxi by building his own stdenv, would that be enough justification for a quick bugfix stdenv-update?

Actually updating curl is not a problem because fetchurl is a "fixed-output" derivation that doesn't cause a rebuild if the dependencies of fetchurl change.

Ah, for some reason I assumed curl was part of the stdenv standard $PATH. Makes sense that it wouldn't be. I'll test the patch then merge if all is well.

I'm okay because I've got the update. :)
The packages that really must be rebuilt are Nix and Perl.

I am running on a bit of a strange system. I'm trying to run /nix
along side RHEL3 from 2002 with 2.4 kernel. It's going okay, but I
think I need to downgrade glibc back to 2.3.6 or move to uclibc before
I'll ever get a web browser running because of some big change to
kernel threading technology. It might be a factor in the curl problem.
Apparently kernel threading is sketchy for several years of 2.6 as
well which sticks it to embedded developers who are stuck with this or
that antiquated kernel patched for their specific chip.

Anyway, it was easy to find people complaining about this buggy
version of curl on the internet so it might affect other people. It is
kind of insidious because it is intermittent. Since Nix has failover
logic it makes it do strange things.

On Sun, Jul 1, 2012 at 9:17 PM, Shea Levy
[email protected]
wrote:

Ah, for some reason I assumed curl was part of the stdenv standard $PATH. Makes sense that it wouldn't be. I'll test the patch then merge if all is well.

---

Reply to this email directly or view it on GitHub:
#28 (comment)

Michael

The change was already merged :) Thanks for the contribution