Steve Langasek writes:
> On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> > Steve Langasek writes:
> > > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
>
> > > > the design decision of putting the binary-all python packages in a
> > > > separate directory into /va
On Fri, Jan 20, 2006 at 10:47:19AM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > > the design decision of putting the binary-all python packages in a
> > > separate directory into /var/lib/python2.x/site-packages has s
Steve Langasek writes:
> On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> > Josselin Mouette writes:
> > > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > > > This is the right direction, and adding support for extensions makes
> > > > this complete. Does your
On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote:
> Josselin Mouette writes:
> > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > > This is the right direction, and adding support for extensions makes
> > > this complete. Does your proposal allow rebuilding these p
Josselin Mouette writes:
> Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit :
> As I already explained on IRC, dh_python will not hand .py files to
> python-support in architecture-dependent packages containing a .so
> module. This is unnecessary and would bring issues like this on
Le mercredi 18 janvier 2006 à 13:06 +0100, Matthias Klose a écrit :
> the design decision of putting the binary-all python packages in a
> separate directory into /var/lib/python2.x/site-packages has some
> problems when supporting packages with extensions (a proposal beeing
> made on #irc was to k
Josselin Mouette writes:
> Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > This is the right direction, and adding support for extensions makes
> > this complete. Does your proposal allow rebuilding these packages
> > without actually changing anything (except the changelog).
>
Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit :
> > Python-support already handles private modules. As for extensions, I
> > don't think we should change the current packaging practise. Packaging
> > them is already complicated enough as it is.
>
> yes, a reason to simplify this.
Josselin Mouette writes:
> > correct, but making it easier for extensions and applications using
> > private modules as well. when will python-support be able to support
> > these?
>
> Python-support already handles private modules. As for extensions, I
> don't think we should change the current p
Le lundi 16 janvier 2006 à 12:40 +0100, Matthias Klose a écrit :
> > Looking at the mailing list archives, some people have tried to initiate
> > discussions about making python in Debian evolve in the recent months,
> > but it doesn't look like there has been much interest.
>
> please see debian-
On Mon, Jan 16, 2006 at 12:40:09PM +0100, Matthias Klose wrote:
> Josselin Mouette writes:
> > Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> > > - beeing able to support more python versions in a separate archive
> > > is not just aesthetic (although not needed in the dist
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> > sorry, what is complicated about the solution?
> >
> > please read again, these benefits aren't just aesthetic:
> >
> > - working on metadata without having all packages available (which
> > ones?
Le vendredi 13 janvier 2006 à 15:31 +0100, Matthias Klose a écrit :
> sorry, what is complicated about the solution?
>
> please read again, these benefits aren't just aesthetic:
>
> - working on metadata without having all packages available (which
> ones?) is not just aesthetic.
What exactly
On Fri, 2006-01-13 at 12:44 +0100, Matthias Klose wrote:
> Joe Wreschnig writes:
> > One issue that comes to my mind now is behavior with regards to
> > dpkg-divert. I've diverted a number of Python modules on my system;
> > under this centralized registry I would have to divert them for all
> > ve
Matthias Klose wrote:
> Josselin Mouette writes:
> > Furthermore, if you want to see this implemented, you'll have to find
> > someone else to write the necessary changes to dh_python. I will not
> > write nor maintain any code that parses the control file in dh_python.
> > This script is already o
Josselin Mouette writes:
> Furthermore, if you want to see this implemented, you'll have to find
> someone else to write the necessary changes to dh_python. I will not
> write nor maintain any code that parses the control file in dh_python.
> This script is already one of the most complex ones in d
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 12:28 +0100, Matthias Klose a écrit :
> > > I don't understand the *need* for a specific control field. I just see
> > > it as another way to implement dh_python. My opinion is that
> > > "dh_python -m 2.2" is easier to implement and looks m
Le vendredi 13 janvier 2006 à 12:28 +0100, Matthias Klose a écrit :
> > I don't understand the *need* for a specific control field. I just see
> > it as another way to implement dh_python. My opinion is that
> > "dh_python -m 2.2" is easier to implement and looks more like other dh_*
> > commands
Joe Wreschnig writes:
> On Fri, 2006-01-13 at 12:04 +0100, Matthias Klose wrote:
> > Joe Wreschnig writes:
> > > On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> > > >- modules are installed into a directory not directly in sys.path.
> > >
> > > While I understand the rationale here,
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 11:30 +0100, Matthias Klose a écrit :
> > > Having a new field in the control file diverges from how debhelper
> > > programs usually behave, so I'd like to avoid such a solution - and I
> > > don't think there's a need for it.
> >
> > I did
On Fri, 2006-01-13 at 12:04 +0100, Matthias Klose wrote:
> Joe Wreschnig writes:
> > On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> > >- modules are installed into a directory not directly in sys.path.
> >
> > While I understand the rationale here, this could be *very* confusing
>
Joe Wreschnig writes:
> On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> >- modules are installed into a directory not directly in sys.path.
>
> While I understand the rationale here, this could be *very* confusing
> for people coming to Debian from other operating systems.
People w
Le vendredi 13 janvier 2006 à 11:30 +0100, Matthias Klose a écrit :
> > Having a new field in the control file diverges from how debhelper
> > programs usually behave, so I'd like to avoid such a solution - and I
> > don't think there's a need for it.
>
> I did outline the need for it. And I see
On Fri, 2006-01-13 at 11:05 +0100, Josselin Mouette wrote:
> Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit :
> > > - Some concerns were raised by the release team, that python-support
> > > tracks it's own state instead of using the dpkg database. To keep
> > > track of usable
Josselin Mouette writes:
> Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit :
> > > - Some concerns were raised by the release team, that python-support
> > > tracks it's own state instead of using the dpkg database. To keep
> > > track of usable python versions, python-central u
Le vendredi 13 janvier 2006 à 00:33 -0600, Joe Wreschnig a écrit :
> > - Some concerns were raised by the release team, that python-support
> > tracks it's own state instead of using the dpkg database. To keep
> > track of usable python versions, python-central uses a field
> > Python-Version i
On Fri, 2006-01-13 at 00:33 -0600, Joe Wreschnig wrote:
> Unless I misunderstand (either or or python-support) it does,
Should be ^- "either you or python-support"
--
Joe Wreschnig <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
On Thu, 2006-01-12 at 14:44 +0100, Matthias Klose wrote:
> After a long silence (and some work on "unrelated" C++ transitions ;),
> an update to the python packaging infrastructure.
Thank you. I've snipped stuff I agree with, or don't have an opinion on
yet.
>- modules are installed into a di
Hi,
I should probably check in to this discussion, since I'm the current
(inactive) maintainer of jython -- I put it up for adoption several
months ago since I don't have so much time these days and I no longer
have much involvement with either java or jython.
A couple of notes:
- I'll probably
> It should be practical to create Java templates for PyPy to use in the
> backend to produce a python implementation that executes in a JVM.
There is one snag to "Java" templates -- since Java has no goto, good
implementations of generators are difficult. The templates might
have to be bytecode
> > It should be practical to create Java templates for PyPy to use in the
> > backend to produce a python implementation that executes in a JVM.
>
> I can't back it up, but I thought this was possible already, as well as
> a clisp backend. I know for certain C and LLVM work.
I'm quite sure there i
> I think it was a good idea at the time to avoid duplicating all of the
> pure-python modules in the standard library. However, given that
> Jython's development hasn't kept pace with CPython I think that
> eliminating the dependency would be a better choice now.
That would simplify the issue gre
On Thu, Jan 12, 2006 at 11:54:18AM -0500, Derrick Hudson wrote:
> | Anyhow, I hate to see Jython orphaned, perhaps down the road (after
> | the next Jython release) I'll come back to find out what it takes to
> | take over the package maintenance of Jython in Debian.
>
> I'd like to see Jython
On Thu, Jan 12, 2006 at 05:09:56PM +0100, Wouter van Heyst wrote:
[jython]
| Is there any reason it can't work with 2.4?
Yes. The most recent release (2.2a1) doesn't implement the new
language constructs introduced by CPython 2.3 and 2.4.
-D
--
If we claim we have not sinned, we make Him out
On Thu, Jan 12, 2006 at 10:52:43AM -0500, Frank Wierzbicki wrote:
| > At least jython isn't an issue anymore (orphaned, and
| > new upstream snapshots available)
| Hi Matthias,
|
| I am (recently) the primary maintainer of the (upstream) Jython
| project.
I'm glad to see someone is working on it.
On Thu, Jan 12, 2006 at 10:52:43AM -0500, Frank Wierzbicki wrote:
> > At least jython isn't an issue anymore (orphaned, and
> > new upstream snapshots available)
> Hi Matthias,
>
> I am (recently) the primary maintainer of the (upstream) Jython
> project. I'm also a big fan of Debian. The next r
> At least jython isn't an issue anymore (orphaned, and
> new upstream snapshots available)
Hi Matthias,
I am (recently) the primary maintainer of the (upstream) Jython
project. I'm also a big fan of Debian. The next release of Jython
will depend on either Python 2.2 or Python 2.3, if it gets pa
37 matches
Mail list logo
