Re: slowly decommission bugzilla?

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hello Sasha,

On Sun, Mar 01, 2026 at 10:42:57AM -0500, Sasha Levin wrote:
> On Sun, Mar 01, 2026 at 04:35:26PM +0100, Laurent Pinchart wrote:
> > On Sun, Mar 01, 2026 at 10:23:00AM -0500, Sasha Levin wrote:
> >> On Sat, Feb 28, 2026 at 03:56:11PM -0500, Steven Rostedt wrote:
> >> > On Sat, 28 Feb 2026 21:28:57 +0100 (CET) Richard Weinberger wrote:
> >> >
> >> >> Wouldn't that only work if the report is able to upload the kernel debug
> >> >> info too?
> >> >
> >> > Yes, this would be nice if we had the help from the distros that could
> >> > automate this process.
> >>
> >> So I've been poking at using LLMs for this.
> >>
> >> decode_stacktrace.sh is great when you have a debug build handy, but
> >> asking a random bug reporter to obtain debuginfo, set up the tooling,
> >> and run the script is quite the hurdle.
> >>
> >> The debuginfo problem is solvable on the server side though. Given a
> >> kernel version string from the oops, an LLM can figure out which distro
> >> and package version the reporter is running, pull the right debuginfo
> >> (or build from the matching config/tag if no debuginfo package exists),
> >> and run decode_stacktrace.sh itself.
> >
> > Do we really have to use non-deterministic tools that will inevitably
> > produce correct-looking but otherwise useless backtraces from time to
> > time, confusing developers and wasting time for everybody, when we can
> > instead easily develop tools that will work in a deterministic fashion ?
> > I'm getting *really* sick of people pushing for LLM usage when it's
> > clearly the wrong tool. Please stop.
> 
> The LLM actually runs scripts/decode_stacktrace.sh. The non-deterministic part
> is being able to get our hands on various debug symbols from
> distros/vendors/etc.

That was my understanding, yes.

> Instead of just crapping on everything,

Please tone the insults down.

> can you propose a different
> deterministic solution that would have worked for
> https://lore.kernel.org/all/DGRCO9SL0T5U.JTINSHJQ9KPK@imlonghao.com/ ?

Not as a procedure to extract line numbers that will work retroactively
of course, but I don't think that's the point.

As we're discussing new developments to replace bugzilla, working with
distributions to streamline bug reporting would be more deterministic.
Running the stack trace decode in the server side is a good idea, and
the server should receive in addition to the stack trace either the
debuginfo or, when running a distro kernel, an identifier of the exact
kernel version to download the debuginfo from an authoritative source.

> Or should we just let that bug report rot as it usually happens because you have
> some dislike for LLMs?

Let's not resort to straw man arguments, you know that's not what I
said.

I will stand by my original claim, that using the community's
development resources to create non-deterministic tools when a
deterministic solution isn't more difficult is a waste of time and
resources. I've always disliked suboptimal solutions, it's not limited
to LLMs.

-- 
Regards,

Laurent Pinchart