Bug 479983 - Review Request: emacs-mew - Email client for GNU Emacs
Summary: Review Request: emacs-mew - Email client for GNU Emacs
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jochen Schmitt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-14 13:28 UTC by Akira TAGOH
Modified: 2009-01-28 07:04 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-01-28 07:04:03 UTC
Type: ---
Embargoed:
jochen: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Akira TAGOH 2009-01-14 13:28:02 UTC
Spec URL: http://tagoh.fedorapeople.org/emacs-mew/emacs-mew.spec
SRPM URL: http://tagoh.fedorapeople.org/emacs-mew/emacs-mew-6.2-1.fc10.src.rpm
Description:
Mew provides a very easy user interface to email, MIME and PGP
(Pretty Good Privacy) on the Emacs and the Editors derived from
the Emacs and so on.

This is a request to rename a srpm to make mew package better for Packaging policy.
I'm not starting to orphan old package yet.

Comment 1 Jochen Schmitt 2009-01-14 16:18:28 UTC
Bad:
- Main package contains no Provides for mew-common
- subpackage el don't contains any Obsoletes/Provides statements
- you man name the subpacke wiht 'el' insteat of '-n %{name}-el'

Comment 2 Akira TAGOH 2009-01-15 02:27:52 UTC
(In reply to comment #1)
> Bad:
> - Main package contains no Provides for mew-common

Thank you for catching this up. fixed.

> - subpackage el don't contains any Obsoletes/Provides statements

Does -el subpackage really need Obsoletes/Provides statements? I suppose it should works since it requires emacs-mew which do obsolete/provide old package.

> - you man name the subpacke wiht 'el' insteat of '-n %{name}-el'

Indeed. just followed a template in Emacs packaging policy. fixed.

Spec URL: http://tagoh.fedorapeople.org/emacs-mew/emacs-mew.spec
SRPM URL: http://tagoh.fedorapeople.org/emacs-mew/emacs-mew-6.2-2.fc10.src.rpm

Comment 3 Jochen Schmitt 2009-01-15 17:00:07 UTC
(In reply to comment #2)
> (In reply to comment #1)

> Does -el subpackage really need Obsoletes/Provides statements? I suppose it
> should works since it requires emacs-mew which do obsolete/provide old package.

I have take a further look on the new and the old package. As far as I can see, the el subpackage should replace the xemace subpackage. So please add the rigth Provides and Obsoletes-Statements for it. 

As second are you sure that the el subpackage is usable for GNU Emacs, because the old package contains a subpackage with the name xemacs?

Gest Regards:

Jochen Schmitt

Comment 4 Akira TAGOH 2009-01-16 03:41:57 UTC
(In reply to comment #3)
> I have take a further look on the new and the old package. As far as I can see,
> the el subpackage should replace the xemace subpackage. So please add the rigth
> Provides and Obsoletes-Statements for it. 

upstream doesn't support xemacs anymore. that's why I've got rid of it from new package.
I'm not quite sure if adding Provides and even Obsoletes is a good idea in this case.

> As second are you sure that the el subpackage is usable for GNU Emacs, because
> the old package contains a subpackage with the name xemacs?

the elisp source package is a kind of -debuginfo package. it's typically used for debugging purpose.

Comment 5 Jochen Schmitt 2009-01-18 16:46:56 UTC
(In reply to comment #4)

> upstream doesn't support xemacs anymore. that's why I've got rid of it from new
> package.
> I'm not quite sure if adding Provides and even Obsoletes is a good idea in this
> case.

Ok, at the minimum you should have a Obsolete-Statement, so the xemacs subpackage may remove clearly.

Best Regards:

Jochen Schmitt

Comment 7 Jochen Schmitt 2009-01-19 17:01:51 UTC
Good:
+ Basename of the SPEC files matches package name
+ Package name fits naming guildelines for emacs packages
+ Package contains most recent release of the software
+ Could download upstream tar ball with spectool
+ Tar ball in source rpm matches with upstream
(md5sum: 615de2bc3c511f244311d22485306bb9)
+ Provides/Obsoletes of the renaming prcoess seems ok.
  Rpmlint produced some warning, but because the new package doesn't
  suppoer XEmacs, this seems ok for me.
+ Package contains a valid license tag
+ License tag contains BSD as a valid OSS license
+ Package contains verbatin copy of the license text
+ Emacs source files are package in a separate el subpackage
+ el subpackage contains proper Req. to main package
+ Local build works fine
+ Debuginfo package contains source files
+ Buildroot will be cleaned on the beginning of %install and %clean
+ Build on koji works fine.
+ Local install works fine
+ %doc section contains a small amount of data, so we don't need a doc subpackage
+ All packaged files have proper file permissions
+ All packaged files are owned by the package
+ There are no files which are in conflict with other packages


Bad:
- Rpmlint complaints source package
emacs-mew.src:396: W: macro-in-%changelog post
emacs-mew.src:401: W: macro-in-%changelog description
emacs-mew.src:419: W: macro-in-%changelog post
emacs-mew.src:420: W: macro-in-%changelog postun
emacs-mew.src: E: tag-not-utf8 %changelog
- Rpmlint complaints binary package
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/incm 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/mewest 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/cmew 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/mewcat 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/smew 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/mewencode 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/mewl 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/mewdecode 0555
emacs-mew.x86_64: E: non-standard-executable-perm /usr/bin/mew-pinentry 0555
emacs-mew.x86_64: W: incoherent-version-in-changelog 6.2.3 ['6.2-3.fc10', '6.2-3']
emacs-mew.x86_64: E: tag-not-utf8 %changelog
emacs-mew.x86_64: W: obsolete-not-provided mew-xemacs
- rpmlint compaints el subpackage
emacs-mew-el.x86_64: W: no-documentation
emacs-mew-el.x86_64: E: tag-not-utf8 %changelog
emacs-mew-el.x86_64: W: obsolete-not-provided mew
TODO:
- Please notify upstream, that eatch source file should contains
a valid copyright notice
- Local uninstall produced the following messages:
install-info: warning: no entries found for `/usr/share/info/mew.info'; nothing deleted
install-info: warning: no entries found for `/usr/share/info/mew.jis.info'; nothing deleted

Comment 8 Akira TAGOH 2009-01-26 06:20:47 UTC
Thanks. hopefully this update wouldn't be missing something else:

Spec URL: http://tagoh.fedorapeople.org/emacs-mew/emacs-mew.spec
SRPM URL: http://tagoh.fedorapeople.org/emacs-mew/emacs-mew-6.2-4.fc11.src.rpm

Comment 9 Jochen Schmitt 2009-01-26 15:52:14 UTC
Good:
+ Rpmlint is ok now.

Bad:
- Error message when uninstall package still occurs.

Comment 10 Akira TAGOH 2009-01-27 01:20:41 UTC
Hmm, no idea. it works for me. is it added to /usr/share/info/dir when the package is installed?

Comment 11 Jochen Schmitt 2009-01-27 16:36:35 UTC
I have done some examinations:

It's seems that something with the F-10 info package is broken. I have found odd entries in the %{_infodir}/dir file.

After I have built the texinfo package from the devel branch the complainted issue doesn't occurs anymore.

Because that was the last issue with your package I'm glade that I can APPROVE your package.

Comment 12 Akira TAGOH 2009-01-28 02:57:29 UTC
thanks for reviewing.

New Package CVS Request
=======================
Package Name: emacs-mew
Short Description: Email client for GNU Emacs
Owners: tagoh
Branches: F-9 F-10 devel
InitialCC:

Comment 13 Kevin Fenzi 2009-01-28 05:35:03 UTC
cvs done.

Comment 14 Akira TAGOH 2009-01-28 06:01:25 UTC
**** Access denied: tagoh is not in ACL for rpms/emacs-mew/devel
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!
cvs commit: saving log message in /tmp/cvs9C0IaR

Something not yet finished to setup. can you check for that?

Comment 15 Kevin Fenzi 2009-01-28 06:17:14 UTC
Yes. There are several syncs that happen after the package is added. 
The acls are generated only every hour I think on the cvs machine. 

Please wait a while and try again. 

Feel free to set the fedora-cvs flag again if you need further attention.

Comment 16 Akira TAGOH 2009-01-28 07:04:03 UTC
Thanks. works fine now.


Note You need to log in before you can comment on or make changes to this bug.