Menu
▾
▴
linuxcoe-devel — LinuxCOE development discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
|
Jun
(14) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(47) |
Nov
(29) |
Dec
(1) |
| 2008 |
Jan
(9) |
Feb
(10) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(4) |
Aug
(1) |
Sep
(10) |
Oct
(7) |
Nov
(23) |
Dec
(37) |
| 2009 |
Jan
(9) |
Feb
(22) |
Mar
(18) |
Apr
(31) |
May
(37) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bryan G. <Bry...@HP...> - 2007-11-21 14:53:19
|
Bruno,
On Wed, Nov 21, 2007 at 02:38:26PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bryan Gartner said on Wed, Nov 21, 2007 at 07:18:33AM -0700:
>
> > > > # from previous configure run
> > > > export prefix=/var/www/linuxcoe-sd
> > > > export exec_prefix=${prefix}
> > > > export bindir=${exec_prefix}/bin
> > > > export sbindir=${exec_prefix}/sbin
> > > > export libexecdir=${exec_prefix}/libexec
> > > > export datadir=${datarootdir}
> > > > export datarootdir=${prefix}/share
> > >
> > > Isn't the order here reversed ?
> >
> > These look ok-ish to me (assuming they match what you specified for
> > configure). Not sure what you mean about "order"?
>
> I meant datadir use the content of datarootdir which is declared just
> after. Looks it could create a problem no ?
Ah, good eye. I have made swapped the order. But FYI, neither are really
used by anything I do (in fact datarootdir was only recently added
as an auto* requirement).
bryang
|
|
From: Bryan G. <Bry...@HP...> - 2007-11-21 14:47:05
|
Bruno,
On Wed, Nov 21, 2007 at 10:38:09AM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bruno Cornec said on Wed, Nov 21, 2007 at 10:38:38AM +0100:
> my /etc/linuxcoe-sd/includes/config.state is probably wrong:
> #! /bin/sh
>
> # from previous configure run
> export prefix=/var/www/linuxcoe-sd
> export exec_prefix=${prefix}
> export bindir=${exec_prefix}/bin
> export sbindir=${exec_prefix}/sbin
> export libexecdir=${exec_prefix}/libexec
> export datadir=${datarootdir}
> export datarootdir=${prefix}/share
> export sysconfdir=/etc/linuxcoe-sd
> export sharedstatedir=${prefix}/com
> export localstatedir=/var
> export libdir=${exec_prefix}/lib
> export includedir=${prefix}/include
> export oldincludedir=/usr/include
> export infodir=${datarootdir}/info
> export mandir=/usr/share/man
> export PACKAGE_NAME=linuxcoe-sd
> export PACKAGE_VERSION=4.1
> export webalias=SystemDesigner
> export httpdcfgdir=/etc/httpd/conf.d
> export docrootdir=/var/www/html
> export httpd_user=apache
> export httpd_group=apache
> export sudoers_cfg=/etc/sudoers
> export TAR=/bin/tar
> export CPIO=/bin/cpio
> export GZIP=/bin/gzip
> export GUNZIP=/bin/gunzip
> export DIFF=/usr/bin/diff
> export FIND=/usr/bin/find
> export MKISOFS=SKIP
> export PERL=/usr/bin/perl
> export PERLMOD=@PERLMOD@
I have fixed this (basically forgot to have configure publish this
value).
> export PALO=NONE
> export SENDMAIL=SKIP
> export APACHE=SKIP
> export APACHECTL=SKIP,
I have fixed the errant comma.
> export APACHE2CTL=SKIP
> export SUDOERS=DOIT
> export SUDO=SKIP
>
> Shouldn't those SKIP be replaced by what is also in binaries.pm ?
As in previous message, nope (it's meant to capture what we were
told to do).
> The diff with the working machine gives (< works, > doesn't)
>
> 13c13
> < export localstatedir=/var/lib
> ---
> > export localstatedir=/var
Since you use:
--localstatedir=%{_localstatedir}
is it possible that the differing build platform's rpm is doing
this to you?
> 32,33c32,35
> < export FIND=/bin/find
> < export MKISOFS=/usr/bin/mkisofs
> ---
> > export FIND=/usr/bin/find
> > export MKISOFS=SKIP
> > export PERL=/usr/bin/perl
> > export PERLMOD=@PERLMOD@
> 35,38c37,42
> < export SENDMAIL=/usr/sbin/sendmail
> < export APACHECTL=/usr/sbin/apachectl
> < export APACHE2CTL=NONE
> < export SUDO=/usr/bin/sudo
> ---
> > export SENDMAIL=SKIP
> > export APACHE=SKIP
> > export APACHECTL=SKIP,
> > export APACHE2CTL=SKIP
> > export SUDOERS=DOIT
> > export SUDO=SKIP
> 74c74
>
> Maybe the PERLMOD,localstatedir,MKISOFS,SENDMAIL,APACHE,APACHECTL,
> APACHE2CTL,SUDO lines are wrong too ?
> It seems that that script is called by post-actions:
> /var/www/linuxcoe-sd/bin/post-actions: test -f "/etc/linuxcoe-sd/includes/config.state" && . /etc/linuxcoe-sd/includes/config.state
Yes, this is the way I pass choices from build time to install time
(since can be on totally different systems).
> I'm also skeptic by that one:
> diff /var/www/linuxcoe-sd/includes/sysdes_paths.pm /mnt//var/www/linuxcoe-sd/includes/sysdes_paths.pm
> 14c14
> < $VAR="/var/lib";
> ---
> > $VAR="/var";
So that is consistent with the above differences, and matches my
expectations since:
$VAR="@localstatedir@";
is what I do.
> (which corresponds to the difference mentioned above in localstatedir)
>
> I also found another issue:
> # ls -al /var/lib/linuxcoe-sd/profiles/
> total 20
> drwxrwsr-x 2 apache apache 4096 Aug 30 02:09 .
> drwxrwsr-x 3 apache apache 4096 Aug 30 02:09 ..
> lrwxrwxrwx 1 root apache 29 Aug 30 02:09 profiles -> /var/lib/linuxcoe-sd/profiles
>
> So I created the following:
> # ln -s /var/log/linuxcoe-sd /var/lib/logs
>
> But still no log file :-(
> [root@localhost images]# find / -name sysdes.log
Hmm.
> [root@localhost images]#
>
> Still searching ;-)
In a default install (letting localstatedir remain as ${prefix}/var),
/usr/local/linuxcoe-sd/var/logs -> /var/log/linuxcoe-sd
and sysdes.log logfile would be in that directory
/usr/local/linuxcoe-sd/var/profiles -> /var/lib/linuxcoe-sd/profiles
and the actual profiles would be in that directory
but with your config above (my guesses would be):
/var/logs -> /var/log/linuxcoe-sd
/var/profiles -> /var/lib/linuxcoe-sd/profiles
bryang
|
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 14:38:41
|
Bryan Gartner said on Wed, Nov 21, 2007 at 07:18:33AM -0700:
> > > # from previous configure run
> > > export prefix=/var/www/linuxcoe-sd
> > > export exec_prefix=${prefix}
> > > export bindir=${exec_prefix}/bin
> > > export sbindir=${exec_prefix}/sbin
> > > export libexecdir=${exec_prefix}/libexec
> > > export datadir=${datarootdir}
> > > export datarootdir=${prefix}/share
> >
> > Isn't the order here reversed ?
>
> These look ok-ish to me (assuming they match what you specified for
> configure). Not sure what you mean about "order"?
I meant datadir use the content of datarootdir which is declared just
after. Looks it could create a problem no ?
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
|
|
From: Bryan G. <Bry...@HP...> - 2007-11-21 14:19:55
|
Bruno,
I am a little short on context for some of the following, but will
still make educated guesses.
> > # from previous configure run
> > export prefix=/var/www/linuxcoe-sd
> > export exec_prefix=${prefix}
> > export bindir=${exec_prefix}/bin
> > export sbindir=${exec_prefix}/sbin
> > export libexecdir=${exec_prefix}/libexec
> > export datadir=${datarootdir}
> > export datarootdir=${prefix}/share
>
> Isn't the order here reversed ?
These look ok-ish to me (assuming they match what you specified for
configure). Not sure what you mean about "order"?
> > export MKISOFS=SKIP
> > export SENDMAIL=SKIP
> > export APACHE=SKIP
> > export APACHECTL=SKIP,
> > export APACHE2CTL=SKIP
> >
> > Shouldn't those SKIP be replaced by what is also in binaries.pm ?
If all of the above is in config.state, these look ok, as they were
meant to capture what you "configured" for later reference. And you
are, in fact, correct, that the post-install will only modify the
binaries.pm file to migrate SKIP -> paths to binaries (at least those
it can now find on the target install system).
> Still answering myself. Probably not. Because that script is especially
> used to create the correct binaries.pm, so point is void.
>
> > The diff with the working machine gives (< works, > doesn't)
> >
> > 13c13
> > < export localstatedir=/var/lib
> > ---
> > > export localstatedir=/var
>
> That still look strange to me.
Hmm, don't you specify the --localstatedir=<SomeDir> in your package
builds ? FWIW, I typically don't for either CVS/tar installs or debian
package builds (as the default actions do the "right" thing for me).
bryang
|
|
From: Bryan G. <Bry...@HP...> - 2007-11-21 14:06:10
|
Bruno, On Wed, Nov 21, 2007 at 09:38:38AM +0000, Cornec, Bruno (Linux Consultant) wrote: > Bruno Cornec said on Wed, Nov 21, 2007 at 10:14:25AM +0100: > > > Still scratching my head to understand why all that. Will look at it on > > my side, but obviously will welcome again your help Bryan. > > Humm I found one strange think from my point of view: > > In /etc/linuxcoe-sd/linuxcoe.rc I have: > # FTP_PATH - where the bootable images are made available for download > FTP_PATH @ftppubdir@/LinuxCOE/images > > Is that normal ? Well, "normal" = yes. It is an artifact from when we offered FTP as the download mechanism (on the very last pages of bootimage/retrofit). At this point, it is really just an orphaned "feature". I just removed it from linuxcoe.rc (but it did no harm). > Then looking for the '@' in linuxcoe installed files, I found some other > unexpanded macros: I am a bit surprised by this one, as it used to work and will try to fix this. > /var/www/linuxcoe-sd/html/docs/README.last: > http://@hostname@/SystemDesigner > /var/www/linuxcoe-sd/html/docs/README.last: > http://@hostname@/SystemDesigner/docs I am not too surprised by this list in the "docs" space. All of these are in fact the "source" DocBook files, and I only try to ensure that the final .html (and .pdf) files (which are the ones visible from the WebUI of SystemDesigner are certain to have the substitutions. As noted before, I am still in process of a rather major overhaul of the documentation guides (due to a lot of the upgrades to the code), so there are in fact more changes coming. > /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: /etc@prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: @prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: COETHEME @prefix@/html/themes/default > /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: @prefix@/html/themes/default > /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/etc > /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/ > [... more in that file ...] > /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: /etc@prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: @prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/configuration_overlay.dkb: /etc/@prefix@/ > /var/www/linuxcoe-sd/html/docs/guides/eula.dkb: /etc@prefix@/html/eulas > /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc > /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc > /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: @prefix@/base/README > /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: /etc@prefix@/base > > (Seems the doc is not processed correctly in the .spec) > > Bruno. > -- > Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET > http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net > Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux > La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 12:17:03
|
Bruno Cornec said on Wed, Nov 21, 2007 at 11:38:09AM +0100:
> # from previous configure run
> export prefix=/var/www/linuxcoe-sd
> export exec_prefix=${prefix}
> export bindir=${exec_prefix}/bin
> export sbindir=${exec_prefix}/sbin
> export libexecdir=${exec_prefix}/libexec
> export datadir=${datarootdir}
> export datarootdir=${prefix}/share
Isn't the order here reversed ?
> export MKISOFS=SKIP
> export SENDMAIL=SKIP
> export APACHE=SKIP
> export APACHECTL=SKIP,
> export APACHE2CTL=SKIP
>
> Shouldn't those SKIP be replaced by what is also in binaries.pm ?
Still answering myself. Probably not. Because that script is especially
used to create the correct binaries.pm, so point is void.
> The diff with the working machine gives (< works, > doesn't)
>
> 13c13
> < export localstatedir=/var/lib
> ---
> > export localstatedir=/var
That still look strange to me.
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
|
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 10:39:28
|
Bruno Cornec said on Wed, Nov 21, 2007 at 10:38:38AM +0100:
> Humm I found one strange think from my point of view:
>
> In /etc/linuxcoe-sd/linuxcoe.rc I have:
> # FTP_PATH - where the bootable images are made available for download
> FTP_PATH @ftppubdir@/LinuxCOE/images
>
> Is that normal ?
Yes. It is according to the doc.
Now comparing a server which works with the one which doesn't I found
other diffs:
my /etc/linuxcoe-sd/includes/config.state is probably wrong:
#! /bin/sh
# from previous configure run
export prefix=/var/www/linuxcoe-sd
export exec_prefix=${prefix}
export bindir=${exec_prefix}/bin
export sbindir=${exec_prefix}/sbin
export libexecdir=${exec_prefix}/libexec
export datadir=${datarootdir}
export datarootdir=${prefix}/share
export sysconfdir=/etc/linuxcoe-sd
export sharedstatedir=${prefix}/com
export localstatedir=/var
export libdir=${exec_prefix}/lib
export includedir=${prefix}/include
export oldincludedir=/usr/include
export infodir=${datarootdir}/info
export mandir=/usr/share/man
export PACKAGE_NAME=linuxcoe-sd
export PACKAGE_VERSION=4.1
export webalias=SystemDesigner
export httpdcfgdir=/etc/httpd/conf.d
export docrootdir=/var/www/html
export httpd_user=apache
export httpd_group=apache
export sudoers_cfg=/etc/sudoers
export TAR=/bin/tar
export CPIO=/bin/cpio
export GZIP=/bin/gzip
export GUNZIP=/bin/gunzip
export DIFF=/usr/bin/diff
export FIND=/usr/bin/find
export MKISOFS=SKIP
export PERL=/usr/bin/perl
export PERLMOD=@PERLMOD@
export PALO=NONE
export SENDMAIL=SKIP
export APACHE=SKIP
export APACHECTL=SKIP,
export APACHE2CTL=SKIP
export SUDOERS=DOIT
export SUDO=SKIP
Shouldn't those SKIP be replaced by what is also in binaries.pm ?
The diff with the working machine gives (< works, > doesn't)
13c13
< export localstatedir=/var/lib
---
> export localstatedir=/var
32,33c32,35
< export FIND=/bin/find
< export MKISOFS=/usr/bin/mkisofs
---
> export FIND=/usr/bin/find
> export MKISOFS=SKIP
> export PERL=/usr/bin/perl
> export PERLMOD=@PERLMOD@
35,38c37,42
< export SENDMAIL=/usr/sbin/sendmail
< export APACHECTL=/usr/sbin/apachectl
< export APACHE2CTL=NONE
< export SUDO=/usr/bin/sudo
---
> export SENDMAIL=SKIP
> export APACHE=SKIP
> export APACHECTL=SKIP,
> export APACHE2CTL=SKIP
> export SUDOERS=DOIT
> export SUDO=SKIP
74c74
Maybe the PERLMOD,localstatedir,MKISOFS,SENDMAIL,APACHE,APACHECTL,
APACHE2CTL,SUDO lines are wrong too ?
It seems that that script is called by post-actions:
/var/www/linuxcoe-sd/bin/post-actions: test -f "/etc/linuxcoe-sd/includes/config.state" && . /etc/linuxcoe-sd/includes/config.state
I'm also skeptic by that one:
diff /var/www/linuxcoe-sd/includes/sysdes_paths.pm /mnt//var/www/linuxcoe-sd/includes/sysdes_paths.pm
14c14
< $VAR="/var/lib";
---
> $VAR="/var";
(which corresponds to the difference mentioned above in localstatedir)
I also found another issue:
# ls -al /var/lib/linuxcoe-sd/profiles/
total 20
drwxrwsr-x 2 apache apache 4096 Aug 30 02:09 .
drwxrwsr-x 3 apache apache 4096 Aug 30 02:09 ..
lrwxrwxrwx 1 root apache 29 Aug 30 02:09 profiles -> /var/lib/linuxcoe-sd/profiles
So I created the following:
# ln -s /var/log/linuxcoe-sd /var/lib/logs
But still no log file :-(
[root@localhost images]# find / -name sysdes.log
[root@localhost images]#
Still searching ;-)
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
|
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 09:38:47
|
Bruno Cornec said on Wed, Nov 21, 2007 at 10:14:25AM +0100: > Still scratching my head to understand why all that. Will look at it on > my side, but obviously will welcome again your help Bryan. Humm I found one strange think from my point of view: In /etc/linuxcoe-sd/linuxcoe.rc I have: # FTP_PATH - where the bootable images are made available for download FTP_PATH @ftppubdir@/LinuxCOE/images Is that normal ? Then looking for the '@' in linuxcoe installed files, I found some other unexpanded macros: /var/www/linuxcoe-sd/html/docs/README.last: http://@hostname@/SystemDesigner /var/www/linuxcoe-sd/html/docs/README.last: http://@hostname@/SystemDesigner/docs /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: /etc@prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: @prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: COETHEME @prefix@/html/themes/default /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: @prefix@/html/themes/default /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/etc /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/ [... more in that file ...] /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: /etc@prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: @prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/configuration_overlay.dkb: /etc/@prefix@/ /var/www/linuxcoe-sd/html/docs/guides/eula.dkb: /etc@prefix@/html/eulas /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: @prefix@/base/README /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: /etc@prefix@/base (Seems the doc is not processed correctly in the .spec) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 09:14:35
|
Bruno Cornec said on Wed, Nov 21, 2007 at 01:00:35AM +0100: > > I have updated configure and post-install scripts to do the "right" > > think, AFAICT. Basically the former now gives one the options to > > skip anything I check for, and the latter can try to find the > > commands on the target install system. > > Ok, restarting the VM build process. should take all the night here. I installed this morning the new packages. Even if the binaries.pm modules looks better: [root@localhost ~]# more /var/www/linuxcoe-sd/includes/binaries.pm package binaries; # Blast these programs into the name space of calling scripts # Used by nph-* scripts only (and coe_profiles for sendmail) require Exporter; @ISA = qw(Exporter); @EXPORT = qw($TAR $CPIO $GZIP $GUNZIP $DIFF $FIND $MKISOFS $PALO $SENDMAIL $SUDO); use vars @EXPORT; # Needed programs (beyond those of FHS expected in /bin) $TAR="/bin/tar"; $CPIO="/bin/cpio"; $GZIP="/bin/gzip"; $GUNZIP="/bin/gunzip"; $DIFF="/usr/bin/diff"; $FIND="/usr/bin/find"; $MKISOFS="/usr/bin/mkisofs"; $PALO="NONE"; $SENDMAIL="/usr/sbin/sendmail"; $SUDO="/usr/bin/sudo"; 1; There is still an Internal Server Error at the end, when trying to create the iso. And still no log at all, and still the wrong symlink: [root@localhost ~]# grep LOGFILE !$ grep LOGFILE /etc/linuxcoe-sd/linuxcoe.rc # LOGFILE - defines where SysDes writes it's debug data, LOGFILE >>/var/log/linuxcoe-sd/sysdes.log # If not spec'd, defaults to LOGFILE above [root@localhost ~]# ls -al /var/log/linuxcoe-sd/ total 20 drwxrwsr-x 2 apache apache 4096 Aug 30 02:09 . drwxr-xr-x 12 root root 4096 Nov 21 2007 .. lrwxrwxrwx 1 root apache 20 Aug 30 02:09 linuxcoe-sd -> /var/log/linuxcoe-sd Still scratching my head to understand why all that. Will look at it on my side, but obviously will welcome again your help Bryan. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 00:02:14
|
Bryan Gartner said on Tue, Nov 20, 2007 at 12:51:54PM -0700: > > > Ok, I did the perl modules, and also mkisofs and sendmail which may not > > > be in a VM either. (The rest is really part of core distros). > > > > Excellent, thanks! And I am hoping you have added all of these > > as RPM dependencies, since you have now effectively disabled the > > checks. We may also need to revisit this issue with the post-install > > script, to repopulate some values on the target install system. > > I have updated configure and post-install scripts to do the "right" > think, AFAICT. Basically the former now gives one the options to > skip anything I check for, and the latter can try to find the > commands on the target install system. Ok, restarting the VM build process. should take all the night here. > P.S. FWIW, I cannot replicate your circular links re: log > files/directories. Well for me just installing my base rpm shows it. I need to look at it closer, but it's minor ATM. Thanks a lot for your 'SKIP' fixes ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-20 19:54:43
|
Bruno, > > Ok, I did the perl modules, and also mkisofs and sendmail which may not > > be in a VM either. (The rest is really part of core distros). > > Excellent, thanks! And I am hoping you have added all of these > as RPM dependencies, since you have now effectively disabled the > checks. We may also need to revisit this issue with the post-install > script, to repopulate some values on the target install system. I have updated configure and post-install scripts to do the "right" think, AFAICT. Basically the former now gives one the options to skip anything I check for, and the latter can try to find the commands on the target install system. HTH, bryang P.S. FWIW, I cannot replicate your circular links re: log files/directories. |
|
From: Bruno C. <Bru...@hp...> - 2007-11-20 15:23:43
|
Bryan Gartner said on Tue, Nov 20, 2007 at 07:45:30AM -0700: > > Ok, I did the perl modules, and also mkisofs and sendmail which may not > > be in a VM either. (The rest is really part of core distros). > > Excellent, thanks! And I am hoping you have added all of these > as RPM dependencies, since you have now effectively disabled the > checks. yes, for the moment I have: $ grep Requires pbconf/linuxcoe-sd-base/rpm/linuxcoe-sd-base.spec Requires: php >= 4.0.4, perl, sudo, PBDEP $ pbg PBDEP | grep = [...] ./pbconf/linuxcoe-sd-base/pbfilter/rpm.pbf:filter PBDEP = httpd, mkisofs ./pbconf/linuxcoe-sd-base/pbfilter/md.pbf:filter PBDEP = apache, cdrkit-genisoimage I need to re-intriduce a dependency on perl-CGI, when that package exist separately and is needed. Later :-( > We may also need to revisit this issue with the post-install > script, to repopulate some values on the target install system. > > I've now been able to generate RPMs for quite a lot of distro. The only > > one for which I have a pb I need to see is fedora 7 (my VM may have > > something wrong BTW, need to check). > > > > Could some of you please check whether it works also for them ? (I know > > that the removal of packages needs more work, again more on that later > > on). Well I found an interesting issue on RHEL 4 for which I'm doing some tests for my training. The tool in charge of computing dependencies for perl as a bug ;-) When it encounter that pattern: '^[ \t]*use' it thinks this is a perl require, even if it's in a printf :-( So my last commit 'fixes' 2 messages which created false dependencies on "it" and "the" !! > If I install, say linuxcoe-sd-data-opensuse*, I should get > linuxcoe-sd-base due to a dependency, correct? Yep: $ grep Requires pbconf/linuxcoe-sd-data-opensuse/rpm/linuxcoe-sd-data-opensuse.spec Requires: linuxcoe-sd-base, PBDEP > > Next step is to produce .deb packages, but may be later in December, as > > I need now to work on a LinuxCOE training with my packages ;-) > > I will be doing a couple of tweaks to the debian packaging (and will > do my best to migrate those updates to the pbuilder equivalents). Ok, feel free to ask help for that. I've documented how to use pb at http://trac.project-builder.org/wiki/NetPerfExample I do not have pb packages for deb based distro yet :-( Also for pb to work you need a patch to AppConfig. > And I will be starting on my prep to deliver MondoRescue training > in early December. he he !! > BTW, I have gotten OCSinventory/OpenVAS/OpenNMS up and running > as well. Since the first two (at least) are likely candidates > for dploy.org, we may want to help them out with some packaging > as well. Good stuff. Packages exist for OCS for Mandriva, and from the person who did it, it was a sort of nightmare :-( They do not seem to be good at separating stuff, so packaging is much more complex. But at least I can derive easily a .spec for it. Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-20 14:48:13
|
Bruno, On Mon, Nov 19, 2007 at 03:49:05PM +0000, Cornec, Bruno (Linux Consultant) wrote: > Hello, > > Bruno Cornec said on Fri, Nov 16, 2007 at 07:59:14PM +0100: > > > > > Or if you don't mind, I can try to derive what you've done for > > > > sudo/apachectl and do it for the perl modules. > > > > > > Either option is fine by me, go for it ! > > > > Will do that ... but this week-end as it's a bit late now. Hope I'll > > have enough time as I have a concert also to prepare (Cf: > > http://pagesperso-orange.fr/ens.voc.variations/ french only sorry !) > > > Ok, I did the perl modules, and also mkisofs and sendmail which may not > be in a VM either. (The rest is really part of core distros). Excellent, thanks! And I am hoping you have added all of these as RPM dependencies, since you have now effectively disabled the checks. We may also need to revisit this issue with the post-install script, to repopulate some values on the target install system. > I've now been able to generate RPMs for quite a lot of distro. The only > one for which I have a pb I need to see is fedora 7 (my VM may have > something wrong BTW, need to check). > > Could some of you please check whether it works also for them ? (I know > that the removal of packages needs more work, again more on that later > on). > > Short instructions: > 1/ Download packages from ftp://ftp.project-builder.org/ under which > you'll find one directory per distro (fedora mandrake mandriva redhat rhel > sles suse) and below one directory per version (e.g. under mandriva 2005 > 2006.0 2007.0 2007.1 2008.0). You have normaly 1 main package to > download (linuxcoe-sd-base-4.1-1.mdv2008.0.noarch.rpm) and 11 other > optional packages depending on what delivery you want to setup: > linuxcoe-sd-data-centos-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-debian-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-fedora-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-nld-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-opensuse-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-rhel-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-scientific-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-sles-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-suse-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-data-ubuntu-4.1-1.mdv2008.0.noarch.rpm > linuxcoe-sd-docs-4.1-1.mdv2008.0.noarch.rpm If I install, say linuxcoe-sd-data-opensuse*, I should get linuxcoe-sd-base due to a dependency, correct? > 2/ After having done your rpm -ivh, you have to install the boot images > content in addition under /etc/linuxcoe-sd/images. Get them from > http://www.instalinux.com/snapshots/images/ More details in > /var/www/linuxcoe-sd/images/README > > 3/ Celebrate ;-) > > At least, for me it is now as simple as that. > > Next step is to produce .deb packages, but may be later in December, as > I need now to work on a LinuxCOE training with my packages ;-) I will be doing a couple of tweaks to the debian packaging (and will do my best to migrate those updates to the pbuilder equivalents). And I will be starting on my prep to deliver MondoRescue training in early December. BTW, I have gotten OCSinventory/OpenVAS/OpenNMS up and running as well. Since the first two (at least) are likely candidates for dploy.org, we may want to help them out with some packaging as well. > Happy Thanksgiving for those of you in the US. Thank you, do your best to miss us while we rest, bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-11-19 15:50:56
|
Hello, Bruno Cornec said on Fri, Nov 16, 2007 at 07:59:14PM +0100: > > > Or if you don't mind, I can try to derive what you've done for > > > sudo/apachectl and do it for the perl modules. > > > > Either option is fine by me, go for it ! > > Will do that ... but this week-end as it's a bit late now. Hope I'll > have enough time as I have a concert also to prepare (Cf: > http://pagesperso-orange.fr/ens.voc.variations/ french only sorry !) Ok, I did the perl modules, and also mkisofs and sendmail which may not be in a VM either. (The rest is really part of core distros). I've now been able to generate RPMs for quite a lot of distro. The only one for which I have a pb I need to see is fedora 7 (my VM may have something wrong BTW, need to check). Could some of you please check whether it works also for them ? (I know that the removal of packages needs more work, again more on that later on). Short instructions: 1/ Download packages from ftp://ftp.project-builder.org/ under which you'll find one directory per distro (fedora mandrake mandriva redhat rhel sles suse) and below one directory per version (e.g. under mandriva 2005 2006.0 2007.0 2007.1 2008.0). You have normaly 1 main package to download (linuxcoe-sd-base-4.1-1.mdv2008.0.noarch.rpm) and 11 other optional packages depending on what delivery you want to setup: linuxcoe-sd-data-centos-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-debian-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-fedora-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-nld-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-opensuse-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-rhel-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-scientific-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-sles-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-suse-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-data-ubuntu-4.1-1.mdv2008.0.noarch.rpm linuxcoe-sd-docs-4.1-1.mdv2008.0.noarch.rpm 2/ After having done your rpm -ivh, you have to install the boot images content in addition under /etc/linuxcoe-sd/images. Get them from http://www.instalinux.com/snapshots/images/ More details in /var/www/linuxcoe-sd/images/README 3/ Celebrate ;-) At least, for me it is now as simple as that. Next step is to produce .deb packages, but may be later in December, as I need now to work on a LinuxCOE training with my packages ;-) Happy Thanksgiving for those of you in the US. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-16 18:59:43
|
Bryan Gartner said on Fri, Nov 16, 2007 at 11:46:55AM -0700: > > Of course, when building on older distro, with older perl, those modules > > are not necessarily part of the core, but were additional modules. > > Hmm, both of those modules have been in perl since (at least) the 5.005 era. > And CGI goes back to 5.004 (which is the oldest cataloged on the > perldoc.perl.org page). Strange. On the first distro I checked (mdk 10.1) it didn't work. I just checked and it provides perl 5.8.5 but perl-CGI (3.05) is a separate package. > > Or if you don't mind, I can try to derive what you've done for > > sido/apachectl and do it for the perl modules. > > Either option is fine by me, go for it ! Will do that ... but this week-end as it's a bit late now. Hope I'll have enough time as I have a concert also to prepare (Cf: http://pagesperso-orange.fr/ens.voc.variations/ french only sorry !) Happy week-end to all, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-16 18:50:22
|
Bruno, On Fri, Nov 16, 2007 at 05:54:29PM +0000, Cornec, Bruno (Linux Consultant) wrote: > Bruno Cornec said on Fri, Nov 16, 2007 at 06:48:14PM +0100: > > > > In reality, I should do similar checks for all those not required by > > > FHS, however I drew the line at Apache/Sudo since those two I have to > > > directly integrate with for a functioning SystemDesigner. The other > > > checks were left as a failure if not found. > > > > Fine. I don't think it will cause a pb. > > Well nearly :-( > Now it warns on: > > checking presence of "CGI"... configure: error: cannot find module via > /usr/bin/perl -e "use CGI" > > And looking at configure, I guess it will be the same for Carp. And I > think that's all. > > Of course, when building on older distro, with older perl, those modules > are not necessarily part of the core, but were additional modules. Hmm, both of those modules have been in perl since (at least) the 5.005 era. And CGI goes back to 5.004 (which is the oldest cataloged on the perldoc.perl.org page). > I can of course add them to the VM (it's less a problem than Apache in > fact, as they do not have other dependencies themselves). > > Or if you don't mind, I can try to derive what you've done for > sido/apachectl and do it for the perl modules. Either option is fine by me, go for it ! bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-11-16 17:55:34
|
Bruno Cornec said on Fri, Nov 16, 2007 at 06:48:14PM +0100: > > In reality, I should do similar checks for all those not required by > > FHS, however I drew the line at Apache/Sudo since those two I have to > > directly integrate with for a functioning SystemDesigner. The other > > checks were left as a failure if not found. > > Fine. I don't think it will cause a pb. Well nearly :-( Now it warns on: checking presence of "CGI"... configure: error: cannot find module via /usr/bin/perl -e "use CGI" And looking at configure, I guess it will be the same for Carp. And I think that's all. Of course, when building on older distro, with older perl, those modules are not necessarily part of the core, but were additional modules. I can of course add them to the VM (it's less a problem than Apache in fact, as they do not have other dependencies themselves). Or if you don't mind, I can try to derive what you've done for sido/apachectl and do it for the perl modules. WDYT ? Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-16 17:48:30
|
Bryan Gartner said on Fri, Nov 16, 2007 at 10:17:58AM -0700: > Okay I have now setup: > > --without-APACHE skip auto-integration with Apache webserver > --without-APACHECTL skip check for apache*ctl > --without-SUDOERS skip auto-integration with sudo > --without-SUDO skip checks for apache*ctl > > I believe that the --without-APACHECTL and --without-SUDO will > do what you requested. Great ! Thanks a lot ! Just trying now to see how it behaves in my VMs. > Actually there are a whole set of commands that are beyond mandatory > in a base installation that SystemDesigner relies upon. You just > happen to have most of these in your qemu packaging building instances ;) Well yes I do not count what nearly every distro has in its base (perl e.g. ) > In reality, I should do similar checks for all those not required by > FHS, however I drew the line at Apache/Sudo since those two I have to > directly integrate with for a functioning SystemDesigner. The other > checks were left as a failure if not found. Fine. I don't think it will cause a pb. > For the debian crowd, this seems to be handling quite gracefully, as > any package build environment starts at the same base level, and uses > the package description to fill in build dependencies, before trying > to create a given package. I am less familiar on how the rpm-based > distributions handle their package builds. Do you mean that Debian automatically install missing packages required for the build ? I would find that too excessive for my side. If everything goes well, monday you'll have a full set of packages ready to use for all RPMs based distro I support. debs are of course the next to be done just after. FYI, installing a LinuxCOE server with those is just: rpm -Uvh linuxcoe*rpm more /var/www/linuxcoe-sd/images/README cd /tmp wget -m http://www.instalinux.com/snapshots/images/ cp -a www.instalinux.com/snapshots/images/*.tar /etc/linuxcoe-sd/images/ Enjoy !! Now I'll also work on the dploy.org added value consisting in linking that with the mirror processes to have more automatic links with the waystation part. (+PXE stuff) Again more on that later. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-16 17:21:22
|
Bruno,
On Fri, Nov 16, 2007 at 07:01:14AM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bryan Gartner said on Thu, Nov 15, 2007 at 03:46:55PM -0700:
>
> > > What about adding anoption to configure (for packager, which means me
> > > atm) allowing for bypassing those checks ? That would of course not be
> > > on by default.
> > >
> > > Would that work for you ?
> >
> > Those kinds of checks are already there, IIRC (./configure --help)
> >
> > --without-APACHE skip auto-integratation with Apache webserver
> > --without-SUDOERS skip auto-integration with sudo
Okay I have now setup:
--without-APACHE skip auto-integration with Apache webserver
--without-APACHECTL skip check for apache*ctl
--without-SUDOERS skip auto-integration with sudo
--without-SUDO skip checks for apache*ctl
I believe that the --without-APACHECTL and --without-SUDO will
do what you requested.
> I want the integration. What I don't want is the check that apache
> exists.
>
> With the integration activated it will make a symlink to LInuxCOE.conf
> httpd file correctly, anf thus when I install the package on a machine
> with an apache server (which is a requirement of my package) it just
> works. sudo is indeed less a problem as it's nearly mandatory in distro
> nowadays.
Actually there are a whole set of commands that are beyond mandatory
in a base installation that SystemDesigner relies upon. You just
happen to have most of these in your qemu packaging building instances ;)
If you peek at configure.ac, you will see these broken out by groupings.
In reality, I should do similar checks for all those not required by
FHS, however I drew the line at Apache/Sudo since those two I have to
directly integrate with for a functioning SystemDesigner. The other
checks were left as a failure if not found.
In general, this seems to be somewhat grey area WRT to package builders.
For the debian crowd, this seems to be handling quite gracefully, as
any package build environment starts at the same base level, and uses
the package description to fill in build dependencies, before trying
to create a given package. I am less familiar on how the rpm-based
distributions handle their package builds.
> If I remove the integration, I'll have to add it myself and won't be
> abelt to use the post-action script. Which is of course another
> possibility.
With any luck now, the skip checks will still do the right thing
on the installing host now (including the post-install integration).
bryang
|
|
From: Bruno C. <Bru...@hp...> - 2007-11-16 07:01:27
|
Bryan Gartner said on Thu, Nov 15, 2007 at 03:46:55PM -0700: > > What about adding anoption to configure (for packager, which means me > > atm) allowing for bypassing those checks ? That would of course not be > > on by default. > > > > Would that work for you ? > > Those kinds of checks are already there, IIRC (./configure --help) > > --without-APACHE skip auto-integratation with Apache webserver > --without-SUDOERS skip auto-integration with sudo Well that's different if I read them correctly. I want the integration. What I don't want is the check that apache exists. With the integration activated it will make a symlink to LInuxCOE.conf httpd file correctly, anf thus when I install the package on a machine with an apache server (which is a requirement of my package) it just works. sudo is indeed less a problem as it's nearly mandatory in distro nowadays. If I remove the integration, I'll have to add it myself and won't be abelt to use the post-action script. Which is of course another possibility. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-15 22:49:37
|
Bruno, > > What about adding anoption to configure (for packager, which means me > > atm) allowing for bypassing those checks ? That would of course not be > > on by default. > > > > Would that work for you ? > > Those kinds of checks are already there, IIRC (./configure --help) > > --without-APACHE skip auto-integratation with Apache webserver > --without-SUDOERS skip auto-integration with sudo > > I was thinking along same lines, but hadn't had a chance to try those > (since I had originally set them up). Unfortunately this appears to now be broken, but I will try to fix that later this evening. bryang |
|
From: Bryan G. <Bry...@HP...> - 2007-11-15 22:47:19
|
Bruno, On Thu, Nov 15, 2007 at 10:40:16PM +0000, Cornec, Bruno (Linux Consultant) wrote: > Bruno Cornec said on Thu, Nov 15, 2007 at 12:45:04AM +0100: > > > While trying to adapt my LinuxCOE pbconf tree to that, I encountered > > another issue, I think I mentioned earlier, but which is now hurting > > because it prevents me from creating the packages in the VM: > > > > configure: error: can not automatically integrate with Apache HTTP > > server > > > > My VMs try to keep the minimum needed to just allow the build of a > > software, not its installation. So I still think that those checks > > (which are useful) should be rather done at install time, rather than at > > build time. > > > > Bruno. > > Any Idea ? > > Answering to yself ;-) > > What about adding anoption to configure (for packager, which means me > atm) allowing for bypassing those checks ? That would of course not be > on by default. > > Would that work for you ? Those kinds of checks are already there, IIRC (./configure --help) --without-APACHE skip auto-integratation with Apache webserver --without-SUDOERS skip auto-integration with sudo I was thinking along same lines, but hadn't had a chance to try those (since I had originally set them up). bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-11-15 22:41:56
|
Bruno Cornec said on Thu, Nov 15, 2007 at 12:45:04AM +0100: > While trying to adapt my LinuxCOE pbconf tree to that, I encountered > another issue, I think I mentioned earlier, but which is now hurting > because it prevents me from creating the packages in the VM: > > configure: error: can not automatically integrate with Apache HTTP > server > > My VMs try to keep the minimum needed to just allow the build of a > software, not its installation. So I still think that those checks > (which are useful) should be rather done at install time, rather than at > build time. > > Bruno. > Any Idea ? Answering to yself ;-) What about adding anoption to configure (for packager, which means me atm) allowing for bypassing those checks ? That would of course not be on by default. Would that work for you ? Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-15 17:41:23
|
Bryan Gartner said on Thu, Nov 15, 2007 at 09:46:58AM -0700: > > I think there is an issue in th documentation. I'd like to propose the > > following patch: > > Good catch, yes this is from the N-2 revision of pathing. I am Ouf ! I wasn't sure at all to understand those stuff correctly. Happy to make my first real patch ;-) > currently walking the docs and adding/modifying much, so I will > put this (or perhaps more correctly @sysconfdir@ as you alluded > to). Yep. That would be great. In fact I found this while trying to see the process to add the images content to my RPMs installed linuxcoe. I think it could be also useful to have a link to the README under images available in the documentation links as well. > You are welcome to apply this, but I may have further updates real > soon now, Done. I increase my Ohloh score ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-15 16:50:03
|
Bruno, On Thu, Nov 15, 2007 at 03:47:08PM +0000, Cornec, Bruno (Linux Consultant) wrote: > Hello, > > I think there is an issue in th documentation. I'd like to propose the > following patch: Good catch, yes this is from the N-2 revision of pathing. I am currently walking the docs and adding/modifying much, so I will put this (or perhaps more correctly @sysconfdir@ as you alluded to). > -bash-3.2$ cvs diff ./docs/guides/configuration.dkb > Index: ./docs/guides/configuration.dkb > =================================================================== > RCS file: /cvsroot/linuxcoe/docs/guides/configuration.dkb,v > retrieving revision 1.4 > diff -r1.4 configuration.dkb > 65c65 > < /etc/@prefix@/ > --- > > @prefix@/etc > 137c137 > < /etc/@prefix@/ > --- > > @prefix@/etc > > In fact when I use --sysconfdir in configure the dir generated is not > referenced correctly in the documentation. I think the above patch > should fix it but there may bu side effects so I'd like confirmation > before applying. You are welcome to apply this, but I may have further updates real soon now, bryang |
156 messages has been excluded from this view by a project administrator.
