Bug 226571 - Merge Review: xorg-x11-apps
Summary: Merge Review: xorg-x11-apps
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-apps
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-31 21:21 UTC by Nobody's working on this, feel free to take it
Modified: 2015-04-30 12:58 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-04-30 12:58:26 UTC
Type: ---

Attachments (Terms of Use)

Description Nobody's working on this, feel free to take it 2007-01-31 21:21:34 UTC
Fedora Merge Review: xorg-x11-apps

Initial Owner: sandmann@redhat.com

Comment 1 Thorsten Leemhuis 2007-02-03 16:51:08 UTC
* 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:


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

 That really should be fixed upstream. Most the .c .h files seems to contain a
MIT license in the header. But those not:

* 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

 * 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:
-> 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

 * 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

Comment 2 Matthias Clasen 2007-02-04 00:42:24 UTC
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.

Comment 3 Thorsten Leemhuis 2007-02-04 13:53:49 UTC
(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

Comment 4 Bernie Innocenti 2010-02-01 22:04:45 UTC
xorg-x11-apps is in Fedora. Hence, closing this old review.

Comment 5 Jason Tibbitts 2010-02-02 00:18:53 UTC
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.

Comment 6 Cole Robinson 2015-02-11 20:39:35 UTC
Mass reassigning all merge reviews to their component. For more details, see this FESCO ticket:


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


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

Comment 7 Simone Caronni 2015-04-30 12:58:26 UTC
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.

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