|
From: Heiko Z. <he...@zu...> - 2003-03-11 01:16:17
|
manu ESCAR wrote: > Sorry for the lattency but it takes a whole day to compile from scratch ... I know that problem..... > so yesterday, i build a system without problems, grsec and xfs where > disabled, as well as several other packages; this morning, after > updating sources and cvs, i build a new one : make mrpromer then make > menuconfig to enable xfs and finaly make build ... I hope you mean "make mrproper unpack menuconfig" > but when i came back this evening,compilation was stopped with : > ... > patching file drivers/scsi/53c8xx_d.h > patching file drivers/scsi/53c8xx_u.h > patching file drivers/scsi/sim710_d.h > Reversed (or previously applied) patch detected! Assume -R? [n] That really sounds like you didn't do a "make mrproper". > so i opened another shell to see it was grsec patches ! Amazing as the > option was disabled for a while in my selection! So i edit .config file > to see that there is no ligne with CONFIG_GRSECURITY=n !!! It's important that there is no CONFIG_GRSECURITY=y . I checked the script again, I can't find any problems. Do you know if CONFIG_XFS and CONFIG_GRSECURITY were set to "y" ? > Maybe it's part of the pb ? pb ? > Hope it's not an error from me in the build process ... the only thing i > add was the hostap driver which build in 292, too late to impact build > at that time. Check out what "grep GRSECURITY *" show in the build/scripts directory. Mine is like that: $ grep GRSECURITY * grsecurity: if [ "$CONFIG_GRSECURITY" = "y" ] ; then grsecurity: if [ "$CONFIG_GRSECURITY" = "y" ] ; then grsecurity: [ "$CONFIG_XFS" = "y" ] || menu_add "Security" bool "GRSecurity Patch (enhances system security and will break XFS) CONFIG_GRSECURITY xfsprogs: [ "$CONFIG_GRSECURITY" = "y" ] || menu_add "Filesystem" bool "XFS Support" CONFIG_XFS > I posted a question concerning dir /usr/include/linux which i could not > find : it seems to "appear" in his directory after make unpack or > build, i don't know as make build automaticaly unpack sources if they're > not. > I'm a little bit disturbedabout that as your documentation talks about > renaming it to linux2 in chapter 1.2, at the begining of the process and > the directory is created at a latter time (chapter 2 i guess); it is > quite amazing for a newbie like me as you seems to give the whole > process to build in a chronological order ; by the way, why rename it to > linux2 ? I'm very curious :-) A symlink to $DL_DIR/build/tmp/linux-2.4.20/include/linux is created in /usr/include during the early build process. That's our way to ensure the usage of the correct include files for the current Kernel. > Thanks for your help and great job! sure > > ps. i hope after build was successful i can contribute to your efforts > with my work to integrate hostap driver for wireless; i 'm building last > cvs which gives really interesting new features. last question, it seams > a good idea not to modify sources from original tarballs,and to override > things to be changed with options in the make commands, but i was forced > to comment out 3 lines in the main Makefile (of the hostap tree) to > prevent depmod -a to execute at install time : is it against your > philosophy to do that or is it alright? (it's certainly more difficult > to maintain as versions grows) Should i make patch files ? should i ask > developpers of the hostap driver to modify their Makefile so i can > disable it when doing make install ? Always try to avoid modifying tarballs, use patches. If it is really necessary, then we include modified tarballs, but only when we really have to do it. This makes later software updates much easier. About the depmod stuff, you can use it when it doesn't run into an error, which should not happen that late in the build stage (I mean after 159linux). We don't use the generated data and create our own when the system boots up. > Ok, i stop my newbies questions ;-) It's about time. ;-) -- Regards Heiko We are Penguin, resistance is futile! http://www.devil-linux.org |