Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Sunday 12 October 2008, Florian Kulzer wrote:
> On Sun, Oct 12, 2008 at 13:56:57 -0400, Hal Vaughan wrote:
>
> [...]
>
> > I'll ask you to read in this context: 1) You know very little about
> > how packages in Debian are maintained, 2) You know nothing about
> > the internals of apt, 3) You do not know Christian at all, have no
> > idea what he is like, and do not know what to expect, and 4) You
> > have just found what has every appearance of a severe bug:
> > Upgrading some files can keep a system from booting. While your
> > problem is resolved, you're trying to help the distro you prefer
> > keep that from happening to anyone else.
> >
> > With that in mind, notice that nothing said in those posts is at
> > all helpful.
>
> Quoting from the first reply:
> | Please look in /etc/kernel-img.conf, you'll probably find:
> |
> | postinst_hook = /sbin/update-grub
> | postrm_hook = /sbin/update-grub
Actually, I do remember looking up that info, but either didn't see all
the info I expected or found something else that was not as described.
> Quoting from the second reply:
> | I suggest you also read the comments in /boot/grub/menu.lst. They
> | explain very well that some sections of the file are likely to be
> | overwritten when the file is regenerated by update-grub.
> |
> | I guess that the update you made installed a new kernel
> | image...which trigger an update of the grub menu file when the
> | postinst script of the kernel image package is run.
Yes, after I had already fixed menu.lst.
> These are the comments right at the beginning of /boot/grub/menu.lst:
> | # menu.lst - See: grub(8), info grub, update-grub(8)
> | # grub-install(8), grub-floppy(8),
> | # grub-md5-crypt, /usr/share/doc/grub
> | # and /usr/share/doc/grub-doc/.
And when I went through my initial setup with my issue (which involved a
funky Adaptec card) I followed a HOW-TO written up so I could see what
was going on. Remember Daniel's point that devs are only human? Guess
what? So are end users. If I read every man page in detail on every
program or conf file I use, I'd still be reading. I'd have never
gotten anywhere. You know that as well as I. Have you read the full
details in each man page you use? Have you ever had to just follow a
HOWTO or something similar and make sure it works and move on? If so,
you know what I mean. If not -- well, I seriously doubt anyone here
thinks we all can read EACH man page or each conf file in entirety.
> and a bit further down in the same file:
> |### BEGIN AUTOMAGIC KERNELS LIST
> |## lines between the AUTOMAGIC KERNELS LIST markers will be modified
> |## by the debian update-grub script except for the default options
> | below
> |
> |## DO NOT UNCOMMENT THEM, Just edit them to your needs
Yes, and by then I had fixed my problem, but it STILL doesn't fix the
problem: Menu.lst is updated without telling the user. Remember THAT
was the problem! I've seen a pattern with Debian and apt: If a conf
file is going to be overwritten, I'm warned and given a choice. Now
remember that in the next point I make:
> Quoting from the manpage of update-grub:
> | The update-grub script can be ran automagically from the
> | /etc/kernel-img.conf file by adding the following lines:
> |
> | postinst_hook = update-grub
> | postrm_hook = update-grub
> | do_bootloader = no
> |
> | For further information related to /etc/kernel-img.conf, see the
> | manpage kernel-img.conf(5).
Yes, just update-grub. That's it. No script to say, "Do I overwrite
this file?" Or, "Warning: About to overwrite menu.lst." No warning,
just update-grub. This, along with any of the points on grub and
menu.lst are closing the barn door AFTER the cows have left. The issue
was NOT what is in the file, what I had or had not read. The issue was
that the file is overwritten WITHOUT warning or asking permission.
Which, when I filed the bug, made me wonder, "Did he READ what I said?
He's telling me what Grub does, but he's NOT addressing the issue of
the file being overwritten."
If you have an antique car that takes a special oil and bring it to me
to service it and, without telling you, I just change the oil with
a "normal" one, then you start the car and the engine is hosed, what
good will it do me to explain to you how to change the oil? That's
what's going on here. In this case, you'd say, "I KNOW HOW TO CHANGE
THE DAMNED OIL! I KNOW HOW TO DO THAT! I'M MAD BECAUSE YOU DID IT
WITHOUT TELLING ME!"
That's what I'm doing, or was doing, but I wasn't shouting. The issue
was not what was in Grub, but that update-grub is run by either apt,
aptitude, or the kernel package WITHOUT warning. Do you see the
difference? That he dwelt on the info in the remarks in the file and
avoided the issue that the file was overwritten without warning made me
wonder if he had even gotten my point.
> The manpage of kernel-img.conf explains the hooks in more detail.
>>
> > There is no effort, in any of his responses, to say, "Yes,
> > there is a problem here, and while it's not my job to solve it,
> > here's where to look next."
>
> He told you where to look next.
If you're a DD, it may be obvious. It wasn't to me. I'm sorry I'm just
not so freakin' brilliant and so aware of everything Debian that I
missed that point and could not see he was pointing, much less what he
was pointing at.
> > where to look next." What there is, terms of a response, is, "It's
> > not a bug, at least not one I have to worry about."
>
> You never provided details on why update-grub broke your system. If
> you customized menu.lst yourself without reading the comments in the
> original file and the documentation referenced therein then your
> subsequent problem is not a serious bug.
The point was that update-grub is rewriting an important config file
without prompting or warning. Does ANYONE get that?
Or are you so intent on saying, "We, the DDs, are blameless and
everything is perfect, and YOU are wrong" that you don't see that
point?
Again, this is why I don't bother. It's like talking to a brick wall
and the whole thing has wandered from the overall point. Those
responding are more interested in self-defense than listening and
saying, "There may be a point here."
> > There was also the point that I bought up of him saying I did
> > things I did not do, which left me confused. (He said I specified
> > to run update-grub, which I stated I never did unless some package
> > did it without me knowing it.) That's another point that he made
> > no effort to clarify. While it's a small thing, it's just one of
> > many things that left me with the feeling his concern was more to
> > close it out than to solve the overall problem.
>
> He had already given you all the necessary information to fix your
> problem, and there was no indication that a system with a standard
> menu.lst would be affected.
You say he did, you have the background so it made more sense. From
YOUR point of view, yes. From the point of view of someone who doesn't
know the system as well, no. I thought about asking for more, but my
point was an important file was being overwritten. Here's what I
wrote:
"When I did a recent "aptitude update && aptitude upgrade" I received
the prompt that I would have to reboot since kernel modules that were
the same version as my kernel were being updated. In this entire
message neither grub nor /boot/grub/menu.lst were mentioned. When I
rebooted, the system could not boot because update-grub had been run,
totally re-writing my menu.lst file.
For all other configuration files, especially files in /etc, Aptitude
prompts and asks if I want to update them or keep my current version.
There is no such prompt or warning for menu.lst. It is overwritten
without providing a choice of saving it, backing it up, or even
informing the user this is happening."
He told me about grub, he told me about the package, but at the time,
what he gave me was hard to put together with everything else (I don't
have the complete knowledge of all things Debian). Now please tell me
where, in his responses, did he deal with the issue that an important
config file is being overwritten without prompting or warning? Did he
tell me where to go to report that as a bug?
I even re-iterated this and you can see that where he quoted my reply.
Instead of addressing the point of the file being overwritten, he told
me about what was in the file.
There are a lot of reasons people might not want a config file
overwritten. They could be experimenting with different settings, they
could be working with something non-standard, or they could have
customized it for other reasons.
Yet he, and you, have entirely missed and skipped over that point and
nothing he, nor you, have said addresses it. The points you indicate
where you say he helped me do NOT show me he understood that
overwriting a vital config file is an issue, which left me feeling like
he either just didn't get it or didn't see why it was an issue.
Which is one reason I gave up.
> > Also note that this bug includes reporting a bug that can make a
> > system 100% non-functional. Yes, it's a serious bug, yet the
> > response is basically, "Not my problem, go away." Notice he
> > specifically mentions this list as a forum to address it in, which
> > is where I brought it up originally. It may not be outright rude,
> > but when someone brings up a bug that is serious enough to disable
> > a Debian based system and the response is, "It's not my problem,"
> > would you consider that just terse or something more? Just what
> > would you call it when someone, who can help, doesn't want to
> > bother assisting someone who has found a serious bug?
>
> He did assist you.
I've responded to that previously. He dealt with everything but my main
point.
> [...]
>
> > Maybe it's from the jobs I had along the way, but I cannot imagine
> > being part of an organization and someone coming to me for help and
> > saying, "It's not my problem," without doing my best to give them
> > SOME clue on where to go next.
>
> He gave you clues where to go next.
I've responded to that previously. He dealt with everything but my main
point.
> > Again, it's a serious bug. Does it make sense, if someone says,
> > "This action makes a computer unbootable" to not try to prevent it
> > from happening to others also using Debian?
>
> You never followed up with evidence that a standard system would be
> affected and nobody else reported this problem, therefore the bug was
> closed.
No. I didn't bother to. Here's how it went:
Hal: There's a bug here. It disables the whole system. A config file
shouldn't be overwritten without a prompt.
Christian: Not in Apt. I don't know where (he even said something like
that), but it's not here.
Hal: But there's a problem here and aptitude did it somehow (not posted
on report, perhaps I sent it directly, I don't remember).
Christian: It's in aptitude, apt, whatever. It's not a bug here. Write
to the D-U list. And here's info on Grub (not on overwriting files,
but it's about Grub!)
I had already written to the D-U list. I know he didn't know that, but
basically the source I get for other help had bombed out and at this
point I realize it's going to go on in the same pattern:
Hal: There's a problem that needs to be fixed.
Christian: It's not on what I handle, go somewhere else.
Hal: There's a problem that needs to be fixed...
(See endless loop...)
So I gave up. I had it fixed and I had other things to do, so fine,
Debian devs don't want to fix it, they don't have to. By that time I
had fixed it on my own system.
So now we have:
Hal: I don't file bug reports because I've never had one go anywhere.
Devs: You did it wrong.
Hal: Look at what I report and it led nowhere.
Devs: Oh, that's because...
Hal: Okay, let's look closer.
Devs: Oh, that's because...
(Again, see endless loop.)
And that's why I don't bother with bug reports, which is what I said a
long time ago.
You want users to file bug reports? Then listen to them and be sure you
know what they're saying and respond to that point, not to points
around that. And when they say, "There's a problem here," see if there
is instead of spending a ton of effort saying, "There is no problem."
That's what went wrong in that bug report and it's what's going on here.
Hal
Reply to: