KDE Applications 17.04.0 packages available for packagers

[Dennis Nienhüser]

Am 2017-04-17 11:26, schrieb Harald Sitter:
> Well, yeah, but, that's not a **problem** ;)
> Inconsistent, sure, it has no impact on anything though. We have loads
> of libs where the soversion is not equal to the build version.
> 
> The problem you are having is that digikam needs rebuilding against
> the new marble ABI.
> 
> All said, I think the marble team should just use 0.xx.0 as version
> and xx as soversion and bump both once. Given the build version has no
> impact on the soversioning anyway there is no point in sub-versioning
> it during development. Simply bump to 0.27.0/0.28.0/... during
> development once. Unless the bump gets automated people will always
> forget to do the final release bump, so it could just be done away
> with. That way the versions are always aligned and the marble devs
> have less to worry about.
> As long as the soversion is different across feature releases it will 
> be fine.

+1. Seems a nice pragmatic solution. I'll adopt that directly (i.e. 
change the version
bump script accordingly and apply it to current master).

> I think this discussion should be moved to the marble list though. It
> doesn't really impact the release team.

CC marble-devel.

> On Mon, Apr 17, 2017 at 10:39 AM, Heinz Wiesinger 
> <pprkut at slackware.com> wrote:
>> On Monday, 17 April 2017 10:01:29 CEST Harald Sitter wrote:
>>> On Sun, Apr 16, 2017 at 5:44 PM, Eric Hameleers <alien at slackware.com> 
>>> wrote:
>>> > On Fri, 14 Apr 2017, Albert Astals Cid wrote:
>>> >> At the usual location.
>>> >>
>>> >> Haven't had time to compile yet, will start now.
>>> >>
>>> >> REVISIONS_AND_HASHES file at https://paste.kde.org/ptskor7sa
>>> >>
>>> >> Public release next week thursday.
>>> >>
>>> >> Cheers,
>>> >>
>>> >>  Albert
>>> >
>>> > After compiling marble, I end up with these library files and links:
>>> >
>>> > $ ll /usr/lib64/libmarblewidget-qt5.so*
>>> > lrwxrwxrwx 1 root root      25 Apr 16 13:07
>>> > /usr/lib64/libmarblewidget-qt5.so -> libmarblewidget-qt5.so.27*
>>> > -rwxr-xr-x 1 root root 7854768 Apr 16 12:56
>>> > /usr/lib64/libmarblewidget-qt5.so.0.26.20*
>>> > lrwxrwxrwx 1 root root      30 Apr 16 13:07
>>> > /usr/lib64/libmarblewidget-qt5.so.27 -> libmarblewidget-qt5.so.0.26.20*
>>> >
>>> > Why the ".so.27"? As a result, digikam (compiled against marble 16.12.3)
>>> > complains with "error while loading shared libraries:
>>> > libmarblewidget-qt5.so.26"
>>> >
>>> > Looking at the library name "libmarblewidget-qt5.so.0.26.20" I would
>>> > expect
>>> > the symlink to end on 26, instead of 27.
>>> >
>>> 
>>> marble does not maintain their ABIs as such they increase their
>>> soversions every feature release.
>> 
>> That's fine, that's not the problem though. The problem is that 
>> version
>> numbers don't match. Checking git I think a commit bumping marble to a 
>> stable
>> version (0.27.0 instead of 0.26.20, which marks a development version) 
>> is
>> missing.
>> 
>> CC'ing Friedrich who did the bump last time for Applications 16.12. 
>> Maybe he
>> can clarify.
>> 
>> Grs,
>> Heinz