Menu
▾
▴
devil-linux-develop
|
From: Heiko Z. <hz...@pr...> - 2003-10-13 17:54:58
|
On 10/12/2003 08:03:29 PM Heiko Zuerker wrote: >Heiko Zuerker wrote: > >> Bruce Smith wrote: >> >>>> The major change is that you can define dependencies (i.e. which >>>> libs are required for this package). It uses the insserv utility a= nd >>>> will be the same as our init system. >>>> >>> >>> >>> Sounds scary. Give me a little notice before you check it in? >>> (so I can run one last good compile, just in case ... ;-) >>> >>> >> The new build system seems to work. I have to do a few more compiles= >> to make sure, but it looks like I can check it in later tonight. >> So do you "cvs update -d -P" before I check my stuff in. ;-) > >Looks like our build system is a little bit too much for insserv. ;-) >That means there will be some delays.... I found the problem, it was a small bug in insserv. All the changes are checked in! You need to do a "make mrproper unpack" first, since the new build syst= em will not recognize the old flags. There's a new make command: "make prepare" This will order the build scripts according to the specified dependenc= ies and creates all the symlinks. You need to do a "make prepare" when you added new scripts. Prepare will also be automatically invoked after a mrproper. The faciliities are specified in the file build/scripts/buildorder.conf= . cya Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-10-13 19:01:59
|
On 10/13/2003 02:33:32 PM Friedrich Lobenstock wrote: >Heiko Zuerker wrote: >> There's a new make command: "make prepare" >> This will order the build scripts according to the specified >dependencies >> and creates all the symlinks. >> You need to do a "make prepare" when you added new scripts. >> Prepare will also be automatically invoked after a mrproper. >> >> The faciliities are specified in the file >build/scripts/buildorder.conf . > >If insserv reordered the scripts then all .done files will become >invalid because they have the number in them. Did you remove that >part? I re-worked this part, but the old .done files won't be recognized, but= the principle is the same. I also removed the number from the .done files, since the number can be= different. cya Heiko = |
|
From: Friedrich L. <fl...@fl...> - 2003-10-13 19:12:19
|
Heiko Zuerker wrote: > I also removed the number from the .done files, since the number can be > different. That's what I meant. -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <hz...@pr...> - 2003-10-13 19:29:19
|
On 10/13/2003 03:09:10 PM Friedrich Lobenstock wrote: >Heiko Zuerker wrote: >> I also removed the number from the .done files, since the number can= >be >> different. > >That's what I meant. Oh..... ;-) = |
|
From: Heiko Z. <hz...@pr...> - 2003-10-15 20:14:05
|
Hey, the new build system seems to work now. I just finished a full compile including new lfssystem without any problems. Please start testing. cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 13:06:21
|
> the new build system seems to work now. > I just finished a full compile including new lfssystem without any > problems. > > Please start testing. LATE last night (near the end of the Cubs game): I updated from CVS and updated source (after fixing ftp permissions :) installed a new lfssystem and started a compile. I'm still up to date as of this morning (no new updates since then). /etc/apache2/build/libtool --mode=install cp libphp4.la /data/build/tmp/tmp/usr/lib/apache2/modules/ cp .libs/libphp4.so /data/build/tmp/tmp/usr/lib/apache2/modules/libphp4.so cp .libs/libphp4.lai /data/build/tmp/tmp/usr/lib/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /data/build/tmp/php-4.3.4RC1/libs' chmod 755 /data/build/tmp/tmp/usr/lib/apache2/modules/libphp4.so [activating module `php4' in /data/build/tmp/tmp/etc/apache2/httpd.conf] Installing shared extensions: /data/build/tmp/tmp/usr/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /data/build/tmp/tmp/usr/lib/php/ make[2]: Entering directory `/data/build/tmp/php-4.3.4RC1' [PEAR] Archive_Tar - installed: 1.1 [PEAR] Console_Getopt - installed: 1.0 [PEAR] PEAR - installed: 1.3b1 Wrote PEAR system config file at: /data/build/tmp/tmp//etc/pear.conf You may want to add: /usr/lib/php to your php.ini include_path [PEAR] DB - installed: 1.5.0RC2 [PEAR] HTTP - installed: 1.2.1 [PEAR] Mail - installed: 1.1.1 [PEAR] Net_SMTP - installed: 1.2.3 [PEAR] Net_Socket - installed: 1.0.1 [PEAR] XML_Parser - installed: 1.0.1 [PEAR] XML_RPC - installed: 1.0.4 make[2]: Leaving directory `/data/build/tmp/php-4.3.4RC1' Installing build environment: /data/build/tmp/tmp/usr/lib/php/build/ Installing header files: /data/build/tmp/tmp/usr/include/php/ Installing helper programs: /data/build/tmp/tmp/usr/bin/ program: phpize program: php-config program: phpextdist make[1]: Leaving directory `/data/build/tmp/php-4.3.4RC1' ERROR /data/build/scripts/php install failed make: *** [install] Error 1 |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 17:20:22
|
On 10/16/2003 09:02:47 AM Bruce Smith wrote: >> the new build system seems to work now. >> I just finished a full compile including new lfssystem without any >> problems. >> >> Please start testing. > >LATE last night (near the end of the Cubs game): >I updated from CVS and updated source (after fixing ftp permissions :)= >installed a new lfssystem and started a compile. I'm still up to date= >as of this morning (no new updates since then). Yesterday NOT SO LATE (far away from the end of the Cubs game (I think)= ) I wrote an Email to the Mailinglist that you should not select PHP, bec= ause it's not finished yet. But it seems like it never left my mail server. :-(( But it's good that you got that far, that means (almost) everything wor= ks ! You got 2 options: 1) de-select PHP 2) fix the PHP install script ( I prefer this one ! ) cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 17:43:39
|
> >LATE last night (near the end of the Cubs game): > >I updated from CVS and updated source (after fixing ftp permissions :) > >installed a new lfssystem and started a compile. I'm still up to date > >as of this morning (no new updates since then). > > Yesterday NOT SO LATE (far away from the end of the Cubs game (I think)) I > wrote an Email to the Mailinglist that you should not select PHP, because > it's not finished yet. > But it seems like it never left my mail server. :-(( No wonder I didn't see it! :-) > But it's good that you got that far, that means (almost) everything works ! > > You got 2 options: > 1) de-select PHP > 2) fix the PHP install script ( I prefer this one ! ) Don't hold your breath on #2, I've got a lot of other stuff to do first. I'm currently replacing some Redhat Linux servers at work with DL. I figured I'd start out with the easy ones, so I installed two DL BIND servers to replace my employer's RH BIND servers. The master named server worked fine. The slave server wouldn't transfer the zones - permission denied. OK, the master isn't giving the slave permission - WRONG! It turns out the /etc/named directory in the _jail_ is only writable by root and the named process is running as user "named". (even though I ran "chown named /etc/named" on the _real_ directory) It's amazing how much easier it is to find bugs in software when you actually USE it! :-) Fixes will be committed soon, for 1.1 & 1.0. - BS |
|
From: Diego T. <dt...@co...> - 2003-10-20 01:09:27
|
On Thu, Oct 16, 2003 at 01:43:37PM -0400, Bruce Smith wrote: > writable by root and the named process is running as user "named". > (even though I ran "chown named /etc/named" on the _real_ directory) > > It's amazing how much easier it is to find bugs in software when you > actually USE it! :-) Fixes will be committed soon, for 1.1 & 1.0. btw: it should be easier for you to use djbdns :) -- -- gnupg keyfingerprint -- 48AF 5BF9 8F54 2966 64CC 2327 7CD0 DD91 B09D 5799 -- Use of a keyboard or mouse may be linked to serious injuries or disorders. Diego Torres - dt...@co... - Madrid / España |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 22:10:21
|
On 10/16/2003 01:43:37 PM Bruce Smith wrote: >> But it's good that you got that far, that means (almost) everything >works ! >> >> You got 2 options: >> 1) de-select PHP >> 2) fix the PHP install script ( I prefer this one ! ) > >Don't hold your breath on #2, I've got a lot of other stuff to do firs= t. Crap! >I'm currently replacing some Redhat Linux servers at work with DL. >I figured I'd start out with the easy ones, so I installed two DL BIND= >servers to replace my employer's RH BIND servers. The master named >server worked fine. The slave server wouldn't transfer the zones - >permission denied. OK, the master isn't giving the slave permission -= >WRONG! It turns out the /etc/named directory in the _jail_ is only >writable by root and the named process is running as user "named". >(even though I ran "chown named /etc/named" on the _real_ directory) > >It's amazing how much easier it is to find bugs in software when you >actually USE it! :-) Fixes will be committed soon, for 1.1 & 1.0. Yeah that is true. Unfortunately when we set up the DNS Servers in my company with DL, the= guys insisted on *not* using the chroot. I never understood why.... cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-17 02:17:16
|
> Unfortunately when we set up the DNS Servers in my company with DL, the > guys insisted on *not* using the chroot. > I never understood why.... The only advantage I could see would be for a HUGE number of hosts. With chroot the slaves have to do full zone transfers every time they are rebooted, and all the servers would use twice the memory to hold the domain files (/etc/named & a copy in the jail). I don't have to worry about that for quite awhile. :-) - BS |
|
From: Friedrich L. <fl...@fl...> - 2003-10-13 18:33:49
|
Heiko Zuerker wrote: > There's a new make command: "make prepare" > This will order the build scripts according to the specified dependencies > and creates all the symlinks. > You need to do a "make prepare" when you added new scripts. > Prepare will also be automatically invoked after a mrproper. > > The faciliities are specified in the file build/scripts/buildorder.conf . If insserv reordered the scripts then all .done files will become invalid because they have the number in them. Did you remove that part? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <he...@zu...> - 2003-10-13 22:26:17
|
Heiko Zuerker wrote: >On 10/12/2003 08:03:29 PM Heiko Zuerker wrote: > > >>Heiko Zuerker wrote: >> >> >> >>>Bruce Smith wrote: >>> >>> >>> >>>>>The major change is that you can define dependencies (i.e. which >>>>>libs are required for this package). It uses the insserv utility and >>>>>will be the same as our init system. >>>>> >>>>> >>>>> >>>>Sounds scary. Give me a little notice before you check it in? >>>>(so I can run one last good compile, just in case ... ;-) >>>> >>>> >>>> >>>> >>>The new build system seems to work. I have to do a few more compiles >>>to make sure, but it looks like I can check it in later tonight. >>>So do you "cvs update -d -P" before I check my stuff in. ;-) >>> >>> >>Looks like our build system is a little bit too much for insserv. ;-) >>That means there will be some delays.... >> >> > >I found the problem, it was a small bug in insserv. > >All the changes are checked in! >You need to do a "make mrproper unpack" first, since the new build system >will not recognize the old flags. > >There's a new make command: "make prepare" >This will order the build scripts according to the specified dependencies >and creates all the symlinks. >You need to do a "make prepare" when you added new scripts. >Prepare will also be automatically invoked after a mrproper. > >The faciliities are specified in the file build/scripts/buildorder.conf . > > If you don't start with a fresh LFS system, then it is absolutely important that you delete /sbin/insserv inside the LFS system. cya Heiko |
