caddy: update to 2.11.4

[utsurononaka]

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture:
  • x86_64-glibc
  • aarch64-glibc
• I built this PR locally for these architectures:
  • armv6l (cross-build)

[Duncaen]

Please do not adopt packages with your first contribution, we would like to see continued maintainership before assigning new maintainers to packages.

[utsurononaka]

@Duncaen, understood.
May I ask you to elaborate what's the expected flow? I checked contribution guidelines and they are rather tricky.
Meaning, regarding adding new packages, it's said:

we prefer that they are submitted by those with a history of contributions to existing packages. A good way to do this is to work on orphaned packages ... that you use.

At the same time, for template adoption it's said:

template adopters should be familiar with the package and have an established history of contributions to Void.

So that falls into some sort of recursion. 😅

As for my part, I'm interested in both maintaining existing packages and adding and maintaining new ones.

[Duncaen]

@Duncaen, understood. May I ask you to elaborate what's the expected flow? I checked contribution guidelines and they are rather tricky. Meaning, regarding adding new packages, it's said:

we prefer that they are submitted by those with a history of contributions to existing packages. A good way to do this is to work on orphaned packages ... that you use.

At the same time, for template adoption it's said:

template adopters should be familiar with the package and have an established history of contributions to Void.

So that falls into some sort of recursion. 😅

As for my part, I'm interested in both maintaining existing packages and adding and maintaining new ones.

You can update packages without adopting them. Tracking whether the listed maintainer of a package is still active adds extra work and might stop other contributors from updating them.

[utsurononaka]

@Duncaen, got it. Thanks for the prompt reply!
I updated the PR. Hopefully, it's fine now.

[utsurononaka]

Ok so I dug through the logs of failed checks.
It seems the failures stem from an upstream integration tests, not from packaging modifications. Package builds complete successfully. The tests repeatedly reload Caddy with varying HTTP protocol configurations on identical ports, then immediately issue HTTPS requests. However, the test harness waits only until the new configuration appears in the admin API, not until the HTTPS listener is fully ready to serve connections.
On slower build environments (particularly i686 and x86_64-musl builders) this timing mismatch might lead to intermittent connection reset by peer errors.
This behavior also explains why the failure may occur on a local first run yet disappear on subsequent attempts. I managed to get those errors on my x86_64-glibc and aarch-glibc machines by running ./xbps-src -Q pkg caddy (a lot of times), but the repro was extremely low, maybe 2/30 or something.