[Nix-dev] Haskell NG: Still no binaries
Hello everybody,
today I've attempted to switch to Haskell NG again. The new tree itself
seems to work for me, but I'm still not getting prebuilt binary
packages. The only binary I get is GHC, while every other Haskell
package seems to be compiled from source code.
I've tried with the following reasonably minimal setup. My
~/.nixpkgs/config.nix contains the following code:
nixos : {
packageOverrides = pkgs : rec {
hsEnv = pkgs.haskellngPackages.ghcWithPackages (hs: with hs; [
cabal-install
]);
};
}
In my initial attempt I would have liked to switch to the new GHC as
well, so I've also tried the following override:
hsEnv = pkgs.haskell-ng.packages.ghc7101.ghcWithPackages (hs: with hs; [
cabal-install
]);
I'm on the nixos-unstable channel:
# nix-channel --list
nixos https://nixos.org/channels/nixos-unstable
The commands I've tried to get binary packages were:
nix-env \
--option extra-binary-caches https://hydra.nixos.org \
--option extra-binary-caches https://hydra.cryp.to \
-iA nixos.pkgs.hsEnv
nix-env \
--option extra-binary-caches http://hydra.nixos.org \
--option extra-binary-caches http://hydra.cryp.to \
-iA nixos.pkgs.hsEnv
Neither of them gave me binaries. Am I doing something wrong there?
Background: As noted in an earlier thread my current development machine
is too weak to build everything from source. The build of the GHC
7.10-based environment above took about 30 minutes, and that doesn't
include GHC itself.
Greets,
Ertugrul
signature.asc
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] Added renameImports utility to goBuildPackage
On 16/04/2015 18:51, Domen Kožar wrote: You can easily add docs for just this feature - without waiting for other docs. Start a section for goBuildPackage (you can steal buildPythonPackage snippet) and document only renameImports. Just done ;) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bluetooth status query
It might be a little bit late but I’ve been using an Apple Magic Trackpad for some time (more than a year) without any problems. Without any NixOS-specific problems, to be precise. My bluetooth mouse is also working fine although I don’t use it. On Sat, Apr 4, 2015 at 1:45 PM Sergey Mironov grr...@gmail.com wrote: Hi! I'd like to buy Bluetooth keyboard and headset but I have no experience of setting them up with Linux. What is current status of bluez5, does anybody try to use it? What is the status of pulseaudioFull I saw in nixpkgs? Does it work? Regards, Sergey ___ 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] Haskell NG: Still no binaries
Hi Peter, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv what happpens when you use that command to install the attribute nixos.pkgs.haskell-ng.ghc784.cabal-install and/or nixos.pkgs.haskell-ng.ghc7101.cabal-install? Does your machine get binaries for those attributes? Both are built from source, no binaries except GHC. You are running x86_64-linux, right? That's right. Greets, Ertugrul signature.asc 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] Haskell NG: Still no binaries
Might it be the case that you are running nix in daemon mode and thus it ignores `binary-caches`? On Thu, Apr 16, 2015 at 7:50 PM Ertugrul Söylemez ert...@gmx.de wrote: Hi Peter, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv what happpens when you use that command to install the attribute nixos.pkgs.haskell-ng.ghc784.cabal-install and/or nixos.pkgs.haskell-ng.ghc7101.cabal-install? Does your machine get binaries for those attributes? Both are built from source, no binaries except GHC. You are running x86_64-linux, right? That's right. Greets, Ertugrul ___ 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] Haskell NG: Still no binaries
Hi Ertugrul, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv what happpens when you use that command to install the attribute nixos.pkgs.haskell-ng.ghc784.cabal-install and/or nixos.pkgs.haskell-ng.ghc7101.cabal-install? Does your machine get binaries for those attributes? You are running x86_64-linux, right? Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Added renameImports utility to goBuildPackage
Sometimes git repos get renamed and break go packages because of different import paths. Since today I've added a simple renameImports utility, not sure if that was worth it because it was easy to do without it, anyway: renameImports = [ foo bar baz qux ]; Will rename imports from foo to bar and from baz to qux. The replaced import is a regexp. This code will simply run govers -m foo bar; govers -m baz qux. Since it seems a rather common thing to do, I've decided to add this common code to buildGoPackage, also it will be easier to switch a day to something else than govers (just in case). Hopefully we'll have nixpkgs docs about packaging go stuff a day. Best regards, ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Added renameImports utility to goBuildPackage
You can easily add docs for just this feature - without waiting for other docs. Start a section for goBuildPackage (you can steal buildPythonPackage snippet) and document only renameImports. d. On Thu, Apr 16, 2015 at 12:48 PM, Luca Bruno lethalma...@gmail.com wrote: Sometimes git repos get renamed and break go packages because of different import paths. Since today I've added a simple renameImports utility, not sure if that was worth it because it was easy to do without it, anyway: renameImports = [ foo bar baz qux ]; Will rename imports from foo to bar and from baz to qux. The replaced import is a regexp. This code will simply run govers -m foo bar; govers -m baz qux. Since it seems a rather common thing to do, I've decided to add this common code to buildGoPackage, also it will be easier to switch a day to something else than govers (just in case). Hopefully we'll have nixpkgs docs about packaging go stuff a day. Best regards, ___ 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] Haskell NG: Still no binaries
That did it! Since I'm running NixOS I am indeed running nix-daemon. The following setting did the trick: nix.binaryCaches = [ https://cache.nixos.org/; https://hydra.nixos.org/; ]; IMHO, nix-env should pass those options on to the daemon, i.e. it should not be necessary to hard-code hydra.cryp.to as a global binary cache for this to work. Actually I'm not sure whether this is such a good idea. If it did, it would be a backdoor into fellow system users. An attacker could construct a Nix expression that matches exactly another system user's expression. Then the attacker builds it, but they tell Nix that they have a binary cache available for it, which delivers an infected version of the derivation. When the other system user tries to build the same expression, they find that it is already built, but it is actually the infected substitute injected by the attacker. Just out of curiosity, did you configure nix.trustedBinaryCaches = [ http://hydra.nixos.org http://hydra.cryp.to ]; in your configuration.nix? I didn't. Now that you mention it I briefly remember Nix telling me something about the untrusted binary cache. I just ignored it, assuming that Nix would go ahead and use it anyway. I will try with that setting. But yes, because of the above it's totally sensible that Nix doesn't just use any cache that you tell it to use. Thanks! Greets, Ertugrul signature.asc 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] Binary trust
Hi Kirill, Actually, that’s an interesting question. I always assumed they were signed (AFAIK `nix-store` is able to check signatures contained inside NAR-files), but now I wonder how does hydra.cryp.to sign NAR’s… it's my understanding that the content from binary caches is not signed in any meaningful way. If you're downloading pre-compiled binaries from hydra.cryp.to or anywhere else, then you're living in the Wild West, essentially. Anyone with the ability to mess with those machines (or the transport layer between you and the cache) can inject trojan horses into your system as they please. Best regards, Peter ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH] Fixed zImage installation when building Linux.
When building kernels outputting a zImage, the zImage wasn't correctly copied in to the installation. This broke the build process entirely, at least on my ARM machine. --- pkgs/os-specific/linux/kernel/manual-config.nix | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pkgs/os-specific/linux/kernel/manual-config.nix b/pkgs/os-specific/linux/kernel/manual-config.nix index ea29c7f..620df6d 100644 --- a/pkgs/os-specific/linux/kernel/manual-config.nix +++ b/pkgs/os-specific/linux/kernel/manual-config.nix @@ -116,7 +116,9 @@ let ++ optional installsFirmware INSTALL_FW_PATH=$(out)/lib/firmware; # Some image types need special install targets (e.g. uImage is installed with make uinstall) - installTargets = [ (if platform.kernelTarget == uImage then uinstall else install) ]; + installTargets = [ (if platform.kernelTarget == uImage then uinstall else + if platform.kernelTarget == zImage then zinstall else + install) ]; postInstall = (optionalString installsFirmware '' mkdir -p $out/lib/firmware -- 2.3.3 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG: Still no binaries
On Thu, Apr 16, 2015 at 11:33 PM Ertugrul Söylemez ert...@gmx.de wrote: IMHO, nix-env should pass those options on to the daemon, i.e. it should not be necessary to hard-code hydra.cryp.to as a global binary cache for this to work. Actually I'm not sure whether this is such a good idea. If it did, it would be a backdoor into fellow system users. An attacker could construct a Nix expression that matches exactly another system user's expression. Then the attacker builds it, but they tell Nix that they have a binary cache available for it, which delivers an infected version of the derivation. When the other system user tries to build the same expression, they find that it is already built, but it is actually the infected substitute injected by the attacker. And that’s exactly why Nix won’t allow an untrusted user to use a custom binary cache unless it is listed in `trusted-binary-caches` in `nix.conf`. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Binary trust (was: Haskell NG: Still no binaries)
Actually, that’s an interesting question. I always assumed they were signed (AFAIK `nix-store` is able to check signatures contained inside NAR-files), but now I wonder how does hydra.cryp.to sign NAR’s… On Thu, Apr 16, 2015 at 9:09 PM Ertugrul Söylemez ert...@gmx.de wrote: Hi Kirill, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv Might it be the case that you are running nix in daemon mode and thus it ignores `binary-caches`? That did it! Since I'm running NixOS I am indeed running nix-daemon. The following setting did the trick: nix.binaryCaches = [ https://cache.nixos.org/; https://hydra.nixos.org/; ]; Thanks a lot! Unfortunately hydra.cryp.to does not seem to support TLS. That's why I left it out. But that raises an interesting question: Where do the hash values for the binary packages come from? At this point since we lack deterministic builds I would assume that they come from the same host that delivers the substitutes. A related question is: Are the hashes signed? If the hashes are not trusted, then a plain-text connection would be a huge security risk regardless of whether you trust the host. Even a malicious user or an infected machine on your local network could replace binary packages on their way and get arbitrary code onto your machine. Greets, Ertugrul ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Binary trust
That’s not cool at all. An easy way would be to force TLS. Another option could be to sign NARs with a certificate tied to the hostname of the trusted binary cache and issued by a special NixOS/Nixpkgs CA. On Thu, Apr 16, 2015 at 11:30 PM Peter Simons sim...@cryp.to wrote: Hi Kirill, Actually, that’s an interesting question. I always assumed they were signed (AFAIK `nix-store` is able to check signatures contained inside NAR-files), but now I wonder how does hydra.cryp.to sign NAR’s… it's my understanding that the content from binary caches is not signed in any meaningful way. If you're downloading pre-compiled binaries from hydra.cryp.to or anywhere else, then you're living in the Wild West, essentially. Anyone with the ability to mess with those machines (or the transport layer between you and the cache) can inject trojan horses into your system as they please. 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] [PATCH] Fixed zImage installation when building Linux.
Applied in 98d77cd1a57f3ff71d6ef36e727e339dd9cae233 On Apr 16, 2015, at 5:32 PM, Jookia 166...@gmail.com wrote: When building kernels outputting a zImage, the zImage wasn't correctly copied in to the installation. This broke the build process entirely, at least on my ARM machine. --- pkgs/os-specific/linux/kernel/manual-config.nix | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pkgs/os-specific/linux/kernel/manual-config.nix b/pkgs/os-specific/linux/kernel/manual-config.nix index ea29c7f..620df6d 100644 --- a/pkgs/os-specific/linux/kernel/manual-config.nix +++ b/pkgs/os-specific/linux/kernel/manual-config.nix @@ -116,7 +116,9 @@ let ++ optional installsFirmware INSTALL_FW_PATH=$(out)/lib/firmware; # Some image types need special install targets (e.g. uImage is installed with make uinstall) - installTargets = [ (if platform.kernelTarget == uImage then uinstall else install) ]; + installTargets = [ (if platform.kernelTarget == uImage then uinstall else + if platform.kernelTarget == zImage then zinstall else + install) ]; postInstall = (optionalString installsFirmware '' mkdir -p $out/lib/firmware -- 2.3.3 ___ 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] Per-user default binary caches
Hello everybody, is there a way to set a default binary cache for my regular user without making it a systemwide default, perhaps in `~/.nixpkgs/config.nix`? Basically I'd like to get rid of the --option argument when dealing with Haskell packages. Greets, Ertugrul signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Binary trust (was: Haskell NG: Still no binaries)
Hi Kirill, nix-env \ --option extra-binary-caches https://hydra.nixos.org \ --option extra-binary-caches https://hydra.cryp.to \ -iA nixos.pkgs.hsEnv Might it be the case that you are running nix in daemon mode and thus it ignores `binary-caches`? That did it! Since I'm running NixOS I am indeed running nix-daemon. The following setting did the trick: nix.binaryCaches = [ https://cache.nixos.org/; https://hydra.nixos.org/; ]; Thanks a lot! Unfortunately hydra.cryp.to does not seem to support TLS. That's why I left it out. But that raises an interesting question: Where do the hash values for the binary packages come from? At this point since we lack deterministic builds I would assume that they come from the same host that delivers the substitutes. A related question is: Are the hashes signed? If the hashes are not trusted, then a plain-text connection would be a huge security risk regardless of whether you trust the host. Even a malicious user or an infected machine on your local network could replace binary packages on their way and get arbitrary code onto your machine. Greets, Ertugrul signature.asc Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
