Re: [Nix-dev] Will there be a systemd replacement at any time inthe future?

FWIW we've also had problems with logging to stdout not being captured. Luckily these were all internal apps and we could fix the bug of logging to stdout instead of stderr, but IMO it's also a bug that journald didn't capture it. ~Shea On Tue, Sep 02, 2014 at 02:28:34AM +0400, Michael Raskin wro

Re: [Nix-dev] NixOS on Azure?

Hi Ross, Am I reading [1] correctly that Azure VMs are started from VHDs? If so, we already have a function for creating virutalbox images that converts a raw image containing a base NixOS system to VDI using qemu-img, so it should be straightforward to tweak that to create a VHD instead. [1]: h

Re: [Nix-dev] NixOS on Azure?

route you propose, > so can't promise it will work. Certainly worth a try though. > > Sent from my Windows Phone > ____ > From: Shea Levy<mailto:s...@shealevy.com> > Sent: ‎9/‎5/‎2014 3:58 PM > To: Ross Gardler (MS OPEN TECH

Re: [Nix-dev] dvdisaster: new package

Applied, thanks! On Mon, Sep 08, 2014 at 03:29:56AM +0200, Anonymous wrote: > dvdisaster: new package > --- > > diff --git a/pkgs/tools/cd-dvd/dvdisaster/default.nix > b/pkgs/tools/cd-dvd/dvdisaster/default.nix > new file mode 100644 > index 000..b54f342 > --- /dev/null > +++ b/pkgs/tools/cd

Re: [Nix-dev] pypoppler: new package

This patch does not apply cleanly, can you resubmit? ~Shea On Mon, Sep 08, 2014 at 04:32:30AM +0200, Anonymous Remailer (austria) wrote: > > pypoppler: new package > --- > > diff --git a/pkgs/development/python-modules/pypoppler-more-tweaking.patch > b/pkgs/development/python-modules/pypoppler

Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?

fetchurl does depend on the base name, it's the nixos tarball mirror that doesn't Original message From: Bjørn Forsman Date:09/20/2014 12:11 PM (GMT-08:00) To: Vladimír Čunát Cc: nix-dev Subject: Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its

Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?

I suppose a flag that says to rebuild if the output is valid but doesn't have the right deriver could be what you want? But for now the best answer seems to be "change the hash when it needs to change" Original message From: Bjørn Forsman Date:09/21/2014 9:37 AM (GMT-08:00)

[Nix-dev] Announcing nix-exec

Hi all, I've just added [1] nix-exec to nixpkgs. It provides a way to define and execute programs written in nix, for programs that need to interact with the nix store or expression language. Please see the home page [2] for more details. Please note that this was a quick project, and that there

Re: [Nix-dev] nix proposal for security fixes

Yes, this is exactly what replaceDependency is for. On Sun, Sep 28, 2014 at 02:58:03PM -0700, rocon...@theorem.ca wrote: > We already have shlevy's "replaceDependency" which, IMHO, solves this > problem. > > In functional programming when we have an immutable tree structure that we > want to upda

Re: [Nix-dev] Bash CVE-2014-6271

The dry-run thing is likely due to replaceDependency doing an import from a derivation, which requires building at evaluation time. There's not really a good way to work around that, unfortunately. ~Shea On Mon, Sep 29, 2014 at 12:52:10AM +0200, Ricardo M. Correia wrote: > On Sun, Sep 28, 2014 at

Re: [Nix-dev] Announcing nix-exec

project no problem. > > Thanks, > > Wout. > > > On Sun, Sep 28, 2014 at 9:28 PM, Shea Levy wrote: > > > Hi all, > > > > I've just added [1] nix-exec to nixpkgs. It provides a way to define and > > execute programs written in nix, for programs that

Re: [Nix-dev] Bash CVE-2014-6271

;Isn't this happening to anyone else who is using a recent commit from the > >unstable/master channel? > > > >On Mon, Sep 29, 2014 at 2:12 AM, Shea Levy wrote: > > The dry-run thing is likely due to replaceDependency doing an import > > from a deriv

Re: [Nix-dev] Concurrent garbage collection

Check out https://github.com/NixOS/nix/blob/master/src/libstore/gc.cc, particularly addTempRoot (which is called by nix before any new nix path is written or considered valid) and openGCLock. The answer to "what happens" is that invariants are preserved, though possibly at the cost of a long wait.

Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?

On Wed, Oct 01, 2014 at 10:32:57AM +0200, Bjørn Forsman wrote: > On 27 September 2014 11:12, Vladimír Čunát wrote: > > On 09/24/2014 09:58 PM, Bjørn Forsman wrote: > >> > >> On 22 September 2014 17:16, Shea Levy wrote: > >>> > >>> I suppose a f

Re: [Nix-dev] Moving some of the NixOS setup to nixpkgs

Hey all, I've only briefly browsed through the thread, so maybe this is repetitive, but I think whatever we do here we should separate out the "raw" package from the tool that configures the environment for it, so that the package can be composed in different ways without the overhead of the wrapp

Re: [Nix-dev] Reconsidering dash in package names

In my experience, the majority of scripts in nixpkgs either put dependend packages in buildInputs or interpolate them directly into scripts; adding a package directly as an env var is rare. Why is this worth giving up the superior readability and fidelity to actual package name provided by dashes?

Re: [Nix-dev] Reconsidering dash in package names

On Sat, Oct 11, 2014 at 03:09:37PM +0200, Vladimír Čunát wrote: > On 10/11/2014 02:55 PM, Shea Levy wrote: > >In my experience, the majority of scripts in nixpkgs either put > >dependend packages in buildInputs or interpolate them directly into > >scripts; adding a package d

[Nix-dev] Announce: nix-exec 1.1.0

Hi all, I'm happy to announce the release of nix-exec-1.1.0 [1]. This version adds an unsafe-perform-io.nix nix expression that can be imported to run nix-exec IO values in contexts where you can't call nix-exec directly (e.g. when using nixops). Happy hacking! ~Shea [1]: https://github.com/shl

[Nix-dev] Tweak to baseNameOf semantics (POTENTIAL BREAKING CHANGE)

Hi all, I've just opened a pull request [1] to change the baseNameOf primop to not copy paths to the store before returning their base name. Essentially, this means that (baseNameOf ./foo) will return "foo" and not "somenixhash-foo" (or, worse, failure if foo does not exist). In my opinion this is

Re: [Nix-dev] Is systemd a benefit or a liability?

On Sun, Oct 19, 2014 at 03:09:15PM +0200, Eelco Dolstra wrote: > Hi, > > On 19/10/14 13:30, Nathan Bijnens wrote: > > > It's not all quiet at other Distro's, some Debian developers are considering > > forking Debian if Debian switches to SystemD: http://debianfork.org/ > > > > I like some of the

Re: [Nix-dev] About 14.11 release

14.11 is due 11/31 :) On Wed, Oct 22, 2014 at 05:35:59PM +0200, Luca Bruno wrote: > I appreciate the work being done by Domen and jumping in as release manager. > I'd like to point out a few things however about the milestone issues. > The release should be due for October 31th, and in my vision t

[Nix-dev] nix-exec 2.0.0 released

Hi all, I'm proud to announce the release of nix-exec 2.0.0. From the release notes [1]: * unsafe-perform-io now just takes an IO value directly, instead of expecting a function matching the top-level entry point signature * nix-exec's compile-time settings are now accessible from lib instead

Re: [Nix-dev] nix-exec 2.0.0 released

t; On Fri, Oct 24, 2014 at 11:10 PM, Shea Levy wrote: > > > Hi all, > > > > I'm proud to announce the release of nix-exec 2.0.0. From the release > > notes [1]: > > > > * unsafe-perform-io now just takes an IO value directly, instead of > >

Re: [Nix-dev] Zero Hydra Failures (ZHF) project for NixOS

On Sat, Oct 25, 2014 at 05:45:34PM +0200, Nicolas Pierron wrote: > We have 2 solution, either we stop the regressions when a pull request > (PR) is made, or we stop it when the fire is in. The fireman role is > hard to keep, and we should be verifying as much as possible at the PR > time. Also, i

Re: [Nix-dev] Make wrappers be binaries instead of shell scripts?

Some time ago I had an idea for a ‘wrapper interpreter’, seems like execline might be similar. No reason we can’t have such a thing. > On Nov 18, 2014, at 9:02 AM, Thomas Tuegel wrote: > > On Tue, Nov 18, 2014 at 7:32 AM, Wout Mertens wrote: >> Hi all, >> >> I'm wondering if it wouldn't be be

Re: [Nix-dev] Making Nix use pivot_root in addition to chroot

Daniel Peebles (copumpkin) also has some ongoing work to use darwin sandboxes for pure builds on OS X. Perhaps we should try to generalize the interface for these things? > On Dec 5, 2014, at 2:45 PM, Luca Bruno wrote: > > Not a nix dev, but I think by adding an option to nix.conf to use pivot

Re: [Nix-dev] Making Nix use pivot_root in addition to chroot

Couldn't we either a) mount our chroot over / instead of doing a chroot or b) do the chroot *after* the new user namespace? Sent from my iPhone > On Dec 5, 2014, at 4:05 PM, Eelco Dolstra wrote: > > Hi, > >> On 04/12/14 12:24, Harald van Dijk wrote: >> >> Is there any interest in getting som

Re: [Nix-dev] Using ccache without changing stdenv hash?

ccache is impure and thus should not be used for hydra. > On Dec 9, 2014, at 5:28 PM, Wout Mertens wrote: > > Hi all, > > there is some support for ccache in the tree but nothing in the way of > documentation. I gave it a shot, see > https://github.com/NixOS/nixpkgs/issues/2387#issuecomment-6

Re: [Nix-dev] Using ccache without changing stdenv hash?

compiles, no? > > However, it is still useful for development but not if using it means > rebuilding the world on your laptop... So I'd like to at least offer the > option for development. > > Wout. > > On Tue Dec 09 2014 at 6:32:04 PM Shea Levy <mailto:s...@sh

Re: [Nix-dev] Using ccache without changing stdenv hash?

s > rebuilding the world on your laptop... So I'd like to at least offer the > option for development. > > Wout. > > On Tue Dec 09 2014 at 6:32:04 PM Shea Levy <mailto:s...@shealevy.com>> wrote: > ccache is impure and thus should not be used for hydra. > &

[Nix-dev] New darwin binary cache from Zalora

Hi all, My employer, Zalora, has made our darwin binary cache http://zalora-public-nix-cache.s3-website-ap-southeast-1.amazonaws.com publicly accessible. It is populated from our private hydra, and currently contains builds from git://github.com/joelteon/nixpkgs.git. Once darwin builds are fixe

Re: [Nix-dev] Haskell NG

Not related to your central goals (which are awesome), but can we take this opportunity to dashify attribute names as well? > On Dec 12, 2014, at 2:38 PM, Peter Simons wrote: > > Hi guys, > > in the spirit of "release early, release often", I'd like to inform everyone > with an interest in the

Re: [Nix-dev] Haskell NG

> On Dec 12, 2014, at 11:19 PM, Marc Weber wrote: > >> - hackage-packages.nix is generated automatically by the "hackage2nix" >> utility >> from the "v2.x" branch of the cabal2nix repository [2]. The file defines >> builds for the respective latest version of every Hackage package. >> hac

Re: [Nix-dev] Haskell NG

Nice! Then this branch has my full support ;) > On Dec 14, 2014, at 6:40 PM, Peter Simons wrote: > > Hi Shea, > >> Can we take this opportunity to dashify attribute names as well? > > it's already done. :-) All attributes in [1] match the name of the > package. The file [2] implements an (opti

Re: [Nix-dev] Why can't Nix find my C++ compiler? (Mac OS X)

> On Dec 16, 2014, at 5:45 PM, Rico Huijbers wrote: > > Hi, > > I'm new to Nix, and kicking the tires. > > Right now, I'm trying to compile dmd (the D compiler) using Nix, but when I > try to compile it, it can't seem to find my C++ compiler: > > rix0rrr@moloch ~/D/n/nixpkgs(master)> nix

Re: [Nix-dev] Avoiding threads in the daemon

Can't you unshare in the parent then setns back after fork? > On Dec 19, 2014, at 18:20, Eelco Dolstra wrote: > > Hi, > >> On 18/12/14 17:32, Ludovic Courtès wrote: >> >> Thus, I think Nix commit 49fe95 (which introduces monitor-fd.hh, which >> uses std::thread just for convenience) should b

Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))

Hi all, At Zalora, we are gradually switching to using defnix . It is still very much under active development (read: may change at any time), and the underlying implementation does use systemd, but the service/functionality interface (check out the defnixos d

Re: [Nix-dev] Why does fetchgit not look at the URL to determine the cache location?

> On Jan 1, 2015, at 1:22 PM, Bjørn Forsman wrote: > > On 31 December 2014 at 17:50, Rico Huijbers wrote: >> Hi, >> >> When I copy/paste a fetchgit block from another file, and change the URL and >> rev without changing the hash, I expect the download to fail (and tell me >> the hash). >> >

Re: [Nix-dev] Why does fetchgit not look at the URL to determine the cache location?

This PR should make this problem better (though it won’t handle the ‘rev changed but url didn’t’ case) https://github.com/NixOS/nixpkgs/pull/5521 <https://github.com/NixOS/nixpkgs/pull/5521> > On Jan 1, 2015, at 1:27 PM, Shea Levy wrote: > > >> On Jan 1, 2015, at 1

Re: [Nix-dev] Request for comments: pinky-promise determinism

For dirty dirty hacks, you can set __noChroot = true and get access to the network. > On Jan 2, 2015, at 1:09 PM, Georges Dubus wrote: > > Hello everyone > > I would like to propose compromise in the purity rules of non-fixed-output > derivations, and hear what you think about it. > > # Rati

Re: [Nix-dev] Announce list?

Definitely a good idea. > On Jan 7, 2015, at 4:19 AM, Martin Bravenboer > wrote: > > Hi all, > > Would it be a good idea to create a mailing list for announcements only? > > It would be nice if people who want to follow releases or major events can > sign up for an email list with low traffi

[Nix-dev] Backporting haskell-ng to 14.12

Hi all, I’d like to make a case for backporting Peter’s haskell-ng work to 14.12 once it’s merged into master. If I understand correctly, then if a haskell package’s version (and the versions of its dependency closure) stay the same, the haskell-ng branch will result in what is effectively the

Re: [Nix-dev] Backporting haskell-ng to 14.12

Ah, actually I see Peter already brought haskell-ng into master via the haskellngPackages attribute. So I’ll just backport that, as it won’t touch any existing haskellPackages stuff. Never mind! > On Jan 8, 2015, at 1:07 PM, Shea Levy wrote: > > Hi all, > > I’d like to

Re: [Nix-dev] Backporting haskell-ng to 14.12

of repeated work ? > Aloha, > RK. > > On Thu, Jan 8, 2015 at 11:59 PM, Shea Levy <mailto:s...@shealevy.com>> wrote: > Ah, actually I see Peter already brought haskell-ng into master via the > haskellngPackages attribute. So I’ll just backport that, as it won’t touch >

Re: [Nix-dev] Stumped trying to build Idris with mtl_2_2_1

Hi Paul, With the current haskell infrastructure, it is difficult-to-impossible to properly override a core package, and due to the transformers dependency updating mtl amounts to doing just that. However, there has been recent work on haskellng, which is a new haskell infrastructure that, amon

Re: [Nix-dev] Using Nix with external (but 'pure') dependencies

If icc has the same command line interface as gcc, in principle it should work. > On Jan 14, 2015, at 6:40 PM, Ben Darwin wrote: > > We could try to compile with ICC instead if that would be the only > thing we'd have to cp/patchelf. Is it likely we could re-use library > derivations with { cc

Re: [Nix-dev] Multiple instances - detecting resource collisions - nixos module system question

My prediction: This will cause more headaches than it will save. > On Jan 14, 2015, at 10:17 PM, Marc Weber wrote: > > If you use multiple apaches/nginx/mysql/postgresql/whatever instances > its likely to miss adjusting the port or whatsoever. Therefore I'd like > to implement a simple "resource

Re: [Nix-dev] environment.allowedLicenses ?

My only interest in this is ensuring that there’s a single switch to be able to say “install whatever I ask for”, in general though this sounds like a good idea. > On Jan 21, 2015, at 8:15 PM, Matthias Beyer wrote: > > On 21-01-2015 21:08:14, Jascha Geerds wrote: >> Hi, >> >> On Wed, Jan 21,

[Nix-dev] Reducing haskell closures with multiple outputs

Hi Peter, Have you looked into how we could make haskell closures smaller with multiple outputs? At the very least separating ghc’s shared libs from the compiler should be a big win, but ideally we would also separate bin and lib for haskell packages as well. ~Shea

Re: [Nix-dev] Reducing haskell closures with multiple outputs

OK, I’ll take a look at this then, thanks! > On Jan 28, 2015, at 11:08 AM, Peter Simons wrote: > > Hi Shea, > >> Have you looked into how we could make haskell closures smaller with >> multiple outputs? > > I briefly thought about it, but I haven't put any actual effort into the > subject yet.

[Nix-dev] Pause on staging?

Hi all, There are some important changes on staging that would help make the darwin stdenv much more usable on master, but hydra is pretty far behind. Can we have a brief freeze on non-bugfix changes to staging until it’s caught up and merged? Thanks, Shea __

Re: [Nix-dev] Use Haskell for Shell Scripting

Yes, I’m planning to work on multiple outputs for ghc soon :) > On Jan 31, 2015, at 3:55 PM, Daniel Peebles wrote: > > Yeah, was kidding around! > > > > On Jan 31, 2015, at 10:47, Ertugrul Söylemez wrote: > >>> If only we had a way to produce multiple outputs from a single >>> package... :)

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

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

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

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 <mailto:do...@dev.si>> wrote: > :beers: > > On Tue, Feb 3, 2015 at 3:40 PM,

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

ould fast-track the pure-darwin builds. It works swimmingly on > my system, and looks like the current Darwin situation is not tenable. So > anything in pure-darwin that breaks Linux would be good to find early. > > On Tue Feb 03 2015 at 4:00:48 PM Shea Levy <mailto:s...@sheale

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

rge more easily. > > Want to talk this evening (probably won't be home until 10:30 eastern) on > ##nix-Darwin about specifics? I need people to help break out individual > parts (e.g., clang) > > Thanks, > Dan > > > On Feb 3, 2015, at 10:13, Shea Levy <

Re: [Nix-dev] Can we please have text-only on this ML?

I think the muttrc setting you want is “alternative_order”, e.g. "alternative_order text/plain text/html" > On Feb 6, 2015, at 2:05 PM, Matthias Beyer wrote: > > On 06-02-2015 15:03:29, Lluís Batlle i Rossell wrote: >> On Fri, Feb 06, 2015 at 02:57:46PM +0100, Matthias Beyer wrote: >>> I just no

Re: [Nix-dev] Linux config options

For my own use cases at least, I’ve found that when the generic config is not good enough it’s better to just generate a config on my own the traditional way (via make nconfig or similar) and pass it to manual-config. > On Feb 10, 2015, at 1:56 PM, Matthias Beyer wrote: > > On 10-02-2015 14:56

Re: [Nix-dev] [haskell NG] Override package

> On Feb 17, 2015, at 6:18 PM, Daniel Bergey wrote: > > I think you'll need to replace the ~ with your homedir; ISTR Nix doesn't > interpret ~. Then change your buildTools line to refer to hdevtools, > not haskellngPackages.hdevtools. You inspired me: https://github.com/NixOS/nix/pull/480

Re: [Nix-dev] [proposal] Policy how to handle controversial commits

I don’t think we need 24 hour windows or anything. Don’t revert something that is just broken for trivial concerns if the other dev is actively responding, but don’t wait if something is fundamentally broken. My workflow here would be “see bad commit, revert, open discussion on the revert commit

Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?

You can already do this. “import foo” will build any derivations that “foo” depends on at evaluation time. Note though that really “build at evaluation time” is for several reasons inferior to “evaluate at build time”, i.e. recursive nix. I have an implementation for that but it doesn’t look li

Re: [Nix-dev] Question about organising dependencies not in core nixpkgs?

ub.com/shlevy/nix <https://github.com/shlevy/nix> > > > On 18 March 2015 at 16:01, Thomas Hunger <mailto:tehun...@gmail.com>> wrote: > Hi Shea, > > I checked your github version of nix [1] > > > [1] > > > On 18 March 2015 at 14:39, Shea Lev

[Nix-dev] Staging merge imminent

Hi all, The latest staging evaluation (http://hydra.nixos.org/eval/1176429 ) is nearly complete, barring any objection I will merge that in to master tomorrow morning. ~Shea___ nix-dev mailing list nix-dev@lists.sc

Re: [Nix-dev] Staging merge imminent

Merged. > On Mar 19, 2015, at 5:55 AM, Shea Levy wrote: > > Hi all, > > The latest staging evaluation (http://hydra.nixos.org/eval/1176429 > <http://hydra.nixos.org/eval/1176429>) is nearly complete, barring any > objection I will merge that in to master t

Re: [Nix-dev] Use GHC 7.10.1 as default Haskell compiler in nixpkgs

IMO (and this is not limited to Haskell) we should either always use the latest or, if the latest tends to provide a significantly different experience than the previous version, not have a default at all and require users to request a specific version. We do this for mysql in NixOS for example.

Re: [Nix-dev] [***SPAM***] git:// repositories in nixpkgs

fetchurl has a concept of multiple urls and mirrors, I’m not sure if fetchgit does but it would be nice for this use case. git:// should be preferred when it is usable, but if it’s not fetchgit could fall back to an alternatively specified URL. > On Mar 27, 2015, at 12:40 PM, Serge Kosyrev <_de

Re: [Nix-dev] [PATCH] Fixed zImage installation when building Linux.

Applied in 98d77cd1a57f3ff71d6ef36e727e339dd9cae233 > On Apr 16, 2015, at 5:32 PM, Jookia <166...@gmail.com> wrote: > > When building kernels outputting a zImage, the zImage wasn't correctly copied > in > to the installation. This broke the build process entirely, at least on my ARM > machine. >

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

Applied in 7b37a5f168706db5efa33599354f5c1967ac4c51, thanks! > On Apr 27, 2015, at 10:16 PM, 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. > >

Re: [Nix-dev] [PATCH 2/2] nixos-install: Fix chroot flag not defaulting to Bash outside NixOS.

Applied in 71910be9ea225895e36f60ed23a1bdce402b3088, thanks! > On Apr 27, 2015, at 10:16 PM, Jookia <166...@gmail.com> wrote: > > Passing the chroot flag to nixos-install without arguments should now give > you a > Bash shell as intended rather than try an empty path. > > This was masked by the

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

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

Re: [Nix-dev] Nix expression built-in type limitations

Hello, > On Apr 30, 2015, at 4:45 PM, Terrance Kennedy > wrote: > > Hi, > > I'm working on a Python project to convert Python built-in types to Nix > built-in types and it raised some quesions on the limitations of built-in Nix > types. I've been able to gather some information using nix-rep

[Nix-dev] i686 Builds?

Hi all, Do we still have users running 32-bit machines? It would reduce the load on hydra significantly if we could drop support for i686, though of course if people are still relying on it we shouldn't make the change yet. ~Shea ___ nix-dev mailing l

Re: [Nix-dev] Sharing Nix store between systems

Hi Tyson, Looks like a good start! I’ve left some comments on the commits. ~Shea > On May 15, 2015, at 5:39 PM, Tyson Whitehead wrote: > > On April 29, 2015 14:03:08 Tyson Whitehead wrote: >> I'm looking to setup a shared nix store for our HPC clusters. Googling for >> a shared store only gi

[Nix-dev] Adding pure darwin binaries to tarballs.nixos.org

Hi all, Now that pure-darwin is in master, can we move the binaries to tarballs.nixos.org? We're currently trying to fetch them from a dropbox [1], and that is failing on hydra [2] (though it seems to work for me locally with curl). Thanks, Shea [1]: https://github.com/NixOS/nixpkgs/blob/947

Re: [Nix-dev] Adding pure darwin binaries to tarballs.nixos.org

Sure, but having stdenv for darwin rely on someone's dropbox is a bad situation regardless, right? On 2015-10-19 07:30, Eelco Dolstra wrote: > Hi, > > On 19/10/15 13:25, Shea Levy wrote: > >> Now that pure-darwin is in master, can we move the binaries to >> tarbal

Re: [Nix-dev] Darwin on staging

The issue in master is unrelated; It's a networking issue that can only be fixed by Eelco or Rob (see my email to the ml on Monday). The issue in staging is due to a bad nix.conf on the darwin box, which again only Eelco or Rob can fix (its allowed-impure-host-deps field needs to include /usr/l

Re: [Nix-dev] Adding pure darwin binaries to tarballs.nixos.org

Any update on this? On 2015-10-19 07:33, Shea Levy wrote: > Sure, but having stdenv for darwin rely on someone's dropbox is a bad > situation regardless, right? > > On 2015-10-19 07:30, Eelco Dolstra wrote: >> Hi, >> >> On 19/10/15 13:25, Shea Levy wrote: >&

Re: [Nix-dev] Publish All of Hackage

The problem with doing this with import-from-derivation is we still need the hashes of every tarball ahead of time (though that's much smaller than all of hackage, and we really just need the hash of the file that contains all the hashes in nixpkgs itself). If we have that, then we don't need t

Re: [Nix-dev] NixOS/Nixpkgs repository labels

No opinion on the specifics of colors/categories, but +1 for the general idea. On 2015-11-21 19:59, Nicolas Pierron wrote: > Hi everybody, > > I spent a day doing triage of newly created bugs and I think the > labels [1] of our repository are currently a big mess. I think the > meaning of our la

Re: [Nix-dev] Concatenation of values

Hi Arseniy, The ordering of the concatenation is by default unspecified. You can put constraints on it with 'mkOrder', see https://github.com/NixOS/nixpkgs/blob/a2aab3a224939cc7c24e88984c5f5ab169aee271/lib/modules.nix#L464-L470 for the details. So you can for example have the line that sets '

[Nix-dev] Idris packages in nixpkgs

Hi all, I've just added [1] rudimentary support for building Idris packages and composing the packages with the compiler to nixpkgs. Details can be found in the idris-modules directory [2], including potential future work [3]. Idris's lack of any mechanism to have multiple library paths is so

Re: [Nix-dev] [PATCH] daemon: Add 'buildMode' parameter to 'buildPaths' RPC.

Can you resend with paths appropriate to the nix repo? There is no nix/ directory there. ~Shea On 2015-12-02 12:03, Ludovic Courtès wrote: > * nix/libstore/worker-protocol.hh (PROTOCOL_VERSION): Bump to 0x10f. > * nix/libstore/remote-store.cc (RemoteStore::buildPaths): Send the > BUILDMODE when

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

I have no opinion on this feature specifically, but re #3: avoiding a feature in order to keep things in a poor enough state so that users care about the issues you think they should care about is highly patronizing and a terrible way for developers to relate to users. It is incidentally ridicul

Re: [Nix-dev] How can we make import-from-derivation more useful?

https://github.com/NixOS/nix/pull/31 may be relevant. On 2015-12-28 11:10, Daniel Peebles wrote: > A few days ago, I proposed importing from a derivation [1] to save us > from having to manually manage autogenerated firefox/thunderbird > fixed-output derivaiton hash files and junk up the nixpkgs r

Re: [Nix-dev] Perl -> C++

Nothing's stopping you from starting the conversion. If it's clearly better, it will be a lot easier to convince people once you have actual code to show. On 2015-12-30 20:30, stewart mackenzie wrote: > On Thu, Dec 31, 2015 at 4:04 AM, jeaye wrote: >> As C++ devs, I think it's important that we

Re: [Nix-dev] Nix 1.11 released

> > • All "chroot"-containing strings got renamed to "sandbox". In > particular, > some Nix options got renamed, but the old names are still > accepted as > lower-priority aliases. > > This release has contributions from Anders Claesson, Anthony

Re: [Nix-dev] Prepending files to initrd

This may not be the case any more, but in the past at least you had to explicitly specify the newc cpio format (with -H newc) when calling cpio to make initrds. > On Jan 30, 2016, at 5:26 AM, Roger Qiu wrote: > > Hi, > > There's an option called: `boot.initrd.prepend`. I tried to prepend a >

Re: [Nix-dev] An issue regarding the default parameters of a function

This is intentional: @-capture captures what was actually passed. You can always do something like: let args_ = args // { buildDepends = args.buildDepends or buildDepends; } if you really need this behavior. On 2016-02-12 06:11, Sergey Mironov wrote: > Hi. I have an issue regarding the combinati

[Nix-dev] CVE-2015-7547 stdenv-changing fix merged on master and 15.09

Hi all, I've just merged the patch to fix CVE-2015-7547, a buffer overrun in glibc with working POC exploit, into master and 15.09. It will take some time for the channel to update, so please use your judgment as to whether you want to wait for that or switch to building from git until it catc

Re: [Nix-dev] CVE-2015-7547 stdenv-changing fix merged on master and 15.09

There was an error with the patch, we're cooking up a fix now. On 2016-02-16 10:37, Shea Levy wrote: > Hi all, > > I've just merged the patch to fix CVE-2015-7547, a buffer overrun in > glibc with working POC exploit, into master and 15.09. It will take > some > ti

Re: [Nix-dev] CVE-2015-7547 stdenv-changing fix merged on master and 15.09

Fixed patch pushed to master, 15.09, and 14.12. On 2016-02-16 10:58, Shea Levy wrote: > There was an error with the patch, we're cooking up a fix now. > > On 2016-02-16 10:37, Shea Levy wrote: >> Hi all, >> >> I've just merged the patch to fix CVE-2015-75

Re: [Nix-dev] CVE-2015-7547 stdenv-changing fix merged on master and 15.09

ibc; > replacement = builtins.storePath > /nix/store/5fbwy40pa4pqr97jdgbyaal1y1ns6hb1-glibc-2.21; }) ]; and do a nixos-rebuild against the channel to get a secured system until the channel is updated. Regards, Shea On 2016-02-16 11:36, Shea Levy wrote: > Fixed patch pushed to master, 15.0

Re: [Nix-dev] CVE-2015-7547 stdenv-changing fix merged on master and 15.09

On 2016-02-16 14:25, Kosyrev Serge wrote: > rocon...@theorem.ca writes: >> I am using the following expression which I believe will build a >> patched >> version of glibc locally, and then build a patched NixOS derivation. >> >> system.replaceRuntimeDependencies = with pkgs.lib; >> [{origina

Re: [Nix-dev] Hotfixing glibc

There is a much better solution available to entirely replace a bad store path without violating any nix invariants (e.g. modifying store paths), see http://lists.science.uu.nl/pipermail/nix-dev/2016-February/019564.html for an example. It does have the same dynamic-only limitation, of course.

[Nix-dev] Printing test failure preventing unstable channel update

Hi all, The printing tests are failing on hydra. Anyone know what might be going on here? http://hydra.nixos.org/build/32105948 ~Shea ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Fwd: Wiki is dead

Someone (I think Vladimir?) offered to translate docs in any format into the necessary docbook, and has done so at least for one of my PRs. As long as that offer still stands and isn't overwhelming him, we can avoid spending time and resources switching over our format until we actually have ev

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

"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

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

l 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:5

Re: [Nix-dev] NixON initiative

On 2016-03-03 19:34, Profpatsch wrote: > On 16-02-28 04:44pm, zimbatm wrote: >> So something like that ? https://github.com/NixOS/nixpkgs/pull/13552 >> And then we would convert all of our tooling to output JSON ? > > As long as nixexprs embedded in the JSON are *not* evaluated in any > way, > we

[Nix-commits] SVN commit: nix - r33885 - in nixpkgs/trunk/pkgs: os-specific/linux/kernel top-level

Author: shlevy Date: Mon Apr 23 00:12:47 2012 New Revision: 33885 URL: https://nixos.org/websvn/nix/?rev=33885&sc=1 Log: Linux 3.3.3 This incorporates the btrfs fix, so remove that patch. Also, I will test that this builds after committing, and fix it if it fails Deleted: nixpkgs/trunk/pkgs/o

  1   2   3   4   5   6   7   8   9   10   >