In some future release, glibc's <sys/types.h> will not include
<sys/sysmacros.h> anymore. As of 2.25, it still does, but you get
deprecation warnings if you use the macros without including
<sys/sysmacros.h>
Gentoo original bug: https://bugs.gentoo.org/show_bug.cgi?id=604296
After a while, the procstats fields will overflow the
signed int field and the hd leds will be permanently on.
Use long instead of int for these counters
Gentoo original bug: https://bugs.gentoo.org/show_bug.cgi?id=325615
In particular, the following:
wmhdplop.c:451:96: warning: operation on ‘dl->touched_w’ may be undefined
[-Wsequence-point]
wmhdplop.c:980:44: warning: ignoring return value of ‘seteuid’, declared with
attribute warn_unused_result [-Wunused-result]
procstat.c:73:19: warning: variable ‘in_our_disk’ set but not used
[-Wunused-but-set-variable]
dockapp_imlib2.c:311:85: warning: unused parameter ‘prefs’ [-Wunused-parameter]
gkrellm_hdplop.c:187:40: warning: unused parameter ‘widget’
[-Wunused-parameter]
https://sources.debian.net/src/wmhdplop/0.9.9-5/debian/patches/
fix_compiler_warnings.patch/
In particular, fix the following errors and warnings:
configure.ac:2: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are
deprecated. For more info, see:
configure.ac:2: http://www.gnu.org/software/automake/manual/automake.html
#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
Makefile.am:21: error: linker flags such as '-shared' belong in
'gkhdplop_so_LDFLAGS'
./configure: line 2910: syntax error near unexpected token `build_old_libs,'
./configure: line 2910: ` _LT_DECL(build_old_libs, enable_static, 0,'
./configure: line 2908: syntax error near unexpected token
`build_libtool_libs,'
./configure: line 2908: ` _LT_DECL(build_libtool_libs, enable_shared, 0,
https://sources.debian.net/src/wmhdplop/0.9.9-5/debian/patches/
modernize_autotools.patch/
Patch by Andre Beck <beck@ibh.de> to fix Debian bug #657882.
After the recent /run transition, which also finally turned /etc/mtab into
a symlink to /proc/mounts, *hdplop (both incarnations) may fail to find a
single disk device automatically. This is likely due to the root device
now being exposed as mounted on /dev/disk/by-uuid/$UUID whereas the
former /etc/mtab as written by mount still contained a device name as
taken from /etc/fstab, which in my case could be parsed by *hdplop. It's
unclear if this wouldn't have hit other environments earlier depending
on their fstab contents, I just assume for now that I'm one of the
remaining handful of users of this tool ;)
The fundamental issue is of course the rather crude code in devnames.c's
device_id_from_name() which tries to manually resolve device symlinks,
but cannot possibly work with any symlink except those located directly
in /dev - symlinks in subdirectories of /dev will fail.
Impact on wmhdplop: Doesn't start except when called explicitely with
some "-d /dev/sda" or such option.
Impact on gkrellm-hdplop: Starts but is dazed and confused, leaving a
black window in gkrellm. Clicking on the black window will then crash
gkrellm, as it hits an assertion that the device list cannot be empty.
I've prepared a small patch that makes *hdplop work again for me, the
patch replaces the broken manual symlink resolving by a simple call
to realpath(3), hopefully not breaking other stuff. I refrained from
doing any more changes to the code, even though it looks like it needs
some love. Upstream seems to have lost interest five years ago, though...
So, without much further ado, here's my crude fix:
Don't look too closely, specifically on the strncpy(3) stuff, but I felt
this is still better than abusing snprintf(3) like the original code does
some lines above, and as I said, starting to really fix things here looks
like a bottomless pit...
Thanks,
Andre.
https://bugs.debian.org/657882https://sources.debian.net/src/wmhdplop/0.9.9-5/debian/patches/
find-disk-device.patch/
