Spec URL: http://people.atrpms.net/~hdegoede/libXNVCtrl.spec SRPM URL: http://people.atrpms.net/~hdegoede/libXNVCtrl-1.0-1.fc8.src.rpm Description: This packages contains the libXNVCtrl library from the nvidia-settings application. This library provides the NV-CONTROL API for communicating with the proprietary NVidia xorg driver. This package does not contain the nvidia-settings tool itself as that is included with the proprietary drivers themselves. --- Notice to reviewers, yes you've read it correctly this library is of no use except to users of the proprietary nvidia driver, why include it in Fedora then? 1) Its foss (GPL) 2) Its needed for applications like for example gnome-applet-sensors to read the temperature sensors on nvidia cards whe using the proprietary driver. So this enhances the end user experience of applications like gnome-applet-sensors, which is included in Fedora, for users of the proprietary driver, and has no downside.
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.