Hello,
On antradienis 14 Birželis 2011 18:58:51 Christoph Egger wrote:
> Modestas Vainius <modax@debian.org> writes:
> > Modestas Vainius <modax@debian.org> writes:
> >> please correct me if I'm wrong but I heard that you could give back
> >> packages in squeeze-backports. If so, please give back ktorrent on
> >> armel i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips s390. What's more,
> >> libktorrent/powerpc (also in squeeze-backports) seems to be stuck at
> >> Uploaded state for 2 days already.
> >
> > Is that the same for amarok which seems to have failed in a quite
> > similar way?
>
> And it does not work. Still fails
This seems to be sbuild 0.61 problem (sbuild 0.60 works, e.g. mipsel
succeeded):
sbuild (0.61.0-1) unstable; urgency=low
* sbuild:
- The apt and aptitude build dependency resolvers now use only the
first alternative in alternative dependencies. The other
alternatives are stripped out entirely. This makes the apt and
aptitude resolvers behave exactly like the internal resolver.
Note that this is configurable with the $resolve_alternatives
option, so alternative resolving may be re-enabled with this
option if desired. This is useful for e.g. backports, but not
for unstable where the strict consistency and reproducibility
offered by only using the first alternative is required.
... which can be fixed by setting $resolve_alternatives or upgrading to sbuild
0.62.0:
sbuild (0.62.0-1) unstable; urgency=low
...
+ The aptitude resolver can resolve complex dependencies, e.g.
A | B, where A is uninstallable now correctly falls back to B.
This is not the case for the internal or apt resolvers, which by
intent do not make use of alternatives (they use the first
alternative only. sbuild now has full support for resolving
alternatives, but this is not the default behaviour
(Closes: #403246). Please see #614807 for a proposed description
of autobuilder-imposed build dependency restrictions in Policy.
...
While previous 0.62.x releases were quite troublesome, 0.62.2 looks quite
decent. Any hope that bpo buildds will be fixed or upgraded?
--
Modestas Vainius <modax@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part.