vhaudiquet a0e74073bf
CI / build (push) Successful in 2m55s
CI / test (push) Skipped
CI / snap (push) Successful in 4m32s
lint: add pkh lint, wrapping lintian for parity plus pkh-native checks
pkh covered the package lifecycle but never validated the packaging
itself: broken control stanzas, unparsable changelog versions or
uncommitted debian/ edits only surfaced at build or upload time. pkh
lint lints a source tree with day-one lintian parity plus a native Rust
engine for the checks lintian cannot have.

The wrapper reuses the pkh build output next to the tree when it matches
the current changelog entry and no tree content is newer (mtime walk,
skipping .git/.pc), else packs fresh with dpkg-source -b using weak gzip
compression (the artifact is ephemeral; xz dominated the run at 9.8 s
versus 2.7 s on a 111 MB tree) and symlinks quilt orig tarballs from the
tree's parent, which dpkg-source searches in cwd. Findings are parsed
from the installed lintian into a unified report, deduplicated by tag
name against the native engine, and rendered lintian-shaped
(<L>: <pkg> <type>: <tag> <details>) as text or JSON, colorized at
render time (--color auto/always/never). Exit codes follow lintian's
contract (0 clean, 1 findings at/above --fail-on, 2 runtime error);
lintian's own exit code is ignored because it uses 2 both for findings
and for runtime errors. -d/--dist maps to lintian --profile so the
target distro's rules apply even on a foreign host.

The native engine hosts the first workflow check lintian cannot know:
pkh-debian-changes-not-committed flags debian/ content that is not
committed to git, since the pkh flow builds and uploads the tree as-is.
Checks register in a static registry validated by a unit test, and the
wrapper's parser is pinned by golden tests captured from lintian 2.129
output. Strategies for lintian's Ubuntu blind spots (its vendor data
there is one file plus 14 disabled tags) are specced in
plans/pkh-lint.md, deliberately not implemented yet.
2026-09-19 23:45:31 +02:00
2026-08-22 21:20:44 +02:00
2025-11-26 00:22:09 +01:00

pkh

pkh is a packaging helper for Debian/Ubuntu packages.

Usage and features

Basic concepts

pkh aims at wrapping the different debian tools and workflows (git, git-ubuntu, pull-debian-sources, pull-lp-sources, pull-ppa-sources, dch, dpkg-buildpackage, sbuild, dpkg-source, quilt, ...) into one tool, that would have the same interface for everything, while being smarter at integrating all workflows.

Thus, pkh uses similar options for all subcommands (with very few command-specific options):

Options:
  -s, --series <series>    Target package distribution series
  -d, --dist <dist>        Target package distribution (debian, ubuntu)
  -v, --version <version>  Target package version
  -a, --arch <arch>        Target architecture (amd64, arm64, riscv64, ...)
  -p, --pocket <pocket>    Target distribution pocket (updates, security, proposed, ...)
      --ppa <ppa>          Do the action in/for a specific PPA

Commands and workflows include:

Commands:
  pull   Pull a source package from the archive or git
  chlog  Auto-generate changelog entry, editing it, committing it afterwards
  build  Build the source package (into a .dsc)
  deb    Build the source package into binary package (.deb)
  put    Upload the built source package to a PPA
  help   Print this message or the help of the given subcommand(s)

Examples

A typical workflow to patch an Ubuntu package hello on the development release could be:

# Obtain the package source
git ubuntu clone hello
cd hello
# Apply the patch to the package
...
dpkg-source --commit
# Increment version number
dch
# Test that the patch builds
git ubuntu export-orig
dpkg-buildpackage -S -I -i -nc -d
sbuild --dist resolute --arch amd64 ../hello_xxx.dsc
# Upload the package to a ppa
dput ppa:user/hello_xxx ../hello_xxx_source.changes
# Commit the changes to git
git add debian/patches/xxx.patch
git commit -m "Applied patch xxx"
git add debian/changelog
git commit -m "changelog"
git checkout -b xxx
git push xxx user-fork

That is a lot of different tools and operations. With pkh, the same workflow:

# Obtain the package source (and orig tarball)
pkh pull hello # needs -d ubuntu if you are not running Ubuntu
# Apply the patch to the package
...
pkh commit -m "Applied patch xxx"
pkh chlog
# Test that the package builds
pkh build
pkh deb
# Upload the package to a ppa
pkh put --ppa user/hello_xxx
# Push previously commited changes
git push xxx user-fork

Roadmap: features needed for 1.0

Basically, wrapping the basic debian workflows. Missing features:

  • pkh pull
    • Obtain package sources from git
    • Obtain package sources from the archive (fallback)
    • Obtain package source from PPA (--ppa)
    • Obtain a specific version of the package
    • Fetch the correct git branch for series on Ubuntu
    • Try to fetch the correct git branch for series on Debian, or fallback to the archive
  • pkh chlog
    • Auto-generate changelog entry
    • Extra flags: backport, non-maintainer upload, no change rebuild, ...
    • Commit changelog entry
  • pkh build
    • Build the source package
  • pkh deb
    • Build the binary package
    • Build for a specific architecture
    • Three build modes:
      • Build locally (discouraged)
      • Build using unshare chroot, with binary emulation (default)
      • Cross-compilation
    • Async build
  • pkh status
    • Show build status
  • pkh put
    • Upload the source package to a PPA (native SFTP, no dput dependency)
    • Upload the source package to the archive
  • pkh commit
    • Commit the changes to git
  • pkh lint
    • Lint the package
  • pkh test
    • Run autopkgtest
    • Provide options: local (discouraged), chroot, VM?, ppa
    • Async test

Nice-to-have features

  • 'pkh pull'
    • Cache the Sources.gz files, to improve speed
    • Work in an already downloaded package, to git pull and re-fetch orig tar gz
  • 'pkh context'
    • Select, add, remove, list contexts
    • Context-scoped command execution
    • Context-scoped deb and test commands
    • Per-architecture contexts
    • Per-series contexts
    • ssh contexts
    • docker, lxc contexts?
    • context push, context pop: context stack
S
Description
No description provided
Readme
1.6 MiB
Languages
Rust 99.9%
Go Template 0.1%