With this in mind, should it be planned to exchange out SearX for SearXNG since the development for that is still on going, and is considered the successor to SearX?
I can also try working on this myself by updating the installation scripts.
Any news on that front?
The DuckDuckGo backend of SearX seems not to work any more (luckily the Bing backend still works, but I’d much rather use DuckDuckGo), so it’s become more urgent for me.
If the Debian package for SearXNG comes to fruition, we will be able to quickly add it to FreedomBox (perhaps even to stable users via backports). Are any of your able to contribute to the packaging effort of SearXNG using the packaging already available for SearX?
So, here we are in May 2025 - There is only step-by-step instructions on how to install SearXNG to Debian, which can be found here:https://docs.searxng.org/admin/installation-searxng.html, but no efforts (that I have found yet) to package this for Debian. With Debian 13 (Trixie) currently in development freeze for release, I don’t see that this will become a viable package in Trixie. Sadly, my instance of SearX on my FreedomBox server is now (recently) no longer functional, and I’m not sure if the above installation instructions that are given will integrate nicely with FreedomBox. Maybe there is some other Debian packaged search integration we can use here? I would very much like to see replies here, as this is a serious loss of functionality to my FreedomBox, as I’m sure it is (or will be) to others.This is probably the one feature of FreedomBox I use (or have used) the most, honestly. Maybe we could put this to some kind of vote, to choose a successor to SearX, or to attempt to package SearXNG for Debian. Just not sure here, I welcome replies to this thread.
I, too, will miss SearX, but I thought making Nextcloud available in a Podman container assumed that a packaging effort was underway and that the package would ultimately replace the container.
Can SearXNG even be packaged for Debian? Apparently, “SearXNG is a rolling release; each commit to the master branch is a release.” This is the case for an increasing number of applications, but I thought Debian required discrete patches for security fixes (i.e., without also picking up extraneous changes as would be the case if a security fix is just applied to the head of the master branch). Is FreedomBox still a Debian “Pure Blend” if it includes unpackaged applications in containers?
At this point the FreedomBox criteria for allowing an application to be deployed in a container rather than as a package seem a little vague. Even if an active packaging effort is a prerequisite, there’s no clear sense of how long to wait for it to come to fruition, or what to do if it doesn’t.
Particularly if applications in containers will not be just a temporary bridge to a packaged solution, FreedomBox may want to more clearly distinguish them from Debian packaged applications. Perhaps a visual clue in the application icon and/or an option to hide or display them on the applications page such as a checkbox or filtering keyword.
Agreed. Not to mention how it affects already limited resources on SBCs, since setting up containerized services requires considerably more RAM, processing speed, etc. I’m hoping we can figure out something that will work, and soon.