Menu
▾
▴
linuxcoe-devel — LinuxCOE development discussion
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(17) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
(7) |
Mar
(11) |
Apr
(6) |
May
|
Jun
(14) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(47) |
Nov
(29) |
Dec
(1) |
| 2008 |
Jan
(9) |
Feb
(10) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
(4) |
Aug
(1) |
Sep
(10) |
Oct
(7) |
Nov
(23) |
Dec
(37) |
| 2009 |
Jan
(9) |
Feb
(22) |
Mar
(18) |
Apr
(31) |
May
(37) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bryan G. <Bry...@HP...> - 2007-03-09 16:24:21
|
Bruno, On Fri, Mar 09, 2007 at 04:13:32PM +0100, Bruno Cornec wrote: > > This is the idea behind packaging LinuxCOE both in .debs and .rpm The > > work is in progress and you should have at least a working set of RPM by > > wednesday night when I leave Grenoble :-) > > For sure :-) Even more we should have RPMs for all RPMs based distro for > which I already did the job in the past (OpenSuSE, Mandriva, RHEL, SLES, > Fedora). Debian, Gentoo and Slackware could even be looked at ;-) You can already generate .debs, by following these simple instructions: http://linuxcoe.cvs.sourceforge.net/linuxcoe/packaging/README.deb?revision=1.2&view=markup There are a few things I still need to do to better conform to Debian packaging policy, but this is a good first pass. bryang |
|
From: Bryan G. <Bry...@HP...> - 2007-03-09 16:22:59
|
Bruno, On Fri, Mar 09, 2007 at 04:11:25PM +0100, Bruno Cornec wrote: > Side question, do you have PDF versions of those 2 guides ? > Is the source in a XML|SGML format ? > If not do you want I make such a version ? FWIW, I have the tools to create this, but don't distribute this by default (since I know you can serve the html file, and can also view it, but can't be so sure of pdf, albeit that is very likely in this day/age). In the docs/guides subdir, you could do: make -f Makefile.transform make -f Makefile.transform html make -f Makefile.transform pdf Only caveat, is that you may have to change the XSLSTYLE parameter to match your system's location of that file. That said, if you think I should distribute the PDF version, I would be happy to include it, moving forward. > > In the past we've included 'virgin' boot images for the majority of the > > distributions we support. While this was convenient for users, it put > > us at odds with sourceforge's disk quotes. Chris Slater kindly hosts > > 'tarball' snapshots of System Designer at installinux: > > > > http://www.instalinux.com/LinuxCOE/snapshot/ > > We'll be removing these images and including instructions on how to > > create your own (and perhaps hosting tarballs of just the images > > remotely) to decrease our disk space usage on sf.net and allow true > > build releases on sf.net soon. > > If you want a mirror site, I may also host LinuxCOE content at > mondorescue.org, or more precisely at dploy.org ;-) That is a great offer as well. And regarding Lee's comments, I am thinking I will make a distinct make dist-images target, to gen such a bootimage only tarball (as a convenience). And, we will either have documentation or a script to help users obtain (and tweak) boot images directly from the desired distribution. > > Hope that helps, Bryan will elaborate further I'm sure! Sorry was home sick all day yesterday, but doing much better today. > At last next week yes ;-) Looking forward to it ! bryang |
|
From: Bryan G. <Bry...@HP...> - 2007-03-09 16:13:23
|
Bruno, On Fri, Mar 09, 2007 at 11:20:37AM +0100, Bruno Cornec wrote: > Hello, > > It seems that the systemdesigner part of LinuxCOE will be difficult to > package. Actually not, we already have sample debian packaging tools in place and Louis is walking the rpm set. > 1/ it seems that the planed directory organisation is under a single > main dir (I choose /usr/local/systemdesigner) where the LSB/FHS > integration would rather imply using /usr, /var/log, /etc, ... > We will have to pass a lot of parameters to configure in order to achieve > that, I guess. Everything (sans my laziness in /etc@prefix) shorcuts should make it relocatable. Further all the Makefiles have $(DESTIR)@prefix variables to make it even easier to package/relocate. > 2/ The Apache conf file is not installed by the make install proceudre > (under the service dir) and I think it's a bug. make integrate (and done during post install actions for both .deb and .rpm) > 3/ Is there a bugzilla somewhere we could use ? SF site has one. > 4/ There should also be an easy way to download files compared to CVS > (again for some tools helping to build packages it's easier). I just recently updated the tarball snapshots, and the admin guide has the instructions on how to go from CVS->tarball, and will soon have the package make/install instructions as well. bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-03-09 15:13:42
|
Louis Bouchard said on Fri, Mar 09, 2007 at 01:57:53PM +0100:
> The 'make integrate' is done by the RPM that I created. So you can
> basically do :
>
> # rpm -vih systemdesigner-4.rpm
> # service httpd restart
>
> and access your http://{webserver}/systemdesigner. Voilà !
Great. We will test that next week with you !
> This is the idea behind packaging LinuxCOE both in .debs and .rpm The
> work is in progress and you should have at least a working set of RPM by
> wednesday night when I leave Grenoble :-)
For sure :-) Even more we should have RPMs for all RPMs based distro for
which I already did the job in the past (OpenSuSE, Mandriva, RHEL, SLES,
Fedora). Debian, Gentoo and Slackware could even be looked at ;-)
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
|
|
From: Bruno C. <Bru...@hp...> - 2007-03-09 15:13:03
|
Hi Lee, Lee Mayes said on Fri, Mar 09, 2007 at 06:41:40AM -0500: > My comments in-line: As it has to be ;-) > When we originally decide on filesystem locations, we went with: > > /opt/package - Static package objects > /etc/opt/package - Host specific configuration (optional) > /var/opt/package - Volatile data - namely profiles and logs Which is in fact nearer from a lsb type of packaging, rather than an integrated distribution packaging (which uses rather directly /usr, /var, ...) No problem with it, just it makes the configure line of a package longer ;-) > Bryan and I (mostly Bryan :) parameterized all pathnames with @prefix@ > in the code, so it's relatively easy to relocate the package and all its > components to a different path. The /etc tree is completely optional, > but useful as it allows you to protect any changes between updates (it's > a mirror of what's in /opt/package and takes precedence for config/data > directives). I'm happy changing this if it makes sense. I think we will come back with Louis next week on that, after some concrete tests. We will let you know. > >2/ The Apache conf file is not installed by the make install proceudre > >(under the service dir) and I think it's a bug. > > > This is a function of 'make integrate', which will also update sudoers > if you require that functionality, which is mostly for older distros > where I need to loopmount initrd to make changes. It's separate from > 'make install' as it's something you only do once. Grumph, missed that one on the output of the make command sorry. BTW I do not have description of those steps in the Way Station HOWTO. I've now found them (at least partly) in the Admin guide on SF.net. Side question, do you have PDF versions of those 2 guides ? Is the source in a XML|SGML format ? If not do you want I make such a version ? > http://sourceforge.net/tracker/?group_id=144250&atid=758199 > We should all start using it. Ok. Will do as well. > In the past we've included 'virgin' boot images for the majority of the > distributions we support. While this was convenient for users, it put > us at odds with sourceforge's disk quotes. Chris Slater kindly hosts > 'tarball' snapshots of System Designer at installinux: > > http://www.instalinux.com/LinuxCOE/snapshot/ > > We'll be removing these images and including instructions on how to > create your own (and perhaps hosting tarballs of just the images > remotely) to decrease our disk space usage on sf.net and allow true > build releases on sf.net soon. If you want a mirror site, I may also host LinuxCOE content at mondorescue.org, or more precisely at dploy.org ;-) > Hope that helps, Bryan will elaborate further I'm sure! At last next week yes ;-) Best regards, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Louis B. <lou...@hp...> - 2007-03-09 12:59:47
|
Hi Lee, salut Bruno,
Le vendredi 09 mars 2007 =C3=A0 06:41 -0500, Lee Mayes a =C3=A9crit :
> Hi Bruno,
>=20
> My comments in-line:
>=20
Mine too :-)
> Bruno Cornec wrote:
> > Hello,
> >
> > It seems that the systemdesigner part of LinuxCOE will be difficult to
> > package.
Not that much. I have a first pass at systemdesigner,
systemdesigner-docs & systemdesigner-rhel done and almost working.
> >
> > 1/ it seems that the planed directory organisation is under a single
> > main dir (I choose /usr/local/systemdesigner) where the LSB/FHS
> > integration would rather imply using /usr, /var/log, /etc, ...
> > We will have to pass a lot of parameters to configure in order to achie=
ve
> > that, I guess.
> > =20
> When we originally decide on filesystem locations, we went with:
>=20
> /opt/package - Static package objects
> /etc/opt/package - Host specific configuration (optional)
> /var/opt/package - Volatile data - namely profiles and logs
>=20
> Bryan and I (mostly Bryan :) parameterized all pathnames with @prefix@=20
> in the code, so it's relatively easy to relocate the package and all its=20
> components to a different path. The /etc tree is completely optional,=20
> but useful as it allows you to protect any changes between updates (it's=20
> a mirror of what's in /opt/package and takes precedence for config/data=20
> directives). I'm happy changing this if it makes sense.
>=20
The directories that we use are set by variables in the .spec file using
the variables that Lee is talking about. So it can be easily changed.
> > 2/ The Apache conf file is not installed by the make install proceudre
> > (under the service dir) and I think it's a bug.
> >
> > =20
> This is a function of 'make integrate', which will also update sudoers=20
> if you require that functionality, which is mostly for older distros=20
> where I need to loopmount initrd to make changes. It's separate from=20
> 'make install' as it's something you only do once.
>=20
The 'make integrate' is done by the RPM that I created. So you can
basically do :
# rpm -vih systemdesigner-4.rpm
# service httpd restart
and access your http://{webserver}/systemdesigner. Voil=C3=A0 !
> > 3/ Is there a bugzilla somewhere we could use ?
> > =20
> There's the standard bug-tracker provided by sf.net:
>=20
> http://sourceforge.net/tracker/?group_id=3D144250&atid=3D758199
>=20
> We should all start using it.
> > 4/ There should also be an easy way to download files compared to CVS
> > (again for some tools helping to build packages it's easier).=20
> > =20
> In the past we've included 'virgin' boot images for the majority of the=20
> distributions we support. While this was convenient for users, it put=20
> us at odds with sourceforge's disk quotes. Chris Slater kindly hosts=20
> 'tarball' snapshots of System Designer at installinux:
>=20
> http://www.instalinux.com/LinuxCOE/snapshot/
>=20
This is the idea behind packaging LinuxCOE both in .debs and .rpm The
work is in progress and you should have at least a working set of RPM by
wednesday night when I leave Grenoble :-)
> We'll be removing these images and including instructions on how to=20
> create your own (and perhaps hosting tarballs of just the images=20
> remotely) to decrease our disk space usage on sf.net and allow true=20
> build releases on sf.net soon.
> > That's all for now, but I may come back with further questions :-)
> > Bruno.
> > =20
> Hope that helps, Bryan will elaborate further I'm sure!
>=20
> Best Regards,
>=20
> Lee
>=20
>=20
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share y=
our
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDEV
> _______________________________________________
> 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
|
|
From: Lee M. <lee...@hp...> - 2007-03-09 11:40:51
|
Hi Bruno, My comments in-line: Bruno Cornec wrote: > Hello, > > It seems that the systemdesigner part of LinuxCOE will be difficult to > package. > > 1/ it seems that the planed directory organisation is under a single > main dir (I choose /usr/local/systemdesigner) where the LSB/FHS > integration would rather imply using /usr, /var/log, /etc, ... > We will have to pass a lot of parameters to configure in order to achieve > that, I guess. > When we originally decide on filesystem locations, we went with: /opt/package - Static package objects /etc/opt/package - Host specific configuration (optional) /var/opt/package - Volatile data - namely profiles and logs Bryan and I (mostly Bryan :) parameterized all pathnames with @prefix@ in the code, so it's relatively easy to relocate the package and all its components to a different path. The /etc tree is completely optional, but useful as it allows you to protect any changes between updates (it's a mirror of what's in /opt/package and takes precedence for config/data directives). I'm happy changing this if it makes sense. > 2/ The Apache conf file is not installed by the make install proceudre > (under the service dir) and I think it's a bug. > > This is a function of 'make integrate', which will also update sudoers if you require that functionality, which is mostly for older distros where I need to loopmount initrd to make changes. It's separate from 'make install' as it's something you only do once. > 3/ Is there a bugzilla somewhere we could use ? > There's the standard bug-tracker provided by sf.net: http://sourceforge.net/tracker/?group_id=144250&atid=758199 We should all start using it. > 4/ There should also be an easy way to download files compared to CVS > (again for some tools helping to build packages it's easier). > In the past we've included 'virgin' boot images for the majority of the distributions we support. While this was convenient for users, it put us at odds with sourceforge's disk quotes. Chris Slater kindly hosts 'tarball' snapshots of System Designer at installinux: http://www.instalinux.com/LinuxCOE/snapshot/ We'll be removing these images and including instructions on how to create your own (and perhaps hosting tarballs of just the images remotely) to decrease our disk space usage on sf.net and allow true build releases on sf.net soon. > That's all for now, but I may come back with further questions :-) > Bruno. > Hope that helps, Bryan will elaborate further I'm sure! Best Regards, Lee |
|
From: Bruno C. <Bru...@hp...> - 2007-03-09 10:20:53
|
Hello, It seems that the systemdesigner part of LinuxCOE will be difficult to package. 1/ it seems that the planed directory organisation is under a single main dir (I choose /usr/local/systemdesigner) where the LSB/FHS integration would rather imply using /usr, /var/log, /etc, ... We will have to pass a lot of parameters to configure in order to achieve that, I guess. 2/ The Apache conf file is not installed by the make install proceudre (under the service dir) and I think it's a bug. 3/ Is there a bugzilla somewhere we could use ? 4/ There should also be an easy way to download files compared to CVS (again for some tools helping to build packages it's easier). That's all for now, but I may come back with further questions :-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-02-25 13:35:51
|
Lee, On Sat, Feb 24, 2007 at 08:18:57PM -0500, Lee Mayes wrote: > Had a ping on IRC: > > --> wezmurphy (i=wesleyNO@nat/hp/x-4a069ef9c52e8222) has joined #linuxcoe > <wezmurphy> This is HP right? > <cat-xeger> wezmurphy - it's linuxcoe, which is a project out of HP, > originally, yes > <wezmurphy> Thanks cat-xeger. The files for download are not available on > the sourceforge downloads page - do you know where I could get them (other > than CVS)? > <-- wezmurphy (i=wesleyNO@nat/hp/x-4a069ef9c52e8222) has left #linuxcoe > > Is there a way to point to the tarballs on instalinux from sf.net? > > http://www.instalinux.com/LinuxCOE/snapshot/ The project home page http://linuxcoe.sf.net has this link as one of the three methods to download. Unfortunately, the http://sourceforge.net/projects/linuxcoe/ download link can only show "released" files thru the sf download manager (which we have yet to do). BTW, this is the process by which we snapshot some files fit for distribution (and then the back-end SF mechanisms mirror them out to their servers). I am ready to do that whenever we as a group are ready to. bryang > _______________________________________________ > Linuxcoe-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel |
|
From: Lee M. <le...@ma...> - 2007-02-25 02:54:18
|
Had a ping on IRC: --> wezmurphy (i=3DwesleyNO@nat/hp/x-4a069ef9c52e8222) has joined #linuxc= oe <wezmurphy> This is HP right? <cat-xeger> wezmurphy - it's linuxcoe, which is a project out of HP, originally, yes <wezmurphy> Thanks cat-xeger. The files for download are not available o= n the sourceforge downloads page - do you know where I could get them (othe= r than CVS)? <-- wezmurphy (i=3DwesleyNO@nat/hp/x-4a069ef9c52e8222) has left #linuxcoe Is there a way to point to the tarballs on instalinux from sf.net? http://www.instalinux.com/LinuxCOE/snapshot/ Lee |
|
From: Bryan G. <Bry...@HP...> - 2007-02-23 15:53:25
|
FYI,
I just got my second usable .deb package created (for
systemdesigner-docs). So now that I can see how to
scale the packaging across the other modules, I thought
I would step back and ask for some feedback.
In the SystemDesigner CVS module, I actually checked
in the debian sub-tree (which is where the debian
packaging magic happens) mostly just as a way to keep
the work around. What I am proposing to do moving
forward is a bit different, so that the developers
and package maintainers can work in different spaces.
Basically this was the advice of a seasoned Debian
Maintainer, so that the package process can rev as needed
independently from the project itself. Couple that
with the intent to create .rpm packages next, and
I think you may see further justification.
So, I am ready to create a "packaging" CVS module
to house all of the packaging artifacts:
CVS/
packaging/
<module-name> (like docs, SystemDesigner)
debian/
...
<module-name>.spec
(perhaps even with various distro suffixes)
In this way, the packaging maintainers would have
ready reference to:
- tweak packaging artifacts distinct from the package
itself
- possibly even make targets within this space to
create an easy way to have the necessary inputs
for package maintainers (plus, of course, needing
the .tar.gz from the main package modules)
- CVS tags could then be used to synchronize what
packaging version is tied to what package release
(when we are ready to commit such "releases")
What do others think? Are there better approaches?
bryang
P.S. I took a quick SWAG at a SystemDesigner.spec
file yesterday as well. While it only
packaged a single file from that module,
the remainder seemed pretty straightforward
(sans postinst logic which would need to
be similar to the make integrate functionality).
So I could offer that as a seed in that
packaging space as well.
|
|
From: Bryan G. <Bry...@HP...> - 2007-02-18 15:37:46
|
FYI, On Sun, Feb 18, 2007 at 12:57:23PM +0100, Bruno Cornec wrote: > Mayes, Lee said on Sat, Feb 17, 2007 at 05:54:36PM -0500: > > > It's not possible with the current code, but you can override this by pointing the variable $deffile in lib/LinuxCOE.pm to any absolute path (that's the first place it looks, which is current /opt/SystemDesigner/4). It's kind of a chicken-egg problem, I'll think on it some. Needless to say, a roll of LinuxCOE.pm would point it back to default, but at least your file wouldn't get overwritten. Perhaps we should stop shipping linuxcoe.rc and rename it to linuxcoe.rc.example or something? Okay, per suggestions above and below, have fixed new admin guide, and made current installer preserve existing copy (yet still deliver a NEW-linuxcoe.rc) in the proper directory for manaul merging. > 1/ That's where packaging is also helping as it saves the old config > file > 2/ For mondo I have resolved to provide a fixed config file named > /etc/mindi/mindi.conf.dist (in case of pkg, /usr/local/etc otherwise) > and reads a potentially empty /etc/mindi/mindi.conf in addition which > can overrides the values by new ones. > > I even md5sum /etc/mindi/mindi.conf.dist to check it didn't changed sinc > install, so that I'm sure that I have the minimum set of functions > required. Sorry this is shell code, so not sharable like that for a perl > based project, but the idea should be reusable in itself. bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-02-18 11:59:05
|
Mayes, Lee said on Sat, Feb 17, 2007 at 05:54:36PM -0500: > It's not possible with the current code, but you can override this by pointing the variable $deffile in lib/LinuxCOE.pm to any absolute path (that's the first place it looks, which is current /opt/SystemDesigner/4). It's kind of a chicken-egg problem, I'll think on it some. Needless to say, a roll of LinuxCOE.pm would point it back to default, but at least your file wouldn't get overwritten. Perhaps we should stop shipping linuxcoe.rc and rename it to linuxcoe.rc.example or something? 1/ That's where packaging is also helping as it saves the old config file 2/ For mondo I have resolved to provide a fixed config file named /etc/mindi/mindi.conf.dist (in case of pkg, /usr/local/etc otherwise) and reads a potentially empty /etc/mindi/mindi.conf in addition which can overrides the values by new ones. I even md5sum /etc/mindi/mindi.conf.dist to check it didn't changed sinc install, so that I'm sure that I have the minimum set of functions required. Sorry this is shell code, so not sharable like that for a perl based project, but the idea should be reusable in itself. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Mayes, L. <lee...@hp...> - 2007-02-17 22:55:34
|
It's not possible with the current code, but you can override this by = pointing the variable $deffile in lib/LinuxCOE.pm to any absolute path = (that's the first place it looks, which is current = /opt/SystemDesigner/4). It's kind of a chicken-egg problem, I'll think = on it some. Needless to say, a roll of LinuxCOE.pm would point it back = to default, but at least your file wouldn't get overwritten. Perhaps we = should stop shipping linuxcoe.rc and rename it to linuxcoe.rc.example or = something? Lee -----Original Message----- From: lin...@li... on behalf of Gartner, = Bryan W Sent: Sat 2/17/2007 9:36 AM To: lin...@li... Subject: [Linuxcoe-devel] linuxcoe.rc file precedence =20 FYI, Haven't checked in a while, but is it possible to copy the /opt/.../linuxcoe.rc file to /etc/opt/.../linuxcoe.rc file and make all of one's localized changes to the /etc version (and have it take precedence, as in complete and not overlay)? If so, I would like to document this as standard practice for the upcoming admin guide and also to implement the copy (if the destination file) does not exist during installation. bryang -------------------------------------------------------------------------= Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share = your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV _______________________________________________ Linuxcoe-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel |
|
From: Bryan G. <Bry...@HP...> - 2007-02-17 14:38:47
|
FYI, Haven't checked in a while, but is it possible to copy the /opt/.../linuxcoe.rc file to /etc/opt/.../linuxcoe.rc file and make all of one's localized changes to the /etc version (and have it take precedence, as in complete and not overlay)? If so, I would like to document this as standard practice for the upcoming admin guide and also to implement the copy (if the destination file) does not exist during installation. bryang |
|
From: Lee M. <le...@ma...> - 2006-09-27 22:10:31
|
Will do Bruno, I must have been looking at old stuff here: http://members.shaw.ca/mandrake/ Thanks! Lee (guilty of poor googling ;) On Wed, 2006-09-27 at 23:53 +0200, Bruno Cornec wrote: > Hello Lee ! > > Lee Mayes said on Wed, Sep 27, 2006 at 01:32:27PM -0400: > > Today it doesn't appear Mandrake supports pulling the autoinst config > > file from anywhere but a network source or floppy disk. This makes it > > kind of unusable in our current way of creating images. > > Ok, I check the doc before asking (sorry for the habits :-) andfound > that this is probably not true. Cf: > http://qa.mandriva.com/twiki/pub/Main/AutoInstall/auto_inst.html#The_auto_instcfg_File_Location > > > The issue is being raised with the cooker developers. If there is an > > undocumented way to do it (or they add ks=file || cdrom options) I'll > > give it another go. > > I think you could indeed try that: > > append auto_install=path/to/test.cfg automatic=method:cdrom ramdisk_size=128000 > initrd=network.rdz root=/dev/ram3 acpi=ht vga=788 > > Let me know if you're able to use that with success. (or not :-) > > Bruno. |
|
From: Bruno C. <Bru...@hp...> - 2006-09-27 21:53:31
|
Hello Lee ! Lee Mayes said on Wed, Sep 27, 2006 at 01:32:27PM -0400: > Today it doesn't appear Mandrake supports pulling the autoinst config > file from anywhere but a network source or floppy disk. This makes it > kind of unusable in our current way of creating images. Ok, I check the doc before asking (sorry for the habits :-) andfound that this is probably not true. Cf: http://qa.mandriva.com/twiki/pub/Main/AutoInstall/auto_inst.html#The_auto_instcfg_File_Location > The issue is being raised with the cooker developers. If there is an > undocumented way to do it (or they add ks=file || cdrom options) I'll > give it another go. I think you could indeed try that: append auto_install=path/to/test.cfg automatic=method:cdrom ramdisk_size=128000 initrd=network.rdz root=/dev/ram3 acpi=ht vga=788 Let me know if you're able to use that with success. (or not :-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Lee M. <le...@ma...> - 2006-09-27 17:32:29
|
On Wed, 2006-09-27 at 11:01 -0600, Bryan Gartner wrote: > BTW, > > What is the status of Mandriva support for the SystemDesigner, > and what items remain for it's inclusion ? > > bryang Today it doesn't appear Mandrake supports pulling the autoinst config file from anywhere but a network source or floppy disk. This makes it kind of unusable in our current way of creating images. While I could vend *both* a small ~8M ISO and a floppy image, have the user burn/insert both, it's not real usable IMO. Heck, lots of systems these days don't even have a floppy drive. And since AOL went to CD's even I have a hard time finding a usable 3.5 floppy laying about. :) The issue is being raised with the cooker developers. If there is an undocumented way to do it (or they add ks=file || cdrom options) I'll give it another go. Best Regards, Lee |
|
From: Bryan G. <br...@po...> - 2006-09-27 17:01:46
|
BTW, What is the status of Mandriva support for the SystemDesigner, and what items remain for it's inclusion ? bryang |
|
From: Lee M. <lee...@gm...> - 2006-03-11 06:19:49
|
Hey All, These lists have been dead for a while, it's time to move more formal communication here vs. IRC I guess. So what I will do is post a message here anytime I check anything major into CVS. This is not major, but thought I'd start getting in the habit. Tonight's update was to enable FTP/HTTP proxy support at install time. I looked long and hard, but I just could not find a way to do this in kickstart. I don't think RH supports it. So for now, it's only avail on preseed and AutoYaST installed servers. So when enabled, you won't even se= e it as an option for RHEL/Fedora. It's toggled on and off with the new SHOW_PROXY and DEF_PROXY flags in linuxcoe.rc. Lee |
|
From: Lee M. <lee...@gm...> - 2006-03-11 05:56:01
|
Hey All, These lists have been dead for a while, it's time to move more formal communication here vs. IRC I guess. So what I will do is post a message here anytime I check anything major into CVS. This is not major, but thought I'd start getting in the habit. Tonight's update was to enable FTP/HTTP proxy support at install time. I looked long and hard, but I just could not find a way to do this in kickstart. I don't think RH supports it. So for now, it's only avail on preseed and AutoYaST installed servers. So when enabled, you won't even se= e it as an option for RHEL/Fedora. It's toggled on and off with the new SHOW_PROXY and DEF_PROXY flags in linuxcoe.rc. Lee |
|
From: Bryan G. <Bry...@HP...> - 2005-10-12 14:36:24
|
FYI, The sourceforge CVS has been updated to reflect all the goodies of the SystemDesigner v4. In addition, automated snapshots of HEAD are being generated on at least a daily basis, for your downloading pleasure. Grab either via the download link at: http://linuxcoe.sourceforge.net Feedback, as always is welcome, bryang |
|
From: Lee M. <lee...@hp...> - 2005-08-31 03:13:47
|
Just to get a response on record (for mailing list archives), I feel LinuxCOE has to start out as a 'Cathedral' type development model, at least for System Designer. Once the code is a little better commented, the inner workings and API's a little better documented, I see no reason not to move towards the bazaar. However, with System Designer's 'Monolithic Perl' roots, it really doesn't lend itself to the bazaar method well. Bizarre, maybe! Lee |
|
From: Lee M. <lee...@hp...> - 2005-08-31 02:55:38
|
I've got no problem with what's proposed, a little self-discipline would be a good thing IMO. As the CVS doc ref'd from sf.net states, and I paraphrase: "Every developer knows that a 'stable' release is just a snapshot of the development tree at some point in time." Give me, oh, 3 more days (Gee, have you heard that before? :) and we'll do a snapshot of 4.0, I'll stop coding completely, we'll get it checked in, and I'll start learning to live and love the new process. There's still gremlins in the Debian stuff that shouldn't see the light of day. Lee On Tue, 2005-08-30 at 17:05 -0600, Shank, Jeffrey R. wrote: > Here is the proposed development process: > > ----- > 1. Each developer checks out a sandbox from CVS on SourceForge. > Instructions are found on > http://sourceforge.net/cvs/?group_id=144250 > under Developer CVS Access via SSH. > > 2. Developers make changes to the files and test them on their > development machine. When they are ready to test them on the testing > server (which matches the production environment as closely as > possible), they check them into CVS. > > 3. Files from CVS head-of-stream are checked out (perhaps by cron) to > the testing server. If possible, relevant regression tests should be > done to ensure the changes do not break anything else. > > 4. After the changes have been fully tested, the developer tags the > files as "stable". > > 5. During the next release phase the stable files in the repository are > tagged with the version number of the release and that release is > exported and tarred for delivery through the SourceForge file server. > The tarball is then downloaded to the production server, extracted, and > installed in the relevant directories with that releases version number > (for example, /*/opt/SysDes/4.0/*). On the release date, symlinks to the > current version are updated to point to the new version. > ----- > > There will be another e-mail going out sometime tomorrow for the process > on critical bug fixes. Until then, let me know what you think about this > process. > > Thanks, > Jeff > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Linuxcoe-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel |
|
From: ed f. <edf...@ya...> - 2005-08-31 01:20:34
|
It sounds like a fairly standard and straight forward process imho, but I'd like to hear Lee's spin on it if possible. Since I'm not in cvs every day a cheatsheet/brownbag would be really cool (ie, I can't think of how to tag files as "stable" off hand). Also, is there a "standard" development system, or should we expect everything to work on any Linux distribution at any time? xlnt process Jeff, -craiger --- "Shank, Jeffrey R." <js...@hp...> wrote: > Here is the proposed development process: > > ----- > 1. Each developer checks out a sandbox from CVS on > SourceForge. > Instructions are found on > http://sourceforge.net/cvs/?group_id=144250 > under Developer CVS Access via SSH. > > 2. Developers make changes to the files and test > them on their > development machine. When they are ready to test > them on the testing > server (which matches the production environment as > closely as > possible), they check them into CVS. > > 3. Files from CVS head-of-stream are checked out > (perhaps by cron) to > the testing server. If possible, relevant regression > tests should be > done to ensure the changes do not break anything > else. > > 4. After the changes have been fully tested, the > developer tags the > files as "stable". > > 5. During the next release phase the stable files in > the repository are > tagged with the version number of the release and > that release is > exported and tarred for delivery through the > SourceForge file server. > The tarball is then downloaded to the production > server, extracted, and > installed in the relevant directories with that > releases version number > (for example, /*/opt/SysDes/4.0/*). On the release > date, symlinks to the > current version are updated to point to the new > version. > ----- > > There will be another e-mail going out sometime > tomorrow for the process > on critical bug fixes. Until then, let me know what > you think about this > process. > > Thanks, > Jeff > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software > Conference & EXPO > September 19-22, 2005 * San Francisco, CA * > Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects > & Teams * Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Linuxcoe-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel > ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
156 messages has been excluded from this view by a project administrator.
