AlmaLinux/CentOS/RHEL rpm pacakges

[ghost]

Hello!

I wanted to create an RPM package of fts-xapian, to make it easy for me to install it on various email servers. In case anyone is interested, here is my spec file:

Name:           fts-xapian
Version:        1.4.8
Release:        1%{?dist}
Summary:        Dovecot FTS plugin based on Xapian

License:        LGPL-2.1
URL:            https://github.com/grosjo/fts-xapian
Source0:        fts-xapian-1.4.8.tar.gz

BuildRequires:  xapian-core-devel, libicu-devel, dovecot-devel
Requires:       xapian-core, xapian-core-libs, dovecot

%description
This project intends to provide a straightforward, simple and maintenance free, way to configure FTS plugin for Dovecot, leveraging the efforts by the Xapian.org team.

This effort came after Dovecot team decided to deprecate "fts_squat" included in the dovecot core, and due to the complexity of the Solr plugin capabilitles, un-needed for most users.

%prep
%autosetup
autoreconf -vi
./configure --with-dovecot=/usr/lib64/dovecot

%build
make %{?_smp_mflags}

%install
%make_install

%files
/usr/lib64/dovecot/lib21_fts_xapian_plugin.la
/usr/lib64/dovecot/lib21_fts_xapian_plugin.so
/usr/lib64/dovecot/lib21_fts_xapian_plugin.a

%changelog
* Tue Apr  6 2021 xapian
- 

As root:

• Install the development environment and required devel packages: -- dnf groupinstall "Development Tools" -- dnf install rpm-build rpm-devel rpmlint make coreutils diffutils patch rpmdevtools -- dnf install dovecot-devel dovecot libicu-devel icu xapian-core xapian-core-devel

As a normal user:

• Create the ~/rpmbuild tree as a normal user (never build rpms as root): -- rpmdev-setuptree
• Place the spec file under:
• ~/rpmbuild/SPECS/fts-xapian.spec
• Place the tar.gz sources under:
• ~/rpmbuild/SOURCES/fts-xapian-1.4.8.tar.gz
• Generate the binary rpm with: -- QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild -bb ~/rpmbuild/SPECS/fts-xapian.spec

Your RPM packages will be under ~/rpmbuild/RPMS/x86_64/

It would be nice if you could maintain packages for EPEL, so all enterprise linux variants can use fts-xapian without custom compiled packages.

Thank you.

[grosjo]

I believe there is an official way to request a new RPM in the related distribution, right ?

[ghost]

To be honest, I don't know. Usually the authors of some software are also the ones doing the packaging, at least on active projects.

[grosjo]

@Bill-ColeUS Any pointer on how to do that ?

[ghost]

I did a little bit of background research and it appears that the correct way, is to first package your project for Fedora, THEN request an EPEL branch. That should cover pretty much all RPM based distributions like Fedora/AlmaLinux/RockyLinux/RHEL/CentOS, etc.

https://fedoraproject.org/wiki/Category:Package_Maintainers https://fedoraproject.org/wiki/EPEL_Package_Maintainers

Since you already have a basic SPEC file, the rest is simple, join the team and submit the package for review. Sorry I can't be of more help, I've created packages for myself but never submitted an official one.

[a16bitsysop]

Doesn’t it just need the one file: /usr/lib64/dovecot/lib21_fts_xapian_plugin.so

[grosjo]

@Bill-ColeUS

I installed Fedora on a virtual machine, and adjusted your data

Now , running the coomands in rpm.sh (see my github folder), I reach:

ERROR 0010: file '/usr/lib64/dovecot/lib21_fts_xapian_plugin.so' contains an empty rpath in []

Can you help ?

[a16bitsysop]

I maintain the alpine Linux package, in that I remove the rpath with chrpath -d "$pkgdir"/usr/lib/dovecot/lib21_fts_xapian_plugin.so

[ghost]

You may ignore that error, it comes from a script run on official Fedora packages.

Just prefix your rpmbuild command with QA_RPATHS=$(( 0x0001|0x0010 ))

Here is my complete command that I used to create the package:

cd ~/rpmbuild
QA_RPATHS=$(( 0x0001|0x0010 )) rpmbuild -bb --nodebuginfo ./SPECS/fts-xapian.spec

[a16bitsysop]

So needs a makedepends of chrpath as well, not sure how to do that for an rpm

[grosjo]

It works now

However, when building with "koji" (as required by the doc), it fails, not finding "g++" https://kojipkgs.fedoraproject.org//work/tasks/9140/66659140/build.log

ANy clue ?

[grosjo]

https://bugzilla.redhat.com/show_bug.cgi?id=1953340 Make sense ?

[a16bitsysop]

Instead of removing the static files I use --enable-static=no When calling configure as well

[ghost]

I don't know anything about "koji" since I've never created official packages, sorry.

I do know, that g++ is provided by the gcc-c++ package.

Thank you for taking the time to submit official packages,

[grosjo]

@eclipseo Running fedora in a VM, I get :

[root@localhost RPM]# fedora-review --mock-config fedora-rawhide-x86_64 -n glyr ERROR: 'No mock group - mock not installed or mock not in effectivegroups. Try running "newgrp" or logging out from all your local sessions and logging back in. Or disable test using REVIEW_NO_MOCKGROUP_CHECK, see manpage' (logs in /root/.cache/fedora-review.log)

Can you also clarify the link between glyr and dovecot-fts-xapian ?

[eclipseo]

@eclipseo Running fedora in a VM, I get :

[root@localhost RPM]# fedora-review --mock-config fedora-rawhide-x86_64 -n glyr ERROR: 'No mock group - mock not installed or mock not in effectivegroups. Try running "newgrp" or logging out from all your local sessions and logging back in. Or disable test using REVIEW_NO_MOCKGROUP_CHECK, see manpage' (logs in /root/.cache/fedora-review.log)

First you have to set up mock as described in https://github.com/rpm-software-management/mock/wiki#setup Simply add your user to the mock group:

usermod -a -G mock [User name]

Then relog or run:

newgrp -

If the mock group doesn't exist, just create it beforehand with newgrp. The mock group should have been created when it was installed though.

Can you also clarify the link between glyr and dovecot-fts-xapian ?

As I have explained in the bug report, before being accepted in the packager group, you have to show that you have a good grasp of the packaging guidelines. I know it might seems excessive for one simple package you want to maintain, but this is the process we all had to pass to have contributors of good quality and knowledgeable. I use the SPEC I sent you as a test because it's a good example of errors a new packager might make. Understanding what the issues are shows you have good knowledge of the packaging guidelines.

I am available for any questions you might have.

[grosjo]

I get this INFO: Processing local files: glyr INFO: Getting .spec and .srpm Urls from : Local files in /home/joan/tmp INFO: --> SRPM url: file:///home/joan/tmp/glyr-1.0.10-1.src.rpm INFO: --> Spec url: file:///home/joan/tmp/glyr.spec INFO: Using review directory: /home/joan/tmp/review-glyr INFO: No upstream for (Source0): glyr-1.0.10.tar.gz INFO: Running checks and generating report INFO: Results and/or logs in: /home/joan/tmp/review-glyr/results INFO: Reading configuration from /etc/mock/site-defaults.cfg INFO: Reading configuration from /etc/mock/fedora-rawhide-x86_64.cfg INFO: Build completed INFO: Installing built package(s) INFO: Active plugins: Generic, C/C++, Shell-api

Package basesystem-11-11.fc34.noarch contains no files Package glibc-minimal-langpack-2.33.9000-36.fc35.x86_64 contains no files Package basesystem-11-11.fc34.noarch contains no files Package glibc-minimal-langpack-2.33.9000-36.fc35.x86_64 contains no files INFO: ExclusiveArch dependency checking disabled, enable with EXARCH flag

Review template in: /home/joan/tmp/review-glyr/review.txt fedora-review is automated tool, but YOU are responsible for manually reviewing the results and finishing the review. Do not just copy-paste the results without understanding them.

I already spent so much time to be able to create the source file. Can you please help to move things forward ?

[eclipseo]

Review template in: /home/joan/tmp/review-glyr/review.txt fedora-review is automated tool, but YOU are responsible for manually reviewing the results and finishing the review. Do not just copy-paste the results without understanding them.

Yes then you analyze the SPEC file for errors with the help of the Packaging Guidelines and fill the /home/joan/tmp/review-glyr/review.txt file by filling the checkboxes. It's not that time consuming.

[grosjo]

@eclipseo yes but I need to go through all the doc Can't you just tell me what is to be updated for this dovecot-fts-xapian and we push this in Fedora ?

[eclipseo]

@eclipseo yes but I need to go through all the doc Can't you just tell me what is to be updated for this dovecot-fts-xapian and we push this in Fedora ?

Nothing need to be updated in the dovecot-fts-xapian SPEC, you just need to be vetted to be approved in the packager group.

[grosjo]

Maybe you just tell what to fix in that glyr package (which I really don't care) , and help me to push the actual package in Fedora ?

I am doing all this on free will only and very busy otherwise.

[eclipseo]

If you don't want to do the work to show you can be approved as a packager, I can't help you. The only other solution would be for you to create a COPR https://copr.fedorainfracloud.org/ to have an unofficial package.

[grosjo]

@eclipseo How to find someone able to take care of this complexity ?

[ghost]

I think what eclipseo wants you to do, is read about RPM packaging rules, understand how RPM works and to have the responsibility to maintain your own packages. There are responsibilities being a package maintainer.

It may be a lot of work, but it is worth your effort, because Xapian will be available to thousands of people, admins, sysops, devops and if you manage to get the packages to EPEL, then millions of servers.

[grosjo]

@Bill-ColeUS : can you do it ?

[ghost]

Sorry but I can't, I am already responsible for other open source projects.

[grosjo]

@eclipseo I don't really know what to do know. SPEC file and review.txt, are linked to a "glyr" package, I don't really know what is wrong or right about this "glyr"

The interest here is the dovecot-fts-xapian RPM. How to push the RPM in Fedora ? 99% of the job is done

[grosjo]

https://bodhi.fedoraproject.org/updates/FEDORA-2021-3eb32b9b00

[ghost]

Looks like you are progressing nicely with the rpm build. All it shows is two static analysis tests for runpath. What I would be interested to know, is if this will cover all current Fedora versions (33 & 34) and EPEL.

[grosjo]

For F34, short term, I made a RPM here : https://github.com/grosjo/fts-xapian/tree/master/PACKAGES/RPM

[grosjo]

https://pagure.io/releng/fedora-scm-requests/issue/36603

[grosjo]

https://src.fedoraproject.org/rpms/dovecot-fts-xapian

[grosjo]

@Bill-ColeUS Ok for you ?

[ghost]

Excellent! thank you very much.

Please submit your work to the EPEL repository as well, so we can use this project on servers!

[grosjo]

I get the following error for EPEL7 Mock Version: 2.12 Mock Version: 2.12 Mock Version: 2.12 Mock Version: 2.12 ENTER ['do_with_status'](['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/dovecot-fts-xapian.spec'], chrootPath='/var/lib/mock/epel7-build-29868064-4073272/root'env={'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\033]0;\007"', 'PS1': ' \s-\v\$ ', 'LANG': 'C.UTF-8'}shell=Falselogger=<mockbuild.trace_decorator.getLog object at 0x7fff89a81280>timeout=201600uid=1000gid=425user='mockbuild'nspawn_args=[]unshare_net=FalseprintOutput=False) Executing command: ['bash', '--login', '-c', '/usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/dovecot-fts-xapian.spec'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/builddir', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\033]0;\007"', 'PS1': ' \s-\v\$ ', 'LANG': 'C.UTF-8'} and shell False error: line 38: Package does not exist: %post -p /sbin/ldconfig libs Building target platforms: noarch Building for target noarch Child return code was: 1 EXCEPTION: [Error()] Traceback (most recent call last): File "/usr/lib/python3.9/site-packages/mockbuild/trace_decorator.py", line 93, in trace result = func(*args, **kw) File "/usr/lib/python3.9/site-packages/mockbuild/util.py", line 600, in do_with_status raise exception.Error("Command failed: \n # %s\n%s" % (command, output), child.returncode) mockbuild.exception.Error: Command failed:

bash --login -c /usr/bin/rpmbuild -bs --target noarch --nodeps /builddir/build/SPECS/dovecot-fts-xapian.spe

[ghost]

EPEL7 is geared towards RHEL/CentOS 7.x, which is using 7-year old libraries. You may need to make some adjustments to compile there.

EPEL8 should be much easier because its more modern.

[grosjo]

@Bill-ColeUS Epel7 is really too old Epel8 seems to work

[grosjo]

https://koji.fedoraproject.org/koji/packageinfo?packageID=34417

[ghost]

Thank you for the quick update. I'm testing AlmaLinux 8, CentOS 8 and Fedora. No issues so far.

[grosjo]

SHall I close this issue ? Or any additional ?

[ghost]

Yes please, I think you may close this issue.