Re: RFS: symfit/0.5.2-1 [ITP] -- Symbolic Fitting in Python, fitting as it should be
Hi Drew, > Hi Stephan, you haven't got a doc package in place yet for symfit. But > the docs build cleanly, the template generated for dh_make gives the > pattern for python packages like this. Would you like to add this > before update? > > Setting up debian/tests can be useful too. With pytests it shouldn't be > hard to do. (2 tests currently fail but should be straightforward to fix > or work around). > > debian/tests can be added later, but probably a good idea to add the doc > package now. Otherwise it'll be waiting in the NEW queue twice. > > Drew I'm looking into the tests right now, but can you give me some hints on the doc package? I don't get it to build, I'm not really familiar with pybuild. > Nice work. I can sponsor this. Thanks! Where should I maintain this package? In the DPMT? Cheers, Stephan
Re: RFS: symfit/0.5.2-1 [ITP] -- Symbolic Fitting in Python, fitting as it should be
> Heh no need for encryption, no secrets here :) > (not replying encrypted since I'm on webmail which doesn't gave gpg > configured. I took off cc:debian-python.) I think protonmail does that even without me doing anything, it wasn't intended anyway. > You shouldn't need to fiddle (much) with pybuild. Use dh_make to > generate a debian folder, check what it puts in. It's only a few lines > needed, you can copy over from the dh_make-generated debian/ to the > debian/ that you've made. Using the template gives me: > dh_sphinxdoc: warning: Sphinx documentation not found And results in an empty doc package When rebuilding the documentation as described in the rules template, I get: > NotImplementedError: Unknown node: CodeAreaNode The only thing I found regarding that issue was https://github.com/sphinx-doc/sphinx/issues/7816, which isn't really helpful. If you have an idea and want to point it out in the code, you can comment on my salsa repo: https://salsa.debian.org/stephanlachnit/symfit/-/commit/b75fe5f301dd507994957701f5f46ab5e6e88e84 > Since this is a maths tool, you could place it in the Debian Science > team. DMPT could work, but probably science developers are more likely > to be actually using it. Alright, I put it on their salsa account as soon as it's ready. Cheers, Stephan
Re: RFS: symfit/0.5.2-1 [ITP] -- Symbolic Fitting in Python, fitting as it should be
On 2020-06-24 01:57, Stephan Lachnit wrote:
-BEGIN PGP MESSAGE-
Version: ProtonMail
wcFMAysU9YM04hChAQ//cTKRX2ovcrbEV2oEgObcf8/pwIk/p6l0K7sqm2Im
NHnk1mPaSg1VqIdK+QlqGgomxU/oZDSicnjRI1a7dNRvbJuOvMDKMqacQUIc
zJWXCdOxBw361ut+2LrcbwgaMFcW/fuXPbFFt3k5cWNVv8+qBtSFq/VwsSMs
Heh that's kind of funny if your mail client is automatically encrypting
to me, but not encrypting to the mailing list. Seems to defeat the point
of encrypting... still, we should all be using it more.
It looks like you've added --with sphinxdoc to dh, but haven't actually
triggered the doc build itself (dh --with sphinxdoc doesn't *build* the
docs, it just manages the installation of them, and the value of
${sphinxdoc:Depends})
See the commented part of dh_make's debian/rules. Uncomment to get the
docs building.
Or you can also do it just with cd docs; make html. I'm not sure why
dh_make uses a more complicated method. Maybe not all python modules
provide a docs/Makefile.
Building man pages fails (with either method), but you don't need a
manpage for a python module with no binary executable. HTML is enough.
Note the doc-base file in the dh_make templates. It's nice to use this
to register the docs (cf. file:///usr/share/doc/HTML/index.html)
Drew
Moving utility scripts from one package to another
Hi, I have a couple of (mostly library) Python packages, src:wxpython3.0, which was Python 2 only and has been recently RM'd and src:wxpython4.0 which is Python 3 only. wxpython3.0 had a subpackage, python-wxtools, which contained a few utility scripts. wxpython4.0 can also provide those utility scripts, so I just wanted to confirm what I need to do to make that happen safely when adding a python3-wxtools package to replace python-wxtools. 1) python3-wxtools should Replace:, Provide:, and Conflict: python-wxtools, correct? 2) Should python3-wxtools even be named with the python3- prefix if it is not providing a Python library? I'm thinking not. Thanks, Scott
Re: Moving utility scripts from one package to another
Hi Scott (2020.06.23_21:56:04_+) > I have a couple of (mostly library) Python packages, src:wxpython3.0, which > was Python 2 only and has been recently RM'd and src:wxpython4.0 which is > Python 3 only. wxpython3.0 had a subpackage, python-wxtools, which > contained a few utility scripts. wxpython4.0 can also provide those utility > scripts, so I just wanted to confirm what I need to do to make that happen > safely when adding a python3-wxtools package to replace python-wxtools. > > 1) python3-wxtools should Replace:, Provide:, and Conflict: python-wxtools, > correct? Yep. Essentially this is a rename and you're following this method: https://wiki.debian.org/RenamingPackages#Clean_slate_method > 2) Should python3-wxtools even be named with the python3- prefix if it is > not providing a Python library? I'm thinking not. Yeah, probably not. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Bug#962919: RFS: spyne/2.13.15-0.1 [NMU, RC]
Hi, one week has passed and no new spyne package has been released. Please consider sponsoring the version at https://mentors.debian.net/debian/pool/main/s/spyne/spyne_2.13.15-0.1.dsc Bastian
Re: Python-trezor
Hi Michael, I contacted Tristan and Richard some months ago. Tristan said to me he was going to change the maintainer field on d/control. But lookin on the salsa repository, that was not updated. I've already contacted them again. I'll be very happy to update python-trezor, but IMO the maintainer (or uploader) must change the d/control files. At least one other DD DPMT team member give me the ok to go ahead. Cheers, Arias Emmanuel @eamanu http://eamanu.com El dom., 21 de jun. de 2020 a la(s) 14:21, Michael Robinson (mich...@felinefamily.org) escribió: > > Hello again, > > The forthcoming upgrade of Electrum to 4.x will require python-trezor0.12 to > maintain trezor compatibility. Is there someone that can upload that update? > I tried contacting Richard Ulrich and Tristan Seligmann but haven’t been able > to make contact. > > The primary roadblock to 0.12 was python-libusb1, which is now upgraded to > 1.8 and should be compatible. > > Any help you can provide would be greatly appreciated > > Mike
