Re: search.html doesn't look like a Sphinx search page
On Sat, Feb 25, 2012 at 08:00:26PM +0100, Pietro Battiston wrote: I want to make clear that I do not oppose the view that Google Analytics should be stripped off from documentation... I'm just saying that as far as I understand the policy doesn't state that. _Also_ because it doesn't mention the privacy issue (and for instance the .js which is the subject of bug #637580 _could_ be provided locally, and that wouldn't entirely solve the bug according to the submitter). It is probably true that the Debian Policy does not mandate that we protect the privacy of our users. That should not have to be mandated: it is clearly the right thing to do, just like we protect our users' security. -- http://www.kickstarter.com/projects/docstory/mix-1-2-albanian signature.asc Description: Digital signature
Re: restarting processes when python libraries are upgraded?
On Mon, Jun 20, 2011 at 11:51:30AM +0800, Paul Wise wrote: Since python doesn't keep .py files open its hard to use things like checkrestart to find out which servers to restart when upgrading a python library for security updates. I wonder if a dpkg triggers based mechanism could perform this function. Any thoughts? For packaged Python stuff, surely dependencies give sufficient indication of what may need restarting? -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110620085016.ga30...@havelock.liw.fi
Re: restarting processes when python libraries are upgraded?
On Mon, Jun 20, 2011 at 11:59:44AM +0200, Bernd Zeimetz wrote: On 06/20/2011 10:50 AM, Lars Wirzenius wrote: On Mon, Jun 20, 2011 at 11:51:30AM +0800, Paul Wise wrote: Since python doesn't keep .py files open its hard to use things like checkrestart to find out which servers to restart when upgrading a python library for security updates. I wonder if a dpkg triggers based mechanism could perform this function. Any thoughts? For packaged Python stuff, surely dependencies give sufficient indication of what may need restarting? Not necessarily. Some packages have dependencies which are only used by a part of the modules in the package, or they have recommended packages which are installed but not used by your daemon... and so on. Restart them anyway. A proper daemon will deal with restarted gracefully and the rest can't be helped. Security upgrades are rare enough, hopefully, that this won't be a frequent problem. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110620102124.ga5...@havelock.liw.fi
Re: ITP or RFP
On Mon, May 23, 2011 at 05:43:43PM +0200, Nicolas CANIART wrote: I'm going to package the following python module I need: python-django-gerbi-cms (http://packages.python.org/django-page-cms/) I would like to now whether I should file an RFP or ITP bug report since I am no debian maintainer and if, when the package is ready, someone could sponsor me so that the packages find its way to the main archive. That would be an intent to package, or ITP, even if you need someone to sponsor the upload. Use an RFP only when you are requesting for someone else to make a package. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110523160727.ga10...@havelock.liw.fi
Introduction
Hi, I'd like to join the DPMT. I'm going to be uploading my backup application (Obnam, http://braawi.org/obnam/) to Debian, and it has a number of dependencies on Python libraries, which I've also written. I'm starting with the dependencies. In order to have the packages maintained as well as possible, I'd like to do it via DPMT. This should ensure that whoever encounters my packages has the last amount of surprises with them. My first package will be the tracing library: * http://liw.fi/tracing/ * http://pypi.python.org/pypi/tracing/ * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=623857 I have upload privs to Debian, but it's been a while since I did that, so I'll be appreciating a packaging review if anyone's into doing that. Thanks. -- Blog/wiki/website hosting with ikiwiki (free for free software): http://www.branchable.com/ -- 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/1303587528.2488.38.ca...@havelock.liw.fi
Re: Need help with revelation
ma, 2008-12-22 kello 21:00 +, b...@bc-bd.org kirjoitti: Hello debian-python, I have been maintaining revelation in the past, a GNOME2 Password manager. I will most likely orphan this package because: Before this gets removed from the archive: is there a good replacement? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: python2.5 fails to import pygtk and gtk modules
On ti, 2007-01-16 at 09:53 +0200, Tshepang Lekhonkhobe wrote: Maybe there should be a big warning in the release notes (or elsewhere) that python2.5 supports NOT the loading of (certain?) external modules... Sure, something like Python 2.5 is included in etch, but is not fully supported by all extension modules. Python 2.5 is the default version of Python in etch.. Since you're the one feeling strongly about this, please feel free to file a wishlist bug against the release notes. :) -- Programming should be fun, otherwise you're doing something wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On ma, 2007-01-15 at 18:15 +0200, Tshepang Lekhonkhobe wrote: On 1/2/07, Matthias Klose [EMAIL PROTECTED] wrote: Alexandre Fayolle writes: Am I the only one with a mixed feeling about this? I mean, we spent time last spring updating our packages to use the new Python policy, write nice loops in debian/rules to build for all versions specified by `pyversions -r -v`. Now we would need to tweak the Makefile again and clutter it with a hardcoded 2.5 in the list even though this version is requested debian/control (or in some other place if you chose the other way without XS-Python-Version). I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) When etch/sid went into UVF after the 2.5 release, many depending packages and extensions were not yet usable/buildable for 2.5. Adding 2.5 was not considered an option after talking with the release team (Andreas Barth), because it would have introduced a lot of RC reports, which either needed to be fixed by new upstream versions or disabling 2.5 support for this extension. Explicitely adding support for 2.5 on a per package base doesn't introduce these extra RC failures during our release process at the cost of having the burden on the package maintainer, not the release team. Looking at mx and numeric, support for 2.5 can be added, but for example PIL explicitely states in the 1.1.6 release notes that this version adds complete support for 2.5. Maybe support for 2.5 for all extensions looks possible now, but at the time of the UVF it wasn't. You might want to create a python-etch repository and rebuild all extensions where possible to support 2.5, and add new upstream versions where necessary. Once done, propose the versions in this repository to the release team, but I doubt it will be allowed into etch. Mixed feeling yes, but IMO unavoidable with our release schedule for etch. Is there work done on this? If not may python2.5 be removed from Etch, or should I file a grave bug, if python2.5 doesn't load pygtk and gtk modules, then what use is it?. Er, there's plenty of use for plain 2.5, without any extension -- Programming should be fun, otherwise you're doing something wrong. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
Gah, I meant to press control-Backspace, not control-Enter. Sorry. On ma, 2007-01-15 at 16:28 +, Lars Wirzenius wrote: On ma, 2007-01-15 at 18:15 +0200, Tshepang Lekhonkhobe wrote: Is there work done on this? If not may python2.5 be removed from Etch, or should I file a grave bug, if python2.5 doesn't load pygtk and gtk modules, then what use is it?. Er, there's plenty of use for plain 2.5, without any extension I meant to say: there's plenty of use for plain 2.5, without any extension modules. For example, most of my code works with any version of Python from 2.1 onwards, and it's nice to be able to verify this, so having 2.5 packages is certainly useful to me. It will also make it easier to backport extension modules after etch is released. (I'm not opposed to removing 2.5 from etch, if the release managers deem it the best course of action, but doesn't work with pygtk isn't a reason, in my rather strong opinion.) -- RFC 1437 - yet another MIME specification Microsoft ignores -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#382252: Python PATH problem
On ke, 2007-01-03 at 18:14 +0100, Wouter van Heyst wrote: Pierre already mentioned that is not the problem, but I'd like to explicitly state that that would make it impossible to run applications if you only have the .pyc files, a valid use-case, although not something that will arise from Debian packages. While we're listing personal preferences, I'm firmly in the camp that belives Python should create .py[co] files only when explicitly asked, never implicitly just by running programs. That way, whenever someone explicitly has the created, they're also in charge of removing them. Too bad upstream Python seems to have rejected or abandoned the PEP to make this happen. -- It doesn't matter who you are, it's what you do that takes you far. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to package a single Python file?
I am both the upstream developer and Debian packager of Lodju, a digital photo organizer. The version of the package that is now in Debian is written in C, but I am rewriting it in Python. Lodju needs to read the EXIF headers in image files. These are headers that a digital camera adds to a JPEG and contain information about, say, when the photograph was taken, and details about the exposure. I use Gene Cash's EXIF.py for reading them. It is a single pure Python module. I'm wondering how to package it for Debian. The easy solution is to include it in Lodju, but that mixes my code and foreign code, and is not very elegant. It is also not good for those who also would like to use EXIF.py in their own programs. I could put EXIF.py in its own package, but it feels silly to make a separate package for a single file. This is, however, what I'll be doing unless someone suggest a better option. Suggestions, anyone? -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Python policy update
On su, 2003-08-24 at 08:38, Joe Wreschnig wrote: On Sat, 2003-08-23 at 23:54, Donovan Baarda wrote: The problem is, run pydance as any user with write permissions to /usr/share/games/pydance, and the *.py's there will be compiled and saved as *.pyc's using whatever version of python was used at the time. When you de-install or purge pydance, the *.pyc's will be left behind. The only such user should be root, who shouldn't be running pydance anyway... Not pydance in particular, perhaps, but this is a more general problem with Python programs packaged in this way. My own package, enemies-of-carlotta, has a program that root might very well want to run (e.g., to list the users on a mailing list), and it would be bad for the .pyc to be regenerated in this case for the wrong python version. I haven't a solution for this right now. -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: Woody backports of Python2.[23]
On ke, 2003-08-20 at 10:59, Andreas Tille wrote: are there any apt-get sources for Python2.[23] for Woody? http://packages.debian.org/stable/interpreters/python2.2.html Python 2.2.1 is in woody proper. Unstable has 2.2.3. I don't know about backports (neither in general, nor about Python 2.3 in particular), sorry. -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: python 2.2 to python 2.3 transition
On su, 2003-08-10 at 10:55, Matthias Klose wrote: This seems to be a common misunderstanding. Therefore the CC to debian-python that I have something as a reference. ACK. (I'm on -python, so further Cc's are not necessary.) Lars Wirzenius writes: As far as I know, it already works with Python 2.3. And 2.2. And 2.1. I like the fact that the same package works fine both on woody and in unstable. :) No. The package ships compiled python modules. These are maybe compiled with 2.1 or 2.2. If a user other than root uses these modules, python2.3 detects them as invalid and compiles them on the fly each time the module is used. Um, yeah, it does contain a .pyc. I don't think it should: the postinst compiles the eoc.py file. The inclusion of the .pyc file seems like a bug due to unforeseen interaction with the upstream Makefile's install target. I'll have to remove the .pyc from the .deb in the next release. -- Debian developers for gentleness.
Re: python 2.2 to python 2.3 transition
I subscribe debian-python. Please don't Cc me when you reply to the list. On su, 2003-08-10 at 13:06, Matthias Klose wrote: Lars Wirzenius writes: Um, yeah, it does contain a .pyc. I don't think it should: the postinst compiles the eoc.py file. The inclusion of the .pyc file seems like a bug due to unforeseen interaction with the upstream Makefile's install target. I'll have to remove the .pyc from the .deb in the next release. this does not help. it will be recreated when a user runs as root: python foo.py. so you have to remove it anyway in the prerm. Er, did I misunderstand something? I make a .deb that contains a .py, but not a .pyc or .pyo, and the postinst compiles it with whatever is the default version of Python on the system. The prerm removes the .pyc and the .pyo. What is the problem in this scenario? My .deb already does all of the above, except for inadvertently including a .pyc, which is a mistake and a bug. (There will be a problem when the default version of Python changes. I don't think we have a way to deal with that.) -- Debian developers for gentleness.
Re: python 2.2 to python 2.3 transition
On su, 2003-08-10 at 15:56, Josselin Mouette wrote: If you can provide a good solution to achieve this, it will surely be welcome. In the meantime, please don't do what you describe with packages shipping .py files. You should depend on python (= 2.3), python ( 2.4) - this can be done automatically with dh_python. Depending on Python 2.3 when a package works fine with 2.1 and 2.2 as well is not a good solution in my opinion. It prevents, for example, being able to use the package on woody, even if it is uploaded only into stable. (This happens to be the case with my package.) I don't have better suggestions at the moment, though. -- Debian developers for gentleness.
