I just did a test build of the salsa source of whisper.cpp, without
2040-disable-talk-llama.diff, and the resulting whisper-talk-llama
worked.  Not great, but limping along.

Is it time to enable it in the default build?  I notice the comment from
Mathieu Baudier in debian/patches/2040-disable-talk-llama.diff from
January state "Disable talk-llama until it is properly integrated with
llama.cpp packages", but it is unclear to me what 'properly integrated'
mean.  Is the idea to make whisper.cpp build depend on llama.cpp headers
and library?

Hi Petter,

sorry for the delay and thanks for your inputs on the MRs.

I think our whisper.cpp's issues are mostly caught up now, so it could
be time to look at:
@Mathieu, your thoughts on this?

Best,
Christian

Hello,
Debian packages, but have a different origin and a much narrower
scope), I have always been building talk-llama against the libllama
packages.

Essentially, this is done via a simple patch which removes references
to the synced llama.cpp sources and adds llama as a CMake dependency. I
haven't tested it for a while, but I never had problems with the build.
From time to time there are some trivial updates to be done on the
patch.

So, I am confident that there would be no problem to enable this in the
Debian packages.

Back then, the decision was pragmatical: these synced llama.cpp sources
were always causing issues, via the common dependency with ggml. It was
very dependent to when upstream (whisper.cpp) would decide to resync
these llama.cpp sources, while our ggml builds are mostly driven by
llama.cpp. So, more often than not, whisper.cpp build would break only
because of outdated llama.cpp sources.

The other option was to integrate this patch. But I see talk-llama
rather as an interesting proof-of-concept than a usable tool, and my
focus is mostly on the libraries. So, I didn't want to extend the scope
unless there is a demand for it.

Cheers,

Mathieu