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

[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
same source package might be OK for bpo. Of course, d/control
etc. would differ, but that's common.

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

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

[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

[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

[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 have
> any idea, go ahead.

OK, I'll upload web.py without Python 2 support then.
If someone has strong interest in rebuildd, they has to make a
Python 3 version anyway. If the package is not in buster, there
can still be a backport.

Thanks for your input, Julien, Julien, and Mattia!

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

[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 a
Python 2 package of cheroot for buster, but I prefer to drop Python 2
support of web.py instead. Any opinions?


I would say "go for the drop!!!" if not for the presence of a reverse
dependency of the python2 package (rebuildd).  So IMHO the best would
be:
 * port rebuildd to py3
 * drop the py2 package


Julien & Julien, how realistic is moving rebuildd³ to Python 3 for
buster? Or better upload cheroot with Python 2 support for now?
The update of web.py is, unfortunately, necessary for Python 3.7.

Cheers

¹https://tracker.debian.org/webpy
²https://tracker.debian.org/python-cheroot
³https://tracker.debian.org/rebuildd

Dropping Python 2 support for web.py before buster

[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 instead. Any opinions?

Cheers

¹https://tracker.debian.org/webpy
²https://tracker.debian.org/python-cheroot

Re: Matplotlib 3.0 - update ok?

[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 sure, immediately after release, we (= Python
teams) will start to drop Python 2 support anyway. In the mean time
new versions of matplotlib and friends, as well as orange, might be
suitable for experimental, so that your packaging work doesn't need
to wait. Orange looks very interesting and is a welcome addition to
Debian, btw.!

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

[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, which seems to be your impression. I just (maybe
> wrongly) thought, that upstream/master whatever upstream does in
^ follows
> their master/tip/trunk (just as upstream/latest always follows
> the latest upstream release). I don't remember, where I got that
> idea from. Unreliable sources :~)

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

[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 whatever upstream does in
their master/tip/trunk (just as upstream/latest always follows
the latest upstream release). I don't remember, where I got that
idea from. Unreliable sources :~)

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

[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/master" (for
> >following upstream master, typically for experimental)?
>
> I think we should just follow DEP-14 branch naming conventions (which, having 
> re-read it, I discover I haven't been doing).

In fact, I thought that "upstream/master" were DEP-14-ish, but
only "upstream/latest" (for the newest release) is.

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

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

Re: Backport of Python 3.6 for Debian Stretch?

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

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

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

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

[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 not
privileging one of Python 2, Python 3, PyPy, etc. over the others?


Nice idea, I'll do the same. Thanks!

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

[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. Even if we
drop Python 2 at some point, maybe then there is Python 4 or
PyPy. I tend to stay with the traditional path, and ignore
the preference of our beloved policy. Not without first
consulting this very mailing list, of course. Opinions?

TIA & Cheers

Re: PAPT migrated to Git on Salsa

[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

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

[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

[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 the subgroups ever.
With this structure, it is one team already.

If there nobody objects, we have to:
 - migrate the git archives (you volunteered, thanks!)
 - ask for membership in the team (everybody)
 - change Python team documentation (who?)
 - make an MR for https://salsa.debian.org/salsa/AliothRewriter (who?)
 - ?

Re: Merge modules and apps team?

[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 of the reasons I like to merge them. I hope,
that the slightly better situation of the modules will rub off on
the apps.  My illusions might be in vain, but at least I do not
see any disadvantage in the merge.

Move to salsa? Merge modules and apps team?

[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? Any doubts?

TIA & Cheers

Re: Update wokkel?

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

[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-oerplib -- Python client library to Odoo server (#882868)

Maybe somebody likes to take over one or the other?

TIA & Cheers

Update wokkel?

[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

[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 uploaded to Debian on 2012-10-14.

Cheers

Re: pycharm package in debian

[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 unsure how to work with it:
> >
> > How to install?
> I expand the tarball to ~
...

This is my point: I'm too lazy and too old to find out for every
random application how to install, uninstall, upgrade it, find
out which version, if any, is installed on my system, whether
the software complies with the DFSG, etc.

> Surely you don't expect the Debian maintainers to fix bugs you could
> encounter in PyCharm?

I expect Debian maintainers to forward bugs to upstream, if they
assume, that the bug is not introduced by them. (For some highly
complex software, like Gnome or KDE, this is not practical, but
for many packages this should work.)

Cheers

Re: pycharm package in debian

[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 maintained software.
> Especially when there are other means of installing the software which are
> officially documented upstream.
>
> I have been there with packages I personally maintain (spyder for
> instance), and I am raising these concerns out of my own experience and
> feedback from existing users. Feel free to disregard.

Those are absolutely valid concers. I'm aware of many outdated
packages, including some maintained by me. I leave the challenge
to those, who like to package it. Still, if PyCharm were in
Debian, I would at least try it out some day.

Cheers

PS: Is there maybe something broken with the quoting function of
your MUA? I cannot differentiate between text written by you and
quoted text. There is no '> ' or whatever...

Re: pycharm package in debian

[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 Debian.
Or I package it. If there is some snap or other third party
package, I'm unsure how to work with it:

How to install? How to uninstall? How to report bugs and to
whom? How to download the source code and rebuild it? Is it
DFSG-free anyway? (Does it already build reproducible?)

There is nothing wrong with having snap or other packages
available, but I'm not their target audience. But I'm an Emacs
- and vi! - user anyway :~)

Another question is, how much work it will be and whether it is
worth the effort, esp. permanent maintenance. But if somebody
wants to do it, why not?

Cheers

Re: Docs only packages?

[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

[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

[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 python-numpy still uses a downloaded .inv.

Uploading Python modules which drop support for Python 2?

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

[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 maintaining it" ;)


No, it's just "work", as far as I know.


In other words, before I start packaging django-cms and its missing
dependencies, is there anything I should know?


Just read https://bugs.debian.org/516183, I'm sure I'm not the only
one who very much appreciates having Django CMS in Debian!

Cheers

Re: PAPT git migration

[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 git repository should probably renamed to
trac-privatetickets.

Cheers

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

[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

[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 issue at github someone already points out that popcon is "opt-in"
and I'm sure, that the overwhelming majority in Debian is in favour of it
in contrast to "opt-out". I can understand, that upstream would prefer
the latter, but Debian has a reputation for taking privacy issues very
serious and likes to keep it. Not sure about any policy on this, though.
If Django implements usage analytics, I would strongly suggest to make it
"opt-in" in Debian, just as popcon, not "opt-out".

Cheers

Re: on keep providing python 2 packages

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

[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 properly) isn't uncommon.

Been there, lost hours :~(

> As I only heard complains about git-dpm, maybe someone would like to
> express his joy using it, and explain why they think it's a nice tool.
> But is there such person? It seems git-dpm only brings frustration.

Well, in most cases I did not have any problems with it.
Points I like and would prefer not to change:
 - no need to use quilt
 - no special build command, just plain dpkg-bp or whatever

The idea to try something else in PAPT is very welcome from my
side, no matter what tool.

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

[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. Changing that would increase my fun level!)

Re: conflicting packages python-pysocks and python-socksipy

[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

[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 already packaged under the
name python-pysocks.

Questions:

 - shall we remove one of the package?
   (proposal: yes)
 - which of the two packages should be removed from Debian?
   (proposal: remove pysocks, just because socksipy is older)
 - shall the other package provide dummy transitional packages?
   (proposal: yes)
 - shall we rename the binary package to python-socks?
   (proposal: yes)

Any ideas or opinions?

TIA & Cheers

python-cherrypy (was: packages without any uploaders)

[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 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.3.0 and only Python 2.

Cheers

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

[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.3.0 and only Python 2.

I just checked again and realised that there is a cherrypy3
package which is not outdated at all and well-maintained by
Gustavo. But it also lacks the Uploaders name. Easy to fix :~)

Sorry for the noise!

pyftpdlib: Working on Python 3 etc.

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

[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

team vs individual as maintainer (was: radical changes)

[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 "Maintainer" to encourage
others to intervent.

How about leaving it as is? I.e. people in the team decide what is
more appropriate for a package?

Cheers

Re: team vs individual as maintainer

[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 statement of collaboration.  Help in  
maintaining

  the package is appreciated, commits to vcs are freely welcomed, but before
  uploading, please contact the Maintainer for the green light.


+1


how about making it official and adding it to the policy?


+1

Re: Packaging Bokeh

[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 libraries.)

Fortunately, Debian has now a current jQuery 1, again. And
jQuery 3 in experimental. Thanks to Antonio Terceiro! Bootstrap
is a recent version anyway. So it should be easy to just use
Debians packages.

> The most proper packaging would require grunt to be able to rebuild bokeh.js. 
> I was wondering if releasing the pypi version would be good enough. (The 
> package does at least contain a non-minimized version of bokeh.js)

I'm not sure about this, but it looks like the Bokeh source is a
huge directory of coffeescript files, while the resulting
bokeh.js is not the source code. So build is: 1. coffee -> js
2. concat all js. Maybe its possible without grunt, just like
Antonio did with jQuery?

> Bokeh's unit tests also appear to depend on blaze, and that looks like that 
> has several missing dependencies.

I would just leave out the tests for now. Bokeh is a huge beast
even without them. Let's go step by step.

> Thought It looks like the python-modules team is just 
> about to transition to git-dpm. 

Yes, that has been decided in Heidelberg, but I'm not sure about
the current state. Who can comment on this?

> Should I go ahead and submit abstract_rendering?

Yes, but please fix the long description. It starts with
"Abstract Rendering takes the opposite approach:" which confused
me :~)

> Should I work on getting 
> blaze submitted?

If blaze is only needed for the tests, I suggest to postpone it.
(What is blaze anyway?)

Cheers

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

[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 smoothly from SimPy 2 to simpy 3.

There is one error in the test suite. It is ignored during
build, so I ignore it, too. But please check it, this should
be fixed in a subsequent upload:

=== 
FAILURES 
===
___ 
test_exception_chaining 


env = simpy.core.Environment object at 0x7fd086165c90

def test_exception_chaining(env):
Unhandled exceptions pass through the entire event stack. This must 
be
visible in the stacktrace of the exception.


import textwrap, re

def child(env):
yield env.timeout(1)
raise RuntimeError('foo')

def parent(env):
child_proc = env.process(child(env))
yield child_proc

def grandparent(env):
parent_proc = env.process(parent(env))
yield parent_proc

env.process(grandparent(env))
try:
env.run()
pytest.fail('There should have been an exception')
except RuntimeError:
trace = traceback.format_exc()

expected = re.escape(textwrap.dedent(\
Traceback (most recent call last):
  File ...simpy/test/test_exceptions.py, line ..., in child
raise RuntimeError('foo')
RuntimeError: foo

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File ...simpy/test/test_exceptions.py, line ..., in parent
yield child_proc
RuntimeError: foo

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File ...simpy/test/test_exceptions.py, line ..., in grandparent
yield parent_proc
RuntimeError: foo

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File ...simpy/test/test_exceptions.py, line ..., in 
test_exception_chaining
env.run()
  File ...simpy/core.py, line ..., in run
self.step()
  File ...simpy/core.py, line ..., in step
raise exc
RuntimeError: foo
)).replace('\.\.\.', '.+')

   assert re.match(expected, trace), 'Traceback mismatch'
E   AssertionError: Traceback mismatch
E   assert None
E+  where None = function match at 0x7fd088e5ac80('Traceback\\ 
\\(most\\ recent\\ call\\ last\\)\\:\\\n\\ \\ File\\ 
\\.+simpy\\/test\\/test\\_exceptions\\.py,\\ l...File\\ 
\\.+simpy\\/core\\.py,\\ line\\ .+\\,\\ in\\ step\\\n\\ \\ \\ \\ raise\\ 
exc\\\nRuntimeError\\:\\ foo\\\n', 'Traceback (most recent call last):\n  File 
/home/debacle/python-modules/python-simpy3/build-area/python-simpy3-3.0.7py,
 line 137, in run\nself.step()\n  File simpy/core.py, line 229, in step\n 
   raise exc\nRuntimeError: foo\n')
E+where function match at 0x7fd088e5ac80 = module 're' from 
'/usr/lib/python2.7/re.pyc'.match

simpy/test/test_exceptions.py:127: AssertionError
=== 1 failed, 129 
passed, 1 skipped in 2.28 seconds 

I: pybuild base:170: python3.4 -c 'import simpy; simpy.test()'
= test 
session starts 
==
platform linux -- Python 3.4.3 -- py-1.4.28 -- pytest-2.7.0


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150618205916.GA6567@fama

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

[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/topical_guides/porting_from_simpy2.html

In some cases (don't ask me which ones) Debian changes package
names on fundamental changes, e.g. from python-simpy to
python-simpy3. This allows to update simpy without sudden or
unexptected breakage of current packages or even locally
installed software. There is no accidental upgrade path.

OTOH, I'm not sure whether this effort would be justified in
this case. Comments?

Cheers


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150519145134.GA14712@fama

Re: Python 2 d-d-a proposal

[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 latest hack,
Pain in the APT https://painintheapt.alioth.debian.org/, had no
dependency problems, however. Thanks to the team!


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150415205541.GA23779@fama

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

[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 with Python 3 fixed, so
I would package this right after Jessie release and provide
a backport.

Questions:

 - is removing the Python 3 package the right thing to do?
 - how to do this? just remove it from debian/control?

Thanks in advance!

(If somebody has time to really fix the bug, this would be
very much appreciated, of course!)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150125115004.GA14958@fama

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

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

 Also, during the Debconf discussion, we decided we would use the
 pristine-tar workflow, *not* using upstream VCS merge.

Isn't pristine-tar deprecated by its author? I read
https://bugs.debian.org/737871 and
http://www.preining.info/blog/2014/06/debian-pristine-tar-packaging/
and was therefore reluctant to use it. Anyway, I don't remember
to encounter any problems with pristine-tar myself.

 Anyone who doesn't respect what we are collectively agree on
 should IMO take the blame for what happened on IRC and on the commit
 list, and pointing fingers at whoever configured it is IMO wrong.

Blaming and pointing fingers is almost always wrong :~)


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141012103613.GA2011@fama

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

[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 effect? Do you have a
 plan to reduce the amount of noise it causes reducing dramatically the
 SN ratio on the ml?

I believe it must be possible to get only one email per
receive (= push), independent of the number of commits in the
push. Of course, either email gets very large, or one can have
less information in it (e.g. who committed to which repository
how many commits, the rest has to be looked up in git).

 PS: nothing against you Wolfgang, you just happened the one pushing
 these changes ;)

No offense taken!

PS: At least you know now, that I'm packaging mpld3, a D3
backend for matplotlib.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140923214357.GA15014@fama

git (was: Making packaging Python modules fun again)

[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 master (gpbs default) or debian (more
intuitive when one works with upstream)? Will we use the
pristine-tar branch or pristine tar files? Etc.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140127091158.ga12...@fama.tangosoft.com

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

[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 debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130925181547.13216jbp112ja...@webmail.in-berlin.de

Re: PEP 453 affects Debian packaging of Python packages

[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 Debian is a perfect platform for different applications,
even if not packaged for Debian. E.g. Debian contains all
libraries and Python modules needed for an application my
company does. I heard the same from OpenERP developers. They use
Ubuntu and Debian and find it very useful, that everything they
need is available, be it a Python module or nginx.

If there were Python modules missing, it would make Debian a less
usable tool for us and probably many others. Using virtualenv and
pip to play with a new module is nice, but not necessarily an
option for serious application development, e.g. because you have
to think how to deploy the application later. That's why I want to
see all useful Python modules in Debian, even if no Debian
package uses them. If somebody files an ITP or RFP, they know,
what it is good for :~)

To me, having Debian packages of Python modules does not only mean
the package is available via apt-get instead of pip. It does also
mean, that at least one Debian maintainer looked at the usability
and maybe quality of the code, that DD and FTP masters accepted
the license, that I have the same bug tracker available for the
Python module, web server and kernel. Debian packages are checked
by others, whether one can still build and install them, etc.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130920223236.ga20...@fama.tangosoft.com

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

[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. We
  package modules so that apps can use them, not so that people can
  develop with them.

That is maybe my problem with pip: Developers tend to use every Python
library in every version they like from PyPI. As a project leader I
generally have to think about deployment and this means: Use Debian
stable and backports! Only for long-term projects the next Debian
stable release might be relevant. But if you have a dozen or so
libraries installed by pip, there are libraries that will not be
packaged for Debian and the deployment is wrecked.
--- /usr/bin/pip	2013-08-20 00:37:24.0 +0200
+++ pip	2013-09-19 11:11:04.567271401 +0200
@@ -2,6 +2,13 @@
 # EASY-INSTALL-ENTRY-SCRIPT: 'pip==1.4.1','console_scripts','pip'
 __requires__ = 'pip==1.4.1'
 import sys
+
+import os
+
+if os.getuid() = 100:
+print  sys.stderr, a nice insult from the sudo insults list?
+sys.exit(-1)
+
 from pkg_resources import load_entry_point
 
 if __name__ == '__main__':

Re: PEP 453 affects Debian packaging of Python packages

[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 would make pip uninstallable :~)
Next steps: get rid of gem, npm, EPT, ...


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130918150529.18601sbfufo9b...@webmail.in-berlin.de

Re: Two binary from one source - how?

[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 leaving Python related things here, so if you have
more questions, we should move this to debian-mentors or
whatever.)


The master package description can be improved ,)
- This package contains the master, which integrates into Trac.
+ This package contains the master implemented as Trac plugin.


You have commit rights, yes? Please feel free to correct this!


I'd keep full package in master package and strip slave to required
files only. I wonder that will happen with shared files if you install
trac-bitten + trac-bitten-slave and then remove slave? Is Debian smart
enough to detect that these files are still belong to another package?


Files always belong to one package only. That's why I suggested
to put commonly used files into the slave package and let the
trac-bitten package depend on trac-bitten-slave. Alternatively,
common files could be in a trac-bitten-common package and both
master and slave depend on it. But in this specific case there
is no advantage in a third package.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111014130724.104023vcbkd6e...@webmail.in-berlin.de

Re: Two binary from one source - how?

[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 to generate install files,
but it is not really difficult to do it manually. These
days I surely will find some time to create them.


 You have commit rights, yes? Please feel free to correct this!

Not anymore. They were revoked, because I appeared too dumb to
understand Build-Depends-Indep meaning for Python packages.


Hm? Well, I will do the change.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20111014143904.34166au92wuhi...@webmail.in-berlin.de

Re: Two binary from one source - how?

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

 python setup.py --without-master install

 But how to specify that in debian/rules -
 http://anonscm.debian.org/viewvc/python-apps/packages/trac-bitten/trunk/debian/rules?revision=4711view=markup
 ?

You don't have to specify anything in debian/rules! :~)

Just change debian/control (I just checked in my working copy,
see r7647). However, one has to have one or two install files
in the debian directory. These determine, which files will go
into which package.

Note: Because master and slave use some Python files in common,
you need these files either in a third package
(trac-bitten-common) or we just keep these files in the slave
package. This only means, that on the master machine also a
slave must be installed, which doesn't hurt size-wise.

Cheers


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111013195529.gb22...@beron.tangosoft.com

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

[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
Description : Enterprise Resource Management (server)

OpenERP is a complete ERP and CRM. The main features are
accounting (analytic and financial), stock management, sales and
purchases management, tasks automation, marketing campaigns,
help desk, POS, etc. Technical features include a distributed
server, flexible workflows, an object database, a dynamic GUI,
customizable reports, and NET-RPC and XML-RPC interfaces.

This package contains the Open ERP server, install openerp6-web
package for the client.



-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110821125722.16116.52.report...@beron.tangosoft.com

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

[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: Python
Description : Enterprise Resource Management (web frontend)

OpenERP is a complete ERP and CRM. The main features are
accounting (analytic and financial), stock management, sales and
purchases management, tasks automation, marketing campaigns,
help desk, POS, etc. Technical features include a distributed
server, flexible workflows, an object database, a dynamic GUI,
customizable reports, and NET-RPC and XML-RPC interfaces.

This package contains the OpenERP web frontend, install
openerp6-server package for the actual server.



-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110821130245.16538.14468.report...@beron.tangosoft.com

Re: Bug#563391: Package Trac 0.12 as well

[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
svn://svn.debian.org/svn/python-apps/packages/trac-0.12/trunk
please?


- Is the run-time dependency on python-setuptools required (or should
  it only be Build-Depends)?


python-setuptools is indeed used by Trac (at least in 0.11),
maybe for the plugins. Don't touch it :~)


- There is a debian/package-it script that seems to do something similar
  to svn-buildpackage. Should it be removed?


I assume that this script has been used by former maintainers.
Just remove it.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110711170514.12066fp0hweqn...@webmail.in-berlin.de

Re: Bug#563391: Package Trac 0.12 as well

[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 debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110711174334.147454iawn4yv...@webmail.in-berlin.de

Re: Bitten patch to release new version

[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, please go ahead!


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101123232136.50276ys81tz0z...@webmail.in-berlin.de

Re: dfsg suffix

[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 target to do
the repacking. In this case, the SWF files of bitten were
removed, because they are non-free. See debian/changelog.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20101025200344.17655025g1a3f...@webmail.in-berlin.de

Re: common issue: setlocale handling?

[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 the fact instead of just exiting. Still,
this would be wishlist or minor.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100822121401.gc8...@beron.tangosoft.com

Re: Packages whith “except” overwriting builtins

[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 debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100804094337.14326kdf30lj3...@webmail.in-berlin.de

Multiple sources/multiple setup.py in one package

[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: 
http://lists.debian.org/20100611151908.934729boglvxn...@webmail.in-berlin.de

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

[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 are curious, but not sufficiently to look, it
seems that Stefano wrote a small setup.py that just loops over
the subdirectories calling the original setup.py files. Nice.)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100611153655.15754ihl7ai5i...@webmail.in-berlin.de

Django 1.2 for Squeeze?

[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.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[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 permissions correctly if
symlinks lead outside of your environment.


I really have to check my setup. I'm using Apache (and WSGI).
Probably I allowed Apache explicitly to access certain paths.

Changing the semantics of the trac-admin deploy command is
something that I would prefer to be done by upstream. For
Debian it sounds like documenting the issue well, so that
people know, what they have to expect.

There is an open bug report anyway, that suggests and
trac-admin upgrade to be done automatically on every
upgrade of Trac. This is technically too difficult to solve,
because one never knows which environments exist (they
might not even be available at package upgrade time). Again,
this is sth. that should be documented clearly.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: jQuery dependency for Trac 0.11 should be 1.3

[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
useful it is. It saves you from creating one symlink and creating
one WSGI file of typically about ten lines, right?

Maybe it's sufficient to change the documentation of the deploy
command in README.Debian? Like:

If you prefer copies (which are not updated automatically, even
in case of security issues), use trac-admin deploy, if you
prefer links, use the following commands:

$ cp /usr/share/doc/trac/examples/foo.wsgi /my/trac/env/cgi-bin/
$ vi /my/trac/env/cgi-bin/foo.wsgi # adjust trac env directory
$ ln -s /usr/share/pyshared/trac/htdocs /my/trac/env/


So, if a package is listed in Recommends: section it is installed
automatically by command line aptitude install trac? Didn't know
that.


Both aptitude and apt-get install Recommends by default. This can
be switched off, but most users don't know that, fortunately :~)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: jQuery dependency for Trac 0.11 should be 1.3

[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. Sometimes, this is not possible, e.g. if
upstream makes incompatible changes.


The maintenance work in this
case creates more problems than benefits and may be not as
appreciated.


It would be helpful, if you could state the exact problems you
had because of the newer jQuery.


What make people think that Trac developers won't release a new
version when such important security problem arise?


Currently, 58 packages in Debian depends on jQuery. It makes
huge difference, if Debian has to update one package or 58.


It is not necessary to do the extra job of removing jQuery liver from
the Trac body at all. The only advantage I see are security patches.
Anything else?


Security is only an example. Any kind of error is relevant.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: jQuery dependency for Trac 0.11 should be 1.3

[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 applications have many libraries and tools as embedded
code copies. jQuery alone is used by 58 Debian packages. As I'm
already repeating myself I'll stop now arguing about the issue.
Btw. inside of Debian nor Ubuntu I'm not aware of other opinions
in this matter.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: jQuery dependency for Trac 0.11 should be 1.3

[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 available.


That's why the Debian Trac package recommends jQuery. In the
default case, it is installed automatically, but you can
explicitly say no, if you want to.


That makes sense, but they could not at the moment if I understand
correctly? It will require splitting libjs-jquery into libjs-jquery12
and libjs-jquery13 - is that right?


Yes, exactly.


Now I still have
AccountManager named urwid in Trac Admin panel, but I do not even
want to repeat this awful SSH experience.


I have the same problem (wrong Python package names as names of
Trac plugins in the admin panel) sometimes, but I don't know what
the cause is. Any idea? (But I don't think, it's in any way
related to JavaScript nor jQuery...)


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: jQuery dependency for Trac 0.11 should be 1.3

[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 like I
want to check if they are compatible next time I'd like to use one.
15kBytes doesn't worth wasted hours.


The issue is not 15 kB, but the problems Debian would have if an
error must be fixed in jQuery (e.g. a security problem). Currently,
around 58 packages depend on jQuery. In theory, each of them must
have their own copy. Trac does not even depend on jQuery, but only
recommends it, because Trac itself does not need jQuery.


The best solution would be to remove 15_remove_jquery_file.dpatch,
postinst, prerm and let Trac developers ship the version that
contributes to the official API for Trac extension developers for a
given Trac release.


If it is really important to have jQuery 1.2 around, the best way
would be to ask for a libjs-jquery-1.2 package and let Trac
recommend this package instead of libjs-jquery.

Anatoly, please file an ITP or RFP bug against the WNPP[1]
pseudo-package about libjs-jquery-1.2, OK? Set the maintainer of
libjs-jquery in Cc, maybe they will package 1.2 as well. I will
change the dependencies in Trac etc. as soon as the package is in.

[1] http://www.debian.org/devel/wnpp/


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Unit tests

[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 them on a bug report. Does someone do this already, maybe?


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Unit tests

[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
wants to try them, they can easily fetch the source package.

Btw. What's wrong with trac-accountmanager? It does work for me.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: jQuery dependency for Trac 0.11 should be 1.3

[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 dependency for jQuery1.3 to trac package?


This would be only possible, if Debian would ship a libjs-jquery-1.2
package, which does not exist at the moment.
Which plugins exactly do not work with jQuery 1.3?
How much effort would it take to make them compatible with 1.3?
Note, that Trac 0.12 will ship with jQuery 1.3 anyway...

In any case, I will document the potential problem in README.Debian
file, so that our users are not surprised (only disappointed maybe).


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Move GPL discussion elsewhere (was: Python Policy)

[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 only
little relation to Python. Please drop debian-python from it. TIA.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

License entry in egg info files

[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: UNKNOWN
/usr/share/pyshared/lxml-2.2.2.egg-info:License: UNKNOWN
/usr/share/pyshared/miro-2.5.2.egg-info:License: UNKNOWN
/usr/share/pyshared/pcapy-0.10.6.egg-info:License: UNKNOWN
/usr/share/pyshared/pycrypto-2.0.1.egg-info:License: UNKNOWN
/usr/share/pyshared/pyogg-1.3.egg-info:License: UNKNOWN
/usr/share/pyshared/python_mpd-0.2.1.egg-info:License: UNKNOWN
/usr/share/pyshared/pyvorbis-1.4.egg-info:License: UNKNOWN
/usr/share/pyshared/PyXML-0.8.4.egg-info:License: UNKNOWN
/usr/share/pyshared/Sonata-1.6.2.1.egg-info:License: UNKNOWN
/usr/share/pyshared/spambayes-1.0.4.egg-info:License: UNKNOWN
/usr/share/pyshared/tailor-0.9.35.egg-info:License: UNKNOWN

I'm too lazy right now to file bugs, but shouldn't we fix this?


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: License entry in egg info files

[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 maintainer can patch the setup.py file in the meantime or in
case upstream does not care.

A lintian check sounds like a good idea to me. It's all about
package consistency. Fortunately, I forgot my poor Perl
knowledge years ago, so somebody else has to write it.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: License entry in egg info files

[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 UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[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 interested in
having the backports, so I will upload them to b.d.o (but don't
hold your breath), or am I the only one interested? Or better:
Is someone interested in doing the backports? :~)

Cheers


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: trac maintenance activity?

[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 PAPT svn, but - lacking
any experience with git - failed. I will now just start with the last
version and for the history people have to look into the git.

After bringing trac up to date, I hope to have time to package some of
the (to me!) most important plugins, such as bitten and email2trac.


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: trac maintenance activity?

[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 repository would be better to start with).

http://packages.qa.debian.org/t/trac.html states
git://git.debian.org/git/pkg-trac/trac.git

If you like, feel free to try your luck! I would just leave the
git history in git and start with the latest packaged trac
version, but of course I'm not opposed if somebody else does the
work :~)

 BTW, when doing test commit an error occurred,
...
 Warning: post-commit hook failed (exit code 13) with output:
 svnlook: Write error: Broken pipe
 Error opening cache: Permission denied

As long as no pre-commit hook failed...


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Trac - DPMT or PAPT?

[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
application stuff, not library/module.

Cheers


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: VCS for Python code

[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 available).

For me it is similar: I currently do not have the time/energy to
learn a new VCS, so I'ld prefer to stay with SVN. Sorry for
counting my laziness as criterion. If we change, it would at
least question my particiption for one or two years. Or
challenge my ambition, so I would learn git immediately :~)

Still, I would like to move trac and friends to PAPT (or DPMT)
today or tomorrow. This means SVN for now. I don't think this
influences staying with SVN or changing in any way. Currently,
the weather is a little bit too good for Debian work, however.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Trac team almost dead?

[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 Python Modules Team,
which already has some of tracs dependencies, i.e.
libapache2-mod-python, mod-wsgi, python-docutils, genshi,
python-mysqldb, and pygments. If nobody objects, I would do the
necessary work, including fix of #521513 (i.e. upload of current
trac version 0.11.5), under the flag of the python-modules team.

Andres, Federico, Jesus, Luis, Otavio, what do you think?


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[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 trac server, but I remember that
email2trac is installed under /usr/bin and uses the Trac API by
from trac import  Installation outside of Trac directories
is, however, an exception. CMIIW.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Trac team almost dead?

[W. Martin Borgert]

On 2009-08-28 17:25, Mikhail Gusarov wrote:
 There are two modes of installation: putting the .egg to the concrete
 Trac instance and installing it site-wide in the PYTHONPATH. You're
 probably referring to former.

 Distribution-friendly way is latter.

Than I was wrong. I thought that plugins can go into a site-wide
Trac directory, but you are right. So anybody vetoing against
moving Trac to DPMT? You have three seconds... :~)

Given that (1) pkg-trac was inactive the last months and that
(2) interested Trac team members can easily join DPMT, and (3) a
new upstream version is needed desperately by some users, I will
probably start migration tomorrow. Depends on the weather.


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Trac team almost dead?

[W. Martin Borgert]

Quoting Christoph Egger deb...@christoph-egger.org:

I have some of the trac-plugins ITA/ITPed and would probably consider
following trac itself into one of the python Teams. However I wonder how
the $VCS will be handled, throwing away trac's git history doesn't sound
like a good idea to me.


The git history would still exist. And we could also import the git
history into the SVN repository of DPMT. I never used git and I
currently don't have the time to learn new tools, so maybe somebody
could post the right command line to do this, please?


--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[W. Martin Borgert]

On 2009-08-28 12:21, Piotr Ożarowski wrote:
 DPMT is fine then

 (most important ;-) problem solved)

Maybe not yet: To me it would make sense to maintain Trac and
some Trac plugins in the same team and in the same VCS. DPMT
would be OK for Trac, but probably not for all the plugins,
that are never used by anything but Trac. So maybe PAPT is the
right choice then?


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

python-modules takeover of python-webpy?

[W. Martin Borgert]

Hi,

I talked to Kai Hendry, the current maintainer of web.py, who
would like to give up the package (python-webpy). I already
prepared a new version (current upstream, both open Debian bugs
solved), which I would like to upload under the flag of the
python-modules-team (my membership is pending). Any comments?
Vetos? As I can see, similar packages are all handled by this
team, e.g. CheeryPy, Django, TurboGears...

Cheers

PS I will also build and upload the package for lenny-backports


-- 
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org