Hi. A few weeks ago I asked here how a bisect should be done
when bad < good and the aim is to know when something was fixed:

https://lists.debian.org/debian-mentors/2024/11/msg00056.html

The simple solution is to use another script with the exit status reversed.

However, when doing that, we have to change the way we call things.
Good becomes bad and bad becomes good, and if we cut and paste the
final output from debbisect, we have to clarify that the meanings
are swapped.

A better solution is to implement this "natively" in debbisect,
which is what the attached patch tries to do.

It mostly works for me, but it probably needs more testing.

I've also opened a Merge Request in salsa in case it helps.

Thanks.

Hi josch.

Today I made a debbisect using my modified script and this happened:

bisection finished successfully
   last bad timestamp: 20241028T023949Z
   first good timestamp: 20241028T090451Z
ERROR:root:no difference -- this should never happen


I was debbisecting "r-cran-git2r" to see when exactly
bug #1084352 was fixed.

In this case, the only difference between "last bad" and "first good"
was the source package version being built, but not the list
of installed packages.

If the list of installed packages is what the error refers to,
I don't think that's an error of "should never happen" kind,
so I would consider that as a bug in my modified script.

Maybe also a bug in the original debbisect script, but I'm not sure,
so feel free to ask me to report it separately.

Thanks.

Hi.

I found another place requiring small changes:

Time is always supposed to go forward, so the message
about changed packages should be more like this:

-        print(
-            "the following packages differ between the last good and "
-            "first bad timestamp:"
-        )
+        order1, order2 = ("bad", "good") if staticargs.reverse else ("good", "bad")
+        print(f"the following packages differ between the last {order1} and first {order2} timestamp:")

and the output which follows should also be changed because otherwise
this is what it may happen:

   libgsettings-qt-dev:amd64 1.0.0-2 -> 1.0.0-1+b1
   libgsettings-qt1:amd64 1.0.0-2 -> 1.0.0-1+b1
   linux-libc-dev 6.12.17-1 -> 6.12.16-1

that's weird because the arrow (->) represents time which is better
to consider as always going forward.

Thanks.

Hi Santiago,

Quoting Santiago Vila (2025-02-24 15:04:43)

I started working on this issue in this MR:

https://salsa.debian.org/debian/devscripts/-/merge_requests/484

Thanks!

cheers, josch

El 2/3/25 a las 20:10, Santiago Vila escribió:
test case is like this:

the following packages differ between the last bad and first good timestamp:
   libgsettings-qt-dev:amd64 1.0.0-1+b1 -> 1.0.0-2
   libgsettings-qt1:amd64 1.0.0-1+b1 -> 1.0.0-2
   linux-libc-dev 6.12.16-1 -> 6.12.17-1

(btw: I'm trying to avoid code duplication, so I hope you
like the v[::-1] trick :-)

Now I'm going to see if I can test (and fix if required)
the code following that. i.e. the "try to figure out the
exact package that introduce the break" part.

Thanks.