bug#51466: [PATCH 0/1] environment: properly parse environment variables during --check
The PS1=; for i in 1 2 3; do echo GUIX_FLUSH_$i; done; hack appears to work for me but here is my alternate version. I don't think we have to hack our way around the shell if we can dump the environment variables somewhere else. I added a test but the potato machine I'm running that on is taking a very long time to run the whole thing (I did run the test in isolation with and without my patch), would you mind checking it works for you (and can we use Bash there?). Note I'm still not sure why we have env || /usr/bin/env (in case we mess with the PATH I guess?) so I've kept it. Comments welcome, I haven't coded much in Guile/Scheme. Kevin Boulain (1): environment: properly parse environment variables during --check guix/scripts/environment.scm | 65 +++- tests/guix-environment.sh| 16 + 2 files changed, 57 insertions(+), 24 deletions(-)
bug#54597: Bug report
Emailing a bug report as directed in the terminal output: guest@gnu ~$ guix pull Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... Authenticating channel 'guix', commits 9edb3f6 to 943d4b7 (17,238 new commits)... Building from this channel: guix https://git.savannah.gnu.org/git/guix.git 943d4b7 substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% building /gnu/store/sflmgcfcdwizj7iyd3pfksdvrkc3pskb-config.scm.drv... building /gnu/store/7k17dvmcrdicjsdxmpvhss4p3i3d70j5-git.scm.drv... building /gnu/store/j9s3n7iqvh8pqkxkwy91nq3qynr1nby7-hash.scm.drv... building /gnu/store/a5l8a1pypzi7wxj7vpakpm9658piay4y-module-import.drv... building /gnu/store/q26gk38hpnkpdyvxjjybq2hnyxzhk8y2-module-import.drv... building /gnu/store/mv01zhjs1dvxmsdmsw69d8y473nhrnsx-module-import-compiled.drv... building /gnu/store/hr91y089gmk18wwjslhblq3yl9mhv48w-module-import-compiled.drv... building /gnu/store/dg7gfaahxg65mz7hakkk356xm4kdshdc-compute-guix-derivation.drv... Computing Guix derivation for 'x86_64-linux'... \guix pull: error: You found a bug: the program '/gnu/store/jmxd76lck2yb88k3lzhgb4fblmsivcap-compute-guix-derivation' failed to compute the derivation for Guix (version: "943d4b775b9b1cc645e86206b0cf07da8d0030b3"; system: "x86_64-linux"; host version: "1.3.0-1.771b866"; pull-version: 1). Please report the COMPLETE output above by email to
bug#51466: [PATCH 1/1] environment: properly parse environment variables during --check
Should solve https://issues.guix.gnu.org/51466.
This redirects the env command's output to a temporary file so that
there is no way to get it mixed with the shell's output (like PS1).
Additionnally:
- Remove GUIX-CHECK-DONE and read: I don't think there is a need for
them as discarding the output until the shell exits is enough to
guarantee the environment has been dumped. Sadly, Linux doesn't
report EOF but EIO when the shell exits and the pty gets closed hence
the catch/throw.
- Don't try to parse environment variables by splitting them on \n,
instead use env's -0 option to separate environment variables with
\0. This prevent incorrect parsing of some multi-line variables
(e.g.: f() { echo "hello"; }; declare -fx f) but isn't standard.
* guix/scripts/environment.scm (child-shell-environment): make
environment variables parsing more robust.
* tests/guix-environment.sh: add a simple test that was reliably
failing on my machine.
---
guix/scripts/environment.scm | 65 +++-
tests/guix-environment.sh| 16 +
2 files changed, 57 insertions(+), 24 deletions(-)
diff --git a/guix/scripts/environment.scm b/guix/scripts/environment.scm
index ec071402f4..4ff13c6bde 100644
--- a/guix/scripts/environment.scm
+++ b/guix/scripts/environment.scm
@@ -48,7 +48,7 @@ (define-module (guix scripts environment)
#:autoload (gnu packages bash) (bash)
#:autoload (gnu packages bootstrap) (bootstrap-executable %bootstrap-guile)
#:use-module (ice-9 match)
- #:autoload (ice-9 rdelim) (read-line)
+ #:autoload (ice-9 rdelim) (read-delimited read-line)
#:use-module (ice-9 vlist)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-11)
@@ -413,16 +413,22 @@ (define (child-shell-environment shell profile manifest)
"Create a child process, load PROFILE and MANIFEST, and then run SHELL in
interactive mode in it. Return a name/value vhash for all the variables shown
by running 'set' in the shell."
- (define-values (controller inferior)
-(openpty))
-
- (define script
-;; Script to obtain the list of environment variable values. On a POSIX
-;; shell we can rely on 'set', but on fish we have to use 'env' (fish's
-;; 'set' truncates values and prints them in a different format.)
-"env || /usr/bin/env || set; echo GUIX-CHECK-DONE; read x; exit\n")
-
(define lines
+(let* ((environment-port (mkstemp "/tmp/guix-enviroment-XX"))
+ (environment-file (port-filename environment-port))
+ ;; Script to obtain the list of environment variable values. On a
+ ;; POSIX shell we can rely on 'set', but on fish we have to use
'env'
+ ;; (fish's 'set' truncates values and prints them in a different
+ ;; format.)
+ ;; We rely on env --null to mark the end of environment variables.
+ ;; This is expected to be safe because POSIX defines environment
+ ;; variables end with '\0' (but does't document the --null option).
+ ;; Some shells, like Bash, allow to export functions, which will
span
+ ;; multiple lines and break any trivial parsing relying on '\n'.
+ (script (format #f "env --null > ~a || /usr/bin/env --null > ~a;
exit\n"
+ environment-file environment-file)))
+
+ (let-values (((controller inferior) (openpty)))
(match (primitive-fork)
(0
(catch #t
@@ -436,26 +442,37 @@ (define lines
(primitive-exit 127
(pid
(close-fdes inferior)
- (let* ((port (fdopen controller "r+l"))
- (result (begin
+ (let ((port (fdopen controller "r+l")))
(display script port)
+ (catch 'system-error
+ (lambda ()
+ ;; We aren't interested in the output of the shell itself,
+ ;; drop it.
+ (while (not (eof-object? (read-line port)
+ (lambda args
+ (let ((errno (system-error-errno args)))
+ (cond
+((= errno EIO)
+ ;; On Linux, a read won't return EOF but will fail with
EIO
+ ;; when the device is closed:
+ ;; https://bugs.python.org/issue5380#msg252544
+ #t)
+(#t
+ (apply throw args))
+ (close-port port)
+ (waitpid pid)
+
+ (let ((result (begin
(let loop ((lines '()))
- (match (read-line port)
+(match (read-delimited "\0" environment-port)
((? eof-object?) (reverse lines))
-("GUIX-CHECK-DONE\r"
- (display "done\n" port)
- (reverse lines))
(line
- ;; Drop the '\r' from
bug#54607: ncurses attrset colour pair ignored in favour of bkgd
Hello
With ncurses, the "attrset" colour pair is ignored when the background
colour pair is set with "bkgd".
I ran into this issue when compiling robotfindskitten, but it is not
specific to that program and can be reproduced with the attached small
test code. When compiled with "gcc test.c -lncurses", "./a.out" is
expected to display the sample text in yellow (the brownish curses
equivalent of yellow), which is set with "attrset". It does so when
compiled as usual without guix. If compiled in guix, the sample text is
blue instead, which is set with "bkgd" for background and for some
reason is not overridden by "attrset". If the "bkgd" line is removed,
"attrset" works as usual.
This affects software compiled in a guix shell (guix environment), or
on a guix system, or with "guix build" and "guix install".
It does not seem to be caused by the terminal properties or environment
variables because it can be reproduced on the same Debian machine after
compiling (1) with guix (in a guix environment) and (2) without guix.
I tried compiling with guix having ncurses 6.2.20210619 (current guix)
and 6.2.20200212 (from the older guix image from the website and in
Debian bullseye). I tried compiling without guix on Debian with
development packages for ncurses 6.2+20201114-2 (bullseye) and 6.3-2
(bookworm) and on Fedora with its development package for ncurses
6.2.20210508.
I was pointed in a forum to "render_char" function in lib_addch.c, [1]
which defines how colour is applied. But there seem to be no
modifications to that in guix as far as I can see.
[1]:
https://github.com/ThomasDickey/ncurses-snapshots/blob/6b3112c16ee04882a512f9aa967e34dba5e362e1/ncurses/base/lib_addch.c#L57
Roman
#include
int main() {
initscr();
start_color();
init_pair ( 1, COLOR_BLUE, COLOR_BLACK );
init_pair ( 2, COLOR_YELLOW, COLOR_BLACK );
bkgd ( (chtype) COLOR_PAIR(1) );
attrset ( COLOR_PAIR(2) );
printw ( "NO WAR!" );
refresh();
getch();
endwin();
return 0;
}
bug#54557: “fakechroot” execution engine doesn’t work for Bash
Hi, Maxim Cournoyer skribis: > I'd be OK with --without-bash-malloc; it seems we'll pay a bit in terms > of Bash performance in exchange for better memory usage. It also brings > benefits such as solving this issue and may benefit from > advances/bugfixes to glibc's malloc in the future, if there are any. We might actually benefit from the improvements made in glibc’s malloc over the years (it’s more actively developed than that of Bash), who knows. Anyway, pushed to ‘core-updates’ as c6b5161e97ed1010d61331874b09c3231af3b1f9. Thanks, Ludo’.
bug#52808: Guix home should not assume that all targets are dot files
On 2022-03-20 22:00, Ludovic Courtès wrote:
> I wrote:
>
>> I finally got around to committing it as
>> 6da2a5a5655668f42ec5b26f875ddbc498e132b6. Thank you!
>
> I hit “close” too quickly: we still need the patch that changes
> ‘home-files-service-type’ and/or symlink-manager.scm to not prepend a
> dot, so reopening! :-)
>
> Ludo’.
Forgot to update fish home service in previous patch series, please
apply this patch as well:
From 7d9cf53ab574c8ab468bfdae2798de65af6c00b5 Mon Sep 17 00:00:00 2001
From: Andrew Tropin
Date: Mon, 28 Mar 2022 12:14:10 +0300
Subject: [PATCH] home: shells: Migrate fish to xdg-configuration-files.
* gnu/home/services.scm (home-fish-service-type): Migrate to
home-xdg-configuration-files-service-type.
---
gnu/home/services/shells.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gnu/home/services/shells.scm b/gnu/home/services/shells.scm
index 7b9769bcf3..fb728893e3 100644
--- a/gnu/home/services/shells.scm
+++ b/gnu/home/services/shells.scm
@@ -586,7 +586,7 @@ (define-configuration home-fish-configuration
serialize-fish-abbreviations))
(define (fish-files-service config)
- `(("config/fish/config.fish"
+ `(("fish/config.fish"
,(mixed-text-file
"fish-config.fish"
#~(string-append "\
@@ -650,7 +650,7 @@ (define home-fish-service-type
(service-type (name 'home-fish)
(extensions
(list (service-extension
-home-files-service-type
+home-xdg-configuration-files-service-type
fish-files-service)
(service-extension
home-profile-service-type
--
2.34.0
--
Best regards,
Andrew Tropin
signature.asc
Description: PGP signature
bug#54557: “fakechroot” execution engine doesn’t work for Bash
Hi, Philippe SWARTVAGHER skribis: > FTR, the --without-bash-malloc is used in the Debian bash package: > > apt source bash > > cd bash-5.1/debian > > grep -Irn without-bash-malloc > changelog:145: * Configure the normal build --without-bash-malloc as well. > changelog:1125: * Configure the static build --without-bash-malloc. > changelog:1462: * Disable the GNU/kFreeBSD kludge > (--without-bash-malloc). Closes: #234137. > changelog:1546: * Configure --without-bash-malloc on GNU/FreeBSD > (closes: #194182). > changelog:1739: * Configure --without-bash-malloc. At least on hppa, > this fixes an error, > rules:79: --without-bash-malloc > > > This option is also advised in Linux From Scratch: > https://www.linuxfromscratch.org/lfs/view/stable/chapter08/bash.html Good to know, thanks for sharing. I just realized that ‘bash-minimal’ in Guix already uses it, so that’s another way to work around the ‘guix pack -RR’ issue at hand. Ludo’.
bug#25957: gitolite broken: created repositories keep references to /usr/bin for hooks
On Wed, Mar 23, 2022 at 01:44:29PM +0100, Maxime Devos wrote: > zimoun schreef op wo 23-03-2022 om 11:45 [+0100]: > > > On Wed, 12 Jan 2022 at 20:07, Efraim Flashner > > > wrote: > > > > > > > > …the package redis is not a dependency of gitolite. Therefore, > > > > > the > > > > > question is: is our Gitolite package working with Redis? Even > > > > > using the > > > > > /usr/bin one? Idem for SVN. > > > > > > > > > > Otherwise, I am favor to remove the 2 “problematic” > > > > > references. WDYT? > > > > > > > > Or change it to search the $PATH for the binary, so it would just > > > > be > > > > 'redis-server' or 'svnserve' > > > > > > Is our Gitolite package working with Redis? If not, why try to > > > fix. ;-) > > > > What is the status of this old bug [1]? Is it actionable? If yes, > > what > > is the action? If no, let close it. :-) WDYT? > > Seems like all we have to do is 'substitute*' a '/usr/bin/svnserve' > into a '/gnu/store/...' (untested), so seems actionable to me. > Alternatively, as Efraim wrote, let it search the $PATH (that might be > useful if adding svnserve would increase the closure too much and it is > an optional dependency in practice?). I spent some time looking at gitolite and the service. As I understand it, with the exception of svnserve, it searches $PATH for a number of different binaries, including git-annex. I believe that this would only work if git-annex (and potentially other packages) are installed globally. In addition, git (not git-minimal) and openssh are propagated inputs AND wrapped. I haven't tested to see if wrapping only is enough. I think the best choice is to: A: Replace /usr/bin/svnserve with svnserve so it will just search $PATH, like it does with the other helpers. B: Adjust the service so that it automatically creates a variant (or just a wrapped version) of the package which is wrapped with a list of additional packages so that they can be in gitolite's path. If I were deploying this to an arm device I wouldn't want it wrapped with git-annex since it doesn't build, but would definitely want it for an x86_64 machine. I suppose we should try to find someone who is using the gitolite service and see if they can be our test subject for wrapping the package with optional addons. -- Efraim Flashner אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted signature.asc Description: PGP signature
