Builds: https://copr.fedorainfracloud.org/coprs/g/centoshyperscale/gnome/builds/ Cheatsheets fedrq pkgs -A $(uname -m) -P 'pkgconfig(...)' -F sourcerpm Known issues c9s-build works in COPR for x86_64 but not aarch64 - https://github.com/fedora-copr/copr/issues/3235 from the fedora build system matrix it seems it affects some but not all aarch64 boxes so .. networking issues. It's always the network.

Reviewable https://fedoraproject.org/PackageReviewStatus/reviewable.html Review template Package was generated with rust2rpm, simplifying the review. package builds and installs without errors on rawhide test suite is run and all unit tests pass latest version of the crate is packaged license matches upstream specification (MIT OR Apache-2.0) and is acceptable for Fedora

Theme: Technology Innovation Theme: Editions, Spins, Interests Back in 2022, I introduced ebranch at CentOS Dojo - a tool to make branching Fedora packages to EPEL easier, by computing the transitive graph of missing dependencies and, later on, providing helper commands for tracking branch requests and escalating stalled requests. The original dependency resolution functionality was written specifically to handle comparing Fedora and EL + EPEL repositories, but there are other use cases that can be tackled by a more general tool - e.g. packaging new Rust crates (or upgrading existing ones) - as the rust-update-set proof of concept does - or tracking dependencies and dependent packages (as poi-tracker does). I'm now therefore working on a common dependency graph library that can support multiple repository formats - leveraging existing tools such as fedrq and cargo2rpm. Do come and provide your feedback if this is something you find useful.

Current status all packages are in Rawhide mailman3 is in EPEL 9 python-django3 is in EPEL 9 python-django4.2 planned web apps being branched Dep tree (hyperkitty) https://bugzilla.redhat.com/buglist.cgi?bug_id=2246242&bug_id_type=anddependson&format=tvp&list_id=13357095#

Introduction Whether you're a packager, system administrator, or a user of Fedora, CentOS Stream, or their derivatives (RHEL, AlmaLinux, Rocky Linux etc.), you might already be familiar with dnf repoquery. It allows querying the repositories configured on the system for information about packages available, whether or not they are currently installed on the local machine. This is great, within limits: for instance, on Fedora, you can query packages built for stable and branched Fedora releases, and, if you install fedora-repos-rawhide, packages in the development branch. Sufficient care must be used to make sure you don't, for instance, enable repos meant for different Fedora releases by default and thus accidentally upgrade the running system. Enter rpmdistro-repoquery: it comes with a set of repos for different RPM-based distributions, but instead of putting them in /etc/yum.repos.d with the repositories meant for actual use, put them in /usr/share/rpmdistro-repoquery (or, if you so choose, you can clone the repository and use definitions that come in the checkout). DNF is then invoked with a custom configuration file and a custom cache location that points at one of the repos for one of the distributions rather than the default location. The various distributions supported come with the relevant repositories enabled by default; some have additional repositories that need to be enabled explicitly (e.g. source repos are off by default; CentOS Stream configurations come with additional repos for SIG packages that are off by default). This opens up a lot of use cases; I highlight some of them below.