Re: skype 2.1 beta for linux
El día Thursday, September 03, 2009 a las 12:24:07AM +0200, Martin Wilke escribió: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Wed, Sep 02, 2009 at 09:27:40PM +0300, Andriy Gapon wrote: > > > > Just noticed this: > > http://www.skype.com/intl/en/download/skype/linux/ > > > > It doesn't work, this version missing the OSS support, > I talked to the guys we get later a oss version! > > - - Martin I'm using 2.0.0.72-oss in 8-CURRENT which works fine for me. I don't need a better Skype version, what I would like to see is that also the video would work in Skype for us in FBSD. Just my opinion about a newer Skype. Thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: skype 2.1 beta for linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 03, 2009 at 10:10:15AM +0200, Matthias Apitz wrote: > El día Thursday, September 03, 2009 a las 12:24:07AM +0200, Martin Wilke > escribió: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On Wed, Sep 02, 2009 at 09:27:40PM +0300, Andriy Gapon wrote: > > > > > > Just noticed this: > > > http://www.skype.com/intl/en/download/skype/linux/ > > > > > > > It doesn't work, this version missing the OSS support, > > I talked to the guys we get later a oss version! > > > > - - Martin > > I'm using 2.0.0.72-oss in 8-CURRENT which works fine for me. I don't > need a better Skype version, what I would like to see is that also the > video would work in Skype for us in FBSD. Just my opinion about a newer > Skype. Also that's not a problem from Skype, FreeBSD need a v4l(v4bsd)... - - Martin > > Thx > > matthias > -- > Matthias Apitz > t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 > e - w http://www.unixarea.de/ > People who hate Microsoft Windows use Linux but people who love UNIX use > FreeBSD. > - -- +---+---+ | PGP: 0xB1E6FCE9 | Jabber : miwi(at)BSDCrew.de | | Skype : splash_111 | Mail : miwi(at)FreeBSD.org | +---+---+ | Mess with the Best, Die like the Rest! | +---+---+ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (FreeBSD) iEYEARECAAYFAkqfhFYACgkQdLJIhLHm/Ol3OACg4vV9WkjBjm498ika1lktUZ/7 kCsAn2n82QxvTS+lC8werC+9mSzXlLeY =u/yO -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: skype 2.1 beta for linux
El día Thursday, September 03, 2009 a las 10:54:46AM +0200, Martin Wilke escribió: > > I'm using 2.0.0.72-oss in 8-CURRENT which works fine for me. I don't > > need a better Skype version, what I would like to see is that also the > > video would work in Skype for us in FBSD. Just my opinion about a newer > > Skype. > > Also that's not a problem from Skype, FreeBSD need a v4l(v4bsd)... I know. Even better would be that Skype.com provides a native FreeBSD port of Skype. matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ People who hate Microsoft Windows use Linux but people who love UNIX use FreeBSD. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
V4bsd (Was: Re: skype 2.1 beta for linux)
On Thursday 03 September 2009 10:54:46 Martin Wilke wrote: > Also that's not a problem from Skype, FreeBSD need a v4l(v4bsd)... Without getting into the nitty gritty of USB/PCI, what does a camera really do? Power on/off and send a stream of pictures in format X? I've never understood why it is so complex, that v4l needs a second release to get to a somewhat acceptable API. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: libical config error Cannot find Python.h
On Wednesday 26 August 2009 10:02:50 David Southwell wrote: > Thanks Greg -- as usual your are right on the button. I have done as you > suggested and disabled the GNU Pth which I would have prefered to have but > can get round for a while. Just curious, but why do you prefer a userland threads wrapper over 1:1 kernel threads when the application doesn't require it? -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Dovecot Sieve port switched from CMU Sieve to Dovecot
Mel Flynn wrote:
On Saturday 29 August 2009 20:11:22 Wesley Shields wrote:
On Fri, Aug 28, 2009 at 03:19:37PM -0400, Yarema wrote:
I was previously overruled by a committer when I filed a PR to default
ManageSieve to ON. IIRC, POLA was sited as the reason. I'm still of
the opinion that the ManageSieve patch to the main dovecot port should
default to ON for the following reasons:
- with the ManageSieve patch built into the package it becomes possible
for users of binary packages to just install the dovecot-sieve and
dovecot-managesieve ports and have them work. As it stands now anyone
who wants to use ManageSieve has to build the dovecot port from source.
So it doesn't even make sense to have a binary package of
dovecot-managesieve unless the ManageSieve patch is built into the
dovecot package by default as well.
- the ManageSieve patch does not add much bulk to the package. Those
who do not use ManageSieve can simply ignore it or if they build from
source can disable it. Either way from the perspective of those who do
not use ManageSieve nothing really changes (thus POLA is not violated).
- and finally there would be fewer broken PRs filed without the distinfo
for the ManageSieve patch included.
In my opinion it seems not having the binary dovecot-managesieve package
"just work" is more of a POLA violation than having an extra
README.managesieve and related dovecot.conf sections installed by
default in the main dovecot port.
I have no problems marking that option as on by default since it will
mean that the managesieve port can be usefully packaged, while not
bloating the port at all.
To further this issue in the "right" direction, I've investigated the bloat,
using a slave port:
PORTNAME= dovecot
PKGNAMESUFFIX= -withsieve
CATEGORIES= mail ipv6
MASTERDIR= ${.CURDIR}/../../mail/dovecot
CONFLICTS= dovecot-1*
.include "${MASTERDIR}/Makefile"
.if defined(WITHOUT_MANAGESIEVE)
.undef WITHOUT_MANAGESIEVE
.endif
WITH_MANAGESIEVE= yes
Result:
-rw-r--r-- 1 root wheel 2626479 Sep 2 05:05 dovecot-1.2.4.tbz
-rw-r--r-- 1 root wheel 2626719 Sep 2 05:04 dovecot-withsieve-1.2.4.tbz
I think more bytes have been wasted on discussing this, then it adds to the
port. Also, I've left it off, thinking "I'll add this later or just add the
package", because the OPTION framework does not really have enough room to
specify "You have to tick this option to ON if you want to be able to add
dovecot-managesieve port later", so yes, POLA was violated by not having it on
by default and the description should probably read something like "Set to off
if you never want managesieve support".
OK then, Wesley, would you mind defaulting the MANAGESIEVE option to
"on" and closing PR/138300? Which is definitely approved, though we'll
most likely have to remove this new patch once it's rolled into the next
release upstream. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/138300
I don't believe we need to bump PORTREVISION for either of these changes
since it only affects GSSAPI users and/or binary package users. But if
you feel PORTREVISION ought to be bumped up, then so be it. I can roll
a new patch set if need be and tack it on to the above mentioned PR or
file a new one. But as Mel puts it we're using up more bytes in this
thread than is gonna end up in the port after all is said and done.. :)
--
Yarema
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: boost-python-libs and associated compile errors
[Repeating part of thread here to return to the mailing list] 2009/9/3 David Southwell : >> > dns1# md5 /usr/include/c++/4.2/bits/gthr-default.h >> > MD5 (/usr/include/c++/4.2/bits/gthr-default.h) = >> > 2195ca86c1ea76936a87adabe52e461b >> >> Well, this is the same as my. Compiler/header inconsistence version >> fails. have no ideas currently, what causes your issue. I'll try to >> update the ports and build openbabel to see if this is very recent >> failure. >> >> Sincerely, >> Alexander Churanov, >> maintainer of devel/boost-* > this is an amd64 on intel quad 4 > I do not know if that has anything to do with it!! > > David > I do not know too, but this may be the reason. I'll try to rebuild latest openbabel on amd64. By the way on i386 it had rebuilt flawlessly and boost-python-libs too. Sincerely, Alexander Churanov, maintainer of devel/boost-* ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Dovecot Sieve port switched from CMU Sieve to Dovecot
On Thu, Sep 03, 2009 at 08:01:39AM -0400, Yarema wrote:
> Mel Flynn wrote:
> > On Saturday 29 August 2009 20:11:22 Wesley Shields wrote:
> >> On Fri, Aug 28, 2009 at 03:19:37PM -0400, Yarema wrote:
> >
> >>> I was previously overruled by a committer when I filed a PR to default
> >>> ManageSieve to ON. IIRC, POLA was sited as the reason. I'm still of
> >>> the opinion that the ManageSieve patch to the main dovecot port should
> >>> default to ON for the following reasons:
> >>>
> >>> - with the ManageSieve patch built into the package it becomes possible
> >>> for users of binary packages to just install the dovecot-sieve and
> >>> dovecot-managesieve ports and have them work. As it stands now anyone
> >>> who wants to use ManageSieve has to build the dovecot port from source.
> >>> So it doesn't even make sense to have a binary package of
> >>> dovecot-managesieve unless the ManageSieve patch is built into the
> >>> dovecot package by default as well.
> >>>
> >>> - the ManageSieve patch does not add much bulk to the package. Those
> >>> who do not use ManageSieve can simply ignore it or if they build from
> >>> source can disable it. Either way from the perspective of those who do
> >>> not use ManageSieve nothing really changes (thus POLA is not violated).
> >>>
> >>> - and finally there would be fewer broken PRs filed without the distinfo
> >>> for the ManageSieve patch included.
> >>>
> >>> In my opinion it seems not having the binary dovecot-managesieve package
> >>> "just work" is more of a POLA violation than having an extra
> >>> README.managesieve and related dovecot.conf sections installed by
> >>> default in the main dovecot port.
> >> I have no problems marking that option as on by default since it will
> >> mean that the managesieve port can be usefully packaged, while not
> >> bloating the port at all.
> > To further this issue in the "right" direction, I've investigated the
> > bloat,
> > using a slave port:
> > PORTNAME= dovecot
> > PKGNAMESUFFIX= -withsieve
> > CATEGORIES= mail ipv6
> > MASTERDIR= ${.CURDIR}/../../mail/dovecot
> > CONFLICTS= dovecot-1*
> >
> > .include "${MASTERDIR}/Makefile"
> > .if defined(WITHOUT_MANAGESIEVE)
> > .undef WITHOUT_MANAGESIEVE
> > .endif
> > WITH_MANAGESIEVE= yes
> >
> > Result:
> > -rw-r--r-- 1 root wheel 2626479 Sep 2 05:05 dovecot-1.2.4.tbz
> > -rw-r--r-- 1 root wheel 2626719 Sep 2 05:04 dovecot-withsieve-1.2.4.tbz
> >
> > I think more bytes have been wasted on discussing this, then it adds to the
> > port. Also, I've left it off, thinking "I'll add this later or just add the
> > package", because the OPTION framework does not really have enough room to
> > specify "You have to tick this option to ON if you want to be able to add
> > dovecot-managesieve port later", so yes, POLA was violated by not having it
> > on
> > by default and the description should probably read something like "Set to
> > off
> > if you never want managesieve support".
>
> OK then, Wesley, would you mind defaulting the MANAGESIEVE option to
> "on" and closing PR/138300? Which is definitely approved, though we'll
> most likely have to remove this new patch once it's rolled into the next
> release upstream. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/138300
The patch from ports/138300 will be committed today, along with
defaulting MANAGESIEVE to on.
> I don't believe we need to bump PORTREVISION for either of these changes
> since it only affects GSSAPI users and/or binary package users. But if
> you feel PORTREVISION ought to be bumped up, then so be it. I can roll
> a new patch set if need be and tack it on to the above mentioned PR or
> file a new one. But as Mel puts it we're using up more bytes in this
> thread than is gonna end up in the port after all is said and done.. :)
PORTREVISION will be bumped because it does change the default package
and fixes a bug.
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Open discution for a fakeroot support for the ports infrastructure
FAKE_MAKEARGS?= ${MAKE_ARGS} ${DESTDIRNAME}=${FAKE_DESTDIR}
in this bsd.fake.mk DESTDIRNAME= DESTDIR
normally all ./configure/gmake/gmake install supports DESTIR during
the gmake install
gmake install is replaced by gmake DESTFIR=$FAKE_DESTDIR} install
which does the job well.
but there could be some cases where gmake install doesn't support
DESTDIR and the porters didn't overrite the installer. I didn't find
one of them during my testing, there should have really few of them
and they won't work, but with the last patch, and that's why
activating the fake behaviour is optionnal in the last patch.
regards,
Bapt
2009/9/3 Ulrich Spörlein
>
> On Mon, 31.08.2009 at 23:26:43 +0200, Baptiste Daroussin wrote:
> > Hi,
> >
> > I've written some patches for the ports infrastructure importing the
> > fakeroot implementation from midnightbsd ports.
> >
> > In my first implementation the fake directory was enabled by default, no
> > ports had to be modified to support it.
> > My second implementation added a knob to add to make.conf (USE_FAKE) to
> > enable it for people wanting it and want to tested. still no ports to be
> > modified (except perhaps some buggy one)
> >
> > Now the patches are quite old (they won't apply cleanly) so I'm on updating
> > it again.
> >
> > Before rewriting it, I think it is a better idea to first discuss about it,
> > to improve it, see if there are interests, etc.
> >
> > So basically here is what is done and how it works.
> > the changes are only in the infrastructure not in ports themselves (except
> > that some will be able to benefit some cleanup)
> >
> > do-fake (with post and pre) replaces do-install (pre/post) it creates a
> > $WRKSRC/fakeroot where the binaries are copied by the ports (during the
> > do-install of the port)
> >
> > then do-package create a package using pkg-plist (or the generated one)
> > using the binary in fakeroot.
> >
> > do-install (ie make install) now only does a pkg_add of the created pkg.
>
> This is exactly what we need and kudos to you for taking on this task. I
> fail to see however, how this can "just work" for all the ports. Most of
> them are configured with --prefix=/usr/local so you cannot simply run
> 'gmake install' for them and have stuff show up in the fake root.
>
> How is this actually solved (the proposed patch did not enlighten me in
> that regard).
>
> Regards,
> Uli
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: boost-python-libs and associated compile errors
On Wednesday 26 August 2009 16:07:56 David Southwell wrote: > I have just completed > # portupgrade -fRra > following a system upgrade from freebsd 7.2 p2 to p3 > > after a few minor hiccuups and recompiling ssome of the ports I am left > with four failing ports. As at least three of them seem to share some > common features. If anyone would be willing to help me out here it would be > most appreciated. > The failure list is: > > ! science/openbabel (openbabel-2.2.1) (unknown build error) > * misc/kdeedu4 (kdeedu-4.2.4) > ! graphics/blender (blender-2.49a_1)(unknown build error) > ! deskutils/kdeplasma-addons (kdeplasma-addons-4.2.4_1) (missing header) > > The errors reports are shown below in the same order. > The common features are: > problems with compiling boost-python-libs > threading issues > > ## > ! science/openbabel (openbabel-2.2.1) (unknown build error) > ## > > In file included from /usr/include/c++/4.2/bits/gthr.h:114, > from /usr/include/c++/4.2/bits/c++io.h:43, > from /usr/include/c++/4.2/iosfwd:46, > from /usr/include/c++/4.2/ios:43, > from /usr/include/c++/4.2/ostream:45, > from /usr/include/c++/4.2/iterator:70, > from ./boost/iterator.hpp:17, > from ./boost/operators.hpp:81, > from ./boost/python/type_id.hpp:11, > from ./boost/python/converter/registrations.hpp:10, > from libs/python/src/object/function_doc_signature.cpp:6: > /usr/include/c++/4.2/bits/gthr-default.h: In function 'int > __gthread_active_p()': > /usr/include/c++/4.2/bits/gthr-default.h:174: error: conversion from 'int' > to non-scalar type 'pthread_once' requested > ...failed gcc.compile.c++ bin.v2/libs/python/build/gcc-4.2.1/release/link- > static/threading-multi/object/function_doc_signature.o... > ...skipped > multi>libboost_python.a(clean) for lack of > multi>numeric.o... > ...skipped > multi>libboost_python.a for lack of > multi>numeric.o... > ...skipped libboost_python.a for lack of > multi>libboost_python.a... > ...failed updating 54 targets... > ...skipped 5 targets... > ...updated 17 targets... > *** Error code 1 > > Stop in /usr/ports/devel/boost-python-libs. > *** Error code 1 > > Stop in /usr/ports/devel/boost-python-libs. > *** Error code 1 > > Stop in /usr/ports/science/openbabel. > ** Command failed [exit code 1]: /usr/bin/script -qa > /tmp/portupgrade20090826-26960-1q590yk-0 env UPGRADE_TOOL=portupgrade > UPGRADE_PORT=openbabel-2.2.1 UPGRADE_PORT_VER=2.2.1 make > ** Fix the problem and try again. > ## > * misc/kdeedu4 (kdeedu-4.2.4) > ## > > In file included from /usr/include/c++/4.2/bits/gthr-default.h:43, > from /usr/include/c++/4.2/bits/gthr.h:114, > from /usr/include/c++/4.2/bits/c++io.h:43, > from /usr/include/c++/4.2/iosfwd:46, > from /usr/include/c++/4.2/ios:43, > from /usr/include/c++/4.2/ostream:45, > from /usr/include/c++/4.2/iterator:70, > from ./boost/iterator.hpp:17, > from ./boost/operators.hpp:81, > from ./boost/python/type_id.hpp:11, > from ./boost/python/converter/registrations.hpp:10, > from libs/python/src/object/function_doc_signature.cpp:6: > /usr/local/include/python2.6/pthread.h:285: error: conflicting declaration > 'typedef struct pthread_st* pthread_t' ^^ David, I really think that your previous escapade with pth+python has screwed up boost-python. Did you recompile boost after removing pth from python? Because, pth/pthread.h: 282 /* 283* Primitive system data type definitions required by P1003.1c 284*/ 285 typedef struct pthread_st *pthread_t; ^^ -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Dropping maintainership for multimedia/handbrake
Hi, On Wednesday 26 August 2009 19:41:03 Jonathan wrote: > I was hoping to fix the handbrake port and get it working properly over > the summer but it didn't happen and now I'm in school full time. I > don't have time to work on the port anymore and I don't want people to > not try and update it because someone else is already maintaining it. > > If someone wants to take over this port let the list know and a ports > committer will likely go ahead and assign it to you. Is this one of the problems you refer to? kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical unit region Followed by: kernel: (cd0:ata1:0:0:0): Retries Exhausted kernel: ata1: FAILURE - non aligned DMA transfer attempted kernel: unknown: setting up DMA failed handbrake becomes unkillable, machine can only be rebooted by power cycle. I'm interested in this port cause I'm looking for a solid alternative for the fragile multimedia/transcode. If this is one of the problems you're seeing and not something local to my test machine, I'll see what I can do and follow up through PR's. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: boost-python-libs and associated compile errors
> On Wednesday 26 August 2009 16:07:56 David Southwell wrote: > > I have just completed > > # portupgrade -fRra > > following a system upgrade from freebsd 7.2 p2 to p3 > > > > after a few minor hiccuups and recompiling ssome of the ports I am left > > with four failing ports. As at least three of them seem to share some > > common features. If anyone would be willing to help me out here it would > > be most appreciated. > > The failure list is: > > > > ! science/openbabel (openbabel-2.2.1) (unknown build error) > > * misc/kdeedu4 (kdeedu-4.2.4) > > ! graphics/blender (blender-2.49a_1)(unknown build error) > > ! deskutils/kdeplasma-addons (kdeplasma-addons-4.2.4_1) (missing header) > > > > The errors reports are shown below in the same order. > > The common features are: > > problems with compiling boost-python-libs > > threading issues > > > > ## > > ! science/openbabel (openbabel-2.2.1) (unknown build error) > > ## > > > > In file included from /usr/include/c++/4.2/bits/gthr.h:114, > > from /usr/include/c++/4.2/bits/c++io.h:43, > > from /usr/include/c++/4.2/iosfwd:46, > > from /usr/include/c++/4.2/ios:43, > > from /usr/include/c++/4.2/ostream:45, > > from /usr/include/c++/4.2/iterator:70, > > from ./boost/iterator.hpp:17, > > from ./boost/operators.hpp:81, > > from ./boost/python/type_id.hpp:11, > > from ./boost/python/converter/registrations.hpp:10, > > from > > libs/python/src/object/function_doc_signature.cpp:6: > > /usr/include/c++/4.2/bits/gthr-default.h: In function 'int > > __gthread_active_p()': > > /usr/include/c++/4.2/bits/gthr-default.h:174: error: conversion from > > 'int' to non-scalar type 'pthread_once' requested > > ...failed gcc.compile.c++ > > bin.v2/libs/python/build/gcc-4.2.1/release/link- > > static/threading-multi/object/function_doc_signature.o... > > ...skipped > > > multi>libboost_python.a(clean) for lack of > > > multi>numeric.o... > > ...skipped > > > multi>libboost_python.a for lack of > > > multi>numeric.o... > > ...skipped libboost_python.a for lack of > > > multi>libboost_python.a... > > ...failed updating 54 targets... > > ...skipped 5 targets... > > ...updated 17 targets... > > *** Error code 1 > > > > Stop in /usr/ports/devel/boost-python-libs. > > *** Error code 1 > > > > Stop in /usr/ports/devel/boost-python-libs. > > *** Error code 1 > > > > Stop in /usr/ports/science/openbabel. > > ** Command failed [exit code 1]: /usr/bin/script -qa > > /tmp/portupgrade20090826-26960-1q590yk-0 env UPGRADE_TOOL=portupgrade > > UPGRADE_PORT=openbabel-2.2.1 UPGRADE_PORT_VER=2.2.1 make > > ** Fix the problem and try again. > > ## > > * misc/kdeedu4 (kdeedu-4.2.4) > > ## > > > > In file included from /usr/include/c++/4.2/bits/gthr-default.h:43, > > from /usr/include/c++/4.2/bits/gthr.h:114, > > from /usr/include/c++/4.2/bits/c++io.h:43, > > from /usr/include/c++/4.2/iosfwd:46, > > from /usr/include/c++/4.2/ios:43, > > from /usr/include/c++/4.2/ostream:45, > > from /usr/include/c++/4.2/iterator:70, > > from ./boost/iterator.hpp:17, > > from ./boost/operators.hpp:81, > > from ./boost/python/type_id.hpp:11, > > from ./boost/python/converter/registrations.hpp:10, > > from > > libs/python/src/object/function_doc_signature.cpp:6: > > /usr/local/include/python2.6/pthread.h:285: error: conflicting > > declaration 'typedef struct pthread_st* pthread_t' > > ^^ > > David, I really think that your previous escapade with pth+python has > screwed up boost-python. Did you recompile boost after removing pth from > python? Because, pth/pthread.h: >282 /* >283* Primitive system data type definitions required by P1003.1c >284*/ >285 typedef struct pthread_st *pthread_t; > ^^ After the last escapade I did a complete system rebuild and a total rebuild of all ports including python. But let us assume the worst. How would you suggest I do a complete rebuild of the relevant dependencies? I have already tried portupgrade -rRfa but still have the problem. david ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: libical config error Cannot find Python.h
> On Wednesday 26 August 2009 10:02:50 David Southwell wrote: > > Thanks Greg -- as usual your are right on the button. I have done as you > > suggested and disabled the GNU Pth which I would have prefered to have > > but can get round for a while. > > Just curious, but why do you prefer a userland threads wrapper over 1:1 > kernel threads when the application doesn't require it? There is an application that needs it -- cant remember which right now and I am away from my desk-- it may be babel or keedu David ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Script "configure" failed unexpectedly
Hello, while trying: /usr/ports/graphics/xsane -> make -DFORCE_PKG_REGISTER install clean I got: updating cache ./config.cache ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist Try `ltconfig --help' for more information. configure: error: libtool configure failed ===> Script "configure" failed unexpectedly. Please report the problem to po...@freebsd.org [maintainer] and attach the "/usr/ports/graphics/aalib/work/aalib-1.4.0/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). Attached you find the asked File. # uname -a FreeBSD lotk1 7.2-STABLE FreeBSD 7.2-STABLE #6: Wed Jun 24 18:53:33 EDT 2009 r...@build7x64.pcbsd.org:/usr/obj/pcbsd-build72/cvs/7.2-src/sys/PCBSD amd64 Thanks in advance for any help! Best regards Stephan # ls /var/db/pkg ORBit2-2.14.17 gamin-0.1.10_2 libXrandr-1.3.0 p5-Digest-SHA1-2.12 OpenEXR-1.6.1_1 gcc-4.3.4_20090517 libXrender-0.9.4_1 p5-XML-Parser-2.36_1 acroreadwrapper-0.0.20090328gconf2-2.26.1_1 libXt-1.0.5_1 p5-gettext-1.05_2 arts-1.5.10_1,1 gdbm-1.8.3_3 libXtst-1.0.3_1 pango-1.24.2 asciidoc-8.4.5_1getopt-1.1.4_1 libXxf86vm-1.0.2pciids-20090224 aspell-0.60.6_2 gettext-0.17_1 liba52-0.7.4_2 pcre-7.9 atk-1.26.0 ghostscript8-8.64_2 libart_lgpl-2.3.20,1perl-5.8.9_2 autoconf-2.62 gio-fam-backend-2.20.1 libaudiofile-0.2.6 pixman-0.15.2 autoconf-wrapper-20071109 glib-2.20.1 libbonobo-2.24.1pkg-config-0.23_1 automake-1.10.1 gmake-3.81_3 libbonoboui-2.24.1 pkgdb.db automake-1.9.6_3gnome-doc-utils-0.16.1 libcddb-1.3.0 png-1.2.35 automake-wrapper-20071109 gnome-icon-theme-2.26.0_1 libcdio-0.78.2_2policykit-0.9_4 avahi-app-0.6.25_1 gnome-keyring-2.26.1_1 libcheck-0.9.6 policykit-gnome-0.9.2 bash-4.0.17 gnome-mime-data-2.18.0_3 libdaemon-0.12 poppler-0.10.6 bigreqsproto-1.0.2 gnome-mount-0.8_2 libdnet-1.11_3 poppler-data-0.2.1 bitstream-vera-1.10_4 gnome-vfs-2.24.1 libdrm-2.4.9poppler-qt-0.10.6 cairo-1.8.6_1,1 gnome_subr-1.0 libexif-0.6.17 popt-1.7_5 cdparanoia-3.9.8_8 gnomehier-2.3_12 libfontenc-1.0.4portaudio-18.1_2 celt-0.5.2 gnutls-2.6.5 libgcrypt-1.4.4 portmanager-0.4.1_9 compositeproto-0.4 gsfonts-8.11_4 libglade2-2.6.4 printproto-1.0.4 consolekit-0.3.0_8 gtk-2.16.1 libglut-7.4.2_1 py25-libxml2-2.7.3 cups-base-1.3.10_2 gvfs-1.2.2 libgmp-4.3.1python25-2.5.4_1 cups-client-1.3.10_2hal-0.5.11_23 libgnome-2.26.0 qt-3.3.8_9 cups-image-1.3.10_2 help2man-1.36.4_3 libgnomecanvas-2.26.0 qt4-corelib-4.4.3 damageproto-1.1.0_2 hicolor-icon-theme-0.10_2 libgnomeui-2.24.1 qt4-moc-4.4.3 dbus-1.2.4.6iceauth-1.0.2 libgpg-error-1.7qt4-qmake-4.4.3 dbus-glib-0.80 ilmbase-1.0.1_1 libgphoto2-2.4.5qt4-rcc-4.4.3 desktop-file-utils-0.15_1 inputproto-1.5.0 libiconv-1.11_1 qt4-uic-4.4.3 dev86-0.16.17 intltool-0.40.6 libidn-1.13 randrproto-1.3.0 djbfft-0.76_2 iso-codes-3.10.1 libltdl-1.5.26 rarian-0.8.1 dmidecode-2.10 iso8879-1986_2 libmad-0.15.1b_2recordproto-1.13.2 docbook-1.4 jackit-0.116.2_2 libmng-1.0.10 renderproto-0.9.3 docbook-4.1_3 jasper-1.900.1_7 libnotify-0.4.5 rkhunter-1.3.4 docbook-4.2 javavmwrapper-2.3.2 libogg-1.1.3,4 ruby-1.8.7.160_4,1 docbook-4.3 jpeg-6b_7 libpaper-1.1.21_3 samba-libsmbclient-3.0.34_1 docbook-4.4_2 jpeg-7 libproxy-0.2.3 sane-backends-1.0.20_3 docbook-4.5_2 kBuild-0.1.5.p1_1 libpthread-stubs-0.1shared-mime-info-0.60_1 docbook-5.0_1 kbproto-1.0.3 libsamplerate-0.1.7_1 sqlite3-3.6.13 docbook-sk-4.1.2_4 kdegraphics-3.5.10_2 libsigsegv-2.5 startup-notification-0.10 docbook-xml-4.2_1 kdehier-1.0_11 libsndfile-1.0.19 t1lib-5.1.2_1,1 docbook-xml-4.3 kdelibs-3.5.10 libsoup-2.26.1 tiff-3.8.2_3 docbook-xml-4.4_1 lcms-1.1
Lighttpd: (mod_fastcgi.c.1742) connect failed: Connection refused on unix:/tmp/lighttpd-fastcgi-php.socket
I deleted accidentally /usr/local/lib on a server but I was able to reinstall most of the software we need manually. After installing php5, several php5-XXX add ons and lighttpd, I get the appended error. The configuration for lighttpd is stuck with the same as before the accident. spawn_fastcgi ist installed as well as other php5 stuff. I'm helpless, Does anyone have any idea what's going wrong? Box is running FreeBSD 8.0-BETA3/AMD64 with compiled world of today. Software has been taken from ports within the past two days, so it should be up to date. Regards, Oliver P.S. Please respond also to my eMail address, thank you very much. 2009-09-03 19:47:49: (mod_access.c.135) -- mod_access_uri_handler called 2009-09-03 19:47:49: (mod_fastcgi.c.3644) handling it in mod_fastcgi 2009-09-03 19:47:49: (mod_fastcgi.c.1742) connect failed: Connection refused on unix:/tmp/lighttpd-fastcgi-php.socket-7 2009-09-03 19:47:49: (mod_fastcgi.c.2943) backend died; we'll disable it for 5 seconds and send the request to another backend instead: reconnects: 0 load: 1 2009-09-03 19:47:49: (mod_fastcgi.c.2481) unexpected end-of-file (perhaps the fastcgi process died): pid: 20516 socket: unix:/tmp/lighttpd-fastcgi-php.socket-7 2009-09-03 19:47:49: (mod_fastcgi.c.3299) response not received, request sent: 1010 on socket: unix:/tmp/lighttpd-fastcgi-php.socket-7 for /refdb/index.php , closing connection 2009-09-03 19:47:49: (response.c.126) Response-Header: HTTP/1.1 500 Internal Server Error Content-Type: text/html Content-Length: 369 Date: Thu, 03 Sep 2009 17:47:49 GMT Server: Lighttpd ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Script "configure" failed unexpectedly
On Thu, Sep 03, 2009 at 07:23:40PM +0200, Stephan Sann wrote: > Hello, > > while trying: > /usr/ports/graphics/xsane -> make -DFORCE_PKG_REGISTER install clean > > I got: > > updating cache ./config.cache > ltconfig: `/usr/local/share/libtool/config/ltmain.sh' does not exist > Try `ltconfig --help' for more information. > configure: error: libtool configure failed > ===> Script "configure" failed unexpectedly. > Please report the problem to po...@freebsd.org [maintainer] and attach the > "/usr/ports/graphics/aalib/work/aalib-1.4.0/config.log" including the output > of the failure of your make command. Also, it might be a good idea to > provide > an overview of all packages installed on your system (e.g. an `ls > /var/db/pkg`). > > [snip] > > libtool-1.5.26 ushare-1.1a > ports/UPDATING 20090802 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: boost-python-libs and associated compile errors
On Thursday 03 September 2009 17:48:36 David Southwell wrote: > > On Wednesday 26 August 2009 16:07:56 David Southwell wrote: > > > I have just completed > > > # portupgrade -fRra > > > following a system upgrade from freebsd 7.2 p2 to p3 > > > > > > after a few minor hiccuups and recompiling ssome of the ports I am left > > > with four failing ports. As at least three of them seem to share some > > > common features. If anyone would be willing to help me out here it > > > would be most appreciated. > > > The failure list is: > > > > > > ! science/openbabel (openbabel-2.2.1) (unknown build error) > > > * misc/kdeedu4 (kdeedu-4.2.4) > > > ! graphics/blender (blender-2.49a_1)(unknown build error) > > > ! deskutils/kdeplasma-addons (kdeplasma-addons-4.2.4_1) (missing > > > header) > > > > > > The errors reports are shown below in the same order. > > > The common features are: > > > problems with compiling boost-python-libs > > > threading issues > > > > > > ## > > > ! science/openbabel (openbabel-2.2.1) (unknown build error) > > > ## > > > > > > In file included from /usr/include/c++/4.2/bits/gthr.h:114, > > > from /usr/include/c++/4.2/bits/c++io.h:43, > > > from /usr/include/c++/4.2/iosfwd:46, > > > from /usr/include/c++/4.2/ios:43, > > > from /usr/include/c++/4.2/ostream:45, > > > from /usr/include/c++/4.2/iterator:70, > > > from ./boost/iterator.hpp:17, > > > from ./boost/operators.hpp:81, > > > from ./boost/python/type_id.hpp:11, > > > from ./boost/python/converter/registrations.hpp:10, > > > from > > > libs/python/src/object/function_doc_signature.cpp:6: > > > /usr/include/c++/4.2/bits/gthr-default.h: In function 'int > > > __gthread_active_p()': > > > /usr/include/c++/4.2/bits/gthr-default.h:174: error: conversion from > > > 'int' to non-scalar type 'pthread_once' requested > > > ...failed gcc.compile.c++ > > > bin.v2/libs/python/build/gcc-4.2.1/release/link- > > > static/threading-multi/object/function_doc_signature.o... > > > ...skipped > > > > > multi>libboost_python.a(clean) for lack of > > > > > multi>numeric.o... > > > ...skipped > > > > > multi>libboost_python.a for lack of > > > > > multi>numeric.o... > > > ...skipped libboost_python.a for lack of > > > > > multi>libboost_python.a... > > > ...failed updating 54 targets... > > > ...skipped 5 targets... > > > ...updated 17 targets... > > > *** Error code 1 > > > > > > Stop in /usr/ports/devel/boost-python-libs. > > > *** Error code 1 > > > > > > Stop in /usr/ports/devel/boost-python-libs. > > > *** Error code 1 > > > > > > Stop in /usr/ports/science/openbabel. > > > ** Command failed [exit code 1]: /usr/bin/script -qa > > > /tmp/portupgrade20090826-26960-1q590yk-0 env UPGRADE_TOOL=portupgrade > > > UPGRADE_PORT=openbabel-2.2.1 UPGRADE_PORT_VER=2.2.1 make > > > ** Fix the problem and try again. > > > ## > > > * misc/kdeedu4 (kdeedu-4.2.4) > > > ## > > > > > > In file included from /usr/include/c++/4.2/bits/gthr-default.h:43, > > > from /usr/include/c++/4.2/bits/gthr.h:114, > > > from /usr/include/c++/4.2/bits/c++io.h:43, > > > from /usr/include/c++/4.2/iosfwd:46, > > > from /usr/include/c++/4.2/ios:43, > > > from /usr/include/c++/4.2/ostream:45, > > > from /usr/include/c++/4.2/iterator:70, > > > from ./boost/iterator.hpp:17, > > > from ./boost/operators.hpp:81, > > > from ./boost/python/type_id.hpp:11, > > > from ./boost/python/converter/registrations.hpp:10, > > > from > > > libs/python/src/object/function_doc_signature.cpp:6: > > > /usr/local/include/python2.6/pthread.h:285: error: conflicting > > > declaration 'typedef struct pthread_st* pthread_t' > > > > ^^ > > > > David, I really think that your previous escapade with pth+python has > > screwed up boost-python. Did you recompile boost after removing pth from > > python? Because, pth/pthread.h: > >282 /* > >283* Primitive system data type definitions required by P1003.1c > >284*/ > >285 typedef struct pthread_st *pthread_t; > > ^^ > > After the last escapade I did a complete system rebuild and a total rebuild > of all ports including python. > > But let us assume the worst. How would you suggest I do a complete rebuild > of the relevant dependencies? I have already tried portupgrade -rRfa but > still have the problem. I would pkg_delete pth-\*, then portmaster -rf /usr/ports/lang/python26, just in case pth is picked up automagically. Because this python2.6/pthread.h really shows pth constructs, rather then FreeBSD native threads. I would not use portupgrade, because I'm biased, because it may use locally presen
Re: port astro/boinc-setiathome-enhanced
Alexander Melnik schreef: On Sunday 30 August 2009, Rene Ladan wrote: I had a slightly different patch to detect awk (attached) which doesn't need the dependency on gawk. Could you try it? I sent it to the developers (boinc_...@ssl.berkeley.edu), but it got probably lost in their work pile. Thank you for your response. I tested this patch, everything works well. Thanks for testing, I will add it to the port if approved. It has been committed upstream in revesion 622 of seti_boinc. See ftp://rene-ladan.nl/pub/freebsd/patch-seti_boinc__autosetup I actually have to update the astropulse part (the new production version is 5.06). While doing so, I thought that it might be easier to split the setiathome and astropulse clients into seperate ports (although they keep sharing the /var/db/boinc/projects/setiathome.berkeley.edu/ directory). I have some work-in-progress regarding this, if you're interested I can send it to you. Also, users can select on their preferences page which applications to run (currently seti, astropulse 5.03, astropulse 5.05/5.06). What do you think? > Good news, but the new version astropulse able to work without the graphics? The seti part is, but the astropulse part is not (there are some weird dependencies, it builds alright but it won't run). I've asked for this on the developers list but didn't get much response, they really seem to like the graphics. Regards, Rene ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: portmaster is not always recursive
On Sunday 30 August 2009 19:07:24 Doug Barton wrote:
> Ok, I found the problem, but the bad news is that I don't know what the
> solution is going to be. I've cc'ed ale since what I'm seeing is weird
> behavior by the php5-mcrypt slave port.
>
> What portmaster does by default when looking for dependencies is to run
> 'make build-depends-list run-depends-list | sort -u' to get the list of
> things to check. I used to just do all-depends-list by default but users
> complained that it was creating problems by recursing so far down the
> tree.
>
> What I'm seeing in security/php5-mcrypt is that the union of
> {build|run}-depends-list is different if I run it in the slave port than
> if I run it in lang/php5 (after enabling the OPTION for apache):
>
> In the slave port:
> /usr/ports/devel/autoconf262
> /usr/ports/devel/libltdl22
> /usr/ports/lang/php5
> /usr/ports/security/libmcrypt
>
> In lang/php5:
> /usr/ports/devel/autoconf262
> /usr/ports/devel/pkg-config
> /usr/ports/textproc/libxml2
> /usr/ports/www/apache22
>
> That's why portmaster is not picking up the dependency on apache when
> updating php5-mcrypt.
Why should it matter? I didn't think portmaster stopped searching if a first
level dep does not need upgrading. The reason for not using all-depends-list
is that it duplicates efforts. F.e. all-depends-list on x11/xorg recurses down
to everything and then asking all-depends-list for x11/xorg-apps will have
been done already by x11/xorg, but make(1) will still recurse the list and you
can't filter it till you see it.
But when using {build|run}-depends-list, lang/php5 is seen from security/php5-
mcrypt, as such, portmaster should drill down to {build|run}-depends-list of
lang/php5 until ending at leaf nodes. In principle this will end up to be an
all-depends-list, but with faster performance.
--
Mel
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Dropping maintainership for multimedia/handbrake
On Thursday 03 September 2009 17:24:46 Mel Flynn wrote: > Hi, > > On Wednesday 26 August 2009 19:41:03 Jonathan wrote: > > I was hoping to fix the handbrake port and get it working properly over > > the summer but it didn't happen and now I'm in school full time. I > > don't have time to work on the port anymore and I don't want people to > > not try and update it because someone else is already maintaining it. > > > > If someone wants to take over this port let the list know and a ports > > committer will likely go ahead and assign it to you. > > Is this one of the problems you refer to? > kernel: (cd0:ata1:0:0:0): Media region code is mismatched to logical > unit region > Followed by: > kernel: (cd0:ata1:0:0:0): Retries Exhausted > kernel: ata1: FAILURE - non aligned DMA transfer attempted > kernel: unknown: setting up DMA failed K, this is something with FreeBSD and ata/dma, mplayer does the same. Until I find a DVD player that works, can't evaluate this port :/. Doesn't help to be with a US DVD player in Europe. -- Mel ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
