[Bug 475065] New: Review Request: givaro - C++ library for arithmetic and algebraic computations
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
Summary: Review Request: givaro - C++ library for arithmetic and algebraic computations
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Summary: Review Request: givaro - C++ library for arithmetic and algebraic computations Product: Fedora Version: rawhide Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: Package Review AssignedTo: nobody@fedoraproject.org ReportedBy: konrad@tylerc.org QAContact: extras-qa@fedoraproject.org CC: notting@redhat.com, fedora-package-review@redhat.com Estimated Hours: 0.0 Classification: Fedora
Spec URL: http://konradm.fedorapeople.org/fedora/SPECS/givaro.spec SRPM URL: http://konradm.fedorapeople.org/fedora/SRPMS/givaro-3.2.13-1.fc9.src.rpm Description: Givaro is a C++ library for arithmetic and algebraic computations. Its main features are implementations of the basic arithmetic of many mathematical entities: Primes fields, Extensions Fields, Finite Fields, Finite Rings, Polynomials, Algebraic numbers, Arbitrary precision integers and rationals (C++ wrappers over gmp) It also provides data-structures and templated classes for the manipulation of basic algebraic objects, such as vectors, matrices (dense, sparse, structured), univariate polynomials (and therefore recursive multivariate).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #1 from Conrad Meyer konrad@tylerc.org 2008-12-07 19:14:04 EDT --- New URLs: http://konradm.fedorapeople.org/fedora/SPECS/givaro.spec http://konradm.fedorapeople.org/fedora/SRPMS/givaro-3.2.13-2.fc9.src.rpm
Fixed a multilibs conflict (%{_includedir}/givaro-config.h).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #2 from Rex Dieter rdieter@math.unl.edu 2008-12-11 14:55:10 EDT --- Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=993866
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Conrad Meyer konrad@tylerc.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |476299
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #3 from Michael Schwendt bugs.michael@gmx.net 2009-02-11 06:44:16 EDT --- Just a comment, not a review: In your %files sections, you're advised to mark recursively included paths with a trailing slash. That makes it trivial to distinguish files and directories.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Alex Lancaster alexl@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |alexl@users.sourceforge.net AssignedTo|nobody@fedoraproject.org |alexl@users.sourceforge.net
--- Comment #4 from Alex Lancaster alexl@users.sourceforge.net 2009-02-19 04:30:08 EDT --- Can you update taking into account comment #3? and I'll review it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-review?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Alex Lancaster alexl@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|alexl@users.sourceforge.net |tibbs@math.uh.edu
--- Comment #5 from Alex Lancaster alexl@users.sourceforge.net 2009-03-09 23:13:44 EDT --- Reassigning to tibbs, given that he's set the review flag... ;)
tibbs: feel free to reassign back to me if you don't end up doing the review.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Jason Tibbitts tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|tibbs@math.uh.edu |alexl@users.sourceforge.net
--- Comment #6 from Jason Tibbitts tibbs@math.uh.edu 2009-03-10 00:32:05 EDT --- Erm, what? I'm just going through and setting review flags on the tickets where this seems to have been forgotten. (Basically, any review ticket that is assigned to someone.) Doing bugzilla cleanup doesn't mean that I actually want to do the review.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #7 from Alex Lancaster alexl@users.sourceforge.net 2009-03-10 01:25:37 EDT --- (In reply to comment #6)
Erm, what? I'm just going through and setting review flags on the tickets where this seems to have been forgotten. (Basically, any review ticket that is assigned to someone.) Doing bugzilla cleanup doesn't mean that I actually want to do the review.
OK, I had assigned it to me because I had intended to do the review at some point in the future, but I don't like to set the flag until I'm actually in the process of doing the review in case somebody else wants to take it if I don't get around to it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #8 from Conrad Meyer konrad@tylerc.org 2009-03-13 01:15:45 EDT --- Alex: I didn't respond to comment #3 because that is a preference thing I and I prefer it the way I have it. I would welcome a review.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
D Haley mycae@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mycae@yahoo.com
--- Comment #9 from D Haley mycae@yahoo.com 2009-05-30 23:05:39 EDT --- Here is my shot at this.
General comments: * givaro-makefile is a makefile and not an executable shell script. Remove the $!/bin/sh from it and move the file into %doc. *Why are the header files split into two sections (gmp++ and %{name})? This may be related to a later point I make about the configure script.
* MUST: rpmlint must be run on every package. The output should be posted in the review.[1]]
$ rpmlint ../SRPMS/givaro-3.2.13-2.fc10.src.rpm ../RPMS/i386/givaro-3.2.13-2.fc10.i386.rpm givaro.spec givaro.i386: W: shared-lib-calls-exit /usr/lib/libgivaro.so.0.0.2 exit@GLIBC_2.0 2 packages and 1 specfiles checked; 0 errors, 1 warnings.
Please inform upstream that it is not a good idea to do this, or patch this out (if possible). Offending file is: src/kernel/zpz/givzpz16table1.C: Line 46. Could be replaced with an exception or some kind of return code propagation. No idea what the easiest solution is. If upstream is informed that they shouldn't do this, and replies with something sensible, I don't see this as a block.
* MUST: The package must be named according to the Package Naming Guidelines . OK
* MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption. OK
* MUST: The package must meet the Packaging Guidelines . As far as I can see it is OK.
* MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines . OK * MUST: The License field in the package spec file must match the actual license.
* MUST: 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 must be included in %doc. OK: Please consider adding AUTHORS and ChangeLog (not a blocker) * MUST: The spec file must be written in American English. OK * MUST: The spec file for the package MUST be legible. OK * MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. FAIL: URL provided gives 404 error. (The requested URL /CASYS/LOGICIELS/givaro/givaro-3.2.13.tar.gz was not found on this server.) Please update URL or request upstream to not remove old tarballs. * MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. OK. Was able to compile. * MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line. N/A * MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense. OK. * MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden. OK * MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun. OK * MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. N/A * MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory. OK * MUST: A Fedora package must not list a file more than once in the spec file's %files listings. OK * MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example. Every %files section must include a %defattr(...) line. OK * MUST: Each package must have a %clean section, which contains rm -rf %{buildroot} (or $RPM_BUILD_ROOT). OK * MUST: Each package must consistently use macros. OK * MUST: The package must contain code, or permissable content. OK * MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity). OK, no large -doc files * MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present. OK. * MUST: Header files must be in a -devel package. OK * MUST: Static libraries must be in a -static package. OK * MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' (for directory ownership and usability). N/A * MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package. OK * MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} OK * MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built. OK * MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation. N/A * MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time. [24] OK * MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot} (or $RPM_BUILD_ROOT). [25] OK * MUST: All filenames in rpm packages must be valid UTF-8. [26] OK
* SHOULD: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. N/A * SHOULD: The description and summary sections in the package spec file should contain translations for supported Non-English languages, if available. N/A * SHOULD: The reviewer should test that the package builds in mock. Koji OK * SHOULD: The package should compile and build into binary rpms on all supported architectures. OK * SHOULD: The reviewer should test that the package functions as described. A package should not segfault instead of running, for example. Would it be better to patch the -config file to return /usr/include/givaro/ for --cflags rather than /usr/include ? Also it would be good if `givaro-config --cflags --libs` did not return endlines. (add -n to lines 58 and 62, also add leading space to linker & include flags). Finally this may be because of the gmp++ bit? The examples given on the website are a bit bogus -- requires some preprocessor that doesn't exist (404 again). Could you pack a trivial example that compiles into doc directory? * SHOULD: If scriptlets are used, those scriptlets must be sane. This is vague, and left up to the reviewers judgement to determine sanity. N/A * SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. OK * SHOULD: The placement of pkgconfig(.pc) files depends on their usecase, and this is usually for development purposes, so should be placed in a -devel pkg. A reasonable exception is that the main pkg itself is a devel tool not installed in a user runtime, e.g. gcc or gdb. N/A * SHOULD: If the package has file dependencies outside of /etc, /bin, /sbin, /usr/bin, or /usr/sbin consider requiring the package which provides the file instead of the file itself. OK
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #10 from Conrad Meyer konrad@tylerc.org 2009-05-30 23:41:12 EDT --- (In reply to comment #9)
Here is my shot at this.
General comments:
- givaro-makefile is a makefile and not an executable shell script. Remove the
$!/bin/sh from it and move the file into %doc.
Why should we put this in %doc? How is it remotely helpful?
*Why are the header files split into two sections (gmp++ and %{name})? This may be related to a later point I make about the configure script.
gmp++ is C++ bindings for gmp, I think.
- MUST: rpmlint must be run on every package. The output should be posted in
the review.[1]]
$ rpmlint ../SRPMS/givaro-3.2.13-2.fc10.src.rpm../RPMS/i386/givaro-3.2.13-2.fc10.i386.rpm givaro.spec givaro.i386: W: shared-lib-calls-exit /usr/lib/libgivaro.so.0.0.2 exit@GLIBC_2.0 2 packages and 1 specfiles checked; 0 errors, 1 warnings.
Please inform upstream that it is not a good idea to do this, or patch thisout (if possible). Offending file is: src/kernel/zpz/givzpz16table1.C: Line 46. Could be replaced with an exception or some kind of return code propagation. No idea what the easiest solution is. If upstream is informed that they shouldn't do this, and replies with something sensible, I don't see this as a block.
This is poor coding practice by upstream, but it isn't a blocker.
... Please consider adding AUTHORS and ChangeLog (not a blocker)
Ok (though this is not something I feel strongly about).
...
- MUST: The sources used to build the package must match the upstream source,
as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this. FAIL: URL provided gives 404 error. (The requested URL /CASYS/LOGICIELS/givaro/givaro-3.2.13.tar.gz was not found on this server.) Please update URL or request upstream to not remove old tarballs.
Again, upstream's fault...
...
- SHOULD: The reviewer should test that the package functions as described. A
package should not segfault instead of running, for example. Would it be better to patch the -config file to return /usr/include/givaro/ for --cflags rather than /usr/include ? Also it would be good if `givaro-config --cflags --libs` did not return endlines. (add -n to lines 58 and 62, also add leading space to linker & include flags). Finally this may be because of the gmp++ bit?
Something like that sounds necessary, yes.
The examples given on the website are a bit bogus -- requires somepreprocessor that doesn't exist (404 again). Could you pack a trivial example that compiles into doc directory?
Sorry, I'm not familiar with the use of this library, I'm just interested in getting SAGE (and dependencies) packaged and in Fedora.
...
Thanks for the review!
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #11 from D Haley mycae@yahoo.com 2009-05-31 01:00:28 EDT --- Some quick replies:
Why should we put this in %doc? How is it remotely helpful?
Maybe %doc is not quite the right place, but as far as I can see it is only an example makefile, hence documentation, or similar. It certainly should not be executable, nor should it be mislabelled as a shell script and definitely does not belong in /usr/bin.
This is poor coding practice by upstream, but it isn't a blocker.
Still, please try to contact upstream and if they reply put a copy of the relevant reply here. or state that they are non-responsive. I note that te
Again, upstream's fault...
This is a blocker. I cannot confirm the md5sum without this, which is required for review - we need to build against an upstream tarball somewhere, and agree on its location. http://www-lmc.imag.fr/CASYS/LOGICIELS/givaro/Downloads/ may have what we need.
Sorry, I'm not familiar with the use of this library, I'm just interested in getting SAGE (and dependencies) packaged and in Fedora.
I need some way to confirm that the system is working properly -- do you have a suggestion?
gmp++ is C++ bindings for gmp, I think
So is this two separate projects bundled into one? I am totally confused.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #12 from D Haley mycae@yahoo.com 2009-05-31 01:31:50 EDT --- Additional:
None of the source files have a proper GPL header, as documented in the GPL licence "How to Apply These Terms to Your New Programs". Please notify upstream. I am uncertain as to whether this is a blocker or not.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #13 from Conrad Meyer konrad@tylerc.org 2009-05-31 01:36:43 EDT --- (In reply to comment #11)
Some quick replies:
Why should we put this in %doc? How is it remotely helpful?
Maybe %doc is not quite the right place, but as far as I can see it is only an example makefile, hence documentation, or similar. It certainly should not be executable, nor should it be mislabelled as a shell script and definitely does not belong in /usr/bin.
Ah, sorry, didn't realize I was putting it in /usr/bin. I would prefer to not install it anywhere, I think.
This is poor coding practice by upstream, but it isn't a blocker.
Still, please try to contact upstream and if they reply put a copy of the relevant reply here. or state that they are non-responsive. I note that te
Sorry, I don't see any sort of contact info or bug tracking system on the home page.
Again, upstream's fault...
This is a blocker. I cannot confirm the md5sum without this, which is required for review - we need to build against an upstream tarball somewhere, and agree on its location. http://www-lmc.imag.fr/CASYS/LOGICIELS/givaro/Downloads/ may have what we need.
Eh, it won't be an issue *after* review though. I can update to the most recent tarball and you can verify against that md5sum (or, please, sha1sum).
Sorry, I'm not familiar with the use of this library, I'm just interested in getting SAGE (and dependencies) packaged and in Fedora.
I need some way to confirm that the system is working properly -- do you have a suggestion?
Maybe look at some of their examples on the webpage?
gmp++ is C++ bindings for gmp, I think
So is this two separate projects bundled into one? I am totally confused.
It's developed by the givaro folks, and they distribute it with givaro. I don't believe it's a library that anyone else is supposed to use (at least not yet). But you can try asking them if you want a better explanation.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #14 from Conrad Meyer konrad@tylerc.org 2009-05-31 01:37:26 EDT --- (In reply to comment #12)
Additional:
None of the source files have a proper GPL header, as documented in the GPL licence "How to Apply These Terms to Your New Programs". Please notify upstream. I am uncertain as to whether this is a blocker or not.
Upstream doesn't have any sort of bugtracking system or email contact I can find (other than directly emailing all six developers).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #15 from D Haley mycae@yahoo.com 2009-05-31 05:24:14 EDT --- I recommend emailing the three lead devs, probably in the one email. Their addresses are on each of their profile sites. I'm sure they would be happy to help, considering the time it would have taken to write their system. Also their input here would clear up a few matters relatively quickly.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #16 from D Haley mycae@yahoo.com 2009-07-26 05:05:15 EDT --- ping?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #17 from Conrad Meyer konrad@tylerc.org 2009-07-26 05:42:17 EDT --- Pong. Haven't had time :(.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #18 from D Haley mycae@yahoo.com 2009-08-22 23:04:23 EDT --- Hi Conrad,
I have notified upstream via email wrt. to the exit call. They now provide versioned tarballs at the following location:
http://www-lmc.imag.fr/CASYS/LOGICIELS/givaro/Downloads/:
==== Dear Prof. Roch and Gautier,
Recently givaro has been submitted for package review[1] for inclusion in the Fedora linux repositories. However small error was noticed during an automated source-code check. As a requirement of packaging, upstream (you) must be notified of this error.
File src/kernel/zpz/givzpz16table1.C is included in a shared library (libgivaro.so), and Line 46 makes a call to the exit() function.
Calling exit() in a shared library results in incorrect de-allocation of system resources.
If it is possible to update this file in the next version of givaro to not use exit(), this would be most helpful.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=475065
Kind Regards.
D. Haley
===
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #19 from Conrad Meyer konrad@tylerc.org 2009-08-22 23:08:49 EDT --- Hi, I also no longer have time for this package. If you would like to take it, you are quite welcome. Otherwise, it should be closed.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #20 from D Haley mycae@yahoo.com 2009-08-23 00:32:59 EDT --- I'm happy to try to push this through
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #21 from Conrad Meyer konrad@tylerc.org 2009-08-23 00:38:54 EDT --- Ok, sounds good!
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #22 from D Haley mycae@yahoo.com 2009-08-23 01:34:12 EDT --- SPEC URL: http://dhd.selfip.com/427e/givaro.spec SRPM URL: http://dhd.selfip.com/427e/givaro-3.2.15-0.1.rc1.fc10.src.rpm
F10: http://koji.fedoraproject.org/koji/taskinfo?taskID=1626651 F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1626660
rpmlint: $ rpmlint `cat tmp` givaro.i386: W: shared-lib-calls-exit /usr/lib/libgivaro.so.0.0.4 exit@GLIBC_2.0 givaro-devel.i386: W: no-documentation givaro-devel.i386: E: non-executable-script /usr/share/givaro/givaro-makefile 0644 givaro-static.i386: W: no-documentation 5 packages and 0 specfiles checked; 1 errors, 3 warnings. $ cat tmp /home/makerpm/rpmbuild/SRPMS/givaro-3.2.15-0.1.rc1.fc10.src.rpm /home/makerpm/rpmbuild/RPMS/i386/givaro-3.2.15-0.1.rc1.fc10.i386.rpm /home/makerpm/rpmbuild/RPMS/i386/givaro-devel-3.2.15-0.1.rc1.fc10.i386.rpm /home/makerpm/rpmbuild/RPMS/i386/givaro-static-3.2.15-0.1.rc1.fc10.i386.rpm /home/makerpm/rpmbuild/RPMS/i386/givaro-debuginfo-3.2.15-0.1.rc1.fc10.i386.rpm
Notes: *Upstream has been notified about GPL headers, and as above, exit() usage *Tarball has been re-downloaded from new download area on givaro website *makefile has been placed into %{_datadir}/%{name}/ *Trailing slashes have been added *givaro-config.in has been patched to produce correct output in case of multiple flags
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #23 from D Haley mycae@yahoo.com 2009-08-23 01:39:35 EDT --- Whoops. Sorry for the noise, but I have fixed that E, with "sed -i 's|#! /bin/sh||' $RPM_BUILD_ROOT%{_datadir}/%{name}/givaro-makefile" in my current spec.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
D Haley mycae@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Martin Gieseking martin.gieseking@uos.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.gieseking@uos.de
--- Comment #24 from Martin Gieseking martin.gieseking@uos.de 2009-09-08 04:20:41 EDT --- Since you've already done a good job bringing this package in shape, there isn't much left to do. If nobody else wants to do the re-review, I can do it later today. However, I'm not quite happy with the call of exit() in a shared library. This is simply bad style and should be avoided by all means. I'm not sure about Fedora's policy about this, though. Here is a patch that replaces the call of exit() by throwing an exception: http://mgieseki.fedorapeople.org/givaro/givaro-exit.patch
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Jussi Lehtola jussi.lehtola@iki.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jussi.lehtola@iki.fi
--- Comment #25 from Jussi Lehtola jussi.lehtola@iki.fi 2009-09-08 05:21:23 EDT --- (In reply to comment #24)
Since you've already done a good job bringing this package in shape, there isn't much left to do. If nobody else wants to do the re-review, I can do it later today. However, I'm not quite happy with the call of exit() in a shared library. This is simply bad style and should be avoided by all means. I'm not sure about Fedora's policy about this, though. Here is a patch that replaces the call of exit() by throwing an exception: http://mgieseki.fedorapeople.org/givaro/givaro-exit.patch
Calling exit() is not forbidden (in fact it is quite common in scientific packages), so you can omit the rpmlint warning. You should not apply any patches that make functional changes, since that will break compatibility with upstream. You can ask upstream to make the change, though...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #26 from Martin Gieseking martin.gieseking@uos.de 2009-09-08 05:52:24 EDT --- Actually, throwing an exception doesn't change the code functionality in a significant way. It still stops the application if it's not caught but provides better memory handling. To me, using exit() in shared libraries is pretty amateurish style, especially in combination with C++. I also haven't seen it in any of the scientific packages I use. But anyway, if it's OK to leave it in the package, I can live with it.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Martin Gieseking martin.gieseking@uos.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|alexl@users.sourceforge.net |martin.gieseking@uos.de Flag|fedora-review? |fedora-review+
--- Comment #27 from Martin Gieseking martin.gieseking@uos.de 2009-09-08 14:04:09 EDT --- Here comes the review.
$ rpmlint /var/lib/mock/fedora-rawhide-x86_64/result/*.rpm givaro.x86_64: W: shared-lib-calls-exit /usr/lib64/libgivaro.so.0.0.4 exit@GLIBC_2.2.5 givaro-devel.x86_64: W: no-documentation givaro-devel.x86_64: E: non-executable-script /usr/share/givaro/givaro-makefile 0644 /bin/sh givaro-static.x86_64: W: no-documentation 5 packages and 0 specfiles checked; 1 errors, 3 warnings.
- call of exit() can be ignored according to comment #25 - missing docs in -devel and -static is OK - #!/bin/sh in makefile already removed according to comment #23
--------------------------------- keys used in following checklist:
[+] OK [.] OK, not applicable [X] needs work ---------------------------------
[+] MUST: The package must be named according to the Package Naming Guidelines. [+] MUST: The spec file name must match the base package %{name}. [+] MUST: The package must meet the Packaging Guidelines. [+] MUST: The package must be licensed with a Fedora approved license. - GPLv2 boilerplates missing (upstream notified)
[+] MUST: The License field in the package spec file must match the actual license. [+] MUST: files containing the text of the license(s) must be included in %doc. - COPYING added to %doc of base package
[+] MUST: The spec file must be written in American English. [+] MUST: The spec file for the package MUST be legible. [+] MUST: The sources used to build the package must match the upstream source. - md5 hash is f0b754ee54bcac0e866f2979b57393ba
[+] MUST: The package MUST successfully compile and build into binary rpms. - builds in koji https://koji.fedoraproject.org/koji/taskinfo?taskID=1662967
[.] MUST: If the package does not successfully compile, ... [+] MUST: All build dependencies must be listed in BuildRequires [.] MUST: The spec file MUST handle locales properly. - no locales
[+] MUST: Packages containing .so files must call ldconfig in %post and %postun. - base package contains libgivaro.so.0.0.4 - ldconfig called in %post and %postun
[.] MUST: If the package is designed to be relocatable, ... - package not relocatable
[+] MUST: A package must own all directories that it creates. [+] MUST: A package must not list a file more than once in %files. [+] MUST: Permissions on files must be set properly. - givaro-makefile contains #!/bin/sh that must be removed - already done according to comment #23
[+] MUST: %clean section must contain rm -rf %{buildroot}. [+] MUST: Each package must consistently use macros. [+] MUST: The package must contain code, or permissable content. [.] MUST: Large documentation files must go in a -doc subpackage. - no large docs
[+] MUST: Files in %doc must not affect the runtime of the application. [+] MUST: Header files must be in a -devel package. [+] MUST: Static libraries must be in a -static package. - libgivaro.a
[.] MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig' - no .pc files
[+] MUST: .so without suffix must go in a -devel package. - libgivaro.so
[+] MUST: devel packages must require %{name} = %{version}-%{release} [+] MUST: Packages must NOT contain any .la libtool archives - .la file removed in %install
[.] MUST: Packages containing GUI applications must include a %{name}.desktop file - no GUI
[+] MUST: Packages must not own files or directories already owned by other packages. [+] MUST: At the beginning of %install, each package MUST run rm -rf %{buildroot}. [+] MUST: All filenames in rpm packages must be valid UTF-8.
[+] SHOULD: The reviewer should test that the package builds in mock. - builds in mock
[+] SHOULD: The package should compile and build into binary rpms on all supported architectures. [+] SHOULD: The reviewer should test that the package functions as described. - I tested some of the functions provided by the library and they worked as expected - givaro-config prints the correct flags
[+] SHOULD: If scriptlets are used, those scriptlets must be sane. call of ldconfig in %post and %postun
[+] SHOULD: Usually, subpackages other than devel should require the base package using a fully versioned dependency. - subpackage -static requires base and -devel package - Requires: %{name} = %{version}-%{release} is redundant
------------------------ The package is APPROVED. ------------------------
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #28 from Jussi Lehtola jussi.lehtola@iki.fi 2009-09-08 14:21:41 EDT --- Umh..
src/kernel/zpz/StaticElement.h states it is under LGPLv2+, the rest of the files just say "see the copyright file" which doesn't exist. There is a COPYING that contains the GPLv3 license, thus the license tag should read GPL+.
https://fedoraproject.org/wiki/Licensing/FAQ#How_do_I_figure_out_what_versio...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #29 from D Haley mycae@yahoo.com 2009-09-12 02:26:34 EDT --- SPEC URL : http://dhd.selfip.com/427e/givaro-2.rc1.spec SRPM URL : http://dhd.selfip.com/427e/givaro-3.2.15-0.2.rc1.fc10.src.rpm
F10:http://koji.fedoraproject.org/koji/taskinfo?taskID=1672622 F11: http://koji.fedoraproject.org/koji/taskinfo?taskID=1672627
$ rpmlint `cat tmp | awk '{print $2}'` givaro.i386: W: shared-lib-calls-exit /usr/lib/libgivaro.so.0.0.4 exit@GLIBC_2.0 givaro-devel.i386: W: no-documentation givaro-static.i386: W: no-documentation 5 packages and 0 specfiles checked; 0 errors, 3 warnings. $ cat tmp Wrote: /home/makerpm/rpmbuild/SRPMS/givaro-3.2.15-0.2.rc1.fc10.src.rpm Wrote: /home/makerpm/rpmbuild/RPMS/i386/givaro-3.2.15-0.2.rc1.fc10.i386.rpm Wrote: /home/makerpm/rpmbuild/RPMS/i386/givaro-devel-3.2.15-0.2.rc1.fc10.i386.rpm Wrote: /home/makerpm/rpmbuild/RPMS/i386/givaro-static-3.2.15-0.2.rc1.fc10.i386.rpm Wrote: /home/makerpm/rpmbuild/RPMS/i386/givaro-debuginfo-3.2.15-0.2.rc1.fc10.i386.rpm
changelog: * Sun Sep 12 2009 D Haley <mycae(a!t)yahoo.com> - 3.2.15-0.2.rc1 - Change to GPL+ from GPL2 per bugzilla comment
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #30 from Martin Gieseking martin.gieseking@uos.de 2009-09-12 03:07:14 EDT --- Sorry for the overlooked license ambiguity. Since this has been fixed, everything seems to be fine now.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
D Haley mycae@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs?
--- Comment #31 from D Haley mycae@yahoo.com 2009-09-12 04:01:54 EDT --- New Package CVS Request ======================= Package Name: givaro Short Description: C++ library for arithmetic and algebraic computations Owners: mycae Branches: F-10 F-11 EL-5 InitialCC: baz
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Kevin Fenzi kevin@tummy.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+
--- Comment #32 from Kevin Fenzi kevin@tummy.com 2009-09-14 00:56:30 EDT --- cvs done.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #33 from Fedora Update System updates@fedoraproject.org 2009-09-14 06:30:55 EDT --- givaro-3.2.15-0.2.rc1.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/givaro-3.2.15-0.2.rc1.fc11
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #34 from Fedora Update System updates@fedoraproject.org 2009-09-14 06:31:03 EDT --- givaro-3.2.15-0.2.rc1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/givaro-3.2.15-0.2.rc1.fc10
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |ON_QA
--- Comment #35 from Fedora Update System updates@fedoraproject.org 2009-09-15 03:43:21 EDT --- givaro-3.2.15-0.2.rc1.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update givaro'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-9573
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #36 from Fedora Update System updates@fedoraproject.org 2009-09-15 03:44:24 EDT --- givaro-3.2.15-0.2.rc1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update givaro'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9580
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #37 from Fedora Update System updates@fedoraproject.org 2009-10-03 14:55:09 EDT --- givaro-3.2.15-0.2.rc1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ON_QA |CLOSED Fixed In Version| |3.2.15-0.2.rc1.fc10 Resolution| |ERRATA
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
--- Comment #38 from Fedora Update System updates@fedoraproject.org 2009-10-03 15:06:06 EDT --- givaro-3.2.15-0.2.rc1.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=475065
Fedora Update System updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version|3.2.15-0.2.rc1.fc10 |3.2.15-0.2.rc1.fc11
package-review@lists.fedoraproject.org
-
Red Hat Bugzilla