Distro packaging for SMFC

[emansom]

I'm in the process of creating an .spec file here to be used in conjunction with tito for RPM release management.

This will allow publishing to Copr for easy package testing (currently testing here), and eventual upstreaming to EPEL for wider package availability to the EL community at large.

Once the .spec file conforms to all Fedora and EL packaging rules, i'll open up a PR here to merge it in.

However, one of the hurdles I ran into with SMFC while testing on EL: is that the default kernel that ships with RHEL 9, Rocky Linux 9 and CentOS Stream 9 does not have the drivetemp kernel module built-in. This can be worked around with hddtemp to success, but it should not be broken on package installation.

Further the requirement to modify the hd_names variable first before it's functional is tedious and further complicates a functional state from the get go.

It would help the out-of-the-box experience for EL users to have SMFC automatically discover HDDs when e.g. hd_names is set to auto and to have SMFC fall-back/default to hddtemp for temperature.

[petersulyok]

Hi @emansom, sounds great. What is the kernel version you work with at RHEL?

[emansom]

Hi @emansom, sounds great. What is the kernel version you work with at RHEL?

Currently don't have access to any RHEL 9 boxes to verify, however: Rocky Linux 9 ships with kernel version 5.14.0-362.24.1.el9_3.0.1.x86_64 as of now.

Given Rocky Linux 9 and RHEL 9 are using the same SRPMs and remain bug-for-bug compatible, I presume it's the same kernel build config and version on RHEL 9.

For a detection algorithm I think simply checking if the paths to the drive hwmon files exists would suffice, this would handle all cases where: 1) drivetemp kernel module is not loaded 2) drivetemp kernel module is not available 3) drivetemp kernel module is built-in and doesn't show up in e.g. lsmod but is functional 4) drivetemp kernel module is available and loaded

[emansom]

Fedora package review requested:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2274274

[emansom]

Related PR #35 opened

[petersulyok]

Hi @emansom,

The effort you put into this is really impressive, thanks for that. I have several questions and comments:

1. Recently, I've implemented the checking of run-time dependencies and which is contradicting this feature request (e.g. if drivertemp is not loaded then smfc will be stopped)
2. In my mind this feature could be turned on and off with a command-line parameter (e.g. -A)
3. file src/smfc.preset: could it be in .tito folder?

4. In the future I would like to collect all packaging related artifacts in a folder but not sure if it is feasible.

   smfc
     >src
     >packaging
         >deb
         >rpm       
         >.tito
         >arch
     >test

Would it be possible with tito?

Currently there is an issue with codecov plugin in GitHub workflow (it uploads the coverage result to codecov.io), this is the reason why the merge failed. I try to come up with an implementation soon. Cheers,

Peter

[petersulyok]

One additional comment that .tito/packages/smfc file contains a version number. It is getting harder and harder to track all of the instances of the version numbers. Would it be possible to generate this or make it automated somehow?

I'm also thinking on a central version number and central updater solution.

[emansom]

2. In my mind this feature could be turned on and off with a command-line parameter (e.g. -A)

And that command-line parameter can then be passed via /etc/default/smfc. Yes, workable solution 🙂

3. file src/smfc.preset: could it be in .tito folder?

.tito is managed by the tool itself, best not to touch it unless required. I've moved the systemd preset and unit files to their own directory in #36.

4. In the future I would like to collect all packaging related artifacts in a folder but not sure if it is feasible.

smfc
    >src
    >packaging
        >deb
        >rpm       
        >.tito
        >arch
    >test

Would it be possible with tito?

Probably not. I will dig thru the documentation to see if paths can be changed.

[emansom]

Opened #36 to address feedback from Fedora packager.

[emansom]

One additional comment that .tito/packages/smfc file contains a version number. It is getting harder and harder to track all of the instances of the version numbers. Would it be possible to generate this or make it automated somehow?

Fedora packager @NeilHanlon mentioned rpmautospec which may be able to automate this.

I'm also thinking on a central version number and central updater solution.

Setting up an Open Build Service instance could be a solution, combined with a CI/CD tool that integrates with multiple distro/OS-specific packaging definition files would ease this.

I currently lack sufficient resources for this, so only AUR, PPA and Copr (Fedora repo and EPEL in the future) would be feasible from my end for the time being.

[emansom]

A way to generate man pages automatically is also needed per the guidelines, as smfc is a binary.

Update: found this project: argparse-manpage.

It fits the need, but does requires some code modification: namely a static get_parser() method added that returns smfc's argparse.ArgumentParser instance.

[NeilHanlon]

Heya folks! Happy to help on this. I think it would be really helpful for the Fedora Server Working group, and of course for RHEL systems as well.

Have you looked into using packit, perhaps? This can take care of a lot of the "dirty" work in Fedora packaging--including and especially things like version bumps, etc

[NeilHanlon]

A way to generate man pages automatically is also needed per the guidelines, as smfc is a binary.

fwiw, this is not a strict requirement for the manpages to be automatically generated; though of course having them be as up-to-date as possible would be beneficial (and is why the policy says maintainers should work with upstream and use those manpages where available)

[petersulyok]

Hi @NeilHanlon, welcome. I do not have any preference on packaging or tools. My purpose here is to keep the changes on a reasonable and safe level.

[petersulyok]

Hi @emansom, I see you tried to convert smfc to a Python package, but I do not see the reason / benefit. Please explain your motivation. Till now I tried to keep smfc as simple as possible, since it does not have any Python dependency. If smfc was a Python package:

• it would be uploaded to pypi.org
• it would be installed using pip (note: pip installation to OS level is not recommended nowadays, less and less distros are supporting this)

I have done this in another repo: https://github.com/petersulyok/diskinfo

[emansom]

Hi @emansom, I see you tried to convert smfc to a Python package, but I do not see the reason / benefit. Please explain your motivation.

This was done for the tests to run successfully in the RPM package chroot. Fedora's Python RPM package macros make some assumptions about the Python environment and requires it to be exposed as a package by pyproject for the smfc namespace/package to be available when the tests are invoked.

Till now I tried to keep smfc as simple as possible, since it does not have any Python dependency.

It does not add any extra runtime dependencies, only during the RPM package building and package testing phases are the extra tooling (setuptools, pyproject, pytest) required.

If smfc was a Python package:

• it would be uploaded to pypi.org

Good catch. I read over this part in the guidelines. Yes, this is required to mitigate security concerns: where a novice user might be tricked into sudo pip install smfc. If the smfc package there isn't controlled by the same author, they might install malware accidentally.

This will require some modification to the RPM definition file (smfc.spec) to fetch from PyPi instead, as well as some extra tooling (GitHub action) to be added to publish to PyPi on new release.

• it would be installed using pip (note: pip installation to OS level is not recommended nowadays, less and less distros are supporting this)

This is the job of Fedora's Python RPM package build macros (and deb equivalent in the future), it invokes setuptools (via pyproject) to install it to OS level at site-packages within a chroot environment which then gets "zipped up" to a final RPM file.

This RPM file can then be distributed across distro repositories, making it end user installable via dnf install smfc.

[petersulyok]

I've got an idea how could we divide the tasks and step further in RPM packaging. Since the Python packaging is fundamental and it effects everything (including installation and unit testing etc.), I would do that. You may create a docker file (with one or more a selected distros, required packages for build creation etc.) for the RPM package creation. In this way anybody would be able to check if RPM packaging is working properly.

[petersulyok]

Hi @emansom and @NeilHanlon,

I just finished the smfc python packaging and I'm ready to upload it to pypi. I would like to hear your opinion on how tito can:

• install a pypi package at installation time in side a rpm package
• resolve the pypi package dependencies here