Re: [Nix-dev] Auto-generated expressions for applications
Let met try to sum up what I remember: - There 3+ solutions to update "sources" documented on the wiki somewhere - ideas from comparing versions with other distributions up to adding scrapers getting latest version from web sites if I recall correctly - Putting automatically generated code into nixpkgs doesn't solve all issues, for corner cases you have to duplicate dependencies using different version constraints. -> overhead - Its not always quite clear how stable the user wants to be (gimp/inskscape) case, master sometimes has new features. So which versions to support ? - Whatever we do, we don't solve anything for other distros (which suffer the same problem), unless we switch point of view: The solution would be a cross platform cross language dependency management system allowing to declare dependencies in a file so that you can even install from gihtub automatically. systemPackages = [ (fromGithub "user/package" "HEAD") ] # sort rest out on your own, thanks package A could be working, package B could be working, but [A B] in the same environment not (because they both depend on executable C) After all we want nixpkgs to be at least stable enough to have broken packages marked as broken and expect everything else to at least compile/install. Which are the best short/middle/long term solutions ? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nvidia & Cuda & Optimus - root required?
> Isn't there some /dev/* file representing the device that you can set > permissions on? (Half guessing here...) There are, but chmod 777 on /dev/nvidi* didn't help. Also it worked on a desktop machine if I recall correctly. So it eventually is optimus related. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Nvidia & Cuda & Optimus - root required?
Nvidia & Cuda: As root it works, as user it doesn't (even exporting the env from root). Easiest way to reproduce: $(nix-build cudatoolkit)/extras/demo_suite/deviceQuery Either outputs 'FAILED' or some info Has anybody a solution yet? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nvidia proprietary / i7 notebook - does not start
This worked, almost:
({config, pkgs, ...}: {
hardware.bumblebee.enable = true;
hardware.bumblebee.connectDisplay = true;
hardware.bumblebee.driver = "nvidia";
hardware.bumblebee.group = "users";
hardware.opengl.extraPackages = [ pkgs.vaapiIntel ];
services.xserver.videoDrivers = ["intel nvidia"];
services.xserver.deviceSection = ''
BusID "PCI:3:0:0"
BoardName "GeForce 940MX"
'';
})
(Thanks to github.com/yamafaktory/nixos-configuration)
After applying the GDM patch (.66 nivdia driver), I can start X with the
configuratino above, and glxgears -info shows 79 and 780
fpms/sec depending on whether optirun was used. nvidia shows intel or
nvidia.
nix-shell -p python36Packages.tensorflowWithCuda
then optirun python on
import tensorflow as tf
# Creates a graph.
a = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0], shape=[2, 3], name='a')
b = tf.constant([1.0, 2.0, 3.0, 4.0, 5.0, 6.0], shape=[3, 2], name='b')
c = tf.matmul(a, b)
# Creates a session with log_device_placement set to True.
sess = tf.Session(config=tf.ConfigProto(log_device_placement=True))
# Runs the op.
print(sess.run(c))
still shows CPU. The nix-shell command worked on a desktop, the test
script worked on ububntu on the same machine. So there is still a small
thing left to explore, but I do no longer have to reboot :)
Thank you very much for helping me.
Should a nixos-hardware-scan be able to detect such cases and write a
configuration like above? Then a nixos-rebuild boot/switch could
'regenerate' the config and warn if your system doesn't match what nixos
expected. Then you can review changes and things just work ?
If there are preferences to be choosen such as nvidia vs nouveau such
choice could be remembered ?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] nvidia proprietary / i7 notebook - does not start
Desktop: Everything is fine, the way it should Laptop: lspci: 03:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2) => Ubuntu -> fine => Nixos -> black -> then blinking cursor, no (EE) lines in X log I tried copying the relevant part from X.org defining drivers, screens, monitors from Ubuntus config to no avail. Also setting BusID AllowEmptyConfig and such didn't seem to work. Has anybody experienced the same issue/ maybe even solved it? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The .nixpkgs/config.nix file and user configuration
configuration.nix option nixpkgs.config is what ~/.nixpkgs/config.nix is for the user in case you missed it. Thus: nixpkgs.config.allowUnfree = true; nixpkgs.config.packageOverrides = p: .. You don't have to use config.nix if this is all you need. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The .nixpkgs/config.nix file and user configuration
1) misc.* is best looked by using ctagsWrapped on nixpkgs then looking
for misc. (or use grep)
You'll find pkgs/misc/misc.nix:
collection = {list, name} : runCommand "collection-${name}" {} ''
mkdir -p $out/nix-support
echo ${builtins.toString list} >
$out/nix-support/propagated-user-env-packages
'';
2)
If you had a look at other examples you'd try such:
{ ... }:
{
allowUnfree = true;
packageOverrides: p: {
myCollection = pkgs.misc.collection {
name = "graphic";
list = [pkgs.vlc];
}
}
}
then you can nix-env -iA myCollection or such
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The .nixpkgs/config.nix file and user configuration
Or ask google "nix/os/nixpkgs config.nix" to find samples and get inspiration from ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The .nixpkgs/config.nix file and user configuration
> I don't like the idea of using nix-env,
Why? You can also have your own declarative set of packages "per user".
that's also something config.nix can do:
graphicCollection = misc.collection { name = ... ; packages = [ ... . ]} (from
head)
nix-env -i graphicCollection
works well for me :)
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] The .nixpkgs/config.nix file and user configuration
> $HOME/.nixpkgs/config.nix file works. 1) you can install system wide (nixos-rebuild ..) 2) you can install as user into ~/.nix-profile.nix ~/.config.nix is to "customize" user nixpkgs by - setting settings such as allowUnfree - override mplayer to use library X - add your own packages FOO See here: http://stackoverflow.com/questions/36000514/how-to-override-2-two-packages-in-nixos-configuration-nix Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Suggestion: programs are *always* in the path
> > $ export NIX_AUTO_RUN=1 Well, maybe refactoring would make sense and call it ON_MISSING_BUT_KNOWN_EXECUTABLE=run/install/ask/ask_run/ask_install/ask_once_run/ask_once_install where run => runs ask => asks whether to run or run and install ask_install => asks to install ask_run => asks to run or similar. For instance I'd prefer "ask once per app" eventually because I could have made a typo. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] php-packages fix (broken since multiple outputs)
Excerpts from Alastair Pharo's message of dom abr 23 13:34:51 + 2017: > Sorry, I mangled the link to my PR in my previous email. The correct > link is https://github.com/NixOS/nixpkgs/pull/24648. This is another > attempt to fix the PHP situation, quite similar to your fix. Great - didn't look at configure. You took care about php-config and phpize, so I guess your patch should be preferred. Who is going to merge it and fix the brokeness? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] php-packages fix (broken since multiple outputs)
FYI I have an open PR for this on github as well: > https://github.com/NixOS/nixpkgs/pull/2464. Maybe we can compare notes. This issue is labeled "systemd-fstab-generator doesn't find fsck.ext3" thus seems unrelated. There is not much to discuss because * current situation is broken * its known why (includes aren't found) * The best way to fix it is fixing php-config (because it makes all packages compile) => The only think to discuss is the "assert" stuff so that in future all packages can be tested by php71Packages or such (better php71.packages) even better (php7x.packages) -> but that's another story: - https://github.com/NixOS/nixpkgs/issues/24432 - adding tests that the modules actually "work" as expected on multiple platforms The current situation is a stopper for me -> and the fix doesn't make things worse (testing is as good/bad as it previously was). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] php-packages fix (broken since multiple outputs)
Problem: Since outputs = ["out" "dev"] a lot of php-packages stopped compiling because php-config provided wrong includes http://mawercer.de/tmp/php-packages-out-dev.patch - moves php-config into php.dev - patches the includes directory so that headers are found - The patch also rewrites the assertion so that I could test all packages easily by nix-build -A php71Packages My question is, is there a different way to run nix-build -A php71Packages ignoring assertions so that all php packages can be tested easily? I'd like to prepare a PR. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What's the "perfect setup" for hacking on Nix?
If you want to change Vim, also have a look at https://github.com/MarcWeber/vim-addon-errorformats which allows to load multiple error formats and or https://github.com/MarcWeber/vim-addon-nix which already has an implementation. I personally never liked syntastic because it mixed running syntax checks and running scripts in the same plugin, therefore I forke https://github.com/MarcWeber/vim-addon-syntax-checker It also allows defining multiple checkers and debug which one is "usable" or not (for instance because executables are missing) But that's my personal preference. Never added nix cause I use vim-addon-nix. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl https://mailman.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What's the "perfect setup" for hacking on Nix?
ctagsWrapped -> simple nix support (so that you can jump to definitions) nix-instantiate --parse-only for syntax checking (vim-addon-nix on my github page, which also supports kind of follow import path implementation) Nix is dynamic, so there is not that much you can do (except creating some templates or read code). Hacking on C++ => ask the communities * Emacs * Vim * Eclipse * Atom * IDEA * Netbeans * (100 others) and judge yourself :) Typically you also want kind of "open file by typing some chars of the name" feature. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use PHP FPM with 2 PHP versions simultaneously
https://github.com/MarcWeber/nixpkgs/commit/5d1f3e9d4cfe5da9950b94b05203cfa128c2b288 => see comments nixos/modules/services/misc/phpfpm.nix This code even figures out how many fpm daemons to start. Thus if you change ini (eg enabling xdebug) you'll get an additional daemon because you cannot use a pool for it. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] gentoo like nixpkgs globala useflags in nixpkgs config - would it be worth it?
Issue pulseSupport -> does it make sense to have a global 'enable pulse
for all packgages' config.pulseSupport = true flag?
packages could be using: config.pulseSupport or false to disable by
default then.
Gentoo use flags traditionally have been used to enable commonly used
flags such as 'qt support' 'gtk support' or similar.
in the specific pulse case I was told on irc that most packages like
mplayer even work with pulse without having pulse built in.
But same applies to jackd or whatsoever.
The next question is: Which flags might be worth adding right now
(because for instance this would also mean changing flags for sox using
consistent naming which uses enablePulseaudio something flag).
And how / where would those global flags be documented ?
Having a defaultFlags = {
config.sox = null; # does this cause the package default being used in
"config.sox or false" ?
config.pulseSupport = null; # please note: you can enable, but most packages
will work with pulse without doing so
config.qtSupport = null;
config.gtkSupport = null;
}
And then there was a common way to document and set the same behaviour
which affects many packages. Maybe there is already a way which I might
have missed?
Thus package defaults could look like this:
pulseSuport ?
let flag = 'pulseSupport';
let package = 'sox';
in config.$flag or config.$package.$flag or false;
^ global ^ package global ^ derivation default
So you can set nixpgks config to either
pulseSupport = true -> all packages
mplayer.pulseSupport = true -> mplayer only
or still override with .override ( .. ) the known way.
I'm not going to change anything - just want to understand current
situation and whether its worth thinking about it.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How do you work on big packages?
Nix is 'software distribution platform', not a dev platform. Depending on the task other solutions might be better. For instance restarting nginx/ apache the nixos way is also slower than edit/restart cycle on 'debian'. So use the right tool / env for your job. There was a hack to impurely rewrite some dependencies for security reasons - forgot about it - so maybe you can force impurity to speed up your workflow. In the kernel case hat takes most time will be 'building it', thus you can try 'get compiled data' from your directory (binary distribution) like, then use something like nixos build-vm or such (disk caching reasons - no restart required). You can also try creating links to your 'dev' directory and switch off sandoxing and add a 'dummy env vars' which you increment to force rebuilding. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Inkscape pythonEnv - .sif export - PYTHONPATH wrapping
A commit turning the list of pythonpackages into pythonEnv broke the
export. The problem is I'm unsure how to suggest a proper fix to fr...@fridh.nl
because there are many ways to fix:
makeWrapper requires shell function toPythonPath provided by
${python}/nix-support/..
which is "gone" using pythonEnv. Possibilities to fix
1) revert
2) "rescue" adding python2 to buildInputs (providing toPythonPath)
see PATCH below
3) improve pythonEnv lifting toPythonPath from shell to nix world
4a) improve pythonEnv adding a run-in-python-env sot hat the wrapped
script looks like
#!/bin/sh
/nix/store/bin/python-env/bin/run-in-env /nix/store/...inkscape "$@"
4b) make it composable / sourcable
#!/bin/sh
source /nix/store/bin/python-env/nix-support/env
/nix/store/...inkscape "$@"
No idea which solution is best - thoughts?
People who are maintaining python might want to take care of.
Marc Weber
immediate fix: PATCH
diff --git a/pkgs/applications/graphics/inkscape/default.nix
b/pkgs/applications/graphics/inkscape/default.nix
index 2f72d00..53d612f 100644
--- a/pkgs/applications/graphics/inkscape/default.nix
+++ b/pkgs/applications/graphics/inkscape/default.nix
@@ -31,12 +32,23 @@ stdenv.mkDerivation rec {
libxml2 libxslt glib gtkmm2 glibmm libsigcxx lcms boost gettext
makeWrapper intltool gsl poppler imagemagick libwpg librevenge
libvisio libcdr libexif automake114x cmake
+
+python2 # provides toPythonPath
];
enableParallelBuilding = true;
postInstall = ''
# Make sure PyXML modules can be found at run-time.
+for i in "$out/bin/"*
+do
+ wrapProgram "$i" \
+--prefix PYTHONPATH : $(toPythonPath "${python2Env}") \
+--prefix PATH : ${python2Env}/bin || \
+exit 2
+done
rm "$out/share/icons/hicolor/icon-theme.cache"
'';
diff --git a/pkgs/applications/graphics/inkscape/default.nix
b/pkgs/applications/graphics/inkscape/default.nix
index 2f72d00..53d612f 100644
--- a/pkgs/applications/graphics/inkscape/default.nix
+++ b/pkgs/applications/graphics/inkscape/default.nix
@@ -31,12 +32,23 @@ stdenv.mkDerivation rec {
libxml2 libxslt glib gtkmm2 glibmm libsigcxx lcms boost gettext
makeWrapper intltool gsl poppler imagemagick libwpg librevenge
libvisio libcdr libexif automake114x cmake
+
+python2 # provides toPythonPath
];
enableParallelBuilding = true;
postInstall = ''
# Make sure PyXML modules can be found at run-time.
+
+# Make sure PyXML modules can be found at run-time.
+for i in "$out/bin/"*
+do
+ wrapProgram "$i" \
+--prefix PYTHONPATH : $(toPythonPath "${python2Env}") \
+--prefix PATH : ${python2Env}/bin || \
+exit 2
+done
rm "$out/share/icons/hicolor/icon-theme.cache"
'';
diff --git a/pkgs/applications/graphics/inkscape/default.nix
b/pkgs/applications/graphics/inkscape/default.nix
index 2f72d00..53d612f 100644
--- a/pkgs/applications/graphics/inkscape/default.nix
+++ b/pkgs/applications/graphics/inkscape/default.nix
@@ -31,12 +32,23 @@ stdenv.mkDerivation rec {
libxml2 libxslt glib gtkmm2 glibmm libsigcxx lcms boost gettext
makeWrapper intltool gsl poppler imagemagick libwpg librevenge
libvisio libcdr libexif automake114x cmake
+
+python2 # provides toPythonPath
];
enableParallelBuilding = true;
postInstall = ''
# Make sure PyXML modules can be found at run-time.
+
+# Make sure PyXML modules can be found at run-time.
+for i in "$out/bin/"*
+do
+ wrapProgram "$i" \
+--prefix PYTHONPATH : $(toPythonPath "${python2Env}") \
+--prefix PATH : ${python2Env}/bin || \
+exit 2
+done
rm "$out/share/icons/hicolor/icon-theme.cache"
'';
diff --git a/pkgs/applications/graphics/inkscape/default.nix
b/pkgs/applications/graphics/inkscape/default.nix
index 2f72d00..53d612f 100644
--- a/pkgs/applications/graphics/inkscape/default.nix
+++ b/pkgs/applications/graphics/inkscape/default.nix
@@ -31,12 +32,23 @@ stdenv.mkDerivation rec {
libxml2 libxslt glib gtkmm2 glibmm libsigcxx lcms boost gettext
makeWrapper intltool gsl poppler imagemagick libwpg librevenge
libvisio libcdr libexif automake114x cmake
+
+python2 # provides toPythonPath
];
enableParallelBuilding = true;
postInstall = ''
# Make sure PyXML modules can be found at run-time.
+
+# Make sure PyXML modules can be found at run-time.
+for i in "$out/bin/"*
+do
+ wrapProgram "$i" \
+--prefix PYTHONPATH : $(toPythonPath "${python2Env}") \
+--prefix PATH : ${python2Env}/bin || \
+exit 2
+done
rm "$out/share/icons/hicolor/icon-theme.cache"
'';
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Configure Nix to compile in RAMFS?
> is it possible to set Nix to compile in a RAMFS? If yes, how to do this?
fileSystems = [ { device = "tmpfs"; mountPoint="/tmp"; fsType = "tmpfs";
options = ["size=2m" "mode=1777"]; }]
(adopt to your liking)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] -realise: mounting /proc: Operation not permitted
What might be causing this? Nix-daemon nix version is the same which gets activated by the command below: /nix/store/jsfa19hfkrpg39njl7msrnsgfaxjvi3c-nix-1.12pre4997_1351b0d/bin/nix-store --realise /nix/store/kbw4v0hm7srarljkf5idk7ahspd59lp9-system-path.drv/nix/store/kbw4v0hm7srarljkf5idk7ahspd59lp9-system-path.drv these derivations will be built: /nix/store/pq24b3zvyx2fdajsy530vma0n3fgbiv1-NVIDIA-Linux-x86_64-375.26.run.drv /nix/store/msddw7c9wnjjmzwg8j9fmcm5gpgp2sgz-nvidia-x11-375.26-4.9.8.drv /nix/store/kbw4v0hm7srarljkf5idk7ahspd59lp9-system-path.drv building path(s) ‘/nix/store/r3219a23idwsvx8dw6zln2mlg34m0jdm-NVIDIA-Linux-x86_64-375.26.run’ error: while setting up the build environment: mounting /proc: Operation not permitted Marc Weber ___ 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
> Can you give a specific case where your type system would improve things > for either users or developers of nixpkgs? In my experience most of the > nix "code" I write is really just declaration or bash programming, and > it's not clear to me how different types would help. Have you never debugged a "got x but y expected" problem? The typesystem is there, its just lazy as nix is - typed on evaluation. If you write such code it helps: https://github.com/MarcWeber/nixpkgs-haskell-overlay/blob/master/pkgs/haskell-lib.nix But it turned out (oh surpise) that nix is not the best tool to implement a brute force solver for hackage packages in. What about guix https://www.gnu.org/software/guix/ ? Does some typing exist here already? If you need a nice idea about "how to improve the world" - nix guix and the JS implemenation (and the 100+ other distros) clearly say that a cross platform cross language package manage / depndency system is required to derive .nix / guix /whatsoever packages from .. It should allow "platforms" (like Haskell) to have "stable bases" to work on. That would be awesome and the whole open source community & nix would benefit IMHO. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How do I know I can enableParallelBuilding?
> We should als document why parallel building is disabled by default.
build 3 times -> if it works 3 times you are likely to be fine.
You never know for sure.
mkDervation {
run = "1"; # should cause rebuild # inc 2 times
}
whether builds succeed depends on load/ moon /weather / your nose / disk
load / (you get it)
Sometimes the authors know (mailinglist/google/irc)
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell workflow - ghc not in PATH - recommended way / documentation?
> nix-shell -A env
my fault - sry.
In the past I used sourceAndTags to get sources tagged (using hasktags)
so that I was able to jump to source using Vim's :tjump command (and
search names) fast.
Is this workflow "outdated" eg because hoogle can do it or should I try
integrating it into current haskell-packages?
hastags fails at "template haskell generated stuff", adding it is
trivial because its just applying
addHasktagsTaggingInfo = deriv : deriv // {
to an existing derivation. It served me quite well that time.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Haskell workflow - ghc not in PATH - recommended way / documentation?
It's way too much work to keep maintaining my nixpkgs-haskell-overlay.
Trying the workflow specified in the manual:
1) ./default.nix:
{ nixpkgs ? import {}, compiler ? "ghc7102" }:
nixpkgs.pkgs.haskell.packages.${compiler}.callPackage ./foo.nix { }
2) cabal2nix . >| foo.nix
3) nix-shell --command zsh
however doesn't put ghc in PATH.
BTW: Cabal2nix on cabal2nix seems to fail:
configureFlags: --verbose
--prefix=/nix/store/qk9jk6abnqzg8dybzgiabm4p3wjmflr0-distribution-nixpkgs-1
--libdir=$prefix/lib/$compiler --libsubdir=$pkgid --with-gcc=gcc
--package-db=/tmp/nix-build-distribution-nixpkgs-1.drv-0/package.conf.d
--ghc-option=-optl=-Wl,-rpath=/nix/store/qk9jk6abnqzg8dybzgiabm4p3wjmflr0-distribution-nixpkgs-1/lib/ghc-7.10.2/distribution-nixpkgs-1
--enable-split-objs --disable-library-profiling --disable-executable-profiling
--enable-shared --enable-library-vanilla --enable-executable-dynamic
--enable-tests
Configuring distribution-nixpkgs-1...
Setup: At least the following dependencies are missing:
Cabal >1.24
builder for
‘/nix/store/9ml89qkri8fkn1bldyh446a2g6rkscjc-distribution-nixpkgs-1.drv’ failed
with exit code 1
error: build of
‘/nix/store/9ml89qkri8fkn1bldyh446a2g6rkscjc-distribution-nixpkgs-1.drv’ failed
I'm pretty sure that I missed something obvious ..
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Separate repository for autogenerated lists of urls and hashes
I personally think that "autogenerating" packages is the next huge step to be taken. This requires a database and dependency information for all information. Then all distros can benefit, not just nixos.org Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Python & installation
> IIRC the wiki is read-only now on purpose. Its content is being (slowly) > reviewed and integrated into our documentation. > https://github.com/NixOS/nixpkgs/milestones/Move%20the%20wiki! It would not hurt adding comments to a wiki template: The wiki is readonly and will be integrated into the nixpkgs manual. See _issue of github_. Thus the only changes which will be done here will be "removing content" or "telling that moving all important pieces is complete". Then when all contents have been moved an article could be "deleted" or marked as "done". How do you keep track of progress otherwise? A readonly copy could be offered as "archive" (or html dump). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Python & installation
Those are my results - python27.buildEnv worked - nixos wiki: still contained the myEnv solution on the python page. I guess that should be replaced by buildEnv for "my use case". I tried fixing the article but can no longer login. Trying to reset password yields "Error sending mail: Unknown error in PHP's mail() function." manual: SOLUTION 1: https://github.com/proger/python2nix pip installed, PYTHONPATH set, error failed to load / import "log". => README should be updated about how to install it? SOLUTION 2: https://github.com/garbas/pypi2nix => fails on matplotlib (png dependencies or such), thus some additional hint in the README about how to provide them would be nice. I can guess, but I don't like guessing. Then it looks very promising. SOLUTION 3: offlinehacker-pypi2nix/pypi2nix %pypi2nix requirements.json out these derivations will be built: /nix/store/5lbb4vnbyxp9f9wcx1ifq910c8xklb8c-pypi2nix-requests-py27.drv building path(s) ‘/nix/store/f0zakhamn9c0pyqnp7mvwl81bw0hhip1-pypi2nix-requests-py27’ --2016-04-23 10:08:45-- https://raw.github.com/buildout/buildout/master/bootstrap/bootstrap.py Resolving raw.github.com (raw.github.com)... 185.31.17.133 Connecting to raw.github.com (raw.github.com)|185.31.17.133|:443... connected. ERROR: cannot verify raw.github.com's certificate, issued by 'CN=DigiCert SHA2 High Assurance Server CA,OU=www.digicert.com,O=DigiCert Inc,C=US': Unable to locally verify the issuer's authority. To connect to raw.github.com insecurely, use `--no-check-certificate'. builder for ‘/nix/store/5lbb4vnbyxp9f9wcx1ifq910c8xklb8c-pypi2nix-requests-py27.drv’ failed with exit code 5 error: build of ‘/nix/store/5lbb4vnbyxp9f9wcx1ifq910c8xklb8c-pypi2nix-requests-py27.drv’ failed Traceback (most recent call last): File "/nix/store/pw96jxliw0f1nsr91jl71c0mmk5j98gk-python2.7-pypi2nix-1.0_04a68d8577acbceb88bdf51b1231a9dbdead7003/bin/.pypi2nix-wrapped", line 12, in sys.exit(main()) File "/nix/store/pw96jxliw0f1nsr91jl71c0mmk5j98gk-python2.7-pypi2nix-1.0_04a68d8577acbceb88bdf51b1231a9dbdead7003/lib/python2.7/site-packages/pypi2nix/cli.py", line 143, in main tmp = run_buildout(eggsdir, config) File "/nix/store/pw96jxliw0f1nsr91jl71c0mmk5j98gk-python2.7-pypi2nix-1.0_04a68d8577acbceb88bdf51b1231a9dbdead7003/lib/python2.7/site-packages/pypi2nix/buildout.py", line 248, in run_buildout return buildout.run(eggsdir) File "/nix/store/pw96jxliw0f1nsr91jl71c0mmk5j98gk-python2.7-pypi2nix-1.0_04a68d8577acbceb88bdf51b1231a9dbdead7003/lib/python2.7/site-packages/pypi2nix/buildout.py", line 104, in run cwd=buildout_dir, shell=True File "/home/anton_lvov/.nix-profile/lib/python2.7/subprocess.py", line 573, in check_output raise CalledProcessError(retcode, cmd, output=output) subprocess.CalledProcessError: Command '['/run/current-system/sw/bin/nix-build']' returned non-zero exit status 100 %cat requirements.json [ "requests", "unidecode", "pysqlite", "pandas", "matplotlib", "scipy", "scrapy", "mpl_toolkits", "statsmodels", "BeautifulSoup4" ] Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Python & installation
The question I have is which is the recommended way to install "scrapy along with dependencies", the following fixes it by making propagatedUserEnvPkgs equal to propagatedBuildInputs.. is there another way? diff --git a/pkgs/development/python-modules/generic/default.nix b/pkgs/development/python-modules/generic/default.nix index 1fdbd4f..458d187 100644 --- a/pkgs/development/python-modules/generic/default.nix +++ b/pkgs/development/python-modules/generic/default.nix @@ -70,6 +70,8 @@ python.stdenv.mkDerivation (builtins.removeAttrs attrs ["disabled" "doCheck"] // # propagate python/setuptools to active setup-hook in nix-shell propagatedBuildInputs = propagatedBuildInputs ++ [ python setuptools ]; + propagatedUserEnvPkgs = propagatedBuildInputs ++ [ python setuptools ]; + pythonPath = pythonPath; configurePhase = attrs.configurePhase or '' Then installing scrapy and setting PYTHONPATH or PYTHONUSERBASE seems to enough. Full patch adding the missing packages: http://mawercer.de/tmp/scrapy-diff.patch Is there an automated maintained way to do such python packaging work I missed? Sorry for asking such stupid question - I didn't look at python for a long time. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using Nix as a package manager (for yet another language)
urweb requires C/C++ libraries (eventually). AFAIK C/C++ package managers don't exist (dependency information) - they are "encoded in configure scripts and whatnot" - for some universes (gnome) there are dependency informations available eventually. Thus for that use case nix is a good fit, because you can "provide a working set of dependencies" within nixpkgs - and because nix also forces you to have "one maintained set of packages". Eg hackage theoretically allows infinite amount of combinations nobody can test in real life. All languages I know (Haskell, python, ruby) depend on C libraries and thus partially suffer from such kind of problem - even Vim depending on python and whatnot... Thus yes: Nix is likely to provide results you can live with fast. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] [Bachelors Thesis] Studi-Cloud VMs managing with Nix?
VMs: Either you put the 'iso's on disk, then each VM has its own data on disk (may startup faster) - or you "share data" and fetch it via network (nfs or whatever) - like "network booting", then you can share, ad you can have "one nixos host" sharing all mysql/postgresql and the configs required to boot the different systems .. Having many isos is not a problem - that's why nix has a garbage collector :-) The nice thing is using nix you can share the configuration and do both: generates isos or do network boot (in theory - no idea whether a lot of work as been done on this ..) Some packages do depend no "nix" setups (eg /etc/*) thus may or may not work on regular linux systems as expected. But serausly, if the profs need etiher mysql or postgresql why not put both on one iso and be done? Should students switch isos if they "happen to require the other software .." ? Because nixos can "switch configurations" there are more options: use usb sticks, then each prof can provide his config and students can update their 'usb clone' fast because only differences will be fetched (doing as much sharing on the stick as possible). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Please help me with getting the Taskserver service running
> The problems I'm facing is mainly the fact that the taskserver wants > to create certificates and keys[1]. A follow-up problem will be the > creating of users on the taskserver. What about describing which kind of user(s) you mean? /etc/passwd ones? See MySQL service for instance and ids.nix. Certificates: Apache and similar have settings to tell it which certificates to use. You want to look at similar services like ssh/dovecot/... how it is done. I'm unsure. There are two choices: Either use a pre startup script to create them (eg mysqlinit or such gets used this way) - or allow user to set paths. Usually its nice if things "just work" which means generating certificates. Eg mysql does not populate time zone info (mysql_tzinfo_to_sql /etc/zoneinfo/ | mysql) should it be done? the MYSQL_TZ function requires it (otherwise it returns null) If nobody has a strong opnion just be the maintainer and make a choice ? Testing services see nixos/tests/* How to run? See nixos/release.nix or release-combined. nix-build -A tests.firwall -f release.nix or such. (I didn't run any test for a long time). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: Nix PHP / php-fpm patch suggestion / reminder
I tried sending this mail to the mantainer ro...@glob.in, but his email
address seems to be no longer current.
Thus who is maintaining PHP ?
--- Begin forwarded message from Marc Weber ---
From: Marc Weber marco-owe...@gmx.de
To: robin ro...@glob.in
Date: Sat, 15 Aug 2015 16:30:53 +
Subject: Nix PHP suggestion:
You're listed as maintainer for PHP
If you use this code
composableDerivation.composableDerivation {
# merge some php plugins into the derivation, so that the plugins fit the
PHP version
mkDerivation = args:
let php = pkgs.stdenv.mkDerivation args;
in php // callPackage ../../../top-level/php-packages.nix { inherit
php; inherit fetchgit; }
} (fixed: {
You can use php54.acpu for instance instead of creating php54 package
dictionary. This should make things simpler.
Question: How big is the interest in my php-fpm code currently?
===
I also have sophisticated php-fpm code which creates the the fpm
instances on its own depending on differing ini files and such because
it creates php-ids to find out which php's differ.
Usage apache looks like this, mind the nice syntax for xdebug:
let php56 = pkgs.php56.merge { fpmSupport = true; gdSupport = true; };
in
phpfpmPools = {
php56 = {
daemonCfg.xdebug = { enable = true; port = 9000; };
# daemonCfg.opcache.enable = true;
daemonCfg.apcu.enable = true;
daemonCfg.php = php56;
daemonCfg.phpIniLines = ''
extension = gd.so
always_populate_raw_post_data = -1
post_max_size= ${max_size_mb}M
upload_max_filesize= ${max_size_mb}M
memory_limit = ${max_size_mb}M
max_input_vars = 1
; xdebug.profiler_enable = 1
; xdebug.profiler_output_dir=/pr/www/xdebug
; xdebug.profiler_output_name=cachegrind.out.%t.%R
'';
poolItemCfg = {
inherit environment;
user = marc;
group = users;
request_terminate_timeout = ${timeout_secs}s;
listen = { owner = config.services.httpd.user; group =
config.services.httpd.group; mode = 0700; };
slowlog = /pr/www/slow-log-5.6;
extraLines = ''
php_admin_value[upload_max_filesize] = ${max_size_mb}M;
request_terminate_timeout = ${timeout_secs}
'';
};
};
}
FastCGIExternalServer /dev/shm/php5.6.fcgi -socket
${config.services.phpfpm.socketPathFun phpfpmPools.php56} -flush -idle-timeout
${timeout_secs}
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] YouCompleteMe vim plugin
I use such, instead of VAM you can use vundle, however this direct
comparison has shown that VAM event starts up faster.
vimMarc =
vim_configurable.customize {
name = vim-marc-weber;
vimrcConfig.vam.knownPlugins = vimPluginsUsedByMarcWeber;
vimrcConfig.vam.pluginDictionaries = [
''vim-addon-manager''
{ name = ''github:MarcWeber''; }
{ name = ''vim-addon-other''; }
{ name = ''vim-addon-local-vimrc''; }
{ name = ''snipmate''; }
{ name = ''vim-snippets''; }
{ name = ''vim-addon-mru''; }
{ name = ''vim-addon-commenting''; }
{ name = ''vim-addon-sql''; }
{ name = ''vim-addon-completion''; }
{ name = ''vim-addon-async''; }
{ name = ''tlib''; }
{ name = ''vim-addon-toggle-buffer''; }
{ name = ''vim-addon-git''; }
{ name = ''vim-addon-mw-utils''; }
{ name = ''vim-addon-goto-thing-at-cursor''; }
{ name = ''matchit.zip''; }
{ name = ''vim-addon-syntax-checker''; }
{ name = ''vim-addon-rfc''; }
{ name = ''vim-addon-surround''; }
{ name = ''vim-addon-toc''; }
{ name = ''vim-addon-haskell''; filename_regex =
''\%(\%(l\)hs\|cabal\)$$''; }
{ filename_regex = ''\%(php\|inc\|php.inc\|hsc\|lhs\)$$''; names =
[ ''phpcomplete'' ''vim-addon-xdebug'' ''vim-addon-php-manual'' ]; }
{ filename_regex = ''\.\%(iced\|coffee\)$$''; names = [
''sourcemap.vim'' ''vim-iced-coffee-script'' ]; }
{ name = ''vim-addon-haskell''; filetype_regex =
''\%(cabal\|hs\|hsc\|lhs\)$$''; }
{ filetype_regex = ''\%(rb)$$''; names = [ ''vim-ruby''
''vim-addon-rdebug'' ''vim-addon-ruby-debug-ide'' ''textobj-rubyblock'' ]; }
{ filetype_regex = ''\%(rs)$$''; names = [ ''rust'' ]; }
{ filetype_regex = ''\%(nix)$$''; names = [ ''vim-addon-nix'' ]; }
{ filetype_regex = ''\%(vim)$$''; names = [ ''reload''
''vim-dev-plugin'' ]; }
{ name = ''sparkup''; filename_regex =
''\%(html\|xml\|php\|php.inc\|inc\)''; }
];
};
Documentation see misc/vim-plugins/vim-utils.nix
As alternative you can just install YouCompleteMe and symlink that
directory ~/.nix-profile/... into your vundle dir.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS won't boot anymore in certain generations, don't know why (Stage-1 error)
I also have a problem with luks - didn't debug it yet. Some lines appear saying that target link already exist. I can boot this way: in grub hit e, add boot.shell_on_fail or shell_on_fail, then you can debug the mounting / boot process, eg enter interactive shell, then you can mount your partition manually on /root* something After exiting I can boot. I don't restart often so I didn't investigate. A google search told me it could be a race condition. Thus have a look at the shell_on_fail within stage-1 and stage-1 init scripts to learn more about the startup process - then you can debug. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cron job to backup a database as part of the configuration.nix file
1) writeScriptBin (see samples in nixpkgs) 2) services.cron.systemCronJobs = ... Marc ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Confused about packages
Excerpts from Roger Qiu's message of Tue May 19 05:56:30 + 2015:
Wouldn't it be better for version numbers to always exist?
You're totally right that the
mkDerivation {
name =name-version
}
version should always exist. Thus if you find cases just create a topic
branch, fix, and submit once in a while.
I was quite surprised that mysql in all-packages.nix started pointing
to mariadb which broke my ruby overlay because headers were not found.
Thus what can you do?
there is builtins.compareVersions function, and there are nixos module
assertions - thus you could ensure this way that compareVersion
pkgs.mysql equals 5.0 or so - or you could just add a constraint
mysql.name = mysql-5.0 which would fail building.
You always know the version as long as you're using the same nixpkgs
revision - but sometimes you have to update - and then adding such nixos
assertios would be close to what you want. Just grep nixpkgs/nixos for
assertions to see samples.
However usually upgrades just happen to work fine - in the end testing
for versions doesn't protect you from mal functioning (eg a dependency
could have changed) - thus what you really want is writing tests.
There are some samples in the nixpgks repository as well.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Confused about packages
[ with and without version numbers ] Version numbers get added if people find that there is need to keep multiple versions. Thus its kind of random where / how to find package names See https://nixos.org/wiki/Howto_find_a_package_in_NixOS Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Overriding a node package
Dependencies will be fetched from npm repository - thus is questionable whethere overriding some packages gets the job done at all IMHO. I don't know/care atm. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Overriding a node package
This patch is outdated, but illustrates what you're looking for: https://github.com/MarcWeber/nixpkgs/commit/ad6ec783bb61e80f90d6e6ee9e0b2d026982fbbe There is npm2nix utility you have to install. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why are there so many branches in the nixpkgs repo
We could go over a list of those that are merged (git branch -r --merged master), but still for example 'upstart' is a branch that was taken before systemd has replaced it. Maybe it should be a tag. I made the suggestion that too experimental branches / new ideas etc could be submitted to github.com/nixos/nixpgks-ideas or so. This would keep the official repository clean while allowing to submit less common code or keep more history as appropriate. In any case I'd vote for a VERISON file which explains a branch's purpose shortly. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Can we please have text-only on this ML?
benefits text: - minimal bandwidth - user can configure his/her client how to view - looks always the same - no js Thus why are discussing HTML at all - for making some texts *bold*? HTML also runs the risk to not be displayed the same everywhere - eg google mail rewrites inline styles (background images) - no idea what else gets rewritten in strange ways on strange email clients. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell: indexing all packages on Hackage with Hoogle
I often don't use hoogle, hack-nix can autotag sources you use for projects - that is always accurate. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] postfix - generating alias tables in store and some additional changes
Is anybody interested in these? https://github.com/MarcWeber/nixpkgs/commit/1bb2f95c9ab792422a89c11e1f629dcff2cbf322 marc-nixos/postfix - use null instead of for some options which means don't set option at all to make it clearer that the option is unset rather than set to which means postfix defaults apply - use default configuration /etc/postfix/main.cf So that sendmail and postfix flush just works and postconf prints correct configuration location and that its no longer necessary to pass configuration location - remove all the impure ln stuff creating untracked files in the conf directory. Instead create .db files in store (TOOD: !take care about passwords!) - replace options extraAliases, postmaster etc by assertions forcing you to think about creating alias table - assemble command dir adding links to sgid wrapped applications correctly TODO: merge with upstream changes If so I'll try to clean up and submit a PR. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] recent calligra breakage - how to prevent?
We could also introduce nixos style
executables.krita.checks.--help = true;
executables.krita.checks.exists = true;
test -x $out/bin/x
test -x $out/bin/y
Is duplicate testing code
for prog in x y; do
$out/bin/$prog
done
makes it harder to debug what's going on, because shell script will
exit at line foo - its still simple enough
for prog in x y; do
$out/bin/$prog || { echo prog $prog is missing; exit 1 }
done
is that much code that its worth moving into setup.sh IMHO
which is why I'm asking - because documentation purpose could be helpful
as well.
If in doubt - be simple - but version is best ? ..
For the time beeing I'll keep as is - after all I'm human, the next time
I'll know where to look at if krita is missing.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Why Bash and Nix-Shell have no completion?
It got implemented somewhen in the past, some people told about
bash completion being annoying in some cases (- [1]) .. which means the perfect
solutions means conditional opt-in/out eventually.
bash.nix has:
interactiveShellInit = ''
[...]
${bashCompletion}
I personally have patches putting a
source /etc/bash/setup-all
in ~/.bashrc as default which means:
1) user can edit .bashrc (because its not a symlink)
2) user can opt-out easily
3) user can look at setup-all which allows him/her to opt-in/out from
individual features or completion scripts, such as individual
completion scripts..
- [1]
those patches change quite a lot - and I'm unsure whether its worth
merging them into master.
I want to say: Builders should be as clean as possible eventually.
Thus opt-in makes sense - look at ~/.bashrc and source that script
to enable default behaviour ?
Marc Weber
[1] This is the sample code of my /etc/bash/nix-bash-lib which gets
sourced by /etc/bash/setup-all, it opts-out from gnu utils which was
reported to be annoying long time ago - so it might be outdated.
You could use such in your .bashrc
NIX_COMPL_SCRIPT_SOURCED[ALL] = anything
NIX_COMPL_SCRIPT_SOURCED[the-individual-compl-script] = anything
source /etc/bash/setup-all
to opt-out.
declare -A NIX_COMPL_SCRIPT_SOURCED
# potential problems (-rev 20179)
# - It doesn't support filenames with spaces.
# - It inserts a space after the filename when tab-completing in an
#svn command.
# - Many people find it annoying that tab-completion on commands like
#tar only matches filenames with the right extension.
# - Lluís reported bash apparently crashing on some tab completions.
# comment: Does this apply to complete.gnu-longopt or also to bash_completion?
NIX_COMPL_SCRIPT_SOURCED[complete.gnu-longopt]=1
if shopt -q progcomp /dev/null; then
# bash supports completion:
nix_add_profile_completion(){
local profile=$1
# origin: bash_completion, slightly adopted
# source script only once - allow user to use NIX_COMPL_SCRIPT_SOURCED to
# opt out from bad scripts. If a user wants to reload all he can clear
# NIX_COMPL_SCRIPT_SOURCED
local nullglobStatus=$(shopt -p nullglob)
shopt -s nullglob
for s in $profile/etc/bash_completion.d/*
$p/share/bash-completion/completions/*; do
local base=${s/*\//}
[[
-z ${NIX_COMPL_SCRIPT_SOURCED[$base]}
-z ${NIX_COMPL_SCRIPT_SOURCED[ALL]}
]] { . $s; NIX_COMPL_SCRIPT_SOURCED[$base]=1; }
done
eval $nullglobStatus
}
else
nix_add_profile_completion(){ :; }
fi
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] recent calligra breakage - how to prevent?
Recently calligra broke.
I'd like to introduce a simple patch like this:
http://mawercer.de/tmp/calligra.patch
It should ensure that the build fails eg if krita is missing. The
problem was that updating eigen caused calligra to determine krita
cannot be build, so everything else of the suite was build.
Now this is a hack - what about being more declarative introducing
mkDerivation {
[...]
expect.executables = [krita ...]
}
Later this could also be used for documentation purposes - eg finding
packages which provide some specific executables.
Does this already exist?
Marc Weber
Im Tannhoernle 4/1
D-78052 Villingen-Schwenningen
Germany
Mobil: 017660032282
Steuernummer: 22483/ 29259
Finanzamt Villingen-Schwenningen
DE12345678
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to create dirs needed by a module before it runs?
Why not cd into the modules directory and grep for mkdir? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] parallel make (was: Again: Why don't these people havecommit access)
How complicated is it to override mkDerivation in nixpkgs passing parallelBuilding = true ? I think we have a documentation issue. There should be flag such as: parallelBuildingPossible = yes/sometimes/no; instead of parallelBuilding = true. Then Michale Raskin's tests would not fail on packages which are known to not build correctly ... Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
Marc I think it's the general case of more complex PRs. PR that change too much or add too much tend to be delayed. Not only because they are harder to test, but also harder to agree on by more peopl Well - I did take care - I added the new cups version as opt-in. It was your choice. You were free to keep using the old one. I think history is history.. we should talk about the future which also might affect guix (http://www.gnu.org/software/guix/) In the Vim community people leave over and over again because patches don't get accepted or are not taken care of. Just about 2 days ago there was another case. I think that being able to use nixos as desktop system (which implies being able to print) should be a high priority. We also have a new situation compared to back in the old SVN days: _We have releases_ Thus breaking stuff is still bad, but maybe less bad than before. The problem is: We all need stable systems - thus if everybody uses the stable systems nobody is going to use the less stable - thus less testing will happen. But let's talk about a specific case: My patches to apache httpd module: https://github.com/MarcWeber/nixpkgs/commit/7cdeb3f63ee1e26b6113754995284c56257ef162 The apache one breaks the API because I don't want to mess with port stuff (to not mess with .htaccess) so I just created my own loopback device .. Figuring out how to patch this in a backward compatible way was something I could not afford. My current situation is that I update my system only once every couple of weeks because I cannot afford recompiling everything over and over again. Just to say, it's not lack of trust, or being negative. It's lack of time (or platform) for proper testing and lack of time for proper understanding (linux is becoming too giant) the consequences of a change. Well - NSA cases and the one fosdem video (what would I do If I had one million $ and if it was my task to compromise the world ..) was fun to watch: http://video.fosdem.org/2014/Janson/Sunday//NSA_operation_ORCHESTRA_Annual_Status_Report.webm Thus to truly improve you also have to start measuring who reviewed commits to maximize value by spent time - and that not only for nixpkgs but also for projects like openssh. There is no way to ensure that an update will not cause a random failure on hardware X which will happen only once a month. One huge benefit from having commit access would be that experimental or complicated stuff could be submitted as topic cranch to increase visibility and that other people can join such effort and help taking it to a level where it can be merged. I love topic branches because they use two files: .topmsg = The commit message which would be created when all commits got collapsed. The nice thing is that each branch documents its purpose on its own. .topdeps A list of other branches it depends on Then there is a tg update command to merge with all dependencies and a tg export command to collapse in order to yield a nice commit which can be reviewed more easily. The wiki contains a longer introduction. I don't say topgit must be used. But I highly recommend having such topic specific file documenting the purpose of a branch That's another story: do we want many official experimental topic branches? Making experimental branches visible to others would improve collaboration a lot. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Again: Why don't these people have commit access
I can only speak for myself: In the past the community or some members didn't accept what I did for various reasons. That's why I did no longer run for 'commit' access since then. A summary with some cases (some time has passed, maybe my memory is no longer that accurate - but it should give an idea): - patches about parallel building got stuck = result: 3 people (Lluís Batlle, me , Peter) tried different implementations. The first patch was not accepted for no reply is no ok reason - I didn't get a ok due to minor refactoring of make arguments in builder and because some people feared about purity (it would have been opt-in) I messed up hydra that time (due to some -n -j being interpreted as run as much as possible) It was pretty depressing for me because I had need for -j 4 and not getting it into nixpkgs made it impossible for me to use hydra. - patches about cupsd got stuck (due to using versionedDerivation) = fixed printing for me - was later asked on the mailinglist for) - I did mess up python once and did not have time within 5 days or so to fix it - those had to be reverted by Eelco Dolstra - Work on php-fpm was done twice, by me and by somebody else. My version of php-fpm is more complicated but also very complete because it determines how many php-fpm daemons to start on its own. - I eventually had pushed the zsh/bash patches (which I guess are partially obsolete now) - they allow users to opt-out and allow modules/the admin to define bash/zsh snippets to be added to a global bashrc/zshrc which gets sourced by ~/.bashrc so that users can opt-out from everything or pieces. - I would have fixed eigen(2) in krita of calligra much faster = Thus because I have not had commit access this had to be debugged twice. - I have patches pending for apache http and nginx making them more configurable (eg allowing to set the IP to listen to) To sum up: I tend try to apply the 20/80 rule: 20 percent of effort should yield 80% of the desired result - which seems not always to be good enough. Thus in the past I caused both: goodness and badness - thus its fine for me that my commits get reviewed. Thus if PR's don't get accepted I do no longer take it personally - changes end up in my topic branches instead. I treat Nixos to be a very good option to get some jobs done - still seeing much room for improvements. Eg there are 3 implementations: nixpkgs/a js one and guix. Thus moving towards a global package database more distros could derive package descriptions from is much more important to me than caring too much about policies - because I see Nixos to be a tool only to get a job done. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] announce: patch introducing resource tracking
The idea is to prevent the admin from starting multiple daemons accessing the same directories or using the same ports by accident. My updated mysql.services patch [1] depends on it: https://github.com/MarcWeber/nixpkgs/commit/301043d68330646cd245657d2b6ea72703558048 I'm little unsure whether tcp/udp should be tracked differentyl or by keys tcp:80 udp:80 or such. Are there more resources which are worth tracking ? I recommend looking at the patch because it could serve as sample for similar cases such as multiple postgresql instances or whatsoever. Marc Weber [1] https://github.com/NixOS/nixpkgs/pull/5542 ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Multiple instances - detecting resource collisions - nixos module system question
If you use multiple apaches/nginx/mysql/postgresql/whatever instances
its likely to miss adjusting the port or whatsoever. Therefore I'd like
to implement a simple resource tracking module which fails if a
resource such as tcp/ip port or socket or such gets used multiple times.
It should look like this: http://dpaste.com/10RKJSQ
A test like this:
resources.tcp-ports.80 = {};
causes:
The option `resources.tcp-ports.80.allowCollisions' defined in
`/etc/nixos/nixpkgs/nixos/modules/misc/resources.nix' does not exist.
which I don't get because the dpaste sets a default value for
allowCollisions.
Thus does anybody just spot what I'm doing wrong?
If we are at it: Eelco Dolstra proposed services.mysql.services or
such. What about services.mysqls ? We could deprecade services.mysql
then and ask users to switch slowly. No naming collisions. Naming is
short and could be adopted to other services.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] newbie question: Which name is used for eclipse-sdk-4.4 in /etc/nixos/configuration.nix
(Unfortunately I don't know a good reference to point to for a description of this.) https://nixos.org/wiki/Howto_find_a_package_in_NixOS Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Multiple MySQL instances (or nginx/apache/...)
How should this be written in the future ?
I've submitted a pull request which tries to change not much lines to
reach my goal - however I agree that it might not be the perfect
solution yet: https://github.com/NixOS/nixpkgs/pull/5542
This change adds a parameter moduleName to the mysql module which then
gets used for most defaults (pid file, data dir and so on)
{ moduleName ? mysql}: # eg pass mysql2 to add a second mysql
services.${moduleName} = {
enable = mkOption {
default = false;
};
user = mkOption {
default = moduleName;
[...]
Final usage look like this:
imports = [
(import (nixpkgs+/nixos/modules/services/databases/mysql.nix)
{moduleName = mysql_on_tmp; })
]
services.mysql_on_tmp.enable = true;
services.mysql_on_tmp.port = 3307;
services.mysql_on_tmp.package = pkgs.mysql55;
services.mysql_on_tmp.dataDir = /tmp/mysql;
services.mysql_on_tmp.socketDir = /tmp/mysql_tmpfs.socket;
ids.uids.mysql_on_tmp = 2;
ids.gids.mysql_on_tmp = 2;
If there are existing beter solutions let me know and or comment to
either the pull request or this thread.
I guess the most interesting point is uid/gid handling.
Introducing a style will affect almost all services ..
lethalman proposes such style:
services.mysql.instances.name = ...
I agree that this style is nicer. Do you agree?
Should services.mysql be mapped to services.mysql.instances.default then?
Then backward compatibility could be preserved.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Multiple MySQL instances (or nginx/apache/...)
Excerpts from Ertugrul Söylemez's message of Sat Jan 03 14:05:05 + 2015: But don't hold your breath. It could take a week or two before I can present my first prototype. Maybe you can sketch your idea for the sake of discussion? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to get rid of systemd (was: Modifying the init system (introducing S6 supervision suite))
Let me comment:
- Is systemd a step backwards?
* upstart didn't even implement logging, did it?
* some more things I think systemd does better than upstart (eg socket
activation)
However I agree that journalctl is horribly slow.
- Must the module system or systemd go away? I don't think so.
why not add a new option
services.my_modular_thing = mysql postgres bitlbee ..;
But what is the goal?
domain_1 = foreign_domain www.example.com;
domain_2 = domain_managed_by_X www.foo.bar;
ssl_cert = yyy;
php_app = new wordpress_instance {
databases = [
{ type: mysql;
timeouts: foobar;
require_mysql_import_in_path = true
}
];
http = [
{ domains = [domain_1 domain_2]; port = 8080; }
{ domains = [domain_1 domain_2]; port = 443; inherit ssl_cert; }
];
}
container_1_amazon_eu = {
apps = [ php_app ];
}
container_2_load_balancer_with_instances {
apps = [];
}
realise [container_1_amazon_eu container_2_load_balancer_with_instances ];
But still, how to move the app from container_1_amazon_eu to
container_2_load_balancer_with_instances ?
Then due to TTL in DNS there is much more to take into account such as
HTTP proxies, mysql replication (if you want minimal down times) and
whatnot.
Thus a
php_app.move_to_container_with_minimal_downtime(container_2_load_balancer_with_instances)
can this be done with a configuration file at all?
what should move_to_container_with_minimal_downtime ideally do?
1) prepare the second container (create user account, database)
2) start mysql replacation (eg lock database in container 1, create
btrfs snapshot, read replacation state, unlock, copy btrfs backup to
container_2_load_balancer_with_instances, start replication, wait
till its in sync)
3) stop web app @ container_1_amazon_eu, setup http proxy to new IP,
4) garbage collect (thus delete all account/database stuff @
container_1_amazon_eu)
How can this be expressed using a simple text file ?
Some things just require global state IMHO ..
So what do we really want ?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Request for comments: pinky-promise determinism
I've talked to git (irc) long time ago, they are pretty sure that the git
hash would serve well as alternative to a sha256 or md5 hash.
Thus adding an implementation for
mkDerivation {
git_hash = ; # instead of fixed output hash
}
and have the nix implementation check for $out/.git and, git status
returning nothing and HEAD being the desired hash would be much easier
to use.
Most Vim plugins also are stored on github.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Haskell NG
- hackage-packages.nix is generated automatically by the hackage2nix
utility
from the v2.x branch of the cabal2nix repository [2]. The file defines
builds for the respective latest version of every Hackage package.
hackage2nix can include some older package versions, too, if necessary.
So does the spirit behind hack-nix win finally? Finally? :)
If we rewrite the stuff we should get it right this time.
I feel getting this right means
1) versioning hackage
2) implement a way to retrieve hackage packages (either by api or from
versioned hackage dump)
3) share package resolution with cabal (don't invent our own stuff -
because it will always be a lot of work and be totally different)
AFAIK Shea has added a way to load .dll functions. I think I remember it
is possible to call Haskell from C code. Thus what about collaborating
on the implementation sketched above?
It would serve as sample which could be adopted for the other
universes (perl/python/ruby/java/scala/rust/vim/emacs/whatever).
Thus how could usage look like?
haskellPackages {
hackage-dbs: [
http://some-mirror/version/2014-12-10-hackage-packages.tar.gz;)
my custom stuff
]
resolve: bytestring
}
Due to referencing a hackage like database by date it should be
deterministic.
Fetching all versions of a package could be done by API (HTTP) or such -
thus downloading hackage would no longer be necessary.
Thoughts?
This is the next thing I'd try trying to learn from hack-nix.
For all of you who don't know what hack-nix is: Its a brute for
dependency solver written in Nix reading a hackage database which was
serialized to a .nix file doing exactly what Peter wants to implement:
Latest versions + some manually added older versions to make packages
resolve. Additionally its easy to add your own packages (eg dev
versions) and call the solver as well as patch packages (eg .cabal
files, especially its dependency information) before turning it into a
huge .nix file.
You can find a short description https://nixos.org/wiki/Nixpkgs-haskell-overlay
It was meant to be a proof of concept. Now I'd like to ask you whether
you would prefer joining a common effort which is most likely to work.
Its too painful to role my own solutions for everything (haskell, ruby
overlay etc - even though it often works nicely - and fails due to lack
of man power).
Peter: Please comment on the proposal, I'd rather join than keeping my
own stuff, but your attempt just seems to be another hack-nix with all
of its problems.
Who would join implementing the design I've sketched above?
Live is too short IMHO. My point of view might be limited - thus if I
make any bad assumptions please tell me.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How can I write a library inside Nixpkgs? (for Bitcoin and friends...)
What about reading the nixpkgs (the sections describing what a derivation is) manual and or having a look at the nixpkgs repository which should contain more than enough examples ? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] vim-plugins
Leave your comments about this pull request, please: https://github.com/NixOS/nixpkgs/commit/f54f79e5a3632a510daceeb0ccd6fa1ebd8a9ce4#commitcomment-8806938 Now its possible to put all of your plugins into a ~/.vim-scripts [1] files and almost derive your nix configuration from it by doing some simple copy pasting, see vimUtils's documentation. Is a .nix file the appropriate place to put such documentation, or would you prefer another location such as wiki or nixpkgs manual? Marc Weber [1] See http://github.com/MarcWeber/vim-addon-manager 's README file ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Postgis issues
postgis was added by me many years ago, I guess nobody since then looked at it. That time it was neccessary to prepare a databse before you were able to use postgis - to simplify I added helper scripts like this: pg_db_postgis_enable Things might have changed a lot. Rebuilding OS works fine. Postgis appears to install (I can see postgis-1.5.so), but i'm missing `postgis.control` and presumably one extra step? Eventually add use such installPhase: installPhase = '' unset installPhase installPhase fail ''; and use the -K flag when building, then you can have a look at the build directory as well. = Neither the source nor the build nor the install directory contain any .control files 'CREATE EXTENSION postgis; ERROR: could not open extension control file /nix/store/[...]-postgresql-and-plugins-9.2.9/share/extension/postgis.control' Looking at http://postgis.net/source it looks like there are newer versions as well: postgis-2.1.4.tar.gz pdf html (Release Notes) postgis-2.0.6.tar.gz pdf html (Release Notes) postgis-1.5.8.tar.gz pdf html (Release Notes) Thus which ones do you care about? This file (replace the postgis file) makes 1_5_8 build providing the shell script, probably it still just works: http://mawercer.de/tmp/default.nix The newer versions I added as well don't build yet for this reason: gcc: error: ../liblwgeom/.libs/liblwgeom.a: No such file or directory there is a liblwgeom.la file, however replacing the .a version with the .la version in Makefile.in makes gcc not know the file. Does any C guru just know what's going wrong? . o O (Yes - I know that I should rewrite composobaleDerivation ...) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Introducing nox and nox-review
https://nixos.org/wiki/Howto_find_a_package_in_NixOS is the place to add a reference.. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] system wide .vimrc / managing plugins the nix way - proposal and implementation
Now that that it does make sense to think about moving your .vim config into nix space it also makes sense to package most commonly used plugins. Thus if you think a plugin is missing in vimPlugins send me a private mail and I'll try to include it using the vimp-pi = nix export when creating the pull request. If you're using VAM you can create a list of plugins in use by :echo keys(g:vim_addon_manager.activated_plugins) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] system wide .vimrc / managing plugins the nix way - proposal and implementation
4) And I thin[*k*] we have to rename `dependencies` to smth like `runtimeDependencies` and make them the same type as `buildInputs`, not the Well runtimeDependencies could be executable tools. That dependencies attr only lists vim plugin names. We could flag derivations to be a vim plugin and traverse the dependenciy tree (runtime/build dependencies), but that would be more work (cpu wise) probably. I notice that we can do the same for pathogen: install all dependencies, thus the interface changed slightly to pathogen.pluginNames = [...]; and vim.pluginDictionaries = [..]; and vim-addon-nix will also install all depnedencies. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] system wide .vimrc / managing plugins the nix way - proposal and implementation
Well - it might be desirable - but for other users vim should be the way
they know it - plain simple stupid. Thus forcing a customized vim
behavior on other people is could be a pain.
The first step for letting the users choose is
- create nix code creating .vimrc files
- create vim wrappers which use them, eventually having a different name
This patch implements this:
http://mawercer.de/tmp/vim-patch
More than that VAM (vim-addon-manager) got a autoload/nix.vim file which
can turn github based plugins (known by vim-pi) into nix derivations.
I'm not sure I should call myself of being a maintainer of anything
within nix, its just what I think will provide greatest value with least
effort. This change was driven by the discussion found here:
https://github.com/jagajaga/nixpkgs/commit/0b9432d5e22fc5453e0b4265ca36d5015cbcaf1c#commitcomment-8305911
The perfect fix (creating a huge package cross language/tool packagce
database) would be a lot more work, putting all vim plugins into nixpkgs
( 5.000 - a lot are no longer used) would be overkill. Thus this
attempt tries to follow the cabal2nix like approach making packaging
plugins people use easier while supporting enhancements such as
addon-info.json files introduced by VAM containing simple unversioned
dependency information.
The result looks like this illustrating how much the unversioned
dependency management of VAM can simplify your setup:
# test cases:
test_vim_with_vim_addon_nix_using_vam = vim_configurable.customize {
name = vim-with-vim-addon-nix-using-vam;
vimrcConfig.vam.plugins = [
{name = vim-addon-nix; }
];
};
test_vim_with_vim_addon_nix_using_pathogen = vim_configurable.customize {
name = vim-with-vim-addon-nix-using-pathogen;
vimrcConfig.pathogen.plugins = map (x: vimPlugins.${x}) [
# target package:
vim-addon-nix
# dependencies:
vim-addon-completion vim-addon-goto-thing-at-cursor
vim-addon-mw-utils vim-addon-actions vim-addon-errorformats tlib
];
};
The depeendency magic is provided by a dependencies = [name1 name2]
attr in vimPlugins.
Please note that all features provided by VAM's vam#Scripts() function
are supported such as loading plugins lazily triggered by you opening
some special particular filetype.
Because pathogen and VAM are supported (sorry no Vundle/ NeoBundel
support yet) this should please the majority. Pathogen has no advantage
over VAM AFAIK - I just added it for completness and because the
discussion mentioned above asked for it.
This mail is for gathering feedback, I'll create a pull request soon.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] PAGER=less -R
topgit has an issue with that:
https://github.com/greenrd/topgit/blob/master/tg.sh#L462
TG_PAGER gets defined some lines above ${FOO-xxx) means but word if FOO
isn't defined (thanks to Lethalman, I failed finding that in the man
page.
Is the best way to fix this by dropping quotes? Does anybody know how
PAGER ist most commonly used?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] PAGER=less -R
Fed upstream: https://github.com/greenrd/topgit/issues/36 Thanks for tv @ irc for helping. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] haskell: overriding mtl/any builtin
mtl choosing versions Which is the target package you want to use/work on? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Is xdebug working for you?
Is anybody using xdebug? The change making PECL build it broke it for me. This code http://dpaste.com/2HEZVNG still works fine. Maybe I have to configure it in a different way when it gets build by PECL? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Vim setup for Haskell
Excerpts from Thomas Strobel's message of Mon Aug 04 07:09:11 + 2014: The idea behind 'hvim' is to have a single package which installs vim with some stuff that is helpful for Haskell development, without having to understand how nixos or vimrc work. Learning Vim take so much time that unerstanding .vimrc is trivial, sry. For that reason that is your way, but not mine .. Especially it should allow to distribute adjusted or modified programs and plugins which work together nicely. I know about your vim-addon-manager project and your maintained collection of vim plugins for nix**. No, I don't maintain it. I just tried to get the basics right, so that people who would have added vim stuff anyway get it right. In fact I think there is one thing missing to have a perfect software distribution: Authors taking care themselves. VAM is in maintainance mode for two reasons: - there will be neovimm - I'll be creating this as soon as I have time: https://github.com/code-once/ypm The idea I want to explore is whether it is possible to create a huge database with recipes so that you can turn those cross language recipes into .nix derivation or *any distro package specification* automatcially. Eg updating kde/xorg/gnome is always a lot of work. That's why I want to fix this once and forall. Eg there are combinations Vim Ocaml YouCompleteMe which requires recompliing vim (with py support) and running ocamlopt to get a working setup. VAM will never be up to that task. Thus if you like idea behind YPM or want to sponsor it just star it or let me know :) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Vim setup for Haskell
I personally use nixpkgs-haskell-overlay and vim-addon-haskell which can run cabal. The nixpkgs-haskell-overlay implementation is prototype implementation (see wiki) and can tag haskell sources (using hasktags). You then source an env var which sets an environment var pointing to tag files. There are alternative solutions, too Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Better support for Ruby
Excerpts from Charles Strahan's message of Sat Jul 26 19:43:29 + 2014: Hi all, Well - depends on what you're looking for. nixpkgs-ruby-overlay has been in use by me for a long time and often does a resanobly good job https://nixos.org/wiki/nixpkgs-ruby-overlay There are some minor problems such as you having to download a dump of RubyForge (which I don't update regularly right now). It does not support lockfiles yet - but you could turn lockfiles into that such .nix code. The best thing would creating a mirror and fetching package descriptions on the fly via API on demand - but with defined revision so that results can be reproduced. I started this alternative approach after giving up on the generate .nix files for nixpkgs for both Haskell/ruby. I also tried this for Python, but that time I failed because dependency information on PyPi was weak or dynamic (determined by setup scripts) often. Thus the way to move forward would be creating a global package database which contained all information for everyone. (And also make C/C++ gnome and whatnot folks use it ..) That's my view - it could be incomplete. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Better support for Ruby
Excerpts from phreedom's message of Mon Jul 28 13:54:21 + 2014: There's nothing inherently wrong with the old nix gem if you treat it as a way No, that time it took runnig a gem command (the very first implmentation) made me look for an alternative. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cgroups, cpu.rt_runtime_us
While trying to run jack1d I noticed that I had to change some limits:
security.pam.loginLimits = [
# jackd:
{ domain = @audio; type = -; item = rtprio; value = 100; }
{ domain = @audio; type = -; item = memlock; value = 25; }
{ domain = @audio; type = -; item = nice; value = -10; }
];
as well as assign cpu.rt_runtime_us (otherwise sched_setscheduler
fails):
echo 90 /sys/fs/cgroups/cpu,cpuacct/user.slice/cpu.rt_runtime_us
Is there a systemd way to set cpu.rt_runtime_us value or is it most
simple to just create a startup script assigning it?
Eg nixos manual and
http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html
mention some specific settings such as MemoryLimit, but I didnt't find a
rt_runtime_us setting there.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Writing a Nix evaluator in Haskell
As such, I've started a project call hnix which will implement a parser and evaluator for Nix in Haskell. I have the parser working for simple expressions already (using either Parsec or Trifecta, it works with both). AFAIK Peter Simons has written a parser previously, too. Maybe search in the mailinglist archives to join efforts See here: Subject: Haskell Parser for (subset of) Nix http://article.gmane.org/gmane.linux.distributions.nixos/10538/match=nix+parser+haskell My first goal is a syntax verification vim-addon-nix has been using it for ages: nix-instantiate --parse-only foo.nix does a syntax-check You may want to use it till your alternative is ready. Comparing with an Haskell implementation would be fun for many reasons, using multiple cores for instance. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] cabal.mkDerivation and cabal flags
The problem with flags is that dependencies might change. No idea how cabal2nix handles this. Maybe you have to rerun it with flag info. The alternative is using hack-nix which creates the dependency information on the fly anyway - but the database might be a little bit outdated. Thus have a look at cabal2nix and hacknix. If you want to give the latter a try let me know. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gutenprint cups drivers
This chonfiguration works for me:
cupsd_1_7 = {
enable = true;
gutenprintPackage = pkgs.gutenprintCVS;
};
source:
https://github.com/MarcWeber/nixpkgs/tree/experimental/cups-1.6-and-1.7
nixos wiki should still contain some hints about how to use topgit
topic branches efficiently.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] apache module and ip:port configurations?
For fun I tried placing apache behind nginx.
making apache listen on non standard port made existing installations
such as wordpress return redirects. (Yes, could be fixed, ..)
I tried setting up a second loopback device so that I was able to use
port 80 twice (once for nginx proxy_passing requests to apache then
listening on an arbitrary local network address different from
127.0.0.1).
The problem I faced was that the apache module did not allow me
specifying it. The attached patch fixes this, but replaces
port = 80; by a more complicated listen = [{ ip = ...; port = 80;}]
interface.
One way would be making the listen option default to something based on
port if it was set by the user. which is the way to refer to the
config of that particular virtualHost because type = types.attrOf (..)
is used.
Is anybody else interested in such patch?
Marc Weber
apache-module-ip-port.patch
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] builtins.toPath returns ... a string?
--eval-only --strict -xml output:
of
{
s = /home;
p = /home;
to_p = builtins.toPath /home;
}
Same
|| ?xml version='1.0' encoding='utf-8'?
|| expr
|| attrs
|| attr column=3 line=3 name=p path=/tmp/test.nix
|| path value=/home /
|| /attr
|| attr column=3 line=2 name=s path=/tmp/test.nix
|| string value=/home /
|| /attr
|| attr column=3 line=4 name=to_p path=/tmp/test.nix
|| string value=/home /
|| /attr
|| /attrs
|| /expr
primops.cc
/* Convert the argument to a path. !!! obsolete? */
static void prim_toPath(EvalState state, const Pos pos, Value * * args,
Value v)
{
PathSet context;
Path path = state.coerceToPath(pos, *args[0], context);
mkString(v, canonPath(path), context);
}
You may want to talk about your use case.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Restructuring of the Wiki
I'd say the summary of discussions like this belongs on a wiki :) I'd keep as is unless there are strong reasons to switch. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] reading nix profile derivation priorities from manifest.nix
Excerpts from Rommel Martinez's message of Sat May 03 09:46:00 + 2014:
Let's presume that I have run the command 'nix-env --set-flag priority ...'
many times and I have lost track of what they were, how can I reset
them to the default state?
Following profile links to store, cp -L (dereferencing) them to /tmp and
running diff -r shows:
diff -r 11/manifest.nix 22/manifest.nix
1c1
[ { meta = { }; name = nvi-1.79; out = { outPath =
/nix/store/lcb2rbrhb183lbsxhk512d297ymv85j0-nvi-1.79; }; outPath =
/nix/store/lcb2rbrhb183lbsxhk512d297ymv85j0-nvi-1.79; outputs = [ out ];
type = derivation; } ]
\ No newline at end of file
---
[ { meta = { priority = 20; }; name = nvi-1.79; out = { outPath =
/nix/store/lcb2rbrhb183lbsxhk512d297ymv85j0-nvi-1.79; }; outPath =
/nix/store/lcb2rbrhb183lbsxhk512d297ymv85j0-nvi-1.79; outputs = [ out ];
system = unknown; type = derivation; } ]
\ No newline at end of file
Thus read ~/.nix-profile/manifest.nix
How to change/reset? Does'nt look like nix-env provides a command (I
might have missed it again).
From buildenv.nix (nix distribution): (d.meta.priority or 5)
thus default priority is 5.
Now from nix-env:
--meta
Print all of the meta-attributes of the derivation. This option is
only available with --xml.
Thus I'd suggest:
nix-env -q --xml --meta
and there it is:
?xml version='1.0' encoding='utf-8'?
items
item attrPath=0 name=nvi-1.79 system=unknown
meta name=priority type=string value=20 /
/item
/items
If you want to change something you at least have some pointers where/how to
get started.
I've changed the subject hoping that its easier for google to find this
post in the future.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to actually get rid of things from the nix-env -qs list?
Excerpts from Mateusz Kowalczyk's message of Mon Apr 28 10:39:11 + 2014: On 04/28/2014 09:23 AM, Marc Weber wrote: Is there a way to ask nix to tell me which one is active? There is no active:yes/no Example: p-1.0: /bin/foo p-2.0: /bin/foo-2.0 Then you'll have both in PATH In yoru case I expect: python-package-1.0: lib/python-2.7/site-packages/foo.py python-package-2.0: lib/python-2.7/site-packages/foo.py Thus if you link both the one which will be linked first should win. How to find out? follow the symlinks found in path ~/.nix-profiles/lib-python-2.7/site-packages-foo.py to find out which one got linked. But I agree, it might be helpful if there was not only a --set-flag prio but also a --list-prios flag or such for nix-env, did I miss such? No idea where those priorities get stored when set manually. How to solve your problem? Don't use nix-env -i every single package, instead you can use misc.collection = https://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once This illustrates one declarative approach to managing your custom environment. It might make sense to have multiple collections such as pythonPackages mailStuff etc. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] RFC: NixOS version string format
We're using git, thus the only really meaningfull thing is the hash .. But its hard to compare which is more or less up to date. Thus maybe its worth thiking about adding the hash if it is not included. The hash also identifies the history. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] User's configuration files
Excerpts from Arseniy Seroka's message of Sat Apr 26 18:54:38 + 2014: Is it a good idea to create some option for a config file for a special user? I mean, for example, `users.extraUsers.userName.vimrc`. Or it's out of nixos idea? If it works for you why not. About plugins: vim-pi is the project you might want to get a list of packages definitions from to create nix derivations eventually - however I won't spend much time on it due to neovim becoming more popular soon eventually. There are two ways: 1) install .vimrc to /var/run/current-system/sw/vimrc/user.vim and source it in users .vimrc, then it'll be updated, and you can still have machine specific .vimrc lines (Thus install the .vimrc system wide, and make sure it gets installed to a user specific directory so that it doesn't collide with other user's vimrc (unlikely, cause you're managing your own machine) ) 2) override .vimrc .. which is a less nice eventually. It all depends on what you do Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] My blog post on overrides in Nix
Such content should be on the official wiki - then it can be updated (IMHO). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] npm2nix maintainership
Excerpts from Shea Levy's message of Thu Apr 17 02:16:24 + 2014: I wrote npm2nix, but I'm no longer doing any work with node stuff and would prefer to hand it off to someone who is using it and motivated to keep it up-to-date and working. Is there anyone who might want to take ownership of the project? If you don't find anybody document current state on the wiki. Then it'll be found easily again by people who want to use it. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] npm2nix maintainership
Excerpts from Rob Vermaas's message of Thu Apr 17 14:14:22 + 2014: Oh wait, it's a mercurial repo, that won't work :) Why not turn it into git? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix language: converting an attribute set to a list
attrValues (mapAttrs (name: vals: merge or check that name is same as name key) ) attrs Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hash Collisions
Excerpts from Raahul Kumar's message of Tue Apr 08 03:11:03 + 2014: Thanks Marc, Kiril. Is there a way to create packages such that they don't provide redundant files? It's a waste of bandwidth to download a file, then be unable to use it because there is already a copy there. I guess deduplication is what I am looking for. I'll give you another useful tip: If you want to save bandwidth then switch to binary distro. While nixos has had the ability to create binary differences I'm unsure wether its activated/available at the moment. It was disabled in the past. Maybe somebody else can comment on this. Also waste of space/bandwidth always happens because: - nixos always ships with header files for all libraries (this could be fixed because nix supports multiple outputs) - if you replace coreutils you'll have to download everything, not just coreutils To sum up: You're talking about having some man files twice (which should not take much space if they are compressed). Thus I don't think the effort/value ratio is great if you start fixing things at that level :( - We still use nixos because we think the values nixos provides (atomic updates, deterministic distributed builds) are more important to us. Anyway: Welcome to nixos :) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gnome 3 suport
Hi Roelof, I have a deja vue, Is it true that you asked this in 2011? We have gnome expressions in nixpkgs, because gnome libraries are used by some applications which compile and work (eg network manager or such). I'm unsure about whether gnome desktop is supported now. I think its still not (please correct me if I'm wrong). Thus try to clarify whether you're talking about gnome libraries or the gnome desktop. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] versionedDeravation / php fpm / cups 1.7
Excerpts from Domen Kožar's message of Mon Apr 07 17:31:58 + 2014: As soon as we allow more than one design pattern for sharing code between packages, package in my use cases means having same name and having most build instructions be the same. We do already have sharing for different systems, eg src = if system = X then fetchurl else fetchurl .. Eg eclipse case. I'm OK with versionedDerivation, if we come to consensus it's better than current approach and someone ports current codebase to use versionedDerivation. That's not what I'm asking for: (rewriting code). The main request is: Is it worth thinking that much about such small things if such patches fix real world problems people might suffer from. I want to achieve the goals with reasonably low effort - thus do what works fastest. If we can imagine that this happens on this own - there is no reason to fear that there is a maintenance burden - because if there is one it'll be refactored (because contributors want to be done fast, too) TL;DR: having more than one way to share code between packages Thus you'd vote for mkDerivation and setup.sh being the only sensible ways to share code ? :) Just trying to illustrate that its hard to define what one labels as shared code. burden to maintenance We should talk about specific cases, not about general things which are hard to grasp. Please keep in mind that you cannot prevent programmers from shooting themselves into their feet - no matter what you do. The question I'm asking is: Am I doing this is the cases I provided and for what reason - and which kind of gun am I using (soft balls or missiles). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Accidental force push to nixpkgs
solutions: 1) push to another repository which allows seting up hooks, then sync to github/nixos 2) don't preven this when pushing, prevent when pulling by: git merge --ff-only or .git/config: merge.ff [..] When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line). Using Google did not reveal more options to me. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maven support in nix
Excerpts from shacka's message of Sun Apr 06 20:51:22 + 2014: is it possible to build maven project as nix package? Not at all. Maven has its own dependency management, and nobody has worked on porting this to nix (AFAIK). Existing solutions (non Java): - cabal2nix (cabal descriptions to nix) - py2nix (or such) same for python - ruby2nix (or such ) same for ruby -hacknix/nixpkgs-ruby-overlay (they convert hackage/rubyforge to a pool which gets translated to .nix files, derivations get created by functions on the fly) some time age there was announced some work /question about bundler support (ruby) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Repo for incomplete/unmaintained work
We've had some discussion, my proposal was: Add a marker such as unmaintained-since: ... then remove after 6 month or so. Due to the since you know exactly what to remove. The hard thing is to define what it means to be maintained or unmaintained. Thus you could also introduce markers such as maintainance-levels = [ gets-updated-within-a-week-if-new-version-appears somebody is reviewing code ..]; Not sure whether it would make sense. Whether such code gets moved to another repository or not - which is the benefit/ difference from having a simple wiki page unmaintained packages for nixos/ can be found in nixpkgs git history? Then at least google finds it .. No idea. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] versionedDeravation / php fpm / cups 1.7
==
In https://github.com/NixOS/nixpkgs/issues/1957 Eelco Dolstra described
what he dislikes:
== QUOTE
My main objection to versionedDerivation is the wackiness of
having package functions that take the version as an argument,
i.e.
{ stdenv, fetchurl, version ? 5.3 }:
versionedDerivation cups version { ... }
There is nothing about the function interface that tells you what
the valid values of version are, and thus what versions are
supported. What you should do is return an attribute set
containing the supported versions:
{ stdenv, fetchurl }:
{
php_5_3 = ...;
php_5_4 = ...;
}
Of course, you can factor out the commonality between versions any way
you want, e.g.
let
makePHP = common: stdenv.mkDerivation ({ ... } // common);
in {
php_5_3 = makePHP {
name = php-5.3.50;
src = fetchurl { ... };
}
...
}
Alternatively, you can have separate files for each expression
that include a file common.nix for the common stuff (like we do
for the Linux kernel).
== QUOTE END
I agree that it does make sense to docmuent which versions are
supported.
The easy answer is:
The default version is documented in the argument list, the others
just mean can be build - or there has been a time where it did build
unless they get referenced somewhere (most likely in all-packages.nix,
see php5_3fpm example above. Whether this should be documented this way
is another story.
= I've created a new page:
https://nixos.org/w/index.php?title=Open_issues:maintenance_properties_of_a_packageaction=submit
Documenting wich packages are how well supported is an open issue
IMHO. This just is yet another way.
The pattern Eelco Dolstra is discussing is used in different context
and with some varation, eg in python-packages.nix:
python-packages.nix takes as arguments:
{ pkgs, python, lowPrio }:
Thus while its not taking a version, you still have no idea which
python you may pass (or python versions ..) - thus IMHO its not that
much differing :)
A similar argument could be applied to systems. (eg darwin vs
x86_64 i686):
php.5.3.darwin to indicate its fine to be used on darwin.
From this point of view there is not that much wrong by
versionedDerivation, the only change neccessary would be making it
return all versions as attrs so that such usage would be valid:
phps =import php/default.nix;
php_5_3 = import php/default.nix { }.5.3.x;
php_5_4 = import php/default.nix { }.5.4.x;
Thus does it differ that much from [Example 3] above which looks like
this:
php5_3fpm = php5_3.override { sapi = fpm; version = 5.3.x; };
How would the perfect PHP nixpkgs implementation look like?
let commonConfigureFlagDescription = [ long list .. ];
let phpDerivation = { commonConfigureFlagDescription, version,
src_md5_hash, patches ? [], allowFastCGI }: {
// the common code merging the options
}
mergexdebuglikestuff = php: php // {
xdebug = ..
acp = ..
... = ..;
}
phps = {
php5_2 = mergexdebuglikestuff (phpDerivation {
long list of options
});
php5_3 = mergexdebuglikestuff (phpDerivation {
});
php5_4 = mergexdebuglikestuff (phpDerivation {
});
php5_5 = mergexdebuglikestuff (phpDerivation {
});
}
In the end is it that much more readable than what I already have?
Link - [Example 3] PHP above
I totally agree that I should refactor if newer versions happen to be
totally different - it just didn't happen that way (yet) could be
cause I've been lucky though.
Can you reply if you have new arguments about why versionedDeravation
is nice/bad so that we get a comprehensive list and that I understand
which is the best way to rewrite those patches ?
Also ping me if you're interested in testing either patch.
Thanks for helping me gain awarness .. :)
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hash Collisions
Excerpts from Thomas Bereknyei's message of Mon Apr 07 13:48:45 + 2014: I have seen these collisions as well, but I do not understand them. They don't seem to have a detrimental effect on anything. Let me explain: nixos builds a system profile. Eg ls -l /run/current-system/sw When two packages which get linked to that directory provide the same file (see your log) - then collisions happen. Now its up to you to review / change order to make the difference which man page will be opened for instance. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Language integration (Was: NiJS package manager)
Excerpts from Matthew Sackman's message of Wed Apr 02 11:18:32 + 2014: But I'm not sure we're disagreeing, or actually talking about the same thing. So if I've misunderstood, please do say! But in the end in which way does nix differ from rpms or homebrew etc? Nix allows having multiple versions of the same package, except that there is not a big difference.. That's why once you can generate nix derivations it should be possible to build rpms eventually. Of course for the nix store programs are more likely to work due to the every tool knowns about its own dependencies strategy. So of course we basically do agree. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html I have discovered that the Nix expression language is complicated and difficult to learn. Like Haskell, it has a solid theoretical foundation and powerful features (such as laziness), but it's too hard to learn by developers without an academic background. What is this based on? Which is the async problem you were faced by using Nix? Thus which problem are you going to solve ? I personally have use cases in mind such as querying a server knowing about all ruby/python/haskell/perl/your-language-X packages - so that we don't need to distribute 50.000 package descriptions (rubyforge case) or similar. But anyway: We have 3 solutions for describing packages: nix, guix, nixjs Thus eventually its time to think about which information could be shared. Who would join a software version documentation project allowing people to upload the most recent version of my software is X, and it requires Z, FOO, BAR ? Then some nix, nijs, guix packages could be derived automatically (like haskell, ruby, xorg, .. packages). And all the other package systems such as debian could benefit eventually, too. Thoughts? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
