vhaudiquet 37e0b5c978 pull: fetch every component tarball of multi-orig packages
Sources listed with "3.0 (quilt)" extra components (node-jest, php-*,
...) carry one tarball per bundled module next to the main orig, named
<package>_<uver>.orig-<component>.tar.<ext>. fetch_orig_tarball picked
the single file matching ".orig.tar." — which cannot even match the
component naming — so a git pull only fetched the main orig. The later
dpkg-source -b quilt verification then failed with "can't find file to
patch" on the first patch touching a component directory.

Select the files with the existing build::changes::is_orig_tarball
helper (mirroring dpkg's \.orig(-.+)?\.tar\. strip pattern) and fetch
all of them, pristine-tar checkout first with a checksummed archive
download fallback, per tarball.

The end-to-end test now asserts every stanza-listed orig lands in the
package dir instead of just any *.orig.tar.* file, and gains a
node-jest (trixie, 24 components) regression case.

Verified live: pkh pull node-jest -d debian fetches all 15 origs of the
sid ds7 repack, and dpkg-source -b builds the debian.tar.xz and dsc
without touching the series.
2026-09-21 11:28:55 +02:00
2026-09-21 01:36:40 +02:00
2026-09-21 01:36:40 +02:00

pkh

pkh is a packaging helper for Debian/Ubuntu packages.

Installation

No distribution channel is published yet; build from source:

sudo apt install pkg-config libssl-dev libgpg-error-dev libgpgme-dev
git clone https://git.vhaudiquet.fr/vhaudiquet/pkh.git
cd pkh
cargo install --path .

At runtime pkh shells out to the Debian packaging toolchain (git, dpkg-dev, quilt, mmdebstrap, lintian, pristine-tar, ...): install the ones your workflows use, or build the classic snap from snap/snapcraft.yaml (snapcraft pack), which carries them.

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:
  new    Scaffold a new Debian source package (buildable right away)
  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)
  put    Upload the built source package to a PPA
  deb    Build the source package into binary package (.deb)
  lint   Lint the package (lintian wrapper + pkh-native checks)
  prune  Prune residual pkh build artifacts and caches
  help   Print this message or the help of the given subcommand(s)

Options:
  -h, --help     Print help
  -V, --version  Print version

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
...
git add debian/patches/xxx.patch
git 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 the commits to your fork
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 new
    • Scaffold a new Debian source package (interactive, multiple languages)
  • 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 prune
    • Prune residual pkh build artifacts and caches
  • 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
S
Description
pkh is a packaging helper for Debian/Ubuntu packages
Readme
3.3 MiB
Languages
Rust 99.9%
Go Template 0.1%