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.
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?
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.
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
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).
Thanks for the review. I'll fix the issues and upload new files.
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.
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.
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.
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.
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).
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.
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
*** Bug 879738 has been marked as a duplicate of this bug. ***
Please remove %defattr(-,root,root,-). And, will you continue packaging? If not I can take it.
(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.
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.
* "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.
(In reply to Christopher Meng from comment #14) > And, will you continue packaging? If not I can take it. Any news to report here?
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.
https://github.com/bboozzoo/mu-fedora/blob/master/mu.spec seems to be more up-to-date, is it the one to look at?
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
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
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
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}.
(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.
Hi Maciek, Are you still wanting to include this in Fedora? If so, I'll review it for you. Let me know.
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>
ping?
OK, closing this: it's been moribund for 3 years.