Fping 3.4 hangs when started 2nd time and = 1 host down

2012-10-29 Thread Paul Schenkeveld 
Hi,

Fping 3.4 consistently hangs when one of the hosts being pinged is down
ad fping is run more than once.

Example:

# fping -a host1 host2 host3 host4
host1
host2
host4
[times out after some time]
# fping -a host1 host2 host3 host4
host1
host2
host4
[hangs forever]

I'm running FreeBSD 8.3.

With kind regards,

Paul Schenkeveld
___
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

syslog-ng1

2011-10-24 Thread Paul Schenkeveld 
Hello,

Recently sysutils/syslog-ng (version 1) moved to sysutils/syslog-ng1
and version 3 became the standard.  The Makefile for syslog-ng1 says:

DEPRECATED= Suggested by syslog-ng upline, no longer supported
FORBIDDEN=  Vulnerable since 2008-11-18, 
http://portaudit.freebsd.org/75f2382e-b586-11dd-95f9-00e0815b8da8.html

and portaudit.freebsd.org says:

I have not had the time to analyze all of syslog-ng code. But by
reading the code section near the chroot call and looking at strace
results I believe that syslog-ng does not chdir to the chroot jail's
location before chrooting into it.

This opens up ways to work around the chroot jail.

However, if I look at the code (main.c function main() near line 514):

if (chroot_dir) {
if (chdir(chroot_dir)  0) {
werror(Error chdiring, exiting.\n);
return 3;
}
if (chroot(.)  0) {
werror(Error chrooting, exiting.\n);
return 3;
}
}

it looks like the chdir is already present (main.c dates back to Mar 14,
2006).  This is the only occurrence of chroot() in the sources.

Am I missing something here?

My reason for bothering is that I use syslog-ng on man systems that have
no persistent storage to send logging to a central logserver over TCP.

Syslog-ng versions 2 and 3 pull in way too many ports to be useful in
embedded systems so I'd really like to see version 1 survive, unless
someone else has a suggestion for a replacement.  BTW, the log servers
also run syslog-ng and our configuration uses too many features of
-ng to switch to another syslog replacement but we can consider using
version 2 or 3 there.

What does it take to keep version 1 maintained and in the ports tree?

Best regards,

Paul Schenkeveld
___
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: Google-earth: memory fault

2011-04-19 Thread Paul Schenkeveld 
On Wed, Apr 06, 2011 at 08:24:29PM +0200, Juergen Lock wrote:
 In article 20110405232519.ga60...@psconsult.nl you write:
 Hi,
 Hi!
 
 Until a couple of months ago, I was happily using google-earth on all
 my desktops and laptops.  Now, it exits with Memory Fault after
 creating the startup window, the main window and a tiny pop-up window.
 The pop-up window does not have a title not contents so I don't know
 what it's trying to tell me.  After this message, I'm back at the
 shell prompt, the three google-earth windows stay on the screen and
 do not react to resize or cancel messages from the window manager.
 There are 30 ./googleearth-bin processes still running and if I
 killall -1 googleearth-bin the window these processes and the windows
 on my screen disappear.
 
 One laptop had google-earth running fo nearly two years but one day,
 probably after the upgrade to google-earth-6.0.1.2032,1, it started
 exiting with the above message.  The notebook is running FreeBSD
 8.2-STABLE #4: Sun Feb 27 12:28:14 CET 2011 i386, has an Intel T7500
 Core 2 duo CPU and 3 GB RAM.
 
 The other laptop runs FreeBSD 8.2-RELEASE #0: Fri Mar 11 21:52:10 CET
 2011 amd64 on an Intel Q9100 CPU with 4 GB RAM.
 
 I can't get googleearth-bin to dump core, it just prints Memory Fault
 and exits.
 
 Any ideas ow to debug this?
 
 Hm googleearth still runs here...  Did you have accellerated gl when
 it still worked?  If not maybe that is broken again...  If you have

Google-earth was fast, I don't know another way to tell whether
accellerated gl worked or not.

 accellerated gl working for native executables but not for linux ones
 you could try enabling AIGLX in your xserver and tell googleearth
 to use that by setting LIBGL_ALWAYS_INDIRECT=1 in it's environment.
 
  And if you don't have accellerated gl working at all but are using
 an ati HD3xxx or HD4xxx card you could try setting WITHOUT_NOUVEAU
 in make.conf and rebuilding a few ports after that, see the 20100207
 entry in /usr/ports/UPDATING .

Both laptops have an Nvidia card: Quadro FX 360M on the old i386
laptop and Quadro FX 2700M on the new amd64 laptop.  Both are using
nvidia-driver-256.53_1 and I have re-installed this video driver after
installation/upgrade of linux-dri because of the libGL conflict (and
rebooted the laptop to make sure that the correct kernel module is
loaded).

On both laptops, I get the main google-earth window, the Start Up Tip
window and then I get Memory fault, the wrapper script stops and 20
googleearth-bin are still running.

Running google-earth on laptop #1 with $DISPLAY set to laptop #2 works
and also vice versa, of couse it's quite slow this way.

  HTH,
   Juergen

Thank you for your help.

Paul Schenkeveld
___
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

Google-earth: memory fault

2011-04-05 Thread Paul Schenkeveld 
Hi,

Until a couple of months ago, I was happily using google-earth on all
my desktops and laptops.  Now, it exits with Memory Fault after
creating the startup window, the main window and a tiny pop-up window.
The pop-up window does not have a title not contents so I don't know
what it's trying to tell me.  After this message, I'm back at the
shell prompt, the three google-earth windows stay on the screen and
do not react to resize or cancel messages from the window manager.
There are 30 ./googleearth-bin processes still running and if I
killall -1 googleearth-bin the window these processes and the windows
on my screen disappear.

One laptop had google-earth running fo nearly two years but one day,
probably after the upgrade to google-earth-6.0.1.2032,1, it started
exiting with the above message.  The notebook is running FreeBSD
8.2-STABLE #4: Sun Feb 27 12:28:14 CET 2011 i386, has an Intel T7500
Core 2 duo CPU and 3 GB RAM.

The other laptop runs FreeBSD 8.2-RELEASE #0: Fri Mar 11 21:52:10 CET
2011 amd64 on an Intel Q9100 CPU with 4 GB RAM.

I can't get googleearth-bin to dump core, it just prints Memory Fault
and exits.

Any ideas ow to debug this?

Regards,

Paul Schenkeveld
___
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: [Call For Testing] VirtualBox for FreeBSD!

2009-05-19 Thread Paul Schenkeveld 
On Thu, May 14, 2009 at 09:12:37PM +0200, Martin Wilke wrote:
 
 Howdy Guys,
 
 After the announcement from Alexander Eichner about
 Virtualbox on FreeBSD, we started the work on a port
 for FreeBSD. Now we think that we solved the most
 problems and are ready for the first Call for Testing.

Many thanks!

So far I had a short ride but vbox fails every time after the first try.

If the following can help you debug/improve, read on, otherwise I'll just
wait for a more stable version.  If you want me to test anything or send
crash dump, please let me know.

 - Running 7.2-STABLE i386 as of Thu May 14 19:28:42 CEST 2009 on Dell
   Precision M4300 notebook (Intel T7500 Core-2 Duo, 2.2GHz VT-x enabled,
   3 GB RAM)
 - /proc is mounted
 - Downloaded vbox port yesterday evening (~ 18:50 UTC)
 - make -s install clean (watch many qt4 dependencies, dev86 and vbox
   install)
 - kldload vboxdrv (OK, even with X running)
 - $ VirtualBox
 - Created a guest with 512MB RAM, 2GB IDE pri master disk
 - Could not choose bridged network, so fell back to NAT
 - Installed FreeBSD 7.1 from 7.1 release DVD iso, feels very good, nice
   performance!
 - Could not NFS mount anything, vbox NAT translates NFS client to
   unprivileged port
 - Wanted to add second virtual disk to hold /usr/src and /usr/obj so
   stopped vbox, added virtual disk and tried to restart guest many
   times, no luck
 - Rebooted computer
 - kldload vboxdrv (with X11 running), system panics
 - Reboot and load vboxdrv from loader works
 - Trying to start existing vbox guest always fails, sometimes with error
   popup:
   Unknown error creating VM (VERR_PDM_DEVICE_NOT_FOUND).

   Result Code: NS_ERROR_FAILURE (0x80004005)
   Component:   Console
   Interface:   IConsole {a7f17a42-5b64-488d-977b-4b2c639ada27}
   but mostly I only see the console window appear and disappear within
   a second (/var/log/messages: pid 1283 (VirtualBox), uid 2506: exited
   on signal 11
 - Creating a new guest (in case disk image of old guest is damaged)
   never starts (shows same symptoms as original guest)

Thanks again for all the good work!

-- Paul Schenkeveld
___
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: DEPENDS -- is it time to remove it?

2007-12-11 Thread Paul Schenkeveld 
On Fri, Jan 05, 2007 at 08:28:10PM +, RW wrote:
 On Fri, 5 Jan 2007 20:52:50 +0300
 Andrew Pantyukhin [EMAIL PROTECTED] wrote:
 
  On 1/5/07, RW [EMAIL PROTECTED] wrote:
   Isn't DEPENDS still a sensible way of making
   one metaport depend on another. For example
   if someone wanted to create a personal desk-
   top metaport that depends on KDE, xorg etc.
  
  People need programs, not ports. 
 
 It's not that straightforward when you want to depend on a
 metaport like KDE. All of the binaries can be provided by individual
 sub-ports. The sensible thing to do is create a dependency on KDE and
 let KDE's options/knobs handle the lower dependencies. The ports tree
 doesn't need to have metaports depend on metaports, but some people
 find it useful to create their own. 
 
 It's more
  sensible to run_depend on files than just on
  ports.
 
 Looking at the porter's handbook it looks like the solution is to use
 RUN_DEPENDS with${NONEXISTENT}, so I guess DEPENDS is redundant.

So now I have a need for a metaport to depend on another metaport.
Without DEPENDS, how do I accomplish that.  Using RUN_DEPENDS with 
${NONEXISTENT} seems not appropriate here, the Porters Handbook says
that this should only be used to pull in source, not to install another
metaport (unless it is already installed) and the effect of using
something like RUN_DEPENDS=${NONEXISTENT}:${PORTSDIR}/lang/php5-extensions
causes make install to try installing php5-extensions even when this port
is already installed.

The two metaport I need to depend on are php5-extensions and
xorg-drivers and I really don't want to copy the OPTIONS processing of
these ports and maintain that in the future.

Thanks in advance for any help.

Paul Schenkeveld
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: DEPENDS -- is it time to remove it?

2007-12-11 Thread Paul Schenkeveld 
On Tue, Dec 11, 2007 at 02:40:11PM +0100, Gabor Kovesdan wrote:
 Scot Hetzel escribió:
 On 12/11/07, Paul Schenkeveld [EMAIL PROTECTED] wrote:
   
 So now I have a need for a metaport to depend on another metaport.
 Without DEPENDS, how do I accomplish that.  Using RUN_DEPENDS with
 ${NONEXISTENT} seems not appropriate here, the Porters Handbook says
 that this should only be used to pull in source, not to install another
 metaport (unless it is already installed) and the effect of using
 something like RUN_DEPENDS=${NONEXISTENT}:${PORTSDIR}/lang/php5-extensions
 causes make install to try installing php5-extensions even when this port
 is already installed.
 
 The two metaport I need to depend on are php5-extensions and
 xorg-drivers and I really don't want to copy the OPTIONS processing of
 these ports and maintain that in the future.
 
 
 
 For xorg-drivers you simply use:
 
 RUN_DEPENDS= 
 ${LOCALBASE}/libdata/xorg/drivers:${PORTSDIR}/x11-drivers/xorg-drivers
 
 to get this to work for php5-extensions, you would need to patch the
 Makefile with:
 
 PLIST_FILES= libdata/php5/extensions
 PLIST_DIR= libdata/php5
 
 do-install:
 ${MKDIR} ${PREFIX}/libdata/php5
 ${TOUCH} ${PREFIX}/libdata/php5/extensions
 
 Then you could use:
 
 RUN_DEPENDS= 
 ${LOCALBASE}/libdata/php5/extensions:${PORTSDIR}/lang/php5-extensions
   
 Or what about just depending on the specific components of 
 php5-extensions? This would reasult in more lines, but would give you a 
 better way to fine-tune the dependencies and won't result in 
 unnecessarily installed ports for the user. Or do you really need the 
 whole bunch of extensions that php5-extensions offers?

No, I want to use the OPTIONS facility of php5-extensions so I cannot
depend on individual ports as each individual port may be disabled
during make config.

-- Paul Schenkeveld
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: DEPENDS -- is it time to remove it?

2007-12-11 Thread Paul Schenkeveld 
On Tue, Dec 11, 2007 at 07:35:16AM -0600, Scot Hetzel wrote:
 On 12/11/07, Paul Schenkeveld [EMAIL PROTECTED] wrote:
  So now I have a need for a metaport to depend on another metaport.
  Without DEPENDS, how do I accomplish that.  Using RUN_DEPENDS with
  ${NONEXISTENT} seems not appropriate here, the Porters Handbook says
  that this should only be used to pull in source, not to install another
  metaport (unless it is already installed) and the effect of using
  something like RUN_DEPENDS=${NONEXISTENT}:${PORTSDIR}/lang/php5-extensions
  causes make install to try installing php5-extensions even when this port
  is already installed.
 
  The two metaport I need to depend on are php5-extensions and
  xorg-drivers and I really don't want to copy the OPTIONS processing of
  these ports and maintain that in the future.
 
 
 For xorg-drivers you simply use:
 
 RUN_DEPENDS= 
 ${LOCALBASE}/libdata/xorg/drivers:${PORTSDIR}/x11-drivers/xorg-drivers
 
 to get this to work for php5-extensions, you would need to patch the
 Makefile with:
 
 PLIST_FILES= libdata/php5/extensions
 PLIST_DIR= libdata/php5
 
 do-install:
 ${MKDIR} ${PREFIX}/libdata/php5
 ${TOUCH} ${PREFIX}/libdata/php5/extensions
 
 Then you could use:
 
 RUN_DEPENDS= 
 ${LOCALBASE}/libdata/php5/extensions:${PORTSDIR}/lang/php5-extensions

Thanks.

I was afraid it would turn out this way but this would make my port
non-portable to my customers unless I patch all their php5-extensions
Makefiles and make sure they won't get overwritten by a a future cvs
checkout.

Or try to ask the php5-extensions maintainer to add a dummy file or
dir to this meta-port for other meta-ports to depend on.

Anyway, it's a pity that the old DEPENDS functionality of depending on
a port instead of something installed by the port has gone.

Regards,

Paul Schenkeveld
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]