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

2020-04-19 Thread Dmitry Shachnev
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


signature.asc
Description: PGP signature


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

2020-04-19 Thread Thomas Goirand
On 4/19/20 5:24 PM, Félix Sipma wrote:
> I hope I fixed the issues you found

Not really... :(

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.

Cheers,

Thomas Goirand (zigo)



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

2020-04-19 Thread Félix Sipma

On 2020-04-19 15:39+, 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


signature.asc
Description: PGP signature


Ongoing packaging work for some Python Modules

2020-04-19 Thread Henry-Nicolas Tourneur

Hello everyone,

I recently started working together with Josch on some Python modules:
construct, pyfavicon, pykeepass is in the pipe too, others will follow 
as well like yoyo-migrations.


So I just wanted to touch base and say hello to everyone.
The Maintainer field and related will be set to DPMT for those 
new/updated modules,

so I found it would be fair to give you guys a little heads-up :)
The background context is that those modules will be used by Python 
apps I would like to package later on as well (checking also with GNOME 
packaging team about that), namely password-safe (Python+GTK keepass 
password-manager) and authenticator (Python+GTK TOTP tool).


Looking forward to work together on Python modules.
My salsa id is henry-nicolas-guest.

Best regards,
Henry-Nicolas Tourneur
Matrix id: @hntourne:matrix.nilux.be



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

2020-04-19 Thread Scott Kitterman



On April 19, 2020 3:24:17 PM UTC, "Félix Sipma"  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



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

2020-04-19 Thread Félix Sipma

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


signature.asc
Description: PGP signature


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

2020-04-19 Thread Thomas Goirand
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).

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.

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.

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.

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?

I hope this helps,
Cheers,

Thomas Goirand (zigo)



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

2020-04-19 Thread Félix Sipma

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
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "sphinx-autoapi", which is 
needed for the newest version of khard.

 * Package name: sphinx-autoapi
   Version : 1.2.1-1
   Upstream Author : Read the Docs, Inc
 * URL : https://github.com/readthedocs/sphinx-autoapi/
 * License : Expat
 * Vcs : 
https://salsa.debian.org/python-team/modules/sphinx-autoapi.git
   Section : python

It builds those binary packages:

  python3-sphinx-autoapi - Sphinx AutoAPI provides "autodoc" style 
documentation for multiple programming languages without needing to load, run, 
or import the project being documented.


To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/sphinx-autoapi

Alternatively, one can download the package with dget using this command:

  dget -x   
https://mentors.debian.net/debian/pool/main/s/sphinx-autoapi/sphinx-autoapi_1.2.1-1.dsc

Changes since the last upload:

   * Initial release. (Closes: #955819).


-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable'), (100, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Félix


signature.asc
Description: PGP signature
--- End Message ---


signature.asc
Description: PGP signature