t2sde

T2 SDE

T2 SDE is not just a regular Linux distribution - it is a flexible Open Source System Development Environment or "meta distribution". T2 allows the creation of custom distributions with state of the art technology, up-to-date packages and integrated support for cross compilation. Currently the Linux kernel is usually used, but we also started to port T2 to support compiling home-brew like add-on packages on macOS, BSDs, classic Unix systems (Irix, ...) or support bootstrapping alternative micro kernel systems (like a L4 variant or Fuchsia). Similarly building Haiku, Android, Minix, Hurd, Open (or Pure) Darwin, Haiku and OpenBSD could be supported, too.

Download

It is usually best to start with a pre-built ISO download. More information, including about the latest source tree are at:

https://t2sde.org/download/

History

"T2" started as a community driven fork of the ROCK Linux project in 2004, aiming for a simple, clean, lightweight and cross-compiling build system.

"T2" was an intern project name for "try two / second try" or "technology two". The idea was to eventually choose a more public relation aware name, but somehow we just kept sticking with t2 so far ;-)

T2 SDE Developer Cheatsheet

Quick reference for T2 SDE development, system maintenance and hacking. Run commands from /usr/src/t2-src.

Reference docs:

• T2 Handbook
• Knowledge Base

Background: t2, mine and bize

T2 SDE started as a fork of ROCK Linux, and some of the tools date back to that time. Source build scripts live in scripts/*; binary package handling is a separate, older layer:

Source builds always go through the top-level t2 mapping to internal scripts/*. Binary package install/remove goes through mine or bize; the stone installer and t2 uninstall use mine when available and fall back to bize. The .gem format is the ROCK/T2 binary package container (unrelated to Ruby gems); plain tar.* packages carry the same content without the wrapper.

Contents

• Background: t2, mine and bize
• t2 Command Overview
• Getting Started
• Package Maintenance
  • Build
  • Rebuild
  • Cleaning
  • Reading Build Errors
• Package Development
  • Create a Package from a URL
  • .desc Field Reference
  • Update a Package Version
  • Compute a Download Checksum
  • Validate Packages
  • Submit a New Package
  • Test Downloads Against the Real URL (not the mirror)
• Hacking the Source Tree
  • Listing Changed Files
  • Comparing Against Upstream
  • Single File - Diff & Pull from Upstream
  • Colored Diff
  • Patching
  • Commit Workflow
• Building Systems
  • Building a T2 Target (Full System)
  • Kernel Build Options
  • Build an ISO
  • Install Binary Packages into Another Root

t2 Command Overview

Getting Started

Always update the source tree before starting work to avoid working on stale files.

t2 up

Note: t2 update is different: it bumps a package's version metadata (queries Repology, refreshes checksums). It does not update the source tree.

Package Maintenance

Build

Build (and install) a package and its dependencies. Use -optional-deps=no to skip optional deps and -parallel 1 for serialized, readable output.

t2 install -optional-deps=no -parallel 1 

Rebuild

Rebuild and reinstall a package even if it is already installed and up to date. Use this after editing a .desc so the change takes effect.

t2 install -force 
t2 install -force -optional-deps=no -parallel 1 

The second form skips optional dependencies and prints serialized, readable output.

Cleaning

Remove build artifacts (temporary src.* build dirs, logs) to start fresh.

t2 clean 
t2 clean

Reading Build Errors

When a build fails, T2 writes per-package logs to /var/adm/logs/, named -.{out,log,err}. A .err file means that package failed; .out holds the full output and .log a successful build. The path is:

/var/adm/logs/-.err

List or browse current build errors across the target with:

t2 list-errors

Inspect a specific failure directly (full output and the error log):

ls /var/adm/logs/*.err
less /var/adm/logs/9-.err
less /var/adm/logs/9-.out

Package Development

Create a Package from a URL

t2 create generates a new package skeleton. For GitHub/GitLab URLs it queries the API and fills in description, author, license, latest release version and the [D] download automatically; kde.org and gnome.org URLs get matching repository defaults.

t2 create https://github.com//
t2 create package// 

It creates package///.desc, adds the copyright header, runs svn add, then immediately starts a test build. Fill in any fields it prints as TODOs afterwards.

.desc Field Reference

[P] syntax, e.g. X 01---5---9 110.900:

• X or O: build by default or not
• 10-character stage mask, one position per stage 0-9: a digit means the package builds in that stage (0 = host toolchain, 1-2 = cross, 5+ = native), - means it is skipped there
• priority number: a plain sort key for the build order (sort -k3 in scripts/Create-PkgList), the dot is only a naming convention: digits before it are the coarse group (000 dirtree, 101 libc, 102 toolchain, 110 libraries, 5xx applications, 800 kernel), digits after it order packages within the group

Common [F] flags:

Update a Package Version

t2 update bumps a package's [V] version and refreshes the [D] checksums:

Compute a Download Checksum

[D] lines use the legacy "Unix" CRC cksum or, preferably, modern SHA of the decompressed tarball, not of the file:

cripts/Create-CkSumPatch 

Validate Packages

Lint a package's .desc format, and check upstream for newer versions:

scripts/Check-PkgFormat 
scripts/Check-PkgVersion 

Both also accept -repository to sweep a whole repository.

Submit a New Package

Include the build cache so reviewers have dependency information:

t2 ci --cache 

Test Downloads Against the Real URL (not the mirror)

By default t2 download uses the T2 mirror, which hides broken [D] URLs. To test the real upstream URL, turn the mirror off, re-fetch, then restore it:

t2 download --mirror none
rm download/Mirror-Cache

Hacking the Source Tree

Listing Changed Files

Show which files have changed across the tree, or scoped to a package:

svn status
svn status package/base/bash

For a per-file line-count summary (+/-), pipe through diffstat:

svn diff | diffstat
svn diff package/base/bash | diffstat

Comparing Against Upstream

Show what changed on the server since your last update (ignores your local edits):

svn diff -r BASE:HEAD | diffstat
svn diff -r BASE:HEAD | colordiff | less -R

Show how your working copy differs from the latest upstream HEAD (local + upstream changes combined):

svn diff -r HEAD | diffstat

Quick reference:

Single File - Diff & Pull from Upstream

Diff one file against upstream (server changes only):

svn diff -r BASE:HEAD package/base/bash/bash.desc

Pull (update) one file from upstream without touching anything else:

svn update package/base/bash/bash.desc

Colored Diff

Pipe through colordiff and page with -R to preserve colors:

svn diff | colordiff | less -R
svn diff package/base/bash | colordiff | less -R

Patching

Generate a patch to ship upstream. In an svn checkout, svn diff is enough:

svn diff package///.desc > package-fix.patch

Apply a patch to the tree:

t2 apply 

Commit Workflow

For an interactive diff-review + auto-generated cksum and commit log before committing to SVN:

t2 commit bash

To batch commit all locally modified packages that have a [D] download entry:

t2 ci $(grep 'D] .[^ ]' $(svn st package/ | grep '\.desc$' | sed 's/.* //') | cut -d / -f 3)

Building Systems

Building a T2 Target (Full System)

Build a complete system from source into a sandbox under build//.

1. Create a build config

Each config lives in config// and is independe