Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
Package: soprano-daemon
Followup-For: Bug #639300
Just to tell that unixodbc 2.3.1 has support for driver library name
in connection string (though debian ships 2.2.14).
Thus if a connection manager is wished and also wished is the
ability to provide the library name via connection string it
is reachable.
The only issue with the first patch to get the testsuite completing to
the same level as with iodbc is to provide an odbcinst template that
is lacking from virtuoso.
Updated version of the connection manager and virtuoso odbcinst template
attached.
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.8.0-rc2test0-00197-ge364127 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages soprano-daemon depends on:
ii libc6 2.16-0experimental1
ii libgcc1 1:4.8-20130105-1
ii libodbc12.2.14p2-5
ii libqt4-dbus 4:4.8.2+dfsg-9
ii libqt4-network 4:4.8.2+dfsg-9
ii libqtcore4 4:4.8.2+dfsg-9
ii libraptor2-02.0.8-2
ii librdf0 1.0.15-1+b1
ii libstdc++6 4.8-20130105-1
ii unixodbc2.2.14p2-5
Versions of packages soprano-daemon recommends:
pn libsoprano4 none
Versions of packages soprano-daemon suggests:
ii virtuoso-minimal 6.1.4+dfsg1-2
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/lib/soprano/libsoprano_virtuosobackend.so (from
soprano-daemon package)
[Virtuoso ANSI]
Description = Virtuoso ODBC driver (ANSI version)
Driver = virtodbc_r.so
Setup = virtodbc_r.so
Debug = 0
CommLog = 1
[Virtuoso Unicode]
Description = Virtuoso ODBC driver (Unicode version)
Driver = virtodbcu_r.so
Setup = virtodbcu_r.so
Debug = 0
CommLog = 1
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -90,7 +90,7 @@
include(CheckIncludeFiles)
check_include_files(windows.h;sql.h HAVE_SQL_H)
else(WIN32)
- find_package(IODBC)
+ find_package(ODBC)
endif(WIN32)
endif(NOT SOPRANO_DISABLE_VIRTUOSO_BACKEND)
@@ -119,9 +119,9 @@
set(BUILD_DBUS_SUPPORT TRUE)
endif(NOT SOPRANO_DISABLE_DBUS AND QT_QTDBUS_FOUND)
if(NOT SOPRANO_DISABLE_VIRTUOSO_BACKEND)
- if(IODBC_FOUND OR HAVE_SQL_H)
+ if(ODBC_FOUND OR HAVE_SQL_H)
set(BUILD_VIRTUOSO_BACKEND TRUE)
- endif(IODBC_FOUND OR HAVE_SQL_H)
+ endif(ODBC_FOUND OR HAVE_SQL_H)
endif(NOT SOPRANO_DISABLE_VIRTUOSO_BACKEND)
set(HAVE_DBUS BUILD_DBUS_SUPPORT)
@@ -307,7 +307,7 @@
if(WIN32)
message( * Virtuoso storage backend (missing ODBC headers - http://msdn.microsoft.com/en-us/windows/bb980924.aspx))
else(WIN32)
-message( * Virtuoso storage backend (missing libiodbc - http://www.iodbc.org))
+message( * Virtuoso storage backend (missing unixodbc - http://www.unixodbc.org/))
endif(WIN32)
endif(NOT BUILD_VIRTUOSO_BACKEND)
--- a/backends/virtuoso/CMakeLists.txt
+++ b/backends/virtuoso/CMakeLists.txt
@@ -10,7 +10,7 @@
${soprano_SOURCE_DIR}
${soprano_SOURCE_DIR}/server
${virtuoso_BINARY_DIR}
- ${IODBC_INCLUDE_DIR}
+ ${ODBC_INCLUDE_DIR}
)
set(SRC
@@ -36,7 +36,7 @@
if(WIN32)
target_link_libraries(soprano_virtuosobackend odbc32)
else(WIN32)
-target_link_libraries(soprano_virtuosobackend ${IODBC_LIBRARIES})
+target_link_libraries(soprano_virtuosobackend ${ODBC_LIBRARIES})
endif(WIN32)
if(WIN32)
--- a/backends/virtuoso/virtuosobackend.cpp
+++ b/backends/virtuoso/virtuosobackend.cpp
@@ -117,14 +117,18 @@
#ifdef Q_OS_WIN
const QString odbcDriver = QLatin1String( {Virtuoso (Open Source)} );
#else
+#if 0 /* library name require unixodbc 2.3.1 */
const QString odbcDriver = findVirtuosoDriver();
if ( odbcDriver.isEmpty() ) {
setError( Could not find Virtuoso ODBC driver );
return 0;
}
+#else
+ const QString odbcDriver = QLatin1String( {Virtuoso ANSI} );
+#endif
#endif
-const QString connectString = QString::fromLatin1( host=%1:%2;uid=%3;pwd=%4;driver=%5 )
+const QString connectString = QString::fromLatin1( host=%1:%2;uid=%3;pwd=%4;DRIVER=%5 )
.arg( host, QString::number( port ), uid, pwd, odbcDriver );
QStringList connectionSetupCommands;
if ( queryTimeout 1000 ) {
--- /dev/null
+++ b/cmake/modules/FindODBC.cmake
@@ -0,0 +1,22 @@
+# Taken from gammu project
+# Find ODBC (or UnixODBC)
+
+find_path(ODBC_INCLUDE_DIR NAMES sql.h
+ DOC The ODBC include directory
+)
+
+find_library(ODBC_LIBRARY NAMES odbc odbc32
+ DOC The ODBC library
+)
+
+# handle the QUIETLY and REQUIRED arguments and set ODBC_FOUND to TRUE if
+# all listed variables are TRUE
+include(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(ODBC DEFAULT_MSG ODBC_LIBRARY ODBC_INCLUDE_DIR)
+
+if(ODBC_FOUND)
+ set( ODBC_LIBRARIES ${ODBC_LIBRARY} )
+ set(
Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
Ubuntu already linked soprano against libvirtodbc0 rather than libiodbc2.Since it isn't libodbc1, do you think it is still bad? And why is Steve's patch dirty? Here on Debian wheezy, I needed to fix libmyodbc dependencies using ubuntu package, which is much more dirty since I cannot update soprano using apt anymore(no PPA)... -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAG6vemPa4EhOrTYMt9qbH4j98w0RP8hu5kq8sH8qg_=uwrj...@mail.gmail.com
Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
Hey there, This patch to soprano has been included in Ubuntu now for a couple of weeks and nothing's exploded. I see that the KDE transition is also done now. Could this change be included in the Debian package? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
Hi Steve, to be honest: I did not know that this was even possible. I would gladly apply this to upstream Soprano if you could provide a generic non-Debian specific patch. Also did you test this? Did you run the Virtuoso unit test? Cheers, Sebastian On 03/06/2012 08:47 AM, Steve Langasek wrote: Hi Sebastian, nice to meet you! On Tue, Mar 06, 2012 at 01:34:45AM +0100, Pino Toscano wrote: Alle martedì 6 marzo 2012, Steve Langasek ha scritto: I'm surprised to say that after sitting on this bug for far too long, it turns out that it's trivial to fix. Although it had been reported that soprano would not work with unixodbc, once I actually installed virtuoso, which the soprano test suite silently depends on, I get the same results from test/virtuosobackendtest when built against either iODBC or UnixODBC. I remember Sebastian Trueg (main soprano upstream) strongly recommending against using unixODBC (e.g. in [2], just last September), so I'm not sure whether this switch would break anything in the semantic desktop stack. (Disclaimer: I don't use Nepomuk myself.) Sebastian, what is the current status of soprano wrt unixODBC/iODBC? Which problems would result in using unixODBC? [2] http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso- clucene-and-libstreamanalyzer/ Right, so I've read the comment in that blog entry about needing libiodbc because of RDF extensions. But I've reviewed the libiodbc source, and can't find any evidence that such extensions exist - there's a single RDF define in the iodbcext.h header, but a copy of this header is shipped in the soprano source and there are no uses of the define anyway. As best as I can tell, the only extensions are in the virtuoso driver, which libiodbc2 merely passes the requests through to - and unixodbc would appear to do the very same. The one thing I have found that's different between iODBC and UnixODBC (but not represented in the previous patch) is that UnixODBC will not allow look-up of a driver by filename alone; it requires that the filename match the filename for a driver registered with odbcinst.ini. This seems like a feature that we could patch into UnixODBC easily enough if needed. (And apparently there was something wrong with my previous testing that I didn't catch this.) However, I wonder why it makes sense for soprano to use a driver manager at all, given that it appears soprano can *only* use the virtuoso driver as a backend. Wouldn't it be simpler to call into the virtuoso driver directly and omit the driver manager, on Unix? Attached is a revised patch to the Debian that implements the above proposal. Since UnixODBC is no longer involved (except as a provider of the sql.h header) there should not be any compatibility issues here. It may not be portable to non-Linux systems, but maybe it would be an acceptable distro patch, Pino? I'm happy to upload this as an NMU if you would like. It's probably worth an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to migrate to testing, since it's hard to have usable ODBC drivers for soprano until it's fixed. We're currently just started our KDE 4.7 transition, which includes also a soprano update from 2.6 to 2.7; if possible, I think IMHO it would be desiderable to wait for such dependency change, in case, after the transition is over (hopefully in two weeks, if everything goes fine). Would this timeframe suit you? I think it makes perfect sense to not upload this change until we're confident it's not going to be a problem for the transition. Cheers, -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f55cf2c.6020...@kde.org
Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
On Tue, Mar 06, 2012 at 09:47:40AM +0100, Sebastian Trüg wrote: to be honest: I did not know that this was even possible. I would gladly apply this to upstream Soprano if you could provide a generic non-Debian specific patch. I'm not very cmake literate, so I probably won't be able to provide a generic patch on my own. Maybe one of the Debian KDE maintainers can help? Effectively what we need is an implementation of findVirtuosoDriver() in cmake: return Soprano::findLibraryPath( virtodbc_r, QStringList(), QStringList() QLatin1String( virtuoso/plugins/ ) QLatin1String( odbc/ ) ); We can't use find_library() because this isn't strictly speaking a library (it has no soname, it's not named libfoo.so so we can't link against it with -l); it's a DSO, and it happens to be possible to link against DSOs when using glibc, and it happens to be *safe* in this case because we have a stable ABI as defined by ODBC. I don't know if there's a similar cmake idiom for finding DSOs. I guess you can use find_path()? And as I said, linking to a DSO isn't portable to all Unices. So the code should probably still give preference to libiodbc if it's available. Also did you test this? Did you run the Virtuoso unit test? I ran virtuosobackendtest from the tree, which I think is what you're referring to. Linking directly to virtodbc_r.so gives the same test results as linking to libiodbc (23 pass, 3 fail). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org On 03/06/2012 08:47 AM, Steve Langasek wrote: Hi Sebastian, nice to meet you! On Tue, Mar 06, 2012 at 01:34:45AM +0100, Pino Toscano wrote: Alle martedì 6 marzo 2012, Steve Langasek ha scritto: I'm surprised to say that after sitting on this bug for far too long, it turns out that it's trivial to fix. Although it had been reported that soprano would not work with unixodbc, once I actually installed virtuoso, which the soprano test suite silently depends on, I get the same results from test/virtuosobackendtest when built against either iODBC or UnixODBC. I remember Sebastian Trueg (main soprano upstream) strongly recommending against using unixODBC (e.g. in [2], just last September), so I'm not sure whether this switch would break anything in the semantic desktop stack. (Disclaimer: I don't use Nepomuk myself.) Sebastian, what is the current status of soprano wrt unixODBC/iODBC? Which problems would result in using unixODBC? [2] http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso- clucene-and-libstreamanalyzer/ Right, so I've read the comment in that blog entry about needing libiodbc because of RDF extensions. But I've reviewed the libiodbc source, and can't find any evidence that such extensions exist - there's a single RDF define in the iodbcext.h header, but a copy of this header is shipped in the soprano source and there are no uses of the define anyway. As best as I can tell, the only extensions are in the virtuoso driver, which libiodbc2 merely passes the requests through to - and unixodbc would appear to do the very same. The one thing I have found that's different between iODBC and UnixODBC (but not represented in the previous patch) is that UnixODBC will not allow look-up of a driver by filename alone; it requires that the filename match the filename for a driver registered with odbcinst.ini. This seems like a feature that we could patch into UnixODBC easily enough if needed. (And apparently there was something wrong with my previous testing that I didn't catch this.) However, I wonder why it makes sense for soprano to use a driver manager at all, given that it appears soprano can *only* use the virtuoso driver as a backend. Wouldn't it be simpler to call into the virtuoso driver directly and omit the driver manager, on Unix? Attached is a revised patch to the Debian that implements the above proposal. Since UnixODBC is no longer involved (except as a provider of the sql.h header) there should not be any compatibility issues here. It may not be portable to non-Linux systems, but maybe it would be an acceptable distro patch, Pino? I'm happy to upload this as an NMU if you would like. It's probably worth an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to migrate to testing, since it's hard to have usable ODBC drivers for soprano until it's fixed. We're currently just started our KDE 4.7 transition, which includes also a soprano update from 2.6 to 2.7; if possible, I think IMHO it would be desiderable to wait for such dependency change, in case, after the transition is over (hopefully in two weeks, if everything goes fine). Would
Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
tags 639300 patch
thanks
Dear maintainers,
I'm surprised to say that after sitting on this bug for far too long, it
turns out that it's trivial to fix. Although it had been reported that
soprano would not work with unixodbc, once I actually installed virtuoso,
which the soprano test suite silently depends on, I get the same results
from test/virtuosobackendtest when built against either iODBC or UnixODBC.
So I think the attached patch would be safe to apply to soprano, fixing this
longstanding issue.
I'm happy to upload this as an NMU if you would like. It's probably worth
an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to migrate to testing,
since it's hard to have usable ODBC drivers for soprano until it's fixed.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru soprano-2.7.5+dfsg.1/debian/changelog soprano-2.7.5+dfsg.1/debian/changelog
--- soprano-2.7.5+dfsg.1/debian/changelog 2012-03-04 20:55:08.0 +
+++ soprano-2.7.5+dfsg.1/debian/changelog 2012-03-05 23:49:53.0 +
@@ -1,3 +1,10 @@
+soprano (2.7.5+dfsg.1-1.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * Build against unixodbc. Closes: #639300, LP: #901638.
+
+ -- Steve Langasek vor...@debian.org Mon, 05 Mar 2012 23:49:13 +
+
soprano (2.7.5+dfsg.1-1) unstable; urgency=low
* Team upload.
diff -Nru soprano-2.7.5+dfsg.1/debian/control soprano-2.7.5+dfsg.1/debian/control
--- soprano-2.7.5+dfsg.1/debian/control 2012-03-04 20:43:25.0 +
+++ soprano-2.7.5+dfsg.1/debian/control 2012-03-05 23:49:41.0 +
@@ -6,7 +6,7 @@
Build-Depends: debhelper (= 7.4.15), cmake (= 2.6.2), pkg-kde-tools (= 0.12),
dpkg-dev (= 1.15.5), libclucene-dev (= 0.9.21b), libqt4-dev (= 4.5.3),
libraptor1-dev (= 1.4.16), librdf0-dev (= 1.0.13),
- doxygen (= 1.7.1), graphviz, libiodbc2-dev
+ doxygen (= 1.7.1), graphviz, unixodbc-dev
Standards-Version: 3.9.2
Homepage: http://soprano.sourceforge.net
Vcs-Browser: http://git.debian.org/?p=pkg-kde/kde-req/soprano.git
diff -Nru soprano-2.7.5+dfsg.1/debian/patches/series soprano-2.7.5+dfsg.1/debian/patches/series
--- soprano-2.7.5+dfsg.1/debian/patches/series 2012-03-04 20:33:22.0 +
+++ soprano-2.7.5+dfsg.1/debian/patches/series 2012-03-05 23:49:41.0 +
@@ -2,3 +2,4 @@
disable_usr_lib_install_rpath.diff
doxyfile_generate_tagfile.diff
redland_raptor2_support.h
+unixodbc
diff -Nru soprano-2.7.5+dfsg.1/debian/patches/unixodbc soprano-2.7.5+dfsg.1/debian/patches/unixodbc
--- soprano-2.7.5+dfsg.1/debian/patches/unixodbc 1970-01-01 00:00:00.0 +
+++ soprano-2.7.5+dfsg.1/debian/patches/unixodbc 2012-03-05 23:49:41.0 +
@@ -0,0 +1,21 @@
+Description: Build against unixodbc
+ Add support for soprano to build against unixodbc. Thanks to some hints
+ from Alban Browaeys, I've found that the virtuosobackendtest test suite
+ works just as well with either unixodbc or iodbc, you just have to have
+ the virtuoso-opensource-6.1-bin package installed first to avoid
+ incomprehensible test failures.
+Author: Steve Langasek vor...@debian.org
+Bug-Debian: http://bugs.debian.org/639300
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/901638
+
+--- soprano-2.6.0+dfsg.1.orig/cmake/modules/FindIODBC.cmake
soprano-2.6.0+dfsg.1/cmake/modules/FindIODBC.cmake
+@@ -57,7 +57,7 @@ find_path(IODBC_INCLUDE_DIR sql.h
+ ${iodbc_INCLUDE_DIRS}
+ )
+
+-find_library(IODBC_LIBRARIES NAMES iodbc
++find_library(IODBC_LIBRARIES NAMES odbc iodbc
+ HINTS
+ ${iodbc_LIBRARY_DIRS}
+ )
Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev
Hi Steve, (Hi Sebastian, this is a reply of the Debian bug #639300, which is about switching soprano from iODBC to unixODBC; you can find the whole log with the mentioned patch at [1].) [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639300 Alle martedì 6 marzo 2012, Steve Langasek ha scritto: I'm surprised to say that after sitting on this bug for far too long, it turns out that it's trivial to fix. Although it had been reported that soprano would not work with unixodbc, once I actually installed virtuoso, which the soprano test suite silently depends on, I get the same results from test/virtuosobackendtest when built against either iODBC or UnixODBC. I remember Sebastian Trueg (main soprano upstream) strongly recommending against using unixODBC (e.g. in [2], just last September), so I'm not sure whether this switch would break anything in the semantic desktop stack. (Disclaimer: I don't use Nepomuk myself.) Sebastian, what is the current status of soprano wrt unixODBC/iODBC? Which problems would result in using unixODBC? [2] http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso- clucene-and-libstreamanalyzer/ I'm happy to upload this as an NMU if you would like. It's probably worth an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to migrate to testing, since it's hard to have usable ODBC drivers for soprano until it's fixed. We're currently just started our KDE 4.7 transition, which includes also a soprano update from 2.6 to 2.7; if possible, I think IMHO it would be desiderable to wait for such dependency change, in case, after the transition is over (hopefully in two weeks, if everything goes fine). Would this timeframe suit you? -- Pino Toscano signature.asc Description: This is a digitally signed message part.
