tde-devels

devels@trinitydesktop.org

2 participants
3811 discussions

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

Re: [trinity-devel] Icon conflicts in tdeaddons-tdeartwork-tdesdk (which one to choose?)
by Darrell Anderson 29 Jan '14

29 Jan '14

> We have run into another icon conflict error. I know some Who is we, kemosabi? >package managers do >not care and will let you overwrite icons, fonts, etc.., but >Arch's pacman >package manager will not let you overwrite anything in the >filesystem on the >theory that "No package should conflict with another". Of course >you can --force >any install and removal, but that defeats the purpose of proper >packaging. That is what happens in an anal world. > There are a couple of TDE icons that are present in several >different >packages. If one package is installed before any other containing >the same >icons, then install of the subsequent packages fails. At issue >are: > >tde-tdeaddons-14.0.0-1-i686.pkg.tar.xz > >opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png >opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png > >tde-tdeartwork-14.0.0-1-i686.pkg.tar.xz > >opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png >opt/trinity/share/icons/locolor/32x32/apps/kbabel.png >opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png >opt/trinity/share/icons/locolor/16x16/apps/kbabel.png > >tde-tdesdk-14.0.0-1-i686.pkg.tar.xz > >opt/trinity/share/icons/locolor/32x32/apps/kbabel.png >opt/trinity/share/icons/locolor/16x16/apps/kbabel.png > > So this has to be handled from a packaging standpoint on arch. >Fortunately, >the package that contains all icons at issue is tdeartwork. For >Arch, I will >write conditional checks for tdeaddons and tdesdk to avoid the >issue. > > How are the other distros handling this? Can TDE move these >conflicting icons >to tdeartwork exclusively. tdeaddons is from where the ktimemon applet is installed and is the rightful place for related base icons. tdesdk is from where kbabel is installed and is the rightful place for related base icons. Seems the tdeartwork versions should be deleted. That said, the tdeartwork versions for kbabel seem more global. The tdesdk icons are US-centric. As far as I can tell the ktimemon images are duplicates, both in appearance and in file size. Darrell

1 0

Icon conflicts in tdeaddons-tdeartwork-tdesdk (which one to choose?)
by David C. Rankin 29 Jan '14

29 Jan '14

Darrell, We have run into another icon conflict error. I know some package managers do not care and will let you overwrite icons, fonts, etc.., but Arch's pacman package manager will not let you overwrite anything in the filesystem on the theory that "No package should conflict with another". Of course you can --force any install and removal, but that defeats the purpose of proper packaging. There are a couple of TDE icons that are present in several different packages. If one package is installed before any other containing the same icons, then install of the subsequent packages fails. At issue are: tde-tdeaddons-14.0.0-1-i686.pkg.tar.xz opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png tde-tdeartwork-14.0.0-1-i686.pkg.tar.xz opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png tde-tdesdk-14.0.0-1-i686.pkg.tar.xz opt/trinity/share/icons/locolor/32x32/apps/kbabel.png opt/trinity/share/icons/locolor/16x16/apps/kbabel.png So this has to be handled from a packaging standpoint on arch. Fortunately, the package that contains all icons at issue is tdeartwork. For Arch, I will write conditional checks for tdeaddons and tdesdk to avoid the issue. How are the other distros handling this? Can TDE move these conflicting icons to tdeartwork exclusively. -- David C. Rankin, J.D.,P.E.

3 2

tde parallel build issue with tqt3? tdeartwork, amarok, k9copy all failing with strange error
by David C. Rankin 28 Jan '14

28 Jan '14

Tim, Darrell, All, Last night I started an i686 build run. During that run, several packages failed that had just built without issue on x86_64. At first it just looked like a cmake/library issue, but comparing the build failures, there is some common thread running between them that I cannot put my finger on. I need help to determine what the issue is. Most errors I can poke around at enough to figure out, but this one looks strange enough, I would like a second pair of eyes on it. Specifically, it looks to me like any time a link is called involving something openGL related, the build fails with a sting of "undefined reference to `TQGLWidget::" messages. Examples: tdeartwork: <snip> CMakeFiles/keuphoria.kss.dir/Euphoria.cpp.o: In function `EuphoriaWidget::staticMetaObject()': Euphoria.cpp:(.text+0x389): undefined reference to `TQGLWidget::staticMetaObject()' CMakeFiles/keuphoria.kss.dir/Euphoria.cpp.o: In function `EuphoriaWidget::~EuphoriaWidget()': Euphoria.cpp:(.text+0xd45): undefined reference to `TQGLWidget::~TQGLWidget()' CMakeFiles/keuphoria.kss.dir/Euphoria.cpp.o: In function `EuphoriaWidget::EuphoriaWidget(TQWidget*, char const*)': Euphoria.cpp:(.text+0x2b5e): undefined reference to `TQGLWidget::TQGLWidget(TQWidget*, char const*, TQGLWidget const*, unsigned int)' <snip> amarok: <snip> analyzers/libanalyzers.a(analyzerbase.cpp.o): In function `Analyzer::Base3D::tqt_emit(int, TQUObject*)': analyzerbase.cpp:(.text+0x1e7): undefined reference to `TQGLWidget::tqt_emit(int, TQUObject*)' analyzers/libanalyzers.a(analyzerbase.cpp.o): In function `Analyzer::Base3D::tqt_property(int, int, TQVariant*)': analyzerbase.cpp:(.text+0x21f): undefined reference to `TQGLWidget::tqt_property(int, int, TQVariant*)' analyzers/libanalyzers.a(analyzerbase.cpp.o): In function `Analyzer::Base3D::staticMetaObject()': analyzerbase.cpp:(.text+0x391): undefined reference to `TQGLWidget::staticMetaObject()' <snip> Not having any logical explanation for the failures and there being no explicit library missing, I went back and rebuilt everything again. from tqt3 to kdebase. Now recall, the build last night proceeded without error from tqt3 to kdebase, so I should simply be rebuilding the exact same code as was done in: makepkg --> SUCCEEDED for tqt3 at Jan 27 20:11:18 makepkg --> SUCCEEDED for tqtinterface at Jan 27 20:13:07 makepkg --> SUCCEEDED for arts at Jan 27 20:16:27 makepkg --> SUCCEEDED for dbus-tqt at Jan 27 20:16:34 makepkg --> SUCCEEDED for dbus-1-tqt at Jan 27 20:16:56 makepkg --> SUCCEEDED for tqca-tls at Jan 27 20:17:02 makepkg --> SUCCEEDED for libart-lgpl at Jan 27 20:17:21 makepkg --> SUCCEEDED for avahi-tqt at Jan 27 20:17:44 makepkg --> SUCCEEDED for libcaldav at Jan 27 20:18:07 makepkg --> SUCCEEDED for libcarddav at Jan 27 20:18:22 makepkg --> SUCCEEDED for sip4-tqt at Jan 27 20:19:09 makepkg --> SUCCEEDED for python-tqt at Jan 27 20:26:48 makepkg --> SUCCEEDED for tdelibs at Jan 27 20:51:11 makepkg --> SUCCEEDED for tdebase at Jan 27 21:16:07 <snip> makepkg --> FAILED for tdeartwork at Jan 27 22:05:12 After rebuilding the same packages again, (tqt3-tdebase) I can build tdeartwork without issue: makepkg --> SUCCEEDED for tdeartwork at Jan 28 15:16:25 Anybody else see this type of behavior? I rebuilt using parallel building again, so if it was to blame to begin with, it looks like this is some of the spurious type of errors that can occur. -- David C. Rankin, J.D.,P.E.

1 0

tdebinding (libsmoketqt) conflicts with libtqt-perl (libsmoketqt) - which is correct?
by David C. Rankin 28 Jan '14

28 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? -- David C. Rankin, J.D.,P.E.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels