Bug#740883: dpkg-source -x regression: version number does not start with digit
On Fri, Mar 28, 2014 at 04:33:40AM +0100, Guillem Jover wrote: I'm just guessing those sources where created and extracted manually, probably around the time when the “new source format” got introduced, and where maintainers might have not switched to the new tools yet. http://archive.debian.org/debian/dists/Debian-1.2/main/source/README.source-unpack I'm a bit wary of adding a force option, even if only for format 1.0, to allow something that was never allowed in the first place, also taking into account there's source packages in ancient releases that are in the old format that dpkg-source does not know either. Given the above, in principle I'm tending towards not adding such an option to allow wrong fuzz, but I'll still ponder about this one for a bit. I see, and I understand your reasoning / concern. FWIW (and of very marginal importance) for my specific sources.d.n use case I'll have to add manual extraction of very old source packages anyhow, so making it work also for broken .dsc is not a big deal. More to the point, I guess the question you need to ask/answer yourself is what is the intended semantics of dpkg-source -x. Is it the tool meant to be able to extract all source packages that have ever been generated following the documented Debian source formats? Or rather is it the tool meant to be able to extract all valid (for a notion of valid that, as we have seen, have drifted over time) Debian source packages that have ever existed in Debian releases? Picking one gives an answer to the more specific question of adding or not a --force flag. Thanks for your time on this, Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#740883: dpkg-source -x regression: version number does not start with digit
On Wed, 2014-03-05 at 22:27:21 +0100, Guillem Jover wrote: On Wed, 2014-03-05 at 20:01:29 +0100, Stefano Zacchiroli wrote: There seems to be at least two other failure causes: - patches not applying cleanly, e.g.: dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -b -z .dpkg-orig ./rx_1.5-6.diff.gz gave error exit status 1 can't find file to patch at input line 3 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.2-potato/rx_1.5-6.dsc.log) I'm checking when this regressed. Ok, this is due to the fuzz level (-F 0), but strictly speaking this never regressed in dpkg-source, as it has used that option since its introduction in dpkg 1.3.0 (pre-rex Debian 1.2). http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commit;h=a9fe21f068524faa2e32a76c412a29371bba08da I'm just guessing those sources where created and extracted manually, probably around the time when the “new source format” got introduced, and where maintainers might have not switched to the new tools yet. http://archive.debian.org/debian/dists/Debian-1.2/main/source/README.source-unpack I'm a bit wary of adding a force option, even if only for format 1.0, to allow something that was never allowed in the first place, also taking into account there's source packages in ancient releases that are in the old format that dpkg-source does not know either. Given the above, in principle I'm tending towards not adding such an option to allow wrong fuzz, but I'll still ponder about this one for a bit. Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740883: dpkg-source -x regression: version number does not start with digit
Hi Guillem, thanks for your quick reply, On Wed, Mar 05, 2014 at 10:27:21PM +0100, Guillem Jover wrote: I've collected the packages that can no longer be extract (without returning a 0 exit code, at least) and made them available here: http://people.debian.org/~zack/dpkg-source-x-regression/ I've now completed the extraction of all releases on archive.d.o and updated the content of the above URL. There is probably no need for you to check again, though, only one extra package from Lenny has been added, and it's again cnews (in a newer version), which cannot be extract due to the version number does not start with digit error. dpkg-source: error: version number does not start with digit Hmm, yeah this type of sanity check should not really be applied on extractors, at least w/o a way to override. I'm fixing this for dpkg 1.17.7. Thanks. If the patch is available somewhere, I'll be happy to cherry pick it for sources.d.n (which is running on Wheezy, i.e. dpkg 1.16.12) and give it a try. - patches not applying cleanly, e.g.: dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -b -z .dpkg-orig ./rx_1.5-6.diff.gz gave error exit status 1 can't find file to patch at input line 3 I'm checking when this regressed. Great. FWIW I'm not entirely sure that this, and the subsequent one, are actually regression at the dpkg-source level. It might also be the case that we did release sources that weren't extractable at release time. If this is due to a change in gzip, then that's something to be dealt in gzip. If the a previous gzip produced bogus data, then I'd rather not workaround that in dpkg-source. If this had been a warning (exit code 2, instead of 1), then I'd be fine changing dpkg-source to ignore gzip warnings, but certainly not if gzip considers it an error. Fair enough. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#740883: dpkg-source -x regression: version number does not start with digit
Package: dpkg-dev Version: 1.17.6 Severity: normal File: /usr/bin/dpkg-source While injecting historical Debian releases from archive.debian.org into sources.debian.net, I've stumbled upon old source packages that can no longer be extracted using dpkg-source -x. I believe this is unfortunate, and that preserving the ability to extract all previously released source packages would be nice. I've collected the packages that can no longer be extract (without returning a 0 exit code, at least) and made them available here: http://people.debian.org/~zack/dpkg-source-x-regression/ A quick overview of what's in there: - the .txt is an index of .dsc that cannot be extracted (the path mentioned in there is local, but can be easily mapped to the file structure of archive.d.o) - the .tar contains the same content of the dir unextractable-dsc for easier download - the dir itself is organized per-release and contains in a flat structure the source packages + a .log file for each of them with the captured output of dpkg-source -x --no-check DSC_FILE The most common (and likely the only real bug) offendere is like this: dpkg-source: error: version number does not start with digit dpkg-source: info: extracting cnews in cnews-cr.g7 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.1-slink/cnews_cr.g7-12.1.dsc.log) there are currently 25 packages that cannot be extracted for that reason (I'm still extracting lenny, but I suspect that would add 1-2 extra packages max; I'll update my archive on people.d.o when done). This seems to be due to the extra check introduced in (thanks Cyril Brulebois for finding it): http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=0cacb0c3a1d1f837c957f3917a040ace6d60f9e7 I haven't yet tried reverting the commit and redoing the extraction. There seems to be at least two other failure causes: - patches not applying cleanly, e.g.: dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -b -z .dpkg-orig ./rx_1.5-6.diff.gz gave error exit status 1 can't find file to patch at input line 3 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.2-potato/rx_1.5-6.dsc.log) - corrupted .gz file (the .diff.gz, by the look ofit), e.g.: dpkg-source: info: applying xfaces_3.3-14.diff.gz gzip: stdin: unexpected end of file dpkg-source: error: gunzip gave error exit status 1 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.2-potato/xfaces_3.3-14.dsc.log) These might be genuine source packages bug that we let flow into old releases --- I haven't checked yet. But if OTOH they are due to changes in, say, gzip, it'd be nice to have a way for dpkg-source to cope with these too, and preserve the ability to extract ancient packages. ... and thanks a bunch for maintaining dpkg! Cheers. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dpkg-dev depends on: ii base-files7.2 ii binutils 2.24-3 ii bzip2 1.0.6-5 ii libdpkg-perl 1.17.6 ii make 3.81-8.3 ii patch 2.7.1-4 ii xz-utils 5.1.1alpha+20120614-2 Versions of packages dpkg-dev recommends: ii build-essential 11.6 ii fakeroot 1.19-2 ii gcc [c-compiler] 4:4.8.2-2 ii gcc-4.6 [c-compiler] 4.6.4-5 ii gcc-4.7 [c-compiler] 4.7.3-11 ii gcc-4.8 [c-compiler] 4.8.2-16 ii gnupg1.4.16-1.1 ii gnupg2 2.0.22-3 ii gpgv 1.4.16-1.1 ii libalgorithm-merge-perl 0.08-2 Versions of packages dpkg-dev suggests: ii debian-keyring 2014.01.31 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740883: dpkg-source -x regression: version number does not start with digit
On Wed, 2014-03-05 at 20:01:29 +0100, Stefano Zacchiroli wrote: Package: dpkg-dev Version: 1.17.6 Severity: normal File: /usr/bin/dpkg-source While injecting historical Debian releases from archive.debian.org into sources.debian.net, I've stumbled upon old source packages that can no longer be extracted using dpkg-source -x. I believe this is unfortunate, and that preserving the ability to extract all previously released source packages would be nice. This should be considered a bug, yes. I've collected the packages that can no longer be extract (without returning a 0 exit code, at least) and made them available here: http://people.debian.org/~zack/dpkg-source-x-regression/ Thanks. The most common (and likely the only real bug) offendere is like this: dpkg-source: error: version number does not start with digit dpkg-source: info: extracting cnews in cnews-cr.g7 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.1-slink/cnews_cr.g7-12.1.dsc.log) there are currently 25 packages that cannot be extracted for that reason (I'm still extracting lenny, but I suspect that would add 1-2 extra packages max; I'll update my archive on people.d.o when done). This seems to be due to the extra check introduced in (thanks Cyril Brulebois for finding it): http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=commitdiff;h=0cacb0c3a1d1f837c957f3917a040ace6d60f9e7 I haven't yet tried reverting the commit and redoing the extraction. Hmm, yeah this type of sanity check should not really be applied on extractors, at least w/o a way to override. I'm fixing this for dpkg 1.17.7. There seems to be at least two other failure causes: - patches not applying cleanly, e.g.: dpkg-source: error: LC_ALL=C patch -t -F 0 -N -p1 -u -V never -g0 -b -z .dpkg-orig ./rx_1.5-6.diff.gz gave error exit status 1 can't find file to patch at input line 3 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.2-potato/rx_1.5-6.dsc.log) I'm checking when this regressed. - corrupted .gz file (the .diff.gz, by the look ofit), e.g.: dpkg-source: info: applying xfaces_3.3-14.diff.gz gzip: stdin: unexpected end of file dpkg-source: error: gunzip gave error exit status 1 (from http://people.debian.org/~zack/dpkg-source-x-regression/unextractable-dsc/2.2-potato/xfaces_3.3-14.dsc.log) These might be genuine source packages bug that we let flow into old releases --- I haven't checked yet. But if OTOH they are due to changes in, say, gzip, it'd be nice to have a way for dpkg-source to cope with these too, and preserve the ability to extract ancient packages. If this is due to a change in gzip, then that's something to be dealt in gzip. If the a previous gzip produced bogus data, then I'd rather not workaround that in dpkg-source. If this had been a warning (exit code 2, instead of 1), then I'd be fine changing dpkg-source to ignore gzip warnings, but certainly not if gzip considers it an error. Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
