Re: [PATCH v3] Add new C.UTF-8 locale (Bug 17318)

[Carlos O'Donell via Libc-alpha <libc-alpha@sourceware.org>]

On 4/28/21 1:36 PM, Joseph Myers wrote:
> 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.
 
Good point. Let me remove the dates from the generation of files as a first
patch.

-- 
Cheers,
Carlos.