HEADSUP: Python 2.7 upgrade

HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[marco atzeri]

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

Re: HEADSUP: Python 2.7 upgrade

[Corinna Vinschen]

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

Re: HEADSUP: Python 2.7 upgrade

[marco atzeri]

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
>

Re: HEADSUP: Python 2.7 upgrade

[Corinna Vinschen]

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

Re: HEADSUP: Python 2.7 upgrade

[marco atzeri]

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

Re: HEADSUP: Python 2.7 upgrade

[szgyg]

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

Re: HEADSUP: Python 2.7 upgrade

[marco atzeri]

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

Re: HEADSUP: Python 2.7 upgrade

[szgyg]

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

Re: HEADSUP: Python 2.7 upgrade

[Corinna Vinschen]

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

Re: HEADSUP: Python 2.7 upgrade

[marco atzeri]

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

Re: HEADSUP: Python 2.7 upgrade

[szgyg]

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

Re: HEADSUP: Python 2.7 upgrade

[Corinna Vinschen]

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

Re: HEADSUP: Python 2.7 upgrade

[Chris Sutcliffe]

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

RFU: bzr-2.6+b2-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: codeville 0.8.0-4 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: getmail 4.36.0-1 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: mercurial 2.4.2-1 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: /offlineimap 6.5.4-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: planet 2.0-3 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: python-crypto 2.6-3 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: python-feedparser 5.0.1-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: python-logilab-astng 0.23.1-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: python-logilab-common 0.58.0-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: python-paramiko 1.7.7.1-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: spambayes 1.0.4-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: stgit 0.16-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: tailor 0.9.35+darcs20090615-2 (Python 2.7 upgrade)

[Jari Aalto]

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

RFU: urlgrabber 3.1.0-3 (Python 2.7 upgrade)

[Jari Aalto]

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

Re: HEADSUP: Python 2.7 upgrade

[Jason Tishler]

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

Re: HEADSUP: Python 2.7 upgrade

[Ken Brown]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Dr. Volker Zell]

>>>>> 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
  

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Dr. Volker Zell]

>>>>> 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
  

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Samuel Thibault]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Jason Tishler]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Yaakov]

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

Re: HEADSUP: Python 2.7 upgrade

[Corinna Vinschen]

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

Re: HEADSUP: Python 2.7 upgrade

[Christopher Faylor]

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