Re: slowly decommission bugzilla?

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 <[email protected]> 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.

Instead of just crapping on everything, can you propose a different
deterministic solution that would have worked for
https://lore.kernel.org/all/[email protected]/ ? Or
should we just let that bug report rot as it usually happens because you have
some dislike for LLMs?

-- 
Thanks,
Sasha