[Barry Warsaw]
> As an aside, I wonder if it would make sense to create an Ubuntu/Debian
> package that essentially just depended on all those -dev packages. That way
> you could install this python-uber-dev package and get everything you needed
> to build a sumo Python.
I don’t know. Any Debian
>> See PC/bdist_wininst.
>
> Hm, my question may not have been clear: *how* is the wininst-9.0
> built from the bdist_wininst sources ? I see 6, 7.0, 7.1 and 8.0
> versions of the visual studio build scripts, but nothing for VS 9.0.
Ah. See PCbuild/bdist_wininst.vcproj.
Regards,
Martin
_
On Thu, Jul 1, 2010 at 1:22 PM, "Martin v. Löwis" wrote:
>> I would like to modify the code of the bdist installers, but I don't
>> see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
>
> See PC/bdist_wininst.
Hm, my question may not have been clear: *how* is the wininst-9.0
built
Am 01.07.2010 02:01, schrieb Dan Buch:
> /me throws hat into ring. I'm in the middle of migrating fairly
> large chunks of an overgrown codebase from Subversion to Mercurial,
> so I might actually have worthwhile input :)
To all the volunteers: an issue that apparently requires immediate
attentio
> I would like to modify the code of the bdist installers, but I don't
> see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
See PC/bdist_wininst.
HTH,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailma
Hi,
I would like to modify the code of the bdist installers, but I don't
see any VS project for VS 9.0. How are the wininst-9.0*exe built ?
thanks,
David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
/me throws hat into ring. I'm in the middle of migrating fairly
large chunks of an overgrown codebase from Subversion to Mercurial,
so I might actually have worthwhile input :)
--
~Dan
On Wed, Jun 30, 2010 at 10:41:51AM +0200, Georg Brandl wrote:
> Am 30.06.2010 07:37, schrieb "Martin v. Löwis"
Brett Cannon wrote:
> On Wed, Jun 30, 2010 at 15:01, "Martin v. Löwis"
> wrote:
When Tim Peters added it, he wanted it to tell him whether he
did the Windows build correctly, INCLUDING ALL OPTIONAL
PACKAGES that can possibly work on Windows. If you try to
generalize this beyond
On Wed, Jun 30, 2010 at 15:20, Nick Coghlan wrote:
> On Thu, Jul 1, 2010 at 7:55 AM, Brett Cannon wrote:
>> So it isn't that it's "unexpected", it's that a dependency is missing.
>> So it seems the terminology needs to get tweaked.
>
> More that the phrase "expected skip" isn't clearly defined an
On Jul 01, 2010, at 07:52 AM, Nick Coghlan wrote:
>Note that it works this way on Linux as well. On Kubuntu (for example)
>you need another half dozen or so additional *-dev packages installed
>to avoid unexpected test skips.
>
>Cheers,
>Nick.
>
>P.S. For anyone curious, I posted the list of extra
On Thu, Jul 1, 2010 at 7:55 AM, Brett Cannon wrote:
> So it isn't that it's "unexpected", it's that a dependency is missing.
> So it seems the terminology needs to get tweaked.
More that the phrase "expected skip" isn't clearly defined and people
sometimes guess wrong as to what it means. As Mart
On Jun 30, 2010, at 10:35 PM, M.-A. Lemburg wrote:
>The Python default installation dir for
>libs (including site-packages) is $prefix/lib/pythonX.X, so you
>already have separate and properly versioned directory paths.
>
>What difference would the extra version on the .so file make in
>such a set
On Wed, Jun 30, 2010 at 15:01, "Martin v. Löwis" wrote:
>>> When Tim Peters added it, he wanted it to tell him whether he did the
>>> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
>>> possibly work on Windows. If you try to generalize this beyond Windows,
>>> then the only skip
>> When Tim Peters added it, he wanted it to tell him whether he did the
>> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
>> possibly work on Windows. If you try to generalize this beyond Windows,
>> then the only skips that are expected are the ones for tests that
>> absolutely
On Wed, Jun 30, 2010 at 14:52, Nick Coghlan wrote:
> On Thu, Jul 1, 2010 at 5:53 AM, "Martin v. Löwis" wrote:
>> When Tim Peters added it, he wanted it to tell him whether he did the
>> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
>> possibly work on Windows. If you try to ge
On Thu, Jul 1, 2010 at 5:53 AM, "Martin v. Löwis" wrote:
> When Tim Peters added it, he wanted it to tell him whether he did the
> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can
> possibly work on Windows. If you try to generalize this beyond Windows,
> then the only skips that
On Wed, Jun 30, 2010 at 12:53, "Martin v. Löwis" wrote:
>> The whole "unexpected" skipping is somewhat of a mess. In an ideal
>> situation modules that are optionally built should be allowed to skip,
>
> While this may be the wide-spread interpretation, it is definitely *not*
> the original intent
Barry Warsaw wrote:
> On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
>
>> Scott Dial wrote:
>>> On 6/24/2010 5:09 PM, Barry Warsaw wrote:
> What use case does this address?
> If you want to make it so a system can install a package in just one
> location to be used by multiple
Martin v. Löwis wrote:
> > The whole "unexpected" skipping is somewhat of a mess. In an ideal
> > situation modules that are optionally built should be allowed to skip,
>
> While this may be the wide-spread interpretation, it is definitely *not*
> the original intention of the feature.
>
> When
> The whole "unexpected" skipping is somewhat of a mess. In an ideal
> situation modules that are optionally built should be allowed to skip,
While this may be the wide-spread interpretation, it is definitely *not*
the original intention of the feature.
When Tim Peters added it, he wanted it to t
On Wed, Jun 30, 2010 at 09:03, Bill Janssen wrote:
> Martin v. Löwis wrote:
>
>> > Seems to work fine. So this I don't understand. Any ideas, anyone?
>>
>> Didn't we discuss this before?
>
> Possibly, but I don't recall doing so.
>
>> The buildbot slave has no controlling
>> terminal anymore, h
On 06:46 pm, exar...@twistedmatrix.com wrote:
On 04:44 pm, solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
So, my question then is, why are these skips "unexpected"? Seems to
me
that if this is the case, this test will never run on any platform.
You can c
On 05:29 pm, mar...@v.loewis.de wrote:
Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com:
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hen
On Jun 25, 2010, at 12:35 AM, M.-A. Lemburg wrote:
>Scott Dial wrote:
>> On 6/24/2010 5:09 PM, Barry Warsaw wrote:
What use case does this address?
>>>
If you want to make it so a system can install a package in just one
location to be used by multiple Python installations, then the
On Jun 25, 2010, at 03:42 PM, Scott Dial wrote:
>On 6/25/2010 2:58 PM, Brett Cannon wrote:
>> I assume you are talking about PEP 3147. You're right that the PEP was
>> for pyc files and that's it. No one is talking about rewriting the
>> PEP.
>
>Yes, I am making reference to PEP 3147. I make refer
On Jun 26, 2010, at 10:45 PM, Matthias Klose wrote:
>Having non-conflicting extension names is a schema which already is used on
>some platforms (debug builds on Windows). The question for me is, if just a
>renaming of the .so files is acceptable for upstream, or if distributors
>should implement
On Jun 25, 2010, at 11:58 AM, Brett Cannon wrote:
>> Placing .so files together does not simplify that install process in any
>> way. You will still have to handle such packages in a special way. You
>> must still compile the package multiple times for each relevant version
>> of python (with spec
On Jun 26, 2010, at 06:50 PM, Scott Dial wrote:
>On 6/26/2010 4:06 PM, Matthias Klose wrote:
>> On 25.06.2010 22:12, James Y Knight wrote:
>>> On Jun 25, 2010, at 4:53 AM, Scott Dial wrote:
Placing .so files together does not simplify that install process in any
way. You will still have
On 04:26 pm, jans...@parc.com wrote:
exar...@twistedmatrix.com wrote:
Could the test be rewritten (or supplemented) to use a pty? Most or
perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make buildb
On 04:44 pm, solip...@pitrou.net wrote:
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
So, my question then is, why are these skips "unexpected"? Seems to
me
that if this is the case, this test will never run on any platform.
You can change the value of the "usepty" option in your
On Jun 25, 2010, at 04:53 AM, Scott Dial wrote:
>My suggestion was that a package that contains .so files should not be
>shared (e.g., the entire lxml package should be placed in a
>version-specific path).
Matthias outlined some of the pitfalls with this approach.
>The motivation for this PEP wa
On Jun 26, 2010, at 10:22 PM, Matthias Klose wrote:
>On 24.06.2010 22:46, Barry Warsaw wrote:
>> So, we could say that PEP 384 compliant extension modules would get written
>> without a version specifier. IOW, we'd treat foo.so as using the ABI. It
>> would then be up to the Python runtime to th
I'm trying to catch up on this thread, so I may collapse some responses or
refer to points others have brought up.
On Jun 24, 2010, at 05:53 PM, Scott Dial wrote:
>If the package has .so files that aren't compatible with other version
>of python, then what is the motivation for placing that in a
Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com:
> On 05:24 am, mar...@v.loewis.de wrote:
>>> Seems to work fine. So this I don't understand. Any ideas, anyone?
>>
>> Didn't we discuss this before? The buildbot slave has no controlling
>> terminal anymore, hence it cannot open /dev/tty. If
On Wed, Jun 30, 2010 at 10:20 AM, Antoine Pitrou wrote:
> On Wed, 30 Jun 2010 10:03:49 -0700
> Guido van Rossum wrote:
>>
>> > Also, please note that values used by seek() and tell() on
>> > text I/O are "opaque cookies". While they can happen to match the
>> > raw binary file position, it is a m
On Wed, 30 Jun 2010 10:03:49 -0700
Guido van Rossum wrote:
>
> > Also, please note that values used by seek() and tell() on
> > text I/O are "opaque cookies". While they can happen to match the
> > raw binary file position, it is a mere coincidence (or an
> > implementation detail, at your will).
On Wed, Jun 30, 2010 at 9:42 AM, Antoine Pitrou wrote:
> On Tue, 29 Jun 2010 20:05:29 -0400
> "R. David Murray" wrote:
>>
>> I would imagine Guido is talking about an io.TextIOWrapper...in other
>> words, take the binary file you've just finished grabbing info
>> from, and reread it as a text fil
On Wed, 30 Jun 2010 09:00:09 PDT
Bill Janssen wrote:
>
> So, my question then is, why are these skips "unexpected"? Seems to me
> that if this is the case, this test will never run on any platform.
You can change the value of the "usepty" option in your buildbot.tac.
(you will also have to rest
On Tue, 29 Jun 2010 20:05:29 -0400
"R. David Murray" wrote:
>
> I would imagine Guido is talking about an io.TextIOWrapper...in other
> words, take the binary file you've just finished grabbing info
> from, and reread it as a text file in order to grab the actual
> message content.
This sounds a
exar...@twistedmatrix.com wrote:
> Could the test be rewritten (or supplemented) to use a pty? Most or
> perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make buildbottest
in dir /Users/buildbot/build
Martin v. Löwis wrote:
> > Seems to work fine. So this I don't understand. Any ideas, anyone?
>
> Didn't we discuss this before?
Possibly, but I don't recall doing so.
> The buildbot slave has no controlling
> terminal anymore, hence it cannot open /dev/tty. If you are curious,
> just patch
Guido van Rossum wrote:
> On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen wrote:
> > My Leopard and Tiger PPC buildbots are momentarily green! But I'm
> > looking into why I'm skipping some tests. My buildbots are up-to-date
> > OS-wise and very vanilla, with the latest applicable Xcode.
> >
> >
R. David Murray wrote:
> On Tue, 29 Jun 2010 17:02:14 -0400, Steve Holden wrote:
>> Guido van Rossum wrote:
>>
>>> - wrap the binary stream in a text stream
>> "wrap" how? The ultimate destiny of the text is twofold:
>
> I would imagine Guido is talking about an io.TextIOWrapper...in other
> word
On 05:24 am, mar...@v.loewis.de wrote:
Seems to work fine. So this I don't understand. Any ideas, anyone?
Didn't we discuss this before? The buildbot slave has no controlling
terminal anymore, hence it cannot open /dev/tty. If you are curious,
just patch your checkout to output the exact errn
Guido van Rossum python.org> writes:
> As for protocol buffers, assuming its absence (so far from the
> stdlib is the only objection, how hard would it be to make the logging
> package "prepared" so that if one *did* have protocol buffers
> installed, it would be a one-line config setting to use
Am 30.06.2010 07:37, schrieb "Martin v. Löwis":
> It seems that both Dirkjan and Brett are very caught up
> with real life for the coming months. So I suggest that
> some other committer who favors the Mercurial transition
> steps forward and takes over this project.
>
> If nobody volunteers, I pr
46 matches
Mail list logo
