linuxcoe-devel

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Bruno Cornec said on Mon, Oct 22, 2007 at 04:13:17PM +0200:

> `/cvsroot/linuxcoe/pbconf/linuxcoe-sd-data-opensuse'
> (/cvsroot/linuxcoe/pbconf/linuxcoe-sd-data-opensuse/#cvs.lock): No such
> file or directory
> cvs commit: lock failed - giving up
> cvs [commit aborted]: lock failed - giving up
>=20
> Do someone on this list has the possibility to unlock this, or is it a
> SF.net request to make ?

Ok, it seems I'm not CVS friendly. I removed all my local CVS dir under
that subdir, re did cvs add and this time cvs ci was successful.

Bruno.
--=20
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA I=
ET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.n=
et
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/lin=
ux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.o=
rg

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

Bruno,

On Wed, Oct 17, 2007 at 11:42:07PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Hello,
> 
> Bryan Gartner said on Wed, Oct 17, 2007 at 11:01:06AM -0600:
> > Sorry for my proposal/diversion, I have recrafted the following modules to
> > use the previous namespace:
> >
> >       linuxcoe-sd-base
> >       linuxcoe-sd-docs
> 
> Oh, great ! so now my system works directly, and I do not have any
> warning/error message anymore:

Yay!

> # urpmi /usr/src/svn/LinuxCOE/build/RPMS/noarch/linuxcoe-sd-docs-devel-1.mdv2008.0.noarch.rpm /usr/src/svn/LinuxCOE/build/RPMS/noarch/linuxcoe-sd-base-devel-1.mdv2008.0.noarch.rpm
> 
> installing linuxcoe-sd-base-devel-1.mdv2008.0.noarch.rpm linuxcoe-sd-docs-devel-1.mdv2008.0.noarch.rpm from /usr/src/svn/LinuxCOE/build/RPMS/noarch
> Preparing...  #################################################################################
>       1/2: linuxcoe-sd-base #################################################################################
> Reloading httpd: [  OK  ]
>       2/2: linuxcoe-sd-docs #################################################################################
> 
> I'm already happy with that ;-)

You are almost caught up with me now ;)

> More tests tomorrow to see if it really works. (I need to configure the
> apache server now).
> 
> The remaining question I have is for the name of the directories.
> Currently by default they are named /var/log/linuxcoe-sd-base, ...
> /var/www/linuxcoe-sd-base. I wonder whether it would be cleaner to call
> those just /var/www/linuxcoe-sd (or even /var/www/linuxcoe) for more
> clarity on the admin side, and as all packages will add content below.
> May be solved later on BTW.
> 
> >       linuxcoe-sd-data-centos
> >           (and note that this module no longer delivers images)

Actually, my debian packages (which now include base+docs+Distro=FOSS
ones) all install to the same prefix which is currently
/usr/share/linuxcoe-sd/4.1 (yes I know you object to the 4.1 portion),
but the point remains the same (and that issue is still bubbling to
the top of my todo list).

And I have a vm (distinct from the vm that I build these .debs on) that
has all of these installed and working. FWIW, all of the boot images
are currently still in CVS in their original location, yet their
respecitve Makefile.am just doesn't deliver them.  One can still
obtain the images from:

	http://instalinux.com/snapshots/images

And I'll note that in the README and respective documents when this
process is complete.

> I just looked today at the fedora one to see what was needed and what
> had to be generated. If you want I can take a closer look at that based
> on the existing script for ideas, and write a perl script that creates
> what is required for LinuxCOE based on a mirrored centos setup.

What I was thinking is pretty general, basically have the user supply
the prefix to a "known" good repository, and then recursively look
to find the correct kind of files,  then do the "magic" as noted
in the images/README file.  And for extra credit, remember that the
repository does not need to reside locally, but could simply be
a well-known internet mirror ;)  With something like this, whether
you mirror, use mrepo, or just reference somebody else's repository,
you would be covered.

> > and have updated the packaging/<module>/debian artifacts to correctly
> > package them as .debs.  I will work through the remaining modules
> > this week.  After this round of modifications, I will modify:
> >
> >       linuxcoe-sd-data-*
> >           name stds, skip image delivery
> >         linuxcoe-sd-*
> >           pull back version number in delivered directory hierarchy
> >         linuxcoe-sd-*.deb
> >           migrate to .deb via PB
> 
> On that one, if you want, I can copy your current content under pbconf,
> make the adaptations, and you could then test it, once you have a
> working pb on your side ;-)

All I have yet to finish are the nonFOSS distro's.  So feel free to
give it a try with base+one other.

> I'm still not done with all my rpm VMs setup, so have not yet a .deb for pb
> itself. Will come soon I hope.

FYI, I think I have a lead on the relaxing automake1.4 dependency and
am doing some testing now.

bryang

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Bruno Cornec said on Tue, Oct 16, 2007 at 11:58:18PM +0200:

> I'm right now working on having a single spec file for all my 21 rpm
> based VMs. Once it's done, adapting your debian build files to pb will
> be easy, and as you're on Debian based systems, you'll then be able to
> benefit from what I'm doing.
> 

I still have one remaining issue.

The current ChangeLog files (that pb uses to create %changelog entries
for .spec file) doesn't content anythink concerning the version it
applies to.

What I mean is that for mondo e.g. I have:

# $Id: ChangeLog 1679 2007-10-11 23:24:45Z bruno $

MONDO CHANGES

2.2.5 (2007-10-11)
- Build process adapted to use pb http://trac.project-builder.org (Bruno
  Cornec) 
- Fix #137 and #3 issue with large exclude list (> 1000 chars) (Bruno Cornec)
[...]

2.2.4 (2007-07-06)
- Size of DVD is 4482 (or more surely 4480 to avoid problems - used everywhere) (Bruno Cornec)
- New Hardware migration guide with P2V (Eric Montaut/Gallig/Renaud/Bruno Cornec)
[...] etc


Which allows me to easily process that.

I do not really care about format in itself (I will have to provide a
converter), but I care about info such as version and date.

Currently we have:

2005-09-27      Bryan Gartner   <bry...@hp...>

        * incorporated v4 of the LinuxCOE System Designer

2005-08-01      Bryan Gartner   <bry...@hp...>

        * automated the integration of the LinuxCOE System Designer
          to a system, and partitioned the package into modules
          for each distribution

Would it be at least possible to add the version concerned ?
(Which goes back to my question on version management from the other day
BTW).

Thanks for your feedbacks.

Bruno.

PS: I have an option in pb to ignore logs that I'll use meanwhile, but
that's not good practice IMHO.
-- 
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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

> I still have one remaining issue.

And here is the question of the day ;-)

Currently the autoconf.ac script makes checks on tools such as mkisofs,
perl modules, ...

The problem is that this should be rather done a run time than at build
time, because the machine on which you're building the tool may be
different from the machine you want to install it on.

Typically in my VMs, I do not have mkisofs, nor perl-CGI for the moment.
So should I add them to make the build process happy (even if I don't
think it's the right thing to do, I'll do it if that's the concensus),
or should I work on a patch to move those checks at run time or/and in
dependencies either with .spec requires, or the same for deb.

What is your take on this one ?

FYI, I have generated a lot of RPMS today, available at
ftp://ftp.project-builder.org , except that the main one,
linuxcoe-sd-base is missing :-(

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

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

Bruno,

On Thu, Oct 25, 2007 at 10:34:06PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> > I still have one remaining issue.
> 
> And here is the question of the day ;-)
> 
> Currently the autoconf.ac script makes checks on tools such as mkisofs,
> perl modules, ...
> 
> The problem is that this should be rather done a run time than at build
> time, because the machine on which you're building the tool may be
> different from the machine you want to install it on.

And if you are installing from CVS/tar, this is a "runtime" check, which
I'd prefer not to lose the ability to do.  So, I vote to retain the
checks there.

> Typically in my VMs, I do not have mkisofs, nor perl-CGI for the moment.
> So should I add them to make the build process happy (even if I don't
> think it's the right thing to do, I'll do it if that's the concensus),
> or should I work on a patch to move those checks at run time or/and in
> dependencies either with .spec requires, or the same for deb.
> 
> What is your take on this one ?

I am quite open to clever autoconf-ish ways to turn off those checks for
your use case, though.

> FYI, I have generated a lot of RPMS today, available at
> ftp://ftp.project-builder.org , except that the main one,
> linuxcoe-sd-base is missing :-(

Nice job!

bryang

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

Bruno,

On Wed, Oct 24, 2007 at 05:13:20PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> I still have one remaining issue.
> 
> The current ChangeLog files (that pb uses to create %changelog entries
> for .spec file) doesn't content anythink concerning the version it
> applies to.

Hmm, you have pointed out one complete oversight on my part (that
is not maintaining the ChangeLog ... for a very long time).  Whoops!

> What I mean is that for mondo e.g. I have:
> 
> # $Id: ChangeLog 1679 2007-10-11 23:24:45Z bruno $

I can certainly add the # $Id: $, yet for CVS, this really only reflects the
revision of that particular file.

> MONDO CHANGES
> 
> 2.2.5 (2007-10-11)
> - Build process adapted to use pb http://trac.project-builder.org (Bruno
>   Cornec)
> - Fix #137 and #3 issue with large exclude list (> 1000 chars) (Bruno Cornec)
> [...]
> 
> 2.2.4 (2007-07-06)
> - Size of DVD is 4482 (or more surely 4480 to avoid problems - used everywhere) (Bruno Cornec)
> - New Hardware migration guide with P2V (Eric Montaut/Gallig/Renaud/Bruno Cornec)
> [...] etc
> 
> 
> Which allows me to easily process that.
> 
> I do not really care about format in itself (I will have to provide a
> converter), but I care about info such as version and date.

Actually, AFAICT, the format is completely standard:

	http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html

and in fact this was the reference for the original templates used.
 
> Currently we have:
> 
> 2005-09-27      Bryan Gartner   <bry...@hp...>
> 
>         * incorporated v4 of the LinuxCOE System Designer
> 
> 2005-08-01      Bryan Gartner   <bry...@hp...>
> 
>         * automated the integration of the LinuxCOE System Designer
>           to a system, and partitioned the package into modules
>           for each distribution
> 
> Would it be at least possible to add the version concerned ?
> (Which goes back to my question on version management from the other day
> BTW).

So, not really sure where to go on this one (other than poke myself to
update this as changes are made).  That said, the debian/changelog file
which should be maintained (and was created) by the dch command does
have a slightly different format.  Color me confused on how to proceed.

bryang

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Hello Bryan and others,

Bryan Gartner said on Fri, Oct 26, 2007 at 06:25:02AM -0600:

> On Thu, Oct 25, 2007 at 10:34:06PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> > The problem is that this should be rather done a run time than at build
> > time, because the machine on which you're building the tool may be
> > different from the machine you want to install it on.
> 
> And if you are installing from CVS/tar, this is a "runtime" check, which
> I'd prefer not to lose the ability to do.  So, I vote to retain the
> checks there.

OK, so I'd like to propose an alternative that may help both of us:

Could we do the check after the make integrate phase (e.g. a make check
new order) that would have to be called in the context of tar.gz install
(by Creating a cheked dummy file in the tree, that could be verified
before running anything). If there go on, if not, emit a warning rather
than running with CGI-Carp or something like that.

Of course that file could be touched by the spec/rules files to avoid
problems.

WDYT ?

> > FYI, I have generated a lot of RPMS today, available at
> > ftp://ftp.project-builder.org , except that the main one,
> > linuxcoe-sd-base is missing :-(
> 
> Nice job!

Nearly ;-) And I still have problems for the .deb, partly because of the
lack of changelog files.

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

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

Bruno,

On Fri, Oct 26, 2007 at 01:35:27PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Hello Bryan and others,
> 
> Bryan Gartner said on Fri, Oct 26, 2007 at 06:25:02AM -0600:
> 
> > On Thu, Oct 25, 2007 at 10:34:06PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> > > The problem is that this should be rather done a run time than at build
> > > time, because the machine on which you're building the tool may be
> > > different from the machine you want to install it on.
> >
> > And if you are installing from CVS/tar, this is a "runtime" check, which
> > I'd prefer not to lose the ability to do.  So, I vote to retain the
> > checks there.
> 
> OK, so I'd like to propose an alternative that may help both of us:
> 
> Could we do the check after the make integrate phase (e.g. a make check
> new order) that would have to be called in the context of tar.gz install
> (by Creating a cheked dummy file in the tree, that could be verified
> before running anything). If there go on, if not, emit a warning rather
> than running with CGI-Carp or something like that.

I was actually thinking of creative/reworked autoconf checks instead
(that you could turn off in packaging context).  Since make install
puts bits on your system, it would be frustrating to then have it tell
you later that you still needed dependencies.  And the current scheme
would already have turned off the apache integration, since it couldn't
find apache*ctl.

FWIW, you already have the ability to do:

	  --without-PACKAGE       do not use PACKAGE (same as
	  --with-PACKAGE=no)
	  --without-APACHE        skip auto-integratation with Apache webserver
	  --without-SUDOERS       skip auto-integration with sudo

so maybe I should just augment that list.

> > > FYI, I have generated a lot of RPMS today, available at
> > > ftp://ftp.project-builder.org , except that the main one,
> > > linuxcoe-sd-base is missing :-(
> >
> > Nice job!
> 
> Nearly ;-) And I still have problems for the .deb, partly because of the
> lack of changelog files.

Actually, the packaging/<module>debian/changelog files already have the
info you are looking for, I think.  And since we have yet to officially
produce .debs, they stand at 4.1-1, but the latter value should be
rev'd each time.

bryang

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Bryan Gartner said on Fri, Oct 26, 2007 at 07:53:12AM -0600:

> I was actually thinking of creative/reworked autoconf checks instead
> (that you could turn off in packaging context).  Since make install
> puts bits on your system, it would be frustrating to then have it tell
> you later that you still needed dependencies.  And the current scheme
> would already have turned off the apache integration, since it couldn't
> find apache*ctl.
> 
> FWIW, you already have the ability to do:
> 
> 	  --without-PACKAGE       do not use PACKAGE (same as
> 	  --with-PACKAGE=no)
> 	  --without-APACHE        skip auto-integratation with Apache webserver
> 	  --without-SUDOERS       skip auto-integration with sudo
> 
> so maybe I should just augment that list.

Humm does using --without-APACHE  avoids the creation of the conf file and u
its installation ? If yes, it's not what I want.

What about generating BOLD warnings, instead of aborting ending with 
"You build is correct but won't work on that system" ?
Remember that it's only for tar.gz, as for packages, depedencies take
care of that, and will enforce it.

After all it's not different when you use --nodeps with rpm to install a
package anyway.

Moreover, I forgot to mention it, but your checks are not working on all 
distros, as the most recent do not use mkisofs anymore but genisoimage, 
....  So you should check now for one or the other.

> Actually, the packaging/<module>debian/changelog files already have the
> info you are looking for, I think.  And since we have yet to officially
> produce .debs, they stand at 4.1-1, but the latter value should be
> rev'd each time.

I've not looked at why they were not produced, as I was already happy to
find a bunch of packages made automagically ;-) Will work on that ...
well honestly don't know exactly when as it's becoming hectic here :-)

Have a nice WE !
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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Bryan Gartner said on Fri, Oct 26, 2007 at 06:44:48AM -0600:

> Hmm, you have pointed out one complete oversight on my part (that
> is not maintaining the ChangeLog ... for a very long time).  Whoops!

As a socker player, I can say 1-0 ;-)

> > What I mean is that for mondo e.g. I have:
> > 
> > # $Id: ChangeLog 1679 2007-10-11 23:24:45Z bruno $
> 
> I can certainly add the # $Id: $, yet for CVS, this really only reflects the
> revision of that particular file.

Well that was really a detail. Useful, but not mandatory.

> Actually, AFAICT, the format is completely standard:
> 
> 	http://www.gnu.org/software/guile/changelogs/guile-changelogs_3.html

Humm, wasn't aware of thet one. But after reading I find it dated if I
may express my opinion.

When used in conjunction of a good CMS (CVS being average for me, SVN
good, and maybe git, arch, ... excellent as I never tried them) I think
some of those rules are useless (especially documenting the file names
changed, which is the role of the SCM). 

In particular, I think the link between the version and the list of
modification is the most capital information. And it's completely
missing here, and could be unrelated to dates events.

And also currently it's rather considered poorly to add e-mail addresses
in those files, as it would be a help for spammers :-( (I changed mine
in particular for that).

I took example from the result of locate ChangeLog on my HDD (for
non-gnu projects as those tend to respect the format of the project ;-):

Kino:
=====
[...]
Changes in version 1.1.1:
        Changes by Dan Dennedy:
        - commands.cc: bugfix segfault on crash recovery with gtk+
          version < 2.11

Changes in version 1.1.0:
        Changes by Dan Dennedy:

less:
=====
[...]
Version 1.53 Apr 11, 2006
- support for Openoffice documents (Florian Cramer, Vincent Lefevre)
- support for RAR archives (suggested by Cindy Leonhardt)
[...]
Version 1.44 Dec 14, 2004
-------------------------
- fixes in configure script (Slaven Rezic)

netcat:
=======
[*] Sun Jan 11 2004 - netcat v0.7.1

  o Fixed bug in UDP connection code, using pktinfo support. [BUG
#796765]
  o Fixed a segfault in the DNS lookup routines, caused by invalid DNS
    configurations.
[...]
[*] Thu Aug 21 2003 - netcat v0.7.0

  o Added command line switch `-c' (close), which shuts down the
connection
    on EOF from stdin without waiting for any answer from remote host.

Honestly taken randomly.

So I'd tend to conclude that only official GNU projects follow the rule,
other use varied format.
Again, my problem is that I need to extract info from the changelog to
generate the %changelog entries for spec file (and I do the same for deb
changelog as well). But I really need the version info for the spec. So
it needs to be somewhere (could be in another place. Again I don't want
to duplicate info, just keeping it complete and coherent in one single
place, and generate the rest from that single instance.

Time for a ChangeLog RFC ;-)

> So, not really sure where to go on this one (other than poke myself to
> update this as changes are made).  That said, the debian/changelog file
> which should be maintained (and was created) by the dch command does
> have a slightly different format.  Color me confused on how to proceed.

What I can propose is a tool in pb which would:

Take a pb ChangeLog file (under pbconf/pkg) and process it to create a
ChangeLog file in the tar file, the %changelog section in the spec and
the changelog file for deb. THat's pretty easy. Keep the objective of a
single source and respect the target of good changelogs everywhere where
it's needed.

Your ideas ?

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Bryan Gartner said on Wed, Nov 21, 2007 at 07:46:12AM -0700:

> >         export PERLMOD=@PERLMOD@
> 
> I have fixed this (basically forgot to have configure publish this
> value).

Thanks !

> >         export APACHECTL=SKIP,
> 
> I have fixed the errant comma.

Thanks !

> >         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).

Sorry, I was trying to understand but didn't thought enough before
typing :-( It's now clearer (still earning a lot !)

> > 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?

Yes, that's true. on RHEL4 it's /var, on MDV it's /var/lib, so it
*seems* correct. I just was looking for a side effect somewhere, as
nothing obvious pops up :-)

> > 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.

Yeah. That's bad !


> but with your config above (my guesses would be):
> 
> 	/var/logs -> /var/log/linuxcoe-sd
> 	/var/profiles -> /var/lib/linuxcoe-sd/profiles

So true:
[root@localhost images]# ls -al /var/logs
lrwxrwxrwx  1 root root 20 Aug 28 11:41 /var/logs -> /var/log/linuxcoe-sd
[root@localhost images]# ls -al /var/profiles
lrwxrwxrwx  1 root root 29 Aug 28 11:41 /var/profiles -> /var/lib/linuxcoe-sd/profiles

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

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

Bruno

> > > But still no log file :-(
> > > [root@localhost images]# find / -name sysdes.log
> >
> > Hmm.
> 
> Yeah. That's bad !

Ultimately the issue was that SELinux was enabled (and in enforcing
mode), so the user running the webserver didn't have the rights to
create/write the log file.

Guess it's time to get serious about making a valid config,

bryang

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

Hello,

Back to building packages for LinuxCOE, phase II (sorry for the delay).

Bruno Cornec said on Fri, Oct 26, 2007 at 04:30:59PM +0200:
> What I can propose is a tool in pb which would:
> 
> Take a pb ChangeLog file (under pbconf/pkg) and process it to create a
> ChangeLog file in the tar file, the %changelog section in the spec and
> the changelog file for deb. THat's pretty easy. Keep the objective of a
> single source and respect the target of good changelogs everywhere where
> it's needed.
> 

Ok, that's now in the code. In fact I used 2 files, one for external
info changelog which contains what I need and is my current log format.
That allows to cretae the %changelog section and the NEWS file.

Also I use the tools cvs2cl and svn2cl to generate the ChangeLog files
from the CMS. + an pbauthors file which creates the AUTHORS file and is
used by the svn2cl tool.

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 ?
-- 
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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bryan G. <Bry...@HP...>]

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

Re: [Linuxcoe-devel] Update on packaging

[Bruno C. <Bru...@hp...>]

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