bug#53230: Disable authentication seems broken
On 2022-01-13 23:15, Ludovic Courtès wrote: > Andrew Tropin skribis: > >> A day ago I found out that I can't pull/time-machine from my local guix >> repo with patches. After running guix time-machine -C ./channels ..., >> guix reported the following: >> >> Updating channel 'guix' from Git repository at >> 'https://git.savannah.gnu.org/git/guix.git'... >> guix time-machine: warning: channel authentication disabled >> Computing Guix derivation for 'x86_64-linux'... - >> Backtrace: >> 18 (primitive-load "/home/bob/.config/guix/current/bin/guix") >> In guix/ui.scm: >>2206:7 17 (run-guix . _) >> 2169:10 16 (run-guix-command _ . _) >> In ice-9/boot-9.scm: >> 1752:10 15 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) >> 1747:15 14 (with-exception-handler #> ice-9/boot-9.…> …) >> In guix/store.scm: >> 671:3 13 (_) >> In ice-9/boot-9.scm: >> 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) >> In guix/store.scm: >>658:37 11 (thunk) >> In guix/status.scm: >> 802:4 10 (call-with-status-report _ _) >> In guix/store.scm: >>1320:8 9 (call-with-build-handler _ _) >>1320:8 8 (call-with-build-handler #> guix/ui.scm:…> …) >> 2123:24 7 (run-with-store # _ # _ # >> _ # …) >> In guix/inferior.scm: >>817:16 6 (_ _) >> In guix/store.scm: >> 1995:38 5 (_ #) >>1468:0 4 (add-temp-root # >> #) >> In guix/serialization.scm: >>130:20 3 (write-store-path #> /gnu/store/pqn1xr6882907b41j6mybvs…> …) >> In unknown file: >>2 (string->utf8 #> /gnu/store/pqn1xr6882907b41j6mybvsg4218…>) >> In ice-9/boot-9.scm: >> 1685:16 1 (raise-exception _ #:continuable? _) >> 1685:16 0 (raise-exception _ #:continuable? _) >> >> ice-9/boot-9.scm:1685:16: In procedure raise-exception: >> In procedure string->utf8: Wrong type argument in position 1 (expecting >> string): #> /gnu/store/pqn1xr6882907b41j6mybvsg4218kc0k-profile.drv => >> /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> > > Fixed in b1fc98d6b063a117fe2bcc19a60c8b9a48301593, thanks! > Thank you very much! Tested this commit, --disable-authentication works now!) -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53245: broken package: python2-future
Am Freitag, dem 14.01.2022 um 00:17 -0500 schrieb Faerryn: > It looks like module tkinter doesn't load for some reason. Here is > the tail of the build log: Note that a patch to exclude tkinter and winreg from the sanity check is already in the mailing list [1], but hasn't been applied yet. Cheers [1] https://issues.guix.gnu.org/52595#2
bug#53247: calibre fails to build.
Looks like upgrading zeroconf (33898cd5b7fa5cd3c5e5af17d72ee84a95b6a5ba)
broke calibre:
...
starting phase `install'
...
Installing calibre environment module: /gnu/store/q227rjddwqxvkd165ydj648gmak7x4xi-calibre-5.21.0/lib/python3.9/site-packages/init_calibre.py
Traceback (most recent call last):
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/./setup.py", line 119, in
sys.exit(main())
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/./setup.py", line 104, in main
command.run_all(opts)
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/setup/__init__.py", line 203, in run_all
self.run_cmd(self, opts)
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/setup/__init__.py", line 199, in run_cmd
cmd.run(opts)
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/setup/install.py", line 154, in run
self.run_postinstall()
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/setup/install.py", line 177, in run_postinstall
from calibre.linux import PostInstall
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/src/calibre/linux.py", line 13, in
from calibre.customize.ui import all_input_formats
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/src/calibre/customize/ui.py", line 18, in
from calibre.customize.builtins import plugins as builtin_plugins
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/src/calibre/customize/builtins.py", line 752, in
from calibre.devices.smart_device_app.driver import SMART_DEVICE_APP
File "/tmp/guix-build-calibre-5.21.0.drv-0/calibre-5.21.0/src/calibre/devices/smart_device_app/driver.py", line 2044, in
from zeroconf import (BadTypeInNameException, _HAS_A_TO_Z,
ImportError: cannot import name '_HAS_A_TO_Z' from 'zeroconf' (/gnu/store/wd7qza7crmav4z8a0rsaqipil279smv5-python-zeroconf-0.38.1/lib/python3.9/site-packages/zeroconf/__init__.py)
error: in phase 'install': uncaught exception:
%exception #< program: "python" arguments: ("./setup.py" "install" "--prefix=/gnu/store/q227rjddwqxvkd165ydj648gmak7x4xi-calibre-5.21.0" "--no-compile") exit-status: 1 term-signal: #f stop-signal: #f>
phase `install' failed after 2.5 seconds
command "python" "./setup.py" "install" "--prefix=/gnu/store/q227rjddwqxvkd165ydj648gmak7x4xi-calibre-5.21.0" "--no-compile" failed with status 1
builder for `/gnu/store/jkw6y56fsbh53rn8q214ny3fxk25p6c0-calibre-5.21.0.drv' failed with exit code 1
I found this https://bugs.gentoo.org/800233 similar gentoo bug.
Seems, our calibre needs a patch or upgraded to >=5.24
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
signature.asc
Description: PGP signature
bug#53246: Flameshot crashes on screen capture
bash-5.0$ flameshot
(process:6205): Gtk-WARNING **: 06:51:44.636: Locale not supported by C
library.
Using the fallback 'C' locale.
QSettings::value: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QSettings::value: Empty key passed
QSettings::setValue: Empty key passed
QPainter::begin: Paint device returned engine == 0, type: 2
QPainter::setRenderHint: Painter must be active to set rendering hints
QPainter::setCompositionMode: Painter not active
QPainter::translate: Painter not active
QPainter::setPen: Painter not active
QPainter::setBrush: Painter not active
QPainter::setBrush: Painter not active
[source ] [function ] [line ] Locales on your system are not properly
configured. Falling back to defaults
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
Steps to reproduce:
1. Install flameshot e.g. `guix install flameshot`
2. Run `flameshot` in a terminal
3. Invoke the flameshot gui e.g. by clicking on the flameshot icon in
the icon tray
4. Try to save screenshot and expect the failure above.
Info
GNU GuixSD (374fea0f3bc8035f626cb29e6045130df9ffdaf8)
bash-5.0$ cat /etc/config.scm
;; This is an operating system configuration generated
;; by the graphical installer.
(use-modules (gnu))
(use-service-modules
cups
desktop
networking
ssh
xorg)
(operating-system
(locale "en_US.utf8")
(timezone "Europe/Prague")
(keyboard-layout (keyboard-layout "us"))
(host-name "leonid")
(users (cons* (user-account
(name "kreyren")
(comment "Jacob Hrbek")
(group "users")
(home-directory "/home/kreyren")
(supplementary-groups
'("wheel" "netdev" "audio" "video")))
%base-user-accounts))
(packages
(append
(list (specification->package "nss-certs"))
%base-packages))
(services
(append (list
(service xfce-desktop-service-type)
(service openssh-service-type)
(service tor-service-type)
(set-xorg-configuration
(xorg-configuration
(keyboard-layout keyboard-layout %desktop-services
(bootloader
(bootloader-configuration
(bootloader grub-bootloader)
(targets (list "/dev/sda"))
(keyboard-layout keyboard-layout)))
;; SECURITY(Krey): Swap partition is not zero-ed on reboot so it
should reside on an encrypted device --
https://guix.gnu.org/en/manual/devel/en/html_node/Swap-Space.html
;;(swap-space
;;(target (uuid "c965c556-351d-4007-9d33-e7ffbc9c1701")))
(mapped-devices
(list (mapped-device
(source
(uuid "c3ff1f21-b82f-4566-b8a3-274352f40dd4"))
(target "cryptroot")
(type luks-device-mapping))
(mapped-device
(source
(uuid "82c4852c-a46b-43e3-abdb-15600ae61e2e"))
(target "cryptboot")
(type luks-device-mapping))
(mapped-device
(source
(uuid "b14e499f-0c4f-46f6-9adb-1b020f460b11"))
(target "crypthome_kreyren")
(type luks-device-mapping
(file-systems
(cons* (file-system
(mount-point "/")
(device "/dev/mapper/cryptroot")
(type "btrfs")
(dependencies mapped-devices))
(file-system
(mount-point "/boot")
(device "/dev/mapper/cryptboot")
(type "btrfs")
(dependencies mapped-devices))
(file-system
(mount-point "/home/kreyren")
(device "/dev/mapper/crypthome_kreyren")
(type "btrfs")
(dependencies mapped-devices))
%base-file-systems)))
bash-5.0$ uname -r
5.14.14-gnu
publickey - kreyren@rixotstudio.cz - 1677db82.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
bug#52909: Some man pages are not built correctly
Hi Leo,
Leo Famulari writes:
> On Guix Git commit c7d74a9bccfc1b1274fc8754a6e78bb6887c7fea, at least
> some manpages are not being built correctly for packages such as elogind
> and gnome-keyring-daemon. Are we seeing raw groff input? I'm not sure of
> the technology used here.
Thank you for reporting this. I've noticed them too, and somehow
thought the technology was broken.
The technology is docbook xml and xlstproc to transform the source into
man pages (which are in the nroff format, I think).
I've read the same kind of issue reported to the bind9
project and its resolution, which was very helpful:
https://gitlab.isc.org/isc-projects/bind9/-/issues/2310. It seems it's
a DocBook XSL stylesheet problem resolved in
https://github.com/docbook/xslt10-stylesheets/pull/111 but not yet
released...
My first idea was to apply this patch, so I went ahead and made:
--8<---cut here---start->8---
modified gnu/packages/docbook.scm
@@ -229,6 +229,14 @@ (define name-version
"This package provides XSL style sheets for DocBook.")
(license (license:x11-style "" "See 'COPYING' file."
+(define-public docbook-xsl/fixed
+ (package/inherit docbook-xsl
+(name "docbook-xsl-fixed")
+(source (origin
+ (inherit (package-source docbook-xsl))
+ (patches (search-patches
+"docbook-xsl-allow-non-namespace-fix.patch"))
+
(define-public docbook-xsl-ns
(package
(name "docbook-xsl-ns")
new file gnu/packages/patches/docbook-xsl-allow-non-namespace-fix.patch
@@ -0,0 +1,60 @@
+Retrieved from https://github.com/docbook/xslt10-stylesheets/pull/111.
+
+diff --git a/common/common.xsl b/common/common.xsl
+index 59f51dfd0..80742b6ce 100644
+--- a/common/common.xsl
b/common/common.xsl
+@@ -68,7 +68,6 @@ d:subjectset d:substeps d:synopfragment d:table d:tbody
d:textobject d:tfoot d:t
+ d:thead d:tip d:toc d:tocchap d:toclevel1 d:toclevel2 d:toclevel3 d:toclevel4
+ d:toclevel5 d:tocpart d:topic d:varargs d:variablelist d:varlistentry
d:videodata
+ d:videoobject d:void d:warning d:subjectset
+-
+ d:classsynopsis
+ d:constructorsynopsis
+ d:destructorsynopsis
+@@ -81,6 +80,45 @@ d:oointerface
+ d:simplemsgentry
+ d:manvolnum
+ "/>
++
+
+
+
--8<---cut here---end--->8---
Unfortunately the resulting docbook-xsl/fixed package doesn't seem to
work.
Based on this knowledge (from the same issue linked above):
> When using version 1.79.1 or 1.79.2 of the XSL stylesheets, care must
> be taken to ensure the namespaced stylesheets are used for generating
> BIND documentation.
--8<---cut here---start->8---
modified gnu/packages/samba.scm
@@ -269,7 +269,7 @@ (define-public samba
("rpcsvc-proto" ,rpcsvc-proto) ; for 'rpcgen'
;; For generating man pages.
("docbook-xml" ,docbook-xml-4.2)
- ("docbook-xsl" ,docbook-xsl)
+ ("docbook-xsl" ,docbook-xsl-ns)
("xsltproc" ,libxslt)
("libxml2" ,libxml2))) ;for XML_CATALOG_FILES
(home-page "https://www.samba.org/;)
--8<---cut here---end--->8---
But that also doesn't work...
Ahem...
I guess we'll need to wait for Docbook to fix their things and issue a
new release, else use one of their snapshots.
On an unrelated (to the problem at hand note) I've also realized my
confusion in adding a docbook-xsl-ns package. The legacy suffix (1.79.1
and older) )was inverted for 1.79.2 (-ns was removed, so the docbook-xsl
*is* namespaced while -nons was added to denote the non-namespaced
version).
I should probably get rid of this docbook-xsl-ns package unless 1.79.1
is truly needed and replace it by docbook-xsl-nons. I tried to use this
with samba but it also didn't work.
That's frustrating!
Good night,
Maxim
bug#53243: tigervnc-server failed to build
S_ I_ 写道： | 'patch-xserver' phasebuilder I've fixed the build on master and am hopefully closing this bug. Please reopen it if the package still has problems. Kind regards, T G-R signature.asc Description: PGP signature
bug#53245: broken package: python2-future
It looks like module tkinter doesn't load for some reason. Here is the
tail of the build log:
starting phase `sanity-check'
validating 'future'
/gnu/store/9qknps8svnw5njfr823bm1il1gw5nxlm-python2-future-0.18.2/lib/python2.7/site-packages
...checking requirements: OK
...trying to load module _dummy_thread: OK
...trying to load module _markupbase: OK
...trying to load module _thread: OK
...trying to load module builtins: OK
...trying to load module copyreg: OK
...trying to load module future: OK
...trying to load module html: OK
...trying to load module http: OK
...trying to load module libfuturize: OK
...trying to load module libpasteurize: OK
...trying to load module past: OK
...trying to load module queue: OK
...trying to load module reprlib: OK
...trying to load module socketserver: OK
...trying to load module tkinter: ERROR:
Traceback (most recent call last):
File "/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py", line
69, in
importlib.import_module(name)
File
"/gnu/store/y14nmmzzcs2a6m2gnn2diak2gkf5v2av-python2-2.7.18/lib/python2.7/importlib/__init__.py",
line 37, in import_module
__import__(name)
File
"/gnu/store/9qknps8svnw5njfr823bm1il1gw5nxlm-python2-future-0.18.2/lib/python2.7/site-packages/tkinter/__init__.py",
line 5, in
from Tkinter import *
File
"/gnu/store/y14nmmzzcs2a6m2gnn2diak2gkf5v2av-python2-2.7.18/lib/python2.7/lib-tk/Tkinter.py",
line 39, in
import _tkinter # If this fails your Python may not be configured for Tk
ImportError: No module named _tkinter
...trying to load module winreg: ERROR:
Traceback (most recent call last):
File "/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py", line
69, in
importlib.import_module(name)
File
"/gnu/store/y14nmmzzcs2a6m2gnn2diak2gkf5v2av-python2-2.7.18/lib/python2.7/importlib/__init__.py",
line 37, in import_module
__import__(name)
File
"/gnu/store/9qknps8svnw5njfr823bm1il1gw5nxlm-python2-future-0.18.2/lib/python2.7/site-packages/winreg/__init__.py",
line 6, in
from _winreg import *
ImportError: No module named _winreg
...trying to load module xmlrpc: OK
...trying to load endpoint console_scripts pasteurize: OK
...trying to load endpoint console_scripts futurize: OK
error: in phase 'sanity-check': uncaught exception:
%exception #< program: "python" arguments:
("/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py"
"/gnu/store/9qknps8svnw5njfr823bm1il1gw5nxlm-python2-future-0.18.2/lib/python2.7/site-packages")
exit-status: 1 term-signal: #f stop-signal: #f>
phase `sanity-check' failed after 0.2 seconds
command "python"
"/gnu/store/nwwr89v2vyg1hs48i49m083vhczsgh3m-sanity-check.py"
"/gnu/store/9qknps8svnw5njfr823bm1il1gw5nxlm-python2-future-0.18.2/lib/python2.7/site-packages"
failed with status 1
bug#53243: tigervnc-server failed to build
Tobias Geerinckx-Rice 写道： This sounds like your guix is out of date. Never mind, the problem was here. I can reproduce the failure (the error message is pleasantly clear for once :-). Kind regards, T G-R signature.asc Description: PGP signature
bug#53243: tigervnc-server failed to build
Hullo, S_ I_ 写道： building /gnu/store/yr3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv... | 'patch-xserver' phasebuilder for `/gnu/store/yr3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv' failed with exit code 1 This sounds like your guix is out of date. Could you run ‘guix pull’, retry the build, and report the output of ‘guix describe’ if it fails? Kind regards, T G-R signature.asc Description: PGP signature
bug#53243: tigervnc-server failed to build
guix install tigervnc-server The following package will be installed: tigervnc-server 1.11.0 substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0% substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0% The following derivations will be built: /gnu/store/m598av2pv05gddmy6gzrykdliba75bza-profile.drv /gnu/store/yr3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv 31.8 MB will be downloaded glibc-utf8-locales-2.33 382KiB 566KiB/s 00:01 [##] 100.0% autoconf-2.69 663KiB2.2MiB/s 00:00 [##] 100.0% automake-1.16.3 595KiB 528KiB/s 00:01 [##] 100.0% diffutils-3.8 337KiB1.9MiB/s 00:00 [##] 100.0% ed-1.17 58KiB 2.0MiB/s 00:00 [##] 100.0% findutils-4.8.0 520KiB 1.8MiB/s 00:00 [##] 100.0% fltk-1.3.6 1.2MiB 3.4MiB/s 00:00 [##] 100.0% font-util-1.3.2 29KiB 673KiB/s 00:00 [##] 100.0% gettext-minimal-0.21 2.2MiB 3.8MiB/s 00:01 [##] 100.0% glibc-2.33-static 1.4MiB1.1MiB/s 00:01 [##] 100.0% jsoncpp-1.9.4 193KiB2.2MiB/s 00:00 [##] 100.0% kbproto-1.0.7 123KiB932KiB/s 00:00 [##] 100.0% libdmx-1.1.4 32KiB 1.4MiB/s 00:00 [##] 100.0% libuv-1.41.1 102KiB 2.8MiB/s 00:00 [##] 100.0% libxres-1.2.1 9KiB 612KiB/s 00:00 [##] 100.0% make-4.3 485KiB 1.3MiB/s 00:00 [##] 100.0% module-import-compiled 212KiB 2.9MiB/s 00:00 [##] 100.0% patch-2.7.6 107KiB 9.3MiB/s 00:00 [##] 100.0% perl-gettext-1.07 10KiB 888KiB/s 00:00 [##] 100.0% rhash-1.4.2 154KiB 1.5MiB/s 00:00 [##] 100.0% help2man-1.48.3 140KiB 1.1MiB/s 00:00 [##] 100.0% cmake-3.21.3 12.0MiB4.3MiB/s 00:03 [##] 100.0% sed-4.8 242KiB 976KiB/s 00:00 [##] 100.0% tigervnc-client-1.11.0-checkout 1.2MiB 885KiB/s 00:00 [ ] 0 tigervnc-client-1.11.0-checkout 1.2MiB 1.7MiB/s 00:00 [# ] 28 tigervnc-client-1.11.0-checkout 1.2MiB 2.7MiB/s 00:00 [ ] 89 tigervnc-client-1.11.0-checkout 1.2MiB 2.7MiB/s 00:00 [##] 100.0% libtool-2.4.6 384KiB1.7MiB/s 00:00 [##] 100.0% xorg-server-21.1.2.tar.xz 4.8MiB4.8MiB/s 00:01 [##] 100.0% xtrans-1.4.0 42KiB 1.5MiB/s 00:00 [##] 100.0% building /gnu/store/yr3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv... | 'patch-xserver' phasebuilder for `/gnu/store/yr3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv' failed with exit code 1 build of /gnu/store/yr3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv failed View build log at '/var/log/guix/drvs/yr/3qw7zy5r60w8ijfs6zsfmcd04p83hm-tigervnc-server-1.11.0.drv.bz2'. cannot build derivation `/gnu/store/m598av2pv05gddmy6gzrykdliba75bza-profile.drv': 1 dependencies couldn't be built guix install: error: build of `/gnu/store/m598av2pv05gddmy6gzrykdliba75bza-profile.drv' failed
bug#52976: Some tools in Samba fail to find modules, and a missing dependency
Hello Simon,
Simon Streit writes:
> While experimenting with Samba, I noticed that some tools, especially
> samba-tools will not run, and crash:
>
> root@motor ~# samba-tool
> Traceback (most recent call last):
> File "/run/current-system/profile/bin/samba-tool", line 33, in
> from samba.netcmd.main import cmd_sambatool
> File
> "/gnu/store/78baaab8085rd5xnfrpdkxdf07zkmin9-samba-mod-4.13.14/lib/python3.9/site-packages/samba/__init__.py",
> line 29, in
> import samba.param
> ModuleNotFoundError: No module named 'talloc'
>
> Doing more testing, other tools appear to not find the libraries they
> need too. The combination is as folows:
> - samba-tool, fails when tdb missing.
> - samba-gpupdate Idem.
> - samba_dnsupdate requires dnspython, but fails when talloc missing.
> - samba_downgrade_db" fails when tdb missing.
> - samba_kcc Idem.
> - samba_spnupdate" Idem.
> - samba_upgradedns" dns not found when talloc missing.
>
> I prepared a small patch to wrap up the inputs appropriately. I hope it
> is acceptable that they are all combined in one wrap procedure.
Thanks for testing samba!
I've updated samba recently on the version-1.4.0 branch; but the problem
probably remains (I've only tested smbd and smbclient). It's now at
version 4.15.3 and I nedded to add the python-cryptogaphy,
python-dnspython, python-markdown and python-pyasn1 as native inputs.
Based on your findings it probably should be moved to an input.
>>From 201dc8e01fa4484e24b3e088ab6a4211e9839f33 Mon Sep 17 00:00:00 2001
> From: Simon Streit
> Date: Mon, 3 Jan 2022 13:08:23 +0100
> Subject: [PATCH] gnu: samba: Use PYTHONPATH.
>
> * gnu/packages/samba.scm (samba): Use PYTHONPATH in 'wrap-program phase..
> ---
> gnu/packages/samba.scm | 28 ++--
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/gnu/packages/samba.scm b/gnu/packages/samba.scm
> index bb5b402eee..33a39eb3be 100644
> --- a/gnu/packages/samba.scm
> +++ b/gnu/packages/samba.scm
> @@ -235,7 +235,30 @@ (define-public samba
> (lambda _
> (substitute* "dynconfig/wscript"
> (("bld\\.INSTALL_DIR.*") ""))
> - #t)))
> + #t))
Trailing #t are no longer needed.
> + (add-after 'install 'wrap-program
> + ;; Some samba tools selectively fail to find talloc, tdb
> + ;; and dnspython.
> + (lambda* (#:key inputs outputs #:allow-other-keys)
> + (let ((out (string-append (assoc-ref outputs "out")))
> + (talloc (string-append (assoc-ref inputs "talloc")
> + "/lib/python3.9/site-packages"))
> + (tdb (string-append (assoc-ref inputs "tdb")
> + "/lib/python3.9/site-packages"))
> + (python-dnspython (string-append
> + (assoc-ref inputs "python-dnspython")
> + "/lib/python3.9/site-packages")))
We shouldn't hard code Python versions in the paths as it'd be too prone
to break. You could probably make good use of the recently introduced
search-input-directory procedure here :-).
> + (for-each
> +(lambda (bin)
> + (wrap-program (string-append out bin)
> +`("PYTHONPATH" prefix (,talloc ,tdb ,python-dnspython
Make sure to run 'guix lint', it'll probably suggest to add minimal-bash
as an input because of the use of wrap-program.
> +'("/bin/samba-tool"
> + "/sbin/samba-gpupdate"
> + "/sbin/samba_dnsupdate"
> + "/sbin/samba_downgrade_db"
> + "/sbin/samba_kcc"
> + "/sbin/samba_spnupdate"
> + "/sbin/samba_upgradedns"))
> ;; FIXME: The test suite seemingly hangs after failing to provision
> the
> ;; test environment.
> #:tests? #f))
> @@ -258,7 +281,8 @@ (define-public samba
> python
> popt
> readline
> - tdb))
> + tdb
> + python-dnspython))
> (propagated-inputs
> ;; In Requires or Requires.private of pkg-config files.
> (list ldb talloc tevent))
Otherwise it LGTM. Could you try to rebase this patch on top of the
version-1.4.0 branch? Otherwise, wait a few days and it should be
merged into master.
Thank you!
Maxim
bug#53225: shepherd freezes if wireguard is started with dns config enabled
>What do you mean by “freezing”? Does ‘herd status’ and similar commands block forever? Yes >Requests in the Shepherd are currently handled sequentially. So if you issue several ‘herd restart’ commands, they’ll be processed one at a time. This is usually okay because ‘start’ commands are expected to be quick (just wait for the daemon to write its PID file or similar). What is the nature of this serialization? Does wireguard need to finish before resolvconf can start? Because that's probably the issue. On Thu, Jan 13, 2022 at 9:11 AM Ludovic Courtès wrote: > > Hi, > > Nathan Dehnel skribis: > > > When dns is specified, wireguard runs wg-quick, which runs resolvconf, > > which runs /run/current-system/profile/bin/herd restart, which causes > > shepherd to freeze because I guess it doesn't like being given > > multiple start commands at once. I'm not sure how to fix it. > > What do you mean by “freezing”? Does ‘herd status’ and similar commands > block forever? Or is it something else? > > Requests in the Shepherd are currently handled sequentially. So if you > issue several ‘herd restart’ commands, they’ll be processed one at a > time. This is usually okay because ‘start’ commands are expected to be > quick (just wait for the daemon to write its PID file or similar). > > Thanks, > Ludo’.
bug#53230: Disable authentication seems broken
Andrew Tropin skribis: > A day ago I found out that I can't pull/time-machine from my local guix > repo with patches. After running guix time-machine -C ./channels ..., > guix reported the following: > > Updating channel 'guix' from Git repository at > 'https://git.savannah.gnu.org/git/guix.git'... > guix time-machine: warning: channel authentication disabled > Computing Guix derivation for 'x86_64-linux'... - > Backtrace: > 18 (primitive-load "/home/bob/.config/guix/current/bin/guix") > In guix/ui.scm: >2206:7 17 (run-guix . _) > 2169:10 16 (run-guix-command _ . _) > In ice-9/boot-9.scm: > 1752:10 15 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) > 1747:15 14 (with-exception-handler # ice-9/boot-9.…> …) > In guix/store.scm: > 671:3 13 (_) > In ice-9/boot-9.scm: > 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) > In guix/store.scm: >658:37 11 (thunk) > In guix/status.scm: > 802:4 10 (call-with-status-report _ _) > In guix/store.scm: >1320:8 9 (call-with-build-handler _ _) >1320:8 8 (call-with-build-handler # guix/ui.scm:…> …) > 2123:24 7 (run-with-store # _ # _ # > _ # …) > In guix/inferior.scm: >817:16 6 (_ _) > In guix/store.scm: > 1995:38 5 (_ #) >1468:0 4 (add-temp-root # > #) > In guix/serialization.scm: >130:20 3 (write-store-path # /gnu/store/pqn1xr6882907b41j6mybvs…> …) > In unknown file: >2 (string->utf8 # /gnu/store/pqn1xr6882907b41j6mybvsg4218…>) > In ice-9/boot-9.scm: > 1685:16 1 (raise-exception _ #:continuable? _) > 1685:16 0 (raise-exception _ #:continuable? _) > > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > In procedure string->utf8: Wrong type argument in position 1 (expecting > string): # => > /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> Fixed in b1fc98d6b063a117fe2bcc19a60c8b9a48301593, thanks! Ludo’.
bug#53233: installing gnome-terminal on a foreign distribution causes login to fail
Hi Leo! Leo Famulari writes: > On Thu, Jan 13, 2022 at 12:42:18PM -0500, Maxim Cournoyer wrote: >> Hello Guix, >> >> I'm lacking investigation detail, but this seems worthy of reporting. >> >> I had tested installing gnome-terminal from guix on top of a Debian >> stable distribution, and was surprised that login would not longer work >> (!) until I 'guix remove gnome-terminal' from a TTY. > > On Debian 11 (current stable), I did this: > > recent commit, from today >| > -- ▼ > $ guix time-machine --commit=ea71ec1630e06503c14c6e7f4570b69de4e42123 -- > install gnome-terminal > $ gnome-terminal > # Error creating terminal: The name org.gnome.Terminal was not provided by > any .service files > $ > -- Yes, this is because gnome-terminal installs dbus services that aren't found without messing with the host dbus config. > So, it doesn't work in general. But, it also doesn't break login. I > tried `bash --login` and also logged in from the console in another TTY. > > However, my system doesn't use a desktop environment or login manager. I > login from the console and run `startx`. OK, perhaps this explains why. My testing was with GDM/GNOME atop Debian 9. Thanks for trying it! Maxim
bug#48903: bug#42902: texlive substitute TLS error: decoding the received packet
Hello, [ Sending again to 48903 (and excluding everyone else from the recipients) because this bug was archived and thus the original message bounced. ] I’m sending this email to two bugs because they are both about the same problem. Bug 48903 (which is currently closed) has fairly intense attempts at debugging what is going on, but unfortunately without arriving at an answer. This problem is also affecting Cuirass builds. This powerpc64le-linux build: https://ci.guix.gnu.org/build/70/details failed because of the intermitent TLS error: --8<---cut here---start->8--- guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet. fetching path `/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty status: '') @ substituter-failed /gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9 fetching path `/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty status: '') --8<---cut here---end--->8--- The daemon in this case is: /gnu/store/ny30pxjzv866m3w0v1vfbzdbqi17k8wn-guix-daemon-1.3.0-21.e427593/bin/guix-daemon From this Guix version --8<---cut here---start->8--- guixp9: sudo -i guix describe Generation 11 Jan 11 2022 02:07:42(current) guix 83abdc8 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 83abdc8371d90b6d4591a69fae5585a2a99c1627 --8<---cut here---end--->8--- Not sure if this is related, but during that build Guix noticed that the substitute server is slow: --8<---cut here---start->8--- Downloading https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9... guix substitute: warning: while fetching https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9: server is somewhat slow guix substitute: warning: try `--no-substitutes' if the problem persists --8<---cut here---end--->8--- There’s bug 46942 which is specifically about ci.guix.gnu.org being slow, and the bug reporter there also hits this same TLS error, so there’s probably at least some correlation between this problem and the network being slow. -- Thanks, Thiago
bug#42902: texlive substitute TLS error: decoding the received packet
Hello, I’m sending this email to two bugs because they are both about the same problem. Bug 48903 (which is currently closed) has fairly intense attempts at debugging what is going on, but unfortunately without arriving at an answer. This problem is also affecting Cuirass builds. This powerpc64le-linux build: https://ci.guix.gnu.org/build/70/details failed because of the intermitent TLS error: --8<---cut here---start->8--- guix substitute: error: TLS error in procedure 'read_from_session_record_port': Error decoding the received TLS packet. fetching path `/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty status: '') @ substituter-failed /gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9 fetching path `/gnu/store/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9' (empty status: '') --8<---cut here---end--->8--- The daemon in this case is: /gnu/store/ny30pxjzv866m3w0v1vfbzdbqi17k8wn-guix-daemon-1.3.0-21.e427593/bin/guix-daemon From this Guix version --8<---cut here---start->8--- guixp9: sudo -i guix describe Generation 11 Jan 11 2022 02:07:42(current) guix 83abdc8 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 83abdc8371d90b6d4591a69fae5585a2a99c1627 --8<---cut here---end--->8--- Not sure if this is related, but during that build Guix noticed that the substitute server is slow: --8<---cut here---start->8--- Downloading https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9... guix substitute: warning: while fetching https://ci.guix.gnu.org/nar/lzip/fkkfffvwrj103zs5cf6d8bf9as46ywhc-python-minimal-3.5.9: server is somewhat slow guix substitute: warning: try `--no-substitutes' if the problem persists --8<---cut here---end--->8--- There’s bug 46942 which is specifically about ci.guix.gnu.org being slow, and the bug reporter there also hits this same TLS error, so there’s probably at least some correlation between this problem and the network being slow. -- Thanks, Thiago
bug#53234: terminal URL capability not correctly detected (gnome-terminal 3.22.2).
Hello, I discovered that on a Debian 9 (stretch) box equipped with gnome-terminal 3.22.2, Guix would use terminal ANSI codes to represent hyperlinks in its output, which were not supported by GNOME terminal 3.22.2 which uses VTE 0.46.1 (it picked up support in 3.26 IIRC). Thanks, Maxim
bug#53233: installing gnome-terminal on a foreign distribution causes login to fail
On Thu, Jan 13, 2022 at 12:42:18PM -0500, Maxim Cournoyer wrote: > Hello Guix, > > I'm lacking investigation detail, but this seems worthy of reporting. > > I had tested installing gnome-terminal from guix on top of a Debian > stable distribution, and was surprised that login would not longer work > (!) until I 'guix remove gnome-terminal' from a TTY. On Debian 11 (current stable), I did this: recent commit, from today | -- ▼ $ guix time-machine --commit=ea71ec1630e06503c14c6e7f4570b69de4e42123 -- install gnome-terminal $ gnome-terminal # Error creating terminal: The name org.gnome.Terminal was not provided by any .service files $ -- So, it doesn't work in general. But, it also doesn't break login. I tried `bash --login` and also logged in from the console in another TTY. However, my system doesn't use a desktop environment or login manager. I login from the console and run `startx`.
bug#53233: installing gnome-terminal on a foreign distribution causes login to fail
Hello Guix, I'm lacking investigation detail, but this seems worthy of reporting. I had tested installing gnome-terminal from guix on top of a Debian stable distribution, and was surprised that login would not longer work (!) until I 'guix remove gnome-terminal' from a TTY. We should investigate why (such as in a VM). Maxim
bug#52779: tests/no-home test failure in Shepherd
Hi Ludo! Ludovic Courtès writes: > Hello, > > Maxim Cournoyer skribis: > >> + herd -s t-socket-1651 status root >> Started: >> + root >> + herd -s t-socket-1651 stop root >> ++ cat t-pid-1651 >> + kill 1896 >> + exit 1 >> + rm -f t-socket-1651 >> + test -f t-pid-1651 >> ++ cat t-pid-1651 >> + kill 1896 >> + rm -f t-pid-1651 >> FAIL tests/no-home.sh (exit status: 1) > > What happens here is that the shepherd process is still alive after > ‘herd stop root’ has completed, contrary to what’s expected: > > $herd stop root > > if kill `cat "$pid"` > then > exit 1 > fi Yes! [...] > Maybe there’s a chance that the shell hasn’t processed the shepherd’s > SIGCHLD when it evaluates the “if kill `cat "$pid"`” condition; in that > case, the shepherd process still exists as a zombie. > > A more robust approach might be to use the shell’s builtin ‘wait’, > because then I suppose the shell will be forced to process pending > SIGCHLDs: > > diff --git a/tests/no-home.sh b/tests/no-home.sh > index 85b6116..5a8c278 100644 > --- a/tests/no-home.sh > +++ b/tests/no-home.sh > @@ -1,5 +1,5 @@ > # GNU Shepherd --- Make sure shepherd doesn't fail when $HOME is not > writable. > -# Copyright © 2014, 2016 Ludovic Courtès > +# Copyright © 2014, 2016, 2022 Ludovic Courtès > # > # This file is part of the GNU Shepherd. > # > @@ -46,7 +46,4 @@ kill -0 `cat "$pid"` > $herd status root > $herd stop root > > -if kill `cat "$pid"` > -then > -exit 1 > -fi > +wait `cat "$pid"` As I wrote, I was also unable to reproduce this (but when I had a high load of packages to build at the same time, I could get it to happen a couple times upon retrying). Your analysis (and the narrow window which would allow for a failure) makes sense to me, along with the proposed fix. I think you should commit it and tentatively mark this bug as fixed :-). Thank you for looking into it! Maxim
bug#52533: guix deploy breaks SSH access with a PAM error
Hello, Ludovic Courtès writes: > Hi, > > Mathieu Othacehe skribis: > >>> This sounds a lot like this: >>> >>> https://issues.guix.gnu.org/32182#1 >> >> I was just kicked out of my own server due to this PAM/SSH issue. It >> happens quite frequently here. Time for a fix :). Not a meaningful contribution to the discussion, but my workaround is to disable PAM; as it is not enabled in OpenSSH by default, perhaps we should also leave it off unless requested? What are the advantages of having it on? > Note that ‘guix deploy’ now opens a single SSH session, starting from > 7f20e59a13a6acc3331e04185b8f1ed2538dcd0a, which might help mitigate the > problem. > >> Regarding the two potential solutions that you proposed in 2018, are >> they still actual? If yes, I could maybe try to implement the second >> suggestion: introducing service chain-loading. > > Service chain-loading was implemented in the Shepherd a few years ago. > However, it doesn’t really help; consider these two scenario: > > • You do ‘guix system reconfigure && herd restart term-tty1’. In that > case, all is good: ‘term-tty1’, will run the new ‘mingetty’ process > (post-glibc upgrade, thanks to service chain-loading) and ‘login’ > will happily load the .so files listed in /etc/pam.d/login (also > post-glibc upgrade). > > • You run ‘guix system reconfigure’ but do not restart ‘term-tty1’, > ‘sshd’, and all the other services that depend on PAM: these > pre-glibc upgrade programs will try dlopening the post-glibc upgrade > PAM plugins, which will break. > > The crux of the problem rather is the global /etc/pam.d: it’s valid for > pre-glibc upgrade programs, or for post-glibc upgrade programs, but not > both. > > FHS distros have a similar problem though; how do they handle it? Do > they force services to be restarted when glibc is upgraded, or something > along these lines? I just asked this question in Debian's OFTC channel: "how does debian handle glibc updates? are services restarted when it happens? Or does it postpone updating glibc until the next reboot?" And got for answer: "there is no magic postponing of updates"; the external needrestart [0] program was also mentioned. Researching some more, it seems this may be handled on Debian by the use of postinst scripts (which is an arbitrary shell script run after a package is installed); so the libc package of Debian for example restarts the postgres service to avoid problems: [0] https://github.com/liske/needrestart [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710275 > In our case, suppose libpam honors $PAM_DIRECTORY; we could tweak each > PAM-using Shepherd service (login, sshd, etc.) so that it sets > PAM_DIRECTORY… but how would we get the PAM_DIRECTORY value for the OS > being configured? Tricky! Good question, but that seems a good path to pursue; old services would be using their own old pam modules, allowing them to continue running unimpacted, while new ones would get the updated pam modules. > We could maybe sidestep the issue altogether with socket-activated > services: they’d be started on-demand, so the second scenario above > would be unlikely. But getting there is quite a bit of work… I fail to see how this would be a solution for openssh, which would typically already be running unless you've never login ounce since the machine was up (or am I missing something?). Also, it seems to me inetd can already do "socket activation", if this was somehow useful. Thanks, Maxim
bug#53230: Acknowledgement (Disable authentication seems broken)
Seems issue appeared after 9f371f23eb. This one fails: guix time-machine --commit=9f371f23ebfa20f70b3bfd55dc459b683f21ba91 -- time-machine --commit=d87d6d6812 --disable-authentication -- describe This one works: guix time-machine --commit=1a0696e0a6dcde342094712957037c586f572efb -- time-machine --commit=d56a29edb7 --disable-authentication -- describe -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#52779: tests/no-home test failure in Shepherd
Hello,
Maxim Cournoyer skribis:
> + herd -s t-socket-1651 status root
> Started:
> + root
> + herd -s t-socket-1651 stop root
> ++ cat t-pid-1651
> + kill 1896
> + exit 1
> + rm -f t-socket-1651
> + test -f t-pid-1651
> ++ cat t-pid-1651
> + kill 1896
> + rm -f t-pid-1651
> FAIL tests/no-home.sh (exit status: 1)
What happens here is that the shepherd process is still alive after
‘herd stop root’ has completed, contrary to what’s expected:
--8<---cut here---start->8---
$herd stop root
if kill `cat "$pid"`
then
exit 1
fi
--8<---cut here---end--->8---
The expectation is that shepherd has terminated by the time ‘herd stop
root’ exits; I wonder if that’s bogus.
‘herd stop root’ terminates when shepherd has closed its connection,
which normally happens when shepherd exits:
--8<---cut here---start->8---
28003 read(15, "(shepherd-command (version 0) (action stop) (service root)
(arguments ()) (directory \"/data/src/shepherd\"))", 1024) = 107
28003 brk(0x103)= 0x103
28003 mmap(NULL, 262144, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f0072be8000
28003 brk(0x100f000)= 0x100f000
28003 getcwd("/data/src/shepherd", 100) = 19
28003 chdir("/data/src/shepherd") = 0
28003 newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0444,
st_size=2962, ...}, 0) = 0
28003 write(7, "2022-01-13 16:21:16 Exiting shepherd...\n", 40) = 40
28003 chdir("/data/src/shepherd") = 0
28003 getuid() = 1000
28003 close(13) = 0
28003 unlink("test")= 0
28003 exit_group(0) = ?
28006 <... futex resumed>) = ?
28008 <... read resumed> ) = ?
28005 <... futex resumed>) = ?
28004 <... futex resumed>) = ?
28008 +++ exited with 0 +++
28006 +++ exited with 0 +++
28005 +++ exited with 0 +++
28004 +++ exited with 0 +++
28003 +++ exited with 0 +++
--8<---cut here---end--->8---
Maybe there’s a chance that the shell hasn’t processed the shepherd’s
SIGCHLD when it evaluates the “if kill `cat "$pid"`” condition; in that
case, the shepherd process still exists as a zombie.
A more robust approach might be to use the shell’s builtin ‘wait’,
because then I suppose the shell will be forced to process pending
SIGCHLDs:
diff --git a/tests/no-home.sh b/tests/no-home.sh
index 85b6116..5a8c278 100644
--- a/tests/no-home.sh
+++ b/tests/no-home.sh
@@ -1,5 +1,5 @@
# GNU Shepherd --- Make sure shepherd doesn't fail when $HOME is not writable.
-# Copyright © 2014, 2016 Ludovic Courtès
+# Copyright © 2014, 2016, 2022 Ludovic Courtès
#
# This file is part of the GNU Shepherd.
#
@@ -46,7 +46,4 @@ kill -0 `cat "$pid"`
$herd status root
$herd stop root
-if kill `cat "$pid"`
-then
-exit 1
-fi
+wait `cat "$pid"`
I can’t get it to fail while waiting for a few minutes of:
while make check TESTS=tests/no-home.sh ; do : ; done
… but I cannot get the original one to fail either.
Does it work for you?
Ludo’.
bug#53167: texinfo: missing dependents
Hi, zimoun skribis: > Using Guix 3dcc74d, 'sed' and 'cat' are missing from 'texinfo'. Are these two programs just used by texi2dvi? We could patch texi2dvi to refer to them by absolute file name, from ‘coreutils-minimal’. > Moreover, 'texlive' seems also missing. We won’t propagate that one. :-) I think it’s a case where it’s fine to favor “dynamic composition”, where ‘pdflatex’ is taken from $PATH. Thanks, Ludo’.
bug#52533: guix deploy breaks SSH access with a PAM error
Hi, Mathieu Othacehe skribis: >> This sounds a lot like this: >> >> https://issues.guix.gnu.org/32182#1 > > I was just kicked out of my own server due to this PAM/SSH issue. It > happens quite frequently here. Time for a fix :). Note that ‘guix deploy’ now opens a single SSH session, starting from 7f20e59a13a6acc3331e04185b8f1ed2538dcd0a, which might help mitigate the problem. > Regarding the two potential solutions that you proposed in 2018, are > they still actual? If yes, I could maybe try to implement the second > suggestion: introducing service chain-loading. Service chain-loading was implemented in the Shepherd a few years ago. However, it doesn’t really help; consider these two scenario: • You do ‘guix system reconfigure && herd restart term-tty1’. In that case, all is good: ‘term-tty1’, will run the new ‘mingetty’ process (post-glibc upgrade, thanks to service chain-loading) and ‘login’ will happily load the .so files listed in /etc/pam.d/login (also post-glibc upgrade). • You run ‘guix system reconfigure’ but do not restart ‘term-tty1’, ‘sshd’, and all the other services that depend on PAM: these pre-glibc upgrade programs will try dlopening the post-glibc upgrade PAM plugins, which will break. The crux of the problem rather is the global /etc/pam.d: it’s valid for pre-glibc upgrade programs, or for post-glibc upgrade programs, but not both. FHS distros have a similar problem though; how do they handle it? Do they force services to be restarted when glibc is upgraded, or something along these lines? In our case, suppose libpam honors $PAM_DIRECTORY; we could tweak each PAM-using Shepherd service (login, sshd, etc.) so that it sets PAM_DIRECTORY… but how would we get the PAM_DIRECTORY value for the OS being configured? Tricky! We could maybe sidestep the issue altogether with socket-activated services: they’d be started on-demand, so the second scenario above would be unlikely. But getting there is quite a bit of work… Ludo’.
bug#30229: Python modules installed by pip in virtualenv can't find shared objects.
Hi, On Thu, 25 Nov 2021 at 00:39, zimoun wrote: > On Tue, 23 Jan 2018 at 13:00, Ricardo Wurmus wrote: > >>> When a python module needs to load a dynamic shared object, it looks in the >>> path provided by *LD_LIBRARY_PATH*(1), but guix doesn't modify this >>> environment >>> variable to export the needed path for python. >> >> We cannot set this environment variable by default lest we break other >> packages that may be installed. LD_LIBRARY_PATH is dangerous as it >> tells the runtime linker to prefer libraries in the specified >> directories. >> >> For Guix packages we use different means to embed store paths in >> binaries, which are looked up at runtime. For binaries that’s achieved >> with RUNPATH; for others we patch the sources to ensure that libraries >> are not looked up merely by name but by absolute path. >> >> In your particular case (installing packages without Guix) I think the >> best way is to manually set LD_LIBRARY_PATH on demand, or to set >> LD_PRELOAD to the specific libraries that are required. >> >> In general, though, I recommend using Guix for package management and >> development instead of virtualenv and pip. > > Regarding the improvements of ’guix import pypi’ since 2018, and because > tweaking LD_LIBRARY_PATH is dangerous, I do not see what could be the > next action to solve this. > > Therefore, I propose to close it. WDYT? After 7 weeks of delay, I am closing. Cheers, simon
bug#53225: shepherd freezes if wireguard is started with dns config enabled
Hi, Nathan Dehnel skribis: > When dns is specified, wireguard runs wg-quick, which runs resolvconf, > which runs /run/current-system/profile/bin/herd restart, which causes > shepherd to freeze because I guess it doesn't like being given > multiple start commands at once. I'm not sure how to fix it. What do you mean by “freezing”? Does ‘herd status’ and similar commands block forever? Or is it something else? Requests in the Shepherd are currently handled sequentially. So if you issue several ‘herd restart’ commands, they’ll be processed one at a time. This is usually okay because ‘start’ commands are expected to be quick (just wait for the daemon to write its PID file or similar). Thanks, Ludo’.
bug#52919: Hidden "disk-image-rw" files aren't deleted after use, filling $tmpdir
Hello,
Mathieu Othacehe skribis:
>> Hmm. Can we keep “image” persistent by default, and make ‘vm’ volatile
>> by default? That way, ‘--volatile’ would only make sense for ‘image’,
>> and ‘--persistent’ would only make sense for ‘vm’. (So we’d be adding
>> just one option: ‘--persistent’.)
>>
>> WDYT?
>
> I'm not fan of adding antithetic options: --x and --no-x. There's an
> attached patch introducing --volatile-image and --persistent-vm options,
> and documenting them. It's maybe not that bad after all.
[...]
> From b0c84a411f9f23f4f1a4155ba5efa68cac9004a2 Mon Sep 17 00:00:00 2001
> From: Mathieu Othacehe
> Date: Thu, 13 Jan 2022 11:35:40 +0100
> Subject: [PATCH 1/2] scripts: system: Rationalize persistency.
>
> Make sure that the images are created with a non volatile root by default and
> the vm are created with a volatile root by default. Break the --volatile
> option into --volatile-image and --persistent-vm options.
>
> * guix/scripts/system.scm (perform-action): Turn volatile? argument into
> volatile-vm-root?.
> (show-help): Introduce --volatile-image and --persistent-vm options instead of
> --volatile.
> (%default-options): Adapt it.
> (%options): Handle those options.
> (process-action): Honor them.
> * doc/guix.texi (Invoking guix system): Adapt it accordingly.
It’s maybe not that important but I’m not convinced about the extra
“-image” and “-vm” suffixes; I don’t think it makes things clearer.
[...]
> - (option '("volatile") #f #f
> + (option '("volatile-image") #f #f
> + (lambda (opt name arg result)
> + (alist-cons 'volatile-image-root? #t result)))
As a rule of thumb, we should not remove an option without going through
a deprecation period.
So if we take that route, “volatile” should still be accepted, only with
deprecation warning emitted. We can remove it entirely in 1.5.0 or so.
Thanks!
Ludo’.
bug#53230: Disable authentication seems broken
A day ago I found out that I can't pull/time-machine from my local guix repo with patches. After running guix time-machine -C ./channels ..., guix reported the following: --8<---cut here---start->8--- Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'... guix time-machine: warning: channel authentication disabled Computing Guix derivation for 'x86_64-linux'... - Backtrace: 18 (primitive-load "/home/bob/.config/guix/current/bin/guix") In guix/ui.scm: 2206:7 17 (run-guix . _) 2169:10 16 (run-guix-command _ . _) In ice-9/boot-9.scm: 1752:10 15 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) 1747:15 14 (with-exception-handler # …) In guix/store.scm: 671:3 13 (_) In ice-9/boot-9.scm: 1752:10 12 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _) In guix/store.scm: 658:37 11 (thunk) In guix/status.scm: 802:4 10 (call-with-status-report _ _) In guix/store.scm: 1320:8 9 (call-with-build-handler _ _) 1320:8 8 (call-with-build-handler # …) 2123:24 7 (run-with-store # _ # _ # _ # …) In guix/inferior.scm: 817:16 6 (_ _) In guix/store.scm: 1995:38 5 (_ #) 1468:0 4 (add-temp-root # #) In guix/serialization.scm: 130:20 3 (write-store-path # …) In unknown file: 2 (string->utf8 #) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: In procedure string->utf8: Wrong type argument in position 1 (expecting string): # /gnu/store/3hc33q0xlajd75l52grsg8dg1ais2hss-profile 7f66cb7eaeb0> --8<---cut here---end--->8--- Later I discovered, that the problem isn't related to my local changes, it reproduces with main guix channel too, also, other people on their setups reporting the same problem. Way to reproduce: 1. Find any commit you didn't built guix for earlier. For example a79ad5fce5. 2.1 Update guix to the latest version and do describe under time-machine: guix pull && guix time-machine --commit=a79ad5fce5 --disable-authentication -- describe 2.2 or more preciese and less invasive alternative: guix time-machine --commit=0f869287ebf -- time-machine --commit=a79ad5fce5 --disable-authentication -- describe To be sure, I tried it on a separate machine with only guix channel, which wasn't updated for a while. 2.2 failed the same way as described at the beginning, but when I tried just: guix time-machine --commit=a79ad5fce5 --disable-authentication -- describe it worked. Also, I did similiar test like in 2.1 with guix pull and after that guix pull --roll-back, the result is the same. Skimming throught the latest changes didn't bring any results yet. Bisecting and building guix, will let you know, if/when I find more. -- Best regards, Andrew Tropin signature.asc Description: PGP signature
bug#53180: eog 40.3 build error: include file not found
> Yeah nautilus doesn't build at the moment for a similar reason as eog, I > just posted a patch on https://issues.guix.gnu.org/53195 to fix it. I > can push it shortly. Closing, thanks for fixing it Pierre. Mathieu
bug#52533: guix deploy breaks SSH access with a PAM error
> Regarding the two potential solutions that you proposed in 2018, are > they still actual? If yes, I could maybe try to implement the second > suggestion: introducing service chain-loading. Oh sorry, I stopped reading the thread at https://issues.guix.gnu.org/32182#1. Looks like the service chain-loading might not be enough, I'll keep digging. Thanks, Mathieu
bug#52533: guix deploy breaks SSH access with a PAM error
Hey, > This sounds a lot like this: > > https://issues.guix.gnu.org/32182#1 I was just kicked out of my own server due to this PAM/SSH issue. It happens quite frequently here. Time for a fix :). Regarding the two potential solutions that you proposed in 2018, are they still actual? If yes, I could maybe try to implement the second suggestion: introducing service chain-loading. Thanks, Mathieu
bug#53180: eog 40.3 build error: include file not found
> > Yeah nautilus doesn't build at the moment for a similar reason as eog, I > > just posted a patch on https://issues.guix.gnu.org/53195 to fix it. I > > can push it shortly. > > Closing, thanks for fixing it Pierre. Confirming that gnome-desktop now builds completely, thanks Pierre and Guillaume and all others who participated. Thanks raid5atemyhomework
bug#52919: Hidden "disk-image-rw" files aren't deleted after use, filling $tmpdir
Hey,
> Hmm. Can we keep “image” persistent by default, and make ‘vm’ volatile
> by default? That way, ‘--volatile’ would only make sense for ‘image’,
> and ‘--persistent’ would only make sense for ‘vm’. (So we’d be adding
> just one option: ‘--persistent’.)
>
> WDYT?
I'm not fan of adding antithetic options: --x and --no-x. There's an
attached patch introducing --volatile-image and --persistent-vm options,
and documenting them. It's maybe not that bad after all.
> I would still ensure they have a name like “guix-image-$USER-XXX”, where
> XXX is the store file basename.
Sure.
Thanks,
Mathieu
>From b0c84a411f9f23f4f1a4155ba5efa68cac9004a2 Mon Sep 17 00:00:00 2001
From: Mathieu Othacehe
Date: Thu, 13 Jan 2022 11:35:40 +0100
Subject: [PATCH 1/2] scripts: system: Rationalize persistency.
Make sure that the images are created with a non volatile root by default and
the vm are created with a volatile root by default. Break the --volatile
option into --volatile-image and --persistent-vm options.
* guix/scripts/system.scm (perform-action): Turn volatile? argument into
volatile-vm-root?.
(show-help): Introduce --volatile-image and --persistent-vm options instead of
--volatile.
(%default-options): Adapt it.
(%options): Handle those options.
(process-action): Honor them.
* doc/guix.texi (Invoking guix system): Adapt it accordingly.
---
doc/guix.texi | 15 ++-
guix/scripts/system.scm | 25 +
2 files changed, 27 insertions(+), 13 deletions(-)
diff --git a/doc/guix.texi b/doc/guix.texi
index bc289bad7b..9f763bcfa7 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -35152,6 +35152,11 @@ $ $(guix system vm my-config.scm) -m 1024 -smp 2 -nic user,model=virtio-net-pci
The VM shares its store with the host system.
+By default, the root file system of the VM is mounted volatile; the
+@option{--persistent-vm} option can be provided to make it persistent
+instead. In that case, the VM disk-image file will be copied from the
+store to the @env{TMPDIR} directory to make it writable.
+
Additional file systems can be shared between the host and the VM using
the @option{--share} and @option{--expose} command-line options: the former
specifies a directory to be shared with write access, while the latter
@@ -35189,14 +35194,14 @@ QEMU monitor and the VM.
@cindex Creating system images in various formats
@item image
@cindex image, creating disk images
-The @code{image} command can produce various image types. The
-image type can be selected using the @option{--image-type} option. It
+The @code{image} command can produce various image types. The image
+type can be selected using the @option{--image-type} option. It
defaults to @code{efi-raw}. When its value is @code{iso9660}, the
@option{--label} option can be used to specify a volume ID with
@code{image}. By default, the root file system of a disk image is
-mounted non-volatile; the @option{--volatile} option can be provided to
-make it volatile instead. When using @code{image}, the bootloader
-installed on the generated image is taken from the provided
+mounted non-volatile; the @option{--volatile-image} option can be
+provided to make it volatile instead. When using @code{image}, the
+bootloader installed on the generated image is taken from the provided
@code{operating-system} definition. The following example demonstrates
how to generate an image that uses the @code{grub-efi-bootloader}
bootloader and boot it with QEMU:
diff --git a/guix/scripts/system.scm b/guix/scripts/system.scm
index 98e788c657..3ca5592e34 100644
--- a/guix/scripts/system.scm
+++ b/guix/scripts/system.scm
@@ -772,7 +772,7 @@ (define* (perform-action action image
dry-run? derivations-only?
use-substitutes? target
full-boot?
- volatile?
+ volatile-vm-root?
(graphic? #t)
container-shared-network?
(mappings '())
@@ -827,7 +827,8 @@ (define bootcfg
(mlet* %store-monad
((sys (system-derivation-for-action image action
#:full-boot? full-boot?
-#:volatile? volatile?
+#:volatile?
+volatile-vm-root?
#:graphic? graphic?
#:container-shared-network? container-shared-network?
#:mappings mappings))
@@ -997,7 +998,9 @@ (define (show-help)
(display (G_ "
--no-bootloaderfor 'init', do not install a bootloader"))
(display (G_ "
- --volatile for 'image', make the root file system volatile"))
+ --volatile-image for 'image', make the root file system volatile"))
