Bug 578842
| Summary: | Conflict between openssl.i686 and .x86_64 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Horst H. von Brand <vonbrand> |
| Component: | openssl | Assignee: | Tomas Mraz <tmraz> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | matt, rdieter, tmraz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-05-18 11:46:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Horst H. von Brand
2010-04-01 14:32:35 UTC
As I commented in bodhi, the man pages seem to embed the date built, and i686 ones say 02-01 and x86_64 ones 02-02 Solution is to either just rebuild it not around midnight, or just remove the timestamps from the manpages altogether. ok, wierd, these were built on 03-30, so not sure how those different dates snuck in there. This looks like a bug in pod2man as these dates should be the modification dates of the files and not the current date anyway. And it looks like the build machines in the bodhi are probably in different timezones and this makes the problem to appear - note that these files have the modification time of day near the midnight. If the build machines are in different timezones, that would explain the problem: .../openssl-1.0.0/doc/apps $ TZ=America/New_York pod2man rand.pod | grep 2009 .TH RAND 1 "2009-02-01" "perl v5.10.0" "User Contributed Perl Documentation" .../openssl-1.0.0/doc/apps $ TZ=UTC pod2man rand.pod | grep 2009 .TH RAND 1 "2009-02-02" "perl v5.10.0" "User Contributed Perl Documentation" But are they? This ticket suggests that they were all set to UTC: https://fedorahosted.org/fedora-infrastructure/ticket/347 It might be appropriate to set TZ=UTC in the RPM macros so that everyone building RPMs gets reproducibility. Fixed in openssl-1.0.0-3.fc14.x86_64 (i.e., could update to that without trouble; doesn't mean the above is fixed). (In reply to comment #6) > Fixed in openssl-1.0.0-3.fc14.x86_64 (i.e., could update to that without > trouble; doesn't mean the above is fixed). The underlying issue actually is fixed in rawhide: * Tue Apr 06 2010 Tomas Mraz <tmraz> 1.0.0-2 - set UTC timezone on pod2man run (#578842) - make X509_NAME_hash_old work in FIPS mode F12 and F13 need the same change. openssl-1.0.0-1.fc12 also suffers the conflict, and there is no other build of openssl 1.0.0 for F12 available. Adding TZ=UTC to the pod2man calls in openssl is OK for now, but given that the timezone appears to be a fundamental source of non-reproducibility that can affect any package that does similar things, I still believe the right solution is to set TZ=UTC in the standard RPM macros. Maybe this could be done for the next mass rebuild. (One would hope that setting TZ=UTC when building a package would not break anything, but you never know.) Ping. How much longer do I have to wait for an installable F12 openssl update with complete RFC 5746 support (to turn the Firefox site identity button blue again on my local web server)? (In reply to comment #8) > How much longer do I have to wait for an installable F12 openssl update > with complete RFC 5746 support (to turn the Firefox site identity button blue > again on my local web server)? The above request is now bug 588181. |