Re: Joining the team, ITP and RFS
Hi Juhani, pá 27. 11. 2020 v 17:55 odesílatel Juhani Numminen < juhaninummin...@gmail.com> napsal: > Hi! > > I'd like to join the Debian Python Team welcome :) > Also, I would like to ask for a new git repository for the package. > Would you mind creating one in the standard location > https://salsa.debian.org/python-team/packages/python-pysol-cards? > the name of the repository should be the same as the source package name. If that's correct, you can create that repository yourself now. -- Best regards Ondřej Nový
Re: Joining the team
Hi nicoo, po 23. 11. 2020 v 14:15 odesílatel nicoo napsal: > First, an apology: it seems I misremembered being in the team, and > uploaded to > NEW a bunch of packages with the team in `Uploaders`. While I guess that's > technically valid (I'm fine with the Python team uploading to them), I am > not > exactly comfortable with having done so without being a team member or > clearing > it first with you all. > it's up to you to choose if you want to have strong or weak team maintenance. If you are fine with the Python team members uploading, use strong - use team in the Maintainer field. Second, I would like to join the team ^.^ > cool! Please follow our policy: https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst to join the team. Thanks. -- Best regards Ondřej Nový
Re: python-team/packages repo move request
Hi, po 26. 10. 2020 v 9:45 odesílatel Gordon Ball napsal: > 1. Archive python-team/packages/ipython > + rename to python-team/packages/ipython-OLD > 2. Rename python-team/packages/ipython4 -> python-team/packages/ipython > done. -- S pozdravem/Best regards Ondřej Nový
Re: Joining the DPT
Hi, pá 23. 10. 2020 v 21:03 odesílatel Baptiste Beauplat napsal: > would like to join the Debian Python Team welcome :) -- Best regards Ondřej Nový
Re: Joining DPT
Hi, pá 16. 10. 2020 v 20:25 odesílatel Birger Schacht napsal: > I would like to join the Debian Python Team. welcome :) -- Best regards Ondřej Nový
Re: Joining the team
Hi, st 30. 9. 2020 v 14:25 odesílatel Chris MacNaughton < chris.macnaugh...@canonical.com> napsal: > - I want to join the python-modules team so that I can help improve both > Debian and Ubuntu's stance with python dependencies for OpenStack! > welcome :) -- Best regards Ondřej Nový
Re: Transfer cherrytree from DPT to Debian group
Hi, pá 16. 10. 2020 v 17:32 odesílatel Andrius Merkys napsal: > Hello, > > Recently cherrytree [1] has been rewritten from Python to C++, thus it > no longer belongs in DPT. Could someone with adequate permissions > transfer it from DPT to generic Debian group on salsa.d.o? > done: https://salsa.debian.org/debian/cherrytree -- Best regards Ondřej Nový
Re: delete new/empty octave_kernel salsa repo
Hi Joe, čt 1. 10. 2020 v 5:55 odesílatel Joe Nahmias napsal: > Would someone with owner access for the DPT group on salsa please delete > the new/blank octave_kernel repo [Project ID: 54132] it's done. -- Best regards Ondřej Nový
Re: Policy proposal: Consistent use of UNRELEASED in debian/changelog
Hi, po 28. 9. 2020 v 2:08 odesílatel Louis-Philippe Véronneau napsal: > Hi! > > I am proposing a minor addition to the DPT policy to try to make the use > of UNRELEASED in debian/changelog more consistent. The full diff can be > found here [1]. > I agree with this proposal but please change the wording a bit as per rfc2119 :) -- Best regards Ondřej Nový
Re: Joining the team
Hi, po 14. 9. 2020 v 8:11 odesílatel Chris MacNaughton < chris.macnaugh...@canonical.com> napsal: > Hey team, > > I'm Chris MacNaughton (icey) and I've been working on packaging for > OpenStack in Ubuntu for about six months now and would love to help > contribute upstream a bit. I'm working on a new package that's an > OpenStack dependency now and would prefer to work that more in Debian, > rather than maintaining a separate library in Ubuntu so it seems like a > great time to get in touch! Zigo asked me to see about joining this team > if I'll be working on doing these kinds of things upstream so here I am! > that's cool! Please follow policy how to join team: https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst Thank you. -- Best regards Ondřej Nový
Re: PAPT: join request
Hi, pá 11. 9. 2020 v 17:25 odesílatel Fred Le Meur < frederic.le-m...@ac-versailles.fr> napsal: > Hello, > > * I want to join Debian Python Team welcome :) -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, po 21. 9. 2020 v 13:04 odesílatel Ondrej Novy napsal: > Todo: > >- send debian-devel-announce (i will) >- mass-commit vcs+maintainer change > > done. Thanks to all who helped me with these. -- Best regards Ondřej Nový
Re: [DRAFT] DPMT and PAPT is DPT now
Hi, thanks a lot for this. Second version: --- cut --- PAPT and DPMT become DPT Historically, the Debian Python ecosystem was maintained by two separate teams: the Debian Python Applications Packaging Team (PAPT) for applications, and the Debian Python Modules Team (DPMT) for modules used by applications. As there was substantial overlap between the members of these teams, their work, and their tooling, these teams have been merged into one: the Debian Python Team (DPT). Changes --- This merge mainly affects package maintainers. End users should not see a change beyond the Maintainer field of packages. For maintainers, the following has changed: * The respective PAPT and DPMT policies are superseded by the new, more compact DPT policy [1]. Please take a few minutes to familiarize yourself with this new policy. * All Salsa repositories are in "packages" subgroup [2] now. Please set Vcs-* fields of new packages accordingly. * The Maintainer field of new packages should now be set to "Debian Python Team ". Migration - On Salsa, redirects have been implemented from the old "applications" and "modules" subgroups to the new "packages" subgroup. Vcs-* URLs should continue working for now. But it's still a good idea to update your local git remotes to point to new "packages" subgroup. Maintainer and Vcs-* fields were mass-changed in git repositories so there is nothing you need to do as maintainer of DPMT/PAPT packages. All members of DPMT or PAPT are members of DPT now and have access to "packages" subgroup. As always, new contributors are welcomed :) [1] https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst [2] https://salsa.debian.org/python-team/packages --- cut --- -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, po 14. 9. 2020 v 9:59 odesílatel Ondrej Novy napsal: > I prepared scripts for: > >- cloning ACLs from modules+applications subgroups to newly created >packages subgroup >- transferring all project from modules+applications to packages >subgroup >- tested on one project: >https://salsa.debian.org/python-team/packages/alembic > > done. Sorry for those notification emails. I globally disabled notification after suggestion from ansgar so you should receive only ~60 emails. Todo: - send debian-devel-announce (i will) - mass-commit vcs+maintainer change - figure out if we can remove subgroups "modules" and "applications" (will it keep redirects?) - cleanup "tools" subgroup (remove application policy, etc.) - ...? Example of mass-commit: https://salsa.debian.org/python-team/packages/alembic/-/commit/0519af5c5f82cced88431b6c0ec364f2979e0c42 https://salsa.debian.org/python-team/packages/alembic/-/commit/51dbd7b278551fbd33abac72c7a240e6baea6a16 Suggestion for better wording of changelog is welcome. -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, út 15. 9. 2020 v 0:12 odesílatel Christian Kastner napsal: > Has getting rid of the subgroups entirely been considered, IOW: moving > the packages directory to python-team/? > > The only remaining subgroup seems to be "tooling", and that could live > on as a subgroup unless I'm misunderstanding GitLab. > reason is ACL. We need different access for "tools" and for "packages". -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, po 14. 9. 2020 v 14:39 odesílatel Dmitry Shachnev napsal: > I think it's better to update Vcs fields in all packages to point to the > new location, not one that redirects. > > Probably also update Maintainer/Uploader fields with the new team > name/email. > yep. But updating these is a "never ending process". Because we can simply commit change to git, but upload of some packages will take ages :) Good news is we don't need to hurry with this update. -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, po 14. 9. 2020 v 14:26 odesílatel Emmanuel Arias napsal: > So, we shouldn't be worried about changing the VCS-* path during the > migration process, isn't it? > right, we should update them in d/control, but it will work with old one too, which simplifies that process. -- Best regards Ondřej Nový
[DRAFT] DPMT and PAPT is DPT now
Hi, I would like to send information to debian-devel-announce after the team merge as suggested by Christian Kastner. Draft follows. Suggestions welcome. --- Hi, for simplification we merged two subteams - Debian Python Modules Team and Python Applications Packaging Team into just one: Debian Python Team, DPT. All Salsa repositories are in "packages" subgroup [1] now. We have only one team policy [2] now. And as always, new contributors are welcomed :) [1] https://salsa.debian.org/python-team/packages [2] https://salsa.debian.org/python-team/tools/python-modules/-/blob/master/policy.rst -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, I prepared scripts for: - cloning ACLs from modules+applications subgroups to newly created packages subgroup - transferring all project from modules+applications to packages subgroup - tested on one project: https://salsa.debian.org/python-team/packages/alembic It looks like old web URLs works just fine: https://salsa.debian.org/python-team/modules/alembic and cloning too: $ git clone ssh://g...@salsa.debian.org/python-team/modules/alembic.git Cloning into 'alembic'... remote: Enumerating objects: 1141, done. remote: Counting objects: 100% (1141/1141), done. remote: Compressing objects: 100% (558/558), done. remote: Total 1141 (delta 720), reused 932 (delta 543), pack-reused 0 Receiving objects: 100% (1141/1141), 882.54 KiB | 989.00 KiB/s, done. Resolving deltas: 100% (720/720), done. $ $ git clone https://salsa.debian.org/python-team/modules/alembic.git Cloning into 'alembic'... remote: Enumerating objects: 1141, done. remote: Counting objects: 100% (1141/1141), done. remote: Compressing objects: 100% (558/558), done. remote: Total 1141 (delta 720), reused 932 (delta 543), pack-reused 0 Receiving objects: 100% (1141/1141), 882.54 KiB | 3.33 MiB/s, done. Resolving deltas: 100% (720/720), done. $ Any thoughts? pá 28. 8. 2020 v 15:36 odesílatel Ondrej Novy napsal: > Hi, > > pá 28. 8. 2020 v 15:27 odesílatel Louis-Philippe Véronneau < > po...@debian.org> napsal: > >> I think changing the path would be a good idea, as I don't see the point >> between the libraries and applications divide. > > > +1. GitLab will take care with redirects. It's a mess now :) > > -- > Best regards > Ondřej Nový > > -- S pozdravem/Best regards Ondřej Nový
Re: PAPT: join request
Hi, ne 6. 9. 2020 v 19:03 odesílatel Fred Le Meur < frederic.le-m...@ac-versailles.fr> napsal: > Hello, > > I would be please to join PAPT. > cool! But please follow procedure in our team policy to join the team: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thank you. -- Best regards Ondřej Nový
Re: request to join the debian-python team
Hi, ne 6. 9. 2020 v 5:33 odesílatel Joe Nahmias napsal: > I am a retired DD that is planning to rejoin welcome to the team :) -- Best regards Ondřej Nový
Re: What is the new maintainer address for Python team?
Hi Otto, sorry for the long delay. We were in the process of changing this email address. New/correct address is: Maintainer: Debian Python Team po 31. 8. 2020 v 19:19 odesílatel Otto Kekäläinen napsal: > Hello! > > I've been using the address python-apps-t...@lists.alioth.debian.net > as the maintainer address in my packages, but the address no longer > works. I tried looking at what other packages have, but there are no > working examples > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967997). > > So dear list members, what is the correct address to use now as > python-apps-t...@lists.alioth.debian.net no longer works for the > Maintainer field in d/control files? > > > - Otto > > -- S pozdravem/Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, pá 28. 8. 2020 v 15:04 odesílatel Ondrej Novy napsal: > But because it's really huge change I want ack from at least one another > admin. > ~10 days without reply, merged. Thanks for working on this! -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, pá 28. 8. 2020 v 15:27 odesílatel Louis-Philippe Véronneau napsal: > I think changing the path would be a good idea, as I don't see the point > between the libraries and applications divide. +1. GitLab will take care with redirects. It's a mess now :) -- Best regards Ondřej Nový
Re: Merging the PAPT and the DMPT
Hi, čt 27. 8. 2020 v 22:22 odesílatel Louis-Philippe Véronneau napsal: > In October 2019, following a short discussion on the ML [1], I opened a > merge request on the policy [2] for this. Most if not all issues in that > MR have since been resolved and the only blocker is getting the admins > approval. > as DPMT/PAPT admin I agree with merging of these subteams and I agree with this MR. But because it's really huge change I want ack from at least one another admin. Thanks a lot for working on this. -- Best regards Ondřej Nový
Re: Request to join the DPMT
Hi, ne 23. 8. 2020 v 8:24 odesílatel Antonio Valentino < antonio.valent...@tiscali.it> napsal: > Hello, > I would like to prepare and maintain the python package for resampy [1, > 2] within the Debian Python Modules Team. > welcome :) -- Best regards Ondřej Nový
Re: can we disable the bounce kicker? Re: confirm
Hi, po 17. 8. 2020 v 21:15 odesílatel Sandro Tosi napsal: > To these days, this is still happening! can we finally get rid of > this? Piotr, it looks like you're the admin of the mailing list, can > you take care of it please? thanks! > yes, please, please, please, please. -- Best regards Ondřej Nový
Re: PAPT team access request
H čt 23. 7. 2020 v 13:24 odesílatel Aloïs Micard napsal: > I do you agree with the Python Applications Packaging Team - Policy. > welcome :) -- Best regards Ondřej Nový
Re: PAPT team access request
Hi, do you agree to our policy [1]? [1] https://salsa.debian.org/python-team/tools/python-apps/-/blob/master/policy.rst po 20. 7. 2020 v 17:03 odesílatel Aloïs Micard napsal: > Sorry, forgot to send my login: `creekorful` > > Thanks in advance. > > -- > Aloïs Micard > > GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2 > > > From: Aloïs Micard > Sent: Monday, July 20, 2020 10:22:05 AM > To: debian-python@lists.debian.org > Subject: PAPT team access request > > Hello everyone! > > I would like to join the Debian PAPT team > in order to help maintain existing python apps as well as package > one of mine. > > Cheers > > -- > Aloïs Micard > > GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2 > > -- S pozdravem/Best regards Ondřej Nový
Re: joining team / salsa access
Hi, čt 16. 7. 2020 v 15:30 odesílatel Jojo napsal: > I'd like to join the debian python modules and application teams welcome :) -- Best regards Ondřej Nový
Re: Request to join python-team
Hi, pá 17. 7. 2020 v 4:01 odesílatel Francisco Vilmar Cardoso Ruviaro < francisco.ruvi...@riseup.net> napsal: > My name is Francisco Vilmar Cardoso Ruviaro, I would like to be part of the > team welcome :) -- Best regards Ondřej Nový
Re: Request to join python-team on salsa
Hi Shayan, po 13. 7. 2020 v 15:41 odesílatel Shayan Doust napsal: > ... I would like to join the team > welcome to the team. -- Best regards Ondřej Nový
Re: request to join the team
Hi Sudip, ne 12. 7. 2020 v 0:31 odesílatel Sudip Mukherjee napsal: > Hi, > > I am maintaining a python package and have few in NEW also intend to > package #962239. I think its best to maintain them as part of the > team. > My salsa id is 'sudip'. > I have read the policies at > > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and > https://salsa.debian.org/python-team/tools/python-apps/-/blob/master/policy.rst > and I accept them. > welcome to both teams. -- Best regards Ondřej Nový
Re: Request to join Python Modules Team
Hi, út 14. 7. 2020 v 23:18 odesílatel Geert Stappers napsal: > And please enlighten me (and us (through the mailinglist)) > what is holding back > https://lists.debian.org/debian-python/2020/07/msg00057.html huh, this is a bit rude. This is volunteering project and you are trying to give me (us) some deadlines or what? -- Best regards Ondřej Nový
Re: The python command in Debian
Hi, po 13. 7. 2020 v 19:21 odesílatel Matthias Klose napsal: > On 7/13/20 6:23 PM, Fabrice BAUZAC-STEHLY wrote: > > Hi, > > > > Another solution would be to simply use the update-alternatives system > > to manage /usr/bin/python. python3 would have a higher priority than > > python2. Users would still have the possibility to switch > > /usr/bin/python to python2 explicitly if they require it... > > No, never ever. update-alternatives cannot be used because it breaks the > dependency system. > no, it doesn't. If all Python2 packages will use /usr/bin/python2 and all Python3 packages will use /usr/bin/python3, then /usr/bin/python can be managed by update-alternatives. And because we really want all Python2 packages to use /usr/bin/python2, I think this is a viable option. But TBH I don't think it's a good idea, because it can be confusing for users. -- Best regards Ondřej Nový
Re: Is it time to remove python-numpy from testing?
Hi, čt 9. 7. 2020 v 21:25 odesílatel peter green napsal: > python-numpy* is no longer buildable in testing due to the removal of the > "cython" binary package. > The maintainer has requested removal of python-numpy from unstable but the > ftpmasters have not yet > actioned it, presumably because there are still reverse-dependencies in > unstable. A rc bug is > present but will not cause autoremoval because python-numpy is on the "key > packages" list. > > All of the reverse dependencies of python-numpy have already been removed > from testing. So IMO > it makes sense to remove python-numpy from testing at this point, do other > people agree? > if all reverse dependencies of python-numpy were already removed from testing and we are not going to reintroduce python-numpy into testing I think it's good idea to remove python-numpy from "key packages" list and thus allow autoremoval. -- Best regards Ondřej Nový
Re: The python command in Debian
Hi, čt 9. 7. 2020 v 15:27 odesílatel Matthias Klose napsal: > Describing here a solution which is implemented for Ubuntu focal (20.04 > LTS). A > new source package what-is-python (-perl-dont-hurt-me) ships binary > packages > python-is-python2, python-dev-is-python2, python-is-python3 and > python-dev-is-python3. The python-is-python2 package provides the python > package, such that packages that still depend on python are not removed on > a > distro upgrade. On new installs, python-is-python3 is not installed by > default, > but the user gets a hint from command-not-found to install the package if > he > tries to run python. Package dependencies on the new four binary packages > have > to be disallowed in the Python policy. Note that such a package including > the > Provides should only be uploaded once all dependencies on the unversioned > python > packages are gone. > I like this solution in Ubuntu and I have: onovy@jupiter:~$ dpkg -l | grep python-is-python3 ii python-is-python3 3.8.2-4 all symlinks /usr/bin/python to python3 What I think is good idea: * keep "python" command pointing to python2.7 if I'm upgrading buster->bullseye with python2.7 installed. We are going to keep python2.7 interpreter for bullseye, so don't break old "python" command for third-parties apps/scripts/etc. (install python-is-python2 during buster->bullseye upgrade) * allow users to choose if they want python=python3 (apt install python-is-python3) * (maybe?) python=python3 in new installs, because why not? (install python-is-python3 by default in clean install) -- Best regards Ondřej Nový
Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]
Hi, st 8. 7. 2020 v 12:14 odesílatel Thomas Goirand napsal: > There would be no point doing that, as all what pybuild would be doing > (ie: setup.py install and unit testing), I'd be overriding it. it's doing much more, but nevermind. > The other > (IMO preferred) way would be to contribute to Pybuild to make it does > what's needed for these packages, and in a way so that we can also make > such global change for all OpenStack packages at once. > that's even better! Add support for stestr (or whatever is OS using now) with correct autodetection and you are done. -- Best regards Ondřej Nový
Re: Request to join Python Modules Team
Hi, ne 5. 7. 2020 v 18:46 odesílatel Geert Stappers napsal: > Whenever things get stalled it is good to ask: > >Who is waiting on who? > We have a rule between admins we are processing join request after few days to give everyone chance to give their opinions. In this particular case it was my fault and overlooked that email. I volunteer to be part of "Some administrator". > cool. Current admins needs to agree, so: @piotr, @stefanor, @kitterman, @bzed: your opinions please? Debian tradition I will be re-introducing is sending "done messages". > no need to re-introduce, I'm always sending welcome message :) -- Best regards Ondřej Nový
Re: Request to join Python Modules Team
Hi, so 4. 7. 2020 v 9:17 odesílatel Sao I Kuan napsal: > Ping o/ Or am I missing any necessary information? > I'm sorry, I overlooked your request. Added to team, welcome. -- Best regards Ondřej Nový
Re: Timing of Python upstream and Debian releases
Hi, po 6. 7. 2020 v 21:04 odesílatel Matthias Klose napsal: > So what I'm proposing here is to aim to support 3.9 as early as possible > as a > supported Python3 version, starting with the 3.9 upstream release, and > fixing > stuff on the go. Then decide in November, if we can do the defaults > change to > 3.9, or if we drop 3.9 again, or ship with two supported Python3 versions. > +1 for this proposal. -- Best regards Ondřej Nový
Re: pybuild vs os-pkg-tools [was: Maintaining all of the testing-cabal packages under the OpenStack team]
Hi, po 6. 7. 2020 v 11:09 odesílatel Thomas Goirand napsal: > This isn't about hating or loving pybuild. This is all about being able > to control how this set of packages are build globally (the whole set of > packages. so you could wrap these global things around pybuild, right? -- Best regards Ondřej Nový
Re: py2removal - make all leaf applications RC
Hi, ne 5. 7. 2020 v 7:38 odesílatel Sandro Tosi napsal: > I propose to raise the severity of all leaf applications in 3 days > +1 Thanks! -- S pozdravem/Best regards Ondřej Nový
Re: Request for joining DPMT
Hi, so 13. 6. 2020 v 12:18 odesílatel Nilesh Patra napsal: > Hi, > I'm interested in joining DPMT > welcome :) -- Best regards Ondřej Nový
Re: Request to join DPMT
Hi, st 24. 6. 2020 v 11:27 odesílatel Michael Hanke napsal: > Hi, > > I would like to join DPMT, welcome :) -- Best regards Ondřej Nový
Re: Request to join
Hi, so 27. 6. 2020 v 15:30 odesílatel Jerome Charaoui napsal: > Hello, > > I would like to request to join the Python Applications team. > welcome :) -- Best regards Ondřej Nový
Re: Maintaining all of the testing-cabal packages under the OpenStack team
Hi, ne 28. 6. 2020 v 16:48 odesílatel Thomas Goirand napsal: > Hi, > > Under a single Github account, the below packages are maintained: > - mock > - subunit > - testtools > - fixtures > - funcsigs (deprecated, py2 backport) > - testresources > - traceback2 > - testscenarios > - testrepository > - extras > - linecache2 > > Currently, these packages are maintained by a variety of DDs, and > there's no uniform maintenance of them. > which is perfectly fine, that's how Debian works. The last upload of mock 4.0.2, by Ondrej, broke *a least*: > - nova (see: #963339) > - cloudkitty (see: #963069) > - congress (see: #963312) > - rally (see: #963381) > > All of the 4 packages above were able to build in Bullseye (ie: mock > 3.0.5) and FTBFS in Sid (with mock 4.0.2). > > Well done! :( > yep, that's how it works. We need to move forward and don't keep old, buggy and unmaintained packages in Debian, right? You should add autopkgtest to prevent this. Failed autopkgtest will block migration. Or we should start using full transitions, which is a bad idea imho. Ondrej, you once cared for the OpenStack packages. Why are you now > completely careless? > because it's really hard to cooperate with you. I already tried to explain it to you but you didn't listen. > More over, mock debhelper was upgraded to 13, for no apparent reason > (yet another "cosmetic fix" that isn't helping?). I'd like to remind > everyone that, increasing debhelper compat version to a number that > isn't in stable, without a specific reason (like the need of a specific > feature that wasn't there before) is just annoying for anyone > maintaining backports. That's truth even for when debhelper itself is > backported to oldstable (it's always nicer to be able to build a > backport without requiring another backport at build time). > nope, this is not true. Using the newest debhelper compat level is recommended, see man page. There is no reason to __not__ upgrade debhelper compat level. I will always upgrade debhelper in my packages to the newest debhelper as soon as possible. Please newer downgrade debhelper in my packages again without asking. I don't want this to happen again. So I am hereby asking to take over > the maintenance of these packages which aren't in the OpenStack team. > They will be updated regularly, each 6 months, with the rest of > OpenStack, following the upstream global-requirement pace. I'm confident > it's going to work well for me and the OpenStack team, but as well for > the rest of Debian. > for my packages (i'm uploader): no, sorry. Reasons: 1. I hate openstack-pkg-tools 2. I like pybuild 3. you hate pybuild and don't want to use it -- Best regards Ondřej Nový
Re: SETUPTOOLS_SCM_PRETEND_VERSION trick : how to use it in autopkgtest?
H,
po 8. 6. 2020 v 17:22 odesílatel Julien Puydt
napsal:
> Hi,
>
> I know about the SETUPTOOLS_SCM_PRETEND_VERSION trick when it is used
> in d/rules :
>
> include /usr/share/dpkg/pkg-info.mk
> export SETUPTOOLS_SCM_PRETEND_VERSION=$(DEB_VERSION_UPSTREAM)
>
dh-python do this automatically when python{,3}-setuptools-scm is in B-D.
> I got around by turning d/tests/upstreamtestsuite to:
>
> #!/bin/sh
> set -e
> SETUPTOOLS_SCM_PRETEND_VERSION=0.0.0 python3 setup.py test 2>&1
>
> which worked because in fact the tests don't care about the version.
>
you can use "dpkg-parsechangelog -SVersion" or include /usr/share/dpkg/
pkg-info.mk + $DEB_VERSION_UPSTREAM here too.
--
Best regards
Ondřej Nový
Re: Access to python-team/modules (was RFS: ruamel.yaml.clib)
Hi, ne 7. 6. 2020 v 11:26 odesílatel Michael R. Crusoe napsal: > Pardon me, I left out a component of my application for team membership: > > I have read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and I accept the policy. > > On Sun, Jun 7, 2020 at 10:50 AM Michael R. Crusoe wrote: > >> Looks like I emailed the wrong mailing list back in March. >> >> I'm a DD now, so I don't need sponsorship. Can I have access to move my >> repository to https://salsa.debian.org/python-team/modules/ ? >> > welcome to the team :) > My salsa username is crusoe >> >> I would be happy to move some python libraries from the Debian Med team >> over to the DPMT: >> > please talk with Debian Med admins about this first, no problem with it from DPMT side. -- Best regards Ondřej Nový
Re: Please transfer package presto from DPMT to med-team
Hi, pá 29. 5. 2020 v 14:09 odesílatel Andreas Tille napsal: > we would like to maintain presto in Debian Med. Unfortunately I do not > have permissions to transfer the repository. Please either give me > permissions or some kind soul could do the transfer to move the repository > smoothly. > I can do transfer for you. I have enough permissions in DPMT gorup, but not in med-team. -- Best regards Ondřej Nový
Re: Bug#952130: Bug#937769: getting python-linecache2/python-traceback2 fixes into testing (FAO traceback2, funcsigs nipype and numba maintainers).
Hi, út 21. 4. 2020 v 23:24 odesílatel Thomas Goirand napsal: > > But that still leaves the question of what to do about the dependency of > > pytest on pypy-funcsigs ? should pypy modules be removed from pytest and > > it's reverse-dependencies in the same way that regular python2 modules > > were? how feasible is that? are pypy-* packages only useful with python2 > > pypy or are they also useful with python3 pypy? > > I really don't know about pypy. Probably the pypy-pytest should indeed > go away, as the initial plan was to switch to pypy3. Maybe tumbleweed > (Stefano Rivera) would be able to answer. I'm adding him as Cc. > I guess I can say something about pytest because I'm maintainer of pytest, right? :) I'm perfectly fine with removing pypy-pytest binary package and all other dependencies in chain. It's painfull to maintain it. -- Best regards Ondřej Nový
Re: request to join the team, again
Hi, done, welcome :) ne 29. 3. 2020 v 6:08 odesílatel Antoine Beaupré napsal: > Same, with PAPT, please. > > Thanks. > > A. > > On 2017-12-30 09:46:28, Antoine Beaupre wrote: > > Hi, > > > > I've been packaging stuff in Debian for a while and I'm often packaging > > dependencies that would benefit from being under the DPMT umbrella. > > > > My alioth login is "anarcat". > > > > I have read read the policy and accept it. > > > > My next steps are to package the dependencies of the newest > > rapid-photo-downloader. > > > > Thanks, > > > > A. > > > > -- > > Quidquid latine dictum sit, altum sonatur. > > Whatever is said in Latin sounds profound. > > -- > It is capitalism and government which stand for disorder and > violence. Anarchism is the very reverse of it; it means order without > government and peace without violence. > - Alexander Berkman > -- Best regards Ondřej Nový
Re: Joining the PAPT team
Hi, po 9. 3. 2020 v 18:19 odesílatel Berthold Gehrke napsal: > Hello dear PAPT, > > I would like to join this team to maintain (for now together with a > sposor) 'my' package asciidoc3 see https://asciidoc3.org. > welcome :) -- Best regards Ondřej Nový
Re: non-python packages in PAPT?
Hi, so 15. 2. 2020 v 22:17 odesílatel Philipp Huebner napsal: > Is it okay to also transfer that non-python package into PAPT? > my two cents: It's not. Why not use "debian" group for this? -- Best regards Ondřej Nový
Re: Request to join PAPT
Hi, st 5. 2. 2020 v 1:07 odesílatel Bastian Germann napsal: > ... and would like to join PAPT > welcome :) -- Best regards Ondřej Nový
Re: I'd like to Join the DPMT
Hi, út 11. 2. 2020 v 14:52 odesílatel Sam Hartman napsal: > > Hi. > I've read the DPMT policy and accept it. > welcome :) -- Best regards Ondřej Nový
Re: How to find DD member to perform reviews and uploads
Hi, út 11. 2. 2020 v 11:02 odesílatel Adam Cecile napsal: > Bringing the package into the archive would be doable, if someone get > legal contacts at LSI and asked for official statement authorizing > Debian to redistribute their binary. I did this in the past for another > package but I cannot guarantee any success. > be careful with this. See DFSG 8 :) -- Best regards Ondřej Nový
Re: How to find DD member to perform reviews and uploads
Hi, ne 9. 2. 2020 v 15:13 odesílatel Adam Cecile napsal: > I have a couple of package ready on Salsa but my RFS sent here remained > unanswered. > best way how to get help is to join IRC and add that packages to channel topic. Thanks for your work for Debian and DPMT team. -- Best regards Ondřej Nový
Re: Separate lib and executable packages?
Hi, so 8. 2. 2020 v 20:51 odesílatel Gordon Ball napsal: > Perhaps this is worth making an explicit recommendation for new packages > of this type, given that anything new _should_ be python3-only and we > and what about pypy- prefix? -- Best regards Ondřej Nový
Re: Separate lib and executable packages?
Hi, so 8. 2. 2020 v 4:11 odesílatel Scott Kitterman napsal: > Except: Every time we add a binary to Debian it impacts everyone. The > packages file gets bigger and so updates get slower. Although there's no > firm rule, the FTP Masters discourage addition of trivially small packages > and so your package might be rejected. > so let's fix infrastructure? -- Best regards Ondřej Nový
Re: Separate lib and executable packages?
Hi, it depends :). My two cents: If you are packaging application (PAPT team): * user is using it in CLI / Xorg * user don't need to know it's written in Python * Python modules are typically private, not usable by other applications/libraries -> one binary package: foo If you are packaging library (DPMT team): * your package is typically not usable by user directly * your package is typically dependency of other packages (Python applications/libraries) -> as many binary packages as "language branches" we have, e.g. python-foo, python3-foo, pypy-foo If you are packaging application with public library part (PAPT team): * both of above * user is using it in CLI / Xorg * BUT package have library part, which can be used in other Python applications/libraries -> as many binary packages as "language branches" we have, e.g. python-foo, python3-foo, pypy-foo + foo for application. "foo" package can contain more than entrypoints, but icons, menu items, ... -- Best regards Ondřej Nový
Re: Bug#938819: wheel: Python2 removal in sid/bullseye
Hi Dmitry, čt 30. 1. 2020 v 22:38 odesílatel Dmitry Shachnev napsal: > However upstream python-keyring has dropped Python 2 support, and I want > to upgrade to a newer release, so Python 2 support will be dropped sooner > or later. > upstream drop of Python 2 support doesn't mean you need to drop it too. For example I'm keeping pytest at lower version for same reason. Please respect Python 2 removal and release team rules and don't remove Python 2 support untill all reverse(-build) depends (+autopkgtests) are fixed. Removing of python-keyring is blocked by 4 bugs, But recursively it's dozens, for example python-mock is affected. Removing this means marking dozens off Debian packages as AUTORM. Please be careful. If you really need to upgrade python-keyring to newer version, you could split it into two source packages. But do it only if it's really needed. Thanks for understanding. -- Best regards Ondřej Nový
Re: Joining the DPMT Team
Hi, st 4. 12. 2019 v 17:07 odesílatel Boyuan Yang napsal: > ... Can > anyone add me into the DPMT Team? My Salsa account is @byang. > done. -- Best regards Ondřej Nový
Re: Severity bump script
Hi, po 2. 12. 2019 v 20:36 odesílatel Paul Gevers napsal: > #942999 and #936537 > ah right. I think this is correct. There is nothing else "in Python 2 removal process" to do on "someone else" packages. Work needs to be done in these packages so raise severity here to unblock other bugs and continue Python 2 removing effort. -- Best regards Ondřej Nový
Re: Severity bump script
Hi, po 2. 12. 2019 v 20:28 odesílatel Paul Gevers napsal: > I understand the drive to push for Python 2 removal and sympathize with > it. The issue I had yesterday with the process is that "leaf" was > wrongly defined, it was looking at Depends, instead of also including > Build-Depends. > huh? We are not bumping any "blocked" bugs. Depends/Build-Depends/Recommends/autopkgtests usage marks bug as blocked. Any example of "wrong definition" please? -- Best regards Ondřej Nový
Re: Severity bump script
Hi, čt 28. 11. 2019 v 19:07 odesílatel Sandro Tosi napsal: > this is live now, with the following header: > cool, thanks again! -- Best regards Ondřej Nový
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
Hi, čt 28. 11. 2019 v 17:11 odesílatel Andreas Tille napsal: > Hmmm, what are the chances to get this applied? I've added > tbh dunno :) > in Git - but this will not reall fix the test. The only solution I'd see > otherwise is to deactivate the test. > you have two options: 1. deactivate the test (remove Testsuite: autopkgtest-pkg-python from d/control) 2. call `autodep8 >debian/tests/control` and edit result -- Best regards Ondřej Nový
Re: autopkgtest-pkg-python fails if package name is python-pyMODULENAME (Was: Bug#945768: python-pypubsub: autopkgtest failure: No module named 'pypubsub')
Hi, čt 28. 11. 2019 v 16:04 odesílatel Andreas Tille napsal: > Is there any trick to enable autopkgtest-pkg-python detecting the correct > module name? > no (not yet? See: https://salsa.debian.org/ci-team/autodep8/merge_requests/6 ) -- Best regards Ondřej Nový
Re: Severity bump script
Hi, čt 28. 11. 2019 v 4:12 odesílatel Sandro Tosi napsal: > i'm not sure we can: in > https://lists.debian.org/debian-python/2019/10/msg00096.html you say > "We need to prepare draft of RC-bumper email", is this draft ready? > ah, you are right. > add the description to the header (as comment) of a mail to control@? > this is only way to go imho. I think we should use something simple/short like this: --cut-- Raising severity of Python 2 removal bugs, for details see: https://lists.debian.org/debian-devel-announce/2019/11/msg0.html --cut-- Thanks Sandro for working on this. -- Best regards Ondřej Nový
Re: Severity bump script
Hi, pá 22. 11. 2019 v 22:22 odesílatel Sandro Tosi napsal: > I've removed bugs that are marked as blocked by; we're now down to 487 > unique severity raies > cool. Checked and imho it works fine now. So I guess we can run it. Thanks. -- Best regards Ondřej Nový
Re: Severity bump script
Hi Sandro, thanks for first version. I randomly checked few lines and found this: # libufo0 is an application and has low popcon (25 < 300) severity 938743 serious # libufo-bin is an application and has low popcon (4 < 300) severity 938743 serious # libufo-dev is an application and has low popcon (5 < 300) severity 938743 serious # python-ufw is a module and has 0 external rdeps But in bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938743 is Fix blocked by 938744: ufo-filters: Python2 removal in sid/bullseye So because 938743 is blocked by 938744, we should not raise severity of 938743, right? Thanks. -- Best regards Ondřej Nový
Re: getmail: Python2 removal in sid/bullseye
Hi, út 12. 11. 2019 v 16:37 odesílatel Osamu Aoki napsal: > Upstream is active and prides to keep python 2.5 compatibility code in > it ... (Not just 2.7). I (Osamu Aoki ) and dkg even > made some effort to support both 2 and 3 but the idea was rejected by > upstream in 2018. that's odd :/ > I think this qualifies for "py2keep". > i don't think so. Imho is better to support Py3 in Debian with our patches. If Debian and Fedora demonstrate its python3 removal, I am sure the > upstream may change his thought. If you have some progress indicator, > that can be used to convince getmail upstream. I or dkg need a solid > fact to restart conversation with the upstream. > yes, we have! :) http://sandrotosi.me/debian/py2removal/py2removal_progress.png Almost half of work is done in ~ 3 months. -- Best regards Ondřej Nový
Re: Python 2 removal in sid/bullseye: Progress and next steps
Hi, po 11. 11. 2019 v 12:07 odesílatel Yves-Alexis Perez napsal: > generic question about the interaction between the python transition and > current situation with NEW processing. > I think it's unrelated. State of NEW processing is stable for long time. But if you need to accept NEW binary-only I think it's fine to ping ftp-masters over IRC. I already did this few times and they don't bite :) -- Best regards Ondřej Nový
Severity bump script
Hi Sandro, -- Forwarded message - > We are going to raise the severity of the py2removal bugs to "serious" in several steps. In the > first phase we are going to raise severity of the py2removal bugs for > all leaf module packages and low popcon (< 300) application packages. > Bugs marked with the "py2keep" user tag will not have their severity > raised. is there any progress with script from your site please? First we need list to check. Thanks a lot. -- Best regards Ondřej Nový
Re: python-urllib3 1.25.6 uploaded to experimental (closes CVE-2019-11236) but fails build tests
Hi, út 29. 10. 2019 v 13:29 odesílatel Michael Kesper napsal: > > I see. Still an odd kind of protection though. The attacker can just > downgrade themselves. > > No. A sensible server will not talk to you if your requested SSL version > is too low. > pub.orcid.org seems to use absolutely outdated and insecure software > versions. > right. If you want good security, you need to limit TLS version on both side (client-urlib3 and server-whatever). Than downgrade attack is not possible. -- Best regards Ondřej Nový
Re: Discussing next steps for the Python2 removal
Hi, po 28. 10. 2019 v 10:56 odesílatel Simon McVittie napsal: > The maintainer of a leaf package can do this in a few minutes at any > time, but library packages with many reverse-dependencies (for example > dbus-python) don't really have that option, so I hope using autorm for > library packages is not on the table at this stage? > but we are still talking about __leaf__ packages so dbus-python is irelevant, right? -- Best regards Ondřej Nový
Re: Request to join DPMT
Hi, so 26. 10. 2019 v 21:33 odesílatel Jeremy Bicha napsal: > Please add me to https://salsa.debian.org/python-team/modules > done, welcome. :) > I expect to help out a bit with the Python2 removals thanks a lot! -- Best regards Ondřej Nový
Re: Discussing next steps for the Python2 removal
Hi, pá 25. 10. 2019 v 9:09 odesílatel Rebecca N. Palmer napsal: > Not the whole source package, but we do want to remove the py2 binary. > Maybe there should be two versions of the email, with the one for py2/3 > packages saying 'NMU' instead of 'removal'? > this is not how autorm works. You can't remove from testing only one of two binary package from same source package. You are removing package as a whole. But maintainer can anytime fix that bug by removing py2 binary from source package, which is few minutes work. -- Best regards Ondřej Nový
Re: Discussing next steps for the Python2 removal
Hi, pá 25. 10. 2019 v 3:30 odesílatel Sandro Tosi napsal: > do we really want to remove from testing (and subsequently from > debian, as mentioned below) if it both has a py2 and a py3k package? > should we limit this to py2-ONLY packages? > yes and no. If maintainer wants to keep package in Debian, fix is simple: Just remove one binary package. If nobody cares (no team upload, no NMU) we want to move forward and remove that package. > * bug is not marked as py2keep > > * all modules and low popcon apps (< 300) > > JFYI for now i was steering clear of removing py2 support even of > modules with high popcon (while it's true they may not have any rdeps > in the archive, there could be plenty of 3rd party code using them). > we want to remove Python 2 in bullseye ideally. So no 3rd party code will be using them, because there will be no Py2 :) > is there any plan to make some of this tags an upload-rejecting one? > maybe later? -- Best regards Ondřej Nový
Re: Discussing next steps for the Python2 removal
Hi, notes from this meeting ( https://gobby.debian.org/export/Teams/Python/Py2Removal): We want to bump all bugs to RC bugs, if they are: * leaf package * with py2 binary * bug is not marked as py2keep * all modules and low popcon apps (< 300) If package will be removed from testing (auto-rm), we are going to remove them from unstable. We are going to run this process semi-automatically (after more packages gets leaf). First version of list should be checked (emailed to this ML). We need to prepare draft of RC-bumper email. We will send email to d-d-a with current state, our next steps, etc. We are going to bump Lintian tags severity: * python-foo-but-no-python3-foo: warning->error * dependency-on-python-version-marked-for-end-of-life: pedantic->warning * new-package-should-not-package-python2-module: warning->error * build-depends-on-python-sphinx-only: warning->error * depends-on-python2-and-python3: info->warning * script-uses-unversioned-python-in-shebang: info->warning We would like to update Python policy and clearly state future of Python 2. Thanks everybody. -- Best regards Ondřej Nový
Re: [Request]
Hi, út 22. 10. 2019 v 14:26 odesílatel MARIE Alexandre < alexandre.ma...@synchrotron-soleil.fr> napsal: > I woud like to join debian-python team in order to maintain and package a > bunch of modules : > welcome :) -- Best regards Ondřej Nový
Re: Request to Join PAPT
Hi, st 9. 10. 2019 v 19:07 odesílatel Gabe Livengood napsal: > I am interested in joining the PAPT team. welcome :) -- Best regards Ondřej Nový
Re: Joining DPMT
Hi, pá 18. 10. 2019 v 23:30 odesílatel Fabrice Bauzac-Stehly napsal: > May I join the DPMT, pretty please? > welcome :) -- Best regards Ondřej Nový
Re: Request join to PAPT
Hi, čt 17. 10. 2019 v 4:36 odesílatel Emmanuel Arias napsal: > I would like join to PAPT. welcome :) -- Best regards Ondřej Nový
Re: Request to join PAPT
Hi, čt 17. 10. 2019 v 15:23 odesílatel Dr. Tobias Quathamer napsal: > I'd like join PAPT. welcome :) -- Best regards Ondřej Nový
Re: Joining the Debian Python Modules Team
Hi, po 21. 10. 2019 v 20:40 odesílatel Adam Cecile napsal: > I would like to join Debian-Python modules team welcome :) -- Best regards Ondřej Nový
Re: [Python-apps-team] pylint3 reverse dependencies.
Hi, čt 17. 10. 2019 v 14:46 odesílatel Emmanuel Arias napsal: > A team Upload is accepted, isn't? :-) > dh-python package is not team maintained. -- Best regards Ondřej Nový
Re: Raising severity to serious for some Python 2 leaf packages with no Python 3 support upstream
Hi, po 14. 10. 2019 v 4:52 odesílatel Thomas Goirand napsal: > But in both cases, it's going to take a very long time. Do we really > want to get stuck on these packages for like forever, or would it feel > ok to raise the severity to serious, so that the package gets > auto-removed and then we can work on removing Python 2 from its > dependencies? > for me it's perfectly fine to rise severity to serious of all leaf packages with py2remove bug as soon as possible. And let's do it "automatically" everytime any package gets leaf state. But to do this correctly, we need release goal. Do we have one? -- Best regards Ondřej Nový
Re: request to join DPMT
Hi, st 18. 9. 2019 v 12:30 odesílatel napsal: > I'd like to join the DPMT! > welcome :) -- Best regards Ondřej Nový
Re: Bug#940811: ITP: python-simplenote -- Python3 API wrapper for the Simplenote web service
Hi, so 21. 9. 2019 v 8:32 odesílatel Geert Stappers napsal: > i'm not sure if the 3 should/must goto into package name. > src: python-foo binary-python3: python3-foo binary-doc: python-foo-doc Thanks. :) -- Best regards Ondřej Nový
Re: What is the process to update the DPMT and PAPT policies?
Hi, po 16. 9. 2019 v 9:55 odesílatel Mattia Rizzolo napsal: > I wonder, I think the historical reasons for papt and dpmt to be separated > don't quite stand anymore. Perhaps the only difference left is the actual > technical difference between an application and a module as described in > the python policy (rather in the team one). > I don't know historical reason but I agree we could/should merge DPMT and PAPT policies together. -- Best regards Ondřej Nový
Re: What is the process to update the DPMT and PAPT policies?
Hi, po 16. 9. 2019 v 1:59 odesílatel Louis-Philippe Véronneau napsal: > What is the process to update the DPMT and PAPT policies? we don't have process/policy to update policy. So I will propose one and let's add this process to policy itself: - anyone can submit merge request - with MR created, send email to ML - give seven? days grace period to discuss proposal - to accept MR we needed at least one? ack from DPMT admins Comments? :) -- Best regards Ondřej Nový
Re: Re: Bug#920127: Removed package(s) from unstable
Hi, po 9. 9. 2019 v 5:37 odesílatel Sandro Tosi napsal: > Nope. This package did not see an upload since Aug 2013. it was > orphaned since Jan 2019. Nobody stepped up. It ended up removed. > > If the upstream author or a debian packager wants it in debian, it's > easy enough to re-introduce it. > +1 -- Best regards Ondřej Nový
Re: Joining PAPT
Hi, po 2. 9. 2019 v 21:42 odesílatel Denis Danilov napsal: > could someone from salsa-python-admins check my join request please? > fortran-language-server package is implemented in python, so it looks like > it > makes sense to have it under PAPT. > done, welcome :) -- Best regards Ondřej Nový
Re: Why is dh_auto_clean calling python2.7? (Was: Bug#937624: python-burrito: Python2 removal in sid/bullseye)
Hi,
so 31. 8. 2019 v 10:06 odesílatel Dmitry Shachnev
napsal:
> I see that python-all is still present in Build-Depends (line 9).
>
yep, that's reason. pybulid detects python{,-all} in B-D and if they are
present, it runs clean for Python 2.
--
Best regards
Ondřej Nový
Re: reverse-depends problem
Hi, út 27. 8. 2019 v 10:36 odesílatel Ondrej Novy napsal: > yesterday I checked reverse dependencies of python-xlrd with: > and same problem with python-ldap. -- Best regards Ondřej Nový
reverse-depends problem
Hi, yesterday I checked reverse dependencies of python-xlrd with: reverse-depends -lb python-xlrd - and - reverse-depends -l python-xlrd There were none so I removed python-xlrd Python 2 package. But today same commands returns reverse dependecies. So it looks like "reverse-depends" is not always safe for checking reverse dependencies. Hm? -- Best regards Ondřej Nový
Re: Joining Python Modules Team
Hi, po 12. 8. 2019 v 23:19 odesílatel Moritz Mühlenhoff napsal: > Sure, I've read the policy and acking it, my Salsa login is "jmm". > welcome :) -- Best regards Ondřej Nový
Re: python-easygui upload or DM upload access request
Hi, po 12. 8. 2019 v 16:06 odesílatel Andreas Noteng napsal: > ...drops the python2 package. > onovy@sid:~/tmp/python-easygui$ reverse-depends python-easygui Reverse-Recommends == * education-development -- Best regards Ondřej Nový
Re: Joining Python Modules Team
Hi, ne 11. 8. 2019 v 22:43 odesílatel Moritz Mühlenhoff napsal: > ... can you please add me to the Python Modules Team > project on Salsa? > process of joining team is explained in our policy: https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Thank you. -- Best regards Ondřej Nový
