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>
First of all: This is NOT the same package as "pillowfight".
I'm not sure why people want to choose this particular name, but well,
so be it.
I haven't investigated why test_ace and test_all_2 fail, but I've
disabled these tests by now and reported the failures upstream at
jflesch/libpillowfight#2.
Tested by building against Python 3.3, 3.4, 3.5 and 3.6.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This package is a bit more involved because it assumes a lot of paths
being there in a FHS compliant way, so we need to patch the data and
binary directories for Tesseract and Cuneiform.
I've also tried to get the tests working, but they produce different
results comparing input/output. This is probably related to the
following issue:
https://github.com/jflesch/pyocr/issues/52
So I've disabled certain tests that fail but don't generally impede the
functionality of pyocr.
Tested by building against Python 3.3, 3.4, 3.5 and 3.6.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Found out during testing of the Tesseract upgrade the kde5 and sddm
tests don't actually use OCR, so let's disable support for it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @ttuegel
From the upstream changelog:
* Tesseract development is now done with Git and hosted at github.com
(Previously we used Subversion as a VCS and code.google.com for
hosting).
So let's move over to the GitHub repository, where the organisation also
includes a full repository for tessdata, so we no longer need to fetch
it one-by-one.
The build also got significantly simpler, because we no longer need to
run autoconf, neither do we need to patch the configure script for
Leptonica headers.
This also has the advantage that we don't need to use the
enableLanguages attribute for the test runner anymore.
Full upstream changelog can be found at:
https://github.com/tesseract-ocr/tesseract/blob/c4d273d33cc36e/ChangeLog
Tested against all NixOS tests with enabled OCR (chromium, emacs-daemon,
installer.luksroot and lightdm).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @viric
This optionally adds support for GI, because it's needed for
paperwork-backend. The new poppler_gi attribute is also marked as
lowPrio so that users won't accidentally install it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @ttuegel
The tests require a scanner to be physically attached.
Quote from the upstream README:
> Tests require at least one scanner with a flatbed and an ADF
> (Automatic Document Feeder).
>
> If possible, they should be run with at least 2 scanners connected.
> The first that appear in "scanimage -L" must be the one with the ADF.
>
> For reference, my current setup is:
>
> - HP Officejet 4620 (Flatbed + ADF)
> - HP Deskjet 2050 J510 series (Flatbed)
So we disable the tests even though it might be theoretically possible
to use qemu and an emulated scanner. Instead of the upstream tests we
just do a quick check whether initialization of the library succeeds.
Other than that the library uses ctypes.cdll to dlopen() the libsane
shared library, so we need to patch in the right store path.
Tested by building against Python 2.7, 3.3, 3.4, 3.5 and 3.6.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The upstream tag actually says 1.5.7 but the commit actually bumps the
version to 1.5.8:
https://github.com/hickeroar/simplebayes/commit/b8da72c50d20b6f8c0d
We needed to patch the setup.py because the upstream project's setup.py
reads in the README.rst for the longDescription. That very README.rst
contains non-ASCII characters which in turn throws a decoding error with
Python 3 on Nix because I think this has to do with our setup.py wrapper
that doesn't seem to recognize the right encoding when using compile().
Tested by building against Python 2.7, 3.3, 3.4, 3.5 and 3.6.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Upstream changelog without issue numbers:
* Fixes several issues with C++ template deduction.
* Fixes a issue with bound method type inference.
* Fixes a bug with cascaded tuple assignment.
* Fixed or silenced many Clang warnings.
* Fixes bug with powers of pure real complex numbers.
The full changelog with issue numbers can be found here:
https://github.com/cython/cython/blob/0.25.2/CHANGES.rst
My main reason for updating is because there were test failures on
i686-linux, although version 0.25.2 still has one test that fails.
So if we're on i686-linux and on Python 2 we just fix that one little
doctest.
The test failure has already been reported upstream at:
https://github.com/cython/cython/issues/1548
All of the failing tests (including the latter) had to do with integer
representations in that long integers are suffixed by an L while the
test cases weren't expecting this.
Built successfully on i686-linux and x86_64-linux against Python 2.7 and
Python 3.5.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This brings VirtualBox to the latest upstream version, which also fixes
building the modules against kernel 4.9.0.
Tested against all the the "virtualbox" subtests on x86_64-linux.
Bugfix release with the following fixes:
* Fix thumbnail creation for input files with dot
* Use native python to generate list of external commands
* Do not use commandline arguments in test mode
* Catch broken symlinks in the library and filter them
So everything but the last item is essentially what we had in
fixes.patch, hence we cane remove it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The "misc" NixOS test is using Nix to query the store and it tries to
change the ownership of it while doing so.
This fails if Nix is not in a seccomp-sandboxed userid namespace, so
let's make chown() a no-op when applied to store paths.
Fixes the misc test (and possibly future tests) on older Nix versions.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The boot tests import test-instrumentation.nix directly to create a VM
image that only contains things such as the backdoor and serial console
the same way as used by other NixOS VM tests.
With one difference though: It doesn't need nor want to have 9p
filesystems mounted, because we actually want to test an image rather
than re-using most stuff from the host's store.
Change tested against the boot.uefiUsb and ipv6 tests, just that it
becomes clear we don't break either the tests with 9p nor the boot
tests (which were already broken but now succeed).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This largely reverts commit 599312739e.
The main reason is that it breaks the plugins, because the mentioned
commit didn't change the attributes for the plugins as well.
But instead of just fixing the attributes when we import the plugin
packages, let's just override pythonPackages in all-packages.nix.
Right now, Beets is in transition to Python 3, so we don't need to wait
that long until we can remove the dependency on Python 2:
https://github.com/beetbox/beets/releases/tag/v1.4.1
Once Python 3 support is no longer beta, we can just change this by
changing one line only instead of several.
Tested this by building beets with both external plugins.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @FRidh
Packaging itself is pretty much straightforward, the tests however
revealed a few issues, which I have fixed with a small patch that has
been upstreamed at https://github.com/karlch/vimiv/pull/32.
The other sed-based patches in postPatch are mostly NixOS-specific.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There's no reason to disable ALL tests just because only one particular
test module is failing.
Tested on i686-linux and x86_64-linux against these Python versions:
Python 2.6: The interpreter itself doesn't build
Python 2.7: Successful for both architectures
Python 3.3: Successful for both architectures
Python 3.4: Successful for both architectures
Python 3.5: Successful for both architectures
Python 3.6: One of the dependencies of pillow doesn't build (pytest)
Tests for PyPy still fail, which is why the doCheck attribute is only
set to false if we're building for PyPy.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @desiderius, @goibhniu, @prikhi
Full upstream release announcement:
https://github.com/beetbox/beets/releases/tag/v1.4.1
I had to rebase the keyfinder-default-bin.patch in order to apply with
the new release.
Other than that I didn't test whether beets works on my machine, as I
have a more or less temporary setup at the moment.
However, since the bump of mutagen to version 1.34 in commit
555928c228, the mediafile tests fail and
thus this commit unbreaks beets.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason to patch QEMU is that with latest Nix, tests like "printing"
or "misc" fail because they expect the store paths to be owned by uid 0
and gid 0.
Starting with NixOS/nix@5e51ffb1c2, Nix
builds inside of a new user namespace. Unfortunately this also means
that bind-mounted store paths that are part of the derivation's inputs
are no longer owned by uid 0 and gid 0 but by uid 65534 and gid 65534.
This in turn causes things like sudo or cups to fail with errors about
insecure file permissions.
So in order to avoid that, let's make sure the VM always gets files
owned by uid 0 and gid 0 and does a no-op when doing a chmod on a store
path.
In addition, this adds a virtualisation.qemu.program option so that we
can make sure that we only use the patched version if we're *really*
running NixOS VM tests (that is, whenever we have imported
test-instrumentation.nix).
Tested against the "misc" and "printing" tests.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This brings in the new stable version 54 which also introduces a lot of
security fixes:
CVE-2016-5198: Out of bounds memory access in V8
CVE-2016-5181: Universal XSS in Blink
CVE-2016-5182: Heap overflow in Blink
CVE-2016-5183: Use after free in PDFium
CVE-2016-5184: Use after free in PDFium
CVE-2016-5185: Use after free in Blink
CVE-2016-5187: URL spoofing
CVE-2016-5188: UI spoofing
CVE-2016-5192: Cross-origin bypass in Blink
CVE-2016-5189: URL spoofing
CVE-2016-5186: Out of bounds read in DevTools
CVE-2016-5191: Universal XSS in Bookmarks
CVE-2016-5190: Use after free in Internals
CVE-2016-5193: Scheme bypass
Detailed announcements about these changes can be found here (latest to
oldest):
https://googlechromereleases.blogspot.de/2016/11/stable-channel-update-for-desktop.htmlhttps://googlechromereleases.blogspot.de/2016/10/stable-channel-update-for-desktop_20.htmlhttps://googlechromereleases.blogspot.de/2016/10/stable-channel-update-for-desktop.html
The update process of Chromium has been a bit bumpy on our side, because
version 54 also did the switch from GYP to GN so it wasn't just a matter
of updating the upstream-info file.
I've tested the Flash plugin (which runs fine) and WideVine manually,
although I couldn't get WideVine to work (I was running this within a VM
though).
So if people want to use WideVine they need to use Chrome instead until
we got this sorted out.
VM test results along with builds for all platforms can be found here:
https://headcounter.org/hydra/eval/339328
I'm going to backport these changes to stable as soon as the
tests/builds succeed there as well.
Closes: #19565Closes: #20120
Sometimes it happens that the "Type to search or enter a URL to
navigate" popup doesn't show, but all we need to know at this time is
whether Chromium has finished starting up.
So checking for the "startup done" page is a better option here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Versions before 56 already had experimental support for Gtk 3 and since
version 56, Gtk 3 _seemed_ to become the default. Although it's now
requiring *both* Gtk 2 and Gtk3, so let's supply the dependency for now
to get it to build.
In the future however we might want to add use_gtk3 to the GN flags and
get rid of Gtk 2 completely.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Before version 54, the WideVine CDM plugin was built unconditionally and
it seems since version 54 this now is dependent upon a GYP/GN flag on
whether to include the CDM shared library or not.
Also, we now use a patch from Gentoo which should hopefully get the CDM
plugin to work properly, at least according to their bugtracker:
https://bugs.gentoo.org/show_bug.cgi?id=547630
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Overview of updated versions:
stable: 54.0.2840.71 -> 54.0.2840.90
beta: 55.0.2883.21 -> 55.0.2883.35
dev: 56.0.2897.0 -> 56.0.2906.0
This is to get our Chromium versions in par with the latest upstream
ones before merging in the GN migration changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
So far we had the bundled Flash player plugin that came with Chrome, but
since version 54 the Chrome package doesn't include PPAPI Flash anymore.
Instead we're going to download the PPAPI Flash plugin directly from
Adobe and try to use them for all release channels of Chromium.
Of course it would be nice if we'd have an updater for it but for now
it's important that we don't break things for people who are currently
forced to use Flash.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Seems that these libraries aren't the ones Chromium is expecting to be,
so let's switch to use the bundled version of these libraries instead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Previously I've added the extra file common-gn.nix in addition to
common.nix, so we can possibly have a smooth transition from current
stable to the new version 54.
Unfortunately, version 53 is already EOL and we have to move to version
54 as soon as possible so we can only use GN and thus it doesn't make
sense to provide expressions for GYP anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This should now be the upstream default and there also is no more flag
for GN to set it, so we'll no longer need it on our side as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This only uses the most basic GN flags which should represent the GYP
flags we had before. In order to get rid most of the GYP cruft, we now
have common.nix and common-gn.nix which are mostly the same, just that
the latter is only for GN builds.
The GN implementation is far from complete and currently not even
builds, so we need more work to get the beta and dev channels building.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the standalone version of GN used currently solely for building
Chromium. An upstream bug report is available at
https://crbug.com/504074 to support a standalone build without needing
various components from the Chromium source tree.
Because there isn't a standalone vrsion available, I'm choosing
0.0.0.${date} as the version scheme here so that we don't conflict with
versioned releases from upstream someday[TM].
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Thanks to @NeQuissimus in a5c1985fef for
updating busybox, which since version 1.25 doesn't allow local variables
outside of functions anymore (which is the desired behaviour).
See the following upstream commit of busybox which is the change that
let's this problem surface:
https://git.busybox.net/busybox/commit/?id=ef2386b80abfb22ccb697ddbdd4047aacc395c50
So this has been an error I've made on my end in
67223ee205, because I originally had a
function for killing the processes but desired to inline it because it's
only used in one place.
This fixes the boot-stage1 NixOS test.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We already are in the <nixpkgs> repository and using <nixpkgs> within
its own tree will depend on <nixpkgs> to be set in NIX_PATH, otherwise
the evaluation will fail.
So apart from this issue it isn't even necessary to use <nixpkgs>
instead of the relative path to node-packages.nix, so let's use the
latter.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @uwap, @Mic92
aszlig