Re: Build breakage (was: fail to compile kernel...)
In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED] wrote: Yes, the version I have is out of date. It came from cvsup5.freebsd.org over 24 hours after the commit. Everybody, if you find that a CVSup mirror site is running that far behind, please drop a note to the site's maintainer. All of the maintainers are listed in the Handbook along with the mirror sites. 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-current" in the body of the message
Re: fail to compile kernel...
On Sun, 13 Aug 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Idea Receiver writes: : In message [EMAIL PROTECTED] Idea Receiver writes: : : i have try to upgrade one of my 4.1 release to -current. : : however, when i try to build the kernel, it failed as following : : message. : : Upgrade your sources and try again. : : Warner : : cvsed this morning (8 hrs ago..) : and still doesnt work.. Where did you get your sources? As of 12:00 last night, the sources I grabbed from cvsup8 completed both a make buildworld and make buildkernel in a fresh tree. i got my sources from cvsup5.. i change it to cvsup2 this morning. now everything works fine. thank you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Build breakage (was: fail to compile kernel...)
Warner Losh writes: In message [EMAIL PROTECTED] 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). : 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. 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. 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. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
In message [EMAIL PROTECTED] Mike Meyer writes: : Warner Losh writes: : In message [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
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. 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. What if the machine building snapshots took a note of the time it cvsup'ped. Then if the build succeded, it would append this date to a file. We could then feed this date to our cvsup, to get a version which at least compiled. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
On Sun, Aug 13, 2000 at 01:14:09AM -0600, Warner Losh wrote: : 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. Which is why I keep a virgin src checkout and I CVSup (with "-i") right after large commit and try building the code again in the virgin tree. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fail to compile kernel...
On Sat, 12 Aug 2000, Warner Losh wrote: In message [EMAIL PROTECTED] Idea Receiver writes: : i have try to upgrade one of my 4.1 release to -current. : however, when i try to build the kernel, it failed as following : message. Upgrade your sources and try again. Warner cvsed this morning (8 hrs ago..) and still doesnt work.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
Warner Losh writes: In message [EMAIL PROTECTED] Mike Meyer writes: : Warner Losh writes: : In message [EMAIL PROTECTED] 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. Hmm - you mean 'cvs diff' can't be pointed at sys to get a list of everything you've touched? : : 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. I just now grabbed the latest sources, and got the following: cc -O -pipe -march=pentium -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/oldcard/../../pccard/pccard.c cc -O -pipe -march=pentium -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /usr/src/sys/modules/oldcard/../../pccard/pcic.c /usr/src/sys/modules/oldcard/../../pccard/pcic.c:1020: `card_get_memory_offset_desc' undeclared here (not in a function) /usr/src/sys/modules/oldcard/../../pccard/pcic.c:1020: initializer element is not constant /usr/src/sys/modules/oldcard/../../pccard/pcic.c:1020: (near initialization for `pcic_methods[16].desc') *** Error code 1 Stop in /usr/src/sys/modules/oldcard. *** Error code 1 Stop in /usr/src/sys/modules. *** Error code 1 Stop in /usr/src/sys/compile/EVE. 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. If it usually "just worked", it wouldn't be a problem. I expected to have systems that would at times be a bit delicate for a time, or require old kernels, or the like. What I *didn't* expect was that the usual update procedure would be get new sources, watch the build fail, fix it if possible, or post a note to -current and repeat the process when someone claimed it was fixed. : 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. That may be true - which would mean it wouldn't be any better than FreeBSD has been for the past few months. Or any worse. On the other hand, breaking the build on other projects I've worked on was considered
Re: Build breakage (was: fail to compile kernel...)
In message [EMAIL PROTECTED] "David O'Brien" writes: : On Sun, Aug 13, 2000 at 01:14:09AM -0600, Warner Losh wrote: : : 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. : : Which is why I keep a virgin src checkout and I CVSup (with "-i") right : after large commit and try building the code again in the virgin tree. Makes sense for a large commit. I try to do that after most big commits myself, or when things aren't inside the kernel. In this case, however, it wouldn't have saved much time. I made the commit and went to bed. The buildworld on the clean tree wouldn't have been ready for two hours and I was fast asleep by then. When I woke up, I had messages telling me of my mistake and fixed it then. If I had done a buildworld on a fresh tree, then I'd have done the same thing when I discovered it had failed in the morning... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fail to compile kernel...
In message [EMAIL PROTECTED] Idea Receiver writes: : In message [EMAIL PROTECTED] Idea :Receiver writes: : : i have try to upgrade one of my 4.1 release to -current. : : however, when i try to build the kernel, it failed as following : : message. : : Upgrade your sources and try again. : : Warner : : cvsed this morning (8 hrs ago..) : and still doesnt work.. Where did you get your sources? As of 12:00 last night, the sources I grabbed from cvsup8 completed both a make buildworld and make buildkernel in a fresh tree. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
In message [EMAIL PROTECTED] Mike Meyer writes: : Hmm - you mean 'cvs diff' can't be pointed at sys to get a list of : everything you've touched? No, I mean that I have NEWCARD changes as well, that usually never get touched. And it is sometimes easy to get things confused. : I just now grabbed the latest sources, and got the following: Where did you get them? Before I sent the last mail message out I built the kernel on a fresh tree and kicked off a world build (which finished). : If it usually "just worked", it wouldn't be a problem. I expected to : have systems that would at times be a bit delicate for a time, or : require old kernels, or the like. What I *didn't* expect was that the : usual update procedure would be get new sources, watch the build fail, : fix it if possible, or post a note to -current and repeat the process : when someone claimed it was fixed. So we're down to stale sources at one of the mirrors, I think. My kernel tree here is completely clean and checked out from the my local cvs tree. Where do you get your sources from? What revision of src/sys/dev/pccard/card_if.m do you have? The following changed fixes it: revision 1.7 date: 2000/08/11 15:51:51; author: imp; state: Exp; lines: +8 -1 Define get_memory_offset method Which is Friday Morning MST (the time is GMT). Plenty of time for the mirrors to be updated. : That may be true - which would mean it wouldn't be any better than : FreeBSD has been for the past few months. Or any worse. On the other : hand, breaking the build on other projects I've worked on was : considered a major blunder. That doesn't seem to be the case here. That is the case here. Believe me. But sitting around pointing fingers after the problem has been fixed is usually not done. : If you aren't a developer or have another compelling reason to track : -current, track -stable. : : Well, I was hoping to chase out the last of the bugs in the usb modem : driver, and possibly try and recover some of the functionality lost : when the snd drivers quit working. But the latest version of the : former isn't in the tree yet, and new sound cards are cheaper than the : time to work on the latter (if only the documentation on pcm did and : didn't support were accurate). That was the justification for my : converting to -current in the first place. I figured I'd track : -current to make the lifes of the people actually committing the code : easier, but that seems sort of pointless. That's a compelling reason. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
In message 06e001c004fa$39e94d60$[EMAIL PROTECTED] "Leif Neland" writes: : What if the machine building snapshots took a note of the time it cvsup'ped. : Then if the build succeded, it would append this date to a file. : We could then feed this date to our cvsup, to get a version which at least : compiled. Preliminary inidications are that this is a mirroring problem. If the last date mechanism was independent of the mirroring process, then the problem would still persist because the date given would be after the breakage. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED] wrote: Won't the 'cvs diff' command tell you about such things? No, but "cvs -nq update" will, and it's a lot faster 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-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
On Sun, 13 Aug 2000, John Polstra wrote: In article [EMAIL PROTECTED], Mike Meyer [EMAIL PROTECTED] wrote: Won't the 'cvs diff' command tell you about such things? No, but "cvs -nq update" will, and it's a lot faster too. I normally use that, but "cvs status | grep Status" may be better (faster?). "cvs -nq update" is not as good as it used to be. It now prints noise about merging deltas, so I actually normally use "cvs -nq update | grep -v ^M". Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
Warner Losh writes: So we're down to stale sources at one of the mirrors, I think. My kernel tree here is completely clean and checked out from the my local cvs tree. Where do you get your sources from? What revision of src/sys/dev/pccard/card_if.m do you have? The following changed fixes it: revision 1.7 date: 2000/08/11 15:51:51; author: imp; state: Exp; lines: +8 -1 Define get_memory_offset method Which is Friday Morning MST (the time is GMT). Plenty of time for the mirrors to be updated. Yes, the version I have is out of date. It came from cvsup5.freebsd.org over 24 hours after the commit. : That may be true - which would mean it wouldn't be any better than : FreeBSD has been for the past few months. Or any worse. On the other : hand, breaking the build on other projects I've worked on was : considered a major blunder. That doesn't seem to be the case here. That is the case here. Believe me. But sitting around pointing fingers after the problem has been fixed is usually not done. Again, I didn't mean to point fingers or complain about any specific person. I've been sitting on this for most of the last week; your change just happened to be the one that caused the problem this time. Pointing fingers isn't the difference I was talking about. It's more in the attitude after the fact. On FreeBSD, it's "Ok, I fixed it." Elsewhere, people apologize for breaking the bulid. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Build breakage (was: fail to compile kernel...)
In message [EMAIL PROTECTED] Mike Meyer writes: : Pointing fingers isn't the difference I was talking about. It's more : in the attitude after the fact. On FreeBSD, it's "Ok, I fixed : it." Elsewhere, people apologize for breaking the bulid. I sent out a message at the time saying I'm sorry for the breakage and I've fixed it. when it came up again, I just said that I;d fixed it. You're right. I shouldn't have sounded so... so... blasse about it. Warner "pass the connical hat" Losh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fail to compile kernel...
i have try to upgrade one of my 4.1 release to -current. however, when i try to build the kernel, it failed as following message. please help! thanks in advance === oldcard cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pccard.c cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c:1020: `card_get_memory_offset_desc' undeclared here (not in a function) /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c:1020: initializer element is not constant /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c:1020: (near initialization for `pcic_methods[16].desc') *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard. *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules. *** Error code 1 Stop in /usr/obj/mnt/ad4s1e/FreeBSD-CURRENT/src/sys/WHITESUN-LWY-00. *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src. *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fail to compile kernel...
In message [EMAIL PROTECTED] Idea Receiver writes: : i have try to upgrade one of my 4.1 release to -current. : however, when i try to build the kernel, it failed as following : message. Upgrade your sources and try again. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fail to compile kernel...
Idea Receiver writes: i have try to upgrade one of my 4.1 release to -current. however, when i try to build the kernel, it failed as following message. 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. 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. mike === oldcard cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pccard.c cc -O -pipe -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/../include -mpreferred-stack-boundary=2 -c /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c:1020: `card_get_memory_offset_desc' undeclared here (not in a function) /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c:1020: initializer element is not constant /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard/../../pccard/pcic.c:1020: (near initialization for `pcic_methods[16].desc') *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules/oldcard. *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src/sys/modules. *** Error code 1 Stop in /usr/obj/mnt/ad4s1e/FreeBSD-CURRENT/src/sys/WHITESUN-LWY-00. *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src. *** Error code 1 Stop in /mnt/ad4s1e/FreeBSD-CURRENT/src. 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: fail to compile kernel...
In message [EMAIL PROTECTED] 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... : 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... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
