Re: [Nix-dev] [ANN] Home Manager
Nice work! On Sun, Jul 2, 2017 at 11:58 PM, Robert Helgesson 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] firefox package questions
On Mon, Jun 19, 2017 at 12:25 PM, Roland Koebler wrote: > - Name: > I installed firefox-esr, but the started Firefox called itself "Nightly". > I searched the mailinglist, and it looks like it is called "Nightly" This is a branding issue. We could technically do what Debian did, i-e to use the release parameters with a different name. Another option for you it to use the version pre-built by Mozilla, which is available under the attribute firefox-bin. > - Data choices: > After starting Firefox, it tells me: > "Nightly automatically sends some data to Mozilla so that we can >improve your experience. [Choose What I Share]" > > When I click on "Choose What I Share", I get to the data-choices- > preferences-dialog (Preferences -> Advanced -> Data Choices), > but this dialog is empty. > > So, does the NixOS-Nightly-Firefox automatically send data? > Is there a way to prevent this? > And is this documented somewhere? I added telemetry data to Firefox lately, so I can tell you that by default telemetry is not sent on custom builds of Firefox. https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe#Setup_building You can check the content sent to Mozilla by browsing "about:telemetry". If you are still worried, you can browse "about:config" and search for "toolkit.telemetry.enabled". > - Parallel install of esr and newest version: > I would like to install both firefox and firefox-esr and access both > in the same environment (without switching environments). > Would it be possible to e.g. add a "firefox-esr"-executable-symlink by > firefox-esr, so that it works as follows? > - $ firefox > starts the newest version if both firefox and firefox-esr are installed, > or the newest or the esr version if only one is installed > - $ firefox-esr > always starts the esr-version 1/ The simplest way, is to use the nix-shell to run firefox and to make an alias to it: alias firefox="nix-shell -p firefox-bin --run firefox" But this method will not give you rollbacks. 2/ You can also install them in different user profile with the "-p" option of nix-env. 3/ Or create a new derivation which only creates a wrapper and "exec"-ute the binary that you want to start. -- 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 wrote: > On 4 June 2017 at 00:35, Nicolas Pierron 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 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 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
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 wrote: > Nicolas Pierron writes: > >> On Fri, Apr 14, 2017 at 4:40 PM, William Casarin 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
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 wrote: > Nicolas Pierron schrieb am Fr., 17. März 2017 > um 22:36 Uhr: >> >> On Fri, Mar 17, 2017 at 9:38 PM, Benno Fünfstück >> 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 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
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 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 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 wrote: > Nicolas Pierron 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 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 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
Re: [Nix-dev] NixOS Security Team
On Wed, Dec 7, 2016 at 12:52 PM, Graham Christensen wrote: > Yes indeed! I thought about nbp, but noted that he didn't specifically > mention interest in that thread. That is also why I didn't suggest > vcunat and others. Thanks to everybody suggesting I should be part of this team. I honestly do not have much time to dedicate to Nix and NixOS, and the more people have access to sensitive information, the more we have ways to compromised our security. This is for this exact reasons that I did not participate to the "distros security mailing list" thread. Yes, I do have concerns about the security of the Nix ecosystem, but I do yet not think I have to be part of this team to fix existing security issues of the Nix ecosystem. If this team needs my help, they can always contact me on a per-issue basis. -- 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] Incremental recompilation
On Fri, Apr 29, 2016 at 7:56 PM, stewart mackenzie 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 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 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, 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 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&pasta 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 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 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, Игорь Пашев wrote: >> >> 2015-11-29 19:26 GMT+03:00 Joel Moberg : >> > 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, Игорь Пашев 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)
gt;> > >> > The plan is now to test NixUP and hopefully merge NixUP 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 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 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 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 :
>> 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 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 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 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 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 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 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/mailman/li
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 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 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 wrote: >> On Thu, Sep 10, 2015 at 1:35 PM Tim Cuthbertson 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) 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 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 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
>> wrote:
>>>
>>> Hi Daniel,
>>>
>>> On Tue, Aug 25, 2015 at 5:42 PM, Daniel Peebles
>>> 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 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 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
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 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 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 {
>>> inherit (config.nixpkgs) system config;
>>> });
>>> };
>>> }
>>>
>>>
>>> On Fri, Jul 24, 2015 at 5:56 PM, Rob Vermaas 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
>>>> 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 {
inherit (config.nixpkgs) system config;
});
};
}
On Fri, Jul 24, 2015 at 5:56 PM, Rob Vermaas 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
> 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
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
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
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
> 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 wrote:
>>
>> > I am not sure to understand your
>> >
>> > On Fri, May 29, 2015 at 1:39 AM, Manuel Pages
>> > 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] Shape configuration.nix differently
I am not sure to understand your
On Fri, May 29, 2015 at 1:39 AM, Manuel Pages
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] 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 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 (-) 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 > 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 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 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
On Sun, Apr 12, 2015 at 8:56 AM, James Cook wrote:
> On 10 April 2015 at 14:16, Nicolas Pierron
> wrote:
>> Hi,
>>
>> On Fri, Apr 10, 2015 at 7:12 PM, CodeHero 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=36316600&page=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=36318539&page=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 :)
>
> Dependency replacement has me pretty confused. If someone will indulge
> me, I want to make sure I understand the above point, or at least how
> replace-dependency.nix works (assuming that's what you're talking
> about).
>
> First of all, am I correct in assuming that replace-dependency.nix
> works by taking the output of the old derivation and doing some
> relatively fast post-processing, looking for symlinks to the old
> package and replacing with the new?
Almost, basically this looks like doing a search and replace of the
hash dependency by another in one output.
Redefining mkDerivation is just a simple way to collect all "patches"
which have to be done to the output.
> Now, let's work with an example: wget depends
Re: [Nix-dev] Improving security updates
Hi,
On Fri, Apr 10, 2015 at 7:12 PM, CodeHero 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=36316600&page=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=36318539&page=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] Gratuitous generations
Hi Ryan, On Mon, Mar 30, 2015 at 9:47 PM, Ryan Trinkle 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] Nix expressions and latest packages
Hi, On Mon, Mar 30, 2015 at 1:06 AM, 胡雨軒 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] 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 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 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] Automatic download option for "requireFile"
On Tue, Feb 24, 2015 at 12:20 PM, Vladimír Čunát 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] How to override/replace part of a service definition?
Hi Michael,
On Sun, Feb 22, 2015 at 2:45 PM, Michael Alan Dorman 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 ", which has a convenient short-cut
named "mkForce ", 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] How to add (self-signed) SSL certificate to NixOS?
Ok, it should have, can you open a bug and cc me, I will try to look
at it during the week-end.
I guess this might be a side-effect of the attrsOf.merge function
which is used by loaOf.
On Wed, Feb 4, 2015 at 11:18 PM, Bjørn Forsman wrote:
> On 4 February 2015 at 21:56, Nicolas Pierron
> wrote:
>> On Wed, Feb 4, 2015 at 10:26 AM, Bjørn Forsman
>> wrote:
>>> [...]
>>> Apparently, that was only half the problem. I also need to _override_
>>> this entry, because the ca.nix module already provides
>>> environment.etc."ssl/certs/ca-bundle.crt". My attempts so far have
>>> failed:
>>>
>>> (1) Plain setting. Causes "mismatched duplicate entry
>>> /nix/store/HASH1-my-ca-bundle.crt <->
>>> /nix/store/HASH2-cacert-2014-0715/etc/ca-bundle.crt":
>>>
>>> environment.etc."ssl/certs/ca-bundle.crt".source = ...
>>>
>>> (2) "Inner mkForce". Also causes "mismatched duplicate entry ...":
>>>
>>> environment.etc."ssl/certs/ca-bundle.crt" = lib.mkForce { source = ...; };
>>
>> The following should work:
>>
>> environment.etc."ssl/certs/ca-bundle.crt".source = lib.mkForce ...;
>
> Unfortunately it does not. That also results in "mismatched duplicate
> entry ..." error.
>
> - Bjørn
--
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 add (self-signed) SSL certificate to NixOS?
On Wed, Feb 4, 2015 at 10:26 AM, Bjørn Forsman wrote:
> On 2 February 2015 at 21:06, Bjørn Forsman wrote:
>> On 2 February 2015 at 17:43, Eelco Dolstra
>> wrote:
>>> A better way (not tested):
>>>
>>> environment.etc."ssl/certs/ca-bundle.crt".source =
>>> pkgs.runCommand "my-ca-bundle.crt" { }
>>> ''
>>> cat ${pkgs.cacert}/etc/ca-bundle.crt ${./my-certificate.crt} > $out
>>> '';
>>
>> That works! Thank you.
>
> Apparently, that was only half the problem. I also need to _override_
> this entry, because the ca.nix module already provides
> environment.etc."ssl/certs/ca-bundle.crt". My attempts so far have
> failed:
>
> (1) Plain setting. Causes "mismatched duplicate entry
> /nix/store/HASH1-my-ca-bundle.crt <->
> /nix/store/HASH2-cacert-2014-0715/etc/ca-bundle.crt":
>
> environment.etc."ssl/certs/ca-bundle.crt".source = ...
>
> (2) "Inner mkForce". Also causes "mismatched duplicate entry ...":
>
> environment.etc."ssl/certs/ca-bundle.crt" = lib.mkForce { source = ...; };
The following should work:
environment.etc."ssl/certs/ca-bundle.crt".source = lib.mkForce ...;
?
> (3) "Full mkForce". This blows away all other environment.etc.* attrs,
> making the system unable to boot:
>
> environment.etc = lib.mkForce {
> "ssl/certs/ca-bundle.crt" = ...
> };
>
> (4) Merge/override config attribute. Causes infinite recursion:
>
> environment.etc = config.environment.etc // {
> "ssl/certs/ca-bundle.crt".source = ...;
> };
--
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 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.". 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 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 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 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 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] Proposal: Standard installation procedure
Hi Ertugrul, On Thu, Oct 16, 2014 at 1:00 PM, Ertugrul Söylemez 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] 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] NILFS2, NixOS, nixpart and Blivet
On Tue, Sep 30, 2014 at 1:08 PM, Tim Barbour 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 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
On Fri, Aug 22, 2014 at 5:46 PM, Alexander Kjeldaas 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] systemd in initrd
On Fri, Aug 22, 2014 at 5:34 PM, Luca Bruno 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:17 PM, Luca Bruno wrote: > On 22/08/2014 17:01, Nicolas Pierron wrote: >> 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. > Can you rephrase? I didn't understand, sorry. 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. -- 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 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] Overwriting or merging Nix expressions
On Sun, Aug 17, 2014 at 6:33 AM, Roger Qiu 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 >> 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] Smart Card support in initramfs
Hi, On Wed, Aug 13, 2014 at 9:06 PM, tsuraan 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] LXC templates for NixOS?
I know Peter Simons worked on LXC support recently, and also offlinehacker and Zef Hemel did some work around that too, see the following thread for more info: https://github.com/NixOS/nixpkgs/issues/1088#issuecomment-44595302 -- 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 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] 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 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 > 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] Sprint topics
Topic: Support passwords in Nix & NixOS Currently persons who are making modules might not be aware that any password option would appear in a readable format for all users. This is a sad state as the only source of information of such limitation is the documentation. We should make this state obvious by adding the "types.password", which would annotate any strings with the right of the user session. Then "nix" should prevent the files from ever being readable by the user of the same group. This should be applied to both the derivation file and the output of it. On Sat, Aug 16, 2014 at 7:28 AM, Florian Friesdorf 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 > 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] 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 {}).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, 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
>>
>> 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 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] Persona support in Hydra
This is awesome! On Thu, Nov 7, 2013 at 2:54 AM, Eelco Dolstra wrote: > Hydra now allows you to log in using Persona, Mozilla's single sign-on system > (https://login.persona.org/). This means that if you have a valid email > address, you can log in. The main reason for logging in is that you get a > personalised dashboard page, which: \o/ No more password to forget. > * Shows all Hydra jobs of which you are the maintainer (i.e. that have a > meta.maintainers attribute that includes your email address). The "My Jobs" view would be better if we could sort the jobs by name / branch-name. > * Shows "starred" jobs, that is, jobs that you have flagged in Hydra as being > interesting. So even if you're not a maintainer of a job, you can still keep > track of its status. Nice. > The dashboard is a work in progress. Feedback on what sort of things might be > useful in the dashboard is welcome. It would be useful to have maintainers for NixOS modules, or at least for the tests. That's a long time since I last visited Hydra, but I love the reproduce link which download all the inputs :) -- 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 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" 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 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 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 wrote: > Author: rob > Date: Wed Apr 17 14:29:22 2013 > New Revision: 34717 > URL: https://nixos.org/websvn/nix/?rev=34717&sc=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 @@ > >src="screenshots/nixos-kde42-1-small.png" alt="NixOS screenshot" > -/>NixOS is an experimental GNU/Linux distribution that aims to improve > +/>NixOS 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] Missing command suggestions
Hi, On Mon, Mar 25, 2013 at 6:36 AM, Eelco Dolstra wrote: > NixOS now provides Ubuntu-style missing command suggestions. I implemented > this > a while ago, but now it's enabled by default as part of the NixOS channel. > > So if you try to run a command that isn't installed but is available in the > NixOS channel, you get a message like: > > $ pdflatex > The program ‘pdflatex’ is currently not installed. It is provided by > several packages. You can install it by typing one of the following: > nix-env -i tetex > nix-env -i texlive-core Awesome !!! This is realy great to have such suggestion to avoid searching for packages. > And if the environment variable $NIX_AUTO_INSTALL is set, the missing command > is > installed and executed automatically: > > $ hello > The program ‘hello’ is currently not installed. It is provided by > the package ‘hello’, which I will now install for you. > installing `hello-2.8' > ... > Hello, world! Whoa, this is even better and making Nix a powerful zero-install like tool, modulo the fact that we cannot provide a path-independent channel to make useful shareable user-land nix-store. On Mon, Mar 25, 2013 at 8:25 AM, Marc Weber wrote: >> And if the environment variable $NIX_AUTO_INSTALL is set, the missing >> command is >> installed and executed automatically: >> >> $ hello >> The program ‘hello’ is currently not installed. It is provided by >> the package ‘hello’, which I will now install for you. >> installing `hello-2.8' > > I'd prefer such message: > > Application hello is provided by package hello. > May I install it to your user profile by running nix-env -i hello ? > > As alternative you can install packages system wide by adding them to > /etc/nixos/configuration.nix option environment.systemPackages > > [y] to install, ctrl-c to cancel I agree with this change, and using " I " in a system message is kind of weird from my point of view. I think this is good to have a $NIX_AUTO_INSTALL being able to install any without asking. But it would be nice to suggest a system modification. $ export NIX_AUTO_INSTALL=never Does not print anything $ export NIX_AUTO_INSTALL=ask (trusted users) Application Y is provided by the following packages: X1 X2 Do you want to install X1 in your user profile? [y/n] n Do you want to install X2 in your user profile? [y/n] y $ export NIX_AUTO_INSTALL=always (trusted users, only one package) Application Y is only provided by package X. Package X will be installed into your user profile. Use Control-C to interrupt this installation. $ export NIX_AUTO_INSTALL=* (untrusted users) Application Y is provided by the following packages: Contact you system administrator to install any of the following packages: X1 X2 -- 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] wiki and utf-8 characters
Hi, I want to mention: *** Not everybody is a developer *** Even if this sounds wrong for some persons on this mailing list, don't forget that we should lower the barrier of edition, especially on the wiki more than anywhere else. In my opinion the login process of the current wiki is already too much. * The greatest wiki should provide the ability to have WYSIWYG anonymous contributions online. I agree, this sounds crazy, but one can limit the number of anonymous contributions to typos. This is often the most valuable contributions, as they prevent people from judging the wiki on something irrelevant from the subject addressed in the wiki page. Providing this on top of git is doable, the hosting server should provide an anonymous user account on which we can add a commit hooks to restrict the amount of modifications. Github also provides a "Zen Mode" for editing files on-line. This is not yet a WYSIWYG and it need authentification, but this is another way to make modifications. Protecting the account creation with an htaccess is a terrible idea, as this break the concept of being able to edit things easily. * Getting an identity on the wiki should be easy. To get more content, we should use a simple login system. Currently the simplest login system I know is Persona[1], or OpenID, others are tied to accounts such as Google, Facebook and Twitter. This way we avoid storing password on the server, only an email address which can also be used for authoring wiki documentation. * Moderation / Review Multiple people complain about spam on the wiki, and I am among them, as I subscribed to the rss feed of the wiki. Having a review process to go over large contributions would be nice, before somebody can be vouched access to the documentation. Just as a reminder, not everybody is a developer, and the wiki is a way for people who are not familiar with the code to contribute to Nix / Nixpkgs / NixOS. We should not neglect our choices as this is shaping the future of our projects. Personally, I don't think Github is the best solution, it is one solution which is good for developers but a bit harder for others. [1] http://labs.newsint.co.uk/blog/2012/10/why-mozilla-persona-is-the-right-answer-to-the-question-of-identity/ -- 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 wrote:
> Hello,
>
> I'm trying to create a pdf as follows
>
> let
> pkgs = import {};
> 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] nixos hackday on 2.3.
Hi, On Sat, Feb 23, 2013 at 8:11 AM, Rok Garbas wrote: > hi guys (i dont believe we have any female user, yet!), Don't assume that. It is hard for them to don't feel excluded, and if any are reading I recommend them to join other groups such as Womoz. > we'll be having again a day when we'll be working on nixos. as said in > subject this hacking will happen on 2.3. in ljubljana, cyberpipe > (http://kiberpipa.org). so in case somebody is traveling nearby and would > like to join us you'll be more then welcome. > > we have also our todo list http://titanpad.com/v17FugCecZ > in anycase you'll hear from us on #nixos ... sayonara. Nice list, at what time & timezone would you be hacking, to know if we can provide some help over IRC. -- 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
wrote:
> On Sun, Nov 18, 2012 at 10:11 PM, Marc Weber 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] fetchgit - why sha256 protection?
On Sun, Nov 18, 2012 at 10:11 PM, Marc Weber 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] commercial license
Hi,
On Sat, Nov 17, 2012 at 4:59 PM, Marc Weber 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] Dealing with non-Bash /bin/sh on non-NixOS
Hi, There is no point at providing a restrictive shell except for a few cases where we are looking for correctness or optimization. The only thing were such change might benefit is to highlight that some program depend on bash, by breaking them silently. So If you want to do such change, do it as a per project basis, for packages which have been fully verified but certainly not as a global modification. On Fri, Nov 9, 2012 at 10:49 AM, Michael Raskin <7c6f4...@mail.ru> wrote: >>> How do you test packages locally with /bin/sh pointing to Dash on NixOS? >>> I had no idea that's possible. Currently derivations are builds with the patchShebang function which lookup up the binary name in the PATH and substitute it. So the choice between dash and bash will depend on the PATH order. Personally, if such choice is made, I think I will do the same thing as I did on every Ubuntu, namely undoing this conservative bad choice of staying outdated. I am using both zsh and bash, and staying decades in the past to respect POSIX is a bad choice, especially if bash is POSIX compliant. To give a comparison, this is exactly like saying, I won't use this web browser because it implements features which are not yet standardized. -- 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 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] [Nix-commits] SVN commit: nix - r34635 - configurations/trunk/tud
Hi;
On Fri, Oct 26, 2012 at 9:28 PM, Eelco Dolstra wrote:
> Log:
> * Udev no longer assigns persistent names to network devices, so we
> have to do it ourselves :-( Use "internal" and "external" instead
> of eth0 and eth1.
>
> Modified:
>configurations/trunk/tud/cartman.nix
>
> Modified: configurations/trunk/tud/cartman.nix
> ==
> --- configurations/trunk/tud/cartman.nixFri Oct 26 10:00:29 2012
> (r34634)
> +++ configurations/trunk/tud/cartman.nixFri Oct 26 19:28:41 2012
> (r34635)
> @@ -172,11 +172,11 @@
> domain = "buildfarm";
>
> interfaces = [
> - { name = "eth1";
> + { name = "external";
> ipAddress = myIP;
> subnetMask = "255.255.254.0";
>}
> - { name = "eth0";
> + { name = "internal";
> ipAddress = (findSingle (m: m.hostName == "cartman") {} {}
> machines).ipAddress;
> subnetMask = "22";
>}
> @@ -224,27 +224,33 @@
>
> [...]
>
>services = {
>
> +udev.extraRules =
> + ''
> +ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:19:d1:19:28:bf",
> NAME="external"
> +ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:04:23:df:f7:bf",
> NAME="internal"
> + '';
> +
This sounds like a common thing which should probably be shared if the
MAC address is defined as part of the network interface and so prevent
users from digging in udev syntax.
--
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/nixos] a5969: sshd: Do detach into thebackground
Hi, On Sun, Oct 7, 2012 at 10:35 AM, Michael Raskin <7c6f4...@mail.ru> wrote: >> > Commit: a5969634f4da94f85ffbce2ce81f760fd73c67e5 >> > >> > Log Message: >> > --- >> > sshd: Do detach into the background >> > >> > This is necessary to ensure that jobs that need to start after sshd >> > work properly. >> >>this seems counter-intuitive to me. How is running sshd asynchronously >>going to make the service more reliable for dependent jobs that start >>after it? A synchronous start-up feels more predictable to me. What am I >>missing? > > I guess Systemd lacks the means to say that "started" means "listening > on proper TCP port". And without this, sshd detaching is the only clear > point in time that allows to decide that it somehow started. If I remember correctly, Systemd will create a listening socket before sshd starts and then sshd will flush the socket content. I guess you can check if a service is started by waiting on answers produced by the service. http://0pointer.de/blog/projects/systemd.html -- 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 wrote: > On Mon, Aug 27, 2012 at 1:18 PM, Shea Levy 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
