Bug 468161 - translation files cause multilib conflicts (again)
Summary: translation files cause multilib conflicts (again)
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libgnome
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-10-23 10:36 UTC by Torsten Rausche
Modified: 2009-06-27 15:43 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-10-23 17:51:37 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Yum's failing transaction check (3.37 KB, text/plain)
2008-10-23 10:36 UTC, Torsten Rausche
no flags Details

Description Torsten Rausche 2008-10-23 10:36:53 UTC
Created attachment 321264 [details]
Yum's failing transaction check

Description of problem:
The newest version of libgnome has multilib conflicts. Again the culprits are translations files (*.mo).

Version-Release number of selected component (if applicable):
libgnome-2.24.1-5.fc10.

How reproducible:
Always

Steps to Reproduce:
1. # yum install libgnome-2.24.1-5.fc10.i386 libgnome-2.24.1-5.fc10.x86_64
  
Actual results:
Installation/update fails because of file conflicts (see attachment)

Expected results:
No file conflicts

Additional info:
There already were attempts to fix this in previous versions

Comment 1 Matthias Clasen 2008-10-23 15:52:49 UTC
not sure what you mean with 'attempts' - the multilib conflict _was_ fixed.

Comment 2 Torsten Rausche 2008-10-23 16:57:14 UTC
(In reply to comment #1)
> not sure what you mean with 'attempts' - the multilib conflict _was_ fixed.

I just saw the bugzilla entries about the same problem in release 2.24.1-2. They told me that this problem should be fixed. Obviously it isn't fixed in the current release whereas the changelog only has an entry about a theme change after the fix...

I tried a multilib install with 2.24.1-4 now and you are right. There it WAS fixed. So let us say in release 2.24.1-5 it is broken AGAIN :)

Comment 3 Matthias Clasen 2008-10-23 17:01:57 UTC
yay, regression !

Comment 4 Bill Nottingham 2008-10-23 17:51:37 UTC
Looking at it, it's not the timestamp, it's the PO headers in the .mo file.

Should be fixed in -6, although the fix is rather gross.


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