BranchesTags

Latest commit

History

23 Commits

Folders and files

NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md

Repository files navigation

#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm

T3 Code native DEB and RPM packaging

This repository provides unofficial Linux packages for T3 Code. It builds from the canonical pingdotgg/t3code repository and forms packages with the distribution tools themselves:

  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.

The Electron application is built once as an unpacked payload. Both package formats consume that exact payload, so building DEB and RPM does not compile the application twice. Neither package is created by electron-builder, fpm, npm packaging wrappers, or a package-conversion tool.

Supported targets

  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64

The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM dependency names target current Fedora and RHEL-family distributions.

Build requirements

Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron native-module build prerequisites. The source commit and archive SHA-256 are pinned in Makefile.

Package formation additionally requires:

  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and libappstream-glib in the pinned Fedora container

Full package validation additionally uses lintian, rpmlint, and Docker. The Docker checks install and smoke-test the packages in Debian 13 and Fedora 43 containers on the native build architecture.

The source build downloads the dependency graph locked by pnpm-lock.yaml. That is appropriate for vendor packages and CI, but it is not acceptable for an official Debian or Fedora repository build environment. Admission to those archives would also require vendoring/auditing the Node dependency sources and fully declaring bundled components.

Commands

make payload
make packages
make check
make install-test

Outputs are written to dist/. To build one format only:

make deb
make rpm

make packages reuses the same input-keyed build/payload/<arch>/ directory for both formats. Changing the source, version, timestamp, or toolchain selects a fresh payload rather than silently reusing incompatible output. Changes to the Makefile also invalidate an existing payload stamp so recipe edits cannot silently reuse old output. The Makefile is orchestration only; the actual native recipes are debian/rules and rpm/t3code.spec.

The version and source settings can be overridden through the environment or on the make command line. Dynamic builds must supply a full commit SHA. An empty SOURCE_SHA256 is supported for exploratory builds that resolve an immutable commit dynamically; the downloaded archive's digest is still logged. Automated builds resolve the digest before starting the architecture matrix and verify every download against it.

make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=

Automated builds

  • Daily main packages runs every day and on demand. It builds the current pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest non-prerelease from pingdotgg/t3code and builds that exact release commit.

Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the DEB on the host and the RPM in a native Fedora container, both from the same per-architecture payload, retain the results as workflow artifacts, and publish the validated packages to git.tuxbase.com. Daily packages belong to the t3code-daily organization; stable packages belong to t3code-stable. Every workflow run is a distinct package release, even when the upstream stable version has not changed. The workflows lint the packages, install them in Debian and Fedora containers, smoke-test both launchers, and publish a SHA256SUMS file. They do not publish or replace GitHub releases.

Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN. Its Forgejo user must have package write access to both organizations, and the token must have the write:package scope. Package uploads begin only after both architecture jobs succeed. Publication fails closed if an identical package identity already exists because Forgejo's conflict response does not prove that the existing and newly built files have the same contents. Delete packages from a partial publication before rerunning the same workflow run.

RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM with the package owner's registry key, matching the gpgkey in its generated .repo file. The locally built workflow artifacts remain unsigned. Forgejo signs Debian repository metadata itself, so DEB uploads do not request package signing; APT clients trust the owner key from the registry's repository.key endpoint.

The stable repositories are available at these endpoints once the t3code-stable organization exists and its package registry is public:

APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.

Installed layout

/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and Chromium notices, a generated inventory of production dependency licenses, and a third-party licensing guide. License files for bundled npm dependencies are retained inside the Electron application archive and its unpacked native-module tree.

The headless launcher uses Electron's bundled Node mode and loads apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node APIs treat ASAR archives as virtual directories. This is intentional: the upstream Linux build only guarantees native modules in app.asar.unpacked, not the server JavaScript entrypoint.

Updating

For a new T3 Code version:

  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in clean Debian/Ubuntu and Fedora/RHEL-family test systems.

The patch in patches/ only teaches the upstream artifact builder to copy the directory emitted by electron-builder's dir target. It does not delegate DEB or RPM creation to electron-builder.

About

unofficial Linux packages for t3code

Resources

Readme
MIT license
Activity

Stars

0 stars

Watchers

0 watching

Forks

0 forks
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
BranchesTags
Latest commit
History
23 Commits
Folders and files
NameName
Last commit message
Last commit date
.github
.github
debian
debian
packaging
packaging
patches
patches
rpm
rpm
.gitignore
.gitignore
LICENSE
LICENSE
Makefile
Makefile
README.md
README.md
Repository files navigation
#if anyone wants the packages my packaged versions are avaialble at https://git.tuxbase.com/t3code-stable/-/packages and https://git.tuxbase.com/t3code-daily/-/packages i have setup repos for both deb and rpm
T3 Code native DEB and RPM packaging
This repository provides unofficial Linux packages for T3 Code. It builds from
the canonical pingdotgg/t3code repository and forms packages with the
distribution tools themselves:
  • Debian/Ubuntu: dpkg-buildpackage plus a small, explicit debhelper ruleset.
  • Fedora/RHEL-family: rpmbuild plus a conventional spec file.
The Electron application is built once as an unpacked payload. Both package
formats consume that exact payload, so building DEB and RPM does not compile
the application twice. Neither package is created by electron-builder, fpm,
npm packaging wrappers, or a package-conversion tool.
Supported targets
  • x86-64: Debian amd64, RPM x86_64, Electron x64
  • ARM64: Debian/RPM arm64/aarch64, Electron arm64
The DEB dependency names target Debian 13 and Ubuntu 24.04 or newer. The RPM
dependency names target current Fedora and RHEL-family distributions.
Build requirements
Building the payload requires Node.js 24.13.1, pnpm 11.10.0, Rust 1.97.1 with the
matching GNU Linux target, ImageMagick, a C/C++ toolchain, and normal Electron
native-module build prerequisites. The source commit and archive SHA-256 are
pinned in Makefile.
Package formation additionally requires:
  • DEB: dpkg-dev, debhelper, and fakeroot
  • RPM: Docker; make rpm installs rpm-build, desktop-file-utils, and
libappstream-glib in the pinned Fedora container
Full package validation additionally uses lintian, rpmlint, and Docker.
The Docker checks install and smoke-test the packages in Debian 13 and Fedora
43 containers on the native build architecture.
The source build downloads the dependency graph locked by pnpm-lock.yaml.
That is appropriate for vendor packages and CI, but it is not acceptable for
an official Debian or Fedora repository build environment. Admission to those
archives would also require vendoring/auditing the Node dependency sources and
fully declaring bundled components.
Commands
make payload
make packages
make check
make install-test
Outputs are written to dist/. To build one format only:
make deb
make rpm
make packages reuses the same input-keyed build/payload/<arch>/ directory
for both formats. Changing the source, version, timestamp, or toolchain selects
a fresh payload rather than silently reusing incompatible output. Changes to
the Makefile also invalidate an existing payload stamp so recipe edits cannot
silently reuse old output. The Makefile is orchestration only; the actual
native recipes are
debian/rules and rpm/t3code.spec.
The version and source settings can be overridden through the environment or
on the make command line. Dynamic builds must supply a full commit SHA. An
empty SOURCE_SHA256 is supported for exploratory builds that resolve an
immutable commit dynamically; the downloaded archive's digest is still logged.
Automated builds resolve the digest before starting the architecture matrix and
verify every download against it.
make packages \
VERSION=2026.8.8 \
RELEASE=42 \
PACKAGE_DATE=2026-08-08 \
SOURCE_COMMIT=0123456789abcdef0123456789abcdef01234567 \
SOURCE_SHA256=
Automated builds
  • Daily main packages runs every day and on demand. It builds the current
pingdotgg/t3codemain commit with the calendar version YYYY.M.D and uses
the workflow run number as the package release.
  • Latest stable packages runs every day and on demand. It resolves the latest
non-prerelease from pingdotgg/t3code and builds that exact release commit.
Both workflows build on native x86-64 and ARM64 Ubuntu runners. They form the
DEB on the host and the RPM in a native Fedora container, both from the same
per-architecture payload, retain the results as workflow artifacts, and publish
the validated packages to git.tuxbase.com. Daily packages belong to the
t3code-daily organization; stable packages belong to t3code-stable. Every
workflow run is a distinct package release, even when the upstream stable
version has not changed. The workflows lint the packages, install them in
Debian and Fedora containers, smoke-test both launchers, and publish a
SHA256SUMS file. They do not publish or replace GitHub releases.
Forgejo publication requires a GitHub Actions secret named FORGEJO_TOKEN.
Its Forgejo user must have package write access to both organizations, and the
token must have the write:package scope. Package uploads begin only after both
architecture jobs succeed. Publication fails closed if an identical package
identity already exists because Forgejo's conflict response does not prove that
the existing and newly built files have the same contents. Delete packages from
a partial publication before rerunning the same workflow run.
RPM uploads request Forgejo's server-side signing. Forgejo signs each stored RPM
with the package owner's registry key, matching the gpgkey in its generated
.repo file. The locally built workflow artifacts remain unsigned. Forgejo
signs Debian repository metadata itself, so DEB uploads do not request package
signing; APT clients trust the owner key from the registry's repository.key
endpoint.
The stable repositories are available at these endpoints once the
t3code-stable organization exists and its package registry is public:
APT: https://git.tuxbase.com/api/packages/t3code-stable/debian stable main
RPM: https://git.tuxbase.com/api/packages/t3code-stable/rpm.repo

The daily equivalents use owner t3code-daily, APT distribution daily, and
https://git.tuxbase.com/api/packages/t3code-daily/rpm.repo.
Installed layout
/usr/bin/t3code graphical launcher
/usr/bin/t3 bundled headless server launcher
/usr/lib/t3code/ Electron application payload
/usr/share/applications/t3code.desktop desktop and URL-scheme registration
/usr/share/metainfo/ AppStream metadata
/usr/share/icons/hicolor/ application icon

The packages install the upstream MIT license together with the Electron and
Chromium notices, a generated inventory of production dependency licenses, and
a third-party licensing guide. License files for bundled npm dependencies are
retained inside the Electron application archive and its unpacked native-module
tree.
The headless launcher uses Electron's bundled Node mode and loads
apps/server/dist/bin.mjs directly from resources/app.asar. Electron's Node
APIs treat ASAR archives as virtual directories. This is intentional: the
upstream Linux build only guarantees native modules in app.asar.unpacked, not
the server JavaScript entrypoint.
Updating
For a new T3 Code version:
  1. Update VERSION, SOURCE_COMMIT, SOURCE_SHA256, and
SOURCE_DATE_EPOCH in Makefile.
  2. Update debian/changelog, the version/release in rpm/t3code.spec, and the
AppStream release in packaging/t3code.metainfo.xml.
  3. Rebuild with make clean packages check on both supported architectures.
  4. Inspect contents with dpkg-deb --contents and rpm -qlp, then install in
clean Debian/Ubuntu and Fedora/RHEL-family test systems.
The patch in patches/ only teaches the upstream artifact builder to copy the
directory emitted by electron-builder's dir target. It does not delegate DEB
or RPM creation to electron-builder.
About
unofficial Linux packages for t3code
Resources
Readme
MIT license
Activity
Stars
0 stars
Watchers
0 watching
Forks
0 forks
Report repository
Releases
Packages
Contributors
Languages