Re: Ported Python Policy to Sphinx

2021-02-26 Thread Dmitry Shachnev
On Fri, Feb 26, 2021 at 06:09:50PM +, Stefano Rivera wrote:
> Hi Dmitry (2021.02.26_08:31:11_+)
> > You can use :samp:`python3.{Y}`. See:
>
> Thanks for the hint. Glad I asked :)
>
> Switched to that, and re-rendered.

Small addition (sorry that I did not mention it earlier): when referring
to files you can also use :file:. The difference is only semantic, I think
it will produce the same result:

https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-file

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Ported Python Policy to Sphinx

2021-02-26 Thread Dmitry Shachnev
Hi Stefano!

On Thu, Feb 25, 2021 at 10:58:41PM +, Stefano Rivera wrote:
> Hacking on the docbook Python Policy is no fun.
>
> I ported the current version to sphinx.
>
> MR: https://salsa.debian.org/cpython-team/python3-defaults/-/merge_requests/10
>
> Render: https://people.debian.org/~stefanor/python-policy-sphinx/
>
> I'd appreciate it if anyone who has the time would give it a proof-read.
>
> There are definitely sections that could use garbage collection and/or
> re-writes for clarity, but the intention of this MR is to just port to
> Sphinx without content changes.
>
> There's no direct equivalent in RST for
> python3.Y, the best is
> ``python3.Y``.

You can use :samp:`python3.{Y}`. See:

https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#role-samp

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Python 2 support for Bullseye

2020-10-16 Thread Dmitry Shachnev
Hi Moritz!

On Fri, Oct 16, 2020 at 08:04:56PM +0200, Moritz Mühlenhoff wrote:
> There will be few core packages build-depending on Python 2 (for tests
> or building) which won't be ready for Python 3 for Bullseye (Chromium,
> qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very
> small set of support packages like setuptools/jinja) to build and
> run their tests.

Small correction: s/qtwebkit/qtwebengine/.

QtWebEngine bundles Chromium whose upstream is actively working on
Python 3 port [1]. Most probably it won't be ready in time for Bullseye,
but for Bookworm it should be ready (or rather, Qt WebEngine 6 will
use Python 3, and we will remove Qt WebEngine 5).

There are also patches from the FreeBSD maintainer [2], but they are huge
(2200 lines in total) and the author reports that they cause some JS errors,
so I would better not apply them and wait for an official port.

Qt WebEngine in Debian is not supported from security point of view anyway,
so I think it should be fine to let it use Python 2 in Bullseye.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1112471
[2]: https://mail.kde.org/pipermail/distributions/2020-September/000860.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: python3- preffix

2020-10-04 Thread Dmitry Shachnev
Hi Fioddor!

On Sun, Oct 04, 2020 at 06:24:30PM +0200, Fioddor Superconcentrado wrote:
> Thank you Andrey.
>
> In this case it's a module and therefore needs the prefix.
> Ok. renamed the source package with python-.
>
> I get following (translated back to english):
> dpkg-buildpackage: information: system architecture amd64
> dpkg-source:  failure: source package has 2 conflicting values:
> "python-my-package" and "python3-my-package"

You need to change both debian/control and debian/changelog.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Merging the PAPT and the DMPT

2020-09-20 Thread Dmitry Shachnev
On Sat, Sep 19, 2020 at 06:24:06PM -0600, Nicholas D Steeves wrote:
> Are there plans to do this team-wide (for team email in Maintainer) in
> one fell swoop, or will this be a per-maintainer task?

I know Ondrej has the tooling to do mass updates, so I hope he will do it :)

Of course this is only about updating fields in git, there is no need to
upload to archive just because of metadata change.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Merging the PAPT and the DMPT

2020-09-14 Thread Dmitry Shachnev
Hi Ondrej!

On Mon, Sep 14, 2020 at 09:59:00AM +0200, Ondrej Novy wrote:
> Hi,
>
> I prepared scripts for:
>
>- cloning ACLs from modules+applications subgroups to newly created
>packages subgroup
>- transferring all project from modules+applications to packages subgroup
>- tested on one project:
>https://salsa.debian.org/python-team/packages/alembic
>
> It looks like old web URLs works just fine:
> https://salsa.debian.org/python-team/modules/alembic

I think it's better to update Vcs fields in all packages to point to the
new location, not one that redirects.

Probably also update Maintainer/Uploader fields with the new team name/email.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Help with new sphinx version needed (Was: Bug#966983: Most likely fixed in sphinx (2.4.3-5))

2020-08-11 Thread Dmitry Shachnev
Control: reassign -1 python3-sphinx 3.2.0-1
Control: affects -1 + src:python-skbio

Hi Andreas!

On Tue, Aug 11, 2020 at 02:26:40PM +0200, Andreas Tille wrote:
> I need some help with a sphinx error for python-skbio:
>
> > > Extension error:
> > > Handler  for event
> > > 'autodoc-process-docstring' threw an exception (exception: module,
> > > class, method, function, traceback, frame, or code object was expected,
> > > got method_descriptor)
>
> Any idea how to fix this?

This is https://github.com/sphinx-doc/sphinx/issues/8074.

Upstream promises to make a new release within a week. If you don't mind,
I will wait for that and then upload the new release to Debian.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: embedded-javascript-library usr/share/doc/python3-lmfit/html/_static/language_data.js please use sphinx

2020-08-04 Thread Dmitry Shachnev
Hi,

On Mon, Aug 03, 2020 at 03:04:38PM +, PICCA Frederic-Emmanuel wrote:
> Hello, I am working on the lmfit-py package
>
> lintian complain about this
>
> https://salsa.debian.org/science-team/lmfit-py/-/jobs/909498
>
> I use sphinx, so my question is: do you know how to fix this issue

I have just uploaded sphinx 2.4.3-5 where dh_sphinxdoc gained the ability
to symlink language_data.js (for English), so this should be fixed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: The python command in Debian

2020-07-18 Thread Dmitry Shachnev
On Sat, Jul 18, 2020 at 10:35:03AM +0200, deba...@debian.org wrote:
> > Yup, Arch does. From the wiki: https://wiki.archlinux.org/index.php/Python
> >
> > Any program requiring Python 2 needs to point to /usr/bin/python2, instead 
> > of
> > /usr/bin/python, which points to Python 3. 
>
> I wonder, what they do, if there will be a Python 4...

AFAIK Python 4 is not planned even in long term (e.g. because that would break
a lot of programs that rely on sys.version_info.major):

https://www.python.org/dev/peps/pep-0602/

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Python3 -dbg packages

2020-07-07 Thread Dmitry Shachnev
Hi Matthias!

On Mon, Jul 06, 2020 at 08:33:39PM +0200, Matthias Klose wrote:
> Python 3.8 upstream now has a common ABI for normal and debug extension
> builds, so it is technically possible to load a debug extension in
> the normal interpreter, or to load a normal extension in the debug
> interpreter.

Packages from the PyQt5 stack (pyqt5, pyqt5chart, pyqt5webengine, qscintilla2)
have recently started to use PEP 384 limited ABI (the built files are named
*.abi3.so). However, when a debug interpreter is used for build, the build
system disables this feature and builds a normal *.cpython-38d-*.so file:

https://riverbankcomputing.com/hg/sip/file/6169324910f8/sipbuild/buildable.py#l60

Because of this, I decided to still build -dbg versions for these packages.

Do you know how much the -dbg interpreter is compatible with *.abi3.so files?
I just checked, and apparently it can import them, but maybe there is some
benefit in keeping the normal debug versions too?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: python-policy source

2020-07-05 Thread Dmitry Shachnev
Hi Geert!

On Sun, Jul 05, 2020 at 07:05:28PM +0200, Geert Stappers wrote:
> Hi,
>
> Where to find the source of python-policy?

I believe it is here:

https://salsa.debian.org/cpython-team/python3-defaults/-/blob/master/debian/python-policy.dbk

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Help fixing #959558 (case: FTBFS: AttributeError: 'tuple' object has no attribute 'lstrip' with sphinx 2.4)

2020-05-27 Thread Dmitry Shachnev
Hi all!

On Tue, May 26, 2020 at 05:06:16PM -0400, Scott Talbert wrote:
> On Tue, 26 May 2020, Thomas Goirand wrote:
> > Hi there!
> >
> > Does any of you knows how to fix this bug?
> > https://bugs.debian.org/959558
> >
> > Almost all of OpenStack can removed from Bullseye if not fixed in time,
> > so I tried to fix, but couldn't.
>
> It looks like it's a bug in sphinx.  I tried sphinx 3.0.4 and it seems to
> work fine.  2.4.4 still has the problem, however.
>
> Dmitry, do you plan to update to sphinx 3.0.x soon?

3.x won't happen soon, but I will fix this bug in the next Sphinx 2.4 upload.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: [felix+deb...@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

2020-04-19 Thread Dmitry Shachnev
Hi all,

On Sun, Apr 19, 2020 at 09:50:34PM +0200, Thomas Goirand wrote:
> Now the package is 2.7 MB, out of which the extracted library is only
> 380 KB. Now, the extracted documentation is 3.5 MB and contains 3 MB of
> fonts, like fontawesome and lato, which are already part of Debian.
>
> If everyone was doing like you, installing a small python app would
> download gigabytes of packages! :)
>
> Please:
> 1/ Push the docs into a separate package that you could call
> python-sphinx-autoapi-doc.
> 2/ Remove the embedded fonts fonts from that -doc package, and create
> symlinks to the appropriate files in the fonts-font-awesome and
> fonts-lato package.

Better not symlink anything manually but use dh_sphinxdoc which will do it
automatically:

- Replace “--with python3” with “--with python3,sphinxdoc” in debian/rules.
- Make python-sphinx-autoapi-doc depend on ${sphinxdoc:Depends}.
- Drop Suggests: libjs-jquery, libjs-underscore as they will be in Depends.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: py2removal: drop python-pytest by not running tests for python2 packages

2020-04-13 Thread Dmitry Shachnev
On Sun, Apr 12, 2020 at 11:05:13PM -0400, Scott Kitterman wrote:
> On Sunday, April 12, 2020 9:56:01 PM EDT Sandro Tosi wrote:
> > Hello,
> > python-pytest is blocking 18 packages from removal, most of them would
> > be leaves once python-pytest is gone.
> >
> > so i was playing with the idea of tackling python-pytest removal by
> > updating all its rdeps and not run unittests for the python2 binary
> > (so dropping pytest and the other b-d* only used for tests).
> >
> > I know it's suboptimal (some python2 packages can still see updates
> > until we're ready to drop them and running tests can still have
> > value), but i think the cost/benefit ratio points towards removing
> > python-pytest soon rather than wait.
> >
> > There are only 25 packages that would need updating, and most of them
> > are in DPMT/PAPT.
>
> Go for it.

+1 from me too.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: PEP-517/PEP-518 Support In Debian

2020-04-13 Thread Dmitry Shachnev
Hi Scott!

On Sun, Apr 12, 2020 at 06:31:57PM -0400, Scott Kitterman wrote:
> This being roughly the mid-point in the development cycle, I thought it might 
> be good to see where we are in terms of future Python packaging developments.
>
> As I understand it, PEP-517 and PEP-518 are 'the future'.
>
> I took a look at the presence of pyproject.toml files in the Debian archive.  
> There are currently 99 packages.  Of those, only 28 specify a 
> 'build-backend', 
> which is required by 517/518 to be useful for building a package.
>
> 25 specify: build-backend = "setuptools.build_meta" (including setuptools)
> 3 specify: build-backend = "flit_core.buildapi" (including flit)

pyqt5 and pyqt5webengine specify: build-backend = "sipbuild.api".

> If build-backend is not specified, the build system has to fall back to 
> setup.py.
>
> I've recently package flit (just arrived in Testing) and written a flit 
> plugin 
> for pybuild that's pending review for merging[1].  I also packaged pep517 for 
> our pip package, so that's available to support future Debian tool 
> development 
> in this area.
>
> For the moment, I guess we are in reasonable shape, but it might be useful to 
> have a pybuild plugin to use PEP517/setuptools.build_meta in lieu of setup.py 
> with setuptools/distutils when available.  In the future, this will be the 
> primary API and the sooner we start to use it, the better.

One issue that comes to mind: how will we specify the install location in a
way that will work with any backend? In other words, what is the replacement
for distutils' --install-layout=deb?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Reviving #debian-python-changes channel

2020-04-07 Thread Dmitry Shachnev
Hi!

salsabot is dead for two months now, however we can replace it with KGB
which is alive.

I am attaching a script that Lisandro Damián Nicanor Pérez Meyer kindly
shared with me, he used it to revive the #debian-qt-notifications channel.

I have already replaced qt-kde-team/qt with python-team/modules.

Can some admin please run it? (You need to get an API token and put a
SALSA_TOKEN=... line to ~/.devscripts first.)

python-team/applications is not affected because it seems to already use KGB.

--
Dmitry Shachnev


salsa.sh
Description: Bourne shell script


signature.asc
Description: PGP signature


Re: py2removal: proposal to increase apps popcon limit

2020-03-31 Thread Dmitry Shachnev
On Mon, Mar 30, 2020 at 11:01:49PM -0400, Sandro Tosi wrote:
> Hello,
> as part of the py2removal process, we're not raising the bug priority
> to serious if it's associated with an application and popcon is bigger
> than 300
>
> There are currently:
>
> * 38 apps that are leaf packages and popcon > 300;
> ** 13 out of 38 have popcon < 600
> ** 20 out of 38 have popcon < 1000
>
> I propose to raise the popcon threshold to 1000.
>
> What are your thoughts? I will move forward with this change in 3 days
> if i dont hear any opposition.

I think it makes sense.

Maybe you can paste the list of 20 affected apps, though?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: About itsdangerous

2020-02-27 Thread Dmitry Shachnev
Hi Julien!

On Thu, Feb 27, 2020 at 05:02:32PM +0100, Julien Puydt wrote:
> Le jeudi 27 février 2020 à 19:14 +0500, Andrey Rahmatullin a écrit :
>
> > https://alioth-archive.debian.org/git/collab-maint/python-itsdangerous.git.tar.xz
> > 
>
> I must be going through a very bad day, but trying to follow 
> https://wiki.debian.org/Salsa/AliothMigration#By_hand doesn't work ;
> the two git checkout commands (both pristine-tar and upstream) give:
> error: pathspec 'pristine-tar' did not match any file(s) known to git
>
> Are we sure the original git repository had the correct structure
> anyway?

Looking at that repo, it did not have the correct structure, but I think
it makes sense to preserve its history anyway. I would do the following
with branches:

debian/unstable — rename to debian/master
master-dfsg — rename to upstream

Also update branch names in debian/gbp.conf accordingly. And gbp should create
a pristine-tar branch when you update to a newer release.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: pytest and core dump

2020-02-09 Thread Dmitry Shachnev
Hi,

On Sun, Feb 09, 2020 at 03:31:39PM +, PICCA Frederic-Emmanuel wrote:
> Hello, I am working on the vitables package.
>
> during the build I get this error message [1]
>
> = test session starts 
> ==
> 1567 platform linux -- Python 3.7.6, pytest-4.6.9, py-1.8.1, pluggy-0.13.0
> 1568 rootdir: /builds/science-team/vitables/debian/output/vitables-3.0.2
> 1569 collected 54 items
> 1570 tests/test_filenode.py Aborted (core dumped)
> 1571 E: pybuild pybuild:341: test: plugin distutils failed with: e
>
> This core dump is generated in the salsa-ci runners.
>
> I would like a backtrace of this core dump.
>
> so my question is how can we instrument the d/rules in order to print a
> stack trace during the build in case of core dump.

To get the Python traceback, you can export PYTHONFAULTHANDLER=1.

To get the C stack trace, you need to run the Python interpreter in a debugger
like gdb. Better to do this locally of course, not in the CI.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: pyqt5 and entrypoint

2020-02-02 Thread Dmitry Shachnev
Hi,

On Sun, Feb 02, 2020 at 08:21:51PM +, PICCA Frederic-Emmanuel wrote:
> Hello,
>
> We are working on the next pyfai package.
>
> This new version use entry_points like this
> [...]
>
> But once installed, we can not start the gui application.
> [...]
>
> pkg_resources.DistributionNotFound: The 'PyQt5' distribution was not
> found and is required by the application
>
> indeed python3-pyqt5 was installed

Please make sure you have python3-pyqt5 ≥ 5.12+dfsg-1.

If that is the case and you are still getting an error, please check
the output of the following commands in the Python console:

>>> import pkg_resources
>>> pkg_resources.get_distribution('PyQt5')

For me it prints “PyQt5 5.14.1 (/usr/lib/python3/dist-packages)”.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Update python-sip, sip4 request

2020-02-01 Thread Dmitry Shachnev
Hi Matthijs!

On Fri, Jan 31, 2020 at 10:22:33PM +, Matthijs van der Burgh wrote:
> Hello,
>
> In the ROS community, a lot of developers use the 'python-orocos-kdl'
> library, https://github.com/orocos/orocos_kinematics_dynamics, which
> generates its python bindings with SIP. The versions of SIP between
> 4.16.7 and 4.19.20 contain bugs which make the 'python-orocos-kdl' hard
> to use.
>
> I worked with the developer of SIP to fix these bugs. These are fixed in
> the new release 4.19.21, as can be seen on
> https://www.riverbankcomputing.com/hg/sip.

I have just uploaded sip 4.19.21 to unstable.

> I would like to ask you to update the python-sip package on all ubuntu
> release 16.04 and newer to 4.19.21. This would make it possible to generate
> a new version of 'python-orocos-kdl', which would help a lot of developers.

This is Debian mailing list, not Ubuntu's :-)

However my upload will be synced into Ubuntu and available in 20.04 LTS.

If you want a fix in older Ubuntu releases, please file a bug against sip4
package on Launchpad, ideally following this template:

https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template

The whole sip 4.19.21 won't be backported, but it is possible to cherry-pick
individual fixes.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Understanding pybuild

2019-12-20 Thread Dmitry Shachnev
On Fri, Dec 20, 2019 at 08:19:41AM +0100, Ole Streicher wrote:
> That would formalize it a bit, but still does not solve the underlying
> problem: it requires that I maintain the list of these files manually,
> while upstream already does this (by adding them to the list of data
> files).
>
> And also, the built time tests are with pybuild not done with the files
> (anc compilations) that are finally installed, but the installed files
> (especially Python extensions) are created again from scratch, doubling
> the compile time and introducing another difficile source of error.

I think pybuild just calls setup.py build and then setup.py install.

So it is a question to upstream build system, why are files recompiled during
install.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Understanding pybuild

2019-12-19 Thread Dmitry Shachnev
Hi Ole!

On Thu, Dec 19, 2019 at 01:09:40PM +0100, Ole Streicher wrote:
> Hi,
>
> I am currently updating scikit-image (skimage) to its newest version,
> and I have some difficulties to understand how pybuild works (for
> setup.py packages):
>
> 1. first, dh_auto_build calls "python3.X setup.py build" to create the
> packages (Python files and compiled extensions) in
> ..pybuild/cpython3_3.X/. This however does not include the copying of any
> data files.
>
> 2. dh_auto_test then tries runs the tests in .pybuild. If the test need
> data files installed, they must be copied manually (right?).

You can use debian/pybuild.testfiles to copy the test files. See pybuild(1)
for details.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: RFS: python-traits

2019-12-04 Thread Dmitry Shachnev
On Wed, Dec 04, 2019 at 09:23:56AM -0500, Scott Talbert wrote:
> > Please fix that and I will sponsor this.
>
> Done.

Uploaded!

> > Also are you interested in python-traitsui package? It would be nice to
> > get it ported to Python 3 or removed.
>
> Yes, I was planning to work on that package next.

Thanks! Feel free to ping me directly about it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: RFS: python-traits

2019-12-04 Thread Dmitry Shachnev
Hi Scott!

On Wed, Dec 04, 2019 at 12:07:36AM -0500, Scott Talbert wrote:
> Hi,
>
> Can someone please do an upload of python-traits?  I did an update to the
> latest upstream release, plus various minor fixes.  I didn't remove Python 2
> support yet as there are still a few rdeps.
>
> https://salsa.debian.org/python-team/modules/python-traits

- The changelog entry from 4.6.0-1 upload is missing.
- You added ${sphinxdoc:Depends}, but none of the packages contains any .html
  files, so that substitution variable is undefined. Please either build and
  ship the documentation, or remove that variable and python3-sphinx from
  Build-Depends.

Please fix that and I will sponsor this.

Also are you interested in python-traitsui package? It would be nice to get
it ported to Python 3 or removed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Severity bump script

2019-11-15 Thread Dmitry Shachnev
Hi Sandro!

On Thu, Nov 14, 2019 at 07:13:49PM -0500, Sandro Tosi wrote:
> where is the first draft:
> http://sandrotosi.me/debian/py2removal/would_raise_to_rc.txt (it will
> be updated every time the script runs)
>
> there are 703 unique severity bumps roughly half of the pending bugs.
> please note there are duplicates in the list as data is per binary
> package, while bugs are on a source package basis.
>
> you can read the heuristic to determine if it's a module
> (https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L472)
> or and app 
> (https://github.com/sandrotosi/debian-tools/blob/master/py2rm_progress.py#L475)
> in the links, they are pretty weak, is there a better way?

I see that the script considers some -doc packages as modules.

I can’t tell if we should remove them, but maybe the description could
be updated? Like “python-foo-doc is a documentation package has 0 external
rdeps”.

Also, in other lines I would also change “have” to “has”.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: reducing matplotlib2 build-depends.

2019-11-13 Thread Dmitry Shachnev
Hi Sandro!

On Tue, Nov 12, 2019 at 09:10:49PM -0500, Sandro Tosi wrote:
> well, i dont think it's a good reason to just stop testing complex
> software tho. some of those dependencies are required so that mpl can
> build extensions (in particular for the GUI backends) so if you remove
> them, the mpl build system is smart enough to disable those
> extensions, resulting in a graphic library without any GUI bindings to
> work with. that doesnt sound ideal.

That is a valid point. But please drop at least the PyQt4 GUI binding.

That one is clearly not needed when PyQt5 binding exists.

> I'm gonna go thru some of the dependencies and will see if i can
> remove some, in particular now that i've remored the -doc package from
> the git repo, but i'm not gonna get rid the whole unittest suite.
>
> thanks for your work on this, and to nudge me into looking deeper at mpl2
> deps

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: reducing matplotlib2 build-depends.

2019-11-12 Thread Dmitry Shachnev
Hi all,

On Tue, Nov 12, 2019 at 02:13:51PM +, peter green wrote:
> matplotlib2 seems to be an important node in the python2 removal/reduction
> problem (and the qt4 removal problem). I have noticed there are a
> substantial number of python module packages that it build-depends on but
> does not depend on.
>
> [...]
>
> What do others with more experience think? Should these build-dependencies
> be removed?

+1 for this idea!

matplotlib2 is currently one of only 4 blockers for python-qt4 removal (and
one of two blockers for removing its Python 2 part).

I wonder if we can also remove python-matplotlib2-doc and related sphinx
build-dependencies. For developers working on software using matplotlib, the
documentation for its latest version (python-matplotlib-doc) should be enough.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: python-opentracing

2019-10-24 Thread Dmitry Shachnev
Hi,

On Wed, Oct 23, 2019 at 10:56:12PM +0200, Fabrice BAUZAC-STEHLY wrote:
> I have an issue packaging python-opentracing [1] and I need help.
>
> Basically lintian is happy except for one serious problem:
>
> E: python3-opentracing: no-copyright-file

That happens because you are overriding dh_installdocs and running it only
for one package.

Either remove the -ppython-opentracing-doc argument, or add another call
with --remaining-packages option.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: [packaging] wurlitzer

2019-10-21 Thread Dmitry Shachnev
Hi all,

On Mon, Oct 21, 2019 at 04:26:10PM +0300, Andrius Merkys wrote:
> On 2019-10-21 16:15, MARIE Alexandre wrote:
> > I tried it as you said but I still get the same error : 
>
> Hmm. The layout on PyPI seems to have changed. Could you try this now?:
>
> version=4
> opts="pgpmode=none" \
>  https://pypi.python.org/pypi/wurlitzer/ \
>  https://files.pythonhosted.org/packages/.*/.*/.*/\
>  wurlitzer-([\d\.]+).tar.gz debian uupdate

A downside of this debian/watch is that it only sees the latest tarball,
but not the historic releases.

I think using one of these two pages will be better:

- https://pypi.org/simple/wurlitzer/
- https://pypi.debian.net/wurlitzer/

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Git, gbp blues

2019-09-08 Thread Dmitry Shachnev
On Sat, Sep 07, 2019 at 11:57:42PM +0200, Guðjón Guðjónsson wrote:
> Hi again
>
> One more question.
> If I have updated the sources with uscan and when running lintian I
> find out that
> there is an unwanted file in the upstream sources.
>
> How can I remove the file from the upstream tarball after it has been
> imported into upstream and pristine-tar?

If the tarball was not previously repacked, then you need to use a different
version number (e.g. +dfsg or +repack). List the file in Files-Excluded in
debian/copyright and add repack options to debian/rules (e.g.
opts=dversionmangle=s/\+dfsg//,repacksuffix=+dfsg — see pyqt5 for example).

After that, you have a new upstream version so you can import the tarball
using the normal procedure (gbp import-orig --uscan --pristine-tar).

Although, this depends on how much unwanted the file is. If it does not
violate DFSG and is not large, then it may be better to leave the tarball
as is and add that file to debian/clean.

If the tarball is already repacked, and you need to exclude one more file
(and you have not yet uploaded the current version to archive), then I would
suggest you to manually remove the files from upstream branch, and run
pristine-tar commit after generating the new tarball.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Git, gbp blues

2019-09-08 Thread Dmitry Shachnev
Hi Guðjón,

On Sat, Sep 07, 2019 at 08:44:53AM +0200, Guðjón Guðjónsson wrote:
> I am now working on my gspiceui package (which is in fact not a python
> package)
> But the master branch is just master, not debian/master
>
> Here debian/master is preferred
> https://wiki.debian.org/Python/GitPackaging
>
> But in this page the branch name is master.
> https://wiki.debian.org/PackagingWithGit
>
> What is the standard?
> Shall I change?

If the package is not in DPMT or PAPT then you can use any branch names.

Just if you use debian/master, do not forget to specify it in
debian/gbp.conf (gbp expects master by default).

There is an attempt to standardize, DEP-14 (which suggests debian/master),
but it is not yet widely adopted:
https://dep-team.pages.debian.net/deps/dep14/

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: updating mechanize - help concerning tests with pybuild

2019-08-31 Thread Dmitry Shachnev
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

2019-08-31 Thread Dmitry Shachnev
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

2019-08-31 Thread Dmitry Shachnev
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)

2019-08-31 Thread Dmitry Shachnev
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


Bug#938971: RM: python-gdata -- ROM; dead upstream; Python 2 only

2019-08-30 Thread Dmitry Shachnev
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

python-gdata was never ported to Python 3.

Upstream is dead and python3-googleapi may be a better replacement.

The last reverse dependency (ckanclient) was RMed today.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#938936: RM: ckanclient -- RoQA; maintainer MIA; Python 2 only; deprecated upstream

2019-08-30 Thread Dmitry Shachnev
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal

- Last maintainer upload was in 2012. The maintainer does not respond
to any bugs, including a release critical one.
- Python 2 only.
- Depends on python-gdata which I want to remove from unstable (#899010).
- Not in testing.
- Deprecated upstream, replaced with ckanapi (#912472).

Reverse dependencies checked with dak rm -Rn ckanclient.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Filing py2removal bugs with correct attributes

2019-08-28 Thread Dmitry Shachnev
Hi Matthias,

On Wed, Aug 28, 2019 at 09:00:48AM +0200, Matthias Klose wrote:
> Please file Python2 removal bugs with the appropriate attributes.
>
> It's
>
> Package: ftp.debian.org
> Severity: normal
> User: debian-python@lists.debian.org
> Usertags: py2removal

Sorry. I will use correct tags next time.

Both mine and Andrey’s existing bugs now show on [1], so it looks like you
(or someone else) already fixed them.

[1]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-python@lists.debian.org;tag=py2removal

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Git, gbp blues

2019-08-25 Thread Dmitry Shachnev
Hi Guðjón!

On Sun, Aug 25, 2019 at 10:01:02PM +0200, Guðjón Guðjónsson wrote:
> I did follow the procedure but I don't know what to do if a patch
> doesn't apply cleanly.
> I did try
> gbp pq import
> gbp:info: Trying to apply patches at 
> 'c72f39a3a32b5e5c1eb7f9aaf7176e942e85d804'
> gbp:warning: Patch 0004-remove-logo-privacy-issue.diff.patch failed to
> apply, retrying with whitespace fixup

The correct procedure is running “gbp pq import” *before* importing a new
tarball. Then after importing you do “gbp pq rebase”.

Sometimes I myself forget to run “gbp pq import”. In this case I do the
following:

- Remember the current commit SHA1;
- git reset --hard origin/debian/master;  # or to previous tag
- gbp pq import;  # this is the needed step
- git checkout debian/master;  # back to debian/master branch
- git merge COMMIT_ID;  # that you remembered before

> But fixing the patches with quilt before importing them the second
> time seems to fix all my problems.

If it does not break the patches metadata then it also works.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#935700: RM: sphinx-issuetracker -- ROM; Python 2 only; dead upstream; no reverse dependencies

2019-08-25 Thread Dmitry Shachnev
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Last upstream commit was in 2014, and upstream does not respond to pull
requests like [1].

Reverse dependencies checked with with dak rm -Rn sphinx-issuetracker.

[1]: https://github.com/ignatenkobrain/sphinxcontrib-issuetracker/pull/13

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Watch file for riverbankcomputing (QScintilla)

2019-08-24 Thread Dmitry Shachnev
Hi Guðjón!

On Sat, Aug 24, 2019 at 08:43:33AM +0200, Guðjón Guðjónsson wrote:
> I am working on the QScintilla package and starting on the watch file
> but I cannot figure out how to fix the URL. I tried to use the
> pyqt5 package as a template but without luck.
> The URL is
> https://www.riverbankcomputing.com/static/Downloads/QScintilla/2.11.2/QScintilla_gpl-2.11.2.tar.gz
> and the pyqt5 watch file contains:
> https://www.riverbankcomputing.com/software/pyqt/download5 \
> /static/Downloads/PyQt5/[\d.]+/PyQt5_gpl-([\d.]+)\.tar\.gz
>
> but it doesn't help me :(

The following seems to work for me:

version=3
opts=dversionmangle=s/\+dfsg// \
https://www.riverbankcomputing.com/software/qscintilla/download \
/static/Downloads/QScintilla/[\d.]+/QScintilla_gpl-([\d.]+)\.tar\.gz

If you are going to replace custom repacking code with Files-Excluded
field in debian/copyright, then change second line to this:

opts=dversionmangle=s/\+dfsg//,repacksuffix=+dfsg \

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#935508: RM: bauble -- RoQA; Python 2 only, uses unmaintained modules, superseded upstream

2019-08-23 Thread Dmitry Shachnev
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

- package is orphaned (#903644);
- uses unmaintained modules (pygtk #885138, python-gdata #899007);
- not in testing;
- upstream GitHub repository [1] is now archived;
- upstream author is now developing ghini [2] instead, which has similar
  purpose. If someone is interested, it is better to package that instead.

[1]: https://github.com/Bauble/bauble.classic
[2]: https://github.com/Ghini/ghini.desktop

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Bug#935176: RM: babiloo -- ROM; dead upstream, uses Python 2 and Qt 4

2019-08-20 Thread Dmitry Shachnev
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertag: py2removal

Last upstream release was in 2010. The domain http://www.babiloo-project.org/
is now for sale.

Reverse dependencies checked with dak rm -Rn babiloo.

There are reverse recommendations, but it is among other alternatives.
E.g. stardict-czech has
Recommends: sdcv (>= 0.4.2-2) | stardict (>= 2.4.6) | stardict-gtk (>= 2.4.6) | 
goldendict | qstardict | babiloo | dictionarystar

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Use debhelper-compat instead of debian/compat

2019-07-19 Thread Dmitry Shachnev
On Fri, Jul 19, 2019 at 08:41:04AM +1000, Craig Small wrote:
> Why not, it's a simple change and will get them all into line.
>
> One question though, what happens if the package compat level is not the
> latest?

debhelper currently Provides: debhelper-compat (= 9), debhelper-compat (= 10),
debhelper-compat (= 11), debhelper-compat (= 12).

So this change is safe to do for packages whose compat level is ≥ 9.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Packaging python-xrayutilities

2019-03-21 Thread Dmitry Shachnev
On Thu, Mar 21, 2019 at 02:36:01PM +0300, Dmitry Shachnev wrote:
> Hi Marie!

Perhaps this should have been ‘Hi Alexandre’. Sorry if I got this wrong.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Packaging python-xrayutilities

2019-03-21 Thread Dmitry Shachnev
Hi Marie!

On Thu, Mar 21, 2019 at 10:09:22AM +, MARIE Alexandre wrote:
> Hello,
>
> I'm still working on the package python-xrayutilities for debian.
>
> I've come to a point where the package can be built but when generating the 
> doc,
> lintian comes with a bunch of privacy-generic-breach tags like this :
>
> W: python-xrayutilities-doc: privacy-breach-generic [...]
> (https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.5/latest.js?config=tex-ams-mml_htmlormml)
>
> I have tried to add in debian/rules this :
> override_dh_installdocs:
> ln -s /usr/share/javascript/mathjax/MathJax.js 
> $(CURDIR)/doc/build/html/_static/MathJax.js
> find doc/build/html -name "*.html" -exec sed -i 
> "s|https://cdn.mathjax.org/mathjax/latest/MathJax.js|_static/MathJax.js|" {} 
> \;
> dh_installdocs -ppython-xrayutilities-doc doc/build/html
>
> But it does not seem to work.

Don’t do anything in debian/rules. Instead, patch your conf.py to
have a line like this:

  mathjax_path = 
'file:///usr/share/javascript/mathjax/MathJax.js?config=TeX-AMS-MML_HTMLorMML'

This way the files produced by Sphinx will have the right path, and there
won’t be any need for making symlinks.

--
Dmitry Shachnev
(maintainer of both sphinx and mathjax packages)


signature.asc
Description: PGP signature


Re: Please enable me pushing to python-team/applications

2019-03-19 Thread Dmitry Shachnev
Hi Andreas!

On Tue, Mar 19, 2019 at 05:12:33PM +0100, Andreas Tille wrote:
> Hi,
>
> I need to admit that it is a bit demotivating to care for RC bugs on
> behalf of PAPT but beeing prevented to easily commit what simply
> should be commited.  Its not working for me even now and I might
> decide to remove my local Git clone to save some disk space.  Those
> who preventing me to help can try to assemble single commits on
> their own than.
>
> Sorry, for beeing a bit harsh, but I'm afraid that things like
> this are effectively preventing newcomers to this team

I hope you will be added to the team, but while you are not, why can’t
you just use merge requests?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: scipy 1.2.0 and joining DPMT

2019-03-16 Thread Dmitry Shachnev
On Sun, Mar 17, 2019 at 02:50:32AM +0800, Drew Parsons wrote:
> On 2019-03-17 02:48, Drew Parsons wrote:
> >
> > Hi Dmitry, the Tools section still refers to git-dpm.
>
> Ah, that would be MR-5, still in discussion.

Yes.

I will give the original submitter (Yao Wei) some time to fix this,
but if he does not respond, I will merge it with my suggestion applied.

(I hope Ondřej does not mind.)

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: scipy 1.2.0 and joining DPMT

2019-03-16 Thread Dmitry Shachnev
On Fri, Mar 15, 2019 at 02:34:26PM +0100, Ondrej Novy wrote:
> > https://salsa.debian.org/python-team/tools/python-modules/merge_requests/4
>
> let's merge it without "Configurations" section now, please.

Done!

I will now also review the follow-up merge requests.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Review/upload request for python-guizero

2019-02-28 Thread Dmitry Shachnev
Hi Nick,

On Fri, Mar 01, 2019 at 02:56:38AM +, Nick Morrott wrote:
> Yesterday I uploaded a new 0.6.0 release of python-guizero to DPMT on salsa 
> [1].
>
>   [1] https://salsa.debian.org/python-team/modules/python-guizero
>
> Conscious of the approaching Buster freeze and 10-day migration
> period, would anyone be kind enough to review and upload this new
> release today?

Uploaded.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: upstream release of unreleased package

2019-02-22 Thread Dmitry Shachnev
On Fri, Feb 22, 2019 at 07:13:28PM +, llu...@autistici.org wrote:
> Ok. These are the commands I would use:
>
> $ gbp clone g...@salsa.debian.org:python-team/applications/visualequation.git
> $ cd visualequation/
> (debian/master)]$ git revert HEAD
> [debian/master 7cc491f] Revert "Adding patches"
>  3 files changed, 524 deletions(-)
>  delete mode 100644 debian/patches/0001-Imported-Upstream-version-0.3.8.patch
>  delete mode 100644 
> debian/patches/0002-modifying-d-changelog-for-new-upstream-release.patch
>  delete mode 100644 debian/patches/series
> (debian/master)]$ git merge upstream/0.3.8 Merge made by the 'recursive' 
> strategy.
>  README.md| 12 --
> [...]
>  10 files changed, 167 insertions(+), 51 deletions(-)
> (debian/master)]$ dch -v 0.3.8-1
> (debian/master)]$ git add debian/changelog
> (debian/master)]$ git commit -m "Updating debian/changelog to 0.3.8-1"
> [debian/master b5496f5] Updating debian/changelog to 0.3.8-1
>  1 file changed, 3 insertions(+), 2 deletions(-)
> (debian/master)]$ git push origin : --tags

Looks fine to me.

The last command won’t do anything though, since the upstream tag
already exists, and you have not created a Debian release/tag yet.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: upstream release of unreleased package

2019-02-22 Thread Dmitry Shachnev
Hi,

On Fri, Feb 22, 2019 at 12:54:22AM +, llu...@autistici.org wrote:
> Now that my system is working properly I propose a solution for the
> repository. It is based in git-revert the three branches (debian/master,
> upstream and pristine-tar) and invoke gbp import-orig with option
> --upstream-tag=upstream/0.3.8-aux. I paste a log of my proposal.
>
> Do you think it is adequate/correct?
>
> $ gbp clone g...@salsa.debian.org:python-team/applications/visualequation.git
> gbp:info: Cloning from 
> 'g...@salsa.debian.org:python-team/applications/visualequation.git'
> $ cd visualequation/
> (debian/master)]$ git revert HEAD
> [debian/master 99ea7ee] Revert "Adding patches"
>  3 files changed, 524 deletions(-)
>  delete mode 100644
> debian/patches/0001-Imported-Upstream-version-0.3.8.patch
>  delete mode 100644
> debian/patches/0002-modifying-d-changelog-for-new-upstream-release.patch
>  delete mode 100644 debian/patches/series
> (debian/master)]$ git checkout upstream
> Switched to branch 'upstream'
> Your branch is up-to-date with 'origin/upstream'.
> (upstream)]$ git revert HEAD

The last commits in upstream and pristine-tar branches look fine, no
need to revert them.

Just revert the last commit in debian/master (as you did above), then
merge upstream/0.3.8 tag into debian/master and update the changelog.
It should be enough.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: upstream release of unreleased package

2019-02-21 Thread Dmitry Shachnev
Hi Daniel,

On Thu, Feb 21, 2019 at 09:15:59PM +, llu...@autistici.org wrote:
> I paste below a (reproducible) log of what I did. Maybe you can show me what
> I did wrong this time so I am not able to build package for 0.3.8.
>
> [...]
> $ gbp buildpackage --git-tag-only
> gbp:info: Tagging 0.3.7-1 as debian/0.3.7-1
> $ gbp pq import
> gbp:info: Trying to apply patches at 
> 'e7df8339db59a5e92f14523f3c704a989c5b2e74'
> gbp:info: Patches listed in 'debian/patches/series' imported on 
> 'patch-queue/debian/master'
> $ gbp import-orig --pristine-tar --uscan

Here, the output of ‘gbp pq import’ is a bit different (note the ‘0’):

  0 patches listed in 'debian/patches/series' imported on 
'patch-queue/debian/master'

And I cannot reproduce the failure that you are getting later. Does this
mean you are using git-buildpackage older than 0.8.0?

In 0.8.0, the output of ‘gbp pq import’ was changed, and in 0.8.2
bug #832016 was fixed, which may affect your workflow.

Anyway, I think that here you should run import-orig from debian/master
branch, not from patch-queue/debian/master (where the previous command
left you). If you run ‘git checkout debian/master’ before ‘gbp import-orig’
this might work even with older git-buildpackage versions.

I recommend setting up your shell prompt to show the current branch, it will
make it easier to understand what is going on. You can find some instructions
how to do it in /usr/lib/git-core/git-sh-prompt.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: scipy 1.2.0 and joining DPMT

2019-01-29 Thread Dmitry Shachnev
On Mon, Jan 28, 2019 at 11:13:46AM +0100, webm...@emerall.com wrote:
> Thanks Ondrej, read and accepted.  
> The policy on Maintainer/Upload fields is interesting.
> I've installed git-dpm, likely it will be useful for my other packages.

It will not be useful in DPMT/PAPT. The policy is outdated and we have
switched to using gbp instead, as described here:

https://wiki.debian.org/Python/GitPackaging

Ondřeji, do you mind if I merge this?
https://salsa.debian.org/python-team/tools/python-modules/merge_requests/4

Only your comment about debian/gbp.conf seems to be blocking it. I think that
at least specifying debian-branch is definitely needed. If you want I can
simplify it to just that one line before merging, and/or link to the wiki
instead of recommending any specific gbp.conf content.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Command to query “Python versions that are installed *with* standard library”

2019-01-24 Thread Dmitry Shachnev
Hi Ben,

On Thu, Jan 24, 2019 at 10:16:44AM +1100, Ben Finney wrote:
> Howdy all,
>
> What is a ‘py3versions’ (or alternative) command that can be run in
> AutoPkgTest, to query the Python versions that are installed on this
> machine *with* their standard library?
>
> The ‘pythonX.Y-minimal’ packages can be installed *without* standard
> library, but will still appear in the ‘py3versions --installed’ output.
>
> This means it's possible to have an AutoPkgTest test that attempts to
> run a module for all the ‘py3versions --installed’ versions, then fail
> because an import of a standard library module fails.
>
> What command, hopefully as simple as ‘py3versions --installed’, can be
> used in AutoPkgTest to interrogate *only* those Python versions on the
> local machine that have their standard library installed?

I usually use py3versions --supported and make the autopkgtest depend on
python3-all.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Please add 'stappers' to PAPT, 403

2019-01-12 Thread Dmitry Shachnev
On Sat, Jan 12, 2019 at 06:14:51PM +0100, Geert Stappers wrote:
> Thanks
>
> Tried it today:
>
> 
> $ git push --all
> Username for 'https://salsa.debian.org': stappers
> Password for 'https://stapp...@salsa.debian.org': 
> remote: You are not allowed to push code to this project.
> fatal: unable to access
> 'https://salsa.debian.org/python-team/applications/pelican.git/': The
> requested URL returned error: 403
> $ 
> 

Looks like you were added to DPMT but not PAPT:

https://salsa.debian.org/groups/python-team/modules/-/group_members?search=Stappers
https://salsa.debian.org/groups/python-team/applications/-/group_members?search=Stappers

I hope Ondřej or another admin can correct it.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Please add 'stappers' to PAPT

2019-01-04 Thread Dmitry Shachnev
Hi Geert!

On Fri, Jan 04, 2019 at 10:16:20PM +0100, Geert Stappers wrote:
> Hello,
>
> Here Debian Developer 'stappers'.
>
> I'm working on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917468
> which is about fixing the VCS field of the Python package 'pelican'
>
> I would like to create 
> https://salsa.debian.org/python-team/applications/pelican
> or would like to have that git repo created and have write privilege to it.

FWIW, that repo already exists.

And reading bug #917468 log, you were trying to migrate SVN to Git yourself,
which is not needed since all PAPT repos were migrated automatically.

(Of course your request to join the team is still valid.)

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: reference package python3 PAPT

2018-12-26 Thread Dmitry Shachnev
Hi Geert!

On Tue, Dec 25, 2018 at 11:29:01PM +0100, Geert Stappers wrote:
> > I think pymilter-milters is in pretty good shape (as of the version I just 
> > uploaded), keeping in mind it's still python2 and if your upstream supports 
> > it, you should try to go python3.
>
> Thank you,  it got me started.
>
> And I have updated the subject line with the intention
> that more possible reference packages are being reported.

You can take a look at my retext package.

It is Python 3 and in a good shape. The --no-rename option is specific
to retext, but everything else is quite generic.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Help needed to get Python module of libedlib properly installed

2018-12-16 Thread Dmitry Shachnev
Hi Andreas!

On Wed, Dec 12, 2018 at 12:02:42PM +0100, Andreas Tille wrote:
> Hi,
>
> libedlib[1] has a Python3 module which I want to provide in a
> python3-edlib package (since it is needed by some other package
> I'm working on).  I've prepared something in Git[1] but it ends
> up with an empty python3-edlib package despite the file
>
>
> $(CURDIR)/.pybuild/cpython3_3.6_edlib/build/edlib.cpython-36m-x86_64-linux-gnu.so
>
> is created.  Am I missing something in the final install step?

The attached patch should fix the issues.

--
Dmitry Shachnev
From 12e2e883f12acf9f18bbf9fbf927c42c8353bcdb Mon Sep 17 00:00:00 2001
From: Dmitry Shachnev 
Date: Sun, 16 Dec 2018 23:51:53 +0300
Subject: [PATCH] Fix build of Python bindings

---
 debian/control | 2 +-
 debian/rules   | 7 ---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index a338d5a..45b3870 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: debhelper (>= 11~),
d-shlibs,
rename,
cython3,
-   python3-dev,
+   python3-all-dev,
python3-setuptools
 Standards-Version: 4.2.1
 Vcs-Browser: https://salsa.debian.org/med-team/libedlib
diff --git a/debian/rules b/debian/rules
index f37d073..8ab2fed 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,7 +9,7 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all
 DEB_CMAKE_EXTRA_FLAGS = -DCMAKE_BUILD_TYPE=Release
 
 %:
-	dh $@ --buildsystem=pybuild
+	dh $@ --with python3
 
 override_dh_auto_configure:
 	dh_auto_configure --buildsystem=cmake -- $(DEB_CMAKE_EXTRA_FLAGS)
@@ -17,12 +17,13 @@ override_dh_auto_configure:
 override_dh_auto_build:
 	dh_auto_build --buildsystem=cmake
 	# $(MAKE) --directory=bindings/python
-	dh_auto_build -O--buildsystem=pybuild -O--source-directory=bindings/python
+	$(MAKE) --directory=bindings/python edlib pyedlib.bycython.cpp
+	dh_auto_build --buildsystem=pybuild -- --dir bindings/python
 
 override_dh_auto_install:
 	dh_auto_install --buildsystem=cmake
 #	$(MAKE) install --directory=bindings/python
-	dh_auto_install --buildsystem=pybuild -O--source-directory=bindings/python
+	dh_auto_install --buildsystem=pybuild -- --dir bindings/python
 
 override_dh_install:
 	dh_install
-- 
2.19.2



signature.asc
Description: PGP signature


Re: Removing a binary package (python-qwt3d-qt4)

2018-10-28 Thread Dmitry Shachnev
Hi Guðjón!

On Wed, Oct 24, 2018 at 10:28:35PM +0200, Guðjón Guðjónsson wrote:
> Hi list
>
> I have a problem with my package pyqwt3d. It did contain
> the binary package python-qwt3d-qt4 but I removed it and
> replaced it with python3-qwt3d-qt5.
>
> The old binary package seems to exist somewhere and stops the
> package from entering testing. See:
> https://tracker.debian.org/pkg/pyqwt3d

You need to file a bug against ftp.debian.org pseudo-package.
Like this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911272.

If you use reportbug, then run “reportbug ftp.debian.org”, then select
NBS as request type and follow the instructions.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: TypeError: ord() expected a character, but string of length 3 found (Was: Updated python-uncertainties)

2018-10-17 Thread Dmitry Shachnev
Hi Andreas,

On Tue, Oct 16, 2018 at 09:08:43AM +0200, Andreas Tille wrote:
> I can reproduce the wrongly placed / duplicated modules.  Its the same
> observation I made with lmfit-py[1].  While lintian recommends the usage
> of dh_python3
>
> I need to admit I have not found out how to use it properly and thus I
> simply removed the module in question manually[1].  I admit I'd prefer a
> better solution as well and since it seems to happen systematically I
> wonder whether dh-python might have some flaw?

dh_python does not (re)move files if they are different, this needs to be
handled manually.

In your case 2to3 produces different output in 3.6 and 3.7. The resulting
code is still identical, so you can safely remove the differing files.

I used this override in a similar case:

https://salsa.debian.org/python-team/modules/pygithub/blob/master/debian/rules#L10

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Upstreams dropping Python 2 support

2018-09-27 Thread Dmitry Shachnev
On Thu, Sep 27, 2018 at 11:58:28AM +0200, Ole Streicher wrote:
> Is there a reason why one would use Python2-sphinx instead of the Python
> 3 version? How often in these 314 cases it is not just used as an
> executable in d/rules?

One possible reason is when sphinx.ext.autodoc is in use for documenting
Python code, and that code is Python 2 only.

Also there may be custom Sphinx extensions written in Python 2.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Upstreams dropping Python 2 support (Was: Re: Report from the Python BoF @ DebConf18)

2018-09-27 Thread Dmitry Shachnev
On Wed, Sep 19, 2018 at 09:32:23AM -0400, Sandro Tosi wrote:
> > This also means finding
> > solutions for edge-cases such as astroid, whose 2.0 branch is the only to
> > support Py3.7, but also drops 2.x support.
>
> this is becoming less of an edge-case and more the current situation
> of several "core" python modules: drop python2 support (eventually
> maintaining a LTS-like old release around for py2) in favor of a pure
> python3 codebase. Latest example is matplotlib 3.0 released yday which
> dropped python2 support (maintained only in the 2.x branch, which will
> receive only critical fixes), and numpy will release soon a py3k-only
> version.
>
> What did the team decide on this front? duplicating packages is not
> always feasible (both from an archive and from a maintainership
> perspective)

I think for “popular” packages duplication is unavoidable.

Sphinx 2.0 will also drop Python 2.7 support, so I am going to make the
“sphinx” source package ship only python3-sphinx, and introduce the new
source package (“sphinx-python2”?) which will ship only python-sphinx.

Eventually I will also do a mass bug filing, but with the current 314
python-sphinx reverse build-depends it is clear that I will have to ship
sphinx-python2 for quite some time.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: sphinx-build vs. Python 3

2018-08-21 Thread Dmitry Shachnev
Hi Ondřej!

On Mon, Aug 20, 2018 at 09:50:25AM +0200, Ondrej Novy wrote:
> Hi,
>
> I have question about sphinx-build and our effort to move to Python 3.
>
> sphinx-build is currently Python 2 or Python 3 according to python-sphinx /
> python3-sphinx package installed (with python3 as default if both are
> installed by alternative priority).
>
> According to:
> https://wiki.debian.org/Python/LibraryStyleGuide#Sphinx_documentation we
> should use "python3 -m sphinx" if we want to build docs using Python 3,
> because if you run sphinx-build, you can't be sure which version of Sphinx
> is run and if you need some Sphinx extension, which we typically installs
> only Python 2 or Python 3 version of it.

That wiki page was written before I changed Sphinx scripts to use Python 3
by default. That happened only recently, the relevant upload reached
unstable on July 5th 2018.

If you depend on python3-sphinx (>= 1.7.5-4~) then most likely the scripts
will be using Python 3. The opposite will happen only if the user manually
updated the alternative, and this won’t be the case on a sane build
environment.

> And my question is:
> * should we use "python3 -m sphinx" instead of "sphinx-build" everywhere
> where python3-sphinx is in B-D (mass-commit?)

This won’t hurt, but as I said it won’t make any difference on the current
unstable. It will make difference only when building against an older version
of sphinx (e.g. backports) *and* with installed python-sphinx.

> * should we change sphinx-build to be Python3 only? (and broke current
> packages build with Python2 Sphinx)

I would like to do this in the future, but currently there will be too
many broken packages:

https://lintian.debian.org/tags/build-depends-on-python-sphinx-only.html
lists 386 packages.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: git-dpm -> gbp conversion (mass-change) [phase 1 DONE]

2018-08-12 Thread Dmitry Shachnev
Hi,

On Sun, Aug 12, 2018 at 10:20:53AM -0300, eamanu15 wrote:
> Hello Everybody!
>
> Its a good idea use gbp. Its more easy to use.
>
> Are there some step by step of the use?

There was a link in Scott’s mail:

https://wiki.debian.org/Python/GitPackagingPQ

This page covers the most popular operations you would need to do.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: how to deal with py-file-not-bytecompiled

2018-08-02 Thread Dmitry Shachnev
On Thu, Aug 02, 2018 at 06:50:59AM +, PICCA Frederic-Emmanuel wrote:
> Hello, I am preparing the new silx package and I got these error messages 
> from adequate
>
> This package produce the silx python module but install also a bunch of files 
> for qtdesigner
> in the rules file with this command.
>
>   # install the qtdesigner files only for the python3 package
>   dh_install -p python3-silx qtdesigner_plugins/*.py 
> /usr/lib/qt4/plugins/designer/python

A bit off-topic, but you should not use Qt 4 in new packages.

See https://lists.debian.org/debian-devel-announce/2017/08/msg00006.html.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Veusz - update to 3.0

2018-07-14 Thread Dmitry Shachnev
Hi Jeremy,

On Sun, Jun 17, 2018 at 12:11:04PM +0200, Jeremy Sanders wrote:
> [...]
>
> Another issue is that I can't get continuous integration tests working
> properly on Salsa. The module works fine in a pbuilder build, but on Salsa,
> Qt can't load its xcb module for the self tests under Xvfb.

I forked your repository and added QT_DEBUG_PLUGINS=1 before the failing
command. Looks like the process is running out of memory:

https://salsa.debian.org/mitya57/veusz/-/jobs/31240

I do not know what to do with this, but at least we now know the reason.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

2018-07-05 Thread Dmitry Shachnev
On Wed, Jul 04, 2018 at 09:50:51PM -0300, eamanu15 wrote:
> Hello Dmitry,
>
> I just pushed the update the package to Salsa. I pushed the PyGithub_1.40
> version.

Thanks! Uploaded after fixing debian/changelog.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

2018-07-04 Thread Dmitry Shachnev
On Wed, Jul 04, 2018 at 07:09:20AM -0300, eamanu15 wrote:
> Hello Dmitry,
>
> I have the fixes almost already, Just, I have a doubt in this point:
>
> > - When building in the current sid, I get Lintian warnings about three files
> >   shipped in /usr/lib/python3.7/dist-packages/.
>
> To fix this problem I could add in the d/rules the next line:
>
> override_dh_auto_install:
> dh_auto_install
> find ./debian/python3-github/usr/lib/ -type f -name python3.* -delete
>
> isn't?

It is a directory, not a file. Also you need to do it after dh_python3 runs.
So better use this:

override_dh_python3:
dh_python3
rm -rfv debian/python3-github/usr/lib/python3.*

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

2018-07-03 Thread Dmitry Shachnev
On Tue, Jul 03, 2018 at 06:00:34PM -0300, eamanu15 wrote:
> Hello Dimitry,
>
> Thanks for you email. I Will make the changes that you recommend.
>
> I have a cuestion for you. When I update to the version 1.40, Do I merge
> all the changelog entries, including 1.35-1 upload, isn't?

Yes, it is better to merge these entries and keep one entry per actual
upload to archive.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Bug#900368: RFS: pygithub/1.40a3-1 [ITP]

2018-07-03 Thread Dmitry Shachnev
Control: merge 898416 898811 900368

Hi Emmanuel!

On Tue, May 29, 2018 at 12:35:25PM -0300, eamanu15 wrote:
> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pygithub"

Note that I am merging your three RFS bugs. If you want to ping, just reply
to the existing bug, not file a new one.

Here are my comments about your changes.

- It would be nice if you based the repository on the existing Git
  repository [1], rather than starting from scratch.

  Also for new team repositories as this one, it is better to use Gbp-Pq
  workflow as described in the team wiki [2].

- Please merge the last three changelog entries, as 1.35-1 upload did not
  happen.

- When building in the current sid, I get Lintian warnings about three files
  shipped in /usr/lib/python3.7/dist-packages/.

  That probably happens because of output of 2to3 is slightly different in
  Python 3.6 and 3.7 (e.g. files.items() vs. iter(files.items())), and
  dh_python3 does not remove the file if it does not match.

  I would recommend removing debian/python3-github/usr/lib/python3.* manually
  in debian/rules. Keeping debian-python@ in Cc in case someone has a better
  idea.

- A new stable 1.40 release has been released on June 26th [3].
  Can you update from alpha to the stable version?

  Also please add uversionmangle to debian/watch (like here [4]), to make it
  treat 1.40 as a higher version than 1.40aN.

[1]: 
https://alioth-archive.debian.org/git/users/kaction-guest/pygithub.git.tar.xz
[2]: https://wiki.debian.org/Python/GitPackagingPQ
[3]: https://pypi.org/project/PyGithub/1.40/
[4]: https://pypi.debian.net/PyGithub/watch

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Call for testing: Sphinx with Python 3 scripts by default

2018-06-29 Thread Dmitry Shachnev
Hi!

Sphinx 1.7.5-4 in experimental now uses update-alternatives for managing its
scripts (sphinx-build, sphinx-autogen, etc), and Python 3 is now the preferred
version.

This means that if you have both python-sphinx and python3-sphinx installed,
the scripts will use Python 3 by default.

Please try the package from experimental and test your packages with it.
Some packages, especially those that do not support Python 3, may start
failing to build, when some other dependency pulls python3-sphinx.

To explicitly request the Python 2 or Python 3 of sphinx, you can use
“python2 -m sphinx” and “python3 -m sphinx” instead of sphinx-build.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: What to do about packages that depend on distutils being not installable

2018-05-31 Thread Dmitry Shachnev
Hi,

On Thu, May 31, 2018 at 11:50:06AM -0700, Diane Trout wrote:
> Hi,
>
> I was trying to rebuild dask, and discovered that several dependencies
> aren't installable because python3-distutils appears to have been
> merged into python3-stdlib-extensions.
>
> For example in an unstable chroot
>  python3-sphinx : Depends: python3-lib2to3 but it is not installable
>   Depends: python3-distutils but it is not installable
>
> Is this a problem with the python3-stdlib-extensions packaging or does
> anything that currently depends on python3-distutils need to be
> updated?

Looks like it has a build-dep loop:

https://buildd.debian.org/status/package.php?p=python3-stdlib-extensions

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: input into perl 6 packaging required

2018-05-07 Thread Dmitry Shachnev
Hi Robert!

On Sat, May 05, 2018 at 09:21:28PM +0200, Robert Lemmen wrote:
> hi folks,
>
> we are currently thinking about how to package perl 6 modules, some
> background and information at https://wiki.debian.org/Perl6PreCompProposal
>
> Perl 6 does pre-compile modules on loading, a bit like the .pyc files.
> So I would be very glad if you could have a quick look at the wiki page
> above, perhaps you experience could help us. I am also specifically
> interested in your decision to create the .pyc files at package
> installation time, rather than at package build time. What was the
> reason for that? Do you still think it was the right decision? In the
> case of perl 6 the precompiled files depend on a fairly specific version
> of the runtime, so we would need to re-build them quite often...

I think the main reasons for generating .pyc files at install time were:

- Ability to ship “Architecture: all” packages, which reduces load on
  build daemons, mirrors, etc.

- Ability to regenerate all .pyc files for new Python version on users’
  side (it does not take a long time), without need to do binNMUs or
  re-uploads.

And I think it was the right decision, as these reasons still apply.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Bug#895849: sphinxcontrib-autoprogram: Incompatible with Sphinx 1.7

2018-04-18 Thread Dmitry Shachnev
Hi Andreas,

On Tue, Apr 17, 2018 at 11:25:36AM +0200, Andreas Tille wrote:
> I applied the suggested patch to version 0.1.4 since I wanted to upload
> this version anyway.  However, when trying to build the package in Git[1]
> I get a test suite failure:
>
> [...]
> ImportError: No module named cli
> [...]
>
> I can confirm that there is no such module cli.  Before I report the
> issue upstream I'd like to ask for confirmation that it is not just me
> overlooking something.
>
> Thanks for any help

This test needs the doc/cli.py file. It is present in upstream Git but
not in the released tarball:

https://github.com/sphinx-contrib/autoprogram/blob/master/doc/cli.py

Try either adding this file using a patch, or using a tarball from Github
rather than from PyPI.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: RFS: mwic 0.7.4-1

2018-03-20 Thread Dmitry Shachnev
On Mon, Mar 19, 2018 at 11:31:07PM +0100, Georg Faerber wrote:
> On 18-03-20 00:46:16, Dmitry Shachnev wrote:
> > On Sat, Mar 17, 2018 at 10:49:26AM +0100, Georg Faerber wrote:
> > > Also, AFAIK, debian/tests/control is obsolete nowadays if
> > > debian/control contains Testsuite:.
> >
> > This is not true. With autodep8 you can test only whether a package
> > can be imported. If you want to run some actual unit tests, you still
> > need debian/tests/control.
>
> In case you're referring to unit tests shipped upstream, that's not
> true. See this [1] and that [2] for an example. The tests are executed,
> but there is no debian/tests/control file.
> 
> [1] 
> https://ci.debian.net/data/autopkgtest/unstable/amd64/r/ruby-gettext-setup/20180313_122311/log.gz
> [2] https://salsa.debian.org/puppet-team/ruby-gettext-setup

This is a Ruby package. AFAIK autodep8 can run the unit tests for Ruby
packages and maybe for some other languages, but for Python it can
only test importability. I believe this is due to Python having (too)
many different test frameworks and ways to run them.

See https://salsa.debian.org/ci-team/autodep8/blob/master/examples.md
which shows how the generated tests look like for different languages.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: RFS: mwic 0.7.4-1

2018-03-19 Thread Dmitry Shachnev
On Sat, Mar 17, 2018 at 10:49:26AM +0100, Georg Faerber wrote:
> Also, AFAIK, debian/tests/control is obsolete nowadays if debian/control
> contains Testsuite:.

This is not true. With autodep8 you can test only whether a package
can be imported. If you want to run some actual unit tests, you still
need debian/tests/control.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: FYI: Fwd: RFS: pygithub/1.35-1[ITA]

2018-01-19 Thread Dmitry Shachnev
On Wed, Jan 17, 2018 at 11:14:41PM +0100, Filip Pytloun wrote:
> Hello Emmanuel,
>
> few notes to your package:
>
> - it would be good to move under DPMT (have you joined the team
>   already?), create git repository and use git-dpm to import current
>   version and make your changes, also set Maintainer and Vcs-* to
>   reflect this

I think for new packages it is better to use gbp-pq based workflow:
https://wiki.debian.org/Python/GitPackagingPQ

git-dpm is unmaintained and is (IMO) more difficult to work with.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: PyQwt3D packaging strategy

2018-01-13 Thread Dmitry Shachnev
Hi Guðjón,

On Wed, Jan 10, 2018 at 09:21:47PM +0100, Guðjón Guðjónsson wrote:
> Hi list
>
> I am updating my package pyqwt3d. It is tested for Qt5, python2 and python3.
> The changes were so huge that I made GitHub fork of it:
> https://github.com/GauiStori/PyQwt3D
>
> Now I have two questions:
>
> 1. Shall I skip the python2 version since it is already end of life?

It looks like the current version of pyqwt3d has no reverse dependencies,
and new applications will use Python 3, so yes, it makes sense to skip
the Python 2 version.

> 2. Shall I make my changes into a huge patch (changes from upstream
> in the DPMT git repository) or make my own GitHub repository as an
> upstream source?

As the real upstream had no updates since 2009, and your changes are huge,
I don’t see anything wrong in using your GitHub repository as upstream.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: python-markdown and mkdocs circular build-dep

2018-01-12 Thread Dmitry Shachnev
Thanks Ghislain and Simon for your responses.

It turns out mkdocs need python-markdown not for tests, but rather for
building its own docs.

So probably the correct way to go is to make sure both packages take the
nodoc build profile into account.

On Thu, Jan 11, 2018 at 11:29:34AM +, Simon McVittie wrote:
> It would probably be best for python-mkdocs to build-depend on
> python3-markdown , after making sure that building with
> "DEB_BUILD_PROFILES=nocheck DEB_BUILD_OPTIONS=nocheck" and without
> python3-markdown installed does work (it looks as though it should). That
> way the cycle can be broken from either end (and nocheck never changes
> package contents, whereas nodoc does, so nocheck is probably a better
> way to break it).

For both mkdocs and python-markdown, -doc is a separate package, so
the nodoc build profile will not change the package contents, but it will
disable building the -doc package at all.

The other issue I found is that mkdocs adds some bundled JS libraries to
the generated documentation. It would be nice to have a dh_sphinxdoc-like
tool to help with unbundling them. I will file a bug for that.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


python-markdown and mkdocs circular build-dep

2018-01-11 Thread Dmitry Shachnev
Hi Brian and list,

The new release of python-markdown has switched docs building from its own
custom build system to mkdocs. However python-mkdocs itself build-depends on
python3-markdown for tests, which results in a circular build-dependency.

Will it be fine if I just mark the build-dependency in python-markdown as
? Or will it be better to disable docs building completely?

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Can't exec "pyversions"

2017-10-27 Thread Dmitry Shachnev
Hi Ondrej!

On Fri, Oct 27, 2017 at 08:18:43AM +0200, Ondrej Tuma wrote:
> Yes, 
>
> but how can I tell to dh_ to use py3versions instead of pyversions ?

Use pybuild buildsystem:

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

And make sure you have dh-python in build-depends.
See pybuild(1) man page for details.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Python 3 Statsmodels & Pandas

2017-09-30 Thread Dmitry Shachnev
Hi Diane,

On Fri, Sep 29, 2017 at 03:55:13PM -0700, Diane Trout wrote:
> Oops.
>
> I thought that it wouldn't try using sphinx when not building doc
> packages. But apparently being listed in "dh --with" counts as being
> used.

Yes, because dh tries to open Sequece/sphinxdoc.pm which is provided by
sphinx-common.

> I wonder if it's better to filter sphinxdoc out of the dh line, install
> sphinx-common, or just always install python3-sphinx?

Adding sphinx-common to B-D and keeping python3-sphinx in B-D-Indep is
probably the easiest solution. Also you can try not relying on --with
at all and manually call dh_sphinxdoc when the build is arch-indep.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: providing sphinx3-* binaries

2017-09-28 Thread Dmitry Shachnev
 as well (see the Debian policy for example).
>
> > Let me summarize what you, in my opinion, should do as a maintainer of
> > packages using Sphinx:
> >
> > 1) If your project is not using autodoc: just build-depend on python3-sphinx
> > and use /usr/bin/sphinx-build. There is no need to care about
> > versions.
> > 2) If your project uses autodoc, and is compatible with both Python 2 and 3:
> > same as in 1), just use /usr/bin/sphinx-build.
> > 3) If your project uses autodoc, and is only compatible with Python 3:
> > use ‘python3 -m sphinx’ or ‘python3 setup.py build_sphinx’, depending on the
> > upstream build system.
> > 4) If your project uses autodoc, and is only compatible with Python 2:
> > Port it to python 3. Or use ‘python2 -m sphinx’ or ‘python2 setup.py
> > build_sphinx’.
> >
> > If you think this classification is incomplete, then please let me know
> > where I am wrong.
>
> That is a fair description, of course. It would be great to have build
> step automated. At the very least, the above should be clearly
> documented somewhere, maybe in dh_sphinxdoc's README or
> manpage. Documenting that dh_sphinxdoc doesn't build in its manpage
> would also go a long way, as that rather implicit right now. (ie. it
> doesn't say it builds sphinx docs, but it doesn't say it doesn't either:
> we need to assume that the list of things it does is exhaustive and
> complete, something I never assume about documentation :)

Now it is explicit:
https://anonscm.debian.org/cgit/python-modules/packages/sphinx.git/commit/?id=5b2efffcaae8c915

> Okay then the policy seems to point towards shipping sphinx3-build
> binary, no?

See what I said above (about false assumptions).

> > This may happen when setup.py depends on Sphinx and automatically calls it
> > during build. Such packages have to build-depend on both Python 2 and 3
> > versions of Sphinx, even if only one version of documentation actually gets
> > shipped.
>
> I don't follow. Why do they need to depend on both? We don't need *nor*
> want to build the documentation twice - if upstream's setup.py
> automatically calls build_sphinx, then this is something we should be
> working around (again, pybuild?) if only to save time on the buildds.

I do not say that these packages do the right thing. I just tried to find
a reason why they may be doing this. It might be better to ask maintainers
of these packages for more precise reason.

> So maybe there's just nothing else to do here in the short term. I'll
> start using "make SPHINXBUILD='python3 -m sphinx'" even though I find
> that real clunky. In fact, the more I think about it, the less I see the
> point of using the Makefiles at all from debian/rules: i'll probably
> just call "python3 -m sphinx" or "setup.py build_sphinx" myself from
> there, as needed.

Right, there is no reason for Makefiles. If the build process is not
integrated in upstream’s main build system, there should be no difference
for you which line to write in debian/rules.

> The problem, then, of course, is that I lose that precious
> automation. Most Python Debian packages really don't need that much
> stuff in debian/rules - this is enough for 90% of the cases:
>
> %:
> dh $@ --with=python2,python3 --buildsystem=pybuild
>
> Yet, when I want to build docs in there, i need to override the build
> targets immediately:
>
> override_dh_auto_build:
> dh_auto_build
> # builder=html,man only supported in Sphinx 1.6, not yet released:
> # http://www.sphinx-doc.org/en/master/setuptools.html
> make -C doc html man SPHINXBUILD="python3 -m sphinx"
> # ^untested
>
> I'd like to be able to just assume sphinxdoc will do the right thing and
> build me a set of HTML docs (at least). Ideally, I'd be able to choose
> the builders (html, man, epub, etc) through the environment, but then
> that'd need to change the build-deps as well, something I understand is
> basically impossible. ;)

See what I said above about pybuild.

> Anyways, I learned a lot through this. Thanks for all the information,
> and I hope we can update docs somewhere to reflect the current situation
> and move ahead with some better build process for this as well.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: providing sphinx3-* binaries

2017-09-27 Thread Dmitry Shachnev
doc: just build-depend on python3-sphinx
and use /usr/bin/sphinx-build. There is no need to care about versions.
2) If your project uses autodoc, and is compatible with both Python 2 and 3:
same as in 1), just use /usr/bin/sphinx-build.
3) If your project uses autodoc, and is only compatible with Python 3:
use ‘python3 -m sphinx’ or ‘python3 setup.py build_sphinx’, depending on the
upstream build system.
4) If your project uses autodoc, and is only compatible with Python 2:
Port it to python 3. Or use ‘python2 -m sphinx’ or ‘python2 setup.py
build_sphinx’.

If you think this classification is incomplete, then please let me know
where I am wrong.

>  5. optionally, the sphinx and sphinx3 packages *may* conflict with each
> other to fight over the sphinx-build symlink. then people needing to
> build against *both* packages can use the "python -m sphinx"
> mechanism in their makefiles, since it's what upstream seems to be
> [doing][2]

Let me quote Policy section 5.4:

“adding Conflicts is normally not the best solution when two packages provide
the same files. Depending on the reason for that conflict, using alternatives
or renaming the files is often a better approach.”

>  6. there are currently packages depending on *both* python-sphinx and
> python3-sphinx. for me, that makes no sense at all: there is a
> single set of documentation files built in a package, and it must be
> on either one of those packages, but not both. if the software
> supports building with python3, then it should depend on
> python3-sphinx, if not, it should depend on python-sphinx. by
> switching to sphinx{,3} binary packages, this would make that
> distinction clearer as well.

This may happen when setup.py depends on Sphinx and automatically calls it
during build. Such packages have to build-depend on both Python 2 and 3
versions of Sphinx, even if only one version of documentation actually gets
shipped.

> My pain points would mostly be fixed with th e simple #1 and #3
> fixes. Without breaking anything, we could already provide a
> sphinx3-build binary, and we could file a PR upstream to make
> SPHINXBUILD more easily overridable. The rest is just a brainstorm of
> possible medium-term fixes to try and fix that dangling symlink issue.
>
> I understand this is a complex situation and I would love to have better
> answers, but I'm not sure there are any simple answers here. We
> shouldn't hesitate to make radical changes, however: we have transition
> tools to help us with that stuff, and if we can upgrade libc and gcc
> across all of Debian fairly painlessly these days, i don't see why we
> couldn't articulate such a transition for ~1000 python packages. :)

In my opinion there should be a very strong reason to make changes that
break packages. I have to deal with Sphinx upstream breaking compatibility
which results in lots of FTBFS bugs for each major version. And I don’t
want to introduce even more incompatibility myself.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Question about binary sphinx inventory files

2017-08-26 Thread Dmitry Shachnev
Hi!

On Sat, Aug 26, 2017 at 12:19:57AM +0200, W. Martin Borgert wrote:
> Hi,
>
> I believe that a small number of Python module doc packages use
> binary Sphinx inventory (.inv) files during build, that are just
> downloaded from python.org by the package maintainer. I don't
> know anything about Sphinx nor how to encode/decode .inv files.
> https://pypi.python.org/pypi/sphobjinv is not in Debian, is it?
> How would I create e.g. https://docs.python.org/objects.inv
> from which sources?

The .inv files are generated by Sphinx during normal HTML build.

In case of https://docs.python.org/objects.inv, you do not need to
regenerate it yourself. You should just depend on python3-doc and
point Sphinx to /usr/share/doc/python3/html/objects.inv.

Here you can find examples of how other packages do it:

https://codesearch.debian.net/search?q=html%2Fobjects%5C.inv+path%3Adebian%2Fpatches%2F.*

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: [Python-modules-commits] [python-cpuinfo] 02/02: Import Debian changes 3.0.0-1

2017-04-17 Thread Dmitry Shachnev
Hi Mattia,

On Sun, Apr 16, 2017 at 10:50:15PM +0200, Mattia Rizzolo wrote:
> > AFAIC, I happily use pytest or sphinx via their respective python[3]-
> > pytest
>
> There is a peculiar thing about pytest: the version of python used
> matters.  That's different than most python /usr/bin/* things.
>
> > and python[3]-sphinx.
>
> neither python-sphinx nor python3-sphinx ship anything in /usr/bin, so
> bad example.

They do, but indirectly: the files in /usr/bin are created by the
sphinx-common postinst script.

This is similar to alternatives, but we are not using alternatives directly
because Sphinx can import third-party Python code, and thus the Python
version matters.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Heads up about file name changes

2017-04-06 Thread Dmitry Shachnev
Hi Barry!

On Wed, Apr 05, 2017 at 04:53:54PM -0400, Barry Warsaw wrote:
> So far, I've seen this problem in python-babel and python-pika.  In both
> packages, d/rules tries to remove redundant files.  In babel's case it's
> license.txt[1] and in pika's case it's version_history.txt (same path
> pattern).  In both cases, these d/rules commands fail because the files now
> end in .rst.txt, not .txt.
>
> The fixes are easy of course, but this will probably affect many packages in
> DPMT so I wanted to give a heads up.

Thanks for this heads up! This is a change in Sphinx 1.5, added in
https://github.com/sphinx-doc/sphinx/pull/2454.

Sphinx now uses the original file name + sourcelink_suffix (.txt by default)
for files in _sources directory.

Another effect of the same change is that the projects with custom Sphinx
themes and templates now need to add SOURCELINK_SUFFIX option to
DOCUMENTATION_OPTIONS JS object, otherwise the search will not work (like it
is done in https://github.com/rtfd/sphinx_rtd_theme/commit/a5e0e304).

Sphinx 1.5 will be in experimental until the freeze ends, so we still have
time to file and/or fix the bugs.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Salvaging python-cassandra for Stretch

2017-04-06 Thread Dmitry Shachnev
Hi Thomas!

On Thu, Apr 06, 2017 at 05:49:15PM +0200, Thomas Goirand wrote:
> Hi Sandro and others,
>
> Sandro Tosi has left python-cassandra-driver in a bad state, which leads
> me to attempt to salvage it before it's too late. No harsh feeling, this
> happened to everyone of us, and we can all be busy. Though something
> must be done. Indeed, python-cassandra-driver suffers from #857298,
> which is an RC bug that will lead to AUTORM in 16 days. This will also
> remove openstack-trove, which I would like to avoid.
>
> As I don't want to repeat history and get a flame war started by an NMU,
> I'm in advance of a possible NMU upload, sharing the debdiff with the
> debian-python list. If Sandro agrees, or if there's a consensus in this
> list that it's appropriate, I'll NMU. Best would be if Sandro himself
> fixes the issue though.
>
> Attached is the debdiff. As you can see, I'm attempting to use the new
> system that creates -dbgsym, and transitioning to it. Of course, for
> this to happen, we will need the FTP masters to approve such change in a
> timely manner, and likewise with the release team unblock. If someone
> believe he has a better approach, let me know, though what I did is
> probably the safest way to fix #857298.

To be honest, I do not like your patch.

The -dbg package currently contains not only debug symbols, but also the
C extensions built for debug Python interpreter. And you are removing them
even on the platforms where they are successfully built.

In my opinion a better solution (for Stretch) would be just adding an
Architecture: field to the -dbg packages (and for Buster, porting the code
to support big endian architectures).

Also, even if you really wanted to switch to -dbgsym, there is no need to
keep the old -dbg packages for transition. You could use --dbgsym-migration
option of dh_strip instead.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Re: Moving off of git-dpm (Re: git-dpm breakage src:faker)

2017-02-07 Thread Dmitry Shachnev
On Tue, Feb 07, 2017 at 10:47:00AM +, Ghislain Vaillant wrote:
> I know the discussion is leaning towards replacing usage of git-dpm
> with gbp-pq. I have nothing against it but, since we are talking about
> solutions for a git-centric workflow, has anyone considered the dgit-
> maint-merge workflow [1]?
>
> [1] https://www.mankier.com/7/dgit-maint-merge

Quoting from that manpage:

| Debian modifications to the upstream source are squashed into a single diff,
| rather than a series of quilt patches.

No, please let’s not use this. (I am with ScottK here.)

The gbp-pq approach looks fine to me.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Call for testing: Sphinx 1.5

2017-01-22 Thread Dmitry Shachnev
On Fri, Dec 23, 2016 at 06:04:00PM +0300, Dmitry Shachnev wrote:
> With some delay (usual for me), Sphinx 1.5 is now available in experimental.
>
> [...]
>
> If everything goes well, I want to have Sphinx 1.5 included in Stretch.

After all, it looks like 1.5 will *not* be in Stretch (unless someone really
wants it and asks me about it).

I was waiting for Sphinx 1.5.2 bug-fix release, which was only released
today. This leaves me only 4 days to upload it to sid, which is not enough
to do the necessary testing.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Team upload for python-jedi

2017-01-22 Thread Dmitry Shachnev
Hi Ghislain,

On Sat, Jan 21, 2017 at 11:54:13AM +, Ghislain Vaillant wrote:
> "Drop DPMT from Uploaders (due to problems with multiple tarballs in
> git-dpm)"
>
> Then, the package is no longer team-maintained?

Personally I think we could allow such packages to remain in team, even if
they are not able to use git-dpm. But Piotr is an administrator, so his
opinion is more important here.

On Thu, Jan 19, 2017 at 05:57:17PM +, Ghislain Vaillant wrote:
> > For now you can just forget about git-dpm, get the sources manually and
> > copy the Debian directory from Git on top of them.
>
> Just to be sure, do you mean I should leave the repository alone and
> merge my work in a fresh import-dsc of the current package?

I did not mean it. You could just (I think) remove debian/.git-dpm and work
with plain git-buildpackage.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Team upload for python-jedi

2017-01-19 Thread Dmitry Shachnev
Hi Ghislain,

On Wed, Jan 18, 2017 at 05:53:05PM +, Ghislain Vaillant wrote:
> Ok, I have got a working package fixing the RC. However, whoever did
> the migration from svn to git forgot that the source tree was made of
> multiple tarballs (one for jedi, one for jedi-vim) and now the vim
> plugin package cannot be produced because of the missing sources [1].
>
> How I should proceed now?
>
> We could just drop the vim plugin package for now (it does not work
> anyway due to #841043), and consider introducing a new source package
> for it later. Afterall, they are separate projects on GitHub [2, 3].
>
> Otherwise, I guess the svn migration would have to be re-run? I have no
> idea how to do it, nor setting up git-dpm to use multiple tarballs.

The SVN to Git migration was done automatically. I think the script was
just not too smart to deal with multiple tarballs properly.

For now you can just forget about git-dpm, get the sources manually and
copy the Debian directory from Git on top of them.

Now it is too late to fix the DPMT migration script, but it may be not
too late to make sure the problem does not appear with PAPT.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Please help with creating pure Python 3 package (Was: Bug#848479: openmolar: Should Suggest the metapackage default-mysql-*)

2017-01-08 Thread Dmitry Shachnev
Hi Andreas,

On Sun, Dec 18, 2016 at 05:03:10PM +0100, Alberto Caso wrote:
> I could not reproduce the behavior you describe. Maybe your environment
> is messed?
>
> Here is what I get after removing your overrides (for full log see the
> attached file):
>
> [...]
> dh_auto_build -O--buildsystem=pybuild
> I: pybuild base:184: /usr/bin/python3 setup.py build
> running build
> running build_py
> creating /tmp/molar/openmolar/.pybuild/pythonX.Y_3.5/build/openmolar
> [...]
>
> The build does fail in the tests phase, but I does not look related to
> what you are experiencing. Instead it seems to need running setup.py
> makeuis in the build process.

I get the same result as Alberto. In a fresh sid pbuilder chroot, the build
goes correctly up to tests phase, with clean and build overrides removed.

The force_python3.patch seems to be also not necessary.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: PEP 384 (limited ABI)

2017-01-06 Thread Dmitry Shachnev
On Sun, Jan 01, 2017 at 10:31:56PM +0300, Dmitry Shachnev wrote:
> If the debug interpreters do not support normal abi3, maybe we can have
> another prefix for them, like abi3d?

It looks like I got it wrong, and there is no such thing as limited API/ABI
for debug interpreters:

/usr/include/python3.5dm/object.h:65:2: error:
 #error Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and 
Py_REF_DEBUG

So if a package is building extensions for debug interpreters, rebuilds for
new Python versions will be still needed.

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: PEP 384 (limited ABI)

2017-01-01 Thread Dmitry Shachnev
Hi Stefano!

On Sat, Dec 31, 2016 at 07:42:39PM +0200, Stefano Rivera wrote:
> cffi modules will also now use the limited ABI, where possible, so I've
> played with them a bit.
>
> > A) Build with only one Python 3 version and install the .so files with
> >foo.abi3.so filenames (so no rebuilds will be needed for Python updates);
>
> I think dh_python3 already has the necessary support for that.

I don’t see any mentions of this in dh-python code, apart from the tests…

Also, I think there is no (easy) way for dh_python3 to detect whether a built
.so file is using the limited ABI, so the renaming should be done manually.

> Just one thing to watch out for: python3-dbg builds will also use
> abi3.so, but aren't actually compatible.
>
> https://bugs.python.org/issue28401

Thanks for the link!

So, the debug interpreter tries to load the extensions from files prefixed
with abi3, but is not really compatible with abi3? That looks like upstream
bug…

If the debug interpreters do not support normal abi3, maybe we can have
another prefix for them, like abi3d?

Building for one normal interpreter and for all debug interpreters looks a
bit inconsistent to me (especially for PyQt where the build takes quite a
long time).

--
Dmitry Shachnev


signature.asc
Description: PGP signature


PEP 384 (limited ABI)

2016-12-31 Thread Dmitry Shachnev
Hi all, and happy holidays!

The new releases of SIP and PyQt are using the limited set of Python ABI [1]
defined in PEP 384 [2], so that the same .so files work with different Python
versions.

As there seems to be no PEP 384 support in dh_python3, I wonder if I should:

A) Build with only one Python 3 version and install the .so files with
   foo.abi3.so filenames (so no rebuilds will be needed for Python updates);
B) Do not change anything: build for all supported Python 3 versions and
   let dh_python3 rename the files;
C) Anything else?

I could not find any discussion of this PEP in Debian except a couple of
messages from 2010 [3].

[1]: https://www.riverbankcomputing.com/news/sip-419
[2]: https://www.python.org/dev/peps/pep-0384/
[3]: https://lists.debian.org/debian-python/2010/05/msg00103.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Call for testing: Sphinx 1.5

2016-12-23 Thread Dmitry Shachnev
Hi all,

With some delay (usual for me), Sphinx 1.5 is now available in experimental.

There are some incompatible changes, see the documentation [1] for details.

Please test your packages and make sure they build fine with this new version.
When in doubt, file a bug against src:sphinx.

Docutils 0.13 was also uploaded some time ago and broke some packages,
I filed bugs for some of those. If it broke your package too, please let
me know about that.

If everything goes well, I want to have Sphinx 1.5 included in Stretch.

The major remaining difference between our packaging and upstream is that
we have non-English search disabled, this needs some changes in snowball
which I am waiting for. Everything else should work like in upstream.

[1] http://www.sphinx-doc.org/en/1.5.1/changes.html#incompatible-changes

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Request for review and sponsorship for pydbus

2016-12-19 Thread Dmitry Shachnev
Hi Alberto!

On Mon, Dec 12, 2016 at 12:35:45AM +0100, Alberto Caso wrote:
> Hello all,
>
> I would be very grateful if someone could review my pydbus package:
>
> https://anonscm.debian.org/cgit/python-modules/packages/pydbus.git/
>
> Once it gets to a shape good enough to be uploaded, I will also need a
> sponsor for it.

Your package is in a good shape, I have just uploaded it to NEW.

Thanks for your work!

--
Dmitry Shachnev


signature.asc
Description: PGP signature


  1   2   3   >