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-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 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
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-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-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-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-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 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-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 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 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
26 matches
Mail list logo
