Repository navigation
azure-cli not available in MSFT Fedora 44 repo #34131
Description
Activity
Thank you for opening this issue, we will look into it.
Reacted by Charles FlandersBug Analysis
Assessment: Sufficient reproduction information for an RPM distribution/build investigation. This is a package-availability problem before Azure CLI execution, not a failure in an Azure service command.
Target:Azure/azure-cli, base branchdev, repository-level RPM packaging/release engineering. Repository-aware inference returnedunknown(no command module or extension), so retain the issue here; no extension tracker is appropriate.
Use this EXACT PR title:[Packaging] Fix #34131:az --version: Enable Fedora 44 RPM build and validationReported reproduction and expected behavior
- Platform/context: Fedora 44 with Microsoft's production yum repository configured. The reporter says Fedora's downstream
azure-clipackage is outdated. - Exact package lookup supplied:
sudo dnf info azure-cli. Related CLI command supplied:az --version; it is the eventual installation smoke check, not an observed crashing command. - Actual behavior: the reporter cannot find an
azure-clipackage in Microsoft's Fedora 44 production feed. No error message or stack trace was reported. This report does not establish thatdnf infocannot find a Fedora-maintained package from another enabled repository. - Expected behavior: an up-to-date Microsoft-published
azure-cliRPM is discoverable/installable from the configured Fedora 44 feed. - A CLI version is not necessary to investigate a package absent before installation. Fedora 44 plus the repository context and exact lookup provide the relevant reproduction context. Feed contents have not been independently verified here, and no local command, test, build, or release was run.
Current source evidence
Inspected
devat9a3432d5ce7ebcbc5473b994897ab16ae998878b:azure-pipelines.yml, RPM build matrix builds UBI 8/9/10 RPMs for the configured architectures; there is no Fedora entry. The matching installation-test matrix similarly covers those UBI artifacts, not Fedora 44. Azure Linux has separate jobs; preserve them.scripts/release/rpm/fedora.dockerfileexists but defaults to Fedora 35, uses the configurablepython_packagewithPYTHON_CMD=python3, and smoke-tests only installation of a locally built RPM plusaz --version. Its existence does not establish Fedora 44 support or feed publication.scripts/release/rpm/pipeline.shaccepts the Dockerfile, image and Python package, builds the RPM and copies it into staging.PublishPipelineArtifactin the YAML publishes an Azure Pipelines artifact, not a package into a Microsoft production feed.scripts/release/rpm/azure-cli.specderives its Python runtime/build dependencies from the supplied Python package/command; its installation section builds a venv and the launcher. Fedora's real Python/package layout must be validated rather than copying UBI'spython3.12assumptions.test_rpm_in_docker.shinstalls a local RPM and runs the existing package checks.verify_rpm_in_docker.shinstead checks a hard-coded generic Azure CLI yum repository, so neither currently verifies Fedora 44 feed availability. The RPM README also retains Fedora 29 examples.
Diagnosis and ownership boundary: The inspected source confirms a missing Fedora 44 build/test path and a gap in Fedora-specific repository verification. It does not prove where Microsoft production signing/publication is configured, whether Fedora 44 is an approved release destination, or that changing a Dockerfile alone would populate that feed. Treat publication/support approval as a release-owner dependency, not as an already-verified code defect or an authorization to change a production service.
Proposed focused fix for the durable implementation job
- Trace the existing, trusted RPM release configuration to identify the approved Fedora 44 signing/publication destination and owning release process. Do not infer a writable destination or permission from the issue's URL. If that configuration/approval is external or unavailable, report the concrete release-owner dependency and stop before claiming the availability bug is fixed; do not manufacture a publisher, credentials, a new service endpoint, or an unsupported RHEL/CentOS workaround.
- Within that approved release path, add a matching Fedora 44 build/install-test entry to the existing RPM pipeline using
fedora.dockerfile, a verified Fedora 44 image/Python combination, architecture-specific artifact naming, and the Fedora RPM distro suffix. Keep build/test artifact names aligned and retain existing UBI/Azure Linux behavior and existing pipeline trigger conditions. Adjust only Fedora-specific Dockerfile/spec compatibility proven necessary; preserve build-argument overrides. - Connect the resulting Fedora artifact to the existing approved publication mapping where that mapping is repository-owned. Distinguish artifact creation, signed publication, and post-publication verification. A new matrix entry or README change alone is not acceptance of the reported missing-package fix. No release/publish workflow or production repository mutation is authorized during implementation validation.
- Extend the existing RPM repository-verification path narrowly so a maintainer-controlled Fedora 44 scenario checks the selected feed's package origin and requested release version, rather than accidentally passing on Fedora's older downstream package, a preinstalled CLI, or a different enabled feed. Preserve GPG/signature verification for repository installs; do not carry unsigned-local-artifact test options into production-feed validation.
- Update the existing RPM README's affected Fedora examples and clearly distinguish local build capability from actual Microsoft feed publication/support. Keep changes scoped to RPM packaging, its pipeline integration, relevant existing documentation and focused coverage; no unrelated CLI command changes.
Regression/scenario coverage required in the job
- Validate the paired Fedora 44 build/test configuration, architecture and distro-suffix artifact selection, and consistent Python package/executable/pip settings using the repository's existing validation mechanisms.
- In an isolated Fedora 44 environment, exercise the existing local RPM installation/package checks and
az --version(plus the existingaz self-testcheck); verify the built CLI version and runtime dependencies. Validate with existing RPM tools/tests, not a newly invented test framework. - Describe and cover repository-verification success for the intended version/origin and failure for a missing package, an older version, or a package available only in an unrelated/downstream feed. Local artifact installation is not evidence that the public feed is populated.
- Preserve and check existing UBI RPM scenarios and Azure Linux configuration; ensure defaults remain backward-compatible for existing callers. Document the Fedora repository acceptance scenario for the release owner to run after approved publication; do not start or wait for a release from this job.
- Record the actual validation results or precise blockers. This triage has not run any of these tests.
Source-generation classification and execution boundaries
The evidenced files are handwritten packaging scripts, a Dockerfile/spec and pipeline YAML, not AAZ-generated command output. No command model or generated module edit is proposed. The deterministic Codegen protocol below applies if investigation genuinely crosses that boundary; it is not a request to create/regenerate an unrelated
packagingcommand module. Never hand-editaaz/<profile>/output. If generated behavior is implicated, change its owned durable input and use the approved regeneration workflow, or stop with a blocker.Implementation is delegated only to the durable Foundry job through the compatibility dispatch helper and trusted publication. Do not independently assign a bot, start hosted Agent Tasks, post an execution mention, use another provider, or invoke a retired fork-promotion flow.
Mandatory Codegen execution protocol
Before editing implementation files, determine whether the affected
packagingcommand is AAZ-generated. Files underaaz/<profile>/are generated output and must never be patched directly, including by an AI agent. Check outAzure/aazbesideAzure/azure-rest-api-specs,Azure/aaz-dev-tools, and the downstream repository. API-schema defects start in the specification; command naming, grouping, arguments, API-version selection, help, and examples belong in the durableAzure/aazcommand model; non-modelable client behavior belongs in a handwritten subclass or wrapper incustom.py, registered fromcommands.py. X Engineering Agent creates and promotes the corresponding durableAzure/aazsource pull request before it promotes downstream generated output.Follow the Azure CLI repository's Codegen workflow and the aaz-dev setup documentation. Set up the checked-out repositories with
azdev setup. Usegenerateonly when importing or redesigning command models from Swagger/TypeSpec. For an existing module whose durableAzure/aazmodel has been updated, render that model withregenerate:aaz-dev cli regenerate --name packaging --cli-path <azure-cli> # New/imported command model only: aaz-dev cli generate --spec <specification-name> --module packaging
You MUST actually run the generator; do not merely describe it or imitate its output. If the AAZ/specification checkout, local source change, credentials, or generator is unavailable, stop and report the blocker instead of editing generated files. Inspect
_aaz_infoprovenance and the complete regenerated diff, then run focusedazdev style,azdev linter, andazdev testvalidation. For an extension, also update its version andHISTORY.rst, preserveazext_metadata.jsoncompatibility, and let release automation updatesrc/index.json.PR title & description format (required)
This repo enforces a PR format (guide). Please author the PR exactly as follows or CI's Check the Format of Pull Request Title and Content will fail.
Use this EXACT PR title (copy verbatim, do not reword):
[Packaging] Fix #34131: `az --version`: Enable Fedora 44 RPM build and validationKeep the backticks around the command and the
Fix #34131:prefix. You may only adjust the wording after the command (the final summary) if the fix changes; the[Packaging]prefix, issue link, and backticked command must stay.Description — follow the PR template and fill in:
- Link the issue — start the Description with a closing keyword so the PR auto-links and closes it:
Fixes #34131. - Related command — the
az ...command this affects. - Description (mandatory) — why the bug happens, what you changed, and the resulting behavior.
- Testing Guide — example command(s) showing the fix works.
- History Notes — leave the title to drive the history note, or add extra lines in the same format (component in brackets + the command in backticks), e.g.
[Packaging] `az <command>`: <note>. - Keep the template checklist and tick the items you've satisfied.
- Platform/context: Fedora 44 with Microsoft's production yum repository configured. The reporter says Fedora's downstream
Describe the bug
When adding the
packages.microsoft.comrepo to Fedora, azure-cli is not available for installation. The version currently packaged in Fedora 44's downstream repo is out of date.Related command
az --versionsudo dnf info azure-cliErrors
No error message. Package does not exist at https://packages.microsoft.com/fedora/44/prod/Packages/a/
Issue script & Debug output
n/a
Expected behavior
that an up to date
azure-clipackage would exist in the provided Fedora repo.Environment Summary
Fedora 44 with MSFT Prod yum repo added
Additional context
I don't know if this was the right place to open an issue. None of the documentation mentions anything about using the RHEL or CentOS repos instead, and given a Fedora repo does exist, it makes sense that CI release workflows could technically populate it as well, which would be less confusing.