Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => peter.semiletov

I'm trying to figure out what for this /etc/init.d/lm_sensors...

From /etc/sysconfig/lm_sensors:

-----------
# Generated by sensors-detect on Sat Jul 29 18:36:40 2017
# This file is sourced by /etc/init.d/lm_sensors and defines the modules to
# be loaded/unloaded.
#
# The format of this file is a shell script that simply defines variables:
# HWMON_MODULES for hardware monitoring driver modules, and optionally
# BUS_MODULES for any required bus driver module (for example for I2C or SPI).

HWMON_MODULES="coretemp nct6775"
----------

So as far I understand /etc/init.d/lm_sensors is the sensors database. Why it is located at /etc/init.d/? Maybe because it's accessible at early boot stages?
Is that normal? I think I need time and help to understand all this things.

Hi Peter and Marja,

I think, there is cosmetic bug. Need audit of spec-file.
You can compare for mageia 5:

# rpm -qf /etc/init.d/lm_sensors
lm_sensors-3.3.5-3.mga5

# file /etc/init.d/lm_sensors
/etc/init.d/lm_sensors: POSIX shell script, ASCII text executable

# head /etc/init.d/lm_sensors
#!/bin/sh
#
# sensors    This shell script takes care of starting and stopping
#               sensord.
#
# description: sensors is a sensors daemon which can be used to alert you in the
#               event of a hardware health monitoring alarm.
#
# chkconfig: 2345 26 74
#

# systemctl status lm_sensors
● lm_sensors.service - Initialize hardware monitoring sensors
   Loaded: loaded (/usr/lib/systemd/system/lm_sensors.service; enabled)
   Active: active (exited) since Вт 2018-01-30 00:15:58 MSK; 8 months 2 days ago
 Main PID: 2253 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/lm_sensors.service

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

# ls -l /usr/lib/systemd/system/lm_sensors.service
-rw-r--r-- 1 root root 330 окт 17  2014 /usr/lib/systemd/system/lm_sensors.service

Best regads,
Zamir

So is it can be considered as the bug? 
I see the Mageia 1 lm_sensors package with same behaviour (/etc/init.d/lm_sensors), and all following lm_sensors packages for all Mageia too.

(In reply to Peter Semiletov from comment #5)
> So is it can be considered as the bug? 
> I see the Mageia 1 lm_sensors package with same behaviour
> (/etc/init.d/lm_sensors), and all following lm_sensors packages for all
> Mageia too.

I really don't know.

CC'ing all packagers collectively, one of them might know and have time to reply.

CC: (none) => pkg-bugs

(In reply to Peter Semiletov from comment #5)
> So is it can be considered as the bug? 
> I see the Mageia 1 lm_sensors package with same behaviour
> (/etc/init.d/lm_sensors), and all following lm_sensors packages for all
> Mageia too.

Yeah, but you screwed it up here: :)
http://svnweb.mageia.org/packages/cauldron/lm_sensors/current/SPECS/lm_sensors.spec?r1=1145035&r2=1184569

with this part:
-install -m 755 %{SOURCE2} %{buildroot}%{_initrddir}/lm_sensors
+install -m 755 %{SOURCE0} %{buildroot}%{_initrddir}/lm_sensors

and no-one noticed it (me included) until cjw cleaned it up in:
http://svnweb.mageia.org/packages/cauldron/lm_sensors/current/SPECS/lm_sensors.spec?r1=1234055&r2=1245879

So the fix by cjw should be done for mga6 too

CC: (none) => tmb

First I need to test is lm_sensors usable without /etc/init.d/lm_sensors at its "historical" location.

It is, as it provides real systemd service files

/usr/lib/systemd/system/lm_sensors.service
/usr/lib/systemd/system/sensord.service

init.d files are only needed for old sysvinit that we dont support anynore

And I suggest to update it to a newer snapshot at the same time

Thanks to all!
How to properly submit it to mga6? 
mgarepo submit 6
or 
mgarepo submit 6/lm_sensors --define section=core/updates_testing -t 6

P.S. I've never submitted outside of the Cauldron before...

No, you must checkout the package from updates/6 first:

mgarepo co -d 6 lm_sensors

do your fixes, commit them there, and submit to testing with:

mgarepo submit -t 6 --define section=core/updates_testing

And remember, always do fixes in cauldron first, then in stable release so we dont regress on distro upgrades

Thanks for advice, Thomas!

Issue has been solved at 2018

Resolution: (none) => FIXED
Status: NEW => RESOLVED