>Isn't SVN commit access still open? AFAIK github is currently a read-only
>mirror of the SVN repo.
I am collecting opinions about that last part...
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-
>The main issue that we still need to decide on is a workflow / access policy
>(see e.g. http://git-scm.com/book/ch5-1.html). Input welcome. The two main
>alternatives are:
>
>- A centralised workflow where people commit directly into the master. This is
>basically what we did with Subversion.
>> > - A centralised workflow where people commit directly into the
>> > master. This is basically what we did with Subversion. The downside
>> > is a lack of review.
>> I am very much in favor of this approach because it forces the least
>> amount of administrative overhead on regular contribut
I am very much in favor of this approach because it forces the least
amount of administrative overhead on regular contributors while still
leaving the door open for non-regular contributors to submit patches via
pull requests. Personally, I do not want to open a pull request for
>> Noticeable part of major feature proposals get neither positive nor
>> negative review and get buried by inaction before the next person who
>> could benefit of the proposed changes appears.
>
>That's bad, but the alternative can't be to just let everybody potentially poor
>quality changes just
>> (like in the case with the
>>parallel builds)
>
>What's the story with parallel builds?
There was a proposal to introuce off-by-default support for parallel
builds on multicore computers. There was a patch that allowed user to
choose whether he wants to do the risky thing and use parallel buil
>> - nix-tickets@/nix-issues@/similar - notifications about tickets, could
>> also be sent to nix-dev@
>
>Unfortunately, GitHub doesn't seem to support this. At least I can't find any
>place in the interface to set notifications for issues.
Maybe you could just create a virtual project member w
>Let's not forget that in the end we all compete with ubuntu, apple,
>Microsoft etc - because we all depend on a working system (to run our
>servers or write private mail)
Actually, the core that is complex enough to need collaboration is quite
small. I tried to share everything - with medium-easy
> that things can be improved without fracturing the already-small group.
It looks like the main project will be conservative enough to be simple
to pull... A small fork will probably only change things that bother
someone. Overall, this makes believable that the fork will be able to
pull all c
>> What exactly *is* NixOS's policy?
>Also not clearly defined, but so far, it seems to have been
>functioning reasonably well without people feeling the need to fork.
Its lack also has created a few weird and unfiortunate outcomes, and
currently we seem to have a chance to get more.
>> Eelco rev
>> Its meant for all those small changes which are no worth creating pull
>> requests for, too.
>>
>I can't imagine a change not worth creating a pull request. Creating a pull
>request is two clicks, accepting it is one click.
Not just two clicks, but pulling the trunk into your fork which is not
>> Sending patch to mailing list can be done with a single
>> pipeline command in shell...
>>
>> So yes, for simple fixes pull request is more effort than contributing
>> the fix would save.
>No doubt, we _must_ still accept contributions by `git format-patch` from
>those who prefer it.
I would sa
>> It looks like the main project will be conservative enough to be simple
>> to pull...
>Are you basing this assessment only on the git situation over the last 6 days,
>or do you consider the project pre-git to be fairly conservative?
This is based on the recent (couple years) history of the act
>>> Well, it was just an example. My point was merely that it's not enough to
>>> point out a problem, whenever possible you should point out solutions and
>>> be willing to do the legwork necessary to implement them.
>> The real problem is that for many things it does look like the problem
>> is
>> - There is a reasonable public place where I can see every package
>> expression used by any committer. So, if someone uses a git-head version
>> of kernel, it would be nice to see what overrides were needed.
>Do you mean some sort of repository of local overrides? That might be nice, do
>you
>> Many webapps will need to specify that "a" database library is present, but
>> may not care which one.
>Heh: if the web app is so "careless" to not specify which database to use,
>there's no reason why other system components should care about a busted web
>app.
The point is: sometimes it can
>> Continuing with a Java theme: the Java Advanced Imaging interfaces have a
>> (default) pure java implementation as well as a native (accelerated)
>> implementation.
>How should this be solved? Try find answers yourself. Its the same
>problem M.R. talked about if buildfarm uses optimiziations you
>None of which works too well in practice (though java is certainly farther
>along than other languages).
>
>> Same with pure python, pure ruby, pure perl, pure anything with a VM.
>
>python isn't compatible with itself because of 3.0. ruby is even more of a
>mess with
>rvm and per-user shadow tr
>Excerpts from Shea Levy's message of Thu Jun 28 00:38:16 +0200 2012:
>> Ok. Why was builderDefs rejected? What problems do you see with it, and what
>> do others see?
>What does reject mean? I'd say it was not adopted (by me yet) because
>the existing monolitic setup.sh works good enough - I have
>> > Continuing with a Java theme: the Java Advanced Imaging interfaces have a
>> > (default) pure java implementation as well as a native (accelerated)
>> > implementation.
>>
>> How should this be solved? Try find answers yourself. Its the same
>> problem M.R. talked about if buildfarm uses opti
>> Frankly, from the technical point of view I would prefer a set of
>> overridable knobs gradually added to the packages in the main set. This
>> gives easier discoverability which is nice. Of course, this clashes with
>> the struggle for simplicity of the main expression or something else
>> li
>I think it is more fruitful to think of the system between us
>maintainers being anarchy, not democracy and therefore we should be
>aware of and work with consensus.
>
>For a nice description and one implementation of consensus, see:
>
>https://www.noisebridge.net/wiki/Consensus
It does look that
>> >I think it is more fruitful to think of the system between us
>> >maintainers being anarchy, not democracy and therefore we should be
>> >aware of and work with consensus.
>> >
>> >For a nice description and one implementation of consensus, see:
>> >
>> >https://www.noisebridge.net/wiki/Consens
>Also,
>
>I value fast addition of new packages/new package versions above rarity
>of local breakages in the fastest-moving branch. I separately value not
>turning contributors away above avoidance of short glitches.
>
>I think that having a partially-incompatible previous version (unless
>there
> Changed paths:
>M default.nix
>M modules/security/sudo.nix
>
> Log Message:
> ---
> allow out-of-tree nixos modules
>
>The environment variable "NIXOS_EXTRA_MODULES" is now checked to
>contain a path to a file similar to modules/module-list.nix.
>
>This gives the ability to in
>>>This can be useful for modules that are still experimental, or which
>>>aren't useful for other nixos users. Of course, this was already
>>>possible to do this using a forked nixos tree, but with this
>>>functionality, you can just rely on the nixos channel, easing things a
>>>lot.
>>
>> Actuall
>Right now, I need to distribute and sync my "secure files" to multiple
>machines. If I could just store the mysql password in the store,
>gpg encrypted, that would make things a lot easier.
>As files can be encrypted for multiple receivers, I can manage
>permissions through that mechanism and jus
>
>--f46d044787ffa1cd7704c5b76f97
>Content-Type: text/plain; charset=UTF-8
>
>On Thu, Jul 26, 2012 at 9:09 AM, Michael Raskin <7c6f4...@mail.ru> wrote:
>
>> >Right now, I need to distribute and sync my "secure files" to multiple
>> >machines. I
>Well, I believe the Nix expression language is Turing complete right (although
>I have no proof), so it is as powerful as any other general purpose language.
It is obviously turing complete if you have arbitrarily large lists of
strings. The proof is just direct translation of Turing machines i
>Hrm, I see that adding /var/setuid-wrappers is somewhat impure, as the
>current paths point to absolute directories in the nix store.
>
>I'll just have the cronjob output to stdout for now, so normal cron
>handling picks it up for email.
>However, it would be nice to have _some_ jobs send their ou
>For instance, if you add the line
>
> binary-caches = http://nixos.org/binary-cache
Great! Thanks.
>* The main downside to the binary cache substituter is that it has no support
>for binary patches (and it's not obvious how to support them). If you really
>need them, you can add "force-manifes
>> Are binary diffs pregenerated - and only for a fixed set of second
>> arguments?
>>
>> If yes, narinfo could contain them.
>
>Binary diffs are typically generated after the NAR / .narinfo has been
>produced,
>so adding them later requires modifying an existing .narinfo file. That would
>be
>Hi,
>
>On 19/09/12 14:49, Michael Raskin wrote:
>
>> Hm. What about hash-of-name -> list-of-binary patches lists? It would be
>> just as bad as MANIFEST from mutability point of view, but without
>> downloading a huge chunk of data in one sitting.
>
>Yeah,
>Hi all,
>
>The hardware I use for building my channel is not very powerful. It
>does a good job of building derivations, but packing nar files with xz
>takes ages.
>
>My channel is nothing special, It just builds the configurations for a
>few home machines and laptops and some packages that hydra
>> I am not too familiar with precise nix-push inside. Does the idea of
>> building a directory with symlinks of NARs (wo it depends on them all),
>> calling it something that includes current date, and removing
>> 100-hour-old link sets in cron look hard ot easy to implement?
>
>That's the direc
>> Of course, if you look at it you will see that you can easily generate
>> such a file yourself and nix-build it.
>
>I was looking at that just now :)
>
>But I would like to go a step further and just patch nix-push a bit.
>It doesn't need to copy anything I guess.
>Just having it output the resu
> > Commit: a5969634f4da94f85ffbce2ce81f760fd73c67e5
> >
> > Log Message:
> > ---
> > sshd: Do detach into the background
> >
> > This is necessary to ensure that jobs that need to start after sshd
> > work properly.
>
>this seems counter-intuitive to me. How is running sshd asynchronously
>I'm trying to install nix on a new machine. It's running Arch so I
>decided to use the generic x86_64 binary distribution. I ran through
>the steps for using it from a single non-root user account.
>
>rwallace:~$ cd /
>rwallace:/$ sudo tar -jxvf ~/Downloads/nix-1.1-x86_64-linux.tar.bz2
>[sudo] p
>A common problem for people trying to use Nix/Nixpkgs/Guix on non-NixOS
>distros, especially Debian derivatives, is that their /bin/sh is not
>Bash. On Debian and derivatives, it’s a symlink to /bin/dash.
>
>When building without a chroot, things eventually fail because stdenv,
>and sometimes bui
>Hi Michael,
>
>Michael Raskin <7c6f4...@mail.ru> skribis:
>
>> I have some basic-chroot.nix, which is what basics I need to do Nix
>> builds and look at simple problems comfortably.
>>
>> It is literally:
>>
>> let nixpkgs = import
>> So, I guess there would be a configuration option (marked as dangerous
>> and/or impure) to override what is taken from external environment for
>> a normal chroot build (ideally, nothing — maybe it is possible to use
>> even fake proc?).
>
>What I had in mind was more an extension of Derivatio
> > It's one thing to test locally with a dash /bin/sh to find
> > packages with bad assumptions, it's another thing to break packages that
> > currently work perfectly well for the vast majority of nix users.
>
>How do you test packages locally with /bin/sh pointing to Dash on NixOS?
>I had no i
>> How do you test packages locally with /bin/sh pointing to Dash on NixOS?
>> I had no idea that's possible.
>
># nix-build -A dash "" -o /bin/sh
I think this won't work as expected - /bin/sh/bin/dash is not what we
want.
___
nix-dev mailing list
nix
>I'm trying to create a package that, as part of its make, downloads some
>stuff through curl. Most work but one in particular is failing due to
>certificates (see below). This works if I do it on the command line. I
>tried adding 'cacert' to my buildInputs and parameters, but that didn't
>seem
>Hi Mathijs,
>
> > Is anyone still using linux 2.6.15 or 2.6.35 or 3.1 or 3.3 or 3.5 ?
>
>I'm still using 3.5. I cannot upgrade to 3.6 yet, because my wireless
>interface (iwlwifi: Intel Centrino Advanced-N 6205 AGN) won't work with
>the new kernel for some reason.
iwconfig stopped working as Wire
>Of course running nix-prefetch-git is an option, however checking
>whether a store path representing { url = ..; hash = .. } already exists
>is harder. If you run nix-prefetch-git twice it will fetch twice
>(waste). I haven't looked for options.
nix-store --check-validity $(nix-store -q --outputs
>Sorry for my bad English.
>
>Would someone provide a pointer about how install a custom kernel on
>NixOs? I have already searched on TFW and TFM without success.
>
>I'm wondering if NixOs is suitable for kernel development...
Well, you can just override src in any kernel expression we have
(obv
>It seems like Nix can be installed on pretty much any system (including
>Windows?), but the reverse does not seem possible: why shouldn't one be
>able to install any system on NixOS?
I cannot clearly understand what your actual goal is here...
It may be interesting, but I think some clarificat
>> I cannot clearly understand what your actual goal is here...
>The goal is to be able to install any system and have it managed
>completely within Nix. E.g. point Nix at an install of some
>(non-obscure) linux distro and have it turn into a working install of
>NixOS, with packages from that di
>I submitted this pull request last week
>
>https://github.com/NixOS/nixpkgs/pull/216
>
>I cannot understand how this request could be marked as merged and
>closed by me (I don't have commit access on the nixpkgs project, i
>think).
>
>Also I noticed that no commit is associated to this pull reques
>>>Also I noticed that no commit is associated to this pull request.
>>>Can someone enlighten what actually happened?
>>
>> I am not sure, but my working hypothesis would be that someone silently
>> picked your commit into master without using GitHub UI.
>
>Probably myself. But what I don't unders
>I'm using Nix on an "ordinary" Linux distro (not NixOS) and I want to use
>chroot builds, to make package builds more pure. I've successfully performed a
>multi-user installation and I've enabled chroot builds in nix.conf. However,
>the default build-chroot-dirs option value does not include th
>> A possible solution is to bind mount a different directory from my host
>> system
>> (only containing the shell) into the the chroot environment.
>It would have to be a statically linked shell, otherwise you'll need /lib as
>well.
Or a link to stdenv.shell.
>I could also be more creative -- e.g. running nix-daemon in a chroot providing
>a "pure" environment. But doing that is a bit too much effort for me. :P
Well, you can take my script in the short run
configurations/trunk/misc/raskin/misc-scripts/special-chroot
I do exactly this chroot trick
_
>But instead of just having to wait for a while, the whole experience
>was a lot less pleasant, as the build process errored out every hour
>or so, because of missing source downloads. As I was not present the
>whole time, but only check/fix/restarted occasionally, I'm not even
>halfway done yet :(
I guess specifying -k (--keep-going) flag to nix-build would help.
nix-build /etc/nixos/nixos -k -A system
>>>
>>> Didn't think of that, but it might indeed get me a bit further.
>>> Depends a bit on how high/low in the dependency-tree the missing
>>> source sits though.
>>> For exam
>>> Do you mean the opposite–generating Guix expressions from Nix?
>>
>> I actually meant guix -> nix, as guix being within a full language, I
>> had gut feeling this direction might be preferable, see also below.
>
>I think conversion has the same problem in both directions: simple
>meta-data is t
>after updating to a recent 3.7.8 kernel, my EeePC's wireless interface
>is no longer recognized iwconfig and friends:
>
> $ iwconfig wlp1s0
> wlp1s0no wireless extensions.
>
> $ iwlist wlp1s0 scanning
> wlp1s0Interface doesn't support scanning.
>
>wpa-supplicant, on the other hand, wor
>Has anyone tried a webkit browser after stdenv merge? I tried to really
>use them now, and they all segfault at the first attempt to show a
>nontrivial page. I've been unable to find out the reason, though.
>
>(The missing-schemas problems are easy to solve but without really
>working I see not
>>> Has anyone tried a webkit browser after stdenv merge? I tried to really
>>> use them now, and they all segfault at the first attempt to show a
>>> nontrivial page. I've been unable to find out the reason, though.
>>>
>>> (The missing-schemas problems are easy to solve but without really
>>> wor
>It's time to package munin :)
You think Monit, Icinga/Nagios and Zabbix are not enough and the problem
is that munin is not packaged?
>> This seems to happen a lot, any chance some simple program could be
>> installed to warn the maintainers of this so they can get to it in time?
>> >
>> > There
>I'm completely new to Nix so I apologize in advance if this is not the
>right place.
>I installed NixOs yesterday and I needed a recent version of Julia
>(julialang.org) and figured it would be a good way to try out Nix.
>
>Here is a patch to nixpkgs that brings julia to today's git
>(ea277f39ebdf
>Yes those fetchurl are my mistake and weren't used in the build anyway.
>I've however made it to use_system_mpfr and removed the useless fetchs
>(including the pcre source one which doesn't seem used).
>To do so I had to bump the mpfr version to 3.1.2.
>Patch attached. I'll be sure to setup a gith
>>>Yes those fetchurl are my mistake and weren't used in the build anyway.
>>>I've however made it to use_system_mpfr and removed the useless fetchs
>>>(including the pcre source one which doesn't seem used).
>>>To do so I had to bump the mpfr version to 3.1.2.
>>>Patch attached. I'll be sure to se
>I tried to upgrade pgf/tikz in texlive to version 2.10 (which I need to work).
>I succeded from a tar.gz in the debian mirror, but never from the .tdf.zip
>from sourceforge. The nix expression
>is not completely trivial, I managed to have an accepted [ unzip ] as
>buildInputs,
>but I got "unzip
Hello.
It happened that running test-eval-release.sh shows some errors
but plain instantiation of eval-release.nix doesn't. Maybe --strict is
making it evaluate things that are passed through on all platforms, but
only evaluated where relevant.
I decided that this is
>I want to add Riak support to NixOS. The config file is quite large and
>can be complex. It also is a supported file type in my Emacs so I get
>pretty syntax highlighting. Putting this inside Nix expressions losses
>this feature. I think putting config files in Nix expressions is
>suboptimal.
>That does not give access to variables, from my understanding.
Ah yes, you are right
>> >I want to add Riak support to NixOS. The config file is quite large and
>> >can be complex. It also is a supported file type in my Emacs so I get
>> >pretty syntax highlighting. Putting this inside Nix ex
>anyone has experience using ethernet to usb adapter on nixos? Is it even
>possible?
Yup, with no problem. What you need to know is what module you need.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/
>Isn't that 'usbnet'?
Not just it. You also need specific drivers for some of them.
>On Mon, Jul 22, 2013 at 10:48 PM, Michael Raskin <7c6f4...@mail.ru> wrote:
>
>> >anyone has experience using ethernet to usb adapter on nixos? Is it even
>> >pos
>> The feature isn't used too much yet, so I suggest to comment out the
>> offending lines in /pkgs/top-level/all-packages.nix (until you
>> switch to upgraded version).
>
>Thanks. That helped a bit. Now I have a problem:
>
>error: `This version on Nixpkgs requires Nix >= 1.2, please upgrade`
>
>Is
>I am trying to install nilfs-utils.
>
>According to the wiki ( http://nixos.org/wiki/Install/remove_software ), I can
>install a package by 'nix-env -i for one user, or I can install it
>for all users by adding it to environment.systemPackages . The second way does
>not work for me for nilfs-util
>On further reflection, I think I see how it almost might work using
>derivations. Assume it is possible to have a derivation that is only
>considered to be built (hand-waving part here ...) if the required filesystem
>exists. Then that derivation depends on another that is only considered to be
>
>I'd like to unveil this new service, which will hopefully help us keep Nix
>stuff fresh and
>secure: http://vdmvtkitqc3grub6.onion.to/
>
>This is a yesterday's scan result, it may go offline for 5-30 minutes several
>times per day
>as I'm working on improving it.
Do you plan to publish the sc
>Not sure if this is still relevant - I'll drop my thoughts nonetheless.
>
>
>I think a (web) dashboard *and* email reports would be useful. I
>personally don't care very much about a RSS feed, but generating it
>wouldn't be that hard either.
>
>
>Email reports are mostly useful if they're maintai
>./configure: line 15730: `
>PKG_CHECK_EXISTS(gobject-introspection-1.0,,'
>builder for `/nix/store/4cr9r3lrmlvwrv8nk9x60xq88npgcm34-cjs.drv' failed with
>exit code 2
PKG_ something is likely to be related to pkgconfig. Could you try
adding pkgconfig to the buildInputs please? I'd al
>When you do not have gobject-introspection added to the buildsinput you see
>this error :
>
>./configure: line 15707: syntax error near unexpected token `1.32.0'
>./configure: line 15707: `GOBJECT_INTROSPECTION_REQUIRE(1.32.0)'
>builder for `/nix/store/z9mkb2m239y3fdrpxr2fhcb0j4yadki2-cjs.drv' f
>Yes, I did and I solved this problem.
>
>Now I see this error :
>
>No package 'gmodule-2.0' found
>No package 'gthread-2.0' found
>No package 'gio-2.0' found
>No package 'mozjs185' found
>
>So I did find / -name "gmodule-2.0.pc" and I see this output:
>
>/nix/store/1kh7gl673vp4zpilrvsi4cmxwk7il27
>cinnamon = recurseIntoAttrs {
>cjs = callPackage ../desktops/cinnamon/cjs.nix { };
>cinnamon-desktop = callPackage ../desktops/cinnamon/cinnamon-desktop.nix{
> inherit(gnome) gnome_common };
> };
>
>but now I see this error message:
>
>error: syntax error, unexpected '}', expecting I
>
>And now I see this error messages:
>
>building gnome-datetime-source.lo
> CC gnome-datetime-source.lo
>building libgsystem_la-gsystem-local-alloc.lo
> CC libgsystem_la-gsystem-local-alloc.lo
>building libgsystem_la-gsystem-file-utils.lo
> CC libgsystem_la-gsystem-file-utils.
>> >Anyone a clue how to solve this ?
>>
>> GIO is a part of glib.
>>
>> Its include path matches ${glib}/include/gio-*
>>
>> I usually just expand this mask in preConfigure and add
>> -I$gio_include_dir to NIX_CFLAGS_COMPILE variable.
Do you use the export Nix_FLAGS_COMPILE or just NIX_FLAGS_F
>> Date: Sun, 1 Dec 2013 23:10:48 +0400
>> From: 7c6f4...@mail.ru
>> To: rwob...@hotmail.com; nix-dev@lists.science.uu.nl
>> Subject: Re: [Nix-dev] libgsystem/gsystem-file-utils.c:28:34:
>> fatalerror:gio/gunixinputstream.h: No such file or directory
>>
>No luck.
>
>I changed the derivation to t
>Excerpts from Michael Raskin's message of 2013-12-05 04:54:51 +:
>> I wonder if this is the first package I have seen with meta right
>> after the name in the beginning of the expression
>
>Might be the first. I think it's better this way, as when you're
>glancing at an expression, this is inf
>Yes, fixed. Should the absolute non free license also be added to
>lib/licenses? like:
>```
>idea_personal = {
> shortName ="IDEA Personal License";
> fullName = "IDEA Personal License";
> url ="https://www.jetbrains.com/idea/buy/personal_license.html":
>}
>```
>Instead of just unfree? I.e
>The current implementation of the 'asdf' build tool for
>pkgs.lispPackages passes texlive to every package (It's used to build
>documentation).
>
>I think we should drop this input. A 500+Mb download for even the
>smallest lispPackage isn't necessary.
I guess I should say that I do agree that thi
>building muffin-enum-types.h
>building Meta-Muffin.0.gir
> GISCAN Meta-Muffin.0.gir
>Couldn't find include 'Clutter-1.0.gir' (search path: [<…>
>'/nix/store/kgkd63a3q70jxmwz9p11y143xchph7y4-cinnamon-desktop-2.0.4/share/gir-1.0',
> '/nix/store/ry69062ybalsd25z5myszjkfh388k53b-cogl-1.16.0/share/
>What I'm most worried about though is citrix and its critical priority to
>you. But that's mostly based on my previous experiences with the linux
>citrix client's hideous quality. I had a great deal of trouble just with
>Arch linux the last time I used it.
If Citrix is a Java application with no
>It is a trade-off. Broken packages can be more overhead than duplication
>of work. If you make a package that works for you, push it to nixpkgs
>and abandon it, the next person will find it broken for his purpose, fix
>it and in the process break it for you. You will both spend time
>debugging the
>Michael Raskin <7c6f4...@mail.ru> writes:
>> Somehow, whenever updates of packages I care about were broken, it was
>> a simple mistake that was easy to fix separately… I think this scenario
>> is overly pessimistic.
>
>Well, depends on your point of view. If yo
>I've noticed that NixOS doesn't provide man pages for well-known C
>functions from it's stdlib. Probably most of the users don't need
>them, but I'd prefer to install it on my system. Do we have such an
>option? If not, I probably can write a separate expression. What
>package does contain them? g
>I routinely find myself in a situation where some build tool or
>installation of software (gcc, pip, a runtime) not via a nix expression)
>will fail due to not having zlib available/in scope. What would be a simple
>way to prevent this annoyance?
There are NIX_LDFLAGS, NIX_CFLAGS_COMPILE and LD_L
>I managed to force-push master and delete a couple of commits. I have no
>idea how that happened, but let's first fix the mess. Does anyone commit
>
>nixpkgs/master 6cfbc75 Michael Raskin: Fix CL-Launch source link
>
>If so, please force-push it to master (check before
>nix-env -f . -i cinnamon.cinnamon-session shows the no derivations found
>erorr.
nix-env -f . -iA cinnamon.cinnamon-session
?
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
>Hello,
>
>I tried to use the propierty nvidia driver but I cannot make it install.
>
>services.xserver.videoDrivers = ['nvidia'] and
>hardware.opengl.videoDrivers = [ 'nvidia'] gives both a undefined error.
You need either " or ''
___
nix-dev maili
For me versionDerivation looks like a nicer solution, but I generally
tend to be OK with computations written in Nix.
I have been burnt by pythonPackages and even by linuxPackages providing
different subsets of modules for different core versions… so I do not
think versionedDerivation is worse th
>Michael Raskin schreef op 7-4-2014 19:09:
>>> nix-env -f . -i cinnamon.cinnamon-session shows the no derivations found
>>> erorr.
>> nix-env -f . -iA cinnamon.cinnamon-session
>>
>> ?
>>
>>
>>
>>
>
>Same error. It looks lik
>Michael Raskin schreef op 7-4-2014 19:27:
>>> Michael Raskin schreef op 7-4-2014 19:09:
>>>>> nix-env -f . -i cinnamon.cinnamon-session shows the no derivations found
>>>>> erorr.
>>>> nix-env -f . -iA cinnamon.cinnamon-session
>>
>Michael Raskin schreef op 7-4-2014 19:17:
>>> Hello,
>>>
>>> I tried to use the propierty nvidia driver but I cannot make it install.
>>>
>>> services.xserver.videoDrivers = ['nvidia'] and
>>> hardware.opengl.videoDrivers
>Hi! I am managing an nixpkgs branch and this branch become more and
>more older. There already were issues where I had to change mirror
>urls because of missing sources. I'd like to store as much as possible
>into local repository in order to protect myself from such situations.
>Is there a way to
>> I'm looking at the new website with mixed feelings. Being less static is a
>> good idea, so I appreciate the news, blog posts and commits sections. On the
>> other hand it's way uglier and less lucid compared to the old website.
>
>I'm flattered you consider my shitty, amateur design from 5 ye
101 - 200 of 1035 matches
Mail list logo
