Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 11:00:11PM +1100, Hamish Moffatt wrote: 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. .orig.tar.gz should never change between debian revisions. Pre-pool dinstall used to allow it, which sucked. dinstall no longer allows it. What sucks more is when you have an un-pristine orig.tar.gz which needs to be changed, but dinstall changed not to allow changes and additionally made the package unbuildable. :| -- Digital Electronic Being Intended for Assassination and Nullification -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 11:00:11PM +1100, Hamish Moffatt wrote: 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. .orig.tar.gz should never change between debian revisions. Pre-pool dinstall used to allow it, which sucked. dinstall no longer allows it. What sucks more is when you have an un-pristine orig.tar.gz which needs to be changed, but dinstall changed not to allow changes and additionally made the package unbuildable. :| -- Digital Electronic Being Intended for Assassination and Nullification
Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 11:33:17PM +1000, Jason Henry Parker wrote: I've just built a new version of byacc that way, and the .changes and .dsc file look correct, but I suppose the real test is whether dinstall will be happy. You can logon to auric and run 'dinstall -n filename.changes' on the package to see if dinstall will be happy. Looks like dinstall is in the default path on auric. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 11:33:17PM +1000, Jason Henry Parker wrote: I've just built a new version of byacc that way, and the .changes and .dsc file look correct, but I suppose the real test is whether dinstall will be happy. You can logon to auric and run 'dinstall -n filename.changes' on the package to see if dinstall will be happy. Looks like dinstall is in the default path on auric. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On Sun, Jan 07, 2001 at 06:38:27PM -0700, tony mancill wrote: 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 The ./$package-$version/ layout is no longer necessarily, and it's a bug in the relevant documentation that it's still mentioned. I would guess that less than 10% of my packages actually obey that rule. Some have no version. Some even have a different name. For example, the original source archives for the geda-gschem package are called just gschem_date.tar.gz; I rename them to geda-gschem_date.orig.tar.gz. They unpack into just gschem/, which is no problem for modern versions of dpkg-dev. 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. There are some circumstances where it is necessary but they are not too common these days. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 11:00:11PM +1100, Hamish Moffatt wrote: .orig.tar.gz should never change between debian revisions. Pre-pool dinstall used to allow it, which sucked. dinstall no longer allows it. Since a debian revision is just a debian revision, the upstream code (ie the contents of .orig.tar.gz) should not change. Admittedly your reasons for asking about this are different Jason. I don't know what the solution is to satisfy cvs-buildpackage. The solution is to download the pristine tarball from a mirror and put it where cvs-buildpackage exports the package before building it. I've just built a new version of byacc that way, and the .changes and .dsc file look correct, but I suppose the real test is whether dinstall will be happy. I think it will be. 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 Sun, Jan 07, 2001 at 06:38:27PM -0700, tony mancill wrote: 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 The ./$package-$version/ layout is no longer necessarily, and it's a bug in the relevant documentation that it's still mentioned. I would guess that less than 10% of my packages actually obey that rule. Some have no version. Some even have a different name. For example, the original source archives for the geda-gschem package are called just gschem_date.tar.gz; I rename them to geda-gschem_date.orig.tar.gz. They unpack into just gschem/, which is no problem for modern versions of dpkg-dev. 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. There are some circumstances where it is necessary but they are not too common these days. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 07:19:31AM +1000, Jason Henry Parker wrote: 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. .orig.tar.gz should never change between debian revisions. Pre-pool dinstall used to allow it, which sucked. dinstall no longer allows it. Since a debian revision is just a debian revision, the upstream code (ie the contents of .orig.tar.gz) should not change. Admittedly your reasons for asking about this are different Jason. I don't know what the solution is to satisfy cvs-buildpackage. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: different sizes for same upstream tarball
On Mon, Jan 08, 2001 at 11:00:11PM +1100, Hamish Moffatt wrote: .orig.tar.gz should never change between debian revisions. Pre-pool dinstall used to allow it, which sucked. dinstall no longer allows it. Since a debian revision is just a debian revision, the upstream code (ie the contents of .orig.tar.gz) should not change. Admittedly your reasons for asking about this are different Jason. I don't know what the solution is to satisfy cvs-buildpackage. The solution is to download the pristine tarball from a mirror and put it where cvs-buildpackage exports the package before building it. I've just built a new version of byacc that way, and the .changes and .dsc file look correct, but I suppose the real test is whether dinstall will be happy. I think it will be. jason -- ``Banks *are* bastards.'' -- John Laws
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]
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
" " == 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]
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: 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
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: 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
