Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

October 24th, 2007: 2.10.5 Released!  This release adds user-space support for
the SMSC SCH3112, SCH3114 and SCH3116, and sensord support for the Winbond
W83793G and National Semiconductor LM87. It also includes a myriad of minor bug
fixes. See the CHANGES document for details and further changes.

P.S. I waited 10 days, if you knew about this update, sorry...

Reproducible: Always

Any news about this? Thanks.

Version 3 is now out.

November 24th, 2007: 3.0.0 Released!  After over 7 months of work and 3 release
candidates, we are proud to announce that lm-sensors 3.0.0, the
next-generation, chip-independent hardware monitoring tools package for Linux
2.6.5 and later, is finally available for download. Be sure to read the release
announcement for the details.

Release Annoucenement:
http://lists.lm-sensors.org/pipermail/lm-sensors/2007-November/021983.html

Just a humble bump if someone is still assigned to the mobile team...

Hi,

I've just added the x86@gentoo.org to this bug.

Seems like all bugs sent to mobile@gentoo.org in the last 2-3 months were left
unanswered. Is there anybody out there?

If x86 is not the proper team to solve this please redirect, but if redirecting
back to mobile@gentoo.org please make sure that this list has at least one
working member assigned to it.

Thanks,
Dan.

Yes, x86 isn't proper alias. In mobile there are at least 6 active developers,
though they can be bit bussy. Just be patient ;)

Version 3.0.0 has been released quiet some time ago. Ping?

Version 3.0.1 was released Monday the 28th.

I would like to test the new version as my computer's sensors aren't supported
by the old one.

Are there any overlays or sample ebuilds anyone knows about, I wouldn't mind
being a guinea pig :)

Created an attachment (id=142219) [details]
Updated patch for lm_sensors-2.10.5

Gentoo patch updated for 2.10.5, hope i did this right :)
lm_sensors-2.10.5-sensors-detect-gentoo.patch

Created an attachment (id=142231) [details]
Updated patch for lm_sensors-3.0.1

I'm not 100% on this one but for now it seems to be working :)

Created an attachment (id=142232) [details]
New ebuild for lm_sensors-3.0.1

Use at your own risk :)

Created an attachment (id=142234) [details]
Updated sensord3-init.d for new config files

New sensord-init.d For use with lm_sensors-3

Created an attachment (id=142236) [details]
Updated lm_sensors3-init.d for new config files

Update lm_sensors-init.d For use with lm_sensors-3

Ok I have it working on my setup at home, ran sensors-detect and it seems to
still work. If anyone else gives it a try let me know if you see any problmes
:)

Thanks Sonny for the work you're doing with lm_sensors.

I've been looking at this bug for a while :)
Figured I could stumble on my way threw my first hackish ebuild and patch set
:)


PS: I really don't think I know what I am doing.

Thanks for your ebuild. A few comments:

>	if kernel_is lt 2 6 14 && ! (linux_chkconfig_present I2C_SENSOR); then
>		eerror
>		eerror "${P} requires CONFIG_I2C_SENSOR to be enabled."
>		eerror
>		die "CONFIG_I2C_SENSOR not detected"

It is a good idea to provide the location where to find this config option in
menuconfig, which I think most people use. See this example:

        if linux_chkconfig_present PARAVIRT; then
                eerror "The current ati-drivers don't compile when having"
                eerror "paravirtualization active due to GPL symbol export"
                eerror "restrictions."
                eerror "Please disable it:"
                eerror "        CONFIG_PARAVIRT=n"
                eerror "in /usr/src/linux/.config or"
                eerror "        Processor type and features -->"
                eerror "                [ ] Paravirtualization support
(EXPERIMENTAL)"
                eerror "in 'menuconfig'"
                die "CONFIG_PARAVIRT enabled"
        fi

>	dodoc BACKGROUND BUGS CHANGES CONTRIBUTORS INSTALL QUICKSTART \
>		README* TODO
dodoc CHANGES CONTRIBUTORS INSTALL README TODO

>	dodoc doc/donations doc/fancontrol.txt doc/fan-divisors doc/FAQ \
>		doc/progs doc/temperature-sensors doc/vid
dodoc doc/{donations,fan*,FAQ,progs,temperatur-sensors,vid}

>	dohtml doc/lm_sensors-FAQ.html doc/useful_addresses.html
dohtml doc/lm_sensors-FAQ.html

>	docinto busses
>	dodoc doc/busses/*
Doesn't exist

>	docinto developers
>	dodoc doc/developers/applications doc/developers/design \
>		doc/developers/new_drivers doc/developers/proc \
>		doc/developers/sysctl doc/developers/sysfs-interface
dodoc doc/developers/{applications,lm_sensors.lsm,makefiles,release_checklist}
or
dodoc doc/developers/*

>pkg_postinst() {
>	einfo
>	einfo "Please run \`/usr/sbin/sensors-detect' in order to setup"
>	einfo "/etc/conf.d/lm_sensors."
>	einfo
--snip--
>	einfo "(http://www.lm-sensors.org/wiki/Documentation)"
>	einfo
>}
Use elog instead of einfo for these.


Finally, there are errors:
Makefile:170: lib/data.ld: No such file or directory
Makefile:170: lib/general.ld: No such file or directory
Makefile:170: lib/error.ld: No such file or directory
Makefile:170: lib/access.ld: No such file or directory
Makefile:170: lib/init.ld: No such file or directory
Makefile:170: lib/sysfs.ld: No such file or directory
Makefile:170: lib/data.ad: No such file or directory
Makefile:170: lib/general.ad: No such file or directory
Makefile:170: lib/error.ad: No such file or directory
Makefile:170: lib/access.ad: No such file or directory
Makefile:170: lib/init.ad: No such file or directory
Makefile:170: lib/sysfs.ad: No such file or directory
Makefile:170: prog/sensors/main.rd: No such file or directory
Makefile:170: prog/sensors/chips.rd: No such file or directory
Makefile:170: prog/sensord/args.rd: No such file or directory
Makefile:170: prog/sensord/chips.rd: No such file or directory
Makefile:170: prog/sensord/lib.rd: No such file or directory
Makefile:170: prog/sensord/rrd.rd: No such file or directory
Makefile:170: prog/sensord/sense.rd: No such file or directory
Makefile:170: prog/sensord/sensord.rd: No such file or directory
Makefile:170: prog/dump/util.rd: No such file or directory
Makefile:170: prog/dump/isadump.rd: No such file or directory
Makefile:170: prog/dump/isaset.rd: No such file or directory
Makefile:170: prog/dump/superio.rd: No such file or directory

Sorry, but in my opinion there is a lot of work to do till this might get into
portage. ;-)

>	if kernel_is lt 2 6 14 && ! (linux_chkconfig_present I2C_SENSOR); then
>		eerror

Checking for that is unneeded. There are no 2.6 kernels older than 2.6.16 in
portage and as stated in the README, lm_sensors won't work with kernels older
than 2.6.5.

Created an attachment (id=143563) [details]
Cleaned up lm_sensors-3.0.1.ebuild

In addition to the things stated above I removed the filter-flag.
I tested with that flag and it worked without problems here.

*** Bug 212556 has been marked as a duplicate of this bug. ***

AFAIK, the warning about IBM Thinkpads is not applicable to 3.x; it can be
removed.

ksysguard-3.5.9's apparently only update from 3.5.8 is a patch for lm_sensors
3.x compatibility.  Unfortunately, it seems to disable 2.x compatibility, at
least for some people ( bug #211308 ).

So... current ~arch tree lm_sensors is behind and doesn't work with current
~arch tree ksysguard... and Gentoo KDE devs closed the ksysguard bug WORKSFORME
while the lm_sensors bump bug, proposed ebuild included, just sits... for
months...

Anyway, I'm going to try this ebuild and see if I get a working ksysguard-3.5.9
with lm_sensors-3.0.1.

BTW, the lm_sensors 3.0 release announcement says they split off i2c-tools into
a separate package.  i2c-tools exists in portage /as/ that separate package,
with the expected CONFIG_PROTECT errors on attempted merge against
lm_sensors-2.10.4.  I don't see any mention of that in the ebuild.  Perhaps an
i2c USE flag based dependency on it would be useful?  Or perhaps they are
separate enough that it's not.  I don't know, but it's a suggestion.  If
there's no dependency, perhaps an elog telling folks about i2c-tools may be
appropriate.

(In reply to comment #23)
> BTW, the lm_sensors 3.0 release announcement says they split off i2c-tools into
> a separate package.  i2c-tools exists in portage /as/ that separate package,
> with the expected CONFIG_PROTECT errors on attempted merge against
> lm_sensors-2.10.4.  I don't see any mention of that in the ebuild.  Perhaps an
> i2c USE flag based dependency on it would be useful?  Or perhaps they are
> separate enough that it's not.  I don't know, but it's a suggestion.  If
> there's no dependency, perhaps an elog telling folks about i2c-tools may be
> appropriate.
> 
You can't see anything in the ebuild, because the standard terms emake etc. are
used, so a change in the package gets adopted automatically.
There is no i2c stuff in the package anymore, because it never really belonged
there.
I don't think, that most people need the i2c tools, and those, that do, will
very likely already know about i2c-tools
So I don't think, that a (optional) dependency is needed as well as an elog
entry.

(In reply to comment #24)
> (In reply to comment #23)
>> BTW, the lm_sensors 3.0 release announcement says they
>> split off i2c-tools into a separate package.
>
> There is no i2c stuff in the package anymore, because it
> never really belonged there.

Thanks.

BTW, seems there's more to the ksysguard compatibility issue than mentioned
above.  I tried the new (supposedly compatible with lm_sensors 3.x) 3.5.9
ebuild with the lm_sensors-3.0.1.ebuild from here.  It didn't work.

So I'm reverting to lm_sensors-2.10.4 again, and will have to go the overlay
route with the older ksysguard to resolve an upgrade/downgrade dependency
issue, instead.  (I know the old one works remerged from binpkg with --nodeps,
but that's of course just a temporary measure as it doesn't resolve the
dependency conflict.)

btw 2.10.6 is now the latest for the 2X branch

Version 3.0.2 is out now. with numerous fixes.

2.10.7 is out.

Kernel 2.6.26:
The generic thermal sysfs driver's hardware monitoring support requires a
2.10.7/3.0.2 or later lm-sensors userspace.

*** Bug 232308 has been marked as a duplicate of this bug. ***

I've added 2.10.7 and 3.0.2 was already in the tree.

Thank you