Bug 2414840
| Summary: | Review Request: giza - A 2D scientific plotting library built on cairo | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Phil Wyett <philip.wyett> |
| Component: | Package Review | Assignee: | Nobody's working on this, feel free to take it <nobody> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | benson_muite, code, package-review, philip.wyett |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://github.com/danieljprice/giza | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2026-02-09 06:47:50 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Phil Wyett
2025-11-13 15:06:09 UTC
Apologies if I have checked sections that I should not have. It has been a while and this is the first submission in a few years. Copr build: https://copr.fedorainfracloud.org/coprs/build/9795361 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09795361-giza/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. Is there a specific technical requirement for the static library? If so, it would be helpful to justify packaging the static library in a spec-file comment, since we avoid packaging those whenever possible: https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries May also want to check what is in https://bugzilla.redhat.com/show_bug.cgi?id=1187030 and perhaps choose to co-maintain the package. (In reply to Ben Beasley from comment #3) > Is there a specific technical requirement for the static library? If so, it > would be helpful to justify packaging the static library in a spec-file > comment, since we avoid packaging those whenever possible: > https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static- > libraries Ben, Thanks, I am now too used to creating static packages for Debian and have to get back to that they are not wanted unless for good reason. Below is new SPEC and SRPM disabling static lib build and removing associated RPMS. Spec URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza.spec SRPM URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza-1.5.0-1.el9.src.rpm Created attachment 2114906 [details]
The .spec file difference from Copr build 9795361 to 9807606
Copr build: https://copr.fedorainfracloud.org/coprs/build/9807606 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09807606-giza/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. (In reply to Benson Muite from comment #4) > May also want to check what is in > https://bugzilla.redhat.com/show_bug.cgi?id=1187030 and perhaps choose to > co-maintain the package. I will push forward with this submission, but am happy to add a co-maintainer after in Fedora. I will be able to introduce any co-maintainer to the upstream developer who I have a good working relationship with. I can’t find this written down anywhere, but I think that in cases of duplicate review requests for the same package, the earlier one should take priority. In this case, that would be bug 1187030. This review request could be considered if the previous one becomes stalled (https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#stalled) or by agreement with the previous submitter. (In reply to Ben Beasley from comment #9) > I can’t find this written down anywhere, but I think that in cases of > duplicate review requests for the same package, the earlier one should take > priority. In this case, that would be bug 1187030. This review request could > be considered if the previous one becomes stalled > (https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#stalled) > or by agreement with the previous submitter. The ticket listed has had no activity since April of this year and dates back to 2015. I am packaging giza as a build dependency for splash[1] which I am preparing now, a widely used astronomy tool. I will maintain and keep both up to date within fedora and EPEL. [1] https://github.com/danieljprice/splash (In reply to Phil Wyett from comment #10) > The ticket listed has had no activity since April of this year and dates > back to 2015. Right, that’s what https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/#submitter_not_responding is for. The policy implies there will be automated comments, but the automation seems to be broken. I added the prescribed comment, https://bugzilla.redhat.com/show_bug.cgi?id=1187030#c65. If there is no reply within one week, then that bug can be closed as a duplicate of this one. (In reply to Ben Beasley from comment #11) > (In reply to Phil Wyett from comment #10) > > The ticket listed has had no activity since April of this year and dates > > back to 2015. > > Right, that’s what > https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/ > #submitter_not_responding is for. The policy implies there will be automated > comments, but the automation seems to be broken. I added the prescribed > comment, https://bugzilla.redhat.com/show_bug.cgi?id=1187030#c65. If there > is no reply within one week, then that bug can be closed as a duplicate of > this one. Thanks, we will see what happens over the next week. It’s a minor thing, but this doesn’t do what you intended:
%if 0%{?el} <= 9
On Fedora, the el macro is not defined, and this expands to "%if 00 <= 9", which is true – so the unnecessary manual .la file removal does happen on Fedora.
Since the only non-end-of-life EPEL older than EPEL9 is EPEL8, you might just write "%if 0%{?el8}" or "%if %{defined el8}" instead.
Explicitly removing the .la file is just unnecessary on Fedora (because it’s handled by a buildroot policy script), not wrong or harmful, so I wouldn’t block a package review on this.
----
You should be more explicit about listing files in shared directories,
%{_includedir}/*.h
%{_includedir}/*.F90
%{_libdir}/*.so
[…]
%{_libdir}/pkgconfig/*.pc
See https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_lists.
----
A more straightforward way to write this
Source0: %{url}/archive/refs/tags/v%{version}.tar.gz#/%{name}-%{version}.tar.gz
would be this
Source0: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz
If you want to be very precise about specifying a tag (only really required if upstream
produces releases with the same names as tags, making the URL I’ve suggested above
ambiguous), then you can also write
Source0: %{url}/archive/refs/tags/v%{version}/%{name}-%{version}.tar.gz
which still avoids the "#/" hack.
----
I favor re-generating configure scripts from autotools sources by adding BuildRequires on autoconf, automake, and libtool, and adding "autoreconf --force --install --verbose" to %build (or to %conf, if using that section), rather than using pre-generated configure scripts, but this has been a matter of significant debate in Fedora, and there has never been a solid consensus on what the Right Thing to Do is. Therefore, it wouldn’t be correct to ask you to change this, only to point out that you have a choice.
----
Is there anything stopping you from running the tests?
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_test_suites
----
I still haven’t looked at this as closely as I would when doing a real review, but this otherwise looks pretty reasonable.
(In reply to Ben Beasley from comment #13) > It’s a minor thing, but this doesn’t do what you intended: > > %if 0%{?el} <= 9 > > On Fedora, the el macro is not defined, and this expands to "%if 00 <= 9", > which is true – so the unnecessary manual .la file removal does happen on > Fedora. > > Since the only non-end-of-life EPEL older than EPEL9 is EPEL8, you might > just write "%if 0%{?el8}" or "%if %{defined el8}" instead. > > Explicitly removing the .la file is just unnecessary on Fedora (because it’s > handled by a buildroot policy script), not wrong or harmful, so I wouldn’t > block a package review on this. > > ---- > > You should be more explicit about listing files in shared directories, > > %{_includedir}/*.h > %{_includedir}/*.F90 > %{_libdir}/*.so > […] > %{_libdir}/pkgconfig/*.pc > > See > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_explicit_lists. > > ---- > > A more straightforward way to write this > > Source0: > %{url}/archive/refs/tags/v%{version}.tar.gz#/%{name}-%{version}.tar.gz > > would be this > > Source0: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz > > If you want to be very precise about specifying a tag (only really required > if upstream > produces releases with the same names as tags, making the URL I’ve suggested > above > ambiguous), then you can also write > > Source0: %{url}/archive/refs/tags/v%{version}/%{name}-%{version}.tar.gz > > which still avoids the "#/" hack. > > ---- > > I favor re-generating configure scripts from autotools sources by adding > BuildRequires on autoconf, automake, and libtool, and adding "autoreconf > --force --install --verbose" to %build (or to %conf, if using that section), > rather than using pre-generated configure scripts, but this has been a > matter of significant debate in Fedora, and there has never been a solid > consensus on what the Right Thing to Do is. Therefore, it wouldn’t be > correct to ask you to change this, only to point out that you have a choice. > > ---- > > Is there anything stopping you from running the tests? > > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_test_suites > > ---- > > I still haven’t looked at this as closely as I would when doing a real > review, but this otherwise looks pretty reasonable. I think my new upload should cover the issues raised. Spec URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza.spec SRPM URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza-1.5.0-1.el9.src.rpm Created attachment 2115285 [details]
The .spec file difference from Copr build 9807606 to 9813421
Copr build: https://copr.fedorainfracloud.org/coprs/build/9813421 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09813421-giza/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. Fresh upload. Spec URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza.spec SRPM URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza-1.5.0-1.el9.src.rpm Created attachment 2115364 [details]
The .spec file difference from Copr build 9813421 to 9815834
Copr build: https://copr.fedorainfracloud.org/coprs/build/9815834 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09815834-giza/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. The license situation here is weird. COPYING is GPLv3 COPYING.LESSER is LGPLv3 ChangeLog has: > 2023-11-28 Daniel Price <daniel.price> > > * COPYING, LICENSE: changed license to LGPL3 And docs/index.html has: > Giza is currently distributed under the <a href="https://www.gnu.org/licenses/lgpl-3.0.html">LGPL license</a>. But all of the source file still have this header: > /* giza - a scientific plotting library built on cairo > * > * Copyright (c) 2010 James Wetter and Daniel Price > * Copyright (c) 2010-2012 Daniel Price > * > * This library is free software; and you are welcome to redistribute > * it under the terms of the GNU General Public License > * (GPL, see LICENSE file for details) and the provision that > * this notice remains intact. If you modify this file, please > * note section 5a) of the GPLv3 states that: > * > * a) The work must carry prominent notices stating that you modified > * it, and giving a relevant date. > * > * This software is distributed "AS IS", with ABSOLUTELY NO WARRANTY. > * See the GPL for specific language governing rights and limitations. > * > * The Original code is the giza plotting library. > * > * Contributor(s): > * James Wetter <wetter.j> > * Daniel Price <daniel.price> (main contact) > */ which is GPLv3, probably GPL-3.0-only in SPDX terms since there is no “or any later version” language, although it’s a slightly ambiguous notice. However, there is an unusual extra bit here: > and the provision that this notice remains intact. which probably needs to be reviewed in https://gitlab.com/fedora/legal/fedora-license-data/-/issues. From https://github.com/danieljprice/giza/pull/69, upstream seems to have the impression that they can include GPL-licensed sources in a library and still call it LGPL overall. I don’t find this convincing, and would probably call it “LGPL-3.0-only AND GPL-3.0-only”, subject to review of the “and the provision that this notice remains intact” language. I see nothing that indicates a disjunctive choice of licenses, so I don’t think “LGPL-3.0-only or GPL-3.0-only” is correct. The files src/*.pc.in have this license: > # This file is free software; as a special exception the author gives > # unlimited permission to copy and/or distribute it, with or without > # modifications, as long as this notice is preserved. > # > # This file is distributed in the hope that it will be useful, but > # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the > # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. which seems like a close enough match for FSFULLRWD, https://spdx.org/licenses/FSFULLRWD.html. Since the .pc files generated from these are installed in the -devel subpackage, the -devel subpackage should have a corresponding license term, like: # .pc files are FSFULLRWD License: LGPL-3.0-only AND GPL-3.0-only AND FSFULLRWD (In reply to Ben Beasley from comment #20) > The license situation here is weird. > > COPYING is GPLv3 > > COPYING.LESSER is LGPLv3 > > ChangeLog has: > > > 2023-11-28 Daniel Price <daniel.price> > > > > * COPYING, LICENSE: changed license to LGPL3 > > And docs/index.html has: > > > Giza is currently distributed under the <a href="https://www.gnu.org/licenses/lgpl-3.0.html">LGPL license</a>. > > But all of the source file still have this header: > > > /* giza - a scientific plotting library built on cairo > > * > > * Copyright (c) 2010 James Wetter and Daniel Price > > * Copyright (c) 2010-2012 Daniel Price > > * > > * This library is free software; and you are welcome to redistribute > > * it under the terms of the GNU General Public License > > * (GPL, see LICENSE file for details) and the provision that > > * this notice remains intact. If you modify this file, please > > * note section 5a) of the GPLv3 states that: > > * > > * a) The work must carry prominent notices stating that you modified > > * it, and giving a relevant date. > > * > > * This software is distributed "AS IS", with ABSOLUTELY NO WARRANTY. > > * See the GPL for specific language governing rights and limitations. > > * > > * The Original code is the giza plotting library. > > * > > * Contributor(s): > > * James Wetter <wetter.j> > > * Daniel Price <daniel.price> (main contact) > > */ > > which is GPLv3, probably GPL-3.0-only in SPDX terms since there is no “or > any later version” language, although it’s a slightly ambiguous notice. > However, there is an unusual extra bit here: > > > and the provision that this notice remains intact. > > which probably needs to be reviewed in > https://gitlab.com/fedora/legal/fedora-license-data/-/issues. > > From https://github.com/danieljprice/giza/pull/69, upstream seems to have > the impression that they can include GPL-licensed sources in a library and > still call it LGPL overall. I don’t find this convincing, and would probably > call it “LGPL-3.0-only AND GPL-3.0-only”, subject to review of the “and the > provision that this notice remains intact” language. I see nothing that > indicates a disjunctive choice of licenses, so I don’t think “LGPL-3.0-only > or GPL-3.0-only” is correct. > > The files src/*.pc.in have this license: > > > # This file is free software; as a special exception the author gives > > # unlimited permission to copy and/or distribute it, with or without > > # modifications, as long as this notice is preserved. > > # > > # This file is distributed in the hope that it will be useful, but > > # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the > > # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > which seems like a close enough match for FSFULLRWD, > https://spdx.org/licenses/FSFULLRWD.html. Since the .pc files generated from > these are installed in the -devel subpackage, the -devel subpackage should > have a corresponding license term, like: > > # .pc files are FSFULLRWD > License: LGPL-3.0-only AND GPL-3.0-only AND FSFULLRWD I have created a bug upstream asking the upstream developer Daniel t enter this discussion and I hope we can resolve any issues. (In reply to Phil Wyett from comment #21) > (In reply to Ben Beasley from comment #20) > > The license situation here is weird. > > > > COPYING is GPLv3 > > > > COPYING.LESSER is LGPLv3 > > > > ChangeLog has: > > > > > 2023-11-28 Daniel Price <daniel.price> > > > > > > * COPYING, LICENSE: changed license to LGPL3 > > > > And docs/index.html has: > > > > > Giza is currently distributed under the <a href="https://www.gnu.org/licenses/lgpl-3.0.html">LGPL license</a>. > > > > But all of the source file still have this header: > > > > > /* giza - a scientific plotting library built on cairo > > > * > > > * Copyright (c) 2010 James Wetter and Daniel Price > > > * Copyright (c) 2010-2012 Daniel Price > > > * > > > * This library is free software; and you are welcome to redistribute > > > * it under the terms of the GNU General Public License > > > * (GPL, see LICENSE file for details) and the provision that > > > * this notice remains intact. If you modify this file, please > > > * note section 5a) of the GPLv3 states that: > > > * > > > * a) The work must carry prominent notices stating that you modified > > > * it, and giving a relevant date. > > > * > > > * This software is distributed "AS IS", with ABSOLUTELY NO WARRANTY. > > > * See the GPL for specific language governing rights and limitations. > > > * > > > * The Original code is the giza plotting library. > > > * > > > * Contributor(s): > > > * James Wetter <wetter.j> > > > * Daniel Price <daniel.price> (main contact) > > > */ > > > > which is GPLv3, probably GPL-3.0-only in SPDX terms since there is no “or > > any later version” language, although it’s a slightly ambiguous notice. > > However, there is an unusual extra bit here: > > > > > and the provision that this notice remains intact. > > > > which probably needs to be reviewed in > > https://gitlab.com/fedora/legal/fedora-license-data/-/issues. > > > > From https://github.com/danieljprice/giza/pull/69, upstream seems to have > > the impression that they can include GPL-licensed sources in a library and > > still call it LGPL overall. I don’t find this convincing, and would probably > > call it “LGPL-3.0-only AND GPL-3.0-only”, subject to review of the “and the > > provision that this notice remains intact” language. I see nothing that > > indicates a disjunctive choice of licenses, so I don’t think “LGPL-3.0-only > > or GPL-3.0-only” is correct. > > > > The files src/*.pc.in have this license: > > > > > # This file is free software; as a special exception the author gives > > > # unlimited permission to copy and/or distribute it, with or without > > > # modifications, as long as this notice is preserved. > > > # > > > # This file is distributed in the hope that it will be useful, but > > > # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the > > > # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > which seems like a close enough match for FSFULLRWD, > > https://spdx.org/licenses/FSFULLRWD.html. Since the .pc files generated from > > these are installed in the -devel subpackage, the -devel subpackage should > > have a corresponding license term, like: > > > > # .pc files are FSFULLRWD > > License: LGPL-3.0-only AND GPL-3.0-only AND FSFULLRWD > > I have created a bug upstream asking the upstream developer Daniel t enter > this discussion and I hope we can resolve any issues. Link at: https://github.com/danieljprice/giza/issues/76 It looks like the submitter of the original review request is still working on it, https://bugzilla.redhat.com/show_bug.cgi?id=1187030#c66. Perhaps you could ask the reviewer in that bug what’s still required for approval. If the reviewer is no longer interested, you could even offer to take over the review. I hope that a way can be found to get this package across the “finish line,” one way or another. (In reply to Ben Beasley from comment #23) > It looks like the submitter of the original review request is still working > on it, https://bugzilla.redhat.com/show_bug.cgi?id=1187030#c66. Perhaps you > could ask the reviewer in that bug what’s still required for approval. If > the reviewer is no longer interested, you could even offer to take over the > review. > > I hope that a way can be found to get this package across the “finish line,” > one way or another. To be honest, after reading the reply from the other review, I shall be pushing forward with this submission. Reasons: * I plan to package splash that depends on giza. * EPEL is the end goal for both packages. * Requirement of high package quality. * Responsive maintenance. If the other developer wishes to co-maintain with me once in Fedora, I would be happy to discuss it. Regards Phil Spec URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza.spec SRPM URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza-1.5.0-1.el9.src.rpm Added 'check' section. I am hesitant to add a 'docs' package as there are a large amount of HTTP links. I will add one if requested and I will comment in the spec file with a link to the upstream bug report. Spec URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza.spec SRPM URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza-1.5.0-1.el9.src.rpm Change to LGPL-3-only as allowable by upstream. Copr build: https://copr.fedorainfracloud.org/coprs/build/9826891 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09826891-giza/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. Copr build: https://copr.fedorainfracloud.org/coprs/build/9826893 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09826893-giza/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. Spec URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza.spec SRPM URL: https://kathenas.fedorapeople.org/development/fedora/rawhide/for_review/giza-1.5.0-1.el9.src.rpm Added 'docs' package for now. Doing pull requests upstream to rectify in a future release. Regards Phil Created attachment 2115795 [details]
The .spec file difference from Copr build 9826893 to 9829842
Copr build: https://copr.fedorainfracloud.org/coprs/build/9829842 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2414840-giza/fedora-rawhide-x86_64/09829842-giza/fedora-review/review.txt Found issues: - Documentation size is 1044504 bytes in 45 files. Read more: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_documentation 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. I will close this for now. However, if in six months the oter giza submission has not made it into Fedora, I will open it again and expect the other to step aside. |