Re: Base packaging
On Thursday, September 18, 2003, at 11:28 am, Paul Richards wrote: On Thu, 2003-09-18 at 11:25, Alexander Leidinger wrote: We have programs in the ports tree which use our bsd.*.mk infrastructure. Will there be a problem if such a program gets installed from ports (will it try to register itself 2 times)? I don't know, have you got an example port I can look at? graphics/scr2png N ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Base packaging
On Wednesday, September 17, 2003, at 04:27 pm, Paul Richards wrote: I was thinking of adding an option to install so it registers the file in a plist rather than actually doing the install. A seperate "make plist" target could then be used as a helper target to automate the generation of plists. I think the NetBSD guys have already done something like this. Luke Mewburn (IIRC) mentioned this in his 'cross building' talk at BSDCon. N ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: devd/devctl
On Friday, September 12, 2003, at 06:26 pm, Suleiman Souhlal wrote: I was wondering if it would be a good idea to modify devd and devctl for them to handle other events than attaching and detaching devices.. For example, they could be used to mark a network interface as down, when the network cable is pulled out, and run dhclient when it is put back in. I think there are other applications too. Just something that occured to me in a slightly G&T addled state. The GNOME folks have this really cool application at the moment called 'dashboard'. Basically it works by receiving what they've dubbed 'clue packets' from whatever application that you happen to be using at the time, and distributing these to multiple backend plugins that either: a) rewrite the clue packet so that it contains additional information, and/or trigger additional clue packets or b) process it in some way, and update the information that's being displayed by the dashboard The canonical example they use at the moment is receiving an e-mail from someone. Your e-mail app sends a clue packet with the e-mail address of the person you've received it from, and the various backends pull out their address details from your address book, a photo, their web page link (if your browser knows it), their picture, the last five messages they've sent you, and so on, and so forth. I wonder if this model could be adopted for kernel and system events. Instead of a devd, usbd, and others, we need a more generic eventd, which can receive events from the kernel, and distribute them to backends, which can act on them, or augment them as necessary. We've reached cruising altitude, so I can't provide web links, but a google for 'gnome dashboard' should turn up useful info. N ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw userland breaks again.
On Sun, Dec 15, 2002 at 11:08:01AM -0800, Matthew Dillon wrote: > > : > ::This is complete BULLSHIT, Warner. > : > :Your attitude it totally unacceptible. Learn to play well with > :others, or get the fuck out of the project. > > Really? You think I should learn to play well with others? You > think it's appropriate to request that I spend a man week rewriting > an API? You really do? You think it's appropriate to bring up a > bogus security issue when its obvious that no security issue exists, > abusing your power in that manner is playing well with others? This > is Warner of core? I think it's more appropriate if you put options IPFIREWALL_DEFAULT_TO_ACCEPT on any boxes where you're running test code. That's much more acceptable than committing a kludge with a poor choice of name after minimal discussion when efforts would be better spent working on other rough edges in the run up to 5-release. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg48806/pgp0.pgp Description: PGP signature
Re: you broke current in some weird way... etc
On Wed, Feb 27, 2002 at 09:33:48AM -0800, Matthew Dillon wrote: > I'm just going to use this opportunity to plug the concept of temporary > sysctl-instrumentation for a commit like this. Any thoughts on having a root oid for sysctl oids like this, so they're not forgotten, and aren't assumed by anyone to be permanent? tmp.foo.bar or similar? N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg35472/pgp0.pgp Description: PGP signature
Re: BSDCON activities 2night?
On Mon, Feb 11, 2002 at 05:16:26PM -0800, Julian Elischer wrote: > Anyone making the usual plans or should I just look for the terminal room? I'd recommend getting on to the mailing list with details at: http://lists.csociety.org/listinfo/bsdcon/ where we're trying to keep announcements and discussion for attendees. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg34730/pgp0.pgp Description: PGP signature
Re: Junior Annoying Hacker Task
On Tue, Feb 05, 2002 at 01:30:53AM +1030, Mike Gratton wrote: > > However, I have previously thought that a system that used xml files to > > store application configs (that would then be used to generate valid conf > > files) would be useful. > > I was on the verge of doing so the other day. Basically, I wanted to > have standard configuration data describing the network, services and > service configuration stored in XML and use XSLT to produce which-ever > config files you need. You then introduce some inheritance and allow > configuration to be overridden for particular hosts, subnets, networks, > and/or platforms, and you have a powerful site-wide configuration > management tool. Great minds and all that: http://people.freebsd.org/~nik/xml-servers/ I'm going to try and do a 5 minute 'Work in Progress' on this at BSDCon next week if anyone's interested. Feel free to take that as a starting point. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg34120/pgp0.pgp Description: PGP signature
Re: Junior Annoying Hacker Task
On Sat, Feb 02, 2002 at 03:29:50AM -0800, Terry Lambert wrote: > Miguel Mendez wrote: > > Are you really serious about this? :) I've thought about that many > > times, well, not with the registry paradigm, but some sort of graphical > > admin tool based on GTK. I'm doing exams this week but may take a go at > > it after I finish them. > > Let me know the form you want the hierarchy to take, so > you can stick it into the GTK hierarchy thingy; Just go and port NetInfo from Apple's Darwin. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ (__) FreeBSD Documentation Projecthttp://www.freebsd.org/docproj/\\\'',) \/ \ ^ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- .\._/_) msg34036/pgp0.pgp Description: PGP signature
Re: Install Bash shell
On Thu, Oct 25, 2001 at 05:22:48PM +0800, Kelvin Ng Chee Hoong wrote: > I have install FreeBSD 4.4 release but the system does not has bash > shell installed .where can I get this shell from CVS ? please advise . Bash is not part of the base system. Either install it using the ports tree; # cd /usr/ports/shells/bash # make install or install the binary package # pkg_add -r bash Questions like this should be sent to the freebsd-questions mailing list, where I've copied this message, and set the reply-to. You should also read chapter 4 of the FreeBSD Handbook; http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ports.html N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
Re: PATCHES for Kris Kennaway to commit
On Sun, Oct 07, 2001 at 01:45:37PM -0700, Terry Lambert wrote: > Steve Kargl wrote: > > > It was posted to -current (see above). > > > > man send-pr > > > > A search of the GNATS databases with "terry" and "lambert" > > returns zero hits. The freebsd-current mailing list is not > > the preferred method for submission of patches and change > > requests. > > Yeah; I'd prefer it if "send-pr" ran under Windows, It does. Point your web browser at http://www.FreeBSD.org/send-pr.html N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- msg32373/pgp0.pgp Description: PGP signature
Re: uucp user shell and home directory
On Sun, Oct 07, 2001 at 01:25:29AM -0700, Terry Lambert wrote: > So while you are correct that there is an account there, I can't > log into it right now, and I don't know to whom I should send > the passwd file line now that I'm able to do that, since the > changeover was long enough ago that the hosting for the > machine has changed since then. Send an ssh public key for your account to [EMAIL PROTECTED] I suggest you sign this using PGP, or similar, so that they can verify the e-mail came from you. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- msg32354/pgp0.pgp Description: PGP signature
Re: uucp user shell and home directory
On Sat, Oct 06, 2001 at 02:23:35PM +0300, Maxim Sobolev wrote: > On Sat, 6 Oct 2001 02:53:21 -0700, Kris Kennaway wrote: > > On Sat, Oct 06, 2001 at 02:25:37AM -0700, Terry Lambert wrote: > > > Kris Kennaway wrote: > > > > > > > I know *you* have full-time IP connectivity to the internet and the > > > > ability to host a distfile somewhere under your control. > > > > > > Fat lot you know. > > > > Come now, Terrence, do you really mean to tell me a man of your > > resourcefulness, a man with 20 years of internet experience, has no > > way to publically host a single file on the internet? > > I agree with Kris. These days it is not a big problem, especially for > an opensource project, such as UUCP. Most obvious possibility is a > Sourceforge - it provides all what is necessary (i.e. cvs repo, bug > tracking database, mailing lists, www space, ftp space etc) at zero > cost. One problem with SF. Unless I'm missing something, there's no easy way to get at the ,v files for your repo easily. They don't support CVSup. Which means that in order to do things like "cvs diff" you have to be online. This is a royal pain in the ass. Even if you've got DSL or similar, SF's servers are frequently so loaded that cvs commands take ages to run (in my experience). I've tried several times to get SF to fix this, to no avail. N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- msg32317/pgp0.pgp Description: PGP signature
Re: HEADS UP!! S/Key is ancient, OPIE is new
On Wed, Jun 20, 2001 at 09:03:21PM +0200, Mark Murray wrote: > S/Key is old and decrepit; OPIE has taken over from it just about > completely except in FreeBSD; I intend to fix this. > > I want to remove S/Key from CURRENT completely, and replace it > with OPIE where necessary. For the most part, this means just > using PAM, but in one-or-two places, it may still be necessary > to use it directly (like temporarily in ftpd). > > OPIE has been in the sytem for a couple of years; S/Key's removal > was never complete. > > Please note that I'll start committing this in a few days unless > I get valid objections. S/Key is documented in the Handbook, OPIE isn't. Any chance you could rectify this before surgery? N -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- PGP signature
HEADS UP: doc/ tree frozen (was Re: HEADS UP for /usr/src/release/doc & /usr/doc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 11 June 2001 3:07 am, Andrey A. Chernov wrote: > On Mon, Jun 11, 2001 at 03:56:50 +0400, Andrey A. Chernov wrote: > > Please don't commit anything in the areas of subj. until I finish > > rename to new locale names there. > > Done. Feel free to commit. Please don't. While I appreciate the sentiment behind your recent commits to doc/, the last time we did a rename like this there was a lengthy discussion prior to the changes, and we did them by repo-copy. You haven't arranged for any repo copies to be done, effectively doubling the size of the doc/ repo, and there was no discussion of this on doc/. Unfortunately, I'm offline for pretty much the next 36 hours or so (speaking at Linux User Group meetings) so I'm not going to be around. Until then, I've frozen the doc/ tree -- this is to prevent any further commits to the new structure, until we can (I'm assuming) back out your changes, and do them by repo-copy. Sorry for the inconvenience this causes. N - -- FreeBSD: The Power to Serve http://www.freebsd.org/ FreeBSD Documentation Project http://www.freebsd.org/docproj/ --- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 --- -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjsks9oACgkQk6gHZCw343XS7ACbBnH0qaUpEdBTPgyZFN86ysvS n3cAn1yPrEgKI0Pf5U0y6hbd5cVPGBDw =3kPM -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [RFC] RELNOTESng for 5-CURRENT
On Thu, Apr 26, 2001 at 09:58:43AM -0700, Bruce A. Mah wrote:
> This problem (which I agree is valid) is not so much a problem as to
> where the release notes live, but the fact that one needs to actually
> build human-readable renderings of them. If people can't be bothered
> to install the docproj port and the doc/ tree to get release notes
> living in src/, putting the release notes in doc/ sure isn't going to
> help. It's trivial to put the release notes for -RELEASE versions up
> (the Web site does this already), and Dima thinks it's possible to do
> this for -CURRENT too (and -STABLE if and when it's applicable).
I think this, as a whole, is a non-problem. It's trivial to script a
daily build of the release notes and mirror it to the FTP site (and/or
include it in the twice daily build of the web site).
> Putting the release notes in doc/ means that the src/ committers (who I
> just *barely* got now to make changes to the release notes) are going
> to have to chase through parts of the doc/ hierarchy. I'm pretty sure
> I'm going to lose the few converts I've won if I let people talk me
> into this.
True, true.
> > Also, if we want to put these on the website then it means that anyone
> > doing so will need to have checked out www/, doc/, and src/release/
> > trees.
>
> I got the impression that this would not be hard. They don't need to
> have all of src/ checked out, and if enough people complain about it, we
> can probably make another module which is just the RELNOTESng part of
> src/release.
I think that would be a definite requirement. We could even make
release/ a top level directory, alongside src/, doc/, and ports/.
> > Could this come under doc/, and either have a CVS branch for RELENG_4
> > for just the release notes directory hierarchy, or I could start work on
> > the osrel{min,max,in} attribute support code again. . .
>
> Can it come under doc/? Sure. Do I think it's the right thing? No.
>
> I don't like the idea of having one part of doc/ branched and another
> part not (especially when the part that's not branched lives higher in
> the directory hierarchy).
I don't either (just because I suggest something doesn't mean I always
think it's the best way).
At the end of the day, you're the guy doing the work. . .
N
--
FreeBSD: The Power to Serve http://www.freebsd.org/
FreeBSD Documentation Project http://www.freebsd.org/docproj/
--- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 ---
PGP signature
Re: [RFC] RELNOTESng for 5-CURRENT
On Tue, Apr 24, 2001 at 09:03:10AM -0700, Bruce A. Mah wrote:
> There's a snapshot of RELNOTESng for -CURRENT, updated irregularly,
> at:
>
> http://people.freebsd.org/~bmah/relnotes/
Like it.
My main concern is that this is in the src/ tree. As other people
have said this is going to complicate things for src/ folks who just
want up to date release notes, and for doc/ people who might not track
-stable or -current, but who want to work on the SGML side of things.
Also, if we want to put these on the website then it means that anyone
doing so will need to have checked out www/, doc/, and src/release/
trees.
Could this come under doc/, and either have a CVS branch for RELENG_4
for just the release notes directory hierarchy, or I could start work on
the osrel{min,max,in} attribute support code again. . .
N
--
FreeBSD: The Power to Serve http://www.freebsd.org/
FreeBSD Documentation Project http://www.freebsd.org/docproj/
--- 15B8 3FFC DDB4 34B0 AA5F 94B7 93A8 0764 2C37 E375 ---
PGP signature
Re: pkg_update
On Wed, Feb 07, 2001 at 08:23:35PM -0600, Michael C . Wu wrote: > On Thu, Feb 08, 2001 at 01:56:11AM +0100, Leif Neland scribbled: > | It seems pkg_update is only usable when installing from packages, not from > | ports. > > Because it is a package update system. If you want to update > from the ports, use 'pkg_version -c |sh' Never, ever, *ever* do this. "pkg_version -c" is a hack to make cut-n-paste easier. The output is sorted alphabetically and no notice is taken of dependencies between different ports. *If* you know what you're doing then -c is useful to help save you some typing. But you should never run the commands automatically. 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: status of http://www.freebsd.org/handbook/makeworld.html
On Mon, Nov 27, 2000 at 08:28:57PM -0500, Garance A Drosihn wrote: > Unless I'm missing something, which is certainly possible, it > seems to me that > http://www.freebsd.org/handbook/makeworld.html > > is missing some information that it used to have. Send patches. When I wrote that section I was running "make world" once or twice a day. I don't generally do that anymore. 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: Submiting new code
On Thu, Oct 05, 2000 at 10:29:40AM -0400, Michael Lucas wrote: > (copied to -doc for reasons which will become clear below) > > The FTP server no longer accepts uploads. Use uuencode and send-pr. > > Many people put code submissions up on a local web site and request > comments on -current or -hackers before doing this. It makes the > eventual code submission much more likely to be accepted. > > Docs folks, would one of you like to whack the offending statement > from the Handbook? It looks like section 19.2.4 is the problem. (Of > course, if we have a new FTP site, that would be good too. :) Done. Better late than never. 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: new rc.network6 and rc.firewall6
On Tue, Oct 24, 2000 at 02:56:07PM -0700, Jordan Hubbard wrote: > [redirected to just -current; I'm not sure what this has to do with -net] > > > I agree. I've been using them for a while on my dog slow Windows CE > > machine. There were some minor issues when they were first committed > > to NetBSD on some platforms (due to a too early use of ps and some > > brokeness in ps on pmax, for example), but these were quickly > > resolved. > > So, who wants to do a proof-of-concept implementation for -current > which integrates with our existing rc.conf mechanism? In order to > obey POLA, we should at least have the separate scripts switch off the > same knobs whenever possible. As far as I'm aware, Neil Blakey-Milner is doing just that (I'm surprised he hasn't said so himself, although I think this week/fortnight's quite hectic for him in the real world). N To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current.freebsd.org
On Sun, Oct 08, 2000 at 10:32:53PM -0700, Jordan Hubbard wrote: > We've also been forced by the > silicon valley personnel crunch to hire a new system administrator > who's a little strange (he refers to himself as "Elvis Preston" and > makes odd little hip-thrusts at the system rack when he thinks nobody > is looking) and frequently missing, Huh? Sounds like unfurl to me. 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: VMWare on -current, how fast should I expect it to be?
On Tue, Sep 12, 2000 at 04:44:41PM +0200, Reinier Bezuidenhout wrote: > Let me first ask ... do you use the "suspend/resume" option?? Yep. > This caused the same "lockup" every few seconds on my machine too - > a much slower 400 PII. As soon as I "shutdown" Win9X and rebooted > it worked fine. I tried that. The pauses are still there :-( Thanks for the suggestion. 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: VMWare on -current, how fast should I expect it to be?
On Wed, Sep 13, 2000 at 10:48:20AM -0400, Brian A. Seklecki - Stargate Industries, LLC - NOC wrote: > You're running vmware sucsessfully in --current? Yes. -current from August 18th, and I'm running the vmware2-2.0.2.621 port. Installing Win98 took about 4 hours though -- most of that was when Win98 was probing for devices. 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: VMWare on -current, how fast should I expect it to be?
On Tue, Sep 12, 2000 at 07:09:00AM -0700, Julian Elischer wrote: > > atapci0: port 0xfc90-0xfc9f at device 7.1 on >pci0 > > ata0: at 0x1f0 irq 14 on atapci0 > > ata1: at 0x170 irq 15 on atapci0 > > ad0: 17301MB [35152/16/63] at ata0-master using UDMA33 > > > > This is -current from about three weeks ago. It works, but it's a bit slow. > > Applications themselves run at a reasonable speed, but every now and then > > (can be as frequent as 10-15 seconds) > > use only virtual disks and see if it still happens. I am. The information above is the disk underlying the UFS filesystem that VMWare is then splatting it's files to. 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
VMWare on -current, how fast should I expect it to be?
Hi guys, For those of you running VMWare (2) on -current, how fast do you expect it to be? I'm running it quite successfully on a 750MHz PIII w/ 128MB RAM, and the following disk controller / disk atapci0: port 0xfc90-0xfc9f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 17301MB [35152/16/63] at ata0-master using UDMA33 This is -current from about three weeks ago. It works, but it's a bit slow. Applications themselves run at a reasonable speed, but every now and then (can be as frequent as 10-15 seconds) the guest OS (Windows 98 in this case) will freeze or run very slowly -- the mouse pointer doesn't track properly, keystrokes are queued up. After a couple of second things settle back down, the queued keystrokes and mouse movements manifest in the window, and so on, only to repeat shortly afterwards. I don't have this sort of problem with other apps (unless I load 56 copies of Netscape, naturally). Is this a common issue people are seeing? 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: CFR: acpi userland manpages
On Sun, Sep 10, 2000 at 07:58:26AM +0900, Mitsuru IWASAKI wrote: > > Sheldon can probably render an opinion on their usage of the macros. > > OK, I'm looking forward to see it :-) If he doesn't in the next couple of days (no pressure, Sheldon :-) ) then go ahead and commit. 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: CFR: acpi userland manpages
On Fri, Sep 01, 2000 at 12:09:31AM +0900, Mitsuru IWASAKI wrote: > Hi, I've just imported acpi userland tools and writing manpages for > them with contributers in Japan. > Please review them and send any comments (or diffs) for me > ([EMAIL PROTECTED]) in terms of English/roff or whatever. > > The draft version of manpages are available at > http://people.FreeBSD.org/~iwasaki/acpi/acpidump.8 > http://people.FreeBSD.org/~iwasaki/acpi/amldb.8 I've just found the time to give them a quick once over, and I'd have no problem with them going in as they are. There are some grammar changes, and possibly terminology changes that might be appropriate, but I haven't got the time to enumerate them all at the moment, and I'm sure the wider community can make suggestions as time goes on. Sheldon can probably render an opinion on their usage of the macros. 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: problems with /usr/bin/awk
Tony, On Mon, Aug 21, 2000 at 07:17:31PM -0700, Tony Fleisher wrote: > I have been running cvsup nightly to grab -current and -ports, > and noticed some strangeness with awk that seemed to start last > week sometime. > > When building /usr/ports/lang/guile, the build exited with an > awk 'internal error' and a log on the console that awk had > exited on signal 6. To test my theory that the problem was > indeed awk (rather than the guile port), I copied over a copy > of awk from a 4.1-R system. After doing so, the guile port was able to > build and install without any problems. Interesting. I bumped into the same problem on -current, but also had the problem if I tried using gawk from the ports (d'oh. I've just realised, our awk is GNU awk). You can get around it by installed nawk from lang/nawk first, and then doing "make AWK=nawk" you build it. 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: Destabilization due to SMP development
On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote: > Summary: -current will be destabilized for an extended period (on the order > of months). A tag (not a branch) will be laid down before the initial > checkin, and non-developers should either stick closely to that tag until > the kernel stabilizes, or expect large doses of pain. This tag will be > laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning > beforehand. Is there any news on this work? Unless I've missed the significance of recent commits, I haven't seen anything approaching this sort of destabilisation in -current. 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: XML driver config file to replace LINT
On Wed, Jun 28, 2000 at 06:24:01PM -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Nik Clayton writes: > : On Wed, Jun 28, 2000 at 11:27:12AM -0400, Thomas M. Sommers wrote: > : > Warner Losh wrote: > : > > > : > > Any reason that the .c/.h files of the drivers couldn't be used to > : > > generate this information? > : > > : > Or perhaps the other way around. > : > : That's what I'd prefer. Any solution that relys on trying to parse > : "structured comments" like that is a kludge at best. I'd rather get > : all this information in to a usefully structured form now, and then > : process it to produce the various output formats we need. > > I think that this will doom the information to always being obsolete. > If the information is in the .h or .c files, then it will be looked at > (and corrected) all the time by the programmers. If not, then it will > rot as badly as LINT has been rotting. It has taken much effort to > keep LINT as non-rotten as it has been kept. The .h file(s) should be generated from this XML config file, or some other mechanism needs to be put in place to prevent a (hardware) module from working if there isn't a functional entry for it in this XML config file. We've successfully demonstrated that hardware authors don't keep things like LINT up to date. We've also successfully demonstrated that getting volunteers to scan the mailing lists and keep HARDWARE.TXT and similar up to date is equally futile. It's time to turn the tables. I don't know enough about the -current build environment to say precisely how this could be done (yet). But God help you all if I scrape together sufficient resources to put together a box for -current. In the meantime, I'd appreciate suggestions as to how you (or anyone else) would go about abstracting some of the core information that a driver needs out of a source file. 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: XML driver config file to replace LINT
On Wed, Jun 28, 2000 at 11:27:12AM -0400, Thomas M. Sommers wrote: > Warner Losh wrote: > > > > Any reason that the .c/.h files of the drivers couldn't be used to > > generate this information? > > Or perhaps the other way around. That's what I'd prefer. Any solution that relys on trying to parse "structured comments" like that is a kludge at best. I'd rather get all this information in to a usefully structured form now, and then process it to produce the various output formats we need. 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: XML driver config file to replace LINT
On Tue, Jun 27, 2000 at 11:49:34PM +0900, Hiroki Sato wrote: > Nik Clayton <[EMAIL PROTECTED]> wrote > in <[EMAIL PROTECTED]>: > > > [ That schema is not set in stone, and certainly requires more work. In > > particular, we probably need "lang" and "encoding" options on the > >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. > > I think it is difficult to maintain the files because few editors > can handle various languages/encodings at the same time. > So, especially for translators, it is better that the .xml files > are separated on a encoding/language basis. Possibly. I was thinking that the only thing that would be language specific about each driver would be the comment section. ... All the other stuff is language independent. That being the case, it wouldn't be too hard to do ... ... and so on, would it? Or does loading Japanese text in to a non-Japanese aware editor scramble the text? 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: XML driver config file to replace LINT
On Mon, Jun 26, 2000 at 03:02:07PM -0600, Warner Losh wrote: > 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? Initially, the driver's author. Over time, user submissions will indicate whether a particular driver supports a particular card. All I want to do is make sure that this information only needs to be maintained in one place. 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: XML driver config file to replace LINT
On Mon, Jun 26, 2000 at 03:02:07PM -0600, Warner Losh wrote: > 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? Initially, the driver's author. Over time, user submissions will indicate whether a particular driver supports a particular card. All I want to do is make sure that this information only needs to be maintained in one place. 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: XML driver config file to replace LINT
On Mon, Jun 26, 2000 at 03:06:57PM -0600, Warner Losh wrote: > 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. S'fine, that's why this was cc'd to -current. I need input from people involved in the future technical direction of FreeBSD. How are we going to enumerate FreeBSD's supported hardware list in 5.x and beyond? 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: XML driver config file to replace LINT
On Mon, Jun 26, 2000 at 03:06:57PM -0600, Warner Losh wrote: > 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. S'fine, that's why this was cc'd to -current. I need input from people involved in the future technical direction of FreeBSD. How are we going to enumerate FreeBSD's supported hardware list in 5.x and beyond? 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: 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: 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
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 [...] keyboard controller device atkbdc0 at isa? port IO_KBD The keyboard controller; it controls the keyboard and the PS/2 mouse. keyboard device atkbd0 at atkbdc? irq 1 The AT keyboard ATKBD_DFLT_KEYMAP Specify the built-in keymap KBD_DISABLE_KEYMAP_LOAD Refuse to load a keymap KBD_INSTALL_CDEV Install a CDEV entry in /dev 0x01 Force detection of keyboard, else we always assume a keyboard 0x02 Don't reset keyboard, useful for some new ThinkPads 0x04 Old-style (XT) keyboard support, useful for older ThinkPads [ That schema is not set in stone, and certainly requires more work. In particular, we probably need "lang" and "encoding" options on the 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: Check for ports updates
On Tue, Jun 06, 2000 at 10:25:02PM +0200, Thomas Schuerger wrote: > > > Is there already a tool that checks the installed ports for available > > > updates in /usr/ports? > > > > > > I've written such a tool, which seems to work fine already. Anyone > > > interested? > > > > pkg_version(1) > > Ah, haven't seen that before. The output of pkg_version is very > canonical, but not very readable for humans. pkg_version -v pkg_version -c 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: a better idea for package dependencies
On Tue, May 09, 2000 at 10:29:12AM -0700, David O'Brien wrote: > Hopefully some day, parts of the /usr/src bits will be installed with the > pkg_* utils, but today only things in /usr/ports are used with the pkg_* > utils. ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/packages/ :-) [ For those that can't be bothered to look, that's every document, in every format, in every language we have, one package per doc/format/lang combination. ] 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: Problems with MAKEDEV.
On Fri, Apr 14, 2000 at 11:41:55AM +0100, Ashley Penney wrote: > When booting up I noticed the block device warning message. I > did some investigation and discovered that some ad4/ad5 devices > were still block ones. It seems that the MAKEDEV script only > makes up to ad3, but my disks are on ad4/ad5 (ATA-66, Abit BP6). /dev/MAKEDEV.local 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: Alternative way to do -stable to -current upgrade
On Tue, Mar 07, 2000 at 10:19:57AM -0800, Brooks Davis wrote: > On Tue, Mar 07, 2000 at 11:01:09AM +0000, Nik Clayton wrote: > > To which the response has been nil. At this point, you're either all > > struck dumb by the staggering simplicity and elegance of this approach, > > or you're sat there slowly shaking your head, wondering how I could be > > quite so stupid :-) > > > > Come on then, which is it? > > To be honest it seems like a complete waste of time and a hugh pain in > the rear. All you need to do is build a 4.0 kernel, install it under > some random name (say /kernel.current) boot with it to insure that it > works. That, at least, was not the case with an upgrade I attempted a few days ago. On booting with kernel.GENERIC (from -current) it hung mounting the disks. Trying to go back to kernel.stable didn't work, because I'd had to update the /dev entries for -current, and they wouldn't work with -stable. I had to dig out fixit floppies and restore from a backup. Ordinarily, you'd make sure that userland, /dev, and the kernel are all in sync before you reboot. However, in this case (and as advised by src/UPDATING) you have to reboot with a new kernel after updating /dev, but before you update the userland. 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: Alternative way to do -stable to -current upgrade
On Tue, Mar 07, 2000 at 09:20:01AM -0800, Steve Kargl wrote: > Nik Clayton wrote: > >> 5. Mount all the fixed disk partitions, and then (assuming they're all > >> mounted under /mnt/root) > >> > >> cd /mnt/root/usr/src && make DESTDIR=/mnt/root > >> > >> 7. Build and install a new kernel > >> > > > > Come on then, which is it? > > Okay, here's some feedback ;-) > > In 5. above, is "make DESTDIR=/mnt/root" missing "world" or > "installworld"? Rats. It's missing the "installworld" bit. 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: Alternative way to do -stable to -current upgrade
Quoting the whole thing deliberately: On Sun, Mar 05, 2000 at 08:24:35PM +, Nik Clayton wrote: > I had an abortive -stable to -current upgrade late last week, despite > following the directions in UPGRADING, the two kernels I built (one > custom, one GENERIC) both froze on me during the reboot process. > > I'm a little wary of doing it again like that, because it does take > some time to fix. > > So I had an alternative idea. How about doing the following: > > 1. Download -current boot.flp, mfsroot.flp, fixit.flp, and write to > floppies > > 2. cd /usr/src && make buildworld > > 3. Reboot from boot/mfsroot.flp > > 4. When prompted, use the fixit floppy to get a shell > > 5. Mount all the fixed disk partitions, and then (assuming they're all > mounted under /mnt/root) > > cd /mnt/root/usr/src && make DESTDIR=/mnt/root > > 6. Mergemaster > > 7. Build and install a new kernel > > This has the added advantage that if there's something in your system > that was OK in -stable, but doesn't work in -current, you're going to > find out about it before you've done an installworld, and before you've > overwritten a working -stable /kernel, because boot.flp will fail to > work. > > The only problem is that mergemaster assumes it's merging in to /etc, > when that wouldn't be the case here -- mergemaster would need another > config option ($DEST_ETC ?) to specify where to install to. > > Can anyone see anything there that's likely not to work? To which the response has been nil. At this point, you're either all struck dumb by the staggering simplicity and elegance of this approach, or you're sat there slowly shaking your head, wondering how I could be quite so stupid :-) Come on then, which is it? 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
Alternative way to do -stable to -current upgrade
Hi guys, I had an abortive -stable to -current upgrade late last week, despite following the directions in UPGRADING, the two kernels I built (one custom, one GENERIC) both froze on me during the reboot process. I'm a little wary of doing it again like that, because it does take some time to fix. So I had an alternative idea. How about doing the following: 1. Download -current boot.flp, mfsroot.flp, fixit.flp, and write to floppies 2. cd /usr/src && make buildworld 3. Reboot from boot/mfsroot.flp 4. When prompted, use the fixit floppy to get a shell 5. Mount all the fixed disk partitions, and then (assuming they're all mounted under /mnt/root) cd /mnt/root/usr/src && make DESTDIR=/mnt/root 6. Mergemaster 7. Build and install a new kernel This has the added advantage that if there's something in your system that was OK in -stable, but doesn't work in -current, you're going to find out about it before you've done an installworld, and before you've overwritten a working -stable /kernel, because boot.flp will fail to work. The only problem is that mergemaster assumes it's merging in to /etc, when that wouldn't be the case here -- mergemaster would need another config option ($DEST_ETC ?) to specify where to install to. Can anyone see anything there that's likely not to work? 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: Kernel hangs booting fresh -current
On Fri, Mar 03, 2000 at 07:38:33AM -0500, Jim Bloom wrote: > Nik Clayton wrote: > > On a related note, why does UPDATING say to build and install the kernel, > > and then reboot, before doing the "installworld"? That contradicts the > > advice in the Handbook (which I wrote), and I would've thought it's wrong > > precisely because it allows for things like kernel/mount mismatches to > > occur. > > Because the signal interface changed several months ago. If you ran > installworld on an old kernel, the machine would panic part way through > the install. OK. That just about makes sense. > It is almost impossible to do forward compatibility on > major changes. I guess you need to update the handbook to reflect this > change. Not sure. As a corner case it should probably stay in UPDATING. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hangs booting fresh -current
How do, I just tried to go from -stable (built on Feb 24th) to -current, fresh yesterday (Thursday). "make buildworld" completed cleanly, and following /usr/src/UPDATING I made and installed a fresh kernel, and updated /dev (by running "MAKEDEV da0s1a" and "MAKEDEV da1s1a" with a -current mknod). Then I rebooted (without doing an "installworld", UPDATING says you do this *after* the reboot). The new kernel boots, but fails to mount the disks. Thinking this was just a mismatch between the kernel and the mount binary, I dug out my fixit floppy, got back in to the system, installed the new mount binaries (including the mount_* ones), and tried to reboot. This time, the system froze after the last kernel message was printed, but before the "swapon" message appears. This was a complete lock, the LED keys didn't work, neither did CTRL-ALT-DEL. Thinking there was something odd in my kernel config file, I recovered the system again, got back in, and built a -current GENERIC kernel, figuring that it should definitely work. I tried rebooting with this, and got an error message from the npx probe and an immediate reboot. That happened so quickly I couldn't get a good look at it, but the word "nexus" was in there somewhere. I stress this was with a stock GENERIC -current kernel (but built on a 3.4 system). Have I just hit a bad patch? I've been following the -current list for years, and watch for problems religiously -- I figured with the OpenSSL stuff out of the way, this was as good a time as any. On a related note, why does UPDATING say to build and install the kernel, and then reboot, before doing the "installworld"? That contradicts the advice in the Handbook (which I wrote), and I would've thought it's wrong precisely because it allows for things like kernel/mount mismatches to occur. I'd be very surprised if this is hardware failure. This system has been rock solid on all versions of 3.x, and gets stressed quite highly most days. I realise I haven't been able to provide a great deal of information about this, but I hope it rings bells with someone. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Streamlining FreeBSD installations across many machines
On Fri, Feb 25, 2000 at 10:23:37AM -0500, Forrest Aldrich wrote: > I'm wondering if there might not be a way to streamline this install > process, such that a boot floopy and script could be created to take a > minimum amount of information, and then "do the right thing" as for the > install. Things like putting in the packet filters, the kernel, IP > config, etc. See sysinstall(8); you can script sysinstall. See src/release/sysinstall/install.cfg for an example. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[PATCH]: Teach make.conf about FETCH_BEFORE_ARGS
[ Sent to -current and -ports, followups set to -current ]
Here's another trivial patch that people might like to comment on before I
commit it. I'm doing more and more FreeBSD installs recently at various
client sites, and adding "FETCH_BEFORE_ARGS=-p" to make.conf is just one of
those standard things you have to do if there's a firewall in place.
Any one got any objection to mentioning that fact, with the included patch?
N
Index: make.conf
===
RCS file: /home/ncvs/src/etc/defaults/make.conf,v
retrieving revision 1.91
diff -u -r1.91 make.conf
--- make.conf 2000/02/09 04:08:18 1.91
+++ make.conf 2000/02/20 09:10:25
@@ -113,6 +113,10 @@
#
#MOTIFLIB= -L${X11BASE}/lib -lXm
#
+# If you are behind a firewall, this will force port fetching to use
+# passive mode, which is required for most types of firewall.
+#
+#FETCH_BEFORE_ARGS=-p
#
# If you're resident in the USA, this will help various ports to determine
# whether or not they should attempt to comply with the various U.S.
--
If you want to imagine the future, imagine a tennis shoe stamping
on a penguin's face forever.
--- with apologies to George Orwell
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
REVIEW: Update passwd(1) to allow lower case passwords
How do
[cc'd JKH: Assuming this passes review, can I put it in 4.0 and MFC? ]
passwd(1) normally enforces mixed case passwords -- or at least it forces
you to enter the lower case password several times before it will actually
let you use it.
This is a pain if you're using the Unix password file in a situation where
lower case passwords are useful. For example, Windows 9x lower cases
passwords before sending them on to Samba for authentication. You can
sort of work around this in Samba with the "password level" smb.conf
setting, but that's a bit of a hack.
It's also a pain if you have to tell your users, when changing their
passwords, that they have to enter the same password several times
before the change will be accepted. They ask complicated questions
like "Why should I?", and then they walk off without listening to the
answer. . .
So, attached is a tiny patch that teaches passwd(1) about a new login.conf
setting, "mixpasswordcase".
By default, everything is exactly as it was before. However, if you have
:mixpasswordcase@:
somewhere appropriate in your login.conf file, passwd(1) will allow lower
case passwords for those users without further complaint.
Thoughts?
N
--
If you want to imagine the future, imagine a tennis shoe stamping
on a penguin's face forever.
--- with apologies to George Orwell
Index: local_passwd.c
===
RCS file: /home/ncvs/src/usr.bin/passwd/local_passwd.c,v
retrieving revision 1.23
diff -u -r1.23 local_passwd.c
--- local_passwd.c 1999/08/28 01:04:51 1.23
+++ local_passwd.c 2000/02/08 19:25:05
@@ -95,6 +95,7 @@
int nis;
{
int tries, min_length = 6;
+ int force_mix_case = 1;
char *p, *t;
#ifdef LOGIN_CAP
login_cap_t * lc;
@@ -114,7 +115,8 @@
#ifdef LOGIN_CAP
/*
-* Determine minimum password length and next password change date.
+* Determine minimum password length, next password change date,
+* and whether or not to force mixed case passwords.
* Note that even for NIS passwords, login_cap is still used.
*/
if ((lc = login_getpwclass(pw)) != NULL) {
@@ -128,6 +130,8 @@
if (period > (time_t)0) {
pw->pw_change = time(NULL) + period;
}
+ /* mixpasswordcase capability */
+ force_mix_case = login_getcapbool(lc, "mixpasswordcase", 1);
login_close(lc);
}
#endif
@@ -142,10 +146,13 @@
(void)printf("Please enter a password at least %d characters
in length.\n", min_length);
continue;
}
- for (t = p; *t && islower(*t); ++t);
- if (!*t && (uid != 0 || ++tries < 2)) {
- (void)printf("Please don't use an all-lower case
password.\nUnusual capitalization, control characters or digits are suggested.\n");
- continue;
+
+ if (force_mix_case) {
+ for (t = p; *t && islower(*t); ++t);
+ if (!*t && (uid != 0 || ++tries < 2)) {
+ (void)printf("Please don't use an all-lower case
+password.\nUnusual capitalization, control characters or digits are suggested.\n");
+ continue;
+ }
}
(void)strcpy(buf, p);
if (!strcmp(buf, getpass("Retype new password:")))
Index: passwd.1
===
RCS file: /home/ncvs/src/usr.bin/passwd/passwd.1,v
retrieving revision 1.16
diff -u -r1.16 passwd.1
--- passwd.11999/08/28 01:04:51 1.16
+++ passwd.12000/02/08 19:14:50
@@ -70,8 +70,17 @@
Its total length must be less than
.Dv _PASSWORD_LEN
(currently 128 characters).
-Numbers, upper case letters and meta characters
-are encouraged.
+.Pp
+The new password should contain a mixture of upper and lower case
+characters (which may be overridden using the
+.Xr login.conf 5
+.if t ``mixpasswordcase''
+.if n "mixpasswordcase"
+setting for a user's login class). Allowing lower case passwords may
+be useful where the password file will be used in situations where only
+lower case passwords are permissable, such as when using Samba to
+authenticate Windows clients. In all other situations, numbers, upper
+case letters and meta characters are encouraged.
.Pp
Once the password has been verified,
.Nm passwd
Review wanted: [peter.jeremy@alcatel.com.au: docs/14530: Printed manual pages have extraneous blank first page]
-current,
Peter Jeremy forwarded this to me. I'm happy to commit it, because
it solves the problem. However, I don't understand the cause of the
problem, so I don't know whether or not the fix is an appropriate one
or not.
N
- Forwarded message from Peter Jeremy <[EMAIL PROTECTED]> -
Delivered-To: [EMAIL PROTECTED]
From: Peter Jeremy <[EMAIL PROTECTED]>
Subject: docs/14530: Printed manual pages have extraneous blank first page
To: [EMAIL PROTECTED]
Date: Thu, 27 Jan 2000 07:37:16 +1100
Hi Nik,
In view of the upcoming code freeze for 4.0-RELEASE, could you please
consider applying the following patch, which is an updated version of
the one included in PR docs/14530. This patch corrects a problem
which causes printed man pages to begin with a blank page.
Index: src/contrib/groff/tmac/doc-common
===
RCS file: /home/CVSROOT/src/contrib/groff/tmac/doc-common,v
retrieving revision 1.19
diff -u -r1.19 doc-common
--- src/contrib/groff/tmac/doc-common 2000/01/12 10:26:30 1.19
+++ src/contrib/groff/tmac/doc-common 2000/01/13 13:47:19
@@ -231,35 +231,33 @@
.\}
.if "\\$1"FreeBSD" \{\
. if "\\$2"2" .ds oS FreeBSD 2.0
-. ie \\n(.$==1\c
-. el .ie "\\$2"1.0" \c
-. el .ie "\\$2"1.1" \c
-. el .ie "\\$2"1.1.5" \c
-. el .ie "\\$2"1.1.5.1" \c
-. el .ie "\\$2"2" \c
-. el .ie "\\$2"2.0" \c
-. el .ie "\\$2"2.0.5" \c
-. el .ie "\\$2"2.1" \c
-. el .ie "\\$2"2.1.5" \c
-. el .ie "\\$2"2.1.6" \c
-. el .ie "\\$2"2.1.7" \c
-. el .ie "\\$2"2.2" \c
-. el .ie "\\$2"2.2.1" \c
-. el .ie "\\$2"2.2.2" \c
-. el .ie "\\$2"2.2.5" \c
-. el .ie "\\$2"2.2.6" \c
-. el .ie "\\$2"2.2.7" \c
-. el .ie "\\$2"2.2.8" \c
-. el .ie "\\$2"3" \c
-. el .ie "\\$2"3.0" \c
-. el .ie "\\$2"3.1" \c
-. el .ie "\\$2"3.2" \c
-. el .ie "\\$2"3.3" \c
-. el .ie "\\$2"3.4" \c
-. el .ie "\\$2"3.5" \c
-. el .ie "\\$2"4" \c
-. el .ie "\\$2"4.0" \c
-. el .tm Unknown FreeBSD version ``\\$2'' at line \\n(c.
+. if !\\n(.$==1\
+. if !"\\$2"1.0" \
+. if !"\\$2"1.1" \
+. if !"\\$2"1.1.5" \
+. if !"\\$2"1.1.5.1" \
+. if !"\\$2"2" \
+. if !"\\$2"2.0" \
+. if !"\\$2"2.0.5" \
+. if !"\\$2"2.1" \
+. if !"\\$2"2.1.5" \
+. if !"\\$2"2.1.6" \
+. if !"\\$2"2.1.7" \
+. if !"\\$2"2.2" \
+. if !"\\$2"2.2.1" \
+. if !"\\$2"2.2.2" \
+. if !"\\$2"2.2.5" \
+. if !"\\$2"2.2.6" \
+. if !"\\$2"2.2.7" \
+. if !"\\$2"2.2.8" \
+. if !"\\$2"3.0" \
+. if !"\\$2"3.1" \
+. if !"\\$2"3.2" \
+. if !"\\$2"3.3" \
+. if !"\\$2"3.4" \
+. if !"\\$2"3.5" \
+. if !"\\$2"4.0" \
+. tm Unknown FreeBSD version ``\\$2'' at line \\n(c.
.\}
.if "\\*(oS"Null" \{\
. ds oS \&\\$1
Index: src/contrib/groff/tmac/doc-syms
===
RCS file: /home/CVSROOT/src/contrib/groff/tmac/doc-syms,v
retrieving revision 1.24
diff -u -r1.24 doc-syms
--- src/contrib/groff/tmac/doc-syms 2000/01/12 10:26:30 1.24
+++ src/contrib/groff/tmac/doc-syms 2000/01/13 13:47:19
@@ -161,31 +161,31 @@
.ds aa \&\f\\n(cF\s\\n(cZ
.ds ab \& \&
.ie \\n(.$==0 .rm ab
-.el .ie "\\$1"1.0" \c
-.el .ie "\\$1"1.1" \c
-.el .ie "\\$1"1.1.5"\c
-.el .ie "\\$1"1.1.5.1" \c
-.el .ie "\\$1"2.0" \c
-.el .ie "\\$1"2.0.5"\c
-.el .ie "\\$1"2.1" \c
-.el .ie "\\$1"2.1.5"\c
-.el .ie "\\$1"2.1.6"\c
-.el .ie "\\$1"2.1.7"\c
-.el .ie "\\$1"2.2" \c
-.el .ie "\\$1"2.2.1"\c
-.el .ie "\\$1"2.2.2"\c
-.el .ie "\\$1"2.2.5"\c
-.el .ie "\\$1"2.2.6"\c
-.el .ie "\\$1"2.2.7"\c
-.el .ie "\\$1"2.2.8"\c
-.el .ie "\\$1"3.0" \c
-.el .ie "\\$1"3.1" \c
-.el .ie "\\$1"3.2" \c
-.el .ie "\\$1"3.3" \c
-.el .ie "\\$1"3.4" \c
-.el .ie "\\$1"3.5" \c
-.el .ie "\\$1"4.0" \c
-.el .ie "\\$1",".rm ab \" Allow ".Fx ,"
+.el .if !"\\$1"1.0" \
+.if !"\\$1"1.1" \
+.if !"\\$1"1.1.5" \
+.if !"\\$1"1.1.5.1" \
+.if !"\\$1"2.0" \
+.if !"\\$1"2.0.5" \
+.if !"\\$1"2.1" \
+.if !"\\$1"2.1.5" \
+.if !"\\$1"2.1.6" \
+.if !"\\$1"2.1.7" \
+.if !"\\$1"2.2" \
+.if !"\\$1"2.2.1" \
+.if !"\\$1"2.2.2" \
+.if !"\\$1"2.2.5" \
+.if !"\\$1"2.2.6" \
+.if !"\\$1"2.2.7" \
+.if !"\\$1"2.2.8" \
+.if !"\\$1"3.0" \
+.if !"\\$1"3.1" \
+.if !"\\$1"3.2" \
+.if !"\\$1"3.3" \
+.if !"\\$1"3.4" \
+.if !"\\$1"3.5" \
+.if !"\\$1"4.0" \
+.ie
PATCH: Documenting ASUSCOM_IPAC in LINT
Hi, Can I get approval for the attached patch to LINT (and MFC) before 4.0 rolls out of the door? It just documents the ASUSCOM_IPAC option for the Asus ISDNLink 128K ISDN card. This card is listed in the Handbook as being supported, but there aren't any entries in LINT for it. Grovelling through the source code turned it up, but it was a hairy few moments at a client's site today. . . Cheers, N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell Index: LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.742 diff -u -r1.742 LINT --- LINT2000/01/29 18:07:04 1.742 +++ LINT2000/02/04 20:39:23 @@ -2068,6 +2068,10 @@ # PCI bus Cards: # -- # +# Asus ISDNLink 128K +optionsASUSCOM_IPAC +# device isic +# # ELSA MicroLink ISDN/PCI (same as ELSA QuickStep 1000pro PCI) optionsELSA_QS1PCI #deviceisic
Re: OpenSSL docs for FAQ
On Tue, Jan 25, 2000 at 12:49:04AM -0800, Kris Kennaway wrote: > Can people please review this for style and content, for inclusion in > the FAQ? I'll also need someone to mark it up once it's ready since SGML > is currently not among my abilities :-) Is this FAQ material, or better off in the installation section of the Handbook? I'd veer towards the Handbook myself. I can't speak to the veracity of the content, but I can mark it up for the Handbook as necessary. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make world documentation
On Mon, Dec 27, 1999 at 09:31:50PM -0800, Brooks Davis wrote: > > Recently someone posted a url that provided a quick run through on some > > important extra steps to take while doing a make world from -STABLE to > > -CURRENT, unfortunatly I lost the URL. I was wondering if someone could > > post it again? I did check the archives, but I wasn't able to find it. > > http://www.nothing-going-on.demon.co.uk/FreeBSD/make-world/make-world.html > > Though I though it was supposed to have been moved to the main site, but > that's what http://www.freebsd.org/tutorials/ says. Damn, I haven't updated the tutorial page. The contents of that URL have moved in to the Handbook. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No disks found msg in /stand/sysinstall, how come?
On Sun, Dec 19, 1999 at 10:12:16AM +0200, Vallo Kallaste wrote: > On Sat, Dec 18, 1999 at 06:01:21PM -0800, Mike Smith <[EMAIL PROTECTED]> wrote: > > > Sysinstall is not build with 'make world', and should not be used on a > > system that's been updated that way. > > Well, thanks for the pointer, I've never looked at sysinstall > build process. # cd /usr/src/release/sysinstall # make all install This is in the "make world" section of the Handbook (makeworld.html), in the "Update /stand" section. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
On Tue, Dec 14, 1999 at 02:42:52PM +0200, Sheldon Hearn wrote: > On Tue, 14 Dec 1999 13:56:45 +0200, Sheldon Hearn wrote: > > > YES! This comes up at least once a month on the -questions mailing > > list. :-) > > I should have been more specific. People are dead keen on these two > features: > > 1) dump an ascii capture of the screen to a file. > 2) dump the entire scrollback buffer to a file. We need more than just an ASCII capture. Grabbing the colour information is also very useful. This lets you make full colour pictures of things like sysinstall. If anyone's interested, I've still got the old patches to syscons (which were mostly the work of a third party -- I'm damned if I can find out who sent them to me in my mail archive though) and a little utility that converts from the PC text mode screen format (each char described by 2 bytes, 1st byte is ASCII value, second byte is colour, where top nybble is background colour, bottom nybble is foreground colour). It also reads and decodes the same font files that syscons uses, so the GIF it outputs is as near as damn it identical to what was on the screen originally. Source code available free to a good home :-) N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syscons extension: "propellers"
On Tue, Dec 14, 1999 at 12:40:34PM +0100, Oliver Fromme wrote: > By the way, is there interest in giving the "Print Screen" > key an appropriate meaning, i.e. capturing a screenshot? > I have a few patches for this to implement that, I'd just > have to clean the code up and write a bit of documentation. > The GIF on the above webpage was created that way (along > with a small userland tool and netpbm). I'm just asking. > If nobody cares, I will not bother putting more time and > effort into this. Yes. I've got some patches somewhere for 2.2x syscons that implemented an ioctl for this, the idea being that these screenshots can then be used in the FAQ and Handbook as necessary. I didn't get around to sorting this out, which is why I never re-integrated them after the big syscons change that happened when -current became 3.0. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Sun, Dec 12, 1999 at 11:59:38AM +0100, Poul-Henning Kamp wrote: > >Poul, I'd like to know what's wrong with > > > > (1) Putting ata in GENERIC > > > > (2) Keeping wd in LINT, commented out > > This will not force CURRENT users to change their configs, a config > with wd in it will still work unchanged. Peter just added code > for issuing warnings, but I'd prefer for the build to actually > break until people fix it. wd.c #ifndef I_WANT_WD #error "You must really, really, really want to use this driver." #error "See UPDATING for details." #else ... #endif If someone takes their existing config file and tries to build a kernel from it, it will break. That meets every definition of "force CURRENT users to change their configs" that I can think of. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP: wd driver will be retired!
On Fri, Dec 10, 1999 at 07:01:49PM +0100, Poul-Henning Kamp wrote: > The ata driver has been available for you and other to test for a long > time. That may be the case, but the vast majority of our users don't run -current, for good reason, and so are in no position to test it. 4.0 will be their first exposure to ata, and you should definitely expect it to have problems that have been shaken out of the wd driver. Poul, I'd like to know what's wrong with (1) Putting ata in GENERIC (2) Keeping wd in LINT, commented out (3) A big notice in UPDATING, saying that ata is the replacement for wd. Make wd require "options I_WANT_WD" or something similar, so that people can't simply re-config their existing configuration file. That gives you the best of all possible worlds. Most people can move to ata immediately. Those people that can't can still run 4.0 with wd, and will know that it's going away for 4.1, and can take part in reporting the problems they're having with ata. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc-2.95.2, jade and freebsd-sgml-documentation
[ I've cc'd FreeBSD-doc on this, in case there's someone there who's solved the problem you're having ] On Sun, Nov 28, 1999 at 05:38:57PM +0100, F. Heinrichmeyer wrote: > i tried to make me a new handbook, so i needed jade. > > But the newest C++ fashion (g++ under current) has changed to fast for > this very old 1998 heavily template based source code distribution ;-). > I had a lot of problems with const and not const .. and gave up. It is > far to much to post here ... > > A lot of error messages are clearly written 1 to 1 from the ansi > standard (yes we finally spent the 18 dollars ...), but something > especially about a class "Location" looks really strange. > > What tool is recommendet to rebuild the documentation? Unfortunately, jade is the tool of choice. I don't run -current, so haven't had a chance to test out jade with the new GCC. However, could you take a look at OpenJade? It's not in the ports tree yet (should you want to submit a port I'll get it committed), and is a continuation of the Jade codebase after the original author (James Clark) moved on to other things. There's an OpenJade home page at http://www.netfolder.com/DSSSL/ and information about the OpenJade CVS repository at http://jade-cvs.avionitek.com/ I hope that helps. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Threads and my new job.
Jason, On Mon, Nov 22, 1999 at 06:52:20PM -0800, Jason Evans wrote: > Walnut Creek has hired me as a full time employee to work primarily on > improving and expanding FreeBSD's threads support. This is very exciting > to me, and I hope my work will be of benefit the FreeBSD community. That's great. Is it part of your remit to maintain http://www.FreeBSD.org/threads/? That URL doesn't exist at the moment, but if we're going to have an active threads project, it probably should. Are you (or anyone else reading this, you don't have to be a committer at the moment) interested in keeping this section up to date? N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/share/calendar/calendar.freebsd ?
[Redirecting to -chat] On Sun, Oct 31, 1999 at 02:05:14AM -0700, fifi -- hamster of Satoshi wrote: > * From: Brian Fundakowski Feldman <[EMAIL PROTECTED]> > > * Cool idea! Let's just limit it to the committer birthdays and not > * pets' birthdays too (sorry Asami's hamster and Jordan's cats, but it > > Why not? Discrimination! I've committed things too! Isn't this a breach of some "You shall not share your account and password with anyone else rule?" If it isn't, it should be :-) N -- A different "distribution" of Linux is really a different operating system. They just refuse to call it that because it's bad press. But that's what the shoe fits. -- Tom Christiansen, <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/share/calendar/calendar.freebsd ?
Folks, Is there any interest in a /usr/share/calendar/calendar.freebsd file (which would actually be in the CVS tree in src/usr.bin/calendar/calendars). Milestones in FreeBSD development (50 committers, 100 committers, the first 1000 ports), dates of releases, committer birthdays, that sort of thing. If so, I can start collating possible entries. . . N To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Info needed re: new userconfig scripting and PnP
On Tue, Oct 26, 1999 at 06:50:11AM -0500, Conrad Sabatier wrote: > I would be most honored, kind sir. :-) > > Just let me update it first, based on this recently acquired > information re: -current. Then, to whom should I submit it? send-pr, including a URL to the DocBook source is the best way. N To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Info needed re: new userconfig scripting and PnP
On Sun, Oct 24, 1999 at 02:10:03PM -0500, Conrad Sabatier wrote: > Someone just mailed me this heads up about my AWE soundcard setup > tutorial at http://members.home.net/conrads/awepnp-freebsd.html. > As this is the first I've heard about this, I'd greatly appreciate it Conrad (and anyone else with tutorials like this). This could fit neatly under doc/en_US.ISO_8859-1/articles/, if you'd care to. That would get it in the CVS tree (for ease of maintenance), allow the translation teams to tackle it, and get it mirrored on all the FreeBSD mirrors around the world. Interested? N To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
[ quoted section retained for context ] On Thu, Aug 26, 1999 at 08:53:00PM +0100, Nik Clayton wrote: > -stable, -current, > > On Sun, Aug 22, 1999 at 11:05:11AM +0100, Nik Clayton wrote: > > [ cc'd to -current ] > > > > On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote: > > > > > > Will support for building release docs in English only be > > > revived? > > > > > > > For the immediate future, it looks like it will -- it seems as though > > we don't have the man power to make the necessary changes to sysinstall > > to support "installing the docs as packages", so I'm going to fix up > > src/release/Makefile as necessary to cope with the new directory structure. > > With thanks to Jack O'Neill, this is now done. They're only in -current > at the moment, but they should backport to -stable fairly easily. I'd > be obliged if those if you who like to do these things grabbed a copy > of -current that has r1.504 of src/release/Makefile, and tried building > a release with that, and a copy of the doc/ tree that's of a similar > vintage. Everything should pretty much work. > > Brickbats should be sent my way if it doesn't. There's been a disturbing lack of brickbats landing at my feet, so can I assume that the new doc/ "make release" stuff is working for everybody? If so, I'll MFC the infrastructure tonight. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
Jordan, Satoshi, Just a reminder: I have *no* objection to the ports tree being used to build packages of the documentation, as long as the maintenance of those ports is assigned to individuals, and not the FDP (and, more specifically, me). However, I think that another mechanism, one that's wholly within doc/, will be useful, for the reasons I've already outlined. On Thu, Aug 26, 1999 at 06:46:38PM -0700, Satoshi - Ports Wraith - Asami wrote: > Another advantage of having them in the ports tree is the build > checking done at regular intervals. OK. But since the doc/ packages will also be being built daily (first on freefall, and then, when I get the time, on the docs.freebsd.org machine (usw1?) that jkh has been talking about, the same comment applies. > All the japanese/handbook stuff > that's going on right now, these are the problems of the > textproc/docbook* ports (missing files from PLIST, missing > dependencies). People installing these from packages will see the > exact same problem when they try to build the handbook (with or > without the japanese/handbook port). Hang on a second. Are we talking about different things here? I want the formatted documentation available as packages so that those people that want formatted docs, but who have neither the time, the inclination, or the machine horsepower to download the textproc/docproj port have a very easy way of installing and managing formatted documentation -- specifically, pkg_add(1). If people want to go and build the documentation from scratch themselves, they should do so by downloading the doc/ repository, and running make(1) in there, not by going through the ports system. That just adds an additional layer of complexity. [ Obviously, people will have to go through the ports system to download the applications they are using to build the docs, or go through the hassle of configuring and installing them themselves ] > * > Putting the package building rules in the doc/ Makefiles also (and this > * > is just my personal opinion) makes it easier for people to see how the > * > documentation packages are built. The ports Makefile structure is a > * > marvel, but it contains a lot of code that's not necessary for building > * > documentation packages (the "automagically add man pages to the PLIST > * > i" code, for example) that makes it more difficult for the interested > * > learner to browse and understand what's going on. > * > * Now this is a point which is more germin. So, you figure on making a > * similar sort of "package" target under doc? I guess it really doesn't > * matter where these things live, as long as it's still automated.. > > The chief concern I have is that this might result in yet another > place you (Jordan) have to pick up stuff from before the release. This shouldn't matter, should it? As long as the automated doc package building puts the files somewhere sensible (in distfiles/ on wcarchive?) it'll get picked up. Remember that the long term plan is to migrate the docs out of the release as a separate distribution, and in to their own packages, so that at sysinstall time the user can pick and choose which docs to install at the level of the individual packages (presumably, with some additional 'meta' choices, that let them say things like "All the English docs, in HTML and PDF, and the Spanish docs in HTML"). Since this (the package building, and sysinstall changes) are not going to be ready for 3.3-RELEASE, I think we should concentrate on ensuring that "make release" works with the new doc/ structure, and that sysinstall knows about the correct locations of the FAQ and Handbook in the new structure. In the meantime, I can continue adding and tweaking (with input from anybody else that's interested) the package building rules under doc/, and then set up a system that automatic builds formatted versions of the latest documentation daily (or weekly, depending on how rapidly the documentation is changing, and how badly people want it). We can then run with this for a bit, see how it works out, and that gives us plenty of time to consider removing the doc distribution (in favour of the packages) in time for 4.0-RELEASE. The ports tree can continue having a japanese/handbook entry for as long as they want. As long as I don't have to support it, I don't care :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
-stable, -current, On Sun, Aug 22, 1999 at 11:05:11AM +0100, Nik Clayton wrote: > [ cc'd to -current ] > > On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote: > > > > Will support for building release docs in English only be > > revived? > > > > For the immediate future, it looks like it will -- it seems as though > we don't have the man power to make the necessary changes to sysinstall > to support "installing the docs as packages", so I'm going to fix up > src/release/Makefile as necessary to cope with the new directory structure. With thanks to Jack O'Neill, this is now done. They're only in -current at the moment, but they should backport to -stable fairly easily. I'd be obliged if those if you who like to do these things grabbed a copy of -current that has r1.504 of src/release/Makefile, and tried building a release with that, and a copy of the doc/ tree that's of a similar vintage. Everything should pretty much work. Brickbats should be sent my way if it doesn't. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Docs blows up make release
[ I've added Satoshi Asami to the cc: list -- I figure he's almost certainly
on -current, but I wanted to make sure he sees this and can add his input
as necessary.
I've also added -doc, for information. ]
On Sun, Aug 22, 1999 at 02:25:52PM -0700, Jordan K. Hubbard wrote:
> Nik Clayton wrote:
> > For the immediate future, it looks like it will -- it seems as though
> > we don't have the man power to make the necessary changes to sysinstall
> > to support "installing the docs as packages", so I'm going to fix up
> > src/release/Makefile as necessary to cope with the new directory structure.
Just an update on that. I've been working on this with Jack O'Neill, and
if the reports are favourable I'll have one small patch to
src/release/Makefile and one small patch to doc/*/Makefile to go in some
time in the next 48 hours or so which should get release builds working.
Note that this won't include any fixes to teach sysinstall about the new
paths under /usr/share/doc/, although you should have seen a patch I sent
you about that by now.
> I also should note that there's nothing to preclude supplying the docs
> as packages *also*, assuming that they appear in the INDEX and get
> built as part of Satoshi's ports build.
This assumes that the documentation is also listed in the ports tree.
I don't think this is a great idea -- more specifically, I don't think
this is a great idea as the primary mechanism for making packages of
the documentation. I've got no problems with it being another way to
make doc packages.
As the comment for ports/japanese/handbook says, "this is pretty useless
as a port, but is here so I can build a package -- Satoshi".
This makes the ports tree have a dependency on the doc tree. I don't think
this dependency should be there. It's bad enough that the src/ tree
depends on doc/ (and the reason I want the documentation available as
packages is to remove this dependency), having ports depend on the doc tree
as well just means that when things go out of sync in doc for a while I get
both you and Satoshi complaining at me, instead of just you :-)
Putting the package building rules in the doc/ Makefiles also (and this
is just my personal opinion) makes it easier for people to see how the
documentation packages are built. The ports Makefile structure is a
marvel, but it contains a lot of code that's not necessary for building
documentation packages (the "automagically add man pages to the PLIST
i" code, for example) that makes it more difficult for the interested
learner to browse and understand what's going on.
I've attached the patch to docproj.docbook.mk that tells it how to build
packages to this message. To use it.
1. Checkout a recent copy of the doc/ repository.
2. Patch doc/share/mk/docproj.docbook.mk with the attached patch.
3. Pick a directory, such as the English FAQ
# cd doc/en_US.ISO_8859-1/books/faq
4. Make sure that a COMMENT and DESCR file exist. I haven't committed
any of these yet, so the simplest thing to do is
# touch COMMENT DESCR
5. Run "make package", ensuring that the FORMATS variable is set to the
formats you want to build.
# make "FORMATS=html html-split ps pdf rtf" package
6. Sit back and relax, it takes a while. When it's finished, look at
the .tgz files that have been created. Note that package building
*will* update the installed documentation under /usr/share/doc/.
If there's a way to work around this (so that you can build the
package containing files in one directory, but so that when you run
pkg_add(1) the files are installed in a different directory) I'd like
to know about it.
This is still proof of concept. For example, when it's finished, it would
be nice if the DESCR could be automatically generated by pulling out the
... that might be in the source, and the name of the
generated package should probably be something like
...tgz
so
faq.en_US.ISO_8859-1.pdf.tgz
But I think it currently fits the 80/20 rule reasonably well.
If you put COMMENT and DESCR files in all the appropriate directories you
should certainly be able to do something like
# cd /usr/doc
# make "FORMATS=html html-split ps pdf rtf" package
# find . -name \*.tgz -exec scp {} wcarchive:/archive/pub/FreeBSD/doc \;
which is how I intend to automate building these things and ensuring that
wcarchive is kept up to date.
Does that all make sense? I don't think there's anything there that's
egregiously stupid, but it's been known to happen before :-)
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the
Re: Docs blows up make release
[ cc'd to -current ]
On Sat, Aug 21, 1999 at 07:54:51PM -0400, jack wrote:
>
> Will support for building release docs in English only be
> revived?
>
For the immediate future, it looks like it will -- it seems as though
we don't have the man power to make the necessary changes to sysinstall
to support "installing the docs as packages", so I'm going to fix up
src/release/Makefile as necessary to cope with the new directory structure.
I will find this much, much, much easier if someone could e-mail me a
directory listing of what the contents of ${RD}/trees looks like after
the src/release/Makefile:doc.1 target has been run. This saves me having
to scrounge together the necessary resources to actually be able to build
a release on my home system.
It would also help if someone who knows the release build stuff could
let me know whether or not this directory structure is simply splatted
on to the disk at install time and then left alone, or whether any other
parts of the install process rely on being able to find the files in
particular locations under /usr/share/doc.
Many thanks,
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <[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, Aug 20, 1999 at 07:34:31PM +0200, Andrzej Bialecki wrote: > Both versions are available at: > > http://www.freebsd.org/~abial/matrix_3.2.tgz > http://www.freebsd.org/~abial/matrix_4.0.tgz I knew I should have taken the blue pill. FWIW, there are at least two other 'matrix' implementations out there. One is part of xscreensaver, and is quite nice -- it's even better if you halve the size of the image it's using first. This has the advantage that the characters actually look like the ones in the film (reversed numbers and Japanese katana (sp?) characters). That one's (obviously) X only. The other is 'cmatrix'. A web search should turn it up. As the name implies, this is a console version. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cd writer recommendation?
Amancio, On Mon, Aug 16, 1999 at 04:11:46PM -0700, Amancio Hasty wrote: > I simply am trying to get information on which cd-recorder works > well on FreeBSD. It will help to avoid confusion and postings if > there was a cd-record handbook section explaining all the gory > details. When you get your CD recorder working with FreeBSD, I look forward to your submission of documentation for the Handbook. :-) N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: doc/ tree breakage on Sunday 15th August
Heads up, [ cc: to -doc, -current, -committers, reply-to: nik ] On Sunday 15th August the doc/ tree will break. John Polstra will be performing surgery on the CVS repository[1], and when he's completed that I will be going in to fix up the build system infrastructure (all the Makefiles, primarily). If things go smoothly, the doc/ tree should be back and working by late Sunday evening (BST). If things go badly then it will be back and working by the end of Monday evening (BST). Prior to making these changes, John will announce a freeze on the doc/ repository. While this is going on, the doc/ tree will fail to build. This will impact on: * The web site, which uses the doc/ tree to build the FAQ, Handbook, and tutorials. On Thursday or Friday I will be altering the "webbuild" script so that it uses archived copies of the doc/ tree when rebuilding the web site. The site will therefore not be affected, however, any commits made to the FAQ, Handbook, or tutorials after I make the change will not show up on the site. The rest of the web site is unaffected. This will also affect our web site mirrors. I have been e-mailing the contacts for the mirrors to advise them, but a lot of the messages have been bouncing. Be prepared for some of the web site mirrors to either be out of date or broken for 24 hours or so. * "make release". Make sure you build with "NODOC=YES", otherwise the release build will fail. Jordan might want to make this the default -- although for what will hopefully amount to less than 24 hours of breakage it's probably not worthwhile. * Obviously, any -doc committers should get any commits they want in before the work by Saturday afternoon at the latest. So you know, there's a lot of work lined up in the queue ready to happen when this surgery is complete (I've been putting it off, because I didn't want to load the repository up with new files and then be moving them all over the place) including: * French translations of the FAQ and Handbook * The FAQ in DocBook * The beginnings of an infrastructure for http://docs.freebsd.org/ N [1] The nature of this surgery has been discussed extensively on the -doc mailing list, so I won't repeat that here. -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. - Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sitting inside, looking out...
[Reply-to set to -chat] On Tue, Aug 03, 1999 at 08:22:55PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Nik Clayton writes: > >Just for completeness; > > Yeah, sorry for leaving you gang out , but I didn't want to make > it too long, the important thing was to get the three main kinds > down, doc committers are pretty much the same story as the other > two "limited scope" types. Oh, absolutely. But you have to understand that the -doc committers are a rough crowd, and if I don't speak up for them every so they often they start saying rude things about my parentage. What's worse is the translation teams -- they say rude things about my parentage and I can't even understand what they're saying. . . [ Hmm, there's a thought -- could someone who speaks Japanese, Spanish, or one of the other languages we've got translated please check out the different translations of the FAQ, and make sure it doesn't just consist of "Nik's mother wears army boots" repeated again and again. Thanks ] > >At least, that's my take on it. > > > >>NOTE: If somebody can find a sponsor for it, I would really > >>like to offer an "official FreeBSD Committer sweat-shirt" > >>to each and every single committer. Luxury cars, free > >>vacations and suitcases filled with cash would also do. > > > >How about the FreeBSD Project coming up with the > >artwork, and then 'licensing' it to each user group? > > For it to have significance for the committers, it should be done in > such a manner that only the committers get their hands on them. As Matt points out, this has room to backfire. You can see the commit log now; Modified files: CVSROOT avail Log: John Smith is no longer a committer. He's promised to burn his t-shirt in private, and never mention this again. Given that (by and large) the committers are just a subset of a much larger developer base, and that we have developers who, for their own reasons, have declined to become committers, something that's limited to committers is probably not so great. But for patches that closed PRs, absolutely. We could maybe have a generic design that's registered as a copyright (or a trademark, or whatever) with the project, and the project can license this design out to user groups, or individuals, as necessary, and for a small fee. So, if the UK user group wanted to put out 'official UK FreeBSD user group' t-shirts then they can do so, for (say $20 licensing for the design, and $1 per t-shirt). And to pick another example at random, Matt could have a "FreeBSD VM God" t-shirt (and richly deserved it is too). But why stop at t-shirts? FreeBSD boxer shorts? Bra and panties? Anoraks? OK, maybe not the last one. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sitting inside, looking out...
Just for completeness; On Sat, Jul 31, 1999 at 09:42:26PM +0200, Poul-Henning Kamp wrote: > 2. Who are the committers anyway ? > -- > > All the noise about Matt Dillons commit bit have generated a lot > of questions about who gets to be committers, so here is a little > insight into the process of appointing a committer: > > Generally we in core operate with three kinds of committers: > > Ports committers > These are people who maintain one or more ports. > > If Asami-san wants to glue a bit on somebody, we will > generally let him. > > Limited scope committers > These are people who maintain some specific bit of the tree, > typically a subsystem they are (co-)authors of. A good example > is the HARP ATM stack, which Mike Spengler is taking care of > (and many thanks for that Mike!) > > Since these people are taken on board with a explicitly > stated limited scope, we are more relaxed about them than > we are about the last category. People have been known > to successfully sneak out from this category and into: > > Committers at large > These are the people who persist in sending well documented > PRs containing correct patches. The only way we have > devised so far for ridding ourselves of this kind of > annoying behaviour is to say "Here! you're a committer, > now close your own PRs!" :-) Doc committers Contributors to the Documentation Project. Generally stick within doc/ and www/, but have been known to wander in to the src/ hierarchy when manual pages need fixing up. There are generally two ways to become a doc committer. The first is the same as "Committers at large". Send enough good quality doc/ PRs and I'll get bored of committing them soon enough. The second is if you are maintaining a particular language translation of the FreeBSD docs (FAQ, Handbook, man pages, and so on). At least, that's my take on it. > NOTE: If somebody can find a sponsor for it, I would really > like to offer an "official FreeBSD Committer sweat-shirt" > to each and every single committer. Luxury cars, free > vacations and suitcases filled with cash would also do. What an excellent idea. How about the FreeBSD Project coming up with the artwork, and then 'licensing' it to each user group? The user groups handle the printing and distribution of the shirts as necessary (with appropriate local modifications as necessary) and probably charge $LOCAL_CURRENCY 1.00 or 2.00 more than the cost of the shirts, which gets punted back to the Project. I know I'd pay. Hmm. "I submitted a PR to FreeBSD, and all I got was this lousy t-shirt." > PS: See you all at the FreeBSD-con in October! http://www.freebsdcon.org/ Absolutely. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: junior-hacker task: "prepdisk"
On Sun, Aug 01, 1999 at 04:19:52PM +0200, Poul-Henning Kamp wrote: > The following script seems to DTRT for me, and should really be > either integrated into a "fdisk -A" flag or maybe as a stand alone > script. Either way: manpage & handbook needs updated too. What, specifically, is wrong with them? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release doc failure
On Wed, Jul 28, 1999 at 10:16:16AM -0400, John W. DeBoskey wrote: > ===> en/handbook > /usr/local/bin/jade -V html-manifest -ioutput.html -c /usr/doc/share/sgml/catalog >-c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c >/usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog -d >/usr/doc/share/sgml/freebsd.dsl -t sgml handbook.sgml > /usr/local/bin/jade:serialcomms/chapter.sgml:2016:2:E: general entity "man.boot.8" >not defined and no default entity > /usr/local/bin/jade:serialcomms/chapter.sgml:2016:19:E: general entity >"man.loader.8" not defined and no default entity > /usr/local/bin/jade:serialcomms/chapter.sgml:2680:12:E: general entity >"man.loader.conf.5" not defined and no default entity > *** Error code 1 My SNAFU, sorry 'bout that. Now fixed. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Moving ipf(1) to ipf(8)?
On Tue, Jul 20, 1999 at 04:58:49PM -0700, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Nik Clayton <[EMAIL PROTECTED]> wrote:
> > Assuming I did this, what's the approved method?
> >
> > Myself, I'd just
> >
> > # mv ipf.1 ipf.8
> > # cvs remove ipf.1
> > # cvs add ipf.8
> > # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8
> > [... check for any other man pages that refer to ipf(1) and update
> > them accordingly ...]
> >
> > which properly reflects that (until the change) ipf.8 didn't exist. I
> > *would not* use a repository copy for this.
>
> When in doubt, ask the repo-man. :-)
>
> There's enough history in the file that _if_ it were going to be
> renamed, a repository copy should be used. (I don't like them either,
> but they're What We Do.)
I'm curious -- why are they what we do? When I've used CVS on other
projects, it always made more sense to 'cvs remove' and 'cvs add'. That
way, if you checked out files by date stamp, and chose a date prior to
the renaming, the files you got back accurately reflected the state of
the repository at that time. If you repo copy then the file will always
have existed with the new name, even when other files (such as Makefiles)
would refer to the old name.
No?
> However, you shouldn't rename the file, because it is in the contrib
> tree. The whole point of contrib is that it must stay as nearly
> identical to the author's distributions as possible, so that imports
> of new versions aren't painful.
Duly noted.
> I think you should lobby the author <[EMAIL PROTECTED]> to rename
> the file in his own tree. Then the problem goes away when the next
> release is imported.
Will do.
> Meanwhile, if you want to install it into man8, you could do it with
> special rules in "src/sbin/ipf/Makefile". Something like this
> (untested) should do the trick:
>
> MAN8= ipf.8
> CLEANFILES+=ipf.8
>
> ipf.8: ipf.1
> cp ${.ALLSRC} ${.TARGET}
>
> and delete the MAN1 line for ipf.1.
I'll experiment with that (current task: get new laptop working with
Coda. . .)
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Moving ipf(1) to ipf(8)?
On Tue, Jul 20, 1999 at 10:40:03AM +0930, Kris Kennaway wrote: > On Mon, 19 Jul 1999, Nik Clayton wrote: > > > docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to > > (among other things) be consistent with ipfw(8). > > > > Anyone care to comment one way or the other? > > Definitely. Assuming I did this, what's the approved method? Myself, I'd just # mv ipf.1 ipf.8 # cvs remove ipf.1 # cvs add ipf.8 # cvs commit -m "Renamed ipf.1 to ipf.8" ipf.1 ipf.8 [... check for any other man pages that refer to ipf(1) and update them accordingly ...] which properly reflects that (until the change) ipf.8 didn't exist. I *would not* use a repository copy for this. I'm aware that some people's opinions of when you repository copy and when you don't are different, however. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Moving ipf(1) to ipf(8)?
How do, docs/7791 is of the opinion that ipf(1) should be moved to ipf(8), to (among other things) be consistent with ipfw(8). Anyone care to comment one way or the other? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HELP!!! -CURRENT libtool problem.
Satoshi. On Mon, Jul 12, 1999 at 12:31:52AM -0700, Satoshi - Ports Wraith - Asami wrote: > * From: Nik Clayton <[EMAIL PROTECTED]> > > I really wish you would stop spreading FUD. Don't open your mouth if > you don't know what you are talking about. I do know what I'm talking about -- specifically; > * I was under the impression that if you were CVSup'ing the ports tree then > * any changes to the ports subsystem (for example, new command line > * parameters to fetch(1)) would be utilised by the ports system *before* > * they had been merged in to -stable. The rationale being that if you > * were tracking the ports tree in that way then you should be tracking > * -current instead. I'm careful to state that it's my impression. Not that it's the gospel truth, but that's the 'vibe' I've picked up from the times when the ports and src trees have been out of sync, and I've gone scouring for answers as to what's happened. You're correct in that better awareness is almost definitely the key. Would you consider posting the -stable and -current port build results to -announce (and comp.unix.bsd.freebsd.announce) fortnightly, in the same way that the "New ports committed in the past two weeks" message is sent out? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Just the kind of news we needed...
On Mon, Jul 12, 1999 at 02:41:32PM -0400, David E. Cross wrote: > > > http://thc.pimmel.com/ > > > > > I actually found the article a very good source of documentation on > > programming loadable modules for FreeBSD. Granted, I'm not sure of it's > > accuracy, but it was a worthwhile read for someone like myself who has > > only coded LKMs for Linux. Very interesting. > > Agreed. Perhaps we could (with the author's permission) import this a bit > into the documentation project? He he. I'll contact them tomorrow, and see what I can work out. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HELP!!! -CURRENT libtool problem.
On Mon, Jul 12, 1999 at 03:54:40PM -0700, Chris Piazza wrote:
> Um..er... I hope you were really just being sarcastic. All ports
> should work on -stable as well as -current. In fact, more build
> on -stable than -current according to http://bento.freebsd.org/.
> If any ports work on one but not the other it is a bug and should
> be fixed. So I ask, what policy?
I was under the impression that if you were CVSup'ing the ports tree then
any changes to the ports subsystem (for example, new command line
parameters to fetch(1)) would be utilised by the ports system *before*
they had been merged in to -stable. The rationale being that if you
were tracking the ports tree in that way then you should be tracking
-current instead.
There have certainly been periods where my -stable system has been unable
to build new versions of ports where my the ports tree is perhaps a week
newer than the built source tree on my machine. Checking the mail archives
when this has happened has shown me the problem, and it's been relatively
simple to either build the thing by hand, or do a local merge of the
change from -current to my tree.
I'm hand-waving here slightly, as it's been a few months since I last needed
to do this, and specific cases are fuzzy in my memory at the moment, as it
just became an automatic process ("Oh, this port doesn't build, what
hasn't been merged in now?Right, fixed.") that
I didn't take particular note of the ports where it's been an issue.
But my point is that if we're warning people away from -current (and I'm
in complete agreement that this is a good idea) then we should also be
aware that as well as not being able to run the latest and greatest
FreeBSD code, we are occasionally giving them advice that means that
(apparently) unrelated systems (the ports tree) don't build properly.
It's not a big deal, but I see a lot of sweeping generalisations about
things like this (more so on Usenet, obviously), whether it's things like
"Run -stable for an easier life", or "FreeBSD is a better server than
Linux", or "OpenBSD is the most secure of the *BSDs", and it always bugs
me slightly.
:-)
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christiansen in <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HELP!!! -CURRENT libtool problem.
On Sun, Jul 11, 1999 at 08:13:37PM +0900, Daniel C. Sobral wrote: [snip] > "Q: Why shouldn't I just go ahead and run -current? That's got > all the latest stuff, right? [snip] > If you can live with that, and think you have any compelling reason > to run -current, read the handbook for further instructions. > > Sorry if this seems too harsh, but many people are just not used to > the concept of a development tree available publicly, and think of > it as the "latest version". It is *not* the latest version. When it > is *ready*, it will be the latest version. Until then... read the > above." > > Any other question? Q: I want to use this cool piece of software that's in the FreeBSD ports system. But I can't build it on my 3.x-stable system. Why not? A: Ah, sorry. The ports system only targets -current, trying to get it to work with -stable is too much work. If you want to be sure of using the ports system successfully you need to be running -current. Or was this policy reversed recently and I didn't notice (always a likely possibility). [ And yes, I *know* the ports system relies on volunteers, and that if people can't be bothered to test their ports on a -stable system then there's not a lot we can do about it. But this does lead to the amusing situation (for various values of "amusing") where on one hand we're telling people not to use -current unless they really know what they're doing, but on the other hand we're (in some cases) preventing them from using a major piece of FreeBSD infrastructure which is expressly designed to make life easier for exactly the sort of people who should be running -stable. ] N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Building www/en
On Tue, Jun 08, 1999 at 02:23:56PM -0700, Satoshi - Ports Wraith - Asami wrote: > * From: Nik Clayton > > * On Tue, Jun 08, 1999 at 07:41:13AM +1000, Peter Jeremy wrote: > * > My question is: How do I create /usr/local/share/sgml/docbook/catalog? > * > It doesn't exist in any of the ports. > * > * It's created by the post-install target of ports/textproc/docbook. > > Is it arranged to work for packages too? Err, absolutely no idea. I'll read up on the appropriate manual pages ASAP. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Building www/en
On Tue, Jun 08, 1999 at 07:41:13AM +1000, Peter Jeremy wrote: > My question is: How do I create /usr/local/share/sgml/docbook/catalog? > It doesn't exist in any of the ports. It's created by the post-install target of ports/textproc/docbook. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Review: Having aio.h include sys/time.h
How do, -hackers was silent about this, so I'm resending it to -current. Any comments before I commit this (trivial) change? N == docs/11589 says that programs that include aio.h also need to include sys/time.h. I've had a chat with Terry Lambert, who wrote the aio_read.2 manual page, who says > And here is a section from the aio.h manual page (from the > Single UNIX Specification): > > Inclusion of the header may make visible symbols > defined in the headers , , > and . > > Basically, this means that the aio.h header is *defined* as > including sys/types.h (because of off_t and size_t), and is > defined as either including the other headers as well (bad) > or as forward declaring some types as opaque: > Since the Single UNIX Specification make no note of a header > other than aio.h, I'm afraid that the answer is that the aio.h > must include these headers, or directly define the respective > types itself. > > While I dislike promiscuous headers, I believe it is better to > be able to compile and run standards compliant UNIX code. So I want to apply the following very trivial patch; Index: aio.h === RCS file: /home/ncvs/src/sys/sys/aio.h,v retrieving revision 1.9 diff -u -r1.9 aio.h --- aio.h 1999/01/17 22:33:08 1.9 +++ aio.h 1999/06/01 17:57:36 @@ -19,6 +19,7 @@ #ifndef _SYS_AIO_H_ #define_SYS_AIO_H_ +#include #include #include Any objections? I know nothing about the aio* stuff at all, which is why I'm checking first. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
On Wed, Jun 02, 1999 at 07:19:11PM +1200, Joe Abley wrote: > I would take issue with that. All of the regional registries require > extremely good justification for allocating static IP addresses to > transient network connections. Demon (a big ISP in .uk) allocate static IP addresses for *.demon.co.uk). They have a number of class B's, and I believe that RIPE (European IP registry) are quite happy with Demon's very efficient use of this space. > Other times the reason is "so the customer can carry on downloading > after the line dropped" to which the answer is "maintain your access > servers properly and this won't happen". Noise on the line, house mates inadvertently picking up the 'phone, plain bad luck. . . > Anyway, this is off-topic. Back to your scheduled programming. Agreed, Reply-to: points back to me. N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <37514...@cs.colorado.edu> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: Someone blew up the handbook again.
On Wed, May 12, 1999 at 01:48:02PM -0700, Jordan K. Hubbard wrote: > /usr/local/bin/jade -V html-manifest -ioutput.html -c > /usr/doc/share/sgml/catal > og -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c > /usr/local/share/sg > ml/docbook/3.0/catalog -c /usr/local/share/sgml/jade/catalog -d > /usr/doc/share/ > sgml/freebsd.dsl -t sgml handbook.sgml > /usr/local/bin/jade:install/chapter.sgml:279:13:E: character data is not > allowed > > Should I just turn NODOC on for the -current snapshot builds? No objection from me. I imagine that testing the FDP stuff isn't a major priority for people tracking -current. N -- There's some milk in the fridge about to go off. . . and there it goes. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: AIC
On Sun, Apr 11, 1999 at 11:29:09AM -0500, Bob Willcox wrote: > On Wed, Mar 31, 1999 at 12:28:47PM -0800, Brian Beattie wrote: > > On Wed, 31 Mar 1999, Warner Losh wrote: > > > The aic driver will likely oneday be ported. However, no one has come > > > forward to do it. It is a highly desirable driver to have (even if > > > > Umm, I'm still working on the aic driver. Slowly, but working on it. > > > > > writing it would be a pain) because the only pccard scsi cards that are > > > out there are aic-6[23]60 based. > > > > > > > Not having a pcmcia slot or card, I am not sure about support for this. > > I have both and would be willing to test it on my laptop. If you need a desktop tester of the new AIC driver, give me a shout. Upgrading to 3.0 broke my CDROM and internal Zip drive :-( N -- Bagel: The carbohydrate with the hole To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Handbook DocBook cutover complete
[ Sent to -current, and -doc Reply-to not set. Please reply only to the list appropriate for your comments. Thanks. ] Almost a year ago I started the project to switch the Handbook over from LinuxDoc to DocBook. I've pulled the big shiny lever, and the switch has now happened. This has meant that some URLs to pages within the Handbook have changed. Not many, but a few. For those not following the CVS lists, I've; * Removed this project as an entry from the Doc. Proj.'s "Current Projects" list at docproj/current.html * Checked every reference to the Handbook on the website and FAQ, and updated them where necessary to point to the new pages. * Updated the website make(1) infrastructure to use the DocBook Handbook instead of the LinuxDoc one. * Updated "make release" so that the DocBook Handbook is built. Reactivated the "distribute" target in doc/en/handbook/Makefile to make this happen. Turned off the LinuxDoc Handbook in doc/Makefile. * Edited doc/handbook/Makefile, so it's now a NOP. "make" in there will print a polite message and exit. You should be able to see the effect at roughly 0400 PST. If you can't wait that long, ftp://ftp.freebsd.org/pub/FreeBSD/doc/ *should* contain gzipped copies of the plain text, postscript, and HTML (split, and non split) versions. Assuming the feedback from this is positive I'll "cvs remove" doc/handbook from the repository in a few days time. I'll lift the Handbook freeze at the same point. Advocacy I haven't (yet) put this on the announces page of the website, because I want people to beat up on it in the wild for a day or so first. I'm fairly hopeless at writing press releases, but I think we should shout about this at least a little bit. If anyone wants to volunteer one, please do. If not, could someone (anyone) please forward me a sample FreeBSD press release that I can crib boiler plate from. At the very least I'll try and get it posted to * The Davenport (maintainers of DocBook) mailing list * The SGMLTools mailing list * www.freebsdrocks.com * slashdot.org (they probably won't post it, but you never know) * comp.text.sgml * DaemonNews [ Any other suggestions? ] It's worth mentioning that SGML is the older brother of XML, which is getting quite a lot of press recently. I don't know whether we can leverage that in any way. Known bugs -- * I probably haven't caught all the references to old Handbook pages on the site, so there might be some broken links. But I don't think so. This will impact on people who've linked to the Handbook from outside the FreeBSD site though. Sorry 'bout that. * The non-English Handbook's haven't been converted. * PDF generation is broken. I've got a fix, but I haven't tested it yet, and it involves updating a port I don't maintain, so it'll have to wait a couple of days. Acknowledgements My thanks to John Fieber, the previous Doc. Proj. manager. It's his fault I started doing this. I remember he thought it would take about 3 hours. 360 days later. . . Thanks also to James Clark, Norm Walsh, and Sebastian Rahtz. Respectively, they are resposible for Jade, which processes and formats the SGML source, the stylesheets which tell Jade how to format the document, and the TeX macros that allow pretty Postscript output. Finally, thanks to those other members of the FreeBSD community (particularly the TeX hackers) who were able to answer my questions when I stumbled in to areas way outside my sphere of competance. Right, I'm off to play Populous. . . -- Bagel: The carbohydrate with the hole To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
LinuxDoc -> DocBook cutover
Folks, [ sent to -doc and -current, reply-to points back to -doc ] I'm reasonably happy with the state of the DocBook handbook now, and am about ready to do the cutover. This involves changes to the website and to "make release". I'm waiting for feedback on patches that make these changes from a few interested parties, and will then make the changes. Probably at around 20:00 GMT on Friday 26th March. There is one outstanding issue with the DocBook conversion that I am aware of; * Generating the PDF version does not work, due to an overflow in v1.33 of the DSSSL stylesheets that do the formatting. All other formats (Postscript, plain text, HTML, RTF) are generated correctly. This problem is fixed in v1.37 of the stylesheets, but that revision introduces a different problem that badly affects the formatting. I am collaborating with the stylesheet author on a fix. I do not consider this to be a showstopper. Any objections? N -- Bagel: The carbohydrate with the hole To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: "make release" testers wanted for Doc. Proj.
On Fri, Mar 12, 1999 at 03:17:10PM -0800, Jordan K. Hubbard wrote: > This is done by make release in the chroot area. Ah. So it is. > > 2. Make sure /usr/doc/ is up to date (or wherever you store a > > This will have no effect on the chroot area - it's checked out > by make release. :) > > > 3. Edit doc/Makefile, and change the SUBDIR line from > > Ditto. I've got to stop sending these things late at night (glances at clock. Er, OK). What I actually did when I was testing this was to create a staging area (/usr/local/tmp/release in my case), and then run; # cd /usr/src/release # make RD=/usr/local/tmp/release release.1 release.2 doc.1 which seemed to put the files in the right place. If it puts them in the right place for other people (or this deafening silence continues) then I'll assume it's working properly (everyone else has been on the sharp end of "Hey, you broke 'make release'!" messages, now I want a piece of the action. . .) N -- Bagel: The carbohydrate with the hole To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Move doc. install to /usr/share/doc/en?
Folks,
Currently, the English versions of the FAQ and Handbook install in to
/usr/doc/FAQ and /usr/doc/handbook respectively.
The language specific versions install into /usr/doc/{language code}/FAQ
and /usr/doc/{language code}/handbook respectively.
If no one has any objections, I'd like to change this, and have the
English ones install in to /usr/doc/en/* as well. Symlinks could be used
so that /usr/doc/FAQ and /usr/doc/handbook point to whichever version is
most appropriate for the host it's installed on?
Any objections? Would this break anything?
N
--
Bagel: The carbohydrate with the hole
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
"make release" testers wanted for Doc. Proj.
Folks, If you're used to running "make release" I'd appreciate you trying the following and letting me know what happens. This is so that I can check that the DocBook version of the Handbook is being installed correctly. After checking out the most recent version of doc-all, please do the following; 1. Install the textproc/docproj port. This is a meta port which pulls in a few others. You do *not* need the TeX installation with this (not including it is the default, so you don't need to do anything out of the ordinary). 2. Make sure /usr/doc/ is up to date (or wherever you store a checked out copy of the doc-all repository). Specifically, the doc/Makefile should contain a LANGSUBDIR variable which *includes* the "en" directory. doc/en/handbook/Makefile should include a DISTRIBUTION variable. If either of these is missing then you're not up to date. 3. Edit doc/Makefile, and change the SUBDIR line from SUBDIR= FAQ handbook to SUBDIR= FAQ 4. Edit the doc.1 target in /usr/src/release/Makefile. Add "DOC_LANG=en" to the "make all distribute" call. 5. Run "make release" as normal. 6. Check that /trees/doc/usr/share/doc/handbook/ is populated by HTML files. 7. If you want to generate a plain text version of the Handbook as well, at step 4 above add "FORMATS= html-split txt" to the "make" line too. If that works flawlessly then great, I'm a step closer to the cut-over. If it doesn't, please let me know what went wrong. Thanks, N -- Bagel: The carbohydrate with the hole To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
