Re: [Nix-dev] how to debug the binary cache
Hi, - Channel is only updated after the unstable job builds successfully (depends on some jobs deemed essential). Maybe that's the only time when the binary cache is also updated. Thanks for the info! If I understand it correctly, the current status of hydra is the following: - i686-linux catched up fully, - x86_64-linux is very near to catch up (~30 packages left), - x86_64-darwin is catching up too, although a bit more slowly, - *-freebsd is not running at all, - there has been no update to the binary cache since 3-4 days now, none of the builds ever finish (because of freebsd). Would it be possible to force finish e.g. 994004 (nixpkgs githash of 45b8a1b) once *linux and *darwin is done? I'm sure that there are freebsd users out there, but they are not helped by hydra currently anyway. And it would be nice to get the new stuff for the most common platforms sometime soon. Usually, I wouldn't care about building some packages myself, but now a lot of things coincided: - x updates, - a lot of haskell updates that I'd like to use, - 1-2 weeks of other updates without hydra uploading to the binary cache. This results in building really a lot of stuff from source with a new nixpkgs checkout, which is slow and sometimes impossible on non-nixos linux because of some impurities... Gergely ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] wiki entry on how to add a large file into the nix store
hi everyone, i want to add more or less the following howto to the wiki. there is just one question remaining, which i'd like to sort out beforehand, namely what is the distinction between nix-store --add and nix-prefetch-url and the resulting store paths? would anyone care to enlighten me? thanks, jonas to introduce a file into the nix store, you normally either use nix-store --add largefile or nix-prefetch-url file://$(pwd)/largefile but both procedures have the problem that they try to load the whole file into memory, which may fail if you have a large one. properly adding the file on your own is a three step procedure: 1. find the right store path: nix-store --print-fixed-path --recursive sha256 $(nix-hash --type \ sha256 --base32 largefile) largefile to get the path which nix-store --add would be using nix-store --print-fixed-path sha256 $(nix-hash --type sha256 \ --flat --base32 largefile) largefile 2. copy/move the file to this path (you have to remount the nix-store read-write) 3. register the file: nix-store --register-validity --reregister RET store-path RET RET 0 RET C-d what is unclear to me at this point is the distinction between the path, that nix-store --add uses, and the one of nix-prefetch-url. in a requireFile directive you need the nix-prefetch-url one. the one from nix-hash --type sha256 --flat --base32, which needs to be fed into nix-store without --recursive. pgpnXedFT4MnB.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Dealing with dbus
not replyed to all by mistake
-- Forwarded message --
From: Sergey Mironov grr...@gmail.com
Date: 2013/9/13
Subject: Re: [Nix-dev] Dealing with dbus
To: Mathijs Kwik math...@bluescreen303.nl
Thanks for the clarifications. Yes, it is nixos who currently handles
systemd units and it surely can deal with dbus services so I would
probably have no problems packaging some dbus service. But there is a
thing bothering me - it is the inability to specify reverse
dependencies from nixpkgs to nixos.
Lets look at the situation from the client side: for example,
xfce4-power-manager wants to call upower in order to suspend the
system. Had it used the command line-tool like pm-suspend, we would
just write { .. pm-utils .. } in the xfce4-power-manager.nix as
usual. But we can't do similar thing for upower due to it's dbus
nature. Or, to be more precise, we can, but we can't restrict
power-manager from calling anything else so it would not actually help
us to maintain the package. Heh I even didn't know it needs upower
until I looked into sources.
Naturally, Nixpkgs handles link-level dependencies very well by
allowing only some specific libs to link with. Also, it handles
path-level deps by restricting PATH calls. Network-level deps is out
of it's scope and the question is - may we extend the usual logic to
this case and restrict DBus calls somehow? IMHO we need something to
error loudly when a program calls a dbus interface which is not
enabled for it in its *nix file.
Regards,
Sergey
2013/9/10 Mathijs Kwik math...@bluescreen303.nl:
Sergey Mironov ier...@gmail.com writes:
This kind of thing touches the boundaries between nixpkgs and nixos.
First of all, I think your usecase should be handled by systemd.
Systemd knows about dbus, knows which services exist and their dbus
names. It is capable of handling requirements/ordering of these.
But currently, a nixos module has to be written for every nixpkg that
provides a service, which means stuff ends up somewhat separated. If a
binary within a package moves from /bin to /sbin, any nixos module that
uses it needs to be fixed. Getting nixos and nixpkgs a little out of
sync will break things.
For other os-level functionality though, packages can provide things
like udev rules and kernel modules themselves. You tell nixos to use
these, but leave the implementation to the package.
I think something similar can/should be done for systemd units.
Some packages already include a unit file, but for others I think a
passthru attribute systemd-units would be nicer. Then you would only
need to tell nixos to use these, or do this automatically for
environment.systemPackages. Of course these would still be
overridable/tweakable if people need slightly different configs.
(that's why I think passthru is better than including a plain unitfile)
Similar things can probably be done for things like firewall rules.
If daemon-containing packages would carry info about which ports to
open, just saying something like
networking.firewall.daemons = [ pkgs.mysql ];
would be very nice.
Of course this is all a bit offtopic to your question, but you reminded
me about the somewhat unclear nixpkgs/nixos distinction by pointing out
you want to put os-level settings/deps inside a package description,
which I think is a natural thing to do.
For now: just use nixos' systemd.services attributes to tell systemd
about dbus names and dependencies of your services.
Mathijs
Hi. Let me suggest discussing the DBus and the guidelines for
packaging software which uses this technology. I suppose that plain
including dbus into the dependencies list of a package like that:
{ stdenv, fetchurl, pkgconfig, ... dbus ... }:
stdenv.mkDerivation rec {
name = udisks-1.0.4;
..
buildInputs = [ dbus ];
}
is not the best thing to do because we are offering little guaranties
to the user this way. We are actually saying that the package needs a
network, but in reality this package needs the network AND one or more
specific servers in order to work correctly. Could we do something
better? For example, could we treat DBus as just another way of
launching programs, develop the concept of DBUS_PATH and write
something like
{ stdenv, fetchurl, pkgconfig, ... dbus ... dbus_server1, dbus_derver2 }:
stdenv.mkDerivation rec {
name = udisks-1.0.4;
..
buildInputs = [ dbus ];
// Means that udisks should have it's DBUS_PATH containing at least
dbus_server1 and dbus_server2
dbusPath = [ dbus_server1 dbus_server2 ];
}
Does dbus provide an opportunity to organize thing like that?
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] wiki entry on how to add a large file into the nix store
to summarize i don't understand, why: # nix-store --add test.mp4 stores into /nix/store/z3wnqmfzqfmz5gis55bvymx3jbpgx7s5-test.mp4 which coincides with # nix-store --print-fixed-path --recursive sha256 \ $(nix-hash --type sha256 --base32 test.mp4) test.mp4 against # nix-prefetch-url file://$(pwd)/test.mp4 stores into /nix/store/1s52mklnbz1x3708wqyi9dz10xzfz63n-test.mp4 which coincides with # nix-store --print-fixed-path sha256 \ $(nix-hash --type sha256 --flat --base32 test.mp4) test.mp4 pgpeuk3ke3v8x.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] wiki entry on how to add a large file into the nix store
No, but it suggests this instead which probably yields the same store path?: nix-store --add-fixed sha256 jdk-6u45-linux-x64.bin I don't know what the exact difference is, I'm also too lazy to look it up. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wiki entry on how to add a large file into the nix store
On Fri, Sep 13 2013, Marc Weber wrote: No, but it suggests this instead which probably yields the same store path?: nix-store --add-fixed sha256 jdk-6u45-linux-x64.bin oh cool. yes, it does yield the same path as nix-prefetch-url. together with the observation, that nix-store --add also seems to add a whole directory, this suggests a totally different usage scenario for nix-store --add. I don't know what the exact difference is, I'm also too lazy to look it up. fair enough. thanks for bearing with me so far, jonas pgpAFO2w4GPzF.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] wiki entry on how to add a large file into the nix store
You're welcome. Keep asking and start/continue contributing. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Deploying Steam in NixOS
Hello Nixers seeking some entertainment! I also did an attempt to make Steam working in NixOS. I have used a chroot approach and for me it seems to work fine. I was capable of deploying and running Half-Life, Half Life 2, Portal and Counter Strike and they all seem to work fine on both on my desktop machine (with NVIDIA GPU) and notebook (with Intel GPU). More details: http://sandervanderburg.blogspot.com/2013/09/composing-fhs-compatible-chroot.html (Just search for tl;dr if you're too impatient :P) We may need to tweak the environment a bit to get other Steam games working that I don't know of, but the ones that I bought all seem to work. Best, Sander ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deploying Steam in NixOS
Very cool! Is this the approach you're suggesting we take with steam, and abandon hope of doing it outside chroot? On 13 Sep 2013 23:36, Sander van der Burg - EWI s.vanderb...@tudelft.nl wrote: Hello Nixers seeking some entertainment! I also did an attempt to make Steam working in NixOS. I have used a chroot approach and for me it seems to work fine. I was capable of deploying and running Half-Life, Half Life 2, Portal and Counter Strike and they all seem to work fine on both on my desktop machine (with NVIDIA GPU) and notebook (with Intel GPU). More details: http://sandervanderburg.blogspot.com/2013/09/composing-fhs-compatible-chroot.html (Just search for tl;dr if you're too impatient :P) We may need to tweak the environment a bit to get other Steam games working that I don't know of, but the ones that I bought all seem to work. Best, Sander ___ 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] Deploying Steam in NixOS
Excerpts from Oliver Charles's message of Sat Sep 14 01:29:44 +0200 2013: Very cool! Is this the approach you're suggesting we take with steam, and abandon hope of doing it outside chroot? What's wrong about a chroot? Everything else could be a lot more work to maintain. Additional use cases are andoird dev environment and a lot like that. While its possible to patch them all, its could be less effoort (thus smarter) to not try to do so .. IMHO. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deploying Steam in NixOS
On 09/14/2013 12:35 AM, Marc Weber wrote: Excerpts from Oliver Charles's message of Sat Sep 14 01:29:44 +0200 2013: Very cool! Is this the approach you're suggesting we take with steam, and abandon hope of doing it outside chroot? What's wrong about a chroot? Everything else could be a lot more work to maintain. Additional use cases are andoird dev environment and a lot like that. Nothing is wrong with a chroot, I was just wondering if this was an active area of exploration, or a more determined idea. - ocharles signature.asc Description: OpenPGP digital signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deploying Steam in NixOS
Hi Sander, This is really awesome. I had vague plans to eventually do the same things, but I'm glad you beat me to the punch. :) This will surely also make packaging other proprietary binary software much easier - for those cases where patchelf is not enough. One thing that seems like it would be worth adding would be with NixOS aid... a setuid wrapper that immediately after starting the chroot drops the privileges again. By the way, Aszlig also had a packaging effort for Steam. Cheers, Aristid 2013/9/14 Sander van der Burg - EWI s.vanderb...@tudelft.nl Hello Nixers seeking some entertainment! I also did an attempt to make Steam working in NixOS. I have used a chroot approach and for me it seems to work fine. I was capable of deploying and running Half-Life, Half Life 2, Portal and Counter Strike and they all seem to work fine on both on my desktop machine (with NVIDIA GPU) and notebook (with Intel GPU). More details: http://sandervanderburg.blogspot.com/2013/09/composing-fhs-compatible-chroot.html (Just search for tl;dr if you're too impatient :P) We may need to tweak the environment a bit to get other Steam games working that I don't know of, but the ones that I bought all seem to work. Best, Sander ___ 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] Hydra: NixOS tested job failing
Hi all, it seems that there are some networking issues with tested job on hydra, could someone take a look? http://hydra.nixos.org/build/6099164#tabs-constituents Domen ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
