Spec Name or Url: ftp://czar.eas.yorku.ca/pub/xcompmgr/xcompmgr.spec
SRPM Name or Url: ftp://czar.eas.yorku.ca/pub/xcompmgr/xcompmgr-1.1.3.srpm
Description: xcompmgr is a sample compositing manager for X servers supporting the XFIXES, DAMAGE, and COMPOSITE extensions. It enables basic eye-candy effects
files not avialable anymore
sorry about that, check again.
a working url. the link for your binary package doesent work (no big deal).
spec file looks good to me ;) works like a charm on x86_64 rawhide and nvidia
card for me.
These files were there 10 minutes ago, now they're gone :-(
(In reply to comment #4)
> These files were there 10 minutes ago, now they're gone :-(
The computer hosting the files was reboot around that time, should be alright
now. And as Rudolf noted earlier, the proper link is;
Oops, mistake again, sorry it's
> The computer hosting the files was reboot around that time
Yep, got it now, built OK on x86_64 (warning about non-existant user using root
instead) xcompmgr runs fine with xorg 7.0RC4 on radeon
Option "Composite" "Enable"
BoardName "ATI Technologies Inc RV370 X550"
Option "AccelMethod" "EXA"
Option "EnablePageFlip" "false"
Option "RenderAccel" "true"
Option "SubPixelOrder" "NONE"
Option "ColorTiling" "false"
xcompmgr loads, KDE with transparent/fade/shadows works ok, if rather slowly.
one or two cases where single row of pixels not composited properly, I wouldn't
know if this was xorg, kde or xcompmgr though.
On a 3GHz P4 it eats 50% user CPU + 30% system cpu by runnign a fully cached "ls
-lR /" in a foreground konsole, if running in a transparent background konsole
it still eats 50% user but only eats 10% system, however it runs about 1/4 the
I'm sure that slowness is to be expected without using fglrx, but would be
delighted to receive any magic xorg.conf tweaks :-)
Is anything blocking this going into extras?
I'd love to see this in extras, too, but the URL is down again.
Greetings, heres a review:
OK - package name good.
OK - spec file matches.
OK - spec in english.
OK - spec legible.
OK - md5sum matches:
OK - compiles and builds under devel.
OK - files and dirs ok.
OK - clean section good.
OK - macros good.
OK - builds ok in mock on devel.
Needs looking at:
1. License. Is it really X11/MIT? I see that SuSE ships this package as GPL.
The License at the top of the .c file does look BSDish. Might confirm?
2. rpmlint has some output:
E: xcompmgr description-line-too-long xcompmgr is a sample compositing manager
for X servers supporting the XFIXES, DAMAGE, and COMPOSITE extensions. It
enables basic eye-candy effects
W: xcompmgr invalid-license MIT/X11
W: xcompmgr-debuginfo invalid-license MIT/X11
You might add a line break or two in the description line.
3. You might optionally ship the Changelog file as a doc.
4. You might get upstream to ship a copy of it's license with it.
Clarify and confirm the License and fix the description line,
and I will APPROVE.
Sorry for responding so promptly. i can't really confirm the specific license
here, but i daresay it's definitely not GPL, see the last entry in the changelog
for that. In keeping with other products (apps, libs, and drivers) available
from xorg, I'll say MIT/X11 is okay.
Description line in the spec file is fixed and changelog shipped as doc.
Thanks for doing the review.
ok, I did some searching around. It appears the license is really a SGI/STL
license ( something like: http://www.mcda.org/help/stl.html ).
From what I could gather this is a very close variant of the MIT license,
so it should be ok to ship.
Note that rpmlint only has "MIT" as a valid license, not MIT/X11.
I would say change the License to just MIT and then it's APPROVED.
Thanks for your patience.
(In reply to comment #11)
> ok, I did some searching around. It appears the license is really a SGI/STL
> license ( something like: http://www.mcda.org/help/stl.html ).
> From what I could gather this is a very close variant of the MIT license,
> so it should be ok to ship.
> Note that rpmlint only has "MIT" as a valid license, not MIT/X11.
> I would say change the License to just MIT and then it's APPROVED.
I disagree. IMHO, I don't think we should be changing license tags just to
silence rpmlint warnings. If rpmlint warns about it then make a note of it in
the spec file, file a bug with rpmlint, and live with the warning.
The License is very close to the MIT license. It's even closer to the STL license.
However, it's not exactly either of them as it has the name of the author in
some places. Best I suppose would be to make the License field "STL" as thats
what it's closest to, and file a RFE against rpmlint to add that license.
I think rpmlint only recognizes the MIT tag as thats what OSI calls the MIT/X11
license. gnu.org calls it only the X11 license and says "This license is
sometimes called the "MIT" license, but that term is misleading, since MIT has
used many licenses for software."
I guess I do see a number of packages using X11/MIT, so I guess rpmlint should
recognize either of the forms of this same license (X11, MIT/X11, MIT).
Per the license comments, unless there is further objection, could you change it
to STL in the package and file a RFE against rpmlint to add that as a valid
Small fix: (Changelog -> ChangeLog)
[gilboa@gilboa-home-dev SPECS]$ diff -u old/xcompmgr.spec new/xcompmgr.spec
--- old/xcompmgr.spec 2006-03-15 20:21:45.000000000 +0200
+++ new/xcompmgr.spec 2006-03-15 20:20:10.000000000 +0200
@@ -1,7 +1,7 @@
Summary: X11 composite manager
Group: User Interface/X
@@ -34,7 +34,7 @@
In response to comment #15:
good catch. That change should be made.
Deji: Are you still around? Do you still want to maintain this package?
I'm still around ;) I'm sorry I've almost forgotten the package is still at this
stage. I've change the license tag to MIT (I can't find any reference to STL
anywhere in the source). newer spec and src.rpm files are at the usual place;
There are large number of fixes in cvs. (including the odd rdesktop problem.)
Any idea when 1.3.4 will be out?
In answer to comment #17:
Well, the package doesn't mention the license as being STL, but look at:
and then diff it vs the license in this package and the first part is identical,
then this package has
"...and that the name of Keith Packard not be used in
advertising or publicity pertaining to distribution of the software without
specific, written prior permission. Keith Packard makes no
representations about the suitability of this software for any purpose. It
is provided "as is" without express or implied warranty."
So I think it's much closer to the STL license than the MIT one.
Any license gurus out there that can chime in?
In refrence to comment #18:
Which CVS repo are you looking at? I don't see any changes in the ones I looked
at anytime recently (which might be after this release version I guess).
Sorry that this package dropped off my radar...
Deji: You still around?
The only blocker I still see here is what to put in the spec for License.
I think "STL" or even "xcompmgr" would be acceptable.
Any thoughts? It would be good to get this in...
Ok, here is it, with 'STL' for license.
Looks fine with me... go ahead and import and build.
Don't forget to close this as NEXTRELEASE once it's imported and built.
Imported and built.