babeltrace

Overview

Babeltrace is a trace viewer and converter for Common Trace Format (CTF) data. Upstream describes Babeltrace 2 as a trace processing and conversion project, with a library, command-line tools, and plugins for working with traces. In a Linux distribution, this package provides the trace-processing tools and library components that users and other packages can rely on when they need to inspect, convert, or process CTF traces. (efficios.com)

Purpose and typical use cases

Typical use cases include:

• converting traces between supported formats;
• reading and inspecting CTF traces;
• processing trace data with Babeltrace tools or APIs;
• integrating trace handling into scripts, plugins, or automation.

Typical users include:

• system administrators who need to inspect trace output from a host or service;
• developers working on tracing, diagnostics, or tooling around CTF data;
• security engineers and incident responders who examine trace artifacts as part of investigations;
• CI/CD maintainers who run trace-processing checks or packaging validation jobs;
• other users who need to transform or analyze trace data in a repeatable way.

Upstream project

The upstream project is maintained by EfficiOS. The official Babeltrace site describes the project as a trace manipulation toolkit, and the Babeltrace 2 manual states that its purpose is to process or convert traces. The documentation also describes a modular design with a library, plugins, and command-line utilities. (efficios.com)

If NiceOS maintainers need to confirm a package-specific integration detail, they should verify it against the upstream documentation for the exact branch or release being packaged. (babeltrace.org)

Dist-git repository contents

This dist-git repository contains the packaging metadata for the RPM package, not the full upstream source tree.

Expected top-level areas:

• SPECS/ — RPM spec files and packaging logic;
• SOURCES/ — source manifests and related integrity metadata;
• METADATA/ — repository metadata used by the packaging workflow;
• SBOM/ — software bill of materials material, when present for the package.

Large upstream source archives are intentionally not stored in this Git repository. They are handled separately, while the SOURCES directory records the source integrity metadata needed by the packaging workflow. This keeps the dist-git repository small and avoids storing large payloads in Git. (efficios.com)

Source storage and integrity policy

NiceOS tracks upstream source integrity through manifest files in SOURCES. The exact manifest format may vary by package, but the key idea is the same: Git stores references and metadata, while the actual upstream archive is retrieved through the packaging process.

Before relying on any update, maintainers should verify that:

• the manifest entries in SOURCES match the intended upstream source set;
• the spec file points to the correct source layout;
• any source or patch additions are intentional;
• the upstream provenance is clear enough for the repository policy in use.

Do not assume that every source-related file is regenerated automatically. Some updates may require manual refresh of manifests or packaging metadata. If the package uses additional generated files, NiceOS maintainers should verify whether they must be updated together with the spec.

NiceOS maintenance notes

Before updating this package, check the following:

• upstream release notes or change log for user-visible packaging impact;
• build system changes that might affect the spec file, generated build scripts, or helper macros;
• whether any installed files, plugins, or library sonames changed;
• whether the package needs refreshed SOURCES manifests or rebuilt auxiliary metadata;
• whether SBOM/ content, if maintained for this package, needs regeneration;
• whether downstream patches still apply cleanly and are still needed;
• whether new upstream behavior changes the package's runtime or build-time assumptions.

Risks to consider:

• trace-processing packages often interact with external trace data, so regressions may appear only with real input;
• changes in plugin behavior or command-line output can affect scripts that parse the output;
• changes in build tooling can affect reproducibility or subpackage split points.

If any of these points is uncertain for a given update, NiceOS maintainers should verify it before accepting the change.

Build and verification checklist

For RPM maintenance, a practical pre-merge checklist is:

• review the upstream release notes or tagged documentation relevant to the package;
• confirm the source manifest in SOURCES matches the intended upstream input;
• inspect the spec file for new build requirements, renamed files, or packaging splits;
• rebuild in a clean environment;
• run the package test suite if the upstream project provides one and if it is suitable for distribution builds;
• verify the main binaries, libraries, plugins, and man pages that the spec is expected to ship;
• check for unexpected file list changes;
• confirm rpmlint or equivalent package checks are clean or that any exceptions are documented;
• test basic runtime behavior with a small known-good trace, if available to the maintainer.

References

• Babeltrace official site
• EfficiOS Babeltrace page
• Babeltrace 2 introduction manual
• Babeltrace GitHub repository

Russian documentation

See README_RU.md for the Russian version of this documentation.

Dist-git repository notes

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