[Nix-commits] [NixOS/nixpkgs] 2ce7dd: emacs: fix sha256 hashes of savannah patches
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 2ce7dd7f84b86e72131fa616ba4f6a8e5927 https://github.com/NixOS/nixpkgs/commit/2ce7dd7f84b86e72131fa616ba4f6a8e5927 Author: Aycan iRiCAN Date: 2017-02-15 (Wed, 15 Feb 2017) Changed paths: M pkgs/applications/editors/emacs/default.nix Log Message: --- emacs: fix sha256 hashes of savannah patches ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] Plan for GHC 8.0.2
Thank you Peter. — aycan > On 10 Jan 2017, at 00:43, Peter Simons wrote: > > Hi folks, > >> I was wondering what your plan is regarding GHC-8.0.2. Will you add >> it to the release-16.09 branch once it's released? > > the current Git version of "release-16.09" has now the exact same Haskell > infrastructure as 'master', i.e. it's based on LTS Haskell 7.14 and it > includes the latest GHC: > >$ git describe >16.09-806-g2ad30bde82 > >$ nix-shell -p haskell.compiler.ghc802 --run "ghc --version" >The Glorious Glasgow Haskell Compilation System, version 8.0.2 > >$ nix-shell -p stack --run "stack --numeric-version" >1.3.2 > >$ nix-shell -p cabal-install --run "cabal --version" >cabal-install version 1.24.0.2 >compiled using version 1.24.2.0 of the Cabal library > > Enjoy, > Peter > > ___ > 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] Plan for GHC 8.0.2
Happy new year. Since 8.0.2 fixes non deterministic I'd bug, it's very important for those who can't use distributed builds due to this bug. Cheers -- aycan > On 2 Jan 2017, at 02:20, Bas van Dijk wrote: > > First of all, happy New Year everybody! > > Peter, I was wondering what your plan is regarding GHC-8.0.2. Will you add it > to the release-16.09 branch once it's released or do we have wait for 17.03? > > Cheers, > > Bas > ___ > 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] environment.etc.'filename'.owner ?
Here is an example: https://github.com/peti/hydra-tutorial/blob/master/hydra-master.nix — aycan > On 16 Dec 2016, at 15:39, Azul wrote: > > Is there a way to set the owner and group for a file as per the subject ? > > couldn't grep for any example for this. > > thanks > azul > ___ > 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] where is grep?
Are you looking for gnugrep? — aycan > On 14 Nov 2016, at 22:49, Azul wrote: > > some large refactoring left me with this one, > > /run/current-system/sw/bin/grep > grep: unrecognized option '--color=auto' > BusyBox v1.24.2 () multi-call binary. > > grep is coming from busybox, > which package provides the real thing? > > > > ___ > 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] 983ab7: haskellPackages.hans: fixed major version bugs (#1...
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 983ab7be1e1e8efe922d076f6c2f1ee7aa27f394 https://github.com/NixOS/nixpkgs/commit/983ab7be1e1e8efe922d076f6c2f1ee7aa27f394 Author: Aycan iRiCAN Date: 2016-08-06 (Sat, 06 Aug 2016) Changed paths: M pkgs/development/haskell-modules/configuration-common.nix Log Message: --- haskellPackages.hans: fixed major version bugs (#17555) ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] How to access makeTest function from nixpkgs/nixos/lib/testing.nix?
Also you don’t need to use toString, below should also work:
import (my-nixpkgs.path + "/nixos/tests/make-test.nix”) ({…});
—
aycan
> On 03 Aug 2016, at 05:36, Tomasz Czyż wrote:
>
> I'm just adding solution I was looking for and finally found:
>
> (import "${toString my-nixpkgs.path}/nixos/lib/testing.nix")
>
> that's how you get the path from custom nixpkgs.
>
> 2016-06-23 1:43 GMT+01:00 Tomasz Czyż :
>
>
> 2016-06-23 1:39 GMT+01:00 Maarten Hoogendoorn :
> Cool.
>
> For development environments, it is recommended to use the nix-shell program.
>
> +1, I'm constantly forgetting about it.
> A good example is nixops (nixos/nixops on github).
>
> PS, I've added the list again.
>
> Cheers :-)
>
> Tom
> Op 23 jun. 2016 02:34 schreef "Tomasz Czyż" :
>
> Maarten,
>
> thank you for showing this, I definitely omitted this part, now I see how you
> set NIX_PATH in test.sh.
>
> I think this approach is fine, and I'll use that solution if I won't figure
> out better way.
>
> I have tree like that:
> ./nixpkgs.nix # this stuff is importing specific nixpkgs commit
> ./app1
> ./app2
> ./app3
> ./tests
>
> each app is importing "../nixpkgs.nix" separately and tests are importing it
> as well so all separately are using same nix version "internally".
>
> By avoiding wrapper I can go to every directory and run nix-build and it will
> work and app will be bound to specific nixpkgs version.
>
> Another solution would be, as you pointed, setting -I / NIX_PATH, but this is
> another manual step that needs to be done. You have to add this to .profile
> (but this is not project specific :[) or you have to set this in every
> terminal you are working in, or figure out other way to set up this. I'll go
> this route if I have no other options.
>
> Right now with small workaround I described in previous post all stuff is
> working without any other setup.
>
> 1. Clone the repo
> 2. nix-build in every directory you want
>
> 2016-06-23 1:23 GMT+01:00 Maarten Hoogendoorn :
> You could set the nixpkgs path with the -I option, or as I do, with a shell
> variable.
> Point it to your fork of nixpkgs, and you're done.
>
> Alternatively, there is some overridePackage(s?) function that might interest
> you. (I myself should look at in detail as well ;))
>
> Op 23 jun. 2016 02:19 schreef "Tomasz Czyż" :
>
> Maarten,
>
> thank you for sharing your work.
>
> I think you are using approach with "import " and not overriden pkgs
> inside testing config/machine - which I prefer to avoid, because I want to
> have bound nixpkgs version, I don't want to use "system" version. (maybe I'm
> missing some piece, in that case please point it out).
>
> In the meantime I found, that I can pass/override pinned pkgs inside
> config/machine description with a little trick.
>
> import ({
> machine = {config,pkgs,...}: {
> _module.args.pkgs = my-nixpkgs; # this trick overrides pkgs argument
> for all modules
> imports = [
> ... my modules...
> ];
>
> };
> testScript=''
> ...
> '';
> })
>
>
> I would prefer to not use this method as probably "pkgs" argument can "leak"
> in some places (the other version of nixpkgs can be used and I will not
> detect this easily). But that's the best I have so far.
>
>
>
> 2016-06-23 1:10 GMT+01:00 Maarten Hoogendoorn :
> Hi Tomasz,
>
> Some weeks ago, I looked into this to run zfs integration tests for a rust
> binding to libzfs.
>
> The GitHub repository [1] is set up to run a qemu vm on Travis, so that my
> tests can run with a kernel that supports zfs. It also provides some
> isolation during development. I'd rather not destroy my main pool by accident
> ;)
>
> Good luck, and let me know if this helps you out :)
> Maarten
>
> [1] https://github.com/moretea/rust-zfs
>
> 2016-06-23 1:23 GMT+02:00 Tomasz Czyż :
> Hello,
>
> I found makeTest function from nixos useful and I would like to use it in my
> projects for building integration testing environments.
>
> The only method I found by now, how to access it is:
>
> (import ).makeTest
>
> The problem is: in the script I'm running, the fixed nixpkgs version is
> passed as "pkgs" argument. The script must test programs against that
> specific nixpkgs version.
>
> I see two options:
> 1. grab makeTest command from pinned nixpkgs
> 2. grab makeTest from and pass pinned nixpkgs as argument to
> makeTest (and further to machine/nodes).
>
> 1. I couldn't find the attribute which is pointing to that function or file,
> if looks like I can access it only using path syntax like
> . Is there any way to get path for current
> "pkgs" set? Or are there any other ways how I can access this file/function?
>
> 2. I didn't find any way to pass pkgs argument down the stack, looks like
> other funtions inside makeTest are just importing pkgs from "local" files so
> probably this way won't work.
>
> 3. I could copy the files and bind them to attributes but
Re: [Nix-dev] Haskell Development and Deployment Strategies (was: Stackage Support Will Be Discontinued)
This is almost the same setup we’re using in Picus Security. The difference is
that we’re building our project with master and let hydra find sweet spots to
merge. We then update our projects submodule hash to the next stable hash.
Our major problem is not sticking to a stable setup but to intergrate our
project with new and updated packages.
Oh btw, Peter, I really appreciate your efforts. You put a hard work to make
our haskell ecosystem reliable. Not only writing automation tools but also
pushing upstream projects to fix their bugs.
—
aycan
> On 10 Jun 2016, at 18:17, Bas van Dijk wrote:
>
> Just as a point of reference, in my job at LumiGuide I'm in camp 4: "I want
> total control over my entire package set."
>
> * We run a high-profile production system consisting of multiple NixOS
> machines deployed using nixops to physical machines across the Netherlands
> and to machines on Hetzner. I also consider our NixOS development
> workstations to be part of the system. The configuration of all machines is
> defined by a single repository.
>
> * In that repository we set our nixpkgs to our own fork of nixpkgs which
> basically tracks the latest release (currently
> https://github.com/NixOS/nixpkgs-channels/tree/nixos-16.03) and adds a few of
> our own commits on top. We use a variation of Rok Garbas's "Reproducable
> development environments" trick [1].
>
> * Every 3 weeks or so I run a script which:
> 1. shows me the git log between our revision of nixpkgs and the latest
> upstream
> 2. set our revision of nixpkgs to the latest upstream with our own commits
> rebased on top of it
> 3. push that to a special "staging" branch.
>
> * We run our own hydra CI server which starts building the staging branch.
> When it builds successfully I merge staging into master and update all our
> machines (including our development workstations).
>
> * We also extend and override nixpkgs using its packageOverrides
> functionality. The following is the Haskell part of our override function:
>
> super:
> let self = super.pkgs;
> haskellOverrides = import ./haskell super;
> in rec {
> haskellPackages =
> super.haskellPackages.override haskellOverrides;
> haskell = super.haskell // {
> packages = super.haskell.packages // {
> ghcjs =
> super.haskell.packages.ghcjs.override
> haskellOverrides;
> };
> };
> profiledHaskellPackages =
> super.haskellPackages.override {
> overrides = self: super: {
> mkDerivation = args:
> super.mkDerivation (args // {
> enableLibraryProfiling = true;
> });
> } // haskellOverrides.overrides self super;
> };
> ...
> }
>
> * The Haskell overrides function defined in ./haskell/default.nix adds all
> our LumiGuide specific Haskell packages and overrides some existing packages
> to newer versions:
>
> pkgs :
> {
> overrides = self : super :
> let hsLibsFromDir = dir :
> pkgs.lib.genAttrs
> (builtins.attrNames (builtins.readDir dir))
> (name : self.callPackage
> (dir + "/${name}") {});
> inhsLibsFromDir ./.
> // hsLibsFromDir ../../hs-libs
> // hsLibsFromDir ../../hs-js-libs;
> }
>
> * Note that we aren't using the lts package set. I'm not sure if we should...
>
> I just want to provide this as a datapoint of one actual use of the Haskell
> infrastructure of nixpkgs.
>
> Regards,
>
> Bas
>
> [1] https://garbas.si/2015/reproducible-development-environments.html)
>
> On 10 June 2016 at 13:23, Peter Simons wrote:
> Fellow Haskell Hackers,
>
> Nix gives you great freedom to choose how to develop and deploy your
> Haskell software. That's good, but at the same time that flexibility can
> be confusing and feel like a burden. Therefore, I'd like to shed some
> light on this issue and discuss different types of strategies and their
> respective pros and cons. Which strategy is best for you depends on what
> you would like to achieve:
>
> 1. I want the latest version of every package as quickly as possible
> because I love it when build attempts result in hundreds of
> compiler errors that I can fix.
>
> 2. I want my Haskell packages to be up-to-date, but I also want my
> builds to be reliable. I don't mind fixing the occasional build
> error, but I mean, like, *occasionally*.
>
> 3. I want my Haskell package set to be rock solid. I don't want any
> updates unless there is a major security issue or a severe bug that
> threatens the integrity of my system.
>
> 4. I want total control over my entire package set.
>
> Now, let's go through the options those types of users have.
>
> If you favor features over stability as in (1), then you should develop
> with 'cabal-install', really. Nixpkgs might be useful for installing
> your favorite development tools like GHC, c
[Nix-commits] [NixOS/nixpkgs] 379559: snort: 2.9.7.2 -> 2.9.8.2
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 379559702e4b652ada7c37f820a1e59ce52c653f https://github.com/NixOS/nixpkgs/commit/379559702e4b652ada7c37f820a1e59ce52c653f Author: Aycan iRiCAN Date: 2016-05-21 (Sat, 21 May 2016) Changed paths: M pkgs/applications/networking/ids/daq/default.nix M pkgs/applications/networking/ids/snort/default.nix Log Message: --- snort: 2.9.7.2 -> 2.9.8.2 ___ nix-commits mailing list nix-comm...@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-commits
Re: [Nix-dev] break purity
This is a clever optimization. Thank you Oliver.
--
aycan
> On 22 Apr 2016, at 21:33, Oliver Charles wrote:
>
> It's certainly possible, because I just did it with Haskell ;)
>
> https://gist.github.com/ocharles/cbd5d7ce63bb570abb86e655f36435ab
>
>> On Fri, Apr 22, 2016 at 7:16 PM stewart mackenzie wrote:
>> Yeah, I'm not so sure it's possible because one cannot copy from a
>> precompiled derivation output to a new derivation output, ie copy
>> cross derivation.
>>
>> As these multiple outputs (outputs = [x y z]) are seen as different
>> derivations, this cannot happen right?
>>
>> Have you actually managed to make progress beyond the copying part of
>> your example (preConfigure = "cp ${artefacts}/* .'';) in your
>> experimentation?
>>
>> (I'm still thought experimenting)
> ___
> 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] qemu
Thank you Karn. Here is the changelog for 2.4.0.1: CHANGELOG: 83c92b4: Update version for 2.4.0.1 release (Michael Roth) 5a1ccdf: net: avoid infinite loop when receiving packets(CVE-2015-5278) (P J P) 7aa2bca: net: add checks to validate ring buffer pointers(CVE-2015-5279) (P J P) 3a56af1: e1000: Avoid infinite loop in processing transmit descriptor (CVE-2015-6815) (P J P) efec4dc: vnc: fix memory corruption (CVE-2015-5225) (Gerd Hoffmann) > On 12 Oct 2015, at 11:47, Karn Kallio wrote: > > > The attached patch updates the qemu version 2.4.0 to 2.4.0.1 > > <0001-qemu-2.4.0-updated-to-2.4.0.1.patch>___ > 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 and NixOps on server : testimonials here ?
> On 25 Jun 2015, at 18:35, Fabien Bourgeois wrote: > > Le 24/06/2015 15:56, Aycan İrican a écrit : >> [...] I prefere stable branch on production systems mainly for low >> maintenance cost. > > Thanks. Seems reasonable to me. With virtual testing before, should I expect > some rough edges when upgrading from oldstable to stable ? Most probably you wont have any major problems. If so you can boot into previous configuration and fix it. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS and NixOps on server : testimonials here ?
> On 24 Jun 2015, at 16:32, Fabien Bourgeois wrote: > > Hi there, > > I'm a newcomer to Nix ecosystem and am theoretically really pleased > about manuals and articles I've read about it. > > I will really soon give it a try and if tests fulfill my needs, I'd like > to be able to use NixOS "everywhere" (workstations, servers). I have > some questions about using NixOS on servers machines in production (I > guess this list is not exhaustive : > https://nixos.org/wiki/Nix%28OS%29_in_production ) > > 1) Have you experiences about using NixOS on physical or virtual servers > ? Do you have some advice to share ? We’re using NixOS on Leaseweb’s dedicated server (HP DL180) without any problems. Though installing NixOS using ILO was pretty boring. > 2) Do you follow stable or unstable channel ? Why ? (security, stability…) I am using master nixpkgs branch on my desktop since I regularly modify it and I want to follow upstream changes. I prefere stable branch on production systems mainly for low maintenance cost. > 3) Are there here some NixOps users ? How many servers are you deploying > to ? I am currently using libvirtd backend for bringing up a test network as quickly as possible to run tests. Regards, ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Switch to GHC 7.10.1 is imminent
Hi Peter, I am -1 on this. Since some of the packages which I depend doesn't compile with ghc 7.10 yet, they need upstream fixes (hans, http-streams, rank1dynamic, jmacro and a few more). Could you please suspend the merge for one more week? OTOH, I can still use haskell-ng.packages.ghc784 if nobody supports my idea. On Fri, Apr 17, 2015 at 7:23 PM Peter Simons wrote: > Fellow Haskellers, > > I'd like to merge https://github.com/NixOS/nixpkgs/pull/7037 soon, i.e. > by the end of this weekend. This means that haskellngPackages will point > to the "haskell-ng.packages.ghc7101" package set henceforth. You can see > the current state of what compiles and what does not at > http://hydra.cryp.to/jobset/nixpkgs/haskell-updates-ghc7101. If you feel > that this switch is a bad idea and that we should postpone the update, > then please make your voice heard on the Github issue tracker or on this > mailing list. > > Best regards, > Peter > > ___ > 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] extraGroups option does not work
Did you set "users.mutableUsers = true"? If so you should do it manually. On Wed, Aug 20, 2014 at 2:42 AM, Alexey Muranov wrote: > Setting > > extraGroups = [ "wheel" ]; > > in configuration.nix when creating a new user does not seem to have any > effect. Is this a bug? > > Alexey. > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
Thank you Peter. I think it is useful since snap-server has cmd args which one can enable or disable https. On Tue, Jun 24, 2014 at 8:29 PM, Peter Simons wrote: > Hi Aycan, > > > Is it possible to provide cabal flags within a derivation? > > you can set "-fFLAG" in configureFlags to enable the flag during the > build. If this flag is useful in general, then please add it to > > https://github.com/NixOS/cabal2nix/blob/master/src/Cabal2Nix/Flags.hs > > and file a pull request. > > Best regards, > Peter > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
Unfortunately cabal2nix doesn't support flags. I'm going to take a look at hack-nix. On Tue, Jun 24, 2014 at 12:18 PM, Marc Weber wrote: > The problem with flags is that dependencies might change. No idea how > cabal2nix handles this. Maybe you have to rerun it with flag info. > > The alternative is using hack-nix which creates the dependency > information on the fly anyway - but the database might be a little bit > outdated. > > Thus have a look at cabal2nix and hacknix. If you want to give the > latter a try let me know. > > Marc Weber > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cabal.mkDerivation and cabal flags
Hi, Is it possible to provide cabal flags within a derivation? Specifically I need to define a derivation which depends on snapServer built with HOpenSSL (manually I do `cabal install -fopenssl snap-server`)? Regards, -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nixlint or nixflakes?
+1. examples: hlint, stylish-haskell On Tue, Jun 24, 2014 at 12:37 AM, Florian Friesdorf wrote: > > Hi, > > I would like to see a nixlint/nixflakes to encourage/enforce best > practices for nix expressions and work towards a unified style so I > don't have to think for myself what looks nicer or what would be the > correct way of doing things. > > Ideally github would signal whether a pull requests passes this check. > > What do you think? > > florian > -- > Florian Friesdorf > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC > > ___ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > -- http://www.google.com/profiles/iricanaycan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
