Hi,

I just manually closed #1020185, #1020167, #1020160.

They had all been fixed version and was no longer affecting any version
in any supported distribution. However, they had never been `-done`'ed,
so they remained "open" and visible on tracker.d.o as an example and
visible in the graph on https://qa.debian.org/data/bts/graphs/d/dh-elpa.png.

I feel debbugs could just auto-done these after a delay (like 30 days)
once the last affected version disappears and there is at least one
fixed version.

Best regards,
Niels

Thanks for the report!

On Sun, 24 Aug 2025, Niels Thykier wrote:n

The way to fix this is to not close bugs using fixed, but to close them
using -done when they are first completed.

Using -done notifies the submitter and has a bunch of other nice
properties that just setting fixed doesn't.

There's an argument to be made that we should instead warn loudly if a
bug has been fixed without having been -done so the person marking it
fixed knows to send a message to -done as well.

Don Armstrong:

I agree that this is the official best practice for how to close a bug,
and I understand why it is the best practice. But it is also not a very
useful answer to this problem, which is me questioning a failure mode
where the official best practice was not followed. The bug being in a
pseudo-open state like this does not notify the submitter any sooner nor
trigger any of the nice properties of a proper -done. The bug just rots
there forever...

I discovered these three by pure chance, and I only noticed them because
they were RC in a package that was not scheduled for auto-removal (the
RC bugs was listed on tracker.d.o).

I have run into this numerous time in the past, and I will run into this
into the future if the status quo does not change. That is why I filed
this bug. In my view, the status quo leads to zombie bugs that slowly
rots forever.
would recommend it is something that tracker.d.o can display (emails get
lost, I skip the bug pages for a package preferring to jump directly to
known bugs, etc.).
   Added bonus, if it also reports the "when `found version` == `fixed
version` then the bug is not fixed"-issue that has caught people by
surprise as well (assuming that is still a thing).

Jumping to a solution / idea spewing mode:
  - Export a list of bugs per package that has one or more potential
    problems for tracker.d.o and other services.
  - When opening the bug itself, have in the top a "possible metadata
issue(s)" warning a la:

    - "The bug is marked fixed in some versions but is not done.
       Remember to close the bug with a mail to `NNNNNN-done@bugs.d.o
       to ensure the submitter gets a notification and the bug can be
       archived later."

    - "The bug is allegedly both fixed and found in version X. Either
       remove the fixed or the found version for version X. For now,
       the fixed version is ignored."


Best regards,
Niels

UDD can provide a first list of candidates with e.g

select id, source from bugs
where not (affects_oldstable or affects_stable or affects_testing or affects_unstable or affects_experimental)
and status != 'done'
and source in (select source from sources) -- source exists (not pseudo-package)
order by id;

(4961 bugs)

Some of them look like b0rked versions information (#1111558, #1111626)

Lucas