Re: Riddling absence of /usr/lib/libattr.la
Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Yes, that's the problem: it should rather be a -lattr, because libattr.la is not shipped any more. That would be fixed by a newer build of the acl package, but unfortunately it FTBFS ATM (PATH_MAX, #636512). libisofs not building was becoming more and more a problem, so I patched the libacl.la file by hand (yes, a bad thing). So probably one should re-name the bug to libacl-dev on hurd-i386 depends on LAFileRemoval victim libattr.la Well, for the hurd-i386 case, just a rebuild should work, it just doesn't build any more. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829090112.gc4...@type.u-bordeaux.fr
Re: Bug#639517: Riddling absence of /usr/lib/libattr.la
On Mon, Aug 29, 2011 at 11:01:12AM +0200, Samuel Thibault wrote: Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Yes, that's the problem: it should rather be a -lattr, because libattr.la is not shipped any more. That would be fixed by a newer build of the acl package, but unfortunately it FTBFS ATM (PATH_MAX, #636512). You suggest to reintroduce .la files for acl and attr and use -lattr in dependency_libs of /lib/libacl.la after fixing #636512, right? I think we could try it. libisofs not building was becoming more and more a problem, so I patched the libacl.la file by hand (yes, a bad thing). So probably one should re-name the bug to libacl-dev on hurd-i386 depends on LAFileRemoval victim libattr.la Well, for the hurd-i386 case, just a rebuild should work, it just doesn't build any more. Samuel signature.asc Description: Digital signature
Re: Bug#639517: Riddling absence of /usr/lib/libattr.la
Aníbal Monsalve Salazar, le Mon 29 Aug 2011 22:10:25 +1000, a écrit : On Mon, Aug 29, 2011 at 11:01:12AM +0200, Samuel Thibault wrote: Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Yes, that's the problem: it should rather be a -lattr, because libattr.la is not shipped any more. That would be fixed by a newer build of the acl package, but unfortunately it FTBFS ATM (PATH_MAX, #636512). You suggest to reintroduce .la files for acl and attr and use -lattr in dependency_libs of /lib/libacl.la after fixing #636512, right? Not at all. I'm suggesting simply fixing the acl FTBFS, since it should solve the whole issue. Samuel -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110829123453.GB3244@type
Re: Bug#639517: Riddling absence of /usr/lib/libattr.la
On 08/29/2011 11:01 AM, Samuel Thibault wrote: Thomas Schmitt, le Sat 27 Aug 2011 21:54:31 +0200, a écrit : This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Yes, that's the problem: it should rather be a -lattr, because libattr.la is not shipped any more. That would be fixed by a newer build of the acl package, but unfortunately it FTBFS ATM (PATH_MAX, #636512). libisofs not building was becoming more and more a problem, so I patched the libacl.la file by hand (yes, a bad thing). A porter binNMU of the old days ;-) Cheers Luk -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e5bb7de.3050...@debian.org
Riddling absence of /usr/lib/libattr.la
Hi, since yesterday i am proud operator of a Debian GNU/Hurd installed via http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/netinst.iso in a kvm image file on Debian GNU/Linux 6.0.2 amd64. Building my projects GNU xorriso or libisofs from source tarball failed with missing /usr/lib/libattr.la if libacl-dev is installed. I solved this by copying /usr/lib/libattr.la from the hosting system to Hurd, where i had to change its content from libdir='/usr/lib' to libdir='/lib/i386-gnu' But libisofs-1.1.4 builds fine on buildd (bach) for hurd-i386. The version numbers of libacl and libattr packages match mine. So i am riddling what might be the decisive difference in my installation. The tarball and its build system are generated by autotools. I did: $ wget http://files.libburnia-project.org/releases/libisofs-1.1.4.tar.gz $ tar xzf libisofs-1.1.4.tar.gz $ cd libisofs-1.1.4 $ ./configure make [...] checking sys/acl.h usability... yes checking sys/acl.h presence... yes checking for sys/acl.h... yes checking for acl_to_text in -lacl... yes checking attr/xattr.h usability... yes checking attr/xattr.h presence... yes checking for attr/xattr.h... yes checking for listxattr in -lc... yes [... more configuration and lots of compilation ...] /bin/bash ./libtool --silent --tag=CC --mode=link [...] [...] libisofs/libisofs_libisofs_la-md5.lo -lpthread -lz -lacl grep: /usr/lib/libattr.la: No such file or directory /bin/sed: can't read /usr/lib/libattr.la: No such file or directory libtool: link: `/usr/lib/libattr.la' is not a valid libtool archive make: *** [libisofs/libisofs.la] Error 1 $ libacl-dev was installed by apt-get from the default location http://jk.fr.eu.org/debian/hurd-installer/mirror dpkg -l reports: libacl12.2.47-3 libacl1-dev2.2.47-3 apt-file on the hosting GNU/Linux says that /usr/lib/libattr.la would belong to libattr1-dev which i installed for xattr support anyway. But there was no such file installed here. libattr1 1:2.4.46-3 libattr1-dev 1:2.4.46-3 buildd log (from bach) reports Setting up libattr1-dev (1:2.4.46-3) ... Setting up libacl1-dev (2.2.47-3) ... and the same ./configure messages about acl and xattr as my Hurd. After copying and adapting the missing file, GNU xorriso gets linked with libattr.so.1 = /lib/i386-gnu/libattr.so.1 (0x0106c000) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98960612519734@192.168.2.69
Re: Riddling absence of /usr/lib/libattr.la
Hello, dpkg -S libattr* | grep la is returning empty for me too. Package: libattr1 Source: attr Version: 1:2.4.46-3 Architecture: hurd-i386 I have posted a bug report,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639517 CREDIT clarification: If there is response from the debian maintainer, i will give you credit for the find ( I forgot and i have already sent two mails). You could also interact with BugDB to take ownership, credit for the find,etc. Regards, Harish -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafuoqbezozqmhoelnzkyt1jyhnuouyhxlqm6-kqq1r+y4ix...@mail.gmail.com
Re: Riddling absence of /usr/lib/libattr.la
Hello, dpkg -S libattr* | grep la is returning empty for me too. Package: libattr1 Source: attr Version: 1:2.4.46-3 Architecture: hurd-i386 I have posted a bug report,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639517 CREDIT clarification: If there is response from the debian maintainer, i will give you credit for the find ( I forgot and i have already sent two mails). You could also interact with BugDB to take ownership, credit for the find,etc. Regards, Harish -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAFUoqbfUTHaHDqpnj9+mw8=q-sxkxucaqmfg0tb2a_1cujw...@mail.gmail.com
Re: Riddling absence of /usr/lib/libattr.la
On Sun, Aug 28, 2011 at 12:21 AM, Niv Sardi xa...@debian.org wrote: http://wiki.debian.org/ReleaseGoals/LAFileRemoval IIRC, It's a release goal. Well that was embarrassing :). I will close the bug. Sorry, Harish On Aug 27, 2011 3:42 PM, Harish Badrinath harishbadrin...@gmail.com wrote: Package: libattr1-dev Version: 1:2.4.46-3 Severity: important Tags: experimental sid Hello, It seems that libattr.la is not being included in the binary deb packages. It was observed under hurd-i386, sid. But on linux-i386 the problem was not existant. I have attached a simple patch, that fixed the issue. Dont know if its the right way to do it, but dpkg -S started to show libattr.la files after the changes were done. Have a nice day, Harish -- System Information: Debian Release: wheezy/sid Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.3.99/Hurd-0.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libattr1-dev depends on: ii libattr1 1:2.4.46-3 Extended attribute shared library ii libc0.3-dev [libc6-dev] 2.13-16 Embedded GNU C Library: Developmen libattr1-dev recommends no packages. libattr1-dev suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafuoqbfr8e5gjurawtssrbkgidbwzveqhwbbe63-hudnuma...@mail.gmail.com
Re: Bug#639517: Riddling absence of /usr/lib/libattr.la
Sorry thanks for your patch... as the release goal says if you can make a case for using it then we should ship (and use your pat h, thanks a lot for taking the effort). I'll let nathans comment what he thinks, Cheers On Aug 27, 2011 4:00 PM, harish badrinath harishbadrin...@gmail.com wrote: On Sun, Aug 28, 2011 at 12:21 AM, Niv Sardi xa...@debian.org wrote: http://wiki.debian.org/ReleaseGoals/LAFileRemoval IIRC, It's a release goal. Well that was embarrassing :). I will close the bug. Sorry, Harish On Aug 27, 2011 3:42 PM, Harish Badrinath harishbadrin...@gmail.com wrote: Package: libattr1-dev Version: 1:2.4.46-3 Severity: important Tags: experimental sid Hello, It seems that libattr.la is not being included in the binary deb packages. It was observed under hurd-i386, sid. But on linux-i386 the problem was not existant. I have attached a simple patch, that fixed the issue. Dont know if its the right way to do it, but dpkg -S started to show libattr.la files after the changes were done. Have a nice day, Harish -- System Information: Debian Release: wheezy/sid Architecture: hurd-i386 (i686-AT386) Kernel: GNU-Mach 1.3.99/Hurd-0.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libattr1-dev depends on: ii libattr1 1:2.4.46-3 Extended attribute shared library ii libc0.3-dev [libc6-dev] 2.13-16 Embedded GNU C Library: Developmen libattr1-dev recommends no packages. libattr1-dev suggests no packages. -- no debconf information
Re: Riddling absence of /usr/lib/libattr.la
Hi, harish badrinath wrote on debian-hurd@lists.debian.org: I have posted a bug report,http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639517 Niv Sardi wrote to 639...@bugs.debian.org: http://wiki.debian.org/ReleaseGoals/LAFileRemoval IIRC, It's a release goal. I do wonder, how my generated Makefile comes to the idea to expect libattr.la if it is removed from the system. None of my files mentions libattr. This idea must come from libacl-dev. And really in /lib/libacl.la i read dependency_libs=' /usr/lib/libattr.la' Following the prescriptions in LAFileRemoval i change it to dependency_libs='' Suddenly my libisofs source builds without the need for libattr.la. libisofs.la has now dependency_libs=' -lpthread -lz /lib//libacl.la' rather than dependency_libs=' -lpthread -lz /lib//libacl.la /usr/lib/libattr.la' GNU xorriso builds too. So probably one should re-name the bug to libacl-dev on hurd-i386 depends on LAFileRemoval victim libattr.la Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/98961825130110@192.168.2.69
