bug#41669: Cross-compiled powerpc64-linux bootstrap-tarballs not reproducible
Hi Vincent and everyone, Vincent Legoll writes: > Is that showing the same (or a similar) problem : > > https://data.guix-patches.cbaines.net/gnu/store/0lcbxpw1vrca02dzpzw2rxhad7pn4zw7-gcc-objc-5.5.0 > > ? Can you clarify what you mean? I'm not sure what you're referring to. Chris Marusich writes: > At present, it seems possible that within the context of a single > machine, gcc-stripped-tarball-5.5.0.drv builds reproducibly, but on a > different machine, it may (reproducibly) build a different output. > I'm a bit paranoid about making mistakes, so I'll perform another full > GC and then try yet again to build gcc-stripped-tarball-5.5.0.drv in > order to verify whether it truly produces the same output when all (or > nearly all) of its inputs are rebuilt from scratch. I repeated the experiment on the same machine (it took a day or two to build), and the result was the same: on my machine, gcc-stripped-tarball-5.5.0.drv builds identical output to what it built before. To be clear, using Guix 8159ce1970d91567468cf1bacac313099a009d2a on an x86_64-linux machine, I tried (yet again) the following steps: - I deleted as much as I could from the store using 'guix gc'. - I explicitly verified that all outputs for the following derivations no longer existed in the store: /gnu/store/pygln3lr6qbxcps3kmn3w4bc0d0nlpd3-gcc-stripped-tarball-5.5.0.drv /gnu/store/kcv3ja1rfr93hw6ly51878zjhdwpgv7z-gcc-stripped-5.5.0.drv /gnu/store/m9hfwppla8lph0vxa15lfkp81s2bbjjs-gcc-static-5.5.0.drv /gnu/store/g9fpkg2qa27mka1znqsvx8vxqyabsj2y-gcc-7.5.0.drv - I then built gcc-stripped-tarball-5.5.0.drv via the following command: guix build --no-substitutes --check --target=powerpc64-linux-gnu \ -e '(@@ (gnu packages make-bootstrap) %gcc-static)' This rebuilt basically everything, including gcc-7.5.0.drv and the other derivations mentioned above. When I checked the built output of the gcc-stripped-tarball-5.5.0.drv derivation, I found that its SHA-512 hash was identical to the one I calculated previously, which was: --8<---cut here---start->8--- 8aca7f332a1ba8e3c2225c161a7545b0a04ddd690d164dc97afee9c9ea067b0c49bc155e9f06d285c22e24cdd16d91e59730af5f1dd9efcda13a26bede5948a2 /gnu/store/rsmhiyplmbiqm1qwniiafi4ak76pd61v-gcc-stripped-tarball-5.5.0/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz --8<---cut here---end--->8--- Anyway, this confirms what we already knew: GCC builds reproducibly on my machine, but it is different when other people build it on other machines. I'm now quite convinced of this fact. Jack and Vincent shared their build results on the email list. For reference, you can get them here: https://flashner.co.il/~efraim/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz https://jackhill.us/misc/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz https://media.marusich.info/gcc-stripped-5.5.0-powerpc64-linux-gnu.tar.xz I also received a copy of Vincent's build results via private email. In short, they all seem to differ in basically the same ways: --8<---cut here---start->8--- [1] marusich@garuda-lan:~/Documents/notes/guix/ppc/gcc-stripped-tarballs $ diff -r chris jack Binary files chris/bin/c++ and jack/bin/c++ differ Binary files chris/bin/cpp and jack/bin/cpp differ Binary files chris/bin/g++ and jack/bin/g++ differ Binary files chris/bin/gcc and jack/bin/gcc differ Binary files chris/bin/gcov and jack/bin/gcov differ Binary files chris/bin/gcov-dump and jack/bin/gcov-dump differ Binary files chris/bin/gcov-tool and jack/bin/gcov-tool differ Binary files chris/bin/powerpc64-linux-gnu-c++ and jack/bin/powerpc64-linux-gnu-c++ differ Binary files chris/bin/powerpc64-linux-gnu-g++ and jack/bin/powerpc64-linux-gnu-g++ differ Binary files chris/bin/powerpc64-linux-gnu-gcc and jack/bin/powerpc64-linux-gnu-gcc differ Binary files chris/bin/powerpc64-linux-gnu-gcc-5.5.0 and jack/bin/powerpc64-linux-gnu-gcc-5.5.0 differ Binary files chris/lib/libstdc++.a and jack/lib/libstdc++.a differ Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1 and jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1 differ Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1plus and jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/cc1plus differ Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/collect2 and jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/collect2 differ Binary files chris/libexec/gcc/powerpc64-linux-gnu/5.5.0/lto-wrapper and jack/libexec/gcc/powerpc64-linux-gnu/5.5.0/lto-wrapper differ [1] marusich@garuda-lan:~/Documents/notes/guix/ppc/gcc-stripped-tarballs $ diff -r chris vincent Binary files chris/bin/c++ and vincent/bin/c++ differ Binary files chris/bin/cpp and vincent/bin/cpp differ Binary files chris/bin/g++ and vincent/bin/g++ differ Binary files chris/bin/gcc and vincent/bin/gcc differ Binary files chris/bin/gcov and vincent/bin/gcov differ Binary files chris/bin/gcov-dump and vincent/b
bug#36757: AMD-Vi IOMMU bug, kernel crashes using GuixSD 1.0.1
Romulasry, romula...@protonmail.com, via web 写道： It is a amdgpu firmware bug, We've had some trouble booting with the non-free AMDGPU graphics cards before, but the ‘AMD-Vi IOMMU’ part is new to me. What exactly happens? Which error messages (if any) do you get (pictures are fine, but please compress them to a few 100k or host them elsewhere)? will guixsd ever support it? We can certainly try, if we know what (kernel CONFIG_ option, kernel command-line option, …) is required. Since you seem to know more about the bug, could you explain it in more detail of provide a link to more information? Thanks, T G-R signature.asc Description: PGP signature
bug#41780: UEFI bios not supported out of the box when burning to usb stick
Welcome, Romulasry, romulasry via Bug reports for GNU Guix 写道： This would be a nice feature to have in the future when all there will be is UEFI (bioses). UEFI is already supported. Is this the latest Guix version (1.1.0)? What kind of machine did you try it on, and which error (if any) did you get? Does the same installer boot and run fine when booted in CSM (‘legacy’) mode? Could you try a different model of USB drive (this once ‘solved’ it for me)? Kind regards, T G-R signature.asc Description: PGP signature
bug#41780: UEFI bios not supported out of the box when burning to usb stick
This would be a nice feature to have in the future when all there will be is UEFI (bioses). Sent with [ProtonMail](https://protonmail.com) Secure Email.
bug#36757: AMD-Vi IOMMU bug, kernel crashes using GuixSD 1.0.1
It is a amdgpu firmware bug, will guixsd ever support it?
bug#41743: gst123
Tobias Geerinckx-Rice writes: > Kyle, > > Kyle Andrews 写道： >> I tried adding all the gst packages I could think of to the >> environment, >> but it still did not work. Here is what I ran: >> >> guix environment gst-plugins-base gst-plugins-bad gst-plugins-good >> gst-plugins-ugly gst123 -- gst123 "/path/to/music-file.mp3" > > Use ‘guix environment --ad-hoc’. The command above doesn't add any of > the packages to the environment, only their build dependencies. > > I forgot about gst-plugins-base, maybe it suffices. > > Kind regards, > > T G-R Thanks for the tip. Unfortunately, I still see the error: Error: Your GStreamer installation is missing a plug-in. => file cannot be played and will be removed from playlist after running: guix environment --ad-hoc gst-plugins-base gst-plugins-good gst-plugins-bad gst-plugins-ugly gst123 -- gst123 ~/path/to/music-file.mp3
bug#37789: guix pull: error: You found a bug: the program
George Clemmer 写道： I assume that "guix pull w/substitutes off" is not recommended or likely to be used by others. Even if true, it's definitely supported as long your machine has enough memory & storage to do so (which, granted, is a lot). Kind regards, T G-R signature.asc Description: PGP signature
bug#37789: guix pull: error: You found a bug: the program
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#41708: "guix weather" : 504 error
zimoun writes:
> By default, "guix weather" returns:
>
> --8<---cut here---start->8---
> 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
> --8<---cut here---end--->8---
>
> which is not fatal but annoying. Especially, it takes time.
>
> As discussed on IRC [1], it seems that it is a bug server side.
>
> In addition, something appears similar with Bayfront, well the 4
> substitutes servers that I know returns:
>
> --8<---cut here---start->8---
> 'https://ci.guix.gnu.org/api/queue?nr=1000' returned 504 ("Gateway Time-out")
> 'https://bayfront.guix.gnu.org/api/queue?nr=1000' returned 504
> ("Gateway Time-out")
> (continuous integration information unavailable)
> 'https://guix.tobias.gr/api/queue?nr=1000' returned 410 ("Gone")
> --8<---cut here---end--->8---
Hey,
So I think I've got a patch [1] to Cuirass to "fix" this.
1: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00117.html
I expected this was due to the complicated part of the db-get-builds
query, but I think it's actually down to the simple part that fetches
all the outputs for all the builds. Fetching the outputs for a build is
slow, because at the moment, there's no index on the Outputs field, so
looking up the outputs requires reading through the whole table, and the
Outputs table can be quite large.
The performance should improve with the additional query. To see why,
you can use EXPLAIN QUERY PLAN to see what SQLite plans to do when
processing the query:
sqlite> EXPLAIN QUERY PLAN SELECT name, path FROM Outputs WHERE derivation =
'foo';
QUERY PLAN
`--SCAN TABLE Outputs
sqlite> CREATE INDEX Outputs_derivation_index ON Outputs (derivation);
sqlite> EXPLAIN QUERY PLAN SELECT name, path FROM Outputs WHERE derivation =
'foo';
QUERY PLAN
`--SEARCH TABLE Outputs USING INDEX Outputs_derivation_index (derivation=?)
I believe that searching the table using an index is going to be faster
than scanning the table, and testing locally and on bayfront suggests
this will resolve the performance issue.
signature.asc
Description: PGP signature
bug#34275: clementine-1.3.1 fails test
Thorsten Wilms writes: > It appears the issue has vanished, or ‘guix build clementine > --no-grafts --check’ is not entirely equivalent. I had to use the > later, since a recent ‘guix pull && guix package -u’ got me a > substitute for clementine. The build succeeded this way, though check > found a difference (separate report coming up). Weird, but thanks for confirming & reporting the reproducibility issue. Closing this bug! :-) signature.asc Description: PGP signature
bug#41760: ganv-1.5.4 fails at configure
Thorsten Wilms writes: > On Mon, 08 Jun 2020 20:12:54 +0200 > Marius Bakke wrote: > >> ganv was updated to 1.6.0 a while back. Do you get the same failure >> after a 'guix pull'? > > That was after ‘guix pull’. ‘ganv’ is pulled in via ‘ingen’ here. > > ``` > build of > /gnu/store/bxz04gap29dxsmjvb3z4hjdid9l1fil7-ganv-1.5.4-1.12f7d6b04.drv failed > View build log at > '/var/log/guix/drvs/bx/z04gap29dxsmjvb3z4hjdid9l1fil7-ganv-1.5.4-1.12f7d6b04.drv.bz2'. > substituting /gnu/store/8vgp4lv6k16ffq5zhfsjdqb2mpxa5642-aubio-0.4.9... > |guix package: error: build of > `/gnu/store/ahx77sfl5zxgs37vx1g445czp7scrqp1-ingen-0.0.0-2.cc4a4db33.drv' > failed > ``` Oh, I see. Probably the special 'ganv-devel' input of 'ingen' is obsolete with the recent 'ganv' update. Difficult to tell because there are no comments about it, but I went ahead and removed it in c178d5fa5a2cfc07f4a9ab9cadeb6218d6c6483. Let's see if anyone complains! Forgot to mention the bug report in the commit message though :-/ Thanks, Marius signature.asc Description: PGP signature
bug#41768: x265 fails to build on i686
Marius Bakke writes: > Hello, > > Since commit bec45e6ddb0fd8b8feff3c0147936e4d8f41208d, 'x265' fails to > build on i686: I worked around this in d32a3b395c4b9926316779aecec4e5e02ad571ef by removing the nasm input on i686. signature.asc Description: PGP signature
bug#41764: `make authenticate` fails to find the keyring branch
Hi, Leo Famulari skribis: > I just tried pushing for the first time since installing the new > pre-push hook that runs `make authenticate`. > > This failed with the following error: > > Git error: cannot locate remote-tracking branch 'keyring' > > However, `git branch --all` includes "remotes/origin/keyring". > > After I did `git checkout origin/keyring`, it worked. Right, since commit 512b9e2da26968ebafdd47f701edd8fc3936d3e8, you have to have a local ‘keyring’ branch. > Let's update the manual section Commit Access with the recommended way > to make this branch accessible to `make authenticate`. Maybe it should > even do it automatically? I don’t think it can do it automatically because it cannot guess what the remote is called (Tobias reported an issue earlier because “origin/keyring” was hard-coded and Tobias didn’t have an “origin” remote.) Regarding documentation, do you think it would suffice to say that one needs to have a local ‘keyring’ branch tracking upstream’s? Thanks, Ludo’.
bug#41668: Failing test: gui-installed-desktop-os-encrypted
Hey Ludo, > It’s nice, but also a bit complicated just to print stuff on the > screen. :-) You're right, I went too far :p > That’s enough to send the ‘guix system init’ output to the console, > since we use “console=ttyS0”. > > It’s a gross hack of course, but maybe we can do something along these > lines instead of setting up a pipe? Sure, I just applied a variant of your patch. Thanks, Mathieu
bug#41709: installed-os test failing
Hey, > Let’s just set the ‘locale-libcs’ field in (gnu tests) so that it > contains a single libc. WDYT? I'll see first if I can get the closure smaller by other means. I think it would be preferable to keep the tested operating-system as close as possible to the default one. >> * "openssh" is dragging "xauth" which drags some X libraries (but this >> does not account for much). > > Yes, but that’s necessary for “ssh -X”, so I think we consciously made > that choice long ago. Ok, I proposed a work around by introducing openssh-sans-x. >> * "sudo" is dragging "python" for about 100MiB. > > Comes from the Python plugin added in > 452244e670467afe0e8ccdfb9ca2980d5a3b4694. No idea what it buys us. Some python bindings to sudo API, but I moved them to a separate "python" output. > >> * "info-reader" is dragging "perl" (and is in fact the same size as >> "texinfo" because of a mistake that I introduced with >> 614a1e3fa2d731d4719f03912b1b87fb4fd309cb) for about 100MiB. > > Ah would be nice to fix and add a #:disallowed-references flag there! In fact there were a #:disallowed-references already, but its argument was also wrong so it went unnoticed. I fixed all of that on core-updates branch. > >> * The switch to non-canonical version of "glibc" and "coreutils" to fix >> system cross-compilation in dfc8ccbf5da96a67eb1cade499f0def21e7fdb02 is >> also responsible for about 100MiB. > > Yeah, that’s the price to pay. :-/ I'd like to re-introduce "canonical-packages", without breaking the system cross-compilation, by using "let-system". See: https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00093.html. >> Now, the big source of improvement could be Guix itself (278MiB without >> dependencies). > > Yep, see my recent message on this topic. :-) Yes, thanks for your first analysis :) Thanks, Mathieu
bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.
> Welcome. Yes, that’s fine. I fixed indentation, added your copyright and pushed! Thanks, Mathieu
bug#41715: The program '/gnu/store/foobar/compute-guix-derivation' failed to compute the derivation for guix
Hi,
o.ro...@posteo.net skribis:
> here is the log uploaded on mediafire:
> http://www.mediafire.com/file/ldqoi68y88rzrn9/log.bz2/file (note that
> if you can recommend another uploading service, feel free to!)
I don’t know, maybe you could run IPFS.
The log reads:
--8<---cut here---start->8---
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0x7f3d44cfee50) = 1498
close(17) = 0
read(16, "", 1) = 0
close(16) = 0
wait4(1498, [{WIFSIGNALED(s) && WTERMSIG(s) == SIGBUS}], 0, NULL) = 1498
--8<---cut here---end--->8---
… which means the ‘compute-guix-derivation’ process crashed with SIGBUS.
Could you run:
ulimit -c unlimited
guix pull
That should fail again, but this time there should be a ‘core’ file in
the current directory (or ‘core.’ followed by digits).
Then you can run:
gdb --core=./core
and at the GDB prompt, type:
thread apply all bt
Could you let me know what that returns?
Thanks,
Ludo’.
bug#41668: Failing test: gui-installed-desktop-os-encrypted
Hi, Danny Milosavljevic skribis: > my CI setup for work automatically mails me failures. > > It would be really nice to have that for guix master eventually, too. > Maybe just mail failures to guix-devel as they happen. > > I don't check https://ci.guix.gnu.org/ so often, and even when I do the jobset > names are kinda weird there, and there's too few stuff on one page--and just > in > general there's no good overview on there. I mean I can search, but a server > can just automate that and just send me the results as they happen. > > It could also automatically mail failures to the last commiters of the source > files that are relevant--but that's probably difficult to implement. Yeah, Hydra could do that on status change (success -> failure and vice versa). IRC notifications might also be nice. Or Mastodon. There’s always a risk of flood though, at which point people stop paying attention to those notifications. Thanks, Ludo’.
bug#41668: Failing test: gui-installed-desktop-os-encrypted
Hi, Mathieu Othacehe skribis: > From 18754c8c62eabb341e0f710d83ff435ef950ca8e Mon Sep 17 00:00:00 2001 > From: Mathieu Othacehe > Date: Mon, 8 Jun 2020 15:14:49 +0200 > Subject: [PATCH] installer: utils: Dump command output to syslog when testing. > > When debugging the installation tests, it can be very handy to be able to read > "run-command" output, for instance when executing "guix system init". > > Introduce a new "invoke-with-log" procedure that is able to log a command > standard and error outputs to the syslog. Use it, only when running the > installation tests, to dump "run-command" output. > > * gnu/installer/utils.scm (open-pipe-with-stderr, invoke-with-log): New > procedures, > (invoke-log-port): new variable, > (run-command): move to the end of the file and use invoke-with-log when > running the installation tests. > --- > gnu/installer/utils.scm | 164 +--- > 1 file changed, 120 insertions(+), 44 deletions(-) It’s nice, but also a bit complicated just to print stuff on the screen. :-) I found a stash with my debugging hack: diff --git a/gnu/installer/final.scm b/gnu/installer/final.scm index 869be8814b..c084123064 100644 --- a/gnu/installer/final.scm +++ b/gnu/installer/final.scm @@ -137,7 +137,13 @@ or #f. Return #t on success and #f on failure." (lambda () (start-service 'cow-store (list (%installer-target-dir (lambda () -(run-command install-command #:locale locale)) +(with-output-to-file "/dev/console" + (lambda () +(with-error-to-file "/dev/console" + (lambda () +(setvbuf (current-output-port) 'none) +(setvbuf (current-error-port) 'none) +(run-command install-command #:locale locale)) (lambda () (stop-service 'cow-store) ;; Remove the store overlay created at cow-store service start. That’s enough to send the ‘guix system init’ output to the console, since we use “console=ttyS0”. It’s a gross hack of course, but maybe we can do something along these lines instead of setting up a pipe? Thanks, Ludo’.
bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.
Thanks for rebasing :) Your copyright is missing, is this ok for you if I use: "Stefan " or would you prefer something else? Mathieu
bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.
Welcome. Yes, that’s fine. > Am 09.06.2020 um 14:24 schrieb Mathieu Othacehe : > > > Thanks for rebasing :) > > Your copyright is missing, is this ok for you if I use: > > "Stefan " > > or would you prefer something else? > > Mathieu
bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.
* gnu/bootloaders/grub.scm (eye-candy): Use gfxterm depending only on
(bootloader-configuration (terminal-outputs …)), which defaults to '(gfxterm).
This makes the system argument obsolete.
---
gnu/bootloader/grub.scm | 46 -
1 file changed, 13 insertions(+), 33 deletions(-)
diff --git a/gnu/bootloader/grub.scm b/gnu/bootloader/grub.scm
index d4dbb57131..e3b8416d6d 100644
--- a/gnu/bootloader/grub.scm
+++ b/gnu/bootloader/grub.scm
@@ -135,41 +135,25 @@ file with the resolution provided in CONFIG."
(_ #f)
(define* (eye-candy config store-device store-mount-point
-#:key store-directory-prefix system port)
+#:key store-directory-prefix port)
"Return a gexp that writes to PORT (a port-valued gexp) the 'grub.cfg' part
concerned with graphics mode, background images, colors, and all that.
STORE-DEVICE designates the device holding the store, and STORE-MOUNT-POINT is
its mount point; these are used to determine where the background image and
-fonts must be searched for. SYSTEM must be the target system string---e.g.,
-\"x86_64-linux\". STORE-DIRECTORY-PREFIX is a directory prefix to prepend to
-any store file name."
- (define setup-gfxterm-body
-(let ((gfxmode
- (or (and-let* ((theme (bootloader-configuration-theme config))
- (gfxmode (grub-theme-gfxmode theme)))
- (string-join gfxmode ";"))
- "auto")))
-
- ;; Intel and EFI systems need to be switched into graphics mode, whereas
- ;; most other modern architectures have no other mode and therefore
- ;; don't need to be switched.
-
- ;; XXX: Do we really need to restrict to x86 systems? We could imitate
- ;; what the GRUB default configuration does and decide based on whether
- ;; a user provided 'gfxterm' in the terminal-outputs field of their
- ;; bootloader-configuration record.
- (if (string-match "^(x86_64|i[3-6]86)-" system)
- (format #f "
- set gfxmode=~a
- insmod all_video
- insmod gfxterm~%" gfxmode)
- "")))
-
+fonts must be searched for. STORE-DIRECTORY-PREFIX is a directory prefix to
+prepend to any store file name."
(define (setup-gfxterm config font-file)
(if (memq 'gfxterm (bootloader-configuration-terminal-outputs config))
-#~(format #f "if loadfont ~a; then
- setup_gfxterm
-fi~%" #+font-file)
+#~(format #f "
+if loadfont ~a; then
+ set gfxmode=~a
+ insmod all_video
+ insmod gfxterm
+fi~%"
+ #$font-file
+ #$(string-join
+ (grub-theme-gfxmode (bootloader-theme config))
+ ";"))
""))
(define (theme-colors type)
@@ -190,8 +174,6 @@ fi~%" #+font-file)
(and image
#~(format #$port "
-function setup_gfxterm {~a}
-
# Set 'root' to the partition that contains /gnu/store.
~a
@@ -206,7 +188,6 @@ else
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
fi~%"
- #$setup-gfxterm-body
#$(grub-root-search store-device font-file)
#$(setup-gfxterm config font-file)
#$(grub-setup-io config)
@@ -380,7 +361,6 @@ menuentry ~s {
device
mount-point
#:store-directory-prefix store-directory-prefix
- #:system system
#:port #~port)))
(define keyboard-layout-config
--
2.26.0
bug#41775: System cross-compilation to i585-pc-gnu vs. grafts
Hello! Attempting to cross-build the system to i586-pc-gnu with grafts enabled leads to something fishy: --8<---cut here---start->8--- $ git log |head -1 commit a50628bbe0fa4ba3835e311098e4fdf7a1d8a29e $ ./pre-inst-env guix system build --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl -n The following derivations would be built: /gnu/store/3dphrw8kka8x3pj1xshc7wxv18spcp9s-tzdata-2019c.drv /gnu/store/ry0pzyhawjkjmz343dda3in2fbbaax5b-net-tools-1.60-0.479bb4a.drv /gnu/store/jwwsf3kky7qwbi0kswbqa76dk069hj4a-linux-libre-headers-cross-x86_64-linux-5.4.20.drv /gnu/store/sa56z96rixkghpf3z1rv0sqc41rfix4d-gcc-cross-sans-libc-x86_64-linux-7.5.0.drv /gnu/store/kcrrjh29qawb2yhsq41hvggbymnmy67h-glibc-cross-x86_64-linux-2.31.drv /gnu/store/lj7acjnbza54j1kv0n8imdclh70087s3-gcc-cross-x86_64-linux-7.5.0.drv 47.9 MB would be downloaded: /gnu/store/1gyikmvlmdvblg5q6j2aj1dp5dln6d0v-guix-1.1.0-9.ab9e300 /gnu/store/70qjgxkdvjsqb3q14yyam9wk8sd48azc-openldap-2.4.49 /gnu/store/w1rm6r3dmhsvqpb5biwy0hck7swij9z1-curl-7.69.1 /gnu/store/bbm5x79iqrwy0mcx6yr4hq3x5n641jya-git-minimal-2.26.2 $ guix graph --path -t derivation /gnu/store/ry0pzyhawjkjmz343dda3in2fbbaax5b-net-tools-1.60-0.479bb4a.drv /gnu/store/sa56z96rixkghpf3z1rv0sqc41rfix4d-gcc-cross-sans-libc-x86_64-linux-7.5.0.drv /gnu/store/ry0pzyhawjkjmz343dda3in2fbbaax5b-net-tools-1.60-0.479bb4a.drv /gnu/store/jwwsf3kky7qwbi0kswbqa76dk069hj4a-linux-libre-headers-cross-x86_64-linux-5.4.20.drv /gnu/store/sa56z96rixkghpf3z1rv0sqc41rfix4d-gcc-cross-sans-libc-x86_64-linux-7.5.0.drv --8<---cut here---end--->8--- The “x86_64-linux” cross-toolchain look very bogus. It disappears when adding ‘--no-grafts’. Ludo’.
bug#41668: Failing test: gui-installed-desktop-os-encrypted
Hey, > Instead I did reimplement the command in (gnu installer utils) in the > attached patch :). There were an issue with exception handling, here's a v2. Note that it uses the &invoke-error constructor that should be made public I guess. Thanks, Mathieu >From 18754c8c62eabb341e0f710d83ff435ef950ca8e Mon Sep 17 00:00:00 2001 From: Mathieu Othacehe Date: Mon, 8 Jun 2020 15:14:49 +0200 Subject: [PATCH] installer: utils: Dump command output to syslog when testing. When debugging the installation tests, it can be very handy to be able to read "run-command" output, for instance when executing "guix system init". Introduce a new "invoke-with-log" procedure that is able to log a command standard and error outputs to the syslog. Use it, only when running the installation tests, to dump "run-command" output. * gnu/installer/utils.scm (open-pipe-with-stderr, invoke-with-log): New procedures, (invoke-log-port): new variable, (run-command): move to the end of the file and use invoke-with-log when running the installation tests. --- gnu/installer/utils.scm | 164 +--- 1 file changed, 120 insertions(+), 44 deletions(-) diff --git a/gnu/installer/utils.scm b/gnu/installer/utils.scm index 5f8fe8ca01..68b3dd5009 100644 --- a/gnu/installer/utils.scm +++ b/gnu/installer/utils.scm @@ -22,8 +22,13 @@ #:use-module (guix build utils) #:use-module (guix i18n) #:use-module (srfi srfi-1) + #:use-module (srfi srfi-11) + #:use-module (srfi srfi-26) #:use-module (srfi srfi-34) + #:use-module (srfi srfi-34) + #:use-module (srfi srfi-35) #:use-module (ice-9 match) + #:use-module (ice-9 popen) #:use-module (ice-9 rdelim) #:use-module (ice-9 regex) #:use-module (ice-9 format) @@ -68,50 +73,6 @@ number. If no percentage is found, return #f" (and result (string->number (match:substring result 1) -(define* (run-command command #:key locale) - "Run COMMAND, a list of strings, in the given LOCALE. Return true if -COMMAND exited successfully, #f otherwise." - (define env (environ)) - - (define (pause) -(format #t (G_ "Press Enter to continue.~%")) -(send-to-clients '(pause)) -(environ env) ;restore environment variables -(match (select (cons (current-input-port) (current-clients)) - '() '()) - (((port _ ...) _ _) - (read-line port - - (setenv "PATH" "/run/current-system/profile/bin") - - (when locale -(let ((supported? (false-if-exception - (setlocale LC_ALL locale - ;; If LOCALE is not supported, then set LANGUAGE, which might at - ;; least give us translated messages. - (if supported? - (setenv "LC_ALL" locale) - (setenv "LANGUAGE" - (string-take locale - (or (string-index locale #\_) - (string-length locale))) - - (guard (c ((invoke-error? c) - (newline) - (format (current-error-port) - (G_ "Command failed with exit code ~a.~%") - (invoke-error-exit-status c)) - (syslog "command ~s failed with exit code ~a" - command (invoke-error-exit-status c)) - (pause) - #f)) -(syslog "running command ~s~%" command) -(apply invoke command) -(syslog "command ~s succeeded~%" command) -(newline) -(pause) -#t)) - ;;; ;;; Logging. @@ -219,3 +180,118 @@ accepting socket." (current-clients (reverse remainder)) exp) + + +;;; +;;; Run commands. +;;; + +;; XXX: This is taken from (guix build utils) and could be factorized. +(define (open-pipe-with-stderr program . args) + "Run PROGRAM with ARGS in an input pipe, but, unlike 'open-pipe*', redirect +both its standard output and standard error to the pipe. Return two value: +the pipe to read PROGRAM's data from, and the PID of the child process running +PROGRAM." + ;; 'open-pipe*' doesn't attempt to capture stderr in any way, which is why + ;; we need to roll our own. + (match (pipe) +((input . output) + (match (primitive-fork) + (0 +(dynamic-wind + (const #t) + (lambda () +(close-port input) +(close-port (syslog-port)) +(dup2 (fileno output) 1) +(dup2 (fileno output) 2) +(apply execlp program program args)) + (lambda () +(primitive-exit 127 + (pid +(close-port output) +(values input pid)) + +(define invoke-log-port + ;; Port used by INVOKE-WITH-LOG for logging. + (make-parameter #f)) + +(define* (invoke-with-log program . args) + "Invoke PROGRAM with ARGS and log PROGRAM's standard output and standard +error to INVOKE-LOG-PORT. If PROGRAM succeeds, print nothing and return the +unspecified value; otherwise, raise a '&message' error condition with the +status code. This procedure is
bug#41774: Clementine may not be deterministic
Since I had to cause a local build despite having a substitute, I used ‘guix build clementine --no-grafts --check’, which reported: guix build: error: derivation `/gnu/store/003z966hxvb6hs17sjq4fcwshcqvafxa-clementine-1.3.1-2.4619a4c.drv' may not be deterministic: output `/gnu/store/2vpsjrx7q7wx9715cpc2y1vg5xy7hbfw-clementine-1.3.1-2.4619a4c' differs ‘guix challenge clementine’ reports it to be identical, “because it's just looking at the substitute you downloaded”, as Ludovic said on IRC. -- Thorsten Wilms
bug#41702: `guix environment` performance issues
Hey, > That’s over SSH, right? correct, the worst possible case: Inside two VM’s on a Laptop, SSH transport between them and /gnu+/var/guix on an NFS share (nfsd is in the same VM as guix-daemon). > Probably what’s killing us is the round-trip time for all these small > RPCs. We would need pipelining but the RPC protocol is not designed to > make that easy. That would have been my best guess too, but it does not seem to be the biggest problem right now. Looking at the numbers again (both patches applied) with the attached manifest[1], I see that: ---snip--- Local UNIX socket with and without --no-grafts: N Min MaxMedian AvgStddev x 10 6.07 6.35 6.145 6.160.08232726 + 10 17.47 17.8917.54517.6020.14351152 Difference at 99.0% confidence 11.442 +/- 0.150576 185.747% +/- 4.07133% Local UNIX socket vs. guix://localhost transport: N Min MaxMedian AvgStddev x 10 17.47 17.8917.54517.6020.14351152 + 10 17.43 18.1 17.6117.6420.20131788 No difference proven at 99.0% confidence Local UNIX socket vs ssh://localhost transport: N Min MaxMedian AvgStddev x 10 17.47 17.8917.54517.6020.14351152 + 10 33.46 35.2734.31534.3590.53873205 Difference at 99.0% confidence 16.757 +/- 0.5074 95.1994% +/- 3.13957% ---snap--- So I would conclude: 1) Grafting still takes a lot of time and needs more work 2) Linux optimizes localhost networking pretty well 3) Our SSH transport is terribly slow Moving to non-localhost communication between two VM’s: ---snip--- guix://localhost vs. guix://remote-host transport: N Min MaxMedian AvgStddev x 10 17.43 18.1 17.6117.6420.20131788 + 10 20.88 22.5821.09521.2220.49689704 Difference at 99.0% confidence 3.58 +/- 0.487934 20.2925% +/- 2.85159% guix://remote-host vs. ssh://remote-host: N Min MaxMedian AvgStddev x 10 20.88 22.5821.09521.2220.49689704 + 10 30.1 32.5631.00531.0930.70740606 Difference at 99.0% confidence 9.871 +/- 0.786769 46.5131% +/- 4.35326% ---snap--- Conclusion here is the same: Not alot of impact of networking/NFS and SSH transport is still terribly slow. (Confusingly faster than localhost though.) > Perhaps you could “strace -Tt” the thing to check whether this > hypothesis is correct by looking at the time we spend waiting for > replies? I’m not sure this will yield meaningful data for SSH, so I analyzet it for guix://localhost vs. guix://remote-host. Takeaway is, yes, of course there is a statistically significant difference and it’s about 40%±50%, which means this method is pretty useless, because we can’t bin RPC’s by type. So, I guess it would make sense for me to look at the SSH transport itself again and see if there are any other low-hanging fruit. Not sure how much I can help with profiling guile/guix itself. A different/better RPC protocol is probably GSoC/v2.0-worthy? Sorry for all the lengthy emails, Lars [1] You’ll need this channel: https://github.com/leibniz-psychology/guix-zpid (specifications->manifest '( "coreutils" "findutils" "procps" "strace" "openssh" "mit-krb5" "bash" "which" "zip" "geeqie" "util-linux" "grep" "glibc" ;; for locales "glibc-locales" ;; front-end software "jupyter-zpid" "python-jupyterlab" ;; available notebook kernel ; provided by jupyter-zpid ;"python-ipykernel" "r-irkernel" "rstudio-server-zpid" "r" ;; for RMarkdown "r-knitr" "r-yaml" "r-markdown" "r-rmarkdown" "texlive" ;; commonly used r packages "r-psych" "r-ggplot2" "r-lattice" "r-foreign" "r-readr" "r-haven" "r-dplyr" "r-tidyr" "r-stringr" "r-forecast" "r-lme4" "r-nlme" "r-nnet" "r-glmnet" "r-caret" "r-xmisc" "r-splitstackshape" "r-tm" "r-quanteda" "r-topicmodels" "r-stm" ;;"r-parallel" "r-dt" "r-nlp" "r-data-table" "r-hmisc" "r-learnr" "r-metafor" ;; for rmarkdown "ghc-pandoc" )) signature.asc Description: PGP signature
bug#41746: [PATCH] gnu: grub: Support graphical gfxterm on all systems.
Hey Stefan, > * gnu/bootloaders/grub.scm (eye-candy): Use gfxterm depending only on > (bootloader-configuration (terminal-outputs …)), which defaults to '(gfxterm). > This makes the system argument obsolete. This looks good, however due to recent changes in this file (multiboot support), it doesn't apply well. Could you please rebase it and send and updated version? Thanks, Mathieu
bug#34275: clementine-1.3.1 fails test
It appears the issue has vanished, or ‘guix build clementine --no-grafts --check’ is not entirely equivalent. I had to use the later, since a recent ‘guix pull && guix package -u’ got me a substitute for clementine. The build succeeded this way, though check found a difference (separate report coming up).
bug#34275: clementine-1.3.1 fails test
On Mon, 08 Jun 2020 20:19:25 +0200 Marius Bakke wrote: > What architecture are you on, and what does 'guix describe' say? x86_64, Intel Core 2 Duo ~: guix describe Generation 122 Jun 09 2020 09:05:51(current) guix 2356713 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 23567138f842136f83f318b5915457af882ca38a GUIX_PACKAGE_PATH="/media/hd/devel/guix/packages" -- Thorsten Wilms
bug#41760: ganv-1.5.4 fails at configure
On Mon, 08 Jun 2020 20:12:54 +0200 Marius Bakke wrote: > ganv was updated to 1.6.0 a while back. Do you get the same failure > after a 'guix pull'? That was after ‘guix pull’. ‘ganv’ is pulled in via ‘ingen’ here. ``` build of /gnu/store/bxz04gap29dxsmjvb3z4hjdid9l1fil7-ganv-1.5.4-1.12f7d6b04.drv failed View build log at '/var/log/guix/drvs/bx/z04gap29dxsmjvb3z4hjdid9l1fil7-ganv-1.5.4-1.12f7d6b04.drv.bz2'. substituting /gnu/store/8vgp4lv6k16ffq5zhfsjdqb2mpxa5642-aubio-0.4.9... |guix package: error: build of `/gnu/store/ahx77sfl5zxgs37vx1g445czp7scrqp1-ingen-0.0.0-2.cc4a4db33.drv' failed ```
bug#22883: [bug#41767] [PATCH 0/9] Authenticate channels
Ludovic Courtès skribis: > This patch series does it! It integrates checkout authentication > with (guix channels). Now, ‘guix pull’, ‘guix time-machine’ etc. > automatically authenticate the commits they fetch and raise an > error if they find an unsigned commit or a commit signed by an > unauthorized party¹. [...] > ¹ https://issues.guix.gnu.org/issue/22883#64 Something we didn’t discuss is that this model forbids a merge-request kind of workflow, or at least the person who merges must sign the commits, rewriting the merged branch. I think it’s a reasonable tradeoff in this space, but it’s worth keeping in mind. Ludo’.
