Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <hz...@pr...> - 2003-03-07 14:08:48
|
On 03/07/2003 08:15:39 AM Manu ESCAR wrote: >Hi all, > >i'm trying to compile DL from the cvs 0.6b1 v 1.286 2003/03/03 15:21:0= 8 >for the first time without any changes ... > >i first make menuconfig and select nearly every options and then ma= ke >build; >the first pb i get was compiler claims for gtk libs or somethink like >that , to configure makefile for wvstreams ! >i guessed it was for wvdial and deselect it in menuconfig then another= >build > >... and then make stop with : make: *** [build] Error 1 > >it seams it was just after grsec patches, for xfs; it's strange as i >didn't selected grsec in my config:-( > >anyway, i tryed another make build to see where it stopped and guet th= is >after many hits on the return key ! You can stop trying. GRSec and XFS don't like eachother, but the grsec maintainer has released a xfs-compatible patch which I have to add to D= L. It seems that there's a bug with the grsec build script, I'll take a lo= ok at it today/tomorrow and post here when it's fix. For now you could just give it a try without XFS, then it should work. Don't select "wvdial" and "passwdgen", those 2 fail under the new build= system, too. (They're not compatible with glibc 2.3.x/gcc 3.2.x) Regards Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-03-12 14:11:49
|
On 03/12/2003 12:27:12 AM Heiko Zuerker wrote: >Heiko Zuerker wrote: >> Manu ESCAR wrote: >>>>> so i opened another shell to see it was grsec patches ! Amazing a= s >>>>> 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=3Dn !!! >>>> >>>> It's important that there is no CONFIG_GRSECURITY=3Dy . >>>> I checked the script again, I can't find any problems. >>>> Do you know if CONFIG_XFS and CONFIG_GRSECURITY were set to "y" ? >>> >>> CONFIG_XFS=3Dy and nothing about CONFIG_GRSECURITY, not even >>> CONFIG_GRSECURITY=3Dn >> >> Strange, I'll start a compile with xfs and no grsec > >Ok the first compile with xfs and no grsec failed. >I updated xfs and the tools for it and started a recompile. >6 1/2 hours left until I have to get up, so time to go in direction be= d. It failed again. The problem is not grsec, it's the xfs patch which fails to apply. So just unselect xfs and your compile should work. XFS is anyway not supported at the moment, because it doesn't work well= with grsec. When somebody want's to fix the problem now, I'm more then happy to thr= ow it into CVS. cya Heiko = |
|
From: Emmanuel E. <ee...@fr...> - 2003-03-12 16:05:53
|
Heiko Zuerker a écrit: >On 03/12/2003 12:27:12 AM Heiko Zuerker wrote: > > >>Heiko Zuerker wrote: >> >> >>>Manu ESCAR wrote: >>> >>> >>>>>>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" ? >>>>> >>>>> >>>>CONFIG_XFS=y and nothing about CONFIG_GRSECURITY, not even >>>>CONFIG_GRSECURITY=n >>>> >>>> >>>Strange, I'll start a compile with xfs and no grsec >>> >>> >>Ok the first compile with xfs and no grsec failed. >>I updated xfs and the tools for it and started a recompile. >>6 1/2 hours left until I have to get up, so time to go in direction bed. >> >> > >It failed again. >The problem is not grsec, it's the xfs patch which fails to apply. >So just unselect xfs and your compile should work. > >XFS is anyway not supported at the moment, because it doesn't work well >with grsec. >When somebody want's to fix the problem now, I'm more then happy to throw >it into CVS. > >cya > Heiko > Thank you, i ,was going mad some more ;-) > > > > >------------------------------------------------------- >This SF.net email is sponsored by:Crypto Challenge is now open! >Get cracking and register here for some mind boggling fun and >the chance of winning an Apple iPod: >http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en >_______________________________________________ >Devil-linux-develop mailing list >Dev...@li... >https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > > |
|
From: Heiko Z. <he...@zu...> - 2003-03-09 17:25:34
|
On Fri, 7 Mar 2003 09:08:37 -0500 "Heiko Zuerker" <hz...@pr...> wrote: > On 03/07/2003 08:15:39 AM Manu ESCAR wrote: > >Hi all, > > > >i'm trying to compile DL from the cvs 0.6b1 v 1.286 2003/03/03 > >15:21:08 for the first time without any changes ... > > > >i first make menuconfig and select nearly every options and then > >make build; > >the first pb i get was compiler claims for gtk libs or somethink like > >that , to configure makefile for wvstreams ! > >i guessed it was for wvdial and deselect it in menuconfig then > >another build > > > >... and then make stop with : make: *** [build] Error 1 > > > >it seams it was just after grsec patches, for xfs; it's strange as i > >didn't selected grsec in my config:-( > > > >anyway, i tryed another make build to see where it stopped and guet > >this after many hits on the return key ! > > You can stop trying. GRSec and XFS don't like eachother, but the grsec > maintainer has released a xfs-compatible patch which I have to add to > DL. It seems that there's a bug with the grsec build script, I'll take > a look at it today/tomorrow and post here when it's fix. I didn't find a bug within the build system, the only problem was that you could select grsec when xfs is enabled, that is corrected now. When you (de-)select i.e. grsec between compiles, you have to do a "make mrproper" to clean out the patched kernel. Heiko |
|
From: manu E. <ee...@ma...> - 2003-03-10 20:37:48
|
Heiko Zuerker a =E9crit: >On Fri, 7 Mar 2003 09:08:37 -0500 >"Heiko Zuerker" <hz...@pr...> wrote: > > =20 > >>On 03/07/2003 08:15:39 AM Manu ESCAR wrote: >> =20 >> >>>Hi all, >>> >>>i'm trying to compile DL from the cvs 0.6b1 v 1.286 2003/03/03 >>>15:21:08 for the first time without any changes ... >>> >>>i first make menuconfig and select nearly every options and then >>>make build; >>>the first pb i get was compiler claims for gtk libs or somethink like >>>that , to configure makefile for wvstreams ! >>>i guessed it was for wvdial and deselect it in menuconfig then >>>another build >>> >>>... and then make stop with : make: *** [build] Error 1 >>> >>>it seams it was just after grsec patches, for xfs; it's strange as i >>>didn't selected grsec in my config:-( >>> >>>anyway, i tryed another make build to see where it stopped and guet >>>this after many hits on the return key ! >>> =20 >>> >>You can stop trying. GRSec and XFS don't like eachother, but the grsec >>maintainer has released a xfs-compatible patch which I have to add to >>DL. It seems that there's a bug with the grsec build script, I'll take >>a look at it today/tomorrow and post here when it's fix. >> =20 >> > >I didn't find a bug within the build system, the only problem was that y= ou could select grsec when xfs is enabled, that is corrected now. > >When you (de-)select i.e. grsec between compiles, you have to do a "make= mrproper" to clean out the patched kernel. > =20 > Sorry for the lattency but it takes a whole day to compile from scratch .= .. so yesterday, i build a system without problems, grsec and xfs where=20 disabled, as well as several other packages; this morning, after=20 updating sources and cvs, i build a new one : make mrpromer then make=20 menuconfig to enable xfs and finaly make build ... 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] so i opened another shell to see it was grsec patches ! Amazing as the=20 option was disabled for a while in my selection! So i edit .config file=20 to see that there is no ligne with CONFIG_GRSECURITY=3Dn !!! Maybe it's part of the pb ? Hope it's not an error from me in the build process ... the only thing i=20 add was the hostap driver which build in 292, too late to impact build=20 at that time. I posted a question concerning dir /usr/include/linux which i could not=20 find : it seems to "appear" in his directory after make unpack or=20 build, i don't know as make build automaticaly unpack sources if they're=20 not. I'm a little bit disturbedabout that as your documentation talks about=20 renaming it to linux2 in chapter 1.2, at the begining of the process and=20 the directory is created at a latter time (chapter 2 i guess); it is=20 quite amazing for a newbie like me as you seems to give the whole=20 process to build in a chronological order ; by the way, why rename it to=20 linux2 ? I'm very curious :-) Thanks for your help and great job! ps. i hope after build was successful i can contribute to your efforts=20 with my work to integrate hostap driver for wireless; i 'm building last=20 cvs which gives really interesting new features. last question, it seams=20 a good idea not to modify sources from original tarballs,and to override=20 things to be changed with options in the make commands, but i was forced=20 to comment out 3 lines in the main Makefile (of the hostap tree) to=20 prevent depmod -a to execute at install time : is it against your=20 philosophy to do that or is it alright? (it's certainly more difficult=20 to maintain as versions grows) Should i make patch files ? should i ask=20 developpers of the hostap driver to modify their Makefile so i can=20 disable it when doing make install ? Ok, i stop my newbies questions ;-) Best Regards MaNS >Heiko > > >------------------------------------------------------- >This SF.net email is sponsored by: Etnus, makers of TotalView, The debug= ger=20 >for complex code. Debugging C/C++ programs can leave you feeling lost an= d=20 >disoriented. TotalView can help you find your way. Available on major UN= IX=20 >and Linux platforms. Try it free. www.etnus.com >_______________________________________________ >Devil-linux-develop mailing list >Dev...@li... >https://lists.sourceforge.net/lists/listinfo/devil-linux-develop > > > =20 > |
|
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 |
|
From: Manu E. <ee...@fr...> - 2003-03-11 15:56:07
|
Heiko Zuerker a écrit: > 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". No, i didn't make unpack before menuconfig ! that's why it worked for my second compilation as sources where in tmp dir ! > > >> 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" ? CONFIG_XFS=y and nothing about CONFIG_GRSECURITY, not even CONFIG_GRSECURITY=n > >> Maybe it's part of the pb ? > > > pb ? my compile problem ;-) > > >> 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. > It was !!! > > 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. so why renaming it to linux2 ? and when in the build process ? > > >> 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. Thanks a lot, my only purpous is to make good clean job others can use and integrate in this wonderful distro! > >> Ok, i stop my newbies questions ;-) > > > It's about time. ;-) > |
|
From: Heiko Z. <he...@zu...> - 2003-03-12 00:45:30
|
Manu ESCAR wrote: > No, i didn't make unpack before menuconfig ! that's why it worked for my > second compilation as sources where in tmp dir ! A "mrproper" is necessary to ensure a clean build environment. The next step would be a "really-really-clean" which means deleting everything and unpacking the lfssystem. This is the way I use before I release any new version. >>> 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" ? > > > CONFIG_XFS=y and nothing about CONFIG_GRSECURITY, not even > CONFIG_GRSECURITY=n Strange, I'll start a compile with xfs and no grsec >> 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. > > > so why renaming it to linux2 ? and when in the build process ? The documentation says nothing about linux2.... ;-) It's in 001prepare. >> 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. > > > Thanks a lot, my only purpous is to make good clean job others can use > and integrate in this wonderful distro! Sounds good to me. ;-) -- Regards Heiko We are Penguin, resistance is futile! http://www.devil-linux.org |
|
From: Heiko Z. <he...@zu...> - 2003-03-12 05:33:45
|
Heiko Zuerker wrote: > Manu ESCAR wrote: >>>> 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" ? >> >> CONFIG_XFS=y and nothing about CONFIG_GRSECURITY, not even >> CONFIG_GRSECURITY=n > > Strange, I'll start a compile with xfs and no grsec Ok the first compile with xfs and no grsec failed. I updated xfs and the tools for it and started a recompile. 6 1/2 hours left until I have to get up, so time to go in direction bed. -- Regards Heiko We are Penguin, resistance is futile! http://www.devil-linux.org |
