Description of problem: `yum update` has trouble updating a number packages. Possibly because one arch is getting updated and one is not? Version-Release number of selected component (if applicable): # rpm -qa | grep yum yum-metadata-parser-1.1.2-1.fc8 yum-updatesd-0.7-1.fc8 yum-3.2.7-1.fc8 yum-refresh-updatesd-1.1.7-1.fc8 How reproducible: every time See log file which contains details on all the packages that failed to update today (system was current up to yesterday).
Created attachment 229171 [details] error messages
What's the output of 'rpm -q --qf "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}" GConf2' and what command exactly are you using to update?
GConf2-2.20.0-2.fc8.x86_64 GConf2-2.20.0-2.fc8.i386 `yum -y update`
Created attachment 234691 [details] install log
same problems installing taskjuggler--see log in comment#4
adding to F8 blocker on the basis that simple package installation and upgrades should work
This is a multilib conflict in gnokii.
The Makefile in gnokii's po subdir is trying to be too smart and leading to regenerated po files with different timestamps.
*** Bug 228360 has been marked as a duplicate of this bug. ***
*** Bug 341291 has been marked as a duplicate of this bug. ***
I just don't get anywhere with this until I can set up some virtual machine to do the testing, I don't have an x86_64 host, sadly. :-/ Anyone who likes to step in and patch the package, feel free to do so. Bastien, can you look at this?
(In reply to comment #8) > The Makefile in gnokii's po subdir is trying to be too smart and leading to > regenerated po files with different timestamps. And different versions of the .po file are causing problems with all those other programs? I don't see gnokii being mentioned anywhere in the original bug log. Seriously crappy bug. Went from a GConf2/yum bug to gnokii. Anyway, gnokii doesn't do anything fancy to generate its messages file. The Makefile are bog standard gettext supplied. If the generated files are different, then it's msgfmt making them different. I'll look into.
(In reply to comment #11) > I just don't get anywhere with this until I can set up some virtual > machine to do the testing, I don't have an x86_64 host, sadly. :-/ > Anyone who likes to step in and patch the package, feel free to do so. > > Bastien, can you look at this? Note that you don't really need an x86_64 machine to look at it. Finding the conflicts can be done with http://katzj.fedorapeople.org/multilib-cmp.py. (In reply to comment #12) > (In reply to comment #8) > > The Makefile in gnokii's po subdir is trying to be too smart and leading to > > regenerated po files with different timestamps. > > And different versions of the .po file are causing problems with all those other > programs? I don't see gnokii being mentioned anywhere in the original bug log. > Seriously crappy bug. Went from a GConf2/yum bug to gnokii. No argument from me on the bug history -- I really looked at it for the first time this afternoon > Anyway, gnokii doesn't do anything fancy to generate its messages file. The > Makefile are bog standard gettext supplied. If the generated files are > different, then it's msgfmt making them different. The po files end up different because they're being regenerated when they really shouldn't be at build time. I'm not quite sure why the update-gnokii.pot rule is getting run and then the remove-potcdate.sed stuff is also pretty strange > I'll look into. Hopefully I'll spend a little more time tonight and it'll pop out at me, but I wanted to be sure to get the current status of what was going on into the bug before I went home.
Committed a bit of a quick fix to CVS. The problem definitely seems to stem from the remove-potcdate.sed and updating of the po file bits, so I've just removed them for now; the cost is that the po files don't get msgmerged with the pot before we create the mo files, but that actually isn't a problem and most gettext-based Makefiles don't set that up.
Thanks Jeremy, I saw you tagged it as well so I assume this is being built and pushed too?
Yep (although apparently my network connection fell over and so it didn't get tagged for today's rawhide)
This isn't fixed. There is still a pile of conflicts in /usr/share/local/*/LC_MESSAGES/gnokii.mo
Bah, fixed better
no problems installing TaskJuggler now on x86_64 from latest updates.