Bug#996949: dh-python: Errors in python3 maintainer scripts caused by ordering of d.control fields

2021-10-21 Thread Stefano Rivera
A scan of unstable doesn't turn up any affected packages, phew.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Bug#996949: dh-python: Errors in python3 maintainer scripts caused by ordering of d.control fields

2021-10-21 Thread Stefano Rivera
Hi Neil (2021.10.21_02:25:00_-0700)
> After inspecting the locally built package against the package already
> in the archive and rolling back each change in turn, the only change
> which causes a failure is the change to reorder the fields in d.control.
> 
> With that identified, the only change in the resulting .deb binaries
> from that change is that the maintainer scripts call py3compile
> python3-envparse:amd64 instead of py3compile python3-envparse

Thanks for debugging that. Clearly fallout from the patch for bug
#991146.

> Policy requires that the ordering of *blocks* in d.control is
> significant (Source before Package) but Policy does not require any
> specific ordering of fields within the blocks. It appears that dh-python
> is reliant on what is only a convention - that Source and/or Package are
> the first fields in the relevant blocks of d.control.

Ack, I'll try to get that fixed ASAP.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Bug#996949: dh-python: Errors in python3 maintainer scripts caused by ordering of d.control fields

2021-10-21 Thread Neil Williams
Source: dh-python
Version: 5.20211016.1
Severity: important
X-Debbugs-Cc: codeh...@debian.org

Dear Maintainer,

The python-envparse source package had a patch from Debian Janitor which
moved the Source: and Package: fields in d.control to further down the
relevant block:

https://salsa.debian.org/python-team/packages/python-envparse/-/commit/9e543cc28d054301040e211033857f2a5e5d3265

The package which resulted then failed in autopkgtest and piuparts
stages of Salsa CI because it failed to install:

https://salsa.debian.org/python-team/packages/python-envparse/-/jobs/2100830

Setting up python3-envparse (0.2.0-3+salsaci) ...
dpkg-query: package 'python3-envparse' is not installed
Use dpkg --contents (= dpkg-deb --contents) to list archive files contents.
Traceback (most recent call last):
  File "/usr/bin/py3compile", line 319, in 
main()
  File "/usr/bin/py3compile", line 298, in main
compile(files, versions,
  File "/usr/bin/py3compile", line 183, in compile
for fn, versions_to_compile in filter_files(files, e_patterns, versions):
  File "/usr/bin/py3compile", line 128, in filter_files
for fpath in files:
  File "/usr/share/python3/debpython/files.py", line 71, in filter_public
for fn in files:
  File "/usr/share/python3/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of python3-envparse:amd64

After inspecting the locally built package against the package already
in the archive and rolling back each change in turn, the only change
which causes a failure is the change to reorder the fields in d.control.

With that identified, the only change in the resulting .deb binaries
from that change is that the maintainer scripts call py3compile
python3-envparse:amd64 instead of py3compile python3-envparse

The only way to fix the installation and allow any other apt/dpkg
installations to complete, is to delete the broken maintainer scripts
from /var/lib/dpkg/info/ or edit them to remove the :amd64 addition.
This is the only way to allow a fixed package to install.

The error is in the generated maintainer scripts, postinst and prerm,
that the call to py3compile uses the wrong package name:
python3-envparse:amd64 instead of just python3-envparse

Reverting only the change to the ordering of fields in d.control fixes
the problem:
https://salsa.debian.org/python-team/packages/python-envparse/-/commit/f664b41623ca6fc664b52076f48bf80e61802562

The history of this was a little more complex because of a parallel
problem with pristine-tar support in Salsa for which I have proposed a
a separate merge request.

I have set severity to Important because this was not an arbitrary
change to d.control. Debian Janitor appears to be applying this
change routinely. dh-python should not change behaviour simply
because a line in d.control moves from position 0 to position N.

The change in ordering looks like an artifact of how Janitor
writes out the control stanza. Nevertheless, the fact that
dh-python then generated a package which not only failed to
install but which then went on to prevent other installations
would warrant the Important severity.

Policy requires that the ordering of *blocks* in d.control is
significant (Source before Package) but Policy does not require any
specific ordering of fields within the blocks. It appears that dh-python
is reliant on what is only a convention - that Source and/or Package are
the first fields in the relevant blocks of d.control.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.14.0-1-amd64 (SMP w/2 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled