Bug 852660 - Automagic dependencies
Summary: Automagic dependencies
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvncserver
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
URL: http://koji.fedoraproject.org/koji/ta...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-29 08:37 UTC by Petr Pisar
Modified: 2014-01-30 13:26 UTC (History)
2 users (show)

Fixed In Version: libvncserver-0.9.9-8
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-30 13:26:20 UTC
Type: Bug
Embargoed:


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

Description Petr Pisar 2012-08-29 08:37:40 UTC
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 17:13:56 UTC
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 13:44:00 UTC
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 14:01:43 UTC
Created attachment 777333 [details]
Proposed fix

Comment 4 Rex Dieter 2013-07-23 14:10:53 UTC
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 14:15:42 UTC
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 14:25:03 UTC
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.