Re: can buildd logs be sorted (again)?

2008-11-27 Thread Adeodato Simó
* Thomas Viehmann [Mon, 24 Nov 2008 20:20:13 +0100]:

 Adeodato Simó wrote:
  I fixed this to sort entries by age, HTH.

  Thomas: I didn't have the PHP-energy to look at integrating your patch
  at this stage, prod me about it in the future if you'd like.

 Well, I cannot blame you. I do not intend to keep it lying around when
 it's not used, though. Sorry if I should have done more than just
 dumping the ready-to-use php somewhere.

Thomas pointed out that there are cases where sorting by timestamp is
suboptimal (eg. where there are t-p-u uploads involved), so at some
point I'll look into mergin his patch.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
If there is a sin against life, it consists perhaps not so much in
despairing of life as in hoping for another life and in eluding the
implacable grandeur of this life.
-- Albert Camus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-11-24 Thread Adeodato Simó
* Steve M. Robbins [Wed, 29 Oct 2008 01:42:06 -0500]:

 Hi,

 The buildd log pages, e.g. [1], used to be sorted by package version
 (or maybe build date).  However that is no longer the case.

 Can this be fixed?  The current situation is less than useful since
 the latest build is buried in other output.

 Thanks,
 -Steve

 [1] http://buildd.debian.org/build.php?pkg=boost 

I fixed this to sort entries by age, HTH.

Thomas: I didn't have the PHP-energy to look at integrating your patch
at this stage, prod me about it in the future if you'd like.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Testing can show the presence of bugs, but not their absence.
-- Dijkstra


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-11-24 Thread Thomas Viehmann
Adeodato Simó wrote:
 I fixed this to sort entries by age, HTH.

 Thomas: I didn't have the PHP-energy to look at integrating your patch
 at this stage, prod me about it in the future if you'd like.

Well, I cannot blame you. I do not intend to keep it lying around when
it's not used, though. Sorry if I should have done more than just
dumping the ready-to-use php somewhere.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-11-24 Thread Steve M. Robbins
On Mon, Nov 24, 2008 at 08:04:46PM +0100, Adeodato Sim?? wrote:
 * Steve M. Robbins [Wed, 29 Oct 2008 01:42:06 -0500]:
 
  Hi,
 
  The buildd log pages, e.g. [1], used to be sorted by package version
  (or maybe build date).  However that is no longer the case.
 
  Can this be fixed?  The current situation is less than useful since
  the latest build is buried in other output.
 
  Thanks,
  -Steve
 
  [1] http://buildd.debian.org/build.php?pkg=boost 
 
 I fixed this to sort entries by age, HTH.

Yes!  Thanks very much.

-Steve


signature.asc
Description: Digital signature


Re: can buildd logs be sorted (again)?

2008-11-02 Thread Thomas Viehmann
Raphael Geissert wrote:
 So, let's test it with a script I wrote during DC8 (as suggested by Lucas):
Thanks to Raphael's test suite, the (mainly regarding the not fully
parenthesized succession of ( ? : ), but also treating empty Debian
revisions), the comparision now works for all valid versions he tests.

 I will later test udd's perl implementation just to make sure it is ok 
 (although
 I believe it's PET's which is not perfect either).
Mind you, I'd think that arbitrary (consistent) sorting is better than
failing in a way that screws language-provided sort functions in most
practical applications.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-11-01 Thread Raphael Geissert
Neil Williams wrote:

 On Thu, 2008-10-30 at 20:02 -0600, Raphael Geissert wrote:
 [1] I promised Christoph Berg that I am going to write a PHP extension,
 [actually
 an interface, to libapt's functions; but I haven't been lucky enough to find
 the docs (libapt-pkg-doc isn't what I expected). If somebody can point me to
 the right documents it would be great.
 
 libapt-pkg-doc is what there is, apart from the source. Recursion is a
 constant nightmare with the perl bindings for apt so you have to be very
 careful in your debugging cases for the PHP version. Take a look at
 libcache-apt-perl for a sane way to handle at least some of the apt
 bindings with safe recursion. I've no idea whether that design could
 work in PHP but it is (hopefully) clearer than the docs for the bindings
 themselves.
 
 You might also want to look at the source code for edos-debcheck and
 other routines that do dependency iterations etc.
 
 Note that there *is* a PHP interface to the Packages.gz file itself -
 see Emdebian SVN:

http://buildd.emdebian.org/svn/browser/current/website/trunk/english/toolchains
 
[...]

Thanks for the pointers :)

I'm not actually trying to provide a complete binding, but just a couple of
methods that would let PHP scripts access the information without having to
write their own wheel. So by that I guess that there won't be any recursion
issue :)

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-31 Thread Neil Williams
On Thu, 2008-10-30 at 20:02 -0600, Raphael Geissert wrote:
 [1] I promised Christoph Berg that I am going to write a PHP extension, 
 actually
 an interface, to libapt's functions; but I haven't been lucky enough to find
 the docs (libapt-pkg-doc isn't what I expected). If somebody can point me to
 the right documents it would be great.

libapt-pkg-doc is what there is, apart from the source. Recursion is a
constant nightmare with the perl bindings for apt so you have to be very
careful in your debugging cases for the PHP version. Take a look at
libcache-apt-perl for a sane way to handle at least some of the apt
bindings with safe recursion. I've no idea whether that design could
work in PHP but it is (hopefully) clearer than the docs for the bindings
themselves.

You might also want to look at the source code for edos-debcheck and
other routines that do dependency iterations etc.

Note that there *is* a PHP interface to the Packages.gz file itself -
see Emdebian SVN:
http://buildd.emdebian.org/svn/browser/current/website/trunk/english/toolchains

//
// PHP Apt-file parser, Version 1.2
//
// The following PHP functions parse Debian APT-repository files
// (Packages.gz, Sources.gz) and generate an XHTML summary of them.
//
// Written by Jarno Elonen in 2003, 2004

#  Copyright (c) 2003-2006 Jarno Elonen [EMAIL PROTECTED]

Working examples:
http://www.emdebian.org/toolchains/search.php

http://www.emdebian.org/packages/search.php

http://www.emdebian.org/locale/search.php

(Actually all are the same file with different configurations passed to
parse-apt.)

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/




signature.asc
Description: This is a digitally signed message part


Re: can buildd logs be sorted (again)?

2008-10-30 Thread Adeodato Simó
* Thomas Viehmann [Thu, 30 Oct 2008 00:11:09 +0100]:

 If someone could attest to
   http://buildd.debian.org/~tviehmann/cmp_versions_php.txt
 (translated from the perl that udd uses) being wrong in only harmless
 ways (except showing that C-Perl-PHP with the last step being done by
 someone disliking PHP is not a good idea), I could ask Ryan to put
   http://buildd.debian.org/~tviehmann/build.php
 in the appropriate location.

If acceptable, an easier option could perhaps be to just sort all the
package/*/timestamp_arch_log files globally by timestamp.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Listening to: Matthew Kimball - I don't need


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-30 Thread Martín Ferrari
Hi,

On Wed, Oct 29, 2008 at 21:11, Thomas Viehmann [EMAIL PROTECTED] wrote:

 Can this be fixed?  The current situation is less than useful since
 the latest build is buried in other output.

 If someone could attest to
  http://buildd.debian.org/~tviehmann/cmp_versions_php.txt
 (translated from the perl that udd uses) being wrong in only harmless
 ways (except showing that C-Perl-PHP with the last step being done by
 someone disliking PHP is not a good idea), I could ask Ryan to put
  http://buildd.debian.org/~tviehmann/build.php
 in the appropriate location.

If it's of any use, the PET project has a implementation from scratch
of Debian version comparison, made by reading policy and dpkg code.
The only bug I know of is that it doesn't reject some invalid
versions.

-- 
Martín Ferrari


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-30 Thread Raphael Geissert
Adam D. Barratt wrote:
 
 In this specific case, he was already CCed on Steve's mail which began
 this thread...

Didn't notice it, sorry for the noise.

 
 Adam

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-30 Thread Raphael Geissert
Thomas Viehmann wrote:

 Hi,
 
 Steve M. Robbins wrote:
 The buildd log pages, e.g. [1], used to be sorted by package version
 (or maybe build date).  However that is no longer the case.
 
 It seems that build.php relies on the results of opendir/readdir to be
 in order and that assumption not being valid anymore.
 
 Can this be fixed?  The current situation is less than useful since
 the latest build is buried in other output.
 
 If someone could attest to
   http://buildd.debian.org/~tviehmann/cmp_versions_php.txt
 (translated from the perl that udd uses) being wrong in only harmless
 ways (except showing that C-Perl-PHP with the last step being done by
 someone disliking PHP is not a good idea), I could ask Ryan to put
   http://buildd.debian.org/~tviehmann/build.php
 in the appropriate location.

Nice, yet another rewrite of dpkg's code, but now in PHP[1].

So, let's test it with a script I wrote during DC8 (as suggested by Lucas):

8-8
buildd.php failed test 'foo- foo 0'/tests/foo with '1'
buildd.php failed test 'foo fo 1'/tests/foo with '-1'
buildd.php failed test 'foo- foo+ -1'/tests/foo with '1'
buildd.php failed test 'foo~1 foo -1'/tests/foo with '1'
buildd.php failed test 'foo.bar foo1bar 1'/tests/foo with '-1'
buildd.php failed test 'foo.bar foo0bar 1'/tests/foo with '-1'
buildd.php failed test '1foo:bar 1:bar x This is a syntax violation so the
result is undetermined but shouldn't be any of these: -1 0 1'/tests/foo
with '-1'
buildd.php failed test '1foo-1 foo-1 -1'/tests/foo with '1'
buildd.php failed test '0.8.0a-1 0.8.0-2 1 gnunet'/tests/versions.lenny-sid
with '-1'
buildd.php failed test '0.8.0a-1 0.8.0-1 1 gnunet-gtk'/tests/versions.lenny-sid
with '-1'
buildd.php reached the 10 tolerated failures
The remaining tests will be skipped
8-8

With regard to the '1foo:bar 1:bar' test: this test is usually passed when the
versions comparing function returns null (in PHP terms), making the 'case'
script exit with a non-zero status. In your implementation I see parseversion
returning null when it encounters an invalid version, but cmp_version doesn't
care about it.

The tests are in a version1 version2 expected_result comments-format.

I will later test udd's perl implementation just to make sure it is ok (although
I believe it's PET's which is not perfect either).

[1] I promised Christoph Berg that I am going to write a PHP extension, actually
an interface, to libapt's functions; but I haven't been lucky enough to find
the docs (libapt-pkg-doc isn't what I expected). If somebody can point me to
the right documents it would be great.

 
 Kind regards
 
 T.

Cheers,
Raphael Geissert



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-30 Thread Raphael Geissert
Martín Ferrari wrote:
[...]
 
 If it's of any use, the PET project has a implementation from scratch
 of Debian version comparison, made by reading policy and dpkg code.
 The only bug I know of is that it doesn't reject some invalid
 versions.
 

To be more precise:

$ ./test pet.pl
pet.pl failed test 'foo- foo 0'/tests/foo with '1'
pet.pl failed test 'foo- foo+ -1'/tests/foo with '1'
pet.pl failed test '1foo:bar 1:bar x This is a syntax violation so the result
is undetermined but shouldn't be any of these: -1 0 1'/tests/foo with '-1'
pet.pl failed 3 over 731 tests

@Martín[OT]: hope you can find some time to write an email, probably addressed
to [EMAIL PROTECTED], about your proposed version=4 watch files; as I'm
about to write down my proposed watch file format specs.

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



can buildd logs be sorted (again)?

2008-10-29 Thread Steve M. Robbins
Hi,

The buildd log pages, e.g. [1], used to be sorted by package version
(or maybe build date).  However that is no longer the case.

Can this be fixed?  The current situation is less than useful since
the latest build is buried in other output.

Thanks,
-Steve

[1] http://buildd.debian.org/build.php?pkg=boost 

The database contains build logs for the following versions of boost:

* 1.31.0-3 (alpha) (latest build at Apr 12 15:49: maybe-successful)
* 1.31.0-3 (powerpc) (latest build at Apr 12 15:51: maybe-successful)
* 1.31.0-3 (hppa) (latest build at Apr 12 17:13: maybe-successful)
* 1.31.0-3 (ia64) (latest build at Apr 12 15:42: maybe-successful)
* 1.31.0-3 (m68k) (latest build at Apr 13 01:05: maybe-successful)
* 1.31.0-3 (arm) (latest build at Apr 12 18:08: maybe-successful)
* 1.31.0-3 (mips) (latest build at Apr 12 19:11: maybe-successful)
* 1.31.0-3 (sparc) (latest build at Apr 12 18:16: maybe-successful)
* 1.31.0-3 (mipsel) (latest build at Apr 12 17:08: maybe-successful)
* 1.31.0-3 (s390) (latest build at Apr 12 15:54: maybe-successful)
* 1.26.0-3 (powerpc) (latest build at Jan 27 00:21: maybe-successful)
* 1.26.0-3 (arm) (latest build at Jan 27 00:50: maybe-successful)
* 1.26.0-3 (alpha) (latest build at Feb 2 21:57: maybe-failed)
* 1.26.0-3 (sparc) (latest build at Jan 27 00:15: maybe-successful)
* 1.33.1-5 (ia64) (latest build at Jul 20 17:24: maybe-successful)
* 1.33.1-5 (alpha) (latest build at Jul 20 22:27: maybe-successful)
* 1.33.1-5 (mips) (latest build at Jul 20 18:52: maybe-successful)
* 1.33.1-5 (arm) (latest build at Jul 22 11:24: maybe-failed)
* 1.33.1-5 (mipsel) (latest build at Jul 20 18:47: maybe-successful)
* 1.33.1-5 (hppa) (latest build at Jul 20 20:38: maybe-successful)
* 1.33.1-5 (powerpc) (latest build at Jul 20 18:55: maybe-successful)
* 1.33.1-5 (amd64) (latest build at Jul 20 16:31: maybe-successful)
* 1.33.1-5 (s390) (latest build at Jul 20 17:13: maybe-successful)
* 1.33.1-5 (m68k) (latest build at Jul 25 01:09: maybe-successful)
* 1.33.1-5 (sparc) (latest build at Jul 20 20:10: maybe-successful)
* 1.29.0-1 (powerpc) (latest build at Oct 29 19:32: maybe-successful)
* 1.29.0-1 (arm) (latest build at Oct 29 22:05: maybe-successful)
* 1.29.0-1 (s390) (latest build at Oct 31 18:45: maybe-successful)
* 1.29.0-1 (alpha) (latest build at Oct 29 21:44: maybe-successful)
* 1.29.0-1 (ia64) (latest build at Oct 29 20:02: maybe-successful)
* 1.29.0-1 (hppa) (latest build at Oct 29 19:05: maybe-successful)
* 1.29.0-1 (m68k) (latest build at Oct 30 07:43: maybe-successful)
* 1.29.0-1 (sparc) (latest build at Oct 29 21:32: maybe-successful)
* 1.33.0-5 (arm) (latest build at Nov 23 18:05: maybe-successful)
* 1.33.0-5 (ia64) (latest build at Nov 23 02:31: maybe-successful)
* 1.33.0-5 (hppa) (latest build at Dec 14 18:33: maybe-failed)
* 1.33.0-5 (sparc) (latest build at Nov 23 01:40: maybe-successful)
* 1.33.0-5 (s390) (latest build at Nov 23 00:56: maybe-successful)
* 1.33.0-5 (alpha) (latest build at Nov 23 09:25: maybe-successful)
* 1.33.0-5 (m68k) (latest build at Nov 27 17:59: maybe-successful)
* 1.33.0-5 (mipsel) (latest build at Nov 23 03:51: maybe-successful)
* 1.33.0-5 (mips) (latest build at Nov 23 13:19: maybe-successful)
* 1.33.0-5 (powerpc) (latest build at Nov 23 00:27: maybe-successful)
* 1.31.0-4 (powerpc) (latest build at Apr 15 10:55: maybe-successful)
* 1.31.0-4 (sparc) (latest build at Apr 15 11:33: maybe-successful)
* 1.31.0-4 (ia64) (latest build at Apr 15 10:44: maybe-successful)
* 1.31.0-4 (hppa) (latest build at Apr 15 10:55: maybe-successful)
* 1.31.0-4 (m68k) (latest build at Apr 15 22:37: maybe-successful)
* 1.31.0-4 (mipsel) (latest build at Apr 15 12:02: maybe-successful)
* 1.31.0-4 (arm) (latest build at Apr 15 13:21: maybe-successful)
* 1.31.0-4 (mips) (latest build at Apr 15 12:50: maybe-successful)
* 1.31.0-4 (alpha) (latest build at Apr 15 10:49: maybe-successful)
* 1.31.0-4 (s390) (latest build at Apr 15 11:07: maybe-successful)
* 1.33.1-2 (m68k) (latest build at Jan 21 06:48: maybe-successful)
* 1.33.1-2 (mips) (latest build at Jan 11 19:46: maybe-successful)
* 1.33.1-2 (sparc) (latest build at Jan 14 21:09: maybe-successful)
* 1.33.1-2 (mipsel) (latest build at Jan 11 19:26: maybe-successful)
* 1.33.1-2 (arm) (latest build at Jan 13 10:54: maybe-successful)
* 1.33.1-2 (hppa) (latest build at Jan 11 21:04: maybe-successful)
* 1.33.1-2 (s390) (latest build at Jan 11 18:09: maybe-successful)
* 1.33.1-2 (powerpc) (latest build at Jan 11 19:22: maybe-successful)
* 1.33.1-2 (ia64) (latest build at Jan 11 18:09: maybe-successful)
* 1.33.1-2 (alpha) (latest build at Jan 11 18:41: maybe-successful)
* 1.33.1-4 (m68k) (latest build at May 8 22:20: maybe-successful)
* 1.33.1-4 (sparc) (latest build at Mar 

Re: can buildd logs be sorted (again)?

2008-10-29 Thread Peter Palfrader
On Wed, 29 Oct 2008, Patrick Matthäi wrote:

 Steve M. Robbins schrieb:
  Hi,
  
  The buildd log pages, e.g. [1], used to be sorted by package version
  (or maybe build date).  However that is no longer the case.
  
  Can this be fixed?  The current situation is less than useful since
  the latest build is buried in other output.
 
 You should report a bug against qa.debian.org / www.debian.org.

Neither of those is the correct contact/package regarding
buildd.debian.org.  I guess we don't have a metapackage for w-b and
buildd.d.o.  Maybe eventually that will be fixed.

weasel
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-29 Thread Raphael Geissert
Peter Palfrader wrote:

 On Wed, 29 Oct 2008, Patrick Matthäi wrote:
 
 You should report a bug against qa.debian.org / www.debian.org.
 
 Neither of those is the correct contact/package regarding
 buildd.debian.org.  I guess we don't have a metapackage for w-b and
 buildd.d.o.  Maybe eventually that will be fixed.

*cough*, what about contacting Ryan Murray? he is the one listed at buildd.d.o

 
 weasel

Cheers,
Raphael Geissert


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-29 Thread Adam D. Barratt
On Wed, 2008-10-29 at 12:47 -0600, Raphael Geissert wrote:
 Peter Palfrader wrote:
 
  On Wed, 29 Oct 2008, Patrick Matthäi wrote:
  
  You should report a bug against qa.debian.org / www.debian.org.
  
  Neither of those is the correct contact/package regarding
  buildd.debian.org.  I guess we don't have a metapackage for w-b and
  buildd.d.o.  Maybe eventually that will be fixed.
 
 *cough*, what about contacting Ryan Murray? he is the one listed at buildd.d.o

In this specific case, he was already CCed on Steve's mail which began
this thread...

Adam


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-29 Thread Don Armstrong
On Wed, 29 Oct 2008, Peter Palfrader wrote:
 Neither of those is the correct contact/package regarding
 buildd.debian.org. I guess we don't have a metapackage for w-b and
 buildd.d.o. Maybe eventually that will be fixed.

If whoever would be responsible for it files a wishlist bug asking for
it to be created along with contact information and a brief blurb
describing the psuedopackage against bugs.debian.org, it will be
created.


Don Armstrong

-- 
Nothing is as inevitable as a mistake whose time has come.
 -- Tussman's Law

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Re: can buildd logs be sorted (again)?

2008-10-29 Thread Thomas Viehmann
Hi,

Steve M. Robbins wrote:
 The buildd log pages, e.g. [1], used to be sorted by package version
 (or maybe build date).  However that is no longer the case.

It seems that build.php relies on the results of opendir/readdir to be
in order and that assumption not being valid anymore.

 Can this be fixed?  The current situation is less than useful since
 the latest build is buried in other output.

If someone could attest to
  http://buildd.debian.org/~tviehmann/cmp_versions_php.txt
(translated from the perl that udd uses) being wrong in only harmless
ways (except showing that C-Perl-PHP with the last step being done by
someone disliking PHP is not a good idea), I could ask Ryan to put
  http://buildd.debian.org/~tviehmann/build.php
in the appropriate location.

Kind regards

T.
-- 
Thomas Viehmann, http://thomas.viehmann.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]