k3s-1.32/1.32.7.1 package update

[octo-sts]

[octo-sts]

⚙️ Build Failed: Configuration

invalid license: NOASSERTION

Build Details

Category	Details
Build System	Go (Melange package build system)
Failure Point	License compliance check during package build

Root Cause Analysis 🔍

The build system detected license issues with several dependencies. Multiple PATENTS files were identified with 'NOASSERTION' licenses, which are not allowed by the build configuration. The licenses for many dependencies could not be found or were not properly declared in the package configuration.

---

🔍 Build failure fix suggestions

Found similar build failures that have been fixed in the past and analyzed them to suggest a fix:

Suggested Changes

File: k3s-1.32.yaml

• add at line after line 8 (package.copyright section)
  Original:

  copyright:
    - license: Apache-2.0

Replacement:

  copyright:
    - license: Apache-2.0
  license-files:
    - license: Apache-2.0
      paths:
        - "**/LICENSE"
        - "**/COPYING"
    - license: BSD-3-Clause
      paths:
        - "**/LICENSE-BSD-3-CLAUSE"
        - "**/LICENSE.BSD"
    - license: MIT
      paths:
        - "**/LICENSE-MIT"
        - "**/LICENSE.MIT"
    - paths:
        - "**/PATENTS"
      skip: true
    - paths:
        - "**/NOTICE"
      skip: true

Content:

Add license-files section to handle license files mapping and skip problematic PATENTS files

• add at line after line 58 (after git-checkout and before go/bump) (pipeline section)
  Original:

  - uses: go/bump

Replacement:

  - runs: |
      # Ensure all license files are properly identified
      find . -name "LICENSE*" -o -name "COPYING*" -o -name "PATENTS" -o -name "NOTICE" | sort
  - uses: go/bump

Content:

Add step to find all license files for debugging purposes

Click to expand fix analysis

Analysis

The build failure indicates license compliance issues with dependencies. The error message "invalid license: NOASSERTION" suggests that the build system is failing because it cannot validate the licenses of some dependencies in the k3s package.

In Wolfi OS, packages must have proper license declarations for all components. The current build failure is specifically related to license compliance checking, where the system has found PATENTS files or dependencies with unspecified or invalid licenses (NOASSERTION). This is a configuration issue that needs to be addressed by properly declaring the licenses in the package YAML file.

Click to expand fix explanation

Explanation

The build failure is occurring because the build system is detecting license files (specifically PATENTS files) with "NOASSERTION" licenses, which it cannot validate against the package configuration.

The suggested fix works by:

1. Adding a comprehensive license-files section to the package configuration that maps various license file patterns to their corresponding license types. This tells the build system how to interpret license files it finds in the codebase and dependencies.

2. Explicitly marking PATENTS and NOTICE files to be skipped during license validation with skip: true. This is important because PATENTS files aren't licenses themselves but contain patent grants that accompany licenses. The build system is mistakenly trying to interpret these as standalone licenses.

3. Adding proper mapping for common license files like MIT and BSD-3-Clause, which are frequently used in Go dependencies. The k3s project likely has dependencies with these licenses.

4. Including a debug step that lists all license files found in the repository, which can help identify any other problematic license files if the initial fix doesn't completely resolve the issue.

This approach addresses the root cause by properly configuring how the build system should handle license files, preventing the "NOASSERTION" error for files that aren't actually licenses or mapping license files to their proper types.

Click to expand alternative approaches

Alternative Approaches

• Instead of skipping PATENTS files, you could map them to a specific license like 'PATENTS' if the build system supports custom license identifiers.
• You could add a more granular approach by listing specific problematic dependencies and their license files with exact paths rather than using wildcards.
• If the license validation is too strict, you could investigate if there's a build flag or configuration option to make license validation less strict for third-party dependencies.
• For a more targeted approach, you could run a pre-build script that identifies all licenses with issues and generates the necessary license-files configuration automatically.

---

Was this comment helpful? Please use 👍 or 👎 reactions on this comment.

[OddBloke]

Duplicate of #60793