Hi Mark,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
>> The bug stems from ‘ld-wrapper-boot0’ and was introduced in
>> d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that
>> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
>>
Hi Ludovic,
l...@gnu.org (Ludovic Courtès) writes:
> The bug stems from ‘ld-wrapper-boot0’ and was introduced in
> d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that
> ‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
> that builds the derivation i.e.,
Hi Mark,
The bug stems from ‘ld-wrapper-boot0’ and was introduced in
d75acc293dd3e63db8739aa04c021df917aa1b80. The problem is that
‘ld-wrapper-boot0’ uses the value of (%current-system) on the machine
that builds the derivation—i.e., hydra.gnu.org.
Instead, it should use the value of the system
Hi Mark,
Mark H Weaver skribis:
> l...@gnu.org (Ludovic Courtès) writes:
[...]
>>> So, if our approach is to use -fno-builtin-strcpy, then we will have to
>>> apply it system-wide, and rebuild all of 'core-updates' from scratch.
>>
>> Another approach would be to patch GCC,
# Begin of terminal interaction
$ strace ".guix-profile/sbin/samba/smbd"
stat64("/gnu/store/...-samba-4.5.0/etc/samba/smb.conf", 0xbfeb41b0) = -1
ENOENT (No such file or directory)
open("/gnu/store/...-samba-4.5.0/etc/samba/smb.conf", O_RDONLY|
O_LARGEFILE) = -1 ENOENT (No such file or directory)
l...@gnu.org (Ludovic Courtès) writes:
> Mark H Weaver skribis:
>
>> Unfortunately, it is too widespread. As I just pointed out in
>>
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24712#13
>>
>> Among the many packages that include these obfuscated store references,
>> one
Commit f1267c872fcaed6c53d43b3ff51abb726f7418d6 on core-updates added a
patch to Mesa on MIPS only, in order to prevent unnecessary rebuilds on
other systems. 'guix' running on a MIPS system generates a derivation
that applies the patch, but the derivation generated for MIPS on Hydra
omits the
Mark H Weaver writes:
> Almost all of the derivations being generated on Hydra for MIPS on the
> 'core-updates' branch differ from what is generated locally by guix on a
> mips64el-linux machine. The differences go at least as far back as
> 'gettext-boot0', where Hydra