Re: /usr/local misuse (Was: Confusing error messages from shell image activation)
In message [EMAIL PROTECTED] Mike Meyer writes: : I know. Unfortunately, support for PREFIX seems to draw more lip : service than actual service. Actually, which ports, specically, doesn't this work with? I've installed several ports with PREFIX defined to something odd and have had minimal problems. : On the upside, I regularly pr (with patches as often as possible) : ports that aren't PREFIX-clean, and they do get fixed. Maybe I have you to thank for my good luck :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
chun chun !!!
âÁÙ` ´ÏÔTCgݯÁ¿áÁ½B http://216.101.214.74/1/ ³¿æA éæñB ¶áAܽË`B ¿ãñ¿ãñ¿áñæè To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fxp driver not reset after Windows reboot?
Hello, On my VAIO laptop, I have trouble rebooting directly from Windows to FreeBSD (luckily enough I don't run Windows that often :-) I tried to look at the driver code, but it looks to me like it is doing resets when attaching the fxp driver, but somehow, Windows has left it in the state where it isn't recognized properly. Below I have dmesg output, stripped to the fxp0 part. Does anyone have an idea what the problem might be, or where to try to debug this? I have added some comments to the dmesg output, /* here */, to add the programs running there Mark FreeBSD 5.0-CURRENT #0: Wed Dec 6 09:34:39 CET 2000 [EMAIL PROTECTED]:/usr/src2/sys/compile/vaio Preloaded elf kernel "kernel" at 0xc042b000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc042b09c. Preloaded elf module "if_fxp.ko" at 0xc042b0ec. fxp0: Intel Pro 10/100B/100+ Ethernet port 0xfcc0-0xfcff mem 0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps BRIDGE 990810, have 7 interfaces -- index 1 type 6 phy 0 addrl 6 addr ff.ff.ff.ff.ff.ff /* dhclient leads to the below */ fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 /* IPv6 router sollicitation below */ fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 /* various stuff like apache etc below */ fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 fxp0: SCB timeout fxp0: SCB timeout fxp0: device timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 fxp0: SCB timeout fxp0: SCB timeout fxp0: device timeout fxp0: SCB timeout /* etc etc */ 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
Mike Meyer wrote: 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. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. Honestly, let it go. -- 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: write(2) returns error saying read only filesystem when tryingto write to a partition
On Sun, 10 Dec 2000, Daniel C. Sobral wrote: 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??? :), This leaves out the most interesting (complicated) part. FreeBSD supports the fully recursive version of them: Slice := OrdinarySlice or ExtendedSlice OrdinarySlice := LabeledSlice or UnlabeledSlice (see above for layouts) Layout of ExtendedSlice: | ExtendedSlice | | Partition table | Slice | Slice | Slice | Slice | The recursion gives a quaternary tree with OrdinarySlices as leaves. For compatibility with other OS's (ones whose fdisk program actually supports creating the tree :-), the full tree must not be used. There must be at most ExtendedSlice at each level, and at most one nonempty OrdinarySlice except at the top level where there may be up to 4 OrdinarySlices. The tree thus reduces to a list with up to 3 warts at the top. 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. Other things not shown in the diagram: - there may be more partitions (d|e|h). - slice and partition order may be non-physical. - slices may overlap the partition table in dubious configurations, including the "Dangerously Dedicated" one. - slices may overlap each other in dubious configurations. I sometimes use this feature to help move slices. - partitions may overlap each other (... similarly). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possibly related data point - (was) Re: Current Broken!
On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote: I'm not a constraints expert either, but I noticed that when I try to build a kernel WITHOUT any optimization, I get a failure in /usr/src/sys/i386/atomic.h . # make atomic.o cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs ... /usr/src/sys/i386/i386/atomic.c In file included from /usr/src/sys/i386/i386/atomic.c:48: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:178: inconsistent operand constraints in an `asm' with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer is optimizing out the offending contraints. Ouch. Probably not what was intended. Maybe this is what's biting you ? This is sort of the opposite of the bug in machine/mutex.h. It is believed to be caused by using the operand-number constraints (e.g., "(0)") to declare input-output operands in machine/atomic.h. Input-output operands and/or these constraints apparently never worked right until a recent versions of gcc introduced the "+" contraint to declare input-output operations properly. machine/atomic.h uses the new constraint. The problem seems to be that "+" contraints don't work right either. The following kludge fixes compilation of cam_periph.c: diff -c2 mutex.h~ mutex.h *** mutex.h~Sun Dec 10 19:28:53 2000 --- mutex.h Sun Dec 10 23:50:21 2000 *** *** 171,174 --- 176,180 \ __asm __volatile ( \ + " movl$" _V(MTX_UNOWNED) ",%%eax;"\ " " MPLOCKED "" \ " cmpxchgl %4,%0;"/* try easy rel */ \ *** *** 181,185 "# exitlock_norecurse"\ : "+m" (mtxp-mtx_lock),/* 0 */ \ ! "+a" (_tid) /* 1 */ \ : "gi" (type), /* 2 (input) */ \ "g" (mtxp), /* 3 */ \ --- 187,191 "# exitlock_norecurse"\ : "+m" (mtxp-mtx_lock),/* 0 */ \ ! "=a" (_tid) /* 1 */ \ : "gi" (type), /* 2 (input) */ \ "g" (mtxp), /* 3 */ \ This bug seems to have been encountered before -- I copied this inferior code from the function before the one that doesn't compile. Several other functions in machine/mutex.h also use it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possibly related data point - (was) Re: Current Broken!
On Fri, 8 Dec 2000, John Baldwin wrote: On 08-Dec-00 [EMAIL PROTECTED] wrote: John, I'm not a constraints expert either, but I noticed that when I try to build a kernel WITHOUT any optimization, I get a failure in /usr/src/sys/i386/atomic.h . Compiling a kernel with anything but -O for optimization is not supported. gcc has produced buggy code for the -O0 case in the past. -O0 (or plain cc without -O) is supposed to work, but no one cares enough about it to fix it every day. Fixing machine/atomic.h has been pending for many days now. My oldest saved mail about it is dated 21 July 2000, but ISTR discussing it last year. Bruce 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)
Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Mike Meyer writes: : I know. Unfortunately, support for PREFIX seems to draw more lip : service than actual service. Actually, which ports, specically, doesn't this work with? I've installed several ports with PREFIX defined to something odd and have had minimal problems. Well, all the ones I *specifically* know about I've already PR'ed. Except for the ones that use Perl, and I don't remember if PR'ed that, or just made sure the maintainer was was aware of 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
[Please watch your carbon copies!] On Sun, 10 Dec 2000 09:37:53 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. No software that is a part of FreeBSD installs in /usr/local. As a convenience feature, FreeBSD includes software from third parties which does so, and in most cases has always done so by default. -GAWollman 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
Daniel C. Sobral [EMAIL PROTECTED] types: Mike Meyer wrote: 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. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I don't expect to get it changed until enough people are aware that it's a problem. Occasional rounds of consciousness-raising are required to make that happen. That may not happen until the old guard dies of old age; I asume we both want FreeBSD to be a viable OS that long. Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Mike Meyer writes: : 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. Not as many as you might think. /usr/local predates /opt by several years. I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. : 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. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. 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
Garrett Wollman [EMAIL PROTECTED] types: On Sun, 10 Dec 2000 09:37:53 -0600 (CST), Mike Meyer [EMAIL PROTECTED] said: However, FreeBSD is still the only vendor distribution I know of that installs software in /usr/local. That's the problem - software that comes from the vendor doesn't belong in the local administrative regime. No software that is a part of FreeBSD installs in /usr/local. As a convenience feature, FreeBSD includes software from third parties which does so, and in most cases has always done so by default. Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. 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
Mike Meyer writes: If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. If you remember v6 and v7, then please enumerate the packages which installed in /opt on those systems. All "packages" I am aware of from the v6/v7 era installed in /usr or in /usr/local, although I am sort of fuzzy on the exact derivation of /usr/local at this point in time. I do recall having a /usr/local on my V6 PDP-11/40, but it could have been contamination leaking over from the 32V system. I do remember the abomination of /usr/ucb which put binaries in /usr/ucb but also included /usr/ucb/lib, etc. I always hated that structure. I know that we made extensive use of /usr/local in 1983 on 4.1bsd, especially in installing software taken from Usenet, so I think that /usr/local really started with extensive use of Usenet distribution, which was coincident with wide-spread use of BSD on VAXen. As far as I remember, I never encountered the use of /opt until Solaris. /Joe 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 Sun, Dec 10, 2000 at 10:13:42AM -0600, Mike Meyer wrote: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. You are really reaching here. Contributed software that the FreeBSD Project has chosen to integrate, i.e., Perl, Sendmail, just to name a few, are integrated tightly and installed in /usr/bin, etc, not in /usr/local. Ports, on the other hand are installed in /usr/local or /usr/X11R6. You seem to mis-understand that a FreeBSD port is basically a set of patches and a source fetching mechanism that is included with FreeBSD as a convenience for building and installing third party software. The actual software that gets built and installed is _not_ part of FreeBSD. This is not a rationalization. I for one would be really upset if when I installed a Port, it's binaries started getting dropped into /bin, /usr/bin, etc. I suspect many others would too. I'm really not exactly sure what you are complaining about. For example, the last time I built Emacs for Solaris (several years ago admittedly), by default it installed itself into /usr/local. If you install Emacs onto FreeBSD, it goes into /usr/local. The behaviour is the same. Are you proposing that since FreeBSD provides a set of patches so that Emacs builds cleanly, that it should therefore install it somewhere other than /usr/local? -Brian -- Brian Dean [EMAIL PROTECTED] [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
Mike Meyer [EMAIL PROTECTED] writes: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. Your argument doesn't make much sense to me. So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? If I grab a sawfish FreeBSD package from the sawfish website, where should that install? /usr/local? /opt? /usr/pkg? Third party software is third party software, no matter who compiled and packaged it. If I install a package of third-party software, the end result should be about the same as if I compiled and installed it by hand -- the packaged software is a convenience, not a fundamentally different entity. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Package installation location
Within the scope of this problem, would it not be simple to code in a configuration diretive in the build process, such that a simple entry in /etc/make.conf would tell the ports build where to install ($prefix)? Then, the local admin can make that decision.. whether or not to default to /usr/local. _F To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Joe Kelsey [EMAIL PROTECTED] types: Mike Meyer writes: If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. If you remember v6 and v7, then please enumerate the packages which installed in /opt on those systems. All "packages" I am aware of from the v6/v7 era installed in /usr or in /usr/local, although I am sort of fuzzy on the exact derivation of /usr/local at this point in time. I do recall having a /usr/local on my V6 PDP-11/40, but it could have been contamination leaking over from the 32V system. I do remember the abomination of /usr/ucb which put binaries in /usr/ucb but also included /usr/ucb/lib, etc. I always hated that structure. I know that we made extensive use of /usr/local in 1983 on 4.1bsd, especially in installing software taken from Usenet, so I think that /usr/local really started with extensive use of Usenet distribution, which was coincident with wide-spread use of BSD on VAXen. As far as I remember, I never encountered the use of /opt until Solaris. That's what I remember as well. So what? I'm not advocating that packages install in /opt. I'm claiming that installing them in /usr/local is a mistake. Other distributions that have adopted FreeBSD's package/ports system have benefited from that mistake by avoiding it. Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. Or BSD, for that matter. I never encounterd a package system until Solaris. That would make /opt a tradition as old as packages. Brian Dean [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 10:13:42AM -0600, Mike Meyer wrote: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. You are really reaching here. Contributed software that the FreeBSD Project has chosen to integrate, i.e., Perl, Sendmail, just to name a few, are integrated tightly and installed in /usr/bin, etc, not in /usr/local. Actualy, I'm *responding* to someone who's really reaching. Ports, on the other hand are installed in /usr/local or /usr/X11R6. What happend to "that's what PREFIX is for"? You seem to mis-understand that a FreeBSD port is basically a set of patches and a source fetching mechanism that is included with FreeBSD as a convenience for building and installing third party software. The actual software that gets built and installed is _not_ part of FreeBSD. This is not a rationalization. You didn't read what I wrote. I never claimed that packages or a ports are part of FreeBSD (after all, I do know what they are). I claimed that they are part of the FreeBSD distribution. Or are you going to deny that the ports tree and binary packages are on the installation cdrom? Sure, the software in ports/packages aren't part of FreeBSD. Using that to claim they should have the same status or treatment as locally written or maintained software is a rationalization. I for one would be really upset if when I installed a Port, it's binaries started getting dropped into /bin, /usr/bin, etc. I suspect many others would too. I won't argue - that's pretty clearly a mistake as well. I'm really not exactly sure what you are complaining about. For example, the last time I built Emacs for Solaris (several years ago admittedly), by default it installed itself into /usr/local. If you install Emacs onto FreeBSD, it goes into /usr/local. The behaviour is the same. Are you proposing that since FreeBSD provides a set of patches so that Emacs builds cleanly, that it should therefore install it somewhere other than /usr/local? You seem to mis-understand what a port does. Any port that doesn't provide exactly that set of patches is broken. If I install emacs from the ports tree, the package database will claim that all the files are in /usr/opt. If some files from the port land in /usr/local, then the port is not PREFIX clean, and should be fixed. Basically, I'm complaing that 1) the default PREFIX for ports co-opts part of the file name space that it shouldn't, and 2) PREFIX is given only lip service. Fixing #1 is the best option, because people who think local means local could use precompiled packages from the FreeBSD project and commercial vendors with the same administrative regimen they give all software that isn't locally maintained. Fixing #2 would help, though. 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 Sun, Dec 10, 2000 at 09:37:53AM -0600, Mike Meyer wrote: Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I'm fairly sure that some of the software distributed by SGI on their unsupported free software media does this. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
On Sun, Dec 10, 2000 at 07:16:15PM +0100, Dag-Erling Smorgrav wrote: Forrest Aldrich [EMAIL PROTECTED] writes: Within the scope of this problem, would it not be simple to code in a configuration diretive in the build process, such that a simple entry in /etc/make.conf would tell the ports build where to install ($prefix)? You're about six years late. The ports system has used $PREFIX for precisely this purpose since October 1994. Actually see LOCALBASE, and perhaps X11BASE, which influence PREFIX. This is what you'd want to set in /etc/make.conf. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
Forrest Aldrich [EMAIL PROTECTED] writes: Within the scope of this problem, would it not be simple to code in a configuration diretive in the build process, such that a simple entry in /etc/make.conf would tell the ports build where to install ($prefix)? You're about six years late. The ports system has used $PREFIX for precisely this purpose since October 1994. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Actually, I need to create a local wireless backbone between 8 seperate buildings in a small campus area that will share an sdsl internet connection through our freebsd server. The new intel pro wireless 2100 seems to address all of our issues, at least according to the intel webpage. :-) They also have a 50% off promotional package where you get the access point and two 802.11b pccards for $699.00 if you buy before the end of the year. I tried to use airports to connect two wired networks without success. Maybe I just wasn't able to configure them. I'm going to give the java/airport in ports a try. I didn't realize that it existed. Thanks. If anyone has any ideas on where I am off track, they would certainly be appreciated. Thanks, ed -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
Haha... okay, then what's the argument about. You're about six years late. The ports system has used $PREFIX for precisely this purpose since October 1994. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
In message [EMAIL PROTECTED] Forrest Aldrich writes: : Haha... okay, then what's the argument about. People being too lazy to say PREFIX=/glortz in their /etc/make.conf file. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
Forrest Aldrich [EMAIL PROTECTED] types: Haha... okay, then what's the argument about. You're about six years late. The ports system has used $PREFIX for precisely this purpose since October 1994. As Jacques pointed out, you set LOCALBASE in /etc/make.conf. The problem is that *it doesn't work*. Well, not very well. Part of it is that it's only given lip service: the porters handbook says "make your ports PREFIX clean"; portlint doesn't do any checking about it. The porters handbook doesn't even provide instructions on how to test for whether or not a port is PREFIX clean. Making things LOCALBASE clean isn't even suggested. Admittedly, most port maintainers respond well when I report that things are broken, but checking for this should be done before the port is commited, not afterwards! Lots of other random things break: Packages built with a PREFIX value cannot reliably be installed with another value of PREFIX (no, I don't think that should be a requirement). This means that the prebuilt packages on the CDROM are unusable under these conditions. Since distfiles have been banished from the distribution, the pain of setting PREFIX to anything other than /usr/local for my clients that don't have good network connectivity is higher than the cost of doing intermixing the two different file types. For commercial packages, that's not even an option! The system perl build checks the /usr/local tree for modules, not the LOCALBASE tree. Perls module installation package also installs things in /usr/local, no matter what LOCALBASE is set to. This means that all ports that install PERL modules either 1) aren't PREFIX clean or 2) don't find those modules if they are. The python port breaks the other way: the binary only checks the LOCALBASE heirarchy for modules(*). Locally maintained modules wind up being scattered in among the ports modules, and thus require special treatment. I'm not sure about other ports that support modules, but it wouldn't surprise me if they had similar problems. Ports that have build dependencies on other binaries sometimes assume that the binary in question is on roots path. The startup scripts in /root set the path to include things in the /usr/local heirarchy, *not* the LOCALBASE heirarchy. Thus those builds - while being PREFIX clean - are still broken (not LOCALBASE clean). In fact, all the hook for supporting "local" things are pointed directly at /usr/local; none of them check LOCALBASE. All of these would be solved if the FreeBSD took a lesson from their peers. Most of them could be solved without changing the default value for LOCALBASE - if people wanted them solved. mike *) Python calls them packages; I'm using the Perl terminology to avoid confusion. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
logo_saver in VESA 800x600 mode - syscons kbd freeze
Hi, I've decided to finally start playing with -current a day or five ago. One of the first experiences was a funny syscons keyboard freeze when using a custom kernel with 'options VESA' and the logo_saver kernel module. The symptoms: after the saver relinquishes control, the keyboard is kind of frozen; 'kind of', because the controlling keys still work - Alt+Fx switches consoles, Ctrl-PrtScr escapes to DDB, Alt-arrows also switch consoles. However, any 'real' key typed has no effect - nothing appears on the screen and no action is taken - not on the login prompt, not on the shell cmdline, not within an editor. Even Ctrl-Alt-Del is ignored :( The only way to restart the system is by calling restart or panic inside DDB. Attached is my kernel config (derived from GENERIC), and a backtrace of the panic crashdump. More details, including the crashdump and the kernels (booted and debugging) shall be posted shortly on a website - they are currently being uploaded via a slow modem link, and the vmcore is *huge*, even when bzipped :) The webpage index is already there, so are the debug logs and the kernel images, the vmcore shall take a bit longer to arrive. Details at http://mail.orbitel.bg/~roam/crash/logo_vesa.html The *.2.* files are from a -current source tree as of Dec 10, 16:58 EEST. The *.1.* files are from a source tree as of.. mm.. yesterday, I think; however, I do not think many relevant changes have been made to either syscons or the logo_saver source in the meantime. If I'm doing something much wrongly, feel free to beat me up with the heaviest cluestick around :) G'luck, Peter PS. I do not know anything about the syscons/saver interaction; as a matter of fact, i know next to nothing about syscons itself. So things might take a bit of handholding here :) PPS. Please CC: me, as I'm not on -current (or just honor the Mail-Followup-To header ;) -- This sentence contradicts itself - or rather - well, no, actually it doesn't! # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the NOTES configuration file. If you are # in doubt as to the purpose or necessity of a line, check first in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.292 2000/12/08 20:08:18 phk Exp $ machine i386 #cpuI386_CPU #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident RING-5 maxusers32 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=-g3 #Build kernel with gdb(1) debug symbols options MATH_EMULATE#Support for x87 emulation options INET#InterNETworking #optionsINET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options FFS_ROOT#FFS usable as root device [keep this!] options SOFTUPDATES #Enable FFS soft updates support #optionsMFS #Memory Filesystem #optionsMD_ROOT #MD is a potential root device options NFS #Network Filesystem #optionsNFS_ROOT#NFS usable as root device, NFS required options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem #optionsCD9660_ROOT #CD-ROM usable as root, CD9660 required #optionsDEVFS #Device Filesystem options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options UCONSOLE#Allow users to grab the console options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev # To make an SMP kernel, the next two are needed #optionsSMP
Re: Package installation location
On Sun, Dec 10, 2000 at 01:02:09PM -0600, Mike Meyer wrote: The problem is that *it doesn't work*. Well, not very well. Part of it is that it's only given lip service: the porters handbook says "make your ports PREFIX clean"; portlint doesn't do any checking about it. The porters handbook doesn't even provide instructions on how to test for whether or not a port is PREFIX clean. Making things LOCALBASE clean isn't even suggested. Just to nitpick this one statement, PREFIX is set to LOCALBASE (see /usr/ports/Mk/bsd.port.mk) so if PREFIX is honoured by the port, then LOCALBASE will be honoured by default. Not doing it this way would not allow you to override PREFIX for one particular port. Thus if you set LOCALBASE to /usr/opt in /etc/make.conf for instance, but for port "foo" you want it to go somewhere else, you can build that with make PREFIX=/usr/local/foo, for instance. If foo honoured LOCALBASE instead, it would ignore your one-time PREFIX override. Thus PREFIX is the correct thing for the ports to worry about, not LOCALBASE, LOCALBASE just being the default value for PREFIX. -Brian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp driver not reset after Windows reboot?
Hello I have the self same problem with my nics' Realtek 8139's. But on my '98 machine it is dual bootable with Linux. If I don't power cycle the PC between using windows and Linux my nic's are unusable, gaining a MAC address of as I see yours does. I have found no solution for it (even swearing doesnt help) but since it so similar to your problem and with both Linux and FreeBSD we have been Gate'd again Cliff On Sunday 10 December 2000 13:08, Mark Huizer wrote: Hello, On my VAIO laptop, I have trouble rebooting directly from Windows to FreeBSD (luckily enough I don't run Windows that often :-) I tried to look at the driver code, but it looks to me like it is doing resets when attaching the fxp driver, but somehow, Windows has left it in the state where it isn't recognized properly. Below I have dmesg output, stripped to the fxp0 part. Does anyone have an idea what the problem might be, or where to try to debug this? I have added some comments to the dmesg output, /* here */, to add the programs running there Mark FreeBSD 5.0-CURRENT #0: Wed Dec 6 09:34:39 CET 2000 [EMAIL PROTECTED]:/usr/src2/sys/compile/vaio Preloaded elf kernel "kernel" at 0xc042b000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc042b09c. Preloaded elf module "if_fxp.ko" at 0xc042b0ec. fxp0: Intel Pro 10/100B/100+ Ethernet port 0xfcc0-0xfcff mem 0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps BRIDGE 990810, have 7 interfaces -- index 1 type 6 phy 0 addrl 6 addr ff.ff.ff.ff.ff.ff /* dhclient leads to the below */ fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 /* IPv6 router sollicitation below */ fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 /* various stuff like apache etc below */ fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 fxp0: SCB timeout fxp0: SCB timeout fxp0: device timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: DMA timeout fxp0: SCB timeout fxp0: SCB timeout fxp0: warning: unsupported PHY, type = 63, addr = 255 fxp0: SCB timeout fxp0: SCB timeout fxp0: device timeout fxp0: SCB timeout /* etc etc */ 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: Confusing error messages from shell image activation
On Sun, 10 Dec 2000, Brooks Davis wrote: On Sun, Dec 10, 2000 at 09:37:53AM -0600, Mike Meyer wrote: Interesting. What other OS distribution put things that went into /usr/local on their distribution media? I'm fairly sure that some of the software distributed by SGI on their unsupported free software media does this. Since I'm sitting in front of an SGI answering this email I'll throw in that it's actually put in /usr/freeware. It's quite annoying. I much prefer FreeBSD's /usr/local. My path under IRIX has to include: /usr/bin/X11:/usr/local/bin:/usr/freeware/bin:/usr/gnu/bin:/usr/ucb:/usr/bsd:/usr/etc:/usr/gfx to encompass the various places software installs itself. It's so much nicer under FreeBSD to have one location to worry about third-party binaries showing up. -- 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: Lucent Orinoco Gold PCCard?
Doug Ambrisko writes: BTW I saw ADDTRON http://www.addtron.com/ has a base station for around $220 that can do 128 bit encryption, has an antenna and is Web administered. I haven't used it but it looks interesting. I've started playing with one of these. It seems to have the interesting feature that it stops bridging all traffic after about an hour of operation, requiring a power cycle. Haven't tried upgrading the firmware yet though.. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 11:42:38AM -0600, Mike Meyer wrote: Ports, on the other hand are installed in /usr/local or /usr/X11R6. What happend to "that's what PREFIX is for"? I was speaking about the default behaviour. If you want the port to go somewhere other than /usr/local, PREFIX or LOCALBASE is available to change that. You should be able to set this in /etc/make.conf to change the site behaviour. I think I finally understand what you are complaining about, and that is that PREFIX is not honoured by all ports. If that is your argument, then yes, obviously that should be fixed if possible. But to say that installing ports into /usr/local is somehow wrong, I have to disagree. This is a site dependent decision, which can be overridden through the use of PREFIX or LOCALBASE. If the override mechanism is broken for a port, then it should be fixed. If you wish to change the default from /usr/local to something else, then you need to present good arguments for doing so, and if your arguments are good enough and directed to the right people, it will happen. [/me scurries off in shame to fix my broken port to honour PREFIX.] -Brian 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
Nat Lanza [EMAIL PROTECTED] types: Mike Meyer [EMAIL PROTECTED] writes: Whether or not it's part of FreeBSD is immaterial. It's part of the distribution that comes from FreeBSD, and is treated differentlyh from locally installed software (whether written locally or by a third party) in every case *except* where it installs - and that's only because it's installed in the wrong place. In other words, "It's not part of FreeBSD" is a rationalization. Your argument doesn't make much sense to me. Ok, let's walk through the details (bottom of the letter). So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? It should go where you want it to. /usr/local is a bad place because of it's tradition of being for locally maintained software. If I grab a sawfish FreeBSD package from the sawfish website, where should that install? /usr/local? /opt? /usr/pkg? Not /usr/local - that's for locally maintained software. I'd rather it go on /usr, so I don't like /opt. When I got to choose, I chose /usr/opt. But anything other than /usr/local on /usr would do as well. Third party software is third party software, no matter who compiled and packaged it. That's true. But if it's packaged, it belongs in an area reserved for *packages*. FreeBSD is the only system I know of that coopts /usr/local for packages, instead of reserving it for things that are locally maintained. Whether that locally maintained software is written locally or comes from a third party is irrelevant to this discussion. If I install a package of third-party software, the end result should be about the same as if I compiled and installed it by hand -- the packaged software is a convenience, not a fundamentally different entity. That's correct. The differences aren't in the software, they are in the administrative regimen. Let's look at how you deal with FreeBSD proper, ports/packages, 3rd party software that isn't from a port or package, and locally written software. Administrative FreeBSD port/pkg3rd party local item Binary from FreeBSD FreeBSD author author Source from FreeBSD patches and author author location from FreeBSD Responsible for FreeBSD Portlocal local it building on maintainer maintainer maintainer maint- my FreeBSD box ainer requires local src No No Yes Yes configuration? Updates fromFreeBSD FreeBSD author author Patches best sent FreeBSD Portauthor author to maintainer maintainer As you can see, the only difference between locally written software and third party software is that the author in the latter case is local. Meanwhile, the primary difference between software that is part of FreeBSD and a port/pkg is that the person who takes responsibility for some part of FreeBSD is always a FreeBSD committer, whereas the person who takes that responsibility for a port/package may not be a FreeBSD committer. Sure, sometimes that person for a port is the author - but that's also true for FreeBSD. For 3rd party and local software, you always deal with the author; for FreeBSD and a port or package, you deal with an intermediary that has taken responsibility for the software on FreeBSD, who may *not* be the author. The critical difference is the "requires local src configuration" line. For FreeBSD or any of the ports or packages, I can blow away the source tree without worrying about needing it back; I can always get it back from FreeBSD again. For the same reason, I don't worry much about the binaries. For locally written software, if I lose ths source, I'm SOL. For true third party software, how screwed I am depends on how hard it was getting the thing to build on FreeBSD. As a general rule, I always save them. The binaries get the same treatment. Having to figure out which is which is *much* easier if the two are in different directory hierarchies. Clearly, a package is *not* the same as either third party or locally written software. For people who don't care about any of those differences, packages co-opting /usr/local doesn't matter. For people who do, there's PREFIX - except it doesn't work very well, and can't work for binary builds (and with the CDROM set no longer having distfiles on it, that's a major PITA). mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
I think I finally understand what you are complaining about, and that is that PREFIX is not honoured by all ports. If that is your argument, then yes, obviously that should be fixed if possible. But to say that installing ports into /usr/local is somehow wrong, I have to disagree. This is a site dependent decision, which can be I believe the argument is that *packages* don't belong to /usr/local. And I agree. Ports are easy, because you can use PREFIX and put them wherever you want (if the port is well behaved). But packages are precompiled and there is this thing called package database that keeps track of what file belongs where. The argument is simple: currently, packages install into /usr/local. Local software which is not a package or port also installs into /usr/local. It's a mess because you don't know if a file belongs to a package (and the package system keeps track of it in /var/db/pkg) or if it was locally installed. So, can you remove this file? It's roughly comparable to the situation that would arise if we would install packages into /usr - you wouldn't know if a file belongs to a package or to the base system and you wouldn't know if you can safely remove it. Blaz Zupan, Medinet d.o.o, Linhartova 21, 2000 Maribor, Slovenia E-mail: [EMAIL PROTECTED], Tel: +386-2-320-6320, Fax: +386-2-320-6325 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Mike Meyer writes: Sure, the software in ports/packages aren't part of FreeBSD. Using that to claim they should have the same status or treatment as locally written or maintained software is a rationalization. You are simply wrong in your characterization of /usr/local. As far back as I can remember, /usr/local has been used for locally installed software as separate from the default software in /bin and /usr/bin. I have personally use /usr/local to install software obtained from Usenet since at least 1983. I estimate that 90% of my /usr/local use has been for software obtained over some network distribution mechanism, and only 10% has been for actually locally written software. When the BSD started, they tried to distinguish between /usr/local and /usr/public, but that never took hold. Certainly, when GNU distributions started, the FSF very quickly took up the then default (from the long history of standardized distributions in the moderated unix source newsgroups, both before and after the great renaming) usage of /usr/local as the place for network distributed software packages. Certainly, when I think of packages, I think first of the Usenet tradition of shar-packaging. Only when the great UNIX wars started did vendors need to come up with their own binary packaging mechanisms. Each vendor supplied their own packaging commands, as SunOS did long before Solaris (really SYSVR4). The correspondence between ports and packages in FreeBSD is really quite separate from the distribution packages. Simply because a package exists does not make it part of the distribution. At least FreeBSD uses a different nomenclature for each, unlike Red Hat which calls everything an RPM and you can't tell the difference between what Red Hat officially includes in the system and what is simply a pre-compiled port. Definition: distribution: officially part of FreeBSD. port: A set of patches, source and makefiles to ease the process of installing third part software. package: A pre-compiled port. I don't have any problem seeing the distinction between a port/package and the official FreeBSD distributions. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Making {open,close,read,tell,seek}dir thread-safe.
On Mon, 04 Dec 2000 16:11:39 -0500, Dan Eischen [EMAIL PROTECTED] said: I started a cleanup of libc to make it thread-safe. Just as a matter of information The seekdir/telldir interface was debated recently by the Austin Group. The Open Group wanted to include it as part of the XSI extension to 1003.1-200x; other people were strongly opposed to its inclusion. I believe the final decision was that it seekdir/telldir would not be included, because it is impossible to implement over certain filesystems (e.g., SGI's XFS, which uses a radically different data structure for directories). -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 11:14:32AM -0800, Joe Kelsey wrote: You are simply wrong in your characterization of /usr/local. As far back as I can remember, /usr/local has been used for locally installed [...] Pfft. Everyone has their own way of organizing files. There is no right or wrong. However, the fact that /usr/local is still hardcoded into packages IS a bug. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
Brian Dean [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 01:02:09PM -0600, Mike Meyer wrote: The problem is that *it doesn't work*. Well, not very well. Part of it is that it's only given lip service: the porters handbook says "make your ports PREFIX clean"; portlint doesn't do any checking about it. The porters handbook doesn't even provide instructions on how to test for whether or not a port is PREFIX clean. Making things LOCALBASE clean isn't even suggested. Just to nitpick this one statement, PREFIX is set to LOCALBASE (see /usr/ports/Mk/bsd.port.mk) so if PREFIX is honoured by the port, then LOCALBASE will be honoured by default. Not doing it this way would not allow you to override PREFIX for one particular port. Thus if you set LOCALBASE to /usr/opt in /etc/make.conf for instance, but for port "foo" you want it to go somewhere else, you can build that with make PREFIX=/usr/local/foo, for instance. If foo honoured LOCALBASE instead, it would ignore your one-time PREFIX override. Thus PREFIX is the correct thing for the ports to worry about, not LOCALBASE, LOCALBASE just being the default value for PREFIX. My bad - I coined the phrase "LOCALBASE clean" to describe a situation I've seen, without explaining the meaning. Wherease "PREFIX clean" means "all installed files are in the PREFIX tree", I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". The porters handbook explains this, but doesn't even mention that it's something that could break your ports build if you don't obey it. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Package installation location
On Sun, Dec 10, 2000 at 02:18:51PM -0500, Brian Dean wrote: LOCALBASE just being the default value for PREFIX. Not just. It is also where dependancies are looked for. -- -- 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
/usr/local abuse
Joe Kelsey writes: When the BSD started, they tried to distinguish between /usr/local and /usr/public, but that never took hold. Certainly, when GNU distributions started, the FSF very quickly took up the then default (from the long history of standardized distributions in the moderated unix source newsgroups, both before and after the great renaming) usage of /usr/local as the place for network distributed software packages. Just as a clarification of the history of the file system hierarchy. BSD started the habit of putting stuff in different directories. 4.2 included /usr/ucb, /usr/local and /usr/public. /usr/public never really caught on as a place to put officially, locally supported software because the default permissions as shipped from Berkeley was 777. Berkeley used it as a catch-all for anything anyone wanted to make available for public consumption (this was an extension of the /usr/pub directory in V6/V7). Because of the default permissions and the problems associated with keeping it safe locally, /usr/public eventually fell out of use. Basically, /usr/local is for anything the local administration wants to officially support. The ports use of this (and by extension, pre-compiled ports (packages)) is thus completely justified. /Joe 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 Sun, Dec 10, 2000 at 12:12:59PM -0500, Nat Lanza wrote: Your argument doesn't make much sense to me. It make total sense to me. So if I compile sawfish myself I should install it in /usr/local, but if I install a FreeBSD package for it, it should never go in /usr/local? Correct. Third party software is third party software, no matter who compiled and packaged it. No, the issue is one of "preciousness". In other words why backup software that I can just do `pkg_add' to get again? Or if I want to easily start from scratch and update all my FreeBSD Packages? ``rm -rf /usr/pkg'' followed by a bunch of ``pkg_add -r'' is way easy. Similarly to me not backing up /usr on a FreeBSD machine. Why bother as I have a Live-FS cdrom I can get a copy from. Nor many people backup the /home/ncvs directory (see PHK's message about this also in -current) as a simple CVSup will get you a new copy. Now scripts I wrote and software I went to the trouble to download, hacke the Makefiles to DRTR, etc.. have a *LOT* more effort put into getting them working. Thus they are more precious and are treated more dearly. Maybe even backed up. ;-) Thus there _are_ three classes of software in FreeBSD'ville. 1. lives in /usr/src and installed by `make world' 2. lives in /usr/ports and installed by `make install' or `pkg_add'. 3. locally written or obtained -- -- 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 abuse
On Sun, Dec 10, 2000 at 01:44:41PM -0500, Brian Dean wrote: I think I finally understand what you are complaining about, Maybe. But to say that installing ports into /usr/local is somehow wrong, I have to disagree. Do you understand why NetBSD Packages (ie, the system they took from us) install into /usr/pkg by default rather than /usr/local ? -- -- 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: Package installation location
On Sun, Dec 10, 2000 at 01:42:15PM -0600, Mike Meyer wrote: My bad - I coined the phrase "LOCALBASE clean" to describe a situation I've seen, without explaining the meaning. You're mudding up things. You want to set LOCALBASE to /usr/foo and ports should be "PREFIX" clean as that is what is passed to them. LOCALBASE is used as the default value for PREFIX _AND_ the location for dependencies. Thus when testing a port that depends on tk, I can do make PREFIX=/tmp/foo package And not have to install Tcl/Tk in /tmp/foo also. Thus it is easier to auto-generate PLISTs. Wherease "PREFIX clean" means "all installed files are in the PREFIX tree", Correct. I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". If all ports are PREFIX clean, you will have that. Thus it doens't need to be discussed separately. -- -- 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 09:40:31PM -0600, Mike Meyer wrote: I always thought ``make PREFIX=/tmp/foo package'' is pretty obvious.. but ... What does the above command do if the port isn't PREFIX clean? Installs the ports's bits into [most likely] /usr/local, cause an error while trying to build the package, and create a situation where `pkg_delete' could not be used to delete the installed bits. 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. Just a different flavor of catching the errors. "make PREFIX=/tmp/foo package" will also complain if it cannot find the binaries to tar up in PREFIX. -- -- 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 abuse
Joe Kelsey [EMAIL PROTECTED] types: Mike Meyer writes: Sure, the software in ports/packages aren't part of FreeBSD. Using that to claim they should have the same status or treatment as locally written or maintained software is a rationalization. You are simply wrong in your characterization of /usr/local. As far back as I can remember, /usr/local has been used for locally installed software as separate from the default software in /bin and /usr/bin. I have personally use /usr/local to install software obtained from Usenet since at least 1983. I estimate that 90% of my /usr/local use has been for software obtained over some network distribution mechanism, and only 10% has been for actually locally written software. Actually, my characterization of /usr/local agrees with that 100%. What you've missed is that the important characteristic of ports/packages isn't that they are "software obtained over some network distribution mechanism." After all, the entire FreeBSD distribution fits that category. Are you therefore going to argue that it should all be installed in /usr/local because I get it from a CVS server? Each vendor supplied their own packaging commands, as SunOS did long before Solaris (really SYSVR4). The correspondence between ports and packages in FreeBSD is really quite separate from the distribution packages. Simply because a package exists does not make it part of the distribution. At least FreeBSD uses a different nomenclature for each, unlike Red Hat which calls everything an RPM and you can't tell the difference between what Red Hat officially includes in the system and what is simply a pre-compiled port. True - mere existence doesn't make a package part of a distribution. Being put on the distribution media makes it part of a distrbution. However, as shown above, the distribution mechanism is *irrelevant* to this debate. Definition: distribution: officially part of FreeBSD. I don't agree. A distribution is a software collection bundled and distributed together. port: A set of patches, source and makefiles to ease the process of installing third part software. Yes, and the ports are part of the FreeBSD distribution, even if they aren't part of FreeBSD. package: A pre-compiled port. Yup. Some some packages are part of the FreeBSD distribution (again, without being part of FreeBSD), and some aren't. I don't have any problem seeing the distinction between a port/package and the official FreeBSD distributions. Neither do I. Nor do I have any problem seeing that it's *irrelevant* to the issue at hand. Using the fact that something distributed with FreeBSD is a port instead of "officially part of FreeBSD" is just a rationalization for the system defaulting to a behavior that creates administration problems and increases the overhead of running a system. Joe Kelsey writes: When the BSD started, they tried to distinguish between /usr/local and /usr/public, but that never took hold. Certainly, when GNU distributions started, the FSF very quickly took up the then default (from the long history of standardized distributions in the moderated unix source newsgroups, both before and after the great renaming) usage of /usr/local as the place for network distributed software packages. Basically, /usr/local is for anything the local administration wants to officially support. The ports use of this (and by extension, pre-compiled ports (packages)) is thus completely justified. Are you therefore claiming that the "official FreeBSD" distribution is not officially supported by the local administration? Seems a strange position to take for someone who wants to run FreeBSD. Of course, anyone who actually deals with users knows that they assume anything installed on the system is officially supported by the local administration - even if there are explicit statements otherwise. The issue isn't support, the issue is maintenance. Anything you get from FreeBSD - whether officially part of FreeBSD or just a port or package - will work on FreeBSD as is (failure to do so is a bug), can be gotten from FreeBSD again, and there are tools bundled with FreeBSD to detect updates (which come from FreeBSD), install and uninstall the software. None of that is true for third party software, meaning you need locally grown mechanisms to back up, install, uninstall, etc. such software. It's a *lot* easier to do that if the two classes of software are in two different trees. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp driver not reset after Windows reboot?
On my VAIO laptop, I have trouble rebooting directly from Windows to FreeBSD (luckily enough I don't run Windows that often :-) I tried to look at the driver code, but it looks to me like it is doing resets when attaching the fxp driver, but somehow, Windows has left it in the state where it isn't recognized properly. Below I have dmesg output, stripped to the fxp0 part. Does anyone have an idea what the problem might be, or where to try to debug this? I have added some comments to the dmesg output, /* here */, to add the programs running there Mark FreeBSD 5.0-CURRENT #0: Wed Dec 6 09:34:39 CET 2000 [EMAIL PROTECTED]:/usr/src2/sys/compile/vaio Preloaded elf kernel "kernel" at 0xc042b000. Preloaded userconfig_script "/boot/kernel.conf" at 0xc042b09c. Preloaded elf module "if_fxp.ko" at 0xc042b0ec. fxp0: Intel Pro 10/100B/100+ Ethernet port 0xfcc0-0xfcff mem 0xfed0-0xfedf,0xfecff000-0xfecf irq 9 at device 11.0 on pci0 fxp0: Ethernet address ff:ff:ff:ff:ff:ff, 10Mbps BRIDGE 990810, have 7 interfaces -- index 1 type 6 phy 0 addrl 6 addr ff.ff.ff.ff.ff.ff /* dhclient leads to the below */ fxp0: SCB timeout Based on the above, I would say that Windows has powered-down the NIC. This is outside of the scope of the driver, so I don't think a solution should be implemented there. Probably something for our APM folks. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - http://www.terasolutions.com Pave the road of life with opportunities. 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 Sun, Dec 10, 2000 at 01:18:51PM -0500, Brandon D. Valentine wrote: My path under IRIX has to include: /usr/bin/X11:/usr/local/bin:/usr/freeware/bin:/usr/gnu/bin:/usr/ucb:/usr/bsd:/usr/etc:/usr/gfx That is so bad considering the power it gives you? It only takes 2-3 lines in your dot files to check each dir and add it to your PATH if it exists. For instance on Solaris boxes I install GNU bits into /usr/gnu. Why? Because it gives you better control over what binaries you run -- remember GNU *utils replaces the systems native ones (ie, cp, rm, as, shar, etc...). Thus one can put /usr/local/bin:/usr/bin:/usr/gnu/bin as their path and have any wrapper scripts take precedence over system bits, but use the native system bits over the GNU ones if you are a traditionalist. This control is part of why it would be nice to have /usr/pkg separate from /usr/local. I've given up on FreeBSD and had to create my own /usr/treats to hold what should have been in /usr/local if the FreeBSD Packages hadn't polluted it. -- -- 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: Confusing error messages from shell image activation
David O'Brien [EMAIL PROTECTED] types: This control is part of why it would be nice to have /usr/pkg separate from /usr/local. I've given up on FreeBSD and had to create my own /usr/treats to hold what should have been in /usr/local if the FreeBSD Packages hadn't polluted it. I went the other way, because "that's what PREFIX is for". I figured there would be less pain involved in moving a system designed to be moved than in moving random software that may or may not be so designed. After having done so for a while, it's not at all clear that was a correct decision. That this is the case says a lot about the implementation of that design, none of it good. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
David O'Brien writes: On Sun, Dec 10, 2000 at 11:22:17AM -0800, Joe Kelsey wrote: Basically, /usr/local is for anything the local administration wants to officially support. The ports use of this (and by extension, pre-compiled ports (packages)) is thus completely justified. Do you understandy why NetBSD's Packages install in /usr/pkg ? What is your position behind that? I have no problem with /usr/pkg. I personally do not see the need for it. I have been arguing with Mike over his historic characterization of /usr/local as being a repository of locally written software, and I think I have proved my point that his characterization is incorrect. This thread is also about a completely separate issue, which is a deficiency in the package command used on FreeBSD. The basic problem with pkg_add et al., as opposed to, for instance, SVR4 pkgadd, is that it does not allow the local administrator to change the installation directory. Most commercial distributions provide a package distribution mechanism which allows the local administrator the choice between the "standard" package installation location, and the ability to override it with a directory of their own choosing. Arguably, the pkg_* commands of FreeBSD are deficient in that they force an installation directory choice on the local administrator. To the extent that NetBSD *forces* the local administrator to use /usr/pkg, I find it contains the same deficiency. If it does not force this, then perhaps FreeBSD should adopt it. I have never used NetBSD, so I cannot comment further on it. My argument is solely that Mike is incorrect in characterizing /usr/local as a place for locally written software. I also find that his table is incorrect historically. The table he presented conveys his *wish* for administrative purposes and his attempts to justify it by some sort of historical argument do not hold water. He is correct in that it does make sense for a local administrator to *want* to be able to separate packages by the need to maintain source, etc. I can agree with him on that point. He is just wrong about the history of the evolution of the file system hierarchy. /Joe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
Joe Kelsey [EMAIL PROTECTED] types: David O'Brien writes: On Sun, Dec 10, 2000 at 11:22:17AM -0800, Joe Kelsey wrote: Basically, /usr/local is for anything the local administration wants to officially support. The ports use of this (and by extension, pre-compiled ports (packages)) is thus completely justified. Do you understandy why NetBSD's Packages install in /usr/pkg ? What is your position behind that? I have no problem with /usr/pkg. I personally do not see the need for it. I have been arguing with Mike over his historic characterization of /usr/local as being a repository of locally written software, and I think I have proved my point that his characterization is incorrect. I think I've proved that you completely misunderstood my characterization of /usr/local. I also think that I proved Brandon's characterization of using /usr/local for packages as "steeped in decades of tradition" as false. My argument is solely that Mike is incorrect in characterizing /usr/local as a place for locally written software. I also find that his table is incorrect historically. The table he presented conveys his *wish* for administrative purposes and his attempts to justify it by some sort of historical argument do not hold water. I don't think I ever claimed that it was solely for locally *written* software. I claimed it was for locally *maintained* software. There's a difference. I don't know where you got the idea that the table had any kind of historic representation. Nothing in it represents *history*. It describes the world as it is now. If you feel that something in it is incorrect, please say what it is instead of making vague statements about the entire table. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
PREFIX clean vs. LOCALBASE clean (Was: Package installation location)
David O'Brien [EMAIL PROTECTED] types: Wherease "PREFIX clean" means "all installed files are in the PREFIX tree", Correct. I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". If all ports are PREFIX clean, you will have that. Thus it doens't need to be discussed separately. Using the two definitions above, the first sentence is false. In particular, assume that the port APort depends on BPort in some way, and is PREFIX clean. That means that everything in APort is installed in PREFIX, and all APorts references to things in APort look for them there. Neither of those statements precludes APort from looking for things that are part of BPort directly in /usr/local instead of in LOCALBASE. Doing so would make APort PREFIX clean while it was not LOCALBASE clean. I've only seen this break during the build. Most typical is the applications configuration software looking in /usr/local for an include file or library from BPort instead of looking in LOCALBASE. Some things assume that $(LOCALBASE)/bin is in the path, which is probably true for most users. However, the scripts provided by FreeBSD in /root add /usr/local/bin, *not* $(LOCALBASE)/bin. So such runtime dependencies don't break for users, but do for root - which means they are more likely to be noticed if they are build dependencies than if they are run dependencies. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: using mtree in our builds [was: Re: Bootstrapping issues with groff(1)]
David O'Brien wrote: On Sat, Dec 09, 2000 at 07:59:46PM -0800, Marcel Moolenaar wrote: 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. But they're harmless. While I agree it is clutter, having to duplicate its work in the Makefile's with lists of dirs to create just seems like a duplication and waste of effort; If the list is short (as it is now), there's no real problem, but if there's a real bootstrapping issue with groff(1) and we need to add 10+ directories, then it will become a more serious issue and I think that a better solution is called for in that case. and even an little NIH as mtree is rather ingrained in BSD. NIH has nothing to do with it. To me it seems that mtree(1) is designed for a different purpose. Yes, it so happens that mtree can create directories, but that's not the root purpose of the tool. And yet, that's the only reason we'll use mtree(1) in the build (at all?). Adding features to mtree to have it better function in our builds only adds to the bootstrapping overhead, and all we really want to reuse is the directory structure information in our BSD.*.dist files. If the effort to write a small script is of the same order as patching mtree, then I prefer the small script... -- 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
AGP currently broken
Hello, It seems the latest update to AGP breaks it. I get link_elf: symbol M_AGP undefined when trying to load it as a module, and a similar message when I try to build it into the kernel during the link. The problem seems to be the change to static MALLOC_DEFINE(M_AGP, "agp", "AGP data structures"); from MALLOC_DEFINE(M_AGP, "agp", "AGP data structures"); in the latest pci/agp.c. CC me as I'm not on the list. (I know, but I can't cope well with that type of mail volume...) Justin A. Kolodziej To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Bootstrapping issues with groff(1)
Marcel Moolenaar [EMAIL PROTECTED] writes: According to the manpage, if you remove -U it doesn't create new directories or symlinks. At least that's how I interpret it. You interpret it wrong. -U just tells mtree to fix permissions. The canonical way to use the mtree files in /etc/mtree is 'mtree -deU -f file -p path', e.g. 'mtree -deU -f /etc/mtree/BSD.root.dist -p /'. DES -- Dag-Erling Smorgrav - [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
I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. : 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. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. On V7 (the earliest software I have), vendor software installed itself in /usr/[bin|lib], which is IMO worse than /usr/local. Nate 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
"David O'Brien" [EMAIL PROTECTED] writes: No, the issue is one of "preciousness". In other words why backup software that I can just do `pkg_add' to get again? Or if I want to easily start from scratch and update all my FreeBSD Packages? This is an entirely reasonable argument; I don't tend to group software this way, so I hadn't thought of it like this. This is probably because in my world, we use a somewhat different model for software installation -- CMU is heavily dependent on AFS, and software tends to be installed on local machines out of backed-up AFS volumes through something like depot. So every package has its own little directory tree, and it's all merged together at install time into /usr/local or /usr/contributed or something like that. So we don't differentiate how precious software is by where it's installed -- the directories it's installed _from_ are the key bit, and the destination directories can be wiped and recreated at any time. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( Or BSD, for that matter. I never encounterd a package system until Solaris. That would make /opt a tradition as old as packages. Not true. There were package systems before 'Solaris', however Solaris's package utility was much more powerful (annoying?) than previous attempts. One could argue that cpio is a 'package' utility, but shar is probably the first 'package' utility that was used for releases. In any case, I think you're wasting your time trying to convince folks here. It appears to me that this is an argument going nowhere, and the claims you're making of history and tradition are way off the mark, thus making the arguments have much less weight. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: logo_saver in VESA 800x600 mode - syscons kbd freeze
Peter Pentchev [EMAIL PROTECTED] writes: I've decided to finally start playing with -current a day or five ago. One of the first experiences was a funny syscons keyboard freeze when using a custom kernel with 'options VESA' and the logo_saver kernel module. Known bug. Please search the archives, this was discussed earlier this week. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PREFIX clean vs. LOCALBASE clean (Was: Package installation location)
On Sun, Dec 10, 2000 at 02:19:12PM -0600, Mike Meyer wrote: I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". If all ports are PREFIX clean, you will have that. Thus it doens't need to be discussed separately. Using the two definitions above, the first sentence is false. How is it false? In particular, assume that the port APort depends on BPort in some way, and is PREFIX clean. Which is PREFIX clean? Aport or Bport? (it is often good to not use pronouns in technical disucssions...) That means that everything in APort is installed in PREFIX, and all APorts references to things in APort look for them there. Which is correct if Aport is PREFIX-clean. Neither of those statements precludes APort from looking for things that are part of BPort directly in /usr/local instead of in LOCALBASE. Yes it does if Aport is PREFIX-clean. s./usr/local.PREFIX.g and would be a better way to say it, adding PREFIX != LOCALBASE. Doing so would make APort PREFIX clean while it was not LOCALBASE clean. True. -- -- 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 abuse
On Sun, Dec 10, 2000 at 12:26:38PM -0800, Joe Kelsey wrote: This thread is also about a completely separate issue, which is a deficiency in the package command used on FreeBSD. The basic problem with pkg_add et al., as opposed to, for instance, SVR4 pkgadd, is that it does not allow the local administrator to change the installation directory. pkg_add *does* allow the installer to choose the installation directory -- the "-p" option. The issue is one of *compiled* in paths. So if Satoshi builds port foobar (which as a config file etc/foobar.conf) then the foobar binary has "/usr/local/etc" burned into it because that is what Satoshi had PREFIX set to. To the extent that NetBSD *forces* the local administrator to use /usr/pkg, I find it contains the same deficiency. Nope. One can ``ln -s /usr/local /usr/pkg'' and get the behavior those that like everything in one place prefers while still segregating stuff for those that prefer it. -- -- 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: Confusing error messages from shell image activation
In message [EMAIL PROTECTED] Nate Williams writes: : I'm aware that software was installing itself in /usr/local years : before it was installing in /opt. On the other hand, vendor software : was installing in /opt years before I ever saw it install in : /usr/local. : : Most vendor software I know pre-dates /opt, and installed itself in : /usr/local. I'm with Warner on this one, installing in /usr/local : predates /opt by many years. Before /opt, vendors always used : /usr/local, or worse they installed in /bin and /usr/bin. Yes. 4.1BSD, I think, used /usr/ucb for the hacks that ucb had done to the system. I had it in my path for years and have been considering removing it, but solaris still uses it :-( (I have an array of candidate paths for my path and only insert the ones that exist from my .cshrc file). System III with ucb hacks also had them in /usr/ucb. I forget which System that the 3b2s ran (I think it was System V r1 before there was an r2), but they had the ucb hacs in /usr/ucb. I think that software packages built from sources installed themselves into /usr/local, but it has only been about 11 years since I last logged into a 3b2 at Wollongong so I can't easily go back and check. :-) Sadly, I didn't start keeping my .cshrc files under cvs control until 1993 so I can't easily check its evolution before then. I lost that CVS repo in a disk crash while not a practicing member of the church of the daily backup sometime in 1999, so I don't have a complete history between 1993 and 1999 (backup tapes have it up to sometime in 1998, but I didn't find those until after I started a new repo). : If memory serves (and it may not at this remove), /usr/local/bin : wasn't on my path until I started using VAXen, meaning there were few : or no packages installing in /usr/local on v6 v7 on the 11s. : : On V7 (the earliest software I have), vendor software installed itself : in /usr/[bin|lib], which is IMO worse than /usr/local. Agreed. The 4.2BSD and 4.3BSD VAXen that we had at New Mexico Tech in late 1985 didn't have a /opt, but did have a /usr/local which is where software installed itself. We were at a university, and I think we had local hacks to include /usr/local/bin and /usr/ucb/bin in the paths for these machines. As they were VAX 11/750s, we had no X software since this machine predated the availibility of Sun 3/50 workstations at New Mexico Tech, which didn't arrive until late 1986 and weren't online until early 1987. They didn't run X11 until late 1987 or early 1988 iirc. And then X11's installation dir wasn't well standardized. Some software installed in /usr/X11/bin and others installed in /usr/bin/X11. Gosling Emacs was installed in /usr/local/bin/emacs for sure. I don't have my historic Unix version CD handy, or I'd check the man pages from 4.xBSD to check, but version 1.1 of the hier(7) from 1994 says: /usr/ ... local/local executables, libraries, etc. ... but there also was a /usr/contrib for large packages contribtued to Berkeley by outside parties. /usr/contrib was, I think, invented for 4.4BSD, but maybe it was for 4.3BSD. Without the sccs trees handy, I have no way of knowing the exact details. Looking at NetBSD's hier from the same time frame (actually 1 year earlier in 1993) shows the same text. The page itself is dated 1991. NetBSD's /usr/pkg didn't get documented until 1998/04/02 according to the cvs log and that was something that they invented at the time because they didn't like FreeBSD's ports going into /usr/local. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 01:51:25PM -0800, David O'Brien wrote: On Sun, Dec 10, 2000 at 12:26:38PM -0800, Joe Kelsey wrote: [snip] To the extent that NetBSD *forces* the local administrator to use /usr/pkg, I find it contains the same deficiency. Nope. One can ``ln -s /usr/local /usr/pkg'' and get the behavior those that like everything in one place prefers while still segregating stuff for those that prefer it. That makes no sense. The big argument has been that packages should not go into /usr/local because /usr/local is for something else. If you symlink do the symlink trick, you only have one real location for files. If you were to do that, /usr/local or /usr/pkg would be identical. Might as well make /usr/local the "real" location and symlink /usr/pkg. What's the difference? -- Crist J. Clark [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 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 :... When you created the filesystems on which the history and spool reside, did you use any custom parameters for blocksize, fragsize, etc...? P.S. you should not publish paths to kernel dumps on the lists... send that over private email. Dumps might contain sensitive data such as passwords. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Is there a list of wireless pc cards that work (and how well they work) with FreeBSD?? JRS To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
Crist J. Clark [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 01:51:25PM -0800, David O'Brien wrote: On Sun, Dec 10, 2000 at 12:26:38PM -0800, Joe Kelsey wrote: To the extent that NetBSD *forces* the local administrator to use /usr/pkg, I find it contains the same deficiency. Nope. One can ``ln -s /usr/local /usr/pkg'' and get the behavior those that like everything in one place prefers while still segregating stuff for those that prefer it. That makes no sense. The big argument has been that packages should not go into /usr/local because /usr/local is for something else. If you symlink do the symlink trick, you only have one real location for files. If you were to do that, /usr/local or /usr/pkg would be identical. Might as well make /usr/local the "real" location and symlink /usr/pkg. What's the difference? The difference is the cases aren't symmetric. If you want the two merged, then it doesn't matter what the system calls it, you can symlink your preferred name to theirs (or vice versa) and you're done. If you want the two split, the system name becomes something you *can't* use for your local packages, period. Which is why FreeBSD choosing a name that has a historical usage is bad. If someone feels that packages aren't appropriate for that historical usage and wants to use other software that wants that usage, they're screwed. PREFIX lets people feel smug about being able to move it, but as far as I was able to determine when I asked, no one with the commit bit actually runs systems using PREFIX that way. Providing an untested "solution" isn't a good thing. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/dev/pci isa_pci.c
On Sun, Dec 10, 2000 at 03:15:19AM -0800, Mike Smith wrote: msmith 2000/12/10 03:15:19 PST Modified files: sys/dev/pci isa_pci.c Log: The ICH2 reports itself as a PCI:ISA bridge, so don't special-case it here. On a related(?) note, my 810 (ICH) hasn't seen pci devices for a few days. By removing the ICH line from isa_pci.c, the warnings go away, but nothing is seen. Full dmesg's can be found at: http://www.fxp.org/~jedgar/FreeBSD/ICH/ --- dmesg.beforeSun Dec 10 17:46:54 2000 +++ dmesg.after Sun Dec 10 17:48:23 2000 @@ -1,18 +1,17 @@ Copyright (c) 1992-2000 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. -FreeBSD 5.0-20001203-CURRENT #0: Sun Dec 3 08:04:02 GMT 2000 -[EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC +FreeBSD 5.0-CURRENT #5: Sun Dec 10 17:45:49 EST 2000 +[EMAIL PROTECTED]:/usr/src/sys/compile/ARTEMIS Timecounter "i8254" frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (598.19-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 65994752 (64448K bytes) -avail memory = 59174912 (57788K bytes) -Preloaded elf kernel "kernel" at 0xc04f6000. +avail memory = 59691008 (58292K bytes) +Preloaded elf kernel "kernel" at 0xc0477000. Pentium Pro MTRR support enabled md0: Malloc disk -WARNING: Driver mistake: destroy_dev on 154/0 Using $PIR table, 8 entries at 0xc00fdf40 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 @@ -20,14 +19,14 @@ npx0: INT 16 interface pcib0: Intel 82810 (i810 GMCH) Host To Hub bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 -pci0: Intel 82810 (i810 GMCH) SVGA controller at 1.0 irq 10 -pcib1: Intel 82801AA (ICH) Hub to PCI bridge at device 30.0 on pci0 +vga_pci0: VGA-compatible display device mem +0xf400-0xf407,0xf800-0xfbff irq 10 at device 1.0 on pci0 +pcib1: PCI-PCI bridge at device 30.0 on pci0 pci1: PCI bus on pcib1 -pci1: unknown card (vendor=0x1013, dev=0x6005) at 9.0 irq 11 -pci1: unknown card (vendor=0x131f, dev=0x2030) at 13.0 irq 9 -fxp0: Intel Pro 10/100B/100+ Ethernet port 0x3000-0x301f mem 0xf420-0xf42f,0xf430-0xf4300fff irq 10 at device 14.0 on pci1 -fxp0: Ethernet address 00:90:27:3a:1c:89 -isab0: Intel 82801AA (ICH) PCI to LPC bridge at device 31.0 on pci0 +** REDUNDANT ISA BRIDGE MATCH FOR DEVICE 0x24108086 +** Please report to [EMAIL PROTECTED] +** REDUNDANT ISA BRIDGE MATCH FOR DEVICE 0x24108086 +** Please report to [EMAIL PROTECTED] +isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH ATA66 controller port 0x1800-0x180f at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 @@ -37,7 +36,9 @@ usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered -pci0: unknown card (vendor=0x8086, dev=0x2413) at 31.3 irq 9 +ichsmb0: Intel 82801AA (ICH) SMBus controller port 0x1810-0x181f irq 9 at device +31.3 on pci0 +smbus0: System Management Bus on ichsmb0 +smb0: SMBus general purpose I/O on smbus0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 @@ -63,6 +64,7 @@ unknown: PNP0501 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0401 can't assign resources +IP Filter: v3.4.13 initialized. Default = pass all, Logging = enabled ad0: 14598MB SAMSUNG SV1533D [29660/16/63] at ata0-master UDMA66 acd0: CDROM SAMSUNG CD-ROM SC-140 at ata1-master using PIO4 Mounting root from ufs:/dev/ad0s2a -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org 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] "[EMAIL PROTECTED]" writes: : Is there a list of wireless pc cards that work (and how well they work) : with FreeBSD?? There's /etc/defaults/pccard.conf, which says breifly: Aironet 340/342 Series 11Mbps 802.11 wireless NIC Aironet PC4500 2Mbps 802.11 wireless NIC Aironet PC4800 11Mbps 802.11 wireless NIC Bay Networks BayStack 650 Wireless LAN Cabletron RoamAbout, WaveLAN/IEEE clone Compaq WL100 Corega KK Wireless LAN PCC-11 ELECOM Air@Hawk/LD-WL11/PCC (0.7.5) ELECOM Air@Hawk/LD-WL11/PCC (0.7.6 and later) Farallon SkyLINE Wireless Farallon Skyline 11Mbps Wireless Generic AMD Am79c930 based card ICOM SL-1100 ICom SL-200 Lucent WaveLAN/IEEE Melco Airconnect Melco WLI-PCM NCR WaveLAN/IEEE NEC Wireless Card CMZ-RT-WP PLANEX GeoWave/GW-NS110 TDK LAK-CD011WL WebGEAR Aviator 2.4 (ray driver, not 802.11b) Xircom CreditCard Netwave (cwn to be committed soon) ZoomAir-4000 Warner P.S. I'd like to have one of each of these. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Sony jog dial driver
Attached is a preliminary driver for the Sony jog dial. It's enough that
you can create a /dev/jogdial and watch letters come out.
It needs a lot of improvement:
1. Use interrupts instead of polling.
2. Present mouse-oriented events instead of letters.
3. Fix the probe routine so that it tries to detect the presence of the
device rather than the magic 0x10a0 port location.
4. Eventual ACPIification of the driver.
5. Create a 2nd device to deal with other devices like the lid switch,
capture button, etc.
But I wanted to get this much out there for people to play with.
/*
* Insert standard FreeBSD Copyright notice here
*
* spic -- the Sony Programmable I/O Controller
*
* This device exists on most recent Sony laptops. It is the means by which
* you can watch the Jog Dial and some other functions.
*
* At the moment, this driver merely tries to turn the jog dial into a
* device that moused can park on, with the intent of supplying a Z axis
* and mouse button out of the jog dial. I suspect that this device will
* end up having to support at least 2 different minor devices: One to be
* the jog wheel device for moused to camp out on and the other to perform
* all of the other miscelaneous functions of this device. But for now,
* the jog wheel is all you get.
*
* What documentation exists is thanks to Andrew Tridge, and his page at
* http://samba.org/picturebook/
*
* $FreeBSD$
*/
#include sys/param.h
#include sys/systm.h
#include sys/kernel.h
#include sys/bus.h
#include machine/bus.h
#include sys/rman.h
#include machine/resource.h
#include isa/isavar.h
#include sys/poll.h
#include machine/pci_cfgreg.h
#include machine/clock.h
#include sys/tty.h
#include sys/conf.h
#include sys/fcntl.h
#include sys/dkstat.h
#include sys/malloc.h
#include sys/sysctl.h
#include sys/uio.h
#include dev/spic/spicreg.h
static int spic_pollrate;
SYSCTL_INT(_machdep, OID_AUTO, spic_pollrate, CTLFLAG_RW, spic_pollrate, 0, "")
;
devclass_t spic_devclass;
static d_open_t spicopen;
static d_close_tspicclose;
static d_read_t spicread;
static d_ioctl_tspicioctl;
static d_poll_t spicpoll;
static struct cdevsw spic_cdevsw = {
/* open */ spicopen,
/* close */ spicclose,
/* read */ spicread,
/* write */ nowrite,
/* ioctl */ spicioctl,
/* poll */ spicpoll,
/* mmap */ nommap,
/* strategy */ nostrategy,
/* name */ "spic",
/* maj */ CDEV_MAJOR,
/* dump */ nodump,
/* psize */ nopsize,
/* flags */ 0,
/* bmaj */ -1
};
#define SCBUFLEN 128
struct spic_softc {
u_short sc_port_addr;
u_char sc_intr;
struct resource *sc_port_res,*sc_intr_res;
int sc_port_rid,sc_intr_rid;
int sc_opened;
int sc_sleeping;
int sc_buttonlast;
struct callout_handle sc_timeout_ch;
device_t sc_dev;
struct selinfo sc_rsel;
u_char sc_buf[SCBUFLEN];
int sc_count;
};
static void
write_port1(struct spic_softc *sc, u_char val)
{
DELAY(10);
outb(sc-sc_port_addr, val);
}
static void
write_port2(struct spic_softc *sc, u_char val)
{
DELAY(10);
outb(sc-sc_port_addr + 4, val);
}
static u_char
read_port1(struct spic_softc *sc)
{
DELAY(10);
return inb(sc-sc_port_addr);
}
static u_char
read_port2(struct spic_softc *sc)
{
DELAY(10);
return inb(sc-sc_port_addr + 4);
}
static void
busy_wait(struct spic_softc *sc)
{
int i=0;
while(read_port2(sc) 2) {
DELAY(10);
if (i++1) {
printf("spic busy wait abort\n");
return;
}
}
}
static u_char
spic_call1(struct spic_softc *sc, u_char dev) {
busy_wait(sc);
write_port2(sc, dev);
read_port2(sc);
return read_port1(sc);
}
static u_char
spic_call2(struct spic_softc *sc, u_char dev, u_char fn)
{
busy_wait(sc);
write_port2(sc, dev);
busy_wait(sc);
write_port1(sc, fn);
return read_port1(sc);
}
static int
spic_probe(device_t dev)
{
struct spic_softc *sc;
u_char t, spic_irq;
sc = device_get_softc(dev);
bzero(sc, sizeof(struct spic_softc));
if (!(sc-sc_port_res = bus_alloc_resource(dev, SYS_RES_IOPORT,
sc-sc_port_rid, 0, ~0, 5, RF_ACTIVE))) {
device_printf(dev,"Couldn't map I/O\n");
return ENXIO;
}
sc-sc_port_addr = (u_short)rman_get_start(sc-sc_port_res);
if (!(sc-sc_intr_res = bus_alloc_resource(dev, SYS_RES_IRQ,
sc-sc_intr_rid, 0, ~0, 1, RF_ACTIVE))) {
Re: PREFIX clean vs. LOCALBASE clean (Was: Package installation location)
David O'Brien [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 02:19:12PM -0600, Mike Meyer wrote: I intend "LOCALBASE clean" to mean "all files installed by other ports are looked for in the LOCALBASE tree". If all ports are PREFIX clean, you will have that. Thus it doens't need to be discussed separately. Using the two definitions above, the first sentence is false. How is it false? As described below. In particular, assume that the port APort depends on BPort in some way, and is PREFIX clean. Which is PREFIX clean? Aport or Bport? (it is often good to not use pronouns in technical disucssions...) Actually, dangling pronouns are bad in any discussion, and that was one. Both are PREFIX clean. That means that everything in APort is installed in PREFIX, and all APorts references to things in APort look for them there. Which is correct if Aport is PREFIX-clean. By definition, yes. Neither of those statements precludes APort from looking for things that are part of BPort directly in /usr/local instead of in LOCALBASE. Yes it does if Aport is PREFIX-clean. s./usr/local.PREFIX.g and would be a better way to say it, adding PREFIX != LOCALBASE. Take a second look at the definition of the "PREFIX clean" you agreed to before, and the conditions I stated above: all files installed in by APort are in PREFIX, and all references to things installed by APort use PREFIX. That doesn't say anything about how APort references things installed by other ports! Of course, your suggested change fixes some of those cases, but it's not correct for things installed by other ports according to my reading of bsd.port.mk. The port being built things in PREFIX; other ports installed things in LOCALBASE or X11BASE, as appopriate. So fixing references to things in other ports requires s./usr/local.LOCALBASE.g, hence "LOCALBASE clean" for things that fail to deal with that case. As a final note, neither fix corrects the cases where the /usr/local reference that makes things work when LOCALBASE and PREFIX are both /usr/local comes from outside of the ports tree completely. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fix for pageout_flush panic (was Re: 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
Hmm. Very odd. It's catching a fully valid file page which is
marked partially dirty, less then a kilobyte in size, mapped
into memory but not associated with a buffer. m-dirty is
0xFC (roughly equivalent to 3584 bytes, but the file is only 932
bytes long.
I'm not sure how it is possible for the above situation to
occur. No, I take that back... I see one possibility related
to ftruncate()ing a file, where a file is partially dirtied, mapped
into memory, and then ftruncate()ed. I'll look into that.
This is -current, it could be related to the ongoing work in -current, it
has been reported to the list that -j buildworlds don't survive long but
I don't know if that is true on single-cpu -current's or just for MP
current's.
You can revert my KASSERT to get rid of the panic but at this time I
think my KASSERT is correct, and some piece of code somewhere is
blowing something up.
I would recommend *NOT* using -current for a production news machine
If you can repeat the problem under -stable (which has the same patch
set), that will give me more of a base to work from. I'll track down the
one case I can think of to see if I can reproduce the bug.
-Matt
Index: sys/vm/vm_pageout.c
===
RCS file: /home/ncvs/src/sys/vm/vm_pageout.c,v
retrieving revision 1.151.2.5
diff -u -r1.151.2.5 vm_pageout.c
--- vm_pageout.c2000/11/26 02:55:14 1.151.2.5
+++ vm_pageout.c2000/12/10 22:50:43
@@ -372,7 +372,7 @@
*/
for (i = 0; i count; i++) {
- KASSERT(mc[i]-valid == VM_PAGE_BITS_ALL mc[i]-dirty ==
VM_PAGE_BITS_ALL, ("vm_pageout_flush page %p index %d/%d: partially dirty page",
mc[i], i, count));
+ KASSERT(mc[i]-valid == VM_PAGE_BITS_ALL, ("vm_pageout_flush page %p
+index %d/%d: partially dirty page", mc[i], i, count));
vm_page_io_start(mc[i]);
vm_page_protect(mc[i], VM_PROT_READ);
}
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
Nate Williams [EMAIL PROTECTED] types: I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. Oh, I agree that installing things in /usr/local predates /opt by years. I'm curious as to what vendor provided software installed itself in /usr/local, though, as I've never seen any. If memory serves (and it may not at this remove), /usr/local/bin wasn't on my path until I started using VAXen, meaning there were few or no packages installing in /usr/local on v6 v7 on the 11s. On V7 (the earliest software I have), vendor software installed itself in /usr/[bin|lib], which is IMO worse than /usr/local. That sounds like you're agreeing with me, at least about v7. Nate Williams [EMAIL PROTECTED] types: Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( SysIII was not something I ever worked with. I went from v7 to BSD until, and stayed pretty much BSD until I started working with Solaris in the early/mid 90s. In any case, I think you're wasting your time trying to convince folks here. It appears to me that this is an argument going nowhere, and the claims you're making of history and tradition are way off the mark, thus making the arguments have much less weight. I few this as consciousness-raising. That's an ongoing process. My claims about "history" and "tradition" are attempts to refute Brandon's assertion that packages going into /usr/local has "years of tradition behind it." Mostly, it's about what *packages* are, not what /usr/local was used for. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
Is there any supporting Access Point functionality, eg. using the freebsd server as AP? Warner Losh wrote: In message [EMAIL PROTECTED] "[EMAIL PROTECTED]" writes: : Is there a list of wireless pc cards that work (and how well they work) : with FreeBSD?? There's /etc/defaults/pccard.conf, which says breifly: Aironet 340/342 Series 11Mbps 802.11 wireless NIC Aironet PC4500 2Mbps 802.11 wireless NIC Aironet PC4800 11Mbps 802.11 wireless NIC Bay Networks BayStack 650 Wireless LAN Cabletron RoamAbout, WaveLAN/IEEE clone Compaq WL100 Corega KK Wireless LAN PCC-11 ELECOM Air@Hawk/LD-WL11/PCC (0.7.5) ELECOM Air@Hawk/LD-WL11/PCC (0.7.6 and later) Farallon SkyLINE Wireless Farallon Skyline 11Mbps Wireless Generic AMD Am79c930 based card ICOM SL-1100 ICom SL-200 Lucent WaveLAN/IEEE Melco Airconnect Melco WLI-PCM NCR WaveLAN/IEEE NEC Wireless Card CMZ-RT-WP PLANEX GeoWave/GW-NS110 TDK LAK-CD011WL WebGEAR Aviator 2.4 (ray driver, not 802.11b) Xircom CreditCard Netwave (cwn to be committed soon) ZoomAir-4000 Warner P.S. I'd like to have one of each of these. 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: panic: vm_pageout_flush: partially dirty page
Phillipp, could you do me a favor and try this patch instead of
removing the KASSERT? That is, keep the original KASSERT, apply
this patch to your -current instead, and see if you still get the
panic.
This patch is relative to -current. What it does is clear the dirty
bits for the portion of the fragment being truncated off. If the
resulting page is entirely clean, then fine. If it is partially dirty
then we make the whole thing dirty in case it was mapped.
I believe what was happening was that there is a small file, around 1K,
which is clean, gets something appended to it with write() (dirtying
a big chunk of the page but not the first 1K or so), and
then gets truncated small again. The buffer cache then believes,
correctly, that the (now 1K) buffer is no longer dirty and can be thrown
away. However. the backing vm_page_t is still marked partially dirty
because the truncate operation didn't undo the dirty bits for the
section that was truncated. This results in a partially dirty vm_page_t
that is not associated with any buffer. It hits the VM flushing code
and panics because mapped dirty pages are supposed to either be 100%
clean or 100% dirty, not something inbetween.
-Matt
Index: vm/vnode_pager.c
===
RCS file: /home/ncvs/src/sys/vm/vnode_pager.c,v
retrieving revision 1.124
diff -u -r1.124 vnode_pager.c
--- vnode_pager.c 2000/07/11 22:07:57 1.124
+++ vnode_pager.c 2000/12/10 23:53:53
@@ -300,10 +300,29 @@
m = vm_page_lookup(object, OFF_TO_IDX(nsize));
if (m) {
+ int base = (int)nsize PAGE_MASK;
+ int size = PAGE_SIZE - base;
+
+ /*
+* Clear out partial-page garbage in case
+* the page has been mapped.
+*/
kva = vm_pager_map_page(m);
- bzero((caddr_t) kva + (nsize PAGE_MASK),
- (int) (round_page(nsize) - nsize));
+ bzero((caddr_t)kva + base, size);
vm_pager_unmap_page(kva);
+
+ /*
+* Clear out partial-page dirty bits. This
+* has the side effect of setting the valid
+* bits, but that is ok. There are a bunch
+* of places in the VM system where we expected
+* m-dirty == VM_PAGE_BITS_ALL. The file EOF
+* case is one of them. If the page is still
+* partially dirty, make it fully dirty.
+*/
+ vm_page_set_validclean(m, base, size);
+ if (m-dirty != 0)
+ m-dirty = VM_PAGE_BITS_ALL;
}
}
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: fix for pageout_flush panic (was Re: panic: vm_pageout_flush: partially dirty page)
On Sun, Dec 10, 2000 at 03:34:32PM -0800, Matt Dillon wrote: :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 Hmm. Very odd. It's catching a fully valid file page which is marked partially dirty, less then a kilobyte in size, mapped into memory but not associated with a buffer. m-dirty is 0xFC (roughly equivalent to 3584 bytes, but the file is only 932 bytes long. /usr/local/news/etc#wc active 23 92 932 active Innd does mmap the active file, but I don't know what it does with it. I'll look at it; maybe I can construct a simpler example. I would recommend *NOT* using -current for a production news machine Of course not, this is just a mini archive of my favourite newsgroups. :-) If you can repeat the problem under -stable (which has the same patch set), that will give me more of a base to work from. Ok, I'll try that. Bye, Philipp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Sony jog dial driver
On Sun, Dec 10, 2000 at 06:44:45PM -0600, Michael C . Wu scribbled: Oops, nevermind my questions about contacts and Fn+* functions, should have read the code before I reply. :) -- +--+ | [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: Sony jog dial driver
On Sun, 10 Dec 2000, Michael C . Wu wrote: On Sun, Dec 10, 2000 at 03:19:06PM -0800, Nick Sayer scribbled: | Attached is a preliminary driver for the Sony jog dial. It's enough that | you can create a /dev/jogdial and watch letters come out. W00t! :) You did it! How did you wrestle documentation out of Sony? (or did you ever?) If you managed to get a Sony contact, can I contact him too? Nope. I have Andrew Tridge and Ian Dowse to thank jointly for sample code that went into it. I am inclined to split the US$100 prize between them. | It needs a lot of improvement: | 1. Use interrupts instead of polling. | 2. Present mouse-oriented events instead of letters. I recall you talking about the Fn+LCD brightness and such to be controlled by the same controller also. Do you have any work in that area? No, I'm afraid not. AOL whine IMHO, we should have: scroll up/down : mouse 4 and 5 (just like mouse wheel) press down while scrolling up/down : mixer vol +/- press down one time : mouse middle paste Those are tasks best done in userspace. The driver's job is simply to report the events. My immediate task is now to have it do that reporting in a moused compatible way. | 3. Fix the probe routine so that it tries to detect the presence of the | device rather than the magic 0x10a0 port location. | | 4. Eventual ACPIification of the driver. | | 5. Create a 2nd device to deal with other devices like the lid switch, | capture button, etc. | | But I wanted to get this much out there for people to play with. I'll test this tonight. :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: vm_pageout_flush: partially dirty page
On Sun, Dec 10, 2000 at 02:25:48PM -0800, Matt Dillon wrote: : 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 :... When you created the filesystems on which the history and spool reside, did you use any custom parameters for blocksize, fragsize, etc...? No, I used sysinstall with the default parameters to create them. bs=8192, fs=1024, cpg=16 The spool is on /dev/ad0s1f, history etc. is on /dev/da0s1f. If it matters, turning softupdates off on both didn't help. P.S. you should not publish paths to kernel dumps on the lists... send that over private email. Dumps might contain sensitive data such as passwords. I know and I would've changed them and the ssh identity anyway :-) Thanks, Philipp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
On Sun, Dec 10, 2000 at 02:18:31PM -0800, Crist J. Clark wrote: Nope. One can ``ln -s /usr/local /usr/pkg'' and get the behavior those that like everything in one place prefers while still segregating stuff for those that prefer it. That makes no sense. Yes it does. The big argument has been that packages should not go into /usr/local because /usr/local is for something else. By one set of people. There is another set that wants everything in a single directory. The NetBSD way gives that to them with a very simple symlink. There is no easy way to split out the FreeBSD _Packages_ from /usr/local, for the converse. What's the difference? Opinions on wether to separate out or 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: Confusing error messages from shell image activation
On Sun, Dec 10, 2000 at 03:15:58PM -0700, Warner Losh wrote: but there also was a /usr/contrib for large packages contribtued to Berkeley by outside parties. BSDi's BSD/OS installs GNOME, KDE, editors, etc.. into /usr/contrib and leaves /usr/local for the user. -- -- 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: fix for pageout_flush panic (was Re: panic: vm_pageout_flush: partially dirty page)
I found a second issue... just a normal write-via-mmap issue, which I think INN does. If you mmap() a file fragment and write to it via the mmap(), m-dirty is set to VM_PAGE_BITS_ALL (0xFF). the normal buffer flush will only clear the dirty bits on the page associated with the file fragment, leaving m-dirty 0xFC without an associated buffer. I think *this* is causing the panic. Unfortunately, fixing it properly is a bit delicate because there are cases where it is not appropriate for the buffer cache code to just go and clear m-dirty (e.g. for odd buffer block sizes such as those used for bitmap blocks). I should have a patch in a bit. -Matt 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] Andre Oppermann writes: : Is there any supporting Access Point functionality, eg. using the : freebsd server as AP? No. AP mode firmware is generally undocumented. Warner 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
"Daniel C. Sobral" wrote: Mike Meyer wrote: 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. Not for everyone. FreeBSD adopted one of the ways /usr/local was being used. You can keep ranting on this and pretending the way above is how everyone used /usr/local as long as you want, but the fact is that you won't get this changed. I worked on smail as early as 1985; it installed in /usr/local way back then. I think the "/usr/local is for local extensions" is a SysV mindset. -- "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 Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
Not /usr/local - that's for locally maintained software. I'd rather it
go on /usr, so I don't like /opt. When I got to choose, I chose
/usr/opt. But anything other than /usr/local on /usr would do as well.
So do you also put the configurations in ${PREFIX}/etc, or
/usr/local/etc? Even though you got them from a readily
replaceable source, you can't retrieve your local configurations
that way.
That's true. But if it's packaged, it belongs in an area reserved for
*packages*. FreeBSD is the only system I know of that coopts
/usr/local for packages, instead of reserving it for things that are
locally maintained. Whether that locally maintained software is
written locally or comes from a third party is irrelevant to this
discussion.
Well, I'll just stick my oar in for /usr/local. I count myself
among the aesthetically dismayed when I first encountered /opt
on a SunOS box. (Or was that Solaris? Time fades...)
The critical difference is the "requires local src configuration"
line. For FreeBSD or any of the ports or packages, I can blow away the
source tree without worrying about needing it back; I can always get
it back from FreeBSD again. For the same reason, I don't worry much
about the binaries. For locally written software, if I lose ths
source, I'm SOL.
Don't you keep the source that you write somewhere in your home
directory? I do.
For true third party software, how screwed I am
depends on how hard it was getting the thing to build on FreeBSD. As a
general rule, I always save them. The binaries get the same
treatment. Having to figure out which is which is *much* easier if the
two are in different directory hierarchies.
Whenever I have to build something outside the ports hierarchy,
I finish by diffing the orig and modified source trees. I put
the source tarball into /usr/ports/distfiles, in case someone at
FreeBSD gets around to building a port of it, and stick the
diffs in my $HOME/src directory.
Clearly, a package is *not* the same as either third party or locally
written software. For people who don't care about any of those
differences, packages co-opting /usr/local doesn't matter. For people
who do, there's PREFIX - except it doesn't work very well, and can't
work for binary builds (and with the CDROM set no longer having
distfiles on it, that's a major PITA).
I agree that PREFIX/LOCALBASE should work: you can't legislate
taste. I'm going to keep it to /usr/local and /usr/X11R6,
though, thanks all the same.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
On Sun, Dec 10, 2000 at 03:46:27PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "[EMAIL PROTECTED]" writes: : Is there a list of wireless pc cards that work (and how well they work) : with FreeBSD?? There's /etc/defaults/pccard.conf, which says breifly: Aironet 340/342 Series 11Mbps 802.11 wireless NIC This should read: Cisco Aironet 340 Series 11Mbps 802.11 wireless NIC I though this had been fixed, but apparently it wasn't in all places. Aironet PC4800 11Mbps 802.11 wireless NIC These aren't 802.11b compatable. They played the usual game of releasing before the final IEEE vote on the standard to be early to market and didn't win the vote. The 802.11b compatable Aironet access points (Cisco APs) can be configured to support these, but the don't interoperate fully. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Supported wireless PCMCIA cards (was: Lucent Orinoco Gold PCCard?)
On Sunday, 10 December 2000 at 15:46:27 -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "[EMAIL PROTECTED]" writes: : Is there a list of wireless pc cards that work (and how well they work) : with FreeBSD?? There's /etc/defaults/pccard.conf, which says breifly: ... WebGEAR Aviator 2.4 (ray driver, not 802.11b) Specifically, it's 802.11 FHSS. I've been having a *lot* of trouble with this one. It maps a total of 52 kB into I/O space (48 kB + 4 kB, each contiguous), and I can't find that much memory. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Confusing error messages from shell image activation
Andrew Reilly [EMAIL PROTECTED] types:
On Sun, Dec 10, 2000 at 12:31:10PM -0600, Mike Meyer wrote:
Not /usr/local - that's for locally maintained software. I'd rather it
go on /usr, so I don't like /opt. When I got to choose, I chose
/usr/opt. But anything other than /usr/local on /usr would do as well.
So do you also put the configurations in ${PREFIX}/etc, or
/usr/local/etc? Even though you got them from a readily
replaceable source, you can't retrieve your local configurations
that way.
${PREFIX}/etc, and stored in perforce. The perforce database is on
/usr/local, and saved along with everything else.
In fact, *all* my system configuration files are stored in
perforce. In theory, I can restore a system configuration from
that. Since I haven't actually used it, I expect it to work as well as
setting LOCALBASE works.
That's true. But if it's packaged, it belongs in an area reserved for
*packages*. FreeBSD is the only system I know of that coopts
/usr/local for packages, instead of reserving it for things that are
locally maintained. Whether that locally maintained software is
written locally or comes from a third party is irrelevant to this
discussion.
Well, I'll just stick my oar in for /usr/local. I count myself
among the aesthetically dismayed when I first encountered /opt
on a SunOS box. (Or was that Solaris? Time fades...)
I dislike /opt as well. For two reasons. One is that it's not on /usr
meaning I have to either set aside another large FS for system
software, or tweak things to get it there. The other is that all the
packages have their copy of the hierarchy. If there were a hook to
install symlinks in a standard heirarchy under /opt, it wouldn't
bother me so much. But there isn't, so I have to figure out what needs
to be installed, do it by hand, and take some action to insure it gets
recreated if I need to do that.
The critical difference is the "requires local src configuration"
line. For FreeBSD or any of the ports or packages, I can blow away the
source tree without worrying about needing it back; I can always get
it back from FreeBSD again. For the same reason, I don't worry much
about the binaries. For locally written software, if I lose ths
source, I'm SOL.
Don't you keep the source that you write somewhere in your home
directory? I do.
Yup. I also keep the source for random software from the network in my
home directory. I don't keep the source for ports anywhere. That's
part of the basis for the claim that "installed over the network" and
"FreeBSD packages" are *not* identical, and losing the ability to
easily separate them is bad.
For true third party software, how screwed I am
depends on how hard it was getting the thing to build on FreeBSD. As a
general rule, I always save them. The binaries get the same
treatment. Having to figure out which is which is *much* easier if the
two are in different directory hierarchies.
Whenever I have to build something outside the ports hierarchy,
I finish by diffing the orig and modified source trees. I put
the source tarball into /usr/ports/distfiles, in case someone at
FreeBSD gets around to building a port of it, and stick the
diffs in my $HOME/src directory.
Why don't you go ahead and turn it into a port, and submit that? I've
done that - even for locally written software. Being able to use the
ports mechanisms to maintain the installation of software is a win. I
also PR them, and every once in a while one of them gets committed
before the ports structure changes so much the port is outdated.
Whether I turn true third party software into a port or not, I put
network sources in an external source branch, and my build version in
a local branch so I can use source software management tools to deal
with upgrades from the vendor. I *never* do that with a port. I don't
manage that software - someone appointed by FreeBSD does. Again,
that's a reason for wanting the two kinds of software in different
hierarchies, and FreeBSD coopting the place where much of that
software expects to be installed being a pain.
Clearly, a package is *not* the same as either third party or locally
written software. For people who don't care about any of those
differences, packages co-opting /usr/local doesn't matter. For people
who do, there's PREFIX - except it doesn't work very well, and can't
work for binary builds (and with the CDROM set no longer having
distfiles on it, that's a major PITA).
I agree that PREFIX/LOCALBASE should work: you can't legislate
taste. I'm going to keep it to /usr/local and /usr/X11R6,
though, thanks all the same.
Making the default something other than /usr/local makes it more
likely that PREFIX/LOCALBASE will work. Also, as was pointed out
elsewhere in the thread, if ports go somewhere that nobody uses for
anything, a simple symlink will make it look like it's where ever you
want it, and you get the two things merged. If the default occupies
something
Re: /usr/local abuse
David O'Brien wrote:
On Sun, Dec 10, 2000 at 01:44:41PM -0500, Brian Dean wrote:
I think I finally understand what you are complaining about,
Maybe.
But to say that installing ports into /usr/local is somehow wrong, I
have to disagree.
Do you understand why NetBSD Packages (ie, the system they took from us)
install into /usr/pkg by default rather than /usr/local ?
Yes, but that doesn't mean I agree with it. In fact, I find it slighly
bizarre. I dislike needing a different path on NetBSD than what I have
on {Free,Open}BSD.
--
"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
I'm aware that software was installing itself in /usr/local years before it was installing in /opt. On the other hand, vendor software was installing in /opt years before I ever saw it install in /usr/local. Most vendor software I know pre-dates /opt, and installed itself in /usr/local. I'm with Warner on this one, installing in /usr/local predates /opt by many years. Before /opt, vendors always used /usr/local, or worse they installed in /bin and /usr/bin. Oh, I agree that installing things in /usr/local predates /opt by years. I'm curious as to what vendor provided software installed itself in /usr/local, though, as I've never seen any. I know that as recent as 3=4 years ago, Purify installed itself by default in /usr/local, on SunOS and Solaris. Lucid did this as well, although things start getting pretty fuzzy going back that far. :) Then again, your quoting of "packages" points up something else - I never saw prepackaged binaries for v6 or v7. I did on SysIII. As a matter of fact, the entire distribution was bundled into separate packets (all of them installed in /usr). :( SysIII was not something I ever worked with. I went from v7 to BSD until, and stayed pretty much BSD until I started working with Solaris in the early/mid 90s. I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. In any case, I think you're wasting your time trying to convince folks here. It appears to me that this is an argument going nowhere, and the claims you're making of history and tradition are way off the mark, thus making the arguments have much less weight. I few this as consciousness-raising. That's an ongoing process. My claims about "history" and "tradition" are attempts to refute Brandon's assertion that packages going into /usr/local has "years of tradition behind it." Mostly, it's about what *packages* are, not what /usr/local was used for. I disagree. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Lucent Orinoco Gold PCCard?
"[EMAIL PROTECTED]" wrote: Is there a list of wireless pc cards that work (and how well they work) with FreeBSD?? man -k 802.11 or man -k wireless should do it, but the man pages aren't quite that organized. All I can find grepping the 4.2 sources is Cisco/Aironet and Lucent WaveLAN/ Orinoco: an(4) and wi(4). Many of the cards on the market are Lucent OEMs, but it's still a crapshoot without direct knowlege. -- "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: Lucent Orinoco Gold PCCard?
Andre Oppermann wrote: Is there any supporting Access Point functionality, eg. using the freebsd server as AP? There's no special support for it, but it's just another interface. If you run it (and your other 802.11 devices) in ad-hoc mode, everything should work peachy. -- "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
Nate Williams [EMAIL PROTECTED] types: I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early 90s, and don't remember anything being in /usr/local that I didn't drag of the net (or write myself) and install there, on either VAXen or MIPS boxes. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. I'd certainly be interested in that. Of course, as you yourself said, the argument about tradition is a sideline. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. 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
I ran mostly DEC boxes until the early 90s, which had all software installed in /usr/bin or /usr/local/bin. Well, I ran DEC boxes for Dec (at WSE) back in the late 80s and early 90s, and don't remember anything being in /usr/local that I didn't drag of the net (or write myself) and install there, on either VAXen or MIPS boxes. Hmm, trying to dig up memories of the software from that long ago. Software that run a piece of chemistry hardware (a electronic microscope?) sounds right, but I wouldn't bet my life on it. By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. '/opt', '/usr/pkg', '/whatever-you-want-to-call-it'. You were the one who claimed that Solaris was the first 'vendor' to provide packages, and they used opt. Probably the same time-frame for SunOS, although I didn't have experience with it until the early 90's. However, if necessary, I can try and dig out installation docs for some software which ask to have the stuff unpacked in /usr/local. I'd certainly be interested in that. It'd be Purify. Of course, as you yourself said, the argument about tradition is a sideline. Yep. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. Not true. You can change the source to point to '/usr/mike-likes-it-here', and it *should* work. If it doesn't, then it's borken. :) Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. Nate 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 Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. The default setup for locally built ports can stay exactly as it is. (On the subject of third-party software the installs in /usr/local, the only binary thing that I run is StarOffice5.2, and it installed itself in /usr/local/office52, but I think that it's pretty agnostic about where it lives.) -- Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Nate Williams [EMAIL PROTECTED] types: By your own admission, /usr/local wasn't used on v7. So the discussion should turn to when BSD started seeing prebuilt vendor packages to install in /usr/local. Late '80s on DEC boxes running Ultrix (which one could argue is one of the earliest commercial 'vendor' BSD unices). I don't consider Solaris a BSD unix, so it using /opt isn't a valid point, which makes the whole concept of '/opt' for BSD packages a moot point. :) I wish people would quite acting like moving packages out of /usr/local meant going to something like /opt. I don't think anyone in their right mind would suggest that. '/opt', '/usr/pkg', '/whatever-you-want-to-call-it'. You were the one who claimed that Solaris was the first 'vendor' to provide packages, and they used opt. No, I said they were the first OS vendor I was aware of that used packages, as opposed to tarballs with ad hoc scripts. The real issue is that ports/packages have one source, and things that may *not* have a mechanism to move them out of /usr/local (however badly broken) have another some of us want - quite legitimately - want to treat those two things differently, and packages using a directory name that has an established use makes that difficult. Not true. You can change the source to point to '/usr/mike-likes-it-here', and it *should* work. If it doesn't, then it's borken. :) True. I can also go through and fix everything in FreeBSD to use /usr/packages-really-go-here, and release the resulting system as EvenMoreFreeBSD. This is probably a lot easier that what you suggest, as it involves fixing an identifiable set of software that claims to be configurable for that (to bad the claim is only partly true). Doing what you propose involves changing much larger set of software, much of which doesn't even claim to be movable in that way. Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I *know* how broken it is - I tried to use the existing mechanism to move it, based on the argument in the above paragraph. The thing is, using *any* name that has ever been used by the community for something (doesn't really matter what) for something new is bad, because Unix doesn't have a mechanism that lets you separate things once they've been used. Using a totally new name avoids that, and linking it to the name you want is trivial. Hmm - maybe they should go in /usr/.local? I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. FreeBSD, of course, *does* have such a tradition. NetBSD and BSD/OS don't. I can even see why, when jkh first built the port system, he would make it use /usr/local. After all, he's just making it easier for people to install software that normally installs there. The thing is, the package system has grown into something more than that. It really is vendor-supplied and vendor-supported third party software, and part of the distribution. Those claiming that packages aren't part of the FreeBSD distribution are claiming that something like 75% of the "FreeBSD subscription" isn't in the FreeBSD distribution. In which case, calling it a "FreeBSD subscription" would seem to be a misnomer as bad as calling a planet thats 75% water "dirt". 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
Fixing broken things is a good thing. Your argument about 'moving it from /usr/local to show how broken' is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". I don't think anyone is agreeing. Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. I don't see how building it for /usr/local or /usr/pkg by default changes things. If things are built for a default location, they'll be broken no matter where they go. The default setup for locally built ports can stay exactly as it is. I don't agree that we need to differentiate between 'pre-built' ports and 'locally built' ports. As a matter of fact, I think differentiating only confuses things. If the 'port' is broken w/regard to not using it's 'base', then it's broken, no matter where it's installed to. I think time would be better spent fixing this brokeness rather than arguing where the default should be. :) Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[current] Re: Confusing error messages from shell image activation
"Brian" == Brian Dean [EMAIL PROTECTED] writes: Brian I'm really not exactly sure what you are complaining about. Brian For example, the last time I built Emacs for Solaris (several Brian years ago admittedly), by default it installed itself into Brian /usr/local. If you install Emacs onto FreeBSD, it goes into Brian /usr/local. The behaviour is the same. Are you proposing that Brian since FreeBSD provides a set of patches so that Emacs builds Brian cleanly, that it should therefore install it somewhere other Brian than /usr/local? I'm jumping into the middle of an argument that I havn't been reading, but I've had the very same argument with a number of people. It's fairly predictable. For foreign or not-so-foreign packages and software, I've seen /usr/local, /local, /usr/contrib, /opt and /usr/pkg. One site that I worked at was even pedantic that /usr/contrib was for externally generated software and /usr/local was for software written and/or maintained locally. I've also worked in environments where different directory structures implied the level that the IS guys intended to support the software. Arguing about any of that in an OSS project is silly. However, I believe that /usr/ports should install all it's software in one place and that place _shouldn't_ be /usr/local. Reasoning: - having it install in /usr/X11R6 and /usr/local is confusing. Having random software put itself in either /usr/X11R6 or /usr/local is more confusing. Having ports even migrate from /usr/local to /usr/X11R6 is even more confusing. - having all ports under one tree allows you to share a tree of ports without sharing a tree of /usr. - would allow package management (eventually) to say that every file under /blah is accounted for by the package database. - (and the reason it shouldn't be /usr/local) ... many packages on the net install in /usr/local by default ... so I can see the lazyness in just accepting that. However, /usr/local is a useful place for an administrator to put things that are not part of the ports collection that he has hand compiled onto the machine. In many cases an inordinate amount of work would be required to change a piece of software that was only to be installed on one machine. It also forces all ports to be PREFIX enabled ... which is useful. Now... I think it would be useful to have arguments about more complex package software that allowed /usr/pkg/foo to hold all of foo and linking /usr/pkg/bin/foo to /usr/pkg/foo/bin/foo ... 'n stuff like that. Complete separation and versioning are desireable things. I suppose if everything was dead accurate (which it's not) you could account for every file in the namespace ... which would be way-cool ... but separating packages might be more sensible. ... but /usr/pkg supplanting /usr/local is one of the things that I like about NetBSD. Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://www.velocet.net/~dgilbert | are precisely opposite. | =GLO To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
In message [EMAIL PROTECTED] Joe Kelsey writes: : To the extent that NetBSD *forces* the local administrator to use : /usr/pkg, I find it contains the same deficiency. If it does not force : this, then perhaps FreeBSD should adopt it. I have never used NetBSD, : so I cannot comment further on it. I'd point out that make install in the pkgsrc tree installs into /usr/pkg too. So NetBSD doesn't differentiate between locally compiled files and binary packages they supply. Warner 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
Andrew Reilly [EMAIL PROTECTED] types: On Sun, Dec 10, 2000 at 09:46:46PM -0700, Nate Williams wrote: Fixing broken things is a good thing. Your argument about moving it from /usr/local to show how broken is a good test procedure, but turning it into policy is something completely different. I think the 'tradition' of FreeBSD installing packages in /usr/local is enough to leave things the way they are, especially since non-broken packages allow you to install it somewhere else on *your* system. You have to admit that the "prebuilt packages" argument is a pretty good one. I don't used many myself (only cvsup, I think), but if it's true that the distribution CDs ship these pre-built programs, rather than the distfiles, then they should be built in such a way as to minimise the amount of "built-in policy". Building for /usr/pkg (which can be sym-linked to /usr/local) does seem to solve that problem, without having to invent a mechanism for tweaking compiled-in paths after the fact. The course of this conversation made me realize that the reasons I subscribed to FreeBSD in the first place no longer hold - except for financial contributions to the project, that is. The install disk and and live file system are nice to have, but not crucial. The real reason was having all those precompiled packages and/or distfiles around. But the distfiles vanished as of 4.0, and the ability to use the packages vanished when I set LOCALBASE to /usr/opt and rebuilt all my installed ports. (On the subject of third-party software the installs in /usr/local, the only binary thing that I run is StarOffice5.2, and it installed itself in /usr/local/office52, but I think that it's pretty agnostic about where it lives.) The office52 port is quit happy installing anywhere - I've got it at /usr/opt on my system. The WordPerfect and NetScape ports are also PREFIX clen. On the other hand, Applixware Office ships a precompiled package for /usr/local, and doesn't like being installed anywhere else. Which means I've got a couple of hundred megabytes being backup up for no good reason :-(. 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
In message [EMAIL PROTECTED] Nate Williams writes: : I know that as recent as 3=4 years ago, Purify installed itself by : default in /usr/local, on SunOS and Solaris. Lucid did this as well, : although things start getting pretty fuzzy going back that far. :) purify and the binary distributions of xemacs installed themselves into /usr/local on Solaris in the 1992-1996 time frame. As did *ALL* of the software binaries we downloaded from the net. Framemaker installed in /usr/local as well in the SunOS 3.5/4.0 time frame. Interleaf installed itself in /usr/local on SunOS 4.0/4.1 time frame. : My claims about "history" and "tradition" are attempts to refute : Brandon's assertion that packages going into /usr/local has "years of : tradition behind it." Mostly, it's about what *packages* are, not what : /usr/local was used for. : : I disagree. I do too. : Probably the same time-frame for SunOS, although I didn't have : experience with it until the early 90's. However, if necessary, I can : try and dig out installation docs for some software which ask to have : the stuff unpacked in /usr/local. I still have some backup tapes of our main server from the 1992 time frame that shows software packages from ISVs installed into /usr/local/bin. Warner 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
In message [EMAIL PROTECTED] Nate Williams writes: : Probably the same time-frame for SunOS, although I didn't have : experience with it until the early 90's. However, if necessary, I can : try and dig out installation docs for some software which ask to have : the stuff unpacked in /usr/local. : : I'd certainly be interested in that. : : It'd be Purify. Try also Interleaf, FrameMaker, the elan license manager, eroff, lucent emacs binaries for the net, TeX binaries from the net, gosling emacs, and I think informix. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
/usr/local abuse
Warner Losh [EMAIL PROTECTED] types: In message [EMAIL PROTECTED] Nate Williams writes: : I know that as recent as 3=4 years ago, Purify installed itself by : default in /usr/local, on SunOS and Solaris. Lucid did this as well, : although things start getting pretty fuzzy going back that far. :) purify and the binary distributions of xemacs installed themselves into /usr/local on Solaris in the 1992-1996 time frame. As did *ALL* of the software binaries we downloaded from the net. Framemaker installed in /usr/local as well in the SunOS 3.5/4.0 time frame. Interleaf installed itself in /usr/local on SunOS 4.0/4.1 time frame. How much of that software did you get from the OS vendor? : My claims about "history" and "tradition" are attempts to refute : Brandon's assertion that packages going into /usr/local has "years of : tradition behind it." Mostly, it's about what *packages* are, not what : /usr/local was used for. : I disagree. I do too. Exactly what do you disagree with? That I'm arguing about what packages are? Or my assertion that packages installing in /usr/local doesn't have years of tradition behind it? The former is clearly true. And I've never tried to claim that people haven't been installing third party software in /usr/local for years (though some interpreted my comments about "locally maintained software" to exclude such). My claim is that the package system has grown into something other than "something to make installing third party software more convenient". It is pretty much a direct translation of some vendors practice of providing precompiled freeware into an OSS environment. The end user no longer has to worry about porting to or configuring for the OS - someone appointed by the OS vendor does that. The end user doesn't worry about updates to the software - the vendor provides them with udpates to the OS. The end user doesn't have to worry about what is and isn't part of the software - tools for doing all that come with the OS (well, with FreeBSD, anyway, if not with all the commercial OSs). Sure, with FreeBSD the end user sometimes has to *compile* the package. On the other hand, the end user sometimes has to compile the OS as well; that's part of dealing with an OSS system. Now, back to /usr/local and tradition - how many OS vendors provide software that installs in /usr/local. So far, no one has named one other than FreeBSD and OpenBSD, which copied FreeBSD. All the ones you named aren't OS vendors, they are third parties distributing their own software. Those are perfectly reasonable things to install in /usr/local; the OS vendor has nothing to do with them. That's not true for FreeBSD packages. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /usr/local abuse
: I know that as recent as 3=4 years ago, Purify installed itself by : default in /usr/local, on SunOS and Solaris. Lucid did this as well, : although things start getting pretty fuzzy going back that far. :) purify and the binary distributions of xemacs installed themselves into /usr/local on Solaris in the 1992-1996 time frame. As did *ALL* of the software binaries we downloaded from the net. Framemaker installed in /usr/local as well in the SunOS 3.5/4.0 time frame. Interleaf installed itself in /usr/local on SunOS 4.0/4.1 time frame. How much of that software did you get from the OS vendor? Ahh, if we're limiting the discussio to 'OS vendor' software, then every OS vendor I know installs its software in /usr/bin, and /usr/lib. Even Sun does this with it's 'OS vendor' tools. Only 3rd party software installed itself in /usr/local. So, going with the 'OS vendor' argument, then all software should install itself in /usr, and definitely not /usr/local. Non-OS vendor software installs itself all over the place, but Solaris *tries* to keep the software in /opt. : My claims about "history" and "tradition" are attempts to refute : Brandon's assertion that packages going into /usr/local has "years of : tradition behind it." Mostly, it's about what *packages* are, not what : /usr/local was used for. : I disagree. I do too. Exactly what do you disagree with? That I'm arguing about what packages are? Or my assertion that packages installing in /usr/local doesn't have years of tradition behind it? The former is clearly true. And I've never tried to claim that people haven't been installing third party software in /usr/local for years And that third party software often installs itself in /usr/local by default. (though some interpreted my comments about "locally maintained software" to exclude such). My claim is that the package system has grown into something other than "something to make installing third party software more convenient". It is pretty much a direct translation of some vendors practice of providing precompiled freeware into an OSS environment. There is no standard for precompiled freeware distributed by OS vendors that I'm aware of. Packages I've downloaded from Sun put themselves *all over* the place, including /opt/local, /usr/gnu, /opt/gnu, /opt, and many other places. I'm not even sure SCO's skunkware has a standard installation directory. Now, back to /usr/local and tradition - how many OS vendors provide software that installs in /usr/local. SCO perhaps? DEC did for awhile. Sun may have even done it for some of their 'development' tools on SunOS, so as to not wipe-out the default C compiler in the system. Nate 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
In message [EMAIL PROTECTED] Mike Meyer writes: : 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. Not as many as you might think. /usr/local predates /opt by several years. : 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. Ummm, software packages have been make installing into /usr/local since at least 1985 when I started building them. no coopting has been done. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
