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 blo
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 ra
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/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... > > acinc
Bug#529908: Upstream Fix
On 2009-10-25 Robert Hogan 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 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 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-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) iEYEARECAAYFAkrkaFIACgkQ2XA5inpabMflJgCfWIvOX07
Bug#529908: Upstream Fix
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-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 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
