Re: [Nix-dev] Patching uname in stdenv?
Hi, On 08/17/2011 05:03 AM, s...@shealevy.com wrote: What would people think of a patch that made stdenv's uname return the same value on every linux? I assume you're referring to the kernel version returned by ‘uname -r’. Since ‘uname’ is also used outside of builders, this is not a good idea — it would change the behaviour that users expect from it. BTW, the kernel version does matter sometimes, for instance, APR (IIRC) at compile-time decides whether to use the accept4() system call based on the kernel version of the build system. So if you try to run the resulting library on an older kernel, it doesn't work. Arguably the kernel version should be part of the system value, but that would be too painful. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 12:00 PM, Michael Raskin wrote: What would people think of a patch that made stdenv's uname return the same value on every linux? I assume you're referring to the kernel version returned by ‘uname -r’. Since ‘uname’ is also used outside of builders, this is not a good idea — it would change the behaviour that users expect from it. We already have distinct bash in stdenv and user's environment. How so? Anyway, this would be breaking a feature of uname, namely that ‘uname -r’ returns the kernel version. Users would find it very surprising if they're running a X.Y kernel and uname returns something different than X.Y. -- Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
I assume you're referring to the kernel version returned by ‘uname -r’. Since ‘uname’ is also used outside of builders, this is not a good idea — it would change the behaviour that users expect from it. We already have distinct bash in stdenv and user's environment. How so? As I remember, stdenv bash has no ncurses. And user environment usually gets bashInteractive Anyway, this would be breaking a feature of uname, namely that ‘uname -r’ returns the kernel version. Users would find it very surprising if they're running a X.Y kernel and uname returns something different than X.Y. Of course, stdenv will have unameFakeVersions and simle uname will work as expected. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[***SPAM***] Re: [Nix-dev] Patching uname in stdenv?
Anyway, this would be breaking a feature of uname, namely that ‘uname -r’ returns the kernel version. Users would find it very surprising if they're running a X.Y kernel and uname returns something different than X.Y. Actually, maybe it is not worth the effort to have two unames - my point is only that it has benefits and the only obvious drawback is time to implement (so I wonder whether there are other) ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On Wed, Aug 17, 2011 at 12:59:22PM +0400, Michael Raskin wrote: e1qtafh-0003g2-00.7c6f434c-mail...@smtp4.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? I'd like a list of the problems this would solve. General idea is to forcibly remove one more impurity. FF6.0 release manages to trigger it. Is this impurity affecting the behaviour of FF6.0? If it is, I think they are doing something wrong. If they care about the API, they should check the kernel headers version.h, and not uname. Or is it simply storing what kernel was it running at build time, and you care on getting always the same 'hash' on the result directory? ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[***SPAM***] Re: [Nix-dev] Patching uname in stdenv?
16b0358b83ffeaf7d2876f231de4e64d.squir...@webmail.shealevy.com e1qtbry-0003pi-00.7c6f434c-mail...@smtp8.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? I'd like a list of the problems this would solve. General idea is to forcibly remove one more impurity. FF6.0 release manages to trigger it. Is this impurity affecting the behaviour of FF6.0? If it is, I think they are doing something wrong. If they care about the API, they should check the kernel headers version.h, and not uname. They do something wrong, they admit it, but this wrong is in their 6.0 release tarball. They have a fix, maybe it will be in 6.0.1 - I have no idea. But Nix has a few tricks to stop builders from doing obviously wrong things. Or is it simply storing what kernel was it running at build time, and you care on getting always the same 'hash' on the result directory? Not really. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On Aug 17, 2011, at 11:46 AM, Eelco Dolstra wrote: Hi, On 08/17/2011 05:03 AM, s...@shealevy.com wrote: What would people think of a patch that made stdenv's uname return the same value on every linux? I assume you're referring to the kernel version returned by ‘uname -r’. Since ‘uname’ is also used outside of builders, this is not a good idea — it would change the behaviour that users expect from it. BTW, the kernel version does matter sometimes, for instance, APR (IIRC) at compile-time decides whether to use the accept4() system call based on the kernel version of the build system. So if you try to run the resulting library on an older kernel, it doesn't work. Arguably the kernel version should be part of the system value, but that would be too painful. Just for the record, it happens that I rely on uname -r impurity in some build scripts that generated checkpointed binaries with BLCR. The point is that these scripts depend on the version of the running kernel. Also they do work on Linux in general, not necessarily on NixOS, and they need to be re-run each time the kernel is updated. Marco___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On Wed, Aug 17, 2011 at 12:33:37PM +0200, Marco Maggesi wrote: On Aug 17, 2011, at 11:46 AM, Eelco Dolstra wrote: Hi, On 08/17/2011 05:03 AM, s...@shealevy.com wrote: What would people think of a patch that made stdenv's uname return the same value on every linux? I assume you're referring to the kernel version returned by ‘uname -r’. Since ‘uname’ is also used outside of builders, this is not a good idea — it would change the behaviour that users expect from it. BTW, the kernel version does matter sometimes, for instance, APR (IIRC) at compile-time decides whether to use the accept4() system call based on the kernel version of the build system. So if you try to run the resulting library on an older kernel, it doesn't work. Arguably the kernel version should be part of the system value, but that would be too painful. Just for the record, it happens that I rely on uname -r impurity in some build scripts that generated checkpointed binaries with BLCR. The point is that these scripts depend on the version of the running kernel. Also they do work on Linux in general, not necessarily on NixOS, and they need to be re-run each time the kernel is updated. How can it be? I assume you mean blcr built from nixpkgs. BLCR should fail to work in kernels older to the kernelHeaders in nixpkgs. And the kernelHeaders in nixpkgs should be the only determinant of what kernels blcr can work on. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
[sorry for the previous incomplete message] On Aug 17, 2011, at 12:47 PM, Lluís Batlle i Rossell wrote: The point is that these scripts depend on the version of the running kernel. Also they do work on Linux in general, not necessarily on NixOS, and they need to be re-run each time the kernel is updated. How can it be? I assume you mean blcr built from nixpkgs. BLCR should fail to work in kernels older to the kernelHeaders in nixpkgs. And the kernelHeaders in nixpkgs should be the only determinant of what kernels blcr can work on. This is interesting. I should consider your remark to improve my build scripts. The truth is that I don't understand the implementation details of BLCR. (And, to be honest, I try to keep myself away as much as possible from this kind of low-level details.) I simply make the assumptions that: 1. BLCR is installed on the system (I don't care how this is done, e.g., it can be installed by hand on an ubuntu server) and 2. I want to run checkpointed binaries that matches both the kernel and the BLCR installation that has been used to produce them. These assumption are probably too restrictive, but they have an advantage: they give a simple model and they do not depend on how the checkpointing software works internally. For instance I use the same technique with other checkpointing software like dmtcp. (But perhaps your remark applies equally to dmtcp, I don't know.) Marco___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On Wed, Aug 17, 2011 at 01:11:53PM +0200, Marco Maggesi wrote: On Aug 17, 2011, at 12:47 PM, Lluís Batlle i Rossell wrote: BLCR should fail to work in kernels older to the kernelHeaders in nixpkgs. And the kernelHeaders in nixpkgs should be the only determinant of what kernels blcr can work on. This is interesting. I should consider your remark to improve my build scripts. The truth is that I don't understand the implementation details of BLCR. (And, to be honest, I try to keep myself away as much as possible from this kind of low-level details.) The libc is built against some specific kernel headers (the linux API). That linux API is also available in 'stdenv', so programs wanting linux-specific things, have access to them. We use to update the version of kernel headers in nixpkgs when we change gcc or the libc in stdenv, so, not often. Linux claim to have an API always backward compatible. So if you build with the API (kernel headers) of version 2.6.20, it means that the program should work fine in any kernel equal or newer than 2.6.20. It may be that some distributions have kernel variations or kernel API variations that break that backward compatibility. And I bet there are programs that make assumptions on the kernel API they use, either because they did not use properly the kernel headers, or they decided code based on uname reports, for example. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
Excerpts from Lluís Batlle i Rossell's message of Wed Aug 17 10:45:39 +0200 2011: I'd like a list of the problems this would solve. Eventually build of python-2.7 on linux-3.0 and the like which use uname to determine kernel version, and they don't know about linux-3 yet. The alternative would be starting a VM for building. Then you could set the kernel to build packages in configuration.nix. However if kernel API is always backward compatible then this might be overkill. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On Wed, Aug 17, 2011 at 04:21:40PM +0200, Marc Weber wrote: Excerpts from Lluís Batlle i Rossell's message of Wed Aug 17 10:45:39 +0200 2011: I'd like a list of the problems this would solve. Eventually build of python-2.7 on linux-3.0 and the like which use uname to determine kernel version, and they don't know about linux-3 yet. Why they want the kernel version? ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 03:16 AM, Michael Raskin wrote: Hi all, What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? Default being the version of kernelheaders seems like the way to do it. Not sure how stdenv is supposed to find out which version of the kernel was passed for kernelPackages, though. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 04:45 AM, Lluís Batlle i Rossell wrote: On Wed, Aug 17, 2011 at 11:16:12AM +0400, Michael Raskin wrote: Hi all, What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? I'd like a list of the problems this would solve. Regards, Lluís. Two problems that I know of so far: openjdk fails to build without a patch on linux = 3.0, and firefox fails to build on the same kernel versions. In general, the idea that a build has any need to know the current running kernel (beyond the fact that it's newer than a certain baseline, perhaps) is suspect to me, though I'll admit I don't have much knowledge in that area. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 05:46 AM, Eelco Dolstra wrote: Hi, On 08/17/2011 05:03 AM, s...@shealevy.com wrote: What would people think of a patch that made stdenv's uname return the same value on every linux? I assume you're referring to the kernel version returned by ‘uname -r’. Since ‘uname’ is also used outside of builders, this is not a good idea — it would change the behaviour that users expect from it. I can think of two ways off the top of my head to localize it to builds: Have it check for an env var that stdenv sets, or leave the coreutils version alone and put the patched version directly into stdenv's $out (though I may be misunderstanding how name collisions are resolved, and this would be a problem for anyone with stdenv in their environment). BTW, the kernel version does matter sometimes, for instance, APR (IIRC) at compile-time decides whether to use the accept4() system call based on the kernel version of the build system. So if you try to run the resulting library on an older kernel, it doesn't work. Arguably the kernel version should be part of the system value, but that would be too painful. Why wouldn't just depending on the kernel headers be enough here? Shouldn't that be how packages determine the kernel API anyway? ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 06:20 AM, Lluís Batlle i Rossell wrote: On Wed, Aug 17, 2011 at 12:59:22PM +0400, Michael Raskin wrote: e1qtafh-0003g2-00.7c6f434c-mail...@smtp4.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? I'd like a list of the problems this would solve. General idea is to forcibly remove one more impurity. FF6.0 release manages to trigger it. Is this impurity affecting the behaviour of FF6.0? If it is, I think they are doing something wrong. If they care about the API, they should check the kernel headers version.h, and not uname. Or is it simply storing what kernel was it running at build time, and you care on getting always the same 'hash' on the result directory? In the FF6.0 case, the build actually fails. While I'd like to get the same hash on the result directory every time (I've been thinking of starting a stdenv-pure branch to root out as many impurities as possible), there are definitely noticeable changes in some packages beyond just a hash. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
Why they want the kernel version?
Don't ask me. I have't had time to debug it. All I found out was that it
python configured itself to use different modules and some fail.
for older xulunner which got removed there were similar problems.
It looked to me like they are configuring based on target (linux vs darwin ...)
and they all expected linux-2.X with increasing X forever without a major
version bump.
Patches for postfix (newer version than current nixpkgs), obsolete xulrunner
and valgrind failed:
POSTFIX failed [1]
xulrunner failed [2]
valgrind failed [3]
[1]
pkgs/servers/mail/postfix/default.nix
index 773f113..f779964 100644
@@ -56,7 +56,11 @@ stdenv.mkDerivation {
buildInputs = [db4 openssl cyrus_sasl perl];
- patches = [./postfix-2.2.9-db.patch ./postfix-2.2.9-lib.patch];
+ patches = [
+./postfix-2.2.9-db.patch
+./postfix-2.2.9-lib.patch
+./postfix-linux-3.0.patch
+ ];
inherit glibc;
}
-- pkgs/servers/mail/postfix/postfix-linux-3.0.patch --
new file mode 100644
index 000..bee1c4c
@@ -0,0 +1,14 @@
+diff --git a/makedefs b/makedefs
+index 4faa430..965ceb3 100644
+--- a/makedefs
b/makedefs
+@@ -108,6 +108,9 @@ case $# in
+ *) echo usage: $0 [system release] 12; exit 1;;
+ esac
+
++# don't think that linux 3.0 introduced important changes
++ if [ $SYSTEM == Linux ] [ ${RELEASE##3*} == ]; then RELEASE=2;
fi
++
+ case $SYSTEM.$RELEASE in
+SCO_SV.3.2)SYSTYPE=SCO5
+ # Use the native compiler by default
[2]
pkgs/applications/networking/browsers/firefox/3.6.nix
index 2d472ce..a4e82a4 100644
@@ -45,6 +45,13 @@ rec {
inherit src;
+# make it compile on linux-3.0. Is there more that has to be changed ?
+postUnpack = ''
+ ( cd mozilla-*
+[ -f security/coreconf/Linux3.0.mk ] || cp
security/coreconf/Linux2.6.mk security/coreconf/Linux3.0.mk
+ )
+'';
+
patches = [
# Loongson2f related patches:
./xulrunner-chromium-mips.patch
pkgs/applications/networking/browsers/firefox/4.0.nix
index 6d988fb..4452595 100644
@@ -54,6 +54,14 @@ rec {
inherit src;
+# make it compile on linux-3.0. Is there more that has to be changed ?
+postUnpack = ''
+ ( cd mozilla-*
+[ -f security/coreconf/Linux3.0.mk ] || cp
security/coreconf/Linux2.6.mk security/coreconf/Linux3.0.mk
+ )
+'';
+
+
buildInputs =
[ pkgconfig gtk perl zip libIDL libjpeg libpng zlib cairo bzip2
python dbus dbus_glib pango freetype fontconfig xlibs.libXi
[3]
+ # linux 3.0 hack
+ preConfigure = ''sed -i '/as_fn_error Valgrind works on kernels 2.4,
2.6/d' configure'';
+
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 06:20 AM, Lluís Batlle i Rossell wrote: On Wed, Aug 17, 2011 at 12:59:22PM +0400, Michael Raskin wrote: e1qtafh-0003g2-00.7c6f434c-mail...@smtp4.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? I'd like a list of the problems this would solve. General idea is to forcibly remove one more impurity. FF6.0 release manages to trigger it. Is this impurity affecting the behaviour of FF6.0? If it is, I think they are doing something wrong. If they care about the API, they should check the kernel headers version.h, and not uname. Or is it simply storing what kernel was it running at build time, and you care on getting always the same 'hash' on the result directory? In the FF6.0 case, the build actually fails. While I'd like to get the same hash on the result directory every time (I've been thinking of starting a stdenv-pure branch to root out as many impurities as possible), there are definitely noticeable changes in some packages beyond just a hash. Technically, it fails even without it. But in a significantly different way. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 10:59 AM, Michael Raskin wrote: On 08/17/2011 06:20 AM, Lluís Batlle i Rossell wrote: On Wed, Aug 17, 2011 at 12:59:22PM +0400, Michael Raskin wrote: e1qtafh-0003g2-00.7c6f434c-mail...@smtp4.mail.ru) Mime-Version: 1.0 Content-type: text/plain; charset=UTF-8 What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? I'd like a list of the problems this would solve. General idea is to forcibly remove one more impurity. FF6.0 release manages to trigger it. Is this impurity affecting the behaviour of FF6.0? If it is, I think they are doing something wrong. If they care about the API, they should check the kernel headers version.h, and not uname. Or is it simply storing what kernel was it running at build time, and you care on getting always the same 'hash' on the result directory? In the FF6.0 case, the build actually fails. While I'd like to get the same hash on the result directory every time (I've been thinking of starting a stdenv-pure branch to root out as many impurities as possible), there are definitely noticeable changes in some packages beyond just a hash. Technically, it fails even without it. But in a significantly different way. Fair enough. FF5.0 builds fine on 2.6.x but fails on 3.x, then. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
Excerpts from Lluís Batlle i Rossell's message of Wed Aug 17 10:45:39 +0200 2011: I'd like a list of the problems this would solve. And we should add a list of worms this may introduce. Kernel should be compatible. But software development is never perfect (although it comes close). Many packages encode linux version in info boxes or such. And they might be wrong. I agree that I don't expect too many problems. But there might be some cases where having the wrong value in an info box could slow down solving issues. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 03:16 AM, Michael Raskin wrote: Hi all, What would people think of a patch that made stdenv's uname return the same value on every linux? I've only just had the idea and haven't had time to think through the possible downsides, but my initial thought is that most packages shouldn't need to know the kernel version, and that those that have a reason to (e.g. packages that provide kernel modules) should be dependent on the kernel passed to the nix expression, rather than whatever the kernel happens to be in memory at a given time. Or am I wrong? Is there a reason a build should depend on which version of the I guess default uname should say version of kernel from kernelheaders used for glibc, and kernelPackages one should say the kernel version of the passed kernel? Default being the version of kernelheaders seems like the way to do it. Not sure how stdenv is supposed to find out which version of the kernel was passed for kernelPackages, though. # nix-instantiate --eval-only /etc/nixos/nixpkgs/ -A linuxPackages.kernel.version 2.6.32.44 kernelHeaders currently do not put version in an attribute, but put it in a file. This can be changed easily. kernelPackages could replace uname with its own one - dependent on kernel.version. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
On 08/17/2011 05:46 AM, Eelco Dolstra wrote: Hi, On 08/17/2011 05:03 AM, s...@shealevy.com wrote: What would people think of a patch that made stdenv's uname return the same value on every linux? I assume you're referring to the kernel version returned by ‘uname -r’. Actually, I'm not sure why we shouldn't just keep everything in uname -a fixed (if we can localize the patched uname to builds). Any build system that does depend on that info should depend on it explicitly, so in the long term it's probably a good thing if some builds were to fail with such a patch since it would help us better identify dependencies. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
