bug#42553: python-gevent is broken on i686-linux (tests fail)
On Thu Jul 14, 2022 at 4:40 AM CEST, Maxim Cournoyer wrote: > Finally disabled the test in 692c2ad327. > > Closing. Are we sure this is the appropriate course of action? It sounds like the test is exposing a bug in our packaging that might affect users of python-gevent. It might be better to have the package build than not, of course, but still we might want to investigate why the test fails. Regards, Kuba
bug#42342: Wine64 segfaults (5.12/staging)
On Sun, Aug 09, 2020 at 04:03:07PM +0200, Pierre Neidhardt wrote: > OK, I think I got it. I had to have _both_ wine and wine64 (staging or > not) in my profile. Interesting. Perhaps we should merge the two packages, then? We'd need to take care to make it work right on i686-linux, but I don't think that's unsurmountable... > Previously, the "wine" executable (for 32-bit apps) used to work when > wine64 alone was in the profile. Now it looks like we need both. Any > idea what changed? Perhaps loading 32-bit programs with the wine64 wasn't supposed to work in the first place, and we were relying on some implementation quirk? Alternatively, cross-compiling from 64 to 32 bit is less tested by upstream than compiling natively on 64 or 32 bit, and we're hitting an upstream bug? Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#37013: LyX can not find refstyle.sty
It seems that this issue is not caused by any behavior of LyX, since
merely adding LyX to a profile breaks the existing texlive installation:
~/tmp$ cat test.tex
\documentclass[a4paper]{article}
\usepackage{url}
\begin{document}
\end{document}
~/tmp$ guix environment --pure --ad-hoc texlive -- pdflatex test.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded
format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2018-12-01>
(/gnu/store/wyp70a5a4spmj1g2wvm27d5968sssvwq-texlive-texmf-20190410/share/texmf
-dist/tex/latex/base/article.cls
Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
(/gnu/store/wyp70a5a4spmj1g2wvm27d5968sssvwq-texlive-texmf-20190410/share/texmf
-dist/tex/latex/base/size10.clo))
(/gnu/store/wyp70a5a4spmj1g2wvm27d5968sssvwq-texlive-texmf-20190410/share/texmf
-dist/tex/latex/url/url.sty)
No file test.aux.
(./test.aux) )
No pages of output.
Transcript written on test.log.
~/tmp$ guix environment --pure --ad-hoc texlive lyx -- pdflatex test.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.20 (TeX Live 2019) (preloaded
format=pdflatex)
restricted \write18 enabled.
entering extended mode
(./test.tex
LaTeX2e <2018-12-01>
(/gnu/store/xq0b0mgz5h6invz9fh13n29mb2jfdb0s-texlive-union-51265/share/texmf-dist/tex/latex/base/article.cls
Document Class: article 2018/09/03 v1.4i Standard LaTeX document class
(/gnu/store/xq0b0mgz5h6invz9fh13n29mb2jfdb0s-texlive-union-51265/share/texmf-dist/tex/latex/base/size10.clo))
! LaTeX Error: File `url.sty' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: sty)
Enter file name:
====
Regards,
Jakub Kądziołka
signature.asc
Description: PGP signature
bug#42342: Wine64 segfaults (5.12/staging)
On Tue, Jul 28, 2020 at 05:58:08PM +0200, Pierre Neidhardt wrote: > Cc-ing to Tobias and Jakub. > > -- > Pierre Neidhardt > https://ambrevar.xyz/ Hi, I can't reproduce this. I usually use 32-bit wine, so when it complained about the bitness of the wineprefix, I did $ mv ~/.wine ~/.wine32 then $ guix environment --ad-hoc wine64 -- wine64 regedit fired up the registry editor just fine. Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#42553: python-gevent is broken on i686-linux (tests fail)
The package python-gevent doesn't build on i686-linux, the following
test failure occurs:
==
FAIL: test_unlink (gevent.tests.test__core_stat.TestCoreStat)
--
Traceback (most recent call last):
File
"/tmp/guix-build-python-gevent-20.6.2.drv-0/gevent-20.6.2/build/lib.linux-i686-3.8/gevent/testing/errorhandler.py",
line 47, in wrapper
return method(self, *args, **kwargs)
File
"/tmp/guix-build-python-gevent-20.6.2.drv-0/gevent-20.6.2/build/lib.linux-i686-3.8/gevent/testing/errorhandler.py",
line 34, in wrapper
return method(self, *args, **kwargs)
File
"/tmp/guix-build-python-gevent-20.6.2.drv-0/gevent-20.6.2/build/lib.linux-i686-3.8/gevent/testing/testcase.py",
line 182, in wrapper
return method(self, *args, **kwargs)
File
"/tmp/guix-build-python-gevent-20.6.2.drv-0/gevent-20.6.2/build/lib.linux-i686-3.8/gevent/tests/test__core_stat.py",
line 114, in test_unlink
self._check_attr('attr', True)
File
"/tmp/guix-build-python-gevent-20.6.2.drv-0/gevent-20.6.2/build/lib.linux-i686-3.8/gevent/tests/test__core_stat.py",
line 66, in _check_attr
self.assertIsNone(x, name)
AssertionError: os.stat_result(st_mode=997, st_ino=0,
st_dev=74395714104328192, st_nlink=3, st_uid=0, st_gid=0,
st_size=6851593278123409408, st_atime=1595260873, st_mtime=0, st_ctime=-2) is
not None : attr
--
Ran 48 tests in 1.238s
I have created a simple standalone script based on this test case:
import os, tempfile, gevent
fd, path = tempfile.mkstemp('.test')
os.close(fd)
hub = gevent.get_hub()
watcher = hub.loop.stat(path, interval=-1)
hub.loop.update_now()
gevent.spawn_later(0.5, os.unlink, path)
hub.wait(watcher)
print(watcher.attr)
print(watcher.prev)
After adding a (delete 'check) to python-gevent's arguments, we observe
the following:
% ./pre-inst-env guix environment --ad-hoc python python-gevent -- python3
~/tmp/gevent-test.py
None
os.stat_result(st_mode=33152, st_ino=44162375, st_dev=2052, st_nlink=1,
st_uid=1000, st_gid=1000, st_size=0, st_atime=1595787602, st_mtime=1595787602,
st_ctime=1595787602)
% ./pre-inst-env guix environment --system=i686-linux --ad-hoc python
python-gevent -- python3 ~/tmp/gevent-test.py
os.stat_result(st_mode=1000, st_ino=0, st_dev=189675956338688000,
st_nlink=1000, st_uid=0, st_gid=0, st_size=6853855360088801280,
st_atime=1595787555, st_mtime=0, st_ctime=-2)
os.stat_result(st_mode=33152, st_ino=2052, st_dev=2052, st_nlink=1,
st_uid=1000, st_gid=1000, st_size=17592186044416, st_atime=1595787555,
st_mtime=1595787555, st_ctime=0)
Namely, the i686 variant returns entirely bogus values.
I have tried reproducing this in a Guix-less environment in a Docker
container based on the i386/debian:bullseye image, but I haven't had any
luck.
Regards,
Jakub Kądziołka
signature.asc
Description: PGP signature
bug#42164: Combining file-append with gexps results in incomprehensible errors
Consider this minimal operating-system definition:
(use-modules (gnu))
(use-package-modules gcc)
(operating-system
(host-name "test")
(timezone "UTC")
(bootloader (bootloader-configuration
(bootloader grub-efi-bootloader)
(target "/boot/efi")))
(file-systems (cons*
(file-system
(device (file-system-label "root"))
(mount-point "/")
(type "ext4"))
%base-file-systems))
(packages '())
(services (cons*
(service special-files-service-type
`(("/lib64" ,(directory-union "rustup-libs"
(list
(file-append glibc "/lib")
(file-append #~#$gcc:lib "/lib"))
%base-services)))
I would expect this way of specifying a specific output of a package to
work, but it results in the following error:
ice-9/boot-9.scm:1515:18: object is not an exception of the right type
#<&gexp-input-error input: #:lib> 7f06c6b06990>> #
This also happens when I omit the directory-union:
(service special-files-service-type
`(("/lib64" ,(file-append #~#$gcc:lib "/lib"
What *does* work, is this variant with string-append:
(service special-files-service-type
`(("/lib64" ,#~(string-append #$gcc:lib "/lib"
However, using it in the directory-union breaks again:
(service special-files-service-type
`(("/lib64" ,(directory-union "rustup-libs"
(list
(file-append glibc "/lib")
#~(string-append #$gcc:lib "/lib"))
ERROR: In procedure opendir:
Wrong type (expecting string): (string-append
"/gnu/store/mdxmdhrlkgdik6ay9pzmmy8mjcbibpwb-gcc-7.5.0-lib" "/lib")
builder for `/gnu/store/p5hf7hqxn35fgsb75s5i7326vyzb8jkr-rustup-libs.drv'
failed with exit code 1
I have figured out that the following does work:
(service special-files-service-type
`(("/lib64" ,#~(directory-union "rustup-libs"
(list
(string-append #$glibc "/lib")
(string-append #$gcc:lib "/lib"))
However, I would expect the other variants to work as well. The
documentation and error messages are lacking in this regard.
Regards,
Jakub Kądziołka
signature.asc
Description: PGP signature
bug#41872: emacs-irony-mode fails to build on LLVM 10
On Tue, Jun 16, 2020 at 12:13:52PM +0200, Ludovic Courtès wrote: > Hi, > > Alternatively, we can try building clang@10 with the flags Pierre > mentioned recently on this list so that we’re only building shared > libraries; that should take up less space. I'm currently building clang@10 with -DCLANG_LINK_CLANG_DYLIB=ON, but unfortunately this flag requires -DLLVM_LINK_LLVM_DYLIB=ON, and it doesn't work if LLVM wasn't build with that same flag. Unfortunately, LLVM is a reverse-dep to the entire mesa mess, so this approach would require a trip through staging (unless we create a separate llvm-for-mesa package - would that be reasonable?). Thoughts? Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#41872: emacs-irony-mode fails to build on LLVM 10
I was trying to update the default LLVM.
diff --git a/gnu/packages/llvm.scm b/gnu/packages/llvm.scm
index 11e4cfbe4c..b0e80507f4 100644
--- a/gnu/packages/llvm.scm
+++ b/gnu/packages/llvm.scm
@@ -527,10 +527,10 @@ output), and Binutils.")
(make-clang-toolchain clang-9))
;; Default LLVM and Clang version.
-(define-public llvm llvm-9)
-(define-public clang-runtime clang-runtime-9)
-(define-public clang clang-9)
-(define-public clang-toolchain clang-toolchain-9)
+(define-public llvm llvm-10)
+(define-public clang-runtime clang-runtime-10)
+(define-public clang clang-10)
+(define-public clang-toolchain clang-toolchain-10)
(define-public llvm-8
(package
With the help of `guix refresh', I have identified all packages that
depended on LLVM 9 and will now potentially be using LLVM 10. Among
those is emacs-irony-mode-server, which fails to build with the
following error:
CMake Error at
/gnu/store/4ml806jam2af7f8i8sg8xi7b4mw81x9g-clang-10.0.0/lib/cmake/clang/ClangTargets.cmake:627
(message):
The imported target "clangApplyReplacements" references the file
"/gnu/store/4ml806jam2af7f8i8sg8xi7b4mw81x9g-clang-10.0.0/lib/libclangApplyReplacements.a"
but this file does not exist. Possible reasons include:
* The file was deleted, renamed, or moved to another location.
* An install or uninstall procedure did not complete successfully.
* The installation package was faulty and contained
"/gnu/store/4ml806jam2af7f8i8sg8xi7b4mw81x9g-clang-10.0.0/lib/cmake/clang/ClangTargets.cmake"
but not all the files it references.
Call Stack (most recent call first):
/gnu/store/4ml806jam2af7f8i8sg8xi7b4mw81x9g-clang-10.0.0/lib/cmake/clang/ClangConfig.cmake:18
(include)
src/CMakeLists.txt:4 (find_package)
-- Configuring incomplete, errors occurred!
See also
"/tmp/guix-build-emacs-irony-mode-server-1.4.0.drv-0/source/CMakeFiles/CMakeOutput.log".
command "cmake" "server"
"-DCMAKE_INSTALL_PREFIX=/gnu/store/5clyjcgw8g9jhryhk8bhljg950ijmwm4-emacs-irony-mode-server-1.4.0"
failed with status 1
builder for
`/gnu/store/qiiqbbzpigs7lnywplbwjdsh4qc2ic94-emacs-irony-mode-server-1.4.0.drv'
failed with exit code 1
The ClangTargets.cmake file for LLVM 10 gained ApplyReplacements in a
list of libraries provided by clang, but Guix removes these libraries:
;; Remove MiBs of .a files coming from
;; 'clang-tools-extra'.
(for-each (lambda (component)
(delete-file
(string-append lib "/libclang"
component ".a")))
'("ApplyReplacements"
"ChangeNamespace"
"Daemon"
"DaemonTweaks"
"Doc"
"IncludeFixer"
"IncludeFixerPlugin"
"Move"))
The code was introduced in this commit:
commit 77a87ad4aceed9d89d615540e0fd147e3a8b2f64
Author: Ludovic Courtès
Date: Thu May 28 11:46:59 2020 +0200
gnu: clang: Build 'clang-tools-extra'.
* gnu/packages/llvm.scm (clang-from-llvm): Add #:tools-extra.
Add 'output' field. In 'inputs', add TOOLS-EXTRA when it's given.
In 'arguments', add 'add-tools-extra' and 'move-extra-tools' phases when
TOOLS-EXTRA is given.
I don't know cmake nearly well enough to fix this.
Regards,
Jakub Kądziołka
signature.asc
Description: PGP signature
bug#41796: Grafts don't handle outputs other than out
$ cat test.scm
(use-modules
(guix packages)
(guix build-system trivial))
(define-public core-pkg
(package
(name "core-pkg")
(version "1.0")
(replacement core-pkg/fixed)
(source #f)
(outputs '("out" "lib"))
(build-system trivial-build-system)
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let ((outdir (assoc-ref %outputs "out"))
(libdir (assoc-ref %outputs "lib")))
(mkdir-p outdir)
(mkdir-p libdir)
#t
(synopsis #f)
(description #f)
(home-page #f)
(license #f)))
(define-public core-pkg/fixed
(package
(inherit core-pkg)
(version "1.1")))
(package
(name "other-pkg")
(version "4.2")
(source #f)
(build-system trivial-build-system)
(inputs
`(("core-pkg" ,core-pkg)
("core-pkg:lib" ,core-pkg "lib")))
(arguments
`(#:modules ((guix build utils))
#:builder
(begin
(use-modules (guix build utils))
(let ((outdir (assoc-ref %outputs "out")))
(mkdir-p outdir)
(with-output-to-file (string-append outdir "/hello")
(lambda ()
(display (assoc-ref %build-inputs "core-pkg"))
(newline)
(display (assoc-ref %build-inputs "core-pkg:lib"))
(newline)))
#t
(synopsis #f)
(description #f)
(home-page #f)
(license #f))
~$ cat `guix build --no-offload -f test.scm`/hello
/gnu/store/pmz07rzm63z02lkyyldsw3srf98h01y2-core-pkg-1.1
/gnu/store/pivsji8qfpln4i4v0f5v5cjmzakmcmvg-core-pkg-1.0-lib
Expected output: the second line contains -core-pkg-1.1-lib.
Regards,
Jakub Kądziołka
signature.asc
Description: PGP signature
bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
Hi, I encountered a similar error message today, but it worked fine after retrying. After digging around in /var/log/guix/drvs, I found these lines in an appropriately-timestamped log file: substitute: guix substitute: warning: ci.guix.gnu.org: connection failed: Connection timed out @ build-started /gnu/store/klyq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv - x86_64-linux /var/log/guix/drvs/kl//yq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv.bz2 3907994 @ build-succeeded /gnu/store/klyq05c1q8jzwnwrlmvy4ma6m2h6hbk0-compute-guix-derivation.drv - I do recall seeing the Connection timed out message, I'd even say it's probably the reason why I decided to retry the pull without much investigation. Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#41596: [staging] 'librsvg-next' build failure
On Fri, May 29, 2020 at 03:17:51PM +0200, Marius Bakke wrote: > On the 'staging' branch, "librsvg-next" (a dependency of GNOME) fails to > compile the 'xml-rs' Rust crate: > > --8<---cut here---start->8--- >Compiling xml-rs v0.8.1 > error[E0658]: `cfg(doctest)` is experimental and subject to change > --> > /tmp/guix-build-librsvg-2.46.4.drv-0/librsvg-2.46.4/vendor/rust-xml-rs-0.8.1.tar.gz/src/lib.rs:9:7 > | > 9 | #[cfg(doctest)] > | ^^^ > | > = note: for more information, see > https://github.com/rust-lang/rust/issues/62210 That's a feature that was stabilized in Rust 1.40. I have a WIP patch that updates Rust upto 1.43.1, but it's blocked on a LLVM 9 patch backport I haven't had time to prepare yet. I won't have the time to look into it properly right now, but here are the relevant links: https://github.com/rust-lang/llvm-project/commit/7d5e7c023053660ffe494d72ce471e48ecc7f49b https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959877 https://github.com/rust-lang/llvm-project/pull/43 Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#41491: docker fails to build on foreign Debian system
I am trying to build the `docker' package on a foreign distro. Specifically, Debian sid. This results in the following test failures: -- === [31mFailed[0m === [31mFAIL[0m: daemon/graphdriver/quota TestBlockDev/testBlockDevQuotaDisabled (0.03s) --- FAIL: TestBlockDev/testBlockDevQuotaDisabled (0.03s) projectquota_test.go:83: assertion failed: error is not nil: exit status 1: mount failed: mount: /tmp/guix-build-docker-19.03.7.drv-0/xfs-mountPoint-325789281: mount failed: Operation not permitted. === [31mFAIL[0m: daemon/graphdriver/quota TestBlockDev/testBlockDevQuotaEnabled (0.02s) --- FAIL: TestBlockDev/testBlockDevQuotaEnabled (0.02s) projectquota_test.go:83: assertion failed: error is not nil: exit status 1: mount failed: mount: /tmp/guix-build-docker-19.03.7.drv-0/xfs-mountPoint-054602316: mount failed: Operation not permitted. === [31mFAIL[0m: daemon/graphdriver/quota TestBlockDev/testSmallerThanQuota (0.01s) --- FAIL: TestBlockDev/testSmallerThanQuota (0.01s) projectquota_test.go:83: assertion failed: error is not nil: exit status 1: mount failed: mount: /tmp/guix-build-docker-19.03.7.drv-0/xfs-mountPoint-879061307: mount failed: Operation not permitted. === [31mFAIL[0m: daemon/graphdriver/quota TestBlockDev/testBiggerThanQuota (0.01s) --- FAIL: TestBlockDev/testBiggerThanQuota (0.01s) projectquota_test.go:83: assertion failed: error is not nil: exit status 1: mount failed: mount: /tmp/guix-build-docker-19.03.7.drv-0/xfs-mountPoint-487602526: mount failed: Operation not permitted. === [31mFAIL[0m: daemon/graphdriver/quota TestBlockDev/testRetrieveQuota (0.01s) --- FAIL: TestBlockDev/testRetrieveQuota (0.01s) projectquota_test.go:83: assertion failed: error is not nil: exit status 1: mount failed: mount: /tmp/guix-build-docker-19.03.7.drv-0/xfs-mountPoint-717635877: mount failed: Operation not permitted. === [31mFAIL[0m: daemon/graphdriver/quota TestBlockDev (0.38s) projectquota_test.go:50: meta-data=/tmp/guix-build-docker-19.03.7.drv-0/xfs-image973358730 isize=256 agcount=4, agsize=4096 blks = sectsz=512 attr=2, projid32bit=1 = crc=0finobt=0, sparse=0, rmapbt=0 = reflink=0 data = bsize=4096 blocks=16384, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1 log =internal log bsize=4096 blocks=853, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 -- This suggests that there's an issue with permissions. I recalled that Debian ships a custom kernel patch that disables unprivileged namespaces by default. However, after setting kernel.unprivileged_userns_clone = 1 the problem persisted. I am attaching the full build log. x1kdy6a8qnigmlp045m81rqhw8dl9w-docker-19.03.7.drv.bz2 Description: Binary data signature.asc Description: PGP signature
bug#39930: python-virtualenv produces a broken pip when network is available
I am encountering a weird error: | ~/tmp$ guix environment --pure --ad-hoc python python-virtualenv coreutils | ~/tmp% pip3 --version | pip 19.0.3 from /gnu/store/az4z48nrlyhrpkj2njs6xz3p0mj71wi7-profile/lib/python3.7/site-packages/pip (python 3.7) | ~/tmp% virtualenv venv | Using base prefix '/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4' | New python executable in /home/kuba/tmp/venv/bin/python | Installing setuptools, pip, wheel... | done. | ~/tmp% . venv/bin/activate | (venv) ~/tmp% pip3 --version # or any other command | Traceback (most recent call last): | File "/home/kuba/tmp/venv/bin/pip3", line 7, in | from pip._internal.cli.main import main | ModuleNotFoundError: No module named 'pip._internal.cli.main' Note that unsetting PYTHONPATH helps: | (venv) ~/tmp% PYTHONPATH= pip3 --version | pip 20.0.2 from /home/kuba/tmp/venv/lib/python3.7/site-packages/pip (python 3.7) Similarily, omitting the python package from the environment also helps: | ~/tmp$ guix environment --pure --ad-hoc python-virtualenv coreutils | ~/tmp% virtualenv venv | Using base prefix '/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4' | New python executable in /home/kuba/tmp/venv/bin/python | Installing setuptools, pip, wheel... | done. | ~/tmp% . venv/bin/activate | (venv) ~/tmp% pip3 --version | pip 20.0.2 from /home/kuba/tmp/venv/lib/python3.7/site-packages/pip (python 3.7) Interestingly, even with PYTHONPATH set, everything works in a container started without network access: | ~/tmp$ guix environment --container --ad-hoc python python-virtualenv coreutils | kuba@gravity ~/tmp [env]$ virtualenv venv | Using base prefix '/gnu/store/608bvypsh90c58apvd2cgg3m9l2pwjqn-python-3.7.4' | New python executable in /home/kuba/tmp/venv/bin/python | Installing setuptools, pip, wheel... | done. | kuba@gravity ~/tmp [env]$ . venv/bin/activate | (venv) kuba@gravity ~/tmp [env]$ pip3 --version | pip 19.0.3 from /gnu/store/az4z48nrlyhrpkj2njs6xz3p0mj71wi7-profile/lib/python3.7/site-packages/pip (python 3.7) My guess as to what's happening: virtualenv tries to use a newer pip than is provided by Guix. It then generates an entrypoint appropriate for the pip version it chose and installed into the venv. Unfortunately, the $PYTHONPATH set by Guix overrides virtualenv's mechanism for directing Python to venv/lib/python3.7/site-packages. This makes an entrypoint designed for pip 20.0.2 try to load pip 19.0.3. pip's main function was relocated between releases, making this problematic. I am not sure which part of that is wrong here, nor how to go about fixing it. The problem would disappear temporarily when we merged core-updates into master, but keeping up with Python's release schedule doesn't sound feasible. Note that while virtualenv doesn't change PYTHONPATH, it does unset PYTHONHOME - maybe that's a more appropriate environment variable to use for pointing Python to the primary modules directory? While debugging this, I noticed that the virtualenv we ship is outdated. I prepared a patchstack, which I will send later today, to update the version to latest virtualenv. The behavior didn't change, apart from slightly different output formatting of virtualenv. Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#39402: [PATCH] services: xorg: Filter modules based on system
On Sun, Feb 09, 2020 at 09:31:09PM +, shtwzrd wrote:
> @@ -356,7 +361,7 @@ in @var{config}, are available. The result should be
> used in place of
> #~(apply execl #$X #$X ;; Second #$X is for argv[0].
> "-logverbose" "-verbose" "-terminate"
> #$@(xorg-configuration-server-arguments config)
> - (cdr (command-line
> + (cdr (command-line
>
>(program-file "startx" exp))
>
> @@ -477,7 +482,7 @@ desktop session from the system or user profile will be
> used."
>(auto-login? slim-configuration-auto-login?
> (default #f))
>(default-user slim-configuration-default-user
> -(default ""))
> +(default ""))
>(theme slim-configuration-theme
> (default %default-slim-theme))
>(theme-name slim-configuration-theme-name
> @@ -870,10 +875,10 @@ the GNOME desktop environment.")
> "Enable=" (if (gdm-configuration-debug? config)
> "true"
> "false") "\n"
> - "\n"
> - "[security]\n"
> - "#DisallowTCP=true\n"
> - "#AllowRemoteAutoLogin=false\n"))
> + "\n"
> + "[security]\n"
> + "#DisallowTCP=true\n"
> + "#AllowRemoteAutoLogin=false\n"))
>
> (define (gdm-pam-service config)
>"Return a PAM service for @command{gdm}."
Looks like you reformatted the file by accident. Apart from that, LGTM,
so pushed as 779d96c9b0ee38cbaca9f8577e6cc7f907fb29cb after removing the
formatting mishap.
Thanks for the patch!
signature.asc
Description: PGP signature
bug#25240: Fixed on core-updates
A patch that fixes this landed on core-updates, see #38873. A follow-up bug regarding some cleanup is #39415. signature.asc Description: PGP signature
bug#39415: [core-updates] Removing SSL patches in CMake and Kodi - help wanted
In commit a76a343082d61d5303b61a9e4cbde4ab8515a1e7 (currently on CORE-UPDATES), the patch curl-use-ssl-cert-env.patch was added. This makes programs linking to curl work with Guix's SSL certificates. Previously, separate workarounds for each dependent package were required. This means that the following patches are, as far as I know, obsolete: - cmake-curl-certificates.patch - kodi-set-libcurl-ssl-parameters.patch However, I don't use neither cmake nor kodi, and as such I don't think I can sufficiently test that these patches are no longer needed. I would like to ask somebody more familiar with those packages to verify. Regards, Jakub Kądziołka signature.asc Description: PGP signature
bug#38884: guix system roll-back doesn't roll setuid-programs back
Steps to reproduce: 1. Add a setuid program to your config: (setuid-programs (cons* (file-append hello "/bin/hello") %setuid-programs)) 2. guix system reconfigure 3. Observe that /run/setuid-programs/hello got created 4. Undo the configuration change 5. guix system reconfigure 6. Observe that /run/setuid-programs/hello no longer exists 7. guix system roll-back Expected behavior: /run/setuid-programs/hello appears again Actual behavior: /run/setuid-programs/hello still doesn't exist Similarly, when roll-back is supposed to remove a file, it doesn't. Previously mentioned in https://debbugs.gnu.org/38800. Regards, Jakub Kądziołka
bug#38838: 'whatis' doesn't work
The 'whatis' utility from man-db 2.9.0 doesn't work for me. This includes both my user profile and 'guix environment's. 'apropos' works, so the man database is present and working. $ guix environment --pure --ad-hoc man-db man-pages [env] $ apropos memcpy memcpy (3) - copy memory area wmemcpy (3) - copy an array of wide-characters [env] $ whatis memcpy memcpy: nothing appropriate. Regards, Jakub Kądziołka
bug#22883: Authenticating Git checkouts: step #1
Hi Guix! Ludovic Courtès wrote: > --8<---cut here---start->8--- > If you want to hack Guix itself, it is recommended to use the latest > version from the Git repository: > > git clone https://git.savannah.gnu.org/git/guix.git > >How do you ensure that you obtained a genuine copy of the repository? > Guix itself provides a tool to “authenticate” your checkout, but you > must first make sure this tool is genuine in order to “bootstrap” the > trust chain. To do that, run: > > git verify-commit `git log --format=%H build-aux/git-authenticate.scm` > >The output must look something like: > > gpg: Signature made Fri 27 Dec 2019 01:27:41 PM CET > gpg:using RSA key > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > ... > gpg: Signature made Fri 27 Dec 2019 01:25:22 PM CET > gpg:using RSA key > 3CE464558A84FDC69DB40CFB090B11993D9AEBB5 > ... > > ... meaning that changes to this file are all signed with key > ‘3CE464558A84FDC69DB40CFB090B11993D9AEBB5’ (you may need to fetch this > key from a key server, if you have not done it yet). > >From there on, you can authenticate all the commits included in your > checkout by running: > > make authenticate > >The first run takes a couple of minutes, but subsequent runs are > faster. > > Note: You are advised to run ‘make authenticate’ after every ‘git > pull’ invocation. This ensures you keep receiving valid changes to > the repository > --8<---cut here---end--->8--- Sadly, these instructions don't work from a fresh clone. There is only Makefile.am and no Makefile itself, so you get $ make authenticate make: *** No rule to make target 'authenticate'. Stop. Moreover, I don't think running 'make authenticate' after 'git pull' would really work -- after you pulled, git-authenticate could've been modified, so the verify-commit you did earlier doesn't apply anymore. There's also the issue of trusting pre-inst-env, which is used to run the verification. Should that be passed to 'git log --format=%H' next to git-authenticate.scm? This also applies to any scripts you use to drive this process, like the Makefile. Regards, Kuba
bug#38831: IceCat: some codecs don't work without workaround
Hello,
I had some problems with video codecs in IceCat 68.3.0-guix0-preview1.
For example, consider this page: http://demo.nimius.net/video_test/. By
default, the videos under the headings H.264 / AAC and MPEG4 don't work
("No video with supported format and MIME type found.").
The following steps make the first of these videos work:
1. Open about:config
2. Click "I accept the risk!"
3. Set security.sandbox.content.read_path_whitelist to /gnu/store/
(the trailing / is important).
The instructions were originally sketched out in this help-guix
message:
https://lists.gnu.org/archive/html/help-guix/2019-12/msg00150.html
I believe it would be beneficial to make this a default.
On IRC, bandali suggested that it would be better to only whitelist the
necessary store subdirectories. I don't know how to gather such a list,
but it it seems like a good idea.
I don't know how about:config entries modified by the user behave when
IceCat is updated, but in some of the behaviors I can imagine, the
config entry stops updating, in which case it would be better to add
the paths to some internal whitelist (I reckon such a whitelist already
exists and contains something like /usr/lib).
Regards,
Jakub Kądziołka
CC: mhw as suggested by nckx
bug#38800: Non-existent setuid programs make "guix system reconfigure" break mid-generation-switch
Steps to reproduce: 0. [IMPORTANT] Make sure you will be able to reconfigure your system when all setuid binaries stop working (this includes sudo, which makes this, IMHO, a serious bug). Namely, either make sure you can log in as root, or keep a "sudo -s" shell open. The latter is slightly more dangerous in the event of a power outage. I would also recommend running "guix pull" in this recovery shell, as a root login shell will use root's profile, and not your own. 1. Add a non-existant file to your system configuration's setuid-programs. For example, (setuid-programs (cons* #~(string-append #$bash "/bin/enoent") %setuid-programs)) 2. Reconfigure your system. $ sudo guix system reconfigure /etc/config.scm Actual behavior: activating system... substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% building /gnu/store/0ay9wd3wz4x0f5mgmbdfs72w98qvm68z-switch-to-system.scm.drv... making '/gnu/store/7vwa2xd378fgwrkgwif7pi6ymshsf2jc-system' the current system... setting up setuid programs in '/run/setuid-programs'... guix system: error: copy-file: No such file or directory: "/run/setuid-programs/enoent" $ sudoedit /etc/config.scm -bash: /run/setuid-programs/sudoedit: No such file or directory $ ls -l /run/setuid-programs total 0 Expected behavior: the running system is left untouched. /run/setuid-programs is still populated with the previous generation's setuid programs. The error message says that the source of the copy-file doesn't exist, not the destination. (While the latter is technically correct, it's utterly unhelpful) 3. [OPTIONAL] Run a rollback. # guix system roll-back Expected behavior: /run/setuid-programs gets populated again. Actual behavior: /run/setuid-programs is still empty. (Is this a separate bug with roll-back not restoring setuid-programs? No idea, didn't test) 4. Remove the changes made to the configuration and run reconfigure again. # guix system reconfigure /etc/config.scm Expected & actual behavior: system is back in (AFAIK) a well-defined state. Regards, Jakub Kądziołka
