Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Review Request: mu - mu is a collection of utilties for indexing and searching Maildirs|
|Product:||[Fedora] Fedora||Reporter:||Andy Bailey <bailey>|
|Component:||Package Review||Assignee:||Nobody's working on this, feel free to take it <nobody>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-12-15 11:01:19 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Andy Bailey 2010-12-05 13:37:18 EST
Spec URL: https://github.com/GooseYArd/rpm/raw/master/SPECS/mu.spec SRPM URL: https://github.com/GooseYArd/rpm/raw/master/SRPMS/mu-0.9.11.fc14.src.rpm Description: mu is a set of tools for dealing with Maildirs and the e-mail messages in them. This is my first package, so I'm hunting for a sponsor. A couple of notes about the spec, as you can see from the sed commands, there's a libtool/rpath issue in the package. I read that autoreconfing is frowned upon, so this solution seems to work reasonably well. I've been working with the upstream author already on a few other configure.ac changes to help building on fc-14, so I suspect we'll be able to eliminate this kludge within an upstream release or two. Thanks!
Comment 1 Andy Bailey 2010-12-05 13:40:13 EST
one more thing- the short name worries me a little- the author uses "mu0" at google code (I'm guessing maybe theres a minimum length?), but the project is also referred to as "mu-tools" in a few places, so I think there's an alternative if "mu" doesn't work for Fedora packaging.
Comment 2 Andy Bailey 2010-12-07 14:35:34 EST
user tibbs on #fedora-devel suggested that I review some other pendingreview packages to help secure a sponsorship of this one. I found a few interesting ones that I'll note here. First, 611372.
Comment 3 Andy Bailey 2010-12-08 12:05:14 EST
I'll also work on 634025.
Comment 4 Andy Bailey 2010-12-15 11:01:19 EST
Withdrawing submission, I think simply having a working spec file satisfies my needs. It'll be available at the same location if an established maintainer would like to create a new package later.