The sensors plugin forgets its settings every now and then. I want to have displayed the thermal sensors for the CPU, the System and my HDD. When I select these sensors in the settings dialog and rename them they are displayed as expected. But every now and then - not always - when I logout, reboot my system and login again, the sensor plugin only displays the HDD sensor with the name I've given but forgets the settings (selection and name) of the other two sensors, so that I regularly have to change these settings again. Affected are at least the it8720-228 (temp1 and temp2) sensor.
I have the same problem. Details: https://bugs.archlinux.org/task/20399?project=1&opened=5430 Config is lost when change sensors order. For example: Day 0: I set some sensors Day 1: Config is lost (for all sensors) === diff output ==== Preferred_Height=356 [Chip0] -Name=acpitz-0 +Name=k8temp-c3 Number=0 -[Chip0_Feature0] -Id=0 -Address=0 -Name=temp1 -Color=#00B000 -Show=true -Min=0,00 -Max=80,00 - [Chip1] -Name=k8temp-c3 +Name=acpitz-0 Number=1 [Chip2] Name=atk0110-0 Number=2 -[Chip2_Feature4] -Id=-1 -Address=4 -Name=CPU FAN Speed -Color=#00B000 -Show=true -Min=1500,00 -Max=3500,00 - [Chip3] Name=ACPI Number=3 === /diff output ==== I reconfig sensors panel. Day 2: Config is lost again (only one sensor live) === diff output ==== Preferred_Height=356 [Chip0] -Name=k8temp-c3 +Name=acpitz-0 Number=0 [Chip1] -Name=acpitz-0 +Name=k8temp-c3 Number=1 [Chip2] Name=atk0110-0 Number=2 +[Chip2_Feature4] +Id=-1 +Address=4 +Name=CPU FAN Speed +Color=#00B000 +Show=true +Min=1500,00 +Max=3500,00 + [Chip3] Name=ACPI Number=3 === /diff output ====
OK, thx for the detailed diff. In fact, this behaviour was intended because I rather assumed to have new chips with other or new features (i.e. names) because of other module drivers or new hardware. And in this case you rather would not want to reuse the previous settings. For this purpose, the concept of chip numbers was introduced. By specifying the order in which modules load, you will be able to bypass this problem, i.e. first load acpi and then lm-sensors-whatever module. I will therefore close this bug as invalid at first; feel free to reopen it if you have any strong arguments why I should neglect the order in which chips are found. Please also report to archlinux and indicate the workaround with the order in which modules load, thanks.
Bug reopened, because there is a strong argument why you should neglect the order in which chips are found. Kernel modules are loaded quite randomly. In my case the affected modules are k8temp and it87. Unfortunately both modules don't have an index parameter. So it's not possible to set the load order in /etc/modprobe.d/modprobe.conf. If there was such an index option in all of these modules as it is in the sound modules it would be possible to set a fixed order in which those modules would be loaded. So I doubt that downstream can set a default priority or something like that.
I had another look at the modules and /etc/conf.d/lm_sensors. This is the content of this file besides some comments: HWMON_MODULES="k8temp it87" MODULE_0=k8temp MODULE_1=it87 If this has an effect on the order in which these modules are loaded then they should always be loaded in a fixed order. In this case the order in which the modules are loaded can't be the reason for this bug.
Same here with it87, k8temp and hddtemp. Every 2-3 boots the sensors plugin reverts to hddtemp only. Since the problem is caused by a random re-ordering, how about imposing a sort, e.g by module name? Here's a workaround: Use multiple sensors plugins, one per module. You get multiple configuration files in ~/.config/xfce4/panel but within each module you can display as many voltages, fan speeds and temp's as you like. Maybe I've just been lucky but it seems to work.
Unfortunately, the proposed workaround doesn't work. When the order of the modules listed in the "Sensors type:" pull-down menu changes, the configuration for the re-ordered modules is lost, even if there is a separate instance of sensors-plugin for each module.
Since Xfce 4.8 I can't get sensors-plugin running at all. When I add it to the panel I only get its title "Sensors". When I change some settings they all get lost and I still only have the title "Sensors". So it's completely unusable anymore. See bug #7208. Regarding this bug, there's now a sensors module radeon-100 which can't be loaded in a specific order by adding it to /etc/conf.d/lm_sensors, because there's no separate kernel sensors module radeon-100. I haven't tested it, if it's possible to add the kernel module radeon to this file. And I don't think that new chips are added to a computer so often. So it would be nice if the modules will be loaded by the plugin in a specified order or if the plugin settings are not always lost if those modules are loaded in a random order. And it would be nice if the other issue above would be fixed, too. The sensors plugin is not the least important plugin.
I am also affected by this issue. xfce4-sensors-plugin lists the following: acpitz-0, k10temp-c3, thinkpad-0, radeon-8, ACPI .. and there seem to be enough randomness in loading and probing the modules for the enumeration to change every now and then.
fixed with current commit. feel free to test and report; I swapped the entries in my config file and it worked at least
I'm using Arch Linux and updated today to the latest version of xfce4-sensors-plugin-git package. It still crashes. dmesg shows entries like this: [28126.359816] xfce4-sensors-p[11281]: segfault at 8 ip 00007f3667fcd541 sp 00007fff33796d58 error 4 in libc-2.13.so[7f3667f51000+154000] [28726.532118] xfce4-sensors-p[11487]: segfault at 8 ip 00007f3762a7e541 sp 00007fffbc91de28 error 4 in libc-2.13.so[7f3762a02000+154000] [29219.124949] xfce4-sensors-p[11662]: segfault at 7fcc70000000 ip 00007fcc6f3592d9 sp 00007fff18a8f370 error 4 in libc-2.13.so[7fcc6f2e2000+154000] [31313.098971] xfce4-sensors-p[967]: segfault at 8 ip 00007feb5e99e541 sp 00007fffbe91c5a8 error 4 in libc-2.13.so[7feb5e922000+154000] I can't change the order of the modules in /etc/conf.d/lm_sensors, because there is only one: HWMON_MODULES="w83627ehf" MODULE_0=w83627ehf (the k8temp module is loaded automatically as dependency of w83627ehf) Could you please fix this bug in near future?! It is really annoying...
(In reply to comment #10) > (the k8temp module is loaded automatically as dependency of w83627ehf) In Arch Linux you can prevent k8temp from being loaded automatically by adding "!k8temp" to the MODULES array in /etc/rc.conf.
(In reply to comment #10) > I'm using Arch Linux and updated today to the latest version of > xfce4-sensors-plugin-git package. It still crashes. dmesg shows entries like > this: > > [28126.359816] xfce4-sensors-p[11281]: segfault at 8 ip 00007f3667fcd541 sp > 00007fff33796d58 error 4 in libc-2.13.so[7f3667f51000+154000] > [28726.532118] xfce4-sensors-p[11487]: segfault at 8 ip 00007f3762a7e541 sp > 00007fffbc91de28 error 4 in libc-2.13.so[7f3762a02000+154000] > [29219.124949] xfce4-sensors-p[11662]: segfault at 7fcc70000000 ip > 00007fcc6f3592d9 sp 00007fff18a8f370 error 4 in > libc-2.13.so[7fcc6f2e2000+154000] > [31313.098971] xfce4-sensors-p[967]: segfault at 8 ip 00007feb5e99e541 sp > 00007fffbe91c5a8 error 4 in libc-2.13.so[7feb5e922000+154000] > > I can't change the order of the modules in /etc/conf.d/lm_sensors, because > there is only one: So your report is not related to the changing order and must therefore appear in a different bug report. Investigate as given the steps within this thread and the other bug reports related to your issue. dmesg output doesn't tell much, and you did not present the actions you performed with the plugin before it crashed.
(In reply to comment #10) > I'm using Arch Linux and updated today to the latest version of > xfce4-sensors-plugin-git package. It still crashes. dmesg shows entries like > this: > Now I understand your ArchLinuxer problems... Your git package is not a git package, but was a git pull on the day the package was created from git sources instead of from a release. So you don't have the latest patches and have to ask the archlinuxers to pull the new git version or you have to use git on your own, as I already indicated in the previous comment.
(In reply to comment #13) > Now I understand your ArchLinuxer problems... Your git package is not a git > package, but was a git pull on the day the package was created from git sources > instead of from a release. So you don't have the latest patches and have to ask > the archlinuxers to pull the new git version or you have to use git on your > own, as I already indicated in the previous comment. Not really. This is the PKGBUILD (bash script) from AUR which downloads the latest git snapshot and builds it. $pkgver doesn't contain a fixed version number and is always updated before pulling the snapshot from the git tree, so it always contains the version number of the latest git snapshot. Means if there will be a git snapshot 20110511 $pkgver will first be updated from 20110509 to 20110511 automatically. And it doesn't make any difference if you pull and build the latest snapshot manually or with a PKGBUILD. The advantage of the PKGBUILD is that it first creates a package which can be installed and managed by the package manager pacman. It does pretty the same as you explained me in bug #7208, which is indeed fixed now. And with this new PKGBUILD it can be built again without errors. The reason why I couldn't build it were two cp commands which I missed. (Maybe another upstream bug?) See the lines: cp ${srcdir}/configuration.c ${srcdir}/${_gitname}/lib cp /usr/share/libtool/config/ltmain.sh . The PKGBUILD: # Maintainer kfgz <kfgz at interia pl> # Package based on xfce4-sensors-plugin pkgname=xfce4-sensors-plugin-git pkgver=20110509 pkgrel=1 pkgdesc="A lm_sensors plugin for the Xfce panel" arch=('i686' 'x86_64') license=('GPL2') url="http://git.xfce.org/panel-plugins/xfce4-sensors-plugin/" groups=('xfce4-goodies') depends=('xfce4-panel>=4.6.0' 'gnu-netcat' 'hddtemp>=0.3.beta15.45-2' 'lm_sensors>=3.1.0' 'libnotify>0.7.1' 'hicolor-icon-theme') makedepends=('pkgconfig' 'intltool' 'xfce4-dev-tools' 'git') options=(!libtool) conflicts=('xfce4-sensors-plugin' 'xfce4-sensors-plugin-svn') install=xfce4-sensors-plugin.install #source=(segfault_fix.patch) source=(configuration.c) md5sums=(af63b2b19691858f86781a284e985318) _gitroot="git://git.xfce.org/panel-plugins/xfce4-sensors-plugin" _gitname="xfce4-sensors-plugin" build() { cd ${srcdir} msg "Connecting to xfce.org GIT server...." if [ -d ${srcdir}/${_gitname} ] ; then cd ${_gitname} && git pull origin msg "The local files are updated." else git clone ${_gitroot} fi msg "GIT checkout done or server timeout" msg "Creating build directory" #segfault fix cp ${srcdir}/configuration.c ${srcdir}/${_gitname}/lib if [ -d ${srcdir}/${_gitname}-build ]; then rm -rf ${srcdir}/${_gitname}-build; fi cp -R ${srcdir}/${_gitname} ${srcdir}/${_gitname}-build msg "Starting make..." cd ${srcdir}/${_gitname}-build #fix for missing ltmain.sh cp /usr/share/libtool/config/ltmain.sh . #segfault fix #cd ${srcdir} #patch -Np1 -i ${srcdir}/segfault_fix.patch #cd ${srcdir}/${_gitname}-build xdt-autogen ./configure --prefix=/usr \ --sysconfdir=/etc \ --libexecdir=/usr/lib \ --localstatedir=/var \ --disable-static \ --disable-notification \ --with-pathhddtemp=/usr/sbin/hddtemp \ --disable-debug ##--disable-notification ## package won't compile when enabled make -j1 } package() { cd ${srcdir}/${_gitname}-build make DESTDIR=${pkgdir} install }
why do you overwrite lib/configuration.c with an empty file? there is not configuration.c in the root dir. Maybe this is a left-over from the patches? Also try to no longer disable notifications as it is fixed since at least this weekend. Instead of xdt-autogen and configure, you should use ./autogen.sh. The ltmain.sh is really missing in my case as well, it is added to git now, hopefully this works.
(In reply to comment #15) > why do you overwrite lib/configuration.c with an empty file? there is not > configuration.c in the root dir. Maybe this is a left-over from the patches? > > Also try to no longer disable notifications as it is fixed since at least this > weekend. Instead of xdt-autogen and configure, you should use ./autogen.sh. > > The ltmain.sh is really missing in my case as well, it is added to git now, > hopefully this works. This package is not from me, but the configuration.c is not empty, it's in the AUR package. Download the Tar-Archive from http://aur.archlinux.org/packages.php?ID=31168 and untar the archive. Then you will see the configuration.c. According to the comment above (in the PKGBUILD) it seems to fix a segfault bug. Maybe you should indeed have a look at it and compare it to yours. $srcdir contains the directory into which every file in the source array of the PKGBUILD (e.g. the source package, patches etc.) is copied. It's actually the working directory for building the package. If I try to build it exactly as you explain, it again fails to build at: panel-plugin/Makefile.am:48: `%'-style pattern rules are a GNU make extension Makefile.am: installing `./INSTALL' So autogen.sh doesn't seem to work while xdt-autogen and configure is working. And ltmain.sh is still missing. Maybe your git tree doesn't release new commits at once? Because every other change you made a few days ago is now present in the git snapshot while they haven't been when I tried it two days ago. Btw., notifications is not disabled anymore. The option --disable-notification is commented out in the PKGBUILD.
(In reply to comment #16) > (In reply to comment #15) > > why do you overwrite lib/configuration.c with an empty file? there is not > > configuration.c in the root dir. Maybe this is a left-over from the patches? > > > > Also try to no longer disable notifications as it is fixed since at least this > > weekend. Instead of xdt-autogen and configure, you should use ./autogen.sh. > > > > The ltmain.sh is really missing in my case as well, it is added to git now, > > hopefully this works. > > This package is not from me, but the configuration.c is not empty, it's in the > AUR package. Download the Tar-Archive from > http://aur.archlinux.org/packages.php?ID=31168 and untar the archive. Then you > will see the configuration.c. According to the comment above (in the PKGBUILD) > it seems to fix a segfault bug. It doesn't. As I said, it's the applied "patch" that only does not save the global variable font, which however is initialized to non-NULL when initializing the tachometer class and which is saved only if valid. > Maybe you should indeed have a look at it and > compare it to yours. I had, maybe you better have a look at the files on what they do and what they are. Also, it seems that the packaging is kind of crapped when instead of patches the patched files are delivered. Another reason why your packages fail. > $srcdir contains the directory into which every file in the source array of the > PKGBUILD (e.g. the source package, patches etc.) is copied. It's actually the > working directory for building the package. That was clear from the code. > > If I try to build it exactly as you explain, it again fails to build at: > panel-plugin/Makefile.am:48: `%'-style pattern rules are a GNU make extension > Makefile.am: installing `./INSTALL' Ahm, it doesn't fail to build. You need to be precise, I couldn't figure out what you meant the last time as well. I can guess now that you mean that configuration or autogeneration stops after this message. The build process is compiling with "make" or "gcc". Same story with what you meant on you forgot to "cp". > So autogen.sh doesn't seem to work while xdt-autogen and configure is working. That's strange. > And ltmain.sh is still missing. Maybe your git tree doesn't release new commits > at once? Did you try autogen.sh before or after adding the ltmain.sh. It is important to be methodically correct and complete when trying such stuff, because otherwise the reports are useless to me. > Because every other change you made a few days ago is now present in > the git snapshot while they haven't been when I tried it two days ago. My bad, forgot to push because I thought I already had pushed the changes. It now really is included. > Btw., notifications is not disabled anymore. The option --disable-notification > is commented out in the PKGBUILD. See your build script, it's commented below, but still included in the options.
(In reply to comment #17) > It doesn't. As I said, it's the applied "patch" that only does not save the > global variable font, which however is initialized to non-NULL when > initializing the tachometer class and which is saved only if valid. The configuration.c from the AUR package can indeed be removed I think. At least it builds and runs without it. But the tachometer only eats up a lot of CPU resources, but doesn't do anything, maybe it doesn't belong to this bug. > I had, maybe you better have a look at the files on what they do and what they > are. Also, it seems that the packaging is kind of crapped when instead of > patches the patched files are delivered. Another reason why your packages fail. It wasn't the package's fault, at least not only. > Ahm, it doesn't fail to build. You need to be precise, I couldn't figure out > what you meant the last time as well. I can guess now that you mean that > configuration or autogeneration stops after this message. The build process is > compiling with "make" or "gcc". Same story with what you meant on you forgot to > "cp". > > > So autogen.sh doesn't seem to work while xdt-autogen and configure is working. > That's strange. Now it seems to work with autogen.sh as well as with xdt-autogen and configure. > Did you try autogen.sh before or after adding the ltmain.sh. It is important to > be methodically correct and complete when trying such stuff, because otherwise > the reports are useless to me. I guess after adding it. But this is fixed now. ltmain doesn't need to be copied anymore by the PKGBUILD. > See your build script, it's commented below, but still included in the options. Like I said, it's not mine, but I indeed missed it. Nevertheless it fails to build without --disable-notification. I get this error message: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -DNDEBUG -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\" -pthread -I/usr/include/xfce4/libxfce4ui-1 -I/usr/include/gtk-2.0 -I/usr/include/xfce4 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -pthread -I/usr/include/xfce4/libxfce4panel-1.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/xfce4 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/include -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -march=x86-64 -mtune=generic -O2 -pipe -MT libxfce4sensors_la-sensors-interface.lo -MD -MP -MF .deps/libxfce4sensors_la-sensors-interface.Tpo -c sensors-interface.c -fPIC -DPIC -o .libs/libxfce4sensors_la-sensors-interface.o sensors-interface.c:27:24: warning: extra tokens at end of #ifdef directive [enabled by default] sensors-interface.c: In function 'fill_gtkTreeStore': sensors-interface.c:74:28: warning: extra tokens at end of #ifdef directive [enabled by default] sensors-interface.c:104:40: warning: extra tokens at end of #ifdef directive [enabled by default] sensors-interface.c:109:17: error: too many arguments to function 'notify_notification_new' /usr/include/libnotify/notification.h:114:21: note: declared here make[2]: *** [libxfce4sensors_la-sensors-interface.lo] Error 1 make[2]: Leaving directory `/tmp/yaourt-tmp-cyber/aur-xfce4-sensors-plugin-git/src/xfce4-sensors-plugin-build/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/yaourt-tmp-cyber/aur-xfce4-sensors-plugin-git/src/xfce4-sensors-plugin-build' make: *** [all] Error 2
Hello, it works now! I just can't say why, because I disabled the k8temp module in the modules list yesterday, and today after a new boot I updated the Xfce4-sensors-plugin to the latest git version. Thank you very much!
(In reply to comment #18) > (In reply to comment #17) > I get this error message: > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -DNDEBUG > -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS > -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\" -pthread > -I/usr/include/xfce4/libxfce4ui-1 -I/usr/include/gtk-2.0 -I/usr/include/xfce4 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 > -I/usr/include/libpng14 -pthread -I/usr/include/xfce4/libxfce4panel-1.0 > -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/xfce4 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 > -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 > -I/usr/include -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -pthread > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -march=x86-64 > -mtune=generic -O2 -pipe -MT libxfce4sensors_la-sensors-interface.lo -MD -MP > -MF .deps/libxfce4sensors_la-sensors-interface.Tpo -c sensors-interface.c > -fPIC -DPIC -o .libs/libxfce4sensors_la-sensors-interface.o > sensors-interface.c:27:24: warning: extra tokens at end of #ifdef directive > [enabled by default] > sensors-interface.c: In function 'fill_gtkTreeStore': > sensors-interface.c:74:28: warning: extra tokens at end of #ifdef directive > [enabled by default] That's an easy one, thanks for letting me know, it's a left-over of my first ifdef tries. Should work now as well, changes are pushed
(In reply to comment #20) > That's an easy one, thanks for letting me know, it's a left-over of my first > ifdef tries. Should work now as well, changes are pushed It still doesn't work, still the same error. Have you pushed the fix or is there another issue which causes this build failure? Btw., the AUR package is now without any downstream patches.
(In reply to comment #20) > That's an easy one, thanks for letting me know, it's a left-over of my first > ifdef tries. Should work now as well, changes are pushed Sorry, it fails with a different error message: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -DNDEBUG -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\" -pthread -I/usr/include/xfce4/libxfce4ui-1 -I/usr/include/gtk-2.0 -I/usr/include/xfce4 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -pthread -I/usr/include/xfce4/libxfce4panel-1.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/xfce4 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 -I/usr/include -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -march=x86-64 -mtune=generic -O2 -pipe -MT libxfce4sensors_la-sensors-interface.lo -MD -MP -MF .deps/libxfce4sensors_la-sensors-interface.Tpo -c sensors-interface.c -fPIC -DPIC -o .libs/libxfce4sensors_la-sensors-interface.o sensors-interface.c: In function 'fill_gtkTreeStore': sensors-interface.c:109:17: error: too many arguments to function 'notify_notification_new' /usr/include/libnotify/notification.h:114:21: note: declared here make[2]: *** [libxfce4sensors_la-sensors-interface.lo] Error 1 make[2]: Leaving directory `/tmp/yaourt-tmp-cyber/aur-xfce4-sensors-plugin-git/src/xfce4-sensors-plugin-build/lib' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/yaourt-tmp-cyber/aur-xfce4-sensors-plugin-git/src/xfce4-sensors-plugin-build' make: *** [all] Error 2
(In reply to comment #22) > (In reply to comment #20) > > That's an easy one, thanks for letting me know, it's a left-over of my first > > ifdef tries. Should work now as well, changes are pushed > > Sorry, it fails with a different error message: > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -DNDEBUG > -DG_DISABLE_CAST_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS > -DPACKAGE_LOCALE_DIR=\"/usr/share/locale\" -pthread > -I/usr/include/xfce4/libxfce4ui-1 -I/usr/include/gtk-2.0 -I/usr/include/xfce4 > -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 > -I/usr/include/libpng14 -pthread -I/usr/include/xfce4/libxfce4panel-1.0 > -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include > -I/usr/include/xfce4 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 > -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 > -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng14 > -I/usr/include -pthread -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -pthread > -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 > -I/usr/lib/glib-2.0/include -I/usr/include/libpng14 -march=x86-64 > -mtune=generic -O2 -pipe -MT libxfce4sensors_la-sensors-interface.lo -MD -MP > -MF .deps/libxfce4sensors_la-sensors-interface.Tpo -c sensors-interface.c > -fPIC -DPIC -o .libs/libxfce4sensors_la-sensors-interface.o > sensors-interface.c: In function 'fill_gtkTreeStore': > sensors-interface.c:109:17: error: too many arguments to function > 'notify_notification_new' > /usr/include/libnotify/notification.h:114:21: note: declared here because you might have the headers for libnotify0.7 but configured it differently or because you explicitly enabled it, which would trigger version 0.4 then. again, first be sure on what you did BEFORE, i.e. simply autogen.sh, and only then check the output of what is built and whether that's correct. Maybe the detection of your notify version is wrong; or you have libnotif 0.5 or 0.6 if that exists, I don't know. Can't help further this way, again, you need to be much mor eaware of what you did and detailed in the descriptions, as if you were the author and maintainer of the plugin yourself, otherwise these bug reports really are useless and a time-consuming guess in the wild for me.
(In reply to comment #23) > because you might have the headers for libnotify0.7 but configured it > differently or because you explicitly enabled it, which would trigger version > 0.4 then. again, first be sure on what you did BEFORE, i.e. simply autogen.sh, > and only then check the output of what is built and whether that's correct. > Maybe the detection of your notify version is wrong; or you have libnotif 0.5 > or 0.6 if that exists, I don't know. > > Can't help further this way, again, you need to be much mor eaware of what you > did and detailed in the descriptions, as if you were the author and maintainer > of the plugin yourself, otherwise these bug reports really are useless and a > time-consuming guess in the wild for me. Sorry, but this is definitely a bug in your package. I have installed libnotify 0.7.2. And this is the actual error message: sensors-interface.c: In function 'fill_gtkTreeStore': sensors-interface.c:109:17: error: too many arguments to function 'notify_notification_new' So you pass too many arguments to a function call or a declaration or the like. The error message also tells you the position of the error. But I'll attach a full build log and the current PKGBUILD which doesn't apply any downstream patches anymore.
Created attachment 3660 xfce4-sensors-plugin-git build log
Created attachment 3661 PKGBUILD
(In reply to comment #24) > (In reply to comment #23) > > because you might have the headers for libnotify0.7 but configured it > > differently or because you explicitly enabled it, which would trigger version > > 0.4 then. again, first be sure on what you did BEFORE, i.e. simply autogen.sh, > > and only then check the output of what is built and whether that's correct. > > Maybe the detection of your notify version is wrong; or you have libnotif 0.5 > > or 0.6 if that exists, I don't know. > > > > Can't help further this way, again, you need to be much mor eaware of what you > > did and detailed in the descriptions, as if you were the author and maintainer > > of the plugin yourself, otherwise these bug reports really are useless and a > > time-consuming guess in the wild for me. > > Sorry, but this is definitely a bug in your package. > > I have installed libnotify 0.7.2. > > And this is the actual error message: > > sensors-interface.c: In function 'fill_gtkTreeStore': > sensors-interface.c:109:17: error: too many arguments to function > 'notify_notification_new' > > So you pass too many arguments to a function call or a declaration or the like. > The error message also tells you the position of the error. Gee, I know that. But I can't guess your config.h or output from configure, nor your options you passed. > > But I'll attach a full build log and the current PKGBUILD which doesn't apply > any downstream patches anymore. Well, see xfce@xfce.org, another one was able to precisely, accurately and quickly tell what he noticed, it is fixed in git now and a 1.2.1 release is published. Apart from that, I already told you to not keep bug reports alive because you can't compile while the actualy issue has been fixed long ago. And I shouldn't have been explaining bug-reporting within bug-reports themselves.
(In reply to comment #27) > (In reply to comment #24) > Gee, I know that. But I can't guess your config.h or output from configure, nor > your options you passed. You could have asked for these informations if you needed additional ones. But I have given you the options, at least I have given you the URL to the PKGBUILD I was using. But what does the config.h, the configure output or the options have to do with this libnotify bug? If you pass too many arguments then you pass too many arguments to a function call. I don't know which argument is too much. I haven't written the plugin and I haven't written libnotify. So I don't know any changes made in the latest libnotify package. I assume that you know your code and libnotify better than me. > Well, see xfce@xfce.org, another one was able to precisely, accurately and > quickly tell what he noticed, it is fixed in git now and a 1.2.1 release is > published. Excuse me, but I have also explained in detail and accurately what I have noticed. I gave you every error message. What else do you expect? I tried everything you asked me to do. If you need some more specific informations, you could ask for them. I can't read your mind. It's, btw., not fixed in git. The libnotify error still exists. > Apart from that, I already told you to not keep bug reports alive because you > can't compile while the actualy issue has been fixed long ago. And I shouldn't > have been explaining bug-reporting within bug-reports themselves. You didn't told me that, not to mention the fact that this is usually obvious. But in this case those build errors came up during some tests I've made to help you fix the original issues. So it's a lot easier and faster to post and fix those error messages in this bug report. Regarding the libnotify bug I'm willingly to open a new bug report if you want me to as this indeed hasn't anything to do with this bug.
(In reply to comment #28) > (In reply to comment #27) > > (In reply to comment #24) > > It's, btw., not fixed in git. The libnotify error still exists. Well, I did push the changes before, and it must work. See if the have_libnotify7 is preceding via an elsif statement at the region where you get the compile error. and check your output whether the two libmotify messages are still there. the first one now indicates general support, the second one explicit support for libnotify 0.7. and then it all should work.
(In reply to comment #29) > Well, I did push the changes before, and it must work. See if the > have_libnotify7 is preceding via an elsif statement at the region where you get > the compile error. and check your output whether the two libmotify messages are > still there. the first one now indicates general support, the second one > explicit support for libnotify 0.7. and then it all should work. I found the bug. It's a syntax error in sensors-interface.c and hddtemp.c. This fixes the issue: sed -i "s:#elseif:#elif:g" lib/sensors-interface.c sed -i "s:#elseif:#elif:g" lib/hddtemp.c
Regarding the original issue here, I took the patch that went into 1.2 and applied it onto Ubuntu natty's 1.0 and it has been working fine since. Consider this tested if you don't hear back from me in the next week or so! Cheers.
Spoke too soon :( This morning my panel was showing again "Sensors", and not the CPU temperature I had selected. I noticed that the it did not only forget the sensor (i.e. the one that was activated and the friendly name I gave it), but also all other global settings like update interval, not showing the title and labels. Can you make sense of this, Fabian? Is there something else going on besides the module loading variations that could clear the configuration like this? Regards.
Gottfried, are you still using 1.0.0 with only this patch? Is your issue probably bug #7208? It's fixed in git and 1.2.1.
I just installed the current git version and will update this bug when the issue occurs again.
Florian, this bug seems still not be fixed - can you reopen the bug? I am running a fairly recent version compiled from git (a0d04d600bfad800a7a77b4f68f45d7117ff19fa). My laptop died after the battery ran out, and when I restarted xfce4-sensors had forgotten all its settings. Now I don't know whether this is because of the dirty shutdown, or this was just a coincidence. For the reference, the order in which I am seeing the sensors listed currently: acpitz-0, k10temp-c3, thinkpad-0, radeon-8. But it's not just that the sensor from k10temp-c3 is no longer selected, all the other settings I had (like update interval) are gone too. If I can help you to figure this out, please let me know.
This bug still exists, maybe not in the form it originally had back in 2011. The sensors plugin doesn't forget its settings every time I reboot, but it DOES forget its settings every time my computer is hard-reset without a proper shutdown. I can't fix that by simply avoiding a hard reset, because of an unrelated bug I have with QEMU/KVM where my Windows virtual machine freezes my computer on shutdown. I've narrowed it down a lot, though. Here are the details: -If I shut down cleanly, it remembers its settings. -If my computer hangs and must be manually shut down, every setting in the entire plugin (not just the sensors itself but also update interval, etc.) will be completely forgotten. -Even if I fully log out of XFCE and just have lightdm running a login prompt at the time of the freeze, it STILL forgets its settings on that freeze & hard reset. The only other panel applet I'm running that has a similar bug is the whisker-menu. It doesn't forget all its settings on a hard reset, but it does forget its icon. However, it doesn't forget any other settings, and unlike with the sensors plugin, logging out of XFCE before the freeze/reset actually does prevent it from forgetting. That's a huge relief, because dealing with GNOME's absolutely horrible file chooser is much worse than reconfiguring the sensors.
(In reply to Jimi Bove from comment #36) OK, accepted.
Fixed with commit f9904f1. Hopefully you will try more than 6 years later.