Tim Golden wrote:
However, the .msi installs (and Python
runs) without issue on a virgin VirtualXP. And it passes the basic test
suite ok.
I lied. test_zipfile fails because the new(ish) zipdir.zip doesn't
get carried across to the install. Patched in:
http://bugs.python.org/issue5470
A co
Martin v. Löwis wrote:
I also see that it fails to add custom actions into
InstallExecuteSequence. I find that puzzling - apparently,
it tries to merge the twice. Are you sure you didn't run it
twice? It will certainly fail the second time.
Just to confirm: I'm certainly only running this once
Martin v. Löwis wrote:
First, it relies on config.py whose existence msi.py
optionally ignores.
Feel free to create a patch for that.
http://bugs.python.org/issue5467
TJG
--
http://mail.python.org/mailman/listinfo/python-list
Martin v. Löwis wrote:
BTW what are your feelings on a patch to msi.py to change the
names of the directories it's looking for to pick up the Tk
licenses? It's a bit of a grey area since the only "canonical"
reference I can find is the externals checkout from within
tools\buildbot: you might as w
> BTW what are your feelings on a patch to msi.py to change the
> names of the directories it's looking for to pick up the Tk
> licenses? It's a bit of a grey area since the only "canonical"
> reference I can find is the externals checkout from within
> tools\buildbot: you might as well argue that
Martin v. Löwis wrote:
AFAICT, it only complained about errors in merging _Validation.
I'm not sure whether I get the same errors (I would have to
check); those errors can safely be ignored.
Good.
I also see that it fails to add custom actions into
InstallExecuteSequence. I find that puzzling
> I attach the merge.log output but I'll try to do some
> research to understand what's going on here in any case.
> In particular it's not clear to me whether the thing
> has worked but has just tripped up over some non-essential
> part, or whether these are real errors. (I really need
> to set up
Tim Golden wrote:
Martin v. Löwis wrote:
Just create an empty one.
Won't quite work: merge tries to find full_current_version
which is determined (if None) in msi.py from the rather
involved current version stuff.
Only if you don't pass an msi file on the command line. So
I recommend that you
Martin v. Löwis wrote:
Just create an empty one.
Won't quite work: merge tries to find full_current_version
which is determined (if None) in msi.py from the rather
involved current version stuff.
Only if you don't pass an msi file on the command line. So
I recommend that you do that.
OK.
>> Just create an empty one.
>
> Won't quite work: merge tries to find full_current_version
> which is determined (if None) in msi.py from the rather
> involved current version stuff.
Only if you don't pass an msi file on the command line. So
I recommend that you do that.
> I'm going to give up
Martin v. Löwis wrote:
merge.py attempts to import config.py but I can't find it...
Just create an empty one.
Won't quite work: merge tries to find full_current_version
which is determined (if None) in msi.py from the rather
involved current version stuff.
I'm going to give up on this for to
> First, it relies on config.py whose existence msi.py
> optionally ignores.
Feel free to create a patch for that.
> File "", line 2, in OpenDatabase
> pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, None,
> None, None, 0, -2147024786), None)
This is 0x8007006e; 0x6E, in turn, mi
> merge.py attempts to import config.py but I can't find it...
Just create an empty one.
Martin
--
http://mail.python.org/mailman/listinfo/python-list
En Sun, 08 Mar 2009 18:08:50 -0200, Martin v. Löwis
escribió:
What does the merge do? I can't find mention of it
in the docs.
It merges the msvcrt merge module into the installer (and then
monkey patches it, to revert the msm decision of setting
ALLUSERS). I tried to integrate it originally
Martin v. Löwis wrote:
What does the merge do? I can't find mention of it
in the docs.
It merges the msvcrt merge module into the installer (and then
monkey patches it, to revert the msm decision of setting
ALLUSERS). I tried to integrate it originally as a step
after creating the msi. Unfortun
> What does the merge do? I can't find mention of it
> in the docs.
It merges the msvcrt merge module into the installer (and then
monkey patches it, to revert the msm decision of setting
ALLUSERS). I tried to integrate it originally as a step
after creating the msi. Unfortunately, the merge objec
Scott David Daniels wrote:
Tim Golden wrote:
... Anyhow, at the end I have a working Python 2.7a0 running
under Windows.
Do you mean 3.1a0? As far as I know, 2.7a0 requires the use
of the time machine, as it is expected to be 3 months out.
No; 2.7a0 is the version number of the svn HEAD.
Martin v. Löwis wrote:
In addition, the CVS version of pywin32 which I built in
order to run the msi.py script has a small bug in genpy
which prevents it from generating COM support in the way
in which msi.py does it.
I'm using Python 2.4 to run msi.py; that has always worked
fine for me.
Int
> Do you mean 3.1a0? As far as I know, 2.7a0 requires the use
> of the time machine, as it is expected to be 3 months out.
The current trunk calls itself 2.7a0. I think you might be referring
to 3.0a1.
Regards,
Martin
--
http://mail.python.org/mailman/listinfo/python-list
> In addition, the CVS version of pywin32 which I built in
> order to run the msi.py script has a small bug in genpy
> which prevents it from generating COM support in the way
> in which msi.py does it.
I'm using Python 2.4 to run msi.py; that has always worked
fine for me.
Regards,
Martin
P.S.
Tim Golden wrote:
... Anyhow, at the end I have a working Python 2.7a0 running
under Windows.
Do you mean 3.1a0? As far as I know, 2.7a0 requires the use
of the time machine, as it is expected to be 3 months out.
If you do get an installer built, even having a semi-official copy
around for th
Gabriel Genellina wrote:
En Fri, 06 Mar 2009 06:52:00 -0200, escribió:
I have succeeded in building Python 2.6.1 from source under Windows XP
by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
both from the Visual C++ application as well as from the commandline
[...]
I would li
On Mar 6, 11:21 am, Christian Heimes wrote:
> dan.erik.peter...@gmail.com schrieb:
>
> > I suppose that what I am looking for is the Windows version of "make
> > install" as we know it after running configure with --
> > prefix=custom_location --exec-prefix=custom_location flags and make on
> > th
En Fri, 06 Mar 2009 06:52:00 -0200, escribió:
I have succeeded in building Python 2.6.1 from source under Windows XP
by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
both from the Visual C++ application as well as from the commandline
[...]
I would like to move this Python ins
dan.erik.peter...@gmail.com schrieb:
> I suppose that what I am looking for is the Windows version of "make
> install" as we know it after running configure with --
> prefix=custom_location --exec-prefix=custom_location flags and make on
> the Linux platform.
The Windows build system doesn't have
I suppose that what I am looking for is the Windows version of "make
install" as we know it after running configure with --
prefix=custom_location --exec-prefix=custom_location flags and make on
the Linux platform.
Dan
--
http://mail.python.org/mailman/listinfo/python-list
Hi all -
I have succeeded in building Python 2.6.1 from source under Windows XP
by running Visual C++ 2008 Express on the PCbuild/pcbuild.sln file
both from the Visual C++ application as well as from the commandline
using :
vcbuild pcbuild.sln 'Release|Win32'
This builds fine (allowing for error
27 matches
Mail list logo
