Re: Progress report: Multilingual sysinstall for -current
On Sat, Dec 09, 2000 at 11:36:26AM +0900, Tatsumi Hosokawa scribbled: | At Wed, 6 Dec 2000 18:18:50 -0600, | Michael C . Wu [EMAIL PROTECTED] wrote: | | Do you have Alpha boot floppies? Does kons25/big5con/korean compile | on Alpha? Would this fit on our ever growing mfsroot.flp and kern.flp? | | I don't have alpha machine and my knowledge about Alpha architecture | is very limited. But kons25 currently can't be compiled on Alpha | machine, and is disabled if ARCH==alpha (perhaps | release/localization/kon2 should be release/localization/i386/kon2). | | I recall seeing the release engineers struggling with fitting the kernel. | | I have committed to move *.ko modules to mfsroot.flp (and I think it's | easily extended to the third floppy or CD-ROM) last month. This is | not enabled on Alpha currently, but I think it can be also used on | alpha architecture. I've not put it to alpha floppy only because I | dont have alpha testbed. | | If you copy release/i386/drivers.conf to release/alpha and edit it to | fit the alpha architecture, drivers will be moved to mfsroot.flp | easily. | | It would be hard to make OpenBOOT and SRM do what we do in kons25. | (Doable, but someone has to do it.) I also know that Alpha | SRM+vidcontrol+sc0 can only have one video mode, 80x25. Can | Mr. Yokota clarify this for me? | | Does vidcontrol on Alpha support loadable font option? Russian | support uses only this function and does not use graphics console. | Other European languages can be supported in this way. Yes, vidcontrol on Alpha supports loadable fonts. But foxfair told me that he and vanilla looked into kons/big5con for Alpha. Their conclusion was that it is pretty impossible, but not too impossible. :) DECUnix/Tru64 has support for CJK and many other languages in SRM. However, FreeBSD's vidcontrol cannot do what SRM does, for some reason. -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Fri, Dec 08, 2000 at 06:17:52PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). I have lightly tested this on my -stable box, and would appreciate a feedback on them. Do not remove the USRDIRS and INCDIRS and replace it with mtree (ie make hierarchy). There's no need to duplicate the complete hierarchy inthe object tree. Also, mtree fiddles with ownership and mods, which is not appropriate when building. The -U flag to mtree(8) could be eliminated for this case... Which additional directories do you need? Everyting below /usr/share/tmac and /usr/share/groff_font: /usr/share/tmac /usr/share/tmac/locale /usr/share/tmac/mdoc /usr/share/tmac/mdoc/locale /usr/share/tmac/mm /usr/share/groff_font /usr/share/groff_font/devX100 /usr/share/groff_font/devX100-12 /usr/share/groff_font/devX75 /usr/share/groff_font/devX75-12 /usr/share/groff_font/devascii /usr/share/groff_font/devcp1047 /usr/share/groff_font/devdvi /usr/share/groff_font/devhtml /usr/share/groff_font/devkoi8-r /usr/share/groff_font/devlatin1 /usr/share/groff_font/devlbp /usr/share/groff_font/devlj4 /usr/share/groff_font/devps /usr/share/groff_font/devutf8 The new groff(1) release is likely to provide new groff_font subdirectories, so we would need to update USRDIRS every time we upgrade groff(1). Does it look reasonable? -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
$B%Q%A%s%3E9$N=P6L4IM}$NHkL)$G$9(B
$B%Q%A%s%3E9$N=P6L4IM}$NHkL)$G$9(B$B%Q%A%s%3E9$G$N!VBgEv$?$j!W$O%7%^$NItJ,ItJ,$K=8CDH/@8$7$^$9!#!JK\Ev$G$9!#!K(B$B$"$J$?$O$=$N;v
Re: Bootstrapping issues with groff(1)
On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Christopher Masto wrote: On Fri, Dec 08, 2000 at 11:23:00PM -0700, Wes Peters wrote: I am told that the Apple "AirPort Base Station", which is $399, works well and can be configured with the Java-based thing in the ports collection. I am further told that the Lucent/ORiNOCO RG-1000 base station is virtually identical, although more expensive and somehow inferior, although I don't understand the exact inferiorities. They're the same thing in different cases, it's hard to see how one can be superior in any way other than price. "The most stupid thing was that you couldn't set its network name to anything other than its serial number because on bootup, it copies its serial number over the first five bytes of the network name. It also can't be fully configured without the Windows software -- which is a bit misleading for me to say because even with the Windows software, you can only set it up to use the modem or provide NAT routing via Ethernet, and not set it up to do bridging." The "Windows software" is actually a Java applet that I saw running on FreeBSD at BSDCon. Don't believe everything you read, try to verify it first. I am thinking of getting one of these things, despite my strong desire to avoid owning such a stupid looking piece of hardware. Wait for the LinkSys; the dual antennas and price differential will be worth the wait. If the plethora of 802.11b equipment at BSDCon 2k is any indication, interoperability should be pretty good. But will I be able to configure the LinkSys? That's my primary concern. I only have FreeBSD, so if it requires any proprietary software at all, I can't use it. Besides that, I'll only be using this 10 feet away from the base. :-) If you're only 10 feet from the base, save several hundred dollars and buy a 4 meter patch cable. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000, Mike Meyer wrote: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000, Brandon D. Valentine wrote: On Sat, 9 Dec 2000, Mike Meyer wrote: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. And before somebody else jumps in, yes I fat-fingered the numpad. That's hier(7), not 5. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Brandon D. Valentine [EMAIL PROTECTED] types: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS, for instance. I claim that We don't seek to comply with the arbitrarily devised linux filesystem standard. We comply with hier(5), a standard steeped in decades of tradition. Corrections first: The only place where FreeBSD fails to follow FHS (in my quick perusal of it) is in putting packages in /usr/local instead of /opt. You can't blame that part of FHS on Linux - I have as yet to see a Linux distro or package do it that way. No, this bit comes from commercial vendors, where it's also steeped in years of tradition. Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. All of which has nothing to do with the question of whether we want to continue giving error messages that are wrong, or commit this patch and provide ones that are actually informative. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
In message [EMAIL PROTECTED] Christopher Masto writes: : If you're only 10 feet from the base, save several hundred dollars and buy : a 4 meter patch cable. : : Thanks, that hadn't occurred to me. It depends on the 10' :-) My laptop roams between 3' and 75' of my closest outlet. Usually 5-10'. Patch cables are cheaper and faster (when was the last time you got 100Mbps over wireless?). Wireless cards are easier to expand the net with and easier to take to a slightly different place :-) Warner -- Seen on the door of an egineer at sun: "We're the dot in vm.core" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Rant second: FreeBSD *violates* years of traditions with it's treatment of /usr/local. /usr/local is for *local* things, not add-on software packages! Coopting /usr/local for non-local software creates needless complexity and confusion, which of course leads to needless pain. Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, Dec 09, 2000 at 08:21:28PM +0100, [EMAIL PROTECTED] wrote: Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. That's why PREFIX exists. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. That's why PREFIX exists. Okay, let me rephrase: It would be nice if FreeBSD *by default* stored the packages/ports under /usr/pkg, like NetBSD (and the corresponding sources under /usr/pkgsrc). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, Dec 09, 2000 at 08:28:07PM +0100, [EMAIL PROTECTED] wrote: like NetBSD (and the corresponding sources under /usr/pkgsrc). Please stick to reasonable ideas. To move the CVS repo from ports/ to pkgsrc/ would be totally unreasonable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem With Man Formatting
I dropped off the list for a day, or so, during an ISP change. Did I miss a resolution? # ls -l `which groff` -r-xr-xr-x 1 root wheel 62860 Dec 7 00:01 /usr/bin/groff* # groff -v GNU troff version 1.16.1 #ls -l `which man` -r-sr-xr-x 1 man wheel 28576 Dec 7 00:01 /usr/bin/man* # man -d zzz ctype locale env: Invalid argument using more as pager ... status from is_newer() = -2 ... Formatting page, please wait... trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | /usr/bin/gzip -c) No output, debug mode. using default preprocessor sequence Couldn't open /usr/share/man/cat8/zzz.8.gz.tmpiYU0us for writing. using default preprocessor sequence trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | more) tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local misuse (Was: Confusing error messages from shell image activation)
Will Andrews [EMAIL PROTECTED] types:
On Sat, Dec 09, 2000 at 08:21:28PM +0100, [EMAIL PROTECTED] wrote:
Agreed. It would be nice if FreeBSD could use the same system as NetBSD,
storing the packages/ports under /usr/pkg.
That's why PREFIX exists.
I know. Unfortunately, support for PREFIX seems to draw more lip
service than actual service. I've urged a number of times that
portlint should test for this, or that the porters handbook should
include instructions for checking this (it's actually pretty easy),
all to no avail. Last time I checked, Perl modules installed by the
standard perl module installer always go to /usr/local. Other may go
to ${PREFIX}, but the Perl interpreter doesn't know to search there
for modules, so the port generally winds up broken anyway.
On the upside, I regularly pr (with patches as often as possible)
ports that aren't PREFIX-clean, and they do get fixed.
mike
--
Mike Meyer [EMAIL PROTECTED] http://www.mired.org/home/mwm/
Independent WWW/Unix/FreeBSD consultant,email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Ruslan Ermilov wrote: On Fri, Dec 08, 2000 at 06:22:09PM -0800, Marcel Moolenaar wrote: Ruslan Ermilov wrote: The attached patches (p4 and p5) try to solve this bootstrapping problem with groff(1). Sorry, I missed this statement before. What exactly are the bootstrapping problems you're seeing? New groff(1) provides new versions of macro packages and device files. When building, we should use THEM rather than installed (obsolete) ones. Is the old groff(1) incompatible with the new groff(1) in the sense that manpages created with the old groff(1) are visibly different from the manpages created with the new groff(1)? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Is this the problem I see with mal-formatted man pages? The pages appear as 1 block with no headers, tities, etc. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: Is this the problem I see with mal-formatted man pages? Possibly. I don't know if we changed files to get our sources working with the new groff(1). If we did, we definitely have a bootstrapping problem, because that would mean that we can't reliably create manpages with the old groff(1). If this is the case for you, then remaking the manpages with the new groff(1) should solve your problem. If that doesn't help, then you have to give us more information to work on. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Not likely to happen - people have an investment in the current scheme and it would certainly mess with their heads if one day FreeBSD suddenly started doing something entirely different than what it's been doing for the last 7 years. For those who really want to track the NetBSD way of doing things, it can be set according to their own tastes. - Jordan Agreed. It would be nice if FreeBSD could use the same system as NetBSD, storing the packages/ports under /usr/pkg. That's why PREFIX exists. Okay, let me rephrase: It would be nice if FreeBSD *by default* stored the packages/ports under /usr/pkg, like NetBSD (and the corresponding sources under /usr/pkgsrc). Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
There is also a new access point (either just available or "RSN") from Zyxel (316); it is a combination of a 310 (cable modem/bridged DSL/PPPOE router) and single-card bridged access point. I'm using one at work (overkill since I'm not using the router) as a bridged access point; it works just fine in that role (plug the ethernet into the "LAN" (10/100!) port and leave the "WAN" port empty). Stock it only comes with 40 bit but maybe could be used with a gold (or equivalent) card (haven't tried it, though). The card it comes with is OEM'd by someone (Melco?) and does have an antenna jack. At home I'm currently using a Lucent card in a FBSD machine as a base; IBSS create does work; it gets a hybrid between BSS and ad-hoc mode (at least the client connects in infrastructure mode). In this mode the client is transmitting a lot, though; makes the laptop power supply get pretty warm. -- Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
# ls /usr/share/man/man*/zzz* /usr/share/man/man8/zzz.8.gz # ls /usr/share/man/cat*/zzz* ls: No match. Ok, so, man zzz should reformat the man page. I have attached the output of 'man -d zzz' and 'man zzz' After 'man zzz', I see # ls /usr/share/man/cat*/zzz* /usr/share/man/cat8/zzz.8.gz So, the man page was reformatted with the new groff. tomdean === # man -d zzz ctype locale env: Invalid argument using more as pager found mandatory man directory /usr/share/man found mandatory man directory /usr/share/perl/man found optional man directory /usr/local/lib/perl5/5.00503/man found manpath map /bin -- /usr/share/man found manpath map /usr/bin -- /usr/share/man found manpath map /usr/local/bin -- /usr/local/man found manpath map /usr/X11R6/bin -- /usr/X11R6/man search path for pages determined by manpath is /usr/home/tomdean/man:/usr/local/man:/usr/share/man:/usr/X11R6/man:/usr/local/LessTif/doc/man:/usr/local/pgsql/man adding /usr/home/tomdean/man to manpathlist adding /usr/local/man to manpathlist adding /usr/share/man to manpathlist adding /usr/X11R6/man to manpathlist Warning: couldn't stat file /usr/local/LessTif/doc/man! adding /usr/local/pgsql/man to manpathlist searching in /usr/home/tomdean/man trying section 1 with globbing globbing /usr/home/tomdean/man/man1/zzz.1* globbing /usr/home/tomdean/man/man1/zzz.0* globbing /usr/home/tomdean/man/cat1/zzz.1* globbing /usr/home/tomdean/man/cat1/zzz.0* searching in /usr/local/man trying section 1 with globbing globbing /usr/local/man/man1/zzz.1* globbing /usr/local/man/man1/zzz.0* globbing /usr/local/man/cat1/zzz.1* globbing /usr/local/man/cat1/zzz.0* searching in /usr/share/man trying section 1 with globbing globbing /usr/share/man/man1/zzz.1* globbing /usr/share/man/man1/zzz.0* globbing /usr/share/man/cat1/zzz.1* globbing /usr/share/man/cat1/zzz.0* searching in /usr/X11R6/man trying section 1 with globbing globbing /usr/X11R6/man/man1/zzz.1* globbing /usr/X11R6/man/man1/zzz.0* globbing /usr/X11R6/man/cat1/zzz.1* globbing /usr/X11R6/man/cat1/zzz.0* searching in /usr/local/pgsql/man trying section 1 with globbing globbing /usr/local/pgsql/man/man1/zzz.1* globbing /usr/local/pgsql/man/man1/zzz.0* globbing /usr/local/pgsql/man/cat1/zzz.1* globbing /usr/local/pgsql/man/cat1/zzz.0* searching in /usr/home/tomdean/man trying section 1aout with globbing globbing /usr/home/tomdean/man/man1aout/zzz.1aout* globbing /usr/home/tomdean/man/man1aout/zzz.0* globbing /usr/home/tomdean/man/cat1aout/zzz.1aout* globbing /usr/home/tomdean/man/cat1aout/zzz.0* searching in /usr/local/man trying section 1aout with globbing globbing /usr/local/man/man1aout/zzz.1aout* globbing /usr/local/man/man1aout/zzz.0* globbing /usr/local/man/cat1aout/zzz.1aout* globbing /usr/local/man/cat1aout/zzz.0* searching in /usr/share/man trying section 1aout with globbing globbing /usr/share/man/man1aout/zzz.1aout* globbing /usr/share/man/man1aout/zzz.0* globbing /usr/share/man/cat1aout/zzz.1aout* globbing /usr/share/man/cat1aout/zzz.0* searching in /usr/X11R6/man trying section 1aout with globbing globbing /usr/X11R6/man/man1aout/zzz.1aout* globbing /usr/X11R6/man/man1aout/zzz.0* globbing /usr/X11R6/man/cat1aout/zzz.1aout* globbing /usr/X11R6/man/cat1aout/zzz.0* searching in /usr/local/pgsql/man trying section 1aout with globbing globbing /usr/local/pgsql/man/man1aout/zzz.1aout* globbing /usr/local/pgsql/man/man1aout/zzz.0* globbing /usr/local/pgsql/man/cat1aout/zzz.1aout* globbing /usr/local/pgsql/man/cat1aout/zzz.0* searching in /usr/home/tomdean/man trying section 8 with globbing globbing /usr/home/tomdean/man/man8/zzz.8* globbing /usr/home/tomdean/man/man8/zzz.0* globbing /usr/home/tomdean/man/cat8/zzz.8* globbing /usr/home/tomdean/man/cat8/zzz.0* searching in /usr/local/man trying section 8 with globbing globbing /usr/local/man/man8/zzz.8* globbing /usr/local/man/man8/zzz.0* globbing /usr/local/man/cat8/zzz.8* globbing /usr/local/man/cat8/zzz.0* searching in /usr/share/man trying section 8 with globbing globbing /usr/share/man/man8/zzz.8* to_name in convert_name () is: /usr/share/man/cat8/zzz.8.gz will try to write /usr/share/man/cat8/zzz.8.gz if needed status from is_newer() = -2 using default preprocessor sequence mode of /usr/share/man/cat8/zzz.8.gz.tmpwUNTCA is now 644 Formatting page, please wait... trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | /usr/bin/gzip -c) No output, debug mode. using default preprocessor sequence Couldn't open /usr/share/man/cat8/zzz.8.gz.tmpB0cdyZ for writing. using default preprocessor sequence trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | /usr/bin/col | more) = # man zzz Formatting page, please wait...Done. controls the Intel / Microsoft APM (Advanced Power
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc trying command: (cd /usr/share/man ; /usr/bin/zcat /usr/share/man/man8/zzz.8.gz | /usr/bin/tbl | /usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
/usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc This was generated by 'man', not me. There appears to be a problem in man. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote: On the other hand, I also don't want to use mtree. The only thing you don't like about mtree is it changing ownership + modes, right? If so, what about a new flag to mtree to make it only create directories and nothing else? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local misuse (Was: Confusing error messages from shell image activation)
On Sat, Dec 09, 2000 at 01:59:51PM -0600, Mike Meyer wrote: I know. Unfortunately, support for PREFIX seems to draw more lip service than actual service. I disagree. If one of the ports I maintain isn't PREFIX-clean, let me know and it _will_ be fixed. If you know others, please open a PR, let me know and I'll assign it to the maintainer. or that the porters handbook should include instructions for checking this (it's actually pretty easy), I always thought ``make PREFIX=/tmp/foo package'' is pretty obvious.. but maybe not... -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
David O'Brien wrote: On Sat, Dec 09, 2000 at 12:43:24PM -0800, Marcel Moolenaar wrote: On the other hand, I also don't want to use mtree. The only thing you don't like about mtree is it changing ownership + modes, right? Not only that. Using mtree(1) creates busloads of unnecessary directories. It's too brute-force in my book. If there's a clean way to create selective subtrees and do that without setting ownership and file mods, then I'm happy. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
Poul-Henning Kamp wrote: | Partition table | Data| | Slice 1 | Slice 2 | Slice 3 | Slice 4 | | Disklabel | Data | | c | |a|b|f|g| That is really an excellent diagram. That should be in an FAQ somewhere. Doc committers? Except it is not actually correct. The BSD disklabel is usually inside the 'a' partition and certainly inside the 'c' Is that so? Mea culpa, then. At least I knew what I was talking about wrt partition table and the actual slices. This diagram is just an example. There can be less slices, it doesn't show extended partitions (extended slices??? :), it suggests an ordering that is not necessary. If this is going to the FAQ or the handbook, a number of notes should be made to point out these (and possibly others I'm overlooking right now) issues. -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: /usr/bin/groff -S -Wall -mtty-char -man -Tascii | ... should be -mandoc This was generated by 'man', not me. I understand that. There appears to be a problem in man. Not that I'm aware of. Did you verify your settings? ie build options env.vars and local modifications? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic: vm_pageout_flush: partially dirty page
Hi,
ever since this commit: ...
dillon 2000/11/18 15:06:27 PST
Modified files:
sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c
vfs_vnops.c
sys/sys buf.h vnode.h
sys/ufs/ffs ffs_inode.c ffs_softdep.c
sys/ufs/ufs ufs_readwrite.c
sys/vm swap_pager.c vm_page.c vm_page.h
vm_pageout.c
Log:
Implement a low-memory deadlock solution.
... I can very reliable reproduce this panic.
I have INN running here (inn-2.3.0 straight from /usr/ports) and feed
it articles with suck. Actually suck is run twice in a row (for
different news servers) and as soon as the second run starts feeding
articles to innd, the panic occurs. (In a few cases the panic occured
a bit later, maybe 30 seconds.)
I've appended some output from gdb and put a crash dump (96 MB / 17MB
gzipped) and a debug kernel on http://ltilx150.etec.uni-karlsruhe.de/p/
(This is with sources from today.)
Some additional observations:
-The INN is compiled with mmap(). The history file has about 11 MBytes,
the active file has just 23 lines :-).
-The output from "trace" in ddb has one line more than gdb's
"backtrace":
[...]
sync_fsyc(c76e1f7c) at sync_fsync + 0xcf
sched_sync at sched_sync + 0x13a
fork_trampoline at fork_trampoline + 0x1c
-Apart from this situation, I haven't seen this (or any other) panic.
Please let me know if I should provide additional information.
Bye, Philipp
--
http://www.uni-karlsruhe.de/~un1i/ (,.)
\\\00 )
\= )
cc_|\_,^
gdb -k kernel.73.debug vmcore.73
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...
IdlePTD 4055040
initial pcb at 32e6c0
panicstr: from debugger
panic messages:
---
panic: vm_pageout_flush page 0xc04eacd0 index 0/1: partially dirty page
panic: from debugger
Uptime: 4m2s
dumping to dev da0s1b, offset 26624
dump 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70
69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41
40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12
11 10 9 8 7 6 5 4 3 2 1
---
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:477
477 if (dumping++) {
(kgdb) bt
#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:477
#1 0xc0178080 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:320
#2 0xc01784d9 in panic (fmt=0xc02b70d4 "from debugger")
at /usr/src/sys/kern/kern_shutdown.c:570
#3 0xc0132c01 in db_panic (addr=-1071064268, have_addr=0, count=-1,
modif=0xc70e1c4c "") at /usr/src/sys/ddb/db_command.c:433
#4 0xc0132ba1 in db_command (last_cmdp=0xc02f81d4, cmd_table=0xc02f8034,
aux_cmd_tablep=0xc031acb8) at /usr/src/sys/ddb/db_command.c:333
#5 0xc0132c66 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455
#6 0xc0134e2b in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_trap.c:71
#7 0xc028d8c6 in kdb_trap (type=3, code=0, regs=0xc70e1d4c)
at /usr/src/sys/i386/i386/db_interface.c:163
#8 0xc029989c in trap (frame={tf_fs = 16, tf_es = 16, tf_ds = 16, tf_edi = 0,
tf_esi = 256, tf_ebp = -955376232, tf_isp = -955376264,
tf_ebx = 2097666, tf_edx = -1072980320, tf_ecx = 32, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1071064268, tf_cs = 8,
tf_eflags = 2097222, tf_esp = -1070695009, tf_ss = -1070848829})
at /usr/src/sys/i386/i386/trap.c:589
#9 0xc028db34 in Debugger (msg=0xc02c24c3 "panic") at machine/cpufunc.h:60
#10 0xc01784d0 in panic (
fmt=0xc02e2580 "vm_pageout_flush page %p index %d/%d: partially dirty page") at
/usr/src/sys/kern/kern_shutdown.c:568
#11 0xc027798f in vm_pageout_flush (mc=0xc70e1df4, count=1, flags=0)
at /usr/src/sys/vm/vm_pageout.c:378
#12 0xc0274902 in vm_object_page_clean (object=0xc78754e0, start=0, end=0,
flags=4) at /usr/src/sys/vm/vm_object.c:655
#13 0xc01ae696 in vfs_msync (mp=0xc0aa1200, flags=2)
at /usr/src/sys/kern/vfs_subr.c:2597
#14 0xc01aea73 in sync_fsync (ap=0xc70e1f7c)
at /usr/src/sys/kern/vfs_subr.c:2866
#15 0xc01ac9e6 in sched_sync () at vnode_if.h:423
(kgdb) frame 15
#15 0xc01ac9e6 in sched_sync () at vnode_if.h:423
423 rc = VCALL(vp, VOFFSET(vop_fsync), a);
(kgdb) print a
$1 = {a_desc = 0xc02f2a40, a_vp = 0xc781bd00, a_cred = 0xc0699e00,
a_waitfor = 3, a_p = 0xc6a0cfe0}
(kgdb) print vp
$2 = (struct vnode *) 0xc781bd00
(kgdb) print *((struct vnode *) 0xc781bd00)
$3 =
Re: /usr/local misuse (Was: Confusing error messages from shell image activation)
David O'Brien [EMAIL PROTECTED] types: On Sat, Dec 09, 2000 at 01:59:51PM -0600, Mike Meyer wrote: I know. Unfortunately, support for PREFIX seems to draw more lip service than actual service. I disagree. If one of the ports I maintain isn't PREFIX-clean, let me know and it _will_ be fixed. If you know others, please open a PR, let me know and I'll assign it to the maintainer. Like I said, I do report them when I find them. However, things like ports with perl modules being either PREFIX dirty or broken tend to be pretty damning. But my comment is based on the experience of running a system with LOCALBASE set to something other than /usr/local. If you run systems that way and have a different experience, I'd be interested in hearing about it. or that the porters handbook should include instructions for checking this (it's actually pretty easy), I always thought ``make PREFIX=/tmp/foo package'' is pretty obvious.. but maybe not... It's not obvious to me. It's also not mentioned in the handbook anywhere. I suspect that most people are like me, and seldomp build packages - which would explain why it's not obvious. What does the above command do if the port isn't PREFIX clean? My personal test is "make PREFIX=/tmp/foo install make deinstall". If something in the plist is installed outside of /tmp/foo, the deinstall will complain when it can't find it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000 12:32:01 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: There are other places where FreeBSD doesn't comply with the appropriate standard - packages vs. FHS I have never heard of ``FHS''. What is its ANSI, FIPS, IEEE, IEC, or ISO number? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: write(2) returns error saying read only filesystem when trying to write to a partition
Bruce Evans [EMAIL PROTECTED] wrote: On Fri, 8 Dec 2000, Matthew Thyer wrote: Mike Smith wrote: The program works on Compaq True64 UNIX v 4.0d It also works on Solaris 7 (only tested sparc). So it seems FreeBSD is broken here. FreeBSD just behaves differently. If you want to write to the whole disk, open the whole-disk device, not the 'c' partition. Thanks Mike, /dev/da18 works fine for me although I notice that /dev/da18s1 does not. There seems to be some inconcistencies in this area. Please tell me (and for the benefit of the list) as to why I cant use /dev/da18s1c ? Because metadata (i.e,. label) write protection actually works on /dev/da18s1c. It is supposed to be possible to turn off write protection using the DIOCWLABEL ioctl, but IIRC this only works if the data written over the label area is a valid label (if there is already a label there, as there must be for /dev/da18s1c to exist), so labels can't be cleared by writing zeros to them (zeros don't give a valid label). Labels can be cleared by zeroing them using the whole-disk device. All subdevices of the device should be closed before starting, and none except the whole-disk device should be opened before finishing, to ensure that the old in-core copy of the label isn't used. Someone broke dd(1) to always turn off write protection of labels, to hack around a bug in the alpha disklabel code (someone broke the label for the whole-disk device by making it a real label to hack around a non-understood bug that is said to break sysinstall; real labels are write protected, so the whole-disk device can't be used to bypass the write protection). Since overwriting labels doesn't work quite right even when write protection is turned off, I'm not sure how the breakage helps. O'Brien said that it was totally necessary to be able to do it. If it's the hack that the alpha users need, it's not really my place to try to analyze the how and why of alpha breakage to determine whether it's proper or not if I have no alpha systems. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
On Sat, 9 Dec 2000, David O'Brien wrote: On Sat, Dec 09, 2000 at 08:28:07PM +0100, [EMAIL PROTECTED] wrote: like NetBSD (and the corresponding sources under /usr/pkgsrc). Please stick to reasonable ideas. To move the CVS repo from ports/ to pkgsrc/ would be totally unreasonable. I've always thought /usr/pkg/src a logical place to put it. -- Brandon D. Valentine [EMAIL PROTECTED] "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
I have no environment settings that relate to groff and only MANPATH that relates to man. There are no local modifications. etc/make.conf only has CFLAGS= -O -pipe HAVE_MOTIF= yes MOTIF_STATIC= yes USA_RESIDENT= YES WRKDIRPREFIX= /usr/obj/ports NO_MODULES= NO I have always done cvsup followed by 'make world'. # cd /usr/src/gnu/usr.bin # make clean # cd /usr/src # make -DNOCLEAN world fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could it be a problem with the Makefile in man? Next week, I will do a cvsup, etc. I will use -j36 and see if it changes anything. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
"Thomas D. Dean" wrote: # cd /usr/src/gnu/usr.bin # make clean # cd /usr/src # make -DNOCLEAN world fixed the problem. Before, I used 'make -j36 -DNOCLEAN world'. Could it be a problem with the Makefile in man? -DNOCLEAN is not guaranteed to work. Especially when makefiles change. Use with care! -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
