Re: Test suite errors with Python3 (Was: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: ...))
On Sat, Aug 31, 2019 at 04:47:42PM -0400, Sandro Tosi wrote:
> burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
>
> is the file there?
No, that file does not exist.
$ grep -R /tmp/fixed.txt
burrito/tests/test_util.py:f = open('/tmp/fixed.txt','w')
burrito/tests/test_util.py:result['fixed_file'] =
ResultPath(Path='/tmp/fixed.txt')
burrito/tests/test_util.py:result['fixed_file'] =
ResultPath(Path='/tmp/fixed.txt')
The code snippet that should create the file is
...
#generate some stderr
print('I am stderr', file=stderr)
# Write the fixed file
f = open('/tmp/fixed.txt','w')
f.writelines(['I am fixed file'])
f.close()
...
I have no idea why it might fail.
Kind regards
Andreas.
> > ...
> > ==
> > ERROR: CLAppTester: Alternative TmpDir functions as expected
> > --
> > Traceback (most recent call last):
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 304, in __call__
> > result_paths)
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
> > line 769, in test_TmpDir
> > result = app()
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 308, in __call__
> > raise e1
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 299, in __call__
> > result_paths=result_paths)
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 104, in __init__
> > raise ApplicationError('Could not open %s' % value.Path)
> > burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> >
> > ==
> > ERROR: CLAppTester: TmpDir functions as expected w space in name
> > --
> > Traceback (most recent call last):
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 304, in __call__
> > result_paths)
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
> > line 797, in test_TmpDir_w_space
> > result = app()
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 308, in __call__
> > raise e1
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 299, in __call__
> > result_paths=result_paths)
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 104, in __init__
> > raise ApplicationError('Could not open %s' % value.Path)
> > burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
> >
> > ==
> > ERROR: CLAppTester: WorkingDir functions as expected
> > --
> > ...
> > ==
> > ERROR: CLAppTester: parameters turned on, no data, space in command
> > --
> > Traceback (most recent call last):
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 304, in __call__
> > result_paths)
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
> > line 330, in _handle_app_result_build_failure
> > raise ApplicationError("Error constructing CommandLineAppResult.")
> > burrito.util.ApplicationError: Error constructing CommandLineAppResult.
> >
> > During handling of the above exception, another exception occurred:
> >
> > Traceback (most recent call last):
> > File
> > "/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_uti
Re: updating mechanize - help concerning tests with pybuild
Dear Matthias Thanks, I interpret this a go ahead with the adoption. Thanks for your and the teams work. At all: anything you want to see before I upload the new version? Best Norbert On September 1, 2019 9:43:33 AM GMT+09:00, Matthias Klose wrote: >On 01.09.19 01:59, Norbert Preining wrote: >> Hi Raphael, >> >> @Matthias, please read on. >> >> On Sat, 31 Aug 2019, Raphael Hertzog wrote: >>> https://salsa.debian.org/python-team/modules/python-mechanize >> >> Thanks, that is perfect. I pushed my work there, changed control VCS, >> maintainer, and uploader. >> >> ATM I only put me into the uploaders. Please, those who are >interested, >> put yourself in there, thanks! >> Do we go through package salvaging? https://wiki.debian.org/PackageSalvaging >>> >>> I don't think it's required here. The bugs have been open for long >enough >>> without any activity. >> >> Hmmm... I don't feel confident simply uploading someone's else >package. >> Best would probably be if Matthias Klose, one of the current >Uploaders, >> agrees to that and uploads the current package thus passing over >> maintainership. >> >> Matthias? > >did you see my comment in #936270? -- PREINING Norbert http://www.preining.info Accelia Inc. + JAIST + TeX Live + Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: updating mechanize - help concerning tests with pybuild
On 01.09.19 01:59, Norbert Preining wrote: Hi Raphael, @Matthias, please read on. On Sat, 31 Aug 2019, Raphael Hertzog wrote: https://salsa.debian.org/python-team/modules/python-mechanize Thanks, that is perfect. I pushed my work there, changed control VCS, maintainer, and uploader. ATM I only put me into the uploaders. Please, those who are interested, put yourself in there, thanks! Do we go through package salvaging? https://wiki.debian.org/PackageSalvaging I don't think it's required here. The bugs have been open for long enough without any activity. Hmmm... I don't feel confident simply uploading someone's else package. Best would probably be if Matthias Klose, one of the current Uploaders, agrees to that and uploads the current package thus passing over maintainership. Matthias? did you see my comment in #936270?
Re: updating mechanize - help concerning tests with pybuild
Hi Raphael, @Matthias, please read on. On Sat, 31 Aug 2019, Raphael Hertzog wrote: > https://salsa.debian.org/python-team/modules/python-mechanize Thanks, that is perfect. I pushed my work there, changed control VCS, maintainer, and uploader. ATM I only put me into the uploaders. Please, those who are interested, put yourself in there, thanks! > > Do we go through package salvaging? > > https://wiki.debian.org/PackageSalvaging > > I don't think it's required here. The bugs have been open for long enough > without any activity. Hmmm... I don't feel confident simply uploading someone's else package. Best would probably be if Matthias Klose, one of the current Uploaders, agrees to that and uploads the current package thus passing over maintainership. Matthias? Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Test suite errors with Python3 (Was: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: ...))
Control: tags -1 help
On Sat, Aug 31, 2019 at 11:50:16AM +0200, Ondrej Novy wrote:
> > I see that python-all is still present in Build-Depends (line 9).
>
> yep, that's reason. pybulid detects python{,-all} in B-D and if they are
> present, it runs clean for Python 2.
Thanks for pointing this out - it just came in an unexpected sequence.
Unfortunately it turns out that some build time tests are failing with:
...
==
ERROR: CLAppTester: Alternative TmpDir functions as expected
--
Traceback (most recent call last):
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 304, in __call__
result_paths)
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 330, in _handle_app_result_build_failure
raise ApplicationError("Error constructing CommandLineAppResult.")
burrito.util.ApplicationError: Error constructing CommandLineAppResult.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
line 769, in test_TmpDir
result = app()
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 308, in __call__
raise e1
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 299, in __call__
result_paths=result_paths)
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 104, in __init__
raise ApplicationError('Could not open %s' % value.Path)
burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
==
ERROR: CLAppTester: TmpDir functions as expected w space in name
--
Traceback (most recent call last):
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 304, in __call__
result_paths)
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 330, in _handle_app_result_build_failure
raise ApplicationError("Error constructing CommandLineAppResult.")
burrito.util.ApplicationError: Error constructing CommandLineAppResult.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.py",
line 797, in test_TmpDir_w_space
result = app()
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 308, in __call__
raise e1
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 299, in __call__
result_paths=result_paths)
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 104, in __init__
raise ApplicationError('Could not open %s' % value.Path)
burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
==
ERROR: CLAppTester: WorkingDir functions as expected
--
...
==
ERROR: CLAppTester: parameters turned on, no data, space in command
--
Traceback (most recent call last):
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 304, in __call__
result_paths)
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 330, in _handle_app_result_build_failure
raise ApplicationError("Error constructing CommandLineAppResult.")
burrito.util.ApplicationError: Error constructing CommandLineAppResult.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/tests/test_util.
result = app()
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 3
raise e1
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 2
result_paths=result_paths)
File
"/build/python-burrito-0.9.1/.pybuild/cpython3_3.7_burrito/build/burrito/util.py",
line 1
raise ApplicationError('Could not open %s' % value.Path)
burrito.util.ApplicationError: Could not open "/tmp/fixed.txt"
--
Ran 116 tests in 1.323s
FAILED (errors=12)
E: pybuild pybuild:341: test: plugin distutils failed with: exit code=1: cd
/b
Re: updating mechanize - help concerning tests with pybuild
Hi, On Sun, 01 Sep 2019, Norbert Preining wrote: > Fine with me. If you could give me DPMT membership on salsa I can push > my current work there. I can't grant you the right to the whole group (I'm not an owner) but I created the repository and granted you the rights on this repository at least: https://salsa.debian.org/python-team/modules/python-mechanize Let me know if you need anything else. To get access to the group, you should follow the procedure described in this document: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > Do we go through package salvaging? > https://wiki.debian.org/PackageSalvaging I don't think it's required here. The bugs have been open for long enough without any activity. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: updating mechanize - help concerning tests with pybuild
Hi Raphael, On Sat, 31 Aug 2019, Raphael Hertzog wrote: > Thus I would suggest to go ahead and take over the package in the DPMT > team. Fine with me. If you could give me DPMT membership on salsa I can push my current work there. Do we go through package salvaging? https://wiki.debian.org/PackageSalvaging Best Norbert -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: updating mechanize - help concerning tests with pybuild
On Sat, Aug 31, 2019 at 07:10:43PM +0200, Raphael Hertzog wrote: > Looking at the status of the packages in the team, it's quite clear that > the team is MIA as a whole: > https://qa.debian.org/developer.php?email=pkg-zope-develop...@lists.alioth.debian.org > > The only recent upload is from TANIGUCHI Takaki > on zope.deprecation 4.4.0-1. It's also the only package > > Thus I would suggest to go ahead and take over the package in the DPMT > team. And many of those packages can be RMed. I checked packages from `grep-dctrl -FMaintainer pkg-zope`. These non-zope.* packages have revdeps: python-chameleon python-mechanize (while python-clientform can be dropped) python-transaction python-zc.buildout python-zconfig python-zdaemon python-zodb So these non-zope.* packages can be RMed: bobo sourcecodegen van.pydeb It's harder to check all revdeps of the zope.* packages as they depend on each other and some, but not all, have py3 subpackages, but these py2 subpackages can be dropped (I didn't check if they are the only subpackages): python-zope.authentication python-zope.cachedescriptors python-zope.component-persistentregistry python-zope.component-test python-zope.copy python-zope.dottedname python-zope.sendmail python-zope.sqlalchemy python-zope.testbrowser python-zope.traversing And these source packages can be RMed (overlaps with the list above, checked with dak): zope.authentication zope.browser zope.cachedescriptors zope.contenttype zope.copy zope.dottedname zope.i18n zope.publisher zope.sendmail zope.sqlalchemy zope.testbrowser zope.traversing This includes several Py3 subpackages. Hope this helps. -- WBR, wRAR signature.asc Description: PGP signature
Re: updating mechanize - help concerning tests with pybuild
Hello, On Sat, 31 Aug 2019, Norbert Preining wrote: > I would be interested in adopting mechanize if the current maintainers > / uploaders are fine with it. Or we put it into the python modules team > and I do the stuff there. All is fine for me. I would like to see the package in the python modules team as well. We have packages in Kali depending on this module and we also need the Python 3 version. Hence we also pinged the current maintainers here just one day before you: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912014#10 > How could be proceed here? Looking at the status of the packages in the team, it's quite clear that the team is MIA as a whole: https://qa.debian.org/developer.php?email=pkg-zope-develop...@lists.alioth.debian.org The only recent upload is from TANIGUCHI Takaki on zope.deprecation 4.4.0-1. It's also the only package Thus I would suggest to go ahead and take over the package in the DPMT team. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: updating mechanize - help concerning tests with pybuild
On Sat, 31 Aug 2019, Dmitry Shachnev wrote:
> http_proxy= no_proxy= dh_auto_test -- --system custom --test-args "cd
> {build_dir}; {interpreter} run_tests.py"
Cool, thanks a big lot
BTW, why isn't that mentioned anywhere in the pybuild docs ...
Thanks
Norbert
--
PREINING Norbert http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Webpage to track py2removal bugs & packages
On Sat, Aug 31, 2019 at 11:50:33AM -0400, Scott Kitterman wrote: > > > I definitely think it will be helpful. Thanks for putting it together. > > > It's the best thing I've seen yet for answering the question of what can > > > we try to kill off now. > > > > > > Please keep it updated. > > > > Please note though that all python modules with QA or DPMT in Maintainer > > and without revdeps are already fixed. > > I'm not sure how you checked that. reverse-depends and reverse-depends -b > I just now fixed pycxx which did have an > rdepend, but only one from the same source package. Indeed, though it has reverse build-deps anyway. > Depending on your methodology, there may be others. Yes, but I suspect not many of them. -- WBR, wRAR signature.asc Description: PGP signature
Re: updating mechanize - help concerning tests with pybuild
On Sat, Aug 31, 2019 at 06:57:23PM +0300, Dmitry Shachnev wrote:
> On Sun, Sep 01, 2019 at 12:34:02AM +0900, Norbert Preining wrote:
> > Now, the interesting thing are the error messages. One of them is
> > [...]
> > httperror_seek_wrapper: HTTP Error 403: request disallowed by robots.txt
>
> Maybe this happens because pybuild exports http_proxy='http://127.0.0.1:9/',
> and this breaks the local http server used in tests.
>
> If you explicitly set http_proxy to empty string then pybuild won't do it.
>
> > H? Why does it use the original file directly in mechanize.git???
>
> Apparently you need to explicitly cd to build directory. So try this:
>
> http_proxy= dh_auto_test -- --system custom --test-args "cd {build_dir};
> {interpreter} run_tests.py"
>
> With this command, only three tests are failing for me.
Ah, if you also add no_proxy= then all tests pass.
http_proxy= no_proxy= dh_auto_test -- --system custom --test-args "cd
{build_dir}; {interpreter} run_tests.py"
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Re: updating mechanize - help concerning tests with pybuild
On Sun, Sep 01, 2019 at 12:34:02AM +0900, Norbert Preining wrote:
> Now, the interesting thing are the error messages. One of them is
> [...]
> httperror_seek_wrapper: HTTP Error 403: request disallowed by robots.txt
Maybe this happens because pybuild exports http_proxy='http://127.0.0.1:9/',
and this breaks the local http server used in tests.
If you explicitly set http_proxy to empty string then pybuild won't do it.
> H? Why does it use the original file directly in mechanize.git???
Apparently you need to explicitly cd to build directory. So try this:
http_proxy= dh_auto_test -- --system custom --test-args "cd {build_dir};
{interpreter} run_tests.py"
With this command, only three tests are failing for me.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Re: updating mechanize - help concerning tests with pybuild
Dear Dmitry
thanks for your email!
On Sat, 31 Aug 2019, Dmitry Shachnev wrote:
> - Add run_tests.py and the tests themselves to debian/pybuild.testfiles,
> to make pybuild copy them to the build directory.
>
> - Add override_dh_auto_test target with a command like this:
> dh_auto_test -- --system custom --test-args "{interpreter} run_tests.py"
Ok, I have done this and added the necessary files. Interestingly, I
*still* get errors:
Testing manually in the root:
$ pwd
.../mechanize.git
$ ls
... examples mechanize test test-tools ...
$ python2.7 run_tests.py
...
--
Ran 303 tests in 6.048s
OK
Testing manually in the build directory
$ pwd
.../mechanize.git/.pybuild/cpython2_2.7_mechanize/build
$ ls
... examples mechanize test test-tools ...
$ python2.7 run_tests.py
...
--
Ran 303 tests in 5.960s
OK
Finally doing dpkg-buildpackage or whatever
debian/rules override_dh_auto_test-indep
make[1]: Entering directory '/home/norbert/Development/calibre/mechanize.git'
dh_auto_test -- --system custom --test-args "{interpreter} run_tests.py"
pybuild --test -i python{version} -p 2.7 --system custom --test-args
"{interpreter} run_tests.py"
I: pybuild base:217: python2.7 run_tests.py
.E...EEE.EEF.E.EEE.EE.EE..FF...
Now, the interesting thing are the error messages. One of them is
ERROR: test_mozilla_cookiejar (test.test_functional.CookieJarTests)
--
Traceback (most recent call last):
File
"/home/norbert/Development/calibre/mechanize.git/test/test_functional.py", line
684, in test_mozilla_cookiejar
self._test_cookiejar(make_cookiejar, commit)
File
"/home/norbert/Development/calibre/mechanize.git/test/test_functional.py", line
654, in _test_cookiejar
html = br.open(url).read()
File
"/home/norbert/Development/calibre/mechanize.git/mechanize/_mechanize.py", line
253, in open
return self._mech_open(url_or_request, data, timeout=timeout)
File
"/home/norbert/Development/calibre/mechanize.git/mechanize/_mechanize.py", line
309, in _mech_open
raise response
httperror_seek_wrapper: HTTP Error 403: request disallowed by robots.txt
H? Why does it use the original file directly in mechanize.git???
run_tests.py does more or less
this_dir = os.path.dirname(__file__)
sys.path.insert(0, os.path.join(this_dir, "test"))
sys.path.insert(0, os.path.join(this_dir, "test-tools"))
sys.path.insert(0, os.path.join(this_dir, "mechanize"))
so **why** does it use the test/test-tools/mechanize from the ROOT
instead of the python test build?
It seems something is messed up in the pybuild test setup?
If you want to take a look, here is the git repo with the current
status:
https://github.com/norbusan/debian-mechanize.git
Thanks a lot and all the best
Norbert
--
PREINING Norbert http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: Webpage to track py2removal bugs & packages
On Saturday, August 31, 2019 11:09:33 AM EDT Andrey Rahmatullin wrote: > On Sat, Aug 31, 2019 at 10:20:32AM -0400, Scott Kitterman wrote: > > I definitely think it will be helpful. Thanks for putting it together. > > It's the best thing I've seen yet for answering the question of what can > > we try to kill off now. > > > > Please keep it updated. > > Please note though that all python modules with QA or DPMT in Maintainer > and without revdeps are already fixed. I'm not sure how you checked that. I just now fixed pycxx which did have an rdepend, but only one from the same source package. Depending on your methodology, there may be others. Scott K
Re: Webpage to track py2removal bugs & packages
On Sat, Aug 31, 2019 at 10:20:32AM -0400, Scott Kitterman wrote: > I definitely think it will be helpful. Thanks for putting it together. It's > the best thing I've seen yet for answering the question of what can we try to > kill off now. > > Please keep it updated. Please note though that all python modules with QA or DPMT in Maintainer and without revdeps are already fixed. -- WBR, wRAR signature.asc Description: PGP signature
Re: Webpage to track py2removal bugs & packages
On Saturday, August 31, 2019 2:31:36 AM EDT Sandro Tosi wrote: > Hello, > i've prepared a small website, > http://sandrotosi.me/debian/py2removal/index.html, to keep track of > the bugs user-tagged `py2removal`. > > * i'm sure there are bugs > * it's pretty brutal html, but should provide useful information > * it tries to account for crufted binary packages > * it ignores the package if the py2removal bug is closed (that means > you can remove a pkg with rdeps and not be identified by this page) > * since py2removal bugs are against src pkg, the script gets the > binary package and work only on the ones depending on python2 packages > * it's sorted with packages with 0 or few r-deps at the top, which > ideally are packages "easy" to get py2 removed from > * there's a graph too, which gives a more visual representation of the > rdeps; it's currently at level=1 (ie only the target package + the > direct reverse-dependencies are shown), i'll consider expand it to > level=3/4 > * for now it's juts a single snapshot; if considered useful i'll to to > keep it updated regularly (but my laptop is not always on anyway) > > let me know if you consider it helpful and/or it should include more > information to make it more interesting. I definitely think it will be helpful. Thanks for putting it together. It's the best thing I've seen yet for answering the question of what can we try to kill off now. Please keep it updated. Scott K
dh-python and pylint
Hello, I am preparing the new spyder package. since the removal of pylint3 from the src:pylint. I need to remove the Build-Depends: pylint3. Now dh_python3 still produce a pylint3 dependency for the binary packages. It seems that thsi is hard coded here[0] Is it a bug of dh-python ? Cheers Frederic [0] https://salsa.debian.org/python-team/tools/dh-python/blob/master/pydist/cpython3_fallback#L2047
Re: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: Python2 removal in sid/bullseye)
Hi,
so 31. 8. 2019 v 10:06 odesílatel Dmitry Shachnev
napsal:
> I see that python-all is still present in Build-Depends (line 9).
>
yep, that's reason. pybulid detects python{,-all} in B-D and if they are
present, it runs clean for Python 2.
--
Best regards
Ondřej Nový
Re: updating mechanize - help concerning tests with pybuild
Hi Norbert,
Let me try answering your second question, about tests.
On Sat, Aug 31, 2019 at 11:33:54AM +0900, Norbert Preining wrote:
> Current mechanize needs to set up a special environment for the tests.
> There is a dedicated script
> run_tests.py
> that would do the trick. I tried to use the pybuild before tests feature
> to export PYTHONPATH, but that didn't work.
>
> Is there a way to run a specific script instead of the built-in tests of
> pybuild?
Something like this should do the trick:
- Add run_tests.py and the tests themselves to debian/pybuild.testfiles,
to make pybuild copy them to the build directory.
- Add override_dh_auto_test target with a command like this:
dh_auto_test -- --system custom --test-args "{interpreter} run_tests.py"
Then pybuild will take care of running the tests with all supported
interpreters, each one in its own directory, and cleaning up after that.
See pybuild(1) for details.
--
Dmitry Shachnev
signature.asc
Description: PGP signature
Re: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: Python2 removal in sid/bullseye)
Hi Andreas, On Sat, Aug 31, 2019 at 09:57:16AM +0200, Andreas Tille wrote: > Hi, > > I have removed the Python2 package from d/control and all python-* > Build-Depends in Git[1]. I see that python-all is still present in Build-Depends (line 9). -- Dmitry Shachnev signature.asc Description: PGP signature
Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: Python2 removal in sid/bullseye)
Hi,
I have removed the Python2 package from d/control and all python-*
Build-Depends in Git[1]. However, the build in a pbuilder chroot fails
with:
dh clean --with python3 --buildsystem=pybuild
dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python2.7 setup.py clean
Traceback (most recent call last):
File "setup.py", line 11, in
from setuptools import find_packages, setup
ImportError: No module named setuptools
E: pybuild pybuild:341: clean: plugin distutils failed with: exit code=1:
python2.7 setup.py clean
dh_auto_clean: pybuild --clean -i python{version} -p 2.7 returned exit code 13
make: *** [debian/rules:10: clean] Error 255
Any idea how I can stop pybuild from calling python2.7?
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/python-burrito
--
http://fam-tille.de
