ctype and dh_python3 extension rename
Hello, I am packaging the latest tomopy package.this software use ctype to open
some extensions during the import, but I have this error message.
>>> import tomopy
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/tomopy/__init__.py", line 63, in
from tomopy.misc.corr import *
File "/usr/lib/python3/dist-packages/tomopy/misc/corr.py", line 60, in
import tomopy.util.extern as extern
File "/usr/lib/python3/dist-packages/tomopy/util/extern/__init__.py", line 86,
in
from tomopy.util.extern.prep import *
File "/usr/lib/python3/dist-packages/tomopy/util/extern/prep.py", line 65, in
LIB_TOMOPY_PREP = c_shared_lib("libtomopy-prep")
File "/usr/lib/python3/dist-packages/tomopy/util/extern/__init__.py", line 69,
in c_shared_lib
raise ModuleNotFoundError(
ModuleNotFoundError: The following shared library is missing:
/usr/lib/python3/dist-packages/tomopy/util/extern/libtomopy-prep.soIndeed
during the build process this module was renamed into
libtomopy-prep.cpython-310-x86_64-linux-gnu.soSo my question is... how can I
solve this issue. - do not rename the extension - change the logic in order
to find the renamed extension. (I like it but where can I find the debian
modules helper which allows to do this).Thanks for your helpFrederic
Re: join the team
Hi, Nilson has requested to join on September 27th because I encouraged him to do so after handing in several Python packages. After at least one incomplete application, this application had the complete info that is requested by the team policy. Nobody in charge has reacted yet. This is a friendly reminder. Thanks for processing joining applications! Cheers, Bastian
Bug#1021954: RFP: git-xl -- git diff extension for Excel spreadsheets
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-python@lists.debian.org * Package name: git-xl Version : 0.5.1 Upstream Author : https://github.com/xlwings * URL : https://www.xltrail.com/git-xl * License : MIT Programming Lang: Python Description : git diff extension for Excel spreadsheets Git XL is an open-source Git command line extension for managing Excel workbook files in Git. The extension makes git diff work for Excel VBA (xls, xlt, xla, xlam, xlsx, xlsm, xlsb, xltx, xltm). Git XL does not require Excel as it works directly on the workbook file. With Git XL installed, Git can diff Excel VBA just like any other source code file. Git XL was previously called "git-xltrail". Possibly depends on the xlwings library: https://github.com/xlwings/xlwings ... which is an opencore thing, but might work well enough for most use cases (e.g. not for cloud documents) in the opensource version.
Bug#1021964: ITP: python-noseofyeti -- Module to create Python codec for tests using RSpec inspired DSL
Package: wnpp Severity: wishlist Owner: Scott Kitterman X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org * Package name: python-noseofyeti Version : 2.3.1 Upstream Author : Stephen Moore * URL : https://github.com/delfick/nose-of-yeti * License : MIT Programming Lang: Python Description : Module to create Python codec for tests using RSpec inspired DSL This is a project creates a custom Python codec that lets you write your tests using an RSpec inspired DSL (i.e. describe and it blocks). . It uses the fact that you can register a codec that is able to modify a Python file before executing it. Using this when Python imports a file with a particular encoding as the first line of the file it will be intercepted and potentially rewritten into something else before the import continues. . nose-of-yeti uses this technique to translate from the DSL it defines, into Python classes and functions that then will be executed by your test framework of choice. I plan to maintain this package as part of the Debian Python team. It is needed to run the tests for python-dict2xml, which are now provided in the upstream tarball.
beancount: updating to 2.3.5 and later
Hi team, Was trying to package beancount 2.3.5, it failed with this: > I: pybuild pybuild:326: chmod +x > /var/lib/sbuild/beancount/.pybuild/cpython3_3.10/build/beancount/tools/treeify.py > > /var/lib/sbuild/beancount/.pybuild/cpython3_3.10/build/beancount/tools/sheets_upload.py; > rm > /var/lib/sbuild/beancount/.pybuild/cpython3_3.10/build/beancount/scripts/setup_test.py > cd /var/lib/sbuild/beancount/bin; \ > for binary in *; do \ > if [ "X$binary" = "XBUILD" ]; then continue; fi ; \ > PYTHONPATH=$(cd /var/lib/sbuild/beancount; pybuild --print build_dir > --interpreter python3) \ > help2man \ > --name "$(grep $binary > /var/lib/sbuild/beancount/debian/manpages/whatis.txt | cut -f 2)" \ > --no-info \ > --help-option=-h \ > --version-string=2.3.5 \ > ./$binary > /var/lib/sbuild/beancount/debian/manpages/$binary.1 ; \ > done > help2man: can't get `-h' info from ./upload-to-sheets > Try `--no-discard-stderr' if option outputs to stderr > make[1]: *** [debian/rules:20: override_dh_auto_build] Error 1 > make[1]: Leaving directory '/var/lib/sbuild/beancount' > make: *** [debian/rules:13: binary] Error 2 > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status > 2 After a little investigation it's found to be beancount.tools.sheets_upload having changed to require google-auth-oauthlib in 2.3.4. It no longer depends on googleapi, which itself hasn't seen upload or development since mid-2020. Further on, beancount developement branch has non-core components moved to beanlabs [1], including bin/upload-to-sheets, removing beancount.tools.sheets_upload entirely [2]. Maybe we could start packaging beanlabs? 1: https://github.com/beancount/beanlabs 2: https://github.com/beancount/beancount/issues/654 -- Regards, Blair Noctis OpenPGP_signature Description: OpenPGP digital signature
