Starlark good first issues

This issue describes a problem where Bazel's path mapping for hermetic C++ toolchains is not correctly applied to arguments passed to `rustc`. Specifically, the C++ linker path and sysroot paths are passed as analysis-time strings, which Bazel cannot rewrite. This leads to Rust linking failures when the toolchain is a Bazel artifact, as the sandbox environment uses a different path layout.

When building Rust binaries on Windows with the MSVC toolchain using rules_rust, the `windows_subsystem = "windows"` attribute is being overridden, resulting in console executables instead of GUI executables. This appears to be caused by rules_cc forwarding a console subsystem flag that rules_rust then incorrectly applies, despite Rust's own subsystem selection.

This issue requests the addition of a GitHub Actions workflow to install QEMU version 10.1.0 on GitHub runners. The current default QEMU version (8.0) lacks support for the Raspberry Pi 4 machine type, which is needed for testing. The workflow should ensure the correct QEMU version is installed and validated.

This issue describes a bug in `crate_universe` where Bazel aliases for patched Rust crates are generated incorrectly. Instead of pointing to the local patched path, the aliases point to the default vendored location, causing build failures. The root cause is suspected to be in the `crate_label` function, which doesn't account for local path overrides when constructing labels.

This issue requires a comprehensive audit of all repositories within the S-Core organization to identify those using Rust. For each identified Rust project, the task involves extracting its dependencies from Cargo.toml/Cargo.lock and compiling this information into a centralized report, detailing repository name, project path, and a list of used crates with versions.

This issue describes a problem where shared libraries for packages like libblas3 and liblapack3 are installed in a subdirectory and then symlinked via `update-alternatives` during post-installation. This post-installation step is not being executed in the user's build environment, causing binaries like `ogr2ogr` to fail because they cannot find the required `libblas.so.3` file. The user is proposing a workaround using symlinks.

This feature request aims to allow `rules_distroless` to support partial installations by reusing existing package information from a base image's `dpkg` status. This would enable users to build upon existing base images with pre-installed packages, rather than always starting from scratch, improving efficiency and reducing image bloat. Two options are proposed: explicitly excluding packages or automatically deriving installed packages by inspecting base image layers.

This issue reports a bug in rules_python where generated `py_library` targets exclude `.pyc` files from installed packages. This prevents importing modules that rely on these compiled bytecode files, contrary to Python's expected behavior. The user found a workaround by manually removing the `.pyc` exclusion from the generated `py_library` rule.

The documentation for the `py_wheel`'s `description_file` attribute incorrectly states it should be a single line, contradicting Python packaging specifications. The issue requests updating this documentation, adding a new `summary` attribute for a one-line description, and a `description_content_type` attribute to align with PyPA standards.

The user is reporting that code coverage reports are only generated for Scala files when their directory structure has a specific depth relative to the BUILD file. Files are excluded from coverage results if they are nested too deeply or if the BUILD file is not at the root. This issue appears to be specific to code coverage and not other build/test operations.

This issue reports a bug where packages locked from a Git source in a `uv.lock` file are not correctly handled by `pip.parse`. The problem arises because the URL in the lock file, which includes Git parameters like `rev`, is being treated as a literal download URL, leading to fetch and validation errors.

This issue requests an update to the `py_wheel` rule to support PEP 639 license metadata. This involves adding support for SPDX license expressions and license files, which are crucial for auditable license metadata in redistributed wheels. The proposed solution includes new attributes for `license_expression` and `license_files`, and a backward-compatible update to the metadata version.

This issue requests adding support for `uv_lock` as an attribute to the `gazelle_python_manifest` rule. The goal is to allow users to fully replace `requirements.lock.txt` files with `uv_lock` files, simplifying dependency management within the Gazelle plugin.

The `pip.parse` function in `uv_lock` fails when parsing lock files containing Git-sourced packages with a revision hash. This is because the generated repository name includes a '?' character, which is invalid for Bazel repository names.

This issue describes a bug where rules_distroless fails to decompress xz package indices on macOS because it relies on the `xz` command, which is not natively available. The native macOS decompression method for xz files is `gzip -d`, and the issue suggests either automatically using this or at least documenting the `xz` dependency.

The `build_test` macro in bazel-skylib uses an internal rule named `_empty_test`, which is not descriptive when filtering targets. The issue proposes renaming this internal rule to `skylib_build_test` for better clarity and user experience.

The `pip_parse` tool in Bazel's `rules_python` is failing to generate PyPI package definitions for Windows ARM64. This results in an empty `@pypi` repository, causing build failures for projects like TensorFlow that rely on these dependencies. The issue appears to stem from `pip_parse` not correctly identifying or mapping the `windows_aarch64` platform.

Several documentation files are missing required 'includes' links, causing build warnings in the latest docs-as-code main branch. These errors require domain knowledge to resolve and need to be fixed by relevant stakeholders before the next release.

This issue reports an excessive number of warnings generated by the coverage wheel when certain toolchains are not present. The warnings indicate that the bundled coverage tool for rules_python lacks a wheel for a specific Python version and platform, leading to empty lcov files for py_test targets. The user suggests either pinning the Python version or manually configuring the coverage tool.

This feature request aims to enhance the `pip_parse` Bazel rule by adding a new attribute, such as `extra_files`, to allow users to pass additional files like SSL certificates or pip configuration files. This would provide a more integrated Bazel-native approach compared to using environment variables.

This feature request aims to extend the `pip.dep` functionality in `rules_python` to support concrete dependency management directly within `MODULE.bazel` files. Currently, `pip.dep` is only used for abstract dependencies, requiring concrete versions to be specified via `pip.parse` and `requirements.txt`. The proposed solution would allow users to define all dependency version requirements solely within `MODULE.bazel`, similar to the `crate_universe` feature in `rules_rust`.