(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>
