bug#57022: fmit fails to build/upgrade
On 07-08-2022 01:14, Dr. Arne Babenhauserheide wrote:
I get a build error when updating fmit with
guix upgrade fmit
It fails with
phase `install' succeeded after 0.4 seconds
starting phase `wrap-executable'
error: in phase 'wrap-executable': uncaught exception:
wrong-type-arg "string-append" "Wrong type (expecting ~A): ~S" ("string"
#f) (#f)
phase `wrap-executable' failed after 0.0 seconds
Backtrace:
14 (primitive-load "/gnu/store/k7dvw09nink46bbpls85bzw5560…")
In guix/build/gnu-build-system.scm:
906:2 13 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
1752:10 12 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
634:9 11 (for-each # …)
In ice-9/boot-9.scm:
1752:10 10 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
927:23 9 (_)
In ice-9/eval.scm:
619:8 8 (_ #(#(#(#) # #) #))
163:9 7 (_ #(#(#(#) # #) #))
174:20 6 (_ #(#(#(#) # #) #))
177:32 5 (lp (#))
In ice-9/boot-9.scm:
222:29 4 (map1 ("qtbase" "qtmultimedia-5" "qtsvg-5"))
222:17 3 (map1 ("qtmultimedia-5" "qtsvg-5"))
Looks like fallout from #56771, the fix is possibly just a matter of
replacing "qtmultimedia-5" with "qtmultimedia" in the package definition
and likewise for qtsvg.
Greetings,
Maxime.
OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
bug#50916: Experimental `guix container PID program args` not working as expected
This bug still persists and effectively bypasses container sandboxing: 1. Start a container shell. $ guix shell --container 2. Exec a shell inside the container. Here it is a foreign distro's bash, and assume that there is only 1 container running. $ guix container exec $(pgrep --full 'guix shell --container') /bin/bash 3. Observe that path is not empty. $ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/bin This shell can access commands outside the container, such as kill (part of util-linux). 4. Kill the container from the shell inside the container. [env] $ kill -9 $(pgrep --full 'guix shell --container') [env] $ echo $? 0 The shell still persists in the container, even though the container itself is killed. The problem is that in guix/scripts/container/exec.scm, execlp is used to launch program with args. info guile says this about execlp: Similar to ‘execl’, however if FILENAME does not contain a slash then the file to execute will be located by searching the directories listed in the ‘PATH’ environment variable. As seen above $PATH is set to a subset of the host system's PATH, not the PATH inside the guix container.
bug#57037: Package `guile-newt' cannot be cross-compiled
The `guile-newt' package that is used for the installation UI can't be cross-compiled as it tries to load the `newt' dynamic library when the Guile code is compiled. I've tried to find a solution/fix but I don't know much about how Guile byte-code compilation works. The compilation error can be reproduced with (#56536 was pushed a few hours ago, so a git pull may be needed): ./pre-inst-env guix build guile-newt --target=aarch64-linux-gnu I think this is one of the last remaining bits before being able to fully cross compile an installation image. — Jean-Pierre De Jesus DIAZ
bug#55657: libgccjit is unusable
Am Sonntag, dem 07.08.2022 um 03:19 + schrieb John Kehayias: > So. I tried to see what was different between your and Andrew's code > and I'm not seeing what it could be. There must be some subtle > difference we're missing? Seems we have all the ingredients and a > known working example. It's a really stupid one. Basically, the tests and really any executable you try to build fails to execute without LD_LIBRARY_PATH set. Now obviously, that's an issue with ld and you know which package has ld? That's right, it's binutils! In Andrew's recipe, he sneakily snarfed out binutils from inputs using assoc-ref, but I'm using the new package style with (this-package- input) to achieve the same thing, so I had to add binutils. But this now shadows ld-wrapper. So we have to add ld-wrapper as well. Now this makes me question whether the driver options are actually sane or whether we'd have to prepend ld-wrapper to those as well. WDYT, Andrew?
bug#55657: libgccjit is unusable
--- Original Message --- On Sunday, August 7th, 2022 at 9:59 AM, Liliana Marie Prikler wrote: > It's a really stupid one. Basically, the tests and really any > executable you try to build fails to execute without LD_LIBRARY_PATH > set. Now obviously, that's an issue with ld and you know which package > has ld? That's right, it's binutils! > Ah! That LD_LIBRARY_PATH was needed was the clue. > In Andrew's recipe, he sneakily snarfed out binutils from inputs using > assoc-ref, but I'm using the new package style with (this-package- > input) to achieve the same thing, so I had to add binutils. But this > now shadows ld-wrapper. So we have to add ld-wrapper as well. Now > this makes me question whether the driver options are actually sane or > whether we'd have to prepend ld-wrapper to those as well. > Is the assoc-ref for binutils (implicit input?) equivalent to just using #$binutils directly? e.g. (string-append "-B" #$binutils "/bin/") with no added binutils to the inputs. Is that not a good idea? As a test, that does indeed work, everything configures, builds, and runs (only tested opening with no configuration). > WDYT, Andrew?
bug#55657: libgccjit is unusable
Am Sonntag, dem 07.08.2022 um 15:09 + schrieb John Kehayias: > Is the assoc-ref for binutils (implicit input?) equivalent to just > using #$binutils directly? e.g. (string-append "-B" #$binutils > "/bin/") with no added binutils to the inputs. Is that not a good > idea? As a test, that does indeed work, everything configures, > builds, and runs (only tested opening with no configuration). Not quite, because this binutils is actually binutils-final from commencement.scm, which it doesn't seem we can import the normal way. Also doing this would make it so that binutils isn't configurable, which with an input you get. The trick is just to also use make-ld- wrapper from base.scm Cheers
bug#56799: (gnu services configuration) usage of *unspecified* is problematic
Hello, I just hit this while running ‘guix home reconfigure’ from f0ae9da3210cc6d87ca519545203daf9751f3465: home-config.scm:24:16: error: invalid value unset for field 'address-family' It’s an ‘openssh-host’ record: (openssh-host (name "xyz") (host-name "xyz.example.org") (user "ludo")) ⇒ #< %location: #f name: "xyz" host-name: "xyz.example.org" address-family: # identity-file: # port: # user: "ludo" forward-x11?: #f forward-x11-trusted?: #f forward-agent?: #f compression?: #f proxy-command: # host-key-algorithms: # accepted-key-types: # extra-content: ""> We have a new bug to address. Ludo’.
bug#57048: tiled-1.8.1 fails to build
log here: http://ix.io/46XY I was just running guix upgrades, for the first time in 12 days or so.
bug#57049: cool-retro-term-1.2.0 build failure
build log: http://ix.io/46Yn guix version: just shows up as 0 for some reason...
bug#57048: tiled-1.8.1 fails to build
Fixed in commit ee216d16ef5ea537eaf5508dcffa5d808ab62bb0, thank you for the report!
bug#56971: greeter user permissions are not enough to talk with seatd
Am Sonntag, dem 07.08.2022 um 23:48 +0300 schrieb muradm: > Point is not that "there are any/others affected", the point is, > that seatd is providing [an] interface, and currently it has a > problem, which is wrong permission. But there are two sides in this permission issue. Note that the subject line of the email is the inverse of what you just said. Note further how this issue doesn't require a single, but two patches to solve, which are currently marked as blockers. These are obviously related. Cheers
