T2 Knowledge Base - Getting started with a fresh T2 install (2024)

#8 Getting started w/ a fresh T2 install

2023-06-06, by René Rebe

So you installed T2 on a newsystem and want to install additional, latest and greatest open sourcesoftware or update the already pre-installed packages. In this article we compiled asummary of the most important steps to get you started:

As T2 is a source based, rolling release Linux distribution, youfirst need the latest T2 sources including it's meta-data of packagebuild recipes. Since August 2023 this sources come pre-installed in/usr/src/t2-src, for older or more minimal installation sets, you cansimply check them out via Subversion (SVN, just like Git ;-) with:

svn co https://svn.exactcode.de/t2/trunk /usr/src/t2-src

and change into T2 source directory. All T2 commands are run frominside the source-tree:

cd /usr/src/t2-src

Using the T2 source based build system you can simply installpackage using "scripts/Emerge-Pkg". The scripts determinedependencies, and on the first invocation also copy the installedsystem configuration from /etc/SDE-CONFIG to the source tree'sconfig/default. For example to install the Lua scripting language, you can simplyrun:

scripts/Emerge-Pkg lua

Usually that would already be all you need to know to install newsoftware packages and it's dependencies. However, there are somecomplications we like to point out:

Rebuilding vital packages w/ known cross compile issues

As T2 dev team intentionally cross compiles all ISOs —so allarchitecture builds are created equal— no matter the build host. ARMor RISCV. To have identical configuration and uncover build issues forall builds quickly. However, some packages must be re-build to befully functional. Perl and Python are currently the main offenders. Tobuild some, more complex source packages (such as KDE, GNOME, but alsoWine or Qemu), first rebuild those:

scripts/Emerge-Pkg -f perl perl-xml-parser \
python pip setuptools meson ninja libtool libxml

Keeping your whole system up-to-date

To keep up-to-date with latest bug and security fixes, releaseddaily by all the individual Open Source projects, it is recommended torun Emerge-Pkg as often as necessariy for your level of expectedsystem security for the packages already installed in the system:

scripts/Emerge-Pkg -system

Which will result in a set of package updates to be build similarto:

> gcc ... New version (13.1.0 -> 13.1.1). Vital, skipped by default.
> openssl ... New version (1.1.1t -> 1.1.1u). Added.

As some packages, including the system compiler and C library areconsidere vital, they are not build by default and the educated usercan choose for themselves if the want to manually schedule themfor update.

Gobject-Introspection

If you plan to install Gtk-based components of the GNOME desktopenvironment, you most likely also need to rebuild some of it's basepackages. This is because at the time of writing,gobject-introspection does not support cross-compilation as itrequires to run native helper binaries to process the annoated sourcecode for introspection. While we plan to tackle this issue in thefuture, for now you need rebuild those packages in order to have the.gir gobject introspection data generated for other packages:

scripts/Emerge-Pkg -f gobject-introspection gdk-pixbuf pango \
harfbuzz at-spi2-core graphene gtk

Broken, stray dependencies

As we believe in automation, T2 does not use human curateddependency information, and instead relies on our build sandbox tocache all accessed file information to map those to package fordependencies. While this usually works quite well, modern complexsources often unintentionally pull in various random false positives,e.g thru Python and other such meta data registries and buildartefacts. While we work on ironing and filtering out the lastremaining random fake depencies, our scripts/Emerge does currentlyonly perfom one-level, direct depenency resolution. Due to that thereare can be overly complex compendency chains (e.g. often with modernKDE and GNOME pkgs) that will cause build errors and require manuallyadding this secondary depencneis in case of build errors. For suchexceptions, for now a little common sense has to be used to derivepotentially missing pkg from build errors:

t.b.d. example build error missing X

In this case X is missing and has to be added together with theoriginal pkg you want to install to the Emerge arguments.

Too many dependencies

As T2's sandbox currently tries to cache the maximally requireddependencies, Emerge might at times want to build more than you wouldlike to install. For example:

scripts/Emerge-Pkg php
> php ... Not installed. Added.
php> brotli ... Not installed. Added.
php> cyrus-sasl2 ... Not installed. Added.
php> openldap ... Not installed. Added.
4 packages scheduled to build: brotli cyrus-sasl2 openldap php

As a professional power user, you might realize you don't need someor none of the optional depenencies, and thus cancel the build, anddisable dependency resolution and specify only the ones you like toinstall:

scripts/Emerge-Pkg brotli php

For future releases we not only plan to work in improving theautomatically cached dependencies, we also plan to annotate (at leastthe most important) optoinal dependencies, so future updates ofEmerge-Pkg will provide feedback and ask whether to install optionaldependencies, too.

Rebuild binutils for build time estimates

T2 is caching package build times using the Binutils package astime reference. If you want the T2 build scripts estimate the timeneded to build a package you need to once force re-build binutils tohave it's reference time available:

scripts/Emerge-Pkg -f binutils

The Author

René Rebe studied computer science and digital media science at theUniversity of Applied Sciences of Berlin, Germany. He is the founderof the T2 Linux SDE, ExactImage, and contributer to various projects in theopen source ecosystem for more than 20 years,now. He also founded the Berlin-based software companyExactCODE GmbH.A company dedicated to reliable software solutions that just work, every day.