Bug#529908: Upstream Fix
Hi there, After upgrading to Karmic Koala I'm now getting this same error. However, I can build with --with-external-torsocks. Short of developing a magic wand to fix whatever it is libtool is doing wrong, I don't see a way of fixing this. One way out of this is to package torsocks separately (http://code.google.com/p/torsocks) and I can update tork to rely on its presence (rather than including it in the source). If this is satisfactory I can make the appropriate changes. Thanks, Robert On Sunday 25 October 2009 15:01:38 Patrick Matthäi wrote: > Andreas Metzler schrieb: > > On 2009-10-19 Robert Hogan wrote: > >> Is there any way the reporter or an interested packager could check > >> the fix for this in upstream CVS: > >> > >> http://sourceforge.net/mailarchive/message.php?msg_name=E1MLhzT-a > >>q...@ddv4jf1.ch3.sourceforge.com > >> > >> Once validated, I can perform a release - or alternatively the patch > >> can be applied to the tork package. > > > > Hello, > > > > I think that generally the fix is correct. > > > > However I do not seem to able to make *any* changes to the build > > system and getting a compileable setup. > > > > Even a simple > > make -f Makefile.cvs ; ./configure ; make > > fails with > > Hello, > > yes I talked to Robert in private the last days and I have got exactly > the same error, he is working on it. > > > if /bin/bash ../../libtool --silent --tag=CC --mode=compile gcc > > -DHAVE_CONFIG_H -I. -I. -I../.. -DQT_THREAD_SUPPORT -D_REENTRANT > > -Wall -MT dead_pool.lo -MD -MP -MF ".deps/dead_pool.Tpo" -c -o > > dead_pool.lo dead_pool.c; \ then mv -f ".deps/dead_pool.Tpo" > > ".deps/dead_pool.Plo"; else rm -f ".deps/dead_pool.Tpo"; exit 1; fi > > /bin/bash ../../libtool --silent --tag=CC --mode=link gcc -Wall -o > > libtorksocks.la -rpath /usr/lib/tork -version-info 1:0:0 tsocks.lo > > common.lo parser.lo dead_pool.lo -ldl gcc: libtorksocks.so.1: No such > > file or directory > > gcc: unrecognized option '-soname' > > make[3]: *** [libtorksocks.la] Error 1 > > make[3]: Leaving directory `/tmp/TORK/tork-0.31/src/tsocks' > > make[2]: *** [all-recursive] Error 1 > > make[2]: Leaving directory `/tmp/TORK/tork-0.31/src' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/tmp/TORK/tork-0.31' > > make: *** [all] Error 2 > > > > I think this is caused by mixing old ltmain.sh in ./admin with new > > libtool.m4 in /usr/share/ or something like that. The aclocal run > > triggered by make -f Makefile.cvs throws loads of errors and warnings: > > SID)ametz...@argenau:/tmp/TORK/tork-0.31$ make -f Makefile.cvs > > This Makefile is only for the CVS repository > > This will be deleted before making the distribution > > > > *** automake (GNU automake) 1.9.6 found. > > *** Creating acinclude.m4 > > make[2]: Entering directory `/tmp/TORK/tork-0.31' > > make[2]: Leaving directory `/tmp/TORK/tork-0.31' > > *** Creating list of subdirectories > > make[2]: Entering directory `/tmp/TORK/tork-0.31' > > cd . && make -f admin/Makefile.common subdirs > > make[3]: Entering directory `/tmp/TORK/tork-0.31' > > make[3]: Leaving directory `/tmp/TORK/tork-0.31' > > make[2]: Leaving directory `/tmp/TORK/tork-0.31' > > *** Creating configure.files > > *** Creating configure.in > > make[2]: Entering directory `/tmp/TORK/tork-0.31' > > cd . && make -f admin/Makefile.common configure.in ; > > make[3]: Entering directory `/tmp/TORK/tork-0.31' > > make[3]: Leaving directory `/tmp/TORK/tork-0.31' > > make[2]: Leaving directory `/tmp/TORK/tork-0.31' > > *** Creating aclocal.m4 > > configure.in:51: warning: AC_REQUIRE: `AC_PROG_CC' was expanded before > > it was required ../../lib/autoconf/c.m4:433: AC_LANG_COMPILER(C) is > > expanded from... ../../lib/autoconf/lang.m4:315: > > AC_LANG_COMPILER_REQUIRE is expanded from... > > ../../lib/autoconf/general.m4:2593: AC_COMPILE_IFELSE is expanded > > from... ../../lib/autoconf/general.m4:2601: AC_TRY_COMPILE is expanded > > from... acinclude.m4:2978: KDE_CHECK_FOR_BAD_COMPILER is expanded > > from... acinclude.m4:3059: AC_CHECK_COMPILERS is expanded from... > > configure.in:51: the top level > > configure.in:51: warning: AC_REQUIRE: `AC_PROG_CXX' was expanded > > before it was required ../../lib/autoconf/c.m4:671: > > AC_LANG_COMPILER(C++) is expanded from... > > ../../lib/autoconf/ge
Bug#529908: Upstream Fix
On Sunday 25 October 2009 14:18:07 Andreas Metzler wrote: > I think this is caused by mixing old ltmain.sh in ./admin with new > libtool.m4 in /usr/share/ or something like that. Interesting, I tried libtoolize to no avail - it just broke the build even further. I checked the admin folder in the kde-common module in the KDE 3.5 SVN repo and it as old as mine. Any ideas on what to do/try out to remedy this? (Other than hand-edit the admin folder!) > The aclocal run > triggered by make -f Makefile.cvs throws loads of errors and warnings: > I think these are a red herring. I get them too and I can still build fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636943: torsocks: patching libresolv symbols is not trivial
On Sunday 05 February 2012 10:14:44 intrigeri wrote: > Hi Robert, > > Lunar wrote (30 Jan 2012 17:45:37 GMT) : > > It looks like to ideally solve this, proper probing logic must be > > implemented to support all OS, architectures and glibc variants. > > The attached patch uses a more brute force approach and always try > > the `__` variants if a `res_*` fails to be found. > > FYI, I agreement with Patrick Matthäi, I am going to take over the > maintenance of torsocks in Debian. > > I am going to wait a few more days for feedback from you before > I upload into the Debian archive a package with Lunar's patch applied. > > Thoughts? Seems fine to me. I'll apply it to trunk and let you know! > > Cheers, > -- > intrigeri > > | GnuPG key @ > | https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc OTR > | fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc > | If you must label the absolute, use it's proper name: Temporary. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#444329: Help
On Tuesday 29 January 2008 17:34:44 Patrick Matthäi wrote: > Jonathan Patrick Davies schrieb: > > On Sun, 27 Jan 2008, Patrick Matthäi wrote: > >> The package is at the moment freezed. You and me are not allowed to > >> publish it because of licensing problems. > > > > Hm, I was under the impression that Robert fixed all of these in the > > lastest > > release, or could you be a bit more specific about what is wrong? > > > > However, if it really cannot be packaged I suggest that the package be > > removed > > from this list[1] and put here[2]. > > > > Jonathan > > > > [1]: http://www.us.debian.org/devel/wnpp/being_packaged > > [2]: http://www.us.debian.org/devel/wnpp/unable-to-package > > It's not completly unable to package. The last problem we saw is the > linking against the GPL licensed libwhich, which should be solved in the > next release. > > Please do in the future more work on the licenses of the packages. Yes, libwhich will be remove in the next release. As far as I know that will remove the last remaining obstacle to a debian package. Thanks to everyone for their patience! signature.asc Description: This is a digitally signed message part.
Bug#502155: [Tork-packagers] [Fwd: Bug#502155: tork: Wrong configuration with custom tor server]
On Tuesday 14 October 2008 18:13:18 Patrick Matthäi wrote: > Package: tork > Version: 0.29.2-2 > Severity: normal > > If you use the custom tor server configuration and you change the > connection ports, tork will create a wrong configuration file: > > DirListenAddress 6730 > DirPort 9030 > ORListenAddress 6728 > ORPort 9001 > Thanks for that Andrea. It will be fixed in the next release. signature.asc Description: This is a digitally signed message part.
Bug#529908: Upstream Fix
Is there any way the reporter or an interested packager could check the fix for this in upstream CVS: http://sourceforge.net/mailarchive/message.php?msg_name=e1mlhzt-aq...@ddv4jf1.ch3.sourceforge.com Once validated, I can perform a release - or alternatively the patch can be applied to the tork package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#551496: RM: tork/0.31-2
On Sunday 18 October 2009 17:44:01 Patrick Matthäi wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > Hello, > > please remove tork from testing/squeeze. > > Reasons: > 2) Upstream is not very reponsive Hi - I'm the upstream developer. Guilty as charged. Patrick has been very supportive of Tork and has put a lot of work into improving it over the last year or two. I'm afraid I've let him down with his last couple of bug- reports. It's the usual story of getting sidetracked to other projects. > 1) It still lacks a Qt4 port Correct, and this is likely to remain the case for some time. I honestly don't see myself taking on this task at all in the next year at least. > and is not very compatible with KDE4 When running KDE 4.2 I would have agreed with this statement. However, I recently upgraded to KDE 4.3.2 and, lo and behold, Tork works fine with it. Tork's interaction with Konqueror was completely broken in 4.2, but in 4.3.2 now seems more or less on a par with 3.5 - the KDE series it was originally written for. I'm using the KDE 4.3.2 supplied by: deb http://ppa.launchpad.net/kubuntu-ppa/backports/ubuntu jaunty main So if there are any niggles left I could fix those to maintain complete interoperability with KDE 4. > 3) Bug #529908 has become critical, it is a showstopper for inclusion in > Squeeze. It has to be fixed, before tork may enter squeeze again. I just responded to that bug - there has been a fix in CVS for a while but Patrick reported that it did not work for him. It works for me, but my autofoo is very weak, many levels beneath the know-how that comes with maintaining packages. So my hope here is that someone can take a look at that patch and advise on what I'm doing wrong. http://sourceforge.net/mailarchive/message.php?msg_name=e1mlhzt-aq...@ddv4jf1.ch3.sourceforge.com So in summary: There won't be a Qt4 based Tork for a long time, if ever. However, Tork does seem to interoperate with KDE 4.3.2 - so if someone can help with #529908 and point out any remaining interoperability niggles for me to fix, Tork could remain a viable debian package. > > Upstream CCed. > > -- System Information: > Debian Release: squeeze/sid > APT prefers unstable > APT policy: (500, 'unstable'), (200, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.30-2-amd64 (SMP w/2 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/bash > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#402593: (no subject)
0.39 fixes freshclam compatibility but not onaccess scanning (klamd.cpp). i will commit a quick fix later today to klamav cvs and release a 0.39.1 as soon as i can. i still need to revisit and completely redo the klamd executable, an ugly hack providing on-modify scanning that has spent a year or two in bit-rot - though it still works! -- KlamAV - An Anti-Virus Manager for KDE - http://www.klamav.net TorK - A Tor Controller For KDE - http://tork.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
