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: 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 ha

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 pr

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 web.py

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? I'm

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-02 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/mas

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)?

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 software :~)

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 recommendation while

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 me

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 subgroups later. No need to merge t

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 opinions?

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) python-oer

Re: Update wokkel?

2017-10-27 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. Very good, thanks! You can reach him via xmpp:ral...@ik.nu > I you want to co-maintain wokkel package we could talk about it. Well, it is not t

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 uploa

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'm

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 maint

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 Debia

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, only

Question about binary sphinx inventory files

2017-08-25 Thread W. Martin Borgert
Hi, I believe that a small number of Python module doc packages use binary Sphinx inventory (.inv) files during build, that are just downloaded from python.org by the package maintainer. I don't know anything about Sphinx nor how to encode/decode .inv files. https://pypi.python.org/pypi/sphobjinv

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 "noone started maintai

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

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 upstreams. In the i

Re: can we disable the bounce kicker? Re: confirm

2016-09-10 Thread W. Martin Borgert
On 2016-09-10 17:29, Sandro Tosi wrote: > in some countries (italy to name one) you would be > breaking the law accepting emails and not delivering them to the > recipient. Same in Germany, AFAIK.

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 properl

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. C

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 alrea

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.

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 w

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

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 Uploaders is a weak

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 to have the 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 librarie

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 mov

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

2015-05-23 Thread W. Martin Borgert
On 2015-05-22 19:08, Dmitry Shachnev wrote: > I think with such a little number of rdepends it's easier to port > them than to carry two packages. Yes - at least if we don't expect many people to have locally installed software depending on python-simpy. Anybody up to put simpy into git instead o

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 > http://simpy.rtfd.org/en/latest/topic

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 release

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 source

Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)

2014-10-11 Thread W. Martin Borgert
On 2014-10-10 13:13, Matthias Urlichs wrote: > Looking at that code, IMHO it should be sufficient to add the arguments > '--' and 'debian' to all calls of "git revlist". Who can add this? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble

Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)

2014-10-10 Thread W. Martin Borgert
On 2014-10-10 10:13, Raphael Hertzog wrote: > On Fri, 10 Oct 2014, W. Martin Borgert wrote: > > I assume, that the script uses post-receive, so it has access to > > all commits, including all affected paths. If so, generating only > > emails or IRC messages when debian/ is in

Re: Keeping upstream commits separate from Debian packaging commits (was: Fighting commit storm madness)

2014-10-09 Thread W. Martin Borgert
On 2014-10-10 15:59, Ben Finney wrote: > Agreed. This is a direct result of rebasing Debian packaging history > onto upstream VCS history, and keeping them all in the same repo as one > undifferentiated history, no? Not sure, but isn't this more a result of the scripts in use, to not differentiate

Fighting commit storm madness (was: [Python-modules-commits] [python-mplexporter] 135/135: Merge pull request #30 from rainwoodman/patch-1)

2014-10-09 Thread W. Martin Borgert
(Please, when using email, choose an appropriate subject. Thanks!) On 2014-10-09 10:02, Raphael Hertzog wrote: > I fixed the default configuration in setup-repository to limit to 20 > commits per push as a maximum. And I also limited the size of individual > commit emails to 1000 lines. I wonder,

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 si

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 "ma

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

2013-09-25 Thread W. Martin Borgert
Quoting "Barry Warsaw" : 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 debian-python-requ...@lists.debi

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 developer

Re: PEP 453 affects Debian packaging of Python packages

2013-09-18 Thread W. Martin Borgert
Quoting "Matthias Klose" : 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 would make pip

Re: Two binary from one source - how?

2011-10-14 Thread W. Martin Borgert
Quoting "anatoly techtonik" : On Fri, Oct 14, 2011 at 2:07 PM, W. Martin Borgert 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 to generate install

Re: Anybody to package new Bitten version?

2011-10-14 Thread W. Martin Borgert
Quoting "anatoly techtonik" : What does this testing implies? If there is a reference document on testing - somebody else may do this. This doc should exists even just to tell which parts can possibly go wrong as well as history of previous problems and mistakes. I'm running unreleased 0.6b3 for

Re: Two binary from one source - how?

2011-10-14 Thread W. Martin Borgert
Quoting "anatoly techtonik" : 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 leaving Python related

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: >

Re: Anybody to package new Bitten version?

2011-10-13 Thread W. Martin Borgert
Quoting "anatoly techtonik" : It's 9 months since the patch to upgrade trac-bitten was committed to Debian repository and it's not packaged yet. Can anybody release it? Problem is: I can't (currently) test new versions properly - no time. Second issue: I really want to have two packages: Master

Bug#638722: ITP: openerp6-web -- Enterprise Resource Management (web frontend)

2011-08-21 Thread W. Martin Borgert
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" Package name: openerp6-web Version : 6.0.3 Upstream Author : OpenERP URL : http://www.openerp.com/ License : OEPL (non-free, but relatively permissive) Programming Lang: Python D

Bug#638720: ITP: openerp6-server -- Enterprise Resource Management (server)

2011-08-21 Thread W. Martin Borgert
Package: wnpp Severity: wishlist Owner: "W. Martin Borgert" Package name: openerp6-server Version : 6.0.3 Upstream Author : OpenERP URL : http://www.openerp.com/ License : AGPL, GPL, BSD, etc. Programming Lang: Python Description : Enterpris

Re: Bug#563391: Package Trac 0.12 as well

2011-07-11 Thread W. Martin Borgert
Quoting "Éric Araujo" : Are you sure the full python-setuptools is required, not only python-pkg-resources? Look in debian/changelog :~) I replaced python-setuptools once with python-pkg-resources and had to revert the change. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org

Re: Bug#563391: Package Trac 0.12 as well

2011-07-11 Thread W. Martin Borgert
Quoting "Arthur de Jong" : I've updated the Trac packaging in svn://svn.debian.org/svn/python-apps/packages/trac/trunk to 0.12 and done some migration and cleaning up (see debian/changelog for details). Btw. could you please remove my now unused path svn://svn.debian.org/svn/python-apps/packa

Re: Bitten patch to release new version

2010-11-23 Thread W. Martin Borgert
Quoting "Sandro Tosi" : Talk with the current maintainer (which you're not). In this case it's PAPT. I'm the only Uploader, but happy about anybody helping with Trac and/or Bitten. Currently I'm too busy to help with new versions, but if somebody has time and skills and fun, please go ahead!

Re: dfsg suffix

2010-10-25 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Does that mean that I need to figure out why tarball was repacked and manually repack it again with the same changes to do new release? In this case the maintainer (I) was too lazy/sloppy/whatever to document it properly or add a debian/rules target to do the repac

Re: common issue: setlocale handling?

2010-08-22 Thread W. Martin Borgert
On 2010-08-22 12:38, Julian Andres Klode wrote: > Well, it does not really make sense to use invalid locales, so I see no > problems if applications exit with a failure. Users should fix their > environments instead. It would be nice, if applications would fall back to the "C" locale and warn abou

Re: Packages whith “except” overwriting builtins

2010-08-04 Thread W. Martin Borgert
Quoting "Paul Wise" : Actually, is there any generalised syntax, language, deprecation and mistake checker for python? There are pychecker, pyflakes, and pylint in Debian. This specific case raises a warning in pylint, if I'm not mistaken. -- To UNSUBSCRIBE, email to debian-python-requ...@lis

Re: exaile package

2010-07-28 Thread W. Martin Borgert
Quoting will...@agencialivre.com.br: Looks like the exaile[1] package is very out-of-date. ... I tried to contact the maintainers of this package without success. Given that - the package is really out of date, - the last three uploads were NMUs, - Ubuntu has more recent version, - there are

Re: Multiple sources/multiple setup.py in one package

2010-06-11 Thread W. Martin Borgert
Quoting "Piotr Ożarowski" : [W. Martin Borgert, 2010-06-11] did anyone already put more than one Python source in a Debian package? I.e. more than one setup.py? Do examples exist? TIA! Stefano did, see f.e. python-repoze.who-plugins Perfect, many thanks! (For those who are curiou

Multiple sources/multiple setup.py in one package

2010-06-11 Thread W. Martin Borgert
Hi, did anyone already put more than one Python source in a Debian package? I.e. more than one setup.py? Do examples exist? TIA! Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: htt

Django 1.2 for Squeeze?

2010-01-08 Thread W. Martin Borgert
Hi, would it be realistic/possible to have Django 1.2 in Squeeze? IMHO, it will come too late, because Squeeze will freeze in March and the Django release in planned for March, 9th... But maybe other people are more optimistic? Cheers -- To UNSUBSCRIBE, email to debian-python-requ...@lists.de

Re: How do I know if my package is 'arch-all' or 'arch-any'?

2009-12-29 Thread W. Martin Borgert
Quoting "anatoly techtonik" : python-support README [1] contains different instructions for 'arch-all' and 'arch-any' packaged. How do I know which one is mine? all: Package works on all architectures without (re-) compilation, e.g. a program written in Python any: Package needs e.g. comp

Trac upgrade documentation (was: jQuery dependency for Trac 0.11)

2009-12-29 Thread W. Martin Borgert
Quoting "anatoly techtonik" : That's not sufficient. To update Trac environment you will need to run "trac-admin upgrade" and optionally "trac-admin wiki upgrade". The second point is that web-servers (including Apache) treat symlinks differently and I am unsure how to setup web permissions corre

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-28 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Then we should also patch "trac-admin deploy" command so that it create symlinks to static resources instead of copies to update user environments to latest jQuery automaically. I don't remember, I ever used "trac-admin deploy", and I wonder how useful it is. It sa

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-27 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Is it possible to create symlink on a symlink? (I am on windows right now - can't test) Yes. That's true. Trac was designed to work even without JavaScript, but Trac plugins are written by community and people often assume that jQuery is available. That's why t

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-27 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Then why can't you wait until upstream developers, whose product bundles that library, confirm, validate, test and release fix for that error in their source package together with release announcement? Also in the case of Trac/jQuery. Again, many applications have

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-27 Thread W. Martin Borgert
Quoting "anatoly techtonik" : 1. Trac is not a package - it's an application. Inside of Debian, applications, libraries, and many other things come as "package" as we call it. In Debian, trac is a package. If there will be a problem in one of the files that shipped with Trac sources - it is a

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-27 Thread W. Martin Borgert
Quoting "anatoly techtonik" : If you see jquery.js file inside of its source package - why not to leave it alone - where is the Policy that requires to replace it with some external copy? In general, Debian puts a lot of work into finding and removing embedded code copies. Sometimes, this is no

Re: Unit tests

2009-12-26 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Even if most users don't need them, tests greatly increase the value of bugreports and doesn't bloat python packages too much. True. What do other people think of the issue? If unit tests were in the package, reportbug could automatically run them on a bug report.

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-26 Thread W. Martin Borgert
Quoting "anatoly techtonik" : There are more than 200 plugins tagged for 0.11 on http://trac-hacks.org/ They were developed and debugged with jQuery 1.2.x which is not forward compatible with 1.3.x Most Trac plugins do not use JavaScript, even less use jQuery. I don't feel like I want to chec

Re: jQuery dependency for Trac 0.11 should be < 1.3

2009-12-25 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Trac 0.11 ships with jQuery 1.2.6 However, Debian patches remove this file in favor of libjs-jquery package which contains version 1.3.x This breaks plugins for Trac 0.11 that rely on 1.2.x jQuery features removed in 1.3.x How to properly add dependency for jQuery<1

Re: Unit tests

2009-12-25 Thread W. Martin Borgert
Quoting "anatoly techtonik" : Python policy is silent about unit tests. Should they be stripped? Or should they be Debianized or left as-is? Just my opinion: Unit tests should be in the source package, but not in the binary package. Most users don't need them, and if somebody wants to try them,

  1   2   >