Bug 852660 - Automagic dependencies
Automagic dependencies
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: libvncserver (Show other bugs)
19
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
http://koji.fedoraproject.org/koji/ta...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-29 04:37 EDT by Petr Pisar
Modified: 2014-01-30 08:26 EST (History)
2 users (show)

See Also:
Fixed In Version: libvncserver-0.9.9-8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-30 08:26:20 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed fix (1.66 KB, patch)
2013-07-23 10:01 EDT, Petr Pisar
no flags Details | Diff

  None (edit)
Description Petr Pisar 2012-08-29 04:37:40 EDT
Building the package in koji and in local system results in different set of features and dependencies of the resulting package.

This is cause by missing configure arguments.

E.g. png support is such an example.

I propose to add --with/without-{png,gcrypt} to configure and if enabled, then to add corresponding build-requires.


Also I propose removing LibVNCServer provides/obsoletes as no supported Fedora release delivers it. Also some renovation like removing explicit %defattr or BuildRoot redefinition and cleaning would be great.
Comment 1 Fedora End Of Life 2013-04-03 13:13:56 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 2 Petr Pisar 2013-07-23 09:44:00 EDT
And it's there, the build fails in today's rawhide because of undeclared dependencies <http://koji.fedoraproject.org/koji/taskinfo?taskID=5644308>:

/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../common    -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -Wall  -I/usr/include/p11-kit-1  -c -o stats.lo stats.c
 gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../common -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -I/usr/include/p11-kit-1 -c websockets.c  -fPIC -DPIC -o .libs/websockets.o
 gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../common -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -I/usr/include/p11-kit-1 -c rfbcrypto_gnutls.c  -fPIC -DPIC -o .libs/rfbcrypto_gnutls.o
 gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../common -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wall -I/usr/include/p11-kit-1 -c rfbssl_gnutls.c  -fPIC -DPIC -o .libs/rfbssl_gnutls.o
rfbcrypto_gnutls.c:25:20: fatal error: gcrypt.h: No such file or directory
 #include <gcrypt.h>
                    ^
compilation terminated.
make[2]: *** [rfbcrypto_gnutls.lo] Error 1
Comment 3 Petr Pisar 2013-07-23 10:01:43 EDT
Created attachment 777333 [details]
Proposed fix
Comment 4 Rex Dieter 2013-07-23 10:10:53 EDT
I usually dislike adding build options, unless there is some good motivation for doing so.  What is the justification in this case?

In this case, I'm more inclined to fix the immediate problem of gcrypt.h not being found.

(and general .spec cleanup can come later in separate commits)
Comment 5 Rex Dieter 2013-07-23 10:15:42 EDT
Looks like your failure is due to a chance in gnutls-devel, it used to pull in libgcrypt-devel, but now it doesn't.  Need to determine the proper fix to adapt to this change.
Comment 6 Rex Dieter 2013-07-23 10:25:03 EDT
Looking at your .spec patch now, I think I misunderstood your previous comments.  I agree with your fix, and will apply it.

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