Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Backport release-22.05] arm-trusted-firmware: unfree only if hdcp.bin used #176339

Merged
merged 1 commit into from Jul 3, 2022
Merged

Conversation

ghost
Copy link

@ghost ghost commented Jun 5, 2022

This is a cherry-pick of 8485bfc which was merged from issue #174691.

This commit reduces the scope of a breaking change relative to 21.11.

Specifically, it allows the arm-trusted-firmware for non-Rockchip devices to be built without NIXPKGS_ALLOW_NONFREE=1, as was possible in 21.11.

Description of changes

The unfreeIncludeHDCPBlob parameter was introduced as a result of
this reviewer request:

#148890 (comment)

The default value unfreeIncludeHDCPBlob?true causes a change in the
meta.license field for all of the subpackages within
pkgs/misc/arm-trusted-firmware/, and results in them needing
NIXPKGS_ALLOW_NONFREE=1.

For non-Rockchip platforms the file hdcp.bin does not get included in
the output; the blob is for a Synopsys HDCP core that is currently
used only by Rockchip (although other companies could license it from
Synopsys in the future). Therefore on non-Rockchip we can delete
hdcp.bin before building instead of changing the license. This
preserves the ability to build them without NIXPKGS_ALLOW_NONFREE=1.

Let's do that.

Deleting hdcp.bin ensures that we won't be caught by surprise if some
future non-Rockchip Arm CPU licenses the same Synopsys HDCP core that
Rockchip is using.

Use easier-to-follow names for controlling the blob
inclusion/exclusion. Also, if the blob is believed to be unnecessary,
delete it beforehand so we will know if we were wrong about that belief.

Co-authored-by: Sandro sandro.jaeckel@gmail.com
(cherry picked from commit 8485bfc)

Things done
  • Built on platform(s)
    • x86_64-linux
    • aarch64-linux
    • x86_64-darwin
    • aarch64-darwin
  • For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
  • Tested, as applicable:
  • Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
  • Tested basic functionality of all binary files (usually in ./result/bin/)
  • 22.11 Release Notes (or backporting 22.05 Release notes)
    • (Package updates) Added a release notes entry if the change is major or breaking
    • (Module updates) Added a release notes entry if the change is significant
    • (Module addition) Added a release notes entry if adding a new NixOS module
    • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
  • Fits CONTRIBUTING.md.

The `unfreeIncludeHDCPBlob` parameter was introduced as a result of
this reviewer request:

  #148890 (comment)

The default value `unfreeIncludeHDCPBlob?true` causes a change in the
`meta.license` field for all of the subpackages within
`pkgs/misc/arm-trusted-firmware/`, and results in them needing
`NIXPKGS_ALLOW_NONFREE=1`.

For non-Rockchip platforms the file hdcp.bin does not get included in
the output; the blob is for a Synopsys HDCP core that is currently
used only by Rockchip (although other companies could license it from
Synopsys in the future). Therefore on non-Rockchip we can delete
hdcp.bin before building instead of changing the license. This
preserves the ability to build them without NIXPKGS_ALLOW_NONFREE=1.

Let's do that.

Deleting hdcp.bin ensures that we won't be caught by surprise if some
future non-Rockchip Arm CPU licenses the same Synopsys HDCP core that
Rockchip is using.

Use easier-to-follow names for controlling the blob
inclusion/exclusion.  Also, if the blob is believed to be unnecessary,
delete it beforehand so we will know if we were wrong about that belief.

Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
(cherry picked from commit 8485bfc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant