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
Bumped to the latest version available.
Also tested the `web.archive.org` backup to avoid broken downloads when
the tarball is removed from the official download mirror.
The `zsh-autosuggestions` package provides several configuration options
such as a different highlight style (like `fg=cyan` which is easier to
read).
With `rename.nix` the old `programs.zsh.enableAutosuggestions` is still
functional, but yields the following warning like this during evaluation:
```
trace: warning: The option `programs.zsh.enableAutosuggestions' defined in `<unknown-file>' has been renamed to `programs.zsh.autosuggestions.enable'.
```
The module provides the most common `zsh-autosuggestions` (highlight
style and strategy) as options that will be written into the interactive
shell init (`/etc/zshrc` by default). Further configuration options can
be declared using the `extraConfig` attr set:
```
{
programs.zsh.autosuggestions.extraConfig = {
"ZSH_AUTOSUGGEST_BUFFER_MAX_SIZE" = "buffer_size";
};
}
```
A full list of available configuration options for `zsh-autosuggestions`
can be viewed here: https://github.com/zsh-users/zsh-autosuggestions/blob/v0.4.3/README.md
`udiskie` breaks for me with the following error when using 1.7.4:
```
Traceback (most recent call last):
File "/nix/store/cqa72mqgm5gi0xpqp5r8csdizv3p3ajr-udiskie-1.7.4/lib/python3.6/site-packages/udiskie/cli.py", line 307, in _start_async_tasks
results = yield self._init()
File "/nix/store/cqa72mqgm5gi0xpqp5r8csdizv3p3ajr-udiskie-1.7.4/lib/python3.6/site-packages/udiskie/cli.py", line 495, in _init
tasks.append(Async())
NameError: name 'Async' is not defined
```
The error has been confirmed by the Debian issue tracker, so it's
obviously not related to NixOS.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=899419 for further
reference.
The build for `pythonPackages.jira` failed with the following error:
```
Download error on https://pypi.python.org/simple/sphinx/: [Errno -2] Name or service not known -- Some packages may not be found!
Couldn't find index page for 'sphinx' (maybe misspelled?)
Download error on https://pypi.python.org/simple/: [Errno -2] Name or service not known -- Some packages may not be found!
No local packages or working download links found for sphinx>=1.6.5
Traceback (most recent call last):
...
File "/nix/store/bp4dillg6xxblpf00v8d9nxfx3bnggfy-python3.6-bootstrapped-pip-10.0.1/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 667, in easy_install
raise DistutilsError(msg)
distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('sphinx>=1.6.5')
builder for '/nix/store/8dv7mpspyk6kxwnzqb43rzm4q5j14xp0-python3.6-jira-1.0.15.drv' failed with exit code 1
```
The root issue is most likely caused by some docs fixes upstream
(https://github.com/pycontribs/jira/commit/519183d874fde26e676a75aa53496968643aaac0)
which were released in 1.0.15. The bump (without the fix) has been
performed in 7a6bf668fb. Since `sphinx`
isn't needed during runtime, it's not necessary to use it as
`propagatedBuildInput`. In order to work around this the dependency had
to be removed from from `setup.py`.
See https://hydra.nixos.org/build/75004048 for further reference
It seems as Python will be fetched from $PATH in Vim 8.1:
```
stat("/home/ma27/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/run/wrappers/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/home/ma27/.nix-profile/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/nix/var/nix/profiles/default/bin/python", 0x7ffe57a317b0) = -1 ENOENT (No such file or directory)
stat("/run/current-system/sw/bin/python", {st_mode=S_IFREG|0555, st_size=291, ...}) = 0
readlink("/run/current-system/sw/bin/python", "/nix/store/ggjkqbvwnv7dflkmdgmmp"..., 4096) = 72
```
This breaks in cases where you want to use a modified Python derivation
for the VIM plugins you use in `vim_configurable`:
```
let
vim_configurable' = vim_configurable.override {
# python with modules for ensime
python = python.withPackages (ps: with ps; [ sexpdata websocket_client ]);
};
in
vim_configurable'.customize {
# ...
}
```
With VIM 8.0 this worked perfectly fine, now it's necessary to install
the modified `python` in $PATH to actually use it, otherwise an error
like this arises:
```
[ensime] A dependency is missing, please `pip2 install sexpdata websocket-client` and restart Vim.
Press ENTER or type command to continue
```
However it should be possible to pass the modified Python to the
modules, the easiest workaround is to write a wrapper which prefixes
$PATH to have the Python derivation available.
The `3.0.1` build was broken (see the Hydra build from
https://hydra.nixos.org/build/74368257 for further reference).
Because of the missing `utillinux` build input the package fails fairly
early:
```
-- Checking for module 'blkid'
-- No package 'blkid' found
CMake Error at /nix/store/9hmhxgj4jk6jmxihgavj6gm0p759misc-cmake-3.10.2/share/cmake-3.10/Modules/FindPkgConfig.cmake:415 (message):
A required package was not found
```
Additionally `partition-manager` was broken on non-KDE desktops (none+i3
in my case) as the plugins from `libsForQt5.kpmcore` couldn't be found
in `QT_PLUGIN_PATH` unless it's installed in
`environment.systemPackages` or with `nix-env -iA libsForQt5.kpmcore`.
This has been fixed by adding a wrapper in the `postInstall` hook which
prefixes the `QT_PLUGIN_PATH` with the plugin path from `kpmcore` used
for the build.
`xsslock` (which was originally packaged in 6cb1d1aaaf)
is a simple screensaver which connects a given screen locker (e.g.
`i3lock`) with `logind`. Whenever `loginctl lock-sessions` is invoked
the locker will be used to lock the screen. This works with its power
management features (e.g. `lid switch`) as well, so the PC can be locked
automatically when the lid is closed.
The module can be used like this:
```
{
services.xserver.enable = true;
programs.xss-lock.enable = true;
programs.xss-lock.lockerCommand = "i3lock";
}
```
`statsd` is a daemon written in `node` to gather statistics over UDP.
The current test ensures that a port is open, but the basic
functionality isn't sufficiently tested.
This patch contains the following changes:
* Simplified port scanning (`waitForOpenPort` rather than `netcat` magic).
* Issue a TCP command to check the health of the `statsd` server.
* Simple script to check if `statsd` receives data over UDP and confirms
the basic functionality of the TCP interface on `8126` for admin
purposes.
The original `nexus` derivation required `/run/sonatype-work/nexus3`
which explicitly depended on the NixOS path structure.
This would break `nexus` for everyone using `nixpkgs` on a non-NixOS
system, additionally the module never created `/run/sonatype-work`, so
the systemd unit created in `services.nexus` fails as well. The issue
wasn't actively known as the `nixos/nexus` test wasn't registered in
Hydra (see #40257).
This patch contains the following changes:
* Adds `tests.nexus` to `release.nix` to run the test on Hydra.
* Makes JVM parameters configurable: by default all JVM options were located
in `result/bin/nexus.vmoptions` which made it quite hard to patch
these parameters. Now it's possible to override all parameters by
running `VM_OPTS_FILE=custom-nexus.vmoptions ./result/bin/nexus run`
(after patching the `nexus` shell script), additionally it's possible
to override these parameters with `services.nexus.vmoptions`.
* Bumped Nexus from 3.5.1 to 3.11.0
* Run the `nexus` test on Hydra with `callTest` in `nixos/release.nix`,
furthermore the test checks if the UI is available on the specified
port.
* Added myself as maintainer for the NixOS test and the package to have
some more people in case of further breakage.
* Added sufficient disk space to the `nexus` test, otherwise the service
fails with the following errors:
```
com.orientechnologies.orient.core.exception.ODatabaseException: Cannot create database 'accesslog'
com.orientechnologies.orient.core.exception.OLowDiskSpaceException: Error occurred while executing
a write operation to database 'accesslog' due to limited free space on the disk (242 MB). The database
is now working in read-only mode. Please close the database (or stop OrientDB), make room on your hard
drive and then reopen the database. The minimal required space is 256 MB. Required space is now set to
256MB (you can change it by setting parameter storage.diskCache.diskFreeSpaceLimit) .
```
/cc @ironpinguin @xeji
The package breaks currently breaks with the following message:
```
fixed-output derivation produced path '/nix/store/5dh1mdj027ad8sprk12fqa5h5bpdxs5n-sasview' with sha256 hash '12k1w4yq1mzjxcp2cqb562c7cbwzhi54rsbmgi0fax0i1660q167' instead of the expected hash '05la54wwzzlkhmj8vkr0bvzagyib6z6mgwqbddzjs5y1wd48vpcx'
```
To fix the build the following changes were applied:
* Switched to latest master for now as the older releases have a broken
`py.test` configuration and altering hashes.
* Added `checkPhase` which invokes `py.test` directly and drops
duplicated files from `dist/tmpbuild`.
* Rebased the patches `pyparsing-fix.patch` and `local_config.patch` for
the latest master revision.
Additionally refer to the discussion in #40381 for further reference.
* The revision checksum changed, so it's safer to pin the package
against an explicit `git` tag (https://github.com/NixOS/nixpkgs/pull/40381#issuecomment-388484695)
* Repaired `checkPhase` to run `py.test` properly on Python {2,3}
* Bumped to latest revision (unstable-2018-04-27) as it supports the entire test suite
properly.
When opening `shutter` it adds an indicator icon to the status bar.
However this doesn't happen (and an ugly default icon will be used) if
`shutter` can't find the `hicolor-icon-theme`. In such a case a warning
like this can be found in `stderr`:
```
Gtk-WARNING **: Could not find the icon 'image-png'. The 'hicolor' theme
was not found either, perhaps you need to install it.
```
As I don't think that we should force users to install this theme
globally and several other packages including `tor-browser`, `gparted`
or `clawsmail` add `hicolor-icon-theme` to their closure this seems to
be a fair measure.
Version 2.9 is based on QT5 (with a much better interface) and requires
additionally the dependencies `qtbase`, `qtdeclarative` and `qttools`.
Furthermore the `QT_PLUGIN_PATH` had to be altered, however the
`phonon-backend` contains versioned paths, so we provide the plugin path
that matches the QT version used to build this package.
See #33248
The latest update of `yowsup` (https://github.com/tgalal/yowsup/releases/tag/v2.5.7)
contains the following fixes:
* Updated tokens
* Fixedtgalal/yowsup#1842: Bug in protocol_groups RemoveGroupsNotificationProtocolEntity
* Other minor bug fixes
The `argparse-dependency.patch` required a rebase onto the latest
version of `setup.py` and ensures that `argparse` won't be needed as
extra dependency as our `python3` package ships `argparse` by default.
A short note to Python 2 support:
the actual issue related to Python 2.x support has been resolved
(https://github.com/tgalal/yowsup/issues/2325#issuecomment-354533727),
however this relies on `six==1.10` which isn't support by `nixpkgs` as
`six` has been bumped to `1.11`. When trying to inject a patched version
of our `six` package based on `six==1.10` you'll run into issues with
duplicated libraries in your closure as further build dependencies
(`pytest` in this case) use the latest `six` version. As Python 2.7 will
die in 2020 (https://pythonclock.org/) and patching around in the
dependencies of `pytest` to get `yowsup` running isn't worth the effort
in my opinion I decided to keep the Python 2.x build disabled for now.
The following changes have been applied:
- the property `http.headers.X-Content-Type-Options` must a list of
strings rather than a serialized list
- instead of `/etc/docker/registry/config.yml` the configuration will be
written with `pkgs.writeText` and the store path will be used to run
the registry. This reduces the risk of possible impurities by relying
on the Nix store only.
- cleaned up the property paths to easy readability and reduce the
verbosity.
- enhanced the testcase to ensure that digests can be deleted as well
- the `services.docker-registry.extraConfig` object will be merged with
`registryConfig`
/cc @ironpinguin
Some time ago I fixed the broken package `osquery` (see #39336).
I had to test the package manually by starting the daemon locally,
however this doesn't ensure that the module is still functional.
In order to cover the package *and* the integration with the NixOS
module I thought that adding a testcase might be the best idea.
The current testcase does the following things:
* Starts an `osqueryd` service in a test machine with customized logger
path and PID file
* Ensures that the `osqueryd.service` unit is running
* Checks if the customized flags (`pidfile`, `logger_path`) are applied
to `osquery`.
* Performs a simple test query against the `etc_hosts` database to check
if the basic funcitonality of `osquery` (storing system information into
a database) works fine.
The package is broken on master for some time now:
https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.notary.x86_64-linux/all
The main reason for the breackage is that the `Makefile` script attempts
to retrieve the latest git commit by using `git rev-parse` which breaks
as `git` is not in the build environment. This could be fixed by using
`?=` rather than `:=` for the `GITCOMMIT` variable in the `make` script
to easily override `GITCOMMIT` in the `buildPhase`.
See the Hydra logs for reference:
https://nix-cache.s3.amazonaws.com/log/ib4qp8h4r8d830ra4fah38l7ybb82gp7-notary-0.6.0.drv
Furthermore some refactoring was applied:
* Activated the test suite for `cmd/notary` to confirm the basic
functionality when building for NixOS.
* Added {pre,post} hooks for `{build,install}Phase`
* Added myself as maintainer to have more people available in case of
further breakage.
As reported in #39676 the build broke because of ca52152 as the bump of
`pythonPackages.botocore` to 1.10.9 clashed with the wanted dependencies
in `awscli`.
In order to reduce the risk of accidental bugs because of loosened
version constraints I bumped the AWS CLI to `1.15.10` which depends on
`botocore@1.10` as well.
Fixes#39676
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
The package was originally broken as reported in #38940 and
facebook/osquery#4257. The latest version (3.x) contains several
important fixes for GCC 7, so now we can compile without a much less
complicated patches.
The following changes were needed to fix the derivation:
* Upgrade `osquery/third-party` to the latest rev to be compliant with
osquery 3.
* Keep using an override for the AWS SDK (for a lower closure size and
less compile time), but make the `ec2` API available.
* Added the dependencies `fpm`, `zstd`, `rdkafka`, `rapidjson` to the
build. `linenoise-ng` is obsolete as it's directly bundled with
`osquery/third-party`.
* Fixed the linking issue with `gflags` as recommended in the mailing
list: https://groups.google.com/d/msg/nix-devel/l1blj-mWxtI/J3CwPATBCAAJ
* Dropped the obsolete dependencies `cpp-netlib`, `lz4`, `apt` and
`devicemapper` (thanks @Infinisil).
* Override `OSQUERY_PLATFORM` to provide `nixos:version`
for sandbox and non-NixOS based builds. The `platform-nixos.patch`
file is now obsolete (thanks @flokli).
The patch was rebased against the 3.x branch of `osquery` and contains
mostly old changes. Additionally several testing targets were skipped as
they broke the build.
The functionality has been testing using the following command:
```
mkdir /tmp/osq.log/
./result/bin/osqueryd --pidfile /tmp/osq.pid \
--database_path /tmp/test.db --logger_path /tmp/osq.log
```
With the daemon running the database can be queried easily using
`./result/bin/osqueryi`.
Fixes ticket #38940
See ticket #36453
Further reference can be gathered from the affected Hydra logs for
the master branch: https://hydra.nixos.org/job/nixos/trunk-combined/nixpkgs.osquery.x86_64-linux
When reading the `nixpkgs` version from `.version` you always have a
`\n` at the end because of the final newline.
This issue exists since b7d15ed and had to be fixed several times
according to the history of `.version`.
Furthermore @Infinisil recommended I explicitly configured
`.editorconfig` to avoid newlines in `.version`.
Both packages referred to the same repo (`gflags/gflags` at GitHub),
both packages used almost the same version (2.2.1 and 2.2.0). Therefore
I think that it's just fair to drop one of the packages to avoid
duplication and reduce the maintenance overload.
I decided to drop `gflags` originally packaged by @shlevy as it didn't
contain testing support as `google-gflags` does. The package set refers
from `gflags` to `google-gflags`, so both package names remain (to avoid
any confusions), however the `gflags` expression is removed.
This patch is heavily inspired by bd0d8ed807 which added
a setcap wrapper for `mtr` in order to allow running `mtr` without
`sudo`. The need for the capability `cap_net_raw` that can be registered using
`setcap` has been documented in the Arch Wiki: https://wiki.archlinux.org/index.php/Capabilities#iftop
A simple testcase has been added which starts two machines, one with a
setcap wrapper for `iftop`, one without. Both testcases monitor the
bandwidth usage of the machine using the options `-t -s 1` once, the
machine with setcap wrapper is expected to succeed, the `iftop` on the
machine without setcap wrapper is expected to return a non-zero exit
code.
The `clementine` package is actually released under Apache license, but
requires the unfree `libspotify` package to build.
Now `nixpkgs.clementine` points to the free derivation and
`nixpkgs.clementineUnfree` has been introduced for the package bundled
with spotify support.
Fixes#38315
The following fixes have been applied according to the changelog (https://github.com/ageitgey/face_recognition/releases)
- Added the face_detection CLI command
- Removed dependencies on scipy to make installation easier
- Cleaned up KNN example and fixed a bug with drawing fonts to label detected faces in the demo
Furthermore the maintainer switched to actual GIT tags for PyPI releases
as discussed in ageitgey/face_recognition#417 and #37566
`pythonPackages.prov` has been bumped to `1.5.2`, however `nipype`
pinned `prov` to `1.5.0`. Patching `nipype/info.py` fixes this issue by
bumping to the current `prov` version in nixpkgs.
See https://hydra.nixos.org/build/71817962/log
See ticket #36453
Tests broke on Hydra as the `checkPhase` wasn't configured properly. By
explicitly relying on `nosetests` and injecting `LC_ALL` into the
`checkPhase` the tests work again.
The license (bsd3) according to `LICENSE` distributed with the upstream
package wasn't specified in the meta section which could've caused legal
issues.
The expression has been moved into its own file to reduce the length and
complexity of `pkgs/top-level/python-packages.nix`.
See https://hydra.nixos.org/build/70689499/log
See #36453
The original idea behind this change (described in ticket #11064) was to
improve the assertions to avoid that users of the X server accidentally
forget to configure a DM or WM.
However this caused several issues with setups that require X, but no DM
or WM. The keymap testcases became instable as well as now disabling DMs
needs to be done explicitly.
(see https://github.com/NixOS/nixpkgs/pull/31268#issuecomment-347080036)
In the end the idea behind the change and #11064 was obviously a
mistake, so reverting it completely for now should be fine.
The `1822-release` build breaks on Hydra, some days ago the stable
`2.2.0` release has been tagged on upstream.
It required some new build inputs (zlib, curl, SDL2_mixer, python3) and
some minor changes in the cmakeFlags and makeFlags for the build.
See https://hydra.nixos.org/build/71818713/log
See ticket #36453 and #31747
The compilation broke due to the flag `-Werror=int-in-bool-context`
which caused several compilation errors with GCC v7. Disabling this
warning manually with `-Wno-error` in `NIX_CFLAGS_COMPILE` should be
fine.
This package experienced several radical changes as the entire python
build in `$src/management/python` was broken since the given Python
interpreter missed several needed modules (including
`pythonPackages.qpid-python`). As the CMake build tried to invoke the
affected `setup.py` manually and patched the shebangs with `disutil` and
caused non-functional executables, I split the package up into two
parts, the actual `qpid-cpp` lib and the Python module that will be
composed using `buildEnv`.
Furthermore I added myself as maintainer for the package as the diff
became quite huge and we should have more folks available to maintain
this.
See https://hydra.nixos.org/build/71519082/log
See tickets #36453 and #31747
The `geogebra` package is subject to break as upstream removes versioned
packages from their download server when five new releases are comming.
This is why I had to fix almost monthly the package by bumping the
version (these can be found by running `git log --online | grep
geogebra:`). As the package didn't cause any issues for several months
now I guess that using `archive.org` seems to be a suitable solution for
now.
/cc @sternenseemann @matthewbauer
Adds the python package `face_recognition` and its dependency
`face_recognition_models`.
This package is a wrapper for `dlib` which is able to detect faces in a
given image. I checked the package with the following expression:
```
with import ./. { };
stdenv.mkDerivation {
name = "facetest";
src = null;
buildInputs = with pythonPackages; [ face_recognition ];
}
```
The package works perfectly fine in a `nix-shell`:
```
$ nix-shell
[nix-shell:~]$ python
Python 2.7.14 (default, Sep 16 2017, 17:49:51)
[GCC 7.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import face_recognition
>>> img = face_recognition.load_image_file("/home/ma27/me.jpg")
>>> print(face_recognition.face_locations(img))
```
`zed` is obviously dead and not maintained anymore
(https://zef.me/how-to-abandon-open-source-d5ebbc6e45e5).
As the last upstream commit was in 2015 we faced and will face many
issues with its dependencies due to the outdated upstream which can be
fatal when having security issues in the NodeJS ecosystem to fix.
One example is the handling of `nwjs` which is currently version `0.23`,
but `zed` relies on `0.9`. In order to reduce the maintenance overload
because of dead packages it's better to get rid of `zed` entirely.
Fixes#37361
Origianlly the package was broken as bumping `pythonPackages.pillow` to
5.x broke `thumbor`. The latest upstream version `6.4.2` solved this
issue, so a simple package bump was sufficient.
Furthermore the following changes were made:
- moved the expression into its own file
- added myself as maintainer in case of any further breackage
- re-enabled python3 build: 6.4.2 is fine with python3, however the
`futures` dependency can't be satisfied anymore as it's part of
Python3. Therefore a patch for `setup.py` will be applied for Python3
buildsto drop the dependency
Note: the testsuite is disabled for now as several impure tests are done
and our testing environment seems to be unable to work the with the
natively compiled python modules properly.
Therefore I tested the module using the following expression:
``` nix
with import ./. {};
stdenv.mkDerivation {
name = "thumbor-test";
src = null;
buildInputs = [ python pythonPackages.thumbor ];
}
```
Inside this nix shell `thumbor` works fine and the native modules can be
imported.
See https://hydra.nixos.org/build/71062729/log
See ticket #36453
Aspino patched `libglucose` for their own uses, however they currently
depend on glucose v4.0.
(see https://github.com/alviano/aspino/tree/e31c3b4e5791a454e6602439cb26bd98d23c4e78/patches)
The patches don't apply properly on `glucose-4.1` anymore, furthermore
the new source directory caused the `bootstrap.sh` from `aspino` which
was supposed to apply the patches and recompile the setup to break.
Furthermore some minor changes to the derivation were introduced:
- upgraded from `2016-01-31` to `2017-03-09`
- the name contains an `-unstable-` infix as upstream has no releases
- instead of a `patchPhase` the `postPatch` hook will be used for
`substituteInPlace` to keep advanced patching features from `nixpkgs`
available.
- `patchShebangs` will be called to avoid impurities because of the
implicit reliance on `/bin/sh`
- added myself as second maintainer to have more people available in
case of any further breackage
See https://hydra.nixos.org/build/70688471/log
See ticket #36453
In order to adjust the language with `LC_ALL` properly the
`glibcLocales` is needed as `checkInput`. This was the only thing
preventing the testsuite from passing.
See ticket #36453
See https://hydra.nixos.org/build/70682982/nixlog/3
When compiling with GCC v7 and the `-Werror` flag several new warnings
caused the build to fail: https://hydra.nixos.org/build/70751457/nixlog/2
Note: I patched the CMake file manually as v4.3.0 is quite old, a v5 is
in progress, but isn't stable yet, so patching v4 seems to be the better
solution taking stability into account.
See tickets #31747 and #36453
This solves the `Cannot access native keychain` warning from
IntelliJ-based IDEs. Previously IDEA was unable to find `libsecret` as
it was not part of its library path.
Please keep in mind that the keyring daemon that can be enabled on
NixOS with `services.gnome3.gnome-keyring.enable = true` must be
running.
Currently the installation on Darwin fails due to a bug in the
installation script: https://github.com/NixOS/nixpkgs/pull/34840#issuecomment-369227222
As I lack knowledge and resources to properly test this package against
Darwin I'll disallow Darwin builds for now.
`uutils-coreutils` is an a cross-platform rewrite of GNU/coreutils based
on Rust. It aims to increase portability and improve Windows support
(see https://github.com/uutils/coreutils#why).
Since the derivation provides the same binaries as `coreutils` does a
`prefix` argument as been added to the function to avoid any conflicts
that can be used like this:
``` nix
self: super:
{
uutils-coreutils = self.uutils-coreutils.override { prefix = "uutils"; };
}
```
Resolves#28114 /cc @NeQuissimus
-----
Important notice: the patch depends on #34505 which needs to be merged
*FIRST* as it fixes a bug in the `rustc` setup of nixpkgs (see the PR's
discussion and https://github.com/rust-lang/cargo/commit/5c9665f41c6b4d3b99d3b9f8b48a286f5f154692#commitcomment-27271420 for further reference).
This drastically reduces the complexity of the `avidemux` derivation
and adds QT5 support (see #33248).
Rather than invoking `cmake` over preconfigured hooks, it's much easier
to use the `bootStrap.bash` script provided by the developers to do the
installation tasks. Furthermore this script makes it way easier to
configure which parts of `avidemux` should be used (e.g. CLI-only) or
without the plugins.
In order to create a CLI-only instance you can simply override the
derivation:
```
avidemux.override {
withQT = false;
}
```
It's possible to set the default executable as well (`avidemux` creates
a `avidemux_qt5` and `avidemux_cli` executable by default):
```
avidemux.override {
default = "cli"; # default is `qt5`
}
```
The GTK support has been dropped entirely since it was originally broken
in our system and can't be built ATM. Other distros such as ArchLinux
don't support GTK anymore (see https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/avidemux#n64)
`pythonPackages.docker` isn't compatible with `docker-compose` 1.18 and
causes severe breackage when running `docker-compose up --build`.
See https://github.com/docker/compose/issues/5685 for further reference.
This reverts commit 2a8a058a21.
Sometimes it's needed to override parts of `vim_configurable`, for
instance when using ENSIME (http://ensime.github.io/), in this case you
need a Python interpreter and the modules `sexpdata` and
`websocket_client`.
However overriding `vim_configurable` is quite hard as we run
`vimUtils.makeCustomizable` over the default comming from
`configurable.nix`. Therefore it's necessary to copy the code from
`all-packages.nix` and alter the parts you need: https://nixos.org/nix-dev/2017-April/023364.html
In order to simplify overriding `vim_configurable` I added an
`override` and an `overrideAttrs` function to `vimutils.makeCustomizable`
to ensure that the customization capabilities won't be lost after
altering the derivation.
Now it's possible to write expressions like this without evaluation
failures:
```
with pkgs;
let
vimPy3 = vim_configurable.override {
python = python3;
};
in vimPy3.customize { ... }
```
`pythonPackages.parameterized` is the successor of `nose-parameterized`
as the authors of the module decided to support more testing frameworks
and stopped focusing on `noes` only. `nose-parameterized` is still
available in `pypi` with version `0.6.0`, but is officially deprecated.
However the renaming happened quite recently so it is possible that
there are still folks relying on `nose-parameterized`. Therefore I moved
the expression to provide a `pythonPackages.parameterized` derivation
and added a package override which builds `nose-parameterized` after
yielding a deprecation warning.
`nixos-generate-config` detects the `cpuFreqGovernor` suited best for my
machine, e.g. `powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";`.
However the `powerManagement` module sets a sensitive default for
`cpuFreqGovernor` using `mkDefault` to avoid breackage with older
setups. Since 140ac2f1 the `hardware-configuration.nix` sets the
gorvernor with `mkDefault` as well which causes evaluation errors if the
powermanagement module is enabled:
```
error: The unique option `powerManagement.cpuFreqGovernor' is defined multiple times, in `/home/ma27/Projects/nixos-config/hardware-configuration.nix' and `/nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs/nixos/modules/config/power-management.nix'.
```
Using `mkOptionDefault` rather than `mkDefault` in the powermanagement
module fixes this issue as it decreases the priority of the module and
prefers the value set in `hardware-configuration.nix`.
I have confirmed the change using the following VM declaration:
```
{
cpuFreq = { lib, ... }: {
powerManagement.cpuFreqGovernor = lib.mkDefault "powersave";
powerManagement.enable = true;
};
}
```
The following changes landed in master:
- Reset colors unconditionally (2f1ee69d4c75e210265dca732ff6c2ddd7f440f2)
- Document NixOS support (993f1b5a7bc2a41a353a104cff0763860c053c92)
- ya_int_song: improve configuration of playerctl properties (1f776cd5f1f4e89e6ebca3ca09feb7e09f79e79e)
The default cache directory set by oh-my-zsh is $ohMyZsh/cache which
lives in the Nix store in our case. This causes issues with several
completion plugins provided by oh-my-zsh.
This change sets an environment variable to ensure that Android Studio
uses the correct drivers to avoid any breackage when trying to run a
native application on a virtual device.
Without proper configuration `android-studio` would be unable to load
the drivers for the AVD and yield messages like this:
```
3:32 PM Executing tasks: [:app:assembleDebug]
3:32 PM Emulator: libGL error: unable to load driver: i965_dri.so
3:32 PM Emulator: libGL error: driver pointer missing
3:32 PM Emulator: libGL error: failed to load driver: i965
3:32 PM Emulator: libGL error: unable to load driver: i965_dri.so
3:32 PM Emulator: libGL error: driver pointer missing
3:32 PM Emulator: libGL error: failed to load driver: i965
3:32 PM Emulator: libGL error: unable to load driver: swrast_dri.so
3:32 PM Emulator: libGL error: failed to load driver: swrast
3:32 PM Emulator: X Error of failed request: BadValue (integer parameter out of range for operation)
3:32 PM Emulator: Major opcode of failed request: 155 (GLX)
3:32 PM Emulator: Minor opcode of failed request: 24 (X_GLXCreateNewContext)
3:32 PM Emulator: Value in failed request: 0x0
3:32 PM Emulator: Serial number of failed request: 64
3:32 PM Emulator: Current serial number in output stream: 65
3:32 PM Emulator: emulator: ERROR: Missing initial data partition file: /home/ma27/.android/avd/Nexus_5X_API_27.avd/userdata.img
3:32 PM Emulator: Process finished with exit code 1
3:32 PM Gradle build finished with 2 warnings(s) in 6s 378ms
```
For further reference have a look at the following StackOverflow
message: https://stackoverflow.com/a/40790339
To make the configuration of `yabar` more pleasant and easier to
validate, a NixOS module will be quite helpful.
An example config could look like this:
```
{
programs.yabar = {
enable = true;
bars.top.indicators.exec = "YA_DATE";
};
}
```
The module adds a user-controlled systemd service which runs `yabar` after
starting up X.
It is quite complicated to test services using the test-driver when
declaring user services with `systemd.user.services` such as many
X11-based services like `xautolock.service`.
This change adds an optional `$user` parameter to each systemd-related
function in the test-driver and runs `systemctl --user` commands using
`su -l $user -c ...` and sets the `XDG_RUNTIME_DIR` variable
accordingly and a new function named `systemctl` which is able to run a
systemd command with or without a specified user.
The change can be confirmed with a simple VM declaration like this:
```
import ./nixos/tests/make-test.nix ({ pkgs, lib }:
with lib;
{
name = "systemd-user-test";
nodes.machine = {
imports = [ ./nixos/tests/common/user-account.nix ];
services.xserver.enable = true;
services.xserver.displayManager.auto.enable = true;
services.xserver.displayManager.auto.user = "bob";
services.xserver.xautolock.enable = true;
};
testScript = ''
$machine->start;
$machine->waitForX;
$machine->waitForUnit("xautolock.service", "bob");
$machine->stopJob("xautolock.service", "bob");
$machine->startJob("xautolock.service", "bob");
$machine->systemctl("list-jobs --no-pager", "bob");
$machine->systemctl("show 'xautolock.service' --no-pager", "bob");
'';
})
```
These packages will be placed into an environment using
`backendsToPackages`. This function explicitly maps backends to
`pkgs.nodePackages.${type}` unless it's a builtin. This ensures that only
valid backends that work on NixOS are used (if not, the build already
breaks at evaluation time).
The log will be redirected to `stdout` to be able to watch the entire
output using `journalctl`.
Configuration parameters for the backends need to be set using
`services.statsd.extraConfig` as each backend has its own options and
all of them shouldn't be validated and checked explicitly and manually.
The 0.16-releases contain several useful new features:
https://launchpad.net/stellarium/0.16/0.16.1
I also added myself as maintainer to have more people available if the
package breaks a release.
Airfield suffered from loose version constraints which
caused severe version (and API) conflicts between its dependencies
and transitive ones.
Furthermore the `npm2nix` packaging is deprecated and needed to be
replaced by `node2nix`.
see #31032
`nixos-option` evals the description and the '`' is used to
define shell commands.
Due to this, the following error appears:
```
$ nixos-option services.postgresql.superUser
Value:
"root"
Default:
"root"
Description:
/run/current-system/sw/bin/nixos-option: line 294: root: command not found
/run/current-system/sw/bin/nixos-option: line 294: postgres: command not found
NixOS traditionally used as superuser, most other distros use .
From 17.09 we also try to follow this standard. Internal since changing this value
would lead to breakage while setting up databases.
```
Maximilian Bosch