using termux-apt on-device, I can't reproduce the exact error that truboxl saw invalid regular expression, maybe truboxl can explain how to reproduce that, but I can report the first error I have encountered testing lint-packages.sh on-device, which is this:

================================================================

Package: cabal-install

Layout: PASS
Package name 'cabal-install': PASS
End of line check: PASS
File permission check: PASS
Indentation check: FAILED
packages/cabal-install/build.sh:29:			 ghc-options: -fexternal-interpreter -pgmi=$(command -v termux-ghc-iserv)
packages/cabal-install/build.sh:36:			 flags: +no-cmm
Mixed indentation

================================================================

A problem has been found in 'packages/cabal-install/build.sh'.
Checked 0 packages before the first error was detected.

================================================================

which is reproducible by the command scripts/lint-packages.sh packages/cabal-install/build.sh in termux-apt, but is not reproducible inside the termux-package-builder, so there must be some difference between how they each evaluate packages/cabal-install/build.sh.

Is your on-device clone of the repo up to date?
Because the current linter version passes all packages on my PC, but I am seeing that mixed indentation so what's going on with that.

Is your on-device clone of the repo up to date?

yes.

Because the current linter version passes all packages on my PC, but I am seeing that mixed indentation so what's going on with that.

It appears that for some reason, lint-packages.sh can detect the mixed indentation of cabal-install when run on-device, but cannot detect it when run inside termux-package-builder. I am not sure what the root cause of that would be.

It's probably regex related.
Ugh, that's a pain in the ass but I need to debug that anyway.

Actually it's a sequencing error.
Because both of these mixed indentation lines are in a heredoc, the heredoc logic hits continue before the mixed indentation check is ever run on the line.

So we just need to move this block up above the heredoc check.

Judging from the comment on the heredoc block, this was intentional behavior, however it seems to be unintended as far as expectations are concerned.

Although, the CI itself doesn't seem to catch %ci:no-build if it's not on the last commit in the push...
Hmm.

You need at least Android 14 to see my reported errors. I test on Android 15.

My device is on Android 15, so I should be able to replicate the issue.
I suspect (though I haven't been able to verify this yet) that Termux's Bash is falling back to a different regex engine than that used by Ubuntu's Bash in the CI.

You need at least Android 14 to see my reported errors. I test on Android 15.

Thank you, I will begin trying to find a solution.

I have created this minimal reproducible example test script as the first step to work on creating a solution:

#/usr/bin/env bash

heredoc_regex="[^\(/%#]<{2}-?\s*(['\"]?(\w*(\\\.)?)*['\"]?)"


if [[ "cat << 'EOF'\ntest\nEOF" =~ $heredoc_regex ]]; then
	echo "ok" # android 13 reaches here
else
	echo "bad" # android 14 reaches here
fi

It seems like the problem might be similar to this other problem that happened in the aspell package that you helped me fix before, so I would guess that you basically already know what is going on:

• [Bug]: Aspell Errors #25825

however, Tomjo2000 might not yet be familiar with the events that occurred in that issue, so maybe linking the issue can help Tomjo2000 understand what is happening.

I have created and tested this change, which appears to work for me, at least I think it does:

diff --git a/scripts/lint-packages.sh b/scripts/lint-packages.sh
index a7961d27d3..0e42ec404d 100755
--- a/scripts/lint-packages.sh
+++ b/scripts/lint-packages.sh
@@ -73,7 +73,7 @@ check_indentation() {
 	local pkg_script="$1"
 	local line='' heredoc_terminator='' in_array=0 i=0
 	local -a issues=('' '') bad_lines=('FAILED')
-	local heredoc_regex="[^\(/%#]<{2}-?\s*(['\"]?(\w*(\\\.)?)*['\"]?)"
+	local heredoc_regex="[^\(/%#]<{2}-?[[:space:]]*(['\"]?([[:alnum:]_]*(\\\.)?)*['\"]?)"
 	# We don't wanna hit version constraints "(<< x.y.z)" with this, so don't match "(<<".
 	# We also wouldn't wanna hit parameter expansions "${var/<<}", ${var%<<}, ${var#<<}
 

• I used this reference guide (in addition to the understanding that I previously gained while working on [Bug]: Aspell Errors #25825 in the past) to help me understand what to do:

https://www.regular-expressions.info/gnu.html

Interesting.
So between Android 13 and 14 support for short form character classes (e.g. \s, \w) broke or was removed from... I guess it'd have to be Bionic Libc?

Interesting. So between Android 13 and 14 support for short form character classes (e.g. \s, \w) broke or was removed from... I guess it'd have to be Bionic Libc?

that is correct, but actually the original decision was made by the operating system FreeBSD, NetBSD's regcomp() function is downstream of FreeBSD and Android's regcomp() function is downstream of NetBSD, I believe the commit in Android 14 which causes the behavior change is this one https://android-review.googlesource.com/c/platform/bionic/+/2290937 and I'm not 100% sure which commit in NetBSD or FreeBSD causes the behavior change but it seems like it could be these: NetBSD/src@1ee269c freebsd/freebsd-src@18a1e2e

The upstream changes in NetBSD and FreeBSD seem confusing because they seem like they're adding support for \w and \s, rather than removing support for \w and \s, but just speculating, maybe something about the changes doesn't work or was lost in the process of repeated copying and pasting first from FreeBSD to NetBSD and then from NetBSD to Android.

The end result is just what we now observe, \w and \s not working in some situations in Android 14, 15 and 16.

So Android gets its regcomp() from NetBSD, and NetBSD gets it from FreeBSD.
That explains it.

Warning: /home/builder/.termux-build/cabal-install/src/cabal.project.local: Unrecognized field 'ghc-options' on line 13

error: Couldn't find a target code interpreter. Try with -fexternal-interpreter

It appears that possibly, there may be significant-whitespace in the Heredocs of cabal.project.local files that requires them to be formatted with particular significant-whitespace that does not pass the current linting policy of github.com/termux/termux-packages.

It appears, for example, that the <<- of the way these Heredocs are formatted is removing leading-tabs from the written file,

which, when combined with the changes in this PR, removes the significant-whitespace and results in an ill-formed cabal.project.local file that is no longer capable of successfully cross-compiling cabal-install.

There are several possible paths forward:

• Try to find a different way to format the cabal.install.local Heredocs that could successfully pass the current linting policy of github.com/termux/termux-packages without compromising the integrity of the significant-whitespace when the written files are exposed to the Haskell toolchain (maybe by replacing <<- with <<, or replacing the Heredocs with repeated echo commands, or something like that?)
• Change the linting policy of github.com/termux/termux-packages to provide for an exception to accommodate the necessary significant-whitespace of the cabal.install.local files
• Move the cabal.install.local files into a different file that isn't linted by lint-packages.sh instead of writing them as Heredocs (this way does not sound good, but mentioning it for thoroughness of the analysis)

@MrAdityaAlok what do you think about this problem?

Replacing <<- with << seems an option with least work.

But we should consider your second option. Languages like Nim don't allow indenting with tabs (although it can be bypassed).

I personally think heredoc semantics are a hassle to deal with in any case, and when indentation matters it's probably best to add an extra file to the package directory.

But allowing mixed indentation to account for white space sensitive formats might still be a good idea.
That reason should be documented in both the linter and style guide though.

Replacing <<- with << seems an option with least work.

Can't quite do that.
That would also require removing the indentation on the heredoc delimiter.

But we should consider your second option. Languages like Nim don't allow indenting with tabs (although it can be bypassed).

We should definitely revisit that if it comes up as an issue in the future.
Though I will reiterate that I think shell heredocs are fundamentally unsuited for whitespace sensitive formats.

I have previously stated by dislike for heredoc semantics, << and <<- changing the behavior of the delimiter is a large part of that.

I'm gonna postpone the heredoc mixed indentation thing to another time, it's clearly breaking builds right now and that's something a linter change or linter compliance fix should never do.

I'll add a comment to explicitly state that mixed indentation for heredocs is permissible since it's required for Haskell and potentially Nim.

Alright, this is just tested and verified fixes now.
Still haven't been able to track down Robert's issue, but this should fix on-device support and the stale FETCH_HEAD issue I ran into earlier.
The startup and shutdown messages should also make debugging easier going forward.

I'm sure we'll be back here for another round of linter fixes.
(I actually hope so since I'd like to solve Robert's Heisenbug.)