Python dependencies
A useful way to figure out the dependencies for packages that I just sorta-discovered: python -v (filename) < /dev/null 2>&1 | grep import This dumps out the filenames of the packages that are imported. A proper dependency checker (like the dh_perl that just went into debhelper) probably wouldn't be much harder. Perhaps I'll do something with it later... Caveat: non-console programs probably won't stop. Interactive ones might not stop either... Chris -- ===== | Chris Lawrence | Visit my home page! | |<[EMAIL PROTECTED]> | http://www.lordsutch.com/chris/ | | | | | Amiga A4000 604e/233Mhz | Your site belongs here. | | with Linux/APUS 2.2.8 | [Commercialize your sig today!] | =
Re: Policy for naming python packages
On Jun 09, Michael Sobolev wrote: > On Fri, Jun 09, 2000 at 11:16:13AM +0200, Jérôme Marant wrote: > > Do all Debian python packages have to be prefixed by 'python-' ? > > I recently packaged the "pyunit" software and I still don't > > know if I have to rename it python-unit or if I can keep its > > name as is. > > Looks like there is at least one package that does not follow this "policy": > reportbug. Hmm, zope also uses its own naming scheme... :) reportbug and zope can be used without doing any programming in Python; hence, I don't think naming them "python-X" makes any sense. It would be like calling the bug "sh-bug". The python-* nomenclature is intended for modules, not end-user applications. (For example, python-newt is a module because it doesn't do anything user-visible. reportbug is an end-user application because it provides binaries. reportbug does provide modules as well, but that's not the point of the package... the point is to produce a bug reporting tool, the modules are just there for reusability in case someone gets around to writing a GUI tool or people want to use the BTS interface code. Theoretically, those modules could be in a "python-debbugs" package, but IMHO that'd be a waste of resources.) Other python-using applications: - ppmtofb (has "fbview" script) - fetchmailconf - idle - vim-python - pydf Hopefully this clears that up. Chris (reportbug maintainer) -- = | Chris Lawrence| It's 2/3 of a beltway... | |<[EMAIL PROTECTED]> | http://www.lordsutch.com/tn385/ | | | | |Grad Student, Pol. Sci.|Are you tired of politics as usual?| | University of Mississippi | http://www.lp.org/| =
Re: Python license and GPL programs
On Jan 16, Peter Eckersley wrote: > IANAL either, > > but I did do some research into the matter, and you could add a caluse to the > GPL which says something like: > > "If this program is used with Python interpreter code whose license contains a > clause requiring legal disputes to be settled under the jurisdiction of the > State of Virginia, USA, and whose copyright is owned by the Corporation for > National Research Initiatives (CNRI) of Virginia, USA, then any legal action > pertinent to such code, and where such a clause is enforceable, may be > resolved > under the jurisdiction of the State of Virginia, USA." > > This should give away the absolute minimum of concessions to be compatible > with > the Python 1.6+ license. Get a lawyer to look at it before you use it! > Also, if you do get advice that it is okay, post so back here, so that I can > put it in my code ;) By this reasoning, for Python 2.0, you'd also have to add a BeOpen & California clause. And god knows what jurisdiction 2.1 will be under (I assume it will be owned by the PSF). I guess I'm still missing how saying "you will interpret this license under the laws of state X" has any effect on GPLed code. If it doesn't matter under which state's laws you interpret the GPL, the choice of state X doesn't matter; if it does matter, then the GPL is flawed and we have much more serious problems than license incompatibility. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics & Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
Re: Please wait before bloating Debian with python2- packages
On Jan 22, J?r?me Marant wrote: > I've recently seen some python2- modules being uploaded into Incoming. > It seems that people did not read our previous thread and prefer to > duplicate package for all Python interpreters. This is all non-sense. > > Please realize that this will bloat Debian an unconsistant way. > > Rob recently came up with an interesting proposal, inspired from > emacsen way of installing modules. I don't know if he had a deeper > look in it and if he started implementing something since then. > > Matthias, Gregor, what do you think of this? Thanks. > > Right now, I'm ready to help on implementing something but I don't > want that we duplicate our efforts. Rob, did you start something ? Unfortunately, this argument doesn't apply to binary modules, which are specific to the particular version of the interpreter (IIRC). That's why python2-pqueue is there. I suppose you could put both 1.5 and 2.0 modules in one package and depend on python-base (>= 1.5.2) | python2-base, but I really didn't think of that at the time... In any event, there are good technical reasons to keep both 1.5 and 2.0 for now that have nothing to do with the GPL issue. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Computer Systems Manager (Physics & Astronomy, 125 Lewis, 662-915-5765) Instructor, POL 101 (Political Science, 208 Deupree, 662-915-5949)
[EMAIL PROTECTED]: Bug#101165: reportbug fails to install]
Anyone have a clue what might cause this? I'm stumped.
Chris
--
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
--- Begin Message ---
Package: reportbug
Version: 1.17
Whenever I try to install reportbug I get the following:
Setting up reportbug (1.17) ...
/var/lib/dpkg/info/reportbug.postinst: line 34: 2810 Segmentation fault
python -O /usr/lib/python1.5/compileall.py -q $i
dpkg: error processing reportbug (--configure):
subprocess post-installation script returned error exit status 139
Linux d-ni 2.4.4 #1 Sat May 5 17:48:03 EST 2001 i686 unknown
a few package versions below:
ii dpkg 1.9.9 Package maintenance system for Debian
ii python-base1.5.2-16 An interactive object-oriented
scripting lan
ii python-newt0.50.17-7 A newt module for Python.
--
/"\ Joanne Rosemary Hunter
\ / ([EMAIL PROTECTED]) {http://menagerie.tf/~jrhunter}
X <--(ASCII Ribbon Campaign - No HTML Mail or postings!)
/ \ Of course I don't know how interesting any of this really is,
but now you've got it in your brain cells so you're stuck with it.
-Gary Larson
--- End Message ---
Re: Status report on python2 transition
stalled; of course, unless some magic API fix comes along, they would anyway. It also doesn't include any way to accomodate locally-built Pythons, unless they are built and installed as debs. This may or may not be a problem (some people may want to track CVS). I think this covers all of the important issues though. It may be needlessly complex, but it does support users having whatever Pythons they want installed and should allow most things to work. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
Re: Status report on python2 transition
On Jul 12, Bruce Sass wrote: > On 12 Jul 2001, Jérôme Marant wrote: > > Bruce Sass <[EMAIL PROTECTED]> writes: > > > > > Surely adopting a convention of... > > > > > > #!/usr/bin/env python[major.minor] > > > > > > ...is preferable. > > > > > > It does the same thing without additional runtime overhead and > > > without creating a class of Debian-specific Python programs. > > > > I object to this. It make scripts not portable to other systems as > > it currently does with current python 2.0 scripts in Debian. > > We shall end up with this trick as soon as possible. > > How not portable? > > Any build of Python I have done installs both: > > bin/python. > and > bin/python > > as hardlinks... > > ...calling "python-wrapper" to execute the program is definately not > portable to other systems. True... but it would only be done by Python scripts in Debian packages that depend on external modules. The problem with a hardcoded version in the #! path is that it locks the script into running with that version. Let me give you a "for instance": - I create a package that uses and depends on python-newt. Python-newt is only supplied for Python 1.5 at the moment, so I hardcode a call to /usr/bin/python1.5 - python-newt's maintainer releases a new python-newt that works with python 2.1, and drops python 1.5 support. - I install the new python-newt (and probably a lot of the python-2.1-*) - My package is now broken and I have to reupload it, even though all I need to change is the #!. With python-wrapper: - python-newt's maintainer does the right black magic with the python-wrapper business. - I create a package that uses and depends on python-newt. I call /usr/bin/python-wrapper. - python-newt's maintainer releases a new python-newt that works with python 2.1, and drops python 1.5 support. - I install the new python-newt (and probably a lot of the python-2.1-*) - My package still works fine, since python-wrapper knows that this version of python-newt needs python 2.1 to run. Now, two questions arise from all this: - Are we willing to have One and Only One Python in each stable release? If so, screw this python-wrapper business. It really doesn't solve any problems with locally-installed Pythons, except by making sure Debian packaged python programs don't use local pythons. But we will need to figure out some way to cleanly deal with not having python 1.5 in woody (a long Conflicts line looks likely). - If we aren't willing to do this, then we either live with a lot of messy dependencies that have to be updated every time a new x.y python comes out, or go with something like python-wrapper that leaves dealing with new Pythons mostly painless. The only other solution is to call "python-wrapper" /usr/bin/python, and make it fallback to calling a Python interpreter (defined by alternatives or whatever) if no suitable wrapper is found. That is completely portable, except in the case where /usr/bin/python is expected to be an ELF binary (does freeze need this?), but it adds overhead to every invocation. I have nothing invested one way or the other, mind you. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Instructor and Doctoral Student, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5949
Re: Bug#41113: Proposal: Naming Conventions for modules
On Jul 17, Stephane Bortzmeyer wrote: > On Friday 16 July 1999, at 13 h 21, the keyboard of Joey Hess > <[EMAIL PROTECTED]> wrote: > > And get a list of perl modules [1]. But I can't do that. I can with python > > modules though, which is very nice. > > Is there a formal policy for Python? I searched it and found > nothing. No; but, with < 5 people developing Python modules I suspect it's not much of a problem. Python's unofficial scheme is close to how Apache modules are named (libapache-mod-* vs. python-*). Maybe python-* should be mandatory. Ex: I have an ITP on Graphite and PIDDLE. python-graphite and python-piddle are reasonable names. libgraphite-python seems wrong (the upstream package isn't called "libgraphite" and it's certainly not a shared library in the C sense). Moving away from the existing convention for Python seems counter-productive. Chris -- ===== | Chris Lawrence | You have a computer. Do you have Linux? | | <[EMAIL PROTECTED]> | http://www.linux-m68k.org/index.html | || | | Amiga A4000 604e/233Mhz |Do you want your bank to snoop? | |with Linux/APUS 2.2.8 | http://www.defendyourprivacy.com/ | =
Re: RFC: New package "python"
On Jan 13, Gregor Hoffleit wrote:
> Ok, maybe we better go with task-python, although I still like the idea of a
> real python package--IMHO it's a little bit more intuitive than task-python,
> and if the name is still free, why shouldn't we use it.
I do think task-python(*) makes sense. But I think a "python" package
would just encourage people to make gratuitous overarching
dependencies ("my one liner requires python, and I can't be bothered
to see what modules it uses, so I'll just depend on python"). We
ought to be more fine-grained when looking at dependencies from a
maintainer standpoint, and "python" is not much of a win over
"task-python" from the user's standpoint.
On a rambling note:
It seems to me that we ought to pursue something like "python-core" vs
"python", like Perl has done: a core "python-core" package with the
essentials (interpreter, required services as defined by the library
reference), and a "python" package that is the rest of python-base.
Of course, I don't know what the size differential would be, or even
if you could program anything worthwhile with "python-core" alone.
Somehow I doubt it... perl-core (or -base or whatever) is more driven
by "what do we need for all the perl scripts in base to work" rather
than any rational plan from an upstream standpoint. I doubt anything
I've written for Debian could work with any reasonable "python-core"
alone.
Chris
--
=
| Chris Lawrence| Get rid of Roger Wicker this year!|
|<[EMAIL PROTECTED]> | http://www.lordsutch.com/ms-one/ |
| | |
|Grad Student, Pol. Sci.|Are you tired of politics as usual?|
| University of Mississippi | http://www.lp.org/|
=
Re: Python upgrade path (draft/proposal)
On Oct 17, Matthias Klose wrote:
> With the last python-1.5.2-18.2 NMU we have non-conflicting python1.5,
> 2.0 and 2.1 packages in unstable, not more not less.
>
> Here two proposals, how to go further on. The first proposal is a
> safer proposal (but needs more uploads and needs loong). The second
> proposal accepts some breakage during the upgrade, but is a bit
> shorter.
[...]
>Each package maintainer should decide, if he only supports the
>default python version, or more than one version (the policy
>should make this clear).
>
>a) support the default version only: Name your package
> python-XXX (for a library). Make your package depend on
> python-base (>= 2.1), python-base (<< 2.2).
>
>b) support more than one python version: Make packages
> python1.5-XXX and python2.1-XXX and a package python-XXX.
> The python1.5-XXX and python2.1-XXX packages should depend
> on python1.5-base and python2.1-base, the python-XXX
> package should depend on of of the python1.5-XXX or
> python2.1-XXX packages.
>
>If maintainer A (maintaining python-FOO (depending on
>python-base (>= 2.1), python-base (<< 2.2)) decides for (a),
>then a maintainer B should be allowed to repackage
>python1.5-FOO, if "his" package cannot be converted to
>use the default python version.
May I suggest a simpler alternative for (b) (or maybe an alternative "c"):
Make package python-XXX containing support for both python 1.5 and
python 2.1. For each python {1.5,2.1} that is installed, bytecompile
the package's .py files on install. Since we use
/usr/lib/pythonx.y/site-packages, it won't hurt anything if the
"other" version is not installed. If the files are identical, they
should only appear in the package once (use hard links or symlinks,
but don't symlink directories because of .py[co]). Depend on
python-base (>= 1.5.2-1) and nothing should break. Build-depend on
both python1.5-base and python2.1-base.
Since the buildds need both versions installed to make
python{2.1,1.5}-X anyway, this approach doesn't cause them any extra
problems.
The only downside is that people with one installed python will get
extra cruft installed, but the use of links should minimize it. I'd
follow this alternative unless the package consists entirely of .so
files and the .so files are *big*.
I can build a new python-pqueue as an example if anyone wants to see
how this might work in practice...
Chris
--
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
Instructor and Doctoral Student, Political Science, Univ. of Mississippi
208 Deupree Hall - 662-915-5765
Re: Python upgrade path (draft/proposal)
On Oct 18, Matthias Klose wrote:
>
> > May I suggest a simpler alternative for (b) (or maybe an alternative "c"):
> >
> > Make package python-XXX containing support for both python 1.5 and
> > python 2.1. For each python {1.5,2.1} that is installed, bytecompile
> > the package's .py files on install. Since we use
> > /usr/lib/pythonx.y/site-packages, it won't hurt anything if the
> > "other" version is not installed. If the files are identical, they
> > should only appear in the package once (use hard links or symlinks,
> > but don't symlink directories because of .py[co]). Depend on
> > python-base (>= 1.5.2-1) and nothing should break. Build-depend on
> > both python1.5-base and python2.1-base.
>
> Depend on python-base (>= 1.5.2-1), python-base (<< 2.2), or do you
> _know_ the future ;-? You have to make a new upload, but it's an
> acknowledgement by the package that he actually tested the package
> with the new version.
I typo'ed here. I meant python1.5-base | python2.1-base.
> > Since the buildds need both versions installed to make
> > python{2.1,1.5}-X anyway, this approach doesn't cause them any extra
> > problems.
> >
> > The only downside is that people with one installed python will get
> > extra cruft installed, but the use of links should minimize it. I'd
> > follow this alternative unless the package consists entirely of .so
> > files and the .so files are *big*.
> >
>
> Is it really simpler?
>
> - from the user's point of view, you have to install packages you
> don't want.
Well, you have to install *files* you don't want, but you don't need
all of the pythonX.Y-base packages, just the particular version you
want to use. The point is that the user doesn't have to care which
Python he has installed to figure out which extension to use; it "just
works."
> - from the package maintainer's point of view,
>
> * you have to make new uploads every time a new python is installed/
> adjust your packaging rules.
Well, you have to do that anyway, regardless.
> * you have to make sure your symlink system works for every single
> package. I would prefer a system, availabe in python-base, but
> then each package would have to pre-depend on python-base.
I haven't tested it with a package that installs .py files. I may try
to do it with reportbug this weekend and share my results.
> * it's limited to arch independent packages. python1.5 and python2.1
> have different ABIs. I didn't look at 2.1 and 2.2 compatibility.
No, arch dependent packages can have separate so files for each major
version of Python; see python-pqueue 0.2-3 for an example. It's
actually easier with arch dependent packages because you're not
duplicating files.
i.e. there is:
/usr/lib/python1.5/site-packages/pqueuemodule.so
/usr/lib/python2.1/site-packages/pqueuemodule.so
two modules, compiled against the appropriate pythonX.Y-dev packages.
The beauty of it is that if you don't have one version installed, it
doesn't matter, except for the disk space you're using. (Hence why I
said not to use it for big .so files, where big is probably >= 100k or
so.)
> Anthony Towns describe a "register/unregister" system in
> http://lists.debian.org/debian-python/2001/debian-python-200110/msg00066.html
> Do you want to give it a try?
That much overhead may not be necessary; really, all you need to do in
your postinst is (in Python... adjust to sh as you see fit):
for version in glob.glob('/usr/bin/python?.?'):
sys.system(version+' compileall.py
/usr/lib/'+version+'/site-packages/my-package')
sys.system(version+' -O compileall.py
/usr/lib/'+version+'/site-packages/my-package')
Seems short, simple, and to the point. The only downside is you won't
automatically get new .pyc and .pyo files every time you install a new
major version (in which case it might be nicer to go with something
like a register/unregister system... YMMV).
Chris
--
Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/w
Re: Final draft of Python Policy (hopefully ;-)
On Oct 27, Gregor Hoffleit wrote: > I've put a version 0.3.6 of the Python Policy Draft on > http://people.debian.org/~flight/python/. The version is still a little > bit rough and sometimes incomplete, but it already gives a good outline > of the Python packaging system we are installing just now. > > Please have a look at the document, and post all fundamental problems > you have with the content. > > If nobody find fundamental show-stoppers that render this unusable, > we're going to submit it to Debian Policy very soon. My main concern is that the policy seems to force the installation of the default version to use anything in the distribution that uses python... a few comments, focusing on section 2: - If a package works with any version of Python in the archive, is there a setup that allows users to choose which version of Python they want to have installed? Or are they stuck with the default version? - If not, how is /usr/bin/python going to be handled? We threw out using an alternative for it, but that was when we were still calling the default version "python-base". If the default version isn't installed, presumably /usr/bin/python doesn't exist under the current setup. What do you use for a #! then? - Why is the following statement in the policy (2.1.1)? "You should not make a default, unversioned module package python-foo depend on the versioned Python package pythonX.Y!" 'Depends: pythonX.Y' appears to be synonymous to 'Depends: python (>= X.Y), python (<< X.Y+1)'. Is this some sort of newbie-friendliness we're going for? If so, why? The only "good reason" I can think of is to have a parallel between the python-foo/python and pythonM.N-foo/pythonM.N names. But since that's rather user-invisible (it's a dependency), I don't quite see the point. - Should 2.1.1 require python-foo to provide pythonX.Y-foo? - Again in 2.1.1: Should any new python-foo conflict with python-base (<= 1.5.2-18.4) so python-base has to be upgraded for python-foo to be upgraded too? (Could this get rid of the whole conficts problem in python core?) - Would it be cleaner to make all pythonX.Y-foo provide python-foo, so any version-independent package that needs foo can depend on python-foo? If we did this (and got rid of the Depends funkiness) we could throw out 2.1.1 completely, as it would be a special case of 2.1.2. - 2.1.2.2, or some other part of the policy, should explicitly prohibit the use of /usr/lib/site-python, as it is deprecated upstream. - I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good name... maybe /usr/share/python/site-packages instead. (After all, the things should be arch independent.) I'd be happy to code up the symlink thingamajig for 2.1.2.2 if nobody's working on it. - Perhaps instead of a dependency on python (<= X.Y+1), 2.1.2.2 should say packages should confict with python (>> X.Y+1), unless we want to force everyone to have the default version installed. - Maybe the rationale should be at the beginning of section 2... it would make the rest of the section more understandable. - (editorial nit) There seems to be a superfluous < in the rationale. Anyway, feel free to rip away... Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
Re: what to do about python-kjbuckets
On Nov 04, Matthias Klose wrote: > Donovan Baarda writes: > > On Sun, Nov 04, 2001 at 05:23:30PM +0100, Joel Rosdahl wrote: > > [...] > > > But there is a problem: The current (from 1997) upstream version[1] > > > doesn't work with Python >= 2.0. Now, Berthold Hoellmann, Oleg > > > Broytmann and others have ported[2] kjbuckets to work with newer > > > Pythons, but it's not as official as one could hope. For instance, > > > the version number is still the same as the old upstream version > > > (2.2). > > > > > > I'm not sure what to do. Here's a couple of solutions: > > [...] > > > 2) Only make a python1.5-kjbuckets package. (Nah.) > > [...] > > > 5) Use date in version, i.e. 2.2.port.20011104 or similar. (Best > > >solution I can come up with.) > > [...] > > > > I would hope that you also make a python1.5-kjbuckets so that older > > python1.5 programs that used it can still use it. You them also make a > > python2.2-kjbuckets (2.2.0-port.20011104) package if you want something > > newer. > > do we really need 1.5 support? gadfly was just orphaned, someone would > have to look at routeplanner. Can these packages use 2.1? routeplanner runs under Python 2.1 with no modifications, and works with the "unofficial" kjbuckets. I'm mainly waiting on python-gnome to get updated... It will run without kjbuckets at all, but there's about a 15% performance penalty under Python 1.5. Dunno about 2.x... Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
Re: Removal of python1.5?
On Dec 10, Matthias Klose wrote: > Donovan Baarda writes: > > On Mon, Dec 10, 2001 at 11:53:24AM +1000, Anthony Towns wrote: > > > On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote: > > > > If I don't hear a serious reason to keep python1.5, I plan to file a > > > > bug report for ftp.debian.org to remove the python1.5 package. > > > > > > Eh? > > > > > > python1.5's still useful to users, isn't it, especially ones with > > > important python programs they don't want to port to 2.1 just yet? > > > > > > Dropping python1.5 doesn't seem a particularly clever thing to do. > > > > I agree. Old versions can also be useful when testing backwards > > compatability of scripts etc. > > hmm, yes, this argument holds for all versions of all packages ... > > > Now that the python policy supports multiple versions and a default version, > > having old versions around doesn't hurt. Why not just leave them there? > > Removing them buys nothing but a little archive space. > > well, but the policy shouldn't be used to rectify a Debian python > museum. IMHO keeping Python 1.5 around for woody doesn't hurt anything. People could still have legacy scripts that need Python 1.5 that aren't accounted for by Debian packages, for example. Also, the 1.5 packages in potato are incompatible with the current Python packaging; if someone needs 1.5 on a woody box, and we drop it from woody, they'd have to build from source and debianize it themselves or install into /usr/local. Now, after woody is released, I can't see any good reason to keep 1.5 around for woody+1. But for now let's keep it around. (If you or Gregor don't want to maintain it, someone else would probably volunteer.) Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
python-gnome: float weirdness with gnome.ui is back
reassign 119951 python-gnome, routeplanner-gnome retitle 119951 python-gnome: float() works incorrectly after import gnome.ui thanks On Nov 17, Sebastian Rittau wrote: > Package: routeplanner-gnome > Version: 0.12 > Severity: important > > After starting the Gnome routeplanner frontend and trying to open > /usr/share/routeplanner/Basic-USA.rpl3.gz I get the following stack > trace on the console: > > [EMAIL PROTECTED]:~$ grplan > Traceback (most recent call last): [...] > File "/usr/share/routeplanner/rpcity.py", line 36, in __init__ > self.longitude = float(data[2]) > ValueError: invalid literal for float(): 0.000 > > The "Loading Cities" requester then hangs a 0%. I've done some more tracking. Here's the interesting result: $ [EMAIL PROTECTED] rpcli NorthAmerica.rpl3 * This works $ [EMAIL PROTECTED] grplan NorthAmerica.rpl3 * This doesn't work The reason: "from gnome.ui import *" does something nasty to the locale settings that stops float() from working. Python's float builtin (like int) is supposed to work in the C locale all of the time; even if you do locale.setlocale(LC_ALL, "") in a program, the only things that are affected are in the locale module itself. Even doing "import gnome.ui" triggers the bug. I don't know what exactly is going on, but it's probably something in python-gnome. I'm passing this along to its maintainer. (Torsten: I suspect the fix for #59713 got rolled back somewhere along the line, or something similar is going on elsewhere in the code.) Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765
Re: Python and Emacs
On May 21, Jérôme Marant wrote: > I'm sorry, this may be a bit off topic but I don't really know > where I can post this question. > > I'm a bit annoyed with Emacs when editing Python programs because > Emacs always replaces TABs with spaces ; this wouldn't bother me if > Emacs was the only editor in the world. But when you share programs > with others, it is better to have real TABs instead of spaces. > I know about the "C-q TAB" but I don't want to use it every time > I want automatic indentation. > > Does anyone know how to achieve this? When you're done editing... C-x h M-x tabify Of course, we all know that using tabs in Python code is Evil. :-) Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Packaging, supporting both 2.1 and 2.2
On May 22, Moshe Zadka wrote: > Doesn't work. > What if the user installed python2.2-foo but /usr/bin/python > is /usr/bin/python2.1, or vice versa? > If this is what python-central does, then python-central, I'm afraid, > has a bug... Under Debian's Python policy, /usr/bin/python is guaranteed to be Python 2.1 for woody. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#148415: jack: should use #!/usr/bin/python
On Jun 23, Michael Banck wrote: > Hi, > > On Tue, May 28, 2002 at 05:22:32PM -0500, Chris Lawrence wrote: > > Some users may have a local version of Python installed (like Python > > >from CVS), so jack should use the path to the default Debian version > > of Python rather than using /usr/bin/env. > > As Python-policy says: > > 1.3.2. Interpreter Location > > The preferred specification for the Python interpreter is > `/usr/bin/python' or `/usr/bin/python.'. > > If a maintainer would like to provide the user with the possibility > to override the Debian Python interpreter, he may want to use > `/usr/bin/env python' or `/usr/bin/env pythonX.Y'. > > I'll close this bug, OK? Not OK, since the locally-installed Python may not/will not have access to jack's site-python files. Using /usr/bin/env python is IMHO only acceptable if the package is self-contained or munges sys.path to include any non-standard modules in the search path. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.2 for sarge?
On Jul 25, Matthias Klose wrote: > My current plan is: > > - upload python2.3 packages soon (when 2.3alpha1 is released) > > - remove python1.5 from unstable > > - adopt python-central for 2.1, 2.2 and 2.3, hopefully with the > help of the author, hint, hint > > - upload python2.3 beta to unstable > > - make it the python default > > - remove python2.1 from unstable > > I don't see much sense in making the switch to 2.2 now and then again > to 2.3. But anyway, let's make unstable really unstable first by > switching to gcc-3.2 as the default compiler (coming soon :-) I don't think python2.1 should be dropped until sarge+1; keeping around the previous default Python in the next release is probably a good idea as general policy. I also wouldn't bother switching to 2.2 as the default if 2.3 is going to be the default by December. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Instructor and Ph.D. Candidate, Political Science, Univ. of Mississippi 208 Deupree Hall - 662-915-5765 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: standard Python build for Debian distributions
On Aug 14, Damon Fasching wrote: > Are there any plans to include packages like distutils in the > standard Debian distribution? distutils is in the python-dev package; there are other python-* packages with various other components of the "batteries included" Python distribution. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
Re: Maintaining Python 1.5
On Sep 10, Matthias Klose wrote: > Moshe Zadka writes: > > I was wondering if you mind passing Python 1.5 maintainership to me. > > I do not mind passing the maintainership, but I do mind keeping it in > unstable. Debian is not a museum for old python versions. What hinders > you to install the python1.5 packages from woody in unstable? apt > tagging is your friend. Well, two problems I can see: 1. Woody will eventually go away to archive.debian.org land, not long after sarge is released. 2. There are woody Python packages that want libdb1, which disappears from libc6 in sid/sarge. I agree we shouldn't keep it around forever, but it seems like as long as people are using python1.5 with post-woody we should keep it. Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765
[rene@debian.org: Bug#165356: reportbug creates "snow" mail text]
For the third time, *I THOUGHT PYTHON 2.2 WAS FEATURE-FROZEN*. This email module crap is ridiculous... Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/ Computer Systems Manager, Physics and Astronomy, Univ. of Mississippi 125B Lewis Hall - 662-915-5765 --- Begin Message --- Package: reportbug Version: 2.5 Severity: grave Justfication: renders package unusable Hi, I just wanted to file a bug report using reportbug: [EMAIL PROTECTED]:~$ reportbug libc6 Using '"Rene Engelhard" <[EMAIL PROTECTED]>' as your from address. Getting status for libc6... Verifying package integrity... Checking for newer versions at packages.debian.org... Your version (2.2.5-15) of libc6 appears to be out of date. The following newer release(s) are available in the Debian archive: unstable: 2.3.1-1 Do you still want to file a report [y|N|?]? y Will send report to Debian. Querying Debian bug tracking system for reports on src:libc6 (Use ? for help at prompts.) [...] Maintainer for libc6 is 'GNU Libc Maintainers '. Getting dependency information for libc6... Please briefly describe your problem (you can elaborate in a moment; an empty response will stop reportbug). > libc6 2.3.1-1 breaks fetchmail/exim (and others?) [...] Please select a severity level: [normal] critical [...] Please select tags: [none] sid [...] This results in a message as follows in mutt: ---snip--- From: Rene Engelhard <[EMAIL PROTECTED]> To: Debian Bug Tracking System <[EMAIL PROTECTED]> Cc: Bcc: Rene Engelhard <[EMAIL PROTECTED]> Subject: libc6 2.3.1-1 breaks fetchmail/exim (and others?) Reply-To: X-Reportbug-Version: 2.5 X-Operating-System: Debian GNU/Linux X-GnuPG-Key: $ finger [EMAIL PROTECTED] UGFja2FnZTogbGliYzYKVmVyc2lvbjogMi4yLjUtMTUKU2V2ZXJpdHk6IGNyaXRpY2FsClRhZ3M6 IHNpZAoKCgotLSBTeXN0ZW0gSW5mb3JtYXRpb246CkRlYmlhbiBSZWxlYXNlOiB0ZXN0aW5nL3Vu c3RhYmxlCkFyY2hpdGVjdHVyZTogaTM4NgpLZXJuZWw6IExpbnV4IHN0YW4gMi40LjE4ICMyIE1v biBKdW4gMTcgMDM6Mzg6MDkgQ0VTVCAyMDAyIGk2ODYKTG9jYWxlOiBMQU5HPWRlX0RFQGV1cm8s IExDX0NUWVBFPWRlX0RFQGV1cm8KClZlcnNpb25zIG9mIHBhY2thZ2VzIGxpYmM2IGRlcGVuZHMg b246CmlpICBsaWJkYjEtY29tcGF0ICAgICAgICAgICAgICAgICAyLjEuMy02ICAgIFRoZSBCZXJr ZWxleSBkYXRhYmFzZSByb3V0aW5lcyBbZ2wKCi0tIG5vIGRlYmNvbmYgaW5mb3JtYXRpb24KCg== ---snip--- (signature snipped) I tried with another package, another severity, with or with no tags - always the same thing (although the "snow" is different) Regards, Rene -- .''`. Rene Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 --- End Message ---
Re: Move to python 2.2 as default release?
On Aug 14, Laura Creighton wrote: > The new Python Business Forum (www.python-in-business.com) is > collaborating with the Python developers to produce Python-in-a-Tie, > a business-targetted release of Python. This is a 'Sumo-Release', > which will include other useful Python libraries and programs which > are not part of the standard Python releases. What we want is a release we > tell our cyustomers to run which will give them 18 months or so > during which there is no need for them, as users, not developers, to > upgrade a to a newer version of Python. Then we will target a next > release, and to be the next Python-in-a-Tie. I am the Chairman of > the Python-in-a-Tie SIG, and the Python-in-a-Tie release is going > to be based on 2.2, not 2.1 or 2.3. Thus 2.2 is the release which > we are telling Python developers is the release which they should > write for. Therefore I think that skipping the 2.2 release in > favour of the 2.3 would be a mistake. > > Please cc any discussion and replies to me since I do not read > debian-devel. Thanks very much, Laura: (and Guido et al.) Debian plans to support at least Python 2.2 and 2.3 in the next release (sarge); unlike other distributors, we do not have a problem with making multiple Python versions available so long as they are useful. If you need to target a specific release of Python (i.e. 2.2), you should use #!/usr/bin/env python2.2. However, the *default* Python shipped by Debian (i.e. /usr/bin/python) affects things within our distribution, and there may be wins for us basing on 2.3 rather than 2.2 (the "enumerate" builtin being an obvious, immediate example; universal newline support may also be important). Now, if 2.3 won't be stable until well into next year (as opposed to the schedule in PEP 283), then we may want to target 2.2.x as our default version. This is something that largely depends on our anticipated release schedule - which is not very calendar driven, but "Q2 2003" is less likely to make sarge than "Q4 2002". (Note that debian-python is probably the most appropriate list for followups.) Chris -- Chris Lawrence <[EMAIL PROTECTED]> - http://www.lordsutch.com/chris/
