Re: Upstream build system, Sphinx autodoc, Python import path

Or use the following alternative, which lets the user browse the documentation offline. $ cat debian/patches/use-local-python3-doc-for-cross-references >From f519a948173bfd4e9700a4ebc60bc54bf3455018 Mon Sep 17 00:00:00 2001 From: Florent Rougon Date: Thu, 8 Oct 2015 13:28:35 -0700 Subject:

Re: Packaging pythonpy

Hello, Dmitry Shachnev wrote: > Also, don't you think that /usr/bin/py is too generic? Maybe use > /usr/bin/pythonpy or something similar instead? (It's easy to change that, > as the linking is done by packaging rather than upstream buildsystem). Especially considering that 'py' is the name cho

Re: Using 'pyvenv' or 'python3 -m venv' on unstable

Barry Warsaw wrote: > Since the fix for this is in python3.5, I've already provided a patch to > Matthias. I wanted to get his feedback about one particular point of the > patch, but in the meantime I will attach the patch to that bug and reassign > it. Ah, glad to see a fix is on its way. Than

Using 'pyvenv' or 'python3 -m venv' on unstable

Hello, Sorry for linking to my own bug report, but am I the only one affected by bug #815864? () I'm wondering, because it seems pretty serious to me for people doing Python development (or users wanting to install stuff with pip without b

Re: Status of pythondialog in Debian

Florent Rougon wrote: > Yes, I know the technical conditions that justify Conflicts and > Replaces, I only proposed them as a means to get users' package managers > to automatically propose the upgrade from python-dialog to > python3-dialog... Hmm... I believe I spoke a bit

Re: Status of pythondialog in Debian

Tristan Seligmann wrote: > Replaces: would not be appropriate or necessary since none of the > files are overlapping; this is only necessary when two packages > install files to the same location, and the one package must be > installed over the other. > > Conflicts: would not be appropriate eith

Re: Status of pythondialog in Debian

Hi, Tristan Seligmann wrote: >> The package is already uploaded, right? > > It is, and processed through NEW. I uploaded -2 earlier today to fix > #766041 and I believe it is now in unstable; it looks like the PTS > isn't updated yet, though, possibly related to some problems with > Debian infra

Re: Status of pythondialog in Debian

'evening! Tristan Seligmann wrote: > Looks like your Debian account is marked emeritus; if you wish to > re-activate it you could follow the process described here: > > https://www.debian.org/doc/manuals/developers-reference/developer-duties.html#returning Thanks for the info, maybe later... >

Re: Status of pythondialog in Debian

Hi, Tristan Seligmann wrote: > Thus I intend to take over the existing ITA and inject Florent's > source package into DPMT now, under the old source package name > (pythondialog), and review it for upload. Florent, would you like to > be listed as one of the package co-maintainers? If you don't

Re: Status of pythondialog in Debian

Hi, Barry Warsaw wrote: > Please note that this is not a team-maintained package. We could do a > non-maintainer upload of it, but I'd rather see either 1) Adam, the current > maintainer CC'd here, update the package, or 2) have Adam move the package to > the Debian Python team, where we could

Status of pythondialog in Debian

Hello, As the upstream maintainer of pythondialog, I feel a bit concerned about its status in Debian, in particular about what is going to go into jessie. In short, I'd rather see the package removed from Debian than stay in the current status. The package that is currently in unstable is terribl

Re: where is the Python tutorial?

Hi, "Tshepang Lekhonkhobe" <[EMAIL PROTECTED]> wrote: > Hi, > I looked in the packages list and couldn't find the tutorial and was > wondering if it was removed from the archive. Was it? Doesn't look so. Install python2.5-doc and you'll have: /usr/share/doc/python2.5/html/tut/tut.html python

Bug#335901: O: pyxmms-remote -- command-line interface to XMMS

Package: wnpp Severity: normal Hi, I cannot work on PyXMMS-remote anymore and am hereby orphaning it. Description: command-line interface to XMMS PyXMMS-remote allows you to control (or start, or terminate) an XMMS session from your shell's command-line (or a program, or a MIME-aware applic

Bug#335900: O: pyxmms -- Python interface to XMMS

Package: wnpp Severity: normal Hi, I cannot work on PyXMMS anymore and am hereby orphaning it. Description: Python interface to XMMS PyXMMS, packaged as python-xmms in Debian, is a set of Python bindings for the libxmms library. With PyXMMS, you can control an XMMS session and manage the XMM

Re: Python only packages and the new Python policy

Matthias Klose <[EMAIL PROTECTED]> wrote: > look at the archives. python-central is a step forward, but it doesn't > do anything to solve the forward conflicts for python applications and > modules outside of sys.path. OK, thanks for the explanation. -- Florent -- To UNSUBSCRIBE, email to [E

Re: Python only packages and the new Python policy

Sergio Talens-Oliag <[EMAIL PROTECTED]> wrote: > OK, then I'll take a look and see if I can write a script to support it, it > seems quite simple but maybe I'm missing something... Before you write another script, I think it would be useful to know why python-central was not adopted. I have a

Re: [LONG] python2.3-subversion leaves byte-compiled files after removal in /usr/lib/python2.3/site-packages/{lib,}svn/

Hi, Frédéric Bothamy <[EMAIL PROTECTED]> wrote: > IAIUI this is against Python Policy 2.5 Module Bytecompilation. Should I > file a bug report or have I missed something? You should file a bug report against python2.3-subversion. -- Florent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with

Re: Question about python policy

Fabian Fagerholm <[EMAIL PROTECTED]> wrote: > It probably doesn't solve the case where you need a certain version of > python to run build-time test cases and such. I guess it might have been > a good idea, but since it didn't catch on, perhaps it was too > complicated. Build-time tests are run,

Re: Question about python policy

Fabian Fagerholm <[EMAIL PROTECTED]> wrote: > Hello all, Hi, > Firstly, it seems a little silly to duplicate all the code in both > packages. I guess there's really no other way of doing it, since there There used to be a tool called python-central (look in the mailing list archives) that allow

Re: installing stuff to sbin with distutils

Andreas Schuldei <[EMAIL PROTECTED]> wrote: > how do i install python progs to /usr/sbin with pythons > distutils? > > i manage to install stuff to bin, using scripts=[...] but not > sbin I am not a distutils guru (but I use it for a set of extension modules I wrote), but it may well be that you

Re: Bug#230704: zope-testcase: SOFTWARE_HOME and INSTANCE_HOME can break install.

"Donovan Baarda" <[EMAIL PROTECTED]> wrote: > G'day, Hi, > I was going to reply "this is why many packages sanitize PATH in their > scripts", but after checking through /var/lib/dpkg/info/* it seems they > don't. Indeed, Policy § 6.1 says they should not: , | Programs called from maintaine

Re: Correct location of .py and .pyc files

Terry Hancock <[EMAIL PROTECTED]> wrote: > Okay, I stand corrected. > > Three people including two I know are long-time developers > have replied that .pyc/.pyo files are indeed architecture > independent, and that changing this is unlikely: Thanks for having asked the question on comp.lang.pytho

Re: Bug#221523: Causes build failures

Junichi Uekawa <[EMAIL PROTECTED]> wrote: >> > The configure script is checking for 'python' script. >> > >> > What was the original reason for the 'recommends' instead of >> > 'depends'? It's not really clear to me. >> >> some people wanted to be able to keep the default python version at >> v

Re: Correct location of .py and .pyc files

Terry Hancock <[EMAIL PROTECTED]> wrote: > There was some discussion on comp.lang.python about > standardizing the bytecode awhile back, but the consensus > was that the standardized part of Python is *the source code*. > IMHO, they (/we) don't want to encourage obfuscated > distributions of Pyth

Re: Correct location of .py and .pyc files

Hi, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le dim 16/11/2003 à 11:34, Matthias Klose a écrit : >> There is no reason why /usr/share/ should be disallowed. > > That depends on whether .pyo files really are architecture-independent. > At least the generated files are different on different a

Re: Correct location of .py and .pyc files

Marco Paganini <[EMAIL PROTECTED]> wrote: > So, it would be /usr/share after all, as the .py modules in question are > not architecture dependent, but *are* private. > > Correct? Yes, I think you can go for /usr/share/package. -- Florent

Re: Correct location of .py and .pyc files

Matthias Klose <[EMAIL PROTECTED]> wrote: > Joss proposal is already incorporated into the proposed policy found > in the python package. > > There is no reason why /usr/share/ should be disallowed. I > changed the proposed policy to: [private modules can now go to /usr/share/package/] Good, tha

Re: linda ... Re: Correct location of .py and .pyc files

Cory Dodt <[EMAIL PROTECTED]> wrote: > I note that applications written in python, such as my aap package, go into > /usr/lib/ per the policy (section 3.1.1), but linda does not support > this. _all packages (most things written in Python) belong in /usr/share > according to linda, but /usr/lib a

Re: Correct location of .py and .pyc files

[Ugh, sorry for the double message, Marco] Marco Paganini <[EMAIL PROTECTED]> wrote: > Hi All, Hi, > I need to package a Python application that depends on multiple modules. > I've been wondering about the correct location for the modules (both .py and > .pyc files) in Debian. FHS states that a

Re: python related packages out of date on m68k/mips/mipsel/arm/s390/powerpc

Florent Rougon <[EMAIL PROTECTED]> wrote: [ m68k build for pyxmms failing with "/usr/bin/apt-cache failed" at the very beginning ] > I did not see this problem referenced on debian-m68k. Who should I > contact? Mmmm, it seems the appropriate list for discussions about th

Re: python related packages out of date on m68k/mips/mipsel/arm/s390/powerpc

Hi, Matthias Klose <[EMAIL PROTECTED]> wrote: > missing builds: [...] > pyxmms (m68k, mips, not in testing) The mips build hasn't happenned yet according to http://buildd.debian.org/build.php?arch=&pkg=pyxmms (pyxmms entered the archive recently). As for the problem on m68k, it seems

Re: MailMan Security patch for Woody Broken?

Matt Zimmerman <[EMAIL PROTECTED]> wrote: > Python 1.5.2 (#0, Jan 13 2002, 13:19:04) [GCC 2.95.4 20011223 (Debian > prerelease)] on linux2 > Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam > >>> ''.lower() > Traceback (innermost last): > File "", line 1, in ? > AttributeError: 's

Re: standard Python build for Debian distributions

Damon Fasching <[EMAIL PROTECTED]> wrote: > Hi, Hi, To complete Chris's answer, if you want to know which Debian binary packages to install in order to get the same things as if you had installed from the source, you may want to something like: grep-available -enF Source -s Package '^python2\

Re: python-gtk and python-gtk2 (and gnome packages), please comment

Torsten Landschoff <[EMAIL PROTECTED]> wrote: > Problem with this: No matter which python-gnome release shall be used > the upstream will use "import gnome.ui". So which binding should he > get? Yes, this is problematic. The question "Why not having gtk2, gnome2, etc. modules instead of gtk, gn

Re: python-gtk and python-gtk2 (and gnome packages), please comment

Hi, Torsten Landschoff <[EMAIL PROTECTED]> wrote: > that route. But - do we want to continue supporting the old gnome > for sarge? Otherwise I would be for removing the old binding > entirely before the next release. Just wondering if any dependent > package will be updated for the new gnome. O

Re: Bytecode compilation

Dave Swegen <[EMAIL PROTECTED]> wrote: > Not having really followed the discussion, and being faaar too bone-idle > to actually look it up in the archives, this is my view on it: Shipping > pre-compiled really isn't an option, as the size increase would be > unacceptable - not only from a debian a

Re: Bytecode compilation

Dave Swegen <[EMAIL PROTECTED]> wrote: > Surely the right way to handle this is using debconf in the main python > packages, and subsequently any packages check this to see if python > scripts should be compiled or not. Or have I missed anything? You are talking about (compiling the .py in postin

Re: Emacs in build-depends of python2.1

Florent Rougon <[EMAIL PROTECTED]> wrote: > immutable, so repeatedly inserting/replacing small strings into the > whole document's string, having all the includes recursively > expanded would be quite bad) or something like (c)StringIO. But then > you

Re: Emacs in build-depends of python2.1

"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> wrote: > The problem is we now have a piece of a fairly common package using > script(s) in a language few understand. So if you get hit by a bus > someone WILL have to reverse engineer that script. This is the same Well, I guess you mean "py2texi.el's up

Re: Emacs in build-depends of python2.1

Bastian Kleineidam <[EMAIL PROTECTED]> wrote: > python2.1 (2.1.3-3) from sid > py2texi.el is a generated file > it is included in debian/patches/info-docs.dpatch > the fixinfo.el is replaced by it, fixinfo.el is not run. OK, py2texi and fixinfo have nothing in common. > Dont know, seems that a l

Re: Python in package development?

Matthias Klose <[EMAIL PROTECTED]> wrote: > huh? potato was released with 1.5.2, woody with 2.1 as default, > woody+1 probably with 2.4. So someone upgrading faces the features Potato's Python version is not relevant for the discussion. Luca was talking about tools to be written, so what is to be

Re: Python in package development?

Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote: > I'm not sure of the usefulness of this approach. > Even if python is one of my favorite language, it's still too young compared > wit perl and it's staility. python is still evolving, and we have not, afaik, > sufficent warranties of what

Re: Python and Emacs

Jonne Itkonen <[EMAIL PROTECTED]> wrote: > And I again opposite to your opinion. If everybody uses tab to indent, > then everyone can set his or her environment to render that tab with > as many spaces as necessary, _or_ when using proportional fonts, as > long an empty space as needed. I really d

Re: Python and Emacs

[EMAIL PROTECTED] (Jérôme Marant) wrote: > Hi, Hi, > I'm sorry, this may be a bit off topic but I don't really know > where I can post this question. fr.comp.applications.emacs would be quite OK. ;-) > I'm a bit annoyed with Emacs when editing Python programs because > Emacs always rep