Spec URL: http://fedorapeople.org/~bretm/reviews/wordpress-mu/wordpress-mu.spec SRPM URL: http://fedorapeople.org/~bretm/reviews/wordpress-mu/wordpress-mu-2.6-6.fc8.src.rpm Description: WordPress-MU is a variant of WordPress that supports more than one blog per instance. It is the basis for the wordpress.com hosted service, and scales to large numbers of users and blogs. Spec file has been based upon the conventions laid-out by the existing wordpress Fedora package; please note any incorrect divergence. Source checksum should match current "latest" tarball available from upstream; upstream does not currently offer a conveniently-named version-specific tarball (http://trac.mu.wordpress.org/ticket/701). rpmlint output: ----------------- [bretm@koom rpmbuild]$ rpmlint SPECS/wordpress-mu.spec SPECS/wordpress-mu.spec: W: no-%build-section 0 packages and 1 specfiles checked; 0 errors, 1 warnings. [bretm@koom rpmbuild]$ rpmlint SRPMS/wordpress-mu-2.6-6.fc8.src.rpm wordpress-mu.src: W: no-%build-section 1 packages and 0 specfiles checked; 0 errors, 1 warnings. The spec file doesn't have a %build section; this seems acceptable, as the application is a php web application, and doesn't have any sort of compilation step.
I think you just need to have an empty %build section to get rid of that message.
I can't assign to myself right now
Unfortunately, %build is not just a section marker but also a macro. Some things that rpmbuild does are tied to the expansion of that macro. I don't know that leaving it out will break your particular package but including it will not break your package. So you should just include an empty %build section to avoid unexpected and mysterious breakage.
RPM Lint: no %build warning Package name: ok Spec file: ok License: GPLv2 Actual License: GPLv2 (source tarball carries license.txt) %doc License: ok Spec file language: ok Spec file readable: ok Upstream source vs. used tarball: matches, noted that upstream doesn't version their releases very well ;-) Compile and Build: - F-7: builds - F-8: builds - rawhide: builds - EL-5: builds Applicable Package Guidelines: Locales: not applicable Shared libs: not applicable Relocatable: no Directory and file ownership: ok No duplicate files in %files: ok File Permissions: ok Macro usage: ok Code vs. Content: ok (Large) Documentation: ok %doc affecting runtime: ok Header files in -devel package: not applicable Static Libraries in -static package: not applicable pkgconfig Requires: not applicable Library files: not applicable Devel requires base package: not applicable .la libtool archives: not applicable Duplicate ownership of files/directories: no Remove BuildRoot: yes UTF-8 filenames: no If the %build section (which can be empty) is added back to the spec, I can approve the package
I'm working with Stefan on this, but he cannot set the flags or assign this bug (yet, dunno what the problem is)
Thanks for the prompt response folks :) [bretm@koom ~]$ grep -r -A4 '%build' /usr/lib/rpm/redhat/macros %build %%build\ LANG=C\ export LANG\ unset DISPLAY\ %{nil} Neither LANG nor DISPLAY are likely to affect creation of the wordpress-mu pkg, but happy to conform to the standard. I've added %build to the spec file, and updated them: http://fedorapeople.org/~bretm/reviews/wordpress-mu/wordpress-mu.spec http://fedorapeople.org/~bretm/reviews/wordpress-mu/wordpress-mu-2.6-6.fc8.src.rpm
You're welcome. BTW you linked the wrong src rpm in comment #6 :) I took the spec from #6 and overwrote the spec from the src rpm. rpmlinkt is nice and quiet now. Package approved I can't change the review flag though (permission denied...)
Weird. /me looks at his terminal... crap, rsync bailed on me. /me fixes... http://fedorapeople.org/~bretm/reviews/wordpress-mu/wordpress-mu.spec http://fedorapeople.org/~bretm/reviews/wordpress-mu/wordpress-mu-2.6-7.fc8.src.rpm
I suspect this is because S.A hartsuiker isn't in the fedorabugs group.
@mmcgrath could be, how do I get in that group? new srpm is good. approved (again :) )
Shouldn't be wp-config.php part of the package? Selinux is not permitting to create it via the web interface. And in scenario where selinux is disabled, wp-config.php is not removed with the RPM anyway. Jul 29 22:48:46 mmahut kernel: type=1400 audit(1217364526.850:3): avc: denied { create } for pid=10865 comm="httpd" name="blogs.dir" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=dir Jul 29 22:48:49 mmahut kernel: type=1400 audit(1217364529.793:4): avc: denied { create } for pid=10867 comm="httpd" name="wp-config.php" scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file Jul 29 22:48:49 mmahut kernel: type=1400 audit(1217364529.793:5): avc: denied { write } for pid=10867 comm="httpd" name="wp-config.php" dev=dm-0 ino=2376771 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file Jul 29 22:48:49 mmahut kernel: type=1400 audit(1217364529.794:6): avc: denied { setattr } for pid=10867 comm="httpd" name="wp-config.php" dev=dm-0 ino=2376771 scontext=unconfined_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:usr_t:s0 tclass=file
1) We could ship a wp-config.php that is suitably commented and forces the user to edit the value, but having that file not exist achieves the same goal in a fashion more in-line w/ upstream and the currently shipped wordpress package, and wp-config-sample.php is shipped as the example to customize off of. You're right though, the rpm -e case needs to be addressed, I'll look into that. 2) Generally speaking, I'm open to ideas about how best to handle post rpm-bit-deployment configuration. For multi-system applications, we've typically just not worried too much about configs, trusting that a cfengine or puppet system would deploy what was necessary after the fact... I'm all ears for a better solution. 3) I am not at all a fan of the existing wordpress-mu installer, and plan long-term to work with upstream to have a better deployment & configuration story. This ties into #2. 4) any patches for the selinux use case cheerfully accepted :) That's just one area of the installer that will make selinux quite unhappy... if you enable file uploads, I'm pretty sure selinux will prevent that without custom policy, no?
Btw, now that the package has been approved, what's the next step? Importing into Fedora CVS?
In reply to comment #13: Yes, normally... however your reviewer is not yet in the packaging group, so he can't officially approve this package. :( I am however working with them on another submission, and once that is done, I can sponsor them and this review is valid. ;) If someone else would like to do a quick review/approval we can get this moving sooner.
I am now in the packing group and seeing no one has picked this up further, I am setting this to review-approved. Bretm, once this is in CVS, go here for further instructions: http://fedoraproject.org/wiki/PackageMaintainers/Join#Add_Package_to_CVS_and_Set_Owner
New Package CVS Request ======================= Package Name: wordpress-mu Short Description: multi-user variant of wordpress blogging package Owners: bretm Branches: F-8 F-9 InitialCC: jonrob
cvs done.
Package Change Request ====================== Package Name: wordpress-mu New Branches: EL-5 Owners: bretm Description: WordPress-MU is a variant of WordPress that supports more than one blog per instance. It is the basis for the wordpress.com hosted service, and scales to large numbers of users and blogs. I'd like to add an EPEL branch for RHEL 5 support; we've been using it for several months now on that platform.
Kevin, as this is the first EPEL branch I've worked with, can you point me in the right direction for next steps? I'm not seeing any new directories in cvs...
Nmind. Pebkac.