Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #11968 > unrolled thread

RFS: python-pyjsparser (ITP bug #943785)

Back to article view | Back to linux.debian.maint.python

Contents

  RFS: python-pyjsparser (ITP bug #943785) Peter Wienemann <fossdev@posteo.de> - 2019-11-01 11:00 +0100
    Re: RFS: python-pyjsparser (ITP bug #943785) Nick Morrott <knowledgejunkie@gmail.com> - 2019-11-10 00:10 +0100
      Bug#943785: RFS: python-pyjsparser (ITP bug #943785) Peter Wienemann <fossdev@posteo.de> - 2019-11-11 20:10 +0100
        Bug#943785: RFS: python-pyjsparser (ITP bug #943785) Peter Wienemann <fossdev@posteo.de> - 2019-11-24 12:30 +0100
        Bug#943785: RFS: python-pyjsparser (ITP bug #943785) Peter Wienemann <fossdev@posteo.de> - 2019-12-14 09:20 +0100

#11968 — RFS: python-pyjsparser (ITP bug #943785)

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) upload it.

Thanks, Peter

[toc] | [next] | [standalone]

#11993

On Fri, 1 Nov 2019 at 09:50, Peter Wienemann <fossdev@posteo.de> wrote:
>
> 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) upload it.

Peter,

Thank you for your work in packaging python-pyjsparser. Out of
curiosity, what are you using to be build your package?

I checked out the package and built it - your work looks good, and the
build was successful. I then ran it through lintian, Debian's package
linting tool which you should get into the habit of using before
uploading to salsa (and once you're a DM/DD, also before uploading to
the archive).

Here is the lintian output for the binary changes file:

N: Unpacking packages in group python-pyjsparser/2.7.1-1
N: ----
N: Processing changes file python-pyjsparser (version 2.7.1-1, arch
source all) ...
N: ----
N: Processing source package python-pyjsparser (version 2.7.1-1, arch
source) ...
P: python-pyjsparser source: rules-requires-root-missing
I: python-pyjsparser source: debian-watch-contains-dh_make-template (line 11)
X: python-pyjsparser source: debian-watch-does-not-check-gpg-signature
I: python-pyjsparser source: testsuite-autopkgtest-missing
X: python-pyjsparser source: upstream-metadata-file-is-missing
N: ----
N: Processing buildinfo package python-pyjsparser (version 2.7.1-1,
arch all source) ...
N: ----
N: Processing binary package python3-pyjsparser (version 2.7.1-1, arch all) ...
I: python3-pyjsparser: extended-description-is-probably-too-short
N: Finished processing group python-pyjsparser/2.7.1-1

The output is split into 2 sections for the source and binary
package(s). As you can see, there are a few issues to take care of,
which I expand on below (you can ignore the gpg-signature warning
unless the packages on pypi are signed).

* d/control
  - no Rules-Requires-Root field [lintian]
  - the extended package description should probably include details
about the library's key features/support [lintian]

* d/copyright
  - the only copyright dates I can see in the source are 2014-2015
  - you can add the Upstream-Contact field to the header

* d/rules
  - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1"

* d/upstream/metadata
  - please add and complete this file - there are plenty of examples
in the team's salsa project [lintian]

* d/watch
  - +1 for asking upstream to version their releases on github
  - the additional (commented) scaffolding inserted into the file by
dh-make can be removed to leave only the version line and the URL to
check [lintian]
  - as this is a version 4 watch file, we can take advantage of new
variable substitutions for the version and extension fields, so that
the URL to check would look like:

    https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@

* upstream changelog
  - there is no upstream changelog

* documentation/examples
  - There is no documentation at all, aside from the simple example in
the README. Perhaps this snippet could be installed as an example when
installing the package?

* tests
  - there are no tests to run at build time (and therefore no
autopkgtests to run for continuous integration whenever the package's
dependencies are updated). Looking at the github repo there seems to
be a significant testsuite that should really be available in the
Debian source package to take advantage of autopkgtest. [lintian]


I hope you find this useful - if you have any questions don't hesitate
to ask the team (the Python list is visible and archived, IRC may get
a quicker answer...). I'm a new DD and there are likely some things
that the more experienced members of the team will notice.

Thanks,
Nick

[toc] | [prev] | [next] | [standalone]

#12003 — Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

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 motivation for packaging python-pyjsparser is to be able to
bump the version of Charliecloud:

https://tracker.debian.org/pkg/charliecloud

Version 0.10 of Charliecloud adds new dependencies, including
lark-parser which in turn depends on python-js2py which in turn depends
on python-pyjsparser.

> I checked out the package and built it - your work looks good, and the
> build was successful. I then ran it through lintian, Debian's package
> linting tool which you should get into the habit of using before
> uploading to salsa (and once you're a DM/DD, also before uploading to
> the archive).

I have configured my sbuild setup in such a way that it always runs
lintian after builds. But thanks to your feedback I noticed that I was
running lintian with a too high display threshold such that the only
lintian feedback I received was

"I: Lintian run was successful."

and

"Lintian: pass"

despite of the issues you discovered.

I have tweaked the lintian options in my ~/.sbuildrc now. Hopefully I
will not miss similar issues in the future.

> * d/control
>   - no Rules-Requires-Root field [lintian]

Fixed.

>   - the extended package description should probably include details
> about the library's key features/support [lintian]

Done.

> * 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 years: copyright notices in the source or the
git history? Maybe it would be best to combine both information which
would yield 2014-2019. Once I know what should be used, I will update
the copyright file accordingly.

>   - you can add the Upstream-Contact field to the header

Done.

> * d/rules
>   - pybuild can provide verbose output with "export PYBUILD_VERBOSE=1"

Added.

> * d/upstream/metadata
>   - please add and complete this file - there are plenty of examples
> in the team's salsa project [lintian]

Done.

> * d/watch
>   - +1 for asking upstream to version their releases on github

Thanks! Let's see what happens.

>   - the additional (commented) scaffolding inserted into the file by
> dh-make can be removed to leave only the version line and the URL to
> check [lintian]

The idea behind leaving the Github lines as comment was that I could
easily switch to following Github tags/releases provided that upstream
decides to publish them for future releases. But since the
"<project>" string triggers the lintian complaint and replacing this
placeholder would be just guessing until upstream actually provides
releases on Github, I removed all comments related to this.

This also makes lintian happier. :-)

>   - as this is a version 4 watch file, we can take advantage of new
> variable substitutions for the version and extension fields, so that
> the URL to check would look like:
> 
>     https://pypi.debian.net/pyjsparser/pyjsparser@ANY_VERSION@@ARCHIVE_EXT@

Very convenient variables. Changed accordingly.

> * upstream changelog
>   - there is no upstream changelog

To my knowledge upstream does not provide such a file.

> * documentation/examples
>   - There is no documentation at all, aside from the simple example in
> the README. Perhaps this snippet could be installed as an example when
> installing the package?

Done (although I am not sure whether the way I implemented it is the
recommended way to do it). Suggestions how to improve the code are welcome.

> * tests
>   - there are no tests to run at build time (and therefore no
> autopkgtests to run for continuous integration whenever the package's
> dependencies are updated). Looking at the github repo there seems to
> be a significant testsuite that should really be available in the
> Debian source package to take advantage of autopkgtest. [lintian]

The testsuite available on Github requires js2py which is not in the
Debian archive yet (thus the testsuite introduces a circular dependence:
pyjsparser <-> js2py). js2py is the next package on my to-package list
(see above).

I see two options to move forward:

1. Wait for js2py being packaged and provide autopkgtests for pyjsparser
once js2py is available.

2. Install js2py using pip for the test.

None is really nice in my opinion. Which option do you prefer?

> I hope you find this useful - if you have any questions don't hesitate
> to ask the team (the Python list is visible and archived, IRC may get
> a quicker answer...). I'm a new DD and there are likely some things
> that the more experienced members of the team will notice.

Yes, your feedback was definitely very helpful and allowed me to learn
new things.

Thanks,

Peter

[toc] | [prev] | [next] | [standalone]

#12038 — Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

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 years: copyright notices in the source or the
> git history? Maybe it would be best to combine both information which
> would yield 2014-2019. Once I know what should be used, I will update
> the copyright file accordingly.

I asked on IRC how to handle this situation. The answer was: Use the 
copyright years from the copyright notices in the source. I have just 
pushed a commit with the corresponding change to salsa.

Peter

[toc] | [prev] | [next] | [standalone]

#12149 — Bug#943785: RFS: python-pyjsparser (ITP bug #943785)

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web