Re: Plans for libvolume-id?
Petr Salinger (01/07/2009): > From #437162 (udev package): > > PS> IMHO, there are effectively only two options > > PS> - build libvolume-id from udev source package on non-linux PS> > architectures > PS> - separate libvolume-id into libvolume-id source package on linux > PS> architectures > > PS> Which one do you prefer ? > > MD> I still do not care enough. Heh, I didn't even think there was a bug open against udev, but that was to be expected. :D > It looks like the new hal 0.5.12 does not use it > > http://cgit.freedesktop.org/hal/log Oh, nice. Should help. I guess I can continue tweaking using libvolume-id and try and get the rest in shape. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Fuse and GNU/kFreeBSD
Hello, I've prepared a package [1] with Aurelien's patch applied. Could you please build and test it on kFreeBSD before I upload this new package? If it works fine, Miklos Szeredi (fuse upstream) is usually nice and I bet he would accept your patch. Do you want me to forward it to him for an inclusion in incoming fuse 2.8 ? Regards, Adam. [1] http://mentors.debian.net/debian/pool/main/f/fuse/fuse_2.7.4-2.dsc -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Plans for libvolume-id?
On Wed, Jul 01, 2009 at 07:33:56AM +0200, Petr Salinger wrote: >> short story: >> - udev produces libvolume-id-dev and its library; >> - the libvolume-id source package was introduced to provide that >> library without udev for GNU/kFreeBSD (and eventually hurd? Didn't >> check.) > > From #437162 (udev package): > > PS> IMHO, there are effectively only two options > > PS> - build libvolume-id from udev source package on non-linux PS> > architectures > PS> - separate libvolume-id into libvolume-id source package on linux > PS> architectures > > PS> Which one do you prefer ? > > MD> I still do not care enough. > MD> Anyway, libvolume-id will disappear in a few weeks so there is no > MD> reason to even discuss this. > >> Since the latter isn't available within Debian yet (but only in >> unreleased), one can't even try to play with hal within sid (and trying >> to get rid of the need for libvolume-is sounds like a PITA). I guess I'm >> gonna install libvolume-id locally for now, but I guess we would need to >> think of either merging it into one of the freebsd-specific source >> package (?) or introducing it (??) but making sure it's only built on >> relevant architectures (Architecture: ˙˙ + P-a-s come to mind). > > It looks like the new hal 0.5.12 does not use it > > http://cgit.freedesktop.org/hal/log > > 2009-05-12update NEWS for 0.5.12 release HAL_0_5_12 > 2009-05-10move from libvolume_id to libblkid > Yes, actually hal 0.5.12 does not need libvolume-id anymore, but use libblkid. Unfortunately the change upstream only concerns Linux, but porting the commit to GNU/kFreeBSD should not be really difficult. About hal itself, I have already filled a bug (#528383) with a patch. The opened point has to be fixed first (mainly the new library that the maintainer doesn't like should be linked statically instead). Note that part of the changes in this patch are already merged upstream for 0.5.13. Unfortunately, being on holidays with bad connectivity, I have no possibility to work on that those days. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
(Keeping you Cc'd, not sure you're on this list.) "Adam Cécile (Le_Vert)" (01/07/2009): > Hello, Hello, > Could you please build and test it on kFreeBSD before I upload this > new package? sure, builds fine. > Do you want me to forward it to him for an inclusion in incoming fuse > 2.8 ? Please, less work for you with the next releases. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Plans for libvolume-id?
Aurelien Jarno (01/07/2009): > Yes, actually hal 0.5.12 does not need libvolume-id anymore, but use > libblkid. Unfortunately the change upstream only concerns Linux, but > porting the commit to GNU/kFreeBSD should not be really difficult. Yep. > About hal itself, I have already filled a bug (#528383) with a patch. I should have mentioned that I've started this thread while working on updating this patch, sorry for that. > The opened point has to be fixed first (mainly the new library that > the maintainer doesn't like should be linked statically instead). Note > that part of the changes in this patch are already merged upstream for > 0.5.13. > > Unfortunately, being on holidays with bad connectivity, I have no > possibility to work on that those days. As agreed during a quick conversation on IRC (also with the maintainer), I'm going to work on getting that library in a reasonable shape, so that we are ready when 0.5.12 gets uploaded (which is blocked by util-linux, e2fsprogs, udev, etc. see #528830). Which means I'm cheating with the locally-hacked libvolume-id library for now, and that we'll only have to do some bits of porting for libblkid by then. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
Hi, On Wed, Jul 01, 2009 at 09:44:29PM +0200, "Adam Cécile (Le_Vert)" wrote: > [1] http://mentors.debian.net/debian/pool/main/f/fuse/fuse_2.7.4-2.dsc Just wondering: is a fuse4bsd source package (see [1]) already available somewhere for testing with this? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528537 What I noticed when building: dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/libfuse2/usr/lib/libulockmgr.so.1.0.1 found in none of the libraries. dpkg-shlibdeps: warning: symbol devname_r used by debian/libfuse2/usr/lib/libfuse.so.2.7.4 found in none of the libraries. If I later try to build sshfs-fuse with the previously built libfuse-dev, it FTBFS which seem to be caused by the above: i486-kfreebsd-gnu-gcc -Wall -g -O2 -Wall -W -Icompat -o sshfs sshfs-sshfs.o sshfs-cache.o sshfs-fuse_opt.o -pthread -lfuse -ldl -lgthread-2.0 -lrt -lglib-2.0 /usr/lib/gcc/i486-kfreebsd-gnu/4.3.3/../../../libfuse.so: undefined reference to `devname_r' collect2: ld returned 1 exit status make[2]: *** [sshfs] Error 1 make[2]: Leaving directory `/home/abe/debian/sshfs-fuse-2.2' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/abe/debian/sshfs-fuse-2.2' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1324: dpkg-buildpackage -rfakeroot -D -us -uc failed Regards, Axel -- Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
What I noticed when building: dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/libfuse2/usr/lib/libulockmgr.so.1.0.1 found in none of the libraries. It should come from libpthread. dpkg-shlibdeps: warning: symbol devname_r used by debian/libfuse2/usr/lib/libfuse.so.2.7.4 found in none of the libraries. It is in our libfreebsd, the added test in configure.in tries to find it by AC_SEARCH_LIBS(devname_r, [freebsd]) It looks like slight tweaking is still needed, at least including Build-Depends: libfreebsd-dev [kfreebsd-amd64 kfreebsd-i386] I do not know the answers for the rest. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
Hi, On Wed, Jul 01, 2009 at 11:40:31PM +0200, Petr Salinger wrote: >> What I noticed when building: >> >> dpkg-shlibdeps: warning: symbol pthread_sigmask used by >> debian/libfuse2/usr/lib/libulockmgr.so.1.0.1 found in none of the libraries. > > It should come from libpthread. $ dpkg -S libpthread libc0.1-dev: /usr/lib/libpthread.so libc0.1-i686: /lib/i686/cmov/libpthread.so.0 libc0.1-dev: /usr/lib/libpthread_nonshared.a libc0.1-dev: /usr/lib/libpthread.a freebsd-hackedutils: /usr/lib/libpthread.so.2 libc0.1: /lib/libpthread.so.0 libc0.1: /lib/libpthread-0.10.so libc0.1-i686: /lib/i686/cmov/libpthread-0.10.so Those were installed while building the package in kfreebsd-i386, but the warning came anyway. >> dpkg-shlibdeps: warning: symbol devname_r used by >> debian/libfuse2/usr/lib/libfuse.so.2.7.4 found in none of the libraries. > It is in our libfreebsd, the added test in configure.in tries to find it by > > AC_SEARCH_LIBS(devname_r, [freebsd]) > > It looks like slight tweaking is still needed, at least including > Build-Depends: libfreebsd-dev [kfreebsd-amd64 kfreebsd-i386] Yeah, installing libfreebsd-dev fixed that. And after installing the libfuse-dev built again with libfreebsd-dev installed, sshfs-fuse still throws some warnings, but at least it no more FTBFS. (Can't install and further test it due to fuse-utils/fuse4bsd missing though.) So, Adam, please include the Build-Depends mentioned above by Petr in the package before uploading it. Or, in case you already uploaded it, please include it in the next upload. Regards, Axel -- Axel Beckert - a...@deuxchevaux.org, a...@noone.org - http://noone.org/abe/ -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
Hi. dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/libfuse2/usr/lib/libulockmgr.so.1.0.1 found in none of the libraries. Those were installed while building the package in kfreebsd-i386, but the warning came anyway. It is not specific for kfreebsd-* as at least in https://buildd.debian.org/fetch.cgi?&pkg=fuse&ver=2.7.4-1.1&arch=i386&stamp=1222983978&file=log https://buildd.debian.org/fetch.cgi?&pkg=fuse&ver=2.7.4-1.1&arch=ia64&stamp=1222984628&file=log is also dpkg-shlibdeps: warning: symbol pthread_sigmask used by debian/libfuse2/usr/lib/libulockmgr.so.1.0.1 found in none of the libraries. May be this will help: --- lib/Makefile.am +++ lib/Makefile.am @@ -38,6 +38,6 @@ -Wl,--version-script,$(srcdir)/fuse_versionscript libulockmgr_la_SOURCES = ulockmgr.c -libulockmgr_la_LDFLAGS = -version-number 1:0:1 +libulockmgr_la_LDFLAGS = -pthread -version-number 1:0:1 EXTRA_DIST = fuse_versionscript Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
Petr Salinger (01/07/2009): >> What I noticed when building: >> >> dpkg-shlibdeps: warning: symbol pthread_sigmask used by >> debian/libfuse2/usr/lib/libulockmgr.so.1.0.1 found in none of the libraries. > > It should come from libpthread. > >> dpkg-shlibdeps: warning: symbol devname_r used by >> debian/libfuse2/usr/lib/libfuse.so.2.7.4 found in none of the libraries. > It is in our libfreebsd, the added test in configure.in tries to find it by > > AC_SEARCH_LIBS(devname_r, [freebsd]) > > It looks like slight tweaking is still needed, at least including > Build-Depends: libfreebsd-dev [kfreebsd-amd64 kfreebsd-i386] Yep, installing that package made fuse built properly (without the previous devname_r issue), and sshfs-fuse was then built without problems. I'm still getting pthread_sigmask has not found, though. :( | k...@kbsd:~/fuse-2.7.4$ objdump -x | debian/libfuse2/usr/lib/libulockmgr.so.1.0.1|grep NEEDED | NEEDED libc.so.0.1 (Long time no see, is -pthead the correct option? configure.in might need an s/-pthread/-lpthread/. Doesn't seem to help, anyway.) Adam (put back in the loop, just to make sure), please consider adding the above-mentioned package to the Build-Depends, at least. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Fuse and GNU/kFreeBSD
Petr Salinger (02/07/2009): > May be this will help: > > --- lib/Makefile.am > +++ lib/Makefile.am > @@ -38,6 +38,6 @@ > -Wl,--version-script,$(srcdir)/fuse_versionscript > > libulockmgr_la_SOURCES = ulockmgr.c > -libulockmgr_la_LDFLAGS = -version-number 1:0:1 > +libulockmgr_la_LDFLAGS = -pthread -version-number 1:0:1 > > EXTRA_DIST = fuse_versionscript (And the same in lib/Makefile.in) It indeed does, no more warnings and indeed: | k...@kbsd:~/fuse-2.7.4$ objdump -x debian/libfuse2/usr/lib/libulockmgr.so.1.0.1|grep NEEDED | NEEDED libpthread.so.0 | NEEDED libc.so.0.1 Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
boost almost there; almost.
Heya, although it built, -lboost_python and -lboost_filesystem aren't found in polybori and sfftobmp respectively. Will try and investigate later, I just wanted to let you know about its not-perfect-yet state. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-ia32-libs-maintainers] Bug#535365: ia32-apt-get: Should drop 32-bit version of type-handling
Daniel Schepler writes: > Package: ia32-apt-get > Version: 20 > Severity: normal > > In a pbuilder amd64 chroot, after installing ia32-apt-get and doing an > apt-get > update (unsetting DEBIAN_FRONTEND so that I could choose the "All" option in > the debconf prompt): > > frobozz:/tmp# dpkg-architecture > DEB_BUILD_ARCH=amd64 > DEB_BUILD_ARCH_OS=linux > DEB_BUILD_ARCH_CPU=amd64 > DEB_BUILD_GNU_CPU=x86_64 > DEB_BUILD_GNU_SYSTEM=linux-gnu > DEB_BUILD_GNU_TYPE=x86_64-linux-gnu > DEB_HOST_ARCH=amd64 > DEB_HOST_ARCH_OS=linux > DEB_HOST_ARCH_CPU=amd64 > DEB_HOST_GNU_CPU=x86_64 > DEB_HOST_GNU_SYSTEM=linux-gnu > DEB_HOST_GNU_TYPE=x86_64-linux-gnu > frobozz:/tmp# apt-get install i386 > Reading package lists... Done > Building dependency tree > Reading state information... Done > Note, selecting type-handling instead of i386 > The following NEW packages will be installed: > type-handling > 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. > Need to get 6222B of archives. > After this operation, 69.6kB of additional disk space will be used. > Get:1 http://ftp.egr.msu.edu sid-amd64/main type-handling 0.2.23 [6222B] > Fetched 6222B in 0s (9674B/s) > debconf: delaying package configuration, since apt-utils is not installed > Selecting previously deselected package type-handling. > (Reading database ... 10982 files and directories currently installed.) > Unpacking type-handling (from .../type-handling_0.2.23_amd64.deb) ... > Setting up type-handling (0.2.23) ... > frobozz:/tmp# apt-get install not+amd64 > Reading package lists... Done > Building dependency tree > Reading state information... Done > Note, selecting type-handling instead of not+amd64 > type-handling is already the newest version. > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. > > So having a 32-bit version of type-handling available to install seems to > defeat the whole purpose of the type-handling package. > -- > Daniel Schepler Actually I think you found a bug in apt: Package: type-handling Architecture: amd64 Version: 0.2.23 Provides: amd64, linux, linux-gnu, not+alpha, not+arm, not+armeb, not+bsd-darwin, not+bsd-freebsd, not+bsd-netbsd, not+bsd-openbsd, not+darwin, not+freebsd, not+gnu, not+gnu-hurd, not+gnu-kfreebsd, not+gnu-knetbsd, not+gnu-linux, not+gnueabi-linux, not+gnulp-linux, not+hppa, not+i386, not+i486, not+ia64, not+kfreebsd-gnu, not+knetbsd-gnu, not+linux-gnueabi, not+linux-gnulp, not+m32r, not+m68k, not+mips, not+mipsel, not+netbsd, not+openbsd, not+powerpc, not+powerpc64, not+ppc64, not+s390, not+s390x, not+sh3, not+sh3eb, not+sh4, not+sh4eb, not+solaris, not+sparc, not+sysv-solaris, x86-64-linux-gnu Filename: pool/main/t/type-handling/type-handling_0.2.23_amd64.deb Package: type-handling Architecture: amd64 Version: 0.2.23~21 Provides: i386, i486-linux-gnu, linux, linux-gnu, not+alpha, not+amd64, not+arm, not+armeb, not+bsd-darwin, not+bsd-freebsd, not+bsd-netbsd, not+bsd-openbsd, not+darwin, not+freebsd, not+gnu, not+gnu-hurd, not+gnu-kfreebsd, not+gnu-knetbsd, not+gnu-linux, not+gnueabi-linux, not+gnulp-linux, not+hppa, not+ia64, not+kfreebsd-gnu, not+knetbsd-gnu, not+linux-gnueabi, not+linux-gnulp, not+m32r, not+m68k, not+mips, not+mipsel, not+netbsd, not+openbsd, not+powerpc, not+powerpc64, not+ppc64, not+s390, not+s390x, not+sh3, not+sh3eb, not+sh4, not+sh4eb, not+solaris, not+sparc, not+sysv-solaris Filename: pool/main/t/type-handling/type-handling_0.2.23_i386.deb 'apt-get install i386' should install type-handling=0.2.23~21. Instead it installs type-handling=0.2.23 which does NOT provide i386. So unlike what the apt-get output might suggest you actually don't have "i386" installed now and neither not+amd64. Which is what you want I guess. But ask ia32-apt-get to do something stupid and it will. If you specifically say apt-get install type-handling=0.2.23~21 then you will get i386 and non+amd64. I think that is not a bug in ia32-apt-get as you do have to specifically ask for it. I consider that to be the same as rm allowing 'rm -rf /'. I do agree however that type-handling does not do the right thing here and will not do the right thing with mutliarch. I'm not really sure what the right type-handling output for an amd64/i386 system would be but I guess it should be something like Provides: i386 amd64 not+i386 not+amd64 ... The not+ syntax does not really make much sense when multiple architectures are supported. The current type-handling does not provides the "right" things in either the amd64 not the i386 deb for such a system. MfG Goswin -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
