Re: Calligra and Okular versions
El divendres, 9 de desembre de 2016, a les 15:49:08 CET, Jonathan Riddell va escriure: > Recently Okular's internal version changed and so did the requirement > for Okular by Calligra. > > Okular is now set to 0.99.0 for the stable Applications/16.12 branch > and Calligra wants 0.99.60. I fucked up with the version increase. Cheers, Albert > > How before these versions changed I had a version of Calligra master > (due to become 3.0.0 shortly) which compiled fine with Okular from > Applications/16.12 > http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/1/ > > It would be a shame if Calligra released without a version of Okular > that it worked with also being released. Does Calligra work with > Okular from Applications/16.12 ? > > Jonathan
Re: Calligra and Okular versions
On Friday, 9 December 2016 at 15:49, Jonathan Riddell wrote:
> Okular is now set to 0.99.0 for the stable Applications/16.12 branch
> and Calligra wants 0.99.60.
I was puzzled how that could happen again, since I made the calligra commit
that dialled back the okular requirement from 1.0.0 to 0.99.60 (which worked a
few weeks ago). That was necessary due to okular commit
ebeeac8d72b258b516929344b43ceec3a57e06e7 setting version to
0.99.${KDE_APPLICATIONS_VERSION_MICRO}
which was bound to break (go backwards) when moving from beta/RC numbers
16.11.60 to 16.12.0 release.
Regards,
Andreas
Re: Calligra and Okular versions
On Fri, Dec 09, 2016 at 07:55:30PM +0100, Andreas Sturmlechner wrote:
> On Friday, 9 December 2016 at 15:49, Jonathan Riddell wrote:
> > Okular is now set to 0.99.0 for the stable Applications/16.12 branch
> > and Calligra wants 0.99.60.
>
> I was puzzled how that could happen again, since I made the calligra commit
> that dialled back the okular requirement from 1.0.0 to 0.99.60 (which worked
> a
> few weeks ago). That was necessary due to okular commit
> ebeeac8d72b258b516929344b43ceec3a57e06e7 setting version to
>
> 0.99.${KDE_APPLICATIONS_VERSION_MICRO}
>
> which was bound to break (go backwards) when moving from beta/RC numbers
> 16.11.60 to 16.12.0 release.
I highlighted a related issue not long ago
https://marc.info/?l=kde-devel=147929111915475=2
Jonathan
Re: Calligra and Okular versions
> Depending on whether 16.12.0 tarballs have already been made either Calligra > needs to adapt to that now, or Okular could still get fixed. tars have been made for 16.12 but aren't released until next week so maybe Albert can update that Jonathan
Re: Calligra and Okular versions
Thanks for the heads-up, Jonathan.
Am Freitag, 9. Dezember 2016, 15:49:08 CET schrieb Jonathan Riddell:
> Recently Okular's internal version changed and so did the requirement
> for Okular by Calligra.
>
> Okular is now set to 0.99.0 for the stable Applications/16.12 branch
> and Calligra wants 0.99.60.
>
> How before these versions changed I had a version of Calligra master
> (due to become 3.0.0 shortly) which compiled fine with Okular from
> Applications/16.12
> http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/1/
>
> It would be a shame if Calligra released without a version of Okular
> that it worked with also being released. Does Calligra work with
> Okular from Applications/16.12 ?
Yes, it does.
What happened is that Okular has
ecm_setup_version(0.99.${KDE_APPLICATIONS_VERSION_MICRO}
VARIABLE_PREFIX OKULAR
VERSION_HEADER "${CMAKE_CURRENT_BINARY_DIR}/core/version.h"
PACKAGE_VERSION_FILE "${CMAKE_CURRENT_BINARY_DIR}/
Okular5ConfigVersion.cmake")
and someone bumped KDE_APPLICATIONS_VERSION_MICRO from 90 to 0, but noone made
sure the 0.99 gets bumped too. :/
Depending on whether 16.12.0 tarballs have already been made either Calligra
needs to adapt to that now, or Okular could still get fixed.
Cheers
Friedrich
Calligra and Okular versions
Recently Okular's internal version changed and so did the requirement for Okular by Calligra. Okular is now set to 0.99.0 for the stable Applications/16.12 branch and Calligra wants 0.99.60. How before these versions changed I had a version of Calligra master (due to become 3.0.0 shortly) which compiled fine with Okular from Applications/16.12 http://build.neon.kde.org/job/xenial_stable_calligra_calligra_bin_amd64/1/ It would be a shame if Calligra released without a version of Okular that it worked with also being released. Does Calligra work with Okular from Applications/16.12 ? Jonathan
Re: Selecting the needed po catalogs in the module dir
Luigi Toscano skrev den 2016-12-09 00:10: In data giovedì 8 dicembre 2016 20:44:34 CET, Friedrich W. H. Kossebau ha scritto: Am Donnerstag, 8. Dezember 2016, 12:11:26 CET schrieb Dag: > Boudewijn Rempt skrev den 2016-12-08 11:53: > > 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? Parsing the Messages.sh file. See the attached functions which comes from the work in progress (you can use it in the scripts which a license which matches the KDE Policy license), the extraction works well in my testing. Where in the infrastructure would this go? Just for the record, the script will not work out of the box for calligra because we have construct like: calligra_xgettext calligra.pot $LIST but we could of course change all Message.sh to conform to requirements. My long term idea is to get rid of Messages.sh and use a declarative format (which can be a simple INI file) to define which translation files exists and which files are associated to them, with a separate engine with pluggable support for different translatable artifacts (regular gettext, json, etc).
