bug#33647: First `guix pull' behaves unexpectedly

[Diego Nicola Barbato]

Hello,

Ludovic Courtès  writes:

> Hello,
>
> Ricardo Wurmus  skribis:
>
>>> Hello Guix,
>>>
>>> The first time a user runs ‘guix pull’ after a fresh install it does not
>>> seem to update guix.  ‘guix --version’ reports that guix is still
>>> version 0.15.0 after running ‘guix pull’, instead of showing the hash of
>>> the latest commit.
>>
>> “guix pull” should have reminded you to add ~/.config/guix/current/bin
>> to the front of your PATH environment variable.  When you do that you
>> will be using the new version of Guix.

I forgot to mention that this is on GuixSD, where
~/.config/guix/currend/bin is already in PATH, which maybe explains why
I did not get a reminder.

> In addition, be aware that Bash maintains a cache of commands it looked
> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
> invalidate its cache thus you kept using that old version.
>
> The solution is to run “hash guix” at the Bash prompt to force cache
> invalidation (info "(bash) Bourne Shell Builtins").

I believe this is it.  This also explains why ‘which guix’ returned the
updated guix while ‘guix --version’ claimed it was still the older
version, which I found rather confusing.
I am afraid being unaware of this has led me to inadvertently downgrade
GuixSD whenever I reconfigured for the first time after a fresh install.

Thanks!

Diego

bug#33647: First `guix pull' behaves unexpectedly

[Björn Höfling]

On Fri, 07 Dec 2018 09:36:31 +0100
Diego Nicola Barbato  wrote:

> I believe this is it.  This also explains why ‘which guix’ returned
> the updated guix while ‘guix --version’ claimed it was still the older
> version, which I found rather confusing.
> I am afraid being unaware of this has led me to inadvertently
> downgrade GuixSD whenever I reconfigured for the first time after a
> fresh install.

OK, then I'm closing this issue.

Björn


pgpyOBYRUdQbA.pgp
Description: OpenPGP digital signature

bug#33623: Backtrace when running `guix system roll-back'

[Diego Nicola Barbato]

Diego Nicola Barbato  writes:

> Hello Swedebugia,
>
> swedebu...@riseup.net writes:
>
>> On 2018-12-05 12:36, Diego Nicola Barbato wrote:
>>> Hello Guix,
>>> 
>>> When I run ‘guix system roll-back’ I get the following backtrace:
>>> 
>>> --8<---cut here---start->8---
>>> root@tapuakh ~# guix system roll-back
>>> Backtrace:
>>>   10 (primitive-load "/root/.config/guix/current/bin/guix")
>>> In guix/ui.scm:
>>>   1603:12  9 (run-guix-command _ . _)
>>> In ice-9/boot-9.scm:
>>> 829:9  8 (catch srfi-34 # …)
>>> 829:9  7 (catch system-error # …)
>>> In guix/scripts/system.scm:
>>>1268:8  6 (_)
>>> In guix/status.scm:
>>> 615:4  5 (call-with-status-report _ _)
>>> In guix/scripts/system.scm:
>>>1208:9  4 (process-command _ _ _)
>>>469:10  3 (switch-to-system-generation # …)
>>> In guix/store.scm:
>>>   1659:24  2 (run-with-store _ _ #:guile-for-build _ #:system _ # _)
>>> In guix/scripts/system.scm:
>>> 499:6  1 (_ _)
>>> In unknown file:
>>>0 (_ #)
>>> 
>>> ERROR: Wrong type to apply: #< name: "grub.cfg" gexp:
>>> # guile: #f options: (#:local-build? #t)>
>>> --8<---cut here---end--->8---
>>> 
>>> I run GuixSD (commit: 1f51f0d975d95a2ba645193cf43d0a294d952e83) on an
>>> x86_64 machine.
>>
>> Interesting. Could you provide a config.scm to help us reproduce the
>> issue?
>
> I've got something better.
>
> Steps to reproduce:
>
> Install GuixSD in a VM using the iso image and the attached config.  The
> image should be at least 16G (8G is to small for a reconfigure).
>
> Reboot the VM.
>
> Run ‘guix pull --commit=1f51f0’ as root.
>
> Make sure to log out and back in again to avoid bug#33647.
>
> Run ‘guix system reconfigure /etc/config.scm’.
>
> Reboot the VM.
>
> Run ‘guix system roll-back’ as root.
>
> Backtrace ensues.

I just repeated the aforementioned steps with the new (0.16.0) iso image
and by pulling from current master (5118e2) instead of 1f51f0 and got a
similar backtrace.  I believe ‘guix system roll-back’ is currently
broken on master.
Judging from the backtrace this might have something to do with the
recent clean up of system code (specifically commit 46c296).

Greetings

Diego

bug#33659: Perl-build-system does not honor #:module-build-flags or #:configure-flags

[swedebugia]

Hi

I'm trying hard to package perl-term-readline-gnu but have failed so
far. :D

See the attached patch for my addition to perl-build-system that did not
help.

The Makefile in the source says:

# Usage: perl Makefile.PL [--prefix=...] [--includedir=...]
[--libdir=...]   
#   [OPTIMIZE=...] 

The build failure (with or without my modifications to the build-system)
is:

starting phase `configure'
running `perl' with arguments ("Makefile.PL"
"PREFIX=/gnu/store/w4wb4wd1kjj6gmxlix0i3jj47v0izijh-perl-term-readline-gnu-1.35"
"INSTALLDIRS=site" "NO_PERLLOCAL=1")
Could not find neither libtermcap.a, libncurses.a, or libcurses.
Backtrace:
   4 (primitive-load "/gnu/store/vgfkdlnwks28vk50mg0xjl8iaf9…")
In ice-9/eval.scm:
   191:35  3 (_ _)
In srfi/srfi-1.scm:
640:9  2 (for-each # …)
In
/gnu/store/wy2ja4vrrnakwhabsn87ngsb3bqqm5fx-module-import/guix/build/gnu-build-system.scm:
   799:31  1 (_ _)
In
/gnu/store/wy2ja4vrrnakwhabsn87ngsb3bqqm5fx-module-import/guix/build/utils.scm:
616:6  0 (invoke _ . _)

/gnu/store/wy2ja4vrrnakwhabsn87ngsb3bqqm5fx-module-import/guix/build/utils.scm:616:6:
In procedure invoke:
Throw to key `srfi-34' with args `(#)'.
note: keeping build directory
`/tmp/guix-build-perl-term-readline-gnu-1.35.drv-17'
builder for
`/gnu/store/n6dcbwrfag9klwysrfdkj2j05cr9710i-perl-term-readline-gnu-1.35.drv'
failed with exit code 1
build of
/gnu/store/n6dcbwrfag9klwysrfdkj2j05cr9710i-perl-term-readline-gnu-1.35.drv
failed
View build log at
'/var/log/guix/drvs/n6/dcbwrfag9klwysrfdkj2j05cr9710i-perl-term-readline-gnu-1.35.drv.bz2'.
cannot build derivation
`/gnu/store/pz0zrnpsvip0yxyd18cjazibsrlpf29h-youtube-viewer-cli-3.4.1.drv':
1 dependencies couldn't be built
guix build: error: build failed: build of
`/gnu/store/pz0zrnpsvip0yxyd18cjazibsrlpf29h-youtube-viewer-cli-3.4.1.drv'
failed


-- 
Cheers 
SwedebugiaFrom 2afd42c1631793fc5c186b82fbdbb3964f6ae464 Mon Sep 17 00:00:00 2001
From: swedebugia 
Date: Fri, 7 Dec 2018 12:14:37 +0100
Subject: [PATCH] gnu: Add perl-term-readline-gnu -- flags not honored

---
 gnu/packages/perl.scm  | 37 -
 guix/build-system/perl.scm |  3 ++-
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/perl.scm b/gnu/packages/perl.scm
index cbdf070e8..d41182962 100644
--- a/gnu/packages/perl.scm
+++ b/gnu/packages/perl.scm
@@ -51,7 +51,8 @@
   #:use-module (gnu packages freedesktop)
   #:use-module (gnu packages perl-check)
   #:use-module (gnu packages perl-web)
-  #:use-module (gnu packages pkg-config))
+  #:use-module (gnu packages pkg-config)
+  #:use-module (gnu packages readline))
 
 ;;;
 ;;; Please: Try to add new module packages in alphabetic order.
@@ -8115,6 +8116,40 @@ other terminal related features, including retrieval/modification of the
 screen size, and retrieval/modification of the control characters.")
 (license (package-license perl
 
+(define-public perl-term-readline-gnu
+  (package
+   (name "perl-term-readline-gnu")
+   (version "1.35")
+   (source
+(origin
+  (method url-fetch)
+  (uri (string-append
+"mirror://cpan/authors/id/H/HA/HAYASHI/Term-ReadLine-Gnu-"
+version
+".tar.gz"))
+  (sha256
+   (base32
+"09cixf93w9y443jj291viw3r292xskihx3af65pnbkb7mga34pap"
+   (build-system perl-build-system)
+   (arguments
+'(#:configure-flags '("--test"
+ ;;(string-append "-libdir=" (getenv
+;;"LIBRARY_PATH"))
+  )
+  #:module-build-flags '("--test"
+ ;;(string-append "-libdir=" (getenv
+;;"LIBRARY_PATH"))
+ )))
+   (native-inputs
+`(("perl-module-build" ,perl-module-build)
+  ("readline" ,readline)))
+   (home-page
+"https://metacpan.org/release/Term-ReadLine-Gnu";)
+   (synopsis
+"Perl extension for the GNU Readline/History Library")
+   (description "This module enables support for the GNU Readline/History Library.")
+   (license perl-license)))
+
 (define-public perl-term-size-any
   (package
 (name "perl-term-size-any")
diff --git a/guix/build-system/perl.scm b/guix/build-system/perl.scm
index 06af1dd20..a06cf5b44 100644
--- a/guix/build-system/perl.scm
+++ b/guix/build-system/perl.scm
@@ -78,6 +78,7 @@
 
 (define* (perl-build store name inputs
  #:key
+ (configure-flags ''())
  (search-paths '())
  (tests? #t)
  (parallel-build? #t)
@@ -111,6 +112,7 @@ provides a `Makefile.PL' file as its build system."
#:make-maker? ,make-maker?
#:make-maker-flags ,make-maker-flags
#:module-build-flags ,module-build-flags
+   #:configure-flags ,configure-flags
#:phases ,phases

bug#33647: First `guix pull' behaves unexpectedly

[Ludovic Courtès]

Hi,

Diego Nicola Barbato  skribis:

> Ludovic Courtès  writes:

[...]

>> In addition, be aware that Bash maintains a cache of commands it looked
>> up in $PATH.  Thus it may be that, say, it had cached that ‘guix’ is
>> really /run/current-system/profile/bin/guix.  When you pulled, it didn’t
>> invalidate its cache thus you kept using that old version.
>>
>> The solution is to run “hash guix” at the Bash prompt to force cache
>> invalidation (info "(bash) Bourne Shell Builtins").
>
> I believe this is it.  This also explains why ‘which guix’ returned the
> updated guix while ‘guix --version’ claimed it was still the older
> version, which I found rather confusing.
> I am afraid being unaware of this has led me to inadvertently downgrade
> GuixSD whenever I reconfigured for the first time after a fresh install.

Yeah.  This is not strictly speaking a Guix bug, but clearly it’s a
common pitfall.  Perhaps we should print a hint upon completion?

Ludo’.

bug#33623: Backtrace when running `guix system roll-back'

[Ludovic Courtès]

Hi Diego,

Diego Nicola Barbato  skribis:

> When I run ‘guix system roll-back’ I get the following backtrace:

Fixed in commit 6ddc63e599a26c302f74d0622f67cfd987f0dc5f, thanks!

Ludo'.

bug#33661: A recent Guix pull failed

[Joshua Branson]

Hello,

I'm tried looking to see if someone else was experiencing this bug, but
I couldn't find a easy way to search the guix bug database, so I'm sorry
if I am making a duplicate bug report.

Anyway, I'm using a Macbook 7,1.  guix version reports this:

guix (GNU Guix) 17cfb7aeffaaba70e67e9afb50d7100614ffca7f
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


And guix pull shows this:

Updating channel 'my-personal-packages' from Git repository at 
'https://notabug.org/jbranso/guix-packages.git'...
Updating channel 'guix' from Git repository at 
'https://git.savannah.gnu.org/git/guix.git'...
Building from these channels:
  my-personal-packageshttps://notabug.org/jbranso/guix-packages.git a6784b7
  guix  https://git.savannah.gnu.org/git/guix.git   6ddc63e
;;; compiling 
/gnu/store/nnawlikz0n644rh05p9fyggq30qk5lis-my-personal-packages/share/guile/site/2.2/myemacs.scm
;;; compiled 
/home/joshua/.cache/guile/ccache/2.2-LE-8-3.A/gnu/store/xgd83571ijj6karrs8sykk0f5i4kqa39-guix-packages-862909a/myemacs.scm.go
guix pull: warning: failed to load '(myemacs)':
no code for module (myemacs)
Computing Guix derivation for 'x86_64-linux'... -@ build-started 
/gnu/store/4s6w1cz1srv9vh1bj5wim71sr4v8y22a-guix-0.16.0-2.5227d93-checkout.drv 
- x86_64-linux 
/var/log/guix/drvs/4s//6w1cz1srv9vh1bj5wim71sr4v8y22a-guix-0.16.0-2.5227d93-checkout.drv.bz2
environment variable `PATH' set to 
`/gnu/store/q09sy224qnxrp982z4xfaxi19721mjx8-gzip-1.9/bin:/gnu/store/ipx79bfj2mrc8npj7s3qi3zri11jfhaw-tar-1.30/bin'
Initialized empty Git repository in 
/gnu/store/yj0ly310dvzc4bxbvpa9d44wx93r7jql-guix-0.16.0-2.5227d93-checkout/.git/
\error: Server does not allow request for unadvertised object 
5227d938e2b7bda22e2a7aa733e1e09a6c726f18
Failed to do a shallow fetch; retrying a full fetch...
\From https://git.savannah.gnu.org/r/guix
 * [new branch]  core-updates-next   -> origin/core-updates-next
 * [new branch]  guile-daemon-> origin/guile-daemon
 * [new branch]  imagemagick-updates -> origin/imagemagick-updates
 * [new branch]  master  -> origin/master
 * [new branch]  nix -> origin/nix
 * [new branch]  python-updates  -> origin/python-updates
 * [new branch]  qt-updates  -> origin/qt-updates
 * [new branch]  reproduce-bug-29774 -> origin/reproduce-bug-29774
 * [new branch]  rhel6   -> origin/rhel6
 * [new branch]  staging -> origin/staging
 * [new branch]  version-0.10.0  -> origin/version-0.10.0
 * [new branch]  version-0.11.0  -> origin/version-0.11.0
 * [new branch]  version-0.12.0  -> origin/version-0.12.0
 * [new branch]  version-0.13.0  -> origin/version-0.13.0
 * [new branch]  version-0.14.0  -> origin/version-0.14.0
 * [new branch]  version-0.15.0  -> origin/version-0.15.0
 * [new branch]  version-0.16.0  -> origin/version-0.16.0
 * [new branch]  version-0.8.3   -> origin/version-0.8.3
 * [new branch]  version-0.9.0   -> origin/version-0.9.0
 * [new branch]  wip-bootstrap   -> origin/wip-bootstrap
 * [new branch]  wip-build-systems-gexp  -> origin/wip-build-systems-gexp
 * [new branch]  wip-check   -> origin/wip-check
 * [new branch]  wip-container   -> origin/wip-container
 * [new branch]  wip-deploy  -> origin/wip-deploy
 * [new branch]  wip-gcc7-> origin/wip-gcc7
 * [new branch]  wip-gexp-grafts -> origin/wip-gexp-grafts
 * [new branch]  wip-gexp-hygiene-> origin/wip-gexp-hygiene
 * [new branch]  wip-git-https   -> origin/wip-git-https
 * [new branch]  wip-gnome-upgrades  -> origin/wip-gnome-upgrades
 * [new branch]  wip-grafts  -> origin/wip-grafts
 * [new branch]  wip-haskell -> origin/wip-haskell
 * [new branch]  wip-hurd-> origin/wip-hurd
 * [new branch]  wip-installer   -> origin/wip-installer
 * [new branch]  wip-installer-2 -> origin/wip-installer-2
 * [new branch]  wip-ipfs-> origin/wip-ipfs
 * [new branch]  wip-ipfs2   -> origin/wip-ipfs2
 * [new branch]  wip-kde-frameworks-update -> 
origin/wip-kde-frameworks-update
 * [new branch]  wip-loongson2f  -> origin/wip-loongson2f
 * [new branch]  wip-mediagoblin -> origin/wip-mediagoblin
 * [new branch]  wip-newt-installer  -> origin/wip-newt-installer
 * [new branch]  wip-next-browser-> origin/wip-next-browser
 * [new branch]  wip-next-browser2   -> origin/wip-next-browser2
 * [new branch]  wip-next-browser3   -> origin/wip-next-browser3
 

bug#33661: A recent Guix pull failed

[Joshua Branson]

cat .config/guix/channels.scm

;; Add my personal packages to those Guix provides.
(cons (channel
   (name 'my-personal-packages)
   (url "https://notabug.org/jbranso/guix-packages.git";))
  %default-channels)

My channel is probably not correct.  I'm not certain if I am specifying
packages correctly.

Thanks,

Joshua

bug#33656: Hard locks on boot (uefi system) via usb

[Ricardo Wurmus]

Hi Ryan,

> I used sudo dd if=guixsd-install-0.16.0.x86_64-linux.iso of=/dev/sdb to
> make the usb work in uefi mode

What errors do you get (if any)?

-- 
Ricardo

bug#33661: A recent Guix pull failed

[Ricardo Wurmus]

Hi Joshua,

there was a bug with commit 6eac835f178c0c78637b0db8a4585a617b2f7622,
which has already been fixed in commit
23a1f738b1ef83c3dcb329e1c68617b0452e6a07.

Please try again.

--
Ricardo

bug#33666: spacefm fails to build

[Bradley Haggerty]

guix (GNU Guix) 5118e26f83cc2b4ec835df56bee2a4003c1325b9
building /gnu/store/k993nvk595hqsrcfj4ymvmcj3w9fbfv3-spacefm-1.0.6.drv...
builder for `/gnu/store/k993nvk595hqsrcfj4ymvmcj3w9fbfv3-spacefm-1.0.6.drv'
failed with exit code
1
build of /gnu/store/k993nvk595hqsrcfj4ymvmcj3w9fbfv3-spacefm-1.0.6.drv
failed
View build log at
'/var/log/guix/drvs/k9/93nvk595hqsrcfj4ymvmcj3w9fbfv3-spacefm-1.0.6.drv.bz2'.

guix package: error: build failed: build of
`/gnu/store/k993nvk595hqsrcfj4ymvmcj3w9fbfv3-spacefm-1.0.6.drv'
failed

from build log:
main.c:189:42: error: implicit declaration of function ‘major’
[-Werror=implicit-function-declaration]
  major( stat_buf.st_dev ),
  ^
main.c:190:42: error: implicit declaration of function ‘minor’
[-Werror=implicit-function-declaration]
  minor( stat_buf.st_dev ),
  ^
/gnu/store/gfprsx2m62cvqbh7ysc9ay9slhijvmal-module-import/guix/build/utils.scm:616:6:
In procedure invoke:
Throw to key `srfi-34' with args `(#)'.

bug#33623: Backtrace when running `guix system roll-back'

[znavko]

Hello! This is just an idea.
Is it possible to automatize detection of this kind of problems? 
As I see, some PC can has crontab job to do `guix pull`, so that if 'Backtrace' 
message occurs, it sends a report to developer not to rush up to push his 
branch to master branch.
Different branches can be defended from such a minor issues, just trying `guix 
pull` for all branches using channels. 


Dec 7, 2018, 2:15 PM by l...@gnu.org:

> Hi Diego,
>
> Diego Nicola Barbato <> dnbarb...@posteo.de > > 
> skribis:
>
>> When I run ‘guix system roll-back’ I get the following backtrace:
>>
>
> Fixed in commit 6ddc63e599a26c302f74d0622f67cfd987f0dc5f, thanks!
>
> Ludo'.
>

bug#33667: Ingen fails to build

[Thorsten Wilms]

...
phase `patch-usr-bin-file' succeeded after 0.0 seconds
starting phase `patch-source-shebangs'
patch-shebang: ./scripts/ingen.py: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./scripts/ingenams: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./scripts/ingenish: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./src/client/wscript: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./src/gui/wscript: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./src/ingen/ingen.grind: changing `/usr/bin/env sh' to
`/gnu/store/q19l04vd2za80mk1845pz7r8cz29qk43-bash-minimal-4.4.23/bin/sh'
patch-shebang: ./src/server/wscript: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./src/wscript: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./waf: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
patch-shebang: ./wscript: changing `/usr/bin/env python' to
`/gnu/store/r68bi4640vm0s7zsgyk7shsag8ibl3nc-python-wrapper-3.7.0/bin/python'
phase `patch-source-shebangs' succeeded after 0.1 seconds
starting phase `configure'
running "python waf" with command "configure" and parameters
("--prefix=/gnu/store/wzg2ih9wplilr7fwc6bzlv2s6sxxdyxx-ingen-0.0.0-2.cc4a4db33"
"--no-webkit")
Traceback (most recent call last):
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Node.py",
line 312, in ant_iter
raise StopIteration
StopIteration

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Scripting.py",
line 114, in waf_entry_point
run_commands()
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Scripting.py",
line 171, in run_commands
parse_options()
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Scripting.py",
line 144, in parse_options
Context.create_context('options').execute()
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Options.py",
line 146, in execute
super(OptionsContext,self).execute()
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Context.py",
line 93, in execute
self.recurse([os.path.dirname(g_module.root_path)])
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Context.py",
line 134, in recurse
user_function(self)
  File "/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/wscript",
line 19, in options
opt.load('compiler_cxx')
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Context.py",
line 90, in load
fun(self)
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Tools/compiler_cxx.py",
line 36, in options
opt.load_special_tools('cxx_*.py')
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Context.py",
line 321, in load_special_tools

lst=self.root.find_node(waf_dir).find_node('waflib/extras').ant_glob(var)
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Node.py",
line 361, in ant_glob
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
  File
"/tmp/guix-build-ingen-0.0.0-2.cc4a4db33.drv-0/source/.waf3-1.8.22-cd01c337ef788738c16f5e03aaddf994/waflib/Node.py",
line 361, in 
ret=[x for x in
self.ant_iter(accept=accept,pats=[to_pat(incl),to_pat(excl)],maxdepth=kw.get('maxdepth',25),dir=dir,src=src,remove=kw.get('remove',True))]
RuntimeError: generator raised StopIteration
Backtrace:
   5 (primitive-load "/gnu/store/3rvl42cz9qxk6rzcps0lwpmalp3?")
In ice-9/eval.scm:
   191:35  4 (_ _)
In srfi/srfi-1.scm:
   863:16  3 (every1 # ?)
In
/gnu/store/s3nazihm99q8f3h431c3193mvqph1q6z-module-import/guix/build/gnu-build-system.scm:
   799:28  2 (_ _)
In
/gnu/store/s3nazihm99q8f3h431c3193mvqph1q6z-module-import/guix/build/waf-build-system.scm:
 41:9  1 (call-waf _ _)
In
/gnu/store/

bug#33623: Backtrace when running `guix system roll-back'

[Ludovic Courtès]

Hello,

 skribis:

> Is it possible to automatize detection of this kind of problems? 
> As I see, some PC can has crontab job to do `guix pull`, so that if 
> 'Backtrace' message occurs, it sends a report to developer not to rush up to 
> push his branch to master branch.

There are lots of unit tests and system tests in Guix.  Unfortunately
this particular bit is not covered by a test.  We would need to come up
with a testing strategy for this but it can be quite challenging.

Ludo’.

bug#33639: ISO installer image is broken on i686

[Ludovic Courtès]

Hello!

"Thomas Schmitt"  skribis:

>> Based on this and on a suggestion Ricardo made on IRC, I passed
>> “-padding 10m” and that solved the problem.  \o/
>
> Ouchers. Do all files bear their expected content ?
> Especially the last one: /var/guix/db/db.sqlite

It looks good, and there are no I/O errors left (I mounted it and run
“tar” over it.)

Note that the image is now available here:

  https://alpha.gnu.org/gnu/guix/guixsd-install-0.16.0.i686-linux.iso.xz

(I haven’t tried smaller padding.)

> If so, then something truncates the output stream of libisofs via libburn.
> The only component that comes to my mind is the fifo between them.
> The default fifo size is 4 MiB. Quite suspicious.
>
> Try to reduce its size to the minimum by adding these grub-mkrescue
> arguments:
>
>   -- -- -fs 64k -padding 64k
>
> If the fifo is to blame, then a padding of 64k should suffice to protect
> the valuable blocks from a premature end.

OK, I’ll try to test this, but note that I’ll be largely unavailable for
a week.

>> the documentation of “-padding” suggests
>> that this kind of problem is not uncommon.
>
> It's normal purpose is to work around a traditional Linux kernel bug:
>
> CDs written with write type Track-At-Once bear two unreadable blocks at
> the end. Most CD drives report these blocks as part of the data range.
> When Linux shall read a single block for isofs, it reads a larger chunk.
> The chunk is not large enough to reach over the nominal end of the data
> range, but it can reach the unreadable end blocks by mistake.
> In this case Linux does not only miss the end blocks but also valid
> payload blocks which are part of the filesystem. This yields I/O error.
>
> The developer of cdrecord and the kernel people mistake this problem
> for a "fuzziness" of a CD end by at most 2 seconds of audio play time.
> This is wrong from reading the specs and from making experiments.
> However, cdrecord introduced the tradition to add 150 blocks of padding
> which would 2 seconds of sound.
> As long as the read chunk of Linux is smaller than that, the padding
> protects the operating system from touching the lead-out blocks of the
> TAO track.
>
> This cannot happen on hard disk or any optical media type other than CD.
> If you write the CD by Session-At-Once it cannot happen. If you have one
> of the rare CD drives which do not count the lead-out blocks to the
> readable size of the CD, it cannot happen. (Currently 1 of my 7 drives
> tells the truth.)
>
> But who am i to stand against all others ?
> So xorriso, too, adds 300 KiB of padding by default.

I see, thanks for explaining!

Ludo’.

bug#33610: [PATCH] gnu: Add a C++14 variant of Boost for packages that need it.

[Leo Famulari]

Pushed as b9103c827c605dee32baf62816a0429543b3e451


signature.asc
Description: PGP signature

bug#33542: Strange tarball download error on Hydra

[Mark H Weaver]

reopen 33542
retitle 33542 Offloading to older Guix fails for lack of (guix base16)
thanks

Hi Ludovic,

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

> Mark H Weaver  skribis:
>
>> Mark H Weaver  writes:
>>
>>> On Hydra, the armhf builds for al variants of 'linux-libre-4.14.84'
>>> failed because the tarball download failed.  See below for the build
>>> log.  Strangely, it was unable to find the (guix base16) module.
>>
>> I now see that 89f1fee8e788fc32d08583b4207c1ecb91d50f28 added a new use
>> of (guix base16) during downloads, and that the copies of Guix currently
>> running on the armhf build slaves is too old to include (guix base16).
>
> Oops indeed.  Commit a52ae1b6620fcef28e668047a51a6b2a9fb89e35 addresses
> it by autoloading (guix base16), such that old installations will still
> work but won’t be able to download from Software Heritage.

The autoload workaround introduced in commit a52ae1b6 didn't to work.
Downloads on these armhf slaves are still failing in recent evaluations.
For example, see the build log below, for a version of linux-libre that
did not exist when commit a52ae1b6 was pushed.

I tried upgrading 'guix' on the armhf build slaves, but after doing so
*all* builds offloaded to those machines started aborting.  The nix logs
on Hydra indicate that the (guix) module could not be found.  For now, I
rolled back the upgrades, so this issue is still relevant.

Thanks,
  Mark


--8<---cut here---start->8---
@ build-started 
/gnu/store/m74cjfkak0h54jss4043nwpydr90w6i0-linux-libre-4.14.86-gnu.tar.xz.drv 
- armhf-linux 
/var/log/guix/drvs/m7//4cjfkak0h54jss4043nwpydr90w6i0-linux-libre-4.14.86-gnu.tar.xz.drv.bz2
;;; Failed to autoload bytevector->base16-string in (guix base16):
;;; ERROR: missing interface for module (guix base16)
Backtrace:
In ice-9/boot-9.scm:
  66: 19 [call-with-prompt prompt0 ...]
In ice-9/eval.scm:
 432: 18 [eval # #]
In ice-9/boot-9.scm:
2404: 17 [save-module-excursion #]
4056: 16 [#]
1727: 15 [%start-stack load-stack #]
1732: 14 [#]
In unknown file:
   ?: 13 [primitive-load 
"/gnu/store/hkzbag401s8pkrj6k4bjizy3dybqffp4-guix-0.12.0-2.b291/bin/.guix-real"]
In guix/ui.scm:
1222: 12 [run-guix-command perform-download ...]
In ice-9/boot-9.scm:
 160: 11 [catch srfi-34 # ...]
 160: 10 [catch system-error ...]
In guix/scripts/perform-download.scm:
  63: 9 [perform-download #]
In guix/build/download.scm:
 837: 8 [url-fetch # ...]
In srfi/srfi-1.scm:
 643: 7 [append-map # ...]
 573: 6 [map # #]
 661: 5 [filter-map # #]
In guix/build/download.scm:
 841: 4 [# #]
In ice-9/eval.scm:
 387: 3 [eval # #]
 386: 2 [eval # #]
 393: 1 [eval # #]
In unknown file:
   ?: 0 [memoize-variable-access! # #]

ERROR: In procedure memoize-variable-access!:
ERROR: Unbound variable: bytevector->base16-string
builder for 
`/gnu/store/m74cjfkak0h54jss4043nwpydr90w6i0-linux-libre-4.14.86-gnu.tar.xz.drv'
 failed with exit code 1
@ build-failed 
/gnu/store/m74cjfkak0h54jss4043nwpydr90w6i0-linux-libre-4.14.86-gnu.tar.xz.drv 
- 1 builder for 
`/gnu/store/m74cjfkak0h54jss4043nwpydr90w6i0-linux-libre-4.14.86-gnu.tar.xz.drv'
 failed with exit code 1
--8<---cut here---end--->8---

bug#33656: Hard locks on boot (uefi system) via usb

[Ryan Bach]

Nothing it just gets stuck at initializing amdfbpudrb (or something
similar):.

On Fri, Dec 7, 2018 at 7:46 AM Ricardo Wurmus  wrote:

>
> Hi Ryan,
>
> > I used sudo dd if=guixsd-install-0.16.0.x86_64-linux.iso of=/dev/sdb to
> > make the usb work in uefi mode
>
> What errors do you get (if any)?
>
> --
> Ricardo
>
>