Proposal: infrastructure for Debian packaging of the Odoo 18 + OCA Python libraries #1

New issue

Open

opened 2026-09-29 23:04:28 -03:00 by navigator · 1 comment

navigator commented

2026-09-29 23:04:28 -03:00

Owner

Scope: the 34 pure Python libraries the packaging map (handbook PR #23, docs/odoo-python-packaging-map.md) lists as missing from trixie, packaged the Debian Python Team way so they can later go to Debian. This issue proposes the infrastructure only; no package is started before it is accepted. Decision 0022 stays open: this work makes the .deb option measurable, it does not decide it.

1. Repository per source package

One repository per source package on git.pop.coop/deb/<source> (for example deb/python-openupgradelib, deb/python-xsdata), public. The binary is python3-<name>.
git-buildpackage layout, the same one the Debian Python Team uses on Salsa, so a repository can be pushed to Salsa unchanged:
- branches debian/master, upstream, pristine-tar; upstream tags upstream/<version>, packaging tags debian/<version>;
- debian/gbp.conf with debian-branch = debian/master, pristine-tar = True;
- debian/control: Maintainer: Marcos Mendez <mendez.foto@gmail.com>, Rules-Requires-Root: no, Build-Depends: dh-sequence-python3, pybuild-plugin-pyproject, python3-all, ..., Testsuite: autopkgtest-pkg-pybuild when upstream has tests;
- debian/rules: dh $@ --buildsystem=pybuild;
- debian/copyright in full DEP-5, debian/watch (PyPI or GitHub tags), debian/upstream/metadata, debian/salsa-ci.yml, and debian/README.source whenever an older upstream is packaged on purpose.
The upstream tarball comes from PyPI (sdist) or a GitHub tag, fetched by uscan and checked against the hash PyPI publishes. PyPI is the source of the tarball, never an install path.
A template repository deb/python-package-template carries the skeleton above plus the CI workflow, so each new package starts from the same files.

2. Versions

Names are Debian's, never Keel's: source python-<name>, binary python3-<name>. Keel shows only in the Debian revision.
Not in Debian: <upstream>-0+keel1. It sorts below -1, so the Debian upload replaces it cleanly, and it carries the +keelN suffix the apt tooling already requires (BRIEF section 7), so bin/build-package needs no change.
Backport of something already in sid (pyzbar): <sid version>~bpo13+keel1.
Changelog distribution unstable in the git tree (what Salsa expects); the Keel archive build sets the target suite.
Older upstream on purpose (xsdata 25.7, brazilfiscalreport 1.1.0, requests-pkcs12 1.25, pygount 3.1.0): the reason is written in debian/README.source, and the version is the one that satisfies both trixie and the OCA manifest specifier.
Every package's dist-info name is checked against the name in the OCA manifest, because Odoo 18 checks importlib.metadata.version() and not the import name.

3. CI (Forgejo Actions, no Docker)

One workflow per repository, calling a shared workflow in deb/.forgejo (or copied from the template, if Forgejo's reusable workflows across repositories do not work on this instance; to be measured):

sbuild against a clean trixie chroot built with mmdebstrap in unshare mode (no root, no Docker, no schroot setup);
lintian --fail-on warning on the .changes, with overrides only when justified in the override file;
autopkgtest on the built .deb inside the same unshare backend;
reproducibility: build twice with the same SOURCE_DATE_EPOCH and compare the .deb digests (reprotest later, if cheap enough).

Needs a Forgejo runner registered for the deb organization, running on LXC with the host executor (no Docker), with sbuild mmdebstrap uidmap lintian autopkgtest git-buildpackage pristine-tar devscripts installed. Whether a runner already exists for the organization is not known from here.

4. Build and publication to staging

Builds for the archive run on the build host, in a scratch directory under /tmp, never in /turnkey/* or /srv/keel-apt, and never while a release runs.
bin/build-package in the apt tooling clones from KEEL_GIT_BASE, which can point at https://git.pop.coop/deb. One gap in it for these packages:
- it builds binary only (-b). A package meant for Debian should also have its source in the archive (Architectures: amd64 source already allows it).
Source control lives on git.pop.coop; built packages live only in the project archive. Nightly builds go to trixie-staging on archive.keellinux.org (bin/publish --staging, signed by the build host's staging key, then bin/keel-publish-mirror), and releases go to trixie on the same archive, signed by the maintainer. Nothing from this work is signed with the release key by an agent.
Nightly: the build host rebuilds every deb/* repository whose debian/master changed since the last run, and publishes to trixie-staging only what built, passed lintian and autopkgtest.
Promotion from trixie-staging to trixie only when an OCA 18.0 module needs the package and after testing on staging; releases point at a dated pool snapshot (decision 0012).

5. Tests beyond CI

Per package: install on a clean trixie machine from trixie-staging, import the module, then install the OCA 18.0 module that depends on it into an Odoo 18 test database. Results go in the package PR.

6. Conflicts to resolve before packaging (one issue each)

pycryptodome (payment_redsys imports Crypto): prefer an OCA patch to Cryptodome/pycryptodomex.
deepdiff<8 (l10n_es_aeat_sii_match) against trixie's 8.1.1: prefer an OCA patch lifting the cap, after testing with 8.1.1.
suds-py3 (delivery_gls_asm) file-conflicts with python3-suds: prefer an OCA manifest change to suds-community, after testing.
workalendar (l10n_br_resource), removed from Debian as abandoned: adopt it in Keel, or move the module to another library (for example holidays, already in trixie). Proposal in its own issue.

7. Order

Base (openupgradelib, pdf2image, pyzbar backport, pygount 3.1.0, odoo-test-helper, pyjon.utils, py3o.formats, py3o.template, pysftp, mpld3, bokeh last), then Brazil (12), Spain, the other localizations, then the verticals, as the map orders them. Contributions to Debian (pdf2image's ITP #1087742, the pyzbar backport, then xsdata, altcha, numpy-financial, requests-pkcs12, brazilcep, xmlsig, pygount) run in parallel, and every text sent to Debian is approved first.

Decisions needed

Forgejo runner for deb: which host, and who registers it.
Build host: install sbuild, mmdebstrap, uidmap, lintian, autopkgtest, git-buildpackage, pristine-tar (pbuilder is installed but has no base chroot).
Source packages in the archive (bin/build-package builds binary only today).
Where the per package PRs are reviewed and merged: on git.pop.coop (same rules: independent adversarial review, green CI, merge commit).

Scope: the 34 pure Python libraries the packaging map (handbook PR #23, `docs/odoo-python-packaging-map.md`) lists as missing from trixie, packaged the Debian Python Team way so they can later go to Debian. This issue proposes the infrastructure only; no package is started before it is accepted. Decision 0022 stays open: this work makes the `.deb` option measurable, it does not decide it. ## 1. Repository per source package - One repository per source package on `git.pop.coop/deb/<source>` (for example `deb/python-openupgradelib`, `deb/python-xsdata`), public. The binary is `python3-<name>`. - `git-buildpackage` layout, the same one the Debian Python Team uses on Salsa, so a repository can be pushed to Salsa unchanged: - branches `debian/master`, `upstream`, `pristine-tar`; upstream tags `upstream/<version>`, packaging tags `debian/<version>`; - `debian/gbp.conf` with `debian-branch = debian/master`, `pristine-tar = True`; - `debian/control`: `Maintainer: Marcos Mendez <mendez.foto@gmail.com>`, `Rules-Requires-Root: no`, `Build-Depends: dh-sequence-python3, pybuild-plugin-pyproject, python3-all, ...`, `Testsuite: autopkgtest-pkg-pybuild` when upstream has tests; - `debian/rules`: `dh $@ --buildsystem=pybuild`; - `debian/copyright` in full DEP-5, `debian/watch` (PyPI or GitHub tags), `debian/upstream/metadata`, `debian/salsa-ci.yml`, and `debian/README.source` whenever an older upstream is packaged on purpose. - The upstream tarball comes from PyPI (sdist) or a GitHub tag, fetched by `uscan` and checked against the hash PyPI publishes. PyPI is the source of the tarball, never an install path. - A template repository `deb/python-package-template` carries the skeleton above plus the CI workflow, so each new package starts from the same files. ## 2. Versions - Names are Debian's, never Keel's: source `python-<name>`, binary `python3-<name>`. Keel shows only in the Debian revision. - Not in Debian: `<upstream>-0+keel1`. It sorts below `-1`, so the Debian upload replaces it cleanly, and it carries the `+keelN` suffix the apt tooling already requires (BRIEF section 7), so `bin/build-package` needs no change. - Backport of something already in sid (pyzbar): `<sid version>~bpo13+keel1`. - Changelog distribution `unstable` in the git tree (what Salsa expects); the Keel archive build sets the target suite. - Older upstream on purpose (xsdata 25.7, brazilfiscalreport 1.1.0, requests-pkcs12 1.25, pygount 3.1.0): the reason is written in `debian/README.source`, and the version is the one that satisfies both trixie and the OCA manifest specifier. - Every package's `dist-info` name is checked against the name in the OCA manifest, because Odoo 18 checks `importlib.metadata.version()` and not the import name. ## 3. CI (Forgejo Actions, no Docker) One workflow per repository, calling a shared workflow in `deb/.forgejo` (or copied from the template, if Forgejo's reusable workflows across repositories do not work on this instance; to be measured): 1. `sbuild` against a clean trixie chroot built with `mmdebstrap` in unshare mode (no root, no Docker, no schroot setup); 2. `lintian --fail-on warning` on the `.changes`, with overrides only when justified in the override file; 3. `autopkgtest` on the built `.deb` inside the same unshare backend; 4. reproducibility: build twice with the same `SOURCE_DATE_EPOCH` and compare the `.deb` digests (`reprotest` later, if cheap enough). Needs a Forgejo runner registered for the `deb` organization, running on LXC with the host executor (no Docker), with `sbuild mmdebstrap uidmap lintian autopkgtest git-buildpackage pristine-tar devscripts` installed. Whether a runner already exists for the organization is not known from here. ## 4. Build and publication to staging - Builds for the archive run on the build host, in a scratch directory under `/tmp`, never in `/turnkey/*` or `/srv/keel-apt`, and never while a release runs. - `bin/build-package` in the apt tooling clones from `KEEL_GIT_BASE`, which can point at `https://git.pop.coop/deb`. One gap in it for these packages: - it builds binary only (`-b`). A package meant for Debian should also have its source in the archive (`Architectures: amd64 source` already allows it). - Source control lives on git.pop.coop; built packages live only in the project archive. Nightly builds go to `trixie-staging` on `archive.keellinux.org` (`bin/publish --staging`, signed by the build host's staging key, then `bin/keel-publish-mirror`), and releases go to `trixie` on the same archive, signed by the maintainer. Nothing from this work is signed with the release key by an agent. - Nightly: the build host rebuilds every `deb/*` repository whose `debian/master` changed since the last run, and publishes to `trixie-staging` only what built, passed lintian and autopkgtest. - Promotion from `trixie-staging` to `trixie` only when an OCA 18.0 module needs the package and after testing on staging; releases point at a dated pool snapshot (decision 0012). ## 5. Tests beyond CI Per package: install on a clean trixie machine from `trixie-staging`, import the module, then install the OCA 18.0 module that depends on it into an Odoo 18 test database. Results go in the package PR. ## 6. Conflicts to resolve before packaging (one issue each) - `pycryptodome` (`payment_redsys` imports `Crypto`): prefer an OCA patch to `Cryptodome`/`pycryptodomex`. - `deepdiff<8` (`l10n_es_aeat_sii_match`) against trixie's 8.1.1: prefer an OCA patch lifting the cap, after testing with 8.1.1. - `suds-py3` (`delivery_gls_asm`) file-conflicts with `python3-suds`: prefer an OCA manifest change to `suds-community`, after testing. - `workalendar` (`l10n_br_resource`), removed from Debian as abandoned: adopt it in Keel, or move the module to another library (for example `holidays`, already in trixie). Proposal in its own issue. ## 7. Order Base (openupgradelib, pdf2image, pyzbar backport, pygount 3.1.0, odoo-test-helper, pyjon.utils, py3o.formats, py3o.template, pysftp, mpld3, bokeh last), then Brazil (12), Spain, the other localizations, then the verticals, as the map orders them. Contributions to Debian (pdf2image's ITP #1087742, the pyzbar backport, then xsdata, altcha, numpy-financial, requests-pkcs12, brazilcep, xmlsig, pygount) run in parallel, and every text sent to Debian is approved first. ## Decisions needed 1. Forgejo runner for `deb`: which host, and who registers it. 2. Build host: install `sbuild`, `mmdebstrap`, `uidmap`, `lintian`, `autopkgtest`, `git-buildpackage`, `pristine-tar` (pbuilder is installed but has no base chroot). 3. Source packages in the archive (`bin/build-package` builds binary only today). 4. Where the per package PRs are reviewed and merged: on git.pop.coop (same rules: independent adversarial review, green CI, merge commit).

navigator commented

2026-09-30 01:57:46 -03:00

Author

Owner

Runner ready: keel-deb-runner (label keel-deb, host executor, no Docker) on the git-runner VM, scoped to this organization. sbuild in unshare mode against a clean trixie chroot built pyzbar 0.1.9-3 from sid with lintian and autopkgtest passing (31 tests). Decision 1 is done; the proposal still waits for approval before the first package.

Runner ready: `keel-deb-runner` (label `keel-deb`, host executor, no Docker) on the git-runner VM, scoped to this organization. sbuild in unshare mode against a clean trixie chroot built `pyzbar` 0.1.9-3 from sid with lintian and autopkgtest passing (31 tests). Decision 1 is done; the proposal still waits for approval before the first package.