From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AM7WI38I12BpUAEAgWs5BA (envelope-from ) for ; Sat, 26 Jun 2021 12:59:11 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id qKuHH38I12BpKAAA1q6Kng (envelope-from ) for ; Sat, 26 Jun 2021 10:59:11 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id ABF38C0FE for ; Sat, 26 Jun 2021 12:59:10 +0200 (CEST) Received: from localhost ([::1]:38218 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lx61l-0003Xb-OC for larch@yhetil.org; Sat, 26 Jun 2021 06:59:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46076) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lx61e-0003XL-NY for bug-guix@gnu.org; Sat, 26 Jun 2021 06:59:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:35635) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lx61e-0000qN-BQ for bug-guix@gnu.org; Sat, 26 Jun 2021 06:59:02 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lx61e-0004iY-5K for bug-guix@gnu.org; Sat, 26 Jun 2021 06:59:02 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#49145: Cannot build Guix (Texinfo failure) Resent-From: Julien Lepiller Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Sat, 26 Jun 2021 10:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49145 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: 49145@debbugs.gnu.org, hiphish@posteo.de X-Debbugs-Original-To: bug-guix@gnu.org, HiPhish , 49145@debbugs.gnu.org Received: via spool by submit@debbugs.gnu.org id=B.162470512018101 (code B ref -1); Sat, 26 Jun 2021 10:59:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Jun 2021 10:58:40 +0000 Received: from localhost ([127.0.0.1]:47181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lx61H-0004ht-Fu for submit@debbugs.gnu.org; Sat, 26 Jun 2021 06:58:39 -0400 Received: from lists.gnu.org ([209.51.188.17]:53954) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lx61D-0004hi-4o for submit@debbugs.gnu.org; Sat, 26 Jun 2021 06:58:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45972) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lx61B-0003Vn-9n for bug-guix@gnu.org; Sat, 26 Jun 2021 06:58:34 -0400 Received: from lepiller.eu ([2a00:5884:8208::1]:35074) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lx616-0000Tp-S8 for bug-guix@gnu.org; Sat, 26 Jun 2021 06:58:33 -0400 Received: from lepiller.eu (localhost [127.0.0.1]) by lepiller.eu (OpenSMTPD) with ESMTP id da6db867; Sat, 26 Jun 2021 10:58:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=lepiller.eu; h=date :in-reply-to:references:mime-version:content-type :content-transfer-encoding:subject:to:from:message-id; s=dkim; bh=pDa1BEORdbIxn186tZ9v/UOIaFMsBQ8Y9PoG0cezU7M=; b=K/MHYXoZawkq ibstDMlFea3ccuI4iaPWnxpDlETkC1/QRWWanVih2tuKx1HZd2JT62FW3UtoSlwY g1vylJhFguqaevRdVT/tjg66LLgwFwmfC00mdWF/7+8YHCnHPsvCK201ywKXck0f BcuMWdswD8zacKcW/3+Vj0s2savgs13tlwQoMP660xj1dxR+FyYgA+9N300NYZFm V60r0gbTYpP0RgaGnuudwtnEUdydu5IiHJL4ZKhUHYwR/3UBUd5cT5A+Mad3vWBl 8FCKK8IR2IP0at+6yh0qCuM7kO8yAzEhM+f91nnTGCS4mWQV+Lb79Awgv87zlfBh 7ckhFUNK0Q== Received: by lepiller.eu (OpenSMTPD) with ESMTPSA id 91cb9f22 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO); Sat, 26 Jun 2021 10:58:21 +0000 (UTC) Date: Sat, 26 Jun 2021 06:58:03 -0400 User-Agent: K-9 Mail for Android In-Reply-To: <4350643.LvFx2qVVIh@titan> References: <4629869.GXAFRqVoOG@titan> <4350643.LvFx2qVVIh@titan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----LS5AWQX8I7PLFWJOMH2LS6WP891GZK" Content-Transfer-Encoding: 7bit From: Julien Lepiller Message-ID: <10D07CE8-83B9-4CC7-A881-9A29EA908278@lepiller.eu> Received-SPF: pass client-ip=2a00:5884:8208::1; envelope-from=julien@lepiller.eu; helo=lepiller.eu X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1624705151; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=FwnL4q/IMuuKlwYJmxYGxLlBC3J85eyiZzAkHX/OUg4=; b=b7O8derJ73eGneA6zuzCwJzn3FbllGQ4BfF3n1fzXXQQ3E2B00Yk5BIjP9A9XTUIW2g8nd n6akH2EGwc9oqGxKNi3EnPcH53dDmqGLrlkmEjmJnLnaP/xnKjmIMePtnM7r/9gw4BDuj1 nq5myMJ+zNgI9JBXJ7AoOFe1ZF81e0qF8WbKaTx1TXWt374ILSoDG8QZtFY9cVt7kjLb3U u/8M31oxFagpIsyYBFa0MUdrQU1HnkVFWguoRrj81743PtTQSG7H8LjkXM/7t0ugtIG++a 3HZG9nHuW90w29peS8KVRktQnS2tKBaNyfqAXwU/GeOJVZEpFkcSA7uMs8YJNQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1624705151; a=rsa-sha256; cv=none; b=daXkFWhkX7EDWn00bSMFFwbBZI/XX1OYw+a0HnsJRtSnANqBgLm5b8bSE1bewDrvxUirwZ OeRY3rOpcWxB16XxRRH/dKUm+jnOqsvDhm36syvu+ixMw2SoIXIwubJnrVk+lvT+6nu+nL kWlENC0GfPwBvYWEZk+4ZIWKD5LnFcm78GgY56Ol5FRlKrJeorGYiNcwOf+YvEB2kH6M/G mLZyPpowvi7o8OIdxccyZN/aB4Ke09NNyzNEeQkKbVsrfOv8XSzRKCK8OuUG58lwywSqFU 6uTtPRORN0jz8Sh6x1ovSXgnrP1NR8TeFHdV80M3VY/xg4enfClP9pyTDfiHeA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lepiller.eu header.s=dkim header.b="K/MHYXoZ"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Spam-Score: -1.33 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=lepiller.eu header.s=dkim header.b="K/MHYXoZ"; dmarc=fail reason="SPF not aligned (relaxed)" header.from=lepiller.eu (policy=none); spf=pass (aspmx1.migadu.com: domain of bug-guix-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=bug-guix-bounces@gnu.org X-Migadu-Queue-Id: ABF38C0FE X-Spam-Score: -1.33 X-Migadu-Scanner: scn1.migadu.com X-TUID: LcMs4pdooTzy ------LS5AWQX8I7PLFWJOMH2LS6WP891GZK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The process for translating the manual is as follows: we use po4a to replac= e English strings with the target language's strings=2E At this point, the = translation contains English node names=2E Then, the Makefile is supposed t= o replace these with the actual translation of the node names (that way eve= n untranslated strings refer to the correct nodes)=2E However, it seems tha= t in your case, that process did not go well=2E I'd rather try to fix the issue than avoid it, but you can always remove r= eferences to the translated manual from doc/local=2Emk=2E Can you try running the xref command from doc/local=2Emk manually, to see = if it's doing anything wrong? Le 25 juin 2021 18:26:51 GMT-04:00, HiPhish a =C3=A9= crit : >I actually looked into the offending files and I found that they are >only half- >translated=2E Part of them is in German, but some parts are in English, >and the=20 >English parts are referencing English node names, which obviously do >not exist=20 >in the German manual=2E > >I do not need the German manual, is there a way to skip it? A quick >glance=20 >shows the same problem in the Spanish manual as well, and other manuals >are=20 >probably affected as well=2E I don't know why `make` only choked up on >the German=20 >manual though=2E Maybe because that's the first one in alphabetical order >and=20 >`make` did not bother trying the rest? Or could it be because my >machine is in=20 >Germany? The output of the `locale` command is: > > $ locale > LANG=3Den_GB=2EUTF-8 > LC_CTYPE=3D"en_GB=2EUTF-8" > LC_NUMERIC=3D"en_GB=2EUTF-8" > LC_TIME=3D"en_GB=2EUTF-8" > LC_COLLATE=3DC > LC_MONETARY=3D"en_GB=2EUTF-8" > LC_MESSAGES=3D"en_GB=2EUTF-8" > LC_PAPER=3D"en_GB=2EUTF-8" > LC_NAME=3D"en_GB=2EUTF-8" > LC_ADDRESS=3D"en_GB=2EUTF-8" > LC_TELEPHONE=3D"en_GB=2EUTF-8" > LC_MEASUREMENT=3D"en_GB=2EUTF-8" > LC_IDENTIFICATION=3D"en_GB=2EUTF-8" > LC_ALL=3D > >And when inside a pure Guix environment: > > $ locale > LANG=3D > LC_CTYPE=3D"POSIX" > LC_NUMERIC=3D"POSIX" > LC_TIME=3D"POSIX" > LC_COLLATE=3D"POSIX" > LC_MONETARY=3D"POSIX" > LC_MESSAGES=3D"POSIX" > LC_PAPER=3D"POSIX" > LC_NAME=3D"POSIX" > LC_ADDRESS=3D"POSIX" > LC_TELEPHONE=3D"POSIX" > LC_MEASUREMENT=3D"POSIX" > LC_IDENTIFICATION=3D"POSIX" > LC_ALL=3D ------LS5AWQX8I7PLFWJOMH2LS6WP891GZK Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The process for translating the manual is as follo= ws: we use po4a to replace English strings with the target language's strin= gs=2E At this point, the translation contains English node names=2E Then, t= he Makefile is supposed to replace these with the actual translation of the= node names (that way even untranslated strings refer to the correct nodes)= =2E However, it seems that in your case, that process did not go well=2E
I'd rather try to fix the issue than avoid it, but you can always remo= ve references to the translated manual from doc/local=2Emk=2E

Can yo= u try running the xref command from doc/local=2Emk manually, to see if it's= doing anything wrong?

Le 25 juin 2021 18= :26:51 GMT-04:00, HiPhish <hiphish@posteo=2Ede> a =C3=A9crit : 
I actually looked into the offending files and I fou=
nd that they are only half-
translated=2E Part of them is in German, but=
 some parts are in English, and the 
English parts are referencing Engli=
sh node names, which obviously do not exist 
in the German manual=2E
=

I do not need the German manual, is there a way to skip it? A quick gla=
nce 
shows the same problem in the Spanish manual as well, and other man=
uals are 
probably affected as well=2E I don't know why `make` only chok=
ed up on the German 
manual though=2E Maybe because that's the first one=
 in alphabetical order and 
`make` did not bother trying the rest? Or co=
uld it be because my machine is in 
Germany? The output of the `locale` =
command is:

    $ locale
    LANG=3Den_GB=2EUTF-8
    LC_CTYPE=
=3D"en_GB=2EUTF-8"
    LC_NUMERIC=3D"en_GB=2EUTF-8"
    LC_TIME=3D"en=
_GB=2EUTF-8"
    LC_COLLATE=3DC
    LC_MONETARY=3D"en_GB=2EUTF-8"
=
    LC_MESSAGES=3D"en_GB=2EUTF-8"
    LC_PAPER=3D"en_GB=2EUTF-8"
    =
LC_NAME=3D"en_GB=2EUTF-8"
    LC_ADDRESS=3D"en_GB=2EUTF-8"
    LC_TEL=
EPHONE=3D"en_GB=2EUTF-8"
    LC_MEASUREMENT=3D"en_GB=2EUTF-8"
    LC_=
IDENTIFICATION=3D"en_GB=2EUTF-8"
    LC_ALL=3D

And when inside a =
pure Guix environment:

    $ locale
    LANG=3D
    LC_CTYPE=
=3D"POSIX"
    LC_NUMERIC=3D"POSIX"
    LC_TIME=3D"POSIX"
    LC_C=
OLLATE=3D"POSIX"
    LC_MONETARY=3D"POSIX"
    LC_MESSAGES=3D"POSIX"<=
br>    LC_PAPER=3D"POSIX"
    LC_NAME=3D"POSIX"
    LC_ADDRESS=3D"POS=
IX"
    LC_TELEPHONE=3D"POSIX"
    LC_MEASUREMENT=3D"POSIX"
    LC=
_IDENTIFICATION=3D"POSIX"
    LC_ALL=3D





------LS5AWQX8I7PLFWJOMH2LS6WP891GZK--