Date: Sun, 28 Jul 2002 12:37:33 -0400 From: Alan E <alane@geeksrus.net> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: Alan E <alane@geeksrus.net>, FreeBSD Ports List <ports@FreeBSD.ORG> Subject: Re: troubles with the FAM port Message-ID: <20020728163732.GA5503@wwweasel.geeksrus.net> In-Reply-To: <200207281557.g6SFvu7Y004074@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> References: <200207181631.g6IGVLJ1037421@250-217.customer.cloud9.net> <20020718182425.GA41703@wwweasel.geeksrus.net> <200207270421.g6R4LZ3K046239@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp> <20020727162242.GA82166@wwweasel.geeksrus.net> <200207281557.g6SFvu7Y004074@silver.carrots.uucp.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 29, 2002 at 12:57:55AM +0900, Seigo Tanimura wrote: >On Sat, 27 Jul 2002 12:22:42 -0400, > Alan E <alane@geeksrus.net> said: > >Alan> 1. What is the standard compiler for ports on -current? > >I understand that the portbld gcc31 is the standard one for C++ at the >moment. > >I could ifdef the gcc31-dependent part in the patch, though. Please do, if the means ifdef'ing on gcc version. I wouldn't do it on bsd date (version), though. >Alan> 2. What affect does all this assert code have on -stable compilation? I >Alan> believe it's ifdef'd out, which is good. > >The ifdef in the __assert() code detects the number of __assert() >arguments. __assert() of current takes 4 arguments, while that of >stable takes only 3. > >RCS file: /home/ncvs/src/lib/libc/gen/assert.c,v >---------------------------- >revision 1.3 >date: 2001/10/24 18:12:18; author: asmodai; state: Exp; lines: +10 -5 >Add __FBSDID. >Change __assert() function to print failing function name. >#if 0 the sccsid block. >This makes us C99 conforming. >---------------------------- > >Alternatively, it could be done in configure. That sounds ugly. Is this assert change a FreeBSD only thing, or a gcc thing? If a gcc thing, we should find some other way to check it. If it's a FBSD version thing, then just make sure you have the right version and we're fine AFAIAC. Let me know which case it is. If it's something that *must* be tested by configure, make sure changes are done to work with the right version of autoconf (whichever one it is that fam uses). But doing this is a last resort, and I really do not want to go there. If we do go there, they *must* be accepted for the SGI FAM tree or I won't put them in. This is not something we want to keep around and have to maintain. We want SGI to do that. >Alan> 3a. How well has this been tested? > >I tried to use fam via nautilus, but I have seen no assertion failure >yet, so not sure if assertion via syslog works. Please do the following: 1. Make a deliberate change to the code to force an assertion (say it's been up for N seconds/minutes, then make a stupid assertion. Test this.) >Alan> 3b, What happens if syslogd is down? > >Syslog messages are discarded until you run another syslogd process. Please test this by: 1. killing syslogd before a copy of fam is started, then run the above test code.. 2. killing syslogd after fam has started up, then run the above test code. 3. Restarting syslogd, then run the above test code, to make sure it resumes logging. Additional tests: Please make sure it runs correctly both from inetd and from standalone start. You don't need to duplicate all the assertion tests in each case, though. It'd probably be easier to do them using the inetd started fam. Follwup steps: Once the above tests pass, I will pass the code changes past the FAM maintainer at SGI for acceptance, If we can get them incorporated there, in a future version, then they're only temporary in our tree, and that's good. Finally, it needs to be tested against kde3, which is not yet -current ready. If the above tests pass, and we apply any changes suggested by SGI, I will commit after the appropriate PR is generated (I can do that if you want) to track the change, without kde3 testing, on the condition that you will install a full kde3 environment and fix anything that breaks. It will get tested simply by the commit happening, so you'll only need to do this in case of a failure, which I think is a very low probability occurence.. If you had a -stable machine kept relatively up to date as well, I'd ask if you want to maintain this, except for the fact that it is an integral part of KDE. But I'd be happy to have you continue to work with me on -current issuesi; I'd be grateful if you'd do so (I'd even add a comment in the Makefile listing you as -CURRENT co-maintainer). Thanks for all your patience with my requirements. I come from a background (Wall St trading floors) where crashes may mean unemployment for the programmer who didn't test a condtion that should have been tested. Since this is a system daemon, I expect the same level of reliability from it, and so I'm requesting fairly rigourous testing; it must remain at least as reliable as it is now under all circumstances. -- AlanE KDE-FreeBSD Team To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020728163732.GA5503>