Bug 751749

Spec URL: http://kklic.fedorapeople.org/emacs-php-mode.spec
SRPM URL: http://kklic.fedorapeople.org/emacs-php-mode-1.5.0-2.el6.src.rpm

* Fri Jul 13 2012 Karel Klíč <kklic> - 1.5.0-2
- Merged .el files to the main package
- Added php to interpreter-mode-list, rhbz#802850

Emacs in Rawhide is now built without php-mode. To ensure that php-mode is available in F18 this new package must go through a review.

Any chance to have it in the next weeks?

I am looking into this one right now.

The command:
   fedora-review -b 751749  -m fedora-rawhide-x86_64
fails without any helpfull hints:

ERROR: Exception(/home/user_to_make_rpms/reviews/751749-emacs-php-mode/srpm/emacs-php-mode-1.5.0-2.el6.src.rpm) Config(fedora-rawhide-x86_64) 0 minutes 11 seconds
INFO: Results and/or logs in: /home/user_to_make_rpms/reviews/751749-emacs-php-mode/results
ERROR: Command failed: 
ERROR: 'mock build failed, see /home/user_to_make_rpms/reviews/751749-emacs-php-mode/results/build.log'

The command:
  mock -v -r fedora-rawhide-x86_64 --rebuild emacs-php-mode-1.5.0-2.el6.src.rpm
gives more details on what goes wrong. It gives a funny error:

DEBUG util.py:264:  Error: No Packages found for:
DEBUG util.py:264:    ccache
...
ERROR: Command failed: 
 # ['/usr/bin/yum', '--installroot', '/var/lib/mock/fedora-rawhide-x86_64/root/', 'install', 'ccache', '--setopt=tsflags=nocontexts']

This seems a problem with mock or my configuration, so retrying it with target f18 in a minute.
In the mean time, if you have an idea what is wrong here I would welcome ideas how to solve this. (or should I just file a bug on mock?)

Running mock on target f18 seems to work just fine:

mock -v -r fedora-18-x86_64 --rebuild emacs-php-mode-1.5.0-2.el6.src.rpm

this creates 2 rpm files. rpmlint results look good:

$ rpmlint  emacs-php-mode-1.5.0-2.fc18.noarch.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

$ rpmlint  emacs-php-mode-1.5.0-2.fc18.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Another try using the review tool now on target f18 seems to work fine:

fedora-review -b 751749  -m fedora-18-x86_64

I'll post my results in the next comment.

Koji build for f18 runs fine, see:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=5121376
For f19 as well, see:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=5121912

Package Review
==============

Key:
[x] = Pass
[!] = Fail
[-] = Not applicable
[?] = Not evaluated
[ ] = Manual review needed

===== MUST items =====

Generic:
[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]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package requires other packages for directories it uses.
==>/usr/share/emacs/site-lisp is provided by emacs-common which in turn
   is required by emacs, which is stated as a requirement for this packages
   so this is fine.
[x]: Package uses nothing in %doc for runtime.
[x]: Package is not known to require ExcludeArch.
[x]: Package complies to the Packaging Guidelines
[x]: Texinfo files are properly installed
     Note: Texinfo .info file(s) in emacs-php-mode
==>tested using mock --shell and info pages load as expected
[-]: 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.
[-]: License field in the package spec file matches the actual license.
==>currently no license file is included in this package
[x]: Package consistently uses macro is (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Package must own all directories that it creates.
==>as mentioned above, requiring emacs and thus emacs-common should
   ensure all needed directories are available
[x]: Package does not own files or directories owned by other packages.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[-]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 30720 bytes in 1 files.
[x]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Fully versioned dependency in subpackages, if present.
[x]: Spec file lacks Packager, Vendor, PreReq tags.
[x]: Package use %makeinstall only when make install' ' DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package do not use a name that already exist
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: No rpmlint messages.

===== SHOULD items =====

Generic:
[-]: Uses parallel make.
==>no compilation of c-source code is needed for this package
   so calling parallel make does not make any sense
[!]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
==>you probably should do this
[x]: Final provides and requires are sane (see attachments).
[x]: Package functions as described.
[x]: Latest version is packaged.
==>this package is rather old, latest version from november 2008.
   Are you sure upstream is still actively supporting this?
[-]: Package does not include license text files separate from upstream.
==>if upstream is still active, you should probably ask for this.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
==>no check is provided since no test target/script is provided by upstream
[!]: Packages should try to preserve timestamps of original installed files.
==>you should probably add '-p' to the install steps in the spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: Reviewer should test that the package builds in mock.
==>works fine for f18. Note that it fails for f17 and rawhide at the moment.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: SourceX tarball generation or download is documented.
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define.

===== EXTRA items =====

Generic:
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.
[x]: Rpmlint is run on all installed packages.
     Note: No rpmlint messages.
[x]: Spec file according to URL is the same as in SRPM.

Concluding, I see no real problems with this package, only a few should items that should probably be looked at in a next round, so this package is:
APPROVED.

MMmm, it seems this package did not reach F18.
Or is it in some optionnal repository?

the package still needs to be added to the fedora git system, that it the reason it is not yet part of any repository.

Karel, could you please look into this if you find the time?

Lifting needinfo

Please also note that the maintained version is here: https://github.com/ejmr/php-mode
Have a look at the timeline.

Any update on this?

No emacs-php-mode in Fedora 20 either.  My pet peeve: removing something before making sure that users can find it elsewhere; very frustrating...

Is there any update?
Why doesn't it available in Fedora yet?

Any reason?

I guess the original packager, Karel Klíč lost interest, since he did not respond in over 3 years. If anyone else is interested to take over, I would welcome it but I am not sure about the procedure to be followed for this. Since it is not packaged yet the policy for nonresponsive package maintainers does not apply I think.

Note that whoever does end up maintaining this, the elisp files need to be installed under

%{_emacs_sitelispdir}/php-mode

rather than 

%{_emacs_sitelispdir}/

Yeah, I agree with that.
Shall I take a review?
Although, I see that the bugzilla has already fedora-review+.

Could you please finish it?

By the way, I guess that emacs packages itself should be modified, right?
Like is mentioned in #c0
But I didn't find a code.

According to the https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews (and as pointed out on the devel mailing list) this ticket is stalled and a response from the original submitter is needed. 

If he does not respond within a week, I'll close the bug as NOTABUG so we can reopen the review request in a new ticket and hopefully get it packaged soon.

I agree. Closing it.

I have created a new bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1289860

*** This bug has been marked as a duplicate of bug 1289860 ***