This fixes an eval error introduced by
17a069276f.
The reason the evaluation fails is because there's an assertion on the
version of the Python library in order to be in par with the top-level
libvirt package.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @fpletz
The build for the version 5.4.0 of digiKam has been broken at the time
prior to this commit, which is the main reason for this update as I
don't think it makes sense to fix the build for 5.4.0 when we're going
to update it anyway.
A lot has changed upstream between version 5.4.0 and 5.7.0 and it's too
much to be summarized here, so here are the URLs to the upstream
announcements:
* https://www.digikam.org/news/2017-03-14_digiKam_5.5.0_is_released/
* https://www.digikam.org/news/2017-06-21-5.6.0-release-announcement/
* https://www.digikam.org/news/2017-09-11-5.7.0_release_announcement/
On the packaging side, we now no longer have the patch that disables
-fno-operator-names because the build runs fine without that patch
(which didn't even apply but I didn't check why) and IMO it doesn't make
sense to rebase that patch for no reason.
Additionally, there were build time dependencies lurking around in
propagatedBuildInputs, which is kinda pointless and the application just
runs fine if those dependencies are listed in buildInputs.
While looking for clues about why that might be necessary I haven't
found any comment about it in the source nor a clarification within the
message of the commit where this has been introduced.
The commit in question is be7b7d908f.
Apart from these changes, the rest is just adding a few dependencies
(kcalcore, libksane, mesa and pcre) to get less errors during
cmakeConfigurePhase.
I've tested digiKam by playing around within a VM using photos I
netcat'ed into it and it works so far. The VM was built using:
nix-build nixos --arg configuration '{ pkgs, ... }: {
imports = [ ./nixos/tests/common/user-account.nix ];
environment.systemPackages = [ pkgs.digikam ];
services.xserver.enable = true;
services.xserver.displayManager.sddm.enable = true;
services.xserver.desktopManager.plasma5.enable = true;
services.xserver.desktopManager.default = "plasma5";
virtualisation.memorySize = 1024;
}' -A vm
What I didn't test however was whether importing from a camera would
work (as I don't have one), but aside from that, the application seems
to run fine compared to the fact that it didn't even build until now :-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @the-kenny, @urkud, @viric, @cillianderoiste, @ttuegel
Cc: @jraygauthier, @fkz, @sh01, @lsix
This was actually already mentioned in the comment above version:
Awaiting upcoming `v1.12.0` release. `v1.11.0` is not supporting
cmake which is the the reason behind taking an unstable git rev.
So version 1.12.0 has been released in the meantime and it's also needed
by the latest version of digiKam, which is the only package in nixpkgs
that depends on libqtav.
As we're going to bump digiKam, I think bumping this is safe as in the
worst case we can only make things broken which are already broken
(digiKam currently doesn't build).
The fixes for the CMakeLists.txt are now also no longer needed, so we
can safely drop them as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @jraygauthier
The submodule of the "docker-containers" option isn't recognized as a
proper submodule and thus neither properly type-checks nor are its
options included in the manual.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by a02bb00156.
The fix is done by disabling writableStore, because the latter will set
up an overlayfs on the Nix store within the VM, which in turn will
discard all the outputs of the resulting output path.
However in runInMachine we actually *want* the contents of the generated
path and also don't want a writable store within the VM (except of
course for $out, which is writable anyway).
I've added a small regression test to verifify the output in
nixos/tests/run-in-machine.nix to make sure this won't break again in
the future.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 801c920e95.
Since then, the btrfsSimple subtest of the installer VM test fails with:
Btrfs did not return a path for the subvolume at /
The reason for this is that the output for "btrfs subvol show" has
changed between version 4.8.2 and 4.13.1.
For example the output of "btrfs subvol show /" in version 4.8.2 was:
/ is toplevel subvolume
In version 4.13.1, the output now is the following and thus the regular
expressions used in nixos-generate-config.pl and install-grub.pl now
match (which results in the error mentioned above):
/
Name: <FS_TREE>
UUID: -
Parent UUID: -
Received UUID: -
Creation time: -
Subvolume ID: 5
Generation: 287270
Gen at creation: 0
Parent ID: 0
Top level ID: 0
Flags: -
Snapshot(s):
In order to fix this I've changed nixos-generate-config.pl and
install-grub.pl, because both use "btrfs subvol show" in a similar vein,
so the regex for parsing the output now doesn't match anymore whenever
the volume path is "/", which should result in the same behaviour as we
had with btrfs-progs version 4.8.2.
Tested against the btrfsSimple, btrfsSubvols and btrfsSubvolDefault
subtests of the installer VM test and they all succeed now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This option got introduced in 7904499542
and it didn't check whether mailUser and mailGroup are null, which they
are by default.
Now we're only creating the user if createMailUser is set in conjunction
with mailUser and the group if mailGroup is set as well.
I've added a NixOS VM test so that we can verify whether dovecot works
without any additional options set, so it serves as a regression test
for issue #29466 and other issues that might come up with future changes
to the Dovecot service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #29466
Cc: @qknight, @abbradar, @ixmatus, @siddharthist
New features since version 3.2.0:
* G'MIC Plugin
* Touch Painting
* Smart Patch Tool
* New Brush Presets
The full release notes can be found at:
https://krita.org/en/release-notes-for-krita-3-2/
Version 3.2.1 contains these fixes:
* Crash on startup if only OpenGL 2.1 is found: if you had to disable
opengl for 3.2.0, you can try to enable it again
* A crash when changing layer types in the gmic-qt plugin
* A bug where gmic-qt could crash on odd-sized images
* A regression where using the text tool would break the brush tool
* The option to use the native platform's file dialogs was restored
* A bug where selecting the line tool would disable the flow slider
* Some issues with the LUT docker were fixed
Upstream release notes for 3.2.1:
https://krita.org/en/item/krita-3-2-1-released/
I've dropped the patch, because it was already from the upstream
development version and thus is also included in this release.
Built and tested using a few images and just playing around with a few
new features.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar, @Mic92, @kragniz
Quoting from @FRidh:
Note overridePythonAttrs exists since 17.09. It overrides the call to
buildPythonPackage.
While it's not strictly necessary to do this, because postPatch ends up
in drvAttrs anyway, it's probably better to use overridePythonAttrs so
we don't run into problems when the underlying implementation of
buildPythonPackage changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is a rebased version of the pull request with small fixes due to
changes in recent master.
Original description from the pull request:
Currently this is only a very basic test which gets certificates via
the enableACME option of the nginx module.
However the main reason why I'm not directly merging and putting this
up for review is that the complexity here lies in the support-modules
needed for the test. The support modules are for running a Boulder
instance along with a DNS resolver (as a separate module).
For details about the implementation, see the commit messages and the
comments at the start of the respective support modules.
I'm merging this first of all because other than @abbradar, none of the
other requested reviewers did comment on the changes and second because
the change here is adding a test, so even if the implementation would be
so disgusting and crappy it's better than having no test at all.
The comment of @abbradar was:
Can't we factor Boulder into a proper package and a NixOS service?
Maybe not very general purpose for now but still -- putting everything
into one test seems painful to me.
My objection to this is that the components are heavily patched and some
of them don't even have a release, so I'm not sure whether infesting
pkgs/ with them is really a good idea.
Nevertheless, we can still do that later.
Cc: @fpletz, @domenkozar, @bjornfor
Since 67651d80bc the requests package now
depends on certifi, which in turn provides the CA root certificates that
we need to replace.
It might also be a good idea to actually patch certifi with our version
of cacert by default so that if we want to override and/or add something
we only need to do it once.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @fpletz, @k0ral, @FRidh
The enableSSL option has been deprecated in
a912a6a291, so we switch to using onlySSL.
I've also explicitly disabled enableACME, because this is the default
and we don't actually want to have ACME enabled for a host which runs an
actual ACME server.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The test here is pretty basic and only tests nginx, but it should get us
started to write tests for different webservers and different ACME
implementations.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
These modules implement a way to test ACME based on a test instance of
Letsencrypt's Boulder service. The service implementation is in
letsencrypt.nix and the second module (resolver.nix) is a support-module
for the former, but can also be used for tests not involving ACME.
The second module provides a DNS server which hosts a root zone
containing all the zones and /etc/hosts entries (except loopback) in the
entire test network, so this can be very useful for other modules that
need DNS resolution.
Originally, I wrote these modules for the Headcounter deployment, but
I've refactored them a bit to be generally useful to NixOS users. The
original implementation can be found here:
https://github.com/headcounter/deployment/tree/89e7feafb/modules/testing
Quoting parts from the commit message of the initial implementation of
the Letsencrypt module in headcounter/deployment@95dfb31110:
This module is going to be used for tests where we need to
impersonate an ACME service such as the one from Letsencrypt within
VM tests, which is the reason why this module is a bit ugly (I only
care if it's working not if it's beautiful).
While the module isn't used anywhere, it will serve as a pluggable
module for testing whether ACME works properly to fetch certificates
and also as a replacement for our snakeoil certificate generator.
Also quoting parts of the commit where I have refactored the same module
in headcounter/deployment@85fa481b34:
Now we have a fully pluggable module which automatically discovers
in which network it's used via the nodes attribute.
The test environment of Boulder used "dns-test-srv", which is a fake
DNS server that's resolving almost everything to 127.0.0.1. On our
setup this is not useful, so instead we're now running a local BIND
name server which has a fake root zone and uses the mentioned node
attribute to automatically discover other zones in the network of
machines and generate delegations from the root zone to the
respective zones with the primaryIPAddress of the node.
...
We want to use real letsencrypt.org FQDNs here, so we can't get away
with the snakeoil test certificates from the upstream project but
now roll our own.
This not only has the benefit that we can easily pass the snakeoil
certificate to other nodes, but we can (and do) also use it for an
nginx proxy that's now serving HTTPS for the Boulder web front end.
The Headcounter deployment tests are simulating a production scenario
with real IPs and nameservers so it won't need to rely on
networking.extraHost. However in this implementation we don't
necessarily want to do that, so I've added auto-discovery of
networking.extraHosts in the resolver module.
Another change here is that the letsencrypt module now falls back to
using a local resolver, the Headcounter implementation on the other hand
always required to add an extra test node which serves as a resolver.
I could have squashed both modules into the final ACME test, but that
would make it not very reusable, so that's the main reason why I put
these modules in tests/common.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream bug fixes:
* pen and touchscreen input handling bugfixes
* fix a minor bug with save file paths in Windows (D. German)
* use GDK macros (not WIN32) to disable X11-specific code (T.
Schoonjans)
* export to PDF and printing: fix resolution loss on some pdf
backgrounds
* disable xinput during modal dialog boxes
* avoid data corruption when exporting to overwrite a PDF
* fix path search order for toolbar bitmaps
* text and image tools activate on button release instead of button
press to avoid subsequent confusion between clicks in toolbar and
drawing area
* fix "pen disable touch" when touchscreen sends prox events (A.
Kittenberger)
* fix crash when pasting text or images via xclip
* updated Italian translation (Marco Ciampa)
New upstream features:
* add space and shift-space bindings to page down/up (D. German)
* add A5 paper (D. German)
* config option to export successive layers to separate PDF pages
* config option to create new file when trying to open non-existent
.xoj
The full change log along with bug numbers can be found at:
https://sourceforge.net/p/xournal/code/ci/Release-0_4_8_2016/tree/ChangeLog
I've dropped gdk-quartz-backend.patch, because I believe it has been
fixed upstream.
Here are the upstream changes relevant for the patch (shortened, because
SourceForge has really long URLs):
http://bit.ly/2vXW8n0 -> src/Makefile.am
http://bit.ly/2gDnjl7 -> src/xo-file.c
http://bit.ly/2xJ5K7A -> src/xo-misc.c
Tested building and using the application.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c, @dguibert
Cc: @johbo who has introduced the patch in #21842
I missed this in 799435b7ca.
This time I used "git grep -F pythonPackages.deluge" just to be sure :-)
Thanks a lot to @roconnor for spotting this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @roconnor
Upstream changes:
* Tesseract 4.00.00alpha:
* Version parsing: Ignore suffix (so '4.00.00alpha' == (4, 0, 0))
* Libtesseract: Load libtesseract.so.4 instead of libtesseract.so.3
if available
* Support for Tesseract 3.05.00:
* Builders: Split field 'tess_conf' into 'tess_flags' and 'tess_conf'
* Libtesseract: If available, use
TessBaseAPIDetectOrientationScript() instead of
TessBaseAPIDetectOS
* Libtesseract:
* Workaround: Prevents possible segfault in image_to_string() when
the target language is not available
Full upstream change log can be found at:
https://github.com/openpaperwork/pyocr/blob/b006123d1d002711b9/ChangeLog
The tesseract.patch for supporting Tesseract version 3.05.00 has been
applied upstream and we can safely drop it.
We now use substituteInPlace in conjunction with a patch to insert the
relevant store paths instead of sed, so it's less fragile whenever we
have upstream changes in handling of these paths.
I've tested this by reverting 48a941e29f and applying a build
fix patch of Cuneiform 1.1.0 from Arch Linux, because right now
Cuneiform is an experimental version that can't be fixed on behalf of
pyocr (the reason is that pyocr needs to get a list of languages, which
doesn't work in that version anymore).
In addition to that I've successfully built paperwork-backend which by
now is the one package which depends on pyocr. However, I didn't do
runtime tests of Paperwork.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c
We already have a patch feeling lonely inside the python-modules
directory and to have everything at one place let's actually move pyocr
into its own dedicated directory so it's easier to patch it up (which
we're going to).
Right now, the package fails to build because of a few test failures, so
I haven't tested this apart from evaluating.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In order to run the tests for the external plugins of beets, we need to
have beets itself as a dependency. So in order to do that, we now pass
beets without plugins and tests to the nativeBuildInputs of the plugins
so that we can run them.
As soon as the plugins are built they become part of the final beets,
which also has tests enabled, so disabling the tests for beets
derivation that is used for external plugin tests is a non-issue here
because they're going to be executed anyway.
Enabling tests for the alternatives plugin is pretty straightforward,
but in order to run tests for the copyartifacts plugin, we need to bump
the source code to the latest Git master.
The reason for this is that the version that was in use until now
required to have the beets source directory alongside of the
copyartifacts source code, but we already have beets available as a
normal dependency.
Updating copyartifacts to latest master largely consists of unit test
changes and a few Python 3 compatibility changes. However, one change
has the biggest stat, which is
sbarakat/beets-copyartifacts@1a0c281da0.
Fortunately, the last change is just moving the implementation to a
newer API from upstream beets and by the looks of the implementation it
seems to break support for moving files. However, reverting this commit
also reveals that moving files was already broken before, so it wouldn't
matter much whether we have this version bump or not.
Tested with the following command:
nix-build -E '(import ./. {}).beets.override {
enableAlternatives = true;
enableCopyArtifacts = true;
}'
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @Profpatsch, @michalrus
Regression introduced by 94351197cd.
Running the tests results in the following traceback:
...
File ".../unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File ".../test/regrtest.py", line 184, in <module>
for module in sys.modules.itervalues():
RuntimeError: dictionary changed size during iteration
The reason for this is that the test directory itself is called "test"
and the package including regrtest.py is also called "test", so the
loader tries to load tests from its own implementation.
We could fix this by changing PYTHONPATH and/or making the test
directory a proper package, but we'd still have failing tests because
beets itself is required to run the tests.
However for now I'm just removing the unit_tests kwarg in setup.py so
that we have the same behaviour as before the initially mentioned
commit.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by fa5e343242.
The deluge package no longer resides in pythonPackages but now is a
top-level package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @grantwwu, @fpletz
This has been introduced in 6a6fb6d31c.
Relying on non-free software by default is probably a bad idea. Apart
from the fact that (sane) people usually don't want to have it sitting
on their system even people who don't care will have to set
"allowUnfree" to true in order to install conky.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @canndrew, @Mic92
From the upstream changelog:
Version 0.9.34:
* quick fix to "Assertion mapInfo.count" failed, don't mess with these
addrman structures!
Version 0.9.33:
* fix serious connectivity problem: not trying to connect to >=0.9.30
peers with random ports.
Version 0.9.31:
* backport from upstream (arvidn/libtorrent@677e642):
fixed uTP vulnerability from
The fixes in 0.9.31 are a bit more serious and it actually contains two
fixes from what I've been able to dig through:
* https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-5685
* https://www.us-cert.gov/ncas/alerts/TA14-017A
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 520a43ced3.
Using XML tag characters for things that are not tags needs to be
properly indicated by an entity.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 1ded0cb24c.
The package defines macros for min() and max(), but those macros are
undefined by the inclusion of stdlib.h since GCC 6.x, so we need to
change tho order of inclusions to include stdlib.h *before* NoWindows.h.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This updates canto-daemon to version 0.9.7 and canto-curses to version
0.9.9. I've tested building both and executing them (although without
very comprehensive tests) and they do work on my machine.
I haven't tested the NixOS service module however, but given that
@devhell is also the maintainer of these packages and the service
module, I trust that he's done testing by himself.
Regression introduced by 345b35c48a.
The commit in question switched the implementation of buildPythonPackage
so that .override now is behaving the same way as for other packages
that are using callPackage.
So the fix for html5lib_0_9999999 is to just use .overridePythonAttrs
instead of .override.
Note that the mentioned commit initially introduced this as
overridePythonPackage but it got later renamed to overridePythonAttrs in
abdb58e407.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Evaluation error introduced in a0d464033c.
If the value for timeZone is null it shouldn't be even tried to coerce
it into a string.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann, @joachifm
Tested via building the linux_testing attribute, but didn't test it at
runtime (yet).
Diffed unpacked tarball against my local git clone and the contents
match.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Checking the keyboard layout has been a long set of hurdles so far, with
several attempts. Originally, the checking was introduced by @lheckemann
in #23709.
The initial implementation just was trying to check whether the symbols/
directory contained the layout name.
Unfortunately, that wasn't enough and keyboard variants weren't
recognized, so if you set layout to eg. "dvorak" it will fail with an
error (#25526).
So my improvement on that was to use sed to filter rules/base.lst and
match the layout against that. I fucked up twice with this, first
because layout can be a comma-separated list which I didn't account for
and second because I ran into a Nix issue (NixOS/nix#1426).
After fixing this, it still wasn't enough (and this is btw. what
localectl also does), because we were *only* matching rules but not
symbols, so using "eu" as a layout won't work either.
I decided now it's the time to actually use libxkbcommon to try
compiling the keyboard options and see whether it succeeds. This comes
in the form of a helper tool called xkbvalidate.
IMHO this approach is a lot less error-prone and we can be sure that we
don't forget about anything because that's what the X server itself uses
to compile the keymap.
Another advantage of this is that we now validate the full set of XKB
options rather than just the layout.
Tested this against a variety of wrong and correct keyboard
configurations and against the "keymap" NixOS VM tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann, @peti, @7c6f434c, @tohl, @vcunat, @lluchs
Fixes: #27597
Regression introduced by 2799a94963.
Attribute zfsStable and zfsUnstable are now gone for the package
expression itself.
The mentioned commit however only changed the reference in
all-packages.nix for the kernel module, but not the userland package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @globin
The patch is from Arch Linux at:
https://aur.archlinux.org/cgit/aur.git/tree/linux412.patch?h=broadcom-wl
Tested this by building against the following attributes:
* linuxPackages.broadcom_sta
* linuxPackages_latest.broadcom_sta
* pkgsI686Linux.linuxPackages.broadcom_sta
* pkgsI686Linux.linuxPackages_latest.broadcom_sta
I have not tested whether this works at runtime, because I do not posess
the hardware.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The helper tool had a very early check whether the automatically created
CA key/cert are available and thus it would abort if the key was
unavailable even though we don't need or even want to have the CA key.
Unfortunately our NixOS test didn't catch this, because it was just
switching from a configuration with an automatically created CA to a
manual configuration without deleting the generated keys and certs.
This is done now in the tests and it's also fixed in the helper tool.
Reported-by: @jpotier
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Compiling the kernel modules on Linux 4.12 fails, so I've included an
upstream patch from:
https://www.virtualbox.org/changeset/66927/vbox
The patch is applied against the guest additions as well, where we need
to transform the patch a bit so that we get CR LF line endings (DOS
format), which is what is the case for the guest additions ISO.
I've tested this with all the subtests of the "virtualbox" NixOS VM
tests and they all succeed on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Regression introduced by 44c64fef16.
The services.xserver.layout option allows to specify more than one
layout separated by comma, which the commit above didn't take into
account.
This is very similar to @lheckemann's pull request (#26984) but differs
in the following ways:
* Print out the full list available layouts (as suggested by @0xABAB
in [1]).
* Loop over $layout using the default IFS (and thus no need for
escaping ${cfg.layout}), because the layouts won't contain white
spaces.
* Re-do the error message, which now uses multiple echos instead of a
heredoc, so the line is wrapped according to the viewers terminal
width.
I've tested this with several good and bad layouts and also against the
keymap NixOS VM subtests.
[1]: https://github.com/NixOS/nixpkgs/pull/26984#discussion_r125146700
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #26961Closes: #26984
The following errors occur when you start Chromium prior to this commit:
[2534:2534:0625/202928.673160:ERROR:gl_implementation.cc(246)] Failed to
load .../libexec/chromium/swiftshader/libGLESv2.so:
../libexec/chromium/swiftshader/libGLESv2.so: cannot open shared object
file: No such file or directory
[2534:2534:0625/202928.674434:ERROR:gpu_child_thread.cc(174)] Exiting
GPU process due to errors during initialization
While in theory we do not strictly need libGLESv2.so, in practice this
means that the GPU process isn't starting up at all which in turn leads
to crawling rendering performance on some sites.
So let's install all shared libraries in swiftshader.
I've tested this with the chromium.stable NixOS VM test and also locally
on my machine and the errors as well as the performance issues are gone.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
First of all, we need a newer version of Vc, because at least version
1.1.0 is required for Krita 3.1.3.
Also, qtmultimedia and qtx11extras were missing.
Built and tested successfully on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
The merge of the version bump in
6fb9f89238 didn't take care of our patch
for the hardening mode and thus enabling VirtualBox without also
force-disabling hardening mode will result in a build error.
While the patch is largely identical with the old version, I've removed
one particular change around the following code:
if (pFsObjState->Stat.st_mode & S_IWOTH)
return supR3HardenedSetError3(VERR_SUPLIB_WORLD_WRITABLE, pErrInfo,
"World writable: '", pszPath, "'");
In the old version of the patch we have checked whether the path is
within the Nix store and suppressed the error return if that's the case.
The reason why I did that in the first place was because we had a bunch
of symlinks which were writable.
In VirtualBox 5.1.22 the code specifically checks whether the file is a
symlink, so we can safely drop our change.
Tested via all of the "virtualbox" NixOS VM subtests and they now all
succeed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
On several occasions I've seen people bumping packages which have NixOS
tests but without actually running them.
While this probably won't prevent such occasions entirely, at least it
serves as an additional checklist item so contributors don't forget
about these tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since 9c57f3b5c0 bumped the protobuf
version because the new upstream requires it, electrum now gets
protobuf3_0 *and* protobuf3_2 instead of just one version.
This leads to the following build errer:
Found duplicated packages in closure for dependency 'protobuf':
protobuf 3.0.2 (...-python2.7-protobuf-3.0.2/lib/python2.7/site-packages)
protobuf 3.2.0 (...-python2.7-protobuf-3.2.0/lib/python2.7/site-packages)
Using protobuf3_2 for keepkey and electrum fixes the build.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @np
Regression introduced by 76beb08313.
With version 0.7.15 a few additional dependencies are needed by trezor,
mainly a newer version of protobuf bindings and requests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @np
Tesseract seems to have a hard time detecting the "ALICE FOOBAR" text,
so let's match on "Select your user and enter password" instead.
Ran the test on x86_64-linux and it now succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With newer Nix it's (fortunately) no longer possible to create a file
with setuid bits, even though the permissions are fixed later the build
will fail during installPhase already.
I've verified whether the contents of the output path are the same as
before this change and the contents match.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We really want to break channel updates whenever we break something like
this, because this actually will hit machines out there and can be very
much annoying (we had broken keymaps a few times which is why I
introduced these tests in the first place).
Just to be sure I don't break channel updates with this commit, I ran
all of the keymap tests and they all succeeded.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Enumerating the symbols directory doesn't include variants, so we're now
basically doing what "localectl list-x11-keymap-layouts" does but we use
sed instead.
The reason I'm not using localectl directly is because the path to
rules/base.lst is hardcoded in the systemd source.
Of course, the XKB specification allows for much more complicated rules,
but at least this should cover the most basic ones including variants.
So the sed expression itself is just for listing the available layouts
and variants and we use a grep with -xF to match only full lines without
interpreting regular expressions.
This should again allow to set "dvorak" as the layout option.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @lheckemann
Fixes: #25526
Upstream changes:
* Added OpenSSL.X509Store.set_time() to set a custom verification time
when verifying certificate chains. pyca/pyopenssl#567
* Added a collection of functions for working with OCSP stapling. None
of these functions make it possible to validate OCSP assertions, only
to staple them into the handshake and to retrieve the stapled
assertion if provided. Users will need to write their own code to
handle OCSP assertions. We specifically added:
Context.set_ocsp_server_callback, Context.set_ocsp_client_callback,
and Connection.request_ocsp. pyca/pyopenssl#580
* Changed the SSL module's memory allocation policy to avoid zeroing
memory it allocates when unnecessary. This reduces CPU usage and
memory allocation time by an amount proportional to the size of the
allocation. For applications that process a lot of TLS data or that
use very lage allocations this can provide considerable performance
improvements. pyca/pyopenssl#578
* Automatically set SSL_CTX_set_ecdh_auto() on OpenSSL.SSL.Context.
pyca/pyopenssl#575
* Fix empty exceptions from OpenSSL.crypto.load_privatekey().
pyca/pyopenssl#581
The full upstream changelog can be found at:
https://pyopenssl.readthedocs.io/en/17.0.0/changelog.html
I've also added a patch from pyca/pyopenssl#637 in order to fix the
tests, which was the main reason for the version bump because that patch
won't apply for 16.2.0.
According to the upstream changelog there should be no
backwards-incompatible changes, but I've tested building against some of
the packages depending on pyopenssl anyway. Regardless of this, the
build for pyopenssl fails right now anyway, so the worst that could
happen via this commit would be that we break something that's already
broken.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should allow us to easily add system-wide Chromium extensions via a
NixOS configuration similar to this:
{ pkgs, ... }: {
environment.pathsToLink = [ "/share/chromium/extensions" ];
environment.systemPackages = [ pkgs.my-shiny-extension ];
}
For more details about what Chromium expects within that directory, see:
https://developer.chrome.com/extensions/external_extensions
I've introduced this because of a personal desire to gain more control
about which extensions are installed and what they are able to do. All
of the extensions I use are free software, but despite that it's useful
to either easily patch them and also prevent unwanted automatic updates.
Tested this using the NixOS "chromium.stable" test on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @offlinehacker because of #21050
When you have a setup consisting of multiple monitors, the default is
that the first monitor detected by xrandr is set to the primary monitor.
However this may not be the monitor you need to be set as primary. In
fact this monitor set to primary may in fact be disconnected.
This has happened for the original submitter of the pull request and it
affected these programs:
* XMonad: Gets confused with Super + {w,e,r}
* SDDM: Puts the login screen on the wrong monitor, and does not
currently duplicate the login screen on all monitors
* XMobar: Puts the XMobar on the wrong monitor, as it only puts the
taskbar on the primary monitor
These changes should fix that not only by setting a primary monitor in
xrandrHeads but also make it possible to make a different monitor the
primary one.
The changes are also backwards-compatible.
Someone on IRC wanted to boot Fedora from another disk. While I'm not
too familiar with UEFI booting in conjunction with GRUB2 it took some
time to get it to work.
So in order to safe others from frustration I'm adding this as another
example to the extraEntries option.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
It was asked by @CMCDragonkai to elaborate on that, so let's just do
this by actually providing a code comment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The xrandrHeads option has been there since a long time, so there is no
need to advertise it as a new feature.
Instead, let's focus on just what has changed, which is that we now
assign one head to be primary.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using invalid module options in the submodule isn't very nice, because
it doesn't give very useful errors in case of type mismatch, also we
don't get descriptions of these options as they're effecively
nonexistent to the module system. Another downside of this is that
merging of these options isn't done correctly as well (eg. for
types.lines).
So we now have proper submodules for each xrandrHead and we also use
corcedTo in the type of xrandrHeads so that we can populate the
submodule's "output" option in case a plain string is defined for a list
item.
Instead of silently skipping multiple primary heads, we now have an
assertion, which displays a message and aborts configuration evaluation
appropriately.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In c6b3c66277, the unstable version has
been bumped to 2.6.
Unfortunately the staging source is re-using the version attribute from
the unstable source and thus has been bumped as well.
I have built wineStaging on x86_64-linux and it now succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @FRidh
This is currently our default display manager, so I'm adding this to the
"tested" job as well to ensure we don't ship broken revisions where X is
most likely not working.
The test uses a custom SLiM theme that's specifically tailored for good
OCR results (mainly white background and black fonts without anything
else), because our default NixOS theme has a very small contrast between
background and fonts in some places.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The main change here is a patch of SLiM to tread a log file of
/dev/stderr specially in that it now uses std::cerr instead of a file
for logging.
This allows us to set the logfile to stderr in NixOS for the generated
SLiM configuration file and we now get logging to the systemd journal.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has surfaced since d990aa7163.
The "simpleUefiGummiboot" installer test fails since this commit,
because that commit introduced a small check to verify whether the store
was altered.
While installing NixOS for the first time, the store is usually in
/mnt/nix/store and without the read-only bind mount that's preventing
programs from altering the store.
So after nixos-install is done creating the system closure and setting
it as the active system profile, the bootloader is written from the
closure inside the chroot. The systemd-boot-builder is invoked during
this step, which adds .pyc files for various Python modules of the
Python 3 store path, which in turn invalidates the hash of the Python 3
store path itself.
At the time the system is booted up again, the nix-store is verified and
fails with something like this:
path /nix/store/zvm545rqc4d97caqq9h7344bnd06jhzb-python3-3.5.3 was
modified! expected hash
b2c975f4b8d197443fbb09690fb3f6545e165dd44c9309d7d6df2fce0579ebeb, got
bccca19f39c9d26d857ccf1fb72818b2b817967e6d497a25a1283e36ed0acf01
Running the interpreter with the -B argument prevents Python from
writing those byte code files:
https://docs.python.org/3/using/cmdline.html#cmdoption-B
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This basically does something similar than the AUR build:
https://aur.archlinux.org/packages/vlc-qt5/
On our side, all there is to do is to force compiling using C++11 mode
and use a patch that the AUR package took from the following upstream
patchwork URL:
https://patches.videolan.org/patch/14061/
Instead of passing CXXFLAGS to the configure script, I'm using sed here
to make sure we don't override flags figured out by configure.
For example if ./configure is used with CXXFLAGS=-std=c++11 appended or
prepended, we have something like:
... -I../include -std=c++11 -Wall -Wextra -Wsign-compare ...
While if we don't do that at all, we have something like:
... -I../include -g -O2 -Wall -Wextra -Wsign-compare ...
Another way would be to use NIX_CFLAGS_COMPILE, but that would affect
even compilation of C code and thus resulting in a bunch of warnings
like this:
cc1: warning: command line option '-std=c++11' is valid for C++/ObjC++
but not for C
So with our approach the flags during build look much better:
... -I../include -std=c++11 -g -O2 -Wall -Wextra -Wsign-compare ...
Another thing I've changed is that the vlc_qt5 attribute in
all-packages.nix now uses the latest Qt 5 version, because the build for
Qt >= 5.7.0 is now no longer broken.
I've also ordered the preConfigure attribute before the configureFlags
attribute, because it makes more sense in terms of context (pre ->
configure -> post).
Tested by building on x86_64-linux with libsForQt56.vlc, libsForQt58.vlc
and vlc (the Qt 4 version, just to be sure I didn't accidentally break
it).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @ttuegel
This reverts commit 0a6a06346a.
The commit replaced the text to search for from ALICE to BOB, because
our OCR detection only caught "BOB FOOBAR" but missed "ALICE FOOBAR"
completely.
With the improvements to our OCR system this no longer is the case and
the test passes successfully with this reverted.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @shlevy
First of all, we're now using ImageMagick to improve the screenshot so
that Tesseract has an esier time to recognize the text. The resulting
image of this post-processing is a scaled up black-and-white version
with the backgrounds almost entirely removed and the text edges a bit
blurred, so the screen shots now more or less resemble an image from a
scanner rather. This is what Tesseract is trained for by default.
As mentioned in the previous commit we now also use Tesseract 4, which
further improves the quality of text recognition.
I've spent countless hours just to test different postprocessing
variants and testing what works best for our tests and this is the one
that worked best so far. It's certainly not perfect and I'd like to
avoid the scaling step but we're way better off than before.
In addition to this, the OCR process is now done without an intermediate
file, solely using pipes.
I've tested this using the following VM tests which have OCR enabled:
* nixos/tests/chromium.nix -A stable
* nixos/tests/emacs-daemon.nix
* nixos/tests/installer.nix -A luksroot
* nixos/tests/lightdm.nix
* nixos/tests/plasma5.nix
* nixos/tests/sddm.nix
All of the tests still succeed and comparing some of the recognition
results to the earlier results it now also detects a lot more text than
before this commit.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tesseract 4 has got a new long short-term memory neural networking based
OCR engine which really helps a lot in terms of accuracy and our VM
tests.
I ran the new version across a bunch of different screenshots and
comparing the results to the 3.x branch and it really makes a big
difference, especially with various font rendering settings.
The only downside of this is that version 4 hasn't been released yet and
is in alpha state right now, but it will eventually get there and the
only solutions that came into my mind sticking to version 3 were really
sub-par:
* Use several passes with different color negation on the screenshots.
* Train Tesseract 3 specifically for screenshots. This is sub-par
because we'd need to do it for Tesseract 4 from scratch again.
* Change the test systems so that it specifically uses *only* OCR an
font when displaying. I've actually tried this but this also isn't
accurate enough with our default font rendering setup.
* Turn off special font rendering settings for our tests. In
conjunction with changing to an OCR font this might work but it won't
catch all the cases, because applications might use their own font
rendering.
Given that version 4 is faster[1] when it comes to OCR detection and also
the points just mentioned I think even using the alpha version just for
tests isn't going to hurt anybody.
[1]: https://github.com/tesseract-ocr/tesseract/wiki/4.0-Accuracy-and-Performance
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is from the commit message I've written for the upstream pull
request (jflesch/pyocr#62):
This is a bit more involved, because Tesseract 3.05.00 comes not
only with improvements but also with a few quirks we need to deal
with.
The first quirk is that the order arguments of the `tesseract'
command now matters and the list of configurations has to be at the
end of the command line. So we add a new attribute tesseract_flags
to the BaseBuilder class that contains a list of all the flags to
pass to `tesseract', the tesseract_configs attribute however remains
pretty much the same but now only really contains a list of configs
instead of being mixed with flag arguments.
Another quirk has to do with Leptonica >= 1.74 which Tesseract
3.05.00 now requires. Leptonica has special handling of files that
reside in /tmp and assumes that it's an internal temporary file of
Leptonica. In order to deal with it, we now run Tesseract in a
temporary directory, which contains the input/output files and use
the relative name of these files because Leptonica only searches for
path names beginning with /tmp.
Fortunately the last item we need to address is not really a quirk,
but an API change. In Tesseract 3.05.00 there is now a new function
called TessBaseAPIDetectOrientationScript(), which doesn't fill the
OSResults object anymore but now allows to pass the values we're
interested in directly by reference. We need to use this new
function because the old function TessBaseAPIDetectOS() now *always*
returns false.
I've tested this specifically on NixOS and in conjunction with Paperwork
(the only package that's using pyocr so far) and all the tests of the
dependency chain are now succeeding. However, I didn't do manual tests
of Paperwork though.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream changes for version 0.4.5:
* Clean up exceptions raised when OCR fails:
* Now, all tools raise only exceptions inheriting from
pyocr.PyocrException
* There is now one and only one TesseractError (shared between
pyocr.libtesseract and pyocr.tesseract)
Upstream changes for version 0.4.6:
* hOCR outputs: Generate valid XHTML files
The full upstream changelog can be found at:
https://github.com/jflesch/pyocr/blob/master/ChangeLog
Note that because of the version bump of Tesseract neither version 0.4.4
nor version 0.4.6 succeed to build, so we need to fix this up soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream changelog:
* Made some fine tuning to the hOCR output.
* Added TSV as another optional output format.
* Fixed ABI break introduced in 3.04.00 with the AnalyseLayout()
method.
* text2image tool - Enable all OpenType ligatures available in a font.
This feature requires Pango 1.38 or newer.
* Training tools - Replaced asserts with tprintf() and exit(1).
* Fixed Cygwin compatibility.
* Improved multipage tiff processing.
* Improved the embedded pdf font (pdf.ttf).
* Enable selection of OCR engine mode from command line.
* Changed tesseract command line parameter '-psm' to '--psm'.
* Added new C API for orientation and script detection, removed the old
one.
* Increased minimum autoconf version to 2.59.
* Removed dead code.
* Fixed many compiler warning.
* Fixed memory and resource leaks.
* Fixed some issues with the 'Cube' OCR engine.
* Fixed some openCL issues.
* Added option to build Tesseract with CMake build system.
* Implemented CPPAN support for easy Windows building.
The upstream URL of the change log is:
https://github.com/tesseract-ocr/tesseract/releases/tag/3.05.00
Tested by building against the following packages that directly depend
on it:
* vapoursynth (with ocrSupport = true)
* pyocr (fails)
* vobsub2srt
Also tested against the following NixOS VM tests that have OCR enabled:
* nixos/tests/chromium.nix -A stable
* nixos/tests/emacs-daemon.nix
* nixos/tests/installer.nix -A luksroot
* nixos/tests/lightdm.nix
* nixos/tests/plasma5.nix
* nixos/tests/sddm.nix
All of the packages and tests except pyocr build/succeed on
x86_64-linux.
Fixing pyocr is outside of the scope of this commit and will happen very
soon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The changes are a bit too big to include it here in the commit message,
so if you want the details of what changed, please visit this URL:
http://leptonica.org/source/version-notes.html
I have also provided openjpeg, giflib and libwebp as dependencies so
that Leptonica is able to read/write those file formats.
Additionally I've added a patch that uses pkgconfig to resolve all
dependencies (except giflib), because unlike AC_CHECK_LIB() the
PKG_CHECK_MODULES() macro defines *_LIBS variables to include the linker
search path.
Unfortunately that patch alone is not enough, because the *_LIBS
variable are substituted by the upstream configure.ac to *not* include
the linker search paths, so we need to remove the AC_SUBST() calls
within PKG_CHECK_MODULES().
The only dependency that's not yet using PKG_CHECK_MODULES() is giflib,
because giflib doesn't have a pkg-config description file, therefore
we're using substituteInPlace to insert the linker search path after the
lept.pc file was generated by configure.
Another thing that we no longer need is the dependency on libpng version
1.2, because Leptonica now also works with more recent libpng versions.
Tested by building the package itself and also the following packages
that immediately depend on leptonica:
* k2pdfopt
* tesseract
* jbig2enc
All of these packages succeeded to build on x86_64-linux.
The main reason why I'm bumping Leptonica to version 1.74.1 is that we
need at least version 1.74 to bump Tesseract to the latest upstream
version.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I've removed that attribute in 68bc260ca2,
because the language files no longer were distributed as seperate files,
but if we for example only want to use the English training data, the
closure size of Tesseract gets quite large (around 1.2 GB), which is a
bit much just to be able to run NixOS VM tests.
For this reason I've also switched the VM tests back to using only the
English language.
Tested using the following VM tests (the ones that have OCR enabled) on
x86_64-linux:
* nixos/tests/chromium.nix -A stable
* nixos/tests/emacs-daemon.nix
* nixos/tests/installer.nix -A luksroot
* nixos/tests/lightdm.nix
* nixos/tests/plasma5.nix
* nixos/tests/sddm.nix
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This has surfaced since f803270b7e.
The commit bumped bash to version 4.4, which caused to change the order
of --subst-var flags in substituteAll, which this test was relying on,
because it added a @shell@ to boot.initrd.postMountCommands.
Our substituter is currently working a bit like this:
original.replace('@var1@', 'val1').replace('@var2@', 'val2')...
Unfortunately, this means that if @var2@ occurs within @var1@ it is
replaced by the new value, so the order of the substvars actually
matter. I highly doubt that we want a behaviour like this and I'm
wondering why it didn't occur to me as a problem while writing the
initial implementation of the VirtualBox tests.
Whether to get rid of this and disallowing substitution of substvars
within substvars is another topic which I think needs discussion in a
different place.
As for now, I'm using stdenv.shell, because the closure size of this
should fit within the initrd, so it's fine especially because it's just
a test.
Tested with the net-hostonlyif and systemd-detect-virt tests and they
both succeed with this change.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @globin on IRC
This reverts commit 3a4e2376e4.
The reverted commit caused the fix for CVE-2016-9602 not to be applied
for qemu_test because it conflicts with the force-uid0-on-9p.patch.
So with the rebase of the patch on top of the changes of the
CVE-2016-9602.patch, both patches no longer conflict with each other.
I've tested this with the "misc" NixOS test and it succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* 4.17.0: A few smaller fixes.
* 4.16.0beta: It's now possible to show saved passwords from the
GWEN_PASSWD_STORE file.
* 4.15.6beta: Improve Certificate handling with TLS connections.
* 4.15.5beta: Fix problem with some servers aborting SSL connections.
The full changelogs in German can be found at:
https://www.aquamaniac.de/sites/news/index.php
Built and tested successfully on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* 5.6.11: Fix problem with some servers aborting SSL connections.
* 5.6.12: Improve handling of offset accounts during turnover
retrieval.
The full changelogs in German can be found at:
https://www.aquamaniac.de/sites/news/index.php
Built and tested successfully on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Since systemd version 232 the install subcommand of bootctl opens the
loader.conf with fopen() modes "wxe", where the "e" stands for
exclusive, so the call will fail if the file exists.
For installing the boot loader just once this is fine, but if we're
using NIXOS_INSTALL_BOOTLOADER on a systemd where the bootloader is
already present this will fail.
Exactly this is done within the simpleUefiGummiboot installer test,
where nixos-install is called twice and thus the bootloader is also
installed twice, resulting in an error during the fopen call:
Failed to open loader.conf for writing: File exists
Removing the file prior to calling bootctl should fix this.
I've tested this using the installer.simpleUefiGummiboot test and it now
succeeds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra, @shlevy, @mic92
Fixes: #22925
This leads to the following error when trying to install a new machine
where the machine ID wasn't yet initialized during boot:
Failed to get machine did: No such file or directory
In addition this was also detected by the simpleUefiGummiboot installer
test.
So let's generate a fallback machine ID by using
systemd-machine-id-setup before actually running bootctl.
Tested this by running the installer.simpleUefiGummiboot test, it still
fails but not because of the machine ID.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra, @shlevy, @mic92
Fixes: #22561
First of all, these "documents" are not really documentation, so it
really doesn't make much sense to put it into $doc.
The main point however is that the installer tests are failing since
this was introduced in ac0cdc1952.
One way to circumvent this is putting dbus.doc into
system.extraDependencies of the installer tests, but given the first
point this sounds a bit odd to me.
So I went for the second way of putting it into $out, because it's now
basically necessary to build a NixOS system.
With this the NixOS installer tests should now work again, although I
have only tested this with the installer.simple test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
The problem with using libxslt as buildInputs is that the dev output is
used for building the dbus config.
This is one of the reasons why the installer tests are failing since
ac0cdc1952, because the tests do not have
libxslt.dev in their closure and really shouldn't.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
This is the output of the builder:
building path(s) `/nix/store/khkcfb8433i9mabb6wnb8ik6p9skg644-dbus-1'
error : connection refused
error : connection refused
However, even when using --nonet we'd still get this:
I/O error : Attempt to load network entity
http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd
So in order to avoid this, we now provide an XML catalog file, mapping
the public URLs to the local DTD paths inside the store instead of using
--path (which doesn't seem to work with xsltproc).
Tested this by comparing the SHA256 (nix-hash --type sha256) of the
output path generated by:
nix-build -E '(import ./. {}).makeDBusConf {
suidHelper = "SUIDHELPER";
serviceDirectories = [ "SERVICEDIR1" "SERVICEDIR1" ];
}'
... with the SHA256 of the generated output path prior to this commit
and they have the same hash:
6f3f9594b12fddbff9407b85252b6f649da11f56b7fd514f761966c11399a7ab
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
This has surfaced due to 505d7bea3a and
the fixup commit 77f5a50c40.
The individial platform attributes are a list rather than single
elements, so in this case we got:
with platforms; [darwin linux freebsd illumos]
Which results in:
[ ["x86_64-darwin"]
["i686-linux" "x86_64-linux" "armv5tel-linux" "armv6l-linux"
"armv7l-linux" "aarch64-linux" "mips64el-linux"]
["i686-freebsd" "x86_64-freebsd"]
["x86_64-solaris"]
]
So if you don't have allowBroken set in nixpkgs config, you end up with
an evaluation error because meta.platforms is expected to be a list
instead of a list of lists which we got here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @mornfall, @vcunat
Fixes the locale path, which I got wrong in
7199f1bd94.
It should have been "$out/share", because Paperwork itself already
appends /locale to the path.
Thanks to @symphorien for the fix.
This is deliberate because using the taskd binary to configure
Taskserver has a good chance of messing up permissions.
The nixos-taskserver tool now can manage even manual configurations, so
there really is no need anymore to expose the taskd binary.
If people still want to use the taskd binary at their own risk they can
still add taskserver to systemPackages themselves.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This subtest actually serves two purposes:
1. Test manual PKI configuration
2. Test changing of configuration files
In order to only test manual PKI configuration it would have been enough
to just add another server with a manual config.
But as the switch from automatic PKI config to manual config is probably
one of the most fundamental changes in configuration, so it serves
*very* well to also check whether changes in the NixOS configuration
actually have an impact in the real system.
So instead of adding another server, we now create a dummy "newServer"
machine, which is the new configuration for "server" and use
switch-to-configuration to switch "server" to the config of "newServer".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Putting an include directive in the configuration file referencing a
store path with the real configuration file has the disavantage that
once we change the real configuration file the store path is also a
different one.
So we would have to replace that include directive with the new
configuration file, which is very much error-prone, because whenever
taskd modifies the configuration file on its own it generates a new one
with *only* the key/value options and without any include directives.
Another problem is that we only added the include directive on the first
initalization, so whenever there is *any* configuration change, it won't
affect anything.
We're now passing all the configuration options via command line,
because taskd treats everything in the form of --<name>=<value> to be a
configuration directive.
This also has the effect that we now no longer have extraConfig, because
configuration isn't a file anymore.
Instead we now have an attribute set that is mapped down to
configuration options.
Unfortunately this isn't so easy with the way taskd is configured,
because there is an option called "server" and also other options like
"server.cert", "server.key" and so on, which do not map very well to
attribute sets.
So we have an exception for the "server" option, which is now called
"server.listen", because it specifies the listening address.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #22705
The helper tool so far was only intended for use in automatic PKI
handling, but it also is very useful if you have an existing CA.
One of the main advantages is that you don't need to specify the data
directory anymore and the right permissions are also handled as well.
Another advantage is that we now have an uniform management tool for
both automatic and manual config, so the documentation in the NixOS
manual now applies to the manual PKI config as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The error message displays that a specific user doesn't exist in an
organisation, but uses the User object's name attribute to show which
user it was.
This is basically a very stupid chicken and egg problem and easily fixed
by using the user name provided on the command line.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
A long-time issue and one of the reasons I've never used that function
before. So let's remove that todo-comment and escape the contents
properly.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @edolstra
Since the update of imagemagick in
5e753c1a65 there are certain test cases
which now unexpectly succeed and in turn cause the whole build to fail.
So in order to prevent this from happening let's skip those tests
properly instead of running them and expect them to fail.
Tested by building pythonPackages.pyocr on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Tested via building the linux_testing attribute only, not in production.
Verified unpacked tarball with GnuPG:
gpg: Signature made Mon 06 Feb 2017 12:21:50 AM CET
gpg: using RSA key 79BE3E4300411886
gpg: Good signature from "Linus Torvalds <torvalds@linux-foundation.org>" [unknown]
Primary key fingerprint: ABAF 11C6 5A29 70B1 30AB E3C4 79BE 3E43 0041 1886
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The tests have failed because Chromium has started up displaying the
following error message in a dialog window:
Chromium can not be run as root.
Please start Chromium as a normal user. If you need to run as root for
development, rerun with the --no-sandbox flag.
So let's run as user "alice" and pass all commands using the small
helper function "ru" (to keep it short, it's for "Run as User").
Tested it by running the "stable" test on x86_64-linux.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @globin
Regression introduced by 0cb487ee04.
This changed the result for defaultGateway to be a submodule instead of
just a plain string, so instead of using just cfg.defaultGateway we need
to pass cfg.defaultGateway.address now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
The tag wasn't properly closed which caused the manual build to fail.
Tested with: nix-build nixos/release.nix -A manual.x86_64-linux
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This reverts commit 55b18ac486.
There is already a "thin-provisioning-tools" package (see
cd1ec18b42).
Although this one was committed earlier, I'm reverting it because it's
not only older, but it's unreferenced within <nixpkgs>.
Apart from that the packaging of the other package is of higher
packaging quality (maintainer and license, doesn't use "descriptionS",
uses autoreconfHook).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @globin, @dwe11er, @jagajaga
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This pulls updates from @devhell for libmediainfo, mediainfo,
mediainfo-gui and libzen to their latest upstream versions.
Tested by building all of these packages plus "ums" and "sonarr" (both
depend on one or more of these updated packages) on x86_64-linux.
This essentially unbreaks deploying new Hetzner machines with NixOps,
because the Hetzner robot has changed its way of handling admin
accounts.
It also now provides a more helpful error message (instead of an
AssertionError) if admin account creation has failed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: Graham Christensen <graham@grahamc.com>
Issue: https://github.com/NixOS/nixops/issues/563
I have not yet tested scanning, but the main application works so far.
A lot of patching is required here, because the upstream project
references some paths from well-known FHS locations which of course are
not available on Nix(OS).
We also use all available aspell dictionaries right now, which is maybe
a bit ugly but it makes language switching easier.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
While not explicitly checked by setup.py or by the "chkdeps" command
from the project I have added pyinsane2 and pyocr to the list of
dependencies as well, because they're referenced in the source.
Tested by building against Python 3.3, 3.4, 3.5 and 3.6.
The build against Python 3.6 failed because pycairo doesn't build, so
it's a non-issue at least for paperwork-backend.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
aszlig