Re: [Nix-dev] Hydra Building PRs
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] Hydra Building PRs
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] Typing nix − funding campaign
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] Is CI of pull requests broken?
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] 3 strange busybox problems
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] Simplify node packages?
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] github triggered builds
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] github triggered builds
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 :
> 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 :
> >
> > > 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] In multi-user Nix, let the daemon handle creation of GC roots
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
[Nix-commits] [NixOS/nixpkgs] caf44a: google-cloud-sdk: enable alpha and beta features
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: caf44a5dd3d5baf99a30290dd067f40266197435 https://github.com/NixOS/nixpkgs/commit/caf44a5dd3d5baf99a30290dd067f40266197435 Author: Maarten Hoogendoorn 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
[Nix-dev] Install Nix on OSX, install nixops -> runs python2.7-pytest tests
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
Re: [Nix-dev] Install Nix on OSX, install nixops -> runs python2.7-pytest tests
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 :
> 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
> 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
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 :
> 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, 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
Ah, I see ;) Now it makes sense.
2016-06-07 14:42 GMT+02:00 zimbatm :
> 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, 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 :
>>
>>> 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,
>>> 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] Nixops fails to log into virtualbox machines on osx.
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] Nixops fails to log into virtualbox machines on osx.
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 : > 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 > 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] Twitter account?
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
[Nix-dev] Link to nix.useSandbox in pull request template
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
Re: [Nix-dev] Malicious installation methods
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] API for nixops / distributed storage of sqlite3 db
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] How to access makeTest function from nixpkgs/nixos/lib/testing.nix?
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
Re: [Nix-dev] How to access makeTest function from nixpkgs/nixos/lib/testing.nix?
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ż" :
> Maarten,
>
> thank you for showing this, I definitely omitted this part, now I see how
> you set NIX_PATH in test.sh.
>
> I think this approach is fine, and I'll use that solution if I won't
> figure out better way.
>
> I have tree like that:
> ./nixpkgs.nix # this stuff is importing specific nixpkgs commit
> ./app1
> ./app2
> ./app3
> ./tests
>
> each app is importing "../nixpkgs.nix" separately and tests are importing
> it as well so all separately are using same nix version "internally".
>
> By avoiding wrapper I can go to every directory and run nix-build and it
> will work and app will be bound to specific nixpkgs version.
>
> Another solution would be, as you pointed, setting -I / NIX_PATH, but this
> is another manual step that needs to be done. You have to add this to
> .profile (but this is not project specific :[) or you have to set this in
> every terminal you are working in, or figure out other way to set up this.
> I'll go this route if I have no other options.
>
> Right now with small workaround I described in previous post all stuff is
> working without any other setup.
>
> 1. Clone the repo
> 2. nix-build in every directory you want
>
> 2016-06-23 1:23 GMT+01:00 Maarten Hoogendoorn :
>
>> You could set the nixpkgs path with the -I option, or as I do, with a
>> shell variable.
>> Point it to your fork of nixpkgs, and you're done.
>>
>> Alternatively, there is some overridePackage(s?) function that might
>> interest you. (I myself should look at in detail as well ;))
>> Op 23 jun. 2016 02:19 schreef "Tomasz Czyż" :
>>
>> Maarten,
>>>
>>> thank you for sharing your work.
>>>
>>> I think you are using approach with "import " and not overriden
>>> pkgs inside testing config/machine - which I prefer to avoid, because I
>>> want to have bound nixpkgs version, I don't want to use "system" version.
>>> (maybe I'm missing some piece, in that case please point it out).
>>>
>>> In the meantime I found, that I can pass/override pinned pkgs inside
>>> config/machine description with a little trick.
>>>
>>> import ({
>>> machine = {config,pkgs,...}: {
>>> _module.args.pkgs = my-nixpkgs; # this trick overrides pkgs
>>> argument for all modules
>>> imports = [
>>> ... my modules...
>>> ];
>>>
>>> };
>>> testScript=''
>>> ...
>>> '';
>>> })
>>>
>>>
>>> I would prefer to not use this method as probably "pkgs" argument can
>>> "leak" in some places (the other version of nixpkgs can be used and I will
>>> not detect this easily). But that's the best I have so far.
>>>
>>>
>>>
>>> 2016-06-23 1:10 GMT+01:00 Maarten Hoogendoorn :
>>>
>>>> Hi Tomasz,
>>>>
>>>> Some weeks ago, I looked into this to run zfs integration tests for a
>>>> rust binding to libzfs.
>>>>
>>>> The GitHub repository [1] is set up to run a qemu vm on Travis, so that
>>>> my tests can run with a kernel that supports zfs. It also provides some
>>>> isolation during development. I'd rather not destroy my main pool by
>>>> accident ;)
>>>>
>>>> Good luck, and let me know if this helps you out :)
>>>> Maarten
>>>>
>>>> [1] https://github.com/moretea/rust-zfs
>>>>
>>>> 2016-06-23 1:23 GMT+02:00 Tomasz Czyż :
>>>>
>>>>> Hello,
>>>>>
>>>>> I found makeTest function from nixos useful and I would like to use it
>>>>> in my projects for building integration testing environments.
>>>>>
>>>>> The only method I found by now, how to access it is:
>>>>>
>>>>> (import ).makeTest
>>>>>
>>>>> The problem is: in the script I'm running, the fixed nixpkgs version
>>>>> is passed as "pkgs" argument. The script must test programs against that
>>>>> specific nixpkgs version.
>>>>>
>>>>> I see two options:
>>>>> 1. grab makeTest command from pinned nixpkgs
>
[Nix-dev] Building mesos from git
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
[Nix-dev] Amsterdam Nix meetup
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 upstream nixops (to include in another project) fails
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
Re: [Nix-dev] Building upstream nixops (to include in another project) fails
2016-06-29 16:06 GMT+02:00 Maarten Hoogendoorn :
> 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 :
>
>> 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] Add banner to wiki to tell (new) users that it's not maintained
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] Add banner to wiki to tell (new) users that it's not maintained
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 : > 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 > 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] Pinning nixpkgs on unstable channel: retention of cached packages
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] nix as a library
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
Re: [Nix-dev] Pinning nixpkgs on unstable channel: retention of cached packages
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 : > 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
[Nix-dev] Override systemd service definition generated by nixos service
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] Override systemd service definition generated by nixos service
That did the trick for making programs available, thanks. 2016-07-13 15:02 GMT+02:00 Rickard Nilsson : > 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] vmTools.runInLinuxImage with ubuntu 1204 image blocks on getrandom()
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] overridePackages with nixops
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
Re: [Nix-dev] NixOS 16.09 stable branch-off is due in ~a month
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] Mesos fetcher
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] vmTools.runInLinuxImage with ubuntu 1204 image blocks on getrandom()
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 :
> 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] using qemu virtual machine for testing software
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
[Nix-dev] nix-update --channel broken on unstable?
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] typed nix
missed the list, sorry. 2016-08-30 14:01 GMT+02:00 Maarten Hoogendoorn : > 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 : > >> 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 : >> >>> 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
Re: [Nix-dev] Distributing files between machines in a nixops deployment
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
[Nix-dev] PatchELF in Bundix's postBuild step
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] PatchELF in Bundix's postBuild step
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 :
> 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
Re: [Nix-dev] PatchELF in Bundix's postBuild step
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 :
> 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, 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 :
>>
>> 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
[Nix-commits] [NixOS/nixpkgs] b217c0: yarn: init at 0.17.8 (#20635)
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: b217c0a99ba22371b2a73821a8e127892f2e24d4 https://github.com/NixOS/nixpkgs/commit/b217c0a99ba22371b2a73821a8e127892f2e24d4 Author: Maarten Hoogendoorn 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] Expression to list all packages from ?
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-dev] Nix workshop in Amsterdam: Bring your own app, we'll package it together
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] NixOS 17.03 release manager is Robin Gloster
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
Re: [Nix-dev] Typing nix − funding campaign
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 on (Android) Tablet
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
[Nix-commits] [NixOS/nixpkgs] 3cbc64: minikube: 0.13.1 -> 0.15.0
Branch: refs/heads/master Home: https://github.com/NixOS/nixpkgs Commit: 3cbc64d5bb9f3f2a386409e87b924a35ddcd16e8 https://github.com/NixOS/nixpkgs/commit/3cbc64d5bb9f3f2a386409e87b924a35ddcd16e8 Author: Maarten Hoogendoorn 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 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] Arch is dropping i686. Should we?
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
Re: [Nix-dev] Fosdem
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] nix-bundle: Bundle Nix derivations to run anywhere
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
[Nix-dev] Rust wants to integrate better in build systems
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] RFC for RFCs
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] Feedback on workshop material
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] Explicitly selecting sources for "src" in stdenv.mkDerivation?
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
