Bug 225783 - Merge Review: gdb
Merge Review: gdb
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Matěj Cepl
Fedora Package Reviews List
:
Depends On: 235753
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-31 13:41 EST by Nobody's working on this, feel free to take it
Modified: 2012-06-15 12:47 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-03-10 16:19:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
panemade: fedora‑review+


Attachments (Terms of Use)
suggested fix for License: field (739 bytes, patch)
2010-03-09 10:52 EST, Matěj Cepl
no flags Details | Diff

  None (edit)
Description Nobody's working on this, feel free to take it 2007-01-31 13:41:27 EST
Fedora Merge Review: gdb

http://cvs.fedora.redhat.com/viewcvs/devel/gdb/
Initial Owner: jkratoch@redhat.com
Comment 1 Ralf Corsepius 2007-04-07 00:00:49 EDT
This package will need a lot of love ;)


Some obious issues:

1. When running configure
...
checking for libexpat... no
configure: WARNING: expat is missing or unusable; some features may be
disabled.
=> Missing BR: libexpat-devel

2. %makeinstall
%makeinstall should not be used if a package supports make DESTDIR=.. install

Old gdb didn't, but modern ones do (AFAICT, gdb-6.6 does).

3. The way, the infos are being installed.
I don't see much wrong with the way you are doing it, but ... I'd recommend to
convert this to the way most packages handle it nowadays.

4. Prereq: info
This construct is being frowned upon.

It should be replaced with 
Requires(pre): /sbin/install-info
Requires(post): /sbin/install-info

5. running the tests should be put into a separate %check section.

6. The rationale for the "version-reporting paragraph" escapes me.
I recommend to remove it.

7. Package doesn't honor RPM_OPT_FLAGS:
gdb-6.3-warnings-20050317.patch:+-Wp,-U_FORTIFY_SOURCE"


When running the testsuite:
...
Running ../../../gdb/testsuite/gdb.base/auxv.exp ...
WARNING: can't generate a core file - core tests suppressed - check ulimit
-c
=> You probably should set ulimit -c unlimited before running the tests

...
Running ../../../gdb/testsuite/gdb.base/prelink.exp ...
sh: prelink: command not found
I was running rpmbuild as ordinary user, who didn't have /usr/sbin in $PATH


Finally: Running the testsuite hangs when building this package on FC6.
Comment 2 Jan Kratochvil 2007-04-11 10:12:57 EDT
Thanks for the review.  As I still wait on one review listing here the
preliminary changelog entry going to be committed soon.

1.+2.+3.+4.+5.+6.+7.+ulimit+prelink: All implemented.

6. It is useful but there are now stored all the installed packages versions
   in the logs from mock.

Your note about build hang on FC6 is not reproducible - WORKSFORME.  If you
target rebuilds in mock, it may be a DUPLICATE of the still pending Bug 221351.


* Wed Apr 11 2007 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.6-9
- Package review, analysed by Ralf Corsepius (BZ 225783).
 - Fix prelink(8) testcase for non-root $PATH missing `/usr/sbin' (BZ 225783).
 - Fix debugging GDB itself - the compiled in source files paths (BZ 225783).
 - Fix XML support - the build was missing `expat-devel'.
 - Updated `info' spec file support.
 - Building now with the standard Fedora code protections - _FORTIFY_SOURCE=2.
 - Use multiple CPUs for the build (%{?_smp_mflags}).
 - Separate testsuite run to its %check section.
 - Fix (remove) non-ASCII spec file characters.
 - Remove system tools versions dumping - already present in mock build logs.
 - BuildRequires now `libunwind-devel' instead of the former `libunwind'.
 - Use the runtime variant of `libunwind-ARCH.so.7' rather than the `.so' one.
Comment 4 Ralf Corsepius 2007-04-11 22:38:56 EDT
Any updated *.spec or src.rpm available?

http://cvs.fedora.redhat.com/viewcvs/devel/gdb/
still is at *-8
Comment 5 Jan Kratochvil 2007-04-12 16:13:23 EDT
(In reply to comment #4)
> http://cvs.fedora.redhat.com/viewcvs/devel/gdb/
> still is at *-8

as I wrote in Comment 2 I could not commit it so far, wait a moment, please.
Comment 6 Ralf Corsepius 2007-04-18 00:55:33 EDT
Ping? Still no fixed spec nor src.rpm available.

If this was a community Review Request, I'd now start a one week timer after
which I'd close this PR as FAILED due to submitter disinterest/non-cooperativeness.
Comment 7 Stepan Kasal 2007-04-20 11:15:54 EDT
A formalistic comment:
this bug should be assigned to a reviewer (who must be != pkg owner), which
would at the end guarantee that the pkg passed the review.

So, if I understand the process correctly, Ralf should have assigned the bug to
himself when posting comment #1.

(Later on, Jan has assigned the bug to himself, which is a common mistake among
RH developers coming from Fedora Core.)
Comment 8 Ralf Corsepius 2007-04-20 11:32:03 EDT
(In reply to comment #7)
> A formalistic comment:
> So, if I understand the process correctly, Ralf should have assigned the bug to
> himself when posting comment #1.
I am not formally reviewing this package, I am just commenting.

Jan has had his chances to make me review this package, but his non-colaboration
has caused my interest in continuing this review to NULL.
Comment 9 Stepan Kasal 2007-04-20 12:14:35 EDT
(In reply to comment #8)
> I am not formally reviewing this package, I am just commenting.

OK, assigning it back to nobody, until a reviewer is found.
Comment 10 Ralf Corsepius 2007-04-21 00:13:38 EDT
(In reply to comment #9)
> OK, assigning it back to nobody, until a reviewer is found.

I really hate having to say this, but I am wondering what kind of clue-stick it
takes to hit @RH's with until they finally understand how reviews are supposed
to work:

You will not be able to find any, because this package's sources are not 
available. RH's cvs still is at *-8, and nobody did provide an URL where the
current *.src.rpm can be downloaded.
Comment 11 Jan Kratochvil 2007-04-24 12:05:13 EDT
All the issues described in this Bug so far have been committed now to CVS as:
* Tue Apr 24 2007 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.6-11
- Package review, analysed by Ralf Corsepius (BZ 225783).
 - Fix prelink(8) testcase for non-root $PATH missing `/usr/sbin' (BZ 225783).
 - Fix debugging GDB itself - the compiled in source files paths (BZ 225783).
 - Fix harmless GCORE stack buffer overflow, by _FORTIFY_SOURCE=2 (BZ 235753).
 - Fix XML support - the build was missing `expat-devel'.
 - Updated the `info' files handling by the spec file.
 - Building now with the standard Fedora code protections - _FORTIFY_SOURCE=2.
 - Use multiple CPUs for the build (%{?_smp_mflags}).
 - Separate testsuite run to its %check section.
 - Fix (remove) non-ASCII spec file characters.
 - Remove system tools versions dumping - already present in mock build logs.

Sorry but `gdb-6.6-bz235753-gcore-strings-overflow.patch' had some potential
security risk and commenting anything more here would disclose it.
According all the opinions the bug has fortunately no security risk.

Thanks for the review, it was very helpful for the real packaging improvements
including one real crash fix etc.

As I am not aware of more review issues may this Bug be closed?
Or is anyone else going to comment?
(Mistakes in the implementation of the fixes above should REOPEN this Bug.)
Comment 12 Stepan Kasal 2007-04-25 04:27:58 EDT
According to http://fedoraproject.org/wiki/PackageReviewProcess you are supposed
to set flag fedora-review to "?" and wait.  It's not your responsibility to look
for a reviewer, just let it rot here.
Comment 13 Stepan Kasal 2007-04-25 04:36:56 EDT
(In reply to comment #12)
> to set flag fedora-review to "?" and wait.

No, my mistake.  The flag should be " ", not "?".
I apologize that I'm messing with your bug.

So you are done now and should patiently wait.

Comment 14 Ralf Corsepius 2007-04-25 04:51:13 EDT
jan.kratochvil@redhat.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |CLOSED
         Resolution|                            |DEFERRED

So we can assume gdb not to be present in FC7?

Or is this an attempt of @RH's to demonstrate their ability to overrule the
community?



Comment 15 Robert Scheck 2007-04-25 04:58:19 EDT
Ralf, I think this was a mistake, because the report was opened again one 
minute after it got closed.
Comment 16 Ralf Corsepius 2007-04-25 05:04:32 EDT
(In reply to comment #15)
> Ralf, I think this was a mistake, because the report was opened again one 
> minute after it got closed.

I am more than willing to believe this, but ... given how this review and other
"merge reviews" (did not) proceeded doesn't give me much reason for trust.
Comment 17 Jan Kratochvil 2007-04-25 05:15:02 EDT
(In reply to comment #15)
> Ralf, I think this was a mistake, because the report was opened again one 
> minute after it got closed.

It was an attempt to get this Bug into the state NEW as formerly reopened Bugs
went to the state NEW (and they went to REOPENED state even before).
Unfortunately I found out the Bugzilla behavior changed.
It was being done to reinsert this Bug back to the list referenced from
http://fedoraproject.org/wiki/PackageReviewProcess by its link
https://bugzilla.redhat.com/bugzilla/buglist.cgi?product=Fedora+Extras&component=Package+Review&bug_status=NEW
but unfortunately one would have to CLOSE this Bug completely and open a new one
to reach its NEW state again.

(In reply to comment #16)
> I am more than willing to believe this, but ... given how this review
...
> (did not) proceeded

The issues listed in Comment 1 were implemented in about 2 days - is it such a
tragical response time? During the implementation there was found one possible
security hole which was being requested to be evaluated by security response
entities but unfortunately this step took too long - it was not a real security
threat but noone was willing to give a certification for it.

It is a security policy to never disclose any security flaws until the fix is
known to protect the users of the product.  So far I am glad to be the White Hat
- not the Black Hat (relationship to Red Hat is just a coincidence here :-) ).
Comment 18 Stepan Kasal 2007-04-25 05:39:04 EDT
rpmlint v. 0.80 is not silent on gdb src.rpm.
(rpmlint on the binary rpm is OK.)

Jan, your advice is needed for the not-applied-patch issue.
The rest are just a formal issues; is it OK with you if I fix them?

W: gdb patch-not-applied Patch197: gdb-6.5-bz198365-IPv6.patch
A patch is included in your package but was not applied.

W: gdb summary-ended-with-dot A GNU source-level debugger for C, C++, Java and
other languages.
Summary ends with a dot.

W: gdb unversioned-explicit-obsoletes gdb64
The specfile contains an unversioned Obsoletes: token, which will match all
older, equal and newer versions of the obsoleted thing.  This may cause update
problems, restrict future package/provides naming, and may match something it
was originally not inteded to match -- make the Obsoletes versioned if
possible.

E: gdb hardcoded-library-path in /usr/lib/libc.so
A library path is hardcoded to one of the following paths: /lib,
/usr/lib. It should be replaced by something like /%{_lib} or %{_libdir}.

W: gdb macro-in-%changelog check
W: gdb macro-in-%changelog p
Macros are expanded in %changelog too, which can in unfortunate cases lead
to the package not building at all, or other subtle unexpected conditions that
affect the build.  Even when that doesn't happen, the expansion results in
possibly "rewriting history" on subsequent package revisions and generally
odd entries eg. in source rpms, which is rarely wanted.  Avoid use of macros
in %changelog altogether, or use two '%'s to escape them, like '%%foo'.

W: gdb mixed-use-of-spaces-and-tabs (spaces: line 530, tab: line 517)
The specfile mixes use of spaces and tabs for indentation, which is a
cosmetic annoyance.  Use either spaces or tabs for indentation, not both.
Comment 19 Jan Kratochvil 2007-04-25 15:34:11 EDT
(In reply to comment #18)
> W: gdb patch-not-applied Patch197: gdb-6.5-bz198365-IPv6.patch
> A patch is included in your package but was not applied.

It should be removed; it can be added again after it gets accepted upstream.
Comment 20 Jan Kratochvil 2007-07-23 18:23:46 EDT
Committed the last change I am aware of:

* Mon Jul 23 2007 Jan Kratochvil <jan.kratochvil@redhat.com> - 6.6-21
- .spec file updates to mostly pass RPMLINT - Fedora merge review (BZ 225783).

There is still the RPMLINT message:
E: gdb hardcoded-library-path in /lib/libc.so
but not aware of its solution.
GDB needs both biarch glibcs for its build-time testsuite.
Specifying them directly (glibc.i386+glibc.x86_64 || glibc.ppc+glibc.ppc64) is
not possible as some of the build farms use glibc32.x86_64 to be purely x86_64.
The %{eprefix} etc. is not usable for root-based /lib.
Comment 21 Jan Kratochvil 2010-03-03 16:25:12 EST
(In reply to comment #20)
> There is still the RPMLINT message:
> E: gdb hardcoded-library-path in /lib/libc.so
> but not aware of its solution.
> GDB needs both biarch glibcs for its build-time testsuite.
> Specifying them directly (glibc.i386+glibc.x86_64 || glibc.ppc+glibc.ppc64) is
> not possible as some of the build farms use glibc32.x86_64 to be purely x86_64.
> The %{eprefix} etc. is not usable for root-based /lib.    

This has been fixed in gdb-7.0.1-22.fc12:
  - Replace all hardcoded-library-path by variants of %%{_isa}.

Requesting to get the review CLOSED if there are no other objections.
Comment 22 Matěj Cepl 2010-03-08 10:22:32 EST
Couple of warnings (URL we dealt with over IRC, other ones should be either fixed or at least explained somehow in SPEC).

johanka:F-13$ rpmlint -i gdb-7.0.90.20100306-18.fc13.src.rpm 
gdb.src: W: strange-permission gdb-6.8-bz457187-largefile-test.patch 0775L
A file that you listed to include in your package has strange permissions.
Usually, a file should have 0644 permissions.

---------
I may not understand the comment correctly. Is this explained in the spec file?

gdb.src: W: patch-not-applied Patch328: gdb-6.8-inlining-by-name.patch
A patch is included in your package but was not applied. Refer to the patches
documentation to see what's wrong.

gdb.src: W: patch-not-applied Patch350: gdb-6.8-inlining-addon.patch
A patch is included in your package but was not applied. Refer to the patches
documentation to see what's wrong.

-------------
just warning, explained in SPEC ... OK

gdb.src: W: invalid-url Source4: libstdc++-v3-python-r155978.tar.bz2
The value should be a valid, public HTTP, HTTPS, or FTP URL.

---------------
we talked about it

gdb.src: W: invalid-url Source0: ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.0.90.20100306.tar.bz2 <urlopen error ftp error: [Errno ftp error] 550 gdb-7.0.90.20100306.tar.bz2: No such file or directory>
The value should be a valid, public HTTP, HTTPS, or FTP URL.

-----------
just break the lines, typographical nonsense.

gdb-gdbserver.x86_64: E: description-line-too-long C This package provides a program that allows you to run GDB on a different machine than the one which is running the program being debugged.

------------
and many others ... quite clearly a bug in rpmlint. Don't bother.

Please, fix these and we can deal with the proper packaging review then.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo
Comment 23 Matěj Cepl 2010-03-08 10:24:09 EST
(In reply to comment #22)
> and many others ... quite clearly a bug in rpmlint. Don't bother.
> 
> Please, fix these and we can deal with the proper packaging review then.
> 
> gdb.x86_64: E: postin-without-ldconfig
> /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo    

Sorry, it should be:

and many others ... quite clearly a bug in rpmlint. Don't bother.

gdb.x86_64: E: postin-without-ldconfig
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo    

------------------

Please, fix these and we can deal with the proper packaging review then.

i.e.,don't bother with broken rpmlint.
Comment 24 Jan Kratochvil 2010-03-08 10:37:27 EST
(In reply to comment #22)
> gdb.src: W: strange-permission gdb-6.8-bz457187-largefile-test.patch 0775L
> A file that you listed to include in your package has strange permissions.
> Usually, a file should have 0644 permissions.

No permissions to fix it and no luck requesting the change:
  https://fedorahosted.org/fedora-infrastructure/ticket/1916


> I may not understand the comment correctly. Is this explained in the spec file?
> 
> gdb.src: W: patch-not-applied Patch328: gdb-6.8-inlining-by-name.patch
> A patch is included in your package but was not applied. Refer to the patches
> documentation to see what's wrong.
> 
> gdb.src: W: patch-not-applied Patch350: gdb-6.8-inlining-addon.patch
> A patch is included in your package but was not applied. Refer to the patches
> documentation to see what's wrong.

There was for it:
# Disable break-by-name on inlined functions due to a regression on parameters
# of inlined functions falsely <optimized out> (BZ 556975 Comment 8).
# Disable addon (finish) due to inline-cmds.exp: up from outer_inline2 assert.

I will reapply the patches in different form in the future, OK, I will remove them now as there are zillions of other patches in similar state.


> gdb.src: W: invalid-url Source0:
> ftp://sourceware.org/pub/gdb/snapshots/branch/gdb-7.0.90.20100306.tar.bz2
> <urlopen error ftp error: [Errno ftp error] 550 gdb-7.0.90.20100306.tar.bz2:
> No such file or directory>
> The value should be a valid, public HTTP, HTTPS, or FTP URL.

Fixed in: gdb-7.0.90.20100306-19.fc13


> just break the lines, typographical nonsense.
> 
> gdb-gdbserver.x86_64: E: description-line-too-long C This package provides a
> program that allows you to run GDB on a different machine than the one which
> is running the program being debugged.

Fixed.


> and many others ... quite clearly a bug in rpmlint. Don't bother.
> 
> Please, fix these and we can deal with the proper packaging review then.
> 
> gdb.x86_64: E: postin-without-ldconfig
> /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo    

Ignored.


Thanks, current state: gdb-7.0.90.20100306-20.fc13
Comment 25 Matěj Cepl 2010-03-09 10:51:20 EST
+ MUST: rpmlint must be run on every package. The output should be posted in
the review
Sources used when checking (from Fedora CVS for F-13):

johanka:F-13$ md5sum gdb.spec gdb-7.0.90.20100306.tar.bz2
b0dadd6e0bf07f2d73ce87c53538edcc  gdb.spec
9d52988c5b2a2085e0ee5df89393e5a0  gdb-7.0.90.20100306.tar.bz2
(plus 117 patches for which I haven't calculated md5sums)

johanka:F-13$ rpmlint -i gdb-7.0.90.20100306-20.fc13.src.rpm x86_64/gdb-*.rpm
gdb.src: W: strange-permission gdb-6.8-bz457187-largefile-test.patch 0775L
A file that you listed to include in your package has strange permissions.
Usually, a file should have 0644 permissions.

gdb.src: W: invalid-url Source4: libstdc++-v3-python-r155978.tar.bz2
The value should be a valid, public HTTP, HTTPS, or FTP URL.

gdb.src: W: invalid-url Source0: gdb-7.0.90.20100306.tar.bz2
The value should be a valid, public HTTP, HTTPS, or FTP URL.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo
This package contains a library and its %post scriptlet doesn't call ldconfig.

gdb.x86_64: E: library-without-ldconfig-postun /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo
This package contains a library and provides no %postun scriptlet containing a
call to ldconfig.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyc
This package contains a library and its %post scriptlet doesn't call ldconfig.

gdb.x86_64: E: library-without-ldconfig-postun /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyc
This package contains a library and provides no %postun scriptlet containing a
call to ldconfig.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyo
This package contains a library and its %post scriptlet doesn't call ldconfig.

gdb.x86_64: E: library-without-ldconfig-postun /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyo
This package contains a library and provides no %postun scriptlet containing a
call to ldconfig.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyc
This package contains a library and its %post scriptlet doesn't call ldconfig.

gdb.x86_64: E: library-without-ldconfig-postun /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyc
This package contains a library and provides no %postun scriptlet containing a
call to ldconfig.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.py
This package contains a library and its %post scriptlet doesn't call ldconfig.

gdb.x86_64: E: library-without-ldconfig-postun /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.py
This package contains a library and provides no %postun scriptlet containing a
call to ldconfig.

gdb.x86_64: E: postin-without-ldconfig /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.py
This package contains a library and its %post scriptlet doesn't call ldconfig.

gdb.x86_64: E: library-without-ldconfig-postun /usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.py
This package contains a library and provides no %postun scriptlet containing a
call to ldconfig.

4 packages and 0 specfiles checked; 12 errors, 3 warnings.
johanka:F-13$ 

(for explanation of the above warnings see the previous comments here)

NO PROBLEM HERE

+ MUST: package 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 .
Package far exceeds level of the Packaging Guidelines. (I would probably make pearls like 
! find -name "*.rej" # Should not happen.
more readable, but certainly whole spec is very correct).
+ MUST: The package licensed with a Fedora approved license and meets the
Licensing Guidelines
- MUST: The License field in the package spec file matches the actual
license

I went through whole gdb and found it to be incredible collection of all possible licenses, so that my proposed License tag is

License: GPLv3+ and GFDL and GPLv2+ and GPLv3+ and GPLv3+ with exceptions and LGPLv2+ and and GPL+ and Public Domain

(all on one line)

+ 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.
+ 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, as provided in the spec URL. Reviewers should use md5sum for this task
From srpm:
9d52988c5b2a2085e0ee5df89393e5a0  gdb-7.0.90.20100306.tar.bz2
04e5c4b1b9e633422cc48990fe61958d  libstdc++-v3-python-r155978.tar.bz2
= MATCHES
+ MUST: The package successfully compiles and builds into binary rpms on at
least one primary architecture
 - build in koji
 http://koji.fedoraproject.org/koji/taskinfo?taskID=2039459
0 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
+ MUST: All build dependencies must be listed in BuildRequires, except for any
that are listed in the exceptions section of the Packaging Guidelines
Build in koji
0 MUST: The spec file handles locales properly. This is done by using the
%find_lang macro
No locales
0 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.
Not appllicable
0 MUST: Packages must NOT bundle copies of system libraries
0 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
+ MUST: 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
+ MUST: Package must not list a file more than once in the spec file's %files
listings
+ MUST: Permissions on files must be set properly. Every %files section must
include a %defattr(...) line.
+ MUST: Each package must have a %clean section, which contains rm -rf
%{buildroot} (or $RPM_BUILD_ROOT).
+ MUST: Each package must consistently use macros
+ MUST: The package must contain code, or permissable content
0 MUST: Large documentation files must go in a -doc subpackage
+ MUST: If a package includes something as %doc, it must not affect the runtime
of the application
0 MUST: Header files must be in a -devel package
0 MUST: Static libraries must be in a -static package
0 MUST: Packages containing pkgconfig(.pc) files must 'Requires: pkgconfig'
0 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
0 MUST: devel packages must require the base package using a fully versioned
dependency: Requires: %{name} = %{version}-%{release}
+ MUST: Packages must NOT contain any .la libtool archives, these must be
removed in the spec if they are built
0 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
+ 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}
(or $RPM_BUILD_ROOT)
+ MUST: All filenames in rpm packages must be valid UTF-8

Please fix the License field.
Comment 26 Matěj Cepl 2010-03-09 10:52:12 EST
Created attachment 398830 [details]
suggested fix for License: field
Comment 27 Jan Kratochvil 2010-03-09 13:21:03 EST
(In reply to comment #26)
> suggested fix for License: field    
+License: GPLv3+ and GFDL and GPLv2+ and GPLv3+ and GPLv3+ with exceptions and LGPLv2+ and GPL+ and Public Domain

(a) There is duplicate "GPLv3+".  I wrote in PkgWrangler also "GPLv3"
    but I cannot find any such licensed file now.
(b) Where have you found "GPL+"?

Thanks for all the work!
Comment 28 Matěj Cepl 2010-03-09 18:46:30 EST
(In reply to comment #27)
> (a) There is duplicate "GPLv3+".  I wrote in PkgWrangler also "GPLv3"
>     but I cannot find any such licensed file now.

I haven't found GPLv3 myself and I am dimly remember it might not be possible to have one ... I think GPLv3 made + finally mandatory, but I would have to check on this.

> (b) Where have you found "GPL+"?

some header files in include/opcode/ directory.

johanka:gdb-7.0.90.20100306$ grep -ril 'either version 1, or' include/opcode/*
include/opcode/arm.h
include/opcode/hppa.h
include/opcode/i860.h
include/opcode/np1.h
include/opcode/ns32k.h
include/opcode/pdp11.h
include/opcode/pn.h
include/opcode/vax.h
johanka:gdb-7.0.90.20100306$ 

However, while looking for it I found this pearl:

gdb/osf-share/HP800/cma_thread_io.h is apparently BSD-ish license.
Comment 29 Matěj Cepl 2010-03-09 18:56:53 EST
(In reply to comment #28)
> gdb/osf-share/HP800/cma_thread_io.h is apparently BSD-ish license.    

Actually, this is the same license for all files in gdb/osf-share directory
Comment 30 Jan Kratochvil 2010-03-10 04:51:24 EST
(In reply to comment #29)
> (In reply to comment #28)
> > gdb/osf-share/HP800/cma_thread_io.h is apparently BSD-ish license.    

Posted:
  Licensing: gdb/osf-share/ is GPL-incompatible
  http://sourceware.org/ml/gdb/2010-03/msg00061.html

Just it IMO should not be tagged as "BSD with advertising" as the companies listed there are not Berkeley.
https://fedoraproject.org/wiki/Licensing#Good_Licenses

Going to use (currently without the gdb/osf-share/ before it gets resolved upstream):
License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPL+ and LGPLv2+ and GFDL and Public Domain
Comment 31 Jan Kratochvil 2010-03-10 14:47:58 EST
In CVS F-13/ as gdb-7.0.90.20100306-21.fc13.

License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPL+ and LGPLv2+ and GFDL and BSD and Public Domain

Used "BSD" for gdb/osf-share/ as it looks like:
BSD License (no advertising) 	 BSD 	 Yes 	Yes 	Yes
https://fedoraproject.org/wiki/Licensing/BSD#3ClauseBSD
Comment 32 Jan Kratochvil 2010-03-10 15:11:50 EST
In CVS F-13/ as gdb-7.0.90.20100306-22.fc13.

Add GPLv2+ with exceptions for files like libtool.m4.

License: GPLv3+ and GPLv3+ with exceptions and GPLv2+ and GPLv2+ with exceptions and GPL+ and LGPLv2+ and GFDL and BSD and Public Domain
Comment 33 Matěj Cepl 2010-03-10 16:16:37 EST
Right.

APPROVED
Comment 34 Matěj Cepl 2010-03-10 16:19:24 EST
yes, of course, this is Merge Review.

Closing as Rawhide.
Comment 35 Parag AN(पराग) 2012-06-15 12:47:42 EDT
This bug just popped out when I searched for packages under review but this looks completed without setting fedora-review+

Setting the flag therefore.

Note You need to log in before you can comment on or make changes to this bug.