Matthias Klose added the comment:
See http://mail.python.org/pipermail/python-dev/2013-January/123774.html
for the discussion.
Not updating the patches for tip/trunk is the best way to keep them out of the
project.
--
___
Python tracker
<h
Matthias Klose added the comment:
now closing/rejecting this issue. See
http://mail.python.org/pipermail/python-dev/2013-January/123774.html
for the discussion.
--
resolution: -> rejected
stage: patch review -> committed/rejected
status: open -&g
Matthias Klose added the comment:
> Ray Donnelly added the comment:
> Next time there's a release of Python 3, I'll rebase my patches against that.
sorry, this is the wrong attitude, if you want mingw support to go upstream.
fetch tip/trunk, re-apply your patches,
Matthias Klose added the comment:
I'm planning to update the tip to the next libffi release candidate once it's
released.
Once this is checked in, maybe revisit the extra copy for OS X; an ABI issue
with llvm/clang was identified in
http://sourceware.org/ml/libffi-discuss/2013/msg
Matthias Klose added the comment:
now committed, watching the buildds
--
stage: -> committed/rejected
status: open -> pending
type: -> enhancement
___
Python tracker
<http://bugs.python.or
Matthias Klose added the comment:
config.add and config.sub are needed for the AC_CANONICAL_HOST macro. the patch
includes these and the regenerated configure script.
--
___
Python tracker
<http://bugs.python.org/issue17
New submission from Matthias Klose:
I would like to check in a backport of the cross build patches on Thu or Fri,
so that these can be checked for the upcoming 2.7.4 release. The backport was
made using the current state of the cross build support on the 3.3 branch.
The patch is tested with
Matthias Klose added the comment:
just saw the comment about .hgtouch in
http://bugs.python.org/issue15819#msg169484
attaching a patch for it here (as proposed on python-committers).
--
nosy: +doko
Added file: http://bugs.python.org/file28874/hgtouch.diff
Matthias Klose added the comment:
> However, we must go further and add that the patches *cannot* break any
> other native or cross-compilation, which - as I think Matthias is
> alluding to - is probably not the case with your patch. This issue is
> called "cross and native bu
Matthias Klose added the comment:
> IMHO, updating these patches to track the latest Python is a pointless goal.
sorry, no. it's the *only* way to get these patches upstream. The mingw patches
will never see the light of the 3.3 branch. So the best thing to do is to
actively su
Matthias Klose added the comment:
now checked in the configure change. I think that the cross-build documentation
deserves an extra issue. Therefore now closing this issue.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -&g
Matthias Klose added the comment:
now committed, using stdin for sed.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Matthias Klose added the comment:
so here is what I intend to commit.
- --help now does exit with 0 (same as the python script)
- removed the abi safety check (always compares the same
two strings)
- build the script for the build target, so that it can be
checked before installing it
Changes by Matthias Klose :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Matthias Klose added the comment:
some random comments about py3k-20121004-MINGW.patch:
- Modules/_ctypes/libffi_msvc/win32.S
Please can you get rid of libffi_msvc and use libffi?
afaics, libffi has support for mingw32.
- there seem to be chunks which are unrelated to mingw, like
Matthias Klose added the comment:
about py3k-20121004-CROSS.tgz:
- committed 0001-CROSS-fix-typo-in-thread-AC_CACHE_VAL.patch
- 0002-CROSS-restore-graminit.-to-source-directory.patch
is this necessary? Assuming that you have correct time
stamps, this is something which usually is not
New submission from Matthias Klose:
currently regen calls the python interpreter for the host, not the build
machine. You can't directly use BUILD_FOR_PYTHON, because this one uses
./python explicitly, so use BUILDPYTHON instead.
I'd like to see this for 3.3 and
Matthias Klose added the comment:
I don't think this one is still necessary. can it be closed?
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/is
Matthias Klose added the comment:
in 3.3 and later, the test defaults to no when cross-building. If gcc is used
for the cross build, then a compile test is used.
it is usually needed to provide some values in a CONFIG_SITE file. See autoconf
for the details.
closing the issue
Matthias Klose added the comment:
the change to the configure script looks ok. however you could change the
README too.
It looks like the changes to the Makefile.pre.in are already applied.
--
nosy: +doko
___
Python tracker
<http://bugs.python.
Matthias Klose added the comment:
updated the comment, the fixes for the duplicate issues are checked in.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Changes by Matthias Klose :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue15484>
___
___
Python-bugs-list mailing list
Unsubscri
Matthias Klose added the comment:
and adding the pybuilddir to PYTHONPATH, so that _sysconfigdata.py is found if
it does exist.
$(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)
--
___
Python tracke
Matthias Klose added the comment:
> 2-CROSS-use-_PYTHON_PROJECT_BASE-in-distutils-sysconfig.patch
This looks ok to me, just factoring out some code and setting the project base.
Even if distutils is frozen, I'll apply this one, based on Eric's comment in
http://bugs.python.o
New submission from Matthias Klose:
On MultiArch systems, header files are split into /usr/include and
/usr/include/. Make sure that h2py finds all headers.
Currently the build of IN.py is broken, when running on such a system.
--
components: Build
files: ma-h2py.diff
keywords: patch
Matthias Klose added the comment:
looks fine to me.
--
___
Python tracker
<http://bugs.python.org/issue16828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Matthias Klose :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue16828>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
fixed in experimental, pyvenv's are now handled the same way as
python-virtualenvs. closing the issue here.
--
resolution: -> works for me
status: open -> closed
___
Python tracker
<http://b
Matthias Klose added the comment:
virtualenv for 2.7, when used with a Debian/Ubuntu system installation, should
only see site-packages. Same thing should be done for venv for 3.3 and up.
Even if needed patches will not go upstream, they are welcome
Matthias Klose added the comment:
having the posix_prefix as the default in Debian is an oversight on my side. it
always should be posix_local. I'll fix this at least for 3.3 in current
development releases.
The rationale for this is that distutils based installs install by default into
Changes by Matthias Klose :
--
nosy: +doko
___
Python tracker
<http://bugs.python.org/issue16480>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
oh, the equivalent for
flags = ['-I' + sysconfig.get_path('include'),
'-I' + sysconfig.get_path('platinclude')]
is still missing. I know that both scripts versions are only run post-install,
but
Matthias Klose added the comment:
looks fine, just one more minor issue: please use @LIBPL@ directly.
there's no feedback from others, so I think this should go in as the extra
script first, and not replace the original one immedi
Matthias Klose added the comment:
Am 07.11.2012 13:52, schrieb Ray Donnelly:
>
> Ray Donnelly added the comment:
>
>> is there a need for the built vs. installed prefix?
>> this is logic not found in the python implementation.
>> what is this supposed to do?
&
Changes by Matthias Klose :
--
nosy: +georg.brandl, loewis
___
Python tracker
<http://bugs.python.org/issue16235>
___
___
Python-bugs-list mailing list
Unsub
Matthias Klose added the comment:
see issue #1161914 for the original script.
> 2) Since we are Pythoneers, why write this script as a
> shell-script instead of a Python script? (sh may not even be
> available on Windows).
python-config is usally not used by python module builds,
Matthias Klose added the comment:
Earlier, we had the shell script, now we have the python implementation, which
doesn't work for cross builds. On the other hand, I don't like to have two
implementations which need to be kept in sync.
So my proposal would be to discard
Matthias Klose added the comment:
> Wait, does that mean you are explicitly supporting older Python versions?
no, that is unchanged. the Parser/asdl_c.py script had a shebang with python.
Of course you could replace the python in AC_CHECK_PROCS with the allowed
python2.x versions. But t
Matthias Klose added the comment:
yes, the test checks with a recent version first, then the older ones. However
you can configure with PYTHON=python2.4 configure ... to overwrite these
defaults.
--
___
Python tracker
<http://bugs.python.
Matthias Klose added the comment:
now checked in even without review, because it was broken on the branches too.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Changes by Matthias Klose :
--
components: +Build
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue16262>
___
___
Python-bugs-list mailin
Matthias Klose added the comment:
typo, r71375
--
___
Python tracker
<http://bugs.python.org/issue16262>
___
___
Python-bugs-list mailing list
Unsubscribe:
Matthias Klose added the comment:
r71315 did remove the call-out to hg, so it looks safe to not check for hg in
ASDLGEN.
--
___
Python tracker
<http://bugs.python.org/issue16
Matthias Klose added the comment:
looking at the unused subprocess import in asdl_c.py, maybe some call-outs to
svn/hg were made in the past?
the patch removes the check for hg for the asdl.[ch] builds, and sets ADSLGEN
to a appropriate python interpreter if one is found.
fixes the build for
New submission from Matthias Klose:
seen with the 3.3 branch and the trunk:
also, I think using python now unconditionally breaks the cross builds, so this
should call PYTHON_FOR_BUILD, not python.
/bin/mkdir -p Include
hg: no-repository, python: found! cannot run ../Parser/asdl_c.py -h
Matthias Klose added the comment:
http://www.freedesktop.org/software/systemd/man/os-release.html
is the next step, with the advantage of the definition of the file format for
/etc/os-release.
--
___
Python tracker
<http://bugs.python.
Matthias Klose added the comment:
the proposed patch has still some issues:
- it breaks the installation on 64bit platforms on Debian and Ubuntu.
Please test the patch on one of these platforms too.
- it hardcodes more platform information in the sys modules, which
makes it difficult
Matthias Klose added the comment:
fixed for 2.7 and 3.2 as well.
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11715>
___
___
Py
Matthias Klose added the comment:
now fixed, see http://bugs.python.org/issue15591#msg169927
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Matthias Klose added the comment:
looks fine. from my point of view this should go to the 3.3 branch after the
3.3.0 release, and to the trunk.
--
keywords: -needs review
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
I think that the ma.diff can safely go to the 2.7 and 3.2 branches.
For the other extensions which are not built you are probably missing the build
dependencies (try: apt-get build-dep python2.7 python3.2
Matthias Klose added the comment:
even if you pass other options to make, and -s not as the first flag? and does
this work for other makes different than GNU make too? But maybe we already
require GNU make.
--
___
Python tracker
<h
Matthias Klose added the comment:
@benjamin: no, the extensions were never built in parallel
@christian: no, that again would match the `s' when you have something like
--jobserver in MAKEFLAGS.
--
___
Python tracker
<http://bugs.py
Matthias Klose added the comment:
looks ok, two issues are:
builddir should have added
+("-pydebug" if hasattr(sys, "gettotalrefcount") else "")
the installation installs this to the lib-dynload director
Matthias Klose added the comment:
fixed.
--
resolution: -> fixed
status: open -> closed
versions: -Python 2.6
___
Python tracker
<http://bugs.python.org/i
Matthias Klose added the comment:
bah, this happens when you do a parallel build. --jobserver-fds is passed in
MAKEFLAGS, and the test for sharedmods turns on the quiet mode, because it
matches just *s* in MAKEFLAGS :-/
The patch tries to parse MAKEFLAGS using getopt, and if getopt is not
Matthias Klose added the comment:
this breaks the following upstream builds:
createrepo, linkchecker, gwibber, pegasus-wm
there is no need to remove is_hierarchical on the branches. it's not used by
urlparse at all.
is it safe to just keep the uses_query and uses_fragment lists o
Matthias Klose added the comment:
fixed for 2.7, made isdir static on windows and posix
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
New submission from Matthias Klose:
2.7 only:
isdir should not be exported, but a local symbol instead (this was accidentally
changed after the 2.7.3 release.
currently defined and used in Modules/getpath.c and Python/import.c, and used
in Python/bltinmodule.c
proposal to rename the
Matthias Klose added the comment:
the configure step sets LIBDIR to /usr/local/lib64. Please find out why this is
not set to /usr/local/lib.
--
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
> File "/etc/pythonstart", line 5, in
and this seems to be a patched/distro installation. Do you see this with an
unpatched one as well?
--
___
Python tracker
<http://bugs.pytho
Matthias Klose added the comment:
please could you attach the configure options, generated _sysconfigdata.py and
a log of the install step?
--
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
I don't think so. lib is hardcoded for any python release, so this issue
shouldn't be specific to 3.3.
--
___
Python tracker
<http://bugs.python.o
New submission from Matthias Klose:
I see this on all Debian and Ubuntu releases, when stdout is redirected. I
expect to see the compiler and linker invocations for the sharedmods target,
but I only see stderr (compiler and linker warnings).
e.g. make 2>&1 | tee log
or script -c &#x
New submission from Matthias Klose:
seen with at least 2.7, 3.2 and 3.3:
$ python-config --libs
-lpthread -ldl -lutil -lm -lpython2.7
$ pkg-config python --static --libs
-lpthread -ldl -lutil -lpython2.7
python-config uses the SYSLIBS macro, while pkg-config uses the LIBS macro.
depending on
Changes by Matthias Klose :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue11715>
___
___
Python-bugs-list
Matthias Klose added the comment:
committed the ma.diff from #11715, msg167680.
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
Matthias Klose added the comment:
afaics, msg166444 doesn't have to do anything with the cross build issue, but a
missing build dependency (here: dpkg-dev).
--
___
Python tracker
<http://bugs.python.org/is
Matthias Klose added the comment:
and please make sure that other build dependencies are installed as well:
sudo apt-get build-dep python3.2 (on 12.04/precise)
sudo apt-get build-dep python3.3 (on 12.10/quantal)
--
___
Python tracker
<h
Matthias Klose added the comment:
these are all extensions, which use headers and libraries installed in
multiarch paths, which I think are not found in this case. If the dpkg-dev
package isn't installed, please install it and recheck. So this issue should be
closed, maybe with the ma
Matthias Klose added the comment:
about searching /lib/: adding this directory won't help. all .a and
.so files are installed in /usr/lib or /usr/lib/.
about the missing dpkg-architecture: see the attached ma.diff patch. the
Debian/Ubuntu system compilers add an option -print-multiarch,
Matthias Klose added the comment:
just back in DE today, but still travelling. Won't be able to look at this
before late Monday.
--
___
Python tracker
<http://bugs.python.org/is
Matthias Klose added the comment:
like other platform dependent files _sysconfigdata.py should be installed in
plat-*
--
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
the current ability to cross-build python now relies on being able to run the
build python with the host library, using the _sysconfigdata.py from the host.
if somebody decides to implement _sysconfigdata as a C extension, please ensure
that this information
Matthias Klose added the comment:
while I appreciate the fix for #13150, it's the patch for #13150 which
introduces the ugliness to build the file in the srcdir in the first place.
re-setting the bug severity. the current behaviour can result in a bogus
installation; please let the re
Matthias Klose added the comment:
proposed patch, tested with configure, build and install
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file26345/sysconfigdata.diff
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
looks like the module can be put into $builddir/`cat pybuilddir.txt`. However
pybuilddir.txt is written/computed by the just built python. So either
- implement distutils.util.get_platform in configure.ac
- or write a temporary pybuilddir.txt, call the
New submission from Matthias Klose :
_sysconfigdata is generated in srcdir, not builddir, so if you do two
consecutive differently builds in different builddirs and using the same
srcdir, then the _sysconfigdata of the second build wins. _sysconfigdata.py has
to be built in the builddir, not
Matthias Klose added the comment:
using sys.maxsize isn't safe for cross builds. it should at least guarded by
'if not cross_compiling'.
I still think that the preferred way to get the library dirs is to ask the
compiler (patch attached), however this will add "incompati
Matthias Klose added the comment:
libffi_osx wasn't (yet) updated. so this seems to be unrelated to the 3.0.11
update.
--
___
Python tracker
<http://bugs.python.org/is
Matthias Klose added the comment:
and a variant, which moves all curses header related check together
(curses3.diff)
--
keywords: +patch
Added file: http://bugs.python.org/file26278/curses3.diff
___
Python tracker
<http://bugs.python.
Changes by Matthias Klose :
--
keywords: +needs review -patch
___
Python tracker
<http://bugs.python.org/issue15268>
___
___
Python-bugs-list mailing list
Unsub
Matthias Klose added the comment:
and only add the dir for the curses.h and nurses.h header checks
--
Added file: http://bugs.python.org/file26277/curses2.diff
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
can be closed if we don't bother to use the "wrong" header for the checks
--
___
Python tracker
<http://bugs.pyt
New submission from Matthias Klose :
the curses configure checks fail if only /usr/include/ncursesw/curses.h is
installed (on a Debian/Ubuntu system, uninstall the libncurses5-dev package,
and install the libncursesw5-dev package).
The attached patch adds -I/usr/include/ncursesw to CPPFLAGS
Matthias Klose added the comment:
hmm, that was submitted years ago ... (can we move this off line?)
--
___
Python tracker
<http://bugs.python.org/issue15
Matthias Klose added the comment:
fyi, the cross build changes are now checked in. Checked with an
x86_64-linux-gnu to arm-linux-gnueabi cross build. I don't plan to add
anything more for the 3.3 release besides bug fixes.
--
___
Python tr
New submission from Matthias Klose :
setup.py still has a version check for berkley db, currently only allowing
versions up to 5.1.x. I'm checking in a patch to bump this to allow versions up
to 5.3.x.
Maybe this version check should be disabled (after 3.3), using berkley db as a
backen
New submission from Matthias Klose :
if a runtime library path is passed to build an extension, it always ends up in
the .so file. it's not needed, so avoid runtime library path for extensions
found in system directories.
--
assignee: doko
components: Build
files: rpath.diff
key
Changes by Matthias Klose :
--
resolution: -> fixed
___
Python tracker
<http://bugs.python.org/issue14330>
___
___
Python-bugs-list mailing list
Unsubscri
Matthias Klose added the comment:
now renamed, add added the news entry
--
___
Python tracker
<http://bugs.python.org/issue14330>
___
___
Python-bugs-list mailin
Matthias Klose added the comment:
the cross build support is now updated for 3.3. so the mingw32 patches need an
update. Not sure if they will go into 3.3, because there seem to be non-trivial
changes for in Lib/distutils. Other self-contained changes probably should
still go into 3.3
Matthias Klose added the comment:
Roumen, I would like to close this issue. Please could you file separate issues
for the remaining bits?
- the thread/pthread configure issue
- the generation of the Setup / pyconfig.h files?
--
___
Python
Matthias Klose added the comment:
applied
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue14330>
___
___
Python-bugs-list mai
Matthias Klose added the comment:
PYTHON_BUILD_HOST_PLATFORM is confusing/misleading. I'll use
_PYTHON_HOST_PLATFORM (with the leading underscore to mark it somehow internal).
--
___
Python tracker
<http://bugs.python.org/is
Matthias Klose added the comment:
the ncurses/_flags changes seem to be unrelated. please open a separate issue.
--
___
Python tracker
<http://bugs.python.org/issue3
Matthias Klose added the comment:
for the readline ldd check, I'm checking in a patch to use readelf instead of
ldd for the cross build.
--
___
Python tracker
<http://bugs.python.org/i
Matthias Klose added the comment:
use a linker test to check for profiling support (derived from the patch in
issue #3754.
--
Added file: http://bugs.python.org/file26218/profiling.diff
___
Python tracker
<http://bugs.python.org/issue14
Matthias Klose added the comment:
some chunks of the python-py3k-20120607-CROSS.patch patch are now checked in.
I didn't see any issues with the symlinks, and generating the posix vars, so
maybe these bits should be dropped from the patch.
remaining issues are:
- the readline/nc
Matthias Klose added the comment:
updated the patch in issue #14330.
--
___
Python tracker
<http://bugs.python.org/issue3754>
___
___
Python-bugs-list mailin
501 - 600 of 827 matches
Mail list logo
