Re: [Nix-dev] NixOS small channel
On 01/10/2014 03:29, Anderson Torres wrote: Yes! t is cool! :) But, how about the other channels? I use the nixos-unstable here, can I mix both, small and unstable, in my local machine? I also use unstable for the server because I need some changes that are only in unstable. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?
On 27 September 2014 11:12, Vladimír Čunát vcu...@gmail.com wrote:
On 09/24/2014 09:58 PM, Bjørn Forsman wrote:
On 22 September 2014 17:16, Shea Levy s...@shealevy.com wrote:
I suppose a flag that says to rebuild if the output is valid but doesn't
have the right deriver could be what you want? But for now the best
answer
seems to be change the hash when it needs to change
I don't know what deriver is.
Deriver is the derivation that built a path (i.e. the build recipe).
If you built a path yourself, you can get it by
nix-store -q --deriver /nix/store/path
Ah, thanks.
Shea, it looks like the deriver (*.drv) doesn't change unless name
or the output hash attrs changes. So rebuild-if-deriver-changed won't
make any difference.
Even though it's a bit hackish, using
stdenv.mkDerivation rec {
extraHash = builtins.hashString sha256 (buildCommand);
name = foo-${extraHash}-0.0;
works just like I want it to.
Ouch, it broke real bad when using it in the real world[1]:
fetchGrailsAppDeps = { stdenv, grails, src, sha256 }:
stdenv.mkDerivation rec {
srcHash = builtins.substring 0 20 (builtins.hashString sha256
(builtins.toString src));
name = grails-app-deps-${srcHash};
[SNIP]
};
$ nix-build grails-app.nix
error: the string `grails-app-deps-b0f29513403e6dca5372' is not
allowed to refer to a store path (such as
`!out!/nix/store/80bd47sghjl4i41sd783b2w49lqzkm93-git-export.drv'), at
/nix/store/rjvnj4skg17is5x9jhzq1yl96mdvch0c-nix-1.7/share/nix/corepkgs/derivation.nix:8:12
This only happens when src = fetchgit { ... } and not when src =
./path/to/source. Why?
And what does this check protect against?
Now I have a big fat warning IMPORTANT: Remember to force re-download
deps whenever you update the source! in my expression :-(
Oh, this is bad...
I think I understand what you want: the output should not change except on
updating the package itself, but one can only find out the hash by
performing the build. On update you want to do that.
I personally force such rebuilds by changing the first few sha256 characters
to zeros. The extraHash way and Shea's suggestion are other fine ways. For
this use case, I find no clear winner, and I don't think we can do
significantly better.
What about a new, optional derivation input like extraHashInputs = [
list of attrs that will be included in calculation of $out ];?
[1]: https://gist.github.com/bjornfor/3f2fda1b1ce077225df5
Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Reengineered npm2nix: call for feedback
I haven't implemented any checks so far, but that could be improved. The
version number that you specified is actually not a valid semver version
specification. A version number should consist of 3 components. Also, I
could check for semver validity as well.
On Tue, Sep 30, 2014 at 8:55 PM, Paul Colomiets p...@colomiets.name wrote:
Hi,
On Tue, Sep 30, 2014 at 1:13 PM, Sander van der Burg
svanderb...@gmail.com wrote:
Hopefully, you can also try npm2nix on your projects to find out whether
there any additional issues. :)
If package.json doesn't contains name or version npm2nix, the
build fails with the following:
error: `buildNodePackage' at /tmp/react/node-env.nix:33:5 called
without required argument `version', at /tmp/react/registry.nix:5:27
It would be nicer, if npm2nix fails when generating nix files.
After I've filled both name and version I've got the following error:
nix-build -A build
these derivations will be built:
/nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv
building path(s)
`/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1'
building /nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1
unpacking sources
unpacking source archive /nix/store/d394a7821m6sn02ymhvfa13c7dac2fiq-react
source root is react
patching sources
configuring
no configure script, doing nothing
building
installing
npm ERR! install Couldn't read dependencies
npm ERR! Error: Invalid version: 0.1
npm ERR! at Object.module.exports.fixVersionField
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-p$
ckage-data/lib/fixer.js:183:13)
npm ERR! at
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-package-data/lib/normalize.js:30:38
npm ERR! at Array.forEach (native)
npm ERR! at normalize
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/node_modules/normalize-package-data/lib/normalize.js$
29:15)
npm ERR! at final
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:342:33)
npm ERR! at then
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:126:33)
npm ERR! at
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/read-package-json/read-json.js:316:48
npm ERR! at evalmachine.anonymous:207:20
npm ERR! at OpenReq.Req.done
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:141:5)
npm ERR! at OpenReq.done
(/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/lib/node_modules/npm/node_modules/graceful-fs/graceful-fs.js:61:22)
npm ERR! If you need help, you may report this *entire* log,
npm ERR! including the npm and node versions, at:
npm ERR! http://github.com/npm/npm/issues
npm ERR! System Linux 3.15.5
npm ERR! command
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/bin/node
/nix/store/ih3sbklf4ncxgs84pdi34hq0lk8lrfwg-nodejs-0.10.32/bin/npm
--registry http://www.example.c$
m --nodedir=/nix/store/qf80rbp1rrcmhkibmia2p64gqd881yvx-node-sources
--production --ignore-scripts install
npm ERR! cwd
/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1/lib/node_modules/reacttest
npm ERR! node -v v0.10.32
npm ERR! npm -v 1.4.28
npm ERR!
npm ERR! Additional logging details can be found in:
npm ERR!
/nix/store/aksz62alq8903cnp88iv0z36n0lrybjh-node-reacttest-0.1/lib/node_modules/reacttest/npm-debug.log
npm ERR! not ok code 0
builder for
`/nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv'
failed with exit code 1
error: build of
`/nix/store/6g9vk21ag4rzjl13dnqnq3nabb1hgas0-node-reacttest-0.1.drv'
failed
The package.json is as simple as:
{
name: reacttest,
version: 0.1,
dependencies: {react: *}
}
--
Paul
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Moving some of the NixOS setup to nixpkgs
Hi all, TL;DR: I'd like to discuss the empty space between declarative NixOS systems and imperative nix-env user profiles. As we all know, nixpkgs provides compiled packages and NixOS ties them together with environment variables, configuration files and systemd services. This dichotomy causes a bit of a problem for user environments, especially on nixpkgs installs outside NixOS. Examples are the environment variables TZDIR, CURL_CA_BUNDLE, OPENSSL_X509_CERT_FILE and others, which are in place for NixOS users but not for nixpkgs users. Without these, glibc and curl don't work 100% right. Plain nixpkgs installs should have these set in the user environment somehow. Another issue, is that configuration files are only generated for NixOS services. So if you as a user want to use nginx on an unprivileged port for development, you need to generate the configuration by hand instead of just specifying a port and getting a wrapper. One more related topic is declarative user environments. You can do it [1], but it's a bit of a hidden feature and not very straightforward. So I'm hoping that we can come up with a system where: - configuration wrappers are in nixpkgs, and NixOS modules use those. - multiple configurations of a package become multiple wrappers with user-definable names - environment variables like TERMINFO are declared in nixpkgs instead of NixOS modules and synthesized into the user environment instead of via NixOS - declarative user environments are made as easy as possible. Perhaps it should be the default and nix-env only edits the declaration. Thoughts please! Wout. [1]: https://nixos.org/wiki/Howto_develop_software_on_nixos#Obtaining_an_Environment_from_a_Custom_Definition ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Moving some of the NixOS setup to nixpkgs
Hi, I'm using nixpkgs outside NixOS, and I have to agree that there are a few things that could be a little bit better. I'll just list a few things that I had to work around. * Curl seems to work fine, except for when I'm using nix-prefetch-url. I haven't figured out what the actual issue is. However, a workaround is to set `NIX_CURL_FLAGS=-k`. * MANPATH is not set by the default nix.sh profile script. So, I need to set it myself. It would be great if there was some automation for such environment variables. E.g. also INFOPATH... * Related to the above. I needed to manually install locals, and configure the `LOCAL_ARCHIVE` variable. See [1] for details. Cheers, Andreas [1]: http://lists.science.uu.nl/pipermail/nix-dev/2009-May/002405.html ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NILFS2, NixOS, nixpart and Blivet
aszlig writes: On Tue, Sep 30, 2014 at 09:08:41PM +1000, Tim Barbour wrote: The most serious problem is that NILFS2 needs to update /etc/mtab when mounting a filesystem, so that it can store information about the [...] I don't have any experience with NILFS2 yet, but you might want to take a look at how it is handled when using NFS in fileSystems: I think your point is that NFS also needs to keep track of some state when filesystems are mounted and unmounted. https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/filesystems/nfs.nix I had a look at that file, but I could not see where it is handling the state. Nice :-) Have you considered submitting your patch for 0.41 upstream? If it doesn't get upstreamed too soon, I could include it as well while cleaning up the mess^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hupdating blivet/nixpart. That would be great. But as mentioned in the other mail, I'm working on nixpart 1.0 already, which should get rid of the monkey patching with 0.17. I attach a tarball with patches for Blivet (note that the 0.41 patch is untested). Yah, probably would make sense to test against 0.41, because I think we shouldn't aim for old versions, especially in terms of nixpart. Are you able to build a current Blivet to test with ? I just checked, and it looks as if Blivet is up to about 0.65 now: https://apps.fedoraproject.org/packages/python-blivet Tim --- GPG public key available at: http://phasechangeit.com/~trb/gpg-key or http://subkeys.pgp.net:11371 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Non-free files in some versions of WebKitGTK+
Original Message Subject:Non-free files in some versions of WebKitGTK+ Date: Wed, 1 Oct 2014 13:22:49 +0200 From: Alberto Garcia be...@igalia.com To: webkit-...@lists.webkit.org CC: distributor-l...@gnome.org A few days ago we discovered that some of the files included in WebKitGTK+ are covered by a license that does not allow redistribution. The files affected are the Web Inspector images, located under Source/WebInspectorUI/UserInterface/Images/. The full text of the license can be read here: http://trac.webkit.org/browser/trunk/Source/WebInspectorUI/APPLE_IMAGES_LICENSE.rtf In particular, clause 2 of the license states that you may, in connection with your development of WebKit, use the Apple Software for personal use or internally within your business or organization but that You may not redistribute the Apple Software, in whole or in part (with Apple Software meaning the Web Inspector images in this context). We have confirmed with Apple that our understanding of the situation is correct, so we have proceeded to look for free replacements for all the affected images. * We have released WebKitGTK+ 2.2.8, 2.4.6, 2.5.90 and 2.6.0 with the new set of images. * We have also fixed all the tarballs from the affected releases in the archive: 2.1.92 and the 2.2.x, 2.3.x, 2.4.x and 2.5.x series. The new tarballs have an 'a' appended to the version number (2.1.92a, 2.4.3a, etc) and have the non-free images removed or replaced with the free ones where possible, but are else identical to the old ones. The old tarballs are no longer available. http://www.webkitgtk.org/releases/ If you use any of the affected WebKitGTK+ releases, we urge you to upgrade to a version without the non-free images. We apologize for the situation, and would like to thank Dominique Leuenberger from openSUSE for reporting this problem. Best regards, Alberto Garcia ___ distributor-list mailing list distributor-l...@gnome.org https://mail.gnome.org/mailman/listinfo/distributor-list ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS small channel
Hi Eelco, Can we also have a small channel for unstable? Most of its build products will be reused by the regular jobs, so it shouldn't take away too many resources from regular builds, right? Wout. On Wed, Oct 1, 2014 at 9:00 AM, Luca Bruno lethalma...@gmail.com wrote: On 01/10/2014 03:29, Anderson Torres wrote: Yes! t is cool! :) But, how about the other channels? I use the nixos-unstable here, can I mix both, small and unstable, in my local machine? I also use unstable for the server because I need some changes that are only in unstable. ___ 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] Moving some of the NixOS setup to nixpkgs
Hi, On 2014-10-01 11:11 (Wednesday), Wout Mertens wout.mert...@gmail.com writes: Examples are the environment variables TZDIR, CURL_CA_BUNDLE, OPENSSL_X509_CERT_FILE and others, which are in place for NixOS users but not for nixpkgs users. Without these, glibc and curl don't work 100% right. Plain nixpkgs installs should have these set in the user environment somehow. ... One more related topic is declarative user environments. You can do it [1], but it's a bit of a hidden feature and not very straightforward. You should have a look on this: https://github.com/nilcons/ceh We support installing Nix in an easy way on top of modern mainstream linux distros (ubuntu, fedora, debian, nixos). And we have user environments in git, kind of. If you have specific questions about how stuff works or you find some issues while you're trying it out, please come back to us! We use this setup at our own startup for almost a year now (mainly for Haskell developing environment) and stuff works great, I wanted to announce this properly on this mailing list, but didn't find the time yet. Gergely ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?
On Wed, Oct 01, 2014 at 10:32:57AM +0200, Bjørn Forsman wrote:
On 27 September 2014 11:12, Vladimír Čunát vcu...@gmail.com wrote:
On 09/24/2014 09:58 PM, Bjørn Forsman wrote:
On 22 September 2014 17:16, Shea Levy s...@shealevy.com wrote:
I suppose a flag that says to rebuild if the output is valid but doesn't
have the right deriver could be what you want? But for now the best
answer
seems to be change the hash when it needs to change
I don't know what deriver is.
Deriver is the derivation that built a path (i.e. the build recipe).
If you built a path yourself, you can get it by
nix-store -q --deriver /nix/store/path
Ah, thanks.
Shea, it looks like the deriver (*.drv) doesn't change unless name
or the output hash attrs changes. So rebuild-if-deriver-changed won't
make any difference.
Nope, deriver will change if any attribute changes. Or can you show me
an example otherwise?
Even though it's a bit hackish, using
stdenv.mkDerivation rec {
extraHash = builtins.hashString sha256 (buildCommand);
name = foo-${extraHash}-0.0;
works just like I want it to.
Ouch, it broke real bad when using it in the real world[1]:
fetchGrailsAppDeps = { stdenv, grails, src, sha256 }:
stdenv.mkDerivation rec {
srcHash = builtins.substring 0 20 (builtins.hashString sha256
(builtins.toString src));
name = grails-app-deps-${srcHash};
[SNIP]
};
$ nix-build grails-app.nix
error: the string `grails-app-deps-b0f29513403e6dca5372' is not
allowed to refer to a store path (such as
`!out!/nix/store/80bd47sghjl4i41sd783b2w49lqzkm93-git-export.drv'), at
/nix/store/rjvnj4skg17is5x9jhzq1yl96mdvch0c-nix-1.7/share/nix/corepkgs/derivation.nix:8:12
This only happens when src = fetchgit { ... } and not when src =
./path/to/source. Why?
Use builtins.unsafeDiscardStringContext on the result of toString src
before hashString.
And what does this check protect against?
Now I have a big fat warning IMPORTANT: Remember to force re-download
deps whenever you update the source! in my expression :-(
Oh, this is bad...
I think I understand what you want: the output should not change except on
updating the package itself, but one can only find out the hash by
performing the build. On update you want to do that.
I personally force such rebuilds by changing the first few sha256 characters
to zeros. The extraHash way and Shea's suggestion are other fine ways. For
this use case, I find no clear winner, and I don't think we can do
significantly better.
What about a new, optional derivation input like extraHashInputs = [
list of attrs that will be included in calculation of $out ];?
[1]: https://gist.github.com/bjornfor/3f2fda1b1ce077225df5
Please no. This is fixing the problem in the wrong place.
Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?
Hi Shea,
On 1 October 2014 17:59, Shea Levy s...@shealevy.com wrote:
On Wed, Oct 01, 2014 at 10:32:57AM +0200, Bjørn Forsman wrote:
Shea, it looks like the deriver (*.drv) doesn't change unless name
or the output hash attrs changes. So rebuild-if-deriver-changed won't
make any difference.
Nope, deriver will change if any attribute changes. Or can you show me
an example otherwise?
Oh, you're right. It does change. I tested it in nix-repl (perfect
tool for the job!). Earlier today I didn't use nix-repl and must have
messed up when calling nix-build and nix-store -q --deriver.
So yes, a rebuild-if-deriver-changed option would be nice.
Even though it's a bit hackish, using
stdenv.mkDerivation rec {
extraHash = builtins.hashString sha256 (buildCommand);
name = foo-${extraHash}-0.0;
works just like I want it to.
Ouch, it broke real bad when using it in the real world[1]:
fetchGrailsAppDeps = { stdenv, grails, src, sha256 }:
stdenv.mkDerivation rec {
srcHash = builtins.substring 0 20 (builtins.hashString sha256
(builtins.toString src));
name = grails-app-deps-${srcHash};
[SNIP]
};
$ nix-build grails-app.nix
error: the string `grails-app-deps-b0f29513403e6dca5372' is not
allowed to refer to a store path (such as
`!out!/nix/store/80bd47sghjl4i41sd783b2w49lqzkm93-git-export.drv'), at
/nix/store/rjvnj4skg17is5x9jhzq1yl96mdvch0c-nix-1.7/share/nix/corepkgs/derivation.nix:8:12
This only happens when src = fetchgit { ... } and not when src =
./path/to/source. Why?
Use builtins.unsafeDiscardStringContext on the result of toString src
before hashString.
Thank you very much! Now the world makes sense again.
What about a new, optional derivation input like extraHashInputs = [
list of attrs that will be included in calculation of $out ];?
[1]: https://gist.github.com/bjornfor/3f2fda1b1ce077225df5
Please no. This is fixing the problem in the wrong place.
Ok. But a rebuildIfDeriverChanged = true; flag then?
Best regards,
Bjørn Forsman
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?
On 10/01/2014 09:15 PM, Bjørn Forsman wrote: Ok. But a rebuildIfDeriverChanged = true; flag then? A nix-build option for that would make much more sense to me than an argument to mkDerivation. (IIRC that's what Shea intended originally.) Vladimir smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?
On 1 October 2014 21:33, Vladimír Čunát vcu...@gmail.com wrote: On 10/01/2014 09:15 PM, Bjørn Forsman wrote: Ok. But a rebuildIfDeriverChanged = true; flag then? A nix-build option for that would make much more sense to me than an argument to mkDerivation. (IIRC that's what Shea intended originally.) Ok. My first thought was that a nix-build flag would be a very big hammer, and that it could cause unneeded rebuilds. But maybe you're right. Best regards, Bjørn Forsman ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] fixed-output derivation that *also* depend on (some of) its inputs?
On 10/01/2014 09:50 PM, Bjørn Forsman wrote: My first thought was that a nix-build flag would be a very big hammer, and that it could cause unneeded rebuilds. Hmm, with the flag you would have rebuilds of e.g. all things where you changed the download URI, true. But that seems an unlikely combination of events. smime.p7s Description: S/MIME Cryptographic Signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
