`nifskope` v2 contains a lot of new features and a new, QT5-based UI
(see https://github.com/niftools/nifskope/releases). Additionally the
2.0 sourcetree exists for quite a while and after some short user tests
it seems fairly stable.
The following aspects have been changed:
* Use QT 5.9 rather than QT4 (see #33248).
* GCC7 support from upstream (gcc6 patch not needed anymore, build on
GCC7 works fine), disabled `-Werror=format-security` can be used again
as compiler flag.
* Patched broken paths in `NifSkope_targets.pri` to point to the proper
dependencies (otherwise `<gli.hpp>` and `qhull` couldn't be found).
* Patched paths in `NifSkope.pro` to `lupdate` and `lrelease` (default
`QT_*` paths point to `libsForQt5x.qtbase` which doesn't contain the
needed binaries, instead they need to point to `libsForQt5x.qttools`).
* Added myself as maintainer.
In particular, this contains Firefox-related and libgcrypt updates.
Other larger rebuilds would apparently need lots of time to catch up
on Hydra, due to nontrivial rebuilds in other branches than staging.
OPAE is a software toolchain and for integration and use of programmable
accelerators, currently supporting Intel Arria 10 and Stratix 10 FPGAs.
This package only contains the userspace software SDK tools and C
libraries -- not the OPAE Linux drivers.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is the first time since 5.9 that we also update `qtwebkit`.
`qtwebkit` is not maintained by Qt anymore and thus, we switch to the
community port as for example arch has done. To prevent pulling in
single patches, we just stick to the latest git version.
When you evaluate nixos/tests/simple.nix, you'll run into an infinite
recursion since 41b140cb25.
The reason is that udisks2 now pulls in gnupg because it now depends on
libblockdev, which in turn depends on volume_key and that depends on
gnupg.
Nevertheless, it's not the real reason, because this only means, that
since gnupg is now pulled into the closure of a basic nixos
configuration the real problem becomes visible:
In nixos/modules/config/no-x-libs.nix there is an overlay which does
something like this:
nixpkgs.overlays = singleton (const (super: {
pinentry = super.pinentry_ncurses;
}));
Now since pinentry_ncurses is already using pinentry.override we get an
infinite recursion because now the pinentry attribute refers to
pinentry_ncurses, which by itself is again referring to pinentry.
This is solved by using the self.pinentry.override instead, so that the
override used by pinentry_ncurses doesn't use the attribute from the
overlay.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
Signed-off-by: aszlig <aszlig@nix.build>
A .la file specifies linker flags to link with the library it describes. Its
"dependency_libs" field lists the libraries that this library depends upon.
This list often contains "-l" flags without corresponding "-L" flags. Many
packages in Nixpkgs deal with this in one of these ways:
- delete .la file [1]
- clear dependency_libs [2]
- add -L flags to dependency_libs [3]
- propagate dependencies [4]
Sometimes "dependency_libs" contain wrong "-L" flags pointing to the "dev"
output with headers rather than to the main output with libraries. They have to
be edited or deleted to reduce closure size [5].
Deleting .la files is often but not always safe [6]. Atomatically deleting as
many of them as possible is complex [7]. Deleting .la files that describe
shared rather than static libraries is probably safe; but clearing their
"dependency_libs" field achieves the same effect with less potential for
unintended consequences. This is the approach that may be enabled for all
Nixpkgs.
[1] 2a79d296d3
[2] c83a530985
[3] 9e0dcf3bd9
[4] 01134e698f
[5] f6c73f1e37
[6] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Handling_Libtool_Archives
[7] https://github.com/gentoo/gentoo/blob/fb1f2435/eclass/ltprune.eclass
