fix excessive liberal regex used to pick correct path to ELPA include path in WIEN2k easyblock

[boegel]

(created using eb --new-pr)

Installing WIEN2k often failed due to failing to find a match for questions that were raised by the interactive installers, as reported in:

• WIEN2k easyblock fails to find match for question raised by siteconfig_lapw interactive configure script #4064

I was hitting this today, and when checking the log file I noticed that the WIEN2k easyblock failed to find a match for a known question for the following bit of output:

The present values are:
      PARAMETER          (NMATMAX=   29000)
      PARAMETER          (NUME=   6000)
      PARAMETER          (RESTRICT_OUTPUT= 9999) ! 1 for mpi with less output-files

    Change parameters in:

    1   lapw1/2  (e.g. NMATMAX, NUME)
    A   all programs (RESTRICT_OUTPUT)

    Q   to quit

     Selection:
      PARAMETER          (NMATMAX=   29000)
      PARAMETER          (NUME=   6000)
      PARAMETER          (RESTRICT_OUTPUT= 9999) ! 1 for mpi with less output-files

Which parameter to change? (q to quit):

That's weird, because the last 5 lines which include the "Which parameter to change?" question that can't be answered should only be shown when the Selection: question above was answered with 1. That should never happen, because there's a question pattern for Q to quit followed by Selection:, which should always be answered with Q...

It turns out that the problem was that the regex used to determine which number to use to specify the correct path to the ELPA header files was way too liberal, because it includes (.*\n)*, which matches any line in the output, without restriction.

That caused trouble, because it resulted in the "path to ELPA headers" question being answered multiple times rather than just once, even though it was not at the end of the output and hence not the question that should be answered:

$ grep 'replying with.*1$' /tmp/eb-h1t2dyp7/easybuild-qnj26ncq.log
== 2026-08-03 14:17:49,898 run.py:339 INFO Found match for question pattern '.*(?P<number>[0-9]+)\t/software/ELPA/2025.06.002-intel-2025b/include/elpa_openmp-2025.06.002\n(.*\n)*[\s\n]*$', replying with: 1
== 2026-08-03 14:17:50,685 run.py:339 INFO Found match for question pattern '.*(?P<number>[0-9]+)\t/software/ELPA/2025.06.002-intel-2025b/include/elpa_openmp-2025.06.002\n(.*\n)*[\s\n]*$', replying with: 1
== 2026-08-03 14:17:51,542 run.py:339 INFO Found match for question pattern '.*(?P<number>[0-9]+)\t/software/ELPA/2025.06.002-intel-2025b/include/elpa_openmp-2025.06.002\n(.*\n)*[\s\n]*$', replying with: 1
== 2026-08-03 14:17:52,006 run.py:339 INFO Found match for question pattern '.*(?P<number>[0-9]+)\t/software/ELPA/2025.06.002-intel-2025b/include/elpa_openmp-2025.06.002\n(.*\n)*[\s\n]*$', replying with: 1
...

Because the answer is 1, we were actually (incorrectly) answering the Selection: question mentioned above with 1, which results in the follow-up question "Which parameter to change?", which eventually leads to:

== FAILED: Installation ended unsuccessfully: No matching questions found for current command output, giving up after 200 seconds! 

This problem has been there since the WIEN2k easyblock was ported to EasyBuild 5 in:

• use run_shell_cmd in custom easyblock for WIEN2k #3413

It was not a problem in EasyBuild 4.x, because there the interactive siteconfig_lapw command was run with the (now deprecated)run_cmd_qa function. This had two lists of patterns for questions:

• qa: a list with string values that were an exact match for questions, which in the case of WIEN2k included "Q to quit Selection:"), and
• std_qa: a separate list with regular expressions to consider for matching questions.

The latter list was only used when no match could be found using the list of strings, and hence the "Q to quit Selection:" was always matched before the regex pattern to answer the "path to ELPA headers" question was considered...

There was an attempt to circumvent the problem being properly fixed here in 45f9339 by moving the pattern for the "path to ELPA headers" question later in the list of patterns, but that's just an imperfect workaround, the real problem is that the regex is way too liberal.

fixes #4064

[boegel]

Test report by @boegel

Overview of tested easyconfigs (in order)

• SUCCESS WIEN2k-24.1-intel-2023a.eb

• SUCCESS WIEN2k-24.1-foss-2025b.eb

• SUCCESS WIEN2k-24.1-intel-2025b.eb

Build succeeded for 3 out of 3 (total: 1 hour 24 mins 55 secs) (3 easyconfigs in total)
node4402.skiddo.os - Linux RHEL 9.6, x86_64, AMD EPYC 9755 128-Core Processor (zen5), Python 3.9.21
See https://gist.github.com/boegel/b71b48bff5816aa1f6d11b2a6202fd63 for a full test report.

[smoors]

lgtm

[smoors]

Going in, thanks @boegel!