bug#42173: [PATCH 2/2] services: nix: Fix sandbox.
* gnu/tests/package-management.scm: New file.
* gnu/local.mk: Add this.
* gnu/services/nix.scm (): New record.
(nix-activation): Generate Nix config file.
(nix-service-type): Add default value.
(nix-shepherd-service): Allow provide Nix package.
* doc/guix.texi (Miscellaneous Services)[Nix service]:
Document record.
---
doc/guix.texi| 21 +
gnu/local.mk | 1 +
gnu/services/nix.scm | 90 +
gnu/tests/package-management.scm | 131 +++
4 files changed, 211 insertions(+), 32 deletions(-)
create mode 100644 gnu/tests/package-management.scm
diff --git a/doc/guix.texi b/doc/guix.texi
index 26ef937604..5639a360be 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -27597,6 +27597,27 @@ $ source
/run/current-system/profile/etc/profile.d/nix.sh
@end defvr
+@deftp {Data Type} nix-configuration
+This data type represents the configuration of the Nix daemon.
+
+@table @asis
+@item @code{nix} (default: @code{nix})
+The Nix package to use.
+
+@item @code{sandbox} (default: @code{#t})
+Specifies whether builds are sandboxed by default.
+
+@item @code{build-sandbox-paths} (default: @code{'()})
+This is a list of strings or objects appended to the
+@code{build-sandbox-paths} field of the configuration file.
+
+@item @code{extra-config} (default: @code{'()})
+This is a list of strings or objects appended to the configuration file.
+It is used to pass extra text to be added verbatim to the configuration
+file.
+@end table
+@end deftp
+
@node Setuid Programs
@section Setuid Programs
diff --git a/gnu/local.mk b/gnu/local.mk
index 0eac01d72d..2c19562171 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -674,6 +674,7 @@ GNU_SYSTEM_MODULES =\
%D%/tests/mail.scm \
%D%/tests/messaging.scm \
%D%/tests/networking.scm \
+ %D%/tests/package-management.scm \
%D%/tests/reconfigure.scm\
%D%/tests/rsync.scm \
%D%/tests/security-token.scm \
diff --git a/gnu/services/nix.scm b/gnu/services/nix.scm
index 3c0065207d..04e7726e4d 100644
--- a/gnu/services/nix.scm
+++ b/gnu/services/nix.scm
@@ -1,5 +1,5 @@
;;; GNU Guix --- Functional package management for GNU
-;;; Copyright © 2019 Oleg Pykhalov
+;;; Copyright © 2019, 2020 Oleg Pykhalov
;;;
;;; This file is part of GNU Guix.
;;;
@@ -31,7 +31,9 @@
#:use-module (guix store)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-26)
+ #:use-module (ice-9 match)
#:use-module (ice-9 format)
+ #:use-module (guix modules)
#:export (nix-service-type))
;;; Commentary:
@@ -40,10 +42,17 @@
;;;
;;; Code:
-
-;;;
-;;; Accounts
-;;;
+(define-record-type*
+ nix-configuration make-nix-configuration
+ nix-configuration?
+ (package nix-configuration-package ;package
+ (default nix))
+ (sandbox nix-configuration-sandbox ;boolean
+ (default #t))
+ (build-sandbox-paths nix-configuration-build-sandbox-paths ;list of strings
+ (default '()))
+ (extra-confignix-configuration-extra-options ;list of strings
+ (default '(
;; Copied from gnu/services/base.scm
(define* (nix-build-accounts count #:key
@@ -74,32 +83,49 @@ GID."
(id 4))
(nix-build-accounts 10 #:group "nixbld")))
-(define (nix-activation _)
- "Return the activation gexp."
- (with-imported-modules '((guix build utils))
-#~(begin
-(use-modules (guix build utils)
- (srfi srfi-26))
-(for-each (cut mkdir-p <>) '("/nix/store" "/nix/var/log"
- "/nix/var/nix/gcroots/per-user"
- "/nix/var/nix/profiles/per-user"))
-(chown "/nix/store"
- (passwd:uid (getpw "root")) (group:gid (getpw "nixbld01")))
-(chmod "/nix/store" #o775)
-(for-each (cut chmod <> #o777) '("/nix/var/nix/profiles"
- "/nix/var/nix/profiles/per-user")
+(define nix-activation
+ ;; Return the activation gexp.
+ (match-lambda
+(($ package sandbox build-sandbox-paths extra-config)
+ (with-imported-modules (source-module-closure
+ '((guix build store-copy)))
+ #~(begin
+ (use-modules (guix build utils)
+(ice-9 format)
+(srfi srfi-1)
+(srfi srfi-26))
+ (for-each (cut mkdir-p <>) '("/nix/store" "/nix/var/log"
+"/nix/var/nix/gcroots/per-user"
+"/nix/var/nix/profiles/per-user"))
+ (chown "/nix/store"
+ (passwd:uid (getpw "root")) (group:gid (getpw "nixbld01")))
+ (chmod "/nix/store" #o775)
+
bug#42173: Nix on Guix System: can't update channels
Hi Oleg,
Oleg Pykhalov skribis:
> Oleg Pykhalov writes:
>
> […]
>
>> Currently I don't see a way to mount
>> /gnu/store/57xj5gcy1jbl9ai2lnrqnpr0dald9i65-coreutils-8.32
>> dependencies (and other packages) inside the Nix sandbox.
>
> Found one way:
>
> (with-output-to-file "/etc/nix/nix.conf"
> (lambda _
> (display "sandbox = true")
> (newline)
> (format #t "build-sandbox-paths = ~{~a ~}~%"
> '#$(package-closure (map (match-lambda ((name package) package))
> (package-inputs nix))
That’s inaccurate: ‘package-closure’ does not capture non-package
inputs, and it’s the set of build-time dependencies, not references.
Using #:references-graphs solves that problem because it gives you
precisely the closure of each package, as returned by ‘guix gc -R’.
HTH!
Ludo’.
bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
Hi Olivier, Olivier skribis: > I see that some time has passed and I believe that the issue can be closed. > > Long story short, my hdd has died and I bought a new one and > re-installed. I could imagine that the errors I was running into were > related to the impending hardware failure -- that's a speculation, > though. Anyway, following your suggestions brought me to the same > point I was at earlier (gdb didnt show anything useful). OK, too bad. Do let us know if you experience a similar crash again. Thank you, Ludo’.
bug#42162: Recovering source tarballs
Hello! zimoun skribis: > On Tue, 21 Jul 2020 at 23:22, Ludovic Courtès wrote: > >> • If we no longer deal with tarballs but upstreams keep signing >> tarballs (not raw directory hashes), how can we authenticate our >> code after the fact? > > Does Guix automatically authenticate code using signed tarballs? Not automatically; packagers are supposed to authenticate code when they add a package (‘guix refresh -u’ does that automatically). >>> >>> So I miss the point of having this authentication information in the >>> future where upstream has disappeared. >> >> What I meant above, is that often, what we have is things like detached >> signatures of raw tarballs, or documents referring to a tarball hash: >> >> https://sympa.inria.fr/sympa/arc/swh-devel/2016-07/msg9.html > > I still miss why it matters to store detached signature of raw tarballs. I’m not saying we (Guix) should store signatures; I’m just saying that developers typically sign raw tarballs. It’s a general statement to explain why storing or being able to reconstruct tarballs matters. Thanks, Ludo’.
bug#42173: [PATCH 2/2] services: nix: Fix sandbox.
Hi!
Oleg Pykhalov skribis:
> * gnu/tests/package-management.scm: New file.
> * gnu/local.mk: Add this.
> * gnu/services/nix.scm (): New record.
> (nix-activation): Generate Nix config file.
> (nix-service-type): Add default value.
> (nix-shepherd-service): Allow provide Nix package.
> * doc/guix.texi (Miscellaneous Services)[Nix service]:
> Document record.
Nice! You can add a “Fixes” line too.
> +@item @code{build-sandbox-paths} (default: @code{'()})
> +This is a list of strings or objects appended to the
> +@code{build-sandbox-paths} field of the configuration file.
I’d use “files” or “items” instead of “paths”, for consistency.
> + (mkdir-p "/etc/nix")
> + (with-output-to-file "/etc/nix/nix.conf"
> + (lambda _
> + (format #t "sandbox = ~a~%" (if #$sandbox "true" "false"))
> + (format #t "build-sandbox-paths = ~{~a ~}~%"
> + (append (append-map (cut call-with-input-file <> read)
> + '#$(map references-file
> + (list package)))
> + '#$build-sandbox-paths))
> + (for-each (cut display <>) '#$extra-config
Here you’re adding the closure of Nix itself, which is a bit more than
needed I guess, but maybe it’s OK (perhaps with a comment explaining
that ‘config.nix’ captures store file names.)
Actually I thought this would have to be addressed in the ‘nix’ package
itself because this is where those store file names are captured. But
maybe it’s OK to do it in the service. WDYT?
> +(define* (run-nix-test name test-os)
> + "Run tests in %NIX-OS Guix operating system, which has nix-daemon running."
^
TEST-OS
> +(define %nix-os
Pretty fun. :-)
> +(define %test-nix
> + (system-test
> + (name "nix")
> + (description "Connect to a running nix-daemon")
> + (value (run-nix-test name %nix-os
Great that you were able to write a test for that!
Thanks,
Ludo’.
bug#42476: Krita fails to start
Currently, Krita fails to start after loading its splash screen. It just
hangs forever.
I found this upstream bug report in Qt:
https://bugreports.qt.io/browse/QTBUG-83207
Currently, I'm testing the build of Krita based on the Qt patch in that
bug report.
I've attached my patch.
>From 616b6541150f71e44618eeb969cf6aa64f02 Mon Sep 17 00:00:00 2001
From: Leo Famulari
Date: Wed, 22 Jul 2020 13:47:39 -0400
Subject: [PATCH] gnu: Fix Krita.
* gnu/packages/patches/qtbase-fix-krita-deadlock.patch: New file.
* gnu/local.mk (dist_patch_DATA): Add it.
* gnu/packages/kde.scm (qtbase-for-krita): New variable.
(krita)[inputs]: Replace qtbase with qtbase-for-krita.
---
gnu/local.mk | 1 +
gnu/packages/kde.scm | 10 +-
.../patches/qtbase-fix-krita-deadlock.patch | 110 ++
gnu/packages/qt.scm | 1 +
4 files changed, 121 insertions(+), 1 deletion(-)
create mode 100644 gnu/packages/patches/qtbase-fix-krita-deadlock.patch
diff --git a/gnu/local.mk b/gnu/local.mk
index a1bd6a644a..6464181548 100644
--- a/gnu/local.mk
+++ b/gnu/local.mk
@@ -1488,6 +1488,7 @@ dist_patch_DATA =
\
%D%/packages/patches/qrcodegen-cpp-make-install.patch\
%D%/packages/patches/qt4-ldflags.patch \
%D%/packages/patches/qtbase-absolute-runpath.patch \
+ %D%/packages/patches/qtbase-fix-krita-deadlock.patch \
%D%/packages/patches/qtbase-moc-ignore-gcc-macro.patch \
%D%/packages/patches/qtbase-use-TZDIR.patch \
%D%/packages/patches/qtscript-disable-tests.patch\
diff --git a/gnu/packages/kde.scm b/gnu/packages/kde.scm
index 9a80e362b6..9fa8ed7c15 100644
--- a/gnu/packages/kde.scm
+++ b/gnu/packages/kde.scm
@@ -360,6 +360,14 @@ a module for implementing ODF Gantt charts, which are bar
charts that
illustrate project schedules.")
(license license:gpl2+)))
+(define qtbase-for-krita
+ (package
+(inherit qtbase)
+(source (origin
+ (inherit (package-source qtbase))
+ (patches (append (origin-patches (package-source qtbase))
+ (search-patches
"qtbase-fix-krita-deadlock.patch")))
+
(define-public krita
(package
(name "krita")
@@ -434,7 +442,7 @@ illustrate project schedules.")
("openexr" ,openexr)
("perl" ,perl)
("poppler-qt5" ,poppler-qt5)
- ("qtbase" ,qtbase)
+ ("qtbase" ,qtbase-for-krita)
("qtdeclarative" ,qtdeclarative)
("qtmultimedia" ,qtmultimedia)
("qtsvg" ,qtsvg)
diff --git a/gnu/packages/patches/qtbase-fix-krita-deadlock.patch
b/gnu/packages/patches/qtbase-fix-krita-deadlock.patch
new file mode 100644
index 00..d3554be3c9
--- /dev/null
+++ b/gnu/packages/patches/qtbase-fix-krita-deadlock.patch
@@ -0,0 +1,110 @@
+Fix a deadlock in Krita:
+
+https://bugreports.qt.io/browse/QTBUG-83207
+
+Patch copied from Qt bug tracker:
+
+https://codereview.qt-project.org/c/qt/qtbase/+/296034
+
+From 276fa8383a7535765be7182883ef4aade17ce013 Mon Sep 17 00:00:00 2001
+From: Thiago Macieira
+Date: Thu, 02 Apr 2020 12:08:41 -0300
+Subject: [PATCH] QLibrary: fix deadlock caused by fix to QTBUG-39642
+
+Commit ae6f73e8566fa76470937aca737141183929a5ec inserted a mutex around
+the entire load_sys(). We had reasoed that deadlocks would only occur if
+the object creation in instance() recursed into its own instance(),
+which was already a bug. But we had forgotten that dlopen()/
+LoadLibrary() executes initialization code from the module being loaded,
+which could cause a recursion back into the same QPluginLoader or
+QLibrary object. This recursion is benign because the module *is* loaded
+and dlopen()/LoadLibrary() returns the same handle.
+
+[ChangeLog][QtCore][QLibrary and QPluginLoader] Fixed a deadlock that
+would happen if the plugin or library being loaded has load-time
+initialization code (C++ global variables) that recursed back into the
+same QLibrary or QPluginLoader object.
+
+PS: QLibraryPrivate::loadPlugin() updates pluginState outside a mutex
+lock, so pluginState should be made an atomic variable. Once that is
+done, we'll only need locking the mutex to update errorString (no
+locking before loading).
+
+Fixes: QTBUG-83207
+Task-number: QTBUG-39642
+Change-Id: Ibdc95e9af7bd456a94ecfffd160209304e5ab2eb
+Reviewed-by: Volker Hilsheimer
+Reviewed-by: David Faure
+---
+
+diff --git a/src/corelib/plugin/qlibrary.cpp b/src/corelib/plugin/qlibrary.cpp
+index ddb053c..be9d92b 100644
+--- a/src/corelib/plugin/qlibrary.cpp
b/src/corelib/plugin/qlibrary.cpp
+@@ -576,9 +576,7 @@
+
+ Q_TRACE(QLibraryPrivate_load_entry, fileName);
+
+-mutex.lock();
+ bool ret = load_sys();
+-mutex.unlock();
+ if (qt_debug_component()) {
+ if (ret) {
+ qDebug() << "loaded library" << fileName;
+diff --git a/src/corelib/plugin/qlibra
bug#42480: cabal-install/GHC fails to find libraries
Hi Guix, I have a haskell project until recently compiled with the following: env -u GHC_PACKAGE_PATH cabal new-build Now it fails with the following: ld: cannot find -lm ld: cannot find -lpthread ld: cannot find -lz ld: cannot find -lrt ld: cannot find -lutil ld: cannot find -ldl ld: cannot find -lpthread ld: cannot find -lm ld: cannot find -lrt ld: cannot find -ldl ld: cannot find -lpthread ld: cannot find -lpthread ld: cannot find -lpthread ld: cannot find -lc Could a graft be failing to update references to various libraries? I really don't know what could be going on. Thanks! John
bug#41362: error when running guix pull on i686-linux
Hi Mayeul, Does this bug still show up for you? https://issues.guix.gnu.org/41362 TIA, Ludo’.
bug#42480: cabal-install/GHC fails to find libraries
John Soo writes: > I have a haskell project until recently compiled with the following: > > env -u GHC_PACKAGE_PATH cabal new-build > > Now it fails with the following: [ld errors] Do you have “gcc-toolchain” installed? -- Ricardo
bug#42480: cabal-install/GHC fails to find libraries
Hi Ricardo, I do have gcc-toolchain installed and I just realized that my project compiles fine if I do not try to statically link. I believe this can be closed as dynamic linking works fine. My mistake. I did see the issue regarding captured inputs to ghc. I am in favor of removing them. I always must have gcc-toolchain installed when using ghc anyways. Thanks again, John
