linuxcoe-devel — LinuxCOE development discussion

Re: [Linuxcoe-devel] Update on packaging

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

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:

# 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 ;-)
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)

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.

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

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.

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

Louis,

On Wed, Oct 17, 2007 at 07:06:08AM +0000, Bouchard, Louis wrote:
> Hi guys,
> 
> I don't know why we're going through another iteration of the naming
> convention used.  We should discuss it at today's core meeting but my
> (rough) feeling is that LinuxCOE needs something else than just another
> naming convention.

Sorry for my proposal/diversion, I have recrafted the following modules to
use the previous namespace:

	linuxcoe-sd-base
	linuxcoe-sd-docs
	linuxcoe-sd-data-centos
	    (and note that this module no longer delivers images)

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

bryang

Re: [Linuxcoe-devel] Update on packaging

[Louis B. <lou...@hp...>]

Hi guys,

I don't know why we're going through another iteration of the naming
convention used.  We should discuss it at today's core meeting but my
(rough) feeling is that LinuxCOE needs something else than just another
naming convention.

-sd- is not much more (or less) cryptic than sysdes so it won't change
much at the end. But it do means that it will ask for (yet another)
rework of the .spec files, something for which I have absolutely no time
for.

I'm not against discussion, but sometimes the buck needs to stop
somewhere. I thought we had this discussion before. It's been close to a
year and we still don't have RPM/DEB packages yet.

So here is how I will do it : I'm taking friday off to nail down a set
of RPM, named as they are today in the CVS. Hopefully we'll be able to
have the ./images directory out of the way in order to have the overlays
RPM a bit lighter.

Then we'll need to get the RPM out in the public so they can be tested.

Sorry if I'm sounding a bit rude, but with the (very) limited resources
that I have it is the only thing I can offer.

Regards,

..Louis

Le mardi 16 octobre 2007 =C3=A0 23:55 +0000, Cornec, Bruno (Linux Consultan=
t)
a =C3=A9crit :
> Bryan Gartner said on Tue, Oct 16, 2007 at 01:02:47PM -0600:
>=20
> > > linuxcoe-sd-base and linuxcoe-sd-docs (I now use this one) or
> > > linuxcoe-sysdes and linuxcoe-sysdes-docs
> >
> > I can go either way with this, except "sd" is rather short and non-desc=
ript,
> > so I'd like to propose
> >
> >       linuxcoe-sysdes-common
> >               (vs. -base, as that is more common, at least in .deb spac=
e)
>=20
> *I* think that common is used when the brick is used by other potential
> upper layer (e.g. vim-common with vim-extended & vim-X11) whereas base
> is used when the component is the basis of the rest of the stack.
>=20
> So IMVHO in that case base is fine.
> But it's just for the pleasure to discuss with you, I'll let the long
> time writer decide, and adopt it.
> What I'd need is a parid concensus ;-)
>=20
> >       linuxcoe-sysdes-docs
>=20
> I take it ;-)
>=20
> (Too bad CVS doesn't support mv)
>=20
> > Another proposal is to modify the distro overlays as:
> >
> >       linuxcoe-sysdes-vend-<Distro>
> >               (instead of the "data*all" approach)
>=20
> Is vend more clear for native english speakers ?
> (For non native english speaker such as myself, I find data quite
> explicit). But again, let you choose.
>=20
> > > I'll then derived as we need the same choice vor /var/log and /var/li=
b
> > > (What I won't do the make another subdir below with the verion name a=
s
> > > fr packages this is useless because you can't have multiple instances=
)
> >
> > Actually you can easily have multiple instances (and this is quite
> > useful right now since we are making the 4-4.1 transistion).  We do
>=20
> Well this may on a test platform. But on a platform managed by packages,
> when you upgrade, what you eally want is that the new application takes
> place of the old one.
>=20
> When I do urpmi postfix / apt-get install postfix, I just want the new
> version. Then it's up to the packagers to be clever enough to keep the
> configuration files safe, or ven to aply filter to them if format has
> changed.
>=20
> The only case, where it would be acceptable IMO, is when you want
> multiple major versions in parallel (apache1 and apache2) However, this
> is generally for a short period of time, in particular when they all
> listen on the same port :-(
>=20
>=20
> Also I want to look for log files under /var/log/linuxcoe-sysdes, not
> under /var/log/linuxcoe-sysdes/4.1, and then realize it's the new
> version so should look at 4.2, ...
> More confusing than useful for me.
>=20
> And also a system like rpm won't let you have 2 packages with the same
> name and 2 versions different coexist on the system ;-) Rightly IMO .
>=20
> > it all the time as we move into production.  And this is almost trivial
> > with the next change that was implemented:
>=20
> I understand that for tar files, potentially but for packages I find it
> less useful.
>=20
> 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/l=
inux
> La musique ancienne?  http://www.musique-ancienne.org http://www.medieval=
.org
>=20
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
--=20
Louis Bouchard, Linux Support Engineer
EMEA Linux Competency Center,
Linux Ambassador, HP

HP Services                       1 Ave du Canada
HP France                         Z.A. de Courtaboeuf
lou...@hp...             91 947 Les Ulis
http://www.hp.com/go/linux        France
http://www.hp.com/fr

Re: [Linuxcoe-devel] Update on packaging

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

Bryan Gartner said on Tue, Oct 16, 2007 at 01:02:47PM -0600:

> > linuxcoe-sd-base and linuxcoe-sd-docs (I now use this one) or
> > linuxcoe-sysdes and linuxcoe-sysdes-docs
> 
> I can go either way with this, except "sd" is rather short and non-descript,
> so I'd like to propose
> 
> 	linuxcoe-sysdes-common
> 		(vs. -base, as that is more common, at least in .deb space)

*I* think that common is used when the brick is used by other potential
upper layer (e.g. vim-common with vim-extended & vim-X11) whereas base
is used when the component is the basis of the rest of the stack. 

So IMVHO in that case base is fine.
But it's just for the pleasure to discuss with you, I'll let the long
time writer decide, and adopt it. 
What I'd need is a parid concensus ;-)

> 	linuxcoe-sysdes-docs

I take it ;-)

(Too bad CVS doesn't support mv)

> Another proposal is to modify the distro overlays as:
> 
> 	linuxcoe-sysdes-vend-<Distro>
> 		(instead of the "data*all" approach)

Is vend more clear for native english speakers ?
(For non native english speaker such as myself, I find data quite
explicit). But again, let you choose.

> > I'll then derived as we need the same choice vor /var/log and /var/lib
> > (What I won't do the make another subdir below with the verion name as
> > fr packages this is useless because you can't have multiple instances)
> 
> Actually you can easily have multiple instances (and this is quite
> useful right now since we are making the 4-4.1 transistion).  We do

Well this may on a test platform. But on a platform managed by packages,
when you upgrade, what you eally want is that the new application takes
place of the old one. 

When I do urpmi postfix / apt-get install postfix, I just want the new
version. Then it's up to the packagers to be clever enough to keep the
configuration files safe, or ven to aply filter to them if format has
changed.

The only case, where it would be acceptable IMO, is when you want
multiple major versions in parallel (apache1 and apache2) However, this
is generally for a short period of time, in particular when they all
listen on the same port :-(


Also I want to look for log files under /var/log/linuxcoe-sysdes, not
under /var/log/linuxcoe-sysdes/4.1, and then realize it's the new
version so should look at 4.2, ...
More confusing than useful for me.

And also a system like rpm won't let you have 2 packages with the same
name and 2 versions different coexist on the system ;-) Rightly IMO .

> it all the time as we move into production.  And this is almost trivial
> with the next change that was implemented:

I understand that for tar files, potentially but for packages I find it
less useful.

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 Tue, Oct 16, 2007 at 12:49:47PM -0600:

> > ./packaging/SystemDesigner/debian/prerm: /usr/share/linuxcoe-sysdes/4.1/bin/post-actions -u
> 
> At one point, all of this was being handled by auto* processing, but
> in order to make it easier for a real Debian maintainer, this was
> pulled out of the module space and into a distinct location.  So,
> yes, back to hardcoded values (at least until PB shows me that light).

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.

And I try to avoid hard coded values (except when I do mistakes as in
the previous mail ;-)

> I will probably need a quick tutorial in order to implement this.

I guess you won't be alone ;-) I want to first have a working
environment, and then will re-work the documentation on trac.
>From that, the tutorial should be quicker (and you'll be able to update
trac to fill missing parts ;-)

> FWIW, what is currently in CVS, does in fact build usable .deb
> for the "-common" + "-docs" modules.

FWIW, what is currently in CVS,under pb builds not completely usable
rpms, due to the problems we are addressing in these mails ;-)
But we're not far from it, just that some details remain annoying for
really working packages.

> > Now the problem for all of you will be that you'll have to use pb to
> > generate the tar ball file that you need to work with. Is that an
> > acceptable constraint, or too much ?
> 
> I'd like to get a bit more creative, in that if PBVER is defined
> the auto*/build/tar "process" uses it, and if not, falls back to the existing
> convention if we can.

Ah ! Well, generally it's the reverse I do. PBVER is a macro substituted
by pb before calling the build process, when preparing the tar file.

Extremely short tutoral:

pb -p linuxcoe cms2build does:

- export content from CVS (cvs export)
- get the log from CVS
- create all build files instantiated from pbconf, applying filtering by
  default on them, and also on every file specified as having to be filtered
  (This is where PBVER disappear and is replaced by 4.1)
- executes a script if requested to (e.g. autogen.sh)
- create a tar.gz file from the result.

pb -p linuxcoe build2pkg does:

- get the underlying distribution
- extract the tar file
- setup the build files for that distro from the tar file.
- call the build process of the underlying distro

Now, if we can find a way to satisfy your needs, I'd be more than happy.
Let think about it.

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 Tue, Oct 16, 2007 at 12:44:32PM -0600:

Hello Bryan,

thanks for all your answers :-)

> > perl -pi -e 's/^apache.*//' /etc/sudoers
> 
> Other than being a bit too general (and assuming you meant ^${httpd_user}),
> I think it's fine to walk the entries we put in and remove them.  I'll
> see if I can something like that implemented today.

Yep. Of course, I was too quick here.
In fact I use now:

perl -pi -e 's/^PBHTTPDUSER.*//' /etc/sudoers

(PBHTTPDUSER is filtered by pb depending on the distro).

> > Also, it appears there is an issue with CVS. When I do a commit, and
> > ask for a cvs up on another machine, it doesn't come up immediately.
> > I have to wait a couple of minutes for it to be available. I'm used to SVN
> > rather which is immediate. Is it a known limitation ?
> 
> Yes, since SF.net mirrors CVS from developer space to anonymous access.

Humm annoying. I'll check if it's the same when I change to
authenticated user on both sides. Thanks for the hint.

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 Tue, Oct 16, 2007 at 12:18:51PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bruno Cornec said on Mon, Oct 15, 2007 at 05:56:43PM +0200:
> 
> > >From a quick look at the sources of today, I remarked that:
> >
> > ./docs/configure.ac:AC_INIT([linuxcoe-sysdes-docs],[4.1],[bry...@hp...])
> > ./SystemDesigner/configure.ac:AC_INIT([linuxcoe-sysdes],[4.1],[bry...@hp...])
> 
> 
> Looking back at the thread with Louis this morning, I'm looking where
> the truth is (if we can find any ;-)
> 
> Should we use for packages:
> 
> linuxcoe-sd-base and linuxcoe-sd-docs (I now use this one) or
> linuxcoe-sysdes and linuxcoe-sysdes-docs

I can go either way with this, except "sd" is rather short and non-descript,
so I'd like to propose

	linuxcoe-sysdes-common
		(vs. -base, as that is more common, at least in .deb space)
	linuxcoe-sysdes-docs

Another proposal is to modify the distro overlays as:

	linuxcoe-sysdes-vend-<Distro>
		(instead of the "data*all" approach)

> Then once this is answered, then what subdirectory name should we use:
> /etc/systemdesigner or
> /etc/linuxcoe-sysdes or
> /etc/linuxcoe-sd-base or
> /etc/linuxcoe-sd or
> /etc/linuxcoe or
> (insert your favorite here ;-)

As you can already control that via packaging (and if you install from
tarballs you get the package, or your specified, standard), I'd say 
lets get the above naming standard done, and by default use those locations.

> I'll then derived as we need the same choice vor /var/log and /var/lib
> (What I won't do the make another subdir below with the verion name as
> fr packages this is useless because you can't have multiple instances)

Actually you can easily have multiple instances (and this is quite
useful right now since we are making the 4-4.1 transistion).  We do
it all the time as we move into production.  And this is almost trivial
with the next change that was implemented:

	FWIW, I have also introduced a new "webalias" variable in
	config.site that allows you to control the presentation part
	of the URL irregardless of packaging naming.  By default,
	you'll get "SystemDesigner" as the base of the URL.

bryang

Re: [Linuxcoe-devel] Update on packaging

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

Bruno,

On Mon, Oct 15, 2007 at 03:56:43PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bryan Gartner said on Tue, Oct 09, 2007 at 09:41:40AM -0600:
> 
> > > Another problem I have is with the versioning of the LinuxCOE project.
> > > Where are those version number handled ? Is there a subverion ? When a
> > > new package is released, will it be 4.1 ? 4.0.1 ? What granularity do
> > > you want ?
> >
> > The autoconf/automake currently handles the versioning, but my plan all
> > along has been to use CVS tags (since we don't use subversion) to denote
> > versioning.  Seems like now might be the right time to begin that
> > implementation as well,
> 
> 
> >From a quick look at the sources of today, I remarked that:

True enough, for all that below.

>[snip] ...

> ./packaging/SystemDesigner/debian/prerm: /usr/share/linuxcoe-sysdes/4.1/bin/post-actions -u

>[snip] ...

At one point, all of this was being handled by auto* processing, but
in order to make it easier for a real Debian maintainer, this was
pulled out of the module space and into a distinct location.  So,
yes, back to hardcoded values (at least until PB shows me that light).

> What I'd like to propose is to use (later on, when ready ;-) the
> Project-Builder macro PBVER to replace all those hardcoded values with
> it. That way all packages generated will just use the declaration in
> pbconf/linuxcoe.pb to get the project version and filter all the files
> accordingly.

I will probably need a quick tutorial in order to implement this.
FWIW, what is currently in CVS, does in fact build usable .deb
for the "-common" + "-docs" modules.

> Now the problem for all of you will be that you'll have to use pb to
> generate the tar ball file that you need to work with. Is that an
> acceptable constraint, or too much ?

I'd like to get a bit more creative, in that if PBVER is defined
the auto*/build/tar "process" uses it, and if not, falls back to the existing
convention if we can.

bryang

Re: [Linuxcoe-devel] Update on packaging

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

Bruno,

On Mon, Oct 15, 2007 at 05:16:52PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Hello again,
> 
> Other remarks:
> 
> 1/ When attempting to remove my package (for tests) it says:
> 
> sudo-specific removal tasks
>   should un-augment /etc/sudoers, but not implemented yet ...
>   please look for ^apache /etc/sudoers entries to remove ... sorry
> 
> Why would prevent using the following:
> 
> perl -pi -e 's/^apache.*//' /etc/sudoers

Other than being a bit too general (and assuming you meant ^${httpd_user}),
I think it's fine to walk the entries we put in and remove them.  I'll
see if I can something like that implemented today.

> I put it in the spec file, and it seems to work fine.
> (except it doesn't remove the comments ;-)
> 
> 
> 2/ I have a misunderstanding on naming convention:
> 
> I thought we agreed on packages named systemdesigner and
> systemdesigner-docs (for the 2 first I'm dealing with now).

Nope, we had revisited the scheme some months ago (which is
why the 4.1 changes this).

> However in the code it seems to be linuxcoe-sysdes and
> linuxcoe-sysdes-docs.

This was "closer" but still doesn't match the "standard" we
had talked about.  I'll reply to the follow-on message with
some proposed changes.

> Did I forget something ? Coudl someone indicate which one is the right
> one please.
> 
> Also for additional Distro support what about
> [systemdesigner|linuxcoe-sysdes]-[addon|plgin]-distroname
> 
> e.g.: linuxcoe-sysdes-plugin-fedora or linuxcoe-sysdes-addon-fedora.

See follow-up.

> WDYT ?
> 
> 
> Also, it appears there is an issue with CVS. When I do a commit, and
> ask for a cvs up on another machine, it doesn't come up immediately.
> I have to wait a couple of minutes for it to be available. I'm used to SVN
> rather which is immediate. Is it a known limitation ?

Yes, since SF.net mirrors CVS from developer space to anonymous access.

bryang

Re: [Linuxcoe-devel] Update on packaging

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

Bruno Cornec said on Mon, Oct 15, 2007 at 05:56:43PM +0200:

> >From a quick look at the sources of today, I remarked that:
> 
> ./docs/configure.ac:AC_INIT([linuxcoe-sysdes-docs],[4.1],[bry...@hp...])
> ./SystemDesigner/configure.ac:AC_INIT([linuxcoe-sysdes],[4.1],[bry...@hp...])


Looking back at the thread with Louis this morning, I'm looking where
the truth is (if we can find any ;-)

Should we use for packages:

linuxcoe-sd-base and linuxcoe-sd-docs (I now use this one) or
linuxcoe-sysdes and linuxcoe-sysdes-docs

Then once this is answered, then what subdirectory name should we use:
/etc/systemdesigner or
/etc/linuxcoe-sysdes or
/etc/linuxcoe-sd-base or
/etc/linuxcoe-sd or
/etc/linuxcoe or
(insert your favorite here ;-)

I'll then derived as we need the same choice vor /var/log and /var/lib
(What I won't do the make another subdir below with the verion name as
fr packages this is useless because you can't have multiple instances)

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

Louis Bouchard said on Tue, Oct 16, 2007 at 08:54:21AM +0200:

> > Why would prevent using the following:
> >=20
> > perl -pi -e 's/^apache.*//' /etc/sudoers
> >=20
> > I put it in the spec file, and it seems to work fine.
> > (except it doesn't remove the comments ;-)
> >=20
>=20
> I would not put it in the .spec file for two reasons :
>=20
>   1) It goes against the best practices of loading the .spec file with
> scripts.

Humm. Any reference ?
(I personaly know a lot of spec files that uses scripts, even inlined in
the %pre/%post sections)

I agree with you that it should be done upstream, but in the meanwhile,
it's better to do it in the spec, than to let a file overloaded
especially the sudoers one (security concerns)

>   2) It puts distribution specifics in the .spec file which means that
> the .spec file needs to be very distribution specific.

Eh, no :-)
That perl line is extremely generic, and works for all distro (even non
rpms one).

> > However in the code it seems to be linuxcoe-sysdes and
> > linuxcoe-sysdes-docs.
> > Did I forget something ? Coudl someone indicate which one is the right
> > one please.
>=20
> I think that you're working on outdated .spec files ! Here is the naming
> convention as I noted it from the minutes of the core meeting :
>=20
> oe-sd-content-dist-ver      version/targetdist/release
> _________________________________________________________________________=
__________
> linuxcoe-sd-base            -   4.0.rhel4-1    (only installs on rhel)
> linuxcoe-sd-base            -   4.0.sles10-1   (only installs on sles)
> linuxcoe-sd-data-rhel-all   -   4.0-1          (add rhel functionality to=
 any dist)
> linuxcoe-sd-data-sles-10    -   4.0-1          (add sles functionality to=
 any dist)
> linuxcoe-sd-data-fc  -4     -   4.0-1          (add sles functionality to=
 any dist)

Ah thanks I hadn't that with me :-(
BTW, all those spec file are similar (I checked them before starting) so
it's not a big issue in fact, just that I had'nt the right name.

However my first point is still valid:

linuxcoe-sd-base !=3D linuxcoe-sysdes as in the source tree. So there is
still a mismatch on names between what we want for packages and what we
have in the upstream code.

> Any 'systemdesigner-{something}' .spec file should no longer be used and
> should actually be removed from the CVS tree, but I'm not sure if I can
> to that.

Yes you can !
cvs remove is your friend ;-)

What is missing in CVS is cvs mv :-(
>=20
> > Also for additional Distro support what about
> > [systemdesigner|linuxcoe-sysdes]-[addon|plgin]-distroname
> >=20
> > e.g.: linuxcoe-sysdes-plugin-fedora or linuxcoe-sysdes-addon-fedora.
> >=20
> > WDYT ?
> >=20
>=20
> Not sure if it is required, since distribution specific identification
> is already provided in the main package name.

If we already agreed on -data- it's ok for me. Will just use that.

Thanks for the feedback Louis,
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

[Louis B. <lou...@hp...>]

Hi,

Le lundi 15 octobre 2007 =C3=A0 17:16 +0000, Cornec, Bruno (Linux Consultan=
t)
a =C3=A9crit :
> Hello again,
>=20
> Other remarks:
>=20
> 1/ When attempting to remove my package (for tests) it says:
>=20
> sudo-specific removal tasks
>   should un-augment /etc/sudoers, but not implemented yet ...
>   please look for ^apache /etc/sudoers entries to remove ... sorry
>=20
> Why would prevent using the following:
>=20
> perl -pi -e 's/^apache.*//' /etc/sudoers
>=20
> I put it in the spec file, and it seems to work fine.
> (except it doesn't remove the comments ;-)
>=20

I would not put it in the .spec file for two reasons :

  1) It goes against the best practices of loading the .spec file with
scripts.
  2) It puts distribution specifics in the .spec file which means that
the .spec file needs to be very distribution specific.

>=20
> 2/ I have a misunderstanding on naming convention:
>=20
> I thought we agreed on packages named systemdesigner and
> systemdesigner-docs (for the 2 first I'm dealing with now).
>=20
> However in the code it seems to be linuxcoe-sysdes and
> linuxcoe-sysdes-docs.
> Did I forget something ? Coudl someone indicate which one is the right
> one please.
>=20

I think that you're working on outdated .spec files ! Here is the naming
convention as I noted it from the minutes of the core meeting :

oe-sd-content-dist-ver      version/targetdist/release
___________________________________________________________________________=
________
linuxcoe-sd-base            -   4.0.rhel4-1    (only installs on rhel)
linuxcoe-sd-base            -   4.0.sles10-1   (only installs on sles)
linuxcoe-sd-data-rhel-all   -   4.0-1          (add rhel functionality to a=
ny dist)
linuxcoe-sd-data-sles-10    -   4.0-1          (add sles functionality to a=
ny dist)
linuxcoe-sd-data-fc  -4     -   4.0-1          (add sles functionality to a=
ny dist)

Any 'systemdesigner-{something}' .spec file should no longer be used and
should actually be removed from the CVS tree, but I'm not sure if I can
to that.

> Also for additional Distro support what about
> [systemdesigner|linuxcoe-sysdes]-[addon|plgin]-distroname
>=20
> e.g.: linuxcoe-sysdes-plugin-fedora or linuxcoe-sysdes-addon-fedora.
>=20
> WDYT ?
>=20

Not sure if it is required, since distribution specific identification
is already provided in the main package name.

MTCW,

...Louis
--=20
Louis Bouchard, Linux Support Engineer
EMEA Linux Competency Center,
Linux Ambassador, HP

HP Services                       1 Ave du Canada
HP France                         Z.A. de Courtaboeuf
lou...@hp...             91 947 Les Ulis
http://www.hp.com/go/linux        France
http://www.hp.com/fr

Re: [Linuxcoe-devel] Update on packaging

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

Hello again,

Other remarks:

1/ When attempting to remove my package (for tests) it says:

sudo-specific removal tasks
  should un-augment /etc/sudoers, but not implemented yet ...
  please look for ^apache /etc/sudoers entries to remove ... sorry

Why would prevent using the following:

perl -pi -e 's/^apache.*//' /etc/sudoers 

I put it in the spec file, and it seems to work fine.
(except it doesn't remove the comments ;-)


2/ I have a misunderstanding on naming convention:

I thought we agreed on packages named systemdesigner and
systemdesigner-docs (for the 2 first I'm dealing with now).

However in the code it seems to be linuxcoe-sysdes and
linuxcoe-sysdes-docs. 
Did I forget something ? Coudl someone indicate which one is the right
one please.

Also for additional Distro support what about
[systemdesigner|linuxcoe-sysdes]-[addon|plgin]-distroname

e.g.: linuxcoe-sysdes-plugin-fedora or linuxcoe-sysdes-addon-fedora.

WDYT ?


Also, it appears there is an issue with CVS. When I do a commit, and
ask for a cvs up on another machine, it doesn't come up immediately.
I have to wait a couple of minutes for it to be available. I'm used to SVN
rather which is immediate. Is it a known limitation ?

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 Tue, Oct 09, 2007 at 09:41:40AM -0600:

> > Another problem I have is with the versioning of the LinuxCOE project.
> > Where are those version number handled ? Is there a subverion ? When a
> > new package is released, will it be 4.1 ? 4.0.1 ? What granularity do
> > you want ?
> 
> The autoconf/automake currently handles the versioning, but my plan all
> along has been to use CVS tags (since we don't use subversion) to denote
> versioning.  Seems like now might be the right time to begin that
> implementation as well,


>From a quick look at the sources of today, I remarked that:

./docs/configure.ac:AC_INIT([linuxcoe-sysdes-docs],[4.1],[bry...@hp...])
./SystemDesigner/configure.ac:AC_INIT([linuxcoe-sysdes],[4.1],[bry...@hp...])
./packaging/SystemDesigner/debian/prerm: /usr/share/linuxcoe-sysdes/4.1/bin/post-actions -u
./packaging/SystemDesigner/debian/postinst: /usr/share/linuxcoe-sysdes/4.1/bin/post-actions -i
./packaging/SystemDesigner/debian/rules: --prefix=/usr/share/linuxcoe-sysdes/4.1 \
./packaging/SystemDesigner/debian/rules: --sysconfdir=/etc/linuxcoe-sysdes/4.1 \
./packaging/SystemDesigner/debian/conffile: /etc/linuxcoe-sysdes/4.1/linuxcoe.rc
./packaging/SystemDesigner/debian/conffile: /etc/linuxcoe-sysdes/4.1/includes/config.state
./packaging/SystemDesigner/debian/conffile: /etc/linuxcoe-sysdes/4.1/includes/LinuxCOE-SystemDesigner.conf
./packaging/SystemDesigner/debian/conffile: /etc/linuxcoe-sysdes/4.1/includes/sudoers
./packaging/SystemDesigner/debian/dirs:/usr/share/linuxcoe-sysdes/4.1
./packaging/SystemDesigner/debian/dirs:/etc/linuxcoe-sysdes/4.1
./packaging/SystemDesigner/debian/dirs:/usr/share/linuxcoe-sysdes/4.1/var
./packaging/SystemDesigner/debian/dirs:/var/cache/linuxcoe-sysdes/4.1
./packaging/SystemDesigner/debian/dirs:/var/lib/linuxcoe-sysdes/4.1
./packaging/SystemDesigner/debian/dirs:/var/lib/linuxcoe-sysdes/4.1/profiles
./packaging/SystemDesigner/debian/dirs:/var/log/linuxcoe-sysdes/4.1


What I'd like to propose is to use (later on, when ready ;-) the
Project-Builder macro PBVER to replace all those hardcoded values with
it. That way all packages generated will just use the declaration in
pbconf/linuxcoe.pb to get the project version and filter all the files
accordingly.

Now the problem for all of you will be that you'll have to use pb to
generate the tar ball file that you need to work with. Is that an
acceptable constraint, or too much ? 

Looking for feedbacks ;-)

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

[Linuxcoe-devel] Ohloh reference

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

For your information I just referenced LinuxCOE in Ohloh.
http://www.ohloh.net/projects/9128

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 Tue, Oct 09, 2007 at 09:41:40AM -0600:

> Bruno,

Hello Bryan !

> On Tue, Oct 09, 2007 at 08:10:53AM +0000, Cornec, Bruno (Linux Consultant) wrote:
> > This is called ProjectBuilder (aka pb). Cf:
> > http://trac.project-builder.org
> > 
[...]
> 
> This is all great work Bruno  !!

Well, it will be when it'll reach v1.0.0 ;-)
(I passed 0.8.0 yesterday to improve Debian support).

> We totally agree and have been meaning to move those out of the
> package space for awhile now.

Good. Now you have a customer pushing ;-)

> 	SystemDesigner/bin/make-images

Found it !

[...]
# I'm planning to port this to PERL
# once it's roughly working
[...]

May I contribute here ? Not that my perl is at the level of yours or
Lee's, but I have a bit of time to work on it till end of year, so want
to benefit of the opportunity to advance as much as I can.

> although I don't think it's functional yet.  There is already
> a README under images that talks about how to create them.

Ok, will try to work on it taking Mandriva as a pretext to learn more on
that process, and bring a new function.

> At thist point, I can certainly remove the "images" from the
> package/install perspective (and leave them only in the "make dist"
> tarball view), so that you can proceed.  

Well the rpm build also call make integrate, so I'm not sure it will be
sufficient. Anyway I already take it ;-)

> Then step two, I will move
> them out of CVS, and use up some more of our graciously provided
> "instalinux" disk quota to directly host them for download.  Step

We will compete for the quota ;-) But anyway you have priority over my
VMs.

> 3 can then provide a script to generate them.  This stepwise approach
> will allow you to continue working on this very visible portion of
> the project, yes allow us to smoothly transition out of "vending"
> distro images :)

I can begin to help on this I think.

My problem is that I need to develop a Stack for end December using
LinuxCOE+MOndo (aka dploy.org), and I want to povide a clean way to
install everything on the server. So RPMs are mandatory for me.

So Step 3 is the most interesting ;-)

> > WDYT ?
> 
> Above steps seem reasonable?

Yeah, as long as 1 is done tomorrow and 2 friday, I could have a working
setup early next week ;-)

Seriously I follow what you say. I think I can not help that much for
1&2 as my knowledge is not yet sufficient. However helping Louis for 3
seems more reasonable.

> The autoconf/automake currently handles the versioning, but my plan all
> along has been to use CVS tags (since we don't use subversion) to denote
> versioning.  Seems like now might be the right time to begin that
> implementation as well,

Great. My questions was of course on tool support, but also from a
project perspective. What is the roadmap in term of versions, what is
the version numbering schema adopted (4.0 vs 4 alone vs 4.x.y ...)

And then which are the files impacted in the project by such a choice ?

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

Chris Slater said on Tue, Oct 09, 2007 at 06:27:49AM -0700:

> I've got room to host those files on my Instalinux web hosting.  I
> think my quota is around 250GB, and I'm using around 35GB...

THat would be handy ;-)
I still need to work on them before being able to provide them, but
that's a good proposal Chris, Thanks a lot :-)

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

Louis Bouchard said on Tue, Oct 09, 2007 at 10:29:48AM +0200:

> > Once it's done, I'll be able to share all those VMs (as long as you have
> > the necessary place to host them, as they represent around 50 GB right
> > now) so that everybody will be able to use the same mecanism to build
> > it's own project.
>=20
> This is very good news to me ! This is indeed one of the issues in
> developing the .spec files : coherent RPM production & testing.

Well the other advantage I see (I'm a former Software Engineering
Consultant ;-) is that I can maintain easily a core .spec/rules file and
just derive what needs to be changed for the various distro. But it
allows me to keep common all what is common (and it represent most of
the code in those build files).

> > Have someone already worked on a script that would allow to generate
> > from a distro the files needed by LinuxCOE, without embedding them in a
> > package ? (after all it's generated so shouldn't be part of neither the
> > package, nor the CVS IMHO) ?
>=20
> Not to me & Brian either ! This is why we decided to remove the images
> out of the RPM/DEBS. A separate tarball containing only the content of
> the ./images directory will be made available separately, as well as a
> script that will generate the images from a waystation.

Humm good stuff. So it means IIUC that the packages will provide a tool
that allow us to generate the Image Environement on the waystation as it
has the required files, or from the tar file on another machine.
But I won't require those files on the build system, then is that right
?

> I don't now if BG has had time to make the necessary modifications to
> the configure/make files required to avoid building the images. Once
> it's done, I have the spec files ready to build the Overlay packages
> _WITHOUT_ the binaries.

Great. Would you mind posting them here, so that I can integrate them in
the pbconf dir under CVS and be ready to use them asa the rest is in
place ?

> Hope it helps,

Yes !!

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 Tue, Oct 09, 2007 at 08:10:53AM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Hello,
> 
> This is called ProjectBuilder (aka pb). Cf:
> http://trac.project-builder.org
> 
> The tool is written in perl, and provides the following functions:
> 
>         cms2build: Create tar files for the project under your CMS
>                    CMS supported are SVN and CVS
> 
>         build2pkg: Create packages for your running distribution
> 
>         cms2pkg:   cms2build + build2pkg
> 
>         build2ssh: Send the tar files to a SSH host
> 
>         pkg2ssh:   Send the packages built to a SSH host
> 
>         build2vm:  Create packages in VMs, launching them if needed
>                    and send those packages to a SSH host once built
>                    VM type supported are QEMU
> 
>         cms2vm:    cms2build + build2vm
> 
>         launchvm:  Launch one virtual machine
> 
>         script2vm: Launch one virtual machine if needed
>                    and executes a script on it
> 
> 
> They are mostly all working for both mondo (SVN) and LinuxCOE (CVS).
> I've produced last week my first packages for Mandriva (my native
> distro) and I'm in the process of upgrading all my VMs (QEMU based) in
> order to be able to produce my next MondoRescue version (2.2.5) using
> that system (60% done). Once it's done, I'll also be able to generate
> packages for LinuxCOE for the same set of distro. All RPMs based distro
> are now working (fedora, rhel, mandriva, sles, suse), and I'm converting the
> .deb based VMs. Gentoo, Slackware will follow.

This is all great work Bruno  !!

> Now specifically for LinuxCOE, I've worked on systemdesigner and
> systemdesigner-docs packages up to now. But in order to have a useful
> system, I'd need a package supporting one distribution.
> But (there is always a but ;-), packaging a set of binary files is
> really not appealing to me.

We totally agree and have been meaning to move those out of the
package space for awhile now.

> Have someone already worked on a script that would allow to generate
> from a distro the files needed by LinuxCOE, without embedding them in a
> package ? (after all it's generated so shouldn't be part of neither the
> package, nor the CVS IMHO) ?

Several of us have talked about a script, and Louis even started one,
IIRC:

	SystemDesigner/bin/make-images

although I don't think it's functional yet.  There is already
a README under images that talks about how to create them.

> At the point I'm now, I'd need to work on that soon, so any already
> existing tool would help, if not I'll begin to look at that for Mandriva
> (which will also help adding support for that distro ;-) keeping in mind
> the genericity needed for other distro as well.

At thist point, I can certainly remove the "images" from the
package/install perspective (and leave them only in the "make dist"
tarball view), so that you can proceed.  Then step two, I will move
them out of CVS, and use up some more of our graciously provided
"instalinux" disk quota to directly host them for download.  Step
3 can then provide a script to generate them.  This stepwise approach
will allow you to continue working on this very visible portion of
the project, yes allow us to smoothly transition out of "vending"
distro images :)

> WDYT ?

Above steps seem reasonable?

> Another problem I have is with the versioning of the LinuxCOE project.
> Where are those version number handled ? Is there a subverion ? When a
> new package is released, will it be 4.1 ? 4.0.1 ? What granularity do
> you want ?

The autoconf/automake currently handles the versioning, but my plan all
along has been to use CVS tags (since we don't use subversion) to denote
versioning.  Seems like now might be the right time to begin that
implementation as well,

bryang

Re: [Linuxcoe-devel] Update on packaging

[Chris S. <chr...@gm...>]

I've got room to host those files on my Instalinux web hosting.  I
think my quota is around 250GB, and I'm using around 35GB...

Chris

On 10/9/07, Louis Bouchard <lou...@hp...> wrote:
> Hi Bruno,
>
> Le mardi 09 octobre 2007 =E0 08:10 +0000, Cornec, Bruno (Linux Consultant=
)
> a =E9crit :
> > Hello,
> >
> > In order to help spread the adoption of LinuxCOE, I proposed to reuse
> > the setp of scripts/tools I developped for the MondoRescue project.
> >
> > Looking at them, they were clearly too tightly integrated with mondo to
> > make an easy reuse, so I decided to re-start from scratch and write a
> > 3rd version of my packaging tools, this time unrelated to a specific pr=
oject.
> >
> > This is called ProjectBuilder (aka pb). Cf:
> > http://trac.project-builder.org
> >
> > The tool is written in perl, and provides the following functions:
> >
> >         cms2build: Create tar files for the project under your CMS
> >                    CMS supported are SVN and CVS
> >
> >         build2pkg: Create packages for your running distribution
> >
> >         cms2pkg:   cms2build + build2pkg
> >
> >         build2ssh: Send the tar files to a SSH host
> >
> >         pkg2ssh:   Send the packages built to a SSH host
> >
> >         build2vm:  Create packages in VMs, launching them if needed
> >                    and send those packages to a SSH host once built
> >                    VM type supported are QEMU
> >
> >         cms2vm:    cms2build + build2vm
> >
> >         launchvm:  Launch one virtual machine
> >
> >         script2vm: Launch one virtual machine if needed
> >                    and executes a script on it
> >
> >
> > They are mostly all working for both mondo (SVN) and LinuxCOE (CVS).
> > I've produced last week my first packages for Mandriva (my native
> > distro) and I'm in the process of upgrading all my VMs (QEMU based) in
> > order to be able to produce my next MondoRescue version (2.2.5) using
> > that system (60% done). Once it's done, I'll also be able to generate
> > packages for LinuxCOE for the same set of distro. All RPMs based distro
> > are now working (fedora, rhel, mandriva, sles, suse), and I'm convertin=
g the
> > .deb based VMs. Gentoo, Slackware will follow.
> >
> > Once it's done, I'll be able to share all those VMs (as long as you hav=
e
> > the necessary place to host them, as they represent around 50 GB right
> > now) so that everybody will be able to use the same mecanism to build
> > it's own project.
> >
>
> This is very good news to me ! This is indeed one of the issues in
> developing the .spec files : coherent RPM production & testing.
>
> > Now specifically for LinuxCOE, I've worked on systemdesigner and
> > systemdesigner-docs packages up to now. But in order to have a useful
> > system, I'd need a package supporting one distribution.
> > But (there is always a but ;-), packaging a set of binary files is
> > really not appealing to me.
> >
> > Have someone already worked on a script that would allow to generate
> > from a distro the files needed by LinuxCOE, without embedding them in a
> > package ? (after all it's generated so shouldn't be part of neither the
> > package, nor the CVS IMHO) ?
> >
>
> Not to me & Brian either ! This is why we decided to remove the images
> out of the RPM/DEBS. A separate tarball containing only the content of
> the ./images directory will be made available separately, as well as a
> script that will generate the images from a waystation.
>
> I don't now if BG has had time to make the necessary modifications to
> the configure/make files required to avoid building the images. Once
> it's done, I have the spec files ready to build the Overlay packages
> _WITHOUT_ the binaries.
>
> Hope it helps,
>
> ...Louis
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
>
>
>

Re: [Linuxcoe-devel] Update on packaging

[Louis B. <lou...@hp...>]

Hi Bruno,

Le mardi 09 octobre 2007 =C3=A0 08:10 +0000, Cornec, Bruno (Linux Consultan=
t)
a =C3=A9crit :
> Hello,
>=20
> In order to help spread the adoption of LinuxCOE, I proposed to reuse
> the setp of scripts/tools I developped for the MondoRescue project.
>=20
> Looking at them, they were clearly too tightly integrated with mondo to
> make an easy reuse, so I decided to re-start from scratch and write a
> 3rd version of my packaging tools, this time unrelated to a specific proj=
ect.
>=20
> This is called ProjectBuilder (aka pb). Cf:
> http://trac.project-builder.org
>=20
> The tool is written in perl, and provides the following functions:
>=20
>         cms2build: Create tar files for the project under your CMS
>                    CMS supported are SVN and CVS
>=20
>         build2pkg: Create packages for your running distribution
>=20
>         cms2pkg:   cms2build + build2pkg
>=20
>         build2ssh: Send the tar files to a SSH host
>=20
>         pkg2ssh:   Send the packages built to a SSH host
>=20
>         build2vm:  Create packages in VMs, launching them if needed
>                    and send those packages to a SSH host once built
>                    VM type supported are QEMU
>=20
>         cms2vm:    cms2build + build2vm
>=20
>         launchvm:  Launch one virtual machine
>=20
>         script2vm: Launch one virtual machine if needed
>                    and executes a script on it
>=20
>=20
> They are mostly all working for both mondo (SVN) and LinuxCOE (CVS).
> I've produced last week my first packages for Mandriva (my native
> distro) and I'm in the process of upgrading all my VMs (QEMU based) in
> order to be able to produce my next MondoRescue version (2.2.5) using
> that system (60% done). Once it's done, I'll also be able to generate
> packages for LinuxCOE for the same set of distro. All RPMs based distro
> are now working (fedora, rhel, mandriva, sles, suse), and I'm converting =
the
> .deb based VMs. Gentoo, Slackware will follow.
>=20
> Once it's done, I'll be able to share all those VMs (as long as you have
> the necessary place to host them, as they represent around 50 GB right
> now) so that everybody will be able to use the same mecanism to build
> it's own project.
>=20

This is very good news to me ! This is indeed one of the issues in
developing the .spec files : coherent RPM production & testing.

> Now specifically for LinuxCOE, I've worked on systemdesigner and
> systemdesigner-docs packages up to now. But in order to have a useful
> system, I'd need a package supporting one distribution.
> But (there is always a but ;-), packaging a set of binary files is
> really not appealing to me.
>=20
> Have someone already worked on a script that would allow to generate
> from a distro the files needed by LinuxCOE, without embedding them in a
> package ? (after all it's generated so shouldn't be part of neither the
> package, nor the CVS IMHO) ?
>=20

Not to me & Brian either ! This is why we decided to remove the images
out of the RPM/DEBS. A separate tarball containing only the content of
the ./images directory will be made available separately, as well as a
script that will generate the images from a waystation.

I don't now if BG has had time to make the necessary modifications to
the configure/make files required to avoid building the images. Once
it's done, I have the spec files ready to build the Overlay packages
_WITHOUT_ the binaries.

Hope it helps,

...Louis

[Linuxcoe-devel] Update on packaging

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

Hello,

In order to help spread the adoption of LinuxCOE, I proposed to reuse
the setp of scripts/tools I developped for the MondoRescue project.

Looking at them, they were clearly too tightly integrated with mondo to
make an easy reuse, so I decided to re-start from scratch and write a
3rd version of my packaging tools, this time unrelated to a specific project.

This is called ProjectBuilder (aka pb). Cf:
http://trac.project-builder.org

The tool is written in perl, and provides the following functions:

        cms2build: Create tar files for the project under your CMS
                   CMS supported are SVN and CVS

        build2pkg: Create packages for your running distribution

        cms2pkg:   cms2build + build2pkg

        build2ssh: Send the tar files to a SSH host

        pkg2ssh:   Send the packages built to a SSH host

        build2vm:  Create packages in VMs, launching them if needed
                   and send those packages to a SSH host once built
                   VM type supported are QEMU

        cms2vm:    cms2build + build2vm

        launchvm:  Launch one virtual machine

        script2vm: Launch one virtual machine if needed
                   and executes a script on it


They are mostly all working for both mondo (SVN) and LinuxCOE (CVS).
I've produced last week my first packages for Mandriva (my native
distro) and I'm in the process of upgrading all my VMs (QEMU based) in
order to be able to produce my next MondoRescue version (2.2.5) using
that system (60% done). Once it's done, I'll also be able to generate 
packages for LinuxCOE for the same set of distro. All RPMs based distro 
are now working (fedora, rhel, mandriva, sles, suse), and I'm converting the
.deb based VMs. Gentoo, Slackware will follow.

Once it's done, I'll be able to share all those VMs (as long as you have
the necessary place to host them, as they represent around 50 GB right
now) so that everybody will be able to use the same mecanism to build
it's own project.

Now specifically for LinuxCOE, I've worked on systemdesigner and
systemdesigner-docs packages up to now. But in order to have a useful
system, I'd need a package supporting one distribution.
But (there is always a but ;-), packaging a set of binary files is
really not appealing to me.

Have someone already worked on a script that would allow to generate
from a distro the files needed by LinuxCOE, without embedding them in a
package ? (after all it's generated so shouldn't be part of neither the
package, nor the CVS IMHO) ?

At the point I'm now, I'd need to work on that soon, so any already
existing tool would help, if not I'll begin to look at that for Mandriva
(which will also help adding support for that distro ;-) keeping in mind
the genericity needed for other distro as well.

WDYT ?

Another problem I have is with the versioning of the LinuxCOE project.
Where are those version number handled ? Is there a subverion ? When a
new package is released, will it be 4.1 ? 4.0.1 ? What granularity do
you want ?

Thanks in advance for your feedback,
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

[Linuxcoe-devel] Some warnings from rpmlint

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

Hello,

In my work to help packaging LinuxCOE, I'm using rpmlint as a tool to
check the accuracy of my built packages. Some errors are still mine to
dfix, but for some other I'd like your feedback:

E: systemdesigner non-executable-script /etc/systemdesigner/includes/config.state 0644
E: systemdesigner zero-length /var/www/systemdesigner/base/PRE
E: systemdesigner zero-length /var/www/systemdesigner/base/POST-APT
E: systemdesigner script-without-shellbang /var/www/systemdesigner/includes/errors
E: systemdesigner non-executable-script /var/www/systemdesigner/data/suse_retro_skel 0644
E: systemdesigner non-executable-script /var/www/systemdesigner/data/retro_skel 0644
E: systemdesigner zero-length /var/www/systemdesigner/base/MID
E: systemdesigner non-executable-script /var/www/systemdesigner/data/deb_retro_skel 0644
E: systemdesigner script-without-shellbang /var/www/systemdesigner/includes/sysdes_paths.pm
E: systemdesigner zero-length /var/www/systemdesigner/base/POST-YUM
E: systemdesigner script-without-shellbang /var/www/systemdesigner/includes/binaries.pm
E: systemdesigner non-executable-script /var/www/systemdesigner/data/suse_final_skel 0644
E: systemdesigner zero-length /var/www/systemdesigner/base/POST


Would it be possible to add comments to zero-length files, in order to
suppress the error message ?
Would it be possible to add the relative #! at the begining of
script-without-shellbang files ?

Let me know what you think.

I'll soon begin to test those packages on my deployment server so may
report back other questions.

TIA,
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

[Linuxcoe-devel] What makes an OS easy to deploy?

[Christopher P. <cph...@gm...>]

Hello,

I am working on installing and maintaining the LinuxCOE system on my server
and I would like to develop a system that I am working on to port to COE. as
such I would like to know:

   - What makes an OS easy to deploy
   - What makes an OS easy to maintain
   - What makes an OS easy to port to COE

Guess that is a good start.  Oh and any tips or suggestions would be
pleasantly accepted.

Thanks

-- 
Christopher Phelps
cph...@gm...

Re: [Linuxcoe-devel] Thaughts on LinuxCOE

[ed f. <edf...@ya...>]

Hi Louis, core-team,

I read this twice, Louis.  These are fantastic
observations, and things we often overlook while we're
burried in day-to-day details.  As far as the
open-source project is concerned, I agree it's doing
very well, and has all the qualities you'd expect
(respect/cooperation/collaboration).  The HP side is
more interesting as we've left IT, we're in Services,
and have gone though some significant reorgs.  We've
survived reorgs in the past, but getting management to
one, understand opensource, and two, actually support
it, are hard things to do.  Even if management fails
to understand and support us, they still see the news
in the press about LinuxCOE, and how Ann Livermore
mentions us in her keynotes.  So perhaps they don't
need to understand it, but rather know that other
"important" people do.  This is why we have the
"LinuxCOE shameless self promotion department."  I
know it seems silly to spend time on this
non-engineering-soft-skill stuff, but I do think it
adds value/support/funding to the project within HP.


thanks for your thoughts!!  I owe you a beer or two!

-craig



--- "Bouchard, Louis" <Lou...@hp...> wrote:

> Hi everyone,
> 
> This is highly philosophical content.  So if you
> don't feel like wasting
> your time reading through this, I won't be offended.
> 
> In early February I came about the LinuxCOE project,
> following a brief
> encounter with BryanG & LeeM at the OSLO Tech Tour
> 2007.  I'm starting
> to have a rough idea on how things are working,
> evolving, being
> constructed in the LinuxCOE project.
> 
> I don't intend to give lessons, to teach anything to
> anyone. I just want
> to share my newcomer's perspective on a successful
> project which has
> everything that needs to become even bigger. I
> originally thought of
> posting this on my blog, but this list is better
> since opening a
> discussion is what I'm hoping for.
> 
> Driving to work this morning, I was listening to
> Brian Behlendorf's
> TuxTalk
>
(http://opensource.professions.hp.com/tuxtalks/200706/).
> He was
> talking about open source teams, how they worked,
> what made them
> successful, etc. I found in his description many of
> the things I found
> when joining the LinuxCOE group :
> 
> - Collaboration
> - Cooperation
> - Respect
> - friendship team spirit
> 
> All of that I had already sensed when I met with B&L
> in Fort Collins.
> The rest from our weeklies & IRC encounters
> confirmed my beliefs.
> 
> All of these are the strong foundations on which
> LinuxCOE is being
> built.  This is good since LinuxCOE is, in my view,
> the first real
> example of Open Source in Action within HP. It's
> also a very good
> example of "eat your own dog food" for HP.  So I
> guess that this strong
> foundation can affort to question itself on a few
> questions that keeps
> poping up in my mind.
> 
> Can LinuxCOE exist outside of HP ?
> 
> Of course it can. We have the sf.net environment,
> website, public IRC,
> mailing list, etc. Though I sometime think that it
> is still mostly an
> internal HP effort. I might be wrong, but it still 
> is not much of an
> issue, really.
> 
> Can LinuxCOE exist without HP ?
> 
> It would be tough.  My guess is that a lot of what's
> required to keep
> LinuxCOE alive relies on HP hardware. This is fine
> since the project is
> heavily used internally. But if this was to change
> for a reason,
> LinuxCOE might be faced with the need to find its
> own house.
> 
> Can LinuxCOE integrate participants from the outside
> world ?
> 
> Sure it can. But a lot of LinuxCOE's life is within
> HP (i.e. the
> internal #linuxcoe).  This is not a problem right
> now, but it might
> become one when more outside world participants will
> join the team. This
> is why I'm now auto-joining the public #linuxcoe.
> 
> Where is LinuxCOE common knowledge ?
> 
> In many people's head I'm afraid. A lot of
> functional information lies
> in the Admin docs, and a few other files. A lot of
> stuff is in the
> CVS/SVN repo. But discussions, architectural
> details, stuff like that
> might be somewhere I don't know of. You might know
> where I'm heading :
> do we need a wiki or something similar to that ? For
> example, where do I
> document the thinks I'm setting up in order to build
> the packages
> (rpmlint, lsb-rpmchk, custom scripts, process) ,
> 
> Does LinuxCOE needs a name change ?
> 
> I don't think so, Tony. At least, it is not
> something that will change a
> lot in how things are doing now.  But I do think
> that LinuxCOE fits in
> something bigger : dploy.org.
> 
> The main problem with dploy.org is that it will not
> have a life as easy
> as LinuxCOE does withing HP. It might collide with
> products marketed by
> HP, namely RDP & Control Tower.  So my guess is that
> if rdeploy is to
> succeed, it will need to be a separate project that
> make use of
> LinuxCOE. It will also have to go through the OSRB
> as a separate
> project.
> 
> I hope that these few questions can trigger a
> discussion or at least be
> useful in sharing a newcomer's view of the LinuxCOE
> project.
> 
> Regards,
> 
> 
> Caribou
> 
> -- 
> Louis Bouchard, Linux Support Engineer
> EMEA Linux Competency Center,
> Linux Ambassador, HP
> 
> HP Services                       1 Ave du Canada
> HP France                         Z.A. de
> Courtaboeuf
> lou...@hp...             91 947 Les Ulis
> http://www.hp.com/go/linux        France
> http://www.hp.com/fr
> >
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/>
_______________________________________________
> Linuxcoe-devel mailing list
> Lin...@li...
>
https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel
> 




      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7