Re: Join the Python team
Hi Jose (2021.10.12_19:54:59_+) > My salsa login is jrivero-guest. I've read the policy at > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst, > looks good to me. Added, welcome. > The only point is that I don't have experience using pq > for the management of the patches (always used quilt) but does not sound > difficult to learn. pq is just a tool to turn a quilt series into a git branch and vice-versa. It's great for rebasing patches on new upstream releases. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: request to join python-team/packages group on salsa
Hi Afif (2021.10.04_02:18:30_+) > On 10/3/21 6:50 PM, Sandro Tosi wrote: > >> I sometimes need to add or make updates to python packages. Currently, I > >> just uploaded a newer upstream version of httpbin and I'd like to push > >> the changes to the git repository, which resides in python-team/packages. > > > > httpbin has been orphaned, so it appears as if this repo should be > > moved from the python-team to the debian namespace (only admins can do > > that). > > > > please let us know if you still want to join the team. > > > > I'd still like to join. Added, welcome. And sorry about the delay. SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join Debian Python Team
Hi Vasudev (2021.09.29_08:51:47_+) > I would like to reintroduce foolscap [1] which is part of DPT back to > unstable as it is a dependency for reintroducing tahoe-lafs which I used > to maintain earlier in Debian. Added you on Salsa, welcome to the team! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Phil (2021.09.29_05:37:20_+) > Hi all, I've been lurking on the list for a while as several important > applications I use are written in python and I hope to package e.g. > mautrix-signal. Right now if I am part of the team, I can help with > lexicon and backports. Added, welcome to the team! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Request to join the team
Hi Luiz (2021.09.19_11:02:13_+) > My Salsa login is lamaral, but my account is not activated yet. Once I > get salsa access, I will move the fbtftp repository there, as it > currently resides in my GitHub[2]. I sponsored fbtftp to NEW, we should move its repo into the team. Added you. Welcome to the team! SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Joining Debian Python team
Hi yokota (2021.09.20_03:04:31_+) > I want to join Debian Python team to help packaging "python-zeroconf" > to work "calibre" well. > Because "python-zeroconf" is required package to "calibre". > > Please add me (salsa: yokota) to Debian Python team. Added, welcome to the team (and sorry about the delay). SR -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: packaging help request: paths for build_py and build_scripts phases
Hi Jonathan,
* Jonathan Dowland [2021-10-18 11:04]:
Here, the scripts are copied to a path *not* rooted in <>.
So far as I can tell, both phases are normal parts of the
setuptools/distutils build lifecycle, and I haven't spotted anything
obviously non-standard about the way that is specified.
[...]
A BTS bug requesting the new version with some back-and-forth trying to
figure this out is
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988597
The main issue is the implicit upstream assumption that the tests
are run from the source root dir; I've had a similar problem with
tweepy and my solution was to make sure that the tests find
everything they need in the build folder, i.e. add the following
snippet to d/rules:
export PYBUILD_BEFORE_TEST=cp {dir}/trash-* {dir}/script/bump.py {build_dir}
export PYBUILD_AFTER_TEST=rm {build_dir}/trash-* {build_dir}/bump.py
The second line is needed so the extraneous stuff is not installed
with the built package. It's not very pretty, and hopefully someone
else has a better solution, but it gets the job done.
You'll also have to patch tests/run_command.py to run python3 and
add python3-psutils to your Build-Depends.
diff --git a/tests/run_command.py b/tests/run_command.py
index 2e31e11..746cdad 100644
--- a/tests/run_command.py
+++ b/tests/run_command.py
@@ -17,7 +17,7 @@ def run_command(cwd, command, args=None, input='', env=None):
if args == None:
args = []
command_full_path = os.path.join(base_dir, command)
-process = subprocess.Popen(["python", command_full_path] + args,
+process = subprocess.Popen(["python3", command_full_path] + args,
stdin=subprocess.PIPE,
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
Cheers
Timo
PS. I worked around the missing fork
PPS. I thought about patching run_command.py to use the scripts from
the source directory, but that will use the trashcli module from the
source tree, not from the build tree, and contaminate the source tree
with __pycache__ folders.
--
⢀⣴⠾⠻⢶⣦⠀ ╭╮
⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │
⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄ ╰╯
signature.asc
Description: PGP signature
packaging help request: paths for build_py and build_scripts phases
Hello, I am attempting to package the latest upstream version of "trash-cli"¹, which differs quite a lot from the current package on the build side of things. https://github.com/andreafrancia/trash-cli The problem occurs during the post-build test phase. The tests cannot find the scripts they are trying to test. The build appears to be a standard python setuptools/distutils thing and the packaging is a standard dh --with python3 --buildsystem=pybuild. The Build runs /usr/bin/python3 setup.py build Which outputs the following (elided) running build_py creating /<>/.pybuild/cpython3_3.9/build/trashcli copying trashcli/fstab.py -> /<>/.pybuild/cpython3_3.9/build/trashcli ... So for the build_py phase, the destination for copied files is rooted under <>. The next build phase handles scripts: running build_scripts creating build creating build/scripts-3.9 copying and adjusting trash -> build/scripts-3.9 ... Here, the scripts are copied to a path *not* rooted in <>. So far as I can tell, both phases are normal parts of the setuptools/distutils build lifecycle, and I haven't spotted anything obviously non-standard about the way that is specified. Where is it that the build_py phase's path are specified or overridden such that they are correctly rooted under <>, and why isn't the same true of the build_scripts phase? I've pushed my WIP packaging to a temporary branch. https://salsa.debian.org/debian/trash-cli/-/tree/jmtd-update-0.21.7.24 A BTS bug requesting the new version with some back-and-forth trying to figure this out is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988597 Thank you in advance for any tips you can offer! Best wishes, -- Jonathan Dowland ✎j...@debian.org https://jmtd.net
