Re: Growing file lists after python2.7 rebuild

2014-03-13 Thread Moritz Mühlenhoff
On Wed, Mar 12, 2014 at 12:47:18AM +0100, Jakub Wilk wrote:
 [This is a copy of what I sent to #702005 (after unarchiving it), which
 didn't show up on bugs.d.o yet.]
 According to python2.7-minimal's README.Debian, the _ssl and _hashlib are
 supposed to be included in the -minimal package.
 python2.7-minimal_2.7.3-6_amd64.deb indeed includes them both, but on every
 other architecture they are shipped in python2.7.
 Worse, if you rebuild wheezy's src:python2.7 in a clean environment, the
 modules move to python2.7, likely leading to upgrade problem similar to that
 reported a while ago:


I'll contact the people doing archive rebuilds; file lists could be compared
for successful builds. 

There are several Java packages in Wheezy which have broken file lists after
a rebuild.

 * Vincent Lefevre, 2013-03-01, 17:00:
 Unpacking replacement python2.7 ...
 dpkg: error processing /var/cache/apt/archives/python2.7_2.7.3-7_amd64.deb 
 trying to overwrite '/usr/lib/python2.7/lib-dynload/', which is 
 also in package python2.7-minimal 2.7.3-6
 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
 I believe the bug lies in the following part of debian/rules:
   DH_COMPAT=2 dh_movefiles -p$(p_min) --sourcedir=$(d) \
   usr/bin/python$(VER) \
   usr/share/man/man1/python$(VER).1 \
   $(foreach i,$(MIN_MODS),$(scriptdir)/$(i).py) \
   $(foreach i,$(MIN_PACKAGES),$(scriptdir)/$(i)) \
   $(foreach i,$(MIN_ENCODINGS),$(scriptdir)/$(i)) \
   $(scriptdir)/config/Makefile \
   usr/include/$(PVER)/pyconfig.h \
   $(scriptdir)/ \
   $(shell cd $(d); for i in $(MIN_EXTS); do \
   test -e $(scriptdir)/lib-dynload/$$ \
  echo $(scriptdir)/lib-dynload/$$; \
 done; true)
 The culprit appears to be that make expands $(shell ... ) too early, when no
 *.so files exist yet.
 Replacing $(shell ... ) with $$( ... ), and then adding appropriate
 Breaks+Replaces should fix this bug. (I haven't tested the proposed fix in
 practice yet.)

Thanks a lot for your analysis. I'll make a test build tomorrow and follow up.
 It still don't understand why this bug didn't trigger for the amd64 package.
 Perhaps the build log could shed some light on it.

Unfortunately I don't have the build log for the deb7u1 upload, the amd64
version was the one I uploaded and I didn't save the log.


To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact

Re: pybuild: where to put --test-pytest?

2014-03-13 Thread Nikolaus Rath
Piotr Ożarowski writes:
 [Nikolaus Rath, 2014-03-12]
 I'm working on a package that uses pytest. Conventiently, pybuild seems
 to have a --test-pytest option -- but I'm completely at a loss where to
 put it.
 Currently my rules file looks like this:

 you can add this line in debian/rules:


Thanks, this seems to work (documenting this in the pybuild manpage
would be nice).

However, now I have a different problem:

It seems that pybuild tries to find the tests in some temporary

$ debuild -us -uc
make[1]: Leaving directory `ROOT/python-dugong-2.1'
   dh_auto_test -O--buildsystem=pybuild
I: pybuild base:170: cd ROOT/python-dugong-2.1/.pybuild/pythonX.Y_3.4/build; 
python3.4 -m pytest 
= test session starts ==
platform linux -- Python 3.4.0 -- pytest-2.5.1
collected 0 items

This is presumably because the tests are in ROOT/test, not in
ROOT/python-dugong-2.1/.pybuild/pythonX.Y_3.4/build. The latter seems to
contain only the dugong module itself.

Who/what is responsible for copying the tests in this directory? 


Encrypted emails preferred.
PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C

 »Time flies like an arrow, fruit flies like a Banana.«

To UNSUBSCRIBE, email to
with a subject of unsubscribe. Trouble? Contact