Bug 226365

Is the archive only present in the srpm? Couldn't there be a
better place for it, to allow for easier modifications?

Shouldn't the references to Red Hat be removed? The reference
to Red Hat are in config.guess, though it seems a bit buggy
since the mere presence of the file isn't a necessary condition
for redhat to be vendor. I don't know what is the exact status 
of that file regarding trademark, though:
config.guess:## for Red Hat Linux
config.guess:if test -f /etc/redhat-release ; then
config.guess:    VENDOR=redhat ;

in dist.sh, I think that  /etc/system-release should be used instead.

In macros there is
%_vendor         redhat

and
# Use these macros to differentiate between RH and other KMP implementation(s).
redhat_kernel_module_package     1
I believe this one is right, but redhat is not really redhat here,
it could be anything else.

In the spec file there are also references to Red Hat, it seems
to me that they should be changed to something more neutral, like
Distribution.

Now the %_vendor definition is right, and this itself seems a good
reason to me to keep the package name and the directory name. What
do you think about it? In any case if there are trademark issues,
it would be nice to be easily able to change redhat to something
else at a specific place only, such that this package can easily
be reused.


Buildroot is not in the accepted ones.

Summary should not end with a dot.

Taking on review.

rpmlint output:
redhat-rpm-config.noarch: W: no-documentation
redhat-rpm-config.noarch: E: non-executable-script /usr/lib/rpm/redhat/find-provides.d/firmware.prov 0644
redhat-rpm-config.noarch: E: non-executable-script /usr/lib/rpm/redhat/find-provides.d/modalias.prov 0644
redhat-rpm-config.noarch: W: summary-ended-with-dot Red Hat specific rpm configuration files.
redhat-rpm-config.noarch: W: no-url-tag
redhat-rpm-config.noarch: E: only-non-binary-in-usr-lib
redhat-rpm-config.src:121: W: macro-in-%changelog name
redhat-rpm-config.src:265: W: macro-in-%changelog configure
redhat-rpm-config.src:274: W: macro-in-%changelog __spec_install_post
redhat-rpm-config.src: E: no-cleaning-of-buildroot %install
redhat-rpm-config.src: W: no-%build-section
redhat-rpm-config.src: W: summary-ended-with-dot Red Hat specific rpm configuration files.
redhat-rpm-config.src: W: no-url-tag
2 packages and 0 specfiles checked; 4 errors, 9 warnings.

- Fix the macros in changelog (should be %%name instead of %name etc).

- Clean buildroot before install.

- Add disclaimer from http://fedoraproject.org/wiki/Packaging/SourceURL#We_are_Upstream to spec file.

- Remove dot from summary and set executable flags on scripts.

- Drop use of %{_prefix}.

- Change buildroot to
%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)

MUST: The spec file for the package is legible and macros are used consistently. OK
MUST: The package must be named according to the Package Naming Guidelines. OK
MUST: The spec file name must match the base package %{name}. 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. NEEDSFIX
- Since we are upstream it should be no problem to get the license specified and the license files included in the package.

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. NEEDSFIX

MUST: The package MUST successfully compile and build into binary rpms. OK
MUST: The spec file MUST handle locales properly. OK
MUST: Optflags are used and time stamps preserved. OK
MUST: Packages containing shared library files must call ldconfig. OK
MUST: A package must own all directories that it creates or require the package that owns the directory. OK
MUST: Files only listed once in %files listings. OK
MUST: Permissions on files must be set properly. OK
MUST: Clean section exists. OK
MUST: Large documentation files must go in a -doc subpackage. OK
MUST: All relevant items are included in %doc. Items in %doc do not affect runtime of application. 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'. OK
MUST: If a package contains library files with a suffix then library files ending in .so 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. OK
MUST: Packages does not contain any .la libtool archives. OK
MUST: Desktop files are installed properly. OK
MUST: No file conflicts with other packages and no general names. OK

MUST: Buildroot cleaned before install. NEEDSFIX

SHOULD: If the package does not include license text(s) as separate files from upstream, the packager should query upstream to include it. NEEDSFIX

SHOULD: %{?dist} tag is used in release. OK
SHOULD: The package builds in mock. OK

Please address issues.

ping?

Oh, I don't seem to be assigned to this properly, but anyway, ok, I'll look.

Ugh, you're not supposed to change the assignment; Merge Reviews are like Package Reviews: the reviewer is the assignee, s/he makes critical notes about the package that are dealt with by the maintainer(s).

Well, if getting this done requires you to get the assignment, that's OK with me.

Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:

  https://fedorahosted.org/fesco/ticket/1269

If you don't know what merge reviews are about, please see:

  https://fedoraproject.org/wiki/Merge_Reviews

How to handle this bug is left to the discretion of the package maintainer.

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Hasn't gotten done in nine years, ain't gonna happen now. There's not much in common between the starting point and current situation anyway.