bug#55953: `guix install dub` fails

[Hugo Nobrega]

Hello,

The `dub` package cannot be installed on an up-to-date Guix System. I am
attaching the failed build log, although honestly I couldn't make much
from it.

This of course has implications such as `dub-build-system` not working...

Best wishes,
Hugo



9yj5q4s3vb7gzr8vb9rssz0h9hga71-dub-1.7.2.drv.gz
Description: build log

bug#55951: Lowering an is sensitive to (%current-system)

[Ludovic Courtès]

Consider this file:

--8<---cut here---start->8---
(use-modules (guix))

(lambda ()
  (lower-object (load "overdrive1.scm") "aarch64-linux"))
--8<---cut here---end--->8---

When ran on x86_64-linux, these two commands return different
derivations, contrary to what one might expect:

  guix build -f that-file.scm -d --no-grafts -s aarch64-linux
  guix build -f that-file.scm -d --no-grafts

That demonstrates that the result depends on (%current-system), even
though it shouldn’t because we’re explicitly specifying the system.

This has implications on ‘guix deploy’: if you try to deploy
aarch64-linux boxes from x86_64-linux (say), some of the derivations are
going to be for x86_64-linux instead of aarch64-linux, which can lead to
unbootable systems, as Ricardo reported a while back.

In particular, /gnu/store/…-activate.scm.drv (a direct dependency
/gnu/store/…-system.drv) is one of those derivations sensitive to
(%current-system).

Ludo’.

bug#55949: installing HP printer using Gnome Settings fails

[Attila Lendvai]

i have a HP printer connected on USB, and hplip-minimal is installed.

the printer is detected in Gnome Settings, but installing it fails.

i see the following in the cups log afterwards:

[cups-driverd] Unable to open driver directory 
\"/gnu/store/rwrmqxklbdq85lwjgjl56r9zh54066ra-cups-server-bin/lib/cups/driver\":
 No such file or directory

installing the printer using the CUPS web interface works, and afterwards 
printing works, too.

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“All wars are civil wars, because all men are brothers […] Each one owes 
infinitely more to the human race than to the particular country in which he 
was born.”
— Francois Fenelon

bug#43579: Problem still present

[Andreas Enge]

After removing the patch that works around this problem in fplll
with commit 5dec5f65ec3c7371dde309a101b85b930e423a46, I noticed that it
actually still does occur.

We used to have the problem with gcc-toolchain@10.2 that with test.cpp equal to

#include 
int main() {
   std::fesetround (FE_TONEAREST);
   return 1;
}

the compilation "g++ test.cpp" fails. With gcc-toolchain@10.3 it actually
succeeds.

But with gcc-toolchain@11.3 or @12.1 it fails again.

Indeed,
/gnu/store/bxh206gz379wkn8cvb2ghlkvpqgwfd2v-gcc-toolchain-10.3.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h
contains in line 1572:
#define _GLIBCXX_USE_C99_FENV_TR1 1

whereas
/gnu/store/c17nwiafb01pig2r3mjm1jznfpas61np-gcc-toolchain-12.1.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h
contains in line 1759:
/* #undef _GLIBCXX_USE_C99_FENV_TR1 */

Did we change anything between 10.2 and 10.3, and then revert it with
11.3? Or is it a transient thing that depends on some random ordering of
include files? The latter looks more plausible, since the change from
10.2 and 10.3 really just changes the version and the hash.

What can we do?

Andreas

bug#40641: Building from git breaks when /bin/sh isn't bash

[pelzflorian (Florian Pelz)]

Only the tests are affected, as far as I can tell.  make runs fine.
The issue with “gnu/local.mk” from [1] got fixed in 2019 via
92d00ca4661e186022732a47956a2bc0ef16be96.

But Makefile.am has 

SH_LOG_COMPILER = $(top_builddir)/test-env $(SHELL)
AM_SH_LOG_FLAGS = -x -e

Probably autoconf can be made to detect if $(SHELL) is bash or zsh
somehow™.  But I suppose it is not important and I won’t fix it.

Regards,
Florian

bug#54546: bug#54750: (gnu packages racket) assumes that (ice-9 exceptions) exist, breaks pulling from old Guix

[Maxime Devos]

Thanks!


signature.asc
Description: This is a digitally signed message part

bug#55809: guix challenge with diffoscope fails to clean up temporary directory

[Ludovic Courtès]

Hello,

Vagrant Cascadian  skribis:

> When I run a command such as:
>
>   guix challenge --verbose --diff=diffoscope gavl 2>&1 | tee gavl
>
> It works for the most part, producing the diffoscope output, but ends
> with a bunch of warnings regarding removing the temporary directory it
> created to compare the files:
>
>   warning: failed to delete /tmp/guix-directory.5TokII/share/doc: Permission 
> denied
>   warning: failed to delete /tmp/guix-directory.5TokII/share: Permission 
> denied
>   warning: failed to delete /tmp/guix-directory.5TokII: Directory not empty

Fixed in 2a2856d5ccd9a9b7df8a94333a277b971a39b150, thanks!

Ludo’.

bug#54750: (gnu packages racket) assumes that (ice-9 exceptions) exist, breaks pulling from old Guix

[Ludovic Courtès]

Hi,

For some reason I had not seen this issue earlier; too bad it remained
for this long.

This is now fixed in 8918ce6d1622303465e716ae491b8e5124c7aece.

Thanks,
Ludo’.

bug#53355: guix shell --check: confusing error message

[Ludovic Courtès]

Hi Chris,

Chris Marusich  skribis:

> One alternative method I tried successfully in a variety of shells was
> to use shell redirection (see attached).  I like this approach.
> However, this will only work in shells that support redirection.  I
> recall testing with bash, ash (busybox's shell), dash, zsh, fish, ksh,
> and csh.  I recall that only csh failed, since it doesn't support
> redirection.

That’s a good success list in my view; not being a POSIX shell, (t)csh
was already excluded from the list in the original submission I think:
.

> I personally like the attached patch better than what I proposed
> earlier.  The earlier patch just echoes a few times.  Presumably, it
> only works because the PS1 prompt is likely (but not guaranteed) to be
> emitted before the last of the echo commands finishes printing.  I'd
> rather just control the desired output and ignore PS1 entirely, and that
> is what the attached patch accomplishes using FDs.  However, if support
> for shells without redirection is a requirement, then maybe the original
> hack (echo a few times) is OK, or perhaps we need something else.
>
> How would you like to proceed?  Is it OK to rely on shell redirection?

Yeah, I think so.  This new approach looks more robust.

> From 9a1cef589abf01b61e22656f44c76441f4c50ffd Mon Sep 17 00:00:00 2001
> From: Chris Marusich 
> Date: Fri, 11 Mar 2022 00:20:12 -0800
> Subject: [PATCH] environment: Prevent PS1 from clobbering output in 'check'.
>
> Fixes: .
>
> * guix/scripts/environment.scm (child-shell-environment) [shell-pipe]
> [shell-pipe-in, shell-pipe-out]: New local variables.
> [script]: Redirect the stdout of each command to the file descriptor of the
> shell-pipe-out port.
> [lines]: In the child, close shell-pipe-in before starting the shell.  In the
> parent, close shell-pipe-out before sending the script to the shell.  Read
> lines from shell-pipe-in, not port, so that the shell's PS1 prompt cannot
> clobber the lines.  Close shell-pipe-in just before waiting on the child.

LGTM, please push!

Ludo’.

bug#53225: shepherd freezes if wireguard is started with dns config enabled

[Ludovic Courtès]

Hi,

The /var/log/messages excerpt you sent me has nothing beyond:

> Jun 11 11:43:33 localhost shepherd[1]: Service networking has been started.

[…]

> Jun 11 11:43:33 localhost vmunix: [5.552395] wireguard: WireGuard
> 1.0.0 loaded. See www.wireguard.com for information.
> Jun 11 11:43:33 localhost vmunix: [5.552398] wireguard: Copyright
> (C) 2015-2019 Jason A. Donenfeld . All Rights
> Reserved.
> Jun 11 11:43:33 localhost shepherd[1]: Failed to start wireguard-test
> in the background.

That there’s not a single error message from wireguard doesn’t help.

Mathieu, Guillaume: any idea what might prevent the wireguard Shepherd
service from starting, or how we could gather debugging info?

(Context: .)

Ludo’.

bug#55583:

[Maxime Devos]

retitle 55583 guix-daemon doesn't cleanly error-out on case-sensitive file 
systems.
thanks

(previous command doesn't seem to have worked)


signature.asc
Description: This is a digitally signed message part