Menu
▾
▴
ark-users — General discussion by Arusha Project people
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
(5) |
Mar
(12) |
Apr
(1) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(35) |
Oct
|
Nov
|
Dec
|
|
From: Will P. <pa...@dc...> - 2002-09-27 15:21:52
|
Joel S writes: > Wearing my Redhat Linux administrator hat, I hesitate. I > believe that Redhat continues to include Python 1.5.2 in > its distributions. ... Yes (but not sure about 8.0). The 7.x distributions have python 2.x as /usr/bin/python2. We'll definitely cover those possibilities, if we get to that. Jonathan's comment about expat depressed me. I *hate* packages that _silently_ turn into one thing (an XML-capable Python) if the configure script happens to notice something lying around (expat), and into something else (an XML-cripped Python) otherwise. It doesn't yell or anything; unless you check every configure log *carefully*, you'll miss these. Bummer. Will |
|
From: Shprentz, J. [C] <Shp...@ni...> - 2002-09-27 14:28:34
|
Will Partain wrote:
> I propose that, from 1st January 2003, we require Python 2
> for ARK, and try *very hard* to get by with nothing but the
> builtin 'minidom'.
Wearing my Sun Solaris administrator hat, I concur. Python 2 is just one
more arbitrary prerequisite to load (we use it here anyway).
Wearing my Redhat Linux administrator hat, I hesitate. I believe that
Redhat continues to include Python 1.5.2 in its distributions. Of course,
anyone who could productively use Arusha should be able to find and install
Python 2.
One suggestion: Don't assume that Python 2 will have a binary named python.
Many sites have both Python 1.? and Python 2.? installed, with the newer
version named python2 or python2.2. Yes, I know most names are configurable
in Arusha, but arkcmd begins
#! /usr/bin/env python
--Joel
|
|
From: Jonathan H. <jon...@on...> - 2002-09-27 11:17:12
|
On 27/9/2002 12:10, Will Partain wrote: > I propose that, from 1st January 2003, we require Python 2 > for ARK, and try *very hard* to get by with nothing but the > builtin 'minidom'. > > OK, it may be a pain to have to have Python 2, but all the > PyXML problems just vanish. [And why would anyone *not* > want Python 2 (which came out on Oct 16, 2000)?] I'd second that. Though we have to add another dependency on expat being installed first. Bah. Perhaps we should just write our own XML parser. Heck, it's not that hard. I wrote one yesterday... Jonathan -- jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451 |
|
From: Will P. <pa...@dc...> - 2002-09-27 11:10:25
|
Jonathan, near the end of a thread with a muddle about Python and PyXML: > One day Python will get its act together regarding XML and we can make this > sort of nonsense go away. I propose that, from 1st January 2003, we require Python 2 for ARK, and try *very hard* to get by with nothing but the builtin 'minidom'. OK, it may be a pain to have to have Python 2, but all the PyXML problems just vanish. [And why would anyone *not* want Python 2 (which came out on Oct 16, 2000)?] Anyone want to argue? Will |
|
From: Will P. <pa...@dc...> - 2002-09-27 10:57:54
|
> As far as I can remember (which currently extends at least until > yesterday), it is similar to a clown wig. ... Luke, you, uh, may wish to change your identity and have that plastic surgery before you make that visit to Scotland.. The Jimmy Wig is the Official Headgear of the "Tartan Army", the rapid supporters of the ever-lofty Scottish football (soccer) team. > My guess is that the "Jimmy" reference is to Jimi Hendrix, > ... Maybe we can get Matt, who spends a lot of time in Glasgow pubs, to record some local colloquial speech, which will undoubtedly include the phrase "See *you*, Jimmy,...", and it will all become clear. Will |
|
From: Will P. <pa...@dc...> - 2002-09-27 10:53:27
|
Joel S writes: > The term "bits" appears throughout the Arusha documentation. For example, on > the "Arusha Project package management" page > <http://ark.sourceforge.net/pkg-mgmt.html#terminology>, you define a package > in terms of bits: "A 'package' is a logically coherent bundle of bits > promulgated by a team that represent some sysadmin 'added value.'" > > As an American working with computers, I assumed that these bits were binary > digits--literally the ones and zeroes that compose a package. Then my > British neighbor spoke of needing some bits to repair his car. > > Now I wonder whether a package is a bundle of binary digits or a bundle of > small pieces. I will clarify all uses of the words 'bit' and 'bits' :-) (I have a dubious linguistic heritage, so blame it on my early childhood!) A package is (ultimately) "binary digits". It may be "logically coherent" but not "co-located" (see "dchunks"). For example, a package "apache-config-intranet" may include an http.conf (which gets put in one place), and a boot script (which gets put in /etc/init.d/), and you might even count the http and https lines in /etc/services (those are bits, too...) as part of that package -- they all {go, are managed} together (logically coherent), even if they don't live together on a live system. Will |
|
From: Will P. <pa...@dc...> - 2002-09-27 10:09:07
|
Here are detailed comments on Joel S's notes: > Following the Sidai team notes on booting ARK stuff, I copied and > modified the sidai/sysadmin-utils/add-perhost-ark-dirs.sample script. Note that I've tidied up the "blessed names" for things (optional, of course); e.g. reveal area deploy area /our /our/.-ark-deploy /usr/local /usr/local/.-ark-deploy / /.-ark-deploy (I won't change glasli1, because that isn't what it uses :-() Also, I now am inclined to keep ARK/system-y chunks in /sys, rather than /d; so I changed things to refer to e.g. /sys/.-ark-install-ALL /sys/ark-builds /sys/ark-state Note that where I keep tarballs and vendor things are still /d/open-src /d/vendor-stuff Again, these are all entirely up to the site owner. > cd $ARK_SRC/ARK/arkbase > ./arkcmd package reveal --verbose --use-deps=max arkbase < /dev/null Given current chat on ark-dev, this may need to change to ./arkcmd package reveal --verbose ark-bootstrap but let's wait and see... > In the sample1 team, revealing arkbase requires ALL.xml and three > packages (ark-prereq-utils.xml, ark-site-gen.xml, and arkbase.xml). > I copied newer versions of these package files from the verilab2 team > to the package directory of my own team. I sync'd all of these except ALL.xml, where sample1 and any-real-team (e.g. verilab2) are trying to do quite different things (play vs work :-). > On the next run, I learned that my primary group must match the group > specified by ark-sysadmin-group-must-be. ... Note: if you don't want all ARK work to be forced to be done as a particular group (e.g. when multiple cooperating sysadmins), then just don't set that field. > Arusha complained that a "CVS entry is badly formed." I had checked > in the Arusha distributions with the -ko option to retain the > original CVS keyword expansions. This displeased event.py. Fixed in the next release :-) > My next challenge was understanding why Arusha complained about > directories like /our/.-ark-deploy, which were not mentioned in > add-perhost-ark-dirs.sample or the HTML documentation. The explanation > was that verilabs2 lists different directories than glasli1 or the > documentation. ... Fixed; as per notes above. > As Arusha installed itself, it created three new directories in /d: > ark-builds, ark-gen-pkg, and ark-state. It had some trouble creating > /d/ark-gen-pkg/arkbase because /d/ark-gen-pkg had not yet been > created. Following the approach used elsewhere, I added -p to the > mkdir options. Fixed. > I was installing Arusha on a virgin machine, but Arusha was configured > to look for tar, gcc, and other programs in the places where it would > later install them. Some packages specified a boot version of these > utilities, but, perversely, these three basic Arusha packages did not. As you know (from ark-dev), we're taking another run at this bootstrapping thing; I think it's going to be simpler. Keep up the good work, Will |
|
From: Jonathan H. <jon...@on...> - 2002-09-26 07:44:53
|
On 26/9/2002 1:52, Luke A. Kanies wrote: >> Try running the following at a Python prompt: >> >>>>> import xml.dom.ext.reader.Sax > > That did it. For some retarded reason, my PyXML compiled with ssl > support, but can't find it during loading. Uh, huh? Excellent! I think the actual way it works is that the socket library uses SSL if it's found during compilation, the socket library is used by urllib, and urllib is used by PyXML. > I set the LD_LIBRARY_PATH and it all worked, but that's obviously not the > long term solution. Unfortunately, *sigh* Python has a complicated mechanism for building that makes it very difficult to build with non-standard linking paths. I've tried to argue this before with Python developers but they seem to believe that people only ever install things in /usr/local... > Definitely being hampered by the total lack of knowledge of how python > does stuff, but I guess I'll get it figured out. > > I'm still having some issues, but at least it compiles now. Cool. Keep in touch and we'll try to help out with any problems you have. > Interestingly, python didn't puke on not being able to load the ssl lib > unless I did the import directly; I would have thought I'd be given the > library error when running try-ark. That's my fault. The way I determine if PyXML is there or not is to try and import it while catching import exceptions. If I get one I presume it isn't there and silently move on to using the builtin minidom implementation. One day Python will get its act together regarding XML and we can make this sort of nonsense go away. Jonathan -- jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451 |
|
From: Luke A. K. <lu...@ma...> - 2002-09-26 05:35:14
|
Okay, I've made some progress now. I had to link my make into /usr/bin, since I didn't feel like looking for where to change that, and like I said I had to set my LD_LIBRARY_PATH, although that was a Python/PyXML problem, not an Arusha problem. Of course I'm running into new problems--textutils isn't compiling, for instance--but the main point is that it is actually doing something. My next step is to read some of the docs on how this all works, so I have plenty of time to think about it while I'm in Europe. Luke -- I never think of the future. It comes soon enough. --Albert Einstein |
|
From: Luke A. K. <lu...@ma...> - 2002-09-26 00:54:24
|
On Wed, 25 Sep 2002, Jonathan Hogg wrote:
> On 25/9/2002 6:14, Luke A. Kanies wrote:
>
> > parsing: /home/luke/ark/madstop/team.xml (minidom)
>
> Aha. This isn't using PyXML. If it had been it would say "(new PyXML)".
> Either PyXML isn't where it should be, or our logic to find it is failing.
>
> Try running the following at a Python prompt:
>
> >>> import xml.dom.ext.reader.Sax
That did it. For some retarded reason, my PyXML compiled with ssl
support, but can't find it during loading. Uh, huh?
I set the LD_LIBRARY_PATH and it all worked, but that's obviously not the
long term solution.
Definitely being hampered by the total lack of knowledge of how python
does stuff, but I guess I'll get it figured out.
I'm still having some issues, but at least it compiles now.
Interestingly, python didn't puke on not being able to load the ssl lib
unless I did the import directly; I would have thought I'd be given the
library error when running try-ark.
I'll keep you posted. If I can figure this out, I hope to spend some time
figuring out how it all actually works.
Luke
--
SELF-EVIDENT, adj. Evident to one's self and to nobody else.
-- Ambrose Bierce
|
|
From: Shprentz, J. [C] <Shp...@ni...> - 2002-09-25 20:51:48
|
Yesterday I wrote: > I finally had a chance to try installing Arusha on a > sacrificial virgin machine. Here are a few notes from > my trials ... > > ... > > At the end of the day, Arusha is installed. Tomorrow I > will rip it out and confirm that the installation can run > from start to finish without error. That worked! Arusha installed itself without error. Now I am ready to start installing packages. I notice that sidai/ALL.xml defines a process dependent on Arusha-installed versions of gzip, tar, gcc, and md5sum (from textutils). I had better install those first. Let's see ... gcc needs texinfo, texinfo needs tar, tar needs gcc. Uh oh! Only a handful of Sidai packages rely on preArusha-installed software (designated, for example, GNU-MAKE-BOOT): binutils, gcc, gzip, texinfo, and textutils. In addition to the documented prerequisite software gcc, Perl, and Python (with PyXml), they require GNU make and md5sum. They expect Arusha-installed tar and gzip. My next three steps are: 1. Install additional prerequisite software: gzip, GNU make, GNU tar, and md5sum. 2. Identify a core set of initial packages. 3. Modify those packages to make explicit their interdependencies and to use preinstalled software where needed. -- Joel Shprentz National Imagery and Mapping Agency Mailstop N-17 Washington Navy Yard, Building 213 1200 First Street, SE Washington, DC 20303-0001 202-685-3534 |
|
From: Will P. <pa...@dc...> - 2002-09-25 16:30:58
|
> P.S. What is a Jimmy Wig?
Easy one first -- here's Matt and I (make that {L-to-R} "I
and Matt"?) at LISA last year:
http://www.dcs.gla.ac.uk/~matt/tams1.jpg
Those of a sensitive disposition or possessed of any good
taste of any kind: spare yourself, don't take a peek.
(The things we do for geekdom...)
Will
|
|
From: Luke A. K. <lu...@ma...> - 2002-09-25 15:27:32
|
On Wed, 25 Sep 2002, Shprentz, Joel [C] wrote:
> Will,
>
> Your mention of a "Jimmy Wig" reminds me that although we converse in
> English, we may not share a common vocabulary.
As far as I can remember (which currently extends at least until
yesterday), it is similar to a clown wig. My guess is that the "Jimmy"
reference is to Jimi Hendrix, because it was a bit of a psychodelic 'fro,
but I'm only guessing.
> Now I wonder whether a package is a bundle of binary digits or a bundle of
> small pieces.
My guess is that it is a bundle of small pieces; there's not point in
bundling individual bits in anything but a file at a time, and those are
usually called "files", not "bundles". Thus, it would follow that a
bundle would be a bundle of related files.
Plus, we've pretty much abstracted the whole "digital bit" thing these
days. I've never yet had to move actual little bits anywhere in my
five-odd years as a sysadmin, and I'd be surprised if a bundling
mechanism's main goal was to bundle individual bits....
Luke
--
Today at work an ethernet switch decided to take the 'N' out of NVRAM
-- Richard Letts
|
|
From: Shprentz, J. [C] <Shp...@ni...> - 2002-09-25 15:18:41
|
Will, Your mention of a "Jimmy Wig" reminds me that although we converse in English, we may not share a common vocabulary. The term "bits" appears throughout the Arusha documentation. For example, on the "Arusha Project package management" page <http://ark.sourceforge.net/pkg-mgmt.html#terminology>, you define a package in terms of bits: "A 'package' is a logically coherent bundle of bits promulgated by a team that represent some sysadmin 'added value.'" As an American working with computers, I assumed that these bits were binary digits--literally the ones and zeroes that compose a package. Then my British neighbor spoke of needing some bits to repair his car. Now I wonder whether a package is a bundle of binary digits or a bundle of small pieces. P.S. What is a Jimmy Wig? -- Joel Shprentz National Imagery and Mapping Agency Mailstop N-17 Washington Navy Yard, Building 213 1200 First Street, SE Washington, DC 20303-0001 202-685-3534 |
|
From: Shprentz, J. [C] <Shp...@ni...> - 2002-09-25 14:51:23
|
Yes, you may use the notes and patches however you like. I am lobbying my management for approval to attend LISA. -----Original Message----- From: Will Partain [mailto:pa...@dc...] Sent: Wednesday, September 25, 2002 5:28 AM To: Shprentz, Joel [C] Cc: ark...@li... Subject: Re: Installing Arusha on a new site (long, but dull) Joel writes: > I finally had a chance to try installing Arusha on a sacrificial > virgin machine. Here are a few notes from my trials ... Joel, those notes are *magificent*; assuming it's OK with you, I'll fold those into the docs and/or fix the bugs :-) Many thanks, Will PS: Going to be at LISA by any chance? |
|
From: Jonathan H. <jon...@on...> - 2002-09-25 13:43:02
|
On 25/9/2002 12:39, Will Partain wrote: > Looking at the documentation Jeez, that's a radical idea ;-) Jonathan -- jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451 |
|
From: Will P. <pa...@dc...> - 2002-09-25 11:39:08
|
> Perhaps it's a change in minidom? Looking at the error again: > > File "./ark/xmlfile.py", line 722, in zero_attributes > if len(node.attributes) != 0: > TypeError: len() of unsized object > > I have a suspicion that 'node.attributes' is something other than a > collection. ... Looking at the documentation (sorry :-) [http://www.python.org/doc/current/lib/dom-node-objects.html], you can get None for non-elements (e.g. a Text node or a Comment node). Luke, if you want to stick in the odd bit of debugging (temporarily), in ARK/arkbase/ark/xmlfile.py, you could stick in the print statement at... print >>sys.stderr, 'node=',child.nodeName,child.nodeType (fname, fval) = _read_cooked_resource( child, filename ) That should show what kind of funny DOM node is popping up. Jonathan's tweak may work, but we kinda need to know *why* such things are happening. (Remember to clear off your old .xmla files in between trying things [e.g. switching parsers]: cd $ark && find . -name \*.xmla -print | xargs /bin/rm ) Will |
|
From: Jonathan H. <jon...@on...> - 2002-09-25 10:45:17
|
On 25/9/2002 11:18, Will Partain wrote:
> I am not aware of knowingly changing that stuff; are you
> *sure* that the builtin 2.x minidom thing really worked? I
> personally haven't seen a non-PyXML ARK ever working...
Hmmm. I'm pretty sure it worked when I wrote it. I tried it out on a few
platforms at the time. But that was over a year ago so it's all pretty fuzzy
now. Staring at the CVS-annotated source shows that the portions touched in
the stack trace haven't changed since the dawn of time (i.e., revision 1.1).
Perhaps it's a change in minidom? Looking at the error again:
File "./ark/xmlfile.py", line 722, in zero_attributes
if len(node.attributes) != 0:
TypeError: len() of unsized object
I have a suspicion that 'node.attributes' is something other than a
collection. Perhaps it is being set to 'None' if there are no attributes? A
sensible thing might be to try changing that line to:
if node.attributes and len(node.attributes) != 0:
...
and see if the error goes away. You could give this a go, Luke, if you feel
up to it. However, that still leaves the question of why ARK is using the
builtin minidom implementation instead of the PyXML one...
Jonathan
--
jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd
http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451
|
|
From: Will P. <pa...@dc...> - 2002-09-25 10:43:21
|
Hmm... tried the minidom thing (forced it w/ the change
below) -- this is a Python 2.2.1 -- and it worked just fine.
Oh well, keep fishing...
Will
diff -u -1 -r1.30 xmlfile.py
--- xmlfile.py 11 Feb 2002 10:22:05 -0000 1.30
+++ xmlfile.py 25 Sep 2002 10:38:47 -0000
@@ -136,25 +136,33 @@
# since the xml.version_info variable is not a reliable indicator.
- try:
- # Try for a PyXML implementation first, starting with
- # the new-style PyXML first (>= 0.5.6):
- import xml.dom.ext.reader.Sax
- doc = xml.dom.ext.reader.Sax.FromXmlStream(open(filename))
- if ark.control.ArkControl().debug(ark.control.PARSING):
- sys.stderr.write(' (new PyXML)\n')
- except ImportError:
- try:
- # No luck there, so try the old-style PyXML (probably
- # 0.5.5.1):
- import xml.dom.core
- import xml.dom.utils
- doc = xml.dom.utils.FileReader().readFile(filename)
- if ark.control.ArkControl().debug(ark.control.PARSING):
- sys.stderr.write(' (old PyXML)\n')
- except ImportError:
- # Last ditch, do we have a modern Python (>= 2.0) with
- # a minidom implementation:
- import xml.dom.minidom
- doc = xml.dom.minidom.parse( open(filename) )
- if ark.control.ArkControl().debug(ark.control.PARSING):
- sys.stderr.write(' (minidom)\n')
+
+ # Last ditch, do we have a modern Python (>= 2.0) with
+ # a minidom implementation:
+ import xml.dom.minidom
+ doc = xml.dom.minidom.parse( open(filename) )
+ if ark.control.ArkControl().debug(ark.control.PARSING):
+ sys.stderr.write(' (minidom)\n')
+
+# try:
+# # Try for a PyXML implementation first, starting with
+# # the new-style PyXML first (>= 0.5.6):
+# import xml.dom.ext.reader.Sax
+# doc = xml.dom.ext.reader.Sax.FromXmlStream(open(filename))
+# if ark.control.ArkControl().debug(ark.control.PARSING):
+# sys.stderr.write(' (new PyXML)\n')
+# except ImportError:
+# try:
+# # No luck there, so try the old-style PyXML (probably
+# # 0.5.5.1):
+# import xml.dom.core
+# import xml.dom.utils
+# doc = xml.dom.utils.FileReader().readFile(filename)
+# if ark.control.ArkControl().debug(ark.control.PARSING):
+# sys.stderr.write(' (old PyXML)\n')
+# except ImportError:
+# # Last ditch, do we have a modern Python (>= 2.0) with
+# # a minidom implementation:
+# import xml.dom.minidom
+# doc = xml.dom.minidom.parse( open(filename) )
+# if ark.control.ArkControl().debug(ark.control.PARSING):
+# sys.stderr.write(' (minidom)\n')
|
|
From: Will P. <pa...@dc...> - 2002-09-25 10:18:34
|
> Aha. This isn't using PyXML. ... Hey, we have a suspect! (a very *guilty* suspect :-) > [As an aside: Will, something must have changed in the parsing code such > that it no longer works with the builtin Python 2.x minidom implementation.] I am not aware of knowingly changing that stuff; are you *sure* that the builtin 2.x minidom thing really worked? I personally haven't seen a non-PyXML ARK ever working... (Snooping around ahead...) Will |
|
From: Will P. <pa...@dc...> - 2002-09-25 09:27:51
|
Joel writes: > I finally had a chance to try installing Arusha on a sacrificial > virgin machine. Here are a few notes from my trials ... Joel, those notes are *magificent*; assuming it's OK with you, I'll fold those into the docs and/or fix the bugs :-) Many thanks, Will PS: Going to be at LISA by any chance? |
|
From: Jonathan H. <jon...@on...> - 2002-09-25 06:49:48
|
On 25/9/2002 6:14, Luke A. Kanies wrote: > parsing: /home/luke/ark/madstop/team.xml (minidom) Aha. This isn't using PyXML. If it had been it would say "(new PyXML)". Either PyXML isn't where it should be, or our logic to find it is failing. Try running the following at a Python prompt: >>> import xml.dom.ext.reader.Sax Another test you can try is: >>> import xml >>> xml.__version__ 0.7.1 [As an aside: Will, something must have changed in the parsing code such that it no longer works with the builtin Python 2.x minidom implementation.] Jonathan -- jonathan hogg, one good idea ltd, 131 queen margaret dr., glasgow g20 8pd http://www.onegoodidea.com/ tel:+44-(0)7976-614338 fax:+44-(0)7970-537451 |
|
From: Luke A. K. <lu...@ma...> - 2002-09-25 05:14:08
|
On Tue, 24 Sep 2002, Will Partain wrote:
> PS, Luke: when re-running, perhaps safer to run with
> ARK_DEBUG=15 (setenv ARK_DEBUG 15, if a csh kinda guy).
Here's the output again:
luke@kirby:~/ark/madstop $ ARK_DEBUG=15 try-ark/try-ark 2>&1 | tee ark.out
try-ark/try-ark: warning: this script may be overly paranoid and, um,
wrong...
+ ./arkcmd package reveal --verbose --use-deps=max arkbase
parsing: /home/luke/ark/madstop/team.xml (minidom)
Traceback (most recent call last):
File "./arkcmd", line 86, in ?
main()
File "./arkcmd", line 73, in main
things_mgr.doToolSubcommand()
File "./ark/thing.py", line 240, in doToolSubcommand
victims = self.unpackSpecs(ark_ctrl.cmdLineNonOptions())
File "./ark/thing.py", line 139, in unpackSpecs
thing = self.lookup(thing_name,team_id)
File "./ark/thing.py", line 75, in lookup
team_id = ark.team.ACTING_TEAM().id
File "./ark/team.py", line 65, in ACTING_TEAM
_ActingTeam.instance = ArkTeam(acting_team_id)
File "./ark/team.py", line 149, in __init__
(self._is_prototype, xml_version, self._xmlf) =
xml_file.read(explicit_filename="%s/team.xml" %
(ark.control.ArkControl().repository(team_id)))
File "./ark/xmlfile.py", line 201, in read
(fname, fval) = _read_cooked_resource( child, filename )
File "./ark/xmlfile.py", line 320, in _read_cooked_resource
zero_attributes(res)
File "./ark/xmlfile.py", line 722, in zero_attributes
if len(node.attributes) != 0:
TypeError: len() of unsized object
luke@kirby:~/ark/madstop $
It always fails on the same line, and I can't read python yet.
> Uh, could you also remove any/all .xmla files? (pickled ARK
> .xml files)
There weren't any.
> One thing we'll definitely want to check is how .xml files
> made their way through the python/pyxml gauntlet, and
> ARK_DEBUG=15 will report that. Thanks,
It will if we get that far, but we aren't. There's no difference in
output with or without debugging set.
--
"The optimist proclaims that we live in the best of all possible worlds,
and the pessimist fears that this is true."
-- James Branch Cabell 1879-1958
|
|
From: Luke A. K. <lu...@ma...> - 2002-09-25 05:12:32
|
On Tue, 24 Sep 2002, Will Partain wrote: > Following up on Luke's bug report... > > I must now rather sheepishly admit that it's been a few > months since I ran 'try-ark' myself, and, yes, some things > were busted :-( :-( > > I have checked in some fixes to CVS (teams sidai and > sample1). If you are sucking on CVS [a reasonable > thing...], then just 'cvs update' those two teams. Did this, recreated my team.xml and kirby.xml files from the new files, and still get the exact same output. I can resend it if you want... > Alternatively, all the needful changes are below. For your > own team (based on sample1), be *sure* that host/ALL.xml has > fields for <GNU-TAR> and <SUDO>, even if you don't have gnu > tar or sudo :-) -- just as I did in the sample1 version. Yep, I checked that, and they're both there. > .ark_profile that you use; I use one that looks like > > #begin > # partain's ARK profile when sample1'ing > team = sample1 > > repository[ARK] = /workspace/partain/ark/ARK > repository[sample1] = /workspace/partain/ark/sample1 > repository[sidai] = /workspace/partain/ark/sidai > #end Yep, that's basically what mine looks like. I can mess with it some more if you give me an idea... It's basically not even compiling or something (I don't know python's compile/run modes), so it's not Arusha that's failing but the code itself. -- "The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly goes wrong goes wrong it usually turns out to be impossible to get at or repair." -- Douglas Adams, Mostly Harmless |
|
From: Shprentz, J. [C] <Shp...@ni...> - 2002-09-24 22:39:43
|
I finally had a chance to try installing Arusha on a sacrificial virgin machine. Here are a few notes from my trials ... I installed Solaris 2.8 on a Netra t1 connected to a private network. This will be the gold server, so I named it gold. The two local disk partitions are / and /._disk1. Prerequisite software gcc, Perl, and Python (with PyXml) were installed in /usr/local, their default locations. I unpacked the Arusha tarballs and decided to check everything into CVS before proceeding. I installed CVS in /usr/local. Following the Sidai team notes on booting ARK stuff, I copied and modified the sidai/sysadmin-utils/add-perhost-ark-dirs.sample script. I changed OWNER from partain to shprentj. I ran the script and admired the results. The Arusha documentation is a little sketchy on what to do next. I studied the sample1 team and its try-ark script to understand the installation of Arusha by Arusha. Try-ark performs a number of sanity checks and then runs the distribution copy to reveal a working copy. The key lines are near the bottom of the script: cd $ARK_SRC/ARK/arkbase ./arkcmd package reveal --verbose --use-deps=max arkbase < /dev/null I copied this script and renamed it setup-ark-on-gold. I removed some of the code specific to maintaining a test environment. In the sample1 team, revealing arkbase requires ALL.xml and three packages (ark-prereq-utils.xml, ark-site-gen.xml, and arkbase.xml). I copied newer versions of these package files from the verilab2 team to the package directory of my own team. In the host directory, I copied ALL.xml, sparc-solaris.xml, sparc-solaris8.xml, std-sparc-solaris.xml, sun-ultra60.xml, and hermione.xml from verilab2. I renamed sun-ultra60.xml to sun-netra-t1.xml and hermione.xml to gold.xml to match our equipement. I edited these files, making the obvious network address changes, etc. Finally (I hoped), I copied the verilab2 team.xml file to my team.xml. I delete the <site-spec><table> stuff for now. A few edits were needed: contacts, ARK_SRC, ark-sysadmin-group, and ark-sysadmin-group-must-be. I proudly ran setup-ark-on-gold and learned that "ARK_PROFILE file not where it is expected." Oops. I created ~/.ark_profile and defined the ARK_PROFILE environment variable. On the next run, I learned that my primary group must match the group specified by ark-sysadmin-group-must-be. I corrected that in /etc/passwd, logged out, logged in, and ran setup-ark-on-gold again. After defining my ARK_PROFILE environment variable again, Arusha ran (a little). it was time to delve into Arusha. Arusha complained that a "CVS entry is badly formed." I had checked in the Arusha distributions with the -ko option to retain the original CVS keyword expansions. This displeased event.py. Index: ARK/arkbase/ark/event.py =================================================================== RCS file: /d/cvs/arusha/arusha/ARK/arkbase/ark/event.py,v retrieving revision 1.1.1.1 diff -r1.1.1.1 event.py 283c283 < if len(words) != 6 or words[0] != '' or words[4] != '' or words[5] != '\n': --- > if len(words) != 6 or words[0] != '' or words[4] not in ['', "-ko"] or words[5] != '\n': My next challenge was understanding why Arusha complained about directories like /our/.-ark-deploy, which were not mentioned in add-perhost-ark-dirs.sample or the HTML documentation. The explanation was that verilabs2 lists different directories than glasli1 or the documentation. I "corrected" the deploy directories in team.xml: Index: gateway/team.xml =================================================================== RCS file: /d/cvs/arusha/arusha/gateway/team.xml,v retrieving revision 1.1 diff -r1.1 team.xml 23,24c23,24 < <entry name="OUR_DEPLOY"> /our/.-ark-deploy </entry> < <entry name="ROOT_DEPLOY"> /.-ark-deploy </entry> --- > <entry name="OUR_DEPLOY"> /.-ark-deploy </entry> > <entry name="ROOT_DEPLOY"> /.-ark-deploy-root </entry> As Arusha installed itself, it created three new directories in /d: ark-builds, ark-gen-pkg, and ark-state. It had some trouble creating /d/ark-gen-pkg/arkbase because /d/ark-gen-pkg had not yet been created. Following the approach used elsewhere, I added -p to the mkdir options. Note that if /d is an automount point, as recommended, these directories should be defined before installing Arusha. Index: ARK/ark-site-gen/Makefile.in =================================================================== RCS file: /d/cvs/arusha/arusha/ARK/ark-site-gen/Makefile.in,v retrieving revision 1.1.1.1 diff -r1.1.1.1 Makefile.in 65,66c65 < $(MKDIR) $(arkbase_dir) < $(MKDIR) $(arkbase_dir)/ark --- > $(MKDIR) -p $(arkbase_dir)/ark I was installing Arusha on a virgin machine, but Arusha was configured to look for tar, gcc, and other programs in the places where it would later install them. Some packages specified a boot version of these utilities, but, perversely, these three basic Arusha packages did not. A few parameter definitions fixed these problems (at the rate of one parameter per run). Index: sidai/package/ark-prereq-utils.xml =================================================================== RCS file: /d/cvs/arusha/arusha/sidai/package/ark-prereq-utils.xml,v retrieving revision 1.1.1.1 diff -r1.1.1.1 ark-prereq-utils.xml 48a49,54 > <create-golden-copy> > <param name="TAR">@proxy-host:GNU-TAR-BOOT@</param> > <param name="SUDO">no-sudo-for-me</param> > </create-golden-copy> > > <!-- ..................................................... --> Index: sidai/package/ark-site-gen.xml =================================================================== RCS file: /d/cvs/arusha/arusha/sidai/package/ark-site-gen.xml,v retrieving revision 1.1.1.1 diff -r1.1.1.1 ark-site-gen.xml 90a91,96 > <create-golden-copy> > <param name="TAR">@proxy-host:GNU-TAR-BOOT@</param> > <param name="SUDO">no-sudo-for-me</param> > </create-golden-copy> > > <!-- ..................................................... --> 101a108,111 > <param name="cc">@proxy-host:CC-BOOT@</param> > <param name="cflags">@proxy-host:CFLAGS-BOOT@</param> > <param name="cxx">@proxy-host:CXX-BOOT@</param> > <param name="cppflags">@proxy-host:CPPFLAGS-BOOT@</param> Index: gateway/package/arkbase.xml =================================================================== RCS file: /d/cvs/arusha/arusha/gateway/package/arkbase.xml,v retrieving revision 1.1 diff -r1.1 arkbase.xml 15a16,47 > > <!-- ..................................................... --> > <compile> > <param name="MAKE">@proxy-host:MAKE-BOOT@</param> > <param name="cc">@proxy-host:CC-BOOT@</param> > <param name="cxx">@proxy-host:CXX-BOOT@</param> > <param name="cppflags">@proxy-host:CPPFLAGS-BOOT@</param> > <param name="cflags">@proxy-host:CFLAGS-BOOT@</param> > <param name="ldflags">@proxy-host:LDFLAGS-BOOT@</param> > </compile> > > <!-- in case it decides to compile something...(timestamp problems) --> > <install-bits> > <param name="MAKE">@proxy-host:MAKE-BOOT@</param> > <param name="cc">@proxy-host:CC-BOOT@</param> > <param name="cxx">@proxy-host:CXX-BOOT@</param> > <param name="cppflags">@proxy-host:CPPFLAGS-BOOT@</param> > <param name="cflags">@proxy-host:CFLAGS-BOOT@</param> > <param name="ldflags">@proxy-host:LDFLAGS-BOOT@</param> > </install-bits> > > <!-- ..................................................... --> > <create-golden-copy> > <param name="TAR">@proxy-host:GNU-TAR-BOOT@</param> > <param name="SUDO">no-sudo-for-me</param> > </create-golden-copy> > > <!-- ..................................................... --> > <create-manifest> > <param name="MD5SUM">@proxy-host:MD5SUM-BOOT@</param> > </create-manifest> > I'm not sure that these entries are in the right place, but they worked. I will soon find out how they play on the second host. Actually, they worked only after I fixed some definitions in my hosts/ALL.xml file. Apparently I do not have a decent gcc yet. Index: gateway/host/ALL.xml =================================================================== RCS file: /d/cvs/arusha/arusha/gateway/host/ALL.xml,v retrieving revision 1.1 114,118c114,115 < <!-- used to be: @team:ark-dirs:ARK_BOOT@/bin/gcc --> < <!-- and @team:ark-dirs:ARK_BOOT@/bin/g++ --> < <!-- but we have a decent gcc now, so lets use it --> < <CC-BOOT>/our/bin/gcc</CC-BOOT> < <CXX-BOOT>/our/bin/g++</CXX-BOOT> --- > <CC-BOOT>@team:ark-dirs:ARK_BOOT@/bin/gcc</CC-BOOT> > <CXX-BOOT>@team:ark-dirs:ARK_BOOT@/bin/g++</CXX-BOOT> 186a184 > <GNU-TAR-BOOT>/usr/bin/tar</GNU-TAR-BOOT> At the end of the day, Arusha is installed. Tomorrow I will rip it out and confirm that the installation can run from start to finish without error. -- Joel Shprentz National Imagery and Mapping Agency Mailstop N-17 Washington Navy Yard, Building 213 1200 First Street, SE Washington, DC 20303-0001 202-685-3534 |
