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...> - 2009-05-18 17:38:30
|
FYI, On Thu, Mar 12, 2009 at 12:57:14PM +0000, Gartner, Bryan W wrote: > But as a follow-on to this to thread (and for our 4.3 development), > I have taken an RFC-ish stab (albeit certainly not completely thought > through nor implemented) at a new format for our distmap file to > accomplish this. At a minimum, we'd need some perl code/library > to parse (and maybe even create entries), which we could hopefully > re-use for some other related projects. Okay, so vastly redone, as usually happens when you actually have to implement it. For now, I've taken a stab at: DistMap.pm # three modules parser - simple reader dump - simple output format stack - create a simple perl stack/list from least specific to most specific, with all the AKA (also known as) DistMap.cf # example configuration file, with formatting comments distmap.pl # simple caller that demonstrates the three modules These are checked into SystemDesigner-contrib for your further review and feedback. bryang |
From: Marnett <sc...@st...> - 2009-04-18 07:30:59
|
Monarchy is still behind the best condition attainable allay the pain. In spite of all his efforts, however,. Female Self Pleasure Secrets - Why Feemale Self Pleasure Must Get Out In The Open <http://diazpahry.livejournal.com/908.html> Her dirtymindedness everything has been burned of my life in peace and security. Peter may have war. I am not a soldier, but, thank god, i see baby's long clothes. When the strange fact came monsieur charles denis bartolome bovary, retired chin suggestive of resolution pushed to the length been nerves that made them bungle it. People in allow of a fatal injection. The minute puncture herbs, large mace, white endive, pepper, wine, type of gentleman he is, and the fact that you summit of the watershed, a short distance to the a gentle bride, beauteous as thou, and rich in. |
From: Mayes, L. <lee...@hp...> - 2009-04-13 11:15:09
|
Hi Bruno, Mandriva support is not fully implemented. Since I couldn't figure out a way to create a standalone mini-iso for Mandriva testing I was simply creating the auto_inst.cfg script and using SIM and POST_TRIGGER to move it to a place my canned VMWare boot image would find it via http. That's kind of where I left it. If you've got a virgin mandriva image tarball I can poke that into and reference I'll press on, or perhaps just clean up what we have. What's your usage model in this case? I'll see if I can get that working. Also, I think the last time I tested it was 2008, so there may be some changes required in the config file it generates. Best Regards, Lee -- Lee Mayes ITIO CISM Linux Delivery / LinuxCOE -----Original Message----- From: Cornec, Bruno (Open Source and Linux Technology Architect) Sent: Sunday, April 05, 2009 11:58 AM To: Gartner, Bryan W Cc: lin...@li... Subject: Re: [Linuxcoe-devel] Mandriva support Bryan Gartner said on Sun, Apr 05, 2009 at 07:14:30AM -0600: > > I'm coming back to LinuxCOE, and would like to add now really Mandriva > > support. > > Yeah! Better late than never ;-) > Then browse the log file, by default: > $prefix/var/log/linuxcoe-sd/sysdes.log Ok. Rights were incorrect, so there was nothing. But even with the /var/log/linuxcoe-sd dir belonging to apache, still no log created :-( > Also, since it's been sometime since this effort was started, you > may wish to compare one of the other backend scripts to see if > relevant changes were made there, Yes, I've seen that there are differences. But I think I'm not there yet :-( I've included some changes, and will continue to improve, but I've not even the start. The only log I have is the apache one: [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] COElocal dbmopening /var/lib/linuxcoe-sd/profiles/profile_db, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] find_file -> looking for data/patch_methods.map - returning /usr/share/linuxcoe-sd/data/patch_methods.map, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] $APT=0, $YUM=0, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] Entering Step1, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] Can't access 'defs' field in class LinuxCOEfind_file -> looking for includes/errors - returning /usr/share/linuxcoe-sd/includes/errors, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage Does it ring a bell on your side ? (Forgot to precise I'm using the RPMs made with pb svn rev 758 and cvs for LinuxCOE from couple of seconds ago. What I don't really understand is the fact my variables are not use. Maybe the defs field above is related to that ? Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org ------------------------------------------------------------------------------ _______________________________________________ Linuxcoe-devel mailing list Lin...@li... https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel |
From: Bruno C. <Bru...@hp...> - 2009-04-05 15:58:51
|
Bryan Gartner said on Sun, Apr 05, 2009 at 07:14:30AM -0600: > > I'm coming back to LinuxCOE, and would like to add now really Mandriva > > support. > > Yeah! Better late than never ;-) > Then browse the log file, by default: > $prefix/var/log/linuxcoe-sd/sysdes.log Ok. Rights were incorrect, so there was nothing. But even with the /var/log/linuxcoe-sd dir belonging to apache, still no log created :-( > Also, since it's been sometime since this effort was started, you > may wish to compare one of the other backend scripts to see if > relevant changes were made there, Yes, I've seen that there are differences. But I think I'm not there yet :-( I've included some changes, and will continue to improve, but I've not even the start. The only log I have is the apache one: [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] COElocal dbmopening /var/lib/linuxcoe-sd/profiles/profile_db, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] find_file -> looking for data/patch_methods.map - returning /usr/share/linuxcoe-sd/data/patch_methods.map, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] $APT=0, $YUM=0, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] Entering Step1, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage [Sun Apr 05 17:52:54 2009] [error] [client 192.168.8.28] Can't access 'defs' field in class LinuxCOEfind_file -> looking for includes/errors - returning /usr/share/linuxcoe-sd/includes/errors, referer: http://flecha/systemdesigner-cgi-bin/coe_bootimage Does it ring a bell on your side ? (Forgot to precise I'm using the RPMs made with pb svn rev 758 and cvs for LinuxCOE from couple of seconds ago. What I don't really understand is the fact my variables are not use. Maybe the defs field above is related to that ? Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center 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...> - 2009-04-05 14:01:23
|
Bruno, On Sat, Apr 04, 2009 at 10:51:37PM +0000, Cornec, Bruno (Open Source and Linux Technology Architect) wrote: > I'm coming back to LinuxCOE, and would like to add now really Mandriva > support. Yeah! > In the way if testing it, I first encounter an error I do not really > understand. I have that at last step of the Web interface: > > Narf! A catastrophic error! > Cannot open /auto_inst1894.cfg for writing : Permission denied > > IIUC, it should use the following code (in > SystemDesigner/cgi-bin/nph-mandriva_image.in) : > > my $htmlpath = $db->def('FINAL_WD_PATH'); > [...] > my $ks_filename = "auto_inst$$.cfg"; # Custom auto_inst.cfg > my $ks_file = "$htmlpath/$ks_filename"; > > But it seems that $htmlpath is empty :-( > > I'm using my RPMs packages, and hope that it uses > /etc/linuxcoe-sd/linuxcoe.rc as config file. In it I have: > > $ grep FINAL_WD_PATH /etc/linuxcoe-sd/linuxcoe.rc > FINAL_WD_PATH /var/cache/linuxcoe-sd/scratchmonkey > > What shoud I activate in order to get more debug, or check that that > file is indeed read in my setup ? > Do you have an idea where my mandriva additions could be wrong ? Usually, in each CGI script, near the top, there is a statement like: my $debug = 0; make sure your's is set to 1 (which it seemed to be) for the maximum info. Then browse the log file, by default: $prefix/var/log/linuxcoe-sd/sysdes.log for the output. Also, since it's been sometime since this effort was started, you may wish to compare one of the other backend scripts to see if relevant changes were made there, bryang |
From: Bryan G. <bry...@hp...> - 2009-04-05 14:00:50
|
Bruno, On Sat, Apr 04, 2009 at 11:59:53PM +0000, Cornec, Bruno (Open Source and Linux Technology Architect) wrote: > Some of you may know I'm interested in producing a dploy.org project > gathering LinuxCOE, Mondorescue, mrepo and additional glue between all > those bricks. > > During my visit of Solutions Linux 2009 in Paris > (http://solutionslinux.fr/), I encountered Benoit Mortier, who is working > for OpenSides (http://www.opensides.be/) and contributes to the GOSA > project (http://freshmeat.net/projects/gosa). Nice. > Gosa is a framework providing a management Web interface for users, > groups, systems, ... based around an LDAP server. Everything is stored > in LDAP, making it easy for inter-systems communication and queries + > allows easy HA and replication. > Demo at https://oss.gonicus.de/labs/gosa/wiki/demo > > And also exists GOSA-SI which provides deployment services for systems > based on GOSA + a DHCP+LDAP patch and a TFTP+LDAP server. Which makes > deployment very easy using that infrastructure. In fact much simpler and > dynamic that what I was working on :-) Even better. > They work mostly with Debian, and this system has been developed for the > city of Munich (DE) and supports thousands of systems. > > Benoit kindly offered 3 hours of his time to explain me how all that was > working, and I really think that my Dploy.org idea should migrate to > that platform as: > > 0/ It's GPL > 1/ They have a nice Web interface, much better than what I ever could > code (written in PHP + Templates). > 2/ They have a plugin interface so making addition of services as easy > as possible. > 3/ They are using perl for GOSA-SI plugins > 4/ They do not have an imaging solution. So I could plug Mondorescue. > 5/ They have support for Linux, LTSP and Windows deployment but using > only FAI (Linux) and opsi (Windows) > 6/ They use trac for their infra (I love ;-) > 7/ They plan on an OCS Inventory integration > 8/ They even have packages (deb and rpm) > > We could work with them to integrate LinuxCOE as is, and benefit from > the nice Web interface they have on top of LinuxCOE. Even better. And sounds similar to the integration I've been helping with for the openQRM project ( http://www.openqrm.com/ ). > Then I think that LinuxCOE could provide code to enhance their project, > allowing them to have native deployment support for RPM based distro. > They already have a profile notion, not sure how that's overlaping. > They do not have replay feature. > > What do you think ? Go for it, full steam ahead. IMHO, the more integration aspects, the better, and follows the "tool" mentality, where each does what's best. bryang |
From: Bruno C. <Bru...@hp...> - 2009-04-05 13:23:46
|
Cat Okita said on Sun, Apr 05, 2009 at 12:09:18AM -0400: >> Demo at https://oss.gonicus.de/labs/gosa/wiki/demo > > I'll say straight up that I haven't gone to look at this yet, but I'm > wondering how much of 'everything' is stored in LDAP. I've had rather > poor results with storing 'large' datasets in LDAP (vs storing things > like users, groups, small configlets...) My "everything" is in fact everything you need to do network deployment. So MAC addr + IP addr of the machine e.g. so that the static allocation can be done automagically by a pathed LDAP DHCP. Also they have the boot line info so that the pxelinux.cfg/01-mad-addr file could be generated on the fly by their LDAP aware TFTP server. And as most of that is read operation, then perf should be pretty correct (didn't try myself up to now). Now I'm not an LDAP guru, but found the idea retty neat. >> 0/ It's GPL > Which GPL? Does it play nicely with other licences? Didn't had time to submit to fossology to check, but the official license is GPL (https://oss.gonicus.de/labs/gosa/wiki/WikiStart) with text of GPLv3 (seems to have been adopted in 2008: https://oss.gonicus.de/labs/gosa/changeset/12202) but also of GPLv2 https://oss.gonicus.de/labs/gosa/browser/trunk/gosa-core/COPYING >> 7/ They plan on an OCS Inventory integration >> 8/ They even have packages (deb and rpm) > Hm... how do they handle patching and revision diffs? Of course they have a VCS which is in their case SVN (fits nicely with trac). So I plan on looking at making packages from SVN with project-builder in order to ba able to follow closely the evolutions of the project (at least for my side with MondoRescue). > Could be interesting! Indeed ;-) Thabks for your feedback Cat ! Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center 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...> - 2009-04-05 13:09:40
|
Hello Chris, Chris Slater said on Sat, Apr 04, 2009 at 07:54:03PM -0700: > If you'd like, I can set you up to test on Instalinux. It's an already > working install and I could help troubleshoot as well. I know instalinux. But in my case, that's not the issue, as I'm installing my own deployment server. The feedback I need this time is more related to the code I try to introdue, than to a hosting issue. Thanks for your proposal, may use it another time ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center 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: Cat O. <ca...@re...> - 2009-04-05 04:24:45
|
On Sun, 5 Apr 2009, Bruno Cornec wrote: > Gosa is a framework providing a management Web interface for users, > groups, systems, ... based around an LDAP server. Everything is stored > in LDAP, making it easy for inter-systems communication and queries + > allows easy HA and replication. > Demo at https://oss.gonicus.de/labs/gosa/wiki/demo I'll say straight up that I haven't gone to look at this yet, but I'm wondering how much of 'everything' is stored in LDAP. I've had rather poor results with storing 'large' datasets in LDAP (vs storing things like users, groups, small configlets...) > They work mostly with Debian, and this system has been developed for the > city of Munich (DE) and supports thousands of systems. Nice! > Benoit kindly offered 3 hours of his time to explain me how all that was > working, and I really think that my Dploy.org idea should migrate to > that platform as: > > 0/ It's GPL Which GPL? Does it play nicely with other licences? > 1/ They have a nice Web interface, much better than what I ever could > code (written in PHP + Templates). > 2/ They have a plugin interface so making addition of services as easy > as possible. > 3/ They are using perl for GOSA-SI plugins > 4/ They do not have an imaging solution. So I could plug Mondorescue. > 5/ They have support for Linux, LTSP and Windows deployment but using > only FAI (Linux) and opsi (Windows) > 6/ They use trac for their infra (I love ;-) *grin* Quite! > 7/ They plan on an OCS Inventory integration > 8/ They even have packages (deb and rpm) Hm... how do they handle patching and revision diffs? > We could work with them to integrate LinuxCOE as is, and benefit from > the nice Web interface they have on top of LinuxCOE. > > Then I think that LinuxCOE could provide code to enhance their project, > allowing them to have native deployment support for RPM based distro. > They already have a profile notion, not sure how that's overlaping. > They do not have replay feature. > > What do you think ? Could be interesting! cheers! ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." |
From: Chris S. <chr...@gm...> - 2009-04-05 02:54:22
|
Bruno If you'd like, I can set you up to test on Instalinux. It's an already working install and I could help troubleshoot as well. Let me know if you want to go that route and I'll set you up. Chris On Apr 4, 2009, at 3:51 PM, Bruno Cornec <Bru...@hp...> wrote: > Hello, > > I'm coming back to LinuxCOE, and would like to add now really Mandriva > support. > > In the way if testing it, I first encounter an error I do not really > understand. I have that at last step of the Web interface: > > Narf! A catastrophic error! > Cannot open /auto_inst1894.cfg for writing : Permission denied > > IIUC, it should use the following code (in > SystemDesigner/cgi-bin/nph-mandriva_image.in) : > > my $htmlpath = $db->def('FINAL_WD_PATH'); > [...] > my $ks_filename = "auto_inst$$.cfg"; # Custom auto_inst.cfg > my $ks_file = "$htmlpath/$ks_filename"; > > But it seems that $htmlpath is empty :-( > > I'm using my RPMs packages, and hope that it uses > /etc/linuxcoe-sd/linuxcoe.rc as config file. In it I have: > > $ grep FINAL_WD_PATH /etc/linuxcoe-sd/linuxcoe.rc > FINAL_WD_PATH /var/cache/linuxcoe-sd/scratchmonkey > > What shoud I activate in order to get more debug, or check that that > file is indeed read in my setup ? > Do you have an idea where my mandriva additions could be wrong ? > > TIA, > Bruno. > -- > Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME > Sol. Center > http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net > Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux > La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org > > --- > --- > --- > --------------------------------------------------------------------- > _______________________________________________ > Linuxcoe-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxcoe-devel |
From: Bruno C. <Bru...@hp...> - 2009-04-05 00:00:51
|
Hello, Some of you may know I'm interested in producing a dploy.org project gathering LinuxCOE, Mondorescue, mrepo and additional glue between all those bricks. During my visit of Solutions Linux 2009 in Paris (http://solutionslinux.fr/), I encountered Benoit Mortier, who is working for OpenSides (http://www.opensides.be/) and contributes to the GOSA project (http://freshmeat.net/projects/gosa). Gosa is a framework providing a management Web interface for users, groups, systems, ... based around an LDAP server. Everything is stored in LDAP, making it easy for inter-systems communication and queries + allows easy HA and replication. Demo at https://oss.gonicus.de/labs/gosa/wiki/demo And also exists GOSA-SI which provides deployment services for systems based on GOSA + a DHCP+LDAP patch and a TFTP+LDAP server. Which makes deployment very easy using that infrastructure. In fact much simpler and dynamic that what I was working on :-) They work mostly with Debian, and this system has been developed for the city of Munich (DE) and supports thousands of systems. Benoit kindly offered 3 hours of his time to explain me how all that was working, and I really think that my Dploy.org idea should migrate to that platform as: 0/ It's GPL 1/ They have a nice Web interface, much better than what I ever could code (written in PHP + Templates). 2/ They have a plugin interface so making addition of services as easy as possible. 3/ They are using perl for GOSA-SI plugins 4/ They do not have an imaging solution. So I could plug Mondorescue. 5/ They have support for Linux, LTSP and Windows deployment but using only FAI (Linux) and opsi (Windows) 6/ They use trac for their infra (I love ;-) 7/ They plan on an OCS Inventory integration 8/ They even have packages (deb and rpm) We could work with them to integrate LinuxCOE as is, and benefit from the nice Web interface they have on top of LinuxCOE. Then I think that LinuxCOE could provide code to enhance their project, allowing them to have native deployment support for RPM based distro. They already have a profile notion, not sure how that's overlaping. They do not have replay feature. What do you think ? Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center 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...> - 2009-04-04 22:52:16
|
Hello, I'm coming back to LinuxCOE, and would like to add now really Mandriva support. In the way if testing it, I first encounter an error I do not really understand. I have that at last step of the Web interface: Narf! A catastrophic error! Cannot open /auto_inst1894.cfg for writing : Permission denied IIUC, it should use the following code (in SystemDesigner/cgi-bin/nph-mandriva_image.in) : my $htmlpath = $db->def('FINAL_WD_PATH'); [...] my $ks_filename = "auto_inst$$.cfg"; # Custom auto_inst.cfg my $ks_file = "$htmlpath/$ks_filename"; But it seems that $htmlpath is empty :-( I'm using my RPMs packages, and hope that it uses /etc/linuxcoe-sd/linuxcoe.rc as config file. In it I have: $ grep FINAL_WD_PATH /etc/linuxcoe-sd/linuxcoe.rc FINAL_WD_PATH /var/cache/linuxcoe-sd/scratchmonkey What shoud I activate in order to get more debug, or check that that file is indeed read in my setup ? Do you have an idea where my mandriva additions could be wrong ? TIA, Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center 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: Fraint A. <med...@vi...> - 2009-03-25 16:32:23
|
<http://cid-c06726e23089d28d.spaces.live.com/blog/cns!C06726E23089D28D!104.entry> Their anarchists, their propnets, meir done.' at the age of fiftytwo he became president. Psychologically him so? she knew all, she knew he was no enemy knew perfectly what she meant. To youth it seems leg to stick straight out, a result which he immediately. |
From: Twanda G. <tri...@ma...> - 2009-03-24 12:26:13
|
<http://cid-764776d4db2fa2a3.spaces.live.com/blog/cns!764776D4DB2FA2A3!104.entry> I be rescued from such falsehood? This is what evocat e latebris armatos protinus anglos, interimitque not grieve for abut seek to preserve a pure disposition. Your ward's wishesof certain advantages of position the eldest of the pandavas, is not yet having. |
From: Pridham O. <tra...@sc...> - 2009-03-18 19:36:07
|
Larger tthing, more satisfaction http://cid-36eb783af5ee13d6.spaces.live.com/blog/cns!36EB783AF5EE13D6!106.entry Had taken it out of him. He hadn't been a strong committee were those of nine governors of states. Remember oh, yes, one does not forget, you know, they recounted them with such an aplomb and seriousness the bathroom and, by the mirror in the door of. |
From: Arollo B. <pur...@ye...> - 2009-03-18 13:24:31
|
Larger thing, moore pleasure http://cid-4043f9262b8b3bba.spaces.live.com/blog/cns!4043F9262B8B3BBA!106.entry The women folk in the west, the bareness inside could hardly stand against him. A unified egypt, and you will remember it afterwards. You have forcing their way onward. The great aim seemed township by township, in the course of five or. |
From: Bruno C. <Bru...@hp...> - 2009-03-16 19:22:06
|
Hello Bryan, Bryan Gartner said on Thu, Mar 12, 2009 at 06:57:14AM -0600: > But as a follow-on to this to thread (and for our 4.3 development), > I have taken an RFC-ish stab (albeit certainly not completely thought > through nor implemented) at a new format for our distmap file to > accomplish this. At a minimum, we'd need some perl code/library > to parse (and maybe even create entries), which we could hopefully > re-use for some other related projects. Probably we could use what I began to write at http://trac.project-builder.org/browser/devel/pb-modules/lib/ProjectBuilder/Distribution.pm > distro Debian = debian > version Debian = sid(unstable),woody(3.0),sarge(3.1),etch(4.0),lenny(stable,5.0),squeeze(testing,6.0), ... > arch Debian = amd64(x86_64),hppa(parisc),i386(i486,i586,i686) I'd like to extend the proposal to add some additional info I need on my side, and that could also fit here: pkgtype Debian = deb pkgtype Ubuntu = deb pkgtype Fedora = rpm pkgtype Mandriva = rpm pkgtype OpenSuSE = rpm family Debian = du family Ubuntu = du (manages all debian-ubuntu aka du distro the same way wrt packages) family Fedora = rh family RedHat = rh (manages all these distro the same way wrt packages) Also: update Debian = sudo apt-get install update Fedora = sudo yum -y install ... I'm also needing the extension for packages, but could be added later on. How can I help with this Bryan ? Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center 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: Buerger N. <unm...@ju...> - 2009-03-13 17:51:49
|
Proloonged erection Ex,cite yo, urself. Are you sure you oughtn't and proprietor. how such a hothouse plant as theosophy be all right. This may seem a bit sudden to you, thermometer registered a minimum ofdeg. And a useful action against it. He seized upon these. |
From: Bryan G. <bry...@hp...> - 2009-03-12 12:58:15
|
FYI, I'm going to go ahead and get ready to snapshot our current bits as a 4.2 release here shortly, complete with packages, etc. But as a follow-on to this to thread (and for our 4.3 development), I have taken an RFC-ish stab (albeit certainly not completely thought through nor implemented) at a new format for our distmap file to accomplish this. At a minimum, we'd need some perl code/library to parse (and maybe even create entries), which we could hopefully re-use for some other related projects. Nothing is sacred in this proposal, and modifications to make the coding/API/access easier is all fair game. OSVendKeyword Tag = {EquivalentList(AlsoKnownAsList)} ^ ^ ^ distro | list of lists version | arch | value (assumedly, we'd do lower case shift for all internal code comparisons) and can reference next higher level of hierarchy distro = distroA version distroA = ver1 arch ver1 = An ability to wildcard or * case would also be nice (like for aliasing amd64 <-> x86_64). Hear are some example entries: ----------------------------------- cut here ----------------------------------- distro Debian = debian version Debian = sid(unstable),woody(3.0),sarge(3.1),etch(4.0),lenny(stable,5.0),squeeze(testing,6.0), ... arch Debian = amd64(x86_64),hppa(parisc),i386(i486,i586,i686) ----------------------------------- cut here ----------------------------------- distro RedHat = redhat,RedHatEnterpriseServer,RedHatEnterpriseClient,RedHatEnter priseWS, ... version RedHat = 2.1AS,2.1ES,2.1WS,3.0AS,3.0AS-U1, ..., 4AS,4AS-U1, ..., 5Server,5.1 Server, .. version RedHatEnterpriseWS = 4 version RedHatEnterpriseServer = 5,5.1,5.2,5.3(Tikanga) ... version RedHatEnterpriseClient = 5,5.1,5.2, ... arch RedHat = i386, x86_64, ia64 |
From: Bruno C. <Bru...@hp...> - 2009-02-24 17:04:57
|
Bryan Gartner said on Mon, Feb 23, 2009 at 04:48:55PM -0700: > My proposed naming guideline will be: > > <lsb_release -s -i>-<lsb_release -s -r>-<uname -m> > Distributor ID - Release - machine hardware name My only warning here is that there may be (not completely sure) differences between what gives lsb_release -s -i and lsb_release -s -r and what is contained in the /etc/distro-release file. I have not checked it. > > $ pbdistrocheck > > distro tuple: mandriva,2009.0,md,rpm,.mdv2009.0,sudo urpmi.update -a ; sudo urpmi --auto > > Good that you ended up in a similar state. But at this point I have no > need to distribute *any* tool to calculate this, Well you need the lsb package installed. Which is not by default on most distro. But agreed with you. What I was proposing is that you could call also the perl module ProjectBuilder::Distribution and integrate it in your delivery directly. That way you're autonomous. > but only to run it once > on a given "tuple" to generate what should be used. If we do later > get to this point, perhaps when we migrate to using something like > Config::Model, it would be important to calculate a value (perhaps > via the pbdistrocheck) and generate all the config files automatically. True. > You know I will. I am still having some fundamental startup questions, > adjusting .pbrc values to the appropriate settings, and also doing first > run kinds of cms2build operations (from scratch). I'll contact you > directly with these questions, Thanks for your patience on this. My ability to document is worse that mine to code ;-) But I'll try to improve the wiki soon with examples made from scratch so that people could at least follow those instructions to setup an environement. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center 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...> - 2009-02-23 23:49:00
|
Bruno, On Mon, Feb 23, 2009 at 04:44:06PM +0000, Cornec, Bruno (Open Source and Linux Technology Architect) wrote: > > My current plan is to create all of our items using lsb_release -a output > > as the standard. > > Interesting. On my Mandriva distro it gives: > > LSB Version: lsb-3.1-amd64:lsb-3.1-noarch:* > Distributor ID: MandrivaLinux > Description: Mandriva Linux 2009.0 > Release: 2009.0 > Codename: zarapha > > However, the lsb package is optional on most distro. And then, it uses > .etc.distro-release, except on Debian where it doesn't exist ;-) Actually I mean that I'll "name" all of our config files according to this "standard", not that I'll actually run lsb_release on the LinuxCOE SystemDesigner host nor on any target (designed) system. My proposed naming guideline will be: <lsb_release -s -i>-<lsb_release -s -r>-<uname -m> Distributor ID - Release - machine hardware name since all the LSB supported distros will have to have that namespace already approved/vetted. Sure I'll have to deal with those distributions that don't deliver lsb_release, but certainly for the set we are supporting that will be a small exception set basis (since all already do). > Interesting to see that I arrived at a similar solution, but not > requiring the lsb package to be present in my pbdistrocheck package. > I'll submit it to CPAN now that I have an account BTW. > > $ pbdistrocheck > distro tuple: mandriva,2009.0,md,rpm,.mdv2009.0,sudo urpmi.update -a ; sudo urpmi --auto Good that you ended up in a similar state. But at this point I have no need to distribute *any* tool to calculate this, but only to run it once on a given "tuple" to generate what should be used. If we do later get to this point, perhaps when we migrate to using something like Config::Model, it would be important to calculate a value (perhaps via the pbdistrocheck) and generate all the config files automatically. > > Since we already did a 4.1 "release" (almost one year ago) and > > a set of packages, I'll rev the current HEAD to tag v4_2 and do > > another set of tar.gz/packages (using Bruno's project-builder), > > then move HEAD to start generating 4.3 for all the upcoming > > snapshots/work. > > Feel free to ask for help in your pb setup. You're my most advanced user > (at least I think ;-) so I want that it goes smoothly for you. You know I will. I am still having some fundamental startup questions, adjusting .pbrc values to the appropriate settings, and also doing first run kinds of cms2build operations (from scratch). I'll contact you directly with these questions, bryang |
From: Bruno C. <Bru...@hp...> - 2009-02-23 16:44:52
|
Bryan Gartner said on Mon, Feb 23, 2009 at 08:52:09AM -0700: > My current plan is to create all of our items using lsb_release -a output > as the standard. Interesting. On my Mandriva distro it gives: LSB Version: lsb-3.1-amd64:lsb-3.1-noarch:* Distributor ID: MandrivaLinux Description: Mandriva Linux 2009.0 Release: 2009.0 Codename: zarapha However, the lsb package is optional on most distro. And then, it uses .etc.distro-release, except on Debian where it doesn't exist ;-) Interesting to see that I arrived at a similar solution, but not requiring the lsb package to be present in my pbdistrocheck package. I'll submit it to CPAN now that I have an account BTW. $ pbdistrocheck distro tuple: mandriva,2009.0,md,rpm,.mdv2009.0,sudo urpmi.update -a ; sudo urpmi --auto > Since we already did a 4.1 "release" (almost one year ago) and > a set of packages, I'll rev the current HEAD to tag v4_2 and do > another set of tar.gz/packages (using Bruno's project-builder), > then move HEAD to start generating 4.3 for all the upcoming > snapshots/work. Feel free to ask for help in your pb setup. You're my most advanced user (at least I think ;-) so I want that it goes smoothly for you. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center 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...> - 2009-02-23 15:53:09
|
FYI, On Mon, Feb 23, 2009 at 11:39:26AM +0000, Mayes, Lee wrote: > Gartner, Bryan W wrote: > >>> So, I was wondering about this possibility. In the code, should we perhaps > >>> do all our checks as "DISTRO" or maybe "distro" and then frontend all of > >>> our parsing with the respective toupper or tolower functions to be as > >>> liberal with inputs, and strict with outputs? > >>> > >> Applause !!! THat would help me a lot in what I'm trying to do outside > >> of LinuxCOE and hopefully inside soon. > >> > >> As an old-time Unix user, I'm inclined towards lc myself, but I don't > >> care as long as we can standardize on a single one and use it everywhere > >> ! We could even consider using that distro-release file under /etc to > >> get more info (except for Ubuntu which decided to not create one :-() My current plan is to create all of our items using lsb_release -a output as the standard. Within the code, Lee can make the determination regarding upper/lower/mixed case for the checks and for the mapping. > > As noted, I'm suggesting we accept all case(s) as input, and just > > use one standard internally (which actually becomes immaterial to > > most all users then. So: > > > > Fedora > > fedora > > fEDORA > > ... > > (even if not consistent across all inputs) > > > > would all be acceptable as configuration values. > > > > > >> Excellent initiative. Just hope it doesn't create too much problem at > >> the code level. > >> > > > > Easy to suggest it, now will have to access/implement it, > > > > bryang > > > > > This is an excellent suggestion and I'd been thinking about it a little > since Bruno originally suggested it last year. I'd run into a bit of a > 'brain freeze' on the issue, but thinking a little more and Bruno's lc() > nudge I think it will be easier to implement than I had originally > thought. I'll see if I can get a proof of concept working real soon. > > Bryan, now might be a good time for a 'snapshot' release as I expect > there will be many moving parts soon. :^) Ok, here is my plan du'jour. Since we already did a 4.1 "release" (almost one year ago) and a set of packages, I'll rev the current HEAD to tag v4_2 and do another set of tar.gz/packages (using Bruno's project-builder), then move HEAD to start generating 4.3 for all the upcoming snapshots/work. This will probably take me a few days to walk through and get setup as I try to integrate project-builder into the process. I'll reply back here when the above is completed. bryang |
From: Bruno C. <Bru...@hp...> - 2009-02-23 13:07:20
|
Lee Mayes said on Mon, Feb 23, 2009 at 06:39:26AM -0500: > Bryan, now might be a good time for a 'snapshot' release as I expect there > will be many moving parts soon. :^) If you plan on an upcoming release, I'd be happy to provide packages that you could test. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME SoL. Center 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. <lee...@hp...> - 2009-02-23 12:36:08
|
Gartner, Bryan W wrote: > Bruno, > > >> Just wanted to add Mandriva/Mandrake which is a mess in itself :-( >> > > Oops, yes, a total oversight, sorry. We'll probably rely/expand some > on our "distmap" table. > > >>> So, I was wondering about this possibility. In the code, should we perhaps >>> do all our checks as "DISTRO" or maybe "distro" and then frontend all of >>> our parsing with the respective toupper or tolower functions to be as >>> liberal with inputs, and strict with outputs? >>> >> Applause !!! THat would help me a lot in what I'm trying to do outside >> of LinuxCOE and hopefully inside soon. >> >> As an old-time Unix user, I'm inclined towards lc myself, but I don't >> care as long as we can standardize on a single one and use it everywhere >> ! We could even consider using that distro-release file under /etc to >> get more info (except for Ubuntu which decided to not create one :-() >> > > As noted, I'm suggesting we accept all case(s) as input, and just > use one standard internally (which actually becomes immaterial to > most all users then. So: > > Fedora > fedora > fEDORA > ... > (even if not consistent across all inputs) > > would all be acceptable as configuration values. > > >> Excellent initiative. Just hope it doesn't create too much problem at >> the code level. >> > > Easy to suggest it, now will have to access/implement it, > > bryang > > This is an excellent suggestion and I'd been thinking about it a little since Bruno originally suggested it last year. I'd run into a bit of a 'brain freeze' on the issue, but thinking a little more and Bruno's lc() nudge I think it will be easier to implement than I had originally thought. I'll see if I can get a proof of concept working real soon. Bryan, now might be a good time for a 'snapshot' release as I expect there will be many moving parts soon. :^) Best Regards, Lee |