[Nix-commits] [NixOS/nixpkgs] caf44a: google-cloud-sdk: enable alpha and beta features

2017-07-03 Thread Maarten Hoogendoorn
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: caf44a5dd3d5baf99a30290dd067f40266197435
  
https://github.com/NixOS/nixpkgs/commit/caf44a5dd3d5baf99a30290dd067f40266197435
  Author: Maarten Hoogendoorn <maar...@moretea.nl>
  Date:   2017-07-03 (Mon, 03 Jul 2017)

  Changed paths:
A pkgs/tools/admin/google-cloud-sdk/alpha__init__.py
A pkgs/tools/admin/google-cloud-sdk/beta__init__.py
M pkgs/tools/admin/google-cloud-sdk/default.nix

  Log Message:
  ---
  google-cloud-sdk: enable alpha and beta features

google-cloud-sdk: enable alpha and beta features


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


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

2017-06-19 Thread Maarten Hoogendoorn
There appear to be sufficient people in favor of this feature. Time for a
RFC?

2017-06-19 11:28 GMT+02:00 Adrien Devresse :

> Note, sharing /nix is already not really possible because the metadata is
> stored in sqlite and its locking does not play nice with nfs. (*)
>
>
> Sharing is possible if you use a distributed file system that handle
> consistency correctly, like GPFS, Lustre or similar.
>
> We use Nix in shared model in production everyday in my organization.
>
>
> Another issue is that right now, nix does not /require/ the daemon to
> work, and this proposal would change that.
>
>
> It is not really an issue. It could be done the same way it is done
> currently. The client does the GC management if configured in single user
> mode, or does it through the daemon if configure in multi user mode.
>
> The strong point here is that only ONE user should write to /nix :
> - Yourself in single user mode
> - The nix-daemon in multi user mode.
>
> This is not the case currently.
>
>
> 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?
>
>
> I strongly support your idea.
>
> The roots / profile implementation is currently hacky, not really
> reliable, and potentially a security issue.
>
>
> Regards,
> Adev
>
>
> Le 18. 06. 17 à 07:43, Wout Mertens a écrit :
>
> 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 
> listnix-...@lists.science.uu.nlhttps://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 mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] github triggered builds

2017-05-10 Thread Maarten Hoogendoorn
I'm interested in this area as well.

Graham wrote some tooling to enable hydra to build PR's (
https://github.com/grahamc/hydra-prs/). Combined with a github bot this is
getting close to what you're aiming for. (The bot is necessary given that
we don't want to run any PR without a manual code review on this public
project).


2017-05-09 22:44 GMT+02:00 Harmen <har...@lijzij.de>:

> On Tue, May 09, 2017 at 01:08:08PM +0200, Maarten Hoogendoorn wrote:
> > Unfortunately this does not really help with sharing derivations that
> have
> > been built before.
>
> Thanks for all the replies. Seems like I didn't miss anything obvious.
>
> My current plan is to try gitlab with my own runner, which has a 'shell
> executor' option.
> https://docs.gitlab.com/runner/executors/shell.html
> That looks like to be exactly what I need for nix based builds.
>
>
> Is this use-case of nix so uncommon (push-triggered builds)? Do most
> people go for Hydra?
>
> Thanks!
> Harmen
>
> >
> > 2017-05-09 10:02 GMT+02:00 zimbatm <zimb...@zimbatm.com>:
> >
> > > Travis CI also has support for nix builds and might be easier to setup.
> > >
> > > On Mon, 8 May 2017, 18:17 Tomasz Czyż, <tomasz.c...@gmail.com> wrote:
> > >
> > >> https://nixos.org/hydra/
> > >>
> > >> and
> > >>
> > >> https://github.com/hercules-ci/hercules ( looks like still in heavy
> > >> development but maybe usable :))
> > >>
> > >> 2017-05-08 18:14 GMT+01:00 Harmen <har...@lijzij.de>:
> > >>
> > >>> Hi,
> > >>>
> > >>> I'm trying to see how I can make my build processes easier with nix.
> So
> > >>> far
> > >>> it's going pretty good and it's fun, although there was a lot of
> > >>> searching
> > >>> online for scattered documents.
> > >>>
> > >>> Want I want to do (as the first thing to change to nix in
> production) is
> > >>> to
> > >>> port the building of some docker images I use for testing. The idea
> is to
> > >>> have docker images build, tagged with their branch they come from,
> when
> > >>> someone
> > >>> pushes something. The building and pushing an sich work. The .nix
> files
> > >>> live in
> > >>> the repo, and with a `make docker` the image is build and uploaded.
> I'm
> > >>> very
> > >>> happy to be able to build docker images without actually having to
> use
> > >>> docker
> > >>> ;)
> > >>>
> > >>> So, what would be the recommended way to trigger the building
> process?
> > >>> I'm
> > >>> currently using drone.io, but that works with containers. It works
> with
> > >>> nix,
> > >>> when I give it the nixos/nix docker image, but building a node
> project
> > >>> takes
> > >>> about 5 minutes, and drags in way too much from cache.nixos.org. I
> > >>> tried to
> > >>> have it make a local nix binary-cache, but there are some problems
> > >>> there, but
> > >>> drone also just doesn't fit the problem nicely.  Nix solves the
> problem
> > >>> of
> > >>> versioning so much nicer than containers that I would prefer to use
> > >>> something
> > >>> simpler. Hydra could work, but I'm a bit intimidated by that, and
> would
> > >>> like to
> > >>> have something simpler for now.
> > >>>
> > >>> The LT;DR: question: is there a simple nix based build system which
> can
> > >>> be
> > >>> triggered via git{hub,lab} hooks?
> > >>>
> > >>>
> > >>> Thanks!
> > >>> Harmen
> > >>> (If there is a better place to ask this, let me know)
> > >>> ___
> > >>> nix-dev mailing list
> > >>> nix-dev@lists.science.uu.nl
> > >>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Tomasz Czyż
> > >> ___
> > >> 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 mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] github triggered builds

2017-05-09 Thread Maarten Hoogendoorn
Unfortunately this does not really help with sharing derivations that have
been built before.

2017-05-09 10:02 GMT+02:00 zimbatm :

> Travis CI also has support for nix builds and might be easier to setup.
>
> On Mon, 8 May 2017, 18:17 Tomasz Czyż,  wrote:
>
>> https://nixos.org/hydra/
>>
>> and
>>
>> https://github.com/hercules-ci/hercules ( looks like still in heavy
>> development but maybe usable :))
>>
>> 2017-05-08 18:14 GMT+01:00 Harmen :
>>
>>> Hi,
>>>
>>> I'm trying to see how I can make my build processes easier with nix. So
>>> far
>>> it's going pretty good and it's fun, although there was a lot of
>>> searching
>>> online for scattered documents.
>>>
>>> Want I want to do (as the first thing to change to nix in production) is
>>> to
>>> port the building of some docker images I use for testing. The idea is to
>>> have docker images build, tagged with their branch they come from, when
>>> someone
>>> pushes something. The building and pushing an sich work. The .nix files
>>> live in
>>> the repo, and with a `make docker` the image is build and uploaded. I'm
>>> very
>>> happy to be able to build docker images without actually having to use
>>> docker
>>> ;)
>>>
>>> So, what would be the recommended way to trigger the building process?
>>> I'm
>>> currently using drone.io, but that works with containers. It works with
>>> nix,
>>> when I give it the nixos/nix docker image, but building a node project
>>> takes
>>> about 5 minutes, and drags in way too much from cache.nixos.org. I
>>> tried to
>>> have it make a local nix binary-cache, but there are some problems
>>> there, but
>>> drone also just doesn't fit the problem nicely.  Nix solves the problem
>>> of
>>> versioning so much nicer than containers that I would prefer to use
>>> something
>>> simpler. Hydra could work, but I'm a bit intimidated by that, and would
>>> like to
>>> have something simpler for now.
>>>
>>> The LT;DR: question: is there a simple nix based build system which can
>>> be
>>> triggered via git{hub,lab} hooks?
>>>
>>>
>>> Thanks!
>>> Harmen
>>> (If there is a better place to ask this, let me know)
>>> ___
>>> nix-dev mailing list
>>> nix-dev@lists.science.uu.nl
>>> https://mailman.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>
>>
>>
>> --
>> Tomasz Czyż
>> ___
>> 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 mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Simplify node packages?

2017-04-25 Thread Maarten Hoogendoorn
I've been working with zimbatim and manveru on a yarn2nix as well, see
https://github.com/moretea/yarn2nix

I'm not actively using it myself though. I would be interested in planning
a few hours to hack on this together ;)

2017-04-25 10:37 GMT+02:00 Profpatsch :

> On 17-04-25 08:20am, Benno Fünfstück wrote:
> > If we get upstream to support enough for our use case, the solution
> should
> > be much more stable.
>
> Upstream support might be helpful,
> but that’s a wholly different beast.
>
> > Hmm, so perhaps in we can unpack the tarballs already in `phase 1` and
> tell
> > yarn to just look in $DIR for unpacked tarballs? Yarn should already have
> > most of the code that is required for correct symlinking, no?
>
> The code for correct symlinking is <4 lines,
> maybe a few more for manpages and binaries.
>
> I’d argue integrating it into yarn is even more frickle:
> 1. With yarn there’s now two implementations of npm packages.
> 2. We have to invest into lobbying so our integration
>isn’t broken by upstream sometimes. Then lobby again.
> 3. You’d definitely have to change yarn to have
>an offline mode where it doesn’t try to download stuff.
>I’m pretty sure upstream doesn’t care about that very much.
>
> These are the problem points I see.
>
> --
> 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
> 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] 3 strange busybox problems

2017-04-20 Thread Maarten Hoogendoorn
Did you install busybox globally on your system? It might shadow some GNU
core tools, if you set the priority for busybox higher than the priority
for the GNU tools.

2017-04-20 9:56 GMT+02:00 Michael Bock :

> Hi nix folks,
>
> I'm having some strange troubles on my NixOS machine. It looks that's
> somehow related to the busybox package, here are some cases:
>
> 1. It's not possible to see manpages for any program anymore.
>
> ``
>
> man grep
> man: no manual entry for 'grep'
>
> man -aw
> BusyBox v1.24.2 () multi-call binary.
>
> Usage: man [-aw] [MANPAGE]...
>
> Format and display manual page
>
> -aDisplay all pages
> -wShow page locations
>
> ``
>
> This appeared some time ago and is the case throughout any rollback.
>
>
> 2. The top command
>
> ``
>
> top
>
> [...]
>
> *** buffer overflow detected ***: top terminated
> [...]
>
> 0040-004f8000 r-xp  fe:01 411845
> /nix/store/gkm15nx2gw43qasbkijs3czzhq6hwk86-busybox-1.24.2/bin/busybox
> [...]
>
> 7febfa18d000-7febfa1a3000 r-xp  fe:01 695683
> /nix/store/q3wx1gab2ysnk5nyvyyg56ana2v4r2ar-glibc-2.24/lib/libgcc_s.so.1
> [...]
>
> ``
>
> See the full output here: https://pastebin.com/ssUCziP7
>
> This appeared earlier than the first issue and is also now the case in
> any older rollback.
>
>
> 3. Tor-Browser (happens with some other programs as well..)
>
> ``
>
> tor-browser
> cp: invalid option -- 'u'
> BusyBox v1.24.2 () multi-call binary.
>
> Usage: cp [OPTIONS] SOURCE... DEST
>
> Copy SOURCE(s) to DEST
>
> -aSame as -dpR
> -R,-rRecurse
> [...]
>
> ``
>
> This however, disappears when rolling back.
>
>
> All of them seem to be busybox related. For example the procps top works
> fine:
>
> ``
>
> nix-shell -p procps
>
> top ...
>
> ``
>
>
> Does anyone have suggestion here? It's actually the first time something
> 'mutable' happened to the nix system I'm using, it's updated to 17.03
> but this did not change the problems.
>
> Regards,
>
> Michael
>
> ___
> 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] Is CI of pull requests broken?

2017-04-09 Thread Maarten Hoogendoorn
Hopefully we can move soonish to a setup where maintainers (who have commit
access to the NixOS repo) can trigger a build on a hydraulic setup.

@grahamc, what's the timeline for that :)?

Op 9 apr. 2017 20:47 schreef "Layus" :

> On 09/04/17 11:13, Florent Becker wrote:
>
> Moreover, many of the merged pull requests [2] also have failed CI. It
> looks like the failed CI signal nothing to the people who do merge.
> Everybody just knows that CI is broken and its success or failure
> means nothing. Is it so?
>
> Failure means nothing, but success means the changes are not (too)
> broken. So it's not quite useless.
>
> Some failures are meaningful. It only takes a quick glance to tell if the
> failure is some kind of bustage or a real issue.
>
> ___
> 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] Typing nix − funding campaign

2017-03-28 Thread Maarten Hoogendoorn
Good luck, and have fun ;)

2017-03-28 11:45 GMT+02:00 Théophane Hufschmitt :

> Hi everyone,
>
> My internship has now started, and I'll try to post regular updates on
> https://typing-nix.regnat.ovh/ as promised. So if you're interested,
> just follow the rss :)
>
> > --
> > Théophane Hufschmitt
>
> Thu 12 Jan 17 − 14:13, Théophane Hufschmitt(rg_ni...@regnat.ovh) a écrit:
> > Hi,
> >
> > I am Théophane Hufschmitt, a french master degree CS student, and I
> > wish to start a six month length internship on giving nix a type
> > system.
> >
> > Numtide offered to fund a part of the internship, but we still need
> > some help for me to be able to start it.
> >
> > The goal of the internship is to design (and implement) a type system
> > for nix in order to be able to statically get some guaranties about
> > the well-foundness of the nixpkgs repo (or any nix expression), in
> > complement to hydra or travis tests which may let some inconsistencies
> > pass − especially on nixos module system which is way harder to test.
> >
> > Providing nix with a proper type system is a long running issue (see
> > https://github.com/NixOS/nix/issues/14), and I think a huge
> > opportunity for nix to improve its awesomeness.
> >
> > The crowdfunding campaign (and a slightly more detailled description of
> > the project) is open at https://www.gofundme.com/typing-nix, and you
> > are all invited to donate.
> >
> > Of course, I'll be happy to answer any question, by mail or on
> > irc/matrix (I am regnat[m] on 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] Hydra Building PRs

2017-03-07 Thread Maarten Hoogendoorn
Heh, I've been working on this as well today. Do you have a github repo
somewhere?

2017-03-07 14:27 GMT+01:00 Robin Gloster :

> I'm working on a bot to make sure only acknowledged PRs get built.
>
> That is a bit on hold until the release probably but I'm going to continue
> that definitely.
>
> That bot could then also include stuff like mentioning the correct
> maintainers, auto merging if the builds succeed, security tracking etc.
>
> Cheers
> Robin
>
> On 7 March 2017 14:15:56 CET, Graham Christensen 
> wrote:
>>
>> Bas van Dijk  writes:
>>
>>  Hi Graham, what's te status of this project?
>>>
>>
>> Great question. Dezgeg and I are working on bootstrapping some ARM
>> machines now, at which point I'll be working with Eelco to add
>> them to Hydra.
>>
>> I don't have an ETA, but finding a compatible time between Dezgeg and I
>> was a major blocker. From here, I expect the slow parts will be
>> coordinating with Eelco, then having nixpkgs build them.
>>
>> Graham
>> --
>>
>> nix-dev mailing list
>> nix-dev@lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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] Hydra Building PRs

2017-03-07 Thread Maarten Hoogendoorn
As a stop-gap measure, what about adding an external SSD drive via usb and
enabling swap?

2017-03-06 16:33 GMT+01:00 Bas van Dijk :

> On 28 January 2017 at 14:20, Graham Christensen 
> wrote:
>
>> Packet.net is also one of the only hosting companies I know of which
>> rents Cavium ThunderX ARMv8s, and they're very interested in our
>> supporting this architecture. Soon, with the help of Dezgeg,
>> prs.nix.gsc.io will also building PRs against ARMv8.
>>
>> After that works, I've spoken with Rob, and it sounds like
>> hydra.nixos.org will gain the ability to run ARMv8 builds, too.
>>
>
> Hi Graham, what's te status of this project?
>
> I'm currently upgrading some Raspberry Pi 3's s to NixOS-17.03 but the
> build of gcc is getting killed by what I expect is the OOM killer (Pi's
> only have 1GB of RAM). It would be great to utilise a Cavium ThunderX
> machine for this.
>
> Are there any blockers; technology-wise, timewise, fundingwise for this
> project to succeed? Do you need help? Maybe I can help.
>
> Regards,
>
> 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] Explicitly selecting sources for "src" in stdenv.mkDerivation?

2017-02-17 Thread Maarten Hoogendoorn
Awesome function Thomas!

Would you be willing to open a PR on nixpkgs for that?

2017-02-17 11:16 GMT+01:00 Thomas Hunger :

> Thanks for your replies everyone!
>
> Bas - your "toString" helped me over the finishing line. Pretty obvious in
> hindsight to use toString to force evaluation of src. I adapted your code
> to this:
>
> sourceByRegex = src: regexes: builtins.filterSource (path: type:
> let relPath = lib.removePrefix (toString src + "/") (toString path);
> in lib.any (re: builtins.match re relPath != null) regexes)
>   src;
>
> To be used like this:
>
> sourceByRegex /tmp/sourcetest [".*hs$", "someTestFile"]
>
> And then I have some predefined lists like cabalProject = [".*\.cabal$",
> ".*\.hs"]
>
> ~
>
>
>
> On 16 February 2017 at 21:58, Bas van Dijk  wrote:
>
>> At LumiGuide we're using the following function in our Haskell packages:
>>
>>   # Copy everything under src into the Nix store except those paths that
>> don't
>>   # have one of the specified allowedPrefixes.
>>   whitelistSource = src: allowedPrefixes:
>> builtins.filterSource
>>   (path: type:
>> lib.any (allowedPrefix: lib.hasPrefix (toString (src + "/${
>> allowedPrefix}")) path)
>> allowedPrefixes)
>>   src;
>>
>> To be used as for example:
>>
>>   src = lib.whitelistSource ./. [
>>   "lumi-central-server.cabal"
>>   "src"
>>   "default.conf"
>> ];
>>
>> Bas
>>
>> Op 16 feb. 2017 13:14 schreef "Thomas Hunger" :
>>
>> Hi,
>>
>> I am consistently struggling with the following in nix: I have a
>> repository and I want to specify derivations for some local sub-projects.
>> The obvious solution is
>>
>>   src = ./subproject-A;
>>
>> But that pulls in everything in that directory, including build
>> artifacts, or random intermediate data files.
>>
>> Another solution is
>>
>>   src = sourceFilesBySuffices ./subproject-A [".cabal" ".hs"];
>>
>> Which works reasonably well but introduces this weird dance where I
>> suffix files so they can be matched by sourceFilesBySuffices. Mostly I want
>> to do this:
>>
>>   src = [ ./subproject-A/schema.sql ./subproject-A/lib ];
>>
>> Or even get all the files checked into git:
>>
>>   src = gitFiles ./subproject-A; # does not work
>>
>> I was wondering whether any of you have this issue, and if you do: how do
>> you solve it?
>>
>> ~
>>
>> (see also https://github.com/NixOS/nix/issues/885)
>>
>> ___
>> 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] Feedback on workshop material

2017-02-15 Thread Maarten Hoogendoorn
Dear list,

I'm organizing a Nix workshop in Amsterdam on February 25th and have
started to create some workshop material for it [1].

Could you provide me with some feedback on the things I plan to cover? [2]

Thanks,
Maarten

[1] https://github.com/moretea/nix-workshop
[2] https://github.com/moretea/nix-workshop/blob/master/toc.md
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] RFC for RFCs

2017-02-12 Thread Maarten Hoogendoorn
Also see the notes that Arian took during the BoF session at FOSDEM:

We had a very spontaneous NixOS discussion panel at FOSDEM.
>
> I took minutes.  I must say they're a bit rushy at times, so add stuff to
> it
> you think isn't clear or is lacking in content.  Thanks!
>
>
> http://piratepad.net/1nHg65LMQj
>

2017-02-12 19:46 GMT+01:00 Thomas Hunger :

> That would be amazing! I actually have an email sitting in my draft folder
> proposing Nix Enhancement Proposals (NEPs).
>
> IMHO one of the things we aren't very good at is getting larger changes
> merged or rejected. We attract a lot of smart people because Nix is pretty
> awesome. These smart people then do substantial work, submit a PR and the
> PR bitrots. This is highly demotivating.
>
> An RFC process would allow us to get to an accept / reject early on, with
> the expectation that accepted RFCs will be merged when the technical work
> is done.
>
> I'll add more specific comments to your PR.
>
> ~
>
> On 12 February 2017 at 15:12, zimbatm  wrote:
>
>> Hi all,
>>
>> we discussed of introducing a RFC process during FOSDEM. The goal is to
>> help discussion for large or controversial changes which typically grind to
>> a halt.
>>
>> Here is an initial proposal based on the one from the Rust community:
>> https://github.com/zimbatm/rfcs/pull/1 . Please let me know what you
>> think.
>>
>> Cheers,
>> z
>>
>> ___
>> 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] Rust wants to integrate better in build systems

2017-02-07 Thread Maarten Hoogendoorn
Hi,

I would like to point the people that manage the rust compiler in nixpkgs
to a discussion on the roadmap for rust [1].

They are also discussing Bazel, a build tool from google that has some
similarities to Nix.

[1] https://github.com/rust-lang/rust-roadmap/issues/12
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] nix-bundle: Bundle Nix derivations to run anywhere

2017-02-07 Thread Maarten Hoogendoorn
It could also be used to implement an offline NixOS installer. I guess it
needs to run as root given that you're setting up a chroot env?

Op 7 feb. 2017 12:50 p.m. schreef "Shea Levy" :

+1! This is really cool.
Tomasz Czyż  writes:

> I would vote for mirroring this tool in nixos github namespace (or even
> trying to make this project official one) as it can have big impact of
> propagating/implementing nix ideas into environments where it's not
> straight forward to use it.
>
> What do you think people?
>
> 2017-02-07 11:31 GMT+00:00 Tomasz Czyż :
>
>> Matthew,
>> very good tool, thank you for sharing.
>>
>> 2017-02-07 10:32 GMT+00:00 Domen Kožar :
>>
>>> Awesome! I will need this very soon, good timing :)
>>>
>>> On Tue, Feb 7, 2017 at 11:30 AM, Moritz Ulrich 
>>> wrote:
>>>

 Hey Matthew,

 This sounds great! I'll give it a try :-)

 One question: Will it create a persistent /nix directory on the machine
 the generated binary is running?

 Cheers
 Moritz

 Matthew Bauer  writes:

 > GitHub page: https://github.com/matthewbauer/nix-bundle
 >
 > I just wanted to post about a little project I've been working on.
I'm
 > calling it "nix-bundle".
 >
 > Basically, what it does is: take a Nix closure, compress it into a
 > tarball, and turn that tarball into an executable using "Arx". The
 > final result looks like a plain shell script, but actually has a
 > tarball closure appended to it. When you run that script, Arx will
 > execute "nix-user-chroot" (which is included in the closure) which
 > will setup a /nix/ directory, then execute a target executable. All
of
 > this should work "out of the box" for any Nix derivation folder with
a
 > valid executable.
 >
 > For example, to generate a "hello" bundle:
 >
 > ./nix-bundle.sh hello /bin/hello
 >
 > "hello" specifies pkgs.hello and /bin/hello specifies the file
 > ${pkgs.helloi}/bin/hello to be executed. The output file will just be
 > called "hello".
 >p
 > The result is a "bundle" that can run without Nix being installed! No
 > external dependencies are needed because they are all contained
within
 > the Nix closure.
 >
 > There are two main drawbacks: slow startup and large file size.
 > Extracting the tarball takes time and this adds on to startup times.
 > Also, because everything is included from the Nix closure,
complicated
 > apps tend to be much larger because of the dependency tree.
 >
 > I've been experimenting with using AppImage as a format to package
 > them in, but it is not currently ready yet.
 > ___
 > 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
>>>
>>>
>>
>>
>> --
>> Tomasz Czyż
>>
>
>
>
> --
> Tomasz Czyż
> ___
> 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] Fosdem

2017-02-01 Thread Maarten Hoogendoorn
Me too!

I could not quickly find a dev-room for Nix, did I miss something?
I did notice that Sander van der Burg is going to talk about node2nix

Are there plans in place to have a meeting?

2017-02-01 13:38 GMT+01:00 Adrien Devresse :

> I will also be there
>
> Adrien
>
> Le 01. 02. 17 à 10:27, José San Leandro a écrit :
>
> Me too (+1)
>
> On Tue, Jan 31, 2017 at 9:55 AM, Théophane Hufschmitt  > wrote:
>
>> I'll be there too !
>> With another nixer friend
>>
>> Quoting zimbatm (2017-01-31 09:16:22)
>> > Count me in!
>> >
>> > On Mon, 30 Jan 2017, 21:56 Putten, A. van (Arian), 
>> > wrote:
>> >
>> > > I will be there!
>> > > --
>> > > *From:* nix-dev-boun...@lists.science.uu.nl [
>> > > nix-dev-boun...@lists.science.uu.nl] on behalf of Nathan Bijnens [
>> > > nat...@nathan.gs]
>> > > *Sent:* Monday, January 30, 2017 9:35 PM
>> > > *To:* Louis Taylor
>> > > *Cc:* nix-dev
>> > > *Subject:* Re: [Nix-dev] Fosdem
>> > >
>> > > I will be there on Saturday, mostly at the Big Data track.
>> > >
>> > > N.
>> > >
>> > > On Mon, Jan 30, 2017, 21:33 Louis Taylor  wrote:
>> > >
>> > > On Mon, Jan 30, 2017 at 8:16 PM, Nathan Bijnens 
>> wrote:
>> > > > Anyone going to Fosdem?
>> > >
>> > > February just isn't right without a trip to Brussels!
>> > >
>> > > ___
>> > > 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 
> listnix-...@lists.science.uu.nlhttp://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] Arch is dropping i686. Should we?

2017-01-28 Thread Maarten Hoogendoorn
2017-01-27 14:13 GMT+01:00 Eelco Dolstra :

>
> I think it's more an issue of build time, especially if we want Hydra to
> build
> PRs (which could trigger a full rebuild in the worst case).
>
>
I think we could/should use a GitHub bot like the @bors used by the Rust
language project.
This will prevent building PR's until a code review is done by a
contributor, who then will instruct the build bot to build the PR via a
GitHub comment. If the tests pass on Hydra, the PR will be merged
automatically into master.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-commits] [NixOS/nixpkgs] 3cbc64: minikube: 0.13.1 -> 0.15.0

2017-01-13 Thread Maarten Hoogendoorn
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: 3cbc64d5bb9f3f2a386409e87b924a35ddcd16e8
  
https://github.com/NixOS/nixpkgs/commit/3cbc64d5bb9f3f2a386409e87b924a35ddcd16e8
  Author: Maarten Hoogendoorn <maar...@moretea.nl>
  Date:   2017-01-13 (Fri, 13 Jan 2017)

  Changed paths:
M pkgs/applications/networking/cluster/minikube/default.nix

  Log Message:
  ---
  minikube: 0.13.1 -> 0.15.0


  Commit: af299d94ebc383b391dc58f165f40e8b4e25897a
  
https://github.com/NixOS/nixpkgs/commit/af299d94ebc383b391dc58f165f40e8b4e25897a
  Author: Maarten Hoogendoorn <maar...@moretea.nl>
  Date:   2017-01-13 (Fri, 13 Jan 2017)

  Changed paths:
M pkgs/applications/networking/cluster/minikube/default.nix

  Log Message:
  ---
  minikube: disable shell autocompletion; causes impurities.

Apparently the the generation of auto completion files depends on a
network connection. My `nix-build --pure` failed because of this.
Disabled autocompletion for now, given that minikube prints out lots of
documentaton if you provide partial commands.


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


Re: [Nix-dev] NixOS on (Android) Tablet

2017-01-13 Thread Maarten Hoogendoorn
You might want to look at Ubuntu Phone, which borrows heavily from the
Android kernel, but actually exposes a full Ubuntu system.
As a first step, you could look into running Ubuntu Phone, with nix
side-loaded.

Futhermore, there is some discussion in
https://github.com/NixOS/nixpkgs/issues/21222 on how to build Android with
nix.

2017-01-12 21:37 GMT+01:00 Matthias Beyer :

> Hi community.
>
> I just ordered a XIDO Z120 Tablet with the idea to try to get NixOS on
> it working, over the next few months, ... as an early summer-project.
>
> If you have _any_ input, I would highly value some short notes how to
> do it!
>
> I will, of course, publish the results of my research on my blog and
> notify this list about it!
>
> --
> 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


Re: [Nix-dev] Typing nix − funding campaign

2017-01-12 Thread Maarten Hoogendoorn
Interesting idea.

Note that Eelco's phd thesis about nix contains a formal definition of both
the syntax and semantics the language.
The whole thesis is well written and approachable.

Potential other benefits from a deeper analysis could include:
- generation of better documentation for helper functions
- or even IDE features like jump to definition


2017-01-12 14:13 GMT+01:00 Théophane Hufschmitt :

> Hi,
>
> I am Théophane Hufschmitt, a french master degree CS student, and I
> wish to start a six month length internship on giving nix a type
> system.
>
> Numtide offered to fund a part of the internship, but we still need
> some help for me to be able to start it.
>
> The goal of the internship is to design (and implement) a type system
> for nix in order to be able to statically get some guaranties about
> the well-foundness of the nixpkgs repo (or any nix expression), in
> complement to hydra or travis tests which may let some inconsistencies
> pass − especially on nixos module system which is way harder to test.
>
> Providing nix with a proper type system is a long running issue (see
> https://github.com/NixOS/nix/issues/14), and I think a huge
> opportunity for nix to improve its awesomeness.
>
> The crowdfunding campaign (and a slightly more detailled description of
> the project) is open at https://www.gofundme.com/typing-nix, and you
> are all invited to donate.
>
> Of course, I'll be happy to answer any question, by mail or on
> irc/matrix (I am regnat[m] on freenode).
>
> --
> Théophane Hufschmitt
>
> ___
> 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 17.03 release manager is Robin Gloster

2017-01-11 Thread Maarten Hoogendoorn
Thanks Robin, for picking this up, and to Domen for the awesome work you
did on the releases you managed.

2017-01-10 17:52 GMT+01:00 Domen Kožar :

> Hi all,
>
> I'm happy to announce Robin (https://github.com/globin) will be release
> manager starting with NixOS 17.03.
>
> He has been contributing to Nix ecosystem for over two years. I've met him
> personally at mayflower NixOS meetup and I'm sure he'll take release
> management to the next step.
>
> Please congratulate him, this is huge effort for him towards NixOS
> community!
>
> 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


[Nix-dev] Nix workshop in Amsterdam: Bring your own app, we'll package it together

2017-01-04 Thread Maarten Hoogendoorn
Hi all,

I would like to invite anyone who is interested to join us in Amsterdam on
Saturday 25th of February to learn more about Nix, or help someone else
learn about it :)

The plan is to have some talks about Nix, nixpkgs and NixOS, after which
we'd start packaging or deploying apps with Nix tools.

For more information and registration, see
https://www.meetup.com/Amsterdam-Nix-Meetup/events/23275/

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


Re: [Nix-dev] Expression to list all packages from ?

2017-01-03 Thread Maarten Hoogendoorn
I hacked something together:
https://gist.github.com/moretea/a28f0fa2afe99fc6cd026ac56460bf84

2017-01-03 12:19 GMT+01:00 Matthias Beyer :

> Hi,
>
> I tried to hack a nix expression to list all package names for a given
> maintainer. But I failed. Is there someone out there who has such an
> expression?
>
> Also, I wanted to wish you all a very nice year 2017!
>
> --
> 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


[Nix-commits] [NixOS/nixpkgs] b217c0: yarn: init at 0.17.8 (#20635)

2016-12-14 Thread Maarten Hoogendoorn
  Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: b217c0a99ba22371b2a73821a8e127892f2e24d4
  
https://github.com/NixOS/nixpkgs/commit/b217c0a99ba22371b2a73821a8e127892f2e24d4
  Author: Maarten Hoogendoorn <maar...@moretea.nl>
  Date:   2016-12-14 (Wed, 14 Dec 2016)

  Changed paths:
M pkgs/development/node-packages/node-env.nix
M pkgs/development/node-packages/node-packages-v4.nix
M pkgs/development/node-packages/node-packages-v6.nix
M pkgs/development/node-packages/node-packages.json
M pkgs/top-level/node-packages.json

  Log Message:
  ---
  yarn: init at 0.17.8 (#20635)


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


Re: [Nix-dev] PatchELF in Bundix's postBuild step

2016-12-02 Thread Maarten Hoogendoorn
I'm trying to use grpc (http://www.grpc.io/)  from ruby. This gem has some
hardcoded paths in there, and apparently also tries to write to a directory
owned by the ruby interpreter after building a native extension. I've
opened a issue for this at https://github.com/grpc/grpc/issues/8935

2016-12-01 22:29 GMT+01:00 zimbatm <zimb...@zimbatm.com>:

> Yes that's it. There is also a pkgs.defaultGemConfig that contains common
> overrides, like injecting libxml for the nokogiri gem. You might want to
> merge it with your override (or submit yours to nixpkgs).
>
> On Thu, 1 Dec 2016, 20:51 Maarten Hoogendoorn, <maar...@moretea.nl> wrote:
>
>> OK, I found a solution after taking a longer look at the bundlerEnv
>> implementation.
>> Each gem is packaged as a separate derivation (which makes complete
>> sense).
>> BundlerEnv offers the `gemConfig', in which one can set another
>> postInstall step.
>>
>> In my case, the following snippet works:
>>
>> with pkgs; (bundlerEnv {
>> name ="ruby-protoc-v3";
>> inherit ruby;
>> gemfile= ./Gemfile;
>> lockfile = ./Gemfile.lock;
>> gemset = ./gemset.nix;
>> gemConfig = {
>>   grpc-tools = attr: {
>> postInstall= ''
>>   for file in $(find $out/lib/ruby/gems/2.3.0/gems/
>> grpc-tools-1.0.1/bin/x86_64-linux -type f -executable ); do
>> patchelf --set-interpreter 
>> ${stdenv.glibc}/lib/ld-linux-x86-64.so.2
>> $file
>>   done
>> '';
>>   };
>>     };
>> })
>>
>> I think that I got confused by the fact that I did not see any symlinks
>> during my investigation. I must have missed that somewhere.
>>
>> - Maarten
>>
>> 2016-12-01 21:24 GMT+01:00 Maarten Hoogendoorn <maar...@moretea.nl>:
>>
>> Hi,
>>
>> I'm trying to build a gem that has vendored a statically compiled program
>> (that still depends on /lib64/ld-linux-x86-64.so.2).
>>
>> I've tried to use patchelf in the postBuild in a bundlerEnv, but it's
>> complaining about not having write permissions to $out
>>
>> I wrote a one-liner to check for .nix files that contained both the words
>> bundlerEnv and patchelf, but only the top-level/all-packages.nix matched
>> both.
>>
>> I tried to create another derivation, that pulls all file in from the
>> bundlerEnv, and then patches the elf file, but it's resulting in the same
>> error message.
>>
>> A nix-expression that reproduces this error is attached.
>>
>>
>> ___
>> 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] PatchELF in Bundix's postBuild step

2016-12-01 Thread Maarten Hoogendoorn
OK, I found a solution after taking a longer look at the bundlerEnv
implementation.
Each gem is packaged as a separate derivation (which makes complete sense).
BundlerEnv offers the `gemConfig', in which one can set another postInstall
step.

In my case, the following snippet works:

with pkgs; (bundlerEnv {
name ="ruby-protoc-v3";
inherit ruby;
gemfile= ./Gemfile;
lockfile = ./Gemfile.lock;
gemset = ./gemset.nix;
gemConfig = {
  grpc-tools = attr: {
postInstall= ''
  for file in $(find
$out/lib/ruby/gems/2.3.0/gems/grpc-tools-1.0.1/bin/x86_64-linux -type f
-executable ); do
patchelf --set-interpreter
${stdenv.glibc}/lib/ld-linux-x86-64.so.2 $file
  done
'';
  };
};
})

I think that I got confused by the fact that I did not see any symlinks
during my investigation. I must have missed that somewhere.

- Maarten

2016-12-01 21:24 GMT+01:00 Maarten Hoogendoorn <maar...@moretea.nl>:

> Hi,
>
> I'm trying to build a gem that has vendored a statically compiled program
> (that still depends on /lib64/ld-linux-x86-64.so.2).
>
> I've tried to use patchelf in the postBuild in a bundlerEnv, but it's
> complaining about not having write permissions to $out
>
> I wrote a one-liner to check for .nix files that contained both the words
> bundlerEnv and patchelf, but only the top-level/all-packages.nix matched
> both.
>
> I tried to create another derivation, that pulls all file in from the
> bundlerEnv, and then patches the elf file, but it's resulting in the same
> error message.
>
> A nix-expression that reproduces this error is attached.
>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] PatchELF in Bundix's postBuild step

2016-12-01 Thread Maarten Hoogendoorn
Hi,

I'm trying to build a gem that has vendored a statically compiled program
(that still depends on /lib64/ld-linux-x86-64.so.2).

I've tried to use patchelf in the postBuild in a bundlerEnv, but it's
complaining about not having write permissions to $out

I wrote a one-liner to check for .nix files that contained both the words
bundlerEnv and patchelf, but only the top-level/all-packages.nix matched
both.

I tried to create another derivation, that pulls all file in from the
bundlerEnv, and then patches the elf file, but it's resulting in the same
error message.

A nix-expression that reproduces this error is attached.


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


Re: [Nix-dev] Distributing files between machines in a nixops deployment

2016-11-19 Thread Maarten Hoogendoorn
I'm not pretending to be a NixOps expert, but I think the approach of
generating the secret in the "deployment" machine is good enough.
You could store the private key encrypted in a git repository. Have you
seen this [1] blog post? It describes how to do this in a team.

Best regards,
Maarten


2016-11-19 12:50 GMT+01:00 Marius Bergmann :

> On 2016-11-19 12:46, Arnold Krille wrote:
> > On Sat, 19 Nov 2016 12:10:59 +0100 Marius Bergmann 
> > wrote:
> >> Is it possible to declare the distribution of a file (in my case a ssh
> >> server/client public key) to different machines in a nixops
> >> deployment?
> >>
> >> I want to create a client keypair on one machine and then authorize
> >> the public part on several other machines in the deployment. Those
> >> other machines' public server keys should also be added to the
> >> known_hosts of the machine logging into them.
> >>
> >> I know I could create all the keypairs on the machine running nixops
> >> and send both the public as well as the private keys over the
> >> network, but I would like to find out if there's a way around it.
> >
> > I think this is one of the things you don't do/want with Nix/NixOps as
> > this is essentially self-modifying deployment. Which makes the
> > deployment non-deterministic and unreproducible in the strict sense.
> > With deployment-/configuration-management systems that have a central
> > node and database, like chef and puppet can have, you can do such
> > things. For Nix this is counter-intuitive.
> >
> > - Arnold
>
> Do you have a recommendation on how to handle my use case then? In
> practice, I need this to allow the backup user to log into the machines
> being backed up. Would you use a central location for all the key pairs?
> ___
> 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] typed nix

2016-08-30 Thread Maarten Hoogendoorn
missed the list, sorry.

2016-08-30 14:01 GMT+02:00 Maarten Hoogendoorn <maar...@moretea.nl>:

> I started to experiment a bit with this, when I tried to add documentation
> to functions at the 3 day hackathon in Berlin last June.
>
> A small youtube demo: https://www.youtube.com/watch?v=ahVu3tjrriM
>
>
> 2016-08-30 5:52 GMT+02:00 Daniel Hlynskyi <abcz2.upr...@gmail.com>:
>
>> Dynamic attributes make exact typing hard. Perhaps Nix will adopt the
>> gradually typed approach in a future.
>>
>> https://en.wikipedia.org/wiki/Gradual_typing#Examples
>>
>> But would that be worth of it?
>>
>> 2016-08-29 21:47 GMT+00:00 stewart mackenzie <setor...@gmail.com>:
>>
>>> per chance, is there work underway to make nix a typed language?
>>>
>>> kr/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
>>
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] nix-update --channel broken on unstable?

2016-08-23 Thread Maarten Hoogendoorn
Hi, it appears that the nix-update command is broken. See the output below.


$ nix-channel --update
downloading Nix expressions from ‘
https://nixos.org/channels/nixos-unstable/nixexprs.tar.bz2’...
downloading ‘https://nixos.org/channels/nixos-unstable/nixexprs.tar.bz2’...
[0/0 KiB, 0.0 KiB/s]
error: unable to download ‘
https://nixos.org/channels/nixos-unstable/nixexprs.tar.bz2’: HTTP response
code said error (22)
cannot fetch ‘https://nixos.org/channels/nixos-unstable/nixexprs.tar.bz2’

[maarten@maarten-laptop:~/cs/containerpilot-ui]$ curl
https://nixos.org/channels/nixos-unstable/nixexprs.tar.bz2

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="en" xml:lang="en">

Access forbidden!
mailto:eelco.dols...@logicblox.com; />




Access forbidden!





You don't have permission to access the requested object.
It is either read-protected or not readable by the server.





If you think this is a server error, please contact
the mailto:eelco.dols...@logicblox.com;>webmaster.



Error 403

  nixos.org
  Apache/2.4.18 (Unix) OpenSSL/1.0.2h PHP/5.6.24





[maarten@maarten-laptop:~/cs/containerpilot-ui]$
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] using qemu virtual machine for testing software

2016-07-29 Thread Maarten Hoogendoorn
Am I correct to think that  you are trying to connect to the postgresql
instance in the VM from your host machine?
The documentation of forwardPort states: "Forward a TCP port on the host to
a TCP port on the guest.  Useful during interactive testing."
So it provides TCP forwarding in the direction host -> vm guest, it does
not expose a VM guests' port on the host.

AFAIK, the purpose of this vmtools machinery is to run tests inside the VM,
not to provide VM's that you can use in your other tests.
If you want access to debug your postgres db, you can either add assertions
/ psql cli commands to the test script, or you could see if it's possible
to (ab)use netcat to create a bash shell in your test vm machine.


2016-07-29 2:40 GMT+02:00 Tomasz Czyż :

> Hi,
>
> I'm trying to use same mechanism as nixos for testing with vm.
> I've created "run-vm.nix" and I can run vm with "nix-build run-vm.nix".
>
> I can't connect to forwarded port and I don't know how to connect/interact
> with the machine. Is there anyone who know how I could connect to this
> machine and would be willing to explain?
>
> run-vm.nix:
>
> {system?builtins.currentSystem}:
> let
>   pkgs = import  {};
>   machine = {...}: {
>   services.postgresql = {
>   enable=true;
>   enableTCPIP = true;
>   };
>   # networking.firewall.enable=false; # I've tried with this
>};
>   testing = import {inherit system;};
>   test = testing.makeTest ({
> machine = machine;
> testScript=''
>   $machine->start;
>   $machine->waitForUnit("postgresql.service");
>   $machine->waitForOpenPort(5432);
>   $machine->forwardPort(9432, 5432);
>   # $machine->forwardPort(5432, 9432); # I've tried with this as well
>   # $machine->execute("sleep 999"); # I've tried with this as well
>   $machine->waitForShutdown;
> '';
>   });
> in
> test
>
>
>
> ___
> 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] vmTools.runInLinuxImage with ubuntu 1204 image blocks on getrandom()

2016-07-26 Thread Maarten Hoogendoorn
OK, fixed this problem by adding the virtio_rng device to the kernel and
qemu opts, see below.

Would a PR to make these additions the default in
build-support/vm/default.nix be appreciated?

with import  {}; with pkgs;
let
 script = ''
   # /dev/urandom works fine
   dd if=/dev/urandom of=/dev/null bs=1M count=1

   # /dev/random only works if virtio_rng is enabled.
   dd if=/dev/random of=/dev/null bs=1M count=1
 '';
  img = runCommand "nix-binary-tarball-test" {
diskImage = vmTools.diskImages.ubuntu1204x86_64;
QEMU_OPTS = "-device virtio-rng-pci";
   } script;
   runCustomInImage = vmTools.override {
 rootModules = [ "virtio_rng" "virtio_pci" "virtio_blk"
"virtio_balloon" "ext4" "unix" "9p" "9pnet_virtio" "rtc_cmos" ];
   };
in
   runCustomInImage.runInLinuxImage img #<- does work
#  vmTools.runInLinuxImage img # < - does not work

2016-07-16 15:39 GMT+02:00 Maarten Hoogendoorn <maar...@moretea.nl>:

> Hi there,
>
> I'm trying to run some tests on a binary program on ubuntu 1204 using
> vmTools.runInLinuxImage. It just blocks on getrandom().
>
> I've created a minimal reproducible example:
>
> with import  {}; with pkgs;
> let
>  script = ''
># /dev/urandom works fine
>dd if=/dev/urandom of=/dev/null bs=1M count=1
>
>   # /dev/random does not work!
>${pkgs.strace}/bin/strace \
>  dd if=/dev/random of=/dev/null bs=1M count=1
>  '';
>   img = runCommand "nix-binary-tarball-test" {
> diskImage = vmTools.diskImages.ubuntu1204x86_64;
> #QEMU_OPTS = "-device virtio-rng-pci";
>} script;
> in
>   vmTools.runInLinuxImage img
>
> I read somewhere that adding a virtio-rng-pci device could solve this,
> but it made no difference.
>
> Could someone confirm this behavior? And maybe one of you has an idea on
> how to fix this.
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] Mesos fetcher

2016-07-26 Thread Maarten Hoogendoorn
Hi,

Is anyone on the list using mesos?

I've tried to deploy a mesos framework (mesos-kafka) that depends on the
extraction of archives, that are downloaded by the mesos fetcher [1].

I've opened an issue about this on the nixpkgs repository as well [2].

[1] http://mesos.apache.org/documentation/latest/fetcher/
[2] https://github.com/NixOS/nixpkgs/issues/16917
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] NixOS 16.09 stable branch-off is due in ~a month

2016-07-26 Thread Maarten Hoogendoorn
Hi Domen,

How do you track things that must be done before the 16.09 release is
branched? Via the 16.09 milestone?

2016-07-25 16:00 GMT+02:00 Domen Kožar :

> Hi all,
>
> I'd like to remind you all that 16.09 will branch from master at the end
> of August. Then we have a month to release a stable NixOS version.
>
> Please, set milestone for issues/PRs that you'd like to get into next
> release and make sure they land in master until end of August.
>
> If something is unclear, ping @domenkozar and I'll try to answer shortly.
>
> Release process is still not documented clearly, but I'll make sure we
> really get it into the manual for this release. Meanwhile see
> https://github.com/NixOS/nixpkgs/issues/4442
>
> 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


[Nix-dev] overridePackages with nixops

2016-07-21 Thread Maarten Hoogendoorn
Hi there,

How could one override a package used in a service definition on nixops?
Defining config.packageOverrides results in an error message:

error: Module `:anon-1:anon-1' has an unsupported attribute `deployment'.
This is caused by assignments to the top-level attributes `config' or
`options'.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] vmTools.runInLinuxImage with ubuntu 1204 image blocks on getrandom()

2016-07-16 Thread Maarten Hoogendoorn
Hi there,

I'm trying to run some tests on a binary program on ubuntu 1204 using
vmTools.runInLinuxImage. It just blocks on getrandom().

I've created a minimal reproducible example:

with import  {}; with pkgs;
let
 script = ''
   # /dev/urandom works fine
   dd if=/dev/urandom of=/dev/null bs=1M count=1

  # /dev/random does not work!
   ${pkgs.strace}/bin/strace \
 dd if=/dev/random of=/dev/null bs=1M count=1
 '';
  img = runCommand "nix-binary-tarball-test" {
diskImage = vmTools.diskImages.ubuntu1204x86_64;
#QEMU_OPTS = "-device virtio-rng-pci";
   } script;
in
  vmTools.runInLinuxImage img

I read somewhere that adding a virtio-rng-pci device could solve this, but
it made no difference.

Could someone confirm this behavior? And maybe one of you has an idea on
how to fix this.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Override systemd service definition generated by nixos service

2016-07-14 Thread Maarten Hoogendoorn
That did the trick for making programs available, thanks.

2016-07-13 15:02 GMT+02:00 Rickard Nilsson <rickard.nils...@telia.com>:

> Hi,
>
> On 07/13/2016 02:27 PM, Maarten Hoogendoorn wrote:
> > Hi,
> >
> > I have to make some other derivations visible to mesos, and the jdk in
> > particular.
> >
> > What would be the best way forward: to override the mesos package, or
> > the service?
> > Alternatively, I could create a wrapper derivation (mesos-with-jdk), and
> > make the package used by the mesos service configurable.
> >
> > I'd like to hear your thoughts about these options.
>
> In what sense should jdk be available to mesos? Like, in the PATH? If
> so, you could just add this to your config:
>
>   services.mesos-master.path = [ pkgs.jdk ];
>
> (and do the same to any other mesos services needing jdk)
>
> If this is not something that is specific to your environment, I suggest
> opening a PR.
>
>
>   / Rickard
>
> ___
> 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] Override systemd service definition generated by nixos service

2016-07-13 Thread Maarten Hoogendoorn
Hi,

I have to make some other derivations visible to mesos, and the jdk in
particular.

What would be the best way forward: to override the mesos package, or the
service?
Alternatively, I could create a wrapper derivation (mesos-with-jdk), and
make the package used by the mesos service configurable.

I'd like to hear your thoughts about these options.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Pinning nixpkgs on unstable channel: retention of cached packages

2016-07-12 Thread Maarten Hoogendoorn
Good to know. I expected that something like this would be the case.

The context is that I'm doing some performance benchmarks of kafka and
kafka running on top of mesos, and would like to have a 100% reproducible
setup that I can give to our client. I guess that in theory, I could export
the closures of the nixops machines and store them somewhere, but that's
probably overkill :)

Thanks!

2016-07-11 16:25 GMT+02:00 Eelco Dolstra <eelco.dols...@logicblox.com>:

> Hi,
>
> On 07/11/2016 10:54 AM, Maarten Hoogendoorn wrote:
>
> > I was wondering if it's safe to depend on any commit in the unstable
> channel,
> > and still be able to fetch the derivations build by Hydra from the
> binary cache.
>
> No. Currently any version except the most recent of any channel may be
> garbage-collected at some point. Note that this also applies to the stable
> channels.
>
> --
> 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] nix as a library

2016-07-12 Thread Maarten Hoogendoorn
You could try to modify nix-repl to have a "daemon" mode, that listens on a
unix socket, and implements a simple json protocol. This could also open
doors for easy evaluation of nix-lang snippets in text editors.

2016-07-09 19:16 GMT+02:00 stewart mackenzie :

> Hmm on second thoughts, it's probably best to expose a nix-repl... it
> would be much more powerful. Thanks for than Vladimir!
>
> The user interface (ie compile button, whatever) could just write
> strings directly into the repl then linefeed, or you could just type
> it yourself.
>
> This would simplify things quite a lot actually.
> ___
> 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] Pinning nixpkgs on unstable channel: retention of cached packages

2016-07-11 Thread Maarten Hoogendoorn
Hi there,

I was wondering if it's safe to depend on any commit in the unstable
channel, and still be able to fetch the derivations build by Hydra from the
binary cache.

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


Re: [Nix-dev] Add banner to wiki to tell (new) users that it's not maintained

2016-06-30 Thread Maarten Hoogendoorn
It appears that this theme is disabled:
https://github.com/NixOS/nixos-org-configurations/blob/master/nixos-org/webserver.nix#L153
I tried to find some element that should be present in the theme, but was
not.

2016-06-30 13:41 GMT+02:00 zimbatm <zimb...@zimbatm.com>:

> Good idea. I think this could be done by changing
> https://github.com/NixOS/nixos-org-configurations/blob/master/delft/wiki-skins/nixos.php
>
>
> On Thu, 30 Jun 2016 at 12:29 Maarten Hoogendoorn <maar...@moretea.nl>
> wrote:
>
>> I only learned a few weeks ago that the wiki is not maintained anymore,
>> and that the content is going to be moved into the manuals.
>>
>> Could we add a banner to the top of the wiki to tell (new) users that the
>> information in there might be out of date?
>>
>> This might prevent a lot of frustration for new users.
>> ___
>> 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] Add banner to wiki to tell (new) users that it's not maintained

2016-06-30 Thread Maarten Hoogendoorn
I only learned a few weeks ago that the wiki is not maintained anymore, and
that the content is going to be moved into the manuals.

Could we add a banner to the top of the wiki to tell (new) users that the
information in there might be out of date?

This might prevent a lot of frustration for new users.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Building upstream nixops (to include in another project) fails

2016-06-29 Thread Maarten Hoogendoorn
2016-06-29 16:06 GMT+02:00 Maarten Hoogendoorn <maar...@moretea.nl>:

> Yes, I looked at the ./dev-shell.sh file on which attribute I should
> depend on.
>
> I want to have a nix-shell with both a custom version of nixops, and some
> other packages.
>
> My other approach does not work either, but with a more interesting error
> message:
>
> $ nix-shell --show-trace
> these derivations will be built:
>
> /nix/store/r1p3m87criwffxwn2is5a06qlrxyrbjj-nixops-tarball-1.4pre0_abcdef.drv
>   /nix/store/ap23fcb9jqg4h5fifsbawys7bvk1a5mz-nixops-1.4pre0_abcdef.drv
> building path(s)
> ‘/nix/store/1xb0f4jcivcg7fxpb4605hi55cm9j12l-nixops-tarball-1.4pre0_abcdef’
> unpacking sources
> unpacking source archive /nix/store/hixjn9gi008bqwlakmnwqpci2rc7x4jb-nixops
> *do not know how to unpack source archive
> /nix/store/hixjn9gi008bqwlakmnwqpci2rc7x4jb-nixops*
> build time elapsed:  0m0.032s 0m0.008s 0m0.000s 0m0.002s
> builder for
> ‘/nix/store/r1p3m87criwffxwn2is5a06qlrxyrbjj-nixops-tarball-1.4pre0_abcdef.drv’
> failed with exit code 1
> cannot build derivation
> ‘/nix/store/ap23fcb9jqg4h5fifsbawys7bvk1a5mz-nixops-1.4pre0_abcdef.drv’: 1
> dependencies couldn't be built
> error: build of
> ‘/nix/store/ap23fcb9jqg4h5fifsbawys7bvk1a5mz-nixops-1.4pre0_abcdef.drv’
> failed
> /run/current-system/sw/bin/nix-shell: failed to build all dependencies
>
>
> Expression:
>
> let
>   pkgs = import  {};
>   stdenv = pkgs.stdenv;
>   custom_nixops = (import ./nixops/release.nix {}).build.x86_64-linux;
>
>   env = stdenv.mkDerivation rec {
> name = "noez";
> src = ./.;
> buildInputs = with pkgs; [ ruby custom_nixops ];
>   };
> in
>   env
>
>
>
> 2016-06-29 14:20 GMT+02:00 Domen Kožar <do...@dev.si>:
>
>> You have build nixops using release.nix, which populates the _version_
>> string
>>
>
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] Building upstream nixops (to include in another project) fails

2016-06-29 Thread Maarten Hoogendoorn
Hi all,

I'm trying to build a newer version of nixops than that is present in
nixpkgs. In need this newer version, since I require this patch [1].

Building nixops with the following expression:

with (import ) {};
with pkgs;
callPackage (import
) rec {
  version = "1.04pre0_0xz1nz3";
  src = fetchFromGitHub {
owner = "NixOs";
repo = "nixops";

# latest version in git
#rev = "e6f012a95988e52cc6555c04242056d319478b24";
#sha256 = "0xz1nz3a49vwhzkjb0b9c7c83iwfpkpvsnq5bpgm2w3qii75vhkj";

# version with my patch
rev = "94bf6d95134790e04a3f8fa6d51c75eda2c4ba19";
sha256 = "1hkp634lkc0p22jrfxpq8lwlsrjgi2x9nxb6bab2fl01r4jrmp8l";
  };
}

This fails in the installing python phase:

*running install_scripts*
creating build/bdist.linux-x86_64/wheel/nixops-_version_.data
creating build/bdist.linux-x86_64/wheel/nixops-_version_.data/scripts
copying build/scripts-2.7/nixops ->
build/bdist.linux-x86_64/wheel/nixops-_version_.data/scripts
changing mode of
build/bdist.linux-x86_64/wheel/nixops-_version_.data/scripts/nixops to 755
creating build/bdist.linux-x86_64/wheel/nixops-_version_.dist-info/WHEEL
*installing*
/tmp/nix-build-nixops-1.04pre0_0xz1nz3.drv-0/nixops-94bf6d95134790e04a3f8fa6d51c75eda2c4ba19-src/dist
/tmp/nix-build-nixops-1.04pre0_0xz1nz3.drv-0/nixops-94bf6d95134790e04a3f8fa6d51c75eda2c4ba19-src
Ignoring indexes: https://pypi.python.org/simple
*nixops-_version_-py2-none-any.whl is not a valid wheel filename.*
builder for
‘/nix/store/qxvwma9gk0myic2k6fcwczcmlyqchk7c-nixops-1.04pre0_0xz1nz3.drv’
failed with exit code 1
error: build of
‘/nix/store/qxvwma9gk0myic2k6fcwczcmlyqchk7c-nixops-1.04pre0_0xz1nz3.drv’
failed

I know nothing about python packaging, does someone have a clue on how to
fix this?

- maarten

[1]
https://github.com/NixOS/nixops/commit/94bf6d95134790e04a3f8fa6d51c75eda2c4ba19
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] Amsterdam Nix meetup

2016-06-29 Thread Maarten Hoogendoorn
Hi felllow nixers,

I've started a Amsterdam Nix meetup [1] and plan to speak a bit more at
other meetups about nix. If you're interested in attending and/or speaking
at this meetup!, please register (or send an email to me).

[1] http://www.meetup.com/Amsterdam-Nix-Meetup/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] Building mesos from git

2016-06-23 Thread Maarten Hoogendoorn
Hi there,

I want to experiment a bit with some of the features of a unreleased mesos.

I've copied the mesos package definition from nixpkgs to a separate dir,
and have modified it to point to a git repository. The result is in a
GitHub repo [1]

The log [2] shows that it compiles all C++ stuff, but fails on creating a
python egg:
ValueError: ZIP does not support timestamps before 1980

Makefile:11639: recipe for target 'python/dist/mesos-1.0.0-py2.7.egg' failed
make[2]: *** [python/dist/mesos-1.0.0-py2.7.egg] Error 1
make[2]: Leaving directory
'/tmp/nix-build-mesos-git-head.drv-0/mesos-d1b681f/src'
Makefile:3175: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory
'/tmp/nix-build-mesos-git-head.drv-0/mesos-d1b681f/src'
Makefile:762: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1
builder for ‘/nix/store/3h0hgqp70x0kzrwsx4v8imvi4g5ay3x4-mesos-git-head.drv’
failed with exit code 2
error: build of
‘/nix/store/3h0hgqp70x0kzrwsx4v8imvi4g5ay3x4-mesos-git-head.drv’
failed

I could use some tips on how to proceed. I'd like to keep python support in
there, but I'm also open to some tips on how to disable python builds.

Thanks,
Maarten


[1] https://github.com/moretea/nixops-mesos-git-head
[2]
https://raw.githubusercontent.com/moretea/nixops-mesos-git-head/master/log.txt
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] How to access makeTest function from nixpkgs/nixos/lib/testing.nix?

2016-06-22 Thread Maarten Hoogendoorn
Cool.

For development environments, it is recommended to use the nix-shell
program.

A good example is nixops (nixos/nixops on github).

PS, I've added the list again.
Op 23 jun. 2016 02:34 schreef "Tomasz Czyż" <tomasz.c...@gmail.com>:

> 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 <maar...@moretea.nl>:
>
>> 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ż" <tomasz.c...@gmail.com>:
>>
>> 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 <maar...@moretea.nl>:
>>>
>>>> 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ż <tomasz.c...@gmail.com>:
>>>>
>>>>> 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 tw

Re: [Nix-dev] How to access makeTest function from nixpkgs/nixos/lib/testing.nix?

2016-06-22 Thread 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 I prefer to
> avoid that if possible.
>
> If anyone have some suggestions please let me know.
>
> Tom
>
> --
> Tomasz Czyż
>
> ___
> 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] API for nixops / distributed storage of sqlite3 db

2016-06-20 Thread Maarten Hoogendoorn
I've read/heard somewhere that there were plans for an API for nixops. I
think I saw it on a recording of a talk at the nix meeting in Germany in
the last quarter of last year.
How are things progressing on that front? I would be willing to contribute
to this effort.

Secondly, is there existing work on having a distributed storage for the
state in nixops? I found this [1] email thread in February last year.
This is another area that I'd be interested in to work on.

[1] http://lists.science.uu.nl/pipermail/nix-dev/2015-February/016306.html
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Malicious installation methods

2016-06-17 Thread Maarten Hoogendoorn
First of all, you can install nix in another location, but then you won't
be able to use the binary cache anymore.

I thought a bit about how we could make this work:
- store the nix store physically in /var/lib/nix/store on Debian
- create a union fs in /var/lib/nix/nix-root of / and /var/lib/nix/store
- create "entrypoint" wrapper scripts in some well known path for each
profile, as a post processing step after profiles are generated.

These wrapper scripts would call a setuid binary to chroot into
/var/lib/nix/nix-root. Once a program enters the nix-universe chroot, it
can use the orignal binaries in the profiles again.

Please shoot holes in my reasoning!

2016-06-18 0:00 GMT+02:00 Yui Hirasawa :

> >>> True, of course. But, there is a class of software projects which
> will
> >>> likely never be "packaged" by package managers - namely, other
> package
> >>> managers. Nix falls into this class, along with, for example, NPM,
> >>> Brew, Oh-My-Zsh, and others.
> >>
> >> What reason would there to not package other package managers?
> >
> > IIRC, Debian won't package Nix because it violates the FHS (by
> requiring
> a /nix
> > directory).
> 
>  Is the nix root dir configurable? Would it be that horrible to have
>  /opt/nix or /var/lib/nix or something else be the nix root on Debian?
> >>>
> >>> It's not strictly required, but it would mean losing out on all the
> binary
> >>> packages provided by the CI.
> >>
> >> Aren't they built in a chroot like Guix does? Why would anything break
> >> just because you change where they are installed?
> >
> > Because it invalidates all the store references.
>
> Seems like nix needs some redesign then.
> ___
> 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] Link to nix.useSandbox in pull request template

2016-06-17 Thread Maarten Hoogendoorn
I've encountered a missing dependency in a package, and created a pull
request [1] to add the dependency.

However, I'm not completely sure how to build/test this using sandboxing as
is suggested in the pull request template. Could the link to the
documentation be broken?

Thanks,
Maarten

[1] https://github.com/NixOS/nixpkgs/pull/16304
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


[Nix-dev] Twitter account?

2016-06-08 Thread Maarten Hoogendoorn
Hi there,

I'm about to post a blogpost on Nix. We'd like to tweet about this, and
include a twitter handle for nix*. Does such an account exist :)?

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


Re: [Nix-dev] Nixops fails to log into virtualbox machines on osx.

2016-06-07 Thread Maarten Hoogendoorn
That did the trick. I assumed the ssh invoked in nixops would use it's own
ssh configuration file.

2016-06-07 17:22 GMT+02:00 zimbatm <zimb...@zimbatm.com>:

> Can you try to edit you ~/.ssh/config and add "StrictHostKeyChecking no"
> in the file ? What it does is automatically accept new hosts in the
> ~/.ssh/known_hosts provided the machine doesn't already exists.
>
> On Tue, 7 Jun 2016 at 14:24 Maarten Hoogendoorn <maar...@moretea.nl>
> wrote:
>
>> Hi there,
>>
>> As mentioned in the previous email I sent to the list, I'm trying to work
>> with nixops on osx.
>>
>> The next error I encountered is that nixops is unable to log in to the
>> VM's due to unknown host keys, see the (partial) output of nixops deploy
>> below:
>>
>> containersolutionss-MacBook-Pro:blog-nix containersolutions$ nixops deploy
>>
>> *mesos-slave-1.> *creating VirtualBox VM...
>>
>> *mesos-slave-1.> *Virtual machine
>> 'nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-slave-1' is created and
>> registered.
>>
>> *mesos-slave-1.> *UUID: 039cb7f7-af9a-486f-867d-49f7ef729136
>>
>> *mesos-slave-0.> *Settings file: '/Users/containersolutions/VirtualBox
>> VMs/nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-slave-0/nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-slave-0.vbox'
>>
>> *mesos-master-0> *creating disk ‘disk1’...
>>
>> *mesos-master-1> *Clone medium created in format 'VDI'. UUID:
>> 7d898ca7-1d46-4a40-9210-1115d34310d5
>>
>> *mesos-master-1> *attaching disk ‘disk1’...
>>
>> *mesos-master-1> *Waiting for VM
>> "nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-master-1" to power on...
>>
>> *mesos-master-1> *VM
>> "nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-master-1" has been
>> successfully started.
>>
>> *mesos-master-1> *waiting for IP address...
>>
>> *mesos-slave-1.> *.
>>
>> *mesos-master-0> * 192.168.56.109
>>
>> *mesos-master-2> * 192.168.56.113
>>
>> *mesos-slave-1.> * 192.168.56.110
>>
>> The authenticity of host '192.168.56.110 (192.168.56.110)' can't be
>> established.
>>
>> ED25519 key fingerprint is
>> SHA256:BYtAmTw/dvAE8tOTKC6PabqNhP0m1X3Uzo0Y10o5ZQ4.
>>
>> Are you sure you want to continue connecting (yes/no)? The authenticity
>> of host '192.168.56.109 (192.168.56.109)' can't be established.
>>
>> ED25519 key fingerprint is
>> SHA256:UO/GwVQ7bItuhG1BTZDXfLCcC2+WKlKJj/SbXZMRO3w.
>>
>> Are you sure you want to continue connecting (yes/no)? The authenticity
>> of host '192.168.56.113 (192.168.56.113)' can't be established.
>>
>> ED25519 key fingerprint is
>> SHA256:mxa29nKLySX1YeVUgiN8+CKMlzc+krZwD5fBpYmOySA.
>>
>> Are you sure you want to continue connecting (yes/no)? *mesos-master-1> *
>> .
>>
>> *mesos-slave-0.> *. 192.168.56.112
>>
>> The authenticity of host '192.168.56.112 (192.168.56.112)' can't be
>> established.
>>
>> ED25519 key fingerprint is
>> SHA256:+FebG9JhzPR5rDVnZyZ5o34RFliKCFF3Fl0//aYJo4A.
>>
>> Are you sure you want to continue connecting (yes/no)? *mesos-master-1> *
>> ..yes.
>>
>> Host key verification failed.
>>
>>
>> *mesos-master-0> *could not connect to ‘root@192.168.56.109’, retrying
>> in 1 seconds...
>>
>> *mesos-master-1> *.The authenticity of host '192.168.56.109
>> (192.168.56.109)' can't be established.
>>
>> ED25519 key fingerprint is
>> SHA256:UO/GwVQ7bItuhG1BTZDXfLCcC2+WKlKJj/SbXZMRO3w.
>>
>> Are you sure you want to continue connecting (yes/no)? ye. 192.168.56.106
>>
>> sThe authenticity of host '192.168.56.106 (192.168.56.106)' can't be
>> established.
>>
>> ED25519 key fingerprint is
>> SHA256:3WCxfVqgYqEwGN+pIS1yAPBu0e1hm//xOT5PCRatTpw.
>>
>> Are you sure you want to continue connecting (yes/no)?
>>
>> Please type 'yes' or 'no': yes
>>
>> Please type 'yes' or 'no': yes
>>
>> Please type 'yes' or 'no': yes
>>
>> Please type 'yes' or 'no': yes
>>
>> Please type 'yes' or 'no':
>>
>> Please type 'yes' or 'no':
>>
>> Host key verification failed.
>>
>> *mesos-master-1> *could not connect to ‘root@192.168.56.106’, retrying
>> in 1 seconds...
>>
>> The authenticity of host '192.168.56.106 (192.168.56.106)' can't be
>> established.
>>
>> ED25519 key fingerprint is
>> SHA256:3WCxfVqgYqEwGN+pIS1yAPBu0e1hm//xOT5PCRatTpw.
>>
>> Are you sure you want to continue connecting (yes/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] Nixops fails to log into virtualbox machines on osx.

2016-06-07 Thread Maarten Hoogendoorn
Hi there,

As mentioned in the previous email I sent to the list, I'm trying to work
with nixops on osx.

The next error I encountered is that nixops is unable to log in to the VM's
due to unknown host keys, see the (partial) output of nixops deploy below:

containersolutionss-MacBook-Pro:blog-nix containersolutions$ nixops deploy

*mesos-slave-1.> *creating VirtualBox VM...

*mesos-slave-1.> *Virtual machine
'nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-slave-1' is created and
registered.

*mesos-slave-1.> *UUID: 039cb7f7-af9a-486f-867d-49f7ef729136

*mesos-slave-0.> *Settings file: '/Users/containersolutions/VirtualBox
VMs/nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-slave-0/nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-slave-0.vbox'

*mesos-master-0> *creating disk ‘disk1’...

*mesos-master-1> *Clone medium created in format 'VDI'. UUID:
7d898ca7-1d46-4a40-9210-1115d34310d5

*mesos-master-1> *attaching disk ‘disk1’...

*mesos-master-1> *Waiting for VM
"nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-master-1" to power on...

*mesos-master-1> *VM
"nixops-8acebf33-2caa-11e6-ae59-a45e60d9f55d-mesos-master-1" has been
successfully started.

*mesos-master-1> *waiting for IP address...

*mesos-slave-1.> *.

*mesos-master-0> * 192.168.56.109

*mesos-master-2> * 192.168.56.113

*mesos-slave-1.> * 192.168.56.110

The authenticity of host '192.168.56.110 (192.168.56.110)' can't be
established.

ED25519 key fingerprint is
SHA256:BYtAmTw/dvAE8tOTKC6PabqNhP0m1X3Uzo0Y10o5ZQ4.

Are you sure you want to continue connecting (yes/no)? The authenticity of
host '192.168.56.109 (192.168.56.109)' can't be established.

ED25519 key fingerprint is
SHA256:UO/GwVQ7bItuhG1BTZDXfLCcC2+WKlKJj/SbXZMRO3w.

Are you sure you want to continue connecting (yes/no)? The authenticity of
host '192.168.56.113 (192.168.56.113)' can't be established.

ED25519 key fingerprint is
SHA256:mxa29nKLySX1YeVUgiN8+CKMlzc+krZwD5fBpYmOySA.

Are you sure you want to continue connecting (yes/no)? *mesos-master-1> *.

*mesos-slave-0.> *. 192.168.56.112

The authenticity of host '192.168.56.112 (192.168.56.112)' can't be
established.

ED25519 key fingerprint is
SHA256:+FebG9JhzPR5rDVnZyZ5o34RFliKCFF3Fl0//aYJo4A.

Are you sure you want to continue connecting (yes/no)? *mesos-master-1> *
..yes.

Host key verification failed.


*mesos-master-0> *could not connect to ‘root@192.168.56.109’, retrying in 1
seconds...

*mesos-master-1> *.The authenticity of host '192.168.56.109
(192.168.56.109)' can't be established.

ED25519 key fingerprint is
SHA256:UO/GwVQ7bItuhG1BTZDXfLCcC2+WKlKJj/SbXZMRO3w.

Are you sure you want to continue connecting (yes/no)? ye. 192.168.56.106

sThe authenticity of host '192.168.56.106 (192.168.56.106)' can't be
established.

ED25519 key fingerprint is
SHA256:3WCxfVqgYqEwGN+pIS1yAPBu0e1hm//xOT5PCRatTpw.

Are you sure you want to continue connecting (yes/no)?

Please type 'yes' or 'no': yes

Please type 'yes' or 'no': yes

Please type 'yes' or 'no': yes

Please type 'yes' or 'no': yes

Please type 'yes' or 'no':

Please type 'yes' or 'no':

Host key verification failed.

*mesos-master-1> *could not connect to ‘root@192.168.56.106’, retrying in 1
seconds...

The authenticity of host '192.168.56.106 (192.168.56.106)' can't be
established.

ED25519 key fingerprint is
SHA256:3WCxfVqgYqEwGN+pIS1yAPBu0e1hm//xOT5PCRatTpw.

Are you sure you want to continue connecting (yes/no)?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev


Re: [Nix-dev] Install Nix on OSX, install nixops -> runs python2.7-pytest tests

2016-06-07 Thread Maarten Hoogendoorn
Ah, I see ;) Now it makes sense.

2016-06-07 14:42 GMT+02:00 zimbatm <zimb...@zimbatm.com>:

> It's possible, the nixpkgs-unstable and nixos-unstable both evolve
> independently as they have different "success" conditions.
>
> On Tue, 7 Jun 2016, 13:38 Maarten Hoogendoorn, <maar...@moretea.nl> wrote:
>
>> Ah, that could be very well the cause of this. Is the OS X build lagging
>> behind the NixOS one? I thought if some package was present in the unstable
>> channel, that hydra would have build it and uploaded it to the binary cache?
>>
>> 2016-06-07 14:30 GMT+02:00 zimbatm <zimb...@zimbatm.com>:
>>
>>> In general I found that there are less packages available from the cache
>>> on OSX. What probably happened is that the packages had to be built. If
>>> doCheck = true then tests are run after the build and this is the default
>>> for python packages.
>>>
>>> On Tue, 7 Jun 2016, 13:19 Maarten Hoogendoorn, <maar...@moretea.nl>
>>> wrote:
>>>
>>>> Hi there,
>>>>
>>>> I have been a really happy Nix{,pkgs,os,ops} for some time. In fact,
>>>> I'm writing two intro blog posts about nix during working hours for
>>>> Container Solutions. Since most of the developers that will read the
>>>> blogpost will be running OS X, I've borrowed a spare macbook, and installed
>>>> nix and nixops.
>>>>
>>>> To my surprise, this caused python tests to run. Is this the expected
>>>> behavior?
>>>>
>>>> Thanks,
>>>> Maarten
>>>> ___
>>>> 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] Install Nix on OSX, install nixops -> runs python2.7-pytest tests

2016-06-07 Thread Maarten Hoogendoorn
Ah, that could be very well the cause of this. Is the OS X build lagging
behind the NixOS one? I thought if some package was present in the unstable
channel, that hydra would have build it and uploaded it to the binary cache?

2016-06-07 14:30 GMT+02:00 zimbatm <zimb...@zimbatm.com>:

> In general I found that there are less packages available from the cache
> on OSX. What probably happened is that the packages had to be built. If
> doCheck = true then tests are run after the build and this is the default
> for python packages.
>
> On Tue, 7 Jun 2016, 13:19 Maarten Hoogendoorn, <maar...@moretea.nl> wrote:
>
>> Hi there,
>>
>> I have been a really happy Nix{,pkgs,os,ops} for some time. In fact, I'm
>> writing two intro blog posts about nix during working hours for Container
>> Solutions. Since most of the developers that will read the blogpost will be
>> running OS X, I've borrowed a spare macbook, and installed nix and nixops.
>>
>> To my surprise, this caused python tests to run. Is this the expected
>> behavior?
>>
>> Thanks,
>> Maarten
>> ___
>> 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] Install Nix on OSX, install nixops -> runs python2.7-pytest tests

2016-06-07 Thread Maarten Hoogendoorn
After I encountered this problem, I checked the channel (it was "unstable")
and ran nix-channel --update. It did not make any difference w.r.t. running
these tests. I expected this, since I saw that the installation script
pulled an up to date channel definition during installation.

Just to make sure that you have all information: I just grabbed this wiped
(no other dev tools present) macbook from a bookshelve at the office, and
installed nix and nixops directly.

2016-06-07 14:25 GMT+02:00 Domen Kožar <do...@dev.si>:

> Hi,
>
> I suspect you saw nixops dependencies being built because for some reason
> it wasn't built by hydra:
> http://hydra.nixos.org/job/nixpkgs/trunk/nixops.x86_64-darwin
>
> If you update to latest channel this shouldn't happen anymore.
>
> On Tue, Jun 7, 2016 at 1:18 PM, Maarten Hoogendoorn <maar...@moretea.nl>
> wrote:
>
>> Hi there,
>>
>> I have been a really happy Nix{,pkgs,os,ops} for some time. In fact, I'm
>> writing two intro blog posts about nix during working hours for Container
>> Solutions. Since most of the developers that will read the blogpost will be
>> running OS X, I've borrowed a spare macbook, and installed nix and nixops.
>>
>> To my surprise, this caused python tests to run. Is this the expected
>> behavior?
>>
>> Thanks,
>> Maarten
>>
>> ___
>> 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] Install Nix on OSX, install nixops -> runs python2.7-pytest tests

2016-06-07 Thread Maarten Hoogendoorn
Hi there,

I have been a really happy Nix{,pkgs,os,ops} for some time. In fact, I'm
writing two intro blog posts about nix during working hours for Container
Solutions. Since most of the developers that will read the blogpost will be
running OS X, I've borrowed a spare macbook, and installed nix and nixops.

To my surprise, this caused python tests to run. Is this the expected
behavior?

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