Re: [Nix-dev] [ANN] Home Manager
Nice work! On Sun, Jul 2, 2017 at 11:58 PM, Robert Helgesson <rob...@rycee.net> wrote: > In short Home Manager is a set of NixOS modules and a command line tool > called `home-manager` that lets you configure your user's environment > similar to how you configure your NixOS system. For your information, the module system was made such that you can re-use it as a submodule. So technically, you might be able to create a NixOS module for NixOS which imports the home-manager within NixOS users ;) This home-manager submodule would have to forward pkgs as a module argument (as done in NixOS), and import the modules from the home-manager. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hydra and security updates
On Sun, Jun 4, 2017 at 1:17 AM, Bjørn Forsman <bjorn.fors...@gmail.com> wrote: > On 4 June 2017 at 00:35, Nicolas Pierron <nicolas.b.pier...@nbp.name> wrote: >> So I started SOS [1] to make Nixpkgs more >> declarative. Thus removing some of the function overhead from >> packages, which would help fixing a lot of the issues reported by the >> static-analysis. > > I think you forgot to add the link to the SOS thing. (I'm interested.) > > Best regards, > Bjørn Forsman [1] https://github.com/NixOS/rfcs/pull/3 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hydra and security updates
On Sat, Jun 3, 2017 at 1:26 PM, Graham Christensen <gra...@grahamc.com> wrote: > This is part of my inclination of not really loving PR#10851, it is > complicated and goes around the normal proceses, even when we can easily > deploy fairly quickly. The problem that I have with the current solutions is that they involve _user_ actions (*), they do not address all uses cases, and potentially a lot of local recompilation time. PR#10851 goals are to address all of these issues. >From the _maintainer_ point-of-view, this would be as simple as a cherry-pick (*). >From the user point of view, this would be like any ordinary channel. >From hydra point of view, this would be only rebuilding packages which have patches, or which are statically linked. (*) goes around the normal processes. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hydra and security updates
On Sat, Jun 3, 2017 at 12:54 AM, Leo Gaspard <l...@gaspard.io> wrote: > On 06/02/2017 12:05 PM, Domen Kožar wrote: >>> I see two ways of doing this: either having hydra somehow handle with >>> special care security updates (hard to do) >> >> https://github.com/NixOS/nixpkgs/pull/10851 > > This looks great! > > Unfortunately, it doesn't appear to be close to merging (esp. as it has > merge conflicts), so I guess that's the best solution that isn't coming > up right now? So having master and stable always build may be a current > path forward, not yet as good as this PR but a good stop-gap. I started a branch at the end of last year, which include these changes and rebased them on top of the latest master, but I gave up as I did not got any feedback for getting any Hydra infrastructure in place to make use of this feature in a testing branch. Having Hydra infra in place would be among the next step to demonstrate the usefulness of this approach, and convince more people to help fix the static-analysis reports. So currently, this project is held by a dead-lock between people asking me to demonstrate a large scale example, and having the infrastructure to doing so. Most of the time, unpatched dependencies from PR#10851 are coming from the fact that dependencies are resolved by functions them-self taken for older generations of the fix-point, breaking the hypothesis on which PR#10851 is based on. So I started SOS [1] to make Nixpkgs more declarative. Thus removing some of the function overhead from packages, which would help fixing a lot of the issues reported by the static-analysis. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Replace default gcc through overlays?
Hi,
You can indeed replace gcc by a newer version of it, but the overlay
system does not allow you to do so inside the early stages of the
bootstrapping. If you have to replace the early stages of the
bootstrapping, then I suggest you look at `pkgs/stdenv/default.nix`
and `pkgs/stdenv/linux/default.nix` and give it as argument of
`pkgs/top-level/default.nix` which is currently loading this file to
bootstrap the standard environment.
Otherwise, an overlay should help you with what you are looking for by
replacing the `stdenv` attribute as well as all the packages used for
bootstrapping. You have to replace these packages as well because you
would otherwise have an inifnite loop as you try to add the new
compiler to the stdenv, which would be needed for compiling the
compiler it-self, due to `callPackage` taking stdenv from `self.`
```nix
self: super:
let
...
stdenv = super.stdenvAdapters.overrideCC super.stdenv ...; # see [1]
in
{ inherit stdenv; } // stdenv.overrides self super
```
I did something similar a while ago, to use an old version of gcc, in
order to reproduce a bug which was on a different CI. You can find
the detail here[1].
Note that, you might have to override the stdenv argument (and maybe
others) used for building the compiler:
```nix
cc.override { stdenv = super.stdenv }
```
In addition to changing the source of the derivation, otherwise you
might have an infinite loop, as the compiler is by default compiled
with the `callPackage` function which takes its inputs from the result
of the fix-point, which is not what you want here for bootstrapping
this new stdenv for every packages.
About making it a cross compiler, I do not know enough, but I can only
give you some pointers to `makeStdenvCross` stdenv adapter
function[2].
I have not tested this for replacing the stdenv globally, but I think
this will bring you closer to the final solution.
Good luck.
[1] https://github.com/mozilla/nixpkgs-mozilla/blob/master/release.nix#L96
[2] https://github.com/NixOS/nixpkgs/blob/master/pkgs/stdenv/adapters.nix#L59
On Wed, May 24, 2017 at 12:15 AM, Mateusz Czaplinski
<czapko...@gmail.com> wrote:
> I'm writing a local (non-nixpkgs) derivation, and I'd like to replace the
> default "gcc" to be a patched gcc6 - also for all implicit dependencies in
> nixpkgs. Is it possible to do that (I assume via overlays and resulting
> fixpoint)? If yes, how should I write this to work?
>
> For background: I want to cross-compile the Linux kernel (actually, a fork -
> L4Linux) to a new target platform. But setting `crossSystem` seems to
> trigger rebuilding of gcc, which crashes on me because of OOM killer on
> genattrtab. This I believe could be mitigated by a Nov'2016 patch to gcc
> (https://patchwork.ozlabs.org/patch/695293/), so I believe I need to have it
> incorporated into default gcc. This I hope would let me overcome the "out of
> memory" obstacle, so that I could go back to hacking on my main task...
>
> When fixing this, I would much prefer not to have to fork whole nixpkgs, if
> feasible. I suppose maintaining a nixpkgs fork is harder, and also sharing
> sounds not so simple then as in the basic case of a single .nix file?
>
> I'd be grateful for any help.
> Thanks,
> /Mateusz.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Rust prebuilt package overlay.
On Sun, Apr 16, 2017 at 2:57 PM, William Casarin <j...@jb55.com> wrote: > Nicolas Pierron <nicolas.b.pier...@nbp.name> writes: > >> On Fri, Apr 14, 2017 at 4:40 PM, William Casarin <j...@jb55.com> wrote: >>> >>> $ nix-shell -p rustChannels.stable.rust >>> >>> [...] >>> while evaluating ‘tokenizer_rec’ at >>> /Users/jb55/etc/nixpkgs-mozilla/lib/parseTOML.nix:6:46, called from >>> /Users/jb55/etc/nixpkgs-mozilla/lib/parseTOML.nix:41:20: >>> compiling pattern ‘([ >>> ]+(=|[[][[][a-zA-Z0-9_."*-]+[]][]]|[[][a-zA-Z0-9_."*-]+[]]|[a-zA-Z0-9_-]+|"[^"]*")[ >>> [... same line repeated 4094 times ...] >>> ]+(=|[[][[][a-zA-Z0-9_."*-]+[]][]]|[[][a-zA-Z0-9_."*-]+[]]|[a-zA-Z0-9_-]+|"[^"]*")).*’: >>> out of memory >>> >>> Looks like some kind of infinite recursion bug? >>> Seems to work fine on my nixos box though 樂 >> >> There is a constant[1] that you can modify in the overlay, by >> increasing it, it would make a smaller pattern and consume less >> memory, but it would make take more time to parse the content of the >> file. > > This worked. Increasing it to 180 fixed it. Thanks for testing, feel free to submit a patch ;) > I was watching activity > monitor and noticed spikes of 14GB memory usage (12GB compressed) so > about ~2-3GB real. It looks like generatePatterns is creating 14GB+ > of strings!? No, it generates a string which is a few ~100KB, but apparently the C++ std::regex_match implementation probably do so when compiling the string into an automaton. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Questions about the all-packages fixpoint
On Sat, Mar 18, 2017 at 7:40 PM, Benno Fünfstück
<benno.fuenfstu...@gmail.com> wrote:
> Ok, thanks again!
>
>> - 0 hop: means that you are linking statically. Any change of such
> dependency would cause your package to be rebuilt.
>
> Does this mean that when I link statically, I cannot go through self? so the
> following would be wrong:
>
> foo = import foo.nix { bar = self.bar; }
>
> if `foo` links statically against `bar`?
Yes, this used to be the case, the problem is that we cannot override
statically linked libraries, so at the end I think I would split the
self-fixpoint into one fix-point for statically linking, and a second
fix-point of dynamically-linking.
Thus at the end, I expect to create an interface such as:
{dynamicLink, staticLink}: super:
But then we would have to revise the way callPackage works in order to
distinguish statically linked dependencies versus dynamically linked
dependencies.
This would become a non-problem as soon as I manage time to answer and
push S.O.S. [1] forward, in order to get rid of callPackage.
[1] https://github.com/zimbatm/rfcs/pull/3
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Questions about the all-packages fixpoint
On Sat, Mar 18, 2017 at 3:27 PM, Benno Fünfstück <benno.fuenfstu...@gmail.com> wrote: > Nicolas Pierron <nicolas.b.pier...@nbp.name> schrieb am Fr., 17. März 2017 > um 22:36 Uhr: >> >> On Fri, Mar 17, 2017 at 9:38 PM, Benno Fünfstück >> <benno.fuenfstu...@gmail.com> wrote: >> > One thing that is nicer about `self.callPackage` though is that you can >> > follow the rule "whenever taking something from self does not lead >> > infinite >> > recursion, take it from self" when writing overrides. >> >> And we should not advertise that, because this would lead to packages >> which are not patched, under the rules of the future security-update >> work. >> So whatever you think this is simpler or not, this is incorrect, I >> guess we could nullify these functions in the latest layer, preventing >> callPackage to ever be used through `self`. > > > Oh, why would that lead to not applying security updates? I'm not very > familar with "future security-update work", but that sounds unexpected to > me. What's so deeply magical about security updates? The security-update branch needs to peel off the fix-point of Nixpkgs. Then the patching behaviour is added in-between every package by doing one more step of the Nixpkgs function. This has the consequences of giving the following semantic to the numbers of hops that you use to fetch the dependencies: - 0 hop: means that you are linking statically. Any change of such dependency would cause your package to be rebuilt. - 1 hop: means that you are linking dynamically. Any change of such dependency would cause your package to be patched. - >1 hops: means nothing. Any change of such dependency would leave your package to be unchanged. Going through `self` is adding hops. If you were to call `self.callPackage` instead of `super.callPackage`, you would have 2 hops instead of 1 hop, because callPackage generate attribute set out of `self`. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Questions about the all-packages fixpoint
On Fri, Mar 17, 2017 at 9:38 PM, Benno Fünfstück <benno.fuenfstu...@gmail.com> wrote: > One thing that is nicer about `self.callPackage` though is that you can > follow the rule "whenever taking something from self does not lead infinite > recursion, take it from self" when writing overrides. And we should not advertise that, because this would lead to packages which are not patched, under the rules of the future security-update work. So whatever you think this is simpler or not, this is incorrect, I guess we could nullify these functions in the latest layer, preventing callPackage to ever be used through `self`. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Questions about the all-packages fixpoint
Hi Benno,
Before answering, let me give you a brief intro to the fix-extend
function combo.
The extend function is similar to the update operator of Nix `//`, the
main difference is that it give its left-hand side (`super`) as
argument to its right hand side.
But this extend function give an extra argument (`self`) to all its
arguments. When chaining these extend function, the `self` argument is
the same for the all layers.
When a fix point is applied to this chain of extend function, `self`
corresponds to the last set produced by the extend function chain.
Note that using `self` can easily cause infinite recursion, for
example if the addition of an attribute to the set depends on the
presence of an attribute in `self`.
On Fri, Mar 17, 2017 at 5:04 PM, Benno Fünfstück
<benno.fuenfstu...@gmail.com> wrote:
> 2. In `stage.nix`, why do we construct a *local* fixpoint just for
> all-packages? The current code is:
>
> allPackages = self: super:
> let res = import ./all-packages.nix
> { inherit lib nixpkgsFun noSysDirs config; }
> res self;
> in res;
>
> Even more confusingly, if we look at `all-packages.nix`, it is a function
> defined like this:
>
> { lib, nixpkgsFun, noSysDirs, config}:
> self: pkgs:
>
> So the variable that is called `self` in `stage.nix` is bound to what is
> called `pkgs` in `all-packages.nix`, and `self` in `all-packages.nix`
> actually refers to what is called `res` in `stage.nix`
This is because this code is still legacy before the introduction of
the extend function.
We should not use this `self` argument under all-packages.nix, but
last time I tried to avoid changing any hashes.
Another reason why I did not address this, such as renaming it because
`self` is quite an overloaded name, and a naive search and replace
would not work as expected.
Note, there is also a package named `self`, for interpreting the Self language.
So `pkgs` of all-packages.nix is literaly the result of the fix-point,
given to all overlays under the name `self`.
> 1. An override is given the arguments `self` and `super`, as expected. But
> why does `super.callPackage` resolve dependencies from `self`?
`callPackage` take a function as argument, or a path to a function,
and list the arguments of it. It then create a set with the requested
argument and a set given as argument.
In `top-level/splice.nix`, the callPackage function is given an
argument which is constructed from the result of the fix-point.
Thus `super.callPackage` will fill the arguments of the functions with
the value taken within the result of the fix-point.
> I would have
> expected it to not know about `self`, and resolve dependencies in the scope
> of `super`. If I wanted this behaviour, I would have used
> `self.callPackage`, but the current behaviour makes that unnecessary. Why is
> this implemented like that?
The history of all-packages.nix used to be that we had a "rec" keyword
on top of the attribute set.
Then we added the `self` reference that you complained about in (2) in
order to be able to override packages.
If `super.callPackage` were taking all its arguments from `super`,
then this would imply that you could not easily override the argument
of packages which are inside the dependencies of another one.
By taking the packages from `self`, we can easily replace it for all its uses.
> This is confusing to me. Also, why do we need `self` and `pkgs`? Wouldn't
> one of them be enough?
Yes, but again, renaming these variables is hard without the proper
tooling to guarantee that we are not making any mistake.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Function to look up symbols dynamically?
Hi Bryan, On Wed, Mar 15, 2017 at 5:21 PM, Bryan Ferris <primummo...@gmail.com> wrote: > I believe that for complicated configurations this would lead to a tidier > config. I honestly don't think this would help you keep your configuration isolated by concerns as the module system of NixOS does. > My goal is to be able to add one line to configuration.nix which > will import everything from the directory, meaning that you can put as much > or as little as you want into the main configuration file and you can move > code around easily in order to find the system of organization that fits > your specific use-case the best. Modules have an `imports` top-level attribute which can be used to list other files that have to be included in the configuration. > This seems like a reasonable approach to a > useful tool, no? If you really want to continue that way, I suggest you to look at the builtin function `builtins.readDir`. Otherwise, if what you are looking for a better way to lookup options, maybe you should look at `nixos-option` tool, which should help you better understand where options are defined both within NixOS, and within your own modules: $ nixos-option environment.systemPackages Declared by: "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/config/system-path.nix" Defined by: "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/x11/desktop-managers/kde4.nix" "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/services/x11/desktop-managers/xterm.nix" "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/virtualisation/virtualbox-guest.nix" "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/virtualisation/containers.nix" "/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/tasks/swraid.nix" ... If you are looking for reading more about it, I will recommend the 2 following chapters of the NixOS manual: http://nixos.org/nixos/manual/index.html#sec-configuration-syntax http://nixos.org/nixos/manual/index.html#sec-writing-modules -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] System overlays?
On Tue, Mar 14, 2017 at 4:23 AM, Judson Lester <nya...@gmail.com> wrote: > I was just looking, and I can't see how (or if?) overlays are supported at > the system (i.e. configuration.nix) level. Is that documented somewhere? It is supposed to show up on nixos.org, but for reasons that I don't know, it does not seems that the list of options got updated to 17.03 yet, and hydra only report 404 pages for the release. Otherwise you can look at the documentation from the sources of it: https://github.com/NixOS/nixpkgs/blob/release-17.03/nixos/modules/misc/nixpkgs.nix#L63 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-shell with overlay?
On Wed, Mar 8, 2017 at 11:01 AM, Benno Fünfstück <benno.fuenfstu...@gmail.com> wrote: > Nicolas Pierron <nicolas.b.pier...@nbp.name> schrieb am Mi., 8. März 2017, > 01:30: >> >> nit: super.callPackage, as the super.callPackage *function* already >> aliases self packages. Otherwise, you would be going twice through >> the fix-point. > > What if someone later wants to override callPackage? Later, this person would have to face the fact that security updates are not applied. The documentation is clear that if this is a function or a recipe, then it should be coming from `super`, if this is a dependency it should come from `self`. `callPackage` is a function, which captures `self` to provide default dependencies, so it should be taken out of `super`. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Rust prebuilt package overlay.
On Tue, Mar 7, 2017 at 1:41 PM, Profpatsch <m...@profpatsch.de> wrote: > On 17-03-04 08:34pm, Nicolas Pierron wrote: >> The *.toml manifest file is then parsed (yes, in Nix [3]) to extract >> [3] https://github.com/mozilla/nixpkgs-mozilla/blob/master/lib/parseTOML.nix > > what have you done I made tool to avoid updating this repository every time there is a new nightly version of rustc. This Nix expression is able to parse a 200 kB toml file in less than 1 second. To make it short: - The tokenizer abuse ` builtin.match ` ability to generate a list of strings out of the captured regex, and avoid deep recursions by approximating down the number of expected tokens. - The parser uses ` builtin.foldl' `, to make some kind of for-loop which does not consume space and mutate the parser state to reconstruct the corresponding attribtue set of the *.toml file If you want more detail, maybe I should present it at the next NixCon. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-shell with overlay?
On Tue, Mar 7, 2017 at 5:14 PM, Matthias Beyer <m...@beyermatthias.de> wrote:
> On 07-03-2017 16:33:15, Profpatsch wrote:
>> On 17-03-07 03:57pm, Matthias Beyer wrote:
>> > Hi,
>> >
>> > is there a way to import an overlay in a default.nix for a nix-shell
>> > and use the packages from the overlay in the nix-shell only, without
>> > installing the overlay "globally" for my user?
>> >
>> > If yes, how?
>>
>> Not sure what you mean, how about just adding the overlay to the default.nix?
>>
>> import {
>> overlays: [(self: super: {
>> myDep = super.myDep.override {
>> …
>> };
>> myPkg = self.callPackage ./. {};
nit: super.callPackage, as the super.callPackage *function* already
aliases self packages. Otherwise, you would be going twice through
the fix-point.
>> })];
>> }
>
> Ah, nice! But I also have to fetch the overlay in the expression...
> (I'm trying to get the rust-overlay from mozilla to work)
you can import it in the list of overlays.
overlays = [ (import ~/nixpkgs-mozilla/rust-overlay.nix) ]
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Rust prebuilt package overlay.
Hi list, # Motivation I saw an issue on github the other day about Rust packaging #23291. I have faced the problem that Rust nightly version was not enough for building rustc out of the repository. Rust nightly is probably changing too frequently to be maintained within Nixpkgs #8697. Also, Firefox developer, I will need to follow Rust versions as soon as they are packaged and updated in Firefox. The recommended way for developing Firefox is to periodically run rustup (every ~6 weeks), which is sad from my point of view. As I rely on nixpkgs-mozilla [1] repository to generate the build environment I use, I decided to tackle the issue inherent of having recent version of rustc & cargo. # What I created an overlay which mimic rustup behaviour, and allow you to spawn a nix-shell with the latest nightly, beta, or stable version of rustc & cargo. To use this overlay, checkout nixpkgs-mozilla [1], and create a symbolic link to the file rust-overlay.nix [2] in the ~/.config/nixpkgs/overlays $ cd ~/ $ git clone https://github.com/mozilla/nixpkgs-mozilla.git $ mkdir -p ~/.config/nixpkgs/overlays $ ln -s ~/nixpkgs-mozilla/rust-overlay.nix ~/.config/nixpkgs/overlays/rust-overlay.nix Once installed, you can install the latest versions with the following commands: $ nix-env -Ai nixos.rustChannels.stable.rust Or use this attribute to build a nix-shell environment which pull the latest version of rust for you when you enter it. You can substitute the "stable" channel by "nightly" and "beta", or use the function provided by this overlay to pull a version based on a build date. # How This overlay should auto-update it-self as if you were running rustup each time you go through the rustChannels attributes. It works by using the fetchurl builtin function to pull the same file as rustup do through https. The *.toml manifest file is then parsed (yes, in Nix [3]) to extract the sha256 and the location of all the packages indexed by the manifest file. Then, some logic is used [2] to convert the *.toml file into proper derivations which are used to pull the prebuilt binaries and to change the interpreter of the binaries using patchelf. If you encounter issue, feel free to report them on the nixpkgs-mozilla repository [1], and to fix them as well ;) Have fun and enjoy. #23291: https://github.com/NixOS/nixpkgs/issues/23291 #8697: https://github.com/NixOS/nixpkgs/issues/8697 [1] https://github.com/mozilla/nixpkgs-mozilla [2] https://github.com/mozilla/nixpkgs-mozilla/blob/master/rust-overlay.nix [3] https://github.com/mozilla/nixpkgs-mozilla/blob/master/lib/parseTOML.nix -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Introducing Nixpkgs Overlays
Hello Nixpkgs users,
One of the issues of Nixpkgs is the lack of modularity. By
modularity, I mean that someone else can provide a complementary
source of packages which works side-by-side with Nixpkgs, and that as
a user, you can combine multiple of these sources.
# Extending Nixpkgs Today
Today, we have a lot of way to extend Nixpkgs:
1. We can import nixpkgs, and add packages on top of it.
```nix
let pkgs = import {}; in
pkgs // rec {
foo = pkgs.foo.override { enableBar = true; };
bar = import ./pkgs/bar { inherit (pkgs) stdenv fetchurl foo; };
}
```
2. We have `packageOverrides` from ~/.nixpkgs/config.nix.
```nix
{
packageOverrides = pkgs: rec {
foo = pkgs.foo.override { enableBar = true; };
bar = import ./pkgs/bar { inherit (pkgs) stdenv fetchurl foo; };
};
}
```
3. We have `pkgs.overridePackages`.
```nix
let pkgs = import {}; in
pkgs.overridePackages (self: super: {
foo = super.foo.override { enableBar = true; };
bar = import ./pkgs/bar { inherit (self) stdenv fetchurl foo; };
})
```
But none of these approaches can easily be composed with other sources
doing similar things.
# Extending Nixpkgs with Overlays
Fortunately, the recent improvements of Nixpkgs inner structure
[2,3,4,5], highlights that we have a list of layers which are stacked
one on top of the others.
These layers are literally what composes Nixpkgs, we could technically
rewrite the entire Nixpkgs collection into thousands of these layers,
where each one handles a single package at a time, but this would be
inefficient.
On the other side, we could expose this layering mechanism to external
sources of Nixpkgs, and gain the modularity that Nixpkgs never had.
This is what I did with the `overlays` pull-request [1].
An overlay is literally an additional layer added on top of Nixpkgs,
within the fix-point of Nixpkgs.
The same principles was already used by `pkgs.overridePackages`
without adding the composition ability of overlays.
An overlay would look something like [6]:
```nix
self: super:
{
foo = super.foo.override { enableBar = true; };
bar = import ./pkgs/bar { inherit (self) stdenv fetchurl foo; };
}
```
Which is essentially the minimal part of all the previous examples,
and more over the exact same way we represents the different layers
within Nixpkgs.
The modularity aspect of overlays comes from the fact that overlays
are listed, either in the directory, or as argument of nixpkgs. By
default the ~.nixpkgs/overlays/ directory is considered unless
NIXPKGS_OVERLAYS specify otherwise.
This directory should only contain Nix expression files (or directory
with a default.nix) which are overlays, with the same layout as the
example above. One can also use a symbolic link to where each of
these overlays are installed on your file system.
The directory is converted in a list of elements, which are ordered
based on the alphabetical order of the elements within the directory.
[1] https://github.com/NixOS/nixpkgs/pull/21243
[2] https://github.com/NixOS/nixpkgs/pull/9400
[3] https://github.com/NixOS/nixpkgs/pull/14000
[4] https://github.com/NixOS/nixpkgs/pull/15043
[5] With the help of Peter Simons' extend function.
[6] https://github.com/nbp/nixpkgs-mozilla/blob/nixpkgs-overlay/moz-overlay.nix
# Planning for the future.
As part of this modification, I intend to remove the
`pkgs.overridePackages` function, as this one can literally be
replaced by the following Nix expression:
```nix
let pkgs = import {}; in
import pkgs.path { overlay = [ (self: super: {
foo = super.foo.override { enableBar = true; };
bar = import ./pkgs/bar { inherit (self) stdenv fetchurl foo; };
}) ]; }
```
One additional reason to remove `pkgs.overridePackages` function, is
that the creation of this function also stands as the function which
adds Nixpkgs fix-point. The `pkgs.overridePackages` function does not
play nicely with the `security-updates` branch, as for the applying
patches to packages, we have peels the fix-point out, as well as this
function. Thus, there would be no way to benefit from the security
updates while using `pkgs.overridePackages`, without making it much
more complex.
On the other hand, the overlays system play nicely with the
`security-updates` branch, as it add layers within the existing
fix-point, and thus peeling the fix-point does not change the
overlays.
# If you are not yet convinced
A while ago, I suggested to add modularity to NixOS [7], and I
personally consider it as a great success for one reason. This reason
is allow any user to extend NixOS without changing syntax, and without
changing NixOS sources.
Adding overlays would add the same benefits to Nixpkgs, such as giving
the opportunities to multiple companies to distribute software [6
(above)] without providing a full clone of Nixpkgs them-self.
[7] http://lists.science.uu.nl/pipermail/nix-dev/2008-November/001467.html
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name
Re: [Nix-dev] Incremental recompilation
On Fri, Apr 29, 2016 at 7:56 PM, stewart mackenzie <setor...@gmail.com> wrote: > IMHO, incremental compilation is a strong boon for nix adoption. It is the > only serious issue I can see which prevents Nix being a Make replacement. I agree with you on this point, Nix has the potential of been a better ccache & distcc in one shot. Note, this is not the same issue as mention in the Volkhov email. The email suggest caching artifacts of the compilation spawn by Nix and independently of the build system, while doing a make replacement involves replacing/wrapping existing build system and using Nix for caching artifacts of the compilation spawned in user-land. But, I guess the second problem's solution could be a mean for solving the first problem. Also, I admit I thought on how to solve this issue in the first place, but the main problem I got is not even building, this is only about making a copy of the source directory into the nix store. When your project sources are larger than 1 GB (without the VCS), you don't want to be reading all the bytes before being able to start any compilation. Thus, none of the approaches proposed before are practical for larger projects. So, how can we make it such that it will scale? The only approach I can think of would be to: - Upload each individual file to the Nix store, when they would be needed. - Make a symlink fram to re-build fake source directories. - Use hash-by-content to prevent recompilation. (when using "gcc -M" to filter out directory content, you want to make sure you get the same set of headers, and only cause a recompilation if some of the header changed) -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Difference between Pkgs, Super and Self in this Snippet
On Mon, Apr 11, 2016 at 7:34 AM, Roger Qiu <roger@matrix.ai> wrote:
> ```
> { pkgs }: { # pkgs is the fully configured packages, after overrides
>packageOverrides = super: let self = super.pkgs; in rec { # super is
> without overrides, self is with
> # ... overrides go here ...
>};
> }
> ```
>
> While I understand that `super` is the package set that hasn't been
> overridden yet, what's the difference between `self` and `pkgs`? Do both
> of them have the overrides applied?
For the moment there is no difference between the two.
This makes me think that we should get rid of the `packagesOverrides`
function, and let the content of config.nix be similar to what
all-packages.nix is.
My wish by getting rid of `packagesOverrides` function is to make sure
that we can properly document this in NixOS modules.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] New undeclared dependency for Nix itself?
One other option is that PKG_CONFIG environment variable is not set to find your installed version of liblzma. Otherwise you should probably open a bug on https://github.com/NixOS/nix and hope that Eelco or Shea got time to investigate this issue. On Sat, Apr 2, 2016 at 9:13 PM, Michiel Leenaars <ml.softw...@leenaa.rs> wrote: > Hi Daniel, Nicolas, > > thanks for your suggestions. > > @Daniel: > > I can't yet run configurePhase, because I'm trying to install nix > itself. My complete actions are as attached. > > @Nicolas: the log indicates that pkg-config with at least version > 0.9.0... is present. > > Best, > Michiel > > DP> Run configurePhase, not ./configure. You'll find that we pass quite > DP> a few things in through $confgureFlags and just typing ./configure > DP> loses those. Something similar bit me the other day, but the readme > DP> does say to write configurePhase. > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] New undeclared dependency for Nix itself?
You can look for all the dependencies in the way we build the tarball in nix/release.nix file. I think the problem might be that you are missing pkgconfig, which is used to locate the inputs. I would hope that any dependency is being explicitly list in the release.nix file. On Sat, Apr 2, 2016 at 10:06 AM, <ml.softw...@leenaa.rs> wrote: > Hi all, > > I wanted to see what the status was of FreeBSD support (basically > because I a jail running that needed some new software and I'd like > Nix to manage the dependencies), and noticed something unexpected: > > 1) I clone the Nix git repository from https://github.com/NixOS/nix > 2) I execute ./bootstrap.sh and then ./configure > 3) it fails on something that is not officially listed as a > dependency [http://nixos.org/nix/manual/#sec-building-source]: > > [...] > checking for LIBLZMA... no > configure: error: Package requirements (liblzma) were not met: > > Of course I tried to go around it by installing > > /usr/ports/archivers/lzmalib > /usr/ports/archivers/lzma > > But that didn't help. Is this a new dependency? If so, can someone > point to what *exactly* it is that is needed? > > Best, > Michiel > > > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Status: Transparent Security Updates
Hi all, This is email is an update on the status of the transparent security update feature: - #14000 (#9400) landed again. This change improves the ways Nixpkgs is written. One of the major visible changes, is that `all-packages.nix` is now properly indented :) . Also, Nixpkgs is now written as a single fix-point with multiple extends function. The reason this changes were blocking #10851, was mainly because #10851 requires Nixpkgs to behave as a single and pure function. Please, join me to thanks all the persons who helped by reviewing these changes: * Mathnerd314 * aszlig * John Ericson * Peter Simons * Shea Levy * Vladimír Čunát * zimbatm - #10851 is now rebased, with none of the package fixes. The description of the pull request now explicit the motivations, goals and approach taken in the pull request. This pull request should be complete, and ready for review tomorrow. The reason I stripped all the changes related to the package fixes, is that they can be done in parallel. Thus, I think it is better to avoid adding extra review complexity for the reviewers, and first get the infrastructure in place. What to expect next: The static analysis, added as part of #10851, would be addressed. This static analysis currently reports more than 20k issues. Most of the remaining work would be to minimize the numbers of issues reported by the static analysis. Most of them are common issues related to the lookup of the functions used to build the packages. Fixing those issues would remove a large chunk of these ~20k. Aliasing of packages is currently the source of 2120 issues, while running `nix-env -f ./. -qaP --drv-path`. This is caused by the fact that packages are aliasing each others by using the `pkgs` argument instead of using `self`, or instead of being moved in `aliases.nix`. Cheers, #14000 https://github.com/NixOS/nixpkgs/pull/14000 #9400 https://github.com/NixOS/nixpkgs/pull/9400 #10851 https://github.com/NixOS/nixpkgs/pull/10851 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Transparent Security Updates
On Tue, Feb 16, 2016 at 4:55 PM, Shea Levy <s...@shealevy.com> wrote:
> # nix-store -r /nix/store/…-glibc-2.21
> --option binary-caches https://code.nathan7.eu/hydra --option
> binary-cache-public-keys colossus.nathan7.eu:…
>
> Obviously this assumes you trust his hydra to be providing a real
> result!
I hope this is not an official statement, and even then this is still awful!
We should not suggest to the few number of users who are reading our
mailing list to type such commands, ever!
On Tue, Feb 16, 2016 at 7:29 PM, Kosyrev Serge
<_deepf...@feelingofgreen.ru> wrote:
> rocon...@theorem.ca writes:
>> I am using the following expression which I believe will build a patched
>> version of glibc locally, and then build a patched NixOS derivation.
>>
>> system.replaceRuntimeDependencies = with pkgs.lib;
>> [{original = pkgs.glibc; replacement = …; });} ];
>>
>> I didin't time it, but I think it took around 25 minutes to update my
>> desktop machine this way. Good luck everyone.
>
> For those of us who aren't that fluent in Nix idioms -- could you
> provide a quick summary of how you manage to achieve the seemingly
> impossible?
>
> […]
>
> And lastly -- is this somehow related to the techniques proposed for
> providing NixOS with security updates?
No, this is not related. The solution proposed at NixCon [1][2] aims
at making this transparent, which once complete implies that:
- You would no longer have to copy anything.
- You won't have to watch the mailing list for security issues and
instructions.
- This will work for NixOps, NixOS and for nix-env, nix-build and
nix-shell commands.
- Hydra will build and distribute fixes on top of the existing channels.
- You should never have to trust an unknown remote for getting binaries.
There is already a draft of the transparent security update [3], but
this work is more than likely to bit-rot quickly. To work-around this
bit-rot issues, I currently re-creating this work in smaller patches,
to make them easier to review, and to get them accepted faster.
Unfortunately, without dedication from both me and the reviewers, we
are more likely to never land this changes.
Currently this work is being addressed in [3], and I am creating
various pull request to address each bit independently. Currently I
am working on redoing the work Mathnerd314 did [4], in a way where we
can all have a clear understanding of all the implications [5].
[1] https://www.youtube.com/watch?v=RhcKXS00zEE
[2] https://nbp.github.io/slides/NixCon/2015.ShippingSecurityUpdates/index.html
[3] https://github.com/NixOS/nixpkgs/pull/10851
[4] https://github.com/NixOS/nixpkgs/pull/9400
[5] https://github.com/NixOS/nixpkgs/pull/14000
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/Re:
[Nix-dev] CVE-2015-7547 stdenv-changing fix merged on master and 15.09
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] import vs override
On Fri, Mar 18, 2016 at 11:19 PM, zimbatm <zimb...@zimbatm.com> wrote:
> Hi, stupid question of the day.
>
> When I see things like recurseIntoAttr in all-packages.nix I am left
> wondering why this is better than repeated `import ./-packages.nix {
> lang = lang_1_0; }`, where lang_1_0 would vary. Does anybody know ?
recurseIntoAttrs is used to hint that we have an attribute set of
derivations below, thus to let a few function iterate over the full
list of packages.
If we don't have it is probably because we don't want to list the set
of packages which are below.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Replace module options
No mkForce only applies to option definitions, not to option declarations. On Sun, Nov 29, 2015 at 4:32 PM, Teo Klestrup Röijezon <t...@nullable.se> wrote: > mkForce (https://nixos.org/nixos/manual/index.html#sec-modularity) is > probably what you're looking for then. > > On 29 November 2015 at 17:29, Игорь Пашев <pashev.i...@gmail.com> wrote: >> >> 2015-11-29 19:26 GMT+03:00 Joel Moberg <joel.mob...@gmail.com>: >> > I think every service have a enable attribute, you should be able to set >> > this to false or just override that service with another one (example >> > config.systemd.services.alsa-store.enable=false). nix-repl is useful to >> > inspect what your config looks like, you can invoke it with nix-repl >> > '' and investigate the attribute 'config'. >> >> >> I tried to override the "enable" option a well. And it said >> "The option `services.foo.enable' in is already declared in >> " ¯\_(ツ)_/¯ >> ___ >> 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 > -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Replace module options
Hi, Unfortunately, this is one of the current limitation of the module system. This is can be implemented quickly, but as of today I did not faced enough uses cases to decide what was the proper granularity for it. So, I would appreciate if you can describe in more details what you are trying to achieve, and what module within NixOS is causing you some trouble. On Sun, Nov 29, 2015 at 4:12 PM, Игорь Пашев <pashev.i...@gmail.com> wrote: > Hi all. > > Is there a way to exclude some NixOS module from evaluation > and put my module instead? That is, NixOS defines services.foo > and I want to use my own service.foo. > > I'm not sure it's a good idea, at least I can use a namespace (service.my.foo) > or give my service a fancy name. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix User Profile (NixUP)
P into NixOS. The >> > next step then will then be to extend NixOS and NixUP so that the same >> > configuration can be written into the NixOS user declaration of >> > 'configuration.nix' and into the user's NixUP 'profile.nix'. After that, >> > we could generalize the NixOS modules of those services that could also >> > run as user services and make them available for both NixOS and NixUP. >> > In the long run, NixUP should be developed into an extensive collection >> > of user modules that allow to declaratively configure and manage user >> > applications and user services. >> > >> > >> > Please let me know what you think, and please try to test NixUP! :) >> > >> > >> > Best regards, >> > Thomas >> > >> > >> > [1] https://github.com/NixOS/nixpkgs/pull/9250 >> > ___ >> > nix-dev mailing list >> > nix-dev@lists.science.uu.nl >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> -- >> Mit freundlichen Grüßen, >> Kind regards, >> Matthias Beyer >> >> Proudly sent with mutt. >> Happily signed with gnupg. >> >> ___ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > > > -- > Sincerely, > Arseniy Seroka > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS/Nixpkgs repository labels
For your information, I modified our list of labels, and kept a few old one as they do not map directly to any label of the new set. Thanks for the link, now I recall reading this on the mailing list, I think have a target system makes sense, as well as having a package-class. On the other hand, I think I should to continue to do some triage every few days to see what are the pain points, and improve one step at a time. I invite other contributors to join me on this triaging effort, such that this system is not only made for me. On Sun, Nov 22, 2015 at 3:52 PM, Rok Garbas <r...@garbas.si> wrote: > Quoting Vladimír Čunát (2015-11-22 16:16:10) >> For reference, we had a short but closely related discussion about half >> a year ago: >> http://lists.science.uu.nl/pipermail/nix-dev/2015-March/016549.html >> >> Since then the rate of issues and PRs increased a bit, but their >> structure hasn't changed significantly, I believe. >> > > Tnx Vladimir, I guess we need to document some of this to not forget in the > future. > > > -- > Rok Garbas - http://www.garbas.si > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] NixOS/Nixpkgs repository labels
Hi everybody, I spent a day doing triage of newly created bugs and I think the labels [1] of our repository are currently a big mess. I think the meaning of our labels are not clear for multiple reasons. I will take a few examples to illustrate my point, and then propose a solution to fix that. 1/ Currently our labels are color-coded but most of them have inconsistent colors. For example, work-in-progress duplicate invalid wontfix are all dealing with the state of the pull request / issue, Or worse, some times they have the same color but they do not express the same thing closure-size (topic) needs-changelog (need) 2/ Our labels appear in alphabetic order, which makes it harder to spot the status of a pull request. For example: blocker (severity) will appear before nixos (topic), while security (serverity) appears after. On the other side, if we look at other projects which have a lot of contributions on Github, such as rust [2], they are using a single prefix letter to force the ordering of the labels and use identical colors for each group. I think this kind of organization makes it clear that labels are missing or not, and thus easier to spot the completion of pull request / issues based on the remaining set of color coded labels. On the other hand, I wonder if a gradient of color for severity / completion might not be better. I suggest that we should reorganize our labels as follow (with prefix letters to keep the ordering of categories). severity: (red) [one per issue/pr] blocker security mass-darwin-rebuild mass-rebuild kind: (light-blue) [one per issue/pr] bug question enhancement skill: (pink) [one] good-first-bug trivial sprintable topic: (sticky notes color) [one or many per issue/pr] closure-size darwin documentation gnome3 grsecurity haskell kde kernel nixos darwin non-nixos python status: (light gray) [one per issue/pr] * new work-in-progress duplicate invalid wontfix has: (green) [one or many per issue/pr] documentation * changelog new-package update-package * new-module * update-module * clean-up needs: (light-red) [one or many per issue/pr] feedback changelog documentation * new-module * new-package * update-module * update-package If people agree that this is better than what we have today, I will proceed and rename the labels and reset the color as described above. The idea of the above is that each issue / pull request should have at least one of each label, and the last 2 categories are used to figure out in a simple color-coded way if the issue / pull-request still needs some work to be done before being merged. (thus if there is some light-red, do not land) What do you think? [1] https://github.com/NixOS/nixpkgs/labels [2] https://github.com/rust-lang/rust/labels -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NIX_PATH and tarballs
Hi Daniel, On Sat, Nov 21, 2015 at 10:58 AM, Daniel Hlynskyi <abcz2.upr...@gmail.com> wrote: > But when I run `nixos-rebuild` twice, I notice that tarball is not > downloaded second time. > > root# > NIX_PATH=nixos-config=/etc/nixos/configuration.nix:nixpkgs=https://github.com/NixOS/nixpkgs-channels/archive/nixos-unstable.tar.gz > \ > root# nixos-rebuild dry-build > building the system configuration... > # -> tarball is not downloaded second time <--- > these derivations will be built: > /nix/store/h2sp5p9x3gzryiq57znqdzc3jrw3dlpa-nixos-help.drv > /nix/store/9gzsm78klcassgs9yvpmnd38naczndc1-system-path.drv > /nix/store/rflgcrmas917yzdihxd9kqbp8n27w2qj-dbus-conf.drv > > What kind of caching is this and what happens when upstream tarball changes? I asked Eelco a similar question, and Nix will check the meta data of the file before any attempt to download it, if the meta data highlight that the file is unchanged on the server, then Nix will not re-download it. Your browser does the same thing to avoid re-downloading resources as long as it does not change on the server. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [nix-dev] private NixOS modules
Hi Sergey,
We have a some documenation in the NixOS Manual [1] which explains how
to do that. To make it short, your configuration.nix file should have
an import attribute which is a list of additional modules that you
want to include.
So if you file configuration.nix looks something like (a), you want to
convert it to something similar to (b)
** (a):
{
services.openssh.enable = true = …;
…
}
** (b):
{
imports = [ ./custom-service.nix ];
services.openssh.enable = true = …;
…
}
[1] http://nixos.org/nixos/manual/index.html#sec-modularity
On Wed, Nov 18, 2015 at 8:14 AM, Sergey Mironov <grr...@gmail.com> wrote:
> Nicolas, I didn't know about NIXOS_EXTRA_MODULE_PATH, thanks.
> Could you explain other possible solution in a bit more details? How
> can we include modified module list in configuration.nix?
>
> Regards,
> Sergey
>
> 2015-11-17 17:43 GMT+03:00 Nicolas Pierron <nicolas.b.pier...@gmail.com>:
>> Hi Sergey,
>>
>> I think you can set the NIXOS_EXTRA_MODULE_PATH [1] environment
>> variable to achieve that.
>> Otherwise, you can change your configuration.nix file to always
>> include your new module list, and to include your own real-config.nix
>>
>> [1]
>> https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/eval-config.nix#L30
>>
>>
>> On Tue, Nov 17, 2015 at 2:04 PM, Sergey Mironov <grr...@gmail.com> wrote:
>>> Hi. I'd like to write a couple of NixOS modules which probably don't
>>> look meaningful for large audience. Normally, we keep modules in
>>> nixpkgs/nixos/modules directory and list them in module-list.nix file.
>>> In my case, I'd like to put module in a private place (which is my git
>>> repo which keeps nixpkgs as a Git submodule). Is it possible to
>>> 'include' them in the public list to make them accessible from
>>> per-system.nix files?
>>>
>>> As a result, I'd like to be able to write in configuration.nix
>>> something like the following:
>>>
>>> services.my-custom-service = {
>>> enable = true;
>>> ...
>>> }
>>>
>>> without including expression for my-custom-service in the public tree.
>>>
>>> Regards,
>>> Sergey
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
>>
>> --
>> Nicolas Pierron
>> http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Pass arguments to 'required' configs
Hi Sergey,
If you are not using the proxy_port and proxy_host values for
selecting the modules, I suggest you use the module system instead.
This means that your previous example would become something like the
example below. This solution is a bit more verbose, but you might be
able to introspect these options with nixos-option command line tool
and NixUI.
// configuration.nix
{
require = [
/etc/nixos/configuration.nix
./include/global_bash_aliases.nix
];
custom.go.proxy.port = 4343;
custom.go.proxy.host = "myproxy.local";
…
}
// ./include/global_bash_aliases.nix
{ config, pkgs, lib, ... } :
with lib;
{
options = {
custom.go.proxy.port = mkOption {
default = 4242;
example = 4343;
type = types.uniq types.int;
description = ''
port number used by the goproxy shell alias command.
'';
};
custom.go.proxy.host = mkOption {
example = "example.com";
type = types.uniq types.str;
description = ''
host name used by the goproxy shell alias command.
'';
};
};
config = {
environment = {
extraInit = with config.custom.go.proxy ''
alias goproxy "nc ${port} ${host}
'';
};
};
}
On Tue, Nov 17, 2015 at 2:17 PM, Sergey Mironov <grr...@gmail.com> wrote:
> Hi. This is a follow-up to my previous letter about Private NixOS modules.
>
> Another thing I am missing is the ability to pass arguments to
> 'required' configuration modules. Below is the illustration of the
> idea. Could you please give me some advice on this?
>
> Regards,
> Sergey
>
>
> // configuration.nix
>
> {config, pkgs, ...}:
> let
> proxy_port = "4343";
> proxy_host = "myproxy.local";
> in
> {
> require = [
> /etc/nixos/hardware-configuration.nix
> ..
> (withArguments ./include/global_bash_aliases.nix { inherit
> proxy_port proxy_host; })
> ..
> ];
> ...
>
> }
>
>
> //./include/global_bash_aliases.nix
>
> { proxy_port, proxy_host} :
> { config, pkgs, ... } :
> {
> environment = rec {
>
> extraInit = ''
>alias goproxy "nc ${proxy_port} ${proxy_host}
> '';
> };
>
> }
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [nix-dev] private NixOS modules
Hi Sergey,
I think you can set the NIXOS_EXTRA_MODULE_PATH [1] environment
variable to achieve that.
Otherwise, you can change your configuration.nix file to always
include your new module list, and to include your own real-config.nix
[1] https://github.com/NixOS/nixpkgs/blob/master/nixos/lib/eval-config.nix#L30
On Tue, Nov 17, 2015 at 2:04 PM, Sergey Mironov <grr...@gmail.com> wrote:
> Hi. I'd like to write a couple of NixOS modules which probably don't
> look meaningful for large audience. Normally, we keep modules in
> nixpkgs/nixos/modules directory and list them in module-list.nix file.
> In my case, I'd like to put module in a private place (which is my git
> repo which keeps nixpkgs as a Git submodule). Is it possible to
> 'include' them in the public list to make them accessible from
> per-system.nix files?
>
> As a result, I'd like to be able to write in configuration.nix
> something like the following:
>
> services.my-custom-service = {
> enable = true;
> ...
> }
>
> without including expression for my-custom-service in the public tree.
>
> Regards,
> Sergey
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to move /nix into /usr?
Hi Tobias, On Tue, Nov 10, 2015 at 7:57 PM, Tobias Hunger <tobias.hun...@gmail.com> wrote: > I am wondering how I can implement a stateless system with NixOS. Can you refine what you mean by stateless. >From what I know, NixOS does not depend on any "state" for its execution. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Ideas for a NixOS-related bachelors thesis?
I had quite a long discussion today on #ipfs, on the topic of using IPFS for sharing Nix derivation output. As Eelco mentioned there is no problem of using IPFS today if we want to reproduce the model that we have today with the binary cache. IPNS can be used to index all the compressed nar archived and the narinfo files. On the other hand, if we want to go to a model where the cache is not built by a central authority, which sounds a bit more interesting and challenging, then we would need a way to map a derivation to the output. Note, that the intentional would not help in any way. The intentional model compute hashes after moving the self-references hash to be indexes, which means that you effectively got a different hash than just blindly hashing the content. Also, you probably don't want to upload nar files as-is, even if nothing prevents you from doing so, because you probably want to take advantage of the merkle-dag for sharing similar files, in the same way as we optimize the nix-store with hard links. On Sun, Nov 1, 2015 at 5:58 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > Hi, > > On 01/11/15 18:17, Ericson, John wrote: > >> This is perhaps a bigger project, and one that would require C++, but I >> think a >> lack of the intentional store[1] is the single biggest missing feature for >> Nix. >> >> On 29-10-2015 13:28:10, Erik Rybakken wrote: >> >> The IPFS-thing would be a channel with a binary cache, not a >> /nix/store! >> >> >> I really want IPFS too, but we can only use it correctly once we have the >> intentional store. > > Without an intentional store, IPFS could be used to store the NARs of the > binary > cache, since those can be content-addressed. This is already the case for > cache.nixos.org: > > $ curl > http://cache.nixos.org/nar/1ssnjdbi6jc9729gql4par7g03jz0r52xawkck1kdik4h5ij894g.nar.xz > \ > | nix-hash --type sha256 --flat --base32 /dev/stdin > 1ssnjdbi6jc9729gql4par7g03jz0r52xawkck1kdik4h5ij894g > > The .narinfo files should be stored somewhere else, though, since they're not > content-addressed. However, even in the intensional model, you would need > non-content-addressed files (namely the .drv -> output path mappings). > >> We can also ditch SQLite by >> just storing everything in IPFS. > > Well, you still need to keep track of the metadata of the local store > somewhere > (if only for caching), which may as well be in SQLite. > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The Future of Haskell Packaging in Nix
I think I might have the beginning of an answer for you by addressing
another issue.
One of the problem we have today is that "override" are costly. They
are costly because the default value that we are expecting are
derivations results.
A while back, when Luis was working on the cross compilation issue, we
decided that having a drv.nativeDrv and drv.crossDrv (or similar)
would be a good way to go. Then we added extra arguments to the
mkDerivation functions so that we can filter one from the other. What
is interesting in the previous solution (a-part from the fact that it
is not a good solution from distinguishing cross-compiled programs) is
that the top-level returned value, while still being the first-citizen
was no longer the one of interest.
What I suggest, is that derivations, are just one of the potential
*views* of the package evaluation.
What does that mean, in terms of code?
Currently we have something like:
firefox = callPackage ../application/browser/firefox ;
with a file which looks like this:
{ lib, stdenv, fetchurl, jemalloc […] }:
stdenv.mkDerivation {
name = "firefox-41.0.2";
[…]
}
Looking at this, currently we have a major view which is provided by
the mkDerivation function. Most of the inputs are packages provided
by the callPackage function.
So, what would happen if we had more than one view?
Probably the first thing would be that we would need to up-lift the
mkDerivation function above the arguments of the function.
firefox = callPackageWith context context.stdenv.mkDerivation
../application/browser/firefox ;
and
{ lib, fetchurl, jemalloc […] }:
{
name = "firefox-41.0.2";
[…]
}
We could remove the need for the argument list, but I will keep it now
to keep this example simple.
So, let make multiple views:
viewFunctions = rec {
drv = file: ctx: ctx.drv.stdenv.mkDerivation (raw file ctx);
function = file: ctx: import file;
raw = file: ctx: callWithDrv (function file ctx) ctx; //
callWithDrv query the drv attributes of the arguments.
license = file: ctx: (raw file ctx).meta.license;
name = file: ctx: (raw file ctx).name;
};
firefox = callPackageWith context viewFunctions
../application/browser/firefox ;
Then the evaluation of the above can be evaluated to:
firefox = {
inherit context viewFunctions;
file = ../application/browser/firefox/default.nix;
} // {
drv = viewFunctions.drv file context;
function = viewFunctions.function file context;
raw = viewFunctions.raw file context;
license = viewFunctions.license file context;
name = viewFunctions.name file context;
};
The benefit of this approach is that extending the context, replacing
the body of a package, and in general making introspection becomes
easier as everything is at the same level.
More over, we do not have to do the evaluation of the mkDerivation
function as the mkOverridable function do today, and we can
potentially dramatically increase the speed of "nix-env" as looking
for packages by name is no longer as costly as iterating over all
packages evaluation.
On Thu, Oct 15, 2015 at 10:21 AM, Peter Simons <sim...@cryp.to> wrote:
> Hi William,
>
> >> We still don't have convincing answers to questions like: how do I
> >> compile my package with profiling support?
> >
> > I thought we already have fairly straightforward support for this via
> > overrides? I have been using this method:
> >
> > https://gist.github.com/jb55/af8b095b3ad97fb3035e
> >
> > and then just `nix-shell --arg profiling true` to build with profiling.
>
> yes, you are right, that solution is pretty good.
>
> I guess I'm just concerned about the complexity involved in this
> seemingly simple operation. The average Haskell hacker is not going to
> understand what that Nix code does and how it works, and they'll have a
> hard time coming up with that themselves. Good documentation mitigates
> those issues, no doubt. Still, it would be nice if there was a way to
> simplify this. For example, for every package "foo" we have
>
> haskell.packages.ghcXYZ.foo.env
>
> to enter an interactive shell environment. Why not define
>
> haskell.packages.ghcXYZ.foo.profiled
>
> the same way? We could also have every package set contain a variant of
> itself with profiling enabled. Then the names
>
> haskell.packages.ghcXYZ -- default choice
> haskell.packages.ghcXYZ.profiled -- with profiling
> haskell.packages.ghcXYZ.vanilla -- without profiling
>
> would be defined by Nixpkgs -- instead of requiring users to define a
> "profiled" package set themselves.
>
> Best regards,
> Peter
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/ma
Re: [Nix-dev] NixOS-Wiki alternative. Was: What license does the content of the nixos wiki and the manuals have?
I think having a wiki in git can be a big trouble for users who don't know where to find the "edit" / "login" buttons, but I am sure that we can make the proper template in due time to wrap an interface around such system. On Fri, Sep 25, 2015 at 3:49 PM, Eelco Dolstra <eelco.dols...@logicblox.com> wrote: > […] But I wouldn't call that a wiki, since you can't easily edit it from a > browser, or make it world-writable. But if we do want go that way, another > possibility is GitHub Pages + Jekyll. Also, I wanted to mention that Github offers an option for modifying pages without even cloning the repository on your computer. Which makes this approach less painful for making contributions. https://help.github.com/articles/editing-files-in-your-repository/ I am sure that a review process is good for the quality and consistency of the wiki, but we should *clearly* document how people can contribute to the wiki: - Open an issue for the lack of documentation - Use the ACE editor to edit pages online and submit pull requests - Clone the repository to edit and preview pages locally. Also, I think that having an issue tracker to highlight the lack of documentation is a really good idea. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Logo improvement ideas
Instead of giving 4 choices for each logo, you should ask to rank the logo. Also, I would love to have more choices. For example, I think the hex logo would be nicer with the weight of the straight lambda. Maybe instead of asking for specific logo, we could ask for different details, such as the thickness (small, medium, large, Huge) of the lambda, or the ending (round like the old one, surround-circle, surround-hex, surround-tangent), and the space between the lambda (no space, tiny, huge), the color of the lambda (uniform, feature, half), and the the shade and the colors. On Fri, Sep 11, 2015 at 4:14 PM, Tim Cuthbertson <t...@gfxmonk.net> wrote: > I've now updated this form with the remaining options, so I think it > is nearly ready to go. > > I'll let it stew for a few days in case anyone has suggestions for > improvement before we start collecting results, but does anyone know > who we'd talk to to get a link somewhere official (twitter / planet / > etc)? > > On Fri, Sep 11, 2015 at 9:03 PM, Oliver Charles <ol...@ocharles.org.uk> wrote: >> On Thu, Sep 10, 2015 at 1:35 PM Tim Cuthbertson <t...@gfxmonk.net> wrote: >>> >>> If nobody authoritative wants to set up a poll, I can certainly do one :) >>> I'm a little bit busy at the moment, but as long as we're not in a >>> hurry... >>> >>> To prevent overwhelming people with options, and after letting these >>> stew for a little while, I'd be happy to limit choices to: >>> >>> * shapes: just circle and hex. I think circle is strictly better than >>> "straight", and I think "slant" is too disorganised / unclean to be a >>> winner. >>> >>> * colours: "feature" and "half". The plain versions are probably too >>> boring to bother with. >>> >>> So that only leaves 4 proposals, across those two axis. I can include >>> more if people think it's worth it, but I don't want to overwhelm. >>> >>> I've made a start here: >>> >>> >>> https://docs.google.com/forms/d/1oMKuPCIz5bmUokrN6mllYpIDH7cmVQTzuZAcUdGH1HM/viewform >> >> >> Looks like a step in the right direction! I can't think of anything else I'd >> add. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Logo improvement ideas
On Fri, Sep 4, 2015 at 9:44 AM, Guillaume Maudoux (Layus) <layus...@gmail.com> wrote: > Tim has invested some time in making great logos, and everybody seems to like > the hex-half version. > It would be too sad to loose his job, so what is the next step ? > Who is authorized to do such a modification ? I don't think there is any precedent. The last time was when we settled on the first logo: http://lists.science.uu.nl/pipermail/nix-dev/2009-October/003231.html (and replies) http://lists.science.uu.nl/pipermail/nix-dev/2009-November/003326.html (and replies) I think the board of the NixOS foundation might have the last word, based on the community choices. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What is the end game?
I don't think the #1 is unpractical, if you consider that these
fetches are properly mirrored, which we currently do with channels.
On Sun, Aug 30, 2015 at 5:34 PM, Daniel Peebles pumpkin...@gmail.com wrote:
I'm trying to avoid making this conversation about Hydra (or services)
specifically, but agree with the points you're making.
To try to steer the discussion in the direction I'm most interested in, what
if binutils had a release.nix in its repo? How about gcc or clang? What
would the expressions look like in nixpkgs? The options I can see:
1) nixpkgs is full of e.g., binutils = (import ${fetch* { url =
url/to/binutils; sha256 = abc; }}/release.nix).build
2) Duplicate the release.nix of binutils in nixpkgs
3) Some combination of 1 and 2, where metadata, name, dependencies are
expressed in nixpkgs, but build instructions are in the repo's release.nix
4) ???
5) profit
Actually, I'm not sure #4 and #5 are relevant, but I couldn't think of other
options.
#1 seems impractical because a single nix-env would result in thousands of
fetchurls
#2 seems undesirable due to duplicated information
#3 seems like our best bet, but I don't know what that would look like
On Sun, Aug 30, 2015 at 9:54 AM, Domen Kožar do...@dev.si wrote:
Or we could, as any software, tag and release hydra so that users can
fetch working versions for easier learning curve.
On Sun, 30 Aug 2015 15:38 Nicolas Pierron nicolas.b.pier...@gmail.com
wrote:
Hi Daniel,
On Tue, Aug 25, 2015 at 5:42 PM, Daniel Peebles pumpkin...@gmail.com
wrote:
Let's say for a moment that Nix has taken over the world, and every
open
source project now includes a default.nix or release.nix in its repo
root.
What does nixpkgs look like in this world? Does it duplicate the
individual
package .nix files in their respective repositories? Does it only
duplicate
minimal information (dependencies and meta) from the remote
repositories?
If we were in such world, then the module would probably be best
handled by upstream maintainers.
The way NixOS modules are working, we need all of them before
evaluating any configuration, thus we would need to have a copy of the
configuration file, even if we have to download it. In such case, it
makes sense that NixOS list of modules would be built out-of an
aggregate of fetched resources.
Thus, if we ever do a copy, we should do it with an url and a hash,
and have one of the multiple output of packages be the NixOS module
that we will aggregate, as-if it was a generic post-install script.
Then, the problem with Hydra, is slightly different. Currently hydra
does not provide any stable (tagged) version. I guess we could
experiment the previous suggestion, but I would prefer to have
multiple instances of this problem before attempting any generic
solution as described above. In the mean time, I think having your
own copy of hydra, and using it to aggregate the module which is
inside might be the best solution.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Logo improvement ideas
Thanks Tim, I think we definitely need a new logo, for at least 2 reasons: - The overlap of the lambda does not render correctly in all software. - The colors are not industrial printers friendly. All your proposal are well addressing the first issue, by removing the overlap and adding extra transparency between the lambdas. On the other hand, the gradient might be worse than the current status about making the image easy to print (CYMK). I think we would be printing more and more t-shirts / goodies in the future, and this is a critical issue that we have to solve with the current logo. Also, a-part from the shape of the logo, I think it would be interesting to see how well the colors of the lambda might render with various background colors. The goal is not to choose a different background color, but to make sure that the lambda's color are still good, even if printed on black t-shirts. Personal opinion: shape: - slant does not feels good and straight, as I would expect from our image. - hex, circle, straight are fine. - straight lambdas' left arm seems to be too-long. color: - none removes the charm, of having something a bit different. - half and feature sound both good. - feature sounds interesting, and makes the lambda too obvious, but half sounds warmer/more solid than feature. On Mon, Aug 24, 2015 at 7:58 PM, Joachim Schiele j...@lastlog.de wrote: looks great! On 24.08.2015 05:14, Tim Cuthbertson wrote: Hello all, I'm a big fan of Nix / NixOS, but I've long felt that the logo could do with a bit of work. So I toyed about a bit with inkscape, and came up with a few ideas: https://github.com/gfxmonk/nixos-logo-ideas/tree/master/exports They mostly keep to the existing logo structure, but with some changes: - Make the lines wider, and remove the rounded caps. The existing logo feels too thin, as if it's made of lines rather than shapes. This feels fragile, particularly when scaled down. - Made the lambda structure more obvious. To be honest, it wasn't until fairly recently that I noticed that the logo was made of lambdas. I've added gaps between each one so they don't run into a single shape as much. I've also added some subtle gradients at the top of each, to turn it into more of a woven structure, rather than a snowflake. - Rotated the shape so that there's an upright lambda, and the shape fits better into a restricted-height context (e.g a header bar). # Shape variants: straight: More or less equivalent to the current logo, but with straight (not rounded) edges hex: Blockier in general, and gives the short foot of the lambda a triangular edge. This aligns all outer points to a hexagon shape, mirroring the inner hexagon. slant: The lambdas in this one have a fatter head and thinner feet. This makes the overall structure look more dynamic and organic, but de-emphasizes the clean lambda shape somewhat. The shapes on this one may need some tweaking, as the outer shape (made by the feet) still seems a little disorganized still. # Highlight variants: none: every lambda has the same shading half: every second shape is darker (as in the current logo) feature: the right-way-up lambda is the only darker shape. This makes the repeating lambda structure more obvious, but obviously affects symmetry. I haven't done too much experimentation with the colours, but feel free to crack open the svgs (in the parent directory) and try whatever you like. Let me know what you think! Cheers, - Tim. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Working on multiple modules on multiple branches - single server
Hi Christian, On Thu, Jul 30, 2015 at 9:26 AM, Edward Tjörnhammar e...@cflags.cc wrote: On Thu, Jul 30, 2015 at 07:59:44AM +0200, Christian Theune wrote: Hi, I’m working on a few things for my home server at the moment (Sensu for monitoring, Netatalk for TimeMachine) and I just started splitting my work into multiple branches so that I can submit the pieces individually. However, no I experience some pain while developing as I’m rebuilding the system from various branches all the time (editing locally, rsyncing the whole thing to the machine, then running nixos-rebuild -I …) which turns out will always disable my other work … Is there an obvious solution to this that I’m missing? Complicated git branch management? Use flat topgit, i.e. each service/PR from master and one aggregating topgit branch which has all your service braches in its .topdeps and export that to your builder branch. I concur with Edward, that topgit might solve your issue, by merging your two topic branches into one. On the other hand, TopGit does not provide a nice solution for pushing the branches, as it enforces that you never rebase your branches, which might be harder if you are not used to manipulate merge conflicts. I suggest that you just do the following instead: $ git branch -D aggregate $ git checkout -b aggregate $(git merge-base topic-branch-1 topic-branch-2) $ git merge topic-branch-1 $ git merge topic-branch-2 This would be easier for you if you do not care about the history of the `aggregate` branch. If you are re-building to frequently, I suggest that you rebase your branches on top of the channel version. If you do not know which version you are based on, you can use the following command to instrument your nixpkgs work-directory with branches corresponding to your channels. $ $(git rev-parse --show-cdup)maintainers/scripts/update-channel-branches.sh -- http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixops - nix-channel per machine
The problem of using the `_module.args.pkgs` is that you have the
NixOS module system of the nix-channel, but the package resolution of
the version that you specified. The error that you are seeing is that
the latest module might use a package which got packaged/renamed
recently.
Strangely `pkgs.ipset` does not seems to be used, apart from being
listed as an non-literal example (which is a bug) [1].
One option would be for you to make a dummy derivation for ipset, or
use the one from the latest nixpkgs.
[1]
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/services/networking/firewall.nix#L425
On Mon, Jul 27, 2015 at 1:50 PM, Tomas Hlavaty
tomas.hlav...@knowledgetools.de wrote:
I got the _module.args.pkgs to (almost) work but I think it somehow
mixes up the two nixpkgs versions (running on unstable, overriding
_module.args.pkgs to stable):
error: attribute ‘ipset’ missing, at
/nix/store/fdv2bhnjgdanr87wjqa7rbbm5gf6k4hr-nixos-15.06pre65267.6ad8fab/nixos/nixpkgs/nixos/modules/services/networking/firewall.nix:446:50
Tomas
Tomas Hlavaty tomas.hlav...@knowledgetools.de writes:
Hi Rob Nicolas,
thank you for your suggestions.
The option -I nixpkgs=/path/to/your/nixpkgs sets the nixpkgs globally
for nixops. That is not what I need.
I have tried using nixops set-attrs, but that is also doesn't allow me
to use stable for one machine and unstable for the other.
Maybe this could work if I created two separate networks depending on
nixpks. But this is not a nice workaround.
It looks like the module suggestion might be what I need but that gives
me an error:
error: Module `foo/configuration.nix' has an unsupported attribute
`boot'. This is caused by assignments to the top-level attributes
`config' or `options'. (use ‘--show-trace’ to show detailed location
information) error: evaluation of the deployment specification failed
It seems that I am not allowed to change that. Moreover, it doesn't
seem to be the same as specifying a different nixos-channel.
What I need is something like:
test-logical.nix:
{
network.description = test network;
foo = with-stable-channel ./foo/configuration.nix;
bar = with-unstable-channel ./bar/configuration.nix;
}
Is there a way to achieve that?
Thanks a lot!
Tomas
Nicolas Pierron nicolas.b.pier...@gmail.com writes:
Otherwise, if you are using the latest master of NixOS, then you
should be able to define which set of packages you are interested in
within the module system, while using the modules from the latest
NixOS.
{ config, lib, ... }:
{
config = {
_module.args.pkgs = lib.mkForce (import my-nixpkgs {
inherit (config.nixpkgs) system config;
});
};
}
On Fri, Jul 24, 2015 at 5:56 PM, Rob Vermaas rob.verm...@gmail.com wrote:
Hi Tomas,
you can use -I nixpkgs=/path/to/your/nixpkgs when using nixops. You
can also make it persistent using 'nixops create/modify', the nix path
will be stored in the nixops database, and you can inspect it with
'nixops info'.
Cheers,
Rob
On Fri, Jul 24, 2015 at 3:10 PM, Tomas Hlavaty
tomas.hlav...@knowledgetools.de wrote:
Hi,
in nixops, how can i specify a nix-channel per machine? Or any other
way to have different machines running different versions of nixos?
Thank you,
Tomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Rob Vermaas
[email] rob.verm...@gmail.com
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixops - nix-channel per machine
Otherwise, if you are using the latest master of NixOS, then you
should be able to define which set of packages you are interested in
within the module system, while using the modules from the latest
NixOS.
{ config, lib, ... }:
{
config = {
_module.args.pkgs = lib.mkForce (import my-nixpkgs {
inherit (config.nixpkgs) system config;
});
};
}
On Fri, Jul 24, 2015 at 5:56 PM, Rob Vermaas rob.verm...@gmail.com wrote:
Hi Tomas,
you can use -I nixpkgs=/path/to/your/nixpkgs when using nixops. You
can also make it persistent using 'nixops create/modify', the nix path
will be stored in the nixops database, and you can inspect it with
'nixops info'.
Cheers,
Rob
On Fri, Jul 24, 2015 at 3:10 PM, Tomas Hlavaty
tomas.hlav...@knowledgetools.de wrote:
Hi,
in nixops, how can i specify a nix-channel per machine? Or any other
way to have different machines running different versions of nixos?
Thank you,
Tomas
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Rob Vermaas
[email] rob.verm...@gmail.com
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixos modules: Setting attrsOf sub-options
Hi,
On Wed, Jul 1, 2015 at 12:31 AM, Rickard Nilsson
rickard.nils...@telia.com wrote:
top = mkMerge (
map (a: { ${a}.opt2 = f a; }) (attrNames config.top)
)
This would work, only if you were not redefining top, or if you knew
the list of names ahead.
{
options.top = mkOption {
type = with types; attrsOf (submodule ({ name, config, ... }: {
config.opt2 = f name;
};
};
}
On the other hand, this is the proper way to extend submodules.
Note that `opt1` can be accessed with `config.opt1` within each submodule.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Shape configuration.nix differently
I am not sure to understand your
On Fri, May 29, 2015 at 1:39 AM, Manuel Pages
amarr.industr...@gmail.com wrote:
Hey, I'm working on a differently-shaped /etc/nixos/configuration.nix.
My vision is to shape it like this:
```
{ config, pkgs, ... }:
pkgs.lib.fold (x: y: pkgs.lib.mergeAttrs x y) {} [
import ./hardware-configuration.nix { pkgs = pkgs; config = config; }
import ./boot/grub.nix { device = /dev/sda; }
# ...
]
```
The problem that you see is that recent modifications of the module
system change pkgs to be the result of the configuration, instead of
being the one from your system.
This change as a side-effect of making pkgs.lib cause infinite recursions.
Then, I am not completely sure to understand what you want to achieve
which cannot be done with the module system?
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Shape configuration.nix differently
For your information, the module system is basically doing the following:
let config =
pkgs.lib.fold (x: y: pkgs.lib.mergeAttrs x y) {} (map
(collect_all_imports) { config = config });
in
config
Which is why I was wondering what you were trying to do.
This also mean that any filed imported with imports is a valid
module, in a similar way as configuration.nix. If you look closely,
NixOS is composed entirely of modules.
Then the term submodule is used for options such as fileSysems or
jobs, such that we can extend these options from different modules.
On Fri, May 29, 2015 at 2:24 AM, Manuel Pages
amarr.industr...@gmail.com wrote:
Dear Nicolas, I have already read the diffs and lib/modules.nix
and am sad. I don't have enough knowledge to criticize those changes
though.
Dear Jeffery, this way my submodules are shaped as a first-order
functions (Submodule :: Set - Set), with your approach we
actually have (Submodule :: Set - (Set - Set)) which is fine by
me and I'll use this approach for now.
Thank you very much!
On Fri, May 29, 2015 at 2:04 AM, Jeffrey David Johnson jef...@gmail.com
wrote:
Isn't that the same as
```
{
imports = [
./hardware-configuration.nix
./boot/grub.nix
];
}
```
? I think you can still access config and pkgs from each file.
Jeff
On Fri, 29 May 2015 01:55:34 +0200
Nicolas Pierron nicolas.b.pier...@gmail.com wrote:
I am not sure to understand your
On Fri, May 29, 2015 at 1:39 AM, Manuel Pages
amarr.industr...@gmail.com wrote:
Hey, I'm working on a differently-shaped /etc/nixos/configuration.nix.
My vision is to shape it like this:
```
{ config, pkgs, ... }:
pkgs.lib.fold (x: y: pkgs.lib.mergeAttrs x y) {} [
import ./hardware-configuration.nix { pkgs = pkgs; config = config;
}
import ./boot/grub.nix { device = /dev/sda; }
# ...
]
```
The problem that you see is that recent modifications of the module
system change pkgs to be the result of the configuration, instead of
being the one from your system.
This change as a side-effect of making pkgs.lib cause infinite
recursions.
Then, I am not completely sure to understand what you want to achieve
which cannot be done with the module system?
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
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
--
Fly safe,
Sloz
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Git branches to track nix channels
Hi, I did that a while ago, and somebody removed them, because of the potential noise that such branches can caused. Then I pushed the script that I made to keep track of the channel versions. You can use this script in your nixpkgs working directory, run $ $(git rev-parse --show-cdup)maintainers/scripts/update-channel-branches.sh Then you can make an alias in your .git/config: [alias] fetch-channels = !sh -c \$(git rev-parse --show-cdup)maintainers/scripts/update-channel-branches.sh\ which means that you can also do, from anywhere inside your working directory. $ git fetch-channels This will pull all the channel branches from nixos.org, and also look for the channels that are corresponding to nixos-version, and any channel that you have in ~/.nix-defexpr . On Tue, May 19, 2015 at 9:56 AM, Florian Friesdorf f...@chaoflow.net wrote: Hi, nix channels are series of snapshots of nixpkgs that were succesfully build by hydra and we subscribe and update them via nix-channel - for users of nixpkgs this is great! As maintainers of nixpkgs and users who keep custom patches, we also have one or more local checkouts of git://github.com/NixOS/nixpkgs.git. It would be great if channel information would be available via git as well: - one branch per channel, git reset --hard to the latest successfully build nixpkgs in this channel - tags (channel-name-datetime) for each successful channel build. This would enable us to base local customizations of nixpkgs on-top of successful hydra builds and therefore getting as much binary package support as possible, and would remove the need to additionally maintain channels with nix-channel. What do you think? cheers florian -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gold linker in shell.nix
Hi Nikita I have not looked precisely on using the gold linker yet, but I guess this might be similar to what I have done with overriding the default compiler in stdenv [1]. You might want to have a look around the stdenvAdapters. [1] https://github.com/nbp/firefox-build-env/blob/master/release.nix On Fri, May 1, 2015 at 6:21 PM, Nikita Karetnikov nik...@karetnikov.org wrote: How do I link with gold in nix-shell? ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ #NixOSParis evening — June 4 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
On Sun, Apr 12, 2015 at 7:45 PM, James Cook james.c...@utoronto.ca wrote: Side questions: - Why does stdenv.mkDerivation need to be clever? Why not just blindly apply all the fixes to every package? The substitution is not as simple as doing a mapAttrs, as this would lead to infinite loops, and would imply that you have to download all the binary version of the fixed packages. I don't understand the infinite loop part. Don't we want something like the following? pkgs.wget = applyFixesFrom fixes pkgsBeforeFixes.wget pkgs.foobar = applyFixesFrom fixes pkgsBeforeFixes.foobar ... No we don't want something which is independent of the dependencies. And, in your previous expression, if pkgsBeforeFixes.wget depends on a library which it-self depend on a vulnerable library, then we want this one to be fixed as well. Because of the previous reason, making the transformation independent would imply that all packages would have to be build, which is exactly what we want to avoid as this is either not working / time consuming (otherwise hydra would have done it). Where is the infinite loop? The infinite loop comes with the fact that we don't want the pkgsBeforeFixes.wget, but the pkgsWithFixedDependencies.wget, which happens to be the one that we are trying to produce. Thus if the applyFixesFrom is independent of the list of dependencies, then this would lead to an infinite loop. The issue of having to download all the fixes makes sense. Maybe for now the fixes can be divided into rebuild-the-world fixes (which you'd probably have to download anyway) and non-rebuild-the-world fixes, which can be applied to master the normal way since they won't slow down Hydra? This is not an issue if we redefine mkDerivation, as we would only use the fixes on which we depend on. We don't want to have fixes which are rebuilding the world, because this might be the reason why hydra is lagging behind, but fixes are likely to be patching the world. - What are the `small` and `last` you rever to above? I use small (or quick-fix) to refer to the tiny channel of quick fixes. I use last (or stable) to refer to the last good known state of the channel. The security channel is made out of these two, such that we inherit all packages from the stable channel while doing something similar to a mutation based approach on pre-build stable packages with the ABI compatible changes from the quick-fix channel. On a second thought, I do not think we need a special quick-fix channel at all. What matters is that we can identify ABI compatible packages, in which case the nixpkgs-security is just a mirror of the latest channel update with all changes to all ABI compatible packages applied. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Improving security updates
Hi,
On Fri, Apr 10, 2015 at 7:12 PM, CodeHero codeh...@nerdpol.ch wrote:
So, after this huge update delay for nixos-unstable I think we should
talk about improving the way security updates are handled. One can
currently install security upgrades by using the instructions on this
page (https://nixos.org/wiki/Security_Updates), but it's a lot of work
to find all the libs that need those updates; and flagging packages as
security updates will most likely not work without a dedicated security
team.
We've been brainstorming a little bit on the irc
(https://botbot.me/freenode/nixos/2015-04-10/?msg=36316600page=4), and
we came up with a few ideas. I personally like the extra security branch
idea, but i'm not sure how it would work out
(https://botbot.me/freenode/nixos/2015-04-10/?msg=36318539page=5), so
that's why I'm asking here. Maybe somebody has some ideas and the
know-how to make things better.
The question is: who has suggestions on how to improve the installation
of critical security updates; who knows how to implement the best
suggestion; and who will maintain it?
I want to enumerate a few points that we should keep in mind:
1. This should be done as part of nixpkgs, and not as part of nixos
2. This should be transparent for the end user.
3. We should provide tools to watch for security updates. (polling /
push-notifications)
Currently the only way to provide fast security updates is to
substitute in-place the packages which are vulnerable. I do not think
that we have better alternative here.
Still, I think there is a problem with the approach suggested on the
wiki (https://nixos.org/wiki/Security_Updates ), which is that there
is no automatic relation between the original package and the fix.
The problem I can see with `replaceDependency`, is that we replace
`hash-vul` by `hash-fix` in one derivation, but not in all derivations
which are depending on `hash-vul`.
This leads to 2 questions:
- How do we know that `hash-vul` is vulnerable ?
- How do we know that one derivation depends on `hash-fix` ?
Nixpkgs does not know about anything about runtime dependecies (except
for cross-compilation), it only know things about build dependencies.
This implies that one package can depend on a dependency of its
dependencies. Thus we have to carry over the hash substitution of the
dependencies.
A: buildInputs = [ B ];
B: buildInputs = [ C ];
C: [ { vul = ; fix = ; } ]
A: [ /* A */ { vul = ; fix = ; } /* B */ { vul = ; fix = ; } /* C */ {
vul = ; fix = ; } ]
B: [ /* B */ { vul = ; fix = ; } /* C */ { vul = ; fix = ; } ]
C: [ /* C */ { vul = ; fix = ; } ]
So basically, we want a channel, which is constructed by merging the
`last`, with the `small`. Basically, the merge will flag all `small`
(fix) packages as being a replacement of the `last` (vulnerable).
Then we replace the `stdenv.mkDerivation` function to do the
substitution if the original derivation depends on a fixed small
package.
This method implies that we should never bump the version of small
packages across ABI-incompatible changes. Which means that we would
have to ensure that any small package is versioned in nixpkgs, at
least until the next `last` channel update.
At the end, the small channel should mirror the latest channel, with
delta binary patches for all fixes of the small packages.
I think this is all :)
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix expressions and latest packages
Hi, On Mon, Mar 30, 2015 at 1:06 AM, 胡雨軒 pde-b...@isep.fr wrote: The documentation says Nix conceptually builds package from source but relies on stores (some package caches) to download already built packages. Indeed, the way this works is that we hash the recipe (including its dependencies) and this hash is used to look-up pre-build packages made by trusted remotes. So there is some set of fixed package versions and system update depends on the store update pace, doesn't it? This mostly depend which channel you are following, we have a stable unstable channels which are updated by a buildfarm. Then by trusting the buildfarm, you can download anything which is built by it. On the other hand, you can go extremelly bleeding-edge by pulling the latest recipes from the github repository of nixpkgs. Is it possible to set nix to always download latest versions of installed packages, If you use a channel, then you will mostly be downloading the latest versions, except if this is not built by the buildfarm (no redistributable, no maintainer, not supported architecture). built it aside the old version and upgrade the system automatically? With a cron job, or similar, yes. I know one could think some latest package may be not compatible with each other, but this leads me to the next question. I'm planning to use nix package manager within Arch Linux distro, so the distro team would do what's necessary to avoid incompatibilities. Nix install its packages in /nix/store, which it assumes to be the only one to manage. So we have no conflict with other package managers because we are using a different set of directories. Then, is it possible to configure nix to retrieve data both from Arch repositories and from the AUR? I do not know Arch enough to answer this question precisely. I know somebody did something similar for debian packages, by mocking an FHS layout for one program. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gratuitous generations
Hi Ryan, On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle ryan.trin...@gmail.com wrote: On a somewhat related note, is there any way to see the exact configuration.nix for a particular generation? It would be great to be able to diff generations against each other (e.g.: to figure out whether a channel update caused a problem or whether it was my own change). You are not the first one to request this feature. They are a few issues in the way, but I will open an issue and do it as soon as I am done with the httpd rewrite. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wrapping functions?
Yes, there is a better way to do this, by extending the sub-modules by
the extraUsers option, in a similar way as done by sshd [1,2]. The
idea is that instead of making a function which will pre-process all
the options definitions of one user, you will just extend all users
with a flag.
Note that `userOptions` in sshd is a sub-module, which means that it
behaves as a module in NixOS, except that its `config` argument is re
stricted to what is available for each instance of the option (read
for each user).
Basically, the code that you had in your gist should look something
like (for mkUser):
{config, pkgs, lib, ...}:
with lib;
let topConfig = config; in
{
options.users.extraUsers = mkOption {
options = {config, name, ...}: {
options = {
isUser = mkOption {
default = false;
type = types.bool;
description = set defaults for one user;
};
};
config = mkIf config.isUser {
extraGroups = [ users ];
group = name;
home= /home/${name};
createHome = true;
useDefaultShell = false;
shell = /run/current-system/sw/bin/bash;
};
};
};
}
This way, any user declaration would look like
{lib, ...}:
with lib;
{
config = {
users.extraUsers.joe = {
isUser = true;
};
}
}
[1]
https://github.com/NixOS/nixpkgs/blob/7f90cc40b4b62e9495a77121dc96278501afd79b/nixos/modules/services/networking/ssh/sshd.nix#L282-L284
[2]
https://github.com/NixOS/nixpkgs/blob/7f90cc40b4b62e9495a77121dc96278501afd79b/nixos/modules/services/networking/ssh/sshd.nix#L26-L54
On Fri, Mar 27, 2015 at 5:15 PM, Joe Hillenbrand joehil...@gmail.com wrote:
Is there a better way to do this?
https://gist.github.com/joehillen/5e762c74b6b8f7595736
What I'm trying to do here is create wrapper functions that set some default
values.
The problem is that I have to pass along every attribute I want to be able
to set at the top level.
As you can see, I don't do anything with `description` or `openssh`. I just
pass it along all the way
down to `extraUsers`.
Based on what I've seen, there seems like there is some way to accomplish
this (like an override or 'mkDefault')
but I keep getting confused.
Still learning. Please excuse my ignorance.
-Joe Hillenbrand
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Some bug tracker experience and RFC on improvements
Hi, I totally agree that we should label pull requests, and I think we should do it. Still, many contributions made to the repository are not made in a Pull Request, and it would be nice if we could keep track of these commits too. On Mon, Mar 16, 2015 at 12:43 AM, Austin Seipp ase...@pobox.com wrote: 1) It would also be nice to adopt an official policy of maintainers for the source tree; e.g. who is responsible for certain NixOS or Nixpkgs subsystems, or Darwin/FreeBSD support, etc. This makes it easier to track down the right person, IMO. You can consider me as responsible for NixOS module system (N-lib) and a peer on Nixpkgs lib directory. There are other things I could think of (e.g. milestoning policies for a release), but that's getting a bit ahead of myself. So I'd like to get the discussion out there. FWIW, if people are supportive of this, I'd at least be willing to author a CONTRIBUTING.md file to the tree, and re-name all the existing labels, and add others as specified above (pending a final list some of us can come to an agreement on). That can be done relatively easily with an overall bet benefit, I think. I would be happy to review any modification to the CONTRIBUTING.md page. It might be good to list the most relevant parts for persons who are packaging software in the CONTRIBUTING.md, and redirect to the wiki[1] for detailed information. Or just remove the wiki page, and make this file the central point. [1] https://nixos.org/wiki/Contributing -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to override/replace part of a service definition?
Hi Michael,
On Sun, Feb 22, 2015 at 2:45 PM, Michael Alan Dorman mdor...@jaunder.io wrote:
All the documentation I can find about overriding things seems focuses
on packages, but what I'm interested in overriding is the systemd
pre-start-script. I tried what seemed obvious:
{ config, ... }:
let
cfg = config.services.couchdb;
in {
systemd.services.couchdb.preStart =
''
[…]
'';
}
But that appears to have had an *additive* effect---that is, a copy of
the modified text appears *after* the existing, non-working, definition.
First, you can double check the content of this option without
building a system, with
$ nixos-option systemd.services.couchdb.preStart
The *additive* effect is a feature, which is used in many cases, such
as defining fileSystems, systemd.services, and many more. This
gives the ability to have a module system where multiple modules can
register them-self concurrently in other modules.
You can override other modules definitions, almost as you expected, by
using mkOverride int value, which has a convenient short-cut
named mkForce value, with the force int-priority.
This way, you mention that one definition override all the others, as
thus ignore all the definitions with a default priority. These
properties are briefly described in the Manual [1], and in the Wiki
[2].
[1]
https://nixos.org/nixos/manual/sec-writing-modules.html#sec-option-definitions
[2] https://nixos.org/wiki/NixOS:Modules
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Automatic download option for requireFile
On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát vcu...@gmail.com wrote: On 02/24/2015 12:02 PM, Harald van Dijk wrote: If you just want to _use_ the software, not modify it, not re-distribute it, then for a whole lot of packages, you do not have to accept the license. I meant that in any case you're required to conform to the license terms (whether that means some act of accepting it or not). Which raise a good point, what does allowUnfree = true; means. Does that mean that you read the licenses of all software, and that you do *agree with all* of them? Should we do something like allowLicenses = [ pkgs.licenses.adobeEULA ]; instead? -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple instances - detecting resource collisions - nixos module system question
On Wed, Jan 14, 2015 at 11:17 PM, Marc Weber marco-owe...@gmx.de wrote:
If you use multiple apaches/nginx/mysql/postgresql/whatever instances
its likely to miss adjusting the port or whatsoever. Therefore I'd like
to implement a simple resource tracking module which fails if a
resource such as tcp/ip port or socket or such gets used multiple times.
This is awesome!
It should look like this: http://dpaste.com/10RKJSQ
A test like this:
resources.tcp-ports.80 = {};
causes:
The option `resources.tcp-ports.80.allowCollisions' defined in
`/etc/nixos/nixpkgs/nixos/modules/misc/resources.nix' does not exist.
which I don't get because the dpaste sets a default value for
allowCollisions.
Apparently, the submodules are no longer option sets by default, so
you should wrap the options under an options = { … }; attribute.
If we are at it: Eelco Dolstra proposed services.mysql.services or
such.
I would prefer services.mysql.instances.name. These is what httpd
does with virtual hosts.
What about services.mysqls ? We could deprecade services.mysql
then and ask users to switch slowly. No naming collisions. Naming is
short and could be adopted to other services.
the s is shorter than .instances or .services, but it might be
confusing typo friendly.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
On Sat, Dec 27, 2014 at 7:48 AM, Ertugrul Söylemez ert...@gmx.de wrote:
I think as a first step to get rid of systemd and gain a much more
sensible services model as well we should move away from NixOS modules
for services.
The module system is made in such a way that one can build on top of
the work of the other without having any computer scientist knowledge.
This is also the reason why I am pushing to abolish functions as
option definitions. Most of the time if you want to use a function,
you can express it as a set of input (option declaration) which are
being processed to provide a lower level of abstraction given by
another module (option definitions).
The module system does not prevent us from doing anything, it provides
a new way of formatting which makes things declarative and extensible.
If a module does not serve what you expect, you can always write
another module and use it instead of the previous one. Having
multiple instances of a service is an issue with the module, not a
limitation in the module system.
Being able to reason about the resulting system is very
important.
Have you tried nixos-option ?
I would prefer and do propose an algebraic solution (view services as a
toolbox from which you can pick the services you want and compose them
together). A services configuration then might look like this:
services =
bitlbee { port = 1; stateDir = /var/lib/bitlbee1; }
bitlbee { port = 10001; stateDir = /var/lib/bitlbee2; }
nginx { httpConfig = ...; }
postfix { postMasterAlias = blah; }
First, unamed instance are not modular. This is why we are moving away
from types.listOf and that the suggested alternative is a backward
compatible version named types.loaOf (list or attribute set of).
Second, I see 2 additional concepts and I do not think I would be able
to explain these to my grand-mother, Can you?
I think what you are trying to express can be done with the module
system, maybe you can try to make a prototype using the module system
and a new top-level system-proto option which is declaring submodule
for every service that you want to declare. Maybe we can learn
something from this experiment, in order to better design future
services.
In any cases, I do not think we want to switch to something without
having a working prototype to experiment with. Do not take that
personally, this was also the case with the module system [1].
[1] http://comments.gmane.org/gmane.linux.distributions.nixos/1187
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] escaping /* in emacs nix mode
Hi Mathijs, What I used to do is add a # */ either at the end of the line if this is a shell script, or at the end of the string. On Sun, Dec 21, 2014 at 3:58 PM, Pascal Wittmann pascalwittm...@gmx.net wrote: Hi Mathijs, I am annoyed by this as well. Some time ago I tried to fix this but failed. I should have at least opened an issue about it. Maybe we have some elisp expert who can fix it? Regards Pascal ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix as a dotfiles manager
Hi,
On Sun, Nov 30, 2014 at 9:29 PM, Arseniy Seroka ars.ser...@gmail.com wrote:
Hello!
I want to do smth like
`if networking.name = foo
then writeFile /home/user/.dorfile
else if networking.name = bar then ...`.
What do you mean by networking.name, are you referring to the NixOS option?
But it turnes out that I have no idea how to do it.
So the questions are: is it a good idea to use nix as a dotfiles manager?
I do not yet know. I know I have been doing so without Nix for a
while, and as this was a requested feature, I started making NixUP [1]
(see the corresponding pull request)
And what is a best way to do it?
If you are under NixOS, then you should use the activation script to
copy it to the home directory of the user. Nix is deliberately not
capable of writing out-side the Nix store, but we can create execute
scripts which are sym-linking the files of the Nix store.
I thought smth like: now we are making pkgs and making symlinks to their
executable to ls `~/.nix-profile/bin/`.
Maybe there is a way for some derivation set the output path as a `~/` and
do smth like (write it in a ~/.nixpkgs/config.nix):
No, the ~/ is replaced while building the derivations, such as we do
not pollute user environment, and such that builds can be reproduced
when multiple users are requesting the same derivation.
`configs = buildConfigEnv ~/ [
{ name = .zshrc; contents = ''#zshrc config''
}
]`
If it is possible, please give me some hints or smth and I will try to
implement it (if it is a good idea).
The cleanest approach is what is done in NixOS for environment.etc,
and identically for user.resourceFiles in NixUP.
This way, IMO, we would provide a good mechanism for a dotfiles managing at
several machines.
[1] https://github.com/NixOS/nixpkgs/pull/4594
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS
We have 2 solution, either we stop the regressions when a pull request (PR) is made, or we stop it when the fire is in. The fireman role is hard to keep, and we should be verifying as much as possible at the PR time. Also, if we want to avoid firemans, we probably want to forbid pushing patches to the repository without having made a pull request at first. Which means, no more massive updates without checks. One other way, is to have an inbound, and a nightly branch. Every day, we merge in nightly, the last green-build of the inbound branch which got tested by Hydra. This way we do not have a strict policy for pushing to inbound. The only policy being that nobody merge into inbound if it is broken. This is the model used by Mozilla. On Fri, Oct 24, 2014 at 12:31 PM, Vladimír Čunát vcu...@gmail.com wrote: On 10/23/2014 08:29 PM, Domen Kožar wrote: I'm +1 on this one. Hydra evaluates nixpkgs very fast. I'm only worried if the email is per build, not per jobset evaluation. Is that the case? I don't think it's per-build. I'd expect one e-mail per evaluation to all who committed in-between. The merged PR: https://github.com/NixOS/hydra/pull/126 Vladimir ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Moving some of the NixOS setup to nixpkgs
Hi, First of all I want to thanks Thomas, for his pull request on the Vim configuration [1]. One of the most interesting part, from my point of view, is to give the Configuration Management aspect of NixOS configuration to manage user environments. Jan, suggested a similar idea except that the module lies in the derivation files of the packages. Even if I do not like the approach of storing the modules inside the derivation, I think this is the rough idea we should be aim at, at least at the package level. Jan also suggested to have activations scripts, which is an idea coming from NixOS. Having such a thing would be very convenient at the user level, but leads to multiple questions to know what does it maps to at user profile. (as I am waiting to get feedback / reviews for the Nix's secret branch [2]) I started to work on a system (NixUP) which would be identical and compatible with NixOS, the idea would be to have another tool for managing user profiles, which would be similar to what nixos-rebuild do, and nixos-option should almost the same way. By compatible, I want us to be able to have modules which are targeting both NixOS options and NixUP options. Also, ideally NixUP modules should be valid sub-modules for the users.extraUsers option, such as anything which can be handled at the user level can also be handled at the system level. (such as openssh.authorizedKeys.keys) Among the thing that I am trying to get right at the moment, is what does it means to activate a user profile? Should the activation of a user profile be done only when you switch to a new profile (changing $HOME/.zshrc), or should it be something done only once we are logged in (ssh-agent), or should it be something which is done every time we start a terminal? I think that all these use cases deserved to be considered as valid activations, and then the question is how do we manage them properly. So far, on all my computers, I have been managing my user configuration with a private git repository hosted on a server. I think this is time to change and to update it to use a new model based on NixOS module system. One of the thing that I want everybody to keep in mind, is that doing such system implies that we should not be relying on the operating system. We should not assume that a user can use systemd processes, and this implies that we will have to support multiple backends. Maybe, later, we could be writing some default abstraction based on the operation system on which the user environment is running (host.system = debian), or even infer it in a similar way as hardware-config.nix. Also note, that NixUp should NOT be considered as a replacement of nix-env or Nixpkgs. Managing a configuration of one user does not replace the management of a user environment. nix-env provides some convenient imperative management such as one-click-install, which are not working with the module system (so far). [1] https://github.com/NixOS/nixpkgs/pull/4493 [2] https://github.com/NixOS/nix/pull/329 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Proposal: Standard installation procedure
Hi Ertugrul, On Thu, Oct 16, 2014 at 1:00 PM, Ertugrul Söylemez ert...@gmx.de wrote: Proposal The basic idea is this: To build a system, you use a standard function from Nixpkgs and pass it a configuration module. The result is a derivation that represents a complete self-contained system. The initialisation program ($out/init) is not systemd directly, but a script that first checks whether the filesystem has already been initialised. If not, it sets up all necessary directories (like /etc) and then starts systemd as normal. In other words a container-based NixOS system is really just a Nix store, nothing more. It doesn't need to contain any additional files or directories and building it does not require us to understand the complexity of nixos-install, because it will all be moved to the system initialisation phase. Ideally we should factor out the initialisation into a separate script $out/pre-init that accepts a prefix argument. Then $out/init would simply look like this: #! /bin/sh /nix/store/abcxyz-nixos/pre-init --prefix=/ exec /nix/store/abc123-systemd/bin/systemd I think the exec should be calling $out/post-init, which then execute systemd, such as init is just a convenient concatenation of pre-init and post-init. If we can also move pre-boot initialisation (like installing the boot loader) into the system itself (say, $out/pre-boot), then we could build entire virtual machines completely without relying on a hypervisor and the complexity of having to communicate with the installation process. Just set up the disk image, install the system and use the resulting $out/pre-boot script with appropriate override arguments: out=`nix-build my-machine.nix` # ... copy the closure ... $out/pre-boot --override-grub-device=disk.img This would greatly simplify the implementation of nixos-install (just build the system and invoke the pre-boot script without overrides), but more importantly it would provide a very simple and standardised installation procedure for virtual machines and containers that we can rely on. […] Final remarks = […] What do you think? I would love to provide a prototype, but I really need help with this one. I think this is an awesome idea. I you need help/suggestion for this project feel free to ask me. (pierron on irc / nbp on github). -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
On Tue, Sep 30, 2014 at 1:08 PM, Tim Barbour t...@categorical.net wrote: NILFS2 is a log-structured filesystem which is now in the Linux kernel source tree, and supported by GRUB2. It should appeal to NixOS users because it avoids destructive update (changing a file produces a new version of the file). I have installed NixOS with all filesystems on NILFS2, but encountered some problems along the way. Looking at the details of NILFS2, I saw that it does a linear search within directories. This is far from ideal for the /nix/store as this directory is HUGE. This might have a noticeable cost at the start-up of a computer / programs. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] automatically mount vboxsf
Hi Andreas,
On Tue, Sep 2, 2014 at 11:06 AM, Andreas Herrmann andreas...@gmx.ch wrote:
However, inside the virtual machine these are not available immediately.
These folders have to be mounted manually by executing the following command
as root:
mount.vboxsf hostHome /host_home
Have you tried listing it as an entry of the fileSystem of the vm, such as:
fileSystems./host_home = {
fsType = vboxsf;
device = hostHome;
};
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemd in initrd
Hi, On Thu, Aug 21, 2014 at 3:39 PM, Luca Bruno lethalma...@gmail.com wrote: The disadvantage is that adding systemd to initrd is another level of complexity, and ram usage at boot. Not only, probably after choosing to use systemd, I guess we are not going to maintain the old way of building the initrd. So it's either systemd, or not. Are we only talking about stage-1-init.sh [1] or I am missing something else? It sounds to me that the stage-1 looks more like the activation script than anything else, even if I accept that we might want additional options which might be easier with systemd, I do not see any reason for not having a trivial backend for jobs-entries which just assert that these additional options are not used. [1] https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/stage-1-init.sh -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemd in initrd
On Fri, Aug 22, 2014 at 5:34 PM, Luca Bruno lethalma...@gmail.com wrote: On 22/08/2014 17:28, Nicolas Pierron wrote: I am just saying, that I do not see why we could not use the jobs syntax on top of a string-dependency system which is used by the activation script. Systemd solves job dependencies dynamically to benefit from the kernel scheduling, while the activation scripts are concatenated ahead to make a single simple activation process. I think there is no need to always bring the complexity of systemd to the init process, this could be optional. What I suggest is to have a 2 backends for the init process. The systemd one, and the string-dependency one. Of course, the string-dependency backend would have to assert (while building the system) about cases which cannot be handled. So you want to parse systemd nixos modules in a restricted mode and concatenate them? Yes, that makes sense. Not parsing, just providing a different way to handle the submodule options. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] systemd in initrd
On Fri, Aug 22, 2014 at 5:46 PM, Alexander Kjeldaas a...@formalprivacy.com wrote: How will actually building the initrd be improved? I feel that the dependency resolution is only half of the problem. Things like this is the other half - manual copying of libraries and binaries to minimize initrd size: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/luksroot.nix#L408 Note that this is independent of the problem reported here, in fact, if we want to solve this the proper way we should probably change that at the package level (by providing multiple outputs), to strip what is not needed for executing the commands. For my use I don't care whether initrd is large, but making systemd services portable to initrd by copying their closures will probably affect initrd size a lot more than systemd itself. As Eelco mentioned, the idea would be to have a different set of jobs for the initrd. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Overwriting or merging Nix expressions
On Sun, Aug 17, 2014 at 6:33 AM, Roger Qiu roger@polycademy.com wrote: You mean something like this? something.enable = mkDefault 101 true; # at 101 something.enable = false; # at 100 something.enable = mkDefault true; # at 1000 [1] something.enable = false; # at 100 [1] https://github.com/NixOS/nixpkgs/blob/master/lib/modules.nix#L318 Or something like: something.enable = true; # at 100 something.enable = mkOverride 99 false; # at 99 In both cases the second something.enable has a lower priority than the original statement. Yes, this is what I mean. Would have prefered if this overriding could be done similar to CSS, so later definitions would always override prior definitions unless specified to be immutable. Modules have no ordering, one module can be imported from any other and made visible to all. There is no redefinition, only multiple definitions with different properties (mkOverride, mkOrder, mkIf, mkMerge). A global ordering based on the order of modules does not makes sense, as the mkOverride and mkOrder are highlighting. We have 2 properties to express 2 different kinds of ordering, one which is used to hide definitions with lower priorities, and the other which is used to sort definitions before giving them to the merge function of the option. Ordering based on the imports order would not make any sense because this would then depend on the traversal made of these imports, and I do not think that basing any choice on such unknown thing makes sense to users. On 17/08/2014 2:03 AM, Nicolas Pierron wrote: Hi Roger, Sorry for the late answer. On Mon, Jul 7, 2014 at 8:50 AM, Roger Qiu roger@polycademy.com wrote: I was wondering if there's a way to override Nix expressions. I think you are specifically talking about NixOS modules, right? Say I define a Nix expressions such as: something.enable = true; But later on I decide to change it to: something.enable = false; What you are looking for is having a higher priority for the new option definition, or a lower one for the all option definition. something.enable = mkOverride 99 false; The default priority is 100, smaller means that it would be taken first. mkDefault can be used the opposite way, to define a default value (with a smaller priority) in a module based on other options value. This is useful to define sane relations, while having the default syntax work by default to override the the option, if the default is not satisfying. -- Founder of Polycademy SnapSearch http://polycademy.com https://snapsearch.io +61420925975 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Sprint topics
Topic: Different sources of packages Currently Nix use a mirror which is furnished by Hydra to deliver packages. Hydra and its mirror have been a central point of failure. Other distribution are providing multiple mirrors to answer this solution. Nix is capable of using different sources, but the current model is too centralized. Hydra solves 2 issues, the security aspect (Can I trust the way you are compiling packages), and the transport aspect (Can you transfer me this package). This makes Hydra a central point of failure for security and for reliability. We should change that by adding 2 things; add GPG based authenticity of Nar signatures; add Torrent based transport for nar files. Note that the 2 things are independent from each others. This would be useful for distributing the charge of trust (Nar signature) to the authors of the packages, while getting a package from the user of the package (Nar file). On Sat, Aug 16, 2014 at 7:28 AM, Florian Friesdorf f...@chaoflow.net wrote: Hi, in preparation for the sprint, please add your topics to the titanpad: https://titanpad.com/7yn7iBQ6n2 For discussion it might be nice to have one reply per topic to this email. see you soon florian -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Overwriting or merging Nix expressions
Hi Roger, Sorry for the late answer. On Mon, Jul 7, 2014 at 8:50 AM, Roger Qiu roger@polycademy.com wrote: I was wondering if there's a way to override Nix expressions. I think you are specifically talking about NixOS modules, right? Say I define a Nix expressions such as: something.enable = true; But later on I decide to change it to: something.enable = false; What you are looking for is having a higher priority for the new option definition, or a lower one for the all option definition. something.enable = mkOverride 99 false; The default priority is 100, smaller means that it would be taken first. mkDefault can be used the opposite way, to define a default value (with a smaller priority) in a module based on other options value. This is useful to define sane relations, while having the default syntax work by default to override the the option, if the default is not satisfying. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Smart Card support in initramfs
Hi, On Wed, Aug 13, 2014 at 9:06 PM, tsuraan tsur...@gmail.com wrote: So, I'm wondering, how can I get gnupg, pcscd, and ccid into a Nix initramfs, and how can I get the initramfs's init to use gpg in its luksOpen call? I'm thinking that, from the configuration.nix side, I'd want to just specify a pgp blob (boot.initrd.luks.encryptedkey = ''-BEGIN PGP MESSAGE- ...'') and specify that I want to use a smart card (boot.initrd.luks.smartcard=true), or something like that. Where should I look to start hacking? You should look at luksroot.nix [1], this file is a NixOS module which handle all luks options. These options are then used to generate the script which is written in the initrd. The other bit is whether the Nix kernel builder can handle dependencies in its kernelExtraConfig (kernelExtraConfig=INITRAMFS_SOURCE=\/boot/initramfs\), and build the initramfs before it builds the kernel. I haven't tried that yet, and I'm actually not even really sure where Nix writes its initramfs file, so that's something else I'm curious about, I guess. Is that similar to what is currently implemented with yubikey.ramfsMountPoint ? Otherwise, if the current setup does not satisfy you, you might either checkout NixOS and modify this file, in which case you will need to update your NIX_PATH. Or you can copy this file and rename any luks to luks2, and customize it as you want and later merge your modification back into nixos. In which case you will have to include it in you configuration.nix file (as done for the hardware-configuration.nix file) to make the option visible in your configuration.nix file. [1] https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/system/boot/luksroot.nix -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix os modules: how to filter out unset values
And I guess you are also interested in a way to filter out these null
out of the attribute set that you are getting, as the following code does:
with (import nixpkgs {}).lib;
let
filterAttrsRec = pred: v:
if isAttrs v then
filterAttrs pred (mapAttrs (path: filterAttrsRec pred) v)
else
v;
in
filterAttrsRec (n: v: v != null) {
a.b = null;
c = 32;
d.e = 64;
d.f = null;
g = null;
h.i.j = 1;
}
On Fri, Jul 4, 2014 at 9:35 AM, phree...@yandex.ru wrote:
On Monday, June 30, 2014 22:56:27 Max Ivanov wrote:
That would work if not type of default should match type of option. So
to make it work, I'd need to invent magic values for every type I use,
and then filter them all out, which doesn't seem to be very elegant
solution.
Unless the magic value is null :) Try this:
opt1 = mkOption { type = types.nullOr types.str; default=null; };
The problem is that access to any attribute in
config.services.xyz triggers evaluation of the value and if default is
missing the error is thrown.
So in normal case it enforces values to be set, unless mkOption is
used with default attribute. My minimal goal here is at least to keep
enforcing as it is, and mark optional values so that they don't
appear (or can be removed) from config.services.xyz
On Mon, Jun 30, 2014 at 8:48 AM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.uk wrote:
On 06/30/2014 09:42 AM, Max Ivanov wrote:
Hi Nixers,
I am building a nix os module and stumbled upon a problem which I
might need your advice on how to approach it.
What I can't figure out, is how to filter out unset values even if
they don't have a default value set in mkOption. The idea is that
application itself handles missing values using defaults and I don't
want to duplicate them in a config.
On the other hand, there are some values which are mandatory, so that
if they are missing from configuration.nix config build should fail.
Worth mentioning is that number of mandatory attrs is number of
handled by default attrs, so I'd prefer to whitelist mandatories if it
is possible. Also the solution whatever it is should process cfg
recursively as cfg is actually nested set of types.submodules.
Here is a minimal example, which demonstrates the problem I am trying
to solve. It doesn't make sense overall, so don't judge me for missing
mkIf or silly system services ;) it just shows what I am trying to
achieve.
{ config, lib, pkgs, ... }:
with lib;
let
# question is how to write this function
filter_cfg = cfg: cfg;
cfg = filter_cfg config.services.xyz;
confFile = pkgs.writeText xyz.json (builtins.toJSON cfg);
in
{
options.services.xyz = {
opt1 = mkOption { type = types.str; default=default_opt1; };
# should be excluded from cfg if missing in configuration
opt_devs_defaults = mkOption { type = types.str; };
# error should be raised if missing in conf
opt_mandatory = mkOption { type = types.str; };
};
config = {
systemd.services.xyz = {
serviceConfig = {
ExecStart = ${pkgs.bash} -c 'touch ${confFile}';
};
};
};
}
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
For optional values, you could set default to null and then checking for
null later. If it's null, don't include it in the command and if it
isn't then do include it. Effectively ‘not set’ becomes default.
I'm unsure how you can enforce a presence of an option. Things like
‘assert’ c could be used to catch such things but I don't know whether
this is recommended course of action.
--
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 mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fixing module arguments (PROPOSAL MAY BREAK EXISTING NIXOS CONFIGS, PLEASE READ)
Hi all,
On Wed, Feb 19, 2014 at 4:44 PM, Shea Levy s...@shealevy.com wrote:
Hi all,
The Problem
---
I've been doing a bit of work to make it possible to define nixops
networks modularly in the same way we do NixOS configs (with each
machine in a network being a submodule),
I think this is a good idea, that's what I tried to motivate during
the making of disnix, but apparently failed to explain / explicit to
get it adopted.
and in doing so I've repeatedly
run into issues due to the fact that NixOS's modules take a bunch of
arguments beyond config, options, and lib, in particluar that they take
'pkgs'. The problem with these extra arguments in general is that they
are superfluous and non-modular: superfluous, because any internal
values we want to make accessible to all modules can be put into config;
Yes for packages, even if they are extremely convenient to have as a
first argument, but no for the module logic. (mkIf, mkOption, ...)
Also, having pkgs as an argument is a convenient shortcut for all
expressions. One way to transition would be to define pkgs as being
extracted from the result.
let
moduleWithPkgs = result: m: args: m (args // { pkgs =
result.config.nixpkgs.pkgs });
in
...
I have always made changes such as we can give a LONG grace period for
migrating. People might remember the require attributes, the
rename.nix file[1], or the pkgs.types.loaOf.
The reason why I did so is the same reason why I switched to NixOS in
the first place, *not having to* update, *but choosing when I want to*
update.
This is exactly the same idea we have behind the --rollback option.
Even if the rollback option is not evaluating Nix code, we still want
users to experiment with their old configuration for a while, such as
they are not forced to update at one time, but within a grace period.
In terms of solution, I have no problem adding a pkgs argument to all
sub-modules arguments, even if it defaults to an error message when
the pkgs option does not exist. We can do that while we ensure that
all mkFunctions are extracted from the lib attribute, and not
pkgs.lib. Then, later we can remove this pkgs argument.
[1] https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/rename.nix
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Templates
Hi Malcolm,
You do not have to copy anything in the configuration.nix file or any
where, unless you have inter-dependencies, in which case it is best
filled by NixOS options.
The policy so far has been to provide a list of options (mkOption) for
the most common use cases, extraConfig for the infrequent options,
and configFile for large file with no external dependencies (such as
ups configs) or with secured content(*).
What you can do is add an option to subsitute the generated
configuration file for Riak to use the one provided by the
configFile option if it is defined.
(*) Any file containing protected content should be mentioned with a
string instead of a path, as a path will make a copy of the file. In
such case this also change the behavior as you will need to handle the
version of this file on your own.
On Wed, Jun 26, 2013 at 12:26 PM, Malcolm Matalka mmata...@gmail.com wrote:
I want to add Riak support to NixOS. The config file is quite large and can
be complex. It also is a supported file type in my Emacs so I get pretty
syntax highlighting. Putting this inside Nix expressions losses this
feature. I think putting config files in Nix expressions is suboptimal.
On Jun 26, 2013 9:20 PM, Marc Weber marco-owe...@gmx.de wrote:
I don't get what's bad about nix, you can use import (but you know that).
Nix should suppport: (I never tested it):
let config = import
${derivation_reading_config_file_creating_nix_file}/the_generated_nix_file.nix:
That's closest and works right now.
Well of course you can just write ruby preprocessors turning your
templates into nix files, too.
Or patching nix are options.
But honestly I don't understand your use case.
Marc Weber
___
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
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Stable NixOS releases
Hi all, On Tue, May 14, 2013 at 4:26 AM, Eelco Dolstra eelco.dols...@logicblox.com wrote: So what kinds of updates would be suitable for release branches? Typically, conservative bug fix releases (e.g. Linux 3.4.45 - 3.4.46, Firefox 20.0 - 20.0.1), in particular security fixes. I want to highlight one aspect which should be considered with such release management. As I know a bit about Firefox, I will take it as example, but this also apply for all other packages. Having a release cycle larger than the release cycle of the packages is a security issue. Firefox has a release cycle of 6 weeks, which means that every 6 weeks users are by default updated to the latest version of the browser. If we omit the fact that Firefox maintains an LTS branch (currently 17, soon 24), then we should better constantly follow the latest release instead of keeping 20.0.1, because this version will have no more security updates. Then I don't think that we want to maintain our own version of Firefox by back-porting security patches to an older version. Doing so would imply way more work, by people who are not necessary familiar with the code. - What can we do? If we decide to have larger release cycle, we should either use the LTS in the release branch, or use a beta/alpha version in the unstable branch, such as the release never contain an unmaintained version. Note that features available in beta/alpha version might not be identical to the one of the release (last example in date, third party cookies) So, we should be careful when we claim that a release cycle is made for taking only security updates, because the way packages are maintained might not match our update policy. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] LVM troubles
On Sun, Apr 21, 2013 at 10:29 AM, Rickard Nilsson rickard.nils...@telia.com wrote: […] uses LVM on top of mdadm RAID […] For your information, LVM supports RAID 0 and RAID 1 since 2008-2009. Unless you want to do a RAID 5, I will recommend you to use either one or the other to handle your RAID. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] SVN commit: nix - r34717 - homepage/trunk/nixos
On Wed, Apr 17, 2013 at 7:29 AM, Rob Vermaas rob.verm...@gmail.com wrote: Author: rob Date: Wed Apr 17 14:29:22 2013 New Revision: 34717 URL: https://nixos.org/websvn/nix/?rev=34717sc=1 Modified: homepage/trunk/nixos/index.tt == --- homepage/trunk/nixos/index.tt Thu Apr 11 16:37:41 2013 (r34716) +++ homepage/trunk/nixos/index.tt Wed Apr 17 14:29:22 2013 (r34717) @@ -5,7 +5,7 @@ pa href=screenshots/nixos-kde42-1.pngimg class=inline screenshot src=screenshots/nixos-kde42-1-small.png alt=NixOS screenshot -//aNixOS is an experimental GNU/Linux distribution that aims to improve +//aNixOS is a GNU/Linux distribution that aims to improve the state of the art in system configuration management. In existing Thanks for removing the experimental words from these pages. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] pathExists
On Sat, Feb 23, 2013 at 7:38 AM, Marco Maggesi magg...@math.unifi.it wrote:
Hello,
I'm trying to create a pdf as follows
let
pkgs = import nixpkgs {};
in
pkgs.texFunctions.runLaTeX {
rootFile = ./strengthened.tex;
}
And I get the following error:
...
while evaluating the function at
`/Users/maggesi/Devel/nixpkgs/pkgs/tools/typesetting/tex/nix/default.nix:68:40':
while evaluating the builtin function `pathExists':
string `/nix/store/6x6mcjdj07kwxnhwmcy62slih3pdvkv8-HOAT/article.cls'
cannot refer to other paths
What does it mean cannot refer to other paths in this case?
Thanks?
My guess is that the input of pathExist is a string which is build
out-of a derivation path, so it is considered as being in the context
of the other derivation and thus it cannot be evaluated because this
would be an impurity in our Nix expression.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] commercial license
Hi,
On Sat, Nov 17, 2012 at 4:59 PM, Marc Weber marco-owe...@gmx.de wrote:
I'd force the user to set a config option like this:
~/.nixpkgs/config.nix:
{
proprietary-licenses-accept.your-package = true;
}
and only allow installing the software if this is enabled.
At least this requires attention from the users..
I'm not a lawayer..
I will suggest something stupid.
But old games ensured that you bought the game by asking you to copy a
piece from the license agreement. Such as copying the word number 6
from section 3, paragraph 4.
I feel like using the same technique and comparing with a hash of the
word would be more insightful from a lawyer perspective, because you
have to find the license terms to answer the question.
The binary choice does not imply that the person as got a chance to
read the license before. How many times have you checked the box
without reading the terms of the license?
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
On Sun, Nov 18, 2012 at 10:11 PM, Marc Weber marco-owe...@gmx.de wrote:
Isn't it enough to depend on the git's hash value, eg
fetchgit { git_hash = xxx; url = yyy; }
Is compromising a git repository (even using shallow clones) that much
easier than compromising a .tar.* file protected by sha256?
That would be better because there is no trivial way to check the
sha256 when making the Nix expression.
How does git distinguish a branchnamed after a revision?
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fetchgit - why sha256 protection?
On Sun, Nov 18, 2012 at 10:24 PM, Nicolas Pierron
nicolas.b.pier...@gmail.com wrote:
On Sun, Nov 18, 2012 at 10:11 PM, Marc Weber marco-owe...@gmx.de wrote:
Isn't it enough to depend on the git's hash value, eg
fetchgit { git_hash = xxx; url = yyy; }
Is compromising a git repository (even using shallow clones) that much
easier than compromising a .tar.* file protected by sha256?
That would be better because there is no trivial way to check the
sha256 when making the Nix expression.
How does git distinguish a branchnamed after a revision?
We should also enforce that provided hashes have all digits, to
prevent easier attack.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Build Android apps with the Nix package manager
Hi Sander, First, I saw patches for your thesis, if you want any review/comments feel free to ask ;-) On Wed, Nov 7, 2012 at 12:16 PM, Sander van der Burg - EWI s.vanderb...@tudelft.nl wrote: I have been quiet for some time. At my new employer I have spent some time in developing an infrastructure as well as 2 functions capable of building and emulating Android Apps (http:/www.android.com). I have a detailed blog post about this here: http://sandervanderburg.blogspot.com/2012/11/building-android-applications-with-nix.html Feedback, suggestions, compliments etc. are welcome! This is an awesome work, especially knowing that it can be integrated in Hydra and thus can be used in a continuous integration testing. You should definitely suggest a talk about that to the FOSDEM. For your company, I will recommend you to have a look at Firefox OS and its market place. The good thing about the Mozilla place is that it use install Web API which is open and any browser can implement it, and as such it potentially targets any Web enabled device, which currently means Firefox OS, Android and Desktops. Such integration testing with different targets might be even more challenging and appealing. Congratulation for your new Job. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] buildInputs vs buildNativeInputs
Hi, On Mon, Aug 27, 2012 at 4:40 AM, Mathijs Kwik math...@bluescreen303.nl wrote: On Mon, Aug 27, 2012 at 1:18 PM, Shea Levy s...@shealevy.com wrote: On 08/27/2012 07:12 AM, Mathijs Kwik wrote: Hi all, I understand the difference between buildInputs and buildNativeInputs, but I'm not quite sure how to figure out when an input should be native. The question is, when is the machine code provided by the input executed? If it's at build time (e.g. you execute 'perl' to run a build script), it's a buildNativeInput. If it's at run time (e.g. a linked-to library), it's a buildInput. The reason for this is cross-compilation: buildNativeInputs are host versions of the package, buildInputs are target versions of the package. I understand that part. I recognize a few easy targets like documentation-builders that I know run at build-time, but for other inputs it's not always clear. As I'm not an expert on the build-process of most packages, I was hoping there is some easy trick to find out when the input is needed. For example, can I just try to move stuff from buildInputs to buildNativeInputs one by one? Or some other procedure to try? Or doesn't it matter a lot most of the time? Unless you plan to use a cross-compiled version you should not care much. If somebody wants a cross-compiled version of your software he will do the work. In addition, if you are not cross-compiling, then you have no good way to check if this is correct or not. Viric used to cross compiled for ARM and use qemu for testing the cross-compiled tools. This is a clever way for testing, but we would need a step-by-step process explaining all of that before asking everybody to handle them correctly (knowing that not all packages can be cross-compiled). Cheers, Sorry for the late answer. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] [NixOS/nixpkgs] 58ccf7: it seems fetchgit does not like version tags
Hi, fetchgit nix-prefetch-git have support for any references including tags which are just references, like branches. refs/tags/tag-name On Sat, Aug 11, 2012 at 3:13 AM, Lluís Batlle i Rossell vi...@viric.name wrote: It happened some time ago, that we discussed that fetchgit somehow does not support tags (maybe some tricky syntax makes it work with them). nix-prefetch-git also had some issues. I don't know the status on those, but I think noone added tags support for fetchgit. Maybe someone can update on that status? Regards, Lluís. On Sat, Aug 11, 2012 at 02:47:18AM -0700, Mathijs Kwik wrote: Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 58ccf70f479d6216781ecaf6fdb0329315ae689f https://github.com/NixOS/nixpkgs/commit/58ccf70f479d6216781ecaf6fdb0329315ae689f Author: Mathijs Kwik math...@bluescreen303.nl Date: 2012-08-11 (Sat, 11 Aug 2012) Changed paths: M pkgs/applications/editors/emacs-modes/gh/default.nix M pkgs/applications/editors/emacs-modes/logito/default.nix M pkgs/applications/editors/emacs-modes/pcache/default.nix Log Message: --- it seems fetchgit does not like version tags I think they built ok on my system before, because I nix-prefetch-git'd them. ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] [NixOS/nixos] b609ff: allow out-of-tree nixos modules
Hi all, I wrote a bit of documentation to for people who cannot understand NixOS logic. You might find main use case of modules described on https://nixos.org/wiki/NixOS:Modules On Sat, Jul 21, 2012 at 9:25 AM, Mathijs Kwik math...@bluescreen303.nl wrote: Ah :) I did read the sources of lib/eval-config and saw that configuration.nix is just treated as a module, so I did understand that part. However it wasn't clear to me how to use that to add additional modules (config option modules of course doesn't exist). The reason is that modules are filtered to avoid duplicates and this option may cause the evaluation of a configuration to have no fix-point. In addition, of having no fix-point, this is likely to cause a huge memory consumption compared to our current system, which does not do that well right now. But indeed, now it's clear. Didn't see lib/modules in nixpkgs yet. Quite ingenious :) Thanks, I think I will keep this email around for the bad days :) I'll revert my commit. On Sat, Jul 21, 2012 at 6:11 PM, Shea Levy s...@shealevy.com wrote: Nope, it works for both. 'configuration files' are actually a special case of a module (a module that has no options and unconditionally sets other options). On Jul 21, 2012, at 12:05 PM, Mathijs Kwik math...@bluescreen303.nl wrote: As I understood, require is for including configuration files (that set options). This new option allows adding modules, leading to new options to configure. On Sat, Jul 21, 2012 at 6:00 PM, Shea Levy s...@shealevy.com wrote: How does the 'require' option not suit this need? On Jul 21, 2012, at 11:38 AM, Mathijs Kwik math...@bluescreen303.nl wrote: The environment variable NIXOS_EXTRA_MODULES is now checked to contain a path to a file similar to modules/module-list.nix. You might find some examples in my laptops configurations: https://nixos.org/repos/nix/configurations/trunk/misc/nicolas.b.pierron/ I made a few modules in the common directory which are included in most of my configurations. Which was the first reason of NixOS module system ;) -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixos/nixpkgs release tags?
Hi, On Sun, Jul 15, 2012 at 5:53 PM, Florian Friesdorf f...@chaoflow.net wrote: On Tue, 12 Jun 2012 17:29:43 -0400, Eelco Dolstra eelco.dols...@logicblox.com wrote: Hi, On 12/06/12 17:26, Florian Friesdorf wrote: I have some local changes that are not in a state to be committed yet, but I'd like to use them already, so I have to patch nixos/nixpkgs. Also I'd like to be as close to the channel versions as possible. Are there / could there be tags on github to indicate the latest nixos/nixpkgs versions in the channel? Not currently, but it's on the TODO list. Script that extracts the revisions from a channels nixos/svn_revision file and create tags in nixos/nixpkgs repos (subdir of current dir): https://github.com/chaoflow/skel/blob/master/bin/create_tags_from_nixos_channel.sh I use it: % sudo -H nix-channel --update % cd dev/nixos % (cd nixos git pull --rebase) % (cd nixpkgs git pull --rebase) % create_tags_from_nixos_channel.sh I like the idea, but tag is the wrong git concept for non-release channels. You should prefer a branch which is reset to the latest commit instead of a tag. instead of « git tag name », I will recommend « git update-ref refs/heads/latest-channel /sha1/ ». -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Anyone against giving the nixpkgs attrset a reference to itself?
On Thu, Jul 19, 2012 at 6:03 AM, Mathijs Kwik math...@bluescreen303.nl wrote: On Wed, Jul 18, 2012 at 7:12 AM, Nicolas Pierron nicolas.b.pier...@gmail.com wrote: On Mon, Jul 16, 2012 at 12:32 AM, Mathijs Kwik math...@bluescreen303.nl wrote: I would like to add the final nixpkgs attrset (defaults + overrides) to itself (named finalPkgs). As this is a somewhat strange thing to do, I thought it would be best to ask first :) strange ? No, this is the base principle of NixOS. In fact I would almost recommend you to use a similar idea because I think we should get rid of __override. […] Then we can extend this list with various index files either search at default locations, given as arguments or listed in an environment variable. That sounds very extensible indeed. Can this also be used to override certain attributes of other package sets (like kde or emacs in your example) in such a way that other (rec) attributes of the originating package set see it (like __override gives us)? Because I don't just want to add completely separate package sets, but modify the behaviour of the official set as well. Indeed, the latest example does not allow to override, but we can imagine to merge by using some-kind of priority flag within the derivation if there is a collision, and then only throw if 2 derivations have the same rank. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Firefox 13 issue
On Sun, Jul 8, 2012 at 1:38 AM, Lluís Batlle i Rossell vi...@viric.name wrote: On Sat, Jul 07, 2012 at 05:59:45PM -0700, Nicolas Pierron wrote: On Mon, Jun 18, 2012 at 1:56 AM, Lluís Batlle i Rossell I confirm it's patchelf. An unpatched plugin-container, with a LD_LIBRARY_PATH, works fine. But xpcshell gets killed with and without patchelf. Have you tried to configure firefox with --disable-elf-hack and potentially --disable-elf-dynstr-gc? No, I did not try anything like that. But patchelf should not break any ELF, I think, regardless of how is it prepared. For another kind of work, I want to profile firefox with symbols, and I totally fail although I add --enable-profiling, --disable-elf-hack, ... all appears in 'perf' as without relevant symbols. I'll try this --disable-elf-dynstr-gc too. The flag --enable-profiling enables the Firefox profiler (as opposed as -pgo or what so ever) which is a sampling profiler used to detect what firefox is doing when an event is queued. AFAIK it is not complete and it needs JIT integration to be able to report Javascript frames as well. You might want to try --disable-strip to keep the symbols. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Firefox 13 issue
Hi, On Mon, Jun 18, 2012 at 1:56 AM, Lluís Batlle i Rossell vi...@viric.name wrote: On Mon, Jun 18, 2012 at 12:31:36AM +0200, Lluís Batlle i Rossell wrote: On Sun, Jun 17, 2012 at 11:22:34PM +0200, Lluís Batlle i Rossell wrote: On Sat, Jun 09, 2012 at 08:54:23PM +0400, Kirill Elagin wrote: Ooops, I should have looked through the commit log… Eelco mentioned this in commit#f677edf57f71cf0c8c9e0906d26b4304e4213ef8https://github.com/nbp/nixpkgs-2/commit/f677edf57f71cf0c8c9e0906d26b4304e4213ef8 . Still would be nice is someone using Firefox managed to find some spare time to resolve this… I thought it could be a problem in our old binutils, and I tried disabling ICF (--disable-icf at xulrunner), but the result is the same. So, I wonder, maybe it's a problem in glibc ld.so? Maybe a problem of patchelf (it is patchelfed, xulrunner-stub not). patchelfing 'xulrunner-stub' did not make it fail. But although I've not tested it, I think it may be patchelf breaking the binaries. There patchelf patches two executables: xpcshell and plugin-container. xpcshell was broken already in firefox12 (it suicides before the ld.so much), and also is in 13. I don't know what is xpcshell for, and what can be used for, if it suicides that way. Anyone knows about xpcshell? I confirm it's patchelf. An unpatched plugin-container, with a LD_LIBRARY_PATH, works fine. But xpcshell gets killed with and without patchelf. Have you tried to configure firefox with --disable-elf-hack and potentially --disable-elf-dynstr-gc? -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Tentative NIx Hackfest in Augsburg (or Munich): July 6th-9th
Hi, On Fri, Jun 29, 2012 at 4:20 AM, Florian Friesdorf f...@chaoflow.net wrote: I'm July 1st - 8th at EuroPython in Florence, Italy. This could also be a nice place for a meetup... On Thu, 28 Jun 2012 19:38:25 +0200, Cillian de Róiste cillian.deroi...@gmail.com wrote: I've added a brief page to the wiki which we could use for planning: https://nixos.org/wiki/Nix_Hackfest:_2012-07_Augsburg This might be a good opportunity to create a wiki page to summarize upcoming events and past events, such as we can claim an active community. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-prefetch-git in nixpkgs
On Fri, Jun 8, 2012 at 3:13 AM, Kirill Elagin kirela...@gmail.com wrote: 2012/6/8 Nicolas Pierron nicolas.b.pier...@gmail.com Hi, On Thu, Jun 7, 2012 at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: I'm reading nix-prefetch-git from HEAD right now and its behaviour seems to be consistent with documentation except for a small bug that renders those --* setters a bit unusable (see this). I don't understand, the for loop should still iterate over the arguments, unless bash is removing them from the list of argument because they are directly used. I probably should explain what was going on. Note that when you call `./nix-prefetch-git --url git://gitorious.org/qt-labs/jom.git --rev HEAD`, $3 is --rev, and due to those lines that I modified in the first patch, $expHash becomes --rev. Since there is no `--hash` option, $expHash is not overwritten later and that's why call to nix-store fails. Good catch. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-prefetch-git in nixpkgs
Hi, On Thu, Jun 7, 2012 at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: I'm reading nix-prefetch-git from HEAD right now and its behaviour seems to be consistent with documentation except for a small bug that renders those --* setters a bit unusable (see this). What you call the old syntax is currently the most used. I would be quite happy to remove it, but this will change a lot of hashes. I don't understand, the for loop should still iterate over the arguments, unless bash is removing them from the list of argument because they are directly used. Next. You are giving a tag as `rev`. `rev` must be one of HEAD, `refs/*`-reference or commit hash (actually adding support for tags would be really nice). refs/tags/v1.0.11 May be a --tag which does this desugaring should be enough. The problem is that the script doesn't have a code path that handles invalid rev's — it just doesn't do anything (see here) =). Can somebody accept these patch, if this is not already the case? 2012/6/4 Lluís Batlle i Rossell vi...@viric.name Hello, I can't understand how nix-prefetch-git works. If I call: ./nix-prefetch-git git://gitorious.org/qt-labs/jom.git v1.0.11 it does not fetch anything and gives always the same hash. If I call: ./nix-prefetch-git --url git://gitorious.org/qt-labs/jom.git --rev v1.0.11 it says: unknown flag '--rev'. And its output without parameters is a help that says: syntax: nix-prefetch-git [options] [URL [REVISION [EXPECTED-HASH]]] Options: --out path Path where the output would be stored. --url url Any url understand by 'git clone'. --rev ref Any sha1 or references (such as refs/heads/master) --hash h Expected hash. --deepClone Clone submodules recursively. --no-deepClone Do not clone submodules. --leave-dotGit Keep the .git directories. --builder Clone as fetchgit does, but url, rev, and out option are mandatory. So, do I fail to understand how to call nix-prefetch-git, or it is very wrong? :) Thank you, Lluís. ___ 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 -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] using my own xorg.conf
Hi James, On Sat, May 26, 2012 at 6:19 AM, James Cook james.c...@utoronto.ca wrote: NixOS currently generates an xorg.conf file based on various options services.xserver.*. Unfortunately these options are not quite flexible enough to support my preferred configuration[0]. For the past few months, I've gotten around this by doing two things: Where have you look for information, this means that you did not found the right answer before making attempts to patch NixOS, which exactly why I introduce NixOS module system ;-) 0. Add services.xserver.config = builtins.readFile ./xorg.conf; to configuration.nix (referring to my own xorg.conf) 1. Patch modules/services/x11/xserver.nix to remove services.xserver.config = '' ... ''. If I don't do this, then the resulting x.org configuration consists of the default configuration concatenated with my configuration. Have you tried mkOverride ? Options are by default merged based on the type of the option. strings are concatenated, but mkOverride is getting rid of al other definitions and replace them by your current one. So, at best you should never have to modify NixOS files. services.xserver.config = pkgs.lib.mkOverride 50 (builtins.readFile ./xorg.conf); I would prefer to replace step 1 with something simple like: 1. set services.xserver.generateConfig = false; in configuration.nix This does not seems necessary anymore. Cheers, -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] SVN commit: nix - r34197 - in nixpkgs/trunk/pkgs: misc/busybox top-level
Hi Eelco, On Mon, May 21, 2012 at 10:51 AM, Eelco Dolstra e.dols...@tudelft.nl wrote: * By default, build a dynamically linked Busybox. In the initrd we need Glibc anyway, so there is no point in static linking. This saves about a megabyte from the initrd. Just to comment, my guess is that busybox was statically build for the bootstrap tools. It does not matter much since we can override the configuration. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] lighttpd service
Hi,
On Tue, May 22, 2012 at 3:13 PM, Alexander Foremny
alexanderfore...@googlemail.com wrote:
I am trying to write a service module for lighttpd. I came up with a
minimal example [1] which is giving me the following error upon
rebuilding my system.
Nice. I would be happy to see that.
How can I make my option services.lighttpd known to NixOS?
Every NixOS file, even your configuration.nix is a module, this means
that you don't have to build against a custom version of NixOS unless
you want to modify some of its files. If you just want to *add* a new
module, I will recommend you to use the require or imports
attribute in your configuration.nix.
So your /etc/nixos/configuration.nix should look like:
{
require = [
lighttpd/default.nix
];
…
}
The syntax of module is documented in the wiki[1] for more detail.
[1] http://nixos.org/wiki/NixOS:Modules
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using Nix to build embedded linux firmware
Hi, On Mon, May 21, 2012 at 10:11 AM, Felix Lange f...@travelping.com wrote: A closer look at Nix has revealed some questions: Cross Compilation There seems to be some work in the nixpkgs tree that deals with cross builds (pkgs/top-level/release-cross.nix). It would be interesing to hear from the people who are behind this. Are cross builds alive and supported? I have been using some of them recently, to cross-build the Javascript engine of Firefox. So even if you cannot cross-build perl yet, you can still use perl to bootstrap and configure your builds. Nix packages are design such as we can distinguish between the host dependencies and the build dependencies. So the same nix-expression can be used for both the build version and the host version. The usual approach of package manager is to maintain a separated set of packages for building the host versions. Nix's binary size and runtime requirements: Our usual size limit for images is 8MB compressed. With an image that small, we need to be really picky about what goes in and what doesn't. Quick measurement shows that Nix + libraries take ~10MB on disk. AFAIK, Nix also requires the C++ STL. We have almost a similar issue with our bootstrap tools, even if the size is not as important we try to reduce to the minimal set of programs needed for bootstrapping Nix packages, without any host system. One similar thing that I have been working on recently is the cross-bootstrap tools which implies cross-compiling the tools needed for bootstrapping Nix packages on another device which already has Nix installed. I am biased, but I really love to be able to build and *test* cross-bootstrap-tools by using Nix feature to delegate jobs to another computer with a different architecture. For your limited use case, I won't recommend to embedded Nix on the device because you cannot compile on the device. What you seems to need is limited to the update/rollback constraint which is done by replacing a symbolic link (filesystem?) and running a generated script/program (called activation). Remote installation of packages: As a follow-up thought to the last one, would it be possible to update an installation remotely, with only a very limited set of tools being present? I've looked at Disnix, and the README says that all target hosts need to have Nix (and Nixpkgs) installed, which is unfortunate but understandable given its intended use case (server/cluster deployment). The Nix store file structure seems simple enough to allow remote management. Is this correct? This is seemes correct to me. If you don't plan to have Nix on board, you can just maintain the closure of the wanted systems on the remote and remove everything which is not listed in the closure of the systems. Nix can generate such closure, and Hydra (the buildfarm) can even be used to generate them. Configuration changes: System configuration (networking, services...) is not part of Nixpkgs but is kept in the NixOS tree. This is good, because we have very specific needs in terms of network configuration and implement it ourselves anyway. How does Nix handle pre/post upgrade scripts? As far as I understand, the Nixpkgs tree only contains build instructions, any output is created at compile time. Nix does provide post-install script because we want to have deterministic and isolated results, which is the key of the reproducibility and thus the rollbacks. Each time NixOS is started it does not assume any setup of the system and start creating/upgrading the system. In case of dynamic data (as opposed to static packages/configuration), they can be updated by using a migration script if data are already present on the system. This system is used by Hydra (the buildfarm) to update the database schema. The hic here is about rollback. Your tools have to know how to revert the schema of your dynamic data. Without such abilities, Nix rollbacks are useless when the schema is updated. Our current activation script is a shell script, but I guess you can cross-compile a small generated binary to do the same if needed. -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] SVN commit: nix - r34080 - in nixos/trunk/modules: system/boot tasks
On Sun, May 13, 2012 at 6:33 PM, Eelco Dolstra e.dols...@tudelft.nl wrote:
Log:
* Require fileSystems to be set.
Modified: nixos/trunk/modules/system/boot/stage-1.nix
==
--- nixos/trunk/modules/system/boot/stage-1.nix Sun May 13 19:10:57 2012
(r34079)
+++ nixos/trunk/modules/system/boot/stage-1.nix Mon May 14 01:33:11 2012
(r34080)
@@ -304,7 +304,7 @@
# !!! copypasted from upstart-jobs/filesystems.nix.
mountPoints =
- if fileSystems == null
+ if fileSystems == []
then abort You must specify the fileSystems option!
else map (fs: fs.mountPoint) fileSystems;
devices = map (fs: if fs.device != null then fs.device else
/dev/disk/by-label/${fs.label}) fileSystems;
Using the assertions option should be better instead of having an abort.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Nix-commits] [NixOS/hydra] be3748: In case of deep clone, make sure there is local br...
On Wed, Apr 25, 2012 at 04:49, Rob Vermaas rob.verm...@gmail.com wrote:
Log Message:
---
In case of deep clone, make sure there is local branch.
diff --git a/src/lib/Hydra/Helper/AddBuilds.pm
b/src/lib/Hydra/Helper/AddBuilds.pm
index 3a81cb5..feecf0d 100644
--- a/src/lib/Hydra/Helper/AddBuilds.pm
+++ b/src/lib/Hydra/Helper/AddBuilds.pm
@@ -343,6 +343,10 @@ sub fetchInputGit {
($res, $stdout, $stderr) = captureStdoutStderr(600,
(git, pull, --ff-only, -fu, --all));
die Error pulling latest change from git repo at `$uri':\n$stderr
unless $res;
+ # Make sure there is a local branch
+ ($res, $stdout, $stderr) = captureStdoutStderr(600,
+ (git, checkout, -f, $branch));
+ die Error making local branch $branch in $clonePath from git repo
at `$uri':\n$stderr unless $res;
You should avoid checkout, in fact it would be better to have
bare/mirror repository for git.
I you want to create a local branch, use git fetch -fu origin
+$branch:$branch.
I think you can get rid of the deep clone condition here and use the
other branch which already have git fetch -fu origin
+$branch:$branch.
--
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
