* HEADSUP: Python 2.7 upgrade
@ 2013-01-24 0:57 Yaakov
2013-01-24 5:49 ` marco atzeri
` (22 more replies)
0 siblings, 23 replies; 47+ messages in thread
From: Yaakov @ 2013-01-24 0:57 UTC (permalink / raw)
To: cygwin-apps
Jason Tishler announced last month[1] that he intends to upgrade Python
to 2.7 on 01 February, which is quickly approaching.
If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
In order to assure a prompt and smooth transition to Python 2.7, the
following packages will need a rebuild/update:
Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
pylint, python-crypto, python-feedparser, python-logilab-astng,
python-logilab-common, python-paramiko, spambayes, stgit, tailor,
urlgrabber
Marco Atzeri: postgresql
Ken Brown: bzr-fastimport, python-fastimport
Jan Nieuwenhuizen: lilypond
Bo Peng: lyx
David Rothenberger: rdiff-backup, subversion
Chris Sutcliffe: googlecl, python-gdata
Samuel Thibault: brltty, python-pyrex
Dr. Volker Zell: lcms, ming
TIA,
Yaakov
[1] http://cygwin.com/ml/cygwin-announce/2012-12/msg00024.html
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
@ 2013-01-24 5:49 ` marco atzeri
2013-01-24 9:39 ` Corinna Vinschen
2013-01-24 12:29 ` Chris Sutcliffe
` (21 subsequent siblings)
22 siblings, 1 reply; 47+ messages in thread
From: marco atzeri @ 2013-01-24 5:49 UTC (permalink / raw)
To: cygwin-apps
On 1/24/2013 1:56 AM, Yaakov (Cygwin/X) wrote:
> Jason Tishler announced last month[1] that he intends to upgrade Python
> to 2.7 on 01 February, which is quickly approaching.
>
> If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
>
> ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
>
> In order to assure a prompt and smooth transition to Python 2.7, the
> following packages will need a rebuild/update:
>
> Marco Atzeri: postgresql
postgresql upgrade is blocked by a rebase/objcopy issue
http://cygwin.com/ml/cygwin/2013-01/msg00199.html
also patching cygport to use
"--long-section-names enable" together with "--add-gnu-debuglink"
one of the dll "dict_snowball-dll" causes rebase to segfault
I am not sure if it is objcopy creating a bugged debuglink dll,
or it is rebase incorrectly choking on it.
As workaround, I can release 9.2.2 without debug symbols,
but I will prefer that we understand ,possibly solve,
the issue before.
>
> TIA,
>
>
> Yaakov
>
> [1] http://cygwin.com/ml/cygwin-announce/2012-12/msg00024.html
>
Regards
Marco
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 5:49 ` marco atzeri
@ 2013-01-24 9:39 ` Corinna Vinschen
2013-01-24 10:41 ` marco atzeri
0 siblings, 1 reply; 47+ messages in thread
From: Corinna Vinschen @ 2013-01-24 9:39 UTC (permalink / raw)
To: cygwin-apps
On Jan 24 06:49, marco atzeri wrote:
> On 1/24/2013 1:56 AM, Yaakov (Cygwin/X) wrote:
> >Jason Tishler announced last month[1] that he intends to upgrade Python
> >to 2.7 on 01 February, which is quickly approaching.
> >
> >If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
> >
> >ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
> >
> >In order to assure a prompt and smooth transition to Python 2.7, the
> >following packages will need a rebuild/update:
> >
>
> >Marco Atzeri: postgresql
>
> postgresql upgrade is blocked by a rebase/objcopy issue
>
> http://cygwin.com/ml/cygwin/2013-01/msg00199.html
>
> also patching cygport to use
> "--long-section-names enable" together with "--add-gnu-debuglink"
>
> one of the dll "dict_snowball-dll" causes rebase to segfault
>
> I am not sure if it is objcopy creating a bugged debuglink dll,
> or it is rebase incorrectly choking on it.
I debugged this last week, and I don't see how this could be a rebase
bug. The layout of the relocation information is basically an array
of relocation blocks, like this:
.reloc section
block1
header
base offset
sizeof following array
array of 2 byte values with:
4 bit relocation type
12 bit offset from base offset
block2
[...]
The size of the .reloc section in the file header does not indicate how
long the relocation information in the section actually is. Usually the
section is larger than the actual relocation info. The end of the
relocation info is indicated by a block header with a base offset of 0
and a sizeof of 0, let's call it the NULL block.
What I could reproduce using Marco's ltree.dll example was this:
After adding the .gnu_debuglink section, the former NULL block suddenly
contained some seemingly random values. So rebase rightfully assumed
that another relocation block is following. So it happily tried further
to relocate the file, until the address falls outside of the allocated
memory block, which resulted in the SEGV.
To me this indicates a bug in objcopy.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 9:39 ` Corinna Vinschen
@ 2013-01-24 10:41 ` marco atzeri
2013-01-24 12:30 ` Corinna Vinschen
0 siblings, 1 reply; 47+ messages in thread
From: marco atzeri @ 2013-01-24 10:41 UTC (permalink / raw)
To: cygwin-apps
On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
> On Jan 24 06:49, marco atzeri wrote:
>> On 1/24/2013 1:56 AM, Yaakov (Cygwin/X) wrote:
>>> Jason Tishler announced last month[1] that he intends to upgrade Python
>>> to 2.7 on 01 February, which is quickly approaching.
>>>
>>> If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
>>>
>>> ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
>>>
>>> In order to assure a prompt and smooth transition to Python 2.7, the
>>> following packages will need a rebuild/update:
>>>
>>
>>> Marco Atzeri: postgresql
>>
>> postgresql upgrade is blocked by a rebase/objcopy issue
>>
>> http://cygwin.com/ml/cygwin/2013-01/msg00199.html
>>
>> also patching cygport to use
>> "--long-section-names enable" together with "--add-gnu-debuglink"
>>
>> one of the dll "dict_snowball-dll" causes rebase to segfault
>>
>> I am not sure if it is objcopy creating a bugged debuglink dll,
>> or it is rebase incorrectly choking on it.
>
> I debugged this last week, and I don't see how this could be a rebase
> bug. The layout of the relocation information is basically an array
> of relocation blocks, like this:
>
> .reloc section
> block1
> header
> base offset
> sizeof following array
> array of 2 byte values with:
> 4 bit relocation type
> 12 bit offset from base offset
> block2
> [...]
>
> The size of the .reloc section in the file header does not indicate how
> long the relocation information in the section actually is. Usually the
> section is larger than the actual relocation info. The end of the
> relocation info is indicated by a block header with a base offset of 0
> and a sizeof of 0, let's call it the NULL block.
>
> What I could reproduce using Marco's ltree.dll example was this:
>
> After adding the .gnu_debuglink section, the former NULL block suddenly
> contained some seemingly random values. So rebase rightfully assumed
> that another relocation block is following. So it happily tried further
> to relocate the file, until the address falls outside of the allocated
> memory block, which resulted in the SEGV.
>
> To me this indicates a bug in objcopy.
ok Corinna,
but on dict_snowball I see a that rebase is
changing the next section after .reloc
it is not touching the 00 at the end of
the .reloc section from 0003 6a60 to 0003 6bf0
while is touching the debug section
from 0003 6c00 to 0003 df00
At least it should stop at the end of the .reloc
section anyway
diff -uN dump-debug.txt dump-rebased.txt
[cut]
0032260 1000 0004 007c 0000 333f 3343 3366 338c
0032270 3390 33a9 33d1 33d5 33ee 346b 346f 34df
0032280 34e8 351b 354c 3589 358d 360d 3611 3626
@@ -13928,9 +13930,37 @@
0036a60 0000 0000 0000 0000 0000 0000 0000 0000
*
0036c00 6964 7463 735f 6f6e 6277 6c61 2e6c 6c64
-0036c10 2e6c 6264 0067 0000 86d0 2d33 0000 0000
+0036c10 2e6c 48f5 0067 0000 86d0 2d33 0000 0000
0036c20 0000 0000 0000 0000 0000 0000 0000 0000
-*
+0036c30 0000 e691 0000 0000 0000 0000 0000 0000
+0036c40 0000 0000 0000 0000 0000 0000 0000 0000
+0036c50 0000 e691 0000 0000 0000 0000 0000 0000
+0036c60 0000 0000 0000 0000 0000 0000 0000 0000
+0036c70 0000 e691 0000 0000 0000 0000 0000 0000
+0036c80 0000 0000 0000 0000 0000 0000 0000 0000
+0036c90 0000 e691 0000 0000 0000 0000 0000 0000
+0036ca0 0000 0000 0000 0000 0000 0000 0000 0000
+0036cb0 0000 e691 0000 0000 0000 0000 0000 0000
+0036cc0 0000 0000 0000 0000 0000 0000 0000 0000
+0036cd0 0000 e691 0000 0000 0000 0000 0000 0000
+0036ce0 0000 0000 0000 0000 0000 0000 0000 0000
+0036cf0 0000 e691 0000 0000 0000 0000 0000 0000
+0036d00 0000 0000 0000 0000 0000 0000 0000 0000
+0036d10 0000 e691 0000 0000 0000 0000 0000 0000
+0036d20 0000 0000 0000 0000 0000 0000 0000 0000
+0036d30 0000 e691 0000 0000 0000 0000 0000 0000
+0036d40 0000 0000 0000 0000 0000 0000 0000 0000
+0036d50 0000 e691 0000 0000 0000 0000 0000 0000
+0036d60 0000 0000 0000 0000 0000 0000 0000 0000
+0036d70 0000 e691 0000 0000 0000 0000 0000 0000
+0036d80 0000 0000 0000 0000 0000 0000 0000 0000
+0036d90 0000 e691 0000 0000 0000 0000 0000 0000
+0036da0 0000 0000 0000 0000 0000 0000 0000 0000
+0036db0 0000 e691 0000 0000 0000 0000 0000 0000
+0036dc0 0000 0000 0000 0000 0000 0000 0000 0000
+0036dd0 0000 e691 0000 0000 0000 0000 0000 0000
+0036de0 0000 0000 0000 0000 0000 0000 0000 0000
+0036df0 0000 e691 0000 0000 0000 0000 0000 0000
0036e00 0013 0000 672e 756e 645f 6265 6775 696c
-0036e10 6b6e 0000
+0036e10 6b6e 0091
0036e13
>
>
> Corinna
>
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
2013-01-24 5:49 ` marco atzeri
@ 2013-01-24 12:29 ` Chris Sutcliffe
2013-01-26 7:56 ` RFU: bzr-2.6+b2-2 (Python 2.7 upgrade) Jari Aalto
` (20 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Chris Sutcliffe @ 2013-01-24 12:29 UTC (permalink / raw)
To: Cygwin-apps
On 23 January 2013 19:56, Yaakov wrote:
> Jason Tishler announced last month[1] that he intends to upgrade Python
> to 2.7 on 01 February, which is quickly approaching.
>
> In order to assure a prompt and smooth transition to Python 2.7, the
> following packages will need a rebuild/update:
>
> Chris Sutcliffe: googlecl, python-gdata
I've uploaded python-gdata and googecl rebuilt to work with python2.7:
python-gdata:
---
wget -x -nH --cut-dirs=3 \
https://dl.dropbox.com/u/5530441/cygwin/python-gdata/python-gdata-2.0.17-2.tar.bz2
\
https://dl.dropbox.com/u/5530441/cygwin/python-gdata/python-gdata-2.0.17-2-src.tar.bz2
\
https://dl.dropbox.com/u/5530441/cygwin/python-gdata/setup.hint
---
googlecl:
---
wget -x -nH --cut-dirs=3 \
https://dl.dropbox.com/u/5530441/cygwin/googlecl/googlecl-0.9.14-2.tar.bz2 \
https://dl.dropbox.com/u/5530441/cygwin/googlecl/googlecl-0.9.14-2-src.tar.bz2 \
https://dl.dropbox.com/u/5530441/cygwin/googlecl/setup.hint
---
Please upload when appropriate.
Thanks,
Chris
--
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 10:41 ` marco atzeri
@ 2013-01-24 12:30 ` Corinna Vinschen
2013-01-24 12:51 ` marco atzeri
2013-01-26 0:09 ` szgyg
0 siblings, 2 replies; 47+ messages in thread
From: Corinna Vinschen @ 2013-01-24 12:30 UTC (permalink / raw)
To: cygwin-apps
On Jan 24 11:41, marco atzeri wrote:
> On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
> >I debugged this last week, and I don't see how this could be a rebase
> >bug. The layout of the relocation information is basically an array
> >of relocation blocks, like this:
> >
> > .reloc section
> > block1
> > header
> > base offset
> > sizeof following array
> > array of 2 byte values with:
> > 4 bit relocation type
> > 12 bit offset from base offset
> > block2
> > [...]
> >
> >The size of the .reloc section in the file header does not indicate how
> >long the relocation information in the section actually is. Usually the
> >section is larger than the actual relocation info. The end of the
> >relocation info is indicated by a block header with a base offset of 0
> >and a sizeof of 0, let's call it the NULL block.
> >
> >What I could reproduce using Marco's ltree.dll example was this:
> >
> >After adding the .gnu_debuglink section, the former NULL block suddenly
> >contained some seemingly random values. So rebase rightfully assumed
> >that another relocation block is following. So it happily tried further
> >to relocate the file, until the address falls outside of the allocated
> >memory block, which resulted in the SEGV.
> >
> >To me this indicates a bug in objcopy.
>
> ok Corinna,
> but on dict_snowball I see a that rebase is
> changing the next section after .reloc
>
> it is not touching the 00 at the end of
> the .reloc section from 0003 6a60 to 0003 6bf0
rebase does not change the .reloc section. It uses the information
in the .reloc section to change other file information. Feel free
to debug rebase yourself.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 12:30 ` Corinna Vinschen
@ 2013-01-24 12:51 ` marco atzeri
2013-01-26 0:09 ` szgyg
1 sibling, 0 replies; 47+ messages in thread
From: marco atzeri @ 2013-01-24 12:51 UTC (permalink / raw)
To: cygwin-apps
On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
>
> rebase does not change the .reloc section. It uses the information
> in the .reloc section to change other file information. Feel free
> to debug rebase yourself.
>
as soon I will understand how PE-COFF should be,
and where objcopy is messing the things
;-)
>
> Corinna
Thanks
Marco
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 12:30 ` Corinna Vinschen
2013-01-24 12:51 ` marco atzeri
@ 2013-01-26 0:09 ` szgyg
2013-01-26 5:51 ` marco atzeri
2013-01-28 10:35 ` Corinna Vinschen
1 sibling, 2 replies; 47+ messages in thread
From: szgyg @ 2013-01-26 0:09 UTC (permalink / raw)
To: cygwin-apps
On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
> On Jan 24 11:41, marco atzeri wrote:
>> On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
>>> I debugged this last week, and I don't see how this could be a rebase
>>> bug. [...] To me this indicates a bug in objcopy.
Strip copies the whole .reloc section, including entries for removed
debug sections. This is documented in rebase/README. Rebase checks for
this condition in Relocations::relocate and silently ignores wrong
entries. Well, except in Marco's dict_snowball.dll.
Btw,
>>> The size of the .reloc section in the file header does not indicate how
>>> long the relocation information in the section actually is. Usually the
>>> section is larger than the actual relocation info. The end of the
>>> relocation info is indicated by a block header with a base offset of 0
>>> and a sizeof of 0, let's call it the NULL block.
VirtualSize (offset 8 in section header) should be exact. There are no
terminator zero block, but can be zero section padding. VirtualSize +
padding = SizeOfRawData.
szgyg
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-26 0:09 ` szgyg
@ 2013-01-26 5:51 ` marco atzeri
2013-01-26 23:22 ` szgyg
2013-01-28 10:35 ` Corinna Vinschen
1 sibling, 1 reply; 47+ messages in thread
From: marco atzeri @ 2013-01-26 5:51 UTC (permalink / raw)
To: cygwin-apps
On 1/26/2013 1:08 AM, szgyg wrote:
> On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
>> On Jan 24 11:41, marco atzeri wrote:
>>> On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
>>>> I debugged this last week, and I don't see how this could be a rebase
>>>> bug. [...] To me this indicates a bug in objcopy.
>
> Strip copies the whole .reloc section, including entries for removed
> debug sections. This is documented in rebase/README. Rebase checks for
> this condition in Relocations::relocate and silently ignores wrong
> entries. Well, except in Marco's dict_snowball.dll.
>
probably the FixImage does no work as rebase is not applied
to the stripped dll, but after the addittion of the
.gnu_debuglink section. The section is small and usually
it is not likely to be covered by the reloc table.
Postgresql has 77 dll's and only 1 hit the problem.
I also noted that using "gcc -shared" instead of "dllwrap" produce
a dict_snowball.dll without the reloc table covering the ".debug_*"
$ objdump -p dict_snowball.dll |grep Virtual
Virtual Address: 00001000 Chunk size 72 (0x48) Number of fixups 32
Virtual Address: 00002000 Chunk size 64 (0x40) Number of fixups 28
[cut]
Virtual Address: 0002d000 Chunk size 312 (0x138) Number of fixups 152
Virtual Address: 0002e000 Chunk size 336 (0x150) Number of fixups 164
$ objdump -h dict_snowball.dll
dict_snowball.dll: file format pei-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000162d0 10001000 10001000 00000400 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00017160 10018000 10018000 00016800 2**5
CONTENTS, ALLOC, LOAD, DATA
2 .edata 00000fde 10030000 10030000 0002da00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .idata 000002c0 10031000 10031000 0002ea00 2**2
CONTENTS, ALLOC, LOAD, DATA
4 .reloc 00002d40 10032000 10032000 0002ee00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .debug_aranges 00000440 10035000 10035000 00031c00 2**0
CONTENTS, READONLY, DEBUGGING
6 .debug_pubnames 00000f14 10036000 10036000 00032200 2**0
CONTENTS, READONLY, DEBUGGING
7 .debug_pubtypes 00000ad5 10037000 10037000 00033200 2**0
CONTENTS, READONLY, DEBUGGING
8 .debug_info 00044129 10038000 10038000 00033e00 2**0
CONTENTS, READONLY, DEBUGGING
9 .debug_abbrev 00004873 1007d000 1007d000 00078000 2**0
CONTENTS, READONLY, DEBUGGING
10 .debug_line 00006ee9 10082000 10082000 0007ca00 2**0
CONTENTS, READONLY, DEBUGGING
11 .debug_frame 00001ed8 10089000 10089000 00083a00 2**2
CONTENTS, READONLY, DEBUGGING
12 .debug_str 0000062c 1008b000 1008b000 00085a00 2**0
CONTENTS, READONLY, DEBUGGING
13 .debug_loc 00016d11 1008c000 1008c000 00086200 2**0
CONTENTS, READONLY, DEBUGGING
14 .debug_ranges 0000f388 100a3000 100a3000 0009d000 2**0
CONTENTS, READONLY, DEBUGGING
As workaround I will deploy a postgresql release without
debug symbols.
Changing the build system to not use dllwrap will
take some additional time, specially for the testing all
the 77 dll's behaviour.
> Btw,
>>>> The size of the .reloc section in the file header does not indicate how
>>>> long the relocation information in the section actually is. Usually
>>>> the
>>>> section is larger than the actual relocation info. The end of the
>>>> relocation info is indicated by a block header with a base offset of 0
>>>> and a sizeof of 0, let's call it the NULL block.
>
> VirtualSize (offset 8 in section header) should be exact. There are no
> terminator zero block, but can be zero section padding. VirtualSize +
> padding = SizeOfRawData.
>
> szgyg
>
Regards
Marco
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: bzr-2.6+b2-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
2013-01-24 5:49 ` marco atzeri
2013-01-24 12:29 ` Chris Sutcliffe
@ 2013-01-26 7:56 ` Jari Aalto
2013-01-26 8:04 ` RFU: codeville 0.8.0-4 " Jari Aalto
` (19 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 7:56 UTC (permalink / raw)
To: cygwin-apps
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6+b2-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6+b2-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: codeville 0.8.0-4 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (2 preceding siblings ...)
2013-01-26 7:56 ` RFU: bzr-2.6+b2-2 (Python 2.7 upgrade) Jari Aalto
@ 2013-01-26 8:04 ` Jari Aalto
2013-01-26 8:19 ` RFU: getmail 4.36.0-1 " Jari Aalto
` (18 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:04 UTC (permalink / raw)
To: cygwin-apps
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/codeville/codeville-0.8.0-4-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/codeville/codeville-0.8.0-4.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/codeville/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: getmail 4.36.0-1 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (3 preceding siblings ...)
2013-01-26 8:04 ` RFU: codeville 0.8.0-4 " Jari Aalto
@ 2013-01-26 8:19 ` Jari Aalto
2013-01-26 8:28 ` RFU: mercurial 2.4.2-1 " Jari Aalto
` (17 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:19 UTC (permalink / raw)
To: cygwin-apps
New upstream release, remove oldest. Built for Python 2.7.
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/getmail/getmail-4.36.0-1-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/getmail/getmail-4.36.0-1.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/getmail/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: mercurial 2.4.2-1 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (4 preceding siblings ...)
2013-01-26 8:19 ` RFU: getmail 4.36.0-1 " Jari Aalto
@ 2013-01-26 8:28 ` Jari Aalto
2013-01-26 8:31 ` RFU: /offlineimap 6.5.4-2 " Jari Aalto
` (16 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:28 UTC (permalink / raw)
To: cygwin-apps
New usptream release, remove oldest. Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-2.4.2-1-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/mercurial/mercurial-2.4.2-1.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/mercurial/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: /offlineimap 6.5.4-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (5 preceding siblings ...)
2013-01-26 8:28 ` RFU: mercurial 2.4.2-1 " Jari Aalto
@ 2013-01-26 8:31 ` Jari Aalto
2013-01-26 8:39 ` RFU: planet 2.0-3 " Jari Aalto
` (15 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:31 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/offlineimap/offlineimap-6.5.4-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/offlineimap/offlineimap-6.5.4-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/offlineimap/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: planet 2.0-3 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (6 preceding siblings ...)
2013-01-26 8:31 ` RFU: /offlineimap 6.5.4-2 " Jari Aalto
@ 2013-01-26 8:39 ` Jari Aalto
2013-01-26 8:44 ` RFU: python-crypto 2.6-3 " Jari Aalto
` (14 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:39 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/planet/planet-2.0-3-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/planet/planet-2.0-3.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/planet/setup.hint
Note that this package has been orphaned,
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: python-crypto 2.6-3 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (7 preceding siblings ...)
2013-01-26 8:39 ` RFU: planet 2.0-3 " Jari Aalto
@ 2013-01-26 8:44 ` Jari Aalto
2013-01-26 8:49 ` RFU: python-feedparser 5.0.1-2 " Jari Aalto
` (13 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:44 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/python-crypto/python-crypto-2.6-3-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-crypto/python-crypto-2.6-3.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-crypto/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: python-feedparser 5.0.1-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (8 preceding siblings ...)
2013-01-26 8:44 ` RFU: python-crypto 2.6-3 " Jari Aalto
@ 2013-01-26 8:49 ` Jari Aalto
2013-01-26 8:54 ` RFU: python-logilab-astng 0.23.1-2 " Jari Aalto
` (12 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:49 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/python-feedparser/python-feedparser-5.0.1-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-feedparser/python-feedparser-5.0.1-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-feedparser/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: python-logilab-astng 0.23.1-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (9 preceding siblings ...)
2013-01-26 8:49 ` RFU: python-feedparser 5.0.1-2 " Jari Aalto
@ 2013-01-26 8:54 ` Jari Aalto
2013-01-26 8:58 ` RFU: python-logilab-common 0.58.0-2 " Jari Aalto
` (11 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:54 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/python-logilab-astng/python-logilab-astng-0.23.1-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-logilab-astng/python-logilab-astng-0.23.1-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-logilab-astng/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: python-logilab-common 0.58.0-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (10 preceding siblings ...)
2013-01-26 8:54 ` RFU: python-logilab-astng 0.23.1-2 " Jari Aalto
@ 2013-01-26 8:58 ` Jari Aalto
2013-01-26 9:02 ` RFU: python-paramiko 1.7.7.1-2 " Jari Aalto
` (10 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 8:58 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/python-logilab-common/python-logilab-common-0.58.0-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-logilab-common/python-logilab-common-0.58.0-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-logilab-common/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: python-paramiko 1.7.7.1-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (11 preceding siblings ...)
2013-01-26 8:58 ` RFU: python-logilab-common 0.58.0-2 " Jari Aalto
@ 2013-01-26 9:02 ` Jari Aalto
2013-01-26 9:10 ` RFU: spambayes 1.0.4-2 " Jari Aalto
` (9 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 9:02 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/python-paramiko/python-paramiko-1.7.7.1-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-paramiko/python-paramiko-1.7.7.1-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/python-paramiko/setup.hint
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: spambayes 1.0.4-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (12 preceding siblings ...)
2013-01-26 9:02 ` RFU: python-paramiko 1.7.7.1-2 " Jari Aalto
@ 2013-01-26 9:10 ` Jari Aalto
2013-01-26 9:18 ` RFU: stgit 0.16-2 " Jari Aalto
` (8 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 9:10 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/spambayes/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/spambayes/spambayes-1.0.4-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/spambayes/spambayes-1.0.4-2.tar.bz2
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: stgit 0.16-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (13 preceding siblings ...)
2013-01-26 9:10 ` RFU: spambayes 1.0.4-2 " Jari Aalto
@ 2013-01-26 9:18 ` Jari Aalto
2013-01-26 9:23 ` RFU: tailor 0.9.35+darcs20090615-2 " Jari Aalto
` (7 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 9:18 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/stgit/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/stgit/stgit-0.16-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/stgit/stgit-0.16-2.tar.bz2
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: tailor 0.9.35+darcs20090615-2 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (14 preceding siblings ...)
2013-01-26 9:18 ` RFU: stgit 0.16-2 " Jari Aalto
@ 2013-01-26 9:23 ` Jari Aalto
2013-01-26 9:38 ` RFU: urlgrabber 3.1.0-3 " Jari Aalto
` (6 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 9:23 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/tailor/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/tailor/tailor-0.9.35+darcs20090615-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/tailor/tailor-0.9.35+darcs20090615-2.tar.bz2
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* RFU: urlgrabber 3.1.0-3 (Python 2.7 upgrade)
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (15 preceding siblings ...)
2013-01-26 9:23 ` RFU: tailor 0.9.35+darcs20090615-2 " Jari Aalto
@ 2013-01-26 9:38 ` Jari Aalto
2013-02-01 2:19 ` HEADSUP: Python 2.7 upgrade Jason Tishler
` (5 subsequent siblings)
22 siblings, 0 replies; 47+ messages in thread
From: Jari Aalto @ 2013-01-26 9:38 UTC (permalink / raw)
To: cygwin-apps
Built for Python 2.7
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/urlgrabber/setup.hint \
http://cante.net/~jaalto/tmp/cygwin/urlgrabber/urlgrabber-3.1.0-3-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/urlgrabber/urlgrabber-3.1.0-3.tar.bz2
Jari
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-26 5:51 ` marco atzeri
@ 2013-01-26 23:22 ` szgyg
0 siblings, 0 replies; 47+ messages in thread
From: szgyg @ 2013-01-26 23:22 UTC (permalink / raw)
To: cygwin-apps
On 1/26/2013 6:50 AM, marco atzeri wrote:
> On 1/26/2013 1:08 AM, szgyg wrote:
>> Strip copies the whole .reloc section, including entries for removed
>> debug sections. This is documented in rebase/README. Rebase checks for
>> this condition in Relocations::relocate and silently ignores wrong
>> entries. Well, except in Marco's dict_snowball.dll.
>
> probably the FixImage does no work as rebase is not applied
> to the stripped dll, but after the addittion of the
> .gnu_debuglink section. The section is small and usually
> it is not likely to be covered by the reloc table.
> Postgresql has 77 dll's and only 1 hit the problem.
Indeed. Rebase checks whether the base address in a relocation block
points into an existing section. It does, because there is
.gnu_debuglink, but this section is only 0x200 bytes while a relocation
block covers 0x1000 bytes, so rebase segfaults if we have a relocation
in this gap.
> I also noted that using "gcc -shared" instead of "dllwrap" produce
> a dict_snowball.dll without the reloc table covering the ".debug_*"
>
> As workaround I will deploy a postgresql release without
> debug symbols.
>
> Changing the build system to not use dllwrap will
> take some additional time, specially for the testing all
> the 77 dll's behaviour.
Another workaround would be fixing .reloc between stripping and adding
.gnu_debuglink. Running `make rebase.exe' in rebase/imagehelper creates
a rebase which have an -f flag for this. (But it inserts a zero
terminator block instead of changing VirtualSize, so it may or may not
work.)
szgyg
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-26 0:09 ` szgyg
2013-01-26 5:51 ` marco atzeri
@ 2013-01-28 10:35 ` Corinna Vinschen
2013-01-28 10:52 ` marco atzeri
2013-01-28 13:25 ` szgyg
1 sibling, 2 replies; 47+ messages in thread
From: Corinna Vinschen @ 2013-01-28 10:35 UTC (permalink / raw)
To: cygwin-apps
On Jan 26 01:08, szgyg wrote:
> On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
> >On Jan 24 11:41, marco atzeri wrote:
> >>On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
> >>>I debugged this last week, and I don't see how this could be a rebase
> >>>bug. [...] To me this indicates a bug in objcopy.
>
> Strip copies the whole .reloc section, including entries for removed
> debug sections. This is documented in rebase/README. Rebase checks
> for this condition in Relocations::relocate and silently ignores
> wrong entries. Well, except in Marco's dict_snowball.dll.
>
> Btw,
> >>>The size of the .reloc section in the file header does not indicate how
> >>>long the relocation information in the section actually is. Usually the
> >>>section is larger than the actual relocation info. The end of the
> >>>relocation info is indicated by a block header with a base offset of 0
> >>>and a sizeof of 0, let's call it the NULL block.
>
> VirtualSize (offset 8 in section header) should be exact. There are
> no terminator zero block, but can be zero section padding.
> VirtualSize + padding = SizeOfRawData.
Are you implying that rebase (or better: the included imagehelper lib)
is doing the right thing, or not? The size of the reloc section is
taken from SizeOfRawData. Relocations::check checks if the data is
within a valid section. I just don't see what it's doing wrong there.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-28 10:35 ` Corinna Vinschen
@ 2013-01-28 10:52 ` marco atzeri
2013-01-28 13:25 ` szgyg
1 sibling, 0 replies; 47+ messages in thread
From: marco atzeri @ 2013-01-28 10:52 UTC (permalink / raw)
To: cygwin-apps
On 1/28/2013 11:35 AM, Corinna Vinschen wrote:
> On Jan 26 01:08, szgyg wrote:
>> On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
>>> On Jan 24 11:41, marco atzeri wrote:
>>>> On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
>>>>> I debugged this last week, and I don't see how this could be a rebase
>>>>> bug. [...] To me this indicates a bug in objcopy.
>>
>> Strip copies the whole .reloc section, including entries for removed
>> debug sections. This is documented in rebase/README. Rebase checks
>> for this condition in Relocations::relocate and silently ignores
>> wrong entries. Well, except in Marco's dict_snowball.dll.
>>
>> Btw,
>>>>> The size of the .reloc section in the file header does not indicate how
>>>>> long the relocation information in the section actually is. Usually the
>>>>> section is larger than the actual relocation info. The end of the
>>>>> relocation info is indicated by a block header with a base offset of 0
>>>>> and a sizeof of 0, let's call it the NULL block.
>>
>> VirtualSize (offset 8 in section header) should be exact. There are
>> no terminator zero block, but can be zero section padding.
>> VirtualSize + padding = SizeOfRawData.
>
> Are you implying that rebase (or better: the included imagehelper lib)
> is doing the right thing, or not? The size of the reloc section is
> taken from SizeOfRawData. Relocations::check checks if the data is
> within a valid section. I just don't see what it's doing wrong there.
>
>
> Corinna
>
Rebase is not doing wrong. It works on rebasing the stripped file,
as the excess relocation table have no sectors to match.
Unfortunately on the stripped + debug link there is a small
chance that the additional .gnu_debuglink is inside the addresses
of excess relocation table.
Rebase has no way to know that .gnu_debuglink was added later.
In theory both these will help to solve the matter:
-strip should sanitize the .reloc table, but it doesn't care.
-dllwrap should not make binary with relocation of the debug area
It is clear a corner case; my workaround is no debug info when
using dllwrap. Unlikely to happen on general cases
Regards
Marco
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-28 10:35 ` Corinna Vinschen
2013-01-28 10:52 ` marco atzeri
@ 2013-01-28 13:25 ` szgyg
2013-01-28 14:27 ` Corinna Vinschen
1 sibling, 1 reply; 47+ messages in thread
From: szgyg @ 2013-01-28 13:25 UTC (permalink / raw)
To: cygwin-apps
I didn't see the discussion on the other list. Oh, well.
On 1/28/2013 11:35 AM, Corinna Vinschen wrote:
> On Jan 26 01:08, szgyg wrote:
>> On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
>>>>> The size of the .reloc section in the file header does not indicate how
>>>>> long the relocation information in the section actually is. Usually the
>>>>> section is larger than the actual relocation info. The end of the
>>>>> relocation info is indicated by a block header with a base offset of 0
>>>>> and a sizeof of 0, let's call it the NULL block.
>>
>> VirtualSize (offset 8 in section header) should be exact. There are
>> no terminator zero block, but can be zero section padding.
>> VirtualSize + padding = SizeOfRawData.
>
> Are you implying that rebase (or better: the included imagehelper lib)
> is doing the right thing, or not? The size of the reloc section is
> taken from SizeOfRawData. Relocations::check checks if the data is
> within a valid section. I just don't see what it's doing wrong there.
This problem is unrelated to the segfault.
Relocations::relocate does a strange thing that works by accident. See
this condition:
&relocp->SizeOfBlock < (PDWORD) ((char *)relocs + size)
&& relocp->SizeOfBlock != 0;
After the last relocation block, the first half of the condition is
false if we have 0 or 1 DWORD of padding, and the second half is false
if the second DWORD of padding is 0. As paddings should be all zeros,
this condition always terminates the loop, but I wouldn't write it in
this way. A better form is something like
relocp < relocs + virtual_size
Relocations::fix is broken, but hopefully it doesn't run on dlls not
created by dllwrap. It should set VirtualSize and zero out the remaining
part of .reloc. Right now it leaves a .reloc with an invalid, 0-size
block and additional garbage.
szgyg
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-28 13:25 ` szgyg
@ 2013-01-28 14:27 ` Corinna Vinschen
0 siblings, 0 replies; 47+ messages in thread
From: Corinna Vinschen @ 2013-01-28 14:27 UTC (permalink / raw)
To: cygwin-apps
On Jan 28 14:25, szgyg wrote:
> I didn't see the discussion on the other list. Oh, well.
>
> On 1/28/2013 11:35 AM, Corinna Vinschen wrote:
> >On Jan 26 01:08, szgyg wrote:
> >>On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
> >>>>>The size of the .reloc section in the file header does not indicate how
> >>>>>long the relocation information in the section actually is. Usually the
> >>>>>section is larger than the actual relocation info. The end of the
> >>>>>relocation info is indicated by a block header with a base offset of 0
> >>>>>and a sizeof of 0, let's call it the NULL block.
> >>
> >>VirtualSize (offset 8 in section header) should be exact. There are
> >>no terminator zero block, but can be zero section padding.
> >>VirtualSize + padding = SizeOfRawData.
> >
> >Are you implying that rebase (or better: the included imagehelper lib)
> >is doing the right thing, or not? The size of the reloc section is
> >taken from SizeOfRawData. Relocations::check checks if the data is
> >within a valid section. I just don't see what it's doing wrong there.
>
> This problem is unrelated to the segfault.
>
> Relocations::relocate does a strange thing that works by accident.
> See this condition:
>
> &relocp->SizeOfBlock < (PDWORD) ((char *)relocs + size)
> && relocp->SizeOfBlock != 0;
>
> After the last relocation block, the first half of the condition is
> false if we have 0 or 1 DWORD of padding, and the second half is
> false if the second DWORD of padding is 0. As paddings should be all
> zeros, this condition always terminates the loop, but I wouldn't
> write it in this way. A better form is something like
> relocp < relocs + virtual_size
>
> Relocations::fix is broken, but hopefully it doesn't run on dlls not
> created by dllwrap. It should set VirtualSize and zero out the
> remaining part of .reloc. Right now it leaves a .reloc with an
> invalid, 0-size block and additional garbage.
You know that this is an open source project and patches against current
CVS(*) are very welcome, right?
Corinna
(*) cvs -d :pserver:anoncvs@cygwin.com:/cvs/cygwiin-apps checkout rebase
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (16 preceding siblings ...)
2013-01-26 9:38 ` RFU: urlgrabber 3.1.0-3 " Jari Aalto
@ 2013-02-01 2:19 ` Jason Tishler
2013-02-01 3:53 ` Ken Brown
2013-02-01 6:40 ` Yaakov
2013-02-01 7:49 ` Dr. Volker Zell
` (4 subsequent siblings)
22 siblings, 2 replies; 47+ messages in thread
From: Jason Tishler @ 2013-02-01 2:19 UTC (permalink / raw)
To: cygwin-apps
On Wed, Jan 23, 2013 at 06:56:56PM -0600, Yaakov wrote:
> Jason Tishler announced last month[1] that he intends to upgrade
> Python to 2.7 on 01 February, which is quickly approaching.
>
> If anybody needs them, my Python-dependent distro packages have been
> rebuilt and are available in a staging area here:
>
> ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
>
> In order to assure a prompt and smooth transition to Python 2.7, the
> following packages will need a rebuild/update:
>
> Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
> pylint, python-crypto, python-feedparser, python-logilab-astng,
> python-logilab-common, python-paramiko, spambayes, stgit, tailor,
> urlgrabber
> Marco Atzeri: postgresql
> Ken Brown: bzr-fastimport, python-fastimport
> Jan Nieuwenhuizen: lilypond
> Bo Peng: lyx
> David Rothenberger: rdiff-backup, subversion
> Chris Sutcliffe: googlecl, python-gdata
> Samuel Thibault: brltty, python-pyrex
> Dr. Volker Zell: lcms, ming
It seems like many, but not all of the above, have been rebuilt for
Python 2.7. Should I release as scheduled or give the maintainers
more time?
Thanks,
Jason
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-01 2:19 ` HEADSUP: Python 2.7 upgrade Jason Tishler
@ 2013-02-01 3:53 ` Ken Brown
2013-02-01 5:49 ` Yaakov
2013-02-01 6:40 ` Yaakov
1 sibling, 1 reply; 47+ messages in thread
From: Ken Brown @ 2013-02-01 3:53 UTC (permalink / raw)
To: cygwin-apps
On 1/31/2013 9:18 PM, Jason Tishler wrote:
> On Wed, Jan 23, 2013 at 06:56:56PM -0600, Yaakov wrote:
>> Jason Tishler announced last month[1] that he intends to upgrade
>> Python to 2.7 on 01 February, which is quickly approaching.
>>
>> If anybody needs them, my Python-dependent distro packages have been
>> rebuilt and are available in a staging area here:
>>
>> ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
>>
>> In order to assure a prompt and smooth transition to Python 2.7, the
>> following packages will need a rebuild/update:
>>
>> Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
>> pylint, python-crypto, python-feedparser, python-logilab-astng,
>> python-logilab-common, python-paramiko, spambayes, stgit, tailor,
>> urlgrabber
>> Marco Atzeri: postgresql
>> Ken Brown: bzr-fastimport, python-fastimport
>> Jan Nieuwenhuizen: lilypond
>> Bo Peng: lyx
>> David Rothenberger: rdiff-backup, subversion
>> Chris Sutcliffe: googlecl, python-gdata
>> Samuel Thibault: brltty, python-pyrex
>> Dr. Volker Zell: lcms, ming
>
> It seems like many, but not all of the above, have been rebuilt for
> Python 2.7. Should I release as scheduled or give the maintainers
> more time?
I don't need more time for my packages. I've got them ready, and I'll
just test them before sending an RFU after your release.
Ken
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-01 3:53 ` Ken Brown
@ 2013-02-01 5:49 ` Yaakov
0 siblings, 0 replies; 47+ messages in thread
From: Yaakov @ 2013-02-01 5:49 UTC (permalink / raw)
To: cygwin-apps
On Thu, 31 Jan 2013 22:53:19 -0500, Ken Brown wrote:
> I don't need more time for my packages. I've got them ready, and I'll
> just test them before sending an RFU after your release.
Could you do that so now in order that we can upload these
simultaneously and minimize the time frame for breakage?
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-01 2:19 ` HEADSUP: Python 2.7 upgrade Jason Tishler
2013-02-01 3:53 ` Ken Brown
@ 2013-02-01 6:40 ` Yaakov
1 sibling, 0 replies; 47+ messages in thread
From: Yaakov @ 2013-02-01 6:40 UTC (permalink / raw)
To: cygwin-apps
On Thu, 31 Jan 2013 21:18:48 -0500, Jason Tishler wrote:
> On Wed, Jan 23, 2013 at 06:56:56PM -0600, Yaakov wrote:
> > Jason Tishler announced last month[1] that he intends to upgrade
> > Python to 2.7 on 01 February, which is quickly approaching.
> >
> > If anybody needs them, my Python-dependent distro packages have been
> > rebuilt and are available in a staging area here:
> >
> > ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
> >
> > In order to assure a prompt and smooth transition to Python 2.7, the
> > following packages will need a rebuild/update:
> >
> > Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
> > pylint, python-crypto, python-feedparser, python-logilab-astng,
> > python-logilab-common, python-paramiko, spambayes, stgit, tailor,
> > urlgrabber
> > Marco Atzeri: postgresql
> > Ken Brown: bzr-fastimport, python-fastimport
> > Jan Nieuwenhuizen: lilypond
> > Bo Peng: lyx
> > David Rothenberger: rdiff-backup, subversion
> > Chris Sutcliffe: googlecl, python-gdata
> > Samuel Thibault: brltty, python-pyrex
> > Dr. Volker Zell: lcms, ming
>
> It seems like many, but not all of the above, have been rebuilt for
> Python 2.7. Should I release as scheduled or give the maintainers
> more time?
Upon further examination, it appears that lilypond need NOT be rebuilt,
so that leaves:
Bo Peng: lyx
Samuel Thibault: brltty (python-brlapi), python-pyrex
Dr. Volker Zell: (python-)lcms, (python-)ming
lyx is just a matter of bytecode recompilation, but the others will be
completely broken by the upgrade until they are rebuilt. I'm a bit
concerned about python-pyrex as a build-time dep for other packages;
the others show no reverse dependencies in distro nor Ports.
Either way, unless you're pulling the trigger right now, could we wait
at least 48 hours so that I can be online to coordinate the upload?
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (17 preceding siblings ...)
2013-02-01 2:19 ` HEADSUP: Python 2.7 upgrade Jason Tishler
@ 2013-02-01 7:49 ` Dr. Volker Zell
2013-02-03 7:03 ` Yaakov
2013-02-03 10:48 ` Yaakov
` (3 subsequent siblings)
22 siblings, 1 reply; 47+ messages in thread
From: Dr. Volker Zell @ 2013-02-01 7:49 UTC (permalink / raw)
To: cygwin-apps
>>>>> Yaakov writes:
> Jason Tishler announced last month[1] that he intends to upgrade Python
> to 2.7 on 01 February, which is quickly approaching.
> Dr. Volker Zell: lcms, ming
lcms is ready on sourceware under /home/vzell and can be moved to the setup area whenever needed.
Whith the latest cygport installed I get the following errors
Stripping executables:
usr/bin/cyglcms-1.dll
usr/bin/icc2ps.exe
usr/bin/icclink.exe
usr/bin/icctrans.exe
usr/bin/jpegicc.exe
usr/bin/tiffdiff.exe
usr/bin/tifficc.exe
usr/bin/wtpt.exe
usr/lib/python2.7/site-packages/_lcms.dll
head: cannot open `usr/share/lcms/sRGB' for reading: No such file or directory
tail: cannot open `usr/share/lcms/sRGB' for reading: No such file or directory
tail: cannot open `usr/share/lcms/sRGB' for reading: No such file or directory
head: cannot open `Color' for reading: No such file or directory
tail: cannot open `Color' for reading: No such file or directory
tail: cannot open `Color' for reading: No such file or directory
head: cannot open `Space' for reading: No such file or directory
tail: cannot open `Space' for reading: No such file or directory
tail: cannot open `Space' for reading: No such file or directory
head: cannot open `Profile.icm' for reading: No such file or directory
tail: cannot open `Profile.icm' for reading: No such file or directory
tail: cannot open `Profile.icm' for reading: No such file or directory
>>> Creating source package
lcms-1.19-3.cygwin.patch
lcms-1.19-3.src.patch
lcms-1.19.tar.gz
lcms.cygport
sed: can't read usr/share/lcms/sRGB: No such file or directory
sed: can't read Color: No such file or directory
sed: can't read Space: No such file or directory
sed: can't read Profile.icm: No such file or directory
This seems to be triggered by a file with spaces in it's name, namely
-> ./inst/usr/share/lcms/sRGB Color Space Profile.icm
Trying to compile ming with latest cygport gives
08:47 AM [538]> cygport ming.cygport compile
>>> Compiling ming-0.4.4-3
*** ERROR: No Perl module detected
cygport-0.11.0 with my ming cygport file worked fine.
> Yaakov
Ciao
Volker
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-01 7:49 ` Dr. Volker Zell
@ 2013-02-03 7:03 ` Yaakov
0 siblings, 0 replies; 47+ messages in thread
From: Yaakov @ 2013-02-03 7:03 UTC (permalink / raw)
To: cygwin-apps
On Fri, 01 Feb 2013 08:50:30 +0100, Dr. Volker Zell wrote:
> Whith the latest cygport installed I get the following errors
>
> head: cannot open `usr/share/lcms/sRGB' for reading: No such file or directory
> tail: cannot open `usr/share/lcms/sRGB' for reading: No such file or directory
> tail: cannot open `usr/share/lcms/sRGB' for reading: No such file or directory
> head: cannot open `Color' for reading: No such file or directory
> tail: cannot open `Color' for reading: No such file or directory
> tail: cannot open `Color' for reading: No such file or directory
> head: cannot open `Space' for reading: No such file or directory
> tail: cannot open `Space' for reading: No such file or directory
> tail: cannot open `Space' for reading: No such file or directory
> head: cannot open `Profile.icm' for reading: No such file or directory
> tail: cannot open `Profile.icm' for reading: No such file or directory
> tail: cannot open `Profile.icm' for reading: No such file or directory
>
> sed: can't read usr/share/lcms/sRGB: No such file or directory
> sed: can't read Color: No such file or directory
> sed: can't read Space: No such file or directory
> sed: can't read Profile.icm: No such file or directory
>
> This seems to be triggered by a file with spaces in it's name, namely
>
> -> ./inst/usr/share/lcms/sRGB Color Space Profile.icm
More specifically, that file must also be executable; chmod -x that file
during src_install should avoid the problem.
> Trying to compile ming with latest cygport gives
>
> 08:47 AM [538]> cygport ming.cygport compile
> >>> Compiling ming-0.4.4-3
> *** ERROR: No Perl module detected
>
> cygport-0.11.0 with my ming cygport file worked fine.
I'm not sure yet which commit would have caused the change in
behaviour, but make sure the cygclass providing the desired
src_compile/src_install (which may be "autotools") is at inherit()ed
last.
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (18 preceding siblings ...)
2013-02-01 7:49 ` Dr. Volker Zell
@ 2013-02-03 10:48 ` Yaakov
2013-02-04 12:01 ` Dr. Volker Zell
2013-02-04 21:17 ` Yaakov
` (2 subsequent siblings)
22 siblings, 1 reply; 47+ messages in thread
From: Yaakov @ 2013-02-03 10:48 UTC (permalink / raw)
To: cygwin-apps
On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
> Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
> pylint, python-crypto, python-feedparser, python-logilab-astng,
> python-logilab-common, python-paramiko, spambayes, stgit, tailor,
> urlgrabber
> Ken Brown: bzr-fastimport, python-fastimport
> David Rothenberger: rdiff-backup, subversion
> Chris Sutcliffe: googlecl, python-gdata
All of these are now in my staging area.
> Bo Peng: lyx
Awaiting clarification on dependencies.
> Samuel Thibault: brltty, python-pyrex
Ping?
> Dr. Volker Zell: lcms, ming
lcms is staged; waiting for ming.
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-03 10:48 ` Yaakov
@ 2013-02-04 12:01 ` Dr. Volker Zell
2013-02-04 20:57 ` Yaakov
0 siblings, 1 reply; 47+ messages in thread
From: Dr. Volker Zell @ 2013-02-04 12:01 UTC (permalink / raw)
To: cygwin-apps
>>>>> Yaakov writes:
>> Dr. Volker Zell: lcms, ming
> lcms is staged; waiting for ming.
ming is under /home/vzell on soureceware now, waiting to be staged....
> Yaakov
Ciao
Volker
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-04 12:01 ` Dr. Volker Zell
@ 2013-02-04 20:57 ` Yaakov
0 siblings, 0 replies; 47+ messages in thread
From: Yaakov @ 2013-02-04 20:57 UTC (permalink / raw)
To: cygwin-apps
On Mon, 04 Feb 2013 13:02:18 +0100, Dr. Volker Zell wrote:
> ming is under /home/vzell on soureceware now, waiting to be staged....
Done.
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (19 preceding siblings ...)
2013-02-03 10:48 ` Yaakov
@ 2013-02-04 21:17 ` Yaakov
2013-02-07 0:42 ` Samuel Thibault
2013-02-07 9:30 ` Yaakov
2013-02-08 9:21 ` Yaakov
22 siblings, 1 reply; 47+ messages in thread
From: Yaakov @ 2013-02-04 21:17 UTC (permalink / raw)
To: samuel.thibault; +Cc: cygwin-apps
On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
> Jason Tishler announced last month[1] that he intends to upgrade Python
> to 2.7 on 01 February, which is quickly approaching.
>
> If anybody needs them, my Python-dependent distro packages have been rebuilt and are available in a staging area here:
>
> ftp://ftp.cygwinports.org/pub/cygwinports/uploads/
>
> In order to assure a prompt and smooth transition to Python 2.7, the
> following packages will need a rebuild/update:
[snip]
> Samuel Thibault: brltty (python-brlapi), python-pyrex
Samuel,
Yours are the last packages that need to be updated for Python 2.7.
Will you be able to take care of these in the next few days?
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-04 21:17 ` Yaakov
@ 2013-02-07 0:42 ` Samuel Thibault
2013-02-07 9:17 ` Yaakov
0 siblings, 1 reply; 47+ messages in thread
From: Samuel Thibault @ 2013-02-07 0:42 UTC (permalink / raw)
To: Yaakov; +Cc: cygwin-apps
Yaakov, le Mon 04 Feb 2013 15:17:19 -0600, a écrit :
> Yours are the last packages that need to be updated for Python 2.7.
> Will you be able to take care of these in the next few days?
Most probably not. I'm afraid I've been completely unable to follow
the cygwin discussions of the past months, so I completely missed the
HEADSUP.
I'm wondering whether I can really say I'm able to maintain these
packages.
Samuel
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-07 0:42 ` Samuel Thibault
@ 2013-02-07 9:17 ` Yaakov
0 siblings, 0 replies; 47+ messages in thread
From: Yaakov @ 2013-02-07 9:17 UTC (permalink / raw)
To: cygwin-apps; +Cc: Samuel Thibault
On Thu, 7 Feb 2013 01:41:56 +0100, Samuel Thibault wrote:
> Yaakov, le Mon 04 Feb 2013 15:17:19 -0600, a écrit :
> > Yours are the last packages that need to be updated for Python 2.7.
> > Will you be able to take care of these in the next few days?
>
> Most probably not. I'm afraid I've been completely unable to follow
> the cygwin discussions of the past months, so I completely missed the
> HEADSUP.
>
> I'm wondering whether I can really say I'm able to maintain these
> packages.
Thank you for the response. I'll go ahead and mark your packages up
for grabs for now; if your situation does change in the meantime, we'll
be glad to have you back.
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (20 preceding siblings ...)
2013-02-04 21:17 ` Yaakov
@ 2013-02-07 9:30 ` Yaakov
2013-02-08 0:42 ` Jason Tishler
2013-02-08 9:21 ` Yaakov
22 siblings, 1 reply; 47+ messages in thread
From: Yaakov @ 2013-02-07 9:30 UTC (permalink / raw)
To: cygwin-apps
On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
> Jason Tishler announced last month[1] that he intends to upgrade Python
> to 2.7 on 01 February, which is quickly approaching.
Jason,
Everything but python-brlapi is in place now, so I think we're
ready to do this. Shall I mark 2.7.3-1 stable and move everything in?
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-07 9:30 ` Yaakov
@ 2013-02-08 0:42 ` Jason Tishler
2013-02-08 9:12 ` Yaakov
0 siblings, 1 reply; 47+ messages in thread
From: Jason Tishler @ 2013-02-08 0:42 UTC (permalink / raw)
To: cygwin-apps
Yaakov,
On Thu, Feb 07, 2013 at 03:30:19AM -0600, Yaakov wrote:
> On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
> > Jason Tishler announced last month[1] that he intends to upgrade
> > Python to 2.7 on 01 February, which is quickly approaching.
>
> Jason,
>
> Everything but python-brlapi is in place now, so I think we're
> ready to do this. Shall I mark 2.7.3-1 stable and move everything in?
Sounds good. How should we handle the announcement(s)? Should each
maintainer send their own announcement(s)? Or, should one coordinated
announcement be sent?
I really appreciate your help with this upgrade.
Thanks,
Jason
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-08 0:42 ` Jason Tishler
@ 2013-02-08 9:12 ` Yaakov
0 siblings, 0 replies; 47+ messages in thread
From: Yaakov @ 2013-02-08 9:12 UTC (permalink / raw)
To: cygwin-apps
On Thu, 07 Feb 2013 19:44:37 -0500, Jason Tishler wrote:
> Sounds good.
It's done now.
> How should we handle the announcement(s)? Should each
> maintainer send their own announcement(s)? Or, should one coordinated
> announcement be sent?
Go ahead and announce 2.7.3, and mention prominently that
Python-dependent packages have been rebuilt accordingly. Everyone else
can make their announcements on their schedule.
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
` (21 preceding siblings ...)
2013-02-07 9:30 ` Yaakov
@ 2013-02-08 9:21 ` Yaakov
2013-02-08 11:50 ` Corinna Vinschen
22 siblings, 1 reply; 47+ messages in thread
From: Yaakov @ 2013-02-08 9:21 UTC (permalink / raw)
To: cygwin-apps
On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
> Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
> pylint, python-crypto, python-feedparser, python-logilab-astng,
> python-logilab-common, python-paramiko, spambayes, stgit, tailor,
> urlgrabber
> Marco Atzeri: postgresql
> Ken Brown: bzr-fastimport, python-fastimport
> Bo Peng: lyx
> David Rothenberger: rdiff-backup, subversion
> Chris Sutcliffe: googlecl, python-gdata
> Dr. Volker Zell: lcms, ming
Python 2.7.3 has been made stable, and all your packages have been
moved into release. Thank you all for helping make this happen in a
timely fashion.
Yaakov
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-08 9:21 ` Yaakov
@ 2013-02-08 11:50 ` Corinna Vinschen
2013-02-08 14:56 ` Christopher Faylor
0 siblings, 1 reply; 47+ messages in thread
From: Corinna Vinschen @ 2013-02-08 11:50 UTC (permalink / raw)
To: cygwin-apps
On Feb 8 03:21, Yaakov wrote:
> On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
> > Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
> > pylint, python-crypto, python-feedparser, python-logilab-astng,
> > python-logilab-common, python-paramiko, spambayes, stgit, tailor,
> > urlgrabber
> > Marco Atzeri: postgresql
> > Ken Brown: bzr-fastimport, python-fastimport
> > Bo Peng: lyx
> > David Rothenberger: rdiff-backup, subversion
> > Chris Sutcliffe: googlecl, python-gdata
> > Dr. Volker Zell: lcms, ming
>
> Python 2.7.3 has been made stable, and all your packages have been
> moved into release. Thank you all for helping make this happen in a
> timely fashion.
And especially thanks to you for organizing this switch! We just don't
have enough gold stars to give you the number you deserve :)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
^ permalink raw reply [flat|nested] 47+ messages in thread
* Re: HEADSUP: Python 2.7 upgrade
2013-02-08 11:50 ` Corinna Vinschen
@ 2013-02-08 14:56 ` Christopher Faylor
0 siblings, 0 replies; 47+ messages in thread
From: Christopher Faylor @ 2013-02-08 14:56 UTC (permalink / raw)
To: cygwin-apps
On Fri, Feb 08, 2013 at 12:49:30PM +0100, Corinna Vinschen wrote:
>On Feb 8 03:21, Yaakov wrote:
>> On Wed, 23 Jan 2013 18:56:56 -0600, Yaakov (Cygwin/X) wrote:
>> > Jari Aalto: bzr, codeville, getmail, mercurial, offlineimap, planet,
>> > pylint, python-crypto, python-feedparser, python-logilab-astng,
>> > python-logilab-common, python-paramiko, spambayes, stgit, tailor,
>> > urlgrabber
>> > Marco Atzeri: postgresql
>> > Ken Brown: bzr-fastimport, python-fastimport
>> > Bo Peng: lyx
>> > David Rothenberger: rdiff-backup, subversion
>> > Chris Sutcliffe: googlecl, python-gdata
>> > Dr. Volker Zell: lcms, ming
>>
>> Python 2.7.3 has been made stable, and all your packages have been
>> moved into release. Thank you all for helping make this happen in a
>> timely fashion.
>
>And especially thanks to you for organizing this switch! We just don't
>have enough gold stars to give you the number you deserve :)
Mega dittos.
cgf
^ permalink raw reply [flat|nested] 47+ messages in thread
end of thread, other threads:[~2013-02-08 14:56 UTC | newest]
Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-24 0:57 HEADSUP: Python 2.7 upgrade Yaakov
2013-01-24 5:49 ` marco atzeri
2013-01-24 9:39 ` Corinna Vinschen
2013-01-24 10:41 ` marco atzeri
2013-01-24 12:30 ` Corinna Vinschen
2013-01-24 12:51 ` marco atzeri
2013-01-26 0:09 ` szgyg
2013-01-26 5:51 ` marco atzeri
2013-01-26 23:22 ` szgyg
2013-01-28 10:35 ` Corinna Vinschen
2013-01-28 10:52 ` marco atzeri
2013-01-28 13:25 ` szgyg
2013-01-28 14:27 ` Corinna Vinschen
2013-01-24 12:29 ` Chris Sutcliffe
2013-01-26 7:56 ` RFU: bzr-2.6+b2-2 (Python 2.7 upgrade) Jari Aalto
2013-01-26 8:04 ` RFU: codeville 0.8.0-4 " Jari Aalto
2013-01-26 8:19 ` RFU: getmail 4.36.0-1 " Jari Aalto
2013-01-26 8:28 ` RFU: mercurial 2.4.2-1 " Jari Aalto
2013-01-26 8:31 ` RFU: /offlineimap 6.5.4-2 " Jari Aalto
2013-01-26 8:39 ` RFU: planet 2.0-3 " Jari Aalto
2013-01-26 8:44 ` RFU: python-crypto 2.6-3 " Jari Aalto
2013-01-26 8:49 ` RFU: python-feedparser 5.0.1-2 " Jari Aalto
2013-01-26 8:54 ` RFU: python-logilab-astng 0.23.1-2 " Jari Aalto
2013-01-26 8:58 ` RFU: python-logilab-common 0.58.0-2 " Jari Aalto
2013-01-26 9:02 ` RFU: python-paramiko 1.7.7.1-2 " Jari Aalto
2013-01-26 9:10 ` RFU: spambayes 1.0.4-2 " Jari Aalto
2013-01-26 9:18 ` RFU: stgit 0.16-2 " Jari Aalto
2013-01-26 9:23 ` RFU: tailor 0.9.35+darcs20090615-2 " Jari Aalto
2013-01-26 9:38 ` RFU: urlgrabber 3.1.0-3 " Jari Aalto
2013-02-01 2:19 ` HEADSUP: Python 2.7 upgrade Jason Tishler
2013-02-01 3:53 ` Ken Brown
2013-02-01 5:49 ` Yaakov
2013-02-01 6:40 ` Yaakov
2013-02-01 7:49 ` Dr. Volker Zell
2013-02-03 7:03 ` Yaakov
2013-02-03 10:48 ` Yaakov
2013-02-04 12:01 ` Dr. Volker Zell
2013-02-04 20:57 ` Yaakov
2013-02-04 21:17 ` Yaakov
2013-02-07 0:42 ` Samuel Thibault
2013-02-07 9:17 ` Yaakov
2013-02-07 9:30 ` Yaakov
2013-02-08 0:42 ` Jason Tishler
2013-02-08 9:12 ` Yaakov
2013-02-08 9:21 ` Yaakov
2013-02-08 11:50 ` Corinna Vinschen
2013-02-08 14:56 ` Christopher Faylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).