Re: ITP persistent and merging zope and python teams?
On Wed, Jun 25, 2014 at 10:50:58AM -0400, Barry Warsaw wrote: AFAICT, the persistent library is not yet packaged for Debian. https://pypi.python.org/pypi/persistent/4.0.8 I've search for existing packages and wnpp/ITP and not found anything. I think this is also required as a build dependency for zope.component. It's possible I've missed it though, so I'm going to file an ITP and work on the packaging, but please do let me know if it's already available. I'm aware of python-zope.component-persistentregistry, but that's a metapackage and not specifically related to the above. I plan on naming the source package `python-persistent` since claiming `persistent` seems a bit presumptuous. I'm going to put it under DPMT. As a side question, I wonder if it still makes sense to continue to segregate the ZTK packages under pkg-zope-developers. Why not fold all/most/some of those packages into DPMT? They're both under svn so it should be pretty easy to do, and the DPMT seems to be the much more active team than p-z-d. Thoughts? As I mentioned before, I think it's a great idea :) I think that you should give it some time for any objections to be raised. If none are, you should go ahead. Perhaps seek out Gediminas' opinion. As he is the next most active member of pkg-zope-developers and would probably have to join DPMT to carry on with the ZRK package maintenance. Cheers, -Barry ___ pkg-zope-developers mailing list pkg-zope-develop...@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-zope-developers -- Brian Sutherland -- 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/20140625193113.GA60845@Brians-MacBook-Air.local
Re: Python 3.4 and ensurepip (rehashed, long)
On Fri, Mar 21, 2014 at 01:23:53PM +0100, Piotr Ożarowski wrote:
[Barry Warsaw, 2014-03-19]
TL;DR: Let's re-enable the ensurepip module in Python 3.4, and possibly
address some usability issues. We should descend en masse on Montreal
and
stage a revolt at Pycon. :)
IMO our ensurepip.py should look similar to this:
| try:
| from pip import *
| except ImportError:
| raise Exception('Please ask administrator to install python3-pip
package.'
| ' Note that installing packages system-wide using pip
is'
| ' considered harmful, please do not report Python
related'
| ' bugs in Debian bugtracker if you decide to do that.')
IMO we should warn users that they can^W will break their systems and
`sudo pip install ...` should raise an exception if
--i-will-not-blame-debian option is not enabled.
I recently had to clean up after a sysadmin, previously explicitly
warned not to, used sudo pip install I think the option should
require an argument which must match with a randomly generated string.
That way only the NSA could ever actually use the option as only they
own all the random numbers.
/sarcasim
--
Brian Sutherland
--
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/20140326161329.GA25017@Brians-MacBook-Air.local
Re: python3.3 status
On Fri, May 24, 2013 at 11:24:20AM -0400, Barry Warsaw wrote: On May 07, 2013, at 02:01 PM, Jakub Wilk wrote: flufl.bounce FTBFS #707086 This one is really because of the ancient version of zope.interface in sid/jessie. It's not until z.i 4.0.2 that Python 3.3 support was added, although 4.0.5 is the latest version in the Cheeseshop. CC pkg-zope-developers to get their feedback. FWIW, we have 4.0.5 in Ubuntu, so I'd be willing to help merge the Ubuntu changes back into Debian if the Zope team wants. Please do. We recently discussed what to do now that Wheezy is out: http://lists.alioth.debian.org/pipermail/pkg-zope-developers/2013-May/008547.html The gist is that we got to a consensus on: * Merge changes from Ubuntu * add python3 support where possible * try stick to versions in http://docs.zope.org/zopetoolkit/releases/packages-2.0a1.html where possible Any help with that agenda would be appreciated :) -- Brian Sutherland -- 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/20130524154805.GA69767@Brians-MacBook-Air.local
Re: Double build failures
On Thu, May 10, 2012 at 12:07:28PM +0200, Jakub Wilk wrote: * Brian Sutherland br...@vanguardistas.net, 2012-05-10, 10:36: AFAIK, the problem is double build failures because dpkg detects that there are leftovers/changes from the first build. You end up with failures when a second build is attempted [1]. This leads people to use workarounds like this snippet taken from the style guide [2]: override_dh_auto_clean: dh_auto_clean rm -rf build rm -rf *.egg-info (Note that rm -rf build is unrelated to egg-info problem.) There are simpler workarounds, though: 1) Add *.egg-info/* to debian/clean. (This requires compat = 7.) 2) Add extend-diff-ignore=^[^/]+\.egg-info/ to debian/source/options. (This requires source format 3.0.) Which work sometimes, but sometimes cause other bugs with the second build. For example, when setup.py uses setuptools+include_package_data without specifying a MANIFEST.in. In that case deleting *.egg-info causes missing files in the built package. Interesting. Can you show us example of a package like this? For example zope.configuration, or zope.security, had this problem around Nov 2011. Even running the tests didn't help as they ran at build time against the unpacked source. In any case, solution 2) wouldn't trigger this problem. Yeah, thats the approach that was used in the end for the zope.* packages. Any objections (from anyone) to updating the style guide to prefer solution 2? -- Brian Sutherland -- 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/20120510143708.gb24...@minimac.lan
Re: autopkgtest'ing against multiple Python versions
On Sat, Apr 21, 2012 at 10:33:24PM +0200, Jakub Wilk wrote: 3) Provide one test that is run against all installed versions (pyversions -i): Tests: test-installed Depends: python-pet-module This is a variant of 2 which is more friendly to users who can't or don't want to install extra packages. It's also less useful for users who would install test dependencies automatically anyway (since then you do want to install python-all). This issue could be fixed if autopkgtest supported weak dependencies, e.g.: Tests: test-installed Depends: python-pet-module Recommends: python-all This is the way we did it in the zope.* packages. But, as an observer, I'm puzzled by 2 things: * How are you actually running the tests with adt-run. Did you actually setup a testbed, or is there now an easy way to run the tests? * Do you run the tests against the code installed via the .deb package or on the code in the unpacked source? -- Brian Sutherland -- 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/20120430174742.ga45...@minimac.lan
Re: to distribute_setup() or not, that is the question
On Fri, Jan 27, 2012 at 08:36:40AM -0500, Barry Warsaw wrote: On Jan 27, 2012, at 01:14 PM, Brian Sutherland wrote: Extra bonus points for getting PJE to change the DEFAULT_VERSION in setuptools trunk to something OK for most major distributions;) Here's a thought: What if we proposed a hook to get DEFAULT_VERSION from a file or environment variable? Then at least on Debian systems we could provide that file in our python-setuptools package, or set the envar in our d/rules files? I'd probably prefer the former since it would allow us to specify the default version for the majority of Python packages. The two aren't mutually exclusive, but I'm not sure both would be useful. What would that file name be? Is this just adding more nonsense to insanity? If it would be useful, I'd be happy to pursue it in upstream. I'm not sure it's more useful than just setting DEFAULT_VERSION to a very old version. It's certainly more complex. -- Brian Sutherland -- 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/20120127143828.GB45898@Brians-MacBook-Air.local
Re: New python-defaults upload to experimental
On Thu, Jul 07, 2011 at 09:18:19AM -0400, Scott Kitterman wrote: On Thursday, July 07, 2011 04:27:32 AM Piotr Ożarowski wrote: [Scott Kitterman, 2011-07-07] B.Packaging Tools - B.1. distutils - B.2. python-support - B.3. python-central - B.4. CDBS + B.1. dh_python2 and dh_python3 + B.2. distutils + B.3. python-support + B.4. python-central + B.5. CDBS changing these IDs might not be a good idea (think about all places where they're referenced), why not adding dh_python* as B.5? I could, but it seemed odd to reference the non-deprecated tool after the deprecated ones. Unless someone else speaks up I'll move it after. perhaps B.0. ? -- Brian Sutherland -- 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/20110707152313.GA4981@Boo.local
Re: restarting processes when python libraries are upgraded?
On Mon, Jun 20, 2011 at 11:51:30AM +0800, Paul Wise wrote: Hi all, 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? Havn't looked deeply at all, but perhaps the right level to do something like this is an import hook [1]. It could probably write to some datastructure when files are imported or even just open (and keep open) the imported file so checkrestart works unchanged. [1] http://www.python.org/dev/peps/pep-0302/ -- Brian Sutherland -- 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/20110620131053.GA12613@Boo.local
Re: Current state of packaging Python software for Debian
On Wed, Jun 15, 2011 at 10:18:25AM +0200, Zygmunt Krynicki wrote: W dniu 15.06.2011 03:28, Ben Finney pisze: If we are talking from a perspective of upstream developers that also maintain their packages then I would *love* to see setup.py sdist-test and would use it each day. ;-) How would a putative ‘sdist_test’ differ from ‘test’? Why is this an argument for a new command, and not an argument to improve what is done by ‘test’ anyway? Pure test runs the test on the check-out of the code and is usually invoked by the upstream developer. It can (and often does) run on a superset of files that are distributed with sdist). In contrast, the theoretical sdist_test would first create a release tarball with sdist, unpack it to some temporary directory and run `setup.py test` there. Such a command would be useful for checking that project manifest file contains everything desired to make the program run correctly (I often miss something and only realise it's missing when I start packaging). IMHO it should be a separate command to ensure that 1) stuff that works today keeps working 2) there is no performance penalty for running setup.py test that would be required by setup.py sdist_test. I think what you really want to do is test an installation. I.e. run the tests from the source code on an installation. Note that the installation should not necessarily have to contain the tests. Theres some code and a spec out there to standardize this for Debian source/binary packages, see the recent debian-devel thread [1]. I've done this for some python-zope.* packages, but I need to use a very non-standard testrunner incantation to run the tests. I'm also forced to install the tests. Ideal would be some kind of standard: $ pysetup test-installation command which would run the tests from an unpacked sdist against an installation which is expected to already be on the python path. [1] http://lists.debian.org/debian-devel/2011/01/msg00813.html -- Brian Sutherland -- 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/20110615091142.GF83513@Boo.local
Re: [kob...@debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]
On Sun, Sep 20, 2009 at 01:34:24PM +0200, Matthias Klose wrote: On 02.07.2009 13:05, Jonas Meurer wrote: why not wait for zope2.12 with python2.5/2.6 support, upload that one to debian/unstable and afterwards file a request for removal for zope2.10/zope2.11/python2.4? I believe that a zope2.12 release candidate will be published within the next month, given that a beta2 has already been published on 27. of may. That way we would have a zope2 release available in debian/unstable all the time would. The zope2.12 release candidate was released last week. I updated the packaging in the zope team repository. An upload still requires some work, because some modules still need to be packaged. These are: Acquisition DateTime ExtensionClass Persistence RestrictedPython tempstorage zLOG zope.container Note: Persistence and ExtensionClass (I think) are packaged in python-zodb already zope.contentprovider zope.contenttype zope.deferredimport zope.formlib zope.lifecycleevent zope.pagetemplate zope.processlifetime zope.sendmail zope.sequencesort zope.site zope.size zope.structuredtext zope.tal zope.tales zope.testbrowser [zope-functional-testing] (UNRELEASED?) zope.viewlet zope.app.form zope.app.publication zope.app.publisher zope.app.schema All other zope dependencies are available as modular zope packages in unstable. Please have a look how these are packaged, and start packaging. The current packaging of the zope.* packages is the way it is because they are required to be easily backportable. I'm working on a few van.pydeb plugins for debhelper 7 that'll make the packaging much more elegant. But we'll only use that for the packages the zope team maintains after the current release. However, if you're interested in using this for the any of the above packages, please send me a private mail. As an interim solution it could be useful to include the still missing modules in the zope2.12 package until all these are packaged. +1, especially for things like zope.app.* or zLOG that Zope2 is looking to remove as dependencies. The good news is that the schooltool project already did package a lot of these, so you only need updates to recent upstream versions, and an update from python-vanguardistas to python-van.pydeb (Brian might give more help on this). Honestly, these packages are so simple that it's probably easier to just remake them by hand. I know that not the whole zope team is interested in these additional modules, so I'm CCing the zope2.x uploaders directly to get involved with the packaging. Of the list presented, we are only currently interested in packaging zope.sendmail (See an earlier mail from me). The others have very difficult dependencies or are semi-deprecated. -- Brian Sutherland -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [kob...@debian.org: The future of Zope{2, 3} and Plone in Debian and Ubuntu]
On Tue, Jun 23, 2009 at 01:48:41PM -0400, Erik Rose wrote: Buildout is really a development tool and not universally lauded as a deployment solution (though it's ubiquitous right now simply because it's the only thing that works). It suffers many reliability issues in both its design and its execution that make it unsuitable for our production environments There's also the option of converting a built buildout into a package for deployment on production environments. I don't use it myself, but some do use zc.sourcerelease for this: http://pypi.python.org/pypi/zc.sourcerelease/ Personally, I prefer to manage Debian repositories and mirror them into PYPI style indexes of eggs (or a set of buildout versions). Development buildouts then use the PYPI index: http://pypi.python.org/pypi/van.reposync -- Brian Sutherland -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Running unittest on build?
On Fri, Jan 11, 2008 at 08:27:22PM +0100, Vincent Bernat wrote: Hi ! Should we run unittest when building a python package? The main drawback is that we need to add more build-dependencies. You could try autopkgtest. Aside from reducing build dependencies, you can also re-test the package as the dependencies are upgraded. -- Modularise. Use subroutines. - The Elements of Programming Style (Kernighan Plauger) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Brian Sutherland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparing for python2.5 / python -dbg packages
On Thu, Jul 19, 2007 at 11:51:09PM +0200, Bernd Zeimetz wrote: python version for lenny. Still hoping to drop support for 2.4 once a zope2.x version supporting 2.5 is released... Today I heard that opensuse run Zope with python 2.5 since Zope version 2.9.4. Did anybody ever try to run Zope in 2.5? If there's something not working, we should take care of it. Did they ever actually run the tests then? http://archives.free.net.ph/message/20070616.183425.b42a7509.en.html#zope-zodb-dev That mail was just over a month ago. -- Brian Sutherland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: preparing for python2.5 / python -dbg packages
On Fri, Jul 20, 2007 at 11:35:37AM +0200, Bernd Zeimetz wrote: Did they ever actually run the tests then? no clue, I know why I'm not using suse ;) Yep, having ZEO lock up on you after an upgrade wouldn't be fun. http://archives.free.net.ph/message/20070616.183425.b42a7509.en.html#zope-zodb-dev That mail was just over a month ago. as I understand one of the mails in the thread this problem seems to be solved in one of the latest dev versions, we should keep an eye on it. They've got a google SoC student busy trying to get things working on python2.5. Apparently there's a lot of stuff that changed. -- Brian Sutherland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unicode in setup.py file causing RC bug
On Mon, May 07, 2007 at 09:27:18PM -0400, Scott Kitterman wrote: On Monday 07 May 2007 20:43, Kevin Coyner wrote: Or 3. Patch setup.py to expect it. I believe if you add: # -*- encoding: utf-8 -*- to the file before the unicode characters are encountered the first time, that should solve your problem. I didn't look at your package, but that worked for me before for a similar issue. I believe it needs to be on either the first or second line: http://docs.python.org/ref/encodings.html -- Brian Sutherland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.3 removed - open bugs
On Tue, Jan 09, 2007 at 09:40:10PM +0100, Martin Michlmayr wrote: python2.3 has been removed from unstable. Can someone please go through the list of open bugs and reassign those which still apply to python2.4 and close the rest. The current list of bugs is: snip 377329: normal: python2.3 -c 'int(buffer(__import__(array).array(c)))' segfaults 390152: normal: python2.3: logging module is broken I've confirmed these 2 with python2.4 and reassigned them -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#378604: dh_python generates dependencies on unversioned python versions for versioned python modules
On Tue, Jul 18, 2006 at 11:53:26AM +0200, Matthias Klose wrote:
Raphael Hertzog writes:
tag 378604 + patch
thanks
On Mon, 17 Jul 2006, Matthias Klose wrote:
Package: debhelper
Version: 5.0.37.3
Severity: important
Looking at python2.4-schoolbell, ${python:Depends} is expanded to
python-central (= 0.5), python ( 2.5), python (= 2.4) | python2.4
which is wrong.
It's not really wrong... but it's not really optimized for the purpose of
the package.
The package puts files in /usr/lib/python2.4/site-packages so it won't
work with python2.5 ... the python ( 2.5) guarantees that.
There's no script using #!/usr/bin/python2.4 otherwise you would have
had a dependency python2.4 ...
In theory, looking at the package it should have gotten a python (=
2.4), python ( 2.5) dependency however since that's not satisfiable in
sid right now, it has been loosened to the dependency above.
If modules are meant for public uses, they should work with all python
versions and in that case the dependency they get is the right one. But in
this case, we have public modules which are not really meant to be used by
the end-user and which are only used by one application and thus compiled
for the version that this application uses.
all the modules are for public use. however zope3 is only available
for python2.4 (and not above), so the same is needed for packages
depending on zope3. You have two hints that a dependency on a
unversioned python is unwanted:
- XS-Python-Version is explicitely set
- the package is named python2.4-xxx
FYI, in the schooltool packages for the next upstream release, the
package name will take the form python-xxx.
However the XS-Python-Version will continue to be set to a subset of the
python versions of the its dependencies (zope3 being the main culprit).
--
Brian Sutherland
Metropolis - it's the first movie with a robot. And she's a woman.
And she's EVIL!!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .egg in Debian summary?
On Fri, Mar 31, 2006 at 01:26:41AM -0300, Gustavo Noronha Silva wrote: It even uses python-support =D The code is on pkg-turbogears svn repo at alioth, and I'll upload it soonish, I hope. Comments? Being a Zope-ish hacker myself, I'm very glad to have helped the competition;) -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .egg in Debian summary?
On Mon, Mar 27, 2006 at 10:24:39PM +0200, Raphael Hertzog wrote: On Mon, 27 Mar 2006, Brian Sutherland wrote: [...] For what it's worth, I will be converting most of my packages that build with setuptools to use option 3. That is, of course, until there is some kind of consenus/decision. If you have done that, can you post your patch to the list ? I have never packaged Python related stuff yet, but I recently made a patch to update the kid package (#359012) and tried to look quickly what would be needed to achieve that but each time I ended with a .egg in the .deb ... So it would be great to have a example of how this ought to be done. I really have no idea how this ought to be done, but here's my way of doing it;) If it fries your hard disk, don't blame me. Also if anyone has any additions/corrections, let me know. For example upstream converted python-pullparser package to setuptools between 0.0.6 and 0.0.7. At the time we only had setuptools version 0.6a8-0.1, so I had to patch the setup.py to remove setuptools (which is similar to your kid patch): --- orig/setup.py +++ mod/setup.py @@ -73,10 +73,10 @@ #--- # the rest is constant for most of my released packages: +#import ez_setup +#ez_setup.use_setuptools() -import ez_setup -ez_setup.use_setuptools() +from distutils.core import setup -import setuptools if PACKAGE: packages, py_modules = [NAME], None @@ -85,7 +85,7 @@ doclines = __doc__.split(\n) +setup( -setuptools.setup( name = NAME, version = VERSION, license = LICENSE, Now that setuptools 0.6a9-1 I can remove that patch, and patch my rules and control as follows: % baz diff * looking for [EMAIL PROTECTED]/debian-python--python-pullparser--1.0--patch-6 to compare with * comparing to [EMAIL PROTECTED]/debian-python--python-pullparser--1.0--patch-6: .. done. * modified files --- orig/control +++ mod/control @@ -2,7 +2,7 @@ Section: python Priority: extra Maintainer: Brian Sutherland [EMAIL PROTECTED] -Build-Depends-Indep: debhelper (= 4.0.0), python-dev, python2.3-dev, python2.4-dev +Build-Depends-Indep: debhelper (= 4.0.0), python-dev, python2.3-dev, python2.4-dev, python2.3-setuptools (= 0.6a9-1), python2.4-setuptools (= 0.6a9-1) Standards-Version: 3.6.2.1 Package: python-pullparser --- orig/rules +++ mod/rules @@ -35,7 +35,7 @@ install -D --mode 644 ChangeLog python-$(PACKAGE)/usr/share/doc/python-$(PACKAGE)/changelog set -e;\ for ver in $(PYVERSIONS); do\ - $(PYTHON)$$ver setup.py install --no-compile --prefix=debian/python$$ver-$(PACKAGE)/usr;\ + $(PYTHON)$$ver setup.py install --no-compile --single-version-externally-managed --root=debian/python$$ver-$(PACKAGE);\ done .PHONY: binary-common The contents of the deb come out like this then: % dpkg-deb -c ../../python2.3-pullparser_0.0.7-1_all.deb drwxr-xr-x root/root 0 2006-03-28 12:38:15 ./ drwxr-xr-x root/root 0 2006-03-28 12:38:12 ./usr/ drwxr-xr-x root/root 0 2006-03-28 12:38:09 ./usr/lib/ drwxr-xr-x root/root 0 2006-03-28 12:38:09 ./usr/lib/python2.3/ drwxr-xr-x root/root 0 2006-03-28 12:38:10 ./usr/lib/python2.3/site-packages/ drwxr-xr-x root/root 0 2006-03-28 12:38:10 ./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/ -rw-r--r-- root/root 1537 2006-03-28 12:38:10 ./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/PKG-INFO -rw-r--r-- root/root 0 2006-03-28 12:38:10 ./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/zip-safe -rw-r--r-- root/root 231 2006-03-28 12:38:10 ./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/SOURCES.txt -rw-r--r-- root/root11 2006-03-28 12:38:10 ./usr/lib/python2.3/site-packages/pullparser-0.0.7-py2.3.egg-info/top_level.txt -rw-r--r-- root/root 12610 2006-01-01 22:44:41 ./usr/lib/python2.3/site-packages/pullparser.py drwxr-xr-x root/root 0 2006-03-28 12:38:12 ./usr/share/ drwxr-xr-x root/root 0 2006-03-28 12:38:12 ./usr/share/doc/ drwxr-xr-x root/root 0 2006-03-28 12:38:14 ./usr/share/doc/python2.3-pullparser/ -rw-r--r-- root/root 446 2005-11-09 17:38:47 ./usr/share/doc/python2.3-pullparser/copyright -rw-r--r-- root/root 410 2006-01-01 22:47:42 ./usr/share/doc/python2.3-pullparser/changelog.Debian.gz Have Fun. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: .egg in Debian summary?
On Sat, Mar 25, 2006 at 04:09:52PM +0100, Raphael Hertzog wrote: 3. Using Phillip's .egg-info solution http://permalink.gmane.org/gmane.comp.python.distutils.devel/2567 Well, since there's no progress, it's up to you as package maintainer to take the decision. The day when we have a real policy here, it will still be time to change things. My opinion is that we probably shouldn't distribute eggs but we must make it possible for our users to use them. So I think that the egg meta-info ought to be distributed either within a package directly (when the content of the egg matches the content of a single package) or as separate meta-packages depending on the various packages. From what I understood this is solution 3 above. For what it's worth, I will be converting most of my packages that build with setuptools to use option 3. That is, of course, until there is some kind of consenus/decision. -- Brian Sutherland Metropolis - it's the first movie with a robot. And she's a woman. And she's EVIL!! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python 2.4.1
On Wed, Apr 06, 2005 at 11:02:29AM +1000, Donovan Baarda wrote: On Tue, 2005-04-05 at 20:34 -0400, Colin J. Williams wrote: If you were asking when the default python package will be upgraded to version 2.4, I dunno... but probably not too long now 2.4.1 is released. Not too sure about this, but I think this transition is one of the things waiting for a sarge release. -- Brian Sutherland It's 10 minutes, 5 if you walk fast. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packaging for zope 3
Seems most of the discussion on zope 3 happens on this mailing list, so I'm putting my questions here. I'm currently packaging SchoolBell, what will be a calendering library for zope X3.1 as well as a calendaring server in its own right. Right now there are no zope X3.1 packages (nor even a zope X3.1:), so I am including a large portion of the current zope trunk checkout. (Very dirty hack) But it would be nice to get things right for the future. So: Is there anyone working on a zope X package that I could depend on for the needed modules? I have seen such a package in Ubuntu, but Debian is kind of lacking. The package naming scheme I am thinking of using is: schoolbell- Config and binaries for a schoolbell standalone server zope3.1-python2.3-schoolbell - The zope libraries themselves Comments? -- Brian Sutherland It's 10 minutes, 5 if you walk fast. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
