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

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

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

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)

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

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

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

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

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:

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

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

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 deba...@debian.org Package name: openerp6-web Version : 6.0.3 Upstream Author : OpenERP supp...@openerp.com URL : http://www.openerp.com/ License : OEPL (non-free, but relatively permissive) Programming Lang

Re: Bug#563391: Package Trac 0.12 as well

2011-07-11 Thread W. Martin Borgert
Quoting Arthur de Jong adej...@debian.org: 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

Re: Bug#563391: Package Trac 0.12 as well

2011-07-11 Thread W. Martin Borgert
Quoting Éric Araujo mer...@netwok.org: 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

Re: Bitten patch to release new version

2010-11-23 Thread W. Martin Borgert
Quoting Sandro Tosi mo...@debian.org: 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,

Re: dfsg suffix

2010-10-25 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

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 about

Re: Packages whith “except” overwriting builtins

2010-08-04 Thread W. Martin Borgert
Quoting Paul Wise p...@debian.org: 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

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:

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

2010-06-11 Thread W. Martin Borgert
Quoting Piotr Ożarowski pi...@debian.org: [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

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

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

2009-12-29 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

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

2009-12-29 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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:

Re: jQuery dependency for Trac 0.11 should be 1.3

2009-12-28 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Re: jQuery dependency for Trac 0.11 should be 1.3

2009-12-27 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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.

Re: jQuery dependency for Trac 0.11 should be 1.3

2009-12-27 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Re: jQuery dependency for Trac 0.11 should be 1.3

2009-12-27 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Re: jQuery dependency for Trac 0.11 should be 1.3

2009-12-26 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Re: Unit tests

2009-12-26 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Re: Unit tests

2009-12-25 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Re: jQuery dependency for Trac 0.11 should be 1.3

2009-12-25 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: 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

Move GPL discussion elsewhere (was: Python Policy)

2009-12-15 Thread W. Martin Borgert
Quoting anatoly techtonik techto...@gmail.com: Given that people are tired of discussing things they've already decided for themselves I CC this to debian-legal. Addendum: Given that some Debian documents are released under the terms of the GPL (e.g. our release notes), this discussion has

License entry in egg info files

2009-10-17 Thread W. Martin Borgert
Hi, I believe that the following entries are incorrect: /usr/share/pyshared/arista-0.9.1.egg-info:License: UNKNOWN /usr/share/pyshared/cups-1.0.egg-info:License: UNKNOWN /usr/share/pyshared/Django-1.1.1.egg-info:License: UNKNOWN /usr/share/pyshared/git_build_package-0.0.0.egg-info:License:

Re: License entry in egg info files

2009-10-17 Thread W. Martin Borgert
On 2009-10-17 23:59, Ben Finney wrote: So currently I don't think they are bugs of any severity above ‘minor’. I agree, that this is 'minor' or even 'wishlist'. Presumably all these are created by upstream ‘setup.py’ settings, so it would ultimately be for upstream to fix in each case. The

Re: License entry in egg info files

2009-10-17 Thread W. Martin Borgert
On 2009-10-18 09:46, Ben Finney wrote: I don't have a strong objection in this case, and I can see good arguments for and against a Lintian check. I wouldn't put up a fight either way :-) Me neither, it's certainly one of the least pressing issues we have with Debian Python :~) -- To

Backports: Django, web.py, Trac - anyone wants them?

2009-09-20 Thread W. Martin Borgert
Hi, for some reasons I need lenny backports of python-django, python-webpy and trac. Some of the packages I don't need for production use, but for automatic testing (using bitten) only. I could work with squeeze chroots, but probably I will go for the backports. Now my question: Are more people

Re: trac maintenance activity?

2009-09-10 Thread W. Martin Borgert
Quoting Andres Salomon dilin...@collabora.co.uk: Ah, just noticed debacle's emails[0] regarding this. You'll certainly find no objections from me. Feel free to take over. Yes, trac will be maintained in the Python Application Packaging Team. I already tried to copy the git history to the

Re: trac maintenance activity?

2009-09-10 Thread W. Martin Borgert
On 2009-09-11 00:03, anatoly techtonik wrote: There is always Tailor that is capable of converting various repositories into each other. According to the description, tailor supports both git and svn. I may try to do the conversion, just let me know where to get GIT sources (althout HG

Trac - DPMT or PAPT?

2009-09-01 Thread W. Martin Borgert
Hi, sorry for bringing up this again: Is it OK to put Trac into PAPT, not into DPMT? Reason: I think Trac and at least some of it's plugins should be maintained together (same team, same VCS, Trac users know too well the problem of plugins not fitting in a specific Trac version...), so this is

Re: VCS for Python code

2009-08-29 Thread W. Martin Borgert
On 2009-08-29 08:46, Michal Čihař wrote: There was recently lengthly discussion about using Git, check archives. The reasons against Hg will be the same + the fact that much poeple do not know it. (I'd be for Git but not for Hg, which I never used before and I'm too lazy to know every VCS

Trac team almost dead?

2009-08-28 Thread W. Martin Borgert
On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian

Re: [Pkg-trac-devel] Trac team almost dead?

2009-08-28 Thread W. Martin Borgert
On 2009-08-28 12:08, Piotr Ożarowski wrote: question is: are these plugins installed in trac's directory or do they import trac? AFAIK, this depends on the package. Typical plugins are installed into Trac directories, but they have also to import trac to use the APIs. I'm currently not near my

  1   2   >