bug#48373: vice: processor dependency
This is the build log from the server. there may be clues here if it differs from yours: https://ci.guix.gnu.org/build/290428/log/raw
bug#48343: Cannot boot after installation
If setting nomodeset is the answer, there is a trick you can use in GRUB to set it before boot. Apparently in GRUB, you: 1. Press e 2. Edit the linux ... line to add nomodeset as an option 3. Press ctrl X I just found the instructions here https://duckduckgo.com/?q=grub+nomode+set At least give that a go and report back if it works.
bug#48373: vice: processor dependency
I'm curious the guix version would also build differently on your computer. You can run for example guix build vice --no-grafts --check to build it from source and check the difference. if its different, something like guix gc -D $(guix build --no-grafts vice); guix build --no-substitutes vice should delete it and built it from source without using the prebuilt binary. If it's different then its a reproducibility bug. Some packages are actually intended to be that way, like atlas, and have substitutable? #f set so that they are always built and tuned to the cpu it's used on. On my computer, AMD 5700X, the built is identical to the substitute: b@jiu ~/code/guix [env]$ guix challenge vice 1 store items were analyzed: - 1 (100.0%) were identical - 0 (0.0%) differed - 0 (0.0%) were inconclusive
bug#39527: Cannot log into LXQt DE
Sorry for not responding to this bugreport earlier. It is most likely the same issue as https://issues.guix.gnu.org/36508 https://issues.guix.gnu.org/36508 . Running this would most likely fix it for now, provided you have the gdm service installed. sudo chmod -R gdm:gdm /var/lib/gdm
bug#40039: 'wrap-script' introduces spurious argument
Same patch as before, but with a test case. Have a play with it and see if it
makes sense.
From 21d5f4e01be7f9b86649f4176f53e14854b58d53 Mon Sep 17 00:00:00 2001
From: Brendan Tildesley
Date: Thu, 29 Apr 2021 20:33:08 +1000
Subject: [PATCH] utils: Fix wrap-script argument handling.
* guix/build/utils.scm (wrap-script):
Don't add (car cl) one too many times, cl its self contains it's car.
Split the aguments string with string-tokenize to avoid leaving an empty
string argument when there should be none. These two bugs seemed to
be partially cancelling each other out so that scripts still worked when
ran with no arguments.
* tests/build-utils.scm: Adjust wrap-script to above changes.
Add two tests to ensure the command line arguments appear identical to a
script and its wrapped version.
---
guix/build/utils.scm | 8 +++
tests/build-utils.scm | 55 +++
2 files changed, 54 insertions(+), 9 deletions(-)
diff --git a/guix/build/utils.scm b/guix/build/utils.scm
index 419c10195b..cc2a020fbf 100644
--- a/guix/build/utils.scm
+++ b/guix/build/utils.scm
@@ -5,6 +5,7 @@
;;; Copyright © 2015, 2018 Mark H Weaver
;;; Copyright © 2018 Arun Isaac
;;; Copyright © 2018, 2019 Ricardo Wurmus
+;;; Copyright © 2021 Brendan Tildesley
;;;
;;; This file is part of GNU Guix.
;;;
@@ -1295,10 +1296,9 @@ not supported."
`(let ((cl (command-line)))
(apply execl ,interpreter
(car cl)
- (cons (car cl)
- (append
-',(string-split args #\space)
-cl))
+ (append
+ ',(string-tokenize args char-set:graphic)
+ cl)
(template (string-append prog ".XX"))
(out (mkstemp! template))
(st (stat prog))
diff --git a/tests/build-utils.scm b/tests/build-utils.scm
index 654b480ed9..f3f31deaf6 100644
--- a/tests/build-utils.scm
+++ b/tests/build-utils.scm
@@ -1,6 +1,7 @@
;;; GNU Guix --- Functional package management for GNU
;;; Copyright © 2012, 2015, 2016, 2019, 2020 Ludovic Courtès
;;; Copyright © 2019 Ricardo Wurmus
+;;; Copyright © 2021 Brendan Tildesley
;;;
;;; This file is part of GNU Guix.
;;;
@@ -165,9 +166,7 @@ echo hello world"))
"/some/path:/some/other/path"
'(let ((cl (command-line)))
(apply execl "/anything/cabbage-bash-1.2.3/bin/sh"
- (car cl)
- (cons (car cl)
- (append '("") cl)
+ (car cl) cl)))
script-contents)
(call-with-temporary-directory
(lambda (directory)
@@ -206,8 +205,7 @@ print('hello world')"))
`(let ((cl (command-line)))
(apply execl "/anything/cabbage-bash-1.2.3/bin/python3"
(car cl)
- (cons (car cl)
- (append '("" "-and" "-args") cl)
+ (append '("-and" "-args") cl
script-contents)
(call-with-temporary-directory
(lambda (directory)
@@ -241,4 +239,51 @@ print('hello world')"))
"/some/other/path")))
#f)
+(define (arg-test bash-args)
+ (call-with-temporary-directory
+ (lambda (directory)
+ (let ((script-file-name (string-append directory "/bash-test.sh")))
+ (call-with-output-file script-file-name
+ (lambda (port)
+ (display (string-append "\
+#!" (which "bash") bash-args "
+echo \"$#$0$*${A}\"")
+port)))
+
+ (display "Unwrapped script contents:\n")
+ (call-with-input-file script-file-name
+ (lambda (port) (display (get-string-all port
+ (newline) (newline)
+ (chmod script-file-name #o777)
+ (setenv "A" "A")
+ (let* ((run-script (lambda _
+(open-pipe*
+ OPEN_READ
+ script-file-name "1" "2" "3 3" "4")))
+ (pipe (run-script))
+ (unwrapped-output (get-string-all pipe)))
+ (close-pipe pipe)
+
+ (wrap-script script-file-name `("A" = ("A\nA")))
+
+ (display "Wrapped script contents:\n")
+ (call-with-input-file script-file-name
+ (lambda (port) (display (get-string-all port
+ (newline) (newline)
+
+ (let* ((pipe (run-script))
+(wrapped-output (get-string-all pipe)))
+ (close-pipe pipe)
+ (display "./bash-test.sh 1 2 3\\ 3 4 # Output:\n")
+
bug#34016: Git checkouts managed by (guix git) grow indefinitely
Since this bug report 1.1.0 was released. The Changelog includes this note: "Repositories with a large number of packfiles no longer exhaust the number of file descriptors." https://github.com/libgit2/libgit2/pull/5396 May or may not be related to this.
bug#41138: IceDove
Problem is gone for me now. (78.6.0)
bug#36508: GDM files have incorrect owner after temporarily removing service
> On 04/14/2021 12:32 PM Ludovic Courtès wrote: > > > Hi Mark, > > Mark H Weaver skribis: > > > Brendan Tildesley via Bug reports for GNU Guix > > writes: > > > >> I recently encountered what is likely the same bug. The directory > >> /var/lib/gdm > >> had the correct permissions gdm:gdm, but all the files inside had > >> something like > >> 973:gdm > > > > The underlying problem here, which I've also experienced, is that if you > > reconfigure your system with fewer users/groups, and then later add > > those users/groups back, there is no guarantee that they will be > > assigned the same UIDs and GIDs. > > Yes. > > The patch Brendan posted LGTM (though I’m surprised the directory itself > can have the right UID/GID while files inside it don’t; perhaps this was > made possible by 2161820ebbbab62a5ce76c9101ebaec54dc61586, which chowns > the home directory unconditionally.) > > Note that there are other places, in addition to GDM, where we > forcefully reset the UID/GID of the home directory (e.g., for the > ‘knot-resolver’ service.) > > My preferred solution to this would be to unconditionally chown -R home > directories upon activation (for efficiency, it would be best if we > could do that if and only if the home directory itself has wrong > ownership). Thoughts? > I'm confused. It sounds like you're suggesting to add the very IF condition that my patch removes from %gdm-activation in order to fix the problem.
bug#36508: GDM files have incorrect owner after temporarily removing service
> On 04/13/2021 10:51 PM Mark H Weaver wrote: > > > Hi Brendan, > > Brendan Tildesley via Bug reports for GNU Guix > writes: > > > I recently encountered what is likely the same bug. The directory > > /var/lib/gdm > > had the correct permissions gdm:gdm, but all the files inside had something > > like > > 973:gdm > > The underlying problem here, which I've also experienced, is that if you > reconfigure your system with fewer users/groups, and then later add > those users/groups back, there is no guarantee that they will be > assigned the same UIDs and GIDs. > > This problem is made much worse by the fact that files may be left > around, e.g. in /var, with the old UIDs and GIDs. > > In your case, I guess that the 'gdm' user was previously assigned UID > 973, but now it has been given a different UID. > > In my case, after reconfiguring to a minimal system and later switching > back to a full GNOME-based desktop system, I found that many files and > directories in /var had the wrong owner or group. Here's what I saw > before I cleaned things up: > > --8<---cut here---start->8--- > root@jojen ~# ls -l /var/lib/ > total 4 > drwxr-xr-x 1 colord colord40 Mar 28 2017 colord > drwx-- 1 995978 56 Sep 3 02:10 gdm > drwx-- 1 root root 30400 Dec 25 01:55 NetworkManager > -rw--- 1 root root 512 Dec 25 01:35 random-seed > drwxr-xr-x 1 colord colord 164 Dec 28 2017 sddm > drwx-- 1 tortor 178 Dec 19 21:28 tor > drwx-- 1 root root 20 Sep 5 01:32 udisks2 > drwxr-xr-x 1 root root 274 Dec 25 01:55 upower > drwxr-xr-x 1 root root 86 Mar 28 2017 wicd > root@jojen ~# ls -la /var/lib/gdm/ > total 4 > drwx-- 1 995978 56 Sep 3 02:10 . > drwxr-xr-x 1 root root 750 Dec 25 01:59 .. > drwxr-xr-x 1 994 colord 64 Sep 3 02:10 .cache > drwx-- 1 994 colord 54 Sep 3 02:10 .config > -rw--- 1 994 colord 16 Sep 3 02:10 .esd_auth > drwxr-xr-x 1 994 colord 10 Sep 3 02:10 .local > root@jojen ~# > --8<---cut here---end--->8--- > > Given the fact that existing files and directories in /var can > *effectively* have their ownership changed, I think that this issue > could be a security risk. Yes and they could change for any reason under the sun, and so we have no choice but to set them right on service activation. Guix system rollbacks should be a supported feature of Guix, not just a gimmick that falls out of its design. It should be that a Guix user could leave their system for 5 years, and then do a guix pull; guix system reconfigure in the year 2026. Perhaps at that time the new system will break, and then its desirable that they can rollback to the previous generation. So what fixes we put in to Guix services today need to consider not just how files could have changed in the past, but how they might change in breaking ways in the future, within reason. I don't know off the top of my head of any way that can be done other than to have chmod -R gdm:gdm /var/lib/gdm always executed. > > There's some discussion of this issue at <https://bugs.gnu.org/44944>, > although I'm not sure that Danny's suggested solution is practical. > > Here's one idea: when activating a system, *never* delete users or > groups if files still exist that are owned by those users/groups. > Checking all filesystems would likely be too expensive, but perhaps it > would be sufficient to check certain directories such as /var, /etc, and > possibly the top directory of /home. > > What do you think Wouldn't that imply that uids could be randomly different on different systems with the same configuration, and then remain statically different permanently? We want as little randomness and moving parts as possible. It's yet another way the system is not actually Functional, but has state. Seems this bug spans 3 or so different bug reports. In http://issues.guix.gnu.org/45571 I commented that Nix uses hard coded id's, sorta like how ports are allocated for a purpose: https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix Perhaps you are thinking of other kinds of security issues that could be caused that I'm not thinking of. In that case maybe Nix devs have already made the best choice by making them static? ... After all, if the permissions can change, then it is possible another user could actually modify the contents of /var/lib/gdm its self, thereby infecting other users, if for some reason that other malicious user gets allocated that ID. That further points towards static ID's like Nix has as a solution.
bug#36508: GDM files have incorrect owner after temporarily removing service
I recently encountered what is likely the same bug. The directory /var/lib/gdm had the correct permissions gdm:gdm, but all the files inside had something like 973:gdm a43e9157ef479e94c19951cc9d228cf153bf78ee is supposed to fix this (duplicate bug 37423) but it only checks the permissions of /var/lib/gdm/ itself. Not all of the files in it. This explains why in my case it failed to fix the permissions, because the directory was gdm:gdm. How it got that way I don't know, and infact it doesn't really matter. The directory is mutable, and thus can theoretically be changed for any number of reasons. Therefore if we wish for Guix to be robust with it's Functional design, and have meaningful rollbacks, we perhaps have no choice but to assert the required invariants like these on mutable files. A better solution may be to make it fully chown -R on reconfigure, but not each time on boot? I've attached an untested patch with a suggested solution of making %gdm-activation operate every single time, instead of just after checking /var/lib/gdm. From 31cb6dbd756af695bd6a1f4d4c89b42367b13307 Mon Sep 17 00:00:00 2001 From: Brendan Tildesley Date: Tue, 13 Apr 2021 23:04:28 +1000 Subject: [PATCH] services: gdm: Correctly set ownership on /var/lib/gdm. * gnu/services/xorg.scm (%gdm-activation): Always chown /var/lib/gdm, instead of only when it appears to be correct, because it's still possible the files inside could be wrong and break GDM. I encountered this once: https://issues.guix.gnu.org/36508 . Perhaps it is with good intentions to try not running this code every single time on boot, but when it fails, the consequence is that GDM can break not just for the current revision, but all previous rollback systems in GRUB will fail, and subsequent reconfigure-ings fail too. That totally destroys a desktop system and our rollback functionally, which is much much worse! --- gnu/services/xorg.scm | 15 +-- 1 file changed, 5 insertions(+), 10 deletions(-) diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm index 17d983ff8d..a206c7c93a 100644 --- a/gnu/services/xorg.scm +++ b/gnu/services/xorg.scm @@ -861,16 +861,11 @@ the GNOME desktop environment.") (let* ((gdm (getpwnam "gdm")) (uid (passwd:uid gdm)) - (gid (passwd:gid gdm)) - (st (stat "/var/lib/gdm" #f))) - ;; Recurse into /var/lib/gdm only if it has wrong ownership. - (when (and st - (or (not (= uid (stat:uid st))) - (not (= gid (stat:gid st) -(for-each (lambda (file) -(chown file uid gid)) - (find-files "/var/lib/gdm" - #:directories? #t))) + (gid (passwd:gid gdm))) + (for-each (lambda (file) + (chown file uid gid)) +(find-files "/var/lib/gdm" +#:directories? #t)) (define dbus-daemon-wrapper (program-file -- 2.31.1
bug#37955: warning: '.desktop' file refers to '', which cannot be found
> On 04/09/2021 7:39 PM Pierre Neidhardt wrote: > > > So if the path is already an absolute store path, then I suppose that > the whole phase is superfluous, isn't it? > > Couldn't we just delete it? Do you mean delete the phase entirely or just from Racket? It's not always the case that they are absolute paths. Racket probably just has some code to generate them automatically.
bug#37955: warning: '.desktop' file refers to '', which cannot be found
> On 04/09/2021 1:23 PM Pierre Neidhardt wrote:
>
>
> Thanks for the investigation. Would you like to send a patch?
I'm not sure what the right way to fix it is. I may have come up with a
brilliant idea. Untested patch attached.From 64c200f3630de13ec3487cb5c756b47b133c6ecf Mon Sep 17 00:00:00 2001
From: Brendan Tildesley
Date: Fri, 9 Apr 2021 21:43:54 +1000
Subject: [PATCH] build: gnu-build-system: Improve patch-dot-desktop-files.
* guix/build/gnu-build-system.scm (patch-dot-desktop-files):
When patching .desktop files, Exec= values beginning with '/', (or
spaces or newline characters) will result in the 'binary' symbol
matching an empty string. Changing *, meaning 0 or more, to +, meaning 1
or more ensures it will match a binary of atleast 1 length, or nothing.
---
guix/build/gnu-build-system.scm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index 2e7dff2034..99636c442a 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -725,9 +725,9 @@ which cannot be found~%"
;; UTF-8-encoded.
(with-fluids ((%default-port-encoding "UTF-8"))
(substitute* files
- (("^Exec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
+ (("^Exec=([^/[:blank:]\r\n]+)(.*)$" _ binary rest)
(string-append "Exec=" (which binary) rest))
- (("^TryExec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
+ (("^TryExec=([^/[:blank:]\r\n]+)(.*)$" _ binary rest)
(string-append "TryExec="
(which binary) rest)
outputs)
--
2.31.1
bug#37955: warning: '.desktop' file refers to '', which cannot be found
The Exec paths in these files already refer to absolute paths, infact,
/gnu/store paths
Thus the regex:
("^Exec=([^/[:blank:]\r\n]*)(.*)$" _ binary rest)
with binary = empty string and rest = everything after Exec=
Why? The second subexpression [^/[:blank:]\r\n]* is bound to binary, but it
means anything
that is a series of anything that is not /, space, or newline. absolute paths
start with /, so it matches nothing (empty string), and continues to call
(which "").
I notice this phase hasn't been edited in 5 years and has other issues, for
example:
1. patch-dot-desktop-files only searches the output of the package for paths,
not the inputs. This means for example xfce4-settings fails to patch references
to exo-open in desktop files.
The code should be remade to be more /correct/, and handle all unexpected
inputs. In this case the phase is accidentally doing the right thing by failing
in a harmless way and correctly not patching the files, but emitting a warning.
bug#46212: ci.guix.gnu.org narinfos with excessive NarSize
I just had the same bug with flightgear as Ludo. Running `guix build flightgear', guix showed it was downloading substitute information, and then errored with guix build: error: integer expected from stream Possibly helpful strace info: write(14, "\36\0\0\0\0\0\0\0\3\0\0\0\0\0\0\0?\0\0\0\0\0\0\0/gnu/store/ssdka48kwx9f2z54j63mjxvn6bg502mm-flightgear-2018.3.5\0@\0\0\0\0\0\0\0/gnu/store/pr6xy604hg7yhcinnlymrkc958kl0bnn-openscenegraph-3.4.1<\0\0\0\0\0\0\0/gnu/store/g8g4paw3q3z8hkl441ddhdn0in54gi3f-simgear-2018.3.5\0\0\0\0", 232) = 232 read(14, "ptxc\0\0\0\0", 8) = 8 read(14, "\34\0\0\0\0\0\0\0", 8)= 8 read(14, "integer expected from stream\0\0\0\0", 32) = 32 read(14, "\1", 1) = 1 read(14, "\0\0\0\0\0\0\0", 7) = 7 close(14)
bug#45571: Support stable uids and gids for system accounts in a container
It may be useful to see what Nix does. Nix has many static id, with the comment: # IMPORTANT! # We only add static uids and gids for services where it is not feasible # to change uids/gids on service start, in example a service with a lot of # files. Please also check if the service is applicable for systemd's https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/misc/ids.nix
bug#47618: "guix upgrade" and "guix package -u ." inconsistency
Below, --do-not-upgrade appears to be behaving like "--only-upgrade". I realised this comes about because I didn't use '='. guix upgrade takes all other arguments to be upgrade regex's, but it still seems. _wrong_. Some long arguments in guix require and = sign after them, and the cli help indicates as much, but --do-not-upgrade seems to break that pattern and takes all arguments after it to be regexes's to match and not upgrade. flags that have this behaviour of acting on all arguments after them should indicate clearly they do that. and indicated if the '=' is optional using some intuitive notation. The line: --do-not-upgrade[=REGEXP] do not upgrade any packages matching REGEXP suggest it must take either no argument or only '=something'. guix upgrade --help says that it is an alias for 'guix package -u .'. My understanding is that the meaning of alias is something that can be substituted and it will behave the same, like Bash aliases. We should change 'guix upgrade''s behaviour to be like 'guix package -u', taking all arguments after --do-not-upgrade as regex's to not upgrade. b@jiu ~/code/guix [env]$ guix upgrade --do-not-upgrade '^[a-n]' The following packages will be upgraded: audacity (dependencies or package changed) cool-retro-term (dependencies or package changed) deluge(dependencies or package changed) diffoscope170 → 171 emacs (dependencies or package changed) eog (dependencies or package changed) evince(dependencies or package changed) ffmpeg(dependencies or package changed) git 2.31.0 → 2.31.1 git:send-email2.31.0 → 2.31.1 gnome-font-viewer (dependencies or package changed) gnome-tweaks (dependencies or package changed) godot (dependencies or package changed) ibus (dependencies or package changed) ibus-anthy(dependencies or package changed) icecat(dependencies or package changed) keepassxc (dependencies or package changed) lm-sensors(dependencies or package changed) lollypop (dependencies or package changed) mpv (dependencies or package changed) mumble(dependencies or package changed) 62.6 MB will be downloaded ^C b@jiu ~/code/guix [env]$ guix package -u . --do-not-upgrade '^[a-n]' The following packages will be upgraded: obs(dependencies or package changed) piper (dependencies or package changed) playonlinux(dependencies or package changed) rhythmbox (dependencies or package changed) stellarium (dependencies or package changed) syncthing-gtk (dependencies or package changed) tinc (dependencies or package changed) transmission:gui (dependencies or package changed) ungoogled-chromium (dependencies or package changed) vlc(dependencies or package changed) youtube-dl (dependencies or package changed) zrythm (dependencies or package changed) The following derivation will be built: /gnu/store/6ldzv7ilcsg4ah8vyig9vyh9y79yz6m1-tinc-1.1pre17.drv
bug#38907: close?
Since 38408 has been pushed, can you close this one if the issue has been fixed?
