Spec URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/8/SPECS/php-ZendFramework.spec SRPM URL: http://prelive.iconmobile.com/dev31/fedora-icm-repo/Fedora/8/SRPMS/php-ZendFramework-1.0.3-1.fc8.src.rpm Description: Extending the art & spirit of PHP, Zend Framework is based on simplicity, object-oriented best practices, corporate friendly licensing, and a rigorously tested agile codebase. Zend Framework is focused on building more secure, reliable, and modern Web 2.0 applications & web services, and consuming widely available APIs from leading vendors like Google, Amazon, Yahoo!, Flickr, as well as API providers and catalogers like StrikeIron and ProgrammableWeb.
I'm getting a 502 proxy error trying to access the above links.
Sorry - the host will be available again on January 2.
I had a chance to briefly look at the spec file before it went down, and I think you should consider splitting the package in several subpackages, possibly at the "component" granularity as described in: http://framework.zend.com/manual/components it will be more work but otherwise you loose one of the big win of the Framework, that is, components are loosely coupled so it's possible to "pick" only the ones required for a given work.
Gianluca, I guess you're right. However I'll need some time to get this done as many spec files and subsequent package review requests are needed thus I'm removing this request for now.
Well, if you want to defer this it is ok. However, please note you just need one spec and one review. I was only suggesting that the single spec file would build a number of binary RPMS instead of a single one. This is done in several other packages and (more or less) detailed in http://docs.fedoraproject.org/drafts/rpm-guide-en/ch10s04.html
Reopening. Updated SPEC URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.0-1.fc8.rc3.src.rpm -- Since 1.5.0 is about to reach stable, I'm using the release candidates series for now. All components are split up into subpackages with interdependencies resolved via manual search and unit tests applied. All components have virtual requires and provides in the php-Zend(x) namespace. All significant rpmlint warnings and errors refer to files that are needed by the unit tests (subpackage -tests) and must not be modified in the distribution, otherwise complex patches to the tests have to be created and maintained. One issue remaining is that some unit tests explicitly try to create a cache directory (grep for cache_dir) locally below their _files directories, thus failing. Simply symlinking each _files directory below /var/tmp/php-Zendframework is not a clean solution since most of those already contain static test data so maybe /var/lib would be a better candidate. Any suggestions here are welcome.
Seems like I missed the final release just by a few minutes. Updated SPEC URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.0-1.fc8.src.rpm
As mentioned on this bug: https://bugzilla.redhat.com/show_bug.cgi?id=439015 maybe y'all can collaborate on one packaging of this?
*** Bug 439015 has been marked as a duplicate of this bug. ***
Alexander, did you get in touch with Jess Portnoy from Zend to see if you can work together on the package? I guess he could have some insights to fix the test issue. Alternatively, you could post on fedora-devel or fedora-packaging to ask for help on the issue; chances are that's not a blocking one.
Hi Alexander, Would be happy to collaborate with you. Please contact me at: jess at zend.com and we can discuss this further. Thanks,
About the problem with the getTmpDir() function in the unit tests, I think a good solution would be to allow overriding of the default TMPDIR [currently evaluated from: dirname(__FILE__)/zend_cache_tmp_dir], maybe as an ENV var or better yet, a directive in Zend/tests/Zend/Config/_files/config.ini. This way, it can be set to a convenient location, sort of the same idea as the TMPDIR ENV variable. Does that sound reasonable to you? I will discuss it with the Zend Framework developers and keep you posted.
oh, and in the meanwhile 1.5.2 is out
Hi Jess, thank you for helping me here. For the review request the latest stable version has to be packaged always so I need to update for 1.5.2 first, as Gianluca mentioned. The config.ini solution sounds most reasonable to me as this requires only a single file to be provided or patched once in Fedora's package. On the other hand, using ENV only would require a user to properly set his environment first, i.e. it doesn't work out of the box and requires providing a special README.fedora file. Will the config.ini be part of 1.5.3? The other issue are the subpackages: Do you know any feasible way to accomplish interdependency determination between the components of the framework, preferably programmatic? Wil is concerned here, although I'm pretty optimistic my method of unit testing each component individually and isolated suffices as long as code coverage is near complete - I think this process could be automated as well utilizing mock, our package building chroot tool. We (the Fedora community) emphasize high package quality implying high granularity and removing redundancy where reasonable/possible. If you are certain that splitting up Zend Framework brings more problems than benefits, I'll remove the split. From my personal experience with the framework, many components can be used either individually or pulling in only few dependencies. Especially I don't see why everyone must have all Zend_Service:s installed as many rely on registration with the service providers and/or are very specific. @Gianluca Would you volunteer for the review? Zend Framework release cycles are pretty tight and the faster we get this into Fedora, the less work will finally be wasted in case the subpackages stay (doesn't mean to review less thoroughly than usual though).
Hi Alexander, In general, I am all for segmentation but I think here it's a bit over segmented. For instance, I think there's much sense in placing the unit tests and demos in separate RPMs. Maybe it would make more sense to group modules into a few meta packages? This way, you could have a package of "common" modules, another for demos, a third for unit tests and poteniotally a few other extra packages containing less popular modules. This way, the user won't have to go through a huge list of packages related to the framework but, on the other hand, won't have many redundant packages he will never use. Does that sound reasonable?
My $0.02: I also think it's over-segmented, currently counting 59 packages. The only reason I'd want ZF segmented is to control which binary dependencies yum installs. I don't mind the bloat of PHP source files but I might not want certain extensions installed. How about using the packages' extension dependencies as a guide to grouping them? Extension dependencies: http://framework.zend.com/manual/en/requirements.extensions.html All the Zend_Service packages can definitely go in one package. That alone takes care of eleven subpackages.
Hi Jess, hi Brad, taking both of your inputs into consideration I propose the following package setup: - php-ZendFramework (base package) Contains all commonly used modules including the MVC components and all non-base components not requiring additional binary modules (PHP extensions) Pulls in php-ctype, php-xml - php-ZendFramework-Services Contains Zend_Service* excluding those listed below, base package and per-service provider subpackages Pulls in php-soap - php-ZendFramework-Cache-Backend-Apc Pulls in php-pecl-apc - php-ZendFramework-Locale-Math Pulls in php-bcmath - php-ZendFramework-Search-Lucene Pulls in nothing as php-pecl-bitset doesn't seem to be available for Fedora (yet) but extra package anyway as it is not commonly used (I guess) - php-ZendFramework-Http-Client-Adapter-Curl Pulls in php-curl - php-ZendFramework-Pdf Pulls in php-gd - php-ZendFramework-Db-Adapter-Db2 Same situation as with Zend_Search_Lucene, ibm_db2 not available as of now (proprietary?) - php-ZendFramework-Db-Adapter-Firebird Same as Zend_Search_Lucene, no i(nter)base - php-ZendFramework-Feed Pulls in php-mbstring - php-ZendFramework-Cache-Backend-Memcached Pulls in php-pecl-memcache - php-ZendFramework-Db-Adapter-Mysqli Pulls in php-mysql (also contains mysqli) - php-ZendFramework-Db-Adapter-Oracle Its required extension is proprietary but available in the free beer manner, we can either drop it or require the user to take care of the dependency manually - php-ZendFramework-Db-Adapter* Pull in php-pdo - php-ZendFramework-Cache-Backend-Sqlite Fedora's PHP was complied with --without-sqlite and I can only find the PDO driver, drop the component or file a bug against php..? - php-ZendFramework-tests - php-ZendFramework-demos (php-ZendFramework-manual-en and -api-doc are submitted as separate packages / review requests already) One problem with Zend_Http_Client: I don't know about mime_magic (cannot find it) and it's declared deprecated, can it use php-pecl-Fileinfo automatically instead? The following required extensions are included with Fedora's PHP by default already: dom, hash, iconv, json, pcre, posix, Reflection, session, SimpleXML, SPL, standard, zlib Any suggestions? The setup still looks pretty cluttered, maybe you've got another idea for the grouping details. Please take note that I will be on vacation and thus unavailable for one week starting tomorrow, details are at http://fedoraproject.org/wiki/Vacation
Hi Alexander, This package segmentation seems better. I think all php-ZendFramework-Db-Adapters can be included in one package, though it is true one would usually need only one or maximum two of these. Maybe it's better to have all common DBs in one package which requires php-pdo and the rest in another package. This would mean you will install the Oracle stuff even if you only want to use DB2 which is not so nice but on the other hand, there's something logical about deviding the whole DB support into common and misc DBs. I think most PHP developers use PDO to access MySQL, PGSQL, SQLite, etc and a substantial lesser amount of developers use DB2 and OCI8 directly so the separation makes sense. MySQLi is somewhat hard to decide upon because it does not belong with the PDO and is pretty commonly used... I admit I am not sure as to whether it should be in it's own package or included somewhere else. About mime_magic, it is true that php.net declares it as deprecated by Fileinfo from PECL but their APIs are not entirely compatible and I think many people still use mime_magic. It's source is included in the PHP 5.2.6 [latest stable] source tree under ext/mime_magic and it would be very easy to make an RPM out of it. I will send you a spec file shortly.
About mime_magic, after a second look: it seems that it's quite easy to keep using existing code originaly coded for mime_magic without changes as all you need to do is add one compatibility wrapper function. As stated in ext/mime_magic/DEPRECATED. Since it is so, I will discuss this matter with the ZF developers. I think the best thing would be to include this wrapper function in the event we have the Fileinfo extension loaded and not mime_magic and so it will be able to use both. Does this sound logical to you?
(In reply to comment #14) > @Gianluca > Would you volunteer for the review? Zend Framework release cycles are pretty > tight and the faster we get this into Fedora, the less work will finally be > wasted in case the subpackages stay (doesn't mean to review less thoroughly than > usual though). Well, given my interest in using the framework, I think I could go for it. Just ping me when the next iteration of the package is available
Thank you, Gianluca. Will do. I am waiting for a new version which will include my patch to getTmpDir() and my suggested fix for the mime_magic issue. As soon as it's done we can go forward.
Hi Jess, this is my status: Current packages (base) demos tests Cache-Backend-Memcached Cache-Backend-Sqlite Db-Adapter-Mysqli Db-Adapter-Db2 Db-Adapter-Firebird Db-Adapter-Oracle Feed Gdata (why doesn't this exist as a service component?) Pdf Search-Lucene Services There are some issues here: Cache-Backend-Sqlite requires php-sqlite but this is not available in Fedora's PHP build, it was disabled Mon Nov 8 2004 by Joe Orton, most probably in favor of pdo-sqlite. Can the back end handle pdo-sqlite instead of sqlite? If not we probably have to exclude it. Db-Adapter-Db2, Db-Adapter-Firebird and Db-Adapter-Oracle require extensions that must be compiled in while having the respective database software installed, in case of DB2 and Oracle this is impossible for Fedora since they are proprietary software, I don't know about InterBase/Firebird however it's also missing. We can of course offer Zend's adapters but the user is required to compile PHP and enable the affected dependencies himself. Feed has been separated because it requires mbstring; same goes for Pdf because of GD, Search-Lucene because of bitset; Locale-Math has _not_ been separated as planned since Date uses bcmath as well and cannot be separated as a major dependency for other base components. About mime_magic: I've checked our PHP build, the extension was disabled Wed Mar 21 2007, indeed in favor of Fileinfo. I'd really appreciate Fileinfo support from your side! A wrapper functions sounds completely reasonable. The total list of extensions required for the base framework package as of now: bcmath, ctype, curl, dom, hash, iconv, json, pcre, posix, reflection, session, simplexml, spl, zlib. Only two of them, bcmath and dom, require additional extensions to be pulled in which is pretty acceptable. About the getTmpDir() issue: Please keep in mind you're targeting a multi-user platform, setting a fixed value in a configuration file can still create clashes, especially if no cleanup is performed afterwards. Given both choices only, I'd rather go with the environment variable; if you want a much more flexible solution involving the configuration file, I suggest append a hash, timestamp or the uid to the base path given. Actually this is what I do in my tests :) Alternatively, you could go with world writable modes for all files and directories created during the tests. @Gianluca Thanks in advance for volunteering!
Hi Alexander, About SQLite and the proprietary DB extensions, I think it's perfectly OK for the user to take care of the missing deps should he so desire. The unit tests themselves always check whether the extensions required are loaded and throw an exception if they're not so the user can easily tell what's required and take care of it. I see no problem with it as there are over 100 PHP extensions, naturally you can't provide them all. About getTmpDir(), I suggested: return getenv('TMPDIR').DIRECTORY_SEPARATOR . 'zend_cache_tmp_dir_'.date("mdyHis"); This way, the directory will be created with a timestamp which will avoid conflicts just as you suggested. I have also submitted a wrapping function to the ZF developers and am now waiting for them to apply both the getTmpDir() patch and this wrapper.
Hi Jess, I will ask on fedora-devel how to handle absent or unavailable package requirements when providing the requiring package makes sense. Could be that it is not possible to provide the affected extensions at all because I (as the would-be package maintainer) cannot provide support (verifying/fixing bugs etc.) for them without non-Fedoran packages. Your getTmpDir() solution looks perfectly suitable to solve all issues identified so far, thank you!
Hi Alexander, Are there any additional extensions are you missing in the FC repo besides mime_magic and third party, non open DB vendors? About the getTmpDir() function, it has been patched but unfortunately not quite as I suggested, it's pretty close to my original suggestion but it only supports exporting TMPDIR for now, my config.ini idea, where a directive could be set to use an alternative tmpdir is not yet implemented. I think this will do for now but I hope it can be implemented in the future. For now, we could just export TMPDIR. The change is available from ZF's SVN trunk: http://framework.zend.com/svn/framework/standard/trunk/ About mime_magic vs. fileinfo, my wrapper function was not yet applied but I will become a ZF committer soon and just apply it myself. Please let me know how you did with getTmpDir().
Created attachment 309009 [details] Test run on ZendFramework 1.5.2 with PHPunit PHP 5.2.5 (cli) (built: Apr 24 2008 10:37:47) PHPUnit 3.2.19 shell$ phpunit -d memory_limit=512M --verbose AllTests.php \ > ~/ZendFramework-1.5.2-testall-$(date +%F)-tap.log 2>&1 All packages and dependencies identified so far were installed.
Hi Jess, as you can see in above's comment I've attached the log from a complete 1.5.2 test run, maybe this is helpful to you. (In reply to comment #25) > Are there any additional extensions are you missing in the FC repo besides > mime_magic and third party, non open DB vendors? Surprisingly, yes: php-bitset (php-pecl-bitset) is not available for Fedora. Pecl says someone from Zend maintains it but there has never been an update after initial release in 2005. What are the drawbacks of using Search_Lucene without bitset? Is it still considered maintained? If not, becoming the packager of php-pecl-bitset would also mean becoming the maintainer in Fedora World and I don't have any spare capacities to cope with this. Otherwise, i.e. if Zend is still maintaining it, I'd package it. > About the getTmpDir() function, it has been patched but unfortunately not quite > as I suggested, it's pretty close to my original suggestion but it only supports > exporting TMPDIR for now, my config.ini idea, where a directive could be set to > use an alternative tmpdir is not yet implemented. I think this will do for now > but I hope it can be implemented in the future. For now, we could just export > TMPDIR. This improves our situation of testing most components properly right now but I wouldn't consider it the final solution. Our goal should be to have a blank PHPunit run on AllTests.php walk through after a fresh installation without any failures and/or errors. > The change is available from ZF's SVN trunk: > http://framework.zend.com/svn/framework/standard/trunk/ I've just checked out the trunk but will make an inspection and test run tomorrow. > About mime_magic vs. fileinfo, my wrapper function was not yet applied but I > will become a ZF committer soon and just apply it myself. Sounds good. > Please let me know how you did with getTmpDir(). Will do next time.
Hi Alexander, About bitset, the person listed as maintainer no longer works at Zend. I don't believe it will be maintained further. However, the use of bitset is not mandatory. Comment in library/Zend/Search/Lucene/Index/SegmentInfo.php on line 167 reads: bitset if bitset extension is loaded or array otherwise. Therefore it is possible to use w/o having bitset loaded. This is also true to mime_magic, BTW. I will review your log and see what I can do about it.
Hello again, I reviewed the log and the good news are most of the problems are mostly around the same lines of the getTmpDir(), that is, the tests are trying to create and manipulate files within the ZF tree which a normal user cannot do if the tree is located under /usr/share. The problem here is more vast than just getTmpDir() it appears as though the entire concept was not considered when the tests were designed. I will discuss it with the ZF developers and see how fast we can address this. Thanks,
Hi Jess, any news? I just did a test run on revision 9862 but getTmpDir() doesn't seem to be in usage yet with the exception of a few optional tests. Regards Alex
Hi Alex, Regarding the permissions issue, which is cross wide and not only specific to the cache component as was quite obvious from the report you attached, I am still waiting for the ZF maintainers to come up with a general fix. I have explain the issue to them and suggested a few options to fix this. The mime_magin vs. fileinfo issue is suppose to be resolved. Please see: http://framework.zend.com/issues/browse/ZF-3320 For more inforamtion. I will, of course, notify you as you soon as they release a version that does not suffer from these issues. For now, can you please verify the Zend/Http/Client.php fix? Thanks,
Sorry guys, I'm a bit lost by now... Are the remaining issues really a blocker or we can go ahead with the review in the meanwhile?
Well, I don't want to speak on Alex's behalf but this is how I see our status: 0. The mime_magic vs. fileinfo issue is resolved [assuming it works well] 1. About the unit tests, some of them work properly, some do not due to permissions issues. I don't think this is a show stopper, it should most certainly be fixed but I think we can release the first RPM version as is and work on it as we go along. The problem here is not periodic and I am trying to motivate the ZF maintainers to address it. Alex, are there any other issues I can help promote? Thanks,
Hi Jess, hi Gianluca, (In reply to comment #31) > For now, can you please verify the Zend/Http/Client.php fix? I've just verified this in HEAD: With php-Fileinfo installed, the correct mime type is returned; without, the default (application/octet-stream). I consider this fixed and not having this feature in 1.5.2 yet is definitely not a blocker issue. There's one minor non-blocker issue you could actually try to promote: Since Zend has decided to not only provide a zipped version of the framework but also a tarball which is most likely meant to target platforms like Fedora (UN*X-likes), please fix file permissions before every release. In 1.5.2, all Gdata-related files have their executable bit set. Right now, this needs to be handled by my installation script. Gianluca: I consider all previous blockers fixed and will upload a 1.5.2 package right away.
Updated SPEC URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.0-1.fc8.rc3.src.rpm Changes: - update to 1.5.2 - new package split - removed Cache-Backend-Sqlite, Db-Adapter-Db2, Db-Adapter-Firebird, Db-Adapter-Oracle - removed optional php-bitset requirement from Search-Lucene, not available - removed virtual requires and provides, not necessary anymore
Oops, old package URL. Correct one: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.5.2-1.fc9.src.rpm
Hi Alex and Gianluca, Just wanted to let you know the ZF team will release the 1.6 version in approx. 2 weeks. It will include the patches for both the mime_magic/fileinfo and the fix for the cache unit test. I have also written to them about the package permissions issue [the executable bit being turned on where it is not needed] and I asked for them to fix it.
Hey Alex and Gianluca, ZF 1.6RC1 is out. This includes the fix for the mime_magic-fileinfo issue. The unit tests issue is not yet addressed unfortunately but the ZF developers are aware of it. Thanks,
OT: too bad http://www.zendframework.com/issues/browse/ZF-2624 is still open ;)
Updated SPEC URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework.spec Updated SRPM URL: http://akahl.fedorapeople.org/php-ZendFramework/php-ZendFramework-1.6.0-0.1.rc1.fc9.src.rpm Change: - update to 1.6.0RC1 - added php-Fileinfo dependency The Fileinfo/mime_magic issue is fixed now. SQLite support via PDO in Zend_Cache_Backend_Sqlite is still missing (non-blocker). Also, we can definitely go without the working unit tests for now but can we continue collaboration on issues after the Fedora/RHEL release? Anyway, I'll open a Zend Tracker account. Gianluca: Ready for a review or do you want to wait for 1.6 final? Talking about ZF issues still open, I'd love to see ZF-2151 fixed, maybe utilizing libyaml/php-yaml.
Hi Alex and Gianluca, About the unit tests, yes, of course you can count on our collaboration. I find this issue to be very important and I was assured it will get proper consideration in the future. About 2151: There is a PECL extension that can do the trick [http://pecl.php.net/package-search.php?pkg_name=syck&bool=AND&submit=Search] and also a nice article about how to utilize it [http://devzone.zend.com/article/2585-using-yaml-with-php-and-pecl]. I will discuss this with the ZF guys and see how I can further promote it. Things are a bit busy for me so I am not sure I commit to taking ownership and writing this ZF component but we'll see :) I urge you to open an account so we can collaborate in an even more affective manner :) P.S Great work and thanks
Hi Jess, thank you for your pledge. About 2151: I know all YAML alternatives for PHP pretty well and all of them have their pitfalls, including syck; ATM syck-php segfaults for Fedora, at least on x86_64 and also i386 IIRC. spyc and Horde_Yaml are too slow because processing is done via pure PHP code and while seeming mature, syck seems to be unmaintained (0.55 released 2005 May 18) and still sticks around with YAML 1.0; libyaml on the other hand is considered alpha state despite being very stable (I'm using it for production!), is under active development, offers YAML 1.1 support and has php-yaml as third-party binding which is at least capable of deserialization already; I've added a patch to get parser errors into PHP and sent it to the original author but no reply so far. If necessary I'll add serialization support myself. Please consider the alternatives :) Best regards
Hi Alex, I will checkout the YAML issue. Maybe it's worth improving syck, making it support YAML 1.1 and fix the seg fault[s]. I am not sure it is but it's worth looking into. I will review the code first time I get. Also, I run: find /tmp/ZendFramework-1.6RC1/ -type f -perm /u+x,g+x And discovered they still have the exec bit set for some files without cause, I will open an issue about it and remind them once more. Again, thanks for all the hard work. I think this process is very productive in helping ZF become better.
Hi again, I looked at PECL and saw the last update on the syck extension was issued on 2007-11-22 [version 0.9.2]. It's declared to be beta but that doesn't necessarily mean anything. I compiled it and it loaded properly on my FC 8. Is there a certain scenario that causes the seg fault? I am now interested :)
Ok, I think it's time to get this into Fedora, let's see if I can carve some time for the review
Hi Jess, hi Gianluca, I'd really love to see syck back maintained and supporting YAML 1.1 or even 1.2 (http://code.google.com/p/yaml-cpp/ does it); as far as I can judge from the alternatives' code basis, libyaml seems to be most suitable for extension as it clearly follows formal grammar / parser theory patterns (BNF tokens etc.) but maybe I'm just wrong here and underestimating syck. Fedora's php-syck still seems to come from the original syck tarball instead of php-pecl-syck, thus being utterly obsoleted. I'll file a bug report here right away. Actually the file permissions issue is a classic amongst developers working in heterogeneous environments as soon as the Redmond OS is involved. Btw. you can also use -perm /111 to get u+x,g+x,o+x. Hey, collaboration is what keeps the community alive and Free Software is what makes us able to help our neighbor :) Gianluca: Great! I know we're all busy and really appreciate your commitment here.
==== REVIEW CHECKLIST ==== - package named according to package naming guidelines - spec filename matches %{name} - package meet packaging guidelines - package licensed with open source compatible license (BSD) - license matches actual license - license file included in %doc - spec written in American english - spec legible - source match upstream 196aef8904be20c199e536480f92c5c9 ./ZendFramework-1.6.0RC1.tar.gz - successfully builds in mock for rawhide x86_64 - no locales - no shared libraries - package is not relocatable - package owns all directories it creates - file permissions set properly - contains proper %clean - macro usage is consistent - package contains code - no large documentation - not a GUI app needing a .desktop file - rpmlint output not clean php-ZendFramework-Cache-Backend-Apc.noarch: W: no-documentation php-ZendFramework-Cache-Backend-Memcached.noarch: W: no-documentation php-ZendFramework-Cache-Backend-Memcached.noarch: W: filename-too-long-for-joliet php-ZendFramework-Cache-Backend-Memcached-1.6.0-0.1.rc1.fc9.noarch.rpm php-ZendFramework-demos.noarch: W: no-documentation php-ZendFramework-demos.noarch: E: htaccess-file /usr/share/php/Zend/demos/OpenId/mvc_auth/html/.htaccess php-ZendFramework-Feed.noarch: W: no-documentation php-ZendFramework-Gdata.noarch: W: no-documentation php-ZendFramework-Pdf.noarch: W: no-documentation php-ZendFramework-Search-Lucene.noarch: W: no-documentation php-ZendFramework-Services.noarch: W: no-documentation php-ZendFramework-tests.noarch: W: no-documentation php-ZendFramework-tests.noarch: E: zero-length /usr/share/php/Zend/tests/Zend/Filter/_files/file.1 php-ZendFramework-tests.noarch: E: non-executable-script /usr/share/php/Zend/tests/Zend/Text/Figlet/GenerateDummies.sh 0644 php-ZendFramework-tests.noarch: E: zero-length /usr/share/php/Zend/tests/Zend/Text/Figlet/InvalidFont.flf php-ZendFramework-tests.noarch: W: hidden-file-or-dir /usr/share/php/Zend/tests/Zend/Auth/Adapter/Digest/_files/.htdigest.1 php-ZendFramework-tests.noarch: E: zero-length /usr/share/php/Zend/tests/Zend/Soap/_files/cert_file php-ZendFramework-tests.noarch: E: zero-length /usr/share/php/Zend/tests/Zend/Http/Client/_files/testHeaders.php php-ZendFramework-tests.noarch: W: file-not-in-%lang /usr/share/php/Zend/tests/Zend/Translate/_files/test_fileerror.mo php-ZendFramework-tests.noarch: W: file-not-in-%lang /usr/share/php/Zend/tests/Zend/Translate/_files/testmsg_en.mo php-ZendFramework-tests.noarch: W: file-not-in-%lang /usr/share/php/Zend/tests/Zend/Translate/_files/testmsg_ru(koi8-r).mo php-ZendFramework-tests.noarch: W: file-not-in-%lang /usr/share/php/Zend/tests/Zend/Translate/_files/translate_bigendian.mo 10 packages and 0 specfiles checked; 6 errors, 15 warnings. I think the "no-documentation" warnings could be ignored on subpackages. You may consider adding the license file to silence it filename-too-long-for-joliet is annoying if this is going to be burned on a CD/DVD. I am not sure if that's a blocker htaccess-file IIRC htaccess files are ignored by the default apache installation. please check if we can remove it without impacting the demo. I think all the -tests W and E can be safely ignored. Please just double check the .htdigest.1 and the zero lenght files are really the test targets. One last remark. If there is some post installation steps the user is supposed to do, please add a README.Fedora file with the appropriate note. So, I can't see any blocker here, the package is APPROVED.
Gianluca: I've fixed the "no-documentation" issue by adding the license to all subpackages. The joliet problem should go away with 1.6 stable; for the rest I've verified the files are necessary and correct for the unit tests. Right now there's nothing special required to have Zend Framework run on Fedora, if it ever will, I'll add a README. Thanks again! Jess: Which way do you recommend for staying in contact, do you want to be set CC for Zend Framework related bugs in RedHat Bugzilla or should I open a Zend Jira account and forward bug reports where applicable? Sorry guys for taking so long but whenever I tried posting Bugzilla's update seemed to get into my way..
New Package CVS Request ======================= Package Name: php-ZendFramework Short Description: Leading open-source PHP framework Owners: akahl Branches: F-9 InitialCC: Cvsextras Commits: yes
Hi Alex, I'd love to be set CC. It can't hurt :)
cvs done.
All builds successful. If anyone wants this into EPEL/RHEL, I'll consider it - but for now, the implicated long-term responsibility is quite daunting. Thank you Jess and Gianluca for your help!
Hi Alex, I was thinking, it might be a good idea for the RPM %post to run the following: sed 's@\(^include_path\s*=\s*".*\)"@\1:%{_datadir}/php"@' -i /etc/php.ini So that the prefix for ZF is found within PHP's include path. I don't think it's a must and can also think of reasons why not to interfere with the php.ini but still, thought I'd suggest it none the less.
Hi Jess, nice idea but actually useless for Fedora: include_path is not set in php.ini by default, instead it's hard-coded by a patch to .:/usr/share/pear:/usr/share/php (in C: INCLUDE_PATH=.:$EXPANDED_PEAR_INSTALLDIR:${EXPANDED_DATADIR}/php) Our policy is to install PEAR packages into /usr/share/pear and all other PHP packages into /usr/share/php; if anyone wishes to override the path, he or she has to make sure the default still applies.
OK, I would love to hear to reason for this patch someday but it seems in that case it is indeed useless :)
Package Change Request ====================== Package Name: php-ZendFramework New Branches: el5 el6 Owners: heffer
Ah, sorry. Drop the el5. PHP in EL5 is too old for ZendFramework.
Git done (by process-git-requests). EL-5 dropped.
For the records, RHEL 5.6 got a php53 package which I guess is possible to use as a dep for the EL-5 branch
Package Change Request ====================== Package Name: php-ZendFramework New Branches: el7 Owners: heffer
Git done (by process-git-requests).