Fedora Merge Review: gdb http://cvs.fedora.redhat.com/viewcvs/devel/gdb/ Initial Owner: jkratoch
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.
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> - 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.
Any updated *.spec or src.rpm available? http://cvs.fedora.redhat.com/viewcvs/devel/gdb/ still is at *-8
(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.
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.
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.)
(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.
(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.
(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.
All the issues described in this Bug so far have been committed now to CVS as: * Tue Apr 24 2007 Jan Kratochvil <jan.kratochvil> - 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.)
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.
(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.
jan.kratochvil 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?
Ralf, I think this was a mistake, because the report was opened again one minute after it got closed.
(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.
(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 :-) ).
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.
(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.
Committed the last change I am aware of: * Mon Jul 23 2007 Jan Kratochvil <jan.kratochvil> - 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.
(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.
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
(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.
(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
+ 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.
Created attachment 398830 [details] suggested fix for License: field
(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!
(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.
(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
(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
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
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
Right. APPROVED
yes, of course, this is Merge Review. Closing as Rawhide.
This bug just popped out when I searched for packages under review but this looks completed without setting fedora-review+ Setting the flag therefore.