Bug 248291 - Review Request: libXNVCtrl - Library that provides the NV-CONTROL API
Summary: Review Request: libXNVCtrl - Library that provides the NV-CONTROL API
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Nicolas Chauvet (kwizart)
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-07-15 10:17 UTC by Hans de Goede
Modified: 2014-10-31 01:25 UTC (History)
3 users (show)

Fixed In Version: libXNVCtrl-169.12-12.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-31 01:25:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
kwizart: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Hans de Goede 2007-07-15 10:17:09 UTC
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.

Comment 1 Nicolas Chauvet (kwizart) 2007-07-22 20:08:53 UTC
3) Oyranos seems also to uses it to control color profiles...

I will review it soon, then

Comment 2 Nicolas Chauvet (kwizart) 2007-07-22 21:20:40 UTC
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...

Comment 3 Hans de Goede 2007-07-23 13:24:17 UTC
(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



Comment 4 Nicolas Chauvet (kwizart) 2007-07-24 22:34:00 UTC
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




Comment 5 Hans de Goede 2007-07-25 05:47:35 UTC
(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.


Comment 6 Nicolas Chauvet (kwizart) 2007-07-26 12:13:56 UTC
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...


Comment 7 Nicolas Chauvet (kwizart) 2007-07-26 16:37:59 UTC
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...)

Comment 8 Hans de Goede 2007-07-27 08:26:55 UTC
(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


Comment 9 Nicolas Chauvet (kwizart) 2007-07-27 09:21:54 UTC
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...


Comment 10 Hans de Goede 2007-07-27 09:31:03 UTC
(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



Comment 11 Nicolas Chauvet (kwizart) 2007-07-27 09:50:04 UTC
* 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)

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

Comment 12 Hans de Goede 2007-07-27 10:24:42 UTC
Thanks!

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


Comment 13 Hans de Goede 2007-07-27 21:16:13 UTC
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.


Comment 14 Wolfgang Ulbrich 2014-10-09 17:33:19 UTC
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

Comment 15 Kevin Fenzi 2014-10-13 22:57:32 UTC
Git done (by process-git-requests).

Comment 16 Fedora Update System 2014-10-14 13:08:14 UTC
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

Comment 17 Fedora Update System 2014-10-14 18:13:20 UTC
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).

Comment 18 Fedora Update System 2014-10-31 01:25:42 UTC
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.


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