Re: PySNMP asyncio backend unusable in Debian 12 (needs stable update?)
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 ! 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. 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. 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 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. Adam.
Re: PySNMP asyncio backend unusable in Debian 12 (needs stable update?)
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. On 9/12/23 18:10, tho...@goirand.fr wrote: Hi, Quickly from my phone... Of course, we can update Stable with targeted patches (only: no new upstream release except in very rare cases). I can take care of the update tomorrow, though the next point release is in a few month from now. Also note that I uploaded all 4 pysnmp/asn1 modules from lextudio. Is your patch from them ? Cheers, Thomas Goirand (zigo) On Sep 12, 2023 5:52 PM, Adam Cecile wrote: Hello, Package python3-pysnmp4 is partially unusable in Debian 12 because its asyncio backend is using @asyncio.coroutine decorator that has been removed from Python 3.11. It is, imho, quite a serious issue, as any code using PySNMP4 on a machine will stop working after upgrading from Debian 11 to Debian 12 (my case). I'm not aware of how Debian stable updates work, but I think we should consider making an exception for that. I prepared a patched package version using backported patch from new upstream (previous maintainer passed away) and had to deal with an upstream bug too. Now it works again and I added all information to the Debian bug report: https://bugs.debian.org/1051774 The fix is quite safe as it impacts only asyncio backend, and current version is not importable at all so I do not see how it could lead to any regression. What is your opinion about this ? Best regards, Adam.
PySNMP asyncio backend unusable in Debian 12 (needs stable update?)
Hello, Package python3-pysnmp4 is partially unusable in Debian 12 because its asyncio backend is using @asyncio.coroutine decorator that has been removed from Python 3.11. It is, imho, quite a serious issue, as any code using PySNMP4 on a machine will stop working after upgrading from Debian 11 to Debian 12 (my case). I'm not aware of how Debian stable updates work, but I think we should consider making an exception for that. I prepared a patched package version using backported patch from new upstream (previous maintainer passed away) and had to deal with an upstream bug too. Now it works again and I added all information to the Debian bug report: https://bugs.debian.org/1051774 The fix is quite safe as it impacts only asyncio backend, and current version is not importable at all so I do not see how it could lead to any regression. What is your opinion about this ? Best regards, Adam.
Re: Tiledb-py fails to build (Was: tiledb: uses atomic operations, but is not linked to libatomic)
Hello,
It seems unittests are running against very new pandas version that wants
pyarrow (but it does not seems to be available in the archive).
Can you check while self.use_arrow evaluate to True ? That's mostly the root
cause of the failure.
I'll try to have a look when I'll be in front of my computer.
Regards, Adam.
On March 25, 2023 2:55:39 PM GMT+01:00, Andreas Tille wrote:
>Hi,
>
>as you can read in the bug log, there was an upload of a new version of
>tiledb a couple of hours before it has migrated to testing. Thus the
>package remains affected by a testing removal (together with its two
>reverse dependencies tiledb and genomicsdb). To follow the freeze
>policy I reverted the version bump and NMUed tiledb
>2.15.0really2.14.1-0.1 to experimental (since the maintainer did not
>responded).
>
>As we can see tiledb-py does not build against tiledb 2.15.0[1]
>
>I've now forced (Build-)Depends to
> tibtiledb-dev (>= 2.15.0really2.14.1~)
>but it seems Salsa CI autopkgtest does not respect the setting
>
>variables:
> # Build against tiledb in experimental
> RELEASE: 'experimental'
>
>and thus the autopkgtest log does not reproduce the error I've got
>in my local build:
>
>...
>
>=== FAILURES
>===
>___ TestNumpyToArray.test_from_numpy_empty_str[1-0]
>
>
>self =
>empty_str = '', num_strs = 1
>
>@pytest.mark.parametrize("empty_str", ["", b""])
>@pytest.mark.parametrize("num_strs", [1, 1000])
>def test_from_numpy_empty_str(self, empty_str, num_strs):
>uri = self.path("test_from_numpy_empty_str")
>np_array = np.asarray([empty_str] * num_strs, dtype="O")
>tiledb.from_numpy(uri, np_array)
>
>with tiledb.open(uri, "r") as A:
>assert_array_equal(A[:], np_array)
>if has_pandas():
>> assert_array_equal(A.query(use_arrow=True).df[:][""], np_array)
>
>tests/test_libtiledb.py:3356:
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>_.
>/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:192: in
>__getitem__
>return self if self.return_incomplete else self._run_query()
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>_.
>
>self =
>
>def _run_query(self) -> Union[DataFrame, Table]:
>if self.pyquery is not None:
>self.pyquery.submit()
>
>if self.pyquery is None:
>df = DataFrame(self._empty_results)
>elif self.use_arrow:
>with timing("buffer_conversion_time"):
>> table = self.pyquery._buffers_to_pa_table()
>E ModuleNotFoundError: No module named 'pyarrow'
>
>/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:329:
>ModuleNotFoundError
>___ TestNumpyToArray.test_from_numpy_empty_str[1-1]
>
>
>self =
>empty_str = b'', num_strs = 1
>
>@pytest.mark.parametrize("empty_str", ["", b""])
>@pytest.mark.parametrize("num_strs", [1, 1000])
>def test_from_numpy_empty_str(self, empty_str, num_strs):
>uri = self.path("test_from_numpy_empty_str")
>np_array = np.asarray([empty_str] * num_strs, dtype="O")
>tiledb.from_numpy(uri, np_array)
>
>with tiledb.open(uri, "r") as A:
>assert_array_equal(A[:], np_array)
>if has_pandas():
>> assert_array_equal(A.query(use_arrow=True).df[:][""], np_array)
>
>tests/test_libtiledb.py:3356:
>/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:192: in
>__getitem__
>return self if self.return_incomplete else self._run_query()
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>_.
>
>self =
>
>variables:
> # Build against tiledb in experimental
> RELEASE: 'experimental'
>def _run_query(self) -> Union[DataFrame, Table]:
>if self.pyquery is not None:
>self.pyquery.submit()
>
>if self.pyquery is None:
>df = DataFrame(self._empty_results)
>elif self.use_arrow:
>with timing("buffer_conversion_time"):
>> table = self.pyquery._buffers_to_pa_table()
>E ModuleNotFoundError: No module named 'pyarrow'
>
>/usr/lib/python3/dist-packages/tiledb/multirange_indexing.py:329:
>ModuleNotFoundError
>__ TestNumpyToArray.test_from_numpy_empty_str[1000-0]
>__
>
>self =
>empty_str = '', num_strs = 1000
>
>@pytest.mark.parametrize("empty_str", ["", b""])
>@pytest.mark.parametrize("num_strs", [1, 1000])
>def test_from_numpy_empty_str(self, empty_str, num_strs):
>uri = self.path("test_from_numpy_empty_str")
>np_array = np.asarray([empty_str] * num
>
>=== FAILURES
>===
>___ TestNumpyToArray.test_from_numpy_empty_str[1-0]
>
>
>self =
>empty_str = '', num_strs = 1
>
>
Re: status of python-cx-oracle in Debian?
Hello, Yo be honest I did not even recalled having uploaded this one to salsa and if d/control is not properly set, please consider its under DPMT control and feel free to take over from where I left it. Best regards, Adam. On November 19, 2021 5:14:14 PM GMT+01:00, Joe Nahmias wrote: >Hello, > >I am currently in need of the cx_Oracle python module. I see the salsa repo [0] >is gathering dust at the moment... Are you still working on packaging it for >Debian? Would it be okay if I took over and worked on it under the Debian >Python Team? > >BTW - I note that since it requires the oracle client, it should go to contrib, >not main. Please let me know if you understand otherwise. > >Thanks, >--Joe > >0: https://salsa.debian.org/python-team/packages/python-cx-oracle
Re: RFS: python-fastjsonschema: validation of JSON documents by JSON schema drafts 04/06/07
Thank you, indeed I forgot to remove that part, good catch On October 7, 2021 9:50:19 PM GMT+02:00, Scott Talbert wrote: >On Thu, 7 Oct 2021, Adam Cecile wrote: > >> Hello >> >> Still looking for sponsoring ! >> >> Thanks >> >> On September 28, 2021 10:20:25 PM GMT+02:00, "Adam Cécile" >> wrote: >> >> 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. > >I tweaked the copyright file to remove the paragraph for the >json-schema-test-suite files and uploaded. > >Scott
Re: RFS: python-untokenize: Untokenize transforms tokens into source code
Hello Still looking for sponsoring ! Thanks On September 28, 2021 10:47:27 PM GMT+02:00, "Adam Cécile" wrote: >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. >
Re: RFS: python-fastjsonschema: validation of JSON documents by JSON schema drafts 04/06/07
Hello Still looking for sponsoring ! Thanks On September 28, 2021 10:20:25 PM GMT+02:00, "Adam Cécile" wrote: >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: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
For the record, I usually go for github upstream because (as state by other) documentation and unittests are usually missing from pypi. And IMHO, no package should be uploaded without running unittest :-) Regards, Adam On September 29, 2021 9:44:13 PM GMT+02:00, Dominik George wrote: >Hi, > >> 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. > >uploaded, thanks for your contribution! > >One note: I'd consider watching for PyPI instead of GitHub. > >Cheers, >Nik >
Re: RFS: python-click-default-group: Extension for Python click adding default subcommand to group
Hi, Great, I'll be available tomorrow (UTC+2) if you want me to do some changes. Adam. On September 28, 2021 11:38:15 PM GMT+02:00, Dominik George wrote: >Hi, > > >> 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. > >I will check it tomorrow. > >-nik
Bug#980452: ITP: aiohttp-retry -- Simple aiohttp retry client
Package: wnpp Severity: wishlist Owner: Adam Cecile * Package name: aiohttp-retry Version : 2.3 Upstream Author : Dmitry Inyutin * URL : https://github.com/inyutin/aiohttp_retry * License : Expat Programming Lang: Python Description : Simple aiohttp retry client This library add retrying feature to aiohttp HTTP client and provides an API being exactly the same as original ClientSession object. . You can define your own timeouts logic or use: - ExponentialRetry with exponential backoff - RandomRetry for random backoff - ListRetry with backoff you predefine by list I intend to maintain this package within the Debian Python Modules Team.
Re: How to find DD member to perform reviews and uploads
Hello Utkarsh, I fixed the changelog issue, sadly salsa is unresponsive atm so I it's not pushed yet. For the autodep8 issue I know what is going on: For some reasons Django packages, especially Django REST Fmwrk does not follow standard naming scheme so expected package import name is not correct. Can you help me understanding how to fix this properly ? Regards, Adam. Le 11 février 2020 23:09:43 GMT+01:00, Utkarsh Gupta a écrit : >Hi Adam, > >On Sun, Feb 9, 2020 at 9:13 AM Adam Cecile wrote: >> >https://salsa.debian.org/python-team/modules/djangorestframework-api-key > >Could you quickly update d/ch entry date? >timewarp-standards-version (2020-01-06 < 2020-01-20) -> 4.5.0 was >released afterwards :) > >Also, there's an autopkgtest failure :( >Here's how you can reproduce: >autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild > >Relevant logs: >Testing with python3.8: >Traceback (most recent call last): > File "", line 1, in >ModuleNotFoundError: No module named 'djangorestframework_api_key' > >Let me know once you fix them, I'll be happy to upload! :) > > >Best, >Utkarsh
Re: How to find DD member to perform reviews and uploads
On 2/11/20 9:45 PM, Thomas Goirand wrote: On 2/11/20 12:12 PM, Ondrej Novy wrote: Hi, út 11. 2. 2020 v 11:02 odesílatel Adam Cecile mailto:acec...@le-vert.net>> napsal: Bringing the package into the archive would be doable, if someone get legal contacts at LSI and asked for official statement authorizing Debian to redistribute their binary. I did this in the past for another package but I cannot guarantee any success. be careful with this. See DFSG 8 :) This is irrelevant. We're discussing uploading something into non-free, and as you know, non-free is not part of Debian, and the DFSG doesn't apply there. Cheers, Thomas Goirand (zigo) Btw Thomas, python-cassandra has been fixed and ready for uploading if you're still interested in. Adam.
Re: How to find DD member to perform reviews and uploads
On 2/11/20 9:51 AM, Thomas Goirand wrote: On 2/9/20 3:12 PM, Adam Cecile wrote: Hello Debian-Python, I have a couple of package ready on Salsa but my RFS sent here remained unanswered. So I'm asking again for your help again ! Here is a list of package waiting for uploads: https://salsa.debian.org/python-team/modules/djangorestframework-api-key https://salsa.debian.org/python-team/modules/aionotify https://salsa.debian.org/python-team/modules/python-fastjsonschema https://salsa.debian.org/python-team/modules/python-cassandra-driver https://salsa.debian.org/python-team/modules/python-sunrise Thanks in advance, Regards, Adam. Hi Adam, I've built and uploaded python-cassandra-driver. Thanks for your contribution to Debian. Do you still need sponsoring for the above? Also, thanks a lot for your work on megacli packaging, it's very useful. However, I haven't found the matching source packages. Do you also think it'd be possible to push these into the non-free repository of Debian? Do you even have some sources from upstream, or only binaries? I very much need this for my work (we use Dell LSI hardware RAID a lot), and my colleagues would love to have this through the official channel, rather than from your unofficial repository. Your thoughts? Cheers, Thomas Goirand (zigo) Hello Thomas, It seems the package got rejected because I'm building an additional package (doc one). Anyway, please wait a bit I'll fix a couple of minor issues spotted by Onovy and we'll ask for an uploaded again. I'll also need sponsorship for others package but just like cassandra, I'll fix a few things first. Regarding megacli, no sources it's 100% proprietary tool from LSI and the license clearly state it's forbidden to redistribute by 3rd parties. But the hwraid repo is kinda popular and I never got any complaint by LSI because I think they understood it's useful and needed by their users. Bringing the package into the archive would be doable, if someone get legal contacts at LSI and asked for official statement authorizing Debian to redistribute their binary. I did this in the past for another package but I cannot guarantee any success. I got a few contacts with LSI people and they have been helpful, in an unofficial way but I'm not sure it'll be the same for a public statement. Regards, Adam.
Re: How to find DD member to perform reviews and uploads
Hi, Here we go, I set up a bouncer again so I won't miss messages while being away. My nickname is "acecile". Regards, On 2/9/20 4:28 PM, Ondrej Novy wrote: Hi, ne 9. 2. 2020 v 15:13 odesílatel Adam Cecile <mailto:acec...@le-vert.net>> napsal: I have a couple of package ready on Salsa but my RFS sent here remained unanswered. best way how to get help is to join IRC and add that packages to channel topic. Thanks for your work for Debian and DPMT team. -- Best regards Ondřej Nový
How to find DD member to perform reviews and uploads
Hello Debian-Python, I have a couple of package ready on Salsa but my RFS sent here remained unanswered. So I'm asking again for your help again ! Here is a list of package waiting for uploads: https://salsa.debian.org/python-team/modules/djangorestframework-api-key https://salsa.debian.org/python-team/modules/aionotify https://salsa.debian.org/python-team/modules/python-fastjsonschema https://salsa.debian.org/python-team/modules/python-cassandra-driver https://salsa.debian.org/python-team/modules/python-sunrise Thanks in advance, Regards, Adam.
RFS: aionotify: Simple, asyncio-based inotify library for Python
Hello, I just imported this Python module to Salsa. I was already using it in several projects and I though it might be useful to others. Could you check the package https://salsa.debian.org/python-team/modules/aionotify/ and upload it if it looks ok ? Regards, Adam.
RFS: djangorestframework-api-key: API key permissions for Django REST Framework
Hello, I just finished packaging this Python module for my own projects and I'd like to get it into the archive. Could you check the package https://salsa.debian.org/python-team/modules/djangorestframework-api-key and upload it if it looks ok ? It's working fine here in production but sadly I cannot use the builtin unittests because they require a working Django REST server. I will probably later enable this as a custom build profile so I can run the integrations tests on my laptop before uploading newer version. Regards, Adam.
Joining the Debian Python Modules Team
Hello Debian Python people, I would like to join Debian-Python modules team because I want to get involved back in Debian especially for Python stack (mostly asyncio / big-data related). I'd start with aiomysql [0] because Ruben Undheim expressed interest in it. My Salsa login is acecile-guest. I have of course read team poliy at [1] and fully agree. Thanks a lot in advance, Regards, Adam [0] https://mentors.debian.net/package/aiomysql [1] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
Re: Allow installation on buster of a package not supporting 3.7 (async/await syntax error when generating bytecode)
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, >-- >Nicolas Dandrimont > >BOFH excuse #227: >Fatal error right in front of screen -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: RFS: jupyter components
Hello Gordon, We are really interested in getting notebook 5, any progress on this ? Is it possible to get your not-uploaded-yet packages (I did not find them on mentors.debian.net). Thanks in advance, Best regards, Adam. On 08/28/2017 11:56 PM, Gordon Ball wrote: Hello The following packages should be ready for upload, if someone would be willing to check and sponsor the uploads: * ipython 5.4.0-1 IPython 6.x is now available, but is python3 only. For the moment, the existing ipython source package will be the 5.x series, and at some point it will cease to build the python3 package and a new source package based on ipython6 will take that binary over. Question for previous packagers: we currently ship a custom ipython.sh script as /usr/bin/ipython[3] instead of using the entry-points script that would otherwise be installed, but I can't find the rationale documented - faster startup? * jupyter-console: 5.2.0-1 I tried out converting this one to gbp-pq (all others are still in git-dpm format) * jupyter-core: 4.3.0-1 * nbformat 4.4.0-1 * jupyter-client: 5.1.0-1 The remaining packages are currently blocked: * nbconvert: 5.2.1 waiting on python-pandocfilters >= 1.4 (already in dpmt git, but not yet uploaded) * jupyter-notebook: 5.0.0 working package available, but with some functionality limited due to unpackaged or out-of-date javascript libraries Thanks Gordon
