bug#48392: Guile 3.0.7 fails to build on ci.guix.gnu.org

[Leo Famulari]

On Wed, May 12, 2021 at 09:34:15PM -0400, Leo Famulari wrote:
> Guile 3.0.7 failed to build on the build farm, during the test suite.
> 
> There's nothing to link to on ci.guix.gnu.org because Cuirass can't
> evaluate Guix without Guile.
> 
> I've attached the build log.

I logged in to berlin.gnu.org and tried building the Guile derivation
again. It failed once, then succeeded, then failed a few more times. So
there is some nondeterminism in the test suite.

At least now there is a substitute for it.


signature.asc
Description: PGP signature

bug#48393: Can't build installer on aarch64 / v86d fails to build on aarch64

[Leo Famulari]

I tried building the installer on my aarch64 computer, but it fails to
build v86d, as shown below.

This package v86d is used in the installer's uvesafb-shepherd-service
service, which is supposed to not be used on aarch64 (the 'start' action
of the service limits use to Intel-compatible systems).

--
$ guix system image -t iso9660 gnu/system/install.scm -v3
[...]
starting phase `build'
make -e -w -C libs/lrmi-0.10 liblrmi.a
/gnu/store/ap7hgyv4rjqmhg4a6cb6cypsh3g1f5q4-gcc-7.5.0/bin/gcc -Wall -g -O2 
-I/lib/modules/5.11.19-gnu/source/include -Ilibs/lrmi-0.10 -c -o v86_lrmi.o 
v86_lrmi.c
make[1]: Entering directory 
'/tmp/guix-build-v86d-0.1.10.drv-0/v86d-0.1.10-checkout/libs/lrmi-0.10'
/gnu/store/ap7hgyv4rjqmhg4a6cb6cypsh3g1f5q4-gcc-7.5.0/bin/gcc -c  -g -Wall -o 
lrmi.o lrmi.c
/gnu/store/ap7hgyv4rjqmhg4a6cb6cypsh3g1f5q4-gcc-7.5.0/bin/gcc -Wall -g -O2 
-I/lib/modules/5.11.19-gnu/source/include -Ilibs/lrmi-0.10 -c -o v86_common.o 
v86_common.c
/gnu/store/ap7hgyv4rjqmhg4a6cb6cypsh3g1f5q4-gcc-7.5.0/bin/gcc -Wall -g -O2 
-I/lib/modules/5.11.19-gnu/source/include -Ilibs/lrmi-0.10 -c -o v86.o v86.c
lrmi.c:1093:2: warning: #warning "LRMI is not supported on your system!" [-Wcpp]
 #warning "LRMI is not supported on your system!"
  ^~~
In file included from v86_lrmi.c:2:0:
libs/lrmi-0.10/lrmi.h:105:2: warning: #warning "LRMI is not supported on your 
system!" [-Wcpp]
 #warning "LRMI is not supported on your system!"
  ^~~
ar -rs liblrmi.a lrmi.o
In file included from v86_lrmi.c:3:0:
v86.h:8:10: fatal error: config.h: No such file or directory
 #include "config.h"
  ^~
In file included from v86_common.c:2:0:
v86.h:8:10: fatal error: config.h: No such file or directory
 #include "config.h"
  ^~
compilation terminated.
compilation terminated.
make: *** [Makefile:40: v86_lrmi.o] Error 1
ar: make: *** Waiting for unfinished jobs
creating liblrmi.a
make: *** [Makefile:40: v86_common.o] Error 1
make[1]: Leaving directory 
'/tmp/guix-build-v86d-0.1.10.drv-0/v86d-0.1.10-checkout/libs/lrmi-0.10'
In file included from v86.c:17:0:
v86.h:8:10: fatal error: config.h: No such file or directory
 #include "config.h"
  ^~
compilation terminated.
make: *** [Makefile:40: v86.o] Error 1
command "make" "-j" "4" failed with status 2
builder for `/gnu/store/ll2g97yxbqrqr4vsn0i5zjhdf3dbigpq-v86d-0.1.10.drv' 
failed with exit code 1
build of /gnu/store/ll2g97yxbqrqr4vsn0i5zjhdf3dbigpq-v86d-0.1.10.drv failed
View build log at 
'/var/log/guix/drvs/ll/2g97yxbqrqr4vsn0i5zjhdf3dbigpq-v86d-0.1.10.drv.bz2'.
cannot build derivation 
`/gnu/store/afv6x2id02mldbyirv59d7q3vwabkd27-shepherd-maybe-uvesafb.scm.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/fx3cfyff5lcgjd1dr3j2088cgsii0x7n-shepherd-maybe-uvesafb.go.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/3bbh5zpifch3jrb1g050pn5hvsza5dfq-shepherd.conf.drv': 1 dependencies 
couldn't be built
cannot build derivation `/gnu/store/gnrykng6fgcqg75z26gfyjcnbd3j7gx2-boot.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/yxikf0sqa67ydlbfk99dkw7brh5bg4a8-system.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/dzs47c2p79cj8yycmnxirab3xamcfsy6-image.iso.drv': 1 dependencies 
couldn't be built
guix system: error: build of 
`/gnu/store/dzs47c2p79cj8yycmnxirab3xamcfsy6-image.iso.drv' failed
--

bug#48391: FYI: Guix 1.3.0 "guix pull" error

[ogmtau via Bug reports for GNU Guix]

Installed Guix 1.3.0 on bare metal, not in a virtual machine.

Attached file guix-pull-error.txt is console output.

Attached file lshw.txt is output from the lshw command.

=
λf.(λx.f(xx))(λx.f(xx)) ᚛ᚄᚂᚐᚅ  ᚐᚌᚐᚈ᚜

Sent with [ProtonMail](https://protonmail.com) Secure Email.tdr@idpdguix ~$ guix pull
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to 696cf48 (5 new commits)...
Building from this channel:
  guix  https://git.savannah.gnu.org/git/guix.git   696cf48
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 compute-guix-derivation  1KiB  
 89KiB/s 
00:00 [##] 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 po4a-0.61  1.6MiB  
1.8MiB/s 
00:01 [##] 100.0%
building /gnu/store/l3k1n1d8zxni80jpxxgzjqrg5yzaj7sl-guile-3.0.7.drv...
/ 'check' phaseBacktrace:
  13 (primitive-load 
"/gnu/store/2pwr6pr8x583x0fl1wlr9cah6nr46fkk-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2076:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1910:8  7 (_ _)
In ./guix/gexp.scm:
   256:18  6 (_ _)
   1137:2  5 (_ _)
   1003:2  4 (_ _)
849:4  3 (_ _)
In ./guix/store.scm:
  1958:12  2 (_ #)
   1372:5  1 (map/accumulate-builds # _ _)
  1383:15  0 (_ # _ _)

./guix/store.scm:1383:15: ERROR:
  1. &store-protocol-error:
  message: "build of 
`/gnu/store/qn3022kzrgwzyh1g551zz2yx7n61c8cr-guix-daemon-1.3.0-1.771b866.drv' 
failed"
  status: 100
guix pull: error: You found a bug: the program 
'/gnu/store/2pwr6pr8x583x0fl1wlr9cah6nr46fkk-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"696cf48b98ad4ef03c88cdb5a83c739618c8fa16"; system: "x86_64-linux";
host version: "1.3.0"; pull-version: 1).
Please report it by email to .

tdr@idpdguix ~$ 
idpdguix
description: Notebook
product: 80SA (LENOVO_MT_80SA_BU_idea_FM_Lenovo ideapad FLEX 4-1470)
vendor: LENOVO
version: Lenovo ideapad FLEX 4-1470
serial: MP13CE9P
width: 64 bits
capabilities: smbios-2.8 dmi-2.8 smp vsyscall32
configuration: administrator_password=disabled boot=normal chassis=notebook 
family=IDEAPAD frontpanel_password=disabled keyboard_password=disabled 
power-on_password=disabled sku=LENOVO_MT_80SA_BU_idea_FM_Lenovo ideapad FLEX 
4-1470 uuid=3C72F22F-5B1E-E611-B27E-1C3947C5F5C7
  *-core
   description: Motherboard
   product: Lenovo ideapad F
   vendor: LENOVO
   physical id: 0
   version: SDK0J40709 WIN
   serial: MP13CE9P
   slot: Type2 - Board Chassis Location
 *-firmware
  description: BIOS
  vendor: LENOVO
  physical id: 0
  version: 0VCN18WW(V1.03)
  date: 05/17/2016
  size: 128KiB
  capacity: 6MiB
  capabilities: pci upgrade shadowing cdboot bootselect edd 
int13floppynec int13floppytoshiba int13floppy360 int13floppy1200 int13floppy720 
int13floppy2880 int9keyboard int10video acpi usb biosbootspecification uefi
 *-cpu
  description: CPU
  product: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
  vendor: Intel Corp.
  physical id: 4
  bus info: cpu@0
  version: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
  serial: To Be Filled By O.E.M.
  slot: U3E1
  size: 2719MHz
  capacity: 4005MHz
  width: 64 bits
  clock: 100MHz
  capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 
apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht 
tm pbe syscall nx pdpe1gb rdtscp x86-64 constant_tsc art arch_perfmon pebs bts 
rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 
monitor ds_cpl est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic 
movbe popcnt aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault 
epb invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx 
rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida 
arat pln pts hwp hwp_notify hwp_act_window hwp_epp cpufreq
  configuration: cores=2 enabledcores=2 threads=4
*-cache:0
 description: L1 cache
 physical id: 6
 slot: L1 Cache
  

bug#48390: bug

[Florian Hoertlehner]

guix pull: error: You found a bug: the program
'/gnu/store/2pwr6pr8x583x0fl1wlr9cah6nr46fkk-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"696cf48b98ad4ef03c88cdb5a83c739618c8fa16"; system: "x86_64-linux";
host version: "f09e4dd8ea6b86ecbae9c90e0316f6fa44b546d6"; pull-version: 1).

bug#48389: Guix pull failed

[Michael Jury]

guix pull: error: You found a bug: the program
'/gnu/store/0bgadpjvbbr1cs2pr9z4kqizx3k7smil-compute-guix-derivation'
failed to compute the derivation for Guix (version:
"6a724b0277f31245a0573c8347a6462786d7c0d1"; system: "x86_64-linux";
host version: "55aa50834fe07597adddbfc4e007de9420b195ec"; pull-version: 1).
Please report it by email to .

Let me know if you want the backtrace or anything else

-- 
Best
-Michael Jury
"The question isn't who will let me, the question is who will stop me."

bug#48392: Guile 3.0.7 fails to build on ci.guix.gnu.org

[Leo Famulari]

Guile 3.0.7 failed to build on the build farm, during the test suite.

There's nothing to link to on ci.guix.gnu.org because Cuirass can't
evaluate Guix without Guile.

I've attached the build log.


k1n1d8zxni80jpxxgzjqrg5yzaj7sl-guile-3.0.7.drv.gz
Description: application/gunzip


signature.asc
Description: PGP signature

bug#48214: inetutils 1.9.4 builds successfully

[Bone Baboon via Bug reports for GNU Guix]

Closing bug#48214 because inetutils 1.9.4 now builds successfully even
with IPv6 disabled.

bug#48214: inetutils-1.9.4 build fails

[Bone Baboon via Bug reports for GNU Guix]

I have done several pulls since reporting that inetutils failed to
build.  I can now build inetutils-1.9.4 successfully.  I still have IPv6
disabled. I do not know what the cause of the build failure was.  I do
not know why it can now build (likely a recent commit).

Bone Baboon via Bug reports for GNU Guix writes:

> On a x86_64 computer when I run `guix build --no-substitutes --keep-failed 
> inetutils` the build fails because of one failed test.
>
> `guix describe` outputs:
>
> ```
> Generation 18   May 03 2021 13:15:55(current)
>   guix 065d2cd
> repository URL: https://git.savannah.gnu.org/git/guix.git
> commit: 065d2cd6ced96ddb38c15a46f798488f61660a33
> ```
>
> Error message:
>
> ```
> command "make" "check" failed with status 2
> note: keeping build directory `/tmp/guix-build-inetutils-1.9.4.drv-0'
> builder for `/gnu/store/immphxs1iknnz5rfdhcs4i62j22yshqx-inetutils-1.9.4.drv' 
> failed with exit code 1
> build of /gnu/store/immphxs1iknnz5rfdhcs4i62j22yshqx-inetutils-1.9.4.drv 
> failed
> View build log at 
> '/var/log/guix/drvs/im/mphxs1iknnz5rfdhcs4i62j22yshqx-inetutils-1.9.4.drv.bz2'.
> guix build: error: build of 
> `/gnu/store/immphxs1iknnz5rfdhcs4i62j22yshqx-inetutils-1.9.4.drv' failed
> ```
>
> Test suite contents:
>
> ```
> ===
>GNU inetutils 1.9.4: tests/test-suite.log
> ===
>
> # TOTAL: 15
> # PASS:  8
> # SKIP:  6
> # XFAIL: 0
> # FAIL:  1
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> SKIP: ping-localhost.sh
> ===
>
> ping needs to run as root
> SKIP ping-localhost.sh (exit status: 77)
>
> SKIP: traceroute-localhost.sh
> =
>
> traceroute needs to run as root
> SKIP traceroute-localhost.sh (exit status: 77)
>
> SKIP: tftp.sh
> =
>
> The use of the superserver Inetd in this script requires
> the availability of "/etc/nsswitch.conf", "/etc/passwd", and
> "/etc/protocols".  At least one of these is now missing.
> Therefore skipping test.
> SKIP tftp.sh (exit status: 77)
>
> FAIL: syslogd.sh
> 
>
> ../src/logger: ::1:7041: Cannot assign requested address
> Registered 24 successes out of 25.
> NOTICE: Standard port test was not run.
> Failing some tests.
> FAIL syslogd.sh (exit status: 1)
>
> SKIP: ftp-localhost.sh
> ==
>
> The use of the superserver Inetd in this script requires
> the availability of "/etc/nsswitch.conf", "/etc/passwd", and
> "/etc/protocols".  At least one of these is now missing.
> Therefore skipping test.
> SKIP ftp-localhost.sh (exit status: 77)
>
> SKIP: inetd.sh
> ==
>
> This test requires the availability of "/etc/protocols",
> a file which can not be found in the current system.
> Therefore skipping this test.
> SKIP inetd.sh (exit status: 77)
>
> SKIP: telnet-localhost.sh
> =
>
> No TTY assigned to this process.  Skipping test.
> SKIP telnet-localhost.sh (exit status: 77)
> ```

bug#48343: Cannot boot after installation

[pelzflorian (Florian Pelz)]

On Wed, May 12, 2021 at 03:33:51PM -0400, Bone Baboon via Bug reports for GNU 
Guix wrote:
> Sergey Petrov writes:
> > but terminal only, my WM (Enlightenment) cannot initialize. I think I
> > can give a try to some other WMs and check how it goes.
> 
> You may find this has useful information in regards to getting a
> graphical environment working:
> https://lists.gnu.org/archive/html/help-guix/2021-04/msg00220.html

Another WM would be the leaner solution, however maybe uvesafb (which
is also used in the installer image) can help you set up GNOME etc.:

https://lists.gnu.org/archive/html/bug-guix/2020-04/msg00320.html

Regards,
Florian

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Simon Streit]

Ludovic Courtès  writes:

> Hi,
>
> Simon Streit  skribis:
>
>> Then it was suggested I checkout to commit
>> dd14678b9b9843be20e2bbb98ceb30d2433dab82 and force downgrade my new
>> system.  While doing so, I noticed that guix-daemon would still offload,
>> while if I'd type in `guix offload test`, I'd get a response:
>>
>> guix offload: testing 1 build machines defined in '/etc/guix/machines.scm'...
>> guix offload: Guix is usable on 'host' (test returned 
>> "/gnu/store/883yjkl46dxw9mzykykmbs0yzwyxm17z-test")
>> guix offload: 'host' is running GNU Guile 3.0.5
>> guix offload: error: failed to connect over SSH to daemon at 'host', socket 
>> /var/guix/daemon-socket/socket
>>
>> Anyway, back to this old commit offloading works for all users.
>>
>> The commit with this broken behaviour is at:
>> 87b4b0e4385149b40ee87ae2d57712679452746b.
>
> Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02.  Let me know if it
> works for you!

Offloading works with this commit!  Thanks
>
> Thanks,
> Ludo’.

bug#48343: Cannot boot after installation

[Bone Baboon via Bug reports for GNU Guix]

Looks like you are running into many of the problems I had when I
installed Guix on a computer.

Sergey Petrov writes:
> Hi Brendan! It works, I can proceed to system now
>
> On 5/12/21 10:17 PM, Brendan Tildesley wrote:
>> If setting nomodeset is the answer, there is a trick you can use in
>> GRUB to set it before boot.
>> Apparently in GRUB, you:
>>
>> 1. Press e
>> 2. Edit the linux ... line to add nomodeset as an option
>> 3. Press ctrl X
>>
>> I just found the instructions here
>> https://duckduckgo.com/?q=grub+nomode+set 
>> 

If you were able to manually use nomodeset in Grub then you should be
able to add that snippet for the Linux kernel argument nomodeset that I
shared and reconfigure your system.  Then you will not need to manually
enter nomodeset in Grub each time you boot.

> but terminal only, my WM (Enlightenment) cannot initialize. I think I
> can give a try to some other WMs and check how it goes.

You may find this has useful information in regards to getting a
graphical environment working:
https://lists.gnu.org/archive/html/help-guix/2021-04/msg00220.html

bug#48343: Cannot boot after installation

[Sergey Petrov]

Thanks, I've planned to read docs about it right after I can boot to guix :)

On 5/12/21 4:24 AM, Ludovic Courtès wrote:

Hi Sergey,

Sergey Petrov  skribis:


Hm, I've added these lines to the etc/config.scm, tried to boot again
and it doesn't seem to change anything...

Note that /etc/config.scm doesn’t have any effect in itself.  You need
to run ‘guix system reconfigure /etc/config.scm’ to deploy the changes
you made.

HTH,
Ludo’.

bug#48343: Cannot boot after installation

[Sergey Petrov]

Hi Brendan! It works, I can proceed to system now, but terminal only, my 
WM (Enlightenment) cannot initialize. I think I can give a try to some 
other WMs and check how it goes.


On 5/12/21 10:17 PM, Brendan Tildesley wrote:
If setting nomodeset is the answer, there is a trick you can use in 
GRUB to set it before boot.

Apparently in GRUB, you:

1. Press e
2. Edit the linux ... line to add nomodeset as an option
3. Press ctrl X

I just found the instructions here 
https://duckduckgo.com/?q=grub+nomode+set 



At least give that a go and report back if it works.

bug#48374: Found a bug, apparently.

[Merazi via Bug reports for GNU Guix]

Hello!,

So I did a guix pull, and I got a message asking me to upload the bug report, 
so here I am.
The message is as follows:
merazi@guix~$ guix pull
Updating channel 'nonguix' from Git repository at 
'https://gitlab.com/nonguix/nonguix'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Authenticating channel 'guix', commits 9edb3f6 to b7cbca2 (95 new commits)...
Building from these channels:
  guix  https://git.savannah.gnu.org/git/guix.git b7cbca2
  nonguix   https://gitlab.com/nonguix/nonguix 95c8e6e
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/23bwjp2sb8bxhwm08mmsvchjw4kk40a3-module-import.drv...
building /gnu/store/d2mxbqyyazv7y6v74nx9rv3cdmlk9h4m-module-import.drv...
building 
/gnu/store/m4km1wc3a2ihy949rm6kr37r6sm8782p-module-import-compiled.drv...
building 
/gnu/store/dmxi573n198radcgv08km8cm14q4a0nz-module-import-compiled.drv...
building 
/gnu/store/808h6rppqfi9ckfva3jzawka5svw0026-compute-guix-derivation.drv...
Computing Guix derivation for 'x86_64-linux'... -Backtrace:
  13 (primitive-load 
"/gnu/store/kk145kjq49xmwhdasmh7ah95a3r2ws7r-compute-guix-derivation")
In ice-9/eval.scm:
    155:9 12 (_ _)
    159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
    152:2 10 (with-fluid* _ _ _)
    152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2076:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1910:8  7 (_ _)
In ./guix/gexp.scm:
   256:18  6 (_ _)
   1137:2  5 (_ _)
   1003:2  4 (_ _)
    849:4  3 (_ _)
In ./guix/store.scm:
  1958:12  2 (_ #)
   1372:5  1 (map/accumulate-builds # _ _)
  1383:15  0 (_ # _ _)

./guix/store.scm:1383:15: ERROR:
  1. &store-protocol-error:
  message: 
"`/gnu/store/jbm45plkq6fc9ypb05lm3jp6c5v6jvfn-guix-1.2.0-21.4dff6ec/bin/guix 
substitute' died unexpectedly"
  status: 1
guix pull: error: You found a bug: the program 
'/gnu/store/kk145kjq49xmwhdasmh7ah95a3r2ws7r-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"b7cbca221f74e9e9ef43c228dca9fa9930babec5"; system: "x86_64-linux";
host version: "1.2.0-21.4dff6ec"; pull-version: 1).
Please report it by email to .

--
Merazi

bug#48380: Guix 1.3 installer restarts after Partitioning Scheme

[alphantom--- via Bug reports for GNU Guix]

Here's how I reproduced the possible bug:

Locale: English
Locale Location: United States
Choose Graphical Install
Timezone: *not included due to privacy*
Layout: English (US)
Variant: English (US)
Hostname: *Anything*
Internet Access: Wifi
Substitute server discovery: Disable
System Admin Password
User Creation
Desktop Environment: Emacs EXWM
Network Service: OpenSSH, Mozilla NSS Cert
Partitioning Method: Guided - using entire disk with encryption
Disk: select hard drive
Partitioning Scheme: Everything in one partition

** It then goes black**

You end up on back on Locale

-- 
 Sent with Tutanota, the secure & ad-free mailbox: 
 https://tutanota.com

bug#48373: vice: processor dependency?

[Leo Famulari]

On Tue, May 11, 2021 at 06:33:07PM -0800, Christopher Howard wrote:
> As a guess, I suspect your build made use of some advanced multimedia
> CPU flag not available on my computer.

I'd guess that the problem is that it's being built with -march=native,
which the build logs show.

We'll need to disable this so it is instead built generically.

If you grep for "march=native" in gnu/packages, you'll find examples of
how that can be accomplished.

bug#48373: vice: processor dependency

[Brendan Tildesley via Bug reports for GNU Guix]

This is the build log from the server. there may be clues here if it differs 
from yours:

https://ci.guix.gnu.org/build/290428/log/raw

bug#48373: vice: processor dependency

[Christopher Howard]

Hello, I ran the following:

guix gc -D $(guix build --no-grafts vice); guix build --no-substitutes
vice
guix challenge vice

The result of the last command was

/gnu/store/ixsr68sfkyfvp66mzg6291sv2gbdwvzc-vice-3.5 contents differ:
  local hash: 1gw2m26g506fivlki829h4ljjxs4s6c4c9hyi8bdzl1h4kw4qz6l
  
https://ci.guix.gnu.org/nar/lzip/ixsr68sfkyfvp66mzg6291sv2gbdwvzc-vice-3.5
: 0bsm4lf5pbfpq6q82jbvv0c9swpais572bf4lhbbrn2i9kld1krm
  differing files:
/bin/xscpu64
/bin/vsid
/bin/x64sc
/bin/xplus4
/bin/x128
/bin/xcbm5x0
/bin/xvic
/bin/xcbm2
/bin/xpet

1 store items were analyzed:
  - 0 (0.0%) were identical
  - 1 (100.0%) differed
  - 0 (0.0%) were inconclusive

-- 
Christopher Howard
blog: https://librehacker.com
social: https://gnusocial.club/librehacker

On Wed, 2021-05-12 at 17:08 +0200, Brendan Tildesley wrote:
> guix gc -D $(guix build --no-grafts vice); guix build --no-
> substitutes vice

bug#48343: Cannot boot after installation

[Brendan Tildesley via Bug reports for GNU Guix]

If setting nomodeset is the answer, there is a trick you can use in GRUB to set 
it before boot.
Apparently in GRUB, you:

1. Press e
2. Edit the linux ... line to add nomodeset as an option
3. Press ctrl X

I just found the instructions here https://duckduckgo.com/?q=grub+nomode+set

At least give that a go and report back if it works.

bug#48373: vice: processor dependency

[Brendan Tildesley via Bug reports for GNU Guix]

I'm curious the guix version would also build differently on your computer.
You can run for example

guix build vice --no-grafts --check

to build it from source and check the difference. if its different, something 
like

guix gc -D $(guix build --no-grafts vice); guix build --no-substitutes vice

should delete it and built it from source without using the prebuilt binary.
If it's different then its a reproducibility bug. Some packages are actually
intended to be that way, like atlas, and have substitutable? #f set so that
they are always built and tuned to the cpu it's used on.

On my computer, AMD 5700X, the built is identical to the substitute:

b@jiu ~/code/guix [env]$ guix challenge vice

1 store items were analyzed:
- 1 (100.0%) were identical
- 0 (0.0%) differed
- 0 (0.0%) were inconclusive

bug#48373: vice: processor dependency?

[Christopher Howard]

Comparing objdumps on the guix binary vs. my local binary, I suspect
that the extension available on your CPU but not on mine is the AVX*
instructions. I see that, e.g., VMOVAPS is used in your binary, but
that is not available on my system.

https://www.felixcloutier.com/x86/movaps

some diff output: the guix build compared to my local build:

1,110c1,336
< 00641a50 <_ZN5reSID17WaveformGeneratorC1Ev>:
<   641a50: 80 3d 89 5a 38 01 00cmpb   $0x0,0x1385a89(%rip)
# 19c74e0 <_ZZN5reSID17WaveformGeneratorC4EvE10class_init>
<   641a57: 53  push   %rbx
<   641a58: 48 89 fbmov%rdi,%rbx
<   641a5b: 0f 85 43 01 00 00   jne641ba4
<_ZN5reSID17WaveformGeneratorC1Ev+0x154>
<   641a61: c5 f8 28 1d 37 a0 09vmovaps
0x9a037(%rip),%xmm3# 6dbaa0
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x860>
<   641a68: 00 
<   641a69: c5 78 28 1d af bf 03vmovaps
0x3bfaf(%rip),%xmm11# 67da20 
<   641a70: 00 
<   641a71: b8 40 d0 74 00  mov$0x74d040,%eax
<   641a76: ba 40 f0 74 00  mov$0x74f040,%edx
<   641a7b: c5 78 28 15 2d a0 09vmovaps
0x9a02d(%rip),%xmm10# 6dbab0
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x870>
<   641a82: 00 
<   641a83: c5 f8 28 35 35 a0 09vmovaps
0x9a035(%rip),%xmm6# 6dbac0
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x880>
<   641a8a: 00 
<   641a8b: c5 d8 57 e4 vxorps %xmm4,%xmm4,%xmm4
<   641a8f: c5 78 28 05 39 a0 09vmovaps
0x9a039(%rip),%xmm8# 6dbad0
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x890>
<   641a96: 00 
<   641a97: c5 f8 28 3d 71 71 00vmovaps
0x7171(%rip),%xmm7# 648c10 
<   641a9e: 00 
<   641a9f: c5 f8 28 2d 39 a0 09vmovaps
0x9a039(%rip),%xmm5# 6dbae0
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x8a0>
<   641aa6: 00 
<   641aa7: c5 78 28 0d 41 a0 09vmovaps
0x9a041(%rip),%xmm9# 6dbaf0
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x8b0>
<   641aae: 00 
<   641aaf: 90  nop
<   641ab0: c4 c1 61 fe d2  vpaddd %xmm10,%xmm3,%xmm2
<   641ab5: c4 c1 60 54 c0  vandps %xmm8,%xmm3,%xmm0
<   641aba: 48 83 c0 10 add$0x10,%rax
<   641abe: c4 c1 68 54 c8  vandps %xmm8,%xmm2,%xmm1
<   641ac3: c5 f9 76 c4 vpcmpeqd %xmm4,%xmm0,%xmm0
<   641ac7: c5 f8 29 b0 f0 ff 00vmovaps %xmm6,0xfff0(%rax)
<   641ace: 00 
<   641acf: c5 f8 29 70 f0  vmovaps %xmm6,-0x10(%rax)
<   641ad4: c5 f1 76 cc vpcmpeqd %xmm4,%xmm1,%xmm1
<   641ad8: c5 f8 55 c7 vandnps %xmm7,%xmm0,%xmm0
<   641adc: c5 f8 29 b0 f0 7f 01vmovaps %xmm6,0x17ff0(%rax)
<   641ae3: 00 
<   641ae4: c5 f8 29 b0 f0 7f 00vmovaps %xmm6,0x7ff0(%rax)
<   641aeb: 00 
<   641aec: c5 f0 55 cf vandnps %xmm7,%xmm1,%xmm1
<   641af0: c5 d9 fa c0 vpsubd %xmm0,%xmm4,%xmm0
<   641af4: c5 d9 fa c9 vpsubd %xmm1,%xmm4,%xmm1
<   641af8: c5 f8 57 c3 vxorps %xmm3,%xmm0,%xmm0
<   641afc: c5 f0 57 ca vxorps %xmm2,%xmm1,%xmm1
<   641b00: c5 f9 72 d0 0b  vpsrld $0xb,%xmm0,%xmm0
<   641b05: c5 d0 54 c0 vandps %xmm0,%xmm5,%xmm0
<   641b09: c5 e9 72 d2 0c  vpsrld $0xc,%xmm2,%xmm2
<   641b0e: c5 f1 72 d1 0b  vpsrld $0xb,%xmm1,%xmm1
<   641b13: c5 d0 54 c9 vandps %xmm1,%xmm5,%xmm1
<   641b17: c5 d0 54 d2 vandps %xmm2,%xmm5,%xmm2
<   641b1b: c4 e2 79 2b c9  vpackusdw %xmm1,%xmm0,%xmm1
<   641b20: c5 f9 72 d3 0c  vpsrld $0xc,%xmm3,%xmm0
<   641b25: c5 d0 54 c0 vandps %xmm0,%xmm5,%xmm0
<   641b29: c4 c1 61 fe db  vpaddd %xmm11,%xmm3,%xmm3
<   641b2e: c4 c1 70 54 c9  vandps %xmm9,%xmm1,%xmm1
<   641b33: c4 e2 79 2b d2  vpackusdw %xmm2,%xmm0,%xmm2
<   641b38: c5 f8 29 88 f0 1f 01vmovaps %xmm1,0x11ff0(%rax)
<   641b3f: 00 
<   641b40: c5 f8 29 88 f0 1f 00vmovaps %xmm1,0x1ff0(%rax)
<   641b47: 00 
<   641b48: c5 f8 29 90 f0 3f 01vmovaps %xmm2,0x13ff0(%rax)
<   641b4f: 00 
<   641b50: c5 f8 29 90 f0 3f 00vmovaps %xmm2,0x3ff0(%rax)
<   641b57: 00 
<   641b58: 48 39 c2cmp%rax,%rdx
<   641b5b: 0f 85 4f ff ff ff   jne641ab0
<_ZN5reSID17WaveformGeneratorC1Ev+0x60>
<   641b61: c5 fb 10 05 97 9f 09vmovsd
0x99f97(%rip),%xmm0# 6dbb00
<_ZZ21_vte_boa_advance_tailE19__PRETTY_FUNCTION__+0x8c0>
<   641b68: 00 
<   641b69: 31 d2   xor%edx,%edx
<   641b6b: be 0c 00 00 00  mov$0xc,%esi
<   641b70: bf e0 34 9c 01  mov$0x19c34e0,%edi
<   641b75: c7 43 10 00 00 00 01movl   $0x100,0x10(%rbx)
<   641b7c: e8 3f 21 00 00

bug#48376: Failure in "guix pull"

[Konrad Hinsen]

Trying the "guix pull" a short while (and one commit to Guix) later, the
error is gone. Which is a bit strange: whatever the cause of the error
was, it's hard to believe that adding the package
"python-sqlalchemy-stubs" (which is what commit
f8a4724c101880892640dcc2fe3438dc2a26b624 did) could fix it.

Konrad.

bug#48376: Failure in "guix pull"

[Konrad Hinsen]

Today's "guix pull" resulted in an error message that ends with a
request for a bug report. So here it comes:

===
Updating channel 'guix-past' from Git repository at 
'https://gitlab.inria.fr/guix-hpc/guix-past'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
guix pull: warning: moving channel 'guix' from 
3e4f6d2bbc6f0f81c1487eb1bb69d8e9fe9bdbd7 to unrelated commit 
34985fb6ae7deffd40443766f5408649a0cbbff2
Authenticating channel 'guix', commits 9edb3f6 to 34985fb (777 new commits)...
Building from these channels:
  guix  https://git.savannah.gnu.org/git/guix.git   34985fb
  guix-past https://gitlab.inria.fr/guix-hpc/guix-past  0f892e4
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
 module-import  2KiB   25KiB/s 00:00 [##] 100.0%

 module-import-compiled  1.4MiB   1.7MiB/s 00:01 [##] 100.0%

 compute-guix-derivation  1005B 9KiB/s 00:00 [##] 100.0%

Computing Guix derivation for 'x86_64-linux'... |Backtrace:
  13 (primitive-load 
"/gnu/store/jbz265j88niryci4f80zfwq92vjy2xam-compute-guix-derivation")
In ice-9/eval.scm:
155:9 12 (_ _)
159:9 11 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(# ?) ?) ?) 
?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
In ice-9/boot-9.scm:
152:2 10 (with-fluid* _ _ _)
152:2  9 (with-fluid* _ _ _)
In ./guix/store.scm:
  2076:24  8 (run-with-store # _ 
#:guile-for-build _ #:system _ #:target _)
   1910:8  7 (_ _)
In ./guix/gexp.scm:
   256:18  6 (_ _)
   1137:2  5 (_ _)
   1003:2  4 (_ _)
849:4  3 (_ _)
In ./guix/store.scm:
  1958:12  2 (_ #)
   1372:5  1 (map/accumulate-builds # _ _)
  1383:15  0 (_ # _ _)

./guix/store.scm:1383:15: ERROR:
  1. &store-protocol-error:
  message: "some substitutes for the outputs of derivation 
`/gnu/store/8kj83zhzcfpp7df9jxsyarnkrbvglwri-guile-json-3.5.0.drv' failed 
(usually happens due to networking issues); try `--fallback' to build 
derivation from source "
  status: 1
guix pull: error: You found a bug: the program 
'/gnu/store/jbz265j88niryci4f80zfwq92vjy2xam-compute-guix-derivation'
failed to compute the derivation for Guix (version: 
"34985fb6ae7deffd40443766f5408649a0cbbff2"; system: "x86_64-linux";
host version: "3e4f6d2bbc6f0f81c1487eb1bb69d8e9fe9bdbd7"; pull-version: 1).
Please report it by email to .
===

bug#48335: Emacs is broken

[Xinglu Chen]

On Wed, May 12 2021, Leo Prikler wrote:

>> Hmm, ldd doesn’t list any libraries for me
>> 
>> --8<---cut here---start->8---
>> $ ldd /gnu/store/nvddirc1j6f031zhcwnkd0zrpjc10dyc-profile/bin/emacs
>>  not a dynamic executable
>> --8<---cut here---end--->8---
> The "emacs" command is just a wrapper, you'll have to resolve the
> correct .emacs-real (in this case .emacs-27.2-real).

Oh, I should have known that...

Running ldd on the real binary yields this.

--8<---cut here---start->8---
$ ldd 
/gnu/store/xmsccg3lvgxjll605xs4ffw00in7vz66-emacs-27.2/bin/.emacs-27.2-real | 
grep m17
libm17n-core.so.0 => not found
libm17n-flt.so.0 => not found
--8<---cut here---end--->8---

But libm17 exists in my store.

--8<---cut here---start->8---
0yqxlr0kbjilw48qscf7pfh4l7ys2k7v-m17n-lib-1.8.0-guile-builder
2lyzzw7ybsm3s2n7fgqm17n33n62dl7c-mesa-20.2.4/
2m2hnv9hlrfjdzc1c4xxqgjdbbgj46vq-m17n-lib-1.8.0.drv
2nq943kc7ksch4q5f0ym073iw2gyqgy0-m17n-lib-1.8.0.drv
3b7987inhi3yg5bbqhv5b6brv9rm807d-m17n-db-1.8.0.tar.gz.drv
8dgcc76g6xjrgykf8vd5kv8lk8qqbvwh-m17n-lib-1.8.0/
9jv7xsfhp4m5pxfb95iwyg46l3g3mfb3-m17n-db-1.8.0/
akfwmc4xfpjsx91zpyvgy2q4g7nbaydw-m17n-lib-1.8.0.drv
cq1zm0nik02s1d0d52picipaq26m3d4q-m17n-db-1.8.0.drv
f92dm4mbv4wrzyj3x1886fr5h16lxq9q-m17n-lib-1.8.0.drv
ka96jmddzi1yqncpacl98qcvqbyflk0p-m17n-lib-1.8.0.tar.gz.drv
l7izhc1ws4x6jgsxl9ir0nxqcinjah01-m17n-db-1.8.0.tar.gz.drv
ml2z24n2ysa8jlsq4dl8fmi7whhklviw-m17n-lib-1.8.0/
n58jdhm4wxxrw6v2p0c8hd56r9k9f3yy-m17n-lib-1.8.0.drv
pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/
pxi39yl5qv6jh67n0x4wckvjh1g16nh5-m17n-db-1.8.0.drv
r2r82m88cpqxra3hdjpk843ji50infpc-m17n-lib-1.8.0.drv
s3001awd1li30n3fzi6nna3fml62h8y9-m17n-lib-1.8.0-guile-builder
w1vl0f9vwnqjc92zjlcj8vyl49m1s2bm-m17n-lib-1.8.0.tar.gz.drv
wkgm6jqz6s6rjxw2z9nqvj3b3agafd0l-m17n-lib-1.8.0-guile-builder
xzymd2m17n2djch1j90dvqirqp9iy0zx-dbus-glib-0.110/
y8ywqmpy9frkn0wpinbypjmmgp2f3wcx-m17n-lib-1.8.0-guile-builder
yb1q28dq5wi93qzkcbszgqsgqg3234c0-m17n-db-1.8.0.drv
yf9i0d9q92gkx6vmn8hvb0crjplrbfdd-m17n-db-1.8.0-guile-builder
--8<---cut here---end--->8---

>> I am now bisecting commit 5866fa558b68b3e0213b9eef93d115e6e38dcc2a, I
>> don’t think it should be related to the changes to the
>> ‘emacs-build-system’.
> The wip-ungrafting merge?

Yup.

>> This doesn’t seem to help either, and as I wrote above, ldd doesn’t
>> list any libraries for Emacs.  Interestingly, this also seems to be
>> the case with ‘emacs-native-comp’ from the flatwatson channel[1], but
>> the binary works fine (I am using it to write this email).
> As before, /bin/emacs is just a shell script, it can't work with ldd :(

‘emacs-native-comp’ doesn’t seem to refer to libm17n at all.

--8<---cut here---start->8---
$ ldd 
/gnu/store/0drwnvfnfnz486m3vz4ddnd4x91za5m5-emacs-native-comp-28.0.50-165.25c775b/bin/.emacs-28.0.50-real
 | grep m17

--8<---cut here---end--->8---

bug#48238: Julia contains references to its build directory

[zimoun]

Hi,

In the update to v1.6.1, please give a look at some explanations:






On mer., 05 mai 2021 at 15:22, zimoun  wrote:

> $ find $(guix build julia --no-grafts) -type f \
>-exec grep '/tmp/guix-build-julia-1.5.3.drv-0' {} \;
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/libjulia.so.1.5 
> matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/julia/sys.so 
> matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/julia/libccalltest.so.debug
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/lib/julia/libllvmcalltest.so
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/bin/.julia-real 
> matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/base.cache
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Bar/HXSAn_w3IH9.ji
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Foo/MYb1d_w3IH9.ji
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Foo/TeeT6_w3IH9.ji
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Qux/YFfiR_w3IH9.ji
>  matches
> Binary file 
> /gnu/store/i1dgzqfjvkkjlfhpcwc33lz17vslq50y-julia-1.5.3/share/julia/test/depot/compiled/v1.5/Baz/rONVA_w3IH9.ji
>  matches

In addition, "guix build julia --no-grafts -K" then something ugly to
show that for some files the reference of the source file itself are
included in their object version.  Maybe I miss something.

--8<---cut here---start->8---
$ for f in $(find /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/ -name "*.o" 
-type f -print | sed 's/\.o//' |sort);
do
   [ -f ${f}.cpp ] \
   && echo "## grep ${f}.cpp *" \
   && find /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/ -type f -print \
  | xargs -I {} grep ${f}.cpp {} ;
done

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/aotcompile.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/aotcompile.o 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/APInt-C.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/cgmemmgr.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/cgmemmgr.o 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/codegen.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/codegen.o 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/debuginfo.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/debuginfo.o 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/disasm.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/disasm.o 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/jitlayers.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/jitlayers.o 
correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/llvm-alloc-opt.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/llvm-alloc-opt.o correspondant

## grep /tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/llvm-api.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant

## grep 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/llvm-final-gc-lowering.cpp *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.1.5 
correspondant
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/llvm-final-gc-lowering.o 
correspondant

## grep 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/src/llvm-gc-invariant-verifier.cpp
 *
Fichier binaire 
/tmp/guix-build-julia-1.5.3.drv-0/julia-1.5.3/usr/lib/libjulia.so.

bug#48335: Emacs is broken

[Leo Prikler]

Am Mittwoch, den 12.05.2021, 09:55 +0200 schrieb Xinglu Chen:
> Leo Prikler wrote:
> 
> > I can't:
> > 
> > --8<---cut here---start->8---
> > $ guix time-machine --
> > commit=87b4b0e4385149b40ee87ae2d57712679452746b
> > -- \
> >  environment --pure --ad-hoc emacs -- emacs --version
> > GNU Emacs 27.2
> > Copyright (C) 2021 Free Software Foundation, Inc.
> > GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> > You may redistribute copies of GNU Emacs
> > under the terms of the GNU General Public License.
> > For more information about these matters, see the file named
> > COPYING.
> > --8<---cut here---end--->8---
> > 
> > As for the output of ldd:
> > 
> > libm17n-core.so.0 => /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-
> > m17n-
> > lib-1.8.0/lib/libm17n-core.so.0
> 
> Hmm, ldd doesn’t list any libraries for me
> 
> --8<---cut here---start->8---
> $ ldd /gnu/store/nvddirc1j6f031zhcwnkd0zrpjc10dyc-profile/bin/emacs
>   not a dynamic executable
> --8<---cut here---end--->8---
The "emacs" command is just a wrapper, you'll have to resolve the
correct .emacs-real (in this case .emacs-27.2-real).

> > > The latest “good” commit I know of is
> > > ee86a035c79b838e3fdabbdb88dc30906a83cc30 (still bisecting).
> > That'd be big if true, we've had the wip-emacs merge between then
> > and
> > now and while that caused a lot of problems to many, it should
> > still
> > open up.
> 
> I am now bisecting commit 5866fa558b68b3e0213b9eef93d115e6e38dcc2a, I
> don’t think it should be related to the changes to the
> ‘emacs-build-system’.
The wip-ungrafting merge?

> > Now, perhaps there's a case to be made, that it's in fact broken on
> > another architecture or when not using substitutes (it is not
> > reproducible after all), but atm we're lacking a bit of necessary
> > info
> > here.
> 
> I am on x86_64 with substitutes enabled on a foreign distro (NixOS).
> 
> On Tue, May 11 2021, Ludovic Courtès wrote:
> 
> > I wondered if this could be a missed reference issue due to
> > grafting (whereby a recent ‘guix gc’ would have deleted m17n-lib
> > from the store because the grafted Emacs didn’t have a visible
> > reference to it) but that doesn’t seem to be the case (on x86_64-
> > linux):
> > 
> > --8<---cut here---start->8---
> > $ guix time-machine --
> > commit=87b4b0e4385149b40ee87ae2d57712679452746b -- build emacs
> > /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2
> > $ ldd /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-
> > 27.2/bin/.emacs-27.2-real |grep m17n
> > libm17n-core.so.0 =>
> > /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-
> > 1.8.0/lib/libm17n-core.so.0 (0x7f6800d1d000)
> > libm17n-flt.so.0 =>
> > /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-
> > 1.8.0/lib/libm17-flt.so.0 (0x7f6800d11000)
> > $ guix gc -R /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2 
> > |grep pdwv15zmghndkqy5473v1hxgibmvzvlz
> > /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0
> > --8<---cut here---end--->8---
> > 
> > Does passing ‘--no-grafts’ to ‘environment’ make a difference for
> > you?
> 
> This doesn’t seem to help either, and as I wrote above, ldd doesn’t
> list any libraries for Emacs.  Interestingly, this also seems to be
> the case with ‘emacs-native-comp’ from the flatwatson channel[1], but
> the binary works fine (I am using it to write this email).
As before, /bin/emacs is just a shell script, it can't work with ldd :(

Regards,
Leo

bug#48335: Emacs is broken

[Xinglu Chen]

Leo Prikler wrote:

> I can't:
> 
> --8<---cut here---start->8---
> $ guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b
> -- \
>  environment --pure --ad-hoc emacs -- emacs --version
> GNU Emacs 27.2
> Copyright (C) 2021 Free Software Foundation, Inc.
> GNU Emacs comes with ABSOLUTELY NO WARRANTY.
> You may redistribute copies of GNU Emacs
> under the terms of the GNU General Public License.
> For more information about these matters, see the file named COPYING.
> --8<---cut here---end--->8---
> 
> As for the output of ldd:
> 
> libm17n-core.so.0 => /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-
> lib-1.8.0/lib/libm17n-core.so.0

Hmm, ldd doesn’t list any libraries for me

--8<---cut here---start->8---
$ ldd /gnu/store/nvddirc1j6f031zhcwnkd0zrpjc10dyc-profile/bin/emacs
not a dynamic executable
--8<---cut here---end--->8---

> > The latest “good” commit I know of is
> > ee86a035c79b838e3fdabbdb88dc30906a83cc30 (still bisecting).
> That'd be big if true, we've had the wip-emacs merge between then and
> now and while that caused a lot of problems to many, it should still
> open up.

I am now bisecting commit 5866fa558b68b3e0213b9eef93d115e6e38dcc2a, I
don’t think it should be related to the changes to the
‘emacs-build-system’.

> Now, perhaps there's a case to be made, that it's in fact broken on
> another architecture or when not using substitutes (it is not
> reproducible after all), but atm we're lacking a bit of necessary info
> here.

I am on x86_64 with substitutes enabled on a foreign distro (NixOS).

On Tue, May 11 2021, Ludovic Courtès wrote:

> I wondered if this could be a missed reference issue due to grafting
> (whereby a recent ‘guix gc’ would have deleted m17n-lib from the store
> because the grafted Emacs didn’t have a visible reference to it) but
> that doesn’t seem to be the case (on x86_64-linux):
>
> --8<---cut here---start->8---
> $ guix time-machine --commit=87b4b0e4385149b40ee87ae2d57712679452746b -- 
> build emacs
> /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2
> $ ldd 
> /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2/bin/.emacs-27.2-real 
> |grep m17n
> libm17n-core.so.0 => 
> /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17n-core.so.0
>  (0x7f6800d1d000)
> libm17n-flt.so.0 => 
> /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0/lib/libm17-flt.so.0
>  (0x7f6800d11000)
> $ guix gc -R /gnu/store/d0r7zcph1f3y0cahp9yv5hs8rhi9hcig-emacs-27.2 |grep 
> pdwv15zmghndkqy5473v1hxgibmvzvlz
> /gnu/store/pdwv15zmghndkqy5473v1hxgibmvzvlz-m17n-lib-1.8.0
> --8<---cut here---end--->8---
>
> Does passing ‘--no-grafts’ to ‘environment’ make a difference for you?

This doesn’t seem to help either, and as I wrote above, ldd doesn’t list
any libraries for Emacs.  Interestingly, this also seems to be the case
with ‘emacs-native-comp’ from the flatwatson channel[1], but the binary
works fine (I am using it to write this email).

--8<---cut here---start->8---
$ ldd 
/gnu/store/0drwnvfnfnz486m3vz4ddnd4x91za5m5-emacs-native-comp-28.0.50-165.25c775b/bin/emacs
not a dynamic executable
--8<---cut here---end--->8---

[1]: 
https://github.com/flatwhatson/guix-channel/blob/master/flat/packages/emacs.scm#L160

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Simon Streit]

Ludovic Courtès  writes:
> Fixed in da28efef36af8925bcd9e40a81cbf552cf8c2d02.  Let me know if it
> works for you!

I'll try it later.  I missed this mail yesterday.


Cheers! 

bug#48240: “guix copy” to host with daemon listening on TCP fails

[Simon Streit]

Ludovic Courtès  writes:
> Simon Streit  skribis:
>> Anyway, back to this old commit offloading works for all users. 
>
> Is the socket file name displayed above correct?  Or did you specify
> something else in the  record?

No, nothing that I'm aware about.  I haven't made any special changes. 
>
> Is the ‘GUIX_DAEMON_SOCKET’ environment variable defined on that
> machine?

No.
>
> How do you run guix-daemon on the head node?  The patches discussed here
> haven’t made it into the ‘guix’ package yet AFAIK.

That is a Guix system, where I've got an extra user with no extra group
permisions that takes the requests for offloading the clients make.
Thinking about it, the host isn't fully updated. Its current checkout
is, or was at the time of reporting to this issue:
407e0af6aa465479d08dafb125d06d50109f1822


Cheers!