Re: CVS commit: src/sys/net
On Sat, Feb 18, 2012 at 11:47:48PM +, Mindaugas Rasiukevicius wrote: > Module Name: src > Committed By: rmind > Date: Sat Feb 18 23:47:48 UTC 2012 > > Modified Files: > src/sys/net: route.h > > Log Message: > rt_setkey: remove invalid assert, sockaddr_dup() may fail if no memory. What are the ultimate consequences of setting both rt->_rt_key and rt->rt_nodes->rn_key to NULL? :-/ Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
re: CVS commit: src/usr.sbin/crash
On Feb 19, 6:43am, m...@eterna.com.au (matthew green) wrote: -- Subject: re: CVS commit: src/usr.sbin/crash | | > I thought arm works. I am fixing mvme68k now. I am trying to make things | > work without the kludge that is why I left it broken. | | can you please not do this? ie, don't commit broken code and leave | the tree broken for random ports for some time. if you see a break | that isn't trivial to fix, please just revert your change. I have fixed everything already. While I have built all the toolchains and it is easy for me to build one arch at the time I don't have the space to build all. | (i'm not even convinced that making crash/Makefile "clean" is worth | all the code churn involved, espcially with cvs as our back end that | doesn't cope well with moved files.) It is not much churn at all; crash uses a small subset of db_interface.c and it is not worth it ifdef'ing it all over the place and not understanding what gets compiled or not. | it's really annoying when you try to build netbsd and it doesn't | for these sorts of reasons. i've wasted a bunch of hours just in | the last week dealing with failed build points when trying to | binary search a failure point. It was just broken for 2 days, because I could not get build results quicker. christos
re: CVS commit: src/usr.sbin/crash
> I thought arm works. I am fixing mvme68k now. I am trying to make things > work without the kludge that is why I left it broken. can you please not do this? ie, don't commit broken code and leave the tree broken for random ports for some time. if you see a break that isn't trivial to fix, please just revert your change. (i'm not even convinced that making crash/Makefile "clean" is worth all the code churn involved, espcially with cvs as our back end that doesn't cope well with moved files.) it's really annoying when you try to build netbsd and it doesn't for these sorts of reasons. i've wasted a bunch of hours just in the last week dealing with failed build points when trying to binary search a failure point. .mrg.
Re: CVS commit: src/usr.sbin/crash
On Feb 19, 1:18am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/usr.sbin/crash | > I thought arm works. | | Daily build reports many arm ports | (acorn32 cats evbarm hpcarm iyonix netwinder shark zaurus) fail | http://releng.netbsd.org/builds/HEAD/201202171310Z/ | after your commit at 201202162036Z. | | If you commit changes without any tests, make sure to check result | in daily build log. That's too old... christos
Re: CVS commit: src/usr.sbin/crash
In article <120219011842.m0113...@mirage.ceres.dti.ne.jp>, Izumi Tsutsui wrote: >> I thought arm works. > >Daily build reports many arm ports >(acorn32 cats evbarm hpcarm iyonix netwinder shark zaurus) fail >http://releng.netbsd.org/builds/HEAD/201202171310Z/ >after your commit at 201202162036Z. > >If you commit changes without any tests, make sure to check result >in daily build log. Can't be, I built shark. I will take a look. christos
Re: CVS commit: src/usr.sbin/crash
> I thought arm works. Daily build reports many arm ports (acorn32 cats evbarm hpcarm iyonix netwinder shark zaurus) fail http://releng.netbsd.org/builds/HEAD/201202171310Z/ after your commit at 201202162036Z. If you commit changes without any tests, make sure to check result in daily build log. --- Izumi Tsutsui
Re: CVS commit: src/usr.sbin/crash
On Feb 19, 1:08am, tsut...@ceres.dti.ne.jp (Izumi Tsutsui) wrote: -- Subject: Re: CVS commit: src/usr.sbin/crash | > >http://releng.netbsd.org/builds/HEAD/201202171310Z/ | > > | > >What checks did you do before committing your refactoring? | > | > None, this is why I waited after the branch. I am fixing sparc64 now. | | Can you also fix arm and m68k? Or should I put kludge? | On m68k only sun3 (which has different pmap) has db_machdep.c. I thought arm works. I am fixing mvme68k now. I am trying to make things work without the kludge that is why I left it broken. christos
Re: CVS commit: src/usr.sbin/crash
> >http://releng.netbsd.org/builds/HEAD/201202171310Z/ > > > >What checks did you do before committing your refactoring? > > None, this is why I waited after the branch. I am fixing sparc64 now. Can you also fix arm and m68k? Or should I put kludge? On m68k only sun3 (which has different pmap) has db_machdep.c. --- Izumi Tsutsui
Re: CVS commit: src/usr.sbin/crash
In article <120218180432.m0107...@mirage.ceres.dti.ne.jp>, Izumi Tsutsui wrote: >> In article <20120217122414.7254417...@cvs.netbsd.org>, >> Martin Husemann wrote: >> >-=-=-=-=-=- >> > >> >Module Name:src >> >Committed By: martin >> >Date: Fri Feb 17 12:24:14 UTC 2012 >> > >> >Modified Files: >> >src/usr.sbin/crash: Makefile >> > >> >Log Message: >> >Fix build for sparc64 >> >> I'd rather re-organize the contents of the files so that sparc64 is not >> different than everyone else. > >m68k and arm didn't have db_machdep.c in old Makefile and >they are also broken, so sparc64 is not alone ;-p >http://releng.netbsd.org/builds/HEAD/201202171310Z/ > >What checks did you do before committing your refactoring? None, this is why I waited after the branch. I am fixing sparc64 now. christos
Re: CVS commit: src/usr.sbin/crash
> In article <20120217122414.7254417...@cvs.netbsd.org>, > Martin Husemann wrote: > >-=-=-=-=-=- > > > >Module Name: src > >Committed By:martin > >Date:Fri Feb 17 12:24:14 UTC 2012 > > > >Modified Files: > > src/usr.sbin/crash: Makefile > > > >Log Message: > >Fix build for sparc64 > > I'd rather re-organize the contents of the files so that sparc64 is not > different than everyone else. m68k and arm didn't have db_machdep.c in old Makefile and they are also broken, so sparc64 is not alone ;-p http://releng.netbsd.org/builds/HEAD/201202171310Z/ What checks did you do before committing your refactoring? --- Izumi Tsutsui
