Re: catch 22 - manual upload of qt4-x11 for GNU/kFreeBSD needed
On 2009-06-29, Petr Salinger wrote: > Hi DDs ;-) > > Unfortunately > > phonon Build-Depends on libqt4-dev > qt4-x11 Build-Depends on libphonon-dev > > Therefore a manual build of qt4-x11 will be needed for both GNU/kFreeBSD > architectures. All others Build-Depends of qt4-x11 are available. Planned to be fixed on next upload, where phonon libs is built from qt4 sources. /Sune -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: catch 22 - manual upload of qt4-x11 for GNU/kFreeBSD needed
On Tue, Jun 30, 2009 at 09:04:06AM +0200, Petr Salinger wrote: > Hi again. > >>> phonon Build-Depends on libqt4-dev >>> qt4-x11 Build-Depends on libphonon-dev >>> >>> Therefore a manual build of qt4-x11 will be needed for both GNU/kFreeBSD >>> architectures. All others Build-Depends of qt4-x11 are available. >> >> Unfortunately this is not yet possible, as the build-dependencies of >> phonon are not all available. We are facing a lot bigger >> build-dependency loop through avahi and pulseaudio and maybe gnome. >> It looks like the next things to get is all the build-dependencies of >> xine-lib that are not in the big build-depends loop. > > I thought, it is possible to install "all others Build-Depends of qt4-x11" > from debian.org, install libphonon-dev and its dependents (libphonon4, > libqt*4*) from debian-ports.org, build qt4-x11 and upload it into debian.org. > >> From debian/rules of qt4-x11: > > config.status: > ./configure > ... > -phonon \ > -no-phonon-backend \ > > common-install-arch:: > # Use system phonon > rm -f lib/*phonon* debian/tmp/usr/lib/*phonon* > > So it looks like whole purpose of Build-Depends on libphonon-dev is > to get Dependency lines for libqt4-webkit and qt4-demos packages. > Technically it is clearly possible, but we have been asked to bootstrap the kfreebsd-* architectures again. So if I understand correctly, what we should do is: - build qt4 using phonon from debian-ports.org - build phonon using the just built qt4 - rebuild qt4 using the just built phonon Upload both resulting packages. But if the build-dependency loop is very long and difficult to break, we may end-up doing what you suggest. -- 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: catch 22 - manual upload of qt4-x11 for GNU/kFreeBSD needed
Technically it is clearly possible, but we have been asked to bootstrap the kfreebsd-* architectures again. So if I understand correctly, what we should do is: - build qt4 using phonon from debian-ports.org - build phonon using the just built qt4 - rebuild qt4 using the just built phonon Upload both resulting packages. But if the build-dependency loop is very long and difficult to break, we may end-up doing what you suggest. I do not know the exact negotiations with ftp-masters. The dependency loop is rather long and includes even hal. But today email from Sune Vuorela suggest we can also just wait for 4.5.2-1 upload: -- Forwarded message -- Date: Tue, 30 Jun 2009 01:03:50 + (UTC) From: Sune Vuorela Planned to be fixed on next upload, where phonon libs is built from qt4 sources. /Sune -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFC: patch for libibverbs
Hi, while setting up a devel box, I've tried to install sbuild, but thanks to a huge chain of dependencies, it's not installable because of schroot, mpi, etc. until libibverbs. For that one, I've written the attached patch, but it sounds like suboptimal to me. I guess there might be a better way to express those types. Maybe using the types I've defined everywhere in the sources, instead of the “linuxisms” (I'd assume they are) that are currently used? I'm going to file a bug against that package with that current patch and eventually open a minor bug later if someone points me to a better approach. Thanks for your time. Mraw, KiBi. --- a/include/infiniband/kern-abi.h +++ b/include/infiniband/kern-abi.h @@ -35,7 +35,19 @@ #ifndef KERN_ABI_H #define KERN_ABI_H +#if __linux #include +#else +#include +#define __u64 u_int64_t +#define __s64 int64_t +#define __u32 u_int32_t +#define __s32 int32_t +#define __u16 u_int16_t +#define __s16 int16_t +#define __u8 u_int8_t +#define __s8int8_t +#endif /* * This file must be kept in sync with the kernel's version of --- a/include/infiniband/sa-kern-abi.h +++ b/include/infiniband/sa-kern-abi.h @@ -33,7 +33,19 @@ #ifndef INFINIBAND_SA_KERN_ABI_H #define INFINIBAND_SA_KERN_ABI_H +#if __linux #include +#else +#include +#define __u64 u_int64_t +#define __s64 int64_t +#define __u32 u_int32_t +#define __s32 int32_t +#define __u16 u_int16_t +#define __s16 int16_t +#define __u8 u_int8_t +#define __s8int8_t +#endif /* * Obsolete, deprecated names. Will be removed in libibverbs 1.1.
Re: RFC: patch for libibverbs
while setting up a devel box, I've tried to install sbuild, but thanks to a huge chain of dependencies, it's not installable because of schroot, mpi, etc. until libibverbs. Is the libibverbs package reasonable on GNU/kFreeBSD ? It looks like it is a userspace counterpart to some (linux) kernel driver. The openmpi package have it excluded just for this reason (see #433142): Build-Depends: debhelper (>= 5.0.0), libibverbs-dev (>= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], gfortran, gcc (>= 4:4.1.2), chrpath, quilt It looks like the real problem lies in the libopenmpi-dev package as it should similarly use Depends: ... libibverbs-dev (>= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386] in debian/control. Unfortunately the libibverbs-dev everywhere got in due to #522153 :-( My suggestion is to do not submit bug to libibverbs, but to openmpi. Petr -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: patch for libibverbs
Petr Salinger (30/06/2009): > Is the libibverbs package reasonable on GNU/kFreeBSD ? It looks like it is a > userspace counterpart to some (linux) kernel driver. Dunno. Was my first impression, but since it built anyway… :) > The openmpi package have it excluded just for this reason (see #433142): > Build-Depends: debhelper (>= 5.0.0), libibverbs-dev (>= 1.1.1) > [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], gfortran, gcc (>= 4:4.1.2), > chrpath, quilt > > It looks like the real problem lies in the libopenmpi-dev package as it > should similarly use > > Depends: ... libibverbs-dev (>= 1.1.1) [!kfreebsd-i386 !kfreebsd-amd64 > !hurd-i386] Well, then building will fail when trying to find the .la, so we'd have to get rid of it conditionally for non-Linux architectures. > Unfortunately the libibverbs-dev everywhere got in due to #522153 :-( Which would be reopened for non-Linux arch if we don't strip the .la. > My suggestion is to do not submit bug to libibverbs, but to openmpi. I'm going to follow up to my libibverbs bug, asking for the maintainers' opinion. (Currently with my libibverbs patch, mpi got built, boost building.) Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: patch for libibverbs
Cyril Brulebois (30/06/2009): > > Depends: ... libibverbs-dev (>= 1.1.1) [!kfreebsd-i386 > > !kfreebsd-amd64 !hurd-i386] > > Well, then building will fail when trying to find the .la, so we'd > have to get rid of it conditionally for non-Linux architectures. There's no ibverbs references in the .la's, nice build system. \o/ > > My suggestion is to do not submit bug to libibverbs, but to openmpi. > > I'm going to follow up to my libibverbs bug, asking for the > maintainers' opinion. Did so, opened #535225, fixed openmpi on its way thanks to a very responsive maintainer. mpi-defaults might then FTBFS (#535230), but otherwise boost1.38 can then be tried. I sent some wb requests to Aurélien already. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Port insserv to kfreebsd? [done]
Heya. Guillem Jover (28/06/2009): > posix_fadvise is optional per POSIX, so checking that that builds if > you use autoconf or for the macro is better. You should also probably > return ENOSYS instead. Petter should have received one of the successful build logs already, but let's let -bsd and other initscripts-ng folks know: insserv was built successfully on both kfreebsd-*. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: porter NMUs for GNU/kFreeBSD needed
Cyril Brulebois (29/06/2009): > > - python-stdlib-extensions: #521078 > > FTBFS with current blt-dev (build-depends have to be changed) > > Serious bug since Tue, 24 Mar 2009, blocks at least GNOME > > I'll take a look at those, possibly before tomorrrow. Done too, to DELAYED/1 (well, doko really deserved it to be DELAYED/0, but well, I'm not *that* in a hurry). It brings python-gdbm, but that's not sufficient for avahi, which also needs python-gtk2, which then goes back to libhal-dev. Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Plans for libvolume-id?
Heya, 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.) 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). Mraw, KiBi. -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535243: kfreebsd-kernel-headers: Wrong type in ?
Package: kfreebsd-kernel-headers
Version: 0.34
Severity: important
Tags: patch
Heya,
while working on hal on kfreebsd-i386, I've stumbled upon the following:
./hald/freebsd/hf-pci.c includes , but the latter uses
uint64_t for the pci_bar_io structure, instead of u_intNN_t for other
structures, and the compiler fails on that token.
Maybe a -D (I tried __USE_BSD) or another include is missing? Or one
could just use the attached patch (I copied the path from the
000_bruno_haible.diff patch, I didn't install the whole sources)?
Mraw,
KiBi.
--- src/sys/sys/pciio.h
+++ src/sys/sys/pciio.h
@@ -113,8 +113,8 @@
struct pcisel pbi_sel; /* device to operate on */
int pbi_reg; /* starting address of BAR */
int pbi_enabled; /* decoding enabled */
- uint64_t pbi_base; /* current value of BAR */
- uint64_t pbi_length; /* length of BAR */
+ u_int64_t pbi_base; /* current value of BAR */
+ u_int64_t pbi_length; /* length of BAR */
};
#define PCIOCGETCONF _IOWR('p', 5, struct pci_conf_io)
Re: Plans for libvolume-id?
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-12 update NEWS for 0.5.12 release HAL_0_5_12 2009-05-10 move from libvolume_id to libblkid Petr
