Fedora Account System
Red Hat Associate
Red Hat Customer
Spec URL: https://pnemade.fedorapeople.org/rust-font-types.spec SRPM URL: https://pnemade.fedorapeople.org/rust-font-types-0.11.1-1.fc44.src.rpm Upstream URL: https://crates.io/crates/font-types Description: Scalar types used in fonts. Fedora Account System Username: pnemade
This package built on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=143891202
It looks like you modified the output of rust2rpm by removing the lines marking LICENSE-APACHE and LICENSE-MIT as license files, and README.md as documentation. --- c/rust-font-types.spec 2026-03-31 22:42:23.191868272 +0100 +++ srpm-unpacked/rust-font-types.spec 2026-03-31 01:00:00.000000000 +0100 @@ -30,9 +30,6 @@ use the "%{crate}" crate. %files devel -%license %{crate_instdir}/LICENSE-APACHE -%license %{crate_instdir}/LICENSE-MIT -%doc %{crate_instdir}/README.md %{crate_instdir}/ %package -n %{name}+default-devel Why? If it is because fedora-review gives a finding about “Package does not contain duplicates in %files.” otherwise, this is not a serious problem, and this diagnostic is reported for every rust2rpm-packaged submission. This just means the files were matched in the files list more than one way, not that there are duplicate packaged copies of the files, and this due to reasonable design decisions in rust2rpm. Removing these lines means that license and documentation files are not correctly marked as such, which *is* a real defect, e.g. https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text.
Thank you for this initial review. Yes I am new to rust packaging and I followed the findings from fedora-review tool. I have added back License files with same SPEC and SRPM URL. Kindly check again and review this package.
Copr build: https://copr.fedorainfracloud.org/coprs/build/10280931 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2453339-rust-font-types/fedora-rawhide-x86_64/10280931-rust-font-types/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
No issues found; the package is APPROVED. It’s neat to see Rust-based font tooling starting to show up. Happy to help with any issues you might encounter, or you can ask questions in the Fedora Rust room on Matrix. === Recommended post-import rust-sig tasks: - set up package on release-monitoring.org: project: $crate homepage: https://crates.io/crates/$crate backend: crates.io version scheme: semantic version filter (*NOT* pre-release filter): alpha;beta;rc;pre distro: Fedora Package: rust-$crate - add @rust-sig with "commit" access as package co-maintainer (should happen automatically) - set bugzilla assignee overrides to @rust-sig (optional) - track package in koschei for all built branches (should happen automatically once rust-sig is co-maintainer) === Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated The spec file is exactly as generated by rust2rpm, greatly simplifying the review. Issues: ======= - Package does not contain duplicates in %files. Note: warning: File listed twice: /usr/share/cargo/registry/font- types-0.11.1/LICENSE-APACHE See: https://docs.fedoraproject.org/en-US/packaging- guidelines/#_duplicate_files OK: not a serious problem; due to reasonable rust2rpm design decisions. ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "Apache License 2.0", "MIT License". 20 files have unknown license. Detailed output of licensecheck in /home/ben/fedora/review/2453339-rust-font-types/licensecheck.txt [x]: License file installed when any subpackage combination is installed. [-]: If the package is under multiple licenses, the licensing breakdown must be documented in the spec. [x]: %build honors applicable compiler flags or justifies otherwise. [x]: Package contains no bundled libraries or specifies bundled libraries with Provides: bundled(<libname>) if unbundling is not possible. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [x]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Package is not known to require an ExcludeArch tag. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: No rpmlint messages. [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: The License field must be a valid SPDX expression. [x]: Package requires other packages for directories it uses. [x]: Package must own all directories that it creates. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Permissions on files are set properly. [x]: Package must not depend on deprecated() packages. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 0 bytes in 0 files. [x]: Packages must not store files under /srv, /opt or /usr/local ===== SHOULD items ===== Generic: [-]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [-]: Fully versioned dependency in subpackages if applicable. Note: No Requires: %{name}%{?_isa} = %{version}-%{release} in rust- font-types-devel , rust-font-types+default-devel , rust-font- types+bytemuck-devel , rust-font-types+serde-devel , rust-font- types+std-devel [x]: Package functions as described. (tests pass) [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [x]: Package should compile and build into binary rpms on all supported architectures. https://koji.fedoraproject.org/koji/taskinfo?taskID=143891202 [x]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: No rpmlint messages. [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: rust-font-types-devel-0.11.1-1.fc45.noarch.rpm rust-font-types+default-devel-0.11.1-1.fc45.noarch.rpm rust-font-types+bytemuck-devel-0.11.1-1.fc45.noarch.rpm rust-font-types+serde-devel-0.11.1-1.fc45.noarch.rpm rust-font-types+std-devel-0.11.1-1.fc45.noarch.rpm rust-font-types-0.11.1-1.fc45.src.rpm ============================ rpmlint session starts ============================ rpmlint: 2.8.0 configuration: /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml rpmlintrc: [PosixPath('/tmp/tmpjnn0ec7k')] checks: 32, packages: 6 6 packages and 0 specfiles checked; 0 errors, 0 warnings, 31 filtered, 0 badness; has taken 0.2 s Rpmlint (installed packages) ---------------------------- ============================ rpmlint session starts ============================ rpmlint: 2.9.0 configuration: /usr/lib/python3.14/site-packages/rpmlint/configdefaults.toml /etc/xdg/rpmlint/fedora-spdx-licenses.toml /etc/xdg/rpmlint/fedora.toml /etc/xdg/rpmlint/scoring.toml /etc/xdg/rpmlint/users-groups.toml /etc/xdg/rpmlint/warn-on-functions.toml checks: 32, packages: 5 5 packages and 0 specfiles checked; 0 errors, 0 warnings, 27 filtered, 0 badness; has taken 0.0 s Source checksums ---------------- https://crates.io/api/v1/crates/font-types/0.11.1/download#/font-types-0.11.1.crate : CHECKSUM(SHA256) this package : 73829a7b5c91198af28a99159b7ae4afbb252fb906159ff7f189f3a2ceaa3df2 CHECKSUM(SHA256) upstream package : 73829a7b5c91198af28a99159b7ae4afbb252fb906159ff7f189f3a2ceaa3df2 Requires -------- rust-font-types-devel (rpmlib, GLIBC filtered): cargo rust rust-font-types+default-devel (rpmlib, GLIBC filtered): cargo crate(font-types) rust-font-types+bytemuck-devel (rpmlib, GLIBC filtered): (crate(bytemuck/default) >= 1.13.1 with crate(bytemuck/default) < 2.0.0~) (crate(bytemuck/derive) >= 1.13.1 with crate(bytemuck/derive) < 2.0.0~) (crate(bytemuck/min_const_generics) >= 1.13.1 with crate(bytemuck/min_const_generics) < 2.0.0~) cargo crate(font-types) rust-font-types+serde-devel (rpmlib, GLIBC filtered): (crate(serde/default) >= 1.0.0 with crate(serde/default) < 2.0.0~) (crate(serde/derive) >= 1.0.0 with crate(serde/derive) < 2.0.0~) cargo crate(font-types) rust-font-types+std-devel (rpmlib, GLIBC filtered): cargo crate(font-types) Provides -------- rust-font-types-devel: crate(font-types) rust-font-types-devel rust-font-types+default-devel: crate(font-types/default) rust-font-types+default-devel rust-font-types+bytemuck-devel: crate(font-types/bytemuck) rust-font-types+bytemuck-devel rust-font-types+serde-devel: crate(font-types/serde) rust-font-types+serde-devel rust-font-types+std-devel: crate(font-types/std) rust-font-types+std-devel Generated by fedora-review 0.11.0 (05c5b26) last change: 2025-11-29 Command line :/usr/bin/fedora-review -b 2453339 Buildroot used: fedora-rawhide-x86_64 Active plugins: Shell-api, Generic Disabled plugins: Ocaml, R, PHP, fonts, Java, Perl, Python, SugarActivity, C/C++, Haskell Disabled flags: EXARCH, EPEL6, EPEL7, DISTTAG, BATCH
The Pagure repository was created at https://src.fedoraproject.org/rpms/rust-font-types
FEDORA-2026-6f8429a6ec (rust-font-types-0.11.1-1.fc45) has been submitted as an update to Fedora 45. https://bodhi.fedoraproject.org/updates/FEDORA-2026-6f8429a6ec
FEDORA-2026-6f8429a6ec (rust-font-types-0.11.1-1.fc45) has been pushed to the Fedora 45 stable repository. If problem still persists, please make note of it in this bug report.
Thank you for the quick review help.
Parag, are you still working on a project that would need these Rust crate libraries (font-types and font-test-data), and is there anything you need help or advice with? As you probably know, RPM-packaged Rust crate libraries in Fedora are source-only packages that are (for various reasons) really only useful for building packaged applications (and shared libraries, and other binaries) that use them, not for end users doing Rust development. There is no rule against maintaining Rust library packages for their own sake, but it’s generally not useful work unless you’re building toward using them to build a binary. I know that there are several other crates developed in https://github.com/googlefonts/fontations, and some of them are dependencies for interesting things, but I’m not sure exactly what your end goal is. Again, let me know if you’re having trouble with anything and I’m happy to answer questions or take a look. I’d also like to mention that the commit messages on these packages look a bit unusual, e.g. https://src.fedoraproject.org/rpms/rust-font-types/commits/rawhide. Almost every commit has the message “local build,” which isn’t meaningful or particuarly accurate, and with rpmautospec/%autochangelog these “local build” entries also make it into the RPM changelog. If this indicates that you’re using some kind of scripting or automation to manage these packages, it seems like it could use improvement and/or more thorough human review. It’s also worth mentioning that groups of Rust crates maintained together like this may have dependencies on particular patch releases of each other, and that upgrades across SemVer boundaries (e.g. 0.11.x→0.12.x) are incompatible and need to be coordinated with reverse dependencies, either by updating and/or patching everything together or (when that isn’t possible) by introducing compat packages. In either case, these kinds of coordinated updates are best done in side tags, https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guide/#multiple_packages. We *do* have permanent exceptions to the Updates Policy for incompatible Rust library updates in Fedora stable branches and EPEL leading branches, so these kinds of updates are fine, they just need to be coordinated. Finally, we have a practice in the Rust SIG of trying to keep versions of Rust library crates aligned across all Fedora branches, which is possible because of the Updates-Policy exception mentioned above and justified by the fact that these packages aren’t targeted at end users, so as long as they are coordinated with the application packages that use them, nothing is broken from a user perspective. So when we update a crate in Rawhide, we try to update it everywhere else as well unless there is some concrete reason not to. This simplifies crate library maintenance across Fedora because we mostly don’t have to deal with a unique set of dependency issues for each branch. For analyzing Rust dependency relationships, you can use the script “cratedeps,” which is (after a long period of incubation) now included with rust2rpm. Please let me know if anything here is unclear, or if you are having any particular difficulties with your Rust+font packaging goals.
(In reply to Ben Beasley from comment #10) > Parag, are you still working on a project that would need these Rust crate > libraries (font-types and font-test-data), and is there anything you need > help or advice with? I believe I have done the needed thing from my side and if anything is still remaining then I need help for https://bugzilla.redhat.com/show_bug.cgi?id=2455091 > > As you probably know, RPM-packaged Rust crate libraries in Fedora are > source-only packages that are (for various reasons) really only useful for > building packaged applications (and shared libraries, and other binaries) > that use them, not for end users doing Rust development. There is no rule > against maintaining Rust library packages for their own sake, but it’s > generally not useful work unless you’re building toward using them to build > a binary. I know that there are several other crates developed in > https://github.com/googlefonts/fontations, and some of them are dependencies > for interesting things, but I’m not sure exactly what your end goal is. > Again, let me know if you’re having trouble with anything and I’m happy to > answer questions or take a look. I really don't know who will need https://github.com/harfbuzz/harfrust in future but my aim was to add this tool in Fedora which got stuck with package review of rust-read-fonts > > I’d also like to mention that the commit messages on these packages look a > bit unusual, e.g. > https://src.fedoraproject.org/rpms/rust-font-types/commits/rawhide. Almost > every commit has the message “local build,” which isn’t meaningful or > particuarly accurate, and with rpmautospec/%autochangelog these “local > build” entries also make it into the RPM changelog. If this indicates that > you’re using some kind of scripting or automation to manage these packages, > it seems like it could use improvement and/or more thorough human review. Yes I used bugzilla commands and some other commands to auto update packages. I never liked rpmautospec, hence never thought to update my scripts for rpmautospec. I like more verbose way of adding Changelog in SPEC file itself. > > It’s also worth mentioning that groups of Rust crates maintained together > like this may have dependencies on particular patch releases of each other, > and that upgrades across SemVer boundaries (e.g. 0.11.x→0.12.x) are > incompatible and need to be coordinated with reverse dependencies, either by > updating and/or patching everything together or (when that isn’t possible) > by introducing compat packages. In either case, these kinds of coordinated > updates are best done in side tags, > https://docs.fedoraproject.org/en-US/package-maintainers/ > Package_Update_Guide/#multiple_packages. We *do* have permanent exceptions > to the Updates Policy for incompatible Rust library updates in Fedora stable > branches and EPEL leading branches, so these kinds of updates are fine, they > just need to be coordinated. Sorry but I did not understand this. Probably can you give any specific example to understand this better? I know about packages which need compat package when doing soname bump. > > Finally, we have a practice in the Rust SIG of trying to keep versions of > Rust library crates aligned across all Fedora branches, which is possible > because of the Updates-Policy exception mentioned above and justified by the > fact that these packages aren’t targeted at end users, so as long as they > are coordinated with the application packages that use them, nothing is > broken from a user perspective. So when we update a crate in Rawhide, we try > to update it everywhere else as well unless there is some concrete reason > not to. This simplifies crate library maintenance across Fedora because we > mostly don’t have to deal with a unique set of dependency issues for each > branch. > I will henceforth will update the updated rawhide packages in older stable releases as well. > For analyzing Rust dependency relationships, you can use the script > “cratedeps,” which is (after a long period of incubation) now included with > rust2rpm. Thank you for letting me know about this script. > > Please let me know if anything here is unclear, or if you are having any > particular difficulties with your Rust+font packaging goals. Thank you very much for your detailed feedback here.
(In reply to Parag Nemade from comment #11) > I believe I have done the needed thing from my side and if anything is still > remaining then I need help for > https://bugzilla.redhat.com/show_bug.cgi?id=2455091 It looks like that review still needs something done about the Adobe Glyph List license: > - The new agl feature (“Support for mapping glyph names <-> unicode via the > Adobe glyph list”) relies on “code” (really, just a data table in Rust source > form, data/generated/generated_agl.rs) generated from data/glyphlist.txt, the > “Adobe Glyph List,” which is licensed BSD-3-Clause. This would seem to > require the license expression in Cargo.toml to be patched from “MIT OR > Apache-2.0” to “(MIT OR Apache-2.0) AND BSD-3-Clause”. > > I suggested this change upstream in > https://github.com/googlefonts/fontations/pull/1859. I think you need to > patch the license expression downstream in your cargo metadata patch, adding > a comment to package.cargo-toml-patch-comments linking the upstream PR. ---- (In reply to Parag Nemade from comment #11) > I really don't know who will need https://github.com/harfbuzz/harfrust in > future > but my aim was to add this tool in Fedora which got stuck with package > review of rust-read-fonts Hmm, I do wonder if it’s worth building up and maintaining this tree of libraries just in case an application comes along that wants them. I do expect that they may be needed eventually, but there is no guarantee, and you may find yourself maintaining them for several years before that happens. ---- (In reply to Parag Nemade from comment #11) > Yes I used bugzilla commands and some other commands to auto update packages. > I never liked rpmautospec, hence never thought to update my scripts for > rpmautospec. > I like more verbose way of adding Changelog in SPEC file itself. Note that (if you’re not already doing so) Rust library packages need to be updated by using rust2rpm to re-generate the spec file every time, because changes in the upstream crate may need to be reflected in the package. For example, upstream adding a new feature means the spec file gets a new metapackage for that feature. ---- (In reply to Parag Nemade from comment #11) > Sorry but I did not understand this. Probably can you give any specific > example > to understand this better? I know about packages which need compat package > when > doing soname bump. The docs for Rust’s flavor of SemVer are at https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility. If I am updating a Rust library from 1.1.3 to 1.2.0, that’s fine, and I don’t have to coordinate it. If I am updating from 0.1.7 to 0.1.8, that’s also compatible and fine (in contrast to regular SemVer, where any pre-1.0 update could have breaking changes). If I update a Rust library (let’s call it bogolib) from 0.1.7 to 0.2.0, now I need to coordinate this with anything that depends on it. One option that doesn’t require coordination is to simultaneously request a rust-bogolib0.1 compat package, and build rust-bogolib-0.2.0 and rust-bogolib0.1-0.1.7 in the same side tag and ship them in the same update. The accumulation of compat packages increases the maintenance burden, though, so it’s nice to avoid them when they aren’t necessary. So suppose I use cratedeps to learn: rust-bogocli : (crate(bogolib/default) >= 0.1.3 with crate(bogolib/default) < 0.2.0~) Now maybe we have rust-bogocli 1.2.3 packaged, but there’s an update available to 1.2.4 that updates the bogolib dependency from 0.1.3 to 0.2.0. Then the easiest thing I can do is to update bogolib and bogocli at the same time, building them together in a side tag with "fedpkg chain-build" to ensure that the SemVer-breaking library update is accompanied by any changes needed to keep everything compatible. If the latest rust-bogocli still wants bogolib 0.1 but I still want to update the packaged bogolib to 0.2 (maybe because something else needs that version?), and I really want to avoid the compat package, maybe I can patch rust-bogocli to allow bogolib 0.2. This requires a bit more care and understanding, as I have to verify that it isn’t affected by any breaking changes. I can read the bogolib changelogs to see what triggered the SemVer bump: maybe it was just for MSRV (minimum supported Rust version) reasons, or gross API changes where if something compiles, it must not use the affected API, cases that are easy to validate. (The harder case is where the SemVer break involves subtle behavioral changes and the reverse dependency’s test suite might not be detailed enough to catch them.) Ideally I would also send a PR upstream to the bogocli project suggesting the bogolib 0.2 update. Again, the patched bogocli needs to be shipped in the same side tag. Sometimes I might update bogolib from 0.1.10 to 0.1.11 (compatible) and bogocli from 1.4.5 to 1.5.0 (compatible), but bogocli 1.5 requires a minimum bogolib version of 0.1.11. Again, a side tag keeps me from having to wait for the bogolib update to go stable before I can ship bogocli. This kind of thing happens a lot with tightly-coupled libraries that are developed in the same source repository and where upstream often releases updates to multiple crates at the same time.
Thank you for your detailed reply. I am fine to have rust-font-types and rust-font-test-data packages retired from all Fedora releases. If you have ready tools, please retire them. You can also close rust-read-fonts package review. Thanks!
Thanks for talking through all of this. I hope that this doesn’t come off as too discouraging. I am quite excited that upstreams are introducing Rust to font tooling, and I’m excited that you in particular, as an experienced packager who understands fonts, are interested in doing the packaging work. I look forward to helping out when an application (or a shared library, or a Python package) does eventually start to requires these libraries.