different sizes for same upstream tarball
Hi, The byacc upstream tarball on ftp.debian.org 52916 bytes long, but on my development system, it compresses to 52930 bytes. (There hasn't been an upload of this package in about a year, shame on me.) I need to do an upload to fix several bugs, there have been no upstream changes (I think it's effectively abandoned), but my uploads are rejected because of the different file sizes. I've tried forcing a source upload, but dinstall complains that it can't remove the existing upstream source archive. Should I file a bug against ftp.debian.org, or alter the filesize and md5sum in the .changes and .dsc, resign and upload that? Is there anything else I could do? jason -- ``Banks *are* bastards.'' -- John Laws
Re: different sizes for same upstream tarball
Just use the old one from ftp.debian.org. If the .orig.tar.gz already exists in .. (relative to the source dir), a new one won't be generated. -brad On Sun, Jan 07, 2001 at 05:15:46PM +1000, Jason Henry Parker wrote: > Hi, > > The byacc upstream tarball on ftp.debian.org 52916 bytes long, but on > my development system, it compresses to 52930 bytes. (There hasn't > been an upload of this package in about a year, shame on me.) I need > to do an upload to fix several bugs, there have been no upstream > changes (I think it's effectively abandoned), but my uploads are > rejected because of the different file sizes. > > I've tried forcing a source upload, but dinstall complains that it > can't remove the existing upstream source archive. > > Should I file a bug against ftp.debian.org, or alter the filesize and > md5sum in the .changes and .dsc, resign and upload that? Is there > anything else I could do? > > jason > -- > ``Banks *are* bastards.'' -- John Laws > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: different sizes for same upstream tarball
On 20010107T171546+1000, Jason Henry Parker wrote: > Should I file a bug against ftp.debian.org It would be closed as a non-bug. > or alter the filesize and > md5sum in the .changes and .dsc, resign and upload that? Don't do that. It would probably make your upload broken. What I suggest is throwing away the tarball you have and using the one you download from ftp.debian.org (or directly from auric). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Keep the Deja Archive Alive! http://www2.PetitionOnline.com/dejanews/petition.html
Re: INSTALL.gz with generic installation instructions
On Sat, 6 Jan 2001 15:32:17 +0200, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: >On 20010106T13+0100, Marc Haber wrote: >> Is it allowed or desired to exclude documentation from binary packages >> that are in the source? > >Of course, if done with taste. The INSTALL file almost never should be >installed (it would not do any good for it to be installed, since the user >does the install in a completely different way, ie. using dpkg or apt). > >See Policy manual section 6.3, last sentence. That's what I have been looking for. Thanks. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: different sizes for same upstream tarball
On 7 Jan 2001, Jason Henry Parker wrote: > Hi, Hi Jason, > The byacc upstream tarball on ftp.debian.org 52916 bytes long, but on > my development system, it compresses to 52930 bytes. (There hasn't > been an upload of this package in about a year, shame on me.) I need > to do an upload to fix several bugs, there have been no upstream > changes (I think it's effectively abandoned), but my uploads are > rejected because of the different file sizes. > > I've tried forcing a source upload, but dinstall complains that it > can't remove the existing upstream source archive. > > Should I file a bug against ftp.debian.org, or alter the filesize and > md5sum in the .changes and .dsc, resign and upload that? Is there > anything else I could do? apt-get source byacc and you have the old .tar.gz. (Or is there a good reason for a newly compressed tarball?) > jason cu, Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi
lintian info message
In creating an unofficial Debian Package on a Potato system I get the following lintian info message, which I don't know how to get rid of: $ lintian -iIv PACKAGE.dsc ... I: PACKAGE source: unknown-field-in-dsc format ... Checking the deb-file alone produces no info message so I supsect the following line in the dsc-file: Format: 1.0 But I don't know how this lines find it's way into the dsc-file and how to avoid it. Any hints are appreciated. Michael PS: dpkg: 1.6.15 debhelper: 2.0.86 -- [EMAIL PROTECTED] http://www.miwie.org [EMAIL PROTECTED] http://wap.miwie.org
Looking for a sponsor for an upload of debian-mirror
Hi, Could someone please upload debian-mirror 1.0-1 deb ftp://rut.informatik.uni-tuebingen.de/ unstable main deb-src ftp://rut.informatik.uni-tuebingen.de/ unstable main ftp://rut.informatik.uni-tuebingen.de/dists/unstable/main/[source/binary-i386]/ Thanks. MfG Goswin
changes and arch?
Hi, all. I have a question about the subject of the following message. I built a freeradius binary .deb and ...powerpc.changes on a powerpc. Is the changes file really architecture-specific? I didn't think so, but the name is wierd. - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic') Return-Path: <[EMAIL PROTECTED]> Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian)) id 14FM2A-0004tH-00; Sun, 07 Jan 2001 15:03:18 -0500 From: Debian Installer <[EMAIL PROTECTED]> To: Chad Miller <[EMAIL PROTECTED]> Subject: radiusd-freeradius_0.0.20001227-1_powerpc.changes is NEW Date: Sun, 07 Jan 2001 15:03:18 -0500 (new) radiusd-freeradius_0.0.20001227-1.dsc standard net (new) radiusd-freeradius_0.0.20001227-1.tar.gz standard net (new) radiusd-freeradius_0.0.20001227-1_powerpc.deb standard net A high-performance and highly configurable RADIUS server A high-performance and highly configurable RADIUS server. freeradius is similar to Livingston's 2.0 and derived from Cistron's server, but has support for... - many vendor-specific attributes - proxying and replicating requests by any criteria - authentication on system passwd, MySQL, LDAP, users, PAM - multiple DEFAULT configurations - regexp matching in string attributes and lots more. Changes: radiusd-freeradius (0.0.20001227-1) unstable; urgency=low . * Initial revision. (closes: Bug#76476) Announcing to debian-devel-changes@lists.debian.org Closing bugs: 76476 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions.
Re: different sizes for same upstream tarball
Adrian Bunk <[EMAIL PROTECTED]> writes: > apt-get source byacc > and you have the old .tar.gz. (Or is there a good reason for a newly > compressed tarball?) The reason I wanted to try a recompressed tarball was that I use cvs-buildpackage to make builds easier; if I have to futz about copying the old .tar.gz into place it could be a little inconvenient, but it's much better than not being able to upload it at all. Thanks, jason -- ``Banks *are* bastards.'' -- John Laws
Re: different sizes for same upstream tarball
> " " == Jason Henry Parker <[EMAIL PROTECTED]> writes: > Adrian Bunk <[EMAIL PROTECTED]> writes: >> apt-get source byacc and you have the old .tar.gz. (Or is there >> a good reason for a newly compressed tarball?) > The reason I wanted to try a recompressed tarball was that I > use cvs-buildpackage to make builds easier; if I have to futz > about copying the old .tar.gz into place it could be a little > inconvenient, but it's much better than not being able to > upload it at all. The orig.tar.gz file should be pristine (does someone have the pointer to the policiy about this?). Basically NEVER rebuild it. It should be the original file downloaded from the upstream author without any changes so that the md5sum compares to any md5sum the author made public. MfG Goswin
Re: different sizes for same upstream tarball
On 7 Jan 2001, Goswin Brederlow wrote: > The orig.tar.gz file should be pristine (does someone have the pointer > to the policiy about this?). Basically NEVER rebuild it. > > It should be the original file downloaded from the upstream author > without any changes so that the md5sum compares to any md5sum the > author made public. This is neither pragmatic, nor could I find anything in policy or the packaging manual that states this. The reason this is not a useful guideline is that *many* upstream tarballs are not a ./$package-$version/code format. Some aren't gzipped, and some aren't even tarballs. Yet others are broken in other special ways. For example, I just sponsored an upload a fortunes package where the upstream tarball contained a full copy of the source for wget (?!?) - naturally, we cut that out and saved about 450kB of cruft from occupying every Debian mirror in the world. As for Debian policy, the packaging manual (section 3.3) has this to say: Original source archive - package_upstream-version.orig.tar.gz This is a compressed (with gzip -9) tar file containing the source code from the upstream authors of the program. The tarfile unpacks into a directory package-upstream-version.orig, and does not contain files anywhere other than in there or in its subdirectories. Of course, you should make every effort to maintain the integrity of the upstream source, but that doesn't mean that you can't repack it if need be. After all, that's why we insist on licenses that allow redistribution. tony [EMAIL PROTECTED] | Der Graf sehnt sich so sehr nach dem Blut einer http://www.debian.org | Jungfrau. Doch der Graf hat Angst... | Angst vor HIV. (die Aerzte)
Re: lintian info message
Michael Wiedmann <[EMAIL PROTECTED]> wrote: >In creating an unofficial Debian Package on a Potato system I get the >following lintian info message, which I don't know how to get rid of: > >$ lintian -iIv PACKAGE.dsc >... >I: PACKAGE source: unknown-field-in-dsc format >... > >Checking the deb-file alone produces no info message so I supsect the >following line in the dsc-file: > >Format: 1.0 > >But I don't know how this lines find it's way into the dsc-file and how >to avoid it. Any hints are appreciated. It's not a bug in your package, but a bug in lintian; the Format: field was introduced in dpkg 1.6.13. The warning was eliminated in lintian 1.11.3: lintian (1.11.3) unstable; urgency=low * Added 'Format' field to dsc file checks New dpkg versions seem to write a Format version to dsc files, lintian flagged them as an unknown field. [...] -- Sean 'Shaleh' Perry <[EMAIL PROTECTED]> Fri, 1 Sep 2000 15:35:03 -0700 Try upgrading to the version of lintian in unstable (which has generally better checks anyway). It should install cleanly on potato systems. -- Colin Watson [EMAIL PROTECTED]
Re: changes and arch?
Chad Miller <[EMAIL PROTECTED]> wrote: >Hi, all. I have a question about the subject of the following message. >I built a freeradius binary .deb and ...powerpc.changes on a powerpc. Is >the changes file really architecture-specific? I didn't think so, but the >name is wierd. The .changes file contains the md5sums of the files you're uploading, including any architecture-specific .deb. There will be separate .changes files generated for each different architecture as your package is ported. -- Colin Watson [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
> " " == tony mancill <[EMAIL PROTECTED]> writes: > On 7 Jan 2001, Goswin Brederlow wrote: >> The orig.tar.gz file should be pristine (does someone have the >> pointer to the policiy about this?). Basically NEVER rebuild >> it. >> >> It should be the original file downloaded from the upstream >> author without any changes so that the md5sum compares to any >> md5sum the author made public. > This is neither pragmatic, nor could I find anything in policy > or the packaging manual that states this. The reason this is I thought it said that one should try to keep the original file. > not a useful guideline is that *many* upstream tarballs are not > a ./$package-$version/code format. Some aren't gzipped, and > some aren't even tarballs. Yet others are broken in other > special ways. For example, I just sponsored an upload a > fortunes package where the upstream tarball contained a full > copy of the source for wget (?!?) - naturally, we cut that out > and saved about 450kB of cruft from occupying every Debian > mirror in the world. > As for Debian policy, the packaging manual (section 3.3) has > this to say: > Original source archive - package_upstream-version.orig.tar.gz > This is a compressed (with gzip -9) tar file containing the > source code from the upstream authors of the program. The > tarfile unpacks into a directory package-upstream-version.orig, > and does not contain files anywhere other than in there or in > its subdirectories. > Of course, you should make every effort to maintain the > integrity of the upstream source, but that doesn't mean that > you can't repack it if need be. After all, that's why we > insist on licenses that allow redistribution. Thats what I ment. MfG Goswin
Re: different sizes for same upstream tarball
On 20010107T171546+1000, Jason Henry Parker wrote: > Should I file a bug against ftp.debian.org It would be closed as a non-bug. > or alter the filesize and > md5sum in the .changes and .dsc, resign and upload that? Don't do that. It would probably make your upload broken. What I suggest is throwing away the tarball you have and using the one you download from ftp.debian.org (or directly from auric). -- %%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%% Keep the Deja Archive Alive! http://www2.PetitionOnline.com/dejanews/petition.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: INSTALL.gz with generic installation instructions
On Sat, 6 Jan 2001 15:32:17 +0200, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: >On 20010106T13+0100, Marc Haber wrote: >> Is it allowed or desired to exclude documentation from binary packages >> that are in the source? > >Of course, if done with taste. The INSTALL file almost never should be >installed (it would not do any good for it to be installed, since the user >does the install in a completely different way, ie. using dpkg or apt). > >See Policy manual section 6.3, last sentence. That's what I have been looking for. Thanks. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On 7 Jan 2001, Jason Henry Parker wrote: > Hi, Hi Jason, > The byacc upstream tarball on ftp.debian.org 52916 bytes long, but on > my development system, it compresses to 52930 bytes. (There hasn't > been an upload of this package in about a year, shame on me.) I need > to do an upload to fix several bugs, there have been no upstream > changes (I think it's effectively abandoned), but my uploads are > rejected because of the different file sizes. > > I've tried forcing a source upload, but dinstall complains that it > can't remove the existing upstream source archive. > > Should I file a bug against ftp.debian.org, or alter the filesize and > md5sum in the .changes and .dsc, resign and upload that? Is there > anything else I could do? apt-get source byacc and you have the old .tar.gz. (Or is there a good reason for a newly compressed tarball?) > jason cu, Adrian -- A "No" uttered from deepest conviction is better and greater than a "Yes" merely uttered to please, or what is worse, to avoid trouble. -- Mahatma Ghandi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
lintian info message
In creating an unofficial Debian Package on a Potato system I get the following lintian info message, which I don't know how to get rid of: $ lintian -iIv PACKAGE.dsc ... I: PACKAGE source: unknown-field-in-dsc format ... Checking the deb-file alone produces no info message so I supsect the following line in the dsc-file: Format: 1.0 But I don't know how this lines find it's way into the dsc-file and how to avoid it. Any hints are appreciated. Michael PS: dpkg: 1.6.15 debhelper: 2.0.86 -- [EMAIL PROTECTED] http://www.miwie.org [EMAIL PROTECTED] http://wap.miwie.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for a sponsor for an upload of debian-mirror
Hi, Could someone please upload debian-mirror 1.0-1 deb ftp://rut.informatik.uni-tuebingen.de/ unstable main deb-src ftp://rut.informatik.uni-tuebingen.de/ unstable main ftp://rut.informatik.uni-tuebingen.de/dists/unstable/main/[source/binary-i386]/ Thanks. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
changes and arch?
Hi, all. I have a question about the subject of the following message. I built a freeradius binary .deb and ...powerpc.changes on a powerpc. Is the changes file really architecture-specific? I didn't think so, but the name is wierd. - chad -- Chad Miller <[EMAIL PROTECTED]> URL: http://web.chad.org/ (GPG) "Any technology distinguishable from magic is insufficiently advanced". First corollary to Clarke's Third Law (Jargon File, v4.2.0, 'magic') Return-Path: <[EMAIL PROTECTED]> Received: from troup by auric.debian.org with local (Exim 3.12 1 (Debian)) id 14FM2A-0004tH-00; Sun, 07 Jan 2001 15:03:18 -0500 From: Debian Installer <[EMAIL PROTECTED]> To: Chad Miller <[EMAIL PROTECTED]> Subject: radiusd-freeradius_0.0.20001227-1_powerpc.changes is NEW Date: Sun, 07 Jan 2001 15:03:18 -0500 (new) radiusd-freeradius_0.0.20001227-1.dsc standard net (new) radiusd-freeradius_0.0.20001227-1.tar.gz standard net (new) radiusd-freeradius_0.0.20001227-1_powerpc.deb standard net A high-performance and highly configurable RADIUS server A high-performance and highly configurable RADIUS server. freeradius is similar to Livingston's 2.0 and derived from Cistron's server, but has support for... - many vendor-specific attributes - proxying and replicating requests by any criteria - authentication on system passwd, MySQL, LDAP, users, PAM - multiple DEFAULT configurations - regexp matching in string attributes and lots more. Changes: radiusd-freeradius (0.0.20001227-1) unstable; urgency=low . * Initial revision. (closes: Bug#76476) Announcing to [EMAIL PROTECTED] Closing bugs: 76476 Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
Adrian Bunk <[EMAIL PROTECTED]> writes: > apt-get source byacc > and you have the old .tar.gz. (Or is there a good reason for a newly > compressed tarball?) The reason I wanted to try a recompressed tarball was that I use cvs-buildpackage to make builds easier; if I have to futz about copying the old .tar.gz into place it could be a little inconvenient, but it's much better than not being able to upload it at all. Thanks, jason -- ``Banks *are* bastards.'' -- John Laws -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
> " " == Jason Henry Parker <[EMAIL PROTECTED]> writes: > Adrian Bunk <[EMAIL PROTECTED]> writes: >> apt-get source byacc and you have the old .tar.gz. (Or is there >> a good reason for a newly compressed tarball?) > The reason I wanted to try a recompressed tarball was that I > use cvs-buildpackage to make builds easier; if I have to futz > about copying the old .tar.gz into place it could be a little > inconvenient, but it's much better than not being able to > upload it at all. The orig.tar.gz file should be pristine (does someone have the pointer to the policiy about this?). Basically NEVER rebuild it. It should be the original file downloaded from the upstream author without any changes so that the md5sum compares to any md5sum the author made public. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On 7 Jan 2001, Goswin Brederlow wrote: > The orig.tar.gz file should be pristine (does someone have the pointer > to the policiy about this?). Basically NEVER rebuild it. > > It should be the original file downloaded from the upstream author > without any changes so that the md5sum compares to any md5sum the > author made public. This is neither pragmatic, nor could I find anything in policy or the packaging manual that states this. The reason this is not a useful guideline is that *many* upstream tarballs are not a ./$package-$version/code format. Some aren't gzipped, and some aren't even tarballs. Yet others are broken in other special ways. For example, I just sponsored an upload a fortunes package where the upstream tarball contained a full copy of the source for wget (?!?) - naturally, we cut that out and saved about 450kB of cruft from occupying every Debian mirror in the world. As for Debian policy, the packaging manual (section 3.3) has this to say: Original source archive - package_upstream-version.orig.tar.gz This is a compressed (with gzip -9) tar file containing the source code from the upstream authors of the program. The tarfile unpacks into a directory package-upstream-version.orig, and does not contain files anywhere other than in there or in its subdirectories. Of course, you should make every effort to maintain the integrity of the upstream source, but that doesn't mean that you can't repack it if need be. After all, that's why we insist on licenses that allow redistribution. tony [EMAIL PROTECTED] | Der Graf sehnt sich so sehr nach dem Blut einer http://www.debian.org | Jungfrau. Doch der Graf hat Angst... | Angst vor HIV. (die Aerzte) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: lintian info message
Michael Wiedmann <[EMAIL PROTECTED]> wrote: >In creating an unofficial Debian Package on a Potato system I get the >following lintian info message, which I don't know how to get rid of: > >$ lintian -iIv PACKAGE.dsc >... >I: PACKAGE source: unknown-field-in-dsc format >... > >Checking the deb-file alone produces no info message so I supsect the >following line in the dsc-file: > >Format: 1.0 > >But I don't know how this lines find it's way into the dsc-file and how >to avoid it. Any hints are appreciated. It's not a bug in your package, but a bug in lintian; the Format: field was introduced in dpkg 1.6.13. The warning was eliminated in lintian 1.11.3: lintian (1.11.3) unstable; urgency=low * Added 'Format' field to dsc file checks New dpkg versions seem to write a Format version to dsc files, lintian flagged them as an unknown field. [...] -- Sean 'Shaleh' Perry <[EMAIL PROTECTED]> Fri, 1 Sep 2000 15:35:03 -0700 Try upgrading to the version of lintian in unstable (which has generally better checks anyway). It should install cleanly on potato systems. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: changes and arch?
Chad Miller <[EMAIL PROTECTED]> wrote: >Hi, all. I have a question about the subject of the following message. >I built a freeradius binary .deb and ...powerpc.changes on a powerpc. Is >the changes file really architecture-specific? I didn't think so, but the >name is wierd. The .changes file contains the md5sums of the files you're uploading, including any architecture-specific .deb. There will be separate .changes files generated for each different architecture as your package is ported. -- Colin Watson [[EMAIL PROTECTED]] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
> " " == tony mancill <[EMAIL PROTECTED]> writes: > On 7 Jan 2001, Goswin Brederlow wrote: >> The orig.tar.gz file should be pristine (does someone have the >> pointer to the policiy about this?). Basically NEVER rebuild >> it. >> >> It should be the original file downloaded from the upstream >> author without any changes so that the md5sum compares to any >> md5sum the author made public. > This is neither pragmatic, nor could I find anything in policy > or the packaging manual that states this. The reason this is I thought it said that one should try to keep the original file. > not a useful guideline is that *many* upstream tarballs are not > a ./$package-$version/code format. Some aren't gzipped, and > some aren't even tarballs. Yet others are broken in other > special ways. For example, I just sponsored an upload a > fortunes package where the upstream tarball contained a full > copy of the source for wget (?!?) - naturally, we cut that out > and saved about 450kB of cruft from occupying every Debian > mirror in the world. > As for Debian policy, the packaging manual (section 3.3) has > this to say: > Original source archive - package_upstream-version.orig.tar.gz > This is a compressed (with gzip -9) tar file containing the > source code from the upstream authors of the program. The > tarfile unpacks into a directory package-upstream-version.orig, > and does not contain files anywhere other than in there or in > its subdirectories. > Of course, you should make every effort to maintain the > integrity of the upstream source, but that doesn't mean that > you can't repack it if need be. After all, that's why we > insist on licenses that allow redistribution. Thats what I ment. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
