Adding patches in a SPEC

Wed Nov 17 22:26:34 UTC 2010

On Wed, 2010-11-17 at 07:39 -0500, Eric "Sparks" Christensen wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 11/17/2010 03:57 AM, Martin Sourada wrote:
> > On Tue, 2010-11-16 at 17:17 -0500, Eric "Sparks" Christensen wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 11/16/2010 04:28 PM, Martin Sourada wrote:
> >>> On Tue, 2010-11-16 at 11:18 -0500, Eric "Sparks" Christensen wrote:
> >>>> On Tue, Nov 16, 2010 at 11:04, Patrick MONNERAT <pm at datasphere.ch> wrote:
> >>>>> On Tue, 2010-11-16 at 17:48 +0200, Andy Shevchenko wrote:
> >>>>>> You need to do patch on top of source tree container
> >>>>>>
> >>>>>> mycoolpkg-5.3/
> >>>>>>     /Makefile
> >>>>>>     /source.c
> >>>>>> ...
> >>>>>> mycoolpkg-5.3.new/
> >>>>>>    /Makefile
> >>>>>>    /source.c
> >>>>>> ...
> >>>>>>
> >>>>>> run  diff -ruN -p mycoolpkg-5.3 mycoolpkg-5.3.new
> >>>>>>
> >>>>>
> >>>>> ... and use %patch0 -p 1 ...
> >>>>
> >>>> Okay, I ran the above diff and created a nice patch:
> >>>>
> >>>> diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
> >>>> --- gpredict-1.2/Makefile       2010-11-15 20:07:20.676418835 -0500
> >>>> +++ gpredict-1.2.new/Makefile   2010-11-16 11:04:49.677590541 -0500
> >>>> @@ -168,7 +168,7 @@ OTOOL64 =
> >>>>  PACKAGE = gpredict
> >>>>  PACKAGE_BUGREPORT =
> >>>>  PACKAGE_CFLAGS = -pthread -I/usr/include/gtk-2.0
> >>>> -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
> >>>> -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0
> >>>> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> >>>> -I/usr/include/pixman-1 -I/usr/include/freetype2
> >>>> -I/usr/include/libpng12 -I/usr/include/goocanvas-1.0
> >>>> -PACKAGE_LIBS = -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
> >>>> -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> >>>> -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
> >>>> -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
> >>>> +PACKAGE_LIBS = -lm -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0
> >>>> -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0
> >>>> -lm -lcairo -lpng12 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
> >>>> -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcurl
> >>>>  PACKAGE_NAME =
> >>>>  PACKAGE_STRING =
> >>>>  PACKAGE_TARNAME =
> >>>>
> >>>> I changed the SPEC to say "%patch0 -p 1".  I get the same error (below):
> >>>>
> >>>> [user at server rpmbuild]$ rpmbuild -ba SPECS/gpredict.spec
> >>>> Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.wAGj7E
> >>>> + umask 022
> >>>> + cd /home/christensene/rpmbuild/BUILD
> >>>> + LANG=C
> >>>> + export LANG
> >>>> + unset DISPLAY
> >>>> + cd /home/christensene/rpmbuild/BUILD
> >>>> + rm -rf gpredict-1.2
> >>>> + /usr/bin/gzip -dc /home/user/rpmbuild/SOURCES/gpredict-1.2.tar.gz
> >>>> + /bin/tar -xf -
> >>>> + STATUS=0
> >>>> + '[' 0 -ne 0 ']'
> >>>> + cd gpredict-1.2
> >>>> + /bin/chmod -Rf a+rX,u+w,g-w,o-w .
> >>>> + echo 'Patch #0 (gpredict-1.2-DSO.patch):'
> >>>> Patch #0 (gpredict-1.2-DSO.patch):
> >>>> + /bin/cat /home/user/rpmbuild/SOURCES/gpredict-1.2-DSO.patch
> >>>> + /usr/bin/patch -s -p1 --fuzz=0
> >>>> The text leading up to this was:
> >>>> --------------------------
> >>>> |diff -ruN -p gpredict-1.2/Makefile gpredict-1.2.new/Makefile
> >>>> |--- gpredict-1.2/Makefile      2010-11-15 20:07:20.676418835 -0500
> >>>> |+++ gpredict-1.2.new/Makefile  2010-11-16 11:04:49.677590541 -0500
> >>>> --------------------------
> >>> That might be because the Makefile actually isn't there -- it's usually
> >>> created from Makefile.in after calling ./configure. IMHO you have
> >>> several options
> >>>       * use sed to make the change, after running configure
> >>>       * patch Makefile.in instead of Makefile
> >>>       * patch Makefile.am and reconfigure (autoreconf --force,
> >>>         or ./autogen.sh, depending how autotools are handled in
> >>>         gpredict)
> >>>
> >>> And anyway, why are you trying to patch it this way? Unless I missed
> >>> something you're adding -lm to PACKAGE_LIBS which is however already
> >>> present (prior to -lcairo) there.
> >>>
> >>> Martin
> >>>
> >>
> >> I ran into the following error when I was building the SRPM:
> >>
> >> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
> >> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
> >> /lib64/libm.so.6 so try adding it to the linker command line
> >> /lib64/libm.so.6: could not read symbols: Invalid operation
> >> collect2: ld returned 1 exit status
> >> make[4]: *** [test-002] Error 1
> >> make[4]: *** Waiting for unfinished jobs....
> >> /usr/bin/ld: solar.o: undefined reference to symbol 'sincos@@GLIBC_2.2.5'
> >> /usr/bin/ld: note: 'sincos@@GLIBC_2.2.5' is defined in DSO
> >> /lib64/libm.so.6 so try adding it to the linker command line
> >> /lib64/libm.so.6: could not read symbols: Invalid operation
> >>
> >>
> >> I was told that I needed to add the -lm to the PACKAGE_LIBS which is
> >> what I was trying to do.  If this is NOT what I need to do or I need to
> >> fix this in a different manner I'm open to suggestions.
> >>
> > Well, the thing is, unless I read the patch incorrectly, that -lm
> > already is in PACKAGE_LIBS, so this error is even more confusing. Does
> > it build with the patched Makefile (i.e. does running make after editing
> > the Makefile works)?
> > 
> > Actually, I've just searched a bit over the net, try doing something
> > along the lines of this patch (to different package)
> > http://launchpadlibrarian.net/48982549/0001-Fix-building-clutk-with-implicit-DSO-change-in-Fedor.patch
> > 
> > Perhaps, it would be best if you committed the changes you want to make
> > to git so that people here could look into it in full context.
> > 
> > Martin
> 
> So just to add another twist to the problem, if I build from source on
> my computer, not using rpmbuild, everything works just fine.  I put the
> SPEC and the source into rpmbuild and FAIL.
That's interesting, and most likely beyond my ability to help, but maybe
connected to the build flags fedora rpmbuild uses... Does it also fail
if built via koji (i.e. commit to fedora git and do fedpkg build; or
just do a scratch build)?

> 
> I could post everything up to my fpeople account if someone would like
> to look at everything that I have.
> 
Just pushing the intended changes (without the patch, at least
initially) to fedora git is fine (every package maintainer can do fedpkg
clone gpredict).

Cheers,
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20101117/54f50156/attachment.bin