Bug 9440 - Y2K problem in slrn
Summary: Y2K problem in slrn
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: slrn   
(Show other bugs)
Version: 5.2
Hardware: All Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-02-14 21:41 UTC by Charles R. Anderson
Modified: 2014-03-17 02:12 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Charles R. Anderson 2000-02-14 21:41:20 UTC
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 22:11:59 UTC
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.