[Bash-completion-devel] Bug#498474: Bug#498474: moreinfo

Thu Sep 11 08:54:22 UTC 2008

On Thu, 2008-09-11 at 09:17 +0200, David Paleino wrote:
> Hi Lucio,
> please keep all us CCed :)

(Reply-all is handy with bug reports - especially when you have more
people than just the submitter and the maintainer involved.)

> On Thu, 11 Sep 2008 02:28:18 +0200, Lucio Crusca wrote:
> 
> > Currently I have no access to the only box where I can reproduce this bug (it 
> > is a fileserver at a customer's office). However I'll post here all the info 
> > you ask as soon as I can access the server.
> 
> Ok, thanks.

Also, Lucio, please add the output from this command:

$ ls -l /bin/sh

on the affected box. (that's the lower case L option to ls).

> > <rant>
> > About the RC bug argument: I didn't even know that a grave bug is RC while an 
> > important one isn't. I simply read the instructions that reportbug prints on 
> > the screen: it says that the bug is grave when the package is completely 
> > unusable, and that's exactly the situation on said server. Is it not a 
> > bash-completion bug? Ok, I take your word, but please recognize it's not easy 
> > for non-developers to identify the right package...

True, although you can generally take a hint if the package contains a
directory /etc/foo/bar.d/ or /etc/foo.d/ because those .d directories
are intended for system administrators or other packages to just "drop"
in their own files using an agreed syntax. Think /etc/init.d/ - no one
package owns all those files, each file is individually managed.
Reporting a bug against the package that creates /etc/init.d/ instead of
the package that puts a particular file into /etc/init.d/ does not make
sense once you understand how .d directories are generally used. That
isn't a Debian thing, that's a UNIX thing.

Probably the first thing to do with bugs like this is try to reproduce
it on a different system. If it cannot be reproduced and the package
uses a .d directory, you know the blame must lie elsewhere and you can
start to narrow down the list of possible packages by checking the
listing in the .d directory. In most cases, the filename with match the
package responsible, otherwise dpkg -S /etc/bash_completion.d/$filename
will identify which package put the file in place.

$ dpkg -S /etc/bash_completion.d/emdebian-qa
emdebian-qa: /etc/bash_completion.d/emdebian-qa

You can then fix this problem for your customer by moving a single file
out of the way:
# mv /etc/bash_completion.d/foo /home/user/bar/
(or move it to your USB stick etc. and test it at home.)

To test the file, start a new terminal window and use:
. /home/user/bar/foo

exit that shell, then comment out each block in the file one at a time
and retest. When you have identified which block of code is responsible,
you can put the file back with the appropriate section commented out and
the customer will only then be missing a single completion.

This is all standard bug-triage work that most users will already be
doing. Bugs are far more likely to get fixed if a little bit of testing
is done on the affected system *before* filing a bug.

(Maybe reportbug should hint about something like that, or maybe
bash-completion {or bash} can add a presubj file to reportbug to suggest
something like that. Hmmm, this bug could end up being cloned twice.)

As I've shown, bash completion works perfectly well with and without the
bash-completion package on my test systems. I'm beginning to think that
bash should take more responsibility for checking the contents
of /etc/bash_completion.d/ and documenting how to use it.

> In fact, it's maintainer's duty to re-assign the bug if it's the wrong
> package... don't worry :)

Agreed. Users can but the maintainer is the one who needs to if nobody
else does. To do that, the maintainer needs that listing I asked for, so
once you have a connection to that server and send in the listing,
things will be a lot easier for everyone.

> > a common user who takes himself the time to report a bug could even think
> > it's a bash bug (though a minor one in that case).
> 
> And, in fact, many bugs reported to bash are re-assigned by bash's maintainer
> to bash-completion :)
> 
> > I think you developers/maintainers should be thankful when someone reports a
> > bug,
> 
> We *are* thankful!

Ditto.

> > instead of complaining about mistakes in the bug report
> 
> Those *were* *not* complains... just suggestions.

Hence the /me prefix - hints, gentle pointers in the right direction.

> > and arguing I deliberately raised the bug severity in hope to get faster
> > attention.
> 
> It wasn't your case, it was a "general concept": it has happened that users
> raised the severity to get more attention... I excuse myself (and Neil, I
> suppose) if this wasn't clear :(

Guess I missed a smilie in that case. It was not my intention to make a
personal accusation, just comment on the general problem. Each case can
have a different cause - this time it was a lack of understanding
about /etc/bash_completion.d/ and how it is used. If you had known
about .d and how it is used, you may have passed the suspect file to
reportbug and reportbug would have identified the right package from
that information (and it would probably not have been bash_completion
because even after installing bash-completion alongside all the other
completion scripts in /etc/bash_completion.d/ I have no problems with
completion).

> > I've read the reportbug instructions and thought twice about what severity to
> > choose and finally I choose what seemed the best fit based on my
> > observations. Is the "grave" severity badly described in reportbug? Fix it!
> > You are the developers after all! </rant>
> 
> Probably it's badly described, after all ;)

I'm not sure reportbug can do that much more - it does need to cover all
packages after all. The problem is that this is not a bug in
bash-completion, it is a bug in a package that uses bash-completion. As
such, it is unlikely that the package at fault absolutely relies upon
bash-completion and cannot possibly operate without it. Therefore, once
the correct package is identified, the fix would be to simply remove the
relevant file from /etc/bash_completion.d/ to restore full bash
completion for all other packages. With a little understanding of how
a .d directory is used, this bug would have been easier to file using
reportbug with the existing instructions. reportbug would have
identified the package responsible for the problematic file and the
severity would have been lower because you would be able to see that it
is only one part of package 'foo' that is broken.

Therefore, this is a wishlist bug in bash-completion seeking better
documentation (an explicit manpage for /etc/bash_completion.d/ or a
general manpage for bash-completion that clearly
documents /etc/bash_completion.d/ and explains that other packages put
files into it.). The bash manpage is extremely long (as one would
expect) but I couldn't find any mention of /etc/bash_completion.d/ in
it. (/etc/bash_completion.d/ works even without bash-completion itself
being installed so maybe this bug is a bug in bash rather than
bash-completion after all and could be reassigned as wishlist against
bash, preferably asking for a separate manpage to cover completion and
bash_completion.d/.) That is a choice left to the maintainer. ;-)

At the same time, the bug needs to be cloned and reassigned to whichever
package is responsible for the broken file in /etc/bash_completion.d/ -
depending on the package, this could be a bug of severity important,
normal or minor.

In no way is this an RC bug (severity critical, grave or serious).

The bit about breaking unrelated software does not apply to this bug - a
bug in a bash_completion script may well affect completion for other
packages but that is related software, not unrelated. True, maybe bash
could be more intelligent about parsing files
in /etc/bash_completion.d/, maybe dh_bash-completion should be extended
to support error parsing during builds and be brought fully within
debhelper so that it can be made a compulsory step in using
bash_completion (I have several completion scripts and have never used
dh_bash-completion because it means build-depending on bash-completion).
None of that detracts from the fact that bash-completion, as a package,
is not buggy in this respect.

> > Anyway, I don't understand how that can be a bug of a different package, but, 
> > again, I take your word.
> 
> bash_completion, besides the code in /etc/bash_completion itself, can read the
> code from files in /etc/bash_completion.d/, and *any* package can install files
> there (i.e. can provide completions for bash...)

Hence the list of files in my request and the comment that any of those
*packages* could not be the cause of this bug because I have lots of
bash completion in usage and the bash completion code itself is *not*
buggy in this respect.

Some package has dropped a file into /etc/bash_completion.d/ on your
test system that is not installed on my system (or David's by the sound
of it) and it is one of these files that is buggy. Identifying which
packages you have installed that I do not have installed is a key part
of identifying the cause of this bug. Moving the ones that differ aside,
one by one, will fix your problem.

Files in /etc/bash_completion.d/ map directly to other packages where
this bug could be reassigned. The fact that bash_completion itself is
*not* broken on other systems means that the reportbug severity was a
mistake, borne out of a misunderstanding of what .d directories do and
how bash completion works.

> Please, provide the info Neil asked ASAP :)

Ditto.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20080911/f13afcb2/attachment-0002.pgp 