Bug 200937

I get the following on FC5 during the build process:
/usr/lib/libwx_gtk2-2.4.so: undefined reference to `pango_x_get_context'
collect2: ld returned 1 exit status
make[2]: *** [freqtweak] Error 1

I think this is due to bugzilla # 188941.

(In reply to comment #1)
> I get the following on FC5 during the build process:
> /usr/lib/libwx_gtk2-2.4.so: undefined reference to `pango_x_get_context'
> collect2: ld returned 1 exit status
> make[2]: *** [freqtweak] Error 1
> 
> I think this is due to bugzilla # 188941.

Strange, this should be taken care of by this part of the spec file:

%if "%{fc5}" == "1"
export LDFLAGS=`pkg-config --libs pangox `
%endif

At least I'm able to compile it fine in my build system (mach based). I thought
that the extras build system was actually setting fcx during the build...
perhaps it is not doing that?

On a vanilla (non-mach) FC5 system, this is what happens:

####################################################
# rpmbuild --rebuild --define fc5=1 freqtweak-0.6.1-4.src.rpm
[snip]
g++  -I/usr/lib/wx/include/gtk2-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I/usr/include/libxml2 -I/usr/lib/sigc++-1.2/include -I/usr/include/sigc++-1.2   -Wall -D_REENTRANT -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -O2 -fexpensive-optimizations -funroll-loops -finline-functions -ffast-math    -o 
freqtweak  FTapp.o FTmainwin.o FTioSupport.o FTjackSupport.o FTprocessPath.o 
FTspectralEngine.o FTspectragram.o FTspectrumModifier.o FTactiveBarGraph.o 
FTutils.o FTportSelectionDialog.o FTconfigManager.o RingBuffer.o xml++.o 
FTprocI.o FTprocDelay.o FTprocEQ.o FTprocGate.o FTprocPitch.o 
FTprocOrderDialog.o FTdspManager.o FTprocLimit.o FTprocWarp.o 
FTpresetBlendDialog.o FTpresetBlender.o FTprocCompressor.o FTprocBoost.o 
FThelpWindow.o FTmodulatorI.o FTmodulatorManager.o FTmodulatorDialog.o 
FTmodulatorGui.o FTmodRandomize.o FTmodRotate.o FTmodRotateLFO.o 
FTmodValueLFO.o  -lm  -lfftw3f -lm   -ljack   -pthread -lwx_gtk2-2.4 -L/usr/lib -lxml2 -lz -lm -lsigc-1.2
/usr/lib/libwx_gtk2-2.4.so: undefined reference to `pango_x_get_context'
collect2: ld returned 1 exit status
#######################################################

Prior to that, I had to install a few dependencies. There was a weird conflict 
between compat-wxGTK2-devel and compat-wxGTK-devel and I had to uninstall the 
latter.

(In reply to comment #3)
> On a vanilla (non-mach) FC5 system, this is what happens:
> 
> ####################################################
> # rpmbuild --rebuild --define fc5=1 freqtweak-0.6.1-4.src.rpm

I think it should be:
  --define "fc5 1"

(In reply to comment #2)
> At least I'm able to compile it fine in my build system (mach based). I thought
> that the extras build system was actually setting fcx during the build...
> perhaps it is not doing that?

The Fedora build systems define the macros %{dist} and %{fedora} for this purpose.
There is no %{fcX} style macro defined.

http://fedoraproject.org/wiki/Packaging/DistTag

Running this on FC5+CCRMA, all of the buttons in freqtweak show up blacked out
for me. I'd post a screenshot, but the laptop is already packed away for my
vacation ;->

Ok, now I see that if I define fc5 to 1 it builds.  My bad.

However, I'm getting the same results as Adrian in comment #6.  I'll look into
this a bit tonight.

(In reply to comment #5)
> (In reply to comment #2)
> > At least I'm able to compile it fine in my build system (mach based). I thought
> > that the extras build system was actually setting fcx during the build...
> > perhaps it is not doing that?
> 
> The Fedora build systems define the macros %{dist} and %{fedora} for this purpose.
> There is no %{fcX} style macro defined.
> 
> http://fedoraproject.org/wiki/Packaging/DistTag

Sorry, I missed this. Easy to fix. 

(In reply to comment #6)
> Running this on FC5+CCRMA, all of the buttons in freqtweak show up blacked out
> for me. I'd post a screenshot, but the laptop is already packed away for my
> vacation ;->

Strange, I don't see that. In my test machine some of the buttons (those on the
left of the editable frequency domain panes) have a font that is too large - the
text is slightly larger than the button itself, but I can see the text and they
work fine. Maybe a missing font in your machine (unlikely, I know)?

Created attachment 133610 [details]
black buttons

Built it on FC5, buttons are black.

(In reply to comment #4)
> 
> I think it should be:
>   --define "fc5 1"

Builds fine, but when running it the buttons are black, see the previously
created attachement.

(In reply to comment #10)
> (In reply to comment #4)
> > 
> > I think it should be:
> >   --define "fc5 1"
> 
> Builds fine, but when running it the buttons are black, see the previously
> created attachement.

I bet it is an interaction with the desktop theme. Could you try with the
default theme? I'll test this later. 

(In reply to comment #11)
> I bet it is an interaction with the desktop theme. Could you try with the
> default theme? I'll test this later. 

I'm using clearlooks, which (I think) is the default Fedora theme.  Let me mess
around with this as well.  Perhaps strace will provide some insight.

(In reply to comment #11)
> 
> I bet it is an interaction with the desktop theme. Could you try with the
> default theme? I'll test this later.

Can't test it right now, but anyway I never change the theme. I'm using whatever
comes default with FC5. The only thing I usually change in the way of desktop
look and feel is enable "Select windows when the mouse moves over them" which is
definitely unrelated.
I'll see if I can tweak a few things tonight.

My feeling is that it's an issue related to some kind of toolkit used by this
software. The widgets are clearly wrong. Maybe my system and yours have
different libraries installed? Some hidden dependency not explicited by the spec
file? Or some kind of difference in the minor version number in a lib somewhere?

What happens if you build the src.rpm on a clean fresh FC5 install? (only Fedora
Main, Updates and Extras)

Created attachment 135515 [details]
screenshot

Sorry for the long delay.  This builds on rawhide if I force fc5 = 1.  It would
be nice if we could special case <=fc4 and just let >=fc5 not require macro
tests.

I don't get black buttons on rawhide, which is great, but they still don't
render perfectly - see attached.  Poking at the code, I think this is a
FreqTweak bug and shouldn't prevent us from getting this packaged into rawhide
at least.  I'm going to continue with the review for rawhide (the fc5 black
buttons is still a mystery).

(In reply to comment #14)
> Created an attachment (id=135515) [edit]
> screenshot
> 
> Sorry for the long delay.  This builds on rawhide if I force fc5 = 1.  It would
> be nice if we could special case <=fc4 and just let >=fc5 not require macro
> tests.
> 
> I don't get black buttons on rawhide, which is great, but they still don't
> render perfectly - see attached. 

That's exactly what I see when building and running (successfully here) on fc5.
It'd be great to find the bug for the font size problem. 

> Poking at the code, I think this is a
> FreqTweak bug and shouldn't prevent us from getting this packaged into rawhide
> at least.  I'm going to continue with the review for rawhide (the fc5 black
> buttons is still a mystery).

Yep, sorry, I have not had time to try to debug this yet. Must be a library
version somewhere. 

Hi.  I went through the checklist quickly.  I think the two remaining issues are:

rpmlint is not silent:
  W: freqtweak strange-permission freqtweak-0.6.1.tar.gz 0600
  W: freqtweak mixed-use-of-spaces-and-tabs
  W: freqtweak patch-not-applied Patch1: freqtweak-0.6.1-addnoise.patch
These should be easy to clean up.  For the spaces/tabs thing, I just use the
untabify command in emacs.  As for the patch, is it supposed to be applied?

We should special case builds for <=fc4 systems and have defaults for fc5 and
greater.  The current SRPM builds on fc5, but not fc6 because of the special
tests for fc5.

Anything happening here?  It's been nine months since the last comment, and it
seems as if this package is almost ready (or was at the time).

No response in another seven months; closing.