Bug 578842 - Conflict between openssl.i686 and .x86_64
Summary: Conflict between openssl.i686 and .x86_64
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-01 14:32 UTC by Horst H. von Brand
Modified: 2010-05-18 11:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-18 11:46:34 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Horst H. von Brand 2010-04-01 14:32:35 UTC
Description of problem:
When updating openssl a file conflict shows up

Version-Release number of selected component (if applicable):
openssl-1.0.0-1.fc14.i686 and x86_64

How reproducible:
Always

Steps to Reproduce:
1. yum -y update openssl
2.
3.
  
Actual results:
Transaction Check Error:
  file /usr/share/man/man1/nseq.1ssl.gz conflicts between attempted installs of openssl-1.0.0-1.fc14.i686 and openssl-1.0.0-1.fc14.x86_64
  file /usr/share/man/man1/sslrand.1ssl.gz conflicts between attempted installs of openssl-1.0.0-1.fc14.i686 and openssl-1.0.0-1.fc14.x86_64

Expected results:
Packages installed

Additional info:

Comment 1 Rex Dieter 2010-04-01 15:40:56 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.

Comment 2 Rex Dieter 2010-04-01 15:41:55 UTC
ok, wierd, these were built on 03-30, so not sure how those different dates snuck in there.

Comment 3 Tomas Mraz 2010-04-06 09:48:39 UTC
This looks like a bug in pod2man as these dates should be the modification dates of the files and not the current date anyway.

Comment 4 Tomas Mraz 2010-04-06 09:58:25 UTC
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.

Comment 5 Matt McCutchen 2010-04-10 03:21:43 UTC
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.

Comment 6 Horst H. von Brand 2010-04-19 15:09:54 UTC
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).

Comment 7 Matt McCutchen 2010-04-20 03:36:33 UTC
(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.)

Comment 8 Matt McCutchen 2010-05-01 19:25:07 UTC
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)?

Comment 9 Matt McCutchen 2010-05-03 02:35:18 UTC
(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.


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