tde-devels

devels@trinitydesktop.org

9 participants
3789 discussions

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

Arch - Building TDE i686 on x86_64 hardware
by David C. Rankin 28 Jan '14

28 Jan '14

All, A note to all who may try building TDE on arch. You can build/package both x86_64 and i686 packages on your x86_64 box -- simply. To build i686 packages on x86_64, create a 2nd archroot using a custom makepkg.conf and pacman.conf. To create the custom conf files, the only changes necessary are change '$auto' or auto, and x86_64 and x86-64 to 'i686' as follows: echo " Creating i686 pacman.conf" cp /etc/pacman.conf "$tmp" sed -i 's/Architecture = auto/Architecture = i686/' "$tmp/pacman.conf" echo " Creating new i686 archroot in '$CHROOT'" cp /etc/makepkg.conf "$tmp" sed -i 's/x86.64/i686/g' "$tmp/makepkg.conf" echo " Creating new i686 archroot in '$CHROOT'" sudo mkarchroot \ -C "$tmp/pacman.conf" \ -M "$tmp/makepkg.conf" \ $CHROOT/root base base-devel sudo gdb Build your first package by switching to the directory with the PKGBUILD for the first dependency and build/clean with: sudo makechrootpkg -c -r $CHROOT Then create a [local] repository to hold all packages with 0777 permissions and update your $CHROOT/root/etc/pacman.conf with the [local] repo definition sudo mkdir -p $CHROOT/root/repo || echo -e " WARNING: unable to create \$CHROOT/root/repo\n You must manually setup local repository.\n" echo " Setting permissions for '$CHROOT/root/repo'" [[ -d $CHROOT/root/repo ]] && sudo chmod 0777 $CHROOT/root/repo echo " Adding local repository to root/pacman.conf" echo -e "\n[local]\nSigLevel = Never\nServer = file:///repo\n" > /tmp/repotmp.txt sudo bash -c "cat /tmp/repotmp.txt >> $CHROOT/root/etc/pacman.conf" rm /tmp/repotmp.txt The copy the first package to $CHROOT/root/etc/pacman.conf and create the [local] repository index with: sudo repo-add $CHROOT/root/repo/local.db.tar.gz $CHROOT/root/repo/*.xz Then simply build all remaining dependencies and TDE in the order specified, install each complete package to the rw-layer of the chroot when built, and copy each completed package to $CHROOT/root/repo updating the local repository index as shown above after building/installing each package Build all remaining packages with: sudo makechrootpkg -r $CHROOT -- David C. Rankin, J.D.,P.E.

1 1

KControl joystick module screen captures needed
by Darrell Anderson 28 Jan '14

28 Jan '14

All, I have a joystick help handbook to push to git but no screen captures. I don't own a joystick! :) I need two screen captures: * tdecmshell joystick (3.5.13.2: kcmshell joystick) * The Calibrate dialog Preferred ksnapshot method: Capture mode: Window under cursor Thank you! Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels