Re: New entropy harvesting sysctl's enabled in rc
On Thu 2001-03-01 (15:57), Brandon D. Valentine wrote: Appropriate rc.conf(5) entries will be coming in a seperate commit. I am working on a general cleanup/update of that file, but I plan to wait till the reality in rc.conf is closer to what we want it to be. This is only tangentially related but while you're talking about a cleanup of the rc.conf(5) file, did anyone ever work up a patchset for the NetBSD rc system that was discussed several months ago? I have a bastardisation on my laptop at home; if I can find the time over the weekend, I'll see about getting it off there[1] and sending it to -hackers. [1] It has no network card anymore, and a dodgy floppy drive. Joy. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bug in src tree?
On Fri 2001-01-12 (08:17), electro wrote: I try to compile a new kernel with the latest source and I always end up with this (in the end). Any suggestions? I mean the error message is fun...dont match any know i386 instruction cc -c -x assembler-with-cpp -DLOCORE -O -Wall -Wredundant-decls -Wnested-externs -Wst rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../dev -I../../.. /include -I../../contrib/dev/acpica/Subsystem/Include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 ../../i386/i386/bioscall.s /tmp/ccmJEqq7.s: Assembler messages: /tmp/ccmJEqq7.s:758: Error: operands given don't match any known 386 instruction /tmp/ccmJEqq7.s:822: Error: operands given don't match any known 386 instruction *** Error code 1 Stop in /usr/src/sys/compile/PROFESSOR.010110. You're not using buildkernel, and thus you don't have the necessarily updated tools to handle that source. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /etc/defaults/rc.conf
On Wed 2000-11-08 (09:30), Mikel wrote: I've had been considering running xinted for some time now, and thanks to Forest's suggestions I've been able to successfully get it up and running smoothly. I am personnaly left wondering why not just replact inetd altogether with this version? It certainly enhances security a bit. How does it enhance security? My main concern: (nbm@scythe) /usr/src/usr.sbin/inetd find . -type f -name "*.c" | xargs wc -l | grep total 2933 total vs: (nbm@scythe) /home/nbm/security/xinetd-2.1.8.9pre10 find . -type f -name "*.c" | xargs wc -l | grep total 23149 total Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Updating ports
[ - -ports ] On Tue 2000-10-03 (18:51), Leif Neland wrote: Jacques Personally I don't want sysinstall or make world to touch my ports. Jacques But a tool to do this would be great. Completely automatic update of installed ports is acutally difficult because we cannot get to know the language or required toolkit from the name of a binary. (eg emulator/wine and japanese/wine, timidity++-xaw and timidity++-tcltk) We can still detect and enumerate the ports that possibly installed old binaries, and decide which of the ports listed up to update. Isn't enough information in /var/db/pkg? Perhaps a level of redirection is needed in the dependencies? (sp?) Something like the Debian way? Instead of foo-1.23 being required by bar-3.34, bar should just require a foo 1.20. Or even bar requires an xyzzy. xyzzy is supplied by fee xyzzy is supplied by fie Then the user has the option of installing fee or fie. This really is an issue for ports@, not current@. We've had a long discussion on this, and not much has come out of it yet, but I imagine that it just needs some time to simmer at a low heat before some deep-frying. (: So far, we've identified (or, rather, some people have suggested) that we need relative versioning and virtual packages, so we've covered your suggestions. My "accurate" versioning stuff has come in (epoch, revision, just like Debian), and it'll take some time more for someone to supply and review the code for the others. I believe Satoshi is reviewing a port of the NetBSD relative versioning stuff at the moment. Virtual packages are an interesting thing, I don't believe there's code available for it, but it should be easy enough. Luckily, it seems things are progressing, and that the creative juices are flowing again. Will has a talk which includes stuff based loosely on some suggestions of mine from way-back, which he'll give at BSDcon (hopefully I can make it), and that will probably be a good brain-storming starter. So, things are looking up. I can't actually remember why I replied to this, other than to move it over to ports. My mind is a'wandering. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel broken?
On Thu 2000-09-21 (16:27), Stijn Hoop wrote: nm: could not exec elf/nm in /usr/obj/usr/src/i386/usr/libexec: No such file or directory Yep, this is the problem. Which is quite correct since I blew away /usr/obj after my last buildworld (FreeBSD 4.1-STABLE #0: Wed Sep 13 14:45:31 CEST 2000). Is this a problem? Yep. Should I have done a buildworld before a buildkernel now? I'm trying to convince Marcel that since we already let you use gcc from out the tree, there's no reason we should prevent people from running 'nm' from out the tree. Since he knows more about this sort of thing, and says there may be a problem, I'll leave it to him. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel broken?
On Thu 2000-09-21 (08:48), Donn Miller wrote:
An example of what I get when I try to do a make buildkernel. I have set
KERNEL=CUSTOM in /etc/make.conf, so I should be alright there.
{standard input}:2342: Error: Subtraction of two symbols in different sections
".data" {.data section} - "KERNBASE" {*UND* section} at file address 928.
Do you have a populated /usr/obj? (ie, with nm)
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildkernel broken?
On Thu 2000-09-21 (10:00), Donn Miller wrote:
On Thu, 21 Sep 2000, Neil Blakey-Milner wrote:
On Thu 2000-09-21 (08:48), Donn Miller wrote:
An example of what I get when I try to do a make buildkernel. I have set
KERNEL=CUSTOM in /etc/make.conf, so I should be alright there.
{standard input}:2342: Error: Subtraction of two symbols in different sections
".data" {.data section} - "KERNBASE" {*UND* section} at file address 928.
Do you have a populated /usr/obj? (ie, with nm)
I've been doing "make buildkernel installkernel" in /usr/src without doing
a "make buildworld" first. Is this OK? I guess the buildkernel created a
/usr/obj, but I deleted it and tried buildkernel again with the same
results.
No, it's not ok.
I have patches awaiting some final decision from Marcel that'll make it
possible. It mostly works, but OBJFORMAT_PATH doesn't have access to
the same PATH we're exporting during the kernel build, meaning 'nm'
won't work. They look something like:
cvs diff: cannot find Makefile
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.167
diff -u -r1.167 Makefile.inc1
--- Makefile.inc1 2000/09/03 02:58:39 1.167
+++ Makefile.inc1 2000/09/06 21:10:53
@@ -193,6 +193,14 @@
PATH=${TMPPATH}
WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
+# kernel stage
+.if ${BUILD_ARCH} == ${MACHINE_ARCH}
+KMAKEENV= ${WMAKEENV} \
+ OBJFORMAT_PATH=${WORLDTMP}/usr/libexec:/usr/libexec
+.else
+KMAKEENV= ${WMAKEENV}
+.endif
+
# install stage
IMAKEENV= ${CROSSENV} \
PATH=${STRICTTMPPATH}:${INSTALLTMP}
@@ -383,6 +391,9 @@
.if empty(INSTALLKERNEL)
INSTALLKERNEL= ${_kernel}
.endif
+.else
+.BEGIN:
+ @echo " Kernel configuration ${_kernel} does not exist; not building"
.endif
.endfor
@@ -409,10 +420,10 @@
${MAKE} -f ${KRNLSRCDIR}/dev/aic7xxx/Makefile
.if !defined(NO_KERNELDEPEND)
cd ${KRNLOBJDIR}/${_kernel}; \
- ${WMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} depend
+ ${KMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} depend
.endif
cd ${KRNLOBJDIR}/${_kernel}; \
- ${WMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} all
+ ${KMAKEENV} MACHINE=${MACHINE} ${MAKE} KERNEL=${INSTKERNNAME} all
.endfor
#
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Please consider some cosmetic changes in boot messages
On Fri 2000-09-08 (15:19), John Toon wrote: I have a plan to revamp the way that the startup process's output is presented and stored for later viewing. I need to chat to some folks first about the best way to do this, first. Be patient, and look forward to something interesting in 5.0-RELEASE. :-) On that subject, can you give me a rough projection as to when 5.0-RELEASE is likely to arrive? FreeBSD 2.2.1 1997-04-xx [FBD] FreeBSD 3.0 1998-10-16 [FBD] FreeBSD 4.0 2000-03-13 [FBD] So we're talking 2001-07 to 2001-11, at a wild guess. We have lots of new developments, but also a much more streamlined system. It's anyone's guess when it'll be deemed stable and complete enough to roll. (and please don't quote me, since this is only my guess) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Fri 2000-09-08 (22:53), Matthew Thyer wrote:
I would like to see startup and shutdown scripts exist in a single
directory ("/usr/local/etc/rc.d/" for ports and eventually
"/etc/rc.d" when the system migrates to the same scheme).
I don't think we should move away from the 'base' system and 'extra'
stuff differentiation. Any script that can support /etc/rc.d can
probably support /usr/local/etc/rc.d, /usr/X11R6/etc/rc.d, and others
based on a variable in /etc/rc.conf.
The startup and shutdown functionality would be in the same script
and the scripts should be named starting with a capital 'S' for
startup and a capital 'K' for shutdown (I'm also keen on the HPUX
startmsg and stopmsg one liners).
Why not just use chmod +x or chmod -x, like we do already? This means
not having to rename things.
The scripts will be differentiated from existing scripts (the old
system) as the new system will only act on scripts that have a digit
in the second character of their name (there could be a backward
compatability process to act on all the others afterwards which
would be disabled by default... presumably "disabled.S99rc.compat"
or some such name).
I prefer chmod +x and chmod -x.
Stop scripts will be a symbolic link to their startup script
counterpart (and would simply not be executed if the K* file doesn't
exist). Symbolic links make it clear they are the same script.
I don't see the point.
Scripts would be executed in alphabetical order (after the S or K)
so the sysadmin has control over the execution order which is
important.
I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at
http://people.FreeBSD.org/~eivind/newrc.tar.gz)
Scripts would source common functions from a system file so we have
control over future changes in functionality/reporting. This would
also make the template script very simple.
I imagine that's the way to do it.
Eventually I would like the system to migrate to such a scheme but
maintain the backward compatibility scripts /etc/netstart which
could be implemented either by simply 'knowing' which rc scripts
do network functionality or by reserving a range of numbers for
network startup --- HACK!
This is why you want dependencies.
I'd really like the system to allow stuff like "/etc/rc.d/S84named
reread" (or "restart", "reload" whatever is acceptable).
That's a natural extension to the current method, yes. We should be
sure to fail on something we don't understand, and not (like we may do
now) run the default start script.
I'd also really like at least named and perl to be removed from the
base system but that's another thread.
I'll comment when you bring it up. Warning: perl is necessary for
kernel builds.
One of the big turn offs to FreeBSD in the System V world is:
"What!, why do I need to know which signal to send blah to reload
it ?".
I agree. We need a simpler system. Simple, and obvious. None of this
complex symlink stuff.
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Sat 2000-09-09 (00:05), Matthew Thyer wrote: Stop scripts will be a symbolic link to their startup script counterpart (and would simply not be executed if the K* file doesn't exist). Symbolic links make it clear they are the same script. I don't see the point. The point is that people are worried about scripts that aren't aware of the "start" and "stop" argument trying to start apps again at shutdown time. With my scheme, the script wont be executed at shutdown time if the K* script doesn't exist. If it's there, it gets executed. If it's there, it was put there. If it was put there, it'll have support for "start" and "stop". If an administrator puts a script in there that does the wrong thing, that's his fault. He could use the fall-back rc.local method. We needn't support stupid behaviour by complicating the matter. Scripts would be executed in alphabetical order (after the S or K) so the sysadmin has control over the execution order which is important. I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at http://people.FreeBSD.org/~eivind/newrc.tar.gz) I haven't looked at this yet but off the top of my head, a dependency based system sounds overly complicated (consider ports authors) and unecessarily different from other systems. I am considering port authors, and I think that dependency-based systems will be _much_ better for them. Thanks for bringing it up. # before zope # before apache # after networking # after nfs is much better than: S10.networking.sh S20.nfs.sh S40.zope.sh S45.apache.sh and then figuring to use S43.foo.sh. I'd also really like at least named and perl to be removed from the base system but that's another thread. I'll comment when you bring it up. Warning: perl is necessary for kernel builds. I know but I'm pretty keen on awk and would like all the perl dependencies to be re-written with awk or other tools as I dislike FreeBSD being dependent on such a beast as perl which should only exist as a port. Just look at the pain of getting perl 5.6.0 into the system. I know the perl lovers will hate me but I thinks its worth having some ugly awk to get away from elegant perl being required in the base system. I'm not particularly attached to perl, but it has a convenience in some sections, like ports, that is unmatched by sed and awk. Note the excessive use of "perl -i -pe 's/foo/bar/'" for in-place substitution. I've asked on at least two occasions for a simple, easy-to-use, thing to do it without doing a two-liner that copies to another file, and then replaces the old file with the new file. I'd go further to say that the whole base OS needs to be more modularised ala Solaris and Linux especially since we dont have an established binary patch process. Its pretty hard to sell FreeBSD to my work masters when the only patch method is source code patches or a complete rebuild of -STABLE or just wait until the next release. A more modular system could be upgraded more easily. I agree. I'd suggest you check out the freebsd-libh mailing list, and ask there about how to check out the libh sources. Your contributions to the libh project will aid development of the next-generation package management and installer. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Fri 2000-09-08 (11:12), Don Lewis wrote: On Sep 9, 12:05am, Matthew Thyer wrote: } Subject: Re: /usr/local/etc/rc.d and /etc/rc.d } Neil Blakey-Milner wrote: } I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at } http://people.FreeBSD.org/~eivind/newrc.tar.gz) How does this compare with what NetBSD implemented? } I haven't looked at this yet but off the top of my head, a dependency } based system sounds overly complicated (consider ports authors) and } unecessarily different from other systems. NetBSD switched to a dependency based system a while back. Judging by the traffic on their mail lists, it was somewhat controversial ... Eivind's system is almost exactly the same. I wonder if they used it as a base. (they also seem to use etc/default from March this year) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local/etc/rc.d and /etc/rc.d
On Sat 2000-09-09 (11:25), Matthew Thyer wrote:
Don Lewis wrote:
On Sep 9, 12:05am, Matthew Thyer wrote:
} Subject: Re: /usr/local/etc/rc.d and /etc/rc.d
} Neil Blakey-Milner wrote:
} I'd prefer a dependency based system. (cf. Eivind Eklund's newrc, at
} http://people.FreeBSD.org/~eivind/newrc.tar.gz)
How does this compare with what NetBSD implemented?
} I haven't looked at this yet but off the top of my head, a dependency
} based system sounds overly complicated (consider ports authors) and
} unecessarily different from other systems.
NetBSD switched to a dependency based system a while back. Judging by
the traffic on their mail lists, it was somewhat controversial ...
I'd consider it overly complicated because:
- The OS vendor can work out the correct order for system component
startup and set the numbers right once per release so who needs
the overhead and complexity of a dependency based system ?
We don't work with machines "once per release". Keeping those numbered
files in CVS will also suck if we rearrange things.
You're making an assumption that there is overhead and complexity in a
dependency-based system. The NetBSD one seems incredibly no-nonsense
and direct - the core of /etc/rc is:
files=`rcorder -s nostart /etc/rc.d/*`
for i in $files; do
run_rc_script $i start
done
Here's a simple dependency example:
/
#!/bin/sh
#
# $NetBSD: timed,v 1.2 2000/03/13 04:04:10 lukem Exp $
#
# PROVIDE: timed
# REQUIRE: DAEMON
. /etc/rc.subr
name="timed"
command="/usr/sbin/${name}"
load_rc_config $name
run_rc_command "$1"
\
Or a more complex on:
/
#!/bin/sh
#
# $NetBSD: postfix,v 1.3 2000/04/30 12:21:00 lukem Exp $
#
# PROVIDE: mail
# REQUIRE: LOGIN
# we could do this, but make mail start late, so that things like
# .forward's are not processed until the system is fully operational
## REQUIRE: DAEMON
. /etc/rc.subr
name="postfix"
required_files="/etc/${name}/main.cf"
extra_commands="reload"
start_precmd="checkyesno postfix"
start_cmd="postfix start"
stop_precmd=$start_precmd
stop_cmd="postfix stop"
reload_precmd=$start_precmd
reload_cmd="postfix reload"
load_rc_config $name
run_rc_command "$1"
\
This is really easy to understand and document, and the few people of
all levels of proficiency I've just asked think this is cool.
- The ports collection is so huge these days that we need to make it
easier rather than harder for non-hardcore FreeBSD users to
submit and maintain their own ports. Its already hard enough to
do a port right especially if it should have ifdefs on the version
of FreeBSD to work correctly in -STABLE and -CURRENT. Port authors
really need -CURRENT and -STABLE installed and maintain a copy of the
repository to DTRT.
Most of the ports submitters I know personally only have -RELEASE
machines. They seem to do fine.
I don't see how the SysV way is any easier than the dependency-based
system. The dependency-based system means you can set it up, and then
leave it alone and never worry about renumbering.
- The SysV style number based system is fine in that port authors can
all use the same number (say S50myport) unless it needs to be changed
due to the unlikely need for ordering (remember we haven't had
ordering
to date and there are ~3700 ports).
This applies equally to a dependency-based system. Most will use the
PORTS requirement, I imagine, which'd be equivalent to the current
system, and which we could tweak from a central place if needs be,
without changing every single port.
- Dont think of /usr/local/etc/rc.d being just for the ports collection,
people will put there own startup scripts there too and will find it
very easy to just pick the right numbers ala SysV.
Only to have the vendor re-number things in the next release, and spoil
their carefully-located numbers? Dependencies are a big win here too.
All in all I'm delighted with the NetBSD dependency-based system that
has been pointed out to me. It'd be great to synchronise with their
system, and share and help develop their code (which, from casual
inspection, is great, and looks like it may never need changes).
It kinda makes me wonder what I'll do when I see that RedHat machine at
work. (:
Neil
--
Neil Blakey-Milner
Sunesi Clinical Systems
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: perl built twice?
On Sun 2000-09-03 (15:02), R Joseph Wright wrote: While doing a make world, I noticed that perl is built early on. When I came back later, I saw perl being built again along with all the other gnu.usr.bin stuff. Was I tripping or did perl really get built twice? libperl and miniperl are built early on, in the 'build-tools' section (I think). Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: AFS.
On Wed 2000-08-30 (13:47), Robert Watson wrote: Transarc/IBM source will presumably greatly facilitate the development of Arla, and also allow use of the IBM code in the mean time (Arla is under a liberal BSD-style license, whereas I would guess the IBM code will be under something like the Netscape license?). The license is at: http://oss.software.ibm.com/developerworks/opensource/license10.html It's somewhat similar to the (original) openssl license, in that any source-available distributions must be distributed under it: When the Program is made available in source code form: a) it must be made available under this Agreement; and b) a copy of this Agreement must be included with each copy of the Program. It may be distributed in object form without fee to IBM/Transarc, or restriction, save that the use of the code by the person giving away the object form must fulfil the agreement, and that the standard disclaimers and stuff against damages are applied. Additionally a distributor of object code must tell those distributed to that the free source program exists and how to get it. I think it is probably sufficiently free. It doesn't sufficiently cover the use of small bits of its code, though. It is a non-terminating license. Neil (who wonders to which list one should redirect license talk) -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: People running with LOCALBASE set to something other than /usr/local?
On Thu 2000-08-24 (20:52), Andrew Reilly wrote: On Wed, Aug 23, 2000 at 10:54:44PM -0700, Satoshi - Ports Wraith - Asami wrote: However, note that you need to move LOCALBASE and X11BASE for *all* ports, not one. (For instance, you can't expect an emacs-lisp package to install correctly if you just try to move it while emacs is still in /usr/local.) Set LOCALBASE and X11BASE in /etc/make.conf and rebuild everything, including X. At least that would help to keep track of things that I've gratuitously added to /usr/local, outside of the ports mechanism. Try /usr/ports/Tools/scripts/consistency-check Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail updated from 8.9.3 to 8.11.0 in -current
On Sun 2000-08-13 (09:20), Kurt D. Zeilenga wrote: A make.conf knob to use a userinstalled library may create problems with different versions of Cysus-SASL. I had some problems with that when uppgrading my mailservers to Sendmail 8.10. I'd recommend bringing Cyrus-SASL into the base system eventually under the same rational used to bring OpenSSL in. What are the license issues on this? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sendmail updated from 8.9.3 to 8.11.0 in -current
On Sun 2000-08-13 (10:48), Kurt D. Zeilenga wrote: At 06:53 PM 8/13/00 +0200, Neil Blakey-Milner wrote: On Sun 2000-08-13 (09:20), Kurt D. Zeilenga wrote: A make.conf knob to use a userinstalled library may create problems with different versions of Cysus-SASL. I had some problems with that when uppgrading my mailservers to Sendmail 8.10. I'd recommend bringing Cyrus-SASL into the base system eventually under the same rational used to bring OpenSSL in. What are the license issues on this? None worse than those associated with OpenSSL. Ah, it seems to be a simplistic BSD-like license. For a second I thought it might be a non-commercial one, like cyrus-imapd has in some areas. OpenSSL is slightly more structured - Apache-like BSD license. So at least there won't be any insane license-wars over it. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Custom ISO Images
On Wed 2000-08-02 (11:05), Marc Teichtahl wrote: i need to build a large number of machine with a customer distribution based on 4.1-RELEASE are there any pointers or help you can give me on how to create an ISO image of my distribution ? cd /usr/src/release make release You might need to adjust a few things, though ;) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locale issues on -current
On Sat 2000-07-22 (00:10), Doug Barton wrote: I installed a recent snapshot of -current (a week ago) and I keep getting the following warnings: [vshah@vorpal] /etc perl perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LC_ALL = (unset), LC_CTYPE = "en_US", LANG = (unset) are supported and installed on your system. I get the same thing. It's LC_CTYPE that's causing the problem. I was half thinking that it was something related to gnome, but I haven't worked very hard to fix it. Unsetting that variable makes the warning go away, whether that fixes the problem or not. Viren: Is that in an X session, possibly running gnome? I've had this too. Never have figured what it was about, but it happened only in X, where I use gnome. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kerneld for -current
On Thu 2000-07-13 (13:46), Yevmenkin, Maksim N, CSCIO wrote: long time back there was a discussion about kerneld for FreeBSD. some people have found it useless, but some not :) anyway, alpha version of code can be found at sourceforge.net. http://sourceforge.net/projects/kerneld/ changes: - minor bug fixes - kd device improvements (now support select) - kerneld now has access control list to accept/deny request from users/group (thanks to Someone from the list for the idea, sorry don't remember The Name :) What, exactly, does it do? Can you write a quick blurb about it, so we can see what the features are, what it buys us, why we want it, and things like that? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Mak
On Tue 2000-06-27 (02:41), John Baldwin wrote: On 26-Jun-00 David O'Brien wrote: On Mon, Jun 26, 2000 at 10:28:53PM +0200, Mark Murray wrote: Since I'm now through it, I don't know the latest problem, but the last thing I saw that the old lib got used with the new perl (or the other way round) and that looks like it can be fixed with some path adjustments. The problem here is that miniperl needs to be built early enough to be in the path perl "proper" is done. I thought build-tools was the answer; sadly that seems to be wrong. Now I'm looking at cross-tools (out of src/makefile.inc1). Adding something to bootstrap-tools implies that we can't use the installed miniperl (backward compatibility problem) or the host doesn't have miniperl. The bootstrap-tools built miniperl would then be used throughout the build and install stages. I think that's what we have in this case. We need the newer version of miniperl to build perl, correct? Yes, exactly. We were only building libperl (statically) and miniperl in the build-tools stage, so that miniperl (statically linked with libperl) is available for the building later. The choice to use crosstools is easier, since it by default installs the tool into the "strict path", but Mark used build-tools and a path to miniperl to do it instead, presumably since it is restricted to a very minor bit of the tree. (This reminds me that I have a skeleton document about 'make world' that needs serious attention. Too many projects.) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Check for ports updates
On Wed 2000-06-28 (15:13), Leif Neland wrote: Any reason not to put this into bsd.port.mk? make update It will break the system at least 20% of the time. Change 20% to 100% for gnome, kde, xpm, png, tiff, jpeg, and so forth. Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: building stable from current
On Thu 2000-06-22 (22:12), Kent Hauser wrote: For the last while (several months), whenever I try to build a RELENG_4 release from my -current box, it fails building gcc. As -current is supposed to be "fluid" for the next several months, I wanted to make a set of -current and -stable CDs now. The current build was fine. To build stable I did the following: # cd /usr; rm -rf src.stable;mkdir src.stable # rm -rf /usr/obj/usr/src.stable # su kent % cd src.stable % cvs -R -d /home/ncvs co -r RELENG_4 src % cd src.stable; mv src/* .;rmdir src % make buildworld build.log and it blew up linking cc1plus. I built -stable as me so as to be sure no system files were touched. But I'm also confused as I thought "buildworld" was self-contained -- as long as a reasonably current make was available to jump-start the process. Thoughts corrections greatly welcomed. Can you send the last 50 or so lines of build.log? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Missing openssl/idea.h?
On Fri 2000-06-23 (16:31), Sheldon Hearn wrote: Current sources as of 10H40 on 23 June 2000 build and install without problems (provided one pays attention to the new world order with respect to config(8)). The kernel boots and the system lives at least as long as it took me to type and send this message. :-) I can't find any local deltas in either of src/secure and src/crypto which might influence this. Do you have "WITH_IDEA" set? I had to manually set CFLAGS+= -DNO_IDEA in secure/libssh, secure/ssh, secure/ssh-keygen, and secure/sshd's Makefile from about 6 hours ago or so. (well, a .if !defined(WITH_IDEA) CFLAGS+=-DNO_IDEA .endif ) Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fetch | sh panics system
On Tue 2000-05-30 (16:28), Christian Weisgerber wrote: 5.0-CURRENT from ~May 17, dual ppro. The following, completely innocuous command line $ fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh (nbm@monster) /home/nbm uname -a FreeBSD monster.sunesi.com 5.0-CURRENT FreeBSD 5.0-CURRENT #12: Tue May 16 10:16:47 SAST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/SCRITCH i386 (nbm@monster) /home/nbm fetch -o - http://sites.inka.de/mips/unix/freebsd/xterm.shar | sh Receiving - (2136 bytes) 2136 bytes transferred in 0.0 seconds (4301.06 Kbytes/s) c - xterm c - xterm/pkg x - xterm/pkg/PLIST x - xterm/pkg/DESCR x - xterm/pkg/COMMENT c - xterm/files x - xterm/files/md5 x - xterm/Makefile Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Wrong permissions on /dev ?
On Sun 2000-05-21 (23:35), Arun Sharma wrote: I upgraded my 4.0-release laptop to 5.0-current today and my xe0 was recognized by the driver and everything was great. There is a minor nit about the permissions on /dev. It was not readable by others. So ps wouldn't work, because it could not open /dev/null. 'make world' doesn't (or at least, it shouldn't) touch permissions (or anything else) on /dev. Or was this a snapshot binary install? Neil -- Neil Blakey-Milner Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Breaking build world costs $5? (was: Can we please have acurrent that compiles?)
On Mon 2000-05-15 (11:43), Paul Richards wrote: The only problem being that at Desktop you can drop the $5 into the fine box when you leave work but I'd have to walk down the bank and either do a wire transfer or send an international money order. Apart from the hassle involved there's the fact that all told it will cost me in the region of $30-40 to pay the fine! A nice idea but not very practical for the FreeBSD project. The way I read it: "If you happen to be around a bunch of developers, and have some extra change, use the fact you broke world as an excuse to (help) buy them a round of drinks. Mention that it's because you broke world, and have a laugh about it." If you happen to be at BSDCon, so much the better, and may there be many merry nights of drunken revelry. It's team-building (ick!) in the fact that it gives you an easy opportunity to thank the people who work with you on the project, and to continue the pointy-hat metaphor for further amusement. There is no obligation, nor should there be. That's not how the project works, after all. Neil -- Neil Blakey-Milner Hacker In Chief, Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Archive pruning
On Sat 2000-04-29 (20:56), gh wrote: For an opinion from a reasonably new-comer and non-developer, I think at least the main source tree should remain *completely* complete. As someone mentioned, why not have "lite" mirrors? You are welcome to co-ordinate the resources (developer time, bandwidth, machines) to provide this service. Kindly don't continue this discussion in this (inappropriate) forum. Neil -- Neil Blakey-Milner Hacker In Chief, Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with MAKEDEV.
On Fri 2000-04-14 (18:34), David Scheidt wrote: Sure. What's the point of having both std and all, though? How much does it hurt to have a few extra device files kicking around? 'std' is standard devices (leaving out exotic ones), and 'all' is at least one of every device out there. Neil -- Neil Blakey-Milner Hacker In Chief, Sunesi Clinical Systems [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Upgrade 3.4 - 5.0 -current Success
On Tue 2000-04-04 (21:14), Thomas D. Dean wrote: I installed the 3.4 normal user, bin and docs on the new disk. I copied /etc, /usr/src and /usr/ports from the old -current disk. I did a make world to upgrade to -current. 'make world' had two problems. The buildworld phase completed successfully. There were two problems in the install phase. 1. install-info. The 3.4 version of install-info does not support the newest version of the flags, it wants -section, not -dsection. I copied the version in /usr/obj/usr/src/i386/usr/bin to /usr/bin and this problem was solved. Can 'make install' use /usr/obj/usr/src/i386/usr/bin/install-info? This is a known problem, and unfortunately my solution to it broke cross-compilation. Someone more intelligent may just fix it soon. 2. sh is installed and then is used in later in the installation process. The number of syscalls changed, so the new version of sh core dumps. I copied a 5.0-current kernel from another disk, rebooted, and install completed without error. Can make copy or link the existing version of sh to tools and use that during the install? I think you're supposed to reboot with a new kernel (built with 'make buildkernel make installkernel') and then installworld. This is the new 'one true way'. It's not supposed to work over more than one major version, so I doubt 3.4 - 5.0 will work for much longer. Good work on the make/install process. Cool. Marcel and others deserve a massive round of applause. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
On Thu 2000-02-17 (21:03), Matthew N. Dodd wrote: On Thu, 17 Feb 2000, Alfred Perlstein wrote: Yes, but the benifits of a correct implementation are quite awesome, a centralized logging place to dole out authentication and potentially administratively shutdown/lockout accounts if a brute force attempt (or other abuse) is detected. You've just described Kerberos. No, he just described something, amongst many many other things that might not be useful for mere mortals, that Kerberos can do. Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The Matrix screensaver, v.0.2
On Fri 1999-08-27 (10:25), Nick Hibma wrote: I seriously doubt they'll win this lawsuit. You can sue someone for anything and everything, including having a hair color which ^ in the States Or if you're a US company. Wasn't it (the Irish?) McMuffin which Mcdonalds sued for name infringment? Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
