This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 225575 - Review Request: roundcubemail - Round Cube Webmail is a browser-based multilingual IMAP client
Review Request: roundcubemail - Round Cube Webmail is a browser-based multili...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernard Johnson
Fedora Package Reviews List
:
Depends On: 239436
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 08:35 EST by Jon Ciesla
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-29 07:20:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
bjohnson: fedora‑review+
wtogami: fedora‑cvs+


Attachments (Terms of Use)
cleanups and fixes (3.83 KB, patch)
2007-05-09 15:28 EDT, Bernard Johnson
no flags Details | Diff
diff against comment #46 (1.43 KB, patch)
2007-05-09 16:54 EDT, Bernard Johnson
no flags Details | Diff
a few more cleanups and fixes against comment #53 (3.17 KB, patch)
2007-05-10 20:07 EDT, Bernard Johnson
no flags Details | Diff

  None (edit)
Description Jon Ciesla 2007-01-31 08:35:22 EST
Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.spec
SRPM URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-beta2.2.src.rpm
Description: RoundCube Webmail is a browser-based multilingual IMAP client
with an application-like user interface. It provides full
functionality you expect from an e-mail client, including MIME
support, address book, folder manipulation, message searching
and spell checking. RoundCube Webmail is written in PHP and
requires the MySQL database. The user interface is fully
skinnable using XHTML and CSS 2.

I am sponsored already, and this is a Wishlist package.
Comment 1 Xavier Lamien 2007-01-31 09:58:33 EST
---Spec file review ---

* your %define is not especially necessary
* Buildroot doesn't right, it misses one "-" just after "root" (must be fix).
* Use 'mkdir -p' instead of 'install -d' as below in you field %install
* Use 'install -m 644 *' instead of 'cp -pr *' for install all files in
%{_datadir}/roundcubemail with 644 permission, like that, you will not have to
atribute permissions to each files and sub-directories in %files.
* You should comment why you modify or remove file from main tarball in spec
file for more understanding and best review.
* Doc INSTALL should not be includes in the package (must be fix)
* Many of files listed twice in %files section (must be fix).
* %attr(0644-root,root) can be set in %intall section.
* You shoul define the default maccros in %files.

--- rpmlint error ---

* from srpm: clean

* from rpm: 

E: roundcubemail non-standard-gid /usr/share/roundcubemail/temp apache
E: roundcubemail non-standard-dir-perm /usr/share/roundcubemail/temp 0775
E: roundcubemail non-standard-gid /usr/share/roundcubemail/logs apache
E: roundcubemail non-standard-dir-perm /usr/share/roundcubemail/logs 0775

All must be Fix.
Comment 2 Gianluca Sforna 2007-01-31 11:31:49 EST
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224245#c2

says it bundles code incompatible with GPL. is it a blocker?
Comment 3 Jon Ciesla 2007-01-31 11:36:06 EST
Which code?  I'll ask on that thread as well.
Comment 4 Tomas 2007-01-31 12:31:33 EST
PHP Pear libraries are licensed under PHP license. 
http://www.gnu.org/philosophy/license-list.html#GPLIncompatibleLicenses

I am not a lawyer, but I suspect that you can't bundle GPL code with code
incompatible with GPL.

If code can't handle plural forms and is difficult to maintain translations, I
wouldn't call it multilingual.

$messages['searchsuccessful'] = '$nr messages found';

This string can have up to four different translations, that depend in $nr value.

Translation should not contain variables. sprintf('%d messages found',$nr)
Comment 5 Jon Ciesla 2007-01-31 12:36:20 EST
Roundcube ships Googiespell 2.1, which says it's MIT Licensed, so that's fine. 
The current is 3.4, which is GPL.

It also includes code Licensed under PHP License 3.0 and 2.02, which are GPL
incompatible.

Based on
http://fedoraproject.org/wiki/Packaging/Guidelines#head-76294f12c6b481792eb001ba9763d95e2792e825,
I don't think any of this is a problem.  Will post to the squirrelmail bug.
Comment 6 Rex Dieter 2007-01-31 12:43:21 EST
> I don't think any of this is a problem

It *is* a problem, roundcubemail is GPL and it is including/using
GPL-incompatible (php license) code.  roundcude upstream developers should be
made aware of this.
Comment 7 Jon Ciesla 2007-01-31 12:48:59 EST
Ok. I'll notify them.  If they won't re-release without the PHP-Licensed code,
I'll close the bug.

I'd think they could.  It looks like it's stuff from PEAR anyway, and the DB
part at least is in Extras.
Comment 8 Warren Togami 2007-01-31 12:49:44 EST
(While the GPL compatibility issue must be fixed upstream, this is a separate
question.)

Why is roundcube including a copy of a PHP Pear library within its own source?

If software uses a Pear library, that library sholud be packaged independently
for Fedora.
Comment 9 Jon Ciesla 2007-01-31 12:58:55 EST
Agreed.  That's very strange.  I sent this upstream:

Hi.

I was attempting to package Roundcube for inclusion in Fedora Extras.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=225575

During the review process, we hit a snag.  Portions of the code distributed with
Roundcube are Licensed under the PHP 3.0 and PHP 2.02 licenses, which are
GPL-incompatible.  

This is a legal no-no:
http://www.gnu.org/licenses/gpl-faq.html#MereAggregation

I wanted to make you aware of this:

A: For your protection

B: So that, if this is corrected, we can continue our efforts to include
Roundcube in Fedora Extras.

Please let me know what action you intend to take, if any.

Thank you!

Jon Ciesla
Comment 10 Jon Ciesla 2007-01-31 13:37:57 EST
Response from upstream:
2007/1/31, Jon Ciesla <limb@jcomserv.net>:
>
> During the review process, we hit a snag.  Portions of the code
> distributed with Roundcube are Licensed under the PHP 3.0 and PHP 2.02
> licenses, which are GPL-incompatible.

Hmm, which parts are not GPL? I wasn't aware of that.

> Please let me know what action you intend to take, if any.

Could we just describe those files/packages as a dependency instead of
including them with the package? Please sorry for this stupid question
but license stuff always confuses me.
>
> Thank you!
>
> Jon Ciesla
>
Regards,
Thomas

My reply:
The parts from PEAR, namely DB, Auth, Net and Mail.  You need to let the end
user install them on their own, since they're readily available and
GPL-incompatible.  This won't be an issue for Fedora, as they're all available
as Extras packages which Roundcube can require as dependencies. 

Also, where are the .map files in program/lib/encoding from?  How are they
licensed?  There's a contact address in them from microsoft, which in the
absence of concrete licensing information in the utf8.class.php file makes it
likely that it can't be redistributed with GPL code.

Taking care of the PEAR parts shouldn't be a problem, but the utf stuff probably
should go and be replaced with something using this:

http://us2.php.net/manual-lookup.php?pattern=utf&lang=en

I hope this is helpful.

-------------

We'll see where it goes.
Comment 11 Tomas 2007-01-31 13:58:37 EST
(In reply to comment #10)
> Also, where are the .map files in program/lib/encoding from?  How are they
> licensed?  There's a contact address in them from microsoft, which in the
> absence of concrete licensing information in the utf8.class.php file makes it
> likely that it can't be redistributed with GPL code.

Mappings are distributed by Unicode consortium.

http://ftp.unicode.org/Public/MAPPINGS/

Comment 12 Jon Ciesla 2007-01-31 14:09:14 EST
Ah. So all he has to do is pull the PEAR code and I'll get on fixing the many
.spec issues. :)
Comment 13 Bernard Johnson 2007-01-31 21:01:30 EST
%attr(0775,root,apache) %{roundcubedir}/temp

temporary files should be created in /tmp, /var/cache/roundcubemail, or possibly
another directory depending on usage, but NEVER under /usr 

%attr(0775,root,apache) %{roundcubedir}/logs

same for logs, except /var/log if a single log or /var/log/roundcubemail if
multiple logs
Comment 14 Jon Ciesla 2007-02-01 08:04:04 EST
Upstream's response:
--------------
2007/1/31, Jon Ciesla <limb@jcomserv.net>:
> The parts from PEAR, namely DB, Auth, Net and Mail.  You need to let the
> end user install them on their own, since they're readily available and
> GPL-incompatible.  This won't be an issue for Fedora, as they're all
> available as Extras packages which Roundcube can require as dependencies.

OK, I'll take care of that.
>
> Also, where are the .map files in program/lib/encoding from?  How are they
> licensed?  There's a contact address in them from microsoft, which in the
> absence of concrete licensing information in the utf8.class.php file makes
> it likely that it can't be redistributed with GPL code.

The map files are from ftp://ftp.unicode.org/Public/MAPPINGS/
and the utf8.class contains the following line:
"License: Choose the more appropriated for You - I don't care."
>
> Taking care of the PEAR parts shouldn't be a problem, but the utf stuff
> probably should go and be replaced with something using this:
>
> http://us2.php.net/manual-lookup.php?pattern=utf&lang=en

utf8_encode only works from latin to utf8 but does not support other
charsets. RoundCube tries to use mbstring, iconv and
utf8_encode/decode methods and only if none of them is available or if
those do not support the requested charset the utf8.class with the
mapping files will be used.
See program/include/main.inc : rcube_charset_convert() for details about this.

If the PHP installation of the Fedora package includes mbstring you
could actually deliver RoundCube without these utf8 files.
>
> I hope this is helpful.

Thanks!
Thomas
---------------

My reply:

---------------
> OK, I'll take care of that.

Great, let me know when the new release is out.

> 
> The map files are from ftp://ftp.unicode.org/Public/MAPPINGS/
> and the utf8.class contains the following line:
> "License: Choose the more appropriated for You - I don't care."

IANAL, but it sounds fine, if a bit unwise on the copyright holder's part.

> 
> utf8_encode only works from latin to utf8 but does not support other
> charsets. RoundCube tries to use mbstring, iconv and
> utf8_encode/decode methods and only if none of them is available or if
> those do not support the requested charset the utf8.class with the
> mapping files will be used.
> See program/include/main.inc : rcube_charset_convert() for details about
> this.
> 
> If the PHP installation of the Fedora package includes mbstring you
> could actually deliver RoundCube without these utf8 files.

I'll require php-mbstring in the Fedora package, so if you ever deprecate this
and just list mbstring as a requirement (which I recommend, as it's fairly
common), it won't impact Fedora.

Eagerly awaiting the new release,
Jon
Comment 15 Matthias Saou 2007-02-13 13:30:19 EST
Any answer yet? Would it be worth trying to make a package based on a modified
version of the current release, which would have all non GPL licensed code
ripped out?
Comment 16 Rex Dieter 2007-02-13 13:38:02 EST
> Would it be worth trying to make a package based on a modified
> version of the current release...

That should be ok.
Comment 17 Jon Ciesla 2007-02-13 13:42:10 EST
(In reply to comment #16)
> > Would it be worth trying to make a package based on a modified
> > version of the current release...
> 
> That should be ok.

I'll get on that and re-post SRPM and SPEC.  I can follow up with upstream and
re-release later.
Comment 18 Jon Ciesla 2007-02-15 11:46:00 EST
New SRPM and spec, sans GPL-incompatible code.  Builds fine, runs fine.

Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.1.spec
SRPM URL:
http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-beta2.2.1.src.rpm

However:
[limb@forge SPECS]$ rpmlint -i ../RPMS/noarch/roundcubemail-0.1-beta2.2.1.noarch.rpm
W: roundcubemail dangling-relative-symlink /usr/share/roundcubemail/temp
../../../var/tmp
The relative symbolic link points nowhere.

But once installed, this link is fine.  Am I missing something obvious?  I'm
also listing the whole thing in FILES and listing some within that indidually so
set permissions, as some things in the tarball are set executable for absolutely
no reason.  Any problem with this?
Comment 19 Jon Ciesla 2007-03-09 12:45:37 EST
Update: No new release from upstream, but I've been using the above RPM on my
own server for a month now and it's fine.  Any takers for a review? :)
Comment 20 Bernard Johnson 2007-05-04 02:46:25 EDT
If I read the comments correctly, all GPL compatability issues have been worked out.

If that is the case, I will provide you with a review, just let me know.
Comment 21 Jon Ciesla 2007-05-04 07:26:26 EDT
Yes. All I need to do is construct a source tarball that doesn't include the
conflicting material and add the explanation to the .spec.  Shall I do that and
let you start from there?
Comment 22 Jon Ciesla 2007-05-04 08:20:14 EDT
Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.2.spec
SRPM URL:
http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-beta2.2.2.src.rpm

Spec and SRPM with the above issue addressed.

Thanks in advance for the review.
Comment 23 Bernard Johnson 2007-05-05 13:48:54 EDT
Roundcubemail claims to support sqlite databases, but I've been unsuccessful in
getting it to work.  

In db.inc.php I have:
$rcmail_config['db_dsnw'] = 'sqlite://./sqlite.db?mode=646';

and whenever I try to load roundcubemail, I get this in the log file:
[05-May-2007 11:42:22 -0600] DB Error: DB Error: extension not found in
/usr/share/roundcubemail/program/include/rcube_db.inc on line 105

Looking at the spec file for php, I'm actually quite confused as to whether
sqlite support is even built into php.  Can someone shed some light on this?
Comment 24 Tomas 2007-05-06 07:01:50 EDT
(In reply to comment #23)
> Roundcubemail claims to support sqlite databases, but I've been unsuccessful in
> getting it to work.  
> 
> In db.inc.php I have:
> $rcmail_config['db_dsnw'] = 'sqlite://./sqlite.db?mode=646';
> 
> and whenever I try to load roundcubemail, I get this in the log file:
> [05-May-2007 11:42:22 -0600] DB Error: DB Error: extension not found in
> /usr/share/roundcubemail/program/include/rcube_db.inc on line 105
> 
> Looking at the spec file for php, I'm actually quite confused as to whether
> sqlite support is even built into php.  Can someone shed some light on this?
> 

Please note that this is not roundcube or php support forum. Error message says
that sqlite extension (http://www.php.net/sqlite) is not available. FC6 compiles
PHP without sqlite support.
Comment 25 Jon Ciesla 2007-05-06 16:50:26 EDT
Actually, I forget the name off the top of my head, but depending on how
roundcube is coded, it may work with the PHP PDO SQLite package, already in fedora.
Comment 26 Bernard Johnson 2007-05-07 02:06:28 EDT
(In reply to comment #24)
> Please note that this is not roundcube or php support forum.

Well, perhaps if I had written "roundcubemail RPM" claims to support sqlite...
you'd have gotten what I meant.  This is a package review.  If the package has
information that indicates that you can use sqlite and you in fact can not, then
that will lead to a poor user experience (and many bug reports).  And it is
things like this, among many others, that I'm checking for.

(In reply to comment #25)
> Actually, I forget the name off the top of my head, but depending on how
> roundcube is coded, it may work with the PHP PDO SQLite package, already in
fedora.

You may be right (PHP is definately not my expertise).  However, everything that
I've been able to read about the PDO sqlite extension implies that it's not a
drop in replacement.

Unless someone can show that it works with roundcubemail, I think we are going
to have to assume that it does not.

This is too bad, because it would be nice to have sqlite as the default out of
the box experience.  This would allow you to install the package and have it
immediately work against an existing imap server without messing around with
configuration files and setting up a mysql/pgsql database, which is quite a pain
for this simple of an application.

Unless it can be shown to work with sqlite, I think we should remove the example
line in db.inc.php.  There's no point in giving it as an example if it simply
won't work.

This also warrants a README.fedora file in %doc to explain database support
available, lack of sqlite support, and basic instructions for settings up (or
pointing to included docs - maybe the INSTALL file?) database support.

Here are some things that I've noticed so far that need corrected:

1) /usr/share/roundcubemail/{CHANGELOG,INSTALL,LICENSE,README,UPGRADING} should
be removed.

2) Rather than creating symlinks from /usr/share/roundcubemail to other
directories, I think it would be more clear to edit the main.inc.php with the
real paths.  The indirection of symbolic links don't buy you anything.

in %prep, for example:
sed -i 's|temp/|/tmp/|' main.inc.php
and again for log dir,
and config (in program/include/main.inc)

3) I'm still looking into the security implications of having a static des_key.
 This might be a candidate for automatic generation in %post.

4) move SQL to %doc

5) /var/log/roundcubemail should have %attr(0775,root,apache), currently it is
unwritable by apache process

6) Package should require httpd

7) Install *.dist files as regular config files, we know they have to be changed
anyway at this point, and the error that roundcubemail reports with them
installed or not installed is the same.

8) /etc/roundcubemail/* should be mode 640 (contain sensitive information)

9) would appreciate lines between changelog entries as it's easier to read :)

10) What's up with the versioning? 
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a

11) Need to investigate selinux policy for package.

More to come later.  You can rebuild the rpm with these changes or we can
discuss anything here that you think is not appropriate.
Comment 27 Tomas 2007-05-07 03:58:14 EDT
(In reply to comment #26)
> (In reply to comment #24)
> > Please note that this is not roundcube or php support forum.
> 
> Well, perhaps if I had written "roundcubemail RPM" claims to support sqlite...
> you'd have gotten what I meant.  This is a package review.  If the package has
> information that indicates that you can use sqlite and you in fact can not, then
> that will lead to a poor user experience (and many bug reports).  And it is
> things like this, among many others, that I'm checking for.

Roundcube rpm does not claim that you can use sqlite. Upstream documentation
does. rpm says "RoundCube Webmail is written in PHP and requires the MySQL
database." If packager starts fixing upstream documentation without cooperation
with upstream, he or she will have issues with package updates.

RoundCube should work with mysql, mysqli, postgresql and sqlite, if your PHP
install has required database functions. If developer removes remaining database
specific function calls and turns on DB/MDB2 portability options, interface will
work with all databases supported by Pear DB/MDB2. Pear DB/MDB2 libraries don't
support PDO. If you want SQLite support without changes in Fedora's PHP
packages, write PDO backend for roundcube.

Your question does look like support question, because you haven't bothered to
do basic PHP tests (see http://www.php.net/phpinfo) and ask on bugzilla how to
do that.
Comment 28 Jon Ciesla 2007-05-07 09:41:35 EDT
Upon further investigation, it looks like RC only supports the
SQLite2-supporting native PHP5 extension, not the SQLite3-supporting PDO
extension provided by php-pdo.

I'll add something to included documentation indicating a lack of SQLite support
in Fedora, as well as the other issues, soon.
Comment 29 Jon Ciesla 2007-05-07 09:57:34 EDT
Addressed 1,4,5,6,7,8,9.  Will look at 2.  Will wait for advice on 3 and 11.

10.  The versioning is admittedly odd.  Shall I change to the linked format, 0.xyz?
Comment 30 Bernard Johnson 2007-05-07 13:43:57 EDT
(In reply to comment #27)
> Roundcube rpm does not claim that you can use sqlite. Upstream documentation
> does. rpm says "RoundCube Webmail is written in PHP and requires the MySQL
> database." If packager starts fixing upstream documentation without cooperation
> with upstream, he or she will have issues with package updates.

Well, if it says it works with X but doesn't on Fedora that has to be fixed (doc
fixes or code fixes).  The following files say that it works with sqlite:
CHANGELOG
INSTALL
db.inc.php

These are some of the first files you're going to look at if you start setting
it up.  Therefore, my question was valid, because it does not work on fedora as
advertised.

> "RoundCube Webmail is written in PHP and requires the MySQL
> database."

Which is incorrect as well.

> write PDO backend for roundcube.

Note that no one here is a roundcube developer, but Fedora packagers.  If Jon
wants to write this, that would be great, but it's not required of him.
 
> Your question does look like support question, because you haven't bothered to
> do basic PHP tests (see http://www.php.net/phpinfo) and ask on bugzilla how to
> do that.

As a reviewer I can ask any question I want regarding the functionality of the
package.  I'm not reviewing php, I'm reviewing roundcubemail, so if it doesn't
work as advertised, then I will ask why.


(In reply to comment #28)
> Upon further investigation, it looks like RC only supports the
> SQLite2-supporting native PHP5 extension, not the SQLite3-supporting PDO
> extension provided by php-pdo.

I'm assuming that this functionality will not be available for the full release?


(In reply to comment #29)
> 10.  The versioning is admittedly odd.  Shall I change to the linked format,
0.xyz?

Yes.  roundcubemail-0.1-0.1.beta2.2.src.rpm
                          ^
                          |--- increment this for releases

When 0.1 is released, then the version-release becomes
roundcubemail-0.1-1.src.rpm (increment the 0, drop the rest)


What are your plans regarding packaging the language files? 
http://sourceforge.net/project/showfiles.php?group_id=139281&package_id=180282
Comment 31 Jon Ciesla 2007-05-07 14:07:43 EDT
WRT SQLite support, I think editing the 3 relevant files and omitting mention of
SQLite support is the sanest method of handling this.  If you want, I can file a
bug against PHP asking that SQLite2 functionality be compiled in and then split
out in the a seperate package (a la mbstring or mysql).

And, FWIW, I did verify all this using phpinfo().  :)

I'll change the versioning. What part of that goes in the version tag and what
in release?

I've been playing with the sed scripts for log/config/tmp paths, and aside from
breaking the app, it re-introduces several rpmlint errors.

As for the language packs, I'm not sure how we handle that.  Would they require
seperate reviews, or could I combine with this SRPM?
Comment 32 Bernard Johnson 2007-05-07 14:17:19 EDT
(In reply to comment #31)
> WRT SQLite support, I think editing the 3 relevant files and omitting mention of
> SQLite support is the sanest method of handling this.

Actually, just the README.fedora inclusion and then edit out the sqlite example
ref in db.inc.php should be sufficient.

> I'll change the versioning. What part of that goes in the version tag and what
> in release?

Version 0.1
Release 0.1.beta2.2 

> I've been playing with the sed scripts for log/config/tmp paths, and aside from
> breaking the app, it re-introduces several rpmlint errors.

What are those?
 
> As for the language packs, I'm not sure how we handle that.  Would they require
> seperate reviews, or could I combine with this SRPM?

Depends on if you are going to include them as sourceX lines here and have a
single package for review or submit them separately.

Comment 33 Bernard Johnson 2007-05-07 15:09:44 EDT
(In reply to comment #32)
> Actually, just the README.fedora inclusion and then edit out the sqlite example
> ref in db.inc.php should be sufficient.

I would just do this in %prep:

sed -i '/sqlite/d' config/db.inc.php.dist

Then add the README.fedora.
Comment 34 Bernard Johnson 2007-05-08 00:04:30 EDT
(In reply to comment #26)
> 11) Need to investigate selinux policy for package.

I did just about everything I could with my setup and the only avc that I
managed to generate was:

audit(1178594537.211:25): avc:  denied  { name_connect } for  pid=31565
comm="httpd" dest=143 scontext=user_u:system_r:httpd_t:s0
tcontext=system_u:object_r:pop_port_t:s0 tclass=tcp_socket

Not sure why it says pop_port_t when I'm using imap but it will need to cover
ports 25, 143, 389, 465, 587, 993.

Please open a bug on selinux-policy-targeted as a blocker for this bug.  Ask for
a policy update to fix this avc.  Reference this bug and comment.  CC me please.

Also note that if you support sqlite at some point, it's likely that you're
going to have to have more changes.
Comment 35 Bernard Johnson 2007-05-08 00:16:08 EDT
(In reply to comment #26)
> 3) I'm still looking into the security implications of having a static des_key.
>  This might be a candidate for automatic generation in %post.

I hate putting complicated things in %post, but you should be able to do
something like this:

function makedesstr
(
chars=(0 1 2 3 4 5 6 7 8 9 a b c d e f g h i j k l m n o p q r s t u v w x y z A
B C D E F G H I J K L M N O P Q R S T U V W X Y Z ! @ \# $ % ^ \&)

max=${#chars[*]}

for i in `seq 1 24`
do

        let rand=${RANDOM}%${max}
        str="${str}${chars[$rand]}"
done
echo $str
)

sed -i "s/rcmail-\!24ByteDESkey\*Str/`makedesstr`/"
/etc/roundcubemail/main.inc.php || : &> /dev/null
Comment 36 Jon Ciesla 2007-05-08 09:45:45 EDT
Bug filed against s-p-t.
Comment 37 Jon Ciesla 2007-05-09 11:15:39 EDT
My permission errors brought about by log/temp/config path changes:
[limb@fawkes SPECS]$ rpmlint -i
../RPMS/noarch/roundcubemail-0.1-beta2.2.3.noarch.rpm 
E: roundcubemail non-standard-dir-perm /etc/roundcubemail 0640
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

E: roundcubemail non-readable /etc/roundcubemail/db.inc.php.dist 0640
The file can't be read by everybody. If this is expected (for security
reasons), contact your rpmlint distributor to get it added to the list of
exceptions for your distro (or add it to your local configuration if you
installed rpmlint from the source tarball).

E: roundcubemail non-standard-gid /var/log/roundcubemail apache
A file in this package is owned by a non standard group.
Standard groups are:
root, bin, daemon, sys, adm, tty, disk, lp, mem, kmem, wheel, mail,
news, uucp, man, games, gopher, dip, ftp, lock, nobody, users

E: roundcubemail non-standard-dir-perm /var/log/roundcubemail 0775
A standard directory should have permission set to 0755. If you get this
message, it means that you have wrong directory permissions in some dirs
included in your package.

E: roundcubemail non-readable /etc/httpd/conf.d/roundcubemail.conf 0640
The file can't be read by everybody. If this is expected (for security
reasons), contact your rpmlint distributor to get it added to the list of
exceptions for your distro (or add it to your local configuration if you
installed rpmlint from the source tarball).

W: roundcubemail spurious-executable-perm
/usr/share/doc/roundcubemail-0.1/SQL/postgres.initial.sql
The file is installed with executable permissions, but was identified as one
that probably should not be executable.  Verify if the executable bits are
desired, and remove if not.

E: roundcubemail non-readable /etc/roundcubemail/main.inc.php.dist 0640
The file can't be read by everybody. If this is expected (for security
reasons), contact your rpmlint distributor to get it added to the list of
exceptions for your distro (or add it to your local configuration if you
installed rpmlint from the source tarball).

W: roundcubemail conffile-without-noreplace-flag /etc/roundcubemail/db.inc.php.dist
A configuration file is stored in your package without the noreplace flag.
A way to resolve this is to put the following in your SPEC file:

%config(noreplace) /etc/your_config_file_here


W: roundcubemail conffile-without-noreplace-flag
/etc/roundcubemail/main.inc.php.dist
A configuration file is stored in your package without the noreplace flag.
A way to resolve this is to put the following in your SPEC file:

%config(noreplace) /etc/your_config_file_here
Comment 38 Bernard Johnson 2007-05-09 13:39:53 EDT
(In reply to comment #37)
> E: roundcubemail non-standard-dir-perm /etc/roundcubemail 0640

This is probably an error in your spec file.  You probably want this:
%dir %{_sysconfdir}/%{name}
%attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/*

> E: roundcubemail non-readable /etc/roundcubemail/db.inc.php.dist 0640
> E: roundcubemail non-standard-gid /var/log/roundcubemail apache
> E: roundcubemail non-standard-dir-perm /var/log/roundcubemail 0775

These are expected and can be safely ignored.

> E: roundcubemail non-readable /etc/httpd/conf.d/roundcubemail.conf 0640

There is no particular reason that that you can't have this as 0644.

> W: roundcubemail spurious-executable-perm

Change the mode on these files to 0644 with chmod or install -m in the %install
section.
 
> E: roundcubemail non-readable /etc/roundcubemail/main.inc.php.dist 0640

Expected. 

W: roundcubemail conffile-without-noreplace-flag /etc/roundcubemail/db.inc.php.dist
W: roundcubemail conffile-without-noreplace-flag
/etc/roundcubemail/main.inc.php.dist

It's complaining that these files are not marked with %config(noreplace). 
However, I thought you said you were now installing them as
/etc/roundcubemail/db.inc.php and /etc/roundcubemail/main.inc.php respectively.  

Comment 39 Bernard Johnson 2007-05-09 13:47:48 EDT
(In reply to comment #38)
> %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/*

%attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/%{name}/*
Comment 40 Bernard Johnson 2007-05-09 13:57:42 EDT
(In reply to comment #38)
> > W: roundcubemail spurious-executable-perm
> 
> Change the mode on these files to 0644 with chmod or install -m in the %install
> section.

Sorry for the followups, I missed a few things without looking at the spec.  I
don't think you need any executables in the source files, so you should be able to:

In %prep (after %setup), run

find . -type f -print | xarg chmod a-x

Then all those %attr lines with %roundcubemail can be replaced by just:
%{roundcubedir}
because there won't be permissions to fix (that's causing duplicate file
listings in the rpm anyway).

These odd permissions should be reported upstream as "undesirable".
Comment 41 Jon Ciesla 2007-05-09 14:05:39 EDT
(In reply to comment #39)
> (In reply to comment #38)
> > %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/*
> 
> %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/%{name}/*

Thanks, I intuited that. :)

(In reply to comment #40)
> (In reply to comment #38)
> > > W: roundcubemail spurious-executable-perm
> > 
> > Change the mode on these files to 0644 with chmod or install -m in the %install
> > section.
> 
> Sorry for the followups, I missed a few things without looking at the spec.  I
> don't think you need any executables in the source files, so you should be
able to:
> 
> In %prep (after %setup), run
> 
> find . -type f -print | xarg chmod a-x
> 
> Then all those %attr lines with %roundcubemail can be replaced by just:
> %{roundcubedir}
> because there won't be permissions to fix (that's causing duplicate file
> listings in the rpm anyway).
> 
> These odd permissions should be reported upstream as "undesirable".
> 

That's great, but what's xarg?
[limb@fawkes SPECS]$ rpmbuild -ba roundcubemail.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.91340
+ umask 022
+ cd /usr/src/redhat/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /usr/src/redhat/BUILD
+ rm -rf roundcubemail-0.1beta2
+ /bin/gzip -dc /usr/src/redhat/SOURCES/roundcubemail-0.1beta2.2.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd roundcubemail-0.1beta2
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ find . -type f -print
+ xarg chmod a-x
/var/tmp/rpm-tmp.91340: line 37: xarg: command not found
error: Bad exit status from /var/tmp/rpm-tmp.91340 (%prep)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.91340 (%prep)
Comment 42 Bernard Johnson 2007-05-09 14:08:10 EDT
(In reply to comment #41)
> That's great, but what's xarg?

xargs... sorry
Comment 43 Jon Ciesla 2007-05-09 14:22:41 EDT
Ok, that works for perms, save the non-standard warnings.  Still breaks the app,
Error 500, though.

Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.3.spec
SRPM URL:
http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-beta2.2.3.src.rpm

Still haven't addressed the DES issue, will soon.
Comment 44 Jon Ciesla 2007-05-09 15:03:17 EDT
Added your DES suggestion, got this: 

W: roundcubemail percent-in-%post
E: roundcubemail shell-syntax-error-in-%post

Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.4.spec
SRPM URL:
http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-beta2.2.4.src.rpm
Comment 45 Bernard Johnson 2007-05-09 15:28:18 EDT
Created attachment 154419 [details]
cleanups and fixes

> Ok, that works for perms, save the non-standard warnings.  Still breaks the
app,
> Error 500, though.

Here is a diff against your spec in comment #43.  It has misc cleanups and
fixes.	

rpmlint output, all expected:
E: roundcubemail non-standard-gid /etc/roundcubemail/main.inc.php apache
E: roundcubemail non-readable /etc/roundcubemail/main.inc.php 0640
E: roundcubemail non-standard-gid /var/log/roundcubemail apache
E: roundcubemail non-standard-dir-perm /var/log/roundcubemail 0775
E: roundcubemail non-standard-gid /etc/roundcubemail/db.inc.php apache
E: roundcubemail non-readable /etc/roundcubemail/db.inc.php 0640
W: roundcubemail incoherent-version-in-changelog 0.1-beta2.2.3
0.1-0.1.beta2.2.fc6

(last line will be fixed when you update the changelog)
Comment 46 Jon Ciesla 2007-05-09 15:51:11 EDT
A definite improvement.  I can use the app as installed.  Now it's just the
non-standard rpmlint errors and the following from the DES scriptlet on %post:

[root@zanoni limb]# rpm -Uvh roundcubemail-0.1-beta2.3.noarch.rpm 
Preparing...                ########################################### [100%]
   1:roundcubemail          warning: /etc/roundcubemail/db.inc.php created as
/etc/roundcubemail/db.inc.php.rpmnew
warning: /etc/roundcubemail/main.inc.php created as
/etc/roundcubemail/main.inc.php.rpmnew
########################################### [100%]
/var/tmp/rpm-tmp.92232: line 10: syntax error near unexpected token `let'
/var/tmp/rpm-tmp.92232: line 10: `        let rand=${RANDOM}%${max}'
error: %post(roundcubemail-0.1-beta2.3.noarch) scriptlet failed, exit status 2

Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.5.spec
SRPM
URL:http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-beta2.3.src.rpm
Comment 47 Bernard Johnson 2007-05-09 16:54:16 EDT
Created attachment 154428 [details]
diff against comment #46

Please note your version-release is still wrong.  Your releases should be going
like this:

roundcubemail-0.1-0.1.beta2.2
roundcubemail-0.1-0.2.beta2.2
roundcubemail-0.1-0.3.beta2.2
roundcubemail-0.1-0.4.beta2.2
etc

and when 0.1 is released:
roundcubemail-0.1-1

I think the percent-in-%post is a false positive, but I'll look into it
further.
Comment 49 Jon Ciesla 2007-05-10 08:45:35 EDT
The translations are 8k a piece and there are 23 of them.  Is there any point to
not including them in the base package?
Comment 51 Bernard Johnson 2007-05-10 13:46:23 EDT
(In reply to comment #47)
> I think the percent-in-%post is a false positive, but I'll look into it
> further.

FYI, it is a false positive: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239611#c1
Comment 52 Bernard Johnson 2007-05-10 13:56:24 EDT
Somewhere you've got some bad mojo going on.  Either cut & paste or transferring
your spec files or something.  Note the control characters (^S and ^M) in the
lines below and the fact that the `` characters have been stripped from the
original script.


for i in ^Seq 1 24; do

sed -i "s/rcmail-\!24ByteDESkey\*Str/^Makedesstr/"
/etc/roundcubemail/main.inc.php || : &> /dev/null
Comment 53 Jon Ciesla 2007-05-10 14:27:06 EDT
Looks like joe was converting the `S and `M into control chars.  I was able to
correct it with Emacs.

Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.8.spec
SRPM
URL:http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-0.3.beta2.2.src.rpm
Comment 54 Bernard Johnson 2007-05-10 20:07:15 EDT
Created attachment 154507 [details]
a few more cleanups and fixes against comment #53

I'll start your official review shortly since things look pretty good at this
point.

Included is a patch with a few more cleanups to make things look nicer and a
few corrections.

You still need to write the README.fedora regarding the database availability
and sqlite (already referenced it in my diff :).

I believe you can now reduce your roundcubemail.conf file to this, as the other
restrictions are not necessary now that those paths are not accessible in the
web hierarchy:

#
# Round Cube Webmail is a browser-based multilingual IMAP client
#

Alias /roundcubemail /usr/share/roundcubemail

<Directory /usr/share/roundcubemail/>
	Order Deny,Allow
	Deny from all
	Allow from 127.0.0.1
</Directory>
Comment 55 Jon Ciesla 2007-05-11 08:00:50 EDT
Applied the above.  I bow to your superior script-fu. :)

Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.9.spec
SRPM
URL:http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-0.4.beta2.2.src.rpm

Comment 56 Bernard Johnson 2007-05-12 02:20:58 EDT
Package Review
==============

Key:
 - = N/A
 x = Check
 ! = Problem
 ? = Not evaluated

=== REQUIRED ITEMS ===
 [x] Package is named according to the Package Naming Guidelines.
 [x] Spec file name must match the base package %{name}, in the format %{name}.spec.
 [x] Package meets the Packaging Guidelines.
 [x] Package successfully compiles and builds into binary rpms on at least one
supported architecture.
     Tested on: FC6 / i386
 [x] Rpmlint output:
       E: roundcubemail non-standard-gid /var/log/roundcubemail apache
       E: roundcubemail non-standard-dir-perm /var/log/roundcubemail 0775
       E: roundcubemail non-standard-gid /etc/roundcubemail/main.inc.php apache
       E: roundcubemail non-readable /etc/roundcubemail/main.inc.php 0640
       E: roundcubemail non-standard-gid /etc/roundcubemail/db.inc.php apache
       E: roundcubemail non-readable /etc/roundcubemail/db.inc.php 0640
       W: roundcubemail percent-in-%post
 [x] Package is not relocatable.
 [x] Buildroot is correct
(%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n))
 [x] Package is licensed with an open-source compatible license and meets other
legal requirements as defined in the legal section of Packaging Guidelines.
 [x] License field in the package spec file matches the actual license.
     License type: GPL
       Packager has properly generated a custom tarball removing code that
       conflicts with GPL license.
 [x] If (and only if) the source package includes the text of the license(s) in
its own file, then that file, containing the text of the license(s) for the
package is included in %doc.
 [x] Spec file is legible and written in American English.
 [x] Sources used to build the package matches the upstream source, as provided
in the spec URL.
     MD5SUM this package    : 
       ac64aea002c4951b1a3005fe966082bf  roundcube_arabic-0.1-beta2.tar.gz
       c1d4e21cd1280a3f5f06892ddcd5f1b9  roundcube_armenian-0.1-beta2.tar.gz
       7817973ca9f280ee60980668401bf7f8  roundcube_brazilian-0.1-beta2.tar.gz
       fc98428238cb77af3c8f336aadc4168d  roundcube_catala-0.1-beta2.tar.gz
       71490edf78375bd273f1326d77d3e449  roundcube_chinese-0.1-beta2.tar.gz
       eb389dc044924b476a67cf7be2109714  roundcube_chinese-big5-0.1-beta2.tar.gz
       7252bc28846db945500ea45071f08012  roundcube_czech-0.1-beta2.tar.gz
       77202ea30056a63ff208cdade1eef279  roundcube_danish-0.1-beta2.tar.gz
       0b94ca8e149a443ab42bbb96b9c149df  roundcube_dutch-0.1-beta2.tar.gz
       b23398f6df2767c192f7498b6197ed3a  roundcube_estonian-0.1-beta2.tar.gz
       62963ef840c6f9f104119870a7486e19  roundcube_hungarian-0.1-beta2.tar.gz
       f5641dc92c9c76b7d3dd9da5656aae94  roundcube_italiano-0.1-beta2.tar.gz
       323ae63d544f0febf72418d0b44967ff  roundcube_japanese-0.1-beta2.tar.gz
       ba62761bbee19a8d91a1796fa4bb297a  roundcube_latvian-0.1-beta2.tar.gz
       50d48afe8cfee6b5db4a20eeaafd1fbf  roundcubemail-0.1beta2.2.tar.gz
       e72c13a77dde332b07417e41fbdd6434  roundcube_norwegian-0.1-beta2.tar.gz
       5455303054e3fcd70d38a9e2c01e9fa3  roundcube_polish-0.1-beta2.tar.gz
       fe38f58dadeb05806320d7ddadabb000  roundcube_portuguese-0.1-beta2.tar.gz
       f91874d95f46c830837335c5b33ef8b9  roundcube_romanian-0.1-beta2.tar.gz
       2e071a52d3ffdb4707a062d740f85691  roundcube_serbian-0-1-beta2.tar.gz
       6e021e49da6f64506b305bcd01c2e9c9  roundcube_slovak-0.1-beta2.tar.gz
       f577b2cce8dd031f427b5f3f343649f3  roundcube_swedish-0.1-beta2.tar.gz
       c28485169c7127b5f17584e6fe175280  roundcube_turkish-0.1-beta2.tar.gz
       25289980efaf7c655028e4ce889764cd  roundcube_vietnamese-0.1-beta2.tar.gz
     MD5SUM upstream package: 
       ac64aea002c4951b1a3005fe966082bf  roundcube_arabic-0.1-beta2.tar.gz
       c1d4e21cd1280a3f5f06892ddcd5f1b9  roundcube_armenian-0.1-beta2.tar.gz
       7817973ca9f280ee60980668401bf7f8  roundcube_brazilian-0.1-beta2.tar.gz
       fc98428238cb77af3c8f336aadc4168d  roundcube_catala-0.1-beta2.tar.gz
       71490edf78375bd273f1326d77d3e449  roundcube_chinese-0.1-beta2.tar.gz
       eb389dc044924b476a67cf7be2109714  roundcube_chinese-big5-0.1-beta2.tar.gz
       7252bc28846db945500ea45071f08012  roundcube_czech-0.1-beta2.tar.gz
       77202ea30056a63ff208cdade1eef279  roundcube_danish-0.1-beta2.tar.gz
       0b94ca8e149a443ab42bbb96b9c149df  roundcube_dutch-0.1-beta2.tar.gz
       b23398f6df2767c192f7498b6197ed3a  roundcube_estonian-0.1-beta2.tar.gz
       62963ef840c6f9f104119870a7486e19  roundcube_hungarian-0.1-beta2.tar.gz
       f5641dc92c9c76b7d3dd9da5656aae94  roundcube_italiano-0.1-beta2.tar.gz
       323ae63d544f0febf72418d0b44967ff  roundcube_japanese-0.1-beta2.tar.gz
       ba62761bbee19a8d91a1796fa4bb297a  roundcube_latvian-0.1-beta2.tar.gz
       e72c13a77dde332b07417e41fbdd6434  roundcube_norwegian-0.1-beta2.tar.gz
       5455303054e3fcd70d38a9e2c01e9fa3  roundcube_polish-0.1-beta2.tar.gz
       fe38f58dadeb05806320d7ddadabb000  roundcube_portuguese-0.1-beta2.tar.gz
       f91874d95f46c830837335c5b33ef8b9  roundcube_romanian-0.1-beta2.tar.gz
       47f2fc3fc5e0b3325ca3c3a360011a03  roundcube_russian-0.1-beta2.tar.gz
       2e071a52d3ffdb4707a062d740f85691  roundcube_serbian-0-1-beta2.tar.gz
       6e021e49da6f64506b305bcd01c2e9c9  roundcube_slovak-0.1-beta2.tar.gz
       f577b2cce8dd031f427b5f3f343649f3  roundcube_swedish-0.1-beta2.tar.gz
       c28485169c7127b5f17584e6fe175280  roundcube_turkish-0.1-beta2.tar.gz
       25289980efaf7c655028e4ce889764cd  roundcube_vietnamese-0.1-beta2.tar.gz
       roundcube source tarball is a custom tarball
 [x] Package is not known to require ExcludeArch, OR:
     Arches excluded:
     Why:
 [x] All build dependencies are listed in BuildRequires, except for any that are
listed in the exceptions section of Packaging Guidelines.
 [-] The spec file handles locales properly.
 [-] ldconfig called in %post and %postun if required.
 [x] Package must own all directories that it creates.
 [x] Package requires other packages for directories it uses.
 [x] Package does not contain duplicates in %files.
 [x] Permissions on files are set properly.
 [x] Package has a %clean section, which contains rm -rf %{buildroot} (or
$RPM_BUILD_ROOT).
 [x] Package consistently uses macros.
 [x] Package contains code, or permissable content.
 [-] Large documentation files are in a -doc subpackage, if required.
 [x] Package uses nothing in %doc for runtime.
 [-] Header files in -devel subpackage, if present.
 [-] Static libraries in -devel subpackage, if present.
 [-] Package requires pkgconfig, if .pc files are present.
 [-] Development .so files in -devel subpackage, if present.
 [-] Fully versioned dependency in subpackages, if present.
 [x] Package does not contain any libtool archives (.la).
 [-] Package contains a properly installed %{name}.desktop file if it is a GUI
application.
 [x] Package does not own files or directories owned by other packages.

=== SUGGESTED ITEMS ===
 [x] Latest version is packaged.
 [x] Package does not include license text files separate from upstream.
 [-] Description and summary sections in the package spec file contains
translations for supported Non-English languages, if available.
 [x] Reviewer should test that the package builds in mock.
     Tested on: FC6 / i386
 [-] Package should compile and build into binary rpms on all supported
architectures.
     Tested on:
 [x] Package functions as described.
 [x] Scriptlets must be sane, if used.
 [-] The placement of pkgconfig(.pc) files are correct.
 [-] File based requires are sane.


=== Issues ===
1.  Please use wget -N or equivalent to download source files and preserve
timestamps.
2.  Missing the russian langpack.
3.  I see that there is also a log directory listed in main.inc.php so the same
sed to fix the logs/ dir should be applied there.
4.  I don't think your logrotate is right.  The conf file is to rotate a file
called "logfile", but at least on my system, the only logfile created is
"errors".  Please check.
5.  This line: %dir %config(noreplace) %{_sysconfdir}/logrotate.d/roundcubemail
should not have a %dir because it is a file.


=== Final Notes ===
1. Once the selinux policy is updated for bug #239436, you'll want to add a
Conflicts: selinux-policy-targeted < version_it_was_fixed_in.  You can do this
post import.


Get those minor issues listed fixed and I'll approve your package.

Please note I'll be traveling for the next ten days or so.  Expect my responses
to be very slow.
Comment 58 Jon Ciesla 2007-05-14 15:42:47 EDT
From selinux bug:

All mail ports are grouped under a single type name of pop_port_t.  You need to
turn on the policy boolean httpd_can_network_connect

setsebool -P httpd_can_network_connect=1

Should I do this in %post?  I don't see any other webapps in fedora doing this.
 I would have thought Squirrelmail might, but it doesn't.
Comment 59 Jon Ciesla 2007-05-21 14:25:50 EDT
Ping?
Comment 60 Bernard Johnson 2007-05-21 15:43:42 EDT
Sorry, I just got back in town.

I posted an additional comment regarding the selinux issues on bug #239436
regarding selinux issues, but these are IMHO not enough to warrant holding up
the package approval.  Please follow that bug an implement any suggestions post
import.

47f2fc3fc5e0b3325ca3c3a360011a03  roundcube_russian-0.1-beta2.tar.gz

================
*** APPROVED ***
================
Comment 61 Jon Ciesla 2007-05-21 15:47:03 EDT
No problem, thanks for the review! I'll keep an eye on the selinux bug.

New Package CVS Request
=======================
Package Name: roundcubemail
Short Description: A browser-based multilingual IMAP client
Owners: limb@jcomserv.net
Branches: FC-5 FC-6
InitialCC: 
Comment 62 Jon Ciesla 2007-05-22 09:10:54 EDT
Oops: 
New Package CVS Request
=======================
Package Name: roundcubemail
Short Description: A browser-based multilingual IMAP client
Owners: limb@jcomserv.net
Branches: FC-5 FC-6 F-7
InitialCC: 
Comment 63 Jason Tibbitts 2007-05-26 16:54:38 EDT
This ticket has some odd flags; it shouldn't block FE-NEW, and it should be at
least in the ASSIGNED state until it's actually impolrted and built.

I'll fix them up.
Comment 64 Jon Ciesla 2007-05-26 17:16:42 EDT
Thanks.  Might that be why it's still waiting for CVSAdmin?  I've got several
other CVSAdmin requests waiting since Monday or Tuesday, though, and others
submitted since then that were completed very quickly, so I really have no idea
what's going on. :)

I think it was blocking FE-NEW since when I submitted it, we weren't using flags
yet. :)
Comment 65 Jens Petersen 2007-05-26 22:36:46 EDT
cvs admin done
Comment 66 Jon Ciesla 2007-05-29 07:20:31 EDT
Thanks all, imported and built.
Comment 67 Warren Togami 2007-07-06 13:39:16 EDT
Jon, any plans on building this for EPEL-5 too?
Comment 68 Jon Ciesla 2007-07-06 13:48:28 EDT
Yes.  There's a new upstrem with GPL-only content, that works great, and was
just pushed to F-7-updates.  I've built successfully for FC-6, and I've been
using it myself, so I think it's ready.

Package Change Request
======================
Package Name: roundcubemail
New Branches: EL-5
Comment 69 Warren Togami 2007-07-06 13:52:56 EDT
It appears that php-pear-Mail-Mime owned by fedora@theholbrooks.org also needed
to be added to EPEL-5 in order to make this work.  You will need to check with
that owner to see if they are willing to maintain php-pear-Mail-Mime in EPEL, or
if they are OK with you maintaining it there.
Comment 70 Jon Ciesla 2007-07-06 13:57:06 EDT
Not finding a review bug.  Brandon, what do you think?
Comment 71 Bernard Johnson 2007-07-06 14:34:32 EDT
Jon, I'd really like to see this in EL-4 as well if there are no hangups on
dependencies.
Comment 72 Jon Ciesla 2007-07-06 14:41:54 EDT
No objection here, I'll check and chase down deps.

Package Change Request
======================
Package Name: roundcubemail
New Branches: EL-4 EL-5
Comment 73 Brandon Holbrook 2007-07-06 14:49:16 EDT
I've been meaning to put Mail_Mime in EL5 anyway (I've already got a branch),
this is just the kick in the pants I needed to actually *do* it :)  I'll also
request an EL4 branch as well.
Comment 74 Warren Togami 2007-07-06 14:52:26 EDT
Branched roundcubemail on EL-4 EL-5
Branched php-pear-Mail-Mime on EL-4
Comment 75 Jon Ciesla 2007-07-06 14:55:57 EDT
Great, I'll build when I see Mail_Mime get built.
Comment 76 Jon Ciesla 2007-07-11 08:25:19 EDT
Built for EPEL5.  Brandon, any ETA on building Mail-Mime for 4?
Comment 77 Brandon Holbrook 2007-07-11 23:49:36 EDT
After branching Mail_Mime for EL4, I found out the hard way that EL4 currently
doesn't have the necessary pear infrastructure to build pear packages in epel
(Mail-Mime is the only pear package in CVS with an EL4 branch, so I'm the first
pear packager who's attempted this).  I've started some discussion on
fedora-php-devel-list at
https://www.redhat.com/archives/fedora-php-devel-list/2007-July/msg00000.html 
I'll post on here when something changes, but for now no pear packages in EL4 :(

Note You need to log in before you can comment on or make changes to this bug.