bug#57402: FreeCAD build fails to configure / Qt5WebKitWidgets related.

[Thiago Jung Bauermann via Bug reports for GNU Guix]

Hello Marcel,

Marcel van der Boom  writes:

> The freecad package fails to build. The following error is the 
> relevant part from the log.
>
> I'm on powerpc64le, which is usually somewhat problematic in 
> building. Not sure if that is relevant for this issue though.
>
> CMake Error at cMake/FreeCAD_Helpers/SetupQt.cmake:28 
> (find_package):
>   By not providing "FindQt5WebKitWidgets.cmake" in 
>   CMAKE_MODULE_PATH this
>   project has asked CMake to find a package configuration file 
>   provided by
>   "Qt5WebKitWidgets", but CMake did not find one.
>
>   Could not find a package configuration file provided by 
>   "Qt5WebKitWidgets"
>   with any of the following names:
>
> Qt5WebKitWidgetsConfig.cmake
> qt5webkitwidgets-config.cmake
>
>   Add the installation prefix of "Qt5WebKitWidgets" to 
>   CMAKE_PREFIX_PATH or
>   set "Qt5WebKitWidgets_DIR" to a directory containing one of the 
>   above
>   files.  If "Qt5WebKitWidgets" provides a separate development 
>   package or
>   SDK, be sure it has been installed.
> Call Stack (most recent call first):
>   CMakeLists.txt:69 (include)
>
>
> -- Configuring incomplete, errors occurred!

Is this on master, or core-updates? On master, freecad-0.20.1 builds
fine on x86_64-linux, but on powerpc64le-linux it doesn't get built
because of a dependency failure:

--8<---cut here---start->8---
*** HDF-SD test fails ***
make[5]: *** [Makefile:1202: hdftest.chkexe_] Error 1
make[5]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[4]: *** [Makefile:1188: build-check-s] Error 2
make[4]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[3]: *** [Makefile:1183: test] Error 2
make[3]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[2]: *** [Makefile:999: check-am] Error 2
make[2]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf/test'
make[1]: *** [Makefile:428: check-recursive] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-hdf4-alt-4.2.14.drv-0/hdf-4.2.14/mfhdf'
make: *** [Makefile:515: check-recursive] Error 1

Test suite failed, dumping logs.
error: in phase 'check': uncaught exception:
%exception #< program: "make" arguments: ("check") exit-status: 2 
term-signal: #f stop-signal: #f>
phase `check' failed after 8.3 seconds
command "make" "check" failed with status 2
builder for `/gnu/store/1szzq357gdplnjd15kbs2m5zb3xrdz7q-hdf4-alt-4.2.14.drv' 
failed with exit code 1
build of /gnu/store/1szzq357gdplnjd15kbs2m5zb3xrdz7q-hdf4-alt-4.2.14.drv failed
View build log at 
'/var/log/guix/drvs/1s/zzq357gdplnjd15kbs2m5zb3xrdz7q-hdf4-alt-4.2.14.drv.gz'.
cannot build derivation 
`/gnu/store/a8df1igdk1b15x06bkk7rvyq1maqkf8v-netcdf-4.7.4.drv': 1 dependencies 
couldn't be built
applying 2 grafts for postgresql-13.7 ...
cannot build derivation 
`/gnu/store/35bapv6z5fsalaxapmhymj7m8z8yrjph-freecad-0.20.1.drv': 1 
dependencies couldn't be built
guix build: error: build of 
`/gnu/store/35bapv6z5fsalaxapmhymj7m8z8yrjph-freecad-0.20.1.drv' failed
--8<---cut here---end--->8---

Unfortunately I can't test on core-updates because of a kernel issue on
guixp9 which triggers a libaio testsuite failure, and thus most of
core-updates is unbuildable there...

-- 
Thanks
Thiago

bug#57480: Wrong Type To Apply on Reconfigure

[Christopher Rodriguez]

Hello All,

A change made in b084398 is preventing both my system and home
configurations from building with a Wrong Type to Apply error. Did the
channel spec format change with the changes in that commit?

Here's my channels.scm: https://paste.debian.net/1252097/

And here's the error message for any commit after b084398:
https://paste.debian.net/1252096/


--

Christopher Rodriguez


signature.asc
Description: PGP signature

bug#57479: Inkscape can't find python-lxml

[Leo Famulari]

I'm not able to create QR codes in Inkscape.

I try to create a QR code in Inkscape by going through these menus:
Extensions -> Render -> Barcode -> QR Code

But, when I click "Apply" to create the QR code, Inkscape prints an
error message like this:

--
Traceback (most recent call last):
  File 
"/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/render_barcode_qrcode.py",
 line 30, in 
import inkex
  File 
"/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/__init__.py",
 line 11, in 
from .extensions import *
  File 
"/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/extensions.py",
 line 34, in 
from .elements import (
  File 
"/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/elements/__init__.py",
 line 9, in 
from ._parser import SVG_PARSER, load_svg
  File 
"/gnu/store/crndrs40jrk5ddfxi7569123lbibhz42-inkscape-1.2.1/share/inkscape/extensions/inkex/elements/_parser.py",
 line 30, in 
from lxml import etree
ModuleNotFoundError: No module named 'lxml'
--

Any ideas?

bug#57478: meson-build-system's shrink-path phase can fail

[Maxim Cournoyer]

Hi,

Maxim Cournoyer  writes:

> Hi,
>
> While updating Mutter to version 42.4, I encountered this:
>
> starting phase `shrink-runpath'
> error: in phase 'shrink-runpath': uncaught exception:
> wrong-type-arg "struct-vtable" "Wrong type argument in position ~A (expecting 
> ~A): ~S" (1 "struct" #f) (#f) 
> phase `shrink-runpath' failed after 0.0 seconds
> Backtrace:
>   10 (primitive-load "/gnu/store/l5ri9gc942zpr8hqags8gl66ck0…")
> In guix/build/gnu-build-system.scm:
> 906:2  9 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> In ice-9/boot-9.scm:
>   1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
> 634:9  7 (for-each # …)
> In ice-9/boot-9.scm:
>   1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
> In guix/build/gnu-build-system.scm:
>927:23  5 (_)
> In guix/build/meson-build-system.scm:
> 105:2  4 (shrink-runpath #:elf-directories _ #:outputs _)
> In srfi/srfi-1.scm:
> 634:9  3 (for-each # (("out" . #)))
> 634:9  2 (for-each # ("/gnu/s…" …))
> 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 struct-vtable: Wrong type argument in position 1 (expecting 
> struct): #f
> builder for `/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' 
> failed with exit code 1
> @ build-failed /gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv - 
> 1 builder for `/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' 
> failed with exit code 1
> derivation '/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' 
> offloaded to 'localhost' failed: build of 
> `/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' failed
> build of /gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv failed
> View build log at 
> '/var/log/guix/drvs/r5/w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv'.
>
> I do not have the head clear enough to pursue investigating this now,
> but it should be reproducible by undeleting the shrink-path phase of the
> mutter 42.4 update that I should push soon.
>
> Thanks,
>
> Maxim

It seems this was caused by Mutter using '-Wl,--disable-new-dtags' as a
linker flag, which was causing no runpath to be registered by our linker
script.

That's a pathological case, but perhaps we could fail more gracefully
and provide a hint.

Thanks,

Maxim

bug#57478: meson-build-system's shrink-path phase can fail

[Maxim Cournoyer]

Hi,

While updating Mutter to version 42.4, I encountered this:

--8<---cut here---start->8---
starting phase `shrink-runpath'
error: in phase 'shrink-runpath': uncaught exception:
wrong-type-arg "struct-vtable" "Wrong type argument in position ~A (expecting 
~A): ~S" (1 "struct" #f) (#f) 
phase `shrink-runpath' failed after 0.0 seconds
Backtrace:
  10 (primitive-load "/gnu/store/l5ri9gc942zpr8hqags8gl66ck0…")
In guix/build/gnu-build-system.scm:
906:2  9 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  8 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9  7 (for-each # …)
In ice-9/boot-9.scm:
  1752:10  6 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   927:23  5 (_)
In guix/build/meson-build-system.scm:
105:2  4 (shrink-runpath #:elf-directories _ #:outputs _)
In srfi/srfi-1.scm:
634:9  3 (for-each # (("out" . #)))
634:9  2 (for-each # ("/gnu/s…" …))
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 struct-vtable: Wrong type argument in position 1 (expecting 
struct): #f
builder for `/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' 
failed with exit code 1
@ build-failed /gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv - 1 
builder for `/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' 
failed with exit code 1
derivation '/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' 
offloaded to 'localhost' failed: build of 
`/gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv' failed
build of /gnu/store/r5w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv failed
View build log at 
'/var/log/guix/drvs/r5/w8fl87b1ps7rdj9cn6w198qik5i9x5-mutter-42.4.drv'.
--8<---cut here---end--->8---

I do not have the head clear enough to pursue investigating this now,
but it should be reproducible by undeleting the shrink-path phase of the
mutter 42.4 update that I should push soon.

Thanks,

Maxim

bug#56444: [EXT] Re: [EXT] Re: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[zimoun]

Hi David,

On lun., 29 août 2022 at 09:59, "Thompson, David"  
wrote:

> To any other maintainer or core dev: If any of you wants to sign off on
> this patch as-is, I'll merge it.  I have commit access.

I am not maintainer, Maxime neither AFAIK, and I am not a “core dev“
neither.  For what it is worth, your patch LGTM; please push.

The patch seems a pragmatic workaround waiting an implementation more
robust as Maxime has proposed.  Feel free to send here or open another
submission for this upcoming “better” fix.

BTW, unrelated but Gitolite in Guix requires some love.  If you have
time, a look at bug#25957 [1] would be appreciated. :-)

Cheers,
simon

1: 

bug#57306: guix pull to old commit fails due to unsupported manifest format

[zimoun]

Hi,

On mar., 30 août 2022 at 01:07, Arun Isaac  wrote:

> Thanks, Josselin! I have asked at #56441 whether it may be reopened.

>From my understanding, it is another side effect of
4ff12d1de7cd617b791996ee7ca1240660b4c20e.  Commit
9b8c442b254b82196fe2492142b3c3bbbd891a1b is the parent of 4ff12d.


Using a recent commit,

--8<---cut here---start->8---
$ guix describe
Generation 6août 19 2022 12:36:01   (current)
  guix 65cabb0
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 65cabb010e3388d10f9b25ec560bfcfab5f810d4
--8<---cut here---end--->8---

‘generate-package-cache’ passes…

--8<---cut here---start->8---
$ guix pull --commit=9b8c442b254b82196fe2492142b3c3bbbd891a1b -p 
/tmp/old-ko-describe

[...]

$ /tmp/old-ko-describe/bin/guix describe
guix describe: error: unsupported manifest format
--8<---cut here---end--->8---

…but not “guix describe”.  Indeed, version 4:

--8<---cut here---start->8---
$ cat /tmp/old-ko-describe/manifest | grep -A 1 '(manifest'
(manifest
  (version 4)
--8<---cut here---end--->8---


Note that,

--8<---cut here---start->8---
$ guix pull --commit=4ff12d1de7cd617b791996ee7ca1240660b4c20e -p /tmp/old-ok

$ /tmp/old-ok/bin/guix describe
Generation 1août 29 2022 22:49:56   (current)
  guix 4ff12d1
repository URL: https://git.savannah.gnu.org/git/guix.git
commit: 4ff12d1de7cd617b791996ee7ca1240660b4c20e

$ /tmp/old-ok/bin/guix pull --commit=9b8c442b254b82196fe2492142b3c3bbbd891a1b 
-p /tmp/old-ko
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   9b8c442
Computing Guix derivation for 'x86_64-linux'... -
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://bordeaux.guix.gnu.org'... 100.0%
The following derivation will be built:
  /gnu/store/r5qk23fibxn5ryd2k7b8qkbryqv4m3ds-profile.drv

building package cache...
|builder for 
`/gnu/store/19nk2x26s0dp68r7d36ifbg0ck0q3xps-guix-package-cache.drv' failed to 
produce output path 
`/gnu/store/axqgrls563slnp76x60dqlv7sdwcm2ly-guix-package-cache'
build of /gnu/store/19nk2x26s0dp68r7d36ifbg0ck0q3xps-guix-package-cache.drv 
failed
View build log at 
'/var/log/guix/drvs/19/nk2x26s0dp68r7d36ifbg0ck0q3xps-guix-package-cache.drv.gz'.
cannot build derivation 
`/gnu/store/r5qk23fibxn5ryd2k7b8qkbryqv4m3ds-profile.drv': 1 dependencies 
couldn't be built
guix pull: error: build of 
`/gnu/store/r5qk23fibxn5ryd2k7b8qkbryqv4m3ds-profile.drv' failed
--8<---cut here---end--->8---


Well, it appears to me easier if bug#57306 remains closed since ’guix
time-machine’ is fixed; as it was the subject.


Cheers,
simon

bug#55898: Services depending on new Shepherd features may fail until reboot

[Maxim Cournoyer]

Hi Ludovic,

Ludovic Courtès  writes:

> Hi,
>
> Maxim Cournoyer  skribis:
>
>> Ludovic Courtès  writes:
>
> [...]
>
>>> Yes.  The issue is that we’re more free-style than systemd: we’re
>>> basically loading code live in the running Shepherd.  So we have to
>>> write that code such that it works with older Shepherd versions.
>>>
>>> This is why we have things like conditions on
>>>
>>>   (defined? 'make-inetd-constructor)
>>>
>>> and the likes, with a fallback.
>>
>> I saw that used somewhere, but I still think a minimally required
>> Shepherd version field could be of use on services, for the following
>> reasons:
>>
>> 1. Otherwise each services are left implementing ad-hoc solutions.
>>
>> 2. It's more complicated to be compatible with two Shepherd version than
>> simply mentioning the minimum version required, and prevent the service
>> from running until it is satisfied (especially on a system like Guix
>> System where we *know* what is the current version of Shepherd
>> available).
>
> I think it’s a situation similar to “feature tests vs. identity tests”
> in build system configuration (checking whether the libc function you
> want to use is available rather than checking whether ‘uname’ returns
> “Linux”), and for the same reason I tend to prefer feature tests as
> shown above.

Agreed, but the context differs wildly: while Autoconf or browsers for
example really are facing a diversity of configuration, the version of
Shepherd used in Guix System is known and controlled.  So the only
problems bound to happen are in this context:

1. New Shepherd version introduced in Guix (package upgrade).

2. New Shepherd features used by services.

3. Machine reconfigured using a commit including 1 and 2.

The problems are temporary: upon a reboot the running Shepherd version
will be the latest, and have all the features needed.

Hence my suggestion to use something simple to improve the user
experience of a user faced with 3.

> I won’t pretend it’s pretty :-), but I don’t see an improvement feasible
> in the short term.
>
> In the long term, maybe we’d want the service API in the Shepherd to be
> more declarative, more like packages in Guix.  But that’s more for a 2.0
> horizon IMO.
>
> Perhaps we should close this issue unless it becomes actionable?

It's a relatively narrow use case and it's relatively rare too, but I'd
err on keeping it open until it gets fixed, whether in a definitive
fashion or as a more limited one to help users facing 3. above.

Thanks, and welcome back!

Maxim

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

Hi zimoun,

> I do not think it is related to guix-daemon and I think it is expected;
> indeed it could be considered as a bug.  The command-line,
>
> guix pull --commit=xyz -p /tmp/test
>
> writes /tmp/test/manifest using the current Guix (say manifest 4) and
> not using Guix at commit xyz (say manifest 3).  Contrary to “guix
> time-machine --commit=xyz”.

Ah, that makes sense! Any ideas as to how this issue might be fixed?

Thanks,
Arun

bug#57306: guix pull to old commit fails due to unsupported manifest format

[Arun Isaac]

Thanks, Josselin! I have asked at #56441 whether it may be reopened.

bug#57306: guix pull to old commit fails due to unsupported manifest format

[zimoun]

Hi Arun,

On sam., 20 août 2022 at 15:07, Arun Isaac  wrote:
> When I guix pull to 6f75565b4ec3b8a7247699c327a3b3196c787f76, activate
> the profile and run guix describe, it fails with an "unsupported
> manifest format" error.
>
> --8<---cut here---start->8---
> $ guix pull --commit=6f75565b4ec3b8a7247699c327a3b3196c787f76 -p
> /tmp/test
> $ source /tmp/test/etc/profile
> $ guix describe
> guix describe: error: unsupported manifest format
> --8<---cut here---end--->8---
>
> This happens because my guix-daemon writes a version 4 manifest and the
> guix from commit 6f75565b4ec3b8a7247699c327a3b3196c787f76 only
> understands a version 3 manifest.

I do not think it is related to guix-daemon and I think it is expected;
indeed it could be considered as a bug.  The command-line,

guix pull --commit=xyz -p /tmp/test

writes /tmp/test/manifest using the current Guix (say manifest 4) and
not using Guix at commit xyz (say manifest 3).  Contrary to “guix
time-machine --commit=xyz”.

--8<---cut here---start->8---
$ cat 
~/.cache/guix/inferiors/cfcv5rt7xiax6pvdqwoad3hdrsqrpl34z2tufvtcb7nspeum5cba/manifest
;; This file was automatically generated and is for internal use only.
;; It cannot be passed to the '--manifest' option.
;; Run 'guix package --export-manifest' if you want to export a file
;; suitable for '--manifest'.

(manifest
  (version 3)
  (packages
(("guix"
  "6f75565"
  "out"
  "/gnu/store/3nfgbg6nd6vq9im8fp97h6h5zm1rvhzh-guix-6f75565b4"
  (propagated-inputs ())
  (search-paths ())
  (properties
(source
  (repository
(version 0)
(url "https://git.savannah.gnu.org/git/guix.git;)
(branch #f)
(commit
  "6f75565b4ec3b8a7247699c327a3b3196c787f76")
(name guix)
(introduction
  (channel-introduction
(version 0)
(commit
  "9edb3f66fd807b096b48283debdcddccfea34bad")
(signer
  "BBB0 2DDF 2CEA F6A8 0D1D  E643 A2A0 6DF2 A33A 54FA"))
--8<---cut here---end--->8---


Cheers,
simon

bug#57436: Running ./configure from `guix shell -D guix --pure` errors

[zimoun]

Hi,

On sam., 27 août 2022 at 09:56, Katherine Cox-Buday  
wrote:

> This turned out to be the issue. I discovered my shell startup files were
> mis-configured by running `guix shell --pure --check -D guix`. This is
> definitely a user error, and my fault, but maybe we should update the manual
> to include the `--check` flag?

Well, “guix shell” should hint a ’--check’ the first time you run it.
And is the explanation about ’--check’ (section Invoking guix shell) not
clear?

Do you mean update the «Building from Git» section?


Cheers,
simon

bug#57272: libvirt 8.6 fails to start network

[Marius Bakke]

Hi, thanks for the bug report, and sorry for the breakage.

Lars-Dominik Braun  skriver:

> Hi,
>
> after the update to libvirt 8.6.0 in
> 3a76c2bfd94557c9776aa11240fec14580aec1b0 networks don’t start any more:
>
> > LANG=C virsh net-start default
> error: Failed to start network default
> error: Unable to find 'dnsmasq' binary in $PATH: No such file or directory
>
> I tried to patch dnsmasq’s path like follows, but then the testcase
> networkxml2conftest fails and cannot find dnsmasq either.

I don't understand why that test is failing with your patch.  It has a
hard coded "/usr/sbin/dnsmasq", but patching that does not make a
difference.  It seems the lookup via virFindFileInPath, which ultimately
calls out to GLib's g_find_program_in_path, fails; but ostensibly using
an absolute file name should not make a difference[0].

  [0]: https://docs.gtk.org/glib/func.find_program_in_path.html

Anyway, I was able to reproduce the failure in the system test:

--8<---cut here---start->8---
diff --git a/gnu/tests/virtualization.scm b/gnu/tests/virtualization.scm
index 4bd56e5d9d..557f30db4f 100644
--- a/gnu/tests/virtualization.scm
+++ b/gnu/tests/virtualization.scm
@@ -106,6 +106,26 @@ (define marionette
  "-c" "qemu:///system" "connect"))
  marionette))
 
+  (test-eq "create default network"
+0
+(marionette-eval
+ '(begin
+(chdir "/tmp")
+(system* #$(file-append libvirt "/bin/virsh")
+ "-c" "qemu:///system" "net-define"
+ #$(file-append libvirt
+
"/etc/libvirt/qemu/networks/default.xml")))
+ marionette))
+
+  (test-eq "start default network"
+0
+(marionette-eval
+ '(begin
+(chdir "/tmp")
+(system* #$(file-append libvirt "/bin/virsh")
+ "-c" "qemu:///system" "net-start" "default"))
+ marionette))
+
   (test-end
 
   (gexp->derivation "libvirt-test" test))
--8<---cut here---end--->8---

And can confirm your patch fixes that, which is arguably more important.
So I went ahead and committed your patch (and disabled the failing
test), and the system test to avoid future regressions in this area.

Fixed in:

  acbf2f9def gnu: libvirt: Use absolute dnsmasq.
  3e0abde17b tests: libvirt: Ensure the default network can be started.


signature.asc
Description: PGP signature

bug#57477: "guix refresh -u" sometimes 'unmirrors' source URLs

[Maxime Devos]

I think I've found a solution: extract some mirror://-generating code 
from check-mirror-url and use it in check-mirror-url. Currently trying 
this out ...


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57477: "guix refresh -u" sometimes 'unmirrors' source URLs

[Maxime Devos]

The 'change to generic-html' plan didn't work out, generic-html has the 
same problem ...


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57477: "guix refresh -u" sometimes 'unmirrors' source URLs

[Maxime Devos]

On 29-08-2022 19:30, Maxime Devos wrote:

As noted in #57463 (https://issues.guix.gnu.org/57463#1) by Marius Bakke:


The updater has a tendency to change the URI from mirror:// to the
resolved URL, which can be easy to miss when staging the patch.

(it would be nice to fix that bug)

TBI ...

Greetings,
Maxime

This happens for the gnu-ftp updater, which is according to a comment 
next to its definition, obsolescent. I'll try changing the packages to 
use the generic-html updater instead, maybe gnu-ftp can be removed 
afterwards ...


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57477: "guix refresh -u" sometimes 'unmirrors' source URLs

[Maxime Devos]

The problem appears to be that latest-ftp-release in (guix 
gnu-maintenance) always constructs a ftp:// URL, even if mirror:// is 
desired.


Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57477: "guix refresh -u" sometimes 'unmirrors' source URLs

[Maxime Devos]

As noted in #57463 (https://issues.guix.gnu.org/57463#1) by Marius Bakke:


The updater has a tendency to change the URI from mirror:// to the
resolved URL, which can be easy to miss when staging the patch.

(it would be nice to fix that bug)

TBI ...

Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#57136: Snakemake cannot execute remote jobs

[Konrad Hinsen]

The bug is fixed via the patch referenced above in commit 
5831155175614726685edab7efa60ce48e4da1f5.

bug#56444: [EXT] Re: [EXT] Re: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Thompson, David]

On Mon, Aug 29, 2022 at 9:44 AM Maxime Devos  wrote:

> As there appears to be a lack of willingness to invest the tiniest bit of
> extra effort to implement a proper patch, and given the length of previous
> discussion, I think my time will be better spent continuing fixing things
> in Guix rather than any failing attempts at convincing you. As such, I'll
> stop responding until a v2 or questions on how to implement a v2, but that
> cannot be interpreted as me agreeing with you.
>

>From my perspective, there is a lack of willingness on your end to accept
imperfect solutions that have low impact.  In projects I maintain and in
the professional world, I try to acknowledge the work someone has already
done and accept patches/pull requests that are not ideal but solve real
world problems.  I'd be happy to do some follow-up work to make
system-level improvements when I have the time to properly test a change
that impacts literally everyone that uses the Guix distro, but it would
have been great to have improved the gitolite service in the meantime.
If/when I get around to doing this work, I'll send along a patch.

To any other maintainer or core dev: If any of you wants to sign off on
this patch as-is, I'll merge it.  I have commit access.

- Dave

bug#56444: [EXT] Re: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Maxime Devos]

On 29-08-2022 15:30, Thompson, David wrote:


On Mon, Aug 29, 2022 at 9:19 AM Maxime Devos  
wrote:


On 29-08-2022 14:57, Thompson, David wrote:

> I disagree.  I believe we shouldn't let perfect be the enemy of
the good.

I don't think your patch counts as "good" here -- while fixing the
bug
counts as "good", you are at the same time introducing a new bug (the
non-atomicity), which is bad.  You would have to weigh the
goodness and
the badness to end up with an overall "good" (or maybe "bad",
depending
on the conclusion), but I'd think that the time required to do such a
weighing is better spent by doing a tiny bit of extra effort to
implement the new field (it should be very low effort, see other
response).


My patch has a very limited scope of only changing the gitolite 
service.  Your proposal has a much greater scope of modifying a core 
structure used for system configuration.

It is a greater scope, but it's not really more effort.
The new bug you mention is only bad in a theoretical sense.  In 
practice, the permission bits are misconfigured for a blip of time 
during system reconfiguration, which is a lot better than being 
misconfigured all the time which is the status quo.  It's the 
difference between a gitolite that works nicely with cgit/gitweb and 
one that doesn't. I agree that it's a good goal to improve atomicity 
and I think making  more general to allow for different 
permission bits on the home directory is a good idea, but I see it as 
one step removed from fixing this particular bug.


The time required to analyse it as "just theoretical" could have been 
spent doing the tiny bit of extra effort.


Theoretical bugs like these are especially nasty, if you encounter them 
there is often not a clue what the cause is unless you already know what 
to look for.


  My patch follows the recommended approach outlined in a comment in 
(gnu build activation) written by Ludovic in 2019:


      ;; Always set ownership and permissions for home directories of 
system

      ;; accounts.  If a service needs looser permissions on its home
      ;; directories, it can always chmod it in an activation snippet.


I've refuted that recommendation (albeit without explicitly mentioning 
that paragraph), that paragraph is a bug, see my previous comments on 
non-atomicity. Please remove it in the v2 patch.


As there appears to be a lack of willingness to invest the tiniest bit 
of extra effort to implement a proper patch, and given the length of 
previous discussion, I think my time will be better spent continuing 
fixing things in Guix rather than any failing attempts at convincing 
you. As such, I'll stop responding until a v2 or questions on how to 
implement a v2, but that cannot be interpreted as me agreeing with you.


Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#55898: Services depending on new Shepherd features may fail until reboot

[Ludovic Courtès]

Hi,

Maxim Cournoyer  skribis:

> Ludovic Courtès  writes:

[...]

>> Yes.  The issue is that we’re more free-style than systemd: we’re
>> basically loading code live in the running Shepherd.  So we have to
>> write that code such that it works with older Shepherd versions.
>>
>> This is why we have things like conditions on
>>
>>   (defined? 'make-inetd-constructor)
>>
>> and the likes, with a fallback.
>
> I saw that used somewhere, but I still think a minimally required
> Shepherd version field could be of use on services, for the following
> reasons:
>
> 1. Otherwise each services are left implementing ad-hoc solutions.
>
> 2. It's more complicated to be compatible with two Shepherd version than
> simply mentioning the minimum version required, and prevent the service
> from running until it is satisfied (especially on a system like Guix
> System where we *know* what is the current version of Shepherd
> available).

I think it’s a situation similar to “feature tests vs. identity tests”
in build system configuration (checking whether the libc function you
want to use is available rather than checking whether ‘uname’ returns
“Linux”), and for the same reason I tend to prefer feature tests as
shown above.

I won’t pretend it’s pretty :-), but I don’t see an improvement feasible
in the short term.

In the long term, maybe we’d want the service API in the Shepherd to be
more declarative, more like packages in Guix.  But that’s more for a 2.0
horizon IMO.

Perhaps we should close this issue unless it becomes actionable?

Thanks,
Ludo’.

bug#56444: [EXT] Re: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Thompson, David]

On Mon, Aug 29, 2022 at 9:19 AM Maxime Devos  wrote:

> On 29-08-2022 14:57, Thompson, David wrote:
>
> > I disagree.  I believe we shouldn't let perfect be the enemy of the good.
>
> I don't think your patch counts as "good" here -- while fixing the bug
> counts as "good", you are at the same time introducing a new bug (the
> non-atomicity), which is bad.  You would have to weigh the goodness and
> the badness to end up with an overall "good" (or maybe "bad", depending
> on the conclusion), but I'd think that the time required to do such a
> weighing is better spent by doing a tiny bit of extra effort to
> implement the new field (it should be very low effort, see other response).
>

My patch has a very limited scope of only changing the gitolite service.
Your proposal has a much greater scope of modifying a core structure used
for system configuration.  The new bug you mention is only bad in a
theoretical sense.  In practice, the permission bits are misconfigured for
a blip of time during system reconfiguration, which is a lot better than
being misconfigured all the time which is the status quo.  It's the
difference between a gitolite that works nicely with cgit/gitweb and one
that doesn't. I agree that it's a good goal to improve atomicity and I
think making  more general to allow for different permission
bits on the home directory is a good idea, but I see it as one step removed
from fixing this particular bug.  My patch follows the recommended approach
outlined in a comment in (gnu build activation) written by Ludovic in 2019:

  ;; Always set ownership and permissions for home directories of system
  ;; accounts.  If a service needs looser permissions on its home
  ;; directories, it can always chmod it in an activation snippet.

- Dave

bug#55848: AArch64 Honeycomb builders are inactive

[Ludovic Courtès]

Hello!

Ludovic Courtès  skribis:

> I’m currently reconfiguring pankow and grunewald⁰ from berlin with ‘guix
> deploy’ to include the fix above¹, but it’s gonna take a while as it’s
> currently building GCC…

That eventually succeeded and pankow is now reconfigured with the right
daemon settings. \o/

In the meantime, grunewald went off-line so I can’t tell if it’s
properly reconfigured, and kreuzberg is still running the old config I
believe (I cannot log in).

Ricardo, do you have access to these two?

Cheers,
Ludo’.

bug#57071: Xscreensaver not working since latest patch

[Ludovic Courtès]

Heya,

Ludovic Courtès  skribis:

> Rick Huijzer  skribis:
>
>> It seems that xscreensaver-auth needs to be setuid instead of the main
>> xscreensaver binary. The screen-locker-service in xorg.scm sets the
>> provided package setuid and sets the required pam configuration for the
>> provided package. The problem is that the pam configuration needs to be set
>> for xscreensaver (/etc/pam.d/xscreensaver) and setuid needs to be set for
>> xscreensaver-auth.
>>
>> Interestingly when I setuid xscreensaver-auth manually I run into the
>> following when unlocking:
>> Aug 10 13:35:02 localhost unix_chkpwd[2197]: check pass; user unknown
>> Aug 10 13:35:02 localhost unix_chkpwd[2197]: password check failed for user
>> (rhuijzer)
>> Aug 10 13:35:02 localhost xscreensaver-auth: pam_unix(xscreensaver:auth):
>> authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost=
>>  user=rhuijzer
>>
>> But this might be fixed in time by [RFC PATCH] gnu: linux-pam: Change path
>> to unix_chkpwd helper .
>>
>> I don't know how to fix this elegantly, maybe create a dedicated service
>> for xscreensaver instead of the standard screen-locker-service?
>
> Yes, either that or a special case in ‘screen-locker-service’.

With the attached patch I can make ‘xscreensaver-auth’ setuid-root
(which is optional: it’s needed to tweak OOM behavior) while keeping the
‘xscreensaver’ PAM entry that’s needed.

However, authentication’s still failing due to ‘unix_chkpwd’ not working
on current ‘master’ where  is
missing.

Ideas on how to work around that?  It’s not clear to me how
‘unix_chkpwd’ ends up being invoked in the first place…

Thanks,
Ludo’.

diff --git a/gnu/packages/xdisorg.scm b/gnu/packages/xdisorg.scm
index 7be995a438..72698aa28a 100644
--- a/gnu/packages/xdisorg.scm
+++ b/gnu/packages/xdisorg.scm
@@ -1655,8 +1655,16 @@ (define-public xscreensaver
(lambda _
  (substitute* '("driver/Makefile.in" "po/Makefile.in.in")
(("@GTK_DATADIR@") "@datadir@")
-   (("@PO_DATADIR@") "@datadir@"))
- #t)))
+   (("@PO_DATADIR@") "@datadir@"
+ (add-before 'configure 'adjust-default-path
+   (lambda _
+ ;; On Guix System, give higher precedence to the setuid-root
+ ;; 'xscreensaver-auth' program compared to the one that lives in
+ ;; $libexecdir.  This modifies code in the 'hack_environment'
+ ;; function, which changes $PATH.
+ (substitute* "driver/xscreensaver.c"
+   (("= DEFAULT_PATH_PREFIX")
+"= \"/run/setuid-programs:\" DEFAULT_PATH_PREFIX")
#:configure-flags '("--with-pam"
 
;; Don't check /proc/interrupts in the build
@@ -1704,7 +1712,11 @@ (define-public xscreensaver
 (license (license:non-copyleft
   (string-append
"http://metadata.ftp-master.debian.org/changelogs/;
-   "/main/x/xscreensaver/xscreensaver_5.36-1_copyright")
+   "/main/x/xscreensaver/xscreensaver_5.36-1_copyright")))
+(properties
+ ;; Tell 'screen-locker-service' which program should be setuid-root.
+ '((screen-locker-setuid-program
+. "libexec/xscreensaver/xscreensaver-auth")
 
 (define-public xssproxy
   (package
diff --git a/gnu/services/xorg.scm b/gnu/services/xorg.scm
index 0cbd9aa53b..8f99c0f023 100644
--- a/gnu/services/xorg.scm
+++ b/gnu/services/xorg.scm
@@ -1,6 +1,6 @@
 ;;; GNU Guix --- Functional package management for GNU
 ;;; Copyright © 2017 Andy Wingo 
-;;; Copyright © 2013, 2014, 2015, 2016, 2017, 2019, 2020 Ludovic Courtès 
+;;; Copyright © 2013-2017, 2019-2020, 2022 Ludovic Courtès 
 ;;; Copyright © 2015 Sou Bunnbu 
 ;;; Copyright © 2018, 2019 Timothy Sample 
 ;;; Copyright © 2019 Jan (janneke) Nieuwenhuizen 
@@ -680,12 +680,26 @@ (define slim-service-type
 ;;;
 
 (define-record-type 
-  (screen-locker name program empty?)
+  (screen-locker name package empty?)
   screen-locker?
   (namescreen-locker-name) ;string
-  (program screen-locker-program)  ;gexp
+  (package screen-locker-package)  ;file-like
   (empty?  screen-locker-allows-empty-passwords?)) ;Boolean
 
+(define (screen-locker-setuid-program-name locker)
+  "Return the name of the setuid program of LOCKER.  It's usually LOCKER's
+name but it might differ in some cases--e.g., 'xscreensaver-auth' for
+XScreenSaver."
+  (let ((package (screen-locker-package locker)))
+(or (and (package? package)
+ (assoc-ref (package-properties package)
+'screen-locker-setuid-program))
+(string-append "bin/" (screen-locker-name locker)
+
+(define (screen-locker-setuid-program locker)
+  (file-append (screen-locker-package locker) "/"
+   (screen-locker-setuid-program-name locker)))
+
 (define screen-locker-pam-services
  

bug#56444: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Maxime Devos]

On 29-08-2022 14:57, Thompson, David wrote:


I disagree.  I believe we shouldn't let perfect be the enemy of the good.


I don't think your patch counts as "good" here -- while fixing the bug 
counts as "good", you are at the same time introducing a new bug (the 
non-atomicity), which is bad.  You would have to weigh the goodness and 
the badness to end up with an overall "good" (or maybe "bad", depending 
on the conclusion), but I'd think that the time required to do such a 
weighing is better spent by doing a tiny bit of extra effort to 
implement the new field (it should be very low effort, see other response).


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56444: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Maxime Devos]

On 29-08-2022 14:57, Thompson, David wrote:

[...]
Can any other maintainers please chime in here?


To correct a misunderstanding, I'm not a maintainer, at least if you 
meant "maintainer" in the same sense as used at 
.


Greetings,
Maxime




OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56444: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Maxime Devos]

On 29-08-2022 14:57, Thompson, David wrote:

Hi Maxime,

I disagree.  I believe we shouldn't let perfect be the enemy of the 
good.  I haven't sent patches to Guix in quite some time, but I've 
never felt roadblocked like this and it is concerning to me.


It's almost trivial to implement 'the perfect' here, almost no more 
effort than your partial solution; there is no "perfect enemy of the 
good" situation here -- "perfect enemy of the good" only applies when 
"the perfect" is significantly harder / more effort than "the good", but 
that's not the case here.


Given that a proper fix is very easy, simple and low-effort and 
furthermore, it is even known what form the proper fix would take (see: 
extra field, + adjust procedure in (gnu build activation) slightly), 
there aren't any roadblocks except for an apparent refusal by you to 
invest a little extra effort.


If you genuinely find it actually hard to implement, please tell so and 
I can give you some pointers on what procedures appear to be need to be 
modified. Currently, your response appears to be made in bad faith t me.


Greetings,
Maxime



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56444: [EXT] Re: bug#56444: Patch to fix Gitolite home directory permissions

[Thompson, David]

Hi Maxime,

I disagree.  I believe we shouldn't let perfect be the enemy of the good.
I haven't sent patches to Guix in quite some time, but I've never felt
roadblocked like this and it is concerning to me.

Can any other maintainers please chime in here?

- Dave

On Mon, Aug 29, 2022 at 8:52 AM Maxime Devos  wrote:

>
> On 29-08-2022 14:49, Thompson, David wrote:
> > Hi again Maxime,
> >
> > What do you think of my proposal?  Do any other maintainers care to
> > chime in here?
> >
> > - Dave
>
> Backlogged thing have a tendency to be backlogged indefinitely, and my
> proposal for a home-permissions-bits seems straightforward and simple to
> me, so I would rather not trade a bug for another bug but rather do a
> proper fix.
>
> Greetings,
> Maxime.
>

bug#56444: Patch to fix Gitolite home directory permissions

[Maxime Devos]

On 29-08-2022 14:49, Thompson, David wrote:

Hi again Maxime,

What do you think of my proposal?  Do any other maintainers care to 
chime in here?


- Dave


Backlogged thing have a tendency to be backlogged indefinitely, and my 
proposal for a home-permissions-bits seems straightforward and simple to 
me, so I would rather not trade a bug for another bug but rather do a 
proper fix.


Greetings,
Maxime.


OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

bug#56444: Patch to fix Gitolite home directory permissions

[Thompson, David]

Hi again Maxime,

What do you think of my proposal?  Do any other maintainers care to chime
in here?

- Dave

On Tue, Aug 23, 2022 at 10:45 AM Thompson, David 
wrote:

> Hi Maxime,
>
> On Tue, Aug 23, 2022, 8:41 AM Maxime Devos  wrote:
>
>>
>> During "guix system reconfigure", there is now window where the
>> directory temporarily has incorrect bits and hence if gitolite is
>> restarted during that time it will presumably fail.  Could a
>> 'home-permission-bits' or such field be added instead to 
>> to make things atomic?
>>
>
> That would be a nice improvement to backlog now that such a use case has
> emerged. However, I think for our immediate needs this one line patch,
> while imperfect, solves a longstanding problem adequately. So how about
> merging it, closing this bug, and opening a new bug for the system level
> improvement?
>
> - Dave
>

bug#57467: [EXT] Re: bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Thompson, David]

Hi Maxime,

On Mon, Aug 29, 2022 at 6:29 AM Maxime Devos  wrote:

> On 29-08-2022 03:28, Thompson, David wrote:
>
> Hi again,
>
> I decided to just implement the fix and see what people think of it.
> Simply removing a check for non-interactive invocation solves the issue and
> now 'guix shell' and 'guix shell -- make' act exactly the same except for
> which command they run.  Patch attached.
>
> The interactive check is a feature, not a bug:
>
Could you please explain why it's a feature? I've provided an example that
shows how it is confusing and unexpected.

> https://issues.guix.gnu.org/50960#69:
> [...]
> Agreed. The automatic reading of guix.scm/manifest.scm, if we keep it,
> should only happen in interactive use; I’ll double-check and make sure
> this is the case.
>
> It might still be possible to solve 57467, but I don't think this patch is
> the solution.
>

Could you propose an alternate solution?  What are the next steps here?
Right now all I know is that you don't like my patch.

- Dave

bug#57467: 'guix shell' does not honor default behavior when given a specific command to run

[Maxime Devos]

On 29-08-2022 03:28, Thompson, David wrote:

Hi again,

I decided to just implement the fix and see what people think of it.  
Simply removing a check for non-interactive invocation solves the 
issue and now 'guix shell' and 'guix shell -- make' act exactly the 
same except for which command they run.  Patch attached.



The interactive check is a feature, not a bug:


https://issues.guix.gnu.org/50960#69:
[...]
Agreed. The automatic reading of guix.scm/manifest.scm, if we keep it,
should only happen in interactive use; I’ll double-check and make sure
this is the case.
It might still be possible to solve 57467, but I don't think this patch 
is the solution.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature