Re: ITP: googlecl-0.9.7

2010-06-30 Thread Andy Koppe
On 30 June 2010 13:11, Chris Sutcliffe wrote: > On 28 June 2010 09:27, Christopher Faylor wrote: >> If it is not officially in a distribution then it needs to be >> voted on. > > It officially will be part of Fedora 13: > > https://admin.fedoraproject.org/pkgdb/collections/name/F-13?tg_paginate_lim

Re: ITP: python-gdata-2.0.10

2010-06-30 Thread Yaakov (Cygwin/X)
On Wed, 2010-06-23 at 21:33 -0400, Chris Sutcliffe wrote: > Thank you for the quick review and the tip on the cygport. I've > uploaded new versions based on the revised cygport: > > wget -x -nH --cut-dirs=3 \ > http://emergedesktop.org/cygwin/python-gdata/python-gdata-2.0.10-1.tar.bz2 \ > http://

Re: [RFU] flk, fltk_gdi (take2)

2010-06-30 Thread Yaakov (Cygwin/X)
On Wed, 2010-06-30 at 23:15 +0200, A.R. Burgers wrote: > I've uploaded a 2nd try, simplified a lot. > Thanks to Yaakov for his feedback. > > If ok this should supersede 1.1.8r5648-1, which should be left as previous. > http://members.quicknet.nl/ar.burgers/cygwin17/fltk/libfltk1.1/setup.hint \ >

Re: [ITP] mingw-w64

2010-06-30 Thread Charles Wilson
On 6/30/2010 2:06 PM, JonY wrote: Thanks, I will check it out. (btw, libtool too needs to get an epoch version, having problems with macro version mismatches in gcc cygautoreconf). Oh boy. Yeah, I would imagine so. The gcc-tools-* stuff was added to support Dave Korn's needs when building the

Re: ITP: python-gdata-2.0.10

2010-06-30 Thread Chris Sutcliffe
On 30 June 2010 15:16, Yaakov (Cygwin/X) wrote: > On Wed, 2010-06-30 at 16:41 +0200, Corinna Vinschen wrote: >> Yaakov?  You were already looking into this and I'm not python aware. >> WOuld you mind to have another look if that package is ok now? > > If he's using my .cygport files then *I* am sur

[RFU] flk, fltk_gdi (take2)

2010-06-30 Thread A.R. Burgers
LS, I've uploaded a 2nd try, simplified a lot. Thanks to Yaakov for his feedback. If ok this should supersede 1.1.8r5648-1, which should be left as previous. fetching all in one go: wget -r -np -nH -x --cut-dirs=2 -R index*,*.css ,.gif \ http://members.quicknet.nl/ar.burgers/cygwin17/f

Re: [ITP] mingw-w64

2010-06-30 Thread Charles Wilson
On 6/30/2010 1:51 PM, JonY wrote: On 7/1/2010 00:36, Charles Wilson wrote: I don't know much about sf's buildbot; I assume that if you can get a cygport to DTRT on your home PC without human intervention except for kicking off the build, then you can convince the buildbot to do it for you? Ri

Re: [ITP] mingw-w64

2010-06-30 Thread NightStrike
On Wed, Jun 30, 2010 at 3:34 PM, Charles Wilson wrote: > On 6/30/2010 2:53 PM, NightStrike wrote: >> >> On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote: >>> >>> Hmm. So, big picture, we have possibly three different mingw-ish >>> compilers, >>> and you're currently attempting to shepherd th

Re: [ITP] mingw-w64

2010-06-30 Thread Charles Wilson
On 6/30/2010 2:53 PM, NightStrike wrote: On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote: Hmm. So, big picture, we have possibly three different mingw-ish compilers, and you're currently attempting to shepherd the first one, while being mindful of future issues related to simultaneous ins

Re: ITP: python-gdata-2.0.10

2010-06-30 Thread Yaakov (Cygwin/X)
On Wed, 2010-06-30 at 16:41 +0200, Corinna Vinschen wrote: > Yaakov? You were already looking into this and I'm not python aware. > WOuld you mind to have another look if that package is ok now? If he's using my .cygport files then *I* am sure they are, but I thought it would be appropriate for s

Re: [ITP] mingw-w64

2010-06-30 Thread NightStrike
On Wed, Jun 30, 2010 at 12:36 PM, Charles Wilson wrote: > Hmm. So, big picture, we have possibly three different mingw-ish compilers, > and you're currently attempting to shepherd the first one, while being > mindful of future issues related to simultaneous installation of both of the > first two:

Re: [ITP] mingw-w64

2010-06-30 Thread JonY
On 7/1/2010 00:49, Charles Wilson wrote: As an aside, to compile with a different prefix using cygport requires a bit of work right now, because AFAIK cygport doesn't support anything but --prefix=/usr. See http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-auto

Re: [ITP] mingw-w64

2010-06-30 Thread JonY
On 7/1/2010 00:36, Charles Wilson wrote: On 6/29/2010 1:13 PM, JonY wrote: On 6/30/2010 00:10, Charles Wilson wrote: Now, I thought you wanted to use the w64 prefix as a "project origin" indicator, and assumed that "-mingw64-" would be the "target bitdepth" indicator. However, given "w64-mingw6

Re: [ITP] mingw-w64

2010-06-30 Thread Charles Wilson
As an aside, to compile with a different prefix using cygport requires a bit of work right now, because AFAIK cygport doesn't support anything but --prefix=/usr. See http://cygwin.osuosl.org/release/autoconf/gcc-tools-epoch2-autoconf/gcc-tools-epoch2-autoconf-2.64-1-src.tar.bz2 for how I did i

Re: [ITP] mingw-w64

2010-06-30 Thread Charles Wilson
On 6/29/2010 1:13 PM, JonY wrote: On 6/30/2010 00:10, Charles Wilson wrote: Now, I thought you wanted to use the w64 prefix as a "project origin" indicator, and assumed that "-mingw64-" would be the "target bitdepth" indicator. However, given "w64-mingw64-pthreads-devel32" and "w32-mingw64-pthre

[ITA] cyrus-sasl

2010-06-30 Thread David Rothenberger
I would like to adopt cyrus-sasl. It is listed as orphaned and Gareth Pearce recently indicated he was not planning to repackage it.[1] I have added two new packages with LDAP and SQL plugins. cyrus-sasl.hint -- sdesc: "The Cyrus

Re: ITP: python-gdata-2.0.10

2010-06-30 Thread Corinna Vinschen
On Jun 27 18:02, Chris Sutcliffe wrote: > On 23 June 2010 21:33, Chris Sutcliffe wrote: > > Thank you for the quick review and the tip on the cygport.  I've > > uploaded new versions based on the revised cygport: > > > > --- > > > > wget -x -nH --cut-dirs=3 \ > > http://emergedesktop.org/cygwin/pyt

Re: ITP: googlecl-0.9.7

2010-06-30 Thread Chris Sutcliffe
On 28 June 2010 09:27, Christopher Faylor wrote: > If it is not officially in a distribution then it needs to be > voted on. It officially will be part of Fedora 13: https://admin.fedoraproject.org/pkgdb/collections/name/F-13?tg_paginate_limit=0&_csrf_token=2d176377b6cdff78cd6eccc7fcfbe0a686917e6