Re: ports/devel/protobuf: Segmentation fault in mmap in some applications

2010-01-07 Thread O. Hartmann

On 01/07/10 01:41, Pieter de Goeje wrote:

On Wednesday 06 January 2010 14:14:28 O. Hartmann wrote:

Dear Sirs,
We use a software package for scientific imagery processing from USGS,
ISIS3 (http://isis.astrogeology.usgs.gov/). The most recent version is
3.1.21 and since this version, the software intensively uses
libprotobuf.so.

While we can use ISIS 3.1.20 very well under FreeBSD 8.0/amd64, it is
impossible to use the software with version no. 3.1.21, which seems to
have some issues wih libprotobuf.so. Every client out of this ISIS3
package crashes with a segmentation fault and as far as I can judge the
situation, there is a problem with libprotobuf.so, against which all
clients out of ISIS 3.1.21 are linked.


Perhaps the ISIS package was developed using a different (older?) version of
Google's protocol buffers. Compiling protobuf from source is quite easy on
FreeBSD. You can find the source here:
http://code.google.com/p/protobuf/downloads/list
I would start by trying version 2.1.0 and 2.2.0a.



I searched for help on the ISIS3-support forum and realised that some
Apple OS X guys have had similar problems, but those threads where
closed immediately or got relative senseless response.

In our case, we compile every necessary library and prerequisite
software package (mostly Qt4 libs) from ports. This works great with
some tweaks for FreeBSD in make/config.freebsd (which I derived from
some linux and/or OS X config files).

Now I'm floating like a dead man i the water. Below I provide q gdb
output of the qview-client (the same is with all other clients, like
photrim etc. for those familiar with the software package).


A backtrace ('bt' at the gdb prompt) might contain more useful information.



Additionaly, I provide a truss-output, that stops at mmap issues.

Well, if someone could provide me with some advance debugging hints I
would appreaciate them. I'm pretty sure he problem is located within the
libprotobuf library or the way it is treated, but this is a guess of a
non-developer.

Thanks very much in advance.
Please reply also to this email address, since I'm not subscriber of the
list I post to.

Oliver


- Pieter



Hello Pieter,

ISIS3 utilises the very same revision of libprotobuf as FreeBSD has in 
the ports repositorium (libprotobuf.so.4.0.0, aka protobuf-2.2.0). The 
backtrace follows, it is a little bit lengthy ...



(gdb) bt
#0  0x000805a2f2c8 in std::_Rb_treestd::string, 
std::pairstd::string const, std::pairvoid const*, int , 
std::_Select1ststd::pairstd:: tring const, std::pairvoid const*, int 
 , std::lessstd::string, std::allocatorstd::pairstd::string 
const, std::pairvoid const*, int::_M_insert_unique () from 
/usr/local/lib/libprotobuf.so.4
#1  0x000805a326c6 in 
google::protobuf::InsertIfNotPresentstd::mapstd::string, 
std::pairvoid const*, int, std::lessstd::string, std::a 
locatorstd::pairstd::string const, std::pairvoid const*, int   , 
std::string, std::pairvoid const*, int  ()

   from /usr/local/lib/libprotobuf.so.4
#2  0x000805a32d4f in 
google::protobuf::SimpleDescriptorDatabase::DescriptorIndexstd::pairvoid 
const*, int ::AddFile ()

   from /usr/local/lib/libprotobuf.so.4
#3  0x000805a2df86 in 
google::protobuf::EncodedDescriptorDatabase::Add () from 
/usr/local/lib/libprotobuf.so.4
#4  0x0008059ed8fd in 
google::protobuf::DescriptorPool::InternalAddGeneratedFile () from 
/usr/local/lib/libprotobuf.so.4
#5  0x000805a16218 in 
google::protobuf::protobuf_AddDesc_google_2fprotobuf_2fdescriptor_2eproto () 
from /usr/local/lib/libprotobuf.so.4
#6  0x000805a168a5 in __static_initialization_and_destruction_0 () 
from /usr/local/lib/libprotobuf.so.4
#7  0x000805a64aab in __do_global_ctors_aux () from 
/usr/local/lib/libprotobuf.so.4

#8  0x0008059d00f6 in _init () from /usr/local/lib/libprotobuf.so.4
#9  0x00080064bc70 in ?? () from /libexec/ld-elf.so.1
#10 0x00080052582b in dlsym () from /libexec/ld-elf.so.1
#11 0x000800526b85 in dlopen () from /libexec/ld-elf.so.1
#12 0x0008005217a9 in ?? () from /libexec/ld-elf.so.1
#13 0x in ?? ()
#14 0x in ?? ()
#15 0x in ?? ()
#16 0x in ?? ()
#17 0x0001 in ?? ()
#18 0x7fffe800 in ?? ()
#19 0x in ?? ()
#20 0x7fffe806 in ?? ()
#21 0x7fffe822 in ?? ()
#22 0x7fffe847 in ?? ()
#23 0x7fffe852 in ?? ()
#24 0x7fffe86c in ?? ()
#25 0x7fffe879 in ?? ()
#26 0x7fffe899 in ?? ()
#27 0x7fffe8c7 in ?? ()
#28 0x7fffe8d9 in ?? ()
#29 0x7fffe8f0 in ?? ()
#30 0x7fffe907 in ?? ()
#31 0x7fffe927 in ?? ()
#32 0x7fffe936 in ?? ()
#33 0x7fffe943 in ?? ()
#34 0x7fffe95d in ?? ()
#35 0x7fffec8e in ?? ()
#36 0x7fffecb1 in ?? ()
#37 0x7fffecbc in ?? ()
#38 0x7fffecd1 in ?? ()
#39 0x7fffed99 in ?? ()
#40 0x7fffedb2 in ?? ()
#41 0x7fffedce 

updates to pending new ports

2010-01-07 Thread Klaus T. Aehlig

Hi,

Recently, I submitted PR ports/141674 suggesting a port for the uzbl
web browser. Given the current holiday season, I'm not surprised that
it is still unassigned. On the other hand, upstream has developped
further, and I wonder if I'm right in submitting updated versions of
this port as followups to the PR. (My thoughts went along the lines 
If it's still unassigned, then probably no committer has spent any 
time on it; so when it gets assigned to a commiter, (s)he might as well
look at a port for the latest version.) Or should I consider the
fact that the PR is unassigned as a sign that this port is
probably not interesting for FreeBSD?

[Since I'm using that browser on my private machine, I'm updating
the port anyway, so it's no extra work for me to submit follow
ups. I'm just wondering whether this is what I'm supposed to do,
or just considered annoying.]

Best regards and happy new year!

Klaus

___
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: updates to pending new ports

2010-01-07 Thread Matthew Seaman

Klaus T. Aehlig wrote:

Hi,

Recently, I submitted PR ports/141674 suggesting a port for the uzbl
web browser. Given the current holiday season, I'm not surprised that
it is still unassigned. On the other hand, upstream has developped
further, and I wonder if I'm right in submitting updated versions of
this port as followups to the PR. (My thoughts went along the lines 
If it's still unassigned, then probably no committer has spent any 
time on it; so when it gets assigned to a commiter, (s)he might as well

look at a port for the latest version.) Or should I consider the
fact that the PR is unassigned as a sign that this port is
probably not interesting for FreeBSD?

[Since I'm using that browser on my private machine, I'm updating
the port anyway, so it's no extra work for me to submit follow
ups. I'm just wondering whether this is what I'm supposed to do,
or just considered annoying.]


It's certainly better to submit updates by following up on an already open
ticket, rather than creating a whole raft of new tickets.

Updating your port before it is committed does indicate a certain degree of 
commitment to keeping the port up to date, which is a good thing.


You can't really assume anything about the status of your submission if it
is still unassigned.  All that really means is that no one has yet taken
responsibility for checking and committing it.  If there were any questions
as to whether the port should be added to the tree at all, then they would be
coming to you from the committer that had assigned the PR to themselves.  If
your new port has been languishing unassigned for a long time (I'd say a few
weeks at least), it's legitimate to ask about its status on this list -- as
you say, submitting the port during the holiday season may well have slipped
it under the radar of anyone that might work on it.

Cheers,

Matthew

--
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
 Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
 Kent, CT11 9PW



signature.asc
Description: OpenPGP digital signature


FreeBSD Port: openerp-server-5.0.6_1

2010-01-07 Thread Jean-Yves Boisiaud - Osiell

Hello,

Here is a rc.d script to start/stop/restart the OpenERP server.

openerp-server default configuration file (-c option) should give the 
same PID file that the rc script :


pidfile = /var/run/openerp/server.pid

The installation script should create a user with no password used to 
run the OpenERP server. Here, I used terp.



#!/bin/sh

#
# PROVIDE: openerp_server
# REQUIRE: postgresql
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable OpenERP server:
#
#  openerp_server_enable=YES
#  # optional
#  openerp_server_flags=-c /usr/local/etc/openerp-server.conf
#  openerp_server_user=terp
#
# Do not forget to define the same PID file in the OpenERP configuration
# file (see the variable $pidfile defined below).
#
# This scripts takes one of the following commands:
#
#   start stop restart status
#

: ${openerp_server_enable=NO}
: ${openerp_server_flags=-c /usr/local/etc/openerp-server.conf}
: ${openerp_server_user=terp}

. /etc/rc.subr

name=openerp_server
rcvar=${name}_enable
command_args= /dev/null 21 
pidfile=/var/run/openerp/server.pid
start_precmd=${name}_prestart
command=/usr/local/bin/openerp-server
procname=/usr/local/bin/python2.6

openerp_server_prestart() {
# PID file should be not empty.
[ x$pidfile = x ]  err 1 variable pidfile should not be empty

# Check PID directory exists.
d=$(dirname $pidfile)

if [ ! -d  $d ]; then
# Create PID directory.
mkdir -p $d || return 1
chmod 750 $d || return 1
chown ${openerp_server_user}:wheel $d || return 1
fi
}

load_rc_config $name

run_rc_command $1


___
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


open-vm-tools-nox11

2010-01-07 Thread Peter Czanik
Hello,
When building a package from open-vm-tools-nox11, I run into the
following problem:

===  Building package for open-vm-tools-nox11-210370_1
Creating package /usr/packages/All/open-vm-tools-nox11-210370_1.tbz
Registering depends: glib-2.22.3 gettext-0.17_1 libiconv-1.13.1
icu-3.8.1_2 pcre-8.00 pkg-config-0.23_1 perl-5.8.9_3 python26-2.6.4
libdnet-1.11_3.
Registering conflicts: open-vm-tools-[0-9]* vmware-guestd[0-9]*
vmware-tools[0-9]*.
Creating bzip'd tar ball in
'/usr/packages/All/open-vm-tools-nox11-210370_1.tbz'
tar: lib/open-vm-tools/plugins/vmsvc/libhgfsServer.so: Cannot stat: No
such file or directory
tar: lib/open-vm-tools/plugins/vmsvc/libvix.so: Cannot stat: No such
file or directory
tar: Error exit delayed from previous errors.
pkg_create: make_dist: tar command failed with code 256
*** Error code 1

Stop in /usr/ports/emulators/open-vm-tools-nox11.

Removing the two offending lines from pkg-plist allows to build the
package without errors.
Bye,
CzP
___
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


mplayer update

2010-01-07 Thread Iasen Kostov
Can You pleas update mplayer to something more recent, current version is
last updated '12 Dec 2007' which is more than 2 years ago and the last
update on their site is from '2009-11-01', There are a lot of new features
and fixes like VDPAU, .mkv seek and many many many more. I hate to have them
all on my windoze version and not on the FreeBSD one.

Best regards, Iasen.
___
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: mplayer update

2010-01-07 Thread Lars Engels
On Thu, Jan 07, 2010 at 12:33:17PM +0200, Iasen Kostov wrote:
 Can You pleas update mplayer to something more recent, current version is
 last updated '12 Dec 2007' which is more than 2 years ago and the last
 update on their site is from '2009-11-01', There are a lot of new features
 and fixes like VDPAU, .mkv seek and many many many more. I hate to have them
 all on my windoze version and not on the FreeBSD one.

There have been several discussions on this topics during the last
weeks. The port should be updated, soon.


pgpA76PgOQU3k.pgp
Description: PGP signature


freeradius-2.1.6 + perl-5.8.9_3 + perl hook problem

2010-01-07 Thread Nick Rogers
I started a thread discussing a similar problem a few days ago but I would
like to repost a more concise statement and a way to replicate easily.

There seems to be some kind of shared library linking issue between the
freeradius2 and perl packages compiled from RELEASE_8_0 ports tree branch.
If one tries to use freeradius in conjunction with a perl hook (script) for
authentication, and the perl script requires a perl module relying on a
compiled shared object file (e.g., IO), then freeradius will fail to load
the perl script and throws errors.

Below is a dump that should make it easy to replicate the problem. This was
done after freshly installing 8.0-RELEASE-i386 onto a system from the
official ISO.

Note that I have also tried to compile the ports myself and run into the
same problem on i386 and amd64 architectures. I am going to try and compile
the ports using portupgrade as suggested by someone on this list and see if
that changes anything. Any further help would be greatly appreciated.
Thanks!



# uname -a
FreeBSD  8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:48:17 UTC 2009
  r...@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  i386
#
# pkg_info
#
#
# pkg_add -r freeradius
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/Latest/freeradius.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/python26-2.6.2_3.tbz...
Done.


Note that some of the standard modules are provided as separate
ports since they require extra dependencies:

bsddb   databases/py-bsddb
gdbmdatabases/py-gdbm
sqlite3 databases/py-sqlite3
tkinter x11-toolkits/py-tkinter

Install them as needed.


Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/perl-5.8.9_3.tbz...
Done.
Removing stale symlinks from /usr/bin...
Skipping /usr/bin/perl
Skipping /usr/bin/perl5
Done.
Creating various symlinks in /usr/bin...
Symlinking /usr/local/bin/perl5.8.9 to /usr/bin/perl
Symlinking /usr/local/bin/perl5.8.9 to /usr/bin/perl5
Done.
Cleaning up /etc/make.conf... Done.
Spamming /etc/make.conf... Done.
Cleaning up /etc/manpath.config... Done.
Spamming /etc/manpath.config... Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/libltdl-2.2.6a.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/gdbm-1.8.3_3.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/libiconv-1.13.1.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/gettext-0.17_1.tbz...
Done.
Fetching
ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8.0-release/All/gmake-3.81_3.tbz...
Done.
=== Created group freeradius
=== Created user freeradius
=== Setting user and group in radiusd.conf
=== Bootstrapping default certificates, please wait...
=== Adjusting ownership of directory /usr/local/etc/raddb
=== Adjusting ownership of directory /var/log/radacct
=== Adjusting ownership of directory /var/run/radiusd
=== Adjusting ownership of /var/log/radius.log
=== Adjusting ownership of /var/log/radutmp
=== Adjusting ownership of /var/log/radwtmp
=== Updating libdir in /usr/local/etc/raddb/radiusd.conf

===

To enable FreeRADIUS, put the following line in /etc/rc.conf

radiusd_enable=YES


The sample configuration can be found at
/usr/local/share/examples/freeradius/raddb

If you are upgrading FreeRADIUS, you are advised to use this as a reference
for updating your configuration.


FreeRADIUS will look for its configuration directory at
/usr/local/etc/raddb by default.

If you did not already have a configuration at this location, the sample
configuration has been copied to this location and has been bootstrapped.


If you wish to point FreeRADIUS to a configuration at a different
location, put the following line in /etc/rc.conf

radiusd_flags=-d /path/to/raddb


To start the server in normal (daemon) mode, run:

/usr/local/etc/rc.d/radiusd start

and to stop the server, run:

/usr/local/etc/rc.d/radiusd stop


To start the server in debugging mode, run:

/usr/local/etc/rc.d/radiusd debug


You are advised to make cautious changes to the configuration, and to test
frequently, using debugging mode where necessary. Try to resist the
temptation to disable or delete things that you don't understand - you may
well break things!

The documentation has been installed at /usr/local/share/doc/freeradius

Useful configuration advice can be found in the FreeRADIUS Wiki at
http://wiki.freeradius.org

===


#
# pkg_info
en-freebsd-doc-20090913 Documentation from the FreeBSD Documentation Project
freeradius-2.1.6A free RADIUS server implementation
gdbm-1.8.3_3The GNU database manager
gettext-0.17_1  GNU gettext package
gmake-3.81_3GNU 

Re: Binary packages for releases and portupgrade

2010-01-07 Thread Peter Ulrich Kruppa
Am Mittwoch, den 06.01.2010, 16:24 -0500 schrieb Martin Cracauer:
 Peter Ulrich Kruppa wrote on Wed, Jan 06, 2010 at 09:43:21PM +0100: 
  On Wed, 6 Jan 2010, Martin Cracauer wrote:
  

 If there is a serious question WRT it does run in the Linux emulator
 that would be easy enough to test, I can just NFS-mount one of my
 diskless Debians.
 
  Today I started an experiment: I created a jail as a clean 
  build enviroment for OOo. Yet it has installed 145 dependencies 
  and not even started building OOo.
And that worked (building in a jail I mean).
- Just for the records.

Uli.


 
 I expected nothing less.
 
 The Java requirement is particularly annoying on FreeBSD.  And all
 that do get a Powerpoint clone with drunker mouse pointer syndrome
 written in tcl...
 
 Martin

___
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


Request for a new port review iplike 1.0.8

2010-01-07 Thread Sevan / Venture37

Hi Guys
I've written a new port for iplike, which is a C implementation of the 
OpenNMS iplike stored procedure, I'm happy with the port  I intend to 
raise a PR by the weekend but I'd like a few more people to test it out 
before I do that.

If you're an OpenNMS user you can grab the iplike port from here:
http://www.geeklan.co.uk/files/iplike/iplike-108-freebsd-port.tgz
If you don't currently have OpenNMS running, you can grab a copy of the 
port from here:

http://www.geeklan.co.uk/files/opennms/opennms-168-freebsd-port.tgz
The OpenNMS port is a work in progress, see 
http://www.geeklan.co.uk/?p=132 for status updates.




Sevan / Venture37
___
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: ports/devel/protobuf: Segmentation fault in mmap in some applications

2010-01-07 Thread Pieter de Goeje
On Thursday 07 January 2010 10:02:36 O. Hartmann wrote:
 On 01/07/10 01:41, Pieter de Goeje wrote:
  On Wednesday 06 January 2010 14:14:28 O. Hartmann wrote:
  Dear Sirs,
  We use a software package for scientific imagery processing from USGS,
  ISIS3 (http://isis.astrogeology.usgs.gov/). The most recent version is
  3.1.21 and since this version, the software intensively uses
  libprotobuf.so.
 
  While we can use ISIS 3.1.20 very well under FreeBSD 8.0/amd64, it is
  impossible to use the software with version no. 3.1.21, which seems to
  have some issues wih libprotobuf.so. Every client out of this ISIS3
  package crashes with a segmentation fault and as far as I can judge the
  situation, there is a problem with libprotobuf.so, against which all
  clients out of ISIS 3.1.21 are linked.
 
  Perhaps the ISIS package was developed using a different (older?) version
  of Google's protocol buffers. Compiling protobuf from source is quite
  easy on FreeBSD. You can find the source here:
  http://code.google.com/p/protobuf/downloads/list
  I would start by trying version 2.1.0 and 2.2.0a.
 
  I searched for help on the ISIS3-support forum and realised that some
  Apple OS X guys have had similar problems, but those threads where
  closed immediately or got relative senseless response.
 
  In our case, we compile every necessary library and prerequisite
  software package (mostly Qt4 libs) from ports. This works great with
  some tweaks for FreeBSD in make/config.freebsd (which I derived from
  some linux and/or OS X config files).
 
  Now I'm floating like a dead man i the water. Below I provide q gdb
  output of the qview-client (the same is with all other clients, like
  photrim etc. for those familiar with the software package).
 
  A backtrace ('bt' at the gdb prompt) might contain more useful
  information.
 
  Additionaly, I provide a truss-output, that stops at mmap issues.
 
  Well, if someone could provide me with some advance debugging hints I
  would appreaciate them. I'm pretty sure he problem is located within the
  libprotobuf library or the way it is treated, but this is a guess of a
  non-developer.
 
  Thanks very much in advance.
  Please reply also to this email address, since I'm not subscriber of the
  list I post to.
 
  Oliver
 
  - Pieter

 Hello Pieter,

 ISIS3 utilises the very same revision of libprotobuf as FreeBSD has in
 the ports repositorium (libprotobuf.so.4.0.0, aka protobuf-2.2.0). The
 backtrace follows, it is a little bit lengthy ...

Ok, I can reproduce this locally. The cause is incorrect compiler flags. 
Basically one must use `pkg-config --cflags protobuf` to get the correct 
CFLAGS and `pkg-config --libs protobuf` for the correct libraries.

Most likely one or both of the following were missing during the 
compilation/linking of ISIS: -D_THREAD_SAFE -pthread

Regards,

Pieter
___
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: Binary packages for releases and portupgrade

2010-01-07 Thread Dominic Fandrey
Lars Engels wrote:
 On Wed, Jan 06, 2010 at 08:46:38PM +0100, Peter Ulrich Kruppa wrote:
 On Wed, 6 Jan 2010, Martin Cracauer wrote:
 So the verdict is to hunt down OpenOffice packages manually and
 install them so that portupgrade ignores them, then go from there.

 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/
 seems to have what `portupgrade -P` should expect, right?

 So I wouldn't have to move from stable to release+sec.
 I wonder if people who succeed in building OOo (happens about 
 twice a year to me) could put their packages on some kind of ftp 
 server. From their mailing list I get the impression OOo-porting 
 team could need all kind of help.
 
 There are already some builds (english and german) at
 http://wiki.bsdforen.de/anwendungen/openoffice_aus_inoffiziellen_paketen
 
 They're updated on a unregularly basis.

That means you sometimes have to wait for a whole week after the
port has been updated. ;)

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
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: mplayer update

2010-01-07 Thread Thomas Zander
On Thu, Jan 7, 2010 at 14:12, Lars Engels lars.eng...@0x20.net wrote:

 There have been several discussions on this topics during the last
 weeks. The port should be updated, soon.

Correct. I am on it.
I'll post a call for testing to this list as soon as my
work-in-progress version sucks less :-)

Riggs
___
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: Binary packages for releases and portupgrade

2010-01-07 Thread Dominic Fandrey
Lars Engels wrote:
 On Wed, Jan 06, 2010 at 08:46:38PM +0100, Peter Ulrich Kruppa wrote:
 On Wed, 6 Jan 2010, Martin Cracauer wrote:
 So the verdict is to hunt down OpenOffice packages manually and
 install them so that portupgrade ignores them, then go from there.

 ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-stable/
 seems to have what `portupgrade -P` should expect, right?

 So I wouldn't have to move from stable to release+sec.
 I wonder if people who succeed in building OOo (happens about 
 twice a year to me) could put their packages on some kind of ftp 
 server. From their mailing list I get the impression OOo-porting 
 team could need all kind of help.
 
 There are already some builds (english and german) at
 http://wiki.bsdforen.de/anwendungen/openoffice_aus_inoffiziellen_paketen

Actually there are more packages on the FTP than the ones listed
there. Some people don't update the wiki page after uploading a
new package.

-- 
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail? 
___
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


Call for testers - mplayer svn port

2010-01-07 Thread Thomas Zander
Hi,

thanks to Wes Morgan and Martin Wilke there is something for you to
test which approximates what's going to become our next mplayer in the
ports tree.

Due to the vast number of changes between the last official release of
mplayer and the current svn version and the significant changes we did
to the port, I am almost certain you will stumble upon regressions.
Furthermore, because of the large number of possible OPTIONS and
combinations thereof, it might or might not even build for you.
Over the next weeks I aim to stabilise the build process on different
configurations and reduce the regressions that users might encounter
when we finally commit this to the ports tree. I trust that you report
problems that you run into on the mailing list and - if possible -
please please send patches to me that solve a particular regression
for you.

To the topic: On
http://www.rrr.de/~riggs/mplayer/m20100107.tar.bz2
you can get a small tarball. It contains three items: The ports for
mplayer and mencoder. Both are drop-in replacements for the respective
directories in ${PORTSDIR}/multimedia
This should work without further changes (at least it does on my amd64
test machine). NOTE that ONLY if you want to test it with x264 (only
available for mencoder, mplayer uses ffmpeg's internal h264 decoder
now.), you HAVE to apply the supplied x264 patch to
${PORTSDIR}/multimedia/x264.

Thank you in advance and good luck
Riggs
___
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


Samba33 errors ?

2010-01-07 Thread David Southwell

Hi

Can anyone tell me what is happening here..

Thanks in advance for any clues

Following a portupgrade I am getting these (I have no idea whether this is 
directly connected with upgrades or just coincidental). 
Jan  7 22:23:14 dns1 smbd[3227]: [2010/01/07 22:23:14,  0] 
lib/util.c:reinit_after_fork(1054)
Jan  7 22:23:14 dns1 smbd[3227]:   tdb_reopen_all failed.
Jan  7 22:23:14 dns1 smbd[3227]: [2010/01/07 22:23:14,  0] 
smbd/server.c:open_sockets_smbd(773)
Jan  7 22:23:14 dns1 smbd[3227]:   reinit_after_fork() failed
Jan  7 22:23:14 dns1 smbd[3227]: [2010/01/07 22:23:14,  0] 
lib/util.c:smb_panic(1673)
Jan  7 22:23:14 dns1 smbd[3227]:   PANIC (pid 3227): reinit_after_fork() 
failed
Jan  7 22:23:14 dns1 smbd[3227]: [2010/01/07 22:23:14,  0] 
lib/util.c:log_stack_trace(1777)
Jan  7 22:23:14 dns1 smbd[3227]:   BACKTRACE: 0 stack frames:
Jan  7 22:23:14 dns1 smbd[3227]: [2010/01/07 22:23:14,  0] 
lib/fault.c:dump_core(231)
Jan  7 22:23:14 dns1 smbd[3227]:   dumping core in /var/log/samba/cores/smbd

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: mail/py-spambayes and Python 2.6 update

2010-01-07 Thread Torfinn Ingolfsen
Hello,

something is up with the spambayes port again.

I've recently upgraded my main workstation to FreeBSD 8.0-stable:
ti...@kg-v2$ uname -a
FreeBSD kg-v2.kg4.no 8.0-STABLE FreeBSD 8.0-STABLE #1: Wed Jan  6 21:21:40
CET 2010 r...@kg-v2.kg4.no:/usr/obj/usr/src/sys/GENERIC  amd64

I have python 2.6 installed (and only that):
ti...@kg-v2$ portversion -v | grep python
python26-2.6.4  =  up-to-date with port

I change to the spambayes directory, and try to install it (I select
python26 in the options dialog):
make
cd /usr/ports/mail/py-spambayes  make config;
===  py25-spambayes-1.0.4_4 needs Python 2.6 at least. But you specified
2.5.
*** Error code 1

Stop in /usr/ports/mail/py-spambayes.
*** Error code 1

Stop in /usr/ports/mail/py-spambayes.

That fails. However, when I try to run 'make' again, it works:
r...@kg-v2# make
===  Vulnerability check disabled, database not found
===  Found saved configuration for py25-spambayes-1.0.4_4
===  Extracting for py26-spambayes-1.0.4_4
= MD5 Checksum OK for spambayes-1.0.4.tar.gz.
= SHA256 Checksum OK for spambayes-1.0.4.tar.gz.
===  Patching for py26-spambayes-1.0.4_4
===  Applying extra patch
/usr/ports/mail/py-spambayes/files/extra-patch-python26
===  Applying FreeBSD patches for py26-spambayes-1.0.4_4
===   py26-spambayes-1.0.4_4 depends on file: /usr/local/bin/python2.6 -
found
===  Configuring for py26-spambayes-1.0.4_4
running config
===  Building for py26-spambayes-1.0.4_4
running build
running build_py
creating build
creating build/lib
creating build/lib/spambayes
copying spambayes/cdb.py - build/lib/spambayes
copying spambayes/cdb_classifier.py - build/lib/spambayes
copying spambayes/chi2.py - build/lib/spambayes
copying spambayes/classifier.py - build/lib/spambayes
copying spambayes/compatcsv.py - build/lib/spambayes
copying spambayes/compatheapq.py - build/lib/spambayes
copying spambayes/compatsets.py - build/lib/spambayes
copying spambayes/Corpus.py - build/lib/spambayes
copying spambayes/CostCounter.py - build/lib/spambayes
copying spambayes/dbmstorage.py - build/lib/spambayes
copying spambayes/Dibbler.py - build/lib/spambayes
copying spambayes/FileCorpus.py - build/lib/spambayes
copying spambayes/hammie.py - build/lib/spambayes
copying spambayes/hammiebulk.py - build/lib/spambayes
copying spambayes/Histogram.py - build/lib/spambayes
copying spambayes/ImapUI.py - build/lib/spambayes
copying spambayes/mboxutils.py - build/lib/spambayes
copying spambayes/message.py - build/lib/spambayes
copying spambayes/msgs.py - build/lib/spambayes
copying spambayes/oe_mailbox.py - build/lib/spambayes
copying spambayes/optimize.py - build/lib/spambayes
copying spambayes/Options.py - build/lib/spambayes
copying spambayes/OptionsClass.py - build/lib/spambayes
copying spambayes/ProxyUI.py - build/lib/spambayes
copying spambayes/PyMeldLite.py - build/lib/spambayes
copying spambayes/ServerUI.py - build/lib/spambayes
copying spambayes/smtpproxy.py - build/lib/spambayes
copying spambayes/Stats.py - build/lib/spambayes
copying spambayes/storage.py - build/lib/spambayes
copying spambayes/TestDriver.py - build/lib/spambayes
copying spambayes/Tester.py - build/lib/spambayes
copying spambayes/TestToolsUI.py - build/lib/spambayes
copying spambayes/tokenizer.py - build/lib/spambayes
copying spambayes/UserInterface.py - build/lib/spambayes
copying spambayes/Version.py - build/lib/spambayes
copying spambayes/__init__.py - build/lib/spambayes
creating build/lib/spambayes/resources
copying spambayes/resources/classify_gif.py - build/lib/spambayes/resources
copying spambayes/resources/config_gif.py - build/lib/spambayes/resources
copying spambayes/resources/helmet_gif.py - build/lib/spambayes/resources
copying spambayes/resources/help_gif.py - build/lib/spambayes/resources
copying spambayes/resources/message_gif.py - build/lib/spambayes/resources
copying spambayes/resources/query_gif.py - build/lib/spambayes/resources
copying spambayes/resources/scanning__init__.py -
build/lib/spambayes/resources
copying spambayes/resources/status_gif.py - build/lib/spambayes/resources
copying spambayes/resources/train_gif.py - build/lib/spambayes/resources
copying spambayes/resources/ui_html.py - build/lib/spambayes/resources
copying spambayes/resources/ui_psp.py - build/lib/spambayes/resources
copying spambayes/resources/__init__.py - build/lib/spambayes/resources
running build_scripts
creating build/scripts-2.6
copying and adjusting scripts/sb_client.py - build/scripts-2.6
copying and adjusting scripts/sb_dbexpimp.py - build/scripts-2.6
copying and adjusting scripts/sb_evoscore.py - build/scripts-2.6
copying and adjusting scripts/sb_filter.py - build/scripts-2.6
copying and adjusting scripts/sb_bnfilter.py - build/scripts-2.6
copying and adjusting scripts/sb_bnserver.py - build/scripts-2.6
copying and adjusting scripts/sb_imapfilter.py - build/scripts-2.6
copying and adjusting scripts/sb_mailsort.py - build/scripts-2.6
copying and adjusting scripts/sb_mboxtrain.py - build/scripts-2.6

GNAT and LAPACK

2010-01-07 Thread Gerald Pfeifer
 This creates a further problem as installing the math/lapack port 
 requires a Fortran compiler and that means one of the other GCC ports 
 will be compiled as a dependency...

 To clarify this confusing situation: The lang/gnat-gcc44 port needs to 
 be able to compile one of it's own (sometimes) runtime dependencies.

 I'm happy to enable the C++ and gfortran backends in the lang/gnat-gcc44
 port but I suspect it'll be necessary to update either math/lapack
 or bsd.gcc.mk in order to allow the lang/gnat-gcc44 port to compile
 math/lapack. I do regular builds on 7.2 i386/amd64 and 8.0 i386/amd64
 with ada,c,c++,fortran so I'm confident there won't be any serious
 problems with the port itself.

 Perhaps somebody with a clue could tell me what the right way to handle 
 this mess is.

I looked into the situation and think the following should work nicely 
given the constraints of the FreeBSD Ports Collection in handling 
dependencies and creating several packages from one build:

 1. Make gnat-gcc44 dependent on gcc44 itself by means of USE_GCC=4.4.
 2. Have math/lapack as another dependency to gnat-gcc44.
 3. Build the minimum necessary as part of gnat-gcc44.  Do not install
using `make install`, but copy the relevant files to $PREFIX/bin,
$PREFIX/lib,... manually.

That way the Ports Collection as such will use gcc44 and you will add
the GNAT support from gnat-gcc44 (and only that) on top.

Gerald @FreeBSD.org
-- 
Gerald (Jerry) Pfeifer   ger...@pfeifer.com   http://www.pfeifer.com/gerald/
___
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: Issues with Perl 5.8.9_3 port/package (in combination with FreeRADIUS 2.1.6)

2010-01-07 Thread Nick Rogers
I've tried using portupgrade to build and install the freeradius2 package on
a fresh 8.0-RELEASE install with latest ports tree and that did not seem to
change anything.

On Tue, Jan 5, 2010 at 2:04 PM, Jerry ges...@yahoo.com wrote:

 On Tue, 5 Jan 2010 15:21:04 -0500 Nick Rogers ncrog...@gmail.com
 articulated:

  I installed FreeBSD 8.0-RELEASE from official ISO and used pkg_add -r to
  install the packages. I also tried building my own packages from ports
 tree
  and got the same result.

 You might try using something like portmanger to rebuild your installed
 packages:

portmanager -u -f -l -y

 If you go that route, be sure to update your ports tree first.

 --
 Jerry
 ges...@yahoo.com

 ___
 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

___
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