Re: AttributeError: module 'socket' has no attribute 'timeout'
On 4/25/19 10:04 AM, Artem Golubev wrote: Hello, I’m using python3.5, python3.7 on Debian 9 stretch This is my code: [snip] When I execute my code I receive this error *** Traceback (most recent call last): File "/root/python/projects/test/socket.py", line 7, in sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) AttributeError: module 'socket' has no attribute 'AF_INET' Hi, the problem is you've named your file 'socket', and that precedes the python module 'socket' when importing. Try renaming it. Since your question is not specific to debian python packaging though, it would be probably better to ask elsewhere, e.g. https://stackoverflow.com/ Cheers
Re: pybuild and testing pytest plugins
On 1/14/19 1:36 PM, Piotr Ożarowski wrote: >> Conceptually I think it's more relevant to override dh_auto_test. To make >> sure pytest will register the plugin one may tweak the $PYTHONPATH. That's >> the approach I followed in pytest-flask, see [1]. > >> [1] >> https://salsa.debian.org/python-team/modules/pytest-flask/blob/debian/master/debian/rules > > while tests are run in build target (not my choice, I'd check installed files) > I strongly advise to *not* use source files (i.e. "PYTHONPATH=$(CURDIR)") > in dh_auto_test, especially if you build an extension. pybuild changes > directory for a reason. > > If you need some files from source directory during tests, please list > them in debian/pybuild.testfiles file and pybuild will copy them to > build directory (and remove after tests). See pybuild manpage for more info. > Aha, will try to do so for pytest-flask. Thanks for the input. :)
Re: pybuild and testing pytest plugins
On 1/13/19 9:23 PM, Scott Talbert wrote: When packaging a pytest plugin and wanting to run the plugin's unit tests during the build process, the plugin usually has to be installed before running the tests, otherwise pytest cannot find the plugin. This seems to require workarounds such as this [1]. Is there any way to avoid this with pybuild or is such a workaround really necessary? Thanks, Scott [1] https://salsa.debian.org/python-team/modules/pytest-xdist/blob/debian/master/debian/rules#L12 Hi! Conceptually I think it's more relevant to override dh_auto_test. To make sure pytest will register the plugin one may tweak the $PYTHONPATH. That's the approach I followed in pytest-flask, see [1]. Not sure if this is a workaround too though :) Cheers, Alex [1] https://salsa.debian.org/python-team/modules/pytest-flask/blob/debian/master/debian/rules
Bug#911563: ITP: pystemd - Cython-based wrapper on top of libsystemd
Package: wnpp Severity: wishlist Owner: Alexandros Afentoulis X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: pystemd Version : 0.5.0 Upstream Author : Alvaro Leiva * URL : https://github.com/facebookincubator/pystemd * License : BSD Programming Lang: Python Description : Cython-based wrapper on top of libsystemd pystemd is a thin Cython-based wrapper on top of libsystemd, focused on exposing the dbus API via sd-bus in an automated and easy to consume way. It allows talking to systemd over dbus from python, programmatically start/stop/restart/kill and verify services status from systemd point of view, avoiding executing "subprocess.Popen(['systemctl', ..." and then parsing the output to know the result. pystemd also includes a systemd-run equivalent as well as provides an interface to sd_notify. === The presence of the PATENTS file in pystemd troubled me a bit. I was not sure if it complies with DFSG. Digging through the debian-legal list, and considering similar cases [1] [2], I assume that this legal thing is not blocking packaging of pystemd. [1]: https://lists.debian.org/debian-legal/2014/10/msg00064.html [2]: https://lists.debian.org/debian-legal/2017/05/msg8.html
Request to join DPMT
Hello people, I am packaging pytest-flask [1], bug #816713, and I would like to maintain it within the DPMT. I've been in contact with Apollon Oikonomopoulos for sponsorship. I did read and agree with team's policy [2]. My salsa username is alexaf-guest. Thanks! [1] https://salsa.debian.org/alexaf-guest/pytest-flask [2] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst signature.asc Description: OpenPGP digital signature
Bug#897096: RFS: pytest-flask/0.10.0-1 [ITP]
Package: sponsorship-requests Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org Dear mentors, I am looking for a sponsor for my package "pytest-flask" * Package name: pytest-flask Version : 0.10.0-1 Upstream Author : Vital Kudzelka * URL : https://github.com/vitalk/pytest-flask * License : ΜΙΤ Section : python It builds those binary packages: python-pytest-flask - A set of pytest fixtures to test Flask extensions python-pytest-flask-doc - documentation for the pytest-flask Python library python3-pytest-flask - A set of pytest fixtures to test Flask extensions To access further information about this package, please visit the following URL: https://mentors.debian.net/package/pytest-flask Regards, Alexandros Afentoulis
Bug#896557: ITP: python-django-nocaptcha-recaptcha -- Google No CAPTCHA reCAPTCHA widget for Django forms
Package: wnpp Severity: wishlist Owner: Alexandros Afentoulis X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-django-nocaptcha-recaptcha Version : 0.0.20 Upstream Author : Imaginary Landscape * URL : https://github.com/ImaginaryLandscape/django-nocaptcha-recaptcha * License : BSD Programming Lang: Python Description : Google No CAPTCHA reCAPTCHA widget for Django forms This python module allows creating Django forms with Google's "No CAPTCHA" reCAPTCHA or reCAPTCHA version 2. This is the only available reCAPTCHA since Google switched off version 1 in March 2018. This package is not a dependency for others, its building dependencies are already satisfied and has no running dependencies to other python modules. I already have a working debian package, tested against oldstable and Django 1.8. I plan on git pushing the repository on salsa as soon as possible. I will need a sponsor to upload that package and I would certainly maintain it within a team if that's more appropriate.
Re: ITP #816713 , pytest stuck while dpkg building
Nice,cool, thank you Alexandros Afentoulis Στις 22/01/2018 09:20 μμ, ο Alexandros Afentoulis έγραψε: > Alexandros Afentoulis
Re: ITP #816713 , pytest stuck while dpkg building
On 01/22/2018 01:34 PM, Piotr Ożarowski wrote:
> [Alexandros Afentoulis, 2018-01-21]
>> This is the test, essentially two HTTP endpoints where a GET to the
>> first results in a GET to the second, as far as I can tell:
>
> pybuild (by default) sets http{,s}_proxy to http{,s}://127.0.0.1:9/
> in addition to setting easy_install's allow_hosts to None
>
> To disable this, try something like:
>
> override_dh_auto_test:
> http_proxy= https_proxy= dh_auto_test
>
Hi Piotr, thanks for the suggestion.
I did try overriding dh_auto_test like so:
> override_dh_auto_test:
> http_proxy= https_proxy= \
> PYBUILD_SYSTEM=custom PYBUILD_TEST_ARGS="{interpreter} -m pytest -v -s"
> dh_auto_test
with no difference. That particular test gets stuck.
As I mentioned in my previous email, the rest of the tests (also
including GET to HTTP endpoints) succeed so I guest there a specific
peculiarity with test_concurrent_requests_to_live_server and the nested
urlopen call.
ITP #816713 , pytest stuck while dpkg building
0t0 TCP > localhost:38524->localhost:50549 (ESTABLISHED) > ➜ localhost ~ lsof -p 15081 | grep TCP > python2.7 15081 ale 17u IPv4 990400 0t0 TCP localhost:50549 > (LISTEN) > python2.7 15081 ale 18u IPv4 987027 0t0 TCP > localhost:50549->localhost:38524 (ESTABLISHED) > python2.7 15081 ale 19u IPv4 987032 0t0 TCP > localhost:38528->localhost:50549 (ESTABLISHED) Stack trace points that both processes are waiting with 'sk_wait_data'. The Recv-Q counter troubles me a bit: > root@localhost:~# netstat -p | grep "Proto Rec\|50549" > Proto Recv-Q Send-Q Local Address Foreign Address State > PID/Program name > tcp 121 0 localhost:50549 localhost:38528 > ESTABLISHED - > tcp0 0 localhost:38528 localhost:50549 > ESTABLISHED 15081/python2.7 > tcp0 0 localhost:38524 localhost:50549 > ESTABLISHED 15061/python2.7 > tcp0 0 localhost:50549 localhost:38524 > ESTABLISHED 15081/python2.7 Does this mean that the listener has some bytes in the recv-q that have not been processed for some reason? Perhaps that's why the test never ends? I'm trying to understand which parameter of the dpkg environment results in this behavior. Is there some kind of restriction for the interprocess communication through TCP sockets? As far as I can tell 'USENETWORK' has nothing to do with this, since all connections are to localhost. Any insight would be appreciated. Of course bypassing the test with '-k-test_concurrent_requests_to_live_server' successfully builds the package. Thanks in advance, Alexandros [1] https://gitlab.com/alexaf/pytest-flask [2] https://github.com/pytest-dev/pytest-flask/blob/master/tests/test_live_server.py#L86
Re: /usr/bin/python2 in shebangs?
Στις 14 Δεκεμβρίου 2017 3:38:46 μ.μ. EET, ο/η "Piotr Ożarowski" έγραψε: >Hi, > >I plan to prepare new dh-python upload soon and hence a question about >a bit controversial change: should dh_python2 (as we discussed during >last DebConf's Python BoF) replace /usr/bin/python shebangs with >/usr/bin/python2? > >Please note that it's not about pointing /usr/bin/python to python3 - >this will NOT happen. It's about making it easier to those admins that >want to do that anyway (or removing /usr/bin/python from Debian >completely) >-- >GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 +1
