Re: RFS: Pyspread 0.2.6-1

2014-03-11 Thread Vincent Cheng
On Sat, Mar 8, 2014 at 4:57 AM, Andreas Noteng andr...@noteng.no wrote:
 On 07. mars 2014 02:52, Vincent Cheng wrote:

 If there aren't any non-DFSG-compliant files in upstream's tarball
 (and I see nothing that would suggest that this file in particular is
 non-DFSG-compliant), please do not repack upstream's tarball; it's
 simply not necessary at all. You can simply remove this file on clean
 and regenerate it as you would normally do.

 No, the only issue is the non verifyable binary code in the script. If
 you're ok with uploading the original tarball that's fine by me. SVN
 updated.

If you can regenerate that file during the build process, I'd argue
that it doesn't qualify as non-verifyable binary code (given that
source is present and you do in fact regenerate the file). :)

 Looks ok, I haven't found any other issues other than the one above.

 The previous releases have been thoroughly checked by Jakub Wilk, so I think
 it should be OK. :-)


 Also, according to DEHS, there's a new upstream release that you may
 want to consider packaging.

 The newer tarball is a windows only change, so I'll wait for the next
 upstream release.

Ack. Built, signed, and uploaded; thanks for your contribution to Debian!

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CACZd_tBmkYdgBru5_4QZ+=Uu5MFz=F=v06uva8yauo0yb68...@mail.gmail.com



Growing file lists after python2.7 rebuild

2014-03-11 Thread Moritz Muehlenhoff
i,
(I realise this list is primarily on packaging Python modules, but since I got
no response from the Python maintainer, I'm trying it here)

I prepared a security update for python2.7 in stable-security fixing 
CVE-2013-4238
and CVE-2014-1912. But rebuilding the package caused changes in the file list 
which
are not obvious to me:

In python2.7-minimal:
+/usr/lib/python2.7/lib-dynload/_hashlib.so
+/usr/lib/python2.7/lib-dynload/_ssl.so

In python2.7:
+/usr/lib/python2.7/lib-dynload/_hashlib.so
+/usr/lib/python2.7/lib-dynload/_ssl.so

Does anyone have an idea what's going wrong? debian/rules has some commented
entries for lib-dynload/_bsddb.so, so this seems to be a generic problem?

This happened both for my local build and on the buildd. Source package and
build log are on http://people.debian.org/~jmm/  

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140311173017.ga17...@inutil.org



Re: Growing file lists after python2.7 rebuild

2014-03-11 Thread Jakub Wilk

* Moritz Muehlenhoff j...@debian.org, 2014-03-11, 18:30:
I prepared a security update for python2.7 in stable-security fixing 
CVE-2013-4238 and CVE-2014-1912. But rebuilding the package caused 
changes in the file list which are not obvious to me:


In python2.7-minimal:
+/usr/lib/python2.7/lib-dynload/_hashlib.so
+/usr/lib/python2.7/lib-dynload/_ssl.so

In python2.7:
+/usr/lib/python2.7/lib-dynload/_hashlib.so
+/usr/lib/python2.7/lib-dynload/_ssl.so


Unexpected migrations of these modules between python2.7 and 
python2.7-minimal have been observed in the past: #702005. Turns out 
that sweeping the problem under the carpet, instead of fixing it 
properly, wasn't the best strategy…


Does anyone have an idea what's going wrong? debian/rules has some 
commented entries for lib-dynload/_bsddb.so, so this seems to be a 
generic problem?


No idea yet, but I will look into it.

This happened both for my local build and on the buildd. Source package 
and build log are on http://people.debian.org/~jmm/


“You don't have permission to access 
/~jmm/python2.7_2.7.3-6+deb7u1_i386-20140305-1206.gz on this server.”


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140311182655.gb8...@jwilk.net



Re: Growing file lists after python2.7 rebuild

2014-03-11 Thread Moritz Mühlenhoff
On Tue, Mar 11, 2014 at 07:26:55PM +0100, Jakub Wilk wrote:
 * Moritz Muehlenhoff j...@debian.org, 2014-03-11, 18:30:
 I prepared a security update for python2.7 in stable-security fixing
 CVE-2013-4238 and CVE-2014-1912. But rebuilding the package caused changes
 in the file list which are not obvious to me:
 
 In python2.7-minimal:
 +/usr/lib/python2.7/lib-dynload/_hashlib.so
 +/usr/lib/python2.7/lib-dynload/_ssl.so
 
 In python2.7:
 +/usr/lib/python2.7/lib-dynload/_hashlib.so
 +/usr/lib/python2.7/lib-dynload/_ssl.so
 
 Unexpected migrations of these modules between python2.7 and
 python2.7-minimal have been observed in the past: #702005. Turns out that
 sweeping the problem under the carpet, instead of fixing it properly, wasn't
 the best strategy…
 
 Does anyone have an idea what's going wrong? debian/rules has some
 commented entries for lib-dynload/_bsddb.so, so this seems to be a generic
 problem?
 
 No idea yet, but I will look into it.

Thanks!
 
 This happened both for my local build and on the buildd. Source package
 and build log are on http://people.debian.org/~jmm/
 
 “You don't have permission to access
 /~jmm/python2.7_2.7.3-6+deb7u1_i386-20140305-1206.gz on this server.”

Doh, fixed.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140311190907.GA2960@pisco.westfalen.local



Re: Growing file lists after python2.7 rebuild

2014-03-11 Thread Jakub Wilk
[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:


* Vincent Lefevre vinc...@vinc17.net, 2013-03-01, 17:00:

Unpacking replacement python2.7 ...
dpkg: error processing /var/cache/apt/archives/python2.7_2.7.3-7_amd64.deb 
(--unpack):
trying to overwrite '/usr/lib/python2.7/lib-dynload/_hashlib.so', 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)/site.py \
$(shell cd $(d); for i in $(MIN_EXTS); do \
test -e $(scriptdir)/lib-dynload/$$i.so \
   echo $(scriptdir)/lib-dynload/$$i.so; \
  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.)


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.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140311234718.ga6...@jwilk.net



Re: Compiled C modules are not found by test suite (Was: Help needed for python-biopython which splits up modules into two packages per Python version)

2014-03-11 Thread Éric Araujo

Hello,

Le 05/03/2014 10:31, Andreas Tille a écrit :

I have noted another problem:  I worked a bit
on the tests and noticed that those tests that are including compiled C
code are failing.  Is there anything in addition I need to do to make
the C object code visible to the Python modules?


Can non-DD see the source code somewhere?

IIUC you have a Python package  and C extensions; when running the tests 
during the package build (or is it against the installed package?), the 
C extensions are not found.  One explanation for that could be that the 
C extensions are built in a “build” directory instead of inside the 
Python package, and thus aren’t readily importable.  If the build uses 
distutils/setuptools, there is an option to control that:


# file setup.cfg next to setup.py
[build_ext]
inplace = 1

Regards


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/531feea6.6040...@netwok.org



pybuild: where to put --test-pytest?

2014-03-11 Thread Nikolaus Rath
Hello,

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:

,
| #!/usr/bin/make -f
| # -*- makefile -*-
| 
| #export DH_VERBOSE=1
| export PYBUILD_NAME=dugong
| 
| %:
|   dh $@ --with python3,sphinxdoc --buildsystem=pybuild
| 
| override_dh_auto_build:
|   dh_auto_build
|   python3 setup.py build_sphinx
| 
| override_dh_auto_clean:
|   dh_auto_clean
|   rm -rf doc/html doc/doctrees
`

Where can I sneak in the --test-pytest option?


Thanks,
-Nikolaus

-- 
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 debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/8761nkvxyt@vostro.rath.org