Re: HEADS UP! New (incomplete) /dev/random device!
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 just not upgrade their work machines for the next few days until entropy is fixed. Upgrading is fine; just don't build certificates/credentials. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
On Mon, 26 Jun 2000, Mark Murray wrote: That's okay with me too. People should just not upgrade their work machines for the next few days until entropy is fixed. Upgrading is fine; just don't build certificates/credentials. Or use ssh Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vendor import of Perl 5.6
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. Thanks! You're building threads, right? M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems with nlist on -current?
Bernd Luevelsmeyer wrote: Dampure, Pierre Y. wrote: I installed 5.0-2621-CURRENT on a new system (OR840, 2x733EB, 512MB RDRAM) and had problems with top / systat / vmstat all failing after reporting problems with nlist: [...] At a guess, you don't use /boot/loader? The loader seems to be no longer optional, see http://www.FreeBSD.org/cgi/query-pr.cgi?pr=17422 This problem has been discussed several times in the "questions" mailing list, and R. Ermilov kindly mailed 2 patches: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=1186602+1196206+/usr/local/www/db/text/2000/freebsd-questions/2409.freebsd-questions (While I'm at it, may I suggest that the patches be committed? I'm using them for more than a month now on 4.0-Stable, and they work just fine.) My system has 4 SCSI disks, W2K on disk 0, FreeBSD on 1, 2 and 3 (FreeBSD Multiboot installed on disk 0; disks 1, 2 and 3 all in dedicated mode). At boot time, boo2 throws out a 'No /boot/loader' messages, then proceeds to load the kernel normally. So... I guess indeed I do not use /boot/loader, though not of my own will. Thanks for the pointers! PYD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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 instructions and made a new kernel with config -r and make depend then make Do you have a full crypto distribution (kernel also)? Nope, just figured that out myself :) Aren't we supposed to be able to build without crypto ?? Since the random dev is a cryptographically strong PRNG, I think its reasonable to depend on the crypto kernel bits. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vendor import of Perl 5.6
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. Thanks! You're building threads, right? No... should I be? The only perl related item in /etc/make.conf is: NOSUIDPERL= true I forgot to mention that my cvs update happened after your commit to perl.h. Anything I can do to help, let me know. 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. :) Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/dev/random, Perl 5.6 SMP destabilisation (Was: Vendor import of Perl 5.6)
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: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vendor import of Perl 5.6
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 hopefully this'll help mark down the
:: road.
::
::Thanks! You're building threads, right?
Mark,
I'm not sure if this is correct, but I got through the perl build problem
with the following patch:
-8--8--8--
--- contrib/perl5/configpm.ctm Mon Jun 26 13:10:55 2000
+++ contrib/perl5/configpm Mon Jun 26 16:33:13 2000
@@ -17,7 +17,7 @@
open CONFIG, "$config_pm" or die "Can't open $config_pm: $!\n";
-$myver = sprintf "v%vd", $^V;
+$myver = $];
print CONFIG 'ENDOFBEG_NOQ', "ENDOFBEG";
package Config;
@@ -430,11 +430,11 @@
import Config;
die "$0: $config_pm not valid"
- unless $Config{'CONFIGDOTSH'} eq 'true';
+ unless $Config{'CONFIG'} eq 'true';
die "$0: error processing $config_pm"
if defined($Config{'an impossible name'})
- or $Config{'CONFIGDOTSH'} ne 'true' # test cache
+ or $Config{'CONFIG'} ne 'true' # test cache
;
die "$0: error processing $config_pm"
-8--8--8--
BTW, my buildworld is still going, so should know the results
in a few hours.
Hope this helps,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Business Incubation Dept., Kubota Corp.
/|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome
Chuo-ku Tokyo 103-8310, Japan
Tel: +81-3-3245-3318 Fax: +81-3-3245-3315
Email: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Call for review: pkg_which.
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 should be there. Thus, if you have old libraries or a different version of shostscript installed, this will allow the system to register the correct dependency. Patches to bsd.port.mk and pkg_add to follow shortly. At the moment I'd like some people to test and review this. It works for me, but history has shown that to be a poor indicator of real success. Also, I'm not used to style(9), so this might be a mess, and the man page certainly needs some work. Regards, -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
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, 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 makes it hard to determine when to EOI an interrupt. If you expect to perform significant processing in your interrupt handler, you should consider a taskq. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review: pkg_which.
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 on the system, not what they think should be there. Thus, if you have old libraries or a different version of shostscript installed, this will allow the system to register the correct dependency. Patches to bsd.port.mk and pkg_add to follow shortly. At the moment I'd like some people to test and review this. It works for me, but history has shown that to be a poor indicator of real success. Also, I'm not used to style(9), so this might be a mess, and the man page certainly needs some work. Some time ago I had similar idea, but thought about slightly different approach - use existing pkg_info facilities instead of adding new command. Idea is simple: add new option to the pkg_info, for example "-f" which takes name of the file and names of several installed packages. Then pkg_info examines PLISTs of those packages and returns 0 if the file belongs to those packages or 1 if it is not (e.g. pkg_info -f /usr/local/bin/somefile package1-1.0 package2-1.0). This could be easily implemented without much bloat (I think 30-40 lines of additional code will be sufficient). -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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 indeterminate period really bothers me. Agreed. Unlike the upcoming SMPng work, I don't see why this couldn't have been done until the new random device code was fully ready. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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. Your code touched so many files and functions that you could not have not updated your /usr/src/sys for 2 weeks? It is possible to develop on something more than 1 hour old. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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 as happens for if_fxp.ko when I ifconfig it, or msdos.ko and procfs.ko when I mount them. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
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 should be easier to spot what is going on. /home/ncvs/src/sys/i386/conf/gethints.pl,v -- gethints.pl new revision: 1.5; previous revision: 1.4 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
XML driver config file to replace LINT
[ 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 compatability list. We currently list hardware information in LINT, HARDWARE.TXT, the FAQ, and the Handbook. Any time this information changes it has to be updated in all these places (and possibly more). This does not always happen. I'm thinking of abstracting out our list of supported hardware in to one file, marked up according to an XML DTD. Something like [...] device classkeyboard controller/class configdevice atkbdc0 at isa? port IO_KBD/config commentThe keyboard controller; it controls the keyboard and the PS/2 mouse./comment /device device classkeyboard/class configdevice atkbd0 at atkbdc? irq 1/config commentThe AT keyboard/command options optionATKBD_DFLT_KEYMAP/option commentSpecify the built-in keymap/comment optionKBD_DISABLE_KEYMAP_LOAD/option commentRefuse to load a keymap/comment optionKBD_INSTALL_CDEV/option commentInstall a CDEV entry in /dev/comment /options flags flag0x01/flag commentForce detection of keyboard, else we always assume a keyboard/comment flag0x02/flag commentDon't reset keyboard, useful for some new ThinkPads/comment flag0x04/flag commentOld-style (XT) keyboard support, useful for older ThinkPads/comment /flags /device [ That schema is not set in stone, and certainly requires more work. In particular, we probably need "lang" and "encoding" options on the comment element, to support comments in more than one language. ] LINT would then become a skeletal file for things which don't fit this sort of pattern, and the full LINT would be generated by a script which parsed the above and the skeletal file to generate the full LINT. 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. Still another (CGI) script could sit on the website. I'm enamoured of BSDi's hardware selection CGI script on their website. You can choose from a drop down list of supported hardware and/or manufacturers, or do a free text search, and get back a formatted list of all the matching hardware, entries for the kernel config file, links back to the manufacturer's website where necessary, and comments about the suitability or otherwise of specific hardware for specific tasks. We could do something similar today without the above, XML stuff, but it would require duplicating the hardware list in yet another place, which would be a bad thing. The solution I'm proposing would keep all the hardware information in one place, where it would be the driver developer's responsibility to maintain. What I don't know is how this scheme fits in with FreeBSD's future direction. From scanning -current I know that the aim is to have a kernel with very few devices compiled in to it -- devices will be probed once, and if the probe runs true the rest of the device driver will be loaded in. In particular, the phrase "config(8) must die" is bandied about with increasing frequency. I assume, however, that there will still be a place for a statically compiled and configured FreeBSD kernel -- embedded devices, or where you don't want the kernel to load certain devices, or whatever. Can -current provide -doc with a roadmap of where we're heading in this respect, and how a scheme like the above should fit in. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
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 good timing. I got the totally vague warning from gethints.pl to quiet by making my disk section look much like the NOTES file. I then ran it by a brand new config, and out spewed more than 25 errors. The entire section on wiring down disks fails, and also all the stuff on npx, even tho that part was copied verbatim from NOTES. You should get no errors from gethints.pl based on the disk section in NOTES file because those entries are actual hints for device.hints, not something that you put in a config file and feed to gethints.pl. I have an Adaptec dual channel controller on my motherboard, and I have 3 disks and 2 cdroms, which I want to wire down. There's lines in the NOTES examples whose meanings just make no sense to me. Let me do a bit of quoting: [from NOTES] hint.scbus.0.at="ahc0" hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" hint.scbus.3.at="ahc2" hint.scbus.3.bus="0" hint.scbus.2.at="ahc2" hint.scbus.2.bus="1" hint.da.0.at="scbus0" hint.da.0.target="0" hint.da.0.unit="0" hint.da.1.at="scbus3" hint.da.1.target="1" hint.da.2.at="scbus2" hint.da.2.target="3" hint.sa.1.at="scbus1" hint.sa.1.target="6" 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: 'device scbus1 at ahc1 bus 0' becomes: hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" When you have a trailing '?' character in an 'at' binding, you leave it out. eg: hint.scbus.1.at="ahc" (which would have meant "device scbus1 at ahc?") You do not stick numbers after the 'device ahc' and 'device scbus' lines. The device wiring comes from the hints (either /boot/device.hints or the statically compiled in hints) Perhaps you should post your old *ORIGINAL* config file and I'll do a worked example conversion... Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Extend test and expr to 64 bit integers
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 width integers. 2) There is a new dependency on sys/types.h in test.c (for any of our 64 bit integer types). These exact-width integer types should really be defined in inttype.h, no? 3) The changes to "expr" rely on 32 bit integers being promoted to 64 bit integers in function calls (actually only invocations of make_integer().) IT's probably worth chatting the the NetBSD folks about this, since that's where we got our version of test(1). What does Posix say about these programs ? As long as your operands are integers, POSIX.2 is happy. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Gnome INSANE shared memory usage
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 segments currently active and the second should be the
total number of shared memory pages in use. Thanks,
Kelly
Hi,
just FYI, I don't know whether this is much but my machine is definitely
more lagged compared to when I just started X.
FreeBSD 5.0-CURRENT #6: Mon Jun 5 17:06:37 CEST 2000
(yeah it's a bit out of date...)
$ ipcs -bmo | awk -- '/^m/ {num++;total+=$7*$8}; END {print num,(total/4096)}'
47 1362
Running GNOME 1.2, XFree4 with the ati driver (Dell Optiplex onboard chip).
--Stijn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: building stable from current
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 before 4.1. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vendor import of Perl 5.6
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-- snip ::-8--8--8-- :: ::BTW, my buildworld is still going, so should know the results ::in a few hours. Mark, My patch failed with following error, on "stage 4: make dependencies". -8--8--8-- === 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) miniperl -I/usr/obj/usr/src/gnu/usr.bin/perl/perl/lib -e 'use AutoSplit; autosplit_lib_modules(@ARGV)' lib/*.pm lib/*/*.pm Perl 5.00564 required--this is only version 5.00503, stopped at /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/AutoSplit.pm line 3. BEGIN failed--compilation aborted at /usr/obj/usr/src/gnu/usr.bin/perl/perl/lib/AutoSplit.pm line 3. BEGIN failed--compilation aborted at -e line 1. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 -8--8--8-- I don't think I can fix this one. sorry. :-( Haro, =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
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 information changes it has to be updated in all these places (and possibly more). This does not always happen. I don't like "Everything should be written in XML" type thought. But consept for automatic updating of document would be fine. 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 will *forget* to update that master text. :-) LINT would then become a skeletal file for things which don't fit this sort of pattern, and the full LINT would be generated by a script which parsed the above and the skeletal file to generate the full LINT. I think developpers may dislike to install doc toolchain to build LINT file. $CVSROOT/src tree should not depend on doc toolchain. Another idea is to write some script to convert LINT to LINT.xml for documentation. And website and documents depend on it. Yes, this is not ideal world from the point of SGML/XML view, but we should not bother hackers' development in the source tree. -- Jun Kuriyama [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review: pkg_which.
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_* tools. What is it that makes this unsuitable for incorporation into the existing tools? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
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 makes it hard to determine when to EOI an interrupt. If you expect to perform significant processing in your interrupt handler, you should consider a taskq. Right. It would be nice however to not have to go through the trouble of moving things onto different interrupts. Current BIOS's do not quite let you decide on which interrupt you would like to have assigned to the various cards. It will spread them in some way, but that might not spread the two high interrupt count cards onto separate interrupts. You have to move the hardware around in the slots to get things sorted in some cases. 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. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
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 will *forget* to update that master text. :-) The aim is that we have one file that describes the drivers -- this file will be used by us to keep the documentation up to date, but it will also be used by the system -- if the driver writer doesn't update this file then the system won't know about their driver, and won't build it. They'll *have* to keep it up to date. LINT would then become a skeletal file for things which don't fit this sort of pattern, and the full LINT would be generated by a script which parsed the above and the skeletal file to generate the full LINT. I think developpers may dislike to install doc toolchain to build LINT file. $CVSROOT/src tree should not depend on doc toolchain. Agreed. But Perl (already in the base system) plus a Perl XML module should be OK? Another idea is to write some script to convert LINT to LINT.xml for documentation. And website and documents depend on it. Yes, this is not ideal world from the point of SGML/XML view, but we should not bother hackers' development in the source tree. I disagree. We're not Linux, where people can throw in code without thought to the wider consequences -- one of the commitments you should make (that's a generic "you" there, not you specifically) as a FreeBSD committer is to maintain the documentation that's affected by your changes. A look at HARDWARE.TXT shows that (with a few notable exceptions) the FreeBSD Developer Community at large is *not* keeping it up to date. N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
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.) If you're not doing forth/obp... my apologies for the irrelevancy. Mike Williams He is talking loader(8). Mm. Sifting looks cool. I may add it... -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
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(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Windows works, for sufficently small values of "works". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
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: 'device scbus1 at ahc1 bus 0' becomes: hint.scbus.1.at="ahc1" hint.scbus.1.bus="0" When you have a trailing '?' character in an 'at' binding, you leave it out. eg: hint.scbus.1.at="ahc" (which would have meant "device scbus1 at ahc?") You do not stick numbers after the 'device ahc' and 'device scbus' lines. The device wiring comes from the hints (either /boot/device.hints or the statically compiled in hints) Perhaps you should post your old *ORIGINAL* config file and I'll do a worked example conversion... Sure, OK. Here's the last one I've been using, before I did any editing. I have five scsi devices. The disks are wired down, the cd's are not wired down here, but they show up on ahc1 targets 5 6 (show them floating, for more variety in the example). machine i386 cpu I586_CPU cpu I686_CPU ident CH maxusers64 # Create a SMP capable kernel (mandatory options): options SMP # Symmetric MultiProcessor Kernel options APIC_IO # Symmetric (APIC) I/O # Optional, these are the defaults: options NCPU=2 # number of CPUs options NBUS=4 # number of busses options NAPIC=1 # number of IO APICs options NINTR=24# number of INTs options SYSVSHM options SYSVSEM options INCLUDE_CONFIG_FILE options SYSVMSG options MSGBUF_SIZE=40960 options NETATALK#Appletalk communications protocols options NETGRAPH#netgraph(4) system options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L # Lets always enable the kernel debugger for SMP. options DDB options GPL_MATH_EMULATE#Support for x87 emulation via options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS_ROOT options FFS #Berkeley Fast Filesystem options NFS #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=8000 #Be pessimistic about Joe SCSI device options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options SOFTUPDATES options VESA# needs VM86 defined too!! options COMPAT_LINUX # If you see the "calcru: negative time of %ld usec for pid %d (%s)\n" # message you probably have some broken sw/hw which disables interrupts # for too long. You can make the system more resistant to this by # choosing a high value for NTIMECOUNTER. The default is 5, there # is no upper limit but more than a couple of hundred are not productive. # A better strategy may be to sysctl -w kern.timecounter.method=1 options NTIMECOUNTER=20 options ROOTDEVNAME=\"ufs:da0s1a\" device isa0 device eisa0 #controller pnp0 device pci0 device fdc0at isa? port IO_FD1 irq 6 drq 2 device fd0 at fdc0 drive 0 # A single entry for any of these controllers (ncr, ahb, ahc, amd) is # sufficient for any number of installed devices. device ahc0 device ahc1 device scbus0 at ahc0 device scbus1 at ahc1 device pcm0 device bktr0 device iicbus0 device iicbb0 device smbus0 # The Numeric Processing eXtension driver. This should be configured if # your machine has a math co-processor, unless the coprocessor is very # buggy. If it is not configured then you *must* configure math emulation # (see above). If both npx0 and emulation are configured, then only npx0 # is used (provided it works). device npx0at nexus? port IO_NPX iosiz 0x0 flags 0x0 irq 13 device da0 at scbus 0 target 0 device da1 at scbus 0 target 2 device da2 at scbus 1 target 1 device cd0 at scbus? device cd1 at scbus? # The keyboard controller; it controlls the keyboard and the PS/2 mouse. device atkbdc0 at isa? port IO_KBD # The AT keyboard device atkbd0 at atkbdc? irq 1 # new syscons stuff device vga0at isa? port ? device sc0 at isa? device
Re: HEADS UP! New (incomplete) /dev/random device!
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 ``entropy'' when generating random keys Heimdal uses /dev/random This matters in particular for creating keys for servers. Session keys may or may not be a big deal, depending on the application. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
unsubscribe
winmail.dat
Re: XML driver config file to replace LINT
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 *forget* it, but I my indulge in "forget"ing it. :-) How about a couple of fields in the driver source itself, along the lines of http://publicsource.apple.com/projects/headerdoc/ If it's part of the source that the developers are working with, then it's more likely to stay "right". Of course we all know that comment bugs exist. -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current snapshot 0526 sysinstall failure
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 keypress (space or enter) andI get a message at the bottom of the screen saying that accessing md1 failed and the system is rebooting. Why would sysinstall be looking for md1?!? mfsroot is clearly loaded, since sysinstall ran... confused. Paul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Make World is hosed...
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 executable version (5.00503) at Config.p m line 18. *** Error code 255 Stop in /syv/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /syv/src/gnu/usr.bin/perl. *** Error code 1 -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Call for review: pkg_which.
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 the
existing tools?
I thought about doing it within pkg_info, but it would mean changing the
logic flow there a lot. Basically, pkg_info takes package names on the
command line, and itterates over them. pkg_which takes file names, and
(will) itterate over them. Also, pkg_which always operates on all of
the installed packages, and never on packages which it must obtain via
FTP. I don't see any reason to check a subset of packages, or to check
packages which have not been installed.
I've yet to implement a few features, one being support for multiple
files (not difficult once things work for one). With this I can do
things like:
CHK_PLIST=`cat ${PLIST} | sed -e '/^@/d' -e 's#^#${PREFIX}#'`
CONFLICTING_PACKAGES=`pkg_which ${CHK_PLIST}`
if [ -n ${CONFLICT_PACKAGES} ]; then
${ECHO_MSG} "WARNING: This port will overwrite existing " \
"files installed by the following package(s): " \
${CONFLICTING_PACAKGES}
fi
in bsd.port.mk.
I also want to move most of the core logic into the pkg_install library,
so that I can use it for pkg_add. My next task is an extension to
pkg_add which will make it's dependency mechanism work like that for
ports. It will look like this in the PLIST (to preserve compatability):
@pkgdep glib-1.2.8
@comment libdep:glib12.3
Which I can add magic processing for into pkg_add, which will check for
the existance of glib12.3 (via pkg_which -l) and work out that it might
rather depend on an installed glib-1.2.7. Also, pkg_upgrade is going to
need to know why packages depend on one another.
Regards,
-Jeremy
--
FreeBSD - Because the best things in life are free...
http://www.freebsd.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Call for review: pkg_which.
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 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_* tools. What is it that makes this unsuitable for incorporation into the existing tools? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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 as happens for if_fxp.ko when I ifconfig it, or msdos.ko and procfs.ko when I mount them. I'd like to do this, but there is no "trigger" that can be hooked to do the work (mount and ifconfig can both do the work, but where do you hook a read(2) from /dev/random?) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Vendor import of Perl 5.6
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-current" in the body of the message
Re: Make World is hosed...
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 (with variable substitutions) Extracting myconfig (with variable substitutions) Perl lib version (v5.6.0) doesn't match executable version (5.00503) at Config.p m line 18. *** Error code 255 Stop in /syv/src/gnu/usr.bin/perl/perl. *** Error code 1 Stop in /syv/src/gnu/usr.bin/perl. *** Error code 1 -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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" [EMAIL PROTECTED] Cc: "Mark Murray" [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 26, 2000 3:25 PM Subject: Re: HEADS UP! New (incomplete) /dev/random device! 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 ``entropy'' when generating random keys Heimdal uses /dev/random This matters in particular for creating keys for servers. Session keys may or may not be a big deal, depending on the application. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
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 *forget* it, but I my indulge in "forget"ing it. :-) Typical, I've found the files I was looking for after I make the post. 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 about your driver (or option). N -- Internet connection, $19.95 a month. Computer, $799.95. Modem, $149.95. Telephone line, $24.95 a month. Software, free. USENET transmission, hundreds if not thousands of dollars. Thinking before posting, priceless. Somethings in life you can't buy. For everything else, there's MasterCard. -- Graham Reed, in the Scary Devil Monastery To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
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' and the gethints.pl script will understand it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP!: config changes...
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.ata.0.port="0x1F0" hint.ata.0.irq="14" hint.ata.1.at="isa" hint.ata.1.port="0x170" How about adding a hint to the hint driver itself. E.g. SYNOPSIS device isa device ata hint "hintsfile"# see hint(4) -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Config problems
duh... that was too simple... :-) = | Kenneth Culver | FreeBSD: The best NT upgrade| | Unix Systems Administrator | ICQ #: 24767726 | | and student at The | AIM: muythaibxr | | The University of Maryland, | Website: (Under Construction) | | College Park. | http://www.wam.umd.edu/~culverk/| = On Mon, 26 Jun 2000, Peter Wemm wrote: Chuck Robey wrote: device da0 at scbus 0 target 0 device da1 at scbus 0 target 2 device da2 at scbus 1 target 1 device cd0 at scbus? device cd1 at scbus? Change 'scbus 0' to 'scbus0' and 'scbus 1' to 'scbus1' and the gethints.pl script will understand it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Bootstrapping perl (Re: cvs commit: src/gnu/usr.bin/perl Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
[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 look how EXTERN.h is supposed to be built and where it ends up. Never mind, I'm now through it, this time my tree has hosed due to the testing I did earlier today. 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. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: irunning, width in bits.
On Mon, 26 Jun 2000 11:29:39 +0100 (BST), Nick Hibma [EMAIL PROTECTED] 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, is wire-OR'd with INTC of slot 15, is wire-OR'd with INTD of slot 16, and oh, yeah, is also wire-OR'd with INTA of every on-motherboard device. SMP motherboards tend to be significantly better in this regard. The PCI BIOS includes a function which gives you the map of how interrupts are wired together. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
No Subject
unsubscribe 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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 your buildworld (at : least the perl-related parts) somewhere so I can look how EXTERN.h is : supposed to be built and where it ends up. : : Never mind, I'm now through it, this time my tree has hosed due to the : testing I did earlier today. : : 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. Does this mean that I need to add a ntoe to UPDATING? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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 if you just generated a keytab to use for your new server, and you use that key for the lifetime of your server (not atypical). 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? Consult Schroedinger's cat. Maybe it only `matters' if someone is looking for weak keys in your environment. :-) -- Jacques Vidrine / [EMAIL PROTECTED] / [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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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 -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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 dirs to HEAD and do a : world with the new perl in place. Does this mean that I need to add a ntoe to UPDATING? I rather think that it should be fixed. Imagine going from 4-stable to 5-current: in that case you probably can't build the 2624 version manually due to other reasons. 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. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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 me flummoxed. :-(. Have you a script(1) of that? Sorry, my -current box is now through it. 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." 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. Martin -- % Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ BSD User Group Hamburg, Germany http://www.bsdhh.org/ 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP! New (incomplete) /dev/random device!
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 just not upgrade their work machines for the next few days until entropy is fixed. Upgrading is fine; just don't build certificates/credentials. Upgrading is *not* fine. Everything that uses high-quality randomness is broken. This includes SSH, PGP, GnuPG, Apache/SSL random pid generation and what not. No, upgrading is not fine at all. Cheers, Jeroen -- Jeroen C. van Gelderen o _ _ _ [EMAIL PROTECTED] _o /\_ _ \\o (_)\__/o (_) _ \_ _(_) (_)/_\_| \ _|/' \/ (_)(_) (_)(_) (_)(_)' _\o_ 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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. What bothers me is how other boxes managed to get past this point. I think there may be a race... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/
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/perl executable to it and trying to build. What bothers me is how other boxes managed to get past this point. I think there may be a race... I know of no boxes that made it past that point :( -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
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 about your driver (or option). I'm not sure how well this would work. Modules already obviate the need to update stuff in sys/conf. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XML driver config file to replace LINT
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 list them all? Other than that, I like the idea. There's a real, pressing need to know if pccard FOO-bar is supported or is known to work or not in the current version. The PAO folks did a great job with this in their lists of cards known to work. Figuring out how to setup a database with all of this information is going to be tricky. The Japanese nomads were talking about this at one point, and if they come up with someting for pccard, it could likely be extended to all types of cards. Warner 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 Makefile.inc src/gnu/usr.bin/perl/libperl Makefile src/gnu/usr.bin/perl/miniperl Makefile)
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. Note that bootstrap-tools are built (and installed under /obj) to be run on the host. This means that miniperl is going to be built a second time for the target architecture. The bootstrap-tools stage is designed to solve incompatibilities caused by versions of tools installed on the system and the requirements (for newer ones) by the source-tree. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
SUBSCRIBE [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel breakage?
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 Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel breakage?
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 Administrator, eGroups.com http://www.egroups.com/ Maintainer, BSD Driver Database http://www.posi.net/freebsd/drivers/ Coordinator, Team FreeBSDhttp://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: subscribe
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 (and, in some cases, tens of thousands) of people seeing a "subscribe me" message in their mailboxes when they have absolutely nothing to do with the process of adding users like yourself to our mailing lists. This is a poor introduction, at best, and what we really suggest to people is that they read our mailing list FAQ at: http://www.freebsd.org/handbook/eresources.html#ERESOURCES-MAIL Paying particular attention to section 27.1.2: "How to subscribe." You should also be very sure to read section 27.1.3 as well, the mailing list charters. These describe very precisely just how each mailing list may be used and the range of topics allowed for each one. This will help you from making the SECOND most common new user mistake which is to post messages on subject A incorrectly to a mailing list devoted exclusively to the discussion of subject B. The FreeBSD mailing lists have gotten simply huge, with discussion traffic often exceeding 500,000 messages a week, and your cooperation is greatly appreciated in trying to keep the "noise level" down to manageable proportions so that those actually involved in project development, as well as the users of the project, can remain active members of the mailing lists. Thank you. Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Another way perl build is broken
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.bin/perl. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. gina/usr/src # exit Script done on Tue Jun 27 01:52:51 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: subscribe
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 "subscribe" message erroneously to one of our mailing lists, resulting in thousands (and, in some cases, tens of thousands) of people seeing a "subscribe me" message in their mailboxes when they have absolutely nothing to do with the process of adding users like yourself to our mailing lists. Nope. Somehow I got copied on this message, though I'm damned if I know why. The real issue is that you're telling the wrong person (with one exception). I wonder if it wouldn't make more sense to catch these messages and DWHM. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
