Re: [Nix-dev] kernel oops [aufs + squashfs] on nixos-graphical-0.1pre29826-i686-linux.iso
I tested my NixOS CD that was giving kernel oops on my computer on an other computer today, Seems to go fine on the other computer. So I guess this is linked to recent Linux versions, and my particular hardware: a N10/ICH7 Intel computer with a SATA disk 82801G rev 01. Wonder if it is worth to extract the full log of the oops, by getting this old null-modem RS232C cable I must have somewhere, even if it is not on latest kernel. This CD is using 2.6.39. I guess Linux people won't care much unless it is at least 3.1-rc4. I may looks like if I know what I am saying, but I consider myself more an advanced user than a developer, that have tried to triage Ubuntu bugs some time ago. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] kernel oops [aufs + squashfs] on nixos-graphical-0.1pre29826-i686-linux.iso
Excerpts from Paul Dufresne's message of Sat Oct 15 09:34:43 +0200 2011: > Wonder if it is worth to extract the full log of the oops, by getting > this old null-modem RS232C cable I must have somewhere, even if it is > not on latest kernel. This CD is using 2.6.39. I guess Linux people > won't care much unless it is at least 3.1-rc4. Probably its faster to give all kernels a try and see which ones do work instead. If you want to go that route the kernel mailinglist might be the better address. But that's not my field of expertise. If it comes to kernel development I'm a user only as well. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] NixOS - Issue 145
NixOS #145 (15 Oct)By Paul Dufresneaufs oops when about to login on installation CDI burnt and verify (twice) my image (more if you count the one that were bad): paul@paul-P5GZ-MX:~$ md5sum nixos-graphical-0.1pre29826-i686-linux.iso 164774618b05c3633124bf6ef793d5e8 nixos-graphical-0.1pre29826-i686-linux.iso When I boot, it basically goes up to the login prompt. But just as I am about to enter 'root', about 3 cascade oops happens. They are linked to aufs and squashfs. Sometimes, a message say that kernel was fixing from recursive (oops) but need to reboot. I still can change console with Alt-F[1-6], but after entering root, I get some other oops,and nothing happens. I checked my CD was Ok with: paul@paul-P5GZ-MX:~$ dd if=/dev/cdrom | md5sum 164774618b05c3633124bf6ef793d5e8 - The CD works fine on an other computer. I rebooted with oops=panic I noted the trace manually (well, the lines that are on the screen): [I reversed the lines, this make more sense to me] sysenterdocall ptregs_execve sys_execve checkunsafeexec open_exec securitypreparecreds dofilpopen do_last do_lookup d_alloc d_alloc aufs_lookup generic_permission aulkupdentry auwhname_alloc aufsreadlock diwritelock doiiwrite_lock down_write update_curr aulkupone getpagefrom_freelist vfsublookupone_len -- Issue on YellowGrass -- http://yellowgrass.org -- ___ nix-commits mailing list nix-comm...@cs.uu.nl http://mail.cs.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] builderDefs, composedArgsAndFun
Ok, thank you for your explanation. Marco Quoting Michael Raskin <7c6f4...@mail.ru>: >> Hi, >> >> there are some functions in nixpkgs that I always avoided to use >> and understand. >> A couple of them are builderDefs and composedArgsAndFun. >> I'm reading their implementation right now but they don't look >> straightforward to me. >> Can someone give me a hint on what they do or point me to some >> documentation? > > builderDefs compose build process out of phases instead of running > always the same functions, although some of executions of some of the > functions do nothing. > > It was written before there was any reasonable overriding in Nixpkgs to > provide overriding (sometimes changing preConfigure with overrides is > still hard). Also, it doesn't require additional tricks for passing $out > in configureFlags and it is possible to add a new archive format support > in trunk with out a rebuild (and overall it controls more of the build > choices on Nix-language level, instead of in the bash script). > >> In particular, i would like to update the expression for the Io >> language which is now old (2008) which employ builderDefs. > > If it is a complete rewrite because Io's build system is now > rewritten upstream, there is no reason to care about my old > expression. This message was sent using IMP, the Internet Messaging Program. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] python-x.y.z-wrapper vs python-x.y.z-full
Hi Florian, > the attribute name for pythonXYFull is python-X.Y.Z-wrapper. I'd > consider python-X.Y.Z-full to be more intuitive. Anything against > renaming? use of the suffix "-wrapper" is very common in Nix. GCC follows the same naming scheme, and so does GHC. I don't see what we would gain from having a different suffix for Python's wrapper script. Besides, the suffix "-full" would be misleading for all other uses of python/wrapper.nix. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] new possible movement to git (?)
On Mon, 29 Aug 2011 12:51:25 -0700, s...@shealevy.com wrote: > >>> <4e5566e6.9050...@shealevy.com> <4e5b97be.5030...@tudelft.nl>) > 1. Would we still need stdenv-updates, or could we just use feature > branches for the individual update we care about then merge it into > >>> Of course, we will have to name stdenv-updates something new each time > >>> to keep track of what got merged where afterwards. > >>Why would that be necessary? > > > > Given that branches are mere pointers, I don't see how to find out what > > was stdenv-updates before after it has been merged into trunk and > > re-created > > Ah, I see. Yeah, it would be nice if git had information in commits about > which branch the commit was initially performed on. This seems like a > really simple feature, not sure why it doesn't exist. If you tell git not to do fast-forward merges the history will show where a commit is coming from: git merge --no-ff > unstable (or probably master in keeping with git lingo)? This would put > rebuild work onto developers but since users should be using "tested" > >>> It doesn't look like we have large user-to-developer ratio.. > >>No, but as a developer I would have unstable checked out where I do my > >>work, and as a user I would have testing checked out in /etc/nixos or be > >>subscribed to testing as my channel. > > > > An easy way to update to last completed Hydra build would be nice, true. hydra could create tags and push these. Did I understand correctly: we are about to move to git? Having used hg/git and a bit of cvs/svn/darcs I am fully in favor of moving to git. regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpfzzD0nTjol.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29852 - nixpkgs/trunk/pkgs/desktops/kde-4.7/kde-package
Author: urkud
Date: Sat Oct 15 13:32:05 2011
New Revision: 29852
URL: https://nixos.org/websvn/nix/?rev=29852&sc=1
Log:
Fix comment
Modified:
nixpkgs/trunk/pkgs/desktops/kde-4.7/kde-package/default.nix
Modified: nixpkgs/trunk/pkgs/desktops/kde-4.7/kde-package/default.nix
==
--- nixpkgs/trunk/pkgs/desktops/kde-4.7/kde-package/default.nix Fri Oct 14
22:06:50 2011(r29851)
+++ nixpkgs/trunk/pkgs/desktops/kde-4.7/kde-package/default.nix Sat Oct 15
13:32:05 2011(r29852)
@@ -33,7 +33,8 @@
enableParallelBuilding = true;
} // (removeAttrs a [ "meta" "name" ]));
- # kdeMonoPkg wrapper for modules splitted upstream. Used in TODO
+ # kdeMonoPkg wrapper for modules splitted upstream compatible with
combinePkgs
+ # API.
kdeSplittedPkg = module: {name, sane ? name}: kdeMonoPkg name;
# Build subdirectory ${subdir} of tarball ${module}-${release}.tar.bz2
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-dev] What blocks site.py's from being linked?
Hi, what is responsible that below there are no "site.py*" and easy-install.pth anymore after two modules are installed into the profile? I'm not saying its bad, but I'd like to understand how. I understand with only one module installed, the lib folder is linked From the unittest2 derivation. Once the second module also provides content for lib/python2.7/site-packages/ the egg files/dirs are linked. But why aren't easy-install.pth and site.py* linked, too? $ nix-env -p collide -Ai nixpkgs_sys.python27Packages.unittest2 ... $ ls -l collide/lib/python2.7/site-packages/ total 16 -r--r--r-- 1 root root 213 Jan 1 1970 easy-install.pth -r--r--r-- 1 root root 2362 Jan 1 1970 site.py -r--r--r-- 1 root root 1849 Jan 1 1970 site.pyc dr-xr-xr-x 4 root root 4096 Jan 1 1970 unittest2-0.5.1-py2.7.egg/ $ nix-env -p collide -Ai nixpkgs_sys.python27Packages.argparse ... $ ls -l collide/lib/python2.7/site-packages/ total 8 lrwxrwxrwx 1 root nixbld 114 Oct 15 15:44 argparse-1.1-py2.7.egg -> /nix/store/c54vw3vh0x2h76kjxq6iydgfm3lfz6sa-python-argparse-1.1/lib/python2.7/site-packages/argparse-1.1-py2.7.egg lrwxrwxrwx 1 root nixbld 120 Oct 15 15:44 unittest2-0.5.1-py2.7.egg -> /nix/store/5f3y1a8xr6kga7wm8k2mfjj176nwxigj-python-unittest2-0.5.1/lib/python2.7/site-packages/unittest2-0.5.1-py2.7.egg/ regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgp0cYdJCFvRh.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] python-x.y.z-wrapper vs python-x.y.z-full
On Sat, 15 Oct 2011 13:54:40 +0200, Peter Simons wrote: > Hi Florian, > > > the attribute name for pythonXYFull is python-X.Y.Z-wrapper. I'd > > consider python-X.Y.Z-full to be more intuitive. Anything against > > renaming? > > use of the suffix "-wrapper" is very common in Nix. GCC follows the > same naming scheme, and so does GHC. I don't see what we would gain > from having a different suffix for Python's wrapper script. Besides, > the suffix "-full" would be misleading for all other uses of > python/wrapper.nix. Ok, I agree. But there are plenty of "-wrapper"s, but only ghc and python use it as a suffix _after_ the version. This results in python-2.7.1 being "upgraded" to python-2.7.1-wrapper by 'nix-env -u \*'. Why not python-wrapper-2.7.1? regards florian -- Florian Friesdorf GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpRAhAparrYD.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29853 - nixpkgs/trunk/pkgs/games/dwarf-fortress
Author: roconnor
Date: Sat Oct 15 14:46:05 2011
New Revision: 29853
URL: https://nixos.org/websvn/nix/?rev=29853&sc=1
Log:
updating dwarf-fortress
Modified:
nixpkgs/trunk/pkgs/games/dwarf-fortress/default.nix
Modified: nixpkgs/trunk/pkgs/games/dwarf-fortress/default.nix
==
--- nixpkgs/trunk/pkgs/games/dwarf-fortress/default.nix Sat Oct 15 13:32:05
2011(r29852)
+++ nixpkgs/trunk/pkgs/games/dwarf-fortress/default.nix Sat Oct 15 14:46:05
2011(r29853)
@@ -3,11 +3,11 @@
assert stdenv.system == "i686-linux";
stdenv.mkDerivation rec {
- name = "dwarf-fortress-0.31.16";
+ name = "dwarf-fortress-0.31.25";
src = fetchurl {
-url = "http://www.bay12games.com/dwarves/df_31_16_linux.tar.bz2";;
-sha256 = "04pyxyigrrclbpxdx3wryisgy5xraz0s7rsxr2kp4i136479f2r4";
+url = "http://www.bay12games.com/dwarves/df_31_25_linux.tar.bz2";;
+sha256 = "0d3klvf5n99j38pdhx9mak78px65aw47smck82jb92la97drmcg3";
};
phases = "unpackPhase patchPhase installPhase";
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] python-x.y.z-wrapper vs python-x.y.z-full
Hi Florian, > But there are plenty of "-wrapper"s, but only ghc and python use it > as a suffix _after_ the version. This results in python-2.7.1 being > "upgraded" to python-2.7.1-wrapper by 'nix-env -u \*'. apparently, you consider that a problem? Why is that? > Why not python-wrapper-2.7.1? Well, I guess that would work fine, too. I don't feel strongly about that issue. Take care, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29854 - nixpkgs/trunk/pkgs/development/interpreters/guile
Author: ludo Date: Sat Oct 15 16:34:26 2011 New Revision: 29854 URL: https://nixos.org/websvn/nix/?rev=29854&sc=1 Log: Guile: Disable more GC-sensitive tests when using `-O0'. Modified: nixpkgs/trunk/pkgs/development/interpreters/guile/disable-gc-sensitive-tests.patch Modified: nixpkgs/trunk/pkgs/development/interpreters/guile/disable-gc-sensitive-tests.patch == --- nixpkgs/trunk/pkgs/development/interpreters/guile/disable-gc-sensitive-tests.patch Sat Oct 15 14:46:05 2011(r29853) +++ nixpkgs/trunk/pkgs/development/interpreters/guile/disable-gc-sensitive-tests.patch Sat Oct 15 16:34:26 2011(r29854) @@ -3,6 +3,16 @@ be many false references held on the stack, leading to the failure of such tests. +--- a/test-suite/tests/gc.test b/test-suite/tests/gc.test +@@ -67,6 +67,7 @@ + + (with-test-prefix "gc" + (pass-if "Unused modules are removed" ++(throw 'unresolved) + (let* ((guard (make-guardian)) +(total 1000)) + --- a/test-suite/tests/threads.test +++ b/test-suite/tests/threads.test @@ -366,6 +366,7 @@ ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] python-x.y.z-wrapper vs python-x.y.z-full
Hi Peter, > > But there are plenty of "-wrapper"s, but only ghc and python use it > > as a suffix _after_ the version. This results in python-2.7.1 being > > "upgraded" to python-2.7.1-wrapper by 'nix-env -u \*'. > > apparently, you consider that a problem? Why is that? Because -u relies on an algorithm similar to that of strverscmp(3) to determine what the newest version of a package is. Consequently, it fails to make a meaningful decision if the last component of the name is not a version number. Thanks, Ludo’. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] SVN commit: nix - r29745 - nix/trunk/tests
Author: eelco
Date: Mon Oct 10 21:32:34 2011
New Revision: 29745
URL: https://nixos.org/websvn/nix/?rev=29745&sc=1
Log:
* Refactoring: remove unnecessary variables from the tests.
Modified:
nix/trunk/tests/add.sh
nix/trunk/tests/binary-patching.sh
nix/trunk/tests/build-hook.sh
nix/trunk/tests/check-refs.sh
nix/trunk/tests/common.sh.in
nix/trunk/tests/dependencies.sh
nix/trunk/tests/export-graph.sh
nix/trunk/tests/export.sh
nix/trunk/tests/fallback.sh
nix/trunk/tests/filter-source.sh
nix/trunk/tests/fixed.sh
nix/trunk/tests/gc-concurrent.sh
nix/trunk/tests/gc-runtime.sh
nix/trunk/tests/gc.sh
nix/trunk/tests/hash.sh
nix/trunk/tests/init.sh
nix/trunk/tests/install-package.sh
nix/trunk/tests/lang.sh
nix/trunk/tests/logging.sh
nix/trunk/tests/misc.sh
nix/trunk/tests/negative-caching.sh
nix/trunk/tests/nix-build.sh
nix/trunk/tests/nix-pull.sh
nix/trunk/tests/nix-push.sh
nix/trunk/tests/parallel.sh
nix/trunk/tests/referrers.sh
nix/trunk/tests/secure-drv-outputs.sh
nix/trunk/tests/simple.sh
nix/trunk/tests/substitutes.sh
nix/trunk/tests/substitutes2.sh
nix/trunk/tests/timeout.sh
nix/trunk/tests/user-envs.sh
nix/trunk/tests/verify.sh
Modified: nix/trunk/tests/add.sh
==
--- nix/trunk/tests/add.sh Mon Oct 10 21:30:59 2011(r29744)
+++ nix/trunk/tests/add.sh Mon Oct 10 21:32:34 2011(r29745)
@@ -1,9 +1,9 @@
source common.sh
-path1=$($nixstore --add ./dummy)
+path1=$(nix-store --add ./dummy)
echo $path1
-path2=$($nixstore --add-fixed sha256 --recursive ./dummy)
+path2=$(nix-store --add-fixed sha256 --recursive ./dummy)
echo $path2
if test "$path1" != "$path2"; then
@@ -11,18 +11,18 @@
exit 1
fi
-path3=$($nixstore --add-fixed sha256 ./dummy)
+path3=$(nix-store --add-fixed sha256 ./dummy)
echo $path3
test "$path1" != "$path3" || exit 1
-path4=$($nixstore --add-fixed sha1 --recursive ./dummy)
+path4=$(nix-store --add-fixed sha1 --recursive ./dummy)
echo $path4
test "$path1" != "$path4" || exit 1
-hash1=$($nixstore -q --hash $path1)
+hash1=$(nix-store -q --hash $path1)
echo $hash1
-hash2=$($nixhash --type sha256 --base32 ./dummy)
+hash2=$(nix-hash --type sha256 --base32 ./dummy)
echo $hash2
test "$hash1" = "sha256:$hash2"
Modified: nix/trunk/tests/binary-patching.sh
==
--- nix/trunk/tests/binary-patching.sh Mon Oct 10 21:30:59 2011(r29744)
+++ nix/trunk/tests/binary-patching.sh Mon Oct 10 21:32:34 2011(r29745)
@@ -8,12 +8,12 @@
# Build version 1 and 2 of the "foo" package.
nix-push --copy $TEST_ROOT/cache2 $TEST_ROOT/manifest1 \
-$($nixbuild -o $RESULT binary-patching.nix --arg version 1)
+$(nix-build -o $RESULT binary-patching.nix --arg version 1)
-out2=$($nixbuild -o $RESULT binary-patching.nix --arg version 2)
+out2=$(nix-build -o $RESULT binary-patching.nix --arg version 2)
nix-push --copy $TEST_ROOT/cache2 $TEST_ROOT/manifest2 $out2
-out3=$($nixbuild -o $RESULT binary-patching.nix --arg version 3)
+out3=$(nix-build -o $RESULT binary-patching.nix --arg version 3)
nix-push --copy $TEST_ROOT/cache2 $TEST_ROOT/manifest3 $out3
rm $RESULT
@@ -28,19 +28,19 @@
grep -q "patch {" $TEST_ROOT/manifest3
# Get rid of versions 2 and 3.
-$nixstore --delete $out2 $out3
+nix-store --delete $out2 $out3
# Pull the manifest containing the patches.
clearManifests
-$NIX_BIN_DIR/nix-pull file://$TEST_ROOT/manifest3
+nix-pull file://$TEST_ROOT/manifest3
# Make sure that the download size prediction uses the patches rather
# than the full download.
-$nixbuild -o $RESULT binary-patching.nix --arg version 3 --dry-run 2>&1 | grep
-q "0.01 MiB"
+nix-build -o $RESULT binary-patching.nix --arg version 3 --dry-run 2>&1 | grep
-q "0.01 MiB"
# Now rebuild it. This should use the two patches generated above.
rm -f $TEST_ROOT/var/log/nix/downloads
-$nixbuild -o $RESULT binary-patching.nix --arg version 3
+nix-build -o $RESULT binary-patching.nix --arg version 3
rm $RESULT
[ "$(grep ' patch ' $TEST_ROOT/var/log/nix/downloads | wc -l)" -eq 2 ]
@@ -50,9 +50,9 @@
# Rebuild version 3. This should use the direct patch rather than the
# sequence of two patches.
-$nixstore --delete $out2 $out3
+nix-store --delete $out2 $out3
clearManifests
rm $TEST_ROOT/var/log/nix/downloads
-$NIX_BIN_DIR/nix-pull file://$TEST_ROOT/manifest3
-$nixbuild -o $RESULT binary-patching.nix --arg version 3
+nix-pull file://$TEST_ROOT/manifest3
+nix-build -o $RESULT binary-patching.nix --arg version 3
[ "$(grep ' patch ' $TEST_ROOT/var/log/nix/downloads | wc -l)" -eq 1 ]
Modified: nix/trunk/tests/build-hook.sh
==
--- nix/trunk/tests/build-hook.sh Mon Oct 10 21:30:59 2011(r29744)
+++ nix/trunk/tests/build-hook.sh
[Nix-commits] SVN commit: nix - r29855 - nixos/trunk/modules/system/boot
Author: NicolasPierron
Date: Sat Oct 15 21:01:30 2011
New Revision: 29855
URL: https://nixos.org/websvn/nix/?rev=29855&sc=1
Log:
Add support for NFS root file system.
Patch by Rickard Nilsson.
Modified:
nixos/trunk/modules/system/boot/stage-1-init.sh
nixos/trunk/modules/system/boot/stage-1.nix
Modified: nixos/trunk/modules/system/boot/stage-1-init.sh
==
--- nixos/trunk/modules/system/boot/stage-1-init.sh Sat Oct 15 16:34:26
2011(r29854)
+++ nixos/trunk/modules/system/boot/stage-1-init.sh Sat Oct 15 21:01:30
2011(r29855)
@@ -221,8 +221,10 @@
# For CIFS mounts, retry a few times before giving up.
local n=0
while true; do
-if mount -t "$fsType" -o "$options" "$device" /mnt-root$mountPoint;
then
-break
+if [ "$fsType" = "nfs" ]; then
+ nfsmount "$device" "/mnt-root$mountPoint" && break
+else
+ mount -t "$fsType" -o "$options" "$device" "/mnt-root$mountPoint" &&
break
fi
if [ "$fsType" != cifs -o "$n" -ge 10 ]; then fail; break; fi
echo "retrying..."
Modified: nixos/trunk/modules/system/boot/stage-1.nix
==
--- nixos/trunk/modules/system/boot/stage-1.nix Sat Oct 15 16:34:26 2011
(r29854)
+++ nixos/trunk/modules/system/boot/stage-1.nix Sat Oct 15 21:01:30 2011
(r29855)
@@ -169,6 +169,11 @@
cp
${kernelPackages.splashutils}/${kernelPackages.splashutils.helperName}
$out/bin/splash_helper
''}
+ # Copy nfsmount if there is any NFS mounts required for boot.
+ ${optionalString (filter (fs: fs.fsType == "nfs" && (fs.mountPoint ==
"/" || fs.neededForBoot)) fileSystems != []) ''
+cp -v ${pkgs.klibc}/lib/klibc/bin.static/nfsmount $out/bin
+ ''}
+
${config.boot.initrd.extraUtilsCommands}
# Run patchelf to make the programs refer to the copied libraries.
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] SVN commit: nix - r29856 - nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4
Author: ludo
Date: Sat Oct 15 23:25:12 2011
New Revision: 29856
URL: https://nixos.org/websvn/nix/?rev=29856&sc=1
Log:
GNU M4: Have a test work around flaws in newer Linux versions.
Added:
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/readlink-EINVAL.patch
Modified:
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/default.nix
Modified:
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/default.nix
==
---
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/default.nix
Sat Oct 15 21:01:30 2011(r29855)
+++
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/default.nix
Sat Oct 15 23:25:12 2011(r29856)
@@ -11,7 +11,7 @@
doCheck = !stdenv.isDarwin;
# Upstream is aware of it; it may be in the next release.
- patches = [ ./s_isdir.patch ];
+ patches = [ ./s_isdir.patch ./readlink-EINVAL.patch ];
meta = {
homepage = http://www.gnu.org/software/m4/;
Added:
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/readlink-EINVAL.patch
==
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++
nixpkgs/branches/stdenv-updates/pkgs/development/tools/misc/gnum4/readlink-EINVAL.patch
Sat Oct 15 23:25:12 2011(r29856)
@@ -0,0 +1,18 @@
+Newer Linux kernels would return EINVAL instead of ENOENT.
+The patch below, taken from Gnulib, allows the test to pass when
+these Linux versions are in use:
+https://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00308.html .
+
+diff --git a/tests/test-readlink.h b/tests/test-readlink.h
+index 08d5662..7247fc4 100644
+--- a/tests/test-readlink.h
b/tests/test-readlink.h
+@@ -38,7 +38,7 @@ test_readlink (ssize_t (*func) (char const *, char *,
size_t), bool print)
+ ASSERT (errno == ENOENT);
+ errno = 0;
+ ASSERT (func ("", buf, sizeof buf) == -1);
+- ASSERT (errno == ENOENT);
++ ASSERT (errno == ENOENT || errno == EINVAL);
+ errno = 0;
+ ASSERT (func (".", buf, sizeof buf) == -1);
+ ASSERT (errno == EINVAL);
___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits
