Re: How to fix this in 5.1-REL??
On (2003/11/24 15:39), Kevin Oberman wrote: > > > I end up with the following when I run `make world` on 5.1-RELEASE-p10. > > > > Did you read UPDATING? > > I fear a bikeshed, but I really think it may be past time to remove > the 'world' target from /usr/src/Makefile.inc1. It is rarely useful > and only should be used by those who understand the process and know > that it is safe. Removing it would remove a clear way to shoot one's > foot and would really have trivial impact on those who use it > properly. I agree. The job requires quite a lot of documentation work, though. If you can get buy-in from the doc project folks, I doubt you'd meet with serious objections from src people. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unattended reboot was Re: signal 12's everywhere on Currentwith update this morning.
On (2003/11/13 14:02), Eric Anderson wrote: > I'm not having any luck - I'm started to feel like I'm missing something > here :) > > I cvsup'd yesterday afternoon, and did my usual make buildworld, kernel, > install kernel, single user mode, then make installworld - except it > bombed on the installworld. I ignored the message moved on. You missed a step. The HEADS UP sent to -current said you needed to reboot between kernel install and world install. This is the strictly safe way of upgrading always. However, many people skip the reboot (and even the drop to single-user mode) as a shortcut. Sometimes, the shortcut works. This time, it doesn't. :-) Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ALTQ support
On (2003/11/10 11:35), Alexander Leidinger wrote: > > Is there any plan to make it into the kernel ? > > AFAIK the author of ALTQ said we shouldn't import it. Search the mailing > lists @FreeBSD.org for the reason. If anyone finds that message in the archives, please post a URL. I can't find it in -current or -arch, and I'd really like to know what the motivation was. Thanks, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: More ULE bugs fixed.
On (2003/11/04 15:46), Jeff Roberson wrote: > > The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to > > look for a cause for that specific problem in ULE. > > How long have you been seeing this? Are you using a usb mouse? Can you > try with PS/2 if you are? Since my last update, Fri Oct 24 17:47:22. I am using a USB mouse, but don't have a PS/2 one. I'm also using moused, and my WM is sawfish. The problem with all these reports is that they're scattered. It's hard to pin down exactly what the common elements are. Indeed, we may be looking at combinations of elements. I don't have time to be more helpful, which is why I hadn't complained. I just wanted to include the datapoint that over-active mouse behaviour under load exists under SCHED_4BSD as well. Incidentally, this is under ATA disk load. I don't really push my CPU. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADSUP: if_xname changes incoming
On (2003/11/03 13:38), Brooks Davis wrote: > I've sent mail to both his FreeBSD address and the one on the IPFilter > homepage. If anyone knows a reliable way to communicate with him, that > would be useful. The latter address works, but he's terrible with email, by his own admission. If you don't get an answer in a couple of days, send a nag mail; he's okay with that. :-) Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: More ULE bugs fixed.
On (2003/11/04 09:29), Eirik Oeverby wrote: > The problem is two parts: The mouse tends to 'lock up' for brief moments > when the system is under load, in particular during heavy UI operations > or when doing compile jobs and such. > The second part of the problem is related, and is manifested by the > mouse actually making movements I never asked it to make. Wow, I just assumed it was a local problem. I'm also seeing unrequested mouse movement, as if the signals from movements are repeated or amplified. The thing is, I'm using 4BSD, not ULE, so I wouldn't trouble Jeff to look for a cause for that specific problem in ULE. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sched_Ule
On (2003/10/09 16:57), Jeff Roberson wrote: > > For me, the sluggish mouse problem manifests under these conditions: > > > > 1) Use a USB mouse, not a PS2 mouse. > > Is this _only_ with usb? For me, yes. -CURRENT gets a little sluggish with either scheduler, but the noticible difference between SCHED_4BSD and SCHED_ULE only strikes me with a USB mouse. YMMV. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sched_Ule
On (2003/10/09 00:28), Scott Sipe wrote: > Anything that seems disk intensive: bzip2 (unbzip2ing one big file makes > this happen), making world, building ports, etc makes my X environment > practically unusable. Mouse stutters, reaction times is very slow, feels > 10x more sluggish than normal. (I'm running KDE if anyone is curious). A number of us are seeing this problem, and not all of us are entry level end-users. I'm using a single PIII with 1GB of RAM and maxusers 0. No Hyper-threading, nothing interesting in the kernel (apart from I686_CPU only, KTRACE and _KPOSIX_PRIORITY_SCHEDULING). The problem (as I recall) is that Jeff hasn't received reports from people who can dig into the problem and have the time to do so. For example, I'm pretty sure I could at least point a finger at the problem if I had time. But I'm under heavy pressure, and so the only solution that's feasible for me is to just switch to SCHED_4BSD and keep moving. What surprises me is that Jeff can't reproduce it. For me, the sluggish mouse problem manifests under these conditions: 1) Use a USB mouse, not a PS2 mouse. 2) SCHED_ULE in the kernel. 3) make buildworld (no -j necessary, but -k exacerbates the problem). 4) Fiddle around in X (no particular window manager required). Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On (2003/09/24 20:18), John Birrell wrote: > > Okay, so what are we supposed to do to ports that are now broken because > > -pthread doesn't exist (e.g. devel/pwlib)? > > -pthread is back in current. It just had a little holiday. It's back, > refreshed, eager and willing to do the deed. 8-) That's really, REALLY good news. Will Andrews recently posted a patch on -current and mentioned that -pthread is back but will go away again soon. Can I relax and disregard his comment? :-) > > Is there a simple rule we should follow when trying to fix ports, or do > > we have to think now? > > Someone has to think and make a decision. Is simplicity (the -pthread switch) > reason enough to support one thread library by default? I'm happy with -pthread providing a simple default, which I can override if I think I know what my software really wants. :-) Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing -pthreads (Re: ports and -current)
On (2003/09/23 19:35), Daniel Eischen wrote:
> The applications is free to link to whatever it wants;
> we're not changing that. If it wants to link to 1:1
> libthr or whatever, then it had better be sure to use
> -lthr because -pthread won't do it regardless of whether
> it is a NOOP or not.
Okay, so what are we supposed to do to ports that are now broken because
-pthread doesn't exist (e.g. devel/pwlib)?
This discussion has gone around in circles and I haven't read every
message, but it's pretty obvious there's a lot of confusion.
Is there a simple rule we should follow when trying to fix ports, or do
we have to think now? At the moment, I'm just patching configure files
to use ${PTHREAD_LIBS} instead of -pthread, and pushing PTHREAD_LIBS
into the ports' CONFIGURE_ENV.
Ciao,
Sheldon.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Text file busy
On (2003/09/04 14:44), Paul Richards wrote: > Overwriting a file that's currently executing results in a "Text file > busy" error. > > When did this start happening? > > This was something that was fixed way back on FreeBSD but it seems to be > a problem again. Really? I've never seen it "fixed". I've occasionally hit this problem upgrading perl and exim for as long as I can remember. Ciao, Sheldon. -- http://starjuice.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /lib symlinks problem?
On (2003/09/02 09:43), Ian Freislich wrote: > > I posted one approach to this today... touch a file right before you > > start installworld, then consider anything not newer than that file a > > candidate for disposal. There is currently something weird going on in > > /usr/lib though... a lot of the files don't have newer dates, I haven't > > tracked down why yet. > > That's because bsd.lib.mk and bsd.own.mk hardcode '-C' for install. Which a few of us have complained about and subsequently settled on local patches for. :-( Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld failure
On (2003/08/29 11:48), Robert Watson wrote: > The differences here seem to be: > > (1) I'm using -O, not -O2 > (2) I'm optimizing -mcpu as pentiumpro, not pentium4 Isn't pentium4 a known-broken optimization at the moment? Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld failure
On (2003/08/29 11:41), Mike Jakubik wrote: > Yes, I can see that its not working. But this is a solution to the cause, > not the problem. Shouldn't this be fixed? Depends on how much work is involved in fixing it, and what the negative impact is of leaving it. Do you know what the impact is? > > Okay, you philosophize while the rest of us follow the advice of the > > folks who have a good understanding of gcc's optimizer. :-) > > Are you saying this is a bug in GCC and not the PAM code? Quite possibly. But until it's clear that -O2 produces significantly better compiled code, why worry? We've got _much_ bigger fish to fry. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: buildworld failure
On (2003/08/29 11:30), Mike Jakubik wrote: > Why should I have to turn off all my optimization options when building > world? Because it's not working? Mind you, it's only -O2 that you're recommended to turn off; -O works fine. > This shouldn't be like that. 4.x always compiled fine with -O2 and > CPU options. Okay, you philosophize while the rest of us follow the advice of the folks who have a good understanding of gcc's optimizer. :-) Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
libmap.conf kudos
Hi Matthew, Dude, your libmap.conf work ROCKS! Finally, a painless way to play around with the impact of various threading implementations on Java without tearing any hair out over symlinks and such. Thanks! Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Does linux-sun-jdk_1.4.2 work?
On (2003/07/21 23:41), Adam wrote: > Perhaps you should try working with Java 1.4.x on FreeBSD before you > assume something about me that's highly inaccurate. I think you'll find > very quickly that it doesn't work nicely unless the process is running > as root. So that this doesn't stick in people's minds as the status quo, let me just add that several of us are very happy with the native jdk14 port on FreeBSD, both -CURRENT and -STABLE. However, this kind of discussion (sans Mr Migus unacceptable rudeness) would be more valuable on the freebsd-java mailing list. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Resource temporarily unavailable'' in vi
On (2003/07/15 13:35), Byron Schlemmer wrote: > Being the curious person that I am, I tried the following from the truss > manpage : > > % truss /bin/echo hello > truss: cannot open /proc/1805/mem: No such file or directory > truss: cannot open /proc/curproc/mem: No such file or directory > > Is this expected behaviour on -CURRENT or is it just me? It's expected if you don't have a process filesystem mounted on /proc. kldload procfs mount_procfs /dev/procfs /proc Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: APM problem in 5.1-RELEASE
On (2003/06/19 20:06), Tobias Roth wrote: > you compare a stable linux kernel branch with an unstable freebsd branch. > please make yourself familiar with freebsds (and possibly linux') release > process before you make statements like this. you will only piss off the > people that are trying to help you. While I understand the desire to "protect FreeBSD", I don't think you're being fair. Jesse was providing useful information, and drew logical conclusions from it. If he'd said "and therefore you're all a bunch of arseholes", then it might be time to wag a finger. But so far, I think Jesse has been pretty reasonable. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Native JDK with libthr/libkse
On (2003/06/01 23:53), Narvi wrote: > > The absence of credible Java support in FreeBSD has lost us significant > > penetration in the past, and it would be disastrous if the perceptions > > of the past shaped the future. > > credible rather sounds like 'comes on the installation cd, doesn't have > significantly more bugs than linux/solaris/xxx version' 8-( And I think we'll get there. I'm currently doing some Java development on a FreeBSD-CURRENT workstation using a native jdk14. It's good enough for testing components in a J2EE application server (JBoss), and performance is comparable to that seen on an equivalent Windows workstation. Would I use FreeBSD as a production J2EE server reliant on 1.4.1? No. But the time is coming, so don't write FreeBSD off just yet. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Native JDK with libthr/libkse
On (2003/06/01 00:50), Daniel Eischen wrote: > > I just built jdk13 a couple of days ago. No problem whatsoever. You > > guys must have rotten karma or something. > > Did you already have a native JDK installed? I built the native 1.4.1 JDK two weeks ago, first without the native JDK for bootstrapping, and then with the native JDK. Both worked without a hitch. If you're having problems with the build, your input would be appreciated on freebsd-java. The absence of credible Java support in FreeBSD has lost us significant penetration in the past, and it would be disastrous if the perceptions of the past shaped the future. FreeBSD now has some seriously committed Java people working hard on the port, and it'd be a shame if they didn't get to hear about the problem you've encountered. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libthr and 1:1 threading.
On (2003/04/02 07:38), Terry Lambert wrote: > Is the disk I/O really that big of an issue? All writes will > be on underlying non-blocking descriptors; I guess you are > saying that the interleaved I/O is more important, further > down the system call interface than the top, and this becomes > an issue? Dude, you should really try this stuff for yourself before naysaying performance improvements on principle. It's actually quite impressive for desktop users (at least). Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: breakage this morning
On (2003/04/02 09:43), Michael W . Lucas wrote: > > You sure you didn't get caught in the middle of a cvsup mirror sync? I > > have an IP_EVIL world and kernel running fine here. > > According to some folks on IRC, it was renamed to "IP_EF" in > src/sys/netinet/ip.h, but not renamed in ping.c. > > I just finished re-supping from cvsup16, and while I got some updates, > an update to ping_c was not among them... Ah, so it's me who got lucky, not you who got unlucky. Sorry. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: breakage this morning
On (2003/04/02 09:20), Michael W . Lucas wrote: > While I'm all for a sense of humor, and agree that implementation of > the IP_EVIL flag is vital for FreeBSD to be a modern operating system, > it stops being funny when it breaks world. You sure you didn't get caught in the middle of a cvsup mirror sync? I have an IP_EVIL world and kernel running fine here. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: libthr and 1:1 threading.
On (2003/04/02 06:05), Terry Lambert wrote: > > I think Jeff (or someone else?) said, that some web browsers gain > > "something" too (serialization issues with libc_r)? I had the impression > > that this also applies to UP systems. > > > > Do I misremember this? If not, does it not apply to UP systems as well? > > FWIW: the libc_r reentrancy isn't fixed by a 1:1 model for > anything but calls for which there are no non-blocking > alternative kernel APIs. [...long ramble...] For all the rambling, I'm happy to report that my SCHED_ULE + libthr UP workstation feels noticibly more responsive when I have several Mozilla tabs all loading pages simultaneously while I'm trying to make a threaded Java IDE do something sensible. It's possible that I'm actually seeing the impact of other changes that have been committed in the last week, I suppose. Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE nice behavior fixed.
On (2003/04/02 21:48), Bruce Evans wrote: > > Some of us have been waiting for that behaviour for a long time (long > > before you started working on ULE). > > Er, this is the normal behaviour in FreeBSD-3.0 through FreeBSD-4.8, > so you shouldn't have waited more than negative 4 years for it :-). > The strict implementation of this behaviour in these releases causes > priority inversion problems, but the problems apparently aren't very > important. The scaling of niceness was re-broken in -current about 3 > years ago to "fix" the priority inversion problems. I should have realized that "a long time" would mean different things to different people, with respect to HEAD. I remember being involved in a flamefest on this issue a few years back. You were involved too. :-) However, are you sure the "nice 20 only gets unwanted CPU" behaviour is actually what you get in RELENG_4 (as opposed to your heavily patched version)? Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ULE nice behavior fixed.
On (2003/04/02 01:54), Jeff Roberson wrote: > It probably still needs some tweaking but it seems to be MUCH better now. > New algorithm entirely. > > nice +20 processes will not run if anything else wants to. Some of us have been waiting for that behaviour for a long time (long before you started working on ULE). Thanks very much! Ciao, Sheldon. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Debugger("panic") on reboot
On (2003/03/19 20:43), Andrew Mace wrote: > Thanks for Your reply. Your right, I'm in the wrong league here :-). I had > 5.0 RELEASE installed before, but the jdk1.4 port wouldn't compile and there > is no binary package. But now that I have it compiled and packaged can I just > install it on 5.0 RELEASE or even 4.7 STABLE? No. The native jdk1.4.1 depends on a threads support change in libc that was committed after 5.0-RELEASE. You _really_ don't want to upgrade libc to 5.0-CURRENT without upgrading the rest of the system. You could, however, just apply the patch concerned [1] and rebuild world from the 5.0-RELEASE sources. Personally, I'd just update to -CURRENT and enjoy a host of bugfixes, at the risk of catching it at a bad time. You can minimize that risk by using the same FreeBSD source that you used to produce the host environment that successfully built the java/jdk14 port's package, because you've seen it in action. Ciao, Sheldon. [1] You'd have to hunt the freebsd-java mailing list archives for "the libc_r patch", which shouldn't be too hard to find. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PLEASE TEST - ATA driver patch (ATANG)...
On (2003/02/13 14:00), Soeren Schmidt wrote: > I've prepared a patch that brings the ATA driver to the next level. You've brought ata in under cam? ;-) *duck* Sorry, couldn't resist. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Seat-belt for source upgrades from stable to current
Hi folks, Can anyone think of a good way to implement an installworld / installkernel seat-belt for source upgrades from stable to current? What I'm looking for is a way for installworld and installkernel in the current source to look for some signature in the target filesystem that suggests that a stable world is about to be upgraded to current. I want this because far too many people, far too frequently, update their source to HEAD by mistake and then end up with current when they really wanted stable. [1] If this can be done cleanly, I'd like to do it. If not, I don't want it to be a hack. So, ideas on infallible signatures? Ciao, Sheldon. [1] Guess who just trashed a stable installation for the 3rd time in 3 years today? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: OpenOffice swriter working on -CURRENT
On (2003/01/20 11:04), Martin Blapp wrote: > http://people.freebsd.org/~mbr/ports/openoffice-port-1.02.tgz > > There is one bug (crash) which I'd like to have fixed before I > update the port. And OpenOffice.org needs to announce OpenOffice.org > version 1.02 officially. > > Maybe you don't have procfs running ? The old packages still needs > procfs, and crash without it. The new version (also the one in cvs > doesn't need it. I have procfs running. Given your feedback, I'll assume I just have a too-old version installed. I'll wait for an updated package. Thanks again for taking this on and making packages available, by the way! Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
OpenOffice swriter working on -CURRENT
Hi folks, Could someone with an up-to-date -CURRENT (as of anything since Wednesday last week) and OpenOffice let me know whether OpenOffice's swriter works? For me, works just implies that it starts up on a blank document before core dumping, and then accepts at least one character of input. Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD 5.0 RC3 now available
On (2003/01/14 10:22), local.freebsd.current wrote: > >In the meantime we _really_ have to ship 5.0-RELEASE, we keep > >slipping it. > > That sounds like "it's time to ship so we're going to ship". > > I'm not trying to get up anyone's nose here, but aren't there > objective release criteria? Yes. One of the release criteria is that it come into existence. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: world broken at libkvm
Make sure you have rev 1.289 of sys/sys/proc.h, which is expected to fix the problem you're reporting. Ciao, Sheldon. - Original Message - Date: Sun, 12 Jan 2003 18:14:51 -0800 From: walt <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: world broken at libkvm > cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o > /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': > /usr/src/lib/libkvm/kvm_proc.c:376: structure has no member named `ke_pctcpu' > > > 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: The great perl script rewrite - progress report
On (2002/12/01 19:36), Kris Kennaway wrote: > > /usr/bin/mmroff > > /usr/bin/afmtodit > > > > /usr/sbin/adduser > > /usr/sbin/rmuser > > These must be converted before 5.0-R. Unless we make installation of the perl package happen automatically as part of sysinstall. I spent an hour looking at sysinstall and got a head-ache. I'm not saying that this is a preferable solution, just a solution that we know will definitely work, while new C versions of these utilities don't have much time to get tested. Remember that we didn't remove Perl from the base system because we didn't think FreeBSD should ship with it; we had other reasons that related mostly to maintenance. These issues are not tickled by a package install. Of course, someone would actually have to work past the head-ache and produce a working patch for sysinstall. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cbb0: unsupported card type and reboot
On (2002/11/20 11:00), Chris Howells wrote: > I'd love to... sadly I do not know how to. I've only been messing > around with FreeBSD for around a week (though I'm experienced with > Linux, but getting bored of it) and am trying 5.0 because 4.7 locks up > when I try to access my PC Card (maybe CardBus) modem. Not to discourage you from trying 5.0, but I had this problem with 4.7; my laptop would "lock up" on boot if I had my CardBus modem inserted already. When this lockup happens, I just eject and reinsert the card, and the machine continues the boot. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make.conf and make.conf(5)
On (2002/11/19 15:17), Carl Schmidt wrote: > The following PR has two patches attached which address the lack of some > documentation of make.conf in the manual page. It also contains a patch > for make.conf to fix style inconsistencies and two (if I recall > correctly) items which are documented in the manual page but did not > exist in the example conf. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=45470 I see that Tom Rhodes has taken this one. Tom, I like this patch. When you commit it, please tidy up the new description for MAKE_SHELL, which I think is a bit more chatty than necessary. :-) Thanks, Carl. This work is always a pain in the butt to do, but readers of the manpage get very frustrated if it isn't done. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/15 14:45), Vallo Kallaste wrote: > Yes. For what it's worth, I think that system should be airtight out > of the box and the consequences for average desktop user (as I am) > clearly documented in handbook. Users who will not read the fine > documentation fully deserve the pain. Well, in the case of being able to write to the CDRW, that's only true because sysinstall doesn't ask you whether this is a multiuser or single-user machine. One day, when sysinstall makes that distinction, it can add more permissive rules to the file that devfs(8) reads on startup if the operator indicates that the installation is for a single-user workstation. By then, I'm sure we'll be running devfs(8) on startup. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/15 09:48), Soeren Schmidt wrote: > > Don't you think it makes more sense for the kernel to start off with > > more restrictive permissions, and have the administrator determine > > whether more restrictive permissions are appropriate? > > Actually no I dont. > The security aware admin will know (or should that be "should know" :) ) > what to do to make a system secure. > The avarage user that uses FreeBSD dont, and will get confused if the CDROM > device doesn't appear to work (ie writeprotected). Well I think this goes against the grain of much of the work that's happened recently. Look at how sysinstall now defaults to installing an inetd.conf with no services enabled. Look at how sshd doesn't allow root login or empty passwords by default. Look at how IPFW defaults to deny all. Look at how the floppy drive is inaccessible to anyone but root by default. And so on and so forth. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: /dev/acd*t* no longer available in -current?
On (2002/11/14 19:27), Soeren Schmidt wrote: > > - insecure permissions. Among other holes, these allowed the world to > > erase cd-rw's. > > Use rc.devfs for that as it was intended. Don't you think it makes more sense for the kernel to start off with more restrictive permissions, and have the administrator determine whether more restrictive permissions are appropriate? I think this approach is much more in line with "the Unix way". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sleep(1) behavior
On (2002/11/13 15:06), Dag-Erling Smorgrav wrote: > > I think it's pretty clear that negative time arguments to sleep(1) are > > not portable. > > I have, somewhere in my big bag of tricks, an unfinished patch which > would allow us to implement negative sleep times by directing the PSU > to emit positrons instead of electrons for the required period of > time, thereby causing the system to run backward in time. For the love of dog, whatever you do, just please make sure it works when kern.turbo is not set. It's all very well adding new features, but you need to consider folks who're still using perfectly legitimate legacy configurations. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sleep(1) behavior
On (2002/11/12 16:37), Nate Lawson wrote: > I've found an interesting contradiction and was wondering what behavior > sleep should have. It checks for a command line flag with getopt(3) and > exits with usage() if it finds one. However, it then checks for a '-' or > '+' sign. If negative, it behaves like "sleep 0" and exits > immediately. This case can almost never be triggered since the > getopt(3) will catch the minus sign, even if a digit follows it. > > Current behavior: > sleep 0 = exits immediately > sleep -1 = exits with usage() > sleep -f = exits with usage() > sleep " -1" = exits immediately and is the only way I know to trigger > the negative case. > > What is the standard, desired behavior? IEEE Std 1003.2-1992 says: timeA nonnegative decimal integer specifying the number of seconds for which to suspend execution. I think it's pretty clear that negative time arguments to sleep(1) are not portable. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: perl5.6.1 wrapper
On (2002/11/12 22:17), Doug Barton wrote: > In case another vote is needed, I've always been opposed to the wrapper. > tobez and I put some work into getting the use.perl script in the port > to DTRT shortly after the demise of base perl, and I'm still willing to > help fine tune it if needed. I hate to drag this out further, but nobody else seems to have mentioned something I think is important. Where are we with making lang/perl5's package default selected in sysinstall? While I've been opposed to the inclusion of the wrapper since before it was imported, I think its removal would be well accompanied by the sysinstall change. If there's already a precedent in sysinstall, I'll happily go cut-n-paste a solution myself. Just tell me what the precedent is. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Samba on -current
On (2002/11/12 08:55), Jason Vervlied wrote: > I am having problems with a Samba share on my -current box, I just > installed from 20021103-SNAP. I did recompile my kernel with the following > options. I'll bet your problem as nothing to do with Samba. What you have is a problem with smbfs. > Here is the error I get when I try to copy a file from my samba share > > [jvervlied@current 80-85]$ cp bad_religion-yesterday.mp3 ~/ > cp: /home/jvervlied/bad_religion-yesterday.mp3: Bad address I'll bet you get that error when you try to copy a file from a remote filesystem mounted locally with smbfs. It's a known problem. Consider reading the -current mailing list to keep up to date with known problems. It was discussed last week. No solution is known at this time. Use dd(1) instead of cp(1) as an interim workaround. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] note the __sF change in src/UPDATING
On (2002/11/08 18:13), Daniel Eischen wrote: > > The problem is that you cannot have 4.x packages and 5.x packages > > co-mingled on the same system. that's what I'm trying to fix. You'd > > have to rebuild the 4.x packages before they are fixed. > > I don't think this is a show-stopper. Just recompile all your > ports or use the pre-built 5.0 packages. If we keep thinking only in terms of software for which source is available, we'll soon find ourselves completely estranged from commercial ventures and we can kiss any hope of serious vendor support for FreeBSD good-bye. If the final word on this whole issue is "You can't run binaries compiled for 4.x-RELEASE on 5.x-RELEASE" then we should start puckering up. Developers tend to remember these things and you don't have to screw them too many times before they remove FreeBSD downloads from their web sites and replace them with a brief message explaining that "We don't have time to cope with FreeBSD's disregard for backward compatibility." At that point, whining about how they shouldn't have been fiddling with these symbols in the first place is bound to be a fruitless exercise. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: questions about the state of current
On (2002/10/29 13:06), Matthew Dillon wrote: > :Most of the speed difference is WITNESS, INVARIANTS, and other > :debugging code that's turned on by default in the config files > :for -current. You can turn most of it off. That said, -current > :is slower than -stable in a number of places, so expect some > :slowdown, if you are running non-concurrent code. > > I would concur with this diagnosis. With witness turned off > -current is around 15% slower then -stable for general purpose > computing, like a 'make buildworld -j 20', and I expect that > -stable will beat out -current on single-cpu boxes for a long > time to come. I hate to "me too", but I have a different flavour to offer prospective early adopters. I tried out -CURRENT on my Compaq Presario 2700 (yuk, spit), which is a 512MB PIII. When I downgraded to -STABLE, the performance with simple command-line stuff was noticible. Not huge, but "tangible to a human being". So the answer to "will I notice a performance degredation" is "yes for typical end-users, but not huge". Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/23 11:31), Terry Lambert wrote: > AHA! > > The reason an FFS write resulted in an SMBFS read is that > you had mmap()'ed an SMBFS file, and then wrote a mapped > but-not-in-core page to the target FFS file. Well, a similar problem occurred with cat(1), which doesn't use mmap(). However, I should have included in my message that the following messages are received from the kernel: Oct 23 17:53:02 axl kernel: smbfs_getpages: error 60 Oct 23 17:53:02 axl kernel: vm_fault: pager read error, pid 8022 (cp) Oct 23 17:58:18 axl kernel: smbfs_getpages: error 4 Oct 23 17:58:18 axl kernel: vm_fault: pager read error, pid 8087 (cp) This supports your theory. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/23 18:00), Sheldon Hearn wrote:
> Confirmed with rev 1.9 of subr_mchain.c.
>
> However, I notice that this only happens with files of 8145 bytes size
> or larger.
>
> [server]
> # for i in `jot 512 7680`; do
> dd if=/dev/zero of=$i bs=$i count=1
> done 2>/dev/null
>
> [client]
> $ for i in `jot 512 7680`; do
> cp /smb/urchin/pub/bytes/$i . || break;
> done
> cp: ./8145: Bad address
>
> If I truss the cp process, I get this:
>
> [...]
> open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
> open("./8145",0x401,00) = 4 (0x4)
> mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
Actually, cat(1) is a simpler test case, and more accurately reflects
the problem:
open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
fstat(1,0xbfbff620) = 0 (0x0)
read(0x3,0x805e000,0x2000) ERR#60 'Operation timed out'
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/23 18:21), Vitaly Markitantov wrote:
> > Umm, guys. The code was dereferencing NULL pointers in the mbchain
> > code which was fixed yesterday. Please test it out with the fixed
> > mbchains code.
>
> Yes, it not panics now, but again, when i copy to/from
> smbfs share i get:
>
> cp /share/someFile ./
> cp: ./someFile: Bad address
Confirmed with rev 1.9 of subr_mchain.c.
However, I notice that this only happens with files of 8145 bytes size
or larger.
[server]
# for i in `jot 512 7680`; do
dd if=/dev/zero of=$i bs=$i count=1
done 2>/dev/null
[client]
$ for i in `jot 512 7680`; do
cp /smb/urchin/pub/bytes/$i . || break;
done
cp: ./8145: Bad address
If I truss the cp process, I get this:
[...]
open("/smb/urchin/pub/bytes/8145",0x0,00) = 3 (0x3)
open("./8145",0x401,00) = 4 (0x4)
mmap(0x0,8145,0x1,0x1,3,0x0) = 671461376 (0x2805b000)
I don't have my laptop set up as a serial debugging client now, so
that's as far as I can go. :-(
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Linux and FreeBSD compared
On (2002/10/23 16:16), Nigel Weeks wrote: > I recently heard a comparison between Linux and FreeBSD that I found > amusing. Use freebsd-chat next time, please. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: smbfs broken?
On (2002/10/22 10:48), John Baldwin wrote: > > This is the one I'm seeing everytime while trying to copy file from > > ro smbfs mount. -current is about four days old, smbfs.ko _is_ > > compiled with -DSMP and in sync with kernel. > > Can you compile smbfs into your kernel 'options SMBFS' instead of as a > module and then get a dump and provide a trace? Just to save some time in the feedback round-trip, I'd recommend adding all of these options, in case the bug is in an smbfs dependency: options SMBFS #SMB/CIFS filesystem options NETSMB #SMB/CIFS requester options NETSMBCRYPTO#encrypted password support for SMB options LIBICONV#optional internationalization options LIBMCHAIN #mbuf management library Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kthread.9 out of date
On (2002/10/18 19:38), Benno Rice wrote: > I have just discovered the hard way that the kthread.9 manual page is > slightly out of date. > > Having never done man page work before, I've attached a diff of the > proposed change and if someone could give this a once-over and fix > and/or commit it, that'd rock. Looks good from a style point of view. Just one nit I spotted: +The +.Fa pages +argument specifies the size of the new kthread's kernel stack in pages. +If 0 is used, the default kernel stack size is allocated. This is the first use of the word "kthread". Consider replacing it with "kernel thread" as used elsewhere in the page. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: unbreaking buildkernel?
On (2002/10/15 11:48), Nate Lawson wrote: > cd /usr/src/gnu/usr.bin/binutils; make cleandir; make depend; make all > install Isn't this a bad idea? First, you may not remove stale object files from the src tree, and second, you may leave stale .depend files in the src tree, which will cause you problems later. I would have thought that this would be better: cd /usr/src/gnu/usr.bin/binutils make cleandir make cleandir make obj make depend make all install Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: src/games bikeshed time.
On (2002/10/10 06:55), James Howard wrote: > > If you want to maintain it, I'd be delighted! Are you a committer? > > I could use a new hobby, but I am not a committer. Have you given up on your grep implementation? :-) Quite a few folks were really looking forward to it. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Do we still need portmap(8)?
On (2002/10/09 22:03), Terry Lambert wrote: > The other problem with an mtree.obsolete is that it assumes > the the upgrade process completes successfully. This doesn't > mean that it completes without an error in the upgrade process, > it means that the resulting system functions. Why not just let Warner (or whoever) make this "solution" available and see how it flies? People like you and me who have our own simple and effective ways of pruning stale files can just ignore it or hack it out. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ready to connect libbsdxml (nee libexpat) to the build !
On (2002/10/04 13:26), Poul-Henning Kamp wrote: > What was the concensus on the xmlwf program, did we want it in > the tree or not ? Would it be useful to anybody or is it just > a hackers-proof-of-concept thing ? I think it needs to stay out of the base system, so that 3rd party applications aren't surprised to find a stale binary in the base system instead of the latest version installed in the LOCALBASE. I don't like the idea of a renamed version of this utility existing in the base system, because I feel that folks who want it just for testing the utilities linked against libbsdxml will have sufficient clue to build it themselves. Ciao, Sheldon. PS: Thanks for persevering through the rather long thread that got us to this point, even if it was heavily assisted by your MUA's delete function. :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: expat2 in the base system?
On (2002/10/02 13:57), Marc Recht wrote: > IMO 1. would be better with a complete expat. So the ports could use > the system version and probably/maybe the drift between the official- > and system-version will not be that big. And compared to Perl expat it > rather small. So the bloat couldn't be that big.. What? Have you had much experience with the expat ports? I'm guessing that you're arguing a theoretical point. For a while, we had two versions in the ports tree, and some applications had conflicting version requirements that caused them to blow up horribly (e.g. mod_perl, PageKit). We're at a lucky moment in time, where there's only one version of expat in the ports tree. But think about what happens when there are two mainstream versions at large again. Please let's learn from past mistakes and give this library a completely separate name, perhaps with stripped down functionality. Then ports can still choose to use it instead of the expat2 port if it does the job for them, and we have our cake and eat it. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
On (2002/10/02 16:27), Bruce Evans wrote: > It is a devfs issue that devfs moves things into the kernel where they > harder to control and more fatal if they are got wrong. If it's just ownerships and permissions you're worried about, I think the issue could be made moot by some /etc support for devfs(1). In fact, as the loudest supporter of MAKEDEV, you might be the best person to drive its transcription into /etc/defaults/devfs.conf. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADSUP! GEOM as default in 5 days...
On (2002/09/30 21:09), Poul-Henning Kamp wrote: > Provided nothing terminal pops up in the next 5 days, GEOM will > become default in -current on Saturday 5th of october. > > Please test it now on _your_ configuration and tell me if it > fails to work. There are problems in -CURRENT that have held me back from upgrading for two weeks. These include X crashes and kernel panics. Maybe you'd get more testers if you wait until the latest serious problems are resolved before going ahead. Maybe you wouldn't, though. So I wouldn't be annoyed if you responded with "Worth considering, but I don't think waiting would make a difference." :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: installworld broken
On (2002/09/02 12:44), Steve Kargl wrote: > > : I've had to add ex, touch and gencat to the installworld target. And > > : I've still not manged to complete a installworld. > > : > > : anybody else see this? > > > > Strange, I just did a "make buildworld ... mergermaster" > sequence and I did not need the three utilities you mention. Why is that strange? You're talking about everything up to but not including installworld. Warner's talking about installworld. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: hw.pci.enable_io_modes default value.
On (2002/09/01 19:12), Marc Fonvieille wrote: > I had "freeze at boot" problem with my laptop and -CURRENT: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=42262 > > I found the solution: setting hw.pci.enable_io_modes to 0. > So I have a question: that sysctl has to be =1 by default? I mean if I > have that issue with it and my laptop, maybe I'll not be the only one > with that problem. > > Well I'm sure there is a good reason for that default setting. Perhaps > we could write somewhere that setting may lead to hangs with some > hardware :) Don't be too sure. :-) revision 1.194 date: 2002/07/26 07:58:16; author: imp; state: Exp; lines: +36 -21 Make PCI_ENABLE_IO_MODES a sysctl hw.pci.enable_io_modes. It can also be set at boot time. It defaults to 1 now since it can be set in the boot loader. If this proves unwise, we can reset it to defaulting to 0. If enough people have trouble with this default, we might want to set it to 0, since 1) We can't please everyone. 2) We should try to please people with working hardware first. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT's termcap broken
On (2002/08/28 20:32), Jens Schweikhardt wrote: > # > Yes, use plain TERM=xterm. It's got color now as it should. I'm > # > thinking of removing xterm-color if I can't resolve the > # > enter_alt_charset_mode stuff. Let me know if TERM=xterm does not > # > work as expected in mutt et al. I'll post a minor HEADS UP to > # > current@. > # > # Doesn't work for centericq or mutt. > > Are you sure? I use mutt too (in an rxvt), and TERM=xterm works > wonderfully with colors. Hang on, will test mutt in plain xterm... > yes, works there too. I do have customized my .muttrc and > app-defaults/XTerm, however to use different colors from the standard > ones. Maybe you have a stale termcap.db? Argh, how stupid of me. I tried removing TERM=xterm-color without rolling forward to your latest version where xterm has colour support! Your fix works great, thanks. Do you have time to commit mention of it to UPDATING? If so, please draw Bruce Mah's attention to the delta so that he can steal your text for use in the release notes. If not, I'll get around to it eventually. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CURRENT's termcap broken
Hi Jens, I just updated to the latest -current and my TERM=xterm-color applications (mutt and centericq) are broken. Mutt shows this when I start vi as my editor or run fetchmail: "TERMCAP", line 0, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars My centericq window ends up using pipe signs (|), minus signs (-) and plus signs (+) to draw boxes. This breakage is visible with the following revisions of the termcap src files: rev 1.129 of src/share/misc/termcap.src rev 1.5 of src/share/misc/reorder Reverting to these revisions of the termcap src files makes things behave as they did before your changes: rev 1.124 of src/share/misc/termcap.src rev 1.4 of src/share/misc/reorder Any ideas? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rcNG and dhcp
On 12 Aug 2002 12:40:20 +0400, "Vladimir B. " Grebenschikov wrote: > There is patch to teach rcNG do not try dhcp on not-connected ethernet. > > simply put > ifconfig_fxp0="dhcp-if-carrier" > into rc.conf > > It will be interested to somebody For what it's worth, I think this rocks. > Theoretically there are another solution for problem - add new key to > dhclient - check interface media before broadcasting. Yes, that's definitely the long-term solution. However, I'd like the dhcp-if-carrier solution while we wait for patches to be accepted by the ISC folks. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: firewall support?
On (2002/07/28 09:49), Szilveszter Adam wrote: > > is firewall support built into the -current kernel or does it need to be > > compiled in? > > It is not in GENERIC, but you can always either compile it in, or load > it from a module by editing /boot/loader.conf. Beware! AFAIK, the kernel-loadable version of IPFW (ipfw.ko) defaults to deny! Enable with care on remotely managed systems for which you do not have serial console access. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem compiling -current on 4.6-RELEASE
On (2002/07/25 11:45), Martin Bundgaard wrote: > I have a problem. When trying to do a 'make buildworld' on a (freshly > fetched) -current source-tree, I quickly get an error: Other people have pointed out the cause of the problem. However, please note for future reference that what you're doing is not supported. Current cross-builds on -STABLE are only supported "on the latest -STABLE". Since 4.6-RELEASE was a snapshot cut off the -STABLE branch very recently, it's likely that what you're doing will work. But keep it in mind for the future. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is it just me or has -current suddenly got massively unstable?
On (2002/07/23 12:08), Yann Berthier wrote: >Thanks a lot, patch applied, and all is going fine. Peter: I knew you >would come up with a solution :) >(well, feel free to call it bandaid, but it solves the problem BTW) To quote Terry Lambert on what he calls Occam's Corollary: Anything that works is better than anything that doesn't. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Is it just me or has -current suddenly got massively unstable?
On (2002/07/22 18:48), Szilveszter Adam wrote: > I have a kernel and world from Saturday, it seems reasonably ok in > console mode (does not panic although it is used as an ADSL router) but > in X, it locks up very easily. I tried it with Mozilla on Sunday, it > froze twice within as many hours, [...] As a datapoint, yesterday's -CURRENT was sufficiently stable on a UP system to perform a full local ports build and install (117 ports including X and mozilla), while also serving as an X workstation with pretty heavily-used mozilla and CVS clients. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Still no XFree86-4
On (2002/07/21 21:08), Eric Anholt wrote:
> You don't have XFree86-4 uninstalled, or don't have it uninstalled
> successfully. Just removing the XFree86-4 metaport doesn't remove the
> miniports that contain the actual files. If you are going to build
> without using portupgrade, you should start from scratch wrt XFree86
> (all XFree86-4 ports uninstalled along with imake-4).
I find the situation with the XFree86-4 metaports annoying, so allow me
to share my "portdeps" solution.
I use this perl script to build all dependencies of a port, in the
correct order, before building the port itself.
I use /usr/ports/makefile as follows:
| MY_STUFF?=\
| archivers/unzip \
| ...
| x11/XFree86-4 \
| ...
| x11/xlockmore
|
| MY_FULL_LIST!= ${.CURDIR}/Tools/portdeps ${MY_STUFF}
| SUBDIR?= ${MY_FULL_LIST}
|
| update:
| @cvs -qR update -dPA ${SUBDIR}
|
| .include
The script /usr/ports/Tools/portdeps is attached. I wrote it in a hurry
ages ago, so it's probably a little sucky.
Then, I can do this to build all the ports I want, along with all their
dependencies, in the correct order:
cd /usr/ports
make install
make clean
Or, I can just build one particular port, with all its dependencies, in
the correct order:
cd /usr/ports
make MY_STUFF=x11/XFree86-4
Ciao,
Sheldon.
#!/usr/bin/perl -w
#
# Takes one or more "port name" arguments, each consisting of the name of a
# port, preceded by its primary category and a forward slash, e.g.
#
# databases/gnats
#
# EXAMPLE:
#
# cd /usr/ports
# portdeps `make -f ./makefile -V SUBDIR`
#
use strict;
my $PROGNAME = 'portdeps';
my %desired;
my %required_by;
my %mustbuild;
my %seen;
my %unresolved;
my @buildlist;
my $basedir;
my $loop_prot;
my $deps_only;
$basedir = `pwd`;
chomp $basedir;
if (defined($ARGV[0]) and $ARGV[0] eq '-d') {
$deps_only = 1;
shift @ARGV;
}
foreach (@ARGV) {
$unresolved{$_} = 1;
$desired{$_} = 1;
}
$loop_prot = 100;
while (keys %unresolved and $loop_prot--) {
foreach my $port (keys %unresolved) {
my (@index_parts, $make_out, @prereqs);
next if $seen{$port}++;
$mustbuild{$port} = 1;
delete $unresolved{$port};
chdir($basedir) or
die "$PROGNAME: chdir: $basedir: $!\n";
chdir($port) or
die "$PROGNAME: chdir: $port: $!\n";
$make_out = `make describe`;
if ($?) {
die "$PROGNAME can't make describe: $port\n";
}
@index_parts = split(/\|/, $make_out);
$index_parts[1] =~ /([^\/]+\/[^\/]+)$/;
$port = $1;
@prereqs = split(' ', "$index_parts[7] $index_parts[8]");
foreach my $req_path (@prereqs) {
my $req;
$req_path =~ /([^\/]+\/[^\/]+)$/;
$req = $1;
if (exists $required_by{$req}) {
push(@{$required_by{$req}}, $port);
} else {
$required_by{$req} = [ $port ];
$unresolved{$req} = 1;
}
}
}
}
$loop_prot = 100;
while (keys %mustbuild and $loop_prot--) {
CANDIDATE:
foreach my $candidate (keys %mustbuild) {
foreach my $dependency (@{$required_by{$candidate}}) {
if (not grep {$_ eq $dependency} @buildlist) {
next CANDIDATE;
}
}
unshift(@buildlist, $candidate);
delete($mustbuild{$candidate});
}
}
foreach my $port (@buildlist) {
if (not $deps_only or not exists $desired{$port}) {
print "$port\n";
}
}
exit 0;
Re: DEVFS rule subsystem (was: cvs commit: src/sbin Makefile src/sbin/devfs Makefile devfs.8 devfs.c extern.h rule.c src/sys/conf files src/sys/fs/devfs devfs.h devfs_devs.c devfs_rule.c devfs_vfsops.c devfs_vnops.c )
On (2002/07/17 01:52), Dima Dorfman wrote: > The devfs(8) manual page is a pretty good reference of the existing > features and semantics, but it lacks polish needed to be able to serve > as an introduction. Actually, I think it's brilliant. The only nits are the weird sections, which made it hard for me to find my way around. For example, the examples are all in an Examples subsection of the non-standard RULE SUBSYSTEM section, so I didn't see that there were examples when I first looked for them. I'd suggest the attached patch, to make it easier for manpage die-hards to navigate. Great job, man! Ciao, Sheldon. Index: devfs.8 === RCS file: /home/ncvs/src/sbin/devfs/devfs.8,v retrieving revision 1.1 diff -u -d -r1.1 devfs.8 --- devfs.8 17 Jul 2002 01:46:47 - 1.1 +++ devfs.8 17 Jul 2002 16:25:02 - @@ -62,7 +62,7 @@ operates on .Pa /dev . .El -.Sh RULE SUBSYSTEM +.Ss Rule Subsystem The .Xr devfs 5 rule subsystem provides a way for the administrator of a system to control @@ -207,9 +207,7 @@ .It Cm unhide Unhide the node. .El -.Ss Notes -.Bl -bullet -offset indent -.It +.Sh IMPLEMENTATION NOTES Rulesets are created by the kernel at the first reference, and destroyed when the last reference disappears. E.g., a ruleset is created when a rule is added to it or when it is set @@ -218,12 +216,12 @@ and no other references to it exist (i.e., it is not included by any rules, and it is not the current ruleset for any mount-point). -.It +.Pp Ruleset number 0 is the default ruleset for all new mount-points. It is always empty, cannot be modified or deleted, and does not show up in the output of .Cm showsets . -.It +.Pp Rules and rulesets are unique to the entire system, not a particular mount-point. I.e., a @@ -232,8 +230,7 @@ .Fl m . The mount-point is only relevant when changing what its current ruleset is, or when using one of the apply commands. -.El -.Ss Examples +.Sh EXAMPLES When the system boots, the only ruleset that exists is ruleset number 0; since the latter may not be modified, we have to create another ruleset To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: sparc64 tinderbox failure
On (2002/07/17 06:49), Rob Hughes wrote: > > ===> sbin/newfs > > /usr/home/des/tinderbox/sparc64/src/sbin/newfs/mkfs.c: In function `fsinit': > > /usr/home/des/tinderbox/sparc64/src/sbin/newfs/mkfs.c:711: structure has no member >named `di_createtime' > > *** Error code 1 > > > > Stop in /usr/home/des/tinderbox/sparc64/src/sbin/newfs. > > *** Error code 1 > > Same error on i386 build. Patches posted in Message-ID: <[EMAIL PROTECTED]>, sent to cvs-committers and cvs-all. I haven't committed them myself, because I haven't tested whether the resulting newfs binary works. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Status of C++ in base system?
On (2002/07/11 11:01), Benjamin Close wrote: >I'm using current from just after the KSE & libc_r fix. However it > appears that XFree86-client c++ stuff is still broken. Is there a > planned time when this will be fixed or am I missing something else? > (XFree-libraries compiled and installed without a hitch ). This is not a one-way mailing list. I sent patches to this list in the last two weeks. Please read if you're going to post. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc-3.1 Mozilla Build Fails
On (2002/07/10 19:15), Dirk Engling wrote: > Maybe this would be more interesting to > the mozilla guys but mozilla compiles on > 2.95.3, so I think, the problem is related > to gcc-3.1 As far as I know, ports/lang/gcc31 is still required to build mozilla. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Remember my ill-fated i386 smp pmap optimizations?
On (2002/07/08 13:52), Peter Wemm wrote: > I have found some of them. And what is really scary is that I have > verified that some of what Terry has been FUD'ing(*) about for our TLB > (mis)management is actually correct. :-( Ha! Justice! All those who slapped me around on IRC for defending Terry can now mail me postal details privately so that I can send you a hat to eat. :-) Ciao, Sheldon. PS: For the humour impaired, this is meant in a playful spirit and shouldn't be used as a platform for axe grinding. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On (2002/07/05 17:24), Sheldon Hearn wrote: > You and Paul are both pretty "out there" if you think -current users > will graciously accept a new world order in which ports linked > dymanically against system libraries won't work between a system upgrade > and the next port reinstall. Sorry about the "heat" of my post. I was stressed out and shouldn't even have been reading my FreeBSD mail to start with. I liked Mark Murray's response to Paul's suggestion much better than my own. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Removing perl in make world
On (2002/07/05 05:22), Terry Lambert wrote: > > This would not fit in with the rest of the world target, which doesn't > > clean out stale headers, stale libraries or stale binaries. > > Special-casing certain things will surprise people. > > Headers and libraries arguably should be removed, so as to avoid > errors; not ports headers or libraries -- which aren't in the > installation target paths in the first place -- but things like > deprecated system headers, etc.. You and Paul are both pretty "out there" if you think -current users will graciously accept a new world order in which ports linked dymanically against system libraries won't work between a system upgrade and the next port reinstall. If you want to clean out crap left behind by `make world', just do this: make world rm -r /usr/include # Make world really should overwrite make installincludes# header files! find /bin /sbin /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/share \ -type f -mtime +1 -delete If you're just annoyed by the recent perl wobble, think about how important it is to do what Paul suggests, if it means annoying users who have very good reasons to prefer the way the `make world' upgrade method works. Then, if you still think it's important, figure out a way to do it _without_ annoying those users, as suggested by Terry. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 can't compile XFree86-4-Server
On (2002/07/03 13:29), Garance A Drosihn wrote: > With his patches I was able to compile and install imake. I was > able to compile XFree86-4-libraries, but the 'make install' of it > fails for me after getting most of the way through. I suspect > this is a build problem, not a cc problem. Yes, remember that you're building the MATROX stuff, which I'm not. Also, remember that my patches were for the base system's toolchain, not lang/gcc31's. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Core Dumps et al on -current
On (2002/07/02 14:13), Sid Carter wrote: > Anything obvious I missed ? Yes. You haven't been reading your mail. :-) There's known instability at present, that is believed to relate to changes made to libc_r in the last month, or to the recent KSE update and its impact on libc_r. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [PATCH] Re: Which .info files have been disabled?
On (2002/06/30 11:15), Szilveszter Adam wrote: > Grrr, hit me baby one more time. > > One of the diffs included a completely gratuitous one-line change which > I made yesterday night while I was tired and neglected to correct today. > > So, the patchset again. (Take three!) I've tested your patch through a 'make world' and have committed your patch: rev 1.12src/gnu/usr.bin/binutils/doc/Makefile rev 1.4 src/gnu/usr.bin/binutils/doc/inc-hist.diff Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On (2002/06/30 00:46), Jeremy Lea wrote:
> +#ifndef SharedDepCplusplusLibraryTarget
> +#define SharedDepCplusplusLibraryTarget [...]
This patch would fix the build. Did it also fix the linking problems
involving -lstdc++ for glxinfo, or were the patches that handle
${CXXLIB} still required?
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: i386 tinderbox failure
On (2002/06/27 16:33), Sheldon Hearn wrote: > I got this testing the RMEM_LIMIT patches, but it only crops up after > about an hour of heavy ports building. You'll get this for just any > binary that uses mmap(). > > Unfortunately, I haven't had time to produce any useful debugging > information, so I can't be sure it's really the RMEM_LIMIT patches. FUD. :-( Tor Egge found the feal problem, which had nothing to do with the RLIMIT_VMEM stuff. Sorry, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i386 tinderbox failure
On (2002/06/26 19:00), Dag-Erling Smorgrav wrote: > Wed Jun 26 19:00:10 PDT 2002 > /usr/libexec/ld-elf.so.1: /usr/bin/cvs: Shared object has no run-time symbol table I got this testing the RMEM_LIMIT patches, but it only crops up after about an hour of heavy ports building. You'll get this for just any binary that uses mmap(). Unfortunately, I haven't had time to produce any useful debugging information, so I can't be sure it's really the RMEM_LIMIT patches. But if you have the time, try backing that out and seeing if the problem persists. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On Wed, 26 Jun 2002 13:25:57 +0200, Sheldon Hearn wrote:
> I think I have a handle on this now. If you fix it before you hear back
> from me, let me know so I can stop wasting time on it. XF84-4 test
> builds are slow. :-)
Okay, it looks like a bit of a mess.
I've copied the XFree86-4 maintainer.
I think there are three problems causing the XFree86-4 installation to
fail on -CURRENT:
*) Our imake-4 port doesn't arrange for a SharedDepCplusplusLibraryTarget
rule. I _think_ such a rule would, by default, add $(CXXLIB) to the
deplist for -CURRENT.
*) Our imake-4 port doesn't arrange for a CXXLIB definition. It should
be -lstdc++ on at least -CURRENT. The stock bsdLib.tmpl explicitly
sets CplusplusLibC empty, Imake.tmpl sets it to /**/ if not defined
and FreeBSD.cf doesn't set it at all.
*) The XFree86-4 distribution contains some bad C++ code.
Here's what I did to get XFree86-4 to build with the base system's
toolchain in -CURRENT:
a) ports/devel/imake-4:
Replace files/patch-d and files/patch-xthreads with the attached
patch-config::cf::FreeBSD.cf.
Add the attached patch-config::cf::bsdLib.tmpl.
b) ports/x11/XFree86-4-libraries:
Replace files/patch-z45 with the attached patch-z45.
Note that this isn't quite right, because the linking gets done with
cc as a front-end, not c++. But the job gets done, all the same,
and I'm not writing a SharedDepCplusplusLibraryTarget rule myself.
:-)
c) ports/x11-servers/XFree86-4-Server:
Add the attached patch-gcc31, taken from Motoyuki Konno's post to
<[EMAIL PROTECTED]> with the following Message-ID:
<[EMAIL PROTECTED]>
That's all.
Ciao,
Sheldon.
patch-config::cf::FreeBSD.cf
--- config/cf/FreeBSD.cf.orig Wed Jun 26 15:44:29 2002
+++ config/cf/FreeBSD.cfWed Jun 26 16:21:18 2002
@@ -80,7 +80,6 @@
/*
* math.h uses _REENTRANT and stdio.h uses _THREAD_SAFE, so define both.
*/
-# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE
/*
* FreeBSD has tread-safe api but no getpwnam_r yet.
*/
@@ -91,8 +90,12 @@
# else
# define BuildThreadStubLibrary YES
# define NeedUIThrStubs YES
-# define ThreadsCompileFlags -pthread
-# define ThreadsLibraries -pthread
+# if (OSRelVersion >= 500016)
+# define ThreadsLibraries-lc_r
+# else
+# define SystemMTDefines -D_REENTRANT -D_THREAD_SAFE
+# define ThreadsLibraries-pthread
+# endif
# define SharedX11Reqs$(LDPRELIB) $(XTHRSTUBLIB)
# define SharedXtReqs $(LDPRELIB) $(XLIBONLY) $(SMLIB) $(ICELIB)
$(XTHRSTUBLIB)
# endif
@@ -151,6 +154,7 @@
# define CcCmd cc
# define CplusplusCmd c++
#endif
+#defineCplusplusLibC -lstdc++
#define CppCmd /usr/bin/cpp
#define PreProcessCmd CppCmd
patch-config::cf::bsdLib.tmpl
--- config/cf/bsdLib.tmpl.orig Wed Jun 26 16:19:42 2002
+++ config/cf/bsdLib.tmpl Wed Jun 26 16:20:34 2002
@@ -39,7 +39,9 @@
#define XawClientLibs $(XAWLIB) $(XMULIBONLY) $(XTOOLLIB) $(XPMLIB) $(XLIB)
#endif
-#define CplusplusLibC
+#ifndef CplusplusLibC
+#define CplusplusLibC $(CXX)
+#endif
#define FrescoSysLibs CplusplusLibC MathLibrary
/* Allow for libpthread, as overridden by OS definitions */
patch-z45
--- lib/GLU/Imakefile.orig Wed Jun 6 01:03:20 2001
+++ lib/GLU/Imakefile Wed Jun 26 15:27:14 2002
@@ -103,6 +103,7 @@
#undef _LinkBuildLibrary
#define _LinkBuildLibrary(lib) LinkBuildLibrary(lib)
+#if !defined(LibInstall) || LibInstall
#if NormalLibGlu
NormalDepLibraryTarget($(LIBNAME),$(SUBDIRS) $(DONES),$(STATIC_OBJS))
InstallLibrary($(LIBNAME),$(USRLIBDIR))
@@ -110,9 +111,9 @@
#if SharedLibGlu
#ifdef SharedDepCplusplusLibraryTarget
-SharedDepCplusplusLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS)
$(DONES),$(SHARED_OBJS),.,.)
+SharedDepCplusplusLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS)
+$(DONES),$(SHARED_OBJS) $(CXXLIB),.,.)
#else
-SharedDepLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS) $(DONES),$(SHARED_OBJS),.,.)
+SharedDepLibraryTarget($(LIBNAME),$(SOREV),$(SUBDIRS) $(DONES),$(SHARED_OBJS)
+$(CXXLIB),.,.)
#endif
InstallSharedLibrary($(LIBNAME),$(SOREV),$(SHLIBDIR))
#endif
@@ -126,6 +127,7 @@
ProfiledDepLibraryTarget($(LIBNAME),$(SUBDIRS) $(DONES),$(PROFILE_OBJS))
InstallLibrary($(LIBNAME)_p,$(USRLIBDIR))
#endif /* ProfileLibFont */
+#endif
ForceSubdirs($(SUBDIRS))
patch-gcc31
--- lib/XThrStub/UIThrStubs.c.old Mon Nov 19 06:13:26 2001
+++ lib/XThrStub/UIThrStubs.c Tue Jun 4 11:39:19 2002
@@ -99,6 +99,21 @@
#else
#include
typedef pthread_t xthread_t;
+#if __GNUC__ >= 3
+xthread_t pthread_self()__attribute__ ((weak, alias ("_Xthr_self_stub_")));
+int pthread_mutex_init()__attribute__ ((weak, alias ("_Xthr_zero_stub_")));
+int pthread_mutex_destroy() __attribute__ ((weak, alias (&
Re: What's the right way to build XFree86-4 now?
On (2002/06/25 22:02), Szilveszter Adam wrote: > > I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', > > where that g++31 comes from the lang/gcc31 port, and either way, > > XFree86-4-clients fails with: > > There is another problem, however, and this is that the libGLU built is > parctically unusable anyway, although there the correct compiler is used > (g++), one alway needs to link -lstdc++ with it for it to work. I do not > know why this is. Other parts of X appear to work ok. Thanks for the great response! You really gave me useful stuff to think about. I think I have a handle on this now. If you fix it before you hear back from me, let me know so I can stop wasting time on it. XF84-4 test builds are slow. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: What's the right way to build XFree86-4 now?
On (2002/06/25 10:06), David O'Brien wrote: > On Tue, Jun 25, 2002 at 09:21:57AM +0200, Sheldon Hearn wrote: > > Could someone put me out of my misery and show me "the right way" to > > build XFree86-4 on -current at the moment. > > > > I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', > > where that g++31 comes from the lang/gcc31 port, and either way, > > XFree86-4-clients fails with: > > Try building all of the dependancies with g++31 also. Makes no difference. I'm using a dependecy manager to ensure that all dependencies are built first, in the appropriate order. Was that advice based on the fact that you've built XFree86-4 successfully with lang/gcc31, or was it an educated guess? -- Sheldon Hearn Postmaster - Gambling.com In systems administration, a change is NOT as good as a holiday! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewiting - Any volunteers?
On (2002/06/25 10:20), Mark Murray wrote: > How's this? > > int handle; > template = "/tmp/mumble"; > char *cmd; > handle = mkstemp(template); // template is modified > asprintf(cmd, "prog > %s", template); > system(cmd); > close(handle); // bye-bye file It would be failsafe if you tested that mkstemp() had not returned an error. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
What's the right way to build XFree86-4 now?
Hi folks, Could someone put me out of my misery and show me "the right way" to build XFree86-4 on -current at the moment. I've tried `make install' and `make CXX=/usr/local/bin/g++31 install', where that g++31 comes from the lang/gcc31 port, and either way, XFree86-4-clients fails with: /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_cl ass_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class _type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_c lass_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' Looks like bad linkage to me, but I'm all out of foo. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
When was soundcard.h moved?
Hi folks, When was soundcard.h moved from machine to sys? A large number of ports expect to find it in machine, and I can't find a __FreeBSD_version bump supporting the change. So I need to find out when it happened and piggy-back on the nearest __FreeBSD_version bump. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, 11 Jun 2002 07:29:56 MST, Juli Mallett wrote: > > I don't think you should worry too much about _not_ getting > > reasonable output from POSIX-conformant utilities. :-) > > I'd read SUS's ps(1) escription a little closer. Very few guarantees > with it. My POSIX.2 (1993) suggests that you can get a sufficient level of regularity out of ps(1) to provide reliable input for a tree printer. I think the "5.23.6.1 Standard Output" section defines the impact of the format specified with the -o option "well enough". I haven't looked at what SUS has to say about the issue, but if it's more ambiguous, then it's a regression from POSIX.2 (1993) and should be corrected. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, 11 Jun 2002 06:46:13 MST, Juli Mallett wrote: > > Piping commands through other commands seems icky? > > Relying on reasonable output from ps(1) seems icky when you can extract the > data yourself and not have to worry about formatting getting in the way of > processing data properly. I don't think you should worry too much about _not_ getting reasonable output from POSIX-conformant utilities. :-) I didn't want to be the one to break the "pstree exists" news, because I know how frustrating it is to discover that you've just engineered a solution to a solved problem, but it's an unfortunate fact of life. I was very annoyed when I realized that my waitpid(1) program that I was so proud of already existed in several incarnations. :-) Still, you can be proud of the work you've done. You could even get it into the ports tree. It's always nice to have choices. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Looking for comments on a new utility...
On Tue, 11 Jun 2002 05:15:17 MST, Juli Mallett wrote: > > As some of you may have noticed, I've done some poking of ps(1) lately, and > this has brought attention of people who have ideas for things that they > would like to see done to ps(1) :) The most notable request was for a > feature I've missed having in our ps(1) for a while, the ability to get a > tree of processes printed so you can tell who is whose child, etc. Like pstree in the ports tree? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Safe" to go to -CURRENT?
On Thu, 06 Jun 2002 10:14:52 MST, "David O'Brien" wrote: > > There are still issues with the C++ compiler in the base system that > > make building X and some other C++ ports tricky. > > There is no issue with the C++ compiler. There is issue with the X > source that uses depreciated features. The fact remains, desktop-environment users looking for an easy ride should not be jumping on the -CURRENT wagon bus just now. Such people probably don't really care "whose fault it is". But thanks for clarifying. I'll be sure to explain more carefully to the next person who asks me whether now's a good time for -CURRENT. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failure in libfetch
On Wed, 05 Jun 2002 16:44:55 CST, Scott Long wrote: > Ok, I finally feel the need to speak up here. > > DES, > > FREEFALL CVS IS NOT THE PLACE TO PUT EXPERIMENTAL CODE THAT BREAKS WORLD! > PERIOD! > > Don't give me any crap about "It's -current, you should expect breakage." > You are abusing this disclaimer far more than it was ever meant for. > Breaking world used to be a very humiliating event for committers. You, > however, break it on a consistent basis. What the F*CK? Yes, others > have broken world before you, and others will break it after you, but > you are abusing the standards of the project. I think you went a little over the top with this message. If you'd taken a moment to calm down and limited yourself to presenting an emotion-free complaint, you'd be in a much better position to expect a positive result. Yes, DES broke the world build. Yes, more / better testing on his part could have avoided the breakage. Still, it's seldom useful to come on so strong. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld error in gnu/lib/libstdc++
On Wed, 05 Jun 2002 15:36:04 +0200, Andrea Campi wrote: > I've been seeing a compile error in gnu/lib/libstdc++ for days now. Since no > one else reported it (not even tinderbox) I can only wonder what's up, and > expecially how to get out of this. Show the compile error. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: stat(1) (was Re: mergemaster(8) broken -- uses Perl
On Wed, 05 Jun 2002 23:58:14 MST, Doug Barton wrote: > I'm currently testing a buildworld prior to importing NetBSD's stat(1) > into the tree. Once that's done, if you have suggestions for > improvements I'm sure that they would be interested. I'll be happy to > work with you on adding useful bits to it in our tree as well. You can > see what I'm importing at > http://cvsweb.netbsd.org/bsdweb.cgi/basesrc/usr.bin/stat/ I really like the fact that you're trying to maintain NetBSD compatibility with tools imported from NetBSD. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: "Safe" to go to -CURRENT?
On 05 Jun 2002 08:46:59 GMT, Christopher Nehren wrote: > I've been monitoring the -CURRENT mailing list for about a day or two, > and haven't seen anything that's really broken (except for GCC 3.x, > which I don't use anyway). So, is it "safe" to upgrade to -CURRENT yet? > TIA for the info, > Chris There are still issues with the C++ compiler in the base system that make building X and some other C++ ports tricky. If you use a lot of X applications, you might want to hold back if you're looking for a smooth ride. The base system itself seems pretty stable, though. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Please test the UFS2 patch!
On Wed, 05 Jun 2002 15:13:28 +0200, Poul-Henning Kamp wrote: > I have uploaded an updated version of the UFS2 patch: > > http://phk.freebsd.dk/patch/ufs2.patch > > Please test this! Is this something we can drop in and expect to work / panic / corrupt our filesystems without any change in the way we interact with our systems? If not, where is the information on things we'll have to change in the way we interact with our systems? It's not in this URL, and earlier test requests sounded scarier than this one, so I didn't pay attention to the instructions they included. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mergemaster broken?
On 05 Jun 2002 15:01:24 +0200, Dag-Erling Smorgrav wrote: > > Looks like this is going to be necessary after each > > buildworld, then. :-/ > > No. Mergemaster should not use Perl, and the fact that it does is a > bug. That's probably an overstatement. Perl used to be in the base system, and was, at the time an easy way to stat() a file. I'd say mergemaster's use of perl is "use of an obsoleted interface" at worst. :-) Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc3.1 problems: undefined reference to `__gxx_personality_v0'
On Wed, 29 May 2002 09:27:50 MST, "Dan Trainor" wrote: > Being that -CURRENT's C++ compiler is b0rked, how long will it be until > it's problems have been resolved? I've seen many problems with it > lately, and it kinda made me worried, almost to the point where I > thought a re-install from the 4.5 release would be appropriate. It probably won't be too long, because at least one very clueful individual is working on the problem. In the meantime, though, either compile ports with CXX=/usr/local/bin/g++31 or use a stable, end-user oriented version of FreeBSD (like 4.6-SOMETHING). Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc internal compiler error with mozilla
On Sun, 26 May 2002 15:28:44 MST, Lamont Granquist wrote: > I got non-deterministic internal compiler errors when I was trying to > compile mozilla. At the same time I was compiling gnome in another > terminal window. It only happened with mozilla, it was non-deterministic > in that I could do another 'make' and it would proceed past the point it > failed. At the moment, the c++ compiler in the base system can't be used to build Mozilla. Install the lang/gcc31 port and build Mozilla as follows: cd /usr/ports/www/mozilla make CXX=/usr/local/bin/g++31 A few people have reported on this mailing list that the above works. The archives are your friend. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
