Hi Edward,
On 2024-07-23 13:25:53, Edward Betts wrote:
I am proposing the addition of Home Assistant, a Python-based smart home
platform, to Debian. Home Assistant requires extensive hardware integrations
and thus has a significant number of Python module dependencies.
Upon review, I've identif
Hi,
On 2024-06-13 13:13:33, Pierre-Elliott Bécue wrote:
Andrey Rakhmatullin wrote on 13/06/2024 at 12:48:36+0200:
I'm always hesitant to look at Python module RFSes because on one hand I
would like all of them to be in the team but on the other hand I'm not
sure if it makes sense to write "ple
Dear Helmut,
On 04.11.22 10:36, Helmut Grohne wrote:
Would someone handle dnstwist, which is the only remaining dependency?
I opened a corresponding upstream request:
https://github.com/elceef/dnstwist/issues/170
Peter
Hi Andrey,
thanks for sharing your thoughts.
On 08.12.20 21:43, Andrey Rahmatullin wrote:
You didn't explain what actual problems do you have, but
https://github.com/lark-parser/lark/issues/792 suggests that some way you
used was skipping some of the tests?
I am not familiar enough with Pytho
Dear Python experts,
in trying to update the python-lark package [0] to the most recent
upstream version, an interesting issue regarding unit tests showed up
[1]. Depending on how one runs unit tests they either fail or not. Tried
options are:
1. PYTHONWARNINGS=d pythonX -m unittest discover
Hi Frederic,
On 03.08.20 17:04, PICCA Frederic-Emmanuel wrote:
> I use sphinx, so my question is: do you know how to fix this issue
have a look at
https://bugs.debian.org/964013#35
and the following comment.
Best regards,
Peter
Dear DDs,
I prepared packaging for the parsing library python-lark (ITP bug
#941657). It is needed to bump the versions of prewikka [0] and
charliecloud [1]. The git repository is available on
https://salsa.debian.org/python-team/modules/python-lark
It would be great if someone could review the
Hi Simon,
thanks for your helpful input.
On 30.12.19 18:04, Simon McVittie wrote:
> There are two options:
>
> * If "lark" on PyPI is a dead project, or otherwise something that is never
> going to be useful to package in Debian for some reason, then perhaps it's
> safe for the lark parser t
to change the name to python-lark. But given the
PyPI name clash this is certainly not optimal either. So this seems to
be a particular unfortunate case.
Any advice is welcome!
Peter
> Le sam. 28 déc. 2019 à 05:03, Peter Wienemann <mailto:foss...@posteo.de>> a écrit :
>
>
Hi Nick,
have you already found time to look into the revised packaging described
in [0] and [1]?
Cheers, Peter
[0] https://lists.debian.org/debian-python/2019/11/msg00048.html
[1] https://lists.debian.org/debian-python/2019/11/msg00106.html
Hi Nick,
On 11.11.19 20:01, Peter Wienemann wrote:
* d/copyright
- the only copyright dates I can see in the source are 2014-2015
Judging from the source files, you are right. Judging from the git
commit history I see commits between 2015 and 2019. What is a better
guideline for copyright
Hi Nick,
thank you very much for taking the time to review the packaging and
providing such detailed and helpful feedback.
On 10.11.19 00:02, Nick Morrott wrote:
> Thank you for your work in packaging python-pyjsparser. Out of
> curiosity, what are you using to be build your package?
My primary
Dear Python team,
I prepared packaging for python-pyjsparser (ITP bug #943785) on
https://salsa.debian.org/python-team/modules/python-pyjsparser
It provides a fast JavaScript parser written in Python.
It would be great if a DD could review the code, provide feedback and
(if everything looks OK)
Hi,
I am one of the maintainers of the Charliecloud package [0]. The most
recent version of Charliecloud (0.10) has added new python dependencies
(lark [1] and its dependencies). Some of them are not yet available in
Debian.
My salsa login is wiene-guest.
I read the DPMT policy [2] and I accept
14 matches
Mail list logo
