Bug 9440 - Y2K problem in slrn
Y2K problem in slrn
Product: Red Hat Linux
Classification: Retired
Component: slrn (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Depends On:
  Show dependency treegraph
Reported: 2000-02-14 16:41 EST by Charles R. Anderson
Modified: 2014-03-16 22:12 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-02-14 17:11:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Charles R. Anderson 2000-02-14 16:41:20 EST
After the Y2K rollover, slrn produces this message upon startup:
slrn (Sep 16 1998 00:18:17)

Reading startup file /usr/lib/slrn/slrn.rc.
Reading startup file /home/user/.slrnrc.
Connecting to host news.host ...
Connected to host.  Posting Ok.
Checking for new groups ...
.jnewsrc.time appears corrupt.
I expected to see see: NEWGROUPS yymmdd hhmmss GMT
I will patch the file up for you.

Checking news via active file ...

The .jnewsrc-time file contains:

NEWGROUPS 1000214 212945 GMT

As you can see, the year has rolled over to three digits, confusing slrn.
Slrn fails to "patch the file".  This bug seems to have been fixed in newer
slrn packages that come with Red Hat 6.0 and Red Hat 6.1; those versions
patch the file correctly.  So, the fix would be to backport the latest slrn
package to Red Hat 5.2, and perhaps 4.2 if the bug exists there as well.
Comment 1 Bill Nottingham 2000-02-14 17:11:59 EST
It's fixed in the current release, probably won't be backported.
I believe the main cause is that your news *server* is actually
sending back broken data.

Note You need to log in before you can comment on or make changes to this bug.