When a system wide database exists (at /var/cache/guix/locate/db.sqlite) 'guix
locate --clear' invoked as an unprivileged user tries to write to it and fail.
Steps to reproduce:
- sudo mkdir -p /var/cache/guix/locate
- sudo touch /var/cache/guix/locate/db.sqlite
- guix locate --clear
Observe the e
guix --version
guix (GNU Guix) 812f972f046e521eabc3ddd76e790d7a69d426b5
fibers test suite is hanging so I am skipping it for now.
Also I had to cheat a bit to get past automakes "t/output-order.sh" test where
the guile build driver is leaking "GC Warning: Repeated allocation of very
large block
Hello,
Here are all of the things I had to do to restore the (32bit) Hurd on
core-packages-team branch
- gnumach incompatible with automake@1.17
Our current gnumach does not build with automake@1.17. This got fixed for
gnumach and gnumach-headers in hurd.scm by using automake@1.16.5 but not
After mentioning this on IRC Ludovic pushed
8d31cafbdcb818160852a5d1e6fc24c1a9c53e41 to the shepherd repo.
I wanted to try this out and reconfigured using the shepherd from this commit
as pid1 in the vm (a bit tricky because of help2man).
The first connection still fails in the same way.unexpec
The symlink test failure is even more complex than I thought.
In 2009 there was a patch to gnulib to accept the incorrect EINVAL errno
https://git.savannah.gnu.org/cgit/gnulib.git/commit/tests/test-symlink.h?id=48b0feac54dce2caf46cc53dd160e699737ff52a.
which should never have been passing in the
Hi,
today i reconfigured my system and after a reboot I am unable to use the
guix-daemon on a childhurd.
guix build hello -n
guix build: error: failed to connect to `/var/guix/daemon-socket/socket':
Protocol error
Offloading:
guix offload: error: failed to connect over SSH to daemon at 'local
Hello,
Apr 16, 2025, 20:19 by l...@gnu.org:
> Well there’s ‘guix publish’, and otherwise the examples from
> ‘tests/systemd.sh’ (following ‘define %command’).
>
> Otherwise we could mimic it by writing a C program that that opens a
> SOCK_NONBLOCK socket, binds + listens + select(2) until somethi
Hello,
Apr 19, 2025, 20:42 by l...@gnu.org:
> Hi again,
>
> yelni...@tutamail.com writes:
>
>> Some minor other things:
>> - Currently the NULL byte from the sender is added into the log
>> message, might be worth filtering out
>> - "herd status syslogd" does not show the endpoints and
>> kern
Hello,
After I updated today my hurd-vm is stuck booting.
Looking at the output it seems it is receiving the secrets from the host
correctly but then nothing happens after "Service secret-service-client has
been started"
Not Working: c6ee7b0f79632d50ad491b75c240547be8f40c31
Working: 54cc9c96ec08
Reverting da741d89310efd0530351670d9c55ec2f952ab98 "services: account: Create
/var/guix/profiles/per-user/$USER." fixes this, but I am not sure why.
Finding this was a lot of trial and error (bisecting did now work because of
the python cross compilation failure) but sshd not showing up is caug
Hello
Apr 23, 2025, 20:58 by l...@gnu.org:
> Hey,
>
> yelni...@tutamail.com writes:
>
>> The last thing that still needs fixing is the message-destination
>> procedure in the system-log.sh test. Currently It sends all messages
>> to the $syslog_remote_file if the message has a sender, but arguabl
Hello Ludo,
Apr 13, 2025, 21:09 by l...@gnu.org:
>> + herd -s t-socket-8783 start log-directory-not-writable
>> ++ cat t-log-8783
>> 2025-04-08 07:53:13 GNU Shepherd 1.0.3 (Guile 3.0.9, i586-unknown-gnu)
>> 2025-04-08 07:53:13 Starting service root...
>> 2025-04-08 07:53:13 Service root started
Hello Ludo,
Apr 14, 2025, 13:28 by l...@gnu.org:
> Hi yelninei,
>
> yelni...@tutamail.com writes:
>
FAIL tests/logging-failure.sh (exit status: 124)
>
> [...]
>
>> I was able to reproduce this by extracting the shepherd conf from the
>> test and and attempting to run the test manually
The openssl test issue went away after I updated openssl to 3.4.1
Considering that 3.4.0 is vulnerable to CVE-2024-12797 and CVE-2024-13176
it should probably be upgraded, but I dont know whether to use 3.4.1 or 3.5.0 ?
I reconfigured a minimal server os (basically just openssh and dhcp and and a
For automake@1.17 when I tried to rerun the tests only the t/backcompat2.sh
test was failing.
However this seems to be a transient failure that went away when I retried.
Should flaky tests be disabled?
I dont have the previous logs anymore but iirc there were more failed tests
previously. As t
Hello
Apr 22, 2025, 22:17 by l...@gnu.org:
>
> Can be reproduced with just this:
>
> guile -c '(open "." O_DIRECTORY)'
>
> I think ‘flags_to_mode’ in Guile returns “r” on Linux, which is fine
> because O_RDONLY is set. But on the Hurd, O_RDONLY is not set:
>
> --8<---cut here---
Hello,
Since commit b12d44dd5e35ac236bf3fbb5619b9c8c2f42c902 turned on tests and
switchted to gexps the package no longer cross compiles, which is a dependency
of guile-ssh (and guix).
When cross compiling to a 32bit target (tested with i586-pc-gnu) something goes
wrong ungexp-splicing the ext
This is now fixed in glibc for symlink see
39183b953c68a489cc0b9aefb8974711c834fb38 but should probably be added to
glibc/hurd.
Apr 11, 2025, 10:00 by yelni...@tutamail.com:
> The symlink test failure is even more complex than I thought.
>
> In 2009 there was a patch to gnulib to accept the inc
Something like this fixes my issue.>From c6333e210b6fd38b710800d9fc9b898f9b4409e2 Mon Sep 17 00:00:00 2001
Message-ID:
From: Yelninei
Date: Sun, 13 Apr 2025 09:08:39 +
Subject: [PATCH] locate: Request writable db for --clear.
Fixes https://issues.guix.gnu.org/76141.
* guix/scripts/locate.sc
Hello,
Apr 25, 2025, 17:46 by l...@gnu.org:
> Hi,
>
>> This is now fixed in glibc for symlink see
>> 39183b953c68a489cc0b9aefb8974711c834fb38 but should probably be added to
>> glibc/hurd.
>>
>
> Would you like to prepare a patch for Guix adding this patch to glibc?
>
Sure, I can do that.
I m
Hi Ludo,
Apr 14, 2025, 14:53 by yelni...@tutamail.com:
>
>
>>> The shepherd syslog seems to be extremely slow:
>>>
>>> I extracted the logger.scm and conf.scm from the test, removed the $
>>> from the shell variables variables, started shepherd, echoed the test
>>> msg into the kmsg file and th
Hello,
Apr 15, 2025, 16:08 by l...@gnu.org:
> yelninei--- via Bug reports for GNU Guix writes:
>
>> After mentioning this on IRC Ludovic pushed
>> 8d31cafbdcb818160852a5d1e6fc24c1a9c53e41 to the shepherd repo.
>>
>> I wanted to try this out and reconfigure
Hello,
May 7, 2025, 14:35 by z572@z572.online:
> As far as I know, openssl 3.5 is the lts version and I would tend to
> upgrade to 3.5. Are you interested in sending patches to update it?
>
>
Great, also I had no issues on i586-gnu with 3.5.0 . It will be a while until I
will have an x86-64-lin
I asked about the bison failures on #hurd and ZhaoM tried to rebuild bison on
debian with glibc 2.41 and encountered similar segfaults in the same tests.
I only had one additional failure than them that also was not failing when I
initially checked this. After retrying on a childhurd from master
Some more info for bison:
May 7, 2025, 17:18 by yelni...@tutamail.com:
> I asked about the bison failures on #hurd and ZhaoM tried to rebuild bison on
> debian with glibc 2.41 and encountered similar segfaults in the same tests.
>
>
One that is easy to reproduce is
22 Undefined Symbols (input.at
May 11, 2025, 10:02 by yelni...@tutamail.com:
> One that is easy to reproduce is
> 22 Undefined Symbols (input.at:1013)
>
> It tries to parse this file:
> input.y
>
> %printer {} foo baz
> %destructor {} bar
> %type qux
> %%
> exp: bar;
>
> Starting program:
> /gnu/store/myb2g81i62fclqf0w9rm
Hi Ludo,
Thank you again for finding the cause.Could we add your patch to our hurd
either for master or core-packages-team as it will be a while until it is
available in a tagged snapshot.It would fix the hurd ci builders randomly
failing, the childhurd system test and the minor annoyance that
Hi Ludo,
Apr 28, 2025, 14:28 by yelni...@tutamail.com:
>
>
>> Actually, on ‘core-packages-team’, we should merge ‘glibc’ and
>> ‘glibc/hurd’ since they only differ by Hurd-specific patches.
>>
>
> That would be great but I would love to have the bison issue fully solved
> before to not cause inc
My patches from #78471 have been applied, I think I caught all the major
regressions so I am closing this
Hello Ludo,
Something like this? I called the patch hurd-socket-activation.patch to
indicate what it is addressing. Do you have a better suggestion?
I added it to master but this will create a minor merge conflict with the hurd
update on core-packages-team.
May 14, 2025, 21:51 by l...@gnu.org:
30 matches
Mail list logo
