Debian Bug report logs - #639300
please build against unixodbc-dev instead of libiodbc2-dev

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Wolfgang Walter <wolfgang.walter@stwm.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: odbc-postgresql: can't be installed together with KDE any more

Date: Thu, 25 Aug 2011 20:27:50 +0200

Package: odbc-postgresql
Version: 1:09.00.0310-2
Severity: important


odbc-postgresql can't be installed if libiodbc2 is installed. As most of
KDE depends on libsoprano4 which again depends on libiodbc2 via
soprano-daemon this makes odbc-postgresql unusable together with KDE.

Please remove libiodbc2 from the Breaks:


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.0.3-ei+6.3 (SMP w/6 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages odbc-postgresql depends on:
ii  libc6                         2.13-18    Embedded GNU C Library: Shared lib
ii  libltdl7                      2.4-4      A system independent dlopen wrappe
ii  libpq5                        9.1~rc1-2  PostgreSQL C client library
ii  libssl1.0.0                   1.0.0d-3   SSL shared libraries
ii  multiarch-support             2.13-18    Transitional package to ensure mul
ii  odbcinst1debian2              2.2.14p2-3 Support library for accessing odbc

odbc-postgresql recommends no packages.

Versions of packages odbc-postgresql suggests:
ii  unixodbc-bin                  2.3.0-1    Graphical tools for ODBC management


Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Message #10 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 639300@bugs.debian.org

Cc: 639300-submitter@bugs.debian.org, Debian Qt/KDE Maintainers <debian-qt-kde@lists.debian.org>, Christoph Berg <myon@debian.org>, 509815@bugs.debian.org

Subject: Re: odbc-postgresql: can't be installed together with KDE any more

Date: Fri, 26 Aug 2011 01:17:43 -0700

[Message part 1 (text/plain, inline)]

reassign 639300 soprano
retitle 639300 please build against unixodbc-dev instead of libiodbc2-dev
thanks

Hi folks,

This week with Christoph Berg's help, unixodbc has been converted for
multiarch in unstable along with the common drivers: libmyodbc, tdsodbc, and
odbc-postgresql.  The converted drivers are now all installed in
/usr/lib/<arch>/odbc, and the /etc/odbcinst.ini config has been updated to
use relative paths instead of absolute ones.

libiodbc2, which has been orphaned for nearly three years, has *not* been
updated for multiarch, and so libiodbc will fail to locate these drivers on
disk.  As a result, these drivers declare a Breaks: against libiodbc2.

I do not intend to update libiodbc2 for multiarch.  Instead, I would like to
propose its removal from the archive.  Historically, we have carried both
unixodbc and libiodbc2 in the archive to avoid a circular build-dependency:
Qt build-depends on ODBC for its database support, and UnixODBC
build-depends on Qt for its GUI tools.  The most recent upstream version of
UnixODBC resolves this, because in addition to being updated for Qt4, the
latest upstream release also splits the GUI tools into a separate source
distribution, which I have just uploaded to unstable.

So I am reassigning this bug to soprano.  KDE maintainers, please switch
soprano to build against unixodbc-dev instead of libiodbc2-dev.

(I will file separate bugs against the other reverse-dependencies, but for
soprano someone has beaten me to it.)

Thanks,
-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 639300@bugs.debian.org (full text, mbox, reply):

From: "glpk xypron" <xypron.glpk@gmx.de>

To: Steve Langasek <vorlon@debian.org>, 639300@bugs.debian.org, 509815@bugs.debian.org, 598787@bugs.debian.org

Subject: libiodbc2 -- iODBC Driver Manager orphaned

Date: Sat, 19 Nov 2011 14:14:56 +0100

Hello Steve,

> This week with Christoph Berg's help, unixodbc has been converted for
> multiarch in unstable along with the common drivers: libmyodbc,
> tdsodbc, and odbc-postgresql.  The converted drivers are now all installed in
> /usr/lib/<arch>/odbc, and the /etc/odbcinst.ini config has been updated to
> use relative paths instead of absolute ones.
>
> libiodbc2, which has been orphaned for nearly three years, has *not* been
> updated for multiarch, and so libiodbc will fail to locate these drivers on
> disk.  As a result, these drivers declare a Breaks: against libiodbc2.

I guess the problem is not about iODBC finding shared drivers like
libmyodbc. Instead a driver build against unixODBC is not compatible
with one build against iODBC. See bug #598787.

This means if both iODBC and unixODBC are kept, separate packages
for libmyodbc are needed.

I have had a look at the upstream.

http://unixodbc.svn.sourceforge.net/
shows active development.

http://iodbc.cvs.sourceforge.net/viewvc/iodbc/iODBC/iodbc/
shows no activity since 2009.

I guess the next step should be to ask the upstream author
of iODBC, if iODBC will be supported in future.

Best regards

Xypron

-- 
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

Message #31 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: glpk xypron <xypron.glpk@gmx.de>

Cc: 639300@bugs.debian.org, 509815@bugs.debian.org, 598787@bugs.debian.org

Subject: Re: libiodbc2 -- iODBC Driver Manager orphaned

Date: Sat, 19 Nov 2011 11:35:23 -0800

[Message part 1 (text/plain, inline)]

On Sat, Nov 19, 2011 at 02:14:56PM +0100, glpk xypron wrote:
> > This week with Christoph Berg's help, unixodbc has been converted for
> > multiarch in unstable along with the common drivers: libmyodbc,
> > tdsodbc, and odbc-postgresql.  The converted drivers are now all installed in
> > /usr/lib/<arch>/odbc, and the /etc/odbcinst.ini config has been updated to
> > use relative paths instead of absolute ones.

> > libiodbc2, which has been orphaned for nearly three years, has *not* been
> > updated for multiarch, and so libiodbc will fail to locate these drivers on
> > disk.  As a result, these drivers declare a Breaks: against libiodbc2.

> I guess the problem is not about iODBC finding shared drivers like
> libmyodbc.

You guess wrong.  I put the Breaks there, I'm telling you why they were
added.

> Instead a driver build against unixODBC is not compatible with one build
> against iODBC.  See bug #598787.

The lack of 100% compatibility between iODBC and unixODBC is another issue;
it's one that could be solved if there were a good reason to keep two ODBC
driver managers in the archive, but there isn't.  Thus we should just get
rid of libiodbc; but this is currently blocked on soprano's lack of
compatibility with unixodbc.

> This means if both iODBC and unixODBC are kept, separate packages
> for libmyodbc are needed.

That will absolutely never happen.

> I guess the next step should be to ask the upstream author
> of iODBC, if iODBC will be supported in future.

No, the next step is to figure out how to fix soprano, and then remove iODBC
from the archive.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #36 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 639300@bugs.debian.org

Subject: Re: please build against unixodbc-dev instead of libiodbc2-dev

Date: Mon, 5 Mar 2012 15:55:45 -0800

[Message part 1 (text/plain, inline)]

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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[soprano-639300.diff (text/x-diff, attachment)]

Message #43 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Pino Toscano <pino@debian.org>

To: Steve Langasek <vorlon@debian.org>, 639300@bugs.debian.org

Cc: trueg@kde.org

Subject: Re: Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

Date: Tue, 6 Mar 2012 01:34:45 +0100

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #48 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Pino Toscano <pino@debian.org>

Cc: 639300@bugs.debian.org, trueg@kde.org

Subject: Re: Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

Date: Mon, 5 Mar 2012 23:47:58 -0800

[Message part 1 (text/plain, inline)]

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,
-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[soprano-639300.diff (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Sebastian Trüg <trueg@kde.org>

To: Steve Langasek <vorlon@debian.org>

Cc: Pino Toscano <pino@debian.org>, 639300@bugs.debian.org

Subject: Re: Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

Date: Tue, 06 Mar 2012 09:47:40 +0100

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,

Message #58 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Sebastian Trüg <trueg@kde.org>

Cc: Pino Toscano <pino@debian.org>, 639300@bugs.debian.org

Subject: Re: Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

Date: Tue, 6 Mar 2012 20:12:17 -0800

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 "lib<foo>.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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@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 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,
> 

Message #63 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 639300@bugs.debian.org

Subject: Re: please build against unixodbc-dev instead of libiodbc2-dev

Date: Sun, 25 Mar 2012 14:48:55 -0700

[Message part 1 (text/plain, inline)]

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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #68 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Massimo Cetra <ctrix+debianbugs@navynet.it>

To: 639300@bugs.debian.org

Subject: Please someone provide a NMU

Date: Sun, 15 Apr 2012 17:40:27 +0200

Thanks to Steve Langasek:

i have used your patch and recompiled soprano-daemon and the libraries.
Everything works without a problem.

I would suggest a NMU if no one takes care of this bug which has been 
open far more than it should.

Max

Message #73 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Modestas Vainius <modax@debian.org>

To: Massimo Cetra <ctrix+debianbugs@navynet.it>

Cc: 639300@bugs.debian.org

Subject: Re: Please someone provide a NMU

Date: Sun, 15 Apr 2012 19:30:19 +0300

[Message part 1 (text/plain, inline)]

Hello,

On sekmadienis 15 Balandis 2012 18:40:27 Massimo Cetra wrote:
> Thanks to Steve Langasek:
> 
> i have used your patch and recompiled soprano-daemon and the libraries.
> Everything works without a problem.
> 
> I would suggest a NMU if no one takes care of this bug which has been
> open far more than it should.
> 
> Max

I'm sorry but we are not willing to include a dirty [1] patch just because we 
can. A better solution is welcome.

[1] RPATH, commented out code.

-- 
Modestas Vainius <modax@debian.org>

[signature.asc (application/pgp-signature, inline)]

Message #78 received at 639300@bugs.debian.org (full text, mbox, reply):

From: ciel <cielartisan@gmail.com>

To: 639300@bugs.debian.org

Subject: Re: please build against unixodbc-dev instead of libiodbc2-dev

Date: Sat, 2 Jun 2012 12:39:53 +0900

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)...

Message #83 received at 639300@bugs.debian.org (full text, mbox, reply):

From: "leone2000@inwind.it" <leone2000@inwind.it>

To: 639300@bugs.debian.org

Subject: Re: Please someone provide a NMU

Date: Sat, 22 Sep 2012 10:41:04 +0200 (CEST)

[Message part 1 (text/plain, inline)]

i can't understand why you leave this bug open when a patch (dirty???) can resolve... it's absurd to have to use the ubuntu packages to fix debian bug.
 

[Message part 2 (text/html, inline)]

Message #88 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Alban Browaeys <prahal@yahoo.com>

To: Debian Bug Tracking System <639300@bugs.debian.org>

Subject: Re: please build against unixodbc-dev instead of libiodbc2-dev

Date: Tue, 08 Jan 2013 06:40:52 +0100

[Message part 1 (text/plain, inline)]

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  libodbc1        2.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-0    2.0.8-2
ii  librdf0         1.0.15-1+b1
ii  libstdc++6      4.8-20130105-1
ii  unixodbc        2.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)

[odbcinst.ini.template (text/plain, attachment)]

[iodbc-switchto-unidxodbc.diff (text/x-diff, attachment)]

Message #93 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Bill Allombert <Bill.Allombert@math.u-bordeaux1.fr>, 707301@bugs.debian.org

Cc: Julien Cristau <jcristau@debian.org>, Lukasz Szybalski <szybalski@gmail.com>, 639300@bugs.debian.org, debian-release@lists.debian.org

Subject: Re: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc (< 0.82-8) but 0.82-7 is to be installed

Date: Sat, 11 May 2013 11:48:52 -0700

[Message part 1 (text/plain, inline)]

On Sat, May 11, 2013 at 02:26:22PM +0200, Bill Allombert wrote:
> > On Wed, May  8, 2013 at 16:45:09 -0500, Lukasz Szybalski wrote:

> > > The following packages have unmet dependencies:
> > >  odbcinst1debian2 : Breaks: tdsodbc (< 0.82-8) but 0.82-7 is to be installed
> > > E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.

> > That shouldn't happen, 0.82-7 is the squeeze (oldstable) version.
> > What's the output of "apt-cache policy tdsodbc" at that point?

> This is probably caused by the circular dependency between odbcinst and
> odbcinst1debian2.  (Bug #545861)

No, it is not.  Circular dependencies are not the boogieman you make them
out to be.

Below is the output of an apt debug run from a squeeze minimal test case
using tdsodbc+akonadi-server.  Virtuoso alone does not trigger this issue;
however, virtuoso and akonadi are frequently found together because they are
both dependencies of KDE, so given the mention of virtuoso in the
submitter's output, I assume this is the case on this system.

For akonadi-server, the problem is that soprano-daemon (which is a
dependency of akonadi-server: akonadi-server -> libsoprano4 ->
soprano-daemon) still depends on libiodbc2 in wheezy...  even though
libiodbc2 is not multiarch-compatible and thus obsoleted by unixodbc.
That's bug #639300, which managed to go unfixed in wheezy despite a patch
being made available a year ago.  Apparently the maintainers rejected this
patch for spurious reasons (objecting to rpath which is clearly the lesser
evil; and objecting to commented-out code, which is clearly something the
maintainer could fix when applying the patch), but did not cc: me when doing
so.

I recommend applying the patch from bug #639300 in a stable update, instead
of leaving akonadi/virtuoso un-coinstallable with all ODBC drivers in
wheezy.  Attached is an updated patch for this issue.

SRMs: would you like me to NMU this fix to proposed-updates?

KDE maintainers: would you prefer to prepare a different fix yourselves for
this issue, or upload this patch yourself?


Reading package lists...
Building dependency tree...
Reading state information...
Starting
Starting 2
Investigating (0) libgcc1 [ amd64 ] < 1:4.4.5-8 -> 1:4.7.2-5 > ( libs )
Broken libgcc1:amd64 Breaks on gcc-4.3 [ amd64 ] < 4.3.5-4 > ( devel ) (< 4.3.6-1)
  Considering gcc-4.3:amd64 -1 as a solution to libgcc1:amd64 431
  Added gcc-4.3:amd64 to the remove list
  Fixing libgcc1:amd64 via remove of gcc-4.3:amd64
Investigating (0) libept1 [ amd64 ] < 1.0.4 > ( libs )
Broken libept1:amd64 Depends on libapt-pkg4.10 [ amd64 ] < none > ( none )
  Considering apt:amd64 10 as a solution to libept1:amd64 3
  Removing libept1:amd64 rather than change libapt-pkg4.10:amd64
Investigating (0) mysql-common [ amd64 ] < 5.1.49-3 -> 5.5.30+dfsg-1.1 > ( database )
Broken mysql-common:amd64 Breaks on mysql-server-core-5.1 [ amd64 ] < 5.1.49-3 > ( misc ) (< 5.5)
  Considering mysql-server-core-5.1:amd64 -1 as a solution to mysql-common:amd64 3
  Added mysql-server-core-5.1:amd64 to the remove list
  Fixing mysql-common:amd64 via remove of mysql-server-core-5.1:amd64
Investigating (0) tdsodbc [ amd64 ] < 0.82-7 -> 0.91-2 > ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ] < 3.52.6-4 -> 3.52.7-2 > ( libs )
  Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
  Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64
Investigating (0) libakonadiprotocolinternals1 [ amd64 ] < none -> 1.7.2-3 > ( libs )
Broken libakonadiprotocolinternals1:amd64 Breaks on libakonadiprivate1 [ amd64 ] < 1.3.1-3+squeeze1 > ( libs ) (< 1.4.90)
  Considering libakonadiprivate1:amd64 -2 as a solution to libakonadiprotocolinternals1:amd64 -1
  Added libakonadiprivate1:amd64 to the remove list
  Fixing libakonadiprotocolinternals1:amd64 via remove of libakonadiprivate1:amd64
Investigating (0) akonadi-backend-mysql [ amd64 ] < none -> 1.7.2-3 > ( misc )
Broken akonadi-backend-mysql:amd64 Depends on mysql-server-core-5.5 [ amd64 ] < none -> 5.5.30+dfsg-1.1 > ( database )
  Considering mysql-server-core-5.5:amd64 1 as a solution to akonadi-backend-mysql:amd64 -1
  Holding Back akonadi-backend-mysql:amd64 rather than change mysql-server-core-5.5:amd64
Broken akonadi-backend-mysql:amd64 Depends on mysql-server-core [ amd64 ] < none > ( none )
  Considering mysql-server-core-5.1:amd64 -1 as a solution to akonadi-backend-mysql:amd64 -1
  Holding Back akonadi-backend-mysql:amd64 rather than change mysql-server-core:amd64
  Or group keep for akonadi-backend-mysql:amd64
Investigating (1) odbcinst1debian2 [ amd64 ] < 2.2.14p2-1 -> 2.2.14p2-5 > ( libs )
Broken odbcinst1debian2:amd64 Breaks on tdsodbc [ amd64 ] < 0.82-7 -> 0.91-2 > ( libs ) (< 0.82-8)
  Considering tdsodbc:amd64 0 as a solution to odbcinst1debian2:amd64 3
  Upgrading tdsodbc:amd64 due to Breaks field in odbcinst1debian2:amd64
Investigating (1) akonadi-server [ amd64 ] < 1.3.1-3+squeeze1 -> 1.7.2-3 > ( net )
Broken akonadi-server:amd64 Depends on akonadi-backend-mysql [ amd64 ] < none -> 1.7.2-3 > ( misc ) (= 1.7.2-3)
  Considering akonadi-backend-mysql:amd64 -1 as a solution to akonadi-server:amd64 1
  Try Installing akonadi-backend-mysql [ amd64 ] < none -> 1.7.2-3 > ( misc ) before changing akonadi-server:amd64
Investigating (1) tdsodbc [ amd64 ] < 0.82-7 -> 0.91-2 > ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ] < 3.52.6-4 -> 3.52.7-2 > ( libs )
  Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
  Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64
Investigating (2) odbcinst1debian2 [ amd64 ] < 2.2.14p2-1 -> 2.2.14p2-5 > ( libs )
Broken odbcinst1debian2:amd64 Breaks on tdsodbc [ amd64 ] < 0.82-7 -> 0.91-2 > ( libs ) (< 0.82-8)
  Considering tdsodbc:amd64 0 as a solution to odbcinst1debian2:amd64 3
  Upgrading tdsodbc:amd64 due to Breaks field in odbcinst1debian2:amd64
Investigating (2) tdsodbc [ amd64 ] < 0.82-7 -> 0.91-2 > ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ] < 3.52.6-4 -> 3.52.7-2 > ( libs )
  Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
  Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64

<snip here - repeats until recursion limit is reached>

Done
The following packages have unmet dependencies:
 odbcinst1debian2 : Breaks: tdsodbc (< 0.82-8) but 0.82-7 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.


-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[soprano-639300.diff (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #98 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Sune Vuorela <sune@debian.org>

To: Steve Langasek <vorlon@debian.org>, 639300@bugs.debian.org

Cc: debian-release@lists.debian.org

Subject: Re: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc (< 0.82-8) but 0.82-7 is to be installed

Date: Sat, 11 May 2013 21:18:03 +0200

[recipients trimmed]
> I recommend applying the patch from bug #639300 in a stable update, instead
> of leaving akonadi/virtuoso un-coinstallable with all ODBC drivers in
> wheezy.  Attached is an updated patch for this issue.

My recommendation is to have unixodbc drop the useless and broken Breaks.

> KDE maintainers: would you prefer to prepare a different fix yourselves for
> this issue, or upload this patch yourself?

I guess I can NMU unixodbc if you prefer, given that is the good fix.

iodbc is what upstream and most distributions uses here, and I see no reason 
to deviate from upstream here. 

iodbc is the one supported and written by virtuoso upstream, so that's the one 
we prefer to use.

/Sune
 - member of KDE team.
-- 
Do you know how can I cancel the periferic?

First you either should close the cache, or need to send to a ISA sendmail in 
order to overclock the digital memory.

Message #103 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Sune Vuorela <sune@debian.org>

Cc: 639300@bugs.debian.org, debian-release@lists.debian.org

Subject: Re: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc (< 0.82-8) but 0.82-7 is to be installed

Date: Sat, 11 May 2013 15:54:13 -0700

[Message part 1 (text/plain, inline)]

On Sat, May 11, 2013 at 09:18:03PM +0200, Sune Vuorela wrote:
> [recipients trimmed]
> > I recommend applying the patch from bug #639300 in a stable update, instead
> > of leaving akonadi/virtuoso un-coinstallable with all ODBC drivers in
> > wheezy.  Attached is an updated patch for this issue.

> My recommendation is to have unixodbc drop the useless and broken Breaks.

The breaks are not from unixodbc, they are from the ODBC *drivers*, which
are no longer in a path that libiodbc2 will find.  No one has stepped up to
make libiodbc2 multiarch-capable, and I find it unlikely that this would be
acceptable to fix in a stable update.  Thus the breaks are legitimate and
correct.

> > KDE maintainers: would you prefer to prepare a different fix yourselves for
> > this issue, or upload this patch yourself?

> I guess I can NMU unixodbc if you prefer, given that is the good fix.

No, you have misunderstood the problem.

> iodbc is what upstream and most distributions uses here, and I see no reason 
> to deviate from upstream here. 

> iodbc is the one supported and written by virtuoso upstream, so that's the
> one we prefer to use.

iodbc is the one being *abused* by virtuoso upstream.  Soprano does not work
with arbitrary ODBC drivers; the use of a driver manager (in this case,
iODBC) is a pointless indirection - as I've demonstrated, with my tested
patch.  The iodbc package in Debian has been unmaintained for years; a
simple patch to soprano to remove the dependency on iodbc altogether is all
that's needed here.

If you're willing to maintain libiodbc2 just for the sake of virtuoso, then
fine, maintain it.  But no one has been maintaining it for 4 years, and it
went out the door broken and unusable as an ODBC DM because no one has
ported it for use with multiarch while almost all of the ODBC drivers have
been multiarch-enabled in wheezy.  The only reason this bug doesn't affect
soprano as well is that soprano isn't *using* it as a DM except in the
loosest sense of the word.  So as things stand now, libiodbc2 is useless as
a DM because it's incompatible with any of the drivers that users are going
to configure it to use, and the Breaks are there to reflect that and ensure
partial upgrades don't give users broken ODBC for other squeeze revdeps of
libiodbc2.

-- 
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 Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #110 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Paul Harris <harris.pc@gmail.com>

To: 639300@bugs.debian.org

Subject: How is this bug still not fixed?

Date: Thu, 27 Jun 2013 09:43:24 +0800

[Message part 1 (text/plain, inline)]

Guys, am I missing something?

I cannot install both libmyodbc and okular/k3b/katepart in the same debian
system.

How do I connect to a MySQL database via odbc, AND have (eg) k3b installed
at the same time?  Is it current impossible in Debian?

[Message part 2 (text/html, inline)]

Message #115 received at 639300@bugs.debian.org (full text, mbox, reply):

From: Paul Harris <harris.pc@gmail.com>

To: 639300@bugs.debian.org

Subject: Re: How is this bug still not fixed?

Date: Thu, 27 Jun 2013 10:54:06 +0800

[Message part 1 (text/plain, inline)]

Apologies, in testing it seems that libmyodbc should have fixed the
problem. I think.

Any chance of getting these backported?


On 27 June 2013 09:43, Paul Harris <harris.pc@gmail.com> wrote:

> Guys, am I missing something?
>
> I cannot install both libmyodbc and okular/k3b/katepart in the same debian
> system.
>
> How do I connect to a MySQL database via odbc, AND have (eg) k3b installed
> at the same time?  Is it current impossible in Debian?
>
>

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.