Request to join python-team

2022-12-02 Thread Mohd Bilal

Hello team ,

Just came to know about the sprint happening and I thought to use it as 
an opportunity to join and contribute to the team :)


I've some packaging experience and I intend to work on item #3 listed in 
the wiki[1] during the sprint


As a first step I've fixed #1018583[2] and have pushed my changes here[3].

I would like someone from the team review my changes and I'll push them 
to the team repo if everything's okay


I have read and accepted the policy[4] of the team

My salsa login is rmb

[1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018583
[2] - https://salsa.debian.org/rmb/python-statsd
[3] - 
https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst


Thanks :)
--
Mohammed Bilal
2D65 BC1E B966 5A6E 97F9 730A B3F5 9452 8521 9E1F



OpenPGP_signature
Description: OpenPGP digital signature


Re: Request to join the team - salsa: tai271828

2022-12-02 Thread Stefano Rivera
Hi Taihsiang (2022.12.02_22:51:03_+)
> I would like to join the Debian Python team for the sprint today and
> this weekend, and help with more packaging work in the future.

Added. Thanks for the help.

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272



Request to join the team - salsa: tai271828

2022-12-02 Thread Taihsiang Ho (tai271828)
Hi,

I would like to join the Debian Python team for the sprint today and
this weekend, and help with more packaging work in the future.

During the sprint and working on this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018505 , people
("pollo", thank you!) guided me that I should join the team to fit the
workflow easier.

I have read and accepted the policy of the team
https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst
.

My salsa account name is tai271828 . Thank you!

Regards,
Tai



Re: Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too

2022-12-02 Thread Louis-Philippe Véronneau

On 2022-12-01 01 h 52, Stuart Prescott wrote:

Hi Scott

On 01/12/2022 15:16, Scott Kitterman wrote:

On Wednesday, November 30, 2022 10:38:30 PM EST Stuart Prescott wrote:

Hi Scott,

On 01/12/2022 02:16, Scott Kitterman wrote:

Package: lintian
Version: 2.115.3
Severity: normal
X-Debbugs-Cc: debian-python@lists.debian.org

The missing-prerequisite-for-pyproject-backend check appears to only
look for the prerequisite packages in Build-Depends, but since they
aren't needed for clean, they could be in Build-Depends-Indep, leading
to false positives.

Scott K


I contemplated filing a similar the other day but in writing it up, I
realised that lintian was correct. Policy requires that the 'clean'
target be functional with only the Build-Depends (and Build-Conflicts)
satisfied, and pybuild + the build-backend dependencies are involved in
the cleaning step.


Not always.  At least with the package I ran into this on, clean works 
fine

without them.


Yes indeed...

- the most obvious case where that works is where 'clean' is explicit in 
d/rules


- it would also be possible for it to work in situations where dh-python 
is (redundantly?) listed in B-D (not B-D-I), since the pyproject 
plugin's 'clean' operation has no dependency on `build`, `installer`, 
and the backend.


However, this for this second case:

- it might result in pybuild picking a different plugin through lack of 
dependencies like `tomli`. That might just work... but also feels 
slightly terrifying.


- there's not _currently_ any backend-specific cleaning code, but 
perhaps there should be, which would then need the deps to be in B-D? 
(Is that in the spec somewhere?)


I guess the main thing to be careful of in any rewording of this 
explanation is that for the most common case of using "%:\n\tdh 
--buildsystem pybuild", dh-python (or pybuild-plugin-pyproject) is 
needed in B-D not B-D-I to be policy-compliant.


cheers
Stuart


I've proposed a fix here:

https://salsa.debian.org/lintian/lintian/-/merge_requests/426

It's not precise enough to flag packages that would declare everything 
as a Build-Depends-Indep though. This would be much more complex and I 
feel this situation is overall pretty rare.


--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



OpenPGP_0xE1E5457C8BAD4113.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature


python-greenlet update to 2.0.1

2022-12-02 Thread Scott Talbert

Hi Jelmer,

It looks like you started working on updating python-greenlet to 2.0.1 
(needed because python-gevent was updated and the two versions are now 
incompatible).  Any reason that you stopped or just lack of time?


Thanks,
Scott



Bug#1025319: ITP: python-blurhash -- Python implementation of the blurhash algorithm

2022-12-02 Thread Edward Betts
Package: wnpp
Severity: wishlist
Owner: Edward Betts 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org

* Package name: python-blurhash
  Version : 1.1.4
  Upstream Author : Lorenz Diener 
* URL : https://github.com/halcy/blurhash-python
* License : MIT
  Programming Lang: Python
  Description : Python implementation of the blurhash algorithm

  BlurHash takes an image, and gives you a short string (only 20-30 characters)
  that represents the placeholder for this image. You do this on the backend
  of your service, and store the string along with the image. When you send
  data to your client, you send both the URL to the image, and the BlurHash
  string. Your client then takes the string, and decodes it into an image that
  it shows while the real image is loading over the network. The string is
  short enough that it comfortably fits into whatever data format you use. For
  instance, it can easily be added as a field in a JSON object.
 
I plan to maintain this package as part of the Python team.