Re: KLocale plans (Re: KF5 Unit test results)
> [: Chusslove Illich :] > While splitting out public methods dealing with translation from KLocale > [...] For completeness, also the overview of what I do with other methods (no comment needed except for objections :): All translateRaw*() methods are removed. They were used only by KLocalizedString anyway. setMainCatalog() and setActiveCatalog() are removed. The former is practically either a no-op or equivalent to insertCatalog(), and the latter was used only in about data. insertCatalog() and removeCatalog() go to KLocalizedString. E.g. KLocale::global()->insertCatalog() becomes KLocalizedString::insertCatalog() . This is temporary, later I will remove these two methods too, in favor of Gettext-like catalog resolution (static resolution for i18n calls in libraries, dynamic resolution only using single catalog in applications). So there will be something like KLocalizedString::setApplicationCatalog() equiv. to Gettext textdomain(). copyCatalogsTo() is removed, it was needed only due to entanglement between KLocale, KCatalog and KLocalizedString. removeAcceleratorMarker() goes to KLocalizedString. toString() methods of KLocalizedString currently need a *KLocale argument. This would remain using KLocale inheritor, but in the meantime I will comment them out, and introduce methods taking QStringList &languages instead. This is needed for disentangling, but also makes sense on its own, so they would not be only temporary. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
While splitting out public methods dealing with translation from KLocale, I got a doubt about localizedFilePath(). For a given file path, it returns the localized file path, if available, according to the same language list and fallback rules as for strings in PO files. Due to this, initially I thought moving it to ki18n. However, this function was also used internally in KStandardDirs, so that in a usual KDE program, any file resource could be localized without doing anything in the code. Now I see that QStandardDirs is replacing KStandardDirs. It may not seem that this automatic localizability of file resources is that much needed, since it is rarely needed, and translator could ask programmer to wrap whatever path returned by QStandardDirs with localizedFilePath(). Unfortunatelly, sometimes the programmer also does not handle the path directly (e.g. icons). Any idea here? In a perfect world, the text translation library would come earlier in the hierarchy, and QStandardDirs would use it internally, just as it was with KStandardDirs. Adding this functionality to Qt would make sense, but we will then have a mismatch in the language resolution and fallback rules, which are quite specific with Gettext. On the other hand, we will have this mismatch for text anyway... -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > Hi Chusslove, > > any progress? :-) No progress, but I'm going to do it right now. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
On Sunday 16 September 2012 19:22:26 Chusslove Illich wrote: > > [: David Faure :] > > Anyhow, I recommend splitting "in place" (in kdecore), first, to have > > commits that do the splitting, separated from the commits that do the > > moving. I can even do the moving once you've done the API splitting :-) > > Well that's totally great. I was thinking of asking about doing it this way > exactly, but thought it would be disrespective of your time :) Hi Chusslove, any progress? :-) I solved the kservice issue temporarily (with a few big nasty ifdefs), but I'm very soon going to hit the same issue with KIO, which I'd like to split out, because KIO has a strong dependency on i18n -- I'm not porting that to tr(), there's a lot of plural forms in kio/global.cpp for instance. I think the plan was "tr() for frameworks with very few and simple translations, i18n for heavy i18n usage", and KIO fits into the second category, it seems. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > Anyhow, I recommend splitting "in place" (in kdecore), first, to have > commits that do the splitting, separated from the commits that do the > moving. I can even do the moving once you've done the API splitting :-) Well that's totally great. I was thinking of asking about doing it this way exactly, but thought it would be disrespective of your time :) -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
On Saturday 15 September 2012 13:36:42 Chusslove Illich wrote: > > [: David Faure :] > > So either i18n is ported away from KLocale, or all that calendar stuff has > > to move into the ki18n framework, at least in the short term. > > Since including calendar stuff into ki18n would be a temporary measure that > would later have to be undone, I think it's best that I split out ki18n and > remove KLocale dependencies from it as soon as possible. Yes. > The proper location would be staging/ki18n, right? Yes. Make sure to follow the standard directory structure under that dir (src, autotests, tests), see http://community.kde.org/Frameworks/Policies#Framework_directory_structure Anyhow, I recommend splitting "in place" (in kdecore), first, to have commits that do the splitting, separated from the commits that do the moving. I can even do the moving once you've done the API splitting :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > So either i18n is ported away from KLocale, or all that calendar stuff has > to move into the ki18n framework, at least in the short term. Since including calendar stuff into ki18n would be a temporary measure that would later have to be undone, I think it's best that I split out ki18n and remove KLocale dependencies from it as soon as possible. The proper location would be staging/ki18n, right? -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
On Tuesday 11 September 2012 13:15:37 Chusslove Illich wrote: > > [: David Faure :] > > Is it also part of your plans to remove i18n()'s dependency on KLocale? > > I consider it rather an orthogonal matter. I will anyway remove all Gettext- > related stuff from KLocale, before doing anything about replacing > *gettext() calls themselves. > > > This is what's blocking me now, for extracting a ki18n framework (which I > > then need for the kservice+plugins framework). > > > > I think I'll let you move ahead on this topic and I'll find another area > > to work on meanwhile, there are plenty :-) > > On the other hand, not to stall unnecessarily, maybe it would be better if I > "real soon" factored out i18n as it is into staging/ki18n (possibly > temporarily breaking some internal details, which is no big issue)? And > only then go into what I mentioned before, proposing updated > klocalizedstring.h with new doc, etc. This shouldn't lead to any wasted > work, only slightly changed order of doing it. The reason I'm asking about KLocale, is that it currently depends on KCalendarSystem, KDateTime and KDayPeriod, all of which are not related to ki18n. (and that's basically all of kdecore/date except for the timezone stuff). So either i18n is ported away from KLocale, or all that calendar stuff has to move into the ki18n framework, at least in the short term. Apparently the calendar stuff itself has no additional dependencies (apart from a few kdefakes.h that Nicolas is currently fixing and a KToolInvocation that I'll fix), so the second solution is workable technically. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KLocale plans (Re: KF5 Unit test results)
> [: David Faure :] > Is it also part of your plans to remove i18n()'s dependency on KLocale? I consider it rather an orthogonal matter. I will anyway remove all Gettext- related stuff from KLocale, before doing anything about replacing *gettext() calls themselves. > This is what's blocking me now, for extracting a ki18n framework (which I > then need for the kservice+plugins framework). > > I think I'll let you move ahead on this topic and I'll find another area > to work on meanwhile, there are plenty :-) On the other hand, not to stall unnecessarily, maybe it would be better if I "real soon" factored out i18n as it is into staging/ki18n (possibly temporarily breaking some internal details, which is no big issue)? And only then go into what I mentioned before, proposing updated klocalizedstring.h with new doc, etc. This shouldn't lead to any wasted work, only slightly changed order of doing it. -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KLocale plans (Re: KF5 Unit test results)
On Wednesday 05 September 2012 10:48:54 Chusslove Illich wrote: > Next I plan to rewrite > klocalizedstring.h, such that it reflects the planned changes, but most > importantly to have more comprehensive doc appropriate for a standalone > component. After we review it, I go adapting the code. Waterfall supreme. Is it also part of your plans to remove i18n()'s dependency on KLocale? This is what's blocking me now, for extracting a ki18n framework (which I then need for the kservice+plugins framework). I think I'll let you move ahead on this topic and I'll find another area to work on meanwhile, there are plenty :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
> [: David Faure :] > Any objections if I remove the no-NLS code path? No objection from my side. (When I get to it, I'd even like to replace *gettext() calls with internal MO file handling, which is not that complicated. Then we can remove kludges in kcatalog.cpp, like rebinding catalog locations and setting LANGUAGE all the time.) -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Wednesday 05 September 2012 17:45:32 Chusslove Illich wrote:
> >> [: Chusslove Illich :]
> >> Now all work: Totals: 9 passed, 0 failed, 0 skipped.
> >
> > [: David Faure :]
> > Damn it, so you won't be able to help me debug why it fails for me :(
>
> How about if you stick an i18n call into kde4-config (my favorite for this
> purpose :), maybe tests do something funny with the environment? If that
> doesn't work either, I'd try pure Gettext call within kde4-config, and also
> within pure C code:
>
> #include
> #include
> #include
> int main ()
> {
> setlocale(LC_ALL, "fr_FR.utf8");
> bindtextdomain("kdelibs4", "/usr/share/locale");
> printf("%s\n", dgettext("kdelibs4", "Loadable modules"));
> return 0;
> }
Thanks, your testcase rocked. I found the issue.
The problem was that the dgettext() in kcatalog.cpp was defined to a no-op in
our gettext.h header, because ENABLE_NLS wasn't defined. This was because of
recent changes which moved config-localization.h from kdecore to
kdecore/localization, so I had an old incomplete config-localization-h in
kdecore, which didn't define ENABLE_NLS. Yet another case where #cmakedefine01
saved the day: I saw the warning about it not being defined, during
compilation.
This also explains why it suddenly worked for you after a clean build.
This makes me wonder: do we still need ENABLE_NLS? It makes kdecore (ki18n
soon) compile even if libintl isn't found. Talking to Coolo, he said this was
added for Solaris 0.3, back in the days :-)
I think these days, if someone forgets to install libintl.h, we should rather
abort and tell them. Coolo agreed.
Any objections if I remove the no-NLS code path?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
>> [: Chusslove Illich :]
>> Now all work: Totals: 9 passed, 0 failed, 0 skipped.
>
> [: David Faure :]
> Damn it, so you won't be able to help me debug why it fails for me :(
How about if you stick an i18n call into kde4-config (my favorite for this
purpose :), maybe tests do something funny with the environment? If that
doesn't work either, I'd try pure Gettext call within kde4-config, and also
within pure C code:
#include
#include
#include
int main ()
{
setlocale(LC_ALL, "fr_FR.utf8");
bindtextdomain("kdelibs4", "/usr/share/locale");
printf("%s\n", dgettext("kdelibs4", "Loadable modules"));
return 0;
}
--
Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Wednesday 05 September 2012 13:15:32 Chusslove Illich wrote: > >> [: Chusslove Illich :] > >> Totals: 7 passed, 3 failed, 0 skipped (where all 3 are due to > >> QCoreApplication::translate(), including 2 calls from testThreads()). > > > > [: David Faure :] > > Can you try again? I committed a fix for the KDETranslator stuff. > > Now all work: Totals: 9 passed, 0 failed, 0 skipped. Damn it, so you won't be able to help me debug why it fails for me :( -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
>> [: Chusslove Illich :] >> Totals: 7 passed, 3 failed, 0 skipped (where all 3 are due to >> QCoreApplication::translate(), including 2 calls from testThreads()). > > [: David Faure :] > Can you try again? I committed a fix for the KDETranslator stuff. Now all work: Totals: 9 passed, 0 failed, 0 skipped. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Wednesday 05 September 2012 12:29:15 Chusslove Illich wrote: > > [: David Faure :] > > But back to translateToFrench(): could it be that it is skipped for lack > > of 'fr' translations on your system? > > That was the case just after I built anew :) But then I copied translations > into proper place. So the final line of test output now is > Totals: 7 passed, 3 failed, 0 skipped (where all 3 are due to > QCoreApplication::translate(), including 2 calls from testThreads()). Can you try again? I committed a fix for the KDETranslator stuff. > > On my side I'll keep working on making a klocale framework, removing > > dependencies on other kdecore things and other frameworks. Almost there, I > > think. > > > > BTW I made kjs standalone already, so that klocale can depend on it (-> > > tier2). This makes kservice tier3. > > As for the link between klocale and ki18n[*], I plan to comment out locale- > dependent bits in ki18n until the situation with locale support has fully > cleared up. Locale support is used only at few point places in ki18n (e.g. > before final substitution of a number argument), so it does not really > influence ki18n as a whole (unlike kjs). And everything from klocale related > to translation I will move to ki18n. Makes sense. > [*] I think "ki18n" would be a good name for the i18n KF5 component. Ah, right ki18n for the translation framework, KLocale mostly "deprecated in favour of QLocale", for number formatting and stuff. OK, so ki18n it is. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
> [: David Faure :] > But back to translateToFrench(): could it be that it is skipped for lack > of 'fr' translations on your system? That was the case just after I built anew :) But then I copied translations into proper place. So the final line of test output now is Totals: 7 passed, 3 failed, 0 skipped (where all 3 are due to QCoreApplication::translate(), including 2 calls from testThreads()). > On my side I'll keep working on making a klocale framework, removing > dependencies on other kdecore things and other frameworks. Almost there, I > think. > > BTW I made kjs standalone already, so that klocale can depend on it (-> > tier2). This makes kservice tier3. As for the link between klocale and ki18n[*], I plan to comment out locale- dependent bits in ki18n until the situation with locale support has fully cleared up. Locale support is used only at few point places in ki18n (e.g. before final substitution of a number argument), so it does not really influence ki18n as a whole (unlike kjs). And everything from klocale related to translation I will move to ki18n. [*] I think "ki18n" would be a good name for the i18n KF5 component. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Wednesday 05 September 2012 10:48:54 Chusslove Illich wrote: > > [: David Faure :] > > Could you have another lock? It's broken again, and this time it's not due > > to catalogLocaleDir(), I checked it in kdelibs-4 and kf5, and it returns / > > usr/share/locale in both (with trailing slash in kdelibs-4, but adding one > > didn't help). > > [...] > > Thanks for your help, I'm at a loss here. > > Hm... When I simply did make install after pulling, I too had all > translation tests fail. Then, when I couldn't figure out what's wrong, I > deleted the build and install directories and built from scratch. Now only > QCoreApplication::translate() test fails; apparently it doesn't forward the > call to KLocale::translateQt(), i.e. KDE i18n does not see it at all. Ah yes, that one is my doing. If we don't call KGlobal::locale anymore, QCoreApplication::installTranslator isn't called. I'll move that code to KLocale::global(). But back to translateToFrench(): could it be that it is skipped for lack of 'fr' translations on your system? > As for i18n in general, so far I've written the script to remove KUIT markup > _from i18n strings (turned to be a bit more involved than I thought) -- do > you have a suggestion where to put it in the repos? kdesdk/scripts/kf5/, in svn. > Next I plan to rewrite > klocalizedstring.h, such that it reflects the planned changes, but most > importantly to have more comprehensive doc appropriate for a standalone > component. After we review it, I go adapting the code. Waterfall supreme. Sounds good. On my side I'll keep working on making a klocale framework, removing dependencies on other kdecore things and other frameworks. Almost there, I think. BTW I made kjs standalone already, so that klocale can depend on it (-> tier2). This makes kservice tier3. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
> [: David Faure :] > Could you have another lock? It's broken again, and this time it's not due > to catalogLocaleDir(), I checked it in kdelibs-4 and kf5, and it returns / > usr/share/locale in both (with trailing slash in kdelibs-4, but adding one > didn't help). > [...] > Thanks for your help, I'm at a loss here. Hm... When I simply did make install after pulling, I too had all translation tests fail. Then, when I couldn't figure out what's wrong, I deleted the build and install directories and built from scratch. Now only QCoreApplication::translate() test fails; apparently it doesn't forward the call to KLocale::translateQt(), i.e. KDE i18n does not see it at all. As for i18n in general, so far I've written the script to remove KUIT markup _from i18n strings (turned to be a bit more involved than I thought) -- do you have a suggestion where to put it in the repos? Next I plan to rewrite klocalizedstring.h, such that it reflects the planned changes, but most importantly to have more comprehensive doc appropriate for a standalone component. After we review it, I go adapting the code. Waterfall supreme. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Friday 10 August 2012 14:19:17 Chusslove Illich wrote:
> > [: David Faure :]
> > 5 - kdecore-klocalizedstringtest (Failed) // I don't get it.
> > dgettext("kdelibs4", msgid) works in kdelibs-4.9 and not here
> I've fixed this now.
Could you have another lock? It's broken again, and this time it's not due to
catalogLocaleDir(), I checked it in kdelibs-4 and kf5, and it returns
/usr/share/locale in both (with trailing slash in kdelibs-4, but adding one
didn't help).
kdelibs-4.9 says:
QDEBUG : KLocalizedStringTest::translateToFrench() LANGUAGE=fr
QDEBUG : KLocalizedStringTest::translateToFrench() "fr" bindtextdomain
"kdelibs4" "/d/kde/inst/kde4.9/share/locale/"
QDEBUG : KLocalizedStringTest::translateToFrench() translateStrict: "kdelibs4"
Loadable modules -> Modules chargeables
(where /d/kde/inst/kde4.9/share/locale/fr is a symlink to
/usr/share/locale/fr)
and kdelibs-frameworks5 (with qt4) says:
QDEBUG : KLocalizedStringTest::translateToFrench() LANGUAGE=fr
QDEBUG : KLocalizedStringTest::translateToFrench() "fr" bindtextdomain
"kdelibs4" "/usr/share/locale/"
QDEBUG : KLocalizedStringTest::translateToFrench() translateStrict: "kdelibs4"
Loadable modules -> Loadable modules
(then it tries other catalogs, and fails).
/usr/share/locale/fr/LC_MESSAGES/kdelibs4.mo is being used in both cases.
Thanks for your help, I'm at a loss here.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Sunday 19 August 2012 14:59:29 Rolf Eike Beer wrote:
> David Faure wrote:
> > Update:
> >
> > * kdelibs-frameworks with Qt4:
> >
> > 100% tests passed, 0 tests failed out of 126
> >
> > (I fixed the plasma tests)
> >
> > * kdelibs-frameworks with Qt5:
> >
> > The following tests FAILED:
> > 108 - httpheaderdispositiontest (Failed) [**]
> >
> > [**]
> > FAIL! : HeaderDispositionTest::runAllTests(greenbytes-attwithisofnplain)
> > Compared values are not the same Actual (parameters[key]): foo-?.html
> >
> >Expected (QString::fromUtf8(val.constData(), val.length())): foo-?.html
> >
> >Loc:
> > [/d/kde/src/kf5-qt5/kdelibs-frameworks/kioslave/http/tests/httpheaderdispo
> > s
> > itiontest.cpp(52)] Rolf, any change you can have a look?
>
> QTest::newRow("greenbytes-attwithisofnplain") << "attachment;
> filename=\"foo-\xe4.html\"" <<
> QByteArray("type\tattachment\n"
> "filename\tfoo-ä.html");
>
> Qt5 does not take the string as ISO-8859-1 anymore, so the input is not what
> the testcase expects so the output is also broken.
>
> Merge KDE/4.9 (which contains commit
> b6a802bfab579880612740e7f9da2569fcd900cd) into master and frameworks, this
> should fix it.
Thanks, well spotted!
I applied the same fix to three other lines, and the test passes now.
7 to go ;-)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
David Faure wrote:
> Update:
>
> * kdelibs-frameworks with Qt4:
>
> 100% tests passed, 0 tests failed out of 126
>
> (I fixed the plasma tests)
>
> * kdelibs-frameworks with Qt5:
>
> The following tests FAILED:
> 108 - httpheaderdispositiontest (Failed) [**]
>
> [**]
> FAIL! : HeaderDispositionTest::runAllTests(greenbytes-attwithisofnplain)
> Compared values are not the same Actual (parameters[key]): foo-?.html
>Expected (QString::fromUtf8(val.constData(), val.length())): foo-?.html
>Loc:
> [/d/kde/src/kf5-qt5/kdelibs-frameworks/kioslave/http/tests/httpheaderdispos
> itiontest.cpp(52)] Rolf, any change you can have a look?
QTest::newRow("greenbytes-attwithisofnplain") << "attachment;
filename=\"foo-\xe4.html\"" <<
QByteArray("type\tattachment\n"
"filename\tfoo-ä.html");
Qt5 does not take the string as ISO-8859-1 anymore, so the input is not what
the testcase expects so the output is also broken.
Merge KDE/4.9 (which contains commit b6a802bfab579880612740e7f9da2569fcd900cd)
into master and frameworks, this should fix it.
|| ||
\/ \/
--> Eike <--
/\ /\
|| ||
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
Update:
* kdelibs-frameworks with Qt4:
100% tests passed, 0 tests failed out of 126
(I fixed the plasma tests)
* kdelibs-frameworks with Qt5:
The following tests FAILED:
12 - kdecore-kdatetimetest (Failed) -- John, help!
25 - kdecore-kcalendartest (Failed) -- John, help!
26 - kdecore-kservicetest (Failed) [*]
33 - sonnet-test_filter (Failed)
[https://codereview.qt-project.org/31717]
42 - kde4support-kuniqueapptest (Failed) [QTBUG-26886]
76 - kdeui-ktoolbar_unittest (Failed) [QTBUG-26887]
102 - kfile-kfileplacesmodeltest (Failed) Ordering issue, probably
QSet. Couldn't find where though. Maybe in solid?
108 - httpheaderdispositiontest (Failed) [**]
[*] That one is for me, QStandardPaths testMode doesn't affect
KGlobal::dirs()->resourceDirs("xdgdata"),
so I guess kbuildsycoca needs more porting to QStandardPaths.
[**]
FAIL! : HeaderDispositionTest::runAllTests(greenbytes-attwithisofnplain)
Compared values are not the same
Actual (parameters[key]): foo-?.html
Expected (QString::fromUtf8(val.constData(), val.length())): foo-?.html
Loc:
[/d/kde/src/kf5-qt5/kdelibs-frameworks/kioslave/http/tests/httpheaderdispositiontest.cpp(52)]
Rolf, any change you can have a look?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
New baseline for Qt4-based builds: All tests pass, except for the 3 plasma ones, for lack of any interested plasma hacker. If you see any different result, check your setup, check why individual tests fail, and if you still can't figure it out, post test output here. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Friday 10 August 2012 14:19:17 Chusslove Illich wrote:
> > [: David Faure :]
> > 5 - kdecore-klocalizedstringtest (Failed) // I don't get it.
> > dgettext("kdelibs4", msgid) works in kdelibs-4.9 and not here
> I've fixed this now.
Thanks Chusslove, you rock!
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
> [: Chusslove Illich :] > translateQt fails (for me?), I didn't touch anything about that. False alarm, forgot to install kdeqt.po. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
> [: David Faure :]
> 5 - kdecore-klocalizedstringtest (Failed) // I don't get it.
> dgettext("kdelibs4", msgid) works in kdelibs-4.9 and not here
I've fixed this now.
translateQt fails (for me?), I didn't touch anything about that.
--
Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Unit test results
On Sunday 29 July 2012 14:53:47 David Faure wrote: > 71 - kdeui-kstartupinfo_unittest (Failed) // hangs. > KXMessages::x11Event needs porting to XCB Fixed. > 76 - kdeui-ktoolbar_unittest (Failed) // something about the keyboard > modifiers > in triggered(Qt::MouseButtons,Qt::KeyboardModifiers). Not a "real bug", but a testlib issue. In Qt5, QTest::mouseClick doesn't set QApplication::keyboardModifiers anymore. Mail sent to the Qt development list last Monday (and happily ignored by everyone there since then). kuniqueapptest fails too, with recent Qt5, due to QPA processing events too early; reported to the Qt development list too. I'll look at klibloadertest next, and into plugins in general. > 102 - kfile-kfileplacesmodeltest (Failed) // again :-( Benjamin, didn't > you fix this one once already? (**) > 108 - httpheaderdispositiontest (Failed) // 3 failures, utf8 related, needs > investigation > 116 - kutils-kemoticontest2 (Failed) // Lots of XPASS and one FAIL, needs > investigation Any volunteers? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
