The problem is that the last release was 7 years ago.
The last commit was in Dec 2021, so nearly 3 years ago.
There are 46 open issues, the majority of which have just the original posters content or maybe a couple of responses.
The only one with a lot of responses is the issue (opened in 2020) about getting a new release issued.
In that it was declared that the original developer of lcdproc was going to stop doing the work for new releases or updating the project. Another person offered to pick the project ownership up.
That was in Jul 2021.
Then a year passed with no further progress. Then the new developer asked for help with how to manage the releases. That was provided in the period up to Nov 2023. The new developer then said he hoped to kick off a new release in 30 days (end of 2023).
Since then nothing has happened.
It looks like despite the best intentions the project is not going to be supported in the near future.
There are some issues listed in the project about existing drivers not working or compiling properly with gcc 14 (IPFire is on this version), only with gcc 13 and some other issues referencing problems with changes occurring in the kernel.
All of which suggests that with nothing done to the project existing drivers will start to stop working anyway if nobody does the development work.
The problem is that the last release was 7 years ago.
The last commit was in Dec 2021, so nearly 3 years ago……
So?
Some of my contributions to Linux 1.0.8 still appear in Mainline kernels … I have not made contributions since … I think that it is 1994 … So let’s deprecate that kernel code … ?
I have used this resource for quite some time. Deploying the kit on production equipment opens it up any hardware to significant security concerns. This is not a practical solution.
There are some issues listed in the project about existing drivers not working or compiling properly with gcc 14 (IPFire is on this version), only with gcc 13 and some other issues referencing problems with changes occurring in the kernel.
If it is not compiling under GCC-14 then this offers opportunity from this project to offer a kick-start - perhaps even a fork? ! I won’t comment further on this … GCC with “rapid re-versioning” is heading down the slippery path that Qt has taken … There is a bad flu called “versionitis” out there at the moment !
My point is that it works … Its stable. It is small; it is simple. The code itself is quite innocuous. Yes there are 47-odd issues listed – but none affect us and our application. For our application – which is primarily programming the Sophos “Front Panel LCD” it works well. The application provides no security risks. With the documentation that I added (in response to MULTIPLE queries) it has turned from a zombie into something practical.
Oh, by the way, there is a HELL OF A LOT of Sophos hardware out there now that management paid heaps for that they want to see applied. That is where I come in …
It harms nobody nor does it offer security vulnerabilities. It may not be used often – but I can tell you that “repurposers” such as me use it extensively especially now that there is better “howto” documentation
Well, this actually is causing some security concerns. Even though not directly.
The reason why I proposed this to be dropped is that it didn’t want to build with GCC 14. No matter what you might think of the changes in GCC, there are security fixes in every release and for that and other reasons we try to be as close to upstream as possible.
lcdproc itself is not in a good state. It is ancient code and it is messy. There has been at least one fork that gained some attention but after all it also died as far as I am aware.
I suppose that is because there is no modern hardware available that people are using, so why spent time on software that is not being used by many people?
The project here is very short on time. Developers are busy, donations are at an all time low. So we have to consolidate and make cuts. We want to focus on features that are used by a large group in our community and not on those where there are only very few users.
And so this got cut as nobody wanted to take up the work and work with (what is left of?) upstream to get this thing back on track.
If you want to, please feel free to send patches and take responsibility for this feature. This is an open project, you are welcome to contribute.
Some of us “repurposing” hardware have gone to a considerable amount of trouble – time and effort – based on client requests. We have shared back our learning. Some of our clients have, in return, donated directly back to this project (on our recommendation) … and that is where we potentially run into trouble …
I realise that its catch-22.
I am a little concerned that you are using gcc-14 … Things SHOULD be fully backwardly compatible but (as I raised subliminally in the Qt example) they are not. It is interesting that some of us on Defence work still (are forced) to use “proven” compilers that can be anywhere up to 30 years old …
The problem of proven compilers is just another problem. To verify a compiler you must choose a verified language standard. I don’t think this is true for C, or C++. These languages are a task in progress. This includes removing of constructs not functioning.
For the (hopefully) small part of IPFire in Defence systems, there is just another problem. How do you prove the quality of the system? IPFire is in steady progress and can be expanded in many ways.
