|
Description
Francois Andriot
2013-07-04 13:08:31 CDT
Created attachment 1328 [details]
tdebindings : add missing LDFLAGS causing FTBFS
Created attachment 1329 [details]
tdemultimedia : add missing LDFLAGS causing FTBFS
Note: $(VORBIS_LIBS) is mandatory.
I have to add "-lmad" too, but this may be a consequence of building AKODE support. I'm not sure "-lmad" is required without AKODE.
Created attachment 1330 [details]
tqt3 : fix ftbfs in qvfb with libpng >= 1.5
Created attachment 1331 [details]
libtdeldap : add missing LDFLAGS causing FTBFS
Created attachment 1332 [details]
libtqt-perl : fix build with automake >= 1.13
Created attachment 1333 [details]
python-trinity : fix FTBFS because invalid include directory
I added the report to the R14 etherpad road map. I have no automake 1.13 support in "admin" folder in following component: tdeio-apt tdeio-umountwrapper tderadio tdmtheme (Odpověď na komentář #8)
> I have no automake 1.13 support in "admin" folder in following component:
> tdeio-apt
> tdeio-umountwrapper
> tderadio
> tdmtheme
I did update modules. We'll see if automated system revert updates back or leave current state.
Created attachment 1337 [details]
kbiff : fix FTBFS because missing LDFLAGS
kbibtex builds out of the box, but kbiff requires the attached patch.
kvirc FTBFS because in all .h file, there is Q_OBJECT defined but no TQ_OBJECT . Update source code with: sed -i src/*/*/*.h src/*/*/*.sh -e "s|Q_OBJECT|TQ_OBJECT|" Comment on attachment 1337 [details]
kbiff : fix FTBFS because missing LDFLAGS
Pushed to GIT in hash 79960d05.
Thank you for testing and patch.
Created attachment 1338 [details]
gtk3-tqt-engine: fix FTBFS because missing LDFLAGS
(Odpověď na komentář #11) > kvirc FTBFS because in all .h file, there is Q_OBJECT defined but no TQ_OBJECT > . > > Update source code with: > sed -i src/*/*/*.h src/*/*/*.sh -e "s|Q_OBJECT|TQ_OBJECT|" This is strange, because in any other module is not used TQ_OBJECT, but Q_OBJECT. In addition, when using TQ_OBJECT then not working automoc to generate MOC. See: http://trinity-users.pearsoncomputing.net/?0::5080 (En réponse au commentaire 14)
> (Odpověď na komentář #11)
> > kvirc FTBFS because in all .h file, there is Q_OBJECT defined but no TQ_OBJECT
> > .
> >
> > Update source code with:
> > sed -i src/*/*/*.h src/*/*/*.sh -e "s|Q_OBJECT|TQ_OBJECT|"
>
> This is strange, because in any other module is not used TQ_OBJECT, but
> Q_OBJECT. In addition, when using TQ_OBJECT then not working automoc to
> generate MOC. See:
>
> http://trinity-users.pearsoncomputing.net/?0::5080
Interesting, I have the exact opposite behaviour (in kvirc only).
When using Q_OBJECT, I get several messages like this:
/usr/bin/tqmoc ../tal/kvi_tal_application_kde.h -o ../tal/kvi_tal_application_kde.moc
../tal/kvi_tal_application_kde.h:0: Warning: No relevant classes found. No output generated.
Then FTBFS
../tal/kvi_tal_iconview_qt3.h:77: Error: The declaration of the class "KviTalIconView" contains signals or slots
but no TQ_OBJECT macro.
Using TQ_OBJECT solves this.
Created attachment 1339 [details]
kvirc FTBFS build log
(Odpověď na komentář #10)
> Vytvořena příloha 1337
> kbiff : fix FTBFS because missing LDFLAGS
>
> kbibtex builds out of the box, but kbiff requires the attached patch.
Note: For KBiff you have in tde-packaging wrong description and dependencies.
file "pkgconfig/tdelibs.pc" makes other packages FTBFS on some distro because missing variable "Version". E.g: echo "Version: 14.0.0" >>"tdelibs.pc" Slavek thanks for pointing kbiff mistake, it is fixed now; kdbg built successfully without any patch. I'm done building all R14 packages on Mageia 3 now. There should be very few build issues on other distributions. Created attachment 1348 [details]
tdelibs : fix FTBFS because of libart_lgpl and libudev
Hello, 2 more FTBFS found on CentOS 6 in tdelibs :
1) Libart LGPL libraries are not found if they are installed in a nonstandard directory;
2) "#include <libudev.h>" must be called with "extern C".
Created attachment 1349 [details]
tdebase : fix FTBFS when libart_lgpl has nonstandard directory
Created attachment 1360 [details]
tqt3 : build as shared library instead of static library
Not an FTBFS, but I prefer building TQT3 as shared library (libtqt-mt.so.3.5.0) instead of static.
Created attachment 1370 [details]
python-tqt : fix FTBFS
I encountered 2 problems in python-tqt :
1) When using distribution-provided SIP, the C++ type "pyqt3TQtSignal" does not exist, I only have "pyqt3QtSignal". I saw that Trinity's provided SIP has renamed Qt to TQt, so the type was renamed too. But then we are now incompatible with original SIP ! Personlay, I do not want/need to build Trinity's SIP since the distribution one works correclty, apart from that renaming issue.
2) Under CentOS 6 only, makefile generation for pyuic3 and pylupdate3 fails if the target directory does not exist prior to running the command. So I need to "mkdir" the directories first.
Created attachment 1371 [details]
python-tqt : fix FTBFS (2)
Better patch, check if directory exists before creating it (avoid python exception !!!)
Created attachment 1373 [details]
tdenetwork : use alternate 'resolv.conf' in kppp, if available (redhat legacy)
Hey, I've found out some more legacy patches that I did not submit here !
This patch makes KPPP try to use file "/var/run/ppp/resolv.conf", if available, prior to using "/etc/ppp/resolv.conf".
I dunno what the purpose is, I guess that at some point of history, Fedora had its own configuration directory.
Created attachment 1374 [details]
tdenetwork : update krfb_httpd script (redhat legacy)
Still dunno exactly what this one does.
It is related to the "Desktop Sharing" feature, which is using VNC server, which can be accessed via HTTP.
It looks like this page takes into account a new/different version of the VNC server.
Created attachment 1424 [details]
tdeio-apt : fix FTBFS when using --enable-final
Hello, I've found that activating the option "--enable-final" on some packages cause FTBFS. So here is a patch for tdeio-apt .
Created attachment 1425 [details]
tellico : fix FTBFS "not a string literal error"
The attached patch is for 3.5.13.2 but should work on 14.0.0 or be easily portable.
Created attachment 1426 [details]
k9copy : fix FTBFS with newer libavcodec library
Another patch for 3.5.13.2 which should work for 14.0.0.
Created attachment 1433 [details]
krecipes : fix FTBFS because missing LDFLAGS
Comment on attachment 1433 [details]
krecipes : fix FTBFS because missing LDFLAGS
Pushed to GIT in hash 05371289.
Comment on attachment 1425 [details]
tellico : fix FTBFS "not a string literal error"
Pushed to GIT in hash e22d244e.
Comment on attachment 1332 [details]
libtqt-perl : fix build with automake >= 1.13
Pushed to GIT in hash 40f0f2ae.
Comment on attachment 1426 [details]
k9copy : fix FTBFS with newer libavcodec library
Pushed to GIT in hash 76443cbb.
Comment on attachment 1338 [details]
gtk3-tqt-engine: fix FTBFS because missing LDFLAGS
Pushed to GIT in hash 273baf5f.
Comment on attachment 1348 [details]
tdelibs : fix FTBFS because of libart_lgpl and libudev
Pushed to GIT in hash 6b1e323c and 12b5e141.
Comment on attachment 1349 [details]
tdebase : fix FTBFS when libart_lgpl has nonstandard directory
Pushed to GIT in hash 9f749e63.
Sorry, I made a mistake in attachment 1426 [details], about k9copy and libavcodec library. The correct version should be '54.25' NOT '53.26' See: https://github.com/FFmpeg/FFmpeg/commit/104e10fb426f903ba9157fdbfe30292d0e4c3d72 (Odpověď na komentář #39)
> Sorry, I made a mistake in attachment 1426 [details], about k9copy and libavcodec
> library.
> The correct version should be '54.25' NOT '53.26'
>
> See:
> https://github.com/FFmpeg/FFmpeg/commit/104e10fb426f903ba9157fdbfe30292d0e4c3d72
Fixed in GIT hash b375ac5d.
libcarddav FTBFS on Mageia 3 because file "ChangeLog' is empty. The 'configure.ac' file checks the software version by running the "version.sh" script, which read the number in ChangeLog. This step fails and causes the "./autogen.sh" script to fail entirely. I see in GIT that the ChangeLog existed in initial import, so why empty it afterward ? I also see the following libcarddav build message: configure.ac:26: error: AC_INIT should be called with package and version arguments Created attachment 1441 [details]
tdemultimedia : add missing LDFLAGS causing FTBFS (2)
New patch for tdemultimedia FTBFS.
Still missing flags for Vorbis stuff, but also for Mad.
Unlike what I thought before, the need for "-lmad" in tdemultimedia is NOT related to having Akode support, it's in fact related to having ARTS compiled with MAD support. So whenever Arts has -DWITH_MAD=ON set, we need the "-lmad" here.
Comment on attachment 1339 [details]
kvirc FTBFS build log
The KVIRC problem is solved.
I was using:
--with-qt-moc=/usr/bin/tqmoc
But now I use:
--with-qt-moc=/usr/bin/tmoc
And now it works with Q_OBJECT.
Created attachment 1442 [details]
kvirc : install in correct folder
By default, kvirc install its stuff under /opt/trinity/share/kvirc/ , but at runtime, it looks under /opt/trinity/lib/kvirc .
I see in the Ubuntu packaging that there is a brutal "mv" command at the end of the install ...
The attached patch makes installation directly in the correct folder.
Created attachment 1451 [details]
tqt3 : remove dead symlink under 'mkspecs/default'
When installing tqt3-devel package, I always get a dead symlink '/usr/share/tqt3/mkspecs/default/linux-g++-64 , which points to a temporary build directory.
The attached patch removes the creation of this dead link.
Created attachment 1455 [details]
tqt3 : fix "not a string literal" error
Created attachment 1457 [details]
tqt3 : fix "not a string literal" error (2)
Comment on attachment 1457 [details]
tqt3 : fix "not a string literal" error (2)
Fixed in GIT hash 16f24a61 (Qt3) and 13618b73 (TQt3).
Comment on attachment 1330 [details]
tqt3 : fix ftbfs in qvfb with libpng >= 1.5
Fixed in GIT hads af5bc055 (Qt3) and 3af9b39a (TQt3)
Created attachment 1476 [details]
tdebindings : fix libtool refuses to install in RUBY directory
Strange problem on Fedora 19 ...
Our "configure.in.in" files check ruby directories using "ruby -r ...." commands.
On Fedora 19, it returns, among others:
RUBY_ARCHDIR=/usr/lib64/ruby/
Notice there is "/" at the end of the path.
Then, during "make install", libtool exits with error, saying that "qtruby.la" cannot be installed under a path not ending with "/usr/lib64/ruby" (without the ending slash).
It looks like recent versions of libtool are very strict about path.
The attached patch makes sure that our RUBY detection removes the potential ending slashes. It works for both 3.5.13.2 and 14.0.0 .
Error log:
make[5]: Entering directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdebindings-3.5.13.2/qtruby/rubylib/qtruby'
make[5]: Nothing to be done for `install-exec-am'.
/bin/mkdir -p '/dev/shm/BUILDROOT.fc19.x86_64/trinity-tdebindings-3.5.13.2-2.fc19.opt.x86_64/usr/lib64/ruby/'
/bin/sh ../../../libtool --mode=install /bin/install -c -p qtruby.la '/dev/shm/BUILDROOT.fc19.x86_64/trinity-tdebindings-3.5.13.2-2.fc19.opt.x86_64/usr/lib64/ruby/'
libtool: install: error: cannot install `qtruby.la' to a directory not ending in /usr/lib64/ruby/
make[5]: *** [install-rubylibLTLIBRARIES] Error 1
make[5]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdebindings-3.5.13.2/qtruby/rubylib/qtruby'
make[4]: *** [install-am] Error 2
make[4]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdebindings-3.5.13.2/qtruby/rubylib/qtruby'
make[3]: *** [install-recursive] Error 1
make[3]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdebindings-3.5.13.2/qtruby/rubylib/qtruby'
make[2]: *** [install-recursive] Error 1
make[2]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdebindings-3.5.13.2/qtruby/rubylib'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdebindings-3.5.13.2/qtruby'
make: *** [install-recursive] Error 1
Created attachment 1477 [details]
tdesdk : fix cervisia pod
When building on Fedora 19, I get the error:
[ 5%] Generating cervisia.1
cd /dev/shm/BUILD.fc19.x86_64/trinity-tdesdk-3.5.13.2/build/cervisia && pod2man /dev/shm/BUILD.fc19.x86_64/trinity-tdesdk-3.5.13.2/cervisia/cervisia.pod > cervisia.1.in
/dev/shm/BUILD.fc19.x86_64/trinity-tdesdk-3.5.13.2/cervisia/cervisia.pod around line 87: You forgot a '=back' before '=head1'
POD document had syntax errors at /bin/pod2man line 69.
make[2]: *** [cervisia/cervisia.1] Error 255
make[2]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdesdk-3.5.13.2/build'
make[1]: *** [cervisia/CMakeFiles/cervisia-man.dir/all] Error 2
make[1]: Leaving directory `/dev/shm/BUILD.fc19.x86_64/trinity-tdesdk-3.5.13.2/build'
make: *** [all] Error 2
Attached patch fixes it. (both 3.5.13.2 and 14.0.0)
Created attachment 1478 [details]
koffice : fix FTBFS on Fedora 19
Koffice FTBFS on Fedora 19
In file included from /usr/include/tqt/tqdom.h:32:0,
from basicelement.h:25,
from basicelement.cc:25,
from libkformulalib_la.all_cc.cc:2:
/usr/lib64/qt-3.3/include/qdom.h: At global scope:
/usr/lib64/qt-3.3/include/qdom.h:514:5: error: 'QDomElement::QDomElement(QDomElementPrivate*)' is private
QDomElement( QDomElementPrivate* );
^
In file included from sequenceelement.cc:36:0,
from libkformulalib_la.all_cc.cc:8:
creationstrategy.h:89:85: error: within this context
virtual BasicElement* createElement( TQString type, const TQDomElement& element = 0 );
Created attachment 1479 [details]
ktechlab : fix FTBFS on Fedora 19
Created attachment 1480 [details]
krusader : fix FTBFS on Fedora 19
(Odpověď na komentář #51)
> Vytvořena příloha 1476
> tdebindings : fix libtool refuses to install in RUBY directory
>
> Strange problem on Fedora 19 ...
> Our "configure.in.in" files check ruby directories using "ruby -r ...."
> commands.
> On Fedora 19, it returns, among others:
> RUBY_ARCHDIR=/usr/lib64/ruby/
> Notice there is "/" at the end of the path.
>
> Then, during "make install", libtool exits with error, saying that "qtruby.la"
> cannot be installed under a path not ending with "/usr/lib64/ruby" (without the
> ending slash).
>
> It looks like recent versions of libtool are very strict about path.
>
> The attached patch makes sure that our RUBY detection removes the potential
> ending slashes. It works for both 3.5.13.2 and 14.0.0 .
>
I understand that the same fix is also suitable for KOffice?
(En réponse au commentaire 56) > (Odpověď na komentář #51) > I understand that the same fix is also suitable for KOffice? I did not get this particular error when building Koffice. Created attachment 1486 [details] tdelibs: add version to pkgconfig file In connection with the comment 18 I prepared a patch for autocompletion version number in the pkgconfig file. François, others, please test it. Created attachment 1487 [details]
tqt3: fix symlink 'mkspecs/default'
Instead of removal symlink creation I tried to fix it.
François, others, please test it.
(En réponse au commentaire 59)
> Fichier joint créé 1487
> tqt3: fix symlink 'mkspecs/default'
>
> Instead of removal symlink creation I tried to fix it.
> François, others, please test it.
Hello, the symlink "default" is already created with correct target earlier in the "configure" script, so I don't see the point of recreating (correctly or not) here.
(Odpověď na komentář #60) > (En réponse au commentaire 59) > > Fichier joint créé 1487 > > tqt3: fix symlink 'mkspecs/default' > > > > Instead of removal symlink creation I tried to fix it. > > François, others, please test it. > > Hello, the symlink "default" is already created with correct target earlier in > the "configure" script, so I don't see the point of recreating (correctly or > not) here. Yes, you're right, of course - I did not look into the configure script. It has a patch from attachment 1487 [details] is therefore invalid and I'll push your patch from attachment 1451 [details]. attachement 1486 is OK for tdelibs => you can push it. Comment on attachment 1487 [details] tqt3: fix symlink 'mkspecs/default' Instead of this invalid patch was pushed patch from attachment 1451 [details] Comment on attachment 1486 [details]
tdelibs: add version to pkgconfig file
Pushed to GIT in hash 8e37bb97.
Comment on attachment 1424 [details]
tdeio-apt : fix FTBFS when using --enable-final
Pushed to GIT in hash c4c5713c.
Comment on attachment 1477 [details]
tdesdk : fix cervisia pod
Pushed to GIT in hash 737fd486.
Comment on attachment 1331 [details]
libtdeldap : add missing LDFLAGS causing FTBFS
Pushed to GIT in hash ce1a8700.
(Odpověď na komentář #43)
> Vytvořena příloha 1441
> tdemultimedia : add missing LDFLAGS causing FTBFS (2)
>
> New patch for tdemultimedia FTBFS.
> Still missing flags for Vorbis stuff, but also for Mad.
>
> Unlike what I thought before, the need for "-lmad" in tdemultimedia is NOT
> related to having Akode support, it's in fact related to having ARTS compiled
> with MAD support. So whenever Arts has -DWITH_MAD=ON set, we need the "-lmad"
> here.
We should add a check for the presence of libmad?
Or we assume that all built arts with mad?
(Odpověď na komentář #43)
> Vytvořena příloha 1441
> tdemultimedia : add missing LDFLAGS causing FTBFS (2)
>
> New patch for tdemultimedia FTBFS.
> Still missing flags for Vorbis stuff, but also for Mad.
>
> Unlike what I thought before, the need for "-lmad" in tdemultimedia is NOT
> related to having Akode support, it's in fact related to having ARTS compiled
> with MAD support. So whenever Arts has -DWITH_MAD=ON set, we need the "-lmad"
> here.
We should add a check for the presence of libmad?
Or we assume that all built arts with mad?
(En réponse au commentaire 69)
> (Odpověď na komentář #43)
> > Vytvořena příloha 1441
> > tdemultimedia : add missing LDFLAGS causing FTBFS (2)
> >
> > New patch for tdemultimedia FTBFS.
> > Still missing flags for Vorbis stuff, but also for Mad.
> >
> > Unlike what I thought before, the need for "-lmad" in tdemultimedia is NOT
> > related to having Akode support, it's in fact related to having ARTS compiled
> > with MAD support. So whenever Arts has -DWITH_MAD=ON set, we need the "-lmad"
> > here.
>
> We should add a check for the presence of libmad?
> Or we assume that all built arts with mad?
I'm not sure...
Maybe we should change the pkgconfile file from arts, so that it has the "-lmad" flag when built with MAD.
Then, tdemultimedia would simply use the pkgconfig from Arts.
Created attachment 1497 [details]
tdebindings : fix ruby 2.0 detection
opensuse 13.1 will come with ruby 2.0. Here is a patch to build tdebindings with ruby 2.0 (patch for 3.5.13.2 but should work in R14 too)
Created attachment 1498 [details]
libksquirrel : add support for Giflib 5.0 (FTBFS in opensuse 13.1)
Created attachment 1499 [details]
libksquirrel : add support for Giflib 5.0 (FTBFS in opensuse 13.1) (2)
Created attachment 1500 [details]
koffice : fix ruby 2.0 detection
Comment on attachment 1328 [details]
tdebindings : add missing LDFLAGS causing FTBFS
Pushed to GIT in hash 03f7d427.
Comment on attachment 1476 [details]
tdebindings : fix libtool refuses to install in RUBY directory
Pushed to GIT in hash dcb2a2fb.
Comment on attachment 1497 [details]
tdebindings : fix ruby 2.0 detection
Pushed to GIT in hash 2cf2b76c
Comment on attachment 1478 [details]
koffice : fix FTBFS on Fedora 19
Pushed to GIT in hash dee1a982.
Comment on attachment 1500 [details]
koffice : fix ruby 2.0 detection
Pushed to GIT in hash 7d099fe4.
Comment on attachment 1499 [details]
libksquirrel : add support for Giflib 5.0 (FTBFS in opensuse 13.1) (2)
In all conditions added "defined(GIFLIB_MAJOR) && " and pushed to GIT in hash a433569b.
Comment on attachment 1479 [details]
ktechlab : fix FTBFS on Fedora 19
Pushed to GIT in hash cd721557.
Comment on attachment 1333 [details]
python-trinity : fix FTBFS because invalid include directory
Pushed to GIT in hash a44e65a8.
(Odpověď na komentář #55)
> Vytvořena příloha 1480
> krusader : fix FTBFS on Fedora 19
I think that the patch needs some adjustments. The proposed form would be umount all tmp vfs without distinction => regardless of whether is mounted.
(Odpověď na komentář #45)
> Vytvořena příloha 1442
> kvirc : install in correct folder
>
> By default, kvirc install its stuff under /opt/trinity/share/kvirc/ , but at
> runtime, it looks under /opt/trinity/lib/kvirc .
>
> I see in the Ubuntu packaging that there is a brutal "mv" command at the end of
> the install ...
>
> The attached patch makes installation directly in the correct folder.
Although the "mv" in debian/ubuntu packaging looks "brutally" actually moves "only" libraries - ie *.la and *.so from modules. Other "share" remain in place.
It would be possible to separate installation for data and libraries?
Created attachment 1504 [details] krusader : fix FTBFS on tmpvfs Within the meaning of comment 83 I have prepared an alternative patch. Please test it. (En réponse au commentaire 85)
> Fichier joint créé 1504
> krusader : fix FTBFS on tmpvfs
>
> Within the meaning of comment 83 I have prepared an alternative patch.
> Please test it.
It builds correctly with your patch.
Created attachment 1505 [details]
kvirc : install in correct folder (2)
New patch for kvirc so that only modules are moved from "share" to "lib".
Comment on attachment 1504 [details]
krusader : fix FTBFS on tmpvfs
Pushed to GIT in hash d7e200c5.
Comment on attachment 1505 [details]
kvirc : install in correct folder (2)
It looks good, thanks.
Pushed to GIT in hash a5b7be7d.
Created attachment 1511 [details] k3b : fix FTBFS with newer ffmpeg It looks like the AVCODEC_MAX_AUDIO_FRAME_SIZE macro has been deprecated in FFMPEG and causes FTBFS in K3B. The attached patch use the hardcoded value 192000 instead. See: http://ffmpeg.org/pipermail/ffmpeg-cvslog/2012-August/053785.html https://github.com/jiixyj/libebur128/issues/19 Created attachment 1514 [details]
kkbswitch : fix FTBFS because missing include
Comment on attachment 1514 [details]
kkbswitch : fix FTBFS because missing include
Pushed to GIT in hash f4cd558c.
Comment on attachment 1511 [details]
k3b : fix FTBFS with newer ffmpeg
Pushed to GIT in hash 7de21d9e
Created attachment 1515 [details] arts : add requires to pkgconfig file I have prepared a patch for the arts, as proposed in comment 70. It remains to fix tdemultimedia to use pkg-config. It is also possible that the patch will cause FTBFS in other packages - for example in tdelibs is called mcopidl with -I${ARTS_INCLUDE_DIRS} instead of -I{ARTS_INCLUDEDIR}. I'll fix this soon. Please test this patch. Your patch is OK for ARTS. Created attachment 1517 [details]
tdemultimedia : add missing LDFLAGS causing FTBFS (3)
OK this new patch allows building tdemultimedia using the flags sets in 'arts.pc'.
(Odpověď na komentář #96)
> Vytvořena příloha 1517
> tdemultimedia : add missing LDFLAGS causing FTBFS (3)
>
> OK this new patch allows building tdemultimedia using the flags sets in
> 'arts.pc'.
$(VORBIS_LIBS) and $(VORBISFILE_LIBS) are still needed?
For me both are part of the $(ARTS_LIBS).
No, it works even when removing them. You can remove them. Comment on attachment 1515 [details]
arts : add requires to pkgconfig file
Pushed to GIT in hash f22daba7.
tdelibs FTBFS fixed in GIT hash eeb482ba.
Comment on attachment 1517 [details]
tdemultimedia : add missing LDFLAGS causing FTBFS (3)
Adjusted and pushed to GIT in hash 1f5ba242.
Thank you for your cooperation.
Comment on attachment 1374 [details]
tdenetwork : update krfb_httpd script (redhat legacy)
Pushed to GIT in hash efa390ac.
Created attachment 1529 [details]
sip4-tqt : Revert pyqt3TQtSignal to pyqt3QtSignal
If rename pyqt3TQtSignal is the only one violation of compatibility with the original SIP4, looks like a good idea to revert this renaming. Proposed patch attached.
What do you think?
(En réponse au commentaire 102)
> Fichier joint créé 1529
> sip4-tqt : Revert pyqt3TQtSignal to pyqt3QtSignal
>
> If rename pyqt3TQtSignal is the only one violation of compatibility with the
> original SIP4, looks like a good idea to revert this renaming. Proposed patch
> attached.
>
> What do you think?
Yes, I think it's reasonable to revert just this part. Patch looks good.
Comment on attachment 1529 [details]
sip4-tqt : Revert pyqt3TQtSignal to pyqt3QtSignal
Pushed to GIT in hash 9b74ae48.
Comment on attachment 1371 [details]
python-tqt : fix FTBFS (2)
Pushed to GIT as separate commits 275a3ec4 and 92310a96.
François, I'm sorry, I forgot set you as the author of patches for python-tqt. Created attachment 1547 [details]
tdeio-sword: fix sword detection
For an unknown reason, I now need the attached patch to build tdeio-sword in Mageia 3. It used to work since then on the same computer, but who knows what happened ...
Comment on attachment 1547 [details]
tdeio-sword: fix sword detection
Pushed to GIT in hash 42549c3.
Is this bug report still needed? (Odpověď na komentář #109) > Is this bug report still needed? I hesitate, how to deal with the last patches. patch in attachment 1360 [details] - seems good to me patch in attachment 1373 [details] - I'm not sure if it is right to add non-standard path, or leave this patch as a distribution specific Created attachment 1875 [details] tqt3 : fix FTBFS due to hidden visibility when building as a shared library I tested the patch from attachment 1360 [details] but occurred FTBFS. I have found that it is caused due to hidden visibility. Attached patch solve this problem. Comment on attachment 1360 [details]
tqt3 : build as shared library instead of static library
Pushed to GIT in hash 1e11c1dd (Qt3) and 2ee14b64 (TQt3)
Comment on attachment 1875 [details]
tqt3 : fix FTBFS due to hidden visibility when building as a shared library
Pushed to GIT in hash 53479506 (Qt3) and dab0c5cd (TQt3)
Created attachment 1949 [details]
bibletime: fix FTBFS on Fedora 20, fix custom-installed Sword detection
Created attachment 2049 [details]
koffice-i18n: fix invalid syntax in pt_BR translation
FTBFS in brasilian translation because of missing closing tag.
Comment on attachment 1949 [details]
bibletime: fix FTBFS on Fedora 20, fix custom-installed Sword detection
Pushed to GIT in hash 298da70a.
Comment on attachment 2049 [details]
koffice-i18n: fix invalid syntax in pt_BR translation
Pushed to GIT in hash 9a9219b2.
Comment on attachment 1373 [details]
tdenetwork : use alternate 'resolv.conf' in kppp, if available (redhat legacy)
Pushed to GIT in hash e0801ae2.
|