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 attachment 142219 [details, diff] 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 attachment 142231 [details, diff] Updated patch for lm_sensors-3.0.1 I'm not 100% on this one but for now it seems to be working :)
Created attachment 142232 [details] New ebuild for lm_sensors-3.0.1 Use at your own risk :)
Created attachment 142234 [details] Updated sensord3-init.d for new config files New sensord-init.d For use with lm_sensors-3
Created attachment 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 attachment 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
