Bug#382195: Offer of Assistance
* Dominique Dumont <[EMAIL PROTECTED]> [2007-02-02 09:41]: > The description should explain a little bit what is MTP. > > Description: Media Transfer Protocol (MTP) library > > A library for communicating with MTP aware devices. MTP (Media > Transfer Protocol) is necessary to comunicate with some USB portable > devices like mp3 players, video players or digital camera. > . > While some portable device will use USB mass storage protocol or PTP > (picture transfer protocol), some device can only communicate with > MTP. [ is this the place to add a wikipedia link? > http://en.wikipedia.org/wiki/Media_Transfer_Protocol ] > . > Homepage: http://libmtp.sourceforge.net/ > > > Note: > - I did not cut and paste wikipedia text to avoid GNU FDL licence > problem > - the second part of the description may be better suited to a README > or man page. Your choice. Thanks for your suggestion. I am using the text above with minor changes. Your contribution is acknowledged in debian/changelog (see version 0.1.3-2 of the packages in the usual repository [1]). I repeated the same description for all packages (libmtp5, libmtp-dev, libmtp-doc, and mtp-tools) with a paragraph "This package contains [...]" specific to each package. I think that the Wikipedia link is a good idea, although it may not be a common practice in Debian. Let us see how the other developers will react. The package seems to be in a good shape. I will upload it to unstable soon. Thanks to everybody who contributed. -- Rafael [1] http://people.debian.org/~rafael/libmtp/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
Rafael Laboissiere <[EMAIL PROTECTED]> writes: > In particular, if you have suggestions on how to improve the > packages descriptions, I will be grateful. The description should explain a little bit what is MTP. Description: Media Transfer Protocol (MTP) library A library for communicating with MTP aware devices. MTP (Media Transfer Protocol) is necessary to comunicate with some USB portable devices like mp3 players, video players or digital camera. . While some portable device will use USB mass storage protocol or PTP (picture transfer protocol), some device can only communicate with MTP. [ is this the place to add a wikipedia link? http://en.wikipedia.org/wiki/Media_Transfer_Protocol ] . Homepage: http://libmtp.sourceforge.net/ Note: - I did not cut and paste wikipedia text to avoid GNU FDL licence problem - the second part of the description may be better suited to a README or man page. Your choice. HTH -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
* Sean Kellogg <[EMAIL PROTECTED]> [2007-02-01 09:12]: > Not sure what to do about the man pages. These tools are all very tiny and > not exactly used for much other than testing your libmtp install. What if > one man page were written with just a very general explenation of how to use > the tools and then use that as the man page for all of them? I feel like > this is done with other packages that have a bunch of tiny binaries. I uploaded a new version of the package to my usual apt-getable repository [1]. There is now a generic man page called mtp-tools.1, which all the other man pages link to. Jean Parpaillon offered me his work, so I am "adopting" the package. I will upload it to unstable soon, unless there are big objections. In particular, if you have suggestions on how to improve the packages descriptions, I will be grateful. > Is audio the right group? I've alwasy been confused by how udev OUGHT to > work, so I'll defer to experts, but it seems to me that having access to > the audio device on the system is different than having the ability to > write to a usb device. I set mine to plugdev, only because it seems to > have to do with people who 'plug' things in. But, like I said, I have no > idea how this is supposed to work. Perhaps the policy says something? I guess that the Policy mention this. The base-passwd package has a document [2] which should be authoritative on these matters. It reads: === audio This group can be used locally to give a set of users access to an audio device. [...] plugdev Members of this group can mount removable devices in limited ways via pmount without a matching entry in /etc/fstab. This is useful for local users who expect to be able to insert and use CDs, USB drives, and so on. Since pmount always mounts with the nodev and nosuid options and applies other checks, this group is not intended to be root-equivalent in the ways that the ability to mount filesystems might ordinarily allow. Implementors of semantics involving this group should be careful not to allow root-equivalence. === Neither of the above groups suit perfectly the MTP devices. I would happily use any of them in the libmtp package. What do the others think? [N.B.: If you are in the Cc: list and do not wish to receive the followups, please tell me.] -- Rafael [1] http://people.debian.org/~rafael/libmtp/ [2] /usr/share/doc/base-passwd/users-and-groups.txt.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
On Thursday 01 February 2007 03:57:26 am you wrote: > Indeed, adding a mtp-tools package was straightforward. See [1]. Great. Package installed fine and works perfectly. Not sure what to do about the man pages. These tools are all very tiny and not exactly used for much other than testing your libmtp install. What if one man page were written with just a very general explenation of how to use the tools and then use that as the man page for all of them? I feel like this is done with other packages that have a bunch of tiny binaries. > I also fixed a problem with the udev rules file. The most recent > debian/changelog entry reads: > > libmtp (0.1.3-0.2) unstable; urgency=low > > * Non-maintainer upload > * Created package mtp-tools containing the programs distributed in the > examples directory > * debian/control: Added my name to Uploaders > * debian/rules: > - Clean files libmtp.rules, libmtp.fdi, and libmtp.usermap generated > at build time, such that they do not appear in the diff.gz > - Instead of installing debian/libmtp.rules, change the libmtp.rules > generated at build time to follow the Debian standards (MODE="660", > GROUP="audio") Is audio the right group? I've alwasy been confused by how udev OUGHT to work, so I'll defer to experts, but it seems to me that having access to the audio device on the system is different than having the ability to write to a usb device. I set mine to plugdev, only because it seems to have to do with people who 'plug' things in. But, like I said, I have no idea how this is supposed to work. Perhaps the policy says something? -Sean -- Sean Kellogg e: [EMAIL PROTECTED] w: http://blog.probonogeek.org/ So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
* Rafael Laboissiere <[EMAIL PROTECTED]> [2007-02-01 12:02]: > * Sean Kellogg <[EMAIL PROTECTED]> [2007-01-31 12:51]: > > As a final thought, it would be great to get a package that includes all of > > the example tools that are distributed by upstream... things like > > mtp-detect, and so on. Any change you could put together a "mtp-tools" > > package? > > This is a good idea and creating the new mtp-tools package is a no-brainer. Indeed, adding a mtp-tools package was straightforward. See [1]. I also fixed a problem with the udev rules file. The most recent debian/changelog entry reads: libmtp (0.1.3-0.2) unstable; urgency=low * Non-maintainer upload * Created package mtp-tools containing the programs distributed in the examples directory * debian/control: Added my name to Uploaders * debian/rules: - Clean files libmtp.rules, libmtp.fdi, and libmtp.usermap generated at build time, such that they do not appear in the diff.gz - Instead of installing debian/libmtp.rules, change the libmtp.rules generated at build time to follow the Debian standards (MODE="660", GROUP="audio") -- Rafael Laboissiere <[EMAIL PROTECTED]> Thu, 1 Feb 2007 12:04:54 +0100 > However, in order to be Policy-compliant we will have to provide man pages > for all those commands. Painful... Lintian yells several times when checking the package. I still have to fix this. -- Rafael [1] http://people.debian.org/~rafael/libmtp/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
* Sean Kellogg <[EMAIL PROTECTED]> [2007-01-31 12:51]: > On Wednesday 31 January 2007 09:50:58 am Rafael Laboissiere wrote: > > Notice that the binary package is now called libmtp5. > > It's great to see someone who knows what they are doing pick this up and run > with it. However, I wonder if naming the binary package after the so name is > the right course of action. > > I refer you to the following post on the libmtp mailing list: > http://sourceforge.net/mailarchive/forum.php?thread_id=31351176&forum_id=48918 > > While obviously a joke, I don't know if upstream has decided on a > consistent so name, er, strategy. Would it be better to just keep the > binary package as libmtp so that end users don't have to hunt around for > the correct package should upstream continue to be a moving target? Well, in the libmtp mailing list post you refer above, the developers seem to be correctly coping with the SONAME now. It should not be a problem in the future. In any event, calling the binary package libmtp is against Policy: http://www.debian.org/doc/debian-policy/ch-sharedlibs.html http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg > As a final thought, it would be great to get a package that includes all of > the example tools that are distributed by upstream... things like > mtp-detect, and so on. Any change you could put together a "mtp-tools" > package? This is a good idea and creating the new mtp-tools package is a no-brainer. However, in order to be Policy-compliant we will have to provide man pages for all those commands. Painful... -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
* Ana Guerrero <[EMAIL PROTECTED]> [2007-02-01 07:14]: > On Wed, Jan 31, 2007 at 06:50:58PM +0100, Rafael Laboissiere wrote: > > It is impressive how long this ITP has stayed open, how long it is taking > > to get a sponsor for this package, and how many people have already > > commented on this bug report. > > > > hey, 5 months is not so much in Debian time ;) You are right, unfortunately... > I do not have real interest in the package, i was willing to sponsor it > to get libmtp support in amarok, so i think the best here is you work > with Jean: sponsoring, co-maintaining or whathever you like better. > > If you want to upload his current package (after update it) is fine with > me, but i would ask you try to talk with Jean first. Well, I put Jean in the Cc: of my message. He should have received it, unless: > P.S: for some reason, Rafael's mail never reached my inbox, but Sam's mail > did, so i had to get Rafael's mail thru the BTS. Rafael, could you check > your logs? I would like to know if it was a problem in my side. Thanks! I did not receive any failure notification back. The only trace I have here is in /var/log/exim4/mainlog: 2007-01-31 18:51:04 1HCJbm-0003NS-O5 => [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4] 2007-01-31 18:51:04 1HCJbm-0003NS-O5 -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4] 2007-01-31 18:51:04 1HCJbm-0003NS-O5 -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4] 2007-01-31 18:51:04 1HCJbm-0003NS-O5 -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4] 2007-01-31 18:51:04 1HCJbm-0003NS-O5 -> [EMAIL PROTECTED] R=smarthost T=remote_smtp_smarthost H=smtp.free.fr [212.27.48.4] 2007-01-31 18:51:04 1HCJbm-0003NS-O5 Completed -- Rafael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
Sean Kellogg <[EMAIL PROTECTED]> writes: > Would it be better to just keep the binary package as libmtp so that > end users don't have to hunt around for the correct package should > upstream continue to be a moving target? The problem is that between end user and libmtp, you have an application (like amarok for instance) which expects a specific soname. Your proposal would need amarok to depend on libmtp version B while other package may still require version B. In other words, you'd need to synchronise the release of new version of libmtp with new version of *all* application that use libmtp. This would be a nightmare. HTH -- Dominique Dumont "Delivering successful solutions requires giving people what they need, not what they want." Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
Hi Rafael (and others), On Wed, Jan 31, 2007 at 06:50:58PM +0100, Rafael Laboissiere wrote: > It is impressive how long this ITP has stayed open, how long it is taking to > get a sponsor for this package, and how many people have already commented > on this bug report. > hey, 5 months is not so much in Debian time ;) > That said, I am planing to sponsor libmtp soon. I built it using the > upstream version 0.1.3 and it is available in [1]. It is based on the > original package by Jean Parpaillon, available at mentors.d.o. I fixed the > following Lintian warnings: > > W: libmtp: package-name-doesnt-match-sonames libmtp5 > W: libmtp: package-contains-upstream-install-documentation > usr/share/doc/libmtp/INSTALL.gz > > Notice that the binary package is now called libmtp5. > > I compiled gnomad2 2.8.11 against this package and it correctly recognize's > the Creative Zen MicroPhoto player [2]. > > If there are no objections, I will upload soon the package to unstable. > I interchanged some mails with Jean (and we talked through IRC) because i reviewed Jean's package and asked him to do some changes, but he was busy so we decided to postpone work in the package until he has time for it. We should have updated this information in the BTS, tho. I do not have real interest in the package, i was willing to sponsor it to get libmtp support in amarok, so i think the best here is you work with Jean: sponsoring, co-maintaining or whathever you like better. If you want to upload his current package (after update it) is fine with me, but i would ask you try to talk with Jean first. Ana P.S: for some reason, Rafael's mail never reached my inbox, but Sam's mail did, so i had to get Rafael's mail thru the BTS. Rafael, could you check your logs? I would like to know if it was a problem in my side. Thanks! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
On Wednesday 31 January 2007 09:50:58 am Rafael Laboissiere wrote: > Notice that the binary package is now called libmtp5. It's great to see someone who knows what they are doing pick this up and run with it. However, I wonder if naming the binary package after the so name is the right course of action. I refer you to the following post on the libmtp mailing list: http://sourceforge.net/mailarchive/forum.php?thread_id=31351176&forum_id=48918 While obviously a joke, I don't know if upstream has decided on a consistent so name, er, strategy. Would it be better to just keep the binary package as libmtp so that end users don't have to hunt around for the correct package should upstream continue to be a moving target? As a final thought, it would be great to get a package that includes all of the example tools that are distributed by upstream... things like mtp-detect, and so on. Any change you could put together a "mtp-tools" package? -Sean -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
It is impressive how long this ITP has stayed open, how long it is taking to get a sponsor for this package, and how many people have already commented on this bug report. That said, I am planing to sponsor libmtp soon. I built it using the upstream version 0.1.3 and it is available in [1]. It is based on the original package by Jean Parpaillon, available at mentors.d.o. I fixed the following Lintian warnings: W: libmtp: package-name-doesnt-match-sonames libmtp5 W: libmtp: package-contains-upstream-install-documentation usr/share/doc/libmtp/INSTALL.gz Notice that the binary package is now called libmtp5. I compiled gnomad2 2.8.11 against this package and it correctly recognize's the Creative Zen MicroPhoto player [2]. If there are no objections, I will upload soon the package to unstable. -- Rafael [1] http://people.debian.org/~rafael/libmtp/ [2] http://people.debian.org/~rafael/gnomad2/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#382195: Offer of Assistance
Hey folks, I noticed that this package hasn't really gone anywhere in the past few months. I have a shiny new iRiver my GF bought me for Christmas, and it's going to break my heart if I can't use it because a package is stuck due to lack of interest. I haven't done much with Debian packages, but I'm happy to learn and help out if it means this package can get into unstable sooner. Is there something I can do? I noticed the list of comments from James Westby... I can follow up on some of those if there is need. -Sean -- Sean Kellogg c: 831.818.6940 e: [EMAIL PROTECTED] w: http://blog.probonogeek.org/ So, let go ...Jump in ...Oh well, what you waiting for? ...it's all right ...'Cause there's beauty in the breakdown
