ant to
> force everyone to have the default version installed.
2.1.3.2? Not (>= X.Y+1)? Where is the difference. In both cases you
specify, that your package doesn't work with the next upstream
version.
> - Maybe the rationale should be at the beginning of section 2... it
> would make the rest of the section more understandable.
agreed. Hope you get the section number right after the change ;-)
> - (editorial nit) There seems to be a superfluous < in the rationale.
Corrected.
> Anyway, feel free to rip away...
Not at all. Thanks for the feedback.
Matthias
Joel Rosdahl writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> > It let's a package depend on:
> >
> >python (>= 2.1), python (<< 2.2), python-foo
> >
> > and can expect a working default Python version, which has support for
&
Chris Lawrence writes:
> - 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.
Jérôme Marant writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> > > 2.1.1 Support Only The Default Version
> > >
> > > + does this "Depends: python (>= X.Y), python (<< X.Y+1)" really
> > > work since versioned pr
e
packages to incoming together with the new Python packages.
We hope to make a smooth upgrade from 1.5 to 2.1 and provide a current
Python version with bells, whistles and packages for woody.
Matthias Klose (and Gregor Hoffleit).
Carey Evans writes:
> >From Appendix B.2:
>
> > The new packages will conflict with every Python dependent
> > package, that does depend on `python', `python-base', without
> > depending on `python (<< 1.6)' or `python-base (<< 2.1)'.
>
> Since the new packages conflict wi
Jérôme Marant writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
> > > But I don't want all my python packages to be uninstalled because
> > > python changed. This is unacceptable.
> >
> > So you simply set the new python packages on hold, u
et them
> > here:
> >
> > deb http://joel.rosdahl.net/debian/ ./
> > deb-src http://joel.rosdahl.net/debian/ ./
looks ok. Would it make sense to add a 'Replaces:' line for those
packages without the '-egenix' part? I.E:
Package: python-egenix-mxdatetime
Replaces: python-mxdatetime
Could you copy these packages to ftp-master.debian.org in
~doko/www/python-uploads?
Thanks, Matthias
Mikael Hedin writes:
> Hi, I'm just finishing my new plucker package. And then I read the
> policy again, and it said I should call my program python2.1-plucker,
> as I use method 2 and the upstream name is plucker.
Is plucker an application or a library (probably both ...)
> But this is not
ted to wait
with the bug reports, until all "basic" python libraries have
converted to python2.1.
Matthias
Joel Rosdahl writes:
> 5) Use date in version, i.e. 2.2.port.20011104 or similar. (Best
>solution I can come up with.)
but use something like 2.2.0.port.011104, so you don't need an epoch
for the next official 2.2.1 version.
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?
Matthias
gt; that lead to a big bang with all the dependencies. Old
> libraries have disappeared and new ones won't install.
>
> Could someone of you gently tell us what's the best bet from
> the user point of view ?
As a user, stay away from unstable the next week (or maybe the next
two weeks) and come back, when the conversion is done.
Matthias
ev (Closes: #19009)
>
> -- Dirk Eddelbuettel <[EMAIL PROTECTED]> Sat, 10 Nov 2001 20:18:38 -0600
I didn't look at the new source, but build-depending on python2.1-dev
means that you have to call python2.1 during the build. `python' may
point to something else, if we change the python version to 2.2. So
either build-depend on python (>= 2.1), python (<< 2.2) or use
`python2.1'.
Matthias
It looks like the move to python (v2.1) is done. There are three
packages remaining:
- pydb: http://bugs.debian.org/119203
Not yet ported to 2.1, but we do have an alterbate debugger
available (idle).
- python-pam: http://bugs.debian.org/119213
See http://ftp-master.debian.org/~doko/py
dman writes:
> On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
> | It looks like the move to python (v2.1) is done. There are three
> | packages remaining:
>
> Also gadfly depends on 1.5. Unfortunately it appears stagnant
> upstream (last release in '98)
Mikhail Sobolev writes:
> On Sun, Dec 09, 2001 at 08:00:20PM +0100, Matthias Klose wrote:
> > - python-pam: http://bugs.debian.org/119213
> >See http://ftp-master.debian.org/~doko/python for a try.
> >However I couldn't get it reliably working ...
>
> Co
Anthony Towns writes:
> 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
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
Kim Oldfield writes:
> On 10 Dec 2001, Matthias Klose typed:
> ] Anthony Towns writes:
> ] > Dropping python1.5 doesn't seem a particularly clever thing to do.
> ] If we don't have any python1.5 dependencies, why not?
>
> Because users will have no way of havi
hmm, then we have to keep zope 2.1 as well (the version from
potato). Why do you want to keep 2.3, not 2.2? Why not 2.5? IMO If you
have a mission critical application, which is incompatible among zope
versions, then you should install your own zope. Am I wrong here?
Jim Penny writes:
> I have a z
ere are many packages
that won't retain source compatibility to 2.0.
I fear when woody is released we'll have a stable outdated python
version for which it becomes difficult to build newer third party
packages ...
Matthias
> We have to discuss the policy of dependencies and paths for the Python
> packages at some point.
and don't forget the Debian python policy ...
.0. I hope that these packages will find its
way to the woody dist and allow the upload of python-2.1 dependent
packages to woody. I will do this upload next weekend.
Matthias
ok, I'm giving up, just wanted to finish the python transition. please
could somebody look at #128349?
Torsten Landschoff writes:
> On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote:
> > I have untested scripts python.postinst and python.prerm for this.
>
> If you ask me, scripts for that should go into the python package so
> that not every python-xxx package has to carry them its
Matt Zimmerman writes:
> On Sun, Jan 13, 2002 at 10:00:23PM +0100, Matthias Klose wrote:
>
> > - wajig uses /usr/bin/python as interpreter and therefore should
> > depend on "python (>= 2.1), python (<< 2.2)". Same for the build
> > dependency.
Donovan Baarda writes:
> G'day,
>
> just thought I'd have another look at the current policy and I couldn't find
> it. Where is it again?
/usr/share/doc/python, anybody actually reading the docs?
> Can we get a link to it put on the Debian devel page?
>
> http://www.debian.org/devel/
IMO that
reopen 128531
thanks
> From: [EMAIL PROTECTED] (Adam D. McKenna)
> Changes:
> tmda (0.46-1) unstable; urgency=low
> .
>* New upstream release
>* Package split into 3 packages to help attempt to conform to Debian's
> braindead Python policy. New packages are:
>python-tmda (
Adam McKenna writes:
> On Wed, Feb 20, 2002 at 12:55:59AM +0100, Matthias Klose wrote:
> > reopen 128531
> > thanks
> >
> > > From: [EMAIL PROTECTED] (Adam D. McKenna)
> > > Changes:
> > > tmda (0.46-1) unstable; urgency=low
> > > .
>
Jérôme Marant writes:
> "Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
>
> > we SHOULD be able to fix this ourselves, I just do not know enough about
> > distutils yet to tackle it.
>
> I asked about this on the 4suite mailing list because I don't really
> know what can be done with distut
Sean 'Shaleh' Perry writes:
> >>
> >> apt-cache showpkg doesn't show any reverse dependencies for 4suite, so
> >> an upload might be safe ...
> >
> > Well, some api changed. It might not be reasonnable ...
> >
>
> consider people using it as a depends for software not in Debian.
with this arg
Bastian Kleineidam writes:
> On Sun, Apr 28, 2002 at 04:30:49PM -0500, dman wrote:
> >
> > I did a google search and a search using the engine on debian.org but
> > I can't find the Official Python Policy document anywhere. I did find
> > Neil's draft version 0.1 proposal with no trouble, but I'm
Moshe Zadka writes:
> On Wed, 22 May 2002, Bastian Kleineidam <[EMAIL PROTECTED]> wrote:
>
> > On Wed, May 22, 2002 at 12:09:11PM -, Moshe Zadka wrote:
> > > > a) python2.1-foo: python foo.py module for 2.1
> > Depends: python2.1
> >
> > > > b) python2.2-foo: python foo.py module for 2.2
> >
Florent Rougon writes:
> Luca - De Whiskey's - De Vitis <[EMAIL PROTECTED]> wrote:
>
> > I'm not sure of the usefulness of this approach.
> > Even if python is one of my favorite language, it's still too young compared
> > wit perl and it's staility. python is still evolving, and we have not,
>
[forwarding to debian-python]
using distutils out of the box seems to be difficult, because many
upstream packages are broken down in several binary packages and
because distutils out of the box only builds for one python
version. Not sure which package to look at for a start ...
Tom Hall writes:
Florent Rougon writes:
> 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
reopen 148415
thanks
Chris Lawrence writes:
> 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 Deb
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 a
orted
upstream please.
Matthias
Jérôme Marant writes:
> Bastian Kleineidam <[EMAIL PROTECTED]> writes:
>
> > Missing depends on libstdc++4:
> >
> > Setting up python2.3 (2.2.90-1) ...
> > /usr/bin/python2.3: error while loading shared libraries:
> > libstdc++.so.4: cannot open shared object file: No such file or directory
>
>
Jérôme Marant writes:
> BTW, why is libstdc++ suddenly required? Are there some bits of C++
> in the upcoming release of python?
the main program Modules/ccpython.cc is compiled with g++-3.1. No
other dependencies. hmm, I am sure, there was a bug report filed to
link against libstdc++...
Package: ftp.debian.org
Please remove the python1.5 source package and all depending binary
packages from unstable. Users needing python1.5 can still download
these packages from woody.
Package maintainers building library packages depending on python1.5
should remove the 1.5 specific binary pack
Donovan Baarda writes:
> On Fri, Aug 23, 2002 at 06:35:02PM +0200, Martin Sj?gren wrote:
> > fre 2002-08-23 klockan 18.28 skrev Jim Penny:
> > > What packages do you have in mind? Some of the c-extension maintainers,
> > > myself included, have an informal policy of "support everything in the
> >
ilman make profit from python-central?
They don't install into /usr/lib/python/site-packages, but
their python files need to be recompiled on a python version
change.
Hope you can implement this missing bits for 0.x ;-)
Matthias
Donovan Baarda writes:
> On Sat, Aug 24, 2002 at 07:48:31PM +0200, Matthias Klose wrote:
> > Some comments:
> >
> > - python-central should have a configuration option, how files are
> > compiled. Most users don't need compilation with -O. Maybe
> > a deb
Bastian Kleineidam writes:
> On Sat, Aug 24, 2002 at 07:48:31PM +0200, Matthias Klose wrote:
> > Some comments:
> >
> > - python-central should have a configuration option, how files are
> > compiled. Most users don't need compilation with -O.
> I will have c
ime.
Matthias
I'm preparing a NMU for python-happydoc for tonight. qm fails to
build, because python-happydoc isn't installable anymore.
Graham Wilson writes:
> On Sun, Sep 01, 2002 at 09:08:36AM +0200, Tollef Fog Heen wrote:
> > Until dpkg supports triggers, I think what the emacsen does it the
> > most sane -- I'd be really, really happy if python modules/apps were
>
> what do the emacsen do?
Don't know, maybe Tollef can explain
apt
tagging is your friend.
Matthias
PS: You have to ask Gregor to hand over maintainership.
Neil Schemenauer writes:
> 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.
>
> I
2.3 version as well (if you already build python2.1-foo and
python2.2-foo packages).
For packages not beeing converted, I will file bug reports next week.
Matthias
Hugo van der Merwe writes:
> > I was just about to post a big explanation...again, when I saw you had
> > figured it out :-)
> >
> > Does anyone think the Python policy need a bit more explanation here? would
> > some "use-cases" help?
>
> I think that would be a good idea, probably. To try to av
Bastian Kleineidam writes:
> python-central (0.4) unstable; urgency=low
>
> * renamed register-python-package to python-register, this way
> its prefixed with "python" (and its shorter ;)
as long as python-central handles libraries/modules only, it should be
called register-python-library. Don't confuse the packager ;-)
Matthias, away 'til Sunday.
=?iso-8859-15?B?Suly9G1l?= Marant writes:
> On Thu, Oct 03, 2002 at 05:36:22PM +0200, Matthias Klose wrote:
>
> Hi,
>
> > There are still about 20 packages not installable in sid due to the
> > change of the default python version. Asking for NMUs now, probably
> &
severity 163703 wishlist
thanks
Itamar Shtull-Trauring writes:
> Package: python-doc
> Version: 2.1.3-4
> Severity: important
> A large part of the python docs regarding new features (and this
> especially true for 2.2) are only in PEPs (and for 2.2). The "What's
> New" pages just say "see PEP 12
Manuel Estrada Sainz writes:
> Package: python2.2
> Version: 2.2.1-12
> Severity: wishlist
> Tags: patch
>
> apt-proxy v2 doesn't seam to fit python-policy, I believe that this
> patch makes policy a little more clear:
>
>
> --- python-policy.sgml.orig 2002-10-08 12:59:46.0 +0200
> +++
Manuel Estrada Sainz writes:
> The patch was actualy meant as a suggestion, I didn't expect you to
> apply it literaly.
>
> Should I make a new patch?
Not needed. I hope that Bastian will include your case in the next
python-central version, so this will change again (hint, hint, ...)
Package: sqlrelay
Version: 1:0.32-1
Severity: grave
Original announcement at
http://lists.debian.org/debian-python/2002/debian-python-200209/msg00030.html
however I missed sqlrelay.
You need to keep the python2.1 package (zope uses python2.1). Please
build a python2.2-sqlrelay package as well and
Evan Simpson writes:
> I'm running into dependency clashes while trying to install wxPython,
> and looking for help.
>
> Since I am a Zope developer, and different versions of Zope rely on
> different versions of Python, I need to have several versions of Python
> installed. In fact, I have ins
Bastian Kleineidam writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> I just read this Post from Guido van Rossum[1] that the rexec.py and
> Bastian.py modules have severe security flaws. These modules will be
> disabled in the next 2.2 and 2.3 releases to avoid security risks.
t correct, as Python will ignore .pyc files with incompatible
versions. Otherwise you couldn't run Python 2.1 on a system which defaults
to 2.2.
FWIW, I do agree with your other points.
--
Matthias
This list may be incomplete, but at least all these bugs keep the
python packages out of testing. It seems that all these bugs can be
easily fixed ...
Do you know of other python dependent packages with RC reports?
Matthias
Package: gnue-designer (debian/main)
Maintainer: Jeff Bailey
Hi,
For wxwindows2.2 and 2.4 I see two RC reports. Any chance to fix these
soon?
What about removing wxwindows2.3 from unstable. AFAICR this was a
"development" release anyway. Same for 2.2, no other packages seem to
depend on this version anymore.
Thanks, Matthias
to see 2.2 and 2.3 gone.
>
> I'll file a request at ftp-admin if no-one listening pings me that they've
> already removed them :-)
thanks.
Matthias
st. Maybe it's
still some time to include this in 2.3. But I hesitate to apply such a
patch for Debian on it's own.
Matthias
Luca - De Whiskey's - De Vitis writes:
> On Fri, Apr 18, 2003 at 10:02:39AM +0200, Tim Dijkstra wrote:
> > 1) Should I ship .py or .pyc or both in the package. Byte-compile at
> > install time? Ask user what to do?
> > Ok, just saw a few other messages on this, my conclusion:
> > Byte-compile at
.
>
> Yup, I think its time for python-policy to move
> a) on the Debian website
> b) into debian-policy (along with the Perl policy)
I just wanted to wait for the "extended" python-central, which handles
"program packages" like mailman as well. Not sure who began to write
this ... ;-)
Matthias
Donovan Baarda writes:
> On Fri, 2003-04-18 at 19:54, Matthias Klose wrote:
> [...]
> > And/or take a look at dh_python, which does all this for "free"...
>
> BTW, where can we find this? I'd like to take a look.
Included in debhelper.
has happened. For example call
> "/var/lib/dpkg/info/python-foo.postinst configure pythonX.Y" when
> pythonX.Y is installed and "/var/lib/dpkg/info/python-foo.prerm
> pythonX.Y" when pythonX.Y is removed.
Then we are at a point, where we need a .python file (maybe
in dpkg format), which contains the python specific meta information.
Matthias
Ron writes:
>
> Howdy,
>
> On Sat, Apr 05, 2003 at 11:54:42AM +0200, Matthias Klose wrote:
> > For wxwindows2.2 and 2.4 I see two RC reports. Any chance to fix these
> > soon?
>
> Well the bts issues relating to the package itself should now all
> be fixed
3, psyco will be included in the core
(?).
And if you file a bug report, make sure you include a patch :-)
Matthias
ews on this one?
wxwindows2.4
This one doesn't build with the current binutils on hppa and
powerpc. I'll upload packages for hppa built with the binutils found
at http://ftp-master.debian.org/~doko/binutils/, unless I get notice
from Ron not to do so.
Please can somebody provide packages for powerpc in the same way?
Matthias
Hi,
signed wxwin2.4 binaries for Linux/PPC, built with the binutils from
http://ftp-master.debian.org/~doko/python/, are available on
http://smurf.noris.de/smurf/debian/upload
--
Matthias
As I am away the next two weeks, is somebody interested to make a
patch to build such a package from the python source?
Fabian Fagerholm writes:
> Hi!
>
> I've been working on packaging Albatross, a web application toolkit for
> Python (see ITP: #193574). Albatross has very nice documentation tha
[I'm away for two weeks, so please could somebody help?]
John Goerzen writes:
> Package: python2.2
> Version: 2.2.3-1
> Severity: serious
>
> Hello,
>
> I have a program that writes a logfile. It is opened with a standard
> open(filename, "wt") call.
>
> Whenever this file approaches about 1.8
ot use the anydbm module
(or explicitely the bsddb module).
It could be build using the gdbm module, but this would add another
dependency on an optional library package (gdbm).
Matthias
Encolpe DEGOUTE writes:
> And the module is always in the list of base modules for python2.3
??? there is no such list of "base modules".
> We need python 2.2 and 2.3 for testing Zope 2.7 and 3alpha releases, and
> my boss needs dbm for looking after our job.
zope really needs this module and _c
James Troup writes:
> Matthias Klose <[EMAIL PROTECTED]> writes:
>
> > Encolpe DEGOUTE writes:
> >> Package: python2.3
> >> Version: 2.2.104-1beta1.1
> >> Severity: important
> >> Tags: sid
> >>
> >> Module dbm.so is mis
"Martin v. Löwis" writes:
> Matthias Klose wrote:
> > Next thing to investigate, if the archives generated by the gdbm
> > implementation are binary compatible with the ones created by the
> > libdb1 implementation...
>
> Most definitely not: gdbm produces
for reasonably-small
packages that won't be much of a problem, IMHO.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: Das Zitat wurde zufällig ausgewählt. | http://smurf.noris.de
--
Auf jedes Mädchen mit Kurven kommen zehn Männer mit Geraden.
ists for 2.1, but not 2.2 or 2.3. How
> should the dependencies be written ?
The same way we currently handle non-pure Python packages -- except that
the nonversioned package contains the actual Python code and the versioned
packages are empty, instead of the other way round.
--
Matthias Urlichs
Roland Stigge writes:
> Hi,
>
> why isn't there a default /usr/include/python (possibly accomplished as
> a symlink in the package python-dev, like /usr/bin/python in the package
> python)? (I'm sure there is a reason for that, I just didn't find it
> documented somewhere.)
it's not needed. distu
| python2.2 | python2.1 | python2.0 | python1.6
> | python1.5
> Provides: python2.2-xmlbase, python2.1-xmlbase, python2.0-xmlbase,
> python1.6-xmlbase, python1.5-xmlbase
>
Duh? xmlbase doesn't seem to be supported for Python < 2.1.
--
Matthias Urlichs | {M:U} I
Ricardo Javier Cardenes Medina writes:
> Of course, all this require manual handling from the user. What I was
> proposing would require a whole PEP and some reasonable design and
> implementation, etc, so Python itself could map those .pyc to their
> original file, only resorting to them if the or
eck whether it really does
the right thing when you have python2.2 installed and pull in
python-docutils.
It gets even worse if I decide to support Python versions > 2.3, but that
doesn't seem to be helpable.
> I was going to suggest a solution, but I'm tired and I can&#
If you use debhelper's dh_python, please make sure you use debhelper
(>= 4.1.60), which will be in the archives tonight.
Matthias
r support of legacy applications almost certainly have the
default python package installed anyway.
This solution certainly beats the other alternatives.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.nor
This seems to be a common misunderstanding. Therefore the CC to
debian-python that I have something as a reference.
Lars Wirzenius writes:
> On la, 2003-08-09 at 03:22, Matthias Klose wrote:
> > Please upgrade your packages soon, or ask on debian-python for NMU's or
> > help
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 t
Hi, Lars Wirzenius wrote:
> (There will be a problem when the default version of Python changes. I
> don't think we have a way to deal with that.)
Why not simply call compileall.py for each dirctory in the PYTHONPATH
from "python"s postinst?
--
Matthias Urlichs |
Hi, Josselin Mouette wrote:
> Hrm, this could be achieved quite simply, /methinks. It needs little
> changes in dh_python and some prerm/postinst stuff in the python package
> (not the pythonX.Y package) to rebuild all .pyc's and .pyo's in this
> directory upon upgrade.
John Goerzen writes:
> Hello,
>
> Many Python programs use constructs like #!/usr/bin/env python2.3 to load
> themselves. Many others use #!/usr/bin/python2.3. On most Debian systems,
> these are the same.
>
> The submitter in #189473 claims that #!/usr/bin/env python2.3 is wrong
> because he h
ks like it should look like this instead:
>> egrep "^install ok installed:[^:]*:(|.*[ ,])$PYTHONXY([ ,]|$)" | \
so that it doesn't find packages which depend on packages which just happend
to end with $PYTHONXY. (Or perhaps you should rewrite that shell function in
Python
python in this case... this code has to go
> into the package "python"s postinst script.
So what? In postinst, python is already installed.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.n
it depends on python-numarray.
anyway, thanks for the summary!
please could you update a timestamp of the last update?
Matthias
libssl0.9.7, zlib1g (>= 1:1.1.4), python (>= 2.3)
> ^^^
>
> This wasn't an issue until Matthias added that versioned dependency on
> 'python' in response to bug #204748. In so doing, he has pre
packages.
Matthias
MO it's not soo bad, if you have the space to install zope
(and the data for the site) or jython (together with java).
And for package building there's always the possibility of having a
chroot installed using debootstrap.
Matthias
The package doesn't seem to be maintained, there's no upstream source
given in the copyright file, the closest I could find is
http://pynms.sourceforge.net/
And the pstats module shadows a standard module of the same name.
Joss, you did the last NMU. Any opinions?
Matthias
301 - 400 of 564 matches
Mail list logo
