Spec URL: http://monnerat.fedorapeople.org/JSCookMenu.spec
SRPM URL: http://monnerat.fedorapeople.org/JSCookMenu-2.0.4-1.fc12.src.rpm
mimic complex menus found in popular GUI Applications. It is relatively
simple and easy to use. Creating a new theme requires some patience,
but rarely does one has to write one since some good ones are provided.
The following features are implemented:
* Supports both horizontal and vertical menus.
* Supports relative positioning.
* Supports different menus with different themes in the same web page.
* Eases the menu creation process with a menu builder.
* Special effects such as sliding and fading in/out is available.
rpmlint output: JSCookMenu.noarch: W: no-documentation
--> No documentation files provided in the upstream tarball. The MIT-compatible license text is in script comment.
koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1405548
Hi I'm here for prereview:
$ rpmlint SPECS/JSCookMenu.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
Please either include license file and mention in every source file, or include license contents in every source file.
Also, please persuade author to adopt MIT license rather than MIT-compatible license for legal concerns.
The current license is OK: this is "MIT modern style with sublicense" https://fedoraproject.org/wiki/Licensing/MIT#Modern_Style_with_sublicense
Upstream request for license clarification has been submitted:
Cool! I will follow up then.
I got a reply on http://yuanheng.org/forum/viewtopic.php?t=1690
The theme files are public domain. Unfortunately this clarification only came on the forum page.
As you can see there, I'm insisting... hang on !
License clarified by e-mail. E-mail added in %doc.
W: file-not-utf8 /usr/share/doc/JSCookMenu-2.0.4/JSCookMenu_theme_license_clarification.mail.txt
The license clarification e-mail as downloaded contains an ISO-8859-1 part (with a single ISO8859-1 non-paddable space).
Great work Patrick! I have checked the .spec again and please improve the commands into Macro ones:
Sorry to tell you, but I do not agree with this suggestion for the following reasons:
_ Although these macros are effectively defined in the /usr/lib/rpm/macros file, they are mainly intended to ease porting specs from the old Mandrake distribution. The 2 years-old page you reference to is annotated "This page could probably be deleted... Doesn't seem to be much useful information" and the referring page (https://fedoraproject.org/wiki/Packaging:RPMMacros#Reference) lists it only as a conversion aid from Mandrake spaces (altough not forbidding use of this macros, I conceed to you).
_ I did not find usage references to these macros in the packaging guidelines, neither as a requirement nor even as a recommandation.
_ The use of these macros is not very frequent in current Fedora spec files.
_ Finally, I do not like them: they lower the spec file readability and they introduce a dependency to their definitions while it is unlikely that their defined value changes sometime.
MUST: Each package must consistently use macros.
I was misunderstood about this on review guidelines. Now I would interpret that as "either use that at highest degree or just don't use that at all". Given that you haven't used it almost. This should be recognized as proper in your .spec file.
The .spec and srpm looks okay to me, but you need to get a sponsor for this new package approved.
I agree with your new opinion about macro usage consistency: if a particular macro (or macro "class") is used in a package, it must be used everywhere it can !
Thanks for reviewing. However I do not need a sponsor: I'm a Fedora developer for 18 months now! If you're still OK to accept this review, please set the flag accordingly.
$ rpmlint SPECS/JSCookMenu.spec SRPMS/JSCookMenu-2.0.4-2.fc12.src.rpm
1 packages and 1 specfiles checked; 0 errors, 1 warnings.
All MUST are passed.
Many thanks for your work on this, Kaio.
New Package CVS Request
Package Name: JSCookMenu
Branches: F-12 F-13
I can't seem to find the guideline now, but I don't think you should reload httpd in pre/post here.
Think about a web server where the admin is installing some packages and a reload disrupts their server (or there are changes that are incomplete and it doesn't restart correctly).
I would advise not restarting httpd here.
Well... this is a philosophical problem that could well degenerate into a troll :-(
In the case you mention, you're probably right, but this implies system updates are done while someone changes the server configuration, saves the (bad) configuration and does not test/apply the changes immediately... IMHO, this situation will occur very seldom.
However, I'm not wrong because there is an /etc/httpd/conf.d/*.conf file in this package and a server reload is needed to enable/disable it. phpPgAdmin (for example) reloads the server at post time for the same reason. And by the way, this is just a reload, not a restart.
In the meantime, I suggest we meet halfway by reloading the server only at first package install and last uninstall. @Kevin: would it be satisfactory to you ?
Well, the only packages in the distro that do this are:
phpPgAdmin, postgresql-pgpoolAdmin and w3c-markup-validator.
There are 134 packages in rawhide that provide a /etc/httpd/conf.d/*.conf file.
I would suggest that the 134 packages are doing the right thing here and the other 3 should get fixed to not do this. ;)
I won't hold up your review any further, but I think consulting the packaging mailing list might be a good idea before importing?
CVS done (by process-cvs-requests.py).
JSCookMenu-2.0.4-3.fc12 has been submitted as an update for Fedora 12.
JSCookMenu-2.0.4-3.fc13 has been submitted as an update for Fedora 13.
Typo fixed and post/postun scriptlets removed.
JSCookMenu-2.0.4-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
JSCookMenu-2.0.4-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.