tde-devels

devels@trinitydesktop.org

3821 discussions

Re: [trinity-devel] Can TDE now build in parallel jobs (i.e. -j2 or -j4)?
by Darrell Anderson 20 Jan '14

20 Jan '14

> A year or so ago, building with make -j >1 was advised against >due to the >potential to produce spurious build failures, etc. Has that >changed? The build >time savings is attractive, but if there hasn't been any testing, >best to stick >to -j1 for now? The only build scripts where I limit NUMJOBS=-j1: dependencies/avahi-tqt/avahi-tqt.SlackBuild libraries/pytdeextensions/pytdeextensions.SlackBuild tdebindings/tdebindings.SlackBuild For everything else: if [ "$NUMJOBS" = "" ]; then NUMJOBS="`grep -c '^processor' /proc/cpuinfo`" NUMJOBS=$(($NUMJOBS + 2)) export NUMJOBS="-j${NUMJOBS}" fi Darrell

3 2

Re: [trinity-devel] Note on autotools & obsolete macros
by Darrell Anderson 20 Jan '14

20 Jan '14

> In your autotools builds for applications, etc., pay close >attention to the >obsolete macro warning/errors and the option-subdirs warnings. >From >http://www.gnu.org/software/automake/manual/automake.html : > >Although using some of the following macros was required in past >releases, you >should not use any of them in new code. All these macros will be >removed in the >next major Automake version; if you are still using them, running >autoupdate >should adjust your configure.ac automatically (see Using >autoupdate to Modernize >configure.ac in The Autoconf Manual). Do it NOW! > >I have had several pieces of code hal/dcraw, etc. where I have had >to tweak >these issues with autotools 1.14. So when 2.0 is released. There >may be >significant work to do. Please file a bug report. This kind of information ALWAYS gets lost in this list. Darrell

2 1

tdebase FTBFS - No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a'
by David C. Rankin 20 Jan '14

20 Jan '14

All, I do not know what in the heck this error is: [ 95%] Built target ksysguardd-static Scanning dependencies of target ksysguardd [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/Command.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/conf.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/ksysguardd.c.o [ 95%] Building C object ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/PWUIDCache.c.o make[2]: *** No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a', needed by 'ksysguard/ksysguardd/ksysguardd'. Stop. CMakeFiles/Makefile2:24311: recipe for target 'ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/all' failed make[1]: *** [ksysguard/ksysguardd/CMakeFiles/ksysguardd.dir/all] Error 2 Makefile:116: recipe for target 'all' failed make: *** [all] Error 2 The base error is: *** No rule to make target '/opt/trinity/lib/libtdefakes_nonpic.a', needed by 'ksysguard/ksysguardd/ksysguardd'. Stop. Is this a CMake error or some other type of error? Where to start? -- David C. Rankin, J.D.,P.E.

3 15

Warning: Changing WITH_HAL and WITH_TDEHWLIB configuration defaults
by Darrell Anderson 20 Jan '14

20 Jan '14

Per bug report 1838, we are changing the defaults in tdebase CMakeLists.txt. Please remember to verify your tdebase build scripts. :) If building for mixed distro releases, consider something like the following in the build script: if [ -x /usr/sbin/hald ]; then BUILD_HAL=${BUILD_HAL:-ON} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-OFF} else BUILD_HAL=${BUILD_HAL:-OFF} BUILD_TDEHWLIB=${BUILD_TDEHWLIB:-ON} fi ... cmake $SOURCES_ROOT \ ... -DWITH_HAL=${BUILD_HAL} \ -DWITH_TDEHWLIB=${BUILD_TDEHWLIB} \ ... Darrell

2 1

Missing packages in nightly-builds, renaming one git submodule
by Slávek Banko 20 Jan '14

20 Jan '14

Tim, during my random monitoring FTBFS in nightly builds, I noticed a few missing packages. At the beginning - one unnecessary - knetworkmanager8. This being replaced by tdenetworkmanager, no longer being updated and may be removed from nightly-builds. The second package was renamed, but the git repository has not been renamed - compizconfig-backend-kconfig. I believe that we should rename the git repository. I suppose then the package will be again properly updated in nightly-builds. The following packages are ready for builds, but it seems not to have been included into the automation script: + casper-trinity + trinity-keyring + trinity-livecd + ubiquity-trinity Slavek

2 6

Note on autotools & obsolete macros
by David C. Rankin 20 Jan '14

20 Jan '14

All, In your autotools builds for applications, etc., pay close attention to the obsolete macro warning/errors and the option-subdirs warnings. From http://www.gnu.org/software/automake/manual/automake.html : Although using some of the following macros was required in past releases, you should not use any of them in new code. All these macros will be removed in the next major Automake version; if you are still using them, running autoupdate should adjust your configure.ac automatically (see Using autoupdate to Modernize configure.ac in The Autoconf Manual). Do it NOW! I have had several pieces of code hal/dcraw, etc. where I have had to tweak these issues with autotools 1.14. So when 2.0 is released. There may be significant work to do. -- David C. Rankin, J.D.,P.E.

1 0

Can TDE now build in parallel jobs (i.e. -j2 or -j4)?
by David C. Rankin 20 Jan '14

20 Jan '14

All, A year or so ago, building with make -j >1 was advised against due to the potential to produce spurious build failures, etc. Has that changed? The build time savings is attractive, but if there hasn't been any testing, best to stick to -j1 for now? -- David C. Rankin, J.D.,P.E.

1 0

Re: [trinity-devel] tdebase FTBFS /usr/bin/ld: cannot find -ldbus-tqt-1
by Darrell Anderson 20 Jan '14

20 Jan '14

>This sounds like a problem that has been experienced before and >was fixed by >patching the end of a cmake file, but I do not recall the >specifics. Any one >recall where/what cmake file is responsible for including libdbus- >tqt-1? I'm no compiler expert, not even close, sunny or rainy day. Unless Arch is REALLY different from other distros, I would pause to consider what else might be causing the errors. That is, the rest of the team is building full package sets without the same errors. That said, yes, you could have stumbled across a corner case that Arch exposes. We've seen that before around here. :) Darrell

3 11

tdebase FTBFS - In 'void Lockout::slotButtonOrder()' error: 'KConfig' not in scope
by David C. Rankin 19 Jan '14

19 Jan '14

All, After getting through the CMake issues with tdebase and cmake 2.8.12.1, I have run into another scope error. The error is with gcc 4.8.2: [ 57%] Building CXX object kicker/applets/lockout/CMakeFiles/lockout_panelapplet-module.dir/lockout.cpp.o /build/tde-tdebase/src/tdebase/kicker/applets/lockout/lockout.cpp: In member function 'void Lockout::slotButtonOrder()': /build/tde-tdebase/src/tdebase/kicker/applets/lockout/lockout.cpp:297:4: error: 'KConfig' was not declared in this scope KConfig* conf = config(); ^ /build/tde-tdebase/src/tdebase/kicker/applets/lockout/lockout.cpp:297:13: error: 'conf' was not declared in this scope KConfig* conf = config(); ^ kicker/applets/lockout/CMakeFiles/lockout_panelapplet-module.dir/build.make:63: recipe for target 'kicker/applets/lockout/CMakeFiles/lockout_panelapplet-module.dir/lockout.cpp.o' failed I recall a number of these from prior builds. However, this time I decided to build without -DCMAKE_CXX_FLAGS="-fpermissive". There appear to be several more of these scope issues in the code. I can't recall how we were fixing these, but I recall most being simple. I'll look back through the list and bugzilla. If you know off-hand how to correct this -- let me know. Also, do we want to open bug reports on the scope failures if we cannot correct them with a patch here on the list? (do we want to file ALL of these so they are being actively tracked? -- David C. Rankin, J.D.,P.E.

1 1

Re: [trinity-devel] tdebase FTBFS /usr/bin/ld: cannot find -ldbus-tqt-1
by Darrell Anderson 19 Jan '14

19 Jan '14

>It failed again: > >Any thoughts? My memory is slow most days and other days is not fast. I now remember a similar bug hitting me a while back when trying to build 3.5.13.2: http://bugs.trinitydesktop.org/show_bug.cgi?id=1727 The problem turned out to be the way I had my build scripts configured. I hadn't paid attention for months and discovered I was installing dbus-1-tqt to /usr. Yet the remainder of my build scripts were built to install to /opt/trinity. Therefore the other build scripts were looking for the dbus-1-tqt files in /opt/trinity (${PREFIX}). After I commented out those hard-coded lines I no longer had any problems. You can still see them commented out in the coppies you got from me. Now that specific failure was with 3.5.13.2, not R14. Yet who knows, could be something similar. Check into where your dbus-1-tqt files are actually being installed. BTW, make sure you are not concurrently using WITH_HAL and WITH_TDEHWLIB. One or the other. Darrell

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels