RFS: atmailopen (2nd attempt - updated description)

[Giuseppe Iuculano]

Dear mentors,

I am looking for a sponsor for my package "atmailopen".

* Package name    : atmailopen
  Version         : 1.01-1
  Upstream Author : @Mail <info@...>
* URL             : http://www.atmail.org/
* License         : Apache License Version 2.0
  Section         : web



Description: elegant and intuitive ajax webmail client written in php
 AtMail is a webmail client written in PHP. It aim to provide
 an elegant Ajax webmail client for existing IMAP mailservers, with less bloat
 and a focus on an intuitive, simple user interface.
 AtMail provides users with a lightweight, yet powerful webmail client and
 it is poised to deliver the next generation webmail.
 .
 Features of AtMail Open include:
   * Lightweight Ajax Webmail Interface
   * Video Mail
   * PHP source code
   * IMAP support
   * Live Spell Check
   * Address Book

It builds these binary packages:
atmailopen - elegant and intuitive ajax webmail client written in php

The package appears to be lintian clean.

The upload would fix these bugs: 487263 (ITP)

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/a/atmailopen
- Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/a/atmailopen/atmailopen_1.01-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Giuseppe Iuculano

[Eugene V. Lyubimkin]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

IANADD

Giuseppe Iuculano wrote:

> I am looking for a sponsor for my package "atmailopen".
>
> * Package name    : atmailopen
>   Version         : 1.01-1
>   Upstream Author : @Mail <info@...>
> * URL             : http://www.atmail.org/
> * License         : Apache License Version 2.0
>   Section         : web
>
>
>
> Description: elegant and intuitive ajax webmail client written in php

[snip]
> Kind regards
>  Giuseppe Iuculano
>
>
Debian developers reference suggest not no put "written in <language>" into one-line
descriptions - it is useless for users to know what language the program written in.

- --
Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQFIb0WxchorMMFUmYwRAkQXAJdzZVYwW+3egBfWvwbD5Sz7JK5hAKCgzyOY
6w4tUciscvnND4uB/X7Oiw==
=Yyk/
-----END PGP SIGNATURE-----


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Giuseppe Iuculano]

Eugene V. Lyubimkin ha scritto:

> Debian developers reference suggest not no put "written in <language>" into one-line
> descriptions - it is useless for users to know what language the program written in.
>

Removed, thanks. New synopsis is:

Description: elegant and intuitive ajax webmail client



Giuseppe.

[Ben Finney-5]

Giuseppe Iuculano <giuseppe@...> writes:

> Description: elegant and intuitive ajax webmail client written in php
>  AtMail is a webmail client written in PHP. It aim to provide
>  an elegant Ajax webmail client for existing IMAP mailservers, with less bloat
>  and a focus on an intuitive, simple user interface.

Seems fine, except for all the references to PHP; you should remove
all of them. Once the package is in Debian, you can use debtags to
classify things like implementation language.

>  AtMail provides users with a lightweight, yet powerful webmail client and
>  it is poised to deliver the next generation webmail.

This sentence seems like useless marketing drivel. It can safely be
deleted.

>  Features of AtMail Open include:
>    * Lightweight Ajax Webmail Interface
>    * Video Mail
>    * PHP source code
>    * IMAP support
>    * Live Spell Check
>    * Address Book

Good.

Giuseppe Iuculano <giuseppe@...> writes:

> Description: elegant and intuitive ajax webmail client

Much improved.

--
 \         “In any great organization it is far, far safer to be wrong |
  `\          with the majority than to be right alone.” —John Kenneth |
_o__)                                            Galbraith, 1989-07-28 |
Ben Finney


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Giuseppe Iuculano]

Ben Finney ha scritto:
> Seems fine, except for all the references to PHP; you should remove
> all of them. Once the package is in Debian, you can use debtags to
> classify things like implementation language.

Uploaded with this new description:

Description: elegant and intuitive ajax webmail client
 AtMail is a modern webmail client. It aim to provide an elegant Ajax webmail
 client for existing IMAP mailservers, with less bloat and a focus on an
 intuitive, simple user interface.
 .
 Features of AtMail Open include:
   * Lightweight Ajax Webmail Interface
   * Video Mail
   * PHP source code
   * IMAP support
   * Live Spell Check
   * Address Book




Giuseppe.

[Eduardo M KALINOWSKI-4]

Eugene V. Lyubimkin wrote:

> > Description: elegant and intuitive ajax webmail client written in php
> [snip]
> > Kind regards
> >  Giuseppe Iuculano
>
>
> Debian developers reference suggest not no put "written in <language>"
> into one-line
> descriptions - it is useless for users to know what language the
> program written in.

In this particular case, it actually can be useful, since it's a web
application to be run in a web browser, which will need support for the
particular language. Naturally, the same can be guessed from the package
dependencies, but especially if it were something more exotic than PHP,
the information is not as useless as when it is given for a compiled
program used directly by the users.

--
Distrust all those who love you extremely upon a very slight acquaintance
and without any visible reason.
        -- Lord Chesterfield

Eduardo M KALINOWSKI
eduardo@...
http://move.to/hpkb


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

Eduardo M KALINOWSKI <eduardo@...> writes:

> Eugene V. Lyubimkin wrote:
> > Debian developers reference suggest not no put "written in
> > <language>" into one-line descriptions - it is useless for users
> > to know what language the program written in.
>
> In this particular case, it actually can be useful, since it's a web
> application to be run in a web browser, which will need support for the
> particular language.

I've never needed PHP support in my web browser to use web
applications written in PHP.

Perhaps you mean the web *server* needs PHP support?

> Naturally, the same can be guessed from the package dependencies,

This information is better done with debtags, using the organised tag
hierarchy, rather than cluttering the description. Packaging tools can
easily show the debtags for a package along with its description.

--
 \      "The opposite of a correct statement is a false statement. But |
  `\     the opposite of a profound truth may well be another profound |
_o__)                                              truth." —Niels Bohr |
Ben Finney


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Eduardo M KALINOWSKI-4]

Ben Finney wrote:

> Eduardo M KALINOWSKI <eduardo@...> writes:
>
>  
>> Eugene V. Lyubimkin wrote:
>>    
>>> Debian developers reference suggest not no put "written in
>>> <language>" into one-line descriptions - it is useless for users
>>> to know what language the program written in.
>>>      
>> In this particular case, it actually can be useful, since it's a web
>> application to be run in a web browser, which will need support for the
>> particular language.
>>    
>
> I've never needed PHP support in my web browser to use web
> applications written in PHP.
>
> Perhaps you mean the web *server* needs PHP support?
>  

Sure, it was a typo. And I meant that from the server admin's point of
view, it he who will be installing the package, not the users.

--
Nem que eu tivesse dois pulmões eu alcançava essa bola.
                -- Bradock, amigo de Romário reclamando de um passe
                   longo

Eduardo M KALINOWSKI
eduardo@...
http://move.to/hpkb


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ben Finney-5]

Eduardo M KALINOWSKI <eduardo@...> writes:

> I meant that from the server admin's point of view, it he who will
> be installing the package, not the users.

Right. So, that admin, when she's ready to install packages, can
choose to use a package tool like aptitude that will display all the
debtags for a package.

--
 \     “I have an answering machine in my car. It says, ‘I'm home now. |
  `\  But leave a message and I'll call when I'm out.’” —Steven Wright |
_o__)                                                                  |
Ben Finney


--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Vincent Bernat-3]

OoO En  cette fin de  matinée radieuse du  samedi 05 juillet  2008, vers
11:52, Giuseppe Iuculano <giuseppe@...> disait :


> * Package name    : atmailopen
>   Version         : 1.01-1
>   Upstream Author : @Mail <info@...>
> * URL             : http://www.atmail.org/
> * License         : Apache License Version 2.0
>   Section : web

Hi Giuseppe!

Some    files     have    a    different     license.    For    example,
libs/Atmail/spellChecker.php. The license given  as URL is non-free. You
will  need to  work with  upstream  to sort  this out.  Check all  files
individually. The license which is in the headers is more important than
the one in LICENSE file.

You  introduce a debconf  templates. I  see that  you already  have some
translations. However,  I don't find  your call for  translations. Until
lenny  is  released, this  is  better  to  ask for  translations  before
releasing new debconf templates:
 http://www.perrier.eu.org/weblog/2008/07/15#anti-l10n-cabal

You  may  also  want  to  ask  debian-l10n-english@  to  proofread  your
templates before asking for translation. This will be done at some point
in the future, so doing it now will ease translators work.

Setting global  aliases is considered harmful, you  should comment alias
declaration in  your apache.conf. The  user will have to  uncomment this
directive. This  ensures that nothing bad happens  when someone installs
atmail. See for example:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476162

conf/Config.php is really  huge. You could split it  in several files if
some  parts are  more  likely to  be  modified by  the  user than  other
ones. This way,  if a user will modify  only a small part of  a file, he
won't have  to read a big  diff. At least  PHP functions at the  end are
good candidates to be put in another file, IMO.

In the long description, what does  "PHP source code" means. If it means
that AtMail is open source, you can just remove it.

Since  AtMail will  write in  /usr/share/atmailopen/users, it  should be
placed  in /var/lib/atmailopen  instead.  AtMail should  work with  /usr
being mounted as read-only.

You  still support  web servers  that are  not part  of  Debian (apache,
apache-ssl, apache-perl) any more. Some people don't like this. You ship
a configuration for lighttpd but does not propose to install it. You can
look at roundcube package for some hints about this.

Moreover, you modify the configuration of the web servers without asking
the user first. This is bad.  You should add a debconf question.  If you
take the one from roundcube, you can save some translations too. :)

In postrm, you should remove web server configuration files on purge.

The database  can be  remote (this is  handled by  dbconfig-common). You
should only suggests mysql-server  and depends on mysql-client (which is
needed for dbconfig-common operations).
--
SPITWADS ARE NOT FREE SPEECH
SPITWADS ARE NOT FREE SPEECH
SPITWADS ARE NOT FREE SPEECH
-+- Bart Simpson on chalkboard in episode 8F01

[Giuseppe Iuculano]

Hi Vincent,


Vincent Bernat wrote:
> Hi Giuseppe!
>
> Some    files     have    a    different     license.    For    example,
> libs/Atmail/spellChecker.php. The license given  as URL is non-free. You
> will  need to  work with  upstream  to sort  this out.  Check all  files
> individually. The license which is in the headers is more important than
> the one in LICENSE file.

Some days ago I contacted upstream to inform about this license issue, he
promise me a new version in the next week!



> You  introduce a debconf  templates. I  see that  you already  have some
> translations. However,  I don't find  your call for  translations. Until
> lenny  is  released, this  is  better  to  ask for  translations  before
> releasing new debconf templates:
>  http://www.perrier.eu.org/weblog/2008/07/15#anti-l10n-cabal

Lenny freeze is going to start the next week.., I think I haven't any chance to
upload atmailopen in time..., right?




[...]

> The database  can be  remote (this is  handled by  dbconfig-common). You
> should only suggests mysql-server  and depends on mysql-client (which is
> needed for dbconfig-common operations).

Thanks for your review, I'm waiting new upstream version and I will fix them.


Giuseppe Iuculano.

[Vincent Bernat-3]

OoO En cette nuit striée d'éclairs du lundi 21 juillet 2008, vers 02:30,
Giuseppe Iuculano <giuseppe@...> disait :

>> You  introduce a debconf  templates. I  see that  you already  have some
>> translations. However,  I don't find  your call for  translations. Until
>> lenny  is  released, this  is  better  to  ask for  translations  before
>> releasing new debconf templates:
>> http://www.perrier.eu.org/weblog/2008/07/15#anti-l10n-cabal

> Lenny freeze is going to start the next week.., I think I haven't any chance to
> upload atmailopen in time..., right?

Up-to-date  translations  may be  a  good  argument  to ask  for  freeze
exception. Not guaranteed.
--
BEANS ARE NEITHER FRUIT NOR MUSICAL
BEANS ARE NEITHER FRUIT NOR MUSICAL
BEANS ARE NEITHER FRUIT NOR MUSICAL
-+- Bart Simpson on chalkboard in episode 1F22

[Giuseppe Iuculano]

Hi Vincent,


Vincent Bernat wrote:
> Some    files     have    a    different     license.    For    example,
> libs/Atmail/spellChecker.php. The license given  as URL is non-free. You
> will  need to  work with  upstream  to sort  this out.  Check all  files
> individually. The license which is in the headers is more important than
> the one in LICENSE file.

Upstream fixes this issue in SVN, so I repackaged Atmail svn revision(48)



>
> You  introduce a debconf  templates. I  see that  you already  have some
> translations. However,  I don't find  your call for  translations. Until
> lenny  is  released, this  is  better  to  ask for  translations  before
> releasing new debconf templates:
>  http://www.perrier.eu.org/weblog/2008/07/15#anti-l10n-cabal

Lenny is frozen, and atmailopen is not yet in Debian, should I run
podebconf-report-po ?


>
> You  may  also  want  to  ask  debian-l10n-english@  to  proofread  your
> templates before asking for translation. This will be done at some point
> in the future, so doing it now will ease translators work.

As you suggested, I'm using roundcube and torrentflux templates, and they should
have been reviewed by the debian-l10n-english.


> Setting global  aliases is considered harmful, you  should comment alias
> declaration in  your apache.conf. The  user will have to  uncomment this
> directive. This  ensures that nothing bad happens  when someone installs
> atmail. See for example:
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=476162

Done.

> conf/Config.php is really  huge. You could split it  in several files if
> some  parts are  more  likely to  be  modified by  the  user than  other
> ones. This way,  if a user will modify  only a small part of  a file, he
> won't have  to read a big  diff. At least  PHP functions at the  end are
> good candidates to be put in another file, IMO.

Done, debian modifications are now in /etc/atmailopen/debian.php


> In the long description, what does  "PHP source code" means. If it means
> that AtMail is open source, you can just remove it.

Removed

>
> Since  AtMail will  write in  /usr/share/atmailopen/users, it  should be
> placed  in /var/lib/atmailopen  instead.  AtMail should  work with  /usr
> being mounted as read-only.

Done.

> You  still support  web servers  that are  not part  of  Debian (apache,
> apache-ssl, apache-perl) any more. Some people don't like this. You ship
> a configuration for lighttpd but does not propose to install it. You can
> look at roundcube package for some hints about this.
>
> Moreover, you modify the configuration of the web servers without asking
> the user first. This is bad.  You should add a debconf question.  If you
> take the one from roundcube, you can save some translations too. :)
>
> In postrm, you should remove web server configuration files on purge.
>
> The database  can be  remote (this is  handled by  dbconfig-common). You
> should only suggests mysql-server  and depends on mysql-client (which is
> needed for dbconfig-common operations).

Done.

Reuploaded:

- URL: http://mentors.debian.net/debian/pool/main/a/atmailopen
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/a/atmailopen/atmailopen_1.02+svn48-1.dsc



Giuseppe Iuculano.

[Vincent Bernat-3]

OoO En  cette soirée  bien amorcée  du jeudi 28  août 2008,  vers 22:29,
Giuseppe Iuculano <giuseppe@...> disait :

>> Some    files     have    a    different     license.    For    example,
>> libs/Atmail/spellChecker.php. The license given  as URL is non-free. You
>> will  need to  work with  upstream  to sort  this out.  Check all  files
>> individually. The license which is in the headers is more important than
>> the one in LICENSE file.

> Upstream  fixes  this  issue  in  SVN,  so  I  repackaged  Atmail  svn
> revision(48)

I don't remember if those files  were here on last upload, but there are
a lot of files with non DFSG-free licenses:
 ./libs/PEAR/Mail/smtp.php: PHP (v2.02)
 ./libs/PEAR/DB.php: PHP (v3.0)
 ./libs/PEAR/Net/SMTP.php: PHP (v2.02)
 ./libs/PEAR/Net/Socket.php: PHP (v2.0)
 ./libs/PEAR/DB/mysqli.php: PHP (v3.0)
 ./libs/PEAR/DB/common.php: PHP (v3.0)
 ./libs/PEAR/DB/mssql.php: PHP (v3.0)
 ./libs/PEAR/DB/sqlite.php: PHP (v3.0)
 ./libs/PEAR/DB/mysql.php: PHP (v3.0)
 ./libs/PEAR/Mail.php: PHP (v2.02)
 ./libs/PEAR/PEAR.php: PHP (v3.0)

Moreover, there  are a lot  of files which  are released with  a license
different of  Apache 2.0  license. Even if  those are free  licenses and
even if  you don't ship  any of those  files in the Debian  package, you
should cite them in debian/copyright.

You  can also just  exclude all  those files  from orig.tar.gz.  In this
case, put "dfsg" somewhere in the version string (1.02+svn48.dfsg-1) for
example. And  you should add a note  in README.source on how  to get the
source  package from  SVN (and,  better,  add an  appropriate target  in
debian/rules like get-orig-source).


>> You  introduce a debconf  templates. I  see that  you already  have some
>> translations. However,  I don't find  your call for  translations. Until
>> lenny  is  released, this  is  better  to  ask for  translations  before
>> releasing new debconf templates:
>> http://www.perrier.eu.org/weblog/2008/07/15#anti-l10n-cabal

> Lenny is frozen, and atmailopen is not yet in Debian, should I run
> podebconf-report-po ?

I think that  you can. Those templates are unlikely  to change until the
upload is ready.

Other remarks:
 * php5 depends on php5-cgi (as  an alternative), so you can just depend
   on php5.
 * "$popimap_debug_file='/tmp/popimap_debug'"   can   lead  to   symlink
   attacks. Use something in  /var/log/atmailopen. If this is enabled by
   default, don't forget to add a rule in logrotate.
 * the binary-arch seems to be missing in debian/rules

Seems fine otherwise.
--
 /* James M doesn't say fuck enough. */
        2.4.3 linux/net/core/netfilter.c

[Giuseppe Iuculano]

Vincent Bernat ha scritto:

> You  can also just  exclude all  those files  from orig.tar.gz.  In this
> case, put "dfsg" somewhere in the version string (1.02+svn48.dfsg-1) for
> example. And  you should add a note  in README.source on how  to get the
> source  package from  SVN (and,  better,  add an  appropriate target  in
> debian/rules like get-orig-source).
>

Done



>
> I think that  you can. Those templates are unlikely  to change until the
> upload is ready.

Done.

>
> Other remarks:
>  * php5 depends on php5-cgi (as  an alternative), so you can just depend
>    on php5.
>  * "$popimap_debug_file='/tmp/popimap_debug'"   can   lead  to   symlink
>    attacks. Use something in  /var/log/atmailopen. If this is enabled by
>    default, don't forget to add a rule in logrotate.
>  * the binary-arch seems to be missing in debian/rules

Fixed.

Reuploaded on mentors, thanks.



Giuseppe Iuculano.

[Giuseppe Iuculano]

Giuseppe Iuculano ha scritto:
> I think that  you can. Those templates are unlikely  to change until the
>> upload is ready.
>
> Done.
>

Uploaded again with new debconf translation.

Mentors seems down, uploaded here: http://sd6.iuculano.it/atmailopen/


Giuseppe.

[Vincent Bernat-3]

OoO En cette  fin de matinée radieuse du samedi  13 septembre 2008, vers
11:10, Giuseppe Iuculano <giuseppe@...> disait :

> Mentors seems down, uploaded here: http://sd6.iuculano.it/atmailopen/

Hi Giuseppe!

You removed  the binary-arch  target completely. It  is required  by the
policy  (for   example,  for   a  buildd  that   only  wants   to  build
arch-dependent packages because other are built by other buildd).

You should add it back:

binary-arch:
binary: binary-indep binary-arch

popimap_debug_file variable still points to  a location in /tmp. Make it
point to a file in /var/log/atmailopen to avoid any symlink attack.
--
printk("??? No FDIV bug? Lucky you...\n");
        2.2.16 /usr/src/linux/include/asm-i386/bugs.h