> head -2 /lib/udev/rules.d/69-libmtp.rules Unable to open ~/.mtpz-data for reading, MTPZ disabled.# UDEV-style hotplug map for libmtp # Put this file in /etc/udev/rules.d
I can verify. It's hotplug.sh (hotplug.sh.in in tarball) that is generating the .rules As in, the hotplug.sh.in should be fixed :/
Ping! I only found this string at line " LIBMTP_INFO("Unable to open ~/.mtpz-data for reading, MTPZ disabled.");" of /temp/portage/media-libs/libmtp-1.1.6/work/libmtp-1.1.6/src/mtpz.c when compiling. How does it get into the rules ????
I hoped to find a patch there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723701 But Debian didn't find a solution since one month :(
Got the same problem. Worked around it by building libmtp with "-crypt". The "crypt" use flags is the one that enables support for mtpz, and I have no idea what mtpz is. It is also quite annoying that I see this warning when running any of the mtp command, and now it's gone. So - double win. Unless someone knows of what the use case for mtpz is (quick Google says it's for zune? really?), I would suggest you make "-crypt" the default. Or even better, --disable-mtpz unconditionally.
ArchLinux fixes this by sed, later in the process, like in end of src_install() Like so: https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/libmtp&id=b250f0917eb60e91e477a3733fdd71c786e5b7aa + # fix broken udev rule + sed -i "/^Unable to open/d" ${pkgdir}/usr/lib/udev/rules.d/69-libmtp.rules So similar patch could be created for the .ebuild, however it's nothing upstreamable... The script creating the rule in the first place should be fixed... But I'd settle with .ebuild fix for this one for now
Fixed in tree for 1.1.6, created 1.1.6-r1 for ~arch and -9999