CentOS 9 packages

[volga629-1]

Hello Everyone,
Is possible release packages for centos stream 9 ?

Error: 
 Problem: conflicting requests
  - nothing provides python3-amqp needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-celery needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-lockfile needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-mimeparse needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-redis needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-tabulate needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-treq needed by jasmin-sms-gateway-0.10.11-1.x86_64
  - nothing provides python3-twisted needed by jasmin-sms-gateway-0.10.11-1.x86_64

[root@msg00 yum.repos.d]# dnf repolist 
repo id                                                                     repo name
appstream                                                                   CentOS Stream 9 - AppStream
baseos                                                                      CentOS Stream 9 - BaseOS
crb                                                                         CentOS Stream 9 - CRB
epel                                                                        Extra Packages for Enterprise Linux 9 - x86_64
epel-next                                                                   Extra Packages for Enterprise Linux 9 - Next - x86_64
extras-common                                                               CentOS Stream 9 - Extras packages
jookies_jasmin-sms-gateway                                                  jookies_jasmin-sms-gateway
jookies_jasmin-sms-gateway-source                                           jookies_jasmin-sms-gateway-source

[Kisuke-CZE]

Hi,

I tried to repackage jasmin for RHEL9 and clones. I think it works. Here is a repository in COPR: https://copr.fedorainfracloud.org/coprs/kisuke-cze/Jasmin-SMS-Gateway/

Packages are generated for both - EL8 & EL9. Some patches which are pending in pull requests are already applied here.
BUT I did probably many things wrong (for example I removed requirements for specific versions of some libraries, to be able to build for EL8 end EL9 from same SPEC file).

In theory, you just need to install prerequisites - redis and rabbitmq. And then issue:

dnf copr enable kisuke-cze/Jasmin-SMS-Gateway 
dnf install jasmin-sms-gateway

But I have not the opportunity to test it if jasmin is stable in real-world usage against real SMSC.
It installs on both - EL8 and EL9, it runs, it is logging, you can configure it via CLI, you can write config to disk, and it will read it from disk on next reboot. Anything else is not tested. If anyone is willing to try it in wild, please give some feedback.

SRPM files are available here: https://github.com/Kisuke-CZE/jasmin-RPMs
In those files is included whole procedure of building each package (most of them are just existing SPEC files from https://src.fedoraproject.org/, because they were in EPEL8). I do not believe I can do regular maintanance of these packages. So if anyone is willing to take that role, it will be welcomed.

[farirat]

Hey @Kisuke-CZE

Thank you for packaging to rhel9 !

Let's collaborate to make your work mainstream under jasmin's master branch, as you may know, jasmin packaging is done through nfpm (c.f. nfpm.yml file), can you make a pr with an adjustment on that file to allow builds on rhel9 ?

I'm available to help/assist.

[Kisuke-CZE]

Hi,

I've looked at the nfpm.yaml you mentioned. But it's "only" for jasmin-sms-gateway istelf. Which is not the problem. Your package will work (and do work in RHEL9)
For RHEL9 the main problem is sourcing various python libraries (of course you can install them manuallly using pip, but dependecies do not work outside RPM system - and also if you do this, whole RPM/DEB packaking just loses the point). If you will include library packages in your repository, it will just work with current package.
Only thing I would suggest is adding back that dependecy python3-falcon for both - EL8 and EL9 - package is available in EPEL: https://src.fedoraproject.org/rpms/python-falcon

I would like to push this somehow into upstream. But I do not think my "style" of packaging is compatible with yours. And if it works for most people, who am I to change it to something else.
As you probably know, whole point of those COPR packages is just building from SPEC files automatically - building process just downloads specific sources from pypi.org and builds static package from it (this applies for both - jasmin and python libraries). Basicaly updating package should mean just increase version in SPEC file - and if I am lucky, here comes new package (based on that what is published on pypi.org).
I completely ditched common-postinstall.sh, which does install jasmin and some other things over pip - which is non-RPM way and can cause issues (for me it now does not work on AlmaLinux 8 unless i upgrade pip itself outside of RPM - using pip3 install --upgrade pip). Everything is included inside RPM. Which is nice - but as you know it will not work for DEB packages (Which doubles packaging work. Probably, have not tried).

I also did some cosmetic - like removed administrator credentials from jasmind.service unit file and placing then into /etc/jasmin/jasmind.environment (root readable only). But that is not important at all. (Well I wish jasmin could load config from disk without knowing my credentials, but it is what it is... :-)

[Kisuke-CZE]

@farirat
I thinked about it and I have a proposal how to make packaging less time-consuming.
Just stop making RPM and DEB packages with python dependecies. jasmin-sms-gateway should be just "meta" package to ship systemd units and postscript which will create separate VIRTUALENV with compatible python version and all packages needed. It will be separated from the system and should work on any distribution.

See this commit. It works for RHEL. Not tested in Debian yet, but will do it as soon as I can.
If you are interested, I will create PR (after debian testing and maybe some tweaks for DEB packages). But I do not want to break your workflow.