Re: dh_auto_test versus nosetests3

[Piotr Ożarowski]

pybuild invokes tests from within build directory (for a very good reason)
You can patch the code to use f.e. env. var. that points to resources
directory or you can copy needed files to build directory with something like:

 export PYBUILD_BEFORE_TEST=cp -r {dir}/resources {build_dir}
 export PYBUILD_AFTER_TEST=rm -r {build_dir}/resources
-- 
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

dh_auto_test versus nosetests3

[u]

Hi!

I have a package where upstream provides tests.
These tests, when run with nosetests3, work correctly.

Currently, I build the package using (debian/rules):

 %:
   dh $@ --with python3 --buildsystem=pybuild


But some of the tests fail this way (see log below, for better readability).


Now, when I override dh_auto_test in debian/rules like so:

 override_dh_auto_test:
 nosetests3 --verbose --exe -w $(CURDIR)

The tests get executed without error but I have no real feedback about
their well-being (except when I check the build log) and obviously I get
a complaint that the package does not use tests anymore.

So what's best practice / recommendation here or what did I miss?

Thanks & cheers!
u.


Output build log (using pbuilder in a sid chroot):
--


I: pybuild base:184: cd
/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build; python3.5 -m nose test
..EE..
==
ERROR: load_strings() loads English by default
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File
"/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build/test/onionshare_strings_test.py",
line 33, in test_load_strings_defaults_to_english
strings.load_strings()
  File
"/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build/onionshare/strings.py",
line 40, in load_strings
for filename in os.listdir(locale_dir):
FileNotFoundError: [Errno 2] No such file or directory:
'/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build/resources/locale'

==
ERROR: load_strings() loads other languages in different locales
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 198, in runTest
self.test(*self.arg)
  File
"/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build/test/onionshare_strings_test.py",
line 40, in test_load_strings_loads_other_languages
strings.load_strings("fr")
  File
"/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build/onionshare/strings.py",
line 40, in load_strings
for filename in os.listdir(locale_dir):
FileNotFoundError: [Errno 2] No such file or directory:
'/build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build/resources/locale'

--
Ran 6 tests in 0.130s

FAILED (errors=2)
E: pybuild pybuild:276: test: plugin distutils failed with: exit code=1:
cd /build/onionshare-0.9/.pybuild/pythonX.Y_3.5/build; python3.5 -m nose
test
dh_auto_test: pybuild --test --test-nose -i python{version} -p 3.5
returned exit code 13

Bug#836841: ITP: pydl -- Library of IDL astronomy routines converted to Python

[Vincent Prat]

Package: wnpp
Owner: Vincent Prat 
Severity: wishlist
X-Debbugs-Cc: 
debian-de...@lists.debian.org,debian-as...@lists.debian.org,debian-python@lists.debian.org

* Package name: PyDL
  Version : 0.5.2
  Upstream Author : Benjamin Alan Weaver 
* URL : https://github.com/weaverba137/pydl
* License : BSD-3-Clause
  Programming Lang: Python
  Description :Library of IDL astronomy routines converted to Python

This package consists of Python replacements for functions that are part of
the IDL built-in library or part of astronomical IDL libraries.
The emphasis is on reproducing results of the astronomical library functions.
Only the bare minimum of IDL built-in functions are implemented to support this.

There are four astronomical libraries targeted:

* idlutils : a general suite of tools heavily used by SDSS.
* Goddard utilities : The IDL Astronomy User's Libary, maintained by Wayne 
Landsman and distributed with idlutils.
* idlspec2d : tools for working with SDSS, BOSS and eBOSS spectroscopic data.
* photoop : tools for working with SDSS imaging data.

This package is affiliated with the Astropy project.

It will maintained within the Debian Astronomy Working Group.

Best regards,

Vincent

Re: Issue on setup.py with imports

[Matthias Klose]

On 06.09.2016 09:36, IOhannes m zmölnig (Debian/GNU) wrote:
> 
> 
> On 2016-09-03 10:18, Marcos wrote:
>> I'm migrating Gufw [1] from python2 to python3 and honestly I'm stuck
>> with an error from the setup.py: Python module controller not found:
>>
>> costales@dev:~/Desktop/16.10$ sudo python3 setup.py install --prefix=/usr
>> ERROR: Python module controller not found
>> running install
>> running build
>> running build_py
>> running build_scripts
>> running build_i18n
>> intltool-update -p -g gufw
>> running build_icons
>> running build_help
>> running install_lib
>> running install_scripts
>> changing mode of /usr/bin/gufw to 755
>> changing mode of /usr/bin/gufw-pkexec to 755
>> running install_data
>> running install_egg_info
>> Removing /usr/lib/python3.5/site-packages/gufw-16.10.0-py3.5.egg-info
>> Writing /usr/lib/python3.5/site-packages/gufw-16.10.0-py3.5.egg-info
>> costales@dev:~/Desktop/16.10$
> 
> so the "error" is non-fatal and the installation proceeds.
> i fail to see the problem.

the path looks suspicious, it should be /usr/lib/python3/dist-packages

Re: Issue on setup.py with imports

[Debian/GNU]

On 2016-09-03 10:18, Marcos wrote:
> I'm migrating Gufw [1] from python2 to python3 and honestly I'm stuck
> with an error from the setup.py: Python module controller not found:
> 
> costales@dev:~/Desktop/16.10$ sudo python3 setup.py install --prefix=/usr
> ERROR: Python module controller not found
> running install
> running build
> running build_py
> running build_scripts
> running build_i18n
> intltool-update -p -g gufw
> running build_icons
> running build_help
> running install_lib
> running install_scripts
> changing mode of /usr/bin/gufw to 755
> changing mode of /usr/bin/gufw-pkexec to 755
> running install_data
> running install_egg_info
> Removing /usr/lib/python3.5/site-packages/gufw-16.10.0-py3.5.egg-info
> Writing /usr/lib/python3.5/site-packages/gufw-16.10.0-py3.5.egg-info
> costales@dev:~/Desktop/16.10$

so the "error" is non-fatal and the installation proceeds.
i fail to see the problem.

fgmasdr
IOhannes