From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id mLXtHteO9GB7HAAAgWs5BA (envelope-from ) for ; Sun, 18 Jul 2021 22:28:07 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id AFJ6GteO9GBYUQAAbx9fmQ (envelope-from ) for ; Sun, 18 Jul 2021 20:28:07 +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 E94CA8A40 for ; Sun, 18 Jul 2021 22:28:06 +0200 (CEST) Received: from localhost ([::1]:58930 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m5DOQ-0005DM-2A for larch@yhetil.org; Sun, 18 Jul 2021 16:28:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m5DOM-0005DE-3X for guix-patches@gnu.org; Sun, 18 Jul 2021 16:28:02 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:45938) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m5DOL-0005cz-S2 for guix-patches@gnu.org; Sun, 18 Jul 2021 16:28:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m5DOL-000601-PM for guix-patches@gnu.org; Sun, 18 Jul 2021 16:28:01 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#49517] [PATCH] gnu: txr: Build documentation and update to 265. Resent-From: Kaz Kylheku Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Sun, 18 Jul 2021 20:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49517 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: Guillaume Le Vaillant Cc: "Paul A. Patience" , 49517@debbugs.gnu.org Received: via spool by 49517-submit@debbugs.gnu.org id=B49517.162664005223025 (code B ref 49517); Sun, 18 Jul 2021 20:28:01 +0000 Received: (at 49517) by debbugs.gnu.org; 18 Jul 2021 20:27:32 +0000 Received: from localhost ([127.0.0.1]:57484 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5DNq-0005zH-Ml for submit@debbugs.gnu.org; Sun, 18 Jul 2021 16:27:31 -0400 Received: from omta001.cacentral1.a.cloudfilter.net ([3.97.99.32]:60746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m5DNl-0005z0-G1 for 49517@debbugs.gnu.org; Sun, 18 Jul 2021 16:27:27 -0400 Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id 52tOmKgDdFRDp5DNgmHuLf; Sun, 18 Jul 2021 20:27:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=shaw.ca; s=s20180605; t=1626640040; bh=zbCXkwXchtyFh0e21+lqWp2gof5GGcX71mLuDprxkhA=; h=To:Subject:Date:From:Cc:In-Reply-To:References; b=eGZz32ClXSCQvkFHH/iHFoEYcEMxlgacf7QE3ZuZeUcepItV3p/bxiz464K/srJDi plag/9o/DjPCBC5J+bRnoPJxQDCD/OfYA+PJ/GiZ7FcQH91TwJDWaZZIKYhMbiiJ9E nT9HpA2KNN/89Qo6r/0kQJoAAF0BWAnpcHmPhqrwIhWBk/1DeIxPk4QuGWXamewNXO ka3v6/jrXijx4XpTpJ1A6cB/TXpaXFi6mxt9OQSfwrWcCLDVWgYFSRDg81PgkUgGGB wjoB5INXq24HR/K5PhNaJzNL54gNmFCx0DD5/x5fp5gVBEA27E75lKI0TR1O33huNp ALvEDaGqhK+2A== Received: from kylheku.com ([70.79.163.252]) by cmsmtp with ESMTPA id 5DNem7mNxqevi5DNfm7u7U; Sun, 18 Jul 2021 20:27:19 +0000 X-Authority-Analysis: v=2.4 cv=B4F8bMhM c=1 sm=1 tr=0 ts=60f48ea8 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=e_q4qTt1xDgA:10 a=RqOAJGx8AAAA:8 a=xNf9USuDAAAA:8 a=W4vGv7GogOotNU9VB1kA:9 a=QEXdDO2ut3YA:10 a=SEwjQc04WA-l_NiBhQ7s:22 Received: from www-data by kylheku.com with local (Exim 4.72) (envelope-from ) id 1m5DNe-0003P8-FK; Sun, 18 Jul 2021 13:27:18 -0700 X-PHP-Originating-Script: 501:rcmail.php MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Date: Sun, 18 Jul 2021 13:27:18 -0700 From: Kaz Kylheku In-Reply-To: <874kcr7vt7.fsf@kitej> References: <87o8b1p8k1.fsf@kitej> <3ae1061ea0a61b579c48f9ea7b4f4832@mail.kylheku.com> <96d55c0d8940c64eca79aa4a15a3cb8f@mail.kylheku.com> <874kcr7vt7.fsf@kitej> Message-ID: <598802eda2050f063d01d802edfead99@mail.kylheku.com> X-Sender: kaz@kylheku.com User-Agent: Roundcube Webmail/0.9.2 X-CMAE-Envelope: MS4xfEeU0la6VgD6IAGzAX2xRXBwqVMZK6VDekSuqHjk+uoSnsA9eav3diJoH/8lUgS301D5bpFqjLGw0ts/0xrzXzS1TES7Fd4cMlelctKUs0BNYMDHzaI9 GXBdoOYga1dz3GgzYbfIWpNs2A70TPb1COxQi3Qt67V4L1Vvi/QzwqRYYqD4BsO575wbtLquiLYBODHXYAYH/YWDUaQTgz0ecxcag+VWQIXKtdz3mvpAFw+k X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1626640087; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc: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=vXwkl+Fewta9p5aaQUf3P/1WFHW/2JTYKZQNlXcynmc=; b=UasIA/nl5b5g1AuxKO3NnA7vdV2SsHJtOKC2WIVnTLDV4FDFctbEA4Vnwws/8WviCkBMVw HfgXq0ZI/Op973GUjQjSHESGsnZTSEBfbkO4CsJzOZHpsOSAAqqcPAorHQkJPRBH2DmgY3 24VSya5jybRwZiFMYIj7mV9Ynj0LhptXp/+mUbBT/kvEyXPigwOIGJaLAyVSSxruCckSvJ bXtnOG2ug1y6m9W5sd59jzTGm4JU59xKvgGfPFufLpKsbGHDh6LVVnrNFKgrIuPgTft9Vv RyzBtpRFsEqEJrwTvEyVyWz/TTwySOAXWW145ghhPPSH0q+7e+x28uQjoCT8zw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1626640087; a=rsa-sha256; cv=none; b=Deu74P+FpXAmX6kzU3nfRt5QKSWD9KMMl2GoeOO3DjfeKdbIWyY206xrgC/zFoXJcqFAz8 3ScdozpFKEkX/mGmt+aQMj91UaIRJFomiDpkNHncPwr5IUpGje4Kq6J33JNvECSgKuE0n2 afR9FOQok4OrEPz3X5QUlSrDYXJLSi7sYYbbeTE85HIkuc+1hza5QIS80vvnxx5jlEh00T 0Jox/lJOe8fmgvrNyeWs2ar7Q+6uX/D+Pj1aUWd0+U/yhtRzdPbHHFvHVU47hHWnOoe1Jg sBN8YVLJSe+PeK6h3bNygUpCZdVCYVeDTTViUYs4j94IKSnWWz6QKI7rumVSmA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=shaw.ca header.s=s20180605 header.b=eGZz32Cl; dmarc=fail reason="SPF not aligned (relaxed)" header.from=kylheku.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Spam-Score: -1.31 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=shaw.ca header.s=s20180605 header.b=eGZz32Cl; dmarc=fail reason="SPF not aligned (relaxed)" header.from=kylheku.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: E94CA8A40 X-Spam-Score: -1.31 X-Migadu-Scanner: scn0.migadu.com X-TUID: WEO40RhUV/y+ On 2021-07-18 03:36, Guillaume Le Vaillant wrote: > Hi Kaz, >=20 > I tried your patch and it doesn't fix all the timestamps in the > environment used to build Guix packages: > - Timestamps have the "YYYY-MM-DDTHH:MM:SSZ" format instead of > "YYYY-MM-DDTHH:MM:SS+00:00" > - There are two "...Date(D:YYYYMMDDHHMMSSZ..." timestamps after the=20 > XML > block, although SOURCE_DATE_EPOCH is set to 1 in the environment These are precisely the entries I was referring to in my other post. In the Ubuntu environment, these are following SOURCE_DATE_EPOCH. In fact, all the dates follow SOURCE_DATE_EPOCH. Even with my hack commented out, if we do this: $ SOURCE_DATE_EPOCH=3D0 make txr-manpage.pdf ./txr checkman.txr txr.1 tbl txr.1 | pdfroff -ww -man --no-toc - > txr-manpage.pdf ./pdfroff-eCdDwXuD8U/pdf29977.cmp:1: warning: macro `pdfhref' not=20 defined txr.1:36: warning: number register `M2' not defined # [ $SOURCE_DATE_EPOCH ] && ./txr pdf-clobber-stamps.tl || true the resulting dates are all set to 1970-01-01: $ strings txr-manpage.pdf | grep -E 'Mod|Crea' 1970-01-01T00:00= :00Z 1970-01-01T00:00:00Z groff version=20 1.22.3 /CreationDate(D:19700101000000Z00'00') /ModDate(D:19700101000000Z00'00') /Creator(groff version 1.22.3)>>endobj Moreover, the uuid: strings are not changing between repetitions. Either Ubuntu has a different upstream for these tools, or else they=20 have some patches (which would be worth stealing instead of repeating the=20 work). Moreover, if Ubuntu has patches for this, it might be getting them from Debian. > With the following modified 'pdf-clobber-stamps.tl' the document=20 > becomes > reproducible with Guix (but probably not in some other environments, > depending on the timezone format): This is interesting, not to mention an annoying variation. I wonder where this timezone format is coming from? It doesn't seem to be any local variable under LC_TIME. It's also weird how the timezone is expressed with a colon in the Ubuntu build, as -07:00. I don't see anything in strftime for that, looking at the latest Glibc documentation online. In the Ghostscript code it seems that the latter dates: /CreationDate and all, are the source of the values put into the XML. The /CreationDate is being printed using a gs_sprintf call. Here is the link to the Debian repo, inside a function called=20 pdf_image_finish_file: https://sources.debian.org/src/ghostscript/9.53.3%7Edfsg-7/devices/gdevpdfi= mg.c/?hl=3D670#L753 gs_sprintf(CreationDate,=20 "(D:%04d%02d%02d%02d%02d%02d%c%02d\'%02d\')", tms.tm_year + 1900, tms.tm_mon + 1, tms.tm_mday, tms.tm_hour, tms.tm_min, tms.tm_sec, timesign, timeoffset / 60, timeoffset % 60); I found the code which converst the date with the colon in the timezone, the function pdf_xmp_convert_time: https://sources.debian.org/src/ghostscript/9.53.3%7Edfsg-7/devices/vector/g= devpdfe.c/#L222 It looks the same as in the ArtifexSoftware ghostpd upstream. It is=20 ad-hoc code not using strftime, which puts in the colon. This behavior is conditional depending on the input, though. There is a case in which it puts in a Z and terminates, resulting (I am guessing) in the format seen on Guix: dt[19] =3D buf[14]; /* designator */ if (dt[19] =3D=3D 'Z') return 20; The pdf_image_finish_function writes a Z if it is compiled with #ifdef=20 CLUSTER. This CLUSTER compile-time switch has to do with some "cluster testing"=20 that requires reproducible files. It will also write a Z if it finds that the time offset is zero: #ifdef CLUSTER memset(&t, 0, sizeof(t)); memset(&tms, 0, sizeof(tms)); timesign =3D 'Z'; timeoffset =3D 0; #else time(&t); tms =3D *gmtime(&t); tms.tm_isdst =3D -1; timeoffset =3D (int)difftime(t, mktime(&tms)); /* tz+dst in=20 seconds */ timesign =3D (timeoffset =3D=3D 0 ? 'Z' : timeoffset < 0 ? '-' : '= +'); timeoffset =3D any_abs(timeoffset) / 60; tms =3D *localtime(&t); #endif Aha, this may be what is going on in the Guix build: that the time=20 offset has been set to zero and so the 'Z' character is written; then the conversion function to the other date format writes a 'Z' and quits. I don't see where this code reacts to SOURCE_DATE_EPOCH like I'm seeing on Ubuntu; maybe I'm looking at the wrote branch of the Debian repo, or it really is Ubuntu who did that? In any case, if we end up needing any aspect of my hack, I think I can=20 make it account for all the variations we can expect to see out of this code. Cheers ...