>From my experience using other gitlab installations, yes you have to create
a branch and then commit that branch, and then you can create a merge request.
When the merge is approved (and I haven't set any approval rules so we might
have to experiment there) there is a "delete source branch"
Ok, I see you logged in to GitLab. Your account is registered and added to
the Citadel group as a developer. You can probably add your external email
address and make it primary if you want to at this point.
At this point you *should* be able to submit Merge Requests for patches.
This is
>fixed a couple of defects with the existing code that I am just going to
>include with the new flag support. Small but if you want me to submit
>separate, let me know.
I'd like it if you did that, please. If for no other reason, it would be
a great way for us both to get used to
Announcement!
Citadel's git repository HAS MOVED.
We're now using a private GitLab server at https://code.citadel.org
This will allow us to do CI/CD, merge requests, and all of those other
niceties.
As previously mentioned, if you want to sign up for access, you have to use
an
I'm not surprised. That code has seen a lot of tweaking by a number of people
and it could use some attention.
The underlying data formats are at the front of my attention right now because
I'
m writing a utility to convert a 32-bit database to 64-bit, and it's uncovering
a number of
>problem. The server will operate fine for about an hour then it starts
>deleting users without me being in the interface. The stranger part is
that
This room isn't really for support issues, but you might want to check the
time and date on your system.
Also be sure that you're
Hey developers!
We're going to try something new. Over the last year or so I've really gotten
into the CI/CD thing and now it's time to apply that to Citadel. So I have
built a GitLab server, running in a container on one of our data center hosts.
This will let us do all sorts of
>Noticed flags were getting set wrong in Outlook and in WebCit. I thought
I
>had introduced the bug(s). Finally realized that the bugs were in the
>release and had nothing to do with my code. Spent way too much time
>debugging my code :-)
I've seen it malfunction but never
>Now to the issue: How do you want to support the change to the structure
and
>falling back to older versions of the mail server. My implementation reads
First of all, I love your idea and we should definitely do it. If I'm reading
your description correctly, it could potentially mean
All right, I've applied those patches. I'm giving some consideration to
deploying a GitLab instance so we can have an automated testing and deployment
pipeline; if we do that then you can just have an account and generate merge
requests.
Easy Install isn't in Git at all; if you have
> 2023-05-03 16:12 from HarlowSolutions
By what name do you want to be credited in the documentation?
(oh and thanks for the patch!)
libcitadel and webcit use the GNU Automake build system. That's why there's
a bootstrap program; it sets up the build environment on your build machine
so you can continue.
citadel (server), textclient, and webcit-ng use a much simpler build system,
one that doesn't rely on the GNU
Welcome awrdgrs and sharivegas!
Three new contributors in just a couple of days. This makes me very happy
:)
Please read the last couple of days worth of messages in this room. It will
serve as a quick introduction to the project and how to get started as a
contributor.
There's
The patch looks good, and I'll go ahead and see if it applies cleanly. The
important thing is that it doesn't try to change too many things at the same
time, and you've documented what it is intended to do. That's really really
good.
By the way -- in case you haven't figured it
Ok, let me see if I can answer these questions one at a time.
git: at any given time, you'll want to be keeping up with the code in the
git repo. If you are developing against a released version of the code you
might have trouble integrating your changes.
That having been said, no
Great! I just want to answer quick and let you know I'll read through this
soon -- I'm super busy at work this week but I wanted to let you know these
questions *will* be answered. Give me a bit and I'll go through it. Thanks
for being interested in contributing!
>wtf, why do you want to break the universe?
Heh. Sometimes there are days when it feels like the universe is not worth
saving :)
(No bonus points for guessing correctly that these aren't actually significant
releases and I'm really just testing a CI/CD pipeline.)
(That would be a resounding "yes" from Kitty. :)
I just removed the "check for new mail in the inbox" function out of the
server's GOTO command and moved it into a new command called BIFF. I wonder
how many people will know why I named it that?
Sometimes a bit of code just "feels good" and you know you got it right.
The "Delete" button in the forum view, for example, which just got committed.
We only display the button if we know we have permission to delete messages
in the current room, which is a permission indicated when we fetch
Those who have followed the development of the server for many years will notice an intent here. Look at how little happens between receiving a signal and exiting the server process. In the past, we made an effort to clean everything up. We cleanly logged out every session, each module
I do want to test on ARM hardware other than a Pi, but that will have to come
later. I keep forgetting that Citadel is, for some reason, staggeringly popular
on Raspberry Pi. I don't know why; all I know is that when I break the build,
I hear about it. And I've finally nailed down that
Oh boy.
That was a really long and painful day of troubleshooting. After updating
all of my SSL server code to the latest practices, I was no longer able to
establish SSL connections to Uncensored EXCEPT on HTTPS. So no encrypted
IMAP, no encrypted XMPP, everything just threw a cipher
The sendcommand binary should be in /usr/local/citadel in the container's
filesystem.
But if you *need* sendcommand for something, I should probably know what
it is, so we can provide a better way to do it.
For those of you following along ... the reason I am enduring all of this
extreme frustration of working with the WebCit Classic code base -- which
has been rendered unmaintainable by bloody acres of hash tables and callback
functions -- is because I want to make it work with the ACME HTTP-01
What a fun evening of hacking!
This message is being posted with WebCit-NG!There's a lot of stuff to be cleaned up, of course, but the basic framework is in place. I can't believe it was so easy to write my own editor. The "contenteditable" attribute made it a no-brainer. This was so much easier than trying to decide
Every time I discover something like this -- in this case, scrollIntoView()
-- it affirms that I made the right choice building a new WebCit from scratch.
Web development is such a different beast than it was when I started WebCit
25 years ago. The browser has so many things built-in that
One thing that continues to delight me while developing webcit-ng is how
many of the common tasks are now built in to the typical web browser
environment,
or have been made easy in some other way.
For example, Font Awesome [https://fontawesome.com] eliminates most of our
icon needs. I
Is everyone enjoying the commit log? Hehe
WebCit-NG is front and center again :)
Ooooh, yeah that's right; mail to rooms with spaces in the name, working
again now :)
All righty then! Citadel 939 is now available for download in all three
channels (source tarballs, Easy Install, and Docker).
It has "the fix"
Ok, I have fixed the bug, but the commit has not shown up here, because of
the bug :)
I will let you know when the downloads are updated.
Confirmed! I reproduced the problem on a test machine. I am able to send
email to a room that has no spaces in its name ("room1") but not to a room
with spaces ("Citadel Development").
Does that sound like the problem you have been having? I'm going to fix
that next. Thanks for the bug
I think this is the problem:
Sep 21 15:18:18 prod citserver[515]: msgbase: no such room
It looks like the underscore is not being stripped from the room name before
it goes to look for the room to post in.
I think I was finally able to reproduce your problem:
1. Start up Thunderbird, connected using SMTP/IMAP to Uncensored
2. Write a message, with the following recipients:
nore...@citadel.org, room_citadel_development@uncensored.citadel.org
3. The message is accepted but is NOT
All righty then! Uncensored is now running Citadel 938, and we're now coming
up on 48 hours without a crash. We had been getting server crashes almost
daily because some random idiot would scan our ports for vulnerabilities,
and attempting to start TLS on an already-encrypted port would
Citadel 935 is now available via Easy Install, and by tomorrow it will be
available on Docker Hub.
Ok, it's working well now, just needs a few cosmetic cleanups and we'll be
ready to roll.
>Or a new feature? (let's hope not)
I certainly hope not! :)
It's the code in the server that implements expansion of addresses in the
global alias list. When an address in the alias expansion is larger than
a certain number of characters (feels like around 30 or so) it clobbers
>Yippee-Ki-Yay My Friend!
There's one more bug to squash, a segfault that appears on certain address
combinations. After that's fixed we will go straight to release.
Well this is interesting. I made a copy of the database for my production
system (Uncensored) and am currently running it as a 32-bit container on a
64-bit system. Now I don't have to convert my database, and thanks to the
magic of automatic cross-platform builds, I don't even have to work
The above is kind of a big deal :)
This means that the code available in the Docker container is going to be
exactly the same as the code available through Easy Install. You wanted
assurance
that Easy Install isn't going away -- here it is. It's all part of the same
build chain now:
The latest build has AMD64/i386/ARMv7 thanks to "buildx" which does all of
the cross-compiling for you. This is very cool, and now I can use my Pi for
testing instead of keeping it tied up in the build pipeline. buildx *does*
support 64-bit ARM, and originally I included it in the build.
I didn't pay a lot of attention, but doesn't Proxmox support Docker containers? Or is it just Kurbernettes - or whatever...
Proxmox supports containers using LXC, not Docker. It's still containers, but LXC containers are really more intended to be lightweight virtual machines that share a
It's working exceptionally well, and I am seriously considering switching
from virtual machines to containers for all of my workloads. They all run
on Linux anyway.
Might as well have this conversation here.
First things first: I figured out how to do a "multiarch" build, so there
will no longer be different tags for different architectures. "latest" now
supports AMD64, i386, and ARMv7. I built a script to push nightly builds,
so hopefully we've got
Citadel running in a container! It's working pretty well now. I had to
change the tag names because apparently Docker Hub doesn't differentiate by
architecture; a tag is a tag. So we're using citadeldotorg/citadel:amd64
for x86, and citadeldotorg/citadel:armhf for ARM.
Hopefully we'll
The new location is:git://git.citadel.org/citadel
And of course we still have the gitweb browser at: https://code.citadel.org
I have emailed the new SSH location to those who have write access.
Do you guys find it helpful and/or interesting that I sort of blog the details
of my development effort here? I mostly do it to organize my thoughts but
it would be nice to know that someone is reading it.
WebCit Classic has a template engine that makes adding functionality even
more
In case anyone is tracking the Citadel git repository -- be advised that
I am moving it. I am tired of maintaining an "/appl" hierarchy on my server;
this was done in the distant past before /opt and /usr/local came into
widespread
standard use. I may also move it to a different server ...
Try it!
[ https://www.citadel.org/docker.html ]
AMD/Intel 64-bit only for now. ARM coming soon; I want to re-image my Pi
before I build it.
It is *ridiculously* easy. Docker automates away the hard parts in a way
that the AppImage was very sloppy in attempting.
Oh, and if
>Thank you very much for your work; at the moment I am out of the office,
>I think for this week. (I need to finish a project by mid-September, I
>will try to escape my earring at night)
>
>As soon as I get it, I restore/cleanup the VM/Debian to test it.
Thanks. So far, it is
All right people, grab your favorite 64-bit AMD/Intel Linux machine and try this.
First, install Docker. (On a Debian or Ubuntu host it's "apt install docker.io")
Then, do this:
docker run --name citadel -it --rm --network host --mount type=volume,source=citadel-data,target=/citadel-data
AppImage was intended to be used for desktop applications. I tried it for
a server system and there were just too many things that broke. We're using
Docker for *exactly* its intended purpose.
It shouldn't matter what kind of Linux you run a Docker container on. That's
sort of the point.
Lots of great progress tonight on the Docker container. As expected, much
of the work that went into the AppImage was reusable in Docker, and the Docker
version is running quite well already. It doesn't feel as "fragile" as the
AppImage did, and I think it's going to serve us better in the
>So, do I stop my tests with the AppImage and wait for the thingy* in Docker?
Let's put it on hold for now. The goal is the same, but the package format
is different.
We've learned a lot over the last few months, and in developing the AppImage
we solved a LOT of problems that were
So far, it seems that the distribution of Citadel as an AppImage has been
a complete flop. I had high hopes for a universal binary to work but it doesn't
seem to want to work on any computer that isn't mine.
This is not to say that all the work wasn't worth it. We've phased out the
s3cr3to: this is all towards your use case, so hold tight, it'll be ready
soon!
Ok, with the AppImage release now completed, my next task will be to add
the global email alias table. It won't be pretty, but it'll be accessible
for those who need it.
>I assume that restoring the backup will preserve the ones that are
>currently there, am I correct?
What do you mean by "currently there"?
If you're talking about aliases that were in the user account already, with
the limited amount of space, then yes, those will be preserved
The absence of the text client is definitely still something that is missing from the appimage. I'm trying to figure out what happens when the same AppImage is called multiple times on the same host. Does it consume more memory or does it share? If it shares, I could add a calling mode that
Tell you what ... since your bug reports tend to be good quality and well
triaged, I'm going to just give you access to the "Citadel Issue Tracker"
wiki room. In the distant past we had general bug reporting, but it quickly
filled up with poorly researched/reported bugs, and with feature
All right, I'm satisfied at this point that the AppImage is, at least, beta quality, and I am linking it from the download page.
>Is there any way to list the size of the mailboxes of each account and
>maybe including the size of their folders?
Not inside of Citadel. You could probably find an IMAP tool that does that.
Excellent. It's too bad that Berkeley DB needs that kind of tuning. Perhaps
someday when 32-bit systems are a distant memory we will move to LMDB.
>*May 17 14:21:06 em2 citserver[25444]: db: BDB3017 unable to
>allocate space from the buffer cache*
>*May 17 14:21:06 em2 citserver[25444]: db: compact: Cannot allocate
>memory*
You didn't recover any disk space because it crashed. This means we have
to put some
>I'll let it run another +4 hours, which is about how long it took to do
>the cleanup process.
Did it finish? The warning about the housekeeping loop is normal if you're
doing a big purge, because the purge runs inside the housekeeping loop so
it won't start another one.
>*Question #2*: Will the reduced DB still be compatible with my current
>8.17 version in production? It would be great to have the downsized DB
>for future migration.
No. Citadel databases are never backward compatible. Once you start up
thew new version of the server with the old
>*Question #1*. How can I configure that option using the AppImage?
>I'm very curious to see what size the DB will be at when I do a big
>purge on some mailboxes that I'm sure are no longer checked.
You can telnet to port 504 and log in as an administrator.
The command you want
>I remembered database_cleanup and wanted to try it after copying my
>backup to the corresponding directory.
Are you running database_cleanup because your db is corrupted? Or are you
running it in an attempt to recover unused disk space?
Please read this knowledge base entry:
> * In the alias section, I don't think I can place all my aliases, it
>seems to be limited to 512 characters, currently I have 779 and
>increasing, of course, I need to debug some aliases.
If I am reading this correctly, you need more space for an account's aliases
than the
>Ok. Give me a little framework on what you want me to test and how.Â
The ideal test is this:
Start with a fresh 64-bit Linux VM. Don't bother installing the development
tools -- you won't need them.
Copy over your database /usr/local/citadel/data to the VM. If you're set
up
>Yes! it's working: Sending and receiving external mail.
>
>Can I delete the /usr/local/citadel folder to copy my backup and test
>the migration?
Awesome! Yes, go ahead and delete anything you want. I am finished testing
on your system. Thank you for making it available.
>When you say "might be the one"...Â
...I mean it might be the one that fixes the issues s3cr3to was experiencing.
And it did!
I'd like to see more testing before a production release, and there might
be a few more packaging features to throw in to make the whole thing more
This might be the one!
[ http://easyinstall.citadel.org/citadel-1620778956-x86_64.appimage ]
s3cr3to -- it's already installed on your VM, because I tested it there.
Give it a try. Also be aware that you can now invoke the appimage with "debug"
instead of "run" -- it will
I'm away on business travel this week, so there won't be a lot going on with
Citadel for a few days. Keep that VM running if you are able, and I will
poke in and test things when I can.
We have determined that the main problem, as suspected, is that the server
crashes whenever it makes a
@s3cr3to
We're making progress. I was unable to get the debugger working from within the AppImage, but I was able to run some other tests.
For example, even on a fresh database with no email sent, I found that if I set up an RSS feed, it would also crash when it goes to pull that feed. This
Oh ... I should have thought of that. Instead of sending the VM, you can
just let me log in to it remotely. Why didn't I think of that?
That will be fine, and I will make an effort to give it a try this weekend.
I will probably do something like this: mount the AppImage by hand, jump
Dammit. It's showing the backtrace of an idle thread, not the thread that
crashed.
I don't suppose you have enough bandwidth to simply upload the entire VM?
Ok, good. Now look in /tmp and see if there are any files in /tmp that begin
with "citserver-backtrace". Please post their contents or upload them
somewhere.
Check https://www.citadel.org/appimage.html for new AppImage builds.
This one doesn't *fix* any server crashes, but when the server does crash
it will save a backtrace in /tmp that you can upload here, so we can figure
out what's going wrong.
Hopefully. :)
Just a heads up to mention that crash reporting (particularly in AppImage
builds) is still the #1 priority. The previous bunch of commits were just
some brainless sweeping of the floor to keep me occupied while multitasking.
All right, exit code 139 means the server exited on signal 11, which means
that the AppImage supervisor did the wrong thing. It should have restarted
the server instead of exiting.
I will correct the restart-on-crash problem, but since we also need to find
out *where* yours is crashing, we
>And yes, when trying to send messages it fails; I can send messages to
>the "admin" account itself.
Damn. I did a fresh install of Debian 10, minimal with no extra software
added, on the exact virtual hardware you described in your last post. I still
can't get it to fail.
Can
Ok, so you're using stock Debian 10 (64-bit x86, I assume) and the AppImage
declares that it is compatible. You are attaching it to a copy of an existing
database. Local mail works fine, but any attempt to deliver Internet mail
results in a server crash.
Do I have it clear now?
>And although I discovered my mistake and now this VM works as I know it
>should, in my test it still fails to use the "test" of the AppImage, if
>I try to send some mail it just closes the App.
That's progress. :)
So let me see if I understand correctly. If you run the
The current version of the AppImage *can* run WebCit on nonstandard ports.
Absolutely.
There is a page at https://www.citadel.org/appimage.html which contains the
downloads and instructions for the AppImage distribution of Citadel. This
is actually the final location; it simply isn't linked from the main part
of the site yet.
If you have a clone of your live system and it was
>So, it won't help if I add another virtual disk with more storage if I
>can't change the /tmp dump path. Rigth?
Correct. I've removed the misleading guidance from the help text. The
intermediate
dumps must be on /tmp and this cannot be changed.
If you add another virtual disk
>For the latter, how should I run the database_cleanup to get it to take
>the working path?
database_cleanup always stores its intermediate dumps to /tmp.
I really should change the help text which suggests otherwise.
The results of your tests continue to baffle me. But I am happy to see it,
because if I can fix it for you, that means there are others who would have
had the same result, and we are preventing all those support requests from
happening.
If you have the patience, I would be VERY grateful
>1. What effect would it have if I run *database_cleanup* with my
>backup+data in the DB?
Yes, I'd try database_cleanup just to see what it does.
Also, I have to ask: is the copy of your database actually in
/usr/local/citadel
or is it somewhere else?
You should also try
This is the developer community only. It's private because we had too many
end users posting poorly triaged bug reports, support requests, and feature
requests in here.
[ http://easyinstall.citadel.org/citadel-1617821022-x64.appimage ]
This version of the AppImage uses the same version of Berkeley DB as the
one used in Easy Install. This means if you've tried the AppImage before
but it choked on an existing database, now is the time to try again!
Ok good. That means the migration tools weren't *completely* broken. We've
come a long way from the days when installing a multiuser Citadel meant
compiling
the sources yourself and carefully putting everything into place. 30 years
ago the objective was to make the administration experience as
>Production is an i5 NUC. I've got 4 of that particular model. Dell
>optiplex 3020 Micro - and two 3040s that have the next gen i5 CPU.Â
Ok, so you're on 64-bit x86. Did you use ctdlmigrate to move from ARM?
I ended up making a lot of changes to that recently when I tried to run it
What are you running your production system on right now?
I just upgraded Uncensored to Citadel 931. I have been experiencing two
problems
lately and I know this will fix at least one of them. One problem was finding
WebCit in an endless loop every morning, and I know that's fixed because I
traced it down to an "optimization" of the HTTP/HTTPS read
101 - 200 of 1679 matches
Mail list logo
