[Nix-dev] Backport nodejs-8_x to 17.03

[Wout Mertens]

I'd like to have Node 8 in 17.03, is there any reason why we shouldn't do
that?

It would be a non-default attribute, like in master, so the only impact
would be on Hydra I suppose.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] drone and nix (sort of solved)

[Wout Mertens]

Nice! Why is it not perfect?

On Fri, Jun 16, 2017 at 1:21 PM Harmen  wrote:

> Hi all,
>
> I while ago here I asked about using nix with drone.io (a CI system which
> uses docker), to deal with push based tests. I previously reported back
> with a solution with gitlab, but I did end up with a workable (not perfect)
> solution for drone.
>
> On the 'drone agent' machine run this once:
>
> # docker volume create nix
> # docker run --rm -v nix:/newnix nixos/nix cp -a /nix/store /nix/var
> /newnix
>
> in the .drone.yml files:
>
> pipeline:
>   build:
> image: nixos/nix
> commands:
>   ...
> volumes:
>   - nix:/nix/
>
> And whenever you want to update nixchannel:
>
> # docker run -v nix:/nix/ --rm -ti nixos/nix nix-channel --update
>
>
> This will share the /nix directory with every build, so rebuild (and
> downloads!) are kept to a minimum.
>
>
> Maybe it helps someone.
> Thanks!
> Harmen
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] In multi-user Nix, let the daemon handle creation of GC roots

[Wout Mertens]

Note, sharing /nix is already not really possible because the metadata is
stored in sqlite and its locking does not play nice with nfs. (*)
Another issue is that right now, nix does not /require/ the daemon to work,
and this proposal would change that.

However, you can totally share /nix between multiple hosts, you just have
to pinkie-promise not to write to it from multiple hosts at the same time.

Wout.

(*): the reason is that fnctl() locking is broken on many implementations.
If this testing project
https://sourceforge.net/projects/locktests/files/?source=navbar says it's
not broken, you can totally use nix on nfs.

On Sun, 18 Jun 2017, 5:10 AM ,  wrote:

>
> My understanding is that currently GC roots (symlinks in
> profiles/gcroots) are created and deleted directly by the various Nix
> tools, even in multi-user configurations. (whether on NixOS or on
> another Linux distribution)
>
> It seems to me that it would be useful for the daemon to handle making
> GC roots, and forbid users to directly create GC roots.
>
> The features that come to mind:
> - Allows later implementing policy about GC roots/space consumption
> - Allows avoiding complicated locking around doing GC
> - Allows /nix to be put on network storage transparently
> - Allows /nix to be shared between containers transparently
>
> The network-storage-/nix use case may be the most important, since there
> seems to be a lot of people who want to put /nix on NFS.
>
> Thoughts? Has this been considered?
>
> Thanks for Nix!
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Auto-generated expressions for applications

[Wout Mertens]

This actually ties into my question about nodePackages. It seems to me that
for these large packaging systems, we should have separate repos that
update from their source, and you can then include them into your nixpkgs
configuration.

Only packages that are useful by themselves should get a derivation in
nixpkgs, the rest would be in these add-on repos. For nodejs, that would be
e.g. yarn.

No idea how to accomplish this though.

On Tue, May 30, 2017 at 9:31 AM Freddy Rietdijk 
wrote:

> Hi,
>
> At several places in Nixpkgs we use auto-generated data, mostly for the
> larger package sets like Haskell. Sometimes we also use auto-generated sets
> for applications that may need different versions than are offered in the
> main package sets. In the past months several issues/PR's have been opened
> to add rather large Python applications to Nixpkgs, generated using
> `pypi2nix`.
>
> Using such tool to generate the expressions has some very big advantages.
> However, there's also a disadvantage. The expressions shouldn't only be
> updated when there's a new release of the application, but also whenever
> there's security updates in any of its generated dependencies, which the
> application maintainer now has to keep track of. Therefore, I find it quite
> a risk to have separate package sets. At the same time, we'll also likely
> run behind in the main package sets every once in a while.
>
> What do you think of this issue? Any suggestions how we can improve this?
> Maybe we could have a server/bot that runs update scripts and opens a PR
> whenever there's an actual diff?
>
> Freddy
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] How to best override nodePackages?

[Wout Mertens]

Hi,

I understand that there have been some changes that make Nixpkgs more
overridable.

Could anybody explain how to override the nodePackages derivations so I can
use the most recent versions? Node packages update much faster than
Nixpkgs/Hydra can follow, and compiling them is trivial…

Ideally, this would be just in .nixpkgs/config.nix

Thanks!

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixops: Deploying from macOS

[Wout Mertens]

This issue is quite old and I haven't tried in a while :) back then, even
without nix-daemon it didn't work.

BTW, why not let nix-daemon read the configuration from /etc so that it can
change at runtime?

On Sun, May 28, 2017, 8:13 AM Kirill Elagin <kirela...@gmail.com> wrote:

> I still can’t make sense of the troubles you were experiencing.
>
> As far as I understand it, if one has configured nix-daemon, then there is
> basically no way to use `NIX_REMOTE_SYSTEMS` from nixops and one has to
> configure nix-daemon by setting `NIX_REMOTE_SYSTEMS` in its environment.
> After reading the description of your issue I was left under an impression
> that you somehow managed to make it work without reconfiguring nix-daemon.
> Am I wrong?
>
> Without nix-daemon I don’t think there are any problems as of today.
>
>
> On Sat, May 27, 2017 at 9:08 PM Wout Mertens <wout.mert...@gmail.com>
> wrote:
>
>> The problem is probably ssh-ing into the VM it should be using for
>> building. This probably fails due to not having the correct environment,
>> and then it silently decides building on OSX.
>>
>> On Fri, May 26, 2017, 12:39 PM Kirill Elagin <kirela...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have finally switched my laptop to using nix-daemon and got bitten by
>>> https://github.com/NixOS/nixops/issues/260 (and/or
>>> https://github.com/NixOS/nixops/issues/483).
>>>
>>> To be honest, I am completely lost. Could someone please explain to me
>>> what is going on here?
>>>
>>> 1. The error that I get is this one:
>>>
>>> > error: a ‘x86_64-linux’ is required to build
>>> ‘/nix/store/cm2y0hlgv6dpcyzf022ih1b0qwh3x5n7-etc-logind.conf.drv’, but I am
>>> a ‘x86_64-darwin’
>>>
>>> Why on Earth is Linux needed to build _config files_? Building configs
>>> is mostly echoing, right? Who exactly tells nix that `environment.etc`
>>> files require a certain platform to be built? Maybe we could fix that?
>>>
>>> 2. How is this all related to nix-daemon? `nixops/deployment.py` checks
>>> for `os.environ.get('NIX_REMOTE') != 'daemon'`, why does it do this? Is
>>> that because `NIX_BUILD_HOOK` does not work when using nix-daemon? What’s
>>> that whole story with `NIX_REMOTE_SYSTEMS` and ssh keys really about? Why
>>> are there no issues with ssh keys when we I do not use nix-daemon? Why
>>> copying something manually helps?
>>>
>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixops: Deploying from macOS

[Wout Mertens]

The problem is probably ssh-ing into the VM it should be using for
building. This probably fails due to not having the correct environment,
and then it silently decides building on OSX.

On Fri, May 26, 2017, 12:39 PM Kirill Elagin  wrote:

> Hi,
>
> I have finally switched my laptop to using nix-daemon and got bitten by
> https://github.com/NixOS/nixops/issues/260 (and/or
> https://github.com/NixOS/nixops/issues/483).
>
> To be honest, I am completely lost. Could someone please explain to me
> what is going on here?
>
> 1. The error that I get is this one:
>
> > error: a ‘x86_64-linux’ is required to build
> ‘/nix/store/cm2y0hlgv6dpcyzf022ih1b0qwh3x5n7-etc-logind.conf.drv’, but I am
> a ‘x86_64-darwin’
>
> Why on Earth is Linux needed to build _config files_? Building configs is
> mostly echoing, right? Who exactly tells nix that `environment.etc` files
> require a certain platform to be built? Maybe we could fix that?
>
> 2. How is this all related to nix-daemon? `nixops/deployment.py` checks
> for `os.environ.get('NIX_REMOTE') != 'daemon'`, why does it do this? Is
> that because `NIX_BUILD_HOOK` does not work when using nix-daemon? What’s
> that whole story with `NIX_REMOTE_SYSTEMS` and ssh keys really about? Why
> are there no issues with ssh keys when we I do not use nix-daemon? Why
> copying something manually helps?
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Presenting nix-index: a file-not-found utility

[Wout Mertens]

Very cool!

On Sat, Apr 22, 2017, 8:55 AM Linus Heckemann  wrote:

> On 22/04/17 07:45, Linus Heckemann wrote:
> > On 22/04/17 07:03, Danylo Hlynskyi wrote:
> >> Great!
> >> A question: what does it mean when expression is in round parents?
> >>
> >> (wineUnstable.out)2,141 r
> >>
> /nix/store/cl7b6kw7y8cqkpy4pnwwq4iqmaiw52d0-xextproto-7.3.0/include/X11/extensions/secur.h
> >>
> >
> >
> https://github.com/bennofs/nix-index/blob/master/src/bin/nix-locate.rs#L110-L112
> >
> > That it's not a top-level package.
> > ___
> > nix-dev mailing list
> > nix-dev@lists.science.uu.nl
> > https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> >
>
>
> No, sorry, that's wrong — I misinterpreted the source code. The long
> usage description explains it though:
>
> * we can't know the precise attribute path for every package, so if you
> see the syntax `(attr)`
>   in the output, that means that `attr` is not the target package but
> that it
>   depends (perhaps indirectly) on the package that contains the searched
> file. Example:
>
>   $ nix-locate 'bin/xmonad'
>   (xmonad-with-packages.out)  0 s
>
> /nix/store/nl581g5kv3m2xnmmfgb678n91d7ll4vv-ghc-8.0.2-with-packages/bin/xmonad
>
>   This means that we don't know what nixpkgs attribute produces
> /nix/store/nl581g5kv3m2xnmmfgb678n91d7ll4vv-ghc-8.0.2-with-packages,
>   but we know that `xmonad-with-packages.out` requires it.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 17.03 'Gorilla' Released

[Wout Mertens]

Woohoo! Thanks everyone!!

(sorry for the noise but could not let this one go by)

On Fri, Mar 31, 2017, 4:29 PM Robin Gloster  wrote:

> Dear community,
>
> I'm proud to announce the 7th NixOS stable release 17.03 named
> "Gorilla".
>
> With over 12479 (last release: 13283) commits from 625 (last release
> 554) contributors the release brings a few highlights:
>
> * Nixpkgs is now extensible through overlays. See the Nixpkgs manual for
>   more information.
>
> * This release is based on Glibc 2.25, GCC 5.4.0 and systemd 232. The
>   default Linux kernel is 4.9 and Nix is at 1.11.8.
>
> * The default desktop environment now is KDE's Plasma 5. KDE 4 has been
>   removed
>
> * The setuid wrapper functionality now supports setting capabilities.
>
> * X.org server uses branch 1.19. Due to ABI incompatibilities,
>   ati_unfree keeps forcing 1.17 and amdgpu-pro starts forcing 1.18.
>
> * Cross compilation has been rewritten. See the nixpkgs manual for
>   details. The most obvious breaking change is that in derivations there
>   is no .nativeDrv nor .crossDrv and are now cross by default, not
>   native.
>
> * The overridePackages function has been rewritten to be replaced by
>   overlays
>
> * Packages in nixpkgs can be marked as insecure through listed
>   vulnerabilities. See the Nixpkgs manual for more information.
>
> There are two open issues currently:
>  * gdm crashes on some hardware, using slim to start gnome works, see
> the github issue for more information:
>https://github.com/NixOS/nixpkgs/issues/24172
>  * Firefox e10s tabs crash, see the github issue for more information:
>https://github.com/NixOS/nixpkgs/issues/24295
>
> See release notes for more information about major changes and updates
> at http://nixos.org/nixos/manual/release-notes.html#sec-release-17.03
>
> ISO and VirtualBox images can be downloaded from:
> http://nixos.org/nixos/download.html
> (Azure BLOBs and EC2 AMIs will follow)
>
> The NixOS manual is at http://nixos.org/nixos/manual/
>
> A fresh installation can be done by following "Installation chapter" in
> the manual:
>
> http://nixos.org/nixos/manual/index.html#sec-installation
>
> Upgrading existing NixOS installations:
>
> $ nix-channel --add https://nixos.org/channels/nixos-17.03 nixos
> $ nixos-rebuild switch --upgrade
>
> Please report issues to our bug tracker:
> https://github.com/NixOS/nixpkgs/issues
>
> The most active contributors for this release were:
> 621 commits: Frederik Rietdijk
> 498 commits: Franz Pletz
> 379 commits: Vladimír Čunát
> 377 commits: Thomas Tuegel
> 324 commits: Joachim Fasting
>
> And of course the regular thank you to Eelco Dolstra for his tireless
> work on NixOS, Nix and all the projects around that. I'd like to thank
> Domen Kožar for his help on getting this release out smoothly and his
> regular work on NixOS, the security team for taking a lot of workload
> off the release manager by always making sure to keep our systems and
> packages secure and also Mayflower for allowing me to work on NixOS a
> lot in working hours.
>
> Also I'd like to start a discussion if we want to start rotating the
> release manager for every release or maybe have two release managers
> each rotating after two releases, so you always have one who has
> managed one release. Any opinions? I'm not opposed to doing it again
> but it needs quite some time I could also spend on other work.
>
> PS: Note that according to our new policy, 16.09 is still supported one
> month by our security team until the end of April.
>
> Cheers,
> Robin
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Wout Mertens]

Yes I tried to convince the ML that prelinking /nix/store is sort of
deterministic, but could not get traction. IIRC there is a decent startup
improvement.

OS X does it well, there the dyld automatically does prelinking on the fly,
storing the metadata elsewhere.

On Tue, Mar 21, 2017, 7:36 PM Vladimír Čunát  wrote:

> On 03/21/2017 06:15 PM, Bjørn Forsman wrote:
> > I wonder if it's possible to use "prelink". I think someone mentioned
> > it on the ML some years back.
>
> I suspect prelink addresses a different part of overhead that isn't
> enlarged in nixpkgs.
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] The Church of Suckless NixOS is looking for followers

[Wout Mertens]

My $0.02:

* The bikeshedding in NixOS is indeed terrible; in nixpkgs a bit less

* It is hard to abstract over systemd, it has a huge scope. Simply using
runit means also adding a bunch of other services. This impacts all of
NixOS but nothing in nixpkgs.

* Agreed that we should make github issues available in another format for
posterity. Perhaps just copy the text of merged PRs into /docs? (with some
tool)

* I think you can achieve your fork as a nixpkgs layer. Would be nice to
have some tooling around that so many things would be separate layers.

So, I wish you luck, and I hope that you implement your fork in a way that
we can all benefit and cooperate in nixpkgs.

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Move NodeJS to separate overlay repository?

[Wout Mertens]

Hi all,

now that we got these wonderful overlays as a Chrismas gift (
http://lists.science.uu.nl/pipermail/nix-dev/2016-December/022386.html), I
was wondering if we can move some things out of nixpkgs into their own
repos.

There are a few package groups that I believe are not used in NixOS core
(boot, containers, ...) and are not updated as much as they could be. Node,
Haskell, others?

Specifically, nodePackages is always out of date, and it would be nice if
there could be a repository or maybe just a local process that updates them
separately and adds a lot more builds.

Furthermore, building node packages from scratch is ok, because that's what
npm does anyway. So any caching offered by Hydra is a bonus, not a
necessity.

For example, maybe the overlay could be auto-generated every hour from npm?
And then some service fetches it to /etc/nixos/overlays/nodePackages?

Does this seem like a fair assessment? What should be done to achieve this?

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-commits] [NixOS/nixpkgs] f70405: sqlite: 3.16.2 -> 3.17.0

[Wout Mertens]

  Branch: refs/heads/staging
  Home:   https://github.com/NixOS/nixpkgs
  Commit: f704050a21ecbf950aab06e056e9044120a80835
  
https://github.com/NixOS/nixpkgs/commit/f704050a21ecbf950aab06e056e9044120a80835
  Author: mimadrid <mimad...@ucm.es>
  Date:   2017-03-04 (Sat, 04 Mar 2017)

  Changed paths:
M pkgs/development/libraries/sqlite/default.nix

  Log Message:
  ---
  sqlite: 3.16.2 -> 3.17.0


  Commit: 9ed232b73041ebf7d82ba5b1a79ea4bba6aad857
  
https://github.com/NixOS/nixpkgs/commit/9ed232b73041ebf7d82ba5b1a79ea4bba6aad857
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2017-03-04 (Sat, 04 Mar 2017)

  Changed paths:
M pkgs/development/libraries/sqlite/default.nix

  Log Message:
  ---
  Merge pull request #23480 from mimadrid/update/sqlite3-3.17.0

sqlite: 3.16.2 -> 3.17.0


Compare: https://github.com/NixOS/nixpkgs/compare/da3467003341...9ed232b73041___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] NFS performance issues after upgrade to 16.09

[Wout Mertens]

Maybe it's something else?
https://www.clearos.com/clearfoundation/social/community/solved-nfs-causing-high-load

To further troubleshoot, I'd look into NFS logging to see what is being
read/written, and snooping network traffic might be a quick way into that.
Maybe in the new versions one of the apps started doing lots of mini writes
with fsync?

Wout.

On Thu, Oct 13, 2016, 11:57 PM zimbatm  wrote:

> For the channels look into https://github.com/NixOS/nixpkgs-channels. The
> branches here map directly to the channels that you can fetch publicly. If
> you figure out which files are being used by nfs then it's a matter of
> running a diff between the different branches.
>
>
> https://github.com/NixOS/nixpkgs-channels/blob/nixos-16.09/nixos/modules/services/network-filesystems/nfsd.nix
> doesn't seem to have changed since 16.03.
> It seems to be using the nfs-utils which you can find in the
> pkgs/top-level/all-packages.nix and follow from there. nfs-utils seems to
> have changed:
> https://github.com/NixOS/nixpkgs-channels/blob/nixos-16.09/pkgs/os-specific/linux/nfs-utils/default.nix
> There is also the kernel module that you might want to dig into.
>
> I know it's not a direct solution but hopefully it will give you some more
> things to try out.
>
> Cheers,
> z
>
>
>
> On Thu, 13 Oct 2016 at 15:18 4levels <4lev...@gmail.com> wrote:
>
> Hi Jonas,
>
> disabling fail2ban didn't help, now the Nginx webserver keeps crashing as
> soon as a php error occurs.
> Do you know by any chance if with the upgrade to nixos-16.09 a newer
> version of NFS is included than in 16.03?  Maybe some default parameters in
> NFS have changed causing this havoc.
> As a more general question: how can I see which version of package x is
> used in nixos version y?
>
> Kind regards,
>
> Erik
>
> On Thu, Oct 13, 2016 at 11:05 AM 4levels <4lev...@gmail.com> wrote:
>
> Hi,
>
> thank you for your suggestions.  I've disabled the firewall and fail2ban
> services, let's hope that does the trick!
> I'll report back when things are better..
>
> Kind regards,
>
> Erik
>
> On Thu, Oct 13, 2016 at 9:09 AM zimbatm  wrote:
>
> Hi,
>
> What happens if you disable fail2ban? Maybe the behaviour has changed.
>
> Or try to change the kernel and NFS versions.
>
> I know it's not much help, all I can recommend is to try and replace each
> component to reduce the error.
>
> On Wed, 12 Oct 2016, 10:51 4levels, <4lev...@gmail.com> wrote:
>
> Dear Nix'ers,
>
> I've a permanent issue since the upgrade to nixos-16.09 in my local vm
> (with kvm-qemu from an SSD partition).  The load of the vm is increasing
> over time without any signs in the output of top.  Bash completion when
> traversing directories stalls and the whole system becomes unresponsive
> after about 5 to 10 minutes with top showing a load > 30.  Even rebooting
> fails with several services failing to stop (eg. fail2ban, phpfpm, ).
>
> This has everything to do with NFS: as soon as I disable the NFS mounts,
> the system maintains normal operation.  Nginx / phpfpm are using NFS
> mounted folders for local development.
>
> These are the filesystem declarations in the nixops expression:
>
>   fileSystems."/data/dev" = {
> device = "d01:/data/dev";
> fsType = "nfs";
> options = [ "defaults" "noatime" "nolock" "noacl" "vers=3" "udp"
> "actimeo=1" ];
>   };
>   fileSystems."/extra/Documents" = {
> device = "d01:/extra/Documents";
> fsType = "nfs";
> options = [ "defaults" "noatime" "nolock" "noacl" "vers=3" "udp"
> "actimeo=1" ];
>   };
>
> with d01 being declared in extrahosts
>
>   networking.extraHosts = "192.168.121.1 d01 d01.local";
>
> Has anyone an idea how this could be related to the upgrade to 16.09?  On
> 16.03 this all worked normally..
>
> Kind regards,
>
> Erik aka 4levels
>
> ___
> 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

[Nix-commits] [NixOS/nixpkgs] 59aa3b: nixos stage-1: factor device waiting into a functi...

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 59aa3bb5c84a8d2cfe8d27170bd826499710036e
  
https://github.com/NixOS/nixpkgs/commit/59aa3bb5c84a8d2cfe8d27170bd826499710036e
  Author: Nikolay Amiantov <a...@fmap.me>
  Date:   2016-08-08 (Mon, 08 Aug 2016)

  Changed paths:
M nixos/modules/system/boot/stage-1-init.sh

  Log Message:
  ---
  nixos stage-1: factor device waiting into a function


  Commit: 3ae468e8355494dda2e9c28b5d62d3c03bf4ce98
  
https://github.com/NixOS/nixpkgs/commit/3ae468e8355494dda2e9c28b5d62d3c03bf4ce98
  Author: Nikolay Amiantov <a...@fmap.me>
  Date:   2016-08-08 (Mon, 08 Aug 2016)

  Changed paths:
M nixos/modules/system/boot/stage-1-init.sh

  Log Message:
  ---
  nixos stage-1: move resumption below helper functions' definitions


  Commit: 986a40421a94528c55531719fb382160292c7e16
  
https://github.com/NixOS/nixpkgs/commit/986a40421a94528c55531719fb382160292c7e16
  Author: Nikolay Amiantov <a...@fmap.me>
  Date:   2016-08-08 (Mon, 08 Aug 2016)

  Changed paths:
M nixos/modules/system/boot/stage-1-init.sh

  Log Message:
  ---
  nixos stage-1: wait for devices during resumption attempt

Also a microimprovement -- use `test -n` instead of `test -e`
since we have already checked that the file exists.


  Commit: db8401f6036e0ea840c2baba299897151a2944f7
  
https://github.com/NixOS/nixpkgs/commit/db8401f6036e0ea840c2baba299897151a2944f7
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-08-08 (Mon, 08 Aug 2016)

  Changed paths:
M nixos/modules/system/boot/stage-1-init.sh

  Log Message:
  ---
  Merge pull request #17100 from abbradar/resume-delay

nixos stage-1: wait for resume devices to appear


Compare: https://github.com/NixOS/nixpkgs/compare/f8fbb6fa5ccb...db8401f6036e___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Too many open issues

[Wout Mertens]

Ok fair enough, so no auto-closing but a 6 month reminder would be good.

Anybody up for C4?

On Tue, Jul 26, 2016, 9:18 PM Vladimír Čunát  wrote:

> On 07/24/2016 01:32 PM, Matthias Beyer wrote:
> > As far as I remember, this was over a year ago and they told me
> > (again, AFAIR) they already have something like that on their list.
>
> I reported one thing or two to github, and they replied *very* promptly
> and politely, but nothing real has ever happened in the following months...
>
> BTW, I also don't thing auto-closing would really help. It seems
> unavoidable that a large distribution does have thousands of unsolved
> issues. If you compare to the number of binary builds we provide, it's
> not really that many.
>
> --Vladimir
>
>
> ___
> 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-commits] [NixOS/nixpkgs] cf3867: Fix #9759 SSMTP sendmail wrapper

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: cf3867a5efbbc36743cc7009e33c872cfe3fa232
  
https://github.com/NixOS/nixpkgs/commit/cf3867a5efbbc36743cc7009e33c872cfe3fa232
  Author: Nathan Bijnens <nat...@nathan.gs>
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M nixos/modules/programs/ssmtp.nix

  Log Message:
  ---
  Fix #9759 SSMTP sendmail wrapper


  Commit: bb528e714d677f619db732fc66795bf0f6375204
  
https://github.com/NixOS/nixpkgs/commit/bb528e714d677f619db732fc66795bf0f6375204
  Author: Nathan Bijnens <nat...@nathan.gs>
  Date:   2016-07-23 (Sat, 23 Jul 2016)

  Changed paths:
M nixos/modules/programs/ssmtp.nix

  Log Message:
  ---
  Fix #9759 SSMTP sendmail wrapper - cfg instead of full path


  Commit: 62d11a6961fdae096de947f4971d078159f7b218
  
https://github.com/NixOS/nixpkgs/commit/62d11a6961fdae096de947f4971d078159f7b218
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-07-26 (Tue, 26 Jul 2016)

  Changed paths:
M nixos/modules/programs/ssmtp.nix

  Log Message:
  ---
  Merge pull request #17206 from nathan-gs/patch-2

Fix #9759 SSMTP sendmail wrapper


Compare: https://github.com/NixOS/nixpkgs/compare/66ca9b91467c...62d11a6961fd___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] fe9cab: etc: remove obsolete directories

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: fe9cabedf0292a2b09de16e272b968b42c0ac7fe
  
https://github.com/NixOS/nixpkgs/commit/fe9cabedf0292a2b09de16e272b968b42c0ac7fe
  Author: Alexey Shmalko <rasen.d...@gmail.com>
  Date:   2016-07-25 (Mon, 25 Jul 2016)

  Changed paths:
M nixos/modules/system/etc/setup-etc.pl

  Log Message:
  ---
  etc: remove obsolete directories

This patch adds handling of a directory becoming a symlink in
/etc. Before this patch, the directory wasn't removed and then
symlinking failed, which caused directory not being updated at all.

The idea for the patch goes to @abbradar at
https://github.com/NixOS/nixpkgs/issues/16978#issuecomment-232921903:
> A heuristic idea for this -- a function `isStatic :: Path -> Bool`:
>
> * if path `/etc/foo` is a file, return True iff it's a symlink to 
> `/etc/static/foo`.
> * if path is a directory, return True iff for all items in it `isStatic` is 
> True.
>
> On any conflicts, if old path is static, it's safe to replace and/or
> delete stale. Otherwise make a backup and notify the user via a
> journal entry and console output.

The only difference here -- it will not replace user configs.

This also fixes https://github.com/NixOS/nixpkgs/issues/16978.


  Commit: 3bb18c68d2b767e53f3f9d90b310ede145315726
  
https://github.com/NixOS/nixpkgs/commit/3bb18c68d2b767e53f3f9d90b310ede145315726
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-07-26 (Tue, 26 Jul 2016)

  Changed paths:
M nixos/modules/system/etc/setup-etc.pl

  Log Message:
  ---
  Merge pull request #17042 from rasendubi/etc

etc: remove obsolete directories


Compare: https://github.com/NixOS/nixpkgs/compare/3badad811c60...3bb18c68d2b7___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Skillset labels

[Wout Mertens]

I don't know about using levels, you need to have a good knowledge of the
problem area to decide what level something is, and it can scare off people
that think they are not advanced even though they are. There is already the
good-first-bug label…

On Sat, Jul 23, 2016 at 3:16 PM Profpatsch <m...@profpatsch.de> wrote:

> On 16-07-23 09:49am, Wout Mertens wrote:
> > To better triage issues, it would be good to have labels that indicate
> the
> > skillset needed to work the issue.
>
> Not only triaging, but also finding people interested in certain topics.
> How about these labels, too?
>
> level:beginner
> level:medium
> level:advanced
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Skillset labels

[Wout Mertens]

To better triage issues, it would be good to have labels that indicate the
skillset needed to work the issue. Here's a preliminary list, what is
missing?


   - shell
   - javascript
   - python
   - haskell
   - ruby
   - erlang
   - c/c++
   - vim
   - emacs
   - build toolchain
   - darwin toolchain
   - systemd config
   - nixos core
   - non-nixos install

Yes I said non-nixos is not a skillset, but it turns out it is :) I wish
the labels had extra descriptions.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

   - *Splitting the repo*: Indeed, losing history is bad, so no go. See
   below for alternative.
   - *Triage*: Good ideas to split the load. See below.
   - *Autoclose*: Still convinced we should use it. See below.

For *triage*, we can indeed triage by section (just add labels) and then
maintainers can filter by the labels they can work on.
Right now we have 515 issues without labels
.
*Let's label them!*
We *need to make labels based on skillset* needed to fix. The topic labels
come close, but e.g. "topic: non-nixos" is not a skillset. "skill: bash"
and "skill: kernel" are. Labels are free, let's add all the ones that can
be useful for filtering.

*Splitting the repo* is not a good idea. However, some PRs are languishing
because it is unclear if they can be merged, and the persons that can make
the call are unresponsive. Using the C4 rules
, it is very *clear
when a PR can be merged*, and what needs to be done to make it mergeable.
Instead of splitting the repo, let's mark certain parts of the code as
"merge only when permission from core maintainers", and all the rest is
open for C4.

*Autoclosing* is like garbage collection. Auto-close and then reopening by
a response, is more efficient than triagers having to go in and decide if
something can be closed. We can add labels that prevent auto-close.
No warnings are needed btw, since responding reopens. A warning means two
mails instead of one.
*We should not be afraid of missing out on bugs or ideas*. They are
re-discovered all the time, and the good ones will be interesting enough to
stay open.

So, conclusion:

   1. We need to add *skillset labels*
   2. We need a *triager army* that apply labels to unlabeled issues
   3. *Maintainers use filters* to see their custom issue list
   4. Let's use C4 
   to *objectively decide mergeability*
   5. Let's run autoclose, starting with issues not updated for 6 months (205
   of them
   

   )

I'll start a different email thread soliciting for skillset labels.

On Sat, Jul 23, 2016 at 3:22 AM Profpatsch  wrote:

> On 16-07-22 09:59am, Michael Walker wrote:
> > If there are 1000+ open issues, it's hard to know what to prioritise.
> > If inactive issues get closed, it at least helps cut down on things
> > which may no longer be relevant (and if they are, someone finds the
> > closed issue, comments in it, and it opens again).
>
> I do think Github gives us the means for that.
> You can sort by activity, by age, by label, by reactions …
>
> To start triaging just sort by least recently updated
> and work from start to finish. ;)
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

Ok, how about this: We split nixpkgs in nixpkgs-core and nixpkgs-community

For any package or service, there need to be at least 3 active maintainers,
or it goes out of nixpkgs-core into a nixpkgs-community repo.

Hydra builds nixos from nixpkgs-core, and nixpkgs from both combined.

nixpgks-core issues are mostly solved by the maintainers or of course any
PR that is good enough.

In the nixpkgs-community we implement the
http://rfc.zeromq.org/spec:42/C4/ process,
meaning that any PR that fulfills all the objective goals gets merged. It
worked well for ZeroMQ, and takes the guesswork out of PRs. Tree
maintainers only need to evaluate the C4 objectives
 of the PR, and if
they are fulfilled, merge.

Packages get moved between the two repos as support status changes.

That way, we have a small "trust base" for server systems, and a large
"community base" for the latest and greatest. NixOS is so flexible that you
can mix and match as you wish.

On Fri, Jul 22, 2016 at 3:12 PM Kevin Cox  wrote:

> On 22/07/16 08:55, Alexey Shmalko wrote:
> > This one: https://www.codetriage.com/nixos/nixpkgs
> >
>
> That's it! I have subscribed to get a couple issues a day so hopefully I
> can help a bit. This site seems like a nice way to spread the load.
>
> It's open source too, and I just opened an issue asking them to
> implement filters as I'm not really interesting in seeing in-progress
> issues.
>
> https://github.com/codetriage/codetriage/issues/498
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

We could tag those issues with "mayor-unsolved-issue" and search for them
that way. Unsolvable issues are just standing in the way of solvable ones,
making it harder to keep the project up-to-date.

On Fri, Jul 22, 2016 at 11:49 AM Roger Qiu <roger@matrix.ai> wrote:

> What about things that aren't necessarily small fixable bugs. Some
> projects have long discussions about design or philosophy or some major
> architecting. Or a bug that is pending somebody coming up with a good
> solution (like for example ZFS's encryption issue which was open for
> years). Will people need to constantly comment with `+1` just to reopen?
> Also if an issue is closed it may increase the number of duplicate issues,
> instead of adding onto the closed issue.
>
> On 22/07/2016 7:37 PM, Wout Mertens wrote:
>
> That's the thing about auto-reopening, it makes sure that people
> interested in seeing the issue fixed are reminded of the issue so they can
> continue fixing it, as well as automatically weeding out the issues that
> are no longer important.
>
> All the *real* issues will stay active, since people will reopen them. All
> the rest will be available in the history.
>
> I think 14 days is enough time between reminders for an open source
> project. Shorter is annoying since we can't work on open source every day,
> and longer will just lead to more stale issues.
>
> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles <ol...@ocharles.org.uk>
> wrote:
>
>> Agreed.
>>
>> But if the problem is you think old issues are skewing the results/making
>> it hard to find the signal, then can't you just use more intelligent search
>> filters? E.g., things created in the past 3 months.
>>
>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>> eelco.dols...@logicblox.com> wrote:
>>
>>> Hi,
>>>
>>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>>
>>> > We have 1238 open issues and 286 open PRs.
>>> >
>>> > That is just too much to reason about.
>>> >
>>> > How about using something like https://github.com/twbs/no-carrier
>>> which
>>> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>>>
>>> There is something to be said for auto-closing issues after a long time
>>> (e.g.
>>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
>>> days is
>>> wy to short. Bugs don't disappear after 14 days...
>>>
>>> --
>>> 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
>>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
>
> ___
> nix-dev mailing 
> listnix-...@lists.science.uu.nlhttp://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> --
> Founder of Matrix AIhttps://matrix.ai/
> +61420925975
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

To give you an idea, there are still 109 issues that were updated in the
last 2 weeks:
https://github.com/NixOS/nixpkgs/issues?utf8=%E2%9C%93=is%3Aissue%20is%3Aopen%20%20updated%3A%3E%3D2016-07-08

This is already quite enough to work on.

On Fri, Jul 22, 2016 at 11:37 AM Wout Mertens <wout.mert...@gmail.com>
wrote:

> That's the thing about auto-reopening, it makes sure that people
> interested in seeing the issue fixed are reminded of the issue so they can
> continue fixing it, as well as automatically weeding out the issues that
> are no longer important.
>
> All the *real* issues will stay active, since people will reopen them. All
> the rest will be available in the history.
>
> I think 14 days is enough time between reminders for an open source
> project. Shorter is annoying since we can't work on open source every day,
> and longer will just lead to more stale issues.
>
> On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles <ol...@ocharles.org.uk>
> wrote:
>
>> Agreed.
>>
>> But if the problem is you think old issues are skewing the results/making
>> it hard to find the signal, then can't you just use more intelligent search
>> filters? E.g., things created in the past 3 months.
>>
>> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
>> eelco.dols...@logicblox.com> wrote:
>>
>>> Hi,
>>>
>>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>>
>>> > We have 1238 open issues and 286 open PRs.
>>> >
>>> > That is just too much to reason about.
>>> >
>>> > How about using something like https://github.com/twbs/no-carrier
>>> which
>>> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>>>
>>> There is something to be said for auto-closing issues after a long time
>>> (e.g.
>>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
>>> days is
>>> wy to short. Bugs don't disappear after 14 days...
>>>
>>> --
>>> 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
>>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Too many open issues

[Wout Mertens]

That's the thing about auto-reopening, it makes sure that people interested
in seeing the issue fixed are reminded of the issue so they can continue
fixing it, as well as automatically weeding out the issues that are no
longer important.

All the *real* issues will stay active, since people will reopen them. All
the rest will be available in the history.

I think 14 days is enough time between reminders for an open source
project. Shorter is annoying since we can't work on open source every day,
and longer will just lead to more stale issues.

On Fri, Jul 22, 2016 at 11:17 AM Oliver Charles <ol...@ocharles.org.uk>
wrote:

> Agreed.
>
> But if the problem is you think old issues are skewing the results/making
> it hard to find the signal, then can't you just use more intelligent search
> filters? E.g., things created in the past 3 months.
>
> On Fri, Jul 22, 2016 at 10:15 AM Eelco Dolstra <
> eelco.dols...@logicblox.com> wrote:
>
>> Hi,
>>
>> On 07/22/2016 09:06 AM, Wout Mertens wrote:
>>
>> > We have 1238 open issues and 286 open PRs.
>> >
>> > That is just too much to reason about.
>> >
>> > How about using something like https://github.com/twbs/no-carrier which
>> > auto-closes after 14 days of inactivity, and reopens on a new comment?
>>
>> There is something to be said for auto-closing issues after a long time
>> (e.g.
>> Fedora auto-closes inactive issues from CURRENT-2 releases ago), but 14
>> days is
>> wy to short. Bugs don't disappear after 14 days...
>>
>> --
>> 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
>>
> ___
> 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-commits] [NixOS/nixpkgs] 39cf21: nodejs-6_x: 6.2.2 -> 6.3.1

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 39cf213e2bd4487dbc776c620877e79bde9e62c2
  
https://github.com/NixOS/nixpkgs/commit/39cf213e2bd4487dbc776c620877e79bde9e62c2
  Author: Tobias Pflug <tobias.pf...@holidaycheck.com>
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/web/nodejs/nodejs.nix
M pkgs/development/web/nodejs/v6.nix

  Log Message:
  ---
  nodejs-6_x: 6.2.2 -> 6.3.1


  Commit: 434f9d158bbf3629a653b7d05abef450ea5273d5
  
https://github.com/NixOS/nixpkgs/commit/434f9d158bbf3629a653b7d05abef450ea5273d5
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-07-22 (Fri, 22 Jul 2016)

  Changed paths:
M pkgs/development/web/nodejs/nodejs.nix
M pkgs/development/web/nodejs/v6.nix

  Log Message:
  ---
  Merge pull request #17169 from holidaycheck/nodejs-6.3.1

nodejs-6_x: 6.2.2 -> 6.3.1


Compare: https://github.com/NixOS/nixpkgs/compare/390b49a3e771...434f9d158bbf___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-dev] Too many open issues

[Wout Mertens]

We have 1238 open issues and 286 open PRs.

That is just too much to reason about.

How about using something like https://github.com/twbs/no-carrier which
auto-closes after 14 days of inactivity, and reopens on a new comment?

I'm sure that if we have close to 0 open issues/PRs, there will be a
greater incentive to bring that number to 0…
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs

[Wout Mertens]

How about: name this new one npm2nix_2 and make it the default. If you want
the old one, instal npm2nix_1.

On Thu, Jul 14, 2016 at 1:19 PM Tomasz Czyż <tomasz.c...@gmail.com> wrote:

> 2016-07-13 22:13 GMT+01:00 Wout Mertens <wout.mert...@gmail.com>:
>
>> Great!
>>
>> I tried npm2nix a few times and never really got it to work. I can't
>> imagine that there are a lot of people that use npm2nix that would not be
>> able to switch to your new version if it got added as npm2nix.
>>
> I'm just trying to show similar situation:
> "I don't know if anyone is using gnome, but let's remove it because I
> think it's difficult to use and nobody is using it" :-)
>
> I think there were some cases similar to this one before and what was
> suggested to check if the binary cache is used (if people are downloading
> the package) or other way to check if package is being used.
>
>
>> Having multiple solutions for the same thing is a frustrating experience
>> for people that want to start using nix for npm. I would prefer simply
>> replacing npm2nix.
>>
> Are you sure that having multiple tools/solutions is frustrating? Maybe
> it's just lack of description or documentation?
> (btw, currently there is only one, Sander is trying to introduce second
> "official" one if I understand situation correctly).
>
> Sander, maybe you could add a manual change to your PR to explain this
> situation/move and how the tools can be used?
>
>
>
>> On Tue, Jul 12, 2016 at 3:00 PM Sander van der Burg <
>> svanderb...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I just created a pull request for the release-16.03 branch integrating
>>> my node2nix generated package set:
>>> https://github.com/NixOS/nixpkgs/pull/16886
>>>
>>> I'm looking for feedback as I haven't extensively tested everything. My
>>> stuff seems to work properly, though. If we find the results satisfactory,
>>> I will implement the same kinds of changes for the master branch as well.
>>>
>>> Best,
>>>
>>> Sander
>>>
>>>
>>> On Mon, Jul 11, 2016 at 10:36 AM, Nikolay Amiantov <a...@fmap.me> wrote:
>>>
>>>> One possible way is to add some attribute in current nixpkgs indicating
>>>> version of checksumming scheme, e.g. `fetchgit.checksumVersion`.
>>>> However, this implies that you would run something like
>>>> `nix-instantiate` to determine it, and so you need access to the nixpkgs
>>>> tree -- IIRC you don't have such requirements now, and adding whole
>>>> complexity for just getting this version seems unreasonable.
>>>>
>>>> What about pushing different versions of your utility to release and
>>>> master branches? I feel this could cover most usecases...
>>>>
>>>> On 07/11/2016 01:26 PM, Sander van der Burg wrote:
>>>> > Thanks for the reference. Actually, the change in Nixpkgs makes sense,
>>>> > as I never understood why any file with a .git prefix had to be
>>>> removed.
>>>> > Similarly, I replicated this odd behaviour in npm2nix.
>>>> >
>>>> > I have managed to implement a fix for this locally (which I haven't
>>>> > pushed yet). The only annoying thing is that the 16.03 stable release
>>>> > still uses the old git hash computation method, so I need to keep the
>>>> > old method intact.
>>>> >
>>>> > I'm still a bit puzzled on how to proceed -- I could decide to release
>>>> > my npm2nix version and use the hash computation method that works with
>>>> > 16.03 since that's the stable version and what end-users should use.
>>>> > Then for the master branch, people should switch to the development
>>>> > version of npm2nix that implements the new strategy. The only thing
>>>> I'm
>>>> > afraid of is that people forget about this and push broken versions of
>>>> > the Node.js packages to master.
>>>> >
>>>> > Alternatively, I could make both strategies configurable through a
>>>> > command-line parameter, but this is not very nice either. And still,
>>>> > end-users might forget about it and break the package set.
>>>>
>>>> --
>>>> Nikolay.
>>>>
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> Tomasz Czyż
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] On npm2nix and the NPM package set in Nixpkgs

[Wout Mertens]

Great!

I tried npm2nix a few times and never really got it to work. I can't
imagine that there are a lot of people that use npm2nix that would not be
able to switch to your new version if it got added as npm2nix.

Having multiple solutions for the same thing is a frustrating experience
for people that want to start using nix for npm. I would prefer simply
replacing npm2nix.

On Tue, Jul 12, 2016 at 3:00 PM Sander van der Burg 
wrote:

> Hi,
>
> I just created a pull request for the release-16.03 branch integrating my
> node2nix generated package set:
> https://github.com/NixOS/nixpkgs/pull/16886
>
> I'm looking for feedback as I haven't extensively tested everything. My
> stuff seems to work properly, though. If we find the results satisfactory,
> I will implement the same kinds of changes for the master branch as well.
>
> Best,
>
> Sander
>
>
> On Mon, Jul 11, 2016 at 10:36 AM, Nikolay Amiantov  wrote:
>
>> One possible way is to add some attribute in current nixpkgs indicating
>> version of checksumming scheme, e.g. `fetchgit.checksumVersion`.
>> However, this implies that you would run something like
>> `nix-instantiate` to determine it, and so you need access to the nixpkgs
>> tree -- IIRC you don't have such requirements now, and adding whole
>> complexity for just getting this version seems unreasonable.
>>
>> What about pushing different versions of your utility to release and
>> master branches? I feel this could cover most usecases...
>>
>> On 07/11/2016 01:26 PM, Sander van der Burg wrote:
>> > Thanks for the reference. Actually, the change in Nixpkgs makes sense,
>> > as I never understood why any file with a .git prefix had to be removed.
>> > Similarly, I replicated this odd behaviour in npm2nix.
>> >
>> > I have managed to implement a fix for this locally (which I haven't
>> > pushed yet). The only annoying thing is that the 16.03 stable release
>> > still uses the old git hash computation method, so I need to keep the
>> > old method intact.
>> >
>> > I'm still a bit puzzled on how to proceed -- I could decide to release
>> > my npm2nix version and use the hash computation method that works with
>> > 16.03 since that's the stable version and what end-users should use.
>> > Then for the master branch, people should switch to the development
>> > version of npm2nix that implements the new strategy. The only thing I'm
>> > afraid of is that people forget about this and push broken versions of
>> > the Node.js packages to master.
>> >
>> > Alternatively, I could make both strategies configurable through a
>> > command-line parameter, but this is not very nice either. And still,
>> > end-users might forget about it and break the package set.
>>
>> --
>> Nikolay.
>>
>
> ___
> 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-commits] [NixOS/nixpkgs] c07183: handbrake: depend on hicolor_icon_theme

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: c071831b8b8685bbd395eeba86d0040360d2473d
  
https://github.com/NixOS/nixpkgs/commit/c071831b8b8685bbd395eeba86d0040360d2473d
  Author: Robert Helgesson <rob...@rycee.net>
  Date:   2016-07-09 (Sat, 09 Jul 2016)

  Changed paths:
M pkgs/applications/video/handbrake/default.nix

  Log Message:
  ---
  handbrake: depend on hicolor_icon_theme

This avoids conflicts on `share/icons/hicolor/icon-theme.cache`.


  Commit: 5bf4fd7a63bb0ec0ef8036a6880c3a310f7a5a3e
  
https://github.com/NixOS/nixpkgs/commit/5bf4fd7a63bb0ec0ef8036a6880c3a310f7a5a3e
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-07-09 (Sat, 09 Jul 2016)

  Changed paths:
M pkgs/applications/video/handbrake/default.nix

  Log Message:
  ---
  Merge pull request #16810 from rycee/fix/handbrake

handbrake: depend on hicolor_icon_theme


Compare: https://github.com/NixOS/nixpkgs/compare/9f4775dbb509...5bf4fd7a63bb___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] 36c7c5: services.dbus module: more complete docstring

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 36c7c50512aa9af1284dfd93876fe2568801dfe3
  
https://github.com/NixOS/nixpkgs/commit/36c7c50512aa9af1284dfd93876fe2568801dfe3
  Author: Philip Potter <philip.g.pot...@gmail.com>
  Date:   2016-06-28 (Tue, 28 Jun 2016)

  Changed paths:
M nixos/modules/services/system/dbus.nix

  Log Message:
  ---
  services.dbus module: more complete docstring

The docstring for the `services.dbus.packages` configuration option only
mentioned one directory, but the implementation actually looked for DBus
config files in four separate places within the target packages.  This
commit updates the docstring to reflect the actual implementation
behaviour.


  Commit: 69df7b63ff6b20390fa177df6ed6357f192e34eb
  
https://github.com/NixOS/nixpkgs/commit/69df7b63ff6b20390fa177df6ed6357f192e34eb
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-06-28 (Tue, 28 Jun 2016)

  Changed paths:
M nixos/modules/services/system/dbus.nix

  Log Message:
  ---
  Merge pull request #16405 from 
philandstuff/better-dbus-services-packages-docstring

services.dbus module: more complete docstring


Compare: https://github.com/NixOS/nixpkgs/compare/de6977ffe3f9...69df7b63ff6b___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

[Nix-commits] [NixOS/nixpkgs] a221ff: makeself: header wasn't being patched correctly

[Wout Mertens]

  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a221ff5569cea8b0f8e7a9f7222ccc760034074e
  
https://github.com/NixOS/nixpkgs/commit/a221ff5569cea8b0f8e7a9f7222ccc760034074e
  Author: Matthew Bauer <mjbaue...@gmai.com>
  Date:   2016-06-14 (Tue, 14 Jun 2016)

  Changed paths:
M pkgs/applications/misc/makeself/default.nix

  Log Message:
  ---
  makeself: header wasn't being patched correctly


  Commit: 3bbdfe5df7693b01b35365a0796bb4e29f425167
  
https://github.com/NixOS/nixpkgs/commit/3bbdfe5df7693b01b35365a0796bb4e29f425167
  Author: Wout Mertens <wout.mert...@gmail.com>
  Date:   2016-06-15 (Wed, 15 Jun 2016)

  Changed paths:
M pkgs/applications/misc/makeself/default.nix

  Log Message:
  ---
  Merge pull request #16232 from matthewbauer/makeself-fix-header

makeself: header wasn't being patched correctly


Compare: https://github.com/NixOS/nixpkgs/compare/48de566e545c...3bbdfe5df769___
nix-commits mailing list
nix-comm...@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Re: [Nix-dev] Proposed feature for make-wrapper.sh

[Wout Mertens]

--suffix-flags sounds ok, but perhaps a custom wrapper is better.

On Sun, May 8, 2016, 11:02 AM Philip Carlsen  wrote:

> That's great to hear - Indeed you're not the only one having trouble with
> akonadi. I just gave up before I could make anything useful of it.
> Den 8. maj 2016 01.24 skrev "Phil Wetzel" :
>
>> Greetings,
>>
>> I've just installed NixOS on my desktop with KDE. I had trouble getting
>> akonadi working (the data backend for kdepim). I found one other person
>> with
>> the same problem [1], though it is hard for me to believe I am the only
>> person
>> trying to run KMail on NixOS.
>>
>> The problem turned out to be akonadi starting an instance of mysqld
>> (mariadb)
>> that failed to find an error messages file because it didn't know where
>> it was.
>> Setting the --basedir prevents this problem from occurring, and that is
>> what
>> is done in the service module definition. kdepim users can solve the
>> problem
>> locally by setting basedir in their akonadi/mysql.cf config, but if we
>> would
>> like it to work out of the box it seemed to me that the way forward was
>> to use
>> wrapProgram on mysqld. You can't actually run mysqld from the commandline
>> without without the --basedir argument with it packaged the way it is now
>> anyway.
>>
>> This turned out to not work either because:
>>
>>  - wrapProgram --add-flags *prepends* all the wrapped flags to the
>> argument list
>>  - akonadi uses the --defaults-file argument
>>  - mysqld requires --defaults-file to be the first argument if it is used
>>
>> This can certainly be solved with some hackery after the wrapProgram in
>> postInstall, but perhaps it would be better to include a --suffix-flags
>> feature
>> to make-wrapper.sh.
>>
>> What would you suggest as the better choice? I didn't want to submit a PR
>> with
>> a hack if that wasn't the way forward, and I definitely didn't want to
>> submit a
>> PR touching the build tools and documentation without at least saying
>> hello
>> first.
>>
>> Thank you,
>> Phil Wetzel
>>
>> [1] -
>> http://lists.science.uu.nl/pipermail/nix-dev/2015-January/015575.html
>> ___
>> 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Why not use SONAME instead of RPATH

[Wout Mertens]

Woah I love that! +1, I don't see why we can't do that…

Wout.

On Wed, Apr 20, 2016 at 1:52 PM Silvio Frischknecht  wrote:

> Hello,
>
> I recently found out that if you set the SONAME of a library to an
> absolute path.
>
> gcc --shared -Wl,-soname="$(pwd)/libxyz.so" -o libxyz.so  libxyz.c
>
> and then later link to it
>
> gcc main.c -L. -lxyz
>
> the dynamic linker will only look for the library in the exact path
> specified when compiling the library.
>
> Advantages over RPATH:
> + probably faster since rpaths in nixos tend to be quite long and every
> library has to be looked for in every folder (linear vs quadratic
> complexity)
> + only has to be setup once per library - all referrers will
> automatically work correctly
>
> In this case the path can't be overwritten by LD_LIBRARY_PATH. I guess
> that could be an advantage or a disadvantage depending on how you look
> at it.
>
> Cheers
>
> Silvio
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Upgrade from 15.09 to 16.03 with NixOps

[Wout Mertens]

The expressions are evaluated from the coordinator, so either you upgrade
the channel there or you check out nixpkgs somewhere and set
`NIX_PATH=nixpkgs=/path/to/your/clone` before running nixops.

On Wed, Apr 20, 2016 at 1:52 PM Teo Klestrup  wrote:

> I believe the channels are taken from the coordinator, so when the
> coordinator is upgraded then the other machines should be, too.
> On 18 Apr 2016 19:20, "4levels" <4lev...@gmail.com> wrote:
>
>> Hi Nix'ers,
>>
>> This is an Nix Ops related question.
>>
>> How can I specify which channel to use inside the nix expressions (*.nix
>> files) for nixops?
>>
>> Thanks in advance!
>>
>> Erik
>>
>> ___
>> 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Nix-like npm replacement (NodeJS)

[Wout Mertens]

I thought this would be interesting for some people on this list:

http://gugel.io/ied/ :

Under the hood, ied maintains an "object database", similar to git. Instead
of storing packages by some arbitrary name, a SHA1-checksum is being
generated to approximate their contents. The checksums can not only be used
for guaranteeing a certain level of trust and consistency, but they also
simplify the algorithm through which dependencies are being managed.

The algorithm through which packages are being installed guarantees
consistency through atomic installs. The installation of a package either
fails or succeeds, but at no point in time can a dependency itself be
required without having its own sub-dependencies installed (with the
exception of shared circular dependencies).

The checksum of a package is based on the contents of the package itself,
not of its sub-dependencies. Therefore the validity of a package can be
verified by hashing the package itself. Subsequent dependency updates have
no effect of the generated checksum.

Since node_modules is essentially a file-system based content addressable
storage, multiple versions of the same package can co-exist in the same
project.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Minimal disk image without gcc?

[Wout Mertens]

BTW, that reminds me of https://github.com/NixOS/nixpkgs/issues/12898

On Tue, Apr 19, 2016 at 12:50 PM Wout Mertens <wout.mert...@gmail.com>
wrote:

> Thanks, that really helps!
>
> On Tue, Apr 19, 2016 at 12:21 PM Layus <layus...@gmail.com> wrote:
>
>> On 19/04/16 11:52, Wout Mertens wrote:
>> > Hi,
>> >
>> > I would like to make a specialized image that just runs some tools and
>> > has nothing else installed.
>> >
>> > If I uset the minimal profile it has stdenv, which includes 100MB of
>> gcc.
>> >
>> > Pointers?
>> I am also working on this. From my investigations, the closure-size
>> feature has everything required to get rid of gcc.out (and keep gcc.lib
>> if required).
>> However, many packages are not correctly stripped or somehow maintain a
>> reference to build inputs like gcc.
>>
>> To benefit from this feature, you need to build from master.
>> If your closure still includes some gcc-X.Y.Z (gcc-X.Y.Z-lib is ok),
>> here are some hints to track the misbehaving package.
>>
>>
>> You need to find package depending on gcc, then find why they have
>> runtime dependencies on their compiler.
>>
>> $ nix-store -qR ./result | grep gcc
>> /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3 <- you want to get
>> rid of this one.
>> ...
>>
>> $ blame () {comm -12 <(nix-store -qR "$1" | sort) <(nix-store -q
>> --referrers "$2" | sort); }
>> $ blame ./result /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/
>> ... # (All these packages have runtime dependencies on gcc binaries.)
>>
>> Now you can try to investigate why they do depend on the full gcc.
>> It is probably an unstripped binary, or a wrong rpath.
>> Sometimes, the package keeps track of its buld flags, as mongo does for
>> its --version info.
>>
>> $ grep /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3 -r
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3 -al
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdhtml
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdc
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdpo
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdmerge
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdi
>>
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/lib/cups/daemon/cups-driverd
>>
>> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/lib/libcupsppdc.so.1
>>
>> Now you can simply fix the derivations of these packages and get rif of
>> gcc.
>>
>> Layus.
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
> --
>
> Wout.
> (typed on mobile, excuse terseness)
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Minimal disk image without gcc?

[Wout Mertens]

Thanks, that really helps!

On Tue, Apr 19, 2016 at 12:21 PM Layus <layus...@gmail.com> wrote:

> On 19/04/16 11:52, Wout Mertens wrote:
> > Hi,
> >
> > I would like to make a specialized image that just runs some tools and
> > has nothing else installed.
> >
> > If I uset the minimal profile it has stdenv, which includes 100MB of gcc.
> >
> > Pointers?
> I am also working on this. From my investigations, the closure-size
> feature has everything required to get rid of gcc.out (and keep gcc.lib
> if required).
> However, many packages are not correctly stripped or somehow maintain a
> reference to build inputs like gcc.
>
> To benefit from this feature, you need to build from master.
> If your closure still includes some gcc-X.Y.Z (gcc-X.Y.Z-lib is ok),
> here are some hints to track the misbehaving package.
>
>
> You need to find package depending on gcc, then find why they have
> runtime dependencies on their compiler.
>
> $ nix-store -qR ./result | grep gcc
> /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3 <- you want to get
> rid of this one.
> ...
>
> $ blame () {comm -12 <(nix-store -qR "$1" | sort) <(nix-store -q
> --referrers "$2" | sort); }
> $ blame ./result /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/
> ... # (All these packages have runtime dependencies on gcc binaries.)
>
> Now you can try to investigate why they do depend on the full gcc.
> It is probably an unstripped binary, or a wrong rpath.
> Sometimes, the package keeps track of its buld flags, as mongo does for
> its --version info.
>
> $ grep /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3 -r
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3 -al
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdhtml
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdc
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdpo
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdmerge
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdi
>
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/lib/cups/daemon/cups-driverd
> /nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/lib/libcupsppdc.so.1
>
> Now you can simply fix the derivations of these packages and get rif of
> gcc.
>
> Layus.
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Why won't this get merged?

[Wout Mertens]

Nix on other systems has problems, and https://github.com/NixOS/nix/pull/452
is an attempt to solve some of those.

However, it has been sittin in PR limbo for over a year. Is Eelco not
aware, or too busy? Anything I can do to help?

To me, Nix on other OSes is a "gateway drug" to NixOS, so I don't
understand why we don't make it as smooth as possible.

Wout.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Open source team messaging: mattermost

[Wout Mertens]

That one requires action on the part of the user, unlike the newfangled
group chat tools, but ok.

On Tue, Mar 8, 2016 at 3:16 PM Herwig Hochleitner <hhochleit...@gmail.com>
wrote:

> 2016-03-08 15:11 GMT+01:00 Wout Mertens <wout.mert...@gmail.com>:
>
>> ok, then how about at the very least an IRC bot that sends you a recent
>> history when you connect, and that lets you search the logs?
>>
>> I presume such a bot must exist?
>>
>
> https://botbot.me/freenode/nixos/
>
> --

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Fwd: [nixpkgs] libreoffice spellcheck gb uk (#13046)

[Wout Mertens]

Anybody have an idea why libreoffice might not find dictionaries on
non-nixos installs?

-- Forwarded message -
From: tomjridge <notificati...@github.com>
Date: Tue, Mar 8, 2016 at 12:22 PM
Subject: Re: [nixpkgs] libreoffice spellcheck gb uk (#13046)
To: NixOS/nixpkgs <nixp...@noreply.github.com>
Cc: Wout Mertens <wout.mert...@gmail.com>


nix-env -qa '*' |grep myspell
myspell-dict-he-1.1
myspell-dict-he-1.1

I don't know hebrew :(

On ubuntu, installing libreoffice and myspell-en-gb and possibly
libreoffice-l10n-uk worked.

Removing libreoffice and installing nix libreoffice, spell check also
worked (presumably picking up myspell from ubuntu).

HTH

—
Reply to this email directly or view it on GitHub
<https://github.com/NixOS/nixpkgs/issues/13046#issuecomment-193735888>.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Open source team messaging: mattermost

[Wout Mertens]

ok, then how about at the very least an IRC bot that sends you a recent
history when you connect, and that lets you search the logs?

I presume such a bot must exist?

Wout.

On Tue, Mar 8, 2016 at 1:32 PM Jonn Mostovoy <j...@memorici.de> wrote:

> Dear Wout,
>
> you can't grep discord. Search there is atrocious.
> Slack, on the other hand has an amazing full text search engine, which is
> a huge part in its success.
> However, as search over slack has some heuristics, when I need plain dumb
> (or pretty elaborate) grep, I can't run it over history of Slack.
>
> Picking the tool is about engineering tradeoffs. Right now, IRC is optimal
> given optimization parameters, starting from not sharding the community,
> going through network resilience and system's fault tolerance, ending with
> the degree of democracy IRC provides.
> On Mar 8, 2016 7:30 AM, "Wout Mertens" <wout.mert...@gmail.com> wrote:
>
>> After having used Slack and Discord for a while, I can tell you that
>> having the recent chat log available with a quick scroll up is very handy.
>> Conversations can continue over a longer period of time.
>>
>> With IRC, you have to open your client, fire off your question a few
>> times and hope that someone will know the answer eventually. I can't have
>> IRC open at work all day.
>>
>>
>> On Fri, Mar 4, 2016 at 12:55 AM Profpatsch <m...@profpatsch.de> wrote:
>>
>>> On 16-03-01 11:46pm, Teo Klestrup Röijezon wrote:
>>> > Plain IRC sucks.
>>>
>>> It’s true, but it f* works.
>>>
>>> Especially for developers, devs who can’t configure an IRC client?
>>> Are those people devs?
>>>
>>> But I know the pain.
>>>
>>> Hm, we even use IRC as main communication tool in our Hackerspace,
>>> and so far even non-tech people managed to get a basic setup running.
>>> Maybe no bouncer, but that’s not required strictly speaking.
>>>
>>> --
>>> Proudly written in Mutt with Vim on NixOS.
>>> Q: Why is this email five sentences or less?
>>> A: http://five.sentenc.es
>>> May take up to five days to read your message. If it’s urgent, call me.
>>>
>> --
>>
>> Wout.
>> (typed on mobile, excuse terseness)
>>
>> ___
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>> --

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] yet another npm2nix reengineering attempt

[Wout Mertens]

Great job Sander!

Some thoughts:

   - Node 5 layout is Node 4 compatible, so why not use only that?
   - You can symlink the first level of modules instead of the modules
   themselves to avoid the commonjs derefence thing. So a combination of
   modules becomes a shallow copy.
   - npm2nix doesn't have to support cycles and conflicting versions.
   Having a local node_modules in the project for those pathological cases is
   always an option. Better to only support clean and sane dependency graphs.
   - npm2nix doesn't have to generate the same output as npm. It just needs
   to generate something that matches the package.json declarations when
   loaded into Node…

I think that if you limit what npm2nix does, it will be a lot easier to
handle…

Wout.

On Tue, Mar 1, 2016 at 3:12 PM Sander van der Burg 
wrote:

> It's stateful because the packages that end up in a dependency's
> node_modules/ folder depend on the packages that have been stored in any of
> the includer's (parent directory's) node_modules/ folders. When a
> dependency has been encountered a second time (that fits within a package's
> version range), NPM will not include it again.
>
> For example: if a package would declare a dependency (such as: "optparse":
> ">= 1.0.3") and any of the parent node_modules/ folders would provide
> version 1.0.5, then optparse/ will not be deployed again in the package's
> private node_modules/ folder. Instead, it will be left out and the package
> binds to the version of the parent.
>
> Second, with npm 3.x's flat module installations, we must move packages as
> high as possible in the nested node_modules/ hierarchy, until a conflict
> has been encountered.
>
> On Tue, Mar 1, 2016 at 1:53 PM, Shea Levy  wrote:
>
>> "including NPM dependencies is stateful" how so? Having separate
>> derivations symlinked in would give you sharing, no?
>>
>> On 2016-03-01 08:15, Sander van der Burg wrote:
>> > Hi,
>> >
>> > I don't know how many of you have noticed my latest blog post
>> >
>> > (
>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>> > [1]), but I did yet another reengineering attempt for npm2nix. Its
>> > main objective is to also support npm 3.x's flat module installations
>> > (npm 3.x comes with Node.js 5.x).
>> >
>> > In the second reengineered version, I compute the entire dependency
>> > graph ahead of time and build the entire set of dependencies in one
>> > derivation -- there is no good reason to make them individual Nix
>> > packages, because including NPM dependencies is stateful.
>> >
>> > The new reengineered version supports both Node.js 4.x and 5.x. By
>> > default, it generates expressions for 4.x (I made this the default,
>> > since 4.x is the LTS release):
>> >
>> > $ npm2nix
>> >
>> > Adding the -5 parameter causes it to generate expressions for Node.js
>> > 5.x:
>> >
>> > $ npm2nix -5
>> >
>> > The code lives in the same repository as the old reengineering
>> > version, but in a different branch:
>> >
>> > https://github.com/svanderburg/npm2nix/tree/reengineering2 [2]
>> >
>> > There is a README.md file that describes how to use it and
>> > demonstrates a few common use cases.
>> >
>> > The flat module installation works for many of my packages but it is
>> > still not 100% perfect. My blog post describes some of its
>> > limitations.
>> >
>> > Anyway, I'm announcing this new version so that I can gather
>> > feedback. Maybe this new implementation is not what people are
>> > actually looking for, but I'm eating my own dogfood with it now and
>> > for all my own projects it works fine.
>> >
>> > Regards,
>> >
>> > Sander
>> >
>> >
>> >
>> > Links:
>> > --
>> > [1]
>> >
>> >
>> http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html
>> > [2] https://github.com/svanderburg/npm2nix/tree/reengineering2
>> >
>> > ___
>> > 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Open source team messaging: mattermost

[Wout Mertens]

After having used Slack and Discord for a while, I can tell you that having
the recent chat log available with a quick scroll up is very handy.
Conversations can continue over a longer period of time.

With IRC, you have to open your client, fire off your question a few times
and hope that someone will know the answer eventually. I can't have IRC
open at work all day.


On Fri, Mar 4, 2016 at 12:55 AM Profpatsch  wrote:

> On 16-03-01 11:46pm, Teo Klestrup Röijezon wrote:
> > Plain IRC sucks.
>
> It’s true, but it f* works.
>
> Especially for developers, devs who can’t configure an IRC client?
> Are those people devs?
>
> But I know the pain.
>
> Hm, we even use IRC as main communication tool in our Hackerspace,
> and so far even non-tech people managed to get a basic setup running.
> Maybe no bouncer, but that’s not required strictly speaking.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Travis Testing Needs Rethinking

[Wout Mertens]

Help on https://github.com/madjar/nox/issues/38 is appreciated methinks :-)

On Wed, Mar 2, 2016, 2:46 AM Herwig Hochleitner 
wrote:

> 2016-02-14 19:44 GMT+01:00 zimbatm :
>
>> What if master was always the latest successful hydra build ? People
>> could rebase on top and have cached builds. Nox could also have cached
>> builds.
>>
>
> +1 for having Travis build against the latest successful hydra build.
> Don't care whether that's channels/nixos-unstable or a repurposed master.
>
> This way, most packages timing out on travis, would be those that trigger
> mass-rebuilds, which need to go to staging anyway. It should make the flag
> much more useful.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Open source team messaging: mattermost

[Wout Mertens]

Check it out: http://www.mattermost.org/

Any chance of using that instead of/in addition to IRC?

Wout.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] codetriage.com

[Wout Mertens]

Now if we could run a query for that… :-)

On Sat, Feb 20, 2016, 10:26 AM Michael Raskin <7c6f4...@mail.ru> wrote:

> >Same for PRs, we have some really old ones. What is a good cutoff? 6
> months?
>
> I would start with «6 months without any updates except non-submitter
> pings and the submitter now has commit rights»
>
>
>
> --

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] codetriage.com

[Wout Mertens]

Same for PRs, we have some really old ones. What is a good cutoff? 6 months?

On Thu, Feb 18, 2016, 7:50 PM Profpatsch  wrote:

> On 16-02-17 08:18pm, Rok Garbas wrote:
> > I would suggest closing tickets that you think are not crucial or
> > reporter does not provide code that we can include. Ofcourse be nice
> > in comment and ask reported to reopen if they think you are wrong to
> > do this.
> >
> > What you say, could this work and get us less open tickets?
>
> Maybe include a timeout for „needs more info“ comments of a week
> and then close them. They can always be opened again.
>
> --
> Proudly written in Mutt with Vim on NixOS.
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
> May take up to five days to read your message. If it’s urgent, call me.
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Building v8 on Darwin

[Wout Mertens]

@copumpkin?

Is there anybody able to build v8 on Darwin (apart from the fact that you
need to turn on allowBroken because its platforms are set to linux)?

I'm getting


...

  ACTION Generating icuuc shim headers.
/private/var/folders/g4/76q469c16sg48h2xcl17lm90gn/T/nix-build-v8-3.30.33.16.drv-0/v8-3.30.33.16/out/Release/obj/gen/shim_headers/icuuc/target/third_party/icu/source/common/unicode/appendable.h

  LIBTOOL-STATIC
/private/var/folders/g4/76q469c16sg48h2xcl17lm90gn/T/nix-build-v8-3.30.33.16.drv-0/v8-3.30.33.16/out/Release/libv8_libplatform.a

Traceback (most recent call last):

  File "./gyp-mac-tool", line 511, in 

sys.exit(main(sys.argv[1:]))

  File "./gyp-mac-tool", line 28, in main

exit_code = executor.Dispatch(args)

  File "./gyp-mac-tool", line 43, in Dispatch

return getattr(self, method)(*args[1:])

  File "./gyp-mac-tool", line 223, in ExecFilterLibtool

libtoolout = subprocess.Popen(cmd_list, stderr=subprocess.PIPE)

  File
"/nix/store/6znjvqz144m4077w6qvnj1gl7hglpa5k-python-2.7.11/lib/python2.7/subprocess.py",
line 710, in __init__

errread, errwrite)

  File
"/nix/store/6znjvqz144m4077w6qvnj1gl7hglpa5k-python-2.7.11/lib/python2.7/subprocess.py",
line 1335, in _execute_child

raise child_exception

OSError: [Errno 2] No such file or directory

tools/gyp/v8_libplatform.target.mk:209: recipe for target
'/private/var/folders/g4/76q469c16sg48h2xcl17lm90gn/T/nix-build-v8-3.30.33.16.drv-0/v8-3.30.33.16/out/Release/libv8_libplatform.a'
failed

make: ***
[/private/var/folders/g4/76q469c16sg48h2xcl17lm90gn/T/nix-build-v8-3.30.33.16.drv-0/v8-3.30.33.16/out/Release/libv8_libplatform.a]
Error 1



So it seems that gyp is trying to run something that doesn't exist to do
the LIBTOOL-STATIC action.

And when rethinkdb tries to build it as part of its private build, it fails
due to the gcc libtools not supporting -static.

Thoughts?


Wout.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Installing /nix on nfs-mounted volume possible?

[Wout Mertens]

The problem with nfs nix stores is that the metadata is stored in sqlite,
which can't guarantee proper locking on nfs. However, if you only write
from one host, there is no problem.

As for the python stuff, you can run it in a proot, or use nixos which
doesn't have /usr :-)

On Mon, Feb 8, 2016, 6:37 PM Ben Booth  wrote:

> Hi all,
>
> I would like to use nix to install software and run in on a variety of
> linux machines at my work. I tried installing nix to my NFS-mounted home
> folder as outlined here[1], but I had trouble with both proot[2] and
> nix-user-chroot[3], since they both mess up some permissions and break
> sudo. I should also mention that I really don't want to build packages from
> source if I can avoid it.
>
> The next thing I tried was installing nix to an automounted NFS volume
> mounted at /nix. This seems to work great so far, but now my nix store is
> visible to all users. I don't really mind this, if other users want to run
> my software that's fine. But I've read that for multi-user installations, I
> need to designate a build user and do some other steps for building
> software from source. I haven't tried that yet since I've just been
> downloading packages from the binary cache. Is this something I need to
> worry about?
>
> I've also heard that installing nix on NFS-mounted volumes can cause
> corruption of the nix store because of locking issues. Is this still an
> issue for modern NFSv4 implementations? Our NFS server is running Centos 7
> with a 3.10.0 kernel. Is there some other way to accomplish what I'm trying
> to do that doesn't have these issues?
>
>
> One last question: I installed python into my nix store and would like to
> install some PyPI packages using pip. How can I make sure that, for
> compiled python packages that reference native libraries, that they only
> look in the nix store for native libraries, and not in /usr/lib, etc? I saw
> the `nix-shell` command, but it looks like I would have to add a `-p
> package` argument for each package I want in the environment. Is there any
> way to tell `nix-shell` that I want all my nix packages in the environment?
> I guess I could create a shell script to automate adding a `-p` argument
> for each package in my nix store, but is there an easier way?
>
> Thanks!
> Ben Booth
>
> [1]
> https://nixos.org/wiki/How_to_install_nix_in_home_\(on_another_distribution\)
> [2] http://proot.me/
> [3] https://github.com/lethalman/nix-user-chroot
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] npm packages broken

[Wout Mertens]

Sadly, I always build npm packages locally with a user created for the app.
Npm2nix is not usable yet afaik (I'd love to be wrong).

Last I saw, someone was proposing for it to piggyback on `npm shrinkwrap`,
which I think would be the way to go for determining version numbers. Worst
case, the result could be used to pre-populate an npm cache and to run npm
in a sandbox for building (possibly step by step so we can store all
modules separately).

On Tue, Feb 2, 2016, 8:53 PM Matthew O'Gorman  wrote:

>
> Yesterday I tried to package phonegap for nixos but ran into problems.
> It seems several of the packages in the node-package-generated.nix no
> longer exist so npm2nix over node-packages.json fails.  Should this
> feature be removed? If so how should I go about packaging npm software
> for nix.
>
> --
> Matthew O'Gorman
> BM-NBUmia4p88Jny5bZbRGcMt64SWWp5WVv
> TorChat: 5w3dtk7nhkkijcpc
> Site: https://b.rldn.net
> Xim/Email: m...@rldn.net
> mog@rldn:~$ fortune wisdom -s|cowsay -f /dev/null
>  __
> / There is no cure for birth and death \
> | other than to enjoy the interval.|
> |  |
> \ -- George Santayana  /
>  --
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix-Store sharing (with NFS + AUFS)?

[Wout Mertens]

I looked into what would be needed to have multiple writers on the same
store here: https://github.com/NixOS/nix/issues/378#issuecomment-62724778

The same would apply for aufs-type multi writer setups.

The tl;dr is that Nix would need to treat sqlite as only a cache, with all
needed info written in the store, and that Eelco didn't like the idea :-)

I still would love to have this, the store is at the mercy of a single file
right now…

On Sat, Jan 16, 2016, 1:49 PM Arseniy Seroka  wrote:

> You can't share over nfs because of sqlite. I've tried that myself and got
> no luck.
>
> --
> Sincerely,
> Arseniy Seroka
>
>
>
> On 16 January 2016 15:47:26 Matthias Beyer  wrote:
>
> > On 15-01-2016 17:19:37, Rok Garbas wrote:
> >> Quoting Matthias Beyer (2016-01-15 16:38:30)
> >> > Hi,
> >> >
> >> > I'm currently thinking about the following problem:
> >> >
> >> > I want to share the /nix/store from one Master machine to several
> Slaves, but
> >> > in a slightly different way than is currently possible with ssh /
> http:
> >> >
> >> > I want _one_ store which contains software, which then can be used by
> all the
> >> > slaves (like you'd do with NFS).
> >> >
> >> > The Slave machine should still be able to install software with the
> package
> >> > manager (nix) but only locally, not globally.
> >> >
> >> > So the Slave installs software to /nix/store locally, while /nix/store
> >> contains
> >> > store entries which are hosted on the master.
> >> >
> >> > My first idea would be NFS + AUFS, but maybe there are nix-buildin
> >> > possibilities?
> >> >
> >> >
> >> > Use-Case: Provide a standard-set of software but allow each VM to
> install own
> >> > software if needed, while keeping the amount of used storage as small
> as
> >> > possible.
> >> >
> >> > With the solution I'm searching for, 100 VMs which only use the
> standard
> >> > set on software would cause 1 % Storage-use (the packages are only
> phyiscally
> >> > available on one machine: the master) of the amount of storage which
> would be
> >> > needed with each VM installing the stuff.
> >> >
> >>
> >> you could also just use ``services.nix-serve`` module
> >>
> https://github.com/NixOS/nixpkgs/blob/release-15.09/nixos/modules/services/networking/nix-serve.nix
> >>
> >> and change all slaves to point their binary cache to Master's url.
> >>
> >
> > But wouldn't that cause the slaves to download the binaries from the
> > master instead of using them directly from the masters harddisc?
> >
> > --
> > 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
> >
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Sidestepping the community builds trust issue?

[Wout Mertens]

It is case specific and involves fingerprinting each built file. For
example, with prelinking you rewrite the elf headers, and to verify
equivalence you simply set the linker instructions to 0 while calculating
the file checksum.

On Mon, Jan 4, 2016, 1:01 AM Tim Barbour <t...@categorical.net> wrote:

> On Sat, 26 Dec 2015 09:07:38 +0000,
> Wout Mertens wrote:
> > If web-of-trust is the best solution, and the only blocker is build
> reproducability, how about trying to classify
> > build differences?
> >
> > Each of the differences will have a reason, and either we can fix the
> build to be deterministic (e.g. timestamps,
> > build paths), or we can classify a class of changes as equivalent (e.g.
> optimalizations resulting in equivalent
> > code, prelinking).
> > [...]
>
> Your suggestion sounds a bit like homotopy, which type theorists are now
> using
> to resolve their long-standing difficulties with intensional vs extensional
> equality; perhaps there is a connection between these difficulties and the
> fact that Nixos is not yet using the intensional Nix store model.
>
> How would one verify that the builds are equivalent, and that the
> difference
> is not due to a malicious modification ?
>
> Tim
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Sidestepping the community builds trust issue?

[Wout Mertens]

If web-of-trust is the best solution, and the only blocker is build
reproducability, how about trying to classify build differences?

Each of the differences will have a reason, and either we can fix the build
to be deterministic (e.g. timestamps, build paths), or we can classify a
class of changes as equivalent (e.g. optimalizations resulting in
equivalent code, prelinking).

It could very well be that we cannot automatically determine if a set of
builds is equivalent, and then the build will simply have to be done
locally instead of downloaded.

On Fri, Dec 25, 2015, 9:48 PM Tim Barbour  wrote:

> I agree there is no conflict between your proposal and my suggestion.
> The reason I mentioned it is that I do not like the idea of relying on
> a single trusted party for security (to whic your proposal makes no
> difference, because the trusted party will control all build
> machines). If someone (use your imagination) wanted to be able to gain
> access to any nixos machine, they would be tempted to compromise the
> centrally controlled builds.
>
> Therefore I think we should encourage people to run build systems,
> whether centrally controlled or not.
>
> Tim
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [Bachelors Thesis] Studi-Cloud VMs managing with Nix?

[Wout Mertens]

¯\_(ツ)_/¯ good luck I'd say :)

On Sun, Dec 20, 2015 at 10:45 AM Matthias Beyer <m...@beyermatthias.de>
wrote:

> No.
>
> I need a way to describe debian/centos VM ISO images with Nix. Not
> more, not less.
>
> On 19-12-2015 23:01:22, Wout Mertens wrote:
> > So basically you need a frontend that creates .nix files for profs and a
> vm
> > image with all binaries for everything already on it?
> >
> > On Sat, Dec 19, 2015 at 4:34 PM Matthias Beyer <m...@beyermatthias.de>
> > wrote:
> >
> > > On 11-12-2015 15:56:00, Marc Weber wrote:
> > > >
> > > > But serausly, if the profs need etiher mysql or postgresql why not
> put
> > > > both on one iso and be done? Should students switch isos if they
> "happen
> > > > to require the other software .." ?
> > >
> > > Because we would have N different ISOs flying around. Each Prof needs
> > > another custom image, and having N configuration.nix vs. having N
> > > vm.iso flying around ... is a deal, actually.
> > >
> > > >
> > > > Because nixos can "switch configurations" there are more options: use
> > > > usb sticks, then each prof can provide his config and students can
> > > > update their 'usb clone' fast because only differences will be
> fetched
> > > > (doing as much sharing on the stick as possible).
> > > >
> > >
> > > We cannot expect the profs to write .nix files.
> > >
> > > --
> > > 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
> > >
> > --
> >
> > Wout.
> > (typed on mobile, excuse terseness)
>
> --
> Mit freundlichen Grüßen,
> Kind regards,
> Matthias Beyer
>
> Proudly sent with mutt.
> Happily signed with gnupg.
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [Bachelors Thesis] Studi-Cloud VMs managing with Nix?

[Wout Mertens]

So basically you need a frontend that creates .nix files for profs and a vm
image with all binaries for everything already on it?

On Sat, Dec 19, 2015 at 4:34 PM Matthias Beyer 
wrote:

> On 11-12-2015 15:56:00, Marc Weber wrote:
> >
> > But serausly, if the profs need etiher mysql or postgresql why not put
> > both on one iso and be done? Should students switch isos if they "happen
> > to require the other software .." ?
>
> Because we would have N different ISOs flying around. Each Prof needs
> another custom image, and having N configuration.nix vs. having N
> vm.iso flying around ... is a deal, actually.
>
> >
> > Because nixos can "switch configurations" there are more options: use
> > usb sticks, then each prof can provide his config and students can
> > update their 'usb clone' fast because only differences will be fetched
> > (doing as much sharing on the stick as possible).
> >
>
> We cannot expect the profs to write .nix files.
>
> --
> 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] $3.40/month ARM server w/ 2GB RAM, 50GB disk

[Wout Mertens]

https://blog.scaleway.com/2015/11/03/scaleway-is-growing-too-fast-out-of-stock/

:-)

On Fri, Nov 6, 2015 at 10:16 PM Hajo Möller  wrote:

> Also, https://www.kimsufi.com may be worth checking out. I'm running
> 15.09 on a KS-1 and a KS-5.
>
> A KS-1 is amd64 and can be had for 5 EUR/month.
>
> --
> Regards,
> Hajo Möller
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] $3.40/month ARM server w/ 2GB RAM, 50GB disk

[Wout Mertens]

http://techcrunch.com/2015/09/02/scaleway-now-provides-crazy-cheap-virtual-private-servers-starting-at-3-40-per-month/

It's a dedicated quad-core ARM server, and you even get 200Mb/s networking.

Has anybody tried to get NixOS running on these? Seems like this would be
amazing for web servers…

Having the basically the same configuration.nix for intel or arm platforms
gives NixOS a big leg up in being able to use this.

Wout.
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Feature request: replace the Darwin stdenv with the pure Darwin stdenv

[Wout Mertens]

+1000 on just switching, pure-darwin rocks, impure has constant issues and
we need more eyeballs.

In case of severe breakage we can keep a non-building channel on impure so
people can get at the old binaries…

On Fri, Oct 2, 2015, 18:10 zimbatm  wrote:

> Looking forward to see the merge happening. Right now Darwin is totally
> unusable for me because of the OSX upgrade.
>
> On Fri, 2 Oct 2015 at 16:52 Eric Seidel  wrote:
>
>> I'm tentatively in favor of making the switch too. I'm going to test my
>> environment against pure-darwin this weekend.
>>
>> On Fri, Oct 2, 2015, at 08:03, Anthony Cowley wrote:
>> >
>> >
>> > > On Oct 2, 2015, at 10:26 AM, Daniel Peebles 
>> wrote:
>> > >
>> > > If nobody objects, I think we should just switch over. The only
>> people interested in maintaining the darwin ecosystem on Nix don't really
>> want to have to maintain two parallel stdenvs, and unless someone stands up
>> to fight for the old impure stdenv, I think everyone will be long-term
>> better off with the pure one. Yes, there will be some short- and
>> medium-term pain during the switch, but there already is with the El
>> Capitan upgrade.
>> >
>> > I vote to go ahead with this, too. Getting just a little help from hydra
>> > in terms of binaries will make it a lot easier to contribute to
>> > pure-Darwin.
>> >
>> > Anthony
>> >
>> >
>> >
>> > >
>> > >> On Fri, Oct 2, 2015 at 3:01 AM, Michael Sperber <
>> sper...@deinprogramm.de> wrote:
>> > >>
>> > >> Daniel Peebles  writes:
>> > >>
>> > >> > Probably obvious, but I'm in favor of switching/merging :)
>> > >>
>> > >> +1
>> > >>
>> > >> --
>> > >> Regards,
>> > >> Mike
>> > >>
>> > >> ___
>> > >> 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
>> ___
>> 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] I want nice things (apache compression)

[Wout Mertens]

Hi all,

see
https://github.com/NixOS/nixpkgs/commit/9d82f7e53e66e5594b0c8b82f6c415a0a386b580
which
reverts a site-wide optional compression feature I added. The discussion
and lack of answering can be found at
https://github.com/NixOS/nixpkgs/pull/9407#issuecomment-134523359.

IMHO, configuring Apache is annoying and not easy to get right, so I would
love to have an enableCompression flag. Data point: nixos.org doesn't use
compression, for no good reason.

I'm not happy that the commit got reverted without answering my question,
but that's what happens in a benevolent dictatorship I guess.

So I would like to know what would be an acceptable configuration. I'm
guessing:

   - Configurable site-wide and per virtualhost
   - Only compress known-compressible files: html, css, json, svg, txt, md

Right?

Wout.

PS: Alternatively, there could be a sort of plugin system for
configurations which allows implementing this sort of configuration sugar
without going into nixpkgs and with minimal end-user effort to keep
up-to-date. I don't know what such a system would look like.

-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] I want nice things (apache compression)

[Wout Mertens]

I don't mind reverting commits, I'm just a bit miffed at the lack of
communication around it. I asked a question on how to improve and instead
of an answer it got reverted.

In retrospect, I suppose I should have done the revert myself? At the time
I felt that maybe there could be small tweaks done instead of reverting,
because postponing in Nixpkgs generally leads to issues that languish
without resolution.

I agree that NixOS should provide easy knobs for common settings, and some
of them will be more controversial than others. However, unlike any other
distribution, NixOS allows defining conflicting settings that can still
coexist in code, leaving the end-user to choose what is best for them. You
don't like how compression is defined, you can just provide your own
configuration.

Any pointers on how to implement a per-virtualhost setting, also
overridable on the service level?

Wout.

On Sat, Sep 12, 2015 at 12:53 PM Domen Kožar <do...@dev.si> wrote:

> Reverting controversial commits is how we've been dealing with such
> disagreements and you're encouraged to open a PR for discussion.
>
> I think there should be a line where options are too specific based on
> particular usage.
>
> That said, NixOS has the unique opportunity to take a big step forward
> providing sane defaults while giving a simple flag switch to, for example,
> best TLS configuration settings.
>
> The main problem going that path is, there will be a lot of bikeshedding
> as these configuration options are never perfect (again, due to different
> applications).
>
> I think there are good arguments on both sides and we have to figure out
> which policy works best for everyone.
>
> Given the flexability NixOS modules provide, it should be possible to
> separate basic settings from advanced usage.
>
> PS: Similar change for nginx: https://github.com/NixOS/nixpkgs/pull/9693
>
> Domen
>
> On Sat, Sep 12, 2015 at 11:39 AM, Joachim Schiele <j...@lastlog.de> wrote:
>
>> compression is really important and i would like to have this as a nix
>> option as well! but eelco might be right as this should be a per vhost
>> option but i'm not sure about that.
>>
>> +1
>>
>> On 12.09.2015 11:05, Wout Mertens wrote:
>> > Hi all,
>> >
>> > see
>> https://github.com/NixOS/nixpkgs/commit/9d82f7e53e66e5594b0c8b82f6c415a0a386b580
>> which
>> > reverts a site-wide optional compression feature I added. The discussion
>> > and lack of answering can be found
>> > at https://github..com/NixOS/nixpkgs/pull/9407#issuecomment-134523359
>> > <https://github.com/NixOS/nixpkgs/pull/9407#issuecomment-134523359>.
>> >
>> > IMHO, configuring Apache is annoying and not easy to get right, so I
>> > would love to have an enableCompression flag. Data point: nixos.org
>> > <http://nixos.org> doesn't use compression, for no good reason.
>> >
>> > I'm not happy that the commit got reverted without answering my
>> > question, but that's what happens in a benevolent dictatorship I guess.
>> >
>> > So I would like to know what would be an acceptable configuration. I'm
>> > guessing:
>> >
>> >   * Configurable site-wide and per virtualhost
>> >   * Only compress known-compressible files: html, css, json, svg, txt,
>> md
>> >
>> > Right?
>> >
>> > Wout.
>> >
>> > PS: Alternatively, there could be a sort of plugin system for
>> > configurations which allows implementing this sort of configuration
>> > sugar without going into nixpkgs and with minimal end-user effort to
>> > keep up-to-date. I don't know what such a system would look like.
>> >
>> > --
>> >
>> > Wout.
>> > (typed on mobile, excuse terseness)
>> >
>> >
>> >
>> > ___
>> > 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Nix on Windows

[Wout Mertens]

I don't use Nix on Windows but wanted to say the technical report was very
interesting!

One thing that stood out was that using bash was much slower than using
sed, is that change now on Linux as well? Just wondering...

Wout.

On Tue, Sep 8, 2015 at 1:15 PM Florian Friesdorf  wrote:

>
> Hi,
>
> We got around to publish the technical report we were preparing as part
> of our work on porting nix and nixpkgs to cywin:
>
> http://ternaris.com/lab/nix-on-windows.html
>
> As a next task https://nixos.org/wiki/Nix_on_Windows should probably be
> updated based on this.
>
> Is anybody using Nix on cygwin and could help with that?
>
> --
> 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
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Atom 1.0.11 failing to start (need help with debugging)

[Wout Mertens]

To give you an idea of what can go wrong with atom, check out
https://github.com/atom/atom/pull/7877

Quite stunning, the amount of breakage you can get by simply upgrading
seemingly orthogonal packages. There are just a huge amount of moving parts
I suppose.

Wout.

On Mon, Sep 7, 2015, 22:47 Wout Mertens <wout.mert...@gmail.com> wrote:

> Well, what I mean is that there could be some bug in Node that is
> triggered... So using a diffferent Node might fix it.
>
> On Sun, Sep 6, 2015 at 7:12 PM Domen Kožar <do...@dev.si> wrote:
>
>> It's using bundled nodejs, so that should be the same... It appears that
>> one of the javascript libraries tried to compile with native code and
>> fails. But why does it succeed for some people but not for others?
>>
>> On Sun, Sep 6, 2015 at 7:10 PM, Wout Mertens <wout.mert...@gmail.com>
>> wrote:
>>
>>> Shot in the dark: did you try varying nodejs versions?
>>>
>>> On Sun, Sep 6, 2015, 15:40 Domen Kožar <do...@dev.si> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've been trying to upgrade Atom for our release and for some reason
>>>> it's failing to start under SOME circumstances.
>>>>
>>>> I've tried running Atom in different user, different directory.
>>>>
>>>> Steps to reproduce (please report if it works for you and under which
>>>> nixos-version):
>>>>
>>>> $ git checkout atom_1_0_11
>>>> $ nix-build -A atom
>>>> $ $ env -i DISPLAY="$DISPLAY" HOME="$HOME" PATH="$PATH"
>>>> /nix/store/s5xwlnxlzxfb5zllbzmrnybmp72iw1gz-atom-1.0.11/bin/atom
>>>>
>>>> Original PR was https://github.com/NixOS/nixpkgs/pull/9605 and I can
>>>> successfully run Atom 1.0, but only when I run 1.0.11 it fails to run.
>>>>
>>>> Domen
>>>> ___
>>>> nix-dev mailing list
>>>> nix-dev@lists.science.uu.nl
>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>
>>> --
>>>
>>> Wout.
>>> (typed on mobile, excuse terseness)
>>>
>>
>> --
>
> Wout.
> (typed on mobile, excuse terseness)
>
-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Atom 1.0.11 failing to start (need help with debugging)

[Wout Mertens]

Well, what I mean is that there could be some bug in Node that is
triggered... So using a diffferent Node might fix it.

On Sun, Sep 6, 2015 at 7:12 PM Domen Kožar <do...@dev.si> wrote:

> It's using bundled nodejs, so that should be the same... It appears that
> one of the javascript libraries tried to compile with native code and
> fails. But why does it succeed for some people but not for others?
>
> On Sun, Sep 6, 2015 at 7:10 PM, Wout Mertens <wout.mert...@gmail.com>
> wrote:
>
>> Shot in the dark: did you try varying nodejs versions?
>>
>> On Sun, Sep 6, 2015, 15:40 Domen Kožar <do...@dev.si> wrote:
>>
>>> Hi all,
>>>
>>> I've been trying to upgrade Atom for our release and for some reason
>>> it's failing to start under SOME circumstances.
>>>
>>> I've tried running Atom in different user, different directory.
>>>
>>> Steps to reproduce (please report if it works for you and under which
>>> nixos-version):
>>>
>>> $ git checkout atom_1_0_11
>>> $ nix-build -A atom
>>> $ $ env -i DISPLAY="$DISPLAY" HOME="$HOME" PATH="$PATH"
>>> /nix/store/s5xwlnxlzxfb5zllbzmrnybmp72iw1gz-atom-1.0.11/bin/atom
>>>
>>> Original PR was https://github.com/NixOS/nixpkgs/pull/9605 and I can
>>> successfully run Atom 1.0, but only when I run 1.0.11 it fails to run.
>>>
>>> Domen
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>> --
>>
>> Wout.
>> (typed on mobile, excuse terseness)
>>
>
> --

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [(private) Meetup] I'm traveling through Europe, maybe I can meet some nixers?

[Wout Mertens]

Good luck on your trip, sounds like fun! Unfortunately the Donau doesn't
pass Warsaw, otherwise, welcome!

On Mon, Jul 13, 2015 at 12:56 AM Joachim Schiele j...@lastlog.de wrote:

 if you come near tübingen (where i live) or balingen let me know.

 would be nice meeting you

 On 07.07.2015 20:57, Matthias Beyer wrote:
  Hi Nixers!
 
  So, it happens that I will travel through Europe in August and
  September. Actually, I will travel by bike from Donau-Eschingen (where
  the Donau originates) to the Black Sea, if I get so far.
 
  Maybe I can meet some nixers while traveling? Would be a pleasure to
  meet some of you for a drink or something, if we can arrange that!
 
  Contact me!
 
  Besides: I'd love to attend at a nixos meetp, NixConn anyone? :-P
 
 
 
  ___
  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

-- 

Wout.
(typed on mobile, excuse terseness)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] luks encrypted home stopped mounting after channel update

[Wout Mertens]

Two approaches:

   - Look through all the commits between your working system and your
   broken system, finding anything related to boot, initrd or luks
   - Mount the old and new initrds and compare contents

(I don't really know how luks works, I presume it runs in the initrd to
mount root)

On Wed, May 20, 2015 at 5:48 AM Ellis Whitehead ellis.whiteh...@gmail.com
wrote:

 A few days ago, I ran `nixos-rebuild --switch` using the up-to-date
 unstable channel, and everything worked fine.  Last night I updated
 the channel again and rebuilt, but when I started my computer this
 morning, it doesn't prompt for the encryption password anymore, and
 home doesn't mount.  Any ideas?

 I can get into my system by telling GRUB to boot the previous
 configuration instead, so the partition itself is fine.  Nothing
 changed in my configure.nix.  Here are the relevant lines:

 ---
 # Use the GRUB 2 boot loader.
 boot.loader.grub.enable = true;
 boot.loader.grub.version = 2;
 # Define on which hard drive you want to install Grub.
 boot.loader.grub.device = /dev/sda;

 # Encrypted home
 boot.initrd.luks.devices = [ { device = /dev/sda6; name = home; }
 ];

 fileSystems./home.device = /dev/mapper/home;
 ---

 And this is my hardware-configuration-lorax.nix:

 ---
 # Do not modify this file!  It was generated by ‘nixos-generate-config’
 # and may be overwritten by future invocations.  Please make changes
 # to /etc/nixos/configuration.nix instead.
 { config, pkgs, ... }:

 {
   imports =
 [ nixpkgs/nixos/modules/installer/scan/not-detected.nix
 ];

   boot.initrd.availableKernelModules = [ ehci_pci ahci xhci_hcd
 usbhid ];
   boot.kernelModules = [ kvm-intel ];
   boot.extraModulePackages = [ ];

   fileSystems./ =
 { device = /dev/sda5;
   fsType = ext4;
 };

   swapDevices =[ ];

   nix.maxJobs = 4;
 }
 ---

 The error message in `journalctl -xb` is:
 May 20 04:50:55 lorax systemd[1]: Job dev-mapper-home.device/start timed
 out.
 May 20 04:50:55 lorax systemd[1]: Timed out waiting for device
 dev-mapper-home.device.
 May 20 04:50:55 lorax systemd[1]: Dependency failed for /home.
 May 20 04:50:55 lorax systemd[1]: Dependency failed for Local File Systems.
 May 20 04:50:55 lorax systemd[1]: Triggering OnFailure= dependencies
 of local-fs.target.
 May 20 04:50:55 lorax systemd[1]: Dependency failed for File System
 Check on /dev/mapper/home.

 The AES encryption modules is loaded, though.

 Any ideas about how to get the system to ask for my encryption
 password again?  Much appreciated,
 Ellis
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] write_file '/etc/passwd.tmp' - syswrite: Bad address

[Wout Mertens]

Oh wow I never saw that before, and in a Perl script no less.
I think you may have memory corruption? Does memtest86 work fine?

Wout.

On Sat, May 16, 2015, 2:59 PM Amy de Buitléir a...@nualeargais.ie wrote:

 Sigh... new problem:

 [root@wombat9000:~]# nixos-rebuild switch
 building Nix...
 building the system configuration...
 activating the configuration...
 setting up /etc...
 warning: not applying UID change of user ‘ntp’
 write_file '/etc/passwd.tmp' - syswrite: Bad address at
 /nix/store/a218r8idpw52c652vy44d9zvfjf82jbc-update-users-groups.pl line
 217.
 warning: error(s) occured while switching to the new configuration


 What I have tried:
 1. Ran badblocks, which found no bad blocks on my system.
 2. nixos-rebuild switch --repair, which gave the same error.
 3. nix-store --verify --check-contents --repair

 [root@wombat9000:~]# nix-store --verify --check-contents --repair
 reading the Nix store...
 checking path existence...
 checking hashes...

 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] write_file '/etc/passwd.tmp' - syswrite: Bad address

[Wout Mertens]

Of course, it can only be memory corruption if it is not repeatable,
otherwise there's something weird about the call Perl makes to syswrite(),
definitely a bug somewhere then.

On Sat, May 16, 2015, 3:03 PM Wout Mertens wout.mert...@gmail.com wrote:

 Oh wow I never saw that before, and in a Perl script no less.
 I think you may have memory corruption? Does memtest86 work fine?

 Wout.

 On Sat, May 16, 2015, 2:59 PM Amy de Buitléir a...@nualeargais.ie wrote:

 Sigh... new problem:

 [root@wombat9000:~]# nixos-rebuild switch
 building Nix...
 building the system configuration...
 activating the configuration...
 setting up /etc...
 warning: not applying UID change of user ‘ntp’
 write_file '/etc/passwd.tmp' - syswrite: Bad address at
 /nix/store/a218r8idpw52c652vy44d9zvfjf82jbc-update-users-groups.pl line
 217.
 warning: error(s) occured while switching to the new configuration


 What I have tried:
 1. Ran badblocks, which found no bad blocks on my system.
 2. nixos-rebuild switch --repair, which gave the same error.
 3. nix-store --verify --check-contents --repair

 [root@wombat9000:~]# nix-store --verify --check-contents --repair
 reading the Nix store...
 checking path existence...
 checking hashes...

 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev


___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] write_file '/etc/passwd.tmp' - syswrite: Bad address

[Wout Mertens]

Well, that looks like hardware corruption somewhere. Might I recommend
using zfs or btrfs as your filesystem to ensure integrity?

On Sat, May 16, 2015, 4:58 PM Amy de Buitléir a...@nualeargais.ie wrote:

 Wout Mertens wout.mertens at gmail.com writes:

  so weird... what was the corruption?

 Halfway through the file, there was stuf like this:

 ÃU+0083ÂU+0083ÃU+0082ÂU+0083ÃU+0083ÂU+0082...
 ___
 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] Proposal: make global dependencies or paths explicit

[Wout Mertens]

There are a few dependencies in nixos that are hidden from nix as to not
have to recompile the world when they change.

The instances I know of are the timezone files and CA certificates but
there's probably more. The timezone files expect TZDIR to be set, and all
programs are being compiled to check /etc/ssl/certs/ca-bundle.crt.

I would like to propose that all global state is kept at fixed paths (like
it is with ca-bundle) but that all occurences of those paths are instead
replaced with attributes of pkgs.config.statics, so that users can override
them easily.

That way, for other platforms (e.g. Darwin or cygwin) you can point those
paths to where the relevant data is and ideally with a light recompile
you'd have everything working.

Basically, all occurrences of static paths in nixpkgs like /etc or /var
 should be replaced with pkgs.config.statics.zonedir, .ca-bundle,
.system-config (configuration.nix), .nix-config (/etc/nix/nix.conf),
.shell-profile (/etc/profile) etc.

Should be a pretty small change, not resulting in many rebuilds, that
allows for better discoverability and configurability.

As an example benefit, we can now make /etc/ssl/certs/ca-certificates.crt
the default instead of ca-bundle.crt, simply change one line.

If we do this for everything, eventually this will for example allow us to
move /etc/passwd and /etc/shadow elsewhere, and having full visibility into
all builds that use it.

I gave the concept a try in my static-paths branch at
https://github.com/wmertens/nixpkgs/tree/static-paths but it's not working
because for some reason the contents of nixpkgs.config varies throughout
evaluation.

Hints welcome. To try, clone that branch and run nix-build
./nixos/default.nix -A system -v. I added traces for the pkgs.config
contents.

Would be great to have feedback on the naming and other options over
choosing the nixpkgs config as well.

Cheers,

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Ctrl-pnfb

[Wout Mertens]

That's really a question about Unix in general, not just NixOS.

Basically, there are several (a lot) of input methods, but you can cover a
lot of them by setting up ~/.inputrc and xkb.

See:


   - http://www.gnu.org/software/bash/manual/html_node/Sample-Init-File.html
   - https://wiki.archlinux.org/index.php/Keyboard_configuration_in_Xorg
   (the archlinux wiki is where you'll find most of what you need under NixOS
   :) )

Then you'll also need to set up apps that do things differently. Most of
them allow changing the keyboard configuration somehow.

Cheers,

Wout.

On Mon, May 11, 2015, 5:44 PM stewart mackenzie setor...@gmail.com wrote:

 So after using a mac at work I miss one thing i'd like to do on nix. That
 is everywhere (input boxes, browsers, tex editors, IDEs) I can navigate my
 cursor using:

 ctrl-f :forward
 ctrl-b :backward
 ctrl-n :next line
 ctrl-p : previous line

 is this possible within nixos? If so, how so?

 /sjm
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Vagrant stuff - images and plugin - still alive?

[Wout Mertens]

Yeah, Charles seems to be AWOL for a bit, it would be nice if he merged my
PR... Charles?

Wout.

On Tue, May 12, 2015 at 4:30 PM Christian Theune c...@flyingcircus.io wrote:


  On 12 May 2015, at 16:19, Christian Theune c...@flyingcircus.io wrote:
 
 
  On 12 May 2015, at 16:11, Christian Theune c...@flyingcircus.io wrote:
 
  Hi,
 
  I contacted a few people and got zimbatm to react. I’m trying to get
 his 14.12 branch working. I’ll also have a look at the one from cstrahan.
 
  Or actually the one from Wout. (*waves*)

 So that one builds 14.12 cleanly right away for me. It also provides
 partial integration points expected by oxdi’s plugin.

 Christian

 —
 Christian Theune · c...@flyingcircus.io · +49 345 219401 0
 Flying Circus Internet Operations GmbH · http://flyingcircus.io
 Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
 HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
 Zagrodnick

 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Possible bug in ssh key module

[Wout Mertens]

The build could run a quick check to see if ssh-keygen can read the
file? `ssh-keygen
-l -f filename` will return an error if it can't read a key in the file (it
only checks the first key)

On Tue, May 12, 2015 at 10:33 AM Christian Theune c...@flyingcircus.io
wrote:

 Hi,

 correct me if I’m wrong but SSH keys do not have a strong syntax, and
 aside from “there’s less than ssh-rsa…spacesomethingnonspace there
 isn’t much you can check for.

 Specifically as the comment field can contain pretty much anything and you
 can’t check the key data for validity on a semantic basis AFAIK.

 Christian

 On 12 May 2015, at 10:27, Tomasz Kontusz tomasz.kont...@gmail.com wrote:

 Oops, replied to the wrong address.

 --
 *Od:* Tomasz Kontusz tomasz.kont...@gmail.com
 *Wysłane:* Tue May 12 10:25:21 CEST 2015
 *Do:* Anand Patil anand.prabhakar.pa...@gmail.com
 *Temat:* Re: [Nix-dev] Possible bug in ssh key module

 It would still be nice if the middle yelled at you instead of using
 obviously wrong inputs.

 Actually, is there any practice already in place for this kind of checks?
 Like how picky should they be, and should they be overridable

 Anand Patil anand.prabhakar.pa...@gmail.com napisał:

 Hi Bas, yep, it was just that. Sorry for the false alarm.

 Thanks,
 Anand

 On Mon, May 11, 2015 at 12:52 AM, Bas van Dijk v.dijk@gmail.com wrote:

 On 11 May 2015 at 04:45, Anand Patil anand.prabhakar.pa...@gmail.com 
 wrote:

 Hi everyone,


 Just wanted to point out a small possible bug in NixOS version
 15.05pre61966.75ebc3c (Dingo). I noticed that when I add an
 authorizedKeys option to my user like so:

 openssh.authorizedKeys.keys = [ ssh-rsa stuff ];

 the contents of /etc/ssh/authorized_keys.d/anand look like

 ssh-rsa
 stuff

 with a newline after the ssh-rsa,


 Hi Anand,

 The
 implementation looks correct. It only adds newlines between the keys:

 https://github.com/NixOS/nixpkgs/blob/75ebc3cf1dc1365be5a05018fc8e5409c66025cb/nixos/modules/services/networking/ssh/sshd.nix#L55

 Are you sure your string doesn't contain a newline? Maybe your text
 editor added a newline when it wrapped the string.

 Bas

 --

 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev


 --
 Wysłane za pomocą K-9 Mail.
 --
 Wysłane za pomocą K-9 Mail.
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev


 —
 Christian Theune · c...@flyingcircus.io · +49 345 219401 0
 Flying Circus Internet Operations GmbH · http://flyingcircus.io
 Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
 HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian.
 Zagrodnick

 ___
 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] Support ` (backtick code) on the wiki

[Wout Mertens]

Please, install this extension on the NixOS Wiki:

http://www.mediawiki.org/wiki/Extension:BacktickCode

Thanks!

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] Linux kernel version for next stable?

[Wout Mertens]

Hi,

Our current stable is 3.14, our latest is 3.15, and on kernel.org the
latest longterm is 3.18.13 and stable is 4.0.2.

Is there a reason beyond manpower why we're not going with 3.18 for the
stable release and latest isn't 4.0?

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Linux kernel version for next stable?

[Wout Mertens]

Argh I must have been looking at an older commit. Sorry for the noise :)

Roger: 4.0 is linuxPackages_latest

On Thu, May 7, 2015 at 10:04 AM Domen Kožar do...@dev.si wrote:

 Our stable is 3.18 (latest longterm):
 https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix#L9422

 On Thu, May 7, 2015 at 8:32 AM, Wout Mertens wout.mert...@gmail.com
 wrote:

 Hi,

 Our current stable is 3.14, our latest is 3.15, and on kernel.org the
 latest longterm is 3.18.13 and stable is 4.0.2.

 Is there a reason beyond manpower why we're not going with 3.18 for the
 stable release and latest isn't 4.0?

 Wout.

 ___
 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] modularize all-packages?

[Wout Mertens]

all-packages.nix is gigantic, and because it's so large, github search
doesn't index it.

Would it be a good idea to move the attribute definitions into files per
package section?

So everything would still be in the pkgs attrset, only the definitions
would be split across multiple files.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] modularize all-packages?

[Wout Mertens]

the problem with readDir is slowness due to reading thousands of files...
nix codegen would fix that :)


On Thu, May 7, 2015 at 2:29 PM Daniel Peebles pumpkin...@gmail.com wrote:

 I thought that at some point there was an effort to autogenerate
 (dynamically, so not nix codegen) the list from readDir. If not, it seems
 like the majority of packages could work that way, along with room to
 override where necessary.



  On May 7, 2015, at 08:10, Wout Mertens wout.mert...@gmail.com wrote:
 
  all-packages.nix is gigantic, and because it's so large, github search
 doesn't index it.
 
  Would it be a good idea to move the attribute definitions into files per
 package section?
 
  So everything would still be in the pkgs attrset, only the definitions
 would be split across multiple files.
  ___
  nix-dev mailing list
  nix-dev@lists.science.uu.nl
  http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] modularize all-packages?

[Wout Mertens]

yes indeed that looks nice, it would eliminate some 3855 lines of 9351
non-empty lines... With more probably a small refactor away.

On Thu, May 7, 2015 at 3:08 PM Daniel Peebles pumpkin...@gmail.com wrote:

 What went wrong? I think that's what I was thinking of



  On May 7, 2015, at 08:50, Eelco Dolstra eelco.dols...@logicblox.com
 wrote:
 
  On 07/05/15 14:29, Daniel Peebles wrote:
 
  I thought that at some point there was an effort to autogenerate
  (dynamically, so not nix codegen) the list from readDir.
 
  I made an abortive attempt at reducing the size of all-packages.nix a
 while back:
 
 
 https://github.com/NixOS/nixpkgs/commit/ece61b7cc803d374e81b1094bd9c1f6d5a9ca5d0
 
  It would allow getting rid of all packages that don't override any
 default
  arguments (i.e. pass { } to callPackage).
 
  --
  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
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] modularize all-packages?

[Wout Mertens]

well, that traversal could be automated at commit time? It's just an
optimization...


On Thu, May 7, 2015 at 3:24 PM Eelco Dolstra eelco.dols...@logicblox.com
wrote:

 Hi,

 On 07/05/15 15:02, Daniel Peebles wrote:

  No need to read all the files, right? You import them lazily based on
 what
  readDir returns.

 Yes, but you still need to traverse the directory tree, which itself takes
 a
 long time on non-SSD disks.

 --
 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

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Vagrant stuff - images and plugin - still alive?

[Wout Mertens]

https://github.com/cstrahan/nix-packer/pull/14 makes it build a 14.12 image

On Tue, Apr 28, 2015 at 12:33 PM Domen Kožar do...@dev.si wrote:

 I'd send emails to both authors asking if they plan to update the images :)

 On Tue, Apr 28, 2015 at 9:45 AM, Rok Garbas r...@garbas.si wrote:

 Quoting Rok Garbas (2015-04-28 09:35:18)
  Quoting Christian Theune (2015-04-25 13:41:19)
   Hi,
  
   I’ve been working on getting vagrant-based setups working nicely in
 the last
   weeks and found
  
   https://github.com/oxdi/vagrant-nixos
   https://github.com/oxdi/nixos
   and
   https://github.com/zimbatm/nixbox
  
   The zimbatm has images available, I didn’t get around to using the
 packer
   templates, yet.
  
   The plugin is nice but is not compatible with NixOS 14.12 in the
 released
   version. The code has everything fixed already and just making a
 release of
   that code works nicely for me. However, I’d love if the gem would be
 publicly
   available.
  
   So, is anyone on this list using Vagrant with NixOS? Is the author of
 the
   plugin still around? Alternatives? Should I fork this and start making
   releases?
  
 
  Hi Christian,
 
  I would suggest to create a wiki page about vagrant+nixos to keep all
 the
  information in one place.
 
  currently there is only about virtualbox, but vagrant is quickly
 mentioned at
  the bottom.
 
 
 https://nixos.org/wiki/Installing_NixOS_in_a_VirtualBox_guest#Vagrant_boxes
 

 also i found https://github.com/cstrahan/nix-packer


 --
 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


 ___
 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] iPXE (for NixOps and Vultr)

[Wout Mertens]

Hi all,

Vultr is a cheap hosting provider (like digital ocean), and they allow iPXE
booting:
https://www.vultr.com/docs/ipxe-boot-feature

Does anybody have experience with this? It seems to me that you'd be able
to provide a minimal configuration in a query string and have the VM boot
an install ISO which then installs the VM according to the query. That'd be
nice for NixOps deployment...

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [PATCH 1/2] nixos-install: Fix password prompt failing outside NixOS.

[Wout Mertens]

Well, on github we have travis, and line comments, and bug references etc.
It's just nicer, and I haven't seen many patches come in via ML (this was
the first I noticed) so I didn't really have a workflow ready...

On Tue, Apr 28, 2015 at 12:40 PM Shea Levy s...@shealevy.com wrote:

 As long as I’ve been around we’ve also accepted patches via ML, why not?

  On Apr 28, 2015, at 2:34 AM, Wout Mertens wout.mert...@gmail.com
 wrote:
 
  These patches look useful, but normally we work via github...
 
 
  On Tue, Apr 28, 2015, 4:17 AM Jookia 166...@gmail.com wrote:
  When bootstrapping from other distributions, nixos-install is unable to
 find
  various tools in the chroot since their paths aren't aware of NixOS
 conventions.
 
  This makes a small change to existing code by specifying nixpkgs/nixos
 instead
  of just nixos when running nix-instantiate in the chroot. I haven't
 tested this
  outside of bootstrapping, but the same specification is used elsewhere
 in the
  code so I don't see why it wouldn't work.
  ---
   nixos/modules/installer/tools/nixos-install.sh | 8 +++-
   1 file changed, 7 insertions(+), 1 deletion(-)
 
  diff --git a/nixos/modules/installer/tools/nixos-install.sh
 b/nixos/modules/installer/tools/nixos-install.sh
  index 14ae3da..86e57f7 100644
  --- a/nixos/modules/installer/tools/nixos-install.sh
  +++ b/nixos/modules/installer/tools/nixos-install.sh
  @@ -254,8 +254,14 @@ NIXOS_INSTALL_GRUB=1 chroot $mountPoint \
   chroot $mountPoint /nix/var/nix/profiles/system/activate
 
 
  +# Some systems may not be prepared to use NixOS' paths.
  +export PATH=/run/current-system/sw/bin:/run/current-system/sw/sbin:$PATH
  +export
 NIX_PATH=/nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs
  +export
 NIX_PATH=$NIX_PATH:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels
  +
  +
   # Ask the user to set a root password.
  -if [ $(chroot $mountPoint nix-instantiate --eval 'nixos' -A
 config.users.mutableUsers) = true ]  [ -t 0 ] ; then
  +if [ $(chroot $mountPoint nix-instantiate --eval 'nixpkgs/nixos' -A
 config.users.mutableUsers) = true ]  [ -t 1 ] ; then
   echo setting root password...
   chroot $mountPoint /var/setuid-wrappers/passwd
   fi
  --
  2.3.6
 
  ___
  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

Re: [Nix-dev] [PATCH 1/2] nixos-install: Fix password prompt failing outside NixOS.

[Wout Mertens]

These patches look useful, but normally we work via github...

On Tue, Apr 28, 2015, 4:17 AM Jookia 166...@gmail.com wrote:

 When bootstrapping from other distributions, nixos-install is unable to
 find
 various tools in the chroot since their paths aren't aware of NixOS
 conventions.

 This makes a small change to existing code by specifying nixpkgs/nixos
 instead
 of just nixos when running nix-instantiate in the chroot. I haven't tested
 this
 outside of bootstrapping, but the same specification is used elsewhere in
 the
 code so I don't see why it wouldn't work.
 ---
  nixos/modules/installer/tools/nixos-install.sh | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

 diff --git a/nixos/modules/installer/tools/nixos-install.sh
 b/nixos/modules/installer/tools/nixos-install.sh
 index 14ae3da..86e57f7 100644
 --- a/nixos/modules/installer/tools/nixos-install.sh
 +++ b/nixos/modules/installer/tools/nixos-install.sh
 @@ -254,8 +254,14 @@ NIXOS_INSTALL_GRUB=1 chroot $mountPoint \
  chroot $mountPoint /nix/var/nix/profiles/system/activate


 +# Some systems may not be prepared to use NixOS' paths.
 +export PATH=/run/current-system/sw/bin:/run/current-system/sw/sbin:$PATH
 +export
 NIX_PATH=/nix/var/nix/profiles/per-user/root/channels/nixos:nixpkgs=/etc/nixos/nixpkgs
 +export
 NIX_PATH=$NIX_PATH:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/profiles/per-user/root/channels
 +
 +
  # Ask the user to set a root password.
 -if [ $(chroot $mountPoint nix-instantiate --eval 'nixos' -A
 config.users.mutableUsers) = true ]  [ -t 0 ] ; then
 +if [ $(chroot $mountPoint nix-instantiate --eval 'nixpkgs/nixos' -A
 config.users.mutableUsers) = true ]  [ -t 1 ] ; then
  echo setting root password...
  chroot $mountPoint /var/setuid-wrappers/passwd
  fi
 --
 2.3.6

 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Please test Nix store auto-optimise

[Wout Mertens]

I opened https://github.com/NixOS/nix/issues/377 a while ago and then I ran
some small tests and it didn't seem to matter. The links dir is of course
huge but it still performs fine on sane filesystems. IIRC, the only time
you do readdir on it is during GC to remove the ones with 1 link count.

Wout.

On Sat, Apr 25, 2015 at 3:16 AM Jascha Geerds j...@ekby.de wrote:

 Thank you for the hint, that saved 12GB on my machine. Anyway, wouldn't
 it be better if we use an extra level of directories to reduce the size
 of /nix/store/.links ?

  $ ls -l /nix/store/.links/ | wc -l
  374716

 ls is quite slow and this is just my desktop machine and not a busy
 server like hydra or something like that. Such a huge directory would
 kill slower file manager or other applications. I just think of
 PyCharm's open file dialog which sometimes tries to open my
 /nix/store... this operation freezes the application so that I have to
 kill it.

 For example git or git-annex introduced an extra level of directories to
 reduce the amount of files inside a single directory. Something like
 this:

 $ tree --charset=ascii /tmp/nix/store/.links/
 /tmp/nix/store/.links/
 |-- aab
 |   |-- aab4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 |   `-- aabd31b843d1faf29e4d3e50c135d6539ac9fe77ffd
 |-- aal
 |   |-- aal4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 |   `-- aald31b843d1faf29e4d3e50c135d6539ac9fe77ffd
 |-- ace
 |   |-- ace4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 |   `-- aced31b843d1faf29e4d3e50c135d6539ac9fe77ffd
 |-- ehw
 |   |-- ehw4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 |   `-- ehwd31b843d1faf29e4d3e50c135d6539ac9fe77ffd
 |-- eia
 |   |-- eia4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 |   `-- eiad31b843d1faf29e4d3e50c135d6539ac9fe77ffd
 |-- ial
 |   |-- ial4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 |   `-- iald31b843d1faf29e4d3e50c135d6539ac9fe77ffd
 `-- ode
 |-- ode4f31a9b3119c2f6bb3b45c27c4cb33ff45a8f6e2
 `-- oded31b843d1faf29e4d3e50c135d6539ac9fe77ffd

 7 directories, 14 files


 --
   Jascha Geerds
   j...@ekby.de
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] NixOS 15.05 release moved to 15.06

[Wout Mertens]

I suppose we didn't really keep up with documenting important changes at
https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-unstable.xml
?

How shall we find all the breaking changes and highlights? Someone eyeballs
all commits, or we do a call for important changes (CFIC)?

Wout.

PS: We should make releases happen every 5 months so we keep a 6 month
cycle ;)



On Mon, Apr 20, 2015 at 4:10 PM Domen Kožar do...@dev.si wrote:

 Hi all,

 due to lots of great work being done and all in-progress branches still
 being polished I'd like to move 15.05 release to June (15.06). That means
 release-15.06 branch shall be cut at the end of May.

 Keep up the good work! :) If someone wants to help improve documentation
 and has some questions, I'm happy to help with that and remove any
 obstacles.

 Domen
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] nixpkgs-unstable

[Wout Mertens]

Yes, no problem.

On Tue, Mar 24, 2015, 9:34 PM Arseniy Seroka ars.ser...@gmail.com wrote:

 Using nixos-unstable-small I have to build locally lots of pkgs :(

 But can I mix nixpkgs-unstable and nixos-unstable? Using the first one
 for nix-env and the second one for sudo nixos-rebuild?

 2015-03-24 23:32 GMT+03:00 Domen Kožar do...@dev.si:

 use nixos-unstable-small channel if you want to move fast(er). You can't
 use nixpkgs channel for nixos.

 On Tue, Mar 24, 2015 at 9:30 PM, Arseniy Seroka ars.ser...@gmail.com
 wrote:

 Hello!
 Trying to use nixpkgs-unstable as main channel.

 jaga {0} ~ sudo nix-channel --add
 http://nixos.org/channels/nixpkgs-unstable nixos
 jaga {0} ~ sudo nixos-rebuild switch --upgrade
 downloading Nix expressions from ‘
 http://nixos.org/releases/nixpkgs/nixpkgs-15.05pre59184.e07ea5c/nixexprs.tar.xz
 ’...
   % Total% Received % Xferd  Average Speed   TimeTime Time
  Current
  Dload  Upload   Total   SpentLeft
  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- --:--:--
 0
 unpacking channels...
 error: file ‘nixpkgs/nixos/modules/installer/tools/nixos-rebuild.sh’ was
 not found in the Nix search path (add it using $NIX_PATH or -I)
 building Nix...
 error: file ‘nixpkgs/nixos’ was not found in the Nix search path (add it
 using $NIX_PATH or -I)
 error: file ‘nixpkgs/nixos’ was not found in the Nix search path (add it
 using $NIX_PATH or -I)
 error: file ‘nixpkgs’ was not found in the Nix search path (add it using
 $NIX_PATH or -I)
 /tmp/nixos-rebuild.GAS7Lk/nix
 error: file ‘nixpkgs’ was not found in the Nix search path (add it using
 $NIX_PATH or -I)
 building the system configuration...
 error: file ‘nixpkgs/nixos’ was not found in the Nix search path (add it
 using $NIX_PATH or -I)
 ^C
 error: interrupted by the user

 jaga {130} ~ echo $NIX_PATH

 nixos=/nix/var/nix/profiles/per-user/root/channels/nixos/nixos:nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix
 jaga {0} ~ ls /nix/var/nix/profiles/per-user/root/channels/nixos/
 channel-name  default.nix  lib/  nixos/  README.md
 COPYING   doc/ maintainers/  pkgs/   svn-revision


 So I can't do nixos-rebuild. But nix-env works fine.
 What I'm doing wrong?

 --
 Sincerely,
 Arseniy Seroka

 ___
 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

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Why are there so many branches in the nixpkgs repo

[Wout Mertens]

My vote is to remove merged branches without historical significance
(version 0.5 is a keeper, like upstart), and then any branches that got
their last push before August 2014 are renamed to attic/...

That should make the github interface easier to navigate.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Please test Nix store auto-optimise

[Wout Mertens]

Since it looks for sub-blocks, first run the nix-store --optimise and then
run duperemove -dhr /nix/store.

Read the FAQ though:
https://github.com/markfasheh/duperemove/blob/master/FAQ.md

BTW, since bedup does files incrementally, it's nice to run that too. So
I'd do nix-store --optimise, bedup and then duperemove.

Of course if you don't want hardlinks (but there's really no reason on a
read-only store like /nix/store), you can leave the nix-store --optimise
out and only run bedup and duperemove.
If you want speed, only running nix-store --optimise and bedup should do
the trick, I wonder how much extra duperemove would save.

Wout.

On Wed Feb 18 2015 at 9:42:59 AM Raahul Kumar raahul.ku...@gmail.com
wrote:

 Can I know the best way to do this for BTRFS? Install duperemove, then
 what?

 Aloha,
 RK.

 On Mon, Feb 16, 2015 at 8:32 AM, James Cook james.c...@utoronto.ca
 wrote:

 Oops, yes, that's a good point. Filesystems with fancy things like
 reflinks probably have their own tools for deduplication.

 On 15 February 2015 at 01:48, Wout Mertens wout.mert...@gmail.com
 wrote:
  If you want to use reflinks, better to use the deduplication tools that
 come
  with the filesystem, e.g.
  https://btrfs.wiki.kernel.org/index.php/Deduplication (duperemove is in
  nixpkgs).
 
  Also, it would be nice if we could patch GNU cp so that it always tries
 to
  use reflinks (so that builds automatically have reflinks where
 possible).
  There's an option --reflinks=auto that does that and I don't
 understand
  why it's not the default (as discussed at
 
 http://unix.stackexchange.com/questions/80351/why-is-cp-reflink-auto-not-the-default-behaviour
 ).
  Maybe we should make it a nixos option.
 
  Hardlinks are slightly impure and they do cause build failures in rare
 and
  easily-fixed cases, but they're cross-platform, robust and easy to
 inspect.
  Indeed the .links directory won't be able to be pruned due to reflinks
 being
  invisible.
 
  To implement reflinks properly you would have to keep a hash of each
 file in
  the nix-store in a DB. This has advantages, like being able to hash
 lazily
  (only when another file with the same size shows up), and being able to
 do
  queries, but it also means that you're duplicating that other DB, the
 file
  system.
 
 
  Wout.
 
  On Sun, Feb 15, 2015, 9:54 AM James Cook james.c...@utoronto.ca
 wrote:
 
   Once I wondered if using reflinks instead of hardlinks might be
 better
   from
   some point of view, but it probably won't be a big difference.
 
  I would really like to see reflinks being used instead of hard links
  on filesystems that support it. Hard linking is an impurity which can
  cause bugs, as Wout pointed out at the start of the thread (e.g.
  https://github.com/NixOS/nixpkgs/issues/4266).
 
  Implementation question: how would nix know when it can delete a file
  in /nix/store/.links? I assume than now it just checks the number of
  links, but I don't know if you can do that with reflinks.
 
  James
  ___
  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

Re: [Nix-dev] Please test Nix store auto-optimise

[Wout Mertens]

If you want to use reflinks, better to use the deduplication tools that
come with the filesystem, e.g.
https://btrfs.wiki.kernel.org/index.php/Deduplication (duperemove is in
nixpkgs).

Also, it would be nice if we could patch GNU cp so that it always tries to
use reflinks (so that builds automatically have reflinks where possible).
There's an option --reflinks=auto that does that and I don't understand
why it's not the default (as discussed at
http://unix.stackexchange.com/questions/80351/why-is-cp-reflink-auto-not-the-default-behaviour).
Maybe we should make it a nixos option.

Hardlinks are slightly impure and they do cause build failures in rare and
easily-fixed cases, but they're cross-platform, robust and easy to inspect.
Indeed the .links directory won't be able to be pruned due to reflinks
being invisible.

To implement reflinks properly you would have to keep a hash of each file
in the nix-store in a DB. This has advantages, like being able to hash
lazily (only when another file with the same size shows up), and being able
to do queries, but it also means that you're duplicating that other DB, the
file system.


Wout.
On Sun, Feb 15, 2015, 9:54 AM James Cook james.c...@utoronto.ca wrote:

  Once I wondered if using reflinks instead of hardlinks might be better
 from
  some point of view, but it probably won't be a big difference.

 I would really like to see reflinks being used instead of hard links
 on filesystems that support it. Hard linking is an impurity which can
 cause bugs, as Wout pointed out at the start of the thread (e.g.
 https://github.com/NixOS/nixpkgs/issues/4266).

 Implementation question: how would nix know when it can delete a file
 in /nix/store/.links? I assume than now it just checks the number of
 links, but I don't know if you can do that with reflinks.

 James
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Delays on ssh connection

[Wout Mertens]

Weird - what branch are you on? Anything special in you configuration.nix?
Sounds like a bug somewhere but could be anything. I have no idea what
causes that connection timed out for the session creation if it's not DNS.

You could try picking a different nixpkgs commit and see if your system is
stable there.

Wout.

On Wed Feb 11 2015 at 12:43:29 PM Carles Pagès page.li...@gmail.com wrote:

 It also happens if I ssh to localhost, so I don't think it's the same.
 I forgot to mention that systemd is consuming a lot of cpu (top shows
 ~15% constantly).

 2015-02-11 11:28 GMT+01:00  emil.rang...@chas.se:
  On 2015-02-11 9:57, Carles Pagès wrote:
  Hi all,
 
  My system (nixos 14.12.231.139ead2) is in a state that, when
  connecting through ssh there is a delay of ~30s. It happened to me a
  while ago and was 'solved' with a reboot.
 
  Looking at the logs, I see:
  feb 10 09:33:03 pica sshd[9346]: pam_unix(sshd:session): session
  opened for user xxx by (uid=0)
  feb 10 09:33:03 pica systemd-logind[1748]: New session 66 of user xxx.
  feb 10 09:33:28 pica sshd[9346]: pam_systemd(sshd:session): Failed to
  create session: Connection timed out
 
  Also, the log is full of:
  feb 10 09:33:04 pica systemd[1]: Looping too fast. Throttling
  execution a little.
 
  Seems like there is something wrong with systemd. Trying to look for
  an explanation, I've found people commenting on similar issues that
  were triggered by systemd crashes, but not exactly what I see.
 
  Going back in the log, the 'throttling' starts to appear after this:
  feb 09 02:15:01 pica
  /nix/store/8xg2yyyj651nik95lqmwza4xn0h7d7na-cron-4.1/bin/cron[24928]:
  (root) CMD (/nix/store/8iq0r1d7na-cron-4.1/bin/cron[24928]: (root) CMD
  (/nix/store/8iq0r1l97dzcsvkv33zg465gxlsx56dl-systemd-217/bin/systemctl
  start ul97dzcsvkv33zg465gxlsx56dl-systemd-217/bin/systemctl start
  update-locatedb.service)
 
  Though there's previous executions of that cron task that didn't
  trigger the issue.
 
  Any clues on what might be wrong and/or how to solve this?
  ___
  nix-dev mailing list
  nix-dev@lists.science.uu.nl
  http://lists.science.uu.nl/mailman/listinfo/nix-dev
 
  Might not at all be what you are looking for, but I had a similar
  problem
  with nixos-containers. It was 'solved' by telling sshd not to do any dns
  lookups with something like
 
 services = {
   openssh = {
 enable = true;
 extraConfig =
   ''
 UseDNS no
   '';
 };
 
  ___
  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

Re: [Nix-dev] DNS fails during nixos-install in Virtualbox

[Wout Mertens]

Well, after you forked the nixbox repo you didn't change anything that
would impact DNS resolution, so there must be an issue with something in
NixOS. Did you try building with 14.04 to confirm that it worked at some
point?

I think the least-effort way forward is doing a bisection, trying to build
various 14.04/14.11 versions until you find the set of changes that might
be the problem.

On Wed Feb 11 2015 at 2:15:47 AM Joe Hillenbrand joehil...@gmail.com
wrote:

 I would like to gently bump this issue:
 https://github.com/NixOS/nixpkgs/issues/6066

 I'm currently assigned the project to explore the possibility of replacing
 all our Puppet+Ubuntu infrastructure with NixOS at my work.

 We heavily use Vagrant for our configuration management development, so my
 first logical step was to create a Vagrant base image.

 My goal is to create an automatically updating NixOS Vagrant image to host
 and maintain on vagrantcloud.

 The issue is very easy to replicate. Just download the repo and run make
 (it does take a while though).

 I can't really make sense of what could be causing this. DNS works as soon
 as the nixos-install process finishes.

 A rerun of nixos-install after the failure allows the installation to
 finish, but I suspect it's not actually a successful install.

 Best Regards,

 -Joe Hillenbrand
 joehillen @ freenode




 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Please test Nix store auto-optimise

[Wout Mertens]

On Fri Feb 13 2015 at 3:27:19 PM Vladimír Čunát vcu...@gmail.com wrote:

 On 02/13/2015 12:10 PM, Wout Mertens wrote:
  So it's hard to say what the effect is generally, but the disk space
  saving is definitely there. If you are worried about seek times, you
  might want to turn on filesystem compression and run some sort of
  defragmentation if available.

 I don't think compression should decrease *seek* nontrivially (but it is
 another way to save space).


Yeah, I was more trying to make a point about I/O in general, but if the
overall footprint is smaller and the fs has defragging it will eventually
require somewhat less seeks to read the same working set. Trivial indeed.


 Once I wondered if using reflinks instead of hardlinks might be better
 from some point of view, but it probably won't be a big difference.


Well, in this specific case where the entire store is Write-Once, there is
no practical difference methinks...

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Please test Nix store auto-optimise

[Wout Mertens]

Well, it's in the nix-store library code so presumably that
nix-copy-closure passes through there. If you want to be sure, just run
nix-store --optimise -v and see if it finds anything to update.
Also, wow, 15GB saved :)

On Fri Feb 13 2015 at 6:43:05 PM Richard Wallace 
rwall...@thewallacepack.net wrote:

 Thank you for pointing this option out! I had no idea it existed before
 and it should prove very useful!

 $ du -hs /nix/store/
 38G /nix/store/
 $ sudo nix-store --optimise -v
 snip
 12456.46 MiB freed by hard-linking 881561 files
 $ du -hs /nix/store/
 23G /nix/store/

 Does the auto linking also happen if you use nix-copy-closure?

 Rich

 On Thu, Feb 12, 2015 at 3:47 AM, Wout Mertens wout.mert...@gmail.com
 wrote:

 Hi all,

 (TL;DR: regain disk space, see at the bottom for instructions)

 the Nix store can be optimised by hard-linking files with the same
 contents together, so they are only stored once. This is done by reading
 all the files in your store, calculating their checksums and linking them
 to /nix/store/.links/*[checksum]*. This is especially useful in Nix
 where differing build inputs for a package end up with many of the same
 files.

 Nix 1.8 has a few optimizations that make this operation very fast if you
 run it multiple times. Nix also has the auto-optimise-store setting, which
 will link new files added to the store. If your store was optimised, it
 stays optimised.

 I feel this optimisation should be turned on by default but there were
 some regressions in the past which is why it wasn't. Therefore I'd like to
 ask you to turn on auto-optimise and run optimisation once. Your disk space
 and memory footprint will thank you.

 Advantage:
 - Use less disk space and memory cache
 Disadvantages:
 - Need to checksum all files written to the store
   * this is fast while writing the files because they still are in cache
 - /nix/store/.links can get very large
   * a decent filesystem should handle it
   * E.g. ext3, ext4, btrfs, zfs etc should have no problems

 Hopefully this will prove that it's safe to use and Hydra will start
 using it, which should give it tons more headroom for builds.

 *How to enable*:
 - Run du -hs /nix/store to see how much you're using

 - If you use nixpkgs, put
 auto-optimise-store = true
 in /etc/nix/nix.conf and run nix-store --optimise -v.
 - If you use NixOS, put
 nix.extraOptions = auto-optimise-store = true;
 in your configuration.nix and, as root, run
 nixos-rebuild switch and nix-store --optimise -v.

 - Run du -hs /nix/store to see how much you regained

 It is safe to interrupt the optimisation. It is also safe to clear out
 /nix/store/.links but this will result in more work on the next
 optimisation run.

 Please report any issues you encounter, and it would be nice if you reply
 to this mail in a while to report that you have encountered no issues.

 Cheers,

 Wout.

 PS: Optimise is the British spelling, nix-store also has --optimize but
 not auto-optimize-store :)

 ___
 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] Please test Nix store auto-optimise

[Wout Mertens]

Hi all,

(TL;DR: regain disk space, see at the bottom for instructions)

the Nix store can be optimised by hard-linking files with the same contents
together, so they are only stored once. This is done by reading all the
files in your store, calculating their checksums and linking them to
/nix/store/.links/*[checksum]*. This is especially useful in Nix where
differing build inputs for a package end up with many of the same files.

Nix 1.8 has a few optimizations that make this operation very fast if you
run it multiple times. Nix also has the auto-optimise-store setting, which
will link new files added to the store. If your store was optimised, it
stays optimised.

I feel this optimisation should be turned on by default but there were some
regressions in the past which is why it wasn't. Therefore I'd like to ask
you to turn on auto-optimise and run optimisation once. Your disk space and
memory footprint will thank you.

Advantage:
- Use less disk space and memory cache
Disadvantages:
- Need to checksum all files written to the store
  * this is fast while writing the files because they still are in cache
- /nix/store/.links can get very large
  * a decent filesystem should handle it
  * E.g. ext3, ext4, btrfs, zfs etc should have no problems

Hopefully this will prove that it's safe to use and Hydra will start using
it, which should give it tons more headroom for builds.

*How to enable*:
- Run du -hs /nix/store to see how much you're using

- If you use nixpkgs, put
auto-optimise-store = true
in /etc/nix/nix.conf and run nix-store --optimise -v.
- If you use NixOS, put
nix.extraOptions = auto-optimise-store = true;
in your configuration.nix and, as root, run
nixos-rebuild switch and nix-store --optimise -v.

- Run du -hs /nix/store to see how much you regained

It is safe to interrupt the optimisation. It is also safe to clear out
/nix/store/.links but this will result in more work on the next
optimisation run.

Please report any issues you encounter, and it would be nice if you reply
to this mail in a while to report that you have encountered no issues.

Cheers,

Wout.

PS: Optimise is the British spelling, nix-store also has --optimize but not
auto-optimize-store :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Unstable Nixpkgs on stable NixOS (was: Automatically locking the screen with xautolock)

[Wout Mertens]

Your setting NIX_PATH to `nixpkgs=~/.nix-defexpr/channels/nixpkgs` makes a
lot of sense to me and I wouldn't mind it being the default for users...

In general though the whole home dir setup could use some love. There's
.nix-defexpr/, .nix-channels, .nix-profile@ and .nixpkgs/config.nix, where
it would be a lot cleaner to have everything under ~/.nix/ and on OS X
those should really be under ~/Library/Nix/.

Even nicer would be if everything (except the profile) defaulted to the
system-wide versions until the user takes an action like choosing a channel
or running nix-env. Then the user should get some warnings about getting
user-stored versions and everything gets set up automatically. Basically
making
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/programs/shell.nix#L23-L62
lazy.

Wout.

On Tue Feb 10 2015 at 4:18:06 AM Michael Alyn Miller ma...@strangegizmo.com
wrote:

 The 02/08/2015 12:21, Jeffrey David Johnson wrote:
  Nice! I'm currently binding gksu 'i3lock -c00 
  pm-suspend' to a hotkey using i3, but this is better.  Is
  there a standard way to get it in my fork of nixpkgs, which is
  tracking the release-14.12 branch?  (I could just copy and
  paste but if there's a better way now would be a good time to
  learn.)

 I certainly don't have an authoritative answer to this question,
 but I'll tell you what I am doing and then maybe someone with
 much more NixOS/Nixpkgs experience will chime in with
 tweaks/guidance.

 In general I have the following goals for my NixOS system:

 1. I want everything to be reproducible, which of course means that my
system is configured in /etc/nixos/configuration.nix, but also that
any packages that I install as an individual user are reproducible as
well.
 2. Related to the above, I only want to put system packages into
configuration.nix.  My theory here is that most of my package
management is going to be done as a regular user, by creating
project-specific nix-shell environments, etc.  Also, `nix-env -q` is
a nice way to see everything that is installed and it doesn't appear
that similar tools exist at the NixOS level.

 Goal #1 means that configuration.nix is pretty basic -- the bare minimum
 number of packages to get my system working and launch an X environment
 (the window manager, for example, but no apps).

 Goal #2 was more complex.  I found the following two references on this
 topic:

 - https://nixos.org/wiki/FAQ#How_can_I_manage_software_
 with_nix-env_like_with_configuration.nix.3F
 - https://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once

 I went with the first option because I wanted to be able to use `nix-env
 -q` to see what I had installed, regardless of how I did the install
 (manually or through the myPackageSelections.nix file).  I can provide
 more details here if you like.

 With that choice out of the way, the next problem that I ran into was
 getting access to newer packages.  I have contributed a couple of
 packages to Nixpkgs, fixed some others, etc. and so far I had just been
 manually installing them out of my nixpkgs checkout.  This was not
 entirely compatible with my first goal, because now I had installed
 packages that were not listed in my configuration.

 Enter the nixpkgs-unstable channel!  That channel seems to be updated
 pretty frequently and means that changes are available in binary form
 within a few days.  Thankfully my second goal meant that I already had a
 perfect split between stable and unstable: my NixOS configuration could
 stay on 14.12 and my user-level Nixpkgs was free to go unstable.

 Getting this working was relatively straightforward, although I had to
 modify my environment in a couple of unexpected ways (more on this
 later).

 The simple part is the `nix-channel --add https://nixos.org/channels/
 nixpkgs-unstable` https://nixos.org/channels/nixpkgs-unstable
 and `nix-channel --update` as a normal user.  Some things worked after
 that, but not everything.  `nix-env -i whatever` will happily use the
 nixpkgs-unstable channel because it finds that channel in ~/.nix-defexpr.
 Adding in the -f flag to specify your own expression means that nix-env
 no longer knows about the channel though.  Instead, nix-env falls back
 to NIX_PATH, which by default points at the stable NixOS channel and
 therefore has no idea that you want to use nixpkgs-unstable.

 I found that very confusing, although that's probably because of the
 subtlety that is the myPackageSelections.nix-based way of managing my
 package list.  In any event, I had to dig through the docs to understand
 the situation.

 I fixed this problem by setting NIX_PATH to `nixpkgs=~/.nix-defexpr/
 channels/nixpkgs`
 and removing the channels_root symlink from ~/nix-defexpr.  That last
 step probably isn't necessary, but every now and then nix-env would
 complain about duplicate packages and besides that I don't want to get
 (user) packages out of the stable NixOS channel anyway.

 This all seems 

Re: [Nix-dev] A few questions about ARM support and NixOS on a Chromebook

[Wout Mertens]

There's another option : build natively with distcc pointing to
cross-compilers on x86 boxes. All the configuration etc happens natively
and the compiles themselves are sped up. I wonder if that's the approach
Vladimír Čunát took earlier? He made the notes on how to set up distcc for
raspberry pi on the wiki iirc.

Yet another option : run the above option in qemu, running the whole thing on
an x86 box with the heaviest lifting done natively.

These only speed up C/C++ of course.

Wout.

On Mon, Feb 9, 2015, 5:01 PM Harald van Dijk har...@gigawatt.nl wrote:

 On 09/02/2015 15:57, James Haigh wrote:

 On 09/02/15 14:16, Harald van Dijk wrote:

 On 09/02/2015 14:55, James Haigh wrote:

 On 28/01/15 07:42, Luke Clifton wrote:

 Hi Bjørn,

  I have read that thread. I agree with you 100% that native builds (on
 real or virtual hardware) is the only way this can work. Upstream doesn't
 usually care if their software can cross compile, and they can't maintain
 it themselves even if they did. Sometimes it isn't even an option, e.g. GHC
 still can't cross compile template Haskell yet.

 I don't understand why cross-compilation is even a thing, other than
 decades of false assumptions being baked into compilers.
 As I understand, if a compiler (and by ‘compiler’ I'm referring to the
 whole toolchain required for compilation) is taking source code and
 compilation options as input, and giving object code for the specified
 platform as output, it is called ‘cross-compiling’ if the specified target
 platform is different to the platform that the compiler is running on. If
 GCC is running on ARM, compiling code ‘natively’ to ARM successfully, it is
 counterintuitive that it would fail to build for ARM if GCC is running on
 x86. And vice versa. A compiler should produce object code for a target
 platform that implements the source code – it may not have the same
 efficiency as the output of other compilers (or with other compilation
 options), but should have the same correctness when execution completes. If
 the source code being compiled is a specific version of the GCC source code
 itself, and it is compiled for both x86 and ARM, then if the compilation is
 computationally correct, both compilations of GCC should produce programs
 that, although will compute in a different way and with different
 efficiency, should give the exact same object code when given the same
 source code and parameters. So if the target platform parameter is ARM,
 they should both build exactly the same ARM machine code program.

 All of this is true, but the toolchain usually doesn't have any problems
 with cross-compilations.

 However, evidently this is not the case unfortunately. So the
 compilers or their toolchains are, in essence, receiving the platform that
 they are running on as ‘input’ to the build, and making assumptions that
 this build platform has something to do with the target platform. I.e. they
 are _aware_ of the platform that they're building on, whereas
 theoretically, they shouldn't be. Apparently this has a lot to do with
 configure scripts.

 The configure scripts, or similar machinery in non-autoconf packages, are
 part of the package, not part of the toolchain. Many programs use runtime
 checks in configure scripts. A trivial example that hopefully doesn't exist
 in any real package:

 If a package only compiles on platforms where sizeof(int) == 4, or where
 special code is needed on platforms where sizeof(int) != 4, might try to
 detect those platforms by compiling and linking

 int main(void) {
   return sizeof(int) != 4;
 }

 and then executing it. If the execution succeeds (i.e. returns zero), then
 sizeof(int) == 4. If the execution doesn't succeed, then the configure
 script assumes that sizeof(int) != 4, even though it's very well possible
 that the only reason that execution fails is that the generated executable
 is for a different platform.

 Other examples are build environments that build generator tools at
 compile time, and run them to produce the source files to compile at run
 time. The generator tool must be compiled with the build compiler, not with
 the host compiler, or execution will fail when cross-compiling. Still, many
 packages build such tools with the host compiler anyway, because upstream
 only tests native compilations. This too is not an issue with the toolchain.

 But what I'm saying is that if the package succeeds in compiling natively
 but fails to cross-compile, then this is an issue with the
 compiler/toolchain. Yes it can be solved by writing configure scripts that
 support cross-compiling, but really, the compiler toolchain should isolate
 this such that the compilation is deterministic regardless of build
 platform.
 In your example, I'm saying that it should be the job of the compiler
 toolchain to ensure that ‘sizeof(int) == 4’ gives the correct result for
 the target platform. If the only feasible way to do this deterministically
 is to run the configure scripts 

[Nix-dev] Linux config options

[Wout Mertens]

Just wondering out loud with probably no actionable change:

Why are the kernel options implemented as strings (FOO y) instead of an
attribute set ({ foo = y: })?

Of course that means you can easily import your own .config file as
described at https://nixos.org/wiki/How_to_tweak_Linux_kernel_config_options,
but would an attribute set not allow things like if the kernel has this
feature enabled, install this package or if you enable this module the
kernel must have foo set to one of these values?

Plus, having to convert your own .config file to an attribute set enables
you to only mention the options that you actually care about, thus easily
merging with the default configs in the future.

Thoughts?

Wout.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Announcing New Ruby Support

[Wout Mertens]

rb_enc_raise seems to be a ruby 2.0 thing and you're using 1.9.3. Some
mixup somewhere?
https://bugs.ruby-lang.org/issues/5650 was when it was added to 2.0 3 years
ago...


On Tue Feb 10 2015 at 11:05:56 PM Cillian de Róiste 
cillian.deroi...@gmail.com wrote:

 2015-02-10 19:25 GMT+01:00 Cillian de Róiste cillian.deroi...@gmail.com:
 
  Hi!
 
  I thought I'd try to package jekyll, but I've run into some trouble...
 
  2015-01-22 5:29 GMT+01:00 Charles Strahan charles.c.stra...@gmail.com:
 
  To use the new system, first create (or copy over) a Gemfile describing
 the
  required gems.
 
 
  I grabbed the Gemfile from the github repo:
  $ wget https://raw.githubusercontent.com/jekyll/jekyll/master/Gemfile
 
 
  Next, create a Gemfile.lock by running `bundler package --no-install`
 in the
  containing directory (this also creates two folders - vendor and
 .bundle -
  which you'll want to delete before committing).
 
 
  I had first installed pkgs.bundler, which got me version 1.7.9, which
 doesn't have the --no-install option which seems to have been added in 1.8.
 I then installed pkgs.bundler_HEAD which also reports the version to be
 1.7.9 but does have the --no-install option. However, I got stuck on the
 next step:
 
  $ bundler package --no-install
  There are no gemspecs at /home/goibhniu/ruby/jekyll.

 The second line has the word gemspec, I commented it out and was
 able to get further

 I ran `bundler package --no-install --path vendor/bundle` which
 successfully created lockfile.

  Now, you'll need to dump the lockfile as a Nix expression. To do so,
 use Bundix
  in the target directory:
 
$(nix-build 'nixpkgs' -A bundix)/bin/bundix

 To avoid rebuilding the world I checked out 317d78d and tried to
 install bundix from there. I had to patch the hash for bundix and
 bundler [1], but then I was able to install bundix and create the
 gemset.nix \o/

 
  That will drop a gemset.nix file in your current directory, which
 describes the
  sources for all of the gems and their respective SHAs.
 
  Finally, you'll need to use bundlerEnv to build the gems. The following
 example
  is how we package the sup mail reader:


 I copied the example nix expression, changed the name and added it to
 all-packages.nix to build it. All went quite well until I got the
 following error:

 ...
 Installing liquid 3.0.1

 Gem::Ext::BuildError: ERROR: Failed to build gem native extension.

 /nix/store/wdjnbdyrvsfbg245qyp3r7qwhlhxzd
 1c-ruby-1.9.3-p547/bin/ruby
 -r ./siteconf20150210-115-km0s7e.rb extconf.rb
 creating Makefile

 make  clean
 building clean-static
 building clean

 make
 building lexer.o
 compiling lexer.c
 lexer.c: In function 'lex_one':
 lexer.c:143:5: error: implicit declaration of function
 'rb_enc_raise' [-Werror=implicit-function-declaration]
  rb_enc_raise(utf8_encoding, cLiquidSyntaxError, Unexpected
 character %c, c);

 IIUC it fails to find some ruby header file. Any tips on how to proceed?

 Cheers,
 Cillian


 Patches [1]:

 diff --git a/pkgs/development/interpreters/ruby/bundix/gemset.nix
 b/pkgs/development/interpreters/ruby/bundix/gemset.nix
 index a2c633f..a3e732c 100644
 --- a/pkgs/development/interpreters/ruby/bundix/gemset.nix
 +++ b/pkgs/development/interpreters/ruby/bundix/gemset.nix
 @@ -6,7 +6,7 @@
url = https://github.com/cstrahan/bundix.git;;
rev = 5df25b11b5b86e636754d54c2a8859c7c6ec78c7;
fetchSubmodules = false;
 -  sha256 = 0334jsavpzkikcs7wrx7a3r0ilvr5vsnqd34lhc58b8cgvgll47p;
 +  sha256 = 1iqx12y777v8gszggj25x0xcf6lzllx58lmv53x6zy3jmvfh4siv;
  };
  dependencies = [
thor
 diff --git a/pkgs/development/interpreters/ruby/bundler-head.nix
 b/pkgs/development/interpreters/ruby/bundler-head.nix
 index 2e8cfc8..43a5961 100644
 --- a/pkgs/development/interpreters/ruby/bundler-head.nix
 +++ b/pkgs/development/interpreters/ruby/bundler-head.nix
 @@ -5,7 +5,7 @@ buildRubyGem {
src = fetchgit {
  url = https://github.com/bundler/bundler.git;;
  rev = a2343c9eabf5403d8ffcbca4dea33d18a60fc157;
 -sha256 = 1l4r55n1wzr817l225l6pm97li1mxg9icd8s51cpfihh91nkdz68;
 +sha256 = 1fywz0m3bb0fmcikhqbw9iaw67k29srwi8dllq6ni1cbm1xfyj46;
  leaveDotGit = true;
};
dontPatchShebangs = true;


 --
 NixOS: The Purely Functional Linux Distribution
 http://nixos.org
 ___
 nix-dev mailing list
 nix-dev@lists.science.uu.nl
 http://lists.science.uu.nl/mailman/listinfo/nix-dev

___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Please test NixOS/nixpkgs.git on darwin

[Wout Mertens]

I see that the darwin machine butters is online (and idle) in Hydra, does
that mean the zalora cache is no longer needed for nixpkgs on Darwin?

On Tue Feb 03 2015 at 3:51:47 PM Domen Kožar do...@dev.si wrote:

 :beers:

 On Tue, Feb 3, 2015 at 3:40 PM, Shea Levy s...@shealevy.com wrote:

 Hi all,

 For a while now, there has been a lot of work to improve darwin support
 on the master branch of joelteon’s nixpkgs fork. With the latest staging
 merge, the core of that work is now on upstream master. The rest of the
 changes available on joelteon’s fork are very disparate, and it is not
 clear whether or why they are all needed, so I’d like to request that those
 who have been working off of the fork test their setups against upstream
 now. If something is still not working, please at least open an issue, but
 if you can find the relevant fix on the fork and port it as a PR that would
 be greatly appreciated.

 Hopefully we can soon move on from that fork entirely and have further
 changes (including the ongoing pure-darwin work) done directly against
 upstream master.

 Thanks,
 Shea
 ___
 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