Spec URL: https://dcavalca.fedorapeople.org/review/perfetto/perfetto.spec SRPM URL: https://dcavalca.fedorapeople.org/review/perfetto/perfetto-40.0-1.fc40.src.rpm Description: Perfetto is a production-grade open-source stack for performance instrumentation and trace analysis. It offers services and libraries and for recording system-level and app-level traces, native plus Java heap profiling, a library for analyzing traces using SQL and a web-based UI to visualize and explore multi-GB traces. Fedora Account System Username: dcavalca
This package built on koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=110787234
Perfetto is a complicated beast and this is the minimum viable packaging I could put together. Notable issues: - ExclusiveArch is because the "bespoke" build system this thing uses only works on arches that Android supports (despite not actually targeting Android when doing a Linux build) - libperfetto.so is unversioned; I couldn't find a sane way to fix the soname (or even where it's configured in the first place) - traced_perf doesn't build and is disabled - unittests require a bundled copy of googletests that isn't actually bundled and fail to build, so they're disabled; integration tests require debugfs and perform active tracing, so they're not appropriate for a distro package - the UI isn't packaged, but one can just use https://ui.perfetto.dev - docs, examples, tools and Python bindings are not packaged
Taking this review.
Copr build: https://copr.fedorainfracloud.org/coprs/build/6812701 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2255751-perfetto/fedora-rawhide-x86_64/06812701-perfetto/fedora-review/review.txt Found issues: - Unversioned so-files directly in %_libdir. Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages Please know that there can be false-positives. --- 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.
Spec URL: https://dcavalca.fedorapeople.org/review/perfetto/perfetto.spec SRPM URL: https://dcavalca.fedorapeople.org/review/perfetto/perfetto-40.0-1.fc40.src.rpm Changelog: - package the SDK as well
Created attachment 2005969 [details] The .spec file difference from Copr build 6812701 to 6815981
Copr build: https://copr.fedorainfracloud.org/coprs/build/6815981 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2255751-perfetto/fedora-rawhide-x86_64/06815981-perfetto/fedora-review/review.txt Found issues: - perfetto-sdk : /usr/share/perfetto/sdk/perfetto.h Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages - Unversioned so-files directly in %_libdir. Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages Please know that there can be false-positives. --- 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.
It occurs to me that both this package and another one I was looking at just now (https://github.com/charles-lunarg/vk-bootstrap) have an interesting conundrum. In both cases a "library" is shipped as a header + cpp file, with the explicit goal that the consumer will include and link these directly as part of their build. In the latest iteration of perfetto I ship these in %{_datadir}/%{name}/sdk, but perhaps %{_libdir} would be more appropriate? As while these aren't arched per-se, their consumers would definitely be (and header-only packages are arched, and are probably the closest to this).