On Tue, 23 Dec 2008 13:09:21 -0000 "Adam D. Barratt" <a...@adam-barratt.org.uk> wrote:
> > Also, bug #509453 has now disappeared from the list of bugs affecting > > the source package soci, only 504907 now shows up. > > Indeed; #509453 would need reassigning to src:soci as well. Done - remarked it found too. > [...] > > That could be extended a bit to say: > > dch warning: bug #509453 belongs to package soci, > > which might be the source package. disabling closing changelog entry > > To reassign to soci source use: 'bts reassign 509453 src:soci' > > dch: Did you see that warning? Press RETURN to continue... > > > > Maybe only if $bugpkg == $PACKAGE ? > > Yeah, that seems like a reasonable idea. > > > > [For reference, I believe that #509498, filed a short while ago against > > > bugs.debian.org is another instance of the same underlying issue]. > > > > This does seem to be a bug in b.d.o and the same issue as 509498. > > > > I'm thinking we could change this bug report into a wishlist for > > src: to be documented in the bts manpage and maybe hinted in the error > > line from debchange and mark it blocked by 509498. > > If you're happy with that, then so am I. :) OK, that's done (albeit with a minor problem where the b.d.o bug got retitled instead of this one because I used one too many "it"'s in the bts command). I didn't realise that bts updated the value of 'it' according to the immediate previous bug number rather than sticking with the first: $ bts severity 509472 wishlist , block it by 509498 , retitle it "[debchange] clarify error message when using --closes with source packages" ends up retitling 509498, not 509472. A bit counter-intuitive that. > > To close 509498, I believe it would be necessary for 'bts status' to > > receive the relevant data to populate the source field *and* not list > > the package as "src:soci" in this case, just as "soci". > > "bts status" literally displays the data returned to it by the BTS, which is > why the output sometimes appears a little odd. I'd prefer not to change that > as it has the potential to create confusion when compared to other > representations of the data (although obviously I'm open to being convinced > I'm wrong, and my co-maintainers may disagree). > > I'll query whether the BTS is likely to start returning a useful "source" > field for such bugs, but I probably won't have chance to follow that up > until after Christmas; let's see where that leads. OK, thanks. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpHIAmxrmDL0.pgp
Description: PGP signature