Re: CFLAGS=-O2 -pipe problems in RELENG_5 ?
On 18-Jan-2005 Chris wrote: I have been compiling ports using -O2 since I started using FreeBSD back in 2003 and only port that has had issues with this is lang/ezm3 in FreeBSD 5.2.1 it needed -O. I fixed that at the beginning of November. John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: 4.9-RC and bge
On 30-Sep-2003 Damon Anton Permezel wrote:
Recent SUP.
Installed on Dell PowerEdge 4600.
Getting tons of:
Sep 30 12:23:16 zige /kernel: bge0: gigabit link up
Sep 30 12:23:46 zige last message repeated 98 times
Check your dmesg output, and I bet you'll see that bge0 is sharing an
IRQ with another device. (If not, I'd like to hear about it.) This
bug was fixed in -current in revision 1.41 of if_bge.c, but it never
got merged to -stable. I have a patch for -stable that I am planning
to commit after the source freeze lifts. It is attached to this mail.
Please let me know whether it solves your problem or not.
John
Index: if_bge.c
===
RCS file: /home/ncvs/src/sys/dev/bge/if_bge.c,v
retrieving revision 1.3.2.28
diff -u -r1.3.2.28 if_bge.c
--- if_bge.c26 Sep 2003 16:02:04 - 1.3.2.28
+++ if_bge.c30 Sep 2003 15:15:45 -
@@ -,11 +,12 @@
{
struct bge_softc *sc;
struct ifnet *ifp;
+ u_int32_t statusword;
u_int32_t status;
-
sc = xsc;
ifp = sc-arpcom.ac_if;
+ statusword = loadandclear(sc-bge_rdata-bge_status_block.bge_status);
#ifdef notdef
/* Avoid this for now -- checking this register is expensive. */
@@ -2263,13 +2264,7 @@
BRGPHY_INTRS);
}
} else {
- if ((sc-bge_rdata-bge_status_block.bge_status
- BGE_STATFLAG_UPDATED)
- (sc-bge_rdata-bge_status_block.bge_status
- BGE_STATFLAG_LINKSTATE_CHANGED)) {
- sc-bge_rdata-bge_status_block.bge_status =
- ~(BGE_STATFLAG_UPDATED|
- BGE_STATFLAG_LINKSTATE_CHANGED);
+ if (statusword BGE_STATFLAG_LINKSTATE_CHANGED) {
/*
* Sometimes PCS encoding errors are detected in
* TBI mode (on fiber NICs), and for some reason
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: memory disks in 4.5-stable
In article [EMAIL PROTECTED], Marius M. Rex [EMAIL PROTECTED] wrote: I want to create a number of small RAM disks on some webservers so they can serve high traffic content directly off of RAMdisks instead of conventional disks or NFS. I first tested this out on my desktop machine 4-7 stable and everything worked just fine. I made 3 10Mb RAMdisks and mounted then just as planned. But once I hopped onto the production servers (4.5-Stable from eb 26, 2002 I believe) I seemed to be limited to using only one md device. Only md0 is reconized as valid, any device number above that fails to be recognized as a configured device. It's a bug that I fixed in the -stable branch on 19 August. If you update src/sys/dev/md/md.c to revision 1.8.2.2 and rebuild your kernel, your problem should go away. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Compaq GIGA NIC
In article 002b01c276c2$46fd17c0$3264a8c0@BONG, Jamie Heckford [EMAIL PROTECTED] wrote: Ok apologies - here's my corrected version: The last time *I* used Ethernet cards based on the broadcom chipset the driver caused me massive problems. It was terrible. I hated it. I switched to intels. This solved my problem. IMHO Sorry for my earlier post and before something flies back yes I did understand your reply ;) Sorry I overreacted. :-} Out of curiosity, what was the platform on which you had so much trouble with the Broadcom chips? In particular: what kind of CPU, and was the bus PCI or PCI-X? John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Possible problems with cvsup14.freebsd.org
In article [EMAIL PROTECTED], Kevin Oberman [EMAIL PROTECTED] wrote: I have been updating from many months from cvsup14 but I have had no updates to src-all with the RELENG_4 tag for at least two days. Seemed VERY unlikely! So I just run another cvsup from cvsup3 and got a VERY large number of changes. Seems like something might be broken at cvsup14. But it's not totally dead as I have been getting port updates from cvsup14 just fine. As I final check, I cvsuped my ports from cvsup3 and got only a few changes. So it looks like something is wrong with its src-all mirror. Could you please report this to cvsup14's maintainer, [EMAIL PROTECTED]? By the way, all of the CVSup mirror site maintainers are listed in the FreeBSD Handbook here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html#CVSUP-MIRRORS Thanks, John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Possible problems with cvsup14.freebsd.org
In article [EMAIL PROTECTED], faSty [EMAIL PROTECTED] wrote: try cvsup10.freebsd.org. they are rieable cvs server. They are _all_ reliable, but that doesn't mean there are never ever any problems. Please, if you suspect a problem with a mirror site then find the address of its maintainer in the FreeBSD Handbook (section A.6.7 currently) and let him know. Thanks, John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Unsopported relocation type?
In article [EMAIL PROTECTED], Chris BeHanna [EMAIL PROTECTED] wrote: On Tue, 9 Apr 2002, Karl M. Joch wrote: Hello, i got that one on a freebsd 4.5 server running mostly only samba 2.2.3a with about 50 workstations. /usr/libexec/ld-elf.so.1: /usr/lib/libcrypto.so.2: Unsupported relocation type 85 in non-PLT relocations PLT == Procedure Linkage Table Supposedly, this type of error can occur when non-PIC code is linked into a shared object. I don't think it's that. The valid relocation types are the values 0 thru 10. 85 is way out of range and would be invalid for any i386 executable or library, whether PIC or not. BTW, linking non-PIC code into a shared library generally works. It's just inefficient. It could also be caused by a non-corrected bit error in memory (cosmic ray at an inopportune time while the rtld was doing its thing?). Yes, I'm betting it's that or a corrupted file. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: CVSUP Mirror brain damage
In article [EMAIL PROTECTED], Michael Sierchio [EMAIL PROTECTED] wrote: It appears that cvsup2.freebsd.org is long gone. How to we get it off the list of mirrors, and/or of course see to it that it no longer is aliased to a host which isn't a cvsup mirror? I removed cvsup2 from the list of mirrors over a month ago, but I forgot to have its DNS record deleted. I have asked our hostmaster to do that now. We'll have a replacement for cvsup2 soon, maybe even this week. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup server warnings; /usr/local/etc/cvsup/prefixes/FreeBSD.cvs
In article [EMAIL PROTECTED],
Jason Hunt [EMAIL PROTECTED] wrote:
I don't know if it's just something I missed, or if this has been answered
before, but when I try cvsup'ing my ports I get numerous messages about
not being able to write
/usr/local/etc/cvsup/prefixes/FreeBSD.cvs/{port-section}/{port-name}/files/patch-*,v
and
/usr/local/etc/cvsup/freebsd/FreeBSD.cvs/{port-section}/{port-name}/pkg-*
I am using cvsup 16.1e and cvsup2.ca.freebsd.org
My supfile is as follows:
*default host=cvsup2.ca.FreeBSD.org
*default base=/usr
*default prefix=/usr
*default release=cvs tag=.
*default delete use-rel-suffix
*default compress
ports-all
I seriously doubt that that's the supfile you are using. Those
error messages just don't correspond to it at all. First, the
supfile specifies a prefix of /usr, but the error messages
indicate that the prefix is really prefixes/FreeBSD.cvs. Second,
it is complaining about *,v files, which you wouldn't be getting
if you had tag=. in your supfile.
This looks exactly like you are using the supfile from the
cvsup-mirror port, not the one you posted.
John
--
John Polstra
John D. Polstra Co., Inc.Seattle, Washington USA
Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-stable in the body of the message
Re: cvsup server warnings; /usr/local/etc/cvsup/prefixes/FreeBSD.cvs
In article [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Try another mirror No, that's not the problem. It's on the user's end. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup server warnings; /usr/local/etc/cvsup/prefixes/FreeBSD.cvs
In article [EMAIL PROTECTED], Maxime Romano [EMAIL PROTECTED] wrote: I've been getting the exact same problems at three diffrent locations. You should use cvsup.ca.freebsd.org. Did that actually fix it for you? If so, cvsup.ca.freebsd.org is seriously screwed up. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: find /usr/src -mtime -0
In article [EMAIL PROTECTED], Ruslan Ermilov [EMAIL PROTECTED] wrote: On Tue, Sep 25, 2001 at 02:46:52PM -0700, Kent Stewart wrote: Could this be a side effect of the 9 Sept 01 Cvsup Error. The S1G Cvsup bug makes the dates come out 31 Dec 69 instead of 10 Sep 01. If this 69 is 2069, that is definitely the problem! It was a pretty strange bug, but I don't think it would have been able to set the modtime to anything except the epoch+0, i.e., 1970-01-01 00:00:00 UTC. Note, this maps onto the end of 1969 in many time zones. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: HEADS UP: find /usr/src -mtime -0
In article [EMAIL PROTECTED], Kent Stewart [EMAIL PROTECTED] wrote: How do you wake up some of the cvsup site managers. For example, cvsup4.freebsd.org has been told at least twice going back to 12 Sep 01 that he is running the old version. That site is still pumping out source with the S1G bug. A cvsup started at 9:25 PDT shows Connected to cvsup4.FreeBSD.org Server software version: REL_16_1 Confirmed. I have removed this site from the list in the Handbook, and have asked the freebsd.org hostmaster to delete its DNS record. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Update to fix CVSup timestamp bug
In article [EMAIL PROTECTED], Eugene Grosbein [EMAIL PROTECTED] wrote: I have fixed the bug and have released a new snapshot of CVSup, SNAP_16_1d. I have also created binary packages for FreeBSD-4.x which can be installed using pkg_add. For information about updating your CVSup installation, look here: Please issue an announcement about your plans of creating binary packages for FreeBSD 3.5, will such package be released or not? I don't think a packages for -3.5 will be released. I don't have any way myself to build binaries for -3.x. However, you can build the port from source. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Update to fix CVSup timestamp bug
In article [EMAIL PROTECTED], Eugene Grosbein [EMAIL PROTECTED] wrote: Thank you once more. Our local cvsup-mirror still runs with 3-STABLE. I've successfully built /usr/ports/net/cvsup-devel. Could you please give me a hint how to build a package not requiring Modula's additional packages to exist in the system? How to include these modules 'static'? You can build the port statically-linked by setting STATIC=yes in the environment before building. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: /sys/crypto not getting check out with src-all
In article [EMAIL PROTECTED], Eugene Panchenko [EMAIL PROTECTED] wrote: Hi! It seems that there's a problem with 4.4-RC. I have src-all specified in my stable-supfile, stiff, crypto (and sys-crypto) is not check out. There is simply no such directory as /usr/src/sys/crypto (though it is in CVS and I can get all the files). I've notice this when trying to build my kernel with NETSMBCRYPTO (or likewise) option. Could I hope this is my fault, or if it's not, for this to be fixed?? This is kinda weird (not to mention that is' annoys me) since it's stated in /usr/share/examples/cvsup/stable-supfile that all those used-to-be USA-restrivted distributions (des, and stuff) are now part of src-all distro. That's correct. Do you have a refuse file? (See the section REFUSE FILES in cvsup(1).) If so, please post it. Also please post your supfile. I'm sure there's a simple explanation for the problem. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsuping
In article [EMAIL PROTECTED], Tomas Palfi [EMAIL PROTECTED] wrote: i'am trying to cvsup on 4.3 stable and as i am connected through a firewall i've been at it for a relatively long time. the messages i was getting were all related to the firewall configuration (ie. connection refused, not being able to get to the open at all etc.) we tweaked our firewall and now i seem to be getting out with maranello# cvsup -g -L2 stable-supfile /var/tmp/dest (** the same happen when i use -P m) Parsing supfile stable-supfile Connecting to cvsup.uk.Freebsd.org Connected to cvsup.uk.Freebsd.org Premature EOF from server ( why is it premature ) Will retry at 16:48:40 when i test the connection to any cvsup-server with telnet cvsup.uk.freebsd.org 5999 this is what i get Trying 195.40.6.42... Connected to cvsup.plig.net. Escape character is '^]'. Connection closed by foreign host. maranello# would anyone know please where the problem is?? There is something wrong with your firewall or with the way it is configured. I doubt that any of us can help solve this problem. Only your firewall administrator can fix it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup via socks5
In article [EMAIL PROTECTED], James Satterfield [EMAIL PROTECTED] wrote: WooHoo It works! Thank you Philippe! [...] jester# runsocks cvsup -L 2 ports-supfile When using SOCKS, you must also add @M3novm to the cvsup command line -- anywhere on the command line. If you don't, it will eventually die with a Bad address error. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: ports and cvsup
In article [EMAIL PROTECTED], Jeroen Heijungs [EMAIL PROTECTED] wrote: Every week I do a cvsup for all sources, docs and ports, with the default cvsup cfg files in /usr/share/examples/cvsup. But..., with almost every port I want to install I get the message about the old port layout. When I go to the ftp server get the port skeleton, install that and do the make again everything works fine. I thought that the cvsup was to avoid that kind of problems, but obviously I made somewhere a mistake (or haven't read enough). Probably when you ran CVSup for the first time, you already had a ports tree on your system. CVSup does a pretty good job of adopting existing files, but when you use it like that it will not delete old files which normally should be deleted. That's because it doesn't think it owns those files, because it didn't create them in the first place. In most situations, it doesn't hurt anything to have a few extra files lying around. Unfortunately, the ports tree is very sensitive to that. There is a safe way to adopt existing trees with CVSup. It's described in the CVSup FAQ here: http://www.polstra.com/projects/freeware/CVSup/faq.html#caniadopt and in the two questions that follow it. Your safest bet at this point would be to delete your entire ports tree and re-fetch it with CVSup. (Don't use the -s option.) The ports tree is relatively small, so it won't take too awfully long. Or, if you are careful and know what you're doing, you can probably get things working by doing a systematic manual deletion of all subdirectories named patches and pkg in your entire ports tree. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Hard lockups since cvsup'ing Jul 1st. Help!
In article [EMAIL PROTECTED], Robert L Sowders [EMAIL PROTECTED] wrote: I took a look at the cvsweb and noticed that mfs_vfsops.c was marked as removed at version 1.93 4 weeks ago by phk, It was removed in -current, but not in -stable. A file in CVS can exist in some branches but not in others. but two weeks ago version 181 was added and updated by 1.82 but the dates are backwards on the versions. Screwy eh? That is not what I see when I look at cvsweb or use cvs log. There was a commit to the mfs_vfsops.c file done on Jun 17, that may have been kinda screwy, or maybe it's just the cvs system. That commit was on the RELENG_4 branch (-stable), where the file is still alive. Nothing screwy there. version 1.81 is marked as occuring on Jun 17, 2001 and version 1.82 occurred at Apr 15 2000. I don't know where you saw that. CVSWeb shows a date of Dec 19, 1999 for revision 1.81 and Apr 15, 2000 for revision 1.82. That agrees with what is recorded in the actual RCS file. I'm not sure if cvsup uses the date or the version when it's supping files, If you are asking for the -stable branch with tag=RELENG_4 then CVSup uses the version. Checking my srcs locally it appears that indeed my cvsup pulled version 1.81.2.1 dated 2001/06/17 which is wrong and does not have the add in version 1.82. That is exactly what CVSup should have done. Revision 1.82 is not a part of -stable; it is in -current only. -stable was branched at revision 1.81, before revision 1.82 was created. For -stable, the revision after 1.81 is 1.81.2.1. Next will come 1.81.2.2, etc. I wonder how many other things are screwy in the cvs repository? I don't see anything screwy there. :-) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: NIS/YP still broken!
In article [EMAIL PROTECTED], Andre Albsmeier [EMAIL PROTECTED] wrote: The map here looks slightly different: 0x8048000 0x804d000 5 0 0xd6927ea0 r-x 1 0 0x0 COW NC vnode 0x804d000 0x804f000 2 0 0xd6894d20 rw- 2 0 0x2180 NCOW NNC default 0x804f000 0x8066000 16 0 0xd6894d20 rwx 2 0 0x2180 NCOW NNC default --- additional 0x1804d000 0x1805e000 17 0 0xd73f4d80 r-x 10 5 0x0 COW NC vnode 0x1805e000 0x1805f000 1 0 0xd7246ba0 rw- 1 0 0x2180 COW NNC vnode 0x1805f000 0x18061000 2 0 0xd72ec540 rw- 2 0 0x2180 NCOW NNC default 0x18061000 0x18069000 5 0 0xd72ec540 rwx 2 0 0x2180 NCOW NNC default 0x18069000 0x180e6000 103 0 0xc0280300 r-x 104 45 0x0 COW NC vnode 0x180e6000 0x180eb000 5 0 0xd71fba20 rwx 1 0 0x2180 COW NNC vnode 0x180eb000 0x180ff000 7 0 0xd7b96c60 rwx 1 0 0x2180 NCOW NNC default 0xbfbe 0xbfc0 4 0 0xd79b18a0 rwx 1 0 0x2180 NCOW NNC default That's OK. So im my case it is: || VV 0x1804d000 0x1805e000 17 0 0xd73f4d80 r-x 10 5 0x0 COW NC vnode 0x1805e000 0x1805f000 1 0 0xd7246ba0 rw- 1 0 0x2180 COW NNC vnode 0x1805f000 0x18061000 2 0 0xd72ec540 rw- 2 0 0x2180 NCOW NNC default 0x18061000 0x18069000 5 0 0xd72ec540 rwx 2 0 0x2180 NCOW NNC default ^^ || Right. Done, I have now: static char *rtld_base = (char *)0x1804d000; /* Patch me */ static char *rtld_limit = (char *)0x18069000;/* Patch me too */ Right. I have a corefile but can't debug it: Core was generated by `yppush'. Program terminated with signal 11, Segmentation fault. Cannot access memory at address 0x180600a8. #0 0x1804f358 in ?? ()Cannot access memory at address 0x180600a8. Anything I did wrong? No, I forgot a step. :-) When you run yppush, set LD_BIND_NOW=1 in the environment. (And I _hope_ that won't make it stop failing.) John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: CVSup through ssh tunnel
In article [EMAIL PROTECTED], Marc Fonvieille [EMAIL PROTECTED] wrote: I try to upgrade source tree on my laptop through a ssh tunnel: the laptop is on my lan and only one box (the gateway) can access to the Internet. From the laptop, i launch the following command: laptop:/home/marc% ssh -2 -N -f -L 5999:cvsup.uk.freebsd.org:5999 gateway Then i su to root and i launch: laptop:/home/marc# cvsup -g -L 2 doc-supfile [...] Ok the doc is updated, i do the same with the ports and it succeeded. But when i cvsup the source tree, it gives me: laptop:/home/marc# cvsup -g -L 2 stable-supfile Parsing supfile stable-supfile Connecting to localhost Connected to localhost Server software version: REL_16_1 Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully without any changes in /usr/src (the sources are old 4.3-BETA). Do you have a refuse file in one of the following places? /usr/sup/refuse /usr/sup/src-all/refuse /usr/sup/src-all/refuse.cvs:RELENG_4 Are you sure that the server host you are using is keeping its src-all collection up-to-date? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frankenstein Port: /usr/ports/www/jakarat-tomcat
In article [EMAIL PROTECTED], John Merryweather Cooper [EMAIL PROTECTED] wrote: Jamie Hermans wrote: On Sun, 20 May 2001 19:27:28 -0700, [EMAIL PROTECTED] (John Merryweather Cooper) wrote: This port is messing up my make update run--it apparently is stuck in a cycle between installing itself and deleting itself. Need someone with a good wooden stake to finish it . . . :) I just: rm -f /usr/ports/www/jakarat-tomcat It fixed itself the next time around. Nope. Tried that . . . it comes back!! Someone kill it . . . I had to make manual changes to that port in the repository over the weekend to fix damage caused by a problem commit last year. (A regular file named files had been committed accidentally, and now a committer wanted to create a directory by that name.) I tested all the permutations of cvs update and CVSup I could think of, so I don't understand why you're having problems. If this was your first update since mid-December, that could explain it. Steps: 1. rm -rfd /usr/ports/www/jakarat-tomcat 2. make update --reinstalls itself here 3. make update --tries to deinstall itself and causes make update to fail Unfortunately, make update can do 3 entirely different things depending on the setting in your make.conf, so the information you've provided doesn't tell me much. Could you please fire up the script program, run through the above commands again, and send me the typescript file that gets created? Also please send me the relevant variables from your /etc/make.conf file. The Makefile in /usr/ports suppresses printing of the commands, and I won't know which options were specified unless you send them to me explicitly. Thanks, John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frankenstein Port: /usr/ports/www/jakarat-tomcat
In article [EMAIL PROTECTED], Kent Stewart [EMAIL PROTECTED] wrote: David W. Chapman Jr. wrote: That's just it I believe the problem is fixed, or at the cvs one, not the cvsup one(if there is a problem with cvsup). Once you delete your checkout file all is well and fixed No, it isn't fixed or at least because a very recent update from cvsup13 doesn't work. The first thing it does is checkout the two patch files and tomcat.sh. Then, it tries to delete the directory, which fails because it isn't empty. Let me try to clear up the confusion. There's a combination of things going on. 1. There was a problem in the CVS repository. I fixed that manually during the weekend. The repository is fine now. 2. My manual fix of the repository provoked a bug in CVSup which is affecting some people. I had run a bunch of tests before making the repository fix, but my tests were inadequate to find this particular problem. I know more or less what is happening and will be able to fix the bug, but you shouldn't wait for that. You should work around it (see below). 3. The nature of the bug is such that it creates a bogus entry in the checkouts file. That causes the problem to keep happening until the checkouts file is repaired manually or removed. I posted instructions on how to fix the file in a separate mail. Basically, you have to edit the checkouts file and delete all lines containing jakarta-tomcat. 4. Removing the checkouts file works too, but it's a sledge hammer approach and is better avoided. There's useful information in there, so it's better not to throw it away. 5. Somebody suggested adding an entry to the refuse file to ignore the jakarta-tomcat port. That probably hides the problem, but it doesn't really fix anything. The breakage is still there in your checkouts file. Therefore I don't recommend using the refuse file as a work-around. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frankenstein Port: /usr/ports/www/jakarat-tomcat
In article [EMAIL PROTECTED], John Merryweather Cooper [EMAIL PROTECTED] wrote: Steve Coltrin wrote: (cvsup barfing on ports/www/jakarta-tomcat:) I fixed the problem on my system by editing out all references to jakarta-tomcat in /usr/sup/ports-all/checkouts.cvs:. (period included). Now I can cvsup repeatedly without problems. Well, I could do that except: 1) defeats the purpose of maintaining a current ports tree; No it doesn't. It fixes the problem. Don't worry, those lines will come back (corrected) when you run cvsup. 2) doesn't fix it for anyone who hasn't hacked checkout.cvs. This should be fixed, not blocked on individual machines. I'm sure the daemons are busy in the background figuring out a fix. I recommend against waiting around for that. The real fix is going to be in CVSup, and it's going to take me some time. Sorry, that's just life. It's Monday, I'm barely recovering from the flu, and I'm swamped with work from my real jobs. It'll be a while. So the work-around is your best bet unless you're very patient. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frankenstein Port: /usr/ports/www/jakarat-tomcat
In article [EMAIL PROTECTED], John Merryweather Cooper [EMAIL PROTECTED] wrote: Yes, nuking /usr/sup/ports-all/checkout.cvs:. works. Might be nice if this feature of cvs was quashed with a fairly heavy sledge hammer. :) This originated with a cvs problem, that's definitely true. Unfortunately, the fix for that problem provoked a completely separate bug in CVSup. So cvs doesn't deserve all the blame. :-( John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: Frankenstein Port: /usr/ports/www/jakarat-tomcat
Chad R. Larson wrote: I'm assuming none of this affects those of us who are using CVSup to maintain a local copy of the repository, and using cvs for our local ports tree. Correct. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA Disappointment is a good sign of basic intelligence. -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
Re: cvsup dumps core
In article [EMAIL PROTECTED], Michael R. Wayne [EMAIL PROTECTED] wrote: With the recent ntpd exploit, I wanted to update only the files in /usr/src/contrib/ntp/ntpd. Based on the man page, I should be able to use -i to do this. But cvsup seems pretty unhappy: 1162 /usr/local/bin/cvsup @M3stackdump -g -L 2 -i ntpd /usr/local/etc/stable-supfile I don't know why you got a core dump. It doesn't do that here when I try it. Unrelated to the core dump, you didn't use the -i option quite right. As the man page says: "The pattern is a standard file name pattern. It is interpreted relative to the collection's prefix directory." So you should have used "-i src/contrib/ntp/ntpd". John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: xconsole broken in recent 4.3-RC?
In article [EMAIL PROTECTED], Eriya Akasaka [EMAIL PROTECTED] wrote: /etc/fbtab ? In article [EMAIL PROTECTED], On Mon, 02 Apr 2001 18:49:54 -0700 (PDT) "xconsole broken in recent 4.3-RC?" John Polstra [EMAIL PROTECTED] wrotes: jdp I've just noticed that xconsole no longer works under 4.3-RC from jdp March 24. Yep -- thanks, that was it. I must have clobbered it when I ran mergemaster. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Repeatable panic copying ATAPI audio CD to SCSI disk
With a 4.3-BETA kernel from today (and also with one from a month or
two ago) I can easily induce a panic by trying to copy an audio CD
from an ATAPI drive to a SCSI disk on an ahc controller using this
command:
dd if=/dev/acd0c of=image1 bs=23520
I have no idea if this is a reasonable way to copy the image. I never
tried it before today. It shouldn't cause a panic, of course.
Using remote kgdb I got a stack trace:
Program received signal SIGTRAP, Trace/breakpoint trap.
Debugger (msg=0xc02c60a3 "panic") at ../../i386/i386/db_interface.c:319
319 in_Debugger = 0;
(kgdb) where
#0 Debugger (msg=0xc02c60a3 "panic") at ../../i386/i386/db_interface.c:319
#1 0xc016eb7c in panic (fmt=0xc02bf2ea "for safety")
at ../../kern/kern_shutdown.c:554
#2 0xc013e6d4 in ahc_handle_seqint (ahc=0xc0ec8800, intstat=113)
at ../../dev/aic7xxx/aic7xxx.c:407
#3 0xc0148edd in ahc_platform_intr (arg=0xc0ec8800)
at ../../dev/aic7xxx/aic7xxx_inline.h:472
#4 0xc02ab8c5 in intr_mux (arg=0xc072b760)
at ../../i386/isa/intr_machdep.c:582
#5 0xc0282226 in atapi_read (request=0xc0ffcd00, length=23520)
at machine/cpufunc.h:222
#6 0xc0281cc7 in atapi_interrupt (request=0xc0ffcd00)
at ../../dev/ata/atapi-all.c:385
#7 0xc027b7e6 in ata_intr (data=0xc0ebed80) at ../../dev/ata/ata-all.c:1150
The panics always involve the ahc device interrupting in the middle of
an ata interrupt. (Is that even supposed to happen, ever?)
The console prints this (copied by hand):
ahc1:A:2: ahc_intr - referenced scb not valid during seqint 0x71 scb(0)
ahc1: Dumping Card State at SEQADDR 0x18f
SCB count = 20
Kernel NEXTQSCB = 14
Card NEXTQSCB = 14
QINFIFO entries: 0
Waiting Queue entries:
Disconnected Queue entries: 5:14
QOUTFIFO entries:
Sequencer Free SCB List: 2 0 1 3 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
24 25 26 27 28 29 30 31
Pending list:
Kernel Free SCB list: 0 16 19 17 7 18 15 1 2 3 4 5 6 8 9 13 12 11 10
panic: for safety
Debugger("panic")
The ATAPI drive is a Plextor 1610A CD-RW, and I am running it in PIO
mode. It also panics the same way in DMA mode.
The destination filesystem has soft-updates turned on. I have never
seen any problems with this machine's SCSI subsystem.
The dmesg output and kernel config file are at the end of this mail.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
Copyright (c) 1992-2001 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 4.3-BETA #6: Sun Mar 11 17:14:38 PST 2001
[EMAIL PROTECTED]:/c/src/sys/compile/VASHON
Timecounter "i8254" frequency 1193041 Hz
Timecounter "TSC" frequency 400861711 Hz
CPU: Pentium II/Pentium II Xeon/Celeron (400.86-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x651 Stepping = 1
Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,
PSE36,MMX,FXSR
real memory = 134217728 (131072K bytes)
sio1: gdb debugging port
avail memory = 126648320 (123680K bytes)
Preloaded elf kernel "kernel.new" at 0xc03cb000.
Pentium Pro MTRR support enabled
npx0: math processor on motherboard
npx0: INT 16 interface
pcib0: Intel 82443BX (440 BX) host to PCI bridge on motherboard
pci0: PCI bus on pcib0
pcib1: Intel 82443BX (440 BX) PCI-PCI (AGP) bridge at device 1.0 on pci0
pci1: PCI bus on pcib1
pci1: Matrox MGA Millennium II 2164WA-B AG graphics accelerator at 0.0 irq 0
isab0: Intel 82371AB PCI to ISA bridge at device 7.0 on pci0
isa0: ISA bus on isab0
atapci0: Intel PIIX4 ATA33 controller port 0xffa0-0xffaf at device 7.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
pci0: Intel 82371AB/EB (PIIX4) USB controller at 7.2
chip1: Intel 82371AB Power management controller port 0x440-0x44f at device 7.3 on
pci0
pcib2: DEC 21152 PCI-PCI bridge at device 16.0 on pci0
pci2: PCI bus on pcib2
fxp0: Intel Pro 10/100B/100+ Ethernet port 0xef40-0xef5f mem
0xfea0-0xfeaf,0xfd0ff000-0xfd0f irq 11 at device 17.
0 on pci0
fxp0: Ethernet address 00:e0:81:10:09:c2
ahc0: Adaptec aic7895 Ultra SCSI adapter port 0xe400-0xe4ff mem
0xfebfe000-0xfebfefff irq 10 at device 18.0 on pci0
aic7895C: Wide Channel A, SCSI Id=7, 32/255 SCBs
ahc1: Adaptec aic7895 Ultra SCSI adapter port 0xe800-0xe8ff mem
0xfebff000-0xfebf irq 10 at device 18.1 on pci0
aic7895C: Wide Channel B, SCSI Id=7, 32/255 SCBs
fxp1: Intel Pro 10/100B/100+ Ethernet port 0xef80-0xef9f mem
0xfe80-0xfe8f,0xfd0fe000-0xfd0fefff irq 9 at device 20.0
on pci0
fxp1: Ethernet address 00:a0:c9:b0:13:df
atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0
atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0
psm0: PS/2 Mouse irq 12 on atkbdc0
psm0: model Gener
Re: cvsup confusion
In article [EMAIL PROTECTED], Mark Drayton [EMAIL PROTECTED] wrote: I wrote a small script to cvsup stable, ports and doc every couple of days by running cvsup supfile logfile for each collection. Somehow this script appears to have 'gone wrong' leaving several copies of cvsup running at once. Is running more than one copy of cvsup at once likely to have damaged /usr/src or /usr/ports? I don't know whether it would mess up your files or not, but it's definitely something that won't work right in general. Check out cvsup's "-l" option in the cvsup man page to keep this from happening. Or run it under lockf(1). Sorry if these are common questions - I searched the archives but couldn't find anything. Searching the archives is fine. But don't forget, there's a great big manual page too. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Mysql segfaults; is the culprit libstdc++, pthread, regex ...?
In article [EMAIL PROTECTED],
Matthew Reimer [EMAIL PROTECTED] wrote:
We've been having problems with mysql segfaulting. It seems to occur
when it tries to return from a function, so maybe the stack is getting
stomped.
Sergey Osokin recently reported a very similar problem
on a different threaded C++ program. See message ID
[EMAIL PROTECTED] in the -hackers archives -- it
contains a small test case. I spent a few hours looking at it last
weekend, but I wasn't able to solve the problem. The failure occurs
in a function like this:
void
SS::run()
{
string s; // !!!
string s1; // !!!
sleep(1);
}
Upon returning from the function, the destructors for s1 and s get
called, in that order. The first one seems to corrupt the stack or
a register somehow, such that the code leading up to the call of the
second destructor dereferences a garbage pointer. In Sergey's case,
merely re-ordering two declarations in a different function makes the
problem appear or disappear:
void
SS::spawn()
{
#ifdef BAD
int rc;
Guard guard(m1); // !!!
#else
Guard guard(m1); // !!!
int rc;
#endif
According to Sergey, the problem arose in -stable some time around 12
November 2000. Sergey has been doing some further investigation to
narrow down the changes that caused the problem. I haven't had time
to digest his findings yet, and due to work pressures I may not find
time soon.
In any case, this appears to be a genuine bug that we (FreeBSD)
introduced.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Satoshi - Ports Wraith - Asami [EMAIL PROTECTED] wrote: * From: John Polstra [EMAIL PROTECTED] * If it contains a new libc, that seems like the real problem * to me. It's always risky to use new libs (especially libc) with an * old kernel. New ports and packages didn't work with the old libc because someone moved stuff from libxpg4 to libc without changing the version numbers. Putting it in the upgrade kit was the only way to let 4.0R people use ports-current. That sounds like a good reason to me. Maybe you should have included a kernel in the upgrade kit too ... ;-) Maybe I should have insisted that the libc version change back then. I really wish we could keep the two version numbers from a.out, so I don't have to worry about stuff like this. : Sorry! John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Thomas David Rivers [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Satoshi - Ports Wraith - Asami) wrote: I really wish we could keep the two version numbers from a.out, so I don't have to worry about stuff like this. : You can, if you will accept some restrictions: Let's say the two numbers are the Version number and the Revision number. And, let's furthermore say we will restrict ourselves to only 99 revisions per Version. Then; let the Elf library number be: (100 * Version number) + Revision number *poof* two numbers... i.e. library version 10.20 would get 1020 as the Elf version number. Nope, that wouldn't provide the desired benefits. The whole point of having two version numbers is that they are treated differently. The a.out dynamic linker looked for an exact match on the major version number, and a = match on the minor number. Doing what you suggest wouldn't accomplish that -- we'd still get the exact match on both numbers. This all was discussed to death in the mailing lists when we switched to ELF, so pardon me if I refuse to let myself get drawn into another long-winded rehash of it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CVSup Source Code
In article [EMAIL PROTECTED], Peter Radcliffe [EMAIL PROTECTED] wrote: Tony Finch [EMAIL PROTECTED] probably said: You can't cvsup -STABLE src_all and ports with the same supfile because the ports tree isn't tagged and cvsup doesn't support multiple tags in the same supfile. You must use a separate supfile for src and ports. You can, it just doesn't support multiple _default_ tags. Hey, I know this is a radical suggestion, but maybe next time you guys could try reading the manual page which I so painstakingly wrote from scratch? Trust me, it'll take less work for you to read it than it took for me to write it. Here's what it says about the topic at hand: Default settings may be specified in lines whose collection name is *default. Such defaults will apply to subsequent lines in the supfile. Multiple *default lines may be present. New values augment or override any defaults specified earlier in the supfile. Values specified explicitly for a collection override any default values. The only thing that's not allowed multiple times in a single supfile is "host". John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Satoshi Asami [EMAIL PROTECTED] wrote: It was brought to my attention that recent 40upgrade kills all the networking programs. Looking at the plists, the only thing I can think of is that libc.so.4 has somehow lost backward compatibility. This isn't much to go on. What are the symptoms? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: libc shlib version
In article [EMAIL PROTECTED], Satoshi - Ports Wraith - Asami [EMAIL PROTECTED] wrote: * From: John Polstra [EMAIL PROTECTED] * In article [EMAIL PROTECTED], * Satoshi Asami [EMAIL PROTECTED] wrote: * * It was brought to my attention that recent 40upgrade kills all the * networking programs. Looking at the plists, the only thing I can * think of is that libc.so.4 has somehow lost backward compatibility. * * This isn't much to go on. What are the symptoms? I don't know much either, as I haven't experienced it myself. The reports say core dumps from fetch, etc. Please see PR #21997. OK, all those failures are signal 12 == SIGSYS == non-existent signal call. Somebody must have made a change to libc which caused it to start using a signal call that didn't exist in 4.0-RELEASE. So yes, I suppose that the version number of libc should be bumped. Likewise for libc_r, if it hasn't already been bumped for this release. What a pain -- that means yet another compatxx distribution. Whether the bump is still possible at this late date is a question for the Release Engineer. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Is sockstat broken in -stable?
On a -stable system from October 31, I'm seeing this from sockstat: alpha$ sockstat USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 131955 ? ? ? root sshd 131605 ? ? ? root sshd 1324 ? ? ? root lpd1256 ? ? ? root inetd 1204 ? ? ? root inetd 1205 ? ? ? root inetd 1206 ? ? ? root inetd 1207 ? ? ? root amd1064 ? ? ? root amd1065 ? ? ? root amd1066 ? ? ? root amd1067 ? ? ? daemon portmap 913 ? ? ? daemon portmap 914 ? ? ? root ntpd894 ? ? ? root ntpd895 ? ? ? root ntpd896 ? ? ? root syslogd 824 ? ? ? USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 1323 ? ? ? root inetd 1208 ? ? ? root inetd 1209 ? ? ? USER COMMANDPID FD PROTO ADDRESS root sshd 131956 stream ? root sshd 131606 stream ? root sendmail 1283 dgram ? root lpd1253 dgram ? root lpd1255 stream ? root cron 1224 dgram ? root amd1063 dgram ? root ntpd893 dgram ? root syslogd 823 dgram ? Userland and kernel are in sync. This is on an Alpha, though I don't know whether that's significant or not. Is anybody else seeing this problem? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: upgrade from 3.x
In article [EMAIL PROTECTED], Max Khon [EMAIL PROTECTED] wrote: make buildworld on 3.x of RELENG_4 is broken: [...] /usr/obj/usr/src/gnu/usr.bin/perl/miniperl/../libperl/libperl.a(pp_hot.o): In function `Perl_pp_aassign': pp_hot.o(.text+0x16a1): undefined reference to `setresuid' pp_hot.o(.text+0x16d4): undefined reference to `setresgid' *** Error code 1 Yep, I got the exact same problem here. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: pkg_info does not compile for 4.1.1-RELEASE
In article [EMAIL PROTECTED], Udo Schweigert [EMAIL PROTECTED] wrote: Hi all, due to a missing RELENG_4_1_1_RELEASE tag for src/usr.sbin/pkg_install/info/perform.c pkg_info is not built when doing a "make world" for 4.1.1. (Or: cvsup7.freebsd.org has the tag missing) It's not cvsup7's problem. The tag is missing on freefall. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: rdist and pam
In article [EMAIL PROTECTED], David Malone [EMAIL PROTECTED] wrote: I should mention that ssh does support a challenge-response ^^^ I presume you mean cvsup here. Yes, sorry for the typo. 3) I wasn't sure if you can adjust what gets pushed out to clients from a central config file. We have per machine exceptions. Actually I am testing just that sort of feature now, in preparation for the next release. :-) Cool - sounds useful. How far through this are you? The enhancement was submitted to me in fully working form by Olaf Wagner. It adds the concept of client classes, which are a lot like FreeBSD's login classes. There is an associated login.conf-like configuration file to control various aspects of what each class may do. For example, you can hide certain collections or even certain branches from some clients. From the point of view of those clients, the hidden collections and/or branches don't even exist. The config file syntax and the mechanism are extensible. I am doing a little restructuring of it and a lot of testing, with the goal of releasing a new version before the summer is over. If you're interested I can send you some examples of how we use per-machine exceptions here, which might give you some ideas. That would be great. Please send them to [EMAIL PROTECTED]. Yep, it's some strange interaction between some window managers and the M3 graphics library. It's mentioned in the BUGS section of cvsup(1). I'll try to find a similar workaround for tvtwm - should I let you know if I find one? Sure. But even the work-around mentioned in the man page doesn't really solve the whole problem. I think it has something to do with M3's use of the WM_TAKE_FOCUS window manager protocol. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Re[2]: CVSup server loads (was: Stable broken)
In article [EMAIL PROTECTED], Gabriel Ambuehl [EMAIL PROTECTED] wrote: Friday, July 21, 2000, 10:13:59 AM, you wrote: I was only adding a comment that one of the mirror owners made. The checking of the MD5 signature was supposed to be the limiting factor. [...] What about having cached MD5 sigs on the server as well as on the client (tough there's the problem with the people who like to patch their sources, but anyway)? I mean you only need to regenerate them when you update a file... Before this thread goes too far, let me tell you that I don't think the cost of the MD5 calculations is at all significant. In my CVSup profiling tests the MD5 calculation has never even made a blip on the radar screen. Calculating an MD5 signature is very cheap. It takes less CPU time than the venerable "sum" command. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: CVSup server loads (was: Stable broken)
In article [EMAIL PROTECTED], Kent Stewart [EMAIL PROTECTED] wrote: When cvsup7 was loaded (~20 users), a cvsup required 20 minutes or so. When it was really lightly loaded, I could cvsup 4-stable in 90 seconds. Of course the server load makes a significant difference. But I still think your hypothesis may have the cause and the effect interchanged. The reason the server is loaded is because the clients are taking a long time. And the reason the clients are taking a long time is because every file in ports needs an update. So naturally your update is going to take longer, and it would take longer even if you had the server all to yourself. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
CVSup server loads (was: Stable broken)
In article [EMAIL PROTECTED], Kent Stewart [EMAIL PROTECTED] wrote: That is where I finally got my cvsup update from. I thought cvsup8 was much slower than cvsup7 and then I found later that it wasn't very fast on either site. If you think this is bad then you weren't around in the days when we used sup. :-) Tagging makes everybody's updates take longer, and as a result the server's client counts go up. CVSup7 has a limit of 20, and I can tell you that machine is breathing pretty hard. But it seems to be performing quite well given the load. This is the first time I've ever seen it max out. Other than the increased load because of the number of clients, the bottleneck usually isn't in the server when the tree is tagged. The bottleneck is almost always your hard drive in that case, since it has to edit every file in your repository, write the edited version to a temp file, check the MD5 signature, and then move the temp file to the right place again. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: sshd/RSAPrivateDecrypt problems after make world
In article [EMAIL PROTECTED], Kris Kennaway [EMAIL PROTECTED] wrote: On Tue, 4 Jul 2000, Dan Langille wrote: As for src-crypto-rsa, it appears that /usr/share/examples/cvsup/secure- supfile needs to include that collection. I just added it to my supfile, resupped, and starting the build world again. Is any action being taken to resolve this issue? It's going to catch out a lot of people. Yes, I'm hoping Peter will fix it soon. I don't know why he didn't revert the change once he realised it was not the correct way :-( It has been fixed now. The file in question is back in its original collection, and the src-crypto-rsa collection is gone. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: cvsup in FreeBSD 4.0
In article [EMAIL PROTECTED], Michael Glenn Williams [EMAIL PROTECTED] wrote: Newbie behind firewall in California can't get through for my first cvsup. [...] Cannot connect to cvsup2.FreeBSD.org: Connection refused Will retry at 13:57:43 Retrying Cannot connect to cvsup2.FreeBSD.org: Connection refused Will retry at 14:08:52 Retrying Cannot connect to cvsup2.FreeBSD.org: Connection refused Will retry at 14:31:13 I'm not aware of any problems at cvsup2 lately. I think the problem is your firewall. It's not allowing your outbound connection to the CVSup server. Try a few different servers to make sure. If this is the problem, only your firewall administrator can help you solve it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Dynamic linker bug in 3.4-RELEASE (I think)
In article [EMAIL PROTECTED], Randall Hopper [EMAIL PROTECTED] wrote: | If I run it over-and-over many times repeatedly, occasionally the dynamic | linker will fail to resolve the "sigwait" symbol. | |Is your program multi-threaded? There are some known problems in |connection with that. This program isn't threaded, though I compiled it with -pthread (another util in that dir is threaded, and I'd used the same CFLAGS for both). |Try setting LD_BIND_NOW=1 in the environment and see if that changes |the behavior. That seemed to clear it up. (Though, it happens so rarely it's hard to be sure.) It may be a race between a signal handler and the mainline code, then. Or it could be that the pthreads library (libc_r) uses one or more internal threads which would make your application multi-threaded even if you didn't intend it to be. I will have to look again to see where things stand in the -stable version of the dynamic linker. I just got home from vacation, and the warm sunshine seems to have irradiated away most of my memory cells. :-) If it's convenient for you, please try using the dynamic linker from -current or 4.0. It should cure this problem, and it should build OK on a 3.4 system. (You can find it in "src/libexec/rtld-elf".) A word of caution: be very careful if you experiment with the dynamic linker. Almost nothing works if it is broken. (In particular, you won't be able to run the compiler to build a new one.) Make a backup copy named something like "/usr/libexec/ld-elf.so.1.good" first, so you can "mv" it back into place if something goes wrong. The basic utilities such as "mv" and "cp" are statically linked, so they'll still work even if the dynamic linker is broken. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: problem with /usr/src/libexec/rtld-elf/lockdflt.c:55
In article [EMAIL PROTECTED], Max Khon [EMAIL PROTECTED] wrote: hi, there! On 2 Feb 2000, Soren Dayton wrote: Whenever using jdk 1.1.8 (from ports), I find that I get: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:55 If I wait and let the process eat itself, the core file reveals a stack many thousands of frames deep of exactly this function. Does anyone know what's going on and if there's a fix? the fix was MFC'ed on Jan 28. make sure that you have src/libexec/rtld-elf/lockdflt.c,v 1.3.2.2 Actually that was a different "fix." :-} I haven't merged the real fix (in rtld.c) into -stable yet. I kind of, um, er ... forgot. I have made a note to do it today. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: problem with /usr/src/libexec/rtld-elf/lockdflt.c:55
In article [EMAIL PROTECTED], Max Khon [EMAIL PROTECTED] wrote: the fix was MFC'ed on Jan 28. make sure that you have src/libexec/rtld-elf/lockdflt.c,v 1.3.2.2 Oops, I just realized my previous reply was wrong. You are right about JDK -- the fix in lockdflt.c should make it work. The later fix affected linuxthreads, not JDK. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Host command output changed in bind 8.2.2p5
In article [EMAIL PROTECTED], Bob Willcox [EMAIL PROTECTED] wrote: I have noticed that the host command no longer produces the same output as it did prior to the bind 8.2.2p5 import to 3.4. For machines with an MX record prior to bind 8.2.2p5 I used to get: bob@obiwan-p4 /home/bob host umd1.umd.edu umd1.umd.edu is a nickname for haven.umd.edu haven.umd.edu has address 128.8.10.6 haven.umd.edu mail is handled (pri=4) by haven.umd.edu But now on a recently upgraded 3.4-stable system I get: bob@luke:p6 /home/bob host umd1.umd.edu umd1.umd.edu is a nickname for haven.umd.edu haven.umd.edu has address 128.8.10.6 haven.umd.edu has address 128.8.10.6 Yep, I just noticed the same thing yesterday. It's broken, I'd say. (Same story in -current). John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Huge differences in suid programs ?
Vadim Belman wrote:
Makes sense. I was just going by the examples in
/etc{/defaults}/make.conf. If COPY is more correct, should
/etc{/defaults}/make.conf be changed?
John Yes, I think so.
Wouldn't it slow down the installworld?
No, it wouldn't change anything because the line in make.conf is just
a comment. :-)
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: SetAttrs src/contrib/diff/diff3.c,v
John wrote: I was looking at the docs for cvsup, and I might have missed it, but what is the structure of the line in your supfile to specify a umask? I was toying with the idea of making the entire /usr/src tree mode 600, just to make sure I knew who/what was writing/reading it (especially the custom kernel file), but I don't think I've hit on the correct syntax of the line. If you want it to apply to all your collections, put it at the top of the supfile like this: *default umask=077 If you want it to apply just to a single collection, put it on the collection line: src-all umask=077 John --- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SetAttrs src/contrib/diff/diff3.c,v
In article [EMAIL PROTECTED], The Unicorn [EMAIL PROTECTED] wrote: Just wondering why I see a *LOT* (as in one for each source file on the system) of SetAttrs messages coming over my screen, when I am cvsupping 3.3-STABLE on one system I own. While other systems act normally (loading delta's and other stuff)... Make sure you run cvsup as the same user and with the same umask each time. You can specify the umask in the supfile if you want to be sure about that. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Route table leaks
Brad Knowles wrote: In -CURRENT, I would say that this could probably be committed, if John feels safe. I am not yet convinced that it should be committed to -STABLE, although things do look good so far. Just to clarify, I committed it to -current already this morning. John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Screen Blackness
In article [EMAIL PROTECTED], eirvine [EMAIL PROTECTED] wrote: Just cvsupped stable, made a new kernel, made world, rebooted, and had my dinner glass of wine :*) Came back and instead of my usual screensaver (fire) there was just a black screen. Keyboard input, mouse input etc did not change this. No response. I managed to login "blind" and issue a "reboot". At which stage FreeBSD rebooted. I'd like to provide more details -- but my hands - or eyes were tied. After a second glass, I've managed to repeat the problem. We need more details in order to diagnose this problem. What kind of wine? What vintage? Did you enjoy it? How much did it cost? Do you feel it was at its peak, or could it benefit from a bit more cellaring? Would you say it was better than a working FreeBSD system, or worse? Have you tried repeating the problem with other varieties of wine? We are here to help you, but you'll have to do your part. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: buildword curiousities
In article [EMAIL PROTECTED], Gary Palmer [EMAIL PROTECTED] wrote: Since best.com got assimilated, cvsup2.freebsd.org (aka burka.rdy.com) is off verio.net. The trouble with cvsup2 is that it has a limit of only 6 clients at a time. It's usually maxxed out. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
