Am Freitag 04 November 2005 09:22 schrieb Jochen Schulz:
> execve("/etc/init.d/openct", ["/etc/init.d/openct", "restart"], [/* 39 vars
> */]) = 0 [pid 14599] execve("/usr/sbin/openct-control",
> ["/usr/sbin/openct-control", "shutdown"], [/* 37 vars */]) = 0 [pid 14600]
> execve("/bin/sleep", ["sleep", "1"], [/* 37 vars */]) = 0 [pid 14603]
> execve("/usr/sbin/openct-control", ["/usr/sbin/openct-control", "init"],
> [/* 37 vars */]) = 0 [pid 14604] execve("/usr/sbin/ifdhandler",
> ["/usr/sbin/ifdhandler", "-H", "egate", "/proc/bus/usb/1/5"], [/* 37 vars
> */]) = 0thanks, that clearly shows openct-control hands the wrong parameter to ifdhandler. > ~# dpkg -l | grep libusb > ii libusb-0.1-4 0.1.10a-22 userspace USB programming library that must be unstable or testing, on my debian sarge server I have an older version. > > the linux code in openct uses: > > snprintf(device, sizeof(device), > > "/proc/bus/usb/%s/%s", > > bus->dirname, dev->filename); > > to set the file name. so most likely your libusb is broken. > > if you can confirm that, please report it to libusb, but > > keep me cc:'ed. > > Hm, don't know. Please prod me in the right direction. :) we need to reassign this bug: old versions of libusb return as filename and dirname the filename and dirname in /proc/bus/usb/ so that is fine. the new version returns a string with the same integer, but not with the proper formatting, so it is a libusb API breakage, and I think it was not intended to break openct and other applications. Regards, Andreas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
