Proposal of a MediaWiki extension: Spec URL: http://olea.org/tmp/mediawiki-imagemap.spec SRPM URL: http://olea.org/paquetes-rpm/xhtml2fo-style-xsl-20050106-1.src.rpm SRPM URL: http://olea.org/paquetes-rpm/mediawiki-imagemap-rev39658-1.src.rpm RPM URL: http://olea.org/paquetes-rpm/mediawiki-imagemap-rev39658-1.noarch.rpm Description: This extension lets to use image maps inside Mediawiki.
What is the xhtml2fo-style-xsl srpm for?
Sorry!! I've cut and pasted badly!! Spec URL: http://olea.org/tmp/mediawiki-imagemap.spec SRPM URL: http://olea.org/paquetes-rpm/mediawiki-imagemap-rev39658-1.src.rpm RPM URL: http://olea.org/paquetes-rpm/mediawiki-imagemap-rev39658-1.noarch.rpm The other package got its own bug report (https://bugzilla.redhat.com/show_bug.cgi?id=428793). It's not related with MediaWiki at all.
I'll review it
Notes: * You should describe exact steps how to obtain source code and create tarball. E.g. something like # cvs -d:pserver:anonymous.berlios.de:/cvsroot/sippy export -D 2008-06-27 sippy # tar -cjvf sippy-20080627.tar.bz2 sippy Source0: sippy-20080627.tar.bz2 * Versioning scheme is ugly. If (then) project will release officialtraball, say ver. 1.0.0, then you will be forced to add %epoch to your spec, because 1.0.0 is earlier than rev[0-9].* . I suggest you to consider using the following versioning scheme Version: 0 Release: 0.1.svn39658%{?dist} Note leading zero. E.g. Release == 0.RPMREV.svnSVNREV%{?dist} With this naming scheme you won't have any troubles then upstream will release official tarball. Other things looks sane.
I've follow your recomendations. I remade the package using the supposed last stable version for MediaWiki 1.13. Updated info http://olea.org/paquetes-rpm/mediawiki-imagemap-MW1.13-0.1.r37906.olea.src.rpm http://olea.org/paquetes-rpm/mediawiki-imagemap-MW1.13-0.1.r37906.olea.noarch.rpm Spec URL: http://olea.org/tmp/mediawiki-imagemap.spec
> I remade the package using the supposed last stable version for MediaWiki 1.13. OK. BTW Axel Thimm right now rebuilding MediaWiki 1.13 for F-8 and F-9. REVIEW: MUST Items: - rpmlint warns aboun incoherent version in changelog. Easy to fix - just add notes about latest changes under actual version (MW1.13-0.1.r37906). + The package is named according to the Package Naming Guidelines . + The spec file name matches the base package %{name}, in the format %{name}.spec. + The package meets the Packaging Guidelines . + The package is licensed with a Fedora approved license and meets the Licensing Guidelines. + The License field in the package spec file matches the actual license. + The spec file is written in American English. + The spec file for the package is legible. + The sources used to build the package matches the upstream source: [petro@Sulaco SPECS]$ md5sum ../SOURCES/ImageMap-MW1.13-r37906.tar.gz* 39e7f7fceb125cf6a707d4c057b15f57 ../SOURCES/ImageMap-MW1.13-r37906.tar.gz 39e7f7fceb125cf6a707d4c057b15f57 ../SOURCES/ImageMap-MW1.13-r37906.tar.gz.orig [petro@Sulaco SPECS]$ + The package successfully compiles and builds into binary rpms on at least one supported architecture (ppc). + All build dependencies are listed in BuildRequires. + A package owns all directories that it creates. + A package does not contain any duplicate files in the %files listing. + Permissions on files are set properly. + The package has a %clean section, which contains rm -rf %{buildroot} + The package consistently uses macros, as described in the macros section of Packaging Guidelines . + The package contains code, or permissable content. + Everything, the package includes as %doc, does not affect the runtime of the application. + Package does not own files or directories already owned by other packages. + At the beginning of %install, the package runs rm -rf %{buildroot} + All filenames in rpm packages are valid UTF-8. SHOULD Items: - SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. So, finally * please add entry to %changelog to make rpmlint happy * consider shortening %description - no need to add notes, describing how to download latest version (we should provide such support) * find a minute to drop email to ustream about LICENSE inclusion and this package is APPROVED.
(In reply to comment #6) > MUST Items: > > - rpmlint warns aboun incoherent version in changelog. Easy to fix - just add > notes about latest changes under actual version (MW1.13-0.1.r37906). Strange: I'm rpmlinting my packages and get zero comments :-m I'm using this: [olea@lisergia SPECS]$ rpm -q rpmlint rpmlint-0.84-2.fc9.noarch [olea@lisergia SPECS]$ rpmlint -ivv mediawiki-imagemap.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. > SHOULD Items: > > - SHOULD: If the source package does not include license text(s) as a separate > file from upstream, the packager SHOULD query upstream to include it. aha. > So, finally > > * please add entry to %changelog to make rpmlint happy done. > * consider shortening %description - no need to add notes, describing how to > download latest version (we should provide such support) Well, I'm confused here since you suggested to explain the way to get the sources (see https://bugzilla.redhat.com/show_bug.cgi?id=459540#c4). You mean to write it in comments inside the spec file or to remove it since the sources are created through an upstream service? > * find a minute to drop email to ustream about LICENSE inclusion done Thanks :-)
(In reply to comment #7) > > * consider shortening %description - no need to add notes, describing how to > > download latest version (we should provide such support) > > Well, I'm confused here since you suggested to explain the way to get the > sources (see https://bugzilla.redhat.com/show_bug.cgi?id=459540#c4). > > You mean to write it in comments inside the spec file or to remove it since the > sources are created through an upstream service? I thought that you use custom made svn snapshot. In such cases instructions how to build such snapshot should be supplied in spec-file. See this one, as a reference: http://cvs.fedoraproject.org/viewvc/rpms/flashrom/devel/flashrom.spec?view=markup > Thanks :-) And one lastminute fix - please change versioning scheme again! I don't think that using MW1.13 as "Version" is a good idea. As its just a svn-snapshot and no official release was made so far, you should use 0, e.g. Version: 0 Release: 0.1.%{revision}%{?dist}
(In reply to comment #8) > I thought that you use custom made svn snapshot. It was at the first version, before discovering the WikiMedia tgz service :-) > And one lastminute fix - please change versioning scheme again! I don't think > that using MW1.13 as "Version" is a good idea. As its just a svn-snapshot and > no official release was made so far, you should use 0, e.g. > > Version: 0 > Release: 0.1.%{revision}%{?dist} done: http://olea.org/tmp/mediawiki-imagemap.spec
OK. All issues now resolved. Don't forget to raise fedora-cvs flag to "?" :)
New Package CVS Request ======================= Package Name: mediawiki-imagemap Short Description: The ImageMap extension for MediaWiki Owners: olea Branches: F-8 F-9 InitialCC: mtasaka
cvs done
Ismael, any news since mid September? Are you already sponsored by someone or not?
(In reply to comment #13) > Ismael, any news since mid September? Are you already sponsored by someone or > not? I am sponsoring him.
cvs updated packages build: https://koji.fedoraproject.org/koji/builds?userID=724 Now I'm supposed to push them through bodhi?
Exactly. https://admin.fedoraproject.org/updates
Done for mediawiki-imagemap-0-0.1.r37906.fc8 and mediawiki-imagemap-0-0.1.r37906.fc9 When pushing mediawiki-imagemap-0-0.1.r37906.fc10 I get an error: ------------------------- 500 Internal error The server encountered an unexpected condition which prevented it from fulfilling the request. Powered by CherryPy 2.3.0 ------------------------- :-??????
I think is fine to close now with the «NEXTRELEASE» tag.
Well, about today's F-8 broken dependency for mediawiki-imagemap I tried to mail to Ismael but it is rejected (mail returned). Would you know why? So for now I write here about how to fix it. Hello, Ismael: As you know today Michael Schwendt reported that the dependency of mediawiki-imagemap is broken on F-8 ppc64 [1] as: ------------------------------------------------- mediawiki-imagemap-0-0.1.r37906.fc8.noarch requires mediawiki >= 0:1.13 ------------------------------------------------- This is because on F-8 mediawiki does not support ppc64 at all [2] (while on F-9+ mediawiki also supports ppc64). So your last change to make dependency on mediawiki unversioned like: ------------------------------------------------- -Requires: mediawiki >= 1.13 +Requires: mediawiki ------------------------------------------------- does not work. In this case you should use "ExcludeArch" like ------------------------------------------------- BuildArch: noarch %if 0%{?fedora} == 8 ExcludeArch: ppc64 %endif Requires: mediawiki >= 1.13 ------------------------------------------------- This may seem strange because mediawiki-imagemap itself is noarch, however Fedora package server treats this correctly, so this method is valid [3] Also, please make it sure that F-8 package has EVR (Epoch-Version-Release) not larger than F-9, F-10. Currently F-9 mediawiki-imagemap has $ koji latest-pkg dist-f9-updates mediawiki-imagemap Build Tag Built by ---------------------------------------- -------------------- ---------------- mediawiki-imagemap-0-0.1.r37906.fc9 dist-f9-updates olea so F-8 mediawiki-imagemap must not have "0-0.2.xxxxx" as EVR (0-0.2.rXXXX.fc8 > 0-0.1.rXXXX.fc9). In this case you can use "0.1.r37906%{?dist}.1" for release number (see [4] ). By the way as F-8 support is near end, while it is preferable that you fix the spec file and build a new srpm for dist-f8-updates-candidate, I don't think that pushing this (submitting push request on bodhi) for F-8 branch only to fix dependency problem for ppc64 is needed. (see: [5] ) [1] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02277.html [2] http://koji.fedoraproject.org/koji/buildinfo?buildID=65333 [3] http://www.redhat.com/archives/rhl-devel-list/2007-October/msg00265.html [4] https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches [5] https://www.redhat.com/archives/fedora-devel-list/2008-October/msg02280.html