>I know I get caught with the real-world taking a day or two of
>time away from
>getting RC1 ready to freeze, but we really should be allowing at
>least that long
>for testing before pushing at this point.
>
>Like the .la -> .so push, great move forward, but we should get a
>sign-off from
>each of the active builders before pushing, or at least send a "I
>am about to
>push X that might break Y, please test.."
I won't be surprised if others have the 'undefined symbol' errors
too because the packages all build for me. None fail to build. If
build without failure is the only barometer then nobody pays
attention to the build logs. Yet my build logs are filled with the
errors.
My master build script options looks for a whole slew of build
related errors and warnings and that is how I see these things all
the time. Building without failure is only half the battle.
Darrell
>heh,heh,heh, sip4-tqt FTBFS, python-tqt FTBFS, tdeutils FTBFS,
>etc... I feel your pain... and share the bags under your eyes :-)
The point being that FTBFS patches are being pushed lately without
everybody having an opportunity to test. "Works for me" is not a
good motto. I understand that somebody needs a patch to avoid
FTBFS. I get that. We all do. Yet FTBFS patches should be tested by
everybody involved.
Darrell
I don't know what happened in the past week, but all of my build
logs are filled with this kind of spew:
/dev/shm/tqt3/plugins/designer/libcppeditor.so: undefined symbol:
_ZN6Editor11eventFilterEP8TQObjectP7TQEvent
Including tqt3.
My build set from a week ago does not have this and I never have
seen this before in every single module.
What happened?
Darrell
> Can you confirm the size of the python-trinity package you are
>building. I
>built python-trinity last night for the first time and I was
>bewildered by the
>fact it took 20 minutes to build and resulted in a package that
>was over 20M.
According to my build log, python-trinity takes almost 10 minutes
to build on my dual core and is about 4.8 MB (txz).
Darrell
>Could Darrell's issue be that he still has some components of TDE
built
>that are looking for the static libs when now only the shared libs
exist?
No. This is a clean build from scratch in a clean chrooted build
environment. The errors appear in tqt3.
I always build Trinity in a clean chrooted build environment.
>I bet that is it...
Well, pay up because that is not the cause.
Yes, I'm irritated. Please reverse the patches and post to a bug
report where they can be tested.
Darrell
>On Debian and Ubuntu are no apparent problems during build. Commit
>2ee14b64 caused FTBFS in tqt3 and this was resolved in commit
>dab0c5cd. No other problems have not noticed.
Perhaps we should change the name of the project to the Debian
Desktop Environment.
Darrell
> That's it. Then it builds on bleeding-edge arch without issue.
>Darrell, will
>you try this patch and confirm that it works fine with python2.
>Then let's get a
>few more eyes on it and if no objections, push it.
>
>The patch is included below.
I don't have tme to test this. The bug report will have to do.
Darrell
> I think these are a couple of stray doc packages, I think the
>help files are
>in the correct spots, but these stray docs ended up in random
>locations:
>
>22:47 valhalla:~> l1 /opt/trinity/share/doc/
> kbfx
> ksquirrel-libs
> tde
>22:48 valhalla:~> l1 /opt/trinity/share/doc/tde/
> HTML
>22:48 valhalla:~> l1 /opt/trinity/share/doc/tde/HTML/
> <snip>
> kdiff3
>
> The ksquirrel-libs docs may be the whole doc package, but the
>others have doc
>generation scripts and AUTHOR/HACKING type file. What do you
>suggest? Delete
>them during packaging?
Some developers have egos that simply can't be stroked. Their
package is THE package.
Do what you want with the files.
Darrell
>Can I pose a question?
>
> Why are we looking to add Q_EXPORT calls, and we are we making
>commits
>containing them until they are tested?
Please reverse commits dab0c5cd and 2ee14b64 until they are fully
tested and debugged.
Darrell