bazel_dep(name = "abseil-cpp", version = "20250814.1", repo_name = "com_google_absl")
single_version_override(
    module_name = "abseil-cpp",
    patch_strip = 1,
    patches = [
        "//third_party/absl:build_dll.patch",
        "//third_party/absl:endian.patch",
    ],
)

bazel_dep(name = "nlohmann_json", version = "3.12.0.bcr.1", repo_name = "nlohmann_json_lib")

#
# Given an RPM spec file $1, apply its patches.

SPEC="$1"
grep '%patch' "${SPEC}" |while read cmd ; do
  N=$(echo "${cmd}" |sed 's,%patch\([0-9]\+\).*,\1,')
  file=$(grep "Patch$N:" "${SPEC}" |sed 's,.*: ,,')
  parg=$(echo "${cmd}" |sed 's,.*\(-p[0-9]\).*,\1,')
  if [[ ! "${file}" =~ doxygen && "${cmd}" != \#* ]]; then
    echo "patch ${parg} -s < ${file}"
    patch ${parg} -s < "${file}"
  fi

  Push your changes to a topic branch in your fork of the repository.
+ Make commits of logical units.
+ Respect the original code style: by using the same [codestyle][code-style],
  patches should only highlight the actual difference, not being disturbed by any formatting issues:
  + Only use spaces for indentation.
  + Create minimal diffs - disable on save actions like reformat source code or organize imports.

for v in "${PYTHON_VERSIONS[@]}"; do
  ln -s "/usr/local/include/${v}" "/${TARGET}/usr/include/x86_64-linux-gnu/${v}"
done

# Patch glibc to be compatable with modern clang
case "${VERSION}" in
devtoolset-9)
  cd /
  patch -p0 < /glibc2.17-inline.patch
;;

---

### 🌱 **Contributing to Gradle**

- **Contribution Guide**: [Contribute](https://github.com/gradle/gradle/blob/master/CONTRIBUTING.md) to Gradle by submitting patches or pull requests for code or documentation improvements.
- **Code of Conduct**: Gradle enforces a [Code of Conduct](https://gradle.org/conduct/) to ensure a welcoming and supportive community for all contributors.

---

potentially exploit a vulnerability in the TensorFlow code that handles videos,
which could allow them to execute arbitrary code on the system running
TensorFlow.

It is important to keep TensorFlow up to date with the latest security patches
and follow the sandboxing guideline above to protect against these types of
vulnerabilities.

## Security properties of execution modes

TensorFlow has several execution modes, with Eager-mode being the default in v2.

/**
 * The option of a Java command-line tool where to place the paths to some dependencies.
 * A {@code PathType} can identify the class path, the module path, the patches for a specific module,
 * or another kind of path.
 *
 * <p>One path type is handled in a special way: unlike other options,
 * the paths specified in a {@code --patch-module} Java option is effective only for a specified module.

![image](https://github.com/tensorflow/tensorflow/assets/52792999/3eea4ca5-daa0-4570-b0b5-2a2b03a724a3)

### Contributor License Agreements

We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.

Please fill out either the individual or corporate Contributor License Agreement (CLA).

### Feature

- 'kubeadm: enhanced the "patches" functionality to be able to patch coredns
  deployment. The new patch target is called "corednsdeployment" (e.g. patch file
  "corednsdeployment+json.json"). This makes it possible to apply custom patches

  
  - https://github.com/kubernetes-sigs/kustomize/pull/4911: Drop support for a very old, legacy style of patches. patches used to be allowed to be used as an alias for patchesStrategicMerge in kustomize v3. You now have to use patchesStrategicMerge explicitly, or update to the new syntax supported by patches. See examples in the PR description of https://github.com/kubernetes-sigs/kustomize/pull/4911.