Jenkins-kde-ci: calligra master kf5-qt5 ยป Linux,gcc - Build # 164 - Still Unstable!
GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/calligra%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/164/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 09 Dec 2016 02:55:07 + Build duration: 42 min CHANGE SET Revision 62434fcc17f970936e12890a8af6c9d0f512ded8 by scripty: (SVN_SILENT made messages (.desktop file) - always resolve ours) change: edit plan/libs/ui/reports/items/text/text.json JUNIT RESULTS Name: (root) Failed: 5 test(s), Passed: 148 test(s), Skipped: 0 test(s), Total: 153 test(s)Failed: TestSuite.libs-koodf-TestNumberStyleFailed: TestSuite.libs-pigment-TestColorConversionSystemFailed: TestSuite.sheets-DatetimeFunctionsFailed: TestSuite.sheets-ValueConverterFailed: TestSuite.sheets-ValueParser COBERTURA RESULTS Cobertura Coverage Report PACKAGES 144/171 (84%)FILES 1202/2604 (46%)CLASSES 1202/2604 (46%)LINE 77561/259044 (30%)CONDITIONAL 51632/282194 (18%) By packages braindump.braindumpcore FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/134 (0%)CONDITIONAL 0/98 (0%) braindump.plugins.stateshape FILES 4/14 (29%)CLASSES 4/14 (29%)LINE 24/280 (9%)CONDITIONAL 3/140 (2%) braindump.plugins.webshape FILES 4/9 (44%)CLASSES 4/9 (44%)LINE 22/295 (7%)CONDITIONAL 1/114 (1%) braindump.src FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/3 (0%)CONDITIONAL 0/0 (100%) devtools.rng2cpp FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 600/693 (87%)CONDITIONAL 596/814 (73%) filters.libmso FILES 10/12 (83%)CLASSES 10/12 (83%)LINE 880/7716 (11%)CONDITIONAL 2165/19897 (11%) filters.libmso.generated FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 4193/12624 (33%)CONDITIONAL 3969/23069 (17%) filters.libmsooxml FILES 2/35 (6%)CLASSES 2/35 (6%)LINE 3/8010 (0%)CONDITIONAL 2/24349 (0%) filters.libmsooxml.generated FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/743 (0%)CONDITIONAL 0/3336 (0%) filters.libodf2 FILES 6/29 (21%)CLASSES 6/29 (21%)LINE 97/1606 (6%)CONDITIONAL 82/2174 (4%) filters.libodf2.chart FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/582 (0%)CONDITIONAL 0/1321 (0%) filters.sheets.excel.sidewinder FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 654/685 (95%)CONDITIONAL 1918/3502 (55%) filters.sheets.xlsx FILES 4/5 (80%)CLASSES 4/5 (80%)LINE 111/281 (40%)CONDITIONAL 67/460 (15%) filters.stage.powerpoint FILES 9/10 (90%)CLASSES 9/10 (90%)LINE 1651/2710 (61%)CONDITIONAL 1999/6134 (33%) filters.stage.powerpoint.tests FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 56/58 (97%)CONDITIONAL 92/194 (47%) interfaces FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 54/61 (89%)CONDITIONAL 36/73 (49%) libs.basicflakes.plugin FILES 4/4 (100%)CLASSES 4/4 (100%)LINE 23/31 (74%)CONDITIONAL 1/8 (13%) libs.basicflakes.tools FILES 0/4 (0%)CLASSES 0/4 (0%)LINE 0/819 (0%)CONDITIONAL 0/413 (0%) libs.flake FILES 111/180 (62%)CLASSES 111/180 (62%)LINE 5273/13803 (38%)CONDITIONAL 2895/9878 (29%) libs.flake.commands FILES 19/49 (39%)CLASSES 19/49 (39%)LINE 805/2153 (37%)CONDITIONAL 410/1380 (30%) libs.flake.svg FILES 1/20 (5%)CLASSES 1/20 (5%)LINE 8/2480 (0%)CONDITIONAL 1/1706 (0%) libs.flake.tests FILES 49/49 (100%)CLASSES 49/49 (100%)LINE 3740/3773 (99%)CONDITIONAL 1718/3394 (51%) libs.flake.tools FILES 9/43 (21%)CLASSES 9/43 (21%)LINE 155/1625 (10%)CONDITIONAL 45/952 (5%) libs.kundo2 FILES 5/10 (50%)CLASSES 5/10 (50%)LINE 205/730 (28%)CONDITIONAL 69/390 (18%) libs.main FILES 27/74 (36%)CLASSES 27/74 (36%)LINE 709/7217 (10%)CONDITIONAL 771/17165 (4%) libs.main.config FILES 0/3 (0%)CLASSES 0/3 (0%)LINE 0/218 (0%)CONDITIONAL 0/478 (0%) libs.main.gemini FILES 0/1 (0%)CLASSES 0/1 (0%)LINE 0/2 (0%)CONDITIONAL 0/0 (100%) libs.main.tests FILES 7/7 (100%)CLASSES 7/7 (100%)LINE 258/271 (95%)CONDITIONAL 138/236 (58%) libs.odf FILES 39/46 (85%)CLASSES 39/46 (85%)LINE 2087/5584 (37%)CONDITIONAL 1318/4284 (31%) libs.odf.tests FILES 17/17 (100%)CLASSES 17/17 (100%)LINE 4854/5100 (95%)CONDITIONAL 3516/7158 (49%) libs.odf.writeodf FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 77/106 (73%)CONDITIONAL 29/59 (49%) libs.pageapp FILES 15/35 (43%)CLASSES 15/35 (43%)LINE 543/3106 (17%)CONDITIONAL 271/1791 (15%) libs.pageapp.commands FILES 3/7 (43%)CLASSES 3/7 (43%)LINE 97/180 (54%)CONDITIONAL 63/124 (51%) libs.pageapp.dialogs FILES 0/4 (0%)CLASSES 0/4
Re: Selecting the needed po catalogs in the module dir (was: Re: calligra 3.0.0 tarball)
El dijous, 8 de desembre de 2016, a les 20:44:34 CET, Friedrich W. H. Kossebau va escriure: > Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb Dag: > > Boudewijn Rempt skrev den 2016-12-08 11:53: > > > On Thu, 8 Dec 2016, Dag wrote: > > >> Boudewijn Rempt skrev den 2016-12-08 11:13: > > >> > On Thu, 8 Dec 2016, Dag wrote: > > >> > > Hmmm, well does this mean krita translations will be > > >> > > released/packaged > > >> > > with > > >> > > calligra release? If so, there is bound to be problems sooner or > > >> > > later. Or > > >> > > is/can this be taken care of in some way? > > >> > > > >> > I guess I can add some code, if I remember a bit of ruby (it's years > > >> > since > > >> > I last used it) to skip everything that sounds like krita or kexi. > > >> > > >> Yes well, when calligra is released, when krita is released skip > > >> calligra/kexi, and when kexi is released... > > >> Maybe the best solution, but doesn't sound great. > > > > > > Well, for Krita, we only have krita.po with everything in it -- so that > > > works > > > out automatically. I'm not sure about kexi, though. > > > > Ehhh, no not quite, there is also desktop_calligra_krita.po and > > org.kde.krita.appdata.po, but still... > > Po catalogs like *appdata.po, desktop_*.po, json_*.po are not to be included > in the release tarballs, those are just some translation process artifacts. > Their content is merged into the sources already every time scripty runs, > have a look e.g. into the appdata or desktop files. Thus no need for having > another copy by the separate catalogs, nothing will use them at runtime. > (IMHO they would be in a separate namespace on the server to not confuse > release managers, but such a change did not have enough supporters: > https://marc.info/?l=kde-i18n-doc=146615836224833=1) > > So Krita just packaging krita.po files is correct, as they only have that > one single runtime catalog file for all of the Krita source code. > > > My concern is the future when something is added/changed. > > > > I can't see more than two possible sustainable solutions: > > Best: split calligra, kexi and krita properly both in git and svn. > > > > Not so good: Make some cmake magic to install only the po files we can > > generate pot files for. This will work for all of us, except that there > > will be another special solution to maintain. But it will not solve the > > "problem" that it is less straight forward for the translators as always > > only parts of "calligra" (as they see it) is released. > > Another hack might be to have some script to find all Messages.sh in the > source code and extract the catalog name from them. > Either by crude parsing the existing ones and grep for the .pot > content, or a more engineered approach by adding code to all Messages.sh > files to output the name of the catalog file(s) created when called with > some argument like --just-dump-the-catalog-base-name-please. yes, this, i asked for people volunteering to make a proposal for this a while ago, noone raised their hand though. Cheers, Albert > > @Luigi, IIRC you are working on a similar challenge when it comes to KDE > Application tarballs, where in the future the po files should be inside the > respective source code tarballs, no longer in a separate one. > What approach are you taking there? > > Cheers > Friedrich
Selecting the needed po catalogs in the module dir (was: Re: calligra 3.0.0 tarball)
Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb Dag: > Boudewijn Rempt skrev den 2016-12-08 11:53: > > On Thu, 8 Dec 2016, Dag wrote: > >> Boudewijn Rempt skrev den 2016-12-08 11:13: > >> > On Thu, 8 Dec 2016, Dag wrote: > >> > > Hmmm, well does this mean krita translations will be > >> > > released/packaged > >> > > with > >> > > calligra release? If so, there is bound to be problems sooner or > >> > > later. Or > >> > > is/can this be taken care of in some way? > >> > > >> > I guess I can add some code, if I remember a bit of ruby (it's years > >> > since > >> > I last used it) to skip everything that sounds like krita or kexi. > >> > >> Yes well, when calligra is released, when krita is released skip > >> calligra/kexi, and when kexi is released... > >> Maybe the best solution, but doesn't sound great. > > > > Well, for Krita, we only have krita.po with everything in it -- so that > > works > > out automatically. I'm not sure about kexi, though. > > Ehhh, no not quite, there is also desktop_calligra_krita.po and > org.kde.krita.appdata.po, but still... Po catalogs like *appdata.po, desktop_*.po, json_*.po are not to be included in the release tarballs, those are just some translation process artifacts. Their content is merged into the sources already every time scripty runs, have a look e.g. into the appdata or desktop files. Thus no need for having another copy by the separate catalogs, nothing will use them at runtime. (IMHO they would be in a separate namespace on the server to not confuse release managers, but such a change did not have enough supporters: https://marc.info/?l=kde-i18n-doc=146615836224833=1) So Krita just packaging krita.po files is correct, as they only have that one single runtime catalog file for all of the Krita source code. > My concern is the future when something is added/changed. > > I can't see more than two possible sustainable solutions: > Best: split calligra, kexi and krita properly both in git and svn. > > Not so good: Make some cmake magic to install only the po files we can > generate pot files for. This will work for all of us, except that there > will be another special solution to maintain. But it will not solve the > "problem" that it is less straight forward for the translators as always > only parts of "calligra" (as they see it) is released. Another hack might be to have some script to find all Messages.sh in the source code and extract the catalog name from them. Either by crude parsing the existing ones and grep for the .pot content, or a more engineered approach by adding code to all Messages.sh files to output the name of the catalog file(s) created when called with some argument like --just-dump-the-catalog-base-name-please. @Luigi, IIRC you are working on a similar challenge when it comes to KDE Application tarballs, where in the future the po files should be inside the respective source code tarballs, no longer in a separate one. What approach are you taking there? Cheers Friedrich
Re: calligra 3.0.0 tarball
Boudewijn Rempt skrev den 2016-12-08 11:53:
On Thu, 8 Dec 2016, Dag wrote:
Boudewijn Rempt skrev den 2016-12-08 11:13:
> On Thu, 8 Dec 2016, Dag wrote:
>
> > Hmmm, well does this mean krita translations will be released/packaged
> > with
> > calligra release? If so, there is bound to be problems sooner or later. Or
> > is/can this be taken care of in some way?
>
> I guess I can add some code, if I remember a bit of ruby (it's years since
> I last used it) to skip everything that sounds like krita or kexi.
Yes well, when calligra is released, when krita is released skip
calligra/kexi, and when kexi is released...
Maybe the best solution, but doesn't sound great.
Well, for Krita, we only have krita.po with everything in it -- so that
works
out automatically. I'm not sure about kexi, though.
Ok, short term solution (note: never programmed in ruby): could we add
an excludepo entry in config.ini so we get something like this for
calligra:
[calligra]
gitModule = yes
gitTag = v3.0.0.0
mainmodule = calligra
submodule = calligra
version = 3.0.99.90
translations= yes
docs= no
kde_release = no
wholeModule = yes
excludepo = *krita*,*kexi*
For kexi/krita, if you have only one po file as you say it works out of
the box, if you have more po files you can use the:
custompo
attribute to list all your po files.
We then need something like this for calligra:
if appdata["wholeModule"]
(...)
for pofile in appdata["excludepo"].split(/,/)
`rm -f #{dest}/#{pofile}.po`
end
add to the create_tarball_kf5.rb
Re: calligra 3.0.0 tarball
Boudewijn Rempt skrev den 2016-12-08 11:53: On Thu, 8 Dec 2016, Dag wrote: Boudewijn Rempt skrev den 2016-12-08 11:13: > On Thu, 8 Dec 2016, Dag wrote: > > > Hmmm, well does this mean krita translations will be released/packaged > > with > > calligra release? If so, there is bound to be problems sooner or later. Or > > is/can this be taken care of in some way? > > I guess I can add some code, if I remember a bit of ruby (it's years since > I last used it) to skip everything that sounds like krita or kexi. Yes well, when calligra is released, when krita is released skip calligra/kexi, and when kexi is released... Maybe the best solution, but doesn't sound great. Well, for Krita, we only have krita.po with everything in it -- so that works out automatically. I'm not sure about kexi, though. Ehhh, no not quite, there is also desktop_calligra_krita.po and org.kde.krita.appdata.po, but still... My concern is the future when something is added/changed. I can't see more than two possible sustainable solutions: Best: split calligra, kexi and krita properly both in git and svn. Not so good: Make some cmake magic to install only the po files we can generate pot files for. This will work for all of us, except that there will be another special solution to maintain. But it will not solve the "problem" that it is less straight forward for the translators as always only parts of "calligra" (as they see it) is released.
Re: calligra 3.0.0 tarball
On Thu, 8 Dec 2016, Dag wrote: > > > Boudewijn Rempt skrev den 2016-12-08 11:13: > > On Thu, 8 Dec 2016, Dag wrote: > > > > > Hmmm, well does this mean krita translations will be released/packaged > > > with > > > calligra release? If so, there is bound to be problems sooner or later. Or > > > is/can this be taken care of in some way? > > > > I guess I can add some code, if I remember a bit of ruby (it's years since > > I last used it) to skip everything that sounds like krita or kexi. > Yes well, when calligra is released, when krita is released skip > calligra/kexi, and when kexi is released... > Maybe the best solution, but doesn't sound great. > Well, for Krita, we only have krita.po with everything in it -- so that works out automatically. I'm not sure about kexi, though. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: calligra 3.0.0 tarball
Boudewijn Rempt skrev den 2016-12-08 11:13: On Thu, 8 Dec 2016, Dag wrote: Hmmm, well does this mean krita translations will be released/packaged with calligra release? If so, there is bound to be problems sooner or later. Or is/can this be taken care of in some way? I guess I can add some code, if I remember a bit of ruby (it's years since I last used it) to skip everything that sounds like krita or kexi. Yes well, when calligra is released, when krita is released skip calligra/kexi, and when kexi is released... Maybe the best solution, but doesn't sound great.
Re: calligra 3.0.0 tarball
Boudewijn Rempt skrev den 2016-12-08 10:12: On Thu, 8 Dec 2016, Dag wrote: Ok, it seems good, a lot of po-files present, even too many I think. There are some krita and kexi stuff included, guess these should be deleted from po repository? I'm not too sure about that -- there was some problem with creating a new top-level mainmodule for krita, so krita's still somehow in the calligra hierarchy. That's why the create-tarball config for krita is like this: [krita] gitModule = yes gitTag = v3.0.94 mainmodule = calligra submodule = krita version = 3.0.94 translations= yes docs= no kde_release = no Hmmm, well does this mean krita translations will be released/packaged with calligra release? If so, there is bound to be problems sooner or later. Or is/can this be taken care of in some way?
Re: calligra 3.0.0 tarball
On Thu, 8 Dec 2016, Dag wrote: > Ok, it seems good, a lot of po-files present, even too many I think. > There are some krita and kexi stuff included, guess these should be deleted > from po repository? I'm not too sure about that -- there was some problem with creating a new top-level mainmodule for krita, so krita's still somehow in the calligra hierarchy. That's why the create-tarball config for krita is like this: [krita] gitModule = yes gitTag = v3.0.94 mainmodule = calligra submodule = krita version = 3.0.94 translations= yes docs= no kde_release = no -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: calligra 3.0.0 tarball
Ok, it seems good, a lot of po-files present, even too many I think. There are some krita and kexi stuff included, guess these should be deleted from po repository?
