Sounds good!
signature.asc
Description: PGP signature
Good afternoon! I received this error when trying to run "guix pull" today, and
the report told me to send the output to this address.
Computing Guix derivation for 'x86_64-linux'... -Backtrace:
13 (primitive-load
"/gnu/store/lm4i0rd29gxfahw904gndpwpii7q2qj7-compute-guix-derivation")
On 21-07-2022 19:13, Andrew Tropin wrote:
The source code is here:
https://git.sr.ht/~abcdw/rde/commit/c5b4097ab99309ace23e40d957e9fa1f938f97e9
What's the 'guix-home-gc-roots' for? I would expect the reference
#$(file-append he "/activate") to be sufficient to keep things from
being gc'ed.
On 2022-07-20 20:57, Andrew Tropin wrote:
> On 2022-07-20 11:47, Dale Mellor wrote:
>
>> I would like to be able to create a rescue disk for my system in which
>> the admin user's home directory contains a copy of an encrypted key,
>> for manually unlocking encrypted disk drives.
>>
>> Following
Ludovic Courtès writes:
> Hi,
>
> Chris Keschnat skribis:
>
>> test-name: channel-news, one entry
>> location: /home/ck/tmp/guix/tests/channels.scm:323
>> source:
>> + (test-assert
>> + "channel-news, one entry"
>
> [...]
>
>> + (entry (tag "tag-for-first-news-entry")
During the check phase of building go-1.16.15 (as dependency of
ungoogled-chromium) a failure occurs:
https://dpaste.org/ib5CZ :
--- FAIL: TestTrivialExecutable (3.43s)
shared_test.go:484: file too large: got 202752, want <= 10
--- FAIL: TestTrivialExecutablePIE (0.61s)
On 21-07-2022 18:29, ( wrote:
Not all linkers support linker scripts, e.g. mold doesn't from what I've
read because they make the linker slower.
Would we really need to support anything other than ld, gold, and lld,
though?
-- (
We can choose to not package mold of course, but I think
> We could compile a '__guix_shell_path = "/..."' during the compilation
> of the package (as a .o) and wrap gcc to insert it to the CLI arguments,
> no linker scripts required.
Alas, for some reason I couldn't find any documentation on how to define
strings in a linker script. But never mind
On 21-07-2022 18:13, ( wrote:
Okay, another (hopefully more coherent) proposal: Patch in a
```
extern char *__guix_shell_path;
```
And then, we use a linker script to provide the definition of
__guix_shell_path at linking time. (Unfortunately there's no way to do
this with a flag, afaik...)
Hello everyone,
Ludovic Courtès writes:
> That suggests that this formatting bug was fixed in the meantime, which
> is plausible because a lot of work has gone in the installer since
> 1.3.0.
>
> Josselin, Mathieu, does that ring a bell?
None for me, but it could come from improvements in (gnu
Okay, another (hopefully more coherent) proposal: Patch in a
```
extern char *__guix_shell_path;
```
And then, we use a linker script to provide the definition of
__guix_shell_path at linking time. (Unfortunately there's no way to do
this with a flag, afaik...)
-- (
Hi Peter,
Peter writes:
> To expand on this, Guix installs GRUB. This is undeniable, and this is
> where the problem begins.. over many years users are accustomed to GRUB
> working in a certain way with specific tools.. when they encounter a grub
> installation without grub-mkconfig, etc. they
I must have misunderstood, I thought you wanted to pass it during the build of
glibc.
Le 21 juillet 2022 17:49:36 GMT+02:00, "(" a écrit :
>On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
>> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes. But
>> it's not 'just use
On 21-07-2022 17:49, ( wrote:
On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes. But
it's not 'just use -DSHELL_PATH=', we still need to change 'system'
appropriately.
Why would we need to change it? The glibc definition
Oh! I understand now! The __guix_bin_sh macro would actually be included
in the expansion, not defined during the glibc build. Sorry (again) for
the noise!
-- (
On Thu Jul 21, 2022 at 4:46 PM BST, Maxime Devos wrote:
> Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes. But
> it's not 'just use -DSHELL_PATH=', we still need to change 'system'
> appropriately.
Why would we need to change it? The glibc definition already uses that
macro for
On Thu Jul 21, 2022 at 4:42 PM BST, Julien Lepiller wrote:
> We're trying to avoid hard-coding bash-static in glibc, instead letting the
> build-system fill the value in dependents. So that can't be it, right?
How would it be any different from -D__guix_bin_sh=...? That argument
would simply be
On 21-07-2022 17:11, ( wrote:
couldn't we just use `-DSHELL_PATH=/gnu/store/...`?
Using SHELL_PATH instead of the __guix_bin_sh sounds better, yes. But
it's not 'just use -DSHELL_PATH=', we still need to change 'system'
appropriately.
Would this not violate POSIX? Since, as far as I can
We're trying to avoid hard-coding bash-static in glibc, instead letting the
build-system fill the value in dependents. So that can't be it, right?
Le 21 juillet 2022 17:11:56 GMT+02:00, "(" a écrit :
>
>And considering the definition of system(3) in glibc:
>
>@ sysdeps/posix/system.c (took me
Maxime Devos skribis:
> Why Shepherd and not guile fibers? Is this a Shepherd-specific problem?
Blocking calls are a problem for Fibers in general, and ‘waitpid’ is no
exception.
The problem here is Shepherd-specific in the sense that we’re more
likely to use ‘system*’ and ‘waitpid’ in this
On Thu Jul 21, 2022 at 4:03 PM BST, paren--- via Bug reports for GNU Guix wrote:
> Would this not violate POSIX?
Correction: system(3) is ISO C, not POSIX.
But:
@ C11 7.1.4p1
```
... it is permitted to take the address of a library function even if it
is also defined as a macro ^185 ...
185)
Hi,
elaexuo...@wilsonb.com writes:
> Maxim Cournoyer wrote:
>> I'll see if these Bashisms can be easily switched to POSIX variants,
>> else I'll experiment with setting the shebang of the test scripts to
>> bash.
>
> Is there any particular reason to go this route?
I can think of at least two:
And considering the definition of system(3) in glibc:
@ sysdeps/posix/system.c (took me way too long to find this; glibc's
source code is a maze ;))
```
#define SHELL_PATH "/bin/sh" /* Path of the shell. */
#define SHELL_NAME "sh"/* Name to give it. */
```
On Thu Jul 21, 2022 at 3:52 PM BST, Maxime Devos wrote:
> * Add a macro '#define system ...' that calls this variant and inserts
> __guix_bin_sh as the shell executable
Would this not violate POSIX? Since, as far as I can see,
On 17-06-2022 07:48, Julien Lepiller wrote:
We have bash-minimal and bash-static. The latter is a bit bigger than
the former. Maybe we can keep only bash-minimal?
bash-static is used by glibc (for the 'system' function), it's not
something that can simply be replaced with bash-minimal (due
On 14-07-2022 01:13, Ludovic Courtès wrote:
[...]
Fixed in af4c103595a725194318f40fc5aba110772ff417… except for checking
the name of the variable.
I guess we should stick to the grammar for “names” that Bash defines
(info "(bash) Definitions") and error out if the variable name doesn’t
comply?
Hello,
‘certbot-service-type’ defines an mcron job that invokes ‘certbot’ with
a fairly long list of arguments. However, that command line appears
to be incorrect, or at least it is on bayfront.guix where I tested it:
--8<---cut here---start->8---
27 matches
Mail list logo
