xfce4-sensors has hddtemp support. By default, SUID bit on /usr/sbin/hddtemp is off: neptune / # ls -l /usr/sbin/hddtemp -rwxr-xr-x 1 root root 35896 Jun 3 19:23 /usr/sbin/hddtemp and xfce4-sensors notifies that it cannot run hddtemp - (and one can chmod u+s hddtemp to solve it) and continues to work normally. But if SUID bit is on, xfce4-sensors crashes on launch (see below at "additional information"): neptune / # chmod u+s /usr/sbin/hddtemp && ls -l /usr/sbin/hddtemp -rwsr-xr-x 1 root root 35896 Jun 3 19:23 /usr/sbin/hddtemp hddtemp works normally itself: neptune / # hddtemp /dev/sd[a.b] /dev/sda: WDC WD2500KS-00MJB0: 54 C /dev/sdb: ST3750640AS: 52 C Reproducible: Always Steps to Reproduce: 1. USE="acpi hddtemp lm_sensors" emerge xfce4-sensors 2. chmod u+s /usr/sbin/hddtemp 3. run xfce4-sensors - it will crash Actual Results: xfce4-sensors crashes Expected Results: It should work normally =/ vmbrius@neptune ~ $ xfce4-sensors *** glibc detected *** xfce4-sensors: free(): invalid pointer: 0x0000000001b23840 *** ======= Backtrace: ========= /lib/libc.so.6[0x7fabb71a6258] /lib/libc.so.6(cfree+0x6c)[0x7fabb71aad0c] /usr/lib64/xfce4/modules/libxfce4sensors.so.1(get_hddtemp_value+0x125)[0x7fabbbe112e5] /usr/lib64/xfce4/modules/libxfce4sensors.so.1(sensor_get_value+0x4c)[0x7fabbbe0e91c] /usr/lib64/xfce4/modules/libxfce4sensors.so.1(fill_gtkTreeStore+0xc8)[0x7fabbbe105f8] /usr/lib64/xfce4/modules/libxfce4sensors.so.1(init_widgets+0xc4)[0x7fabbbe10804] xfce4-sensors[0x401b4f] xfce4-sensors[0x401a7e] /lib/libc.so.6(__libc_start_main+0xe6)[0x7fabb7150a26] xfce4-sensors[0x401809] ======= Memory map: ======== 00400000-00403000 r-xp 00000000 08:13 538348176 /usr/bin/xfce4-sensors 00602000-00603000 r--p 00002000 08:13 538348176 /usr/bin/xfce4-sensors 00603000-00604000 rw-p 00003000 08:13 538348176 /usr/bin/xfce4-sensors 01a40000-01b70000 rw-p 01a40000 00:00 0 [heap] 7fabb0000000-7fabb0021000 rw-p 7fabb0000000 00:00 0 7fabb0021000-7fabb4000000 ---p 7fabb0021000 00:00 0 7fabb4fa5000-7fabb4fbb000 r-xp 00000000 08:13 805310847 /lib64/libgcc_s.so.1 7fabb4fbb000-7fabb51ba000 ---p 00016000 08:13 805310847 /lib64/libgcc_s.so.1 7fabb51ba000-7fabb51bb000 r--p 00015000 08:13 805310847 /lib64/libgcc_s.so.1 7fabb51bb000-7fabb51bc000 rw-p 00016000 08:13 805310847 /lib64/libgcc_s.so.1 7fabb51bc000-7fabb51be000 r-xp 00000000 08:13 537863124 /usr/lib64/pango/1.6.0/modules/pango-basic-fc.so 7fabb51be000-7fabb53bd000 ---p 00002000 08:13 537863124 /usr/lib64/pango/1.6.0/modules/pango-basic-fc.so 7fabb53bd000-7fabb53be000 r--p 00001000 08:13 537863124 /usr/lib64/pango/1.6.0/modules/pango-basic-fc.so 7fabb53be000-7fabb53bf000 rw-p 00002000 08:13 537863124 /usr/lib64/pango/1.6.0/modules/pango-basic-fc.so 7fabb53bf000-7fabb53c8000 r-xp 00000000 08:13 807256018 /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so 7fabb53c8000-7fabb55c8000 ---p 00009000 08:13 807256018 /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so 7fabb55c8000-7fabb55c9000 r--p 00009000 08:13 807256018 /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so 7fabb55c9000-7fabb55ca000 rw-p 0000a000 08:13 807256018 /usr/lib64/gtk-2.0/2.10.0/engines/libxfce.so 7fabb55ca000-7fabb55d5000 r-xp 00000000 08:13 537596897 /lib64/libnss_files-2.10.1.so 7fabb55d5000-7fabb57d5000 ---p 0000b000 08:13 537596897 /lib64/libnss_files-2.10.1.so 7fabb57d5000-7fabb57d6000 r--p 0000b000 08:13 537596897 /lib64/libnss_files-2.10.1.so 7fabb57d6000-7fabb57d7000 rw-p 0000c000 08:13 537596897 /lib64/libnss_files-2.10.1.so 7fabb57d7000-7fabb57e1000 r-xp 00000000 08:13 537596905 /lib64/libnss_nis-2.10.1.so 7fabb57e1000-7fabb59e0000 ---p 0000a000 08:13 537596905 /lib64/libnss_nis-2.10.1.so 7fabb59e0000-7fabb59e1000 r--p 00009000 08:13 537596905 /lib64/libnss_nis-2.10.1.so 7fabb59e1000-7fabb59e2000 rw-p 0000a000 08:13 537596905 /lib64/libnss_nis-2.10.1.so 7fabb59e2000-7fabb59f7000 r-xp 00000000 08:13 537596904 /lib64/libnsl-2.10.1.so 7fabb59f7000-7fabb5bf6000 ---p 00015000 08:13 537596904 /lib64/libnsl-2.10.1.so 7fabb5bf6000-7fabb5bf7000 r--p 00014000 08:13 537596904 /lib64/libnsl-2.10.1.so 7fabb5bf7000-7fabb5bf8000 rw-p 00015000 08:13 537596904 /lib64/libnsl-2.10.1.so 7fabb5bf8000-7fabb5bfa000 rw-p 7fabb5bf8000 00:00 0 7fabb5bfa000-7fabb5c01000 r-xp 00000000 08:13 537596907 /lib64/libnss_compat-2.10.1.so 7fabb5c01000-7fabb5e00000 ---p 00007000 08:13 537596907 /lib64/libnss_compat-2.10.1.so 7fabb5e00000-7fabb5e01000 r--p 00006000 08:13 537596907 /lib64/libnss_compat-2.10.1.so 7fabb5e01000-7fabb5e02000 rw-p 00007000 08:13 537596907 /lib64/libnss_compat-2.10.1.so 7fabb5e02000-7fabb60e9000 r--p 00000000 08:13 537378197 /usr/lib64/locale/locale-archive 7fabb60e9000-7fabb60ee000 r-xp 00000000 08:13 805313770 /usr/lib64/libXfixes.so.3.1.0 7fabb60ee000-7fabb62ed000 ---p 00005000 08:13 805313770 /usr/lib64/libXfixes.so.3.1.0 7fabb62ed000-7fabb62ee000 r--p 00004000 08:13 805313770 /usr/lib64/libXfixes.so.3.1.0 7fabb62ee000-7fabb62ef000 rw-p 00005000 08:13 805313770 /usr/lib64/libXfixes.so.3.1.0 7fabb62ef000-7fabb62f1000 r-xp 00000000 08:13 805313901 /usr/lib64/libXdamage.so.1.1.0 7fabb62f1000-7fabb64f0000 ---p 00002000 08:13 805313901 /usr/lib64/libXdamage.so.1.1.0 7fabb64f0000-7fabb64f1000 r--p 00001000 08:13 805313901 /usr/lib64/libXdamage.so.1.1.0 7fabb64f1000-7fabb64f2000 rw-p 00002000 08:13 805313901 /usr/lib64/libXdamage.so.1.1.0 7fabb64f2000-7fabb6503000 r-xp 00000000 08:13 805306692 /usr/lib64/libXext.so.6.4.0 7fabb6503000-7fabb6702000 ---p 00011000 08:13 805306692 /usr/lib64/libXext.so.6.4.0 7fabb6702000-7fabb6703000 r--p 00010000 08:13 805306692 /usr/lib64/libXext.so.6.4.0 7fabb6703000-7fabb6704000 rw-p 00011000 08:13 805306692 /usr/lib64/libXext.so.6.4.0 7fabb6704000-7fabb6706000 r-xp 00000000 08:13 268627792 /usr/lib64/libXcomposite.so.1.0.0 7fabb6706000-7fabb6905000 ---p 00002000 08:13 268627792 /usr/lib64/libXcomposite.so.1.0.0 7fabb6905000-7fabb6906000 r--p 00001000 08:13 268627792 /usr/lib64/libXcomposite.so.1.0.0 7fabb6906000-7fabb6907000 rw-p 00002000 08:13 268627792 /usr/lib64/libXcomposite.so.1.0.0 7fabb6907000-7fabb6911000 r-xp 00000000 08:13 537592263 /usr/lib64/libXcursor.so.1.0.2 7fabb6911000-7fabb6b10000 ---p 0000a000 08:13 537592263 /usr/lib64/libXcursor.so.1.0.2 7fabb6b10000-7fabb6b11000 r--p 00009000 08:13 537592263 /usr/lib64/libXcursor.so.1.0.2 7fabb6b11000-7fabb6b12000 rw-p 0000a000 08:13 537592263 /usr/lib64/libXcursor.so.1.0.2 7fabb6b12000-7fabb6b1a000 r-xp 00000000 08:13 805394369 /usr/lib64/libXrandr.so.2.2.0 7fabb6b1a000-7fabb6d19000 ---p 00008000 08:13 805394369 /usr/lib64/libXrandr.so.2.2.0 7fabb6d19000-7fabb6d1a000 r--p 00007000 08:13 805394369 /usr/lib64/libXrandr.so.2.2.0 7fabb6d1a000-7fabb6d1b000 rw-p 00008000 08:13 805394369 /usr/lib64/libXrandr.so.2.2.0 7fabb6d1b000-7fabb6d25000 r-xp 00000000 08:13 537264894 /usr/lib64/libXi.so.6.0.0 7fabb6d25000-7fabb6f24000 ---p 0000a000 08:13 537264894 /usr/lib64/libXi.so.6.0.0 7fabb6f24000-7fabb6f25000 r--p 00009000 08:13 537264894 /usr/lib64/libXi.so.6.0.0 7fabb6f25000-7fabb6f26000 rw-p 0000a000 08:13 537264894 /usr/lib64/libXi.so.6.0.0 7fabb6f26000-7fabb6f31000 r-xp 00000000 08:13 269524061 /lib64/libsysfs.so.2.0.1 7fabb6f31000-7fabb7130000 ---p 0000b000 08:13 269524061 /lib64/libsysfs.so.2.0.1 7fabb7130000-7fabb7131000 r--p 0000a000 08:13 269524061 /lib64/libsysfs.so.2.0.1 7fabb7131000-7fabb7132000 rw-p 0000b000 08:13 269524061 /lib64/libsysfs.so.2.0.1 7fabb7132000-7fabb7283000 r-xp 00000000 08:13 537596887 /lib64/libc-2.10.1.so 7fabb7283000-7fabb7483000 ---p 00151000 08:13 537596887 /lib64/libc-2.10.1.so 7fabb7483000-7fabb7487000 r--p 00151000 08:13 537596887 /lib64/libc-2.10.1.so 7fabb7487000-7fabb7488000 rw-p 00155000 08:13 537596887 /lib64/libc-2.10.1.so 7fabb7488000-7fabb748d000 rw-p 7fabb7488000 00:00 0 7fabb748d000-7fabb756f000 r-xp 00000000 08:13 538078967 /usr/lib64/libglib-2.0.so.0.2000.2 7fabb756f000-7fabb776f000 Aborted
*** Bug 272526 has been marked as a duplicate of this bug. ***
The hddtemp daemon should be started at system start-up time as root. This is easily achieved with: /etc/init.d/hddtemp start rc-update add hddtemp boot (or default) The problem in this instance is that xfce4-sensors-plugin is not connecting to the socket on port 7634 of localhost. The plugin should attempt to connect to an existing socket *before* attempting to run the daemon.
Are you trying to say there is a daemon support? Last time I've requested it from the upstream they wanted a patch to do anything about it.
(In reply to comment #3) > Are you trying to say there is a daemon support? Yes. That is how the GNOME plugin works. > Last time I've requested it from the upstream they wanted a patch to do > anything about it. Would you like me to attempt to create a patch?
(In reply to comment #4) > > Last time I've requested it from the upstream they wanted a patch to do > > anything about it. > > Would you like me to attempt to create a patch? That would be awesome, because it's not only annoying but also a potential security risk to have hddtemp as suid.
Created attachment 206161 [details] Patch to hddtemp.c to enable connection to the hddtemp daemon via the loopback device (127.0.0.1) on port 7634.
(In reply to comment #5) > (In reply to comment #4) > > > Last time I've requested it from the upstream they wanted a patch to do > > > anything about it. > > > > Would you like me to attempt to create a patch? > > That would be awesome, because it's not only annoying but also a potential > security risk to have hddtemp as suid. Note that the ebuild should be changed so that it no longer instructs the user to chmod the hddtemp utility to suid-root. Instead, it should instruct the user to start the hddtemp daemon and use rc-update to add it to the boot or default run-level (as per comment #2)
Created attachment 206247 [details, diff] Patch to hddtemp.c to enable connection to the hddtemp daemon via the loopback device (127.0.0.1) on port 7634. Improved the look of the GUI by passing better device names. Also cleaned up code that could potentially leak memory.
It needs to be reported also to http://bugzilla.xfce.org so it'll make it into next release and for code review by upstream. That said, i'll try it tonight and apply in Portage it if's working.
(In reply to comment #9) > It needs to be reported also to http://bugzilla.xfce.org so it'll make it into > next release and for code review by upstream. > > That said, i'll try it tonight and apply in Portage it if's working. It would be best for someone else to check it's working. I'm running the patched code on a stable x86 box here, but a wider audience should try it too.
Configured /etc/conf.d/hddtemp for /dev/sda (note that hddtemp /dev/sda works, and reports the correct temp.) and applied your patch, recompiled, started Xfce4 from fresh: with USE="acpi hddtemp" it can be added to panel, but only ACPI is shown with USE="hddtemp" it can't be added to panel (it can without the patch) and it dies with: *** glibc detected *** /usr/libexec...: free(): invalid pointer: 0x00007f450529ceb8 *** where 0x00007f is always constant, but the rest of the values change.
(In reply to comment #11) > Configured /etc/conf.d/hddtemp for /dev/sda (note that hddtemp /dev/sda works, > and reports the correct temp.) and applied your patch, recompiled, started > Xfce4 from fresh: > > with USE="acpi hddtemp" it can be added to panel, but only ACPI is shown This happens when the hddtemp daemon has not been started. Have you started the daemon? > with USE="hddtemp" it can't be added to panel (it can without the patch) and it > dies with: > > *** glibc detected *** /usr/libexec...: free(): invalid pointer: > 0x00007f450529ceb8 *** > > where 0x00007f is always constant, but the rest of the values change. This looks as though there were no sensors available at all, but I cannot yet be certain. There are no direct calls to free() in the hddtemp module, so I suspect it is the driver program crashing. Do you have the lm_sensors daemon running? [As well as the hddtemp daemon.]
(In reply to comment #8) I can confirm this (hddtemp) bug on x86_64 (laptop HP CQ50 with amd64x2), kernel 2.6.30-r5 (gentoo-sources). Unfortunately, though, I can't apply your patch, out of this error: oO_Oo ~ # cd hddtemp-0.3-beta15/src/ oO_Oo src # patch <patch-to-hddtemp.c patching file hddtemp.c Hunk #1 FAILED at 54. Hunk #2 FAILED at 182. Hunk #3 FAILED at 420. Hunk #4 FAILED at 430. Hunk #5 FAILED at 439. Hunk #6 FAILED at 463. Hunk #7 FAILED at 475. Hunk #8 FAILED at 509. Hunk #9 FAILED at 516. 9 out of 9 hunks FAILED -- saving rejects to file hddtemp.c.rej I'm trying on: hddtemp-0.3-beta15.tar.bz2 fetched with: hddtemp-0.3_beta15-r4.ebuild patch version: patch-2.5.9-r1
(In reply to comment #13) > (In reply to comment #8) > > I can confirm this (hddtemp) bug on x86_64 (laptop HP CQ50 with amd64x2), > kernel 2.6.30-r5 (gentoo-sources). > > Unfortunately, though, I can't apply your patch, out of this error: > > oO_Oo ~ # cd hddtemp-0.3-beta15/src/ > oO_Oo src # patch <patch-to-hddtemp.c > patching file hddtemp.c > Hunk #1 FAILED at 54. > Hunk #2 FAILED at 182. > Hunk #3 FAILED at 420. > Hunk #4 FAILED at 430. > Hunk #5 FAILED at 439. > Hunk #6 FAILED at 463. > Hunk #7 FAILED at 475. > Hunk #8 FAILED at 509. > Hunk #9 FAILED at 516. > 9 out of 9 hunks FAILED -- saving rejects to file hddtemp.c.rej > > I'm trying on: hddtemp-0.3-beta15.tar.bz2 > fetched with: hddtemp-0.3_beta15-r4.ebuild > patch version: patch-2.5.9-r1 The patch needs to be applied to xfce4-sensors-plugins-0.10.99.6. The source hddtemp.c is in the "lib" subdirectory.
(In reply to comment #14) > The patch needs to be applied to xfce4-sensors-plugins-0.10.99.6. The source > hddtemp.c is in the "lib" subdirectory. > ok, thank you for the prompt reply. I applied the patch in the right dir, and it only gave me an error, this time: > Hunk #9 FAILED at 516. > 1 out of 9 hunks FAILED -- saving rejects to file hddtemp.c.rej Being those labelled as "516" just a few lines, I compared and changed them manually (while I am not experienced on writing a patch, I know the patch syntax, so hopefully I might have done it right), tar -cjf, and ebuild bla, bla, bla manifest. I checked manually the new files checksum and the new ebuild was correct. I re-emerged xfce4-sensors-plugin with hddtemp use on, and the patched version compiled and installed fine. No improvements, either after a daemons restart and xfce logout-login or a fresh computer restart. Can't see hd temperature listed in the conf panel for xfce4-sensors-plugin, it just shows ACPI (two sockets in my case) and battery. btw, why are xfce and its extras the only one packages where every new ebuild totally wipes out the old ones from portage? I mean, couldn't we just have the chance to choise between several versions? I'm posing this question now, on the xfce4-sensors issue, but was tempted for a very long time to ask why this bizarre policy is in place.
(In reply to comment #15) > (In reply to comment #14) > > The patch needs to be applied to xfce4-sensors-plugins-0.10.99.6. The source > > hddtemp.c is in the "lib" subdirectory. > > > > ok, thank you for the prompt reply. I applied the patch in the right dir, and > it only gave me an error, this time: > > Hunk #9 FAILED at 516. > > 1 out of 9 hunks FAILED -- saving rejects to file hddtemp.c.rej > > Being those labelled as "516" just a few lines, I compared and changed them > manually (while I am not experienced on writing a patch, I know the patch > syntax, so hopefully I might have done it right), tar -cjf, and ebuild bla, > bla, bla manifest. I checked manually the new files checksum and the new ebuild > was correct. I re-emerged xfce4-sensors-plugin with hddtemp use on, and the > patched version compiled and installed fine. I'm a little suprised the patch didn't appply directly, but if the discrepancy is trivial there should be no problem. Just make sure that you are using the right release of xfce4-sensors-plugin. > No improvements, either after a daemons restart and xfce logout-login or a > fresh computer restart. Can't see hd temperature listed in the conf panel for > xfce4-sensors-plugin, it just shows ACPI (two sockets in my case) and battery. There are 2 immediate possibilities for this: 1. The hddtemp daemon isn't running. 2. The hddtemp daemon is running but hasn't been configured properly. The second one is often caused by the hddtemp database lacking entries for the make and model of hard drive(s) in your system. Take a look at /usr/share/hddtemp/hddtemp.db and see if it contains the model id. string for your hard drive(s). If it doesn't, you will need to add one or more lines so that the daemon can interpret the S.M.A.R.T. attributes returned by your drives that represent temperature. You will then need to restart the hddtemp daemon. You should also check that /etc/conf.d/hddtemp contains the device names of the drives you wish to monitor. See comment #2, above, about starting hddtemp as a daemon. > btw, why are xfce and its extras the only one packages where every new ebuild > totally wipes out the old ones from portage? I mean, couldn't we just have the > chance to choise between several versions? I'm posing this question now, on the > xfce4-sensors issue, but was tempted for a very long time to ask why this > bizarre policy is in place. I would not know, as I'm not an Xfce developer. In fact, I'm not even a Gentoo developer.
(In reply to comment #16) > 1. The hddtemp daemon isn't running. It is. > 2. The hddtemp daemon is running but hasn't been configured properly. It is. As I said in Comment #11. Same result here as disperato is seeing.
(In reply to comment #15) > btw, why are xfce and its extras the only one packages where every new ebuild > totally wipes out the old ones from portage? I mean, couldn't we just have the > chance to choise between several versions? I'm posing this question now, on the > xfce4-sensors issue, but was tempted for a very long time to ask why this > bizarre policy is in place. /me mutters something about hijacking bugs but feels compelled to reply anyway. I usually keep a couple versions available in the other packages that I maintain but it is a huge chore to keep an entire DE in working condition for everyone. We are not going to claim support for mixing apps developed with xfce-4.4 on a 4.6 system (for example). Keep in mind ~108 packages are being maintained by 2 people right now ;) I'm not even going to go into the extra space needed on community mirrors for little gain. Also, keep in mind, you can *always* maintain your own overlay with files from the attic: http://sources.gentoo.org/viewcvs.py/gentoo-x86/xfce-extra/xfce4-sensors/?hideattic=0 Anyway, back on topic. Please no more OT chatter on this bug. Thanks.
Yes, my hddtemp was running during the test and the db has the relevant entry (though it can work without it). I found somewhere a 0.10.99.5.tar.gz and installed manually with no modifications to hddtemp configurations and it's working again. I just installed it, no need to restart hddtemp. @ Jeremy Olexa (darkside) thank you, I'll follow your tips.
(In reply to comment #19) > Yes, my hddtemp was running during the test and the db has the relevant entry > (though it can work without it). The hddtemp program, when used as a stand-alone utility, can work without the database entry. When used as a daemon, it *must* have the disk drive's entry available; if not, it returns the string "UNK" as the temperature value. > I found somewhere a 0.10.99.5.tar.gz and installed manually with no > modifications to hddtemp configurations and it's working again. I just > installed it, no need to restart hddtemp. I shall upload some source code of a small diagnostic utility I wrote to get the modified Xfce plugin working on my system. It reads the hddtemp data from the daemon's socket and prints it to the screen. I would like all interested parties to run it and report the results here. This will show us the health of everybody's hddtemp daemon and its database. In the interim, I shall take another look at the patch, and particularly look at the options I use on the diff utility to create it. I suspect the subsequent patch problems to stem from that.
Created attachment 207178 [details] Diagnostic utility for reading hddtemp daemon's output. Build the executable by running "make", then run the program by running "./read_hddtemp".
(In reply to comment #21) > Created an attachment (id=207178) [details] > Diagnostic utility for reading hddtemp daemon's output. > > Build the executable by running "make", then run the program by running > "./read_hddtemp". > you were right, the hard disk entry was not there, maybe wiped out by an upgrade or whatever. The patch, though with the problem reported at line 516 (and files manually modified), is working. Thank you.
Created attachment 207249 [details, diff] Patch to hddtemp.c to enable connection to the hddtemp daemon via the loopback device (127.0.0.1) on port 7634. Changed patch creation options to produced a simpler patch.
Fixing the problem by implementing new features is not the right way for us. Upstream said they applied a patch in git, there was no release since then though. Could you please try again with a recent git snapshot (or use the live ebuild)?
Can you please try again with xfce4-sensors-plugin-1.0.0?
(In reply to comment #25) > Can you please try again with xfce4-sensors-plugin-1.0.0? Okay. It will be a few days before I start, as I am working on some other code at the moment. I will also try to create an ebuild, so that Gentoo users can easily install the patch for testing.
I'm not asking for an updated patch for 1.0.0 - feel free to do it and send it upstream (bugzilla.xfce.org). What I'm asking is if the problem still exists with 1.0.0.
please attach a gdb backtrace. see http://www.gentoo.org/proj/en/qa/backtraces.xml and http://wiki.xfce.org/howto/panel_plugin_debug for more information.
Created attachment 235471 [details, diff] Ebuild and ptach to ease upgrade of lm_sensors This upload contains an ebuild as well as a patch. Untar the gzipped tarball into /usr/local/portage (or wherever PORTDIR_OVERLAY is pointing), *NOT* into /usr/portage, as this is a hack and should only be in your local overlay. Since lm_sensors was upgraded to 3.2.1 today, your revdep-rebuild will work [I hope] if you have this ebuild in your local overlay. Please report any problems.
(In reply to comment #27) > I'm not asking for an updated patch for 1.0.0 - feel free to do it and send it > upstream (bugzilla.xfce.org). > What I'm asking is if the problem still exists with 1.0.0. I took a look at the ebuild, and it still depends on netcat. This means that the Xfce project's code operates in the way the old code attempted to: by creating a new address space in which to run netcat, each time it wants to poll the hddtemp daemon. Such an overhead is highly undesirable, compared with simply opening a socket. This is not the way to design code. The upshot is that I shall not be testing the new code from the Xfce project, nor will I be installing it when it goes stable. Instead, I will maintain my patch privately and use that.
Created attachment 235601 [details, diff] ebuild and patch to ease upgrade of lm_sensors with libsensors The earlier patch would produce compilation errors if the configure script detected libsensors. The patch now has an extra few lines to handle libsensors conditionally.
(In reply to comment #30) > I took a look at the ebuild, and it still depends on netcat. This means that > the Xfce project's code operates in the way the old code attempted to Rather ineffective way of testing that... the ebuild contains what we write in it, a bump usually consists of a copy and some changes. So that dependency was just copied from the older ebuilds, it _should_ mean that the plugin does require netcat, but you can't know if we really checked that. If you really want to know if the plugin behaviour changed, you'll have to install it and see for yourself. I could just as well remove the dependency, that won't make the plugin behave differently. And again, please take your patches upstream. We can't maintain such a set of changes.
upstream ->
