From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 CC: Florian Weimer , Carlos O'Donell via Libc-alpha 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-Spam-Status: No, score=-3127.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 28 Apr 2021 17:36:13 -0000 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