Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

[Nikolaus Rath]

On Oct 14 2015, Piotr Ożarowski  wrote:
>> export PYBUILD_TEST_ARGS={dir}/tests
>
> should I do that by default in pybuild if
> * "test" or "tests" directory is detected
> * PYBUILD_TEST_ARGS is not set
> * nose or pytest test suite is used

Yes please!


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

[Piotr Ożarowski]

[Barry Warsaw, 2015-10-14]
> On Oct 14, 2015, at 01:26 PM, Piotr Ożarowski wrote:
> 
> >> export PYBUILD_TEST_ARGS={dir}/tests
> >
> >should I do that by default in pybuild if
> >* "test" or "tests" directory is detected
> >* PYBUILD_TEST_ARGS is not set
> >* nose or pytest test suite is used
> >
> >?
> 
> Maybe just on the first two conditions, only if it's documented, and if

does `{interpreter} setup.py test` or `{interpreter} -m unittest discover -v`
(always? usually?) take dir as parameter?

If not, then I'd keep it for nose/pytest only.

> there's an easy way to disable it for corner cases.

exporting PYBUILD_TEST_ARGS¹ (with or without options, i.e. it can
be empty) would be enough to disable it

[¹] AKA --test-args
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: pybuild: passing {dir}/tests to nose/pytest by default

[Piotr Ożarowski]

> Oh sorry, I think I misunderstood.  The conditions above are ANDed not ORed. 
> :)

ups, sorry. I wrote it as foo and bar and baz and later replaced "and"
with bullet point to make it... more readable, eh ;)
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

[Barry Warsaw]

On Oct 14, 2015, at 04:28 PM, Piotr Ożarowski wrote:

>[Barry Warsaw, 2015-10-14]
>> On Oct 14, 2015, at 01:26 PM, Piotr Ożarowski wrote:
>> 
>> >> export PYBUILD_TEST_ARGS={dir}/tests
>> >
>> >should I do that by default in pybuild if
>> >* "test" or "tests" directory is detected
>> >* PYBUILD_TEST_ARGS is not set
>> >* nose or pytest test suite is used
>> >
>> >?
>> 
>> Maybe just on the first two conditions, only if it's documented, and if
>
>does `{interpreter} setup.py test` or `{interpreter} -m unittest discover -v`
>(always? usually?) take dir as parameter?
>
>If not, then I'd keep it for nose/pytest only.

Oh sorry, I think I misunderstood.  The conditions above are ANDed not ORed. :)

Cheers,
-Barry

Re: errors pushing tags to git

[Sandro Tosi]

> Yep.  Again, I've seen this, but don't know the cause and don't think it
> actually has any negative effect.

it is because a new tag is being pushed, so the post-receive hook is
trying to get a diff of it, but it fails as.. there is no "previous"
state for that. it is harmless, but annoying to see the error, could
be fixed changing the hook to verify if the prevrev is all 0 and act
accordingly

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

disable the git summary email?

[Sandro Tosi]

dpmt-commit ml is already full of emails (in 4 days I have 500+ emails
there!) should we disable the git summary message? It doesnt give
additional useful information, and in cases like small fix + push it
would prevent to double the emails sent.

-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

RFS: twistar (Was: Request to join)

[Jan-Pascal van Best]

On 10/12/2015 11:57 AM, Piotr Ożarowski wrote:
> you're in, though. Welcome
>
> (and please note that we will use git-dpm, not any other git related
> tool so either use that or make sure it's compatible) 
Thanks for adding me. I've uploaded the twistar packaging to Alioth,
it's at
git+ssh://git.debian.org/git/python-modules/packages/twistar.git. I've
used the default git-dpm branch names (master, upstream and
pristine-tar). I noticed there is some discussion on this list on branch
names, but I've followed the now-official
https://wiki.debian.org/Python/GitPackaging.

The module is Python 2 only. Upstream doesn't support Python 3, and
since twisted (the major dependency of twistar) is Python 2-only in
Debian (AFAIK), it wouldn't make much sense anyway.

The package builds correctly with pbuilder in a clean sid chroot,
without lintian errors (some pedantic and experimental comments).

I'd appreciate if one of the more experienced developers from the team
would take a look at the package and I look forward to your comments,
and to working togethers to get this package and (later) the denyhosts
synchronisation server into Debian.

Cheers

Jan-Pascal

-

From the ITP:

* Package name: python-twistar
  Version : 1.3
  Upstream Author : Brian Muller 
* URL : http://findingscience.com/twistar/
* License : MIT, BSD-derived
  Programming Lang: Python
  Description : Python ORM library for the Twisted framework


Twistar is a Python implementation of the active record pattern (also
known as
an object-relational mapper or ORM) that uses the Twisted framework’s RDBMS
support to provide a non-blocking interface to relational databases.

Twistar is a dependency for denyhosts-server, see its ITP, bug #800630.

Test failures with pyfasta

[Andreas Tille]

Hi Brent,

I intend to package pyfasta for the Debian distribution.  I tried to also
run the unit tests:


$ LC_ALL=C python setup.py nosetests
running nosetests
running egg_info
writing pyfasta.egg-info/PKG-INFO
writing top-level names to pyfasta.egg-info/top_level.txt
writing dependency_links to pyfasta.egg-info/dependency_links.txt
writing entry points to pyfasta.egg-info/entry_points.txt
reading manifest file 'pyfasta.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'pyfasta.egg-info/SOURCES.txt'
FF..creating new files:
some.split.fasta
creating new files:
some.0.fasta
some.1.fasta
creating new files:
some.0
some.1
creating new files:
some.0.1Kmer.fasta
some.1.1Kmer.fasta
creating new files:
some.0.10Kmer.2Koverlap.fasta
some.1.10Kmer.2Koverlap.fasta
creating new files:
some.split.100Kmer.2Koverlap.fasta
...Getötet



The dots '.' come quite fast and than the output stops.  After several
minutes (>10min) the computer slows down all processes and finally the
kernel seems to kill the process (Getötet == killed).  Seems there is
some infinite loop somewhere or so.

Do you have any idea how to debug this issue or what information should
be provided to track down the issue?

Kind regards

   Andreas.

-- 
http://fam-tille.de

pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

[Piotr Ożarowski]

> export PYBUILD_TEST_ARGS={dir}/tests

should I do that by default in pybuild if
* "test" or "tests" directory is detected
* PYBUILD_TEST_ARGS is not set
* nose or pytest test suite is used

?
-- 
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl  www.griffith.cc   www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Python-pyvcf: Couldn't find index page for 'distribute' (maybe misspelled?)

[Andreas Tille]

Hi,

On Tue, Oct 13, 2015 at 11:42:57PM +0200, Piotr Ożarowski wrote:
> > Searching for distribute
> > Reading https://pypi.python.org/simple/distribute/
> > Download error on https://pypi.python.org/simple/distribute/: [Errno 111] 
> > Connection refused -- Some packages may not be found!
> > Couldn't find index page for 'distribute' (maybe misspelled?)
> 
> patch setup.py to use setuptools instead of distribute and add
> python{3,}-setuptools to Build-Depends

Thanks for the hint which was really helpful.  Since setup.py is also
triggering a test suite I recreated the test data from upstream Git
and moved the packaging from Debian Med SVN to Git to simplify fetching
the new source tarball for others:

   git://anonscm.debian.org/debian-med/python-pyvcf.git

While the build works fine now and the tests are running without any
error I would like to be able to trigger the tests for the installed
modules.  I wonder what I need to do rebuild what setup.py is creating
from

   test_suite='vcf.test.test_vcf.suite',

Kind regards

Andreas.

-- 
http://fam-tille.de

Re: pybuild: passing {dir}/tests to nose/pytest by default duplicated binary

[Barry Warsaw]

On Oct 14, 2015, at 01:26 PM, Piotr Ożarowski wrote:

>> export PYBUILD_TEST_ARGS={dir}/tests
>
>should I do that by default in pybuild if
>* "test" or "tests" directory is detected
>* PYBUILD_TEST_ARGS is not set
>* nose or pytest test suite is used
>
>?

Maybe just on the first two conditions, only if it's documented, and if
there's an easy way to disable it for corner cases.

Cheers,
-Barry

Re: [Python-modules-team] django-ajax-selects is marked for autoremoval from testing

[Brian May]

Hello,

Can somebody please explain this email? I know it says 2015-11-05, but
looks like it was sent today.

As far as I can tell version 1.3.6-4 is in testing (not 1.3.6-3 as per
message), it got into testing 5 days ago, and this version has closed the
bug.

Is this something I have to worry about?

Thanks

On Thu, 15 Oct 2015 at 15:39 Debian testing autoremoval watch <
nore...@release.debian.org> wrote:

> django-ajax-selects 1.3.6-3 is marked for autoremoval from testing on
> 2015-11-05
>
> It is affected by these RC bugs:
> 801208: django-ajax-selects: FTBFS: ImportError: No module named 'django'
>
>
> ___
> Python-modules-team mailing list
> python-modules-t...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
>

Re: [Python-modules-team] django-ajax-selects is marked for autoremoval from testing

[Brian May]

On Thu, 15 Oct 2015 at 15:50 Brian May 
wrote:

> As far as I can tell version 1.3.6-4 is in testing (not 1.3.6-3 as per
> message), it got into testing 5 days ago, and this version has closed the
> bug.
>

Actually, I may have misread that. Probably only got into testing today,
maybe not enough time for the autoremoval watch to have noticed yet.