Re: Deadline for amendments to the GR

[Sven Luther]

On Mon, Jan 30, 2006 at 09:37:12PM -0600, Debian Project Secretary wrote:
> Hi folks,
> 
> A new amendment has made it in to the GR _after_ the two week
>  discussion deadline. If there are other people mulling proposals for
>  amendments to the GR, now is the time -- if submissions keep coming
>  in at two week intervals, voting on this GR can be delayed almost
>  indefinitely.  In order to prevent that, I would like to see any
>  changes to the GR come in soon -- say, in the next week or so, when
>  we'll close down for the rest of the discussion period, and then open
>  the door for people to call for votes.

Hi, ...

a single line telling us the title or the URL of the GR in question would have
been welcome. I guess this means there is only one GR open, but still it would
have been neat to clarify this :)

Friendly,

Sven Luther


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

Proposal: move /etc/{protocol,services,rpc} to base-files

[Daniel Schepler]

Currently there are several packages which Build-Depend on netbase just to 
have /etc/protocol and /etc/services available to run tests.  Unfortunately, 
this means that all of netbase's dependencies also need to be installed -- 
and because of bug #162581, pbuilder can't even block inetd from starting in 
its chroot, resulting in orphan inetd processes after the build is over.

So I'd like to propose moving those data files from netbase to base-files.  If 
it's decided that these files are inappropriate content for an essential 
package, I'd at least like to see something like netbase-data which could be 
installed without all the heavy dependencies of netbase.  I'd especially like 
to hear the opinions of the netbase and base-files packages' maintainers on 
this.
-- 
Daniel Schepler


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

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Marco d'Itri]

On Feb 03, Daniel Schepler <[EMAIL PROTECTED]> wrote:

> So I'd like to propose moving those data files from netbase to base-files.  
> If 
No. The correct solution is to fix netbase by moving update-inetd to
each *inetd package.
But aj does not want to do this until update-inetd will have been
rewritten, so if you care you need to fix this first.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Daniel Schepler]

Le Vendredi 03 Février 2006 13:30, Marco d'Itri a écrit :
> On Feb 03, Daniel Schepler <[EMAIL PROTECTED]> wrote:
> > So I'd like to propose moving those data files from netbase to
> > base-files.  If
>
> No. The correct solution is to fix netbase by moving update-inetd to
> each *inetd package.
> But aj does not want to do this until update-inetd will have been
> rewritten, so if you care you need to fix this first.

My main concern wasn't the orphan inetd issue, for which fixing #162581 would 
be the correct fix.  It seems to me that currently netbase is a user package 
to ensure a reasonable networking environment -- which is much more than what 
most source packages Build-Depending on netbase need.

If you're suggesting that with a move of update-inetd then netbase would 
become more like the netbase-data I was suggesting as an alternative, with 
minimal dependencies, that would be fine with me.
-- 
Daniel Schepler

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Marco d'Itri]

On Feb 03, Daniel Schepler <[EMAIL PROTECTED]> wrote:

> If you're suggesting that with a move of update-inetd then netbase would 
> become more like the netbase-data I was suggesting as an alternative, with 
> minimal dependencies, that would be fine with me.
Yes, because only the files in /etc/ would be left.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#351242: ITP: sickle -- mail filtering tool for IMAP

[Gonéri Le Bouder]

Package: wnpp
Severity: wishlist
Owner: "Gonéri Le Bouder" <[EMAIL PROTECTED]>

* Package name: sickle
  Version : 0.3 
  Upstream Author : Duncan Martin <[EMAIL PROTECTED]> 
* URL : http://www.codebunny.org/coding/sickle/
* License : BSD 
  Description : mail filtering tool for IMAP

  Sickle is a mail filtering tool. Designed to filter email before it is
  retrieved or viewed, Sickle filters on the server via IMAP. The filter
  instructions themselves are written in Perl, so benefit from the
  flexibility of the language. Sickle is not meant to be user friendly,
  and has the potential to cause data-loss if handled incorrectly. If
  you're not comfortable with Perl, best stop reading.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: sparc (sparc64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-sparc64-smp
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ANSI_X3.4-1968) (ignored: 
LC_ALL set to C)

Re: Automatic testing of .deb's

[Margarita Manterola]

Hi!

On 2/2/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I would like to have some idea what people think I should do with the
> tests that we're hopefully going to have, eventually for lots of
> packages.  Would Debian like those tests as patches in wishlist bug
> reports, in general ?  That would seem to be best to me but before I
> go down this route I'd like to be clear that that's what Debian
> developers want.

Please, do send any of these patches as wishlist bugs, so that Debian
maintainers can use the tests.

There might be some maintainer that does not like the tests, but I
think that the majority will like them, and when someone doesn't, they
can just not use the test, no harm done.

--
Besos,
Marga

Re: Automatic testing of .deb's

[Gustavo Franco]

On 2/2/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> (...)
>
> I would like to have some idea what people think I should do with the
> tests that we're hopefully going to have, eventually for lots of
> packages.  Would Debian like those tests as patches in wishlist bug
> reports, in general ?  That would seem to be best to me but before I
> go down this route I'd like to be clear that that's what Debian
> developers want.

I think you should put out a summary of how many and what packages will
be changed in Ubuntu. After that we can agree or not with automatic filling
whislist bugs (containing the patches) against Debian packages.

Since Ubuntu Dapper is actually on freeze, what's your timeline to these
patches? Will you include this stuff just on Dapper+1, in the end of
the year?

Thanks,
Gustavo Franco

Re: PHP License for PHP Group packages

[Charles Fry]

Instead I propose that all RC bugs in PHP Group software released with
the PHP License be closed.

For the record, all previous discussions of this matter on debian-legal
have suggested that the PHP License might be non-free for everything
(including PHP), but it has never been argueed that PHP itself and PHP
Group software should be treated differently with respect to the PHP
License. Inasmuch as the PHP License is currently considered free by
Debian (for PHP), I think that the closing of the PHP Group RC bugs is
appropriate, given the recent changes in the PHP License.

Charles

-Original Message-
> From: José Carlos do Nascimento Medeiros <[EMAIL PROTECTED]>
> Subject: Re: PHP License for PHP Group packages
> Date: Thu, 02 Feb 2006 15:27:53 -0200
> To: Charles Fry <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], debian-legal@lists.debian.org,
>   debian-devel@lists.debian.org
> 
> Charles,
> 
> I agree with you, but I think ftp master will not change. 
> I really do not have more time to this unfinished topic :(
> Can you adopt these packages that have RC bugs because license ?
> php-net-checkip
> php-services-weather
> 
> I will be very grateful, as this packages are dependence from anothers.
> If not,  I will ask to take off these packages from debian.
> 
> Thanks.
> Jose Carlos
> 
> 
> Em Qui, 2006-02-02 às 10:05 -0500, Charles Fry escreveu:
> > It would be most helpful if we could make some progress on this issue.
> > There are a handful of RC bugs whose maintainers are trying to work with
> > their upstream authors to find resolution. In some cases the upstream
> > authors believe that the problem should be fixed with the new PHP
> > License. It is becoming unprofessional for us not to be able to give
> > them a straight answer.
> > 
> > Once again, I repeat my claim: that the 3.01 version of the PHP License
> > is equally fit for licensing PHP itself and PHP Group software. This
> > claim has been upheld over months of sporadic discussion on the matter
> > at debian-legal.
> > 
> > Given the lack of disagreement on this issue, I would again like to
> > request that the FTP Masters update their policy to accept PHP Group
> > packages with the PHP License, in addition to PHP itself. Or in the
> > absense of a willingness to do so, please step forward so that we can
> > further this discussion and deal professionally with the upstream
> > authors of the current RC bugs related to the PHP License.
> > 
> > cheers,
> > Charles
> > 
> > -Original Message-
> > > From: Charles Fry <[EMAIL PROTECTED]>
> > > Subject: PHP License for PHP Group packages
> > > Date: Fri, 6 Jan 2006 18:41:33 -0500
> > > To: [EMAIL PROTECTED]
> > > Cc: debian-legal@lists.debian.org
> > > 
> > > FTP Masters,
> > > 
> > > As you are well aware, the current REJECT-FAQ[1] forbids the use of the
> > > PHP License for anything except for PHP itself. In August I contacted
> > > the Pear Group about this[2], to no immediate avail.
> > > 
> > > In October Joerg Jaspert opened a number of RC bugs with existing Debian
> > > packages of Pear packages which use the PHP License (bugs 332606,
> > > 332607, 332608, 332609, 332610, 332611, 332613, 332614, 332615, 332616,
> > > 332617, and 332618 are still open).
> > > 
> > > In November I sent a message to all upstream maintainers about the
> > > situation, requesting them to change their license. Pierre Joye, a
> > > member of the Pear Group, reported in bug #332607[3] that the Pear Group
> > > had asked the PHP Group to modify the PHP License in order to make it
> > > fit for use by Pear packages. Soon thereafter he announced[4] version
> > > 3.01 of the PHP License was released, and that it should fix the
> > > problems we were concerned with.
> > > 
> > > Since that time there has been an ongoing discussion about the PHP
> > > License. While many are concerned that the PHP Licence itself is not
> > > free (even for PHP), it appears that the new PHP License can be applied
> > > on equal grounds to both PHP and PHP Group software, thus making it as
> > > fit for use with Pear packages as it is for PHP[5,6].
> > > 
> > > Given this new development, I would like to request that the FTP Masters
> > > start accepting PHP Group packages licenced under the PHP License (at
> > > least as long as the PHP License is still considered free enough for PHP
> > > in Debian), or at least join the current discussion, pushing it to one
> > > of its two logical conclusions: the acceptance of the PHP Licence as
> > > free for PHP and PHP Group software (and an accompanying update of the
> > > REJECT_FAQ, and the closing of the open RC bugs in Pear packages), or
> > > the rejection of the PHP License for both PHP and PHP Group software in
> > > Debian (and the opening of an RC bug with PHP itself, and a request to
> > > the PHP Group to further update their license).
> > > 
> > > thanks,
> > > Charles
> > > 
> > >  1. http://ftp-master.debian.org/REJECT-FAQ.html
> > >  2. http://lists.debian.org/d

Linux and memory leak

[gustavo halperin]

Hello

I have memory leak in my system, I'm currently using:
   Debian Sarge, Kernel 2.6.10 and Enlightenment
My problem is that the memory (ram and swap) is always grow, my ram is 
775MB and the swap is 1.5GB. After
approximate 20 days the situation of the memory is that all the ram is 
in use and approximate half of the swap is also

in use. In this situation all is work very sloowlyyy.
I'm using the next applications: Mozilla, Acroread, xpdf, gv, 
gnu-emacs, xfig mplayer and some epplets of 
Enlightenment and nothing more.


How I can find the problem, please don't tell me reboot the system, I 
mean this is not Windows. Second, please
also don't tell me that Linux work in this way,  I mean after 
approximate 20 days I can't used nothing.


 Thank you very much, and please help me.

Gustavo Halperin


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

Re: Linux and memory leak

[Laszlo Boszormenyi]

Hi,

On Fri, 2006-02-03 at 20:27 +0200, gustavo halperin wrote:
> In this situation all is work very sloowlyyy.
 Open a terminal, type 'top'. Check that all three numbers after
'load average:' are under one.
You will see a list of applications running, and memory usage in %.
Check which one is big.

>  I'm using the next applications: Mozilla, Acroread, xpdf, gv, 
> gnu-emacs, xfig mplayer and some epplets of 
 I heard that Mozilla needs to be closed after much use, try it.

> Enlightenment and nothing more.
 I think if you use E17, then it may be a problem, because that is
experimental ATM.

>  How I can find the problem, please don't tell me reboot the system, I 
> mean this is not Windows.
 Don't reboot.

>  Second, please
> also don't tell me that Linux work in this way,
 No, it doesn't work this way.
Hope you will figure it out soon. Please report back.

Regards,
Laszlo/GCS


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

Re: Linux and memory leak

[Török Edvin]

On 2/3/06, gustavo halperin <[EMAIL PROTECTED]> wrote:
> Hello
>
> I have memory leak in my system, I'm currently using:
> Debian Sarge, Kernel 2.6.10 and Enlightenment
>  My problem is that the memory (ram and swap) is always grow, my ram is
> 775MB and the swap is 1.5GB. After
> approximate 20 days the situation of the memory is that all the ram is
> in use and approximate half of the swap is also
> in use. In this situation all is work very sloowlyyy.
>  I'm using the next applications: Mozilla, Acroread, xpdf, gv,
> gnu-emacs, xfig mplayer and some epplets of
> Enlightenment and nothing more.

How much memory is each of these applications using? Use 'top' to find
out (sort by memory usage). Don't look only at the applications
listed, there might be another one eating up the memory. Also you
should have most of your memory used as cache, if not there is a very
memory demaning application you have running there.

>
>  How I can find the problem, please don't tell me reboot the system, I
> mean this is not Windows.

You shouldn't have to reboot your system, that is not a solution. Try
to find out which app is responsible for most of this memory usage,
and try restarting that application only, and see if the performance
improves.
Once you pinpointed the leaking application, try to reproduce the
memory leaks, and note down the steps, if successfull, file a
bugreport.


> Second, please
> also don't tell me that Linux work in this way,  I mean after
> approximate 20 days I can't used nothing.

I'm sure it is possible to get an uptime of more than 20 days, and
have everything running as supposed to.

>
>   Thank you very much, and please help me.
>
>  Gustavo Halperin
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
>

[Please don't CC: me as I am subscribed to this list]

Edwin

Re: Linux and memory leak

[Roger Leigh]

gustavo halperin <[EMAIL PROTECTED]> writes:

> My problem is that the memory (ram and swap) is always grow, my ram is
> 775MB and the swap is 1.5GB. After
> approximate 20 days the situation of the memory is that all the ram is
> in use and approximate half of the swap is also
> in use. In this situation all is work very sloowlyyy.
> I'm using the next applications: Mozilla, Acroread, xpdf, gv,
> gnu-emacs, xfig mplayer and some epplets of Enlightenment and nothing
> more.

This question is more appropriate on debian-user.  Please post any
followups there.

Check with top and ps to see memory usage; this should show any memory
hogs.  (Acroread is a likely candidate.)


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgp4cGwrkH6V8.pgp
Description: PGP signature

Bug#351276: ITP: python-dsv -- Python module for delimiter-separated-value files

[Aaron M. Ucko]

Package: wnpp
Severity: wishlist
Owner: "Aaron M. Ucko" <[EMAIL PROTECTED]>

* Package name: python-dsv
  Version : 1.4.0
  Upstream Author : Cliff Wells <[EMAIL PROTECTED]>
* URL : http://sourceforge.net/projects/python-dsv/
* License : standard CNRI Python license
  Description : Python module for delimiter-separated-value files

 Python-DSV is an alternative to Python's standard csv module, with
 somewhat different usage and optional support for wxWidgets-mediated
 user interaction in the course of format autodetection.  Like the
 standard module, it supports a wide range of delimiters and handles
 both import and export.

I'm packaging this in the course of reviving bitpim's ITP (#265585).
I will probably issue a single binary package, for Python 2.3, because
that's all that python-wxgtk2.x supports anyway.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'sarge-unsupported')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


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

Re: PHP License for PHP Group packages

[Don Armstrong]

On Fri, 03 Feb 2006, Charles Fry wrote:
> Instead I propose that all RC bugs in PHP Group software released
> with the PHP License be closed.
> 
> For the record, all previous discussions of this matter on
> debian-legal have suggested that the PHP License might be non-free
> for everything (including PHP), but it has never been argueed that
> PHP itself and PHP Group software should be treated differently with
> respect to the PHP License.

http://lists.debian.org/debian-legal/2005/12/msg00184.html

contains an argument regarding clause 4 of the PHP license version
3.01 which has still not been addressed satisfactorily; namely that
the license requires that software (which is not called PHP to start
with) cannot use the letters "PHP" in their name.[1]

   4. Products derived from this software may not be called "PHP", nor
   may "PHP" appear in their name, without prior written permission
   from [EMAIL PROTECTED] [...]

For example, I should be able to call my derived software
TELEGRAPHPOLE if I want to, which contains "PHP", but does not use the
words PHP in a manner that would likely fall afoul of any trademark of
the term PHP, which presumably the PHP group already has.

As this goes farther than what DFSG 4 allows by dissallowing an entire
class of names, instead of merely requiring that the software changed
names when it is a derived version, it's non-free.

[That of course, isn't to say that the other clauses in the PHP
license which are problematic shouldn't be dealt with as well...]


Don Armstrong

-- 
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 go wrong goes wrong it usually turns out to be impossible to
get at or repair.
 -- Douglas Adams  _Mostly Harmless_

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


signature.asc
Description: Digital signature

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Peter Samuelson]

  [Daniel Schepler]
> > If you're suggesting that with a move of update-inetd then netbase
> > would become more like the netbase-data I was suggesting as an
> > alternative, with minimal dependencies, that would be fine with me.

[Marco d'Itri]
> Yes, because only the files in /etc/ would be left.

That's not quite what he asked.  He mentioned "with minimal
dependencies".  Currently netbase provides a basic networking
environment by depending on several other components, and a *lot* of
packages depend on it, presumably at least partly because of this.

I think it's useful to keep this property (and the dependencies on
ifupdown, et al.) and I also think it's useful to have what Daniel is
asking for, a package that contains /etc/{services,protocols,rpc}
without sucking in all that stuff.  The consequence may be that netbase
shrinks to a mere metapackage, and that seems fine too.


signature.asc
Description: Digital signature

Re: Proposal: move /etc/{protocol,services,rpc} to base-files

[Marco d'Itri]

On Feb 03, Peter Samuelson <[EMAIL PROTECTED]> wrote:

> That's not quite what he asked.  He mentioned "with minimal
> dependencies".  Currently netbase provides a basic networking
The dependencies list would be much shortened too.

> I think it's useful to keep this property (and the dependencies on
I don't.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: PHP License for PHP Group packages

[Glenn Maynard]

(Why is this being CC'd to d-d?)

On Fri, Feb 03, 2006 at 12:06:32PM -0800, Don Armstrong wrote:
>4. Products derived from this software may not be called "PHP", nor
>may "PHP" appear in their name, without prior written permission
>from [EMAIL PROTECTED] [...]
> 
> For example, I should be able to call my derived software
> TELEGRAPHPOLE if I want to, which contains "PHP", but does not use the
> words PHP in a manner that would likely fall afoul of any trademark of
> the term PHP, which presumably the PHP group already has.
> 
> As this goes farther than what DFSG 4 allows by dissallowing an entire
> class of names, instead of merely requiring that the software changed
> names when it is a derived version, it's non-free.

See

 http://lists.debian.org/debian-legal/2005/12/msg00156.html

This clause has been examined carefully in the past and deemed ugly
but not non-free (at least, with no serious objections)--at least in
the "Apache", etc. cases.  However, I don't think that should be extended
to the general case; "nor may 'net' appear in their name" is obviously
not free.  It's an impossible line to draw, between "PHP" and "Apache"
being annoying and "net" being completely unreasonable, which suggests
that it really shouldn't be considered free.

I don't know if it's a battle worth fighting now.  Like patch clauses,
there are so few of them that it's probably not that big a battle, but
if you do want to fight that fight, I don't think "PHP" is any worse
than "Apache", so the objection should be extended across the others
and not single out PHP.

-- 
Glenn Maynard


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

Re: PHP License for PHP Group packages

[Marco d'Itri]

On Feb 03, Glenn Maynard <[EMAIL PROTECTED]> wrote:

> This clause has been examined carefully in the past and deemed ugly
> but not non-free (at least, with no serious objections)--at least in
> the "Apache", etc. cases.  However, I don't think that should be extended
> to the general case; "nor may 'net' appear in their name" is obviously
> not free.
It's obviously not so obvious.

>  It's an impossible line to draw, between "PHP" and "Apache"
> being annoying and "net" being completely unreasonable, which suggests
> that it really shouldn't be considered free.
No, it's quite easy: "net" is a common name, "PHP" and "Apache" are not
(and are even the names of the software being licensed).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Linux and memory leak

[Michael Banck]

On Fri, Feb 03, 2006 at 07:44:17PM +0100, Laszlo Boszormenyi wrote:
> On Fri, 2006-02-03 at 20:27 +0200, gustavo halperin wrote:
> > In this situation all is work very sloowlyyy.
>  Open a terminal, type 'top'. Check that all three numbers after
> 'load average:' are under one.

Please do not follow-up to end-user questions on -devel without at least
setting Mail-Followup-To to a more appropriate list.  Better yet, move
them elsewhere alltogether.


thanks,

Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html


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

Re: Deadline for amendments to the GR

[Manoj Srivastava]

On Fri, 3 Feb 2006 10:58:34 +0100, Sven Luther <[EMAIL PROTECTED]> said: 

> On Mon, Jan 30, 2006 at 09:37:12PM -0600, Debian Project Secretary wrote:
>> Hi folks,
>> 
>> A new amendment has made it in to the GR _after_ the two week
>> discussion deadline. If there are other people mulling proposals
>> for amendments to the GR, now is the time -- if submissions keep
>> coming in at two week intervals, voting on this GR can be delayed
>> almost indefinitely.  In order to prevent that, I would like to see
>> any changes to the GR come in soon -- say, in the next week or so,
>> when we'll close down for the rest of the discussion period, and
>> then open the door for people to call for votes.

> Hi, ...

> a single line telling us the title or the URL of the GR in question
> would have been welcome. I guess this means there is only one GR
> open, but still it would have been neat to clarify this :)


If you do not know what GR's are currently open (despite mails
 on -announce about them), asnd do not know how to simply look it up
 on vote.debian.org, the subject matter is irrelevent to you anyway.

manoj

-- 
"Poor is the man whose pleasures depend on the permission of another."
Madonna
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]