On 2013-04-11 01:02, Dave Korn wrote:
Yes, I've looked at most of your patches already, I'm not saying there's any
complication in adding them, it's just that I didn't want to wait another
howevermany days before getting 4.7.2-2 out there. I'll put them all into the
next release, which I'll g
On 11/04/2013 03:44, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 20:40, Dave Korn wrote:
>>Surely there'll be a problem if the curr: version of everything
>> else goes to 4.7.3-1 but there's no matching version of libffi4?
>
> Not as long as 4.5.3-3-src remains.
Well, there have been some bugf
On 11/04/2013 05:47, Christopher Faylor wrote:
> On Thu, Apr 11, 2013 at 02:21:00AM +0100, Dave Korn wrote:
>> On 11/04/2013 02:05, Dave Korn wrote:
>>> On 11/04/2013 01:18, Christopher Faylor wrote:
gcc won't be available until this is fixed.
>>> Oops. I'll just edit it on the server. Sor
On 11/04/2013 03:23, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 11:56, Dave Korn wrote:
>>It takes 11 hours on a triple-core machine at -j6 to build and
>> package GCC.
>> In order to guarantee consistent reproduction I always respin the built
>> package from -src package through two generation
Yaakov (Cygwin/X) writes:
>> The problem wasn't really downloading the patches. The patch format
>> does not apply with the options that cygport tries, so you'll have to
>> apply it manually still.
>
> Only 'allpatches' doesn't apply; the individual ones do sequentially.
Let me try again, but the
On Thu, Apr 11, 2013 at 02:21:00AM +0100, Dave Korn wrote:
>On 11/04/2013 02:05, Dave Korn wrote:
>> On 11/04/2013 01:18, Christopher Faylor wrote:
>>> gcc won't be available until this is fixed.
>>
>> Oops. I'll just edit it on the server. Sorry for the inconvenience.
>
> Should be ok now I
On 2013-04-10 08:16, Corinna Vinschen wrote:
- Does anybody know of a simple way to find out which packages in the 32
bit distro are actually "noarch' packages? The reason I'm asking is
that I'm looking for a simple way to fill up the 64 bit distro with
all the packages which don't come
On 2013-04-10 20:40, Dave Korn wrote:
Surely there'll be a problem if the curr: version of everything else goes to
4.7.3-1 but there's no matching version of libffi4?
Not as long as 4.5.3-3-src remains.
Yaakov
On 2013-04-10 10:27, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
Also, automating the patches is possible, e.g.:
PATCH_URI=$(seq -f http://www.mpfr.org/mpfr-${VERSION}/patch%02.0f 1 3)
Then use the '3' to control the number of patches available.
The problem wasn't really downloading the pat
On 2013-04-10 11:56, Dave Korn wrote:
It takes 11 hours on a triple-core machine at -j6 to build and package GCC.
In order to guarantee consistent reproduction I always respin the built
package from -src package through two generations. It then takes three to
five days to run enough of the
On 11/04/2013 02:33, Yaakov (Cygwin/X) wrote:
> After applying my libffi-noinst.patch, all you really need to do is
> remove the libffi4-4.7.* test releases and leave 4.5.3-3 in the distro
> until all libffi-dependent packages are rebuilt (most of which are mine).
Surely there'll be a problem i
On 2013-04-10 16:34, Dave Korn wrote:
On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote:
Only the man3 pages collide with gcc4-core. But gcc's libffi.dll.a will
take priority over the one in /usr/lib (see gcc -print-search-dirs), so
manual intervention will be necessary until our gcc stops shipping
On 11/04/2013 02:05, Dave Korn wrote:
> On 11/04/2013 01:18, Christopher Faylor wrote:
>> gcc won't be available until this is fixed.
>
> Oops. I'll just edit it on the server. Sorry for the inconvenience.
Should be ok now I trust. Apologies once more, I've updated my local hint
file in sv
On 11/04/2013 01:18, Christopher Faylor wrote:
> gcc won't be available until this is fixed.
Oops. I'll just edit it on the server. Sorry for the inconvenience.
cheers,
DaveK
gcc won't be available until this is fixed.
Packages for manipulating comma-separated text files in Perl.
Found in several distros: http://pkgs.org/search/?keyword=perl-Text-CSV
# 32-bit
BASEURL=https://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=4 \
${BASEURL}/uVaNv
On 10/04/2013 10:50, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 04:29, Corinna Vinschen wrote:
>> On Apr 10 04:06, Yaakov (Cygwin/X) wrote:
>>> libffi development moved out of GCC into a separate project a long
>>> time ago; the copy included in GCC is used for libgcj, but only as a
>>> convenience (
Corinna Vinschen wrote:
On Apr 10 18:59, Christian Franke wrote:
New 64bit package with command named "hostname", category changed to "Base":
[...]
64 bit version uploaded, together with the new hostname-less coreutils
package.
But I almost screwed this up. You renamed the dir to hostname2,
On Apr 10 18:59, Christian Franke wrote:
> Corinna Vinschen wrote:
> >On Apr 10 09:57, Corinna Vinschen wrote:
> >>On Apr 9 22:55, Christian Franke wrote:
> >>>I would like to contribute the (Debian) Linux version of hostname(1)
> >>>and would suggest to remove the GNU hostname command from coreut
On 4/10/2013 3:16 PM, Corinna Vinschen wrote:
Greetings venerable maintainers,
- Those of you testing the 64 bit Cygwin: How do you judge the
stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or
are we in a stage where we can offically open up the test distro to a
wide
Corinna Vinschen wrote:
On Apr 10 09:57, Corinna Vinschen wrote:
On Apr 9 22:55, Christian Franke wrote:
I would like to contribute the (Debian) Linux version of hostname(1)
and would suggest to remove the GNU hostname command from coreutils
package.
This version of hostname allows to show th
On 10/04/2013 16:47, Christopher Faylor wrote:
> It isn't clear to me why we'd be spending days discussing this when
> presumably the patches apply without too much effort. Some of the
> patches here:
>
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
>
> look worthwh
On Apr 10 16:49, Dave Korn wrote:
> On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
>
> > Could you explain the necessity of the dllimport's in the same patch?
>
> The idea is to one day be able to move away from having auto-import enabled
> by default in binutils, so that .rdata can go back into
Yaakov (Cygwin/X) writes:
>> When installing, make sure you de-install all old packages to avoid old
>> files sticking around due to the package renames.
>
> We can create obsolete packages to handle the renames; just remind me
> in the RFU.
If that just entails creating an empty package ppl-devel
Corinna Vinschen writes:
> - Those of you testing the 64 bit Cygwin: How do you judge the
> stability of the 64 bit Cygwin DLL? Is it still rather pre-beta, or
> are we in a stage where we can offically open up the test distro to a
> wider audience?
I haven't used it for a longer stretch t
On Wed, Apr 10, 2013 at 05:31:55PM +0200, Achim Gratz wrote:
>Dave Korn writes:
>> I have a release of 4.7.2-2 ready to upload. It fixes the dependencies
>> back
>> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
>> work and restores java and libffi. I've also been
On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
> Could you explain the necessity of the dllimport's in the same patch?
The idea is to one day be able to move away from having auto-import enabled
by default in binutils, so that .rdata can go back into the read-only-mapped
.rdata section and be sh
Dave Korn writes:
> I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back
> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
> work and restores java and libffi. I've also been running the testsuite over
> the last few days and the results look
Yaakov (Cygwin/X) writes:
> On 2013-04-02 10:27, Achim Gratz wrote:
>> I've added test packages compiled with gcc-4.7.2-1 (to be installed by
>> manually selecting them, like the test version of gcc itself):
>
> FYI, 3.1.2 is out now.
I know, but since it is just a rollup of the three patches that
On Apr 10 03:38, NightStrike wrote:
> On Wed, Apr 10, 2013 at 3:16 AM, Corinna Vinschen wrote:
> > Greetings venerable maintainers,
> >
> >
> > I have two questions:
> >
> > - Does anybody know of a simple way to find out which packages in the 32
> > bit distro are actually "noarch' packages? Th
On Wed, Apr 10, 2013 at 3:16 AM, Corinna Vinschen wrote:
> Greetings venerable maintainers,
>
>
> I have two questions:
>
> - Does anybody know of a simple way to find out which packages in the 32
> bit distro are actually "noarch' packages? The reason I'm asking is
> that I'm looking for a si
On 4/10/2013 9:16 AM, Corinna Vinschen wrote:
Greetings venerable maintainers,
I have two questions:
- Does anybody know of a simple way to find out which packages in the 32
bit distro are actually "noarch' packages? The reason I'm asking is
that I'm looking for a simple way to fill up
Greetings venerable maintainers,
I have two questions:
- Does anybody know of a simple way to find out which packages in the 32
bit distro are actually "noarch' packages? The reason I'm asking is
that I'm looking for a simple way to fill up the 64 bit distro with
all the packages which do
Hi kiddies,
I just uploaded the 64 bit cygwin 1.7.18-18 package. About 4 weeks ago
I ripped out ptmalloc3. The reason was ptmalloc3 always used mmap.
Duplicating many mmaps at fork time is noticably less performant than
duplicating the heap, so I thought ptmalloc3 is not useful for us.
However
On 2013-04-10 06:49, Charles Wilson wrote:
BTW, which processor do we target these days in 32bit cygwin, as that
will affect which SIMD instruction set is enabled whn libjpeg-turbo is
built? i686?
i686-pc-cygwin-gcc is configured with --with-arch=i686 --with-tune=generic.
Yaakov
On 4/10/2013 4:03 AM, Yaakov (Cygwin/X) wrote:
The libjpeg-turbo project provides SIMD acceleration while remaining API
and ABI compatible with IJG libjpeg 6b/7/8 (based on configure flags). I
have been using this libjpeg8 locally instead of the IJG one from the
distro for some time, and have see
On 2012-12-15 23:06, Yaakov (Cygwin/X) wrote:
Chuck,
Security vulnerabilities have been announced for the tiff package.
Please update tiff to 3.9.7 together with this patchset ASAP:
http://pkgs.fedoraproject.org/cgit/libtiff.git/tree/?h=f17
http://cygwin-ports.git.sourceforge.net/git/gitweb.c
On 2013-04-06 05:45, Achim Gratz wrote:
Packages orphaned by David Billinghurst.
Test version for gcc-4.7.2 only.
GTG.
When installing, make sure you de-install all old packages to avoid old
files sticking around due to the package renames.
We can create obsolete packages to handle the ren
On 2013-04-09 11:11, Dave Korn wrote:
On 09/04/2013 11:30, Yaakov (Cygwin/X) wrote:
On 2013-04-09 02:08, Dave Korn wrote:
On 25/03/2013 08:52, Corinna Vinschen wrote:
On Mar 24 03:33, Yaakov (Cygwin/X) wrote:
In any case, the error is a result of adding one of Dave Korn's
patches:
http://cyg
On 2013-04-10 04:29, Corinna Vinschen wrote:
On Apr 10 04:06, Yaakov (Cygwin/X) wrote:
libffi development moved out of GCC into a separate project a long
time ago; the copy included in GCC is used for libgcj, but only as a
convenience (static) library, and it is usually a few point releases
behi
On 2013-04-02 10:27, Achim Gratz wrote:
I've added test packages compiled with gcc-4.7.2-1 (to be installed by
manually selecting them, like the test version of gcc itself):
PKG_CONTENTS[] is deprecated. Instead, do:
mpclib_CONTENTS='usr/share'
libmpc3_CONTENTS='usr/bin/cygmpc-3.dll'
libmpc_d
On 2013-04-02 10:27, Achim Gratz wrote:
I've added test packages compiled with gcc-4.7.2-1 (to be installed by
manually selecting them, like the test version of gcc itself):
FYI, 3.1.2 is out now.
Also, automating the patches is possible, e.g.:
PATCH_URI=$(seq -f http://www.mpfr.org/mpfr-${VE
On 2013-04-02 10:26, Achim Gratz wrote:
I've added test packages compiled with gcc-4.7.2-1 (to be installed by
manually selecting them, like the test version of gcc itself):
Style point: doins can take multiple arguments at once, and for
installing docs, use docinto/dodoc instead, e.g.:
doci
On Apr 10 09:57, Corinna Vinschen wrote:
> On Apr 9 22:55, Christian Franke wrote:
> > I would like to contribute the (Debian) Linux version of hostname(1)
> > and would suggest to remove the GNU hostname command from coreutils
> > package.
> >
> > This version of hostname allows to show the FQDN
On Apr 10 04:06, Yaakov (Cygwin/X) wrote:
> libffi development moved out of GCC into a separate project a long
> time ago; the copy included in GCC is used for libgcj, but only as a
> convenience (static) library, and it is usually a few point releases
> behind the standalone version. Finally, las
libffi development moved out of GCC into a separate project a long time
ago; the copy included in GCC is used for libgcj, but only as a
convenience (static) library, and it is usually a few point releases
behind the standalone version. Finally, last month, GCC was patched
upstream to stop inst
Chuck (and other affected parties),
The libjpeg-turbo project provides SIMD acceleration while remaining API
and ABI compatible with IJG libjpeg 6b/7/8 (based on configure flags).
I have been using this libjpeg8 locally instead of the IJG one from the
distro for some time, and have seen no ABI
On Apr 9 22:55, Christian Franke wrote:
> I would like to contribute the (Debian) Linux version of hostname(1)
> and would suggest to remove the GNU hostname command from coreutils
> package.
>
> This version of hostname allows to show the FQDN (-f), DNS domain
> name (-d, dnsdomainname), alias n
On Apr 9 17:17, Dave Korn wrote:
>
> Hi all,
>
> I have a release of 4.7.2-2 ready to upload. It fixes the dependencies back
> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
> work and restores java and libffi. I've also been running the testsuite over
> the
49 matches
Mail list logo
