The version 3.21 isn't compatible with our currently packaged
`pythonPackages.gpapi` which is now at version 0.4.3.
See https://hydra.nixos.org/build/83154918
Initially the expression was quite small (just inherited properties from
`pkgs.dlib`), but the more it grows the better it is to store it into
its own file.
With the current plugin configuration I get the following error when
opening a C/C++ file in ViM:
```
"main.cpp" 246L, 7522C
Loading libclang failed, completion won't be available. Are you sure '/nix/store/jdz3pbl853dw6k0qg54ifd5fplkq7xl8-cla
ng-3.9.1/lib/libclang.so' contains libclang?
```
Previously you either had to set the setuid bit yourself or workaround
`isSystemUser = true` (for a loginable shell) to access the weechat
screen.
`programs.screen` shouldn't do this by default to avoid taking too much
assumptions about the setup, however `services.weechat` explicitly
requires tihs.
See #45728
The autoupgrade service defined in `system.autoUpgrade`
(`nixos/modules/installer/tools/auto-upgrade.nix`) doesn't have `su` in
its path and thus yields a warning during the `daemon-reload`.
Specifying the absolute path fixes the issue.
Fixes#47648
The init script slightly differs depending on which shell is in use.
So for bash it should be in the interactiveShellInit as well.
In this case we don't need a mkIf as `bash` is enabled by default
on NixOS.
Previously single quotes were used by default for aliases and the module
never warned about possible collisions when having a shell alias which
relies on single quotes.
Adding `escapeShellArg` works around this fixes the issue and ensures that a
properly quoted value is written to `/etc/zshrc`.
See https://hydra.nixos.org/build/80705583
Recent `boost` versions with `python` enabled have changed their naming
scheme for `boost_python` shared objects which causes issues with the
proper linking when building `pyftgl`.
Previously the library was named `boost_python3`, no it's named
`boost_python36` for current python (3.6.x).
The same issue applies for the `python2`.
Addresses #45960
The ZSH completion script of `tig` basically imports the bash completion
script and uses it as completion approach. Unfortunately the script
takes several assumptions about the directory structure using
`$funcsourcetrace`[1] that don't apply on NixOS.
The easiest workaround is t opatch the completion script and import the
bash completion script from `$out`.
[1] http://zsh.sourceforge.net/Doc/Release/Zsh-Modules.html#index-funcsourcetrace
Instead of searching `/usr` it should search for the `xkb`,
$XDG_DATA_DIRS will be searched. With this approach we allow compliance
on NixOS and non-NixOS systems to find `symbols` in the `xkb` directory.
The patch has been accepted by upstream, but isn't released yet, so this
is mainly a temporary fix until we can bump ZSH to the next stable version.
The `xserver` module links `/share/X11/xkb` to `/run/current-system` to
make this possible.
The fix can be tested inside the following VM:
```
{
zshtest = {
programs.zsh.enable = true;
users.extraUsers.vm = {
password = "vm";
isNormalUser = true;
};
services.xserver.enable = true;
};
}
```
Fixes#46025
The `pkgs.yabar` package is relatively old (2016-04) and contains
several issues fixed on master. `yabar-unstable` containsa recent master
build with several fixes and a lot of new features (I use
`yabar-unstable` for some time now and had no issues with it).
In the upstream bugtracker some bugs could be fixed on ArchLinux by
simply installing `yabar-git` (an AUR package which builds a recent
master).
To stabilize the module, the option `programs.yabar.package` now
defaults to `pkgs.yabar-unstable` and yields a warning with several
linked issues that are known on `pkgs.yabar`.
The test has been refactored as well to ensure that `yabar` actually
starts (and avoid non-deterministic random success) and takes a
screenshot of a very minimalistic configuration on IceWM.
Fixes#46899
This package providesa completion input method for faster typing.
See https://mike-fabian.github.io/ibus-typing-booster
Detailed instructions how to activate this IBus engine on your desktop
can be found in the upstream docs: https://mike-fabian.github.io/ibus-typing-booster/documentation.html
A simple VM with the Gnome3 desktop and activated `ibus' looks like
this:
```nix
{
emojipicker = { pkgs, ... }: {
services.xserver = {
enable = true;
desktopManager.gnome3.enable = true;
desktopManager.xterm.enable = false;
};
users.extraUsers.vm = {
password = "vm";
isNormalUser = true;
};
i18n.inputMethod.ibus.engines = [
pkgs.ibus-engines.typing-booster
];
i18n.inputMethod.enabled = "ibus";
virtualisation.memorySize = 2048;
};
}
```
Fixes#38721
Loading olm.lua as weechat script with `/script load olm.lua' causes
errors like this:
```
/nix/store/43jbh7yxh8j4gjfzbvpd9clncah5dip1-weechat-matrix-bridge-2018-05-29/lib/ffi.so: undefined symbol: lua_tointeger
```
As `olm.lua' is loaded by `matrix.lua' it doesn't need to be included
manually by the weechat configuration.
See https://hydra.nixos.org/build/80727495
`pants' works with requests==2.19 to build successfully and `nixpkgs' currently uses `requests==2.19.1`.
Patching the version constraint in `setup.py' accordingly fixes the problem.
Addresses #45960
See https://hydra.nixos.org/build/80705916
To fix the linux build the patch `bsm-add-audit_token_to_pid.patch`
mustn't be applied during Linux builds, only for Darwin as it's an
Apple-only fix.
The compiler failure occurred because `audit_token_t` is part of
`<mach/mach.h>` which is not available on Linux.
Addresses #45960
The original build broke with the following linker issue:
```
CXXLD _PythonMagick.la
/nix/store/h0lbngpv6ln56hjj59i6l77vxq25flbz-binutils-2.30/bin/ld: cannot find -l-L/nix/store/4gh6ynzsd5ndx37hmkl62xa8z30k43y1-imagemagick-6.9.9-34/lib
collect2: error: ld returned 1 exit status
```
This happens since `BOOST_PYTHON_LIB` wasn't set properly, however
`_PythonMagick.la` was linked with `-l$(BOOST_PYTHON_LIB)
$(MAGICK_LIBS)`. With an empty `BOOST_PYTHON_LIB` the linker got
confused.
To work around this, the `boost` library directory needs to be specified
explicitly. To ensure that the changes take effect, the original
`configure` script shipped with `$src` needs to be removed and recreated
using the `autoreconfHook`.
Additionally the `imagemagick` license (https://spdx.org/licenses/ImageMagick.html)
needs to be added to `lib/licenses.nix` to document the proper license
of `pythonmagick` in the meta section.
See https://hydra.nixos.org/build/80828287
Moves `mahotas` out of `python-packages.nix` into its own file and fixes
broken test cases by skipping them using nosetest's `@nottest`
annotation.
These tests broke from time to time in a sandbox and are therefore
considered impure.
Addresses #45960
See https://hydra.nixos.org/build/80999410
Without a sandbox the `checkPhase` breaks with the following error:
```
/nix/store/i6vl5lwlz5jbkg4r6p340dwmj6fha3xq-stdenv-linux/setup: bin/jbake: /usr/bin/env: bad interpreter: No such file or directory
jbake did not return correct version
```
Running `patchShebangs` before fixes the issue.
Addresses #45960
See https://hydra.nixos.org/build/80998335.
Upstream doesn't support QT 5.11 ATM which broke compilation:
```
src/dialogs/savedialog.cpp: In constructor ‘SaveDialog::SaveDialog(QWidget*, Qt::WindowFlags)’:
src/dialogs/savedialog.cpp:37:34: error: invalid use of incomplete type ‘class QButtonGroup’
group = new QButtonGroup(this);
```
The Arch community recommends to use an older QT version to fix
this (https://aur.archlinux.org/packages/chessx/).
Furthermore the `QT_PLUGIN_PATH` wasn't set properly which broke the
runtime since QT coudln't find the `xcb` plugin:
```
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized.
Reinstalling the application may fix this problem.
```
Finally, some minor style fixes were made for consistent indentation.
Addresses #45960
Fixes the build for `python3Packages.trio' for the next ZHF iteration.
Please refer to the Hydra build for further reference: https://hydra.nixos.org/build/80617356
`python3Packages.sniffio` is needed for the build, otherwise the build
aborts with an error like this:
```
Could not find a version that satisfies the requirement sniffio (from trio==0.6.0) (from versions: )
No matching distribution found for sniffio (from trio==0.6.0)
```
See #45960
In my previous PR I missed that ${sec.foobar} (syntax to retrieve
secrets in a weechat runtime) breaks the shell evaluation.
Furthermore `;` shall be used rather than `\n` to concat scripts and the
init config.
This adds several improvements the previously introduced
`services.weechat` module:
* Dropped `services.weechat.init` as the initialization script can now
be done on package-level since 2af41719bc using the `configure`
function.
* Added `sessionName` option to explicitly configure a name for the
`screen` session (by default: weechat-screen).
* Added `binary` option to configure the binary name (e.g.
`weechat-headless`).
* Added docs regarding `screen` session and `weechat.service`.
This aims to make the `weechat` package even more configurable. It
allows to specify scripts and commands using the `configure` function
inside a `weechat.override` expression.
The package can be configured like this:
```
with import <nixpkgs> { };
weechat.override {
plugins = { availablePlugins, ... }: {
plugins = builtins.attrValues availablePlugins;
init = ''
/set foo bar
/server add freenode chat.freenode.org
'';
scripts = [ "/path/to/script.py" ];
};
}
```
All commands are passed to `weechat --run-command "/set foo bar;/server ..."`.
The `plugins' attribute is not necessarily required anymore, if it's
sufficient to add `init' commands, the `plugins' will be
`builtins.attrValues availablePlugins' by default.
Additionally the result contains `weechat` and `weechat-headless`
(introduced in WeeChat 2.1) now.
This fixes an issue with shells like fish that are not fully POSIX
compliant. The syntax `ENV=val cmd' doesn't work properly in there.
This issue has been addressed in #45932 and #45945, however it has been
recommended to use a single shell (`stdenv.shell' which is either
`bash' or `sh') to significantly reduce the maintenance overload in the
future.
See https://github.com/NixOS/nixpkgs/issues/45897#issuecomment-417923464Fixes#45897
/cc @FRidh @xaverdh @etu
`git-annex` version 6.20180719 enhances the output of `git-annex info`
with a description and UUID of the repository which broke the testcase
`test_process_annex_info_batch` which parses the output of the info
command.
The testcase has been fixed accordingly and the patch was filed upstream
here: https://github.com/alpernebbi/git-annex-adapter/pull/6
I rechecked the functionality in a simple python environment with the
following expression:
```
with import ./. {};
python3.withPackages (ps: with ps; [ git-annex-adapter ])
```
Furthermore I tested the main functionality in a Python REPL within the environment.
The Darwin patch fixes tests that rely on `rev`, a binary which is
distributed in the `utillinux` package and not available on Nix with
Darwin.
To make the purpose of the patches for future contributors clear I
documented the purpose for each patch.
When rebuilding you have to manually run `systemctl --user
daemon-reload`. It gathers all authenticated users using
`loginctl list-user` and runs `daemon-reload` for each of them.
This is a first step towards a `nixos-rebuild` which is able to reload
user units from systemd. The entire task is fairly hard, however I
consider this patch usable as it allows to restart units without running
`daemon-reload` for each authenticated user.
This bumps Hydra to the latest revision available. As Hydra doesn't have
a release model (and therefore no tags) ATM, the derivation will pin
against the actual git revision and the date of the commit in the
derivation name.
Additionally the following changes have been made:
* Dropped `postUnpack` phase. It is useful when working with the Hydra
source (and no dirty changes shall be used in `release.nix`, but is has
no use in `nixpkgs`).
* Added myself as maintainer to have more folks available in case of
future breakage.
* Implemented support for Nix 2.0 and `unstable` (currently 2.1):
Since 1672bcd230447f1ce0c3291950bdd9a662cee974 in NixOS/nix the
evaluator differentiates between `settings` and `evalSettings`.
Previously `restrictEval` in `hydra-eval-jobs.cc` has been set in
`settings`, this doesn't work anymore in Nix 2.1 and is therefore
incompatible to Nix 2.0 on an API level.
To resolve this, the flag `isGreaterNix20` parses the version string
of `pkgs.nix` and applies a patch if nix.version<=2.0.
Furthermore the Hydra build with Nix 2.1 requires `boost` as build input
which is not needed for Nix 2.0. To avoid unnecessary increase in the
closure size this library will only used as build input for
nix.version>2.0.
* Fixed the NixOS test for `hydra`:
disabled binary cache to allow sandbox builds (otherwise it would
query `cache.nixos.org` during the Hydra build inside the test).
Additionally the trivial.nix jobset required simplification (as done
in NixOS/hydra, e.g. tests/api-test.nix) as bash is not available in
the build sandbox as builder (even when adding pkgs.bash to
systemPackages).
The easiest workaround to confirm a the functionality of a jobset
without importing nixpkgs is to use the default shell /bin/sh which
is mounted from `pkgs.busybox` into the build env
(https://github.com/NixOS/nixpkgs/pull/44841#discussion_r209751972) in the
VM and a named pipe to create $out.
Closes#44044
Build was broken as release-0.6.0 didn't support opentimestamps-0.4.0.
Applying the patch which relaxes the version contraints in `setup.py`
helps.
Furthermore the tests were broken as they missed the `git` executable.
This causes collisions between the build outputs of `nix` when building
in an environment with `nix1.perl-bindings` and `nix`:
```
collision between `/nix/store/aa4rrcj7dg2xj4rfkiclcmp745ibqng0-nix-2.0.4/lib/libnixstore.so' and `/nix/store/sp0sdi4bll80h58big1iy8kkh3qqxpw2-nix-1.11.16/lib/libnixstore.so'
builder for '/nix/store/wgbccin107lhm8cv9imnnvkx1j2pgibc-hydra-perl-deps.drv' failed with exit code 25
```
The `weechat-xmpp` plugin requires `pydns` to properly resolve the
XMPP host. Furthermore it's much easier to use substituteAll rather than
messing around with substituteInPlace in a patched file.
Since #44522 it's possible to specify custom certificates for the Citrix
receiver. As it took me some time to create a proper setup Citrix can
behave fairly unexpected.
I mostly covered two aspects:
* Don't install Citrix with `nix run`: when `citrix.desktop` is linked
to $XDG_CONFIG_DIRS, it's possible to start a session directly from the
browser when loading `.ica` files which makes the usage *way* easier.
* It's possible to add custom certificates using the Citrix wrapper. A
new store path with the original derivation and the certificates will be
created and therefore no rebuild of the package is needed when adding
new certs.
In the last year `programs.oh-my-zsh` gained more complexity and since
the introduction of features like `customPkgs` which builds a
`ZSH_CUSTOM` path from a sequence of derivation a documentation may be
fairly helpful to make the knowledge how to use the module and how to
package new ZSH plugins visible.
See https://github.com/NixOS/nixpkgs/pull/43282#issuecomment-410770432
Also fixed the package build from
https://hydra.nixos.org/build/78900949.
`requests_oauthlib` seems to work fine at version 1.0 with `asana`, so
rather than creating our own override for `asana` it's fine to use 1.0
and patch `setup.py`.
Sometimes it's required to modify some parts of the Citrix build on
their own which is why `{pre,post}Install` hooks can be quite helpful.
Additionally some corporate clients use their own certificates that
aren't stored as trusted ones in the `cacert` package with all of the
trusted certs by Mozilla.
Now it's possible to add custom certs like this:
``` nix
with import <nixpkgs> { config.allowUnfree = true; };
let path = ../../Downloads/custom-corporate-cert.pem; in
citrix_receiver.override {
extraCerts = [ path ];
}
```
If multiple third-party modules shall be used for `oh-my-zsh` it has to
be possible to create another env which composes all the packages.
Now it can be done like this:
```
{ pkgs, ... }:
{
programs.zsh.enable = true;
programs.zsh.ohMyZsh = {
enable = true;
customPkgs = with pkgs; [
lambda-mod-zsh-theme
nix-zsh-completions
];
theme = "lambda-mod";
plugins = [ "nix" ];
};
}
```
Please keep in mind that this is not compatible with
`programs.zsh.ohMyZsh.custom`, only one of these options can be used
ATM.
Each package should store its outputs into
`$out/share/zsh/<output-name>`. Completions (and ZSH-only) extensions
should live in the `fpath` (`$out/share/zsh/site-functions`), plugins in
`.../plugins` and themes in `.../themes` (please refer to
fdb6bf6ed68c2f089ae6c729dfeaa3eddea2ce6a and 406d64aad162b3a4881747be4e24705fb5182573).
All scripts in `customPkgs` will be linked together using `linkFarm` to
provide a single directory for all scripts from all derivations in
`customPkgs` as suggested in https://github.com/NixOS/nixpkgs/pull/43282#issuecomment-410396365.
This ensures that no impurity exists due to implicitly depending
on`/usr/bin/env`.
It stores the theme into `$out/share/zsh/themes` to make it possible to
find theme using `buildEnv` and remain consistent with other ZSH
extensions.
These files feature simple aliases and a nix-shell detector when using
`nix-shell --run zsh`. The package itself contains the completion scripts in
`$out/share/zsh/site-functions` (to keep it compatible with ZSH-only
setups) and the plugins in `$out/share/zsh/plugins` for oh-my-zsh.
`ocserv` is a VPN server which follows the openconnect protocol
(https://github.com/openconnect/protocol). The packaging is slightly
inspired by the AUR version
(https://aur.archlinux.org/packages/ocserv/).
This patch initializes the package written in C, the man pages and a
module for a simple systemd unit to run the VPN server. The package
supports the following authentication methods for the server:
* `plain` (mostly username/password)
* `pam`
The third method (`radius`) is currently not supported since `nixpkgs`
misses a packaged client.
The module can be used like this:
``` nix
{
services.ocserv = {
enable = true;
config = ''
...
'';
};
}
```
The option `services.ocserv.config` is required on purpose to
ensure that nobody just enables the service and experiences unexpected
side-effects on the system. For a full reference, please refer to the
man pages, the online docs or the example value.
The docs recommend to simply use `nobody` as user, so no extra user has
been added to the internal user list. Instead a configuration like
this can be used:
```
run-as-user = nobody
run-as-group = nogroup
```
/cc @tenten8401
Fixes#42594
Until now it's impossible to override the attrs of the actual build
instruction for the `termite` package like this:
```
termite.overrideAttrs (_: {
# ...
})
```
This issue occurs since the `termite/default.nix` expressions returns
the `symlinkJoin` expression when I override termite (e.g. to provide a
config file).
I recently patched termite and wanted to apply this patch to my local
termite installation in my system config which is impossible this, so
splitting the wrapper and the build instruction into their own files
makes this way easier to maintian.
The setup.py of `python-package` contains some path resolution magic to
find `libxgboost.so` which is needed for the python API.
Unfortunately the code is incompatible with Nix as it isn't compatible
with the store-based structure for each package and tries to express the
location of the shared object with relative paths.
The detection in `setup.py` and `xgboost/libpath.py` has been either
removed entirely or patched to link to the proper store path of the
`libxgboost` build input.
See https://hydra.nixos.org/build/77702715 for further reference.
According to the current convention python packages should live in
`pkgs/development/python-modules`. As I altered the `graphite_api`
expression previously in d3d1b88873 I decided to move it as well.
Additionally I applied some minor refactorings:
* use `fetchFromGitHub` instead of `fetchgit`.
* use `checkInputs` for test dependencies
* got rid of fixed points
* applied patch which supports flask-caching to 1.3.1 using `git apply
-3`
It seems as recent versions of `trezor` don't work with python 2.x:
```
/build/trezor-0.9.1/dist /build/trezor-0.9.1
Processing ./trezor-0.9.1-py2-none-any.whl
trezor requires Python '>=3.3' but the running Python is 2.7.15
builder for '/nix/store/aqyxki0ckanjk4r1f0an4kj1w4s3kk4f-python2.7-trezor-0.9.1.drv' failed with exit code 1
cannot build derivation '/nix/store/gp4smkzc9r87lzajs17jnq4rh2ayc5q0-python2.7-keepkey-4.0.0.drv': 1 dependencies couldn't be built
```
The package is currently broken and most folks recommend to use
`flask-caching` (see
https://github.com/thadeusb/flask-cache/issues/171).
The only package in `nixpkgs` which remained to use `flask_cache`
(`graphite_api`) still builds with `pythonPackages.flask-caching`.
The removal and corresponding `graphite_api` change unbreaks several
Hydra builds (see https://hydra.nixos.org/build/76953777).
When running e.g. `nixos-option boot.kernelPackages` I get an output
like this on the current unstable channel (18.09pre144959.be1461fc0ab):
```
$ nixos-option boot.kernelPackages
Value:
*exit 1*
```
This is fairly counter-intuitive as I have no clue what might went
wrong. `strace` delivers an output like this:
```
read(3, "error: Package \342\200\230cryptodev-linu"..., 128) = 128
read(3, "ux/cryptodev/default.nix:22 is m"..., 128) = 128
read(3, "lowBroken = true; }\nin configura"..., 128) = 128
read(3, "you can add\n { allowBroken = tr"..., 128) = 128
read(3, "n)\n", 128) = 3
read(3, "", 128) = 0
```
`nixos-option` evaluates the system config using `nix-instantiate` which
might break when the evaluation fails (e.g. due to broken or unfree
packages that are prohibited to evaluate by default). The script aborts
due to the shebang `@shell@ -e`.
In order to ensure that no unexpected
behavior occurs due to removing `-e` from the interpreter the easiest
way to work around this was to wrap `nix-instantiate` in `evalNix()`
with a `set +e`. The function checks the success of the evaluation with
`$?` in the end. Additionally `evalNix` shouldn't break, if one
evaluation (e.g. the values that contain a package set by default) to
return additional information like a description.
With the change `nixos-option boot.kernelPackages` delivers the
following output for me:
```
Value:
error: Package ‘cryptodev-linux-1.9-4.14.52’ in /nix/store/47z2s8cwppymmgzw6n7pbcashikyk5jk-nixos/nixos/pkgs/os-specific/linux/cryptodev/default.nix:22 is marked as broken, refusing to evaluate.
Default:
{ __unfix__ = <LAMBDA>; acpi_call = <CODE>; amdgpu-pro = <CODE>; ati_drivers_x11 = <CODE>; batman_adv = <CODE>; bbswitch = <CODE>; bcc = <CODE>; beegfs-module = <CODE>; blcr = <CODE>; broadcom_sta = <CODE>; callPackage = <CODE>; cpupower = <CODE>; cryptodev = <CODE>; dpdk = <CODE>; e1000e = <CODE>; ena = <CODE>; evdi = <CODE>; exfat-nofuse = <CODE>; extend = <CODE>; facetimehd = <CODE>; fusionio-vsl = <CODE>; hyperv-daemons = <CODE>; ixgbevf = <CODE>; jool = <CODE>; kernel = <CODE>; lttng-modules = <CODE>; mba6x_bl = <CODE>; mwprocapture = <CODE>; mxu11x0 = <CODE>; ndiswrapper = <CODE>; netatop = <CODE>; nvidiaPackages = <CODE>; nvidia_x11 = <CODE>; nvidia_x11_beta = <CODE>; nvidia_x11_legacy304 = <CODE>; nvidia_x11_legacy340 = <CODE>; nvidiabl = <CODE>; odp-dpdk = <CODE>; openafs = <CODE>; openafs_1_8 = <CODE>; perf = <CODE>; phc-intel = <CODE>; pktgen = <CODE>; ply = <CODE>; prl-tools = <CODE>; recurseForDerivations = true; rtl8192eu = <CODE>; rtl8723bs = <CODE>; rtl8812au = <CODE>; rtl8814au = <CODE>; rtlwifi_new = <CODE>; sch_cake = <CODE>; spl = <CODE>; splLegacyCrypto = <CODE>; splStable = <CODE>; splUnstable = <CODE>; stdenv = <CODE>; sysdig = <CODE>; systemtap = <CODE>; tbs = <CODE>; tmon = <CODE>; tp_smapi = <CODE>; usbip = <CODE>; v4l2loopback = <CODE>; v86d = <CODE>; vhba = <CODE>; virtualbox = <CODE>; virtualboxGuestAdditions = <CODE>; wireguard = <CODE>; x86_energy_perf_policy = <CODE>; zfs = <CODE>; zfsLegacyCrypto = <CODE>; zfsStable = <CODE>; zfsUnstable = <CODE>; }
Example:
{ _type = "literalExample"; text = "pkgs.linuxPackages_2_6_25"; }
Description:
"This option allows you to override the Linux kernel used by\nNixOS. Since things like external kernel module packages are\ntied to the kernel you're using, it also overrides those.\nThis option is a function that takes Nixpkgs as an argument\n(as a convenience), and returns an attribute set containing at\nthe very least an attribute <varname>kernel</varname>.\nAdditional attributes may be needed depending on your\nconfiguration. For instance, if you use the NVIDIA X driver,\nthen it also needs to contain an attribute\n<varname>nvidia_x11</varname>.\n"
Declared by:
"/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/system/boot/kernel.nix"
Defined by:
"/home/ma27/Projects/nixos-config/system/boot.nix"
```
The `.service` file defining the `systemd` unit for `autorandr.service`
which is bundled with the package itself uses `--default default` in the
`ExecStart` section. This can be an issue when having multiple layouts
(e.g. `default` as workstation layout I mostly work on and `mobile` when
I go somewhere else).
When the service gets restarted and `--default` can't be applied,
however the current layout can't be detected (e.g. when working with an
unknown beamer) the service silently fails with a message like this:
```
Jun 22 18:44:46 hauptshuhle autorandr[3168]: /nix/store/h83b72ffm68nm8fyjnppljchp456a94r-xrandr-1.5.0/bin/xrandr: ca>
Jun 22 18:44:46 hauptshuhle autorandr[3168]: Failed to apply profile 'default' (line 718):
Jun 22 18:44:46 hauptshuhle autorandr[3168]: Command failed: /nix/store/h83b72ffm68nm8fyjnppljchp456a94r-xrandr-1.>
```
As discussed in the IRC (see https://botbot.me/freenode/nixos/2018-07-05/?msg=101791455&page=6)
it's a bad long-term solution in terms of maintenance to manually patch
the service file bundled with the derivation, instead the service shall
be configured declaratively. Additionally this makes possible overrides
from the user-space way easier.
The `udev` rule (in `$out/etc/udev/rules.d`) won't' be affected, it
simply runs `systemctl start autorandr.service` when e.g. a new display
is added, so now `udev` communicates with the NixOS systemd unit.
This package adds completion scripts for `gradle` on the `bash` and
`zsh` shells.
The completions can be enabled like this:
```
{ pkgs, ... }:
{
environment.systemPackages = [ pkgs.gradle pkgs.gradle-completion ];
programs.zsh.enable = true;
}
```
The package stores the scripts into the expected directories in
`$out/share` to ensure that the shells can easily find their scripts.
Closes#42799
Fixes the Hydra CI build of `python{3,2}Packages.keyutils` on `nixpkgs.`
This patch changes the source retrieval to fetchFromGitHub as the PYPI
tarball doesn't come with tests for the check phase.
`minitube` is currently broken transitively due to the broken
`phonon-backend-qt4`: https://hydra.nixos.org/build/76523277
Although QT4 is fairly old, this package is still built with `qt4` ATM,
however QT5 is available as well. After this change, QT5 will be built
by default and in case anybody requires legacy QT4 it has to be enabled
explicitly like this:
```
with import <nixpkgs> { };
phonon-backend-vlc.override { withQt4 = true; }
```
Now the QT5-only build can be used (which fixes `minitube`) and there
are no confusions anymore with the build dependencies. Previously
`phonon-backend-vlc` and `libsForQt5.phonon-backend-vlc` used `qt4` by
default which was likely responsible for broken `minitube`.
The exception message is broken becuase of some uppercase vs. lowercase
issues that have been patched accordingly.
Additionally use `fetchpatch` rather than `fetchurl` to apply patches
into the build.
The current `thumbor` build on master: https://hydra.nixos.org/build/76000076
This is mainly caused by several dependency bumps (e.g.
`pythonPackages.tornado` to v5 in dd936ccdb9)
that broke the `setup.py` from version 6.4.
Bumping to the latest stable version (6.5.1) fixes these issues.
The stable build for `yabar` is currently broken: https://hydra.nixos.org/build/75989172
Main reason is that the inline function `ya_setup_prefix_suffix` is
supposed to be an inline function, but was insufficiently declared as
such which broke the compiler recently with the following message:
```
gcc -std=c99 -Iinclude -pedantic -Wall -Os `pkg-config --cflags pango pangocairo libconfig` -DVERSION=\"0.4.0\" -D_POSIX_C_SOURCE=199309L -DYA_INTERNAL -DYA_DYN_COL -DYA_ENV_VARS -DYA_INTERNAL_EWMH -c -o src/intern_blks/ya_intern.o src/intern_blks/ya_intern.c
gcc -o yabar src/ya_main.o src/ya_draw.o src/ya_exec.o src/ya_parse.o src/intern_blks/ya_intern.o -lxcb -lpthread -lxcb-randr -lxcb-ewmh `pkg-config --libs pango pangocairo libconfig`
src/intern_blks/ya_intern.o: In function `ya_int_date':
ya_intern.c:(.text+0x49): undefined reference to `ya_setup_prefix_suffix'
src/intern_blks/ya_intern.o: In function `ya_int_uptime':
ya_intern.c:(.text+0xf4): undefined reference to `ya_setup_prefix_suffix'
src/intern_blks/ya_intern.o: In function `ya_int_brightness':
ya_intern.c:(.text+0x1d8): undefined reference to `ya_setup_prefix_suffix'
src/intern_blks/ya_intern.o: In function `ya_int_bandwidth':
ya_intern.c:(.text+0x377): undefined reference to `ya_setup_prefix_suffix'
src/intern_blks/ya_intern.o: In function `ya_int_cpu':
ya_intern.c:(.text+0x6de): undefined reference to `ya_setup_prefix_suffix'
src/intern_blks/ya_intern.o:ya_intern.c:(.text+0x924): more undefined references to `ya_setup_prefix_suffix' follow
collect2: error: ld returned 1 exit status
make: *** [Makefile:18: yabar] Error 1
```
This issue has been fixed on master (see
https://github.com/geommer/yabar/commit/9779a5e04bd6e8cdc1c9fcf5d7ac31416af85a53)
which is why `nixos.yabar-unstable` remained functional.
The current version of `avidemux` (v2.7.0) breaks on master (see
https://hydra.nixos.org/build/75993794), the 18.03 build remains fine
(https://hydra.nixos.org/build/75935027).
The following changes have been applied:
* `glibc` compat patch is obsolete as it landed in upstream.
* Fixed QT_PLUGIN_PATH for QT binaries to avoid errors because of
missing plugins like this:
```
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
[1] 20081 abort /nix/store/rjwxc6ih15zwvvy71ss8bvnh56ibfbmj-avidemux-2.7.1/bin/avidemux3_qt5
```
The 3.2.2 build fails ATM on Hydra: https://hydra.nixos.org/build/75998362
Bumping to 3.2.8 and rebasing `osquery/CMakeLists.txt` with `misc.patch`
fixes the issue. Additionally the NixOS test remains functional.
`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.
This fixes the latest `dlib` build for `nixpkgs` compliancy:
* Patched `setup.py` to use number of jobs defined in `$NIX_BUILD_CORES`
rather than using all available cores.
* Bumped `dlib` to latest version (v19.13 ATM).
* Dropped `openblas` build input, `cblas` which actually works lives in
`dlib/external`. Otherwise the test suite runs into segfaults (see
https://github.com/NixOS/nixpkgs/pull/39255#issuecomment-384535129 for
further reference).
* Added myself as maintainer in case of any further breakage in the
future.
Closes#39255
/cc @dotlambda @ryantm
Maximilian Bosch