[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#905750: RFS: elpy/1.23.0-1

[Not prematurely sending mail this time]


Alas I wrote before, whilst I appreciate the sentiment, please spend any
limited time you have for Debian work writing such things in suitable
venue(s) and not in an adjunct sponsorship bug. Otherwise I fear the
effort expended in such a voluminous and detailed response will be in

> >  * Please fix "wrong-section-according-to-package-name" on your next
> >    upload (or otherwise fix Lintian).
> This is currently an Informational level message.  When it was a
> Warning I declared Section: lisp, even though I do not believe that
> this is accurate.

Please strive to be Lintian clean not fuss about "warning" about
"informational" which are not subject to strict scrutinity and
classification by the Lintian maintainers as you seem to infer.

> Re: fixing Lintian, this will require a discussion and a more clear
> definition of Section: lisp.  Most Emacs modes should probably be in
> Section: editors, because they are interactive extensions to an
> editor.  Magit is definitely in the right section eg: vcs.  Emacs
> packages that enable IDE modes should be in Section: devel.
> Section: lisp should be reserved for libraries like dash-el.

This is a topic for elsewhere.

> >  * gzip -9 might need to be gzip -9n for a reproducible build
> >    (unchecked) but I'm surprised it's not compressed by another tool
> >    too (unchecked).
> Thank you for pointing this out.  I've reverted @commit:9095c18
>     because README.rst is only 2.8k and dh_compress already does the
>     right thing automatically; that is to say, README.rst is not
>     "larger than 4k in size" and should not be compressed.

?? I was talking about -n, not -9. Nothing to do with 4k limits but
rather reproducibly.
> On the topic of reproducibility, generating an info page made Elpy
> unreproducible!
>   https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/elpy.html
> This will take time to look into.  Possibilities are:
>   1) sphinx-build is at fault
>   2) makeinfo is at fault
>   3) something is missing how I'm using 1 and/or 2.
>      - if this is the case then it's also a case of incomplete
>        documentation

Likely #2 or something similar. https://bugs.debian.org/826158?

But again, this is really the wrong venue for these 4/5 topics as it will
quickly get lost..


     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk

Reply to: