datadog-agent/7.60.1 package update

[octo-sts]

datadog-agent and datadog-agent-nvml: various fixes to work with latest

• add libpcap
• symlink so build avoids downloading libpcap and uses system lib
• regen dep bump patch
• build with python 3.12 as integration dependencies require it"
  ERROR: Package 'datadog-slurm' requires a different Python: 3.11.11 not in '>=3.12'
• compile datadog-agent-nvml with python 3.12
• patch to disable new gpu monitor as causing test failures, it's not expected to be enabled by default, upstream issue tracked [BUG] agent: symbol lookup error: /opt/datadog-agent/bin/agent/agent: undefined symbol: nvmlVgpuTypeGetCapabilities DataDog/datadog-agent#32419

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the build error, here's the analysis and solution:

• Detected Error: /bin/bash: line 1: curl: command not found

• Error Category: Dependency

• Failure Point: Package build step trying to download and extract libpcap source

• Root Cause Analysis: The build environment is missing the curl package which is needed to download the libpcap source code

• Suggested Fix: Add curl to the environment.contents.packages section in the melange YAML:

environment:
  contents:
    packages:
      - curl  # Add this line
      - bison
      - build-base
      # ... rest of existing packages

• Explanation: The build process needs to download libpcap source code using curl but the command is not available in the build environment. Adding curl as a build dependency will allow the download step to complete successfully.

• Additional Notes:

• This is a common pattern in build systems where external source tarballs need to be downloaded
• The error occurs in a later stage of the build after the eBPF object compilation
• The fix is straightforward and doesn't impact the core build process
• libpcap is likely needed for network packet capture capabilities in the agent

• References:

• libpcap source: https://www.tcpdump.org/release/
• Melange environment documentation: https://github.com/chainguard-dev/melange#environment

The provided fix should allow the build to progress past the libpcap download step and complete successfully.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, here's my analysis and suggested fix:

• Detected Error: /bin/bash: line 1: /opt/datadog-agent/embedded/bin/clang-bpf: No such file or directory

• Error Category: Build Configuration/Dependency

• Failure Point: During system-probe build step when trying to use clang-bpf

• Root Cause Analysis: The build is failing because it can't find the required clang-bpf binary in the expected location, which is needed for eBPF compilation.

• Suggested Fix:
Add these steps to the pipeline before the system-probe.build command:

- runs: |
    mkdir -p ${{vars.destd}}/embedded/bin
    wget -q https://dd-agent-omnibus.s3.amazonaws.com/llvm/clang-12.0.1.amd64 -O ${{vars.destd}}/embedded/bin/clang-bpf
    wget -q https://dd-agent-omnibus.s3.amazonaws.com/llvm/llc-12.0.1.amd64 -O ${{vars.destd}}/embedded/bin/llc-bpf
    chmod +x ${{vars.destd}}/embedded/bin/clang-bpf ${{vars.destd}}/embedded/bin/llc-bpf

• Explanation: The DataDog agent's system-probe component requires specific versions of clang tools for eBPF compilation. These tools need to be downloaded and placed in the correct location before building.

• Additional Notes:

• The error occurs because the build system expects pre-built LLVM tools
• These specific binaries are used by DataDog for eBPF program compilation
• The files need to be executable for the build process to use them

• References:

• https://github.com/DataDog/datadog-agent/blob/main/docs/dev/system_probe.md
• https://github.com/DataDog/datadog-agent/blob/main/pkg/ebpf/bytecode/runtime/runtime-security.c

[octo-sts]

Gen AI suggestions to solve the build error:

• Detected Error: "Cannot change ownership to uid 1000, gid 1000: Invalid argument" when extracting libpcap source

• Error Category: Build Configuration

• Failure Point: tar extraction of libpcap source code during build process

• Root Cause Analysis: The build system is attempting to preserve ownership during tar extraction, but lacks permissions to set UIDs/GIDs in the container environment due to security restrictions.

• Suggested Fix: Add --no-same-owner flag to the tar extraction command. Modify the command to:

- runs: |
    cd /home/build/dev/dist && curl -L https://www.tcpdump.org/release/libpcap-1.10.5.tar.xz | tar xJ --no-same-owner

• Explanation: The --no-same-owner flag tells tar to extract files as the current user instead of trying to preserve original ownership metadata, which fails in restricted container environments.

• Additional Notes:

• This is a common issue in containerized builds where UID/GID preservation is not possible or desired
• The fix maintains build reproducibility while avoiding permission errors
• No functional impact on the built package

• References:

• GNU tar manual: https://www.gnu.org/software/tar/manual/html_node/no_002dsame_002downer.html
• Related issue in container builds: Add ability to mount volume as user other than root moby/moby#2259

[octo-sts]

Gen AI suggestions to solve the build error:

• Detected Error: tar: Cannot change ownership to uid 1000, gid 1000: Invalid argument

• Error Category: Configuration/Permission

• Failure Point: Extracting libpcap source code during build process

• Root Cause Analysis: The error occurs because tar is trying to preserve ownership during extraction but fails due to container/build environment permissions. This is a common issue in containerized builds where the UID/GID mapping doesn't align.

• Suggested Fix: Add --no-same-owner flag to the tar extraction command. Modify the command line to:

- runs: |
    cd /home/build/dev/dist && curl -L https://www.tcpdump.org/release/libpcap-1.10.5.tar.xz | tar xJ --no-same-owner

• Explanation: The --no-same-owner flag tells tar to extract files as the current user rather than trying to preserve the original ownership metadata, which prevents permission errors in containerized environments.

• Additional Notes:

• This is a common issue in container builds where UID/GID mappings differ
• The fix allows extraction without ownership preservation
• Does not affect functionality of the built package
• Safe to use in build environments since file ownership in the source doesn't matter for compilation

• References:

• GNU tar documentation: https://www.gnu.org/software/tar/manual/html_node/no_002dsame_002downer.html
• Related Docker issue: Add ability to mount volume as user other than root moby/moby#2259