bug#29537: Core updates broken

[Gábor Boskovits]

 8dd35a0e2 is good


2017-12-02 21:12 GMT+01:00 Gábor Boskovits :

> It seems, that we have a breakage in current core-updates. m4, gettext,
> and at least a few other packages fail to build.
>
> We had a discussion about that on irc, here are the important points:
>
> [09:34:53]  * g_bor
> has joined #guix
> [09:34:58]   Hello
> guix!
> [09:37:37]   I
> just tried to build something no core-updates and m4 and python-boot0 does
> not build, I get a message that a decoding error occured in exception
> dispatcher. It seem like it's locale related, I'm on hu_HU.UTF-8
> [09:38:03]   I'm
> tring this now on master to see if the problem persists.
> [09:38:10]   
> Anyone
> seen that?
> [16:46:05]   
> mb[m]1:
> you were right about the failing installation tests
> [16:46:16]   it
> did work a couple of days ago though, so there's hope
> [16:47:16]   
> civodul:
> Any idea what caused it? Haven't been paying attention lately.
> [16:47:24]  *
> kristofer has joined #guix
> [16:53:03]   
> mb[m]1:
> no idea yet, let's see
> [16:54:11]   I
> don't understand why core-updates is failing. I've bisected glibc down to
> the first two commits on the 2.26 branch, and also tried reverting the
> libatomic-ops update.
> [16:54:35]   
> how's
> it failing?
> [16:54:41]   
> well
> maybe i should focus on one thing at a time :-)
> [16:54:46]   So
> the culprit is likely one of these: https://sourceware.org/
> git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
> 
>  and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=
> dc258ce62ae0bbb45...
> 
> [16:55:27]  *
> jonsger has joined #guix
> [16:55:31]   
> civodul:
> "m4" and a few others fail like this: https://paste.debian.net/998765/
> [16:55:36]   
> you'll
> find yourself being a libc hacker without noticing
> [16:55:41]  
> Hehe.
> [16:56:24]   in
> this case it's the 'configure' file that leads to a decoding error
> [16:56:28]   
> could
> you check its encoding?
>
> [16:57:52]   I
> don't currently have the files. But I had built much further before the
> glibc update (with the C++ fixes only).
> [16:57:56]  *
> jonsger has joined #guix
> [17:00:55]   I
> unpacked the m4 source and ran `file` on it:
> [17:00:57]   
> configure:
> POSIX shell script, UTF-8 Unicode text executable
> [17:01:24]   so
> it could be an issue with iconv in the new libc
> [17:06:59]  *
> ryanwatkins has joined #guix
> [17:11:08]  
> hello!
> [17:11:18]   
> Anyone
> seen this?
> [17:11:30]   It's
> on core-updates:
> [17:11:51]   
> starting
> phase `patch-usr-bin-file' Backtrace: 16 (primitive-load 
> "/gnu/store/4jf0jcpvjn6r2warav5xmxhmddf?")
> In ice-9/eval.scm: 191:35 15 (_ _) In srfi/srfi-1.scm: 863:16 14 (every1
> # ?) In /gnu/store/
> yifqwmdxc4pmdpm73diq03lqkprnrizn-module-import/guix/build/gnu-build-system.scm:
> 711:27 13 (_ _) 171:4 12 (patch-usr-bin-file #:native-inputs _ #:inputs _ #
> _) In srfi/srfi
> [17:13:38]   
> g_bor:
> mb[m]1 was just reporting the exact same issue :-)
> [17:13:45]   
> g_bor:
> Yes, I'm currently trying to track it down.
> [17:14:36]   I've
> a

bug#29537: Core updates broken

[Gábor Boskovits]

ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a is the first bad commit.

2017-12-03 9:41 GMT+01:00 Gábor Boskovits :

>  8dd35a0e2 is good
>
>
> 2017-12-02 21:12 GMT+01:00 Gábor Boskovits :
>
>> It seems, that we have a breakage in current core-updates. m4, gettext,
>> and at least a few other packages fail to build.
>>
>> We had a discussion about that on irc, here are the important points:
>>
>> [09:34:53]  * g_bor
>> has joined #guix
>> [09:34:58]   
>> Hello
>> guix!
>> [09:37:37]   I
>> just tried to build something no core-updates and m4 and python-boot0 does
>> not build, I get a message that a decoding error occured in exception
>> dispatcher. It seem like it's locale related, I'm on hu_HU.UTF-8
>> [09:38:03]   I'm
>> tring this now on master to see if the problem persists.
>> [09:38:10]   
>> Anyone
>> seen that?
>> [16:46:05] 
>>  mb[m]1: you were right about the failing installation tests
>> [16:46:16] 
>>  it did work a couple of days ago though, so there's hope
>> [16:47:16]   
>> civodul:
>> Any idea what caused it? Haven't been paying attention lately.
>> [16:47:24]  *
>> kristofer has joined #guix
>> [16:53:03] 
>>  mb[m]1: no idea yet, let's see
>> [16:54:11]   I
>> don't understand why core-updates is failing. I've bisected glibc down to
>> the first two commits on the 2.26 branch, and also tried reverting the
>> libatomic-ops update.
>> [16:54:35] 
>>  how's it failing?
>> [16:54:41] 
>>  well maybe i should focus on one thing at a time :-)
>> [16:54:46]   So
>> the culprit is likely one of these: https://sourceware.org/
>> git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
>> 
>>  and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce6
>> 2ae0bbb45...
>> 
>> [16:55:27]  *
>> jonsger has joined #guix
>> [16:55:31]   
>> civodul:
>> "m4" and a few others fail like this: https://paste.debian.net/998765/
>> [16:55:36] 
>>  you'll find yourself being a libc hacker without noticing
>> [16:55:41]  
>> Hehe.
>> [16:56:24] 
>>  in this case it's the 'configure' file that leads to a
>> decoding error
>> [16:56:28] 
>>  could you check its encoding?
>>
>> [16:57:52]   I
>> don't currently have the files. But I had built much further before the
>> glibc update (with the C++ fixes only).
>> [16:57:56]  *
>> jonsger has joined #guix
>> [17:00:55]   I
>> unpacked the m4 source and ran `file` on it:
>> [17:00:57]   
>> configure:
>> POSIX shell script, UTF-8 Unicode text executable
>> [17:01:24] 
>>  so it could be an issue with iconv in the new libc
>> [17:06:59]  *
>> ryanwatkins has joined #guix
>> [17:11:08]  
>> hello!
>> [17:11:18]   
>> Anyone
>> seen this?
>> [17:11:30]   It's
>> on core-updates:
>> [17:11:51]   
>> starting
>> phase `patch-usr-bin-file' Backtrace: 16 (primitive-load
>> "/gnu/store/4jf0jcpvjn6r2warav5xmxhmddf?") In ice-9/eval.scm: 191:35 15
>> (_ _) In srfi/srfi-1.scm: 863:16 14 (every1 #> /gnu/store/yifqwmdxc4pmd?> ?) In /gnu/store/yifqwmdxc4pmdpm73di
>> q03lqkprnrizn-module-import/guix/build/gnu-build-system.scm: 711:27 13
>> (_ _) 171:4 12 (patch-usr-bin-file #:native-inputs _ #:inputs _ # _) In
>> srfi/srfi
>> [17:13:38] 
>>  g_bor: mb[m]1 was just reporting the ex

bug#29537: Core updates broken

[Gábor Boskovits]

Reverting ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a works. I'm sure it is
not optimal, but for now I will go with it.


2017-12-03 9:45 GMT+01:00 Gábor Boskovits :

> ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a is the first bad commit.
>
> 2017-12-03 9:41 GMT+01:00 Gábor Boskovits :
>
>>  8dd35a0e2 is good
>>
>>
>> 2017-12-02 21:12 GMT+01:00 Gábor Boskovits :
>>
>>> It seems, that we have a breakage in current core-updates. m4, gettext,
>>> and at least a few other packages fail to build.
>>>
>>> We had a discussion about that on irc, here are the important points:
>>>
>>> [09:34:53]  *
>>> g_bor has joined #guix
>>> [09:34:58]   
>>> Hello
>>> guix!
>>> [09:37:37]   I
>>> just tried to build something no core-updates and m4 and python-boot0 does
>>> not build, I get a message that a decoding error occured in exception
>>> dispatcher. It seem like it's locale related, I'm on hu_HU.UTF-8
>>> [09:38:03]   I'm
>>> tring this now on master to see if the problem persists.
>>> [09:38:10]   
>>> Anyone
>>> seen that?
>>> [16:46:05] 
>>>  mb[m]1: you were right about the failing installation tests
>>> [16:46:16] 
>>>  it did work a couple of days ago though, so there's hope
>>> [16:47:16] 
>>>  civodul: Any idea what caused it? Haven't been paying
>>> attention lately.
>>> [16:47:24]  *
>>> kristofer has joined #guix
>>> [16:53:03] 
>>>  mb[m]1: no idea yet, let's see
>>> [16:54:11] 
>>>  I don't understand why core-updates is failing. I've bisected
>>> glibc down to the first two commits on the 2.26 branch, and also tried
>>> reverting the libatomic-ops update.
>>> [16:54:35] 
>>>  how's it failing?
>>> [16:54:41] 
>>>  well maybe i should focus on one thing at a time :-)
>>> [16:54:46] 
>>>  So the culprit is likely one of these: https://sourceware.org/
>>> git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
>>> 
>>>  and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce6
>>> 2ae0bbb45...
>>> 
>>> [16:55:27]  *
>>> jonsger has joined #guix
>>> [16:55:31] 
>>>  civodul: "m4" and a few others fail like this:
>>> https://paste.debian.net/998765/
>>> [16:55:36] 
>>>  you'll find yourself being a libc hacker without noticing
>>> [16:55:41] 
>>>  Hehe.
>>> [16:56:24] 
>>>  in this case it's the 'configure' file that leads to a
>>> decoding error
>>> [16:56:28] 
>>>  could you check its encoding?
>>>
>>> [16:57:52] 
>>>  I don't currently have the files. But I had built much further
>>> before the glibc update (with the C++ fixes only).
>>> [16:57:56]  *
>>> jonsger has joined #guix
>>> [17:00:55] 
>>>  I unpacked the m4 source and ran `file` on it:
>>> [17:00:57] 
>>>  configure: POSIX shell script, UTF-8 Unicode text executable
>>> [17:01:24] 
>>>  so it could be an issue with iconv in the new libc
>>> [17:06:59]  *
>>> ryanwatkins has joined #guix
>>> [17:11:08]  
>>> hello!
>>> [17:11:18]   
>>> Anyone
>>> seen this?
>>> [17:11:30]   
>>> It's
>>> on core-updates:
>>> [17:11:51]   
>>> starting
>>> phase `patch-usr-bin-file' Backtrace: 16 (primitive-load
>>> "/gnu/store/4jf0jcpvjn6r2warav5xmxhmddf?") In ice-9/eval.scm: 191:35 15
>>> (_ _) In srfi/srfi-1.scm: 863:16 14 (every1 #>> /gnu/store/yifqwmdxc4pmd?> ?) In /gnu/store/yifqwmdxc4pmdpm73di
>>> q03lqkprn

bug#29546: Intermittent test failures in 'git'

[Mark H Weaver]

On Hydra, the following intermittent test failure in 'git' has occurred
twice in the last two days, and twice about a month ago:

--8<---cut here---start->8---
not ok 3 - git svn branch tests
#   
#   test_must_fail git svn branch a &&
#   git svn branch --parents a &&
#   test_must_fail git svn branch -t tag1 &&
#   git svn branch --parents -t tag1 &&
#   test_must_fail git svn branch --tag tag2 &&
#   git svn branch --parents --tag tag2 &&
#   test_must_fail git svn tag tag3 &&
#   git svn tag --parents tag3
#   
# failed 1 among 3 test(s)
1..3
make[2]: *** [Makefile:49: t9167-git-svn-cmd-branch-subproject.sh] Error 1
--8<---cut here---end--->8---

The problem is not architecture specific.  It has occurred at least once
on all three hydra-supported-systems (x86_64, i686, and armhf).  The
collateral damage includes several hundred dependency failures.

The following error also happened once on x86_64 about a month ago:

--8<---cut here---start->8---
not ok 3 - git svn branch tests
#   
#   git svn branch a &&
#   base=$(git rev-parse HEAD:) &&
#   test $base = $(git rev-parse remotes/origin/a:) &&
#   git svn branch -m "created branch b blah" b &&
#   test $base = $(git rev-parse remotes/origin/b:) &&
#   test_must_fail git branch -m "no branchname" &&
#   git svn branch -n c &&
#   test_must_fail git rev-parse remotes/origin/c &&
#   test_must_fail git svn branch a &&
#   git svn branch -t tag1 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag1:) &&
#   git svn branch --tag tag2 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag2:) &&
#   git svn tag tag3 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag3:) &&
#   git svn tag -m "created tag4 foo" tag4 &&
#   test $base = $(git rev-parse remotes/origin/tags/tag4:) &&
#   test_must_fail git svn tag -m "no tagname" &&
#   git svn tag -n tag5 &&
#   test_must_fail git rev-parse remotes/origin/tags/tag5 &&
#   test_must_fail git svn tag tag1
#

[...]

# failed 1 among 4 test(s)
1..4
make[2]: *** [Makefile:49: t9128-git-svn-cmd-branch.sh] Error 1
--8<---cut here---end--->8---

  Mark

bug#29537: Core updates broken

[Marius Bakke]

Gábor Boskovits  writes:

> It seems, that we have a breakage in current core-updates. m4, gettext, and
> at least a few other packages fail to build.

Hello!

The problem is that the glibc version string is used a couple of places
to determine where locales are found.

The attached patch fixes it, though I'm not sure if it's the best
approach.  Thoughts?

From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
From: Marius Bakke 
Date: Sun, 3 Dec 2017 02:32:16 +0100
Subject: [PATCH] gnu: glibc: Don't use full version string in locale path.

This is a follow-up to commit ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a.
Fixes .

* gnu/packages/base.scm (glibc/linux)[version]: Change to 2.26.91-gaaa2eb83b8.
[source](uri): Adjust accordingly.
[arguments]: Use VERSION-MAJOR+MINOR for locales path.
(glibc-locales, glibc-utf8-locales): Likewise.
* guix/profiles.scm (ca-certificate-bundle, profile-derivation): Likewise.
---
 gnu/packages/base.scm | 15 ++-
 guix/profiles.scm |  6 --
 2 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
index c8fd8624a..8190a38ed 100644
--- a/gnu/packages/base.scm
+++ b/gnu/packages/base.scm
@@ -523,11 +523,15 @@ store.")
;; archive can be generated by checking out the commit ID and running:
;; git archive --prefix=$(git describe)/ HEAD | xz -9 > $(git describe).tar.xz
;; See  for details.
-   (version "2.26-91-gaaa2eb83b8")
+   ;;
+   ;; Note: Always use a dot after the minor version since various places rely
+   ;; on "version-major+minor" to determine where locales are found.
+   (version "2.26.91-gaaa2eb83b8")
(source (origin
 (method url-fetch)
 (uri (string-append "https://alpha.gnu.org/gnu/guix/mirror/";
-"glibc-" version ".tar.xz"))
+"glibc-" (version-major+minor version) "-"
+(caddr (string-split version #\.)) ".tar.xz"))
 (sha256
  (base32
   "1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk"))
@@ -585,7 +589,7 @@ store.")
 ;; `--localedir' is not honored, so work around it.
 ;; See .
 (string-append "libc_cv_complocaledir=/run/current-system/locale/"
-   ,version)
+   ,(version-major+minor version))
 
 (string-append "--with-headers="
(assoc-ref ,(if (%current-target-system)
@@ -955,7 +959,8 @@ the 'share/locale' sub-directory of this package.")
(list (string-append "libc_cv_complocaledir="
 (assoc-ref %outputs "out")
 "/lib/locale/"
-,(package-version glibc))
+,(version-major+minor
+  (package-version glibc)))
 
 (define-public glibc-utf8-locales
   (package
@@ -973,7 +978,7 @@ the 'share/locale' sub-directory of this package.")
   (gzip  (assoc-ref %build-inputs "gzip"))
   (out   (assoc-ref %outputs "out"))
   (localedir (string-append out "/lib/locale/"
-,version)))
+,(version-major+minor version
  ;; 'localedef' needs 'gzip'.
  (setenv "PATH" (string-append libc "/bin:" gzip "/bin"))
 
diff --git a/guix/profiles.scm b/guix/profiles.scm
index 0eb99f40d..51c330b32 100644
--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -812,7 +812,8 @@ MANIFEST.  Single-file bundles are required by programs such as Git and Lynx."
   ;; install a UTF-8 locale.
   (setenv "LOCPATH"
   (string-append #+glibc-utf8-locales "/lib/locale/"
- #+(package-version glibc-utf8-locales)))
+ #+(version-major+minor
+(package-version glibc-utf8-locales
   (setlocale LC_ALL "en_US.utf8")
 
   (match (append-map ca-files '#$(manifest-inputs manifest))
@@ -1256,7 +1257,8 @@ are cross-built for TARGET."
   #~(begin
   (setenv "LOCPATH"
   #$(file-append glibc-utf8-locales "/lib/locale/"
- (package-version glibc-utf8-locales)))
+ (version-major+minor
+  (package-version glibc-utf8-locales
   (setlocale LC_ALL "en_US.utf8")))
 
 (define builder
-- 
2.15.1



signature.asc
Description: PGP signature

bug#28034: elixir build fails

[nee]

Hello, thank you for the fast and detailed reply.
I made two patches that upgrade erlang and elixir and disable the
failing tests in elixir, and got it to build again.


I sometimes get this undeterministic compile error (see the attached
log). It's always the same error, but it doesn't appear every time, so I
can get a passing build running:

`until ./pre-inst-env guix build elixir; do sleep 1; done`

I don't think that it is related to the version upgrade because I also
got this with the old versions when I first tried to build it today.


While this still not good, it is at least an improvement over the
current state where the package will fail to install in 100% of cases.
From fda40d470fab9ceb58c0e42e59db766eaf840730 Mon Sep 17 00:00:00 2001
From: nee 
Date: Sun, 3 Dec 2017 15:37:28 +0100
Subject: [PATCH 1/2] gnu: erlang: Update to 20.1.

* gnu/packages/erlang.scm (erlang): Update to 20.1.
---
 gnu/packages/erlang.scm | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gnu/packages/erlang.scm b/gnu/packages/erlang.scm
index 1a575a0fd..770ed715b 100644
--- a/gnu/packages/erlang.scm
+++ b/gnu/packages/erlang.scm
@@ -35,7 +35,7 @@
 (define-public erlang
   (package
 (name "erlang")
-(version "20.0")
+(version "20.1")
 (source (origin
   (method url-fetch)
   ;; The tarball from http://erlang.org/download contains many
@@ -46,7 +46,7 @@
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32
-"11xp6vv1v7iay9dg1xc6xm7izfsanbn5pgwp96ba0j1fmlkhjw92"))
+"0r4g8ag7nlpw06y4c39fgcyccykj2sbyhv5jgp4qmrjci2ydgns8"))
   (patches (search-patches "erlang-man-path.patch"
 (build-system gnu-build-system)
 (native-inputs
@@ -62,7 +62,7 @@
version ".tar.gz"))
(sha256
 (base32
- "1k25p37w1l1j20qd8rga4j4q7s7r0rbsi02x3xwzhw51jhm59wdp"))
+ "0ikvdpn4z7az6szg176l1r2yxhgs3msa3wgb3gmy45jkz0pzik05"))
 (inputs
  `(("ncurses" ,ncurses)
("openssl" ,openssl)
-- 
2.14.1

From 3fe3e538a098eb1c0e8fee4d99231c720282db53 Mon Sep 17 00:00:00 2001
From: nee 
Date: Sun, 3 Dec 2017 15:39:40 +0100
Subject: [PATCH 2/2] gnu: elixir: Update to 1.5.2 and disable failing tests.

* gnu/packages/elixir.scm (elixir)[origin]: Update to 1.5.2.
[arguments]: Patch the shebang of mix. Disable failing tests.
---
 gnu/packages/elixir.scm | 33 +++--
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/gnu/packages/elixir.scm b/gnu/packages/elixir.scm
index 7425b49a4..c630b635e 100644
--- a/gnu/packages/elixir.scm
+++ b/gnu/packages/elixir.scm
@@ -30,7 +30,7 @@
 (define-public elixir
   (package
 (name "elixir")
-(version "1.4.2")
+(version "1.5.2")
 (source (origin
   (method url-fetch)
   (uri (string-append "https://github.com/elixir-lang/elixir";
@@ -38,7 +38,7 @@
   (file-name (string-append name "-" version ".tar.gz"))
   (sha256
(base32
-"0gsmgx4h6rvxilcbsx2z6yirm6g2g5bsxdvr0608ng4bsv22wknb"))
+"0v7z0avs3gir7qdfgysfw88l3z9p5f7p7pjnrnsz5gmmsflvf5vk"))
   ;; FIXME: 27 tests (out of 4K) had to be disabled as
   ;; they fail in the build environment.  Common failures
   ;; are:
@@ -55,14 +55,18 @@
#:phases
(modify-phases %standard-phases
  (add-after 'unpack 'replace-paths
-   (lambda* (#:key inputs #:allow-other-keys)
- (substitute* '("lib/elixir/lib/system.ex"
-"lib/mix/lib/mix/scm/git.ex")
-   (("(cmd\\(['\"])git" _ prefix)
-(string-append prefix (which "git"
- (substitute* "bin/elixir"
-   (("ERL_EXEC=\"erl\"")
-(string-append "ERL_EXEC=" (which "erl"
+   (lambda* (#:key inputs outputs #:allow-other-keys)
+ (let ((out (assoc-ref outputs "out")))
+   (substitute* '("lib/elixir/lib/system.ex"
+  "lib/mix/lib/mix/scm/git.ex")
+ (("(cmd\\(['\"])git" _ prefix)
+  (string-append prefix (which "git"
+   (substitute* "bin/elixir"
+ (("ERL_EXEC=\"erl\"")
+  (string-append "ERL_EXEC=" (which "erl"
+   (substitute* "bin/mix"
+ (("#!/usr/bin/env elixir")
+  (string-append "#!" out "/bin/elixir"
  #t))
  (add-after 'unpack 'fix-or-disable-tests
(lambda* (#:key inputs #:allow-other-keys)
@@ -75,6 +79,15 @@
 
  ;; FIXME: Mix.Shell.cmd() always fails with error code 130.
  (delete-file "lib/mix/test/mix/shell_test.exs")
+
+ ;; FIXME:
+ ;; disabled failing impure tests to make it build again.
+  

bug#29537: Core updates broken

[Marius Bakke]

Marius Bakke  writes:

> Gábor Boskovits  writes:
>
>> It seems, that we have a breakage in current core-updates. m4, gettext, and
>> at least a few other packages fail to build.
>
> Hello!
>
> The problem is that the glibc version string is used a couple of places
> to determine where locales are found.
>
> The attached patch fixes it, though I'm not sure if it's the best
> approach.  Thoughts?

Actually, the patch below is not a complete fix.  It worked for m4, but
some other packages now fail like this:

--8<---cut here---start->8---

@ build-started 
/gnu/store/q0fadqzsg969jz8v11r9j2a07x3h2sl4-perl-5.26.1.tar.xz.drv - 
x86_64-linux 
/var/log/guix/drvs/q0//fadqzsg969jz8v11r9j2a07x3h2sl4-perl-5.26.1.tar.xz.drv.bz2
Backtrace:
   2 (primitive-load "/gnu/store/xjb3g9spv30arffi1296qwdaam4?")
In ice-9/eval.scm:
619:8  1 (_ #f)
In unknown file:
   0 (setlocale 6 "en_US.utf8")

ERROR: In procedure setlocale:
ERROR: In procedure setlocale: Invalid argument
builder for 
`/gnu/store/q0fadqzsg969jz8v11r9j2a07x3h2sl4-perl-5.26.1.tar.xz.drv' failed 
with exit code 1
--8<---cut here---end--->8---

Not sure where it's from yet.

>
> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Sun, 3 Dec 2017 02:32:16 +0100
> Subject: [PATCH] gnu: glibc: Don't use full version string in locale path.
>
> This is a follow-up to commit ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a.
> Fixes .
>
> * gnu/packages/base.scm (glibc/linux)[version]: Change to 2.26.91-gaaa2eb83b8.
> [source](uri): Adjust accordingly.
> [arguments]: Use VERSION-MAJOR+MINOR for locales path.
> (glibc-locales, glibc-utf8-locales): Likewise.
> * guix/profiles.scm (ca-certificate-bundle, profile-derivation): Likewise.
> ---
>  gnu/packages/base.scm | 15 ++-
>  guix/profiles.scm |  6 --
>  2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/gnu/packages/base.scm b/gnu/packages/base.scm
> index c8fd8624a..8190a38ed 100644
> --- a/gnu/packages/base.scm
> +++ b/gnu/packages/base.scm
> @@ -523,11 +523,15 @@ store.")
> ;; archive can be generated by checking out the commit ID and running:
> ;; git archive --prefix=$(git describe)/ HEAD | xz -9 > $(git 
> describe).tar.xz
> ;; See  for details.
> -   (version "2.26-91-gaaa2eb83b8")
> +   ;;
> +   ;; Note: Always use a dot after the minor version since various places 
> rely
> +   ;; on "version-major+minor" to determine where locales are found.
> +   (version "2.26.91-gaaa2eb83b8")
> (source (origin
>  (method url-fetch)
>  (uri (string-append "https://alpha.gnu.org/gnu/guix/mirror/";
> -"glibc-" version ".tar.xz"))
> +"glibc-" (version-major+minor version) "-"
> +(caddr (string-split version #\.)) 
> ".tar.xz"))
>  (sha256
>   (base32
>"1zwz6d0x3ndd0hgqp17fx71miyjvn4dgkl1nzhaz3mbcqxzrprhk"))
> @@ -585,7 +589,7 @@ store.")
>  ;; `--localedir' is not honored, so work around it.
>  ;; See 
> .
>  (string-append 
> "libc_cv_complocaledir=/run/current-system/locale/"
> -   ,version)
> +   ,(version-major+minor version))
>  
>  (string-append "--with-headers="
> (assoc-ref ,(if (%current-target-system)
> @@ -955,7 +959,8 @@ the 'share/locale' sub-directory of this package.")
> (list (string-append "libc_cv_complocaledir="
>  (assoc-ref %outputs "out")
>  "/lib/locale/"
> -,(package-version glibc))
> +,(version-major+minor
> +  (package-version glibc)))
>  
>  (define-public glibc-utf8-locales
>(package
> @@ -973,7 +978,7 @@ the 'share/locale' sub-directory of this package.")
>(gzip  (assoc-ref %build-inputs "gzip"))
>(out   (assoc-ref %outputs "out"))
>(localedir (string-append out "/lib/locale/"
> -,version)))
> +,(version-major+minor 
> version
>   ;; 'localedef' needs 'gzip'.
>   (setenv "PATH" (string-append libc "/bin:" gzip "/bin"))
>  
> diff --git a/guix/profiles.scm b/guix/profiles.scm
> index 0eb99f40d..51c330b32 100644
> --- a/guix/profiles.scm
> +++ b/guix/profiles.scm
> @@ -812,7 +812,8 @@ MANIFEST.  Single-file bundles are required by programs 
> such as Git and L

bug#29516: Maxima fails to build

[Diego Nicola Barbato]

Mark H Weaver  writes:

> Diego Nicola Barbato  writes:
>
>> Leo Famulari  writes:
>>
>>> On Fri, Dec 01, 2017 at 11:53:01AM +0100, Diego Nicola Barbato wrote:
 `guix build maxima' fails during the `check' phase with the following
 output:
>>>
>>> Thanks for your report!
>
> FYI, the Maxima builds started failing after the recent upgrade to
> 'gcl'.  I raised the issue here:
>
>   https://lists.gnu.org/archive/html/guix-devel/2017-11/msg00341.html
>
> The person who upgraded 'gcl' first said that he could reproduce the
> build failure locally, and then said that he couldn't.  I'm not sure
> what happened there.
>
>   Mark

This seems to be quite a strange issue indeed:  Out of curiosity I tried
the same thing in a VM (guix system vm-image) and even though it is the
same architecture (x86_64) and the same commit 
(e2721a05e7d778bdf845b7cb7a42fd9f76095b69) guix consistently succeeds to
build maxima in the VM while it consistently fails to build on my
laptop.  I also tried building with only one core on my laptop and
running the VM with two cores (qemu-system-x86_64 -smp cores=2) with the
same result.  `guix build maxima' only fails on the VM when I run it
with `--rounds=2' because the outputs differ.

Diego

bug#29537: Core updates broken

[Marius Bakke]

Marius Bakke  writes:

> Marius Bakke  writes:
>
>> Gábor Boskovits  writes:
>>
>>> It seems, that we have a breakage in current core-updates. m4, gettext, and
>>> at least a few other packages fail to build.
>>
>> Hello!
>>
>> The problem is that the glibc version string is used a couple of places
>> to determine where locales are found.
>>
>> The attached patch fixes it, though I'm not sure if it's the best
>> approach.  Thoughts?
>
> Actually, the patch below is not a complete fix.  It worked for m4, but
> some other packages now fail like this:
>
> --8<---cut here---start->8---
>
> @ build-started 
> /gnu/store/q0fadqzsg969jz8v11r9j2a07x3h2sl4-perl-5.26.1.tar.xz.drv - 
> x86_64-linux 
> /var/log/guix/drvs/q0//fadqzsg969jz8v11r9j2a07x3h2sl4-perl-5.26.1.tar.xz.drv.bz2
> Backtrace:
>2 (primitive-load "/gnu/store/xjb3g9spv30arffi1296qwdaam4?")
> In ice-9/eval.scm:
> 619:8  1 (_ #f)
> In unknown file:
>0 (setlocale 6 "en_US.utf8")
>
> ERROR: In procedure setlocale:
> ERROR: In procedure setlocale: Invalid argument
> builder for 
> `/gnu/store/q0fadqzsg969jz8v11r9j2a07x3h2sl4-perl-5.26.1.tar.xz.drv' failed 
> with exit code 1
> --8<---cut here---end--->8---
>
> Not sure where it's from yet.

This was from (guix packages) and fixed by adding this hunk:

--8<---cut here---start->8---
diff --git a/guix/packages.scm b/guix/packages.scm
index f619d9b37..35f9b685a 100644
--- a/guix/packages.scm
+++ b/guix/packages.scm
@@ -538,7 +538,8 @@ specifies modules in scope when evaluating SNIPPET."
   (setenv "LOCPATH"
   (string-append #+locales "/lib/locale/"
  #+(and locales
-(package-version locales
+(version-major+minor
+ (package-version locales)
   (setlocale LC_ALL "en_US.utf8"))
 
 (setenv "PATH" (string-append #+xz "/bin" ":"
--8<---cut here---end--->8---


signature.asc
Description: PGP signature

bug#29537: Core updates broken

[Gábor Boskovits]

I think it is good to have this one.
In my opinion it is ok, but it would be great if someone else could also
have a look at that.
Once we have a constent that this is a good solution it would be great to
it pushed as soon as posssible, so that I can rebase on this.

The only case where this might might be problematic, is if we really have
different locales for two versions, that are now mapped identically.
How likely is that?
Another possibility would be to really make the locales available under the
full version string path, where they are expected...
That would rule out such an occurence.
WDYT?


2017-12-03 15:13 GMT+01:00 Marius Bakke :

> Gábor Boskovits  writes:
>
> > It seems, that we have a breakage in current core-updates. m4, gettext,
> and
> > at least a few other packages fail to build.
>
> Hello!
>
> The problem is that the glibc version string is used a couple of places
> to determine where locales are found.
>
> The attached patch fixes it, though I'm not sure if it's the best
> approach.  Thoughts?
>
>

bug#29537: Core updates broken

[Ricardo Wurmus]

Marius Bakke  writes:

> Gábor Boskovits  writes:
>
>> It seems, that we have a breakage in current core-updates. m4, gettext, and
>> at least a few other packages fail to build.
>
> Hello!
>
> The problem is that the glibc version string is used a couple of places
> to determine where locales are found.
>
> The attached patch fixes it, though I'm not sure if it's the best
> approach.  Thoughts?

Thank you.

I find it a little ugly to replace the exact version string with only
the major+minor version substring.  Why can’t we use the full version
string?

Do you mean that other packages (such as m4, gettext, etc) compare
against only the major+minor substring of glibc?  If that is so, I think
this patch is acceptable as we cannot possibly patch all other packages
to use the full version string.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#29537: Core updates broken

[Marius Bakke]

Ricardo Wurmus  writes:

> Marius Bakke  writes:
>
>> Gábor Boskovits  writes:
>>
>>> It seems, that we have a breakage in current core-updates. m4, gettext, and
>>> at least a few other packages fail to build.
>>
>> Hello!
>>
>> The problem is that the glibc version string is used a couple of places
>> to determine where locales are found.
>>
>> The attached patch fixes it, though I'm not sure if it's the best
>> approach.  Thoughts?
>
> Thank you.
>
> I find it a little ugly to replace the exact version string with only
> the major+minor version substring.  Why can’t we use the full version
> string?

I think it's because "glibc-versioned-locpath.patch" uses the libc
VERSION constant.

Perhaps we could substitute glibcs "version.h", but that might break
other things.  Or introduce a different variable, say
GUIX_GLIBC_VERSION, and use that.  WDYT?


signature.asc
Description: PGP signature

bug#29537: Core updates broken

[Gábor Boskovits]

I'd go the GUIX_GLIBC_VERSION way.

That one seems the clearest, at least to me...

2017-12-03 19:43 GMT+01:00 Marius Bakke :

> Ricardo Wurmus  writes:
>
> > Marius Bakke  writes:
> >
> >> Gábor Boskovits  writes:
> >>
> >>> It seems, that we have a breakage in current core-updates. m4,
> gettext, and
> >>> at least a few other packages fail to build.
> >>
> >> Hello!
> >>
> >> The problem is that the glibc version string is used a couple of places
> >> to determine where locales are found.
> >>
> >> The attached patch fixes it, though I'm not sure if it's the best
> >> approach.  Thoughts?
> >
> > Thank you.
> >
> > I find it a little ugly to replace the exact version string with only
> > the major+minor version substring.  Why can’t we use the full version
> > string?
>
> I think it's because "glibc-versioned-locpath.patch" uses the libc
> VERSION constant.
>
> Perhaps we could substitute glibcs "version.h", but that might break
> other things.  Or introduce a different variable, say
> GUIX_GLIBC_VERSION, and use that.  WDYT?
>

bug#29522: rustc-1.16.0 broken after jemalloc updated to 5.0.1

[Jelle Licht]

2017-11-30 23:41 GMT+01:00 Adam Van Ymeren :

> I haven't had time to dig in to this further, but in case anyone wants
> to fix rustc-1.16.0, it's broken after the upgrade of jemalloc to 5.0.1.
>
> Reverting commit 475b99fa5cf402430aa93a40e406e854ad2ff6e4 which reverts
> jemalloc back to 4.5.0 causes rustc to build successfully again.  It has
> been broken for some time.
>
> https://hydra.gnu.org/job/gnu/master/rustc-1.16.0.x86_64-linux
>
>
>
>
It seems that the bundled copy of jemalloc in the rustc repo is currently
pinned at 4.5.0 partially
because of this specific issue as well.

I did find an issue on the rust GH repo [0], and it seems this also affects
the nix-rust project,
who seem to have the same errors as our currently failing build [1].

A temporary workaround could be to have a custom version of jemalloc with
the c++ features disabled
by building with `--disable-cxx'. Alternatively, we could just make use of
jemalloc 4.5.0 for rustc only
until this is all sorted our by upstream.

[0]: https://github.com/rust-lang/rust/issues/43586
[1]: https://gist.github.com/marmistrz/a6e503a5491df80a493030e0a0e702d2