[ATrpms-users] Re-building bleeding mythtv package

[Peter]

Axel,


I'm trying to rebuild your bleeding mythtv src rpm (
mythtv-0.21-163_trunk_r13756.src.rpm<http://dl.atrpms.net/src/fc6-x86_64/atrpms/bleeding/mythtv-0.21-163_trunk_r13756.src.rpm>)
and include a slightly more recent svn version (I'm wanting to build at
least svn rev13765). I've installed your src rpm and am able to rebuild it
as-is, by using 'rpmbuild -bb rpm/SPECS/mythtv.spec' command.

I've check'ed out the svn revision I want and tar/bzip'ed it up and
overwrite your mythtv-0.21.tar.bz2 file in rpm/SOURCES dir and tried
building again. Early on during the mythtv build I see that it is creating
files with a - 0.20 (when rebuilding your src rpm these are -0.21 as I'd
expect). If I leave the build to complete it errors as it can't find the
libmyth-0.21 file (as they are all libmyth-0.20).

<snip>
gcc -c -pipe -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith
-Wredundant-decls -Wno-pointer-sign -w -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fomit-frame-pointer
-D_REENTRANT -DPIC -fPIC  -DMMX -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-DPREFIX=\"/usr\" -DLIBDIR=\"/usr/lib64\" -DHAVE_AV_CONFIG_H
-D_LARGEFILE_SOURCE -I/usr/lib64/qt- 3.3/mkspecs/default -I. -I.. -I../.. -o
sha1.o sha1.c
rm -f libmythavutil-0.20.so.0.20.0 libmythavutil-0.20.so
libmythavutil-0.20.so.0 libmythavutil-0.20.so.0.20
g++ -shared -Wl,-soname, libmythavutil-0.20.so.0 -o
libmythavutil-0.20.so.0.20.0 adler32.o mathematics.o integer.o lls.o log.o
mem.o rational.o intfloat_readwrite.o crc.o md5.o fifo.o aes.o tree.o lzo.o
base64.o random.o sha1.o    -lpthread
ln -s libmythavutil-0.20.so.0.20.0 libmythavutil-0.20.so
ln -s libmythavutil-0.20.so.0.20.0 libmythavutil-0.20.so.0
ln -s libmythavutil-0.20.so.0.20.0 libmythavutil-0.20.so.0.20
make[2]: Leaving directory `/home/pleeke/rpm/BUILD/mythtv-0.21/mythtv-0.21
/libs/libavutil'


The mythtv.spec file has 'Version: 0.21' specified. This is FC6 x86_64, in
case its relevant. I must be missing something fairly obvious, but can't
work this one out. Any ideas?


Thanks
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.atrpms.net/pipermail/atrpms-users/attachments/20070627/aa694d9a/attachment.html