Version 3.0.3 was released on September 28, 2008. Please add an ebuild for it. AFAIK, renaming the ebuild works. Reproducible: Always
Created attachment 169991 [details, diff] Version bump of the gentoo specific patch Actually, this patch is needed.
*** Bug 244657 has been marked as a duplicate of this bug. ***
Confirming an ebuild rename and a re-diffed patch is all that is needed.
sys-apps/lm_sensors 3.1.0 has been released: http://lists.lm-sensors.org/pipermail/lm-sensors/2009-March/025457.html
Created attachment 184142 [details] New ebuild for lm_sensors-3.1.0
Created attachment 184143 [details, diff] Updated gentoo patch for lm_sensors-3.1.0 The patch needed a few changes to be applied to lm_sensors-3.1.0
Just curious - is it correct that this is assigned to the moble herd? Thanks.
(In reply to comment #7) > Just curious - is it correct that this is assigned to the moble herd? Thanks. > I haven't got a clue as to why this was assigned to the mobile herd. That can't be right, surely? As for the subject, lm_sensors 3 is in portage, but hardmasked: /usr/portage/profiles/package.mask: # Donnie Berkholz <dberkholz@gentoo.org> (17 Mar 2008) # Most apps that use lm_sensors aren't compatible with the new version I think it is time this was unmasked, or at least make a new attempt to figure out which apps do and do not support it. Ksensors seems to support it, for example.
Last I checked (fairly recently) net-analyzer/net-snmp still didn't support it (with USE=lm_sensors) and I couldn't find a patch for it. Other than that everything I use supports it now.
(In reply to comment #9) > Last I checked (fairly recently) net-analyzer/net-snmp still didn't support it > (with USE=lm_sensors) and I couldn't find a patch for it. Other than that > everything I use supports it now. > Is this still the case as I cannot find a bug for it on this bugzilla? We should really work towards unmasking >=3.0 as sensors that only is supported with 3.0 or newer has started to emerge (for example those on my motherboard).
(In reply to comment #8) > (In reply to comment #7) > > Just curious - is it correct that this is assigned to the moble herd? Thanks. > > > > I haven't got a clue as to why this was assigned to the mobile herd. That can't > be right, surely? > $ grep herd /var/portage/sys-apps/lm_sensors/metadata.xml <herd>mobile</herd> If they still and really want to maintain this is another question...
(In reply to comment #9) > Last I checked (fairly recently) net-analyzer/net-snmp still didn't support it > (with USE=lm_sensors) and I couldn't find a patch for it. Other than that > everything I use supports it now. > i found a patch linked to on the lm_sensors' download page (http://cvs.fedoraproject.org/viewvc/devel/net-snmp/net-snmp-5.4.1-sensors3.patch). i've edited the net-snmp-5.4.2.1 ebuild (attached) and net-snmp compiled properly with USE="lm_sensors"
Created attachment 193443 [details] net-snmp ebuild with lm_sensors-3.X support
Comment on attachment 193443 [details] net-snmp ebuild with lm_sensors-3.X support this probably isn't the correct place for this ebuild, but it's the only relevant conversation found in bugzilla
Created attachment 193444 [details] net-snmp patch for lm_sensors-3.X support attaching the patch for completeness
i've also tested using cacti to graph my lm_sensor data via snmp and all works nicely: https://genuxtsg.com/cacti/graph.php?action=view&local_graph_id=316&rra_id=all
Jeremy, thank you for the URL and I appreciate your enthusiasm. For future reference, it is not really appropriate discuss problems with a different package than the one this bug is for. The right thing to do would be to open a separate bug for all the comments/content and then add a comment here since it is relevant with regards to lm_sensors-3 still being package.masked. I've opened bug #279423 for adding lm_sensors-3 support to net-analyzer/net-snmp. This bug can remain open for a future =sys-apps/lm_sensors-3.1.1 version bump.
The 3.1.1 version has been relesed. It has support for the asus atk0110 device. Please add it to the Portage.
When will lm_sensors-3.1.1 be added to portage? With kernel version 2.6.31 the asus_atk0110 acpi based hwmon driver is in the kernel and the default behavior for acpi is to grab the resources for this chip, if a board supporting atk0110 is detected. The result is that old configurations where the monitoring chip (e.g. with my P5Q Pro board, a w83627ehf based chip) is addressed directly via the appropriate chip driver won't work any longer. The chip driver can not be loaded, because acpi claimed the resources. The correct solution is obviously to use the asus_atk0110 driver to read the sensor values. Unfortunately <lm_sensors-3.1.1 is not capable of reading the values from the asus_atk0110 driver. Please soon add lm_sensors-3.1.1 to portage!
Created attachment 204452 [details] lm_sensors 3.1.1 ebuild and patches for overlay
Created attachment 204454 [details] net-snmp with patches from other bug for overlay
I just would like to say that although it would seem that most things worked when I emerged these two packages with the lm sensors 3 upgrade, the package I needed most ksensors segfaulted so I reverted to the lm sensors 2 but the problem does not lie specifically with the lm sensor upgrade, any new emerge of ksensors segfaults regardless of which lm sensors is installed.
Okay, I re-emerged most of the dependencies of ksensors and ALSO !!! eselected and set the symlinks for my installed postgresql. I now have re-emerged the included ebuilds for net-snmp and lm_sensors 3.1.1 and it works perfectly!!! For those who are in need of the asus_atk0110 acpi virtual kernel driver to replace the broken it87 hwmon driver, this worked perfectly on my asus a8n32-sli deluxe board. Good luck.
I now have this completely operational on 2 different machines. All compiles and functions perfectly.
Created attachment 204559 [details] lm_sensors-3.1.1.ebuild The ebuild itself.
Created attachment 204561 [details] updated patch
3.1.1. works for me, including fan speed monitoring. Asus P5B motherboard using atk0110 device driver (rather than w83627ehf). 2.6.31 kernel. gkrellm 2.3.2-r1.
3.1.1 works for me with the attached ebuild/patch on an Asus P6T Deluxe V2. To use the asus_atk0110 driver, it must be manually specified as sensors-detect has no atk0110 auto-detect support yet. A lm_sensors feature request is open for this.
Time to bump I guess; to git-sources-2.6.31-r13, 'lm_sensors-3.1.1' is already old stuff as it introduces CONFIG_I2C_COMPAT especially for it. I'll jump on the 3.1.1 experimental bandwagon. :)
Is there someone higher up in the Gentoo hierarchy that we can prod to take a look at this in general? It seems that lm_sensors is an important package that is being left unattended. Maybe Donnie Berkholz? lm_sensors seems to slip through the net in terms of which herd it would be suitable for.
Hey Billy, why don't you submit your 3.1.1 ebuild to the Sunrise overlay? That will increase its exposure and, I hope, increase its chances of appearing in the official tree.
(In reply to comment #31) > Hey Billy, why don't you submit your 3.1.1 ebuild to the Sunrise overlay? That > will increase its exposure and, I hope, increase its chances of appearing in > the official tree. > No updates for in tree ebuilds in sunrise. Sorry guys. Ask the maintainer for the bump.
Removed >=sys-apps/lm_sensors-3 from package.mask. See #279423.
The ebuild for lm_sensors-3.1.1 in this bug works well, any chance to see it in portage proper?
Hi Jeremy, Feel free to submit my work to the sunrise overlay. I'm not a developer nor have I ever submitted anything to the overlays but this particular package was a SERIOUS problem as this was requiring special booting parameters with the newer kernels in order to be compatible due to the necessity of the asus atk0110 driver so I had to do something until the developers got around to it.
(In reply to comment #35) > Hi Jeremy, Feel free to submit my work to the sunrise overlay. I'm not a > developer nor have I ever submitted anything to the overlays but this > particular package was a SERIOUS problem as this was requiring special booting > parameters with the newer kernels in order to be compatible due to the > necessity of the asus atk0110 driver so I had to do something until the > developers got around to it. > I just can repeat me. Sunrise will not accept it. The only chance is to keep it in your local overlay and use it there. I am maintaining the ebuild in my personal overlay [1] which can also be made accessible through layman. [1] http://www.j-schmitz.net/gentoo-portage-overlay
Hi, please bump lm_sensors version in the portage to the 3.1.1. Older version are obsolete. I don't see any logical reason to hold 3.1.1 outside of the portage.
Created attachment 207473 [details] updated ebuild that does not require kernel sources This is the existing ebuild for 3.1.1 updated with the relaxed check for kernel sources, as done for the 3.0.x series in portage.
3.1.1 is now in the tree. please test and open new bug reports for all the issues you find. thanks. sorry for the long wait. also - move your votes.
Thank you!
