Bug 1262746 - kf5-sonnet-core: /usr/share/kf5/sonnet/trigrams.map multilib conflict
kf5-sonnet-core: /usr/share/kf5/sonnet/trigrams.map multilib conflict
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kf5-sonnet (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-14 05:17 EDT by Ambrogio
Modified: 2015-09-16 19:48 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-09-16 08:58:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ambrogio 2015-09-14 05:17:26 EDT
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:
Comment 1 Rex Dieter 2015-09-14 06:33:48 EDT
Looks like some sort of multilib conflict.
Comment 2 Kevin Kofler 2015-09-14 07:21:28 EDT
> * 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.
Comment 3 Kevin Kofler 2015-09-14 07:22:31 EDT
I'm starting to think we need to think of a way to set QT_HASH_SEED globally for all RPM builds.
Comment 4 Rex Dieter 2015-09-14 07:24:57 EDT
We can certainly consider adding that to our standard %cmake_kf5 macro
Comment 5 Rex Dieter 2015-09-14 07:39:41 EDT
%changelog
* Mon Sep 14 2015 Rex Dieter <rdieter@fedoraproject.org> 5.13.0-2
- QT_HASH_SEED=0, to workaround multilib conflicts (#1262746)
Comment 6 Rex Dieter 2015-09-14 07:55:11 EDT
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.
Comment 7 Kevin Kofler 2015-09-14 08:16:53 EDT
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) {
Comment 8 Kevin Kofler 2015-09-14 08:17:33 EDT
(in addition to the QT_HASH_SEED=0 trick, which is also needed)
Comment 9 Rex Dieter 2015-09-14 09:12:34 EDT
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) {
Comment 10 Kevin Kofler 2015-09-14 15:06:14 EDT
Hard to tell what else can be non-deterministic. :-( I'm going to have a closer look at the files.
Comment 11 Kevin Kofler 2015-09-14 15:12:03 EDT
At least in kf5-sonnet-5.13.0-2.fc24, the issue is indeed an ordering issue.
Comment 12 Kevin Kofler 2015-09-14 15:20:30 EDT
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.
Comment 13 Rex Dieter 2015-09-15 14:52:37 EDT
OK, that hack worked, thanks.
Comment 14 Rex Dieter 2015-09-15 14:55:45 EDT
%changelog
* Tue Sep 15 2015 Rex Dieter <rdieter@fedoraproject.org> 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)
Comment 15 Kevin Kofler 2015-09-15 22:54:23 EDT
You forgot to "git add sonnet-5.13.0-multilib.patch".
Comment 16 Daniel Vrátil 2015-09-16 08:58:52 EDT
Added the missing patch to 5.14.0-1 build
Comment 17 Kevin Kofler 2015-09-16 19:48:11 EDT
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.

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