bug#54292: Commit e8518c43 breaks guix pull on i686
Hi Liliana, Liliana Marie Prikler writes: > Am Dienstag, dem 08.03.2022 um 13:33 -0500 schrieb Philip McGrath: [...] >> I don't know what the most correct way would be to write this code, >> but I think we could defer the error until someone attempts to build >> the package for the unsupported system by just writing something >> like: >> >> (define machine >> #$(and=> (nix-system->chez-machine) >> chez-machine->threaded)) > I pushed that definition upstream, but a rewrite is still needed. I can confirm that commit b8fc9169 (gnu: stex-bootstrap: Guard against unsupported systems.) fixes this bug: The package cache builds and guix pull succeeds on i686-linux. [...] Thanks, Diego
bug#54292: Commit e8518c43 breaks guix pull on i686
Hi Liliana, Liliana Marie Prikler writes: > Hi, > > Am Montag, dem 07.03.2022 um 12:47 + schrieb Diego Nicola Barbato: >> Hi Guix, >> >> Commit e8518c43 (gnu: Add stex) breaks guix pull, specifically the >> package cache hook, on i686-linux. > This series also fails on CI in a rather peculiar manner [1,2,3]. > However, it succeeded on bordeaux, even for i686 [4]. While these CI issues are certainly interesting and possibly deserving of their own bug reports, they have little to do with this bug report: I didn't try to build chez-nanopass [1], chez-scheme-for-racket-bootstrap-bootfiles [2], or racket [4] itself and I didn't experience any offloading errors [3]. This bug report is about guix pull failing to build the package cache on i686-linux (the package cache is one of the last things guix pull builds, it didn't have any trouble building guix-packages-base, guix-packages, guix-system, guix-home, guix-cli, etc.). > I don't think this is an issue with the patch, we should start > challenging berlin. I do think this is an issue with commit e8518c43 because --8<---cut here---start->8--- guix pull --commit=e8518c43 --system=i686-linux -p /tmp/guix --8<---cut here---end--->8--- fails to build the package cache whereas --8<---cut here---start->8--- guix pull --commit=75f9f944 --system=i686-linux -p /tmp/guix --8<---cut here---end--->8--- succeeds (75f9f944 being the parent commit of e8518c43). I even ran these with --substitute-urls=https://bordeaux.guix.gnu.org in a freshly downloaded instance of the 1.3.0 QEMU image [5] to rule out corrupted substitutes from berlin with the same result. > Cheers Regards, Diego > [1] http://ci.guix.gnu.org/build/517560/log/raw > [2] http://ci.guix.gnu.org/build/517546/log/raw > [3] http://ci.guix.gnu.org/eval/130956/log/raw > [4] > https://bordeaux.guix.gnu.org/build/abde7656-0ced-4621-ad89-9a6bf9517f18 [5] https://ftp.gnu.org/gnu/guix/guix-system-vm-image-1.3.0.x86_64-linux.qcow2
bug#54292: Commit e8518c43 breaks guix pull on i686
Hi Guix, Commit e8518c43 (gnu: Add stex) breaks guix pull, specifically the package cache hook, on i686-linux. I.e. the following command --8<---cut here---start->8--- guix pull --commit=e8518c43 --system=i686-linux -p /tmp/guix --8<---cut here---end--->8--- fails like this: --8<---cut here---start->8--- [...] building package cache... /builder for `/gnu/store/f1j059k0x7hpqmhwgyar6761c6jrw4iw-guix-package-cache.drv' failed to produce output path `/gnu/store/0z272l1izcm45ynwfzz5vvnnhg4ik1ij-guix-package-cache' build of /gnu/store/f1j059k0x7hpqmhwgyar6761c6jrw4iw-guix-package-cache.drv failed View build log at '/var/log/guix/drvs/f1/j059k0x7hpqmhwgyar6761c6jrw4iw-guix-package-cache.drv.gz'. cannot build derivation `/gnu/store/cm9wh5fv3a94cbpb839dhbf2wf31zg7r-profile.drv': 1 dependencies couldn't be built guix pull: error: build of `/gnu/store/cm9wh5fv3a94cbpb839dhbf2wf31zg7r-profile.drv' failed --8<---cut here---end--->8--- The build log looks like this: --8<---cut here---start->8--- (repl-version 0 1 1) Generating package cache for '/gnu/store/dzcm0fk5a41bwmhy74sv0v2bvmapx5qy-profile'... (exception wrong-type-arg (value "string-ref") (value "Wrong type argument in position ~A (expecting ~A): ~S") (value (1 "string" #f)) (value (#f))) --8<---cut here---end--->8--- This issue was introduced by commit e8518c43 and is still present on current master (commit 6c3c4f70). Regards, Diego
bug#52513: php build failure
Hi Mathieu,
Mathieu Othacehe writes:
> Hello,
>
> The php package test suite is failing this way on master:
>
> =
>
> =
> FAILED TEST SUMMARY
> -
> int openssl_x509_checkpurpose ( mixed $x509cert , int $purpose [, array
> $cainfo = array() [, string $untrustedfile ]] ) function
> [ext/openssl/tests/openssl_x509_checkpurpose_basic.phpt]
> =
>
> =
> WARNED TEST SUMMARY
> -
> FPM: Buffered worker output decorated log with multiple continuous messages
> (stdout/stderr mixed)
> [sapi/fpm/tests/log-bwd-multiple-msgs-stdout-stderr.phpt] (warn: XFAIL
> section but test passes)
> =
[...]
> Test suite failed, dumping logs.
> error: in phase 'check': uncaught exception:
> %exception #<&invoke-error program: "make" arguments: ("test" "-j" "32")
> exit-status: 2 term-signal: #f stop-signal: #f>
> phase `check' failed after 971.4 seconds
> command "make" "test" "-j" "32" failed with status 2
> builder for `/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv'
> failed with exit code 1
> @ build-failed /gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv - 1
> builder for `/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv'
> failed with exit code 1
> derivation '/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv'
> offloaded to '10.0.0.1' failed: build of
> `/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' failed
> build of /gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv failed
> View build log at
> '/var/log/guix/drvs/qv/gr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv.bz2'.
> guix build: error: build of
> `/gnu/store/qvgr41cvrh6b3m5bk5n93gcw0rk0kax5-php-7.4.26.drv' failed
>
> The openssl_x509_checkpurpose test seems to blame.
The test fails because two of the certificates it uses have expired on
11 December 2021. Upstream has already fixed it [1] but the change has
not made it into the 7.4.27 (!) release. We could apply their fix with
a patch or just disable the openssl_x509_checkpurpose test.
[...]
HTH,
Diego
[1]:
https://github.com/php/php-src/commit/98175fc7f1623873ceb2e9a017a319d19bfb3912
bug#48686: games: pioneer fails to start
Hi, Luis Felipe writes: > STEPS TO REPRODUCE > > 1. guix install pioneer > 2. run pioneer from a terminal > > > EXPECTED RESULT > > The game starts and I can play it. > > > UNEXPECTED RESULT > > The game starts, but fails while loading assets. It displays a message that > says: > > Error while loading Space Station data (check stdout/output.txt). [OK] [...] This has been fixed with commit 5be7870a8d4a0b27628e9eb6add61ddc5c05f186 on master. Thanks, Diego
bug#40406: python-matplotlib fails to build on i686-linux
Hey, Diego Nicola Barbato writes: [...] > Apparently there is nothing wrong with the slider. Instead matrix > multiplication, which is used under the hood for transformations, seems > to sometimes produce incorrect results on i686-linux. I have reported > this as a separate bug (https://debbugs.gnu.org/41665). I got this wrong: This issue isn't caused by the Numpy bug, since Matplotlib doesn't use Numpy for transformations. Both bugs are caused by the excess precision of the x87 FPU's floating point registers. I've attached a patch which makes sure that the C and C++ extensions are compiled with -ffloat-store. This doesn't get rid of all possible rounding errors but it's enough for the slider test to pass. [...] Regards, Diego >From 7c60615e29a1aab7922139183d191cc8cedd5c7f Mon Sep 17 00:00:00 2001 From: Diego Nicola Barbato Date: Mon, 8 Jun 2020 02:31:17 +0200 Subject: [PATCH] gnu: python-matplotlib: Fix rounding errors on x86 CPUs. Fixes <https://debbugs.gnu.org/40406>. Reported by Diego Nicola Barbato . * gnu/packages/python-xyz.scm (python-matplotlib)[arguments]: Set the environment variable CFLAGS to -ffloat-store. --- gnu/packages/python-xyz.scm | 5 + 1 file changed, 5 insertions(+) diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm index 94e63d1c74..f0b96c6fb0 100644 --- a/gnu/packages/python-xyz.scm +++ b/gnu/packages/python-xyz.scm @@ -81,6 +81,7 @@ ;;; Copyright © 2020 Josh Holland ;;; Copyright © 2020 Yuval Kogman ;;; Copyright © 2020 Michael Rohleder +;;; Copyright © 2020 Diego N. Barbato ;;; ;;; This file is part of GNU Guix. ;;; @@ -4744,6 +4745,10 @@ convert between colorspaces like sRGB, XYZ, CIEL*a*b*, CIECAM02, CAM02-UCS, etc. ;; has not effect. (setenv "LD_LIBRARY_PATH" (string-append cairo "/lib")) (setenv "HOME" (getcwd)) + ;; Fix rounding errors when using the x87 FPU. + ,@(if (string-prefix? "i686" (%current-system)) + '((setenv "CFLAGS" "-ffloat-store")) + '()) (call-with-output-file "setup.cfg" (lambda (port) (format port "[directories]~% -- 2.26.2
bug#41675: ant-bootstrap fails to build on i686-linux
Hey Guix, Since the recent core-updates merge (commit 4bdf418) ant-bootstrap fails to build on i686-linux. I've attached the build log. Regards, Diego snb6jmz4sd0l8rga6bhnzgzxy999ay-ant-bootstrap-1.8.4.drv.bz2 Description: ant-bootstrap-1.8.4.drv.bz2
bug#41665: python-numpy: incorrect results on i686-linux
Hi Guix, On i686-linux Numpy produces incorrect results for some matrix products. This minimal reproducer ... --8<---cut here---start->8--- python3 <8--- ... should return: --8<---cut here---start->8--- [0. 0. 1.] [0. 0. 1.] --8<---cut here---end--->8--- On x86_64-linux, armhf-linux, and aarch64-linux I get the correct result. On i686-linux I get this instead: --8<---cut here---start->8--- [ 0.e+00 -5.55111512e-17 1.e+00] [0. 0. 1.] --8<---cut here---end--->8--- I came across this bug while looking into https://debbugs.gnu.org/40406, for which it seems to be the underlying cause. I'm surprised this wasn't caught by Numpy's test suite. Regards, Diego
bug#40406: python-matplotlib fails to build on i686-linux
Hi,
Leo Famulari writes:
> On Fri, Apr 03, 2020 at 05:20:08PM +0200, Diego Nicola Barbato wrote:
>> The package python-matplotlib fails to build during the check phase on
>> i686-linux. The test failure appears to be deterministic:
I've taken a closer look at the failing test (on x86_64-linux, commit:
ebbf915) by keeping the build tree ...
--8<---cut here---start->8---
guix build --no-grafts -s i686-linux --keep-failed python-matplotlib
--8<---cut here---end--->8---
... and running python inside of it.
--8<---cut here---start->8---
cd /tmp/guix-build-python-matplotlib-3.1.2.drv-0/matplotlib-3.1.2/
. ../environment-variables
export PYTHONPATH="${PYTHONPATH}:build/lib.linux-i686-3.8"
python3
--8<---cut here---end--->8---
I retraced the steps of the failing test ...
--8<---cut here---start->8---
import matplotlib.pyplot as plt
import matplotlib.widgets as widgets
from numpy.testing import assert_allclose
fig, ax = plt.subplots()
slider = widgets.Slider(ax=ax, label='', valmin=0, valmax=24, valinit=12,
orientation='horizontal')
slider.set_val(10)
box = slider.poly.get_extents().transformed(ax.transAxes.inverted())
assert_allclose(box.bounds, [0, 0, 10/24, 1])
--8<---cut here---end--->8---
... and was able to reproduce the failing assertion ...
--8<---cut here---start->8---
AssertionError:
Not equal to tolerance rtol=1e-07, atol=0
Mismatch: 25%
Max absolute difference: 1.11022302e-16
Max relative difference: 2.66453526e-16
x: array([ 0.00e+00, -1.046255e-17, 4.17e-01, 1.00e+00])
y: array([0. , 0. , 0.416667, 1. ])
--8<---cut here---end--->8---
... , although the differing value wasn't exactly the same as the one
reported by the test. As expected, the assertion did not fail when I
followed the same steps on x86_64.
--8<---cut here---start->8---
guix environment --ad-hoc python python-matplotlib -- python3
--8<---cut here---end--->8---
A closer look at the intermediate results ...
--8<---cut here---start->8---
print(slider.poly.get_extents().bounds,
ax.transAxes.get_matrix(),
ax.transAxes.inverted().get_matrix(),
box.bounds,
sep='\n')
--8<---cut here---end--->8---
... revealed that only the values of box.bounds differ. The dimensions
of the slider are the same (as are the values of the transformation
matrices) on i686-linux ...
--8<---cut here---start->8---
(80.0, 52.8, 206.63, 369.57)
[[496.0. 80. ]
[ 0. 369.6 52.8]
[ 0.0.1. ]]
[[ 0.00201613 0. -0.16129032]
[ 0. 0.00270563 -0.14285714]
[ 0. 0. 1.]]
(0.0, -1.0462550964485118e-17, 0.4166, 1.0)
--8<---cut here---end--->8---
... and on x86_64-linux.
--8<---cut here---start->8---
(80.0, 52.8, 206.63, 369.57)
[[496.0. 80. ]
[ 0. 369.6 52.8]
[ 0.0.1. ]]
[[ 0.00201613 0. -0.16129032]
[ 0. 0.00270563 -0.14285714]
[ 0. 0. 1.]]
(0.0, 0.0, 0.41663, 1.0002)
--8<---cut here---end--->8---
Apparently there is nothing wrong with the slider. Instead matrix
multiplication, which is used under the hood for transformations, seems
to sometimes produce incorrect results on i686-linux. I have reported
this as a separate bug (https://debbugs.gnu.org/41665).
> I wonder if this scientific computing stuff should be tried on i686 at
> all. Should we limit it to contemporary architectures?
I was opposed to this at first (after all, if upstream supports Numpy on
i686, why shouldn't we?), but after seeing that even simple things like
matrix multiplication can produce incorrect results I'm in favour of
limiting it to contemporary architectures. What do others think?
Regards,
Diego
bug#41651: nm-applet fails: Settings schema 'org.gnome.nm-applet' is not installed
Hi, Pierre Neidhardt writes: > Guix commit e7b86a0d88760275afefa0c44a3c30602f80aac0 > > $ nm-applet > > (nm-applet:28022): GLib-GIO-ERROR **: 20:18:12.633: Settings schema > 'org.gnome.nm-applet' is not installed > trace/breakpoint trap > > It used to work on commit afc46f22672eb3218fbd1e567f85fc6367286461. I have the same problem (on EXWM as well). It looks like this was introduced by commit 4c29111232c44c84908922442abd1cd83ddc7686 (gnu: network-manager-applet: Update to 1.16.0.). The last known good commit is 9af90aafdfd8afd5fb7b5377ca5daf2215d38d7a (nm-applet doesn't build between those two commits). I was able to work around this by installing libnma in my user profile. Regards, Diego
bug#41116: Guix deploy fails with new version of Herd
Hey,
Ludovic Courtès writes:
> Hello Alex & Marius,
>
> Marius Bakke skribis:
>
>> Alex Sassmannshausen via Bug reports for GNU Guix
>> writes:
>>
>>> Hello,
>>>
>>> I maintain a number of servers using Guix deploy. It seems that the
>>> recent upgrade to Herd in Guix, and specifically commit
>>> 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec might have introduced a bug.
>>>
>>> From my testing, guix deploy currently consistently fails with:
>>> -8<->8---
>>> ice-9/boot-9.scm:1667:16: In procedure raise-exception:
>>> ERROR:
>>> 1. &inferior-exception:
>>> arguments: (srfi-34 #>> &action-exception-error [service: root action: eval key:
>>> keyword-argument-error args: ("#>> shepherd/service.scm:903:4 (command #:key user group directory
>>> environment-variables pid-file pid-file-timeout log-file) | (program .
>>> program-args)>" "Unrecognized keyword" () (#:file-creation-mask))]
>>> 7eff2bd7be00>>)
>>> inferior: #f
>>> stack: ()
>>> -8<->8---
>>>
>>> A workaround is to build the system configuration locally on the target
>>> server, then to reconfigure. It will still error at the same place, but
>>> at this point, after restarting the server, the new version of Herd will
>>> be running and both deploy and reconfigure will work.
>>>
>>> I don't know what a good solution to this could be, but it may be
>>> something we need to consider in future development of Herd.
>>
>> This issue has been reported by a number of users on IRC. I think the
>> problem is that the the #:file-creation-mask keyword requires support
>> from the running Shepherd, which may not have it yet. I think we should
>> revert commit 4c0cc7bed3de2c0e2d3a6e95b88693941e839eec until we find a
>> smooth upgrade path. Can you try it and push if that fixes guix deploy?
>
> I’ve reverted the patch in 5aa4d2dcf2f4f8786358feb45338893ed08a4cd9.
>
> Diego: I guess we can reinstate the patch “later”, once Shepherd 0.8 can
> be considered widespread.
I'm sorry I broke reconfigure and deploy. I didn't consider testing
upgrading from before Shepherd 0.8 to after my change and I didn't even
think of deploy. Going forth I'll leave messing with core functionality
to the pros.
> More importantly, we should handle service reload failures more
> gracefully, as proposed in ,
> for both ‘reconfigure’ and ‘deploy’.
Regards,
Diego
bug#41051: [guix-1.1.0] guix system failed
Hi, wensheng xie writes: > Hi, Marius: > > The problem is not reproduced after I did another 'guix pull'. I attached the > information: > > 1. > root@guix ~# guix describe > Generation 4 May 04 2020 06:21:35 (current) > guix c563f88 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: c563f8887db23241922fabf62a4da5d1526a644f > > 2. config.scm is attached. > > -- > From: Marius Bakke > Sent: Sunday, May 3, 2020 11:16 PM > To: wensheng xie; 41...@debbugs.gnu.org > Subject: Re: bug#41051: [guix-1.1.0] guix system failed > > Thanks for the report! > > wensheng xie writes: > >> The error: >> >> root@guix ~# guix system reconfigure /etc/config.scm >> The following derivation will be built: >>/gnu/store/g26kkrfd49y5wcz57x0xgkh97w997kmb-grub.cfg.drv >> building /gnu/store/g26kkrfd49y5wcz57x0xgkh97w997kmb-grub.cfg.drv... >> /gnu/store/2lnjrv5388727sw45jhrrsyf0140nrd2-system >> /gnu/store/gsxap47dgsjs6zvdim42j5lal5rfj10w-grub.cfg >> >> activating system... >> making '/gnu/store/2lnjrv5388727sw45jhrrsyf0140nrd2-system' the current >> system... >> setting up setuid programs in '/run/setuid-programs'... >> populating /etc from /gnu/store/hzhhbayyfxjqghxklawy8r8a1i8ws7pg-etc... >> The following derivation will be built: >>/gnu/store/6wy32ybajjrdn1nydvp1i0iai6x77jqc-install-bootloader.scm.drv >> building >> /gnu/store/6wy32ybajjrdn1nydvp1i0iai6x77jqc-install-bootloader.scm.drv... >> guix system: bootloader successfully installed on '/dev/sda' >> guix system: error: exception caught while executing 'eval' on service >> 'root': >> Unrecognized keyword: #:file-creation-mask > > Can you post the output of 'guix describe' and the config.scm you are > using? I can reproduce the error when upgrading (i.e. guix pull and guix system reconfigure) from commit 74c7f36 to commit aea6ab2. I believe this will always happen when upgrading from a commit before e3358a8 (gnu: shepherd: Update to 0.8.0.) to any commit starting from 4c0cc7b (services: syslog: Simplify 'start' method.). The latter commit changes the syslog-service-type to use a feature introduced in version 0.8.0 of the Shepherd (the #:file-creation-mask parameter of make-forkexec-constructor) so when Guix tries to load the new service definition the current Shepherd (0.7.0) doesn't recognise the new parameter and we get an error. The error is harmless since this happens after switching the system generation and installing the bootloader. But we should probably print a hint or warning, that some service definitions couldn't be loaded and that it might be necessary to reboot, instead of an error so that it doesn't look like reconfigure failed. Regards, Diego
bug#40405: System log files are world readable
Hi, Ludovic Courtès writes: > Hello, > > Diego Nicola Barbato skribis: > >> Great! Now we can simplify the 'start' method of >> 'syslogd-service-type'. > > Oh right, do you want to take care of it? I already did: https://debbugs.gnu.org/40937 [...] Regards, Diego
bug#39406: emacs-telega on 32bit - "Emacs with wide ints (--with-wide-int) is required"
Hi, This bug has been fixed in a663b7040c3c7ed12d4f673c4ac090ad8d9b8e20. See https://debbugs.gnu.org/39412 for more details. Please note that for emacs-telega to work on 32-bit systems (i686, armhf) it needs to be installed alongside emacs-wide-int instead of emacs. Regards, Diego
bug#40405: System log files are world readable
Hi,
Ludovic Courtès writes:
> Hi,
>
> Ludovic Courtès skribis:
>
>> Diego Nicola Barbato skribis:
>>
>>>>From 43c9ded791ce5b480504ce3528ee34578168f90e Mon Sep 17 00:00:00 2001
>>> From: Diego Nicola Barbato
>>> Date: Tue, 7 Apr 2020 13:58:28 +0200
>>> Subject: [PATCH 1/2] service: Create log files as non-world-readable.
>>>
>>> * modules/shepherd/service.scm (exec-command): Create log-file with file
>>> permissions #o640.
>>
>> [...]
>>
>>>>From e491436967a912e6e7372f582b3bf5c9784b8209 Mon Sep 17 00:00:00 2001
>>> From: Diego Nicola Barbato
>>> Date: Tue, 7 Apr 2020 13:38:47 +0200
>>> Subject: [PATCH 2/2] service: Add #:file-creation-mask to
>>> 'make-forkexec-constructor'.
>>>
>>> * modules/shepherd/service.scm (exec-command): Add #:file-creation-mask
>>> parameter and honor it.
>>> (fork+exec-command): Add #:file-creation-mask parameter and pass it to
>>> exec-command.
>>> (make-forkexec-constructor): Add #:file-creation-mask parameter and pass
>>> it
>>> to fork+exec-command.
>>> * doc/shepherd.texi (Service De- and Constructors): Adjust accordingly.
>>
>> I went ahead and pushed these two patches.
>
> These patches are in Shepherd 0.8.0, which was pushed in Guix master
> commit e3358a831e7d5d9e8dc614340e49ea5aeb11a7ff, so we’re done!
Great! Now we can simplify the 'start' method of
'syslogd-service-type'.
I did eventually write a test script, which I've attached in case we
want to add it to the Shepherd. I'm sorry it took so long that I missed
the new Shepherd release.
Regards,
Diego
>From 2e7a0795b3a7080376238ab604c50d2c180f8730 Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato
Date: Mon, 27 Apr 2020 16:57:36 +0200
Subject: [PATCH] tests: Test #:file-creation-mask option of
'make-forkexec-constructor'.
* tests/file-creation-mask.sh: New file.
---
tests/file-creation-mask.sh | 79 +
1 file changed, 79 insertions(+)
create mode 100644 tests/file-creation-mask.sh
diff --git a/tests/file-creation-mask.sh b/tests/file-creation-mask.sh
new file mode 100644
index 000..9f5f10a
--- /dev/null
+++ b/tests/file-creation-mask.sh
@@ -0,0 +1,79 @@
+# GNU Shepherd --- Test the #:file-creation-mask option of 'make-forkexec-constructor'.
+# Copyright © 2020 Diego N. Barbato
+#
+# This file is part of the GNU Shepherd.
+#
+# The GNU Shepherd is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or (at
+# your option) any later version.
+#
+# The GNU Shepherd is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with the GNU Shepherd. If not, see <http://www.gnu.org/licenses/>.
+
+shepherd --version
+herd --version
+
+socket="t-socket-$$"
+conf="t-conf-$$"
+log="t-log-$$"
+pid="t-pid-$$"
+service_log="t-service-log-$$"
+service_new_file="t-service-new-file-$$"
+
+herd="herd -s $socket"
+
+trap "cat $log || true;
+ rm -f $socket $conf $log $service_log $service_new_file;
+ test -f $pid && kill \`cat $pid\` || true; rm -f $pid" EXIT
+
+function wait_for_file
+{
+i=0
+while ! test -f "$1" && test $i -lt 20
+do
+ sleep 0.3
+ i=`expr $i + 1`
+done
+test -f "$1"
+}
+
+cat > "$conf"<
+ #:provides '(test)
+ #:start (make-forkexec-constructor %command
+ #:log-file "$PWD/$service_log"
+ ;; Set the umask such that file
+ ;; permissions are #o600.
+ #:file-creation-mask #o177)
+ #:stop (make-kill-destructor)
+ #:respawn? #f))
+EOF
+
+rm -f "$pid"
+shepherd -I -s "$socket" -c "$conf" -l "$log" --pid="$pid" &
+
+# Wait till it's ready.
+wait_for_file "$pid"
+
+# Start the service.
+$herd start test
+
+# Make sure the log file is created with the right permissions independently
+# of the value of #:file-creation-mask.
+wait_for_file "$service_log"
+test `stat -c %a "$service_log"` -eq 640
+
+# Make sure the service creates files with the right permissions as determined
+# by the value of #:file-creation-mask.
+wait_for_file "$service_new_file"
+test `stat -c %a "$service_new_file"` -eq 600
--
2.26.0
bug#40544: Pulseaudio is not looking for user configuration
Hi,
Ludovic Courtès writes:
> Hi Diego,
>
> Diego Nicola Barbato skribis:
>
>> pkill9 writes:
>>
>>> Pulseaudio doesn't read my user configuration files according to strace.
>>>
>>> Attached is the output of `strace -o /tmp/log.log pulseaudio` - It only
>>> looks for /etc/pulse/daemon.conf.
>>
>> That's a known [0] (but AFAIK undocumented) side effect of the
>> PulseAudio service, which was added to %desktop-services in January [1].
>> If you want PulseAudio to read your user configuration files you'll have
>> to remove that service from your system services or unset PULSE_CONFIG
>> and PULSE_CLIENT_CONFIG in ~/.profile [2].
>
> It would be good to document that, right below
> ‘pulseaudio-service-type’. Would you like to give it a try, Diego?
I've attached a patch, which adds a warning to the documentation.
> Or alternately, is there a way we can arrange so that the user’s config
> takes precedence over /etc/pulse?
We can't configure PulseAudio with "--sysconfdir=/etc" because it would
break without the service (e.g. on foreign distributions).[0]
We could patch PulseAudio to make the sysconfdir configurable at runtime
using an environment variable. The service could set this environment
variable to /etc instead of setting ‘PULSE_CONFIG’ and
‘PULSE_CLIENT_CONFIG’. That way the user's config would take precedence
over /etc/pulse (PulseAudio's normal behaviour). Without the service
(and with the environment variable unset) it would fall back to the
sysconfdir configured at build time so it wouldn't break on foreign
distributions. Although I doubt that the slight improvement in user
experience would justify the increased maintenance burden.
Regards,
Diego
[0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38172#14
>From a33a10102f555454d9025b0693edf8d539f6a7af Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato
Date: Sat, 25 Apr 2020 11:32:07 +0200
Subject: [PATCH] doc: Mention that PulseAudio service overrides user
configuration.
* doc/guix.texi (Sound Services): Add a warning that 'pulseaudio-service-type'
overrides per-user configuration files in '~/.config/pulse'.
---
doc/guix.texi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index 19094c4b70..683c40b476 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -63,7 +63,7 @@ Copyright @copyright{} 2018, 2019 Florian Pelz@*
Copyright @copyright{} 2018 Laura Lazzati@*
Copyright @copyright{} 2018 Alex Vong@*
Copyright @copyright{} 2019 Josh Holland@*
-Copyright @copyright{} 2019 Diego Nicola Barbato@*
+Copyright @copyright{} 2019, 2020 Diego Nicola Barbato@*
Copyright @copyright{} 2019 Ivan Petkov@*
Copyright @copyright{} 2019 Jakob L. Kreuze@*
Copyright @copyright{} 2019 Kyle Andrews@*
@@ -16288,6 +16288,13 @@ This is the type for the @uref{https://www.pulseaudio.org/, PulseAudio}
sound server. It exists to allow system overrides of the default settings
via @code{pulseaudio-configuration}, see below.
+@quotation Warning
+This service overrides per-user configuration files. If you want
+PulseAudio to honor configuraton files in @file{~/.config/pulse} you
+have to unset the environment variables @code{PULSE_CONFIG} and
+@code{PULSE_CLIENTCONFIG} in your @file{~/.bash_profile}.
+@end quotation
+
@quotation Warning
This service on its own does not ensure, that the @code{pulseaudio} package
exists on your machine. It merely adds configuration files for it, as
--
2.26.0
bug#40544: Pulseaudio is not looking for user configuration
Hey, pkill9 writes: > Pulseaudio doesn't read my user configuration files according to strace. > > Attached is the output of `strace -o /tmp/log.log pulseaudio` - It only > looks for /etc/pulse/daemon.conf. That's a known [0] (but AFAIK undocumented) side effect of the PulseAudio service, which was added to %desktop-services in January [1]. If you want PulseAudio to read your user configuration files you'll have to remove that service from your system services or unset PULSE_CONFIG and PULSE_CLIENT_CONFIG in ~/.profile [2]. Regards, Diego [0]: https://lists.gnu.org/archive/html/guix-patches/2020-01/msg00388.html [1]: https://git.savannah.gnu.org/cgit/guix.git/commit/?id=71e33e32fcedbd0aaafda4fd548fb8443064253c [2]: https://lists.gnu.org/archive/html/guix-patches/2020-01/msg00408.html
bug#40408: emacs-telega: VoIP doesn't work
Hi,
Leo Famulari writes:
> On Fri, Apr 03, 2020 at 06:12:16PM +0200, Diego Nicola Barbato wrote:
>> The following error messages in .telega/telega-voip.log seem relevant:
>>
>> --8<---cut here---start->8---
>> 04-01 20:04:04 E: Error loading libpulse: (null)
>> 04-01 20:04:04 E: Error loading libasound: (null)
>> 04-01 20:04:04 E: Error loading libasound: (null)
>> 04-01 20:04:04 E: Error initializing audio playback
>> --8<---cut here---end--->8---
>
> I'd guess those libraries should be dependencies of this package. I
> would move it to the telephony module as well.
Turns out the libraries are dependencies of libtgvoip. It tries to
dlopen them, but doesn't find them. I've attached a patch to fix that.
Unfortunately VoIP still doesn't work in Telega (it still fails in the
same way as before, except that there are no more error messages in
.telega/telega-voip.log). It looks like that's a separate, unrelated
issue.
Regards,
Diego
>From f63cf832869bee91f3f6e87c076bd1e39d32c285 Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato
Date: Sat, 4 Apr 2020 19:36:31 +0200
Subject: [PATCH] gnu: libtgvoip: Fix loading of shared libraries.
Fixes <https://debbugs.gnu.org/40408>.
* gnu/packages/telephony.scm (libtgvoip)[arguments]<#:phases>[patch-dlopen]:
New phase.
---
gnu/packages/telephony.scm | 17 +
1 file changed, 17 insertions(+)
diff --git a/gnu/packages/telephony.scm b/gnu/packages/telephony.scm
index f64cdd3fb2..f73efb0deb 100644
--- a/gnu/packages/telephony.scm
+++ b/gnu/packages/telephony.scm
@@ -1046,6 +1046,23 @@ This package provides the Jami client for the GNOME desktop.")
("libopusenc" ,libopusenc)
("openssl" ,openssl)
("pulseaudio" ,pulseaudio)))
+(arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ ;; libtgvoip wants to dlopen libpulse and libasound, so tell it where
+ ;; they are.
+ (add-after 'unpack 'patch-dlopen
+ (lambda* (#:key inputs #:allow-other-keys)
+ (substitute* "os/linux/AudioPulse.cpp"
+ (("libpulse\\.so")
+(string-append (assoc-ref inputs "pulseaudio")
+ "/lib/libpulse.so")))
+ (substitute* '("os/linux/AudioInputALSA.cpp"
+"os/linux/AudioOutputALSA.cpp")
+ (("libasound\\.so")
+(string-append (assoc-ref inputs "alsa-lib")
+ "/lib/libasound.so")))
+ #t)
(synopsis "VoIP library for Telegram clients")
(description "A collection of libraries and header files for implementing
telephony functionality into custom Telegram clients.")
--
2.26.0
bug#40405: System log files are world readable
Hey,
Ludovic Courtès writes:
> Hi,
>
> Diego Nicola Barbato skribis:
>
>> On Guix System the log files (in /var/log) generated by syslogd are
>> currently (commit 151f3d4) world readable. They should probably only be
>> readable by root (for the same reason that dmesg can only be run by
>> root).
>>
>> It isn't possible to set the umask with fork-exec-constructor, is it?
>> Otherwise that might have been a simple solution.
>
> That would be a nice solution to implement in the Shepherd. If you feel
> like giving it a try, that would be great!
I've attached two patches for the Shepherd. The first one makes sure
that 'exec-command' creates log files with mode #o640 (I thought about
making it a parameter instead of hard coding it, but I doubt it would be
very useful). The second one makes it possible to set the umask with
'exec-command', 'fork+exec-command', and 'make-forkexec-constructor'. I
wasn't quite sure how to avoid a collision with the procedure umask
(would `((@ (guile) umask) umask)' have been ok?) so I named the
parameter file-creation-mask.
I haven't tested the changes. What would be a straight forward way to
do that on Guix? Looking at the documentation it doesn't seem possible
to swap out the shepherd package of the %shepherd-root-service with
'modify-services'.
[...]
Regards,
Diego
>From 43c9ded791ce5b480504ce3528ee34578168f90e Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato
Date: Tue, 7 Apr 2020 13:58:28 +0200
Subject: [PATCH 1/2] service: Create log files as non-world-readable.
* modules/shepherd/service.scm (exec-command): Create log-file with file
permissions #o640.
---
modules/shepherd/service.scm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/modules/shepherd/service.scm b/modules/shepherd/service.scm
index fc82cc4..9a4a5d9 100644
--- a/modules/shepherd/service.scm
+++ b/modules/shepherd/service.scm
@@ -808,7 +808,7 @@ false."
;; Redirect stout and stderr to use LOG-FILE.
(catch-system-error (close-fdes 1))
(catch-system-error (close-fdes 2))
- (dup2 (open-fdes log-file (logior O_CREAT O_WRONLY O_APPEND)) 1)
+ (dup2 (open-fdes log-file (logior O_CREAT O_WRONLY O_APPEND) #o640) 1)
(dup2 1 2))
(lambda (key . args)
(format (current-error-port)
--
2.26.0
>From e491436967a912e6e7372f582b3bf5c9784b8209 Mon Sep 17 00:00:00 2001
From: Diego Nicola Barbato
Date: Tue, 7 Apr 2020 13:38:47 +0200
Subject: [PATCH 2/2] service: Add #:file-creation-mask to
'make-forkexec-constructor'.
* modules/shepherd/service.scm (exec-command): Add #:file-creation-mask
parameter and honor it.
(fork+exec-command): Add #:file-creation-mask parameter and pass it to
exec-command.
(make-forkexec-constructor): Add #:file-creation-mask parameter and pass it
to fork+exec-command.
* doc/shepherd.texi (Service De- and Constructors): Adjust accordingly.
---
doc/shepherd.texi| 9 +++--
modules/shepherd/service.scm | 22 --
2 files changed, 23 insertions(+), 8 deletions(-)
diff --git a/doc/shepherd.texi b/doc/shepherd.texi
index 3e61f5d..659eb82 100644
--- a/doc/shepherd.texi
+++ b/doc/shepherd.texi
@@ -896,10 +896,12 @@ execution of the @var{command} was successful, @code{#t} if not.
[#:pid-file #f] [#:pid-file-timeout %pid-file-timeout] @
[#:log-file #f] @
[#:directory (default-service-directory)] @
+ [#:file-creation-mask #f] @
[#:environment-variables (default-environment-variables)]
Return a procedure that forks a child process, closes all file
descriptors except the standard output and standard error descriptors, sets
-the current directory to @var{directory}, changes the environment to
+the current directory to @var{directory}, sets the umask to
+@var{file-creation-mask} unless it is @code{#f}, changes the environment to
@var{environment-variables} (using the @code{environ} procedure), sets the
current user to @var{user} and the current group to @var{group} unless they
are @code{#f}, and executes @var{command} (a list of strings.) The result of
@@ -935,13 +937,16 @@ procedures.
[#:group #f] @
[#:log-file #f] @
[#:directory (default-service-directory)] @
+ [#:file-creation-mask #f] @
[#:environment-variables (default-environment-variables)]
@deffnx {procedure} fork+exec-command @var{command} @
[#:user #f] @
[#:group #f] @
[#:directory (default-service-directory)] @
+ [#:file-creation-mask #f] @
[#:environment-variables (default-environment-variables)]
-Run @var{command} as the current process from @var{directory}, and with
+Run @var{command} as the current process from @var{directory}, with
+@var{file-creation-mask} if it's true, and with
@var{environment-variables} (a list of strings like @code{"PATH=
bug#35324: SDDM shows black screen instead of login prompt
Hi Marius, Marius Bakke writes: > Diego Nicola Barbato writes: > >> Hello Guix, >> >> As already mentioned on IRC SDDM does not work for me. >> >> This is what I tried: >> >> $ qemu-system-x86_64 -enable-kvm -snapshot -m 6G $(guix system vm-image >> --image-size=24G config.scm) >> >> After booting I get a black screen instead of a greeter. I have >> attached the config.scm, Xorg.log, and sddm.log. > > I believe this issue has been fixed, please reopen if you still > experience problems. Thanks! If I try what I described in my original bug report I still (commit f2d97d5) get a black screen. If I run $(guix system vm config.scm) -m 6G -enable-kvm instead it works as expected (I get a login screen). So it looks like some runtime dependency doesn't make it into the vm-image. This issue seems limited to this special case (no one else has since complained about it) so I'll leave this closed. Regards, Diego
bug#40408: emacs-telega: VoIP doesn't work
Hey Guix, In Telega neither initiating nor accepting a voice call works: If I call someone (who has the Telegram App) they can accept the call, but the app gets stuck connecting. If either I or the other party hang up I get a bunch of assertion failures. If the other party tries to call me I can accept the call, but again their app gets stuck connecting. Hanging up has the same effect as before. Both actions leave Telega in a broken state (e.g. assertion failures when I try to enter a chat) and it has to be restarted. The following error messages in .telega/telega-voip.log seem relevant: --8<---cut here---start->8--- 04-01 20:04:04 E: Error loading libpulse: (null) 04-01 20:04:04 E: Error loading libasound: (null) 04-01 20:04:04 E: Error loading libasound: (null) 04-01 20:04:04 E: Error initializing audio playback --8<---cut here---end--->8--- I'm currently on commit 151f3d4. Regards, Diego
bug#40406: python-matplotlib fails to build on i686-linux
Hi Guix, The package python-matplotlib fails to build during the check phase on i686-linux. The test failure appears to be deterministic: --8<---cut here---start->8--- === FAILURES === ___ test_slider_horizontal_vertical def test_slider_horizontal_vertical(): fig, ax = plt.subplots() slider = widgets.Slider(ax=ax, label='', valmin=0, valmax=24, valinit=12, orientation='horizontal') slider.set_val(10) assert slider.val == 10 # check the dimension of the slider patch in axes units box = slider.poly.get_extents().transformed(ax.transAxes.inverted()) > assert_allclose(box.bounds, [0, 0, 10/24, 1]) E AssertionError: E Not equal to tolerance rtol=1e-07, atol=0 E E Mismatch: 25% E Max absolute difference: 1.11022302e-16 E Max relative difference: 2.66453526e-16 Ex: array([ 0.00e+00, -2.310706e-18, 4.17e-01, 1.00e+00]) Ey: array([0. , 0. , 0.416667, 1. ]) /gnu/store/8g8yfikj63wf0y3hwvpk00hqj5wpfs7v-python-matplotlib-3.1.2/lib/python3.7/site-packages/matplotlib/tests/test_widgets.py:333: AssertionError --8<---cut here---end--->8--- Im currently on commit 151f3d4. Regards, Diego
bug#40405: System log files are world readable
Diego Nicola Barbato writes: > Hey Guix, > > On Guix System the log files (in /var/log) generated by syslogd are > currently (commit 151f3d4) world readable. They should probably only be > readable by root (for the same reason that dmesg can only be run by > root). > > It isn't possible to set the umask with fork-exec-constructor, is it? ^ That should be 'make-forkexec-constructor'. Sorry for the noise. > Otherwise that might have been a simple solution. > > Regards, > > Diego
bug#40405: System log files are world readable
Hey Guix, On Guix System the log files (in /var/log) generated by syslogd are currently (commit 151f3d4) world readable. They should probably only be readable by root (for the same reason that dmesg can only be run by root). It isn't possible to set the umask with fork-exec-constructor, is it? Otherwise that might have been a simple solution. Regards, Diego
bug#38990: Update of tdlib to 1.5.4 breaks emacs-telega
Hi Guix, I can no longer reproduce this bug (I'm now on commit 5c3d77c). I believe it was fixed with commit cfd0fd9. Regards, Diego
bug#38990: Update of tdlib to 1.5.4 breaks emacs-telega
Hi Guix,
emacs-telega doesn't work with version 1.5.4 of tdlib (last known good
commit: df23842; first known bad commit: 70848cd).
After starting telega (M-x telega RET) the *Telega Root* buffer looks
like this:
--8<---cut here---start->8---
Status: Ready Fetching chats..
[2:All ] [0:Secrets ] [0:Bots ]
[0:Groups] [2:Private ] [0:Channels ]
(all)-
{Alice } Last message from Alice 05.01.20
{Bob } Last message from Bob 04.01.20
--8<---cut here---end--->8---
The dot animation after "Fetching chats" keeps looping and the following
error message is displayed (2 times, according to the *Messages* buffer)
in the minibuffer:
--8<---cut here---start->8---
error in process filter: Wrong type argument: stringp, nil
--8<---cut here---end--->8---
Deleting the ~/.telega directory and logging in again results in the
same error.
The state in ~/.telega seems to get corrupted too: Trying to run the
known good telega from before the tdlib update afterwards fails because
the server seems to crash.
Regards,
Diego
bug#38944: libtgvoip fails to build on i686-linux
Hi Guix, The package libtgvoip (introduced with commit 494135d) fails to build on i686-linux [0]. Since this appears to be related to SSE2 these two Debian patches [1] [2], which disable SSE2 on i386 (the first patch does something unrelated, but it's required for the second one to apply), should fix it. Regards, Diego [0]: https://ci.guix.gnu.org/log/drp47myv1fv6a3scd2rz177yp5b89dp0-libtgvoip-2.4.2 [1]: https://sources.debian.org/patches/libtgvoip/2.4.4-2/Fix-WebRTC-for-non-Linux.patch/ [2]: https://sources.debian.org/patches/libtgvoip/2.4.4-2/Disable-SSE2.patch/
bug#38943: libtgvoip fails to build on armhf-linux
Hi Guix, The package libtgvoip (introduced with commit 494135d) fails to build on armhf-linux [0]. This bug appears to have been fixed upstream [1]. Regards, Diego [0]: https://ci.guix.gnu.org/log/q4j5kzz25j2knf0vhm8i0bd3g14anv8m-libtgvoip-2.4.2 [1]: https://github.com/zevlg/libtgvoip/commit/5efda7ac165ece0aee894ed8dd88f12a7ca0582d
bug#38533: emacs-auctex breaks url package
Hi Maxim, Maxim Cournoyer writes: > Hello Diego, > > Diego Nicola Barbato writes: > >> Hi Guix, >> >> AUCTeX breaks Emacs' bult-in url package. This bug appears to have been >> introduced with commit 3ffdd00 and can be reproduced as follows: >> >> 1) Install ‘emacs’ and ‘emacs-auctex’. >> 2) Start Emacs and do M-: (require 'url), which will produce the >>following backtrace: >> >> Debugger entered--Lisp error: (void-function TeX-add-style-hook) >> (TeX-add-style-hook "url" #f(compiled-function () #) >> LaTeX-dialect) >> require(url) >> eval((require (quote url)) nil) >> eval-expression((require (quote url)) nil nil 127) >> funcall-interactively(eval-expression (require (quote url)) nil nil 127) >> call-interactively(eval-expression nil nil) >> command-execute(eval-expression) >> >> It looks like Emacs tries to load the file >> $GUIX_PROFILE/share/emacs/site-lisp/style/url.elc, which is provided by >> ‘emacs-auctex’, instead of >> $GUIX_PROFILE/share/emacs/26.3/lisp/url/url.elc, which is provided by >> Emacs itself. >> >> Regards, >> >> Diego > > This was caused by Emacs site-lisp/subdirs.el file, which when found in > a profile's union was causing Emacs to *recursively* add everything > under site-lisp to the load-path. > > Fixed with commit a7a492899a. Wow, that was fast! > Thank you for the report! Thank you for fixing this (and the other Emacs related bugs I've reported)! Regards, Diego
bug#38533: emacs-auctex breaks url package
Hi Guix, AUCTeX breaks Emacs' bult-in url package. This bug appears to have been introduced with commit 3ffdd00 and can be reproduced as follows: 1) Install ‘emacs’ and ‘emacs-auctex’. 2) Start Emacs and do M-: (require 'url), which will produce the following backtrace: --8<---cut here---start->8--- Debugger entered--Lisp error: (void-function TeX-add-style-hook) (TeX-add-style-hook "url" #f(compiled-function () #) LaTeX-dialect) require(url) eval((require (quote url)) nil) eval-expression((require (quote url)) nil nil 127) funcall-interactively(eval-expression (require (quote url)) nil nil 127) call-interactively(eval-expression nil nil) command-execute(eval-expression) --8<---cut here---end--->8--- It looks like Emacs tries to load the file $GUIX_PROFILE/share/emacs/site-lisp/style/url.elc, which is provided by ‘emacs-auctex’, instead of $GUIX_PROFILE/share/emacs/26.3/lisp/url/url.elc, which is provided by Emacs itself. Regards, Diego
bug#38479: Org Mode is borked
Hi Guix, Our Org Mode package (emacs-org) seems to be broken in a funny way. Here's how to reproduce this bug (on commit dac7928): 1) Install ‘emacs’ and ‘emacs-org’. 2) Start Emacs and work around https://debbugs.gnu.org/38399 by adding the directory containing org to the front of ‘load-path’: --8<---cut here---start->8--- (push "/path/to/org-9.2.6" load-path) --8<---cut here---end--->8--- 3) Open a new org file: --8<---cut here---start->8--- C-x C-f foo.org RET --8<---cut here---end--->8--- 4) Enter the following text into the buffer: --8<---cut here---start->8--- #+STARTUP: indent --8<---cut here---end--->8--- 5) Verify you're running Org Mode version 9.2.6 by running: --8<---cut here---start->8--- M-x org-version RET --8<---cut here---end--->8--- 6) Here comes the fun part: Hit C-c C-c. This will produce the following error message: --8<---cut here---start->8--- Symbol’s function definition is void: org-outline-overlay-data --8<---cut here---end--->8--- 7) Now reload Org from source (instead of the .elc files): --8<---cut here---start->8--- C-u C-c C-x ! --8<---cut here---end--->8--- 6) Repeat step 6. This time it succeeds! --8<---cut here---start->8--- Local setup has been refreshed --8<---cut here---end--->8--- The function ‘org-outline-overlay-data’ isn't defined anywhere in the org-9.2.6 source, but it is defined in the org bundled with Emacs. Because of this I suspect that the new emacs-build-system generates a weird chimera containing parts of both org-9.2.6 and org-9.1.9. To my untrained eye this looks like it’s probably a consequence of the aforementioned bug #38399. So I'd expect this issue to disappear as soon as that one is fixed. Regards, Diego
bug#38399: Recent $EMACSLOADPATH changes break emacs-org
Hello Maxim, Maxim Cournoyer writes: [...] >> It stands to reason that the elisp libraries provided by Emacs itself >> shouldn’t be in EMACSLOADPATH in the first place as they are already in >> ‘load-path’ to which the directories in EMACSLOADPATH are prepended (as >> described in the Emacs manual). > > That's not true; when using EMACSLOADPATH the Emacs' bundled libraries > must be included explicitly, or an empty item be present (which means, > an extra ':' present). > > See (elisp)Library Search: > > An empty element in the value of the environment variable, > whether trailing (as in the above example), leading, or embedded, is > replaced by the default value of ‘load-path’ as determined by the > standard initialization procedure. If there are no such empty > elements, then ‘EMACSLOADPATH’ specifies the entire ‘load-path’. > You must include either an empty element, or the explicit path to > the directory containing the standard Lisp files, else Emacs will > not function. Thanks for the clarification! And sorry for the noise, I should have read it more closely. Regards, Diego
bug#38399: Recent $EMACSLOADPATH changes break emacs-org
Hi Guix, Since the recent changes to the way Guix handles Emacs packages Emacs loads the wrong ‘org’ (the one bundled with Emacs instead of the one provided by the ‘emacs-org’ package installed with Guix). This happens because in EMACSLOADPATH the directory containing the bundled ‘org’ precedes the directory containing the ‘org’ provided by ‘emacs-org’. It stands to reason that the elisp libraries provided by Emacs itself shouldn’t be in EMACSLOADPATH in the first place as they are already in ‘load-path’ to which the directories in EMACSLOADPATH are prepended (as described in the Emacs manual). I’m currently on commit 116787d. Regards, Diego
bug#38135: Mate: missing gio-launch-desktop
Hi Guix, Launching a program from the start menu of the Mate desktop (as provided by the ‘mate-desktop-service-type’) currently (commit: 41ee209) fails. The error message complains about a missing ‘gio-launch-desktop’ (found in the “bin” output of ‘glib’). This can be worked around by adding ‘(list glib "bin")’ to the list of global packages in the ‘operating-system’ configuration. Regards, Diego
bug#37940: endless "try upgrading both" cycles
Hello Ludo, Ludovic Courtès writes: [...] > Now, it doesn’t sound right that ‘util-linux’ is propagated from glib > and from poppler…? Glib propagates 'util-linux' since it was updated to 2.58.1 (and poppler propagates glib). This isn't the first time it's caused trouble [0]. Marius has proposed a patch to fix it, which is intended for 'core-updates' (It hasn't been pushed yet AFAIK). Regards, Diego [0]: http://issues.guix.gnu.org/issue/37732
bug#37732: mps-youtube propagates util-linux
Hello Marius, Marius Bakke writes: [...] > Diego: one work-around you can try in the meantime is to create a > ~/setuid-programs, add it first on PATH, and symlink the required > binaries in there. Sorry for the inconvenience! No worries. I have simply removed 'mps-youtube' from my profile and use it with 'guix environment --ad-hoc mps-youtube -- mpsyt' instead. The difficult part was finding out which package propagated 'util-linux'. I used 'emacs-guix' and lucky guesses to find it (fortunately the profile only contained 12 packages). Is there a more convenient way to recursively show all propagated-inputs of a given package? It would be interesting to check how prevalent this propagation pollution is (another example that comes to mind is 'jami', which installs 125 programs under bin/, of which only about half can be attributed to 'util-linux'). Thanks, Diego
bug#37732: mps-youtube propagates util-linux
Hi Guix, An unfortunate chain of propagated-inputs causes 'util-linux' (mount, umount, etc.) to be installed alongside 'mps-youtube': 'mps-youtube' propagates 'python-pygobject', which propagates 'glib', which propagates 'util-linux'. It seems to have been introduced with commit 6c237a2, when 'util-linux' was moved to the propagated-inputs of 'glib'. This is a problem on foreign distributions, where the stowaway 'mount' and 'umount' commands installed by Guix shadow the setuid ones provided by the distro. I am currently on commit ecf3a3a (post core-updates merge). Regards, Diego
bug#37569: Mount does not honor 'user' option.
Diego Nicola Barbato writes: > Hello Danny, > > Danny Milosavljevic writes: > >> Hmm, how is that solved with other distributions? Is "mount" suid root >> there? > > Indeed, in Debian both mount and umount are suid root: > > $ stat -c "%a %U:%G %n" /bin/*mount > 4755 root:root /bin/fusermount > 4755 root:root /bin/mount > 4755 root:root /bin/umount I've tried adding "mount" and "umount" to `setuid-programs' in my operating-system config: --8<---cut here---start->8--- (setuid-programs (cons* #~(string-append #$util-linux "/bin/mount") #~(string-append #$util-linux "/bin/umount") %setuid-programs)) --8<---cut here---end--->8--- Mounting as an unprivileged user now works as expected (even the fancy 9p stuff). Is there any rationale for not adding "mount" and "umount" to `%setuid-programs' by default? Thanks, Diego
bug#37569: Mount does not honor 'user' option.
Hello Danny, Danny Milosavljevic writes: > Hmm, how is that solved with other distributions? Is "mount" suid root there? Indeed, in Debian both mount and umount are suid root: $ stat -c "%a %U:%G %n" /bin/*mount 4755 root:root /bin/fusermount 4755 root:root /bin/mount 4755 root:root /bin/umount Thanks, Diego
bug#37569: Mount does not honor 'user' option.
Hey Guix, I have added the following to `file-systems' in my operating-system config: --8<---cut here---start->8--- (file-system (device "127.0.0.1") (mount-point "/home/diego/inf") (type "9p") (options "noextend,trans=tcp,dfltuid=1000,dfltgid=998,port=9001,user,nofail") (mount? #f)) --8<---cut here---end--->8--- It works almost as expected except that when I try to mount the file system as a regular user (which is what the option 'user' is supposed to allow) I get: $ LC_ALL=C mount inf mount: /home/diego/inf: must be superuser to use mount. The command succeeds if I run it as root. The following steps reproduce the issue without using a 9p file system: 1. Prepare a file system on a loopback device: $ dd if=/dev/zero of=foo.img bs=1024 count=524288 $ udisksctl loop-setup --file foo.img Mapped file foo.img as /dev/loop0. $ sudo mkfs.ext4 -L foofs /dev/loop0 2. Add the following line to /etc/fstab replacing with something more appropriate: LABEL=foofs /home//foofs ext4 defaults,user 3. Try to mount the filesystem as an unprivileged user (This should work and does work on e.g. Debian 10): $ mkdir foofs $ LC_ALL=C mount foofs mount: /home//foofs: must be superuser to use mount. 4. Try it with sudo to confirm that everything else works as expected: $ sudo mount foofs $ ls foofs lost+found/ Regards, Diego
bug#37520: maxima x86_64/linux build failure
Christopher Howard writes: > Thank you. It is now building fine for me. I'm glad I could help. I'm closing this bug now. Regards, Diego
bug#34484: GCL: segfault on invocation on x86_64 and i686
Hi Guix, I'm closing this bug since it has been fixed a while ago as a side effect of … something. I don't know how it was fixed or even if it was fixed on purpose, but I'm glad it's gone. Regards, Diego
bug#37520: maxima x86_64/linux build failure
Hey Christopher,
Christopher Howard writes:
> Running guix overlaid on Debian 9 amd64. Ran guix pull && guix package -u.
> Ran guix install wxmaxima. Build fails with
>
> / 'configure' phasebuilder for
> `/gnu/store/m5r9y68mhya0kv828mp62y28bfm0lrmv-maxima-5.42.2.drv' failed with
> exit code 1
> build of /gnu/store/m5r9y68mhya0kv828mp62y28bfm0lrmv-maxima-5.42.2.drv failed
> View build log at
> '/var/log/guix/drvs/m5/r9y68mhya0kv828mp62y28bfm0lrmv-maxima-5.42.2.drv.bz2'.
>
> Last lines of build log are
>
> checking for gcl... true
> checking for iconv... true
> checking for recode... false
> configure: error: unable to run gcl executable "gcl".
> Backtrace:
>4 (primitive-load "/gnu/store/8n7mpp0l8rqv26gxr9hg9aj3ax4…")
> In ice-9/eval.scm:
>191:35 3 (_ _)
> In srfi/srfi-1.scm:
>863:16 2 (every1 # …)
> In
> /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/gnu-build-system.scm:
>799:28 1 (_ _)
> In
> /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm:
> 616:6 0 (invoke _ . _)
>
> /gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm:616:6:
> In procedure invoke:
> Throw to key `srfi-34' with args `(# "/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash"
> arguments: ("./configure"
> "CONFIG_SHELL=/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash"
> "SHELL=/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/bash"
> "--prefix=/gnu/store/3ihrqrdsq6r4n69nvaznbvcqni38c968-maxima-5.42.2"
> "--enable-fast-install" "--build=x86_64-unknown-linux-gnu" "--enable-gcl"
> "--with-posix-shell=/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh"
>
> "--with-wish=/gnu/store/2zl6wcliyd2ny8w73h77vk8bn4x91b7x-tk-8.6.8/bin/wish8.6")
> exit-status: 1 term-signal: #f stop-signal: #f] 8a0d40>)'.
This looks like a duplicate of [0]. The build fails because
gcl segfaults on invocation. That's where
> configure: error: unable to run gcl executable "gcl".
comes from.
This bug has recently been fixed (I'm currently on commit ee6bfff from
last friday and maxima builds successfully).
The problem in your case seems to be, that the guix you invoked when
running `guix install wxmaxima' (and `guix package -u') is not the one
you got by running `guix pull' (That's why guix tries to build
maxima-5.42.2 even though it has recently been updated to 5.43.0). You
might want to run:
export PATH="$HOME/.config/guix/current/bin:$PATH"
(See section 4.6 Invoking `guix pull' in the Guix manual). Or if you've
already done that, it might be necessary to run `hash guix' before
running `guix package -u' and `guix install wxmaxima' again.
If maxima still fails to build, could you please post the outputs of the
following commands:
which guix
guix describe
Thanks,
Diego
[0]: https://issues.guix.gnu.org/issue/34484
bug#35601: First 'guix pull' does not display 'hash guix' hint
Hi Guix, Congratulations on 1.0.0! I took the opportunity to revisit bug #33647 [0] and verify that commits 3bbd691 and d1d7283 have the desired effect. Unfortunately they do not: The first time a user runs guix pull on a freshly installed Guix System no hint about running 'hash guix' is displayed even though it is precisely when the hint was supposed to be displayed. To reproduce simply run (after installing Guix System using the 1.0.0 installer) 'guix --version', which will yield 'guix (GNU Guix) 1.0.0', then 'guix pull', which will display no hint about running 'hash guix', then 'guix --version' again, which will return 'guix (GNU Guix) 1.0.0' again, and finally 'hash guix' followed by 'guix --version', which now will yield 'guix (GNU Guix) 1234somecommithash123456789abcdefghijklm'. Regardless of the hint I still believe it is unfortunate that running 'guix pull && guix system reconfigure /etc/config.scm' for the first time will rather counterintuitively downgrade the system instead of upgrading it. Regards, Diego [0]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33647
bug#35408: External monitor not working with GDM
Hi Ben, Ben Sturmfels writes: > Hi Ludovic, > > On Thu, 2019-04-25 at 11:08 +0200, Ludovic Courtès wrote: >> >> Ben Sturmfels skribis: >> >> > I was previously using a 24" Samsung external monitor with my X200 >> > Guix >> > System via VGA. Since the switch to GDM, I no longer seem to be >> > able >> > connect this monitor. When I do, the laptop screen just keeps >> > flashing. >> >> So the GDM login screen never shows up, right? > > I'm thoroughly confused now. GDM definitely *was* working with the > laptop screen only, but now when I reconfigure it or choose an old Grub > entry, I can't get to the login screen with either external monitor or > the laptop. In both cases the console loops showing a message something > like: > > New session c1 of user gdm. > Removed session c1. > . > . > . > New session c506 of user gdm. > Removed session c506. This sounds familiar. Can you check if /var/lib/gdm is owned by gdm. If it isn't, chowning it back to gdm:gdm should fix it. Regards Diego
bug#35324: SDDM shows black screen instead of login prompt
Hello Guix, As already mentioned on IRC SDDM does not work for me. This is what I tried: $ qemu-system-x86_64 -enable-kvm -snapshot -m 6G $(guix system vm-image --image-size=24G config.scm) After booting I get a black screen instead of a greeter. I have attached the config.scm, Xorg.log, and sddm.log. This is on Guix System (commit: 5069bae) on x86_64. Regards, Diego config.scm Description: Binary data Xorg.0.log Description: Binary data sddm.log Description: Binary data
bug#34892: Ghostscript: Missing text when converting PDF to PS
Hello Guix, I am closing this as it is a duplicate of bug 34877, which I accidentally submitted twice. Regards, Diego
bug#34877: Ghostscript: Missing text when converting PDF to PS
Hello Guix, Diego Nicola Barbato writes: > Hello Guix, > > When converting certain PDF files to PostScript pdf2ps (from the > Ghostscript package) will print the following error messages: > > --8<---cut here---start->8--- > Error reading a content stream. The page may be incomplete. >Output may be incorrect. > Error: File did not complete the page properly and may be damaged. >Output may be incorrect. > --8<---cut here---end--->8--- > > The resulting file will be missing some (sometimes all) of the text. > > I have attached one such PDF, which I obtained from > https://www.ichkoche.at/?ctl=recipe_pdf&recipe_id=3161, alongside the > files generated by running pdf2ps on both Guix System and, for > reference, Debian 9, where the conversion succeeds (even though they > provide the same version (9.26 (2018-11-20)) of Ghostscript). > > I have also attached the results of running ‘gsnd -dPDFDEBUG’ on the > offending file. > > I run Guix System (commit: 0bd1498) on x86_64. > > Regards, > > Diego Unfortunately the original message did not make it to the mailing list because the attachments were too big. It did make it to debbugs, though, so the attachments should be available there (https://debbugs.gnu.org/34877). Regards, Diego
bug#34484: GCL: segfault on invocation on x86_64 and i686
Diego Nicola Barbato writes: > Hello Guix, > > GCL segfaults upon execution on x86_64 and i686. This is most likely > the reason why Maxima fails to build on those architectures [0] [1]. > > This is what I tried: > > > diego@GLaDOS ~$ guix build gcl > /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 > diego@GLaDOS ~$ > /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2/bin/gcl > Speicherzugriffsfehler > diego@GLaDOS ~$ guix build -s i686-linux gcl > /gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2 > diego@GLaDOS ~$ > /gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2/bin/gcl > Speicherzugriffsfehler > > > I also tried building GCL locally to check if this was something > non-deterministic with the same result: > > > diego@GLaDOS ~$ guix build gcl --check --keep-failed > > [...] > > phase `compress-documentation' succeeded after 0.1 seconds > note: keeping build directory `/tmp/guix-build-gcl-2.6.12-2.d3335e2.drv-4' > guix build: error: derivation > `/gnu/store/kljywjw5a3wpcqk67p1isrrgy5yxgp21-gcl-2.6.12-2.d3335e2.drv' may > not be deterministic: output > `/gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2' differs > from ‘/gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2-check’ > diego@GLaDOS ~$ > /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2-check/bin/gcl > Speicherzugriffsfehler > diego@GLaDOS ~$ guix build gcl -s i686-linux --check --keep-failed > > [...] > > phase `compress-documentation' succeeded after 0.1 seconds > note: keeping build directory `/tmp/guix-build-gcl-2.6.12-2.d3335e2.drv-3' > guix build: error: derivation > `/gnu/store/p7r9c9kqf4gafik0a3q9fl0ry8hks99f-gcl-2.6.12-2.d3335e2.drv' may > not be deterministic: output > `/gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2' differs > from ‘/gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2-check’ > diego@GLaDOS ~$ > /gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2-check/bin/gcl > Speicherzugriffsfehler > > GCL works fine on armhf (I did not try it on aarch64). > > I run Guix System (commit: 571a01d) on x86_64. > > Regards, > > Diego > > > [0]: https://berlin.guixsd.org/build/943168 (x86_64) > [1]: https://berlin.guixsd.org/build/943189 (i686) Some additional information: GCL does not segfault if I get the substitute from hydra (where Maxima builds successfully). It does segfault (on the aforementioned architectures) if I get the substitute from berlin (where Maxima fails to build) and if I build it locally. Here is what I have tried (I get the same results when passing ‘--system=i686-linux’ to the build commands): --8<---cut here---start->8--- diego@GLaDOS ~$ guix gc --delete $(guix gc --list-dead |grep gcl-2) [...] diego@GLaDOS ~$ $(guix build --substitute-urls=https://mirror.hydra.gnu.org gcl)/bin/gcl 7.1 MB werden heruntergeladen: /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 Substituiere /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 … Lade von https://mirror.hydra.gnu.org/guix/nar/gzip/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 herunter … gcl-2.6.12-2.d3335e2 6.8MiB 2.7MiB/s 00:03 [##] 100.0% GCL (GNU Common Lisp) 2.6.12 ANSIFri Apr 22 15:51:11 UTC 2016 Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl) Binary License: GPL due to GPL'ed components: (READLINE UNEXEC) Modifications of this banner must retain notice of a compatible license Dedicated to the memory of W. Schelter Use (help) to get some basic information on how to use GCL. Temporary directory for compiler files: /tmp/ > --8<---cut here---end--->8--- --8<---cut here---start->8--- diego@GLaDOS ~$ guix gc --delete $(guix gc --list-dead |grep gcl-2) [...] diego@GLaDOS ~$ $(guix build --substitute-urls=https://berlin.guixsd.org gcl)/bin/gcl 7.1 MB werden heruntergeladen: /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 Substituiere /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 … Lade von https://berlin.guixsd.org/nar/gzip/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 herunter … gcl-2.6.12-2.d3335e2 6.7MiB 2.4MiB/s 00:03 [##] 100.0% Speicherzugriffsfehler --8<---cut here---end--->8--- --8<---cut here---start->8--- diego@GLaDOS ~$ guix gc --delete $(guix gc --list-dead |grep gcl-2) [...] diego@GLaDOS ~$ guix build --check --keep-failed gcl [...] guix build: error: derivation `/gnu/store/k5ygb
bug#29516: Maxima fails to build
Hello Guix, I am closing this bug in response to Leo’s message on guix-devel [0]. This particular issue has been solved quite some time ago and GCL and Maxima have both been updated since. Maxima currently fails to build for a different reason for which I have opened a new bug report [1]. Regards, Diego [0]: https://lists.gnu.org/archive/html/guix-devel/2019-02/msg00220.html [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34484
bug#34484: GCL: segfault on invocation on x86_64 and i686
Hello Guix, GCL segfaults upon execution on x86_64 and i686. This is most likely the reason why Maxima fails to build on those architectures [0] [1]. This is what I tried: --8<---cut here---start->8--- diego@GLaDOS ~$ guix build gcl /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2 diego@GLaDOS ~$ /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2/bin/gcl Speicherzugriffsfehler diego@GLaDOS ~$ guix build -s i686-linux gcl /gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2 diego@GLaDOS ~$ /gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2/bin/gcl Speicherzugriffsfehler --8<---cut here---end--->8--- I also tried building GCL locally to check if this was something non-deterministic with the same result: --8<---cut here---start->8--- diego@GLaDOS ~$ guix build gcl --check --keep-failed [...] phase `compress-documentation' succeeded after 0.1 seconds note: keeping build directory `/tmp/guix-build-gcl-2.6.12-2.d3335e2.drv-4' guix build: error: derivation `/gnu/store/kljywjw5a3wpcqk67p1isrrgy5yxgp21-gcl-2.6.12-2.d3335e2.drv' may not be deterministic: output `/gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2' differs from ‘/gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2-check’ diego@GLaDOS ~$ /gnu/store/5zzfw856c1acrmalsdznm1093mkvnwls-gcl-2.6.12-2.d3335e2-check/bin/gcl Speicherzugriffsfehler diego@GLaDOS ~$ guix build gcl -s i686-linux --check --keep-failed [...] phase `compress-documentation' succeeded after 0.1 seconds note: keeping build directory `/tmp/guix-build-gcl-2.6.12-2.d3335e2.drv-3' guix build: error: derivation `/gnu/store/p7r9c9kqf4gafik0a3q9fl0ry8hks99f-gcl-2.6.12-2.d3335e2.drv' may not be deterministic: output `/gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2' differs from ‘/gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2-check’ diego@GLaDOS ~$ /gnu/store/cbw0k4apa6qiqfm7g9j0lzfbzfk6mxj2-gcl-2.6.12-2.d3335e2-check/bin/gcl Speicherzugriffsfehler --8<---cut here---end--->8--- GCL works fine on armhf (I did not try it on aarch64). I run Guix System (commit: 571a01d) on x86_64. Regards, Diego [0]: https://berlin.guixsd.org/build/943168 (x86_64) [1]: https://berlin.guixsd.org/build/943189 (i686)
bug#34468: guix pull: wrong %system when using --system flag
Hello Guix, When running ‘guix pull’ with the --system flag the resulting guix is configured for the host architecture instead of the target architecture (i.e. the %system variable in ‘(guix config)’ is set to the host architecture instead of the target architecture). E.g. after running ‘guix pull -p test -s i686-linux’ on an x86_64 host the file test/share/guile/site/2.2/guix/config.scm will contain the declaration ‘(define-public %system "x86_64-linux")’. I run what was formerly known as GuixSD (commit: 571a01d) on x86_64. Regards, Diego
bug#33647: First `guix pull' behaves unexpectedly
Hello Ludo, Sorry to bother you with this again. Ludovic Courtès writes: [...] > > Thanks for the heads-up. Commit > 3bbd6919bd84b76686d1aa626ba861faf3fc8ceb changes ‘guix pull’ to display > a hint in this case. > > Ludo’. I just tried to check if this worked. I installed GuixSD in a VM (with the 0.16.0 installer), rebooted, and ran ‘guix pull’ (commit d1dfcc7c1b38d816dddc2868917ba490db7e7c3b). It did not print any hint (I have attached the bash session). Will this change only take effect once the installer is updated? Regards, Diego guix_pull.log Description: Bash session
bug#33647: First `guix pull' behaves unexpectedly
Hello, Ludovic Courtès writes: > Diego Nicola Barbato skribis: > >> Ludovic Courtès writes: > > [...] > >>> In addition, be aware that Bash maintains a cache of commands it looked >>> up in $PATH. Thus it may be that, say, it had cached that ‘guix’ is >>> really /run/current-system/profile/bin/guix. When you pulled, it didn’t >>> invalidate its cache thus you kept using that old version. >>> >>> The solution is to run “hash guix” at the Bash prompt to force cache >>> invalidation (info "(bash) Bourne Shell Builtins"). >> >> I believe this is it. This also explains why ‘which guix’ returned the >> updated guix while ‘guix --version’ claimed it was still the older >> version, which I found rather confusing. >> I am afraid being unaware of this has led me to inadvertently downgrade >> GuixSD whenever I reconfigured for the first time after a fresh install. > > Yeah. This is not strictly speaking a Guix bug, but clearly it’s a > common pitfall. Perhaps we should print a hint upon completion? While I think it would be nice for Guix (or strictly speaking Bash) to just do what a noob like me would expect it to do in this situation, a hint would have certainly saved me some trouble. If it is unreasonably cumbersome to make Guix tell Bash to invalidate its cache upon completion of ‘guix pull’, I believe a hint would be good enough. Greetings, Diego
bug#33110: Maxima build fails during check phase
Hello Guix, I am closing this bug report as this has been fixed a while ago and Maxima has since been updated to version 5.42.1. I completely forgot about this, sorry! Diego
bug#33623: Backtrace when running `guix system roll-back'
Diego Nicola Barbato writes: > Hello Swedebugia, > > swedebu...@riseup.net writes: > >> On 2018-12-05 12:36, Diego Nicola Barbato wrote: >>> Hello Guix, >>> >>> When I run ‘guix system roll-back’ I get the following backtrace: >>> >>> --8<---cut here---start->8--- >>> root@tapuakh ~# guix system roll-back >>> Backtrace: >>> 10 (primitive-load "/root/.config/guix/current/bin/guix") >>> In guix/ui.scm: >>> 1603:12 9 (run-guix-command _ . _) >>> In ice-9/boot-9.scm: >>> 829:9 8 (catch srfi-34 # …) >>> 829:9 7 (catch system-error # …) >>> In guix/scripts/system.scm: >>>1268:8 6 (_) >>> In guix/status.scm: >>> 615:4 5 (call-with-status-report _ _) >>> In guix/scripts/system.scm: >>>1208:9 4 (process-command _ _ _) >>>469:10 3 (switch-to-system-generation # …) >>> In guix/store.scm: >>> 1659:24 2 (run-with-store _ _ #:guile-for-build _ #:system _ # _) >>> In guix/scripts/system.scm: >>> 499:6 1 (_ _) >>> In unknown file: >>>0 (_ #) >>> >>> ERROR: Wrong type to apply: #< name: "grub.cfg" gexp: >>> # guile: #f options: (#:local-build? #t)> >>> --8<---cut here---end--->8--- >>> >>> I run GuixSD (commit: 1f51f0d975d95a2ba645193cf43d0a294d952e83) on an >>> x86_64 machine. >> >> Interesting. Could you provide a config.scm to help us reproduce the >> issue? > > I've got something better. > > Steps to reproduce: > > Install GuixSD in a VM using the iso image and the attached config. The > image should be at least 16G (8G is to small for a reconfigure). > > Reboot the VM. > > Run ‘guix pull --commit=1f51f0’ as root. > > Make sure to log out and back in again to avoid bug#33647. > > Run ‘guix system reconfigure /etc/config.scm’. > > Reboot the VM. > > Run ‘guix system roll-back’ as root. > > Backtrace ensues. I just repeated the aforementioned steps with the new (0.16.0) iso image and by pulling from current master (5118e2) instead of 1f51f0 and got a similar backtrace. I believe ‘guix system roll-back’ is currently broken on master. Judging from the backtrace this might have something to do with the recent clean up of system code (specifically commit 46c296). Greetings Diego
bug#33647: First `guix pull' behaves unexpectedly
Hello, Ludovic Courtès writes: > Hello, > > Ricardo Wurmus skribis: > >>> Hello Guix, >>> >>> The first time a user runs ‘guix pull’ after a fresh install it does not >>> seem to update guix. ‘guix --version’ reports that guix is still >>> version 0.15.0 after running ‘guix pull’, instead of showing the hash of >>> the latest commit. >> >> “guix pull” should have reminded you to add ~/.config/guix/current/bin >> to the front of your PATH environment variable. When you do that you >> will be using the new version of Guix. I forgot to mention that this is on GuixSD, where ~/.config/guix/currend/bin is already in PATH, which maybe explains why I did not get a reminder. > In addition, be aware that Bash maintains a cache of commands it looked > up in $PATH. Thus it may be that, say, it had cached that ‘guix’ is > really /run/current-system/profile/bin/guix. When you pulled, it didn’t > invalidate its cache thus you kept using that old version. > > The solution is to run “hash guix” at the Bash prompt to force cache > invalidation (info "(bash) Bourne Shell Builtins"). I believe this is it. This also explains why ‘which guix’ returned the updated guix while ‘guix --version’ claimed it was still the older version, which I found rather confusing. I am afraid being unaware of this has led me to inadvertently downgrade GuixSD whenever I reconfigured for the first time after a fresh install. Thanks! Diego
bug#33647: First `guix pull' behaves unexpectedly
Hello Ricardo, Thank you for the prompt reply. Ricardo Wurmus writes: > Hi Diego, > >> Hello Guix, >> >> The first time a user runs ‘guix pull’ after a fresh install it does not >> seem to update guix. ‘guix --version’ reports that guix is still >> version 0.15.0 after running ‘guix pull’, instead of showing the hash of >> the latest commit. > > “guix pull” should have reminded you to add ~/.config/guix/current/bin > to the front of your PATH environment variable. I just checked the output and there was nothing after “1 package in profile”, which is where the “The following environment variable definitions may be needed:” lines are usually printed. If ‘guix pull’ is indeed supposed to print a reminder this is probably the bug. Greetings Diego
bug#33623: Backtrace when running `guix system roll-back'
Hello Swedebugia, swedebu...@riseup.net writes: > On 2018-12-05 12:36, Diego Nicola Barbato wrote: >> Hello Guix, >> >> When I run ‘guix system roll-back’ I get the following backtrace: >> >> --8<---cut here---start->8--- >> root@tapuakh ~# guix system roll-back >> Backtrace: >> 10 (primitive-load "/root/.config/guix/current/bin/guix") >> In guix/ui.scm: >> 1603:12 9 (run-guix-command _ . _) >> In ice-9/boot-9.scm: >> 829:9 8 (catch srfi-34 # …) >> 829:9 7 (catch system-error # …) >> In guix/scripts/system.scm: >>1268:8 6 (_) >> In guix/status.scm: >> 615:4 5 (call-with-status-report _ _) >> In guix/scripts/system.scm: >>1208:9 4 (process-command _ _ _) >>469:10 3 (switch-to-system-generation # …) >> In guix/store.scm: >> 1659:24 2 (run-with-store _ _ #:guile-for-build _ #:system _ # _) >> In guix/scripts/system.scm: >> 499:6 1 (_ _) >> In unknown file: >>0 (_ #) >> >> ERROR: Wrong type to apply: #< name: "grub.cfg" gexp: >> # guile: #f options: (#:local-build? #t)> >> --8<---cut here---end--->8--- >> >> I run GuixSD (commit: 1f51f0d975d95a2ba645193cf43d0a294d952e83) on an >> x86_64 machine. > > Interesting. Could you provide a config.scm to help us reproduce the > issue? I've got something better. Steps to reproduce: Install GuixSD in a VM using the iso image and the attached config. The image should be at least 16G (8G is to small for a reconfigure). Reboot the VM. Run ‘guix pull --commit=1f51f0’ as root. Make sure to log out and back in again to avoid bug#33647. Run ‘guix system reconfigure /etc/config.scm’. Reboot the VM. Run ‘guix system roll-back’ as root. Backtrace ensues. Greetings Diego config.scm Description: Binary data
bug#33647: First `guix pull' behaves unexpectedly
Hello Guix, The first time a user runs ‘guix pull’ after a fresh install it does not seem to update guix. ‘guix --version’ reports that guix is still version 0.15.0 after running ‘guix pull’, instead of showing the hash of the latest commit. This can be mitigated by logging out and back in, after which ‘guix --version’ returns the expected version. Greetings Diego
bug#33623: Backtrace when running `guix system roll-back'
Hello Guix, When I run ‘guix system roll-back’ I get the following backtrace: --8<---cut here---start->8--- root@tapuakh ~# guix system roll-back Backtrace: 10 (primitive-load "/root/.config/guix/current/bin/guix") In guix/ui.scm: 1603:12 9 (run-guix-command _ . _) In ice-9/boot-9.scm: 829:9 8 (catch srfi-34 # …) 829:9 7 (catch system-error # …) In guix/scripts/system.scm: 1268:8 6 (_) In guix/status.scm: 615:4 5 (call-with-status-report _ _) In guix/scripts/system.scm: 1208:9 4 (process-command _ _ _) 469:10 3 (switch-to-system-generation # …) In guix/store.scm: 1659:24 2 (run-with-store _ _ #:guile-for-build _ #:system _ # _) In guix/scripts/system.scm: 499:6 1 (_ _) In unknown file: 0 (_ #) ERROR: Wrong type to apply: #< name: "grub.cfg" gexp: # guile: #f options: (#:local-build? #t)> --8<---cut here---end--->8--- I run GuixSD (commit: 1f51f0d975d95a2ba645193cf43d0a294d952e83) on an x86_64 machine. Greetings Diego
bug#33110: Maxima build fails during check phase
Hello Guix, After the recent (commit: 82cbe4e0467304e5d8f5931ca4d70617a0e323ba) update of maxima to version 5.42.0 ‘guix build maxima’ fails during the ‘check’ phase. I have attached tests/test-suite.log. I run GuixSD (commit: 2c17bd7b2955beef4130d11b33e07e4fb3b234dc) on an x86_64 machine. Greetings, Diego test-suite.log Description: tests/test-suite.log
bug#32341: EXWM full screen mode broken
Hello Guix The recent [1] update of EXWM has introduced a bug which causes the wrong window configuration to be restored after closing a full screen window. It has already been reported [2] and fixed [3] upstream. Greetings Diego [1] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=b9231c5c0ce8bd23b73a51552d7163558329ebf6 [2] https://github.com/ch11ng/exwm/issues/458 [3] https://github.com/ch11ng/exwm/commit/13a14579cc1bb772735f895dd5b4b90c6812f3ee
bug#31287: qemu-minimal-2.10.2 fails to build
Diego Nicola Barbato writes: > Hello Guix > > Currently `guix build grub --keep-failed' fails with the following error: > > TEST: tests/test-hmp... (pid=13798) > /i386/hmp/pc-0.12: OK > /i386/hmp/pc-i440fx-2.4: OK > /i386/hmp/pc-1.3:OK > /i386/hmp/pc-q35-2.7:OK > /i386/hmp/pc-q35-2.6:OK > /i386/hmp/none: OK > /i386/hmp/pc-i440fx-1.7: OK > /i386/hmp/pc-i440fx-2.8: OK > /i386/hmp/pc-i440fx-1.6: OK > /i386/hmp/pc-i440fx-2.7: OK > /i386/hmp/pc-i440fx-2.10:OK > /i386/hmp/pc-0.11: OK > /i386/hmp/pc-i440fx-2.3: OK > /i386/hmp/pc-0.10: OK > /i386/hmp/pc-1.2:OK > /i386/hmp/pc-i440fx-2.2: OK > /i386/hmp/isapc: OK > /i386/hmp/pc-q35-2.5:OK > /i386/hmp/pc-0.15: OK > /i386/hmp/pc-0.14: OK > /i386/hmp/pc-i440fx-1.5: OK > /i386/hmp/pc-i440fx-2.6: OK > /i386/hmp/pc-i440fx-1.4: OK > /i386/hmp/pc-i440fx-2.5: OK > /i386/hmp/pc-q35-2.9:OK > /i386/hmp/pc-1.1:OK > /i386/hmp/pc-i440fx-2.1: OK > /i386/hmp/pc-q35-2.8:OK > /i386/hmp/pc-1.0:OK > /i386/hmp/pc-i440fx-2.0: OK > /i386/hmp/pc-q35-2.4:OK > /i386/hmp/pc-i440fx-2.9: OK > /i386/hmp/pc-0.13: OK > /i386/hmp/pc-q35-2.10: OK > PASS: tests/test-hmp > make: *** > [/tmp/guix-build-qemu-minimal-2.10.2.drv-0/qemu-2.10.2/tests/Makefile.include:837: > check-qtest-i386] Error 1 > phase `check' failed after 398.0 seconds > note: keeping build directory `/tmp/guix-build-qemu-minimal-2.10.2.drv-0' > builder for > `/gnu/store/66dx3lqbgfff0abfccwsk8yk5718q1sm-qemu-minimal-2.10.2.drv' failed > with exit code 1 > @ build-failed > /gnu/store/66dx3lqbgfff0abfccwsk8yk5718q1sm-qemu-minimal-2.10.2.drv - 1 > builder for > `/gnu/store/66dx3lqbgfff0abfccwsk8yk5718q1sm-qemu-minimal-2.10.2.drv' failed > with exit code 1 > cannot build derivation > `/gnu/store/hlc5kmwwwzacbw7avmsp4fwki129hal7-grub-2.02.drv': 1 dependencies > couldn't be built > guix build: error: build failed: build of > `/gnu/store/hlc5kmwwwzacbw7avmsp4fwki129hal7-grub-2.02.drv' failed > > This also breaks `guix system reconfigure /etc/config.scm'. > > I run GuixSD (commit: 2216b6f4108abfb2f75db7667beaa46ee7d630e8) on an > x86_64 machine. I am closing this as I can no longer reproduce this error. It failed a couple of times in a row but after rebooting (I did not run `guix pull' so I am still on the same commit) the build succeeds every time. Sorry for the noise Diego
bug#31287: qemu-minimal-2.10.2 fails to build
Hello Guix Currently `guix build grub --keep-failed' fails with the following error: TEST: tests/test-hmp... (pid=13798) /i386/hmp/pc-0.12: OK /i386/hmp/pc-i440fx-2.4: OK /i386/hmp/pc-1.3:OK /i386/hmp/pc-q35-2.7:OK /i386/hmp/pc-q35-2.6:OK /i386/hmp/none: OK /i386/hmp/pc-i440fx-1.7: OK /i386/hmp/pc-i440fx-2.8: OK /i386/hmp/pc-i440fx-1.6: OK /i386/hmp/pc-i440fx-2.7: OK /i386/hmp/pc-i440fx-2.10:OK /i386/hmp/pc-0.11: OK /i386/hmp/pc-i440fx-2.3: OK /i386/hmp/pc-0.10: OK /i386/hmp/pc-1.2:OK /i386/hmp/pc-i440fx-2.2: OK /i386/hmp/isapc: OK /i386/hmp/pc-q35-2.5:OK /i386/hmp/pc-0.15: OK /i386/hmp/pc-0.14: OK /i386/hmp/pc-i440fx-1.5: OK /i386/hmp/pc-i440fx-2.6: OK /i386/hmp/pc-i440fx-1.4: OK /i386/hmp/pc-i440fx-2.5: OK /i386/hmp/pc-q35-2.9:OK /i386/hmp/pc-1.1:OK /i386/hmp/pc-i440fx-2.1: OK /i386/hmp/pc-q35-2.8:OK /i386/hmp/pc-1.0:OK /i386/hmp/pc-i440fx-2.0: OK /i386/hmp/pc-q35-2.4:OK /i386/hmp/pc-i440fx-2.9: OK /i386/hmp/pc-0.13: OK /i386/hmp/pc-q35-2.10: OK PASS: tests/test-hmp make: *** [/tmp/guix-build-qemu-minimal-2.10.2.drv-0/qemu-2.10.2/tests/Makefile.include:837: check-qtest-i386] Error 1 phase `check' failed after 398.0 seconds note: keeping build directory `/tmp/guix-build-qemu-minimal-2.10.2.drv-0' builder for `/gnu/store/66dx3lqbgfff0abfccwsk8yk5718q1sm-qemu-minimal-2.10.2.drv' failed with exit code 1 @ build-failed /gnu/store/66dx3lqbgfff0abfccwsk8yk5718q1sm-qemu-minimal-2.10.2.drv - 1 builder for `/gnu/store/66dx3lqbgfff0abfccwsk8yk5718q1sm-qemu-minimal-2.10.2.drv' failed with exit code 1 cannot build derivation `/gnu/store/hlc5kmwwwzacbw7avmsp4fwki129hal7-grub-2.02.drv': 1 dependencies couldn't be built guix build: error: build failed: build of `/gnu/store/hlc5kmwwwzacbw7avmsp4fwki129hal7-grub-2.02.drv' failed This also breaks `guix system reconfigure /etc/config.scm'. I run GuixSD (commit: 2216b6f4108abfb2f75db7667beaa46ee7d630e8) on an x86_64 machine. Greetings Diego
bug#31085: Unexpected behaviour when running `guix build lilypond'
Hello l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Diego Nicola Barbato skribis: > >> I have experienced some unexpected behaviour when running `guix build >> lilypond': >> After verifying that there was a substitute available with `guix weather >> -m m.scm' (Where m.scm evaluates to a manifest containing only lilypond) >> I ran `guix build lilypond --dry-run' which claimed that a substitute >> would be downloaded. I then ran `guix build lilypond' which proceeded >> to build lilypond from source (instead of downloading the substitute). >> >> Upon explaining this on IRC it was suggested that I try running `guix >> build --no-grafts lilypond' (which actually downloaded the substitute) >> then deleting the locally built lilypond with `guix gc --delete >> /gnu/store/...' and finally running `guix build lilypond' again (which, >> this time, grafted the substituted lilypond instead of building it from >> source again). While this fixed the issue I was told that this >> behaviour was indeed unexpected. > > We’d have to see if this is still reproducible, but I have a plausible > explanation. I can consistently reproduce this in a VM with the following steps: First I run: $ qemu-system-x86_64 -enable-kvm -snapshot -m 4G $(guix system vm-image bare-bones.scm --image-size=8G) (Where bare-bones.scm is the bare-bones.tmpl after replacing /dev/sdX with /dev/sda.) Then after logging in as root: # guix pull --commit=872bda5de52a8f0514230ebc4e9680aab74f509a # guix build --dry-run lilypond Which returns: 52.1 MB would be downloaded: /gnu/store/0amx7bcbs518lkqwfh2azmqrp2yqib0g-lilypond-2.19.80 /gnu/store/7b5ykfl6jbrdl8j7xp630fga4as3234z-ghostscript-9.22 /gnu/store/j4vj7h3wyb532g2j0axzjj43z2a0dg81-python-2.7.14 /gnu/store/k2ak44m0miind785x22mmpbcwi0mq7hq-freetype-2.8.1 /gnu/store/mkhfqx7m7pniyic0kh0lnafmajymn4dr-guile-1.8.8 /gnu/store/pwbx5fhjrq9crr1c0d2x08ch0l6vr3cv-pango-1.40.14 /gnu/store/qm8ri32n0rkh749v3jb3x8s8ksjl7yd3-fontconfig-2.12.6 /gnu/store/sm37m59gq3smxxz8gs4jikn50qg0g7xh-glib-2.54.2 Then: # guix build lilypond Which, after downloading the dependencies, starts to build lilypond from source. > Substitute info is cached locally. guix-daemon caches it under > /var/guix/substitute/cache, but ‘guix weather’ caches it under > ~/.cache/guix/substitute (that’s because it needs fine-grain control > over substitute info and thus cannot simply use the > ‘substitutable-path-info’ daemon RPC.) Each cached entry has a > time-to-live (TTL). > > What could have happened is that /var/guix/substitute/ had a > not-expired-yet entry saying that there’s no substitute for LilyPond > (which is why ‘guix build’ ended up building from source), whereas ‘guix > weather’ was run at a point when there was a substitute. The unexpected behaviour was that `guix build lilypond' started to build lilypond from source after `guix build --dry-run lilypond' had claimed that nothing would be built and that it would download a substitute. I assume that `guix build --dry-run' is not affected by the substitute info used by `guix weather'. I only ran `guix weather' in order to double check that there were indeed substitutes available (Sorry for the red herring). Greetings Diego
bug#31085: Unexpected behaviour when running `guix build lilypond'
Hello Guix I have experienced some unexpected behaviour when running `guix build lilypond': After verifying that there was a substitute available with `guix weather -m m.scm' (Where m.scm evaluates to a manifest containing only lilypond) I ran `guix build lilypond --dry-run' which claimed that a substitute would be downloaded. I then ran `guix build lilypond' which proceeded to build lilypond from source (instead of downloading the substitute). Upon explaining this on IRC it was suggested that I try running `guix build --no-grafts lilypond' (which actually downloaded the substitute) then deleting the locally built lilypond with `guix gc --delete /gnu/store/...' and finally running `guix build lilypond' again (which, this time, grafted the substituted lilypond instead of building it from source again). While this fixed the issue I was told that this behaviour was indeed unexpected. I run GuixSD (commit: ae81bf4f995466a4650e2756d2763b8a163d2f63) on an x86-64 machine. Greetings Diego
bug#30370: guix system init can't find guix-register
Hello, l...@gnu.org (Ludovic Courtès) writes: > Diego Nicola Barbato skribis: > >> But I also tried running >> "grep -r d4wwx93gqizx132zjk7h1ir7rzph0pig ~/.config/guix/latest" which >> returned this: >> /home/diego/.config/guix/latest/guix/config.scm: >> "/gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin") > > Bingo! This string is inherit from the (guix config) of your initial > installation, the one you used to run ‘guix pull’. > > I would call this a ‘guix pull’ bug. I think this is a bug in the ‘build’ procedure defined in build-self.scm which is used by guix pull’ and which uses the (guix build pull) module to generate a new config.scm. It uses the value for %sbindir defined in (guix config) which causes it to be passed on unchanged. My guess is that (find-best-packages-by-name "guix" #f) should be used to determine the correct guix instead, which is how the values for the dependencies (libgcrypt, zlib, ...) are determined, and that this should be used to get the sbin directory with ‘string-append’. WDYT? Greetings Diego
bug#30370: guix system init can't find guix-register
Hello, l...@gnu.org (Ludovic Courtès) writes: > Hi, > > Diego Nicola Barbato skribis: > >> l...@gnu.org (Ludovic Courtès) writes: >> >>> Hello, >>> >>> Diego Nicola Barbato skribis: >>> >>>> Betriebssystem unter »/mnt« wird initialisiert … >>>> In execvp of >>>> /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin/guix-register: >>>> Datei oder Verzeichnis nicht gefunden >>>> guix system: error: failed to register >>>> '/gnu/store/2g4dzfcs6nf906d7jl6q225llmnv7krl-linux-libre-4.15' under '/mnt' >>>> copying to '/mnt'... >>>> >>>> It does not matter that it is a loopback device. The same thing happens >>>> if I try to install it on a USB flash drive. >>>> The issue seems to be that there is no >>>> d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/ >>>> in my store. All I could find was this: >>>> 80k8kz7qk9palbn0ccw7y3fgym8jxlps-guix-0.12.0-10.ba2260d/ >>> >>> Could you try to figure out where that >>> d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d comes from? >> >> I could not figure out where this comes from. As I mentioned it is not >> in my store, yet (only) "guix system init" seems to look for it. > > I mean, can you run something like: > > grep -r d4wwx93gqizx132zjk7h1ir7rzph0pig \ > $(dirname $(dirname $(readlink -f $(type -P guix This did not return anything. But I also tried running "grep -r d4wwx93gqizx132zjk7h1ir7rzph0pig ~/.config/guix/latest" which returned this: /home/diego/.config/guix/latest/guix/config.scm: "/gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin") Übereinstimmungen in Binärdatei /home/diego/.config/guix/latest/guix/config.go This is the file: config.scm Description: config.scm Greetings Diego
bug#30370: guix system init can't find guix-register
Hello, l...@gnu.org (Ludovic Courtès) writes: > Hello, > > Diego Nicola Barbato skribis: > >> Betriebssystem unter »/mnt« wird initialisiert … >> In execvp of >> /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin/guix-register: >> Datei oder Verzeichnis nicht gefunden >> guix system: error: failed to register >> '/gnu/store/2g4dzfcs6nf906d7jl6q225llmnv7krl-linux-libre-4.15' under '/mnt' >> copying to '/mnt'... >> >> It does not matter that it is a loopback device. The same thing happens >> if I try to install it on a USB flash drive. >> The issue seems to be that there is no >> d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/ >> in my store. All I could find was this: >> 80k8kz7qk9palbn0ccw7y3fgym8jxlps-guix-0.12.0-10.ba2260d/ > > Could you try to figure out where that > d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d comes from? I could not figure out where this comes from. As I mentioned it is not in my store, yet (only) "guix system init" seems to look for it. > Also, current master is at 0.14.0*, so it’s surprising that you end up > using such an old version. It is indeed quite surprising. Especially since "type -P guix-register" returns "/run/current-system/profile/sbin/guix-register" which links to "/gnu/store/b5hfsdq8yzcqfvikfhm0gk95xa5pfwgy-guix-0.14.0-7.33988f9/sbin/guix-register" and "type -P guix" returns "/run/current-system/profile/bin/guix" which links to "/gnu/store/b5hfsdq8yzcqfvikfhm0gk95xa5pfwgy-guix-0.14.0-7.33988f9/bin/guix" (for both my user and root). > Could it be that ~root/.config/guix/latest points to that old Guix? It did not (I ran "guix pull" as user and as root last Friday, 2018-02-02). And now after running "guix pull" again (as both user and root) ~root/.config/guix/latest and ~/.config/guix/latest point to /gnu/store/a565qard9xc0f0mg0vlbsrn419qgwfp9-guix-latest. > Does “sudo guix pull” help? Unfortunately "sudo guix pull" and "guix pull" did not help either. The error persists even after running "guix system reconfigure /etc/config.scm" and rebooting. Greetings Diego
bug#30370: guix system init can't find guix-register
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > Hi Diego, > > Diego Nicola Barbato skribis: > >> I tried to install GuixSD on a loop device (/dev/loop1) whith its main >> partition mounted under /mnt like this: >> >> $ guix system init /mnt/etc/config.scm /mnt The above line should actually be: $ sudo guix system init /mnt/etc/config.scm /mnt >> This failed with the following error message: >> >> Betriebssystem unter »/mnt« wird initialisiert … >> In execvp of >> /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin/guix-register: >> Datei oder Verzeichnis nicht gefunden >> copying to '/mnt'... >> guix system: error: fport_write: Datenübergabe unterbrochen (broken pipe) > > I suppose you’re running this in a chroot, right? How did you populate > that chroot? Could it be that it misses some store items? I am not running this in a chroot. I am afraid the explanation of what I was doing was a bit unclear. I was able to reproduce the error with the following steps: $ mkdir test $ cd test $ qemu-img create -f raw test.img 7G $ cfdisk test.img I selected gpt and wrote two partitions: the first one with a size of 1M and type BIOS boot, the second with a size of 7G and type Linux filesystem. $ sudo losetup --partscan --show --find test.img /dev/loop1 $ sudo mkfs.ext4 -L my-root /dev/loop1p2 $ sudo mount /dev/loop1p2 /mnt $ sudo mkdir /mnt/etc $ sudo sh -c "sed 's#/dev/sdX#/dev/loop1#g' ../.config/guix/latest/gnu/system/examples/bare-bones.tmpl > /mnt/etc/config.scm" $ sudo guix system init /mnt/etc/config.scm /mnt The following derivation will be built: /gnu/store/nxy7lfbh8mx7ndrigl1bi3clsm1pnhjh-bootloader-installer.drv /gnu/store/viyn658a9hgsf0g8r4lan24hb0f8515d-system /gnu/store/aaigj9lvdyx2wpyyc40z51mjl7ff1zr5-grub.cfg /gnu/store/m74kz7rvxyzabx6i4p8gd9anws84s45z-grub-2.02 /gnu/store/s4bxrnb584jm0cy5gm3jr8hva341cj2f-bootloader-installer Betriebssystem unter »/mnt« wird initialisiert … In execvp of /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin/guix-register: Datei oder Verzeichnis nicht gefunden guix system: error: failed to register '/gnu/store/2g4dzfcs6nf906d7jl6q225llmnv7krl-linux-libre-4.15' under '/mnt' copying to '/mnt'... It does not matter that it is a loopback device. The same thing happens if I try to install it on a USB flash drive. The issue seems to be that there is no d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/ in my store. All I could find was this: 80k8kz7qk9palbn0ccw7y3fgym8jxlps-guix-0.12.0-10.ba2260d/ Greetings Diego
bug#30370: guix system init can't find guix-register
Hello Guix, I tried to install GuixSD on a loop device (/dev/loop1) whith its main partition mounted under /mnt like this: $ guix system init /mnt/etc/config.scm /mnt This failed with the following error message: Betriebssystem unter »/mnt« wird initialisiert … In execvp of /gnu/store/d4wwx93gqizx132zjk7h1ir7rzph0pig-guix-0.12.0-10.ba2260d/sbin/guix-register: Datei oder Verzeichnis nicht gefunden copying to '/mnt'... guix system: error: fport_write: Datenübergabe unterbrochen (broken pipe) I run GuixSD on an x86_64 machine (commit: a3a932c008d0d9051eb8cdfdcea07ebd7b68b1b3) and the configfile is a copy of the `bare-bones.tmpl' with the target field in the bootloader-configuration changed to "/dev/loop1". Greetings Diego
bug#29881: guix system reconfigure fails if config.scm contains LUKS mapped-devices
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > I’m afraid you’ll have to “rm -rf ~/.cache/guile/ccache” (Guile’s > auto-compilation cache) to work around > e2721a05e7d778bdf845b7cb7a42fd9f76095b69. > > Can you confirm? Yes, running `rm -rf ~/.cache/guile/ccache' fixes the issue. Thanks. Diego
bug#29881: guix system reconfigure fails if config.scm contains LUKS mapped-devices
Hello Guix, When running `guix system reconfigure /etc/config.scm' as root I get the following error: guix system: error: failed to load '/etc/config.scm': /etc/config.scm:24:9: /etc/config.scm:24:9: In procedure allocate-struct: Wrong type argument in position 2: 3 This error appears for the first time in commit 4ca90ff5976434a2b6e758df38df54387ae70c1b. On line 24 of my config file I have declared a mapped device of type luks-device-mapping. If the config file does not contain any mapped-devices declaration `guix system reconfigure' works as expected (checked in a VM). I run GuixSD on a x86_64 machine. Greetings Diego N. Barbato
bug#29516: Maxima fails to build
Mark H Weaver writes: > Diego Nicola Barbato writes: > >> Leo Famulari writes: >> >>> On Fri, Dec 01, 2017 at 11:53:01AM +0100, Diego Nicola Barbato wrote: >>>> `guix build maxima' fails during the `check' phase with the following >>>> output: >>> >>> Thanks for your report! > > FYI, the Maxima builds started failing after the recent upgrade to > 'gcl'. I raised the issue here: > > https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00341.html > > The person who upgraded 'gcl' first said that he could reproduce the > build failure locally, and then said that he couldn't. I'm not sure > what happened there. > > Mark This seems to be quite a strange issue indeed: Out of curiosity I tried the same thing in a VM (guix system vm-image) and even though it is the same architecture (x86_64) and the same commit (e2721a05e7d778bdf845b7cb7a42fd9f76095b69) guix consistently succeeds to build maxima in the VM while it consistently fails to build on my laptop. I also tried building with only one core on my laptop and running the VM with two cores (qemu-system-x86_64 -smp cores=2) with the same result. `guix build maxima' only fails on the VM when I run it with `--rounds=2' because the outputs differ. Diego
bug#29516: Maxima fails to build
Leo Famulari writes: > On Fri, Dec 01, 2017 at 11:53:01AM +0100, Diego Nicola Barbato wrote: >> `guix build maxima' fails during the `check' phase with the following >> output: > > Thanks for your report! > >> Testsuite summary for maxima 5.41.0 >> >> # TOTAL: 1 >> # PASS: 0 >> # SKIP: 0 >> # XFAIL: 0 >> # FAIL: 1 >> # XPASS: 0 >> # ERROR: 0 >> >> See tests/test-suite.log >> > > Can you retry the build with '--keep-failed' and send the > 'tests/test-suite.log' file that will be in the directory of the failed > build? As requested I ran `build' with `--keep-failed'. This is the resulting log file: = maxima 5.41.0: tests/test-suite.log = # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: gcl-test.sh = Maxima 5.41.0 http://maxima.sourceforge.net using Lisp GNU Common Lisp (GCL) GCL 2.6.12 Distributed under the GNU Public License. See the file COPYING. Dedicated to the memory of William Schelter. The function bug_report() provides bug reporting information. (%i1) run_testsuite() Running tests in rtest_rules: 103/103 tests passed Running tests in rtestnset: 601/601 tests passed Running tests in rtest1: 186/186 tests passed (not counting 3 expected errors) Running tests in rtest1a: 34/34 tests passed (not counting 1 expected errors) Running tests in rtest2: 268/268 tests passed (not counting 2 expected errors) Running tests in rtest4: 93/93 tests passed Running tests in rtest5: 83/83 tests passed Running tests in rtest6: 39/39 tests passed Running tests in rtest6a: 62/62 tests passed Running tests in rtest6b: 27/27 tests passed Running tests in rtest7: 85/85 tests passed Running tests in rtest9: 89/89 tests passed Running tests in rtest9a: 76/76 tests passed Running tests in rtest10: 62/62 tests passed (not counting 2 expected errors) Running tests in rtest11: 243/243 tests passed (not counting 3 expected errors) Running tests in rtest13: 23/23 tests passed Running tests in rtest13s: 17/17 tests passed Running tests in rtest14: 418/418 tests passed Running tests in rtest15: ** Problem 55 *** Input: compile(f) Result: warning: encountered undefined variable qwerty in translation. Compiling /tmp/gazonk_4051_0.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_0.o. error-catch This differed from the expected result: [f] ** Problem 61 *** Input: compile(f) Result: Compiling /tmp/gazonk_4051_1.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_1.o. error-catch This differed from the expected result: [f] ** Problem 67 *** Input: compile(f) Result: Compiling /tmp/gazonk_4051_2.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_2.o. error-catch This differed from the expected result: [f] ** Problem 73 *** Input: compile(f) Result: warning: encountered undefined variable qwerty in translation. Compiling /tmp/gazonk_4051_3.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_3.o. error-catch This differed from the expected result: [f] ** Problem 79 *** Input: compile(f) Result: warning: encountered undefined variable qwerty in translation. Compiling /tmp/gazonk_4051_4.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_4.o. error-catch This differed from the expected result: [f] ** Problem 85 *** Input: compile(f) Result: Compiling /tmp/gazonk_4051_5.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_5.o. error-catch This differed from the expected result: [f] ** Problem 91 *** Input: compile(f) Result: Compiling /tmp/gazonk_4051_6.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_4051_6.o. error-catch This differed from the expected result: [f] ** Problem 164 *** Input: compile(aref) Result: Compiling /tmp/gazonk_4051_7.lsp. End of Pass 1. End of Pass 2. OPTIMIZE levels: Safety=2, Space=3, Speed=3 Finished compiling /tmp/gazonk_40
bug#29516: Maxima fails to build
Hello Guix, `guix build maxima' fails during the `check' phase with the following output: starting phase `check' Making check in admin make[1]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/admin' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/admin' Making check in crosscompile-windows make[1]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/crosscompile-windows' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/crosscompile-windows' Making check in src make[1]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/src' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/src' Making check in lisp-utils make[1]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/lisp-utils' make[1]: Nothing to be done for 'check'. make[1]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/lisp-utils' Making check in tests make[1]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' make check-TESTS make[2]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' make[3]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' sed <"test.sh.in" >"gcl-test.sh" \ -e 's#!LOCAL_MAXIMA!#/gnu/store/kpxi8h3669afr9r1bgvaf9ij3y4wdyyn-bash-minimal-4.4.12/bin/sh ../maxima-local#' \ -e 's#!LISPNAME!#gcl#' \ -e 's#!OUTPUT_LOG!#../tests/gcl.log#' chmod a+x "gcl-test.sh" FAIL: gcl-test.sh make[4]: Entering directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' make[4]: Nothing to be done for 'all'. make[4]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' Testsuite summary for maxima 5.41.0 # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See tests/test-suite.log make[3]: *** [Makefile:558: test-suite.log] Error 1 make[3]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' make[2]: *** [Makefile:666: check-TESTS] Error 2 make[2]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' make[1]: *** [Makefile:792: check-am] Error 2 make[1]: Leaving directory '/tmp/guix-build-maxima-5.41.0.drv-0/maxima-5.41.0/tests' make: *** [Makefile:457: check-recursive] Error 1 phase `check' failed after 261.2 seconds builder for `/gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv' failed with exit code 1 @ build-failed /gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv - 1 builder for `/gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv' failed with exit code 1 guix build: error: build failed: build of `/gnu/store/cmz95fkz1mc7nb3yxch4x83iaxml6gzs-maxima-5.41.0.drv' failed I am running GuixSD on a x86_64 machine (commit: 9ce07f2dbafe068aea81e79decc4cfc146a48259). The x86_64 version also failed to build on hydra.gnu.org (https://hydra.gnu.org/build/2361466). Greetings Diego
bug#29212: XLockMore displays wrong time
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > Since GuixSD provides /etc/localtime already, we can actually unset TZ. > And when we do so, setuid binaries simply honor /etc/localtime and don’t > go searching for timezone data elsewhere, and they see the right time. > > Can you confirm that: > > (unset TZ; xlock) > > works for you? Yes, it displays the correct time. Thanks, Diego
bug#29211: XScreenSaver does not recognise password
Apparently this is not a bug.
bug#29211: XScreenSaver does not recognise password
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > Hi Diego, > > Diego Nicola Barbato skribis: > >> When I lock my screen with XScreenSaver by first running >> `xscreensaver &' and then `xscreensaver-command --lock' I am unable to >> unlock the screen by entering my password. This happens even though I >> have added `(screen-locker-service xscreensaver "xscreensaver")' to my >> services in my `config.scm'. >> I run StumpWM on GuixSD. >> >> Greetings, >> >> Diego >> >> P.S. I am not sure whether this is relevant but this bug seems to >> coincide with a change in the time displayed on the unlock dialog: It >> no longer displays the wrong time (two hours behind the output of >> `date') and the format has changed from a 24h format to one using AM and >> PM. > > To me that suggests ‘xscreensaver’ is taken from your profile (or the > global profile) instead of being taken from > /run/setuid-programs/xscreensaver. > > What does “type -P xscreensaver” display? > > Thanks, > Ludo’. You are right. `type -P xscreensaver' returns `/home/diego/.guix-profile/bin/xscreensaver'. And if i run `/run/setuid-programs/xscreensaver &' instead of `xscreensaver &' everything works as expected. Apparently my setup should never have worked in the first place. The fact that it did until about two weeks ago led me to think this was a bug. Thanks, Diego
bug#29212: XLockMore displays wrong time
Hello Guix, XLockMore (as invoked by the command `xlock') displays the wrong time on the lock screen. Instead of honouring the timezone set in `config.scm' (as do other programs e.g. the `date' command) it displays UTC. Greetings Diego
bug#29211: XScreenSaver does not recognise password
Hello Guix, When I lock my screen with XScreenSaver by first running `xscreensaver &' and then `xscreensaver-command --lock' I am unable to unlock the screen by entering my password. This happens even though I have added `(screen-locker-service xscreensaver "xscreensaver")' to my services in my `config.scm'. I run StumpWM on GuixSD. Greetings, Diego P.S. I am not sure whether this is relevant but this bug seems to coincide with a change in the time displayed on the unlock dialog: It no longer displays the wrong time (two hours behind the output of `date') and the format has changed from a 24h format to one using AM and PM.
bug#28692: Emacs fails to display images
Marius Bakke writes: > Diego Nicola Barbato writes: > >> Apparently this was a known bug in ImageMagick 6.9.9-15 (and 6.9.9-17) >> (https://github.com/ImageMagick/ImageMagick/issues/825). It has been >> fixed in version 6.9.9-18. > > Hello! I just pushed an update to 6.9.9-18, can you verify that it > works? > > Thanks for the report! Hello! I upgraded Emacs and everything works as expected. Thanks for fixing it!
bug#28692: Emacs fails to display images
Hello Ludo, l...@gnu.org (Ludovic Courtès) writes: > Hello Diego, > > Diego Nicola Barbato skribis: > >> Several of emacs image related features have stopped working properly: >> * Eww does not render images showing empty squares instead. >> * When visiting an image in a buffer and pressing n to visit the next >> image the next image is either not displayed at all (showing an empty >> square instead) or a thumbnail sized version is displayed. >> * Transformations such as "Fit to Window Width" or "Rotate Image" do not >> work at all. The following error message is displayed instead: >> ImageMagick error: no decode delegate for this image format `PBM' @ >> error/constitute.c/ReadImage/504 >> (This happens with all image formats not just .pbm) > > Indeed, I experience this with DocView as well (when resizing), which > leads to: > > ImageMagick error: no decode delegate for this image format `PNG' @ > error/constitute.c/ReadImage/504 > > Could it be a CLI change in ImageMagick? The package was upgraded in > 87a9c53b7ca08bd490c94fe5579c3f26c19be78c. > > Ludo’. I believe the bug was introduced in 030030f4416b54285dcdd58bddb863c0e6bda4c4. It appears to be a known bug in ImageMagick (https://github.com/ImageMagick/ImageMagick/issues/825), which was already present in version 6.9.9-15. It has been fixed in version 6.9.9-18 (https://github.com/ImageMagick/ImageMagick/blob/ImageMagick-6/ChangeLog). Diego
bug#28692: Emacs fails to display images
Apparently this was a known bug in ImageMagick 6.9.9-15 (and 6.9.9-17) (https://github.com/ImageMagick/ImageMagick/issues/825). It has been fixed in version 6.9.9-18.
bug#28692: Emacs fails to display images
Hello!
Several of emacs image related features have stopped working properly:
* Eww does not render images showing empty squares instead.
* When visiting an image in a buffer and pressing n to visit the next
image the next image is either not displayed at all (showing an empty
square instead) or a thumbnail sized version is displayed.
* Transformations such as "Fit to Window Width" or "Rotate Image" do not
work at all. The following error message is displayed instead:
ImageMagick error: no decode delegate for this image format `PBM' @
error/constitute.c/ReadImage/504
(This happens with all image formats not just .pbm)
This is independent of any init file as it still happens if emacs is run
with the -Q flag.
Everything works as it should if I roll back to the version from
2017-09-22.
I am running GuixSD on an x86-64 machine with the following config:
;; This is an operating system configuration file
;; for a "desktop" setup with StumpWM and EXWM where
;; the root partition is encrypted with LUKS.
(use-modules (gnu) (gnu packages) (gnu system nss))
(use-service-modules avahi dbus desktop networking xorg)
(use-package-modules certs emacs gnome lisp xdisorg)
(operating-system
(host-name <>)
(timezone <>)
(locale <>)
;; Assuming /dev/sda is the target hard disk, and "osiris"
;; is the label of the target root file system.
(bootloader (grub-configuration (target "/dev/sda")
(timeout 1)))
;; Specify a mapped device for the encrypted root partition.
;; The UUID is that returned by 'cryptsetup luksUUID'.
(mapped-devices
(list (mapped-device
(source (uuid <>))
(target <>)
(type luks-device-mapping
(file-systems (cons* (file-system
(device <>)
(title 'label)
(mount-point "/")
(type "ext4"))
(file-system
(device <>)
(title 'label)
(mount-point "/home")
(type "ext4")
(dependencies mapped-devices))
%base-file-systems))
(swap-devices '("/dev/sda2"))
(users (cons (user-account
(name <>)
(comment <>)
(group "users")
(supplementary-groups '("lp"
"wheel" "netdev"
"audio" "video"))
(home-directory <>))
%base-user-accounts))
;; This is where we specify system-wide packages.
(packages (cons* nss-certs ;for HTTPS access
;; gvfs ;for user mounts
sbcl-stumpwm ;StumpWM window manager
emacs emacs-exwm ;emacs window manager
%base-packages))
;; Add desktop services to %base-services. This is a modified
;; version of %desktop-services with fewer services and wicd
;; instead of network-manager. Also adding tor, xscreensaver,
;; bluetooth and a <> console keymap.
(services (cons* (tor-service)
;; Login service
(slim-service)
;; Screen lockers are a pretty useful thing
;; and these are small.
(screen-locker-service xlockmore "xlock")
(screen-locker-service xscreensaver "xscreensaver")
;; The D-Bus clique.
(bluetooth-service)
(avahi-service)
(wicd-service)
(udisks-service)
(upower-service)
(colord-service)
(geoclue-service)
(polkit-service)
(elogind-service)
(dbus-service)
(ntp-service)
;; Add swiss german keymap
(console-keymap-service <>)
%base-services))
;; Allow resolution of '.local' host names with mDNS.
(name-service-switch %mdns-host-lookup-nss))
bug#27572: simultaneous installation of python2 and python3 fails
Hello Ludo, Thanks for your reply. l...@gnu.org (Ludovic Courtès) writes: > Hello Diego, > > Diego Nicola Barbato skribis: > >> When running the command "guix pull && guix package -i python@2 python" >> instead of installing the latest version of python2 and python3, as it >> used to do until about four weeks ago, guix gives following error >> message (hash values replaced with ...): >> >> guix package: error: profile contains conflicting entries for python:out >> guix package: error: first entry: python@2.7.13:out >> /gnu/store/...-python-2.7.13 >> guix package: error: second entry: python@3.5.3:out >> /gnu/store/...-python-3.5.3 > > Indeed, Guix now refuses to install two different versions or variants > of the same package since in general they would conflict. > > In this particular case, they do not actually conflict, I think, since > python@3 provides executables prefixed by “3” whereas python@2 does not. > > Perhaps we should rename “python” to “python2” or something like that? > > In the meantime, I recommend using separate profiles for your Python 2 > and Python 3 development environments. Is that a viable option for you? Using separate profiles seems like a reasonable option. I also tried using guix environment with the --ad-hoc flag. > Thanks, > Ludo’. Greetings Diego
bug#27572: simultaneous installation of python2 and python3 fails
When running the command "guix pull && guix package -i python@2 python"
instead of installing the latest version of python2 and python3, as it
used to do until about four weeks ago, guix gives following error
message (hash values replaced with ...):
guix package: error: profile contains conflicting entries for python:out
guix package: error: first entry: python@2.7.13:out
/gnu/store/...-python-2.7.13
guix package: error: second entry: python@3.5.3:out
/gnu/store/...-python-3.5.3
This error could be reproduced in a VM created with guix system vm-image
and following config file:
(use-modules (gnu) (gnu packages) (gnu system nss))
(use-service-modules desktop xorg)
(use-package-modules certs gnome xdisorg lisp)
(operating-system
(host-name "Test")
(timezone "Europe/Zurich")
(locale "de_CH.UTF-8")
(bootloader (grub-configuration (device "/dev/sda")
(timeout 1)))
(file-systems (cons (file-system
(mount-point "/")
(device "/dev/sda1")
(type "ext4"))
%base-file-systems))
(users (cons (user-account
(name "user1")
(comment "User")
(group "users")
(supplementary-groups '("wheel" "audio" "video"))
(home-directory "/home/user1"))
%base-user-accounts))
(packages (cons* nss-certs
sbcl-stumpwm (list sbcl-stumpwm "lib")
%base-packages))
(services (cons* (screen-locker-service xscreensaver "xscreensaver")
(console-keymap-service "de_CH-latin1")
%desktop-services))
(name-service-switch %mdns-host-lookup-nss))
