> It is possible the Perl build Makefiles have a slight bogon that prevents
> things from working properly in this stage?
:-) Uh Huh!
> > > Note that bootstrap-tools are built (and installed under /obj) to be run
> >
> > OK - I'll try again fro build-tools.
>
> I tried that (on my Alpha). Sam
On Tue, Jun 27, 2000 at 08:08:15AM +0200, Mark Murray wrote:
> What you say supports the theory that build-tools is the answer; however
> build-tools seems to want to do an in-place build - not to install the
> tool(s) somewhere into the path like cross-tools. I'm in trouble with
> cross-tools bec
If I somehow cc'd the mailing list on this then I made a mistake which
I don't usually make. These messages, when I'm watching the headers
correctly, are always sent privately.
- Jordan
> On Monday, 26 June 2000 at 15:43:47 -0700, Jordan K. Hubbard wrote:
> >> SUBSCRIBE [EMAIL PROTECTED]
> >>
>
> > 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.
On Monday, 26 June 2000 at 15:43:47 -0700, Jordan K. Hubbard wrote:
>> SUBSCRIBE [EMAIL PROTECTED]
>>
>>
>> To Unsubscribe: send mail to [EMAIL PROTECTED]
>> with "unsubscribe freebsd-current" in the body of the message
>
> If you're receiving this message, it's because you just sent a
> "subscrib
Doing a make world, even after completely removing /usr/obj
cd /usr/src/gnu/usr.bin/perl; make build-tools
cd /usr/src/gnu/usr.bin/perl/libperl && make build-tools
mkdir: lib/auto: File exists
*** Error code 1
Stop in /usr/src/gnu/usr.bin/perl/libperl.
*** Error code 1
Stop in /usr/src/gnu/usr
> SUBSCRIBE [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
If you're receiving this message, it's because you just sent a
"subscribe" message erroneously to one of our mailing lists, resulting
in thousands (
On Mon, 26 Jun 2000, Kelly Yancey wrote:
>
> On a just-supped -current I am seeing:
>
> make: don't know how to make ../../dev/nulldev/nulldev.c. Stop
>
> on kernel builds (even GENERIC).
>
Nevermind, pilot error :(
--
Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA
System Administrat
On a just-supped -current I am seeing:
make: don't know how to make ../../dev/nulldev/nulldev.c. Stop
on kernel builds (even GENERIC).
Kelly
--
Kelly Yancey - [EMAIL PROTECTED] - Belmont, CA
System Administrator, eGroups.com http://www.egroups.com/
Maintainer, BSD Driv
SUBSCRIBE [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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.
>
>
In message <[EMAIL PROTECTED]> Nik Clayton writes:
: Another script would parse the above and generate HARDWARE.TXT. And another
: could parse the above and spit out DocBook for the Handbook and FAQ.
There's some problems witht his. the ed driver supports a whole raft
of cards, but who can lis
In message <[EMAIL PROTECTED]> Nik Clayton writes:
: In my world, this XML file would be a replacement for many of the files
: in src/sys/conf/. Or, at the very least, those files would be generated
: from this XML file. As a developer, if you don't update the file the
: system won't even know
It seems Mark Murray wrote:
> > If I'm not mistaken, all open problems are like "Perl lib version
> > (v5.6.0) doesn't match executable version (5.00503) at Config.pm line
> > 18."
>
> Hmm...
>
> > That should be easy to reproduce on your development system by just
> > copying an old /usr/bin/pe
> If I'm not mistaken, all open problems are like "Perl lib version
> (v5.6.0) doesn't match executable version (5.00503) at Config.pm line
> 18."
Hmm...
> That should be easy to reproduce on your development system by just
> copying an old /usr/bin/perl executable to it and trying to build.
Wh
Mark Murray wrote:
>
> > On Sun, 25 Jun 2000, Warner Losh wrote:
> >
> > > Some days is OK, imho. Much more than that and I'd begin to worry.
> > > Much more than a week or two and I'd worry a lot. I'll go put a note
> > > in updating right now.
> >
> > That's okay with me too. People should ju
> 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 i
In <[EMAIL PROTECTED]>, Mark Murray wrote:
> > Message to others for bootstrapping:
> >
> > Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624,
> > build and install it manually, then update both dirs to HEAD and do a
> > world with the new perl in place.
>
> Now you can colour
In <[EMAIL PROTECTED]>, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> Martin Cracauer writes:
> : [CC'ed to current]
> : Message to others for bootstrapping:
> :
> : Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624,
> : build and install it manually, then update both dir
> Message to others for bootstrapping:
>
> Checkout perl (contrib/perl5 and gnu/usr.bin/perl) from -D 2624,
> build and install it manually, then update both dirs to HEAD and do a
> world with the new perl in place.
Now you can colour me flummoxed. :-(.
Have you a script(1) of that?
M
--
M
On Mon, Jun 26, 2000 at 04:09:26PM +0200, Leif Neland wrote:
> How much does this "unrandomness" matter?
That's why I said `depending on the application'.
It probably doesn't matter too much for a Kerberos session key that will
be used for the duration of an ftp session.
It definately matters i
In message <[EMAIL PROTECTED]> Martin Cracauer writes:
: [CC'ed to current]
:
: In <[EMAIL PROTECTED]>, Martin Cracauer wrote:
: > In <[EMAIL PROTECTED]>, Mark Murray wrote:
: > > May I have a login on your build box to have a look?
: >
: > It would be more useful if you could put a log of you
unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
< said:
> I guess that the perfect solution is to be able to hardwire the PCI irqs
> in some way once FreeBSD is doing the PnP resource allocation.
On typical non-SMP motherboards, the PCI IRQs are hard-wired on the
motherboard. That is to say, INTA of slot 13 is wire-OR'd with INTB of
slot 14,
[CC'ed to current]
In <[EMAIL PROTECTED]>, Martin Cracauer wrote:
> In <[EMAIL PROTECTED]>, Mark Murray wrote:
> > May I have a login on your build box to have a look?
>
> It would be more useful if you could put a log of your buildworld (at
> least the perl-related parts) somewhere so I can l
duh... that was too simple... :-)
=
| Kenneth Culver | FreeBSD: The best NT upgrade|
| Unix Systems Administrator | ICQ #: 24767726 |
| and student at The | AIM: muythaibxr
On Sat, Jun 24, 2000 at 06:32:47PM -0500, Mike Pritchard wrote:
>
> SYNOPSIS
> device isa
> device ata0 at isa? port IO_WD1 irq 14
> device ata1 at isa? port IO_WD2 irq 15
>
>
> Should this become:
>
> SYNOPSIS
> device isa
> device ata
> hint.ata.0.at="isa"
> hint.
Chuck Robey wrote:
> deviceda0 at scbus 0 target 0
> deviceda1 at scbus 0 target 2
> deviceda2 at scbus 1 target 1
>
> devicecd0 at scbus?
> devicecd1 at scbus?
Change 'scbus 0' to 'scbus0' and 'scbus 1' to 'scbus1'
On Mon, Jun 26, 2000 at 08:40:44PM +0900, Daniel C. Sobral wrote:
> Jun Kuriyama wrote:
>
> > And we should keep that master text simple to ease modification by
> > hackers. If we force to write complex markups, hackers will *forget*
> > to update that master text. :-)
>
> I'm not sure I would
How much does this "unrandomness" matter?
How often are keys generated? If only once per program, then does it really
matter if the keys are generated randomly or from my mothers maiden name?
Leif
- Original Message -
From: "Jacques A . Vidrine" <[EMAIL PROTECTED]>
To: "Kris Kennaway" <
It seems Poul-Henning Kamp wrote:
>
> Who knows the cure for this ?
I do :)
Rip out perl from the base system ...
(ducks and runs)
-Søren
> ===> gnu/usr.bin/perl/perl
> Extracting config.h (with variable substitutions)
> Extracting cflags (with variable substitutions)
> Extracting writemain
> I'm not sure if this is correct, but I got through the perl build problem
> with the following patch:
I did something that is effectively the same.
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-curr
> On Sun, Jun 25, 2000 at 12:35:12PM +0200, Mark Murray wrote:
> > 3) It is not built by default (except as a kernel module), so you
> >either need to add the "options RANDOMDEV" like to your kernel
> >config, or load it at boot time in /dev/loader.conf
>
> Can't things be made to autoloa
Yeah, I will say that pkg_info could get a lot more featureful
than it is now without "exceeding its mandate." It would have
been better than a profusion of tools.
- Jordan
>
>
> On Mon, 26 Jun 2000 00:57:00 MST, Jeremy Lea wrote:
>
> > I've placed the source for a new command, pkg_which, on
Hi,
On Mon, Jun 26, 2000 at 12:30:09PM +0200, Sheldon Hearn wrote:
> Argh, yet another pkg_* command that looks (at first glance anyway) like
> it should have been implemented as a feature enhancement to the existing
> pkg_* tools.
>
> What is it that makes this unsuitable for incorporation into
Who knows the cure for this ?
===> gnu/usr.bin/perl/perl
Extracting config.h (with variable substitutions)
Extracting cflags (with variable substitutions)
Extracting writemain (with variable substitutions)
Extracting myconfig (with variable substitutions)
Perl lib version (v5.6.0) doesn't match
Folks,
I haven't honestly debugged this one yet, so feel free to ignore me.
Just a heads-up. I'm trying to install a new system using -current
snapshot boot floppies. I boot the kernel, then I load the mfs
root. Screen turns blue, no messages at all. (No probing for
devices msg.) If I give a
On Mon, Jun 26, 2000 at 08:40:44PM +0900, Daniel C. Sobral wrote:
> Jun Kuriyama wrote:
>
> > And we should keep that master text simple to ease modification by
> > hackers. If we force to write complex markups, hackers will *forget*
> > to update that master text. :-)
>
> I'm not sure I would
winmail.dat
On Sun, Jun 25, 2000 at 12:55:47PM -0700, Kris Kennaway wrote:
> > > I don't know which applications depend on /dev/random providing entropy
> > > and which gather their own.
> SSH and SSL should not be used: PGP should be okay.
FWIW, a quick look indicates:
MIT Kerberos V gathers its own ``en
On Mon, 26 Jun 2000, Peter Wemm wrote:
> > What does ``hint.scbus.1.bus="0"'' mean? Do I have to stick a number
> > after the "device ahc" and "device scbus" lines (the NOTES file
> > doesn't). Are there any other oddities I ought to know of?
>
> It works the same as the other devices:
>
> 'd
Jun Kuriyama wrote:
> And we should keep that master text simple to ease modification by
> hackers. If we force to write complex markups, hackers will *forget*
> to update that master text. :-)
I'm not sure I would *forget* it, but I my indulge in "forget"ing it.
:-)
--
Daniel C. Sobral
Michael Wlliams wrote:
>
> I'm catching up on email, sorry if this was answered... are you talking
> OBP/Forth
> on Suns? Try
> ok sifting foo
> to get a list of words with foo in them (kinda like grep foo). Try
> ok see foo
> to see the details of the word (if you get forth this will help.)
>
>
On Mon, Jun 26, 2000 at 07:27:39PM +0900, Jun Kuriyama wrote:
> So first of all, we (documentation project) should develop prototype
> tool to achive that conversion.
>
> And we should keep that master text simple to ease modification by
> hackers. If we force to write complex markups, hackers w
> > >From what I understood from dfr, when switching away from an interrupt
> > handler it is converted into a full thread. When the second piece of
> > hardware fires an interrupt it could then run at the same time.
>
> I thought of this almost immediately - it's a bad idea though because it
>
On Mon, 26 Jun 2000 00:57:00 MST, Jeremy Lea wrote:
> I've placed the source for a new command, pkg_which, on
> http://people.freebsd.org/~reg/.
Argh, yet another pkg_* command that looks (at first glance anyway) like
it should have been implemented as a feature enhancement to the existing
pkg
At 26 Jun 2000 09:33:30 GMT,
nik wrote:
> We have a problem with keeping our documentation up to date. One of the
> most glaring examples of this is the hardware compatability list. We
> currently list hardware information in LINT, HARDWARE.TXT, the FAQ, and the
> Handbook. Any time this inform
From: [EMAIL PROTECTED] (Munehiro Matsuda)
Date: Mon, 26 Jun 2000 16:53:35 +0900
::Mark,
::
::I'm not sure if this is correct, but I got through the perl build problem
::with the following patch:
::-8<--8<--8<--
::-8<--8<
On Thu, Jun 22, 2000 at 10:12:28PM -0400, 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.
Yes. (but it should only have been for the past 1.5 mos).
There are two ways to fix it. One will be done
On Fri, Jun 23, 2000 at 11:04:10PM -0700, Kelly Yancey wrote:
>
> Can you guys post the output of:
>
> $ ipcs -bmo | awk -- '/^m/ {num++;total+=$7*$8}; END {print num,(total/4096)}'
>
> taken while you are experiencing the problem. The first number is the total
> number of shared memory segment
On Fri, 23 Jun 2000 19:05:14 +0200, Stefan Esser wrote:
> 1) I choose "quad_t" for long integers. Is this a good choice ?
>In the kernel I'd use int64_t, but I'm not sure what is most
>appropriate here.
I'd use the new C standard's int64_t, since you're specifically looking
for 64-bit
Chuck Robey wrote:
> On Sun, 25 Jun 2000, Kenneth Wayne Culver wrote:
>
> > Hey chuck, except for the SMP stuff, your config looks mostly like mine (I
> > only have a cpu line for i686) Let me know if there's anything I can do to
> > help though.
>
> I'm about ready to post again, so this is goo
[ Sent to -doc, for info, -current for some expert advice on the feasability
of this approach with FreeBSD's migration to a kernel consisting only of
aggregated devices. ]
We have a problem with keeping our documentation up to date. One of the
most glaring examples of this is the hardware c
Chuck Robey wrote:
> I am getting a config error with the new gethints.pl stuff:
>
> unrecognized config token 1
This means the decoder for 'device ed0 at isa? flags 1' style lines
did not like what was in one of your device lines. I have added
a new line number message in the error so that it
On Sun, 25 Jun 2000 17:27:28 +0900, "Daniel C. Sobral" wrote:
> This definitely needs some work. I'm not sure the hints syntax will
> change much, if at all. OTOH, I don't know how to approach this. In
> other words, suggestions (and specially patches) are welcome.
Actually, I think that this
On Sun, Jun 25, 2000 at 12:35:12PM +0200, Mark Murray wrote:
> 3) It is not built by default (except as a kernel module), so you
>either need to add the "options RANDOMDEV" like to your kernel
>config, or load it at boot time in /dev/loader.conf
Can't things be made to autoload random.ko
On Sun, Jun 25, 2000 at 10:17:27PM +0200, Mark Murray wrote:
> 2) With the SMP "Destabilization" of the tree coming, I took the
>opportunity because
>a) Merging differences was going to get harder; and
>b) folk were already warned off the use off CURRENT for
> production purposes
On Sun, Jun 25, 2000 at 01:21:10PM -0700, Kris Kennaway wrote:
> > 1) I whined for reviews for long enough. Where were you?
>
> Waiting until the code was complete and nominally commitworthy before
> spending time reviewing it.
\begin{AOL}
me too
\end{AOL}
--
-- David ([EMAIL PROTECTED])
On Sun, Jun 25, 2000 at 12:55:47PM -0700, Kris Kennaway wrote:
> I must say I'm not all that comfortable with this series of commits - I
> was expecting this to stay in Mark's tree until it at least tries to do
> everything the old driver did. Weakening system security like this for an
> indetermi
Jeremy Lea wrote:
> Hi guys,
>
> This is BCC'd to ports, since it is mostly for use there...
>
> I've placed the source for a new command, pkg_which, on
> http://people.freebsd.org/~reg/.
>
> The idea behind this command is to get Ports/Packages to register their
> dependencies based on what is o
>
> What about shared interrupts? How are they going to be treated? With the
> spl leaving the arena it somehow looks feasible to run one interrupt
> source on two different threads if there are two pieces of hardware
> attached to the same interrupt line.
>
> >From what I understood from dfr, w
Hi guys,
This is BCC'd to ports, since it is mostly for use there...
I've placed the source for a new command, pkg_which, on
http://people.freebsd.org/~reg/.
The idea behind this command is to get Ports/Packages to register their
dependencies based on what is on the system, not what they think
Date: Mon, 26 Jun 2000 08:42:43 +0200
From: Mark Murray <[EMAIL PROTECTED]>
::> This indicates to me that configpm is not reading Config.pm from the obj
::> directory, which does contain the correct value that configpm is looking
::> for at line 433.
::>
::> I'm not sure what the fix is, but
Doug Barton wrote:
> Semi-PS, I'd like to put in a vote for your /dev/random work to be
> completed before the SMP destabilization begins. It would be nice to
> have a fully-working -Current to fall back on before the axes start to
> fall. :)
I second to this.
-Maxim
To Unsubscribe:
Mark Murray wrote:
>
> > This indicates to me that configpm is not reading Config.pm from the obj
> > directory, which does contain the correct value that configpm is looking
> > for at line 433.
> >
> > I'm not sure what the fix is, but hopefully this'll help mark down the
> > road.
>
> T
On Sun, 25 Jun 2000, Soren Schmidt wrote:
> It seems Mark Murray wrote:
> > > > Without knowing what you typed (and where), I can't help.
> > >
> > > Well, I thought that was obvious :)
> >
> > Not really; folks do the darndest things. :-)
> >
> > > Just added options RANDOMDEV as pr your inst
66 matches
Mail list logo
