Re: [Nix-dev] error: cannot auto-call a function that has an argument without a default value (‘stdenv’)
Am 07.07.2017 um 08:07 schrieb Vladimír Čunát via nix-dev:
> That's how it's commonly done in nixpkgs. If you want a *separate*
> expression that depends on nixpkgs, you may e.g. start by adding this
> line to the beginning of the file:
> with import {};
> instead of
> { stdenv, something1, something2, ... }:
Another solution (at least commonly used here at Flying Circus IO):
* leave the package expr as-is
* call it with the idiom
nix-build -E 'with import {}; callPackage ./hello.nix {}'
HTH
Christian
--
Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
[Nix-commits] [NixOS/nixpkgs] 09f24f: buildRustPackage: Fix "warning: file ... may be ge...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 09f24f628b64ada599616271ff4809eddb59eb0c https://github.com/NixOS/nixpkgs/commit/09f24f628b64ada599616271ff4809eddb59eb0c Author: Christian Kauhaus <k...@flyingcircus.io> Date: 2017-03-30 (Thu, 30 Mar 2017) Changed paths: M pkgs/build-support/rust/default.nix Log Message: --- buildRustPackage: Fix "warning: file ... may be generated" (#24471) Every Rust derivation used to emit a warning like the following: ``` setting SOURCE_DATE_EPOCH to timestamp 1490877042 of file cargo-6e0c18c/Cargo.lock warning: file cargo-6e0c18c/Cargo.lock may be generated; SOURCE_DATE_EPOCH may be non-deterministic ``` The reason is that the dependencies are copied without preserving timestamps. Changing the build script to timestamp-preserving copy removes the warning. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Problem compiling a rust program without fetchFromGitHub
Am 22.03.2017 um 11:43 schrieb Moritz Ulrich: > I agree. The versions etc. in Cargo.toml are equivalent. The only source > should be some impurities caused by stuff being added which isn't > fetched (or is sanitized after fetching) from Github, *especially* if it > works with the same `depsSha256`. I got it. The error message mentioned at the start of this thread get thrown when a fetchdeps derivation with a matching depsSha256 exists in the Nix store but does not satisfy the requirements from Cargo.lock. I think the fix is not too complicated: put a hash of Cargo.lock into the derivation name, so that Nix must instantiate always a new derivation if Cargo.lock's content has changed. The supplied fixed output hash in then only used for verification and not as content locator. Side question: does anyone know the reason for using the timestamp of Cargo.lock as SOURCE_DATE_EPOCH? Why not fix SOURCE_DATE_EPOCH to 1? Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Problem compiling a rust program without fetchFromGitHub
Am 21.03.2017 um 18:22 schrieb stewart mackenzie: > You need to update the rustIndex in nixpkgs. I don't think that this is part of the solution. When I compile *exactly* the same source obtained via fetchFromGitHub, all dependencies are found. The direction I've been thinking about is that fetchFromGitHub is actually a derivation with a bit of magic attached, while directly imported sources are just a Nix store path. Need to study buildRustPackage's code. Alas, the code in pkgs/build-support/rust/ is not really straight-forward. Help appreciated. :-) Regards Chistian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Problem compiling a rust program without fetchFromGitHub
Am 21.03.2017 um 16:47 schrieb stewart mackenzie: > $ nix-garbage-collect then retry This time I'm getting a new error: | Fetching /tmp/nix-build-my-rustfmt-fetch.drv-0/rustfmt to /nix/store/7v30ck1i3c1l2j2g461ld3jaq3hvfg01-my-rustfmt-fetch | Using rust registry from /nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58 | warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future | Updating registry `file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58` | Updating registry `file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58` | Updating registry `file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58` | Updating registry `file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58` | Updating registry `file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58` | Updating registry `file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58` | error: no matching package named `syntex_syntax` found (required by `rustfmt`) | location searched: registry file:///nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58 | version required: = 0.58.1 | versions found: 0.58.0, 0.57.0, 0.56.2, ... | builder for ‘/nix/store/s23lbgjqvk36c0vgjxxxmg6d22n0jak8-my-rustfmt-fetch.drv’ failed with exit code 101 | cannot build derivation ‘/nix/store/krzc387z5kcwzkyhn3g9vq557272y6na-my-rustfmt.drv’: 1 dependencies couldn't be built Looks to me that the index is out of sync which the crates snapshot. I've inspected the buildRustPackage code but did not find the place where such a problem could originate from. syntex_syntax 0.58.1 has been added to crates.io on 2017-02-19. Needless to say that the nix expression using fetchFromGitHub still works and is yielding exactly the same output as last time, regardless of nix-collect-garbage or whatnot. BR Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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
[Nix-dev] Problem compiling a rust program without fetchFromGitHub
Hello fellow Nixers,
I recently failed to compile a Rust program (rustfmt) from a local checkout.
Compiling with identical sources obtained via fetchFromGitHub succeeded.
Compiling from a identical local checkout didn't. Very strange. Can anyone help
me to figure out what is going wrong?
This is what happened:
* I use pkgs.rustPlatform.buildRustPackage from the latest 17.03beta542.
* This code works:
```
pkgs.rustPlatform.buildRustPackage rec {
name = "my-rustfmt";
src = pkgs.fetchFromGitHub {
owner = "rust-lang-nursery";
repo = "rustfmt";
rev = "907134c2d10c0f11608dc4820b023f8040ad655a";
sha256 = "1sn590x6x93wjzkb78akqjim734hxynck3gmp8fx7gcrk5cch9mc";
};
depsSha256 = "1djpzgchl93radi52m89sjk2nbl9f4y15pwn4x78lqas0jlc6nlr";
}
```
* When I clone the repo into the local filesystem, the build fails. New code:
```
pkgs.rustPlatform.buildRustPackage rec {
name = "my-rustfmt";
src = ./rustfmt;
depsSha256 = "1djpzgchl93radi52m89sjk2nbl9f4y15pwn4x78lqas0jlc6nlr";
}
```
I tried it with and without a .git directory present. No difference.
The relevant output lines of the failing case are:
| Using cargo deps from
/nix/store/7v30ck1i3c1l2j2g461ld3jaq3hvfg01-my-rustfmt-fetch
| Using indexHash '-ba82b75dd6681d6f'
| Using rust registry from
/nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58
| warning: custom registry support via the `registry.index` configuration is
being removed, this functionality will not work in the future
| error: failed to load source for a dependency on `syntex_syntax`
|
| Caused by:
| Unable to update registry file:///dev/null
|
| Caused by:
| failed to open:
/tmp/nix-build-my-rustfmt.drv-0/deps/registry/index/-ba82b75dd6681d6f/.cargo-index-lock
The full logs are attached.
I believe that both attempts should result in identical builds. Did I do
something wrong? Is this a bug?
TIA
Christian
--
Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
these derivations will be built:
/nix/store/krzc387z5kcwzkyhn3g9vq557272y6na-my-rustfmt.drv
building path(s) â/nix/store/mm9lx2k2rs3qvq5ymb5kvirrmf4y3l4b-my-rustfmtâ
unpacking sources
unpacking source archive /nix/store/nyw5scvvgf688cgk4rihjaxabr7hzdxm-rustfmt
source root is rustfmt
Using cargo deps from /nix/store/7v30ck1i3c1l2j2g461ld3jaq3hvfg01-my-rustfmt-fetch
Using indexHash '-ba82b75dd6681d6f'
Using rust registry from /nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58
warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future
error: failed to load source for a dependency on `syntex_syntax`
Caused by:
Unable to update registry file:///dev/null
Caused by:
failed to open: /tmp/nix-build-my-rustfmt.drv-0/deps/registry/index/-ba82b75dd6681d6f/.cargo-index-lock
To learn more, run the command again with --verbose.
builder for â/nix/store/krzc387z5kcwzkyhn3g9vq557272y6na-my-rustfmt.drvâ failed with exit code 101
error: build of â/nix/store/krzc387z5kcwzkyhn3g9vq557272y6na-my-rustfmt.drvâ failed
these derivations will be built:
/nix/store/wfr6d0xivj66zd8d9arvm7wc58a4fc27-my-rustfmt.drv
building path(s) â/nix/store/cg6mdr5gz7bh7d3jg83cqab893212awm-my-rustfmtâ
unpacking sources
unpacking source archive /nix/store/j0xnxxzkbahpnmvf77i3xk0nhyzynpf0-rustfmt-907134c2d10c0f11608dc4820b023f8040ad655a-src
source root is rustfmt-907134c2d10c0f11608dc4820b023f8040ad655a-src
Using cargo deps from /nix/store/7v30ck1i3c1l2j2g461ld3jaq3hvfg01-my-rustfmt-fetch
Using indexHash '-ba82b75dd6681d6f'
Using rust registry from /nix/store/gv06zlhm4rnhi7j9s1sjj4njns3ca788-rustRegistry-2017-02-19-d822c58
warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future
warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future
setting SOURCE_DATE_EPOCH to timestamp 1490109616 of file rustfmt-907134c2d10c0f11608dc4820b023f8040ad655a-src/Cargo.lock
warning: file rustfmt-907134c2d10c0f11608dc4820b023f8040ad655a-src/Cargo.lock may be generated; SOURCE_DATE_EPOCH may be non-deterministic
patching sources
configuring
building
Running cargo build --release
warning: custom registry support via the `registry.index` configuration is being removed, this functionality will not work in the future
Compiling bitflags v0.7.0 (registry file:///dev/null)
Compiling regex-syntax v0.3.9 (registry file:///dev/null)
Compiling winapi v0.2.8 (registry file:///dev/null)
Compiling log v0.3.6 (registry file:///dev/null)
Compiling utf8-ranges
Re: [Nix-dev] how to find packages by file?
On 14.03.2017 21:24, Roni Choudhury wrote: > And perhaps a related final question: *how do I know where a given directory > in /nix/store "came from" - that is, how can I link something in the store to > something in nixpkgs?* I have no immediate answer for the first two questions, but to the third one: use nix-store --query --deriver /nix/store/path/to/file . This will print the source derivation. The derivation file contains information where it was built from, but in most cases it is sufficient to simply look at the file name. HTH Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Nix-store --repair doesn't seem to be repairing
Am 14.03.2017 um 00:18 schrieb Oliver Charles: > Hmm, how did you reach that conclusion? Re-downloading from a trusted source (cache.nixos.org) gives the same "incorrect" checksum again. Of course it could be possible that the file is corrupted on cache.nixos.org, but following the "select isn't broken" rule[1] I would start to search elsewhere. This is just a suspicion not a hard proof. Perhaps you get the checksum errors due to something completely different. BR Christian [1] https://pragprog.com/the-pragmatic-programmer/extracts/tips -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Nix-store --repair doesn't seem to be repairing
Am 12.03.2017 um 20:07 schrieb Oliver Charles: > Any idea what's going on here? Looks like the corruption is rather in the sqlite than in the tree. No idea how to fix this, though. Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Hydra: infinite CPU and RAM consumption in evaluator
Am 19.01.2017 um 11:12 schrieb Christian Theune: > Nevertheless, it looks like we may have introduced poisonous code that sends > the evaluator off into infinity. We’ll come back when we find out what it was. I got it and I would like to share my findings. We introduced a change that imported an item "nginxModules" into all-packages: https://github.com/flyingcircusio/nixpkgs/blob/2926129b8940e880a7745e44df511a3d6adacfa9/nixos/modules/flyingcircus/packages/all-packages.nix#L59 The problem was that (1) this import returnes an attrset or attrsets (none containing a derivation) and that our all-packages gets imported entirely into our Hydra master job so that all of our custom packages are guaranteed to be built: https://github.com/flyingcircusio/nixpkgs/blob/fc-15.09-dev/nixos/release-flyingcircus.nix#L121 This construct seems to send Hydra's evaluator into nowhere land. After removing the "nginxModules" attribute, everything seems to be fine again: https://github.com/flyingcircusio/nixpkgs/blob/fc-15.09-dev/nixos/modules/flyingcircus/packages/all-packages.nix#L54 I don't understand the exact reason. My expectation would be that Hydra's evaluator ignores attrsets defining no derivations (analogous to a Nix expression like `collect isDerivation nixpkgs`. Obviously, it doesn't exactly do so. But hey, now it's running again. :-) Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Why nginx config isn't placed into /etc/nginx/nginx.conf?
Am 12.08.2016 um 10:09 schrieb Roger Qiu: > Fascinating. Have you heard of CFEngine's "Convergent Fixedpoint" idea? > https://en.wikipedia.org/wiki/CFEngine#Convergence Sure. Many mainstream system management tools like Cfengine, Puppet, Ansible, ... are built around this concept of convergence. This is exactly what I mean with "convergent" in my blog post. BR Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Why nginx config isn't placed into /etc/nginx/nginx.conf?
Am 10.08.2016 um 00:29 schrieb Arnold Krille: > On Tue, 9 Aug 2016 19:54:10 +0100 Luca Bruno <lethalma...@gmail.com> > wrote: >> Except that the existing world and software is not reproducible and >> revertable. > [...] > Thanks to Nixos I can set my server back to the system configuration > from four months back. Apart from the user data of course. Systems management always decomposes into congruent, convergent and divergent realms. The aim of Nix (as I understand it) is to grow the congruent realm. Of course, the other realms won't go away. For those interested, I've written a blog post some months ago which explains these realms and how they relate to NixOS: https://blog.flyingcircus.io/2016/05/06/thoughts-on-systems-management-methods/ HTH Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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
[Nix-commits] [NixOS/nixpkgs] ea7e70: varnish: fix localstatedir for varnish* tools (#17...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: ea7e705cd905e01bc65f2a7ccc6e700bd1bcd4e0 https://github.com/NixOS/nixpkgs/commit/ea7e705cd905e01bc65f2a7ccc6e700bd1bcd4e0 Author: Christian Kauhaus <k...@flyingcircus.io> Date: 2016-08-04 (Thu, 04 Aug 2016) Changed paths: M nixos/modules/services/web-servers/varnish/default.nix M pkgs/servers/varnish/default.nix Log Message: --- varnish: fix localstatedir for varnish* tools (#17508) The varnish tools (varnishstat, varnishlog, ...) tried to load the VSM file from a spurious var directory in the Nix store. Fix the default so the tools "just work" when also keeping services.varnish.stateDir at the default. Notes: - The tools use $localstatedir/$HOSTNAME so I've adapted the default for stateDir as well to contain hostName. - Added postStop action to remove the localstatedir. There is no point in keeping it around when varnish does not run, as it regenerates it on startup anyway. Fixes #7495 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
[Nix-commits] [NixOS/nixpkgs] 3530f3: systemd: make ctrl-alt-del target configurable. (#...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 3530f3f20a934ed1d3df35fe3c8041d197f8b41e https://github.com/NixOS/nixpkgs/commit/3530f3f20a934ed1d3df35fe3c8041d197f8b41e Author: Christian Kauhaus <k...@flyingcircus.io> Date: 2016-07-19 (Tue, 19 Jul 2016) Changed paths: M nixos/modules/system/boot/systemd-lib.nix M nixos/modules/system/boot/systemd.nix Log Message: --- systemd: make ctrl-alt-del target configurable. (#16911) We currently only allow upstream's default of "reboot.target" due to the way the symlinks are initialized. I made this configurable similar to the default unit. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Packaging free software that costs money
Am 07.07.2016 um 01:18 schrieb Renato Alves:
> I don't think this issue concerns nix.
I'd go into the same direction. A party is free to distribute libre software
for money or not, but must grant other parties the same rights. Formally, we
(NixOS) may get the source and redistribute it with our own procedures (as long
as we don't stop anyone else).
This is what most other Linux distros do: for example, Ubuntu packages and
distributes Ardour just the normal way as .deb and nobody has a right to stop
them.
That being said, we could do author of such software a favour and add a
meta-attribute which gives a hint to the user that the authors would like to
receive a monetary contribution.
E.g.,
meta = {
support_url = "https://project.local/subscribe;;
};
This meta attribute would result in a hint displayed at the end of nix-build or
nix-env. I'd oppose against any stronger measures that would bring further
complications.
My 2ct
Christian
--
Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick
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] Question about chroot & nixos-install
Am 07.04.2016 um 11:38 schrieb Peter Simons: > https://nixos.org/wiki/How_to_install_NixOS_from_Linux describes how to > do that using a Live-CD ISO. Thanks for the pointer. Didn't consider the wiki since it was down for a while. Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Question about chroot & nixos-install
Am 01.04.2016 um 14:32 schrieb Denis Paukaev: > I would like to use 'nixos-install' to generate a chroot from another > linux (such as Ubuntu), but also using a nixpkgs checkout of my choice. I'd like to second that. I stumbled over the same issue a while ago and I did not find any documented solution. I think installing NixOS into a mountpoint from another OS (where just nixpkgs available) is a common situation. Anyone to present a workable procedure? Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] When will nixos-16.03 be ready?
Am 31.03.2016 um 14:41 schrieb Domen Kožar: > I'll announce the release today evening CET. w00t Still in time. :-) Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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
[Nix-dev] When will nixos-16.03 be ready?
Hi, I wonder what the timeline is for the 16.03 release. As far as I understand it, it was supposed to happen in March, but odds are not so good right now. Has anyone an idea about what it takes for the release to happen? TIA Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] Redesign of documentation
Am 15.02.2016 um 18:57 schrieb Freddy Rietdijk: > So, that's my idea about the documentation. What are your views about this > issue and the proposal? And remember, no talking about implementations/formats > just yet! In my opinion it would be helpful to cover the Nix language (language syntax, features and builtins) in a separate section. Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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] User and group ID ranges
Am 14.01.2016 um 10:55 schrieb Игорь Пашев: > I use this function to get IDs: Thank you for the code, but this is not the problem I'm trying to solve. We allocate UIDs centrally. It's more a policy question: Is the range 500 <= n < 1000 likely to be free in the future? What about using the range 3 < n < 65535? We allocate UIDs now and want to avoid future UID conflicts. Changing UIDs on large-scale infrastructures is painful. Regards Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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
[Nix-dev] User and group ID ranges
Hi, we are currently in the process of configuring users and groups with fixed UID/GID numbers from a central directory on a bunch of NixOS machines. I'd like to clarify some policy issues to avoid future ID conflicts. The current policy, as far as I understand it, is: * Fixed UIDs/GIDs are in the range 0 <= n < 400 (nixos/modules/misc/ids.nix). * Dynamic IDs for system users are allocated from the range 400 <= n < 500 (nixos/modules/config/update-users-groups.pl). * The range 500 <= n < 1000 seems currently to be reserved. * "Normal" (human) users go into the range 1000 <= n < 3 (nixos/modules/config/users-groups.nix). * The range 3 <= n < 65535 seems to be used for dynamically allocated groups for nixbuild (?) Is this correct? Are there any plans on using the range 500 <= n < 1000? When I look at the list of statically allocated UIDs below 400, I wonder if it is not like to see an overflow. I'm currently unsure what the policy is for 3 <= n < 65535. Is it ok for sites to allocate additional IDs without fear for conflict? TIA Christian -- Dipl-Inf. Christian Kauhaus <>< · k...@flyingcircus.io · +49 345 219401-0 Flying Circus Internet Operations GmbH · http://flyingcircus.io Forsterstraße 29 · 06112 Halle (Saale) · Deutschland HR Stendal 21169 · Geschäftsführer: Christian Theune, Christian Zagrodnick 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
