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:41:36 +0100 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c058af6daeb39055f6b91a0" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45497) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLPqf-0004W0-LS for bug-guix@gnu.org; Sun, 03 Dec 2017 03:42:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLPqc-00037y-A0 for bug-guix@gnu.org; Sun, 03 Dec 2017 03:42:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:33730) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLPqc-00037M-1M for bug-guix@gnu.org; Sun, 03 Dec 2017 03:42:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eLPqb-00009L-M7 for bug-guix@gnu.org; Sun, 03 Dec 2017 03:42:01 -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 --94eb2c058af6daeb39055f6b91a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 doe= s > 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=3D > dc258ce62ae0bbb45... > > [16:55:27] * > jonsger has joined #guix > [16:55:31] = civodul: > "m4" and a few others fail like this: https://paste.debian.net/998765/ > [16:55:36] you'll > find yourself being a libc hacker without noticing > [16:55:41] > Hehe. > [16:56:24] in > this case it's the 'configure' file that leads to a decoding error > [16:56:28] could > you check its encoding? > > [16:57:52] = I > don't currently have the files. But I had built much further before the > glibc update (with the C++ fixes only). > [16:57:56] * > jonsger has joined #guix > [17:00:55] = I > unpacked the m4 source and ran `file` on it: > [17:00:57] = configure: > POSIX shell script, UTF-8 Unicode text executable > [17:01:24] so > it could be an issue with iconv in the new libc > [17:06:59] * > ryanwatkins has joined #guix > [17:11:08] > hello! > [17:11:18] = Anyone > seen this? > [17:11:30] = It's > on core-updates: > [17:11:51] = starting > phase `patch-usr-bin-file' Backtrace: 16 (primitive-load "/gnu/store/4jf0= jcpvjn6r2warav5xmxhmddf?") > In ice-9/eval.scm: 191:35 15 (_ _) In srfi/srfi-1.scm: 863:16 14 (every1 > # ?) In /gnu/store/ > yifqwmdxc4pmdpm73diq03lqkprnrizn-module-import/guix/build/gnu-build-syste= m.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. > > --94eb2c058af6daeb39055f6b91a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A08dd35a0e2 is good


2017-12-02 21:12 GMT+01:00 = G=C3=A1bor Boskovits <boskovits@gmail.com>:
It seems, that we have a breakage in c= urrent 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]<g_bor>Hello guix!
[09:37:37]<g_bor>I just tried to build something no core-updates and m4 and python-bo= ot0 does not build, I get a message that a decoding error occured in except= ion 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 pr= oblem persists.
[09:38:10]<g_bor>Anyone seen that?
[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]<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 upd= ate.
[16:54:35]= <civodul>how's it failing?
[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=3Dcomm= itdiff;h=3D665ce88d68fd13c5c...=C2=A0and=C2=A0https://sourceware.org/git/?p=3Dglibc.git;a=3Dco= mmitdiff;h=3Ddc258ce62ae0bbb45...
[16:55:27]* jonsger has jo= ined #guix
[16:55:31]<mb[m]1>civodul: "m4" and a few = others fail like this:=C2=A0http= s://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= 9; file that leads to a decoding error
[16:56:28]<civodul>could you= check its encoding?

starting phase `patch-usr-bin-file' Backtrace: 16 (primitive-= load "/gnu/store/4jf0jcpvjn6r2warav5xmxhmddf?") In ice-9/eva= l.scm: 191:35 15 (_ _) In srfi/srfi-1.scm: 863:16 14 (every1 #<procedure= 9b0b40 at /gnu/store/yifqwmdxc4pmd?> ?) In /gnu/store/yifqwmdxc4pm= dpm73diq03lqkprnrizn-module-import/guix/build/gnu-build-system.sc= m: 711:27 13 (_ _) 171:4 12 (patch-usr-bin-file #:native-inputs _ #:inputs = _ # _) In srfi/srfi[17:16:04]<= td class=3D"m_5426165614840940611gmail-bot-log-nick" style=3D"padding:0.3em= 0.5em"><g_bor>
[16:57:52]<mb[m]1>= I don't currently have the files. But I had built much further before t= he glibc update (with the C++ fixes only).
[16:57:56]* jonsger ha= s joined #guix
[17:00:55]<mb[m]1>I unpacked the m4 source and ran `= file` on it:
[17:00:57]<mb[m]1>configure: POSIX shell script, UTF-8 Unic= ode text executable
[17:01:= 24]<civodul>so it could be an issu= e with iconv in the new libc
[17:06:= 59]* ryanwatkins has joined #gu= ix
[17:11:08]hello!
[17:11:18]<g_bor>Anyone seen = this?
[17:11:30]<g_bor>It's on core-updates:
[17:11:51]<g_bor>
[17:13:38]<civodul>g_bor: mb[m]1 was just repor= ting the exact same issue :-)
[17:= 13:45]<mb[m]1>g_bor: Yes, I'm= currently trying to track it down.
[17:14:36]<g_bor>I've also = seen it on python-boot0, slightly different message.
[17:14:55]<g_bor>Ca= n this be locale related?
[17:15:= 05]<g_bor>I have hu_HU.utf8 here.<= /td>
* civodul has quit (Read error: Connection reset by pee= r)
[17:17:26]= <g_bor>mb[m]1: can I be of assistance?
= [17:18:19]* civodul has joined #guix
[17:18:42]<mb[m]1>g_bor: The fa= ilure 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 conversion error...
[17:20:08]<g_bor>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 gett= ext.
[17:26:26]* xkapastel 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 not checked that.
[17:32:01]<mb[m]1>g_bor: Can = you see if reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 makes a = difference?
[17:32:24]Ok, i will try that
[17:36:36]<g_bor>Do we know about what was the last time it w= as working?
[17:36:58]<g_bor>We could do a git bisect on core-u= pdates?
[17:37:13]Do we have a good commit to start from?
[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 switc= h the default icedtea to icedtea-8, and we'd like to that on core-updat= es...
[18:43]=C2=A0<g_bor> I've ju= st written on the mailing list, that it would be nice if we could have subs= titutes for the core-updates gnu-build-system.
[18:43]=C2= =A0<g_bor> That could speed things like this up.
[18:50]=C2=A0<efraim> mb[m]1: just popped in for a second, c= ore-updates is failing on aarch64 also
[18:50]=C2=A0&l= t;efraim&= gt; civodul too ^
[18:52]=C2=A0<g_bor>= Oh, well.
[18:52]=C2=A0<g_bor> Do we = have a bug report on that already?
[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 information in a bug...

[2= 0:52]=C2=A0<g_bor> reverting 667082d59104d4b964dce878f5e8c0f8ad1be958 did not he= lp

Does anyone know of a last working commit i= d?

I'm trying to seen if it's working afte= r last merge of master, but if someone knows a later point to start investi= gating the issue would help.

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


--94eb2c058af6daeb39055f6b91a0--