Re: Re: RFS: FileZilla3 - GUI ftp client of wxwidgets2.6
Justin Pryzby wrote: > http://lists.debian.org/debian-legal/2003/12/msg00194.html Yep. This too: http://lists.debian.org/debian-devel-announce/2003/12/msg7.html -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFS: FileZilla3 - GUI ftp client of wxwidgets2.6
On Thu, Sep 29, 2005 at 01:34:34PM +0800, Paul Wise wrote: > * debian/copyright needs improvement - who holds copyright? what > are the licencing terms written in the ustream README and source > files? There is a good FAQ about writing these on the lists > somewhere, I forget the URL tho. It might be mentioned in the > debian-mentors FAQ. http://lists.debian.org/debian-legal/2003/12/msg00194.html ? -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: FileZilla3 - GUI ftp client of wxwidgets2.6
On Thu, 2005-09-29 at 13:34 +0800, Paul Wise wrote: > * Any reason for using experimental instead of unstable in the > changelog? Ooops, missed your comment about that. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: RFS: FileZilla3 - GUI ftp client of wxwidgets2.6
Comments: * Delete all the Makefile.in, config.h.in during debian/rules clean, or make otherwise make it so that they are not in the diff.gz * Any reason for using experimental instead of unstable in the changelog? * debian/copyright needs improvement - who holds copyright? what are the licencing terms written in the ustream README and source files? There is a good FAQ about writing these on the lists somewhere, I forget the URL tho. It might be mentioned in the debian-mentors FAQ. * short and long description in debian/control needs improvement. A one line long description is not enough. * debian/rules: remove dh_make cruft and commented out dh_*/dpatch lines * debian/manpage.1: that isn't a real manpage, delete it or write one * debian/menu: fix needs, section and title * why didn't you file an ITP bug before you started packaging and close it in debian/changelog. Please do this now * please register at sponsors.debian.net to make sure this RFS is not forgotten. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: lintian warning native-package-with-dash-version
On Wed, Sep 28, 2005 at 11:33:45PM -0500, Carlo Segre wrote: > On Thu, 29 Sep 2005, kamaraju kusumanchi wrote: > >Q2) should I create a symbolic link gnuplotfortran-0.2.2-1.orig.tar.gz > >which points to gnuplotfortran-0.2.2-1.tar.gz before proceeding with > >dpkg-buildpackage? I see that it is automatically created after > >dpkg-buildpackage step. > > > > You can do that before too, but are you sure that the name is correct? > According to standards, the name should have an underscore rather than the > dash which separates the name from upstream revision number. In addition, > as I mentioned before, you probably need to change the -1 to a .1 to avoid > the lintian error so the proper link should be: I see the problem. The .orig.tar.gz doesn't change for debian releases, so the -1 is translated to nothing for the orig filename. Thus: gnuplotfortran_0.2.2.orig.tar.gz. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian warning native-package-with-dash-version
On Thu, 29 Sep 2005, kamaraju kusumanchi wrote: Hi I am new to packaging and I am trying to package gnuplotfortran whose upstream is located at http://sourceforge.net/projects/gnuplotfortran . The upstream source is called gnuplotfortran-0.2.2-1.tar.bz2 . I downloaded this to /tmp . Then I did tar xjvf /tmp/gnuplotfortran-0.2.2-1.tar.bz2 -C . tar czvf gnuplotfortran-0.2.2-1.tar.gz gnuplotfortran-0.2.2-1/ cd gnuplotfortran-0.2.2-1/ dh_make --copyright lgpl -e [EMAIL PROTECTED] -f \ ../gnuplotfortran-0.2.2-1.tar.gz -l Then I proceeded on doing dpkg-buildpackage etc., At the end I obtained gnuplotfortran_0.2.2-1-1.dsc . But if I do $lintian -i gnuplotfortran_0.2.2-1-1.dsc W: gnuplotfortran source: native-package-with-dash-version N: N: Native packaging should only be used if a piece of software was N: written specifically to be turned into a Debian package. In this case, N: the version number should not contain a debian revision part. N: N: Native source packages are sometimes created by accident. In most N: cases the reason is the location of the original source tarball. N: dpkg-source searches for this in N: ../package_upstream-version.orig.tar.gz. N: Q1) Where am I doing wrong? How can I get rid of this error? I think that this has to do with the -1 in the name of the original tarball. You might consider using the -v 0.2.2.1 option in dh_make to convert this to a compliant version number. The second -1 will still be there in the final package because that is the debian revision. The cause that lintian has suggested does not seem to be your case as you properly identified the source tarball in the dh_make command. Q2) should I create a symbolic link gnuplotfortran-0.2.2-1.orig.tar.gz which points to gnuplotfortran-0.2.2-1.tar.gz before proceeding with dpkg-buildpackage? I see that it is automatically created after dpkg-buildpackage step. You can do that before too, but are you sure that the name is correct? According to standards, the name should have an underscore rather than the dash which separates the name from upstream revision number. In addition, as I mentioned before, you probably need to change the -1 to a .1 to avoid the lintian error so the proper link should be: gnuplotfortran_0.2.2.1.orig.tar.gz and the .dsc file should be gnuplotfortran_0.2.2.1-1.dsc Cheers, Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian warning native-package-with-dash-version
On Thu, Sep 29, 2005 at 12:17:28AM -0400, kamaraju kusumanchi wrote: > Hi > I am new to packaging and I am trying to package gnuplotfortran whose > upstream is located at http://sourceforge.net/projects/gnuplotfortran . > The upstream source is called gnuplotfortran-0.2.2-1.tar.bz2 . I > downloaded this to /tmp . > > Then I did > > tar xjvf /tmp/gnuplotfortran-0.2.2-1.tar.bz2 -C . Doesn't dpkg-source v2 handle bzip? Since June 11, according to the changelog. > tar czvf gnuplotfortran-0.2.2-1.tar.gz gnuplotfortran-0.2.2-1/ > cd gnuplotfortran-0.2.2-1/ > dh_make --copyright lgpl -e [EMAIL PROTECTED] -f \ > ../gnuplotfortran-0.2.2-1.tar.gz -l What if you don't specify -f? > $lintian -i gnuplotfortran_0.2.2-1-1.dsc > W: gnuplotfortran source: native-package-with-dash-version > Q1) Where am I doing wrong? How can I get rid of this error? One way or another you're creating a native package, which this is not. A native package is defined by the lack of a .orig.tar.gz > Q2) should I create a symbolic link gnuplotfortran-0.2.2-1.orig.tar.gz > which points to gnuplotfortran-0.2.2-1.tar.gz before proceeding with > dpkg-buildpackage? I see that it is automatically created after > dpkg-buildpackage step. A symbolic link, or a real link (I guess), or a copy of the file, or a rename. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Thu, 29 Sep 2005, François-Denis Gonthier wrote: On 28 September 2005 14:07, Justin Pryzby wrote: When I make a new upstream package for Erlang, I need to extract the upstream tar.gz file, which is named otp_src_[version].tar.gz, rename the created directory to a Debian friendly name and then make the .orig.tar.gz. Does that count as repackaging? If so I'm clueless as to what I should do to avoid that. YOu should not have to do this every time. The way I have dealt with this issue is the following: 1. make a symbolic link to the original source tarball using the correct Debian name with *_ver.orig.tar.gz 2. untar the original and rename the resulting directory 3. build Debian package in then renamed directory (possibly starting with dh_make) 4. when the next version is released, just download it, make the symbolic link as in (1) and then perform a uupdate inside the previous directory (youcan use the -v option to force a version number if it is not obvious form the tarball name). uupdate will make a new directory with the correct name independent of what is in the tarball 5. better yet, make a watch file and run uscan. if you choose to execute uupdate on the downloaded tarball, it will automagically perform steps in (4) as long as the version number is parseable form the original traball name. The renaming process only needs to be done once and you cactually don't have to re-tar the source. HTH Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre
Re: duplicate library code in a package
On Thu, Sep 29, 2005 at 12:05:10AM -0400, Fran?ois-Denis Gonthier wrote: > On 28 September 2005 14:07, Justin Pryzby wrote: > > When I make a new upstream package for Erlang, I need to extract the upstream > tar.gz file, which is named otp_src_[version].tar.gz, rename the created > directory to a Debian friendly name and then make the .orig.tar.gz. > > Does that count as repackaging? If so I'm clueless as to what I should do to > avoid that. Yes. If the .orig.tar.gz is not identical to the upstream source-ball available from the location indicated in the copyright (guaranteed by policy 12.5), then it is considered repackaging. dpkg-source is intelligent, and can deal with many strange upstream tarballs. It doesn't care if the tarball extracts to the wrong directory name, or extracts to ./, or pretty much anything else. You might have to rename the upstream directory for the initial invocation of dh_make, but that it entirely independent from everything else. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lintian warning native-package-with-dash-version
Hi I am new to packaging and I am trying to package gnuplotfortran whose upstream is located at http://sourceforge.net/projects/gnuplotfortran . The upstream source is called gnuplotfortran-0.2.2-1.tar.bz2 . I downloaded this to /tmp . Then I did tar xjvf /tmp/gnuplotfortran-0.2.2-1.tar.bz2 -C . tar czvf gnuplotfortran-0.2.2-1.tar.gz gnuplotfortran-0.2.2-1/ cd gnuplotfortran-0.2.2-1/ dh_make --copyright lgpl -e [EMAIL PROTECTED] -f \ ../gnuplotfortran-0.2.2-1.tar.gz -l Then I proceeded on doing dpkg-buildpackage etc., At the end I obtained gnuplotfortran_0.2.2-1-1.dsc . But if I do $lintian -i gnuplotfortran_0.2.2-1-1.dsc W: gnuplotfortran source: native-package-with-dash-version N: N: Native packaging should only be used if a piece of software was N: written specifically to be turned into a Debian package. In this case, N: the version number should not contain a debian revision part. N: N: Native source packages are sometimes created by accident. In most N: cases the reason is the location of the original source tarball. N: dpkg-source searches for this in N: ../package_upstream-version.orig.tar.gz. N: Q1) Where am I doing wrong? How can I get rid of this error? Q2) should I create a symbolic link gnuplotfortran-0.2.2-1.orig.tar.gz which points to gnuplotfortran-0.2.2-1.tar.gz before proceeding with dpkg-buildpackage? I see that it is automatically created after dpkg-buildpackage step. thanks raju -- Kamaraju S Kusumanchi Graduate Student, MAE Cornell University http://www.people.cornell.edu/pages/kk288/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On 28 September 2005 14:07, Justin Pryzby wrote: When I make a new upstream package for Erlang, I need to extract the upstream tar.gz file, which is named otp_src_[version].tar.gz, rename the created directory to a Debian friendly name and then make the .orig.tar.gz. Does that count as repackaging? If so I'm clueless as to what I should do to avoid that. > On Wed, Sep 28, 2005 at 01:36:02PM -0400, Roberto C. Sanchez wrote: > > On Wed, Sep 28, 2005 at 12:07:08PM -0500, Carlo Segre wrote: > > > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > > > >On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > > > >>Hi! > > > >> > > > >>I'm packaging kchmviewer, which uses a version of chmlib bundled > > > >>in the upstream tarball. > > > >> > > > >>Is it a Bad Thing to use that library instead of depending on the > > > >>official packaged one? > > > > > > > >Yes(TM), it is a Bad Thing(TM). > > > > > > > >If the official library is suitable, then use it. It will: > > > > > > > >- absolve you of providing security support for the duplicate code > > > >- make the resulting binary packages fewer or smaller > > > >- save space on end user systems and repository mirror sites > > > > > > Don't delete it form the upstream tarball though or your diffs will be > > > huge. Just disable the compilation in the makefiles. > > > > > > Carlo > > > > An excellent point. I imagine that it would also be permissible to > > repackage the .orig.tar.gz file so that it is gone from there as well. > > Usually only 3 reasons are sufficient justification for repackaging. > > 1) non DFSG material included; > 2) large binaries included; > 3) multiple "dependent" upstream source tarballs required for > building a single binary package > > Bill lists some other ones here: > http://lists.debian.org/debian-policy/2003/09/msg00123.html > > My comments within: > --- Files have stupid permissions. > This is probably not a valid reason, in itself; just run > chmod -R u=Xg=o= or whatever in ./debian/rules. > > --- tarball contains files at the root. > As Joerg notes in the New Queue Reject Faq, this is not a valid > reason; dpkg-source deals with this just fine. > > --- Some files are not DFSG free. > Correct. > > --- You can't add binary files (e.g. icons) in a diff. Using uuencode > is not optimal. Sometimes it is better to sneak them in the > source tarball. > That's one way; Theodore Ts'o does it by putting them in the .diff.gz. > > --- tarball include large stuff that we don't want to package. > I think this is only sufficient justification if its very large, like > over 50% of the source package size, and tens of megabytes. > > The other 3 things listed are also okay.. > > -- > Clear skies, > Justin pgpukfeHqRiiW.pgp Description: PGP signature
Re: package maintain help
You really have to punctuate your sentences.
Postinst is for doing things after the package is installed. For
example, you might have to register your package with some larger
package such that it is recognized and available for use. The prerm
undoes this, by unregistering it.
Many packages don't need maintscripts at all (at least not custom
ones; debhelper will add snippets in the appropriate places to do
common things). In that case, you can just remove the examples that
dh_make creates for you, and everything will Just Work.
If your package is really just a collection of shellscripts, then I
don't see any reason why you would need custom maintscripts.
If you need examples of what maintscripts do,
/var/lib/dpkg/info/*{inst,rm} are already on your system.
--
Clear skies,
Justin
On Wed, Sep 28, 2005 at 07:14:00PM -0700, mithereal wrote:
> hello i have some (hopefully simple) questions about
> package maintaining that the howto ot tldp didn't
> readily cover. example i dont understend the postinst
> and prerm scripts well i do understand what theyre for
> just i dont understand certain parts for example i
> have a package of shell scripts ive created that i
> want to install into the system so i follow the howto
> and everything is fine till the mentioned scripts my
> question is what do i need to do in the scripts just
> to install the files into the dir everything ive taken
> from the (dont remember but holds examples of post and
> pre scripts)dir fails the install and i must commont
> out the lines in in the /var/lib/dpkg// dir
> i guess a helpful would be to gimme a howto on
> postinst and prerim scripts what to do and whatnot to do.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package maintain help
hello i have some (hopefully simple) questions about package maintaining that the howto ot tldp didn't readily cover. example i dont understend the postinst and prerm scripts well i do understand what theyre for just i dont understand certain parts for example i have a package of shell scripts ive created that i want to install into the system so i follow the howto and everything is fine till the mentioned scripts my question is what do i need to do in the scripts just to install the files into the dir everything ive taken from the (dont remember but holds examples of post and pre scripts)dir fails the install and i must commont out the lines in in the /var/lib/dpkg// dir i guess a helpful would be to gimme a howto on postinst and prerim scripts what to do and whatnot to do. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules: create folder into deb
On Wed, Sep 28, 2005 at 05:35:50PM -0400, Roberto C. Sanchez wrote: > On Wed, Sep 28, 2005 at 11:26:30PM +0200, nidr wrote: > > Perhaps you guys have seen some of my other threads over at debian-boot. > > They are all related to tasksel, as am trying to add my own tasks for > > personally use. Am grateful for all the help I have got with tasksel so far. > > But there is still something I do not understand: > > > > You see I've been trying to make my own deb out of the tasksel 2.24 source. > > So I've managed to build a working deb with the dpkg-buildpackage command, > > but later I found out that I needed to do some more modifications: > > When I run the dpkg-buildpackage command, the system make this folder > > ./debian/tasksel/usr/lib/tasksel/packages > > But this folder has no items inside. So I want to add my package-list item > > into this folder, so my owm packages list is there, "inside" the deb. How > > can I make so the dpkg-buildpackage will move my list program to that > > folder? > > I've tried to read some documention about debian/rules, but still I can't > > manage to do what I want to. Hope someone could help me here. > > > debian/rules is just a Makefile. Of you understand Makefile syntax, > that is all you need. Basically, you can place your file somewhere in > the debian/ directory. Then after the call to dh_installdirs (I think) > you can use a simple mv command to move your file to the desired > destination. > > -Roberto > ... or, while you're using debhelper, use dh_install - although you won't gain any flexibility compared with a manual mv/cp. Regards, Jan -- Jan C. Nordholz signature.asc Description: Digital signature
Re: Bewerbung
On 28-Sep-2005, martin f krafft wrote: > also sprach Robert Ribnitz <[EMAIL PROTECTED]> [2005.09.28.1059 +0200]: > > List: He's asking about getting a job as a "free translator". Pointing > > him to the l18n lists, and telling him about debian in general, and this > > list in particular. > > I reported his message as spam. Thanks. -- \ "Those who can make you believe absurdities can make you commit | `\ atrocities." -- Voltaire | _o__) | Ben Finney <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: debian/rules: create folder into deb
On Wed, Sep 28, 2005 at 11:26:30PM +0200, nidr wrote: > Perhaps you guys have seen some of my other threads over at debian-boot. > They are all related to tasksel, as am trying to add my own tasks for > personally use. Am grateful for all the help I have got with tasksel so far. > But there is still something I do not understand: > > You see I've been trying to make my own deb out of the tasksel 2.24 source. > So I've managed to build a working deb with the dpkg-buildpackage command, > but later I found out that I needed to do some more modifications: > When I run the dpkg-buildpackage command, the system make this folder > ./debian/tasksel/usr/lib/tasksel/packages > But this folder has no items inside. So I want to add my package-list item > into this folder, so my owm packages list is there, "inside" the deb. How > can I make so the dpkg-buildpackage will move my list program to that > folder? > I've tried to read some documention about debian/rules, but still I can't > manage to do what I want to. Hope someone could help me here. Somewhere late in the install target, you want to put a command to do that. I don't know anything about tasksel, though, so I don't know if that's the right way to do what you want. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian/rules: create folder into deb
On Wed, Sep 28, 2005 at 11:26:30PM +0200, nidr wrote: > Perhaps you guys have seen some of my other threads over at debian-boot. > They are all related to tasksel, as am trying to add my own tasks for > personally use. Am grateful for all the help I have got with tasksel so far. > But there is still something I do not understand: > > You see I've been trying to make my own deb out of the tasksel 2.24 source. > So I've managed to build a working deb with the dpkg-buildpackage command, > but later I found out that I needed to do some more modifications: > When I run the dpkg-buildpackage command, the system make this folder > ./debian/tasksel/usr/lib/tasksel/packages > But this folder has no items inside. So I want to add my package-list item > into this folder, so my owm packages list is there, "inside" the deb. How > can I make so the dpkg-buildpackage will move my list program to that > folder? > I've tried to read some documention about debian/rules, but still I can't > manage to do what I want to. Hope someone could help me here. > debian/rules is just a Makefile. Of you understand Makefile syntax, that is all you need. Basically, you can place your file somewhere in the debian/ directory. Then after the call to dh_installdirs (I think) you can use a simple mv command to move your file to the desired destination. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpVgj2LmreTn.pgp Description: PGP signature
debian/rules: create folder into deb
Perhaps you guys have seen some of my other threads over at debian-boot. They are all related to tasksel, as am trying to add my own tasks for personally use. Am grateful for all the help I have got with tasksel so far. But there is still something I do not understand: You see I've been trying to make my own deb out of the tasksel 2.24 source. So I've managed to build a working deb with the dpkg-buildpackage command, but later I found out that I needed to do some more modifications: When I run the dpkg-buildpackage command, the system make this folder ./debian/tasksel/usr/lib/tasksel/packages But this folder has no items inside. So I want to add my package-list item into this folder, so my owm packages list is there, "inside" the deb. How can I make so the dpkg-buildpackage will move my list program to that folder? I've tried to read some documention about debian/rules, but still I can't manage to do what I want to. Hope someone could help me here. Please let me know if I should post this in the debian-boot list instead, cause am a bit unsure if this is the correct list. Thank you for any input. -nidr
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 01:08:47PM -0500, Carlo Segre wrote: > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > >An excellent point. I imagine that it would also be permissible to > >repackage the .orig.tar.gz file so that it is gone from there as well. > True, but then there is an additional step to taking a new tarball release > and making a package. I think it is better practice not to modify the > upstream tarball. Suppose that I were gone and you wanted to package a > new release of my package. If I have a special, hidden procedure to > prepare the original tarball, then you would not be able to just apply the > diffs from the old source and have a chance to make it work. See devref section 6.7.8.2: "Repackaged upstream source". -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 12:19:08PM -0400, Roberto C. Sanchez wrote: > > Is it a Bad Thing to use that library instead of depending on the > > official packaged one? > > Yes(TM), it is a Bad Thing(TM). > > If the official library is suitable, then use it. It will: > > - absolve you of providing security support for the duplicate code > - make the resulting binary packages fewer or smaller > - save space on end user systems and repository mirror sites - save someone's memory from loading another library Cause usually they're linking it statically which is another Bad Thing(TM). regards fEnIo -- ,''`. Bartosz Fenski | mailto:[EMAIL PROTECTED] | pgp:0x13fefc40 | irc:fEnIo : :' : 32-050 Skawina - Glowackiego 3/15 - w. malopolskie - Poland `. `' phone:+48602383548 | proud Debian maintainer and user `- http://skawina.eu.org | jid:[EMAIL PROTECTED] | rlu:172001 signature.asc Description: Digital signature
Re: duplicate library code in a package
On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. -Roberto True, but then there is an additional step to taking a new tarball release and making a package. I think it is better practice not to modify the upstream tarball. Suppose that I were gone and you wanted to package a new release of my package. If I have a special, hidden procedure to prepare the original tarball, then you would not be able to just apply the diffs from the old source and have a chance to make it work. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 01:36:02PM -0400, Roberto C. Sanchez wrote: > On Wed, Sep 28, 2005 at 12:07:08PM -0500, Carlo Segre wrote: > > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > > > > >On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > > >>Hi! > > >> > > >>I'm packaging kchmviewer, which uses a version of chmlib bundled > > >>in the upstream tarball. > > >> > > >>Is it a Bad Thing to use that library instead of depending on the > > >>official packaged one? > > > > > >Yes(TM), it is a Bad Thing(TM). > > > > > >If the official library is suitable, then use it. It will: > > > > > >- absolve you of providing security support for the duplicate code > > >- make the resulting binary packages fewer or smaller > > >- save space on end user systems and repository mirror sites > > > > > > > Don't delete it form the upstream tarball though or your diffs will be > > huge. > > Just disable the compilation in the makefiles. > > > > Carlo > > An excellent point. I imagine that it would also be permissible to > repackage the .orig.tar.gz file so that it is gone from there as well. Usually only 3 reasons are sufficient justification for repackaging. 1) non DFSG material included; 2) large binaries included; 3) multiple "dependent" upstream source tarballs required for building a single binary package Bill lists some other ones here: http://lists.debian.org/debian-policy/2003/09/msg00123.html My comments within: --- Files have stupid permissions. This is probably not a valid reason, in itself; just run chmod -R u=Xg=o= or whatever in ./debian/rules. --- tarball contains files at the root. As Joerg notes in the New Queue Reject Faq, this is not a valid reason; dpkg-source deals with this just fine. --- Some files are not DFSG free. Correct. --- You can't add binary files (e.g. icons) in a diff. Using uuencode is not optimal. Sometimes it is better to sneak them in the source tarball. That's one way; Theodore Ts'o does it by putting them in the .diff.gz. --- tarball include large stuff that we don't want to package. I think this is only sufficient justification if its very large, like over 50% of the source package size, and tens of megabytes. The other 3 things listed are also okay.. -- Clear skies, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. ? orig.tar.gz should be as it says - the original. not necessarily. It must be the original, but it must not be pristine. One reason could be to remove autotools dependencies, another could be to remove files which would otherwise be removed by the "clean" target and would end up in a huge diff.gz. IMHO this such things should of course be reported to upstream and hopefully be fixed in the next upstream version. Regards, Andreas -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wednesday 28 September 2005 6:36 pm, Roberto C. Sanchez wrote: > > Don't delete it form the upstream tarball though or your diffs will be > > huge. Just disable the compilation in the makefiles. > > > > Carlo > > An excellent point. I imagine that it would also be permissible to > repackage the .orig.tar.gz file so that it is gone from there as well. ? orig.tar.gz should be as it says - the original. Changes to .org.tar.gz are up to upstream. I use conditional builds on my own projects and when I build the tarball from CVS on Debian, it does not build a library that exists on Debian. However, the tarball is the same as one used to create RPM's on FC3 where the library is NOT available and the build uses the internal code. The upstream tarball and .orig.tar.gz should be as flexible as possible and that means keeping the included files in the source but skipping them in the build of the binary. So package-release.i386.deb uses the external library and has a dependency on it. package-release.src.deb includes the internal code and retains the ability to use the external one if it is present on the *build* system. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpxXC3VN6lUi.pgp Description: PGP signature
Re: duplicate library code in a package
Hello Tommaso, Good thing that you are making a debian of kchmviewer. I myself made a debian package a month back or so.I contacted the developer about the same. I got reply just yesterday. Anyways I have already worked on this, so if you want I can send you the debianised source tar and you can have a look into it. Oh and I had included the chmlib while making the debian but I had a also added an depends entry for the same in the control file. I could install the debian I created in two boxes witout much trouble inspite of getting few warnings from lintian. Would like to have a look at them? I can send them over to you. Regards Pradeepto Bhattacharya On Wed, September 28, 2005 9:45 pm, Tommaso Moroni said: > Hi! > > I'm packaging kchmviewer, which uses a version of chmlib bundled > in the upstream tarball. > > Is it a Bad Thing to use that library instead of depending on the > official packaged one? > > > Regards, > -- > Tommaso Moroni <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > -- Pradeepto Bhattacharya. Email : [EMAIL PROTECTED] Website : http://www.eninteractive.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 12:07:08PM -0500, Carlo Segre wrote: > On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: > > >On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > >>Hi! > >> > >>I'm packaging kchmviewer, which uses a version of chmlib bundled > >>in the upstream tarball. > >> > >>Is it a Bad Thing to use that library instead of depending on the > >>official packaged one? > > > >Yes(TM), it is a Bad Thing(TM). > > > >If the official library is suitable, then use it. It will: > > > >- absolve you of providing security support for the duplicate code > >- make the resulting binary packages fewer or smaller > >- save space on end user systems and repository mirror sites > > > > Don't delete it form the upstream tarball though or your diffs will be huge. > Just disable the compilation in the makefiles. > > Carlo An excellent point. I imagine that it would also be permissible to repackage the .orig.tar.gz file so that it is gone from there as well. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpiFM97YzFsQ.pgp Description: PGP signature
Re: duplicate library code in a package
On Wed, 28 Sep 2005, Roberto C. Sanchez wrote: On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: Hi! I'm packaging kchmviewer, which uses a version of chmlib bundled in the upstream tarball. Is it a Bad Thing to use that library instead of depending on the official packaged one? Yes(TM), it is a Bad Thing(TM). If the official library is suitable, then use it. It will: - absolve you of providing security support for the duplicate code - make the resulting binary packages fewer or smaller - save space on end user systems and repository mirror sites Don't delete it form the upstream tarball though or your diffs will be huge. Just disable the compilation in the makefiles. Carlo -- Carlo U. Segre -- Professor of Physics Associate Dean for Special Projects, Graduate College Illinois Institute of Technology Voice: 312.567.3498Fax: 312.567.3494 [EMAIL PROTECTED]http://www.iit.edu/~segre -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: duplicate library code in a package
On Wed, Sep 28, 2005 at 06:15:12PM +0200, Tommaso Moroni wrote: > Hi! > > I'm packaging kchmviewer, which uses a version of chmlib bundled > in the upstream tarball. > > Is it a Bad Thing to use that library instead of depending on the > official packaged one? Yes(TM), it is a Bad Thing(TM). If the official library is suitable, then use it. It will: - absolve you of providing security support for the duplicate code - make the resulting binary packages fewer or smaller - save space on end user systems and repository mirror sites -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpWCsoRy5wEM.pgp Description: PGP signature
duplicate library code in a package
Hi! I'm packaging kchmviewer, which uses a version of chmlib bundled in the upstream tarball. Is it a Bad Thing to use that library instead of depending on the official packaged one? Regards, -- Tommaso Moroni <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: lprof -- Hardware Color Profiler
* Christoph Berg <[EMAIL PROTECTED]> [2005-09-28 15:46:46 +0200]: > Re: Oleksandr Moskalenko in <[EMAIL PROTECTED]> > > Package: lprof > > Uploaded. > > Christoph > -- > [EMAIL PROTECTED] | http://www.df7cb.de/ Thanks a lot Christoph! Alex signature.asc Description: Digital signature
Re: RFS: lprof -- Hardware Color Profiler
Re: Oleksandr Moskalenko in <[EMAIL PROTECTED]> > Package: lprof Uploaded. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Bewerbung
also sprach Robert Ribnitz <[EMAIL PROTECTED]> [2005.09.28.1059 +0200]: > List: He's asking about getting a job as a "free translator". Pointing > him to the l18n lists, and telling him about debian in general, and this > list in particular. I reported his message as spam. > >Ich möchte mich bei Ihnen als freiberuflicher Übersetzer bewerben. That's free-lance, not free. He is looking to make money. > >Wir machen Ihnen gerne einen gratis Kostenvoranschlag. Here he offers to make a tender for free. Spam. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver! someday we'll find it the rainbow connection the lovers, the dreamers, and me! -- kermit signature.asc Description: Digital signature (GPG/PGP)
Re: Bewerbung
List: He's asking about getting a job as a "free translator". Pointing him to the l18n lists, and telling him about debian in general, and this list in particular. Sehr geehrter Herr Dr. Kogler, Debian ist ein Projekt, welches von vielen Entwicklern meist in ihrere Freizeit gepflegt wird. (vgl: http://www.de.debian.org/intro/about.de.html ). Die Mitarbeit im Debian-Projekt erfolgt daher auf Voluntaerbasis und ohne jegliche Bezahlung. Bitte beachten Sie auch, dass die Entwicklergemeinde ueber den ganzen Erdball verstreut ist. In der Regel erfolgt die Kommunikation daher in englischer Sprache. Sollten Sie an einer Mitarbeit interessiert sein, so wenden Sie sich bitte an eine der Uebersetzungs- und internationalisierungslisten (Engl. Uebersicht: http://lists.debian.org/i18n.html ). Insbesondere debian-l10n-german scheint interessant (und deutschsprachig) zu sein. Mit freundlichen Gruessen Robert Ribnitz. Dr. Kogler Übersetzungen wrote: >Sehr geehrte Damen und Herren! > >Ich möchte mich bei Ihnen als freiberuflicher Übersetzer bewerben. > >Mein Team und ich übersetzen alle Weltsprachen. Wir liefern Ihnen >Fachübersetzungen schnell und problemlos! Für Ihren geschäftlichen >Erfolg! > >Testen Sie uns jetzt! Senden Sie uns per E-Mail Ihre Texte an: >mailto:[EMAIL PROTECTED] > >Wir machen Ihnen gerne einen gratis Kostenvoranschlag. >Ich garantiere prompte und zuverlässige Abwicklung! > >Mit freundlichen Grüßen > >Dr. Robert Kogler >Dipl. Übersetzer > >PS: Suchen Sie manchmal jemanden, der kompetent Ihre Texte übersetzt? >Speichern Sie unsere Daten in Ihrem Adressbuch! >--- >Dr. Kogler Übersetzungen >Scharnweberstr. 112 – 19 >D – 13405 Berlin >Tel +49 (0) 1801 555 777 2428 >Fax +44 (0) 870 137 9909 >Email mailto:[EMAIL PROTECTED] >Web www.drkogler.com > > >Ihre Emailadresse können Sie aus meinen Bewerbungsunterlagen entfernen, >indem Sie ein Mail an mailto:[EMAIL PROTECTED] senden und in die >Betreffzeile löschen schreiben. > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re[1]: Буду благодарна, если Ollit
Привет! Предлагаем быстро выучить Разговорный английский язык. Уникальная методика обучения - мышление, произношение, стиль речи. У нас скидки!!! Наши телефоны в Москве: 105-5186 238-33-86 Bohn Raisinghani Perovic Aceves Naylor Krisz Raza Nevrtal Jurewicz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bewerbung
Sehr geehrte Damen und Herren! Ich möchte mich bei Ihnen als freiberuflicher Übersetzer bewerben. Mein Team und ich übersetzen alle Weltsprachen. Wir liefern Ihnen Fachübersetzungen schnell und problemlos! Für Ihren geschäftlichen Erfolg! Testen Sie uns jetzt! Senden Sie uns per E-Mail Ihre Texte an: mailto:[EMAIL PROTECTED] Wir machen Ihnen gerne einen gratis Kostenvoranschlag. Ich garantiere prompte und zuverlässige Abwicklung! Mit freundlichen Grüßen Dr. Robert Kogler Dipl. Übersetzer PS: Suchen Sie manchmal jemanden, der kompetent Ihre Texte übersetzt? Speichern Sie unsere Daten in Ihrem Adressbuch! --- Dr. Kogler Übersetzungen Scharnweberstr. 112 – 19 D – 13405 Berlin Tel +49 (0) 1801 555 777 2428 Fax +44 (0) 870 137 9909 Email mailto:[EMAIL PROTECTED] Web www.drkogler.com Ihre Emailadresse können Sie aus meinen Bewerbungsunterlagen entfernen, indem Sie ein Mail an mailto:[EMAIL PROTECTED] senden und in die Betreffzeile löschen schreiben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
