Re: Transitionning to the lextudio pysnmp / pyasn1 ecosystem
On 9/15/23 09:38, Thomas Goirand wrote: Hi, As you may know, the upstream author for pysnmp passed away last year. As a result, the whole suite was forked by "lextudio". I packaged it, and the result is this list of source packages: python-pyasn1-lextudio python-pyasn1-modules-lextudio python-pysmi-lextudio python-pysnmp-lextudio Appart from the OpenStack packages, here's the list of reverse dependencies for the old python3-pysnmp4 binary package: * patator * pdudaemon * pysmi * snimpy * changeme * python3-snimpy * python3-pysnmp4-apps * python3-pysnmp4-mibs * snmpsim My plan is to file bugs against these packages, asking to transition to the newer packages. We're just below the threshold for asking debian-devel about mass bug-filling, so I figured out I would only send a mail to the Python list. Do you guys approve my plan? Should we make transition dummy packages? Also to Adam Cécile: can you make your pull request against the new Salsa repository? Hello, Regarding my lexstudio patch to fix double awaitable bug ? Cheers, Thomas Goirand (zigo)
Re: PySNMP asyncio backend unusable in Debian 12 (needs stable update?)
On 9/13/23 17:42, Thomas Goirand wrote: On 9/13/23 13:43, Adam Cecile wrote: On 9/13/23 12:55, Thomas Goirand wrote: On 9/12/23 18:16, Adam Cecile wrote: Hello, No hurry, I think we might want to wait for upstream to respond to my PR regarding double awaitable fix. It is indeed lextudio upstream that took over the PySNMP package and all patches are coming from us (except mine ofc). Regards, Adam. Because it messes up the order in which people normally read text. Why is top-posting such a bad thing? Top-posting. What is the most annoying thing in e-mail? Hello, you started first ! LOL ! :) Well, I was on my phone, sorry for that ... :P Thanks! :) I tried applying your patch at https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commit/88d40f1225de8f7b42413b56206b41a6155fcf09 Unfortunately, it doesn't apply on top of 4.4.12-2, which is the current version of the package (in Bookworm, Unstable and Testing). Would you be able to rebase your patch on top of 4.4.12-2? Then I'll do the work to get this into Bookworm (and Unstable/Testing). Cheers, Thomas Goirand (zigo) Yes that's expected. Well, how can I then apply it to the version in Bookworm? Hello, Soory for the delay, I don't get the question, bookworm version is the same as unstable at the moment so my debian/4.4.12-3 branch also works: https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commits/debian/4.4.12-3 If you want only the full patch fixing asyncio, you can find it as debian/patch: https://salsa.debian.org/acecile-guest/python-pysnmp4/-/blob/debian/4.4.12-3/debian/patches/0003-Merge-lextudio-upstream-fork-patch-related-to-asynci.patch This commit is only to fix double awaitable "new" upstream bug. It depends on a large amount of backported commits to fix asyncio / Python 3.11 support. Could you backport it to 4.4.12-2 as in Bookworm and Unstable? As I wrote already, I already packaged python-pysnmp-lextudio, which is currently in the NEW queue. I will be happy to apply your patch in there, but IMO, we should treat pysnmp-lextudio as a different source and binary package (my binary conflicts with python3-pysnmp4), because the dependency chain is very different. Yes it's already done, see above. You can see here a branch created from upstream 4.4.12 tag with asyncio patches cherry-pick from new upstream master: https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commits/4.4.12+cherry-pick-asyncio-lextudio-fixes/ It has then been squashed into a single debian/patch: https://salsa.debian.org/acecile-guest/python-pysnmp4/-/commit/a5f17d27c7813dbdb64cdf674d1855a77c3eb0f0 Ah, super cool! It's too late for today (have to go back home), so I'll work on this tomorrow. Thanks a lot for your contrib. So, all good? BTW, we've been using your MegaCli repo (we mirror it), and I also would like to thank you for this. :) Thanks! Sadly I miss time to take care of it, but no matter how old and badly written was the Python code, it still works flawlessly :-) Cheers to LSI/Broadcom for not breaking tools and output format btw. I made my own forked repository because I'm unsure how we should proceed, but I can easily push the debian/4.4.12-3 tag to the regular Python module repository on Salsa. 4.4.12-3 will be for Unstable. For Stable, it's going to be something like 4.4.12-2+deb12u1, as per the normal process, and it will have to be (pre-)approved by the Debian Stable release team by filling a bug against release.debian.org. No worries, I do understand that Debian procedures are not easy to understand, though I'm happy to explain if you need. Cheers, Thomas Goirand (zigo)
RFS: python-untokenize: Untokenize transforms tokens into source code
Hello, Could someone please upload this little package ? It's a indirect (docformatter dep) dependency of xsdata, an awesome XML/dataclasses library I'd like to get into the archive. ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976441 Salsa: https://salsa.debian.org/python-team/packages/python-untokenize Thanks in advance, Adam.
RFS: python-click-default-group: Extension for Python click adding default subcommand to group
Hello, Could someone please upload this little package ? It's a dependency of xsdata, an awesome XML/dataclasses library I'd like to get into the archive. ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976443 Salsa: https://salsa.debian.org/python-team/packages/python-click-default-group Thanks in advance, Adam.
RFS: python-fastjsonschema: validation of JSON documents by JSON schema drafts 04/06/07
Hello, Is there someone willing to upload this package ? It was waiting for json-schema-test-suite to be uploaded as a separated package, that I did a while ago and I just verified the package is in good shape and updated to latest upstream patch release. ITP: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948968 Salsa: https://salsa.debian.org/python-team/packages/python-fastjsonschema Thanks in advance, Best regards, Adam.
Re: Allow installation on buster of a package not supporting 3.7 (async/await syntax error when generating bytecode)
Just tried but it's not working:
I wrote:
dir|3.7-|/usr/lib/python3/dist-packages/tensorflow/
But installing the package gives:
Traceback (most recent call last):
File "/usr/bin/py3compile", line 290, in
main()
File "/usr/bin/py3compile", line 266, in main
e_patterns = get_exclude_patterns()
File "/usr/bin/py3compile", line 93, in get_exclude_patterns
for type_, vers, dname, pattern in get_exclude_patterns_from_dir():
File "/usr/share/python3/debpython/__init__.py", line 22, in __call__
self.cache[key] = self.func(*args, **kwargs)
File "/usr/bin/py3compile", line 68, in get_exclude_patterns_from_dir
type_, vrange, dname, pattern = line.split('|', 3)
ValueError: not enough values to unpack (expected 4, got 3)
I'm wondering if the "dir" type is actually supported: "re" type
contains the appropriate number of fields.
Regards, Adam.
On 11/9/18 6:43 PM, Adam Cecile wrote:
Thanks a lot Nicolas !
It looks perfect, I made the modification but haven't been able to
test it yet.
Le 8 novembre 2018 14:26:07 GMT+01:00, Nicolas Dandrimont
a écrit :
Hi!
* Adam Cécile [2018-11-08 09:15:59 +0100]:
Hello list, I have a package working perfectly fine on Pyrhon
3.6 but using async/await methods so it cannot work on python
3.7 at the moment. During package compilation, I popd 3.7 from
supported version returned by py3version and it allows me to
build the package just fine: Problem: I cannot install it.
Despite 3.7 was not "enabled" during build, when installing
debian helpers try to compile bytecode for both 3.6 and 3.7
and fails. Is there any way to workaround that ?
You can use the bcep (bytecompile exception pattern) mechanism. The
documentation can be found in dh_python3(1)[1] and
/usr/share/doc/dh-python/README.PyDist, and you can find some examples in
codesearch.
[1]https://manpages.debian.org/unstable/dh-python/dh_python3.1.en.html#bcep_files
HTH,
--
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez
excuser ma brièveté.
Allow installation on buster of a package not supporting 3.7 (async/await syntax error when generating bytecode)
Hello list, I have a package working perfectly fine on Pyrhon 3.6 but using async/await methods so it cannot work on python 3.7 at the moment. During package compilation, I popd 3.7 from supported version returned by py3version and it allows me to build the package just fine: Problem: I cannot install it. Despite 3.7 was not "enabled" during build, when installing debian helpers try to compile bytecode for both 3.6 and 3.7 and fails. Is there any way to workaround that ? Thanks in advance, Adam. PS: I'm aware this is transitional and the package MUST support 3.7, but I kinda need a fast workaround, like right now.
Packaging ElasticSearch (different version for different server API version)
Hello, At the moment, python-elasticsearch is only available in version 1.x [1], which is pretty useless as it's intended to be used against ElasticSearch 1.x servers. The main problem is that the client is disitributed following multiple branches, one for servers running version 1.x, another for version 2.x and the last one for 5.x but I really think Debian should provide high level Python library for ElasticSearch (next goal is to get the DSL in [3]). How would you handle that ? For work purpose I created python-elasticsearch2 and python3-elasticsearch2 as well as python-elasticsearch5 and python3-elasticsearch5. It's working just fine, and I even think it's a lot saner as I can simply do "from elasticsearch5 import ElasticSearch" instead "from elasticsearch2 import ElasticSearch" to test my code against a new ES5 servers cluster.Do you think it's acceptable to "change" upstream behavior like this ? Does it worth an alternative, to provide a default unversionned "elasticsearch" module ? Thanks in advance for your answer, Best regards, Adam. [1] https://packages.debian.org/search?keywords=python-elasticsearch [2] https://elasticsearch-py.readthedocs.io/en/master/#compatibility [3] https://elasticsearch-dsl.readthedocs.io/
