While reviewing the build logs from MariaDB 1:10.11.5-1 I saw multiple
tests fail with this pattern:

main.analyze_engine_stats 'innodb,slow_query_log_off' w1 [ fail ]
        Test ended at 2023-10-05 02:34:21
CURRENT_TEST: main.analyze_engine_stats
--- /<<PKGBUILDDIR>>/mysql-test/main/analyze_engine_stats.result
2023-08-11 06:35:40.000000000 +0000
+++ /<<PKGBUILDDIR>>/mysql-test/main/analyze_engine_stats.reject
2023-10-05 02:34:19.664680297 +0000
@@ -16,9 +16,6 @@
 select '$out' as X;
 X
 {
-  "query_optimization": {
-    "r_total_time_ms": "REPLACED"
-  },
   "query_block": {
     "select_id": 1,
     "r_loops": 1,
@@ -55,9 +52,6 @@
 select '$out' as X;
 X
 {
-  "query_optimization": {
-    "r_total_time_ms": "REPLACED"
-  },
   "query_block": {
     "select_id": 1,
     "r_total_time_ms": "REPLACED",
@@ -88,9 +82,6 @@
 select '$out' as X;
 X
 {
-  "query_optimization": {
-    "r_total_time_ms": "REPLACED"
-  },
   "query_block": {
     "select_id": 1,
     "r_total_time_ms": "REPLACED",
@@ -129,13 +120,9 @@
 ANALYZE FORMAT=JSON SELECT * FROM t1 WHERE a IN (SELECT s FROM t2);
 ANALYZE
 {
-  "query_optimization": {
-    "r_total_time_ms": "REPLACED"
-  },
   "query_block": {
     "select_id": 1,
     "r_loops": 1,
-    "r_total_time_ms": "REPLACED",
     "const_condition": "1",
     "nested_loop": [
       {
mysqltest: Result length mismatch

Failures were in tests: main.analyze_engine_stats,
main.derived_split_innodb, main.cte_recursive,
main.rowid_filter_innodb, main.analyze_stmt_orderby,
main.explain_json_format_partitions etc

There was also other tests failing on result mismatches to the degree
that the test suite stopped running.

Full log.
* https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=hppa&ver=1%3A10.11.5-1&stamp=1696473748&raw=0


This is not a regression in the latest MariaDB version, as there is a
similar pattern of test failues also in e.g. a log from 10.11.1:
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=hppa&ver=1%3A10.11.1-1&stamp=1674740552&raw=0

However in the 10.11.1 build some tests passed that now failed.
Somebody with better understanding on how the optimizer debug output
works should be able to figure out what is HPPA specific here and why
it behaves differently and thus test suite ends up failing.

Note that hppa builds are now passing despite this issue, but this
issue still persists - it is simply skipped in the test list for hppa:
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/unstable-tests.hppa

Note that this issue still exists, but is not visible and build is not
failing on it simply due to issue being skipped via the
unstable-tests.* in
https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/debian/

With the upload of MariaDB 1:11.4.2-1, the hppa build is failing on
openjdk-5-jre-headless dependency.

The last 10.11 series build was successful up until the test suite
fails on some tests having extra optimized debug info.

These were still happening in
https://buildd.debian.org/status/fetch.php?pkg=mariadb&arch=hppa&ver=1%3A10.11.8-1&stamp=1719712940&raw=0

See work-in-progress at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/146

It is currently stalled. Help by hppa porters would be very welcome!

Hi!

In December many expressed interest in porting MariaDB to hppa, but I
didn't notice any comments on any of the bug report or MR or any other
follow-up, so I guess perhaps people didn't have time for this after
all..?

Hi Otto,

Porters are working on a lot of porting issues simultaneously so that they
cannot immediately jump to working on specific packages unless the issue
is urgent.

Just look at the issue tracker for SPARC which has 60 openissues [1].

Furthermore, we had Christmas holidays in between during which many of us
just stepped away from their computers to be with their families.

So, it's not really surprising that there hasn't been any progress on this
issue yet. It doesn't mean porters don't care. It just means they simply
haven't had the time to look into it yet.

Adrian

Hey Otto,
I am actually currently working on it.
I was last able to produce this error which I am currently trying to fix
with mariadb codebase, but I think its progress perhaps?

*# ERROR LOG 1 (initially I faced this):*
Server version: 11.8.5-MariaDB-4 from Debian source revision:
2bb18a8cf1170b7c506b9c57640d8798a3b74298
The information page at
https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/
contains instructions to obtain a better version of the backtrace below.
Following these instructions will help MariaDB developers provide a fix
quicker.
Attempting backtrace. Include this in the bug report.
(note: Retrieving this information may fail)
Thread pointer: 0x0
stack_bottom = 0x0 thread_stack 0x49000
/home/soumyajyotii/build/mariadb-server/builddir/sql/mariadbd(my_print_stacktrace-0x36cf6292)
[0x421a4dac]
Writing a core file...
Working directory at
/home/soumyajyotii/build/mariadb-server/builddir/mysql-test/var/install.db
Resource Limits (excludes unlimited resources):
Limit                     Soft Limit           Hard Limit           Units
Max stack size            8388608              unlimited            bytes
Max processes             257230               257230
processes
Max open files            1024                 1024                 files
Max locked memory         8388608              8388608              bytes
Max pending signals       257230               257230               signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Core pattern: core
Kernel version: Linux version 6.12.57+deb13-amd64 (
debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19)
14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC
Debian 6.12.57-1 (2025-11-05)
make[1]: *** [debian/rules:162: override_dh_auto_test] Error 1
make[1]: Leaving directory '/home/soumyajyotii/build/mariadb-server'
make: *** [debian/rules:253: binary] Error 2
dpkg-buildpackage: error: debian/rules binary subprocess failed with exit
status 2



Currently the build is failing at the CMake *configure* stage because
MariaDB still expects a required core dependency to be present, even after
all related optional features have been explicitly disabled.

So I am trying to figure it out and fix it.

Your advice and guidance would be appreciated on how I could work more
closely with the MariaDB Community for the porting.

Thank you,
Soumyajyotii Ssarkar.

Hello Otto,
I wanted to update you on the current progress for the MariaDB port for
PARISC.

As we discussed earlier, I started by disabling all java related components
for the MariaDB server. This work was done on top of the latest
MariaDB-server repository from GitLab, rather than the version currently
available in the package manager.

*Summary: *At this stage the build completes successfully on PARISC, and
most tests pass. The remaining failures appear to be platform specific test
mismatches, primarily related to error code differences, assumptions around
SSL and huge pages.

*Summary of changes I made so far:*
diff --git a/debian/control b/debian/control
index 480921b86d2..6354450b7ad 100644
--- a/debian/control
+++ b/debian/control
@@ -11,10 +11,10 @@ Build-Depends:
  dpkg-dev (>= 1.22.5),
  bison,
  cmake,
- cracklib-runtime <!nocheck>,
- default-jdk,
+ cracklib-runtime [!hppa],
+ default-jdk [!hppa],
  gdb <!nocheck>,
- libaio-dev [linux-any],
+ libaio-dev [!hppa],
  libboost-dev,
  libbz2-dev,
  libcrack2-dev (>= 2.9.0),
@@ -22,23 +22,23 @@ Build-Depends:
  libcurl4-openssl-dev | libcurl4-dev,
  libedit-dev,
  libedit-dev:native,
- libfmt-dev (>= 10.1.1+ds1-4) | libfmt-dev (<< 10),
- libjemalloc-dev [linux-any],
- libjudy-dev,
+ libfmt-dev (>= 10.1.1+ds1-4) | libfmt-dev (<< 10) [!hppa],
+ libjemalloc-dev [!hppa],
+ libjudy-dev [!hppa],
  libkrb5-dev,
  liblz4-dev,
  liblzma-dev,
- liblzo2-dev,
+ liblzo2-dev [!hppa],
  libncurses-dev,
  libnet-ssleay-perl <!nocheck>,
  libnuma-dev [linux-any],
  libpam0g-dev,
  libpcre2-dev,
- libsnappy-dev,
+ libsnappy-dev [!hppa],
  libssl-dev,
  libssl-dev:native,
  libsystemd-dev [linux-any],
- liburing-dev [linux-any],
+ liburing-dev [!hppa],
  libxml2-dev,
  libzstd-dev (>= 1.3.3),
  lsb-release,
@@ -825,6 +825,7 @@ Description: Connect storage engine for MariaDB server

 Package: mariadb-plugin-connect-jdbc
 Architecture: all
+Build-Profiles: <!hppa>
 Depends:
  default-jre-headless,
  ${misc:Depends},
@@ -877,6 +878,7 @@ Description: RocksDB storage engine for MariaDB server

 Package: mariadb-plugin-oqgraph
 Architecture: any
+Build-Profiles: <!hppa>
 Depends:
  mariadb-server-core (= ${server:Version}),
  ${misc:Depends},
@@ -1041,6 +1043,7 @@ Description: LZMA compression support in the server
and storage engines

 Package: mariadb-plugin-provider-lzo
 Architecture: any
+Build-Profiles: <!hppa>
 Depends:
  mariadb-server-core (= ${server:Version}),
  ${misc:Depends},
@@ -1056,6 +1059,7 @@ Description: LZO compression support in the server
and storage engines

 Package: mariadb-plugin-provider-snappy
 Architecture: any
+Build-Profiles: <!hppa>
 Depends:
  mariadb-server-core (= ${server:Version}),
  ${misc:Depends},
diff --git a/debian/rules b/debian/rules
index 7744795630f..fdb9cee2f83 100755
--- a/debian/rules
+++ b/debian/rules
@@ -55,6 +55,21 @@ ifeq (32,$(DEB_HOST_ARCH_BITS))
     CMAKEFLAGS += -DPLUGIN_ROCKSDB=NO
 endif

+# Java is missing on hppa (so disabling all java dep)
+ifneq (,$(filter hppa,$(DEB_HOST_ARCH)))
+  CMAKEFLAGS += \
+ -DWITH_JAVA=OFF \
+ -DWITH_CONNECTOR_J=OFF \
+ -DCONNECT_WITH_JDBC=NO \
+ -DWITH_LIBAIO=OFF \
+ -DWITH_URING=OFF \
+ -DWITH_JEMALLOC=NO \
+ -DWITH_SYSTEMD=no \
+ -DWITH_SNAPPY=NO \
+ -DWITH_LZO=NO \
+ -DWITH_JUDY=NO \
+   -DHAVE_PCRE2_POSIX=0
+endif
+
 # Fix compilation errors like "relocation truncated to fit: GPREL16
against symbol `wsrep_debug'"
 ifeq ($(DEB_HOST_ARCH),alpha)
     export DEB_LDFLAGS_MAINT_APPEND += -Wl,--no-relax
@@ -107,15 +122,20 @@ endif
     -DCOMPILATION_COMMENT="-- Please help get to 10k stars at
https://github.com/MariaDB/Server" \
     -DMYSQL_SERVER_SUFFIX="-$(DEB_VERSION_REVISION) from $(DEB_VENDOR)" \
     -DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
+    -DWITH_SSL=system \
+    -DOPENSSL_ROOT_DIR=/usr \
     -DBUILD_CONFIG=mysql_release \
     -DCONC_DEFAULT_CHARSET=utf8mb4 \
     -DPLUGIN_AWS_KEY_MANAGEMENT=NO \
     -DPLUGIN_COLUMNSTORE=NO \
     -DWITH_NUMA=AUTO \
     -DIGNORE_AIO_CHECK=ON \
-    -DWITH_URING=ON \
-    -DWITH_LIBAIO=ON \
-    -DWITH_INNODB_SNAPPY=ON \
+    $(if $(filter hppa,$(DEB_HOST_ARCH)), \
+     -DWITH_URING=OFF -DWITH_LIBAIO=OFF, \
+     -DWITH_URING=ON  -DWITH_LIBAIO=ON) \
+    $(if $(filter hppa,$(DEB_HOST_ARCH)), \
+     -DWITH_INNODB_SNAPPY=OFF,\
+ -DWITH_INNODB_SNAPPY=ON) \
     -DHAVE_SYSTEM_LIBFMT_EXITCODE=0 \
     -DWITH_SBOM=NO \
     -DDEB=$(DEB_VENDOR)



*With this I am getting the output of:*





















































*main.ctype_utf8mb4_uca_allkeys400        w5 [ pass ]
 128256main.ddl_i18n_koi8r                      w23 [ pass ]
 84340main.gis-rtree                           w19 [ pass ]
3259main.gis-precise                         w7 [ pass ]
 641437main.upgrade_MDEV-23102-1                w29 [ pass ]
 114369main.upgrade_MDEV-23102-2                w25 [ pass ]
 108717main.ctype_utf8mb4_uca_allkeys520        w21 [ pass ]
 181903main.ssl_connect                         w12 [ pass ]
 296756worker[11] Test still running:
main.ctype_gbk_export_importmain.mysqldump                           w32 [
retry-fail ]        Test ended at 2026-01-28 12:28:07CURRENT_TEST:
main.mysqldump---
/home/soumyajyotii/build/mariadb-server/mysql-test/main/mysqldump.result
 2026-01-07 20:04:52.137901241 +0000+++
/home/soumyajyotii/build/mariadb-server/mysql-test/main/mysqldump.reject
 2026-01-28 12:28:04.292643535 +0000@@ -5753,7 +5753,7 @@ proc one DROP
DATABASE bug25717383;-mariadb-dump: Got error: 2005: "Unknown server host
'unknownhost'" when trying to connect+mariadb-dump: Got error: 2002: "Can't
connect to server on 'unknownhost'" when trying to connect Usage:
mariadb-dump [OPTIONS] database [tables] OR     mariadb-dump [OPTIONS]
--databases DB1 [DB2 DB3...] OR     mariadb-dump [OPTIONS]
--all-databasesResult length mismatch - skipping
'/home/soumyajyotii/build/mariadb-server/builddir/mysql-test/var/32/log/main.mysqldump/'Test
main.mysqldump has failed 2 times, no more
retries!main.ctype_gbk_export_import             w11 [ pass ]  1417042Only
 1360  of 1357
completed.--------------------------------------------------------------------------The
servers were restarted 275 timesSpent 25492.846 of 2328 seconds executing
testcasesCompleted: Failed 6/1155 tests, 99.48% were successful.Failing
test(s): main.large_pages main.ssl_autoverify main.mysqldumpThe log files
in var/log may give you some hint of what went wrong.If you want to report
this error, MariaDB's bug tracker is found athttps://jira.mariadb.org
<https://jira.mariadb.org>Errors/warnings were found in logfiles during
server shutdown after running thefollowing sequence(s) of tests:
main.ssl_autoverify190 tests were skipped, 80 by the test
itself.mysql-test-run: *** ERROR: there were failing test casesmake[1]: ***
[debian/rules:167: override_dh_auto_test] Error 1make[1]: Leaving directory
'/home/soumyajyotii/build/mariadb-server'make: *** [debian/rules:258:
binary] Error 2dpkg-buildpackage: error: debian/rules binary subprocess
failed with exit status 2*


I will move forward with addressing the remaining test case issues and then
prepare a commit for submission to MariaDB Server on GitLab.

Please let me know your opinion on this approach, if you would like me to
proceed differently or focus on any specific area.
Thank you,
Soumyajyotii Ssarkar

Hi Soumyajyotii!

Thanks for working on this. Once you feel it is ready for review,
please submit a Merge Request at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests
along with perhaps some info of how you tested in on hppa as Salsa CI
does not have that architecture.

As your changes include what I did in !146 I will close that draft MR
once your MR is posted and it supersedes it.