a0e74073bf0435f574209ab97530a001aaa601b3
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.
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
dputdependency) - Upload the source package to the archive
- Upload the source package to a PPA (native SFTP, no
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
Languages
Rust
99.9%
Go Template
0.1%