Re: Bug#350397: ITP: dblatex -- Produces DVI, PostScript, PDF documents from DocBook sources

[Frank Küster]

Andreas Hoenen <[EMAIL PROTECTED]> wrote:

> In comparison to that the dblatex development is very vivid, when one
> reports a bug, in most cases it will be fixed within a few days.  The
> upstream author generally is very helpful and would be glad to get the
> project packaged in Debian.
>
> I was able to convince the guys on the Debian SGML mailing list that
> dblatex should be packaged
> (http://lists.debian.org/debian-sgml/2005/10/msg00014.html), they were
> asking for a voluntary maintainer in response.  

So far, so well.  But I'd really also like to read an answer to the
question whether it is, or can be made a drop-in replacement for
db2latex, and whether you've talked with db2latex's Debian maintainers
(apparently a different mailing list with a similar name).  And by the
way, upstream of db2latex in fact is active, they've helped in fixing a
RC of db2latex - unfortunately it still has one, without any maintainer
reaction since September 05.

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX)

Re: when and why did python(-minimal) become essential?

[Josselin Mouette]

Le lundi 30 janvier 2006 à 10:20 +1100, Matthew Palmer a écrit :
> On Sun, Jan 29, 2006 at 02:58:05PM +0100, Josselin Mouette wrote:
> > There have already been - admittedly sporadic - proposals to rewrite
> > some key parts of the system, like the init scripts or adduser, in
> > python. However, if the proponent knows from the beginning the
> > implementation wouldn't be accepted because of the language it is
> > written in, you can't expect him to start working on it.
> 
> What's this "wouldn't be accepted" nonsense?  Are you seriously suggesting
> that, if someone rewrote adduser in Python, that it would be rejected by the
> ftpmasters *because* it was written in Python?

Yes, this is because all dependencies of a package must be of equal or
higher priority. Having adduser depending on python would imply to
increase the priority of python.

> > Putting python in the set of required packages today would simply be a
> > waste of resources. But accepting the idea of putting it in *if* a good
> > enough application shows up is the necessary step to have the
> > applications show up. Some people here are refusing it by principle.
> 
> They're refusing it on the principle of "the cost/benefit ratio sucks".  Not
> a bad principle, as things go.

The arguments I've heard most are not about that ratio. They're only
about "but you can do it in perl!".
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: when and why did python(-minimal) become essential?

[Matthew Palmer]

On Mon, Jan 30, 2006 at 11:03:03AM +0100, Josselin Mouette wrote:
> Le lundi 30 janvier 2006 à 10:20 +1100, Matthew Palmer a écrit :
> > On Sun, Jan 29, 2006 at 02:58:05PM +0100, Josselin Mouette wrote:
> > > There have already been - admittedly sporadic - proposals to rewrite
> > > some key parts of the system, like the init scripts or adduser, in
> > > python. However, if the proponent knows from the beginning the
> > > implementation wouldn't be accepted because of the language it is
> > > written in, you can't expect him to start working on it.
> > 
> > What's this "wouldn't be accepted" nonsense?  Are you seriously suggesting
> > that, if someone rewrote adduser in Python, that it would be rejected by the
> > ftpmasters *because* it was written in Python?
> 
> Yes, this is because all dependencies of a package must be of equal or
> higher priority. Having adduser depending on python would imply to
> increase the priority of python.

Call it 'adduser-python' then.  Show that it's better (oh, for an objective
criterion) and it'll get switched.  Not exactly rocket science.  You're
going to have to do that anyway, even *if* python is essential, because
nobody, even the most die-hard Pythonista, would be dumb enough to call for
tossing out the current adduser implementation for a Python one until the
new one had undergone some fairly massive testing in production.

> > > Putting python in the set of required packages today would simply be a
> > > waste of resources. But accepting the idea of putting it in *if* a good
> > > enough application shows up is the necessary step to have the
> > > applications show up. Some people here are refusing it by principle.
> > 
> > They're refusing it on the principle of "the cost/benefit ratio sucks".  Not
> > a bad principle, as things go.
> 
> The arguments I've heard most are not about that ratio.

You made the argument.

- Matt

Re: when and why did python(-minimal) become essential?

[Wouter Verhelst]

On Mon, Jan 30, 2006 at 11:03:03AM +0100, Josselin Mouette wrote:
> Le lundi 30 janvier 2006 à 10:20 +1100, Matthew Palmer a écrit :
> > On Sun, Jan 29, 2006 at 02:58:05PM +0100, Josselin Mouette wrote:
> > > There have already been - admittedly sporadic - proposals to rewrite
> > > some key parts of the system, like the init scripts or adduser, in
> > > python. However, if the proponent knows from the beginning the
> > > implementation wouldn't be accepted because of the language it is
> > > written in, you can't expect him to start working on it.
> > 
> > What's this "wouldn't be accepted" nonsense?  Are you seriously suggesting
> > that, if someone rewrote adduser in Python, that it would be rejected by the
> > ftpmasters *because* it was written in Python?
> 
> Yes, this is because all dependencies of a package must be of equal or
> higher priority. Having adduser depending on python would imply to
> increase the priority of python.
> 
> > > Putting python in the set of required packages today would simply be a
> > > waste of resources. But accepting the idea of putting it in *if* a good
> > > enough application shows up is the necessary step to have the
> > > applications show up. Some people here are refusing it by principle.
> > 
> > They're refusing it on the principle of "the cost/benefit ratio sucks".  Not
> > a bad principle, as things go.
> 
> The arguments I've heard most are not about that ratio. They're only
> about "but you can do it in perl!".

No, that's not true. You have read it that way, that's right; but that's
an entirely different matter altogether.

I haven't seen _anyone_ say "but it's possible to do in perl, so why
bother?" What I _have_ seen, is many people say "we have perl in base
already, adding python would result in base seriously growing in size,
so what's the benefit?", which is something entirely different.

The only reaction from you that I've seen thus far is "but Python is
much better than Perl!", which obviously attracts some knee-jerk
reactions. That doesn't mean there's no reasonable reason for rejecting
the idea of Python in base at this point in time.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: when and why did python(-minimal) become essential?

[Bill Allombert]

On Mon, Jan 30, 2006 at 12:26:31AM +0100, Emilio Jes??s Gallego Arias wrote:
> Bill Allombert <[EMAIL PROTECTED]> writes:
> 
> > The only (very minor) drawback is that above haskell scripts when
> > compiled is about 7MB in size, but the huge gain in reliability
> 
> I think you're somewhat joking about using Haskell, but your script
> weights:

> [EMAIL PROTECTED]:~/tmp$ ls -lh a.out
> -rwxr-xr-x 1 egallego egallego 182K 2006-01-30 00:19 a.out
> 
> This is including all the Haskell runtime. Using a shared runtime
> would be the optimal solution, as the compiled module is about 9Kb
> (without stripping):

Interestingly the size is highly dependent on the architecture:

[EMAIL PROTECTED]:~$ ls -l postrm-*
-rwxr-xr-x  1 ballombe ballombe 6960782 Jan 30 14:10 postrm-amd64
-rwxr-xr-x  1 ballombe ballombe  266065 Jan 30 14:09 postrm-i386
[EMAIL PROTECTED]:~$ strip postrm*
[EMAIL PROTECTED]:~$ ls -l postrm-*
-rwxr-xr-x  1 ballombe ballombe 4702544 Jan 30 14:10 postrm-amd64
-rwxr-xr-x  1 ballombe ballombe  156720 Jan 30 14:10 postrm-i386

(This is sarge ghc6)

> However, AFAIK GHC doesn't support sharing the runtime.

IIRC, The FAQ says the runtime ABI is too fragile to be practical
to have a shared runtime.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: when and why did python(-minimal) become essential?

[Emilio Jesús Gallego Arias]

Bill Allombert <[EMAIL PROTECTED]> writes:

> Interestingly the size is highly dependent on the architecture:
>
> [EMAIL PROTECTED]:~$ ls -l postrm-*
> -rwxr-xr-x  1 ballombe ballombe 6960782 Jan 30 14:10 postrm-amd64
> -rwxr-xr-x  1 ballombe ballombe  266065 Jan 30 14:09 postrm-i386
> [EMAIL PROTECTED]:~$ strip postrm*
> [EMAIL PROTECTED]:~$ ls -l postrm-*
> -rwxr-xr-x  1 ballombe ballombe 4702544 Jan 30 14:10 postrm-amd64
> -rwxr-xr-x  1 ballombe ballombe  156720 Jan 30 14:10 postrm-i386

Ups, that seems wrong :) I thought that AMD64 maybe wasn't a
registered port in Sarge GHC, but it is.

Anyways, using an hypothetical shared runtime would be too much bloat
for maintainer scripts anyways. A far better approach would be to use
Haskell as a script language, but AFAIK this is not really possible
yet.

Regards,

Emilio


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

Re: Multiple package variants with CDBS?

[Michelle Konzack]

Am 2006-01-28 13:27:11, schrieb W. Borgert:
> Hi,
> 
> I have a package that is configured and compiled two times, so
> that two binary packages are built in one dpkg-buildpackage run:
> One with --enable-gnome, the second without. Is this supported
> by CDBS somehow? Is there a package, that already does such a
> thing using CDBS? Any hint or example debian/rules file
> appreciated, thanks in advance!

Look at fvwm.

> Cheers, WB

Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


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

Re: Bug#349424: ITP: xcftools -- command-line tools for extracting data for XCF files

[Henning Makholm]

Scripsit Daniel Kobras <[EMAIL PROTECTED]>

> Imagemagick in general can handle multi-layered images just fine. I'm
> not sure whether this is true for its xcf module already, but the
> necessary framework is certainly there. So if you don't want to keep
> maintaining a separate utility, merging it with the code in imagemagick
> might be an option for you.

At the moment I think it is easier for me to maintain a separate
utility that does one thing but does it well, than to integrate the
functionality I need into imagemagick sufficiently seamlessly to
satisfy my technical pride.

But thaks for pointing out that imagemagick does have some support for
layers. This wasn't apparent to me the first 20 times I read the
manpage :-)


(In related news, an xcftools package is now in the NEW queue).

-- 
Henning Makholm   "... not one has been remembered from the time
 when the author studied freshman physics. Quite the
contrary: he merely remembers that such and such is true, and to
  explain it he invents a demonstration at the moment it is needed."


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

Bug#350582: ITP: libclass-throwable-perl -- A minimal lightweight exception class

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libclass-throwable-perl
  Version : 0.10
  Upstream Author : stevan little, <[EMAIL PROTECTED]>
* URL : 
http://mirrors.kernel.org/cpan/modules/by-module/Class/Class-Throwable-0.10.tar.gz
* License : Perl: GPL/Artistic
  Description : A minimal lightweight exception class

 This module implements a minimal lightweight exception object. It is meant to 
 be a compromise between more basic solutions like Carp which can only print 
 information and cannot handle exception objects, and more more complex 
 solutions like Exception::Class which can be used to define complex inline 
 exceptions and has a number of module dependencies.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2)


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

Re: when and why did python(-minimal) become essential?

[Henning Makholm]

Scripsit Manoj Srivastava <[EMAIL PROTECTED]>

> If people find Perl too hard (feh), and python too ugly,
>  regressive syntactically, and counter intuitive, and want ruby, or
>  scheme, or haskell, what then?

Unless there is a requirement that maintainer scripts have to be
shipped in an ascii-based format (and TTBOMK there is not), Scheme and
Haskell should be fine even now. Build-depend on an appropriate
compiler, compile the script at build time, and ship the binary.

The problem arises only when people want to write infrastructure
scripts in languages that need an interpreter to run.

-- 
Henning Makholm   "... popping pussies into pies
  Wouldn't do in my shop
just the thought of it's enough to make you sick
   and I'm telling you them pussy cats is quick ..."


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

Re: Multiple package variants with CDBS?

[Michael Banck]

On Sun, Jan 29, 2006 at 11:06:20AM +0100, Michelle Konzack wrote:
> Am 2006-01-28 13:27:11, schrieb W. Borgert:
> > I have a package that is configured and compiled two times, so
> > that two binary packages are built in one dpkg-buildpackage run:
> > One with --enable-gnome, the second without. Is this supported
> > by CDBS somehow? Is there a package, that already does such a
> > thing using CDBS? Any hint or example debian/rules file
> > appreciated, thanks in advance!
> 
> Look at fvwm.

fvwm does not use cdbs, I think we all know how to do this in general.


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: Multiple package variants with CDBS?

[Manoj Srivastava]

On Mon, 30 Jan 2006 17:22:46 +0100, Michael Banck <[EMAIL PROTECTED]> said: 

> On Sun, Jan 29, 2006 at 11:06:20AM +0100, Michelle Konzack wrote:
>> Am 2006-01-28 13:27:11, schrieb W. Borgert:
>> > I have a package that is configured and compiled two times, so
>> > that two binary packages are built in one dpkg-buildpackage run:
>> > One with --enable-gnome, the second without. Is this supported by
>> > CDBS somehow? Is there a package, that already does such a thing
>> > using CDBS? Any hint or example debian/rules file appreciated,
>> > thanks in advance!
>> 
>> Look at fvwm.

> fvwm does not use cdbs, I think we all know how to do this in
> general.

While fvwm does not use CDBS, my build mechanisms did copy
 some bits of CDBS, and the solution in debian/local.mk in fvwm can be
 adapted for use with CDBS.

manoj
-- 
If you wait long enough, it will go away... after having done its
damage. If it was bad, it will be back.
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: Bug#349064: ITP: macromedia-flash-installer -- installer for Macromedia Flash Plugin

[Bart Martens]

So, one conclusion is clear : Nobody wants a second installer for the
Macromedia Flash Plugin.  Efforts should go to flashplugin-nonfree.
Thanks for the comments leading to this consensus.

Less clear to me is "what now".  The maintainer of flashplugin-nonfree
seems to be busy with other things.  Would an NMU be appropriate now ?

Regards,

Bart Martens


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

Re: Bug#349064: ITP: macromedia-flash-installer -- installer for Macromedia Flash Plugin

[Jeroen van Wolffelaar]

On Mon, Jan 30, 2006 at 07:49:09PM +0100, Bart Martens wrote:
> So, one conclusion is clear : Nobody wants a second installer for the
> Macromedia Flash Plugin.  Efforts should go to flashplugin-nonfree.
> Thanks for the comments leading to this consensus.
> 
> Less clear to me is "what now".  The maintainer of flashplugin-nonfree
> seems to be busy with other things.  Would an NMU be appropriate now ?

Yes, if you're following the procedures, a NMU would be fine, as long as
you're not doing things against the (expressed or reasonably
deduceable) wishes of the maintainer.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

Re: returning emeritus developer, no response from [EMAIL PROTECTED]

[Nathanael Nerode]

> > so far not even a response telling me I'm in a queue.
> > Is the procedure described above still the right one?
> 
> DAM is very slow-moving these days.  Probably they haven't looked at your 
mail 
> yet.

Um, just in case anyone was wondering, that wasn't intended as a criticism of 
DAM -- I think it's slowmoving mostly due to having a heavy workload on two 
people who already do a lot of other work -- but I just realized that it 
might have come off as a criticism.  I was just trying to inform the emeritus 
developer that DAM was probably a lot slower now than it was back when he (or 
she) was an active developer, when DAM probably had a lighter workload.

And I liked the clarivoyant joke, but as far as I can tell, I'm not, so no 
need to fast-track me on that account. :-)


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

Re: The Debian community should influence the next Haskell language standard

[Florian Weimer]

* Isaac Jones:

> I'd like to ask the Debian community to look at Haskell98 and some of
> the "research" extensions[2] and give us some input as to what would
> make Haskell more attractive to you.

Uhm, most of the things on Debian's (as opposed to individual
developer's) whishlist are quality-of-implementation issues, not
really language issues.

A sensible approach to separate compiliation, so that it's possible to
change the implementation of a module without having to recompile all
of its clients.  This helps to avoid that packages in our
distributions are too closely coupled, which makes updating individual
components manageable (for example, to patch a security
vulnerability).  Dynamic shared objects with stable ABIs across
compiler versions would be a nice benefit, but I understand that
implementing this is hard.

There should be compilers which are portable to Debian's release
architectures, which consume moderate amounts of memory (just a few
dozen megabytes, but pretty please not a few hundred) and are
reasonably fast.  This means that Haskell programs won't bog down our
build daemons, so we can afford as many of them as we like.

We can cope with C++, so we shouldn't demand too much from other
languages. 8-)

Apart from that, I find your question a bit strange.  Maybe that's
because Debian ships implementations for so many programming languages
that yet another one (or even a new revision of an existing one)
doesn't make a real difference.  The separate compilation aspect is
important, but it currently does not matter much because Haskell
packages generally have very short dependency chains as far as other
Haskell packages are concerned.

On a more personal note, I found the non-predictable space behavior
very hard to deal with.  I'd also like to see something like
unsafePerformIO in the language standard: a trapdoor into the IO monad
which may lead to the side effect happening multiple times, but which
is type-safe.  (The rationale is that unsafePerformIO does occur in
real-world programs, so there seems to be a real-world demand for it,
but its horribly un-soundness makes it look really bad.)  But I can
understand that tackling unsafePerformIO might take Haskell into a
direction the greater community has little interest in.


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

MIA? Fabio Rafael da Rosa

[Lionel Elie Mamane]

Hi,

I still haven't heard back from Fabio Rafaek da Rosa
<[EMAIL PROTECTED]>, my first MIA-test contact was > 2 months
ago.

Otavio, you seem to have been his sponsor, do you have any news from
him in the last 6 months (or since January, 1st 2005, for that
matter)? Anybody else?

On Thu, Dec 08, 2005 at 11:29:09PM +0100, Lionel Elie Mamane wrote to
Fabio Rafael da Rosa:

> Please get in touch, whether you want to continue working on Debian or
> not. If you are "just" temporarily too busy for Debian, would you mind
> my taking care of nag and mnemo in the meantime?

> On Sun, Nov 20, 2005 at 11:38:55AM +0100, Lionel Elie Mamane wrote:

>> I notice you have been quite inactive Debian-wise, for _all_ your
>> packages. If you want to stop Debian work, could you please cleanly
>> orphan your packages (see
>> http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-orphaning)
>> and retire from Debian (see
>> http://www.nl.debian.org/doc/developers-reference/ch-developer-duties.en.html#s3.7)?

>> (In this case, I'll probably take over nag and mnemo.)

>> If the problem is that you are not a DD but lost your sponsor, I'd
>> be glad to sponsor you.

>> In all cases, please get in touch so that we "know" you haven't
>> disappeared.

-- 
Lionel


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

[Auto-Reply] Re: List

[info]

Thank you for your email. Please note that the Asia Art Archive is closed from 
Saturday 28th January 2006 until 10am on the 1st of February 2006 to celebrate 
the Chinese New Year.
We apologise for any inconvenience caused.

Kung Hei Fat Choi!
  
The Asia Art Archive


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

Re: MIA? Fabio Rafael da Rosa

[Otavio Salvador]

Lionel Elie Mamane <[EMAIL PROTECTED]> writes:

> Otavio, you seem to have been his sponsor, do you have any news from
> him in the last 6 months (or since January, 1st 2005, for that
> matter)? Anybody else?

I didn't have any news from him. :(

I think would be fine if you take over the  package. Leave him as
co-maintainer for a while.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."


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