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 <f.rou...@free.fr> Date: Thu, 8 Oct 2015

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

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

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

Re: Status of pythondialog in Debian

Tristan Seligmann mithra...@mithrandi.net 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

Re: Status of pythondialog in Debian

Hi, Tristan Seligmann mithra...@mithrandi.net 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

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

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

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

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

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

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

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

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 allowed

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 cannot

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 maintainer scripts

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 version 2.2, but

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

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 Python

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/module should be disallowed. I changed the proposed policy to: [private modules can now go to /usr/share/package/] Good,

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

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

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 to

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

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

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

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 have to do heavy regexp matching

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 upstream

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 lot of

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 don't

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