Re: RFS: djmount
On Dom, 09 Ago 2009, Ben Finney wrote: You mean, the list should lie about the author of messages so that when you use the “reply to author” feature, it doesn't go only to the author? No, that's not a viable option. It doesn't need to change the author, only the reply to field. And yes, I've read reply to considered harmful. Spare your links. And I'm not advocating it, I'm just saying what would be changed. -- Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
Eduardo M KALINOWSKI edua...@kalinowski.com.br writes: On Dom, 09 Ago 2009, Ben Finney wrote: You mean, the list should lie about the author of messages so that when you use the “reply to author” feature, it doesn't go only to the author? No, that's not a viable option. It doesn't need to change the author, only the reply to field. Which is a field to be set only by the message author, so is a lie if set by the list. And yes, I've read reply to considered harmful. Spare your links. Okay. People can find RFC 2822 for themselves I guess. -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
On Sat, Aug 08, 2009 at 08:01:28PM +0200, Dario Minnucci (midget) wrote: Dear mentors, I am looking for a sponsor for my package djmount. Hi Dario, Thanks for making this package, I have previously used djmount to test libupnp. The upstream package contains private copies of libtalloc and pupnp, both of which are already included in Debian in their own right (libtalloc1 and libupnp3). Perhaps you could consider specifying --with-external-libupnp and --with-external-talloc in your ./configure. If there are any changes you need to libupnp3, I would be pleased to receive suggestions in the BTS. IANADD so I can't upload for you, sorry. Nick -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
Hi Nick, Thanks for your quick answer. Nick Leverton wrote: On Sat, Aug 08, 2009 at 08:01:28PM +0200, Dario Minnucci (midget) wrote: Dear mentors, I am looking for a sponsor for my package djmount. Hi Dario, Thanks for making this package, I have previously used djmount to test libupnp. The upstream package contains private copies of libtalloc and pupnp, both of which are already included in Debian in their own right (libtalloc1 and libupnp3). Perhaps you could consider specifying --with-external-libupnp and --with-external-talloc in your ./configure. If there are any changes you need to libupnp3, I would be pleased to receive suggestions in the BTS. IANADD so I can't upload for you, sorry. I'll try to rebuild it using libs included in Debian. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? Cheers. -- Dario Minnucci (midget) deb...@midworld.net Phone: +34 902021030 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = 62FF F60F CE79 9CE4 EBA8 523F FC84 1B2D 82C8 B711 signature.asc Description: OpenPGP digital signature
Re: RFS: djmount
On Mon, Aug 10, 2009 at 12:31 AM, Dario Minnucci (midget)deb...@midworld.net wrote: Nick Leverton wrote: The upstream package contains private copies of libtalloc and pupnp, both of which are already included in Debian in their own right (libtalloc1 and libupnp3). Perhaps you could consider specifying --with-external-libupnp and --with-external-talloc in your ./configure. If there are any changes you need to libupnp3, I would be pleased to receive suggestions in the BTS. IANADD so I can't upload for you, sorry. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? By far the best is to talk to upstream and get them to remove the embedded code copies along with any patches needed to build properly. Personally I wouldn't bother stripping the embedded code copies from the orig.tar.gz. I would add 'rm -rf libupnp talloc' to debian/rules just before the ./configure call so that there is no chance of the package being built against the embedded code copies though. If you do strip the embedded code copies from the orig.tar.gz, it is inappropriate to add +dfsgX to the upstream version number because you aren't stripping for DFSG-related reasons. +dsX for Debian Source is what the devref or policy recommends for non-DFSG repacking IIRC, please read about that though, I could be wrong. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Wise schrieb: On Mon, Aug 10, 2009 at 12:31 AM, Dario Minnucci (midget)deb...@midworld.net wrote: Nick Leverton wrote: The upstream package contains private copies of libtalloc and pupnp, both of which are already included in Debian in their own right (libtalloc1 and libupnp3). Perhaps you could consider specifying --with-external-libupnp and --with-external-talloc in your ./configure. If there are any changes you need to libupnp3, I would be pleased to receive suggestions in the BTS. IANADD so I can't upload for you, sorry. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? By far the best is to talk to upstream and get them to remove the embedded code copies along with any patches needed to build properly. ACK. Personally I wouldn't bother stripping the embedded code copies from the orig.tar.gz. I would add 'rm -rf libupnp talloc' to debian/rules just before the ./configure call so that there is no chance of the package being built against the embedded code copies though. Moving would be better, because with this way you are modifying the tarball and then you will mostly have an error on building the package twice. I also do not see any need for it, if it realy builds against the system wide libs. If you do strip the embedded code copies from the orig.tar.gz, it is inappropriate to add +dfsgX to the upstream version number because you aren't stripping for DFSG-related reasons. +dsX for Debian Source is what the devref or policy recommends for non-DFSG repacking IIRC, please read about that though, I could be wrong. I wouldn't prefer this solution. If upstream removes them, everything is nice, if not, he should live with that.. - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp/EvIACgkQ2XA5inpabMeVegCfZVpl+BhV4oRL8s/A+mktvyOg 2EMAn3VGcHzxDKfjemDvqQD9UrXMvjWW =1Wmo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
On Sun, Aug 09, 2009 at 06:31:27PM +0200, Dario Minnucci (midget) wrote: I'll try to rebuild it using libs included in Debian. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? I don't think there's any need to remove and re-package the sources, as these libs are DFGS free enough to be in Debian in their own right. I would say it's adequate for the Debian packaging just to tell configure to use the external libraries and add the appropriate build-deps. Helping upstream to drop the embedded copies could be a separate public service change, if you felt keen enough, but they have already given packagers the choice of which to use through ./configure. Nick -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
Hi again, Patrick Matthäi wrote: Paul Wise schrieb: On Mon, Aug 10, 2009 at 12:31 AM, Dario Minnucci (midget)deb...@midworld.net wrote: Nick Leverton wrote: The upstream package contains private copies of libtalloc and pupnp, both of which are already included in Debian in their own right (libtalloc1 and libupnp3). Perhaps you could consider specifying --with-external-libupnp and --with-external-talloc in your ./configure. If there are any changes you need to libupnp3, I would be pleased to receive suggestions in the BTS. IANADD so I can't upload for you, sorry. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? By far the best is to talk to upstream and get them to remove the embedded code copies along with any patches needed to build properly. ACK. Ok, I'll try to talk to upstream about this issue. Anyway, I'm rebuilding it against libs shipped in Debian. Personally I wouldn't bother stripping the embedded code copies from the orig.tar.gz. I would add 'rm -rf libupnp talloc' to debian/rules just before the ./configure call so that there is no chance of the package being built against the embedded code copies though. Moving would be better, because with this way you are modifying the tarball and then you will mostly have an error on building the package twice. Is there any convention to do this 'moving'? I also do not see any need for it, if it realy builds against the system wide libs. OK If you do strip the embedded code copies from the orig.tar.gz, it is inappropriate to add +dfsgX to the upstream version number because you aren't stripping for DFSG-related reasons. +dsX for Debian Source is what the devref or policy recommends for non-DFSG repacking IIRC, please read about that though, I could be wrong. I wouldn't prefer this solution. If upstream removes them, everything is nice, if not, he should live with that.. I prefer not to touch sources, if it's possible. Cheers and thanks for quick answers. PS: Shall I write back to the one who answers my questions or directly back to the list, or both? -- Dario Minnucci (midget) deb...@midworld.net Phone: +34 902021030 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = 62FF F60F CE79 9CE4 EBA8 523F FC84 1B2D 82C8 B711 signature.asc Description: OpenPGP digital signature
Re: RFS: djmount
On Mon, Aug 10, 2009 at 4:10 AM, Dario Minnucci (midget)deb...@midworld.net wrote: PS: Shall I write back to the one who answers my questions or directly back to the list, or both? http://www.debian.org/MailingLists/#codeofconduct -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
Paul Wise wrote: On Mon, Aug 10, 2009 at 4:10 AM, Dario Minnucci (midget)deb...@midworld.net wrote: PS: Shall I write back to the one who answers my questions or directly back to the list, or both? http://www.debian.org/MailingLists/#codeofconduct * When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. I was wondering that just because when you hit 'Reply' automacally sets: To: who answers Cc: debian-mentors@lists.debian.org Ok, I'll get use to this. Thanks. -- Dario Minnucci (midget) deb...@midworld.net Phone: +34 902021030 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = 62FF F60F CE79 9CE4 EBA8 523F FC84 1B2D 82C8 B711 signature.asc Description: OpenPGP digital signature
Re: RFS: djmount
Nick Leverton wrote: On Sun, Aug 09, 2009 at 06:31:27PM +0200, Dario Minnucci (midget) wrote: I'll try to rebuild it using libs included in Debian. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? I don't think there's any need to remove and re-package the sources, as these libs are DFGS free enough to be in Debian in their own right. I would say it's adequate for the Debian packaging just to tell configure to use the external libraries and add the appropriate build-deps. That's the solution I will use. Thanks. Helping upstream to drop the embedded copies could be a separate public service change, if you felt keen enough, but they have already given packagers the choice of which to use through ./configure. Using any of these options --with-external-libupnp OR --with-external-talloc, distclean fails. I fix it, but I will report it to upstream. Cheers. -- Dario Minnucci (midget) deb...@midworld.net Phone: +34 902021030 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = 62FF F60F CE79 9CE4 EBA8 523F FC84 1B2D 82C8 B711 signature.asc Description: OpenPGP digital signature
Re: RFS: djmount
On Sun, Aug 09, 2009 at 08:18:27PM +0200, Patrick Matth??i wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Wise schrieb: On Mon, Aug 10, 2009 at 12:31 AM, Dario Minnucci (midget)deb...@midworld.net wrote: Nick Leverton wrote: The upstream package contains private copies of libtalloc and pupnp, both of which are already included in Debian in their own right (libtalloc1 and libupnp3). Perhaps you could consider specifying --with-external-libupnp and --with-external-talloc in your ./configure. If there are any changes you need to libupnp3, I would be pleased to receive suggestions in the BTS. IANADD so I can't upload for you, sorry. PS: Shall I remove from the original sources 'libupnp' and 'talloc' and rename the package to be DFSG, or it's OK to distribute upstream sources like that ? By far the best is to talk to upstream and get them to remove the embedded code copies along with any patches needed to build properly. ACK. Personally I wouldn't bother stripping the embedded code copies from the orig.tar.gz. I would add 'rm -rf libupnp talloc' to debian/rules just before the ./configure call so that there is no chance of the package being built against the embedded code copies though. Moving would be better, because with this way you are modifying the tarball and then you will mostly have an error on building the package twice. AIUI, dpkg-source has no problem with files that are present in the .orig.tar.gz but are missing in the actual source directory - it just ignores the missing file and goes on. Isn't this the conventional way to deal with autotools-generated configure, Makefile, etc? So, IMHO, just removing them in the configure target should be fine. I also do not see any need for it, if it realy builds against the system wide libs. As Paul Wise said, the removing would be a good idea if the packager is not completely certain that the upstream build system will never, ever, under any circumstances, use the bundled source even if it is told to use the external libraries. Consider a build system that goes like, Oh, okay, you told me to use the external library, but something changed, I can't quite locate the header file, or this definition is no longer available, or something just messed up... no matter, if I can't use the external library, I'll just use my own source, I *know* things will build just fine this way!. Honest, I've seen upstream sources that did that. G'luck, Peter -- Peter Pentchev r...@ringlet.netr...@space.bgr...@freebsd.org PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If wishes were fishes, the antecedent of this conditional would be true. pgp0tX7hZmew6.pgp Description: PGP signature
Re: RFS: djmount
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Pentchev schrieb: As Paul Wise said, the removing would be a good idea if the packager is not completely certain that the upstream build system will never, ever, under any circumstances, use the bundled source even if it is told to use the external libraries. Consider a build system that goes like, Oh, okay, you told me to use the external library, but something changed, I can't quite locate the header file, or this definition is no longer available, or something just messed up... no matter, if I can't use the external library, I'll just use my own source, I *know* things will build just fine this way!. Honest, I've seen upstream sources that did that. Isn't this something the maintainer should check before he uploads his package? - -- /* Mit freundlichem Gruß / With kind regards, Patrick Matthäi GNU/Linux Debian Developer E-Mail: pmatth...@debian.org patr...@linux-dev.org Comment: Always if we think we are right, we were maybe wrong. */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkp/NGAACgkQ2XA5inpabMeKlwCcClIpQkiinlVPm+4TxXSvr1Zk eOwAn36P7dtFpg4cHeIhAxxTMYQdw7Wz =Rt4n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: djmount
Dario Minnucci (midget) deb...@midworld.net writes: * When replying to messages on the mailing list, do not send a carbon copy (CC) to the original poster unless they explicitly request to be copied. I was wondering that just because when you hit 'Reply' automacally sets: To: who answers Cc: debian-mentors@lists.debian.org That's what happens when you use your mail program's “reply to all” command. To reply to a mailing list, use the “reply to list” command. If your mail program doesn't have such a feature, you have a couple of options: switch to a mail program that does have that feature (e.g. Kmail, Mutt, Gnus, loads of others) or manually edit the fields each time you reply to the list. You should also encourage your existing mail program's vendor to add the feature. For Icedove or Thunderbird, this is requested in Mozilla's bug#45715 URL:https://bugzilla.mozilla.org/show_bug.cgi?id=45715 which is reportedly fixed in version 3.0. -- \ “If you pick up a starving dog and make him prosperous, he will | `\ not bite you. This is the principal difference between a dog | _o__)and a man.” —Mark Twain, _Pudd'n'head Wilson_ | Ben Finney pgpMhSUFAR0oZ.pgp Description: PGP signature
Re: RFS: djmount
Hi Ben, Ben Finney wrote: [...] If your mail program doesn't have such a feature, you have a couple of options: switch to a mail program that does have that feature (e.g. Kmail, Mutt, Gnus, loads of others) or manually edit the fields each time you reply to the list. You should also encourage your existing mail program's vendor to add the feature. For Icedove or Thunderbird, this is requested in Mozilla's bug#45715 URL:https://bugzilla.mozilla.org/show_bug.cgi?id=45715 which is reportedly fixed in version 3.0. Thanks for the extended info. A third option could be configuring the list to send back to the list on replies. :) But I will use the second one until Icedove implemets the first. Regards. -- Dario Minnucci (midget) deb...@midworld.net Phone: +34 902021030 | Fax: +34 902024417 | Support: +34 80745 Key fingerprint = 62FF F60F CE79 9CE4 EBA8 523F FC84 1B2D 82C8 B711 signature.asc Description: OpenPGP digital signature
Re: RFS: djmount
Dario Minnucci (midget) deb...@midworld.net writes: A third option could be configuring the list to send back to the list on replies. :) You mean, the list should lie about the author of messages so that when you use the “reply to author” feature, it doesn't go only to the author? No, that's not a viable option. But I will use the second one until Icedove implemets the first. Thank you. -- \“I installed a skylight in my apartment. The people who live | `\ above me are furious!” —Steven Wright | _o__) | Ben Finney pgpQUSt9ILrw1.pgp Description: PGP signature
