[Bug 228043] New: ??? 64bit sa-update.1 manpage timestamp differs from 32bit?

[bugzilla at redhat.com]

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 at redhat.com
        ReportedBy: wtogami at redhat.com
                CC: fedora-perl-devel-
                    list at redhat.com,felicity at kluge.net,jm at jmason.org,parkerm
                    @pobox.com,reg+redhat at sidney.com,wtogami at redhat.com


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.