Description of problem: There is no notmuch package for epel7 Version-Release number of selected component (if applicable): 0.25 How reproducible: $ yum search notmuch Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.denit.net * centosplus: mirror.denit.net * epel: fr.mirror.babylon.network * extras: mirror.denit.net * updates: mirror.denit.net Warning: No matches found for: notmuch No matches found Expected results: Being able to install notmuch including dependancies. Additional info: There is a Fedora 27 package available.
Resetting this to the current maintainer. Also we should probably add epel9 as well? Willing to help maintain this, please add salimma and the epel-packagers-sig group as comaintainers, thanks
notmuch (upstream) uses linear release history without release branches nor bugfix backports. This fits fell with Fedora's release model, and is quite orthogonal to RHEL/EPEL. Typically, a linear upstream creates a lot of maintenance burden (which is why you pay for REHL) unless you are prepared to live with an old version for RHEL lifetime. Now, notmuch does not "face the internet" and has a good security track record so far, so I might consider it, and I'd appreciated some help from those "in the EPEL knows": - Does EPEL9 support autorelease? (I just switched not long ago.) - Are notmuch's build requirements in EPEL already? - Does it build on RHEL 9 and or Stream? - Does it make sense (or is it required) to consider ELN or stream when packaing for EPEL9? (The new F-related EL world has many players.) Also, I'm sure I can find EPEL packaging guidelines somewhere but you'll have them handy already, so that would be nice.
I've just build notmuch (for my own selfish needs) COPR: https://copr.fedorainfracloud.org/coprs/flatcap/neomutt/packages/ It requires two extra packages, which I pulled from F35: - gmime30-3.2.7-5.fc35.src.rpm - xapian-core-1.4.18-3.fc35.src.rpm To build notmuch, again using the F35 rpm, I needed to remove two `BuildRequires` - glib - python3-pytest-shutil then it built correctly.
Created attachment 1844907 [details] modified spec to build notmuch
(In reply to Richard Russon from comment #3) > I've just build notmuch (for my own selfish needs) > > COPR: https://copr.fedorainfracloud.org/coprs/flatcap/neomutt/packages/ Good news! > It requires two extra packages, which I pulled from F35: > > - gmime30-3.2.7-5.fc35.src.rpm > - xapian-core-1.4.18-3.fc35.src.rpm So we would need to get those into EPEL or C-Stream before. > To build notmuch, again using the F35 rpm, I needed to remove two > `BuildRequires` > - glib Interesting. I'm pretty confident you are building with glib, but in fact removing the explicit BR works on F35, too. > - python3-pytest-shutil This is used in the test suite only, so no biggy. Though I'm suprised it's missing in RHEL+EPEL. > then it built correctly. And, apparantly, gmime30 and xapian build there, too. Who is going to take care of these? I'll fold the necessary notmuch spec-changes into the next update (0.34.2 is around upstream's corner). I see you prepocessed the spec. So, no autospec for EPEL 9, or was this just for copr's purposes?
> I see you prepocessed the spec Ah, that's my ignorance. I just extracted it from the source rpm.
So, apparantly xapian-core-devel is in Code Ready Builder resp. PowerTools, something I didn't even know existed before trying to make sense of some acronyms in the other bug. And apparantly you can introduce new packages in a RHEL minor release - even without following up on the main branch? As it turns out again, the EL universe is too much for my simple brain. Tell me when the prerequisites for notmuch are ready in EL land, and what to do then ... Or, better, take the epel branch and do as you wish ;)
xapian-core-devel is indeed now available in CRB, and I've filed a ticket for the missing gmime30 package in EPEL. Once that's sorted out, all the prerequisites for notmuch should be available.
(In reply to Davide Cavalca from comment #8) > xapian-core-devel is indeed now available in CRB, and I've filed a ticket > for the missing gmime30 package in EPEL. Once that's sorted out, all the > prerequisites for notmuch should be available. Thanks! Just to clarify: - Is CRB/... "on" by default for EPEL builds? - Is it available for RHEL rebuilds (Alma etc.)? - Is there an equivalent for CentOS stream? - Do we get xapian-core-devel and gime for EPEL 9, too? But maybe we have to treat EL8, EL9 and Stream completely separately, anyway.
(In reply to Michael J Gruber from comment #9) > Just to clarify: > - Is CRB/... "on" by default for EPEL builds? It is, and the documentation also recommends enabling it on systems that enable EPEL: https://docs.fedoraproject.org/en-US/epel/#_quickstart > - Is it available for RHEL rebuilds (Alma etc.)? To my knowledge, yes, but I haven't played that much with the rebuilds. > - Is there an equivalent for CentOS stream? Yes, the repo is called PowerTools on CentOS Stream 8 and CRB on CentOS Stream 9. > - Do we get xapian-core-devel and gime for EPEL 9, too? Yes, xapian-core-devel is already available in CRB for el9, and once #2040721 is sorted out gmime30 will be branched and available for both el8 and el9, > But maybe we have to treat EL8, EL9 and Stream completely separately, anyway. el8 and el9 builds will respectively end up in EPEL 8 and EPEL 9. There shouldn't be any special casing needed for Stream for this package, but in case that were needed, that's what EPEL Next is for (https://docs.fedoraproject.org/en-US/epel/#what_is_epel_next).
Perfect! Thanks for the info and the pointers. Seems we're on a good path here.
On EPEL9, all tests pass which are not skipped (dtach, shutil missing). So let's go ahead: fedpkg request-branch epel9 https://pagure.io/releng/fedora-scm-requests/issue/42083 (I know the original request was about EPEL8 and that is in the works, too. It uses python2 and has no python2-sphinx.)
(In reply to Michael J Gruber from comment #12) > (I know the original request was about EPEL8 and that is in the works, too. > It uses python2 and has no python2-sphinx.) And I meanwhile figured EPEL8 is "in between" py2 and py3 ... Going with py3 for now.
fedpkg request-branch epel8 https://pagure.io/releng/fedora-scm-requests/issue/42084 EPEL8 https://koji.fedoraproject.org/koji/taskinfo?taskID=82676691 EPEL9 https://koji.fedoraproject.org/koji/taskinfo?taskID=82675153 I'll also see what builds in copr (mjg/notmuch), depending on the state of the chroots there.
FEDORA-EPEL-2022-5f3e206d1f has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5f3e206d1f
FEDORA-EPEL-2022-3ac34f8a16 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3ac34f8a16
epel-packagers-sig set as collaborators for epel* Let me know in case you need more. FTR: epel9 epel8 f37 f36 f35 will have the same notmuch release once the current updates went through. epel8 will stay put unless there are serious bugs. epel9 should probably stay put, too, unless I misread the EPEL guidelines. Released Fedora usually follows notmuch upstream releases since/when they accumulate bugfixes and don't break aynthing. Rawhide, well, you get what you ask for :)
FEDORA-EPEL-2022-3ac34f8a16 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-3ac34f8a16 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-5f3e206d1f has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-5f3e206d1f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-3ac34f8a16 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2022-5f3e206d1f has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.