On Mon, May 5, 2025, at 8:58 AM, Ludovic Courtès wrote:
>> 2025-04-25 20:27:40 localhost sshd[234]: fatal:
>> /gnu/store/8kman284vvlzk2hgy1bv1xzys3rfdzlr-openssh-10.0p1/var/empty
>> must be owned by root and not group or world-writable.
>
> D’oh. The fix here is to tell OpenSSH to use /var/empty i
I just switched my Guix System-based server over to unprivileged guix-
daemon, after which I was unable to ssh into it. From the client, the
syndrome looks like this (shell variables indicate redactions):
$ ssh $my_server
kex_exchange_identification: read: Connection reset by peer
Connection rese
On Tue, Sep 3, 2024, at 12:09 PM, Simon Tournier wrote:
>
> Well, this bug seems an instance of bug#47543 [1].
It is not. This bug is "When guix runs out of memory, it prints an error
message that gives the user unhelpful advice." That is not the same as
any particular reason why guix might run
On Tue, Sep 3, 2024, at 10:39 AM, Simon Tournier wrote:
> On Sun, 28 Jul 2024 at 16:02, "Zack Weinberg" via Bug reports for GNU
> Guix wrote:
>
>> Computing Guix derivation for 'x86_64-linux'... \
>> GC Warning: Failed to expand heap by 8388608 byte
I have noticed that when Guix is building derivations, the progress bar
for what it's currently building will often reverse to somewhere between
5% and 50% after reaching 100%. In some cases, such as for guix-packages-
base.drv and guix-packages.drv, this happens several dozen times before
the bui
If a guix operation fails due to running out of memory, it's reported
to the user as an internal error, instructing them to report a bug to
bug-guix. For example:
# guix pull
Updating channel 'guix' from Git repository at
'https://git.savannah.gnu.org/git/guix.git'...
Building from this channel:
On a Guix System installation, "guix graph -t referrers" is not
helpful when the package you're investigating is brought in directly
by the operating-system declaration. Here are two examples.
1) Packages that have been added to the 'packages' property of the
operating-system declaration, but hav
On Mon, Aug 21, 2023, at 3:37 AM, Janneke Nieuwenhuizen wrote:
> It's terrible that guile.m4 has this feature of preferring numbered
> binaries (even if they're later in PATH, and even if that binary
> doesn't match GUILE_LOAD_*PATHs)
I can see why it does this -- it wants to find the newest avai
On Tue, Aug 15, 2023, at 5:33 PM, Ludovic Courtès wrote:
>> The Guile packages currently install all their binaries under their
>> basic name only, e.g.
...
>> This is a problem for building Guix
>> itself from source in a non-pure ‘guix shell -D guix’ on top of a
>> foreign distro that provides a
The Guile packages currently install all their binaries under their
basic name only, e.g.
$ ls /gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin
/gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin:
guild guile guile-config guile-snarf guile-tools
However, the Autoconf macro
After the core-updates merge (specifically after the bump to python 3.10, I
would guess) quodlibet's testsuite has one failing test and therefore the
package fails to build:
=== FAILURES ===
___ TCoverManager.tes
`narinfo-best-uri` ends with
```
(match (sort choices (if fast-decompression? (negate speed)
substitute: In ice-9/boot-9.scm:
substitute: 724:2 15 (call-with-prompt _ _ #)
substitute: In ice-9/eval.scm:
substitute: 619:8 14 (_ #(#(#)))
substitute: In guix/ui.scm:
substitute:2275:7 13
12 matches
Mail list logo
