Re: [Nix-dev] Encrypted root: LUKS over LVM
It looks like nixos is trying to run fsck after mounting the filesystem (somehow I missed this when I looked at your e-mail before). I don't know what would cause this. Can you send us your hardware-configuration.nix? James On 6 January 2015 at 23:47, Nikita Karetnikov nik...@karetnikov.org wrote: That's odd. Do you have any idea why e2fsck is failing? Nope. What happens if you run e2fsck -n /dev/main/main after booting? # e2fsck -n /dev/main/main e2fsck 1.42.12 (29-Aug-2014) Warning! /dev/main/main is mounted. Warning: skipping journal recovery because doing a read-only filesystem check. /dev/main/main: clean, 73550/7577600 files, 862949/30286848 blocks ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
On 01/09/2015 10:27 PM, Thomas Hunger wrote:
One thing that'd be useful is documenting how
pkgs/development/haskell-modules/hackage-packages.nix is regenerated and
how to fix common issues.
E.g. disabling tests done by overriding a package in
haskell-modules/configuration-common.nix. But I don't understand how to
retain a specific version of a package (e.g. you have time_1_5_0_1 in
there, how did you do that?).
~
I second the request for a few words of how the nixpkgs collaborators
should now work with adding/fixing/updating/retaining the Haskell
package set. In the past it was cabal2nix the package, stick it in
libraries and add to haskell-packages.nix . What is it now?
On 9 January 2015 at 18:11, Peter Simons sim...@cryp.to wrote:
Hi Thomas,
I changed my sandbox code to look like the following. Is that how it's
intended to be used?
yes, exactly. That's a very nice example. You can put that definition into
a
file, say shell.nix, and run
$ nix-shell --pure shell.nix
to obtain an interactive environment that contains the compiler defined
above.
If you want to go all out, you can also add a shellHook attribute to make
nix-shell define the magic environment variables that tell the 'ghc-paths'
package how to use your environment. For example:
| { pkgs ? (import nixpkgs {}).pkgs }:
|
| let
|
| env = pkgs.haskellngPackages.ghcWithPackages (p: with p; [
| text mtl transformers warp cabal-install
| ]);
|
| in
|
| pkgs.stdenv.mkDerivation {
| name = hello-world-wide-web;
| buildInputs = [ env ];
| shellHook = ''
| export NIX_GHC=${env}/bin/ghc
| export NIX_GHCPKG=${env}/bin/ghc-pkg
| export NIX_GHC_DOCDIR=${env}/share/doc/ghc/html
| export NIX_GHC_LIBDIR=$( $NIX_GHC --print-libdir )
| '';
| }
Best regards,
Peter
___
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
--
Mateusz K.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
Hi Thomas,
I changed my sandbox code to look like the following. Is that how it's
intended to be used?
yes, exactly. That's a very nice example. You can put that definition into a
file, say shell.nix, and run
$ nix-shell --pure shell.nix
to obtain an interactive environment that contains the compiler defined above.
If you want to go all out, you can also add a shellHook attribute to make
nix-shell define the magic environment variables that tell the 'ghc-paths'
package how to use your environment. For example:
| { pkgs ? (import nixpkgs {}).pkgs }:
|
| let
|
| env = pkgs.haskellngPackages.ghcWithPackages (p: with p; [
| text mtl transformers warp cabal-install
| ]);
|
| in
|
| pkgs.stdenv.mkDerivation {
| name = hello-world-wide-web;
| buildInputs = [ env ];
| shellHook = ''
| export NIX_GHC=${env}/bin/ghc
| export NIX_GHCPKG=${env}/bin/ghc-pkg
| export NIX_GHC_DOCDIR=${env}/share/doc/ghc/html
| export NIX_GHC_LIBDIR=$( $NIX_GHC --print-libdir )
| '';
| }
Best regards,
Peter
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
This is really cool!
I changed my sandbox code to look like the following. Is that how it's
intended to be used?
{ haskellngPackages ? (import nixpkgs {}).haskellngPackages,
pkgs ? (import nixpkgs {}).pkgs }:
let
env = haskellngPackages.ghcWithPackages (p: [
p.text
p.mtl
p.transformers
p.warp
p.cabal-install
]);
in
pkgs.myEnvFun {
name = hello-world-wide-web;
buildInputs = [ env ];
}
On 9 January 2015 at 15:46, Peter Simons sim...@cryp.to wrote:
Dear Haskellers `intersect` Nixers,
this is the first installment of a series of postings to describe technical
aspects of the re-factored Haskell infrastructure. When this is all done, I
intend to use these articles to create some kind of *gasp* user
documentation
for the Nixpkgs manual. So I encourage everyone to point out of omissions
and
technical errors, or to ask for clarification if something is vague or
misleading. I've chosen an FAQ-style approach because I felt that this is
easiest for me to write. Hopefully this translates into the document being
easy
to read, too! Here we go ...
Why should I care about this new infrastructure?
--
The new code will break evaluation of any Haskell-related configuration
you
may have in ~/.nixpkgs/config.nix or /etc/nixos/configuration.nix.
Privately generated cabal2nix expressions will cease to compile.
Installations that rely on ghc-wrapper finding GHC libraries
automatically in
your ~/.nix-profile are obsolete. If you use this approach, you won't be
able
to update your profile anymore.
Duh, I don't want that!
---
You can stick to the established 'haskellPackages' set, if you prefer.
The
new code exists separately in 'haskellngPackages', and it's invisible to
nix-env -i package-name and nix-env -u. If you don't make a
conscious
effort to switch, you won't see any of it.
So I'll never have to update if I don't want to?
My guess is that 'haskellPackages' and 'haskellngPackages' will co-exist
for
a while. Personally, I switched to Haskell NG, though, and I won't
maintain
any packages in the old hierarchy anymore. I suppose other contributors
will
do the same thing. Once you've converted your setup to
'haskellngPackages',
there's no reason to look back, really.
In other words, you don't have to convert your setup *right now*, but at
some
point in the future you will probably have to.
Is it difficult to migrate to Haskell NG?
-
Users of 'ghcWithPackages' can easily switch back and forth between both
package sets. Your ~/.nixpkgs/config.nix file probably defines an
attribute
like this one:
| {
| packageOverrides = super: let self = super.pkgs; in
| {
| haskellEnv = self.haskellPackages.ghcWithPackages (p: with p; [
| async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
| ]);
| };
| }
Change this definition as follows to switch to Haskell NG:
| {
| provideOldHaskellAttributeNames = true;
|
| packageOverrides = super: let self = super.pkgs; in
| {
| haskellEnv = self.haskellngPackages.ghcWithPackages (p: with p; [
| async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
| ]);
| };
| }
There are only two differences: the ng bit in the name of the package
set,
and the new 'provideOldHaskellAttributeNames' config attribute. (Note
that
this lives at the top level of ~/.nixpkgs/config.nix -- not inside of
'packageOverrides'.)
Users of the ghc-wrapper have to make a greater effort, I'm afraid,
because
ghc-wrapper no longer exists in the NG code. You'll have to switch to
'ghcWithPackages' first. You may find this article helpful for the
process:
http://permalink.gmane.org/gmane.linux.distributions.nixos/15161.
What does 'provideOldHaskellAttributeNames' do?
---
The package 'cabal-install' has the attribute 'cabalInstall' in the old
package set. In the new one, however, the attribute is now called
'cabal-install' -- just like the package. provideOldHaskellAttributeNames
enables a compatibility layer that defins the old camel-case style names
on
top of the new ones. This allows you to use the same configuration for
both
the new and old package sets.
Once you feel ready to migrate permanently to NG code, you can switch the
compatibility layer off, to ensure that all your definition use the new
names
consistently.
Why is the ghc-wrapper gone?
ghc-wrapper's underlying promise is that you can install a random Haskell
package into your Nix profile, and GHC will pick it up from there
automatically. Now, this worked reasonably well for many packages, but
for
may other packages it didn't work, and
[Nix-dev] botan
The generic part of the nixpkgs expression for botan refers to both the bzip
download and the gzip download. The given hash corresponds to the gzip one
and generates a hash mismatch error. The attached patch downloads the
gzipped one to match the given hash.
From 1c81a7c099889af2d1d0a11e5666184e2c87674b Mon Sep 17 00:00:00 2001
From: Karn Kallio kkal...@skami.org
Date: Fri, 9 Jan 2015 12:45:02 -0430
Subject: [PATCH] botan: use the tgz tarball (removing confusion with tbz).
---
pkgs/development/libraries/botan/generic.nix | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/pkgs/development/libraries/botan/generic.nix b/pkgs/development/libraries/botan/generic.nix
index 791731e..8d68009 100644
--- a/pkgs/development/libraries/botan/generic.nix
+++ b/pkgs/development/libraries/botan/generic.nix
@@ -10,7 +10,7 @@ stdenv.mkDerivation rec {
src = fetchurl {
name = Botan-${version}.tgz;
-url = http://files.randombit.net/botan/v${baseVersion}/Botan-${version}.tbz;;
+url = http://files.randombit.net/botan/v${baseVersion}/Botan-${version}.tgz;;
inherit sha256;
};
--
2.1.4
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] A Journey into the Haskell NG infrastructure: Part I
Dear Haskellers `intersect` Nixers,
this is the first installment of a series of postings to describe technical
aspects of the re-factored Haskell infrastructure. When this is all done, I
intend to use these articles to create some kind of *gasp* user documentation
for the Nixpkgs manual. So I encourage everyone to point out of omissions and
technical errors, or to ask for clarification if something is vague or
misleading. I've chosen an FAQ-style approach because I felt that this is
easiest for me to write. Hopefully this translates into the document being easy
to read, too! Here we go ...
Why should I care about this new infrastructure?
--
The new code will break evaluation of any Haskell-related configuration you
may have in ~/.nixpkgs/config.nix or /etc/nixos/configuration.nix.
Privately generated cabal2nix expressions will cease to compile.
Installations that rely on ghc-wrapper finding GHC libraries automatically in
your ~/.nix-profile are obsolete. If you use this approach, you won't be able
to update your profile anymore.
Duh, I don't want that!
---
You can stick to the established 'haskellPackages' set, if you prefer. The
new code exists separately in 'haskellngPackages', and it's invisible to
nix-env -i package-name and nix-env -u. If you don't make a conscious
effort to switch, you won't see any of it.
So I'll never have to update if I don't want to?
My guess is that 'haskellPackages' and 'haskellngPackages' will co-exist for
a while. Personally, I switched to Haskell NG, though, and I won't maintain
any packages in the old hierarchy anymore. I suppose other contributors will
do the same thing. Once you've converted your setup to 'haskellngPackages',
there's no reason to look back, really.
In other words, you don't have to convert your setup *right now*, but at some
point in the future you will probably have to.
Is it difficult to migrate to Haskell NG?
-
Users of 'ghcWithPackages' can easily switch back and forth between both
package sets. Your ~/.nixpkgs/config.nix file probably defines an attribute
like this one:
| {
| packageOverrides = super: let self = super.pkgs; in
| {
| haskellEnv = self.haskellPackages.ghcWithPackages (p: with p; [
| async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
| ]);
| };
| }
Change this definition as follows to switch to Haskell NG:
| {
| provideOldHaskellAttributeNames = true;
|
| packageOverrides = super: let self = super.pkgs; in
| {
| haskellEnv = self.haskellngPackages.ghcWithPackages (p: with p; [
| async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
| ]);
| };
| }
There are only two differences: the ng bit in the name of the package set,
and the new 'provideOldHaskellAttributeNames' config attribute. (Note that
this lives at the top level of ~/.nixpkgs/config.nix -- not inside of
'packageOverrides'.)
Users of the ghc-wrapper have to make a greater effort, I'm afraid, because
ghc-wrapper no longer exists in the NG code. You'll have to switch to
'ghcWithPackages' first. You may find this article helpful for the process:
http://permalink.gmane.org/gmane.linux.distributions.nixos/15161.
What does 'provideOldHaskellAttributeNames' do?
---
The package 'cabal-install' has the attribute 'cabalInstall' in the old
package set. In the new one, however, the attribute is now called
'cabal-install' -- just like the package. provideOldHaskellAttributeNames
enables a compatibility layer that defins the old camel-case style names on
top of the new ones. This allows you to use the same configuration for both
the new and old package sets.
Once you feel ready to migrate permanently to NG code, you can switch the
compatibility layer off, to ensure that all your definition use the new names
consistently.
Why is the ghc-wrapper gone?
ghc-wrapper's underlying promise is that you can install a random Haskell
package into your Nix profile, and GHC will pick it up from there
automatically. Now, this worked reasonably well for many packages, but for
may other packages it didn't work, and those cases caused us a lot trouble,
bug reports, and heated discussions in the past, and we ended up adding more
and more layers of plumbing around xmonad, ghc-mod, and whatnot in an attempt
to rescue the idea that GHC would somehow find packages automatically without
being told about them.
In the NG infrastructure, this whole notion has been abandoned. The proper
way to install ghc is trough the 'ghcWithPackages' function. It knows about
exactly those packages that you tell it to. It's slightly more effort to
define your Haskell environment this way,
Re: [Nix-dev] A Journey into the Haskell NG infrastructure: Part I
One thing that'd be useful is documenting how
pkgs/development/haskell-modules/hackage-packages.nix is regenerated and
how to fix common issues.
E.g. disabling tests done by overriding a package in
haskell-modules/configuration-common.nix. But I don't understand how to
retain a specific version of a package (e.g. you have time_1_5_0_1 in
there, how did you do that?).
~
On 9 January 2015 at 18:11, Peter Simons sim...@cryp.to wrote:
Hi Thomas,
I changed my sandbox code to look like the following. Is that how it's
intended to be used?
yes, exactly. That's a very nice example. You can put that definition into
a
file, say shell.nix, and run
$ nix-shell --pure shell.nix
to obtain an interactive environment that contains the compiler defined
above.
If you want to go all out, you can also add a shellHook attribute to make
nix-shell define the magic environment variables that tell the 'ghc-paths'
package how to use your environment. For example:
| { pkgs ? (import nixpkgs {}).pkgs }:
|
| let
|
| env = pkgs.haskellngPackages.ghcWithPackages (p: with p; [
| text mtl transformers warp cabal-install
| ]);
|
| in
|
| pkgs.stdenv.mkDerivation {
| name = hello-world-wide-web;
| buildInputs = [ env ];
| shellHook = ''
| export NIX_GHC=${env}/bin/ghc
| export NIX_GHCPKG=${env}/bin/ghc-pkg
| export NIX_GHC_DOCDIR=${env}/share/doc/ghc/html
| export NIX_GHC_LIBDIR=$( $NIX_GHC --print-libdir )
| '';
| }
Best regards,
Peter
___
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] A Journey into the Haskell NG infrastructure: Part I
Hi Peter,
this sounds very nice, thanks for all of the work you've put into
nix-haskell!
One immediate question I have is how to translate local haskell
packages (e.g. as described by [1]) into the haskellng regime. If I just
replace `haskellPackages` with `haskellngPackages` I get the following
error:
error: anonymous function at
/Users/gridaphobe/Source/nixpkgs/pkgs/development/haskell-modules/default.nix:1:1
called with unexpected argument ‘extension’, at
/Users/gridaphobe/Source/nixpkgs/lib/customisation.nix:58:12
Thanks!
Eric
[1]:
https://nixos.org/wiki/Haskell#Maintaining_your_own_set_of_additional_Haskell_packages
On Fri, Jan 9, 2015, at 07:46, Peter Simons wrote:
Dear Haskellers `intersect` Nixers,
this is the first installment of a series of postings to describe
technical
aspects of the re-factored Haskell infrastructure. When this is all done,
I
intend to use these articles to create some kind of *gasp* user
documentation
for the Nixpkgs manual. So I encourage everyone to point out of omissions
and
technical errors, or to ask for clarification if something is vague or
misleading. I've chosen an FAQ-style approach because I felt that this is
easiest for me to write. Hopefully this translates into the document
being easy
to read, too! Here we go ...
Why should I care about this new infrastructure?
--
The new code will break evaluation of any Haskell-related configuration
you
may have in ~/.nixpkgs/config.nix or /etc/nixos/configuration.nix.
Privately generated cabal2nix expressions will cease to compile.
Installations that rely on ghc-wrapper finding GHC libraries
automatically in
your ~/.nix-profile are obsolete. If you use this approach, you won't
be able
to update your profile anymore.
Duh, I don't want that!
---
You can stick to the established 'haskellPackages' set, if you prefer.
The
new code exists separately in 'haskellngPackages', and it's invisible
to
nix-env -i package-name and nix-env -u. If you don't make a
conscious
effort to switch, you won't see any of it.
So I'll never have to update if I don't want to?
My guess is that 'haskellPackages' and 'haskellngPackages' will
co-exist for
a while. Personally, I switched to Haskell NG, though, and I won't
maintain
any packages in the old hierarchy anymore. I suppose other contributors
will
do the same thing. Once you've converted your setup to
'haskellngPackages',
there's no reason to look back, really.
In other words, you don't have to convert your setup *right now*, but
at some
point in the future you will probably have to.
Is it difficult to migrate to Haskell NG?
-
Users of 'ghcWithPackages' can easily switch back and forth between
both
package sets. Your ~/.nixpkgs/config.nix file probably defines an
attribute
like this one:
| {
| packageOverrides = super: let self = super.pkgs; in
| {
| haskellEnv = self.haskellPackages.ghcWithPackages (p: with p; [
| async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
| ]);
| };
| }
Change this definition as follows to switch to Haskell NG:
| {
| provideOldHaskellAttributeNames = true;
|
| packageOverrides = super: let self = super.pkgs; in
| {
| haskellEnv = self.haskellngPackages.ghcWithPackages (p: with p; [
| async attoparsec caseInsensitive fgl GLUT GLURaw haskellSrc
| ]);
| };
| }
There are only two differences: the ng bit in the name of the package
set,
and the new 'provideOldHaskellAttributeNames' config attribute. (Note
that
this lives at the top level of ~/.nixpkgs/config.nix -- not inside of
'packageOverrides'.)
Users of the ghc-wrapper have to make a greater effort, I'm afraid,
because
ghc-wrapper no longer exists in the NG code. You'll have to switch to
'ghcWithPackages' first. You may find this article helpful for the
process:
http://permalink.gmane.org/gmane.linux.distributions.nixos/15161.
What does 'provideOldHaskellAttributeNames' do?
---
The package 'cabal-install' has the attribute 'cabalInstall' in the old
package set. In the new one, however, the attribute is now called
'cabal-install' -- just like the package.
provideOldHaskellAttributeNames
enables a compatibility layer that defins the old camel-case style
names on
top of the new ones. This allows you to use the same configuration for
both
the new and old package sets.
Once you feel ready to migrate permanently to NG code, you can switch
the
compatibility layer off, to ensure that all your definition use the new
names
consistently.
Why is the ghc-wrapper gone?
