Re: qiime REMOVED from testing
On 2014-01-21 19:45, Andreas Tille wrote:
> Hi,
>
Hi Andreas and d-mentors,
> I hope this is the correct list to ask this questions - if not please
> redirect me (and also please CC me in your reply). [debian-mentors in
> CC as well - may be some other people have a similar problem.]
>
Seems like a reasonable choice for clarifying removals from testing. :)
> I know that qiime has a serious bug (#731190) where I was seeking for
> help six weeks ago with no real result. So I would have expected to
> become kicked from testing because of this bug which would be fine.
>
It could have been kicked out for that reason. Possibly, it would have
been eventually, but qiime would have blocked the transition in question
until then. I will not rule out that the bug was an "enabler" for an
earlier manual removal - personally, I have kicked packages out for
having RC bugs if those bugs stalled the transitions longer than my
patience lasted[0].
> However, it is kicked because of an "old libffi" dependency. I realised
> that it had in fact
>
> libffi6 (>= 3.0.4)
>
> in its dependencies which was included via
>
> ${shlibs:Depends} or
> ${misc:Depends}
>
> but I have no idea, how to prevent this. Would a rebuild be sufficient
> to get the "new libffi" dependency or do I need to do more?
>
> Kind regards
>
> Andreas.
>
> [...]
As you correctly conclude, a binNMU would usually have been sufficient
to update the dependency. However, qiime currently FTBFS on
kFreeBSD[1]. This makes it impossible to binNMU qiime with the purpose
of completely getting rid of the libffi6 dependency (in testing).
The slightly longer story. In order to finish the transition, qiime
would have to stop depending on libffi6 in testing. This generally
happens in one of two ways:
1. qiime gets removed (as it happened here)
2. qiime gets updated on *ALL* architectures with a libffi6 dependency
to no longer depend on libffi6 and this update migrates to testing.
The problem with doing 2. in this case, is that the package FTBFS on
kFreeBSD. So even if binNMUed on all (other) architectures, the
dependency would remain on the kFreeBSD and thus stall the transition.
Now, by the looks of it, this FTBFS has not been filed. For that, I
believe you have suffered from the problem mentioned in [2].
~Niels
[0] My patience for RC bugs stalling transitions may be a function over
how much time / energy I have to keep track of the transition in
question or how fed up I am with it "still not being done yet".
[1] https://buildd.debian.org/status/package.php?p=qiime
[2] https://lists.debian.org/debian-devel/2013/12/msg00611.html
"""On a related note, I suspect a good part of this problem would go
away if we had an automated tool to deal with the case where a
(sid-only) FTBFS is ignored. It happens sometimes that the maintainer
does nothing (or, maybe, does not realise the package FTBFS on arch X)
and neither the porters nor the buildd admins filed a bug for it.
Then it is not until the package gets in way of a transition (or some
other RC bug fix), that the package gets its RC bug. I have seen a
package stuck in sid for at least 90 days and still no RC bug - the
"only" thing wrong was an "Out of date binaries" on some architecture
(don't remember which package nor which architecture).
"""
Reply to: