This is a bugfix release which fixes the following bugs:
* Synergy Service - Error 87: The parameter is incorrect.
* Option not supported on Linux: --enable-drag-drop (server not
starting)
Bug IDs and the announcement can be found at:
http://synergy-foss.org/blog/synergy-1-4-15-released/
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So, we get the old behaviour of nixos-hardware-scane if we run the
following command:
nixos-generate-config --no-filesystems --show-hardware-config
This allows to use scripts in order to fetch NixOS specific hardware
information, without the need to duplicate code elsewhere.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The attributes swapDevices and imports add a space character after the
eqals sign, which is unnecessary. I know, I'm a pedantic douche bag but
it hurts my eyes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is to get back the old behavior of nixos-hardware-scan, which
didn't include fileSystems and swapDevices.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The default target (i386-linux) causes flags like "-march i386" to be
added, which breaks on recent Fedora releases (18 and up), resulting
in errors like:
/usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48: undefined reference to `__atomic_fetch_add_4'
So set the target to i686-linux.
http://hydra.nixos.org/build/6567357
Spotify doesn't start:
$ ./result/bin/spotify
/nix/store/yx05s6irqil8a24ilyvjvhnjljmm8f15-spotify-0.9.4.183/bin/.spotify-wrapped: error while loading shared libraries: libcef.so: cannot open shared object file: No such file or directory
That is fixed with adding $out/spotify-client/Data to RPATH.
Then Spotify errors out trying to open libudev.so.0. We don't have that
in nixpkgs, so I'm making a symlink to libudev.so.1 instead.
Tested on NixOS x86_64-linux.
meta.license is can be a string or a list of strings. But there is one
unhandled case where "unfree" (or "unfree-redistributable") is a part of
a list. It will currently not be detected as an "unfree" package and
Hydra will attempt to build it. This should fix it.
Example: http://hydra.nixos.org/build/6553461
As zsh's corresponding flag is called --no-rcs, the build environment
couldn't be configured to use zsh at all.
Even then the custom PS1 won't work on zsh, but it's usable enough.
Close#1040.
* simplify directory layout
* clean up option descriptions
* let the user override Firebird package
* create firebird user
* clarify TODO comment
Close # 1061.
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.
Apply a fix which prevented to use -DGL_GLEXT_LEGACY, -Werror and -Wundef
to be used together. This produced a build fail on any software meeting
these requirements.
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).
