Bug#447523: splashy: timeout error due to fsck on big partitions

[Luca Capello]

Package: splashy
Version: 0.3.5
Severity: normal

Hello,

every time my partitions are checked at boot I get the following:
=====
Will now check all file systems.
[...]
[/sbin/fsck.ext3 (1) -- /mnt/movies] fsck.ext3 -a -C0 /dev/mapper/vggismo-lvmovies
/mnt/movies has been mounted 30 times without being checked, check forced.
Splashy ERROR: Timeout (120 sec) occurred while waiting for a message on the Splashy socket
/mnt/movies: 95379/3744608 files (2.1% non-contiguous), 6153446/7476224 blocks
[...]

Done checking file systems.
A log is being saved in /var/log/fsck/checkfs if that location is writable.
=====

Thx, bye,
Gismo / Luca

-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages splashy depends on:
ii libc6 2.6.1-6 GNU C Library: Shared libraries
ii libglib2.0-0 2.14.2-1 The GLib library of C routines
ii libmagic1 4.21-3 File type determination library us
ii libsplashy1 0.3.5 Library to draw splash screen on b
ii lsb-base 3.1-24 Linux Standard Base 3.1 init scrip
ii zlib1g 1:1.2.3.3.dfsg-6 compression library - runtime

splashy recommends no packages.

-- no debconf information

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Luca Capello]

Hi there!

On Sat, 14 Apr 2012 09:06:17 +0200, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the splashy package:
>
> #447523: splashy: timeout error due to fsck on big partitions
[...]
> From: Neil Williams <code...@debian.org>
> Subject: Closing
[...]
> notfound 447523 0.3.5

I disagree on this, read below.

> splashy is no longer in Debian as oldstable has been cleared in preparation for the Wheezy freeze.

The fact that splashy is no longer in Debian (because of #648063) is one
thing, which does not mean that the bug I reported had not been found in
that specific version.

What is the rationale against simply closing the bug without touching
the reported version?

[Neil Williams]

On Sat, 14 Apr 2012 15:05:14 +0200
Luca Capello <lu...@pca.it> wrote:

> > #447523: splashy: timeout error due to fsck on big partitions
> [...]
> > From: Neil Williams <code...@debian.org>
> > Subject: Closing
> [...]
> > notfound 447523 0.3.5
>
> I disagree on this, read below.
>
> > splashy is no longer in Debian as oldstable has been cleared in preparation for the Wheezy freeze.
>
> The fact that splashy is no longer in Debian (because of #648063) is one
> thing, which does not mean that the bug I reported had not been found in
> that specific version.
>
> What is the rationale against simply closing the bug without touching
> the reported version?

For the benefit of the bug report, this was done so that the bug can be closed with -done instead of the deprecated / special purpose -close.

The found version is still listed in the bug report itself, removing the found status simply allows the bug to be archived.

I don't see what purpose the found status field will achieve once the bug is archived as the package does not exist in Debian.

--


Neil Williams
=============
http://www.linux.codehelp.co.uk/

[Colin Watson]

On Sat, Apr 14, 2012 at 04:15:16PM +0100, Neil Williams wrote:
> On Sat, 14 Apr 2012 15:05:14 +0200
> Luca Capello <lu...@pca.it> wrote:
> > What is the rationale against simply closing the bug without touching
> > the reported version?
>
> For the benefit of the bug report, this was done so that the bug can
> be closed with -done instead of the deprecated / special purpose
> -close.

Last I checked - and admittedly it's a little while since I was really
an active BTS administrator, but the current documentation seems to
agree with me - the -done and -close addresses were synonymous, and
neither was deprecated. Perhaps you're thinking of the 'close' command
to control@bugs and the prefixed '-' was a typo.

Rather than removing the found data, it's more usual to mark the bug as
(pseudo-)fixed in a version that's slightly greater than the last one in
the archive. The current convention is to mail -done/-close with the
following pseudo-header at the start of your e-mail body:

Version: 0.3.13-5.1+rm

This would actually have been less effort as you wouldn't have had to
duplicate all the bug numbers between the To: line and all those
'notfound' commands. Nowadays, dak can be told to do this when removing
packages, and you can see the code and e-mail template it uses here:

http://anonscm.debian.org/gitweb/?p=mirror/dak.git;a=blob;f=dak/rm.py
http://anonscm.debian.org/gitweb/?p=mirror/dak.git;a=blob;f=templates/rm.bug-close-related

> I don't see what purpose the found status field will achieve once the
> bug is archived as the package does not exist in Debian.

I agree that it's a bit academic, but perhaps the argument that the
usual convention is actually less effort will be persuasive :-), along
with matching what dak does. In general (although perhaps not in this
specific case) we like to keep the found versions around in case the
package is ever reintroduced.

--
Colin Watson [cjwa...@debian.org]

[Neil Williams]

On Sat, 14 Apr 2012 16:47:36 +0100
Colin Watson <cjwa...@debian.org> wrote:

> On Sat, Apr 14, 2012 at 04:15:16PM +0100, Neil Williams wrote:
> > On Sat, 14 Apr 2012 15:05:14 +0200
> > Luca Capello <lu...@pca.it> wrote:
> > > What is the rationale against simply closing the bug without touching
> > > the reported version?
> >
> > For the benefit of the bug report, this was done so that the bug can
> > be closed with -done instead of the deprecated / special purpose
> > -close.
>
> Last I checked - and admittedly it's a little while since I was really
> an active BTS administrator, but the current documentation seems to
> agree with me - the -done and -close addresses were synonymous, and
> neither was deprecated. Perhaps you're thinking of the 'close' command
> to control@bugs and the prefixed '-' was a typo.

Ah, OK. I think I had -close == close in mind.

> Rather than removing the found data, it's more usual to mark the bug as
> (pseudo-)fixed in a version that's slightly greater than the last one in
> the archive. The current convention is to mail -done/-close with the
> following pseudo-header at the start of your e-mail body:
>
> Version: 0.3.13-5.1+rm
>
> This would actually have been less effort as you wouldn't have had to
> duplicate all the bug numbers between the To: line and all those
> 'notfound' commands. Nowadays, dak can be told to do this when removing
> packages, and you can see the code and e-mail template it uses here:
>
> http://anonscm.debian.org/gitweb/?p=mirror/dak.git;a=blob;f=dak/rm.py
> http://anonscm.debian.org/gitweb/?p=mirror/dak.git;a=blob;f=templates/rm.bug-close-related

For whatever reason, dak didn't send those emails when the package was
removed - in the case of the entire opensync removal, that was because
there were so many packages to remove that ftpmaster recommended a
single RM report using multiple entries in the title but that hits a
bug in dak which won't send the bug reports for multiple RM requests in
the same operation. :-(

So, after doing all of this for the opensync bugs (which was ~100
bugs), I followed the same method for this package when I found it
listed in the QA page about bugs without maintainers.

I could have used +rm but that seemed a little misleading as most
people will interpret that as the output of dak.

> > I don't see what purpose the found status field will achieve once the
> > bug is archived as the package does not exist in Debian.
>
> I agree that it's a bit academic, but perhaps the argument that the
> usual convention is actually less effort will be persuasive :-), along
> with matching what dak does. In general (although perhaps not in this
> specific case) we like to keep the found versions around in case the
> package is ever reintroduced.

Usual convention, yes, probably. I was more trying to avoid making my
cleanup look like the dak operation which somehow went awry originally.

If I have to do this again in future, I think I'd probably use +qa.
TBH, I don't mind either method, this kind of task is only needed
relatively rarely.

[Luca Capello]

Hi there!

On Sat, 14 Apr 2012 17:15:16 +0200, Neil Williams wrote:
> On Sat, 14 Apr 2012 15:05:14 +0200
> Luca Capello <lu...@pca.it> wrote:
>
>> > #447523: splashy: timeout error due to fsck on big partitions
>> [...]
>> > From: Neil Williams <code...@debian.org>
>> > Subject: Closing
>> [...]
>> > notfound 447523 0.3.5
>>
>> I disagree on this, read below.
>>
>> > splashy is no longer in Debian as oldstable has been cleared in preparation for the Wheezy freeze.
>>
>> The fact that splashy is no longer in Debian (because of #648063) is one
>> thing, which does not mean that the bug I reported had not been found in
>> that specific version.
>>
>> What is the rationale against simply closing the bug without touching
>> the reported version?
>
> For the benefit of the bug report, this was done so that the bug can
> be closed with -done instead of the deprecated / special purpose
> -close.

According to the BTS documentation, -done does not absolutely need a
Version: line:

<http://www.debian.org/Bugs/Developer#closing>

Where applicable, please supply a Version line in the pseudo-header of
your message when closing a bug, so that the bug tracking system knows
which releases of the package contain the fix.

> The found version is still listed in the bug report itself, removing
> the found status simply allows the bug to be archived.

If this is true (thus a bug to be archived needs no open found status),
then I would say that the BTS archive option is not completely working:
the bug should be available for archive, no matter its found status, at
least in these special situations.

Moreover, if I want to reintroduce splashy I would need a *quick* way to
know which bugs were present in the last version in Debian, which is now
impossible without looking at *each* bug.

> I don't see what purpose the found status field will achieve once the
> bug is archived as the package does not exist in Debian.

The package *existed* in Debian, at the time the bug was reported, so
the information for that time are still true. We are re-writing the
history here, which is IMHO plainly wrong.

Just to be clear: I am perfectly fine with closing this kind of bugs,
but I do not agree on the method. Anyway, I expressed my opinion
without doing any work, so this will be my last email on this subject.