Bug 821917

Summary: Review Request: mu - maildir utility with Emacs support
Product: [Fedora] Fedora Reporter: Maciek Borzecki <maciek.borzecki>
Component: Package ReviewAssignee: Jonathan Underwood <jonathan.underwood>
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: bugs.michael, georgi.t.valkov, i, jonathan.underwood, josdekloe, maciek.borzecki, martin, package-review, py, ville.skytta
Target Milestone: ---Flags: jonathan.underwood: needinfo? (maciek.borzecki)
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: BuildFails
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 177841    

Description Maciek Borzecki 2012-05-15 14:30:59 EDT
Spec URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu.spec
SRPM URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu-0.9.8.4-1.fc16.src.rpm
Description: mu is a tool for dealing with e-mail messages stored in the
Maildir-format, on Unix-like systems. mu's main purpose is to help you
to find the messages you need, quickly; in addition, it allows you to
view messages, extract attachments, create new maildirs, etc. mu has a
nice Emacs interface provided in emacs-mu4e package.
Comment 1 Jos de Kloe 2012-10-08 16:29:56 EDT
the packaged mu version does not build manually on Fedora17 because of a bug in the configure script. It does not recognise xapian versions 1.2.10 or above (see issue 55 (http://code.google.com/p/mu0/issues/detail?id=55). The actual xapian version on Fedora17 is 1.2.12.
The same problem prevents building the binary rpm packages on current Fedora17 systems.

Could you please upgrade to mu 0.9.8.5 to allow me to do an (informal) review of your package?
Comment 2 Maciek Borzecki 2012-10-12 03:07:39 EDT
Sorry for the delay, been quite busy lately. The package is upgraded to 0.9.8.5. Builds fine on my F17.
Spec URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu.spec
SRPM URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu-0.9.8.5-1.fc17.src.rpm
I did a scratch build for f17 on koji as well: http://koji.fedoraproject.org/koji/taskinfo?taskID=4584418

There is one quirk though, rpmlint complains about source URL not found (404), but my understanding is that it's related to #767739 since tgz is hosted on googlecode.
Comment 3 Maciek Borzecki 2012-10-12 03:09:58 EDT
Obviously, I added wrong link to koji build (only x86_64), the correct URL to both arches is http://koji.fedoraproject.org/koji/taskinfo?taskID=4584417
Comment 4 Jos de Kloe 2012-10-13 16:26:38 EDT
Thanks for upgrading.

rpmbuild -ba runs fine on my Fedora17 system and creates 4 rpms and one srpm package. The rpmlint results are these:


rpmlint mu-0.9.8.5-1.fc17.src.rpm
mu.src: W: spelling-error %description -l en_US maildirs -> airmails
mu.src: W: invalid-url Source0: http://mu0.googlecode.com/files/mu-0.9.8.5.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

rpmlint mu-0.9.8.5-1.fc17.x86_64.rpm
mu.x86_64: E: explicit-lib-dependency glib2
mu.x86_64: E: explicit-lib-dependency libuuid
mu.x86_64: E: explicit-lib-dependency xapian-core-libs
mu.x86_64: E: explicit-lib-dependency zlib
mu.x86_64: W: spelling-error %description -l en_US maildirs -> airmails
mu.x86_64: W: spelling-error %description -l en_US emacs -> Emacs, macs, maces
mu.x86_64: E: binary-or-shlib-defines-rpath /usr/bin/mu ['/usr/lib64']
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-find.1.gz 54: cannot use newline as a starting delimiter
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-find.1.gz 405: warning: macro `T' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-cfind.1.gz 101: warning: macro `sh' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-cfind.1.gz 103: warning: macro `si' not defined
mu.x86_64: E: standard-dir-owned-by-package /usr/share/man/man5
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-index.1.gz 137: warning: macro `si' not defined
mu.x86_64: E: info-files-without-install-info-postin /usr/share/info/mu4e.info.gz
mu.x86_64: E: info-files-without-install-info-postun /usr/share/info/mu4e.info.gz
mu.x86_64: E: standard-dir-owned-by-package /usr/share/man/man1
1 packages and 0 specfiles checked; 9 errors, 7 warnings.

rpmlint emacs-mu4e-0.9.8.5-1.fc17.noarch.rpm
emacs-mu4e.noarch: W: no-documentation
1 packages and 0 specfiles checked; 0 errors, 1 warnings.

rpmlint emacs-mu4e-el-0.9.8.5-1.fc17.noarch.rpm
emacs-mu4e-el.noarch: W: spelling-error %description -l en_US elisp -> lisp, e lisp, Ellis
emacs-mu4e-el.noarch: W: no-documentation
emacs-mu4e-el.noarch: E: incorrect-fsf-address /usr/share/emacs/site-lisp/mu4e/mu4e-speedbar.el
1 packages and 0 specfiles checked; 1 errors, 2 warnings.

rpmlint mu-debuginfo-0.9.8.5-1.fc17.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.


Please try to address the warnings and errors mentioned.
The warning about the invalid-url on googlecode can be ignored for now. This is a known rpmlint problem, see: https://bugzilla.redhat.com/show_bug.cgi?id=767739

Some additional comments on your spec file:

Two different styles of macros are mixed in this spec file, i.e.:
$RPM_BUILD_ROOT%{_datadir}/info/dir

please choose a consistent style, i.e. use:
%{buildroot}%{_datadir}/info/dir
(see http://fedoraproject.org/wiki/Packaging:Guidelines, 
 1.35.1 Using %{buildroot} and %{optflags} vs $RPM_BUILD_ROOT and $RPM_OPT_FLAGS)

the install-info commands seem issued on the wrong subpackage.
mu4e.info.gz is part of the mu rpm, not the emacs-mu4e rpm

The incorrect-fsf-address error is explained here:
https://fedoraproject.org/wiki/Common_Rpmlint_issues

The warnings on the man pages should probably be passed on to upstream.

Please don't own the standard man page directories, only the files below them.

Finally I wonder why the *.elc files are provided in both the
emacs-mu4e-el and emacs-mu4e package. 
It seems to me this may confuse the rpm database in case both packages are installed (but I'm not completely sure, so if anyone has more experience with this, please step in).
Comment 5 Maciek Borzecki 2012-10-13 17:10:00 EDT
Thanks for the review. I'll fix the issues and upload new files.
Comment 6 Jos de Kloe 2012-10-19 17:48:47 EDT
for completeness, I also tested using mock:

mock -r fedora-rawhide-x86_64 --rebuild mu-0.9.8.5-1.fc17.src.rpm
runs fine and creates 4 rpms and one srpm as reported for rpmbuild above. The rpmlint results are identical.
Comment 7 Maciek Borzecki 2012-10-21 07:16:22 EDT
I've updated to 0.9.9.

Spec URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu.spec
SRPM URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu-0.9.9-2.fc17.src.rpm
Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4612389

rmpmlint output for all 4 packages (3 rpms, 1 srcrpm):
mu.src: W: spelling-error %description -l en_US maildirs -> airmails
mu.src:51: W: configure-without-libdir-spec
mu.src: W: invalid-url Source0: http://mu0.googlecode.com/files/mu-0.9.9.tar.gz HTTP Error 404: Not Found
mu.x86_64: W: spelling-error %description -l en_US maildirs -> airmails
mu.x86_64: W: spelling-error %description -l en_US emacs -> Emacs, macs, maces
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-find.1.gz 54: cannot use newline as a starting delimiter
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-find.1.gz 429: warning: macro `T' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-remove.1.gz 5: cannot use a space as a starting delimiter
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-index.1.gz 137: warning: macro `si' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-cfind.1.gz 103: warning: macro `sh' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-cfind.1.gz 105: warning: macro `si' not defined
emacs-mu4e-el.noarch: W: spelling-error %description -l en_US elisp -> lisp, e lisp, Ellis
emacs-mu4e-el.noarch: W: no-documentation
emacs-mu4e-el.noarch: E: incorrect-fsf-address /usr/share/emacs/site-lisp/mu4e/mu4e-speedbar.el
4 packages and 0 specfiles checked; 1 errors, 13 warnings.

mu.src:51 - comes from additional check if configure exists. I'll try to push the spec into upstream, so rebuilds of subsequent releases are easier.

Man and incorrect-fsf-address errors will be pushed upstream, perhaps with patches if time permits.
Comment 8 Jos de Kloe 2012-10-27 18:34:59 EDT
Thanks for the updated version. Here is my (informal) review:

rpmbuild runs fine, creates 4 new rpms and one srpm.
Also mock creates the same rpms and srpm.

rpmlint output on my side is as follows

rpmlint ~/rpmbuild/SRPMS/mu-0.9.9-2.fc17.src.rpm
mu.src: W: spelling-error %description -l en_US maildirs -> airmails
mu.src:51: W: configure-without-libdir-spec
mu.src: W: invalid-url Source0: http://mu0.googlecode.com/files/mu-0.9.9.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

The new warning about configure seems not relevant to me, since line 51 of the
spec file checks for the existence of the configure script, and does not
launch it.

rpmlint ~/rpmbuild/RPMS/x86_64/mu-0.9.9-2.fc17.x86_64.rpm
mu.x86_64: W: spelling-error %description -l en_US maildirs -> airmails
mu.x86_64: W: spelling-error %description -l en_US emacs -> Emacs, macs, maces
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-find.1.gz 54: cannot use newline as a starting delimiter
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-find.1.gz 429: warning: macro `T' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-remove.1.gz 5: cannot use a space as a starting delimiter
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-index.1.gz 137: warning: macro `si' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-cfind.1.gz 103: warning: macro `sh' not defined
mu.x86_64: W: manual-page-warning /usr/share/man/man1/mu-cfind.1.gz 105: warning: macro `si' not defined
1 packages and 0 specfiles checked; 0 errors, 8 warnings.

since you agree to send the man page warnings upstream,
this is fine for the moment

rpmlint ~/rpmbuild/RPMS/noarch/emacs-mu4e-0.9.9-2.fc17.noarch.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

rpmlint ~/rpmbuild/RPMS/noarch/emacs-mu4e-el-0.9.9-2.fc17.noarch.rpm
emacs-mu4e-el.noarch: W: spelling-error %description -l en_US elisp -> lisp, e lisp, Ellis
emacs-mu4e-el.noarch: W: no-documentation
emacs-mu4e-el.noarch: E: incorrect-fsf-address /usr/share/emacs/site-lisp/mu4e/mu4e-speedbar.el
1 packages and 0 specfiles checked; 1 errors, 2 warnings.

since you agree to send the fsf address error upstream
this is fine for the moment

rpmlint ~/rpmbuild/RPMS/x86_64/mu-debuginfo-0.9.9-2.fc17.x86_64.rpm
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

MUST items as mentioned in:
  https://fedoraproject.org/wiki/Packaging/ReviewGuidelines

key:
[+] OK
[.] OK, not applicable
[X] needs work

[+] MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.[1]
[+] MUST: The package must be named according to the Package Naming Guidelines .
[+] MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. [2] .
[+] MUST: The package must meet the Packaging Guidelines .
[+] MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines .
[+] MUST: The License field in the package spec file must match the actual license. [3]
[+] MUST: 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 must be included in %doc.[4]
[+] MUST: The spec file must be written in American English. [5]
[+] MUST: The spec file for the package MUST be legible. [6]
[+] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use sha256sum for this task as it is used by the sources file once imported into git. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.
[+] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. [7]
[.] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. [8]
[+] MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.
[.] MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.[9]
[.] MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. [10]
[+] MUST: Packages must NOT bundle copies of system libraries.[11]
[.] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. [12]
[X] MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. [13]
[+] MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)[14]
[+] MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. [15]
[+] MUST: Each package must consistently use macros. [16]
[+] MUST: The package must contain code, or permissable content. [17]
[.] MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). [18]
[.] MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. [18]
[.] MUST: Static libraries must be in a -static package. [19]
[.] MUST: Development files must be in a -devel package. [20]
[.] MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release} [21]
[.] MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.[19]
[.] MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. [22]
[+] MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [23]
[+] MUST: All filenames in rpm packages must be valid UTF-8. [24]

The only remaining remark I can make results from the requirement "A package must own all directories that it creates":

The directory: %{_emacs_sitelispdir}/mu4e
is used by the packages emacs-mu4e and emacs-mu4e-el
but it is not explicitely owned yet. Since this is a common directory
for both, I think the main package "mu" schould own the directory, even if
it does not place any files in it. This way it will get properly removed
in case of uninstalling the mu rpm and its dependencies.
Comment 9 Maciek Borzecki 2012-11-05 14:56:33 EST
Spec URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu.spec
SRPM URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu-0.9.9-3.fc17.src.rpm
Koji scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=4656883

I've set package emacs-mu4e to be an owner of %{_emacs_sitelispdir}/mu4e, similarly to what other emacs packages (* and *-el) seem to do.

Man and fsf-address warnings have already been fixed in upsteam and all that should be gone with 0.9.9.5 release.
Comment 10 Jos de Kloe 2012-11-07 16:48:15 EST
Thanks for updating.

rpmbuild and mock results look fine again, and rpmlint outputs are identical to your 0.9.902 version.

Looking at https://fedoraproject.org/wiki/Packaging:Emacs (section 1.4 package contents), the "Why package the source elisp?" note says that the main purpose of the elisp package is to get help on variables and provide debugging information on the *.elc files.
Therefore the emacs-mu4e-el is only useful for this purpose when emacs-mu4e is installed as well, so adding the directory ownership to emacs-mu4e is fine I think.

Thinking about this, I think emacs-mu4e-el should explicitely require emacs-mu4e.
I inspected randomly two other packages that package emacs extensions and they do this as well (looked at mercurial and gnuplot).
Comment 11 Maciek Borzecki 2012-11-09 02:19:38 EST
Spec URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu.spec
SRPM URL: http://fiona.dmcs.pl/~mborzecki/fedora/mu/mu-0.9.9-4.fc17.src.rpm

The dependency is fixed now. Thanks for pointing that out.
Comment 12 Jos de Kloe 2012-11-18 16:27:46 EST
Thanks for adding this dependency. I am happy with this version of the spec file and have no further remarks.

Testing with rpmbuild and mock still works fine and rpmlint results are unchanged.
koji test results are here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=4701669

As mentioned earlier, my review is an informal one, meaning that I do not have the rights to sponsor you. You still need to find a sponsor to allow the package to be accepted into Fedora. The best way is to introduce yourself on the devel mailinglist (assuming you did not yet do this).

The procedure for this is detailed here:
https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
Comment 13 Fabian Affolter 2013-02-09 03:48:55 EST
*** Bug 879738 has been marked as a duplicate of this bug. ***
Comment 14 Christopher Meng 2013-07-15 20:00:15 EDT
Please remove %defattr(-,root,root,-).

And, will you continue packaging? If not I can take it.
Comment 15 Maciek Borzecki 2013-07-16 02:31:51 EDT
(In reply to Christopher Meng from comment #14)
> Please remove %defattr(-,root,root,-).
Will fix.

> And, will you continue packaging? If not I can take it.
Yes, I have an update to 0.9.9.5 that I'll be posting shortly.

Does the rest of the packaging look fine? Jos de Kloe helped me out a lot on that.
Comment 16 Christopher Meng 2013-07-16 04:15:42 EDT
I'm not sure.

BTW you are still blocked by NEEDSPONSOR....

My thoughts:

0. Update to the latest version, and scratch a koji build.

1. I don't know why you added:

if [ ! -x ./configure ] ; then
   /usr/bin/autoreconf -if
fi

I think you can notify upstream to update the relevant files(config.guess and so on).

2. Hint:

Use %{_infodir} to replace %{_datadir}/info

3. Suggestion:

Fix the changelog,

* Fri Oct 12 2012 Maciek Borzecki <maciek@corsair> - 0.9.8.5-1

Maybe you are hurried at that time.

4. I hope you can find a sponsor in these days.
Comment 17 Michael Schwendt 2013-10-28 07:19:31 EDT
* "fedora-review -b 821917" fails due to a build failure. Give it a try.


* Manual rpmbuild on Fedora 20 development also fails:

  checking for xapian-config... xapian-config
  configure: error: *** xapian version >= 1.2 needed, but version 1.2.15 found.


> make %{?_smp_mflags}

Build output is non-verbose. Figure out whether can configure with --disable-silent-rules, whether running "V=1 make …" works, or whether patching the Makefiles may be needed.

Only then it would become possible to see the used compiler/link flags and options and e.g. verify them.


> %install
> rm -rf %{buildroot}

Buildroot is created and emptied automatically nowadays, so preferably be explicit about whether the spec file is supposed to target EL5:
https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag


> %defattr(-,root,root,-)

is not needed anymore for any of the active dists (even EL5):
https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions


> %{_datadir}/man/man*/*.gz

%{_datadir}/man/man*/*  is what many reviewers recommend, because it allows for changed/customised/disabled compression of manual pages.


* Without being able to build the package, I can only point out that I find its inter-dependencies too complicated:

  emacs-mu4e-el requires emacs-mu4e, which in turn requires emacs(bin) and mu

but

  emacs-mu4e-el additionally requires emacs and mu

so the dependency on "emacs" and "mu" is redundant, and since I wondered why splitting of the source files into a separate subpackage would be justified, I've searched a bit in the packaging guidelines:

  https://fedoraproject.org/wiki/Packaging:Emacs#Packaging_of_source_elisp_files

That part of the guidelines explains several scenarios. Splitting of -el subpackages for the source files has been done only up to Fedora 16. It's even possible to include the files in the base "mu" package with a proper dep on emacs-filesystem.
Comment 18 Ville Skyttä 2014-05-28 06:13:06 EDT
(In reply to Christopher Meng from comment #14)
> And, will you continue packaging? If not I can take it.

Any news to report here?
Comment 19 Martin Dengler 2014-07-03 19:10:49 EDT
FWIW, http://rpm.pbone.net/index.php3/stat/26/dist/86/size/1224942/name/mu-0.9.9-11.1.src.rpm builds and installs usefully for me on Fedora 20.
Comment 20 Pierre-Yves Luyten 2014-10-18 13:51:40 EDT
https://github.com/bboozzoo/mu-fedora/blob/master/mu.spec seems to be more up-to-date, is it the one to look at?
Comment 21 Maciek Borzecki 2014-12-12 15:26:28 EST
Updated to upstream mu 0.9.11 release tag. Upstream has moved from googlecode to github, hence git SHA-1 corresponding to 0.9.11 tag is used.

Updated SPEC: https://raw.githubusercontent.com/bboozzoo/mu-fedora/4c99fe9b4c27dd6a28ce0cfff4c448f13c595a36/mu.spec

Koji builds: http://koji.fedoraproject.org/koji/taskinfo?taskID=8364297
Comment 22 Michael Schwendt 2014-12-13 11:12:43 EST
Several points raised in comment 17 remain.


Additionally:

* build.log output mentions "make check". This could be done in the %check section of the spec file. If it cannot be done, the spec file should tell.

* guile-%{name} and guile-mu are mixed throughout the spec file. That decreases readability, since %name is "mu" too.

* /usr/share/mu and /usr/share/mu/scripts directories are not included:
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership


> %files -n guile-%{name}-devel
> %{_libdir}/libguile-mu.so

Moving this library into a -devel package means that one could not use Guile for running Scheme scripts, because this is a runtime file for scripts, not a build-time file:
https://fedoraproject.org/wiki/Packaging:Guidelines#Devel_Packages
Comment 23 Maciek Borzecki 2014-12-27 11:37:09 EST
Addressed most of the comments. I've completely dropped separate guile packages as that made little sense. The guile bindings are part of mu anyway, so extra packages were redundant.

fedora-review brings up a couple of issues though:
- unversioned *.so file - this is really needed for guile bindings, and using 'mu' modules triggers a dlopen of libguile-mu.so in %{_libdir}
- a couple of files are listed in licensecheck.txt due to missing license info, I'll be forwarding this upstream

Updated spec: https://raw.githubusercontent.com/bboozzoo/mu-fedora/f16824cf37e85bad17f419899da1640de6298b00/mu.spec

Koji buils: http://koji.fedoraproject.org/koji/taskinfo?taskID=8485709
Comment 24 Christopher Meng 2014-12-27 21:36:25 EST
I still can see %define macro in the spec. And it really doesn't make too much sense to replace 4 chars dcjb with 8 chars %{owner}.
Comment 25 Maciek Borzecki 2014-12-28 04:10:32 EST
(In reply to Christopher Meng from comment #24)
> I still can see %define macro in the spec.

I don't see %define anywhere in the spec. Are you sure that you're looking at this file https://raw.githubusercontent.com/bboozzoo/mu-fedora/f16824cf37e85bad17f419899da1640de6298b00/mu.spec ? Can indicate which line has %define in it?

> And it really doesn't make too
> much sense to replace 4 chars dcjb with 8 chars %{owner}.

That's rather cosmetic.
Comment 26 Jonathan Underwood 2015-06-03 06:20:05 EDT
Hi Maciek,

Are you still wanting to include this in Fedora? If so, I'll review it for you. Let me know.
Comment 27 Jonathan Underwood 2015-06-04 10:19:37 EDT
Also, please can you stick to this format when posting your latest spec and SRPM so that the fedora-review tool finds the latest versions:

Spec URL: <url>
SRPM URL: <url>