MantisBT: Update to v2.26.3

[mreid-tt]

Description

This PR contains the following:

1. Upgrade Mantisbt to version 2.26.3
2. Modernise package scripts
3. Add PHP profiles for DSM 6
4. Add full backup and restore

Fixes #4034

Checklist

• Build rule all-supported completed successfully
• New installation of package completed successfully
• Package upgrade completed successfully (Manually install the package again)
• Package functionality was tested
• Any needed documentation is updated/created

Type of change

• Package update

[mreid-tt]

@hgy59, @th0ma7, I’ve modernized another package, but I'm facing some challenges with installation on DSM7. While installation, upgrade, removal, backup, and restore tests run successfully on DSM6, DSM7 presents an issue related to the install script checks.

The problem seems to stem from a check in the install script that verifies the value of "$g_path," which, according to the admin guide, is the "full URL to your installation as seen from the web browser." The script seems to perform a curl on the application URL to ensure a web server is active before proceeding with the database installation.

However, under DSM7, it seems the web portal for the package isn’t available until the service_postinst completes. The install log shows:

2024/09/25 15:46:47	Begin service_postinst
2024/09/25 15:46:47	Run MantisBT installer
2024/09/25 15:59:49	End service_postinst

The installer fails during this time, and a curl on the web portal URL returns "404 -- The page you are looking for cannot be found." Once the installation finishes, the curl redirects successfully.

This is further supported by synopkg.log entries:

2024/09/25 15:59:45 install mantisbt 2.26.3-6 Begin postinst
2024/09/25 15:59:49 install mantisbt 2.26.3-6 End postinst ret=[0]
2024/09/25 15:59:50 install mantisbt: begin to start version 2.26.3-6
2024/09/25 15:59:51 Acquire webservice for mantisbt when 0x0001 (ready)
2024/09/25 15:59:53 Acquire webservice for mantisbt when 0x0001 (done)

This suggests that the web service only becomes available after postinst. According to the Web Service Resource, it appears that the web service enables at WHEN_ENABLE, which occurs after postinst.

I haven’t found a way to bypass this check since MantisBT doesn’t seem to provide an option to skip or suppress the URL verification. Without bypassing this check, the database remains unconfigured, and there’s no straightforward way to complete this step after service_postinst.

I'd appreciate any insights or suggestions from the team on how to handle this. Alternatively, we might consider reaching out to MantisBT to explore possible installation modifications, though this could complicate future upgrades.

[th0ma7]

I believe you have it all nailed down as your explanation seems ti makes sense. Now how to fix it? I did a quick search and you may be stuck with this:

build/travis_before_script.sh:curl --data "${query_string:1}" http://$HOSTNAME:$PORT/admin/install.php

One way would be to create a cross/mantisbt/patches directory with a patch such as (I don't believe this fix is what you actually need but servers as example):

$ diff -uprN build/travis_before_script.sh.orig build/travis_before_script.sh
--- build/travis_before_script.sh.orig	2024-08-25 04:07:38.000000000 -0400
+++ build/travis_before_script.sh	2024-09-25 19:23:32.805340608 -0400
@@ -141,7 +141,7 @@ do
 done
 
 # trigger installation
-curl --data "${query_string:1}" http://$HOSTNAME:$PORT/admin/install.php
+curl --data "${query_string:1}" http://$HOSTNAME:$PORT/admin/install.php || true
 
 
 # -----------------------------------------------------------------------------

If you look at the spksrc.patch.mk it explain the variations of subdirectories that can be used to get trigerred for only specific arch, tcversion and al:

#    patches/*.patch      ## this is the only location for native and noarch builds
#    patches/kernel-$(subst +,,$(TC_KERNEL))/*.patch   ## Discard any ending +
#    patches/DSM-$(TCVERSION)/*.patch
#    patches/$(group)/*.patch
#    patches/$(group)-$(TCVERSION)/*.patch
#    patches/$(arch)/*.patch
#    patches/$(arch)-$(TCVERSION)/*.patch

So you could have a patch that modifies the mantisbt installer script, trigerred only under dsm7, that changes the order of things the way you actually need it to be.

With hope this gives you a few pointers to solve the issue...

BTW, looking at your install script, that`s a real piece of art 😃

[mreid-tt]

Hey @th0ma7, thanks so much for your guidance! After some digging, I found a part of the installer script that was fairly easy to patch. Initial tests on DSM 7 have been successful, and I’ll be continuing with the rest of the tests shortly.

BTW, looking at your install script, that`s a real piece of art 😃

Appreciate the kind words! It took a lot of ideation and input from several folks when I first started modernizing ownCloud a few months back.

[mreid-tt]

@hgy59, I’ve updated another legacy package to support MariaDB and added new script features, including dynamic PHP profiles for DSM6 and a full backup and restore function. Looking forward to your review and approval.