Hello, On Fri, 2026-06-12 at 11:37 +0200, Christian Kastner wrote: > > 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? > @Mathieu, your thoughts on this?
For my own internal packages (which are very similar to the official 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
