* The licensing of this package is odd afaics:
 * xcursorgen-1.0.1/COPYING -> I asked on #fedora-extras and jeremy replied:
"reworded MIT.  would be worth sending mail to the upstream and asking if it can
be switched to the standard wording"
 
 * All the other contain a COPYING file that contains
{{{
This is a stub file.  This package has not yet had its complete licensing
information compiled.  Please see the individual source files for details on
your rights to use and modify this software.

Please submit updated COPYING files to the Xorg bugzilla:

https://bugs.freedesktop.org/enter_bug.cgi?product=xorg

All licensing questions regarding this software should be directed at the
Xorg mailing list:

http://lists.freedesktop.org/mailman/listinfo/xorg
}}}
 That really should be fixed upstream. Most the .c .h files seems to contain a
MIT license in the header. But those not:
{{{
./xpr-1.0.1/x2pmp.c
./xpr-1.0.1/pmp.h
./xpr-1.0.1/xpr.h
./luit-1.0.1/locale.c
./xeyes-1.0.1/transform.c
./xeyes-1.0.1/Eyes.h
./xeyes-1.0.1/EyesP.h
./xeyes-1.0.1/transform.h
./xload-1.0.1/get_rload.c
./xload-1.0.1/xload.h
}}}


* rpmlint 
E: xorg-x11-apps obsolete-not-provided XFree86
E: xorg-x11-apps obsolete-not-provided xorg-x11
E: xorg-x11-apps obsolete-not-provided XFree86-tools
E: xorg-x11-apps obsolete-not-provided xorg-x11-tools
-> These were probably needed during the switch to modular X -- are they still
needed? Maybe just drop them. Providing those probably does not make sense anymore.

W: xorg-x11-apps unversioned-explicit-obsoletes XFree86
W: xorg-x11-apps unversioned-explicit-obsoletes xorg-x11
W: xorg-x11-apps unversioned-explicit-obsoletes XFree86-tools
W: xorg-x11-apps unversioned-explicit-obsoletes xorg-x11-tools
-> That should be fixed, in case we sometime in the future want to provide
packages with those names again

W: xorg-x11-apps invalid-license MIT/X11
-> please use "MIT"

W: xorg-x11-apps unversioned-explicit-provides luit
W: xorg-x11-apps unversioned-explicit-provides oclock
W: xorg-x11-apps unversioned-explicit-provides x11perf
W: xorg-x11-apps unversioned-explicit-provides xbiff
W: xorg-x11-apps unversioned-explicit-provides xclipboard
W: xorg-x11-apps unversioned-explicit-provides xclock
W: xorg-x11-apps unversioned-explicit-provides xconsole
W: xorg-x11-apps unversioned-explicit-provides xcursorgen
W: xorg-x11-apps unversioned-explicit-provides xeyes
W: xorg-x11-apps unversioned-explicit-provides xkill
W: xorg-x11-apps unversioned-explicit-provides xload
W: xorg-x11-apps unversioned-explicit-provides xlogo
W: xorg-x11-apps unversioned-explicit-provides xmag
W: xorg-x11-apps unversioned-explicit-provides xmessage
W: xorg-x11-apps unversioned-explicit-provides xpr
W: xorg-x11-apps unversioned-explicit-provides xwd
W: xorg-x11-apps unversioned-explicit-provides xwud
-> Those packages have versions upstream, we should provide them

* MISC:
 * From files:
%dir %{_datadir}/X11
-> a lot of packages own that dir. It should be owned by only one package (maybe
by the filesystem)

 * From files:
%{_datadir}/X11/app-defaults/
-> Owning %dir %{_datadir}/X11 but not it's subdir app-defaults/ is "interesting"

 * Hmm, a lot of apps, but no docs? At least x-Message has a README that maybe
should be shipped

 * A lot of GUI apps, but no desktop files. Quoting the guidelines:
" - 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. This is described in detail in the desktop files section of
Packaging Guidelines. 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."

 * the "pkgname" macro -- why define a macro if it's used only in one place?
Please consider getting rid of.

* besides that:
 package meets naming and packaging guidelines.
 specfile is properly named, is cleanly written and uses macros consistently.
 build root is correct.
      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 license is open source-compatible.
 BuildRequires are proper.
 final provides and requires are sane:
 no shared libraries are present.
 package is not relocatable.
 no duplicates in %files.
 file permissions are appropriate.
 %clean is present.
 no scriptlets present.
 code, not content.
 documentation is small, so no -docs subpackage is necessary.
 %docs are not necessary for the proper functioning of the package.
 no headers.
 no pkgconfig files.
 no libtool .la droppings.
 not a GUI app.
 not a web app.
 no open bugs

Believe me, you do _not_ want to install desktop files for xeyes and friends.
I have complained about that wording in the packaging guidelines before.

(In reply to comment #2)
> Believe me, you do _not_ want to install desktop files for xeyes and friends.
> I have complained about that wording in the packaging guidelines before.

/me fully agrees that shipping desktop files for that stuff would be really
stupid -- I probably should have been more clear and should just have quoted the
second sentence from the guidelines that is :
"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.""

xorg-x11-apps is in Fedora. Hence, closing this old review.

It's a merge review; of course the package is already in Fedora.

It's been long-ignored, that's for sure, probably because someone set the fedora-review flag to '-' and dropped it out of the review queue.  I'll clear out the assignments and put it back on the list.  Not sure who should be CC'd, though.

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.

I've got access for this package to update it to current packaging guidelines and an update that contains all the changes has been released before opening this bug.