tmux

English

Overview

tmux is a terminal multiplexer. It allows multiple terminal sessions, windows, and panes to be managed from a single terminal client, and it supports detaching and later reattaching to the same running session. The upstream manual describes tmux as a terminal multiplexer and documents its session, window, and pane model. (man.openbsd.org)

Purpose and typical use cases

Typical uses of tmux include:

• keeping long-running shell work active after disconnecting from a local or remote terminal session;
• organizing several command-line tasks inside one terminal window;
• splitting a screen into panes for monitoring logs, editors, shells, or build output;
• sharing a persistent working session across reconnects.

In a Linux distribution, tmux is typically used as an interactive terminal utility for administrators, developers, CI/CD maintainers, and other users who work extensively in terminal sessions. This is an inference from the upstream description and should be verified by NiceOS maintainers if a distribution-specific usage statement is needed. (man.openbsd.org)

Upstream project

The upstream portable project is maintained at GitHub: tmux/tmux. Upstream documentation points users to the tmux manual page for detailed command reference. The project wiki also describes tmux as a terminal multiplexer and links to the getting started guide and manual page. (github.com)

Dist-git repository contents

This NiceOS dist-git repository is expected to contain the packaging sources for the tmux RPM, including:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source metadata and manifest files used to track upstream source inputs;
• METADATA/ — repository metadata used by NiceOS packaging workflows;
• SBOM/ — software bill of materials data, if present for this package.

Large upstream source archives are intentionally not stored in this Git repository. Instead, the repository tracks source integrity through manifest files in SOURCES/. NiceOS maintainers should verify the exact file layout used by this package branch before making packaging changes.

Source storage and integrity policy

The packaging model for this repository is based on metadata-driven source tracking rather than committing large tarballs or generated archives to Git. For this package, integrity information is recorded in SOURCES/ manifests. Do not treat the absence of an upstream archive in the Git tree as an error; it is part of the repository policy.

Maintainers should verify:

• that the manifest entries still point to the intended upstream source material;
• that any regenerated metadata matches the updated spec and source layout;
• that no untracked local artifacts were introduced during update preparation.

This README does not print concrete hashes or digest values.

NiceOS maintenance notes

Before updating this package, NiceOS maintainers should check the following:

• upstream release notes or changelog entries for packaging-impacting changes;
• whether the spec file needs adjustments for new build systems, options, or install paths;
• whether any SOURCES/ manifest files must be regenerated or refreshed;
• whether SBOM/ content, if maintained for this package, needs to be updated;
• whether the packaging still matches the upstream manual and build instructions.

Risks to consider during updates:

• build failures caused by upstream build-system changes;
• behavioral changes that alter default runtime assumptions or configuration handling;
• changes in upstream documentation or file layout that require spec maintenance;
• accidental drift between the recorded source metadata and the intended upstream source.

If any of these points cannot be confirmed from the package metadata or upstream documentation, NiceOS maintainers should verify them explicitly.

Build and verification checklist

Use the following checklist when preparing an RPM update:

1. Confirm that the upstream source reference is correct and that the source manifest was updated as intended.
2. Review the spec file for patches, build flags, and installed paths that may need adjustment.
3. Rebuild the SRPM and RPMs in the target build environment.
4. Inspect build logs for warnings or failures related to configure, compilation, tests, or installation.
5. Verify that the resulting package installs the expected files and does not omit required runtime components.
6. Check that any package-triggered metadata, manifests, or SBOM artifacts were regenerated if required by NiceOS policy.
7. If tests are available upstream or in packaging, run them and record the result.
8. Confirm that the final package content matches the expected source and packaging inputs.

References

• Upstream source repository
• Upstream getting started guide
• tmux(1) manual page

Русский

Обзор

tmux — это терминальный мультиплексор. Он позволяет управлять несколькими терминальными сеансами, окнами и панелями из одного терминального клиента, а также поддерживает отсоединение и последующее повторное подключение к тому же работающему сеансу. В документации upstream tmux описывается именно как terminal multiplexer с моделью сеансов, окон и панелей. (man.openbsd.org)

Назначение и типовые сценарии использования

Типовые сценарии использования tmux:

• сохранение длительных командных сессий после разрыва локального или удалённого подключения;
• организация нескольких задач командной строки в одном окне терминала;
• разделение экрана на панели для журналов, редакторов, оболочек и вывода сборки;
• работа с постоянной сессией при повторных подключениях.

В Linux-дистрибутиве tmux обычно используется как интерактивная терминальная утилита для администраторов, разработчиков, сопровождающих CI/CD и других пользователей, которые много работают в терминале. Это вывод из описания upstream; если требуется формулировка, завязанная на правила конкретного дистрибутива, её нужно отдельно проверить. (man.openbsd.org)

Upstream-проект

Портируемый upstream-проект размещён в GitHub: tmux/tmux. В документации upstream пользователям предлагается обращаться к man-странице tmux для подробного справочника по командам. Вики проекта также описывает tmux как терминальный мультиплексор и содержит ссылки на руководство по началу работы и man-страницу. (github.com)

Содержимое dist-git репозитория

Ожидается, что этот dist-git репозиторий NiceOS содержит упаковочные данные для RPM tmux, включая:

• SPECS/ — spec-файлы RPM и упаковочную логику;
• SOURCES/ — метаданные исходников и manifest-файлы для отслеживания входных upstream-материалов;
• METADATA/ — метаданные репозитория, используемые процессами NiceOS;
• SBOM/ — данные о составе программного обеспечения, если они ведутся для этого пакета.

Крупные upstream-архивы исходников намеренно не хранятся в этом Git-репозитории. Вместо этого целостность исходников отслеживается через manifest-файлы в SOURCES/. Сопровождающим NiceOS следует проверить фактическую структуру файлов именно для этой ветки перед изменениями упаковки.

Политика хранения исходных файлов и контроля целостности

Модель упаковки этого репозитория основана на отслеживании исходников через метаданные, а не на хранении крупных архивов или сгенерированных файлов в Git. Для этого пакета сведения о целостности фиксируются в manifest-файлах SOURCES/. Отсутствие upstream-архива в дереве Git не является ошибкой; это часть политики репозитория.

Сопровождающим следует проверить:

• что записи в manifest-файлах по-прежнему указывают на нужные upstream-материалы;
• что при обновлении была пересоздана вся требуемая метаинформация;
• что в процессе подготовки обновления не появились лишние локальные артефакты.

В этом README не приводятся конкретные хэши или значения digest.

Замечания по сопровождению в НАЙС.ОС

Перед обновлением пакета сопровождающим NiceOS следует проверить:

• примечания к выпуску upstream или changelog на предмет изменений, влияющих на упаковку;
• нужен ли spec-файлу учёт новых параметров сборки, путей установки или системы сборки;
• требуется ли пересоздание или обновление manifest-файлов в SOURCES/;
• нужно ли обновить содержимое SBOM/, если для этого пакета оно ведётся;
• соответствует ли текущая упаковка документации upstream и инструкции по сборке.

Риски, которые следует учитывать при обновлении:

• сбои сборки из-за изменений в системе сборки upstream;
• изменения поведения, влияющие на настройки по умолчанию или обработку конфигурации;
• изменения в документации upstream или структуре файлов, требующие правок spec-файла;
• расхождение между зафиксированными метаданными исходников и фактическим upstream-источником.

Если какой-либо из пунктов не удаётся подтвердить по метаданным пакета или документации upstream, его следует проверить вручную.

Контрольный список сборки и проверки

Используйте следующий контрольный список при подготовке обновления RPM:

1. Подтвердите, что ссылка на upstream-исходники корректна и manifest исходников обновлён намеренно.
2. Проверьте spec-файл на наличие патчей, флагов сборки и путей установки, которые могут потребовать корректировки.
3. Пересоберите SRPM и RPM в целевой среде сборки.
4. Проверьте журналы сборки на предупреждения и ошибки, связанные с configure, компиляцией, тестами или установкой.
5. Убедитесь, что итоговый пакет устанавливает ожидаемые файлы и не пропускает необходимые компоненты выполнения.
6. Проверьте, что метаданные пакета, manifest-файлы или SBOM-артефакты были пересозданы, если это требуется политикой NiceOS.
7. Если upstream или упаковка содержит тесты, запустите их и зафиксируйте результат.
8. Подтвердите, что содержимое итогового пакета соответствует ожидаемым входным данным исходников и упаковки.

Ссылки

• Upstream-репозиторий исходников
• Руководство по началу работы upstream
• Man-страница tmux(1)

Dist-git repository notes

• Package repository: rpms/tmux
• NiceOS branch: niceos-5.2
• This README is intentionally stable and does not include EVR, source archive checksums or lock hashes.