Re: [Nix-dev] nix-shell dropping into a shell without anything new
On Mon, Apr 27, 2015, at 03:56 PM, Ramakrishnan Muthukrishnan wrote: Hi, Sorry for the badly worded subject line. NixOS newbie here. Playing with NixOS on a VirtualBox installation and really really liking it so far. I am using nix-shell and the quick start example in the manual (step #6 listed here: https://nixos.org/nix/manual/) does not seem to work for me: [ram@nixos:~] nix-shell -p hello these paths will be fetched (0.04 MiB ... *** Downloading [ram@nixos:~]$ hello The program `hello' is currently not installed ... ... [ram@nixos:~]$ exit [ram@nixos:~]$ Note that the prompt string didn't change when we entered the nix-shell. If I do: [ram@nixos:~]$ nix-shell -p hello --pure [nix-shell:~]$ hello Hello, world! [nix-shell:~]$ I wonder why without --pure it didn't get into the shell. Would appreciate any help. The nix-env version is: [ram@nixos:~]$ nix-env --version nix-env (Nix) 1.9pre4088_1711679 -- Ramakrishnan Err and err and err again, but less and less and less ⟶ Piet Hein ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] nix-shell dropping into a shell without anything new
Hi, Sorry for the badly worded subject line. NixOS newbie here. Playing with NixOS on a VirtualBox installation and really really liking it so far. I am using nix-shell and the quick start example in the manual (step #6 listed here: https://nixos.org/nix/manual/) does not seem to work for me: [ram@nixos:~] nix-shell -p hello these paths will be fetched (0.04 MiB ... *** Downloading [ram@nixos:~]$ hello The program `hello' is currently not installed ... ... [ram@nixos:~]$ exit [ram@nixos:~]$ Note that the prompt string didn't change when we entered the nix-shell. If I do: [ram@nixos:~]$ nix-shell -p hello --pure [nix-shell:~]$ hello Hello, world! [nix-shell:~]$ I wonder why without --pure it didn't get into the shell. Would appreciate any help. thanks -- Ramakrishnan Err and err and err again, but less and less and less ⟶ Piet Hein ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Loading a shared object into the compiler at build time fails
Thanks all of you. I added the following to my dependee (bin_prot) and it
worked nicely.
setupHook = writeText setupHook.sh ''
export
CAML_LD_LIBRARY_PATH=''${CAML_LD_LIBRARY_PATH}''${CAML_LD_LIBRARY_PATH:+:}''$1/lib/ocaml/${ocaml_version}/site-lib/bin_prot/
'';
On Mon, Apr 27, 2015 at 12:37 PM, Vladimír Čunát vcu...@gmail.com wrote:
On 04/27/2015 09:14 PM, Vincent Laporte wrote:
Le 2015-04-27 21:08, Vladimír Čunát a ēcrit :
On 04/27/2015 09:03 PM, Eric Merritt wrote:
When ocaml build B, then it fails because it can't load the *.so
that is part of A.
That all seems to boil down to the question: how are those
so-files searched for? (by the ocaml compiler, I guess, or by
what?)
The compiler looks in the colon-separated list of directories given in
the CAML_LD_LIBRARY_PATH environment variable.
If that pattern recurs in ocaml-built packages, I'd expect the compiler
to define an envHook to automatically extend that variable by build
inputs containing such modules. We have already a few very similar cases
in nixpkgs, e.g.:
https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/logic/coq/default.nix#L50
Vladimir
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Loading a shared object into the compiler at build time fails
On 04/27/2015 09:14 PM, Vincent Laporte wrote: Le 2015-04-27 21:08, Vladimír Čunát a ēcrit : On 04/27/2015 09:03 PM, Eric Merritt wrote: When ocaml build B, then it fails because it can't load the *.so that is part of A. That all seems to boil down to the question: how are those so-files searched for? (by the ocaml compiler, I guess, or by what?) The compiler looks in the colon-separated list of directories given in the CAML_LD_LIBRARY_PATH environment variable. If that pattern recurs in ocaml-built packages, I'd expect the compiler to define an envHook to automatically extend that variable by build inputs containing such modules. We have already a few very similar cases in nixpkgs, e.g.: https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/science/logic/coq/default.nix#L50 Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] A Journey into our brand-new Haskell infrastructure: Part III
Hi folks, just a quick update for your information: we now have fully automatic updates of hackages-packages.nix. The process is driven by the update-nixpkgs.sh script [1], which is part of the cabal2nix Git repository [2]. Basically, that script re-generates hackages-packages.nix once per hour from the current state of Hackage (which [3] tracks in a Git repository) and pushes the result to [4]. From there, Hydra [5] picks up the new version and builds everything. We do not merge those updates to 'master' automatically, though. Instead, a human being can decide to do that by choosing a relatively stable version of Hackage from [5] and merging revision into 'master'. Personally, I like to squash all those commits into one by running $ git checkout master git pull $ git checkout haskell-updates git pull $ git rebase -i master Now select squash for all but the first commit, and when Git asks you to edit the final commit message, make sure to chose the *last one*. Then push the result to the origin repository: $ git push -v origin haskell-updates:master Note that the commit messages for hackage-packages.nix allow us to re-produce that particular state at any point in time. It says hackage-packages.nix: update to https://github.com/commercialhaskell/all-cabal-files/commit/30bfb9f7 with hackage2nix revision 0d459262 where the first URL identifies the state of Hackage this file was built from, and the second revision identifies the state of hackage2nix that generated the file. Best regards, Peter [1] https://github.com/NixOS/cabal2nix/blob/master/update-nixpkgs.sh [2] https://github.com/NixOS/cabal2nix [3] https://github.com/commercialhaskell/all-cabal-files [4] https://github.com/peti/nixpkgs/tree/haskell-updates [5] http://hydra.cryp.to/jobset/nixpkgs/haskell-updates ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Failed to add route because network is unreachable
I just discovered that I can successfully manually add the route if I
Ieave of the via gateway option:
# ip route add 10.180.0.0/24 src 172.16.48.17 dev eth0
After this I can successfully ping hosts on the other side of the VPN!
I'll just settle with adding this to my local networking commands:
networking.localCommands = ''
ip route add 10.180.0.0/24 src 172.16.48.17 dev eth0 || true
'';
I do wonder though, why adding that route with a via gateway
option gives the aforementioned error.
Cheers,
Bas
On 27 April 2015 at 15:58, Bas van Dijk v.dijk@gmail.com wrote:
Dear Nixers,
I've a slightly off-topic question but since I know there are some
excellent Unix networking experts on this list I hope to get a pointer
in the right direction.
After some changes in my networking setup (I added an IP address to my
eth0 interface) my strongswan VPN service fails to add a route to my
routing table (it used to work before):
installing route: 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
received netlink error: Network is unreachable (101)
If I manually try to add the route I get the same error message:
# ip route add 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
RTNETLINK answers: Network is unreachable
I've asked[1] the same question on the strongswan mailing list but
haven't found a solution yet.
My network settings are fairly simple (note I'm deploying my machine
using nixops to Hetzner):
deployment = {
targetEnv = hetzner;
hetzner = {
mainIPv4 = 136.243.17.41;
...
};
};
networking = {
enableIPv6 = false;
useDHCP = false;
interfaces.eth0.ip4 = [
{ address = 136.243.25.125; prefixLength = 32; }
{ address = 136.243.25.108; prefixLength = 32; }
{ address = 172.16.48.17; prefixLength = 28; }
];
firewall = {
enable= true;
allowPing = true;
allowedTCPPorts = [ ... ];
}
};
Any idea why I can't add that route?
Regards,
Bas
[1] https://lists.strongswan.org/pipermail/users/2015-April/007935.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Failed to add route because network is unreachable
Dear Nixers,
I've a slightly off-topic question but since I know there are some
excellent Unix networking experts on this list I hope to get a pointer
in the right direction.
After some changes in my networking setup (I added an IP address to my
eth0 interface) my strongswan VPN service fails to add a route to my
routing table (it used to work before):
installing route: 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
received netlink error: Network is unreachable (101)
If I manually try to add the route I get the same error message:
# ip route add 10.180.0.0/24 via 136.243.17.1 src 172.16.48.17 dev eth0
RTNETLINK answers: Network is unreachable
I've asked[1] the same question on the strongswan mailing list but
haven't found a solution yet.
My network settings are fairly simple (note I'm deploying my machine
using nixops to Hetzner):
deployment = {
targetEnv = hetzner;
hetzner = {
mainIPv4 = 136.243.17.41;
...
};
};
networking = {
enableIPv6 = false;
useDHCP = false;
interfaces.eth0.ip4 = [
{ address = 136.243.25.125; prefixLength = 32; }
{ address = 136.243.25.108; prefixLength = 32; }
{ address = 172.16.48.17; prefixLength = 28; }
];
firewall = {
enable= true;
allowPing = true;
allowedTCPPorts = [ ... ];
}
};
Any idea why I can't add that route?
Regards,
Bas
[1] https://lists.strongswan.org/pipermail/users/2015-April/007935.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Depending on a service from inside an expression?
Hi, There is a project that as part of its tests has to create a postgresql database which means that the postgres server needs to be running. Is there an easy way to achieve this? How does one go about testing such packages to begin with? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Depending on a service from inside an expression?
It's possible to run postgres with just a unix domain socket for communication, and no network access. Then, you can point your tests at that self-contained postgres environment. Would that work for your situation? On Mon, Apr 27, 2015 at 8:52 PM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk wrote: Hi, There is a project that as part of its tests has to create a postgresql database which means that the postgres server needs to be running. Is there an easy way to achieve this? How does one go about testing such packages to begin with? -- Mateusz K. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH 2/2] nixos-install: Fix chroot flag not defaulting to Bash outside NixOS.
Passing the chroot flag to nixos-install without arguments should now give you a Bash shell as intended rather than try an empty path. This was masked by the user's shell (usually /bin/bash) being defaulted to by chroot, and being found since their paths used NixOS conventions. --- nixos/modules/installer/tools/nixos-install.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/nixos/modules/installer/tools/nixos-install.sh b/nixos/modules/installer/tools/nixos-install.sh index 86e57f7..097631e 100644 --- a/nixos/modules/installer/tools/nixos-install.sh +++ b/nixos/modules/installer/tools/nixos-install.sh @@ -45,7 +45,9 @@ while [ $# -gt 0 ]; do ;; --chroot) runChroot=1 -chrootCommand=($@) +if [[ $@ != ]]; then +chrootCommand=($@) +fi break ;; --help) -- 2.3.6 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH 1/2] nixos-install: Fix password prompt failing outside NixOS.
When bootstrapping from other distributions, nixos-install is unable to find various tools in the chroot since their paths aren't aware of NixOS conventions. This makes a small change to existing code by specifying nixpkgs/nixos instead of just nixos when running nix-instantiate in the chroot. I haven't tested this outside of bootstrapping, but the same specification is used elsewhere in the code so I don't see why it wouldn't work. --- nixos/modules/installer/tools/nixos-install.sh | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/nixos/modules/installer/tools/nixos-install.sh b/nixos/modules/installer/tools/nixos-install.sh index 14ae3da..86e57f7 100644 --- a/nixos/modules/installer/tools/nixos-install.sh +++ b/nixos/modules/installer/tools/nixos-install.sh @@ -254,8 +254,14 @@ NIXOS_INSTALL_GRUB=1 chroot $mountPoint \ chroot $mountPoint /nix/var/nix/profiles/system/activate +# Some systems may not be prepared to use NixOS' paths. +export PATH=/run/current-system/sw/bin:/run/current-system/sw/sbin:$PATH +export NIX_PATH=/nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs +export NIX_PATH=$NIX_PATH:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels + + # Ask the user to set a root password. -if [ $(chroot $mountPoint nix-instantiate --eval 'nixos' -A config.users.mutableUsers) = true ] [ -t 0 ] ; then +if [ $(chroot $mountPoint nix-instantiate --eval 'nixpkgs/nixos' -A config.users.mutableUsers) = true ] [ -t 1 ] ; then echo setting root password... chroot $mountPoint /var/setuid-wrappers/passwd fi -- 2.3.6 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ZFS on NixOS regarding the `/etc/zfs/zpool.cache` file.
Hello, I found the commit relating to my problem: https://github.com/NixOS/nixpkgs/commit/12e77fdc3f6f223be1a4d5c88d6c79bff63ae70c#commitcomment-10932244 I made a comment regarding the lack of zpool.cache file. It's required for `zdb` to work. Perhaps we can generate the `zpool.cache` file at startup? Thanks, Roger On 28/04/2015 3:22 PM, Roger Qiu wrote: Hi, To people using ZFS on NixOS, does your `zdb` command work? I tried using `zdb` and it just gives: ``` cannot open '/etc/zfs/zpool.cache': No such file or directory ``` This file `/etc/zfs/zpool.cache` file does not exist if you follow the instructions regarding installing ZFS on NixOS. This line https://github.com/NixOS/nixos/blob/master/modules/tasks/filesystems/zfs.nix#L6 hints that the current ZFS package doesn't handle the `/etc/zfs/zpool.cache` file. What's missing, and how would we set up the `zpool.cache` file? Thanks, Roger -- Founder of Matrix AI http://matrix.ai/ +61420925975 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH 0/2] Fix nixos-install when running outside NixOS.
Due to issues with environmental variables, nixos-install failed to install when the host operating system wasn't NixOS. This broke bootstrapping from Debian. Jookia (2): nixos-install: Fix password prompt failing outside NixOS. nixos-install: Fix chroot flag not defaulting to Bash outside NixOS. nixos/modules/installer/tools/nixos-install.sh | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) -- 2.3.6 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] ZFS on NixOS regarding the `/etc/zfs/zpool.cache` file.
Hi, To people using ZFS on NixOS, does your `zdb` command work? I tried using `zdb` and it just gives: ``` cannot open '/etc/zfs/zpool.cache': No such file or directory ``` This file `/etc/zfs/zpool.cache` file does not exist if you follow the instructions regarding installing ZFS on NixOS. This line https://github.com/NixOS/nixos/blob/master/modules/tasks/filesystems/zfs.nix#L6 hints that the current ZFS package doesn't handle the `/etc/zfs/zpool.cache` file. What's missing, and how would we set up the `zpool.cache` file? Thanks, Roger -- Founder of Matrix AI http://matrix.ai/ +61420925975 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] texinfo4 seems to have a /bin/sh dependency
I've configured a system using the nix-daemon with build-use-chroot = true and came across the following problem (using the unstable packages) [tyson@test-centos6 .nixpkgs]$ nix-env -iA nixpkgs.texinfo4 installing ‘texinfo-4.13a’ these derivations will be built: /nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv building path(s) ‘/nix/store/39hrhw46j3vww48hasn8zxpq0jkw25ms-texinfo-4.13a’ unpacking sources unpacking source archive /nix/store/9fh76lcx21pf35flmzfh35sya9a4g069-texinfo-4.13a.tar.lzma source root is texinfo-4.13 patching sources configuring configure flags: --disable-dependency-tracking --prefix=/nix/store/39hrhw46j3vww48hasn8zxpq0jkw25ms-texinfo-4.13a /nix/store/3sqnsignf07mwz12fmi9r4g4vigxg3al-stdenv/setup: ./configure: /bin/sh: bad interpreter: No such file or directory builder for ‘/nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv’ failed with exit code 126 error: build of ‘/nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv’ failed If I understand correctly, the issue is that configure in texinfo-4.13a.tar.lzma refers to /bin/sh and this doesn't exist in the chroot environment. Presumably this works if I disable chroot builds but then parts of my external system would be leaking into my nix builds so that seems wrong too. What is the recommended way to proceed here? Am I missing something? Is there some stdenv flag to handle this sort of thing? Should I file a bug? Thanks! -Tyson ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] texinfo4 seems to have a /bin/sh dependency
On NixOS, nix is configured to not only provide the chroot but also /bin/sh compatability. This is fixed in nix 1.9 so I recommend just using the unstable version of nix as it should just work. On Apr 27, 2015 11:42 AM, Tyson Whitehead twhiteh...@gmail.com wrote: I've configured a system using the nix-daemon with build-use-chroot = true and came across the following problem (using the unstable packages) [tyson@test-centos6 .nixpkgs]$ nix-env -iA nixpkgs.texinfo4 installing ‘texinfo-4.13a’ these derivations will be built: /nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv building path(s) ‘/nix/store/39hrhw46j3vww48hasn8zxpq0jkw25ms-texinfo-4.13a’ unpacking sources unpacking source archive /nix/store/9fh76lcx21pf35flmzfh35sya9a4g069-texinfo-4.13a.tar.lzma source root is texinfo-4.13 patching sources configuring configure flags: --disable-dependency-tracking --prefix=/nix/store/39hrhw46j3vww48hasn8zxpq0jkw25ms-texinfo-4.13a /nix/store/3sqnsignf07mwz12fmi9r4g4vigxg3al-stdenv/setup: ./configure: /bin/sh: bad interpreter: No such file or directory builder for ‘/nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv’ failed with exit code 126 error: build of ‘/nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv’ failed If I understand correctly, the issue is that configure in texinfo-4.13a.tar.lzma refers to /bin/sh and this doesn't exist in the chroot environment. Presumably this works if I disable chroot builds but then parts of my external system would be leaking into my nix builds so that seems wrong too. What is the recommended way to proceed here? Am I missing something? Is there some stdenv flag to handle this sort of thing? Should I file a bug? Thanks! -Tyson ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-shell dropping into a shell without anything new -- update
On Mon, Apr 27, 2015, at 03:56 PM, Ramakrishnan Muthukrishnan wrote: Hi, Sorry for the badly worded subject line. NixOS newbie here. Playing with NixOS on a VirtualBox installation and really really liking it so far. I am using nix-shell and the quick start example in the manual (step #6 listed here: https://nixos.org/nix/manual/) does not seem to work for me: [ram@nixos:~] nix-shell -p hello these paths will be fetched (0.04 MiB ... *** Downloading [ram@nixos:~]$ hello The program `hello' is currently not installed ... ... [ram@nixos:~]$ exit [ram@nixos:~]$ Note that the prompt string didn't change when we entered the nix-shell. If I do: [ram@nixos:~]$ nix-shell -p hello --pure [nix-shell:~]$ hello Hello, world! [nix-shell:~]$ I wonder why without --pure it didn't get into the shell. Would appreciate any help. I figured that the behaviour that triggered this is the single line in the /etc/nixos/configuration.nix: programs.bash.enableCompletion = true; If I comment this out, nix-shell runs just fine. This looks like a bug to me. -- Ramakrishnan Err and err and err again, but less and less and less ⟶ Piet Hein ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Loading a shared object into the compiler at build time fails
Guys, I am packaging up some ocaml projects and running into a problem. Certain syntax extensions (bin_prot) include a *.so component that isn't getting picked up. So when another package has that package as dependency it doesn't build, because the code from that package gets loaded during build time. Essentially, its a runtime extension of the compiler and the compiler isn't using the correct paths. So the problem is: package A builds a *.so that needs to be loaded into the compiler. package B depends on package A When ocaml build B, then it fails because it can't load the *.so that is part of A. My suspicion is that I can use the Runtime Environment ( https://nixos.org/wiki/Nix_Runtime_Environment_Wrapper) wrapper to solve this problem. Essentially wrapping the compiler in that script in the same way that firefox does in the example. So my question is, is this the right way to handle this problem? Is there some better way? Eric ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Loading a shared object into the compiler at build time fails
On 04/27/2015 09:03 PM, Eric Merritt wrote: When ocaml build B, then it fails because it can't load the *.so that is part of A. That all seems to boil down to the question: how are those so-files searched for? (by the ocaml compiler, I guess, or by what?) Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Loading a shared object into the compiler at build time fails
On 04/27/2015 09:03 PM, Eric Merritt wrote: When ocaml build B, then it fails because it can't load the *.so that is part of A. That all seems to boil down to the question: how are those so-files searched for? (by the ocaml compiler, I guess, or by what?) Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] texinfo4 seems to have a /bin/sh dependency
I upgraded to nixUnstable (nix-1.9pre4074_e659978) but it does not seem to have resolved this issue 1 - installed the nixpkgs.nixUnstable (nix-1.9pre4074_e659978) package, 2 - switched the default system profile over to it, 3 - restarted the nix-daemon so it is running 1.9 [root@test-centos6:~] killall nix-daemon [root@test-centos6:~] nix-daemon --version nix-daemon (Nix) 1.9pre4074_e659978 [root@test-centos6:~] nix-daemon 4 - re-ran the install command [tyson@test-centos6 ~]$ nix-env --version nix-env (Nix) 1.9pre4074_e659978 [tyson@test-centos6 ~]$ nix-env -iA nixpkgs.texinfo4 installing ‘texinfo-4.13a’ these derivations will be built: /nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv building path(s) ‘/nix/store/39hrhw46j3vww48hasn8zxpq0jkw25ms-texinfo-4.13a’ unpacking sources unpacking source archive /nix/store/9fh76lcx21pf35flmzfh35sya9a4g069-texinfo-4.13a.tar.lzma source root is texinfo-4.13 patching sources configuring configure flags: --disable-dependency-tracking --prefix=/nix/store/39hrhw46j3vww48hasn8zxpq0jkw25ms-texinfo-4.13a /nix/store/3sqnsignf07mwz12fmi9r4g4vigxg3al-stdenv/setup: ./configure: /bin/sh: bad interpreter: No such file or directory builder for ‘/nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv’ failed with exit code 126 error: build of ‘/nix/store/zng3jwybhn7cj2qagslx9hm41w29ab94-texinfo-4.13a.drv’ failed Is this what you had in mind or is there something I'm missing here? Thanks! -Tyson PS: The ps commands shows only the new daemon running. On April 27, 2015 11:53:54 William Kennington wrote: On NixOS, nix is configured to not only provide the chroot but also /bin/sh compatability. This is fixed in nix 1.9 so I recommend just using the unstable version of nix as it should just work. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Loading a shared object into the compiler at build time fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Le 2015-04-27 21:08, Vladimír Čunát a ēcrit : On 04/27/2015 09:03 PM, Eric Merritt wrote: When ocaml build B, then it fails because it can't load the *.so that is part of A. That all seems to boil down to the question: how are those so-files searched for? (by the ocaml compiler, I guess, or by what?) The compiler looks in the colon-separated list of directories given in the CAML_LD_LIBRARY_PATH environment variable. Cheers, - -- Vincent. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVPoodAAoJEEEW/4F+UwyXKEgP/RCBFSFvNpnCLqMhhfJCCFoJ yDE7WcmQ4+nn1OGFQvWpw5XGhnnR/DzMaoKXDWsOjJRTpz01Kynoi1thNiaLWFDW cwMmk4YN+HhFXwsR9cmse+j3Vqg9qYezFchVFHfFBoVamipQzgKzFx8rPjOQN1dn e446svgILwSF2rbN+shjIZ4AZ4/eqv5UYa5aURQ0ZnkAqFaH5yKqtnsM0h1sO0Xw O+bqM4gAv9Mv4L/TH6v689XrU8oNs+4pynjQ2uiUszmCV9WAHM8KJYiZEi90vey9 Ic3Zgdo3xgsIOSbH4C0o7t3WfjtJm2ttugyqEhpJyHBk9jF040QkrPljYsJ4S0ez z71N4P8NDPD/Rb9Eqrb0U+Q+mZ2a1ripmo2sGmFN4JBSd64517QkDApM+FcjwPRp 63GrHCROBamWj8EoEHZJNyep/dS+3XMzhH0muhbDH/t/r5d6eJ+NnDED3QThttAT xQwatpNbhBnoVqNRUCDNZovoBiZahJ3y57OeuR2kc42vCJCoYWtJwQNqZ3IXLlmP NSrRKkgQTM+VLBDzmy+2RSkFO7NnEhknUEzezIfYxGR2+UiKtfjbuoSrnVE7AIhf bhW87a6ax6kBRZSHJL1IJ41Hq6ji1p8i0pMg4XDe3Ol0bhJLjwpg1tgF8x6Wj51y NMBrfywQAhZuLkURdUZ+ =dZON -END PGP SIGNATURE- ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
