-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

Hi Ilya, see comments below mixed with your email. You are building R14.1.0-DEV right?

Last week I tried out TDE building scripts: for example 99_build_TDE.sh which successfully finished its work in 38 hours. But later that week I looked into 0_logs/build_result.log and found there some "[FAILED]" messages for ten packages ("k3b-i18n", "k9copy", "kaffeine", "kasablanca", "katapult", "kbarcode", "kbfx", "kbibtex", "kbiff", "kpilot").

Under TDE_SRC/2_build/debs/<module>/src you will find a detailed build log of the module, so you can see what went wrong for that specific module

Later I tried to run the same script in "local

mode" ("-l" flag in BUILD_DEFAULT_OPTIONS variable of _config.sh) but it seems the modules don't see the compilation results of the previously compiled modules. And I didn't find any way in the scripts for them to see. So here are some questions about building scripts

- -l is used to build a module locally on your live system. It is mostly useful if you are testing changes and want to do quick local builds. It is not recommended to use it to build a clean TDE since it depends on locally install modules and build may fails if you don't update step by step

0. Do I understand correctly that "modules" (as this word is used in command "build_module" for example in

06_applications_03.sh script) are corresponding 1-to-1 to debian source packages on the one hand and to git submodules of TDE/tde repository on the other hand?

Yes, that is correct.

1. What exactly is the mechanism used while building with "pbuilder" (i.e. WITHOUT "-l") for the module A to use

package B built in one of the previous modules?

This is done by pbuilder as long as everything has been setup correctly. A pbuilder hook script is used to scan the "debs" folder before building each module, specifically the D05deps script.

2. Does something similar exist while building everything in "local mode" (i.e. WITH "-l") on a clean machine? I

see there only the *.deb files, but they don't seem to be installed immediately after creation and then the next step is about to start already and *.deb files are just left there not installed.

As said above this is not recommended and in some unlucky case you may not even be able to build TDE from within TDE. If you want to use -l you need to install the various .deb by yourself in your system before proceeding with the next package. "-l" does not create clean chrooted modules, so think of it as a development tool/commodity.

3. Is there any simple way to disable colored output which is very nice on the terminal, but quite disturbing while

reading logs in a

I may be saying something wrong here going by memory, but I think I have already addressed this issue in my scripts. Am I wrong?

4. Is there a way to stop let's say 99_build_TDE.sh script if a single module compilation failed?

the various build set have been thought as a way to automate building of multiple modules, so they normally continue in case of a build failure. You will need to edit the scripts and look at the result returned by build_module and stop in case of a fault. Perhaps an idea to consider for future improvements :-)

5. Sometimes I see the following lines in the log file (using "show log" -sl option and piping output into a

file): dpkg-checkbuilddeps: error: Unmet build dependencies: tdelibs14-trinity-dev [and many more -I.D.] dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting dpkg-buildpackage: warning: (Use -d flag to override.) Building completed SUCCESSFULLY [in green color -I.D.]

Does this combination (package can't be built, but it's kinda success nevertheless) have any sense or is it some kind of error in the scripts?

It is probably a corner case of the scripts when missing dependencies are detected. I have seen something like this from time to time as well, not often enough to bother me to the point to work on it yet :-D

The meaning of all these questions for me is to understand how to create an environment, where I can rebuild the whole TDE in a reliable way (run a single command and be sure that its success indicates nothing went wrong and everything is built) on a clean machine.

Don't use "-l" in this case. you can use the build TDE script and grep the build_result.log file for "FAILED". That will tell you if any package has failed the build process.

If you need further info, please let me know. Btw, I have not yet come around the meta package building. I am under very heavy work load and for a while have very limited time for TDE unfortunately :-(

Cheers Michele

On 12/11/2019 01:24 AM, Ilya Dogolazky wrote:

Hello!

Last week I tried out TDE building scripts: for example 99_build_TDE.sh which successfully finished its work in 38 hours.

Ouch!!

Thank cannot be right. I used to build TDE (including koffice) in less than 7 hr. on a P4 2.8 GHz box. Now with a normal i7 on SSD you are looking at an hour. If you are running 38 hours on the build something is very, very wrong.