Date: Sun, 13 Aug 2000 01:14:09 -0600 From: Warner Losh <imp@village.org> To: Mike Meyer <mwm@mired.org> Cc: freebsd-current@FreeBSD.ORG Subject: Re: Build breakage (was: fail to compile kernel...) Message-ID: <200008130714.BAA07153@harmony.village.org> In-Reply-To: Your message of "Sun, 13 Aug 2000 01:16:27 CDT." <14742.15675.412839.269577@guru.mired.org> References: <14742.15675.412839.269577@guru.mired.org> <14742.14082.837564.871879@guru.mired.org> <Pine.BSF.4.10.10008131504560.77390-100000@RedDust.BlueSky.net.au> <200008130553.XAA06673@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <14742.15675.412839.269577@guru.mired.org> Mike Meyer writes: : Warner Losh writes: : > In message <14742.14082.837564.871879@guru.mired.org> Mike Meyer writes: : > : The nasty downside of the the module system is that people who don't : > : adequately test module code before checking it in will screw up kernel : > : builds for kernels that don't need that code. : > But I did test it. But I had an uncommitted file on my machine... : : Won't the 'cvs diff' command tell you about such things? If not, : that's yet another argument for ditching cvs in favor of something : without so many flaws (like Perforce). Not when the files are in multiple different directories and you have mutliple patches cooking in your tree. I committed files in sys/pccard, but they depended on one in sys/dev/pccard which I honestly thought I'd checked in with an earlier newcard fix. I'd been running the patches long enough that I basically forgot. This was clearly my fault. : > : Since you probably don't need the oldcard module. Just comment it out : > : of /usr/src/sys/modules/Makefile, and rebuild the kernel. You may want : > : to comment out pccard as well. : > Or you can just update your sources. There was a 8 hour window where : > this was broken... : : Well, it was still broken as of about 30 minutes before he asked the : question. I'd look at it for trivial fixes, then just quit trying to : build it because I wasn't going to need it. No. It is not still broken. I committed a fix for this a while ago (like Friday Morning after breaking it late Thursday night) and have done a buildworld and a kernel build on a different machine since then on fresher sources. If it truely is still broken, I need to know what you did. In fact, I did an cvsup and a cvs update and was able to build a kernel and modules w/o any problems on my -current box. : I didn't mean to finger you particularly. It's just a bit upsetting to : realize that I can't remember the last time I managed to do an update : to -current without some kind of breakage. I realize that -current : isn't guaranteed to build, but that's a bit ridiculous. I mean - I was : pleasantly surprised that I could build the world first time out. To : find the kernel breaking for a module that I have no absolutely no use : for on this machine was a bit upsetting. Well, that's the break's of -current. sometimes things are broken. Sometimes when you update, you get burned. Usually it just works. : I'm beginning to wonder if I shouldn't use -stable as a buffer, and : just let the committers deals with things not being up to -current. Or : maybe check to see if the other *BSD's aren't a bit more demanding of : committers. I know that you are frustrated, but I think that's unfair. You'll likely find that the other BSD's are just as bad at times as we get around here. At least that's my firsthand experience with them as a committer. There was a period of about 6 months that every time I went to upgrade the OpenBSD/arc installed on my Deskstation rPC44, someone had broken something and I had to fix it before it would compile. If you aren't a developer or have another compelling reason to track -current, track -stable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200008130714.BAA07153>