Hello,

Your binary package embeds a copy of the Python pexpect module. This
is violation of Debian Policy 4.13:

"Debian packages should not make use of these convenience copies
unless the included package is explicitly intended to be used in this
way. If the included code is already in the Debian archive in the
form of a library, the Debian packaging should ensure that binary
packages reference the libraries already in Debian and the
convenience copy is not used."

Please modify your package to use the system-wide module provided by
the python-pexpect package.

Ubanus,

Thanks for the report.

Btw, do you have some advice on how best to modify the package?

Any examples where this has been fixed in other packages with python-pexpect?

Thanks,
Mark

* Mark Purcell <msp@debian.org>, 2009-11-29, 16:26:

You should:

1. Assure that copy of pexpect.py bundled in the package is either
unmodified or the package does not rely on any non-standard behaviour.
(This doesn't seem to be the issue for hplip, it uses pexpect in a very
basic way.)

2. Check how the package imports pexpect and possibly fix the imports.
("import pexpect", "import pexpect as ...", "from pexpect import ..."
are OK.)

3. Add appropriate Depends: or Recommends: header(s).

4. Don't let the embedded pexpect.py be installed into binary packages
(either by fixing *.install files or debian/rules).

5. Last but not least, test the package thoroughly.

Hope that helps,

Jakub,

hplip ships pexpect from 2006, current system version in Debian is 2008, there is a bit of difference between the two.  But as you say hplip appears to use in a standard manner.

import pexpect in two places:

base/tui.py:import pexpect
base/utils.py:import pexpect

tui.py looks like:
# Std Lib
import sys
import re

# Local
from g import *
import pexpect
import utils

Do I need to move the "import pexpect" statement up to the Std Lib stanza or will it just look for the system version automatically?

done

So if I don't install the obsolete hplip pexpect.py the python will automatically pick up the system version with the standard import stanza above?

Thanks!

Mark

* Mark Purcell <msp@debian.org>, 2009-11-29, 21:22:

No, no need to move anything.

That's right.

Dear Debian User,

Use of our limited, volunteer supported resources is best served by not
keeping open inactive bugs any longer than desirable, especially in
cases where the package concerned is older than the current stable
Debian version and upstream support has been limited. Consequently, the
report is now being closed.

Regards,

Brian.

Control: reopen -1
Control: found -1 3.21.8+dfsg0-2

This is not very respectful of our users and social contract.

Users should be given the opportunity to reproduce old bugs before they
are summarily closed without any attempt at reproducing them. Old bugs
are extremely likely to still be present, them being open usually means
no-one bothered to look at and fix them, at least in my experience.

The social contract states that we should not hide bugs. Closing old
bugs without attempting to verify if they are fixed or giving users the
opportunity to do so is definitely hiding bugs.

https://www.debian.org/social_contract

When the bug is trivial to verify if it is still present or not,
you should at very least run the two commands needed to do that:

$ chronic apt source hplip
$ find -iwholename '*expect*'
./hplip-3.21.8+dfsg0/base/pexpect
./hplip-3.21.8+dfsg0/base/pexpect/__init__.py

Please also notify the security team of the embedded copy:

https://wiki.debian.org/EmbeddedCopies

Thank you for reopening the report. The security team appears to be
aware of the embedded copy.

https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies

Regards,

Brian.