Issue17237
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2013-02-19 14:31 by alanh, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
ascii_decode_nonaligned.patch | serhiy.storchaka, 2013-05-10 18:41 | review | ||
python3.3_3.3.1-1+m68k.1.debdiff | mirabilos, 2013-05-10 21:46 |
Messages (49) | |||
---|---|---|---|
msg182381 - (view) | Author: Alan Hourihane (alanh) | Date: 2013-02-19 14:31 | |
On m68k this assert triggers in Python/unicodeobject.c:4658 because m68k architectures can align on 16bit boundaries. assert(!((size_t) dest & LONG_PTR_MASK)); I'm not sure of the wider implications in Python as to how to rectify. |
|||
msg182382 - (view) | Author: Christian Heimes (christian.heimes) * | Date: 2013-02-19 14:36 | |
We don't have a m86k test box and I don't think we support this platform either. |
|||
msg182387 - (view) | Author: Alan Hourihane (alanh) | Date: 2013-02-19 14:59 | |
I'm willing to help fix, but there are m68k emulators out there which I guess suffice for a test box. |
|||
msg182388 - (view) | Author: Stefan Krah (skrah) * | Date: 2013-02-19 15:06 | |
TBH, I don't think we should support this platform officially. Is that processor still in use (e.g. in embedded systems)? |
|||
msg182389 - (view) | Author: Ramchandra Apte (Ramchandra Apte) * | Date: 2013-02-19 15:09 | |
Wikipedia says "derivative processors are still widely used in embedded applications." in m68k article. |
|||
msg182390 - (view) | Author: Jesús Cea Avión (jcea) * | Date: 2013-02-19 15:15 | |
Freescale (ex-Motorola) ColdFire architecture is alive and doing well. And I know people still running Motorola 68040 Apple machines. The problem is not a m68k emulator, but to build all the needed environment on it: OS, compilers, network, etc. If the original submitter is willing to help... |
|||
msg182410 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-02-19 19:44 | |
Which branch or version of Python is that? |
|||
msg182417 - (view) | Author: Alan Hourihane (alanh) | Date: 2013-02-19 19:52 | |
As mention in the versions. It is Python 3.3.0. |
|||
msg182421 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-02-19 19:57 | |
Ok, could you post the whole C stack trace? (using e.g. gdb) By the way, this is not about the alignment of m68k architectures: x86 can align on a byte boundary and doesn't trigger the assert. |
|||
msg182428 - (view) | Author: Alan Hourihane (alanh) | Date: 2013-02-19 20:54 | |
It must be about pointer alignment, because that's the whole point of the ASSERT. As for the backtrace, the gdb support on the platform isn't great yet, but here it is.... Breakpoint 1, ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", dest=0x1a6d592 "�������") at Objects/unicodeobject.c:4658 4658 assert(!((size_t) dest & LONG_PTR_MASK)); (gdb) bt #0 ascii_decode (start=0x30c5b04 "__len__", end=0x30c5b0b "", dest=0x1a6d592 "�������") at Objects/unicodeobject.c:4658 #1 0x030595a6 in .L4737 () at Objects/unicodeobject.c:4741 #2 0x03044dba in .L2648 () at Objects/unicodeobject.c:1806 #3 0x03096f54 in PyUnicode_InternFromString (cp=0x30c5b04 "__len__") at Objects/unicodeobject.c:14284 #4 0x030c69f6 in .L1892 () at Objects/typeobject.c:6090 #5 0x030c6dc8 in add_operators (type=0x33507c8) at Objects/typeobject.c:6244 #6 0x030bfc66 in .L1249 () at Objects/typeobject.c:4182 #7 0x030bfbae in .L1241 () at Objects/typeobject.c:4146 #8 0x02ff62a8 in _Py_ReadyTypes () at Objects/object.c:1576 #9 0x0300e688 in .L60 () at Python/pythonrun.c:301 #10 0x0300ea5c in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:401 #11 0x0300ea6e in Py_Initialize () at Python/pythonrun.c:407 #12 0x02ff9fca in .L135 () at Modules/main.c:657 #13 0x02ff24be in .L6 () at ./Modules/python.c:90 #14 0x03329d5a in .L76 () #15 0x0331731e in .L69 () |
|||
msg182429 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-02-19 20:56 | |
What will happened if you just remove this line? |
|||
msg182430 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-02-19 21:02 | |
> It must be about pointer alignment, because that's the whole point of > the ASSERT. Indeed, it's about pointer alignment, but it's not about the CPU. It's about the compiler (or the platform's C ABI). Apparently the compiler doesn't align struct fields to natural boundaries like most other compilers do, which means the size of the PyASCIIObject struct (in unicodeobject.h) ends up not being a multiple of 4, which in turn means the "dest" pointer (allocated from the end of that structure) is not 4 byte-aligned either. However, you can probably safely remove the assert(), since it is there to warn about misalignment on platforms which *are* alignment-sensitive. There is another assert() of the same kind in unicodeobject.c, which you can remove too. It would be nice if the C source could be improved here, but it's not obvious which rule to enforce exactly. We want to be lenient if the misalignment is a product of the compiler's alignment rules, but not if it's a mistake on our part. Which compiler is it? |
|||
msg182431 - (view) | Author: Alan Hourihane (alanh) | Date: 2013-02-19 21:05 | |
It's GCC 4.6.3. GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used. |
|||
msg182433 - (view) | Author: Alan Hourihane (alanh) | Date: 2013-02-19 21:07 | |
Oh, and as for pointer alignment, I probably just wasn't clear in the initial report. But we agree on m68k C ABI. |
|||
msg182434 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-02-19 21:20 | |
Ok, so we could simply disable the assert on m68k, if you can confirm it works. Do you want to provide a patch? I don't know what the preprocessor conditional should look like. |
|||
msg182435 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-02-19 21:36 | |
Perhaps we should disable not only assert, but all optimized code inside #if SIZEOF_LONG <= SIZEOF_VOID_P / #endif block. Benchmarks needed to measure either unaligned writing speedup or slowdown decoding. |
|||
msg182436 - (view) | Author: mirabilos (mirabilos) | Date: 2013-02-19 21:45 | |
@skrah: “I don't think we should support this platform officially.” Please don’t break what works. We have almost complete (about three quarters of roughly 10'000 source packages) Debian unstable working on m68k, with several versions of Python in use. Thanks! @pitrou: “x86 can align on a byte boundary and doesn't trigger the assert.” That’s because most compilers on i386 do “natural alignment” – in fact, most compilers on most platforms do. “natural alignment” means 4-byte quantities get aligned on 4-byte boundaries, 8-byte quantities on 8-byte boundaries, etc. On m68k, the lowest alignment for almost all larger-than-a-byte data types is 2 byte, even though that one is strict. This means that, for example, an int is often only 2-byte aligned. @alanh: “GCC has the -malign-int but mentions this isn't in best interest of m68k ABI compatibility if it's used.” Indeed, because that would break the C and kernel/syscall ABI. @all: what _precisely_ is the assertion needed to check for? @pitrou: “since it is there to warn about misalignment on platforms which *are* alignment-sensitive” Well, m68k is. Just the numbers differ. (It also has int, long and pointer at 32 bit.) We had a similar issue in the Linux kernel, where it used the lower two bits of an address for flags (urgh…) which could only be solved by using GCC’s __attribute__((__aligned__(4))) on the quantities in question, but that may or may not be the required case here, which is why I’m asking. I can test any trees on my VMs, but that takes a day or two, of course, at 50-200 BogoMIPS. You can do that yourself by running a VM as well, the Debian Wiki has instructions, if anyone is interested. Otherwise, it’ll just get tested as soon as it hits Debian (unstable, usually we don’t build experimental packages except on explicit request by the packagers, due to lack of time / horsepower)… Thanks doko for linking this issue! |
|||
msg182438 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-02-19 22:00 | |
> We had a similar issue in the Linux kernel, where it used the lower > two bits of an address for flags (urgh…) which could only be solved by > using GCC’s __attribute__((__aligned__(4))) on the quantities in > question, but that may or may not be the required case here, which is > why I’m asking. It is not required since, as you say, m68k only requires 2-byte alignment. However, as Serhiy said, it may (or may not) be better for performance. At this point, only people with access to a m68k machine or VM (and motivated enough :-)) can do the necessary tests and propose a way forward. (but, performance notwithstanding, fixing the build should be a simple matter of silencing the assert with an appropriate #if line) |
|||
msg182439 - (view) | Author: Stefan Krah (skrah) * | Date: 2013-02-19 22:01 | |
mirabilos <report@bugs.python.org> wrote: > Please dont break what works. We have almost complete (about three quarters > of roughly 10'000 source packages) Debian unstable working on m68k, with > several versions of Python in use. Thanks! Are you saying that the complete test suite works on m68k except for this assert? |
|||
msg182441 - (view) | Author: mirabilos (mirabilos) | Date: 2013-02-19 22:05 | |
@pitrou: As for performance, 2-byte and 4-byte are the same on m68k, given that they usually have RAM which doesn’t benefit from that kind of alignment, and systems that are structured accordingly. The “best” cpp define I don’t know, but my system defines __m68k__ and Alan would probably be able to say whether this is defined on ColdFire, too. @skrah: No, I specifically did not say that ☺ But it works pretty damn well. |
|||
msg182531 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-02-20 16:56 | |
mirabilos, if you are motivated enough, do the following. Compile two Python executables - one with deleted assert, and second with deleted a block between "#if SIZEOF_LONG <= SIZEOF_VOID_P" and "#endif". Run following microbenchmarks for both executables: ./python -m timeit -s "x=b'A'*10000" "x.decode('ascii')" ./python -m timeit -s "x=b'A'*10000" "x.decode('utf-8')" |
|||
msg182545 - (view) | Author: mirabilos (mirabilos) | Date: 2013-02-20 19:48 | |
Serhiy Storchaka dixit: >mirabilos, if you are motivated enough, do the following. Compile two >Python executables - one with deleted assert, and second with deleted >a block between "#if SIZEOF_LONG <= SIZEOF_VOID_P" and "#endif". Run >following microbenchmarks for both executables: > >./python -m timeit -s "x=b'A'*10000" "x.decode('ascii')" >./python -m timeit -s "x=b'A'*10000" "x.decode('utf-8')" > >---------- > >_______________________________________ >Python tracker <report@bugs.python.org> ><http://bugs.python.org/issue17237> >_______________________________________ Thanks, will actually do that, just not before the weekend, dayjob’s keeping me busy, and I need to be careful to not burn out myself in the evening too. Which tree should I build? A release (if so, which)? Or some CVS branch? Do note we clock at roughly 1000 pystones for the fastest machines… yes 1000 not 10000. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh |
|||
msg182551 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-02-20 20:44 | |
> Which tree should I build? A release (if so, which)? Or > some CVS branch? It doesn't matter. > Do note we clock at roughly 1000 pystones for the fastest > machines… yes 1000 not 10000. It doesn't matter. Only relative values have a meaning. What is faster and on how many percent. |
|||
msg182552 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-02-20 20:46 | |
And of course run the tests on non-debug builds. |
|||
msg182561 - (view) | Author: mirabilos (mirabilos) | Date: 2013-02-20 22:00 | |
Serhiy Storchaka dixit: >> Which tree should I build? A release (if so, which)? Or >> some CVS branch? > >It doesn't matter. Erm, still, which one do I build? Not 3.2 because it obviously works, at least as packaged in Debian. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec |
|||
msg182590 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-02-21 12:27 | |
> Erm, still, which one do I build? Not 3.2 because it obviously > works, at least as packaged in Debian. Any >= 3.3.0. |
|||
msg188822 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-10 09:35 | |
Hi again, sorry for being a bit late in following up to this. Here are the results for the two runs you requested; these were done on the same machine, intermixed (the first one cache-clean, the second and third run subsequently (so that the third run is cache-filled)). I used static builds. For the “without assert”, I get approximately 570 usec per loop consistently: (590,580), (570,570), (560,580), (570,560) Interestingly enough, there seems to be no preference either way (ASCII or UTF-8). For the “without the whole if‥endif block”, I get mixed results: (650,540), (690,530), (520,530), (650,540) Interesting here is that the third run of them both has a lower ASCII than UTF-8 time, the others don’t – but the UTF-8 run is the second in a row, so cache might be of an issue. Repeating the runs, I get (560,590), (540,530) for the second case, and (760,570), (590,660) for the first case breaking its “consistently 570 usec” streak. Error of measurement may be large, thus. Which supports your suspicion that the optimised case may not be needed at all. Matthias asked me to provide links how to set up an Atari VM with Debian unstable and a clean/minimal unstable chroot, since there’s much use of Ubuntu here who ship ARAnyM (I even filed a Sync Request so that the latest release got a fixed version ☺). https://wiki.debian.org/Aranym/Quick#download has got pointers for the first part (setting up an ARAnyM VM), and https://wiki.debian.org/M68k/Installing contains the whole documentation (we cannot currently use d-i but people are working on it). http://people.debian.org/~tg/f/20121227/m68k-buildd.tgz is the output of “debootstrap --variant=buildd” and as such should be usable in either cowbuilder or sbuild. Considering that we *only* have unstable available, you may want to be careful when upgrading ;) but an apt-get update should work out of the box (takes a few minutes). The VMs have 768+14 MiB RAM each in the sample configuration (maxed out), which makes them use a bit less than 1 GiB on the host side. A 3 GHz host CPU is of benefit. |
|||
msg188829 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-10 12:18 | |
> Which supports your suspicion that the optimised case may not be needed > at all. So we can just skip the assert when __m68k__ is defined? |
|||
msg188830 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-05-10 12:26 | |
Could you please repeat the tests with a larger data (1MB or more)? |
|||
msg188847 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-10 16:28 | |
Antoine: precisely. Serhiy: sure. The times are now in msec per loop. I did three subsequent runs, so the second and third tuple are cache-warm. Without assert: (89,88), (87,87), (89,86) Without block : (79,78), (78,78), (79,78) And in a second run: Without assert: (87,88), (87,88), (92,87) Without block : (111,91), (78,85), (79,79) This means that, again, removing the “optimised” code speeds up operations (on this particular slow architecture. |
|||
msg188864 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-05-10 18:41 | |
Well, it will be safer to skip this block on such platforms. |
|||
msg188877 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-10 20:26 | |
file30203/ascii_decode_nonaligned.patch is potentially a nop (the struct being a multiple of, in the m68k case 4, bytes is not an indicator of whether to skip it). I think we can be bold and put #if !defined(__m68k__) and #endif around the entire block and, should there ever be another architecture with similar issues, whitelist them there. |
|||
msg188878 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-10 20:36 | |
> I think we can be bold and put #if !defined(__m68k__) and #endif > around the entire block and, should there ever be another architecture > with similar issues, whitelist them there. Agreed. |
|||
msg188879 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-05-10 20:42 | |
What is sizeof(PyASCIIObject) on m68k? |
|||
msg188880 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-10 20:54 | |
Currently 22; it will increase to 24 if a few more bits are added. That’s why I said it’s “fragile” magic. |
|||
msg188884 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-10 21:46 | |
I’m currently thinking this patch. (Will need another day or so for compiles to finish, though.) |
|||
msg188885 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-10 21:55 | |
+ dest is always aligned on common platforms + (if sizeof(PyASCIIObject) is divisible by SIZEOF_LONG). Actually, that’s the part that is not true. On m68k, and perfectly permitted by the C standard, even a 24-byte object has only a guaranteed alignment of 2 bytes (or one, if it’s a char array) in the normal case (contains integers and pointers, nothing special). We patched out this bogus assumption from things like glib already ;) |
|||
msg188915 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-05-11 12:55 | |
PyASCIIObject is allocated on heap and should have a maximal alignment enough for every type. If sizeof(PyASCIIObject) % SIZEOF_LONG == 0 then dest is at least long-aligned. Currently sizeof(PyASCIIObject) is 22 on m68k and the optimization is switched off at compile time. When PyASCIIObject will grow to 24 bytes the optimization will switched on and perhaps will have some effect. I prefer checks for features instead of concrete names. |
|||
msg188916 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-11 12:58 | |
> PyASCIIObject is allocated on heap and should have a maximal alignment > enough for every type. If sizeof(PyASCIIObject) % SIZEOF_LONG == 0 > then dest is at least long-aligned. Currently sizeof(PyASCIIObject) is > 22 on m68k and the optimization is switched off at compile time. When > PyASCIIObject will grow to 24 bytes the optimization will switched on > and perhaps will have some effect. I prefer checks for features > instead of concrete names. This is a bugfix, please let's keep it simple. Checking for __m68k__ ensures that other architectures aren't affected by mistake. |
|||
msg188917 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-11 13:08 | |
Right, keeping it simple helps in preventing accidents, and the code block looks full of magic enough as-is. Maybe add a comment block that says: /* * m68k is a bit different from most architectures in that objects * do not use "natural alignment" - for example, int and long are * only aligned at 2-byte boundaries. Tests have shown that skipping * the "optimised version" will even speed up m68k, so we #ifdef * for "the odd duck out" here. */ Then we have an in-situ documentation point for why that ifdef is there and why m68k is “the odd duck” and this whitelist method is used. |
|||
msg188919 - (view) | Author: Serhiy Storchaka (serhiy.storchaka) * | Date: 2013-05-11 13:23 | |
Well, then already too much bikeshedding for such simple fix. Antoine, do you want to commit a fix? |
|||
msg188922 - (view) | Author: Roundup Robot (python-dev) | Date: 2013-05-11 13:59 | |
New changeset 0f8022ac88ad by Antoine Pitrou in branch '3.3': Issue #17237: Fix crash in the ASCII decoder on m68k. http://hg.python.org/cpython/rev/0f8022ac88ad New changeset 201ae2d02328 by Antoine Pitrou in branch 'default': Issue #17237: Fix crash in the ASCII decoder on m68k. http://hg.python.org/cpython/rev/201ae2d02328 |
|||
msg188923 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-11 14:19 | |
Ok, I hope I got the fix right :) Thanks mirabilos for the comment suggestion, I used a modified version. |
|||
msg188925 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-11 14:32 | |
Thanks Antoine! Now, for “finishing up” this… to follow up on Stefan’s comment… is there any way I can run the testsuite from an installed Python (from the Debian packages)? (I build the packages with disabled testsuite, to get the rest of the system running again, since python3.3 was recently made required and we had never built it before.) Otherwise I guess I could run “make test” on one of the earlier trees I used for the timing… but that machine is currently building six Linux kernel flavours from the src:linux package and thus will not be available for the next one and a half week or so… |
|||
msg188926 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-11 14:38 | |
> Now, for “finishing up” this… to follow up on Stefan’s comment… is > there any way I can run the testsuite from an installed Python (from > the Debian packages)? "python -m test" (with any options you might like), but we don't guarantee that all tests pass on an installed Python. But at least you will be able to spot any hard crashes :-) |
|||
msg188927 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-11 14:57 | |
Antoine Pitrou dixit: >"python -m test" (with any options you might like), but we don't No, I tried that (as it was the only thing I could find on the ’net as well) on an i386 system and only get: tglase@tglase:~ $ python2.7 -m test /usr/bin/python2.7: No module named test.__main__; 'test' is a package and cannot be directly executed 1|tglase@tglase:~ $ python3.2 -m test /usr/bin/python3.2: No module named test.__main__; 'test' is a package and cannot be directly executed Same when adding ‘-h’. bye, //mirabilos -- Gast: „Ein Bier, bitte!“ Wirt: „Geht auch alkoholfrei?“ Gast: „Geht auch Spielgeld?“ |
|||
msg188928 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-11 15:00 | |
> >"python -m test" (with any options you might like), but we don't > > No, I tried that (as it was the only thing I could find on the > ’net as well) on an i386 system and only get: Ah, that's because the system Python install doesn't include the test suite. Perhaps you have to install an additional package, python-dev perhaps? (note, on 2.7, it's "python -m test.regrtest") |
|||
msg188929 - (view) | Author: mirabilos (mirabilos) | Date: 2013-05-11 15:13 | |
Antoine Pitrou dixit: >(note, on 2.7, it's "python -m test.regrtest") That indeed does things. So I had mistaken them for the same problem. >Ah, that's because the system Python install doesn't include the test >suite. Perhaps you have to install an additional package, python-dev >perhaps? tglase@tglase:~ $ l /usr/lib/python2.7/test/ __init__.py pystone.py* regrtest.py* test_support.py __init__.pyc pystone.pyc regrtest.pyc test_support.pyc tglase@tglase:~ $ l /usr/lib/python3.2/test/ __init__.py __pycache__/ pystone.py* regrtest.py* support.py Maybe it’s just not packaged… these are all I can find, and installing python3.2-dev doesn’t fix it. Oh well, then it’ll just have to wait. Do you have a preferred place where I can submit the test results, as it’s getting very off-topic here? bye, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999 |
|||
msg188930 - (view) | Author: Antoine Pitrou (pitrou) * | Date: 2013-05-11 15:16 | |
> Oh well, then it’ll just have to wait. Do you have a preferred > place where I can submit the test results, as it’s getting > very off-topic here? Well, if everything works fine, you don't have to submit them! If you get test failures, you can open issues for the individual test failures. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-11 14:57:41 | admin | set | github: 61439 |
2018-06-19 19:19:55 | serhiy.storchaka | set | pull_requests: - pull_request7408 |
2018-06-19 18:36:49 | methane | set | pull_requests: + pull_request7408 |
2013-05-11 15:16:06 | pitrou | set | messages: + msg188930 |
2013-05-11 15:13:52 | mirabilos | set | messages: + msg188929 |
2013-05-11 15:00:41 | pitrou | set | messages: + msg188928 |
2013-05-11 14:57:31 | mirabilos | set | messages: + msg188927 |
2013-05-11 14:38:48 | pitrou | set | messages: + msg188926 |
2013-05-11 14:32:47 | mirabilos | set | messages: + msg188925 |
2013-05-11 14:19:13 | pitrou | set | status: open -> closed resolution: fixed messages: + msg188923 stage: needs patch -> resolved |
2013-05-11 13:59:51 | python-dev | set | nosy:
+ python-dev messages: + msg188922 |
2013-05-11 13:23:23 | serhiy.storchaka | set | messages: + msg188919 |
2013-05-11 13:08:16 | mirabilos | set | messages: + msg188917 |
2013-05-11 12:58:28 | pitrou | set | messages: + msg188916 |
2013-05-11 12:55:21 | serhiy.storchaka | set | messages: + msg188915 |
2013-05-10 21:55:41 | mirabilos | set | messages: + msg188885 |
2013-05-10 21:46:54 | mirabilos | set | files:
+ python3.3_3.3.1-1+m68k.1.debdiff messages: + msg188884 |
2013-05-10 20:54:52 | mirabilos | set | messages: + msg188880 |
2013-05-10 20:42:44 | serhiy.storchaka | set | messages: + msg188879 |
2013-05-10 20:36:29 | pitrou | set | messages: + msg188878 |
2013-05-10 20:26:04 | mirabilos | set | messages: + msg188877 |
2013-05-10 18:41:12 | serhiy.storchaka | set | files:
+ ascii_decode_nonaligned.patch keywords: + patch messages: + msg188864 |
2013-05-10 16:28:57 | mirabilos | set | messages: + msg188847 |
2013-05-10 12:26:20 | serhiy.storchaka | set | messages: + msg188830 |
2013-05-10 12:18:37 | pitrou | set | messages: + msg188829 |
2013-05-10 09:35:00 | mirabilos | set | messages: + msg188822 |
2013-02-21 12:27:31 | serhiy.storchaka | set | messages: + msg182590 |
2013-02-20 22:00:28 | mirabilos | set | messages: + msg182561 |
2013-02-20 20:46:15 | serhiy.storchaka | set | messages: + msg182552 |
2013-02-20 20:44:12 | serhiy.storchaka | set | messages: + msg182551 |
2013-02-20 19:48:27 | mirabilos | set | messages: + msg182545 |
2013-02-20 16:56:34 | serhiy.storchaka | set | messages: + msg182531 |
2013-02-19 22:05:49 | mirabilos | set | messages: + msg182441 |
2013-02-19 22:01:01 | skrah | set | messages: + msg182439 |
2013-02-19 22:00:04 | pitrou | set | messages: + msg182438 |
2013-02-19 21:45:35 | mirabilos | set | nosy:
+ mirabilos messages: + msg182436 |
2013-02-19 21:36:37 | serhiy.storchaka | set | messages: + msg182435 |
2013-02-19 21:20:09 | pitrou | set | versions:
+ Python 3.4 messages: + msg182434 components: + Interpreter Core, - Build type: crash stage: needs patch |
2013-02-19 21:08:00 | alanh | set | messages: + msg182433 |
2013-02-19 21:05:05 | alanh | set | type: crash -> (no value) messages: + msg182431 components: + Build, - Unicode versions: - Python 3.4 |
2013-02-19 21:02:21 | pitrou | set | messages: + msg182430 |
2013-02-19 20:57:28 | serhiy.storchaka | set | nosy:
+ ezio.melotti components: + Unicode, - Build versions: + Python 3.4 |
2013-02-19 20:56:54 | serhiy.storchaka | set | type: crash messages: + msg182429 nosy: + serhiy.storchaka |
2013-02-19 20:54:55 | alanh | set | messages: + msg182428 |
2013-02-19 19:57:07 | pitrou | set | messages: + msg182421 |
2013-02-19 19:52:00 | alanh | set | messages: + msg182417 |
2013-02-19 19:44:08 | pitrou | set | nosy:
+ pitrou messages: + msg182410 |
2013-02-19 15:15:12 | jcea | set | nosy:
+ jcea messages: + msg182390 |
2013-02-19 15:09:15 | Ramchandra Apte | set | nosy:
+ Ramchandra Apte messages: + msg182389 |
2013-02-19 15:06:01 | skrah | set | nosy:
+ skrah messages: + msg182388 |
2013-02-19 14:59:24 | alanh | set | messages: + msg182387 |
2013-02-19 14:36:04 | christian.heimes | set | nosy:
+ christian.heimes, trent messages: + msg182382 |
2013-02-19 14:31:48 | alanh | create |