Keyboard problems with xorg 7.2 and Dell Inspiron 5100?
I've just upgraded my Inspiron 5100 to the latest and greatest X.org release, 7.2. Using the standard configuration options (either no config file, or the one generated by X -configure), most keys on the keyboard don't react. I've ran xev against the server and find that the only keys that react are the modifier keys. The same machine runs fine with Knoppix 5.2, which has X.org 7.1.1, and it ran fine under FreeBSD with a previous version of X.org 6.9.mumble. Looking at the log file, nothing obvious reaches out and grabs me. In particular, the keyboard-related information corresponds exactly with the Knoppix log file (modulo keyboard layout). Has anybody else seen this? Any ideas? Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html See complete headers for address and phone numbers. pgp143RmILow3.pgp Description: PGP signature
Slightly faster make all-depends-list
Here is a C program that does the same as make all-depends-list but runs four threads at once. I get small time increases on a regular computer, and twice the speed on dual processor systems. e.g. all-depends-list /usr/ports/x11/xorg ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Slightly faster make all-depends-list
Stephen Montgomery-Smith wrote: Here is a C program that does the same as make all-depends-list but runs four threads at once. I get small time increases on a regular computer, and twice the speed on dual processor systems. e.g. all-depends-list /usr/ports/x11/xorg The attachment didn't take. Here it is: http://www.math.missouri.edu/~stephen/all-depends-list.c ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Keyboard problems with xorg 7.2 and Dell Inspiron 5100?
On Mon, May 28, 2007 at 15:47:39 +0930, Greg 'groggy' Lehey wrote: Looking at the log file, nothing obvious reaches out and grabs me. In particular, the keyboard-related information corresponds exactly with the Knoppix log file (modulo keyboard layout). Has anybody else seen this? Any ideas? I've got this problem with my IBM T41 (discussed in -x11 and -mobile) and my solution is add an ENV VAR XKEYSYMDB=/usr/local/share/X11/XKeysymDB hope this helps :) -- self-producing in perl : $_=q(print\$_=q($_);eval;);eval; -- V Vinay pgpfRKiJKshJm.pgp Description: PGP signature
Re: Looking for speed increases in make index and pkg_version for ports
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. pkg_version is one thing -- but to build the INDEX you need to extract at least the values of the following variables: PKGNAME .CURDIR PREFIX COMMENT DESCR MAINTAINER CATEGORIES EXTRACT_DEPENDS PATCH_DEPENDS FETCH_DEPENDS BUILD_DEPENDS RUN_DEPENDS LIB_DEPENDS Plus you need to grep in the referenced pkg-descr file for any WWW links. I also extract the values of: MASTER_PORT .MAKEFILE_LIST SUBDIR for my FreeBSD::Portindex stuff. Trouble is, by the time you've extracted all that lot, you have pretty much done the same level of variable processing as you would were you actually going to build the port. One thing that would speed up this process would be a make option to just do parsing of the Makefile and variable expansion, without calling stat(2) on all the various sources and dependencies involved. For instance: happy-idiot-talk:...ports/databases/mysql-connector-java:% truss make -V PKGNAME | grep stat | wc -l 49 It is quite instructive to see what files make(1) touches while doing that. At least half of them are irrelevant if all make(1) is going to do is print out the values of some variables. Multiply that by 17,000 and it adds up to a big waste of effort. 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGWpTA8Mjk52CukIwRCI0BAJ0bX5hTAJkMCO6Pl+cA4THv3mKulwCgg+39 kCyAGOTYYz9vEzzM9NRe3no= =MqFV -END PGP SIGNATURE- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
can't cd to...
Hi, I have a problem with lots of ports. ex: /usr/ports/game/gnome-games/ # make install clean make all-recursive Making all in po cd: can't cd to po *** Error code 1 Stop in /usr/ports/game/gnome-games/work/gnome-games-2.18.1. This problem is in lots of ports and in my 'autotools' projects. So, where is the bug ? Thanks You ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
can't cd to...
Hi, I have a problems with lots of ports. Ex in gnome-games : #make install clean make all-recursive make all in po cd: can't cd to po *** Error code 1 Stop in /usr/ports/games/gnome-games/work/gnome-games-2.18.1 I have this problem with lots of ports and to my 'autotools' too. the 'cd' doesn't work. But not all, today, xorg-lib. update correctly Where is the bug please ?? Thanks you ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Possibly unbuildable ports reminder
Dear porters, This is just a reminder to please periodically check the list of unbuildable ports at http://pointyhat.freebsd.org/errorlogs/ . A list by MAINTAINER is http://people.freebsd.org/~fenner/errorlogs/ so you can easily check the status of ports that you maintain. In addition, the list of ports with no MAINTAINER with build problems is http://people.freebsd.org/~fenner/errorlogs/[EMAIL PROTECTED] Since no one is responsible for these ports, the problem won't get fixed unless someone on this list takes the initiative. Thanks for your help! Bill annoying port email Fenner ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nagios in current
On 28/05/2007, at 3:44 AM, Randy Bush wrote: bingo! my error. i run a special version of bind and had not rebuilt. Sorry for my lapse. No worries Randy, glad it all worked out in the end. By the way, net- mgmt/nagios-plugins was just updated to 1.4.8. Jarrod. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Matthew Seaman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. pkg_version is one thing -- but to build the INDEX you need to extract at least the values of the following variables: PKGNAME .CURDIR PREFIX COMMENT DESCR MAINTAINER CATEGORIES EXTRACT_DEPENDS PATCH_DEPENDS FETCH_DEPENDS BUILD_DEPENDS RUN_DEPENDS LIB_DEPENDS Plus you need to grep in the referenced pkg-descr file for any WWW links. I also extract the values of: MASTER_PORT .MAKEFILE_LIST SUBDIR for my FreeBSD::Portindex stuff. Trouble is, by the time you've extracted all that lot, you have pretty much done the same level of variable processing as you would were you actually going to build the port. One thing that would speed up this process would be a make option to just do parsing of the Makefile and variable expansion, without calling stat(2) on all the various sources and dependencies involved. For instance: happy-idiot-talk:...ports/databases/mysql-connector-java:% truss make -V PKGNAME | grep stat | wc -l 49 It is quite instructive to see what files make(1) touches while doing that. At least half of them are irrelevant if all make(1) is going to do is print out the values of some variables. Multiply that by 17,000 and it adds up to a big waste of effort. Are you sure? A good deal of the stats() is make poking around for the make infrastructure. This should be in the cache. And there are a couple of stats for the *done* files that might be avoided by doing something in the ports infrastructure. But as I already said in my previous mail: numbers, please, no guessing. harti ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I suggest rewriting make so that variables are only evaluated on a need to know basis. So, for example, if all we need to know is PKGNAME, there is no need to evaluate, for example, _RUN_LIB_DEPENDS, unless the writer of that particular port has done something like having PORTNAME depend on the value of _RUN_LIB_DEPENDS. So make should analyze all the code it is given, and only figure it out if it is needed to do so. This would include, for example, figuring out .for and .if directives on a need to know basis as well. I have only poked around a little inside the source for make, but I have a sense that this would be a major undertaking. I certainly have not thought through what it entails in more than a cursory manner. However I am quite excited about the possibility of doing this, albeit I may well put off the whole thing for a year or two or even forever depending upon other priorities in my life. However, in the mean time I want to throw this idea out there to get some feedback, either of the form of this won't work, or of the form I will do it, or I have tried to do this. Having done a great deal of rewriting of make some two years ago I can tell you that even a small change to make is a tough job testing-wise: run all the combinations of !-j and -j N on all architectures and run the change through the port-building cluster. That's a warning to start with. Second I would start with careful profiling to find out where the problem actually is. You might be surprised. As an example: several times the idea came up to use a hash structure instead of linear lists for make variables. I got a patch for this and - it makes absolutely no difference performance-wise (well, there was some indication that performance gets worse, but that was around or below noise level). With careful I mean to find out who takes the time: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. 2. sub-shells executed for executing targets commands (note, that make optimizes the subshells away when there are no special shell symbol in the command line) 3. executed programs (find, sort, ...) Until you have numbers for this everything is rather moot. It might be a good idea to put some performance measurement hooks into make for this to do. If anybody wants to work on make, I would rather recommend to implement %-rules :-) And if anybody wants to recommend gmake over make(1) - look into the code, what mess that is :-/ Regards, harti ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Current unassigned ports problem reports
Current FreeBSD problem reports 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. Bugs can be in one of several states: o - open A problem report has been submitted, no sanity checking performed. a - analyzed The problem is understood and a solution is being sought. f - feedback Further work requires additional information from the originator or the community - possibly confirmation of the effectiveness of a proposed solution. p - patched A patch has been committed, but some issues (MFC and / or confirmation from originator) are still open. r - repocopy The resolution of the problem report is dependent on a repocopy operation within the CVS repository which is awaiting completion. s - suspended The problem is not being worked on, due to lack of information or resources. This is a prime candidate for somebody who is looking for a project to do. If the problem cannot be solved at all, it will be closed, rather than suspended. c - closed A problem report is closed when any changes have been integrated, documented, and tested -- or when fixing the problem is abandoned. Critical problems S Tracker Resp. Description o ports/112754[ports]: VERY SERIOUS security bug in sysutils/eject f ports/112756www/plone update to 2.5.3 for security fix of XSS vuln f ports/112988print/HPLIP portupgrade failure 3 problems total. Serious problems S Tracker Resp. Description o ports/105549ports/www/squid_radius_auth doesn't work on sparc64 o ports/106369vpnd caused kernel panic with ppp mode o ports/106372vpnd can't run with slip mode o ports/107536editors/scite: Can't write on SciTE text editor f ports/108077www/linux-flashplugin9 crashes linux-firefox f ports/108413net/vnc does not works. f ports/108537print/hplip: Build failure f ports/108606Courier MTA terminates abnormaly after installation f ports/108748mod_fcgid 1.10 does not work inside jail f ports/109160net/samba3 crashes freebsd when accessing a share resi f ports/110035Port fix for sysutils/be_agent f ports/110454Joomla port Makefile has incorrect url for package f ports/110943start-dccifd chowns /var/run to user dcc f ports/111012quagga's ripd does not see ng interfaces f ports/51ports/lang/stklos: l/bin/stklos-install is a buggy she o ports/111224[PATCH] security/pam_per_user conflicts with security/ f ports/111338graphics/yafray: doesn't respect CXX, CXXFLAGS and eve o ports/111462syslog-ng2 default configuration file path o ports/111923[PATCH] databases/unixODBC overwrites config file on p f ports/111966Clamav-milter no up f ports/111980multimedia/mplayer: compilation error o ports/112067ports/paraview 2.4.4 does not compile properly f ports/112083mail/qsheff overwrites configuration upon upgrade f ports/112094www/lynx: plist missing configuration file o ports/112097print/ghostscript-gpl-nox11 compile fails due to missi f ports/112118[PATCH] sysutils/pipemeter: fix crashes o ports/112197[MAINTAINER UPDATE]: devel/libstrfunc upgrade to 8.3 f ports/112277MD5 and SHA256 mismatch for science/hdf5 f ports/112287www/rt36: add missed patches for MULTIPLE_INSTANCES o ports/112385sysutils/lookupd on Kernel 64 o ports/112389[MAINTAINER] mail/mailscanner: update to 4.59.4 f ports/112468sysutils/bacula-server 2.0.3 port build fails for sqli o ports/112545print/ghostscript-gpl 8.54 fail without all driver (or o ports/112652net/freeradius: exited on signal 10 when used with sql f ports/112698www/opera's spell-check doesn't work o ports/112739audio/midimountain doesn't work as patched o ports/112793editors/e3 problem: one line patch to fix bad syscall f ports/112921x11-wm/Beryl not loading focus and keybinding settings f ports/112989[PATCH] sysutils/fusefs-kmod is broken with gcc42 f ports/113068net/Samba 3.0.25 broken if force user/force group to l 40 problems total. Non-critical problems S Tracker Resp. Description o ports/94921 isakmpd fails on amd64 o ports/95854 New Port: www/ochusha o ports/100896[new ports] emulators/vmware-server-guestd1 emulators/ o
Re: another qemu-devel port update ready for testing
On Sun, May 27, 2007 at 10:54:15PM +0200, I wrote:
On Sun, May 27, 2007 at 02:03:29PM -0500, Eric Anderson wrote:
On 05/27/07 13:52, Juergen Lock wrote:
On Sun, May 27, 2007 at 12:32:18PM -0500, Eric Anderson wrote:
On 05/27/07 07:58, Juergen Lock wrote:
On Sat, May 26, 2007 at 06:02:06PM -0500, Eric Anderson wrote:
On a recent -CURRENT (with the new GCC):
# make
...
=== Configuring for qemu-devel-0.9.0s.20070526
WARNING: cc looks like gcc 4.x
QEMU is known to have problems when compiled with gcc 4.x
It is recommended that you use gcc 3.x to build QEMU
To use this compiler anyway, configure with --disable-gcc-check
=== Script configure failed unexpectedly.
Please report the problem to [EMAIL PROTECTED] [maintainer] and attach
the
/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-05-26_05/config.log
including the output of the failure of your make command. Also, it
might be
a good idea to provide an overview of all packages installed on your
system
(e.g. an `ls /var/db/pkg`).
*** Error code 1
Stop in /usr/ports/emulators/qemu-devel.
*** Error code 1
Stop in /usr/ports/emulators/qemu-devel.
Hmm that should not happen... Do you have an old version of
bsd.gcc.mk maybe?
Juergen
# $FreeBSD: ports/Mk/bsd.gcc.mk,v 1.12 2007/05/19 22:06:14 pav Exp $
That the right one?
Yeah. Ok probably CONFIGURE_ARGS needs to come after the
bsd.port.pre.mk include for it to pick up the right ${CC}... try this:
Same thing..
Ok we'll have to find out what configure is doing there, use this and
send me the output:
...
s/use/please use/ o_O
This is getting stranger and stranger... I just diff'd this snapshot's
configure script with the one thats in ports and saw nothing relevant,
and the one in ports does build on pointyhat with configure picking up
the right compiler:
http://pointyhat.freebsd.org/errorlogs/i386-7-latest-logs/qemu-devel-0.9.0s.20070405_4.log
So I'd really like to know whats going on there...
Juergen
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Hartmut Brandt wrote: Having done a great deal of rewriting of make some two years ago I can tell you that even a small change to make is a tough job testing-wise: run all the combinations of !-j and -j N on all architectures and run the change through the port-building cluster. That's a warning to start with. Second I would start with careful profiling to find out where the problem actually is. You might be surprised. As an example: several times the idea came up to use a hash structure instead of linear lists for make variables. I got a patch for this and - it makes absolutely no difference performance-wise (well, there was some indication that performance gets worse, but that was around or below noise level). With careful I mean to find out who takes the time: Yes, I must admit that I thought that a hash structure for the variables would greatly increase the speed of make. I rewrote it using Berkeley databases, and like you said - absolutely no difference!! I even tried btrees. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Stephen Montgomery-Smith wrote: Hartmut Brandt wrote: Having done a great deal of rewriting of make some two years ago I can tell you that even a small change to make is a tough job testing-wise: run all the combinations of !-j and -j N on all architectures and run the change through the port-building cluster. That's a warning to start with. Second I would start with careful profiling to find out where the problem actually is. You might be surprised. As an example: several times the idea came up to use a hash structure instead of linear lists for make variables. I got a patch for this and - it makes absolutely no difference performance-wise (well, there was some indication that performance gets worse, but that was around or below noise level). With careful I mean to find out who takes the time: Yes, I must admit that I thought that a hash structure for the variables would greatly increase the speed of make. I rewrote it using Berkeley databases, and like you said - absolutely no difference!! I even tried btrees. My guess at that time was that because there are actually many variable tables (one per target and the global one) and only a small number of variables in most of the tables the initialisation overhead outweights what you win through the hashing. As for the profiling - I did some profiling on buildworld then. From the several hours a buildworld took only one or two minutes were used by all the makes. At this point I stopped optimizing make :-) (I don't remember the exact numbers - that was two or three years ago). harti ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nagios in current
net-mgmt/nagios-plugins was just updated to 1.4.8. will try today (am home from week+ of intl airplanes). have not been very successful with mysql and dhcpd to date, so will definitely try to reenable those. thanks randy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nagios in current
have not been very successful with mysql and dhcpd to date, so will definitely try to reenable those. lol. forgot that the problem with mysql is that i do not have net access to the mysql open to the site which runs nagios. and dhcpd is local net only, of course. ignore me. jet lag and first cuppa. randy ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Multiword command var in rc.d/*.sh script
Good day!
What is the best way to support multiword command var in rc.d scripts?
My current problem is with dns/maradns port which I'm upgrading to use
maradns stock daemonizer instead of | logger hack.
I'd like to specify command var as ${prefix}/bin/duende
${prefix}/sbin/maradns
where duende(8) is the daemonizer. When I do this and use the script
to start maradns I get these two errors:
=
~/work/ports/maradns[0]# /usr/local/etc/rc.d/maradns.sh start
/usr/local/etc/rc.d/maradns.sh: WARNING: $command_interpreter
/usr/local/sbin/maradns != ELF
[: /usr/local/bin/duende: unexpected operator
Starting maradns.
=
This happens because _find_processes() function in /etc/rc.subr splits
${command} and thinks I'm searching for /usr/local/bin/duende
script run via /usr/local/sbin/maradns interpreter.
I cannot set procname var to ${prefix}/bin/duende because there are
other services which will be started via duende.
And _find_processes() is designed to be able to match only first word
from command column of ps(1) output unless the daemon is run via
interpreter.
I implemented some setproctitle(2) hacks inside duende so that it
includes all the relevant information in the first word
(/usr/local/bin/duende_/usr/local/sbin/maradns) but I don't feel
it's ok to fix problems in rc.subr with such dirty tricks.
Thanks for your advices!
--
Alex Kapranoff,
$n=[1another7Perl213Just3hacker49=~/\d|\D*/g];
$$n[0]={grep/\d/,@$n};print@$n{1..4}\n
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. mike Reducing the number of variables will certainly cut down on the amount of overhead in the make/submake context switches by a long shot. Maybe someone should consider running a 'pre-make' using the .mk files, find the variables of interest for all particular sub-ports, and then carry on the 'root make', i.e. make process in each port directory, with just the variables of interest. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Garrett Cooper wrote: Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. mike Reducing the number of variables will certainly cut down on the amount of overhead in the make/submake context switches by a long shot. Maybe someone should consider running a 'pre-make' using the .mk files, find the variables of interest for all particular sub-ports, and then carry on the 'root make', i.e. make process in each port directory, with just the variables of interest. -Garrett s/long shot/possibly a lot/g Also, I was thinking in particular of the X.Org 7.2 packages, because the bulk majority of the packages are smaller, and compile in a short amount of time. -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't build net/rrdtool
Alexey Lebedev wrote: Hello! This is the output of make: I have just committed a fix, would you please try sync'ing your ports tree and try again? (Please confirm that you have the latest files/patch-bindings-Makefile.in: http://www.freebsd.org/cgi/cvsweb.cgi/ports/net/rrdtool/files/patch-bindings-Makefile.in) Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: Instructions for xorg 7.2 upgrade using portmaster
On Sun, 27 May 2007 01:55:37 -0700 Doug Barton [EMAIL PROTECTED] wrote: Please note that if you can do it, the _best_ way to use portmaster to do the upgrade is still to run 'pkg_delete -f xorg*' followed by 'portmaster x11/xorg', Rebuilding Xorg itself is no big deal. After running into problems with portmanager, I deleted not just the xorg* ports, but everthing they depend on too. Putting back the lot only took a couple of hours - only a few percent of the total time to rebuild all the version-bumped ports. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: another qemu-devel port update ready for testing
On Mon, May 28, 2007 at 01:48:26PM +0200, Juergen Lock wrote:
On Sun, May 27, 2007 at 10:54:15PM +0200, I wrote:
On Sun, May 27, 2007 at 02:03:29PM -0500, Eric Anderson wrote:
On 05/27/07 13:52, Juergen Lock wrote:
On Sun, May 27, 2007 at 12:32:18PM -0500, Eric Anderson wrote:
On 05/27/07 07:58, Juergen Lock wrote:
On Sat, May 26, 2007 at 06:02:06PM -0500, Eric Anderson wrote:
On a recent -CURRENT (with the new GCC):
# make
...
=== Configuring for qemu-devel-0.9.0s.20070526
WARNING: cc looks like gcc 4.x
QEMU is known to have problems when compiled with gcc 4.x
It is recommended that you use gcc 3.x to build QEMU
To use this compiler anyway, configure with --disable-gcc-check
=== Script configure failed unexpectedly.
Please report the problem to [EMAIL PROTECTED] [maintainer] and
attach the
/usr/ports/emulators/qemu-devel/work/qemu-snapshot-2007-05-26_05/config.log
including the output of the failure of your make command. Also, it
might be
a good idea to provide an overview of all packages installed on your
system
(e.g. an `ls /var/db/pkg`).
*** Error code 1
Stop in /usr/ports/emulators/qemu-devel.
*** Error code 1
Stop in /usr/ports/emulators/qemu-devel.
Hmm that should not happen... Do you have an old version of
bsd.gcc.mk maybe?
Juergen
# $FreeBSD: ports/Mk/bsd.gcc.mk,v 1.12 2007/05/19 22:06:14 pav Exp $
That the right one?
Yeah. Ok probably CONFIGURE_ARGS needs to come after the
bsd.port.pre.mk include for it to pick up the right ${CC}... try this:
Same thing..
Ok we'll have to find out what configure is doing there, use this and
send me the output:
...
s/use/please use/ o_O
This is getting stranger and stranger... I just diff'd this snapshot's
configure script with the one thats in ports and saw nothing relevant,
and the one in ports does build on pointyhat with configure picking up
the right compiler:
http://pointyhat.freebsd.org/errorlogs/i386-7-latest-logs/qemu-devel-0.9.0s.20070405_4.log
Ok it built on miwi's tb correctly picking up gcc34:
http://miwi.homeunix.com/tb/logs/7.0-HEAD/qemu-devel-0.9.0s.20070526.log
I forgot bin/qemu-system-ppcemb in plist, so below is the update again,
could you try this on your box and look for differences in the configure
log against miwi's? That may tell us whats happening there...
Thx,
Juergen
Index: Makefile
===
RCS file: /home/pcvs/ports/emulators/qemu-devel/Makefile,v
retrieving revision 1.77
diff -u -r1.77 Makefile
--- Makefile19 May 2007 20:04:37 - 1.77
+++ Makefile27 May 2007 20:49:10 -
@@ -6,8 +6,7 @@
#
PORTNAME= qemu
-PORTVERSION= 0.9.0s.20070405
-PORTREVISION= 4
+PORTVERSION= 0.9.0s.20070526
CATEGORIES=emulators
MASTER_SITES= http://qemu.org/:release \
http://qemu-forum.ipi.fi/qemu-snapshots/:snapshot \
@@ -15,11 +14,11 @@
http://www.volny.cz/xnavara/qemu/:snapshot \
http://people.brandeis.edu/~jcoiner/qemu_idedma/:idedma \
http://people.freebsd.org/~maho/qemu/:misc
-DISTNAME= ${PORTNAME}-snapshot-2007-04-05_05
+PKGNAMESUFFIX= -devel
+DISTNAME= ${PORTNAME}-snapshot-2007-05-26_05
DISTFILES= ${DISTNAME}${EXTRACT_SUFX}:snapshot
DIST_SUBDIR= qemu
EXTRACT_ONLY= ${DISTNAME}${EXTRACT_SUFX}
-PKGNAMESUFFIX= -devel
MAINTAINER=[EMAIL PROTECTED]
COMMENT= QEMU CPU Emulator - development snapshot
@@ -31,7 +30,6 @@
USE_PERL5= yes
USE_GCC= 3.4
PATCH_STRIP= -p1
-CONFIGURE_ARGS+= --prefix=${PREFIX} --cc=${CC}
MAKE_ENV+= BSD_MAKE=${MAKE} CFLAGS=${CFLAGS} LDFLAGS=${LDFLAGS}
MAN1= qemu.1 qemu-img.1
ONLY_FOR_ARCHS=amd64 i386
@@ -47,6 +45,7 @@
.include bsd.port.pre.mk
WITHOUT_CPU_CFLAGS=yes #to avoid problems with register allocation
+CONFIGURE_ARGS+= --prefix=${PREFIX} --cc=${CC}
.if defined(WITHOUT_SDL)
CONFIGURE_ARGS+= --disable-sdl --disable-gfx-check
@@ -111,4 +110,19 @@
post-install:
@${CAT} ${PKGMESSAGE}
+# debug:
+do-configure:
+ @(cd ${CONFIGURE_WRKSRC} \
+ if ! ${SETENV} CC=${CC} CXX=${CXX} \
+ CFLAGS=${CFLAGS} CXXFLAGS=${CXXFLAGS} \
+ INSTALL=/usr/bin/install -c ${_BINOWNGRP} \
+ INSTALL_DATA=${INSTALL_DATA} \
+ INSTALL_PROGRAM=${INSTALL_PROGRAM} \
+ INSTALL_SCRIPT=${INSTALL_SCRIPT} \
+ ${CONFIGURE_ENV} ${SH} -x ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS};
then \
+${ECHO_MSG} === Script \${CONFIGURE_SCRIPT}\
failed unexpectedly.; \
+(${ECHO_CMD} ${CONFIGURE_FAIL_MESSAGE}) | ${FMT} 75 79
; \
+${FALSE}; \
+ fi)
+
.include bsd.port.post.mk
Index: distinfo
===
RCS
Re: FreeBSD Port: samba-3.0.25,1
jeje sorry i clicked send before time :D, the mesaage complete is: El lun, 28-05-2007 a las 16:00 -0500, Jose Ayala escribió: Hi, i just to comment a problem with the samba manager script, i dont know really whats the problem but it resolve executing directly the smbd nmbd and winbindd binaries from /usr/local/samba/sbin I install samba3 from ports, all ok, when i execute /usr/local/etc/rc.d/samba start i get the next message: Removing stale Samba tdb files: done and no more: when i stop samba with : /usr/local/etc/rc.d/samba stop , i dont get any message.. after i try with smbstatus and i get one tip for the problem, the message is: sessionid.tdb not initialised /var/db/samba/connections.tdb not initialised This is normal if an SMB client has never connected to your server. Failed to open byte range locking database /var/db/samba/brlock.tdb ERROR: Failed to initialise locking database Can't initialise locking module - exiting so, the trouble is that the tdb files dont was created, y check mi smb.conf file, file and dir permission and all ok. But the script not be able. Later (2 hours later) i tried executing directly smbd nmbd and winbindd files and ohhh sorprise my samba server starting all right, then some happends with the script. Can you do something?? My samba version is Samba version 3.0.25 ,my freebsd version is 6.2 and i updated today my ports with cvsup command before make the install, if you need more information notice me. Best Regards Jose Ayala ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Port: samba-3.0.25,1
Hi, i just to comment a problem with the samba manager script, i dont know really whats the problem but it resolve executing directly the smbd nmbd and winbindd binaries from /usr/local/samba/sbin I install samba3 from ports, all ok, when i execute /usr/local/etc/rc.d/samba start i get the next message: ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. Unfortunately you deleted the sentence before, so I rephrase it: before looking into optimizations find out where the time is actually spend - how many seconds of the hours the process takes, are actually spent in make and sub-makes. If the entire process takes 2 hours of which the makes take 20 seconds then by enhancing performance of make by 50% you win 10 seconds. This is probably not worth a single line of additional code. The paper you point to talks about something entirely different. harti ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c btw.. stehpen, when are you getting a commit bit? :) I certainly hope that soon enough ;) roman ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Recreating /usr/ports/share/xml/catalog.ports
Hi all, Recently, owing to space problems, my catalog.ports got trashed, and now various ports (such as gdm scrollkeeper) are complaining that they can't find the Docbook XML DTD in it when configuring. Reinstalling docbook doesn't seem to do any good. Does anyone have a sequence of steps to recreate this file? Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: samba-3.0.25,1
On 5/28/07, Jose Ayala [EMAIL PROTECTED] wrote: jeje sorry i clicked send before time :D, the mesaage complete is: El lun, 28-05-2007 a las 16:00 -0500, Jose Ayala escribió: Hi, i just to comment a problem with the samba manager script, i dont know really whats the problem but it resolve executing directly the smbd nmbd and winbindd binaries from /usr/local/samba/sbin I install samba3 from ports, all ok, when i execute /usr/local/etc/rc.d/samba start i get the next message: Removing stale Samba tdb files: done and no more: when i stop samba with : /usr/local/etc/rc.d/samba stop , i dont get any message.. after i try with smbstatus and i get one tip for the problem, the message is: able. Later (2 hours later) i tried executing directly smbd nmbd and winbindd files and ohhh sorprise my samba server starting all right, then some happends with the script. Can you do something?? do you have samba_enable=YES in your /etc/rc.conf file? Without this variable in /etc/rc.conf, the script won't start the smbd, nmbd or winbindd daemons. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. Unfortunately you deleted the sentence before, so I rephrase it: before looking into optimizations find out where the time is actually spend - how many seconds of the hours the process takes, are actually spent in make and sub-makes. If the entire process takes 2 hours of which the makes take 20 seconds then by enhancing performance of make by 50% you win 10 seconds. This is probably not worth a single line of additional code. The paper you point to talks about something entirely different. It think we're talking about two different things. You're talking about the efficiency of make, whereas he's talking about the efficiency of make. Um, wait. You're talking about what I'll call the *internal* efficiency of make, defined as how fast it does the things it does. He's talking about what I'll call the *external* efficiency of make, which is how well it does at doing the minimum amount of work it needs to do. I hope you can see where the confusion comes from. In particular, he talks about how recursive makefiles screw up evaluating complex variables, causing them to be executed multiple times. So if you're running a makefile to pull some variables value, as opposed to do real commands, and your entire process takes 2 hours and the Makefile takes 20 seconds, but it evaluates all the variables twice, then by fixing your makefile you win at least 59 minutes and 50 seconds. I think cutting the run time by 50% is worth some work. Benchmarking can help you decide which things it pays to work on if all you're worried about is the internal efficiency. However, the goal is to make the process faster, so we need to worry about the external efficiency as well. The problem here is that the worse it is, the less it looks like you stand to gain by looking at your makefile when you look at the benchmarks. Given that the ports system has both highly complex variables and is very recursive, I believe that it warrants investigation if you're going to work on making make in the ports faster. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Correct me if I wrong. Don't you missed the fact that chdir(2) changes process wide attribute? Though it's easy to fix with -C option. Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Roman Divacky wrote: On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c btw.. stehpen, when are you getting a commit bit? :) I certainly hope that soon enough ;) Probably not. The program seems to have a bug in it. In particular, I didn't read the fgetln man page sufficiently well. So think of it as a proof of concept rather than a finished product. I'm going to rest from this stuff for a while, but I enjoyed the exchanges and it has given me encouragement to work on it again in the future sometime. Stephen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: samba-3.0.25,1
Paul Fraser to Scot show details 1:21 pm (0 minutes ago) On 5/29/07, Scot Hetzel [EMAIL PROTECTED] wrote: do you have samba_enable=YES in your /etc/rc.conf file? Without this variable in /etc/rc.conf, the script won't start the smbd, nmbd or winbindd daemons. Further to what Scot said, if you run /usr/local/etc/rc.d/samba onestart [or onestop, as you desire], the rc script will ignore the *_enable variable in rc.conf and allow you to start it. See how you go with that. (By the way, sorry Scot for the dupe! Accidently hit reply instead of reply all...) -- Regards, Paul Fraser ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Stephen Montgomery-Smith wrote: Roman Divacky wrote: On Mon, May 28, 2007 at 11:34:24AM -0500, Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c btw.. stehpen, when are you getting a commit bit? :) I certainly hope that soon enough ;) Probably not. The program seems to have a bug in it. In particular, I didn't read the fgetln man page sufficiently well. So think of it as a proof of concept rather than a finished product. I'm going to rest from this stuff for a while, but I enjoyed the exchanges and it has given me encouragement to work on it again in the future sometime. Stephen fgetln(2) just scans ahead to the next newline, so the pointer to the next line is returned and the length of the string (with newline char included) is stored in the len variable (2nd parameter to function). -Garrett ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Port: samba-3.0.25,1
I think this is related to the update in /usr/ports/UPDATING The passdb backend in your smb.conf. I think it defaults to something else now. On 5/29/07, Paul Fraser [EMAIL PROTECTED] wrote: Paul Fraser to Scot show details 1:21 pm (0 minutes ago) On 5/29/07, Scot Hetzel [EMAIL PROTECTED] wrote: do you have samba_enable=YES in your /etc/rc.conf file? Without this variable in /etc/rc.conf, the script won't start the smbd, nmbd or winbindd daemons. Further to what Scot said, if you run /usr/local/etc/rc.d/samba onestart [or onestop, as you desire], the rc script will ignore the *_enable variable in rc.conf and allow you to start it. See how you go with that. (By the way, sorry Scot for the dupe! Accidently hit reply instead of reply all...) -- Regards, Paul Fraser ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] -- Imagination is more important than knowledge. -- A. Einstein ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
