DNM: Misc Chromium changes

[EyeCantCU]

Fixes:

Related:

Pre-review Checklist

For new package PRs only

• This PR is marked as fixing a pre-existing package request bug
  • Alternatively, the PR is marked as related to a pre-existing package request bug, such as a dependency
• REQUIRED - The package is available under an OSI-approved or FSF-approved license
• REQUIRED - The version of the package is still receiving security updates
• This PR links to the upstream project's support policy (e.g. endoflife.date)

For new version streams

• The upstream project actually supports multiple concurrent versions.
• Any subpackages include the version string in their package name (e.g. name: ${{package.name}}-compat)
• The package (and subpackages) provides: logical unversioned forms of the package (e.g. nodejs, nodejs-lts)
• If non-streamed package names no longer built, open PR to withdraw them (see WITHDRAWING PACKAGES)

For package updates (renames) in the base images

When updating packages part of base images (i.e. cgr.dev/chainguard/wolfi-base or ghcr.io/wolfi-dev/sdk)

• REQUIRED cgr.dev/chainguard/wolfi-base and ghcr.io/wolfi-dev/sdk images successfully build
• REQUIRED cgr.dev/chainguard/wolfi-base and ghcr.io/wolfi-dev/sdk contain no obsolete (no longer built) packages
• Upon launch, does apk upgrade --latest successfully upgrades packages or performs no actions

For security-related PRs

• The security fix is recorded in the advisories repo

For version bump PRs

• The epoch field is reset to 0

For PRs that add patches

• Patch source is documented

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the build error, there's a conflict with the _FORTIFY_SOURCE macro being defined multiple times with different values (2 and 3). This is causing compilation warnings that are being treated as errors. Here are a few suggestions to resolve this:

1. Add -Wno-macro-redefined to the compiler flags to suppress these specific warnings:

  - runs: |
      # Add to existing CFLAGS/CXXFLAGS
      export CFLAGS="$CFLAGS -Wno-macro-redefined"
      export CXXFLAGS="$CXXFLAGS -Wno-macro-redefined"

2. Explicitly undefine _FORTIFY_SOURCE before redefining it in the compile flags:

  - runs: |
      export CFLAGS="$CFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2"
      export CXXFLAGS="$CXXFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2"

3. Remove openssf-compiler-options from the environment packages since it might be enforcing _FORTIFY_SOURCE=3, and add the security flags manually:

environment:
  contents:
    packages:
      # Remove this line
      #- openssf-compiler-options

Try option 1 first as it's the least invasive change. If that doesn't work, try option 2. Option 3 should be a last resort since security hardening is important.

These warnings are occurring because Chromium's build system is trying to set _FORTIFY_SOURCE=2 while the system (via openssf-compiler-options) is setting it to 3. Since this is just a warning and not an actual error, suppressing it should be safe as long as one value is consistently applied during the actual compilation.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, there seems to be an issue with creating a symbolic link for Node.js during the Chromium build process. The specific error is:

ln: third_party/node/linux/node-linux-x64/bin/node: File exists
'third_party/node/linux/node-linux-x64/bin/node' -> '/usr/bin/node'

To fix this, you can modify the Node.js setup section in the pipeline to:

1. Remove the existing symlink first
2. Create the new symlink

Update this section in your melange.yaml:

# === INFO === Use host's node
cd /home/src
mkdir -p third_party/node/linux/node-linux-x64/bin
rm -f third_party/node/linux/node-linux-x64/bin/node  # Add this line
ln -sv /usr/bin/node third_party/node/linux/node-linux-x64/bin/

This modification will:

1. Ensure the target directory exists
2. Remove any existing symlink or file
3. Create the new symlink

The error occurs because the symlink target already exists, and the ln command fails when trying to create a new symlink over an existing one without the -f flag. This change should resolve the build error by properly handling the Node.js symlink creation.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the build error, there's a conflict with the _FORTIFY_SOURCE macro being defined multiple times with different values (2 and 3). This is a common issue when building with security hardening flags. Here's how we can fix it:

1. Modify the CFLAGS/CXXFLAGS in the pipeline to explicitly set _FORTIFY_SOURCE=2 and prevent it from being redefined:

  - runs: |
      # Add -U_FORTIFY_SOURCE before defining it to undefine any previous definition
      export CFLAGS="$CFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unknown-warning-option -Wno-builtin-macro-redefined -Wno-deprecated-declarations -Wno-shift-count-overflow -Wno-ignored-attributes"
      export CXXFLAGS="$CXXFLAGS -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wno-unknown-warning-option -Wno-builtin-macro-redefined -Wno-deprecated-declarations -Wno-invalid-constexpr"

2. Alternatively, if you want to keep FORTIFY_SOURCE=3, you can modify the GN args to respect the system's FORTIFY_SOURCE setting by adding:

      time gn gen /home/src/out/Default --args="
        # ... existing args ...
        enable_iterator_debugging=false
        # Add this line:
        is_fortify_source=false
        # ... rest of existing args ...
      "

The first approach is recommended since Chromium is typically built with FORTIFY_SOURCE=2, and this will ensure better compatibility. The -U_FORTIFY_SOURCE flag will undefine any previous definition before setting it to 2.

These warnings are causing the build to fail because they're being treated as errors. The fix should resolve the macro redefinition conflict and allow the build to proceed.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, the main issue appears to be that bindgen cannot find the 'stddef.h' header file when trying to generate Rust bindings for libyuv. Here are some suggestions to fix this:

1. Add libc-dev to the build dependencies. The stddef.h header is typically provided by this package:

environment:
  contents:
    packages:
      # Add this near the top of your package list
      - libc-dev
      # ... rest of your existing packages

2. If libc-dev is already present, try adding clang's standard include path explicitly to the bindgen command by modifying the CFLAGS/CXXFLAGS:

  environment:
    environment:
      CFLAGS: "${CFLAGS} -I/usr/lib/llvm-19/lib/clang/19/include"
      CXXFLAGS: "${CXXFLAGS} -I/usr/lib/llvm-19/lib/clang/19/include"

3. There's also a warning about _FORTIFY_SOURCE being redefined. While this isn't the primary error, you might want to clean it up by ensuring consistent definition. Add this to your environment:

  environment:
    environment:
      CPPFLAGS: "${CPPFLAGS} -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2"

Try these changes and see if they resolve the bindgen error. The most important one is likely adding libc-dev as it provides the missing header file.

If the issue persists, you can try debugging the bindgen command directly when running melange with --interactive by:

1. Checking if stddef.h exists: find /usr -name stddef.h
2. Verifying the clang include paths: clang -v -E -x c /dev/null
3. Running the bindgen command manually with added -v flag for verbose output

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the build error, it appears the main issue is with the Rust bindgen tool failing to find the stddef.h header file. The specific error is:

fatal error: 'stddef.h' file not found

Here are a few suggestions to fix this:

1. Add gcc-dev to the build dependencies in the environment section. This package provides core system headers including stddef.h:

environment:
  contents:
    packages:
      - gcc-dev
      # existing packages...

2. Add libc-dev which also provides some core system headers:

environment:
  contents:
    packages:
      - libc-dev
      # existing packages...

3. The error could also be related to the clang resource directory path. Make sure the --resource-dir argument points to the correct location of the clang headers. Check if the path ../../../../usr/lib/llvm-19/lib/clang/19 exists and contains the required headers.

4. There's also a warning about _FORTIFY_SOURCE being redefined. While this warning shouldn't cause the build to fail, you might want to remove one of the definitions to clean up the build output. Look for duplicate definitions in the compiler flags.

Try adding both gcc-dev and libc-dev first as this is the most likely solution, since bindgen needs access to core system headers to generate the Rust bindings.

The error occurs during the rust bindgen step when trying to generate bindings for the libyuv library, so ensuring all required system headers are available is crucial.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error message, the main issue appears to be:

sed: services/device/public/cpp/usb/BUILD.gn: No such file or directory

This suggests that the path structure in the Chromium source code has changed in version 130.0.6723.116. Here are a few steps to fix this:

1. First, verify the correct path for the USB-related BUILD.gn file. You can do this by:

   • Running the build with --interactive
   • Once in the shell, use find . -name BUILD.gn | grep -i usb to locate the correct path

2. Update the sed command in the pipeline. The current line:

sed 's|//third_party/usb_ids/usb.ids|/usr/share/hwdata/usb.ids|g' \
    -i services/device/public/cpp/usb/BUILD.gn

needs to be updated with the correct path.

3. Alternative approach: You might want to add a safeguard around the sed command:

if [ -f services/device/public/cpp/usb/BUILD.gn ]; then
  sed 's|//third_party/usb_ids/usb.ids|/usr/share/hwdata/usb.ids|g' \
      -i services/device/public/cpp/usb/BUILD.gn
fi

4. You might also need to check if the USB IDs path structure has changed in this version of Chromium. Verify the original path (//third_party/usb_ids/usb.ids) is still valid in the source code.

The underlying issue is likely due to Chromium's source code structure changing between versions, which is common in large projects. The fix involves updating the paths to match the new source code structure.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error message, it appears the build is failing because it can't find the file services/device/public/cpp/usb/BUILD.gn when trying to perform the sed operation to modify USB IDs path.

Here are a few steps to debug and fix this:

1. First, verify the path structure in the extracted source code. You might need to update the sed command path to match the actual location of the BUILD.gn file. After the fetch step, you can check the directory structure:

- runs: |
    # Debug: Check directory structure
    find . -name "BUILD.gn" | grep -i usb
    
    # Then update the sed path accordingly
    # Update the path if different:
    sed 's|//third_party/usb_ids/usb.ids|/usr/share/hwdata/usb.ids|g' \
      -i path/to/correct/BUILD.gn

2. Another approach would be to make the sed command conditional:

- runs: |
    if [ -f services/device/public/cpp/usb/BUILD.gn ]; then
      sed 's|//third_party/usb_ids/usb.ids|/usr/share/hwdata/usb.ids|g' \
        -i services/device/public/cpp/usb/BUILD.gn
    fi

3. You might also want to check if the structure changed in this version of Chromium. Sometimes upstream reorganizes files. Check the Chromium source for version 130.0.6723.116 to confirm the correct path.

4. If the USB ID modification is not critical, you could temporarily comment out that sed command to see if the build proceeds:

# Comment out temporarily to debug
# sed 's|//third_party/usb_ids/usb.ids|/usr/share/hwdata/usb.ids|g' \
#   -i services/device/public/cpp/usb/BUILD.gn

Try these approaches one at a time to identify and fix the issue. The most likely solution is that the path needs to be updated to match the current Chromium source structure.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, it seems the build is failing when trying to remove a file named 'FILE' that doesn't exist. This is likely happening during the cleanup phase after the source tarball is downloaded and verified.

Here are a few suggestions to fix this issue:

1. Check the fetch pipeline:
   The error occurs after the fetch step completes successfully. The fetch pipeline downloaded and verified the chromium tarball correctly, but something in the subsequent cleanup or preparation step is failing.

2. Remove unnecessary file operations:
   Look for any rm commands in the pipeline that might be trying to remove files that don't exist. In particular, check for:

• Hard-coded file removals
• Cleanup steps that assume certain files exist
• File operation commands that don't handle missing files gracefully

3. Add error handling:
   Modify file removal commands to ignore errors for missing files by adding -f flag:

runs: |
    rm -f FILE  # Instead of just rm FILE

4. Debug the build interactively:
   Run melange with the --interactive flag to debug the build environment:

melange build --interactive package.yaml

Then you can:

• Check what files exist
• Test file operations manually
• See exactly where the failure occurs

5. Review the scanelf cleanup step:
   The error might be related to this section:

runs: |
    scanelf -RA -F "%F" "$HOME" | while read -r elf; do
      rm -f "$elf"
    done

Make sure this operation handles empty/missing files correctly.

The most straightforward fix would be to make any rm commands use the -f flag to ignore missing files, or add error checking around file operations.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error log, there are two main issues to address:

1. The scanelf errors with "ar: invalid number: -1"
2. The ninja build failing with "ninja: chdir: No such file or directory"

Let's fix these issues:

1. For the scanelf errors, modify the scanelf command to be more specific and handle archives better:

- runs: |
      # Modified scanelf command to properly handle binaries
      find "$HOME" -type f -executable -o -name "*.so*" | while read -r file; do
        if file "$file" | grep -q "ELF"; then
          rm -f "$file"
        fi
      done

2. For the ninja build directory error, the path needs to be corrected. The error shows it's trying to use /home/build/out/Default but earlier the path was set to /home/src/out/Default. Update the ninja command:

# Change from:
time ninja -C $HOME/out/Default chrome chromedriver.unstripped chrome_crashpad_handler chrome_sandbox

# To:
time ninja -C /home/src/out/Default chrome chromedriver.unstripped chrome_crashpad_handler chrome_sandbox

Also, ensure the gn gen command creates the output directory first:

mkdir -p /home/src/out/Default
time gn gen /home/src/out/Default --args="

These changes should:

1. Fix the scanelf errors by using a more reliable method to identify and remove binaries
2. Ensure the build directory exists and is correctly referenced
3. Maintain consistent path usage throughout the build process

When debugging interactively, you can verify the correct paths exist using:

ls -la /home/src/out/Default  # Check if directory exists
pwd  # Verify current working directory

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, the main issue appears to be with the Rust bindgen tool failing to find the stddef.h header file when trying to generate bindings for libyuv. Here are some suggestions to fix this:

1. Add libc-dev to the build environment packages. This package typically contains the standard C headers including stddef.h:

environment:
  contents:
    packages:
      - libc-dev  # Add this line
      # ... existing packages ...

2. Explicitly specify the system include path for clang in the bindgen flags. Add these flags to the relevant build command:

pipeline:
  - runs: |
      # Add system include paths to CFLAGS
      export CFLAGS="$CFLAGS -I/usr/include"
      # ... rest of the build commands ...

3. Since there's also a warning about _FORTIFY_SOURCE being redefined, you might want to ensure consistent definition by removing it from one location or making them match. In the YAML, look for multiple definitions of _FORTIFY_SOURCE and ensure they're consistent:

environment:
  environment:
    # Remove or update any _FORTIFY_SOURCE definition to match the system value (3)
    CFLAGS: "-D_FORTIFY_SOURCE=3"

4. If the above doesn't work, you might need to add additional include paths for the compiler:

environment:
  environment:
    # Add these to help find necessary headers
    CFLAGS: "-I/usr/include -I/usr/lib/llvm-19/lib/clang/19/include"
    CXXFLAGS: "-I/usr/include -I/usr/lib/llvm-19/lib/clang/19/include"

Try these changes one at a time, starting with adding libc-dev as it's the most likely solution for the missing stddef.h error.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, there are two main issues:

1. Missing header files:

fatal error: 'stddef.h' file not found
fatal error: 'stdarg.h' file not found

2. Conflicting FORTIFY_SOURCE definitions:

warning: '_FORTIFY_SOURCE' macro redefined [-Wmacro-redefined]

Here are the suggested fixes:

1. Add missing C standard library headers by including musl-dev in the environment packages:

environment:
  contents:
    packages:
      - musl-dev  # Add this package

2. Remove the duplicate FORTIFY_SOURCE definition from the build flags. In the runs section where you set up the gn configuration, modify the CPPFLAGS to avoid redefining FORTIFY_SOURCE:

export CPPFLAGS="${CPPFLAGS/-D_FORTIFY_SOURCE=2/} -D__DATE__=  -D__TIME__=  -D__TIMESTAMP__="

3. Since this is using rust-bindgen, you may also need to add:

environment:
  contents:
    packages:
      - clang-dev
      - rust-bindgen

These changes should resolve the header file missing errors and the macro redefinition warnings. The key issues were missing development headers and conflicting compiler flags.

Try these changes and rebuild. If you still encounter issues, you may need to adjust the rust-bindgen configuration or add additional development packages.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, there are two main issues to address:

1. The primary error is:

fatal error: 'stddef.h' file not found

This suggests missing C standard library headers needed for the build.

2. There's also a _FORTIFY_SOURCE redefinition warning, though this is likely not the main blocker.

Here are the suggested fixes:

1. Add the following development packages to the environment section:

environment:
  contents:
    packages:
      # Add these packages
      - libc-dev
      - clang-${{vars.llvm-version}}-dev
      # ... rest of existing packages

2. If that alone doesn't resolve it, you may need to explicitly set the system include path for clang. Add these environment variables:

environment:
  environment:
    # Add these along with existing environment vars
    CPATH: "/usr/include"
    C_INCLUDE_PATH: "/usr/include"
    CPLUS_INCLUDE_PATH: "/usr/include"

3. For the _FORTIFY_SOURCE warning, you could try removing it from the build flags or standardizing on one version. However, this warning is likely not causing the build failure and can be addressed separately if needed.

The key focus should be on ensuring the basic C headers are available to the build system by adding the libc-dev package and setting up the include paths correctly.

Testing locally with --interactive would allow you to verify the headers are available by checking:

ls /usr/include/stddef.h

[tuananh]

@EyeCantCU i'm curious to why we need to switch to gentoo's tarball?

[EyeCantCU]

@tuananh it saves us from needing to run gclient to fetch Chromium's dependencies. gclient pulls down utilities based on arch and a few are only present for linux-x64. The idea actually came from Alpine where they do this to build Chromium for aarch64 natively

Gentoo hosts archives for each Chromium revision where they've gone ahead and synced dependencies themselves with gclient and then produced a tarball. I guess we could do that with qemu

[tuananh]

Interesting. Up until now, Wolfi only provide amd64 build for chromium right?

[EyeCantCU]

Interesting. Up until now, Wolfi only provide amd64 build for chromium right?

Exactly

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, there are two main issues:

1. Missing standard header files:

fatal error: 'stdarg.h' file not found
fatal error: 'stddef.h' file not found

2. Conflicting FORTIFY_SOURCE definitions between level 2 and 3.

Here are the suggested fixes:

1. Add the missing standard header dependencies:

environment:
  contents:
    packages:
      # Add these packages
      - clang-runtime-${{vars.llvm-version}}
      - compiler-rt-${{vars.llvm-version}}
      - libc-dev

2. Remove the conflicting FORTIFY_SOURCE definition from the build flags by modifying the environment section:

environment:
  environment:
    # Remove _FORTIFY_SOURCE=2 from CFLAGS/CXXFLAGS if set
    CFLAGS: "-Wno-unknown-warning-option -Wno-builtin-macro-redefined -Wno-deprecated-declarations -Wno-shift-count-overflow -Wno-ignored-attributes"
    CXXFLAGS: "-Wno-unknown-warning-option -Wno-builtin-macro-redefined -Wno-deprecated-declarations -Wno-invalid-constexpr"

3. Alternative approach - modify the bindgen flags to include system headers:

pipeline:
  - runs: |
      # Add this before bindgen commands
      export BINDGEN_EXTRA_CLANG_ARGS="-I/usr/lib/clang/${{vars.llvm-version}}/include"

These changes should help resolve the header file not found errors and the FORTIFY_SOURCE conflict. The key is ensuring the proper header files are available and managing the compiler flags consistently.

Try these changes one at a time to identify which resolves the issue while maintaining the security benefits of FORTIFY_SOURCE.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, the main issue appears to be that bindgen cannot find the 'stddef.h' header file when trying to generate Rust bindings for the libyuv library. The specific error is:

fatal error: 'stddef.h' file not found

Here are a few suggestions to fix this:

1. Add the missing header paths to the build environment:

environment:
  contents:
    packages:
      # Add these packages
      - linux-headers
      - clang-dev
      - glibc-dev-static

2. Explicitly include the system header path in the bindgen flags. Add these flags to the build command:

--clang-arg=-I/usr/include
--clang-arg=-I/usr/lib/clang/19/include

3. If using rust-bindgen, ensure the correct sysroot is set by adding:

environment:
  environment:
    BINDGEN_EXTRA_CLANG_ARGS: "-I/usr/include -I/usr/lib/clang/19/include"

4. There's also a warning about _FORTIFY_SOURCE being redefined. Consider removing one of the definitions or making sure they're consistent. You can modify the CFLAGS/CXXFLAGS to use a single definition:

environment:
  environment:
    CFLAGS: "-D_FORTIFY_SOURCE=3"
    CXXFLAGS: "-D_FORTIFY_SOURCE=3"

Try implementing these changes one at a time to see which resolves the issue. The most likely fix is adding the correct header paths for bindgen.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error log, the main issue appears to be with bindgen failing to find the 'stddef.h' header file:

fatal error: 'stddef.h' file not found

Here are a few steps to help fix this issue:

1. Add clang-dev to the build environment dependencies, as it provides necessary headers:

environment:
  contents:
    packages:
      - clang-dev
      # ... existing packages ...

2. Make sure the compiler can find the system headers by adding them to the include path. Add these flags to the environment section:

environment:
  environment:
    CFLAGS: "-I/usr/include"
    CXXFLAGS: "-I/usr/include"

3. Alternatively, you could try adding libc-dev explicitly:

environment:
  contents:
    packages:
      - libc-dev
      # ... existing packages ...

4. If the issue persists, you may need to explicitly set the system include path for bindgen by adding these flags to the bindgen command:

pipeline:
  - runs: |
      # Add to existing bindgen command
      --clang-arg=-I/usr/include

The error appears to be related to missing system headers during the Rust bindgen process. Adding the appropriate development packages and include paths should resolve the issue.

Choose the solution that best fits your needs - starting with adding clang-dev and libc-dev would be the most straightforward approach.

[octo-sts]

Gen AI suggestions to solve the build error:

Based on the error output, I'll provide a detailed analysis and solution:

• Detected Error: FileNotFoundError: [Errno 2] No such file or directory: '/home/build/third_party/flac/BUILD.gn'

• Error Category: Build Configuration

• Failure Point: Python script execution in replace_gn_files.py during the system library unbundling process

• Root Cause Analysis: The script is trying to replace GN build files for system libraries, but some expected files are missing after the cleanup step. This suggests the cleanup script removed files needed by the build system.

• Suggested Fix:

1. Modify the system libraries list in the pipeline to remove FLAC:

system_libs="
  brotli
  crc32c
  dav1d
  double-conversion
  # Remove flac from this list
  fontconfig
  harfbuzz-ng
  libdrm
  libevent
  libjpeg
  libsecret
  libusb
  libwebp
  libxml
  libxslt
  openh264
  opus
  zlib
  zstd
"

2. Add FLAC to the excluded libraries section in the file deletion logic:

\! -path "*third_party/flac/*" \

• Explanation: The current unbundling process is trying to use the system FLAC library but failing to properly handle the build file replacement. By removing FLAC from the system libraries list, we'll let Chromium use its bundled version instead, which is a common approach when system library integration causes issues.

• Additional Notes:

• This is a known issue with Chromium's build system where some libraries don't properly support unbundling
• Using the bundled FLAC library is safe and commonly done in other distributions
• The trade-off is slightly larger build size but better build reliability

• References:

• Chromium Build Documentation: https://chromium.googlesource.com/chromium/src/+/main/docs/linux/build_instructions.md
• Similar issues in Chromium bug tracker: https://bugs.chromium.org/p/chromium/issues/detail?id=800737