Bug 2121902

Update to latest version:
Spec URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument.spec
SRPM URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument-4.4.0-1.fc39.src.rpm

Copr build:
https://copr.fedorainfracloud.org/coprs/build/5849458
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2121902-pyinstrument/fedora-rawhide-x86_64/05849458-pyinstrument/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.

- Should fix the shebang in pyinstrument-doc/examples/django_example/manage.py
- The doc sub-package can be marked noarch
- Including Sphinx html documentation requires a bit more effort, possibly to the point of being unmanagable while complying to the current bundled library guidelines. See recent package review [1] and a packaging doc pull request [2].
- Looks like vendor/keypath.py is BSD 2-Clause, and also likely should be handled according to the Bundled library guidelines [3]
- vendor/appdirs.py is MIT, and also likely should be handled according to the Bundled library guidelines [3]

1: https://bugzilla.redhat.com/show_bug.cgi?id=2173018#c5
2: https://pagure.io/packaging-committee/pull-request/1244
3: https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/

Spec URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument.spec
SRPM URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument-4.4.0-2.fc39.src.rpm

Updated:
- shebang fixed
- doc package is noarch
- appdirs and decorator are unbundled
- I added a Provides:bundled() and modified the License for keypath

I didn't change anything about how the documentation is generated.
The pull request for the guidelines is still unresolved, and frankly, I'm not
sure that symlinking is the best option. That javascript is indeed bundled, but
it is only used for some minor operations on the doc page, so I don't think it
makes much of a difference. Ideally, we can figure out some solution that does
not require individual packages to do special steps. I'll leave it as is until
the FPC ticket is resolved.

Created attachment 1963346 [details]
The .spec file difference from Copr build 5849458 to 5897234

Copr build:
https://copr.fedorainfracloud.org/coprs/build/5897234
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2121902-pyinstrument/fedora-rawhide-x86_64/05897234-pyinstrument/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.

Hi Zbigniew, thanks for looking at input-remapper.
The day went nothing like planned, so I didn't get to all the items on the checklist, here are some first comments.

The package works great so far, kudos for digging it up!

There's an app.js file under %{python3_sitearch}/pyinstrument/renderers/html_resources/, which apparently comes from Vue.js and it's MIT-licensed. You'll need to add that to your licenses. That being said, I wasn't able to find the same file in upstream Vue.js (https://github.com/vuejs), however the comment in the file is clear about that.

I checked the contents of the cache of ldconfig (ldconfig -p) after installation and I didn't see the packaged .so file (stat_profile.cpython-311-x86_64-linux-gnu.so), so I guess that's not an issue.

fedora-review complains about the linked spec file and the one in the source rpm not being the same.

There's also this from fedora-review
[!]: Uses parallel make %{?_smp_mflags} macro.
but I don't see why that should be in this spec file. 

Finally, I find this part of the review template a bit confusing:
[ ]: A package which is used by another package via an egg interface should
     provide egg info.
Is the provided *.dist-info directory an equivalent for the older *.egg-info? Would this item on the list be explicitly required if pyinstrument was being packaged as a dependency of another (Python) package?


I think/hope I can finish the review tomorrow.

(In reply to Alexander Ploumistos from comment #7)
> There's an app.js file under
> %{python3_sitearch}/pyinstrument/renderers/html_resources/, which apparently
> comes from Vue.js and it's MIT-licensed.
I added MIT to the license line.
spec/srpm updated in place.

> I checked the contents of the cache of ldconfig (ldconfig -p) after
> installation and I didn't see the packaged .so file
> (stat_profile.cpython-311-x86_64-linux-gnu.so), so I guess that's not an
> issue.
Yes, this is just a normal python compiled module and it is never loaded via
the dynamic linker.

> fedora-review complains about the linked spec file and the one in the source
> rpm not being the same.
I use %autorelease and %autochangelog, and the spec file in the srpm is after
processing. fedora-review should learn to ignore this. (Or maybe it already has,
but this hasn't been released yet? I lost track.)

> There's also this from fedora-review
> [!]: Uses parallel make %{?_smp_mflags} macro.
> but I don't see why that should be in this spec file. 
The build doesn't use make ;)

> Finally, I find this part of the review template a bit confusing:
> [ ]: A package which is used by another package via an egg interface should
>      provide egg info.
> Is the provided *.dist-info directory an equivalent for the older
> *.egg-info? Would this item on the list be explicitly required if
> pyinstrument was being packaged as a dependency of another (Python) package?
.egg-info is the older style of metadata. %pyproject and the new Python packaging
standards use .dist-info.

There's just one point about the license breakdown to clarify and I have a few questions of my own, you are good to go.

I've included the output of all the tools, just in case you're interested. Some items that were marked as "pass" ([x]) by fedora-review should actually have been "not applicable" ([-]), but that's me splitting hairs.


Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated



===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.
[x]: If your application is a C or C++ application you must list a
     BuildRequires against gcc, gcc-c++ or clang.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

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", "BSD 3-Clause License", "MIT License",
     "BSD 2-Clause License". 104 files have unknown license.
[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.
     
* This is new, right? Does this mean that the output of licensecheck (above) needs to be in the spec file from now on?
     
     
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.

* Looking at the keypath code and upstream activity, I can't say that it warrants unbundling. The only problem that might turn up is if someday they decide to add a version number, but that has nothing to do with bundling.
 

[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Package contains desktop file if it is a GUI application.
[-]: 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]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[x]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 30720 bytes in 1 files.
[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: There are rpmlint messages (see attachment).
[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]: 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]: Package does not contain duplicates in %files.
[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]: Packages must not store files under /srv, /opt or /usr/local

Python:
[x]: Python eggs must not download any dependencies during the build
     process.
[x]: A package which is used by another package via an egg interface should
     provide egg info.
[x]: Package meets the Packaging Guidelines::Python

* The newest guidelines! I need to update my packages…


[x]: Package contains BR: python2-devel or python3-devel
[x]: Packages MUST NOT have dependencies (either build-time or runtime) on
     packages named with the unversioned python- prefix unless no properly
     versioned package exists. Dependencies on Python packages instead MUST
     use names beginning with python2- or python3- as appropriate.
[x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files
[x]: Binary eggs must be removed in %prep

===== SHOULD items =====

Generic:
[-]: Uses parallel make %{?_smp_mflags} macro.
[-]: 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).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise
     justified.
     
* The patch is justified, out of curiosity, have you gotten in touch with upstream about modifying their code to allow for system-provided deps?
     
     
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: Package should compile and build into binary rpms on all supported
     architectures.
[x]: %check is present and all tests pass.

* Let's say they do… I think Miro and the Python SIG might be interested in these failures though.


[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]: Fully versioned dependency in subpackages if applicable.
[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]: Spec file according to URL is the same as in SRPM.
     Note: Spec file as given by url is not the same as in SRPM (see
     attached diff).
     See: (this test has no URL)
     
* Already answered.
     
     
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
     
* Why is it "strange" not to have a file readable by others?
* Is there something to be done about these sphinx files (asking for a friend)?
     
     
[-]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.


Rpmlint
-------
Checking: pyinstrument-4.4.0-2.fc39.x86_64.rpm
          pyinstrument-doc-4.4.0-2.fc39.noarch.rpm
          pyinstrument-debuginfo-4.4.0-2.fc39.x86_64.rpm
          pyinstrument-debugsource-4.4.0-2.fc39.x86_64.rpm
          pyinstrument-4.4.0-2.fc39.src.rpm
============================================================================================== rpmlint session starts =============================================================================================
rpmlint: 2.4.0
configuration:
    /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.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/tmp2elfvb8h')]
checks: 31, packages: 5

pyinstrument.spec:40: W: unversioned-explicit-provides bundled(python-keypath)
pyinstrument.src: W: strange-permission pyinstrument.spec 600
pyinstrument-doc.noarch: W: hidden-file-or-dir /usr/share/doc/pyinstrument-doc/html/.buildinfo
=============================================================== 5 packages and 0 specfiles checked; 0 errors, 3 warnings, 0 badness; has taken 1.5 s ==============================================================




Rpmlint (debuginfo)
-------------------
Checking: pyinstrument-debuginfo-4.4.0-2.fc39.x86_64.rpm
============================================================================================== rpmlint session starts =============================================================================================
rpmlint: 2.4.0
configuration:
    /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.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/tmpxx_88v72')]
checks: 31, packages: 1

=============================================================== 1 packages and 0 specfiles checked; 0 errors, 0 warnings, 0 badness; has taken 0.1 s ==============================================================





Rpmlint (installed packages)
----------------------------
============================ rpmlint session starts ============================
rpmlint: 2.4.0
configuration:
    /usr/lib/python3.11/site-packages/rpmlint/configdefaults.toml
    /etc/xdg/rpmlint/fedora-legacy-licenses.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: 31, packages: 4

pyinstrument-doc.noarch: W: hidden-file-or-dir /usr/share/doc/pyinstrument-doc/html/.buildinfo
 4 packages and 0 specfiles checked; 0 errors, 1 warnings, 0 badness; has taken 0.4 s 



Unversioned so-files
--------------------
pyinstrument: /usr/lib64/python3.11/site-packages/pyinstrument/low_level/stat_profile.cpython-311-x86_64-linux-gnu.so

Source checksums
----------------
https://github.com/joerick/pyinstrument/archive/v4.4.0/pyinstrument-4.4.0.tar.gz :
  CHECKSUM(SHA256) this package     : 3afa7f655c3059f4ee938ca9c14abbb6063cab3f94ce6b91f195a7d70ee645ef
  CHECKSUM(SHA256) upstream package : 3afa7f655c3059f4ee938ca9c14abbb6063cab3f94ce6b91f195a7d70ee645ef


Requires
--------
pyinstrument (rpmlib, GLIBC filtered):
    /usr/bin/python3
    libc.so.6()(64bit)
    python(abi)
    python3dist(appdirs)
    python3dist(decorator)
    rtld(GNU_HASH)

pyinstrument-doc (rpmlib, GLIBC filtered):
    pyinstrument

pyinstrument-debuginfo (rpmlib, GLIBC filtered):

pyinstrument-debugsource (rpmlib, GLIBC filtered):



Provides
--------
pyinstrument:
    bundled(python-keypath)
    pyinstrument
    pyinstrument(x86-64)
    python3.11dist(pyinstrument)
    python3dist(pyinstrument)

pyinstrument-doc:
    pyinstrument-doc

pyinstrument-debuginfo:
    debuginfo(build-id)
    pyinstrument-debuginfo
    pyinstrument-debuginfo(x86-64)

pyinstrument-debugsource:
    pyinstrument-debugsource
    pyinstrument-debugsource(x86-64)



Diff spec file in url and in SRPM
---------------------------------
--- /home/alexpl/reviews/2121902-pyinstrument/srpm/pyinstrument.spec	2023-05-15 21:23:44.815303939 +0200
+++ /home/alexpl/reviews/2121902-pyinstrument/srpm-unpacked/pyinstrument.spec	2023-05-15 08:14:04.000000000 +0200
@@ -1,2 +1,12 @@
+## START: Set by rpmautospec
+## (rpmautospec version 0.3.5)
+## RPMAUTOSPEC: autorelease, autochangelog
+%define autorelease(e:s:pb:n) %{?-p:0.}%{lua:
+    release_number = 2;
+    base_release_number = tonumber(rpm.expand("%{?-b*}%{!?-b:1}"));
+    print(release_number + base_release_number - 1);
+}%{?-e:.%{-e*}}%{?-s:.%{-s*}}%{!?-n:%{?dist}}
+## END: Set by rpmautospec
+
 Name:           pyinstrument
 Version:        4.4.0
@@ -107,3 +117,10 @@
 
 %changelog
-%autochangelog
+* Mon May 15 2023 Zbigniew Jędrzejewski-Szmek <zbyszek.pl> - 4.4.0-2
+- Also list MIT in licenses
+
+* Sat May 06 2023 Zbigniew Jędrzejewski-Szmek <zbyszek.pl> - 4.4.0-1
+- Version 4.4.0
+
+* Sat Aug 27 2022 Zbigniew Jędrzejewski-Szmek <zbyszek.pl> - 4.3.0-1
+- Initial version


Generated by fedora-review 0.9.0 (6761b6c) last change: 2022-08-23
Command line :/usr/bin/fedora-review -b 2121902 -v
Buildroot used: fedora-rawhide-x86_64
Active plugins: Shell-api, Generic, C/C++, Python
Disabled plugins: Ocaml, fonts, PHP, Haskell, Java, R, SugarActivity, Perl
Disabled flags: EPEL6, EPEL7, DISTTAG, BATCH, EXARCH

(In reply to Alexander Ploumistos from comment #9)
> [?]: If the package is under multiple licenses, the licensing breakdown
>      must be documented in the spec.
>      
> * This is new, right? Does this mean that the output of licensecheck (above)
> needs to be in the spec file from now on?

Whenever I have seen the term "license breakdown" used previously, it was meant
in the sense of a (short) description. I had a short comment, but it didn't explain
everything, so I expanded it:
# The majority of code is BSD-3-Clause.
# Exceptions:
#   pyinstrument/vendor/keypath.py: BSD-2-Clause
#   pyinstrument/renderers/html_resources/app.js: MIT
  License:        BSD-3-Clause AND BSD-2-Clause and MIT
  
> [x]: %build honors applicable compiler flags or justifies otherwise.
> [x]: Package contains no bundled libraries without FPC exception.
> 
> * Looking at the keypath code and upstream activity, I can't say that it
> warrants unbundling. The only problem that might turn up is if someday they
> decide to add a version number, but that has nothing to do with bundling.

The question is really about the version of the code that is bundled.
If upstream makes a release, and if the pyinstrument author includes this copy that
actually corresponds to some version without modifications, and if we don't
unbundle at that point, then we can add a version. Too many conditionals here
to worry about the issue right now ;).
 
> [x]: Patches link to upstream bugs/comments/lists or are otherwise
>      justified.
>      
> * The patch is justified, out of curiosity, have you gotten in touch with
> upstream about modifying their code to allow for system-provided deps?
I didn't, mostly because I wasn't sure what to ask for: giving external
or bundled version priority. I did some quick testing after the unbundling,
but I want to get this built and used by people, to see if issues actually
arise. Because maybe upstream would be amenable to just dropping the
bundled copy. This would also save them the need to update.

> [x]: %check is present and all tests pass.
> 
> * Let's say they do… I think Miro and the Python SIG might be interested in
> these failures though.

At least two of the tests only fail in mock. So this might be related
to the lack of full environment, and not actually matter for normal use.
I didn't have the energy to debug this.

> [x]: Rpmlint is run on all installed packages.
>      Note: There are rpmlint messages (see attachment).
>      
> * Why is it "strange" not to have a file readable by others?

Let's consider what git is doing: every file has only two bits of access
information: is it a file or directory, and if it is a file, is it executable.
So when you clone a repo, and your user has an umask that is different than the
umask of the person putting the file under version control, this has no effect.
The file permissions ownership is always "you", the group is always "your group",
and the mode is either rw-rw-rw- or rwxrwxrwx masked by the user's umask.

Instead, rpm leaks the irrelevant details that only make sense on a local
system to every recipient of an srpm: user name, group name, file permissions
that are only relevant in relation to the local group config. This is particularly
annoying in case of user names: it immediately breaks reproducibility (in the
sense of reproducible builds), generates completely unnecessary warnings about
the recipient not having some random 'joe' user on their system, and also
creates files with a wrong access mask (because local files _must_ respect
the local user umask, not the umask of the sender. This could even be a
"security issue", if the recipient has a narrower umask than the sender.
E.g. the file could be unexpectedly writeable by the group.) 

This could be fixed. But instead of fixing it, we go in an opposite way:
we cement the rpm design mistake in by adding a linter that annoys people
to adjust something that could and should be handled automatically.

:(

> * Is there something to be done about these sphinx files (asking for a
> friend)?

> pyinstrument-doc.noarch: W: hidden-file-or-dir /usr/share/doc/pyinstrument-doc/html/.buildinfo

I assume you mean this warning ^. I think the case is similar to the
previous rpmlint warning: it doesn't make any sense. There is absolutely
no problem with the file being "hidden". Nobody navigates around using 'cd'
and 'ls' in /usr/share/doc/pyinstrument-doc/html/. And even if they did,
it's good that this file is not shown by 'ls'. What is the _point_ of this
check?

> Unversioned so-files
> pyinstrument: /usr/lib64/python3.11/site-packages/pyinstrument/low_level/stat_profile.cpython-311-x86_64-linux-gnu.so

You didn't mention this one, but it is another similar case: rpmlint could check
that this path is not in the shared library search path, and avoid the useless warning.
Or it could even hardcode that anything with /site-packages/ can be ignored. Instead,
we emit this warning for a large subset of the ~10k python packages.

Updated. The only change is the license breakdown:
Spec URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument.spec
SRPM URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument-4.4.0-3.fc39.src.rpm

Created attachment 1964974 [details]
The .spec file difference from Copr build 5897234 to 5925796

Copr build:
https://copr.fedorainfracloud.org/coprs/build/5925796
(succeeded)

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2121902-pyinstrument/fedora-rawhide-x86_64/05925796-pyinstrument/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.

Thank you for all the replies Zbigniew, it's been very educational.


(In reply to Zbigniew Jędrzejewski-Szmek from comment #10)
> (In reply to Alexander Ploumistos from comment #9)
> > Unversioned so-files
> > pyinstrument: /usr/lib64/python3.11/site-packages/pyinstrument/low_level/stat_profile.cpython-311-x86_64-linux-gnu.so
> 
> You didn't mention this one, but it is another similar case: rpmlint could
> check
> that this path is not in the shared library search path, and avoid the
> useless warning.
> Or it could even hardcode that anything with /site-packages/ can be ignored.
> Instead,
> we emit this warning for a large subset of the ~10k python packages.

I didn't mention it, because I had already checked myself (as required):
[x]: Development (unversioned) .so files in -devel subpackage, if present.
     Note: Unversioned so-files in private %_libdir subdirectory (see
     attachment). Verify they are not in ld path.


> Updated. The only change is the license breakdown:
> Spec URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument.spec
> SRPM URL: https://in.waw.pl/~zbyszek/fedora/pyinstrument-4.4.0-3.fc39.src.rpm


Something has glitched here, because rpmlint spews a new warning:
pyinstrument.x86_64: W: incoherent-version-in-changelog 4.4.0-2 ['4.4.0-3.fc39', '4.4.0-3']

I trust you are more than capable of dealing with this - if indeed it needs to be dealt with.


The package is approved.


P.S.: I'll try to advance with input-remapper on Thursday, though realistically it's probably going to be the weekend, work has drained both my time and my brain.

(In reply to Alexander Ploumistos from comment #13)
> Something has glitched here, because rpmlint spews a new warning:
> pyinstrument.x86_64: W: incoherent-version-in-changelog 4.4.0-2
> ['4.4.0-3.fc39', '4.4.0-3']

I used '[skip changelog]' in the commit (because it only affects the spec file),
and doesn't need to be described in %changelog. But this means that the generated
spec file has the release field bumped without a changelog entry (the last
changelog entry is 4.4.0-2, but the srpm has version 4.4.0-3).

Basically, with rpmautospec, if there is no changelog entry for a rebuild,
the user has to assume that there is no user-visible change since the last entry
in the changelog. The same is actually true with a manual changelog, except
that there the maintainer might have simply forgotten to do a changelog
entry.

In principle, we could try to implement some solution for this, but I think
that this matters very little for users and we can ignore the problem.

OTOH, fedora-review and rpmlint should understand that %autochangelog is
used (there's a tag at the top of the spec file:
 ## RPMAUTOSPEC: autorelease, autochangelog
) and completely ignore the generated changelog.

> The package is approved.

Thanks!

The Pagure repository was created at https://src.fedoraproject.org/rpms/pyinstrument

It's now available in rawhide and in updates for F38 and F37.