Re: BREAKING NEWS: Debian developers aren't trusted

[Francesco P. Lovergine]

On Sun, Feb 11, 2007 at 10:38:42PM +0100, Mike Hommey wrote:
> On Sun, Feb 11, 2007 at 10:59:41PM +0200, Kalle Kivimaa <[EMAIL PROTECTED]> 
> wrote:
> > Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > > The context doesn't make the above quote any more pleasant.
> > 
> > Well, in an ideal world everybody trusts everybody, but unfortunately
> > the world we live in is not ideal. And I'm not sure what's so
> > newsworthy in the fact that one developer doesn't trust another,
> > unless you think that a DPL should trust every DD.
> 
> Considering any DD has the ability to introduce any kind of malware
> and/or kill (almost) any debian.org server, yes, a little bit of trust
> would be a minimum.
> 

There are different levels of trusting. One can think that no DD
would introduce malware in the archive and anyway could think also that some 
developers
are not good for certain tasks because of attitude/lack of skills/lack of 
time/whatever.

-- 
Francesco P. Lovergine


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Anthony Towns]

On Mon, Feb 12, 2007 at 10:15:51AM +0100, Francesco P. Lovergine wrote:
> > Considering any DD has the ability to introduce any kind of malware
> > and/or kill (almost) any debian.org server, yes, a little bit of trust
> > would be a minimum.
> There are different levels of trusting. One can think that no DD
> would introduce malware in the archive and anyway could think also that some 
> developers are not good for certain tasks because of attitude/lack of 
> skills/lack of time/whatever.

Or simply because they don't accept/respect/understand the goals other
people are trying to achieve.

There's no need for everyone to do that for all goals Debian developers
have, but if you're going to do things that interfere with others' goals
for the distro, you do have to take some care. If you're not willing to
take that degree of care, or find some way of achieving your goals that
doesn't affect other folks work, you'll find you won't be trusted. That
shouldn't be surprising.

And yes, sometimes it might be better to accept that what you want to do
interfers with other people's directions and do it anyway. But it's not
fair or reasonable to expect other people to like it, or not to rethink
how they work with you.

Cheers,
aj



signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Stephen Gran]

This one time, at band camp, Yaroslav Halchenko said:
> On Sun, 11 Feb 2007, Stephen Gran wrote:
> > ballombe has already found differences between an emulated environment
> > and a real cpu, where the test suite failed on qemu and passed on a real
> > cpu.  I have no confidence that it can't fail the other way.
> I am sorry - could you please refer to that case?

It was a mail to -devel, and I mispoke, it was aranym, not qemu, although
I don't think that invalidates the point.  I no longer have the msg id,
sorry, although it was a recent email, and should be easy enough to find.

> it is interesting to see if the problem doesn't lie in some obfuscated
> bug withing build tools. In my experience valgrind complains about so
> much of the code shipped, especially on non-i386 architectures
> obviously. Some incorrect memory read/write could successfully pass
> without segfaulting on real but fail on emulated machine, or vice
> versa - just a matter of luck. That would not invalidate build process
> on emulated box, imho I would even consider it another QA test more for
> the build tools involved than to QEMU ;)

It could certainly be a bug in the toolchain, or a bug in the emulator,
or a bug in the original source code.  I'm not really sure it matters,
though.  Increasing the likelihood of building bad binaries for little
gain doesn't seem like a good risk vs. gain assessment to me.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: BREAKING NEWS: Debian developers aren't trusted

[Josselin Mouette]

Le lundi 12 février 2007 à 19:35 +1000, Anthony Towns a écrit :
> > There are different levels of trusting. One can think that no DD
> > would introduce malware in the archive and anyway could think also that 
> > some 
> > developers are not good for certain tasks because of attitude/lack of 
> > skills/lack of time/whatever.
> 
> Or simply because they don't accept/respect/understand the goals other
> people are trying to achieve.

Could you explain which goals the buildd administrators are trying to
achieve that Aurélien doesn't accept/respect/understand, and for which
he shouldn't be trusted?

> There's no need for everyone to do that for all goals Debian developers
> have, but if you're going to do things that interfere with others' goals
> for the distro, you do have to take some care. If you're not willing to
> take that degree of care, or find some way of achieving your goals that
> doesn't affect other folks work, you'll find you won't be trusted. That
> shouldn't be surprising.
> 
> And yes, sometimes it might be better to accept that what you want to do
> interfers with other people's directions and do it anyway. But it's not
> fair or reasonable to expect other people to like it, or not to rethink
> how they work with you.

Intellectual masturbation. Again, what are you talking about?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.

DPL: maybe

[Raphael Hertzog]

Hello,

if you follow -project, you know that I have the project to present myself
for the DPL election this year provided that I can setup a good DPL board.
See http://lists.debian.org/debian-project/2007/02/msg00061.html

I have privately contacted some people that I would like to see on such a
board. However the board can always be expanded, so if you :
- have a good experience of Debian's internal working
- can be active during one year
- can constructively discuss issues even with people who you're
  disagreeing with
- have time to spend to implement improvement propositions that we might
  be doing 

... then feel free to propose yourself and explain me why you believe you
would be a good addition to the DPL board. 

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[MJ Ray]

Martin Schulze <[EMAIL PROTECTED]> wrote:
> Julien BLACHE wrote:
> > Could be at the request of the Project, via a GR I think, if the DPL
> > was, say, unwilling to act and fix a broken situation wrt
> > infrastructure administration and developer access to the said
> > infrastructure.
> 
> Unlikely.  SPI usually has a defined authorisationship with an associated
> project, this refers to people, not the project as a whole or their
> developers or their internal voting results.  However, a GR should be
> able to kick the DPL out of leadership and the next vote would install
> a new DPL who would then have a say.

That's almost the opposite of my understanding: SPI refers to projects
and their decision-making as a whole, not particular people in them.

SPI says the following on project management:

Each Project has its own formal or informal internal structure and
procedures. SPI will not interfere in the internal decision making
of Projects, unless this is requested by the Project or its rules and
procedures. [+2 more paragraphs]
http://www.spi-inc.org/corporate/resolutions/2004-08-10-iwj.1

What says SPI only listens to the DPL, not the project?  AIUI, the DPL
is appointed as an adviser to SPI's board, not a veto.

Puzzled,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Yaroslav Halchenko]

> It was a mail to -devel, and I mispoke, it was aranym, not qemu,
;-) ok - getting closer to the true story here, but unfortunately I
could not locate any 'failed build' email in the -devel from him within
any reasonable timeframe where he would mentioned failed build. But I've
found
http://lists.debian.org/debian-devel/2006/12/msg00084.html
where he describes "quite reliable" setup ;-)

> It could certainly be a bug in the toolchain, or a bug in the emulator,
> or a bug in the original source code.  I'm not really sure it matters,
> though.  Increasing the likelihood of building bad binaries for little
> gain doesn't seem like a good risk vs. gain assessment to me.
yikes... if you got a bad apple it doesn't mean that an orange in the
near-by basket is rotten as well... 

The discussion is either it is as reliable to use emulator (QEMU in
particular) as the real box. You brought an example  where build process
under emulator failed. I mentioned that it might be not emulator false
but build chain and you pretty much agree to that. So how that
brings emulator under question of its equivalence in terms of building
packages to the real box?

And actually failed build is better IMHO than ok-build using flawed
build tool, since it allows to detect/debug/eliminate the problem.
So, to summarize, is possible to extract now from your statement
that real arch promotes building 'bad binaries' ;-)

-- 
  .-.
=--   /v\  =
Keep in touch// \\ (yoh@|www.)onerussian.com
Yaroslav Halchenko  /(   )\   ICQ#: 60653192
   Linux User^^-^^[17]



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

Re: [GR] DD should be allowed to perform binary-only uploads

[Stephen Gran]

This one time, at band camp, Yaroslav Halchenko said:
> > It was a mail to -devel, and I mispoke, it was aranym, not qemu,
> ;-) ok - getting closer to the true story here, but unfortunately I
> could not locate any 'failed build' email in the -devel from him within
> any reasonable timeframe where he would mentioned failed build. But I've
> found
> http://lists.debian.org/debian-devel/2006/12/msg00084.html
> where he describes "quite reliable" setup ;-)

The message is here:
http://lists.debian.org/debian-devel/2007/02/msg00241.html

> > It could certainly be a bug in the toolchain, or a bug in the emulator,
> > or a bug in the original source code.  I'm not really sure it matters,
> > though.  Increasing the likelihood of building bad binaries for little
> > gain doesn't seem like a good risk vs. gain assessment to me.
> yikes... if you got a bad apple it doesn't mean that an orange in the
> near-by basket is rotten as well... 
> 
> The discussion is either it is as reliable to use emulator (QEMU in
> particular) as the real box. You brought an example  where build process
> under emulator failed. I mentioned that it might be not emulator false
> but build chain and you pretty much agree to that. So how that
> brings emulator under question of its equivalence in terms of building
> packages to the real box?
> 
> And actually failed build is better IMHO than ok-build using flawed
> build tool, since it allows to detect/debug/eliminate the problem.
> So, to summarize, is possible to extract now from your statement
> that real arch promotes building 'bad binaries' ;-)

Er, you seem to have read what I said backwards, so perhaps I wasn't
clear.  I am saying that if the emulated environment can be shown to
differ from a real CPU in any but the most trivial of ways, I am
uncomfortable with it.  It may be a bug in the emulator, a bug in the
toolchain, or the wrong color of sacrificial goat.  When you get
different results in an emulated environment, it leads me to believe
that reproducibility will suffer.  The fact that it failed to run the
binary correctly in this failure instance is good.  But another day, it
may fail to correctly run gcc, and that would be bad if it exited 0 with
a wrongly built binary.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Wesley J. Landaker]

On Monday 12 February 2007 09:08, Stephen Gran wrote:
> [...] reproducibility will suffer.  The fact that it failed to run the
> binary correctly in this failure instance is good.  But another day, it
> may fail to correctly run gcc, and that would be bad if it exited 0 with
> a wrongly built binary.

And couldn't this just as easily happen with *real* machines with 
motherboard problems, bad memory, overheating CPUs, or, say Pentium 
floating point errors? Or—heaven forbid—a bug in the compiler or kernel, or 
incorrect build libraries. I've either had or heard of *all* of these 
things resulting in bad reproducibility or failed builds. Yet, in practice, 
these things are not really worth worrying about.

To me this just sounds like anti-emulator superstition.

-- 
Wesley J. Landaker <[EMAIL PROTECTED]> 
OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2


pgpuee1qfBRAZ.pgp
Description: PGP signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Martin Schulze]

Wesley J. Landaker wrote:
> On Monday 12 February 2007 09:08, Stephen Gran wrote:
> > [...] reproducibility will suffer.  The fact that it failed to run the
> > binary correctly in this failure instance is good.  But another day, it
> > may fail to correctly run gcc, and that would be bad if it exited 0 with
> > a wrongly built binary.
> 
> And couldn't this just as easily happen with *real* machines with 
> motherboard problems, bad memory, overheating CPUs, or, say Pentium 

2.6 kernel instead of 2.4 - happened on mips(el)? and hppa at least.
fwiw.

Regards,

Joey

-- 
Long noun chains don't automatically imply security.  -- Bruce Schneier


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Neil McGovern]

On Mon, Feb 12, 2007 at 11:58:46AM +, MJ Ray wrote:
> Martin Schulze <[EMAIL PROTECTED]> wrote:
> > Julien BLACHE wrote:
> > > Could be at the request of the Project, via a GR I think, if the DPL
> > > was, say, unwilling to act and fix a broken situation wrt
> > > infrastructure administration and developer access to the said
> > > infrastructure.
> > 
> > Unlikely.  SPI usually has a defined authorisationship with an associated
> > project, this refers to people, not the project as a whole or their
> > developers or their internal voting results.  However, a GR should be
> > able to kick the DPL out of leadership and the next vote would install
> > a new DPL who would then have a say.
> 
> That's almost the opposite of my understanding: SPI refers to projects
> and their decision-making as a whole, not particular people in them.
> 
> SPI says the following on project management:
> 
> Each Project has its own formal or informal internal structure and
> procedures. SPI will not interfere in the internal decision making
> of Projects, unless this is requested by the Project or its rules and
> procedures. [+2 more paragraphs]
> http://www.spi-inc.org/corporate/resolutions/2004-08-10-iwj.1
> 
> What says SPI only listens to the DPL, not the project?  AIUI, the DPL
> is appointed as an adviser to SPI's board, not a veto.
> 

Further down the resolution, which you snipped:
 snip 
Following informal discussions of Associated Project status with members
of the community, if satisfied the SPI Board will pass a resolution
inviting the project to become Associated with SPI.

This resolution will state the SPI Board's current understanding of who
is authorised to act for the project; it will invite the project to join
with SPI according to this Framework; and it will state a date at which
the invitation will lapse if not accepted.
 snip 

The DPL being advisor to the board is a seperate issue to them acting as
as the authorised decision maker.

Neil
-- 
 'Maybe you can try to find a nice hotel by shouting in the Mexico DF
streets "where could a gringo find a decent hotel in this dirty third
world lame excuse for a country?". I'm sure the people will rush to help
you, as we south americans love to be called third world in a demeaning 
way.'


signature.asc
Description: Digital signature

Re: [GR] DD should be allowed to perform binary-only uploads

[Manoj Srivastava]

On Mon, 12 Feb 2007 10:20:12 -0500, Yaroslav Halchenko
<[EMAIL PROTECTED]> said:  

> The discussion is either it is as reliable to use emulator (QEMU in
> particular) as the real box. You brought an example where build
> process under emulator failed. I mentioned that it might be not
> emulator false but build chain and you pretty much agree to that. So
> how that brings emulator under question of its equivalence in terms
> of building packages to the real box?

I should like to say right off that I do not have concrete
 examples of failure or differing behaviour.  But, in theory, any
 emulator is just trying to replicate the behaviour of a pievce of
 hardware, and there are potential issues with both accuracy and
 completeness of emulation. So, unless one is claiming perfect
 emulation, there is alway potential of the emulated behaviour being
 subtly different. This is especially true of computations (built
 tests, etc) that are multi threaded, or otherwise rely on
 synchronization and timing.

So I can certainly see build time testing giving very
 different results on emulated hardware as opposed to real hardware.

The greater question is, if the archive masters request
 developers not to submit packages built on emulated hardware, should
 that request not be heeded?

manoj
-- 
Wouldn't this be a great world if being insecure and desperate were a
turn-on? "Broadcast News"
Manoj Srivastava <[EMAIL PROTECTED]> 
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: [GR] DD should be allowed to perform binary-only uploads

[Clint Adams]

> The greater question is, if the archive masters request
>  developers not to submit packages built on emulated hardware, should
>  that request not be heeded?

No, why would that be within the bailiwick of the ftp-team?  If you're
going to claim that they have ultimate authority over all the bits in
the archive, then would you grant them the power to make you use
debhelper?


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Hamish Moffatt]

On Mon, Feb 12, 2007 at 07:35:49PM +1000, Anthony Towns wrote:
> On Mon, Feb 12, 2007 at 10:15:51AM +0100, Francesco P. Lovergine wrote:
> > > Considering any DD has the ability to introduce any kind of malware
> > > and/or kill (almost) any debian.org server, yes, a little bit of trust
> > > would be a minimum.
> > There are different levels of trusting. One can think that no DD
> > would introduce malware in the archive and anyway could think also that 
> > some 
> > developers are not good for certain tasks because of attitude/lack of 
> > skills/lack of time/whatever.
> 
> Or simply because they don't accept/respect/understand the goals other
> people are trying to achieve.
> 
> There's no need for everyone to do that for all goals Debian developers
> have, but if you're going to do things that interfere with others' goals
> for the distro, you do have to take some care. If you're not willing to
> take that degree of care, or find some way of achieving your goals that
> doesn't affect other folks work, you'll find you won't be trusted. That
> shouldn't be surprising.

This is a two-way street though. Aurelien was trying to solve a problem
he perceived to exist with the arm port. His solution has been rejected,
but is the original problem being addressed?

Frankly I think ftp-master abused his dual roles (ftp-master and arm
buildd admin) in this incident; any one else's actions would have been
subject to peer review.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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

Re: New General resolution proposed

[Don Armstrong]

[Please respond back to -vote where this belongs, not here.]

On Mon, 12 Feb 2007, Joe Buck wrote:
> Right now, those who run auto-builders are trusted, but the GR
> proposes to trust all developers. Right?

It doesn't really change anything because nothing stops you as a
developer from uploading binary packages which do not correspond to
the source which you have uploaded.


Don Armstrong

-- 
Where I sleep at night, is this important compared to what I read
during the day? What do you think defines me? Where I slept or what I
did all day?
 -- Thomas Van Orden of Van Orden v. Perry

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


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

Re: [GR] DD should be allowed to perform binary-only uploads

[MJ Ray]

Neil McGovern <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 12, 2007 at 11:58:46AM +, MJ Ray wrote:
> > What says SPI only listens to the DPL, not the project?  AIUI, the DPL
> > is appointed as an adviser to SPI's board, not a veto.
> 
> Further down the resolution, which you snipped:
>  snip 
> Following informal discussions of Associated Project status with members
> of the community, if satisfied the SPI Board will pass a resolution
> inviting the project to become Associated with SPI.
> 
> This resolution will state the SPI Board's current understanding of who
> is authorised to act for the project; it will invite the project to join
> with SPI according to this Framework; and it will state a date at which
> the invitation will lapse if not accepted.
>  snip 

Yes, but sorry if this question was unclear: What says SPI only listens to
the DPL, not the project?

For example, what is the relevance of the above copy-pasted block?
Does debian's invitation state that only the DPL is authorised to act,
or is the Secretary authorised to act by sending other decisions to SPI,
or is this an undefined thing that the spi-board are showing public
unity about, or something else?

If only the DPL is authorised to act in SPI's eyes, is that SPI interfering
in the decision-making of the project?  (by ignoring most of the processes)

In case anyone hasn't noticed, it seems very difficult to get anything
like a straight answer out of most of the current SPI board lately.  Try
it for yourself.  Fun for all the debian family.  Knock one over, win a
coconut and five tons of flax!
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: BREAKING NEWS: Debian developers aren't trusted

[Anthony Towns]

On Tue, Feb 13, 2007 at 07:56:36AM +1100, Hamish Moffatt wrote:
> This is a two-way street though. Aurelien was trying to solve a problem
> he perceived to exist with the arm port. His solution has been rejected,
> but is the original problem being addressed?

] I am really upset by the way the ARM build daemons are managed. The
] packages are not uploaded regularly, with sometimes three days between
] two uploads. [...]
]
] All of that resulted in ARM being the slowest architecture to build
] packages. [...]

-- http://blog.aurel32.net/?p=33

I don't imagine Aurelien's any less upset, but as far as I can see, there
aren't actual problems with the way arm's keeping up at present:

http://buildd.debian.org/stats/graph2-quarter-big.png

The current "out of dates" according to britney are:

  4 i386
 13 amd64
 25 sparc
 32 arm
 38 alpha
 45 powerpc
 47 mipsel
 49 mips
 55 s390
 56 m68k
 82 hppa
 86 ia64

Which likewise seems to indicate arm isn't an issue.

As far as demonstrating the plausibility of setting up emulated buildds is
concerned, I don't think it makes any sense to do that by working on the
live archive for a release architecture. Personally, I've been trying to
promote emulated buildds since at least 2005, but you do that by diving
in yourself and producing a demo, not taking a release architecture with
you and having its users have to tread water with you if you turn out
to be wrong and have to find some way to undo it.

> Frankly I think ftp-master abused his dual roles (ftp-master and arm
> buildd admin) in this incident; any one else's actions would have been
> subject to peer review.

Uh, what's this if not peer review?

In addition, I reviewed both changes, and am not a buildd admin, though
I do share Steve's ability to do give-backs.

Cheers,
aj



signature.asc
Description: Digital signature

Re: BREAKING NEWS: Debian developers aren't trusted

[Hamish Moffatt]

On Tue, Feb 13, 2007 at 02:18:12PM +1000, Anthony Towns wrote:
> On Tue, Feb 13, 2007 at 07:56:36AM +1100, Hamish Moffatt wrote:
> > This is a two-way street though. Aurelien was trying to solve a problem
> > he perceived to exist with the arm port. His solution has been rejected,
> > but is the original problem being addressed?
> 
> ] I am really upset by the way the ARM build daemons are managed. The
> ] packages are not uploaded regularly, with sometimes three days between
> ] two uploads. [...]
> ]
> ] All of that resulted in ARM being the slowest architecture to build
> ] packages. [...]
> 
> -- http://blog.aurel32.net/?p=33
> 
> I don't imagine Aurelien's any less upset, but as far as I can see, there
> aren't actual problems with the way arm's keeping up at present:

Another problem is that the buildd email mailbox is apparently piped to
/dev/null.

> > Frankly I think ftp-master abused his dual roles (ftp-master and arm
> > buildd admin) in this incident; any one else's actions would have been
> > subject to peer review.
> 
> Uh, what's this if not peer review?

A proper process would be that the buildd admin / porter (person 1)
would observe a problem and ask ftp-master (person 2) to reject those
uploads; if both people agree it would happen.

It's not peer review when we discuss it later and none of us (including
you) have any power to do anything about it, except via long drawn-out
political processes.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>


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