>From 1686e0beac98867bf1fe358a8fe9a9d8647d4a3a Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 8 Feb 2013 20:58:20 +0100
Subject: [PATCH 1/4] Remove detrimental initialization
* choose.cc (createListview): Remove superflous and detrimental
default trust setting. This
Corinna Vinschen writes:
> I think that would make sense. I'm, not too sure what exactly you're
> doing in this patch.
I hope it is a bit more clear now, otherwise just ask (or consult the
thread from February).
> It looks a bit intrusive for adding two options.
Four, actually. I've split out
Yaakov (Cygwin/X) writes:
> I wanted to get feedback from those using cygport regarding a possible
> new feature: PKG_OBSOLETES. This is best explained with an example,
> so let's say I had the following:
[..]
> The attached patch is what I'm working with at the moment. Thoughts?
Looks good to m
Since the patch from February doesn't apply anymore, I've pulled the
patch up to apply to the current CVS head:
http://repo.or.cz/w/cygwin-setup.git/patch/858289a3ebe90989e3eca123018aff84ad5f2d50
I've not split the patch into three parts, let me know if you prefer me
to do that again.
Remark:
There's a spurious space in the definition of @SETUP@_LDADD line in
Makefile.am in line 103. As long as it stays with the continuation line
this has no consequences of course.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rac
Corinna Vinschen writes:
>> The mingw toolchain on a (32bit only) test machine at work still
>> functions correctly, but the compilation aborts because KEY_WOW64_64KEY
>> and KEY_WOW64_32KEY are not defined.
>
> Building with mingw.org toolchain isn't supported anymore. Use the
> Mingw-w64 toochai
The configury does not check whether static libraries are present, but
unconditionally requests '-static' when linking.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf Q+, Q and microQ:
http://Synth.Stromeko.net
The mingw toolchain on a (32bit only) test machine at work still
functions correctly, but the compilation aborts because KEY_WOW64_64KEY
and KEY_WOW64_32KEY are not defined.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf microQ
Christopher Faylor writes:
>>The setup-version: tag is missing from those setup.ini files at the
>>moment
>
> That was unintentional and now fixed.
Thank you.
>>and the process to generate them seems to have been started one
>>directory level up (paths are starting with x86/ rather than release).
Christopher Faylor writes:
> The setup.ini's used by these two new programs are not
> backwards-compatible with old setup.exe.
The setup-version: tag is missing from those setup.ini files at the
moment and the process to generate them seems to have been started one
directory level up (paths are st
Yaakov (Cygwin/X) writes:
>> Ah, good point. I'll check tomorrow and make a more comprehensive list.
>
> Attached.
To register what has been discussed before in this thread: I can provide
upx for 64bit if anybody wants it, but unfortunately it can't deal with
64bit executables and therefore is ne
Yaakov (Cygwin/X) writes:
> * gcc4-* are replaced by upgrade helpers for gcc-* 4.7.
I did a completely fresh installation of Cygwin for a colleague today
and it broke due to missing gcc-4 and g++-4 links (since it hadn't been
upgraded). It was easily fixed, but I think the current package needs
t
Charles Wilson writes:
> I'll roll a new release of the mingw(.org) toolchain in the next
> week.
I've compiled setup.exe with the mingw toolchain without any errors and
I have not found any executable from the mingw toolchain that actually
links against the libmpc1 library. Maybe I didn't look c
Christopher Faylor writes:
> I don't see why. The ports stuff could also go into the mix under the
> x86* directories.
That would make it more difficult to use seperately mirrored directories
(not downloaded via setup.exe) for installation.
> I presume that now it is only separated by the mirror
Christopher Faylor writes:
> I don't think that anyone was saying that we want one setup.ini to be
> able to handle both distributions though. That certainly isn't the way
> that I've been slowly setting things up on sourceware.org. And, maybe
> more importantly, I don't like the idea so I'm not
Yaakov (Cygwin/X) writes:
> * gcc-mingw-* 3.x (-mno-cygwin support files) are replaced by upgrade
> helpers for mingw-gcc-*.
>
> * All curr/prev/test tags are removed from
> gmp/mpfr/mpclib/ppl/isl/cloog-ppl/cloog-isl, making the latest
> versions current.
I can't test it myself at the moment, but
Corinna Vinschen writes:
> Uh, oh. If you have two different HEAD versions on 32 and 64 bit, how
> do you express this? This complicates the setup.ini handling a lot.
> Personally I'm glad if I don't have to dig too deeply in the weird setup
> C++ code.
I've just put it out there if anybody felt
Corinna Vinschen writes:
>> Having said that, I could also change setup so that any setup.ini file
>> which is not under a $target subdir is still recognized, but only when
>> trying to install a 32 bit Cygwin. This should make the code backward
>> compatible with existing layouts.
I'm usually fo
Corinna Vinschen writes:
>> The change itself breaks a few cases that maybe aren't supported,
>> but nevertheless worked for quite some time.
>
> What cases?
I have abandoned this directory layout some time ago, but I was doing
things like
…/mirror/cygwin/
…/mirror/cygport/
…/local/patch/
…/local
Corinna Vinschen writes:
> + if (--level >= 0)
[...]
> + Find(".").accept(found_ini, 2);// Only search one level deep.
If you would use post-decrement, then that comment would be a bit less
puzzling (after the change of 2->1), I'd think.
The change itself breaks a few cases that maybe aren'
May I suggest that this sort of link (and the similar one in
cygwinports) has potential to break mirror scripts in bad ways? Not
quite as bad, but linking x86_64 -> 64bit also results in duplicates
that aren't serving a good purpose.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQ
JonY writes:
> All the new ppl/mpc/mpfr/gmp that were marked experimental needs to be
> switched to stable at the same time gcc-4.7.x or else gcc would be
> broken for awhile without those DLLs.
When do you plan to roll a new gcc package? I would want to re-compile
these with 4.7.3 just to be sur
Ken Brown writes:
> Maybe I'm missing something, but I don't see the need for bundle
> packages.
Certainly there is no need to bundle in many cases. But if there is
(like with perl_vendor), I think it is easy.
> Take the example of biber. I had to build a bunch of perl-*
> packages, and cygpor
JonY writes:
> I noticed some deps are still marked as experimental, eg
> cloog/ppl/mpc/mpfr/gmp. Parts of the experimental ppl even requires
> experimental 4.7.x libstdc++.
That's because gcc-4.5.3 stops working when these packages get
installed.
> setup constantly tries to revert it to stable v
Reini Urban writes:
> If you really want to maintain 2000+ packages do it. I don't care.
Nobody suggested that all of a sudden Cygwin should come with all CPAN
distributions pre-bundled. My current guess, based on my own usage,
would be on the order of 300 packages.
> I hope you know what happen
Reini Urban writes:
> I would also favor using biber as non-packaged perl script.
+1
> Since you need so many perl deps, do you really want to keep them seperate?
Yes, I would want _all_ non-core Perl distributions as separate cygwin
packages. That's the only sane way to deal with these when th
Yaakov (Cygwin/X) writes:
> If you're talking about perl_vendor, I think that's going to go away
> soon enough.
Last I suggested this to Reini he said he wasn't really considering it,
IIRC. I have been packaging perl_vendor as a bundle of separate perl
distributions locally for almost two years n
Yaakov (Cygwin/X) writes:
> Several people have mentioned changes they would like to see in
> cygport's documentation. I believe the stable APIs are all documented
> now, but what more would you like to see in the docs?
I guess from my own (still growing) experience that a tutorial or
similarly s
Yaakov (Cygwin/X) writes:
> Could you add isl and cloog-isl to the i686 distro as well? They are
> needed for the 32-to-64 cross-compiler which some maintainers need to
> build their packages for x86_64.
These are all test packages built with gcc-4.7.2-2 and linked against
the test package for GM
Yaakov (Cygwin/X) writes:
>> release/cloog-ppl/libcloog-doc/libcloog-doc-0.15.11-2.tar.bz2
>> release/cloog-ppl/libcloog-doc/setup.hint
>
> I removed this per your request.
Please re-instantiate, see below.
>> release/cloog-isl/libcloog-doc/libcloog-doc-0.18.0-2.tar.bz2
>
> I uploaded this as lib
Yaakov (Cygwin/X) writes:
> Could you add isl and cloog-isl to the i686 distro as well? They are
> needed for the 32-to-64 cross-compiler which some maintainers need to
> build their packages for x86_64.
Will do. I will also roll a new release for 64bit after correcting the
problem with the info
Achim Gratz writes:
> release/cloog-ppl/libcloog-doc/libcloog-doc-0.15.11-2.tar.bz2
> release/cloog-ppl/libcloog-doc/setup.hint
These need to be removed, sorry (the doc archive could be moved to
cloog-isl/libcloog-doc as well).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron
Achim Gratz writes:
> I'll re-package and re-test, should be ready on Sunday.
I guess Yaakov should upload in case something is still wrong….
As near as I can tell, the following directories are remnants from the
first aborted upload and should be removed:
cloog/
cloog-ppl/cloog-p
Yaakov (Cygwin/X) writes:
> Sticking with mpclib is easier.
OK.
>> What do your rules resolve to w.r.t. libgmp-doc, libmpfr-doc,
>> libmpc-doc? That's what they're named on 32bit and those were the
>> trigger for me having second thoughts about the whole naming exercise in
>> the first place.
>
Yaakov (Cygwin/X) writes:
>> MPC is called mpclib in 32bit and libmpc in 64bit — which one to
>> keep?
>
> While the libmpc name makes more sense IMO, as we're already using
> mpclib, you could stick with that. Only the source package uses this
> name, so changing this now won't really affect anyt
Yaakov (Cygwin/X) writes:
> I would prefer that we stick with the naming used for the existing
> 64bit packages, which would not require a bunch of renamings on the
> 32bit side either.
You are asking for the impossible. These two don't resolve:
MPC is called mpclib in 32bit and libmpc in 64bit
Reini Urban writes:
> On Mon, Apr 29, 2013 at 1:52 PM, Achim Gratz wrote:
>> today I was trying to clean up my Perl installation by removing all of
>> site_perl on Cygwin and I noticed that Class:ISA (which is supposed to
>> be a core module) was suddenly missing. Is ther
Yaakov (Cygwin/X) writes:
> Sorry, I've been on the road for much of the last week.
Thanks, I figured as much… which is why I was waiting to ask until I saw
some activity from you again. :-)
> * libraries are libfooN (containing cygfoo-N.dll) and libfoo-devel
> (containing headers, libfoo.*, .pc
Hi Yaakov,
Achim Gratz writes:
> If you think any of this is in error or should be done differently, let
> me know and I'll repackage.
would you mind letting me know how to repackage so I can free some time
to actually do it? Otherwise, please install as described in my
original mail
Hi Reini,
today I was trying to clean up my Perl installation by removing all of
site_perl on Cygwin and I noticed that Class:ISA (which is supposed to
be a core module) was suddenly missing. Is there a particular reason
Perl has been packaged without it (whereas perl-5.10.1 had it)?
Regards,
A
Achim Gratz writes:
> Not to me obviously, after the third error I made because each one of
> these was packaged and named differently it felt like a step forward
> when I finally corrected it. That's why I've been asking for naming
> rules earlier, but none have been fo
Yaakov (Cygwin/X) writes:
> I'm sorry, but this looks like a step backwards.
Not to me obviously, after the third error I made because each one of
these was packaged and named differently it felt like a step forward
when I finally corrected it. That's why I've been asking for naming
rules earlier
After some false starts trying to get things play well together, I've
done extensive changes to the packaging so it becomes more coherent, to
me anyway. I hope this makes the maintenance a bit easier in the long
run, but if anybody has any questions about this, please ask.
Therefore I would like
marco atzeri writes:
> upstream decision not mine on latest versions;
> for that reason on octave the qhull check is like this:
>
> OCTAVE_CHECK_LIB(qhull, QHull,
> [Qhull library not found -- this will result in loss of
> functionality of some geometry functions.],
> [libqhull/libqhull.h qhull
Hi Marco,
the includes are in /usr/include/libqhull on Cygwin, but all software
using it I've found so far expects to find them in /usr/include/qhull
instead. I've simply dropped a link on my system, but could you explain
why you've chosen libqhull?
Regards
Achim.
--
+<[Q+ Matrix-12 WAVE#46+3
Hi Yaakov,
as you know I have been using a modified version of cygport to make more
extensive use of version-less cygport files and patches and to more
generally allow the omission of the ".cygport" suffix on the command
line. For want of a better word I've called these changes "rpm-style".
To av
I've realized that both packages try to install
/usr/share/info/cloog.info. Simply renaming the file doesn't work since
the directory entry will be wrong. I could drop libcloog-ppl-doc and
only provide this via libcloog-isl-doc or I'd have to patch the texinfo
sources to change the directory ent
Sorry, I made another mistake. Can the version in the setup.hint file
for mpfr-debuginfo please be corrected to 3.1.2-1 (the release number is
wrongly -2 at the moment)?
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http
Corinna Vinschen writes:
> Strange that nobody did it so far.
If it's any consolation, no 64bit formats are supported, not just PE+.
Somebody's been rumoured to have worked (and then stopped working) on
x86_64 support, but I haven't found any traces of actual code yet.
> It should be rather triv
Corinna Vinschen writes:
> the 64 bit Cygwin seems to be quite stable now. We're still suffering
> from a gcc problem which seems to affect C++ inline methods using
> templates, so some C++ packages might not be buildable yet(*), but other
> than that it looks pretty good.
I'll update my 64bit in
Andrew Schulman writes:
> http://cygwin.com/goldstars/#AG
Glad to be of service.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Corinna Vinschen writes:
> Uploaded. The libgmp10/setup.hint file was missing a "test:"
> line. I added that on cygwin.com.
Thank you for fixing that.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptation for Waldorf rackAttack V1.04R1:
http://
Yaakov (Cygwin/X) writes:
> On 2013-04-18 12:37, Achim Gratz wrote:
>> $wget/ppl/libppl-devel/setup.hint
>
> FYI, there is no obsoletes: tag. I created the necessary upgrade
> helper for ppl-devel and marked it as test:.
Thanks. Since I guess this will come up again, could
Yaakov (Cygwin/X) writes:
> On 2013-04-18 12:32, Achim Gratz wrote:
>> Test packages built with gcc-4.7.2-2, please upload as test and leave
>> current and previous unchanged. The bundled setup.hint files only set
>> the test version, I hope this works as intended with upse
Test packages built with gcc-4.7.2-2, please upload as test and leave
current and previous unchanged. The bundled setup.hint files only set
the test version, I hope this works as intended with upset.
# The first line sets up shell variable wget, to be used by all later lines
# simply paste into th
Test packages built with gcc-4.7.2-2, please upload as test and leave
current and previous unchanged. The bundled setup.hint files only set
the test version, I hope this works as intended with upset.
# The first line sets up shell variable wget, to be used by all later lines
# simply paste into th
Test packages built with gcc-4.7.2-2, please upload as test and leave
current and previous unchanged. The bundled setup.hint files only set
the test version, I hope this works as intended with upset.
# The first line sets up shell variable wget, to be used by all later lines
# simply paste into th
Test packages built with gcc-4.7.2-2, please upload as test and leave
current and previous unchanged. The bundled setup.hint files only set
the test version, I hope this works as intended with upset.
# The first line sets up shell variable wget, to be used by all later lines
# simply paste into th
Test packages built with gcc-4.7.2-2, please upload as test and leave
current and previous unchanged. The bundled setup.hint files only set
the test version, I hope this works as intended with upset.
# The first line sets up shell variable wget, to be used by all later lines
# simply paste into th
Andy Koppe writes:
> I'm struggling to get setup.hint generation to work. Is it supported
> with cygport 0.11.3 as currently in the distros? Below is the
> mintty.cygport I've got. Do I need to do anything else to trigger it?
Try the cygport from Git master, I believe it should fix that.
Regards
Test packages built with gcc-4.7.2-2, TLS is enabled and finally passing
all tests for MPFR. I would appreciate if someone could check if the
setup.hint files are correct before I send an RFU (or if I should omit
them). If there's anything else I should change or check before RFU,
please let me
While the mirror script pulls down the shiny new gcc from Dave…
Charles Wilson writes:
> #1) Is it possible to also record cygwin-specific README content
> within the cygport(5)? [1] If so, can you do more than one? (I'm
> thinking here of inetutils, which has a separate cygwin-specific
> README f
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
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
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 r
Charles Wilson writes:
> On 4/7/2013 7:11 AM, Achim Gratz wrote:
>>
>> I've just set up a Cygwin64 system. It seems I can run a 32bit Cygwin
>> in parallel without disturbing anything, is that right?
>
> FYI, unless I've misinterpreted, I think you need
Ken Brown writes:
> I recall something like this happening when I first switched to the
> new-style cygport files. The problem turned out to be that I wasn't
> giving the full name of the cygport file in the command line. If your
> file is `foo.cygport', you have to type
>
> cygport foo.cygport
I've just set up a Cygwin64 system. It seems I can run a 32bit Cygwin
in parallel without disturbing anything, is that right?
Anyway, I've tried to compile a few packages, but cygport gives me
grief: it somehow doesn't pick up the version and release from new-style
cygport files and defines P ==
Packages orphaned by David Billinghurst.
Test version for gcc-4.7.2 only.
- updated to the versions recommended for gcc-4.7.2
- packaging changed according to the cygport files from Yaakov
Please wait for RFU, upon acceptance the package will be rebuilt with
new binutils and the Cygwin README fi
Yaakov (Cygwin/X) writes:
>> I'm looking at ppl right now. Is there any reason not to package the
>> latest version (1.0)?
>
> 0.11.x is the recommended version for GCC 4.7.
It will either have to be 0.11.2 or 1.1pre8 since the 0.12 and 1.0
series don't compile with gmp-5.1.1. I still prefer the
NightStrike writes:
> You might want to consider zipping ahead to the recently released 4.8
> where ppl isn't allowed anymore and you have to use isl as the cloog
> backend.
I'm operating under the assumption that there will be a release for
gcc-4.7.2 and that these packages should be available fo
Yaakov (Cygwin/X) writes:
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/ppl
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/cloog-ppl
I'm looking at ppl right now. Is there any reason not to package the
latest version (1.0)?
Regards,
Achim.
--
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):
wget="wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release";
$wget/mpclib/setup.hint
$wget/mpclib/mpclib-1.0.1-1-src.tar.bz2
$wget/mpclib/mpclib-1.0.1-1.tar.b
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):
wget="wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release";
$wget/mpfr/setup.hint
$wget/mpfr/mpfr-3.1.1-1-src.tar.bz2
$wget/mpfr/mpfr-3.1.1-1.tar.bz2
$wget/mp
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):
wget="wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release";
$wget/gmp/setup.hint
$wget/gmp/gmp-4.3.2-2.tar.bz2
$wget/gmp/gmp-4.3.2-2-src.tar.bz2
$wget/gmp/gm
Christopher Faylor writes:
> Have you considered the implications of having someone else do your
> packages? That means potentially different setup.hint, potentially
> different versions and version-numbering schemes, and possible
> source-level patches which you have not touched.
My (maybe fault
> 1) Yes.
> 2) N/A
> 3) Yes (but not in the next two or three weeks).
> 4) No.
> 5) No.
> 6) Yes, as long as they don't pretend to be me.
> 7) Yes, if that helps to speed up things.
My working assumption is that the differences between the two
architectures can nearly be absorbed by cygport so tha
Corinna Vinschen writes:
> Looks ok for upload to me. ucl is not a subpackge of upx right now,
> so I guess we don't have to change that.
Thanks. I was just asking in case someone had a strong preference to
change this.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda
Please upload:
wget="wget -xnH --cut-dirs=1 http://cygwin.stromeko.net/release";
$wget/ucl/setup.hint
$wget/ucl/ucl-1.03-2-src.tar.bz2
$wget/ucl/ucl-1.03-2.tar.bz2
$wget/ucl/ucl-debuginfo/setup.hint
$wget/ucl/ucl-debuginfo/ucl-debuginfo-1.03-2.tar.bz2
$wget/upx/setup.hint
$wget/upx/upx-3.09-1-s
Achim Gratz writes:
> Yaakov (Cygwin/X) writes:
> OK. I won't be able to run the tests for some packages this way, but it
> sounds like this should provide a workable solution for bootstrapping.
> I guess we will anyway have to re-compile all packages with gcc47 when
> it
Yaakov (Cygwin/X) writes:
> On Tue, 12 Mar 2013 07:44:56 +0100, Achim Gratz wrote:
>> How did isl make it into the list, it doesn't seem to be used so
>> far, perhaps a new dependency for gcc48?
>
> Exactly; we're already using 4.8 for x86_64.
If the plan is to st
Yaakov (Cygwin/X) writes:
> 1) Build gmp-5.1.1 and install libgmp10 and libgmp-devel;
> 2) Build mpfr-3.1.1 and install ONLY libmpfr-devel;
> 3) Build libmpc-1.0.1 and install libmpfr4, libmpc3, libmpc-devel
> 4) Build ppl-0.11.2, install libppl9 libppl_c4 libpwl5, and replace
> ppl-devel with libp
Achim Gratz writes:
> And again, the real head-scratcher is libmpfr4.
Speaking of which, if I want to compile test packages of these for use
with gcc47, how do I tell cygport to link against the new libraries
without installing them on my system first (since that will make the
installed
Dave Korn writes:
> On 12/03/2013 01:02, Dave Korn wrote:
>> On 10/03/2013 15:43, Achim Gratz wrote:
>>
>>> - TLS disabled since it doesn't work with current gcc
>>
>> I just debugged that over on the mpfr list. It can be made to work by
>> ad
Yaakov (Cygwin/X) writes:
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gcc
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/gmp
> http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/mpfr
> http://cygwin-ports.git.sourceforge.net/gi
Yaakov (Cygwin/X) writes:
> On Sun, 10 Mar 2013 16:50:04 +0100, Achim Gratz wrote:
>> - provide libmpc1 for compatibility with existing packages (the old
>> package pinned the library version to -1 even though the API version
>> was -3), the actual library content is ide
Yaakov (Cygwin/X) writes:
> On Sun, 10 Mar 2013 16:36:05 +0100, Achim Gratz wrote:
>> Packages orphaned by David Billinghurst.
>>
>> - no update due to compatibility issues with existing applications
>
> GCC 4.8 uses isl/cloog-isl for Graphite, which require GMP 5.x.
Packages orphaned by David Billinghurst.
- latest upstream version
- provide libmpc1 for compatibility with existing packages (the old
package pinned the library version to -1 even though the API version
was -3), the actual library content is identical
- linked against libmpfr4 / libgmp3
Pl
Packages orphaned by David Billinghurst.
- updated to latest upstream version and patches
- TLS disabled since it doesn't work with current gcc
- compiled with current gcc4 and binutils
- linked against libgmp3 to maintain compatibility with existing packages
Please wait for RFU, upon acceptanc
Packages orphaned by David Billinghurst.
- no update due to compatibility issues with existing applications
- recompiled with current gcc4 / binutils
- modernized cygport file
Please wait for RFU, upon acceptance the package will be rebuilt with
new binutils and the Cygwin README file will be up
Packages orphaned by Lapo Luchini.
ucl:
- recompiled with current gcc4/binutils
- cygport file modernized
upx:
- latest upstream version 3.09
- compiled with LZMA SDK v4.65 for full functionality
- recompiled with current gcc4/binutils
- cygport file modernized
Please wait for an RFU: upon acc
Christopher Faylor writes:
> And, I added a autodep stub. setup.exe should now parse an autodep
> line like:
>
> autodep: string string
>
> Since quoted strings are allowed, either of those can be the script
> to run. I think it probably makes sense for this to be, e.g.,
>
> autodep: "usr/(?:shar
Christopher Faylor writes:
>>Sorry, I didn't follow the entire thread. I'm not big in libstdc++
>>stuff, but I thought std::regex is part of it by default.
>
> Me too. Can someone definitively confirm or deny this?
The current toolchain based on cygwin definitely doesn't support it and
the statu
Christopher Faylor writes:
> Are you trying to say that the package containing an autorun script
> must run its postinstall.sh before anything else?
No, only that it must be installed so that the script to autorun is
accessible when it triggers. This could of course be handled by
stipulating that
Christopher Faylor writes:
> Actually, it needs to detect when a DLL is being installed. AFAIK,
> that's it.
The first part (detecting when a file of a certain type or in a certain
location gets installed) was never in question. But you also need to
ensure that the package that contains the auto
Christopher Faylor writes:
> There is no need for setup.exe to add anything to a requires list due
> to autodep.
It needs to ensure that the package providing the script is installed,
which means installation, updating or doing nothing; depending on what
state the installation is in. In terms of
Yaakov (Cygwin/X) writes:
> Don't forget python3.2 and ruby.
Thanks for the reminder, ruby was simply an omission in my mail (it is
in the package), but python3.2 isn't — I'll add it in the next update.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Fac
Christopher Faylor writes:
> The autodep/autorun wasn't an either/or. We need the autodep and, while
As I understand (and this might be wrong as I don't know what upset is
doing), autodep adds that package to the requires of another package if
the dependency regex matches for any files installed
1301 - 1400 of 1452 matches
Mail list logo
