Re: [Nix-dev] bash-interactive with support for completion
Excerpts from Peter Simons's message of Mon Sep 12 19:49:49 +0200 2011:
The normal bash (a.k.a. stdenv) is not affected. I would like to commit the
patch, but before I do I wonder whether anyone sees a problem with it?
I'm too lazy to look up all details.
Summary:
- some people dislike the completion. Therefore there should be opt-in
- my nix2/multi-shell-support branch supports bash and zsh completion
for several month now incloding opt-out implementation.
Because I already have a more sophisticated solution I'm likely to revert your
patch in my branches.
It was announced here:
http://article.gmane.org/gmane.linux.distributions.nixos/5666/match=bash+completion
There was no feedback that time.
Marc Weber
# /etc/bash-setup-completion.sh:
# can be sourced by user to setup (unoptrusive) completion for bash
# 1) never source a completion script twice so that later profiles don't change
#behaviour of earlier (more important ones)
# 2) allow users to opt-out from individual annoying completion scripts by
#defining key
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
nix_add_profile_completion(){
# 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
for s in $1/etc/bash_completion.d/*; do
local base=${s/*\//}
[[ ${s##*/} != @(*~|*.bak|*.swp|\#*\#|*.dpkg*|.rpm*) ]]
[ \( -f $s -o -h $s \) -a -r $s ]
[ -z ${NIX_COMPL_SCRIPT_SOURCED[$base]} ]
{ . $s; NIX_COMPL_SCRIPT_SOURCED[$base]=1; }
done
}
for p in $NIX_PROFILES; do
nix_add_profile_completion $p
done
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Disaster recovery / re-deployment
Hi Rickard Nilsson, I'v git repos which provide a minimal bootstrap archive containing enough to run nixos-rebuild only. Of course you must have nixos and nixpkgs an configuration.nix in place. It tries to modularize nixos-install from cd: you have a run-in-chroot command, you have one checking out sources and a minimal store. Ironically I would have needed such very urgently. Contact me on irc and I'll give you access to code and a system which can build those minimal archives for you (i686 only right now). I'm interested in helping getting this done. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: announce: preliminary version of nixpkgs-python-overlay
I'm busy for at least 3 days. Sorry. We can then talk about it. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Blacklisting snd_pcsp by default
Excerpts from Eelco Dolstra's message of Tue Aug 23 09:48:04 +0200 2011: The snd_pcsp module is known to cause issues with the default ALSA audio device, and as far as I know is not really that useful on modern machines. Would anyone mind if snd_pcsp was blacklisted when ALSA is enabled? Consider doing it always. Then nixos-rebuild test does work as well. You'll find many howtos in the internet telling how to physically remove speakers because ensuring that your pc does not beep is much more work (or has been in the past). You can wait two days to see if anybody objects proofing me wrong. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] WIKI question misc.collection, multiple ghc in PATH, bit of problem,
Hi Peter Simon,
If you have $out_1/bin/ghc and $out_2/bin/ghc of course there will be a
problem (which is not that huge cause all ghcs have symlinks to
ghc-version anyway).
So in which way is going to talk about a potential problem going to help
anybody? I see the following solutions: Which one do you like most?
Then we can document it and drop the potential issue.
solutions 1:
Replace it by a request on nixpkgs:
What about providing run-haskell-$VERSION symlinks the way its done for
ghc and ghci?
solution 2:
Manage multiple environments (and this is unrelated to misc.collection)
or its intended usage:
nix-env -p ~/ghc-7-profile -iA yourGHC7Collection
nix-env -p ~/ghc-6-profile -iA yourGHC6Collection
Then add either ~/ghc-6-profile/bin to PATH or use my bash zshrc patch for
nixos
introducing a useful function:
nix_add_profile_vars ~/ghc-7-profile --suffix or --prefix
which should get the job done. It may be overkill in this simple case
because ghc only reads PATH, no PYTHONPATH or such.
solution 3:
install this instead: ( ghc6Collection being misc.collection)
myLodableEnv = runCommand loadable-env-ghc {} mkdir -p $out/envs; ln -s
${ghc6Collection} $out/envs/ghc6;
then use this (bashrc)
loadEnv(){ PATH=~/.nix-profile/envs/$1/bin:$PATH; }
and in shell:
loadEnv ghc6
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: WIKI question misc.collection, multiple ghc in PATH, bit of problem,
Excerpts from Peter Simons's message of Tue Aug 23 15:35:48 +0200 2011: yes, but that is not issue I'm concerned about. The problem I see is that this collision will not be detected. There are two possible collisions: 1) misc.collection and any other package you've installed 2) packages within one misc.collection. Neither is detected cause the additional packages to be installed are considered lasts by env builder. nixpkgs contains top level attr buildEnv which could be used instead. This would fix 1) and 2). However in the case having different ghc's you should eventually create one collection (based on buildEnv) for each version. Then nix-env -iA should report collisions and let you choose (untested). Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: WIKI question misc.collection, multiple ghc in PATH, bit of problem,
Excerpts from Peter Simons's message of Tue Aug 23 17:39:36 +0200 2011: yes, indeed, it appears that buildEnv is superior to misc.collection in that regard. Maybe that function should generally be preferred? Why does the Wiki page recommend collection? Because the wiki page was meant to talk about the idea creating collections. The implementation is a minor detail which happened to work for me all the time. So if you want to fix it change the implementation and commit. I'll be fine with that. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: WIKI question misc.collection, multiple ghc in PATH, bit of problem,
Excerpts from Peter Simons's message of Tue Aug 23 19:29:54 +0200 2011: The title promises to explain How to keep multiple packages up to date at once. The mechanism of choice for that task is a nix-env profile, which can be updated with nix-env -u \*. All right. We can discuss making it perfect. By keeping up to date I mean keeping package up to date - and keeping yourself up to date about removal of packages. If you have Vim in your env and if Vim was dropped nix-env -i \* would not tell you. using a collection still tries evaluating attr vim and fails. That's why I don't consider the -u being an alternative. Also using collections enforce consistent snapshots: You always update ghc and packages. You never update ghc-haskell-posix-regex only causing ghc and library mismatches. Thus you eliminate potential problems. The second thing is that I wrote the wiki so that I can tell people try this way to do it once only. I haven't thought about adding all possibilities. That's why the page exist. I totally agree that it may not be perfect. However it fails early. Thus I can always reinstall a collection and know that all packages still exist and can be evaluated. No other nix-env command provides this information. Its that important to me that I use 5 collections and no single packages at all (only temporarily). So do you suggest changing the scope of the article to various ways by example to update packages and their pros and cons? 1) nix-env -u\* (drawbacks see above) 2) use collections (..) So maybe its my inability to find a proper heading. My it should be changed to how to atomically update many derivations which should be updated at the same time (eg whose versions should match, such as python and its libs or haskell and its libs or gimp and its plugins ...) But that would have been little too long. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: WIKI question misc.collection, multiple ghc in PATH, bit of problem,
Excerpts from Peter Simons's message of Tue Aug 23 20:26:59 +0200 2011: their contents; nix-env -q \* doesn't show all individual packages. I've made some additional changes highlighting the pitfalls. I hope its much better than it was yesterday now. I like it. Hope you still do so as well. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What about introducing security.packages?
Another solution would be having a black/white list. If a package should
be added to DBUS but is contained in neither list tell the user to do
so. This way users have a choice but won't miss to make the decision.
Eg:
systemPackages = [ pkgProvidingDbusConfig pkg2ProvidingDbusConfig
pkg3ProvidingDbusConfig ];
dbus.whitelist= [pkgProvidingDbusConfig];
dbus.blacklist= [pkg2ProvidingDbusConfig];
Now nixos-rebuild will fail because pkg3ProvidingDbusConfig is not
contained in either list.
This is yet another take on it which would satisfy security to some
extend and make things work because users won't forget to whitelist some
packages. Thinking about it I'd prefer this one. Eg we could add
additional info then:
meta / passthru = {
providesDbusConfig = {
why = Without this XY won't work - however security risk might be
...;
}
}
Is complexity a bigger issue than the value this solution provides?
Don't know. It would minimize questions and debugging. That's why its
my favorite. The only downside is that users have to make a choice which
also is a feature.
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What about introducing security.packages?
you:
My system-path derivation lists more than 600 paths... I like this way
of managing package installation; your proposal would make it somewhat
harder...
Me:
[..] Eg we could add
additional info then:
meta / passthru = {
providesDbusConfig = {
why = Without this XY won't work - however security risk might be
...;
}
}
So replace this could with should/must for exactly that reason. Only
packages which have the providesDbusConfig like attr have to added to
those black/white lists. And then hopefully there will be about 20 left
or such (I haven't counted them)
600 times adding a package? No thanks :)
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] What about introducing security.packages?
Excerpts from Yury G. Kudryashov's message of Sat Aug 20 16:18:27 +0200 2011: We have quite a few *.packages variables in NixOS: udev.packages, hal.packages, dbus.packages etc. I see only one reason for separating these packages from system.packages: system.packages? Am I outdated or are you talking about environment.systemPackages? programs/config files/... supplied by these packages are likely to be executed/readed by a daemon running under root priveledges. I propose to merge these variables into one variable (say, security.packages). If nobody objects, I'll start working on this. What exactly are you trying to do? Eg in the dbus case I had the understanding that services.dbus.packages is a list of packages providing dbus services. Because the relation between services and packages providing service configurations is n:m I don't see that your solution is going to improve anything? I mean if a package provides two services having security.packages will not allow you to use one only (Not sure if you need this feature at all). Also I'd like to change the way /var/setuid-wrappers list is generated. I propose the following way: packages in nixpkgs advertise that they need given binary to be wrapped as setuid. For each package in security.packages, we create all wrappers requested by these packages. Which will change opt-in to opt-in automatically if condition where condition means something like package has been added to environment.systemPackages ? I'm not objecting here. Just trying to understand the difference. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: What about introducing security.packages?
Hi Yury,
What exactly are you trying to do?
My goal is to avoid the situation when someone adds a package to
dbus.packages but not to udev.packages.
Probably you're right that in most cases the defaults shipping with
packages get the job done (much more likely than omitting those rules).
first)
What about
pkg = mkDerivation {
meta.provides = { # using attrs if there is ever need for some
# configuration you can add it easily. Also
# patching attrs is easier than adding/dropping
# items from lists?
udevrules = true;
dbussetup = true;
}
}
Then overwriting those setting is even easier.
Then we could introduce udev.packagesAutoAdd = true which picks
packages from environment.systemPackages automatically based on the
provides attr setting and it would be opt-in which some people will
prefer.
second):
You've seen that Eelco Dolstra is about implementing multiple
outputs? So in the future packages may have:
way:
pkg.udevRules pkg.dubsSetup pkg.includes pkg.lib (or whatsoever, time
will tell)
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
Excerpts from Lluís Batlle i Rossell's message of Wed Aug 17 10:45:39 +0200 2011: I'd like a list of the problems this would solve. Eventually build of python-2.7 on linux-3.0 and the like which use uname to determine kernel version, and they don't know about linux-3 yet. The alternative would be starting a VM for building. Then you could set the kernel to build packages in configuration.nix. However if kernel API is always backward compatible then this might be overkill. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
Why they want the kernel version?
Don't ask me. I have't had time to debug it. All I found out was that it
python configured itself to use different modules and some fail.
for older xulunner which got removed there were similar problems.
It looked to me like they are configuring based on target (linux vs darwin ...)
and they all expected linux-2.X with increasing X forever without a major
version bump.
Patches for postfix (newer version than current nixpkgs), obsolete xulrunner
and valgrind failed:
POSTFIX failed [1]
xulrunner failed [2]
valgrind failed [3]
[1]
pkgs/servers/mail/postfix/default.nix
index 773f113..f779964 100644
@@ -56,7 +56,11 @@ stdenv.mkDerivation {
buildInputs = [db4 openssl cyrus_sasl perl];
- patches = [./postfix-2.2.9-db.patch ./postfix-2.2.9-lib.patch];
+ patches = [
+./postfix-2.2.9-db.patch
+./postfix-2.2.9-lib.patch
+./postfix-linux-3.0.patch
+ ];
inherit glibc;
}
-- pkgs/servers/mail/postfix/postfix-linux-3.0.patch --
new file mode 100644
index 000..bee1c4c
@@ -0,0 +1,14 @@
+diff --git a/makedefs b/makedefs
+index 4faa430..965ceb3 100644
+--- a/makedefs
b/makedefs
+@@ -108,6 +108,9 @@ case $# in
+ *) echo usage: $0 [system release] 12; exit 1;;
+ esac
+
++# don't think that linux 3.0 introduced important changes
++ if [ $SYSTEM == Linux ] [ ${RELEASE##3*} == ]; then RELEASE=2;
fi
++
+ case $SYSTEM.$RELEASE in
+SCO_SV.3.2)SYSTYPE=SCO5
+ # Use the native compiler by default
[2]
pkgs/applications/networking/browsers/firefox/3.6.nix
index 2d472ce..a4e82a4 100644
@@ -45,6 +45,13 @@ rec {
inherit src;
+# make it compile on linux-3.0. Is there more that has to be changed ?
+postUnpack = ''
+ ( cd mozilla-*
+[ -f security/coreconf/Linux3.0.mk ] || cp
security/coreconf/Linux2.6.mk security/coreconf/Linux3.0.mk
+ )
+'';
+
patches = [
# Loongson2f related patches:
./xulrunner-chromium-mips.patch
pkgs/applications/networking/browsers/firefox/4.0.nix
index 6d988fb..4452595 100644
@@ -54,6 +54,14 @@ rec {
inherit src;
+# make it compile on linux-3.0. Is there more that has to be changed ?
+postUnpack = ''
+ ( cd mozilla-*
+[ -f security/coreconf/Linux3.0.mk ] || cp
security/coreconf/Linux2.6.mk security/coreconf/Linux3.0.mk
+ )
+'';
+
+
buildInputs =
[ pkgconfig gtk perl zip libIDL libjpeg libpng zlib cairo bzip2
python dbus dbus_glib pango freetype fontconfig xlibs.libXi
[3]
+ # linux 3.0 hack
+ preConfigure = ''sed -i '/as_fn_error Valgrind works on kernels 2.4,
2.6/d' configure'';
+
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patching uname in stdenv?
Excerpts from Lluís Batlle i Rossell's message of Wed Aug 17 10:45:39 +0200 2011: I'd like a list of the problems this would solve. And we should add a list of worms this may introduce. Kernel should be compatible. But software development is never perfect (although it comes close). Many packages encode linux version in info boxes or such. And they might be wrong. I agree that I don't expect too many problems. But there might be some cases where having the wrong value in an info box could slow down solving issues. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: bncf and BNCF
Dear Peter, you can avoid this in the future by setting: [svn] rmdir = yes in your ~/.gitconfig or .git/config project specific config file. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Toward a Purer stdenv
Excerpts from Shea Levy's message of Wed Aug 17 21:37:32 +0200 2011: I've been thinking about creating a nixpkgs branch to find and eliminate some of the remaining impurities in the Linux stdenv. linux stdenv ? What are you referring to exactly? Impurities: - cosmic ray (they may change bits), so build results do not only depend on your computer, but also where it is located - amount of RAM - filesystem being used (btrfs caused different behaviour in previous older kernels) - kernel (you talked about it) * version * settings (over commit or such) * .. - hardware: * disk (if you think about database apps they might choose to use on ore the other implementation depending on how fast your harddisk is don't think this happens in practise) * CPU (features ?, eg is MMX available or not) * graphic card * .. you can think about more issues such as USB being plugged in (does not make sense, but you could write such a prog which behaves differently if some kind of printer is plugged in) - time / timings * clock time * speed of CPU * ... - number of multiple cores when using parallel builds (eg kernel derivation) - running virtualized or not. Eg if you're running in a virtualized env you can't run qemu tests (eg nixos installer) because you can't nest vitrualized systems due to hardware restrictions (correct?).. - /dev/random (thus your keyboard input) This includes builds using rand() function etc. The fix is to fix builds if this happens. Older ghc versions may have had this issues according to a commit log. - network access - of course the user name building a package - the store location (for completeness) The impurity having had greatest impact on me is kernel version when trying 3.0. In fact newest kernel made btrfs worse so my fix was downgrade to 2.6.38.8. You don't know when the next big kernel numbering scheme is going to happen so its hard to say big the impact on us is at all. I'm pretty sure that I've still missed some impurities. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Toward a Purer stdenv
Excerpts from Yury G. Kudryashov's message of Wed Aug 17 22:21:21 +0200 2011: - the store location (for completeness) This is OK since changing store path changes all hashes. But For one package I had to change a generated file resulting in a crash because I didn't change the length field accordingly. It was kind of 3 abc where 3 is string length and abc is string contents. Not everything which can go wrong is equally likely to go wrong. I agree that tmp dir, building user name etc are unlikely to cause trouble. Same about impact by graphic cards (unless you build scientific packages using graphic card for calculation) Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: overview about hack-nix and how it works
I am not quite sure what idea you're referring to, I was referring to the perfect tool which minimizes packaging time. I feel that a complete solution must do dependency analysis in some way because everything else will work for most packages being mainstream only. By mainstream I mean authors updating packages so that they work with latest gtk etc. That both leksah and -server can be build with all ghc's in haskell-packages illustrate that Haskell maintainers do a very good job. - you think its broken by design? No, I don't think that. I cannot judge whether hack-nix is good or not. All I can judge whether it does what I need or not. Those two things are different. Which in turn makes me think that its fun to you copy pasting cabal2nix output into haskell-packages then start try-and-error compiling. That's my perception. If that's the case (let's call it playing the way you did) - then we indeed have different goals. When I started hack-nix the new split-base was introduced. Thus many packages did only build with one or the other version. I feared that package management would keep being that complicated. me: If you have time to rewrite it.. go on and do it. you: Actually, that effort is well underway. me: How will the design look [..]? no reply underway triggered the feeling being incomplete. cabal2nix has been in use and it seems like it does its current job very well (cause you've updated lot's of packages). That's why I'm wondering whether your needs are limited to what cabal2nix does now. Of course I knew how to get cabal2nix. I'm reading the commit messages to the mailinglist. Thus I didn't miss the fetchgit call. I didn't have a look at it because I had the impression that all it is doing is taking cabal files turning them into nix expression - letting you do all the hard work of testing and patching afterwards if required. Looking at its code makes my impression even stronger. So do you think cabal2nix is feature complete? I mean will it always turn cabal files into nix expressions only or do you want to extend it to be more - maybe turning it into something like cabal is? cabal2nix in its current shape does not compete with hack-nix. So by me asking do you want to rewrite and you replying is underway I assumed that you're going to tackle something of similar complexity which probably was a wrong assumption (because our goals differ). And in that case I would have asked you again to give hack-nix a try which would take about 5min: download any cabal project, run hack-nix --build-env. source env. compile. done. Anyway - whenever your mind changes - you're welcome. Just ping me. Thanks for having taken the time for replying again. It has clarified a lot. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r28415 - nixpkgs/trunk/pkgs/applications/virtualization/virtualbox/guest-additions
Excerpts from Marco Maggesi's message of Wed Aug 10 14:30:30 +0200 2011: I'm still trying to understand better what's going on with virtualbox guest additions. I also found this in /var/log/messages This is easy to understand: the job does not start. Thus upstart restarts it. You'll find more info in /var/log/upstart/virtualbox* You can try having a look at /etc/init/virtualbox* files and start the job in a shell manually. Eventually there are some no daemon, no background command line options. Some services can be made print debugging info, ... Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] overview about hack-nix and how it works
Excerpts from Juan Daugherty's message of Mon Aug 08 18:44:56 +0200 2011: Now loading metadata ... packageInfo not found for file-embed-0.0.4.1 packageInfo not found for hjsmin-0.0.14 packageInfo not found for entropy-0.1 [.. snip] Pasting a couple of failures should be enough. LEKSAH ISSUE 1) It's a well known issue nobody cared enough to fix yet. Try this: nix-build -iA haskellPackages.ghc.ghc -f /etc/nixos/nixpkgs/default.nix # unwrapped ghc result/bin/ghc-pkg list nix-build -iA haskellPackages.ghc -f /etc/nixos/nixpkgs/default.nix # wrapped ghc result/bin/ghc-pkg list The first one will show core packages. The last one will show additional (no core) packages only. Try putting the .ghc.ghc version of ghc in PATH, rm -fr ~/.leksah-0.10/ and suddenly the core packages will appear (they did here). That's no fix. Its only a hint what might be wrong LEKSAH ISSUE 2) leksah depends on cabal to build packages and looks in /nix/store/*leksah*/bin/ which of course does not contain cabal. It does on most other systems. The fix is trivial: Patch and make leksah use findExecutable instead. Probably this issue does not exist if you install everything into ~/.nix-profile ? I haven't tried. In the past I mantained a ghc-pkg patch which was able to merge many package databases (or write one based on GHC_PACKAGE_PATH which is not used very often - so most tools including leksah and cabal library ignore it :-( ). I got tired of keeping the cabal patch up to date also because merging using darcs was no fun. However it was a lot of work and broke several times and Andres Loeh ghc wrapper which traverses PATH worked good enough. I'd call it a hack because of ISSUE 1). Do you care enough about this all to help working on a solution? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] overview about hack-nix and how it works
Excerpts from Andres Loeh's message of Wed Aug 10 17:15:50 +0200 2011: I might try and fix leksah package detection in NixOS. So I'd wait until next Monday before spending a lot of extra time on this. hack-nix is populating GHC_PACKAGE_PATH. In which way would you try fixing it? Make leksah pay attention to ~/.nix/profile/ package databases? I'd like to see the ghc-pkg --list thing fixed as well. What about replacing the -package .. hack with setting GHC_PACKAGE_PATH=: ? (the : at the end says also use system packages). I'll give it a try. Can you help making a list what to test? - scion - leksah - ./Setup configure (what about cabal configure?) - ... - ghc - ghci So that they all detect it? Does something else come to your mind? I'm really curious in which way Leksah's fix fixable errors compete with my hacky Vim scripts.. I like leksah using Yi (or will be using) Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] overview about hack-nix and how it works
Excerpts from Marc Weber's message of Wed Aug 10 18:10:31 +0200 2011: - scion - leksah - ./Setup configure (what about cabal configure?) - ... - ghc - ghci - run-ghc - runhaskell Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: overview about hack-nix and how it works
(hack-nix
solver), and we've been talking about manually setting them in nixpkgs.
So I'm not quite sure what you mean now. Maybe its clear what I've been talking
about now.
Maybe it also helps me telling you that I was talking about different things
when saying hack-nix. Its
- the whole idea
- the executable parsing cabal files (using the API which you called trivial)
The hack-nix solver is written in Nix and does not depend on hack-nix
executable.
It's using hack-nix's output (See [2] for example) only.
Now, if hack-nix would be able to resolve build input dependencies
automatically, then it would be very useful indeed.
It does. That's the whole point :) But there are smarter implementations
then brute force I used.. Its a draft implementation which works.
Marc Weber
[2]:
# REGION HACK_NIX: { name = scion; type = git; url =
g...@github.com:MarcWeber/scion.git; branch = resurrect-vim; }
{
name = scion; version = 0.3;
edeps =
[
{
cdeps = [];
deps =
[
{n = scion;}
{i1 = {gte = 0.2;}; i2 = {lt = 0.3;}; n = atto-lisp;}
{
i1 = {gte = 0.8.5.1;}; i2 = {lt = 0.9;}; n = attoparsec;
}
{i1 = {gte = 4.2;}; i2 = {lt = 4.4;}; n = base;}
{i1 = {gte = 0.9;}; i2 = {lt = 0.10;}; n = bytestring;}
{i1 = {gte = 0.1;}; i2 = {lt = 0.3;}; n = multiset;}
{i1 = {gte = 0.11;}; i2 = {lt = 0.12;}; n = text;}
{n = json;} {n = derive;} {n = network;}
];
}
{
cdeps = [];
deps =
[
{n = scion;}
{i1 = {gte = 4.2;}; i2 = {lt = 4.4;}; n = base;}
];
}
];
ldeps =
{
cdeps =
[
[
{or =
[
{compilerFlavor = GHC; versionRange = {gte = 6.11.20081113;};}
{
compilerFlavor = GHC;
versionRange = {i1 = {gte = 6.10.2;}; i2 = {lt = 6.11;};};
}
];}
{cdeps = []; deps = [];}
]
[
{
compilerFlavor = GHC;
versionRange = {i1 = {lt = 6.11;}; i2 = {gte = 6.10;};};
}
{cdeps = []; deps = [];}
]
];
deps =
[
{i1 = {gte = 4.2;}; i2 = {lt = 4.4;}; n = base;}
{i1 = {gte = 1.8;}; i2 = {lt = 1.12;}; n = Cabal;}
{i1 = {gte = 0.3;}; i2 = {lt = 0.5;}; n = containers;}
{i1 = {gte = 1.0;}; i2 = {lt = 1.2;}; n = directory;}
{i1 = {gte = 1.1;}; i2 = {lt = 1.3;}; n = filepath;}
{i1 = {gte = 6.12;}; i2 = {lt = 7.2;}; n = ghc;}
{i1 = {lt = 0.2;}; i2 = {gte = 0.1;}; n = ghc-paths;}
{i1 = {gte = 0.1;}; i2 = {lt = 0.3;}; n = multiset;}
{i1 = {gte = 1.1;}; i2 = {lt = 1.3;}; n = time;}
{i1 = {gte = 0.11;}; i2 = {lt = 0.12;}; n = text;}
{i1 = {gte = 1.0;}; i2 = {lt = 1.1;}; n = process;}
{i1 = {gte = 0.2;}; i2 = {lt = 0.3;}; n = unix-compat;}
{i1 = {gte = 0.9;}; i2 = {lt = 0.10;}; n = bytestring;}
{i1 = {gte = 0.5;}; i2 = {lt = 0.6;}; n = binary;}
{i1 = {gte = 1.0;}; i2 = {lt = 1.1;}; n = old-locale;}
{i1 = {gte = 2.3;}; i2 = {lt = 2.4;}; n = network;}
{i1 = {lt = 1.2;}; i2 = {gte = 1.1;}; n = temporary;}
];
};
srcFile = (fetchurl { url =
http://mawercer.de/~nix/repos/scion-git-826da.tar.bz2;; sha256 =
4b00cf1203f4dece73b27bd2e7c0426b3ed0e3a7510cc8837db50cffc7a08067; });
}
# END
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Patch: Add a --from-file option to all nix commands
Excerpts from Shea Levy's message of Mon Aug 08 20:33:19 +0200 2011: that this patch is NOT YET TESTED, I'm sending it here while I work on figuring out how to build nix from SVN in the hopes that someone might already be equipped to do so .. Wow. You're writing code without running a compiler. Either add lex, bison to buildinputs and build with -K forcing a failure then pick up env-vars file .. Or Have a look at myEnvFun in all-packages.nix. It does roughly the same. However you can load the env using the loadEnv command anytime (see comments). You have to copy paste build inputs. That's what I've been using. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: overview about hack-nix and how it works
: For python and ruby overlays I didn't implement brute force solving. Instead if version mismatches are found an error message is given and you can force a version manually which is a compromise. For Python there are additional issues such as you having to evaluate the description .py files to know about dependencies. So a lot of dependencies have to be added manually. Ruby is stable, Python is still experimental. In the end you also have to think about whether you want to download 50.000 package descriptions (ruby case) if you only want to build 20 out of them. I don't have a solution to this problem which applies to ruby, python, haskel, cepan (perl), .. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: overview about hack-nix and how it works
Excerpts from Juan Daugherty's message of Sun Aug 07 18:30:09 +0200 2011: I built leksah yesterday from scratch on debian 6 after being unable to do so earlier on deb 5. I was surprised how many dependencies there were on ghc6 and ghc6 plgs and how much ad hackery was necessary to get the app built. Well, the cabal file says ghc 7.1 ... Anyway its a nice sample to illustrate what's going on: summary: I didn't finish updating leksah because it would require me updating gtksourceview which probably would require me updating gnome, which could take a couple of hours or more. HACK-NIX http://dpaste.com/588859/ Its easy to see whatever hack-nix tries it fails at haddock. looking at its cabal file its clear why: I force ghc-6.12.x and most recent haddock requires ghc = 7.x So the (first) fix is to add haddock-2.8.1 to the pool and run hack-nix without arguments. Next run is successful and the build starts. Second Failure: Setup: The program alex is required but it could not be found builder for `/nix/store/q419iwglqlgxvywjs59d2yy450yrajvc-haddock-2.8.1.drv' failed; keeping build directory `/tmp/nix-build-q419iwglqlgxvywjs59d2yy450yrajvc-haddock-2.8.1.drv-0' So the fix is to pass alex, happy to haddock because there is no way to tell cabal that an app requires alex,happy,... (there is a bug report though). 3rd Failure (adding gtk2hsBuildToolsFixed, pkgconfig to gktsourceview2) 4th Failure: Not updating gtksourceview (gtk library) which would be required because headers are missing. The headers are not contained in sources. So I'm stopping because I don't want to update gnome at this time :( compared to cabal-packages.nix == first attempt: -iA haskellPackages.leksah: Configuring process-leksah-1.0.1.3... Setup: At least the following dependencies are missing: directory ==1.0.*, filepath ==1.1.* second attempt haskellPackages_ghc6123.leksah Configuring ltk-0.8.0.8... Setup: At least the following dependencies are missing: glib =0.10.0 0.12, gtk =0.10.0 0.12 And at this point I stop, cause I fear getting lost in managing dependencies manually. That's why I wrote hack-nix. Probably it can be easily fixed. The final issue will be gktsourceview anyway. Replying to your additional statements: I'm glad to see this is being talked about and hopefully eventually addressed in the large, i.e. the issue of lang specific pkg managers running under Nix (gems, cabal, pear, whatever). Well - we have to discuss how such a solution should look like. I already mentioned that you eventually don't want 50.000 package description on disk if you use only 10 of them. Also we're far from packaging Eclipse plugins for instance. I wouldn't want to try build leksah on NIxOS Its packaged. So it would have been much easier than using Debian! Well - after figuring out that you have to use haskellPackages_ghc6* instead of the default (7.0.2). a desktop on NixOS anyway. You should make a difference between nixos and nixpkgs. nixpkgs can be used without NixOS on any system (eg debian). And we're talking about packages (similar to nixpkgs here, not the OS) Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Scion, anyone?
Excerpts from Peter Simons's message of Sun Aug 07 21:38:47 +0200 2011: we have a package for Scion, but it doesn't compile with GHC versions newer than 6.x. I've switched to dev version (branch scion-2nd-attempt) some time ago which does no longer depend on ghc-syb. However it depends on atto-lisp which does no longer build with ghc-6.x either (works fine with ghc-7.x though) Andres Loeh has added it so he should comment. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: overview about hack-nix and how it works
take some additional seconds. existence of hack-nix should not be exposed to end users. There are two types of users: - a) the let me try darcs user, they don't care - b) the let me hack on my library and verify that it still builds with ghc-6, ghc-7 and ghc-dev. They have simple questions like Does my package still build if I use newest version of Y? In those cases they change the cabal constraints, run hack-nix and they are done. Maybe I misunderstand the situation, but I have the impression that I would have to install hack-nix before I could install any of the packages in that pool. You have. See B1 B2 in my very first long reply. One is using hack-nix, the other doesn't. hack-nix --build-env just encodes cabal dependencies of *.cabal of the package you're working on in a temporary .nix file so that dependencies can be resolved. The current package get's version so that it always wins over packages found on hackage. I believe you are overstating the magnitude of that problem a bit. Cabal files on Hackage are usually quite accurate. We have different experience here. Even tools like alex had to be patched because they failed due to split base.. Again, I pointed you to the kind of trivial patches I applied in the repo. Just check them out and read a couple of them. Most are trivial, I agree. If you manage dependencies manually you can just pass in the right deps and be happy. If you have a solver you have to fix them occasionally. you can always ask upstream to fix them. And what? waiting 7 days until you can continue if you want to be done tomorrow? You're kidding. Because of this issue (interlude being broken due to a simple typo) I started: http://haskell.org/haskellwiki/Hackage_wiki_page_per_project_discussion In that interlude case I waited 2 weeks and wrote two mails. When the maintainer replied it was fixed fast. When I want to package something I want to make it work for me and others immediately if possible. you can upload a fixed version yourself. If a Cabal file has bugs, then you are by no means doomed; there are plenty of ways to remedy the situation. Right. Usually maintainers should do it and they may be on holiday. Well, if that is true, then hack-nix is not particularly helpful. Figuring out those dependencies is by far the most difficult part of the whole task. What would anyone need a dependency resolver for if it doesn't resolve those dependencies? Automate what can be automated: fetch hashes, write .nix code, .. doing in haskell-packages.nix already. We don't need a tool that allows us to continue to do that manually -- we need a tool that does that for us. If you update a package, do you retest all the others depending on it? What if they require the older one by cabal constraints? Good luck with retesting them all over and over again. Then you updated 10 packages. Then you notice that you also want to give library Z a try. But because nobody updated Z for 3 years it depends on many old packages. What do you do then ? Checkout an older revision of nixpgks 3 years ago? Good luck. Sources will be gone. You're right, we need a tool which is perfect. hack-nix is only a small step towards that perfect solution. I can't afford being perfect always :( I totally agree that hack-nix improves a lot of small sources of failure which are not very obvious at the first glance. Eg that you may break other packages when updating a library. You'll notice the difference if you need those other packages when they are already broken. If you update the hackage cache latest versions change. This breaks packages as well. I think that hack-nix is helpful because you can fix it faster because its less likely that you break other packages by adding additional packages to the pool, you never forget to remove dead dependencies, you don't overwrite packages versions deeply then noticing that other packages fail after having waited a minute for the failure to occur, ... Currently its great because it also does tagging. I agree that this could be added to haskell-packages.nix as well. I'd say we've talked enough. You have an idea about what it is. You also know about its strength and weaknesses. So either you give it a try or you don't. I'll not bother you again about this. You've done what I asked you to do which was learning about the difference - thanks for taking that time. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: haskell-packages: added cabal2nix
Excerpts from Peter Simons's message of Sat Aug 06 09:45:28 +0200 2011: I did try hack-nix. I had trouble understanding how it works, though, and how it's going to scale. Which kind of scaling do you fear? Of course it doesn't scale. That's why I keep it going by limiting the pool of hackage packages it knows about. The default is - latest versions - some manually selected versions to keep some packages building That scales good enough to build everything from yi to darcs or gtk2hs. Well it looks like you're not that interested right now. Whenever that changes and you want to enjoy additional goodies such as having accurate tag files, packaging head versions of haskell packages, switching ghc versions and package configurations (almost) seamlessly [1], give me a chance to explain the details. [1]: true, limiting the pool also limits this feature. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] overview about hack-nix and how it works
Excerpts from Peter Simons's message of Sat Aug 06 13:31:21 +0200 2011: do I understand it correctly that you are saying hack-nix can build *all* of Hackage? I could pick the latest version of any random package, and hack-nix would know how to build it and the build would succeed? That button to press on get my job done does not exist. So what does it do? (sketchy list): A) generate package pool 1) get the index from hackage containing all package versions (and calculate hash, this takes time .. [3]) 2) filter it keeping latest versions + manually selected ones (this can be configure in the ~/.hack-nix/config file) The result of 2) is patched [2] (because dependencies in .cabal files are very often wrong!) and the result is written to a file. This is done by running hack-nix without arguments. The result can be found here: https://github.com/MarcWeber/nixpkgs-haskell-overlay/raw/master/hackage/hack-nix-db.nix B) use the pool (the magic?) === On top of the pool brute force solving of dependencies takes place. Because having all hackage packages would create a huge solution space I have to limit it [4] This pays attention to executables may have additional dependencies which are not propagated upstream. Thus when a package is built its guaranteed that no two versions of the same package cause cabal compile time warnings (or runtime failures). There are two ways to run the solver: B1) when developing: cd into directory containing cabal file: hack-nix --build-env [optional configurations ..] the result is a bash script you can source which will add all dependencies to PATH so that configure build just works. Additional it'll define TAG_FILES. Then you can configure your editor to use them. Tags are generated for all packages automatically which is good enough for 90% of all cases (the other 10% being cpp or template haskell generated code ..) B2) in nix(os/pkgs,..) [default.nix], line 486, example xmonad This way you can use packages in ~/.nixpkgs/config.nix or /etc/nixos/configuration.nix when using overlays [6] Now to reply to your question: No, it won't build all packages on hackage, because they may not even build whatever configuration you may choose (eg if they contain perl instead of haskell code ..). But given the pool it'll tell you whether the cabal dependencies match and feed deps into cabal builds so that at least this work is eliminated when maintaining packages. Its still your task to assign cabal flags (see [default.nix] line 327, darcs example), select additional not latest version [7], or add additional C dependencies (mysql, gtk, ..), see [default.nix] line 216. So if all latest versions on hackage could be build by a single ghc version I'd happily reply yes to your question. Obviously this assumption will be false (thinking about 5.000 packages or more, some being unmaintained). However very often hack-nix --build-env just does the job without packaging anything previously. There are some additional constraints such as packages from the pool being dropped if ghc ships with basic versions and such. We should talk about them if this is causing issues. Nevertheless I have to agree that I picked up a lot of cabal flag configurations from nixpgks (eg xmonad), because it already worked there. I also want to say that coding this kind of stuff in Nix is no fun (no type system) So if it breaks it may be some work to fix .. Luckily only small adjustments had to be done in the past.. Marc Weber more details and links: [2]: See here for a list of cabal file patches: https://github.com/MarcWeber/nixpkgs-haskell-overlay/tree/master/patches You can also patch the Haskell code. If you want to create a patch try: hack-nix --patch-workflow name-version [3]: That's why I also commit the nix-cache: https://github.com/MarcWeber/nixpkgs-haskell-overlay/raw/master/hackage/nix-cache [4]: limiting the solution space is done by using latest versions some manually selected ones. The second limitation is done by choosing default cabal flags which sometimes have to be overwritten. [6]: overlays: They allow moving masses of nix code into external repositories. Think about it being a simple import passing pkgs. [default.nix]: https://github.com/MarcWeber/nixpkgs-haskell-overlay/blob/master/default.nix [7]: my hack-nix config. It gives you an idea. Note the target-packages line telling it to add additional versions to the pool. hackage-index http://hackage.haskell.org/packages/archive/00-index.tar; # url all-packages.nix /pr/gitnixdev/nixpkgs/pkgs/top-level/all-packages.nix # readable description about why some older versions are included: # scion: # ghc-syb 0.1.* # list-tries 0.1.* # uniplate 1.2.* # Cabal 1.8.* # hslogger 1.0.12 # # syb 0.1.0.3 because of agda # QuicCheck 2.1 because of agda # neither because of yesod and persistent # network-2.2.1.10 because its the latest version
[Nix-dev] haskell-packages: added cabal2nix
Hi Peter, Don't you want to give hack-nix at least a try? It hurts me very much seeing that you continuously spend so much time on packaging Haskell packages while I've solved this all long time ago providing additional features such as patching support, dependency resolution etc. At this point you should at least have given it a try once. I offered providing a SSH setup so that you can try it with zero install? You that time told me that you have to try it yourself (for whatever reason) - But I never received any feedback. That time I've spend about 3 weeks on that solution. It does work. What else can I do ? Looks like I'm brain dead .. Do whatever you have to do, its about your time, not mine. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] linux-3.0 btrfs getting slower slower on increasing uptime
I tried it several times stopped doing backups etc to make sure IO is not blowing my SSD away.. Nothing worked. After 48h of uptime the system gets slower and slower. on #btrfs I was told to switch back to 2.6.38 because there is a known bug which will eventually be fixed in 2.6.38.1. I haven't tested whether this bug applies to btrfs only neither did I ask for the exact reason. Its enough to know that my system is back to speed after downgrading the kernel. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: Fwd: Re: [Nix-dev] linux-3.0 btrfs getting slower slower on increasing uptime
Isn't it already up to 2.6.38.8? typo, sry: log: 19:10 MarcWeber When having uptime 48h system slows down and start hanging. Rebooting fixes it always. I'm using btrfs on a SSD, linux-3.0. Any ideas how to find out what's causing it? Maybe it is not btrfs related at all. Somehow it looks like being related to file IO. 19:10 cwillu MarcWeber, try 2.6.38 19:11 cwillu if I understood josef correctly, there's a bug that's not our fault that causes this; I think it may have been fixed in the pull-request for 3.1, but I'm not certain of that Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: [Nix-commits] Nix - Issue 210 has received a comment
Can you pick any .drv file in the middle and build that first? If you do nix-store -q --tree final-system-derivation then it should be easy to pick something closer to the leaves. Its not perfect but with some luck it might get the job done. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Linux 3.0 Install Problem
The patch which worked for me is this: http://mawercer.de/~marc/kernel-3.0 (this is rc5, Shea Levy tries with release version). Looking at the code a second time maybe substituteInPlace Makefile --replace '-b $(INSTALL_MOD_PATH)' '' does no longer suffice? Don't care anymore that much. I've been running rc5 for a couple of days without noticing anything strange. However python and xulrunner (required for firefox) will fail building: - firefox xulrunner does no longer build. (xul.patch fixes it, attached) - python-2.7 does not build. While looking at the build logs I also noticed that it looks like a different set of modules is build if you build i686 packages on a x86_64 system. I don't have a patch yet. Marc Weber xul.patch Description: Binary data ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: [Nix-commits] SVN commit: nix - r27888 - nixos/trunk/modules/services/monitoring
Excerpts from Eelco Dolstra's message of Mon Jul 25 02:42:35 +0200 2011: This path does not necessarily exist (e.g. when using ssmtp via ‘networking.defaultMailServer.directDelivery = true’). No, it must not. But having sendmail setuid seems to be very common and eventually features are limited if you don't use setuid. I'm not an expert - repeating what I grasped at a blog which also might be wrong. nixos has a services.mail.sendmailSetuiWrapper option introduced by Lluís Batlle. So should we introduce a global sendmailPath option? PHP also requires a sendmail setting. I think also cron does and a couple of others services. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use shallow copying in fetchgit
Excerpts from Peter Simons's message of Wed Jul 20 22:46:57 +0200 2011: Does anyone see a problem with applying this patch? Yes. At least in the past there was an issue: You could'nt tell git check out rev XY. So you had to get trunk and go some revs back. If you use shallow 1 its very unlikely that trunk is exactly the hash which was comitted to nixpkgs. At least that's the only reason you should think about before comitting it. If checkout takes too long try nix-repository-manager which creates .tar.gz archives for git,hg,... VCS sources. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Use shallow copying in fetchgit
It may still make sense to use depth X where X is the amount of commits done within 6 month of a project or such. This would still be a lot faster than getting all history. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Use shallow copying in fetchgit
Excerpts from Peter Simons's message of Thu Jul 21 01:14:23 +0200 2011: That's the code pkgs/build-support/fetchgit/nix-prefetch-git Its doing this: git fetch --depth 1 origin +$ref || return 1 Didn't know that you can fetch hash's that way. You can git fetch --depth 100 then try 200 then 500 .. to find it as well. If Pierron's solution works its best. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to run GnuCash (and other GConf applications) on NixOS
1) Add the following line to ~/.gconf.path: xml:readonly:$(HOME)/.nix-profile/etc/gconf/gconf.xml.defaults/ 2) Add the following line to /etc/nixos/configuration.nix: services.dbus.packages = [ pkgs.gnome.GConf ]; Now run nixos-rebuild switch. It may also be necessary to run I'd say this should be put on the wiki .. Peter, are you going to add a very short (copy paste) howto yourself or may I do so for you? I've had issues which such a case myself. Can't remember it exactly. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: How to run GnuCash (and other GConf applications) on NixOS
Excerpts from Peter Simons's message of Mon Jul 11 23:17:18 +0200 2011: you are right. I never obtained an account for editing the Wiki, but now it's probably about time. I've put those instructions here: Thanks - a lot of people will run into this (including me :) Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Adding perl as a build input to util-linux-ng?
Excerpts from Lluís Batlle i Rossell's message of Sat Jul 09 22:30:43 +0200 2011: What would be the benefit? Quoting from commit message: Message: 4 Date: Fri, 08 Jul 2011 23:11:38 + From: Peter Simons James c...@cryp.to Subject: [Nix-commits] SVN commit: nix - r27681 - in nixpkgs/trunk/pkgs:os-specific/linux/util-linux-ng top-level To: nix-comm...@cs.uu.nl Message-ID: 20110708231138.553ce2b8...@mx2.tudelft.nl Content-Type: text/plain; charset=UTF-8 Author: James Cook Date: Fri Jul 8 23:11:38 2011 New Revision: 27681 URL: https://svn.nixos.org/websvn/nix/?rev=27681sc=1 Log: util-linux-ng: prepare expression for the addition of perl as a buildInput The chkdupexe utility requires perl. We cannot change the expression, though, without triggering a re-build of almost all of stdenv, so for the time being I'm making Perl an optional build input that is disabled by default. I agree that Peter should have told about this reason in the mail in addition to the commit message :) Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] texlive-core corrupts manpath
Excerpts from Peter Simons's message of Thu Jul 07 13:58:10 +0200 2011: after installing texlive-core, I get the following error from man: I've removed that man path in my git branches since ages.. Since the symlink is broken it doesn't seem to hurt. So it looks like its safe to remove it. I don't use texlive very often though. This issue also popped up on irc some weeks ago. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] PATCH rawtherapee update
Marc Weber raw-therapee-update.patch Description: Binary data ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Browser update
Excerpts from Vladimír Čunát's message of Mon Jul 04 16:49:18 +0200 2011: Thanks, I forgot that svn trunk currently isn't being merged every day into topgit... just wasted build time. There was another reason. The update broke to the git configuration update. I'm sorry about that. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] nixos rsnapshot module
Enjoy and report bugs Marc Weber nixos-rsnapshot-module.patch Description: Binary data nixpkgs-rsnapshot.patch Description: Binary data ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS issue: Passwords and Nix store
I'm not sure I was able to follow you.
Having a private database would be fun - cause you can change passwords
without recompiling anything.. However this probably means you have to
patch all applications?
passwords in store and restricting access:
think about henry and sally choosing the same password by accident...
Now the trouble starts:
- one can notice that a derivation won't be built - thus he / she knows
that another user is using the same password
- user id's would not work - cause many users should be able to
use the same { pwd = same-password} derivation. ACL's would be a
way. This building a derivation which already exists would mean adding
access rights for a user.
Which use cases are bothering you making you think about this issue?
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] patch: fix ifconfig path for vbox making host adapter and bridge networking setup work proberly
I tried setting up PXE booting recently and it drowe me nuts cause the VM didn't get a dhcp lease. The reason is that vbox runs ifconfig configure the interface and it looks like a failed exit code confuses vbox because manually setting up those interfaces didn't work either (?) Anyway telling vbox about ifconfigs path fixes all issues for me. If you want to test PXE booting yourself don't forget to switch off vbox's internal dhcp server in global settings - network.. Marc Weber vbox-ifconfig-path.patch Description: Binary data ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Is there a way to force small derivations being build locally only?
building `/nix/store/4my4jvqd5cyqxns3x7fcrxaczximjjvj-system-path.drv' on `root@192.168.2.232' This doesn't really make sense. It would be faster to build it locally only. Is there a way to flag a derivation so that remote builds are rejected? Would such a feature make sense - or would it add more complexity than value? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] This is how lxc man pages can be built ..
patchPhase = '' sed -i -e 's@docbook2man -w all .*@true@' doc/Makefile.in # add BOM so that docbook2man knows about encoding (assume utf8) sed -i \ -e '1s/^\(\xEF\xBB\xBF\)\?/\xEF\xBB\xBF/' \ -e 's@!DOCTYPE refentry PUBLIC -//Davenport//DTD DocBook V3.0//EN \[@!DOCTYPE refentry PUBLIC -//Davenport//DTD DocBook V3.0//EN /dev/null [@' \ doc/lxc-*.sgml.in ''; # manually building man pages seem postBuild = '' ( cd doc; for i in lxc-*.sgml; do docbook2man $i; done ) ''; I'd not trust them too much - that they don't build seem to be a known issue ? or our docbook2man is too new ? The code adds some utf-8 boms to .sgml files so that docbook2man knows about an encoding. Also its building the man pages manuall rather than using make .. Thus docbook2man -w all is replaced by true. make install still installs those man pages. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Bisection in Hydra
Excerpts from ludo's message of Tue Jun 07 18:16:40 +0200 2011: What do you think? Should it bisect nixpkgs revisions or let's say svn revisions of tigervnc? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] rationale behind pathsToLink?
Why does this option exist? Why isn't it set to [/] (link all) by default? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] fixing the annoying Cannot find terminfo entry for 'rxvt-unicode'
urxvt ships its own terminal file which you can install system wide using
NixOS's option pathsToLink = [/] easily.
Additionally adding this to the system wide bashrc:
# try to find current terminal setting in system or user profile:
for p in {/var/run/current-system/sw,~/.nix-profile}/share/terminfo; do
[ -e $p/${TERM:0:1}/$TERM ] {
export TERMINFO=$p
# looks like we have to reset TERM after telling zsh where to find
TERMINFO ?
TERM=$TERM
}
done
unset p
will set TERMINFO accordingly and suddenly mutt, screen etc can be
started without tweaking TERM first.
The complicated for loop has been chosen so that it is also enough if
the user installs urxvt into the profile.
You can find minor fix in my branch nix2/multi-shell-support.
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: ZeroMQ package.
Excerpts from Arthur Smyles's message of Wed Jun 01 00:43:39 +0200 2011:
+stdenv.mkDerivation rec {
+name = zeromq-2.1.7;
convention is to use 2 spaces as indentation.
If you're using Vim install vimConfigurable or get vim-addon-nix.
Both add additional VimL code setting this properly.
This is a minor issue only.
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] start samba / stop samba fix + move decls which jobs should not be started into job decls
Marc Weber samba.patch Description: Binary data ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] vbox --headless and rdp?
Has anybody succeeded in starting a headless vm instance while using rdp? after installing oracles extension pack rdp can be enabled and it works. However trying to start in headless mode: VBoxManage startvm name --type headless I get: VBoxManage: error: The virtual machine 'XP INSTALL TEST' has terminated unexpectedly during startup with exit code 1 VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component Machine, interface IMachine, callee This is probably due to nixpkgs uncommon setup? headless works fine in debian chroot - however I always get connection refused when trying to connect to it using remote desktop. I can connect to a nc server run in chroot so networking is fine. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] patch - debootstrap update
Marc Weber diff.trunk Description: Binary data ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] git mirroring - karltk's email address?
Hi list, git mirroring stopped because I don't have an email address of karltk. git-svn stops if it can't find a name in the authors.txt file. Does anybody know how to ask him about its current email address or whether I should use a dummy adress such as dontknow@dontknow.doesnotexist? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Debugging NixOS login problems
Excerpts from Rickard Nilsson's message of Fri May 06 13:32:21 +0200 2011: Does anyone have a suggestion on how to debug this? AFAIK PAM is used for logging in. However what you describe doesn't make sense to me. I recall you can make PAM print or log messages. However maybe its faster to try chrooting eg from a live cd and try passwd or such setting a passowrd and examining the user's shell setting. You didn't mention your way of installation. You can even try start ttyX from chroot after stopping tty from the live cd. Why are you using NFS? I never tried booting from NFS. I think it should not make a difference. Do you mount rw or ro? Maybe that also makes a difference (guessing) I know that login writes to the disk keeping the last login timestamp. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Defaulting to GRUB 2?
Excerpts from ludo's message of Wed May 04 10:57:32 +0200 2011: More importantly, it seems that most of us are using GRUB 2, which leaves GRUB 1 somewhat untested. I'm still using GRUB1 because GRUB 2 didn't boot in the past (lot's of IO errors or such). I stopped debugging it that time. Maybe that's fixed now. However grub devs stopped supporting the 1 (or 0.9?) version for month. It still works fine here :) If I encounter any trouble with the change I'll post. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] nix-commits Digest, Vol 45, Issue 73 - Remove installer2 and nixos-bootstrap-archive
Message: 4 Date: Wed, 27 Apr 2011 16:16:47 + From: Eelco Dolstra e.dols...@tudelft.nl Subject: [Nix-commits] SVN commit: nix - r27008 - in nixos/trunk/modules/installer/tools: . installer2 nixos-bootstrap-archive To: nix-comm...@cs.uu.nl Message-ID: 20110427161647.ad9c9108c...@mx3.tudelft.nl Content-Type: text/plain; charset=UTF-8 Author: eelco Date: Wed Apr 27 16:16:47 2011 New Revision: 27008 URL: https://svn.nixos.org/websvn/nix/?rev=27008sc=1 Log: * Remove installer2 and nixos-bootstrap-archive for lack of documentation / maintenance / clear use cases. Sorry? Lack of maintainance? Lack of documentation? What are those assumptions based on ? Its referenced here: http://wiki.nixos.org/wiki/Install_NixOS_on_Linode Purpose: 1) Provide a minimal archive containing everything required to bootstrapm nixos. Thus it contains curl, nix tools and glibc and about 2 shell scripts checking out nixos/nixpkgs into /etc and doing the chroot work. 2) separate tasks: chroot and install nixos. This is nice if you want to debug the installation or just chroot into /mnt. It mounts / unmounts /proc /sys etc for you. Thus the installation command is do-chroot 'nixos-rebuild ...' or the like. By untarring it on /mnt you can install nixos without boot iso which makes it very useful for people who can't prepare an installation locally and upload it because uploading takes several hours due to upload speed. Of course this is your project - and you may do whatever you wish. My reply time to mails about nixos is often less than 12 hours and almost always less than 24h. So sending a small mail to the mailinglist would have been an alternative. Well I can create those archives myself - and I know how to install NixOS. So maybe I should just remove the wiki article which is outdated now? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix-env bugs
Excerpts from Vladimír Čunát's message of Tue Apr 05 23:11:52 +0200 2011: Hello, it seems nix-env --upgrade is broken. I'm not sure if this was always like that (my version is 1.0pre26015) but it is certainly clashing with the man page. It offers downgrades by default and -A doesn't work at all. For example, nix-env -u \* says upgrading `python-2.7.1' to `python-2.4.6' (that is very old python!). Viric confirmed this on IRC. Can you paste this: nix-env -qa \* -P -f $NIXPKGS_ALL | grep -i python I personally don't use upgrade. Its even harmfull: If a package gets renamed or goes away you won't notice it! That's why I use a collections (see wiki) instead. I always upgrade by reinstalling a set of packages. Then I know that everything still builds the way I know. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How can I stop python writing into the nix store?
Excerpts from roconnor's message of Mon Apr 04 08:19:06 +0200 2011: What is the best way to stop python from modifying the nix store? I'm considiering trying to convince python to write its .pyc or .pyo files at build time so it doesn't feel compelled to write them at runtime. Any ideas how to do this, or any other solutions to this problem. I remember that there was patch - but I can't find it. So maybe I was wrong. From python --help: -B : don't write .py[co] files on import; also PYTHONDONTWRITEBYTECODE=x would be another option. P.S. wicd also writes stuffin into it's share directory in the store. I think I will tackle this issue by patching the source code for wicd. Eelco once came up with a quick solution for this kind of problem for xorg: make $out/etc/share point to /var/share/wicd or such. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Minor stdenv down-grade required in trunk
Excerpts from Peter Simons's message of Fri Apr 01 18:49:34 +0200 2011: Does anyone mind that change? Are there any known security bugs of that older version we should care about? I don't use 2.4 kernels anymore. Probably I'll keep using the new versions in my branches because I don't want rebuilds. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: Various patches
Hi Vlada, Excerpts from Vladimír Čunát's message of Thu Mar 31 21:41:36 +0200 2011: Yesterday I spent a lot of time upgrading hakyll to 3.*, due to many transitive dependencies needing upgrade. :-( You should not have spend time on it. Use hack-nix. All this manually stuff is done by nixpgks-haskell-overlay for you. These are the steps I have to do to get it: a) add it to cabals bulid-deps b) run hack-nix --build-env (wait some minutes) c) source resulting shell script I've talked to Andres Loeh and tried explaining how hack-nix works. The result was that he would prefer a different system which does not yet exist. There are reasons why hack-nix is the way it is. And since Eelco rewrote the evaluator speed is acceptable as well. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS module assertions
Excerpts from ludo's message of Mon Mar 28 17:33:34 +0200 2011:
Why is that? How should we work around it?
In order to reproduce your problem having a configuration.nix file would
be benefical. I get the assertion only when setting kernelPackages and
enabling ttyBackgrounds.
I'd vote for moving the code checking the assertions (assertions.nix)
# This option is evaluated always. Thus the assertions are checked as well.
hacky!
environment.systemPackages =
if [] == failed then []
else throw \nFailed assertions:\n${concatStringsSep \n (map (x: -
${x}) failed)};
to eval-config.nix to ensure its evaluated first eg by adding this untested
code which surrounds the old config = by a let .. in catching the case that
assertion messages are present:
# Optionally check wether all config values have corresponding
# option declarations.
config =
let cfg =
let doCheck = optionDefinitions.environment.checkConfigurationOptions;
in
assert doCheck - pkgs.lib.checkModule systemModule;
systemModule.config;
failed = map (x: x.message) (filter (x: !x.assertion) cfg.assertions);
in if failed == [] then cfg
else throw \nFailed assertions:\n${concatStringsSep \n (map (x: -
${x}) failed)}
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS module assertions
Excerpts from Nicolas Pierron's message of Tue Mar 29 11:11:11 +0200 2011: The only disadvantage is that you won't see multiple assertions failing at once. On the other side, you will always see when an assertion is failing and this implementation is cleaner. Would you mind comparing your solution briefly with what I suggested: force evaluation of assertions when returning the config? I prefer seeing all failures at once rather than many iterative try / fail / fix cycles. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS module assertions
Excerpts from Nicolas Pierron's message of Tue Mar 29 18:09:29 +0200 2011: The problem I see here is that you cannot focus on small subset of your configuration if one assertion is failing unless you disable each module. The problem is raised when you may want to check for option values while trying to understand why you've got an error message (including the assertions). I don't know what you mean by check for option values. The assertion message should be unique. By grepping for it it should be easy to understand the cause of trouble. That would be my way to cope with such failures.. Is this the difference: my solution: assertions always fire your solution: assertions only fire when a guarded expression is used? I see the point. However I don't think its important because assertions are usually guarded by mkIfs or the like. Thus they are only checked when a module is enabled. I would prefer to use properties for assertions (mkAssert), so an assertion made on an unused option has no effect. I already said that I'm fine with your solution. You know this code much better than I do. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [***SPAM***] [PATCH] fix adobeReader by adding gdk_pixbuf to libPath
---
pkgs/applications/misc/adobe-reader/default.nix | 10 --
pkgs/top-level/all-packages.nix |2 +-
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/pkgs/applications/misc/adobe-reader/default.nix
b/pkgs/applications/misc/adobe-reader/default.nix
index 24d01da..cc05328 100644
--- a/pkgs/applications/misc/adobe-reader/default.nix
+++ b/pkgs/applications/misc/adobe-reader/default.nix
@@ -1,4 +1,4 @@
-{ stdenv, fetchurl, libX11, cups, glib, pango, atk, gtk, zlib, libxml2 }:
+{ stdenv, fetchurl, libX11, cups, zlib, libxml2, gtkLibs }:
assert stdenv.system == i686-linux;
@@ -17,7 +17,13 @@ stdenv.mkDerivation {
# versions.
libPath = stdenv.lib.makeLibraryPath
-[ stdenv.gcc.gcc libX11 glib pango atk gtk zlib libxml2 cups ];
+[ stdenv.gcc.gcc libX11 zlib libxml2 cups
+ gtkLibs.pango
+ gtkLibs.atk
+ gtkLibs.gtk
+ gtkLibs.glib
+ gtkLibs.gdk_pixbuf
+];
meta = {
description = Adobe Reader, a viewer for PDF documents;
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 9d70c53..be80fbf 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -5584,7 +5584,7 @@ let
};
adobeReader = callPackage_i686 ../applications/misc/adobe-reader {
-inherit (pkgsi686Linux.gtkLibs) glib pango atk gtk;
+gtkLibs = pkgsi686Linux.gtkLibs;
};
akunambol = newScope pkgs.kde4 ../applications/networking/sync/akunambol { };
--
1.6.6.2
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Various patches
About Vim: Also consider contributing to
http://github.com/MarcWeber/vim-addon-nix
About mercurial: My marc-next branch contains full mercurial support
including most extensions.
Eg my config.nix file:
mercurial = {
atticSupport = true;
guiSupport = true;
pbranchSupport = true;
hgsubversionSupport = true;
mqSupport = true;
histeditSupport = true;
hgextconvertSupport = true;
collapseSupport = true;
record = true;
};
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: nix-prefetch-git TopGit
Excerpts from ludo's message of Fri Mar 18 10:20:25 + 2011: Please see 87wrk7apf8@gnu.org. Please see something which looks like an email address ? I'm not smart enough to get this pointer. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: nix-prefetch-git TopGit
Excerpts from ludo's message of Fri Mar 18 11:52:28 + 2011: It\xe2\x80\x99s a message ID. You can try http://thread.gmane.org/gmane.linux.distributions.nixos/5770 instead. I don't know what you're doing here. And I'm not willing to spend many minutes on looking it up. You talked about tg patch. And you talked about git not fetching objects. The last statement is wrong. All the branches are there after running fetch but prefixed by remote/. If its the case that you don't understand either: git fetch remote or what remote vs local branches are you should look it up. tg patch probably won't work unless using tg remote --populate. In that case I was waiting for a simple explanation such as: I'd like to make hydra publish a patch which is the result of exporting a topgit branch. which would not have taken much time but which would have made your purpose easy to understand. If that's a case I'm lacking knowledge about how hydra manages incremental updates. Then I should shut up. If you talk about failures you haven't seen before you could copy paste the important lines. Getting many mb raw logs of 7 builds takes too long here. I'm not interested anymore. So we should close this thread. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: nix-prefetch-git TopGit
You've missed the real question: Why do you want to populate top-git branches? If you want this should local branches be populate always? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-prefetch-git TopGit
Excerpts from ludo's message of Wed Mar 16 15:04:16 + 2011:
I swear that \xe2\x80\x98tg remote --populate\xe2\x80\x99 /must/ be
performed, otherwise you
can run any 'tg' command.
s/can/can't/ ?
We agree on this.
Explain why you have to run any tg command, please. Which one do you
want to run? Pointing to repo is not enough to make me understand your
problem.
What makes your use case different from
git checkout -tb {,origin/}NAME
NAME can be t/foo
What wording would you suggest?
Simply dropping the word problem would be ok. I don't use the command so I
don't too much. However it may lead to wrong impressions when users who don't
know topgit at all read it.
I'd like to understand why you have to use topgit commands at all.
Because if you do so you'll create new hashes which will not be on
remote servers.
I've changed it to this in my local branches:
else
- echo WARNING: would populate TopGit branches but TopGit is not
available 2
- echo WARNING: install TopGit to fix the problem 2
+# TODO: is this useful at all? Should for each remote branch a
local branch be created?
+ echo If you had installed TopGit I would have populated local
topic branches 2
fi
However the key point is understanding what you want to do and why you have to
run top-git commands yourself.
My understanding of nix-prefetch-* commands is that they should print a hash
only which you can copy paste ..
If we are at it: Can't we make it even smarter outputting full
src = fetchurl { .. }
code rewriting urls by mirrors?
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] /srv directory for storing site-specifc data served by the system
Looks like this could be written down as Wiki article to remind everybody. I'm fine with changing paths. Looking forward to your summary. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] contribute patches and support of AIX platform
Excerpts from Olexiy Buyanskyy's message of Tue Mar 15 20:31:09 + 2011: I found solution here http://publib.boulder.ibm.com/tividd/td/ITAME/GC32-0846-00/en_US/HTML/am39_perftune11.htm I had to set to complete nix-env execution without std::bad_alloc export LDR_CNTRL=MAXDATA=0x200 This means nix-env requires at least 512Mb to parse all nix files You can prevent it from sourcing all by using the -A path flag. Eg nix-env -iA xorg.xserver. See wiki article how to find .. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] firefox40Pkgs.firefox build failure.
Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 + 2011: the trace yet, but if I figure out the problem I'll report back. Which revision? -r 26267 builds here (after updating sources), but I don't know how to run it cause xul is not configured correctly. It fails on startup. Maybe someone just knows what has to be done? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] commit review (ludo, Karn, eelco)
1) ludo
2) Karn
3) eelco
1)
Author: ludo
Modified: nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-git
==
--- nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-gitMon Mar 14
21:13:35 2011(r26304)
+++ nixpkgs/trunk/pkgs/build-support/fetchgit/nix-prefetch-gitMon Mar 14
22:00:20 2011(r26305)
@@ -120,6 +120,17 @@
# Checkout linked sources.
init_submodules;
+if [ -f .topdeps ]; then
+if tg help 21 /dev/null
+then
+echo populating TopGit branches...
+tg remote --populate origin
+else
+echo WARNING: would populate TopGit branches but TopGit is not
available 2
+echo WARNING: install TopGit to fix the problem 2
+fi
+fi
+
cd $top;
}
I've trouble with the wording problem.
The topic branches are fetched as remotes anyway.
top-git is only important if you want to run tg update.
However doing so will create local hashes which do not exist on a remote
server thus its useless.
So not using top-git is not a problem.
The real question is: should nix-prefetch-git populate local branches
for all remote branches automatically?
It looks to me like you tried doing that.
Your comments suggest that you should install top-git because otherwise
something doesn't work which is not the case.
Without git you can still git checkout origin/NAME etc.
2)
Update flapjax compiler
Let me show you how to use hack-nix because you can do this
automatically by nix-repository-manager 1 . --update flapjax and be
done.
3) merge failure (xorg-updates)
- firefox40Pkgs = let p = (applyGlobalOverrides (x : {cairo =
x.cairo_1_10_0;}));
- in p.callPackage
- ../applications/networking/browsers/firefox/4.0.nix {
+ firefox40Pkgs = callPackage
../applications/networking/browsers/firefox/4.0.nix {
inherit (p.gtkLibs) gtk pango;
inherit (p.gnome) libIDL;
};
Source is broken anyway and the result doesn't run (?) See other thread. So
its not very important ?
Thanks for doing it. With some luck I can get rid of the proprietary ATI
driver now.
I'll try and provide feedback soon.
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] firefox40Pkgs.firefox build failure.
Excerpts from Shea Levy's message of Wed Mar 16 03:03:14 + 2011:
On 3/15/11 11:01 PM, Marc Weber wrote:
Excerpts from Shea Levy's message of Wed Mar 16 02:46:25 + 2011:
the trace yet, but if I figure out the problem I'll report back.
Which revision?
-r 26267 builds here (after updating sources), but I don't know how to
run it cause xul is not configured correctly. It fails on startup. Maybe
someone just knows what has to be done?
See my short patch review. Eelco missed this small detail when
merging the x-udpates branch.
Apply the reverse patch of what I quoted and you're done .. except that
the source is gone.
beta was 12 some days ago:
rec {
- firefoxVersion = 4.0b7;
+ firefoxVersion = 4.0b12;
- xulVersion = 2.0b7; # this attribute is used by other packages
+ xulVersion = 2.0b12; # this attribute is used by other packages
src = fetchurl {
url =
http://releases.mozilla.org/pub/mozilla.org/firefox/releases/${firefoxVersion}/source/firefox-${firefoxVersion}.sour
-sha256 =
02cc466a92af828ff3bc563d4515bd98064cf5f136b5871e072b9408fb4db128;
+sha256 =
99e7f17d62d92d37aee850bdf7dfdc8572254e4b6c3c8b8f51143df06f2a04d9;
};
Good luck.
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Fwd: nix-commits Digest, Vol 44, Issue 33
stripped from commit messages: Log: Hakyll needs time = 1.2 Author: andres Log: Upgraded Hakyll to 2.4.3. I know, that's not the latest version, but Hakyll-3 is rather different from Hakyll-2 and the upgrade would require more work. ... Pushed a commit making hack-nix build it. You should really give it a try - even though the design is not what you would have done. It still gets the job done perfectly. Thanks for adding new ghc recently! Yours Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] contribute patches and support of AIX platform
I personally don't pay too much attention to the bug tracker. So also pasting to the mailinglist is probably a good idea. About aix not having gnu make: Would having a cmake build system help? I worte a partial support and someone else did so as well recently. Both implementations would need some additional love. But if it helps .. Or do you happen to know whether automake can recreate a makefile which can be run by your system? Probably this is all you have to do ? (guessing blindly) This is my opinion only - and I only maintain two small patches for Nix myself. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] [PATCH] nix2/debug
patch hepling debugging nix code failures.
If you get got X but Y expected this patch will make nix print what X exactly
is using XML dump.
Signed-off-by: Marc Weber marco-owe...@gmx.de
---
src/libexpr/eval.cc| 40 +--
src/libexpr/eval.hh|2 +
src/libmain/shared.cc |3 ++
src/libstore/globals.cc|1 +
src/libstore/globals.hh|6 -
src/nix-instantiate/nix-instantiate.cc |3 ++
6 files changed, 41 insertions(+), 14 deletions(-)
diff --git a/src/libexpr/eval.cc b/src/libexpr/eval.cc
index 949f45e..ce710ba 100644
--- a/src/libexpr/eval.cc
+++ b/src/libexpr/eval.cc
@@ -5,6 +5,7 @@
#include store-api.hh
#include derivations.hh
#include globals.hh
+#include value-to-xml.hh
#include cstring
#include unistd.h
@@ -202,6 +203,18 @@ void EvalState::addConstant(const string name, Value v)
}
+string EvalState::showTypeOrXml(Value v){
+if (xmldebugCorcionFailure){
+// make running this code intsead optional
+std::ostringstream out;
+PathSet context;
+printValueAsXML(*this, true, false, v, out, context);
+return out.str(); // don't know whether this is safe !
+} else {
+return showType(v);
+}
+}
+
void EvalState::addPrimOp(const string name,
unsigned int arity, PrimOpFun primOp)
{
@@ -490,7 +503,7 @@ bool EvalState::evalBool(Env env, Expr * e)
Value v;
eval(env, e, v);
if (v.type != tBool)
-throwTypeError(value is %1% while a Boolean was expected,
showType(v));
+throwTypeError(value is %1% while a Boolean was expected,
showTypeOrXml(v));
return v.boolean;
}
@@ -499,7 +512,7 @@ void EvalState::evalAttrs(Env env, Expr * e, Value v)
{
eval(env, e, v);
if (v.type != tAttrs)
-throwTypeError(value is %1% while an attribute set was expected,
showType(v));
+throwTypeError(value is %1% while an attribute set was expected,
showTypeOrXml(v));
}
@@ -721,7 +734,7 @@ void EvalState::callFunction(Value fun, Value arg,
Value v)
if (fun.type != tLambda)
throwTypeError(attempt to call something which is neither a function
nor a primop (built-in operation) but %1%,
-showType(fun));
+showTypeOrXml(fun));
unsigned int size =
(fun.lambda.fun-arg.empty() ? 0 : 1) +
@@ -989,7 +1002,7 @@ int EvalState::forceInt(Value v)
{
forceValue(v);
if (v.type != tInt)
-throwTypeError(value is %1% while an integer was expected,
showType(v));
+throwTypeError(value is %1% while an integer was expected,
showTypeOrXml(v));
return v.integer;
}
@@ -998,7 +1011,7 @@ bool EvalState::forceBool(Value v)
{
forceValue(v);
if (v.type != tBool)
-throwTypeError(value is %1% while a Boolean was expected,
showType(v));
+throwTypeError(value is %1% while a Boolean was expected,
showTypeOrXml(v));
return v.boolean;
}
@@ -1007,15 +1020,16 @@ void EvalState::forceAttrs(Value v)
{
forceValue(v);
if (v.type != tAttrs)
-throwTypeError(value is %1% while an attribute set was expected,
showType(v));
+throwTypeError(value is %1% while an attribute set was expected,
showTypeOrXml(v));
}
void EvalState::forceList(Value v)
{
forceValue(v);
-if (v.type != tList)
-throwTypeError(value is %1% while a list was expected, showType(v));
+if (v.type != tList){
+throwTypeError(value is %1% while a list was expected,
showTypeOrXml(v));
+}
}
@@ -1023,7 +1037,7 @@ void EvalState::forceFunction(Value v)
{
forceValue(v);
if (v.type != tLambda v.type != tPrimOp v.type != tPrimOpApp)
-throwTypeError(value is %1% while a function was expected,
showType(v));
+throwTypeError(value is %1% while a function was expected,
showTypeOrXml(v));
}
@@ -1031,7 +1045,7 @@ string EvalState::forceString(Value v)
{
forceValue(v);
if (v.type != tString)
-throwTypeError(value is %1% while a string was expected,
showType(v));
+throwTypeError(value is %1% while a string was expected,
showTypeOrXml(v));
return string(v.string.s);
}
@@ -1109,7 +1123,7 @@ string EvalState::coerceToString(Value v, PathSet
context,
if (v.type == tAttrs) {
Bindings::iterator i = v.attrs-find(sOutPath);
if (i == v.attrs-end())
-throwTypeError(cannot coerce an attribute set (except a
derivation) to a string);
+throwTypeError(cannot coerce an attribute set: %1% (except a
derivation) to a string, showTypeOrXml(v));
return coerceToString(*i-value, context, coerceMore, copyToStore);
}
@@ -1136,7 +1150,7 @@ string EvalState::coerceToString(Value v, PathSet
context,
}
}
-throwTypeError(cannot coerce %1% to a string, showType(v));
+throwTypeError(cannot coerce %1
Re: [Nix-dev] Hydra, nix-prefetch-git, and TopGit
Excerpts from Thomas Schwinge's message of Thu Mar 10 09:21:59 + 2011: Correct -- and may I ask, are you one of the (apparently) few who is still using TopGit? There isn't much / any development any more; but is I know. Uwe Klein K stopped using it at all. But I'm not aware of him talking about a replacement. Mercurial is no option because you can't drop branches easily And I love gits remote feature so much. I contributed the tg push feature. At that point I wished a scripting language would have been used. It works for me so why change or bother about missing upstream? I hope it won't break too soon though. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hydra, nix-prefetch-git, and TopGit
It should be sufficient to checkout the branch you want. Its not important whether the branch is a topic branch or not unless you want tg update to work. However I don't think that Hydra should run tg update. It should be you doing this manually pushing the result somewhere (?) details: TopGit topic branches have an additional refs/top-bases/$NAME branch marking the commit against which to diff when exporting a patch. You can think of it being the merge of all dependencies listed in .topdeps --populate adds local branches for all branches because those local branches are usually referred to in .topdeps files. You could change this and replace dep by origin/dep instead - however this would require all users to use the same remote location name. So without --populate you only miss the ability to run tg update successfully AFAIK. So if Hydra should run tg update then you have to use --populate. Don't think its a good idea doing so in a builder though. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Hydra - future - community
What is the long time goal? Have one hydra building the world - asking users to share costs [1]? (Maybe put it on an Amazon cloud and wait for the world to join?) We all know that NixOS/nixpgks is one of the best (if not the best) way to distribute packages today. Still I'd like to see some statements about its future and goals. Ask companies to setup their own Hydras if their nixpkgs start deviating too much from SVN trunk? Marc Weber [1] maybe its possible to calculate build and hosting resources for users and share them by users. ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: environment.systemPackages
instead. AFAIR, it is illegal to have a.b = ...; a.c = ...; in nix.
Maybe this used to be the case. My Nix can parse it:
{ a.b = ath; a.c = foobar; }
yields
{ a = { b = ath; c = foobar; }; }
I'm too lazy too lookup when the change (if so) took place.
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: How do parallel builds scale?
By the way, do you know how much hydra waits because of waiting for dependencies? I think it shouldn't be too difficult to always find something else to build on hydra, but e. g. for package maintainers Its not about keeping Hydra busy. Its about being able to deliver patched versions fast if there is a use case (eg security patches) In production systems it may matter whether you're able to deploy much faster. However using faster / more machines would have more effect than separating check phases ? Currently its not most important to me. Using stats from hydra, nix could one day estimate the build time automatically. I don't see this as a priority now, as the usual users are IMHO going to prefer binaries from hydra in most cases. If you use sources hydra uses you're fine. If you use a patched nixpgks .. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] announce: preliminary version of nixpkgs-python-overlay
Basic idea:
dump data from pypi package index.
Make Nix read the dump creating derivations on the fly:
Example:
devEnv = pythonEnv26 {
name = libs-coding-style;
# p = { pylint = [ 2.0 ]; } force pylint version being less # than 2.0
names = [ pylint pyflakes ];
};
In a similar way you could make it create dependencies for other
packages such as gimp or inkscape ..
If you install this you'll get a script which you can use this way:
bin/python-env-libs-coding-style bash
then NIX_PYTHON_SITES is defined and the package are put in $PATH
so that you can run pyflake and pylint from commandline.
Package dependencies is taken care of if the constraints are correct.
The solver will fail if two packages choose different versions of the
same package. Then you can choose either version by using a constraint
as shown above.
I haven't done too much testing yet and there are still some problems to
solve such as find out which python package works with what python
version.
Ping back if you're interested in testing packages etc.
Desigs is very similar to the python-ruby-overlay I announced earlier
doing the same for rubyforge.
repos:
http://gitorious.org/nixpkgs-python-overlay
- nixpkgs-python-overlay-dump (script dumping pypi)
- nixpgks-python-overlay-packages (a dump I made for you which will be
updated by cron job once a week soon)
- nixpgks-pyhton-overlay (the nix code doing all the stuff)
The code is based on the arbitrary-strings-as-names patch and maybe some
more things I put into my nix/nixos repositories (branches nix2/marc and
nix2/nix-python-sites)
So it won't work with current trunk.
The purpose of the dump is to abstract away the tedious task of getting
source tarballs and creating derivations. So only the manual nixpkgs
specific adjustments have to take place. (hopefully).
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How do parallel builds scale?
Hi ludo, I've seen your post (autoconf mailinglist) asking about how to scale configure scripts. I don't think there is an easy way. :( Maybe using cmake could be an option. More interesting: Have you also numbers about whether some of those builds failed due to -jX ? That was one of the main arguments against a feature like enableParallelBuilding in the past (?). And discussion stopped at exactly this point. I've seen an internal make failure for some packages ocassionally. Eg ruby19: INTERNAL: Exiting with 6 jobserver tokens available; should be 4! The build phase itself scales better, but for half of the packages the speedup is lower than 4. Many projects (eg HaXe or terraview) just don't care enough about it for whatever reason. I've had another idea in mind: Building up a database listing the resources a build takes (both IO and CPU). Then it would be possible to calculate an estimated wait time for rebuilds - or maybe it would be possible to optimize the order of builds or such. I don't care enough to work on it right now. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How do parallel builds scale?
Looking at some graphics: http://hubble.gforge.inria.fr/parallel-builds.html You plot number of packages against speedup without saying which packages you've used. Without that info the plots are useless. I mean I don't know whether the first 10 packages are python packages only and I don't know whether the 20 packages contain the first 10. IMHO you should publish either enough data so that your results could be verified or nothing. By changing the formatting a very little bit you can make the table http://hubble.gforge.inria.fr/parallel-build-details.html much more readable. Its confusing that the first row has configure, build, check but the following only have configure,build. Without asking Firefox to highlight cells I was not able to read anything. its because 2m 18s is displayed using two rows. You can enhance this easily by forcing col width ensuring that no line breaks occur or use white-space: nowrap; or such. Thanks Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Re: How do parallel builds scale?
Excerpts from ludovic.courtes's message of Thu Mar 03 22:34:09 + 2011: Marc Weber marco-owe...@gmx.de writes: Looking at some graphics: http://hubble.gforge.inria.fr/parallel-builds.html You plot number of packages against speedup without saying which packages you've used. It\xe2\x80\x99s all the packages that have been built, i.e., all those listed at http://hubble.gforge.inria.fr/parallel-build-details.html (or a subset thereof, as indicated.) That as indicated is what I haven't found. From plots I see that you've build 7 [1] packages. Now your listed is sorted alphabetically starting by 0) average (special package?) 1) 4store 2) GConf 3) ImageMagick ... so may I conclude that 1,2,3 are elements of the first subset ?! [1]: figure: the Scalability of the ?check? phase. let's me assume that the lowest blue * is at number of packages 7. Sorry, I still don't get it. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How are perl modules handled?
Excerpts from Tobias Hunger's message of Mon Feb 28 20:33:13 + 2011: fhh602 does not contain a nix-support directory at all! It should also be a perl-module, why is no such directory there? My guess: because it does not have buildInputs or propagatedBuildInputs. Thus no $out/.. is written I do not understand how that defines a link back to the perl version used to build XML-SAX. No perl package references the perl interpreter which was used to build ?! a store path. I'm not even sure you should call it build here because in most cases it will be a copy .pl files to $out only and some testing. The missing piece is /etc/bashrc or such which defines PERL5LIB for your user profile (and the system profile) Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How are perl modules handled?
Excerpts from Tobias Hunger's message of Sun Feb 27 21:50:54 + 2011: Hi there! I am having some trouble understanding how nixos handles perl module installations. Other scripting languages like python and ruby are most likely handled in a similar way. Perl is installed in /nix/store/hasha-perl-5.10.1/... A random perl module is installed into /nix/store/hashb-moduleB-0.8.15/... ~/.nix-profile merges those into one view of the system... which should allow programs using moduleB to function. Have a look at buildPerlPackage. If you have a look at both: perl-packages.nix and the builder.sh file of buildPerlPackage you'll notice that propagatedBuildInputs is used which is then written to $out/nix-support/propagated-build-inputs and propagated-user-env-packages ensuring that dependencies are always added as well. Don't miss setup-hook.sh which will make the default builder add the .pl files to the search path: pkgs/development/interpreters/perl-5.10/setup-hook.sh About Ruby: I did the initial work on it. However I abandoned it in favour of the nixpgks-ruby-overlay (see my git repos). I wrote about it in the mail talking about my work some days ago. Support is pretty good. It even fails if two libraries depend on different versions of the same ruby library. I still have to fix ruby-debug libraries for ruby-1.9 For python: current support in nixpkgs is available but I feel that using PYTHONPATH only is not enough - that's why I also maintain a private branch using an alternative implementation until I find more evidence for it. Eg .pth files are not treaded correctly. Also for my taste the pygtk implementation symlinking gtk-2.0/* to out/lib is too hacky. I've hit some cases where it didn't work for me. However wicd etc runs fine.. I'm working on a nixpkg-python-overlay importing all pypi packages. package import works but I still have to find out about dependencies and write all the nix code handling it. So how does nixos make sure that hashb is only used with the hasha version of perl? .. It only depends on PERL5LIB. And probably using this env var is best you can do. I don't know perl very well. Should it unlink hashb from the user environment once updating it to use hashc-perl-5.10.1? .. Depends on your use cases. grep nixpkgs for PERL5LIB and you'll notice that a common solution is to wrap executables defining a PERL5LIB env var for each executable so that they work without installing libs to your user env profile. Eg have a look at slimrat. If you install it into your user profile it does not also pull WWWMechanize. Was this reply comprehensive enough? Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix vs. Modules
Excerpts from ludo's message of Thu Feb 24 15:29:17 +0100 2011:
It would be fairly simple to provide a command akin to ‘module load’
that would set $PATH, etc. to point to a given profile, somewhat like
‘nix-store -r’ does.
Marc's 'myEnv' seems to do something along these lines, [...]
myEnv was meant to be for devs only to provide a quick and dirty way to
get the environment builders provide into a dev cycle (your repo
directory).
And it does that job very well.
I'm not sure that I really understood what you're looking for.
I rewrote all of the bash initialization - I wrote about the branches
recently.
I introduced a function called nix_add_profile_vars for both: bash and
zsh.
So you install a profile let's say int ~/.nix-profile/module1
you can add it to your env by
nix_add_profile_vars ~/.nix-profile/module1
This takes also care about completion etc.
Its reasonable well tested to not break your system.
Moreover it will fix the annoying run bash or zsh and your env (PATH
etc) will be reset bug.
So my user env is constructed by /etc/bash-comomn.sh (which is sourced
by /etc/{profile,bashrc} this way:
export NIX_PROFILES=$HOME/.nix-profile /nix/var/nix/profiles/default
/var/run/current-system/sw
for p in $NIX_PROFILES; do
nix_add_profile_vars $p --suffix
done
I did the same implementation for zsh.
For both Ruby and Haskell I've augmenting env vars only to work with
special versions with great success using additional derivations and
scripts.
So it may happen that reviewing my patch is all you have to do.
I've been using it for about 2 weeks now without any problems.
You need branch nix2/multiple-shell-support (nixos)
and some library patches found in branch nix2/package-udpates (nixpkgs)
source: http://mawercer.de:7000/
Marc Weber
___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
RE: [Nix-dev] Re: GConf update problem
Excerpts from Roelof Wobben's message of Thu Feb 24 19:48:29 +0100 2011: error : unknown flag --shot-trace try man nix-env. Does a flag look very very similar? Reading the first 20 lines of the man page should be enough. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
RE: [Nix-dev] Re: GConf update problem
You've been correct: This makes it find the header files. Same when using NIX_CFLAGS_COMPILE export CPPFLAGS=$CPPFLAGS $(pkg-config --cflags glib-2.0 dbus-glib-1 polkit-grant) However this change still breaks it. The used policykit 0.9 is the latest stable on the homepage. So you either have to build without policykit or get a dev version? 106c80 PolkitAuthority *auth; --- PolKitContext *pol_ctx; PolKits history shows tags beyond 0.9 0.91 probably has the change and the history talks about api rewrites and cleanups. So this means use git version which also means that you need gtk-doc which means you have do add more buildinputs .. short story: It still doesn't work but you're closer. Pushed by changes to the gnome3 branch. Now you only have to update glib (hopefully ?) If someone wants to join the update send me your ssh key. gnome3 branch can be found here: http://mawercer.de:7000/?p=nixpkgs;a=shortlog;h=refs/heads/gnome3 Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] my recent work: ruby, mercurial, zsh support more
Hi community,
You can find my recent work here:
http://mawercer.de:7000 (git instaweb)
I'm still evaluating gitorious to find out whether its the hosting
service I'd like to use for the future. I'm not sure I like the hierarchy that
you have to create projects containing branches.
So I'll delay talking about that.
For some changes you need a patched nix allowing arbitrary strings in
attr names. The nix expressions in the nixpkgs repo have the patch
applied.
Pick whatever you like.
You've seen much of this in patches I've send to the mailinglist earlier.
The .topmsg files of the branches contain more details about the changes.
Now that ruby support is done I'll also focus on Python support (pypi) again.
Enjoy
Marc Weber
TOPICS:
= overlay support:
==
reference repositories beneath nixpkgs so that you can put
huge amounts of stuff only a minority is interested in into separate packages.
Example:
overlay haskell (based on hack-nix). For whatever reason nobody is interested
in it altough I think it gets the job done pretty well
= RUBY support
==
overlays (gitorious)
1.9 (trunk because older versions ship with an too old version of rubygems eg
for hoe)
nixpgks-ruby-overlay
- spec patches + simple solver
- ruby .nix code providing ruby environments, see below
nixpgks-ruby-overlay-specs
100.000 spec dumped by a gem patch - yielding 20.000 files
Yuri: thanks for showing me how to write external ruby gem plugins
Eg the first rails example can be run.
Yes - importang all specs is crazy - it took more than a day to fetch all
hashes. Hoever when I need a library I don't want to start waiting for
something. So for now I'm done.
I may setup a cronjob updating the dump occasionally
ruby environments
-
can be defined in this way finding their deps automatically and failing
if two different specs require different versions of the same package.
You can filter the package pool to resolve this issue, see
example definition for a rails env [1]. The result is a shell script
setting PATH, RUBYLIB and GEM_PATH. Example usage:
ruby-env-rails bash # start a new shell with ruby and ruby libs in env
Optionally tag all libraries so that you can lookup symbols fast (TAG_FILES
will be exported the same way it was done for hack-nix)
However to make this work I had to patch /etc/bashrc (- multi shell patch)
attention
-
my nixpkgs patches also remove the current ruby-libraries provided by nixpkgs
favoring the overlay which you may think means adding more bloat than value ..
= multi shell patch
===
I love zsh and I wanted a way to add some unobstrusive shell code to all
accounts easily. So I refactored /etc/bashrc and /etc/skel/* files.
The result is:
- /etc/* files only define PATH because without that nothing works on nixos.
- some unobstrusive opt-outable bash completion support (eg upstart)
- In zsh the nix PATHs are defined properly
- nixos options:
* supportedShells
enable zsh support by setting it to [ bash zsh ]
* interactiveShellInit
code to sourced by ~/.bashrc ~/.bash_profile for interactive shells
So I moved some code from /etc/bashrc to user files because /etc/*
files can't be changed by users so they should contain a bare minimum
only
* shellInit
always sourced. Keep it to a minimum. Should define essential env vars
only
You can assemble shell code snippets this way now:
[ # some code
{ bash = # bash only code;
zsh = # zsh oly code;
}
# some more shared code
]
Maybe this is overkill - but it should scale well.
also adding
/etc/skel/.nixpgks/config.nix # demo file
/etc/skel/.vimrc (comment only to make vi startup as vim nocomp)
= mercurial update plugin support
===
put in your config.nix and be happy:
mercurial = {
atticSupport = true;
guiSupport = true;
pbranchSupport = true;
hgsubversionSupport = true;
mqSupport = true;
histeditSupport = true;
hgextconvertSupport = true;
collapseSupport = true;
record = true;
};
= nixos postfix update 2.8.x
- version bump because current version is (very?) outdated
- fixed restart postfix
- added some map abstraction so that you can setup virtual accounts easily
details see .topmsg
= misc
=
various smaller fixes or updates including:
adding:
umtsmon
smlnj
tinyproxy
ziproxy
fish shell
linuxtv_dvb_apps
fixing / updating
bash upstart completion
nvi
buildenv.pl: fix some cases viric discovered
wvdial
opera (add support for gtk/ qt, ..)
builderDefs: add parallel building support
sourceAndTags: ruby support
texLive: remove man. It was broken anyway and it shadowed the man
Re: [Nix-dev] Orbit.nix question
Another hint: pkg-config is usually run by configure. Or run pkg-config --list-all once. The output depends on env vars which is populated by build dependencies in nixpkgs. For details see man pkg-config. Marc Weber ___ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
