bug#29537: Core updates broken

bug#29537: Core updates broken

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 8569 bytes --]

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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567250> * g_bor
has joined #guix
[09:34:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567251> <g_bor> Hello
guix!
[09:37:37] <https://gnunet.org/bot/log/guix/2017-12-02#T1567253> <g_bor> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567254> <g_bor> I'm
tring this now on master to see if the problem persists.
[09:38:10] <https://gnunet.org/bot/log/guix/2017-12-02#T1567255> <g_bor> Anyone
seen that?
[16:46:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567672>
<civodul> mb[m]1:
you were right about the failing installation tests
[16:46:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567673> <civodul> it
did work a couple of days ago though, so there's hope
[16:47:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567675>
<mb[m]1> civodul:
Any idea what caused it? Haven't been paying attention lately.
[16:47:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567676> *
kristofer has joined #guix
[16:53:03] <https://gnunet.org/bot/log/guix/2017-12-02#T1567677>
<civodul> mb[m]1:
no idea yet, let's see
[16:54:11] <https://gnunet.org/bot/log/guix/2017-12-02#T1567678> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567679>
<civodul> how's
it failing?
[16:54:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567680> <civodul> well
maybe i should focus on one thing at a time :-)
[16:54:46] <https://gnunet.org/bot/log/guix/2017-12-02#T1567681> <mb[m]1> So
the culprit is likely one of these:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
<https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c4cbaf2808434c618745137c>
 and
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce62ae0bbb45...
<https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce62ae0bbb456c6a855dbb6b384ecf7e988>
[16:55:27] <https://gnunet.org/bot/log/guix/2017-12-02#T1567682> * jonsger
has joined #guix
[16:55:31] <https://gnunet.org/bot/log/guix/2017-12-02#T1567683>
<mb[m]1> civodul:
"m4" and a few others fail like this: https://paste.debian.net/998765/
[16:55:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567684>
<civodul> you'll
find yourself being a libc hacker without noticing
[16:55:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567685> <mb[m]1>
Hehe.
[16:56:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567686> <civodul> in
this case it's the 'configure' file that leads to a decoding error
[16:56:28] <https://gnunet.org/bot/log/guix/2017-12-02#T1567687>
<civodul> could
you check its encoding?

[16:57:52] <https://gnunet.org/bot/log/guix/2017-12-02#T1567689> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567690> * jonsger
has joined #guix
[17:00:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567693> <mb[m]1> I
unpacked the m4 source and ran `file` on it:
[17:00:57] <https://gnunet.org/bot/log/guix/2017-12-02#T1567694>
<mb[m]1> configure:
POSIX shell script, UTF-8 Unicode text executable
[17:01:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567695> <civodul> so
it could be an issue with iconv in the new libc
[17:06:59] <https://gnunet.org/bot/log/guix/2017-12-02#T1567697> *
ryanwatkins has joined #guix
[17:11:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567699> <g_bor>
hello!
[17:11:18] <https://gnunet.org/bot/log/guix/2017-12-02#T1567700> <g_bor> Anyone
seen this?
[17:11:30] <https://gnunet.org/bot/log/guix/2017-12-02#T1567701> <g_bor> It's
on core-updates:
[17:11:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567702>
<g_bor> 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 #<procedure 9b0b40 at
/gnu/store/yifqwmdxc4pmd?> ?) 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567703>
<civodul> g_bor:
mb[m]1 was just reporting the exact same issue :-)
[17:13:45] <https://gnunet.org/bot/log/guix/2017-12-02#T1567704>
<mb[m]1> g_bor:
Yes, I'm currently trying to track it down.
[17:14:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567705> <g_bor> I've
also seen it on python-boot0, slightly different message.
[17:14:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567706> <g_bor> Can
this be locale related?
[17:15:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567707> <g_bor> I
have hu_HU.utf8 here.
[17:16:04] <https://gnunet.org/bot/log/guix/2017-12-02#T1567708> * civodul
has quit (Read error: Connection reset by peer)
[17:17:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567709>
<g_bor> mb[m]1:
can I be of assistance?
[17:18:19] <https://gnunet.org/bot/log/guix/2017-12-02#T1567711> * civodul
has joined #guix
[17:18:42] <https://gnunet.org/bot/log/guix/2017-12-02#T1567713>
<mb[m]1> g_bor:
The failure happens in the build container which uses a fixed locale (C?).
[17:19:17] <https://gnunet.org/bot/log/guix/2017-12-02#T1567714> <g_bor> Ok,
then it's not that.
[17:19:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567715> <g_bor> It
just seemd to be some character conversion error...
[17:20:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567716> <g_bor> Maybe
some invalid charaters leaked in somehow...
[17:20:15] <https://gnunet.org/bot/log/guix/2017-12-02#T1567717> <g_bor> Wait
a sec...
[17:22:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567719> <g_bor> It
seems, that a lot of packages are broken.
[17:23:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567720> <g_bor> I
laso got that for gettext.
[17:26:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567721> *
xkapastel has joined #guix
[17:30:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567723> <mb[m]1> Can
it be ncurses related?
[17:31:12] <https://gnunet.org/bot/log/guix/2017-12-02#T1567724> <g_bor> Might
be...
[17:31:21] <https://gnunet.org/bot/log/guix/2017-12-02#T1567725> <g_bor> did
not checked that.
[17:32:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567726>
<mb[m]1> g_bor:
Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes a
difference?
[17:32:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567727> <g_bor> Ok,
i will try that
[17:36:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567731> <g_bor> Do
we know about what was the last time it was working?
[17:36:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567732> <g_bor> We
could do a git bisect on core-updates?
[17:37:13] <https://gnunet.org/bot/log/guix/2017-12-02#T1567733> <g_bor> Do
we have a good commit to start from?
[18:40] <g_bor> Ok, now it's building.
[18:40] <g_bor> I think this will take a time...
[18:41] <g_bor> (guile does take some time :) )
[18:42] <g_bor> I'm trying to help to switch the default icedtea to
icedtea-8, and we'd like to that on core-updates...
[18:43] <g_bor> I've just written on the mailing list, that it would be
nice if we could have substitutes for the core-updates gnu-build-system.
[18:43] <g_bor> That could speed things like this up.
[18:50] <efraim> mb[m]1: just popped in for a second, core-updates is
failing on aarch64 also
[18:50] <efraim> civodul too ^
[18:52] <g_bor> Oh, well.
[18:52] <g_bor> Do we have a bug report on that already?
[18:53] <g_bor> Now I'm trying what mb[m]1 suggested, by reverting the
ncurses commit.
[18:54] <g_bor> It might be easier to track related information in a bug...

[20:52] <g_bor> reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 did not
help

Does anyone know of a last working commit id?

I'm trying to seen if it's working after last merge of master, but if
someone knows a later point to start investigating the issue would help.

It would also help, if someone with a more powerful computer could help, as
building on mine is very slow.

[-- Attachment #2: Type: text/html, Size: 42017 bytes --]

bug#29537: Acknowledgement (Core updates broken)

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

2dd12924cf4a30a96262b6d392fcde58c9f10d4b is good.

2017-12-02 21:14 GMT+01:00 GNU bug Tracking System <help-debbugs@gnu.org>:

> Thank you for filing a new bug report with debbugs.gnu.org.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  bug-guix@gnu.org
>
> If you wish to submit further information on this problem, please
> send it to 29537@debbugs.gnu.org.
>
> Please do not send mail to help-debbugs@gnu.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 29537: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>

[-- Attachment #2: Type: text/html, Size: 1639 bytes --]

bug#29537: Acknowledgement (Core updates broken)

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]

61bed1570 is good


2017-12-02 22:32 GMT+01:00 Gábor Boskovits <boskovits@gmail.com>:

> 2dd12924cf4a30a96262b6d392fcde58c9f10d4b is good.
>
> 2017-12-02 21:14 GMT+01:00 GNU bug Tracking System <help-debbugs@gnu.org>:
>
>> Thank you for filing a new bug report with debbugs.gnu.org.
>>
>> This is an automatically generated reply to let you know your message
>> has been received.
>>
>> Your message is being forwarded to the package maintainers and other
>> interested parties for their attention; they will reply in due course.
>>
>> Your message has been sent to the package maintainer(s):
>>  bug-guix@gnu.org
>>
>> If you wish to submit further information on this problem, please
>> send it to 29537@debbugs.gnu.org.
>>
>> Please do not send mail to help-debbugs@gnu.org unless you wish
>> to report a problem with the Bug-tracking system.
>>
>> --
>> 29537: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537
>> GNU Bug Tracking System
>> Contact help-debbugs@gnu.org with problems
>>
>
>

[-- Attachment #2: Type: text/html, Size: 2178 bytes --]

bug#29537: Core updates broken

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 9139 bytes --]

 8dd35a0e2 is good


2017-12-02 21:12 GMT+01:00 Gábor Boskovits <boskovits@gmail.com>:

> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567250> * g_bor
> has joined #guix
> [09:34:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567251> <g_bor> Hello
> guix!
> [09:37:37] <https://gnunet.org/bot/log/guix/2017-12-02#T1567253> <g_bor> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567254> <g_bor> I'm
> tring this now on master to see if the problem persists.
> [09:38:10] <https://gnunet.org/bot/log/guix/2017-12-02#T1567255> <g_bor> Anyone
> seen that?
> [16:46:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567672> <civodul> mb[m]1:
> you were right about the failing installation tests
> [16:46:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567673> <civodul> it
> did work a couple of days ago though, so there's hope
> [16:47:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567675> <mb[m]1> civodul:
> Any idea what caused it? Haven't been paying attention lately.
> [16:47:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567676> *
> kristofer has joined #guix
> [16:53:03] <https://gnunet.org/bot/log/guix/2017-12-02#T1567677> <civodul> mb[m]1:
> no idea yet, let's see
> [16:54:11] <https://gnunet.org/bot/log/guix/2017-12-02#T1567678> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567679> <civodul> how's
> it failing?
> [16:54:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567680> <civodul> well
> maybe i should focus on one thing at a time :-)
> [16:54:46] <https://gnunet.org/bot/log/guix/2017-12-02#T1567681> <mb[m]1> So
> the culprit is likely one of these: https://sourceware.org/
> git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
> <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c4cbaf2808434c618745137c>
>  and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=
> dc258ce62ae0bbb45...
> <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce62ae0bbb456c6a855dbb6b384ecf7e988>
> [16:55:27] <https://gnunet.org/bot/log/guix/2017-12-02#T1567682> *
> jonsger has joined #guix
> [16:55:31] <https://gnunet.org/bot/log/guix/2017-12-02#T1567683> <mb[m]1> civodul:
> "m4" and a few others fail like this: https://paste.debian.net/998765/
> [16:55:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567684> <civodul> you'll
> find yourself being a libc hacker without noticing
> [16:55:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567685> <mb[m]1>
> Hehe.
> [16:56:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567686> <civodul> in
> this case it's the 'configure' file that leads to a decoding error
> [16:56:28] <https://gnunet.org/bot/log/guix/2017-12-02#T1567687> <civodul> could
> you check its encoding?
>
> [16:57:52] <https://gnunet.org/bot/log/guix/2017-12-02#T1567689> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567690> *
> jonsger has joined #guix
> [17:00:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567693> <mb[m]1> I
> unpacked the m4 source and ran `file` on it:
> [17:00:57] <https://gnunet.org/bot/log/guix/2017-12-02#T1567694> <mb[m]1> configure:
> POSIX shell script, UTF-8 Unicode text executable
> [17:01:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567695> <civodul> so
> it could be an issue with iconv in the new libc
> [17:06:59] <https://gnunet.org/bot/log/guix/2017-12-02#T1567697> *
> ryanwatkins has joined #guix
> [17:11:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567699> <g_bor>
> hello!
> [17:11:18] <https://gnunet.org/bot/log/guix/2017-12-02#T1567700> <g_bor> Anyone
> seen this?
> [17:11:30] <https://gnunet.org/bot/log/guix/2017-12-02#T1567701> <g_bor> It's
> on core-updates:
> [17:11:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567702> <g_bor> 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
> #<procedure 9b0b40 at /gnu/store/yifqwmdxc4pmd?> ?) 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567703> <civodul> g_bor:
> mb[m]1 was just reporting the exact same issue :-)
> [17:13:45] <https://gnunet.org/bot/log/guix/2017-12-02#T1567704> <mb[m]1> g_bor:
> Yes, I'm currently trying to track it down.
> [17:14:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567705> <g_bor> I've
> also seen it on python-boot0, slightly different message.
> [17:14:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567706> <g_bor> Can
> this be locale related?
> [17:15:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567707> <g_bor> I
> have hu_HU.utf8 here.
> [17:16:04] <https://gnunet.org/bot/log/guix/2017-12-02#T1567708> *
> civodul has quit (Read error: Connection reset by peer)
> [17:17:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567709> <g_bor> mb[m]1:
> can I be of assistance?
> [17:18:19] <https://gnunet.org/bot/log/guix/2017-12-02#T1567711> *
> civodul has joined #guix
> [17:18:42] <https://gnunet.org/bot/log/guix/2017-12-02#T1567713> <mb[m]1> g_bor:
> The failure happens in the build container which uses a fixed locale (C?).
> [17:19:17] <https://gnunet.org/bot/log/guix/2017-12-02#T1567714> <g_bor> Ok,
> then it's not that.
> [17:19:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567715> <g_bor> It
> just seemd to be some character conversion error...
> [17:20:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567716> <g_bor> Maybe
> some invalid charaters leaked in somehow...
> [17:20:15] <https://gnunet.org/bot/log/guix/2017-12-02#T1567717> <g_bor> Wait
> a sec...
> [17:22:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567719> <g_bor> It
> seems, that a lot of packages are broken.
> [17:23:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567720> <g_bor> I
> laso got that for gettext.
> [17:26:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567721> *
> xkapastel has joined #guix
> [17:30:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567723> <mb[m]1> Can
> it be ncurses related?
> [17:31:12] <https://gnunet.org/bot/log/guix/2017-12-02#T1567724> <g_bor> Might
> be...
> [17:31:21] <https://gnunet.org/bot/log/guix/2017-12-02#T1567725> <g_bor> did
> not checked that.
> [17:32:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567726> <mb[m]1> g_bor:
> Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes a
> difference?
> [17:32:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567727> <g_bor> Ok,
> i will try that
> [17:36:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567731> <g_bor> Do
> we know about what was the last time it was working?
> [17:36:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567732> <g_bor> We
> could do a git bisect on core-updates?
> [17:37:13] <https://gnunet.org/bot/log/guix/2017-12-02#T1567733> <g_bor> Do
> we have a good commit to start from?
> [18:40] <g_bor> Ok, now it's building.
> [18:40] <g_bor> I think this will take a time...
> [18:41] <g_bor> (guile does take some time :) )
> [18:42] <g_bor> I'm trying to help to switch the default icedtea to
> icedtea-8, and we'd like to that on core-updates...
> [18:43] <g_bor> I've just written on the mailing list, that it would be
> nice if we could have substitutes for the core-updates gnu-build-system.
> [18:43] <g_bor> That could speed things like this up.
> [18:50] <efraim> mb[m]1: just popped in for a second, core-updates is
> failing on aarch64 also
> [18:50] <efraim> civodul too ^
> [18:52] <g_bor> Oh, well.
> [18:52] <g_bor> Do we have a bug report on that already?
> [18:53] <g_bor> Now I'm trying what mb[m]1 suggested, by reverting the
> ncurses commit.
> [18:54] <g_bor> It might be easier to track related information in a
> bug...
>
> [20:52] <g_bor> reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 did
> not help
>
> Does anyone know of a last working commit id?
>
> I'm trying to seen if it's working after last merge of master, but if
> someone knows a later point to start investigating the issue would help.
>
> It would also help, if someone with a more powerful computer could help,
> as building on mine is very slow.
>
>

[-- Attachment #2: Type: text/html, Size: 51697 bytes --]

bug#29537: Core updates broken

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 9455 bytes --]

ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a is the first bad commit.

2017-12-03 9:41 GMT+01:00 Gábor Boskovits <boskovits@gmail.com>:

>  8dd35a0e2 is good
>
>
> 2017-12-02 21:12 GMT+01:00 Gábor Boskovits <boskovits@gmail.com>:
>
>> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567250> * g_bor
>> has joined #guix
>> [09:34:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567251> <g_bor> Hello
>> guix!
>> [09:37:37] <https://gnunet.org/bot/log/guix/2017-12-02#T1567253> <g_bor> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567254> <g_bor> I'm
>> tring this now on master to see if the problem persists.
>> [09:38:10] <https://gnunet.org/bot/log/guix/2017-12-02#T1567255> <g_bor> Anyone
>> seen that?
>> [16:46:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567672>
>> <civodul> mb[m]1: you were right about the failing installation tests
>> [16:46:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567673>
>> <civodul> it did work a couple of days ago though, so there's hope
>> [16:47:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567675> <mb[m]1> civodul:
>> Any idea what caused it? Haven't been paying attention lately.
>> [16:47:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567676> *
>> kristofer has joined #guix
>> [16:53:03] <https://gnunet.org/bot/log/guix/2017-12-02#T1567677>
>> <civodul> mb[m]1: no idea yet, let's see
>> [16:54:11] <https://gnunet.org/bot/log/guix/2017-12-02#T1567678> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567679>
>> <civodul> how's it failing?
>> [16:54:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567680>
>> <civodul> well maybe i should focus on one thing at a time :-)
>> [16:54:46] <https://gnunet.org/bot/log/guix/2017-12-02#T1567681> <mb[m]1> So
>> the culprit is likely one of these: https://sourceware.org/
>> git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
>> <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c4cbaf2808434c618745137c>
>>  and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce6
>> 2ae0bbb45...
>> <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce62ae0bbb456c6a855dbb6b384ecf7e988>
>> [16:55:27] <https://gnunet.org/bot/log/guix/2017-12-02#T1567682> *
>> jonsger has joined #guix
>> [16:55:31] <https://gnunet.org/bot/log/guix/2017-12-02#T1567683> <mb[m]1> civodul:
>> "m4" and a few others fail like this: https://paste.debian.net/998765/
>> [16:55:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567684>
>> <civodul> you'll find yourself being a libc hacker without noticing
>> [16:55:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567685> <mb[m]1>
>> Hehe.
>> [16:56:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567686>
>> <civodul> in this case it's the 'configure' file that leads to a
>> decoding error
>> [16:56:28] <https://gnunet.org/bot/log/guix/2017-12-02#T1567687>
>> <civodul> could you check its encoding?
>>
>> [16:57:52] <https://gnunet.org/bot/log/guix/2017-12-02#T1567689> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567690> *
>> jonsger has joined #guix
>> [17:00:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567693> <mb[m]1> I
>> unpacked the m4 source and ran `file` on it:
>> [17:00:57] <https://gnunet.org/bot/log/guix/2017-12-02#T1567694> <mb[m]1> configure:
>> POSIX shell script, UTF-8 Unicode text executable
>> [17:01:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567695>
>> <civodul> so it could be an issue with iconv in the new libc
>> [17:06:59] <https://gnunet.org/bot/log/guix/2017-12-02#T1567697> *
>> ryanwatkins has joined #guix
>> [17:11:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567699> <g_bor>
>> hello!
>> [17:11:18] <https://gnunet.org/bot/log/guix/2017-12-02#T1567700> <g_bor> Anyone
>> seen this?
>> [17:11:30] <https://gnunet.org/bot/log/guix/2017-12-02#T1567701> <g_bor> It's
>> on core-updates:
>> [17:11:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567702> <g_bor> 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 #<procedure 9b0b40 at
>> /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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567703>
>> <civodul> g_bor: mb[m]1 was just reporting the exact same issue :-)
>> [17:13:45] <https://gnunet.org/bot/log/guix/2017-12-02#T1567704> <mb[m]1> g_bor:
>> Yes, I'm currently trying to track it down.
>> [17:14:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567705> <g_bor> I've
>> also seen it on python-boot0, slightly different message.
>> [17:14:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567706> <g_bor> Can
>> this be locale related?
>> [17:15:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567707> <g_bor> I
>> have hu_HU.utf8 here.
>> [17:16:04] <https://gnunet.org/bot/log/guix/2017-12-02#T1567708> *
>> civodul has quit (Read error: Connection reset by peer)
>> [17:17:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567709> <g_bor> mb[m]1:
>> can I be of assistance?
>> [17:18:19] <https://gnunet.org/bot/log/guix/2017-12-02#T1567711> *
>> civodul has joined #guix
>> [17:18:42] <https://gnunet.org/bot/log/guix/2017-12-02#T1567713> <mb[m]1> g_bor:
>> The failure happens in the build container which uses a fixed locale (C?).
>> [17:19:17] <https://gnunet.org/bot/log/guix/2017-12-02#T1567714> <g_bor> Ok,
>> then it's not that.
>> [17:19:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567715> <g_bor> It
>> just seemd to be some character conversion error...
>> [17:20:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567716> <g_bor> Maybe
>> some invalid charaters leaked in somehow...
>> [17:20:15] <https://gnunet.org/bot/log/guix/2017-12-02#T1567717> <g_bor> Wait
>> a sec...
>> [17:22:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567719> <g_bor> It
>> seems, that a lot of packages are broken.
>> [17:23:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567720> <g_bor> I
>> laso got that for gettext.
>> [17:26:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567721> *
>> xkapastel has joined #guix
>> [17:30:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567723> <mb[m]1> Can
>> it be ncurses related?
>> [17:31:12] <https://gnunet.org/bot/log/guix/2017-12-02#T1567724> <g_bor> Might
>> be...
>> [17:31:21] <https://gnunet.org/bot/log/guix/2017-12-02#T1567725> <g_bor> did
>> not checked that.
>> [17:32:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567726> <mb[m]1> g_bor:
>> Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes
>> a difference?
>> [17:32:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567727> <g_bor> Ok,
>> i will try that
>> [17:36:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567731> <g_bor> Do
>> we know about what was the last time it was working?
>> [17:36:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567732> <g_bor> We
>> could do a git bisect on core-updates?
>> [17:37:13] <https://gnunet.org/bot/log/guix/2017-12-02#T1567733> <g_bor> Do
>> we have a good commit to start from?
>> [18:40] <g_bor> Ok, now it's building.
>> [18:40] <g_bor> I think this will take a time...
>> [18:41] <g_bor> (guile does take some time :) )
>> [18:42] <g_bor> I'm trying to help to switch the default icedtea to
>> icedtea-8, and we'd like to that on core-updates...
>> [18:43] <g_bor> I've just written on the mailing list, that it would be
>> nice if we could have substitutes for the core-updates gnu-build-system.
>> [18:43] <g_bor> That could speed things like this up.
>> [18:50] <efraim> mb[m]1: just popped in for a second, core-updates is
>> failing on aarch64 also
>> [18:50] <efraim> civodul too ^
>> [18:52] <g_bor> Oh, well.
>> [18:52] <g_bor> Do we have a bug report on that already?
>> [18:53] <g_bor> Now I'm trying what mb[m]1 suggested, by reverting the
>> ncurses commit.
>> [18:54] <g_bor> It might be easier to track related information in a
>> bug...
>>
>> [20:52] <g_bor> reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 did
>> not help
>>
>> Does anyone know of a last working commit id?
>>
>> I'm trying to seen if it's working after last merge of master, but if
>> someone knows a later point to start investigating the issue would help.
>>
>> It would also help, if someone with a more powerful computer could help,
>> as building on mine is very slow.
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 60808 bytes --]

bug#29537: Core updates broken

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 9839 bytes --]

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 <boskovits@gmail.com>:

> ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a is the first bad commit.
>
> 2017-12-03 9:41 GMT+01:00 Gábor Boskovits <boskovits@gmail.com>:
>
>>  8dd35a0e2 is good
>>
>>
>> 2017-12-02 21:12 GMT+01:00 Gábor Boskovits <boskovits@gmail.com>:
>>
>>> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567250> *
>>> g_bor has joined #guix
>>> [09:34:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567251> <g_bor> Hello
>>> guix!
>>> [09:37:37] <https://gnunet.org/bot/log/guix/2017-12-02#T1567253> <g_bor> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567254> <g_bor> I'm
>>> tring this now on master to see if the problem persists.
>>> [09:38:10] <https://gnunet.org/bot/log/guix/2017-12-02#T1567255> <g_bor> Anyone
>>> seen that?
>>> [16:46:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567672>
>>> <civodul> mb[m]1: you were right about the failing installation tests
>>> [16:46:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567673>
>>> <civodul> it did work a couple of days ago though, so there's hope
>>> [16:47:16] <https://gnunet.org/bot/log/guix/2017-12-02#T1567675>
>>> <mb[m]1> civodul: Any idea what caused it? Haven't been paying
>>> attention lately.
>>> [16:47:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567676> *
>>> kristofer has joined #guix
>>> [16:53:03] <https://gnunet.org/bot/log/guix/2017-12-02#T1567677>
>>> <civodul> mb[m]1: no idea yet, let's see
>>> [16:54:11] <https://gnunet.org/bot/log/guix/2017-12-02#T1567678>
>>> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567679>
>>> <civodul> how's it failing?
>>> [16:54:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567680>
>>> <civodul> well maybe i should focus on one thing at a time :-)
>>> [16:54:46] <https://gnunet.org/bot/log/guix/2017-12-02#T1567681>
>>> <mb[m]1> So the culprit is likely one of these: https://sourceware.org/
>>> git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c...
>>> <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=665ce88d68fd13c5c4cbaf2808434c618745137c>
>>>  and https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce6
>>> 2ae0bbb45...
>>> <https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=dc258ce62ae0bbb456c6a855dbb6b384ecf7e988>
>>> [16:55:27] <https://gnunet.org/bot/log/guix/2017-12-02#T1567682> *
>>> jonsger has joined #guix
>>> [16:55:31] <https://gnunet.org/bot/log/guix/2017-12-02#T1567683>
>>> <mb[m]1> civodul: "m4" and a few others fail like this:
>>> https://paste.debian.net/998765/
>>> [16:55:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567684>
>>> <civodul> you'll find yourself being a libc hacker without noticing
>>> [16:55:41] <https://gnunet.org/bot/log/guix/2017-12-02#T1567685>
>>> <mb[m]1> Hehe.
>>> [16:56:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567686>
>>> <civodul> in this case it's the 'configure' file that leads to a
>>> decoding error
>>> [16:56:28] <https://gnunet.org/bot/log/guix/2017-12-02#T1567687>
>>> <civodul> could you check its encoding?
>>>
>>> [16:57:52] <https://gnunet.org/bot/log/guix/2017-12-02#T1567689>
>>> <mb[m]1> 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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567690> *
>>> jonsger has joined #guix
>>> [17:00:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567693>
>>> <mb[m]1> I unpacked the m4 source and ran `file` on it:
>>> [17:00:57] <https://gnunet.org/bot/log/guix/2017-12-02#T1567694>
>>> <mb[m]1> configure: POSIX shell script, UTF-8 Unicode text executable
>>> [17:01:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567695>
>>> <civodul> so it could be an issue with iconv in the new libc
>>> [17:06:59] <https://gnunet.org/bot/log/guix/2017-12-02#T1567697> *
>>> ryanwatkins has joined #guix
>>> [17:11:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567699> <g_bor>
>>> hello!
>>> [17:11:18] <https://gnunet.org/bot/log/guix/2017-12-02#T1567700> <g_bor> Anyone
>>> seen this?
>>> [17:11:30] <https://gnunet.org/bot/log/guix/2017-12-02#T1567701> <g_bor> It's
>>> on core-updates:
>>> [17:11:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567702> <g_bor> 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 #<procedure 9b0b40 at
>>> /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] <https://gnunet.org/bot/log/guix/2017-12-02#T1567703>
>>> <civodul> g_bor: mb[m]1 was just reporting the exact same issue :-)
>>> [17:13:45] <https://gnunet.org/bot/log/guix/2017-12-02#T1567704>
>>> <mb[m]1> g_bor: Yes, I'm currently trying to track it down.
>>> [17:14:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567705> <g_bor> I've
>>> also seen it on python-boot0, slightly different message.
>>> [17:14:55] <https://gnunet.org/bot/log/guix/2017-12-02#T1567706> <g_bor> Can
>>> this be locale related?
>>> [17:15:05] <https://gnunet.org/bot/log/guix/2017-12-02#T1567707> <g_bor> I
>>> have hu_HU.utf8 here.
>>> [17:16:04] <https://gnunet.org/bot/log/guix/2017-12-02#T1567708> *
>>> civodul has quit (Read error: Connection reset by peer)
>>> [17:17:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567709> <g_bor> mb[m]1:
>>> can I be of assistance?
>>> [17:18:19] <https://gnunet.org/bot/log/guix/2017-12-02#T1567711> *
>>> civodul has joined #guix
>>> [17:18:42] <https://gnunet.org/bot/log/guix/2017-12-02#T1567713>
>>> <mb[m]1> g_bor: The failure happens in the build container which uses a
>>> fixed locale (C?).
>>> [17:19:17] <https://gnunet.org/bot/log/guix/2017-12-02#T1567714> <g_bor> Ok,
>>> then it's not that.
>>> [17:19:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567715> <g_bor> It
>>> just seemd to be some character conversion error...
>>> [17:20:08] <https://gnunet.org/bot/log/guix/2017-12-02#T1567716> <g_bor> Maybe
>>> some invalid charaters leaked in somehow...
>>> [17:20:15] <https://gnunet.org/bot/log/guix/2017-12-02#T1567717> <g_bor> Wait
>>> a sec...
>>> [17:22:51] <https://gnunet.org/bot/log/guix/2017-12-02#T1567719> <g_bor> It
>>> seems, that a lot of packages are broken.
>>> [17:23:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567720> <g_bor> I
>>> laso got that for gettext.
>>> [17:26:26] <https://gnunet.org/bot/log/guix/2017-12-02#T1567721> *
>>> xkapastel has joined #guix
>>> [17:30:38] <https://gnunet.org/bot/log/guix/2017-12-02#T1567723>
>>> <mb[m]1> Can it be ncurses related?
>>> [17:31:12] <https://gnunet.org/bot/log/guix/2017-12-02#T1567724> <g_bor> Might
>>> be...
>>> [17:31:21] <https://gnunet.org/bot/log/guix/2017-12-02#T1567725> <g_bor> did
>>> not checked that.
>>> [17:32:01] <https://gnunet.org/bot/log/guix/2017-12-02#T1567726>
>>> <mb[m]1> g_bor: Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958
>>> makes a difference?
>>> [17:32:24] <https://gnunet.org/bot/log/guix/2017-12-02#T1567727> <g_bor> Ok,
>>> i will try that
>>> [17:36:36] <https://gnunet.org/bot/log/guix/2017-12-02#T1567731> <g_bor> Do
>>> we know about what was the last time it was working?
>>> [17:36:58] <https://gnunet.org/bot/log/guix/2017-12-02#T1567732> <g_bor> We
>>> could do a git bisect on core-updates?
>>> [17:37:13] <https://gnunet.org/bot/log/guix/2017-12-02#T1567733> <g_bor> Do
>>> we have a good commit to start from?
>>> [18:40] <g_bor> Ok, now it's building.
>>> [18:40] <g_bor> I think this will take a time...
>>> [18:41] <g_bor> (guile does take some time :) )
>>> [18:42] <g_bor> I'm trying to help to switch the default icedtea to
>>> icedtea-8, and we'd like to that on core-updates...
>>> [18:43] <g_bor> I've just written on the mailing list, that it would be
>>> nice if we could have substitutes for the core-updates gnu-build-system.
>>> [18:43] <g_bor> That could speed things like this up.
>>> [18:50] <efraim> mb[m]1: just popped in for a second, core-updates is
>>> failing on aarch64 also
>>> [18:50] <efraim> civodul too ^
>>> [18:52] <g_bor> Oh, well.
>>> [18:52] <g_bor> Do we have a bug report on that already?
>>> [18:53] <g_bor> Now I'm trying what mb[m]1 suggested, by reverting the
>>> ncurses commit.
>>> [18:54] <g_bor> It might be easier to track related information in a
>>> bug...
>>>
>>> [20:52] <g_bor> reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 did
>>> not help
>>>
>>> Does anyone know of a last working commit id?
>>>
>>> I'm trying to seen if it's working after last merge of master, but if
>>> someone knows a later point to start investigating the issue would help.
>>>
>>> It would also help, if someone with a more powerful computer could help,
>>> as building on mine is very slow.
>>>
>>>
>>
>

[-- Attachment #2: Type: text/html, Size: 70028 bytes --]

bug#29537: Core updates broken

[Marius Bakke]

[-- Attachment #1.1: Type: text/plain, Size: 394 bytes --]

Gábor Boskovits <boskovits@gmail.com> 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?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-glibc-Don-t-use-full-version-string-in-locale-pa.patch --]
[-- Type: text/x-patch, Size: 4636 bytes --]

From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
From: Marius Bakke <mbakke@fastmail.com>
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 <https://bugs.gnu.org/29537>.

* 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 <https://bugs.gnu.org/29406> 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 <http://sourceware.org/ml/libc-alpha/2013-03/msg00093.html>.
             (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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#29537: Core updates broken

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 6121 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Gábor Boskovits <boskovits@gmail.com> 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 <mbakke@fastmail.com>
> 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 <https://bugs.gnu.org/29537>.
>
> * 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 <https://bugs.gnu.org/29406> 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 <http://sourceware.org/ml/libc-alpha/2013-03/msg00093.html>.
>              (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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#29537: Core updates broken

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]

Marius Bakke <mbakke@fastmail.com> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Gábor Boskovits <boskovits@gmail.com> 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---

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#29537: Core updates broken

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1109 bytes --]

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 <mbakke@fastmail.com>:

> Gábor Boskovits <boskovits@gmail.com> 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?
>
>

[-- Attachment #2: Type: text/html, Size: 1593 bytes --]

bug#29537: Core updates broken

[Ricardo Wurmus]

Marius Bakke <mbakke@fastmail.com> writes:

> Gábor Boskovits <boskovits@gmail.com> 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]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

Ricardo Wurmus <rekado@elephly.net> writes:

> Marius Bakke <mbakke@fastmail.com> writes:
>
>> Gábor Boskovits <boskovits@gmail.com> 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?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#29537: Core updates broken

[Gábor Boskovits]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

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 <mbakke@fastmail.com>:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Marius Bakke <mbakke@fastmail.com> writes:
> >
> >> Gábor Boskovits <boskovits@gmail.com> 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?
>

[-- Attachment #2: Type: text/html, Size: 1846 bytes --]

bug#29537: Core updates broken

[Ludovic Courtès]

Hello!

Marius Bakke <mbakke@fastmail.com> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Marius Bakke <mbakke@fastmail.com> writes:
>>
>>> Gábor Boskovits <boskovits@gmail.com> 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.

Right.  That’s akin to the “effective version” string as defined in
Guile and other packages for cases where you only care about
MAJOR.MINOR.

> 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?

FWIW I think your patches does the right thing.  If we want to reduce
ugliness, we can always add an ‘effective-glibc-version’ property in the
glibc package, but that probably won’t be much less ugly than calling
‘version-major+minor’.

Thoughts?

Ludo’.

bug#29537: Core updates broken

[Ludovic Courtès]

Hi,

Marius Bakke <mbakke@fastmail.com> skribis:

> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
> From: Marius Bakke <mbakke@fastmail.com>
> 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 <https://bugs.gnu.org/29537>.
>
> * 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.

Good catch!  That looks good to me (along with the guix/packages.scm
occurrence you found.)

Thanks!

Ludo’.

bug#29537: Core updates broken

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Hi,
>
> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
>> From: Marius Bakke <mbakke@fastmail.com>
>> 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 <https://bugs.gnu.org/29537>.
>>
>> * 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.
>
> Good catch!  That looks good to me (along with the guix/packages.scm
> occurrence you found.)

OK, pushed!

Now, it would be good to do a final update of glibc so we get the fix
for CVE-2017-15804 and a few other things.  Could you upload a new
tarball for glibc-2.26-105-g0890d5379c.tar.xz?  I'm getting
"0m8cnp2nik0596adwibhl0f3w649m57i3qciqwpwiix7y0sb7vhi" for it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#29537: Core updates broken

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi,
>>
>> Marius Bakke <mbakke@fastmail.com> skribis:
>>
>>> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
>>> From: Marius Bakke <mbakke@fastmail.com>
>>> 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 <https://bugs.gnu.org/29537>.
>>>
>>> * 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.
>>
>> Good catch!  That looks good to me (along with the guix/packages.scm
>> occurrence you found.)
>
> OK, pushed!
>
> Now, it would be good to do a final update of glibc so we get the fix
> for CVE-2017-15804 and a few other things.  Could you upload a new
> tarball for glibc-2.26-105-g0890d5379c.tar.xz?  I'm getting
> "0m8cnp2nik0596adwibhl0f3w649m57i3qciqwpwiix7y0sb7vhi" for it.

I got the same hash but decided to not go with -9 after re-reading
xz(1), which discourages its use due to the memory consumption the
decompressor needs.

The size difference looks reasonable (I used the default, which is -6):

--8<---------------cut here---------------start------------->8---
-rw-r--r-- 1 ludo users 15683872 Dec  5 18:00 glibc-2.26-105-g0890d5379c.tar.xz
-rw-r--r-- 1 ludo users 15309116 Dec  5 18:00 glibc-2.26-105-g0890d5379c.tar.xz-9
--8<---------------cut here---------------end--------------->8---

The file should be on alpha.gnu.org now.

Thanks,
Ludo’.

bug#29537: Core updates broken

[Marius Bakke]

[-- Attachment #1: Type: text/plain, Size: 2063 bytes --]

Ludovic Courtès <ludo@gnu.org> writes:

> Marius Bakke <mbakke@fastmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Hi,
>>>
>>> Marius Bakke <mbakke@fastmail.com> skribis:
>>>
>>>> From 41677631be815d58c36052de7b54d297ad496ec1 Mon Sep 17 00:00:00 2001
>>>> From: Marius Bakke <mbakke@fastmail.com>
>>>> 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 <https://bugs.gnu.org/29537>.
>>>>
>>>> * 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.
>>>
>>> Good catch!  That looks good to me (along with the guix/packages.scm
>>> occurrence you found.)
>>
>> OK, pushed!
>>
>> Now, it would be good to do a final update of glibc so we get the fix
>> for CVE-2017-15804 and a few other things.  Could you upload a new
>> tarball for glibc-2.26-105-g0890d5379c.tar.xz?  I'm getting
>> "0m8cnp2nik0596adwibhl0f3w649m57i3qciqwpwiix7y0sb7vhi" for it.
>
> I got the same hash but decided to not go with -9 after re-reading
> xz(1), which discourages its use due to the memory consumption the
> decompressor needs.
>
> The size difference looks reasonable (I used the default, which is -6):
>
> --8<---------------cut here---------------start------------->8---
> -rw-r--r-- 1 ludo users 15683872 Dec  5 18:00 glibc-2.26-105-g0890d5379c.tar.xz
> -rw-r--r-- 1 ludo users 15309116 Dec  5 18:00 glibc-2.26-105-g0890d5379c.tar.xz-9
> --8<---------------cut here---------------end--------------->8---
>
> The file should be on alpha.gnu.org now.

Thanks!  I got the same hash and pushed an update.  Since this entails a
full rebuild, I also merged in Guile 2.2.3 and updated that as well.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#29537: Core updates broken

[Ludovic Courtès]

Marius Bakke <mbakke@fastmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>> Now, it would be good to do a final update of glibc so we get the fix
>>> for CVE-2017-15804 and a few other things.  Could you upload a new
>>> tarball for glibc-2.26-105-g0890d5379c.tar.xz?  I'm getting
>>> "0m8cnp2nik0596adwibhl0f3w649m57i3qciqwpwiix7y0sb7vhi" for it.
>>
>> I got the same hash but decided to not go with -9 after re-reading
>> xz(1), which discourages its use due to the memory consumption the
>> decompressor needs.
>>
>> The size difference looks reasonable (I used the default, which is -6):
>>
>> --8<---------------cut here---------------start------------->8---
>> -rw-r--r-- 1 ludo users 15683872 Dec  5 18:00 glibc-2.26-105-g0890d5379c.tar.xz
>> -rw-r--r-- 1 ludo users 15309116 Dec  5 18:00 glibc-2.26-105-g0890d5379c.tar.xz-9
>> --8<---------------cut here---------------end--------------->8---
>>
>> The file should be on alpha.gnu.org now.
>
> Thanks!  I got the same hash and pushed an update.  Since this entails a
> full rebuild, I also merged in Guile 2.2.3 and updated that as well.

Excellent, I was going to suggest doing that.  :-)

Thanks!

Ludo’.

PS: Please don’t start an eval today as I’m preparing the release.