Looks like you are removing the mariadb packages but not the DBs.
ok, I will check it. Usualy it ask me, if I will delete all databases, if I uninstall mariadb and I answer Yes, but I assume, that is not enough.
Do you have this error message / warning about “unmet dependencies” and libzip4?
Yes, you need to modify the control file of the PHP Debian package. I add the required logic in hst_autocompile.sh to handle this.
sed -i '/release=$(lsb_release -rs)/a\\ if [[ "$os" = "Debian" ]] \&\& [[ "$release" = "13" ]]; then\n sed -i "/Conflct: libzip5/d" "$BUILD_DIR_HESTIAPHP/DEBIAN/control"\n sed -i "s\/libzip4\/libzip5\/g" "$BUILD_DIR_HESTIAPHP/DEBIAN/control"\n fi' /path/to/hst_autocompile.sh
As the main branch is now running on Symfony 8, you must update the PHP version in Hestia from 8.3 to 8.4.
For reference, here are the commands I use to compile it:
#!/usr/bin/env bash
cd
rm -rf /root/hestiacp
rm -rf /tmp/hestiacp-src
git clone --branch debian-13-support-v2 --single-branch https://github.com/sahsanu/hestiacp.git hestiacp
cd hestiacp
git pull
git remote add upstream https://github.com/hestiacp/hestiacp.git
git switch debian-13-support-v2
git fetch upstream pull/5223/head:pr-5223
git merge pr-5223 -m "Merge PR 5223"
git branch -d pr-5223
git submodule update --init --recursive
apt-get -q -y purge ufw
cd /root/hestiacp/src
php_ver="$(curl -fsSLm60 https://ppa.launchpadcontent.net/ondrej/php/ubuntu/dists/noble/main/binary-amd64/Packages.xz | unxz | grep -E '^Version: 8.4' | head -n1 | grep -Eo '[0-9]\.[0-9]\.[0-9]{1,}')"
sed -i -E "s/^Version:.*/Version: $php_ver/" deb/php/control
sed -i '/release=$(lsb_release -rs)/a\\ if [[ "$os" = "Debian" ]] \&\& [[ "$release" = "13" ]]; then\n sed -i "/Conflct: libzip5/d" "$BUILD_DIR_HESTIAPHP/DEBIAN/control"\n sed -i "s\/libzip4\/libzip5\/g" "$BUILD_DIR_HESTIAPHP/DEBIAN/control"\n fi' hst_autocompile.sh
./hst_autocompile.sh --all --noinstall --keepbuild '~localsrc'
rm -f /etc/apt/sources.list.d/node*
cd /root/hestiacp/install
source /etc/os-release
echo "bash hst-install-${ID}.sh --hostname "$(hostname).example.com" --username 'admin' --email '[email protected]' --password '123456' --sieve yes --clamav no --quota yes --webterminal yes --interactive no --with-debs /tmp/hestiacp-src/deb"
As this is a bit off-topic, send me a private message if you need any other info.
1 Like
Thanks!
But usualy we need to modify hst_autocompile.sh too, if we want to make it runable with DEBIAN 13. Therefore that is not off topic here! But in this case we need this sed inline replace only for DEBIAN 13 and need a detection for it in hst_autocompile.sh, that it called from DEBIAN 13. Ok I will make it in my own IPV6 repository. We need it later as PR for debian-13-support branch, too.
About your compilation and installation script. Yes my install script views similar. I have also separate sections for compillation and after it for installation. Additionally I make a difference in call parameters “–all” or “–hestia” or somethings else. Compillation with “—all” is very extensive and long and you need it usually not daily. I reuse the so compilled deb packages for nginx and php and call autocompile only with “–hestia” parameter, if I work only on HESTIA. The next side effect, which I detected a few days ago: The old recomendation with “2 GB RAM is enough” is not enough, if you compile NGINX and PHP. My virtual server have only 2 GB RAM and it runs full, if you compile NGINX and PHP. Therefore I compile PHP and NGINX using another computer and then copy all the deb packages to my virtual server with 2GB RAM. But 2GB RAM is enough to compile hestia.
Second difference between your and my installation script is my “strategy”. You “collect” all the required changes using your installation script. Practically, you make a “merge” within your installation script. And I make “merge” first to my own IPV6 branch on my own fork and the compile. Yes I know, your strategy is better for HESTIA, if changes will be made later on the other way in main. I will become conflicts and have to solve it manually and you have just to delete a few rows in your local installation script.
Edit: I used your modifications and now I do not have package conflicts anymore recording this PHP version. However, neither compat package was installed automatically. Maybe something is wrong on my virtual server. I will reinstall it fresh later. But now I can install both compat packages manually without conflicts
1 Like
So still no news on the Debian 13 upgrade? It got buried with all of this other stuff!
Its coming! its just right around the bend. I’m serious!
1 Like
Winter will come sooner 
or Debian 14
2 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.