 |
https://www.debian.org/lts/security/2020/dla-2211.en.html It was fixed in Jessie. So now I just gotta see if OpenSim can live with that version instead of it's binary blob. |
|
|
Installing Debian's liblog4net1.2-cli and removing the binary blob from OpenSim seems to have worked. |
|
|
Building with the newer log4net is a problem. It's still finding the old one somewhere and bitching about it. Also the docs for how to find out what version is being used are wrong for this new version. And apt-get source can't find it's source code. |
|
|
It's a complete clusterfuck. Oddly enough this particular bug was fixed long ago in log4net, in version 2.0.10.0. OpenSim has a binary blob of 2.0.8.0. Devuan Linux uses Debian's version of log4net, and is on 2.0.10.0. Installing that worked fine, but then building OpenSim fails, coz it's still picking up 2.0.8.0 from one of the other binary blobs in OpenSim. Soooo, I added a "print the actual version of log4net" line to OpenSim. Which doesn't actually fucking work in any log4net beyond 2.0.9.0. Coz, they decided they didn't really need it, even though the source code for getting the version is in there. That source code isn't actually built. No problem, I'll just build it myself. Only you can only build in on Windows. At this point I just tested the official release of 2.0.13.0, it works, said fuck it and just went with it. Even though it still wont print the version number. Also, any version of log4net beyond 2.0.9.0 has the version 2.0.9.0 hard coded as it's version number, not that it makes any difference, it wont report it anyway. Sooo, what do you expect from something that executes log lines? A complete clusterfuck. And people wonder why I'm rewriting OpenSim entirely in C + Lua. |
- Anonymous
