Menu
▾
▴
linuxcoe-devel
|
From: Bryan G. <Bry...@HP...> - 2007-10-16 18:47:18
|
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
|
|
From: Bruno C. <Bru...@hp...> - 2007-10-16 21:43:59
|
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
|
|
From: Bryan G. <Bry...@HP...> - 2007-10-16 18:50:32
|
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 |
|
From: Bryan G. <Bry...@HP...> - 2007-11-16 17:21:22
|
Bruno,
On Fri, Nov 16, 2007 at 07:01:14AM +0000, Cornec, Bruno (Linux Consultant) wrote:
> Bryan Gartner said on Thu, Nov 15, 2007 at 03:46:55PM -0700:
>
> > > What about adding anoption to configure (for packager, which means me
> > > atm) allowing for bypassing those checks ? That would of course not be
> > > on by default.
> > >
> > > Would that work for you ?
> >
> > Those kinds of checks are already there, IIRC (./configure --help)
> >
> > --without-APACHE skip auto-integratation with Apache webserver
> > --without-SUDOERS skip auto-integration with sudo
Okay I have now setup:
--without-APACHE skip auto-integration with Apache webserver
--without-APACHECTL skip check for apache*ctl
--without-SUDOERS skip auto-integration with sudo
--without-SUDO skip checks for apache*ctl
I believe that the --without-APACHECTL and --without-SUDO will
do what you requested.
> I want the integration. What I don't want is the check that apache
> exists.
>
> With the integration activated it will make a symlink to LInuxCOE.conf
> httpd file correctly, anf thus when I install the package on a machine
> with an apache server (which is a requirement of my package) it just
> works. sudo is indeed less a problem as it's nearly mandatory in distro
> nowadays.
Actually there are a whole set of commands that are beyond mandatory
in a base installation that SystemDesigner relies upon. You just
happen to have most of these in your qemu packaging building instances ;)
If you peek at configure.ac, you will see these broken out by groupings.
In reality, I should do similar checks for all those not required by
FHS, however I drew the line at Apache/Sudo since those two I have to
directly integrate with for a functioning SystemDesigner. The other
checks were left as a failure if not found.
In general, this seems to be somewhat grey area WRT to package builders.
For the debian crowd, this seems to be handling quite gracefully, as
any package build environment starts at the same base level, and uses
the package description to fill in build dependencies, before trying
to create a given package. I am less familiar on how the rpm-based
distributions handle their package builds.
> If I remove the integration, I'll have to add it myself and won't be
> abelt to use the post-action script. Which is of course another
> possibility.
With any luck now, the skip checks will still do the right thing
on the installing host now (including the post-install integration).
bryang
|
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 09:14:35
|
Bruno Cornec said on Wed, Nov 21, 2007 at 01:00:35AM +0100: > > I have updated configure and post-install scripts to do the "right" > > think, AFAICT. Basically the former now gives one the options to > > skip anything I check for, and the latter can try to find the > > commands on the target install system. > > Ok, restarting the VM build process. should take all the night here. I installed this morning the new packages. Even if the binaries.pm modules looks better: [root@localhost ~]# more /var/www/linuxcoe-sd/includes/binaries.pm package binaries; # Blast these programs into the name space of calling scripts # Used by nph-* scripts only (and coe_profiles for sendmail) require Exporter; @ISA = qw(Exporter); @EXPORT = qw($TAR $CPIO $GZIP $GUNZIP $DIFF $FIND $MKISOFS $PALO $SENDMAIL $SUDO); use vars @EXPORT; # Needed programs (beyond those of FHS expected in /bin) $TAR="/bin/tar"; $CPIO="/bin/cpio"; $GZIP="/bin/gzip"; $GUNZIP="/bin/gunzip"; $DIFF="/usr/bin/diff"; $FIND="/usr/bin/find"; $MKISOFS="/usr/bin/mkisofs"; $PALO="NONE"; $SENDMAIL="/usr/sbin/sendmail"; $SUDO="/usr/bin/sudo"; 1; There is still an Internal Server Error at the end, when trying to create the iso. And still no log at all, and still the wrong symlink: [root@localhost ~]# grep LOGFILE !$ grep LOGFILE /etc/linuxcoe-sd/linuxcoe.rc # LOGFILE - defines where SysDes writes it's debug data, LOGFILE >>/var/log/linuxcoe-sd/sysdes.log # If not spec'd, defaults to LOGFILE above [root@localhost ~]# ls -al /var/log/linuxcoe-sd/ total 20 drwxrwsr-x 2 apache apache 4096 Aug 30 02:09 . drwxr-xr-x 12 root root 4096 Nov 21 2007 .. lrwxrwxrwx 1 root apache 20 Aug 30 02:09 linuxcoe-sd -> /var/log/linuxcoe-sd Still scratching my head to understand why all that. Will look at it on my side, but obviously will welcome again your help Bryan. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2008-01-31 13:19:28
|
Bruno,
Just committed the changes to address this issue (I hope, see diff
below). A couple of goofs on my part, I moved from NA -> SKIP
without updating this script, and the echo was from previous debugging
attempts. Sorry about that,
bryang
On Thu, Jan 31, 2008 at 06:29:39AM +0000, Cornec, Bruno (Linux Consultant) wrote:
> 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
RCS file: /cvsroot/linuxcoe/SystemDesigner/bin/post-actions.in,v
retrieving revision 1.20
diff -r1.20 post-actions.in
295c295
< if test "x${APACHE2CTL}" = "xNA" -o "x${APACHE2CTL}" =
"xNONE"; then
---
> if test "x${APACHE2CTL}" = "xSKIP" -o "x${APACHE2CTL}" =
> "xNONE"; then
302c302
< if test "x${APACHECTL}" = "xNA" -o "x${APACHECTL}" = "xNONE";
then
---
> if test "x${APACHECTL}" = "xSKIP" -o "x${APACHECTL}" =
> "xNONE"; then
307c307
< echo ${APACHECTL} restart
---
> ${APACHECTL} restart
>
> 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 ;-)
The SKIP value comes from the --without-APACHECTL, fwiw.
bryang
|
|
From: Bryan G. <Bry...@HP...> - 2007-10-16 19:06:38
|
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 |
|
From: Louis B. <lou...@hp...> - 2007-10-19 13:16:01
|
Hi, >=20 > 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? >=20 I don't see a reason to check in binary data that we do not produce/compile ourselves. We should checkin what is used to produce those images (i.e. scripts) but the the end product itself. This is why the generation script is important in my mind and needs to be addressed asap. I'm off monday to finalize the .spec files and hopefully start on this one. Stay tuned, ...Louis > bryang > Louis Bouchard, Linux Support Engineer > EMEA Linux Competency Center, > Linux Ambassador, HP >=20 > 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: Bruno C. <Bru...@hp...> - 2007-10-16 21:59:03
|
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 |
|
From: Bruno C. <Bru...@hp...> - 2007-11-16 17:48:30
|
Bryan Gartner said on Fri, Nov 16, 2007 at 10:17:58AM -0700: > Okay I have now setup: > > --without-APACHE skip auto-integration with Apache webserver > --without-APACHECTL skip check for apache*ctl > --without-SUDOERS skip auto-integration with sudo > --without-SUDO skip checks for apache*ctl > > I believe that the --without-APACHECTL and --without-SUDO will > do what you requested. Great ! Thanks a lot ! Just trying now to see how it behaves in my VMs. > Actually there are a whole set of commands that are beyond mandatory > in a base installation that SystemDesigner relies upon. You just > happen to have most of these in your qemu packaging building instances ;) Well yes I do not count what nearly every distro has in its base (perl e.g. ) > In reality, I should do similar checks for all those not required by > FHS, however I drew the line at Apache/Sudo since those two I have to > directly integrate with for a functioning SystemDesigner. The other > checks were left as a failure if not found. Fine. I don't think it will cause a pb. > For the debian crowd, this seems to be handling quite gracefully, as > any package build environment starts at the same base level, and uses > the package description to fill in build dependencies, before trying > to create a given package. I am less familiar on how the rpm-based > distributions handle their package builds. Do you mean that Debian automatically install missing packages required for the build ? I would find that too excessive for my side. If everything goes well, monday you'll have a full set of packages ready to use for all RPMs based distro I support. debs are of course the next to be done just after. FYI, installing a LinuxCOE server with those is just: rpm -Uvh linuxcoe*rpm more /var/www/linuxcoe-sd/images/README cd /tmp wget -m http://www.instalinux.com/snapshots/images/ cp -a www.instalinux.com/snapshots/images/*.tar /etc/linuxcoe-sd/images/ Enjoy !! Now I'll also work on the dploy.org added value consisting in linking that with the mirror processes to have more automatic links with the waystation part. (+PXE stuff) Again more on that later. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2007-11-21 09:38:47
|
Bruno Cornec said on Wed, Nov 21, 2007 at 10:14:25AM +0100: > Still scratching my head to understand why all that. Will look at it on > my side, but obviously will welcome again your help Bryan. Humm I found one strange think from my point of view: In /etc/linuxcoe-sd/linuxcoe.rc I have: # FTP_PATH - where the bootable images are made available for download FTP_PATH @ftppubdir@/LinuxCOE/images Is that normal ? Then looking for the '@' in linuxcoe installed files, I found some other unexpanded macros: /var/www/linuxcoe-sd/html/docs/README.last: http://@hostname@/SystemDesigner /var/www/linuxcoe-sd/html/docs/README.last: http://@hostname@/SystemDesigner/docs /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: /etc@prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: @prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: COETHEME @prefix@/html/themes/default /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: @prefix@/html/themes/default /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/etc /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/ [... more in that file ...] /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: /etc@prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: @prefix@/osvend.d /var/www/linuxcoe-sd/html/docs/guides/configuration_overlay.dkb: /etc/@prefix@/ /var/www/linuxcoe-sd/html/docs/guides/eula.dkb: /etc@prefix@/html/eulas /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: @prefix@/base/README /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: /etc@prefix@/base (Seems the doc is not processed correctly in the .spec) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bryan G. <Bry...@HP...> - 2007-11-21 14:06:10
|
Bruno, On Wed, Nov 21, 2007 at 09:38:38AM +0000, Cornec, Bruno (Linux Consultant) wrote: > Bruno Cornec said on Wed, Nov 21, 2007 at 10:14:25AM +0100: > > > Still scratching my head to understand why all that. Will look at it on > > my side, but obviously will welcome again your help Bryan. > > Humm I found one strange think from my point of view: > > In /etc/linuxcoe-sd/linuxcoe.rc I have: > # FTP_PATH - where the bootable images are made available for download > FTP_PATH @ftppubdir@/LinuxCOE/images > > Is that normal ? Well, "normal" = yes. It is an artifact from when we offered FTP as the download mechanism (on the very last pages of bootimage/retrofit). At this point, it is really just an orphaned "feature". I just removed it from linuxcoe.rc (but it did no harm). > Then looking for the '@' in linuxcoe installed files, I found some other > unexpanded macros: I am a bit surprised by this one, as it used to work and will try to fix this. > /var/www/linuxcoe-sd/html/docs/README.last: > http://@hostname@/SystemDesigner > /var/www/linuxcoe-sd/html/docs/README.last: > http://@hostname@/SystemDesigner/docs I am not too surprised by this list in the "docs" space. All of these are in fact the "source" DocBook files, and I only try to ensure that the final .html (and .pdf) files (which are the ones visible from the WebUI of SystemDesigner are certain to have the substitutions. As noted before, I am still in process of a rather major overhaul of the documentation guides (due to a lot of the upgrades to the code), so there are in fact more changes coming. > /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: /etc@prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/install_method.dkb: @prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: COETHEME @prefix@/html/themes/default > /var/www/linuxcoe-sd/html/docs/guides/theme_customization.dkb: @prefix@/html/themes/default > /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/etc > /var/www/linuxcoe-sd/html/docs/guides/configuration.dkb: @prefix@/ > [... more in that file ...] > /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: /etc@prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/distro_rev_arch.dkb: @prefix@/osvend.d > /var/www/linuxcoe-sd/html/docs/guides/configuration_overlay.dkb: /etc/@prefix@/ > /var/www/linuxcoe-sd/html/docs/guides/eula.dkb: /etc@prefix@/html/eulas > /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc > /var/www/linuxcoe-sd/html/docs/guides/global_configuration.dkb: @prefix@/linuxcoe.rc > /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: @prefix@/base/README > /var/www/linuxcoe-sd/html/docs/guides/forced_components.dkb: /etc@prefix@/base > > (Seems the doc is not processed correctly in the .spec) > > Bruno. > -- > Linux Profession Lead EMEA / Open Source Evangelist \ HP C&I EMEA IET > http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net > Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux > La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org |
|
From: Bruno C. <Bru...@hp...> - 2008-01-31 13:59:44
|
Bryan Gartner said on Thu, Jan 31, 2008 at 06:16:34AM -0700: > Just committed the changes to address this issue (I hope, see diff > below). Success :-) > Sorry about that, No worry you're still competing for the fatest bug fix rate of the whole Open Source World ;-) I'' rebuild all the rpms soon, and next week we look at .deb (do you want gentoo :-) Thanks, 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...> - 2008-01-31 14:37:06
|
Bruno, On Thu, Jan 31, 2008 at 01:59:33PM +0000, Cornec, Bruno (Linux Consultant) wrote: > Bryan Gartner said on Thu, Jan 31, 2008 at 06:16:34AM -0700: > > > Just committed the changes to address this issue (I hope, see diff > > below). > > Success :-) > > > Sorry about that, > > No worry you're still competing for the fatest bug fix rate of the whole > Open Source World ;-) Heh, too bad my bug creation rate > bug fix rate ;) > I'' rebuild all the rpms soon, and next week we look at .deb (do you > want gentoo :-) Should have all the .deb stuff in good working order by the end of the week (just finishing up build/test cycles now). And re: gentoo, I will probably defer to your expertise, since I have only used it once (but would like to learn about building "packages" for it). Add that to our todo list, bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-10-16 23:55:42
|
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 |
|
From: Mayes, L. <lee...@hp...> - 2007-10-19 14:29:26
|
While we certainly could script something to create the virgin images, I'm = leaning more towards just documenting the process, as it varies quite wildl= y between distros, and even some between versions of the same distro. Sinc= e we'll have tarballs of the images available publicly, that should do for = all but the most paranoid, and as long as we give them the recipe to create= their own, I think that's sufficient. I'll be happy to write up the processes. Thoughts? Lee -----Original Message----- From: lin...@li... [mailto:linuxcoe-devel-b= ou...@li...] On Behalf Of Bouchard, Louis Sent: Friday, October 19, 2007 9:16 AM To: Gartner, Bryan W Cc: Cornec, Bruno (Linux Consultant); lin...@li... Subject: Re: [Linuxcoe-devel] Update on packaging Hi, > > 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? > I don't see a reason to check in binary data that we do not produce/compile= ourselves. We should checkin what is used to produce those images (i.e. s= cripts) but the the end product itself. This is why the generation script is important in my mind and needs to be a= ddressed asap. I'm off monday to finalize the .spec files and hopefully sta= rt on this one. Stay tuned, ...Louis > bryang > 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: Bryan G. <Bry...@HP...> - 2007-10-19 14:38:13
|
Lee, On Fri, Oct 19, 2007 at 02:28:32PM +0000, Mayes, Lee wrote: > While we certainly could script something to create the virgin images, I'm leaning more towards just documenting the process, as it varies quite wildly between distros, and even some between versions of the same distro. Since we'll have tarballs of the images available publicly, that should do for all but the most paranoid, and as long as we give them the recipe to create their own, I think that's sufficient. I pretty much agree, and had written up the basics some months ago, in the SystemDesigner/images/README file. It is certainly not complete (eg. missing usb image info) and can certainly use more details. However, at least one customer has used this to generate RHEL update images (since we never distributed those). > I'll be happy to write up the processes. Thoughts? Feel free to correct/fix this up as necessary. Plus if you have some time, all the SystemDesigner/*/README files are probably up for a good review/cleanup as well. bryang |
|
From: Bruno C. <Bru...@hp...> - 2007-10-19 15:23:44
|
Mayes, Lee said on Fri, Oct 19, 2007 at 02:28:32PM +0000: > While we certainly could script something to create the virgin images, I'm leaning more towards just documenting the process, as it varies quite wildly between distros, and even some between versions of the same distro. Since we'll have tarballs of the images available publicly, that should do for all but the most paranoid, and as long as we give them the recipe to create their own, I think that's sufficient. > > I'll be happy to write up the processes. Thoughts? That would make a good design doc for the script BTW ;-) And having the script seems mandatory for dploy.org ;-)) 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-10-19 15:22:35
|
Louis Bouchard said on Fri, Oct 19, 2007 at 03:15:52PM +0200: > This is why the generation script is important in my mind and needs to > be addressed asap. I'm off monday to finalize the .spec files and > hopefully start on this one. Humm, FYI I now have everything needed for .spec files based on your original work Louis. So do not pass time anymore on it. It's possible that I try to produce a bunch of RPMs during the WE for at least -base and -docs for you to test next week. I aslo have a -centos build ready, which I may test later on today if time permits (not sure, I'd like to finish my TechCon proposal as well). Should also have a look on the deb, as with what Bryan provides, we shouldn't be far from the result. BTW Bryan to come back to a question you had, PB is perfectly able to *not* filter any file: just do not use macros in it ;-) The only requirement is the structure of the pbconf dir, and the names of subdir. 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 |
|
From: Louis B. <lou...@hp...> - 2007-10-17 07:06:20
|
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 |
|
From: Bruno C. <Bru...@hp...> - 2007-10-19 16:55:30
|
Bruno Cornec said on Fri, Oct 19, 2007 at 05:22:28PM +0200:
> It's possible that I try to produce a bunch of RPMs during the WE for at
> least -base and -docs for you to test next week. I aslo have a -centos
> build ready, which I may test later on today if time permits (not sure,
> I'd like to finish my TechCon proposal as well).
Good day today, I have an abstract (still needs another one for pb ;-)
And I also tested my linuxcoe-sd-data-centos package:
[root@dploy svn]# urpmi
/usr/src/svn/LinuxCOE/build/RPMS/noarch/linuxcoe-sd-data-centos-4.1-1.mdv20=
08.0.noarch.rpm
installing linuxcoe-sd-data-centos-4.1-1.mdv2008.0.noarch.rpm from
/usr/src/svn/LinuxCOE/build/RPMS/noarch
Preparing... ############################################################
1/1: linuxcoe-sd-data-centos
############################################################
And I have the CentOS choices in the ComboBox of links, and was able to
go up to the last page where I got:
Cannot locate defimage for CentOS-4.4-i386 which I think is the correct
error as I do not have the images anymore (I asked it enough ;-)
So now Lee, I'll welcome your proposal of giving instructions ;-)
In he meean time, I know I can provide the other RPM for the other
remaining distro, and test all of that next week.
(BTW, everything is under CVS, except some info for pb building, but
that conf file will be put under CVS when pb reach 0.8.6)
Have a nice week-end.
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
|
|
From: Bryan G. <Bry...@HP...> - 2007-10-17 17:12:15
|
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
|
|
From: Bruno C. <Bru...@hp...> - 2007-10-22 13:42:58
|
Bruno Cornec said on Fri, Oct 19, 2007 at 06:55:18PM +0200: > In the mean time, I know I can provide the other RPM for the other > remaining distro, and test all of that next week. Some more news: # rpm -aq | grep linuxcoe linuxcoe-sd-data-centos-4.1-1.mdv2008.0 linuxcoe-sd-data-debian-4.1-1.mdv2008.0 linuxcoe-sd-docs-4.1-1.mdv2008.0 linuxcoe-sd-data-fedora-4.1-1.mdv2008.0 linuxcoe-sd-data-ubuntu-4.1-1.mdv2008.0 linuxcoe-sd-data-scientific-4.1-1.mdv2008.0 linuxcoe-sd-base-4.1-1.mdv2008.0 linuxcoe-sd-data-opensuse-4.1-1.mdv2008.0 All of those appear in the combo box. Still needs to check with how to instll the image part. 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 |
|
From: Bruno C. <Bru...@hp...> - 2007-10-17 23:42:42
|
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
|
|
From: Bruno C. <Bru...@hp...> - 2007-10-22 14:15:00
|
Bruno Cornec said on Mon, Oct 22, 2007 at 03:40:45PM +0200: > linuxcoe-sd-data-opensuse-4.1-1.mdv2008.0 I seem to not be able to commit my changes for that last package :-( (All previous overlay are in): cvs commit: failed to create lock directory for `/cvsroot/linuxcoe/pbconf/linuxcoe-sd-data-opensuse' (/cvsroot/linuxcoe/pbconf/linuxcoe-sd-data-opensuse/#cvs.lock): No such file or directory cvs commit: lock failed - giving up cvs [commit aborted]: lock failed - giving up Do someone on this list has the possibility to unlock this, or is it a SF.net request to make ? 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X