Re: [Python-Dev] Windows x64 bsddb 4.4.20 woes
The other query I had was whether or not I should try a later version of BerkeleyDB -- are we committed to 4.4.20 (or 4.4.x?) for 2.6/3.0 or is it worth investigating newer versions? Martin/Jesus, any thoughts on this? As Greg says: 4.5.x should work fine. Importing a new version into the build process is a big effort, though, and should only be done if either a) the beta releases are close, so the new version is the one we'll ship, or b) factual improvements can be demonstrated with a new version. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x64 bsddb 4.4.20 woes
Martin, you've changed externals/bsddb-4.4.20 with regards to x64 builds recently -- have you been able to get things working in your x64 environments? I changed the project files so that it will use the x64 compilers even if no environment variables were set - the original bsddb files expected that you run VS with /useenv, in an SDK x64 build environment. As a consequence, it now builds; I have never bothered testing that it actually works. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 3.0 buildbots all red
New sprint idea: getting all (inc. trunk) the buildbots green by Thursday. Anyone interested? I think the chance to achieve that is close to zero. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Fwd: 2.6 and 3.0 project management
Not quite. Items don't automatically end up on a hot list; they must explicitly be put on one. I'm not sure how you'd simulate this via saved searches. Maybe a combination of a custom keyword *and* a saved search would help. However this doesn't scale so well, because keywords show up in everybody's UI. Hot lists are only visible to users who care to subscribe to them. It would be relatively easy to implement this directly in roundup. IIUC, there should be a hotlist object, and either a) an issue has a multilink to multiple hotlists, or b) a hotlist has a multilink to multiple issues. I cannot envision the add to hotlist user interface, though. It should be possible to add an issue to a hotlist from the issue's page, right? So would a comma-separated list be reasonable? (with a popup menu to checkmark hotlists) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] 2.6 and 3.0 project management
It's just depends on how you see the tracker. It's not just to bug tracker anymore, is it? On other projects I've worked with, we had separate areas for bugs, features, and tasks. (yes, it's SourceForge.) I found it easier to keep organized. However, if this is Python's way, I'm not going to stand in it. Actually, one of the main complaints about the SF tracker is that it splits into several ones. Something starts out as a bug, but then becomes a patch as soon as somebody attaches a patch. So on SF, people had to open a *separate* issue to provide a patch, and leave a message in the original bug report pointing to the patch. They hated it, and insisted that the new tracker should have a single list of issues. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.6 and 3.0 tasks
* Replace Windows API calls with wide versions to support unicode for file names, environment etc. +1. This should be broken into separate tasks for each API. What are we referring to here? Calling the W versions explicitly and using wchar_t for everything, or using the TCHAR/TEXT() approach and keeping the API calls the same, letting the #define UNICODE do the work behind the scenes? Not sure whose being attributed here, but I think breaking down should be done by information source: command line, environment, registry, file names, sys.path, module names, etc. I have a patch on SF to resolve the command line issue. I don't think we should use Microsoft's Unicode programming model around TCHAR/TEXT. It would allow for two different builds, and given that we don't need to support W9X anymore, an ANSI build is pointless, IMO. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problems building python2.4 SRPM on RHEL4 x64
Eric B. schrieb:
Hi,
I appologize if this is not the right place to post this, but searching
through the old archives, I ran across the same issue from 3 years ago, but
I cannot find the resolution to it.
Currently, I am trying to build the python2.4 SRPM from Python.org on a
CentOS4.6_x64 platform, but the build is failing with a very non-descript
error message.
+ cd /var/tmp/python2.4-2.4-root/usr/bin
+ mv -f pydoc pydoc2.4
+ cd /var/tmp/python2.4-2.4-root/usr/bin
+ mv -f idle idle2.4
+ echo '#!/bin/bash'
+ echo 'exec /usr/bin/python2.4 /usr/lib64/python2.4/idlelib/idle.py'
+ chmod 755 /var/tmp/python2.4-2.4-root/usr/bin/idle2.4
+ cp -a Tools /var/tmp/python2.4-2.4-root/usr/lib64/python2.4
+ rm -f mainpkg.files
+ find /var/tmp/python2.4-2.4-root/usr/lib64/python2.4/lib-dynload -type f
+ sed 's|^/var/tmp/python2.4-2.4-root|/|'
+ grep -v -e '_tkinter.so$'
error: Bad exit status from /var/tmp/rpm-tmp.55639 (%install)
The last command executed imediately before the error output
seems to be
find
$RPM_BUILD_ROOT%{__prefix}/%{libdirname}/python%{libvers}/lib-dynload
-type f |
sed s|^${RPM_BUILD_ROOT}|/| |
grep -v -e '_tkinter.so$' mainpkg.files
That is not the last command in the %install script (atleast not
according to the spec file). So it is not at all clear why the
shell should stop executing at that point, and spit out
that error message.
The only theory I can come up with is that the shell *crashed*.
Can you get hold of the rpm-tmp file (e.g. by asking RPM not
to delete it)? Then run it independently, perhaps under
strace.
If it's indeed the case that the shell crashes, something
is seriously wrong with your operating system.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x64 bsddb 4.4.20 woes
Removing the dependency on db_static.vcproj and merging the relevant source code files into _bsddb.vcproj did the trick -- all x64 bsddb-related tests now pass. The only issue with this approach is that it locks _bsddb.vcproj into 4.4.20. However, considering that this approach (i.e. bringing their source files into our build instead of linking against a static lib compiled with wildly incompatible flags) only took me about two minutes to implement and immediately fixed every bsddb problem I was encoutering, I'm convinced it's the right way to go. (I can separate the dependencies easily enough.) I'm convinced this is the wrong approach. Are you sure you copied all compiler settings over to the project correctly? What is the procedure to upgrade such a setup? What is the procedure for people who want to build with a different version of bsddb? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows x64 bsddb 4.4.20 woes
I reviewed all the compiler options used by db_static.vcproj -- the only thing I needed to bring over was -DDIAGNOSTIC for debug builds. Everything else either had no impact and could be safely dropped, or conflicted with compiler options used by the rest of the python build (function level linking, buffer overflow checks, etc). If you take out those options from the db_static project, it *should* work just the same as what you've got now, right? Can you use that approach to determine the culprit for making the static library approach fail? As it stands now, the .lib generated by db_static.vcproj for x64 builds just straight out does not work. That can be fixed in two ways: coerce db_static.vcproj into matching our build, or mimicking db_static in a new .vcproj that's contained with our build, inheriting our property sheets. I chose the latter. I would *really* prefer the former. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
