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
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 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
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,
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
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 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
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 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 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 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 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,
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
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 Alexandru,
On 2024-10-15 18:02:10, Alexandru Mihail wrote:
I'd like to request an upload of the psrecord NEW package
( https://salsa.debian.org/python-team/packages/python-psrecord ) as I
don't have uploading rights. This closes #1075810. It's lintian OK and
the latest upstream version.
tha
Hi Alexandru,
On 2024-10-24 21:30:48, Peter Wienemann wrote:
d/control
-
a) The present code fails to build in a clean build environment because
the following build dependencies are missing:
- python3-psutil
- help2man
b) The "Provides" field should be removed (cf. [3]).
Hi Scott,
On 2024-10-26 17:00:18, Scott Kitterman wrote:
From reading this thread, it seems like psrecord is an application written in
Python. Upstream could, if they felt like it, re-implement the whole thing in
Rust and it would still be psrecord. Assuming that's at least generally
correct,
Hi Scott,
On 2024-10-27 20:12:28, Peter Wienemann wrote:
On 2024-10-26 17:00:18, Scott Kitterman wrote:
From reading this thread, it seems like psrecord is an application
written in Python. Upstream could, if they felt like it, re-implement
the whole thing in
Rust and it would still be
Hi Alexandru,
On 2024-11-10 19:23:29, Alexandru Mihail wrote:
d/control
Done
at present both the source package and the binary package are called
"psrecord". Looking at [0] my understanding is that the recent package
name discussion concluded with
source package name: psrecord
binary pac
Hi Alexandru,
On 2024-11-24 23:31:22, Alexandru Mihail wrote:
I implemented the last things you pointed out (I chose utils for the
section of psrecord as I see it fits its use the most).
the build failure mentioned in [0] still persists. I also noticed that
the upstream branch contains commit
Hi Alexandru,
On 2024-11-27 20:41:33, Peter Wienemann wrote:
On 2024-11-24 23:31:22, Alexandru Mihail wrote:
As of you protecting debian/master I can no longer directly push to
this branch. I have the developer role and only Maintainer+Owner roles
can directly push to protected. For now, I&#x
Hi Alexandru,
On 2024-11-23 22:20:16, Alexandru Mihail wrote:
After implementing welcomed suggestions from people who replied to this
thread (thanks Peter et al) I think this package is ready for upload
(or further review if you find anything wrong, of course). It's lintian
clean and you can fin
Hi Alexandru,
On 2024-11-30 14:00:19, Alexandru Mihail wrote:
Yes, there were some rogue commits in [upstream], I reimported upstream
tar.gz and redone the whole process, it seems to build fine for me now
in an empty sbuild.
Seems fine now, thanks for the time; upload when you think OK.
I stil
Hi Alexandru,
On 2024-12-08 16:11:02, Alexandru Mihail wrote:
Did all the little final housework you suggested, including bonus (nice
catch !)
Ready for upload when you can !
I've just uploaded psrecord. It should show up in the NEW queue [0] soon
- waiting for FTP master review.
Thanks a l
Hi Ananthu,
On 2024-12-08 17:58:09, weepingclown wrote:
d/clean would work just as well, that's exactly what I tend to use if I have
more than a few files that I have to specify manually to be cleaned.
I always feel undecided which option I should give preference to.
And personally, I'd rec
Hi Alexandru,
On 2024-12-06 17:13:18, Alexandru Mihail wrote:
Pinging about (upload) my last mail, I cleaned up upstream mess on
psrecord now and I think it's ready for upload. Would really appreciate
your scrutiny one last time.
I am mostly happy now. There are two issues left:
1. The genera
26 matches
Mail list logo
