GNU bug report logs - #65423
README-install contains invalid/outdated information about 32 bit time_t compared to NEWS in 9.3

Previous Next

Package: coreutils;

Reported by: "Osipov, Michael (IN IT IN)" <michael.osipov <at> siemens.com>

Date: Mon, 21 Aug 2023 10:52:01 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


Message #11 received at 65423 <at> debbugs.gnu.org (full text, mbox):

From: "Osipov, Michael (IN IT IN)" <michael.osipov <at> siemens.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 65423 <at> debbugs.gnu.org
Subject: Re: bug#65423: README-install contains invalid/outdated information
 about 32 bit time_t compared to NEWS in 9.3
Date: Tue, 22 Aug 2023 09:58:49 +0200
On 2023-08-21 21:25, Paul Eggert wrote:
> On 8/21/23 05:51, Osipov, Michael (IN IT IN) via GNU coreutils Bug 
> Reports wrote:
>> in 9.3 year 2038 support with 64 bit time_t was made required [1], 
>> here on HP-UX this is a bit problematic, but that's not the actual 
>> problem. The diff between 9.2 and 9.3 [2] says how this can be fixed 
>> on platforms supporting both 32 and 64 bit, on HP-UX it'd be simply 
>> '+DD64', and how to avoid with "ac_year2038_required=no", but README- 
>> install on master [3] still contains '--disable-year2038' which 
>> obviously does not work. It simply needs to be updated to the content 
>> of [2].
> 
> Sorry, I don't understand. Why does --disable-year2038 not work on HP-UX 
> for bleeding-edge coreutils on Savannah?
> 
> It sounds like you're suggesting that we revert the attached patch, but 
> I don't see how that would be correct as bleeding-edge coreutils/ 
> configure no longer looks at ac_year2038_required.

No need to be sorry ;-), I understand where your confusion comes from 
and mine. I was talking about changes between 9.2 and 9.3 only. Looking 
at the changes you refer are solely on master at [1] and [2] which make 
year 2038 support optional again. So no action is required anymore.

>> I cannot compile everything in 64 bit mode since no one has written 
>> our old applications with portability in mind. It needs to remain 32 
>> bit for now. 
> 
> I suggest compiling coreutils in 64-bit mode now. You can keep compiling 
> your other applications in 32-bit mode. Even though HP-UX's end of life 
> is the end of 2025, it's possible you'll run across a stray HP-UX file 
> today with timestamp after 2038, and basic coreutils apps like 'ls' 
> should work with such files.

I agree, and those are just executables. Regardless of this, HPE says at 
least until end of 2025, it is at the end a business decision and I am 
doing IT, so not my responsibility ;-). I just make it run. The files we 
touch go even back to late 80s.

Please go ahead and close this issue, it will auto-resolve with 9.4.

Michael

[1] 
https://github.com/coreutils/coreutils/commit/ba128e628cfa0dd111cf235d965200d1cdf77f52
[2] 
https://github.com/coreutils/coreutils/commit/3f942cd03fce1a6cda87018306b50f803f08f350#diff-df1edefd8cc0b27219a375d046251a2e9e87fcef6c23767640f12d0b4f784c76L321




This bug report was last modified 1 year and 269 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.