The function ‘mkDerivation’ now checks whether the current platform
type is included in a package's meta.platform field. If not, it
throws an exception:
$ nix-build -A linux --argstr system x86_64-darwin
error: user-thrown exception: the package ‘linux-3.10.15’ is not supported on ‘x86_64-darwin’
These packages also no longer show up in ‘nix-env -qa’ output. This
means, for instance, that the number of packages shown on
x86_64-freebsd has dropped from 9268 to 4764.
Since meta.platforms was also used to prevent Hydra from building some
packages, there now is a new attribute meta.hydraPlatforms listing the
platforms on which Hydra should build the package (which defaults to
meta.platforms).
There's a zlib version included with milkytracker,
but there's no makefiles for it. I've only included
the header here, but it fails at link-time with
several 'undefined reference' errors, which simply
means it can't find the definitions, e.g. compiled
zlib.
There's bug reports on other package systems although
unfortunately still unresolved.
https://bugs.archlinux.org/task/31324http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/082180.html
I actually had this breeding in my nixpkgs overrides for a year and only
recently took the time to fix it and thus revive my video feeds :-)
The package uses a patch which is removing the dependency on gconf and
switches to storage within a shelve in ~/.miro/config instead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Compiles fine on linux i686 and amd64. Adding myself as maintainer, even
though I'm not using the package by myself, but a friend is using it for
DJing from a NixOS live system I'm maintaining.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This uses a patch from Gentoo to disable Java support for now, as it is
not needed for supporting Mixxx (which is the package I'm preparing).
Hopefully, the patch will be applied upstream so we can safely drop it
here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
To prevent multiple Qt libraries when developing with a custom one, the Qt
support can now be activated by directly supplying the Qt libraries as an
argument (qtLib).
qtSDK and qtFull users/developers now just have to define an override such
as the following one in order to use it inside their development
environment:
vtk.override { qtLib = qt4SDK; };
The previous behavior is still the same for vtk and vtkWithQt4 end-users.
Change-Id: I517762d4ff7de46d32cc46e6e725fd62737caa52
* There now is full support for building Haskell packages as shared libraries
for GHC versions 7.4.2 or later. The Cabal builder recognizes the following
attributes:
- enableSharedLibraries configures Cabal to build of shared libraries in
addition to static ones. This option requires that all dependencies of
the package have been compiled for use in shared libraries, too.
- enableSharedExecutables configures Cabal to prefer shared libraries when
linking executables.
The default values for these attributes are arguments to the haskellPackages
expression.
* Haskell builds now run in a LANG="en_US.UTF-8" environment to avoid plenty
of build and test suite errors. Without this setting, GHC seems unable to
deal with the UTF-8 character encoding that's generally considered standard
in the Haskell world.
* The Cabal builder supports a new attribute 'testTarget' to specify the exact
set of tests to be run during the check phase.
* The ghc-wrapper attribute ghcVersion has been removed. Instead, we use the
ghc.version attribute, which exists in unwrapped GHC derivations, too.
xc3sprog is command-line tools for programming FPGAs, microcontrollers
and PROMs via JTAG.
Homepage: http://xc3sprog.sourceforge.net/
I'm using the latest from subversion as xc3sprog doesn't seem to make
proper releases. There are only a few seemingly random snapshots at
sourceforge. And these snapshots are built binary packages, not source
archives.
NOTE: I haven't tested this on any hardware yet.
Consider this as a first step towards the integration of Qt5 into nixpkgs,
it does not yet intends to replace Qt4 on every packages even if possible.
My goal here is to have a first derivation in common between people who
needs qt5 for development purposes.
The derivation has been written from scratch but I took care to read at the
version 4 to re-integrate some patches which are still compatible. However,
I did not had enough time to test gtkStyle and flashplayerFix as I do not
use any of them. Also, OSX users will have to do some extra work because
I do not have any mac.
Finally, as some configure flags have changed and in an hope to provide a
clear package definition before it becomes mature, I voluntary added some
flags which are default. Once every option will be mastered, we will just
have to redo a pass on qt5 configure flags and remove the ones which are
set by default.
To give the ability to use a different Qt version than the default one
(which can build 3 different times Qt Libraries if we mixed the default
one, the qtcreator one and the version including all the examples and the
docs).
Right now a developer can choose to directly install the QtSDK which
includes a "full" (developerBuild + docs + examples) Qt version and uses
it to build QtCreator.
The possibility to only install QtCreator and its previous behavior has
been kept for flexibility purposes (we do not need to force someone on the
SDK approach).
FriBID is an open source software for the Swedish e-id system called
BankID. FriBID also supports processor architectures and Linux/BSD
distributions that the official software doesn't support.
https://fribid.se/index.en.html
FriBID plugin is a firefoxWrapper plugin. Enabled by setting:
nixpkgs.config.enableFriBIDPlugin = true
Kept the old hacks where they don't break the build in case they things
they fix are still relevant.
I checked that the upgrade doesn't break:
1) Asymptote and EProver builds.
2) My XeLaTeX demo from configurations/ repository.
3) Some of my own files.
The upgrade fixes problems with simultaneous use of 3D and LaTeX labels
in Asymptote.
Please provide a test that worked previously and is broken now if you
need to revert this update or its parts.
Features:
+ configurable via environment variables
+ can skip the actual launching of the lisp implementation (source it
with NIX_LISP_SKIP_CODE=1 to get all the settings)
+ currently supports SBCL, CLisp, ECL
+ determines lisp implementation from NIX_LISP_COMMAND variable or
from buildInputs
+ sets ASDF search path for packages using buildInputs
Somehow Dwarf Fortress suddenly started failing to use our libpng (or
zlib). I tried all possible combinations (supplying them via
LD_LIBRARY_PATH in the script) but it just won't work.
This solution was found in the Archlinux bug tracker: It just symlinks
all problematic .png files to their .bmp counterparts. It's ugly and
*sadly* breaks tileset support (unless you convert them to bmp) but I
think it's acceptable, as the whole expression is pretty problematic
in terms of purity.
Let's hope the next release of Dwarf Fortress will be easier to
support.
(fixes#710)
