Re: FreeBSD Port: openldap-server-2.3.24: default loglevel and /var/log/debug.log
On Sun, Jul 23, 2006 at 06:57:31AM +, Xin LI wrote: > Oh... I think 0 have the same effect with 32768. I think it's Ok to have Sorry, this is incorrect. 0 means disable logging completely, while 32768 means "only the emergency ones", which is recommended in my opinion. Cheers, ___ 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: openldap-server-2.3.24: default loglevel and /var/log/debug.log
Thierry Lacoste wrote: >> So, Correct, yes. However that loglevel records the activity of the >> server in about the same level of detail as you'ld hope to see from any >> other network server. > With no negative impact on performance for a loaded production server? > My /var/log/debug.log was already rotating every hour and the machine > is only in a testing phase. That depends... The big deal with LDAP is not so much how much data it can pump out per second, but how fast it can answer each individual query. That is, *latency* is more important than *bandwidth*. Remember that from the point of view of slapd, all it has to do is inject the log message into syslog(3) -- it can then get on with processing other queries, while syslogd marshals the log data and gets it into the required log file. In other words, the logging shouldn't add anything significant to the *latency* of your LDAP queries, unless the system is so loaded that syslog and slapd are competing for CPU time slices. If your LDAP database is sufficiently large that searches are going to hit the disk rather than being cached in memory, then there's a possible disk IO contention problem. If that is the case, then arranging things so that the logging data goes to one drive, and the LDAP database lives on a different drive would be a big win. > But clearly /var/log/slapd.log is now rotating fast. > I'm using nss_ldap and a simple "id lacoste" generates more than 2 KB of logs. Hmmm... that does seem like quite a lot. Do you have name service caching configured on the client machines? > I was considering keeping that setting for testing purposes and > either turn to local4.info in syslog.conf or set "loglevel=0" in slapd.conf > when in production. Is this a bad idea? The only way you're going to get a definitive answer is to benchmark the different settings under production-level workloads. Logging is the sort of thing that most of the time you probably don't need, but when things go horribly wrong, then you will need it badly. Even if you run log-less most of the time, probably your first response to reported LDAP problems will be to turn on logging... Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: New portmaster version available for testing/feedback
Hans Lambermont wrote: > Doug Barton wrote: > >> Doug Barton wrote: >> >>> I just uploaded a version that has what should be a fix for this, can >>> you give it a try? And thanks for catching this, you're right, it's >>> an oversight on my part. >> I'm curious if you've had a chance to try that fix, as I'd like to >> commit the new version sometime soon. > > It's nice to have bootable backups ;-) heh > I just tested the same upgrade and it works OK now : > > ===>>> Upgrade for howl-1.0.0_1 to avahi-0.6.11_1 succeeded > > I miss one dependency though : > > # pkg_info -R avahi-0.6.11_1 > Required by: > gimp-2.2.11,1 > kde-3.5.2 > planner-0.13_3 > > The old avahi-0.6.10_3 also had : >> # pkg_info -R avahi-0.6.10_3 >> Required by: >> vlc-0.8.5_2 > > Is this a dependency-merge omission ? It looks like avahi-0.6.11_1 only > has the howl-1.0.0_1 dependencies. D'oh. This is an ugly problem, but I just uploaded a new version at http://dougbarton.us/portmaster that fixes this issue. This time around I created an artificial environment with both howl and avahi dependencies, and with both ports installed, and tested the update. I'm confident that this new version does what _I_ expected it to do, but if you can still test one more time, that would be appreciated. If you don't get a chance to test, that's cool too, just let me know so that I can check in the new version. >> Also, in re-reading your message it occurs to me that one of the problems >> with what you did previously is that you specified just 'howl' as the second >> argument to -o, and that isn't enough. You either need to specify net/howl >> ala portupgrade, or howl-1.0.0_1 (i.e., the installed port name from >> /var/db/pkg). > > Ah yes, perhaps this is a good thing to check for ? ;-) Too dangerous in this situation. I'd rather not guess what the user is trying to do. I did however improve the code that reads the port directory as the second argument, so now you can do (for example) net/howl, /usr/ports/net/howl, or howl-1.0.0_1 and they all work. FYI, the other change I made to the version I just posted is that the -s option to remove stale ports is now recursive, so if you're deleting a big chunk (like the avahi mess that I was testing with) it keeps going till there are no more stale ports to find, rather than having to run it repeatedly like you did previously. Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: portinstall breaks with -m "-j 4"
Mark Linimon wrote:
>> BTW, I apologize for this is not at all a portupgrade issue, but an issue
>> of the ports system.
>
> It is an issue with individual ports -- actually not the "port" (e.g.
> Makefile framework, pkg-*) but the individual applications (IIUC).
>
>> Well, at least the ports system itself should not be broken able to work
>> with this. With larger ports I manage to reduce build times by 40% with
>> distcc and a second machine. As far as I see it the number of ports
>> breaking is rather low.
>
> Please feel free to suggest a framework (complete with regression test
> framework) where the infrastructure code can "learn" which ports are safe.
> I think it's going to be a harder problem than you think it is. Note that
> "appears to work" and "can be shown to work under arbitrary build
> circumstances for all users" are IMHO going to be two very different
> classes of problem -- and the latter will need to be solved before it
> can be used on the package-building cluster.
I do not expect anyone to check weather ports support it or not. I can track
this for myself in my make.conf, but the problem for me is that the ports
framework itself doesn't support it. I am able to work around the broken
install target with this:
.if defined(THREADS)
.if !make(*install)
.MAKEFLAGS: -j ${THREADS}
.else
USE_SUBMAKE=yes
MAKE_ARGS:= -j ${THREADS}
.NOTPARALLEL::
.endif
.endif
But 'make -j N config' is also broken (the config dialogue cannot see the size
of the terminal and does not receive key events) and I did not find a
workaround for this so far.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD Port: net/bfilter: rc.d script broken
Hi, I noticed that the rc.d script needs to be renamed to "bfilter.sh" or else it won't be started at boot time (FreeBSD 6.1). I wonder why nobody pointed this out yet, since several other rc.d scripts also miss a ".sh". Or is this intentional? ___ 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: net/bfilter: rc.d script broken
On Sun, 2006-07-23 at 11:39 +0200, Nikolaus Waxweiler wrote: > Hi, > I noticed that the rc.d script needs to be renamed to "bfilter.sh" or > else it won't be started at boot time (FreeBSD 6.1). I wonder why > nobody pointed this out yet, since several other rc.d scripts also > miss a ".sh". Or is this intentional? If you upgraded from a previous 5.x FreeBSD version via source (ie. make world), you may have forgotten to run mergemaster. -- Florent Thoumie [EMAIL PROTECTED] FreeBSD Committer signature.asc Description: This is a digitally signed message part
[New Port] KPorts
hi everyone, since a couple of weeks sysutils/kports is now available. it is an advanced KDE-frontend for the ports, designed also at more experienced users, but being being rather easy to use. i justed wanted if any of you have tried it, what impression you got, and if you have any suggestions for future development. thanks ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Wireshark-0.99.2 build (formerly ethereal)
There are some issues with this port, which used to be known as the Ethereal network analzyer. #1 There is now a dependency on security/libgcrypt which the port needs to be taught about. On 6.1-STABLE, this causes a build failure which can manually be resolved by adding -lgcrypt to the command line: epan/.libs/libwireshark.so: undefined reference to `gcry_md_get_algo_dlen' epan/.libs/libwireshark.so: undefined reference to `gcry_md_close' epan/.libs/libwireshark.so: undefined reference to `gcry_md_read' epan/.libs/libwireshark.so: undefined reference to `gcry_md_setkey' epan/.libs/libwireshark.so: undefined reference to `gcry_cipher_get_algo_keylen' epan/.libs/libwireshark.so: undefined reference to `gcry_control' epan/.libs/libwireshark.so: undefined reference to `gcry_md_write' epan/.libs/libwireshark.so: undefined reference to `gcry_cipher_open' epan/.libs/libwireshark.so: undefined reference to `gcry_cipher_ctl' epan/.libs/libwireshark.so: undefined reference to `gcry_cipher_close' epan/.libs/libwireshark.so: undefined reference to `gcry_md_open' epan/.libs/libwireshark.so: undefined reference to `gcry_md_algo_name' epan/.libs/libwireshark.so: undefined reference to `gpg_strerror' epan/.libs/libwireshark.so: undefined reference to `gcry_cipher_decrypt' epan/.libs/libwireshark.so: undefined reference to `gcry_cipher_algo_name' *** Error code 1 Stop in /usr/ports/net/wireshark/work/wireshark-0.99.2. *** Error code 1 Stop in /usr/ports/net/wireshark/work/wireshark-0.99.2. *** Error code 1 Stop in /usr/ports/net/wireshark/work/wireshark-0.99.2. *** Error code 1 Stop in /usr/ports/net/wireshark. #2 Someone just "updated" net/wireshark/pkg-descr to show the project link to be: http://www.writeshark.org/ http://www.wireshark.org is the correct site. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
MASTER_PORT buglet
Dear list,
Ahem. Let's try that again with the correct spelling of the list address...
The following slave ports are producing an incorrect 'MASTER_PORT' value:
emulators/linux_base-gentoo-stage1 (linux_base-gentoo-stage1-2006.0_2)
emulators/linux_base-gentoo-stage2 (linux_base-gentoo-stage2-2006.0_1)
emulators/linux_base-gentoo-stage3 (linux_base-gentoo-stage3-2006.0_1)
japanese/kinput2-canna (ja-kinput2-canna-3.1_2)
japanese/kinput2-canna+freewnn (ja-kinput2-canna+freewnn-3.1_2)
japanese/kinput2-canna+freewnn+sj3 (ja-kinput2-canna+sj3+freewnn-3.1_2)
japanese/kinput2-canna+sj3 (ja-kinput2-canna+sj3-3.1_2)
japanese/kinput2-canna+sj3+wnn6 (ja-kinput2-canna+sj3+wnn6-3.1_2)
japanese/kinput2-canna+sj3+wnn7 (ja-kinput2-canna+sj3+wnn7-3.1_2)
japanese/kinput2-canna+wnn6 (ja-kinput2-canna+wnn6-3.1_2)
japanese/kinput2-canna+wnn7 (ja-kinput2-canna+wnn7-3.1_2)
japanese/kinput2-freewnn+sj3 (ja-kinput2-sj3+freewnn-3.1_2)
japanese/kinput2-sj3 (ja-kinput2-sj3-3.1_2)
japanese/kinput2-sj3+wnn6 (ja-kinput2-sj3+wnn6-3.1_2)
japanese/kinput2-sj3+wnn7 (ja-kinput2-sj3+wnn7-3.1_2)
japanese/kinput2-wnn6 (ja-kinput2-wnn6-3.1_2)
japanese/kinput2-wnn7 (ja-kinput2-wnn7-3.1_2)
lang/gfortran (gcc-withfortran-4.1.2_20060721)
math/spooles-mpich (spooles-mpich-2.2_4)
science/mpqc-mpich (mpqc-mpich-2.3.0)
x11-toolkits/fltk-threads (fltk-threads-1.1.6_1)
The symptom is that in each case the MASTER_PORT variable gets set to
a fully qualified path like so:
happy-idiot-talk:...ports/emulators/linux_base-gentoo-stage1:% make -V
MASTER_PORT
/usr/ports/emulators/linux_dist-gentoo-stage1/
Whereas the output is meant to be relative to PORTSDIR, like so:
happy-idiot-talk:...ports/databases/mysql50-client:% make -V MASTER_PORT
databases/mysql50-server
The problem in each case is a trailing slash on the value of MASTERDIR set in
the slave port Makefiles:
happy-idiot-talk:...ports/emulators/linux_base-gentoo-stage1:% grep
^MASTERDIR Makefile
MASTERDIR= ${.CURDIR}/../linux_dist-gentoo-stage1/
It's a pretty trivial thing I know, but I noticed it while working on my
FreeBSD::Portindex module, which relies heavily on the value of MASTER_PORT
to find master/slave relations between ports in the latest release. I've
put in a work-around in my code: I'll leave it to the collected wisdom of the
list to decide if this warrants fixing.
Port maintainers were CC'd in my first attempt at sending this.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
signature.asc
Description: OpenPGP digital signature
Re: portinstall breaks with -m "-j 4"
On Saturday 22 July 2006 22:13, Mark Linimon wrote: > > BTW, I apologize for this is not at all a portupgrade issue, but an issue > > of the ports system. > > It is an issue with individual ports -- actually not the "port" (e.g. > Makefile framework, pkg-*) but the individual applications (IIUC). > > > Well, at least the ports system itself should not be broken able to work > > with this. With larger ports I manage to reduce build times by 40% with > > distcc and a second machine. As far as I see it the number of ports > > breaking is rather low. > > Please feel free to suggest a framework (complete with regression test > framework) where the infrastructure code can "learn" which ports are safe. > I think it's going to be a harder problem than you think it is. Note that > "appears to work" and "can be shown to work under arbitrary build > circumstances for all users" are IMHO going to be two very different > classes of problem -- and the latter will need to be solved before it > can be used on the package-building cluster. It seem to me that virutally all the advantage could be obtained by passing -j just to the build stage, where portupgrade spend most of its time. In any case install is probably too IO-bound to benefit. The user could set say WITH_PARALLEL=4. The value could be passed down to the build if the port sets USE_PARALLEL=yes or the user sets WITH_PARALLEL_FORCE=yes. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Using >= to check for minimum versions.
Hey guys,
Using the minimum version checking is not working for me.
using :
LIB_DEPENDS=usb-0.1.8:${PORTSDIR}/devel/libusb
works.
but using the following construct as section 5.7.9 of the porters
handbook suggests
#LIB_DEPENDS= usb>=0.1.8:${PORTSDIR}/devel/libusb
errors out with:
===> Vulnerability check disabled, database not found
===> Extracting for libnjb-2.2.5
=> MD5 Checksum OK for libnjb-2.2.5.tar.gz.
=> SHA256 Checksum OK for libnjb-2.2.5.tar.gz.
===> Patching for libnjb-2.2.5
Syntax error: redirection unexpected
*** Error code 2
Thanks for any help.
Adrian.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/makefile-depend.html#AEN2209
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
:(
Добрый день ===> Script "configure" failed unexpectedly. Please report the problem to [EMAIL PROTECTED] [maintainer] and attach the "/usr/ports/textproc/wv/work/wv-1.2.1/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/textproc/wv. -- С уважением, Системный администратор ОГУЗ "Новосибирский областной клинический консультативно-диагностический центр" Дмитрий Седлов рабочие тел. 2282735, 2264969 e-mail: [EMAIL PROTECTED] сот. тел.+79231212017 e-mail: [EMAIL PROTECTED] --- Windows NT 5.0 sp=5f Mail agent: TheBat! 3.80.3 PRO config.log Description: Binary data ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
