Re: dependent packages blocked from testing
Am Freitag, den 19.07.2013, 13:02 +0600 schrieb Andrey Rahmatullin:
> On Fri, Jul 19, 2013 at 07:53:51AM +0200, Tobias Frost wrote:
> > Ltt-controls has not been built on all archs (those out of date messages on the PTS). Seems that there are build deps not available.
> > (Take a look at the buildds status page)
> It waits for ust to be built on ia64, mips, mipsel, s390, s390x and sparc.
Ok, lets analyze
buildd's status page says:
"Dependency installability problem for ltt-control on hurd-i386,
kfreebsd-amd64 and kfreebsd-i386:
ltt-control (= 2.1.1-2) build-depends on missing:
- liburcu-dev (>= 0.7.4)
So on the above archs, it does not build due to problems with
liburcu-dev. But as this archs are never built before, so they are
not blocking the transistion. Of course, you could take a look at
liburcu if you can fix the FTBFs...
> Out of those, ia64 build just fails while mips, mipsel, s390x and sparc
> need systemtap-sdt-dev, which does not exist on those arches for at least
> quite some time. s390 has "No entry in s390 database" which I have no idea
> about.
Yes, for those archs you'll need fix ust, which has problems with
systemtap-sdt-dev.
As Systemtap-sdt-dev is only available for i386 amd64 ia64 s390 powerpc
armel armhf, you
1) (if possible) configure ust to not use systemtap-sdt on the other
archs (I do this for example in drizzle, there drizzle's configure
automatically checks if it is available and does not utilize it if not
-- of course debian/control then needs arch-dependent
build-dependencies)
2) only build for those archs where system-tap is available.
Note: You need to file an remove request for the old version on the
unsupported archs for ust, as they otherwise will block the transition.
(If you go for 2), the rm requests are also needed for ltt-control)
coldtobi
> > Jon Bernard <jbernard@debian.org> schrieb:
> >
> > >Hello,
> > >
> > >I'm facing a problem with two packages that are blocked from migrating
> > >into
> > >testing. I'm having trouble seeing a clear path forward and I wonder
> > >if anyone
> > >could point me in a better direction.
> > >
> > >The specific packages are ltt-control[1] and ust[2]. If the source
> > >packages
> > >only built a single binary package, then apt's arbitrary selection of
> > >one to
> > >break the dependency chain would work, from what I understand. But in
> > >this case
> > >each source package builds several binary packages and I do not see a
> > >clean way
> > >out of this (other than asking the release team to manually move them,
> > >but
> > >I would prefer to find a proper solution). Is there any advise for
> > >this
> > >situation? Specifically, how do I get out of this mess cleanly, and
> > >what could
> > >I have done differently to prevent this from ever happening?
> > >
> > >[1]: http://release.debian.org/migration/testing.pl?package=ltt-control
> > >[2]: http://release.debian.org/migration/testing.pl?package=ust
> > >
> > >Cheers,
> > >
> >
>
> --
> WBR, wRAR
>
>
Reply to: