Important announcement: the Citadel git repository has moved!

TL;DR: it is now at [ https://code.citadel.org/citadel/citadel.git ]

The longer story is that we are now running a private GitLab server, so that we can do all of that neat stuff with CI/CD and automatic builds and have a better way of handling merge requests and all of those other things.

You don't need to have an account on the server to download or browse the code. However, if you intend to submit patches or otherwise contribute, you can sign up -- but to limit abuse, we have it configured so that you MUST use an @uncensored.citadel.org email address. I think you can change it later if you want to. I just don't have the time or patience to deal with random kiddies from out of town trying to mess with the system.

This is an important release note regarding Citadel version 976, which is appearing shortly on all the usual download places.

Every installation of Citadel has a database called the Use Table, which keeps track of external data items that have already been "seen" so they are not downloaded again. During the most recent development cycle, we became aware that these items have been getting stored in a way that (1) consumed much more space than required, and (2) never got purged from disk.

Regrettably, this bug was not fixable in a way that could preserve the table, so part of the fix involves erasing the whole table during the next upgrade.
Don't worry, this doesn't erase any of YOUR data. It just means that after your next upgrade, you're going to see some duplicates in rooms that are pulling external RSS feeds or remote POP3 mailboxes. After that first run, the duplicates will not appear again.

We apologize for the minor inconvenience this may cause.

Consider it vaporware -- but not really, since it's already been written, but not published yet. This is just an advance notice so that Citadel sites can take advantage of an upcoming improvement.

If anyone has tried using the "ctdlmigrate" utility to move a Citadel database between machines -- perhaps on different architectures (AMD64 vs. ARM) or different bit widths (32-bit vs. 64-bit), then you already know how slow that utility is, and on very large systems the fidelity can be less than perfect.
Therefore, this utility is being retired in an upcoming release.

It will be replaced by simple "dump" and "load" utilities, whose purpose will be instantly familiar to anyone who has ever worked with databases. You can dump your Citadel database to a flat file, which can then be loaded onto another system running the same version of Citadel -- even if it's a different CPU. These utilities are intended to be used while Citadel Server is *NOT* running, so they are much faster and more reliable.

So if you've been putting off a migration to a different CPU because ctdlmigrate was too finicky (like I have -- my system still runs on 32-bit) then the upcoming release and its new dump and load utilities are for you.

Citadel 992 is now available. There are no end user visible changes in this version, but there's a whole lot going on in the back end. So if you're a system administrator, you might want to get this one.

* As promised, `ctdlmigrate` has been removed. It has been replaced by two utilities that get the job done much faster and more reliably: `ctdldump` and `ctdlload`. They are, as their name suggests, dump and load utilities for your Citadel database. These must be run while Citadel Server is *stopped*.
You can use these utilities to move a Citadel installation around between machines that have different architectures -- for example, you can go from 32-bit to 64-bit, from AMD/Intel to ARM, etc.

* This version has been tested on FreeBSD. There are no sexy installation scripts included but if you're running FreeBSD you probably want to roll-your-own anyway. It does require GCC and GMake.

* IMPORTANT: if you've had problems with database corruption in the past, then this is the one for you! We've got it running REALLY SOLIDLY at this point. I personally haven't been able to get my test databases to fail no matter how badly I abused them. Ironically, this was part of an effort to get ready to move AWAY from Berkeley DB, but in the process we figured out how to get Berkeley DB to be as stable as it was when we first started using it 20+ years ago.

* There is a new `loadtest` utility that you can use to abuse the system for a while before you put real users onto it, if you feel like doing that.
It's multithreaded and can support hundreds of concurrent load testing threads.


So there it is ... that's how the Citadel team spent our summer. :) This is an upgrade that makes the Citadel Server far more solid, far more reliable, and far more portable. We are also now in a position where someone can write alternative back end storage layers for Citadel Server, such as LMDB or MariaDB or whatever.
Such a back end could potentially be written in a few days, and the new dump-and-load utilities would allow quick porting to them.

Once the dust settles down from this upgrade we'll be going back to work on WebCit-N[5~G.