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


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

[felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

Started byFélix Sipma <felix+debian@gueux.org>
First post2020-04-19 12:10 +0200
Last post2020-04-21 11:20 +0200
Articles 10 — 3 participants

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


Contents

  [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-19 12:10 +0200
    Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-19 17:30 +0200
      Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]] Scott Kitterman <debian@kitterman.com> - 2020-04-19 17:40 +0200
        Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-19 19:00 +0200
      Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Dmitry Shachnev <mitya57@debian.org> - 2020-04-19 22:20 +0200
        Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-20 11:20 +0200
      Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-20 11:20 +0200
        Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-20 14:50 +0200
          Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-20 16:40 +0200
            Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1  [ITP]] Félix Sipma <felix+debian@gueux.org> - 2020-04-21 11:20 +0200

#12490 — [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-19 12:10 +0200
Subject[felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
Message-ID<zXf3I-4Ut-13@gated-at.bofh.it>

[Multipart message — attachments visible in raw view] — view raw

Hi,

Nobody answered on mentors, so I'm trying debian-python... If someone could 
have a look to this package and push it to the NEW queue, it would allow 
me to get a new version of khard in sid.

Thanks,

-- 
Félix

[toc] | [next] | [standalone]


#12491

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-19 17:30 +0200
Message-ID<zXk3n-893-5@gated-at.bofh.it>
In reply to#12490

[Multipart message — attachments visible in raw view] — view raw

Hi Thomas,

Thanks for the review, and it's nice to see you found a number of 
problems! I have to admit I did not prepare a new package since a long 
time, probably forgot a lot of things, and copied others from other 
packages of mine...

On 2020-04-19 14:09+0200, Thomas Goirand wrote:
>Hi Felix,
>
>Thanks for working on this. Here's my comments. I'm sorry that there's a
>lot to say on what you did... :/
>
>On 4/19/20 11:53 AM, Félix Sipma wrote:
>>  dget -x  	https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.2.1-1.dsc
>
>Looking at your debian/copyright, I'd strongly suggest releasing the
>Debian packaging under the same license. For me that's a blocker for
>sponsoring the package (it may be ok for others to sponsor).

OK. I prefer using GPL-3+, but nevermind, I would really like to get
this package in sid soon. Other sponsors are still to be found, so I 
turned it to Expat.

>You wrote in d/control as if the 2nd line of Description: was the
>continuation of the short description. This is not the case. Please
>write a proper short description (ie: the first line after
>"Description:") and a long description (what goes after that first line)
>as *not* the continuation of the first line. It's very much ok to repeat
>the short description in the long one. This is also a blocker for me to
>sponsor the package.

Sorry about this, I guess I wanted to write a small description, forgot 
about it, and just put the long description instead. It should be fixed 
now.

>You're packaging the doc "as-is" without using Sphinx to build it. Any
>reason why, or you just don't know how yet? :) I'd suggest looking at
>other Python package building a -doc package to fix this. I'd also
>suggest packaging the doc in a separate -doc package.

Woops, I guess I didn't look closely to the build logs... And I did this 
for a package used for generating doc: I should be punished for that :).

>Also, please remove:
>
>[import-orig]
>merge-mode = replace
>
>from debian/gbp.conf. This is typically something that goes into
>~/.gbp.conf rather than on individual packages.

I don't agree with you on this one. To me, this kind of setting should 
be put in the package, to have an uniform way of updating/building/etc. 
a given package, whoever the uploader could be.

>Can you explain in more details than in debian/rules why you're
>overriding override_dh_auto_clean ? What does it try to download, apart
>from the build dependencies? Can't you set $clean_source = 0; in your
>~/.sbuildrc instead?

Mmh, I don't remember about this... I probably copied it from another of 
my packages, without looking at it. It works without, so I removed it. 
I'll try to find what this other package is to see if I can fix it 
properly :-).

Note that I found and patched another access to the internet during 
build (see 0001-Use-local-object-inventory-files-for-sphinx.patch).

More generally, I disagree with needing special settings in ~/.sbuildrc 
(or other user configuration, or special command line arguments) before 
updating a package. I think that is just making life harder for 
(potential) future uploaders.

>I hope this helps,

Sure, thanks! I have to say that I was starting filling quite 
demotivated because of not finding a sponsor for this little package... 
(And I have the same issue for other haskell packages, maybe I should 
finally complete the procedure to apply for becoming a DD...). I hope I 
fixed the issues you found and that you will agree with my argument for 
the debian/gbp.conf setting.

The new package is at https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.3.0-1.dsc

Regards,

-- 
Félix

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


#12492 — Re: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]

FromScott Kitterman <debian@kitterman.com>
Date2020-04-19 17:40 +0200
SubjectRe: [felix+debian@gueux.org: Bug#955862: RFS: sphinx-autoapi/1.2.1-1 [ITP]]
Message-ID<zXkd4-8cj-9@gated-at.bofh.it>
In reply to#12491

On April 19, 2020 3:24:17 PM UTC, "Félix Sipma" <felix+debian@gueux.org> wrote:
>Hi Thomas,
>
>Thanks for the review, and it's nice to see you found a number of 
>problems! I have to admit I did not prepare a new package since a long 
>time, probably forgot a lot of things, and copied others from other 
>packages of mine...
>
>On 2020-04-19 14:09+0200, Thomas Goirand wrote:
>>Hi Felix,
>>
>>Thanks for working on this. Here's my comments. I'm sorry that there's
>a
>>lot to say on what you did... :/
>>
>>On 4/19/20 11:53 AM, Félix Sipma wrote:
>>>  dget -x 
>	https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.2.1-1.dsc
>>
>>Looking at your debian/copyright, I'd strongly suggest releasing the
>>Debian packaging under the same license. For me that's a blocker for
>>sponsoring the package (it may be ok for others to sponsor).
>
>OK. I prefer using GPL-3+, but nevermind, I would really like to get
>this package in sid soon. Other sponsors are still to be found, so I 
>turned it to Expat.

As a member of the FTP Team, I see this situation from time to time.  It's usually not a serious problem, but I agree with Zigo on this.

Where it becomes problematic is when code in debian/ becomes intermingled with the installed upstream code.  One has to look at the license of both upstream and debian/ to determine the effective license of the package.  If the licenses are incompatible, then the binary isn't distributable.  I have seen this happen.

Aligning the license of the packaging with the upstream license makes it all much simpler.

...
>>Also, please remove:
>>
>>[import-orig]
>>merge-mode = replace
>>
>>from debian/gbp.conf. This is typically something that goes into
>>~/.gbp.conf rather than on individual packages.
>
>I don't agree with you on this one. To me, this kind of setting should 
>be put in the package, to have an uniform way of updating/building/etc.
>
>a given package, whoever the uploader could be.
>
...
>fixed the issues you found and that you will agree with my argument for
>the debian/gbp.conf setting.

If you intend to maintain this package in DPMT or PAPT, we have a standard gbp.conf for the teams that doesn't include this, so it would be inappropriate.  In any case, it's the default for a format 3.0(Quilt) source package, so there's no need for it anyway:

https://manpages.debian.org/testing/git-buildpackage/gbp-import-orig.1.en.html

Scott K

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


#12494

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-19 19:00 +0200
Message-ID<zXlsu-rh-11@gated-at.bofh.it>
In reply to#12492

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-19 15:39+0000, Scott Kitterman wrote:
>As a member of the FTP Team, I see this situation from time to time.  It's usually not a serious problem, but I agree with Zigo on this.
>
>Where it becomes problematic is when code in debian/ becomes intermingled with the installed upstream code.  One has to look at the license of both upstream and debian/ to determine the effective license of the package.  If the licenses are incompatible, then the binary isn't distributable.  I have seen this happen.
>
>Aligning the license of the packaging with the upstream license makes it all much simpler.
>
>...

OK, it makes sense. Thanks for the rationale!

>If you intend to maintain this package in DPMT or PAPT, we have a standard gbp.conf for the teams that doesn't include this, so it would be inappropriate.  In any case, it's the default for a format 3.0(Quilt) source package, so there's no need for it anyway:
>
>https://manpages.debian.org/testing/git-buildpackage/gbp-import-orig.1.en.html
>
>Scott K

OK. I removed the setting.

-- 
Félix

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


#12495

FromDmitry Shachnev <mitya57@debian.org>
Date2020-04-19 22:20 +0200
Message-ID<zXoA1-2uo-1@gated-at.bofh.it>
In reply to#12491

[Multipart message — attachments visible in raw view] — view raw

Hi all,

On Sun, Apr 19, 2020 at 09:50:34PM +0200, Thomas Goirand wrote:
> Now the package is 2.7 MB, out of which the extracted library is only
> 380 KB. Now, the extracted documentation is 3.5 MB and contains 3 MB of
> fonts, like fontawesome and lato, which are already part of Debian.
>
> If everyone was doing like you, installing a small python app would
> download gigabytes of packages! :)
>
> Please:
> 1/ Push the docs into a separate package that you could call
> python-sphinx-autoapi-doc.
> 2/ Remove the embedded fonts fonts from that -doc package, and create
> symlinks to the appropriate files in the fonts-font-awesome and
> fonts-lato package.

Better not symlink anything manually but use dh_sphinxdoc which will do it
automatically:

- Replace “--with python3” with “--with python3,sphinxdoc” in debian/rules.
- Make python-sphinx-autoapi-doc depend on ${sphinxdoc:Depends}.
- Drop Suggests: libjs-jquery, libjs-underscore as they will be in Depends.

--
Dmitry Shachnev

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


#12497

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-20 11:20 +0200
Message-ID<zXAKT-1Br-7@gated-at.bofh.it>
In reply to#12495

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-19 23:18+0300, Dmitry Shachnev wrote:
>Better not symlink anything manually but use dh_sphinxdoc which will do it
>automatically:
>
>- Replace “--with python3” with “--with python3,sphinxdoc” in debian/rules.
>- Make python-sphinx-autoapi-doc depend on ${sphinxdoc:Depends}.
>- Drop Suggests: libjs-jquery, libjs-underscore as they will be in Depends.

Thanks for pointing me to dh_sphinxdoc! I'll fix my other packages relying on
sphinx to make use of it, too.

Regards,

-- 
Félix

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


#12496

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-20 11:20 +0200
Message-ID<zXAKR-1Br-1@gated-at.bofh.it>
In reply to#12491

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-19 21:50+0200, Thomas Goirand wrote:
>On 4/19/20 5:24 PM, Félix Sipma wrote:
>> I hope I fixed the issues you found
>
>Not really... :(

Let's try again, then...

>Now the package is 2.7 MB, out of which the extracted library is only
>380 KB. Now, the extracted documentation is 3.5 MB and contains 3 MB of
>fonts, like fontawesome and lato, which are already part of Debian.
>
>If everyone was doing like you, installing a small python app would
>download gigabytes of packages! :)
>
>Please:
>1/ Push the docs into a separate package that you could call
>python-sphinx-autoapi-doc.
>2/ Remove the embedded fonts fonts from that -doc package, and create
>symlinks to the appropriate files in the fonts-font-awesome and
>fonts-lato package.
>
>One little general advice now: use mc (or something similar) to go
>within the resulting .deb files after you've built them, so you can
>check its content. If you did that, you would have find the issues I'm
>describing above.

For sure, getting a 2.7MB package for this small library is not good. I 
do display the list of the files after I build them, but I admit I 
usually don't look too closely to these, and rely on lintian warnings to 
see if fonts package are incorrectly embedded, if the resulting doc is 
too big and should be put to a separate package, etc. Maybe something 
changed recently on lintian (or in my config, but the warnings were not 
displayed on https://mentors.debian.net/package/sphinx-autoapi either) 
because I do not get the embedded fonts warnings I used to have...

The resulting package is much smaller, I don't think it justifies 
another -doc package. Do you agree?

Regards,

-- 
Félix

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


#12498

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-20 14:50 +0200
Message-ID<zXE25-3uC-7@gated-at.bofh.it>
In reply to#12496

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-20 12:06+0200, Thomas Goirand wrote:
>I'm not sure, the doc still accounts for half of the package. But let's
>pretend it's ok.

We are talking about 80KB for the whole package. If it's not a blocker 
for you I prefer keeping it like that.

>Now, the package contains a test suite. It'd be nice to run it. If you
>add, as dependency: python3-mock, python3-pytest, then pybuild runs the
>tests automatically. It needs to be overridden though, to avoid running
>integration tests which are failing (or these tests must be fixed).
>
>Can you do that? Then I'll happily upload...

I added the dependencies, and disabled the integration tests which 
requires golang and dotnet sphinxcontrib extensions. I don't have the 
energy to package these myself...

Could you please also give me the upload rights for this package when it 
will enter sid?

Thanks again for your reviews.

-- 
Félix

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


#12499

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-20 16:40 +0200
Message-ID<zXFKy-4A3-9@gated-at.bofh.it>
In reply to#12498

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-20 16:16+0200, Thomas Goirand wrote:
>On 4/20/20 2:45 PM, Félix Sipma wrote:
>> On 2020-04-20 12:06+0200, Thomas Goirand wrote:
>>> I'm not sure, the doc still accounts for half of the package. But let's
>>> pretend it's ok.
>>
>> We are talking about 80KB for the whole package. If it's not a blocker
>> for you I prefer keeping it like that.
>
>Fine, ok.
>>
>>> Now, the package contains a test suite. It'd be nice to run it. If you
>>> add, as dependency: python3-mock, python3-pytest, then pybuild runs the
>>> tests automatically. It needs to be overridden though, to avoid running
>>> integration tests which are failing (or these tests must be fixed).
>>>
>>> Can you do that? Then I'll happily upload...
>>
>> I added the dependencies, and disabled the integration tests which
>> requires golang and dotnet sphinxcontrib extensions. I don't have the
>> energy to package these myself...
>
>Of course! However, when I build the package:
>
>The text files are in build/sphinx/text.
> dh_auto_test -O--buildsystem=pybuild
>I: pybuild base:217: cd
>/<<PKGBUILDDIR>>/.pybuild/cpython3_3.8_sphinx-autoapi/build; python3.8
>-m unittest discover -v
>
>----------------------------------------------------------------------
>Ran 0 tests in 0.000s
>
>So, it's running zero tests now. I'm unsure what you did, but that's not
>correct. When it tried myself, a lot of tests ran with success.

I added python3-mock and python3-pytest to actually run the tests, then
I just disabled one specific test through

     `export PYBUILD_TEST_ARGS=-k-test_integration`

I use `dgit sbuild` to build the package, and the other tests are 
actually ran (I just tried again)...

     ...
     The text files are in build/sphinx/text.
        dh_auto_test -O--buildsystem=pybuild
     I: pybuild base:217: cd /<<PKGBUILDDIR>>/.pybuild/cpython3_3.8_sphinx-autoapi/build; python3.8 -m pytest -k-test_integration
     ============================= test session starts ==============================
     platform linux -- Python 3.8.2, pytest-4.6.9, py-1.8.1, pluggy-0.13.0
     rootdir: /<<PKGBUILDDIR>>
     collected 235 items / 14 deselected / 221 selected
     
     tests/test_astroid_utils.py ............................................ [ 19%]
     ........................................................................ [ 52%]
     ........................................................                 [ 77%]
     tests/test_domains.py ......                                             [ 80%]
     tests/test_objects.py .......                                            [ 83%]
     tests/python/test_parser.py ..........                                   [ 88%]
     tests/python/test_pyintegration.py ..........................            [100%]
     
     =============================== warnings summary ===============================
     /usr/lib/python3/dist-packages/jinja2/sandbox.py:19
       /usr/lib/python3/dist-packages/jinja2/sandbox.py:19: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working
         from collections import Mapping
     
     tests/test_domains.py:147
       /<<PKGBUILDDIR>>/.pybuild/cpython3_3.8_sphinx-autoapi/build/tests/test_domains.py:147: DeprecationWarning: invalid escape sequence \s
         self.assertEqual(ret, "With surrounding characters s :any:`FOO`\s")
     
     tests/test_domains.py:152
       /<<PKGBUILDDIR>>/.pybuild/cpython3_3.8_sphinx-autoapi/build/tests/test_domains.py:152: DeprecationWarning: invalid escape sequence \s
         self.assertEqual(ret, "With surrounding characters s ``FOO``\s")
     
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::TestSimpleModule::test_manual_directives
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_napoleon_integration_loaded
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_class_class_content
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_both_class_content
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_init_class_content
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_hiding_inheritance
     .pybuild/cpython3_3.8_sphinx-autoapi/build/tests/python/test_pyintegration.py::test_inherited_members
       /usr/lib/python3/dist-packages/sphinx/domains/python.py:400: RemovedInSphinx40Warning: PyClassmember is deprecated.
         warnings.warn('PyClassmember is deprecated.',
     
     -- Docs: https://docs.pytest.org/en/latest/warnings.html
     ============ 221 passed, 14 deselected, 10 warnings in 3.96 seconds ============
        create-stamp debian/debhelper-build-stamp
        dh_testroot -O--buildsystem=pybuild
        dh_prep -O--buildsystem=pybuild
        dh_auto_install -O--buildsystem=pybuild
     I: pybuild base:217: /usr/bin/python3 setup.py install --root /<<PKGBUILDDIR>>/debian/python3-sphinx-autoapi 
     ...


Could you have another look?

>> Could you please also give me the upload rights for this package when it
>> will enter sid?
>
>I'm sorry, but considering the process and how many mistakes I had to
>point at which were easy to spot, I wont take this responsibility. I
>however will agree to review subsequent uploads.

No problem. I got the "how many mistakes I had to point at which were 
easy to spot", as I did not submit a new package for a long time and 
forgot about some of the packaging subtleties, probably did not put 
enough energy to get this package quality to the top level from the 
beginning, and also (thanks!) because I had to learn new tricks I did 
not know before (like using dh_sphinxdoc). But, just to have an idea, 
what do you mean by "considering the process"?

Regards,

-- 
Félix

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


#12500

FromFélix Sipma <felix+debian@gueux.org>
Date2020-04-21 11:20 +0200
Message-ID<zXXeq-6VH-21@gated-at.bofh.it>
In reply to#12499

[Multipart message — attachments visible in raw view] — view raw

On 2020-04-20 21:53+0200, Thomas Goirand wrote:
>Well, I'm just trying to sponsor what you've uploaded to mentors, and so
>far, it didn't work (I just tried). Please try downloading the .dsc with
>dget and try yourself.
>
>Cheers,
>
>Thomas Goirand (zigo)

How did you build the package?

I just tried to "dget -x https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.3.0-1.dsc && sbuild sphinx-autoapi_1.3.0-1.dsc"
and, again, that just worked, tests included.

Regards,

-- 
Félix

[toc] | [prev] | [standalone]


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


csiph-web