ark-dev — Arusha Project development and discussion list

Arusha Project release 20050419

[Will P. <pa...@dc...>]

I have just done another full release of all the public Arusha Project
stuff.  Wander to http://sourceforge.net/projects/ark for the bits,
or to http://ark.sourceforge.net/ for slightly-tweaked Web pages.

This is a maintenance release with a year's worth of bits. It includes
support for Solaris 10 and Fedora Core (3, at time of writing),
including the latter on x86_64.  There is initial support for NFSv4,
and for ARK repositories kept under Subversion.

In case you've forgotten: the Arusha Project (ARK) provides a
framework for collaborative system administration of multi-platform
Unix sites with many dozens of machines.

If any of you need help exploring or thinking about Arusha Project
stuff, or have "it would be great if..." ideas, please speak up or get
in touch.

Will

FYI: conary (a distributed software management system)

[Will P. <pa...@dc...>]

Folks - the [very new] Conary system, by some ex-Red Hat
people, strikes me as Arusha-compatible in its thinking, and
laden with Good Ideas.  I'll include the Freshmeat
announcement below; also, there's a good intro at lwn.net,
though it may be a few more days before it comes out of
"subscriber-only" purgatory.

Will

From: co...@fr...
Subject: Conary 0.2  - A distributed software management system.
Newsgroups: fm.announce
Date: Wed, 28 Jul 2004 20:48:57 +0000 (UTC)

Conary 0.2  
  by Michael K. Johnson (http://freshmeat.net/~johnsonm/)
  Wed, Jul 28th 2004 13:48 

About:
Conary is a distributed software management system for Linux distributions.
It replaces traditional package management solutions (such as RPM and dpkg)
with one designed to enable loose collaboration across the Internet. It
enables sets of distributed and loosely connected repositories to define
the components which are installed on a Linux system. Rather then having a
full distribution come from a single vendor, it allows administrators and
developers to branch a distribution, keeping the pieces which fit their
environment while grabbing components from other repositories across the
Internet. 

Changes:
New repository wire protocol, bug fixes 

Release focus: Initial freshmeat announcement 
      License: Common Public License 
  Project URL: http://freshmeat.net/projects/conary/

            Homepage: http://freshmeat.net/redir/conary/52115/url_homepage/technology
             Tar/BZ2: http://freshmeat.net/redir/conary/52115/url_bz2/conary-0.2.tar.bz2
   CVS tree (cvsweb): http://freshmeat.net/redir/conary/52115/url_cvs/cvs.specifixinc.com
Mailing list archive: http://freshmeat.net/redir/conary/52115/url_list/conary-list

xml2hostconf

[Erik <eri...@ho...>]

Hi,

You have a nice collection of links to infrastructure tools for system
administration at:

http://ark.sourceforge.net/related.html

I would be very glad if you included a link to
http://xml2hostconf.sourceforge.net 

A description could for instance be:

xml2hostconf is a collection of xslt scripts that generate rpm packages,
dhcpd.conf, grub files, kickstart files and html documentation. A system
administrator of a redhat linux network can specify the setup of all the
computers in a single xml file. Each computer will be given its own
"virtual" rpm package. The generated rpm packages might have
dependencies and they might also contain configuration files. 


I did a comparison between xml2hostconf and ark on
http://xml2hostconf.sourceforge.net/links.html

<snip>
Ark provides a framework for collaborative system administration of
multi-platform Unix sites with many dozens of machines. xml2hostconf
just delivers host configuration files to the clients by means of
generated rpm packages. Ark on the other hand delivers whole packages (
binaries + configuration files ) to the client by means of compilation
from source code. Ark can therefore be used as a layer above many
different unix variants. xml2hostconf is limited to only redhat linux
distributions. Like xml2hostconf do, Ark also uses xml files as
configuration format. xml2hostconf can use its own configuration files
to generate html documentation. I didn't see that feature in Ark. Ark
has a bigger scope and tries to solve more things than xml2hostconf, but
on the other hand seems more complex. It has roughly 7 times as many
lines of source code than xml2hostconf. License: GPL. Programming
language: Python 
</snip>


Do you find it a fair comparison? 
Did I understand Ark correctly?

cheers,
Erik Sjölund

Arusha Project release 20040529

[Will P. <pa...@dc...>]

I have just done another full release of all the public
Arusha Project stuff.  Wander to
http://sourceforge.net/projects/ark for the bits.

The sole reason for this release is to change from the GPL
to the BSD license.

In case you've forgotten: the Arusha Project (ARK) provides
a framework for collaborative system administration of
multi-platform Unix sites with many dozens of machines.

If any of you need help exploring or thinking about Arusha
Project stuff, or have "it would be great if..." ideas,
please speak up or get in touch.

Will

Arusha Project release 20040526

[Will P. <pa...@dc...>]

I have just done a full release of all the public Arusha
Project stuff (teams: ARK, arksf1, glasli1, sample1, sidai,
simple1, verilab2).  The release notes are below.  Wander to
http://sourceforge.net/projects/ark for the bits.

In case you've forgotten: the Arusha Project (ARK) provides
a framework for collaborative system administration of
multi-platform Unix sites with many dozens of machines.

Between October and now, there has been normal-ish ongoing
and undramatic progress.  The main impending change is from
the GNU Public License (GPL) to the standard BSD license;
this is the last [planned] release under the GPL.  I have
been unable to think of anyone who will be adversely
affected by this change.

If any of you need help exploring or thinking about Arusha
Project stuff, or have "it would be great if..." ideas,
please speak up or get in touch.

Will

== release notes =======================================

This is the last version of the core teams' code licensed
under the GPL; the next and subsequent versions (soon?) will
be under the BSD license.

In the Sidai code, we have the first code to manipulate ARK
state events (event-utils/lsevents); the 'sync-replica' tool
can now use rdiff-backup as well as rsync; we have new
packages to install Mozilla and Eclipse binaries, and for
Subversion and (retro-tool...)  DVIutils from source; plus
many small enhancements.

In the Verilab2 code, we have sample CUPS support.

Worried About Having A Little Tiny Diick? ceylon fulvous chalky

[Nina J. <qsr...@ne...>]

dither thysanura haunted swindler 
adieu barmaster ponytail aspiration definition stingless placable considered january greenbelt japan plasma debts dogs 

super-great off-er for all softwares from 15 dollar

[Iluminada R. <fyl...@zo...>]

unduly ligno epistyle bluffness muscadet lightless philippic frigid 
farina bumps ardea neonate christen chromatin realgar precincts barbasco flyer cyathea beglerbeg hour perforator colpocele 
whoredom detonation oiled chanar fohn givenness mundi azide fistfight ardea spermary clonic cypripedia bezant quasar oximeter 

Re: Client alpha.

[Tommy K. <tom...@ve...>]

Ah, go on Jonathan.  Let us play too.
What is it that's in alpha?

:-)

t

----- Original Message ----- 
From: "Jonathan Hogg" <jon...@se...>
To: "ARK Development" <ar...@li...>
Sent: Wednesday, February 04, 2004 5:21 PM
Subject: Re: Client alpha.


> On 4 Feb 2004, at 15:18, Jonathan Hogg wrote:
> 
> > Congratulations all, we are now in alpha for the client.
> >
> > Please read the alpha procedure <http://homer/swswiki/AlphaProcedure> 
> > for an explanation on how to work on bugs.
> 
> Heh. Wrong development mailing list I think.
> 
> Still, I think a toast is in order since we made it to alpha even if 
> you guys didn't ;-)
> 
> Jonathan
> 
> -- 
> Jonathan Hogg
> Director, Technology
> 
> Seventh Wave Systems Ltd.
> 28-30 Worship Street
> London EC2A 2AH
> Telephone: +44 20 7127 9779
> 
> <http://www.seventh-wave-systems.com/>
> 

Re: Client alpha.

[Jonathan H. <jon...@se...>]

On 4 Feb 2004, at 15:18, Jonathan Hogg wrote:

> Congratulations all, we are now in alpha for the client.
>
> Please read the alpha procedure <http://homer/swswiki/AlphaProcedure> 
> for an explanation on how to work on bugs.

Heh. Wrong development mailing list I think.

Still, I think a toast is in order since we made it to alpha even if 
you guys didn't ;-)

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
28-30 Worship Street
London EC2A 2AH
Telephone: +44 20 7127 9779

<http://www.seventh-wave-systems.com/>

Client alpha.

[Jonathan H. <jon...@se...>]

Congratulations all, we are now in alpha for the client.

Please read the alpha procedure <http://homer/swswiki/AlphaProcedure> 
for an explanation on how to work on bugs.

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
28-30 Worship Street
London EC2A 2AH
Telephone: +44 20 7127 9779

<http://www.seventh-wave-systems.com/>

Re: non-gcc dependency flags

[Will P. <pa...@dc...>]

Edward Moy wrote:

> However, I would thing that fixing the "busted
> dependencyFlags" would be a useful future enhancement,
> particularly given the variety of unices out there.

I have hacked substantially on dependencyFlags in
ARK/arkbase/ark/thing.py to make this change fairly
painless.  There are many matching changes in the Sidai
package files (and perhaps elsewhere).  It's all checked in
to CVS.

The thing is that your <team>/host/ALL.xml now needs to
specify

  <COMPILING-STYLE>gcc</COMPILING-STYLE>

In *theory*, if you changed that to

  <COMPILING-STYLE>apple-osx-with-fuzzy-linking</COMPILING-STYLE>

(or whatever), then made suitable tweaks to dependencyFlags
(which is tidier and even slightly documented...), it would
all work.

I've successfully run try-ark with the changes, but I would
not describe the code as "tested".

Will

Re: Ximian Build Buddy

[Will P. <pa...@dc...>]

Jonathan H wrote:

> 	http://primates.ximian.com/~thunder/bb/
> 
> It builds RPMs, DEBs, and Solaris and HPUX packages.

My recollection is that this is not the first such tool.
(Check freshmeat if you really care...)  There are oodles of
interesting build(-ish) tools these days, any of which might
make an interesting Arusha substrate (which I would support
enthusiastically).

Will

Ximian Build Buddy

[Jonathan H. <jon...@se...>]

For anyone who isn't a slave to /., here's an interesting looking 
build/packaging system:

	http://primates.ximian.com/~thunder/bb/

It builds RPMs, DEBs, and Solaris and HPUX packages. I could imagine an 
interesting Arusha site where packages are pulled as source tarballs, 
built into the respective packages for the different site platforms and 
then deployed using the native package install tools.

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
<http://www.seventh-wave-systems.com/>

Re: non-gcc dependency flags

[Will P. <pa...@dc...>]

Edward Moy writes:

> However, I would thing that fixing the "busted
> dependencyFlags" would be a useful future enhancement,
> particularly given the variety of unices out there.

I agree that the present deal is a wart/hack and should be
fixed.  (Not exactly sure when I'll get to it but...)

The simplest thing would be to pass dependencyFlags a
"compiler style" parameter, 'gcc' being one possible value.
Add more as needed.  Means that dependencyFlags becomes More
Horrible, but at least it's in one place.

Anyone care to object/barf :-?

Will

Re: non-gcc dependency flags

[Edward M. <em...@ap...>]

Since I was using try-ark, I had to override <configure> and 
<install-bits> in addition to <compile>.  And since the packages, for 
example, gzip, calls sidal's gzip, which then calls GNU, and GNU 
defines <configure>, I had to put my override prototypes before calling 
sidal's gzip, rather than just adding the overrides to myteam1's ALL.

However, I would thing that fixing the "busted dependencyFlags" would 
be a useful future enhancement, particularly given the variety of 
unices out there.

Edward Moy
em...@ap...
---------------------------------------------------------------
(This messages is from me as a reader of this list, and not a statement 
from Apple.)

On Jan 27, 2004, at 3:56 AM, Will Partain wrote:

> [redirecting a thread to the list...]  An issue raised:
>
>> ... It seems that in thing.py, in dependencyFlags(), the
>> compiler/linker "-Wl,-R" is hard-coded, and our linker
>> uses a different flag.  If the 'R' case is also for the
>> linker, then that -R needs to be changed as well.  How do
>> you suggest dealing with machine-dependent complier/linker
>> flags.
>
> First: having "all the world's a GCC just like mine" wired
> into the code is palpably wrong (but convenient :-), and I
> will gladly cooperate in its correction.
>
> But it is worth thinking what you really want.  The Sidai
> Way with (shared) libraries is a bit weird [but I like it],
> and gives rise to the mess mentioned.  If you don't care for
> the Sidai Way, the quickest way forward may be simply to
> avoid it.
>
> Here's the Sidai way on libraries... (a) System libraries
> are in /lib and /usr/lib, and we don't touch them at all
> (but we do use them).  (b) For all other libraries
> (Arusha-managed), I want to _specify exactly_ what I want
> ["berkeley-db--4.2.52"], and I want that stitched together
> at build time, and I want it to _stay as it is forever_.
> (c) In particular, I do not want programs to wander to
> /usr/local/lib and pick up any old thing that they find
> lying around -- the standard behavior that many people are
> happy with.  (d) I don't want to be meddling with
> /etc/ld.so.conf -- I want the binary to know where to get
> its stuff.
>
> So the Sidai code proceeds as follows: <constraint>s specify
> dependencies on packages (which happen to provide
> libraries), and magic code (dependencyFlags) turns that
> dependency info into GCC flags that will get the right
> compiler/linker flags in at the right places.  It is, of
> course, staggering the effort that some packages go to in
> order to subvert this plan :-)
>
> If you just don't care about all of this, it's pretty easy
> to do what you want.  Imagine you have a package...
>
>    <package name="foo--1.2.3">
>
>    <prototypes>
>      <prototype team="sidai" name="ALL" />
>    </prototypes>
>
> You could add your own "what I want" layer, perhaps by
> saying...
>
>    <package name="foo--1.2.3">
>
>    <prototypes>
>      <prototype team="." name="sidai-ALL" />
>    </prototypes>
>
>    <!- ......... ->
>
>    <package name="sidai-ALL" prototype="yes">
>
>    <prototypes>
>      <prototype team="sidai" name="ALL" />
>    </prototypes>
>
>    <compile>
>       <!-- no dependencyFlags stuff for us, please -->
>       <param name="dep_iflags"></param>
>       <param name="dep_lflags"></param>
>    </compile>
>
> This is the basic Arusha idea of "same as that guy did,
> except for this bit...".
>
> Of course, maybe we need to fix the busted dependencyFlags
> ...  Let me know.

non-gcc dependency flags

[Will P. <pa...@dc...>]

[redirecting a thread to the list...]  An issue raised:

> ... It seems that in thing.py, in dependencyFlags(), the
> compiler/linker "-Wl,-R" is hard-coded, and our linker
> uses a different flag.  If the 'R' case is also for the
> linker, then that -R needs to be changed as well.  How do
> you suggest dealing with machine-dependent complier/linker
> flags.

First: having "all the world's a GCC just like mine" wired
into the code is palpably wrong (but convenient :-), and I
will gladly cooperate in its correction.

But it is worth thinking what you really want.  The Sidai
Way with (shared) libraries is a bit weird [but I like it],
and gives rise to the mess mentioned.  If you don't care for
the Sidai Way, the quickest way forward may be simply to
avoid it.

Here's the Sidai way on libraries... (a) System libraries
are in /lib and /usr/lib, and we don't touch them at all
(but we do use them).  (b) For all other libraries
(Arusha-managed), I want to _specify exactly_ what I want
["berkeley-db--4.2.52"], and I want that stitched together
at build time, and I want it to _stay as it is forever_.
(c) In particular, I do not want programs to wander to
/usr/local/lib and pick up any old thing that they find
lying around -- the standard behavior that many people are
happy with.  (d) I don't want to be meddling with
/etc/ld.so.conf -- I want the binary to know where to get
its stuff.

So the Sidai code proceeds as follows: <constraint>s specify
dependencies on packages (which happen to provide
libraries), and magic code (dependencyFlags) turns that
dependency info into GCC flags that will get the right
compiler/linker flags in at the right places.  It is, of
course, staggering the effort that some packages go to in
order to subvert this plan :-)

If you just don't care about all of this, it's pretty easy
to do what you want.  Imagine you have a package...

   <package name="foo--1.2.3">

   <prototypes>
     <prototype team="sidai" name="ALL" />
   </prototypes>

You could add your own "what I want" layer, perhaps by
saying...

   <package name="foo--1.2.3">

   <prototypes>
     <prototype team="." name="sidai-ALL" />
   </prototypes>

   <!- ......... ->

   <package name="sidai-ALL" prototype="yes">

   <prototypes>
     <prototype team="sidai" name="ALL" />
   </prototypes>

   <compile>
      <!-- no dependencyFlags stuff for us, please -->
      <param name="dep_iflags"></param>
      <param name="dep_lflags"></param>
   </compile>

This is the basic Arusha idea of "same as that guy did,
except for this bit...".

Of course, maybe we need to fix the busted dependencyFlags
...  Let me know.

Will

Re: problems with try-ark

[Edward M. <em...@ap...>]

On 14 Nov 2003, at 09:14, Jonathan Hogg wrote:

> On 14 Nov 2003, at 17:06, Sang Yi wrote:
>
>> my output's the same as yours:
>> [...]
>> any other suggestions?  meanwhile, i'll review my test drive setup
>> again... maybe i missed something
>
> Hmmm. OK, that's odd. The only other thing I can suggest is turning on
> the debugging info and seeing what that turns up just before it fails.
> You can enable that by setting the environment variable ARK_DEBUG=255
> (which will output pretty much everything).
>
> It certainly looks like a broken XML parser, but I can't figure out 
> why.

I ran into this problem as well.  Looks like it is because comments are 
being handled differently in Python 2.3.x:

% python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import xml.dom.minidom
 >>> doc = xml.dom.minidom.parseString( '<test><!-- comment --></test>' )
 >>> root = doc.documentElement
 >>> len(root.attributes)
0
 >>> children = root.childNodes
 >>> print children
[<DOM Comment node " comment ">]
 >>> len(children[0].attributes)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: len() of unsized object

I just added:

     if node.attributes == None:
         return

to zero_attributes() in ARK/arkbase/ark/xmlfile.py.

However, then I ran into:

Panic: sigh: element <#comment> is bogus

Seems that:

 >>> print children[0].nodeName
#comment

so I changed the line in _process_subfields() to:

     elif hname == 'comment' or hname == '#comment':

which then results in:

Panic: sigh: <comment> must have exactly one child node

which seems to be because comments don't have children:

 >>> children2 = children[0].childNodes
 >>> len(children2)
0

So I added:

     if len(children) == 0:
         return ''

to _process_comment().

Now, I get:

     raise 'duff code:',child.nodeName, child.nodeType
TypeError: raise: arg 3 must be a traceback or None

Seems that some of the <code> sections in sidai/package/ALL.xml use 
CDATA, and _process_code() is unhappy:

(Pdb) p children
[<DOM CDATASection node "\ncd $PKG_B...">]
(Pdb) p children[0].nodeType
4
(Pdb) p node.TEXT_NODE
3
(Pdb) p children[0].nodeValue
u'\ncd $PKG_BUILD_DIR\n\nLNDIR=`sidaiPickProgram "$LNDIR" 
"$LNDIR_BOOT"`\n\n# clear out any old symlinks that point to the wrong 
thing\n[ -d src ] && /bin/rm -rf src\n\n$MKDIR_P src\ncd src && $LNDIR 
$GEN_PKG_SRC_LOC .\n'

So I change the line in _process_code() to:

        if len(children) == 1 and (children[0].nodeType == 
node.TEXT_NODE or children[0].nodeType == node.CDATA_SECTION_NODE):

but being new to Arusha, I don't know if this is quite correct, though 
it seemed to finally get it going.  Now, I get a failure for what looks 
like a configuration error on my part.

Edward Moy
em...@ap...
---------------------------------------------------------------
(This messages is from me as a reader of this list, and not a statement 
from Apple.)

RE: Listing packages on hosts or hosts with packages

[Shprentz, J. [C] <Shp...@ng...>]

Will P writes:
> Note that the questions could be answered in two subtly
> different ways: (a) looking at what the state says [as you
> suggest], and (b) looking at the ARK source, which tells you
> what the state *should* say :-).  If you're lucky, the two
> say the same thing.

Reality (a) has a tendency to drift from the ideal (b).  Some examples:

Ideal:  installed
Actual:  missing
Reason:  Host was down when package was installed.
Another reason:  Have not run "ark package install" yet.

Ideal:  indeterminant
Actual:  missing or installed
Reason:  Packages marked "deprecated" may or may not be installed

Thanks for the script.

Re: Listing packages on hosts or hosts with packages

[Will P. <pa...@dc...>]

Joel S writes:

> We frequently are asked questions like, "What hosts have
> Perl 5.6.0 installed?" Another favorite is, "Tell me all
> the packages installed on host abcd."
> 
> Ark has answers to these questions squirreled away in
> /sys/ark-state. Is there an an ark invocation to display
> the answers?

There is as yet no known code to wander about in the
ark-state dir.

Note that the questions could be answered in two subtly
different ways: (a) looking at what the state says [as you
suggest], and (b) looking at the ARK source, which tells you
what the state *should* say :-).  If you're lucky, the two
say the same thing.

A little script [Python's easiest] of the (b) form wouldn't
be too hard.  A sample (which actually ran for glasli1) is
A little script [Python's easiest] below.

Will

#!/usr/local/bin/python

import ark.package
import ark.host

pkgsMgr  = ark.package.ArkPkgsMgr()
hostsMgr = ark.host.ArkHostsMgr()

for pkg in pkgsMgr.getAll():
    if not pkg.isRelevant(): continue
    print pkg.idString, ":",

    for host in hostsMgr.getAll():
	if not host.isRelevant(): continue
	if pkg.appliesToHost(host) != None:
	    print host.idString,
    print ''

Listing packages on hosts or hosts with packages

[Shprentz, J. [C] <Shp...@ng...>]

We frequently are asked questions like, "What hosts have Perl 5.6.0
installed?" Another favorite is, "Tell me all the packages installed on host
abcd."

Ark has answers to these questions squirreled away in /sys/ark-state. Is
there an an ark invocation to display the answers?
--

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

Re: problems with try-ark

[Jonathan H. <jon...@se...>]

On 14 Nov 2003, at 17:06, Sang Yi wrote:

> my output's the same as yours:
[...]
> any other suggestions?  meanwhile, i'll review my test drive setup
> again... maybe i missed something

Hmmm. OK, that's odd. The only other thing I can suggest is turning on 
the debugging info and seeing what that turns up just before it fails. 
You can enable that by setting the environment variable ARK_DEBUG=255 
(which will output pretty much everything).

It certainly looks like a broken XML parser, but I can't figure out why.

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
<http://www.seventh-wave-systems.com/>

RE: problems with try-ark

[Sang Y. <Sa...@Ov...>]

jonathan,
my output's the same as yours:

Python 2.3.2 (#1, Nov 12 2003, 16:24:36)=20
[GCC 2.95.2 19991024 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml.dom.minidom
>>> doc =3D xml.dom.minidom.parseString( '<test><me/></test>' )
>>> root =3D doc.documentElement
>>> len(root.attributes)
0
>>>=20
any other suggestions?  meanwhile, i'll review my test drive setup
again... maybe i missed something


> Yeah, that's the same version I have in 2.3, so I'm confused=20
> as to why=20
> it's failing. Can you try this:
>=20
> -----
>  >> import xml.dom.minidom
>  >> doc =3D xml.dom.minidom.parseString( '<test><me/></test>' )
>  >> root =3D doc.documentElement
>  >> len( root.attributes )
> 0
> -----
>=20
> Jonathan
>=20
> --=20

Re: problems with try-ark

[Jonathan H. <jon...@se...>]

On 14 Nov 2003, at 16:01, Sang Yi wrote:

> no pyXML as my version is > 1.5.2
>
> here's my output from python:
>
> Python 2.3.2 (#1, Nov 12 2003, 16:24:36)
> [GCC 2.95.2 19991024 (release)] on sunos5
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import xml
>>>> xml.__version__
> '1.13'

Yeah, that's the same version I have in 2.3, so I'm confused as to why 
it's failing. Can you try this:

-----
 >> import xml.dom.minidom
 >> doc = xml.dom.minidom.parseString( '<test><me/></test>' )
 >> root = doc.documentElement
 >> len( root.attributes )
0
-----

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
<http://www.seventh-wave-systems.com/>

RE: problems with try-ark

[Sang Y. <Sa...@Ov...>]

no pyXML as my version is > 1.5.2

here's my output from python:

Python 2.3.2 (#1, Nov 12 2003, 16:24:36)=20
[GCC 2.95.2 19991024 (release)] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import xml
>>> xml.__version__
'1.13'



-----Original Message-----
From: Jonathan Hogg [mailto:jon...@se...]
Sent: Friday, November 14, 2003 12:21 AM
To: Sang Yi
Cc: ar...@li...
Subject: Re: problems with try-ark


On 14 Nov 2003, at 01:16, Sang Yi wrote:

>   File "/home/shy2/ark-src/ARK/arkbase/ark/xmlfile.py", line 708, in=20
> zero_attributes
>     if len(node.attributes) !=3D 0:
> TypeError: len() of unsized object
>
> this was on a solaris 2.8 box with python 2.3.2
> anyone else run into this before?  thought i'd ask before i start=20
> digging through the *.py.

This is almost certainly something strange with the XML parser you are=20
using. Have you installed a particular version of PyXML? Or are you=20
just using Python bare?

ark tries to do The Right Thing with whatever XML parser you have=20
available, but it looks like the one it's chosen is broken. Can you try=20
the following things in Python and let us know what you get:

 >>> import xml
 >>> xml.__version__
'1.13'

 >>> import xml.dom.minidom
 >>> doc =3D xml.dom.minidom.parseString( '<test><me/></test>' )
 >>> root =3D doc.documentElement
 >>> len( root.attributes )
0

It's probably just another special case that we need to add to the=20
parser detection logic.

Jonathan

--=20
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
<http://www.seventh-wave-systems.com/>

Re: problems with try-ark

[Jonathan H. <jon...@se...>]

On 14 Nov 2003, at 01:16, Sang Yi wrote:

>   File "/home/shy2/ark-src/ARK/arkbase/ark/xmlfile.py", line 708, in 
> zero_attributes
>     if len(node.attributes) != 0:
> TypeError: len() of unsized object
>
> this was on a solaris 2.8 box with python 2.3.2
> anyone else run into this before?  thought i'd ask before i start 
> digging through the *.py.

This is almost certainly something strange with the XML parser you are 
using. Have you installed a particular version of PyXML? Or are you 
just using Python bare?

ark tries to do The Right Thing with whatever XML parser you have 
available, but it looks like the one it's chosen is broken. Can you try 
the following things in Python and let us know what you get:

 >>> import xml
 >>> xml.__version__
'1.13'

 >>> import xml.dom.minidom
 >>> doc = xml.dom.minidom.parseString( '<test><me/></test>' )
 >>> root = doc.documentElement
 >>> len( root.attributes )
0

It's probably just another special case that we need to add to the 
parser detection logic.

Jonathan

-- 
Jonathan Hogg
Director, Technology

Seventh Wave Systems Ltd.
<http://www.seventh-wave-systems.com/>