bug#40729: Two rottlog servives causes cryptic etc drv failure
Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> I got this error when reconfiguring with a recent revision of Guix. >> >> >> /builder for `/gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv' failed >> with exit code 1 >> build of /gnu/store/kbhl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv failed >> View build log at >> '/var/log/guix/drvs/kb/hl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv.bz2'. >> building /gnu/store/59bd67s06inr5vzyxc70yk6garj2aciz-linux-modules.drv... >> cannot build derivation >> `/gnu/store/n45vq7jbhn5qz24qlgv6a6ginarqs433-system.drv': 1 dependencies >> couldn't be built >> guix system: error: build of >> `/gnu/store/n45vq7jbhn5qz24qlgv6a6ginarqs433-system.drv' failed >> chris@guix-hetzner-1 ~$ bzcat >> /var/log/guix/drvs/kb/hl4rk6p0z4jbimlqj57vj3dhyjgv4x-etc.drv.bz2 >> Backtrace: >>1 (primitive-load "/gnu/store/g4q88pmwr1vy54qpnkz878k3n7f?") >>0 (symlink "/gnu/store/939n705vmkn8613b8gjc10llvsr5jcwc-?" ?) >> >> ERROR: In procedure symlink: >> In procedure symlink: File exists > > Yeah that’s something I noticed here: > > https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00032.html > > Commit a322e9d16b227484ce04721fee0f99618cb1007e does that. > > The result is not optimal yet because it just says “duplicate entries”. > Ideally we’d be able to show a ‘fold-services’ trace of sorts telling > showing where the faulty entries come from. Awesome, that'll be useful for sure :) Thanks, Chris signature.asc Description: PGP signature
bug#40736: Python manylinux wheels cannot find libstdc++.so.6
writes: > Hi, > > I cannot get precompiled python wheels working in a guix environment, > because libstdc++.so.6 is missing. Is this library hidden on purpose? > > It is available for example in > /gnu/store/xqjpihbfdc62d2q0sn8i0y0g1xpzbr1s-gcc-9.3.0-lib/lib/ and > adding that path manually to LD_LIBRARY_PATH seems to fix the issue. > > What is the proper way to include libstdc++.so.6 in my profile? #+BEGIN_EXAMPE guix environment --ad-hoc -e '(list (@@ (gnu packages gcc) gcc-9) "lib")' #+END_EXAMPLE -- WBR, Boris Dekshteyn
bug#40740: guix build problem, no RUNPATH on libpthread.so
Dear Michael,
> On Tue, Apr 21, 2020 at 09:41:47AM +0930, Michael Zucchi wrote:
> > But the first guix pull fails because it tries to run a 32 bit binary, so
> > ultimately fails for the the same reason as detailed in my previous email.
To be sure to understand,
- your machine is 64bit
- and you are running Guix on the top of Slackware
- Guix has been installed using this script
https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
Right?
Then, something screws up and some 32bit stuff shows up, right?
The previous emails related to this topic you mentioned ("I posted
about this months ago but I think I got no answers") in this thread
are [1] and [2], right?
[1] https://lists.gnu.org/archive/html/help-guix/2019-12/msg00111.html
[2] https://lists.gnu.org/archive/html/help-guix/2019-12/msg00131.html
All the best,
simon
bug#40744: guile-2.2.4 (integer-length 0) erroneously returns 0, not 1
Hello guix/guile bug-squashers,
The tl;dr is:
(integer-length 0) should agree with:
(string-length (number->string 0 2)) =-> 1
-- and not: (integer-length 0) =-> 0
The integer length in bits (short for binary digits :)
is the number digits required to write the integer value
in conventional big-endian digit order, signifying coefficients
of successive powers of the radix used.
This applies irrespective of the radix. Thus "11" in decimal is
"1*10^1 + 1*10^0"
or hex is
"11*16^0"
or binary is
"1*2^1 + 1*2^0"
So, the crux of the argument is that it takes one digit to write
either 1 or 0:
--8<---cut here---start->8---
Inputs: 1 (radix 10, decimal value unsigned 1) (output radix 2)
Number as radix-2 glyph{0..1} string (unsigned)
"1"
Number as glyphs representing coefficient values of radix polynomial for
number value:
("1")
(1) -- corresponding coefficient values
Number as polynomial expression:
"1*2^0"
(1) -- corresponding term values
1 -- sum of term values
The following should be equal to guile's (integer-length 1):
1 integer-digit (radix 2)
--8<---cut here---end--->8---
--8<---cut here---start->8---
Inputs: 0 (radix 10, decimal value unsigned 0) (output radix 2)
Number as radix-2 glyph{0..1} string (unsigned)
"0"
Number as glyphs representing coefficient values of radix polynomial for
number value:
("0")
(0) -- corresponding coefficient values
Number as polynomial expression:
"0*2^0"
(0) -- corresponding term values
0 -- sum of term values
The following should be equal to guile's (integer-length 0):
1 integer-digit (radix 2)
--8<---cut here---end--->8---
BTW, this works for signed numbers as well, if you use a complement
representation making the sign digit 0 for positive and radix-1 for
negative (thus 0 and 1 for radix 2, and e.g. 0 and f for radix 16).
Decimal is just another radix:
Inputs: -11 (radix 10, decimal value minus 11) (output radix 10)
Number as radix-10 glyph{0..9} string (radix-complement -sign prefix)
"989" (complement notation)
^--(note that 0 and "9" (radix10 -1) are sign digits for 0 and -1
coefficient values in the polynomial)
Number as glyphs representing coefficient values of radix polynomial for
number value:
("-1" "8" "9")
(-1 8 9) -- corresponding coefficient values
Number as polynomial expression:
"-1*10^2 + 8*10^1 + 9*10^0"
(-100 80 9) -- corresponding term values
-11 -- sum of term values
Tip: for guile integer-length, enter unsigned value with output radix 2
3 integer-digits (radix 10)
The extreme for this version is radix 36:
Inputs: -11 (radix 36, decimal value minus 37) (output radix 36)
Number as radix-36 glyph{0..z} string (radix-complement -sign prefix)
"zyz" (complement notation)
^--(note that 0 and "z" (radix36 -1) are sign digits for 0 and -1
coefficient values in the polynomial)
Number as glyphs representing coefficient values of radix polynomial for
number value:
("-1" "y" "z")
(-1 34 35) -- corresponding coefficient values
Number as polynomial expression:
"-1*36^2 + 34*36^1 + 35*36^0"
(-1296 1224 35) -- corresponding term values
-37 -- sum of term values
Tip: for guile integer-length, enter unsigned value with output radix 2
3 integer-digits (radix 36)
I got a little carried away exploring the complement notation, and wrote
a thing to explain the meanings. Please copy snip to int2poly and chmod 755 it.
Then run once without args for usage help.
I hope it will convince you that guile (integer-length 0) should be 1 ;-)
--8<---cut here---start->8---
#!/usr/bin/env -S guile -e main -s
!#
;; run without arguments for usage, or read below
;; int2poly-0.1.0 -- 2020-04-21
(use-modules (ice-9 format)
(ice-9 regex))
(define self (basename (car (command-line
(define verbose #f)
(define (usage)
(begin
(let*((selfxxx (basename (car (command-line)
(begin
(format (current-error-port)
"Usage:
~a [-v ] | NUMSTR [out-radix] [inp-radix]
where *-radix are entered in decimal, and
out-radix defaults to 2 and inp-radix defaults to 10,
but may set independently to 2..36 to demo generality.
-v for verbose output explanations
NUMSTR will be written in radix digits representing
polynomial coefficients, which is presented in series terms
and evaluated back to the original number.
The NUMSTR character set is the same as for (number->string radix)
but could be any chosen set of distinct glyphs for values {0..}.
guile integer-length can be considered a special case of
coefficient count for radix 2, which is printed in the last
line of output as \"N integer-digits (radix N)\n"
self ))
(if (= (integ
bug#40612: guix build system --dry-run is broken
Hi, Mark H Weaver skribis: > Ludovic Courtès wrote: >> Mark H Weaver skribis: >> >>> Yes, of course, I agree that it's not possible to present a build plan >>> ahead of time when grafts are enabled. That was the case before these >>> changes, and it's the case today. >>> >>> The only part I don't understand is why you decided that "--dry-run" >>> should no longer imply "--no-grafts". Does it work better for other >>> people? For me, the "--dry-run" output has become utterly useless >>> unless "--no-grafts" is included. >> >> I explained the pros and cons of having ‘--dry-run’ no longer implying >> ‘--with-grafts’ here: >> >> https://lists.gnu.org/archive/html/guix-devel/2020-03/msg00337.html > > I read that message, but was unable to find any mention of the 'pros' of > having '--dry-run' no longer imply '--no-grafts'. Did I miss it? I > still don't know what is the argument in favor of that change. The “pro” is not there, you’re right. It’s basically about eliminating a special case. The ideal would be that the special case is unnecessary and grafts can be considered a special case of dynamic dependencies. I’m not saying we’re there yet, I pointed out weaknesses and you found other instances, but that’s the general direction I wanted to take. >> ‘guix package --dry-run’ overall works well IME, except when a >> dependency of a fixed-output derivation is missing, as explained above. >> >> ‘guix system’ doesn’t work so well as you note (though again, that >> depends on what you’re building vs. what you have in store). > > For what it's worth, I've found the --dry-run output to be similarly > useless when rebuilding my user profile as well. Not for me, but we could look at specific examples. Whether substitutes are used makes no difference, which is an improvement compared to the previous situation! Thanks for your feedback, Ludo’.
bug#40682: frozen installer in WiFi section -guix 1.1.0
Hi, Mathieu Othacehe skribis: > Almost unrelated topic, it would be nice to provide an interface where > users can grab a nightly/periodic build of the installer and test the > latest fixes. We are already have "usb-image" and "iso9660-image" jobs > in Cuirass. So it could be a link allowing to download the latest > successful build or so. Yes, it would be nice. We’d need to allow Cuirass to somehow publish raw files, like Hydra does. Ludo’.
bug#40740: guix build problem, no RUNPATH on libpthread.so
G'day Simon,
On 21/4/20 5:25 pm, zimoun wrote:
Dear Michael,
On Tue, Apr 21, 2020 at 09:41:47AM +0930, Michael Zucchi wrote:
But the first guix pull fails because it tries to run a 32 bit binary, so
ultimately fails for the the same reason as detailed in my previous email.
To be sure to understand,
- your machine is 64bit
- and you are running Guix on the top of Slackware
- Guix has been installed using this script
https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
Right?
Correct although I can't remember if i ran the script or used the steps
in the manual
[https://guix.gnu.org/manual/en/html_node/Binary-Installation.html].
slackware doesn't use one of the supported init systems and all the
steps it performs are trivial so i might've skipped it. guix with
substitutions was working ok for the limited use I made of it.
Then, something screws up and some 32bit stuff shows up, right?
Well yes and no - nothing screws up and the behaviour is intended it
just doesn't work. As i found[2] 4 months ago, the bootstrap package
explicitly uses i686 binaries for amd64 because (I presume) they are
statically linked and all amd64 hardware supports executing 32-bit mode
code. But my linux configuration disables it because i don't need or
want it.
It all happens here:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootstrap.scm#n128
|(define bootstrap-executable (mlambda (program system) "Return an
origin for PROGRAM, a statically-linked bootstrap executable built for
SYSTEM." ;>> (let ((system (if (string=? system
"x86_64-linux") "i686-linux" system))) ;<< (match
(assoc-ref (assoc-ref %bootstrap-executables system) program) (#f (raise
(condition (&message (message (format #f (G_ "could not find bootstrap
binary '~a' \ for system '~a'") program system)) ((sha256) (origin
(method url-fetch/executable) (uri (bootstrap-executable-url program
system)) (file-name program) (sha256 sha256))) |
||
||
|I attempted modifying this to use 64-bit binaries at the time but it
wouldn't use the ones i supplied when it|
|came to executing the tests. So I dropped it as it was going nowhere
fast, nobody seemed interested, and had
other things to do like xmas. ||Those failed attempts are long gone.|
||
||
||
The previous emails related to this topic you mentioned ("I posted
about this months ago but I think I got no answers") in this thread
are [1] and [2], right?
[1] https://lists.gnu.org/archive/html/help-guix/2019-12/msg00111.html
[2] https://lists.gnu.org/archive/html/help-guix/2019-12/msg00131.html
Yeah.
All the best,
simon
Cheers,
Z
bug#40758: build failure: gcc-4.8.5 (gcc-toolchain-4.8.5)
My attempt to build gcc-toolchain-4.8.5 dies, with a build failure in the gcc package. I was hoping to use this package to try to build some older software. christopher@nightshade ~/Repos/guix-working$ guix describe Generation 16 Apr 11 2020 08:47:10(current) guix 658505d repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 658505d7a92f0518e1fc4c965bdaa389a6e83f2c Error: In file included from ../../gcc-4.8.5/gcc/cp/except.c:1008:0: cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’: cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here cfns.gperf: At global scope: cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const char*, unsigned int)’ used but never defined make[3]: *** [Makefile:1059: cp/except.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcc.pod make[3]: Leaving directory '/tmp/guix-build-gcc-4.8.5.drv-0/build/gcc' make[2]: *** [Makefile:4157: all-stage1-gcc] Error 2 make[2]: Leaving directory '/tmp/guix-build-gcc-4.8.5.drv-0/build' make[1]: *** [Makefile:18767: stage1-bubble] Error 2 make[1]: Leaving directory '/tmp/guix-build-gcc-4.8.5.drv-0/build' make: *** [Makefile:886: all] Error 2 command "make" "-j" "3" "LDFLAGS_FOR_TARGET=- B/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib -Wl,- dynamic-linker -Wl,/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc- 2.29/lib/ld-linux-x86-64.so.2" "LDFLAGS=-Wl,- rpath=/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib -Wl,- dynamic-linker -Wl,/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc- 2.29/lib/ld-linux-x86-64.so.2" "BOOT_CFLAGS=-O2 -g0" failed with status 2 builder for `/gnu/store/nx6ndhvxg8b2vzhs56fnd3hydkif0rgh-gcc-4.8.5.drv' failed with exit code 1 build of /gnu/store/nx6ndhvxg8b2vzhs56fnd3hydkif0rgh-gcc-4.8.5.drv failed View build log at '/var/log/guix/drvs/nx/6ndhvxg8b2vzhs56fnd3hydkif0rgh-gcc- 4.8.5.drv.bz2'. cannot build derivation `/gnu/store/qcakvv0m8xbyaw36ykmdm878jjii73b4- gcc-toolchain-4.8.5.drv': 1 dependencies couldn't be built guix build: error: build of `/gnu/store/qcakvv0m8xbyaw36ykmdm878jjii73b4-gcc-toolchain-4.8.5.drv' failed -- Christopher Howard p: +1 (907) 374-0257 w: https://librehacker.com social: https://gnusocial.club/librehacker gpg: ADDEAADE5D607C8D (keys.gnupg.net)
