Bug#529908: Upstream Fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Robert Hogan schrieb:
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
I don't know if I will find the time for it before squeeze will release.
Better would be a fix for tork, but I will try to package it.
I have attached a little patchset for torsocks, please apply it and a
new release would be nice.
Also a question:
gnu:~/pbuilder# dpkg-deb -c result/torsocks_1.0-gamma-1_i386.deb
drwxr-xr-x root/root 0 2009-11-06 09:32 ./
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/lib/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/lib/torsocks/
- -rw-r--r-- root/root 841 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.la
- -rw-r--r-- root/root 45428 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.so.1.0.0
- -rw-r--r-- root/root 53442 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.a
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/bin/
- -rwxr-xr-x root/root 3222 2009-11-06 09:32 ./usr/bin/usewithtor
- -rwxr-xr-x root/root 4488 2009-11-06 09:32 ./usr/bin/torsocks
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/doc/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/doc/torsocks/
- -rw-r--r-- root/root 152 2009-11-06 09:26
./usr/share/doc/torsocks/changelog.Debian.gz
- -rw-r--r-- root/root 2727 2009-11-06 09:26
./usr/share/doc/torsocks/changelog.gz
- -rw-r--r-- root/root 2110 2009-11-06 09:26
./usr/share/doc/torsocks/copyright
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/man1/
- -rw-r--r-- root/root 505 2009-11-06 09:32
./usr/share/man/man1/usewithtor.1.gz
- -rw-r--r-- root/root 743 2009-11-06 09:32
./usr/share/man/man1/torsocks.1.gz
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/man8/
- -rw-r--r-- root/root 3085 2009-11-06 09:32
./usr/share/man/man8/torsocks.8.gz
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/man5/
- -rw-r--r-- root/root 3131 2009-11-06 09:32
./usr/share/man/man5/torsocks.conf.5.gz
drwxr-xr-x root/root 0 2009-11-06 09:32 ./etc/
- -rw-r--r-- root/root 2044 2009-11-06 09:32 ./etc/torsocks.conf
lrwxrwxrwx root/root 0 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.so - libtorsocks.so.1.0.0
lrwxrwxrwx root/root 0 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.so.1 - libtorsocks.so.1.0.0
Aren't there any headers which should be installed to build packages
against torsocks?
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkrz36QACgkQ2XA5inpabMfLQgCdHcw4Nb1rf8CAHJte8oJ/2N5E
a4gAnjCisyDPmuOpvohldI1iQs5lLq/a
=V4iu
-END PGP SIGNATURE-
diff -Naur torsocks-1.0-gamma.orig/src/torsocks.conf.5 torsocks-1.0-gamma/src/torsocks.conf.5
--- torsocks-1.0-gamma.orig/src/torsocks.conf.5 2009-11-06 09:26:26.0 +0100
+++ torsocks-1.0-gamma/src/torsocks.conf.5 2009-11-06 09:29:03.0 +0100
@@ -22,7 +22,7 @@
to be proxied over a SOCKS server. However, many installations have several
different SOCKS servers to be used to access different internal (and external)
networks. For this reason the configuration file allows the definition of
-'paths' as well as a default SOCKS server.
+`paths' as well as a default SOCKS server.
Paths are declared as blocks in the configuration file. That is, they begin
with a 'path {' line in the configuration file and end with a '}' line. Inside
@@ -66,7 +66,7 @@
.I server
The IP address of the SOCKS server (e.g server = 10.1.4.253). Only one
server may be specified per path block, or one outside a path
-block (to define the default server). Unless --disable-hostnames was
+block (to define the default server). Unless \-\-disable-hostnames was
specified to configure at compile time the server can be specified as
a hostname (e.g server = socks.nec.com)
@@ -118,7 +118,7 @@
.TP
.I reaches
This directive is only valid inside a path block. Its parameter is formed
-as IP[:startport[-endport]]/Subnet and it specifies a network (and a range
+as IP[:startport[\-endport]]/Subnet and it specifies a network (and a range
of ports on that
Bug#529908: Upstream Fix
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay here is another patch, I attached again both.
Patrick Matthäi schrieb:
Robert Hogan schrieb:
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
I don't know if I will find the time for it before squeeze will release.
Better would be a fix for tork, but I will try to package it.
I have attached a little patchset for torsocks, please apply it and a
new release would be nice.
Also a question:
gnu:~/pbuilder# dpkg-deb -c result/torsocks_1.0-gamma-1_i386.deb
drwxr-xr-x root/root 0 2009-11-06 09:32 ./
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/lib/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/lib/torsocks/
-rw-r--r-- root/root 841 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.la
-rw-r--r-- root/root 45428 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.so.1.0.0
-rw-r--r-- root/root 53442 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.a
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/bin/
-rwxr-xr-x root/root 3222 2009-11-06 09:32 ./usr/bin/usewithtor
-rwxr-xr-x root/root 4488 2009-11-06 09:32 ./usr/bin/torsocks
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/doc/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/doc/torsocks/
-rw-r--r-- root/root 152 2009-11-06 09:26
./usr/share/doc/torsocks/changelog.Debian.gz
-rw-r--r-- root/root 2727 2009-11-06 09:26
./usr/share/doc/torsocks/changelog.gz
-rw-r--r-- root/root 2110 2009-11-06 09:26
./usr/share/doc/torsocks/copyright
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/man1/
-rw-r--r-- root/root 505 2009-11-06 09:32
./usr/share/man/man1/usewithtor.1.gz
-rw-r--r-- root/root 743 2009-11-06 09:32
./usr/share/man/man1/torsocks.1.gz
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/man8/
-rw-r--r-- root/root 3085 2009-11-06 09:32
./usr/share/man/man8/torsocks.8.gz
drwxr-xr-x root/root 0 2009-11-06 09:32 ./usr/share/man/man5/
-rw-r--r-- root/root 3131 2009-11-06 09:32
./usr/share/man/man5/torsocks.conf.5.gz
drwxr-xr-x root/root 0 2009-11-06 09:32 ./etc/
-rw-r--r-- root/root 2044 2009-11-06 09:32 ./etc/torsocks.conf
lrwxrwxrwx root/root 0 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.so - libtorsocks.so.1.0.0
lrwxrwxrwx root/root 0 2009-11-06 09:32
./usr/lib/torsocks/libtorsocks.so.1 - libtorsocks.so.1.0.0
Aren't there any headers which should be installed to build packages
against torsocks?
- --
/*
Mit freundlichem Gruß / With kind regards,
Patrick Matthäi
GNU/Linux Debian Developer
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
Comment:
Always if we think we are right,
we were maybe wrong.
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkrz6LIACgkQ2XA5inpabMcZZgCbBerMDfrQzedANrRAFR7lCGYi
kWkAnAnSFvmO9zq1jp3yqBq3b2vl+LNh
=Yo5e
-END PGP SIGNATURE-
diff -Naur torsocks-1.0-gamma.orig/src/torsocks.conf.5 torsocks-1.0-gamma/src/torsocks.conf.5
--- torsocks-1.0-gamma.orig/src/torsocks.conf.5 2009-11-06 09:26:26.0 +0100
+++ torsocks-1.0-gamma/src/torsocks.conf.5 2009-11-06 09:29:03.0 +0100
@@ -22,7 +22,7 @@
to be proxied over a SOCKS server. However, many installations have several
different SOCKS servers to be used to access different internal (and external)
networks. For this reason the configuration file allows the definition of
-'paths' as well as a default SOCKS server.
+`paths' as well as a default SOCKS server.
Paths are declared as blocks in the configuration file. That is, they begin
with a 'path {' line in the configuration file and end with a '}' line. Inside
@@ -66,7 +66,7 @@
.I server
The IP address of the SOCKS server (e.g server = 10.1.4.253). Only one
server may be specified per path block, or one outside a path
-block (to define the default server). Unless --disable-hostnames was
+block (to define the default server). Unless \-\-disable-hostnames was
specified to configure at compile time the server can be specified as
a hostname (e.g server = socks.nec.com)
@@ -118,7 +118,7 @@
.TP
.I reaches
This directive is only valid inside a path block. Its parameter is formed
-as IP[:startport[-endport]]/Subnet and it specifies a network
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 rob...@roberthogan.net 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/general.m4:2665: AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2674: AC_TRY_LINK is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... acinclude.m4:2903: KDE_CHECK_COMPILER_FLAG is expanded from... configure.in:54: warning: AC_REQUIRE: `AC_OBJEXT' was expanded before it was required acinclude.m4:6067: AC_LIBTOOL_SETUP is expanded from... acinclude.m4:6047: _AC_PROG_LIBTOOL is expanded from... acinclude.m4:6012: AC_PROG_LIBTOOL is expanded from... acinclude.m4:11781: AM_PROG_LIBTOOL is expanded from... acinclude.m4:3472: KDE_PROG_LIBTOOL is expanded from... configure.in:54: the top level configure.in:54: warning: AC_REQUIRE: `AC_EXEEXT' was expanded before it was required
Bug#529908: Upstream Fix
On 2009-10-25 Robert Hogan rob...@roberthogan.net wrote: 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!) [...] Hello, I am neither an auto* guru nor familiar with this style of autotools handling, so please take the rest of this mail with *huge* grain of salt. Afaict it basically works like this: The jobs usually done by aclocal and libtoolize are done centrally in SVN. Somebody keeps the copies of the respective tests and scripts in admin/ up to date and Makefile.cvs or whatever imports them into the project. The stuff (m4 tests) in admin/ is complemented by the stuff available in the system (tests included in the autotools suite). This can fall apart if admin/ is not kept up to date. Some of the stuff in admin might require updates to work with newer autootools files on the local system. Afaiui autotools code in KDE (admin/) *is* dead and unmaintained. KDE has switched to cmake. For tork this probably leaves: * Follow KDE and switch to cmake. * Use normal autotools handling. I am not sure this is workable, since the m4-tests for KDE are not maintained upstream. cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529908: Upstream Fix
On 2009-10-19 Robert Hogan rob...@roberthogan.net 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-aq...@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 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/general.m4:2665: AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2674: AC_TRY_LINK is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... acinclude.m4:2903: KDE_CHECK_COMPILER_FLAG is expanded from... configure.in:54: warning: AC_REQUIRE: `AC_OBJEXT' was expanded before it was required acinclude.m4:6067: AC_LIBTOOL_SETUP is expanded from... acinclude.m4:6047: _AC_PROG_LIBTOOL is expanded from... acinclude.m4:6012: AC_PROG_LIBTOOL is expanded from... acinclude.m4:11781: AM_PROG_LIBTOOL is expanded from... acinclude.m4:3472: KDE_PROG_LIBTOOL is expanded from... configure.in:54: the top level configure.in:54: warning: AC_REQUIRE: `AC_EXEEXT' was expanded before it was required configure.in:54: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached [...] cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529908: Upstream Fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Metzler schrieb: On 2009-10-19 Robert Hogan rob...@roberthogan.net 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-aq...@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/general.m4:2665: AC_LINK_IFELSE is expanded from... ../../lib/autoconf/general.m4:2674: AC_TRY_LINK is expanded from... ../../lib/m4sugar/m4sh.m4:620: AS_IF is expanded from... ../../lib/autoconf/general.m4:2018: AC_CACHE_VAL is expanded from... acinclude.m4:2903: KDE_CHECK_COMPILER_FLAG is expanded from... configure.in:54: warning: AC_REQUIRE: `AC_OBJEXT' was expanded before it was required acinclude.m4:6067: AC_LIBTOOL_SETUP is expanded from... acinclude.m4:6047: _AC_PROG_LIBTOOL is expanded from... acinclude.m4:6012: AC_PROG_LIBTOOL is expanded from... acinclude.m4:11781: AM_PROG_LIBTOOL is expanded from... acinclude.m4:3472: KDE_PROG_LIBTOOL is expanded from... configure.in:54: the top level configure.in:54: warning: AC_REQUIRE: `AC_EXEEXT' was expanded before it was required configure.in:54: warning: AC_CACHE_VAL(lt_prog_compiler_static_works, ...): suspicious cache-id, must contain _cv_ to be cached [...] cu andreas - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrkaFIACgkQ2XA5inpabMflJgCfWIvOX07unsRFEpabBn5wQJ8d La8AnRpwsXqSFjMYMEGzO2uvV/fzVVQE =HOVX -END PGP SIGNATURE- --
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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#529908: Upstream Fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Hogan schrieb: 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. checking for makekdewidgets... /usr/bin/makekdewidgets checking for xmllint... /usr/bin/xmllint checking whether byte ordering is bigendian... no checking for MAXPATHLEN... 4096 checking for KDE version... KDE 3.5.x (x =2) or SVN trunk ./configure: line 28170: syntax error near unexpected token `LIBGNUTLS,' ./configure: line 28170: `PKG_CHECK_MODULES(LIBGNUTLS, gnutls = 1.0.0, ,' make: *** [config.status] Error 2 - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkrdj94ACgkQ2XA5inpabMezyACcCrq9akDL1rQ2G2A/h0BO9H6F EokAn2OBxsnD5PLhYl09ikJzRucfaDyy =ZFsU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
