Build and test failures with Qt 5.6 and Qt 5.3

[David Faure]

On Saturday 07 November 2015 21:42:33 Jan Kundrát wrote:
> Hi David,
> thanks for looking into this. I'm happy that you find the additional 
> coverage useful. At this time, the infrastructure cannot easily send out 
> automated e-mails only upon a change in the state of a build job -- if 
> someone has some time and is willing to improve this, I'll be happy to walk 
> them through.

Actually, I'm not sure I want more CI noise by email :-)

(because there are of course false positives, i.e. setup-related failures)

I'll just try to remember to keep an eye on your matrix in addition to build.kde.org,
but feel free to poke me when you see red again, after we make it green ;)

> >> - [5.6] kcoreaddons: different number formatting
> >
> > This test sets a C locale. Could it be that on your system, the C locale
> > doesn't include having the comma as thousands-separator?
> 
> The build jobs appear to be running with LANG=en_US.UTF-8. My ssh setup 
> apparently forwards these LANG and LC_* variables, so I cannot guarantee 
> 100% correctness, but here's how the number formatting works in root's 
> bash:
> 
> [root at ci-el7-a-4 ~]# LC_ALL=C printf "%'.3f\n" 12345678.901
> 12345678.901
> [root at ci-el7-a-4 ~]# LC_ALL=en_US.utf8 printf "%'.3f\n" 12345678.901
> 12,345,678.901
> 
> Is that a correct behavior?

I get the same, at least.

> > Or maybe the system's locale still interfers, i.e. KFormat 
> > format(QLocale::c());
> > isn't enough to -really- use the C locale?
> 
> Note that the failure is specific to Qt 5.6, which IMHO suggests that 
> there's some behavior change in Qt.

OK, good point.
And looking at bash's behaviour, maybe this is a bugfix, i.e. the C locale
isn't supposed to get en_US-like thousands separators....

Someone needs to dig into Qt changes and/or to make a qt-only testcase.
(don't have time right now).

> >> - kio, in all versions: test failures in KNewFileMenuTest::test(text file 
> >> with jpeg extension)
> >
> > Also a mimetype problem. kcoreaddons' kde5.xml adds "*.doc" as a pattern
> > for text/plain, but surely it doesn't mean for it to become the 
> > main extension.
> > Can you the value of 
> > QMimeDatabase().mimeTypeForName("text/plain").preferredSuffix()
> > on your system? Here's it's "txt", I suspect it's "doc" on your 
> > system. Not sure why yet
> > though, but let's first check that.
> 
> It prints out "txt".

OK.... so why does this code give you ".doc" ?
kio/src/filewidgets/knewfilemenu.cpp:556:         chosenFileName += QLatin1Char('.') + wantedMime.preferredSuffix();

Any chance you could do some debugging around there?

> >> - kservice, in all versions: test failure
> >
> > It appears that your system doesn't know that opendocument 
> > inherits application/zip.
> > Do you have this line in /usr/share/mime/subclasses ?
> > application/vnd.oasis.opendocument.text application/zip
> 
> That line is missing:
> 
> [root at ci-el7-a-4 ~]# grep -c opendocument /usr/share/mime/subclasses 
> 0
> [root at ci-el7-a-4 ~]# rpm -qf /usr/share/mime/subclasses
> shared-mime-info-1.1-7.el7.x86_64

That is really broken. The inheritance of opendocument.text from application/zip
has always been there in s-m-i (since 0.18).

Do you actually have /usr/share/mime/packages/freedesktop.org.xml at all ?

If yes, then I don't know what could have gone wrong; could you maybe send me
a .zip of all of your /usr/share/mime ?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5