[Pkg-wmaker-commits] [wmhdplop] 13/40: debian/patches/find-disk-device.patch: Use realpath instead of symlink to find device (Closes: #657882).

[Doug Torrance]

This is an automated email from the git hooks/post-receive script.

dtorrance-guest pushed a commit to branch master
in repository wmhdplop.

commit e6123966c8c680c169aaadc9d89f1766b68e7181
Author: Doug Torrance <dtorrance at monmouthcollege.edu>
Date:   Mon Aug 11 00:59:59 2014 -0500

    debian/patches/find-disk-device.patch: Use realpath instead of symlink to find
    device (Closes: #657882).
---
 debian/patches/find-disk-device.patch | 60 +++++++++++++++++++++++++++++++++++
 debian/patches/series                 |  1 +
 2 files changed, 61 insertions(+)

diff --git a/debian/patches/find-disk-device.patch b/debian/patches/find-disk-device.patch
new file mode 100644
index 0000000..2559b02
--- /dev/null
+++ b/debian/patches/find-disk-device.patch
@@ -0,0 +1,60 @@
+Description: Fails to find any disk device after /run transition
+ Dear Maintainer,
+ .
+ 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.
+Author: Andre Beck <beck at ibh.de>
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657882
+Last-Update: 2014-08-11
+
+--- a/devnames.c
++++ b/devnames.c
+@@ -186,9 +186,10 @@
+ 
+   if (lstat(devname,&stat_buf)) { BLAHBLAH(1,perror(devname)); return -1; }
+   if (S_ISLNK(stat_buf.st_mode)) {
+-    char lname[512];
+-    int n = readlink(devname, lname, 511); lname[n] = 0;
+-    snprintf(devname,512,"/dev/%s",stripdev(lname));
++    devname_ = realpath(devname, NULL);
++    if(!devname_) { BLAHBLAH(1,perror(devname)); return -1; }
++    strncpy(devname, devname_, 512); devname[511] = 0;
++    free(devname_);
+     if (stat(devname,&stat_buf)) { BLAHBLAH(1,perror(devname)); return -1; }
+   }
+   if (!S_ISBLK(stat_buf.st_mode)) {
diff --git a/debian/patches/series b/debian/patches/series
index 23862e8..47dc012 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 fix-ftbfs-gcc-4.7-667415.patch
 ldflags-to-ldadd.patch
+find-disk-device.patch

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-wmaker/wmhdplop.git