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:45:25 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0551a47e1ae7055f6b9fa5" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLPua-0006D4-0R for bug-guix@gnu.org; Sun, 03 Dec 2017 03:46:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLPuW-00056h-PA for bug-guix@gnu.org; Sun, 03 Dec 2017 03:46:08 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:33734) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLPuW-00056O-JN for bug-guix@gnu.org; Sun, 03 Dec 2017 03:46:04 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eLPuU-0000FJ-6O for bug-guix@gnu.org; Sun, 03 Dec 2017 03:46: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 --94eb2c0551a47e1ae7055f6b9fa5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 do= es >> 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 t= o >> 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=3Ddc258c= e6 >> 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 667082d59104d4b964dce878f5e8c0f8ad1be958 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. >> >> > --94eb2c0551a47e1ae7055f6b9fa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a is the first bad = commit.

= 2017-12-03 9:41 GMT+01:00 G=C3=A1bor Boskovits <boskovits@gmail.com&= gt;:
=C2=A08dd35a= 0e2 is good


2017-12-02 21:12= GMT+01:00 G=C3=A1bor Boskovits <boskovits@gmail.com>:
=
It seems, that we have a br= eakage in current core-updates. m4, gettext, and at least a few other packa= ges 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]<g_bor>Hello = guix!
[09:37:37]= <g_bor>I just tried to build something no core-updates and m4 and pytho= n-boot0 does not build, I get a message that a decoding error occured in ex= ception dispatcher. It seem like 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]<g_bor>Anyone seen that?
[16:47:16]<mb[m]1>[16:54:35]<= /tr>
[16:46:05]<civodul>mb[m]1: you were= right about the failing installation tests
[16:46:16]<civ= odul>it did work a couple of days = ago though, so there's hope
<mb[m]1>civodul: Any idea what caused it? Haven&#= 39;t been paying attention lately.
[16:47:24]* kristofer has joined #guix
[16:53:03]<civod= ul>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 reve= rting the libatomic-ops update.
<civodul>how's it failing?
[16:54:41]well maybe i should = focus on one thing at a time :-)
[16:54:46]<mb[m]1>= ;So the culprit is likely one of thes= e:=C2=A0https://sourceware.org/gi= t/?p=3Dglibc.git;a=3Dcommitdiff;h=3D665ce88d68fd13c5c...=C2=A0and= =C2=A0https://sourceware.org/git/= ?p=3Dglibc.git;a=3Dcommitdiff;h=3Ddc258ce62ae0bbb45...
[16:55:27]* jonsger has joined #guix
[16:55:31]<mb[m]1>ci= vodul: "m4" and a few others fail like this:=C2=A0https://paste.debian.net/998765/
[16:55:36]<civodul>you'= ;ll find yourself being a libc hacker without noticing
[16:55:41]<mb[m]1>Hehe.
[16:56:24]<civodul>in this = case it's the 'configure' file that leads to a decoding error
<= a href=3D"https://gnunet.org/bot/log/guix/2017-12-02#T1567687" id=3D"m_4416= 446150629773212m_5426165614840940611gmail-T1567687" style=3D"color:rgb(0,0,= 136);text-decoration-line:none" target=3D"_blank">[16:56:28]<civodul>could you check its encoding?

<= td class=3D"m_4416446150629773212m_5426165614840940611gmail-bot-log-nick" s= tyle=3D"padding:0.3em 0.5em"><civodul>[17:14:36]= = mb[m]1: can I be of assistance?<= tr class=3D"m_4416446150629773212m_5426165614840940611gmail-bot-log-nick-ev= en m_4416446150629773212m_5426165614840940611gmail-odd" style=3D"background= -color:transparent;border-width:1px 0px;border-style:solid;border-color:rgb= (253,253,253);padding:0.1em 0.6em">
[16:57:52]<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]* jonsger has joined #guix
[17:00:55]<mb[= m]1>I unpacked the m4 source and r= an `file` on it:
[17:00:57]<mb[m]1>configure: POSIX shell script, UTF-8 Unicode text executable<= /td>
[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]<g_bor>hello!
[17:11:18]<g_bor>Any= one seen this?
[17= :11:30]<g_bor>It's on core-updates:
[17:11:51]= <g_bor>starting phase `patch-us= r-bin-file' Backtrace: 16 (primitive-load "/gnu/store/4jf0jcpvjn6r= 2warav5xmxhmddf?") In ice-9/eval.scm: 191:35 15 (_ _) In srfi/srf= i-1.scm: 863:16 14 (every1 #<procedure 9b0b40 at /gnu/store/yifqwmdxc4pm= d?> ?) 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]<civodul>g_bor: mb[m= ]1 was just reporting the exact same issue :-)
[17:13:45]<= mb[m]1>g_bor: Yes, I'm current= ly trying to track it down.
<g_bor>I've also seen it on python-boot0, slightl= y 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 err= or: Connection reset by peer)
[17:17:26]<g_bor>
[17:18:19]* civodul has joined #guix
[17:18:42]<mb[m]1>g_bor: T= he failure happens in the build 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...
[17:20:08]<= /a><g_bor>Maybe some invalid charaters leaked in somehow...
[17:20:15]<g_bor>Wait a= sec...
[17:22:51]<= /td><g_bor>It seems, that a lot of packages are broken.
[17:23:01]<g_bor>I laso got th= at for gettext.
[17:26:26]* xkapastel h= as 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 not checke= d that.
[17:32:01]<= /td><mb[m]1>g_bor: Can you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes a difference?
[17:32:24]<g_bor><= /td>Ok, i will try that
=
[17:36:36]= <g_bor>Do we know about what was the last time it was working?
= [17:36:58]<g_bor>We could do a git bisect on core-updates?
[17:37:13]<g_bo= r>Do we have a good commit to star= t from?
[18:40]=C2=A0<g_bor> Ok, now it's building.
[18:4= 0]=C2=A0<g_bor> I think this will take a time...
[18:41]=C2=A0<g_bor> (guile does take some t= ime :) )
[18:42]=C2=A0<= g_bor> I'm trying to help to switch the default icedte= a 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 cou= ld have substitutes for the core-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 failing on= aarch64 also
[18:50]=C2=A0<efraim> civodul too = ^
[18:52]=C2=A0<g_bor> Oh, well.
[18:52]=C2=A0<g_bor> Do we have a bug report on that alrea= dy?
[18:53]=C2=A0<g_bor<= /span>> Now I'm trying what mb[m]1 suggested, by reverting th= e ncurses commit.
[18:54]=C2=A0<g_bor> It might be easier to track related informat= ion in a bug...
=
[20:52]=C2=A0<= ;g_bor> reverting 667082d59104d4b964dce878f5e= 8c0f8ad1be958 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 mo= re powerful computer could help, as building on mine is very slow.



--94eb2c0551a47e1ae7055f6b9fa5--