McAdams

Thanks Shauren. I have a 35662 client, but I built off an official 37176 client using the current head (as of 2021-02-20). My in-client realm lists the available realm as "Incompatible". Tried fudging the "gamebuild" field in realm_list, which I know has no guarantees of working, and it didn't. Using the history on auth_database.sql I'm guessing building @ https://github.com/TrinityCore/TrinityCore/commit/87448621acd28990ea0fdd600a665012b27d5d98#diff-9548ad5730e018dba61771500dfc778592a20e2bc587d475f7669ed2be7cfc66 when 35662 was added might get me in. Am I way off base?

After digging around in the code, it looks like the best match for this is /sql/base/auth_database.sql - this has a list of client build numbers. Will jump around in history and see what shakes.

I'm building master for the first time and noticed that the required client version is listed in the repo description text. This text isn't tied to history though - a different client version is required for the last tag in master, and we can't see the repo description text at the time that tag was created. I'd like to be able to build even further back in time, as I have even older client versions. Is there a place in the source code where the required client version is defined?

I've been running a TrinityCore instance in a docker container for a few months, and decided to write up my build / maintenance scripts and put them on github @ https://github.com/notagamedevnono/trinityCore-docker My aim was to write a single build script that was relatively easy to set up and which did everything for you with minimal fuss - tool setup, building, client extraction, and docker building all in one. I also added a guide for how to run a docker instance, as there some settings which make it easier. Hopefully someone finds this useful. Feedback welcome.

I rolled a docker container of 3.3.5 and have been testing it on various systems. I've been running a small private server for a few weeks (mostly for my wife and I), and I migrated the database to my docker instance so we could play on my test systems. I found that Linode's smallest node (1G ram, 1 core) is too small to even start the server on, but the next highest one (2G ram, 1 core) is perfectly adequate to run on, though @ 61% memory use. Not sure how it scales above 2 people, but that's worth watching if you want to open your server up to others. If you want to run a server at home, I spun an instance up on a tiny AMD T48E, thats a 2 core 1.4 GHz CPU with integrated "GPU" that comes bolted onto a mini-ITX board. I'm running Ubuntu 20.04 server edition, and 16 gigs of RAM (couldn't find less, sorry), and it's barely breaking a sweat. So all in all, you can get away with running TrinityCore on _really_ low spec hardware if you're aiming for a small server. Just some FYI if anyone's interested.

@Thulium Ah ok, that's what the database build script is for. I need to put more time into running the rest of your stuff, as it will likely take care of even more things I need. Thanks for the tips - explains the missing runtimes. I'm not sure how much energy/time I have for this either, I get the feeling there's a bit of a shortage of build people on TC. Fortunately this project overlaps nicely with my day job, so I just treat it as educational. Yes, hopefully with get around to size-optimizing the container, maybe even automating building it.

@Thulium I got 2) to work, in a slightly roundabout way. I built my own, but the install failed just like it failed with yours because dpkg couldn't find systemd. At least when I try to install it, if systemd is not present the install will outright fail, I don't know how to tell dpkg to ignore the post-setup. Docker containers by design don't allow systemd at all, I think there are ways to force it in but this is not how containers should work. BUT, I realized I could unpack a deb file, strip out the systemd config contents, repack, and install, and voila, it works. Next step is to try this with your builds so I don't have to run my own When I ran TC it failed with some missing dependencies (mariadb-dev for ex), and also there were no sql files in the package so the server couldn't self-scaffold. I'm guessing the scope of your builld is just the executables? I managed to fix these and ... I got my dockerized TC to work! Your build script was essential for me to figure out how to get here, I'm going to write up a guide and put it on github. My plan is to explain how to setup a server from scratch on a linux cloud box, I'd love to base it on the builds you're doing, so it's one less thing for people to have to do. I don't suppose these's a convenient 3.3.5 data dump out there that I can also point to so people don't have to extract?

Hey @Thulium First, thanks for this project, I'm running my first build of the server now (it still takes forever!) Second, I'm trying to get a docker image of TrinityCore going, and it would be a huge step forward if I could get a reliable package build of all the TrinityCore binaries. Unfortunately, the builds I'm getting from your package repo seem to rely on systemd to work, so I cannot run them inside a Docker container. So, now I'm trying to figure out how to build this project without systemd. The build tool you're using is new to me, and I can't find anything obvious in the build config in the trinitycore-recipes repo that includes systemd, other than the daemon restart command in postinst. Do you have any suggestions for how to remove systemd from the build? Thanks again