RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0.1dfsg-1~0unreleased Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0.1dfsg-1~0unreleased.dsc I would be glad if someone uploaded this package for me. Also, please note the use of ~0unreleased at the end of the version number. If you're willing to sponsor this package, please remove this tag or let me know if you want me to remove it. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0.1dfsg-1~0unreleased1 Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0.1dfsg-1~0unreleased1.dsc I would be glad if someone uploaded this package for me. Also, please note the use of ~0unreleased1 at the end of the version number. If you're willing to sponsor this package, please remove this tag or let me know if you want me to remove it. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Nov 26, 2007 3:36 PM, Andres Mejia [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package mediatomb. A more thorough review of your package: doc/mediatomb.1 is generated from docbook xml, but that source code isn't available in the source package. This means the package cannot enter Debian because it fails DFSG 2. Please remove, rewrite or add the docbook source. Some of the .js files are not GPL licenced, please fill out the copyright file properly. Other files are copyrighted by entities not mentioned in debian/copyright: src/md5/* (different copyright holder licence), src/uuid (different copyright holder), src/inotify-nosys.h (different copyright holder, no licence, therefore we cannot distribute it - presumably there is a properly licenced copy somewhere since it looks like it came from linux), tombupnp/*** (different copyright holders licences), tombupnp/upnp/src/uuid/upnp_md5.c upnp_md5.h (looks non-free - no permission to distribute, suggest replacing with a public domain md5 implementation). src/uuid looks like a copy of libuuid, if your package gets uploaded, please notify the security team that your package contains an embedded copy of libuuid. Please also suggest to upstream that they remove it from the source and instead depend on an external libuuid from http://sourceforge.net/projects/e2fsprogs for example. Same for tombupnp, that looks like a modified copy of libupnp, try to get that merged into upstream libupnp: http://pupnp.sourceforge.net/ You also embed external JS libraries (each one js file), I'm not sure what debian policy about that is, although we now have fckeditor in the archive, so maybe package them up so other packages can depend on them? Might want to bring this up on the debian-webapps list. You may want to rewrite the copyright file to be machine parseable: http://wiki.debian.org/Proposals/CopyrightFormat open source (GPL) in the description is redundant for packages in Debian main The Vcs-* links point to a location that has only etch and sarge, where do you store packaging for sid? Do you have access to upstream SVN? If so, I suggest moving the .desktop file there so other distros may benefit from it too. Obviously you'd also need to add a ./configure flag so that distributions can choose which web browser to launch. Possibly the same for debian/config.xml.inst, but I'm not too sure about that. No need to install both the README files, I suggest just installing README. Same for the two scripting.txt files (install the ASCII one). Relevant linda warnings: W: mediatomb-common; Long descriptions contains short description. The long description of this package contains the short description. This is a bad idea, as the long description should be long, and not just reiterate the short description. W: mediatomb; Long descriptions contains short description. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0-7 Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 This package would require the orig tarball to be uploaded and every changelog entry to be uploaded as it has never been uploaded to Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-7.dsc I would be glad if someone uploaded this package for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Nov 16, 2007 4:53 PM, Andres Mejia [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package mediatomb. Another review, minor issues: Homepage doesn't need to be duplicated in the descriptions Vcs-* are official, no need for the XS- Encoding key in the .desktop file is depreciated -- bye, pabs http://wiki.debian.org/PaulWise http://wiki.synfig.com/PaulWise http://pabs.id.au -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0-7 Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 This package would require the orig tarball to be uploaded and every changelog entry to be uploaded as it has never been uploaded to Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-7.dsc I would be glad if someone uploaded this package for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Nov 16, 2007 2:31 AM, Paul Wise [EMAIL PROTECTED] wrote: On Nov 16, 2007 4:53 PM, Andres Mejia [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package mediatomb. Another review, minor issues: Homepage doesn't need to be duplicated in the descriptions Vcs-* are official, no need for the XS- Encoding key in the .desktop file is depreciated Thanks. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0-6 Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 This package would require the orig tarball to be uploaded and every changelog entry to be uploaded as it has never been uploaded to Debian. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-6.dsc I would be glad if someone uploaded this package for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
Am Donnerstag, den 08.11.2007, 20:31 -0500 schrieb Justin Pryzby: On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote: On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: postinst should use dpkg-statoverride instead of chown Really? I thought this was an administrator's tool, and the postinst should do something like I guess I meant chowning blindly instead of chown. I do note that a few postinst files in my /var/lib/dpkg/info/ use dpkg-statoverride rather than chown. I guess I should reread devref/policy. Policy mentions this in 10.9.1; it appears that it can be correct to do either dpkg-statoverride --update or use chown directly, as long as it's conditional on does dpkg-statoverride -l $f /dev/null. I note that using chown doesn't add the file to the override data, which I argue is a good thing due to no ambiguity about who put it there. I had the same issue myself, some days ago. I wasn't sure if using chown or dpkg-statoverride in postinst was the correct way. You argue for not using dpkg-statoverride, policy seems to recommend it though. Asking on #debian-devel, the answers I got were, to use dpkg-statoverride unless I have a very good reason not to. I think one disadvantage of using chown in postinst is, that you have a time frame between unpack and postinst, where the binary has the wrong the permissions. With dpkg-statoverride, dpkg will take care that the binary has always the correct permissions. So this is a big advantage of using dpkg-statoverride. Admittedly it would be nice, if policy was more precise in that matter. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
On Nov 9, 2007 5:24 AM, Michael Biebl [EMAIL PROTECTED] wrote:
Am Donnerstag, den 08.11.2007, 20:31 -0500 schrieb Justin Pryzby:
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote:
On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote:
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
I guess I meant chowning blindly instead of chown.
I do note that a few postinst files in my /var/lib/dpkg/info/ use
dpkg-statoverride rather than chown.
I guess I should reread devref/policy.
Policy mentions this in 10.9.1; it appears that it can be correct to
do either dpkg-statoverride --update or use chown directly, as long as
it's conditional on does dpkg-statoverride -l $f /dev/null.
I note that using chown doesn't add the file to the override data,
which I argue is a good thing due to no ambiguity about who put it
there.
I had the same issue myself, some days ago. I wasn't sure if using chown
or dpkg-statoverride in postinst was the correct way.
You argue for not using dpkg-statoverride, policy seems to recommend it
though. Asking on #debian-devel, the answers I got were, to use
dpkg-statoverride unless I have a very good reason not to.
I think one disadvantage of using chown in postinst is, that you have a
time frame between unpack and postinst, where the binary has the wrong
the permissions. With dpkg-statoverride, dpkg will take care that the
binary has always the correct permissions.
So this is a big advantage of using dpkg-statoverride.
Admittedly it would be nice, if policy was more precise in that matter.
Thanks for the suggestions. I went ahead and made the changes. Here's
the changelog for 0.10.0-5 of this package.
[ Andres Mejia ]
* Using deluser and delgroup commands to remove meditomb user and group.
* Removed dependency on passwd.
* Added --disabled-{login,password} for adduser in preinst.
* Changed --shell option to use /usr/sbin/nologin in preinst.
* Using dpkg-statoverride instead of chown for postinst.
I've uploaded the new package to mentors.d.n. Here are the links.
- URL: http://mentors.debian.net/debian/pool/main/m/mediatomb
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-5.dsc
--
Regards,
Andres Mejia
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dynamic users (Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface))
On Fri, Nov 09, 2007 at 02:26:42PM -0500, Andres Mejia wrote:
On Nov 9, 2007 5:24 AM, Michael Biebl [EMAIL PROTECTED] wrote:
Am Donnerstag, den 08.11.2007, 20:31 -0500 schrieb Justin Pryzby:
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote:
On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote:
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
I guess I meant chowning blindly instead of chown.
I do note that a few postinst files in my /var/lib/dpkg/info/ use
dpkg-statoverride rather than chown.
I guess I should reread devref/policy.
Policy mentions this in 10.9.1; it appears that it can be correct to
do either dpkg-statoverride --update or use chown directly, as long as
it's conditional on does dpkg-statoverride -l $f /dev/null.
I note that using chown doesn't add the file to the override data,
which I argue is a good thing due to no ambiguity about who put it
there.
I had the same issue myself, some days ago. I wasn't sure if using chown
or dpkg-statoverride in postinst was the correct way.
You argue for not using dpkg-statoverride, policy seems to recommend it
though. Asking on #debian-devel, the answers I got were, to use
dpkg-statoverride unless I have a very good reason not to.
I think one disadvantage of using chown in postinst is, that you have a
time frame between unpack and postinst, where the binary has the wrong
the permissions. With dpkg-statoverride, dpkg will take care that the
binary has always the correct permissions.
So this is a big advantage of using dpkg-statoverride.
Admittedly it would be nice, if policy was more precise in that matter.
Thanks for the suggestions. I went ahead and made the changes. Here's
the changelog for 0.10.0-5 of this package.
[ Andres Mejia ]
* Using deluser and delgroup commands to remove meditomb user and group.
* Removed dependency on passwd.
* Added --disabled-{login,password} for adduser in preinst.
BTW did you know that adduser --system adds a user *and* a group? For
system users only. {,} is a bashism of course.
Why do you remove the user/group? I think the suggestion is to leave
dynamic system ID's to avoid them being recreated with a different
(system) user which now has access to some stray files leftover from a
different package. If the admin wants to get rid of them, they can do
find / -user $u -o -group $u -ls at their convenience, or look in
obvious places or decide it's not worth the effort.
I think if you do use deluser, it should be in purge and not
remove.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dynamic users (Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface))
On Nov 9, 2007 2:46 PM, Justin Pryzby [EMAIL PROTECTED] wrote:
On Fri, Nov 09, 2007 at 02:26:42PM -0500, Andres Mejia wrote:
Thanks for the suggestions. I went ahead and made the changes. Here's
the changelog for 0.10.0-5 of this package.
[ Andres Mejia ]
* Using deluser and delgroup commands to remove meditomb user and group.
* Removed dependency on passwd.
* Added --disabled-{login,password} for adduser in preinst.
BTW did you know that adduser --system adds a user *and* a group? For
system users only. {,} is a bashism of course.
Why do you remove the user/group? I think the suggestion is to leave
dynamic system ID's to avoid them being recreated with a different
(system) user which now has access to some stray files leftover from a
different package. If the admin wants to get rid of them, they can do
find / -user $u -o -group $u -ls at their convenience, or look in
obvious places or decide it's not worth the effort.
I think if you do use deluser, it should be in purge and not
remove.
I meant to say purge. deluser and delgroup are used when purging (not
removing) the package.
--
Regards,
Andres Mejia
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
There were some things I needed to fix. Here are the changes. * Fixing mediatomb-daemon.postrm to delete /var/lib/mediatomb when removing or purging. * Adding dpkg-statoverride command during purging to remove overrides used by mediatomb-daemon package. - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-6.dsc -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
Dear mentors, I am looking for a sponsor for my package mediatomb. * Package name: mediatomb Version : 0.10.0-4 Upstream Author : Gena Batyan [EMAIL PROTECTED], Sergey Bostandzhyan [EMAIL PROTECTED], Leonhard Wimmer [EMAIL PROTECTED] * URL : http://mediatomb.cc/ * License : GPLv2 Section : net It builds these binary packages: mediatomb - UPnP MediaServer mediatomb-common - UPnP MediaServer mediatomb-daemon - UPnP MediaServer The package appears to be lintian clean. The upload would fix these bugs: 440199 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediatomb - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediatomb/mediatomb_0.10.0-4.dsc I would be glad if someone uploaded this package for me. -- Regards, Andres Mejia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
getent $u /dev/null ||
adduser --system --group --home /var/... --shell /usr/sbin/nologin \
--disabled-{login,password} $u
dpkg-statoverride --list $f /dev/null ||
chown $u:$u $f
If the statoverride datafile gets filled with all sorts of
maintainer's default package data then it instead requires some
heureustic to try to determine whether the admin did chmod to a
different user/group.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: postinst should use dpkg-statoverride instead of chown Really? I thought this was an administrator's tool, and the postinst should do something like I guess I meant chowning blindly instead of chown. I do note that a few postinst files in my /var/lib/dpkg/info/ use dpkg-statoverride rather than chown. I guess I should reread devref/policy. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote: On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: postinst should use dpkg-statoverride instead of chown Really? I thought this was an administrator's tool, and the postinst should do something like I guess I meant chowning blindly instead of chown. I do note that a few postinst files in my /var/lib/dpkg/info/ use dpkg-statoverride rather than chown. I guess I should reread devref/policy. Policy mentions this in 10.9.1; it appears that it can be correct to do either dpkg-statoverride --update or use chown directly, as long as it's conditional on does dpkg-statoverride -l $f /dev/null. I note that using chown doesn't add the file to the override data, which I argue is a good thing due to no ambiguity about who put it there. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
ftp-master is down, so here is a review of your diff.gz: since you already use the Homepage field, you should remove it from the descriptions don't forget to send the desktop file upstream (and other relevant stuff) the Encoding field is obsolete in .desktop files (please use lintian next time) It would be good if the package descriptions weren't almost-copies of each other Who is Leonhard Wimmer, and why is he in the Maintainer field? The maintainer field is for the maintainer of the debian package, not the upstream code. might want to use debian/compat 5 postinst should use dpkg-statoverride instead of chown -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
