Bug 2430590

These are first packages I have proposed for inclusion in Fedora, so I am looking for a sponsor (per the instructions)

(the associated request for the inclusion of gpib-firmware is here https://bugzilla.redhat.com/show_bug.cgi?id=2430592)

Cannot find any valid SRPM URL for this ticket. Common causes are:

- You didn't specify `SRPM URL: ...` in the ticket description
  or any of your comments
- The URL schema isn't HTTP or HTTPS
- The SRPM package linked in your URL doesn't match the package name specified
  in the ticket summary


---
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://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10025740-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10025740-gpib/gpib-4.3.7-1.fc43.src.rpm

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10032462-gpib/fedora-review/review.txt

Found issues:

- Unversioned so-files directly in %_libdir.
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
- Explicit dependency on perl-devel is not allowed unless building architecture-specific code which links to libperl.so
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/
- Package contains %{pythonX_site(lib|arch)}/* in %files
  Read more: https://pagure.io/packaging-committee/issue/782
- Not a valid SPDX expression 'GPLv2+'. It seems that you are using the old Fedora license abbreviations. Try `license-fedora2spdx' for converting it to SPDX.
  Read more: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1

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.

Updated spec file:
Spec URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10100950-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10100950-gpib/gpib-4.3.7-105.fc43.src.rpm

Spec URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10100950-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10100950-gpib/gpib-4.3.7-105.fc43.src.rpm

fedora-review-service-build
Spec URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10100950-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10100950-gpib/gpib-4.3.7-105.fc43.src.rpm

Created attachment 2133367 [details]
The .spec file difference from Copr build 10032462 to 10224712

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10224712-gpib/fedora-review/review.txt

Found issues:

- Unversioned so-files directly in %_libdir.
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
- Explicit dependency on perl-devel is not allowed unless building architecture-specific code which links to libperl.so
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/
- Package contains %{pythonX_site(lib|arch)}/* in %files
  Read more: https://pagure.io/packaging-committee/issue/782

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.

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10224748-gpib/fedora-review/review.txt

Found issues:

- Unversioned so-files directly in %_libdir.
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
- Explicit dependency on perl-devel is not allowed unless building architecture-specific code which links to libperl.so
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/
- Package contains %{pythonX_site(lib|arch)}/* in %files
  Read more: https://pagure.io/packaging-committee/issue/782

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.

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10224757-gpib/fedora-review/review.txt

Found issues:

- Unversioned so-files directly in %_libdir.
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
- Explicit dependency on perl-devel is not allowed unless building architecture-specific code which links to libperl.so
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/
- Package contains %{pythonX_site(lib|arch)}/* in %files
  Read more: https://pagure.io/packaging-committee/issue/782

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.

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10224765-gpib/fedora-review/review.txt

Found issues:

- Unversioned so-files directly in %_libdir.
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
- Explicit dependency on perl-devel is not allowed unless building architecture-specific code which links to libperl.so
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/
- Package contains %{pythonX_site(lib|arch)}/* in %files
  Read more: https://pagure.io/packaging-committee/issue/782

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.

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10224772-gpib/fedora-review/review.txt

Found issues:

- Unversioned so-files directly in %_libdir.
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
- Explicit dependency on perl-devel is not allowed unless building architecture-specific code which links to libperl.so
  Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/Perl/
- Package contains %{pythonX_site(lib|arch)}/* in %files
  Read more: https://pagure.io/packaging-committee/issue/782

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://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10226169-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10226169-gpib/gpib-4.3.7-106.fc43.src.rpm

Created attachment 2133418 [details]
The .spec file difference from Copr build 10224772 to 10226185

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10226185-gpib/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://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10232498-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10232498-gpib/gpib-4.3.7-107.fc43.src.rpm

Created attachment 2133727 [details]
The .spec file difference from Copr build 10226185 to 10232504

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

Review template:
https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2430590-gpib/fedora-rawhide-x86_64/10232504-gpib/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://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10268058-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10268058-gpib/gpib-4.3.7-109.fc43.src.rpm

Created attachment 2135095 [details]
The .spec file difference from Copr build 10232504 to 10268069

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

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

https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10280463-gpib/gpib.spec
https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10280463-gpib/gpib-4.3.7-109.fc43.src.rpm

spec: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10280463-gpib/gpib.spec
srpm: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-43-x86_64/10280463-gpib/gpib-4.3.7-109.fc43.src.rpm

Spec URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-44-x86_64/10402818-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-44-x86_64/10402818-gpib/gpib-4.3.7-111.fc44.src.rpm

Created attachment 2138555 [details]
The .spec file difference from Copr build 10268069 to 10405281

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

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

I can take this for now, but co-reviewers are welcome since I did not do a review of something this low-level

(In reply to Cristian Le from comment #28)
> I can take this for now, but co-reviewers are welcome since I did not do a
> review of something this low-level

Thanks!

- `%bcond_*` are quite confusing indeed. If you do not port it to epel8 (don't know why you would at this time), please use `%bcond (option) (default_value)` instead
- I try to stay away from sourceforge, but can't you use `Source0` pointing to `https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/%{version}/linux-gpib-%{version}.tar.gz`? I took it from looking at what other spec files with sourceforge do [1]
- Getting a clean git archive is of course also encouraged ever since the libxz saga. I just don't know if sourceforge can automatically provide one. `%forgemeta` at least is not aware of one, but if you could find one out, do let us know.
- Note that the git archive contains the files of the `linux-gpib-kernel`, so you cannot use that as a source until the firmware parts are cleared
- If you are using a git snapshot, please follow the snapshot naming guidelines
- Please use `%autorelease`/`%autochangelog` [3] unless you have reasons not to. It helps other Fedora maintainers
- `linux-gpib` and others are not a known package in Fedora, right? please remove the Obsoletes
- Have you confirmed with upstream that the license is `GPL-2.0-or-later` or `GPL-2.0-only`? Afaik the distinction cannot be made from the license text alone since those are identical
- What are the reasons for all of the `%bcond_*`. Usually these are used to break circular dependencies or if a feature often breaks
- Please use `%autosetup` or at least `%autopatch` instead of manual `%patch` commands
- Using `3` instead of `%{python3_pkgversion}` is sufficient and more readable. The latter is used for systems like centos where they can have a secondary python version. Unless it is requested to use `%{python3_pkgversion}`, please do not use it eagerly
- Please build the manpages regardless of `%with_docs`
- Conversely, consider if the non-man documentations are really necessary and worth the effort to maintain. Latex dependencies can be quite heavy
- The `%bcond` do not gate the `BuildRequires` properly
- For python packages you are supposed to use `%pyproject_buildrequires` instead of adding dependencies like `pyproject-rpm-macros` manually [4]. See other python projects for other macros that you should be using
- Please use a macro for the SOVERSION instead of the `.so.*` glob
- Are the `%ldconfig` parts necessary, i.e. do other libraries expect it to be loaded as if they were installed in `/usr/lib64`?
- The `rm ..` in %postun is a big no-no. For that matter any scriplets should be avoided as much as possible
- Please drop all of the comments separating the sections and instead use 2 newlines when you switch to a new section. Current form can get quite hard to read due to non-standard comments on section separators
- Please confirm that all the `find %{buildroot} -delete` are necessary. If so please report it to upstream because that is a bug
- The comment about `EPEL7` does not apply, epel7 is no longer buildable in either Fedora or copr
- Please confirm the providence of all the Source/Patch files
- The link to the tcl comment is dead. Please use the packaging guideline instructions instead

[1]: https://sourcegraph.com/search?q=context:global+file:%5C.spec%24+sourceforge&patternType=keyword&sm=0
[2]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_snapshots
[3]: https://fedora-infra.github.io/rpmautospec-docs/index.html
[4]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python
[5]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Tcl

Corrected files...

Spec URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-44-x86_64/10413434-gpib/gpib.spec
SRPM URL: https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-44-x86_64/10413434-gpib/gpib-4.3.7%5E202604302b4cefb-1.fc44.src.rpm

[fedora-review-service-build]

  - `%bcond_*` are quite confusing indeed. If you do not port it to epel8 (don't know why you would at this time), please use `%bcond (option) (default_value)` instead

++ I removed these (evolutionary artifacts)

 - I try to stay away from sourceforge, but can't you use `Source0` pointing to `https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/%{version}/linux-gpib-%{version}.tar.gz`? I took it from looking at what other spec files with sourceforge do [1]

++ I changed the Source0: to a URL but I'm not sure that helps - it seems that the file still needs to be downloaded into SOURCES

  - Getting a clean git archive is of course also encouraged ever since the libxz saga. I just don't know if sourceforge can automatically provide one. `%forgemeta` at least is not aware of one, but if you could find one out, do let us know.

++ I don't understand this - the Sourceforge archive IS git. ( https://sourceforge.net/p/linux-gpib/git/ci/master/tree/ )

  - Note that the git archive contains the files of the `linux-gpib-kernel`, so you cannot use that as a source until the firmware parts are cleared

++ There is no firmware files in `linux-gpib-kernel`, these are the files that are now also part of the linux-kernel. Everything in the Sourceforge git archive (and consequently .zip file) is GPL

- If you are using a git snapshot, please follow the snapshot naming guidelines

** Done

  - Please use `%autorelease`/`%autochangelog` [3] unless you have reasons not to. It helps other Fedora maintainers

** Done

  - `linux-gpib` and others are not a known package in Fedora, right? please remove the Obsoletes

** No, I was using that to obsolete the original COPR package.  I've removed it.

  - Have you confirmed with upstream that the license is `GPL-2.0-or-later` or `GPL-2.0-only`? Afaik the distinction cannot be made from the license text alone since those are identical

** I updated to the GPL-3 license which is what the upstream package now is.

  - What are the reasons for all of the `%bcond_*`. Usually these are used to break circular dependencies or if a feature often breaks

** removed (see above)

  - Please use `%autosetup` or at least `%autopatch` instead of manual `%patch` commands

** done

  - Using `3` instead of `%{python3_pkgversion}` is sufficient and more readable. The latter is used for systems like centos where they can have a secondary python version. Unless it is requested to use `%{python3_pkgversion}`, please do not use it eagerly

** done

  - Please build the manpages regardless of `%with_docs`
  - Conversely, consider if the non-man documentations are really necessary and worth the effort to maintain. Latex dependencies can be quite heavy

** done (removed all the conditionals as they are not needed)

- The `%bcond` do not gate the `BuildRequires` properly

** removed

  - For python packages you are supposed to use `%pyproject_buildrequires` instead of adding dependencies like `pyproject-rpm-macros` manually [4]. See other python projects for other macros that you should be using

** removed requirement for pyproject-rpm-macros

  - Please use a macro for the SOVERSION instead of the `.so.*` glob

** I define soversion and used %{soversion} but this is probably not what you want .. please check and let me know

  - Are the `%ldconfig` parts necessary, i.e. do other libraries expect it to be loaded as if they were installed in `/usr/lib64`?

** I removed the ldconfig_scriptlets as they are not used in Fedora (if I reads the documentation correctly). I think the ldconfig is still needed.

- The `rm ..` in %postun is a big no-no. For that matter any scriplets should be avoided as much as possible

** removed ... (not needed)

  - Please drop all of the comments separating the sections and instead use 2 newlines when you switch to a new section. Current form can get quite hard to read due to non-standard comments on section separators

** What do you mean by 'Sections' - please elaborate

  - Please confirm that all the `find %{buildroot} -delete` are necessary. If so please report it to upstream because that is a bug

** removed (without apparent impact)

  - The comment about `EPEL7` does not apply, epel7 is no longer buildable in either Fedora or copr

++ removed

- Please confirm the providence of all the Source/Patch files

++ yes all GPL files

  - The link to the tcl comment is dead. Please use the packaging guideline instructions instead

++ the packaging guideline recommended way to do this is supposed to be ...
    %{!?tcl_version: %global tcl_version %(echo 'puts $tcl_version' | tclsh)}
    %{!?tcl_sitearch: %global tcl_sitearch %{_libdir}/tcl%{tcl_version}}
   but this doesn't work on copr because tclsh is not available. I included the "BuildRequires: tcl-devel" (as described in the guideline) but it still fails to find tclsh.

Created attachment 2138944 [details]
The .spec file difference from Copr build 10405281 to 10413448

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

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

Unfortunately, the Source URL I presumed to be a permanent link was not .. it rotted in a few hours.
I had to revert back to using the filename - it doesn't appear that I can get a link from Sourceforge to a archive file.

The reverted spec file is here... https://download.copr.fedorainfracloud.org/results/vk2bea/GPIB-User/fedora-44-x86_64/10415530-gpib/gpib.spec

> I changed the Source0: to a URL but I'm not sure that helps - it seems that the file still needs to be downloaded into SOURCES

Yes it helps contributors help update, including automations like packit [1] which helps create the PRs automatically when a new version is released. By default it only updates the `Version` tag, and does the downloading and uploading from the template in `Source0`. Re the still needs to be downloaded, yes that is a general workflow in (almost) all spec files here, i.e. use `spectool -g` to download them (and then upload them to lookaside cache).

> I don't understand this - the Sourceforge archive IS git. ( https://sourceforge.net/p/linux-gpib/git/ci/master/tree/ )

Yes, but it does not seem to provide archives (as you just noted in a few hours :) ). E.g. for a github repo (https://github.com/tukaani-project/xz/) the release git archive (and even arbitrary commit ones) are available (https://github.com/tukaani-project/xz/archive/<commitish>.tar.gz). On the other hand, sourceforge provides release tarballs (github equivalent is https://github.com/tukaani-project/xz/releases/download/v5.8.3/xz-5.8.3.tar.gz), which I linked previously in https://sourceforge.net/projects/linux-gpib/files/linux-gpib%20for%203.x.x%20and%202.6.x%20kernels/. The difference between a git archive and the release tarball is that the latter can have arbitrary contents (hence the libxz issue [2]) and it is usually used to provide pre-compiled `configure` files (which you are not supposed to use either way).

> There is no firmware files in `linux-gpib-kernel`, these are the files that are now also part of the linux-kernel. Everything in the Sourceforge git archive (and consequently .zip file) is GPL

Oh I see, where did you get the link for https://linux-gpib.sourceforge.io/firmware? The only reference I found is to https://github.com/fmhess/linux_gpib_firmware.

> I define soversion and used %{soversion} but this is probably not what you want .. please check and let me know

The current version looks good. The issue is that you should use the soversion in the `%{_libdir}/libgpib.so.%{soversion}` so that if there is a change in that file, you catch it early and can check all dependents are compatible and are being rebuilt. For this package this might not be an issue, but it's good practice to use in general.

> What do you mean by 'Sections' - please elaborate

There are various sections defined, but over here I mainly refer to the build-scriplets [3] `%prep`, `%conf`, `%build`, `%install`, `%check`, and `%generate_buildrequires` which behave effectively like sections so it is common to use those as the main separators, e.g.
```
...

%prep
%autosetup


%build
%cmake
%cmake_build


...
```

in the current one the `# Post-install stuff` is a confusing deliminator, particularly since `%post` and such belong to specific (sub-)package and not the build process.

> I removed the ldconfig_scriptlets as they are not used in Fedora (if I reads the documentation correctly). I think the ldconfig is still needed.

`%ldconfig_scriptlets` and `%ldconfig` are the same thing [4-6]. I did misunderstood its function though
```
       ldconfig will look only at files that are named lib*.so* (for
       regular shared objects) or ld-*.so* (for the dynamic loader
       itself).  Other files will be ignored.  Also, ldconfig expects a
       certain pattern to how the symbolic links are set up, like this
       example, where the middle file (libfoo.so.1 here) is the SONAME
       for the library:

           libfoo.so -> libfoo.so.1 -> libfoo.so.1.12
```
but obviously the `%ldconfig` are not needed because you already have those files in `%files` and if you would need it it should be at build time. But let me double-check with devel room.

> - Please confirm the providence of all the Source/Patch files
> ++ yes all GPL files

Not exactly what I asked, but that was on my fault. Besides licensing there is also the copyright holder, and who is it in those cases, you, upstream, or a third-party. If it's the 2nd or 3rd one, you must include a reference.

> about the tcl

Can you post on #devel or #buildsys:fedoraproject.org matrix room about this?

[1]: https://packit.dev/docs/fedora-releases-guide
[2]: https://en.wikipedia.org/wiki/XZ_Utils_backdoor
[3]: https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets
[4]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_shared_libraries
[5]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/#_linker_configuration_files
[6]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#alternatives-to-rpath