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.
---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.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=224245#c2 says it bundles code incompatible with GPL. is it a blocker?
Which code? I'll ask on that thread as well.
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)
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.
> 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.
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.
(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.
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
Response from upstream: 2007/1/31, Jon Ciesla <limb>: > > 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.
(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/
Ah. So all he has to do is pull the PEAR code and I'll get on fixing the many .spec issues. :)
%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
Upstream's response: -------------- 2007/1/31, Jon Ciesla <limb>: > 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
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?
> Would it be worth trying to make a package based on a modified > version of the current release... That should be ok.
(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.
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?
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? :)
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.
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?
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.
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?
(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.
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.
(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.
(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.
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.
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?
(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
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?
(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.
(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.
(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.
(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
Bug filed against s-p-t.
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
(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.
(In reply to comment #38) > %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/* %attr(0644,root,apache) %config(noreplace) %{_sysconfdir}/%{name}/*
(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".
(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)
(In reply to comment #41) > That's great, but what's xarg? xargs... sorry
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.
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
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)
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
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.
Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.6.spec SRPM URL:http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-0.1.beta2.2.src.rpm Fixed versioning.
The translations are 8k a piece and there are 23 of them. Is there any point to not including them in the base package?
Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.7.spec SRPM URL:http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-0.2.beta2.2.src.rpm Added langpacks.
(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
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
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
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>
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
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.
Spec URL: http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail.10.spec SRPM URL:http://zanoni.jcomserv.net/extras/roundcubemail/roundcubemail-0.1-0.5.beta2.2.src.rpm Fixed the above, leaving only the selinux bit.
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.
Ping?
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 *** ================
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 Branches: FC-5 FC-6 InitialCC:
Oops: New Package CVS Request ======================= Package Name: roundcubemail Short Description: A browser-based multilingual IMAP client Owners: limb Branches: FC-5 FC-6 F-7 InitialCC:
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.
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. :)
cvs admin done
Thanks all, imported and built.
Jon, any plans on building this for EPEL-5 too?
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
It appears that php-pear-Mail-Mime owned by fedora 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.
Not finding a review bug. Brandon, what do you think?
Jon, I'd really like to see this in EL-4 as well if there are no hangups on dependencies.
No objection here, I'll check and chase down deps. Package Change Request ====================== Package Name: roundcubemail New Branches: EL-4 EL-5
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.
Branched roundcubemail on EL-4 EL-5 Branched php-pear-Mail-Mime on EL-4
Great, I'll build when I see Mail_Mime get built.
Built for EPEL5. Brandon, any ETA on building Mail-Mime for 4?
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 :(