Re: csync2 broken, how to keep a few web servers in sync?

2009-09-03 Thread mitsuru
 Who interested in repair net/csync2 port, possibly for some amount of 
 financial gratitude ;-)
 I've made a patch and compiled it, though I've not tested if it works.

--
Mitsuru



diff -ruN csync2.org/Makefile csync2/Makefile
--- csync2.org/Makefile 2009-09-03 14:39:39.0 +0900
+++ csync2/Makefile 2009-09-03 14:40:09.0 +0900
@@ -24,12 +24,11 @@
 
 MAN1=  csync2.1
 
-BROKEN=does not compile with new gnuTLS
-
 GNU_CONFIGURE= yes
 CONFIGURE_ARGS=--sysconfdir=${PREFIX}/etc
 CONFIGURE_ENV= CPPFLAGS=-I${LOCALBASE}/include
 CONFIGURE_ENV+=LDFLAGS=-L${LOCALBASE}/lib
+CONFIGURE_ENV+=LIBGNUTLS_CONFIG=${LOCALBASE}/bin/pkg-config gnutls
 
 PLIST_FILES=   etc/csync2.cfg-dist \
sbin/csync2 \
diff -ruN csync2.org/files/patch-configure csync2/files/patch-configure
--- csync2.org/files/patch-configure1970-01-01 09:00:00.0 +0900
+++ csync2/files/patch-configure2009-09-03 14:23:51.0 +0900
@@ -0,0 +1,11 @@
+--- configure.org  2009-09-03 14:22:32.0 +0900
 configure  2009-09-03 14:23:02.0 +0900
+@@ -3836,7 +3836,7 @@
+   else
+ LIBGNUTLS_CFLAGS=`$LIBGNUTLS_CONFIG $libgnutls_config_args --cflags`
+ LIBGNUTLS_LIBS=`$LIBGNUTLS_CONFIG $libgnutls_config_args --libs`
+-libgnutls_config_version=`$LIBGNUTLS_CONFIG $libgnutls_config_args 
--version`
++libgnutls_config_version=`$LIBGNUTLS_CONFIG $libgnutls_config_args 
--modversion`
+ 
+ 
+   ac_save_CFLAGS=$CFLAGS


___
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

2009-09-03 Thread Matthias Apitz
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 g...@unixarea.de - 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

2009-09-03 Thread Martin Wilke
-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 g...@unixarea.de - 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

2009-09-03 Thread Matthias Apitz
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 g...@unixarea.de - 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)

2009-09-03 Thread Mel Flynn
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

2009-09-03 Thread Mel Flynn
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

2009-09-03 Thread Yarema

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

2009-09-03 Thread Alexander Churanov
[Repeating part of thread here to return to the mailing list]

2009/9/3 David Southwell da...@vizion2000.net:
  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

2009-09-03 Thread Wesley Shields
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

2009-09-03 Thread Baptiste Daroussin
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 u...@spoerlein.net

 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

2009-09-03 Thread Mel Flynn
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
 pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
 multilibboost_python.a(clean) for lack of
 pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
 multinumeric.o...
 ...skipped
 pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
 multilibboost_python.a for lack of
 pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
 multinumeric.o...
 ...skipped pstage/liblibboost_python.a for lack of
 pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
 multilibboost_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

2009-09-03 Thread Mel Flynn
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

2009-09-03 Thread David Southwell
 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
  pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
  multilibboost_python.a(clean) for lack of
  pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
  multinumeric.o...
  ...skipped
  pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
  multilibboost_python.a for lack of
  pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
  multinumeric.o...
  ...skipped pstage/liblibboost_python.a for lack of
  pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
  multilibboost_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

2009-09-03 Thread David Southwell
 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

2009-09-03 Thread Stephan Sann

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.18,1 

Lighttpd: (mod_fastcgi.c.1742) connect failed: Connection refused on unix:/tmp/lighttpd-fastcgi-php.socket

2009-09-03 Thread O. Hartmann
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

2009-09-03 Thread Alexey Shuvaev
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

2009-09-03 Thread Mel Flynn
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
   pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
   multilibboost_python.a(clean) for lack of
   pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
   multinumeric.o...
   ...skipped
   pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
   multilibboost_python.a for lack of
   pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
   multinumeric.o...
   ...skipped pstage/liblibboost_python.a for lack of
   pbin.v2/libs/python/build/gcc-4.2.1/release/link-static/threading-
   multilibboost_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 

Re: port astro/boinc-setiathome-enhanced

2009-09-03 Thread Rene Ladan

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

2009-09-03 Thread Mel Flynn
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

2009-09-03 Thread Mel Flynn
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