Re: [Nix-dev] Unfree packages in Nixpkgs
> How do I pass "allowUnfree = true" to nix-repl, so that it lets me evaluate
> unfree expressions?
system:
configuration.nix:
nixpkgs.config.allowUnfree = true;
user:
~/.nixpkgs/config.nix:
{ pkgs, ... } : {
allowUnfree = true;
}
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Unfree packages in Nixpkgs
While I appreciate that things are simple I'm sure we can do even better: nixpkgs.config.allowUnfreePackages = ["skype" "ati"]; or simply "all" or true to allow all When setting to true you still may get "new unfree" software unnoticed. Would you mind thinking about whether having such an explicit white list would be more valuable than just using "true/false" ? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Accidental force push to nixpkgs
solutions: 1) push to another repository which allows seting up hooks, then sync to github/nixos 2) don't preven this when pushing, prevent when pulling by: git merge --ff-only or .git/config: merge.ff [..] When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line). Using Google did not reveal more options to me. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] versionedDeravation / php fpm / cups 1.7
Excerpts from Domen Kožar's message of Mon Apr 07 17:31:58 + 2014: > As soon as we allow more than one design pattern for sharing code between > packages, package in my use cases means "having same name and having most build instructions be the same". We do already have "sharing" for different "systems", eg src = if system = "X" then fetchurl else fetchurl .. Eg eclipse case. > I'm OK with versionedDerivation, if we come to consensus it's better than > current approach and someone ports current codebase to use > versionedDerivation. That's not what I'm asking for: (rewriting code). The main request is: Is it worth thinking that much about such small things if such patches fix real world problems people might suffer from. I want to achieve the goals with reasonably low effort - thus do what works fastest. If we can imagine that this happens on this own - there is no reason to fear that there is a maintenance burden - because if there is one it'll be refactored (because contributors want to be done fast, too) > TL;DR: having more than one way to share code between packages Thus you'd vote for "mkDerivation" and setup.sh being the only sensible ways to share code ? :) Just trying to illustrate that its hard to define what one labels as "shared code". > burden to maintenance We should talk about specific cases, not about "general things" which are hard to grasp. Please keep in mind that you cannot prevent programmers from shooting themselves into their feet - no matter what you do. The question I'm asking is: Am I doing this is the cases I provided and for what reason - and which kind of gun am I using (soft balls or missiles). Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gnome 3 suport
Hi Roelof, I have a "deja vue", Is it true that you asked this in 2011? We have "gnome" expressions in nixpkgs, because gnome libraries are used by some applications which compile and work (eg network manager or such). I'm unsure about whether gnome desktop is supported now. I think its still not (please correct me if I'm wrong). Thus try to clarify whether you're talking about gnome libraries or the gnome desktop. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hash Collisions
Excerpts from Raahul Kumar's message of Tue Apr 08 03:11:03 + 2014: > Thanks Marc, Kiril. Is there a way to create packages such that they don't > provide redundant files? It's a waste of bandwidth to download a file, > then be unable to use it because there is already a copy there. I guess > deduplication is what I am looking for. I'll give you another useful tip: If you want to "save bandwidth" then switch to binary distro. While nixos has had the ability to create "binary differences" I'm unsure wether its activated/available at the moment. It was disabled in the past. Maybe somebody else can comment on this. Also "waste of space/bandwidth" always happens because: - nixos always ships with header files for all libraries (this could be fixed because nix supports multiple outputs) - if you replace "coreutils" you'll have to download everything, not just coreutils To sum up: You're talking about having some man files twice (which should not take much space if they are compressed). Thus I don't think the effort/value ratio is great if you start fixing things at that level :( - We still use nixos because we think the values nixos provides (atomic updates, deterministic distributed builds) are more important to us. Anyway: Welcome to nixos :) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hash Collisions
Excerpts from Thomas Bereknyei's message of Mon Apr 07 13:48:45 + 2014: > I have seen these collisions as well, but I do not understand them. They > don't seem to have a detrimental effect on anything. Let me explain: nixos builds a "system profile". Eg ls -l /run/current-system/sw When two packages which get linked to that directory provide the same file (see your log) - then collisions happen. Now its up to you to review / change order to make the difference which man page will be opened for instance. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] versionedDeravation / php fpm / cups 1.7
(otherwise its
the wrong tool)
discussing versionedDerivation - arguments
==
In https://github.com/NixOS/nixpkgs/issues/1957 Eelco Dolstra described
what he "dislikes":
== QUOTE
My main objection to versionedDerivation is the wackiness of
having package functions that take the version as an argument,
i.e.
{ stdenv, fetchurl, version ? "5.3" }:
versionedDerivation "cups" version { ... }
There is nothing about the function interface that tells you what
the valid values of version are, and thus what versions are
supported. What you should do is return an attribute set
containing the supported versions:
{ stdenv, fetchurl }:
{
php_5_3 = ...;
php_5_4 = ...;
}
Of course, you can factor out the commonality between versions any way
you want, e.g.
let
makePHP = common: stdenv.mkDerivation ({ ... } // common);
in {
php_5_3 = makePHP {
name = "php-5.3.50";
src = fetchurl { ... };
}
...
}
Alternatively, you can have separate files for each expression
that include a file common.nix for the common stuff (like we do
for the Linux kernel).
== QUOTE END
I agree that it does make sense to "docmuent" which versions are
"supported".
The easy answer is:
The default version is documented in the argument list, the others
just mean "can be build - or there has been a time where it did build"
unless they get referenced somewhere (most likely in all-packages.nix,
see php5_3fpm example above. Whether this should be documented this way
is another story.
=> I've created a new page:
https://nixos.org/w/index.php?title=Open_issues:maintenance_properties_of_a_package&action=submit
Documenting wich packages are how well supported is an open issue
IMHO. This just is "yet another way".
The pattern Eelco Dolstra is discussing is used in different context
and with some varation, eg in python-packages.nix:
python-packages.nix takes as arguments:
{ pkgs, python, lowPrio }:
Thus while its not taking a version, you still have no idea which
python you may pass (or python versions ..) - thus IMHO its not that
much differing :)
A similar argument could be applied to "systems". (eg darwin vs
x86_64 i686):
php."5.3"."darwin" to indicate its fine to be used on darwin.
From this point of view there is not that much wrong by
versionedDerivation, the only change neccessary would be making it
return all versions as attrs so that such usage would be valid:
phps =import php/default.nix;
php_5_3 = import php/default.nix { }."5.3.x";
php_5_4 = import php/default.nix { }."5.4.x";
Thus does it differ that much from [Example 3] above which looks like
this:
php5_3fpm = php5_3.override { sapi = "fpm"; version = "5.3.x"; };
How would the "perfect PHP nixpkgs implementation" look like?
let commonConfigureFlagDescription = [ long list .. ];
let phpDerivation = { commonConfigureFlagDescription, version,
src_md5_hash, patches ? [], allowFastCGI }: {
// the common code merging the options
}
mergexdebuglikestuff = php: php // {
xdebug = ..
acp = ..
... = ..;
}
phps = {
php5_2 = mergexdebuglikestuff (phpDerivation {
long list of options
});
php5_3 = mergexdebuglikestuff (phpDerivation {
});
php5_4 = mergexdebuglikestuff (phpDerivation {
});
php5_5 = mergexdebuglikestuff (phpDerivation {
});
}
In the end is it that much more readable than what I already have?
Link -> [Example 3] PHP above
I totally agree that I should refactor if newer versions happen to be
totally different - it just didn't happen that way (yet) could be
cause I've been lucky though.
Can you reply if you have new arguments about why versionedDeravation
is nice/bad so that we get a comprehensive list and that I understand
which is the best way to rewrite those patches ?
Also ping me if you're interested in testing either patch.
Thanks for helping me gain awarness .. :)
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Repo for incomplete/unmaintained work
We've had some discussion, my proposal was: Add a marker such as "unmaintained-since: ..." then remove after 6 month or so. Due to the "since" you know exactly what to remove. The hard thing is to define what it means to be "maintained or unmaintained". Thus you could also introduce markers such as maintainance-levels = [ "gets-updated-within-a-week-if-new-version-appears" "somebody is reviewing code" ".."]; Not sure whether it would make sense. Whether such code gets moved to another repository or not - which is the benefit/ difference from having a simple wiki page "unmaintained packages for nixos/ can be found in nixpkgs git history"? Then at least google finds it .. No idea. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maven support in nix
Excerpts from shacka's message of Sun Apr 06 20:51:22 + 2014: > is it possible to build maven project as nix package? Not at all. Maven has its own dependency management, and nobody has worked on porting this to nix (AFAIK). Existing solutions (non Java): - cabal2nix (cabal descriptions to nix) - py2nix (or such) same for python - ruby2nix (or such ) same for ruby -hacknix/nixpkgs-ruby-overlay (they convert hackage/rubyforge to a pool which gets translated to .nix files, derivations get created by functions on the fly) some time age there was announced some work /question about bundler support (ruby) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Language integration (Was: NiJS package manager)
Excerpts from Matthew Sackman's message of Wed Apr 02 11:18:32 + 2014: > But I'm not sure we're disagreeing, or actually talking about the same > thing. So if I've misunderstood, please do say! But in the end in which way does nix differ from rpms or homebrew etc? Nix allows having multiple versions of the same package, except that there is not a big difference.. That's why once you can generate nix derivations it should be possible to build rpms eventually. Of course for the "nix store" programs are more likely to work due to the "every tool knowns about its own dependencies" strategy. So of course we basically do agree. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Please think the other way round: - most linux distributions (exceptions LFS I know about) want to install packages Some packages (such as gnome) have dependency information, but only encoded in "configure" scripts or READMEs. Rubyforge and PyPi (don't know what's current in python community) do have some limited readable information. At least my nixpkgs-ruby-overlay is based on it. Thus maybe there is a way to convert dependency information rather than duplicating the work. Even omitting "dependency information' - just knowing about the latest stable version - would make it easier to keep nixpkgs/NiJS/guix up to date IMHO. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
Excerpts from Matthew Sackman's message of Tue Apr 01 11:12:32 + 2014: > I'm guessing that the mechanical "let's attempt to translate > $language-specific-deps-file into nix" has been tried and found wanting? > I can see there's the node-packages-generated.nix, and others, but is > that approach appropriate to all such languages? @Matthew: I think python in the past has had an option to determine the "depedencies" at runtime. ruby solves this by having different gem specs for different targets (JVM, ruby, operating system) Haskell has a very complicated configuration system called "cabal" which allows conditional descriptions such as: flag is_windows executable foo dependencies: if is_windows: lib-a else lib-b We should not be against a new option, we should think harder about collaborating so that all targets will work - which one is the best fit for use cases - future might tell. guile -> ecma script: The difference is that guile has to compile everything to JS. AFAIK what Sander suggested is having the js interpreter only read some of all .js files - just enough to compile some packages (like nix does). Anyway - if Eelco decides on "switching" - I'd like to remind that less important policies might not be important at all :) Do we have any idea how much time nix spends on "blocking IO" ? I guess this would be interesting to know .. I know there is some benchmarking code .. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NiJS package manager
> http://sandervanderburg.blogspot.com/2014/04/asynchronous-package-management-with.html > I have discovered that the Nix expression language is complicated and > difficult to learn. Like Haskell, it has a solid theoretical foundation > and powerful features (such as laziness), but it's too hard to learn by > developers without an academic background. What is this based on? Which is the "async" problem you were faced by using Nix? Thus which problem are you going to solve ? I personally have use cases in mind such as querying a server knowing about all ruby/python/haskell/perl/your-language-X packages - so that we don't need to distribute 50.000 package descriptions (rubyforge case) or similar. But anyway: We have 3 solutions for describing packages: nix, guix, nixjs Thus eventually its time to think about which information could be shared. Who would join a "software version documentation" project allowing people to upload "the most recent version of my software is X, and it requires Z, FOO, BAR" ? Then some nix, nijs, guix packages could be derived automatically (like haskell, ruby, xorg, .. packages). And all the other package systems such as debian could benefit eventually, too. Thoughts? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] rdesktop update (94591762fed8344) broke virtual box remote access?
Lluís Batlle upgraded due to copy paste issues, but thereby broke
virtualbox access.
http://sourceforge.net/p/rdesktop/bugs/369/ could be a related bug
report (didn't test)
(http://www.pclinuxos.com/forum/index.php?topic=124711.0 talks about
virtualbox containing a rdesktop-vrdp (does anybody know about it?)
The changes below make rdesktop versions 1.7.1 18.1 and svn version
accessible, the trunk version still suffers.
For me just sticking to the old version is enough.
I don't want to spend much time thus this note only.
{stdenv, fetchurl, openssl, libX11, versionedDerivation
, automake, autoconf, libtool
, version ? "1.7.1"
}:
versionedDerivation "rdesktop" version {
"1.7.1" = rec {
# connects to virtualbox
configureFlags = [ "--with-openssl=${openssl}" ];
pname = "rdesktop";
version = "1.7.1";
name = "${pname}-${version}";
src = fetchurl {
url = "mirror://sourceforge/${pname}/${name}.tar.gz";
sha256 = "0yc4xz95w40m8ailpjgqp9h7bkc758vp0dlq4nj1pvr3xfnl7sni";
};
};
"1.8.1" = rec {
# + fixed some copy paste for viric
# - does not connect to virtualbox
# (http://www.pclinuxos.com/forum/index.php?topic=124711.0 talks about
# virtualbox containing a rdesktop-vrdp
# http://sourceforge.net/p/rdesktop/bugs/369/ could be related
pname = "rdesktop";
version = "1.8.1";
name = "${pname}-${version}";
src = fetchurl {
url = "mirror://sourceforge/${pname}/${name}.tar.gz";
sha256 = "0il248cdsxvwjsl4bswf27ld9r1a7d48jf6bycr86kf3i55q7k3n";
};
configureFlags = [
"--with-openssl=${openssl}"
"--disable-credssp"
"--disable-smartcard"
];
};
# "svn" = {
# does not fix it
# # REGION AUTO UPDATE: { name="rdesktop"; type="svn";
url="svn://svn.code.sf.net/p/rdesktop/code/rdesktop/trunk"; }
# src = (fetchurl { url =
"http://mawercer.de/~nix/repos/rdesktop-svn-1789.tar.bz2";; sha256 =
"2db48c0ea5a6122e29f5d32af9045c9f1cc76eb7033ef4035a2296f2254c8b9a"; });
# name = "rdesktop-svn-1789";
# # END
# buildInputs = [ automake autoconf libtool ];
# preConfigure = "sh bootstrap";
# configureFlags = [
# "--with-openssl=${openssl}"
# "--disable-credssp"
# "--disable-smartcard"
# ];
# };
} {
buildInputs = [openssl libX11];
meta = {
description = "rdesktop is an open source client for Windows Terminal
Services";
};
}
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ntp monlist ddos vulnerability
Excerpts from Mathijs Kwik's message of Mon Feb 24 16:27:58 + 2014: > Our ntpd version (stable, 2011) contains a feature called 'monlist', > which is enabled by default. This feature has recently been abused by > huge ntp-amplification ddos attacks. I'd say its a strong reason - so at least make it "opt-in" and document it (or do what you proposed) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Fixing module arguments (PROPOSAL MAY BREAK EXISTING NIXOS CONFIGS, PLEASE READ)
Why can't we introduce a config.args which gets merged into the attrs to
be passed?
This would not break pretty much everything still make it possible to
pass additional args in two ways, via {, ...} and config.args.
This would be kind of mixing "traditional approach" with "use config"
only - by allowing both ?
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] lens 4 transition plan?
You're right, hack-nix assumes that there are too many variations of building packages, which is why it allows to change "flags" for individual targets. You're right, there are no "binary caches", but once a dependency got compiled its likely to be reused for other projects, most libraries get compiled fast once you have ghc - and ghc is the same .. hack-nix provides another nice feature for "power users" (like you claim to be one): it generates tags for all depedencies, thus you can jump to source easily - eg map or sequence or whatever you use. There are pro/cons. Of course do whatever you feel happy with :) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] lens 4 transition plan?
Excerpts from Gergely Risko's message of Wed Feb 19 10:04:22 + 2014: > Asking this, because having both lens3 and lens4 can cause some > instances to be provided multiple times and that causes some pain. I > just ignored linear for now in my system, but I really would like to > minimize the timespan of the situation where half my packages depend on > lens3 and the other half on lens4. :) If this continues to be a problem you can give hack-nix a try which was written for such cases (there are some other small issues, though). If you can point me to source of some sample packages I can tell you whether there are problems. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-shell NetworkManager
Excerpts from Sergey Mironov's message of Sun Feb 16 19:08:40 + 2014: > > What may go wrong? Who are in charge of reading the NIX_CFLAGS_COMPILE? gcc is wrapped (but eg cpp is not [1], because usually its called by gcc). Some build systems drop env vars (eg scons by default did so [2]). Who is in charge? I don't know whether there are policies. [1] didn't recheck whether its still the way it was. [2] http://comments.gmane.org/gmane.linux.distributions.nixos/4969 (unsure about what is current, didn't recheck) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Using Nix to manage dotfiles
About bash/zsh: I once had a patch (still using it) which has some support for opting in/out from bash/zsh features. The main thing was adding source /etc/bash/setup-all which serves as example. This way users get updates (this is nicer than having a symlink, because users can edit easier). For .vim you can can use "source otherfile.vim", too. Then users can opt out (maybe even temporarely). You can be even smarter: if $NIX_DEFAULTS == yes source .. endif then users can opt-out/in by controlling NIX_DEFAULTS .. Please note that vim plugin support is still week in nixos. The perfect upstream would be joiniing bitbucket.org/vimcommunity/vim-pi and use that as source. Then there would be about 5000 plugins of which only some would be used ... (?) vim-addon-manager does apply some manually patched magic to move some files into the correct directories or setting a subdir to be the runtimepath. Duplicating it can be done, it might be worth it - but would take some time. If you want to do it talk to vim-pi team (eg by creating issues) http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html shows all options about managing plugins which are known to me in some way. Eg NeoBundle and vim-addon-manager both allow lazy loading of plugins as needed. https://github.com/MarcWeber/vim-addon-manager (Those are just some thoughts ..) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to install in NixOS in a KVM virtual machine?
Qemu is a common backend for KVM, isn't it? There you can attach disks created by qemu-img. Then you can attach cdroms. Eg qemu-system-... -hda img -cdrom image.iso Then you can install as usual. The -hda might be too simple, nixpkgs/nixos has some tests illustrating how to attach (so that grub finds disk position - eg have a look at qemu-vm.nix kvm or VirtualBox? Depends on the features you want. VirtualBox traditionally has better graphic support and special drivers allowing to share clipboard, resize screen and the like (no idea whether kvm followed this). Thus if you care about gui VirtualBox could be the better option for that reason (You cannot have kvm and VirtualBox at the same time AFAIK - maybe this changed). Except the default installer iso you can try minimnal install archives etc, see "installing nixos @ XY" guides at the wiki, they are official. I have inofficial minimal install archives, they could be easier to use but might be broken at the moment (and less well tested). At least this mail should help you find out what you're missing exactly. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Bluetooth support - nixos
I'd like to connect my smartphone with internet via laptop hostapd fails: Feb 06 14:50:17 nixos hostapd[9780]: wlp5s0: STA 00:23:76:de:48:8e IEEE 802.11: authenticated Feb 06 14:50:17 nixos hostapd[9780]: wlp5s0: STA 00:23:76:de:48:8e IEEE 802.11: associated (aid 1) Feb 06 14:50:17 nixos hostapd[9780]: wlp5s0: STA 00:23:76:de:48:8e RADIUS: starting accounting session 52F3930...01 Feb 06 14:50:17 nixos hostapd[9780]: wlp5s0: STA 00:23:76:de:48:8e IEEE 802.11: disassociated Feb 06 14:50:18 nixos hostapd[9780]: wlp5s0: STA 00:23:76:de:48:8e IEEE 802.11: deauthenticated due to inactiv...EMOVE) (maybe driver or hardware issue?) Has anybody tried creating a bluetooth network successfully ? blueman: (gtk frontend), but its broken since 2 obex versions [1] And there is bluedevil (requires kde). Has anybody some experience and can hint me what to try first? Marc Weber [1] I guess it would be easy to fix obex readme contains this hint: Upgrading to version 1.6 The function OBEX_FindInterfaces is replaced by the functions OBEX_EnumerateInterfaces() and OBEX_GetInterfaceByIndex(). ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Please explain grub installer
Excerpts from Sergey Mironov's message of Tue Feb 04 12:04:45 +0100 2014: > >From the perl side, ./install-grub.pl reads ARGV[0] and ARGV[1]. > ARGV[0] turns out to contain the path to XML. OK. And ARVG[1] contains > a mysterious config. AFAIK it should point to the folder with kernel, > initrd and others. But where does it come from? Nix has "state", too. That state is history of previous nixos-rebuild boot/switch runs. That state is recorded in /nix/var/nix/gcroots/profiles/system* or such Those previous installations get passed or are read by the perl script. They get turned into the grub menu. The older bash script also has had "sub configurations" which broke when the script was rewritten in perl. Now those system links contain everything which is needed to make up the system: - the kernel - the system environemnt - the configuration name - .. It should be trivial to follow nixpkgs/nixos/* and grep for the perl script usage. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gutenprint cups drivers
I forgot to say that the only reason why you may need my patch (newer cupsd) is that the old cups version stopped printing at 30% of a page randomly - the rest of the page was blank. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gutenprint cups drivers
For whatever reason it happened that I symlinked gutenprintCVS ppds but
was using gutenprint filters ..
Patch updated:
https://github.com/NixOS/nixpkgs/pull/1120/
This should be pretty much all you need
printing = {
enable = true;
gutenprintPackage = config.services.printing.cupsPackages.gutenprintCVS; //
or .gutenprint
};
See description:
gutenprintPackage = mkOption {
default = null;
description = ''
Enable gutenprint by setting this options to
config.services.printing.cupsPackages.gutenprint(CVS).
Unless this setting is null (default) gutenprint.ppds will be symlinked
to /run/current-system/sw/ppds/.
When installing a new printer in cupsd web interface select the matching
ppd file.
'';
};
There might still be "style issues" (depending on view point) with this
patch .. but works for me.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Gutenprint cups drivers
Excerpts from coroa's message of Sat Feb 01 22:37:10 +0100 2014:
> there are the packages gutenprint and gutenprintBin.
Bin in the past contained more recent drivers.
My branches (github.com/MarcWeber) know how to compile gutenprint from
source. However to use eg canon pixma you also need current cupsd (based
on PDF transformations rather than PS) - but I only did enough work to
make my printers work - eg printing sample pages does not work yet with
newest cupsd.
The reason I had to package CSV version is no longer valid for me,
current source distribution contains everything I need - however
building was a lot of fun (work) .. so I still keep it around.
(I also created a pull request for that reason).
In order to use gutenprint you should also create ppd files.
(in my branches [1] they'll get symlinked to /run/current-system/sw/ppds/*)
and they cane be accessed by gutenprint.ppds (-A attr path)
> Unable to find Gutenprint driver named "Canon PIXMA MG5200"!.
And I'm getting such error recently, too (with Canon PIXMA MP980 for
instance).
No idea when /why it broke yet. I'm about debugging it - its not a high
priority - I don't print much.
cupsd.conf setting
LogLevel debug2
might help.
Marc Weber
[1] github.com/MarcWeber/nixpkgs branch experimental/cups-1.6-and-1.7
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
And when to remove unmaintained lines? After yet another year or so?
unmaintained "git-hash" "package-name" "2014-jan"
^^ so that you know when to remove that
line?
^ you may want to catch the install by name case
^^ you cannot instert it, you have to use the git hash
before that one
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Excerpts from Alex Berg's message of Wed Jan 29 03:57:56 +0100 2014: > Rather than removing unmaintained packages, can we make them available as a > separate, opt-in channel? Then they will bitrot even faster - because you have to test much more. It would be possible, I've been using kind of overlays for a long time (for haskell and ruby packages packaged "my automatic style") But also see below, git history will be available always .. @Jan Malakhovski >For what it worth, I think unmaintained packages should not be removed >just for the sake of it, especially when/if their nix-expressions are >nontrivial. Don't forget that history will always be accessible by using git search. But I agree that its easy to miss that. Its non trivial to estimate how much complicated packages (let's say openoffice/libreoffice for instance) also change while packages are broken. In the open office / libre office case open office was broken too, but the fix was not to fix open office but to switch to libre office. There are so many reasons that it does make sense to remove packages after some time (maybe 6-12 month) which is why its important to declarate since when they were broken. At least that's what I think. The more interesting question is whether we should try to keep all tarballs mirrored, so that you at least have a chance to install the old versions which worked once .. - Again nice users statistics would help determining which source archives to keep. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Excerpts from Eelco Dolstra's message of Tue Jan 28 18:21:57 +0100 2014: > It should be possible (if somewhat tricky) to gather this information from the > logs of cache.nixos.org (at least for those packages that are actually in the > cache). You'll get cache hits for "trying packages" - but we need hits for "usages". But you're right that that could be a starting point, too. I just think that its very important to understand what gets used, too. About debian and dropping: Right, If something does not work it should be dropped. I just think its nice to have some guaranteed time to fix as well as some hints that packages are broken. Whether a package gets removed 3 month earlier/later doesn't matter as long as it gets masked and then removed. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Maintainership
Excerpts from Shea Levy's message of Tue Jan 28 16:36:39 +0100 2014: > Thoughts? I'd try such: 1) replace broken = true by broken_since="date"; (Even maintained packages can be broken - and if they don't get fixed within 3-6 month they can be "unmaintained" this way. 2) send reminder to use the script to upload app usages (maybe quartely by mailinglist) 3) one month after the reminder was sent packages which are still broken and were broken for more than a month. Think about whether unused (but non broken) packages should be removed, too. Thus I'd send the maintainers a list of packages they maintain once a year, too. Then they can think about which ones to drop eventually. Its hard to define "high quality" - eg do we expect maintainers to review code, too? ... Maybe it does make sense to think about having different maintainance modes such as: - important - people depend on it - issues will be fixed fast and updates will be made, too? - not important, will be fixed if there is time. The real solution is to start a repository about source versions so that maintainers can upload references to their source tarballs with changelog - also introducing flags such as [this new version fixes a security issue] - then maintainers (also from other distros) could be notified automatically rather than thinking that maintainers will poll homepages regularly .. (which I don't do for most packages I created once).. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Pulling a programs source code from a git repo
In theory git hash should be enough, however nobody implemented a githash=".." attribute for fixed builds. Thus nixprefetchurl can be used. I personally wrote "nix-repository-manager" which runs git clone/pull in a local directory. This way updating is "faster" if there are only some updates, and you can update multiple repositories at the same time. Eg I've assigned all "gimp" related repositories or haxe related repositories to "gimp_group" or "haxe_group" and update them in parallel by: nix-repository-manager 2 . --update-then-publish gimp_group haxe_group (update-then-publish updates archives and uploads them to my server) Downside is that you explicitly have to upload the tarball somewhere. grep nixpkgs for "REGION AUTO UPDATE". A second downside is that requires more "trust" to trust such archives :/ So yes, I really should update it one time to output fetchgit lines instead .. You may also want to have a look at this wiki article which should be related: https://nixos.org/wiki/Open_issues:ways_of_updating_sources_automatically Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Is NixOS a practical proposition for me?
> gnome I tried once, worked 2-3 days on it without getting close (but that time it was shortly before release 3). Updating kde also took quite a while. So it is a lot of effort. Package sources can be derived from gnome ftp servers easily. Figuring out about dependencies and eventually patching due to store paths would be most work. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how to overwrite a derivation in nix
option 1: use ~/.nixpkgs/config.nix, see wiki "how to keep multiple
packages up to date" or such.
option 2: use applyGlobalOverrides
problem: its not exposed by pkgs AFAIK
option 3: when importing nipkgs pass config.nix (like option 1)
option 4: use deepOverride (see lib.misc.nix)
Then it would look like
something_having_thunar_as_dep.deepOverride {
thunar = patch-thunar-here
}
Now it looks like you don't want to "override", instead you want to
reuse a build and add a patch only giving it a new name, this is done by
overrideDerivation found in lib/customization.nix
thunar is in xfce/core/thunar, and no top-level in all-packages.nix
and eg ./pkgs/desktops/xfce/core/xfdesktop.nix|2| depends on it.
Thus you might need any of the deep overriding methods listed above if
you want packages to change depending on it.
Eventually the most simple thing is to create a git topic branch and
just apply your change.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Cinnamon quitting
Excerpts from Roelof Wobben's message of Sat Dec 21 19:45:59 +0100 2013: > Because I do not get Cinnamon work because of the error I mentioned > I forced to quit this project. If you write such a message a) reference "the error you couldn't get to work" b) Rethink whether Cinnamon is most important to you. c) If it is, rethink whether you have to give up "on this project" (whatever you mean by that) - eg you can happily install the nix toolchain on ubuntu - thus get both - or install Cinnamon in a chroot etc. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Automatic makeWrapper
Excerpts from Tomasz Kontusz's message of Thu Dec 12 22:35:15 +0100 2013: > Would a system like this be useful, and is the proposed API sane? API no idea, nixpkgs-ruby-overlay has been using such for long to automatically make all bin/* ruby packages find their dependencies. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how to proceed the best
Excerpts from Roelof Wobben's message of Sat Dec 07 15:03:00 +0100 2013: > Oke, > > I can try this way but I do not fully understand how it works. > > How can I make a branch that depends on x-updates for example > cinnanmon-desktop # make sure a local branch exists: git chekcout -tb x-updates origin/updates # checkout the branch you want to depend on: git checkout x-updates tg create topic/cinnanmon-desktop # write the topic contents (what you want to do into .topmsg) Keeping up to date: 1) update local branch git checkout x-updates && git pull 2) update your topgit branch git checkout topic/cinnanmon-desktop tg update (follow instructions) How to Export, thus feed upstream? to export topic/cinnanmon-desktop Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how to proceed the best
You can automate following one or multiple branches by using topgit. I've added a wiki article long time ago: https://nixos.org/wiki/Nixpkgs_and_TopGit Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mozjs problem
nix-shell can be used to run a shell in build environment easily. pkg-config --list-packages or such shows all known packages. grepping configure or configuer.in or such for the package may tell you which exact version is expected. This can help improving your understanding. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] mozjs problem
Add pkgconfig, man pkgconfig tells you about PKG_CONFIG_PATH variable.
nix-build -A pkgconfig -> nix-support/setup-hook
adds env hooks which get run by the standard builder:
addPkgConfigPath () {
addToSearchPath PKG_CONFIG_PATH $1/lib/pkgconfig
addToSearchPath PKG_CONFIG_PATH $1/share/pkgconfig
}
envHooks=(${envHooks[@]} addPkgConfigPath)
Thus adding pkgconfig to buildInputs should be enough.
The standard builder script is worth looking at and remembering:
./pkgs/stdenv/generic/setup.sh
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardened NixOS
Yes, start the wiki page. Don't forgett that nixos has the "nesting" features for builds. Thus you can build i686,x86_64 and hardened/not hardened systems at the same time. Ther is not much which can go wrong other than that you have to download nix* stuff twice. Its on my todo list to improve the perl based grub builder to allow such showing such 'sub-systems' in the boot menu again. The feature already was there when the bash builder script was used. Might take some time till I manage to do so. Having a very short writeup about - feature -X description see link foo potential issues: .. would be perfect. Why do you fear people disagreeing ? Let me rethink: there are 3 types of tools I use most: - browser (This will not be hardened for JIT reasons?, this could benefit little) - email (this could benefit a lot) - editor (I trust scripts anyway) - web servers (this could benefit, unless I use nodejs ..) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Hardened NixOS
> Securing nixos I guess we all want to be secure :) I'd also like you to start a wiki page talking about - what could be done - what you want to be done - how to verify that the goal has been achieved (if this does make sense) - what else could be done to have a secure system .. - how to detect that a "secure" system was hacked (or what do you try to protect against ?) > NixOS doesn't have many users, and hardened NixOS would have even less of > them, then perhaps this is not necessary at the moment... Maybe you should also try to tell us why some people of us would not like to adopt your changes, eg are there obvious downsides /limitations of the changes you propose ? My two cents Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how much disk do I need ?
> Sorry for maybe a stupid question but what is a VDI. > Im installing NixOs on a normal harddisk. Its a virtual disk image used by Virtual Box. Sorry, looks like I didn't listen properly. By the way: btrfs supports compression, thus eventually this can help reducing required disk space, too. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] how much disk do I need ?
Excerpts from Roelof Wobben's message of Sat Nov 16 10:59:56 +0100 2013: > I will make a partition of 30G. I have a disk of 70G so no problems. > I have a problem with installing NixOs but therefore I made a issue (bug). A VDI will grow and only use as much blocks as the operating system (nixos) has written to. Thus even if your partition is 30G its unlikely that you need that much (at the beginning ..) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wiki spam
Well done (Thanks!). Pressing random page link 10 times only showed 'nix' content this time. > Please make sure that when you add a page, it is linked from another article. This is mentioned here: https://nixos.org/wiki/Contributing briefly now. > help .. I'd like to prevent spam rather then deleting spam. Thus if If there are still problems I'd like to implement what I proposed. The proposal is mentioned on this updated page: https://nixos.org/wiki/TODO_-_Cleaning_up_wiki_spam It was about introducing a custom cookie which must be set in order to see the standard registration/login forms. That would be set by redirecting to a simple form whose action would set the cookie. Thus if there are still problems please let me know. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Enabling CUPS unconditionally allows UDP/631 on the firewall
Excerpts from Eelco Dolstra's message of Wed Nov 13 11:47:32 +0100 2013:
> Well, only the administrator can enable the sshd service, anyway. The
> question
> is whether it's reasonable to expect that enabling sshd also opens port 22.
Whatever being open means (outside/inside/..)?
The perfect setup tracks
- which ports apps should be listening on
- which ports no apps are expected to listen on
There should be a script telling about both
This could be used for monitoring, too.
If you don't expect port to be used and it is used then you want to
investigate..
Eventually you want to allow access only from some ips etc. is on/off
enough? Or do we need more control? I remember having read about tools
which allow access to ports if you "unlock" them by accessing other
ports in a certain order and the like.
Thus eventually creating an attr set like this could be useful:
usedPorts = {
// don't allow two services to use 9981. Thus if {port}.udp.by gets
// set twice cause configuration failure.
9981.udp = {
by = "tvheadend";
allow_from = "127.0.0.1/32";
}
9982.tcp = {
by = "tvheadend";
protocol = 'http';
allow_from = "127.0.0.1/32";
}
}
Then admins can create their own "whitelist" easily by using assertions
and by accessing usedPorts ..
Moreover it would protect against starting two services accessing the
same port by accident. And by introducing "protocol" it would be
possible to define http proxy chains in a "type safer" way.
Eg if apache gets configured to access localhost:8080 but no service is
connfigured to use that port this could be made an early failure
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Help Testing New Package
Excerpts from Alex Berg's message of Wed Nov 13 01:59:24 +0100 2013: > How can I test the package I created in my fork of NixPkgs? nix-build -A name location-of-your-fork/ (default.nix will be used which loads all-packages.nix) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Enabling CUPS unconditionally allows UDP/631 on the firewall
A more complicated way would be introducing use cases such as - home (safe network) - public (unsafe network) which changes defaults. But that would come with its own set of issues. Thus I agree on disabling such features unless they are mandatory for a service to function. Everybody can introduce such safe/unsafe places on his/her own if required. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Localizing firefox
> environment.systemPackages = with pkgs ; [ > ... > (firefoxLocaleWrapper "ru") > ... > ]; I haven't read details, but what if you have different users requiring different locales? Thus what about using a list? (firefoxLocaleWrapper ["ru"]) If we are at it: For gimp I use something "object" like: (gimp.withPlugins ["pluginA" "pluginB"]) so what about using firefox.withLocales ["ru"] Then we could improve it alter: ((firefox.withPlugins ["jre" "flash" "gnash" "mplayer"]).withLocales ["ru"]) Just a thought .. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] ghc-7.6.3 vs haskellPlatform collision
I haven't looked at details.
The main assumption: one ghc works for all could be wrong.
hack-nix and nixpkgs-haskell-overlay assume that and only build
particular environments for target packages. Thus instead of
having one env to build executable EA EB EC you get three which may
have common dependencies. Therefore you do no longer install ghc,
instead you install a scitp-{A,B,C} which augment PATH as needed to
build EA, EB, EC. Its an open question which is the best way to handle
this all. Peter and Andres Loeh have shown that the standard way works
great for almost all use cases.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Support for Nix language in Haskell
Excerpts from Sergey Mironov's message of Wed Oct 30 11:15:08 +0100 2013: > Nix language. I can't find neither message, nor the package now. Could > anybody point me to this thing? https://github.com/peti/language-nix What are you trying to do? (being curious) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] cups update
https://github.com/NixOS/nixpkgs/pull/1120 I can print nice on Canon bjc-like printers finally. First I had to make gutenprintCVS compile (long time ago), then cups still failed - it printed only 30% of some pages. Last week I started giving it another try by trying to update cups. Cups has undergone some changes: - pdf is the default filter chain (unless the printer supports gs or such) - some stuff got moved into cups-filters because Apple decided to no longer maintain it (openprinting took over) - cups has 2 configuration files now - probably some more eventually less important changes. You can read the changelog yourself. gutenprintCVS is no longer neededed (by me) - but being able to build it might be useful again. In that patch there are still some typos. So consider giving the cups update a try and help me fix the remaining things such as print "test page" - test different converters etc. I've tested printing pdf files (openoffice and lpr) which works. Printing .ps files does not work yet. Should we keep both cups versions for a while? If so how, eg introduce services.cups (old) services.cupsNext (new) and allow using only one of both? Note: the gutenprint-cvs patch is not that important but could be useful again. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Touching second physical hdd causes crash.
while doing so do tail -f /var/log/messages and/or journalctl -f in a second window, evetually the kernel has time to write something useful. Make memory check - one run should be enough - the nixos install iso ships with it. Try fdisk -l without that second disk - if you have a second way to attach the same disk - try that, too. (Maybe a cable is bad).. Eg attach the disk where your first disk is attached and boot from live iso. Try something like cat /dev/sdc > /dev/null to make sure that reading from the disk is not causing any problems. (But only do so if you know the disk should be fine, otherwise backup your data first). Try fdisk -l /dev/sdc - instead of fdisk try parted to list partitions. Try ls -l /dev/sdc* to see whether the kernel finds partitions. Try totally different system such as "ubuntu live cd" to see whether it behaves the same way .. Try different kernel Which one is most likely to help find out about the problem? No idea. Maybe somebody else has more ideas. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Customizing packages via overrideDerivation
> NIX_PATH="nixos=/root/hack/nixos:nixpkgs=/root/hack/nixpkgs:nixos-config=/etc/nixos/configuration.nix" Take care about nixos path? It should be /root/hack/nixpkgs/nixos (or there should be a symlink) nixos repository has been merged into nixpkgs If this does not work try stripping down configuration.nix, if you still don't have success I can offer reviewing your configuration.nix file. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Customizing packages via overrideDerivation
Excerpts from Andrey Rogozhin's message of Fri Oct 18 18:51:09 +0200 2013: > Thanks, Eelco! I've just tried to fetch a fresh installation CD and > did a fresh install with the updated expression as you advised. That's the first thing to learn about nixos: Never do a fresh install. Its not necessary. Update the channel or your nixpkgs repository. The update will be incremental and deterministic at the same time! The Nix manual should make this clear. There is the /run/current-system/sw/bin indirection taking care of "switching the system" and similar /etc/* symlink stuff. Also compare with https://nixos.org/wiki/Nix_impurities To be be fool proof you need to: - checkout nixpkgs - export NIX_PATH=nixos=path-to-nixpkgs/nixos:nixpkgs=path-to-nixpkgs:nixos-config=/etc/nixos/configuration.nix Then run any of: nixos-rebuild test/boot/switch/vm (see --help) You've been unlucky hitting this in the first place: https://nixos.org/wiki/Open_issues:derivation_styles builderDefs is a second way to decsribe how packages are build. In contrast to the standard mkDerivation it allows to replace parts of the builder script without causing rebuilds. However those cases did not happen enough to adopt builderDefs for all packages. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Customizing packages via overrideDerivation
> src = "/root/sleuthkit-4.1.2";
Is nix fine with directories? Long time ago this caused problems if I
remember correctly. By problem I mean nix didn't recognize that the
contents change.
In your case try the following:
all-packages.nix:
foo = calPackage .. ; // regular line
myfoo= overrideDerivation foo (attrs: { .. });
Then try nix-build -A myfoo /etc/nixos/nixpkgs (or wherever you have
checked out nixpkgs.
This way its easier/faster to test. And you eliminate potential problems
such as two versions of the same package getting installed to system
PATH - in which case only one can win.
I didn't try your code - but it looked close to be fine.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] NixOS merged into Nixpkgs
Excerpts from Lluís Batlle i Rossell's message of Do Okt 10 15:41:52 +0200 2013: > will and remain valid, for nix paths? No idea whether such a alias was introduced. will be /nixos. You can also work around it by creating a symlink from nixos to nixpkgs/nixos. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Change /nix to /home/user/nix
Excerpts from stewart mackenzie's message of Mon Oct 07 07:41:18 +0200 2013: > Is there a way to correctly change /nix to /home/user/nix? Yes, but you will no longer be able to binary packages ! You can (bind) mount something to /nix at boot probably ? Does this still work since nix creates chroots with private mounts or such under some conditions. Also see nix-store --otimise Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wiki spam
Excerpts from phreedom's message of Sat Oct 05 18:34:13 +0200 2013: > it doesn't, but it provides a clear message that you need them enabled. There > are of course better ways to track logins like session IDs, but that's > another > topic. So all we need is Eelco telling me "Please test those 20 lines of PHP code an send me that small patch". Thus if he tells me "try it" I'l take care and spend the time. Note: Only the login page and create new user page will be affected. And if you login you need cookies anyway. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wiki spam
Excerpts from phreedom's message of Tue Oct 01 14:59:09 +0200 2013: > Because both are off by default and require whitelisting, cookies off? If cookies are off how does Mediawiki remember my name after logging in? Thinking about maintainability: We could also introduce a simple stateful proxy. user <-> proxy <-> media wiki the proxy returns special "you're human login test" if "register new user form" is requested. No idea which would be the best technology to implement it. Probbaly there are many ways. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wiki spam
> All these cookies and javascripts tend to break secure and efficient setups :( Please make me understand why ? My change is about adding a simple require_once 'create-user-guard.php' file. That can be automated. And even if not, it *does solve the problem* unless I get proven wrong. And if we do, we can be pretty sure that humans are spamming the wiki. And that would be a step towards solving the issue, too. > Long-term automated solutions to *prevent* spam don't exist for a > growing community like nixos. Don't overengineer. Don't think today about problems which may happen in 2 years. Maybe its even enough to hide the string "Media Wiki" on each page? You can do so by adding a simple regex post processing to apache AFAIK. We have to 1) document what has been tried 2) try new cheap things to find out whether bots are spamming - then there should be simple soultions - or whether humans are spamming. But I'll shut up. I've offered help. I don't have access, so I cannot change anything. If you want me to setup a demo how the addiotional non standard password protection would look like let me know. But let's consider trying the trivial things first before asking people to spend money or concluding that changes are not maintainable. Count the packages in nixpkgs to see how powerful the nixos community actually is. We should be able to cope with such a simple problem, unless the attackers spend much more effort than we do. Another way to solve this issue would be not allowing to create new users automatically. Setup a simple form: You want to become a wiki member? username [ .. ] password [ .. ] and process this once every 2 weeks. This should be less effort than deleting spam, too. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wiki spam
Excerpts from Philip Lykke Carlsen's message of Mon Sep 30 20:38:09 +0200 2013: > If it was common practise for wikis to require user registrations lay a money > deposit as security for constructive behaviour the problem would go away > overnight. Sure. but can't we try a less intrusive non standard way first? Such as: if create user page / edit page is requested test for our own cookie. If cookie does not exist: redirect to custom password protection page, if simple password gets typed right, set cookie, redirect to previous page (also passing GET/POST vars) If cookie does exists: behave normally? then at least we'll know whether we get spammed by bots or humans. Humans will suceed. Bots should fail, because they were programmed to spawn standarrd media wikis only. Such an implementation is about 20-30 PHP lines or less which can be added to index.php ? Just tell me "do it" and I'll provide that code. We have somebody who is willing to delete the spam, what else do we need to win this situation? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Wiki spam
Eelco: Have a look at vim-wiki.mawercer.de I have not yet had any spam. and if it happens its as easy as git revert. There is *no* password protection at all. You just have to use special ?get parameter. I know the design is not that pretty, its just a hack so that I don't have to type and talk about the same topics again. Maybe its also much less popular than nixos.org/wiki ... I seriously think that bots (or humans?) are specialized on media wiki. I think the real fix is using non standard wikis or doing anything non-standard, such as protecting login page by htaccess and dummy password. Something simple such as 'nixonixo' would probably be enough and more effective than captchas. If irc knowns about it .. Me too thinks that its bad to host spam. Additional alternatives such as github wiki has been discussed. And they are options, too. You can also access those git repositories easily. The community is strong enough to handle this. We just have to make a list of features we want and we must get started. Some additional discussions took place on this mailinglist earlier. How much spam does exist? Click the random page 10 times, then you'll know. click1: Multi-level Marketing Two Schools Of Believed Collide click2: Women's Manner Trend Principles To Stay By click3: Ageing Tips That Can Help You In The Process click4: Meet The Equipment Shop Manager click5: Picking out Straightforward Advice For beauty salon insurance I'm stopping here, you get it, all 5 pages are spam. I'm protecting against arbitrary spammers by adding a 1x1 px input spam bots are likely to fill, but humans miss. Thus if such a field is non empty I can disregard the request. The wiki is one of the weakest parts of this project. People spend their time on the libraries, packages and the core instead mostly. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] How to handle Repositories which don't keep old versions?
Excerpts from Moritz Ulrich's message of Fri Sep 27 17:09:30 +0200 2013:
> My question is: What's the best way to handle this? I personally have
> no problem hosting a mirror which keeps old versions, but I want to
> ask if you guys have other suggestions.
In the past there has been a script "fetch all sources" so that they
don't go away. But it was never run often enough?
If you do it the way python/emacs does the following should be true:
- people trust you as packager
- its easy to comment why you use your mirror
- you can use two urls.
So what about:
1) document it:
# using my own server as fallback, because new source versions cause
# older versions to be deleted...
2) keep original url, but add your own as mirror:
package = {
urls = [ original-url your-mirror-url ];
}
Don't think you can do much better.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Java plugin for FF
nix-env -iA firefoxWrapper /etc/nixos/nixpkgs
wiki has page "how to find the packge I'm looking for".
If the methods shown there don't help then maybe the only way is to know
where to look at. And that's a bug ?
Would you have found a comment in all-packages.nix like this?
# install firefoxWrapper instead
firefox = pkgs.firefoxPkgs.firefox;
[...]
firefoxWrapper = wrapFirefox { browser = firefoxPkgs.firefox; };
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Java plugin for FF
Have you installed firefox or firefoxWrapper ? Try the latter. AFAIK you should get a failure that you have to download Oracles' JRE manually - or do we use openjdk now? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] setting up bash/zsh (completion, key bindings, ...), thinking about discussing more changes?
I'd like to draw the attention of every nixos user to this change
request:
https://github.com/NixOS/nixos/pull/256
Its about improving zsh support for nixos. This topic popped up multiple
times - and I'd like to ask all of you which limitations you encountered
using the existing setup system for bash/zsh - also because I wrote an
alternative long time ago https://github.com/NixOS/nixos/pull/138
which has been is use by me since then. Its a prototype which means some
implementation details can still be done better.
Rather than voting for my patch I'd like to ask and understand which of
the features I implemented are worth caring about. Let me show you a
simple example how configuration.nix ends up in user's .bashrc:
==
configuration.nix:
users.defaultUserShell = "/var/run/current-system/sw/bin/zsh";
# support /etc/zsh,bash/* initialization:
zsh.enable = true;
bash.enable = true;
# very custom code useful to admin and most user accounts he's using,
# but not all:
bash.availableFeatures.interacitve.install_vam = ''
vim-install-vam(){
# do stuff
}
'';
# provide a load completion implementation allowing to opt-out by file
# name:
bash.availableFeatures.interacitve.completion = ''
nix_add_profile_completion(){
local profile="$1"
# origin: bash_completion, slightly adopted
# source script only once - allow user to use NIX_COMPL_SCRIPT_SOURCED to
# opt out from bad scripts. If a user wants to reload all he can clear
# NIX_COMPL_SCRIPT_SOURCED
local nullglobStatus=$(shopt -p nullglob)
shopt -s nullglob
for s in "$profile"/etc/bash_completion.d/*
"$p/share/bash-completion/completions/"*; do
local base="${s/*\//}"
[[
-z "${NIX_COMPL_SCRIPT_SOURCED[$base]}" &&
-z "${NIX_COMPL_SCRIPT_SOURCED[ALL]}"
]] && { . "$s"; NIX_COMPL_SCRIPT_SOURCED[$base]=1; }
done
eval "$nullglobStatus"
}
nix_foreach_profile nix_add_profile_completion
'';
bash.availableFeatures.env_code.add_opt_x_to_path = ''
PATH=$PATH:/opt/x/bin
'';
==
$HOME/.bashrc:
# default implementation
source /etc/bash/setup-all
==
/etc/bash/setup-all:
source setup # this populates KNOWN_FEATURES, PROFILES, ...
# non interactive
setup_path (this is more complicated)
add_opt_x_to_path
# interactive:
activate_features $KNOWN_FEATURES
Now you could copy paste contents from setup-all into your .bashrc and
opt-in/out from indivdiual features easily. That's the main idea and the
main difference to the current master setup.
Is having such features users can opt-in/out only useful to me, or are
more users interested in this?
Please pay attention that the user's .bashrc is not a symlink.
This way he can add his own aliases and still get system updates
from setup-all without having to unlink .bashrc first.
The patch I submitted to nixos shares the principles illustrated here,
but differs in implementation details.
So please let me know whether its time to discuss allowing more control
and how to implement it now because it looks like this topic is hot
right now.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Making PHP find sendmail by default
One way is to use php.ini,
another is to apply this patch.
diff --git a/pkgs/development/interpreters/php/default.nix
b/pkgs/development/interpreters/php/default.nix
index cc57e09..804fe12 100644
--- a/pkgs/development/interpreters/php/default.nix
+++ b/pkgs/development/interpreters/php/default.nix
@@ -48,6 +48,8 @@
, lessThan53 ? builtins.lessThan (builtins.compareVersions version "5.3") 0 #
you're not supposed to pass this
, lessThan54 ? builtins.lessThan (builtins.compareVersions version "5.4") 0
, lessThan55 ? builtins.lessThan (builtins.compareVersions version "5.5") 0
+
+, sendmail ? "/var/setuid-wrappers/sendmail"
}:
/* version specific notes:
@@ -396,6 +398,10 @@ let
sed -i 's/EXEEXT = \.dSYM/EXEEXT =/' Makefile
'';
+ preBuild = ''
+sed -i 's@#define PHP_PROG_SENDMAIL""@#define PHP_PROG_SENDMAIL
"${sendmail}"@' main/build-defs.h
+ '';
+
installPhase = ''
unset installPhase; installPhase;
cp php.ini-${ if lessThan53
The patch will be integrated in my php topic branch on my github page.
If you want it in official nixpkgs apply it yourself
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Peter, please comment *and give it a try* https://github.com/NixOS/nixpkgs/pull/967 still waiting for your feedback on whether the newer bup version suceeds running make test on your machine. This patch also enables make test for the existing version. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Deploying Steam in NixOS
Excerpts from Oliver Charles's message of Sat Sep 14 01:29:44 +0200 2013: > Very cool! Is this the approach you're suggesting we take with steam, and > abandon hope of doing it outside chroot? What's wrong about a chroot? Everything else could be a lot more work to maintain. Additional use cases are andoird dev environment and a lot like that. While its possible to patch them all, its could be less effoort (thus smarter) to not try to do so .. IMHO. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wiki entry on how to add a large file into the nix store
You're welcome. Keep asking and start/continue contributing. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wiki entry on how to add a large file into the nix store
No, but it suggests this instead which probably yields the same store path?: nix-store --add-fixed sha256 jdk-6u45-linux-x64.bin I don't know what the exact difference is, I'm also too lazy to look it up. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] wiki entry on how to add a large file into the nix store
The main difference is that prefetch-url can read from http and the other only works with files? Eg try installing oraclejre which lists both (or similar methods) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Nix 1.6 released
> $ nix-env -f my-packages.nix -ir So such usage is officially recommended now? :-) The old solution still applies, because its easy to create multiple "sets" and update one of those sets only: https://nixos.org/wiki/Howto_keep_multiple_packages_up_to_date_at_once Updating "everything" is doable, but sometimes annoying if it takes a lot time to update everything if you only need to update one piece at a given time. Thanks to all contributors. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
I cannot reproduce the failure locally. At least knowing whetherit happens once only or more often would be helpful, which options do I have now? Peter, have you had a chance to give test the build on your machine? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Treating emacs24-nox as an alternative to emacs
Alternative:
targetpackage.deepOverride { emacs = emacsNox; };
?
Could be slower and less convenient.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Peter, I guess you've missed the point. Even if the new version is stable and the test case works this does not mean that upgrading is stable. So consider commenting on this point, please. Neither does a failing test case mean the new version is less stable then the old - the warnings by "Mathijs Kwik" have been strong. Maybe I find time to actually test bup on my machine to see whether I can reproduce the problems found by him at least once. If 3 out of 4 month failed it should not be that hard. Does bup allow comparing its storage contents against a filesystem tree? I like bup because its simple and fast, but it should also be reasonable stable. > revert I would have liked anybody restarting the build once to see whether this alone triggers a race condition making it pass this time. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Excerpts from Peter Simons's message of Sun Sep 01 18:11:59 +0200 2013: > I think it would be best to revert the update until the reason for the > test failures on Hydra has been understood. I cannot do it (I don't have access). So do as you wish. I personally think its better to have two versions: - the old with a comment "peter is using it, ask him if you want to change something" - the new one (maybe restart the build) to learn more about the failure. The revert is not that easy, because I added a common test case. That's why I think its easier to additionally get back the old version. If you want I can prepare a patch Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Excerpts from Peter Simons's message of Sun Sep 01 15:46:15 +0200 2013: > yes, I depend on bup. Or rather, I depend on git-annex, which depends on > bup. So it would be great to keep bup in a working state. Should we keep both versions then, Peter? bup works, the test suite passed here and Evgeny Egorochkin reported the same. I tjust failed (for wahtever reason) on the buildfarm. I didn't investigate yet. I know that my "custom test case" will only catch the very very obvious problems. It does not backup 30G VM images or the like. But its better than having nothing. But I agree that creating an even nicer test suite eg based on haskell quickcheck would be even nicer. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] bup - test suite
Excerpts from Mathijs Kwik's message of Sun Sep 01 14:51:09 +0200 2013: > I would like to warn you for bup though. > I've used it for daily backups for at least half a year. Well - I guess you should have started a new repo each month .. > I've started over a few times, thinking it was something I messed up > or because of version upgrades, but it happened more than once. > Currently, I moved to using "btrfs send", which is awesome, but > somewhat experimental too :) Didn't knew about it. > Anyway, at least when it fails, it reports about it :) > supports deleting old revisions I've added this as warning. If you think you should have a new full backup each month anyway, then it does not matter that much. So what do you do now? btrfs send on the machine, and btrfs receive on the backup machine? > and does not have a separate on-disk format like bup (which > effectlively doubles space requirements if you want your bup history > available on the same machine as your live data). I compared a use case (500 MB with many git repos) and it was not that bad - eg compared tar j or storebackup - but fastest (initial and incremental backup). The initial backup was 4 times faster. It could be a little risk trusting btrfs as main fs and as backup fs :) If you get a kernel which is bad it could destroy both .. > https://github.com/bluescreen303/bluenix/blob/master/pkgs/kernel/btrfs-updates-against-3.10.7.patch > , which is just a plain "git diff" patch comparing mainline with > linux-btrfs. If nobody is heavily depending on it - then the build failure is not that bad. So I'll just wait. bup is closer to a release anyway. I was a little bit surprised that it says "You can fuse the backup" - but only got 00/0ef234e like files .. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] bup - test suite
I've updated bup adding two tests: a simple manual one which can be implemented for all backup solutions easily, and I tried activating the "make test" for bup. The make test succeeded on my machine and on Evgeny Egorochkin's but failed on hydra. Is anybody depending on the tool or do I have a couple of days to investigate? The quickest fix is commenting the line "make test" probably. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] perl packages - and propagated-native-build-inputs
Isn't nix about "install a version and know that its working !?" So why doesn't perl packages use wrappers wrapping bin/*.pl scripts ensuring that the dependencies are known? Now I fear installing an old package that it disturbes newer packages. Is this by accident or design? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] SECURITY: default SSH host keys are weak
Excerpts from phreedom's message of Fri Aug 23 14:38:55 +0200 2013: > Thus, I'm giving a short notice to people who don't want surprises and then > the default change will trigger generation of a new key. Is it possible to make ssh use/ store a key in a /key-type/* location? Then you could switch forward/backward easily. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] SECURITY: default SSH host keys are weak
Or raise an exception unless a new option such as allowWeakKeyTypes is set to true. There is a way to write assertions, grep for assertion in nixos. I'd like to to see such issues treated seriously and force the right thing unless the admin really opts out. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] disk setup for nixos installation
Excerpts from Aristid Breitkreuz's message of Sun Aug 18 19:16:15 +0200 2013: > I believe Aszlig had actually done some work on automated partitioning for > Nixops, but I'm not sure how far from ready for primetime it is. How to script partitionsing can be looked up in the test cases in nixos. Just grep for parted or such. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] disk setup for nixos installation
Well - the nixos isos ship with "nixos-install". It should be easy to add a script which runs automatically on startup (creating llvm devices and so on) and runs the script afterwards. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gem nix writes sha256 = "no hash"
Excerpts from Bjørn Forsman's message of Sun Aug 11 16:42:56 +0200 2013: > > I like being able to use a package descriptions without waiting. > > the gem-to-nix requires waiting. Then it does not care about depnedencies ? .. (not that they are always helpful ...) ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gem nix writes sha256 = "no hash"
> The number of packages doesn't mean much to me (unless there is one
> package per .nix file?),
If you have to download them (always) when getting nixpkgs they may make
a difference. So having them separate is a better choice IMHO.
I like being able to use a package descriptions without waiting.
the gem-to-nix requires waiting.
The problem gets bigger if you notice than
A-1.0 > B-2
Then you notice you don't need latest B-2, but B-1.9.
Then you *rerun* and wait. I only add this one version constraint and
I'm done. Eg something like this: (force version 2.0):
> > let ro = (pkgs.overlay "ruby");
> > in ro.rubyEnv19 {
> > name = "emproxy";
> > p = {
"eventmachine": ["2.0"];
> > };
> > names = [
> > "eventmachine"
> > "rspec"
> > "em-http-request"
> > "ansi"
> > "rake"
> > "posix-spawn"
> > ];
> > };
I'm more interested in knowing how big the
> dump is. 20 MiB?
du -hs . says: 793M (without running git gc).
Yes, its bad. And I want to write a solution for that once I have time.
Nobody is going to pay me, so it has to wait.
Using latest rev only (shallow clone) it should be less.
It got many of my jobs done - and it is "experimental".
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gem nix writes sha256 = "no hash"
ruby nix overlay:
1) ruby script to dump rubyforge to .nix files (50.000 packages)
So no, I'm not going to ask to include them to nixpkgs.
2) nix code which generates nix derivations on the fly from the dump.
3) a bash script you can source to augment your shell env so that all
packages are found.
4) some info about additional "C dependencies" which gets merged in.
Useful for accessing mysql, etc.
Problems:
- If you need very latest packages you have to rerun the dump (its experimental)
- If you need git based dependendies you might be in trouble
- If there are multiple versions of a package, you have to select a
version eventually.
Great:
Its fast, because the dump is already there
Example:
emproxyCollection =
let ro = (pkgs.overlay "ruby");
in ro.rubyEnv19 {
name = "emproxy";
p = {
};
names = [
"eventmachine"
"rspec"
"em-http-request"
"ansi"
"rake"
"posix-spawn"
];
};
Problem: The versions might be little bit different from what bundlers
suggests.
If you want to know whether it solves your problem let me create an SSH
account on my server and grant you access (ping me on irc).
Then you can give it a try easily. Otherwise use the gem command (some
work with C dependencies) or fix the the tool causing trouble to you.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] gem nix writes sha256 = "no hash"
If you want to give the ruby overlay a try . The following packages are known to it since I did the last dump http://dpaste.com/1339292/ Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] nix-shell enhancements
Well - I have one command nI -A foo which builds foo by attr with -K flag. If the build fails, it cds into the build directory. I then have a second command to start a new terminal window so that I can load nix-env. That's all I need for debugging. If I need more I add a "fail" to a build phase, and run the others manually. That's my way :) You talk about git and rollbacks. What about .o files? Will they be committed so that you can "rollback" ? You should clarify such details. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] VirtualBox images
Excerpts from Eelco Dolstra's message of Thu Jul 25 10:22:38 + 2013: > Since a few weeks Hydra generates NixOS disk images for VirtualBox, > containing Having that is great for the reasons you mention. New users will appreciate it. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Flash broken in Firefox 22?
Excerpts from Peter Simons's message of Sun Jul 14 23:38:20 +0200 2013:
> the recent update to Firefox 22 caused trouble for me.
My expermimental/marc branch works fine with ff 22 and flash debug
version
firefox = {
enableAdobeFlash = true;
# enableAdobeFlash = true;
enableMPlayer = false;
enableRealPlayer=false;
enableGoogleTalkPlugin = true;
# jre = true;
};
flashplayer.debug = true
then installing
p.pkgsi686Linux.firefoxWrapper
So at least I can say that ff 22 and flash can work.
My branches are based on nixpkgs master f3f447ac (2013-06-29 02:16:39)
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] instructions for setting up apache + mediawiki is broken
> - Is it not possible to have a default version? If you do this you can break the system by updating it. For this reason not having a default is the *only* way to protect against suprises. > - If no default version, is there at least a way to print a *human > readable* error message that hints the user about Of course, provide patches. I introduced assertions long time ago. Eg see b43.nix - so fix and provide a patch :) Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Spam on the wiki - reminder
Excerpts from Travis Reeder's message of Fri Jun 28 19:24:46 +0200 2013: > Regarding forking github wiki's, you can via the wiki's git repo, eg: > https://github.com/iron-io/iron_mq_ruby/wiki/_access , but you can only > access it via git cli. You can sync that git with another git repository. So it would not be an issue. I don't want to force another system. I'd like those who are running the wiki to propose a solution so that we all can help keep it clean easily. I don't mind a git based wiki, either Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Spam on the wiki - reminder
Excerpts from phreedom's message of Fri Jun 28 18:15:44 +0200 2013: > Using git as a backend for wiki is a huge win. Not sure how easy it is to > start contributing to github wiki for a $RANDOM_PERSON_WHO_SPOTTED_A_TYPO. It can be done trivially. As experiment I wrote a "vim-wiki": http://vim-wiki.mawercer.de/wiki/index.html There is an edit link, no login required. My hope is that its non standard so bots fail. Till now it seems to work. I neither say the syntax nor the implementation is pretty, but it actually gets the job done I wrote it for. Code is here: https://github.com/MarcWeber/vim-git-wiki I'm not responsible for making any decisions about the wiki. I also think that we have enough developpers to get anything done we can imagine. But we have to know where to go. The nixos wiki also gets it job done - even containing spam. However I still feel bad about it hosting spam. So which is the best we should manage this? Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Spam on the wiki - reminder
We still have huge amounts of spam on the wiki. Just press the random link 10 times to judge yourself. If you tell me how I'm willing to help cleaning up. But if the problem stays - we should try to find a solution. Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] git-annex assistant
If this case happens to be an exception and that it appears to be hard to package at this point in time let me know and I'll try to build it with hack-nix. The difference is that hack-nix resolves dependencies on the fly. The challenge is to feed the resolvel with a minimal set of packages because its using brute force. For details have a look here: https://nixos.org/wiki/Nixpkgs-haskell-overlay Marc Weber ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Templates
> riak
You're talking about the nosql database, right?
Excerpts from Malcolm Matalka's message of Wed Jun 26 21:26:40 +0200 2013:
> It also is a supported file type in my Emacs
nix has an emacs mode nix-mode.le, did you know that?
For nix you can get "syntax checking" by running
nix-instantiate --eval-only FILE
(vim-addon-nix has done this for ages)
So do you think that Emacs mode should be improved?
> this feature. I think putting config files in Nix expressions is
> suboptimal.
You can write config.nix and then import that:
config.nix:
{
hostname ="abc";
}
configuration.nix:
let my_config = import config.nix; in
{
networking.hostname = my_config.hostname;
}
etc.
Can you paste a couple of lines of a nicer configuration you want to use
and comment them why you think a different style is much different than
nix maintainers should care about it?
You can also use "substitute in place" like configurations:\
== the file
allowed_users: @USERS@
==
then make nix substitute @USERS@ to generate the final config.
grep nixos for @ and you should find some examples (bash scripts).
That would be sufficient if you want to create a config file for a
database only (eventually).
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Templates
I don't get what's bad about nix, you can use import (but you know that).
Nix should suppport: (I never tested it):
let config = import
"${derivation_reading_config_file_creating_nix_file}/the_generated_nix_file.nix":
That's closest and works right now.
Well of course you can just write ruby preprocessors turning your
templates into nix files, too.
Or patching nix are options.
But honestly I don't understand your use case.
Marc Weber
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
