bug#24156: QEMU '-net bridge' --> "qemu-system-x86_64: -net bridge: bridge helper failed"

[George Clemmer]

zimoun  writes:

> Hi,
>
> On Fri, 18 Dec 2020 at 20:47, zimoun  wrote:
>> On Thu, 04 Aug 2016 at 22:40, myglc2  wrote:
>
>>> Motivation: bridging or routing is required to enable a connection to be
>>> made inward to a QEMU VM. TAP seems like the best of the available
>>> solutions. But connecting to a TAP device produces an error when the
>>> QEMU bridge helper fails.
>
> If no moreinfo is provided to detail what could the next actionable
> step, then I will close this more-than-3-years bug report in the coming
> days.
>
> http://issues.guix.gnu.org/issue/24156
Hi Simon,

I can't easily provide more detail as I am not currently use QEMU.

Best, George

bug#42054: installer: "invisible" screens, partitioning step fail

[George Clemmer]

Hello,

Recently (June 5, 2020) I tried to use the Graphical Installer to
re-install Guix System on a headless server (ASRock MT-C224 mother board
with NVME system disk). I hit two problems:

1) The installer screens were not visible on the VGA port. However TTYs
3-6 worked just fine. With #guix IRC help I discovered that if I ...

  hit ctr-alt-del

  hit "e" when "GRUB LOADING!" appeared ...

  ... when the linux command line appeard, added "nomodeset" between
  "quiet" and "modprob ..."

  ... hit Ctrl-x

the installer screens became visible.

FWIW, VGA on this server is provided by an ASPEED AST2300 "server
management processor".

2) The installer seemed to work until the "Partitioning method" step.
After selecting "Guided - use the entire disk" nothing more happend.

I rebooted and selected "Manual" partitioning and got the same result.

In both cases it was possible to exit the partitioning step and cycle
through previous selections in an "endless loop".

FWIW, I had no problem proceeding with the install manually.

I believe a recent guix-help post also reports this problem ...

https://lists.gnu.org/archive/html/help-guix/2020-06/msg00136.html

Happy to provide additional details or recreate the "crime" if needed.

George

bug#37789: guix pull: error: You found a bug: the program

[George Clemmer]

Ludovic Courtès  writes:

> Uh.  (You purposefully turned off substitutes, right?)
>
> I’m very surprised this can happen.  Janneke, does that ring a bell?

Hi Ludo’,

I recently re-installed Guix System from USB and abandoned my config
that turned off substitutes. And of course, guix pull works great ;-)

I assume that "guix pull w/substitutes off" is not recommended or likely
to be used by others. If so maybe this bug can be cleared?

If, OTOH, you want to support "guix pull w/substitutes off" I am willing
to turn substitutes off again to see what happens ;-)

WDYT? - George

bug#37789: guix pull: error: You found a bug: the program

[George Clemmer]

Ludovic Courtès  writes:

> Hi George,
>
> George Clemmer  skribis:
>
>> starting phase `configure'
>> PATH="/gnu/store/lxwhz2y0m3c38figfl5sfdydsb7sk7g2-bootstrap-binaries-0/bin:/gnu/store/niv24i583siranb6ydphx991dkvj8x8g-mes-boot-0.19/bin:/gnu/store/grybsvhmi38gbrdl3i8cc31i0r1x7x6z-bootstrap-mescc-tools-0.5.2/bin"
>> configure: error: 'gcc' failed to compile conftest.c.
>> configure: line 332: ./conftest: No such file or directory
>> configure: line 336: ./conftest: No such file or directory
>> Binary  directory   
>> /gnu/store/fkxk1l6l1cvs524q2cmd733gg1wsa6z6-tcc-boot0-0.9.26-6.c004e9a/bin
>> TinyCC directory.
>> [...]
>> 55_lshift_type: [FAIL]
>> expect: 14
>> failed: 15
>> passed: 209
>> total:  224
>> FAILED: 15/224
>> command "sh" "check.sh" failed with status 1
>> builder for 
>> `/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv' 
>> failed with exit code 1
>> build of 
>> /gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv 
>> failed
>
> Uh.  (You purposefully turned off substitutes, right?)

Yes

bug#37789: guix pull: error: You found a bug: the program

[George Clemmer]

George Clemmer  writes:

> Hi Ludo’,
>
> Ludovic Courtès  writes:

>> Note that what you initially reported is not so much that ‘guix pull’
>> “doesn’t work” but rather that it failed to build ghostscript.
>
> Good point. I will respond to your earlier ...
>
>>> configure: error: Guile-JSON is missing; please install it.
>>
>> How are you getting this error?  Please provide all the context.
>
> ... in a second email.

Please see attached. TIA - George



Guile-JSON.log.gz
Description: Binary data

bug#37789: guix pull: error: You found a bug: the program

[George Clemmer]

Hi Ludo’,

Ludovic Courtès  writes:

> Ludovic Courtès  skribis:
>
>>> The guix-configuration is unchanged since then. Shouldn't 'guix pull'
>>> still work?
>>
>> It should work, yes.  What does ‘guix describe’ report?
>
> Note that what you initially reported is not so much that ‘guix pull’
> “doesn’t work” but rather that it failed to build ghostscript.

Good point. I will respond to your earlier ...

>> configure: error: Guile-JSON is missing; please install it.
>
> How are you getting this error?  Please provide all the context.

... in a second email.


> Could you send the tail of the log returned by:
>
>   guix build --log-file 
> /gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv

That gave a ref to the build farm so I did this ...

guix build /gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv
[...]
starting phase `install-locale'
warning: failed to install 'en_US.utf8' locale: Invalid argument
phase `install-locale' succeeded after 0.0 seconds
starting phase `unpack'
[...]
starting phase `configure'
PATH="/gnu/store/lxwhz2y0m3c38figfl5sfdydsb7sk7g2-bootstrap-binaries-0/bin:/gnu/store/niv24i583siranb6ydphx991dkvj8x8g-mes-boot-0.19/bin:/gnu/store/grybsvhmi38gbrdl3i8cc31i0r1x7x6z-bootstrap-mescc-tools-0.5.2/bin"
configure: error: 'gcc' failed to compile conftest.c.
configure: line 332: ./conftest: No such file or directory
configure: line 336: ./conftest: No such file or directory
Binary  directory   
/gnu/store/fkxk1l6l1cvs524q2cmd733gg1wsa6z6-tcc-boot0-0.9.26-6.c004e9a/bin
TinyCC directory.
[...]
55_lshift_type: [FAIL]
expect: 14
failed: 15
passed: 209
total:  224
FAILED: 15/224
command "sh" "check.sh" failed with status 1
builder for 
`/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv' 
failed with exit code 1
build of 
/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv 
failed
View build log at 
'/var/log/guix/drvs/nv/hjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv.bz2'.
cannot build derivation 
`/gnu/store/fglx0fz62bygkdxxg878j7x9pfl37zhh-tcc-boot-0.9.27.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/x9shp86cz9f4rb5xvhs37zzxg1ngi4dr-binutils-mesboot0-2.20.1a.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/r50fj43103526ga6pi2f9jkk4gvaav7m-diffutils-mesboot-2.7.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/kcyh6k46ijm9nsq1as26rr0aq7rkx4f7-gcc-core-mesboot-2.95.3.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/57da9mdiqhyn72m8wv00pdvzqi2ng4xb-make-mesboot0-3.80.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/2lpg626q4x8v7hgqajywpq1rc8y72hzx-binutils-mesboot-2.20.1a.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/q8f5yjxp0kcdn2mwqf83bvhal71cnr71-gcc-mesboot-4.9.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/lp6fycqqd8adndlfylh4mlihm0qakxzw-glibc-mesboot-2.16.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5xh3f9lxl86imd56fk8n6wcqdcrzh2mb-binutils-cross-boot0-2.32.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/492grrzzhh8z7nv9vrh9vai6kk7zfj8i-diffutils-boot0-3.7.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/56xfnvjd2qv05vx3j0s6b30h9dg3dqcj-file-boot0-5.33.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/b1n16vi8ypfr1bsgrcgk67h6sixghy0c-findutils-boot0-4.6.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/h6pl88jbzlgan2majgy0z6kcphzp2x6q-gcc-cross-boot0-7.4.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/5lcadggb83v1dfyza323lcw8ih199v1l-gcc-mesboot-wrapper-4.9.4.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rmfsg2dsb88b136arb40z3kgd57kcnzs-glibc-2.29.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/qcx5p89cac2ghvc4k6cq2c6dsm3xncp1-glibc-intermediate-2.29.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/djxlq3ilag624v2zr8ya3zivwcrpiji7-linux-libre-headers-4.19.56.drv': 
1 dependencies couldn't be built
cannot build derivation 
`/gnu/store/88azrsd0d3axcp043yrd4pl78ifd5368-make-boot0-4.2.1.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/my4rsf2nhcxd9n106bjrdmw56k26cc2j-perl-boot0-5.30.0.drv': 1 
dependencies couldn't be built
cannot build derivation 
`/gnu/store/rhqqd8kmr1fqc9fkzpbh0qca4mwb03xa-texinfo-6.6.drv': 1 dependencies 
couldn't be built
cannot build derivation 
`/gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv': 1 
dependencies couldn't be built
guix build: error: build failed: build of 
`/gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv' failed
glc@g1 ~ [def]$ date
Sat Oct 19 23:52:51 EDT 2019

TIA - George

bug#37789: guix pull: error: You found a bug: the program

[George Clemmer]

Hi Ludo’, thanks for getting back to me.

Ludovic Courtès  writes:

> Hello,
>
> my glc2  skribis:
>
>> [message: "build of
>> `/gnu/store/j5lp13iwcwnsdk545lgg1nh8kn4jdj3d-ghostscript-9.27.drv' failed"
>> status: 100] 5348cc0>)'.
>> guix pull: error: You found a bug: the program
>> '/gnu/store/an0wa7l9726cchav86ixjy520lnq5srx-compute-guix-derivation'
>> failed to compute the derivation for Guix (version:
>> "0230b92fde80b2288028582434034ad0827a61b1"; system: "x86_64-linux";
>> host version: "bd208a13ef4c203cf9035c0ccf454a60c1949c58"; pull-version: 1).
>
> Apparently Ghostcript failed to build, which in turn prevented ‘guix
> pull’ from completing.
>
> This binary is available on ci.guix.gnu.org though:
>
>   https://ci.guix.gnu.org/3i5qm6z0qihhjbdgs3pwj42gy63sf74h.narinfo
>   https://ci.guix.gnu.org/l1iakyjw5lacjbnynm6z7b31clyh1llx.narinfo
>
> Did you enable substitutes, in particular from ci.guix.gnu.org?

I think so. /etc/guix/acl contains several copies of ...
 (entry 
  (public-key 
   (ecc 
(curve Ed25519)
(q #C38DCF2B0EBE663B9450BEFB0E77DFAF6643E8E971318F7002721076ED9C9788#)
)
   )
  (tag 
   (guix import)
   )
  )

> Does the ‘guix pull’ log above provide more insight as to why Ghostcript
> failed to build?

The log is 38M. How about this ...

glc@g1 ~ [def]$ grep failed guix_pull.fail.log
download failed 
"https://linux-libre.fsfla.org/pub/linux-libre/releases/4.19.56-gnu/linux-libre-4.19.56-gnu.tar.xz;
 404 "Not Found"
download failed 
"https://mirrors.ocf.berkeley.edu/gnu/linux-libre/4.19.56-gnu/linux-libre-4.19.56-gnu.tar.xz;
 404 "Not Found"
download failed 
"http://ftp.gnu.org/pub/gnu/linux-libre/4.19.56-gnu/linux-libre-4.19.56-gnu.tar.xz;
 404 "Not Found"
download failed 
"http://ramses.wh2.tu-dresden.de/pub/mirrors/kernel.org/linux/libs/security/linux-privs/libcap2/libcap-2.27.tar.xz;
 404 "Not Found"
download failed 
"http://artfiles.org/gnupg.org/libgcrypt/libgcrypt-1.8.4.tar.bz2; 404 "Not 
Found"
download failed 
"http://artfiles.org/gnupg.org/libgpg-error/libgpg-error-1.36.tar.bz2; 404 "Not 
Found"
download failed "https://www.crysys.hu/libgcrypt/libgcrypt-1.8.4.tar.bz2; 404 
"Not Found"
download failed "https://www.crysys.hu/libgpg-error/libgpg-error-1.36.tar.bz2; 
404 "Not Found"
download failed 
"http://ramses.wh2.tu-dresden.de/pub/mirrors/kernel.org/linux/utils/util-linux/v2.34/util-linux-2.34.tar.xz;
 404 "Not Found"
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-arch-failed-01.d
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-stack-align-failed-a.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-stack-align-failed-b.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-arch-failed-01a.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-stack-align-failed.d
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-arch-failed-01b.s
warning: failed to install 'en_US.utf8' locale: Invalid argument
warning: failed to install 'en_US.utf8' locale: Invalid argument
gcc-7.4.0/gcc/testsuite/gfortran.dg/coarray/failed_images_1.f08
gcc-7.4.0/gcc/testsuite/gfortran.dg/coarray/failed_images_2.f08
gcc-7.4.0/gcc/testsuite/gfortran.dg/coarray_failed_images_1.f08
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-arch-failed-01.d
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-arch-failed-01a.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-arch-failed-01b.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-stack-align-failed-a.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-stack-align-failed-b.s
binutils-2.32/ld/testsuite/ld-riscv-elf/attr-merge-stack-align-failed.d
gcc-7.4.0/gcc/testsuite/gfortran.dg/coarray/failed_images_1.f08
gcc-7.4.0/gcc/testsuite/gfortran.dg/coarray/failed_images_2.f08
gcc-7.4.0/gcc/testsuite/gfortran.dg/coarray_failed_images_1.f08
failed: 5
warning: failed to install 'en_US.utf8' locale: Invalid argument
configure: error: 'gcc' failed to compile conftest.c.
failed: 15
command "sh" "check.sh" failed with status 1
builder for 
`/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv' 
failed with exit code 1
@ build-failed 
/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv - 1 
builder for 
`/gnu/store/nvhjn6b5hi4mj7wnjxrmj0dmdigq9m2z-tcc-boot0-0.9.26-6.c004e9a.drv' 
failed with exit code 1
Throw to key `srfi-34' with args `(#)'.
failed to compute the derivation for Guix (version: 
"0230b92fde80b2288028582434034ad0827a61b1"; system: "x86_64-linux";
glc@g1 ~ [def]$

TIA - George

bug#31367: ERROR: In procedure scm-error: no code for module (guix build utils)

[George Clemmer]

l...@gnu.org (Ludovic Courtès) writes:

> Roel Janssen  skribis:
>
>> Ludovic Courtès  writes:
>>
>>> George myglc2 Clemmer  skribis:
>>>
 cd guix && guix environment guix -- make
 The following derivations will be built:
/gnu/store/mcfys0glgv1hnq5mrcs9xnmn4bpzr3ys-profile.drv
/gnu/store/qikmbskc6598vld2lhb2pn30h1rwxgc8-xdg-mime-database.drv
/gnu/store/izxixb30i4r79gahirb4nj5ay0z8nzv1-info-dir.drv
/gnu/store/bdg4x3925r9l3458li48hp1i26shd7yw-manual-database.drv
 Backtrace:
   10 (primitive-load "/gnu/store/611mdvnasj59v5j46g8mhq7aw0g?")
 In ice-9/eval.scm:
721:20  9 (primitive-eval (begin (use-modules (guix build #) ?) ?))
 In ice-9/psyntax.scm:
   1235:36  8 (expand-top-sequence ((begin (use-modules (# # ?) ?) ?)) ?)
   1182:24  7 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
   1182:24  6 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
285:10  5 (parse _ (("placeholder" placeholder)) (()) _ c (eval) ?)
 In ice-9/boot-9.scm:
   3365:20  4 (process-use-modules _)
222:17  3 (map1 (((guix build utils)) ((srfi srfi-1)) ((srfi ?)) ?))
   3366:31  2 (_ ((guix build utils)))
2791:6  1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ ?)
 In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu?" ?) ?)

 ERROR: In procedure scm-error:
 no code for module (guix build utils)
 Creating manual page database...
 builder for `/gnu/store/izxixb30i4r79gahirb4nj5ay0z8nzv1-info-dir.drv' 
 failed with exit code 1
>>>
>>> I’m merging it with .  No fix yet but we’re
>>> working on it.  In the meantime, ‘guix pull’ may allow you to work
>>> around it.
>>
>> I'm using a git checkout of Guix, and I am encountering this bug with
>> version 217af8ae7.  Is there a work-around?
>
> In essence you need to recompile guix/profiles.go.
>
> If you’re in a checkout that’s easy, otherwise you may have to re-run
> ‘guix pull’, which isn’t great.
>
> Ludo’.

Hi Ludo’,

I continue to hit this error sporadically.  Most recently today using
guix (GNU Guix) 0.16.0.131-ce3fe and guile (GNU Guile) 2.2.4. The above
mentioned workaround does seem to "work". At the moment, I have several
examples of the error in my store. Please advise if it would helpful to
provide these and, if so , what you want to see.

TIA, George

bug#33262: guix fails to find and use some available substitutes

[George Clemmer]

Julien Lepiller  writes:

> I think guix' message is a bit confusing: the .drv file is always
> created by guix, it's the derivation. The derivation is built, which
> results in a new store path. It can be built locally or by using a
> substitute. What you see in your store is the derivation (.drv), not
> its result. You can open that file to find where the result will be
> stored and check if it exists on your machine.

Hi Julien,

Thank you. You are right, the .drv "out" substitute is not on my
local server. So this is not a bug. SORRY for the noise ;-)

After re-reading (guix) Derivations, I see I had a wrong impression:
that the presence of a .drv indicates a successful build. But AIUI now
it only means that at some point in the past we attempted to build the
.drv. IOW, we will also have .drv files for all failed builds.

Is that correct?

Thanks! - George

bug#33262: guix fails to find and use some available substitutes

[George Clemmer]

Oops, the server config attached to the previous email is incorrect,
sorry.  Here is the correct one:



sys.scm
Description: Binary data

bug#33262: guix fails to find and use some available substitutes

[George Clemmer]

I run 'guix system vm-image' VMs on a GuixSD server (hostname g1). The
VMs are configured to get substitutes from g1 in addition to the
official Guix servers.

This works great except that the VMs are failing to find/use some of the
substitutes that are available on g1.  E.g., in the attached log
(setup.log.gz) of the first 'guix package' issued on VM sysi58, curl is
built ...

building /gnu/store/24ag580271wa640529ycykdwj0lk0g6z-curl-7.61.1.tar.xz.drv...
downloading from https://curl.haxx.se/download/curl-7.61.1.tar.xz...
building /gnu/store/17lw3svpjqygpj739yynyz6b8abddikx-curl-7.61.1.drv...

... when the substitute is available in the g1 store ...

  /gnu/store:
  -r--r--r--2 root root3747 Dec 31  1969
   17lw3svpjqygpj739yynyz6b8abddikx-curl-7.61.1.drv

This is "infrequent", in the sense that a high percentabe of the
substitutes available from g1 are being found and used. However, these
other packages for which substitutes are available on g1 are also built:

downloading from ftp://ftp.knackered.org/pub/psutils/psutils.tar.gz...
downloading from http://download.osgeo.org/libtiff/tiff-4.0.9.tar.gz...
downloading from https://ftpmirror.gnu.org/gnu/groff/groff-1.22.3.tar.gz...
downloading from 
https://github.com/apple/cups/releases/download/v2.2.8/cups-2.2.8-source.tar.gz...
downloading from 
https://github.com/ArtifexSoftware/ghostpdl-downloads/releases/download/gs924/ghostscript-9.24.tar.xz...
downloading from 
https://gnupg.org/ftp/gcrypt/libgcrypt/libgcrypt-1.8.3.tar.bz2...
downloading from 
http://www.x.org/releases/individual/lib/libX11-1.6.6.tar.bz2...
downloading from 
http://www.x.org/releases/individual/lib/xtrans-1.3.5.tar.bz2...

Details:

Using Guix from Git:

Server g1: sys.scmv0.15.0-2913-g21c51ebd6

VM sysi58: sysi58.scm v0.15.0-3115-g7571ec357

TIA - George



sysi58.scm
Description: Binary data


sys.scm
Description: Binary data


setup.log.gz
Description: Binary data

bug#33223: In vm-image >>> 'guix package -i' >>> "-python-3.6.5.drv... -Killed"

[George Clemmer]

I rolled Guix back to the commit that produced this VM and built a fresh
VM. Unfortunately it did not reproduce this bug.

I doubt this was caused by the recent Guix infrastructure problems. I
favor the memory leak theory proposed by Christopher Baines ...

http://lists.gnu.org/archive/html/bug-guix/2018-11/msg00032.html

... for bug#33248: python-minimal compilation is breaking [1].

[1] http://lists.gnu.org/archive/html/bug-guix/2018-11/msg00032.html

bug#33248: python-minimal compilation is breaking

[George Clemmer]

Hello,

Christopher Baines  writes:

>> Most probably you are hitting a resource limit, I guess ram. Do you have
>> any swap?
>
> I think I've hit the same problem, I tried with 32GB of RAM, along with
> 60GB of swap, and it still didn't work.
>
> There is a bug here describing it as a memory link [1], which is a
> better theory I think.
>
> 1: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33213

Agreed. I had the same problem building ...

/gnu/store/phy1nbsmlml06lkjixjw2dfb4k6wi5al-python-3.6.5.drv...

... where I normally don't and I could see the build leaking [1]

- George

[1] http://lists.gnu.org/archive/html/bug-guix/2018-11/msg1.html

bug#33223: In vm-image >>> 'guix package -i' >>> "-python-3.6.5.drv... -Killed"

[George Clemmer]

Hello!

Gábor Boskovits  writes:

> George Clemmer  ezt írta (időpont: 2018. nov. 1., Cs, 3:11):
>>
>> In a 'guix system vm-image' VM produced using Guix from Git
>> v0.15.0-3097-gc16913d34

>> g1@sysi53 ~$ guix package -i emacs-no-x

>> building /gnu/store/phy1nbsmlml06lkjixjw2dfb4k6wi5al-python-3.6.5.drv...
>> -Killed

> I just came across this in a guix-help thread, there it seems that the
> VM does not have enough resources to build python3. Can that be the
> case here?

Thanks. The image was built by ...

guix system vm-image -M 4 -c 4 --image-size=20GB

... and run with 'qemu ... -m 5120'. Based on your comment I tried '-m
20G' and now the GiB Mem shown in top grows to 98.7/19.6, the VM
crashes, and there is no "Killed" message ;-O

Yes it's out of resources. But commit 7a06cdfa8 worked a day
earlier. Why is ...-python-3.6.5.drv... suddenly so hungry? Can Guix
infrastructure issues explain this?

- TIA, George

bug#33223: In vm-image >>> 'guix package -i' >>> "-python-3.6.5.drv... -Killed"

[George Clemmer]

George Clemmer  writes:

> In a 'guix system vm-image' VM produced using Guix from Git
> v0.15.0-3097-gc16913d34 I have ...
>
> g1@sysi53 ~$ guix --version
> guix (GNU Guix) 0.15.0-6.f9a8fce
>
> ... and when I try to install a package, e.g., ...
>
> g1@sysi53 ~$ guix package -i emacs-no-x
>
> ... I get ...
>
> building /gnu/store/phy1nbsmlml06lkjixjw2dfb4k6wi5al-python-3.6.5.drv...
> -Killed
>
> ... details and vm-image config, attached.
>
> TIA - George

BTW, a VM build one day ago from the one day ago Guix commit ...

7a06cdfa8c101f431227c4c5c86877939022fb1a COMMENT: "7a06cdfa8 gnu:
r-analytics: Update to 3.0."

... doesn't have the problem.

bug#33223: In vm-image >>> 'guix package -i' >>> "-python-3.6.5.drv... -Killed"

[George Clemmer]

In a 'guix system vm-image' VM produced using Guix from Git
v0.15.0-3097-gc16913d34 I have ...

g1@sysi53 ~$ guix --version
guix (GNU Guix) 0.15.0-6.f9a8fce

... and when I try to install a package, e.g., ...

g1@sysi53 ~$ guix package -i emacs-no-x

... I get ...

building /gnu/store/phy1nbsmlml06lkjixjw2dfb4k6wi5al-python-3.6.5.drv...
-Killed

... details and vm-image config, attached.

TIA - George



python-killed.log
Description: Binary data


sysi52.scm
Description: Binary data

bug#32646: emacs-guix doesn't build, because of guile-gcrypt

[George Clemmer]

Alex Kost  writes:

> George Clemmer (2018-09-10 10:31 -0400) wrote:
>
>> Alex Kost  writes:
>>
>>> Ludovic Courtès (2018-09-06 11:09 +0200) wrote:
>>>
>>>>> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
>>>>> no code for module (guix hash)
>>>>> make[2]: [Makefile:556: emacs-guix/hash.go] Error 1 (ignored)
>>>>
>>>> I suppose Emacs-Guix might need to use (gcrypt hash) instead.
>>>> Any ideas, Alex?
>>>
>>> Ouch, there is no (guix hash) anymore.
>>
>> Looking at commit '57d70dbab * master origin/master gnu: Add yad.'  it
>> seems that 'guix hash' is removed but still documented. Is a
>> re-implementation of 'guix hash' coming? Or is it the intent to remove
>> 'guix hash'. If so, ISTM this is be a meaningful loss of guix usability.
>
> No, no, the command "guix hash" did not go anywhere.  It's just (guix
> hash) module that was removed.  It was replaced by (gcrypt hash) module
> from "guile-gcrypt" package, which is a new dependency of Guix.

Ohh! DUH! Thanks for clarifying ;-) George

bug#32646: emacs-guix doesn't build, because of guile-gcrypt

[George Clemmer]

Alex Kost  writes:

> Ludovic Courtès (2018-09-06 11:09 +0200) wrote:
>
>>> ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
>>> no code for module (guix hash)
>>> make[2]: [Makefile:556: emacs-guix/hash.go] Error 1 (ignored)
>>
>> I suppose Emacs-Guix might need to use (gcrypt hash) instead.
>> Any ideas, Alex?
>
> Ouch, there is no (guix hash) anymore.

Looking at commit '57d70dbab * master origin/master gnu: Add yad.'  it
seems that 'guix hash' is removed but still documented. Is a
re-implementation of 'guix hash' coming? Or is it the intent to remove
'guix hash'. If so, ISTM this is be a meaningful loss of guix usability.

bug#31841: ./pre-inst-env guix system no longer works without ~/.config/guix

[George Clemmer]

Mark H Weaver  writes:

> Hi,
>
> l...@gnu.org (Ludovic Courtès) writes:
>
>> myg...@gmail.com skribis:
>>
>>> Based on this thread I am now making guix like this ...
>>>
>>> guix environment guix --ad-hoc guile-sqlite3 --root=build-env -- make 
>>> [MAKECMDGOALS]
>>>
>>> ... and using it like this ...
>>>
>>> source build-env/etc/profile
>>> ./pre-inst-env guix COMMAND ARGS...
>>
>> Yeah we can improve the doc.  Currently, “Building from Git” mentions
>> ‘guix environment guix’, but “Running Guix Before It Is Installed”
>> doesn’t.  How about this:
>>
>> diff --git a/doc/contributing.texi b/doc/contributing.texi
>> index 205c972ae..3f82f4bc2 100644
>> --- a/doc/contributing.texi
>> +++ b/doc/contributing.texi
>> @@ -108,7 +108,9 @@ actually installing them.  So that you can distinguish 
>> between your
>>  ``end-user'' hat and your ``motley'' costume.
>>
>>  To that end, all the command-line tools can be used even if you have not
>> -run @code{make install}.  To do that, prefix each command with
>> +run @code{make install}.  To do that, you first need to have an environment
>> +with all the dependencies available (@pxref{Building from Git}), and then
>> +simply prefix each command with
>>  @command{./pre-inst-env} (the @file{pre-inst-env} script lives in the
>>  top build tree of Guix), as in@footnote{The @option{-E} flag to
>>  @command{sudo} guarantees that @code{GUILE_LOAD_PATH} is correctly set
>>
>>
>> Note that I purposely did not mention “--ad-hoc guile-sqlite3” because
>> it has become unnecessary with commit
>> c5a2e1ffcb029f50c4c18352cf378b61c41c625e.
>>
>> Likewise, I did not mention “source build-env/etc/profile” because
>> “Building from Git” suggests using ‘guix environment guix’, which sets
>> up the right environment variables.
>>
>> WDYT?
>
> When running Guix exclusively from a git checkout and never running
> 'guix pull', something like "source build-env/etc/profile" must now be
> run before running 'guix'.
>
> You seem to be suggesting that "source build-env/etc/profile" could
> simply be replaced by "guix environment guix".  One problem with this
> idea is that it would introduce a circularity.  My 'guix' script cannot
> very well begin by running 'guix environment guix'.
>
> There are other problems as well:
>
> (1) The build environment used to build the git checkout must be
> registered as a GC root, or else "guix gc" may render my git
> checkout of 'guix' non-functional, with no easy way to recover
> (at least not without running 'guix pull').
>
> (2) When my git checkout is in a bad state, or is unbuilt, then during
> this time I'm unable to easily run "guix environment guix".  So, I
> always need a way to restore a known good development environment to
> rebuild my copy of guix, without using guix itself.  My method is to
> source the etc/profile from my saved development environment profile.
>
> I should emphasize that when running Guix this way, if you wish to avoid
> running 'guix pull', it's important to always keep at least one
> known-good development environment for Guix saved as a GC root.  Toward
> that end, when I run "guix environment guix" to update my development
> environment profile, I make sure to preserve my previous profile as a GC
> root until I'm confident that my new profile is working.
>
> The suggested recipe involving "guix environment guix --root=build-env"
> command is a nice improvement over my manual management of these GC
> roots, but it has one shortcoming: it discards the older profile symlink
> and GC root immediately, before it's known whether the new profile works.
>
> This message should make it clear that when using Guix in this way, it's
> easy to get stuck if you're not careful.  I suppose that I could always
> get unstuck by running 'guix pull', but I prefer to avoid it.
>
>  Regards,
>Mark

Hi Mark,

While I have submitted a few patches, generally I use 'guix pull; make'
primarily to manage my GuixSD systems. In the past 2+ years I have had
to "resort" to 'guix pull' only a few times, usually to escape the 'guix
environment guix' "hole" you describe. Eventually I discovered that if I
_never_ did 'guix gc' and did 'guix environment guix' _before_ I did
'git pull', I never fell into the "hole", that is, unless I screwed up
and did git pull first ;-)

I recently started using gc roots and "custom" profiles and put my guix
build into a makefile "harness" to eliminate manual steps.  I also
switched from the symlink to a script like yours. My script also falls
back to the globally-installed Guix if an environmental is set.

The harness inflates a custom profile and includes a makefile that calls
'guix environment guix -- make'. I added the gc root to work around the
issue raised by this bug.

Recently I have been eyeing all the thrashing that goes on when 'guix
environment' is run after a "big" pull. Previously I avoided this
thrashing and the hole when I remembered to do 'guix environment guix'
before 

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[George Clemmer]

Ricardo Wurmus  writes:

> Hi George,
>
>> The current doc reflects the needs and sensibilities of the hackers,
>> maintainers, and sysops that have built Guix. These "elite" users have
>> different needs and judge what is important quite differently from end
>> users. This guarantees that the current doc is inadequate for end users.
>> So, if, as you say, you want to make Guix accessible to end users, you
>> need to make changes in the doc.  The questions: How? What?
> […]
>> I said: I use 'pre-inst-env guix' this way and this is a bug.
>
> “pre-inst-env” really should not be used by people other than
> developers.  It is only available when building Guix from a clone of the
> git repository.
>
> We do not recommend “pre-inst-env” for any other purpose than to make
> changes to the code, so I would not like to document the quirks and
> limitations of “pre-inst-env” in the manual, as this is not how Guix is
> supposed to be used generally.
>
>> Proposed (revised) footnote:
>>
>> (3) The Guix version in the Guix build is set by './bootstrap'. Thus,
>> the version reported by './pre-inst-env guix --version' is not updated
>> by subsequent 'git pull; make' steps. To update the version (and rebuild
>> everything), use 'git clean -dfx; ./bootstrap; ./configure; make'.
>
> I’m wary of adding this for similar reasons that Ludo wrote earlier.  In
> my opinion this ends up cluttering the manual with notes and what I
> consider to be only tangentially relevant for readers of the manual.

Hi Ricardo,

Please read further down the original post. I think you will find that I
already addressed your points.

Collectively, the responses here bring to mind a Harvard Business School
case study I was taught in 1983. The gist of it: Bakers at Holsum Bread
told a salesman that they had figured out how to run his company's bread
making machine at twice the design speed. Because this was twice as fast
as the competitor's machine, they wanted to place a big order for more
machines. When the salesman told the company engineer about the order he
said, "You can't sell any more machines to Holsum because they aren't
using my machine properly!"

- George

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[George Clemmer]

Ludovic Courtès  writes:

> Hi George,
>
> George Clemmer  skribis:
>
>> Leo Famulari  writes:
>>
>>> On Wed, Jun 13, 2018 at 08:54:49AM +0200, Ludovic Courtès wrote:
>>>> The other aspect, from a maintenance and readability viewpoint, is that
>>>> we could quickly add up lots of explanations that we’ll have to keep
>>>> up-to-date and that may make more important information harder to find.
>>>
>>> Yeah, I'm worried about this too. It's tough to strike the correct
>>> balance.
>>
>> IMO Guix is great for hackers, maintainers and sysops. The doc is
>> appropriate for such users, well done, spare, and already voluminous.
>>
>> This footnote suggestion, and others rejected in the past, are motivated
>> by my assumption that you will want to make Guix attractive to less
>> sophisticated users.
>>
>> Maybe my assumption is wrong? Maybe you want only "elite" users?
>
> No, definitely not; I’m sorry if this is the impression this gave.
>
> Like I wrote, my main concern is about keeping the documentation focused
> and maintainable.  Sometimes we have to document things that are
> technically outside of Guix because there’s no real canonical
> documentation and because users would be impaired without it—I’m
> thinking for instance of bits in the “Preparing for Installation”
> section.
>
> In this case, we’d be documenting something that’s both outside of Guix
> and not vital for routine usage, and that’s mostly covered by the
> Autoconf manual.  Hence my reluctance.
>
> I hope that makes sense.

Hi Ludo’,

I see the situation this way:

The current doc reflects the needs and sensibilities of the hackers,
maintainers, and sysops that have built Guix. These "elite" users have
different needs and judge what is important quite differently from end
users. This guarantees that the current doc is inadequate for end users.
So, if, as you say, you want to make Guix accessible to end users, you
need to make changes in the doc.  The questions: How? What?

May I suggest ...

a) Adopt a less defensive posture when responding to user questions,
   comments, and bug reports.

b) Be pro-active about capturing support resolutions in the doc.

This thread presents a nice example of what I am talking about. To
recap:

I said: I use 'pre-inst-env guix' this way and this is a bug.

You said: Developers expect this, so it's not a bug.

A less defensive response: Hmm, You are using 'pre-inst-env guix' in a
way we didn't anticipate. What are the benefits of using it this way? I
see how this is a bug for your use case.

We discussed a workaround. I suggested adding it to the doc.

You said: I’m not comfortable documenting this because it’s nothing
specific to Guix.

I said: I urge you to reconsider.

You said: This part of the manual targets developers... they know where
to look things up. [The more we write the more we have to maintain.]

And Clément Lassieur  added:

> But non-hacker users can use Guix pull!  Running Guix before it is
> installed (with pre-inst-env) is described in the manual as a "Hacker
> trick".

> Guix pull is well documented, and should be usable for non-elite users.

OK, but I'm non-elite and I have used Guix for 2+ years. I have tried
both. I prefer pre-inst-env. I expect others will too. The fact is that
pre-inst-env does not correctly report the version after 'git pull;
make'. How can you know that this won't be a problem for other users?
It only takes 4 lines to explain this and provide a workaround, e.g.,

Proposed (revised) footnote:

(3) The Guix version in the Guix build is set by './bootstrap'. Thus,
the version reported by './pre-inst-env guix --version' is not updated
by subsequent 'git pull; make' steps. To update the version (and rebuild
everything), use 'git clean -dfx; ./bootstrap; ./configure; make'.

- George

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[George Clemmer]

Ludovic Courtès  writes:

> George Clemmer  skribis:
>
>> Ok, cool. Thanks for the clarification. So... how about adding a
>> footnote to '(guix) Running Guix Before It Is Installed' something like
>> ...
>>
>> (3) The Guix version in the Guix build is set by './configure'. Thus,
>> when guix is run from the Git working tree by './pre-inst-env guix' or a
>> '~/.config/guix/latest’ symlink, the version reported by 'guix
>> --version' is not updated by subsequent 'git pull; make' steps. To
>> update the version (and rebuild everything), you may use 'git clean
>> -dfx; ./bootstrap; ./configure; make'.
>
> I’m not comfortable documenting this because it’s nothing specific to
> Guix.

So to summarize: This behavior is a side effect of how GNU tools
work. It is obvious to anyone who understands them. You don't want to
describe things that are obvious. I understand.

But I think many users don't have a clue about GNU build tools. They may
be puzzled by how pre-inst-env works. I think the footnote would be
helpful for them. I urge you to reconsider.

> Besides, note that ~/.config/guix/latest no longer exists.

Yes, I saw you revamped Guix pull but I haven't actually used guix pull
in over a year.  I need to check the new one out.

- George

bug#31786: 'pre-inst-env guix --version' is not updated by new commits"

[George Clemmer]

Ludovic Courtès  writes:

> Hello George,
>
> George Clemmer  skribis:
>
>> But with subsequent git commit/make cycles the version does not
>> change. It doesn't change when the guix package is updated either. For
>> example, after pulling and building the recent commit updating the guix
>> package ...
>
> Currently the version number is hardcoded in ‘configure.ac’, so the fact
> that running “git pull && make” doesn’t change it is expected.  So to
> me, it’s not a bug.
>
> We could improve on that (see for instance how Guile does it with
> build-aux/git-version-gen), but it still won’t be updated at each commit
> because that’d be inconvenient: ‘config.h’ would regenerated, so in turn
> we’d need to rebuild all of the C++ code.

Hi Ludo’,

Ok, cool. Thanks for the clarification. So... how about adding a
footnote to '(guix) Running Guix Before It Is Installed' something like
...

(3) The Guix version in the Guix build is set by './configure'. Thus,
when guix is run from the Git working tree by './pre-inst-env guix' or a
'~/.config/guix/latest’ symlink, the version reported by 'guix
--version' is not updated by subsequent 'git pull; make' steps. To
update the version (and rebuild everything), you may use 'git clean
-dfx; ./bootstrap; ./configure; make'.

Note: I also tried 'make distclean' and 'make maintainer-clean' which
didn't work.

> ‘guix pull’ does the right thing though, which I think is more important
> than the build tree.

Agreed.

>> Side questions:
>>
>> 1) why don't you gitignore "doc/stamp-1"?
>
> Good idea, done!  :-)

Thanks!

>> 2) why don't you gitignore .po files?
>
> Because they are checked in.

I guess I meant to say, why does the build change these checked-in
files? It seems like they should be ignored.

TIA - George

bug#31403: Font installed in non-default profile doesn't appear.

[George Clemmer]

George Clemmer <myg...@gmail.com> writes:

> Alex Kost <alez...@gmail.com> writes:
>
>> Hello George,
>>
>> George Clemmer (2018-05-08 20:04 -0400) wrote:
>>
>>> In a "headless" vm-image (sysi29.scm, attached), "font-dejavu" installed
>>> by manifest (attached) into the "empty" default profile ...
>>>
>>> 'guix package -m manifest'
>>>
>>> ... appears in the emacs 'M-x menu-set-font' choice box. But it doesn't
>>> appear with the same manifest installed in the "foo" profile ...
>>
>> To make fonts available from a non-standard profile I added the
>> following line into my "~/config/fontconfig/fonts.conf":
>>
>>   ~/path-to-my-profile/share/fonts
>
> Thank you Alex!
>
> On the chance it might be useful to someone else, this ...
>
> 
> 
> 
> 
> ~/path-to-my-profile/share/fonts
> 
>
> ... in "~/.config/fontconfig/fonts.conf" worked for me ;-)

Given that this works, ISTM this can be fixed by placing ...





share/fonts


... in "/etc/fonts/fonts.conf".

WDYT? - George

bug#31367: ERROR: In procedure scm-error: no code for module (guix build utils)

[George Clemmer]

Hi Ludo’,

Ludovic Courtès writes:

> I’m merging it with .  No fix yet but we’re
> working on it.  In the meantime, ‘guix pull’ may allow you to work
> around it.

Thanks for the update. No rush, I have a workaround ;-)