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

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

bug#57480: Wrong Type To Apply on Reconfigure

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

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

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):

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

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"

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

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

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

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

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

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.

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

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

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

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

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

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

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--- >

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

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 >

bug#57272: libvirt 8.6 fails to start network

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 >

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

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

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

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

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 ...

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

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

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

bug#57136: Snakemake cannot execute remote jobs

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

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

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

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

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

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

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

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

bug#55848: AArch64 Honeycomb builders are inactive

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.

bug#57071: Xscreensaver not working since latest patch

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

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

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. 

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

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 .

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

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

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

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

bug#56444: Patch to fix Gitolite home directory permissions

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

bug#56444: Patch to fix Gitolite home directory permissions

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

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

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'

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

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