Re: [RFC] DPT Policy: Canonise recommendation against PyPi-provided upstream source tarballs

2021-06-26 Thread Martin
On 2021-06-26 02:04, Paul Wise wrote: > I would like to see #2 split into two separate tarballs, one for the > exact copy of the git tree and one containing the data about the other > tarball. Then use dpkg-source v3 secondary tarballs to add the data > about the git repo to the Debian source

Re: Remove trac from Debian 11?

2021-05-10 Thread Martin
On 2021-05-10 14:00, Andrius Merkys wrote: > I do not think that slowing down of development is reason serious enough > to remove a package which is otherwise fine. Or are there other reasons > that I am not aware of? I don't have a problem with slow development, but the current version is

Remove trac from Debian 11?

2021-05-10 Thread Martin
Dears, trac is a long-time Debian package, uploaded first by Jesus Climent in 2004. I like the traditional look of Trac and its climate-friendly resource usage :-) Now, while Trac is still maintained upstream and has been ported to Python 3 recently, development slowed down since long and the

Re: Python package situation

2021-02-16 Thread Martin
On 2021-02-17 02:13, Andrey Rahmatullin wrote: > Are you asking about testing or stable? Because for stable the "packages > are either outdated or do not exist" situation is somewhat expected and > testing is not that interesting case, though even in testing we may have a > lot of outdated

Python package situation

2021-02-16 Thread Martin
On 2021-02-16 10:17, Bastian Venthur wrote: > I *wish* I could > just install everything via the Debian Packaging System, but the reality for > most relevant Python packages is very different: packages are either > outdated or do not exist in Debian Are you talking about many packages? Or only

Re: upstream python concerns, python3-full package for bullseye

2021-02-12 Thread Martin
On 2021-02-12 10:16, Thomas Goirand wrote: > I mostly agree to add a metapackage. I just don't agree with the choice > of package name. It makes our user believe that Python isn't "full" > without it, and they then may install it when they don't need it to > consume whatever is packaged in Debian.

Re: python3-(py)crypto(dome)?

2020-12-05 Thread Martin
On 2020-12-05 19:51, Andrey Rahmatullin wrote: > On Sat, Dec 05, 2020 at 02:43:44PM +0100, Martin wrote: > > Package wokkel has changed the dependency from python3-crypto to > > python3-cryptodome, leading to #975748 and #975770. > The changelog entry says "Switch

python3-(py)crypto(dome)?

2020-12-05 Thread Martin
Dears, I'm a little confused about what the correct name for the binary package python3-pycryptodome should or will be. Because https://bugs.debian.org/891619 talks about renaming it and/or providing python3-crypto. Package wokkel has changed the dependency from python3-crypto to

Re: Granting `Janitor` direct access to our teams repos

2020-07-27 Thread Martin
On 2020-07-27 20:18, Sandro Tosi wrote: > So: let's just make that automatic? Thoughts? Yes.

Re: packaging DiscoDOS - a cli tool for vinyl DJs

2020-05-15 Thread Martin
On 2020-05-15 17:43, jojo wrote: > I'd like to join the list because I think my software is a valuable addition > to the debian universe, my ultimate goal would be to bring it into Ubuntu > Studio because it is music-related. Cool! Sounds like a very interesting program, indeed!

Remove or update pyfeed and xmlelements

2020-04-05 Thread Martin
Hi Matteo, hi Thomas, the new version of salutatoi does not need python-feed and python-xe anymore. AFAIK, there are not other dependencies on them. Maybe you would like to ask for removal? If not, remember to update them to Python 3 (currently supported only in experimental, but still with

Re: Non-migration of cssutils

2020-02-06 Thread Martin
Quoting Mattia Rizzolo : Given that the whole stack of packages is scheduled to get out on 2020-02-16, it's more likely that everything will be removed, and then cssutils will migrate back (and with it everything that will be suitable to migrate back into testing) at the next britney run.

Re: Non-migration of cssutils

2020-02-06 Thread Martin
Quoting Mattia Rizzolo : I reckon the way forward is to fix those two FTBFS in calibre. If calibre gets removed from testing on 2020-02-16, the reason for non-migration of cssutils and removing depending packages from testing, e.g. gajim, vanishes. Will this work out due to britneys wisdom? Or

Non-migration of cssutils

2020-02-06 Thread Martin
Hi, at https://tracker.debian.org/pkg/cssutils I don't see, why the package does not migrate. Some package depend on cssutils and will be removed from testing soon... Any idea what's wrong with cssutils? TIA & Cheers

Re: Future of Trac in Debian

2020-01-03 Thread Martin
Quoting Sandro Tosi : So Jan 1 arrived, what do you think we should do? i didnt see any progress on the port to python3 upstream; should we start filing RM for trac extensions/plugins and once they are gone, RM src:trac? I don't expect a Python 3 version of Trac before a year from now. Debian,

Help with interpreting piuparts error

2019-12-29 Thread Martin
Hi, I'm not sure how to interpret this 14799 lines piuparts log: https://piuparts.debian.org/sid/fail/python-aiohttp-session-doc_2.9.0-2.log It says "ERROR: FAIL: Installation and purging test." Any idea what's wrong with the package? TIA! Cheers

Re: Future of Trac in Debian

2019-11-29 Thread Martin
On 2019-11-29 18:13, Nicholas D Steeves wrote: > IMHO one of the Debian Trac uploaders should post to the #12130 Trac > ticket informing them of our plan. I linked to the email of 2019-10-14: https://trac.edgewall.org/ticket/12130#comment:63

Re: Future of Trac in Debian

2019-11-29 Thread Martin
On 2019-11-29 16:24, Sandro Tosi wrote: > I know it may sound hard, but is it now time to remove trac from > Debian, and ideally re-introduce it back when it's being ported to > py3k? See also: https://groups.google.com/forum/#!topic/trac-users/5VMI83sbqFs What would be the alternative? It would

Re: Python 3 transition question

2019-09-04 Thread Martin Kelly
On 9/2/19 1:18 PM, Martin Kelly wrote: On 9/1/19 10:07 PM, Scott Kitterman wrote: On September 2, 2019 4:00:53 AM UTC, Sandro Tosi wrote: I would just stop building these.  And if the reverse dependencies have a py2removal bug itself, then comment in these issues that the suggested

Re: Python 3 transition question

2019-09-02 Thread Martin Kelly
a couple, sagemath and simpy) that would be then uninstallable, and so on and so forth for all their rdeps. Martin, i think for now the only option is to keep the py2 packages around until we're ready to drop them (ie they have 0 rdeps). I just checked on packages.d.o and according to it, python-gmp2

Python 3 transition question

2019-09-01 Thread Martin Kelly
the Python 2 versions of these packages (and invalidate the Suggests/Recommends of these other packages), or should I instead just document this issue? If I document it, where should this documentation go? Thanks, Martin

Re: dropping python2 [was Re: scientific python stack transitions]

2019-07-09 Thread W. Martin Borgert
On 2019-07-08 10:00, Elena ``of Valhalla'' wrote: > I don't think it would be accepted by backports, since it goes against > the requirement that stuff in backports is in testing (and meant to > remain there when it becomes stable). I'm not sure, but building an additional binary package from the

Re: Please enable me pushing to python-team/applications

2019-03-21 Thread W. Martin Borgert
On 2019-03-21 00:47, Thomas Goirand wrote: > Can't you guys just simply give write access to Andreas? What's the > issue? Why is it taking so long? This really give the feeling the "team" > is still very much dysfunctional, Maybe two, three people more can get "owner" permissions?

Remove python-social-auth?

2019-02-11 Thread W. Martin Borgert
Hi, I like to make python-social-auth a transitional package which installs social-auth-core and social-auth-app-django. Which is practically the new project by upstream. Or just remove it? We don't want python-social-auth in buster, do we? TIA & Cheers

Re: Dropping Python 2 support for web.py before buster

2019-02-04 Thread W. Martin Borgert
On 2019-02-04 12:14, Raphael Hertzog wrote: > Anyway, the fact that we have one known user should not forbid you > to go forward with all this. I will change the Kali infrastructure > to use something else, most likely buildd and wannabuild. Or maybe port rebuildd to Python 3?

Re: Help with setuptools-related build break

2019-01-27 Thread Martin Kelly
On 1/26/19 4:56 PM, Scott Kitterman wrote: On Saturday, January 26, 2019 04:05:50 PM Martin Kelly wrote: Hi, I'm attempting to release a new version of my package python-gmpy2 [1] and am hitting a bug that I can't figure out how to resolve. Specifically, in the latest version under pbuilder

Help with setuptools-related build break

2019-01-26 Thread Martin Kelly
guidance and/or debugging suggestions? Thanks, Martin [1] https://salsa.debian.org/python-team/modules/python-gmpy2

Re: Dropping Python 2 support for web.py before buster

2019-01-22 Thread W. Martin Borgert
On 2019-01-22 15:02, Julien Danjou wrote: > I'm not actively maintaining rebuildd for years now. I'm not even sure > it has still any user. I wouldn't spend time on porting rebuildd nor I > would let it block it updating web.py. > Not sure what's the other solution would be (removal?) but if you

Re: Dropping Python 2 support for web.py before buster

2019-01-22 Thread W. Martin Borgert
Quoting Mattia Rizzolo : On Tue, Jan 22, 2019 at 12:18:09PM +0100, W. Martin Borgert wrote: I'm going to package the latest git master of web.py¹, because of Python 3.7 compatibility. It has a new dependency on cheroot², which has only a Python 3 version in Debian. I could ask Julien to provide

Dropping Python 2 support for web.py before buster

2019-01-22 Thread W. Martin Borgert
Hi, I'm going to package the latest git master of web.py¹, because of Python 3.7 compatibility. It has a new dependency on cheroot², which has only a Python 3 version in Debian. I could ask Julien to provide a Python 2 package of cheroot for buster, but I prefer to drop Python 2 support of

cssutils salsa PR review or permission update

2019-01-17 Thread Martin Pitt
, Martin

Re: Matplotlib 3.0 - update ok?

2018-10-16 Thread W. Martin Borgert
Quoting Steffen Möller : Now, I am tempted to create a package matplotlib3 instead of forcing everyone to update from this long term release (see https://matplotlib.org/). Any opinions from your sides? I wonder, whether it's easier to wait for buster and then create an orange backport?

Re: git-dpm -> gbp conversion (mass-change)

2018-08-03 Thread W. Martin Borgert
On 2018-08-03 10:08, W. Martin Borgert wrote: > On 2018-08-03 08:04, Simon McVittie wrote: > > There is no upstream/master, upstream/unstable, upstream/stretch or > > similar in DEP-14, because: > > I did not suggest mingling upstream branches with Debian > versions

Re: git-dpm -> gbp conversion (mass-change)

2018-08-03 Thread W. Martin Borgert
On 2018-08-03 08:04, Simon McVittie wrote: > There is no upstream/master, upstream/unstable, upstream/stretch or > similar in DEP-14, because: I did not suggest mingling upstream branches with Debian versions, which seems to be your impression. I just (maybe wrongly) thought, that upstream/master

Re: git-dpm -> gbp conversion (mass-change)

2018-08-03 Thread W. Martin Borgert
On 2018-08-03 04:33, Scott Kitterman wrote: > On August 3, 2018 3:51:00 AM UTC, "W. Martin Borgert" > wrote: > >How about changing "upstream" to "upstream/latest" (for upstream > >releases, typically for unstable) and "upstream

Re: git-dpm -> gbp conversion (mass-change)

2018-08-02 Thread W. Martin Borgert
On 2018-08-03 11:06, Ondrej Novy wrote: > 2. change default branch to debian/master How about changing "upstream" to "upstream/latest" (for upstream releases, typically for unstable) and "upstream/master" (for following upstream master, typically for experimental)?

Request to join the Python Modules team

2018-07-14 Thread Martin Kelly
(https://python-modules.alioth.debian.org/python-modules-policy.html), as stated in https://wiki.debian.org/Teams/PythonModulesTeam/HowToJoin, but the link is dead. Thanks, Martin

Name of the upstream branch

2018-05-08 Thread W. Martin Borgert
Dear team, https://wiki.debian.org/Python/GitPackagingPQ#Git_Branch_Names states: "we are strongly recommending you use DEP-14 style branch names" and below: "upstream - The un-Debianized upstream source." I ask to change the latter branch name to "upstream/latest", first, because that's what

Re: Backport of Python 3.6 for Debian Stretch?

2018-04-24 Thread W. Martin Borgert
Quoting Nguyễn Hồng Quân : Python 3.6 has much better performance than Python 3.5, especially on embedded computer (I tried and compared). This is interesting! Did you also compare Python 2.7 with 3.5/3.6? I'm looking for more reasons to finally port my embedded

Re: Backport of Python 3.6 for Debian Stretch?

2018-04-24 Thread W. Martin Borgert
Quoting Nguyễn Hồng Quân : We write an application which needs Python 3.6. Could you elaborate, why you need Python 3.6 instead of 3.5? Maybe there is a way to make your application work with 3.5? E.g. by backporting specific modules?

Re: Where to put docs of a -doc package for python 2 + 3 modules?

2018-03-13 Thread W. Martin Borgert
Quoting Thomas Goirand : Which is why I think we should have standardize on python-foo for the source package (which is what I do). Same here, even if foo is not yet taken. Save the environment, do not pollute the global packages namespace! :~)

Re: Where to put docs of a -doc package for python 2 + 3 modules?

2018-03-12 Thread W. Martin Borgert
On 2018-03-12 23:15, Thomas Goirand wrote: > But what now that python-foo is gone? Should I rename the doc package? No, but that's just my gut feeling.

Re: Where to put docs of a -doc package for python 2 + 3 modules?

2018-03-12 Thread W. Martin Borgert
Quoting Simon McVittie : In python-mpd-doc and python-dbus-doc, I installed the real documentation files in /u/s/d/python-*-doc, but placed symlinks to them in both /u/s/d/python-* and /u/s/d/python3-*. Perhaps that's a reasonable way to achieve the spirit of the Policy §12.3

Where to put docs of a -doc package for python 2 + 3 modules?

2018-03-12 Thread W. Martin Borgert
Hi, policy (12.3) says, that putting the contents of package-doc into /usr/share/doc/package/ (main package) is preferred over /usr/share/doc/package-doc/. debhelper detects the Python 2 package as main package. One can override this to the path for the Python 3 package, but both feels wrong to

Re: PAPT migrated to Git on Salsa

2018-02-24 Thread W. Martin Borgert
On 2018-02-24 23:49, Stefano Rivera wrote: > 'trac-batchmodify', > 'trac-git', The functionality of those two is now part of trac itself. We might want to keep them for LTS purposes until they are not part of any LTS release anymore. But I don't care much...

Re: Help proposed for migration of PAPT repos to Salsa

2018-02-23 Thread W. Martin Borgert
Quoting Stefano Rivera : I didn't get much review last time, but there did seem to be a general +1 From me not only "+1", but also "thank you"!

PAPT repo at salsa.d.o open for new packages now?

2018-02-14 Thread W. Martin Borgert
Hi, if I have a Python program, that currently is not yet maintained by PAPT, but want to move it to the team: May I use salsa.d.o/python-team/applications/ now? Any objections? TIA & Cheers

Re: Move to salsa? Team structure preview ready

2018-02-08 Thread W. Martin Borgert
Quoting Ondrej Novy : 2018-02-08 10:14 GMT+01:00 Ondrej Novy : I created team "python-team" in salsa with 3 subgroups: interpreter modules applications OK. I can do DPMT GIT migration, but I need agreement on new structure. OK! :~) We can merge two

Re: Merge modules and apps team?

2018-02-07 Thread W. Martin Borgert
On 2018-02-07 09:58, Matthias Klose wrote: > I don't think that is a good idea. Both teams are not very active when it > comes > to address RC issues and updating to new upstream versions. From my point of > view the apps team is worse than the modules team in this regard. In fact, this is one

Move to salsa? Merge modules and apps team?

2018-02-06 Thread W. Martin Borgert
Hi, how about moving the Python team(s) to salsa? And how about merging the modules and apps teams into one? Moving git packages (modules team) is very easy using import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git Moving svn packages (apps team) is probably more work. Any

Re: Update wokkel?

2018-01-02 Thread W. Martin Borgert
On 2017-10-27 17:26, Angel Abad wrote: > Because there is no official release with these changes, I will > write upstream developer and I will tell you. Was there any outcome? TIA!

Help the orphans! (here: Python modules)

2017-11-29 Thread W. Martin Borgert
Hi, unfortunately, I had to orphan some packages: python-activipy -- implementation of ActivityStreams 2.0 (#882871) python-mpld3 -- D3 viewer for matplotlib (#882858) python-mplexporter -- general matplotlib exporter (#882857) python-odoorpc -- pilot Odoo servers through RPC (#882870)

Update wokkel?

2017-10-26 Thread W. Martin Borgert
Hi Angel and team, would you mind, if I update wokkel and close #735304 (teams git repo) and #879712 (Python 3 support)? I would add myself to uploaders, too. TIA & Cheers signature.asc Description: PGP signature

Re: pycharm package in debian

2017-10-02 Thread W. Martin Borgert
On 2017-10-02 10:37, Thomas Goirand wrote: > On 10/01/2017 11:50 PM, Matthias Klose wrote: > > Do you want point users to the five year lagging behind eclipse package in > > Debian? > > Why 5 years? We do release stable approx every 2.5 years... 5 years minus 12 days: Eclipse 3.8.1 has been

Re: pycharm package in debian

2017-10-01 Thread W. Martin Borgert
On 2017-10-01 23:16, Andrey Rahmatullin wrote: > On Sun, Oct 01, 2017 at 04:52:55PM +0200, W. Martin Borgert wrote: > > I usually start to use software, when it arrives in Debian. > > Or I package it. If there is some snap or other third party > > package, I

Re: pycharm package in debian

2017-10-01 Thread W. Martin Borgert
On 2017-10-01 17:16, Ghislain Vaillant wrote: > Most likely a lot. We are talking about a large application with probably > quite a few dependencies in Java / Kotlin. > > Why not? Because failure to commit to regular updates would feed the > current narrative that Debian ships old and loosely

Re: pycharm package in debian

2017-10-01 Thread W. Martin Borgert
On 2017-10-01 08:26, Ghislain Vaillant wrote: > May I ask what would be the benefit for pycharm to be in Debian, when we > already have the official Jetbrains Toolbox App or the snap package as means > to install and update the application? I usually start to use software, when it arrives in

Re: Docs only packages?

2017-09-24 Thread W. Martin Borgert
On 2017-09-24 10:35, Diane Trout wrote: > What do people think about having documentation only packages? Good thing. Like manpages etc. signature.asc Description: PGP signature

Re: Question about binary sphinx inventory files

2017-08-26 Thread W. Martin Borgert
On 2017-08-26 11:42, Dmitry Shachnev wrote: > https://codesearch.debian.net/search?q=html%2Fobjects%5C.inv+path%3Adebian%2Fpatches%2F.* I should use codesearch more often :~) And "searx" should have a backend for it!

Re: Question about binary sphinx inventory files

2017-08-26 Thread W. Martin Borgert
On 2017-08-25 22:36, Tristan Seligmann wrote: > In the case of Python's documentation inventory specifically, this is built > and distributed in the python*-doc packages, and there should be no need to > download it from python.org. Thanks! I use the packaged file now in python-simpy3. AFAIK,

Uploading Python modules which drop support for Python 2?

2017-08-04 Thread W. Martin Borgert
Hi team, pysolar upstream version 0.7 dropped support for Python 2, so I did not upload it for stretch. I'm considering upload for buster now. What do you think? Cheers signature.asc Description: PGP signature

Re: django-cms in Debian?

2017-06-27 Thread W. Martin Borgert
Quoting Dominik George : at Teckids, we are about to start using Django CMS for our website. We have a policy to only use Debian stable/main if at all possible. This is a very useful policy! So I wonder whether there is a reason django-cms is not in Debian? (Apart from

Re: PAPT git migration

2017-05-31 Thread W. Martin Borgert
Many thanks, Stefano, for your work on this! On 2017-05-31 20:58, Stefano Rivera wrote: > * trac-batchmodify: OK > * trac-git: missing a tag [DONE] Those two are only in oldstable. Not sure whether it is worth to migrate them at all. > * trac-privateticketsplugin: missing some tags [DONE] This

alioth python-apps access for moschlarb-guest

2016-12-27 Thread Christoph Martin
Der Python-Apps Alioth project maintainers, please give moschlarb-guest access rights to the repositories in python-apps. He wants to help maintain together with me nagstamon. Regars Christoph -- Christoph Martin

Re: [Python-modules-commits] [python-social-auth] 55/89: Merge pull request #821 from open-craft/saml-no-idp

2016-12-24 Thread W. Martin Borgert
On 2016-12-24 10:48, Sandro Tosi wrote: > what's all this? 89 commits? are you pulling commits from upstream > git? this looks just spam to the mailing list Sorry, this was not intended. I pulled upstream in fact, but I was not aware that I was pushing it to our git, too. :~(

Re: DEP 8: Gathering Django usage analytics

2016-11-07 Thread W. Martin Borgert
Quoting Barry Warsaw : I'd love to know if there's a Debian-wide policy on such things. E.g. if "opt-out with informed user consent" was an official policy that we could clearly point to and reference, it would greatly help provide guidance to both Debian maintainers and

Joining the team

2016-10-17 Thread Martin Kratochvíl
statement that you have read https://python-modules.alioth.debian.org/policy.html and that you accept it. I read the policy and I'm accepting it. Thanks -- Ing. Martin Kratochvíl

Re: on keep providing python 2 packages

2016-08-19 Thread W. Martin Borgert
On 2016-08-19 08:19, Sandro Tosi wrote: > does anyone else agrees with this view? should we clarify that, when > available, python2 modules must be provided (along with their py3k)? Yes.

Re: using git-dpm or plain git-buildpackage in PAPT and DPMT (was: PAPT Git)

2016-08-10 Thread W. Martin Borgert
On 2016-08-10 10:18, Thomas Goirand wrote: > Instead of > accepting the merge, and resolving conflicts later on, git-dpm goes into > the rebase conflict mode of Git, and it's often not obvious what to do > there. Messing-up everything, and restart from scratch (and then iterate > until done

PAPT Git (was: pypi2deb 1.20160809 and --profile dpmt)

2016-08-09 Thread W. Martin Borgert
On 2016-08-09 23:28, Daniel Stender wrote: > On this occasion ... let it be me to start the discussion: let's get into Git > also for Python Apps soon. A common VCS for both DPMT and PAPT would be nice, indeed. (I have been reminded rightfully by both Piotr and Sandro, that PAPT still uses SVN.

Re: removing $(PYBUILD_NAME).egg-info with clean target in debian/rules?

2016-04-29 Thread Martin A. Brown
fo/" > >and keeping .egg-info here. > >But if you don't want it here, use dh_clean OR create file debian/clean >(man dh_clean for complete doc). I will do that. Thank you both for your quick replies. Best, -Martin -- Martin A. Brown http://linux-ip.net/

removing $(PYBUILD_NAME).egg-info with clean target in debian/rules?

2016-04-29 Thread Martin A. Brown
istclean' or something else I should be using? Thank you in advance, -Martin [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822722 -- Martin A. Brown http://linux-ip.net/

Re: Autopkgtest smoke test for Python libraries

2016-03-01 Thread Martin Pitt
dependencies can still break your module in subtle ways, but at least things like new/removed Python versions, linker errors, wrong paths etc. are spotted. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature

Re: Autopkgtest smoke test for Python libraries

2016-03-01 Thread Martin Pitt
rrors, etc. As said above, maybe in the future we want to try and run upstream test suites, but this will need a lot more heuristics (starting with additional test deps). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: PGP signature

Request to join DPMT

2016-01-28 Thread Tim Martin
Hi, I'd like to join the DPMT. I'm interested in packaging some Python libraries for Yang and Netconf (pyang and pyangbind). My Alioth username is timmartin-guest. I've read and agree to https://python-modules.alioth.debian.org/python-modules-policy.html Tim

Re: conflicting packages python-pysocks and python-socksipy

2016-01-09 Thread W. Martin Borgert
On 2016-01-08 01:54, Scott Kitterman wrote: ... > This is done (#810306). ... > Bug#810309: torchat > Bug#810308: python-sleekxmpp > Bug#810307: offlineimap Scott, many thanks for filing the bugs and fixing python-socksipy!

conflicting packages python-pysocks and python-socksipy

2016-01-04 Thread W. Martin Borgert
Hi, TLDR: Both are the same, providing the "socks" module. We should remove one of them. Maybe renaming the other to python-socks. Longer story: Recently, I upgraded the outdated python-socksipy package. This involved following a new upstream. Later I was informed, that the new upstream was

python-cherrypy (was: packages without any uploaders)

2015-12-12 Thread W. Martin Borgert
On 2015-12-12 21:41, Mattia Rizzolo wrote: > https://tracker.debian.org/pkg/python-cherrypy > > This package, python-cherrpy, is Maintainer: DPMT, but has nobody listed > in Uploaders. ... > I'm CCing the former maintainer, since I don't know if he follows this > list. If neither Gustavo nor you

Re: python-cherrypy (was: packages without any uploaders)

2015-12-12 Thread W. Martin Borgert
On 2015-12-13 00:22, W. Martin Borgert wrote: > If neither Gustavo nor you were interested in CherryPy, I would > consider putting my name in the Uploaders field. I would > probably upgrade the package to version 3.8.1 and add a Python 3 > package - we still ship seven year old 2.

pyftpdlib: Working on Python 3 etc.

2015-11-22 Thread W. Martin Borgert
Hi, just a heads-up email: I will try to work on some open bugs of python-pyftpdlib, mainly because I need the Python 3 version urgently. Janos, if you want me to stop, just say so! :~) Cheers

pristine-tar (was: Git migration schedule)

2015-10-22 Thread W. Martin Borgert
Quoting Julien Puydt : Do you know pristine-tar is orphaned ? (bug #737871) This is known to readers of this mailing list, e.g. https://lists.debian.org/debian-python/2014/10/msg00039.html So far, it just seems to work for (most of?) us. Cheers

Re: python-django-contact-form maintenance

2015-10-11 Thread W. Martin Borgert
On 2015-10-11 16:49, Christophe Siraut wrote: > I do not intend to continue maintaining python-django-contact-form, I > just removed myself from the uploaders field, maintainer is DPMT. > Tests are currently failing and package fails to build from source. > Upstream released a new version 3 months

team vs individual as maintainer (was: radical changes)

2015-10-07 Thread W. Martin Borgert
Quoting Piotr Ożarowski : I assume you all like other ideas, like no team in Maintainer, right? To me, "team maintenance" would mean, that the team appears in the "Maintainer" field. In "Uploaders" it doesn't make sense, so where would the team appear? Personally, I prefer

Re: team vs individual as maintainer

2015-10-07 Thread W. Martin Borgert
Quoting Piotr Ożarowski : [Barry Warsaw, 2015-10-07] * Team in Maintainers is a strong statement that fully collaborative maintenance is preferred. Anyone can commit to the vcs and upload as needed. A courtesy email to Uploaders can be nice but not required. * Team in

Re: Packaging Bokeh

2015-09-05 Thread W. Martin Borgert
On 2015-09-04 22:44, Diane Trout wrote: > I've made some limited progress trying to package Bokeh (BSD-3-Clause) Many thanks for working this! > I managed to get the version 0.9.1 from pypi installable. (Though since it > was > my own experiments I didn't remove the jquery / bootstrap

Re: RFS: python-simpy3/3.0.7+dfsg-1 [ITP]

2015-06-18 Thread W. Martin Borgert
On 2015-06-17 00:01, Larissa Reis wrote: After discussion on this list, I'm making the new simpy version a separate package (see thread starting from [1]). I still need a mentor to review and a sponsor for the package. Uploaded. Thanks for working on this package! I like, that people can move

Rename package? (Re: Request to join DPMT and RFS: python-simpy/3.0.7-1 [ITA])

2015-05-19 Thread W. Martin Borgert
Hi, sorry for the late reply: On 2015-05-02 03:07, Larissa Reis wrote: Changes since the last upload: * New upstream release (Closes: #729866) - Simpy 3 API is not compatible with Simpy 2. For information on porting from Simpy 2, see

Re: Python 2 d-d-a proposal

2015-04-15 Thread W. Martin Borgert
On 2015-04-15 16:27, Paul Tagliamonte wrote: I'd like to send an email to d-d-a asking that project to consider no longer creating new Debian tools in Python 2. Makes sense. I try to use Py3 whenever possible. Sometimes some libs are still missing, mainly when upstream is not very active. My

Remove Python 3 version of module to fix RC bug? (python-exif)

2015-01-25 Thread W. Martin Borgert
I just now don't have the time to look at bug #775609 (python3-exif doesn't work, RC). If nobody steps in, I would upload a new package w/o Python 3 support for jessie. Wheezy hat python-exif, but not python3-exif, so there is no regression for users of wheezy. Anyway, upstream made a new

Using pristine-tar (was: Keeping upstream commits separate from Debian packaging commits)

2014-10-12 Thread W. Martin Borgert
On 2014-10-12 14:49, Thomas Goirand wrote: Let's say there's a few more other people which were not accounted for and that were not at Debconf, those who prefers having upstream source code in the VCS are still the majority. And some weren't at Debconf and prefer to work with upstream sources.

Re: Fwd: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1

2014-09-23 Thread W. Martin Borgert
On 2014-09-23 22:29, Sandro Tosi wrote: there's some people who's subscribed to the commit ml, so getting all the changes done to our repos. Now, with the transition to git we are getting this: 135 emails for updating a package (and these are only upstream changes). Did you consider this side

Re: git-dpm vs gbp-pq: new upstream and patch refresh (long)

2014-09-05 Thread Martin Pitt
). So I'm not sure where switched from git-dpm came from? Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe

git (was: Making packaging Python modules fun again)

2014-01-27 Thread W. Martin Borgert
On 2014-01-27 00:14, Nicolas Dandrimont wrote: (a lot) I agree with everything. If somebody has time to update my packages to modern helpers, convert them from svn to git, or enable Python 3, please go on! About git: This needs clarification, e.g. will we settle on gbp? Shall our branch be

virtualenv --system-site-packages (was: PEP 453 affects Debian packaging of Python packages)

2013-09-25 Thread W. Martin Borgert
Quoting Barry Warsaw ba...@python.org: Sounds a lot like `virtualenv --system-site-packages` right? IMHO, --system-site-packages should be the default. IIRC, it was the default in squeeze (1.4.9), but is not anymore in wheezy (1.7.1.2). Opinions? -- To UNSUBSCRIBE, email to

Re: PEP 453 affects Debian packaging of Python packages

2013-09-20 Thread W. Martin Borgert
On 2013-09-20 13:52, Paul Tagliamonte wrote: It's not about keeping the libraries up to date, it's about keeping the applications up to date. ... Hell, we shouldn't even introduce a module unless it has an app using it. I tend to disagree here (slightly). Too me, it is very important, that

Disabling pip for root? (was: PEP 453 affects Debian packaging of Python packages)

2013-09-19 Thread W. Martin Borgert
On 2013-09-18 09:36, Paul Tagliamonte wrote: 1) pip isn't for global package management, for this is stupid. If we disabled root use of pip, I think we'd all be a bit happier. Very quick and very dirty patch attached. 4) Python modules from dpkg are borderline useless for developers.

Re: PEP 453 affects Debian packaging of Python packages

2013-09-18 Thread W. Martin Borgert
Quoting Matthias Klose d...@debian.org: Also the platform package manager should be the preferred way to install packages, not pip, so even a Recommends is a bit strange. Yes, a not-recommended field would make sense here. As a passionate pip hater I would go for a Conflicts, which finally

Re: Two binary from one source - how?

2011-10-14 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: Nice. But how do you create these install files? Can stdeb tool help with that? I don't know stdeb, but install files are easyly understood. See the documenation: http://www.debian.org/doc/manuals/maint-guide/dother.en.html#install (We're

Re: Two binary from one source - how?

2011-10-14 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: On Fri, Oct 14, 2011 at 2:07 PM, W. Martin Borgert deba...@debian.org wrote: ... The Python thing is to how to generate (and regenerate) these install files? I certainly don't want to create them by hand. I don't know any automated way

Re: Two binary from one source - how?

2011-10-13 Thread W. Martin Borgert
On 2011-10-13 21:31, anatoly techtonik wrote: There is a long standing bug in trac-bitten [1] to make a spin off a bitten-slave package from the same source that will include just slave client for running builds, which is independent of Trac [2]. Usually, you can build bitten-slave with:

  1   2   >