https://bugzilla.redhat.com/show_bug.cgi?id=2121902 --- Comment #10 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (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 -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2121902 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
