Bug 479983 - Review Request: emacs-mew - Email client for GNU Emacs
Review Request: emacs-mew - Email client for GNU Emacs
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jochen Schmitt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-14 08:28 EST by Akira TAGOH
Modified: 2009-01-28 02:04 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-28 02:04:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jochen: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Akira TAGOH 2009-01-14 08:28:02 EST
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 11:18:28 EST
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-14 21:27:52 EST
(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 12:00:07 EST
(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-15 22:41:57 EST
(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 11:46:56 EST
(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 12:01:51 EST
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 01:20:47 EST
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 10:52:14 EST
Good:
+ Rpmlint is ok now.

Bad:
- Error message when uninstall package still occurs.
Comment 10 Akira TAGOH 2009-01-26 20:20:41 EST
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 11:36:35 EST
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-27 21:57:29 EST
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 00:35:03 EST
cvs done.
Comment 14 Akira TAGOH 2009-01-28 01:01:25 EST
**** 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 01:17:14 EST
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 02:04:03 EST
Thanks. works fine now.

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