Discussion:
Building DigiKam 4.14 with libkgeomanip and other former "extras"
Steve M. Robbins
2015-12-20 23:22:07 UTC
Permalink
Hi,

I'm preparing DigiKam 4.x packages for Debian. While I've used KDE for ages,
I'm new to the development side, so I have a couple questions.

The previous Debian package was DigiKam 4.4. I just created an initial 4.14
package. Between 4.4 and 4.14, several "extra" libraries were split out and
are no longer distributed in the digikam source: libkdcraw libkexiv2
libkface libkgeomap libkipi libksane libkvkontakte libmediawiki. Several
of these are already packaged in Debian and I just used them in the build.

Others are not yet packaged for Debian (e.g. libkgeomap and libkface) so I had
to drop functionality temporarily. Now I'm looking for the canonical source
location of these former "extras".

Question 1: Given that I'm building DigiKam 4.x, I presume I'll need a
KDE4/Qt4 version of each extra. Is that the case?


The first place I found was https://www.digikam.org/sharedlibs where I can find
links some of these extras, including kface and geomap. The kface link
takes me to
https://projects.kde.org/projects/kde/kdegraphics/libs/libkface/repository but
here the latest commit is March 2015. The geomap link has bitrotted and
brings up a 404.

Next, I found http://download.kde.org/stable/applications/15.12.0/src/ which
has kface and geomanip. Debian has an "experimental" package for kface that
is version 15.04.0, built against KDE4/Qt4. The new 15.12 version builds
against KF5 and Qt5. The geomap v15.12 sources also build against KF5.

Question 2: If I can't use the latest kface, should I just go backwards in
time to find the last release using KDE4 and use that with DigiKam?


Thanks,
-Steve
Lisandro Damián Nicanor Pérez Meyer
2015-12-21 15:54:46 UTC
Permalink
Post by Steve M. Robbins
Hi,
I'm preparing DigiKam 4.x packages for Debian. While I've used KDE for
ages, I'm new to the development side, so I have a couple questions.
The previous Debian package was DigiKam 4.4. I just created an initial 4.14
package. Between 4.4 and 4.14, several "extra" libraries were split out
and are no longer distributed in the digikam source: libkdcraw libkexiv2
libkface libkgeomap libkipi libksane libkvkontakte libmediawiki.
Several of these are already packaged in Debian and I just used them in the
build.
\o/ Those are really fabulous news!
Post by Steve M. Robbins
Others are not yet packaged for Debian (e.g. libkgeomap and libkface) so I
had to drop functionality temporarily. Now I'm looking for the canonical
source location of these former "extras".
Question 1: Given that I'm building DigiKam 4.x, I presume I'll need a
KDE4/Qt4 version of each extra. Is that the case?
It should be, you can't mix Qt4 and Qt5 (we will be able to do so at some
extent with Qt5 and Qt6, but that's another story).

[snip]
Post by Steve M. Robbins
Question 2: If I can't use the latest kface, should I just go backwards in
time to find the last release using KDE4 and use that with DigiKam?
I'm afraid yes.

Another solution could be to just build the 5.0.0 beta2 which, if I'm not
mistaken, uses Qt5/KF5. And maybe push it to experimental.
--
My favourite poem is the one that starts 'Thirty days hath September' because
it actually tells you something.
-- Groucho Marx

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Steve M. Robbins
2015-12-22 02:49:34 UTC
Permalink
[Since the conversation is now Debian-specific, I trimmed digikam-devel]
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Steve M. Robbins
Question 1: Given that I'm building DigiKam 4.x, I presume I'll need a
KDE4/Qt4 version of each extra. Is that the case?
It should be, you can't mix Qt4 and Qt5
OK. Thanks for confirming.
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Steve M. Robbins
Question 2: If I can't use the latest kface, should I just go backwards in
time to find the last release using KDE4 and use that with DigiKam?
I'm afraid yes.
Another solution could be to just build the 5.0.0 beta2 which, if I'm not
mistaken, uses Qt5/KF5. And maybe push it to experimental.
I am aware of 5.x betas. I hesitate to use them right now because of the
"beta" status. The announcement post itself [1] says "This version is for
testing purposes. It’s not currently advised to use it in production."

Maybe this is overcautious? Opinions welcome.


If we do stick with the stable branch, we are probably stuck with it until
next May [2]. So now the question is: for the "former extras" build-deps --
how do we co-exist the KDE4 and KF5 versions? Can the lib packages be made
co-installable? Is there a package naming convention?

From a quick build of libkface 15.04 (KDE4) and 15.12 (KF5) I can see the
libraries are named differently (libkface.so / libKF5KFace.so). This gives me
hope that at least the libs can remain co-installable. Additionally, the
includes are in separate sub-dirs of /usr/include so maybe even the -dev
packages can be co-installable?

Thoughts / advice?

Thanks,
-Steve

[1] https://www.digikam.org/node/749
[2] https://www.digikam.org/about/releaseplan
Adam Majer
2015-12-22 03:18:29 UTC
Permalink
Post by Steve M. Robbins
I am aware of 5.x betas. I hesitate to use them right now because of the
"beta" status. The announcement post itself [1] says "This version is for
testing purposes. It’s not currently advised to use it in production."
Maybe this is overcautious? Opinions welcome.
I think this is overcautious. Qt 4 is to be removed from Debian so
removing dependencies on Qt 4 is preferred to adding new ones.

- Adam
--
Adam Majer
***@zombino.com
--
http://lists.alioth.debian.org/cgi-bin/mai
Steve M. Robbins
2015-12-22 04:36:18 UTC
Permalink
Post by Adam Majer
Post by Steve M. Robbins
I am aware of 5.x betas. I hesitate to use them right now because of the
"beta" status. The announcement post itself [1] says "This version is for
testing purposes. It’s not currently advised to use it in production."
Maybe this is overcautious? Opinions welcome.
I think this is overcautious. Qt 4 is to be removed from Debian so
removing dependencies on Qt 4 is preferred to adding new ones.
Well, yes: all things being equal, I'd agree it is folly to create new Qt4
packages.

However, the question I am asking is about the quality of DigiKam "beta 5.x"
vis-a-vis "stable 4.x". I don't know that these are equal in quality. The
note from the DigiKam maintainers suggests they are not.

-Steve
Scott Kitterman
2015-12-22 04:38:41 UTC
Permalink
Post by Steve M. Robbins
Post by Steve M. Robbins
I am aware of 5.x betas. I hesitate to use them right now because of
the
Post by Steve M. Robbins
"beta" status. The announcement post itself [1] says "This version
is for
Post by Steve M. Robbins
testing purposes. It’s not currently advised to use it in
production."
Post by Steve M. Robbins
Maybe this is overcautious? Opinions welcome.
I think this is overcautious. Qt 4 is to be removed from Debian so
removing dependencies on Qt 4 is preferred to adding new ones.
Digikam is notoriously difficult to package before final release due to depending on unreleased library versions and/or embedded code copies. Not packaging pre-release versions of Digikam is an eminently reasonable thing to do. This is particularly true right now when no one else was working on it at all AFAICT.

It's not entirely clear is we'll succeed in getting entirely rid of Qt4 this cycle. The thing we know for sure is going away is QtWebKit for Qt4.

Scott K
--
http://lists.alioth.debian.org/cg
Dmitry Shachnev
2015-12-22 11:31:11 UTC
Permalink
Hi all,
Post by Scott Kitterman
Digikam is notoriously difficult to package before final release due to
depending on unreleased library versions and/or embedded code copies. Not
packaging pre-release versions of Digikam is an eminently reasonable thing
to do. This is particularly true right now when no one else was working on
it at all AFAICT.
It's not entirely clear is we'll succeed in getting entirely rid of Qt4 this
cycle. The thing we know for sure is going away is QtWebKit for Qt4.
If nobody is developing a Qt 5.x version of Digikam, then maybe packaging the
Qt 4.x version is OK. Otherwise I would rather not introduce any new Qt 4.x
packages to Debian (especially provided that the official support for Qt 4
ended 3 days ago [1]).

[1]: http://blog.qt.io/blog/2014/11/27/qt-4-8-x-support-to-be-extended-for-another-year/

--
Dmitry Shachnev
Scott Kitterman
2015-12-22 12:08:06 UTC
Permalink
Post by Dmitry Shachnev
Hi all,
Post by Scott Kitterman
Digikam is notoriously difficult to package before final release due
to
Post by Scott Kitterman
depending on unreleased library versions and/or embedded code copies.
Not
Post by Scott Kitterman
packaging pre-release versions of Digikam is an eminently reasonable
thing
Post by Scott Kitterman
to do. This is particularly true right now when no one else was
working on
Post by Scott Kitterman
it at all AFAICT.
It's not entirely clear is we'll succeed in getting entirely rid of
Qt4 this
Post by Scott Kitterman
cycle. The thing we know for sure is going away is QtWebKit for Qt4.
If nobody is developing a Qt 5.x version of Digikam, then maybe
packaging the
Qt 4.x version is OK. Otherwise I would rather not introduce any new Qt 4.x
packages to Debian (especially provided that the official support for Qt 4
ended 3 days ago [1]).
It's not a new package. It was just behind several releases and the question was to either update to the last Qt4 release or an unreleased Qt5 version.

In standard Debian style the person doing the work decided (well IMO) and we who didn't do the work ought to lay off the second guessing.

Scott K
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
Dmitry Shachnev
2015-12-22 12:52:00 UTC
Permalink
Hi Scott,
Post by Scott Kitterman
It's not a new package. It was just behind several releases and the
question was to either update to the last Qt4 release or an unreleased Qt5
version.
By “new package” I meant kgeomanip, which was never packaged.

--
Dmitry Shachnev
Lisandro Damián Nicanor Pérez Meyer
2015-12-22 12:58:37 UTC
Permalink
Post by Dmitry Shachnev
Hi Scott,
Post by Scott Kitterman
It's not a new package. It was just behind several releases and the
question was to either update to the last Qt4 release or an unreleased Qt5
version.
By “new package” I meant kgeomanip, which was never packaged.
As long as it doesn't depends on qtwebkit we should be fine.

Steve: if you need to add it just go ahead please. As you said Digikam is
expected to switch to Qt5 later next year so it's worth the effort.

Thanks a lot for your time on it!
--
En 1975, a los 99 años, muere Leonor Acevedo de Borges. En el velorio, una
mujer da el pésame a Borges y comenta: "Pobre Leonorcita, morirse tan poquito
antes de cumplir los 100 años. Si hubiera esperado un poquito más...".
Borges responde: "Veo, señora, que es usted devota del sistema decimal".
Jorge Luis Borges, en "Borges habla de su madre". http://2tu.us/2i7d

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Steve M. Robbins
2015-12-27 18:08:45 UTC
Permalink
Hi,

Thanks a lot to all who responded. I sense a strong feeling against
introducing new Qt4-based packages right now. And this makes sense to me.

Given that my only motivation for a Qt4 version of these libraries is for
DigiKam 4.x, I will propose instead to avoid the new library packages by
bundling the sources into digikam. This is, essentially, returning to the
situation with DigiKam 4.4, which included sources for the following:
libkdcraw libkexiv2 libkface libkgeomap libkipi libksane libkvkontakte
libmediawiki. Some of these are currently in the archive as Qt4 versions and
some are not. My strategy would be to bundle the minimum necessary.

I know the Debian stance on "convenience" copies of libraries, but in this
case (a) no-one wants or needs a new Qt4 version of these libraries, and (b)
it is temporary as DigiKam 4.x is going away within 6 months.

Let me know if you have a better idea.
Post by Lisandro Damián Nicanor Pérez Meyer
Post by Dmitry Shachnev
Hi Scott,
Post by Scott Kitterman
It's not a new package. It was just behind several releases and the
question was to either update to the last Qt4 release or an unreleased Qt5
version.
By “new package” I meant kgeomanip, which was never packaged.
It was never packaged independently, but was always used as part of digikam.
Post by Lisandro Damián Nicanor Pérez Meyer
As long as it doesn't depends on qtwebkit we should be fine.
DigiKam itself currently uses (Qt4-version) libqtwebkit-dev. I saw the bug
about it and the web page https://wiki.debian.org/Qt4WebKitRemoval
What I haven't seen is a precise time for this. The schedule for Digikam 5
release is May, so I (hopefully) won't need to care after that. Is the webkit
going to be removed before next May?

Thanks,
-Steve
Lisandro Damián Nicanor Pérez Meyer
2015-12-27 18:20:14 UTC
Permalink
Post by Steve M. Robbins
Hi,
Thanks a lot to all who responded. I sense a strong feeling against
introducing new Qt4-based packages right now. And this makes sense to me.
Given that my only motivation for a Qt4 version of these libraries is for
DigiKam 4.x, I will propose instead to avoid the new library packages by
bundling the sources into digikam. This is, essentially, returning to the
libkdcraw libkexiv2 libkface libkgeomap libkipi libksane libkvkontakte
libmediawiki. Some of these are currently in the archive as Qt4 versions
and some are not. My strategy would be to bundle the minimum necessary.
I know the Debian stance on "convenience" copies of libraries, but in this
case (a) no-one wants or needs a new Qt4 version of these libraries, and (b)
it is temporary as DigiKam 4.x is going away within 6 months.
Let me know if you have a better idea.
I would simply say: ship it. I think that in this *very specific* case it's
the right way to go.
--
15: Que es el "Correo Electronico"
* El correo que te llega por la corriente
Damian Nadales
http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Dmitry Shachnev
2015-12-28 12:07:12 UTC
Permalink
Hi Steve,
Post by Steve M. Robbins
DigiKam itself currently uses (Qt4-version) libqtwebkit-dev. I saw the bug
about it and the web page https://wiki.debian.org/Qt4WebKitRemoval
What I haven't seen is a precise time for this. The schedule for Digikam 5
release is May, so I (hopefully) won't need to care after that. Is the webkit
going to be removed before next May?
Actually I would like it to be removed before May. I am going to bump bugs
severities to important soon (in January) and make them RC a couple of months
after that (i.e. in March) to get the packages removed from testing (or fixed).

I am also going to remove the PyQt5 QtWebKit bindings very soon (in a couple
of weeks).

So maybe it's not the best idea to introduce a new package using QtWebKit.

Lisandro, you did not reply to this part of Steve's message, what do you think?

--
Dmitry Shachnev
Steve Robbins
2015-12-28 13:30:52 UTC
Permalink
Just for clarity: I'm talking about digikam not a new package.
Post by Dmitry Shachnev
Hi Steve,
Post by Steve M. Robbins
DigiKam itself currently uses (Qt4-version) libqtwebkit-dev. I saw
the bug
Post by Steve M. Robbins
about it and the web page https://wiki.debian.org/Qt4WebKitRemoval
What I haven't seen is a precise time for this. The schedule for
Digikam 5
Post by Steve M. Robbins
release is May, so I (hopefully) won't need to care after that. Is
the webkit
Post by Steve M. Robbins
going to be removed before next May?
Actually I would like it to be removed before May. I am going to bump bugs
severities to important soon (in January) and make them RC a couple of months
after that (i.e. in March) to get the packages removed from testing (or fixed).
I am also going to remove the PyQt5 QtWebKit bindings very soon (in a couple
of weeks).
So maybe it's not the best idea to introduce a new package using QtWebKit.
Lisandro, you did not reply to this part of Steve's message, what do you think?
--
Dmitry Shachnev
------------------------------------------------------------------------
--
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-kde-talk
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Dmitry Shachnev
2015-12-28 18:50:22 UTC
Permalink
Hi Steve,
Post by Steve Robbins
Just for clarity: I'm talking about digikam not a new package.
Oh, I missed the fact that digikam is already depending on qtwebkit.

Then, indeed, please ignore my message and go ahead (as Lisandro said).

--
Dmitry Shachnev

Lisandro Damián Nicanor Pérez Meyer
2015-12-28 18:40:14 UTC
Permalink
Post by Dmitry Shachnev
Hi Steve,
Post by Steve M. Robbins
DigiKam itself currently uses (Qt4-version) libqtwebkit-dev. I saw the bug
about it and the web page https://wiki.debian.org/Qt4WebKitRemoval
What I haven't seen is a precise time for this. The schedule for Digikam 5
release is May, so I (hopefully) won't need to care after that. Is the
webkit going to be removed before next May?
Actually I would like it to be removed before May. I am going to bump bugs
severities to important soon (in January) and make them RC a couple of
months after that (i.e. in March) to get the packages removed from testing
(or fixed).
I am also going to remove the PyQt5 QtWebKit bindings very soon (in a couple
of weeks).
So maybe it's not the best idea to introduce a new package using QtWebKit.
Lisandro, you did not reply to this part of Steve's message, what do you think?
We need a kf5-based kdepim in unstable first. I was told that current packages
in experimental are not ready for unstable yet.
--
When the winds of change are blowing, some people are building shelters, and
others are building windmills.
Old Chinese Proverb

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Lisandro Damián Nicanor Pérez Meyer
2015-12-28 18:45:48 UTC
Permalink
On Monday 28 December 2015 15:40:14 Lisandro Damián Nicanor Pérez Meyer wrote:
[snip]
Post by Lisandro Damián Nicanor Pérez Meyer
We need a kf5-based kdepim in unstable first. I was told that current
packages in experimental are not ready for unstable yet.
For what it's worth digikam is already in the archive, so just go ahead Steve.
--
Programming is really just the mundane aspect of expressing a solution to a
problem. There are talents that are specifically related to actually coding,
but the real issue is being able to grasp problems and devise solutions that
are detailed enough to actually be coded.
John Carmack answers on Slashdot,
http://slashdot.org/games/99/10/15/1012230.shtml

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Scott Kitterman
2015-12-22 12:59:40 UTC
Permalink
Post by Dmitry Shachnev
Hi Scott,
Post by Scott Kitterman
It's not a new package. It was just behind several releases and the
question was to either update to the last Qt4 release or an unreleased Qt5
version.
By “new package” I meant kgeomanip, which was never packaged.
Ah. That's a bit different. I still think it's not a problem if a Qt5 version
is coming soon.

Scott K
--
http://lists.aliot
Lisandro Damián Nicanor Pérez Meyer
2015-12-22 12:55:25 UTC
Permalink
On Monday 21 December 2015 23:38:41 Scott Kitterman wrote:
[snip]
Post by Scott Kitterman
Post by Adam Majer
I think this is overcautious. Qt 4 is to be removed from Debian so
removing dependencies on Qt 4 is preferred to adding new ones.
Digikam is notoriously difficult to package before final release due to
depending on unreleased library versions and/or embedded code copies. Not
packaging pre-release versions of Digikam is an eminently reasonable thing
to do. This is particularly true right now when no one else was working on
it at all AFAICT.
+1
Post by Scott Kitterman
It's not entirely clear is we'll succeed in getting entirely rid of Qt4 this
cycle. The thing we know for sure is going away is QtWebKit for Qt4.
Qt4 will bee too difficult, qt4's webkit has to go.
--
Simulations are like miniskirts, they show a lot and hide the essentials.
Hubert Kirrman

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
Loading...