Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Martin Steghöfer wrote: It's fine for "libkhtml.so" to request linking to libsoprano. But if it does so, IMHO its corresponding -dev package should make sure that the necessary dependencies are pulled in. Never mind, someone just re-added the missing dependency to kdelibs5-dev, just like I asked. See #799520. Cheers, Martin
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Thank you for your comment, Scott! Let my clarify...
Scott Kitterman wrote:
If there's a warning not to link against it, isn't the solution not to do that?
Yes, of course it would be a solution *not* to link against it, but
"kdelibs5-dev" forces me to do so (that's why I blame it).
That's actually part of the point I was trying to make: My package (as
well as others that are FTBFS'ing in the same way) doesn't actually
*want* to link against libsoprano. It never asks for it. As I said
before: The library libsoprano "is never even mentioned in any of the
CMakeLists.txt files".
It is some CMake magic in kdelibs5-dev's macros that pulls it in. It is
enough to do the following:
/
| KDE4_ADD_EXECUTABLE( myMainApp mymainapp.cxx )
| TARGET_LINK_LIBRARIES( myMainApp ${KDE4_KHTML_LIBS} )
\
That makes "myMainApp" link against libsoprano.
It's fine for "libkhtml.so" to request linking to libsoprano. But if it
does so, IMHO its corresponding -dev package should make sure that the
necessary dependencies are pulled in.
Hope that clears things up a little...
Cheers,
Martin
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
On September 25, 2015 11:29:20 AM CDT, "Martin Steghöfer" wrote: >Dear kdelibs5-dev maintainers, > >One package I worked on is affected by this problem, too. That's why I >started investigating this issue and found out that there is a whole >bunch of packages that are currently (or were recently) FTBFS'ing >because of this problem. Some maintainers employed the workaround of >adding a build dependency to "libsoprano-dev" because that's the only >way they can fix the FTBFS themselves. But it sure feels like a hack, >which is why I'd prefer not to have to do this. > >What's the reason for this odd behaviour? I couldn't really see this >from this bug report, just that it had something to do with "the >transition from nepomuk to the new baloo package". > >Is this going to be fixed properly at some point? I consider adding >"libsoprano-dev" to the Build-Depends of all dependant packages just a >temporary workaround. > >Could we keep this bug open as a reminder that this still needs a >proper >fix? > >To me it feels really wrong to add a build dependency to a library that > >is never even mentioned in any of the CMakeLists.txt files, nor is used > >directly by any of the code (there is even a warning telling me that I >shouldn't have linked against it). Or is there any justification for >seeing libsoprano-dev as a "real" build dependency of packages of that >kind, and I'm just not seeing it? Or a way to get rid of the >"dependency"? If there's a warning not to link against it, isn't the solution not to do that? Scott K
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Dear kdelibs5-dev maintainers, One package I worked on is affected by this problem, too. That's why I started investigating this issue and found out that there is a whole bunch of packages that are currently (or were recently) FTBFS'ing because of this problem. Some maintainers employed the workaround of adding a build dependency to "libsoprano-dev" because that's the only way they can fix the FTBFS themselves. But it sure feels like a hack, which is why I'd prefer not to have to do this. What's the reason for this odd behaviour? I couldn't really see this from this bug report, just that it had something to do with "the transition from nepomuk to the new baloo package". Is this going to be fixed properly at some point? I consider adding "libsoprano-dev" to the Build-Depends of all dependant packages just a temporary workaround. Could we keep this bug open as a reminder that this still needs a proper fix? To me it feels really wrong to add a build dependency to a library that is never even mentioned in any of the CMakeLists.txt files, nor is used directly by any of the code (there is even a warning telling me that I shouldn't have linked against it). Or is there any justification for seeing libsoprano-dev as a "real" build dependency of packages of that kind, and I'm just not seeing it? Or a way to get rid of the "dependency"? Cheers, Martin
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
On Tue, 1 Sep 2015 09:45:33 +0100 Simon McVittie wrote: > On Tue, 01 Sep 2015 at 09:20:17 +0100, Simon McVittie wrote: > > If a particular -dev package requires linking with some other library, > > it should depend on that library's -dev package (the same principle > > as depending on the -dev packages of the libraries mentioned in a > > pkg-config .pc file). > > For kopete, installing libsoprano-dev is enough to build successfully. > I think this means kdelibs5-dev should depend on libsoprano-dev (and the > -dev packages for any other libraries that it indirectly requires > in the same way). > > Adding Build-Depends: libsoprano-dev to kopete seems to be a viable > workaround that would prevent this bug from stalling the libmsn > sub-transition within the libstdc++ transition, and potentially > lower its severity to non-RC. I might NMU kopete with that change if > it becomes necessary. This was unfortunately necessary as part of the transition from nepomuk to the new baloo package. At the time upstream did the switch, it was not well integrated into KDE4 and so we were stuck with dropping some build-depends to get the necessary internal build behavior. As a team, in the Qt-KDE team we've been adding libsoprano-dev to other packages as needed and that's the right thing to do for kopete. Scott K
Re: Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
On Tue, 01 Sep 2015 at 09:20:17 +0100, Simon McVittie wrote: > If a particular -dev package requires linking with some other library, > it should depend on that library's -dev package (the same principle > as depending on the -dev packages of the libraries mentioned in a > pkg-config .pc file). For kopete, installing libsoprano-dev is enough to build successfully. I think this means kdelibs5-dev should depend on libsoprano-dev (and the -dev packages for any other libraries that it indirectly requires in the same way). Adding Build-Depends: libsoprano-dev to kopete seems to be a viable workaround that would prevent this bug from stalling the libmsn sub-transition within the libstdc++ transition, and potentially lower its severity to non-RC. I might NMU kopete with that change if it becomes necessary. S
Bug#797644: kdelibs5-dev: kopete FTBFS: No rule to make target '/usr/lib/libsoprano.so', needed by 'kopete/kopete'
Package: kdelibs5-dev
Version: 4:4.14.10-3
Severity: serious
Justification: kopete fails to build from source (but built successfully in the
past)
Control: affects -1 kopete
X-Debbugs-Cc set to kop...@packages.debian.org since it is known to be
affected.
While building kopete to verify that a proposed upload for libmsn
successfully carries out the libstdc++ transition, I encountered this
build error:
cd kopete && /usr/bin/c++ -DKDE4_CMAKE_TOPLEVEL_DIR_LENGTH=24
-DKDE_DEPRECATED_WARNINGS -DQT_NO_CAST_TO_ASCII -DQT_NO_STL
-DQT_USE_FAST_CONCATENATION -DQT_USE_FAST_OPERATOR_PLUS -D_BSD_SOURCE
-D_DEFAULT_SOURCE -D_REENTRANT -D_XOPEN_SOURCE=500 -g -O2
-fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2
-D_FORTIFY_SOURCE=2 -Wnon-virtual-dtor -Wno-long-long -Wundef -Wcast-align
-Wchar-subscripts -Wall -W -Wpointer-arith -Wformat-security -fno-exceptions
-DQT_NO_EXCEPTIONS -fno-check-new -fno-common -Woverloaded-virtual
-fno-threadsafe-statics -fvisibility=hidden -Werror=return-type
-fvisibility-inlines-hidden -DNDEBUG -DQT_NO_DEBUG -I. -I../../kopete
-I../../libkopete -I../libkopete -I../../libkopete/ui -I../../libkopete/private
-I../../libkopete/contactlist -I../../libkopete/tasks
-I../../kopete/addaccountwizard -Iaddaccountwizard -I../../kopete/statusmenu
-Istatusmenu -I../../kopete/identity -Iidentity -I../../kopete/contactlist
-Icontactlist -I../../kopete/config/plugins -I/usr/include/KDE
-I/usr/include/qt4/KDE -I/usr/include/qt4 -I/usr/include/qt4/phonon
-I/usr/include/qt4/QtXmlPatterns -I/usr/include/qt4/QtXml
-I/usr/include/qt4/QtUiTools -I/usr/include/qt4/QtTest -I/usr/include/qt4/QtSvg
-I/usr/include/qt4/QtSql -I/usr/include/qt4/QtScriptTools
-I/usr/include/qt4/QtScript -I/usr/include/qt4/QtNetwork
-I/usr/include/qt4/QtHelp -I/usr/include/qt4/QtDesigner
-I/usr/include/qt4/QtDeclarative -I/usr/include/qt4/QtDBus
-I/usr/include/qt4/Qt3Support -I/usr/include/qt4/QtGui
-I/usr/include/qt4/QtCore -I/usr/include/qt4/Qt
-I/usr/share/qt4/mkspecs/default -I/usr/include/qimageblitz-D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -o CMakeFiles/kopete_bin.dir/kopeteadaptor.o -c
kopeteadaptor.cpp
make[4]: *** No rule to make target '/usr/lib/libsoprano.so', needed by
'kopete/kopete'. Stop.
This appears to be because KDeclarative's CMake glue mentions that library:
% ack libsoprano /usr/lib
/usr/lib/cmake/KDeclarative/KDeclarativeLibraryTargets-debian.cmake
12: IMPORTED_LINK_INTERFACE_LIBRARIES_DEBIAN "kdeui;/usr/lib/libsoprano.so"
If a particular -dev package requires linking with some other library,
it should depend on that library's -dev package (the same principle
as depending on the -dev packages of the libraries mentioned in a
pkg-config .pc file).
There is an additional, more minor bug here, which could perhaps be fixed
at the same time: that cmake file mentions libsoprano by its fully qualified
path, so kopete would also FTBFS in a similar way if libsoprano was moved
from /usr/lib to /usr/lib/${DEB_HOST_MULTIARCH}. If I'm understanding
correctly, the CMake glue should ideally list system libraries by the
name that would follow the "-l" linker argument, for example "kdeui;soprano",
in the same way that pkg-config would normally result in
"-lkdeui -lsoprano". Please clone a separate bug for this if it is
confirmed but not trivial to fix.
Regards,
S
