This was caused by multiple things: First, the module-path was wrong in
the release. Second, when modules tried to load stumpwm, asdf searched
for its sources in /tmp/nix-build-*.
Both of these issues are fixed by a nix-specific patch that tells adsf
to *never* try to load stumpwm (and others) from the filesystem. This is
fine as those modules are already available in the image anyway.
We also refactor some stuff & clean up the build. Stumpish works now
too.
Sawfish is a versatile, Lisp-based window manager
In that commit I include all Sawfish stack:
- librep, a lisp system;
- rep-gtk, bindings for gtk
- sawfish, the window manager
- Move lgi to luaPackages
- Use luaPackages in awesome and passthru lua
- Allow to pass lua modules to the awesome WM so that those can be used in the configuration
This patch removes the stumpwmContrib package from the top-level since
it can't sensibly be used on its own. Also, it wraps the stumpwm
executable with a dummy reference to the contrib dir to work around the
issue that the stumpwm executable doesn't reference the contrib dir
that's passed in the configure phase for some reason.
This commit updates the stumpwm to version 0.9.8. Futhermore, it
refactors the expression quite a lot:
* stumpwm has been moved from lisp modules to window-managers.
* stumpwm has been added to the window managers NixOS knows about, this
enables the user to add stumpwm as a default window manager in his
NixOS configuration like with Xmonad or i3.
* the package has been split into stumpwm and stumpwmContrib. This is
due to the fact that development of stumpwm and its extension modules
has been split into two repositories. As of today, the release is the
last one before this split. This split into two packages only reflect
those upcoming upstream changes already.
It is planned to make the addition of the extension modules voluntarily,
like with Xmonads option "enableContribAndExtras". Furthermore it might
be possible to add an option to compile stumpwm with clisp instead of
sbcl.
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
Unfortunately, running them in parallel sometimes lead to tests not even
starting up. Probably lock contention is the issue here, but haven't
investigated further so I'm deactivating parallel testing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The exit code of the i3 test runner is always 0, regardless of whether
tests were failing or not, so let's quickly grep for a "not ok" in the
test logfile and if it occurs, the whole build is failing now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Finally, after going through the journey of debugging and gathering
dependencies, we now have tests for i3, hooray!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I don't think it is a good idea to hardcode this patch in nixpkgs as it is likely that
a patch provided by a user will conflict with this patch. This is for instance the case
with the patch "single_tagset" (http://dwm.suckless.org/patches/single_tagset).
PR #1366
The previous windowManager.xmonad option only starts xmonad and
doesn't make ghc available. This assumes that the user has GHC with
access to the xmonad package in his PATH when using xmonad.
Xmonad in Nix is now patched to accept the XMONAD_{GHC,XMESSAGE}
environment variables which define the path to either ghc or xmessage.
These are set automatically when using xmonad through
windowManager.xmonad.
My (or specific: @aristidb and my) changes make it possible to use
Xmonad without adding GHC to any profile. This is useful if you want
to add a different GHC to your profile.
This commit introduces some options:
- xmonad.haskellPackages: Controls which Haskell package set & GHC set
is used to (re)build Xmonad
- xmonad.extraPackages: Function returning a list of additional
packages to make available to GHC when rebuilding Xmonad
- xmonad.enableContribExtras: Boolean option to build xmonadContrib
and xmonadExtras.
Signed-off-by: Moritz Ulrich <moritz@tarn-vedra.de>
