Re: FTBFS due to upgrade/bug in build-dependency

[Frank Terbeck <ft@bewatermyfriend.org>]

Cyril Brulebois <cyril.brulebois@enst-bretagne.fr>:
> On 10/01/2008, Frank Terbeck wrote:
[...]
> > My question is, if it would be the right thing to do is to reassign
> > the bug to tdb-dev and add a comment about signal.h to it? Or should I
> > rather create a new bug against tdb-dev about the problem?
> 
> Simply reassigning is IMHO OK, but if someone else sees this FTBFS, and
> sees no one reported against your package, that someone could open a bug
> against your package, w/o checking that its root is in another one. What
> I usually do in this case is the following:
>   clone + reassign + retitle + block the old one with the new one.

Okay, I'm not sure if I understand the relevant passages in bts(1),
for these subcommands. So I guess, I better ask in more detail, so I
don't screw up my first manual interaction with the bts. :-)

For clone:

  clone <bug> [new IDs]
    The clone control command allows you to duplicate a bug report. It
    is useful in the case where a single report actually indicates
    that multiple distinct bugs have occurred. "New IDs" are negative
    numbers, separated by spaces, which may be used in subsequent
    control commands to refer to the newly duplicated bugs. A new
    report is generated for each new ID.

What confuses me, is the 'new IDs' argument. My guess is this:

% bts clone 456871 -1

So that I can use '-1' instead of waiting for the new number the
cloned bug get assigned.

For reassign:

  reassign <bug> [<bug> ...] <package> [<version>]
    Reassign a bug or a number of bugs to a different package.
    The version field is optional;

The version argument is to tell the bts that a special version
introduced the bug in question, right? So, I would do:

% bts reassign 456871 tdb-dev '1.1.1~svn26294-1'

The retitle command is clear to me.

  block <bug> by|with <bug> [<bug> ...]
    Note that a bug is blocked from being fixed by a set of other
    bugs.

The command itself is pretty clear.
However, this does not mean, that my bug will be closed once the
cloned bug will be closed by the maintainer of tdb-dev, will it?
If not, what would be an appropriate close message to send once the
bug in tdb-dev is closed?

To wrap it up, I would issue these commands, one after another:

% bts clone 456871 -1
% bts reassign -1 tdb-dev '1.1.1~svn26294-1'
% bts retitle  -1 "usr/include/tdb.h uses sig_atomic_t without\
 including signal.h"
% bts block 456871 by -1

Correct, or did I screw up already?

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925