linuxcoe-devel

[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

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

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

[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

[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

[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

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

Bryan Gartner said on Wed, Oct 17, 2007 at 07:52:01PM -0600:

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

Same here:

[root@dploy ~]# rpm -ql linuxcoe-sd-base | grep 4.1
/var/cache/linuxcoe-sd/4.1
/var/lib/linuxcoe-sd/4.1
/var/lib/linuxcoe-sd/4.1/profiles
/var/log/linuxcoe-sd/4.1

So I guess this remains to be chosen and solved.
Maybe another variable would be useful for that, that we could use to
create subdirs under /etc, /var/lib, /var/log, ... and in the upstream
version you could still use linuxcoe-sd/4.1, when we could then use in pkg
only linuxcoe-sd (or whatever name we agree upon). Is that what you intended ?

> And I have a vm (distinct from the vm that I build these .debs on) that
> has all of these installed and working. 

Out of curiosity, what VM system are you using ?
Do you use LinuxCOE to deploy them ;-) ?

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

Ok. I'm also far behing in term of docs :-(

However, for non-OSS distro, there is probably a need to still provide
the content somewhere, internaly,as well as the tool to build it from
repository.

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

Well the design is probably more easy than the code here ;-)
The prefix to a "known" good repository should probably be a URL such as
file://... or http://... or ftp://... but the recursive aspect may then
be difficult to deal with remotely.

I think that 90%+ of the people, will just use an existing/or internal
mirror of the original structure.

So I guess that for, say centos, we will find :

[root@dploy ~]# ls /pub/centos/
2@    3.4@  3.8/  4.1/  4.5/    dostools/       RPM-GPG-KEY-beta RPM-GPG-KEY-CentOS-4@
3@    3.5@  3.9/  4.2/  5/      graphics/       RPM-GPG-KEY-CentOS-2@ RPM-GPG-KEY-CentOS-5
3.1@  3.6@  4@    4.3/  5.0/    HEADER.html     RPM-GPG-KEY-CentOS-3 TIME
3.3@  3.7@  4.0/  4.4/  build/  HEADER.images/  RPM-GPG-KEY-centos4 timestamp.txt

I don't think it makes a big contraint. So having the such a prefix allow
for the script to fetch with wget what is needed and create the local
structure needed for LinuxCOE. Is that what you were proposing ?

(In that case, locally it could be file:///pub/centos and remotely
ftp://deploy/pub/centos)

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

Ok, I made a first copy today of the deb files and have made a rough
adaptation. Not even tested. I'd really like to finish first the rpm
one, as I think making deb after that is just a piece of cake, as you
have the conf ifles, and I'll then have the logic for pb.

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

Good :-)

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, Nov 15, 2007 at 10:40:16PM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bruno Cornec said on Thu, Nov 15, 2007 at 12:45:04AM +0100:
> 
> > While trying to adapt my LinuxCOE pbconf tree to that, I encountered
> > another issue, I think I mentioned earlier, but which is now hurting
> > because it prevents me from creating the packages in the VM:
> >
> > configure: error: can not automatically integrate with Apache HTTP
> > server
> >
> > My VMs try to keep the minimum needed to just allow the build of a
> > software, not its installation. So I still think that those checks
> > (which are useful) should be rather done at install time, rather than at
> > build time.
> >
> > Bruno.
> > Any Idea ?
> 
> Answering to yself ;-)
> 
> What about adding  anoption to configure (for packager, which means me
> atm) allowing for bypassing those checks ? That would of course not be
> on by default.
> 
> Would that work for you ?

Those kinds of checks are already there, IIRC (./configure --help)

  --without-APACHE        skip auto-integratation with Apache webserver
  --without-SUDOERS       skip auto-integration with sudo

I was thinking along same lines, but hadn't had a chance to try those
(since I had originally set them up).

bryang

Re: [Linuxcoe-devel] Update on packaging

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

Bruno,

> > What about adding  anoption to configure (for packager, which means me
> > atm) allowing for bypassing those checks ? That would of course not be
> > on by default.
> > 
> > Would that work for you ?
> 
> Those kinds of checks are already there, IIRC (./configure --help)
> 
>   --without-APACHE        skip auto-integratation with Apache webserver
>   --without-SUDOERS       skip auto-integration with sudo
> 
> I was thinking along same lines, but hadn't had a chance to try those
> (since I had originally set them up).

Unfortunately this appears to now be broken, but I will try to fix that
later this evening.

bryang

Re: [Linuxcoe-devel] Update on packaging

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

Bruno,

> > Ok, I did the perl modules, and also mkisofs and sendmail which may not
> > be in a VM either. (The rest is really part of core distros).
> 
> Excellent, thanks!  And I am hoping you have added all of these
> as RPM dependencies, since you have now effectively disabled the
> checks.  We may also need to revisit this issue with the post-install
> script, to repopulate some values on the target install system.

I have updated configure and post-install scripts to do the "right"
think, AFAICT.  Basically the former now gives one the options to
skip anything I check for, and the latter can try to find the
commands on the target install system.

HTH,

bryang

P.S. FWIW, I cannot replicate your circular links re: log
files/directories.

Re: [Linuxcoe-devel] Update on packaging

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

Hello,

I think I found why my packages didn't work correctly during my recent
LinuxCOE Lab. It seems that now the scratch_monkey dir isn't created
when we use --without-APACHE, which isn't correct for the package now.

2 solutions, either I add a mkdir in my .spec, or we adapt again the
post-action.in to create the directories anyway. Let me know which one you
prefer ?

And merry Christmas for everybody here,
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

Re: [Linuxcoe-devel] Update on packaging

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

Hello,

Thanks to Bryan helps, I was able today to have my first 2 working RPMs
for Mandriva 2008.0 (the distro used on my deployment server) for
linuxcoe-sd-base and linuxcoe-sd-docs. And the docs are accessible
through the Web interface so I guess it's working fine as far as I can
see.

Bruno Cornec said on Thu, Oct 18, 2007 at 01:20:59PM +0200:

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

So I had a look at cento just now. Would you allow me to move the images
part currently under the SystemDesigner-CentOS subdir to
SystemDesigner-CentOS-images ?

The reason for me is that I do an export from the repository (cvs
export) to get the content and I still then get the images as part as
the process, which slow down things for testings :-(

Or give a better advice,
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

Re: [Linuxcoe-devel] Update on packaging

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

Bryan Gartner said on Thu, Nov 15, 2007 at 03:46:55PM -0700:

> > What about adding  anoption to configure (for packager, which means me
> > atm) allowing for bypassing those checks ? That would of course not be
> > on by default.
> > 
> > Would that work for you ?
> 
> Those kinds of checks are already there, IIRC (./configure --help)
> 
>   --without-APACHE        skip auto-integratation with Apache webserver
>   --without-SUDOERS       skip auto-integration with sudo

Well that's different if I read them correctly.
I want the integration. What I don't want is the check that apache
exists.

With the integration activated it will make a symlink to LInuxCOE.conf
httpd file correctly, anf thus when I install the package on a machine
with an apache server (which is a requirement of my package) it just
works. sudo is indeed less a problem as it's nearly mandatory in distro
nowadays.

If I remove the integration, I'll have to add it myself and won't be
abelt to use the post-action script. Which is of course another
possibility.

Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Linuxcoe-devel] Update on packaging

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

Bryan Gartner said on Tue, Nov 20, 2007 at 12:51:54PM -0700:

> > > Ok, I did the perl modules, and also mkisofs and sendmail which may not
> > > be in a VM either. (The rest is really part of core distros).
> > 
> > Excellent, thanks!  And I am hoping you have added all of these
> > as RPM dependencies, since you have now effectively disabled the
> > checks.  We may also need to revisit this issue with the post-install
> > script, to repopulate some values on the target install system.
> 
> I have updated configure and post-install scripts to do the "right"
> think, AFAICT.  Basically the former now gives one the options to
> skip anything I check for, and the latter can try to find the
> commands on the target install system.

Ok, restarting the VM build process. should take all the night here.

> P.S. FWIW, I cannot replicate your circular links re: log
> files/directories.

Well for me just installing my base rpm shows it. I need to look at it
closer, but it's minor ATM.

Thanks a lot for your 'SKIP' fixes ;-)
Bruno.
-- 
Linux Profession Lead EMEA  / Open Source Evangelist \        HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \  http://hpintelco.net
Des infos sur Linux?  http://www.HyPer-Linux.org      http://www.hp.com/linux
La musique ancienne?  http://www.musique-ancienne.org http://www.medieval.org

Re: [Linuxcoe-devel] Update on packaging

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

Hello,

Bruno Cornec said on Fri, Dec 21, 2007 at 12:28:16PM +0100:

> I think I found why my packages didn't work correctly during my recent
> LinuxCOE Lab. It seems that now the scratch_monkey dir isn't created
> when we use --without-APACHE, which isn't correct for the package now.

Thanks to Bryan and Lee hard work, I now have much more clean rpm. 
However, I have a last (for the moment) remaining issue:

# rpm -Uvh --force
# /home/bruno/LinuxCOE/build/RPMS/noarch/linuxcoe-sd-base-4.1-1.mdv2007.0.noarch.rpm
Préparation...              ########################################### [100%]
   1:linuxcoe-sd-base       ########################################### [100%]
LinuxCOE SystemDesigner integration tasks
  creating link : /var/www/linuxcoe-sd/linuxcoe.rc
Apache-specific integration tasks
  creating link : /etc/httpd/conf.d/LinuxCOE-SystemDesigner.conf
NOTE : Apache web server should now be restarted
NOTE : for this modified configuration to take effect.
/var/www/linuxcoe-sd/bin/post-actions: line 300: SKIP: command not found
SKIP restart
sudo-specific integration tasks
Reloading httpd: [  OK  ]

So looking at the post-action script generated I found:

      # restart apache, for either install/uninstall cases
        test -n "$VERBOSE" && {
          echo "NOTE : Apache web server should now be restarted"
          echo "NOTE : for this modified configuration to take effect."
        }
        if test "x${APACHE2CTL}" = "xNA" -o "x${APACHE2CTL}" = "xNONE"; then
          if type apache2ctl >/dev/null 2>&1; then
            apache2ctl restart
          fi
        else
          ${APACHE2CTL} restart 
        fi
        if test "x${APACHECTL}" = "xNA" -o "x${APACHECTL}" = "xNONE"; then
          if type apachectl >/dev/null 2>&1; then
            apachectl restart
          fi
        else
          echo ${APACHECTL} restart 
        fi

So I think there is a mismatch between the echo for ${APACHECTL} and
lack of echo for ${APACHE2CTL} which seems to cause the error message.
However, I don't know why we would want to echo SKIP restart ;-)

So close ... !!
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, Jan 31, 2008 at 07:29:39AM +0100:

>         if test "x${APACHE2CTL}" = "xNA" -o "x${APACHE2CTL}" = "xNONE"; then

I think a test on SKIP is missing here as well. Am I right on the money
?

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

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

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

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

[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

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

Bruno,

> Thanks to Bryan helps, I was able today to have my first 2 working RPMs
> for Mandriva 2008.0 (the distro used on my deployment server) for
> linuxcoe-sd-base and linuxcoe-sd-docs. And the docs are accessible
> through the Web interface so I guess it's working fine as far as I can
> see.

Actually you did all the *really* hard work.

> So I had a look at cento just now. Would you allow me to move the images
> part currently under the SystemDesigner-CentOS subdir to
> SystemDesigner-CentOS-images ?
> 
> The reason for me is that I do an export from the repository (cvs
> export) to get the content and I still then get the images as part as
> the process, which slow down things for testings :-(

I was in the process of doing just that the other day when I
did an errant import and got a duplication of an entire existing
module.  And with the way that CVS works (eg. the attic), and the
policies of sf.net, I had to place a support call to get the cruft removed
from that new module.  I just got confirmation today that it had
been completed.  So I have removed the images from -CentOS as of now.
Once others chime in on the following question, I'll proceed with
the rest.

To be honest, I am starting to debate whether we want to have those
images checked in at all.  I can see making them available for
download, but do we really need to have them under version control
on our sf.net project? 

bryang

Re: [Linuxcoe-devel] Update on packaging

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

FWIW,

> I was in the process of doing just that the other day when I
> did an errant import and got a duplication of an entire existing
> module.  And with the way that CVS works (eg. the attic), and the
> policies of sf.net, I had to place a support call to get the cruft removed
> from that new module.  I just got confirmation today that it had
> been completed.  So I have removed the images from -CentOS as of now.
> Once others chime in on the following question, I'll proceed with
> the rest.

And this has now been completed for:

	CentOS
	Debian
	Fedora
	OpenSUSE
	Scientific
	Ubuntu

I will do some further cleanup of the these modules later.  And I
will attack the others soon.

Remember, these images are still available at:

	http://www.instalinux.com/snapshots/images

bryang

Re: [Linuxcoe-devel] Update on packaging

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

Bryan Gartner said on Fri, Oct 19, 2007 at 07:03:49AM -0600:

> I was in the process of doing just that the other day when I
> did an errant import and got a duplication of an entire existing
> module.  And with the way that CVS works (eg. the attic), and the
> policies of sf.net, I had to place a support call to get the cruft removed
> from that new module.  I just got confirmation today that it had
> been completed.  So I have removed the images from -CentOS as of now.
> Once others chime in on the following question, I'll proceed with
> the rest.

Ahh, the fun of dealing with sf.net :-(
Guess why I preferred to host myself my repository for my projects here
?
More over at that time they were not even proposing SVN, and (sorry to
be crude) I find CVS so featureless, sometimes over complicated :-(

> To be honest, I am starting to debate whether we want to have those
> images checked in at all.  I can see making them available for
> download, but do we really need to have them under version control
> on our sf.net project? 

In theory as they are the result of a production process they should not
be versioned. However, we do not have that process in place yet don't we
? So I think we still need to provide them in one way or another. Again
sf.net doesn't help for ftp availability :-( 

What I could do is ask here for an MSA to add to my mondorescue server
and host what is needed here. 

Probably not the reliability of sf.net BTW, so should be mirrored
elsewhere (Lee i'll come back to you on this topic in your other mail ...
later sorry !)

I vote for a ftp access of those 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