Fix merge issues from 3.0

Author: jslobodzian

.github/workflows/check-rendered-specs-stub.yml

@@ -1,25 +1,25 @@
 # Stub workflow — A copy of this workflow must live on the default branch (3.0) so that the
 # pull_request_target event can trigger it with access to GITHUB_TOKEN (pull-requests: write).
-# It delegates all real work to the reusable template on tomls/base/main.
+# It delegates all real work to the reusable template on 4.0.
 #
 # This two-stage design lets fork PRs trigger the check safely: the stub runs in the
 # context of the default branch (with write token), but the reusable workflow checks out
 # the PR's data files (TOML configs, specs) into a separate directory — never mixing
 # untrusted code with execution context.
 #
 # The stub must exist on the default branch because pull_request_target always runs
-# workflows from there. The reusable workflow on tomls/base/main has the actual scripts,
+# workflows from there. The reusable workflow on 4.0 has the actual scripts,
 # container setup, and rendering logic.
 name: Check Rendered Specs
 
 # pull_request_target gives us a GITHUB_TOKEN with pull-requests: write even for fork PRs.
 # The stub itself runs NO code from the PR — it only delegates to a trusted reusable
-# workflow pinned to tomls/base/main, which checks out PR data (not code) into an
+# workflow pinned to 4.0, which checks out PR data (not code) into an
 # isolated subdirectory.
 on: # zizmor: ignore[dangerous-triggers]
   pull_request_target:
     branches:
-      - tomls/base/main
+      - "4.0"
 
 permissions: {}
 
@@ -32,12 +32,13 @@ jobs:
     # Prevent forks from running a stale/vulnerable copy of this stub with Actions enabled
     if: github.repository == 'microsoft/azurelinux'
     # Intentionally branch-pinned so the reusable workflow picks up updates automatically.
-    uses: microsoft/azurelinux/.github/workflows/check-rendered-specs.yml@tomls/base/main # zizmor: ignore[unpinned-uses]
+    uses: microsoft/azurelinux/.github/workflows/check-rendered-specs.yml@4.0 # zizmor: ignore[unpinned-uses]
     permissions:
       contents: read
       pull-requests: write # Post/update/delete drift comments on PRs
     with:
       pr-head-sha: ${{ github.event.pull_request.head.sha }}
       pr-head-repo: ${{ github.event.pull_request.head.repo.full_name }}
+      pr-base-sha: ${{ github.event.pull_request.base.sha }}
       pr-number: ${{ github.event.pull_request.number }}
       repo: ${{ github.repository }}

.github/workflows/spec-review-stub.yml

@@ -1,6 +1,6 @@
 # Stub workflow — A copy of this workflow must live on the default branch (3.0) so that the pull_request_target
 # event can trigger it with access to secrets. It then delegates all real work to the reusable template on
-# tomls/base/main, which has the scripts, prompts, and agent definitions.
+# 4.0, which has the scripts, prompts, and agent definitions.
 #
 # This two-stage design lets fork PRs trigger the review safely: the stub runs in the
 # context of the default branch (with secret access), but the template checks out only
@@ -14,17 +14,17 @@ name: Spec Review
 
 # pull_request_target is required here: we need secret access (COPILOT_TOKEN) to run the
 # spec review agent on fork PRs. The stub itself runs NO code from the PR — it only
-# delegates to a trusted reusable workflow pinned to tomls/base/main, which sparse-checks
+# delegates to a trusted reusable workflow pinned to 4.0, which sparse-checks
 # out only .spec data files (never executable code) from the PR head.
 on: # zizmor: ignore[dangerous-triggers]
   pull_request_target:
     # Only trigger on PRs targeting the toml base branch which modify .spec files. We do
     # not want to affect PRs targeting other branches.
 
     branches:
-      - tomls/base/main
+      - "4.0"
     paths:
-      - '**/*.spec'
+      - "**/*.spec"
 
 permissions: {}
 
@@ -38,7 +38,7 @@ jobs:
     if: github.repository == 'microsoft/azurelinux'
     # Intentionally branch-pinned to our own repo so the
     # reusable workflow picks up prompt/script/agent updates automatically.
-    uses: microsoft/azurelinux/.github/workflows/spec-review.yml@tomls/base/main # zizmor: ignore[unpinned-uses]
+    uses: microsoft/azurelinux/.github/workflows/spec-review.yml@4.0 # zizmor: ignore[unpinned-uses]
     permissions:
       contents: read
       pull-requests: write # Post review comments and inline annotations on PRs
@@ -47,6 +47,6 @@ jobs:
       pr-head-repo: ${{ github.event.pull_request.head.repo.full_name }}
       pr-number: ${{ github.event.pull_request.number }}
       repo: ${{ github.repository }}
-      scripts-ref: tomls/base/main
+      scripts-ref: 4.0
     secrets:
       COPILOT_TOKEN: ${{ secrets.COPILOT_TOKEN }}

CONTRIBUTING.md

@@ -95,7 +95,7 @@ We welcome documentation improvements. See [toolkit/docs](toolkit/docs) for the
 
 ## Pull Request Guidelines
 
-Please direct pull requests to the desired development branch. Development changes to `3.0` should target `3.0-dev`. Development changes to `2.0` should target `main`. `1.0` is deprecated and should not be used.
+Please direct pull requests to the desired development branch. Development changes to `3.0` should target `3.0-dev`. `2.0` and `1.0` are deprecated and should not be used.
 
 ### Branch structure
 
@@ -108,13 +108,6 @@ An overview of how the branches are structured can be seen below
 |3.0-preview   |Tag           |No       |No         | Publishing in progress
 |3.0-stable    |Tag           |No       |Yes        | Last published release
 
-| Git Ref      | Branch / Tag | For PRs | Published | Notes
-|:-------------|:-------------|:--------|:----------|:------------
-|main          |Branch        |Yes      |No         | **Primary development branch**
-|2.0           |Branch        |No       |Yes - eventually | Staging branch for publishing
-|2.0-preview   |Tag           |No       |No         | Publishing in progress
-|2.0-stable    |Tag           |No       |Yes        | Last published release
-
 ### PR Titles
 
 PR titles should start with an action
@@ -134,7 +127,7 @@ Please avoid titles such as
 ```bash
 - package: <whatever you did to the package>
 - CVE-XXXX-YYYY (leaving off what package was patched or upgraded)
-- [2.0] (prefixing with branch or other information)
+- [3.0] (prefixing with branch or other information)
 ```
 
 ### PR Checklist

README-3.0.md

@@ -0,0 +1,55 @@
+# Azure Linux 3.0
+
+Azure Linux 3.0 is an internal Linux distribution for Microsoft’s cloud infrastructure and edge products and services. Azure Linux is designed to provide a consistent platform for these devices and services and will enhance Microsoft’s ability to stay current on Linux updates. This initiative is part of Microsoft’s increasing investment in a wide range of Linux technologies, such as [SONiC](https://azure.microsoft.com/en-us/blog/sonic-the-networking-switch-software-that-powers-the-microsoft-global-cloud/) and [Windows Subsystem for Linux (WSL)](https://docs.microsoft.com/en-us/windows/wsl/about). Azure Linux is being shared publicly as part of Microsoft’s commitment to Open Source and to contribute back to the Linux community. Azure Linux does not change our approach or commitment to any existing third-party Linux distribution offerings.
+
+Azure Linux has been engineered with the notion that a small common core set of packages can address the universal needs of first party cloud and edge services while allowing individual teams to layer additional packages on top of the common core to produce images for their workloads. This is made possible by a simple build system that enables:
+
+- **Package Generation:** This produces the desired set of RPM packages from SPEC files and source files.
+- **Image Generation:** This produces the desired image artifacts like ISOs or VHDs from a given set of packages.
+
+Whether deployed as a container or a container host, Azure Linux consumes limited disk and memory resources. The lightweight characteristics of Azure Linux also provides faster boot times and a minimal attack surface. By focusing the features in the core image to just what is needed for our internal cloud customers there are fewer services to load, and fewer attack vectors.
+
+When security vulnerabilities arise, Azure Linux supports both a package-based update model and an image based update model.  Leveraging the common [RPM Package Manager](https://rpm.org/) system, Azure Linux makes the latest security patches and fixes available for download with the goal of fast turn-around times.
+
+### Build
+
+Instructions for building Azure Linux 3.0 may be found here: [Toolkit Documentation](./toolkit/README.md).
+
+### ISO
+
+To try Azure Linux Download the ISO here: [Azure Linux 3.0 x86_64 ISO](https://aka.ms/azurelinux-3.0-x86_64.iso) / [Azure Linux 3.0 aarch64 ISO](https://aka.ms/azurelinux-3.0-aarch64.iso)
+
+Before using a downloaded ISO, [verify the checksum and signature of the image](toolkit/docs/security/iso-image-verification.md).
+
+After downloading the ISO, use [the quickstart instructions](toolkit/docs/quick_start/quickstart.md) to install and use the image in a Hyper-V VM.
+
+Note: Support for the ISO is community based. Before filing a new bug or feature request, please search the list of Github Issues. If you are unable to find a matching issue, please report new bugs by clicking [here](https://github.com/microsoft/azurelinux/issues) or create a new feature request by clicking [here](https://github.com/microsoft/azurelinux/issues/new). For additional information refer to the [support.md](https://github.com/microsoft/azurelinux/blob/3.0/SUPPORT.md) file.
+
+
+## Getting Help
+- Bugs, feature requests and questions can be filed as GitHub issues.
+- We are starting a public community call for Azure Linux users to get together and discuss new features, provide feedback, and learn more about how others are using Azure Linux. In each session, we will feature a new demo. The schedule for the upcoming community calls are:
+- 5/28/2026 from 8-9am (PST) [Click to join](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDcyZjRkYWMtOWQxYS00OTk3LWFhNmMtMTMwY2VhMTA4OTZi%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2271a6ce92-58a5-4ea0-96f4-bd4a0401370a%22%7d)
+- 7/23/2026 from 8-9am (PST) [Click to join](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDcyZjRkYWMtOWQxYS00OTk3LWFhNmMtMTMwY2VhMTA4OTZi%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2271a6ce92-58a5-4ea0-96f4-bd4a0401370a%22%7d)
+- 9/24/2026 from 8-9am (PST) [Click to join](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDcyZjRkYWMtOWQxYS00OTk3LWFhNmMtMTMwY2VhMTA4OTZi%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2271a6ce92-58a5-4ea0-96f4-bd4a0401370a%22%7d)
+- 11/19/2026 from 8-9am (PST) [Click to join](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDcyZjRkYWMtOWQxYS00OTk3LWFhNmMtMTMwY2VhMTA4OTZi%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2271a6ce92-58a5-4ea0-96f4-bd4a0401370a%22%7d)
+- 1/28/2027 from 8-9am (PST) [Click to join](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDcyZjRkYWMtOWQxYS00OTk3LWFhNmMtMTMwY2VhMTA4OTZi%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2271a6ce92-58a5-4ea0-96f4-bd4a0401370a%22%7d)
+- 3/25/2027 from 8-9am (PST) [Click to join](https://teams.microsoft.com/l/meetup-join/19%3ameeting_ZDcyZjRkYWMtOWQxYS00OTk3LWFhNmMtMTMwY2VhMTA4OTZi%40thread.v2/0?context=%7b%22Tid%22%3a%2272f988bf-86f1-41af-91ab-2d7cd011db47%22%2c%22Oid%22%3a%2271a6ce92-58a5-4ea0-96f4-bd4a0401370a%22%7d)
+
+## Trademarks
+
+This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow [Microsoft's Trademark & Brand Guidelines](https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks/usage/general). Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.
+
+## Acknowledgments
+
+Any Linux distribution, including Azure Linux, benefits from contributions by the open software community. We gratefully acknowledge all contributions made from the broader open source community, in particular:
+
+1) [GNU](https://www.gnu.org/) and the [Free Software Foundation](https://www.fsf.org/)
+
+2) [The Fedora Project](https://start.fedoraproject.org/) for SPEC files, particularly with respect to Qt, DNF and content in the SPECS-EXTENDED folder.
+
+3) The [Photon OS Project](https://vmware.github.io/photon/) for SPEC files originating from the Photon distribution.
+
+4) [Linux from Scratch](http://www.linuxfromscratch.org)
+
+5) And other open source projects as referenced [here](LICENSES-AND-NOTICES/SPECS/LICENSES-MAP.md)