[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Rejected: epcr_2.3.9-1.dsc: sha1 check failed

On Thu, Apr 17, 2008 at 07:04:39AM -0400, Roberto C. Sánchez wrote:
> On Thu, Apr 17, 2008 at 08:48:21AM +0100, Adam D. Barratt wrote:
> > 2.10.25 should migrate to testing over the weekend, so hopefully a bpo 
> > package won't be too much longer. In the meantime it's fairly easy to 
> > backport yourself, as several people have already done, or simply copy the 
> > new script over from an unstable machine. Other than the update for the new 
> > .changes file format, there have been relatively little changes to debsign 
> > since the version in etch, and those have all been bugfixes.
> > 
> IMO, that sort of misses the point.  While I maintain quite a few
> packages in Debian, the only places I run unstable/testing are in one VM
> (for testing/reproducing/fixing bugs that I cannot reproduce in stable)
> and in some chroots.  The point is that I should be able to build my
> packages inside of a pbuilder or other type of chroot, sign the package
> on my host system and be reasonably sure that my package will be
> accepted into the archive.  If the archive software breaks compatibility
> with the current stable release of (insert name of whatever tool is
> affected, specifically devscripts in this case), then it looks bad on
> Debian.

You're mixing stable and unstable tools.  You have to expect that you may run
into incompatibilities -- that happens with feature development.  As far as I
know, we only require that *upgrades* from one stable release to the next
stable release will work, not intermingling tools between them.  The only
thing about this that looks bad, IMO, is that we had some bad timing on
uploads (which happens in unstable) and that we have developers who can't pay
attention to debian-devel-announce.

devscripts (and the debsign tool) is simply a convenience package and not
having an up-to-date version of the package does not prevent you from doing
your work.  You can just as easily run dpkg-buildpackage in a chroot to build
your packages and that has been generating proper signed .changes files the
entire time.

On the plus side, debsign is now more resilient to future changes in the
Format of .changes files (as will mergechanges in the next upload).  This only
changes *when* the reject happens though (at debsign run instead of at
upload), not whether it happens at all.  Hopefully other tools which parse the
.changes file have also learned from this experience and taken similar steps
to prevent operating on Formats they don't understand.

GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan@debian.org>

Attachment: signature.asc
Description: Digital signature

Reply to: