date:20111031

On 10/27/2011 09:27, Scott Lambert wrote:
 On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
 Hi folks,

 As crees@ suggested, I'm sending an email to ports@ about this.

 What really bothers me when I use the FreeBSD Ports tree on one of my
 systems, is that the behaviour of dealing with services is quite
 inconsistent. 

 My question is whether anyone has ever attempted to improve the
 integration with rc-scripts? In the PR I propose something along these
 lines:

  We know exactly which ports install rc scripts (USE_RC_SUBR).
  Why not run `/usr/local/etc/rc.d/${FOO} status' and
  `/usr/local/etc/rc.d/${FOO} stop' prior to installation. Based
  on the return value of the first, we can run
  `/usr/local/etc/rc.d/${FOO} start' after installation.
 
 If all of that is contingent upon a boolean knob the admin can set,
 something like NO_RESTART_SERVICES, I suspect everyone could get
 what they want and the bikeshed would be limitted to what the default
 for that boolean should be.
 
 The people who don't want the services restarted automagically can
 set it and, once things use the new ports framewoork properly, not
 have to worry about suprises.  The people who want everything to
 restarted as soon as possible can set the knob the other way.  
 
 It could help keep our less sophisticated users from continuing to
 run vulerable versions of software after they think they have done
 what is needed to get the patched software.  The sophisticated users
 would still be free to choose which foot to shoot.
 
 A side effect might, eventually, be to encourage ports maintainers
 to analyse their ported software for incompatible config changes
 so that they can programatically halt the install and output a
 warning message before attempting to stop the old daemon then
 upgrading while a likely un-usable config is in place.
 
 I see it as win, win, if there is a knob.
 
 I do not like either option without a knob, depending on the box
 we are talking about.

Speaking only for myself I hate the idea of stopping/starting services
automatically. However this feature is often requested, and is something
that is provided by many other package systems. If we have people who
are willing to do the work I think it's worth discussing how to do it
properly.

I think Scott's on the right track. The way that I envision it working
would be a 3-knob system. One knob to always restart the services, one
to never do it; and then asking on a per-port basis, which should be the
default. I can imagine portmaster detecting this option in the pre-build
phase similarly to how it detects and warns about IS_INTERACTIVE now,
and giving the user a menu of options for how to handle it. I'm happy to
add more details if people are interested.

Where this actually becomes interesting is not in the ports
build/install process, which is pretty easy to deal with, but with
package installs/deinstalls. I definitely think it's doable, what we
probably want to do is put a knob for this in the port's Makefile, and
handle the stop/start for both the port and the package with a little
script that can be included in the package, and run with @exec and @unexec.


hth,

Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.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

Re: ports/162049: The Ports tree lacks a framework to restart services

2011-10-31 Thread Dominic Fandrey

On 31/10/2011 07:28, Doug Barton wrote:
 On 10/27/2011 09:27, Scott Lambert wrote:
 On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
 What really bothers me when I use the FreeBSD Ports tree on one of my
 systems, is that the behaviour of dealing with services is quite
 inconsistent. 

 If all of that is contingent upon a boolean knob the admin can set,
 something like NO_RESTART_SERVICES, I suspect everyone could get
 what they want and the bikeshed would be limitted to what the default
 for that boolean should be.

 The people who don't want the services restarted automagically can
 set it and, once things use the new ports framewoork properly, not
 have to worry about suprises.  The people who want everything to
 restarted as soon as possible can set the knob the other way.  

 
 
 I think Scott's on the right track. The way that I envision it working
 would be a 3-knob system. One knob to always restart the services, one
 to never do it; and then asking on a per-port basis, which should be the
 default. I can imagine portmaster detecting this option in the pre-build
 phase similarly to how it detects and warns about IS_INTERACTIVE now,
 and giving the user a menu of options for how to handle it. I'm happy to
 add more details if people are interested.

I think this should be handled in the pkg-install script. Pkg based
upgrade tools _do_ exist.

 Where this actually becomes interesting is not in the ports
 build/install process, which is pretty easy to deal with, but with
 package installs/deinstalls. I definitely think it's doable, what we
 probably want to do is put a knob for this in the port's Makefile, and
 handle the stop/start for both the port and the package with a little
 script that can be included in the package, and run with @exec and @unexec.

Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
already there.

 
 
 hth,
 
 Doug
 


-- 
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: ports/162049: The Ports tree lacks a framework to restart services

On 10/31/2011 00:38, Dominic Fandrey wrote:
 On 31/10/2011 07:28, Doug Barton wrote:
 On 10/27/2011 09:27, Scott Lambert wrote:
 On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
 What really bothers me when I use the FreeBSD Ports tree on one of my
 systems, is that the behaviour of dealing with services is quite
 inconsistent. 

 If all of that is contingent upon a boolean knob the admin can set,
 something like NO_RESTART_SERVICES, I suspect everyone could get
 what they want and the bikeshed would be limitted to what the default
 for that boolean should be.

 The people who don't want the services restarted automagically can
 set it and, once things use the new ports framewoork properly, not
 have to worry about suprises.  The people who want everything to
 restarted as soon as possible can set the knob the other way.  



 I think Scott's on the right track. The way that I envision it working
 would be a 3-knob system. One knob to always restart the services, one
 to never do it; and then asking on a per-port basis, which should be the
 default. I can imagine portmaster detecting this option in the pre-build
 phase similarly to how it detects and warns about IS_INTERACTIVE now,
 and giving the user a menu of options for how to handle it. I'm happy to
 add more details if people are interested.
 
 I think this should be handled in the pkg-install script. Pkg based
 upgrade tools _do_ exist.

Yeah, that's what I said below. :)

 Where this actually becomes interesting is not in the ports
 build/install process, which is pretty easy to deal with, but with
 package installs/deinstalls. I definitely think it's doable, what we
 probably want to do is put a knob for this in the port's Makefile, and
 handle the stop/start for both the port and the package with a little
 script that can be included in the package, and run with @exec and @unexec.
 
 Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
 already there.

That feature as it exists currently isn't even close to adequate, and is
causing more problems than it solves. Hence the discussion.


Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.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

gstat collision between sysutils/coreutils and base gstat

Hey all,

Traditionally we've tended to use the 'g' prefix for GNU utilities;
gmake, gtar etc, but apparently with stat that is a problem [1], due
to the different gstat utility in base.

I'm reluctant to simply rename the coreutils to gnu- prefixes, because
that would upset quite a lot of things!

We either need to:

1) Rename to coreutils to gnu- like most of the rest of the non-GNU
world and deal with the breakage (!)
2) Make gstat an OPTION, off by default
3) Be horribly inconsistent and rename gstat to gnustat

Thoughts?

Chris

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=160060
___
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/162049: The Ports tree lacks a framework to restart services

On 31 October 2011 08:37, Doug Barton do...@freebsd.org wrote:
 On 10/31/2011 00:38, Dominic Fandrey wrote:
 On 31/10/2011 07:28, Doug Barton wrote:
 On 10/27/2011 09:27, Scott Lambert wrote:
 On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
 What really bothers me when I use the FreeBSD Ports tree on one of my
 systems, is that the behaviour of dealing with services is quite
 inconsistent.

 If all of that is contingent upon a boolean knob the admin can set,
 something like NO_RESTART_SERVICES, I suspect everyone could get
 what they want and the bikeshed would be limitted to what the default
 for that boolean should be.

 The people who don't want the services restarted automagically can
 set it and, once things use the new ports framewoork properly, not
 have to worry about suprises.  The people who want everything to
 restarted as soon as possible can set the knob the other way.



 I think Scott's on the right track. The way that I envision it working
 would be a 3-knob system. One knob to always restart the services, one
 to never do it; and then asking on a per-port basis, which should be the
 default. I can imagine portmaster detecting this option in the pre-build
 phase similarly to how it detects and warns about IS_INTERACTIVE now,
 and giving the user a menu of options for how to handle it. I'm happy to
 add more details if people are interested.

 I think this should be handled in the pkg-install script. Pkg based
 upgrade tools _do_ exist.

 Yeah, that's what I said below. :)

 Where this actually becomes interesting is not in the ports
 build/install process, which is pretty easy to deal with, but with
 package installs/deinstalls. I definitely think it's doable, what we
 probably want to do is put a knob for this in the port's Makefile, and
 handle the stop/start for both the port and the package with a little
 script that can be included in the package, and run with @exec and @unexec.

 Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
 already there.

 That feature as it exists currently isn't even close to adequate, and is
 causing more problems than it solves. Hence the discussion.

I'd be happy to code this; I've offered once before. However, I had a
hard time convincing people that it wasn't something that
portmaster/portupgrade should be doing instead...

Chris
___
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: VirtualBox-kmod fails to build on -CURRENT


Vladimir Kushnir wrote on 26.10.2011 11:32:

Hi
Well, the problem is:
I'm trying to build VirtualBox{*} on amd64 10.0-CURRENT. The very first 
port, virtualbox-ose-kmod fails with


/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.12_OSE/out/freebsd. 

amd64/release/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:104: error: 
'D_PSEUDO' undeclared here (not in a function)


And indeed, threre's no D_PSEUDO flags in /usr/src
Any help?

Thanks in advance,
Vladimir


See http://svnweb.freebsd.org/base?view=revisionrevision=226500

I presume emulators/virtualbox-ose-kmod needs to take this one into account.

I've submitted a PR.


MfG CoCo
___
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: VirtualBox-kmod fails to build on -CURRENT

2011-10-31 Thread Bernhard Froehlich


On 31.10.2011 10:23, Marco Steinbach wrote:

Vladimir Kushnir wrote on 26.10.2011 11:32:

Hi
Well, the problem is:
I'm trying to build VirtualBox{*} on amd64 10.0-CURRENT. The very 
first port, virtualbox-ose-kmod fails with


/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-4.0.12_OSE/out/freebsd.
amd64/release/bin/src/vboxdrv/freebsd/SUPDrv-freebsd.c:104: error: 
'D_PSEUDO' undeclared here (not in a function)

And indeed, threre's no D_PSEUDO flags in /usr/src
Any help?
Thanks in advance,
Vladimir


See http://svnweb.freebsd.org/base?view=revisionrevision=226500

I presume emulators/virtualbox-ose-kmod needs to take this one into 
account.


I've submitted a PR.


My first guess is that it could be enough to remove the flag but I 
don't know if we need to replace some code with make_dev_p(). So i've 
CC'd ed@ and hope that he can shed some light on that.


https://www.virtualbox.org/browser/trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c#L104

--
Bernhard Froehlich
http://www.bluelife.at/
___
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: VirtualBox-kmod fails to build on -CURRENT

Hi Bernhard,

* Bernhard Froehlich de...@freebsd.org, 20111031 11:04:
 My first guess is that it could be enough to remove the flag but I
 don't know if we need to replace some code with make_dev_p(). So i've
 CC'd ed@ and hope that he can shed some light on that.
 
 https://www.virtualbox.org/browser/trunk/src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c#L104

Hmmm... You can simply remove D_PSEUDO for now, but I think eventually
the driver should be restructured a bit. It seems we can simply use the
cdevpriv API for this, where we have a single /dev/vboxdrv device node.

I think I'll take a closer look at this code more thoroughly sometime
this week.

-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/


pgpicPjIOWu2Q.pgp
Description: PGP signature

Re: ports/162049: The Ports tree lacks a framework to restart services

2011-10-31 Thread Dominic Fandrey

On 31/10/2011 09:37, Doug Barton wrote:
On 10/31/2011 00:38, Dominic Fandrey wrote:
On 31/10/2011 07:28, Doug Barton wrote:
On 10/27/2011 09:27, Scott Lambert wrote:
On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:
What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent.

If all of that is contingent upon a boolean knob the admin can set,
something like NO_RESTART_SERVICES, I suspect everyone could get
what they want and the bikeshed would be limitted to what the default
for that boolean should be.

The people who don't want the services restarted automagically can
set it and, once things use the new ports framewoork properly, not
have to worry about suprises. The people who want everything to
restarted as soon as possible can set the knob the other way.

I think Scott's on the right track. The way that I envision it working
would be a 3-knob system. One knob to always restart the services, one
to never do it; and then asking on a per-port basis, which should be the
default. I can imagine portmaster detecting this option in the pre-build
phase similarly to how it detects and warns about IS_INTERACTIVE now,
and giving the user a menu of options for how to handle it. I'm happy to
add more details if people are interested.

I think this should be handled in the pkg-install script. Pkg based
upgrade tools _do_ exist.

Yeah, that's what I said below. :)

Sorry about that, I read the entire thread in one go, might have overlooked
something. Ironic, because the purpose was to avoid posting redundant
feedback.

Where this actually becomes interesting is not in the ports
build/install process, which is pretty easy to deal with, but with
package installs/deinstalls. I definitely think it's doable, what we
probably want to do is put a knob for this in the port's Makefile, and
handle the stop/start for both the port and the package with a little
script that can be included in the package, and run with @exec and @unexec.

Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
already there.

That feature as it exists currently isn't even close to adequate, and is
causing more problems than it solves. Hence the discussion.

Well, I am one of the people who see no need for this feature and my vote
is for default off, if it's implemented.

I just wanted to hint that such a function is already in place and I don't
think it would be difficult to add the possibility to start a service.

What has to be done after an update is often very specific, though.
I don't envy the person having to come up with an adequate implementation.
E.g. it's not always the service installed by the pkg that needs to be
restarted:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/automounter/pkg-message?rev=1.2;content-type=text%2Fplain

Regards

--
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

Current unassigned ports problem reports

2011-10-31 Thread FreeBSD bugmaster

(Note: an HTML version of this report is available at
http://www.freebsd.org/cgi/query-pr-summary.cgi?category=ports .)

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker  Resp.  Description

f ports/162194[UPDATE] www/py-gunicorn to 0.13.4
o ports/162192[UPDATE] www/py-requests to 0.7.4
o ports/162191[PATCH] editor/emacs: VC doesn't work with subversion 
o ports/162185[PATCH] mail/cyrus-imapd: re-enable autosieve option
o ports/162184[maintainer update] converters/py-bsdconv 6.5
o ports/162178Add bsd.clang.mk with Clang/LLVM support
f ports/162177mail/opendkim - make dependency to Sendmail optional
o ports/162167New port: sysutils/torque2
f ports/162165[update] lang/php52 update for new timezone set in tim
o ports/162158[MAINTAINER-UPDATE] ports-mgmt/bpkg: update to 2.1.4
f ports/162148can't build net-p2p/eiskaltdcpp-lib
o ports/162111[patch][maintainer-update] databases/jasperserver: upd
o ports/162109[new port] sysutils/xjobs: Utility reads job descripti
f ports/162107audio/clementine-player does nor play OGG audio files
o ports/162093[maintainer-update] devel/gdb: Segmentation fault runn
o ports/162085duplicate file name in open-motif-2.3.3 and tcl-8.5.10
f ports/162082[patch] databases/mongodb: fix strip binaries
o ports/162058New port: mail/roundcube-thunderbird_labels Thunderbir
o ports/162053[NEW PORT] devel/php5-msgpack PHP extension for interf
f ports/162052[update][fix] devel/fb303
o ports/162047New port: mail/roundcube-contextmenu Context menu plug
o ports/162045print/ghostview 1.5_2 coredumps on certain files
o ports/162041[new port] print/harfbuzz: OpenType text shaping engin
o ports/162039update for lang/qore from 0.8.0 to 0.8.3
f ports/162026Update www/davical to version 0.9.9.7
f ports/162025devel/php-libawl upgrade to version 0.49
o ports/162024Update port: graphics/yed: new version 3.8
o ports/162017[patch] lang/sbcl: mark BROKEN on freebsd 9/10 (THREAD
o ports/162016BSDPAN::ExtUtils::Packlist-get_dir_list can go into a
o ports/162015New port: www/phpmustache - Installs PHP code for the 
f ports/162013[patch update] sysutils/b43-fwcutter 012 - 015
o ports/161994[maintainer] update lang/petite-chez from 8.3 to 8.4
o ports/161989OpenOCD port (devel/openocd) update 0.4.0 - 0.5.0
o ports/161977New port: sysutils/volman FreeBSD specific volume mana
s ports/161965Update Ports mail/assp to latest version
o ports/161963[MAINTAINER] net-p2p/py26-BitTornado: [SUMMARIZE CHANG
f ports/161951mail/dovecot2-antispam-plugin hangs fails when built w
o ports/161938New port www/pyLoad a fast, lightweight and full featu
o ports/161932net-mgmt/net-snmp reports bogus data in UCD-SNMP-MIB::
o ports/161922[maintainer][patch] math/saga: cleanup unneeded helper
o ports/161894New port databases/datamodeler: Database modeling tool
o ports/161867Revised Port: www/web-traceroute
f ports/161845[update] [patch] multimedia/mplayer-skins Bring in ups
f ports/161844[PATCH] graphics/geos: update to 3.3.1
o ports/161832[maintainer] update databases/mysql-connector-odbc to 
o ports/161814[patch] security update www/linux-opera to 11.52
o ports/161800[new ports] 2 new Pure bindings: math/pure-mpfr  deve
f ports/161790Update security/metasploit port
f ports/161694sysutils/dvd+rw-tools: growisofs fails to close disc
o ports/161690New port: games/prboom-plus Port of ID Software's Doom
o ports/161678New port: sysutils/acpi_call kernle module for calling
o ports/161578devel/strace is not working
f ports/161570deskutils/vym: [UPDATE] to 1.99.0
f ports/161569[MAINTAINER] audio/libaacplus: aacplus.h has comma at 
o ports/161539New port: audio/gmusicbrowser - Jukebox for large amou
f ports/161518[patch] update/add devel/scons version 2.1.0
f ports/161470[patch] www/squid31 unintentionally picks up libmd5 as
o ports/161467[UPDATE] textproc/py-creole to 0.9.1
o ports/161462net-mgmt/zabbix-agent: Zabbix_agentd opens a lot of fi
o ports/161455multimedia/transcode should depend on ffmpeg
o ports/161442[MAINTAINER] devel/gps: Update to version 5.0.1
o ports/161440[NEW

Re: VirtualBox-kmod fails to build on -CURRENT

* Ed Schouten e...@80386.nl, 20111031 11:26:
 I think I'll take a closer look at this code more thoroughly sometime
 this week.

Ugh. Too impatient. Please try the attached patch. It should build on
7.x and higher. I have only compile-tested it, because I am not a
VirtualBox user (yet).

| SUPDrv-freebsd.c |  153 ++-
| 1 file changed, 21 insertions(+), 132 deletions(-)

-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/
--- src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
+++ src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c
@@ -69,10 +69,9 @@
 static int VBoxDrvFreeBSDModuleEvent(struct module *pMod, int enmEventType, 
void *pvArg);
 static int VBoxDrvFreeBSDLoad(void);
 static int VBoxDrvFreeBSDUnload(void);
-static void VBoxDrvFreeBSDClone(void *pvArg, struct ucred *pCred, char 
*pachName, int cchName, struct cdev **ppDev);
 
-static d_fdopen_t   VBoxDrvFreeBSDOpen;
-static d_close_tVBoxDrvFreeBSDClose;
+static d_open_t VBoxDrvFreeBSDOpen;
+static void VBoxDrvFreeBSDDtr(void *pData);
 static d_ioctl_tVBoxDrvFreeBSDIOCtl;
 static int  VBoxDrvFreeBSDIOCtlSlow(PSUPDRVSESSION pSession, u_long 
ulCmd, caddr_t pvData, struct thread *pTd);
 
@@ -100,21 +99,13 @@
 static struct cdevswg_VBoxDrvFreeBSDChrDevSW =
 {
 .d_version =D_VERSION,
-#if __FreeBSD_version  800061
-.d_flags =  D_PSEUDO | D_TRACKCLOSE | D_NEEDMINOR,
-#else
-.d_flags =  D_PSEUDO | D_TRACKCLOSE,
-#endif
-.d_fdopen = VBoxDrvFreeBSDOpen,
-.d_close =  VBoxDrvFreeBSDClose,
+.d_open =   VBoxDrvFreeBSDOpen,
 .d_ioctl =  VBoxDrvFreeBSDIOCtl,
 .d_name =   vboxdrv
 };
 
 /** List of cloned device. Managed by the kernel. */
-static struct clonedevs*g_pVBoxDrvFreeBSDClones;
-/** The dev_clone event handler tag. */
-static eventhandler_tag g_VBoxDrvFreeBSDEHTag;
+static struct cdev *g_pVBoxDrvFreeBSDChrDev;
 /** Reference counter. */
 static volatile uint32_tg_cUsers;
 
@@ -176,20 +167,10 @@
 if (RT_SUCCESS(rc))
 {
 /*
- * Configure device cloning.
+ * Configure character device.
  */
-clone_setup(g_pVBoxDrvFreeBSDClones);
-g_VBoxDrvFreeBSDEHTag = EVENTHANDLER_REGISTER(dev_clone, 
VBoxDrvFreeBSDClone, 0, 1000);
-if (g_VBoxDrvFreeBSDEHTag)
-{
-Log((VBoxDrvFreeBSDLoad: returns successfully\n));
-return VINF_SUCCESS;
-}
-
-printf(vboxdrv: EVENTHANDLER_REGISTER(dev_clone,,,) failed\n);
-clone_cleanup(g_pVBoxDrvFreeBSDClones);
-rc = VERR_ALREADY_LOADED;
-supdrvDeleteDevExt(g_VBoxDrvFreeBSDDevExt);
+g_pVBoxDrvFreeBSDChrDev = make_dev(g_VBoxDrvFreeBSDChrDevSW, 0, 
UID_ROOT, GID_WHEEL, VBOXDRV_PERM, vboxdrv);
+return VINF_SUCCESS;
 }
 else
 printf(vboxdrv: supdrvInitDevExt failed, rc=%d\n, rc);
@@ -210,8 +191,7 @@
 /*
  * Reserve what we did in VBoxDrvFreeBSDInit.
  */
-EVENTHANDLER_DEREGISTER(dev_clone, g_VBoxDrvFreeBSDEHTag);
-clone_cleanup(g_pVBoxDrvFreeBSDClones);
+destroy_dev(g_pVBoxDrvFreeBSDChrDev);
 
 supdrvDeleteDevExt(g_VBoxDrvFreeBSDDevExt);
 
@@ -225,59 +205,6 @@
 
 
 /**
- * DEVFS event handler.
- */
-static void VBoxDrvFreeBSDClone(void *pvArg, struct ucred *pCred, char 
*pszName, int cchName, struct cdev **ppDev)
-{
-int iUnit;
-int rc;
-
-Log((VBoxDrvFreeBSDClone: pszName=%s ppDev=%p\n, pszName, ppDev));
-
-/*
- * One device node per user, si_drv1 points to the session.
- * /dev/vboxdrvN where N = {0...255}.
- */
-if (!ppDev)
-return;
-if (dev_stdclone(pszName, NULL, vboxdrv, iUnit) != 1)
-return;
-if (iUnit = 256 || iUnit  0)
-{
-Log((VBoxDrvFreeBSDClone: iUnit=%d = 256 - rejected\n, iUnit));
-return;
-}
-
-Log((VBoxDrvFreeBSDClone: pszName=%s iUnit=%d\n, pszName, iUnit));
-
-rc = clone_create(g_pVBoxDrvFreeBSDClones, g_VBoxDrvFreeBSDChrDevSW, 
iUnit, ppDev, 0);
-Log((VBoxDrvFreeBSDClone: clone_create - %d; iUnit=%d\n, rc, iUnit));
-if (rc)
-{
-#if __FreeBSD_version  800061
-*ppDev = make_dev(g_VBoxDrvFreeBSDChrDevSW, iUnit, UID_ROOT, 
GID_WHEEL, VBOXDRV_PERM, vboxdrv%d, iUnit);
-#else
-*ppDev = make_dev(g_VBoxDrvFreeBSDChrDevSW, unit2minor(iUnit), 
UID_ROOT, GID_WHEEL, VBOXDRV_PERM, vboxdrv%d, iUnit);
-#endif
-if (*ppDev)
-{
-dev_ref(*ppDev);
-(*ppDev)-si_flags |= SI_CHEAPCLONE;
-Log((VBoxDrvFreeBSDClone: Created *ppDev=%p iUnit=%d si_drv1=%p 
si_drv2=%p\n,
- *ppDev, iUnit, (*ppDev)-si_drv1, (*ppDev)-si_drv2));
-(*ppDev)-si_drv1 = (*ppDev)-si_drv2 = NULL;
-}
-else
-OSDBGPRINT((VBoxDrvFreeBSDClone: make_dev iUnit=%d failed\n, 
iUnit

Re: VirtualBox-kmod fails to build on -CURRENT

* Ed Schouten e...@80386.nl, 20111031 12:07:
 Ugh. Too impatient. Please try the attached patch. It should build on
 7.x and higher. I have only compile-tested it, because I am not a
 VirtualBox user (yet).

Read: I have only compile-tested it on HEAD, but the used interfaces
should be present as of 7.x.

-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/


pgpA5DdwA3IFx.pgp
Description: PGP signature

Re: ports/162049: The Ports tree lacks a framework to restart services

2011-10-31 Thread Matthew Seaman

On 31/10/2011 10:41, Dominic Fandrey wrote:
 I just wanted to hint that such a function is already in place and I don't
 think it would be difficult to add the possibility to start a service.

Restarting a single service is no big deal.  Trouble is there are a lot
of cases where that just isn't the right thing to do.  Suppose you have
a very common situation: a web application written in PHP and using a RDBMS.

   * Upgrades to the RDBMS often require more than just a restart of the
 DB.  Eg. changes to internal schemas require running some external
 script.  (pg_upgrade, mysql_after_upgrade, etc.)

   * Upgrades to PHP -- given that PHP is modularized, then the sane
 way of restarting is to take the web app down at the point
 lang/php5 gets reinstalled, but not bring it up again until all
 the various php5 modules have been reinstalled.  At minimum.  If
 you use, say, eAccelerator, then you almost certainly need to
 rebuild that before restarting the php web-app.

   * Of course, how to restart a PHP based web-app is highly context
 dependent.  Generally it means bouncing some other daemon:
 frequently a web server like apache, or is it lighttpd?  Or some
 sort of FCGI daemon?

   * Certainly no one would ever write a DB based web-app that wouldn't
 cope gracefully with the temporary disappearance of its back-end
 DB.  Why, such a thing would be clearly beyond the bounds of
 possibility, and it would be vanishingly improbable that
 anyone should ever need to worry about needing to restart a
 web-app as a consequence of restarting a DB.

Basically, I think I can summarize by saying that as soon as you go
beyond the simplest and most basic system configurations, there are so
many different possibilities that it requires some sort of intelligent
agent to manage the upgrade and restart process.  Failing the widespread
availability of practicable AI, this is where your sysadmins are going
to earn their princely salaries.

Cheers,

Matthew


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



signature.asc
Description: OpenPGP digital signature

Re: VirtualBox-kmod fails to build on -CURRENT


Ed Schouten wrote on 31.10.2011 12:16:

* Ed Schouten e...@80386.nl, 20111031 12:07:

Ugh. Too impatient. Please try the attached patch. It should build on
7.x and higher. I have only compile-tested it, because I am not a
VirtualBox user (yet).


Read: I have only compile-tested it on HEAD, but the used interfaces
should be present as of 7.x.



Thanks for having a look into this -- I'm trying out your patch right 
now.  This will take a while, as I'll try and test this on 7, also.


MfG CoCo
___
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: VirtualBox-kmod fails to build on -CURRENT

* Marco Steinbach c...@executive-computing.de, 20111031 13:11:
 Thanks for having a look into this -- I'm trying out your patch right
 now.  This will take a while, as I'll try and test this on 7, also.

Great. Thanks! I just inspected the code and it seems VirtualBox expects
the device to be named /dev/vboxdrv%d explicitly. If that's the case,
please try to add a symbolic link from vboxdrv0 to vboxdrv. If that
works, I can get that fixed as well.

-- 
 Ed Schouten e...@80386.nl
 WWW: http://80386.nl/


pgprvecGx0i0i.pgp
Description: PGP signature

Re: ports/162049: The Ports tree lacks a framework to restart services

2011-10-31 Thread Miroslav Lachman

Dominic Fandrey wrote:

On 31/10/2011 09:37, Doug Barton wrote:

On 10/31/2011 00:38, Dominic Fandrey wrote:

On 31/10/2011 07:28, Doug Barton wrote:

On 10/27/2011 09:27, Scott Lambert wrote:

On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:

What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent.

I think this should be handled in the pkg-install script. Pkg based
upgrade tools _do_ exist.

Yeah, that's what I said below. :)

Sorry about that, I read the entire thread in one go, might have overlooked
something. Ironic, because the purpose was to avoid posting redundant
feedback.

Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
already there.

That feature as it exists currently isn't even close to adequate, and is
causing more problems than it solves. Hence the discussion.

Yes, and even if I would like to have possibility to restart some
services after upgrade, I really hate this knob to just stop the service
and leave it stopped. Can somebody add global knob to override this from
make.conf?

Well, I am one of the people who see no need for this feature and my vote
is for default off, if it's implemented.

I agree with default off.

I just wanted to hint that such a function is already in place and I don't
think it would be difficult to add the possibility to start a service.

And that's why I propossed more general user scriptable hooks for
before/after deinstall - install - upgrade actions. (It is on Doug's
portmaster proposal list http://dougbarton.us/portmaster-proposal.html)
Sometimes sysadmin needs more than just restart of the upgraded service.
Sometimes we need to restart other service as well, or run some test
script, send an alert, or for example change some file/directory
permissions - real example is courier-authdaemon when used with Postfix
for SMTP auth, we must change permissions of socket dir on each upgrade.

For me, it would be nice to be able to define functions with whatever
content executed on particular action.

short example:

function_called_after_upgrade_of_authdaemon() {
send notice to operator or write something to logfile
chmod 0755 /var/run/authdaemond
restart authdaemon
execute self-test script to check SMTP auth is working
}

This in general is more useful than just call restart on installed rc.d
script, but ofcourse, it is more complex task to implement and I am not
sure, if it should be in ports or in some utility like portmaster.

I agree that whatever will be implemented as a result of this
discussion, it should be optional feature off by default and ports
system should not silently stop / restart / start services.

Miroslav Lachman
___
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: gstat collision between sysutils/coreutils and base gstat

2011-10-31 Thread Wesley Shields

On Mon, Oct 31, 2011 at 09:21:26AM +, Chris Rees wrote:
 Hey all,
 
 Traditionally we've tended to use the 'g' prefix for GNU utilities;
 gmake, gtar etc, but apparently with stat that is a problem [1], due
 to the different gstat utility in base.
 
 I'm reluctant to simply rename the coreutils to gnu- prefixes, because
 that would upset quite a lot of things!
 
 We either need to:
 
 1) Rename to coreutils to gnu- like most of the rest of the non-GNU
 world and deal with the breakage (!)
 2) Make gstat an OPTION, off by default
 3) Be horribly inconsistent and rename gstat to gnustat

I don't know if 3 is as horribly inconsistent as you think: misc/gnuls
installs the GNU version of ls as gnuls.

-- 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

textproc/libxml2 does not install libxml2.so.5


Hi,

I'm trying to use textproc/libxml2 from ports, but it seems, that some 
files are missing after installation.


Subsequently, installing textproc/libxslt fails due to a missing 
libxml2.so.5, for example.


My /etc/make.conf is empty.  I'm a  bit reluctant to 'fix' this by 
symlinking, and besides that, libxml2.so.5 is listed in the pkg-plist of 
libxml2, so I assume something goes wrong locally or the port might need 
some attention.


I've updated the ports tree on the machine just a few minutes ago.

Here's some more information:

# uname -a
FreeBSD  10.0-CURRENT FreeBSD 10.0-CURRENT #0 r226877: Fri Oct 28 
07:55:10 UTC 2011 root@:/usr/obj/usr/src/sys/GENERIC  amd64

# pwd
/usr/ports/textproc/libxml2
# make -VPKGNAME
libxml2-2.7.8_1
# make install clean
[...]
# pkg_info -IX libxml2
libxml2-2.7.8_1 XML parser library for GNOME
# pkg_info -g libxml2-2.7.8_1
Information for libxml2-2.7.8_1:

Mismatched Checksums:
pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist


Hints and/or pointers welcome.

MfG CoCo

___
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: textproc/libxml2 does not install libxml2.so.5

2011-10-31 Thread Ruslan Mahmatkhanov


Marco Steinbach wrote on 31.10.2011 19:21:

Hi,

I'm trying to use textproc/libxml2 from ports, but it seems, that some
files are missing after installation.

Subsequently, installing textproc/libxslt fails due to a missing
libxml2.so.5, for example.

My /etc/make.conf is empty. I'm a bit reluctant to 'fix' this by
symlinking, and besides that, libxml2.so.5 is listed in the pkg-plist of
libxml2, so I assume something goes wrong locally or the port might need
some attention.

I've updated the ports tree on the machine just a few minutes ago.

Here's some more information:

# uname -a
FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r226877: Fri Oct 28
07:55:10 UTC 2011 root@:/usr/obj/usr/src/sys/GENERIC amd64
# pwd
/usr/ports/textproc/libxml2
# make -VPKGNAME
libxml2-2.7.8_1
# make install clean
[...]
# pkg_info -IX libxml2
libxml2-2.7.8_1 XML parser library for GNOME
# pkg_info -g libxml2-2.7.8_1
Information for libxml2-2.7.8_1:

Mismatched Checksums:
pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist


Hints and/or pointers welcome.

MfG CoCo


Yes, it looks like WITH_FBSD10_FIX=yes doesn't works here.
You may rebuild it with UNAME_r=9.9-CURRENT until the working fix will 
not be committed.


--
Regards,
Ruslan

Tinderboxing kills... the drives.
___
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: textproc/libxml2 does not install libxml2.so.5

2011-10-31 Thread Martin Wilke


On 10/31/2011 15:21, Marco Steinbach wrote:

Hi,

I'm trying to use textproc/libxml2 from ports, but it seems, that some 
files are missing after installation.


Subsequently, installing textproc/libxslt fails due to a missing 
libxml2.so.5, for example.


My /etc/make.conf is empty.  I'm a  bit reluctant to 'fix' this by 
symlinking, and besides that, libxml2.so.5 is listed in the pkg-plist 
of libxml2, so I assume something goes wrong locally or the port might 
need some attention.


I've updated the ports tree on the machine just a few minutes ago.

Here's some more information:

# uname -a
FreeBSD  10.0-CURRENT FreeBSD 10.0-CURRENT #0 r226877: Fri Oct 28 
07:55:10 UTC 2011 root@:/usr/obj/usr/src/sys/GENERIC  amd64

# pwd
/usr/ports/textproc/libxml2
# make -VPKGNAME
libxml2-2.7.8_1
# make install clean
[...]
# pkg_info -IX libxml2
libxml2-2.7.8_1 XML parser library for GNOME
# pkg_info -g libxml2-2.7.8_1
Information for libxml2-2.7.8_1:

Mismatched Checksums:
pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist


Hints and/or pointers welcome.

It works for me correctly

http://tb.smeets.im/tb/index.php?action=display_markup_logbuild=10-FreeBSDid=24#1000

Maybe u should try to rebuild all ports.

- Martin



MfG CoCo

___
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



--
+-oOO--(_)--OOo-+
With best Regards,
Martin Wilke (miwi_(at)_FreeBSD.org)

Mess with the Best, Die like the Rest

___
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: textproc/libxml2 does not install libxml2.so.5


Ruslan Mahmatkhanov wrote on 31.10.2011 16:57:

Marco Steinbach wrote on 31.10.2011 19:21:

Hi,

I'm trying to use textproc/libxml2 from ports, but it seems, that some
files are missing after installation.

Subsequently, installing textproc/libxslt fails due to a missing
libxml2.so.5, for example.

My /etc/make.conf is empty. I'm a bit reluctant to 'fix' this by
symlinking, and besides that, libxml2.so.5 is listed in the pkg-plist of
libxml2, so I assume something goes wrong locally or the port might need
some attention.

I've updated the ports tree on the machine just a few minutes ago.

Here's some more information:

# uname -a
FreeBSD 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r226877: Fri Oct 28
07:55:10 UTC 2011 root@:/usr/obj/usr/src/sys/GENERIC amd64
# pwd
/usr/ports/textproc/libxml2
# make -VPKGNAME
libxml2-2.7.8_1
# make install clean
[...]
# pkg_info -IX libxml2
libxml2-2.7.8_1 XML parser library for GNOME
# pkg_info -g libxml2-2.7.8_1
Information for libxml2-2.7.8_1:

Mismatched Checksums:
pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist


Hints and/or pointers welcome.

MfG CoCo


Yes, it looks like WITH_FBSD10_FIX=yes doesn't works here.
You may rebuild it with UNAME_r=9.9-CURRENT until the working fix will 
not be committed.


This doesn't seem to do the trick for me:

# echo $SHELL
/bin/csh
# setenv UNAME_r 9.9-CURRENT
# echo $UNAME_r
9.9-CURRENT
# cd /usr/ports/textproc/libxml2
# make install clean
[...]
# pkg_info -g libxml2-2.7.8_1
Information for libxml2-2.7.8_1:

Mismatched Checksums:
pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist

Am I doing something wrong here ?

MfG CoCo

___
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: textproc/libxml2 does not install libxml2.so.5

2011-10-31 Thread b. f.

 Mismatched Checksums:
 pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
 pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
 pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist


 Hints and/or pointers welcome.
It works for me correctly

http://tb.smeets.im/tb/index.php?action=display_markup_logbuild=10-FreeBSDid=24#1000

Yes, but in a tinderbox -- this is the same problem I used in the
example from my message to you and the others a few hours ago.  The
FreeBSD 10 fix is triggering refresh builds of the autotools-related
parts of the port after changing the modification time of libtool.m4,
and breaking the build, when some autotools ports are already
installed on the system before rebuilding. There are a number of ways
to circumvent the problem, but a full rebuild is unlikely to help by
itself.

b.
___
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: textproc/libxml2 does not install libxml2.so.5

2011-10-31 Thread b. f.


 This doesn't seem to do the trick for me:

 # echo $SHELL
 /bin/csh
 # setenv UNAME_r 9.9-CURRENT
 # echo $UNAME_r
 9.9-CURRENT
 # cd /usr/ports/textproc/libxml2
 # make install clean
 [...]
 # pkg_info -g libxml2-2.7.8_1
 Information for libxml2-2.7.8_1:

 Mismatched Checksums:
 pkg_info: /usr/local/etc/xml2Conf.sh doesn't exist
 pkg_info: /usr/local/lib/libxml2.so.5 doesn't exist
 pkg_info: /usr/local/libdata/pkgconfig/libxml-2.0.pc doesn't exist

 Am I doing something wrong here ?


Yes, you are trusting us. ;) There are a few problems related to the
FreeBSD 10 fix that are still being worked out.  Whether or not the
FreeBSD 10 fix is used depends on OSVERSION, which is calculated in
bsd.port.mk, so your masquerading is incomplete:


   1192 .if !defined(OSVERSION)
   1193 .if exists(/usr/include/sys/param.h)
   1194 OSVERSION!= ${AWK}
'/^\#define[[:blank:]]__FreeBSD_version/ {print $$3}' 
/usr/include/sys/param.h
   1195 .elif exists(${SRC_BASE}/sys/sys/param.h)
   1196 OSVERSION!= ${AWK}
'/^\#define[[:blank:]]__FreeBSD_version/ {print $$3}' 
${SRC_BASE}/sys/sys/param.h
   1197 .else
   1198 OSVERSION!= ${SYSCTL} -n kern.osreldate
   1199 .endif
   1200 .endif
...
   3664 run-autotools-fixup:
   3665 # Work around an issue where FreeBSD 10.0 is detected as
FreeBSD 1.x.
   3666 .if defined(WITH_FBSD10_FIX)  ${OSVERSION} = 100
...

You could edit the __FreeBSD_version line in param.h, or override
OSVERSION on the command-line, setting it less than 100, if you
wanted to continue to masquerade as 9.9 or some other suitable value
while the problems are being resolved.

b.
___
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/162049: The Ports tree lacks a framework to restart services

On 31 October 2011 12:30, Miroslav Lachman 000.f...@quip.cz wrote:
Dominic Fandrey wrote:

On 31/10/2011 09:37, Doug Barton wrote:

On 10/31/2011 00:38, Dominic Fandrey wrote:

On 31/10/2011 07:28, Doug Barton wrote:

On 10/27/2011 09:27, Scott Lambert wrote:

On Thu, Oct 27, 2011 at 11:15:00AM +0200, Ed Schouten wrote:

What really bothers me when I use the FreeBSD Ports tree on one of my
systems, is that the behaviour of dealing with services is quite
inconsistent.

I think Scott's on the right track. The way that I envision it working
would be a 3-knob system. One knob to always restart the services, one
to never do it; and then asking on a per-port basis, which should be
the
default. I can imagine portmaster detecting this option in the
pre-build
phase similarly to how it detects and warns about IS_INTERACTIVE now,
and giving the user a menu of options for how to handle it. I'm happy
to
add more details if people are interested.

I think this should be handled in the pkg-install script. Pkg based
upgrade tools _do_ exist.

Yeah, that's what I said below. :)

Sorry about that, I read the entire thread in one go, might have
overlooked
something. Ironic, because the purpose was to avoid posting redundant
feedback.

Note the Porters' Handboock chapter 6.23.1. The knob to stop services is
already there.

That feature as it exists currently isn't even close to adequate, and is
causing more problems than it solves. Hence the discussion.

Yes, and even if I would like to have possibility to restart some services
after upgrade, I really hate this knob to just stop the service and leave it
stopped. Can somebody add global knob to override this from make.conf?

Well, I am one of the people who see no need for this feature and my vote
is for default off, if it's implemented.

I agree with default off.

I just wanted to hint that such a function is already in place and I don't
think it would be difficult to add the possibility to start a service.

http://www.freebsd.org/cgi/cvsweb.cgi/ports/sysutils/automounter/pkg-message?rev=1.2;content-type=text%2Fplain

And that's why I propossed more general user scriptable hooks for
before/after deinstall - install - upgrade actions. (It is on Doug's
portmaster proposal list http://dougbarton.us/portmaster-proposal.html)
Sometimes sysadmin needs more than just restart of the upgraded service.
Sometimes we need to restart other service as well, or run some test script,
send an alert, or for example change some file/directory permissions - real
example is courier-authdaemon when used with Postfix for SMTP auth, we must
change permissions of socket dir on each upgrade.

For me, it would be nice to be able to define functions with whatever
content executed on particular action.

short example:

I agree that whatever will be implemented as a result of this discussion, it
should be optional feature off by default and ports system should not
silently stop / restart / start services.

Yeah... though I've just remember the BIG reason I never wrote code
for this; pkg_add etc doesn't read or care about /etc/make.conf, so it
has no way of understanding whether to restart the service or not.

Any time we ever add features like this, they're added as @exec lines
etc to the packages, and unless we want to (undesirably IMO) be
grepping make.conf in @exec plist lines,

An intruiging INDEX problem -- slave ports + make.conf KNOBS

Hey all,

Apparently if you define something in make.conf that slave ports also
define, then a generated INDEX becomes useless...

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/162088

Basically, jpeg2ps-a4 -slave port of- jpeg2ps-letter which defines
A4=yes, and turns jpeg2ps into jpeg2ps-a4, thus duplicating INDEX
records. Unfortunately, the master port is indexed first, so
jpeg2ps-a4 is left with an incorrect origin...

Does anyone have any clever ideas around this?

Chris
___
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: gstat collision between sysutils/coreutils and base gstat

On 31 October 2011 15:18, Wesley Shields w...@freebsd.org wrote:
 On Mon, Oct 31, 2011 at 09:21:26AM +, Chris Rees wrote:
 Hey all,

 Traditionally we've tended to use the 'g' prefix for GNU utilities;
 gmake, gtar etc, but apparently with stat that is a problem [1], due
 to the different gstat utility in base.

 I'm reluctant to simply rename the coreutils to gnu- prefixes, because
 that would upset quite a lot of things!

 We either need to:

 1) Rename to coreutils to gnu- like most of the rest of the non-GNU
 world and deal with the breakage (!)
 2) Make gstat an OPTION, off by default
 3) Be horribly inconsistent and rename gstat to gnustat

 I don't know if 3 is as horribly inconsistent as you think: misc/gnuls
 installs the GNU version of ls as gnuls.

Which would then introduce another conflict; coreutils installs gls :(

Would anyone yell too much if I _just_ changed gstat to gnustat? It
could be a little 'quirk'...

Chris
___
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: An intruiging INDEX problem -- slave ports + make.conf KNOBS

2011-10-31 Thread Matthew Seaman

On 31/10/2011 17:39, Chris Rees wrote:
 Apparently if you define something in make.conf that slave ports also
 define, then a generated INDEX becomes useless...
 
 http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/162088
 
 Basically, jpeg2ps-a4 -slave port of- jpeg2ps-letter which defines
 A4=yes, and turns jpeg2ps into jpeg2ps-a4, thus duplicating INDEX
 records. Unfortunately, the master port is indexed first, so
 jpeg2ps-a4 is left with an incorrect origin...
 
 Does anyone have any clever ideas around this?

One or two.  The generic code for building the INDEX treats this as an
error, but I don't see why that should be so.  Either you decide that
the package name column (the 1st column) should be the unique entry in
the INDEX and so you drop any duplicates, or you decide that the second
column -- directory path of the port -- should be the unique field.

The second option there makes more sense to me, as it better reflects
reality: with certain make variable settings there will be two or more
directories within the ports tree where building the port will result in
installing exactly the same port.  However the assumption made by most
of the software that interacts with the INDEX is that the first column
is the unique key.

Any way, my ports-mgmt/p5-FreeBSD-Portindex code will generate an INDEX
file for you despite this sort of collision.  By default it operates to
make the first column the unique key, but that can be very easily
changed if wanted.

Cheers,

Matthew

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



signature.asc
Description: OpenPGP digital signature

Re: gstat collision between sysutils/coreutils and base gstat

2011-10-31 Thread Eitan Adler

On Mon, Oct 31, 2011 at 1:43 PM, Chris Rees utis...@gmail.com wrote:

 Would anyone yell too much if I _just_ changed gstat to gnustat?


Probably, but you should ignore them. ;)


-- 
Eitan Adler
___
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

innotop-1.8.0_2 and mytop-1.6_7 cannot be installed together

2011-10-31 Thread Miroslav Lachman


Hi,

I tried to install innotop and mytop together by portmaster command:

portmaster databases/mytop databases/innotop

=== The following actions will be taken if you choose to proceed:
Install databases/mytop
Install databases/p5-DBD-mysql
Install databases/p5-DBI
Install devel/p5-Term-ReadKey
Install databases/innotop
Install databases/p5-DBD-mysql51

As you can see, there is problem with conflicting dependencies: 
p5-DBD-mysql vs. p5-DBD-mysql51


The portmaster installed p5-DBD-mysql and mytop first, then innotop 
installation failed with:


===  p5-DBD-mysql51-4.019 conflicts with installed package(s):
  p5-DBD-mysql-4.019

  They will not build together.
  Please remove them first with pkg_delete(1).


If innotop is installed separately first (with it's dependency 
p5-DBD-mysql51), then mytop will install OK and will use p5-DBD-mysql51 
instead of default p5-DBD-mysql.


I am not sure, what port should be changed in what way.

mytop uses:

${SITE_PERL}/${PERL_ARCH}/DBD/mysql.pm:${PORTSDIR}/databases/p5-DBD-mysql

innotop:

p5-DBD-mysql${MYSQL_VER}=1:${PORTSDIR}/databases/p5-DBD-mysql${MYSQL_VER}


I installed them without problems in the past.

Miroslav Lachman
___
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

Radeon KMS [was Re: KWin no longer compositing?]

2011-10-31 Thread Peter Jeremy

On 2011-Oct-29 12:34:11 +0300, Kostik Belousov kostik...@gmail.com wrote:
I think 3-4 months is the reasonable estimation for bringing up both
TTM/execution and KMS for radeons. The KMS infrastructure is already
ported.

If somebody is interested in doing the Radeon driver proper, I may port
TTM.

I'm also interested in this.  Can you give some indication as to what
is involved?

-- 
Peter Jeremy


pgpQ8zu9OSA2o.pgp
Description: PGP signature

Re: innotop-1.8.0_2 and mytop-1.6_7 cannot be installed together

2011-10-31 Thread Steven Kreuzer

Hi Miroslav-

On Oct 31, 2011, at 3:59 PM, Miroslav Lachman wrote:

 Hi,
 
 I tried to install innotop and mytop together by portmaster command:
 
 portmaster databases/mytop databases/innotop
 
 === The following actions will be taken if you choose to proceed:
Install databases/mytop
Install databases/p5-DBD-mysql
Install databases/p5-DBI
Install devel/p5-Term-ReadKey
Install databases/innotop
Install databases/p5-DBD-mysql51
 
 As you can see, there is problem with conflicting dependencies: p5-DBD-mysql 
 vs. p5-DBD-mysql51
 
 The portmaster installed p5-DBD-mysql and mytop first, then innotop 
 installation failed with:
 
 ===  p5-DBD-mysql51-4.019 conflicts with installed package(s):
  p5-DBD-mysql-4.019
 
  They will not build together.
  Please remove them first with pkg_delete(1).
 
 
 If innotop is installed separately first (with it's dependency 
 p5-DBD-mysql51), then mytop will install OK and will use p5-DBD-mysql51 
 instead of default p5-DBD-mysql.
 

Can you apply this patch to mytop and try one more time. 
http://exit2shell.com/~skreuzer/patches/mytop.patch

Thanks

___
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

giving up maintainership for all my ports

2011-10-31 Thread Russell Jackson


These are all up for grabs.

sysutils/puppet
textproc/augeas
textproc/rubygem-augeas
sysutils/mcollective

--
Russell A. Jackson r...@csub.edu
Network Analyst
California State University, Bakersfield
___
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: giving up maintainership for all my ports

2011-10-31 Thread Steve Wills

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 10/31/11 17:45, Russell Jackson wrote:
 These are all up for grabs.
 
 sysutils/puppet
 textproc/augeas
 textproc/rubygem-augeas
 sysutils/mcollective
 

I've taken sysutils/puppet and sysutils/mcollective.

Thanks, hope to see you back soon!
Steve
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (FreeBSD)

iQEcBAEBAgAGBQJOryMnAAoJEPXPYrMgexuhKPkH/2TjCVS+y1GnTJ2DttN2dtgI
OWhtIosb6D1oGjcKZL+D7WZBMuz99aPfVUfbY5T+9VX3QDxbj4uqkmc02s+u051E
Wx5VvUy9/ePTUDv4n0xx+nqJjYMoNJfBlotJSZSXBQC0AHBUbYBXMKdFK23HqRmc
0nz5dISfM4mtLpETJs6ouCr+ZXxV7VQCRx39beYgJNaO6slVtumNbeFaalWmkBJO
OIgI8EFuTOa2CXCryYI4Dsjc2bls+3MPqbHgHgkvChNjrw47ggYrcTrR56BE+9o2
mVhlTPnQnKYL9lnn0/FE4L1LP7uLhqJJ6vLnLsjdosXB+O1eypkZC6/FIY/TxE4=
=ST+/
-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: innotop-1.8.0_2 and mytop-1.6_7 cannot be installed together

2011-10-31 Thread Miroslav Lachman


Steven Kreuzer wrote:

Hi Miroslav-

On Oct 31, 2011, at 3:59 PM, Miroslav Lachman wrote:


Hi,

I tried to install innotop and mytop together by portmaster command:

portmaster databases/mytop databases/innotop

===  The following actions will be taken if you choose to proceed:
Install databases/mytop
Install databases/p5-DBD-mysql
Install databases/p5-DBI
Install devel/p5-Term-ReadKey
Install databases/innotop
Install databases/p5-DBD-mysql51

As you can see, there is problem with conflicting dependencies: p5-DBD-mysql 
vs. p5-DBD-mysql51

The portmaster installed p5-DBD-mysql and mytop first, then innotop 
installation failed with:

===   p5-DBD-mysql51-4.019 conflicts with installed package(s):
  p5-DBD-mysql-4.019

  They will not build together.
  Please remove them first with pkg_delete(1).


If innotop is installed separately first (with it's dependency p5-DBD-mysql51), 
then mytop will install OK and will use p5-DBD-mysql51 instead of default 
p5-DBD-mysql.



Can you apply this patch to mytop and try one more time. 
http://exit2shell.com/~skreuzer/patches/mytop.patch


No it doesn't work.

I found that ${MYSQL_VER} is set in bsd.database.mk but it is not 
included unless Makefile has USE_MYSQL=yes.


It is in bsd.port.mk:

.if defined(USE_MYSQL) || defined(WANT_MYSQL_VER) || \
defined(USE_PGSQL) || defined(WANT_PGSQL_VER) || \
defined(USE_BDB) || defined(USE_SQLITE) || defined(USE_FIREBIRD)
.include ${PORTSDIR}/Mk/bsd.database.mk
.endif


It works with the following patch:

--- Makefile.orig   2010-01-29 05:56:57.0 +0100
+++ Makefile2011-10-31 23:22:15.0 +0100
@@ -7,14 +7,16 @@

 PORTNAME=  mytop
 PORTVERSION=   1.6
-PORTREVISION=  7
+PORTREVISION=  8
 CATEGORIES=databases
 MASTER_SITES=  http://jeremy.zawodny.com/mysql/mytop/

 MAINTAINER=m.sea...@infracaninophile.co.uk
 COMMENT=   A top clone for MySQL

-RUN_DEPENDS= 
${SITE_PERL}/${PERL_ARCH}/DBD/mysql.pm:${PORTSDIR}/databases/p5-DBD-mysql \

+USE_MYSQL=yes
+
+RUN_DEPENDS= 
${SITE_PERL}/${PERL_ARCH}/DBD/mysql.pm:${PORTSDIR}/databases/p5-DBD-mysql${MYSQL_VER} 
\

p5-DBI=1.13:${PORTSDIR}/databases/p5-DBI \
p5-Term-ReadKey=2.10:${PORTSDIR}/devel/p5-Term-ReadKey


The port will have following dependencies

# ports_tree.sh databases/mytop
databases/mytop
databases/mysql51-client
databases/p5-DBD-mysql51
databases/mysql51-client
databases/p5-DBI
lang/perl5.8
lang/perl5.8
databases/p5-DBI
lang/perl5.8
devel/p5-Term-ReadKey
lang/perl5.8
lang/perl5.8

Innotop Makefile also has USE_MYSQL=yes (but I am not sure, if it is the 
right way - I am not ports maintainer)


Miroslav Lachman
___
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

Update for editors/libreoffice-3.4.3_2 failed

2011-10-31 Thread Leslie Jensen



Hi

I need help to solve this. Has anyone seen this error?

Thanks

/Leslie





[ build DEP ] LNK:Library/libswfb.so
[ build DEP ] LNK:Library/libmswordfb.so
[ build LOG ] sw
sw deliver
deliver -- version: 275594
Module 'sw' delivered successfully. 1 files copied, 0 files unchanged

---
Oh dear - something failed during the build - sorry !
  For more help with debugging build errors, please see the section in:
http://wiki.documentfoundation.org/Development

  internal build errors:

ERROR: error 65280 occurred while making 
/usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.3.2/sdext/source/pdfimport/xpdfwrapper


 it seems that the error is inside 'sdext', please re-run build
 inside this module to isolate the error and/or test your fix:
---

rm -Rf 
/usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.3.2/sdext/unxfbsd.pro 
# optional module 'clean'

/usr/local/bin/bash
cd /usr/ports/editors/libreoffice/work/libreoffice-bootstrap-3.4.3.2
source ./FreeBSDAMDEnv.Set.sh
cd sdext
build

when the problem is isolated and fixed exit and re-run 'make' from the 
top-level

gmake: *** [all] Fel 1
*** Error code 1

Stop in /usr/ports/editors/libreoffice.
*** Error code 1

Stop in /usr/ports/editors/libreoffice.

=== make failed for editors/libreoffice
=== Aborting update

=== Update for editors/libreoffice failed
=== Aborting update

___
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

poppler-gtk-0.16.7

2011-10-31 Thread Leslie Jensen



I get

pkg_version -vIL=
poppler-gtk-0.16.7  !   Comparison failed


portmaster --check-depends

Checking poppler-gtk-0.16.7
=== /usr/ports/graphics/poppler-gtk does not exist
=== This port should probably be updated


pkg_delete poppler-gtk-0.16.7
pkg_delete: package 'poppler-gtk-0.16.7' is required by these other packages
and may not be deinstalled:
gimp-app-2.6.11_4,1
squeeze-0.2.3_2
xfce4-appfinder-4.8.0_1
xfce-4.8
gimp-gutenprint-5.2.7
Thunar-1.2.3
xfce4-desktop-4.8.3

No mention in /usr/ports/UPDATING


What should I do to make this right?

Thanks

/Leslie

___
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: poppler-gtk-0.16.7

On 10/31/2011 16:06, Leslie Jensen wrote:
 
 I get
 
 pkg_version -vIL=
 poppler-gtk-0.16.7  !   Comparison failed
 
 
 portmaster --check-depends
 
 Checking poppler-gtk-0.16.7
 === /usr/ports/graphics/poppler-gtk does not exist
 === This port should probably be updated
 
 
 pkg_delete poppler-gtk-0.16.7
 pkg_delete: package 'poppler-gtk-0.16.7' is required by these other
 packages
 and may not be deinstalled:
 gimp-app-2.6.11_4,1
 squeeze-0.2.3_2
 xfce4-appfinder-4.8.0_1
 xfce-4.8
 gimp-gutenprint-5.2.7
 Thunar-1.2.3
 xfce4-desktop-4.8.3
 
 No mention in /usr/ports/UPDATING
 
 
 What should I do to make this right?

portmaster -o graphics/poppler-glib poppler-gtk-0.16.7

did it for me. I agree that a mention in UPDATING is probably warranted.


Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.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

Ports not mentioned in their category's Makefile

2011-10-31 Thread Conrad J. Sabatier

I've generated a list of 57 ports that are not mentioned in the
Makefiles for their respective categories.  Before I do anything more
with this information (like submit patches), though, I just wanted to
check to see if there's any interest in correcting this.

For one thing, these omissions cause the README.html files to be
incomplete, which alone, I think, warrants fixing this.

Thanks for any feedback.

-- 
Conrad J. Sabatier
conr...@cox.net
___
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/162049: The Ports tree lacks a framework to restart services

On 10/31/2011 03:41, Dominic Fandrey wrote:

 What has to be done after an update is often very specific, though.

That's why I proposed that there should be a knob for the port
maintainer to include the standard version of the script, or not. If
there are more heavily customized things that need to be done for the
particular service than a custom pkg-install/pkg-deinstall script is
going to be needed.


Doug

-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.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

Re: ports/162049: The Ports tree lacks a framework to restart services

2011-10-31 Thread Scott Lambert

On Mon, Oct 31, 2011 at 01:30:55PM +0100, Miroslav Lachman wrote:
 For me, it would be nice to be able to define functions with whatever 
 content executed on particular action.
 
 short example:
 
 function_called_after_upgrade_of_authdaemon() {
 send notice to operator or write something to logfile
 chmod 0755 /var/run/authdaemond
 restart authdaemon
 execute self-test script to check SMTP auth is working
 }
 
 This in general is more useful than just call restart on installed rc.d 
 script, but ofcourse, it is more complex task to implement and I am not 
 sure, if it should be in ports or in some utility like portmaster.

Would something like the above in the port's rc.d/daemonscript
simplify things for the packages part of the problem space?

If the rc.d scripts had support for an upgrade option that defaulted
to doing nothing if the porter didn't put an upgrade function in
his/her ports rc.d/daemonscript, the package scripts and ports
infrastructure could unconditionally call rc.d/daemonscript upgrade.

Then control of whether or not to do automatic upgrades could be
in /etc/rc.conf right below the daemon_enable=YES.  

daemon_autoupgrade=NO   # Let the port's rc.d script automagically
# handle needed config changes and stop /
# restart the daemon when upgraded from pkgs or
# ports?

Maybe with a big default cover knob?

autoupgrade_default=NO  # default to allowing ports / pkg tools to
# auto restart daemons and / or upgrade
# daemon configurations/databases/...

Would that be a way to make use of our existing automation / config
store infrastructure?  

This would leave the complex logic for each port in the hands of
the porters who are most likely to know what corner cases need to
be treated with care.  Individual porters could automate as much
as they want.  Look at what depends on the current package, say PHP
since it was mentioned before, and see which if any web servers
might need to be restarted, then call the web server's rc.d/daemonscript
(upgrade|restart) as may be appropriate.

Of course, PHP probably won't have a php5_enable=YES in /etc/rc.conf.
But you could still have:

php5_autoupgrade=(YES|NO|WARN|EMAILUPGRADESCRIPTTOADMIN|...)

That could lead to a proliferation of rc.d/scripts which don't
actually control daemons.  That might not be a good thing.  Maybe
using the rc.d scripts is a bad idea?

-- 
Scott LambertKC5MLE   Unix SysAdmin
lamb...@lambertfam.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

Re: innotop-1.8.0_2 and mytop-1.6_7 cannot be installed together

2011-10-31 Thread Matthew Seaman

On 31/10/2011 19:59, Miroslav Lachman wrote:
 Hi,
 
 I tried to install innotop and mytop together by portmaster command:
 
 portmaster databases/mytop databases/innotop
 
 === The following actions will be taken if you choose to proceed:
 Install databases/mytop
 Install databases/p5-DBD-mysql
 Install databases/p5-DBI
 Install devel/p5-Term-ReadKey
 Install databases/innotop
 Install databases/p5-DBD-mysql51
 
 As you can see, there is problem with conflicting dependencies:
 p5-DBD-mysql vs. p5-DBD-mysql51
 
 The portmaster installed p5-DBD-mysql and mytop first, then innotop
 installation failed with:
 
 ===  p5-DBD-mysql51-4.019 conflicts with installed package(s):
   p5-DBD-mysql-4.019
 
   They will not build together.
   Please remove them first with pkg_delete(1).
 
 
 If innotop is installed separately first (with it's dependency
 p5-DBD-mysql51), then mytop will install OK and will use p5-DBD-mysql51
 instead of default p5-DBD-mysql.
 
 I am not sure, what port should be changed in what way.
 
 mytop uses:
 
 ${SITE_PERL}/${PERL_ARCH}/DBD/mysql.pm:${PORTSDIR}/databases/p5-DBD-mysql
 
 innotop:
 
 p5-DBD-mysql${MYSQL_VER}=1:${PORTSDIR}/databases/p5-DBD-mysql${MYSQL_VER}
 
 
 I installed them without problems in the past.
 
 Miroslav Lachman

I've never really understood the point of all those slave ports that
tack the MySQL version onto the port name.  The generic p5-DBD-mysql
port works with any version of MySQL and in fact installs pretty much
exactly the same files as the explicitly versioned port for whatever
version of mysql-client is on your system.  Or in other words, as far as
mytop is concerned it will work with whatever one of those p5-DBD-mysql
ports is already installed, so just install innotop first.

Cheers,

Matthew

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



signature.asc
Description: OpenPGP digital signature

Re: Ports not mentioned in their category's Makefile

2011-10-31 Thread Eitan Adler

On Mon, Oct 31, 2011 at 7:20 PM, Conrad J. Sabatier conr...@cox.net wrote:

 I've generated a list of 57 ports that are not mentioned in the
 Makefiles for their respective categories.  Before I do anything more
 with this information (like submit patches), though, I just wanted to
 check to see if there's any interest in correcting this.


Please  send the list to po...@freebsd.org. Keep in mind that some ports
not listed may have been incomplete or aborted repocopies.  There is no
need to send patches, the fix is easy enough ;)



-- 
Eitan Adler
___
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

Ports missing in their categories' Makefiles

2011-10-31 Thread Conrad J. Sabatier

OK, the list is actually smaller than I had mentioned earlier.  My
first list included ports not mentioned in the categories' README.html
files as well, which of course, generated a bogus list.

Here's the final list I got:

astro/weatherget
audio/x11amp
databases/pgpool-II-30
devel/boost-pyste
devel/gccxml
devel/py-myghtyutils
devel/py-reverse
devel/py-vmaps
games/xshisen
graphics/gnash-devel
graphics/tkimg
graphics/tumbler
japanese/dvi2tty
japanese/plain2
java/java-tutorial
lang/smarteiffel
net-p2p/transmisson-remote-gui
sysutils/syslog-ng1
www/myghty
www/linux-f10-flashplugin11
www/tomcat41
www/typo345
x11-drivers/xf86-video-intel29
x11-wm/cl-stumpwm
x11-wm/fvwm2-devel

-- 
Conrad J. Sabatier
conr...@cox.net
___
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 missing in their categories' Makefiles

Are you sure your ports tree is up to date? The first few ports you
listed don't check out ...

On 10/31/2011 17:56, Conrad J. Sabatier wrote:
 OK, the list is actually smaller than I had mentioned earlier.  My
 first list included ports not mentioned in the categories' README.html
 files as well, which of course, generated a bogus list.
 
 Here's the final list I got:
 
 astro/weatherget

Doesn't seem to exist?

 audio/x11amp

Has CATEGORIES= audio

 databases/pgpool-II-30

Has CATEGORIES= databases

 devel/boost-pyste
 devel/gccxml
 devel/py-myghtyutils
 devel/py-reverse
 devel/py-vmaps
 games/xshisen
 graphics/gnash-devel
 graphics/tkimg
 graphics/tumbler
 japanese/dvi2tty
 japanese/plain2
 java/java-tutorial
 lang/smarteiffel
 net-p2p/transmisson-remote-gui
 sysutils/syslog-ng1
 www/myghty
 www/linux-f10-flashplugin11
 www/tomcat41
 www/typo345
 x11-drivers/xf86-video-intel29
 x11-wm/cl-stumpwm
 x11-wm/fvwm2-devel
 



-- 

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.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

Re: Ports missing in their categories' Makefiles