Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228043 Summary: ??? 64bit sa-update.1 manpage timestamp differs from 32bit? Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: spamassassin AssignedTo: wtogami@xxxxxxxxxx ReportedBy: wtogami@xxxxxxxxxx CC: fedora-perl-devel- list@xxxxxxxxxx,felicity@xxxxxxxxx,jm@xxxxxxxxxx,parkerm @pobox.com,reg+redhat@xxxxxxxxxx,wtogami@xxxxxxxxxx Odd minor problem... low priority. /usr/share/man/man1/sa-update.1.gz differs by the following unidiff between the 32bit and 64bit architecture builds of spamassassin. --- 32 2007-02-09 12:46:19.000000000 -0500 +++ 64 2007-02-09 12:46:10.000000000 -0500 @@ -129,7 +129,7 @@ .\" ======================================================================== .\" .IX Title "SA-UPDATE 1" -.TH SA-UPDATE 1 "2006-07-30" "perl v5.8.5" "User Contributed Perl Documentation" +.TH SA-UPDATE 1 "2007-01-22" "perl v5.8.5" "User Contributed Perl Documentation" .SH "NAME" sa\-update \- automate SpamAssassin rule updates .SH "SYNOPSIS" This appears to be the only difference in version 3.1.7. Notice that the 32bit version retained the original source timestamp, while the 64bit version somehow decided to differ in this behavior by changing the timestamp to the build date. The above example is 3.1.7 built on RHEL4, but this persists through perl-5.8.8 in FC7 too. While this appears to create a multilib conflict, in practice this is not a real problem because spamassassin is based on perl, and we don't ship both archs in a multilib distribution. This bug is merely to figure out *why* it is behaving in this strange way betweeen 32bit and 64bit builds. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
