Comments (16)
Hi @emansom, sounds great. What is the kernel version you work with at RHEL?
from smfc.
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:
- drivetemp kernel module is not loaded
- drivetemp kernel module is not available
- drivetemp kernel module is built-in and doesn't show up in e.g.
lsmod
but is functional - drivetemp kernel module is available and loaded
from smfc.
Fedora package review requested:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2274274
from smfc.
Related PR #35 opened
from smfc.
Hi @emansom,
The effort you put into this is really impressive, thanks for that.
I have several questions and comments:
- Recently, I've implemented the checking of run-time dependencies and which is contradicting this feature request (e.g. if
drivertemp
is not loaded thensmfc
will be stopped) - In my mind this feature could be turned on and off with a command-line parameter (e.g. -A)
- file
src/smfc.preset
: could it be in.tito
folder? - 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
from smfc.
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.
from smfc.
- 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 🙂
- 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.
- 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.
from smfc.
Opened #36 to address feedback from Fedora packager.
from smfc.
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.
from smfc.
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.
from smfc.
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
from smfc.
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)
from smfc.
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.
from smfc.
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
from smfc.
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
.
from smfc.
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.
from smfc.
Related Issues (20)
- Feature Request: interactive setup CLI HOT 1
- Error starting daemon HOT 12
- Supermicro boards incompatible with ULNA HOT 2
- Feature Request: GPU temperature/activity bias HOT 4
- Version 2.4.0 breaks HD zone loading? HOT 5
- SMFC hardware compatibility HOT 28
- Super Micro X10DRU-i+ zones HOT 6
- Cannot read hwmon*/temp1_input file HOT 27
- [Feature request] Add support to Supermicro M12SWA-TF HOT 8
- Number of HDDs parameter HOT 1
- AMD CPU support HOT 3
- X12 Support? HOT 3
- Request support for remote IPMI HOT 8
- Add note for higher RPM variance tolerance for redux line fans HOT 1
- Feature Request: dracut integration HOT 1
- Feature Request: autoconfiguration of IPMI fan upper and lower bounds HOT 1
- X10DRG HOT 6
- Set all fans to maximum speed on exception HOT 6
- X13SAE-F compatibility HOT 12
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from smfc.