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