On Wed, Aug 10, 2005 at 02:00:36PM +0200, Richard Atterer wrote:
> I just noticed that Steve has scheduled jigdo for removal, so that
> gcc-defaults/gcc-3.4 can enter testing.
Yes. Sorry for this, there's nothing wrong with jigdo itself here, this is
merely a concession to the requirement that packages be installable in
testing: better to have jigdo absent for a few days than to have it present
but uninstallable. (Actually, I was going to go for present but
uninstallable first, since it would only apply to sparc, but britney
rejected me.)
> Soo... I guess 0.7.2-2 will automatically go in at some point, and I don't
> have to do anything?
Correct -- jigdo will get in on its own again once it's ready.
FWIW, the current chain holding the new version of jigdo out is this:
$ grep-excuses jigdo
jigdo (0.7.1-5 to 0.7.2-2)
Maintainer: Richard Atterer
10 days old (needed 2 days)
Removal request by vorlon
Trying to remove package, not update it
Not considered
Depends: jigdo gnutls12 (not considered)
$ grep-excuses gnutls12
gnutls12 (- to 1.2.5-3)
Maintainer: Matthias Urlichs
10 days old (needed 10 days)
Ignoring high urgency setting for NEW package
Valid candidate
Invalidated by dependency
Not considered
Depends: gnutls12 glibc (not considered)
$
There's certainly nothing you can do to shorten the wait time at this point,
since any new uploads will also be blocked on glibc; but i
It's rather unfortunate that the sparc upload is stuck behind the new gnutls
given that curl has already been reuploaded without this dependency.
There's certainly nothing you can do to shorten the wait itme at this point,
since any new uploads will also be blocked on glibc, but going forward I
would strongly recommend fixing up the build rules in your package to
hardcode -lcurl instead of using curl-config --libs. This is certainly not
a portable change that would be appropriate for other architectures, but
Debian policy ensures that tools such as curl-config will always do more
harm than good when building against packaged libs -- such as pulling in a
spurious dependency on a TLS implementation that the HTTP lib itself is no
longer using...
Cheers,
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature