Monday 15 September 2008 skrev Steve Langasek:
> On Mon, Sep 15, 2008 at 06:51:15AM -0000, Flemming Bjerke wrote:
> > Sorry, you are right. But, I found it very offensive that someone
> > (anonymously) deliberately made a bug in order to trouble me, having the
> > explicit purpose of getting me to mob a developer.
>
> Well, this is false.  
Now, I see you are right.

> No one deliberately added a bug, and the bug here is 
> not the one you've described.  

Indeed, it is the one I have described:

I noticed two things from ucf: 

1. # uncomment after a while to begin nagging
        # maintainers to fix their scripts.
(according dictionary,com does "nag" mean:
- to annoy by persistent faultfinding, complaints, or demands.
- to keep in a state of troubled awareness or anxiety, as a recurrent pain or 
problem)
In my view, "nagging" is not a nice thing to do.

2. If the following condition is fulfilled:
if [ "$DEBCONF_ALREADY_RUNNING" ] && [ "$DEBCONF_OK" = NO ]; then
Then, ucf returns an error because the following gives an error: 
==============
<<END
*** WARNING: ucf was run from a maintainer script that uses debconf, but
             the script did not pass --debconf-ok to ucf. The maintainer
             script should be fixed to not stop debconf before calling ucf,
             and pass it this parameter. For now, ucf will revert to using
             old-style, non-debconf prompting. Ugh!

             Please inform the package maintainer about this problem.
END
===============

From 1. and 2. I inferred that now the quoted lines had been uncommented in 
order to nag the developer - which probably is true. Moreover, it IS a bug, 
because the script returns an error under one of the conditions foreseen in 
script. 

However, now I see what must have happened. On my PC, I have two systems: An 
old ubuntustudio and a kubuntu-hardy. On the kubuntu hardy all the relevant 
text is commented. On the ubuntu-studio the END-text quoted above is not 
commented (see attachment), BUT	the cat command is still commented. Thus, the 
person who removed the #'s, forgot to remove it from the line 
# cat \
and thus made a bug. That is, to nag the developer, he made a bug. But, it was 
not deliberate that it became a bug that may obstruct upgrade. It should just 
have been a comment written in the prompt during installation.

> The bug is that HERE docs don't fail 
> gracefully in the event of disk space problems, as you must have had when
> upgrading, 

As I wrote, I DID check if there was enough diskspace, and there was app. 1GB 
on sdb1 and 3 GB on sdb3! (That should suffice for upgrade samba + 
kubuntu-desktop: app. 20 MB.) I was quite confused over this. I haven't got 
into details with that I tried to remove samba as it couldn't be installed. 
This involved uninstalling kubuntu-desktop, which I did, too. Then, I 
re-installed kubuntu-desktop and (unfortunately) samba, too. Again samba made 
an error, that persisted till I commented the quoted END-text. Then, the 
errors disappeared, and samba was installed. In short, it looks like the 
disk-full-message came BECAUSE of the bug. Yes, I know it sounds strange, 
but ... .

> and this wasn't taken into account when commenting out the 'cat' 
> command (probably because it was completely unforeseen by the author of ucf
> - this was a surprising error message that I had never seen before,
> either).
>
> There's also a second bug here, which is that this line should never even
> be reached because samba-common is *not* calling ucf incorrectly; it is
> passing the --debconf-ok argument, but ucf does this check before it
> reaches the argument parsing block.

Yes. Unfortunately, I don't know how to reproduce the bug. Probably the 
condition is not fulfilled any more:

if [ "$DEBCONF_ALREADY_RUNNING" ] && [ "$DEBCONF_OK" = NO ]

Even if I first run:
aptitude purge samba-common sambe-client

Perhaps, it is only when udgrading samba that the condition may be fulfilled.

This probably also explains why (most?) others don't experience the problem.
>
> Fixing the latter bug would resolve the former in almost all cases anyway;
> and if the user's disk is full, this is likely the least severe bug one
> could possibly run into during an upgrade as a result.

But, it wasn't full. 

-- 
Flemming Bjerke
Hyldebjerg 67
DK-4330 Hvalsø
Phone: +45 46928846
Mobile: +45 22120366