Issue 10142: Support for SEEK_HOLE/SEEK_DATA (original) (raw)
Created on 2010-10-19 03:15 by jcea, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (54)
Author: Jesús Cea Avión (jcea) * 
Date: 2010-10-19 03:15
ZFS supports SEEK_HOLE/SEEK_DATA in "lseek()" syscall.
Oracle Solaris man page por "lseek":
""" [...] o If whence is SEEK_HOLE, the offset of the start of the next hole greater than or equal to the supplied offset is returned. The definition of a hole is provided near the end of the DESCRIPTION.
o If whence is SEEK_DATA, the file pointer is set to the
start of the next non-hole file region greater than or
equal to the supplied offset.
The symbolic constants SEEK_SET, SEEK_CUR, SEEK_END,
SEEK_HOLE, and SEEK_DATA are defined in the header
<unistd.h>.[...] A "hole" is defined as a contiguous range of bytes in a file, all having the value of zero, but not all zeros in a file are guaranteed to be represented as holes returned with SEEK_HOLE. Filesystems are allowed to expose ranges of zeros with SEEK_HOLE, but not required to. Applications can use SEEK_HOLE to optimise their behavior for ranges of zeros, but must not depend on it to find all such ranges in a file. The existence of a hole at the end of every data region allows for easy programming and implies that a virtual hole exists at the end of the file. Applications should use fpathconf(_PC_MIN_HOLE_SIZE) or pathconf(_PC_MIN_HOLE_SIZE) to determine if a filesystem supports SEEK_HOLE. See fpath- conf(2).
For filesystems that do not supply information about holes,
the file will be represented as one entire data region."""
Implementation would be trivial. Simply conditionally compile the constant export in the C module. Or adopt the approach in the last phrase.
Any novice?.
Author: Raymond Hettinger (rhettinger) *
Date: 2010-10-19 04:58
Martin, any thoughts on adding a ZFS dependent feature? ISTM this Solaris feature hasn't taken hold elsewhere and it may be a mistake to immortalize it in Python.
Author: Jesús Cea Avión (jcea) *
Date: 2010-10-19 10:37
Seems to be adopted too in *bsd: http://manpages.ubuntu.com/manpages/lucid/man2/lseek.2freebsd.html .
The feature has patches available too for Linux, but never integrated in mainline kernel, AFAIK. Googling "SEEK_HOLE" is interesting.
Author: Antoine Pitrou (pitrou) *
Date: 2010-10-19 10:44
If it's just additional constants then I don't see the problem. We already have a lot of platform-specific constants.
However, it would be a lot better if the io module were made to work properly with these constants, too. There are a lot of places where we hardcode tests such as whence == SEEK_SET or even whence == 0, and whence values above 2 aren't generally considered.
So the patch is probably a bit less trivial than what you imagine :)
Author: Martin v. Löwis (loewis) *
Date: 2010-10-19 22:20
Am 19.10.2010 06:58, schrieb Raymond Hettinger:
Raymond Hettinger <rhettinger@users.sourceforge.net> added the comment:
Martin, any thoughts on adding a ZFS dependent feature? ISTM this Solaris feature hasn't taken hold elsewhere and it may be a mistake to immortalize it in Python.
There isn't any specific patch to review yet. However, Python has a long tradition of exposing all symbolic constants that users have asked for, and these are no different (e.g. how many systems support EX_SOFTWARE, or ENOTACTIVE). As long as it's just new constants, and as long as they are guarded with an ifdef, no approval is necessary for adding them.
Author: Raymond Hettinger (rhettinger) *
Date: 2010-10-21 01:16
Jesús, can you attach a patch (with the appropriate #ifdefs)?
Author: Jesús Cea Avión (jcea) *
Date: 2010-10-25 13:54
I attach patch. I have reviewed the IO module and I think we don't need to do any change there, since values over 2 are not touched.
The patch is trivial. My plan was to leave this patch for a novice :-).
Please, review. But let me do the final commit (I have commit privileges).
Author: Jesús Cea Avión (jcea) *
Date: 2010-10-25 13:57
[jcea@babylon5 py3k]$ ./python Python 3.2a3+ (py3k:85834M, Oct 25 2010, 15:37:04) [GCC 4.5.1] on sunos5 Type "help", "copyright", "credits" or "license" for more information.
import os os.SEEK_DATA 3 os.SEEK_HOLE 4
Author: Martin v. Löwis (loewis) *
Date: 2010-10-25 19:49
The patch lacks a documentation change. Otherwise, it looks fine.
Author: Antoine Pitrou (pitrou) *
Date: 2010-10-25 19:53
I think the docs should also make it clear that these flags are only supported by os.lseek() (unless you have tested the IO lib to work properly, that is, but in this case it would be nice to add unit tests).
Author: Jesús Cea Avión (jcea) *
Date: 2010-10-25 20:10
I will update documentation.
Antoine, it is difficult to write a testcase when I can only test under a system with ZFS. I don't think we have a buildbot with Solaris/*BSD and ZFS.
Any suggestion?.
Author: Antoine Pitrou (pitrou) *
Date: 2010-10-25 20:25
I will update documentation.
Antoine, it is difficult to write a testcase when I can only test under a system with ZFS. I don't think we have a buildbot with Solaris/*BSD and ZFS.
If you ascertain yourself that the test works under ZFS then I think it is enough. Of course, it would be better if a buildbot ran that test, but we can live without it (IMHO).
Author: Martin v. Löwis (loewis) *
Date: 2010-10-25 20:33
If you ascertain yourself that the test works under ZFS then I think it is enough. Of course, it would be better if a buildbot ran that test, but we can live without it (IMHO).
I agree. I trust that the patch is correct, and we really don't need to test whether ZFS works correctly (but trust that Oracle will).
Author: Jesús Cea Avión (jcea) *
Date: 2010-11-09 02:56
This is far more complicated that expected, because I would like to modify "file.seek()" to be able to support these flags too. Analizing "Modules/_io/bufferedio.c:buffered_seek()", the logic is pretty convoluted and the ramifications are extensible.
Should I limit myself to "os.lseek()"/"os.read()"/"os.write()"?. This flags are obscure, but useful enough to be useful even with this limitation.
Fut I don't feel comfy with this partial support.
Author: Jesús Cea Avión (jcea) *
Date: 2010-11-11 00:28
Please, review this. I had changed IO to support the new flags too. To do it, I must relax error control in IO, a bit.
So, the new flag are supported both in "os.lseek()" and in standard file objects.
Please, Antoine, could you review?.
I have checked the patch manually, but I can't think a way to automate it. We don't have any ZFS machine in buildbot.
I would love to commit this next week. Thanks for your time.
Author: Jesús Cea Avión (jcea) *
Date: 2010-11-11 00:39
"""
import os f=open("XX","w+b") f.seek(10241024) 1048576 f.write(b"hello") 5 f.seek(10241024*2) 2097152 f.write(b"bye") 3 f.seek(0,os.SEEK_HOLE) 0 f.seek(0,os.SEEK_DATA) 1048576 f.seek(1048576,os.SEEK_HOLE) 1179648 f.seek(1179648,os.SEEK_DATA) 2097152 f.seek(2097152,os.SEEK_HOLE) 2097155 fd=f.fileno() os.lseek(fd,0,os.SEEK_HOLE) 0 os.lseek(fd,0,os.SEEK_DATA) 1048576 os.lseek(fd,1048576,os.SEEK_HOLE) 1179648 os.lseek(fd,1179648,os.SEEK_DATA) 2097152 """
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *
Date: 2010-11-11 18:03
The patch modifies the _io module but not _pyio, why? (try f=_pyio.open("XX","w+b") at the beginning of the script above)
One test was removed, but nothing was added to test this new feature. This is the most likely way to lose it in future versions! An idea for the test is to do like the MockRawIO class in test_io.py, which "implements" a file but fakes all system calls, and can be wrapped in a BufferedReader.
The feature seems to be not applicable to text files, this should be tested.
Author: Jesús Cea Avión (jcea) *
Date: 2010-11-12 04:20
Amaury, thanks for your valuable feedback.
I forgot about the python implementation. I am not familiar with the new IO framework. Implemented now.
These new SEEK modes should not be used in text mode. In my new patch the modes are rejected in text mode, allowed in binary mode.
I have spend the last 3 hours studying "test_io.py", and I don't understand the Mock* usage. Your MockRawIO hint is valuable, but I can't think a way to test that C/Python implementation passes the new flags to the OS. If I understand correctly, any method implemented in the Mock will be hit instead of the IO implementation, and anything that reach IO implementation will not go back to the Mock. I don't understand... :-?. Or can you magically insert the Mock between the IO module and the OS?. I know something like this is happening, but I don't understand the mechanism.
How do you choose what Mock* are you using in each test?.
I have read about Mock testing in the past, but I don't understand the use here. Are they actually Mocks, as explained in http://agiletesting.blogspot.com/2009/07/python-mock-testing-techniques-and.html , for example?
Sorry.
Could you provide some hint?. Maybe in python-dev, for more audience?.
I have implemented a test "test_posix", if your OS can report holes in a file (so far modern Solaris/OpenSolaris/OpenIndiana, don't know about *bsd). Other OSs will ignore the test.
I know your time is valuable. Thanking for investing in me.
Author: Antoine Pitrou (pitrou) *
Date: 2011-02-23 01:31
Jesus, perhaps you can address Amaury's comments by uploading a new patch?
Author: Andreas Klauer (aklauer)
Date: 2012-03-20 21:59
ZFS supports SEEK_HOLE/SEEK_DATA in "lseek()" syscall. The feature has patches available too for Linux, but never integrated in mainline kernel, AFAIK. it is difficult to write a testcase when I can only test under a system with ZFS
I don't know if this could help, but recently Linux did get some commits regarding SEEK_HOLE/SEEK_DATA ( e.g. http://git.kernel.org/linus/982d816581eeeacfe5b2b7c6d47d13a157616eff ). I haven't tested whether it works / which filesystems support it. Grepping the Linux sources for SEEK_HOLES gives me several hits, e.g. for btrfs.
Author: STINNER Victor (vstinner) *
Date: 2012-03-20 22:24
- /* SEEK_SET and SEEK_CUR are special because we could seek inside the
buffer. Other whence values must be managed without this optimization.Some Operating Systems can provide additional values, likeSEEK_HOLE/SEEK_DATA. */- if (((whence == 0) || (whence == 1)) && self->readable) {
Why not using SEEK_SET and SEEK_CUR instead of 0 and 1 here?
.. versionadded:: 3.2
This is now outdated, it should be 3.3.
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-18 15:02
Victor, internally Python uses 0, 1 and 2 as wired values independently of the platform values. This is probably an historic accident.
Please, review.
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-20 10:41
I am going to integrate next week
Please, review.
Author: Terry J. Reedy (terry.reedy) *
Date: 2012-04-20 17:17
Is there a reason to say (several times) 'can support' instead of just 'support'? Do the OSes in question just optionally support rather than always support?
The first version added: change 'depend of' to 'depend on'.
In several functions you delete error checks:
if not (0 <= whence <= 2):raise ValueError("invalid whence value")
(or C equivalent). What happens with patch if invalid whence value is passed? Error from deeper in the call stack? Silently pass error, with no message?
Could import of io create set of valid_whences for system? Then check would be "if whence not in valid_whences:" (or C equivalent).
In 3.3, unittest has new mock submodule. Perhaps that would help testing.
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-20 17:30
Terry, yes, skiping the test in the code will raise an error anyway when doing the real "seek()" OS syscall.
Is there a reason to say (several times) 'can support' instead of just 'support'? Do the OSes in question just optionally support rather than always support?
Sometimes depends of the concrete filesystem used, or the concrete OS version.
The first version added: change 'depend of' to 'depend on'.
Done in my repository. Thanks.
Could import of io create set of valid_whences for system? Then check would be "if whence not in valid_whences:" (or C equivalent).
This is far from trivial and I don't see the point if OS "seek()" is going to give an error anyway. The only point would to provide a maybe more useful error message.
In 3.3, unittest has new mock submodule. Perhaps that would help testing.
This is a very thin layer over the OS.
Thanks for the feedback.
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *
Date: 2012-04-20 20:04
I don't see the point if OS "seek()" is going to give an error anyway. Please check that Windows won't crash the interpreter with bad 'whence' values, like it already does for closed file descriptors.
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-24 19:51
New version, addressing Amaury concerns and Neologix review.
Please, do a final review.
Author: Antoine Pitrou (pitrou) *
Date: 2012-04-24 19:57
- In test_posix.py: it's better to use the "with" statement when opening a file
- In Misc/NEWS: the entries should be kept in reverse chronological order
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-24 20:15
Another version, after Antoine feedback.
Please, review.
Author: Roundup Robot (python-dev) 
Date: 2012-04-26 14:39
New changeset 86dc014cdd74 by Jesus Cea in branch 'default': Close #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/86dc014cdd74
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2012-04-26 15:04
You broke test_io
www.python.org/dev/buildbot/all/builders/x86 Gentoo Non-Debug 3.x/builds/2143/steps/test/logs/stdio
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-26 15:08
Yes, backing out changeset.
Never suppose anything...
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-26 15:25
New patch proposed, with testsuite fixed.
Please, review. Last chance :-).
Author: Jesús Cea Avión (jcea) *
Date: 2012-04-26 17:57
New patch, after neologix@free.fr review.
Author: Hynek Schlawack (hynek) *
Date: 2012-04-30 14:13
In some cases you change "invalid" to "unsupported" when encountering an invalid/unsupported `whence' and in others you keep them on "invalid". I find it rather hard to really differentiate these two words in that context; care to shed a light and tell me the thought process behind that?
Author: Roundup Robot (python-dev)
Date: 2012-06-22 16:33
New changeset de2a0cb6ba52 by Jesus Cea in branch 'default': Closes #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/de2a0cb6ba52
Author: Stefan Krah (skrah) *
Date: 2012-06-22 21:41
Looks like the FreeBSD bot fails in test_posix:
====================================================================== ERROR: test_fs_holes (test.test_posix.PosixTester)
Traceback (most recent call last): File "/usr/home/buildbot/buildarea/3.x.krah-freebsd/build/Lib/test/test_posix.py", line 1033, in test_fs_holes self.assertEqual(i, os.lseek(fno, i, os.SEEK_DATA)) OSError: [Errno 25] Inappropriate ioctl for device
Ran 81 tests in 1.878s
Author: Roundup Robot (python-dev)
Date: 2012-06-23 00:56
New changeset 13f5a329d5ea by Jesus Cea in branch 'default': Kernel bug in freebsd9 - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/13f5a329d5ea
Author: Jesús Cea Avión (jcea) *
Date: 2012-06-23 00:56
This looks like a bug in freebsd:
http://lists.freebsd.org/pipermail/freebsd-amd64/2012-January/014332.html
Since looks like a kernel bug, skipping test in that case.
Committed patch.
Thanks for the head-up.
Author: Roundup Robot (python-dev)
Date: 2012-06-23 00:58
New changeset 8acaa341df53 by Jesus Cea in branch 'default': Skip the test only if neccesary - Kernel bug in freebsd9 - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/8acaa341df53
Author: Stefan Krah (skrah) *
Date: 2012-06-23 08:58
This looks like a bug in freebsd:
http://lists.freebsd.org/pipermail/freebsd-amd64/2012-January/014332.html
I tested that one already yesterday (it was late, so I forgot to mention it) and the test case attached to the bug report runs fine on the buildbot:
#include <unistd.h> #include <fcntl.h> #include <errno.h>
int main(void) { int fd = open("ccc.c", O_RDONLY); off_t offset=lseek(fd,0,SEEK_HOLE); if (offset==-1) { if (errno==ENXIO) { // No more data printf("no more data\n"); close(fd); exit(-1); } } return 0; }
The skip looks good to me though, I wouldn't be surprised if there is a kernel bug. This bug is still present on my machine:
http://www.freebsd.org/cgi/query-pr.cgi?pr=94729
Author: Stefan Krah (skrah) *
Date: 2012-06-23 09:19
int main(void) { int fd = open("ccc.c", O_RDONLY); off_t offset=lseek(fd,0,SEEK_HOLE); if (offset==-1) { if (errno==ENXIO) {
Darn, the errno in test_posix should be ENOTTY. Indeed, with ENOTTY the test case for the bug is positive.
Author: Georg Brandl (georg.brandl) *
Date: 2012-06-23 12:18
The test case is till failing for the freebsd7 buildbot:
Author: Georg Brandl (georg.brandl) *
Date: 2012-06-23 12:20
And the Ubuntu ARM buildbot.
Author: Roundup Robot (python-dev)
Date: 2012-06-25 11:46
New changeset 814557548af5 by Jesus Cea in branch 'default': Skip test in freebsd entirely - Kernel bug in freebsd7/8/9 - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/814557548af5
Author: Jesús Cea Avión (jcea) *
Date: 2012-06-25 11:55
Stefan, I am confused with your comments. The thing is that freebsd defines SEEK_HOLE/SEEK_DATA but reports an error when you use them. I guess they are errors when used on a filesystem that doesn't support them. This is a bug, in my opinion (if a FS doesn't support them, compatible implementation are trivial).
In the meantime, I am skipping the test completely under freebsd7/8/9. patch just committed.
Testing the patch, but freebsd7 buildbot is really SLOW.
Author: Jesús Cea Avión (jcea) *
Date: 2012-06-25 12:01
Greog, I am confused about ARM ubuntu errors. Do we know what ubuntu version is running there?. What is the filesystem?.
I am seriously thinking about supporting these flags only in "real" OSs like Solaris & derivatives :-)
Author: Georg Brandl (georg.brandl) *
Date: 2012-06-25 12:01
Jesus, what do you think about removing that test entirely?
IMO it is not our job to verify the OS' proper behavior in the face of SEEK_HOLE/SEEK_DATA; it is enough to provide the constants, and let whoever uses it face the perils of the platform.
Author: Jesús Cea Avión (jcea) *
Date: 2012-06-25 12:05
Georg, I am fine with that if you are fine with that :-). Please, confirm :)
(sorry for mistyping your name before!)
Author: Stefan Krah (skrah) *
Date: 2012-06-25 12:27
Jes??s Cea Avi??n <report@bugs.python.org> wrote:
Stefan, I am confused with your comments.
The FreeBSD bug report you linked to had a test case attached. The test case uses errno == ENXIO. I could not reproduce the failure, so in my first comment I questioned whether the failures in test_posix were caused by that particular bug.
Then I noticed that the test_posix traceback shows errno == 25 == ENOTTY. So I ran the test case with errno == ENOTTY and I could reproduce the bug.
In short, I think you linked to the right bug after all. :)
Author: Georg Brandl (georg.brandl) *
Date: 2012-06-25 16:03
As long as we have a test confirming that SEEK_HOLE/SEEK_DATA are accepted by the io module (which is a big part of the patch), it is fine.
E.g. calling seek() with the constants and check that it only raises OSError or nothing should work, right?
Author: Antoine Pitrou (pitrou) *
Date: 2012-07-06 21:39
Ping. The ARM buildbot still fails on test_fs_holes: http://buildbot.python.org/all/builders/ARM%20Ubuntu%203.x/builds/775/steps/test/logs/stdio
Author: Roundup Robot (python-dev)
Date: 2012-07-07 12:57
New changeset d69f95e57792 by Jesus Cea in branch 'default': Cope with OSs lying - #10142: Support for SEEK_HOLE/SEEK_DATA http://hg.python.org/cpython/rev/d69f95e57792
Author: Jesús Cea Avión (jcea) *
Date: 2012-07-07 12:58
Thanks for the head-up, Antoine.
History
Date
User
Action
Args
2022-04-11 14:57:07
admin
set
github: 54351
2012-10-05 02:25:10
jcea
set
status: open -> closed
2012-07-07 12:58:39
jcea
set
messages: +
2012-07-07 12:57:14
python-dev
set
messages: +
2012-07-06 21:39:30
pitrou
set
messages: +
2012-06-25 16:03:31
georg.brandl
set
messages: +
2012-06-25 12:27:08
skrah
set
messages: +
2012-06-25 12:05:11
jcea
set
messages: +
2012-06-25 12:01:46
georg.brandl
set
messages: +
2012-06-25 12:01:15
jcea
set
messages: +
2012-06-25 11:55:48
jcea
set
messages: +
2012-06-25 11:46:36
python-dev
set
messages: +
2012-06-24 07:34:23
hynek
set
nosy: - hynek
2012-06-23 12:20:28
georg.brandl
set
messages: +
2012-06-23 12🔞30
georg.brandl
set
status: closed -> open
nosy: + georg.brandl
messages: +
2012-06-23 09:19:30
skrah
set
messages: +
2012-06-23 08:58:34
skrah
set
messages: +
2012-06-23 00:58:49
python-dev
set
messages: +
2012-06-23 00:56:52
jcea
set
messages: +
2012-06-23 00:56:08
python-dev
set
messages: +
2012-06-22 21:41:24
skrah
set
nosy: + skrah
messages: +
2012-06-22 16:33:12
python-dev
set
status: open -> closed
resolution: fixed
messages: +
stage: patch review -> resolved
2012-04-30 14:13:31
hynek
set
nosy: + hynek
messages: +
2012-04-26 17:57:15
jcea
set
messages: +
2012-04-26 17:56:43
jcea
set
files: + c7abfb4d4260.diff
2012-04-26 15:25:53
jcea
set
messages: +
2012-04-26 15:25:17
jcea
set
files: + 6447a9323b11.diff
2012-04-26 15:08:49
jcea
set
status: closed -> open
resolution: fixed -> (no value)
messages: +
stage: resolved -> patch review
2012-04-26 15:04:11
benjamin.peterson
set
nosy: + benjamin.peterson
messages: +
2012-04-26 14:39:47
python-dev
set
status: open -> closed
nosy: + python-dev
messages: +
resolution: fixed
stage: patch review -> resolved
2012-04-24 20:15:46
jcea
set
messages: +
2012-04-24 20:15:25
jcea
set
files: + ad882ba08568.diff
2012-04-24 19:57:14
pitrou
set
messages: +
2012-04-24 19:51:01
jcea
set
messages: +
2012-04-24 19:48:03
jcea
set
files: + 0a5a40a4674a.diff
2012-04-24 19:38:07
jcea
set
files: - 34103049559f.diff
2012-04-24 19:37:09
jcea
set
files: + 34103049559f.diff
2012-04-20 20:04:50
amaury.forgeotdarc
set
messages: +
2012-04-20 17:30:42
jcea
set
messages: +
2012-04-20 17:17:10
terry.reedy
set
nosy: + terry.reedy
messages: +
2012-04-20 10:41:07
jcea
set
assignee: jcea
messages: +
2012-04-18 15:02:55
jcea
set
messages: +
stage: needs patch -> patch review
2012-04-18 15:00:36
jcea
set
files: + 3f967e00e267.diff
2012-04-18 15:00:08
jcea
set
files: - d6aeff63fa5e.diff
2012-04-18 14:54:03
jcea
set
files: + d6aeff63fa5e.diff
2012-04-18 14:52:54
jcea
set
files: - z.patch
2012-04-18 14:52:29
jcea
set
hgrepos: + hgrepo119
2012-03-21 09:10:09
kristjan.jonsson
set
nosy: - kristjan.jonsson
2012-03-20 22:24:57
vstinner
set
nosy: + vstinner
messages: +
2012-03-20 21:59:42
aklauer
set
nosy: + aklauer
messages: +
2011-02-23 01:31:21
pitrou
set
assignee: amaury.forgeotdarc -> (no value)
messages: +
nosy:loewis, rhettinger, jcea, amaury.forgeotdarc, pitrou, kristjan.jonsson
stage: commit review -> needs patch
2011-02-23 01:28:54
jcea
set
keywords: + patch, easy, - buildbot
assignee: kristjan.jonsson -> amaury.forgeotdarc
nosy: + amaury.forgeotdarc
2011-02-23 01:17:20
jcea
set
keywords: + buildbot, - patch, easy
assignee: amaury.forgeotdarc -> kristjan.jonsson
versions: + Python 3.3, - Python 3.2
nosy: + kristjan.jonsson, - amaury.forgeotdarc
2010-11-12 04:20:39
jcea
set
assignee: pitrou -> amaury.forgeotdarc
2010-11-12 04:20:21
jcea
set
messages: +
2010-11-11 18:03:18
amaury.forgeotdarc
set
nosy: + amaury.forgeotdarc
messages: +
2010-11-11 00:39:13
jcea
set
messages: +
2010-11-11 00:28:26
jcea
set
files: + z.patch
assignee: loewis -> pitrou
messages: +
keywords: + patch
2010-11-11 00:23:01
jcea
set
files: - z
2010-11-09 02:56:16
jcea
set
messages: +
2010-10-25 20:33:50
loewis
set
messages: +
2010-10-25 20:25:00
pitrou
set
messages: +
2010-10-25 20:10:33
jcea
set
messages: +
2010-10-25 19:53:55
pitrou
set
messages: +
2010-10-25 19:49:32
loewis
set
messages: +
2010-10-25 13:57:48
jcea
set
messages: +
2010-10-25 13:54:29
jcea
set
files: + z
messages: +
stage: needs patch -> commit review
2010-10-21 01:16:57
rhettinger
set
messages: +
2010-10-19 22:20:48
loewis
set
messages: +
2010-10-19 10:44:04
pitrou
set
nosy: + pitrou
messages: +
2010-10-19 10:37:41
jcea
set
messages: +
2010-10-19 04:58:08
rhettinger
set
assignee: loewis
messages: +
nosy: + rhettinger, loewis
2010-10-19 03:31:41
jcea
set
stage: needs patch
2010-10-19 03:16:36
jcea
set
components: + Library (Lib), IO
2010-10-19 03:15:16
jcea
create