Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Utkarsh Gupta
On Thu, May 6, 2021 at 1:20 AM Andrey Rahmatullin  wrote:
> But Github doesn't provide the metadata. You would need to get a tarball
> and run sdist or something like that.

Right and thus I am wondering if we could work through this, somehow?
That is, $something fetches the tarball, runs sdist or whatever, and
then the py2dsp magic.

P.S. I know this sounds a little ambitious but I believe this would
really help, too.

- u

Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Utkarsh Gupta

On Thu, May 6, 2021 at 12:33 AM Sandro Tosi  wrote:
> that's correct, the package still needs to be on PyPI, as that's the
> place where py2dsp obtains most of the package metadata

Can we change that or have a flag or something added so that it pulls
from g/h directly?

- u

Re: Build an initial Debian source package with py2dsp from a GitHub project

2021-05-05 Thread Utkarsh Gupta
Hi Sandro,

On Sun, Apr 25, 2021 at 9:53 AM Sandro Tosi  wrote:
> Let me know if you find this useful and if there are
> issues/enhancement you'd like to see added/fixed.

This looks great! Thank you!
However, I am running into an issue (or I guess I am just not doing it
Whilst trying to package from the g/h source
(, it fails like this:

Am I missing something?

- u

Re: Python 3.9 for bullseye

2020-11-09 Thread Utkarsh Gupta

On 11/9/20 6:34 PM, Thomas Goirand wrote:
> On 11/9/20 10:19 AM, Matthias Klose wrote:
>> src:python-fixtures
> Does anyone else than me think it's probably OK to just disable to 2
> broken tests?

As long as it doesn't indicate something serious, it's probably alright
to do so.

- u

Re: upload sphinx-autoapi

2020-10-21 Thread Utkarsh Gupta
Hi Felix,

On Sat, Oct 10, 2020 at 4:04 PM Félix Sipma  wrote:
> I updated the package to the last upstream version, and it includes a
> few fixes. I'd appreciate if I could be given upload rights, that would
> help maintaining the package.

Given you upload rights. You should have an email about it shortly.

 - u

Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Utkarsh Gupta

On Mon, Jun 29, 2020 at 8:24 PM Thomas Goirand  wrote:
> Nice! Thanks a lot for the pointer.


> I very much agree with you that the debate has to be emptied from
> emotions if possible. My goal has never been to point finger at anyone,
> but try to fix a reoccurring situation which I would like to avoid.

Definitely! Everyone would love to avoid that!

> Running the script shows that 279 reverse (build?) dependencies are
> affected by mock. This clearly isn't something one wants to run on a
> personal computer, and even less a test which one wants to run sequentially.

Haha, right.
What we (me and a couple others) do is run this build script on a
server (via screen) and call it a night :P
And we get the list of broken packages in the morning!

But of course, this is not a very "professional" way of doing it.

> Has any thought went into having some kind of runners running on a cloud
> to run these tests, and maybe plug this into Salsa's CI to run it
> automatically?

This seems to be a nice idea!
I am not sure if someone had the time or energy to do this, but this
is something we'd definitely love \o/

> I'd very much would love to set this up, at least as a first
> experimentation on a bunch of package of the DPMT.

Me too!


Re: Maintaining all of the testing-cabal packages under the OpenStack team

2020-06-29 Thread Utkarsh Gupta
On Sun, Jun 28, 2020 at 11:29 PM Sandro Tosi  wrote:
> OS is *just* another software we package for
> Debian; is it complex? sure, but it's not special, and it doesnt
> warrant any special treatment.

I am afraid when you say this.
First of all, that's not completely true. But I don't want to go there.

What I want to emphasis more on is:
It's okay if you don't want to treat packages in a "special" way,
that's totally fine!
But what's **not** fine is breaking something else whilst updating
something else.
That is just NOT...okay.

Sometimes it just happens (accidentally or whatever) but I think even then, the
person who does that should at least look up at the packages broken,
try to fix it,
and if it lies something outside their scope (because of time
constraints, etc), the
least they can do is report this to the respective maintainer(s) or at
least raise to
the list so that people who can, will help!

If everyone uploaded what they felt like without taking care of what's breaking,
the whole of Debian would just be chaos.

And I think, that's not the way it should be. At all.
And I completely agree with Thomas' statement when he says,
"No, this is not how Debian works, it never was, and hopefully, never will."

I love Ondrej and I love Thomas. And this mail has nothing to do with them.
Instead, this is a mail to everyone.
And while at it, I'd also request everyone to be a little empathetic.
I really hope that's not much to ask, is it!?

> It'd be nice if we had a framework to be able to rebuild all reverse
> build-dependency when we update a package. But currently, we don't have
> such CI. If one volunteers to write it, probably we can find some
> compute resources to make it happen. That's probably the way out, and
> IMO we should really all think about it.

There exists such a thing which I use daily: ruby-team/meta[1].
The meta/build script is (hopefully and exactly) what we need here!

It checks all the reverse(-build)-dependencies and lets you know what's
going to break as soon as you dput.


Re: [RFS] djangorestframework-gis

2020-06-19 Thread Utkarsh Gupta

On Sat, Jun 13, 2020 at 11:54 PM Nilesh Patra  wrote:
> This Needs review and sponsorship.

Thanks and uploaded! :)


Re: python-trezor and python-libusb1

2020-06-15 Thread Utkarsh Gupta

On Tue, Jun 16, 2020 at 10:18 AM  wrote:
> Is someone available that could look into fix so python-libusb1 can progress 
> to testing? I’m not a Debian developer, but I’m more than willing to do 
> anything I can to help.

I just did a source-only upload of python-libusb1 and this should help
migrate it to testing.
And should, therefore, unblock python-trezor :)

I hope that helps.


Re: joining the PAPT

2020-05-11 Thread Utkarsh Gupta
Hi Hans,

On Tue, May 12, 2020 at 2:03 AM Hans-Christoph Steiner  wrote:
> Ok, this has become a bit more urgent since someone has moved my package
> fdroidserver into PAPT without asking me.  Now I cannot push commits to
> it.  So either someone needs to grant me PAPT access or put my package
> back where it was in salsa.  I'm fine with fdroidserver being in PAPT,
> I'm not fine with being locked out of my package.

I am sorry this happened (though I've no idea who did it).
Whilst I don't have the right permissions/access to add you to PAPT
officially, I have given you maintainer access to fdroidserver so this
won't be a blocker to you.

I hope someone with the right access adds you to PAPT soon :)
Let me know if I can help you with anything else meanwhile.


Re: Sponsorship backlog

2020-02-12 Thread Utkarsh Gupta
Hi Jonathan,

On Wed, Feb 12, 2020 at 1:28 PM Jonathan Carter  wrote:
> Thanks! I removed them from the topic.

Many thanks! :)

Also uploaded djangorestframework-api-key and python-opentracing to NEW.


Re: Sponsorship backlog

2020-02-11 Thread Utkarsh Gupta
Hi all,

On Mon, Feb 10, 2020 at 4:23 AM Jonathan Carter  wrote:
> The sponsorship request queue in the IRC topic is getting a bit long
> again, I'll try to make time for as many of these as possible this week,
> but if anyone can help reviewing these packages from the IRC topic (and
> then removing them) then that would be great:
> python-babel, gpxpy, pyparsing, python-progress, python-urllib3,
> geoalchemy2, python-marshmallow-polyfield, python-mongoengine,
> python-nest-asyncio, djangorestframework-api-key, aionotify,
> python-fastjsonschema, python-cassandra-driver

>From my end, I've processed some of these:

pyparsing: uploaded!
python-progress: uploaded!
python-urllib3: uploaded!
python-nest-asyncio: uploaded!
djangorestframework-api-key: sent reviews; had autopkgtest failure.

python-marshmallow-polyfield: was already uploaded.
python-mongoengine: was already uploaded.

Hope that helps in reducing some work.
Also, could someone remove these from the channel list?


Re: How to find DD member to perform reviews and uploads

2020-02-11 Thread Utkarsh Gupta
Hi Adam,

On Sun, Feb 9, 2020 at 9:13 AM Adam Cecile  wrote:

Could you quickly update d/ch entry date?
timewarp-standards-version (2020-01-06 < 2020-01-20) -> 4.5.0 was
released afterwards :)

Also, there's an autopkgtest failure :(
Here's how you can reproduce:
autopkgtest -B ../*.deb -- schroot unstable-amd64-sbuild

Relevant logs:
Testing with python3.8:
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'djangorestframework_api_key'

Let me know once you fix them, I'll be happy to upload! :)


Request to (re)join Python team

2019-12-30 Thread Utkarsh Gupta
Hello everyone,

I'd like to migrate my current membership of the Python team to use my
new Salsa login, i.e., utkarsh \o/
(Previously it was utkarsh2102-guest)

Requesting you to please grant access for both, DPMT and PAPT, once again :)

I've read the policy[1] and accept it.


Description: OpenPGP digital signature

Re: Help with interpreting piuparts error

2019-12-29 Thread Utkarsh Gupta

On Mon, 30 Dec, 2019, 11:59 AM Mattia Rizzolo,  wrote:

> There was a temporary bug in piuparts (after a migration from py2 to
> py3).  The bug has been fixed yesterday, and failed tests will be retried
> automatically after a time.
> There are probably hundreds of failed tests like that.

Oh, yes! 7 Golang packages that I know were failing with the exact same
thingy. And it drove me crazy.

But thanks for letting us know. Maybe it could've been announced more
publicly somewhere?


Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)

2019-11-08 Thread Utkarsh Gupta

On 09/11/19 2:42 am, Louis-Philippe Véronneau wrote:
> On 19-11-08 16 h 01, Thomas Goirand wrote:
>> Hi intri!
>> I'm very glad to count you as a member of the team! Welcome. [1]
>> I'd be glad if more perl team members join, it's so much always a
>> pleasure to meet you at each debconf.
>> On 11/8/19 8:54 AM, intrigeri wrote:
>>>  - In,
>>>the "Policy About Maintainer and Uploaders Fields" section
>>>mentions an "unwritten policy". Said policy seems to have been
>>>written since:
>> It's probably time to revisit this policy. I've heard many voices
>> telling that a package should either be in the team, or just not, and I
>> very much agree with this. This middle-ground makes no sense.
> We now have a proper way to propose updates to the policy [1]!

I am not sure where we stand on the following idea, but I'd like to see
it float across.

Something I'd like to propose is to have more *owners* than just 5 of them.
Just having 5 people in the team who everyone relies on for being
granted access doesn't seem like a very nice idea to me. Whilst they are
doing a nice job, I feel every DD[1] should be able to grant access.
I don't quite like how the access is just limited to 5 people throughout

[1]: we can come up with some other metric to bump ACL level, too, but
we should *definitely* come up with something. One way forward is to add
DDs as owner and every other person as a maintainer. Suggestions open.


Description: OpenPGP digital signature

Request to join the Python team

2019-07-28 Thread Utkarsh Gupta

I would like to join the DPMT and PAPT team (yes, both! :D).

I am a DM[1] and maintain packages under the Ruby, Golang, JS, and the Perl 
My QA profile could be found here[2].

Within the Python team, I would like to help maintain the existing packages,
and also package a few new modules for a couple of upstream projects.

My Salsa login is: utkarsh2102-guest

I have read the policy[3] and agree to it.



Description: OpenPGP digital signature