FS#40122 - [libmtp] should be compiled with --disable-mtpz
Attached to Project:
Arch Linux
Opened by Kovid Goyal (kovidgoyal) - Monday, 28 April 2014, 06:14 GMT
Last edited by Antonio Rojas (arojas) - Monday, 06 July 2015, 17:23 GMT
Opened by Kovid Goyal (kovidgoyal) - Monday, 28 April 2014, 06:14 GMT
Last edited by Antonio Rojas (arojas) - Monday, 06 July 2015, 17:23 GMT
|
Details
Description: The libmtp package in Arch should be compiled
with --disable-mtpz
MTPZ refers to support for the Zune. However, in order for it to actually work one needs to posses a actual Zune key. Moreover, libmtp checks for this key on every initialization and prints an error message about it to stdout: Unable to read MTPZ public exponent from ~/.mtpz-data, MTPZ disabled This is annoying as every use of an MTP enabled application spams the console with these messages. It also requires the use of a hack in the current libmtp PKGBUILD to remove this line from the udev rules file. Ideally, there should be two packages in Arch one with mtpz enabled, and one without, so if there are any actual users of the Zune (which seems rather unlikely), then they can install the zune enabled version of libmtp. But the rest of us should not have to suffer in the meantime. Note that in Gentoo one can turn off mtpz support via a useflag. Disabling mtpz also allows dropping the dependency on libgcrypt. I have attached the PKGBUILD I use on my systems with mtpz turned off. Additional info: libmtp-1.1.6-6 Steps to reproduce: |
This task depends upon
Closed by Antonio Rojas (arojas)
Monday, 06 July 2015, 17:23 GMT
Reason for closing: Fixed
Additional comments about closing: libmtp 1.1.9
Monday, 06 July 2015, 17:23 GMT
Reason for closing: Fixed
Additional comments about closing: libmtp 1.1.9
PKGBUILD
Seems like something that should be brought up with upstream, no? If their build system produces garbage, it's a bug.
The rest of this seems only like you're concerned about an uninteresting "error".