Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)
Benoît Knecht wrote:
> Max Power wrote:
> > Output from ldd $(which rtorrent)
> >
> > linux-vdso.so.1 => (0x7fff54fe5000)
> > libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
> > (0x7f0fccb28000)
> > libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
> > (0x7f0fcc8ff000)
> > libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x7f0fcc6f9000)
> > libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4
> > (0x7f0fcc48e000)
> > libtorrent.so.14 => /usr/local/lib/libtorrent.so.14
> > (0x7f0fcc1b2000)
> > libxmlrpc_server.so.3 => /usr/local/lib/libxmlrpc_server.so.3
> > (0x7f0fcbfab000)
> > libxmlrpc.so.3 => /usr/local/lib/libxmlrpc.so.3 (0x7f0fcbd94000)
> > libxmlrpc_util.so.3 => /usr/local/lib/libxmlrpc_util.so.3
> > (0x7f0fcbb9)
> > libxmlrpc_xmlparse.so.3 => /usr/local/lib/libxmlrpc_xmlparse.so.3
> > (0x7f0fcb983000)
> > libxmlrpc_xmltok.so.3 => /usr/local/lib/libxmlrpc_xmltok.so.3
> > (0x7f0fcb767000)
> > libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> > (0x7f0fcb46)
> > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0fcb1dd000)
> > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> > (0x7f0fcafc7000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x7f0fcadab000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0fcaa23000)
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0fca81f000)
> > libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11
> > (0x7f0fca5eb000)
> > libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
> > (0x7f0fca3c1000)
> > liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
> > (0x7f0fca1b2000)
> > libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
> > (0x7f0fc9f62000)
> > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0fc9d59000)
> > libgssapi_krb5.so.2 =>
> > /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
> > libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> > (0x7f0fc98c8000)
> > libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> > (0x7f0fc9501000)
> > librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0
> > (0x7f0fc92e7000)
> > libz.so.1 => /usr/lib/libz.so.1 (0x7f0fc90d)
> > libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26
> > (0x7f0fc8e0f000)
> > /lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
> > libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11
> > (0x7f0fc8b91000)
> > libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
> > (0x7f0fc897a000)
> > libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
> > libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> > (0x7f0fc848d000)
> > libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> > (0x7f0fc8263000)
> > libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
> > (0x7f0fc805f000)
> > libkrb5support.so.0 =>
> > /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
> > libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x7f0fc7c53000)
> > libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3
> > (0x7f0fc7a42000)
> > libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
> > (0x7f0fc782f000)
> > libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
> > (0x7f0fc762c000)
> >
> > As you can see it points to /usr/local/lib/libtorrent.so.14 which point to
> > /usr/local/lib/libtorrent.so.14.0.1 in the same directory.
> >
> > I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
> > /usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown reason
> > it's not linked correctly. Any idea on how to fix this?
>
> Just try removing /usr/local/lib/libtorrent.so.14{,.0.1}, which I guess
> you compiled and installed there yourself at some point.
Actually, you should remove all of the files listed in the output of ldd
that are in /usr/local/lib, as otherwise they will be used instead of
the versions shipped in Debian and eventually cause issues like this
one.
--
Benoît Knecht
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)
Max Power wrote:
> Output from ldd $(which rtorrent)
>
> linux-vdso.so.1 => (0x7fff54fe5000)
> libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5
> (0x7f0fccb28000)
> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5
> (0x7f0fcc8ff000)
> libsigc-2.0.so.0 => /usr/lib/libsigc-2.0.so.0 (0x7f0fcc6f9000)
> libcurl.so.4 => /usr/lib/x86_64-linux-gnu/libcurl.so.4
> (0x7f0fcc48e000)
> libtorrent.so.14 => /usr/local/lib/libtorrent.so.14
> (0x7f0fcc1b2000)
> libxmlrpc_server.so.3 => /usr/local/lib/libxmlrpc_server.so.3
> (0x7f0fcbfab000)
> libxmlrpc.so.3 => /usr/local/lib/libxmlrpc.so.3 (0x7f0fcbd94000)
> libxmlrpc_util.so.3 => /usr/local/lib/libxmlrpc_util.so.3
> (0x7f0fcbb9)
> libxmlrpc_xmlparse.so.3 => /usr/local/lib/libxmlrpc_xmlparse.so.3
> (0x7f0fcb983000)
> libxmlrpc_xmltok.so.3 => /usr/local/lib/libxmlrpc_xmltok.so.3
> (0x7f0fcb767000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f0fcb46)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f0fcb1dd000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f0fcafc7000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f0fcadab000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f0fcaa23000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f0fca81f000)
> libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11
> (0x7f0fca5eb000)
> libssh2.so.1 => /usr/lib/x86_64-linux-gnu/libssh2.so.1
> (0x7f0fca3c1000)
> liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
> (0x7f0fca1b2000)
> libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
> (0x7f0fc9f62000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f0fc9d59000)
> libgssapi_krb5.so.2 =>
> /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f0fc9b1a000)
> libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
> (0x7f0fc98c8000)
> libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
> (0x7f0fc9501000)
> librtmp.so.0 => /usr/lib/x86_64-linux-gnu/librtmp.so.0
> (0x7f0fc92e7000)
> libz.so.1 => /usr/lib/libz.so.1 (0x7f0fc90d)
> libgnutls.so.26 => /usr/lib/x86_64-linux-gnu/libgnutls.so.26
> (0x7f0fc8e0f000)
> /lib64/ld-linux-x86-64.so.2 (0x7f0fccd62000)
> libgcrypt.so.11 => /lib/x86_64-linux-gnu/libgcrypt.so.11
> (0x7f0fc8b91000)
> libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
> (0x7f0fc897a000)
> libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x7f0fc8761000)
> libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> (0x7f0fc848d000)
> libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> (0x7f0fc8263000)
> libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
> (0x7f0fc805f000)
> libkrb5support.so.0 =>
> /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f0fc7e56000)
> libkeyutils.so.1 => /lib/libkeyutils.so.1 (0x7f0fc7c53000)
> libtasn1.so.3 => /usr/lib/x86_64-linux-gnu/libtasn1.so.3
> (0x7f0fc7a42000)
> libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
> (0x7f0fc782f000)
> libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
> (0x7f0fc762c000)
>
> As you can see it points to /usr/local/lib/libtorrent.so.14 which point to
> /usr/local/lib/libtorrent.so.14.0.1 in the same directory.
>
> I have /usr/lib/x86_64-linux-gnu/libtorrent.so.14 and it's pointing to
> /usr/lib/x86_64-linux-gnu/libtorrent.so.14.0.4 but for an unknown reason
> it's not linked correctly. Any idea on how to fix this?
Just try removing /usr/local/lib/libtorrent.so.14{,.0.1}, which I guess
you compiled and installed there yourself at some point.
Cheers,
--
Benoît Knecht
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679021: rtorrent does not start (symbol lookup error undefined symbol)
Hi Max, Max Power wrote: > After uprading from rtorrent 0.8.9 (previous unstable version) > rtorrent is not able to start again with the error message: > > rtorrent: symbol lookup error: rtorrent: undefined symbol: > _ZN7torrent11thread_base8m_globalE > > I have no clue what this means or what I could do against it. Can you please post the output of ldd $(which rtorrent) and see if it lists libtorrent.so.14? It should point to /usr/lib/x86_64-linux-gnu/libtorrent.so.14, so can you check if it exists on your system and links to libtorrent.so.14.0.4 in the same directory (and that the latter is readable)? Also, do you have multiarch-support installed? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628952: minidlna: Possible unknown copyright status of hardcoded image blobs in source code
tag 628952 pending -- Hi everyone, First of all, I'd like to thank everyone for their comments, they were all very helpful. And in light of all of this, I think the best approach is first of all removing the Netgear logo since we're not using it in Debian anyway, and then replacing the Tux logo with the Debian logo. This should be fixed in the next upload of minidlna. Thanks again to everyone. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#628952: minidlna: Possible unknown copyright status of hardcoded image blobs in source code
Hi, Francesco Poli wrote: > On Thu, 02 Jun 2011 15:59:11 +0200 Carl Fürstenberg wrote: > > the source code file icons.c includes binary blobs detailing the NetGear > > logo and the Tux logo. > > Hi! > I am a debian-legal subscriber, and I would like to comment on this bug > report. Thanks a lot for your input, it's very much appreciated. > First of all, thanks for spotting this issue and for reporting it. > > > > > While the source code is licensed under GPL2, the file in question only > > states following: > > > > * Penguin images are the creation of Larry Ewing (lew...@isc.tamu.edu) > > using The GIMP. > > More information about the famous Tux the Penguin image here: > http://www.isc.tamu.edu/~lewing/linux/ > (I'm assuming we are talking about this image, right?) > > Unfortunately the "license" is very incomplete and unclear: > > | Feel free to do whatever you see fit with the images, you are > | encouraged to integrate them into other designs that fit your need. > [...] > | Permission to use and/or modify this image is granted provided > | you acknowledge me lew...@isc.tamu.edu and The GIMP if someone asks. I agree that's rather vague, especially regarding commercial use, although commons.wikimedia.org [1] seems to consider it free enough. [1] http://commons.wikimedia.org/wiki/File:Tux.png > I tried (back in 2005) to get in touch with Larry Ewing and persuade > him that a clearer license should be granted, but I have never received > any reply to my messages... > You may try to contact him now: it's possible that you turn out to be > luckier than me! > According to > http://en.wikipedia.org/wiki/Larry_Ewing > his current home page is: > http://lewing.org/ > Maybe the e-mail address shown there is more up-to-date or > appropriate... Well I could try, but I'm not very optimistic about it (I guess it's not the first time the issue was brought up to Larry Ewing's attention, and apparently no one was successful so far). I'm thinking the best solution for now is to replace the logo altogether. In Debian we could use the Debian logo, but I don't know what free image to suggest as a replacement upstream. Any suggestions? > > * NETGEAR images Copyright (c) 2008- NETGEAR, Inc. All Rights Reserved. > > > > It doesn't explicit state which licenses these binary blobs are under > > (there are four of each, two png and two jpeg). Only the tux image is > > used in the binary package. > > If this is confirmed, then I think the best thing to do is dropping the > NETGEAR images from the source package, and trying to get a > GPL-compatible license for the Tux images (I suggest a simple > permissive non-copyleft license: the Expat one, > http://www.jclark.com/xml/copying.txt ). I had a look at these, and I'm pretty sure they're not eligible for copyright protection (a white 'N' on a blue background is not nearly creative enough). So I don't think there's a problem there; the license header should just be corrected to state that there's no copyright on this particular logo. What do you think? Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#618067: Updated sources
tags 618067 pending thanks Piotr Górski wrote: > Forgot to attach updated sources in my last mail. Now it's where it should > be :) I've applied both your patches, thanks. I'll upload the corrected version to mentors soon, although there's a new upstream version now that also fixes both of these issues. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564425: Fixed 0.62+nmu1 and cleaned-up some lintian warnings in 0.62+nmu2
Hi Alexander, Alexander Reichle-Schmehl wrote: > * Benoît Knecht [101125 20:23]: > > > [..] and while I was at it, I fixed some basic lintian warnings in > > version 0.62+nmu2. > > Thanks for your work, however I found some of your changes to intrusive > for an NMU (e.g. change to source format 3) especially that late in the > freeze cycle. However, your changes shouldn't be in vain, as I'm quite > sure Junichi will take a look at them for the next regular uploads. No worries, although I think '3.0 (native)' is pretty much the same as '1.0'. But if you really consider it an issue, debian/source/format could be set to '1.0' for now, thus making lintian happy while being completely non-intrusive. Actually, I don't really mind the changes affecting the source only being delayed, but I think it's a pity the man page fixes are not included because those are visible to the user. Anyway, I'm glad the serious issue is now fixed, and as for the smaller details, I know they will be included eventually, so it's not a big deal. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564425: Fixed 0.62+nmu1 and cleaned-up some lintian warnings in 0.62+nmu2
Hi, I took the liberty of uploading a new version of the package to mentors.debian.net [1]. It has the proper fix for bug #564425 applied as version 0.62+nmu1 (I didn't do it with a debian/patches since it's a native package anyway), and while I was at it, I fixed some basic lintian warnings in version 0.62+nmu2. [1] http://mentors.debian.net/debian/pool/main/c/cowdancer/cowdancer_0.62+nmu2.dsc Two lintian warnings remain: W: cowdancer source: package-uses-deprecated-debhelper-compat-version 4 W: cowdancer source: ancient-standards-version 3.7.2 (current is 3.9.1) because I didn't want to make any non-trivial changes. For ease of review, I've put all the changes in a git repository; you can see what I've changed from 0.62 by doing the following: git clone -b nmu git://gitorious.org/debian-pkg/cowdancer.git cd cowdancer git log debian/0.62.. Best wishes, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
