Re: Review + Upload for a few Django-related packages
Hi again, On Tue, Aug 8, 2023 at 11:35 PM Lena Voytek wrote: > And here are some Django 4 specific updates: > > https://salsa.debian.org/python-team/packages/python-django-tagging/-/merge_requests/2 > https://salsa.debian.org/python-team/packages/django-menu-generator-ng/-/merge_requests/1 Uploaded both with the "Team upload" addition to d/ch. :) - u
Re: Review + Upload for a few Django-related packages
Hi Lena, On Tue, Aug 8, 2023 at 11:35 PM Lena Voytek wrote: > https://salsa.debian.org/python-team/packages/django-assets/-/merge_requests/3 Sponsored that upload after adding "Team upload" to d/ch! :) > https://salsa.debian.org/python-team/packages/django-dbbackup/-/merge_requests/1 django-dbbackup fails to build from source. Could you please look into it and fix that? - u
Re: Build an initial Debian source package with py2dsp from a GitHub project
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
Hello, 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
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 correctly). Whilst trying to package from the g/h source (https://github.com/keylime/keylime), it fails like this: http://paste.debian.net/1195339/ Am I missing something? - u
Re: Python 3.9 for bullseye
Hey, On 11/9/20 6:34 PM, Thomas Goirand wrote: > On 11/9/20 10:19 AM, Matthias Klose wrote: >> https://bugs.debian.org/973239 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
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
Hello, On Mon, Jun 29, 2020 at 8:24 PM Thomas Goirand wrote: > Nice! Thanks a lot for the pointer. \o/ > 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! Best, Utkarsh
Re: Maintaining all of the testing-cabal packages under the OpenStack team
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. Best, Utkarsh --- [1]: https://salsa.debian.org/ruby-team/meta
Re: [RFS] djangorestframework-gis
Hi, On Sat, Jun 13, 2020 at 11:54 PM Nilesh Patra wrote: > This Needs review and sponsorship. Thanks and uploaded! :) Best, Utkarsh
Re: python-trezor and python-libusb1
Hiya, 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. Best, Utkarsh
Re: Sponsorship backlog
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. Best, Utkarsh
Re: Sponsorship backlog
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? Best, Utkarsh
Re: How to find DD member to perform reviews and uploads
Hi Adam, On Sun, Feb 9, 2020 at 9:13 AM Adam Cecile wrote: > https://salsa.debian.org/python-team/modules/djangorestframework-api-key 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! :) Best, Utkarsh
Request to (re)join Python team
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. Best, Utkarsh --- [1]: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst signature.asc Description: OpenPGP digital signature
Re: Help with interpreting piuparts error
Hiya, 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? Best, Utkarsh
Re: Policy About Maintainer and Uploaders Fields (was: PAPT: join request)
Hey, 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 https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin, >>>the "Policy About Maintainer and Uploaders Fields" section >>>mentions an "unwritten policy". Said policy seems to have been >>>written since: >>> >>> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst >> 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 debian-python. [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. Best, Utkarsh signature.asc Description: OpenPGP digital signature
Request to join the Python team
Hey, 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 team. 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. [1]: https://nm.debian.org/person/utkarsh2102 [2]: https://qa.debian.org/developer.php?login=guptautkarsh2...@gmail.com [3]: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Best, Utkarsh signature.asc Description: OpenPGP digital signature
