tde-devels

devels@trinitydesktop.org

4 participants
3805 discussions

Re: [trinity-devel] python-tqt FTBFS
by Darrell Anderson 29 Jan '14

29 Jan '14

>Look at the comments 1, 2 and 3 in the bug 1790. In principle: >adding of >folder sip4-tqt, respectively, python-tqt in the call configure.py >and create empty __ init__.py file. Thank you. Would you or somebody please post a simple listing of the final package contents? Darrell

1 0

Re: [trinity-devel] python-tqt FTBFS
by Darrell Anderson 29 Jan '14

29 Jan '14

>sip4-tqt and python-tqt is now a need to build as a python >modules. Look >for information from François in bug 1790 and the build scripts in >RedHat >and Debian. > >http://bugs.pearsoncomputing.net/show_bug.cgi?id=1790 >http://git.trinitydesktop.org/cgit/tde- >packaging/tree/debian/squeeze/dependencies/sip4-tqt/debian/rules >http://git.trinitydesktop.org/cgit/tde- >packaging/tree/debian/squeeze/dependencies/python-tqt/debian/rules > >Maybe it would be good to modify sip4-tqt and python-tqt to >internally >implement the installation as modules. Python but I'm not so >buddy, to I >dared to do it. I don't understand what you mean by building as python modules, but I'll look and try to update my build scripts. Pretty much the entire tdebindings chain is affected. Darrell

2 1

python-tqt FTBFS
by Darrell Anderson 29 Jan '14

29 Jan '14

I am unable to build python-tqt. The failure: Traceback (most recent call last): File "configure.py", line 31, in <module> from sip4_tqt import sipconfig ImportError: No module named sip4_tqt make: *** No targets specified and no makefile found. Stop. I don't have anything in my sip4-tqt package named sip4_tqt. Reversing commit bef77650 allows python-tqt to build. What is the conflict? Darrell

2 1

Re: [trinity-devel] R14 RC1 ready?
by Darrell Anderson 29 Jan '14

29 Jan '14

>Darrell spent some time to write about outstanding issues. Not >many fortunately. > >What exactly is allowed on the source code after RC1 is tagged? >Are we restricted to critical bug fixes and nominal patches, or we >still have a good degree of freedom? >Actually this is a question I have been asking myself for a >while.... Good question. What does RC status mean? >As Darrell said, I am working on bug 1825, which although not a >blocker, messes up all documentation indexes, so IMO should be >resolved before releasing R14 (even though technically a fix could >be push even after RC1 is tagged). I'm working hard on updating the handbook system. The handbook system is an utter mess. No, an embarrasing mess, having been ignored since about KDE 3.2. I would like to see 1850 fixed for R14, although that has been broken since KDE3 days. There is a lot of handbook work to do for a long time. We have an etherpad of most handbook issues: http://trinity.etherpad.trinitydesktop.org/82 I have no illusions about fully mending the handbook system for R14. R14 won't crash or disintegrate without additional handbook attention, but I'd like to finish the foundation work and my list in that respect shrinks daily. We get only that one proverbial chance to release R14 as a polished release. Darrell

1 0

Re: [trinity-devel] R14 RC1 ready?
by Darrell Anderson 29 Jan '14

29 Jan '14

>I'm working hard on bug: 1597 [Regression] Pressing the power >button shutdown >computer, regardless of what I set in tdepowersave. I'm close to >completion. That's good to hear. Darrell

1 0

Re: [trinity-devel] R14 translation German
by Darrell Anderson 29 Jan '14

29 Jan '14

>Is there a guide how to fix missing translations in TDE 14 for >German? None that I am aware. For a long while I've wanted us to post a how- to on the wiki to address the topic. For now, probably a good starting point is the KBabel handbook (tdesdk). If you get started on this I'll help massage your notes into some kind of how-to. Darrell

2 1

SOLVED - kaffeine FTBFS - but How to code changes with preprocessor checks?
by David C. Rankin 29 Jan '14

29 Jan '14

c++ gurus, I need help, The problem: cdio-paranoia is removed from libcdio > 0.83. A new package 'libcdio-paranoia' provides all old cdio-paranoia headers, BUT the header file location has moved from: ../cdio to ../cdio/paranoia I successfully built kaffeine on Arch with libcdio & libcdio-paranoia by softlinking the needed paranoia headers to ../cdio: cdda.h -> paranoia/cdda.h paranoia.h -> paranoia/paranoia.h How do we patch kaffeine to properly handle this change? kaffeine/src/input/disc/paranoia.h already includes: #include <cdio/cdda.h> #include <cdio/paranoia.h> The only other files that need fixing are: configure.in:303:KDE_CHECK_HEADER([cdio/cdda.h], [with_cdparanoia=yes], [with_cdparanoia=no]) kaffeine/configure.in.in:223:KDE_CHECK_HEADER([cdio/cdda.h], [with_cdparanoia=yes], [with_cdparanoia=no]) But how to do this with preprocessor checks so that it will work with both libcdio <= 0.83 and those systems with libcdio > 0.83 that will also need libcdio-paranoia? -- David C. Rankin, J.D.,P.E.

1 2

automake WARNING - probably the primary issue - thoughts for now?
by David C. Rankin 29 Jan '14

29 Jan '14

One of the primary issues with the upcoming automake change has to do with the use of "AM_INIT_AUTOMAKE($PACKAGE,$VERSION)" seen in almost every TDE automake setup. The $PACKAGE,$VERSION (argc,argv) invocation of AM_INIT_AUTOMAKE is deprecated as of automake 1.14 and will outright fail with automake 2. Every package I build, I see: configure.in:53: the top level configure.in:43: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated. For more info, see: configure.in:43: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005f… Not only does TDE use the AM_INIT_AUTOMAKE two- and three-argument invocations. but the arguments are used throughout the automake recipes. When I run across issues where the AM_INIT_AUTOMAKE variables are used in the build process should we do anything to flag which package/how for future repair or is this issue the type that a global 'grep' or 'sed' will handle in the future? If you run into things during your builds or good outside information about moving existing automake scripts to automake 2.0, please add them to: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1840 I suspect the more good information we can capture prior to automake 2 arriving, the easier the fixes will be. -- David C. Rankin, J.D.,P.E.

1 0

Re: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
by Darrell Anderson 29 Jan '14

29 Jan '14

>Can someone confirm which package is supposed to provide libsmoke. >Currently I >have libtqt-perl providing: > >opt/trinity/bin/puic >opt/trinity/lib/libsmoketqt.so >opt/trinity/lib/libsmoketqt.la >opt/trinity/lib/libsmoketqt.so.1.2.1 >opt/trinity/lib/libsmoketqt.so.1 > > tdebindings (which finally built!) also provides: > >opt/trinity/lib/libsmoketqt.so >opt/trinity/lib/libsmoketqt.la >opt/trinity/lib/libsmoketde.so.1 >opt/trinity/lib/libsmoketde.so > > Which package should provide libsmoketqt? I always thought the answer is either. When tdebindings is built and installed with libsmoke support, then libtqt-perl is not supposed to build libsmoke. When tdebindings is not installed or built without libsmoke support, then libtqt-perl is supposed to build its own libsmoke. I always build tdebindings before libtqt-perl. But what do I know? Darrell

3 3

Re: [trinity-devel] tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
by Darrell Anderson 29 Jan '14

29 Jan '14

>I would venture to say that the "right place" for libtqt-perl >would include it as another part of tdebindings. I agree. Merge the unique parts into tdebindings and delete the libtqt-perl module. Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels