Since Qt 5.8, font style names are handled in a way that prevents alternate
styles (bold, italic, etc.) from being selected for user interface fonts.
See also: https://phabricator.kde.org/D9070
gnuradio-with-packages was not running makeWrapper on any of the
symlinked executables because `find $out/bin -type f -executable`
does not resolve symlinks. I don't understand how the old code
ever worked on any system.
Since commit e44038bcca, cairo-1.0.typelib contains an absolute
path to cairo in the nix store so that no $LD_LIBRARY_PATH hacks are
needed. However, this did not yet work for lgi, because lgi does
dlopen("libcairo.so.2") without a full path, too.
To make this work, this commit ensures that lgi first uses
gobject-introspection to load libcairo. This uses the full path provided
by the typelib. Afterwards, dlopen("libcairo.so.2") does not hit the
filesystem anymore since the library is already loaded.
This commit adds a patch that reorders some code in lgi's cairo
initialisation. Previously, this started with core.module('cairo', 2),
which is where the dlopen happens. Now, this code is moved down and
instead core.gi.cairo.resolve is used to load the definitions of some
enums first. This part of the code goes through gobject-introspection
and causes libcairo to be loaded.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit e44038bcca, cairo-1.0.typelib contains an absolute
path to cairo in the nix store so that no $LD_LIBRARY_PATH hacks are
needed. However, this did not yet work for lgi, because lgi does
dlopen("libcairo.so.2") without a full path, too.
To make this work, this commit ensures that lgi first uses
gobject-introspection to load libcairo. This uses the full path provided
by the typelib. Afterwards, dlopen("libcairo.so.2") does not hit the
filesystem anymore since the library is already loaded.
This commit adds a patch that reorders some code in lgi's cairo
initialisation. Previously, this started with core.module('cairo', 2),
which is where the dlopen happens. Now, this code is moved down and
instead core.gi.cairo.resolve is used to load the definitions of some
enums first. This part of the code goes through gobject-introspection
and causes libcairo to be loaded.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fixes build failure since recent merge of staging branch:
$ nix-build -A qmmp
[...]
AutoMoc error
-------------
Included moc files with the same name will be generated from different sources.
Consider to
- not include the "moc_<NAME>.cpp" file
- add a directory prefix to a "<NAME>.moc" include (e.g "sub/<NAME>.moc")
- rename the source file(s)
Include conflicts
-----------------
"moc_hotkeymanager.cpp" included in
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager_win.cpp"
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager_x11.cpp"
would be generated from
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager.h"
- "/tmp/nix-build-qmmp-1.1.10.drv-0/qmmp-1.1.10/src/plugins/General/hotkey/hotkeymanager.h"
make[2]: *** [src/plugins/General/hotkey/CMakeFiles/hotkey_autogen.dir/build.make:58: src/plugins/General/hotkey/CMakeFiles/hotkey_autogen] Error 1
The expression now supports having `words.txt` in some place without tens
and tens of megabytes of all the wordlist and spelling dictionaries. Set
`singleWordlist` parameter to the string of region and size settings. For
example:
```
scowl.override{singleWordlist = "en-gb-ise 60";}
```
Should be useful for #34486
pypandoc is broken (it does not work properly with pandoc 2), so we
remove the dependency as it was only used for generating PyPI docs.
The patch will be included upstream in the next version, so it should
be removed next time this package is updated.
390.x is Nvidia's latest "Long Lived Branch version" according to
https://www.nvidia.com/object/unix.html so this upgrades the stable version
from 387.xx.
390.x also also has support for kernel 4.15 and later (due to removal of the
old init_timer APIs, among other things), meaning that
linuxPackages_4_15.nvidia_x11 now builds correctly.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
https://hydra.nixos.org/build/68588849/nixlog/1
libtool: compile: clang++ -DHAVE_CONFIG_H -I. -I../../include/fastjet -O2 -Wall -g -Woverloaded-virtual -DDROP_CGAL -I. -I./siscone -I./../../include -I./siscone -c SISConeBasePlugin.cc -fno-common -DPIC -o .libs/libSISConePlugin_la-SISConeBasePlugin.o
SISConeBasePlugin.cc:12:12: error: no matching member function for call to 'structure_of'
return a.structure_of<UserScaleBase::StructureType>().ordering_var2()
~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./../../include/fastjet/PseudoJet.hh:1012:60: note: candidate template ignored: substitution failure [with TransformerType = fastjet::SISConeBasePlugin::UserScaleBase::StructureType]: ISO C++ specifies that qualified reference to 'StructureType' is a constructor name rather than a type in this context, despite preceding 'typename' keyword
const typename TransformerType::StructureType & PseudoJet::structure_of() const{
~~~~~~~~ ^
After effa9e4045, which switched to Meson,
the Vala bindings were not built which broke Shotwell. Enabling Vala
was not enough due to a bug, though, so we have to patch it.
Provides an app to view battery and power statistics. This app is badly
documented on the web, but is in the default Fedora install; hence to
motivation to add it to Nix.
Otherwise the build fails to detect libusb and doesn't build
the 'xpwn' and 'dfu-util' tools.
New tools run but I don't have any suitable devices to test :).
(I believe latest iGadgets need a newer version of xpwn anyway)
Two packages:
- pkgs.linuxPackages.openafs (only kernel module)
- pkgs.openafs (client/server programs, manpages, docs)
Disable `ncurses` by default
- Only needed for debugging tools
Introduce but disable `tsmbac` by default
- IBM's on-site backup service called Tivoli Storage Manager Backup
Client
- Make openafs ready to use tsmbac when supplied via local overlay
(needs special patching)
- TSM is not in nixpkgs due to unclear/unfree licensing. (Binaries need
to be modified to work with nixos)
Since firefox 58.0.1 the google api key is now stored at an absolute
path ($TMPDIR/ga). Since variable expansion in `configureFlags` does not
really work (as expected) the build started failing when using the
legacy firefox build system. With the newer `./mach` based builds
firefox reads the configure flags from `.mozconfig` instead.
This commit moves the `with-google-api-keyfile=` setting into the
`preConfigure` phase where we can properly expand `$TMPDIR` into
whatever the path is.
As stated by Sylvestre Ledru (@sylvestre) on Nov 22, 2017 at
https://github.com/NixOS/nixpkgs/issues/31843#issuecomment-346372756 we
have permission to use the official firefox branding.
Fur purposes of documentation the statement of @sylvestre:
> As the person who did part of the work described in the LWN article
> and release manager working for Mozilla, I can confirm the statement
> that I made in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815006
>
> @garbas shared with me the list of patches applied for the Nix package.
> As they are just for portability and tiny modifications, they don't
> alter the experience of the product. In parallel, Rok also shared the
> build options. They seem good (even if I cannot judge the quality of the
> packaging of the underlying dependencies like sqlite, png, etc).
> Therefor, as long as you keep the patch queue sane and you don't alter
> the experience of Firefox users, you won't have any issues using the
> official branding.
