Description of problem: dnf update is unable to update the kf5 sonnet component: Version-Release number of selected component (if applicable): Actually installed: kf5-sonnet-core-5.12.0-1.fc22.i686.rpm kf5-sonnet-core-5.12.0-1.fc22.x86_64.rpm kf5-sonnet-ui-5.12.0-1.fc22.i686.rpm kf5-sonnet-ui-5.12.0-1.fc22.x86_64.rpm packages available: kf5-sonnet-core i686 5.13.0-1.fc22 updates 147 k kf5-sonnet-core x86_64 5.13.0-1.fc22 updates 147 k kf5-sonnet-ui i686 5.13.0-1.fc22 updates 230 k kf5-sonnet-ui x86_64 5.13.0-1.fc22 updates 228 k How reproducible: It was already present in last update, but solved with a force installation. Steps to Reproduce: 1. dnf update 2. errors returned. No update performed 3. Actual results: Esecuzione del controllo di transazione Test di transazione eseguito con successo. Test di transazione in corso Errore: Errore nel controllo transazione: file /usr/share/kf5/sonnet/trigrams.map conflicts between attempted installs of kf5-sonnet-core-5.13.0-1.fc22.i686 and kf5-sonnet-core-5.13.0-1.fc22.x86_64 Expected results: Additional info:
Looks like some sort of multilib conflict.
> * parsetrigrams.cpp > * > * Parse a set of trigram files into a QHash, and serialize to stdout. This needs the same QT_HASH_SEED workaround as the Qt documentation multilib conflicts.
I'm starting to think we need to think of a way to set QT_HASH_SEED globally for all RPM builds.
We can certainly consider adding that to our standard %cmake_kf5 macro
%changelog * Mon Sep 14 2015 Rex Dieter <rdieter> 5.13.0-2 - QT_HASH_SEED=0, to workaround multilib conflicts (#1262746)
Darn, that didn't seem to help, the produced trigrams.map is still different (according to diff and rpm) even after setting QT_HASH_SEED=0 during the build.
Try this change to data/parsetrigrams.cpp: > QStringList files = td.entryList(QDir::Files); + files.sort() // ← add this here (line 48) > > Q_FOREACH (const QString& fname, files) {
(in addition to the QT_HASH_SEED=0 trick, which is also needed)
This patch didn't help either :( diff -up sonnet-5.13.0/data/parsetrigrams.cpp.multilib sonnet-5.13.0/data/parsetrigrams.cpp --- sonnet-5.13.0/data/parsetrigrams.cpp.multilib 2015-08-04 06:47:13.000000000 -0500 +++ sonnet-5.13.0/data/parsetrigrams.cpp 2015-09-14 07:42:41.906870766 -0500 @@ -45,6 +45,7 @@ int main(int argc, char **argv) QHash< QString, QHash<QString,int> > models; QStringList files = td.entryList(QDir::Files); + files.sort(); Q_FOREACH (const QString& fname, files) {
Hard to tell what else can be non-deterministic. :-( I'm going to have a closer look at the files.
At least in kf5-sonnet-5.13.0-2.fc24, the issue is indeed an ordering issue.
What you can try, which should also obviate the need both for QT_HASH_SEED and for the files.sort() patch (so you should be able to remove both of those), is to replace all uses of QHash in parsetrigrams.cpp with QMap: sed -i -e 's/QHash/QMap/g' data/parsetrigrams.cpp They have the same QDataStream representation, so the code that reads the .map file should not care either way, and QMap has a fixed ordering.
OK, that hack worked, thanks.
%changelog * Tue Sep 15 2015 Rex Dieter <rdieter> 5.13.0-3 - try harder, use QMap instead of QHash to workaround multilib conflicts (#1262746) closing->rawhide This change will get rolled into kf5-5.14.0 updates coming soon (probably over the next few days)
You forgot to "git add sonnet-5.13.0-multilib.patch".
Added the missing patch to 5.14.0-1 build
You also need to replace the #included header file. It's just luck that it compiles that way. (Something else must be dragging in <QMap>.) Really, I don't understand why you don't just use my one-line sed, which does a reliable global search&replace and never needs to be rebased.