Conversation
There are no users of `odb_source_write_alternates()` in our tree anymore. Remove that function and its supporting infrastructure. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checking loose objects we manually parse the object buffer we have read from the on-disk file, mark the object and then call `fsck_obj()`. The exact same steps are also performed by `fsck_obj_buffer()`. Stop open-coding this logic and call `fsck_obj_buffer()` instead. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The interfaces of the functions `fsck_obj()` and `fsck_obj_buffer()` are somewhat similar to one another. The only difference between those two is that `fsck_obj()` takes an already-parsed object as input, whereas `fsck_obj_buffer()` parses the buffer and then calls `fsck_obj()`. Furthermore, `fsck_obj()` has no callers other than `fsck_obj_buffer()`. Refactor the code by merging those two functions. This makes it obvious which function does what, and it allows us to get rid of the early return in `fsck_obj()` in case `SEEN` is set as the only caller unconditionally clears that bit before calling it anyway. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In subsequent commits we're about to rework some of the option handling in git-fsck(1) a bit. It is currently a bit of a mess though due to lots of global state that makes it hard to see which flags are used where exactly. Refactor the code by moving the fsck options into `cmd_fsck()`. This allows us to convert some of the options into function-local variables. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to git-fsck(1), the "--full" option behaves in the following
way:
Check not just objects in GIT_OBJECT_DIRECTORY ($GIT_DIR/objects), but
also the ones found in alternate object pools listed in
GIT_ALTERNATE_OBJECT_DIRECTORIES or $GIT_DIR/objects/info/alternates,
and in packed Git archives found in $GIT_DIR/objects/pack and
corresponding pack subdirectories in alternate object pools.
So ultimately, it is supposed to control two things: (1) whether we only
check the main object directory, and (2) whether we check packfiles.
In its current state though, the flag only controls whether we check
packfiles or not, and if so we verify packfiles of all attached sources.
But we also have checks for loose objects in git-fsck(1), and here we
unconditionally check them in all sources.
The flag is arguably conflating two unrelated concerns with one another,
and it really should be split up into two flags: one that controls how
thorough we want to check individual sources, and one that controls
which sources we want to check in the first place. So ideally, we would
have:
- "--include-alternates": check all sources, not only the local one.
- "--include-optimized-objects": check not only loose objects, but
also those that have been packed. Note that we explicitly don't say
"--include-packed-objects" here to be more backend-agnostic.
- "--full": implies both of the above flags.
This feels out of scope for this series though. So for now, simply fix
the code by honoring locality of the sources for loose objects.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The on-disk consistency checks in git-fsck(1) are conceptually backend-specific: while connectivity checks and object-level parsing checks are generic, verifying the physical integrity of packfiles and loose objects is meaningful only to backends that use these formats: Having these checks live in "builtin/fsck.c" violates that layering, because it forces the command to reach directly into format-specific internals. Provide new infrastructure to make these format-specific checks pluggable and implement stubs for the different source types we already have. In subsequent commits we'll move functionality over piece by piece. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the packfile verification out of `cmd_fsck()` and into the "packed" source. While doing so, thread the progress meter and object callback through the newly introduced `struct odb_fsck_options` so that the caller's preferences are honoured without exposing those details at the "builtin/fsck.c" level. Note that the old code reported failures when verifying packfiles with the `ERROR_PACK` bit, which gets returned to the caller via the exit code. This bit is neither exercised in our test suite nor is it documented anywhere in our codebase. Furthermore, this bit is highly specific to the object storage backend, which makes it a bad fit for the new pluggable infrastructure. So instead of retaining these semantics, we drop them and return the generic `ERROR_OBJECT` bit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The checks for reverse indexes live in `check_pack_rev_indexes()`, which
is hosted in "builtin/fsck.c". These checks are obviously specific to
the "packed" backend.
Move the logic into `odb_source_packed_fsck()`. As in the preceding
commit, drop the dedicated `ERROR_PACK_REV_INDEX` bit and instead use
the generic `ERROR_OBJECT` bit.
Note that this changes behaviour in two ways:
- The checks are now skipped when "--connectivity-only" was passed.
This is because we don't even run `odb_fsck()` at all when that
flag has been passed by the user, and not verifying data structures
of the object database matches the documented intent of that flag,
which is to only check the connectivity of reachable objects.
- The checks are now skipped for non-local sources when "--no-full"
was passed. This is, again, in line with the documented intent of
that flag.
Add a test to cast these semantics into stone.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The checks for bitmaps live in `verify_bitmap_files()`, which is called by "builtin/fsck.c". These checks are obviously specific to the "packed" backend. Move the logic into `odb_source_packed_fsck()`. As in preceding commits, this means that we now properly honor both "--connectivity-only" and "--no-full". Furthermore, we drop the dedicated `ERROR_BITMAP` bit and instead use the generic `ERROR_OBJECT` bit. Note that this change also adapts `verify_bitmap_files()` to be focused on a single "packed" source instead of verifying bitmaps from all sources. This change is required as we already know to loop around the sources in `odb_fsck()` itself. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The checks for multi-pack indexes are hosted in `cmd_fsck()` directly. These checks are obviously specific to the "packed" backend. Move the logic into `odb_source_packed_fsck()`. As in preceding commits, this means that we now properly honor both "--connectivity-only" and "--no-full". Furthermore, we drop the dedicated `ERROR_MULTI_PACK_INDEX` bit and instead use the generic `ERROR_OBJECT` bit. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The consistency checks for loose objects are hosted by "builtin/fsck.c". These checks are obviously specific to the "loose" backend. Move the logic into `odb_source_loose_fsck()`. Introduce a new "verbose" flag so that we can properly retain semantics around whether or not we want to print some status messages. Note that this fixes a bug as a side effect: the progress meter was captured in the callback data before `start_progress()` was even called, so the per-subdirectory progress updates always operated on a NULL pointer and the meter jumped straight from 0 to 256 upon completion. The new code only sets up the callback data's progress meter after it has been created, so the progress display now advances incrementally again. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile-based builds have had this knob for most of the project's life, since a479a56 (Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make, 2009-12-03). Meson, however, hard-codes the equivalent of $prefix/$mandir, which is not really where all the HTML docs are stored in most distro builds. Plus, this value is missing a trailing slash, so links come out broken, like this in git.1: 1. Git User’s Manual /usr/share/manuser-manual.html Of course we can do better: 1. Change the default to match Make: use file://$(htmldir)/ (with trailing slash!) to form a local URL pointing at the HTML docs. This is safe because all current uses of link:<relative> point at HTML docs: git grep 'link:[[:alnum:]]' Documentation | grep -ve html -e http produces only a single result (Documentation/howto/howto-index.sh) which can be ignored. Since nothing else [*] in the normal build sets MAN_BASE_URL, this seems like the right default. 2. Provide a configurable knob, just like the Makefile, so distributions that build with Meson (like Gentoo) can decide where to make the links if they need to. Those that set htmldir probably won't need to tweak this any further, though. [*]: Well, Git's todo branch has a script dodoc.sh to build and archive docs for kernel.org; these docs are pulled by Homebrew installations, for example. It sets MAN_BASE_URL to "git_htmldocs", so the equivalent note on macOS + Homebrew is 1. Git User’s Manual git-htmldocs/user-manual.html which is not functional either, but that's a problem for downstream. In any case, users can recover the right path with "git --html-path". Signed-off-by: D. Ben Knoble <ben.knoble@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The order of assignments in repo_config_values_init is chaotic and hard to follow, especially with the definition of 'struct repo_config_values' to ensure all members are initialized. As new members will be added in the future, make it easier to validate changes by aligning the two. Refactor assignment order with no behavioral changes. Signed-off-by: D. Ben Knoble <ben.knoble@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Racy Git problems persist today, manifesting themselves in the performance of commands like "git diff" in new worktrees [1]. We have long had a build knob "USE_NSEC" to tell Git to use in-core nanosecond precision when available, which mitigates most if not all racy issues, but most builds we know about don't use it. In part, that's because someone distributing Git can't safely enable it at compile-time if they don't know exactly what platforms their distribution will be used on. [1]: https://lore.kernel.org/git/CALnO6CADMJSixqYvL1Yo8qKX5rWhKQ+2OoSEuPUh-yoeK9TseQ@mail.gmail.com These days, most platforms are likely to be safe for the USE_NSEC code. Regardless, we want to give users the ability to benefit from it. This requires exposing the compile-time gated code as a runtime option. In addition, update the Racy Git documentation and other mentions of USE_NSEC in the code. Due to the conversion from #ifdef to runtime check, using the flag "--ignore-space-change" may be particularly helpful when viewing changes from this patch. Signed-off-by: D. Ben Knoble <ben.knoble@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our "documentation" job has recently stopped working with the following error: + sudo gem install --version 1.5.8 asciidoctor + gem install --version 1.5.8 asciidoctor ./ci/install-dependencies.sh: 23: gem: not found The root cause of this is that we never explicitly install Ruby, and consequently gem(1) isn't explicitly pulled in, either. This used to work alright because we transitively pulled in Ruby via asciidoc. But due to an update it seems that we stopped pulling in the transitive dependency, and consequently we don't have gem(1) available anymore. Fix this by explicitly installing Ruby. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our "documentation" job has recently stopped working with the following error: + sudo gem install --version 1.5.8 asciidoctor + gem install --version 1.5.8 asciidoctor ./ci/install-dependencies.sh: 23: gem: not found The root cause of this is that we never explicitly install Ruby, and consequently gem(1) isn't explicitly pulled inus, either. This used to work alright because we transitively pulled in Ruby via asciidoc. But due to an update it seems that we stopped pulling in the transitive dependency, and consequently we don't have gem(1) available anymore. Fix this by explicitly installing Ruby. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our install-dependencies script avoids installing asciidoctor if the CI environment claims to have it already. But the only environment which made use of this was Azure Pipelines, which went away in 6081d38 (ci: retire the Azure Pipelines definition, 2020-04-11). So this conditional was effectively doing nothing. Let's clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function `cache_tree_fully_valid()` verifies whether the cache tree owned by the index is valid or not. As part of that, the function checks whether the objects referenced by the cache all exist. But because the function has no repository available, it is using the object database of `the_repository` instead. We could of course adapt callers to pass in a repository as parameter explicitly to get rid of this implicit dependency on global state. But all of them pass the cache tree owned by a `struct index_state`, and that structure already has a reference to its owning repository. So instead, adapt the function to accept a `struct index_state`, which ensures that callers will implicitly always pass the correct repository. Adapt callers accordingly. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "cache-tree" subsystem still depends on `the_repository`. Adapt it to instead use repositories provided via the context, either as a new parameter or the one passed in via `struct index_state`. Besides getting rid of `the_repository`, this also removes the last dependency on registering submodule sources with the main object database. When reading gitmodules from a submodule's index we implicitly read that object via `the_repository`'s object database, which is of course wrong. This works though because we would then register the submodule's object database with the main object database, but a later patch is going to get rid of that mechanism. You can verify that we indeed no longer depend on this mechanism by running tests with `GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB=true`. Without this patch we fail in t1092, with this patch we never register submodule object databases anymore. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Several functions in the submodule-config subsystem implicitly depend on `the_repository`. Refactor these to take a `struct repository` as parameter and adapt callers accordingly. Note that as usual with these refactorings, callers simply pass `the_repository` even if they already have a different repository available in the calling context. This simplifies the migration and ensures that we don't have a change in behaviour. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have two uses of `the_hash_algo` in "submodule-config.c":
- One trivial use in `gitmodules_cb`, which we can convert to use the
hash algorithm of the repository that's already available in the
caller's context.
- One use where we compute the hashmap key of an object ID. We should
only ever get valid, populated object IDs here, and consequently we
can easily adapt that function to use the hash algorithm of the
passed-in object ID.
Adapt both sites accordingly. Safeguard us against the case where the
passed-in object ID is _not_ properly initialized. While this case
shouldn't ever happen, it doesn't hurt to be defensive.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When reading the ".gitmodules" file from a blob in a repository other than `the_repository`, we register the repository's object database as an in-memory source of `the_repository`'s object database. This call has its origins in d9b8b8f (submodule-config.c: use repo_get_oid for reading .gitmodules, 2019-04-16): back then, `config_with_options()` was not able to read a blob from an arbitrary repository, but would always read it via `the_repository`. So even though the blob could be resolved in the submodule repository via `repo_get_oid()`, the submodule's object database had to be registered as an in-memory source of `the_repository` so that the subsequent object read was able to find the blob at all. That need went away with e3e8bf0 (submodule-config: pass repo upon blob config read, 2021-08-16), which taught the config machinery to read the blob from the repository we pass to it. The same series converted the eager submodule source registration into a lazy mechanism that only registers submodule sources with the object database when an object lookup failed. The intent though was that we don't ever have to fall back to this mechanism in the first place, and to verify that this is the case we introduced GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB. If set, then any such lazy registration would cause us to BUG. At the beginning of this series, we still triggered this bug in t1092. But now that we have converted the "cache-tree" subsystem to not depend on `the_repository` anymore it also knows to properly access objects via the submodule. With that change, GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB does not cause any failures anymore. Remove the call to `odb_add_submodule_source_by_path()`. This removes the last user of `the_repository`, so at the same time we can also get rid of `USE_THE_REPOSITORY_VARIABLE`. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Same as with the preceding commit, git-grep(1) registers each submodule's object database as an in-memory source of the main object database before grepping it. This was introduced as an eager alternate registration and converted into the lazy mechanism via 8d33c3a (grep: use submodule-ODB-as-alternate lazy-addition, 2021-08-16). Starting with 0693806 (grep: add repository to OID grep sources, 2021-08-16), the command instead knows to pass submodule repositories to our workers, which means that those now use that repository to look up objects, too. As a consequence, registering submodule sources as alternates is not required anymore. Remove the logic to register submodule sources. Unfortunately, this does not allow us to get rid of the object read lock as initializing the subrepository is still racy. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The preceding commits have removed the last two users of `odb_add_submodule_source_by_path()`. The mechanism was only ever meant as a transitional crutch while migrating submodule object access away from "add the submodule ODB as an alternate of the_repository" towards explicitly passing the submodule repository, see a35e03d (submodule: lazily add submodule ODBs as alternates, 2021-08-16). Remove it. As GIT_TEST_FATAL_REGISTER_SUBMODULE_ODB is now a no-op, remove its documentation and the exports from the test suite, as well. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The last caller of `tmp_objdir_add_as_alternate()` went away in bdee7b3 (builtin/receive-pack: stage incoming objects via ODB transactions, 2026-07-10) and is unused now. Remove the function. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When freeing a "packed" source we don't close either its packs nor its multi-pack indices. This can cause memory leaks in case we create an ad-hoc packed source. As we used to always link packed sources to the main object database we never noticed this issue until now, but it's going to surface in subsequent commits where we stop linking them. Plug the memory leaks by closing the source first. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users can tell git-multi-pack-index(1) to access multi-pack indices that are stored in a different object directory via the "--object-dir=" option. This allows them to for example write or verify a multi-pack index other than the one located in the main object directory in case a repository has alternates with multiple multi-pack indices. But while the documentation explicitly points out that the specified object directory must be an alternate of the current repository, we never verify that property. Instead, starting with 017db7b (midx: load multi-pack indices via their source, 2025-08-11), we now construct an ad-hoc source and link it to the main object directory. Besides contradicting the documentation, it's dubious that this really ought to work in the first place: creating a multi-pack index (and potentially a bitmap) for a completely foreign object directory is of questionable value, as bitmap commit selection operates on the invoking repository's refs. Furthermore, this is the only remaining caller outside of our test helpers that constructs an ad-hoc source and links it to the database, and we want to get rid of this mechanism as part of this series. Stop constructing the ad-hoc source and instead refuse the operation. While this results in a change in behaviour, this restriction has been documented as such ever since f57a739 (midx: avoid opening multiple MIDXs when writing, 2021-09-01). Note that this change requires us to adapt one test chain in t5319, as it creates an object directory that is not connected to any repository and then uses it via "--object-dir=". The setup itself already documents this and does the necessary gymnastics to link the object directory to a temporary repository, but subsequent tests don't. Adapt those tests to retain and reuse the temporary repository. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Same as in the preceding commit, refactor the setup of ad-hoc object database sources when accessing a multi-pack index in an arbitrary location to not link the newly created source into the main object database anymore. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the "ref-store" command we support access to multiple different reference stores. As part of that we allow the caller to explicitly exercise stores of a submodule. This allows us to verify low-level behaviour of submodule stores, which is exercised in t1406. When doing so we also link the submodule's object database into the main object database. The intent of this is that it allows us to access objects of the submodule, too. But that functionality is not even needed anymore: when creating a submodule reference store, we will first initialize the submodule repository and then initialize the store with that repository. And as the reference subsystem doesn't depend on `the_repository` anymore all subsequent object lookups performed by the reference store will be routed to the submodule repository. It is thus not needed anymore to register the submodule object store with the main object database. Remove the call. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Over the course of this patch series we have adapted all callers of `odb_add_to_alternates_memory()` to not do so anymore. Remove the function. This series of refactorings doesn't only simplify our code base. More importantly, with those changes in place we can now unconditionally assume that the list of sources linked to the object database only consists of the primary source and its alternates. This serves as the foundation to eventually move handling of alternates into the "files" backend itself. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/ref-syntax-tighten-symref: update-ref: verify stdin refnames as fully qualified refs: check syntax of symref target t1400: fix broken target of symref update symbolic-ref: tighten syntax check of target refname t0614: use test-tool to create garbage symref t3200: fully qualify symref destination refs: check syntax of symbolic ref names refs: take transaction flags for symref updates
* jk/rename-progress: diff: turn on rename detection progress reporting show: turn on rename detection progress reporting progress: use pager's original_stderr if available pager: save the original stderr when redirecting to pager
* jk/stash-show-prefix: revision: simplify mark_argv_for_free() callers revision: hang on to "freed" argv elements
* jk/string-list-cleanups: shortlog: initialize mailmap stuff mailmap into struct mailmap: another case of raw initialization mailmap: another case of pointless strdup_strings setting mailmap: prefer initializer to manual strdup_string set mailmap: drop manual setting of strdup_strings another initializer use a few more initializer uses notes: put string_list directly in struct drop a funky strdup_strings-then-clear case convert to union convert shortlog to hash shortlog: use initializer function for string_lists shortlog: avoid tricky strdup-before-clear string_list construct shortlog: drop redundant assignment of strdup_strings shortlog: drop redundant shortlog struct initialization
This is due to an interaction with my jk/mailmap-trailers topic.
* jk/submodule-remote-leak: submodule--helper: free URL when repository setup fails repository: make repo_clear() idempotent
* jk/symlink-out-of-tree: optionally block out-of-repo symlinks
* jk/textconv-utf16:
diff: enable autoencode by default
diff: add autoencode feature
diff: add utf-{16,32} binary detection
diff: convert filespec is_binary flag to enum
diff: respect diff_options inside get_textconv()
userdiff: give textconv its own struct
fill_textconv: always check DIFF_FILE_VALID()
* jk/trace-curl-redact: curl: handle non-http protocols in trace
* jk/trace-stdin: run-command config experiment trace: add GIT_TRACE_STDIN trace: add pid to each output line trace: implement %p placeholder for filenames
* jk/update-ref-rename: teach update-ref a "--rename" option
* jk/warn-ignored-object: fast-export: leave warnings to revision code prepare_revision_walk: complain of unused objects
Co-authored-by: peff <45925+peff@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Fix failing GitHub Actions job for debian-11
Remove expired Debian 11 CI job
Sep 5, 2026
peff
force-pushed
the
private
branch
7 times, most recently
from
September 11, 2026 22:36
7a874b6 to
8cdc957
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
debian-11 (debian:11)Actions job failed during dependency installation because Debian’s expired Bullseye security repository returned 404 forlibperl5.32.