From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor?= Boskovits Subject: bug#29537: Core updates broken Date: Sun, 3 Dec 2017 09:57:14 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113ecd3ac15cac055f6bc9ae" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48482) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLQ6A-0001yI-3m for bug-guix@gnu.org; Sun, 03 Dec 2017 03:58:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLQ66-0005AG-To for bug-guix@gnu.org; Sun, 03 Dec 2017 03:58:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:33738) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLQ66-00059k-N8 for bug-guix@gnu.org; Sun, 03 Dec 2017 03:58:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eLQ66-0000Vo-BQ for bug-guix@gnu.org; Sun, 03 Dec 2017 03:58:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 29537@debbugs.gnu.org --001a113ecd3ac15cac055f6bc9ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=C3=A1bor Boskovits : > ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a is the first bad commit. > > 2017-12-03 9:41 GMT+01:00 G=C3=A1bor Boskovits : > >> 8dd35a0e2 is good >> >> >> 2017-12-02 21:12 GMT+01:00 G=C3=A1bor 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 d= oes >>> 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=3Dglibc.git;a=3Dcommitdiff;h=3D665ce88d68fd13c5c... >>> >>> and https://sourceware.org/git/?p=3Dglibc.git;a=3Dcommitdiff;h=3Ddc258= ce6 >>> 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 exact same issue :-) >>> [17:13:45] >>> g_bor: Yes, I'm currently trying to track it down. >>> [17:14:36] I've >>> also seen it on python-boot0, slightly different message. >>> [17:14:55] Can >>> this be locale related? >>> [17:15:05] I >>> have hu_HU.utf8 here. >>> [17:16:04] * >>> civodul has quit (Read error: Connection reset by peer) >>> [17:17:26] mb[m]1: >>> can I be of assistance? >>> [17:18:19] * >>> civodul has joined #guix >>> [17:18:42] >>> g_bor: The failure happens in the build container which uses a >>> fixed locale (C?). >>> [17:19:17] Ok, >>> then it's not that. >>> [17:19:38] It >>> just seemd to be some character conversion error... >>> [17:20:08] Maybe >>> some invalid charaters leaked in somehow... >>> [17:20:15] Wait >>> a sec... >>> [17:22:51] It >>> seems, that a lot of packages are broken. >>> [17:23:01] I >>> laso got that for gettext. >>> [17:26:26] * >>> xkapastel has joined #guix >>> [17:30:38] >>> Can it be ncurses related? >>> [17:31:12] Might >>> be... >>> [17:31:21] did >>> not checked that. >>> [17:32:01] >>> g_bor: Can you see if reverting 667082d59104d4b964dce878f5e8c0= f8ad1be958 >>> makes a difference? >>> [17:32:24] Ok, >>> i will try that >>> [17:36:36] Do >>> we know about what was the last time it was working? >>> [17:36:58] We >>> could do a git bisect on core-updates? >>> [17:37:13] Do >>> we have a good commit to start from? >>> [18:40] Ok, now it's building. >>> [18:40] I think this will take a time... >>> [18:41] (guile does take some time :) ) >>> [18:42] I'm trying to help to switch the default icedtea to >>> icedtea-8, and we'd like to that on core-updates... >>> [18:43] 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] That could speed things like this up. >>> [18:50] mb[m]1: just popped in for a second, core-updates is >>> failing on aarch64 also >>> [18:50] civodul too ^ >>> [18:52] Oh, well. >>> [18:52] Do we have a bug report on that already? >>> [18:53] Now I'm trying what mb[m]1 suggested, by reverting the >>> ncurses commit. >>> [18:54] It might be easier to track related information in a >>> bug... >>> >>> [20:52] 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. >>> >>> >> > --001a113ecd3ac15cac055f6bc9ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Reverting=C2=A0ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a wo= rks. I'm sure it is not optimal, but for now I will go with it.

2017= -12-03 9:45 GMT+01:00 G=C3=A1bor Boskovits <boskovits@gmail.com><= /span>:
ee3ebf1a357bd4eb= 36a2fa1790a7b549cffb305a is the first bad commit.

2017-12-03 9:41 GMT+01:00 G=C3=A1bor Boskovits <boskovits@g= mail.com>:
=C2=A08dd35a0e2 is good


2017-12-02 21:12 GMT+01:00 G=C3=A1bo= r Boskovits <boskovits@gmail.com>:
It seems, that we have a breakage in current co= re-updates. m4, gettext, and at least a few other packages fail to build.
We had a discussion about that on irc, here are the impor= tant points:

[09:34:53]* g_bor has jo= ined #guix
[09:3= 4:58]<g_bor&= gt;Hello guix!
[09:37:37]= <g_bor>I just tried to bu= ild 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 l= ike it's locale related, I'm on hu_HU.UTF-8
[09:38:03]<g_bor>I'm tring this now on master to see if the = problem persists.
[09:38:10]A= nyone seen that?
= <= td class=3D"m_5047356837374275723m_4416446150629773212m_5426165614840940611= gmail-bot-log-time" style=3D"padding:0.3em 0.5em">[16:55:27]<civodul>
[16:46:05]<civodul>mb[m]1: you were right about the = failing installation tests
[16:46:16]<civodul>it did work a couple of days ago though, so there's hope
[16:47:16]<mb[m]1>civodul: Any idea what caused = it? Haven't been paying attention lately.
[16:47:24]* kristofer has joined #= guix
[16:53:03]= <civodul>= mb[m]1: no idea = yet, let's see
[16:54:11]&l= t;mb[m]1>I do= n't understand why core-updates is failing. I've bisected glibc dow= n to the first two commits on the 2.26 branch, and also tried reverting the= libatomic-ops update.
[16:54:35]<civodul>[16:54:41]<civodul>= well maybe i should focus on one thing at a time :-)
[16:54:46]<mb[m]1>So the culprit is likely one of these:= =C2=A0https://sourceware.org/git/= ?p=3Dglibc.git;a=3Dcommitdiff;h=3D665ce88d68fd13c5c...=C2=A0and=C2= =A0https://sourceware.org/git/?p= =3Dglibc.git;a=3Dcommitdiff;h=3Ddc258ce62ae0bbb45...
* jonsg= er has joined #guix
[16:55:31]<mb[m]1>https://paste.debian.net/998765/
[16:55:36]you'll find yourself be= ing a libc hacker without noticing
[16:55:41]<mb[m]1>Hehe.
[16:56:24]&l= t;civodul>in = this case it's the 'configure' file that leads to a decoding er= ror
[16:56:28]= <civodul>= could you check = its encoding?

<= td class=3D"m_5047356837374275723m_4416446150629773212m_5426165614840940611= gmail-bot-log-time" style=3D"padding:0.3em 0.5em">[16:57:52]= [17:00:57]<= tr class=3D"m_5047356837374275723m_4416446150629773212m_5426165614840940611= gmail-bot-log-nick-even m_5047356837374275723m_4416446150629773212m_5426165= 614840940611gmail-odd" style=3D"background-color:transparent;border-width:1= px 0px;border-style:solid;border-color:rgb(253,253,253);padding:0.1em 0.6em= ">[17:14:36]<= td class=3D"m_5047356837374275723m_4416446150629773212m_5426165614840940611= gmail-bot-log-time" style=3D"padding:0.3em 0.5em">[17:18:42]=
<mb[m]1>I don't currently have the file= s. 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]<mb[m]1>I unpacked the m4 source and ran `file` on it:
<mb[m]1>configure: POSIX shell script, UTF-= 8 Unicode text executable
[17:01:24]<civodul>so it could be an issue with iconv in the new libc
[17:06:59]* ryanwatkins = has joined #guix
[17:11:08]<g_bor>he= llo!
[17:11:18]= <g_bor>Anyone seen this?<= /td>
[17:11:30]= <g_bor>It's on core-u= pdates:
[17:11:= 51]<g_bor>= ;starting phase = `patch-usr-bin-file' Backtrace: 16 (primitive-load "/gnu/store/4jf= 0jcpvjn6r2warav5xmxhmddf?") In ice-9/eval.scm: 191:35 15 (_ _) In= srfi/srfi-1.scm: 863:16 14 (every1 #<procedure 9b0b40 at /gnu/store/yif= qwmdxc4pmd?> ?) In /gnu/store/yifqwmdxc4pmdpm73diq03lqkprnrizn-modu= le-import/guix/build/gnu-build-system.scm: 711:27 13 (_ _) 171:4 12 (p= atch-usr-bin-file #:native-inputs _ #:inputs _ # _) In srfi/srfi
[17:13:38]<civodul>g_bor: mb[m]1 was just reporti= ng the exact same issue :-)
[17:13:45]<mb[m]1>g_bor: Yes, I'm currently trying to track it down.
<g_bor>I've also seen it on python-boot= 0, slightly different message.
[17:14:55]<g_bor>Can this be locale related?
[17:15:05]<g_bor>I have hu_HU.utf8 here.
[17:16:04]* civodul has quit (Read error: Conne= ction reset by peer)
[17:17:26]<g_bor>mb= [m]1: can I be of assistance?
[17:18:19]* civodul has joined #guix
<mb[m]1>g_bor: The failure happens in the b= uild container which uses a fixed locale (C?).
[17:19:17]<g_bor>Ok, then it's not that.
[17:19:38]<g_bor>It just seemd to be some character conver= sion error...
[1= 7:20:08]<g_b= or>Maybe some= invalid charaters leaked in somehow...
[17:20:15]<g_bor>Wait a sec...
[17:22:51]<g_bor>It seems, that a lot of packages are broken.
[17:23:01]<g_bor>I laso got that for gettext.
[17:26:26]* xka= pastel has joined #guix
[17:30:38]<mb[m]1>Can it be ncurses related?
[17:31:12]<g_bor>Might be...
[17:31:21]<= ;g_bor>did no= t checked that.
= [17:32:01]<m= b[m]1>g_bor: = Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 make= s a difference?
[17:32:24]<= g_bor>Ok, i w= ill try that
[18:40]=C2= =A0<g_bor> Ok, now it's building.
=
[18:40]=C2=A0<g_bor> I think this will take a time...
[18:41]=C2=A0= <g_bor> (guile does take some time :) )
[18:42]=C2=A0= <g_bor> I'm trying to help to switch th= e default icedtea to icedtea-8, and we'd like to that on core-updates..= .
[18:43]= =C2=A0<g_bor> I've just written on the = mailing list, that it would be nice if we could have substitutes for the co= re-updates gnu-build-system.
[18:43]=C2=A0<g_bor> Th= at could speed things like this up.
[18:50]=C2=A0<efraim> mb[m]1: just popped in for a second, core-updates is fai= ling on aarch64 also
[18:50]=C2=A0<efraim&= gt; civodul too ^
[18:52]=C2=A0<g_bor> Oh, well.
[18:52]=C2=A0<= /span><g_bor> Do we have a bug report on that alre= ady?
[18:5= 3]=C2=A0<g_bor> Now I'm trying what mb[= m]1 suggested, by reverting the ncurses commit.
[18:54]=C2=A0<g_bor<= /span>> It might be easier to track related information in a bug.= ..

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

Does anyone kn= ow 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= .




--001a113ecd3ac15cac055f6bc9ae--
[17:36:36]<g_bor>Do we know about what was the last time it= was working?
[17:36:58]&l= t;g_bor>We co= uld do a git bisect on core-updates?
[17:37:13]<g_bor>Do we have a good commit to start from?