Bug 248291

3) Oyranos seems also to uses it to control color profiles...

I will review it soon, then

Ok so few comments to start:

1/ You must use $RPM_OPT_FLAGS
This will allow to have some debuginfo... (cf 0 blocks )

2/ About: # ... but apps expect them under NVCtrl:
  Ok but can you preserve timestamp? ( maybe some install -pm 0644 would be
better...)

Full review will follow later...

(In reply to comment #2)
> Ok so few comments to start:
> 
> 1/ You must use $RPM_OPT_FLAGS
> This will allow to have some debuginfo... (cf 0 blocks )
> 
> 2/ About: # ... but apps expect them under NVCtrl:
>   Ok but can you preserve timestamp? ( maybe some install -pm 0644 would be
> better...)
> 

New version with these both fixed here:
Spec URL: http://people.atrpms.net/~hdegoede/libXNVCtrl.spec
SRPM URL: http://people.atrpms.net/~hdegoede/libXNVCtrl-1.0-2.fc8.src.rpm

OK, i've saw that you just have build libXNVCtrl but is there other libraries to
build from the standard package or only the nvidia-settings binary is missing?

About this don't you think that might be possible to build it also ?

For now i don't know how to bring nvidia users to uses this ? does your program
will have a Requires (or BR) libXNVCtrl ?! Then this library will be bring on
the system whereas the hardware may be not present...
The other way of doing this is to have Requires: libXNVCtrl from the proprietary
nvidia driver, then does others problems will be able to dlopen this library to
talk to the hardware... ?!

I think the first solution is the better, (maybe the two can be done...)

Anyway we may need to have for now (if only the proprietary drivers is required...)
ExclusiveArchs: %{ix86} x86_64

(In reply to comment #4)
> OK, i've saw that you just have build libXNVCtrl but is there other libraries to
> build from the standard package or only the nvidia-settings binary is missing?
> 

There are no other libs AFAIK.

> About this don't you think that might be possible to build it also ?
> 

I don't want to be conflicting with the proprietary drivers from that other
repo, these do not contain this lib (as its linked staticly into
nvidea-settings),  but do contain nvidea-settings itself, and maybe a later version.

> For now i don't know how to bring nvidia users to uses this ? does your program
> will have a Requires (or BR) libXNVCtrl ?! Then this library will be bring on
> the system whereas the hardware may be not present...

Yes, gnome-applet-sensors will BR libXNVCtrl-devel, and then the build binary
will automatically require libXNVCtrl.so.0 . This is not a problem for non
nvidia driver users, this library just gives access to an X extension, just like
extensions as MITSHM, Xvideo and Xxf86dga. If the extension isn't available the
program will not use it and stay to function normally (except that it won't show
the temperature for any nvidia cards). So basicly with this lib, and an X-server
with the extension, nvidia card temp gets added as an additional feature. If the
server is missing the extension, then the app keeps functioning as before.

> The other way of doing this is to have Requires: libXNVCtrl from the proprietary
> nvidia driver, then does others problems will be able to dlopen this library to
> talk to the hardware... ?!
> 

As explained above this is not necessary.

> I think the first solution is the better, (maybe the two can be done...)
> 
> Anyway we may need to have for now (if only the proprietary drivers is
required...)
> ExclusiveArchs: %{ix86} x86_64
> 

This is not necessary either, on ppc the extension will simple not be there and
if nvidia does a ppc driver release, then things will start working without
needing a rebuild.

Ok so i've asked the #nouveau project and they don't seems to uses this for now...
But this could be done eventually whereas this is not the first item from their
TODO list.

And as adviced by D. Woodhouse "They have to detect at runtime whether the X
extension is present or not anyway", this also is usefull to have the libs
present in case of using a remote X... So it is safe to drop ExclusiveArchs:...


Using fedora-review: ? , as this should already be set...

Review for release 2.fc6:
* RPM name is OK
* Source nvidia-settings-1.0.tar.gz is the same as upstream
* Builds fine in mock
* INSERT RESULT OF RUN TEST
As linking with oyranos work and runtime of oyranos works, 
then run test for the library works... Good!

* running rpmlint on installed files:
[root@Kwizatz libXNVCtrl]# rpmlint libXNVCtrl
W: libXNVCtrl incoherent-version-in-changelog 1.0-2 1.0-2.kwizart.fc6
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XReply
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
XMissingExtension
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XFlush
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XEatData
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
XextRemoveDisplay
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
XextCreateExtension
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XRead
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
_XSetLastRequestRead
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
XextFindDisplay
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XSend
W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
XextAddDisplay

[root@Kwizatz libXNVCtrl]# ldd /usr/lib64/libXNVCtrl.so.0.0.0
        libc.so.6 => /lib64/libc.so.6 (0x00002aaaaace7000)
        /lib64/ld-linux-x86-64.so.2 (0x0000555555554000)

I wonder if this can be solved by adding -lX11 (or something else) which seems
needed by BR, i'm searching how to works with thoses issues... where they could
be safety ignored for the review (we need at least to advices upstream about
this...), i wonder if this could be solved by some tweaks ?...


Notes: Thats the only issue it remains (for what i am aware...)

(In reply to comment #7)
> Review for release 2.fc6:
> * running rpmlint on installed files:
> [root@Kwizatz libXNVCtrl]# rpmlint libXNVCtrl
> W: libXNVCtrl incoherent-version-in-changelog 1.0-2 1.0-2.kwizart.fc6
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XReply
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
> XMissingExtension
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XFlush
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XEatData
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
> XextRemoveDisplay
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
> XextCreateExtension
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XRead
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
> _XSetLastRequestRead
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
> XextFindDisplay
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0 _XSend
> W: libXNVCtrl undefined-non-weak-symbol /usr/lib64/libXNVCtrl.so.0.0.0
> XextAddDisplay
> 

Here is a new version fixing these:
Spec URL: http://people.atrpms.net/~hdegoede/libXNVCtrl.spec
SRPM URL: http://people.atrpms.net/~hdegoede/libXNVCtrl-1.0-3.fc8.src.rpm

Unfortunately:
+ gcc -o ./libXNVCtrl.so.0.0.0~ -shared -Wl,-soname,libXNVCtrl.so.0 NVCtrl.o
-lX11 -lXext -lc
/usr/bin/ld: cannot find -lXext
You missed to add BR: libXext-devel
also i wonder if this line should also have some CFLAGS...

(In reply to comment #9)
> Unfortunately:
> + gcc -o ./libXNVCtrl.so.0.0.0~ -shared -Wl,-soname,libXNVCtrl.so.0 NVCtrl.o
> -lX11 -lXext -lc
> /usr/bin/ld: cannot find -lXext
> You missed to add BR: libXext-devel

Oops, sorry about that.

> also i wonder if this line should also have some CFLAGS...

No thats not necessary, CFLAGS are for _C_ompiling not for linking, for some
reason many makefiles also pass them to GCC while linking, but that has zero
effect unless someone has put linking specific flags in there, which is not the
case with RPM_OPT_FLAGS

New version here:
Spec URL: http://people.atrpms.net/~hdegoede/libXNVCtrl.spec
SRPM URL: http://people.atrpms.net/~hdegoede/libXNVCtrl-1.0-4.fc8.src.rpm

* build in mock (tested in FC6 x86_64)
* rpmlint is quite on both rpms and installed files

Good!

This is the "first package" I ever said:


----------------------

This package (libXNVCtrl) is APPROVED by me (kwizart)

----------------------

Thanks!

New Package CVS Request
=======================
Package Name:      libXNVCtrl
Short Description: Library providing the NV-CONTROL API
Owners:            j.w.r.degoede
Branches:          FC-6 F-7 devel
InitialCC:         <empty>

imported and build, closing.

Nicolas, this will also become available for F-7 with the next updates push, so
then you can build against it if you want. Once its pushed for F-7, I will also
build it for FC-6.

Package Change Request
======================
Package Name: libXNVCtrl
New Branches: epel7
Owners: raveit65

needed to build mate-sensor-applet
see https://bugzilla.redhat.com/show_bug.cgi?id=1140374

Git done (by process-git-requests).

libXNVCtrl-169.12-12.el7 has been submitted as an update for Fedora EPEL 7.
https://admin.fedoraproject.org/updates/libXNVCtrl-169.12-12.el7

Package libXNVCtrl-169.12-12.el7:
* should fix your issue,
* was pushed to the Fedora EPEL 7 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=epel-testing libXNVCtrl-169.12-12.el7'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3395/libXNVCtrl-169.12-12.el7
then log in and leave karma (feedback).

libXNVCtrl-169.12-12.el7 has been pushed to the Fedora EPEL 7 stable repository.  If problems still persist, please make note of it in this bug report.