Re: kdelibs port broken?
Not with the port. I was installing Qt to /usr/local/qt, and the port was putting the libs in a non-standard place where KDE couldn't find them. :-C I built Qt 1.45 by hand, installed it, set QTDIR, and everything compiled fine. I haven't done much testing on it yet (only ran kdehelp a couple of times), but nothing obvious. As far as I can tell, the KDE ports find Qt just fine. KDE insists on putting everything under the same dir, as does Qt. This violates our hierarchy (see hier(7) manpage), so we had to make some mods to the configurations for Qt and KDE ports. It's not that difficult. If you're gonna use a port, use ports for its dependencies too. You'd be stupid not to use the ports whenever you can. No one has ever provided me a convincing reason why this is not true. It appears that you do not care to hear my reasons, so I won't bother. If I have reasons that I want Qt and KDE in their own directories, I will do so. I would rather apps that expect Qt and KDE to be set up the same as they are on other OS's to work, than to require apps to be quirkified for FreeBSD's heir. You may not agree with my decision, and I'm not asking you to. But if bwoods has the same preference that I do, I'll gladly tell him how to implement them, and would appreciate not being told I'm stupid in the process. Cheers, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kdelibs port broken?
ON that subject, has anyone tried compiling the KDE port with the new QT145 port? Not with the port. I was installing Qt to /usr/local/qt, and the port was putting the libs in a non-standard place where KDE couldn't find them. :-C I built Qt 1.45 by hand, installed it, set QTDIR, and everything compiled fine. I haven't done much testing on it yet (only ran kdehelp a couple of times), but nothing obvious. Cheers, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree 3.3.6 authentication failed?
[Followups to -current] I am running monday's current, Mesa-glx for Riva, XFree 3.3.6 and KDE 1.1.2. All from monday's ports tree. Well, I think I can't say I am running this system, for I am getting the following message whenever I try startx: Authentication failed - cannot start X server. Perhaps you do not have console ownership? _X11TransSocketUNIXConnect: Can't connect: errno = 2 seems that you have built XFree with PAM support. Just rebuild without PAM -- it's broken. Could you give me a few more details about the brokenness? Thanks, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: natd, firewall, and RFC1918...?
1. Is this right? Is natd behaving correctly when the packet comes back in for unregistered ips? I would think that it would be aliased to like this, "machine B's ip" -- machine C's ip" like a proxy? But this would still break the rule "... from any ...". I am going to assert that the behavior shown is correct. If you were to change the IP, then machine C would not recognize the packet as part of the same connection. If you want a proxy, use a proxy. If you want NAT, that's something different. I simply address the issue by blocking those packets on a rule before I send them through the NAT. This also has the advantage that after the NAT line, I know that anything internal is part of an established connection; that's invaluable for UDP, or was before we added dynamic rule support. Best, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
It would obviously not be hard to write a set of stubs for these things, getting those stubs called selectively in the "no real RSA" case also not being very difficult. One way would be to put them in a lower version-numbered shared lib, like OpenBSD did it, so that the application would fall through to link against the stub version if librsaref.so.2 was not found. Another, better way, would be to use weak symbols and a dlopen(), e.g.: [snip] That way it's not an error to link against the openssl library without librsa, though if you do link with -lrsa and -lssl then you can also skip the stubs entirely and not encur the dlopen() overhead, something which makes the -static (or stand-alone) linkers happy. I'm not familiar with OpenSSL's link lines, but here's a question. Are linking with -lrsa and -lssl normally necessary, or is it normally just -lssl? If it't the latter, then programs that expect to link against OpenSSL will succeed to build and link, but fail to run properly. I realize that every OS has its quirks for building packages, but I find this sort of change vulgar. Naturally, if OpenSSL-based programs *expect* to build against -lrsa and -lssl, then I have no objections. joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: openssl in -current
I have just read several documents from www.eff.org, www.rsa.com, and www.openssl.org and have failed to find anything in there, that forbids us from not using openssl's RSA version. RSA has a patent for the algorithm, and they have provided a reference implementation to help the adoption of the algorithm. In their license (RSAREF) it says you can't export the code outside USA, but the US ITAR laws don't say anything about importing. So in theory, if the CD was made outside the USA, then it could be imported without a single problem. I'm not a lawyer. Here's my take. Let's consider that we are in Switzerland making the One Great CD that I may legally use inside of the US. (We may assume that I also may use it outside of the US, but that's irrelevant to this discussion.) While I use this CD, I'm using the RSA algorithm. This is covered by US patent 4,405,829, meaning that I have to have RSA Labs' permission to use it. I am now obligated to obtain their permission. I have their permission to use it, so long as I'm using RSAREF, and I'm using it for non-commercial purposes. So, we now have to use RSAREF. However, since we're making this in Switzerland, and RSAREF originated in the US, we (or somebody else) must have exported it from the US. We could put a non-RSAREF algorithm on it, but then I do not have RSA's permission to use it in the US. This is entirely disregarding the expense of setting up a Walnut Creek CD-ROM plant in Switzerland, or flying Jordan out of the country every time he wants to build a new release. The whole RSA scheme is bogus, because anyone in the world can get an implementation of RSA, so its widely accesible, so why all this RSAREF/non-RSAREF mumbo-jumbo? The whole RSA scheme is not entirely bogus, at least not from a commercial point of view. The RSAREF/non-RSAREF scheme is the implementation of RSA's goals within our current legal framework. Anybody who is inside the US and using RSA for commercial purposes must pay RSA Labs. That is the purpose of RSA's patent. Encouraging RD using RSA is the purpose of RSAREF. Then, people outside of the US want a way to use RSA. Because of ITAR, they can't get at RSAREF. So, that is the purpose of non-RSAREF. No doubt RSA Labs would love to be able to patent their algorithm outside of the US and export their software, but ITAR forbds it. Perhaps we should send e-mail to RSA to clarify this, and in light of this, ask for permission to distribute RSA with the base OS. Gee, we can get RSA anyway, so what's the point on making harder? RSA is not likely to be helpful. They cannot allow non-US users to use RSAREF, so the best they could do would be to allow a non-RSAREF implementation to be used in the US. That may open them up to certain legal problems, and doesn't gain them anything, so they are very likely to say "go away". Does anyone have ANY document saying that if you are in the US you are obligued to use RSAREF? Patent #4,405,829, issued 20Sep1983, availible online from the horse's mouth at http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1Sect2=HITOFFd=PALLp=1u=/netahtml/srchnum.htmr=1f=Gl=50s1='4,405,829'.WKU.OS=PN/4,405,829RS=PN/4,405,829 This means that if I'm in the US, I must have permission from RSA Labs to use the RSA algorithm. Now, there are two main ways to get permission. Either set up an agreement with RSA (and probably give them money as part of the agreement), or use RSAREF. Cheers, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped --BAC18391.951126129/detlev.piqnet.org-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rc2 install
I've come to the conclusion that the -current stuff really doesn't install on an 8 Meg machine anymore. I have an old 486/66 machine I'm using to play with the current-RC's, and it consistantly dies loading the 'bin' stuff. Perhaps I'll make a MINIGENERIC kernel without some extraneous items like NFS, etc. I can attest that 3.3 can be made to install with 8MB, albeit with some work. I've got a machine with only 8MB that can't be upgraded or replaced. It took some work to get it 3.3 to install (I think I ended up using a different installation method than I originally planned, but I forgot to document it). Anyway, I'll probably bring it to 4.0 after its release, and I'll try to document whatever I do to make it happen. Cheers, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped --BAE18391.951126130/detlev.piqnet.org-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Teergrubes [was Re: Dropping connections without RST]
process normally if the HELO and MAIL From/RCPT To look all right; otherwise continue to read small gulps of the DATA at slow intervals, then answer the final "." with a *temporary* failure code. I'd rather have spammers consume less of my CPU time and bandwidth, not have them keep coming back again and again. I suppose if you've got the computrons to waste, then it's okay. joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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: cd writer recommendation?
For backup, I bought DVD-RAM drive for $400. 5.2GB(double side) media is around $35, you can use them as 2.3GB x 2 disks. No reason to buy double-sided media; just buy single-sided and punch a hole along the edge. :-) joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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
SIGBUS [was Re: gdb]
(gdb) run Starting program: /tmp/./sieve Program received signal SIGBUS, Bus error. That reminds me. I thought that SIGBUS meant byte-alignment errors. What does it mean on FreeBSD/x86? Cheers, joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped 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: cd writer recommendation?
Isn't that the drive with the enclosed DVD disk -- kinda like a permanent caddy? I've avoided the DVD-RAM drives because of that and because the Type I(double side) is with a permanent caddy, but TypeII(single side) can be pulled out from the enclosure and supposed to be read by DVD-ROM drives. Although perhaps not by all DVD-ROM drives; the spec sheet for mine (Pioneer 303S) specifically says that it won't do DVD-RAM. joelh -- Joel Ray Holveck - [EMAIL PROTECTED] Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RE: net.inet.tcp.always_keepalive on as default ?
This wouldn't help the poor sod whose connection gets shot down every eight days while he's not there and doesn't know what hit him. If the poor sod hasn't touched his xterm for 8 days, he's either dead or he doesn't care if it goes away. Again, Matt, with all due respect, please do not post your operational habits as universals. Somebody who keeps a session to a server around so they can see syslog messages if there's a problem may have an idle connection for weeks. In case you still doubt the existance of such a person, I give you a counterexample. Having just spoken with nemo, I am quite certain that he is alive and well, and from my dealings with him have no doubt he would become somewhat miffed if I were to kill off several of his sessions. Cheers, joelh detlev$ finger n...@[deleted] [[deleted]] Login: nemo Name: Joel N. Weber II Directory: /gb/nemo Shell: /usr/local/bin/bash On since Thu Jun 03 23:49 (EDT) on tty12 days 3 hours idle On since Wed May 19 14:43 (EDT) on tty227 minutes 34 seconds idle On since Sun May 30 22:24 (EDT) on tty32 days 1 hour idle On since Sun May 30 22:27 (EDT) on tty42 days 3 hours idle On since Mon May 31 00:15 (EDT) on tty52 days 1 hour idle On since Mon May 31 16:07 (EDT) on tty62 hours 40 minutes idle On since Fri Jun 04 20:58 (EDT) on tty73 days 1 hour idle On since Fri Jun 04 22:28 (EDT) on tty13 2 days 3 hours idle On since Sat Jun 05 17:05 (EDT) on tty14 2 days 1 hour idle On since Sat Jun 05 15:25 (EDT) on tty15 2 days 2 hours idle On since Sat Jun 05 21:59 (EDT) on tty16 2 days 3 hours idle On since Sat Jun 05 22:11 (EDT) on tty17 3 days 2 hours idle On since Sat Jun 05 00:26 (EDT) on tty18 2 days 12 hours idle On since Sun Jun 06 19:15 (EDT) on tty19 2 days 1 hour idle On since Wed May 19 15:57 (EDT) on ttyp0 from xanthine:0.0 10 days 1 hour idle On since Wed May 19 15:58 (EDT) on ttyp1 from xanthine:0.0 10 days 1 hour idle On since Wed May 19 16:11 (EDT) on ttyp2 from xanthine:0.0 12 days 23 hours idle On since Wed May 19 16:45 (EDT) on ttyp3 from xanthine:0.0 15 days 21 hours idle On since Wed May 19 17:29 (EDT) on ttyp4 from xanthine:0.0 9 days 23 hours idle On since Wed May 19 17:43 (EDT) on ttyp5 from xanthine:0.0 10 days 2 hours idle On since Wed May 19 17:44 (EDT) on ttyp6 from xanthine:0.0 9 days 23 hours idle On since Wed May 19 18:09 (EDT) on ttyp7 from xanthine:0.0 15 days 21 hours idle On since Thu May 20 20:20 (EDT) on ttyp8 from xanthine:0.0 19 days idle On since Wed May 19 18:35 (EDT) on ttyp9 from xanthine:0.0 16 days 22 hours idle On since Wed May 19 21:54 (EDT) on ttypa from xanthine:0.0 20 days 2 hours idle On since Thu May 20 16:06 (EDT) on ttypb from xanthine:0.0 16 days 2 hours idle On since Thu May 20 21:05 (EDT) on ttypc from xanthine:0.0 9 days 10 hours idle On since Thu May 20 23:51 (EDT) on ttypd from xanthine:0.0 18 days 20 hours idle Last login Mon Jun 07 19:22 (EDT) on ttypf from zygorthian-space New mail received Wed Jun 09 00:29 1999 (EDT) Unread since Wed Jun 09 00:00 1999 (EDT) No Plan. -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
Most KDE programs, including the configure scripts, look for the KDEDIR environment variable. I believe that the correct thing to do with FreeBSD's KDE install is to set KDEDIR to /usr/local. I do this in /etc/profile and /etc/csh.cshrc here. (I have KDE in /usr/local/kde here, too, so I haven't tested it as /usr/local.) NO This can't be left to stand so. A port *should* set the KDEDIR to $PREFIX, not /usr/local. Just maybe I don't have my ports under /usr/local or have a separate test branch under something else? I spoke ambiguously. I did not mean that FreeBSD's KDE install should set KDEDIR to /usr/local. I meant that, if you used FreeBSD's defaults while installing KDE, then you should set KDEDIR to /usr/local in order to install other apps. --prefix specifies where it should install to. However, this app needs to find some 3rd-party include files, so --prefix is not appropriate. --prefix=($PREFIX) is definately appropriate - you signal with $PREFIX what is the root of your install to tree. If you have your ports under /opt, $PREFIX=/opt -- by default $PREFIX=/usr/local. I am referring to where to find KDE, not where to install it. I do not have KDE in $PREFIX here; apps should look in KDEDIR instead of what I set --prefix to. Normally, these are the same, but your comments about test branches etc still apply. In such a case, I would set $PREFIX to /usr/local/test while I have KDEDIR set to /usr/local/kde. An app looking for KDE in /usr/local/test would be sorely disappointed. Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
Most KDE programs, including the configure scripts, look for the KDEDIR environment variable. I believe that the correct thing to do with FreeBSD's KDE install is to set KDEDIR to /usr/local. I do this in /etc/profile and /etc/csh.cshrc here. (I have KDE in /usr/local/kde here, too, so I haven't tested it as /usr/local.) KDEDIR is depreciated. How do you mean depreciated? Should users not set it, or applications not check for it, or what? The 2.0 kdelibs/README states: IMPORTANT: most applications need KDEDIR as the directory where KDE is installed. Please set this in your login file. Of course, this could be out-of-date. I do not know of an alternate mechanism. A brief examination of the 2.0 kdebase and koffice configure.in's do not immediately reveal one either, other than --prefix. Is this the accepted method, then? What if a user wants to install something in a different place than the rest of KDE? --prefix specifies where it should install to. However, this app needs to find some 3rd-party include files, so --prefix is not appropriate. Uh no. The prefix is also used by the configuration script to figure out where the kdelibs were installed to. From configure: I apologize, I did not examine the source before I spoke. I will maintain that --prefix is, in general, a target specifier rather than a source specifier. In the case of the configure script you quoted (and probably all KDE configure scripts), and if they coincide (as they usually will), then --prefix will DTRT. Which configure script did you take this from? I see the same code in many bits of KDE itself. Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
But remember that the idea is the keepalive would keep trying for a certain amount of time, and this would be finely configureable. Adjusting the keepalive's retry period after activation is also irrelevant. As they currently stand, keepalives operate in virtually [snip] I don't see why this is a point of discussion. The keepalive timers are all configurable via sysctl. Is this mechanism being considered as insufficient? Unless the entire purpose of the connection is to simply be connected, with no data flow ever, being able to finely tune keepalive values does not really help. The existing rough tuning is as much as anyone will ever need to mess with. With all due respect, Matt, the second biggest lesson my time with computers has taught me is to never think that X will be enough for all needs. 640k, 32 bit IP addresses, two-digit years, Ada, non 8-bit-clean text utilities, one-second granularity in the filesystem timestamps, yada yada. (Note that I have no objection to saying that we don't see a need to implement it at present. In this case, I sure don't see such a need, but I'm willing to be given a counterexample. We're not looking at making it impossible-- or even difficult-- to implement other keepalive timing strategies in the future, if the need arises, so I would suggest that we not concern ourselves with this discussion until the need arises.) Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
I don't know what's worse; that Microsoft themselves can't keep Windows running for 50 days, or that they're incapable of manually bumping the counter to a value close to UINT_MAX and wait a few minutes for it to roll over. What's worst is probably that the bug doesn't affect operation. Nobody I've talked to has ever seen a Windows 95 machine stay up for over a week or so, let alone a month. joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
The central issue of keepalives is that, for one machine, they don't create a significant load. Multiplied by the number of machines on the Internet, it can become a problem. Divided by the combined bandwidth of the networks these machines are using, it ceases to be a problem. joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
4. It would be desirable to have per socket timeouts, but would require application changes which are unlikely to happen. Huh? I was just considering writing the patch for this. What application problems would this create? The worst thing I can see is that it would mean that changing the timeout value on a running system wouldn't affect already opened sockets. Even that may be changable by an external utility if I can think of a way to handle the locking in userland. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
This wouldn't help the poor sod whose connection gets shot down every eight days while he's not there and doesn't know what hit him. One thing that no one points out is that this idle connection is potentially a security threat. Even if the physical connection is iced and is reconnected later using the same IP and the TCP connection is restored because it was kept alive, this presents a whole new world of interesting exploits. It's non-trivial, but that doesn't stop people like Network Associates' Labs from publishing papers on the subject. Keepalives are not particularly useful against connection hijacking, as far as I can tell, except perhaps that a keepalive packet may disclose the current TCP sequence number to the new assignee of a dynamic IP. (This, of course, presents an argument for the opposite stance.) As near as I can tell, you're saying that if a transient outage is restored, then after it's restored, an idle connection may be used by an intruder. How does the transient outage affect this? If the transient outage has the side effect of changing routing, then an attacker (or somebody else) is moving cables around, or a dynamic link with a dynamic IP is being changed. In the former case, then the long delay between keepalive packets should not make them a valid protection. (If it takes an attacker more than a week to move a cable, then may I suggest your attacker needs to refine his technique.) In the latter case, then the attacker who now holds the destination IP can respond to the keepalive packets masquerading as the legitimate recipient as easily as they can do any other work involved in hijacking your connection. If the outage did not cause a reconfiguration, then the attacker generally has no different access to your network than before, and no more means to hijack an open connection than before. I've got some whiskey in me right now, so I may be unclear on what you're saying. Am I missing something here? Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: KDE programs won't compile
I can only assume that we install our KDE headers somewhere different than the developers (primarily on Linux machines). By default, KDE installs to /usr/local/kde. On RedHat, the RPM installs it to /opt/kde. All the includes are in /usr/local/kde/include, the libs in /usr/local/kde/lib, etc. where the headers are on the FreeBSD machines and then you'll have to probably add a configure argument like: --with_kde_includes= /some/dir/where/kde/includes/are Most KDE programs, including the configure scripts, look for the KDEDIR environment variable. I believe that the correct thing to do with FreeBSD's KDE install is to set KDEDIR to /usr/local. I do this in /etc/profile and /etc/csh.cshrc here. (I have KDE in /usr/local/kde here, too, so I haven't tested it as /usr/local.) Yes, for better or for worse (I'd vote for worse), the FreeBSD ports install the kde headers in /usr/local/include.. However a simple --prefix=/usr/local *should* fix any configure problems, and if this is to make it into a FreeBSD port, use --prefix=$(PREFIX). --prefix specifies where it should install to. However, this app needs to find some 3rd-party include files, so --prefix is not appropriate. FWIW, I've found that using /usr/local/kde instead of /usr/local has, in my case, been most helpful. I don't advocate it for every tiny library, but for something as large and complex as KDE, it works well. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: Mmap problem in -current?
I just noticed (kernelworld from friday) that locate always cores dump: $ locate xxx Segmentation fault (core dumped) The problem disappears if I recompile locate without the -DMMAP option. Running on the very latest current, it does not work for me. By 'it', do you mean that locate does not work, that the failure test does not work (ie, locate is fine for you), or that the workaround does not work? Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
mount_mfs panics (Was: ``65536-byte tape record bigger than suplied buffer'')
Well, I'll recheck mine... It'd be interesting to see if you (and others) can reproduce this too. Using a May 17 15:00 CDT -current, I also have gotten a panic mounting MFS. The line from fstab is: /dev/da0s2b /tmpmfs rw 0 0 I commented it out, and things work fine. Since no dumpdev was configured yet, I don't have a dump, but can try to produce one now if somebody would find a backtrace useful. Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
I've found where this problem is coming from. It's in emacs20.3/src/s/freebsd.h. It sets a macro called BSD_SYSTEM based upon the version number contained in __FreeBSD__, checking for 1, 2 and 3. Of course, -current uses 4. I have found that you can check for __FreeBSD__ = 3, and it will work, but this feels a bit like a hack. I've never updated a port, so I can either get some instruction from someone to put in a patch, or let someone else do it. I'll make the patch if a committer can get it in. -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: -jN make world
I think I may have fixed the problem in the Makefile... well I might have fixed another smaller problem, but it is now more broken than before and -jN should work. If it's not yet fixed, why don't we add something to the buildworld target that checks MAKEFLAGS for -j and issues an error or warning if it's found? -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: emacs* broken in -current (was Re: Vtable thunks with egcs)
You are absolutely right. I just tried the new version of emacs that I built on my pre-egcs box and it doesn't work on that box either. This definitely doesn't appear to be anything caused by changing to egcs. Not that it matters much but for grins I just built/installed the xemacs port and it _does_ appear to work. I've been having no problems with an Emacs 20.3 and X11R6 built in October on a -current system from April 6. (The Emacs is ELF, and built from my own sources instead of the port.) I'd like to track this down; could people give me more info privately? rms is looking at releasing a mostly bugfix Emacs, possibly tommorow, but it may be another month (he's about to leave town). I haven't been watching the changes; there may be some X-related fixes in there. Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: EGCS breaks what(1)
'what' is broken. C does not impose any sort of address ordering restriction on globals or autos that are declared next to each other. Right, except that 'what' isn't broken. It is vers.c (and conf/newvers.sh) that is broken, believing that the two variables will be allocating in contiguous memory. Changing newvers.sh to generate char sccs[] = @( #) FreeBSD ...; char version = FreeBSD ...; I will assume you meant char *version here. will make what on the kernel work again, at the expense of about 100 duplicated bytes. Check me if I'm wrong, but could we not do the same thing without the duplication: char sccs[] = @( #) FreeBSD ...; char *version = sccs + 4; Happy hacking, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
gcc build count
How many times does gcc get built in a make buildworld? I had assumed only twice, is this wrong? Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!! NOAOUT `make world' knob changed
I have just changed made a change concerning the building of legacy a.out bits during `make world'. Previous to my change, one would define NOAOUT to keep from building the legacy a.out bits. Now one would define WANT_AOUT to build them. The default of building a.out bits gets in the way of some other changes I will make to the `build world' process soon. Will WANT_AOUT be considered a supported option? That is, if I choose to build a.out libraries, will I be giving up the right to gripe when `make world' breaks, and be resigned to the ranks of the NOCLEAN masses? Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
syslogd meets The Sorcerer's Apprentice
I'd like to add safeguards to keep syslogd from cascading its own error messages. To describe more fully: I just came back from a weekend getaway and discovered my crash box screaming bloody murder. I haven't had any odd experiments running for quite some time now. A quick look at the top of /var/log/messages.0 showed: Mar 18 00:00:00 detlev newsyslog[543]: logfile turned over Mar 21 15:44:25 detlev syslogd: /dev/ttyv1: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyv2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp0: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp3: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/console: Too many open files in system: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyv1: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyv2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp0: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp2: Too many open files in system Mar 21 15:44:25 detlev syslogd: /dev/ttyp3: Too many open files in system Mar 21 15:44:25 detlev /kernel: file: table is full Mar 21 15:44:25 detlev last message repeated 41 times Mar 21 15:44:25 detlev sendmail[17482]: PAA17481: SYSERR(UID0): Can't create transcript file xfPAA17482: Too many open files in system Mar 21 15:44:25 detlev sendmail[17482]: PAA17481: SYSERR(UID0): Can't open /dev/null: Too many open files in system Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev /kernel: file: table is full Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev last message repeated 3 times Mar 21 15:44:26 detlev /kernel: file: table is full Mar 21 15:44:26 detlev syslogd: /var/run/utmp: Too many open files in system Mar 21 15:44:26 detlev last message repeated 3 times After that it settled down to just repeating: Mar 21 15:45:30 detlev syslogd: /dev/ttyv1: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyv2: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyp0: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyp2: Too many open files in system Mar 21 15:45:30 detlev syslogd: /dev/ttyp3: Too many open files in system Mar 21 15:45:30 detlev /kernel: file: table is full Evidently it was recording about 125 log messages per second. I came home to discover a full /var, a 25 MB uncompressed messages.0, no /var/log/messages at all, and overall a fairly unhappy computer. (Evidently, when newsyslog ran, things were already hosed. It could move messages.0, but not gzip it or create /var/log/messages.) This is all from a March 13 build, I believe, if it matters. MAXUSERS is set to 20, and there were probably six logins including a small X session at the time. All had been idle for hours. (I figure something was leaking fd's bad.) Now, I don't know what set this off. I moved the messages.0 to another filesystem, rebooted, recreated /var/log/messages, and restarted syslogd. Like I say, I don't know what set this off. That's once concern, but will take more investigation. My concern is whether we should keep syslogd from going into Sorcerer's Apprentice mode like this. What do you think about adding safeguards against syslogd logging more than, say, thirty messages per hour saying why can't log messages? Cheers, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS Problems
This reminds me; do we have a utility to reference wmesg strings back to the code that sets them, a la TAGS? Would this be useful? No, and yes respectively. Okay, I've got an early version written. It's got some fairly substantial TODO's, and needs a fair bit of cleanup. I would appreciate any comments anybody has. -cut here- #! /usr/bin/perl -w # Copyright (c) 1999 Joel Ray Holveck. All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright #notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright #notice, this list of conditions and the following disclaimer in the #documentation and/or other materials provided with the distribution. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $Id$ # NAME # wtags - generate wchan tag file # # SYNOPSIS # wtags [-cegw] [-v] [path] # # DESCRIPTION # wtags scans a 4.4BSD kernel source tree and creates a database # listing all the wchan's which are explicitly specified to # tsleep(9) or similar functions. This is useful for identifying # where in the kernel a process may be hung. # # The source tree to be searched may be specified with path, or # the current directory is used. Subdirectories are always # scanned, and symbolic links are always followed. # # The options are as follows: # # -c Generate ctags(1)-compatible output. Output is appended # to the file tags in the current directory. This file # is typically used with vi(1). # # -e Generate etags(1)-compatible output. Output is appended # to the file TAGS in the current directory. This file # is typically used with Emacs(1). # # -g Generate gtags(1)-compatible output. Output is appended # to the file GSYMS in the current directory. This file # is typically used with the global(1) tags system by # Shigio Yamaguchi, which may be used with vi(1), Emacs(1), # or other systems. # # -w Generate a native file format (described below). This # format is designed to be easily read by humans or machines, # but no utilities currently use it. -w is the default if # no other output format is specified. # # -v Generate warnings for many cases when a possible call to # tsleep(9) or a related function is found, but a wchan # could not be isolated. There are normally many of these # in correct code; one version of wtags produced 83 such # diagnostics on the 4.4BSD-Lite kernel. See DIAGNOSTICS, # below. # # wtags will only recognize string literals for wchan arguments. # A function (such as lf_setlock) which uses a string constant # instead, or one (such as ttread) which uses one of a few known # possibilities selected via :? or another mechanism, may have a # comment such as /* WCHAN: lockf */ on the line in question. # wtags will then use the indicated channel, and ignore any tsleep # call on that line. # # FILES # /sysTraditional kernel source location # WTAGS Default output file, used with -w or if no other # tag file is specified # TAGSEmacs(1) tags output file, used with -e # tagsvi(1) tags file, used with -c # GSYMS global(1) tags file, used with -g # # DIAGNOSTICS # If the -v option is specified, then whenever tsleep (or another # function that uses wchan) is written in the source file, but no # wchan can be found, a diagnostic is printed. These diagnostics # do not always properly describe the issue. # # There is one exception to this: if the item appears to be a # reference to tsleep from within a comment (using a heuristic), # then no diagnostic is printed. # # SEE ALSO # ps(1), etags(1), ctags(1), global(1), tsleep(9), glimpse(1) # # NOTES # wtags was designed under FreeBSD. Any
Re: NFS Problems
This reminds me; do we have a utility to reference wmesg strings back to the code that sets them, a la TAGS? Would this be useful? No, and yes respectively. I have the scanner mostly written; there is one bug yet to fix (This time for sure!). Presently, it creates a single file WTAGS which contains an easily-read (my man or machine) flat file index. I will presently be modifying it to generate Emacs's etags format, as well as ctags, and as soon as I learn it, GSYMS format. At the moment, the scanner scans tsleep, asleep, and ttysleep calls. What other sleep functions can have the wchan specified as a string literal? There being no robust manner to handle calls with a computed or dereferenced wchan, such as acquire(), I will allow for a notation of /* WCHAN: foo */ to cause the appropriate information to be added to the database. Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: NFS Problems
The program on the client side always freezes (top reports it's STAT as 'D'). You need to pass the 'l' switch to ps and look at the 'wchan' column to see where it's actually stuck. This reminds me; do we have a utility to reference wmesg strings back to the code that sets them, a la TAGS? Would this be useful? Thanks, joelh -- Joel Ray Holveck - jo...@gnu.org Fourth law of programming: Anything that can go wrong wi sendmail: segmentation violation - core dumped To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
