Skip to content

Fix CI builds again #5590

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Apr 16, 2025
Merged

Fix CI builds again #5590

merged 5 commits into from
Apr 16, 2025

Conversation

dscho
Copy link
Member

@dscho dscho commented Apr 16, 2025

I noticed that the CI builds of shears/main were failing, as well as the PR builds of #5586. The reasons are outside of Git for Windows, but the fixes need to be inside anyway.

sgn and others added 5 commits April 9, 2025 08:42
With at least glibc 2.39, glibc provides a function declaration that
matches with this POSIX interface:

    int regexec(const regex_t *restrict preg, const char *restrict string,
           size_t nmatch, regmatch_t pmatch[restrict], int eflags);

such prototype requires variable-length-array for `pmatch'.

Thus, sparse reports this error:

> ../add-patch.c: note: in included file (through ../git-compat-util.h):
> /usr/include/regex.h:682:41: error: undefined identifier '__nmatch'
> /usr/include/regex.h:682:41: error: bad constant expression type
> /usr/include/regex.h:682:41: error: Variable length array is used.

Note: `__nmatch' is POSIX's nmatch.

The glibc's intention is informing their users to provides a large
enough buffer to hold `__nmatch' results and provides diagnosis if
necessary.  It's merely a glibc' implementation detail.

Hide that usage from sparse by using standard C11's macro:
__STDC_NO_VLA__

Signed-off-by: Đoàn Trần Công Danh <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
The `sparse` job still uses the `ubuntu-20.04` runner pool, but that
pool is about to go away, so let's stop using it.

There is no `sparse-22.04` artifact provided by the "Build sparse for
Ubuntu" Azure Pipeline, but that is not necessary anyway because Ubuntu
22.04 has the `sparse` package: https://packages.ubuntu.com/jammy/sparse

Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Junio C Hamano <[email protected]>
This is Exhibit A to make the case that maintenance is always required,
a software is never "done".

Signed-off-by: Johannes Schindelin <[email protected]>
This is Exhibit B to make the case that maintenance is always required,
a software is never "done".

Signed-off-by: Johannes Schindelin <[email protected]>
The image pointed to by the fedora:latest tag has moved from fedora 41
to 42. The fedora 41 container images have awk installed while the
fedora 42 images do not.  That change is most likely just part of
reducing the size of the base container images.

In both AlmaLinux and Fedora (as well as other RHEL
derivatives/relatives), awk is provided by the gawk package.

On Fedora, `dnf install awk` would work, but for unintended reasons! It
uses the package filelist data to determine that /usr/bin/awk is
provided by gawk and installs gawk as a result.

On AlmaLinux (8 & 9, by my quick testing), that is not the case and
you'd need to use `dnf install gawk` or `dnf install '*bin/awk'` to get
it installed. Having said that, awk _is_ included in the current
AlmaLinux 8 and 9 images, so it isn't strictly needed.  But it's
probably better to be explicit that we need it installed, as a defense
against some future change to the AlmaLinux container removing awk.

Using the package name "gawk" is the right thing to do.

Note that even '*bin/awk' would have worked, but it is less specific.
And who knows, maybe in the far future a BSD variant of awk is offered,
too, and would then cause ambiguities. Best to avoid that.

Suggested-by: Todd Zullinger <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
@dscho dscho self-assigned this Apr 16, 2025
@dscho dscho added this to the Next release milestone Apr 16, 2025
@dscho dscho merged commit 7a18c63 into git-for-windows:main Apr 16, 2025
59 checks passed
@dscho dscho deleted the fix-ci-builds-again branch April 16, 2025 14:11
git-for-windows-ci pushed a commit that referenced this pull request Apr 16, 2025
I noticed that the CI builds of `shears/main` were failing, as well as
the PR builds of #5586. The reasons are outside of Git for Windows, but
the fixes need to be inside anyway.
git-for-windows-ci pushed a commit that referenced this pull request Apr 16, 2025
I noticed that the CI builds of `shears/main` were failing, as well as
the PR builds of #5586. The reasons are outside of Git for Windows, but
the fixes need to be inside anyway.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants