Message: previous - next
Month: January 2012

Re: [trinity-users] K Menu - kicker crash

From: Darrell Anderson <humanreadable@...>
Date: Sun, 15 Jan 2012 10:31:42 -0800 (PST)
> .. and my quote is correct, but I never stated that TDE was
> unstable. However, the _stable_ source isn't _stable_ in my
> view. Let me list some examples which are extant regardless
> of whether I'm using Wheezy or Squeeze;
> 1. avahi-tqt will not build;
> make  all-recursive
> make[1]: Entering directory `/data/build.0/avahi-tqt'
> Making all in avahi-tqt
> make[2]: Entering directory
> `/data/build.0/avahi-tqt/avahi-tqt'
>   GEN    qt-watch.moc3
> Qt meta object compiler
> moc: Too many input files specified
> Usage:  moc [options] <header-file>
>         -o file    Write
> output to file rather than stdout
>         -f[file]   Force
> #include, optional file name
>         -p path    Path
> prefix for included file
>         -i     
>    Do not generate an #include statement
>         -k     
>    Do not stop on errors
>         -nw       
> Do not display warnings
>         -v     
>    Display version of moc
> make[2]: *** [qt-watch.moc3] Error 1
> make[2]: Leaving directory
> `/data/build.0/avahi-tqt/avahi-tqt'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/data/build.0/avahi-tqt'
> make: *** [all] Error 2
> ... same every time.
> 2. kipi-plugins source requires patching before it will
> build.
> 3. aKode source not present but needed.
> 4. kdeadmin fails to build because it finds and uses the
> TDE installed dummy header, knetworkinterface.h, instead of
> it's own version. kpPty.cpp explicitly includes the system
> installed utils.h instead of it's own version.
> 5. kdevelop fails to build because the autogenerated
> listeditor.ui.h file includes a reference to App which
> should be tqApp.
> and there's more.
> Anyway, I'm not complaining just learning.

Mike, join the club with respect to learning. :) I joined this project before 3.5.12 was released. I have learned much! Part of the learning has been a challenge. At times frustrating. Yet I am learning leaps and bounds. I'm teaching myself C++ right now. Of late I am learning a thing or two about how cmake works. Although I have only superficial knowledge of C++, I have submitted more than a few patches. I think I am actually having fun, but am too old and stubborn to admit as much. ;)

I'll add some observations that help me. None of these thoughts are directed to you. I'm just rambling out loud.

* Software is a moving target. Frustratingly so. Testing known stable software in a known untested or unstable environment, means shouldering the responsibility to find solutions. Ask questions like crazy but let others know that they are not the crazy one. :)

* Always check the bugzilla before posting bug or build related questions.

* Always check the web before posting bug or build related questions.

* Ask, ask, ask.

* There are only a few people working to keep Trinity going. That can be frustrating at times so I always "count to 10" before posting anything to the lists. We all have lives, families, responsibilities. We all need a large dose of patience to keep this project running.

* If no solutions, then post a bug report or enhancement request. I do. Often. :)

* Everybody involved is a creature of limited knowledge. That is a hard lesson I learned about life in general. We can't assume everybody knows, even subject matter experts don't know everything. When things arise like akode not being in the repository, just ask. Chances are that adding the package is as simple as asking.

* Trinity is a continuation of the KDE3 desktop style. Packages that were not part of the original KDE3 package suite need to be added to the Trinity repository.

* Many of us use different distros. That means each of us tests according to our limited perceptions of how our distro works. (See --- we all are creatures of limited knowledge. :) ) That means some features don't get built or tested by others. Recently Tim has been adding a WITH_ALL_OPTIONS to the cmake converted packages. That is good because everybody involved should use that option at least a few times to test the overall build process, even when they don't want to use all features for their distro.

* Occasionally a build feature or two will slip through the proverbial cracks with an automake to cmake conversion. Just let everybody know. An example is the current discussion about FAM/GAMIN support missing in kdelibs. Remember that everybody is a creature of limited knowledge and these things will happen.

Oh, I almost forgot --- with respect to some of the build errors you just shared, the bugs about kipi-plugins and kdevelop have patches in the bugzilla. :) I had better get off my soap box now.