From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.3 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id D3CD41F5AE for ; Wed, 28 Apr 2021 17:36:29 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1B0273970806; Wed, 28 Apr 2021 17:36:14 +0000 (GMT) Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 71D9A393D019 for ; Wed, 28 Apr 2021 17:36:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 71D9A393D019 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: Sc+qRzGjkgTn8ewkmUSFWZhl3k/hhM1tZIQUWQxTPcnoEIpDBeNjFoEImfYK2v5xFNb4jdPqo8 uPWUofncY9pDTPR2hmK6si3HoGmbcFf8ulaaXoLfTnW8w9cp8GiUG8Kpx+ktdNvzMZpI5sP3lW kS4wWNUAw0LxdKWILT3EzIWfBsfOyJUzdiVWx0a3yobsmIntEuSnSOaSHNBLnGNdvjUaDnNBPC ek0t8GGMRLD1T4BvlT957AHsFMpFqXEuE0yUXrCnedmxfwEavzIj3gzkzlBoBykuGXM2I3+T8m jHk= X-IronPort-AV: E=Sophos;i="5.82,258,1613462400"; d="scan'208";a="60614419" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa2.mentor.iphmx.com with ESMTP; 28 Apr 2021 09:36:10 -0800 IronPort-SDR: 0RA938V2HnllTc6gVnZYUpJwDHcP/OA2OsUbkrtjCK5lNJyRnQB+XCM39BjIsEn49eOKTuKD0e UtqVxMHgvuazJua66L5Uhnc9TJYgMNbZz/PVTDEDBBdweKXntCF3raxtCET2Bj7TqTa+Bfk5Aq xhst2e2SwU+IcinZCMvwfM5BGFgPCqWvqtSKb8bYzM0LuPidxFjuRnTUC2x084PHyczqO6hHQX SDupP1wrGyIqxICIlLjlsGuEgwQQFhdGERHbKi+MQimWXrhKjMhxQV72MIEy/UKQv4zCLZyDO5 wlE= Date: Wed, 28 Apr 2021 17:36:05 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Carlos O'Donell Subject: Re: [PATCH v3] Add new C.UTF-8 locale (Bug 17318) In-Reply-To: Message-ID: References: <20210219032748.564216-1-carlos@redhat.com> <87v99xcxzm.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Carlos O'Donell via Libc-alpha Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" On Wed, 28 Apr 2021, Carlos O'Donell via Libc-alpha wrote: > >> diff --git a/localedata/locales/i18n_ctype b/localedata/locales/i18n_ctype > >> index c63e0790fc..c92bb95148 100644 > >> --- a/localedata/locales/i18n_ctype > >> +++ b/localedata/locales/i18n_ctype > >> @@ -26,7 +26,7 @@ fax "" > >> language "" > >> territory "Earth" > >> revision "13.0.0" > >> -date "2020-06-25" > >> +date "2021-02-17" > >> category "i18n:2012";LC_CTYPE > >> END LC_IDENTIFICATION > > > > Those date changes seem spurious. Is this no-op file regeneration > > really needed? > > The protocol is: > > cd localedata/unicode-gen > make install > > The spurious regeneration is not needed, but it's easier to run the > above commands. It gives a date for the last generation for all files > consistently. Is it required to have a date in the file at all? For anything that's generated during the glibc build and ends up installed, we'd avoid having such dates to allow for reproducible builds. As this is a maintainer generation of something checked in as a source file, rather than regenerated from makefile dependencies in a normal glibc build, that doesn't strictly apply, but I still think it would be a good idea to avoid having dates or other such non-reproducible output in maintainer-generated files as far as possible. -- Joseph S. Myers joseph@codesourcery.com