Sorry, I forgot to mention this is my first package and I need a sponsor.

How do you intend to handle any potential conflicts with xorg-x11-drv-via?

It doesn't conflict with xorg-x11-drv-via and can be installed in parallel. The
driver name is openchrome, so switching from one driver to the other is just a
matter of changing the driver name in xorg.conf.

(In reply to comment #2)
> How do you intend to handle any potential conflicts with xorg-x11-drv-via?

Also, there shouldn't be conflicts, because the via driver should go away.  It's
unmaintained and terrible.

Functionality wise, it seems to work for 2D and some 3D. Still crashes the X
server if you try and enable compiz, much like via.

(In reply to comment #5)
> Functionality wise, it seems to work for 2D and some 3D. Still crashes the X
> server if you try and enable compiz, much like via.

Yup, but this is not a bug in openchrome driver, it's mesa that is at fault
here. The unichrome DRI is known to be buggy, especially on K8M800. Mileage will
vary depending on the chipset. It's not that bad at least with CLE266 and
KM400A. I don't own any of the other chipsets, so I can't really comment for them.

*** Bug 205087 has been marked as a duplicate of this bug. ***

rpmlint turns up a few problems:

xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postin
/usr/lib64/libchromeXvMC.so.1.0.0
xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postun
/usr/lib64/libchromeXvMC.so.1.0.0
xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postin
/usr/lib64/libchromeXvMCPro.so.1.0.0
xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postun
/usr/lib64/libchromeXvMCPro.so.1.0.0

Yeah, you should probably do the usual ldconfig run, even though another driver
with XvMC libraries (i810) doesn't do that.

Then there are a whole bunch of these:

xorg-x11-drv-openchrome.x86_64: W: undefined-non-weak-symbol
/usr/lib64/libchromeXvMC.so.1.0.0 _XReply
xorg-x11-drv-openchrome.x86_64: W: undefined-non-weak-symbol
/usr/lib64/libchromeXvMCPro.so.1.0.0 _XReply

Plus the same for a whole bunch of other symbols.  I honestly do not know if
this is an actual problem or not; the same issue came up in the i810 driver
review but I never received an answer as to what causes it.  I'll poke some experts.

xorg-x11-drv-openchrome-devel.x86_64: W: no-documentation

This is OK.

(In reply to comment #8)
> rpmlint turns up a few problems:
> 
> xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postin
> /usr/lib64/libchromeXvMC.so.1.0.0
> xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postun
> /usr/lib64/libchromeXvMC.so.1.0.0
> xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postin
> /usr/lib64/libchromeXvMCPro.so.1.0.0
> xorg-x11-drv-openchrome.x86_64: E: library-without-ldconfig-postun
> /usr/lib64/libchromeXvMCPro.so.1.0.0
> 
> Yeah, you should probably do the usual ldconfig run, even though another driver
> with XvMC libraries (i810) doesn't do that.

There's no point.  The XvMC sublibraries are loadables, they're only ever used
with dlopen().

> Then there are a whole bunch of these:
> 
> xorg-x11-drv-openchrome.x86_64: W: undefined-non-weak-symbol
> /usr/lib64/libchromeXvMC.so.1.0.0 _XReply
> xorg-x11-drv-openchrome.x86_64: W: undefined-non-weak-symbol
> /usr/lib64/libchromeXvMCPro.so.1.0.0 _XReply

They're provided by libXvMC, which dlopens libchromeXvMCPro.so.

These aren't problems.

Surely this cries for /usr/lib/XvMC/ or something and all of these there,
outside of the default linker path.

Moving the libs to /usr/lib/XvMC is not involving this package only, as
xorg-x11-drv-i810 is also dropping its files here and XvMCW probably needs to be
changed too. I guess it will also breaks some users configuration. All in all, I
think it doesn't belong to this package review to change that and this should be
handled in another (upstream ?) bug. 

Ajax, what do you think ?

OK, I'm back from vacation and caught up with work and such.

> There's no point.  The XvMC sublibraries are loadables, they're only ever used
> with dlopen().

I guess you and spot get to duke it out, then:

(#fedora-devel)
[13:06] <tibbs> Is there any situation where you don't want to run ldconfig
after putting a library into /usr/lib?
[13:06] <spot> its not a shared library? :)
[13:07] <tibbs> lib*XvMC.so.*
[13:07] <spot> tibbs: not for that specific situation, no.
[13:08] <tibbs> spot: No to running ldconfig?  Or no to not running ldconfig?
[13:08] <spot> yes. run ldconfig.

I guess if they're only ever dlopened then they don't even need to live under
/usr/lib.  But it's perhaps best not to hang this package up on restructuring
where X puts its dlopened libraries, and frankly I'm nothing resembling an
expert with X drivers so I'll go along with ajax here.  If this proves to be an
incorrect decision then the fix will be trivial.

* source files match upstream:
   42d50f33ce1d6c18045af3d573e718cc70f042c4ef24a1a54ffb49c21b649e63
   xf86-video-openchrome-0.2.900.tar.bz2
* package meets naming and versioning guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* summary is OK.
* description is OK.
* dist tag is present.
* build root is OK.
* license field matches the actual license.
* license is open source-compatible.
* license text not included upstream.
* latest version is being packaged.
* BuildRequires are proper.
* compiler flags are appropriate.
* %clean is present.
* package builds in mock (development, x86_64).
* package installs properly
* debuginfo package looks complete.
* rpmlint has acceptable complaints.
* final provides and requires are sane:
  xorg-x11-drv-openchrome-0.2.900-6.fc8.x86_64.rpm
   libchromeXvMC.so.1()(64bit)
   libchromeXvMCPro.so.1()(64bit)
   openchrome_drv.so()(64bit)
   xorg-x11-drv-openchrome = 0.2.900-6.fc8
  =
   libchromeXvMC.so.1()(64bit)
   libchromeXvMCPro.so.1()(64bit)
   libdrm.so.2()(64bit)
   xorg-x11-server-Xorg

  xorg-x11-drv-openchrome-devel-0.2.900-6.fc8.x86_64.rpm
   xorg-x11-drv-openchrome-devel = 0.2.900-6.fc8
  =
   libchromeXvMC.so.1()(64bit)
   libchromeXvMCPro.so.1()(64bit)
   xorg-x11-drv-openchrome = 0.2.900-6.fc8

* Not possible to test this at rpmbuild time, and I haven't the appropriate 
   hardware to test.
? shared libraries are added to the regular linker path, but they're "special" 
   and so there's no need for an ldconfig run.
* unversioned .so files are in the -devel package.
* owns the directories it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* 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 static libraries.
* no libtool .la files.

APPROVED; I'll sponsor you.

New Package CVS Request
=======================
Package Name: xorg-x11-drv-openchrome
Short Description: Driver for VIA IGPs
Owners: xavierb
Branches: F-7 F-8
InitialCC: xavierb
Cvsextras Commits: yes

CVS done.

built for F-7, F-8 and devel.