Dear TDE devs,
I would like to try my luck (and skills!) with fixing some of the bugs I've been experiencing with TDE. I need help with making my first steps though. I already have the TDE sources cloned from git repositories. Now I need help with the build process. Ideally, I would like to be able to build a Debian package on a VM dedicated to development, and then install and test that package on my primary desktop machine.
I found build instructions on the wiki, but I don't know to what extent these are up-to-date:
https://wiki.trinitydesktop.org/How_to_Build_TDE_Core_Modules
I am confused about the Suggested Build Order section. Do I need to find each of the mentioned components and build it in the listed order? How do I build each of the components? Should I follow with the incantation in "Performing a cmake Build with Ninja" section for each of the components? How to rebuild if dependencies change? If I modify, say, dbus-tqt, do I need to manually rebuild everything that's listed below it in the dependency list? Lastly, once a certain component or application is built, how do I package it?
I have no doubt, that the build instructions on the Wiki make a lot of sense for someone who already knows how to build TDE, but for a beginner they feel slightly incomplete. If anyone has the patience to guide me with my baby steps I will greatly apprciate it.
Best regards, Janek
On Thursday 23 of October 2025 09:25:44 Jan Stolarek via tde-devels wrote:
Dear TDE devs,
I would like to try my luck (and skills!) with fixing some of the bugs I've been experiencing with TDE. I need help with making my first steps though. I already have the TDE sources cloned from git repositories. Now I need help with the build process. Ideally, I would like to be able to build a Debian package on a VM dedicated to development, and then install and test that package on my primary desktop machine.
I found build instructions on the wiki, but I don't know to what extent these are up-to-date:
https://wiki.trinitydesktop.org/How_to_Build_TDE_Core_Modules
I am confused about the Suggested Build Order section. Do I need to find each of the mentioned components and build it in the listed order? How do I build each of the components? Should I follow with the incantation in "Performing a cmake Build with Ninja" section for each of the components? How to rebuild if dependencies change? If I modify, say, dbus-tqt, do I need to manually rebuild everything that's listed below it in the dependency list? Lastly, once a certain component or application is built, how do I package it?
I have no doubt, that the build instructions on the Wiki make a lot of sense for someone who already knows how to build TDE, but for a beginner they feel slightly incomplete. If anyone has the patience to guide me with my baby steps I will greatly apprciate it.
Best regards, Janek ____________________________________________________
Hi Janek
a simple way to rebuild a package with some added patch can be as follows - for example for tdebase:
1. Set up apt sources for both binary and source Trinity packages. 2. apt source tdebase-trinity && apt build-dep -y tdebase-trinity && cd tdebase*/ 3. Add required patches to debian/patches and list them in debian/patches/series. 4. Use quilt push -a to verify that all patches can be applied smoothly. 5. Edit debian/changelog to distinguish the package version from the original. 6. dpkg-buildpackage -j<cpu_count> -b 2>&1 | tee ../build.log
If the build goes correctly, you will find the binary packages and can install them. If not, you can find in the build.log why it failed.
Cheers Slávek --
Hi Slávek,
a simple way to rebuild a package with some added patch can be as follows - for example for tdebase: (...)
Thanks! I have never used source packages before - I see if I can set up that workflow. One question though:
- Add required patches to debian/patches and list them in
debian/patches/series.
When you say "patches" does that mean patches generated using `git format-patch`? I understand this workflow would allow me to begin hacking right away, but I also want to be in position where I can easily submit my changes upstream.
Janek
On Friday 24 of October 2025 16:10:56 Jan Stolarek via tde-devels wrote:
Hi Slávek,
a simple way to rebuild a package with some added patch can be as follows - for example for tdebase: (...)
Thanks! I have never used source packages before - I see if I can set up that workflow. One
question though:
- Add required patches to debian/patches and list them in
debian/patches/series.
When you say "patches" does that mean patches generated using `git format-patch`? I understand this workflow would allow me to begin hacking right away, but I also want to be in position where I can easily submit my changes upstream.
You can use different ways to get patches. Besides the mentioned git format-patch can use git show _commit_ or git diff _commit_.._commit. Or if you will have a new modification, it could be a diff between git and your modification.
Janek ____________________________________________________
Cheers Slávek --
On 2025/10/23 04:25 PM, Jan Stolarek via tde-devels wrote:
Dear TDE devs,
I would like to try my luck (and skills!) with fixing some of the bugs I've been experiencing with TDE. I need help with making my first steps though.
Hi Janek, since you use Debian, you can use my scripts to build TDE, they should make life pretty easy when you have setup everything. Currently the scripts are prepared with the idea that you build everything locally. This is ok for a core dev who works on all the TDE code, but if you want to build individual packages it is a bit overkill because it forces you to build all the required dependencies before you can build a module, if you want builds in clean environment. If you want a local build, the scripts are fine, but occasionally local builds may fail due to changes that you are testing.
There is one thing I have been wanting to add to those scripts for a while, that is the ability to build a single module in a clean environment while using the dependency from the PSB/PTB repos. This would be ideal for people who wants to work on an individual package in a clean environment. I will try to have that ready this weekend and let you know when they are ready. I will also push some recent updates that I have made locally.
Cheers Michele
Hi Michele,
since you use Debian, you can use my scripts to build TDE, they should make life pretty easy when you have setup everything.
Where do I find these scripts?
Currently the scripts are prepared with the idea that you build everything locally. This is ok for a core dev who works on all the TDE code, but if you want to build individual packages it is a bit overkill because it forces you to build all the required dependencies before you can build a module
I have quite a powerful PC, so I am OK with compiling everything, provided further rebuilds only recompile the necessary bits and are thus faster.
There is one thing I have been wanting to add to those scripts for a while, that is the ability to build a single module in a clean environment while using the dependency from the PSB/PTB repos. This would be ideal for people who wants to work on an individual package in a clean environment. I will try to have that ready this weekend and let you know when they are ready. I will also push some recent updates that I have made locally.
I think I didn't fully understand what you refer to as "clean environment"? And also "local builds" - what builds would not be local?
Janek
On Friday 24 of October 2025 16:15:53 Jan Stolarek via tde-devels wrote:
Hi Michele,
since you use Debian, you can use my scripts to build TDE, they should make life pretty easy when you have setup everything.
Where do I find these scripts?
tde-packaging/debian/_buildscripts/local
Currently the scripts are prepared with the idea that you build everything locally. This is ok for a core dev who works on all the TDE code, but if you want to build individual packages it is a bit overkill because it forces you to build all the required dependencies before you can build a module
I have quite a powerful PC, so I am OK with compiling everything, provided further rebuilds only recompile the necessary bits and are thus faster.
There is one thing I have been wanting to add to those scripts for a while, that is the ability to build a single module in a clean environment while using the dependency from the PSB/PTB repos. This would be ideal for people who wants to work on an individual package in a clean environment. I will try to have that ready this weekend and let you know when they are ready. I will also push some recent updates that I have made locally.
I think I didn't fully understand what you refer to as "clean environment"? And also "local builds" - what builds would not be local?
Janek ____________________________________________________
We normally use tools sbuild or pbuilder for building. These work by creating a clean chroot with the base system => "clean environment", into which the source package is then unpacked, build-deps installed and the build performed. After that, the chroot is removed again. This is an automated build.
A local build is intended when this automated process is not used.
Cheers Slávek --
Hi Janek,
Where do I find these scripts?
tde-packaging/debian/_buildscripts/local
Here: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/src/branch/mas... The readme.txt files contains all the instructions for setup and usage. Unless you intend to become a TDE core dev and work on both master and r14.1.x all the time, I recommend you don't use "worktrees". I have updated my scripts yesterday to support the latest distros and TDE code structure. If you run into any issue with the scripts, drop me a message. The script also provide a mechanism to add local patches before the build, see the "hook" mechanism in the instructions.
I think I didn't fully understand what you refer to as "clean environment"? And also "local builds" - what builds would not be local?
There are two main ways of working: 1. locally in your computer Here you build packages in your environment, so you don't have to wait for dependencies to be downloaded and the build is quicker. This is ideal for prototyping, testing, debugging and so on. Depending on what you are working on, occasionally you may end up with weird results, but 99.5% of the time you will be fine. Recommended workflow (refer to readme.txt file): - ./build_module.sh -g -po <module name> --> prepare the code in a build folder - switch to the created build folder for the module - debian/rules clean, followed by debian/rules binary --> builds all the debian binary packages, locally - for specific subpart of big modules (like tdelibs, tdebase, ...) you can "cd obj..." and then use specific ninja targets for partial builds.
2. build in clean environment This is how official debian packages are built. Each module is build in a minimal build environment and only the specified dependencies are imported. This helps identifying missing dependencies and prevents contamination from other locally installed packages. Local builds are open to such errors, so a locally built package may build and work fine on the system where it was built, but could fail when distributed to other people. That is why a clean environment build is so important for any distro.
I have quite a powerful PC, so I am OK with compiling everything, provided further rebuilds only recompile the necessary bits and are thus faster.
If you build locally, you can just build a single module, provided the required dependencies are installed. If you build in a clean environment, you need to build all modules once (at least the "base" modules) and then keep the build updated as changes are merged into the code. I used to do it all the time, but I later moved to PTB and often build locally or on a partially outdated clean build. I do a full rebuild once a month to update the build environment for clean packages.
There is one thing I have been wanting to add to those scripts for a while, that is the ability to build a single module in a clean environment while using the dependency from the PSB/PTB repos.
This is not yet in the scripts.
Hi Michele,
thanks for the details! It will take me a moment to fully digest all of this, but I think I should have enough information to get started. Keep in mind, it might be a slow start :-)
Best regards, Janek
As promised, I am back with questions :-) I am running a full build with 99_build_tde.sh script and, as expected, some of the modules failed to build. For example:
#### Processing module "libraries/pytde" ####
Building from GIT repo Building using pbuilder Building completed WITH ERRORS
#### Processing module "libraries/pytde" failed (1) ####
These failures are caused by missing dependencies, which should mostly be easy to fix. Now, the questions:
1. Once I install the missing dependencies, what is the right way of rebuilding the failed modules? Should I run build_module.sh for each of the failed modules? Or should I do 99_build_tde.sh and it will only rebuild the failed modules?
2. I am missing packages such as libtqt3-mt-dev or tqt3-dev-tools. These should be installed from TDE repo, correct? I am running this in a VM that has no graphical environment at the moment, and thus no TDE.
Best regards, Janek
Also, a handful of modules report something that looks like errors:
#### Processing module "applications/multimedia/k3b" ####
Building from GIT repo
No series file found fatal: not a git repository: /home/killy/tde/2_build/build/applications/multimedia/k3b/../../../../.git/modules/main/applications/multimedia/k3b fatal: not a git repository: /home/killy/tde/2_build/build/applications/multimedia/k3b/../../../../.git/modules/main/applications/multimedia/k3b fatal: not a git repository: /home/killy/tde/2_build/build/applications/multimedia/k3b/../../../../.git/modules/main/applications/multimedia/k3b dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/applications/multimedia/k3b/debian/changelog(l5): badly formatted trailer line LINE: -- <> dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/applications/multimedia/k3b/debian/changelog(l7): found start of entry where expected more change data or trailer LINE: k3b-trinity (1.0.5-4ubuntu2) karmic; urgency=low dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/applications/multimedia/k3b/debian/changelog(l7): found end of file where expected more change data or trailer
Building using pbuilder Building completed SUCCESSFULLY
#### Processing module "applications/multimedia/k3b" succeeded ####
And yet they seem to build successfully? Is this expected?
Janek
Jan Stolarek via tde-devels wrote:
Also, a handful of modules report something that looks like errors:
#### Processing module "applications/multimedia/k3b" ####
Building from GIT repo
No series file found fatal: not a git repository: /home/killy/tde/2_build/build/applications/multimedia/k3b/../../../../.git/modules/main/applications/multimedia/k3b fatal: not a git repository:
For various reasons I use my own build script, so I do not know if I am supposed to comment at all, but in this case it is looking for .git in the wrong directory.
dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/applications/multimedia/k3b/debian/changelog(l5): badly formatted trailer line LINE: -- <>
this here is obviously having problem with parsing content in changelog. How does changelog look like? But it is a warning, so no surprise that it builds. Based on the last entry (on top) in changelog, the package name is set.
found end of file where expected more change data or trailer
Building using pbuilder Building completed SUCCESSFULLY
#### Processing module "applications/multimedia/k3b" succeeded ####
And yet they seem to build successfully? Is this expected?
Janek
In my opinion you should be building in 2_build and not in 2_build/build and may be this is the root cause for all listed here. But again, I do not know the build scripts.
BR
#### Processing module "applications/multimedia/k3b" ####
Building from GIT repo
No series file found fatal: not a git repository: /home/killy/tde/2_build/build/applications/multimedia/k3b/../../../../.git/modules/main/applications/multimedia/k3b fatal: not a git repository:
For various reasons I use my own build script, so I do not know if I am supposed to comment at all, but in this case it is looking for .git in the wrong directory.
Indeed, wrong user process. You are building from the build folder, not the git folder. When things are setup from git to build folder by build_module.sh, the debian patches are applied once, then the series file is removed to avoid reapplication faults. If you try to make your build folder the git folder, you will get something like the above.
I suggest you re-read the readme file a second time and confirm your setup is correct. It may be a good idea to redo it from scratch, now that you have got a first exposure to the process.
Cheers Michele
I tested my hypothesis regarding the missing repositories. I added the main TDE repo to APT sources, but the build script still does not install the dependencies automatically and errors out. Installing dependencies manually allows to proceed with the build, but the end result is ambiguous:
-------------
dpkg-source: info: using options from pytqt/debian/source/options: --compression=xz --compression-level=9 --diff-ignore=.* debian/rules clean dh_testdir dh_testroot rm -rf build-3.13 dbg-build-3.13 rm -f *-stamp dh_clean debian/rules binary dh_testdir mkdir -p build-3.13 cd build-3.13 && echo yes \ | python3.13 ../configure.py \ -c -n /usr/include/tqt3 \ -o /usr/lib/x86_64-linux-gnu -u -j 40 \ -d /usr/lib/python3.13/dist-packages/PyTQt \ -l /usr/include/python3.13 \ -v /usr/share/sip-tqt/tqt \ -m /usr/lib/python3.13/config \ -z \ CXXFLAGS_RELEASE="" CXXFLAGS="-O1 "-I/usr/include/tqt" "-I/usr/include/tqt3"" STRIP="" Error: tqglobal.h could not be found in /usr/share/tqt3/include. make: *** [debian/rules:55: build-3.13/configure-stamp] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
Building completed SUCCESSFULLY
#### Processing module "dependencies/pytqt" succeeded ####
-------------
As you can see, build script reports both an error and a success. Searching the file system for missing tqglobal.h file yields:
/home/killy/shared/tde/main/dependencies/tqt/src/tools/tqglobal.h /home/killy/shared/tde/main/dependencies/tqt/include/tqglobal.h /home/killy/tde/1_git/tde/main/dependencies/tqt/src/tools/tqglobal.h /home/killy/tde/1_git/tde/main/dependencies/tqt/include/tqglobal.h /home/killy/tde/2_build/build/dependencies/tqt/src/tools/tqglobal.h /home/killy/tde/2_build/build/dependencies/tqt/include/tqglobal.h /usr/include/tqt/tqglobal.h
The said file resides in /usr/share/tqt/include, not /usr/share/tqt3/include (note the "3").
What now?
Janek
On 2025/11/02 05:09 AM, Jan Stolarek wrote:
I tested my hypothesis regarding the missing repositories. I added the main TDE repo to APT sources, but the build script still does not install the dependencies automatically and errors out.
Uhm no, that doesn't sound right at all. There should be no need to add TDE repos to APT sources, because we are building TDE from scratch and the existing deb files would be added by the build script during the process. I still think you got something wrong in your config.
The said file resides in /usr/share/tqt/include, not /usr/share/tqt3/include (note the "3").
Ah! Question: are you building 'master' or 'r14.1.x' branch? if you are building 'r14.1.x', you will also need to build the 'tqtinterface' module right after building 'tqt'. In 'master' such module has been merged into 'tqt' and is no longer present.
If needed, I can setup a minimal Trixie VM and retry the process from scratch, to verify if the instructions in the README file are somehow outdated and need some refreshment.
That being said, what is the best way to quickly rebuild a module? I want to be ble to
make quick rebuilds to make sure that everything compiles during development
If you are building inside a VM without TDE installed, you need to do builds in a clean environment (basically build_module.sh without '-l' option. If you have TDE installed, then the quicker way is to do local builds: - build_module.sh -g -po <module> - switch to the module build folder - debian/rules binary
Cheers Michele
Question: are you building 'master' or 'r14.1.x' branch?
I was building the master branch. That was incorrect, wasn't it? I changed my _config.sh to contain:
UPDATE_BRANCHES="r14.1.x" DEFAULT_REPO_BRANCH="r14.1.x"
I then nuked the whole build tree and started from scratch, modifying also 01_base_01.sh script to include tqtinterface module. Things look slightly better now, in that components no longer fail due to missing dependencies. However, I still got some build failures. I might have managed to fix them, but I need to build more components to make sure.
00_pre_base.sh completes without issues.
In 01_base_01.sh the first component to cause trouble is tqt:
#### Processing module "dependencies/tqt" ####
Building from GIT repo
No series file found fatal: not a git repository: /home/killy/tde/2_build/build/dependencies/tqt/../../../.git/modules/main/dependencies/tqt fatal: not a git repository: /home/killy/tde/2_build/build/dependencies/tqt/../../../.git/modules/main/dependencies/tqt fatal: not a git repository: /home/killy/tde/2_build/build/dependencies/tqt/../../../.git/modules/main/dependencies/tqt dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/dependencies/tqt/debian/changelog(l5): badly formatted trailer line LINE: -- <> dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/dependencies/tqt/debian/changelog(l7): found start of entry where expected more change data or trailer LINE: tqt (3:3.3.8-d-0ubuntu0) maverick; urgency=low dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/dependencies/tqt/debian/changelog(l7): found end of file where expected more change data or trailer
Building using pbuilder
After some debugging and hacking, I speculate that the line 391 in build_module.sh, which currently reads:
quilt push -a
should be replaced with the following two lines:
QUILT_PATCHES="debian/patches" quilt push -a cd -
This allows quilt to apply patches, and then returns to the directory which holds the git repository, permitting to correctly udpate the changelog (c.f. line 421). What I don't understand is why there are three "fatal: not a git repository" messages - shouldn't changelog update generate only one from the call to `git log`?
Anyway, with this one change to build_module.sh script, 01_base_01.sh completes successfully. I will be running subsequent build scripts tomorrow.
Janek
Hi Janek,
I was building the master branch. That was incorrect, wasn't it?
It is fine if you want the PTB equivalent packages. If you want to PSB equivalent, then you need to use r14.1.x. I build from master all the time, fyi.
In 01_base_01.sh the first component to cause trouble is tqt:
#### Processing module "dependencies/tqt" ####
Building from GIT repo
No series file found fatal: not a git repository: /home/killy/tde/2_build/build/dependencies/tqt/../../../.git/modules/main/dependencies/tqt
Something still seems wrong. The "2_build" folder is the build folder. If you are "Building from GIT repo", your sources should come from a different subfolder and would be copied to the "2_build" folder automatically, together with the required tde-packaging files.
After some debugging and hacking, I speculate that the line 391 in build_module.sh, which currently reads:
quilt push -a
should be replaced with the following two lines:
QUILT_PATCHES="debian/patches" quilt push -a cd -
Line 391 is already execute from the build folder, so in theory the additional "QUILT_PATCHES" variable should ont be needed.
Can you send me your config and a screenshot of your folder structure? I can take a look. This weekend I can also try to build a new trixie VM with minimal config and retest the process from scratch, to see if there is any step which is not up to date.
Cheers Michele
Something still seems wrong. The "2_build" folder is the build folder. If you are "Building from GIT repo", your sources should come from a different subfolder and would be copied to the "2_build" folder automatically, together with the required tde-packaging files.
Yes, if I understand correctly this is what's happening. In particular, I have completely removed the contents of 2_build several times now in order to restart the build from scratch during debugging.
Line 391 is already execute from the build folder, so in theory the additional "QUILT_PATCHES" variable should ont be needed.
Without the additional variable, I am getting "No series file found" message from quilt. With the extra variable in place, quilt applies the patches. For example:
Applying patch debian/patches/01-klaptopdaemon-setuphandler.diff patching file klaptopdaemon/acpi.cpp Hunk #1 succeeded at 189 (offset 11 lines). patching file klaptopdaemon/apm.cpp Hunk #2 succeeded at 211 (offset 11 lines).
Now at patch debian/patches/01-klaptopdaemon-setuphandler.diff
Also, note the extra `cd -` to return to the previous directory - this prevents subsequent git errors
Can you send me your config and a screenshot of your folder structure?
See attached files. Let me know if there's anything else you need.
----
Building some of the modules from 02_base_02.sh script fails. On the terminal I get:
#### Processing module "libraries/pytdeextensions" ####
Building from GIT repo
Applying patch debian/patches/11_fix_get_libdir_name.diff patching file src/tdedistutils.py Hunk #1 succeeded at 2264 (offset -8 lines).
Now at patch debian/patches/11_fix_get_libdir_name.diff
Building using pbuilder Building completed WITH ERRORS
#### Processing module "libraries/pytdeextensions" failed (2) ####
I am attaching a build log, since it's fairly short. Don't know what to make of it.
Question: I have mentioned how the build logs show missing dependencies. You can see that in the attached log at the very beginning. Is this perhaps simply a warning? Meaning, the script realizes that these are the missing dependencies and proceeds with installing them later on? I looked at other build logs, and realized that even modules that build without any issues reported on the console, still have these kind of errors (?) right at the beginning of a log file.
Cheers, Janek
On 2025/11/04 06:40 PM, Jan Stolarek via tde-devels wrote:
I am getting "No series file found" message from quilt.
Patches are already applied when the sources are copied from git to build folder. The 'series' file is deleted to allow local builds to be done several times, otherwise you would have errors when the code was trying to apply the same patches. If you need to add your own patches, you should use the hook mechanism instead (pre or post hooks).
I have mentioned how the build logs show missing dependencies.
Yes, when building in a clean environment, Debian will install all the required dependencies first. Although you log seems to show something else is also going on. Let me test on a VM in coming days/weekend, using r14.1.x branch. I will feedback and if necessary I will fix the scripts. Config and folder structure looks ok at first sight.
Cheers Michele
Patches are already applied when the sources are copied from git to build folder. The 'series' file is deleted to allow local builds to be done several times, otherwise you would have errors when the code was trying to apply the same patches.
Ok, that makes sense. What about the extra `cd -` that I added? Is there a reason not to return to the previous directory that contains the .git information?
Let me test on a VM in coming days/weekend, using r14.1.x branch. I will feedback and if necessary I will fix the scripts.
Thanks. There's no rush, I'll be travelling for a couple of days starting this weekend.
Cheers, Janek
On 2025/11/04 11:06 PM, Jan Stolarek wrote:
Ok, that makes sense. What about the extra `cd -` that I added? Is there a reason not to return to the previous directory that contains the .git information?
No, there shouldn't be a need and I wonder if this is part of the reason you ran into problems. I have been using the exact same scripts daily for 10+ years, so they have been fairly tested. Of course, they are not perfect and they have evolved over time, but the core of the building part has been pretty much the same for a long time, so they should work pretty much out of the box.
Cheers Michele
Hi Janek, I have updated the scripts in a test branch: https://mirror.git.trinitydesktop.org/gitea/TDE/tde-packaging/pulls/476 Can you test on your side as well? Here I have built everything in the 01 and 02 sets. The only failure is pytdeextensions, but the is likely module related (I will have a look separately). Once you confirm that everything now works for you, I will merge the changes.
Mostly, the problem was that I have been using git worktrees for many years now and somewhere along the line, a small bug sneaked in and made builds fail when not using worktrees. I have not tested that builds succeed with and without worktrees.
Cheers Michele
Hi Michele,
thanks for looking into this! I am travelling until next Tuesday, so will try the changes and get back to you next week.
Cheers, Janek
On 2025/11/04 09:57 AM, Michele Calgaro wrote:
Can you send me your config and a screenshot of your folder structure? I can take a look. This weekend I can also try to build a new trixie VM with minimal config and retest the process from scratch, to see if there is any step which is not up to date.
Hi Janek, I have setup a trixie VM with base environment (CLI only) and building r14.1.x branch. I can confirm some of the issues you ran into, specifically when building tqt. I will investigate what the problem is, solve it and update the scripts. Once everything is working, I will let you know and you can give it a new try. Cheers Michele
On 2025/10/31 04:49 AM, Jan Stolarek via tde-devels wrote:
dpkg-parsechangelog: warning: /home/killy/tde//2_build/build/applications/multimedia/k3b/debian/changelog(l5): badly formatted trailer line LINE: -- <> dpkg-parsechangelog:
That points at something wrong with the debian/changelog file. I had this happening sometimes in the past, but I can't recall what the root cause was.
Building using pbuilder Building completed SUCCESSFULLY #### Processing module "applications/multimedia/k3b" succeeded ####
And yet they seem to build successfully? Is this expected?
Not really, this is a bug. I have seen it too sometimes, but I haven't bother fixing it so far :-(
Cheers Michele
Hi Janek, something in your comments seems weird.
I am running a full build with 99_build_tde.sh script These failures are caused by missing dependencies
The 99_build_tde.sh script would build things in a clean environment, so the required dependencies would be automatically installed as needed. So it seems weird that you run into missing dependencies. Can you explain more about how you are building things? Also I would suggest you first start building individual modules to check your setup is correct, then switch to group builds (00_... to 17_... scripts) before trying the full 99_build_tde.sh script.
- Once I install the missing dependencies, what is the right way of rebuilding the failed
modules? Should I run build_module.sh for each of the failed modules? Or should I do 99_build_tde.sh and it will only rebuild the failed modules?
Yes, run build_module.sh for each of the failed modules. If you run 99_build_tde.sh, it will rebuild everything again.
- I am missing packages such as libtqt3-mt-dev or tqt3-dev-tools. These should be installed from
TDE repo, correct? I am running this in a VM that has no graphical environment at the moment, and thus no TDE.
Those packages are part of tqt, so again it seems you may have something wrong in your setup??
Cheers Michele
Hi Michele,
The 99_build_tde.sh script would build things in a clean environment, so the required dependencies would be automatically installed as needed. So it seems weird that you run into missing dependencies. Can you explain more about how you are building things?
Well, it doesn't seem to do so, i.e. some components fail to build due to missing dependencies. For example, on my first attempt to run the build script, it would fail with missing tools such as fakeroot, debhelper, and chrpath. I do have a suspicion why that might be happening. As mentioned, this is a VM with a minimal install of Trixie. In particular, there is no graphical environment at all, and I have not added TDE repositories to the list of sources, other than the deps repo mentioned in the instructions:
deb http://mirror.ppa.trinitydesktop.org/trinity-sb trixie deps-r14
Perhaps the missing tqt packages come from the main TDE repo and if that one is not in available, then installiny dependencies fails altogether - hence the missing basic Debian tools such as fakeroot. I will test this on Monday, see whether adding base TDE repo solves the problem.
Yes, run build_module.sh for each of the failed modules. If you run 99_build_tde.sh, it will rebuild everything again.
Noted, thanks. I am running a full build as a sanity check to make sure my setup is entirely correct. That being said, what is the best way to quickly rebuild a module? I want to be ble to make quick rebuilds to make sure that everything compiles during development - building all deb packages for a given component seems like an overkill here.
Janek
Now that I managed to build full TDE source, as well as a single module in isolation, I want to figure out how to quick rebuilds. By "quick rebuilds" I mean being able to avoid installing the dependencies every single time, as well as skiping building of deb packages. In other words, I want to be able to quickly check whether the code compiles at all.
Going back to the email from 25th October:
There are two main ways of working:
- locally in your computer
Here you build packages in your environment, so you don't have to wait for dependencies to be downloaded and the build is quicker. This is ideal for prototyping, testing, debugging and so on. Depending on what you are working on, occasionally you may end up with weird results, but 99.5% of the time you will be fine. Recommended workflow (refer to readme.txt file):
- ./build_module.sh -g -po <module name> --> prepare the code in a build folder
- switch to the created build folder for the module
- debian/rules clean, followed by debian/rules binary --> builds all the debian binary
packages, locally
- for specific subpart of big modules (like tdelibs, tdebase, ...) you can "cd obj..." and then
use specific ninja targets for partial builds.
If you build locally, you can just build a single module, provided the required dependencies are installed.
I'm having issues with this. Running `debian/rules binary` results in a bunch of warnings about missing files, and then fails with an error. See attached log. I presume there are some additonal preparation steps that need to be taken here? I tried installing via apt all the PSB packages listed as dependencies by amarok, but that does not resolve the problem.
Cheers, Janek
I'm having issues with this. Running `debian/rules binary` results in a bunch of warnings about missing files, and then fails with an error. See attached log. I presume there are some additonal preparation steps that need to be taken here? I tried installing via apt all the PSB packages listed as dependencies by amarok, but that does not resolve the problem.
Hi Janek, sorry I forgot to mention that to do local builds you will need to first manually install all the required packages listed inside "debian/control" file under "Build-Depends". Sme packages may have options, like "pkgA | pkgB | pkgC" so you need to install one that is available. You will also need to have a compiler (gcc) installed. Cheers Michele
sorry I forgot to mention that to do local builds you will need to first manually install all the required packages listed inside "debian/control" file under "Build-Depends".
Ah! Of course, I realized I need to install package dependencies. What I did not realize is that I also need to install dependencies of the Amarok _source_ package - these are the ones I was missing. I installed all the packages in the control file and now I can compile Amarok without having to compile anything else.
Janek
Dne st 19. listopadu 2025 Jan Stolarek via tde-devels napsal(a):
sorry I forgot to mention that to do local builds you will need to first manually install all the required packages listed inside "debian/control" file under "Build-Depends".
Ah! Of course, I realized I need to install package dependencies. What I did not realize is that I also need to install dependencies of the Amarok _source_ package - these are the ones I was missing. I installed all the packages in the control file and now I can compile Amarok without having to compile anything else.
Janek ____________________________________________________
Instead of manually installing the packages listed in Build-Depends, it's easier to switch to the package's source directory and type ():
apt build-dep .
the dot at the end of the line is important because it says the current directory.
Instead of manually installing the packages listed in Build-Depends, it's easier to switch to the package's source directory and type ():
apt build-dep .
Oh, indeed, that makes things so much easier!
One more question: why does building even a single module require root privileges?
Janek
On 2025/11/20 01:38 AM, Jan Stolarek via tde-devels wrote:
One more question: why does building even a single module require root privileges?
That may be related to the recent problem raised by Emanoil about fakeroot in trixie. But I build packages in Trixie VM as normal user, so you should be able to do the same. In any case we are planning to look into Emanoil's point somewhere during R14.1.6 dev cycle.
Cheers Michele
But I build packages in Trixie VM as normal user, so you should be able to do the same.
Unfortunately, I can't. I mean, I need the root privileges both on my VM and on my desktop (both Trixie). The only difference is that on the VM I am using the ./build_module script, which asks for sudo password, whereas on the desktop machine I build with `sudo ./debian/rules binary`. If I don't use sudo in that last call I get a failure saying I need root priviliges.
As you have seen, in debian-based distro building and working on TDE modules is pretty much a breeze.
While I agree that the build scripts help a lot, I would not call the process a breeze. Four weeks in and I still don't have everything I should have in order to fully test my changes. My VM still does not run in graphical mode, which means that for now I can only test changes I make on the r14.1.x branch, because those I can run on my desktop.
Side note: It does not help that kernel shipped with Trixie has a bug [1] that prevents running it under VirtualBox. This means I had to switch to QEmu. In principle, I don't mind that and would love to move away from VirtualBox. VirtualBox does not support DKMS so I have to sign kernel modules manually after every update, which is a pain. QEmu is better in this regard. At the same time, it is a steep learning curve and that slows things down.
Cheers, Janek
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1119137
On 2025/11/20 06:37 PM, Jan Stolarek wrote:
But I build packages in Trixie VM as normal user, so you should be able to do the same.
Unfortunately, I can't. I mean, I need the root privileges both on my VM and on my desktop (both Trixie). The only difference is that on the VM I am using the ./build_module script, which asks for sudo password, whereas on the desktop machine I build with `sudo ./debian/rules binary`. If I don't use sudo in that last call I get a failure saying I need root priviliges.
Ah yes, I forgot that my script use "sudo" :facepalm:
My VM still does not run in graphical mode, which means that for now I can only test changes I make on the
r14.1.x branch, because those I can run on my desktop.
That sounds strange. We probably have different hardware and different host OS, but I have no problem to run a Trixie machine in VirtualBox. Just fyi.
Cheers Michele
-
deloptes -
Jan Stolarek -
Michele Calgaro -
Slávek Banko