Stephen Warren added the comment:
The attached patch should solve the problem by adding appropriate
dependencies to the libinstall target.
I have tested:
./configure; make install
but not yet:
./configure; make all install
./configure; make all; make install
Note: I introduced a new
Changes by Sean Reifschneider:
--
keywords: +patch
_
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1704287
_
___
Python-bugs-list mailing list
Unsubscribe:
Sean Reifschneider added the comment:
I can verify that this happens in trunk (2.6) on CentOS 5, 32-bit.
Patch review looks good, and solves the problem. I've committed it to
trunk as revision 58225.
--
nosy: +jafo
resolution: - accepted
status: open - closed
type: - behavior
Stephen Warren added the comment:
Now, I have also tested:
./configure; make all install
./configure; make all; make install
The install piece of each of the above doesn't seem to accidentally
duplicate any of the building work, so the patch seems to check out OK -
no negative side-effects.
Changes by Martin v. Löwis:
--
keywords: -py3k
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1185
__
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Sean Reifschneider:
--
keywords: +patch
superseder: - Add os.link() and os.symlink() support for Windows
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue478407
Sean Reifschneider added the comment:
swarren: According to the wikipedi article on junction points:
They can only be used on folders, not files.
They are being replaced by symbolic links.
The latter I take to mean junction points are being phased out, but I
couldn't find any information
New submission from Michael Hoffman:
See http://docs.python.org/lib/optparse-callback-example-6.html where
it says 'either - or - can be option arguments'. One of these should
be --. The same error occurs several times on the same page.
Not a problem in the Optik docs at
Stephen Warren added the comment:
Hmm. I just tested Accurev - whatever it does, it works for files too.
That said, it could be making hard-links, which I guess could be different.
Additionally, the sysinternals junction utility doesn't find any
junction points when probing the link files.
Guido van Rossum added the comment:
This is only a problem with the 2.5 latex docs.
--
assignee: - fdrake
nosy: +fdrake, gvanrossum
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1186
__
Guido van Rossum added the comment:
Can you redo the patch while keeping the slot *position* (though not the
name or type)? The wasted space is minimal (4-8 bytes per type or class
object) and it means a lot for third party code if the positional struct
initialization never breaks due to
Stephen Warren added the comment:
It seems that Accurev uses junction points for directories, and
hard-links for files. That's probably a little to disparate to implement
in Python?
Also, I tried sysinternals' junction.exe and whilst it allows one to
create junction points that point at files,
New submission from Andrew Nissen:
Revision 53293 appears to have missed some of the logic inherent in the
previous code. There also appears to be problems with the way that the
dup2 calls are made that can result in a behavior different then
intended under a number of circumstances.
Andrew Nissen added the comment:
This patch (subprocess.fix_fileno.udiff) made against subprocess.py
(Revision 55604)appears to give the desired behavior
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1187
__
Guido van Rossum added the comment:
Thanks Neil!
--
resolution: - accepted
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1185
__
___
Neil Schemenauer added the comment:
I made the changes as suggest by Guido. Commited as SVN rev 58226.
Thanks for the patch.
--
nosy: +nas
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1185
__
Neil Schemenauer added the comment:
It looks to me like fp_readl is no longer working as designed and the
patch is not really the right fix. The use of decoding_buffer is
tricky and I think the conversion to bytes screwed it up. It might be
clearer to have a separate decoding_overflow struct
Sean Reifschneider added the comment:
If the file links are on the same volume, it's probably using hard
links. Symbolic links can cross file-systems, of course. So it sounds
like the Junction Points aren't going to work to replace symlinks, and
they'll be Vista only.
New submission from Amaury Forgeot d'Arc:
This patch adds documentation for all the fields in the tp_as_number,
tp_as_sequence and tp_as_mapping structures.
It may not be complete, but is still better than the XXX in the current
docs.
This is my first contribution to the doc, feel free to amend
Philip Jenvey
added the comment:
make that against r58227
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1188
__
Changes by
Philip Jenvey
:
--
type: - behavior
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1188
__
New submission from
Philip Jenvey
:
tell() will skip the next LF (after a CR sets f_skipnextlf) when
universal newline support is enabled; essentially doing part of the work
of read(). However it does not identify CRLF as
Changes by Martin v. Löwis:
--
keywords: +patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1189
__
___
Python-bugs-list mailing list
Unsubscribe:
23 matches
Mail list logo