Corinna Vinschen writes:
The implementation of -E is a bit lacking, IMHO.
Fair enough.
The description implies that the ephemeral file list gets also rebased.
So I take it that there are two lists of files, the ones which get
rebased and are written back into the DB, and the ephemeral ones
On Wednesday 20 June 2012, 11:33:17, Corinna Vinschen wrote:
If you really want -E to be an exclusive option, then what I'm missing
is the enforcement on the command line.
Here's a reworked patch (against rebase-4.2.0-1) that enforces mutual
exclusivity between -T and -E; extra files given on
Christopher Faylor writes:
I don't think any native English speaker would use ephemeral as a
switch name. I'll bet a significant number of native English speakers
don't even know what it means.
How many of those are compiling their own Cygwin packages?
And, I said something like not you
Corinna Vinschen writes:
Not speaking for all, just for me, I like the idea to make the switch
a simple switch without argument. The only problem is that the -t
option is already in use. What about -O/--oblivious?
That looks good and all other obvious mnemonics are taken already...
Jason Tishler writes:
Sorry for the delay, but I was AFK...
No worries...
I'm not enamored with the option name, but I can't think of another one
given the lack of available option letters.
Well, I'm oblivious to the naming of the option, I just need the
functionality. If anybody has a
Achim Gratz writes:
Will do. Might need a day or two.
I decided to do it right now. The patch stack against CVS is attached.
The change to build.sh is unchanged since I don't understand what or how
Jason wants it changed. I'll fix it ASAP when he has answered that
question.
rebase-4.3.0
Jason Tishler writes:
I just released rebase-4.3.0-1 with your first three patches --
thank you, Jason.
I did not apply the build.sh patch. I would prefer to leave the build
alone (since I have my own release wrapper script) or convert to
cygport.
OK. I didn't know converting to cygport
Yaakov (Cygwin/X) writes:
Attached is a first draft of a patch to support split debuginfo
packages automatically in cygport. I'm looking for comments and
suggestions, particularly on the following:
The automatic generation of the packages works great, thank you.
Looking at the resulting
Christopher Faylor writes:
Maybe the .debuginfo files should be in a Debug category.
I don't think that would be the right thing to do. It would only be of
help if the debuginfo packages were not shown in the other categories
together with the installation packages, but a flat Debug category
If you're still following, I've uploaded the latest version of the
incremental rebase script:
$cygwin=http://cygwin.stromeko.net/
wget $cygwin/release/_incautorebase/_incautorebase-1-8-src.tar.bz2
wget $cygwin/release/_incautorebase/_incautorebase-1-8.tar.bz2
There is now a short usage
New version with bugfixes, setup.hint file and postinstall script (the
old files have been removed):
$cygwin=http://cygwin.stromeko.net/
wget $cygwin/release/_incautorebase/_incautorebase-2-2-src.tar.bz2
wget $cygwin/release/_incautorebase/_incautorebase-2-2.tar.bz2
wget
Hi Ken,
I've been looking into the TeXlive postinstall scripts since just
running these takes over an hour in my installation. As it turns out,
one can remove most of the churn by organising things a little bit
differently and collect the arguments into a single invocations of the
commands
Hi Ken,
Ken Brown writes:
1. When creating the various texlive-collection-* packages, instead of
creating postinstall scripts, I would drop files into
/usr/share/texmf-dist/postinstall containing the postinstall
information.
Exactly, although you could change that place of course (I've
Hi Reini,
I hope you don't mind that I move this discussion here, but it seems to
be the more appropriate place.
[Summary of previous discussion] I think that each perl module
distribution should have its own Cygwin package. Since our perl
installation at work needs quite a few more
Ken Brown writes:
I'm not crazy about the idea of using texmf-dist for files that are
not part of the upstream distribution. Maybe /etc/texmf
(a.k.a. TEXMFSYSCONFIG) would be a better place.
Certainly, that seems to be a better place. I just didn't want to
create subdirectories in
Reini Urban writes:
What's the problem? Lack of upates for these?
My problem is that I need quite a bunch of additional Perl
distributions, I need to package them into Cygwin packages since they
will need to be installed with setup.exe and the way things are bundled
in perl_vendor makes
Yaakov (Cygwin/X) writes:
cygport 0.11.0 should make it much easier to maintain this quantity of
Perl modules, since it can now generate setup.hint files with
appropriate requires: automatically. I don't think Cygwin READMEs are
necessary for these either.
Yes, I've seen your announcement
Ken Brown writes:
How about something like [PKG_]REQUIRE_EXCLUDES for packages that we
don't want to require?
Any further thoughts about this?
+1
Since I have made a snapshot package, cygport picks up that package as a
dependency. I've patched pkg.cygpart to filter these out (grep -Ev
David Stacey writes:
The package is built with cygport: the 'src' file contains the
original doxygen source code (unaltered), a couple of patch files and
the cygport file itself. As I said, this is my first package - please
be patient with a newbie, and apologies in advance for any mistakes.
Reini Urban writes:
When you start proposing your stuff I can remove these packages
from perl_vendor.
I've been working on extracting the dependencies automatically given a
module or distribution name. The method I started off with turned out
to be very slow and somewhat unreliable, so I bit
David Sastre Medina writes:
The only outstanding issue I can think of right now, would be
to revert this change:
-PATH=/usr/local/bin:/usr/bin:${PATH}
+ORIGINAL_PATH=${PATH}
+PATH=/usr/local/bin:/usr/bin
The details about this issue can be found here:
As requested by Corinna on the Cygwin list, here's a patch to document
some recent changes in the build environment.
From 3dd23c6063a3edb8bfd1874f5b3c68baf0a89ec4 Mon Sep 17 00:00:00 2001
From: Achim Gratz achim.gr...@infineon.com
Date: Fri, 18 Jan 2013 14:24:13 +0100
Subject: [PATCH 1/3] README
Christopher Faylor writes:
You'd really be much better served to submit one patch at a time.
Noted.
If you look at bootstrap.sh, you will see why I'm puzzled why this should be
needed. The script is intended to be run from the build directory which
should be separate from the source
Christopher Faylor writes:
I'm really not too keen on adding hacks to setup so that people can
use it for other than its intended purpose.
If there is another method to do an unattended Cygwin install, I'm all
ears. I have briefly pondered to script a standalone installer, but it
requires too
green fox writes:
Achim, reguardless of if this code getting into cygwin (or not), could
you be able to provide a copy of this on public git/whatever server?
I plan to publish my infrastructure, but haven't yet since it a) isn't
feature complete and b) I need to clean up a few things. I don't
Christopher Faylor writes:
I was referring to your change which handled versioned setup.ini's.
That is not a requirement for an unattended Cygwin install.
I do have that requirement, not that I love it very much.
If there was a general hue and cry for the feature that you want to add,
I'd
Achim Gratz writes:
I have one last idea of how to live without that particular change. If
it works, I'll drop the patch.
I've done some tests and I can implement my minimum requirement by
changing the directory structure to something like:
repo/release/... (packages directory)
repo
Here is a reworked patch series, this time as single patches in separate
mail. For the sake of completeness I'm sending all patches again. They
should all apply seperately if necessary. Some comments below.
[PATCH 1/4] README: document some recent changes in the build environment
I've
From 991a4e1455b73abfffef6651583edae0079c077f Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 25 Jan 2013 13:23:10 +0100
Subject: [PATCH 1/4] README: document some recent changes in the build environment
* setup/README (HOW TO BUILD): Cross compiler package is now named
mingw-gcc-g
From a8ffe947b5e64b9f29cecc8c404d0d508ab7be67 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 18 Jan 2013 14:33:29 +0100
Subject: [PATCH 2/4] Makefile: additional targets strip and upx
* setup/Makefile.am: Provide new targets strip and upx to remove
debugging symbols and compress
From a246270621b2b4fbd476aa386fc217ed14f3fe10 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 25 Jan 2013 12:12:41 +0100
Subject: [PATCH 3/4] Allow delete and reinstall from CLI, re-implement install from CLI
* choose.cc: Add new CLI option -g/--upgrade-also, considers all
installed
From ead437489d0873f983103cef24b708af18a9a391 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 18 Jan 2013 17:05:52 +0100
Subject: [PATCH 4/4] Allow a different basename (instead of setup)
* setup/ini.h: Modify macro definition to pick up name from external
variable SetupBaseName instead
Jon TURNEY writes:
I don't think this is needed. I know cgf said the build directory
should be separate from the source directory, but it seems to me that
setup configures and builds correctly in the source directory.
I tried to build inside the source tree first, but the bootstrap
wouldn't
Jon TURNEY writes:
It looks to me that this might be removing the code which causes the Base
category to get installed by default on the first install. Have you tested
that still happens?
I think there's a single combination of options where this indeed
occurs: a Base package is not installed
:00 2001
From: Achim Gratz
Date: Fri, 1 Feb 2013 20:22:21 +0100
Subject: [PATCH 5/5] Rename variable and re-implement original behaviour
exactly
* choose.cc (OnInit): When a package is from category Base or Misc
is found uninstalled, select it for installation. This
re-implements the previous
-install them.
From 0527144754297f1bb552c4ee337044b8a16f3548 Mon Sep 17 00:00:00 2001
From: Achim Gratz achim.gr...@infineon.com
Date: Mon, 4 Feb 2013 14:28:26 +0100
Subject: [PATCH 3/5] Allow delete and reinstall from CLI, re-implement install
from CLI
* choose.cc: Add new CLI option -g/--upgrade
Yaakov (Cygwin/X) writes:
On Tue, 05 Feb 2013 20:56:42 +0100, Erwin Waterlander wrote:
It doesn't matter that it is not secure.
Yes, it does. IMHO it is irresponsible on our part to distribute
unmaintained or knowingly vulnerable software, and it reflects badly on
the Cygwin project.
Well,
I've updated the incremental autorebase package to work with additional
dynamic languages (most notably ruby) and to take advantage of the
perpetual postinstall scripts that I'm proposing in another post. If
anybody is aware of further places that would need to be inspected for
dynamic objects
normal postinstalls.
From 155955b92498f95631d683c2bbc1d93d6b27ddda Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Wed, 6 Feb 2013 12:37:17 +0100
Subject: [PATCH 5] implement perpetual scripts and run them before all other
postinstall scripts
* postinstall.cc (RunFindVisitor): Exclude perpetual
Christopher Faylor writes:
You should make it clear why the current mechanism is unsatisfactory.
I thought I already had, apologies if I haven't been clear enough. In
general the changes that I've posted for review aim to enable either an
unattended or a guided install (choser mode) that does
Christopher Faylor writes:
I don't really see how making setup.exe always run rebaseall makes
unattended installs work better.
It requires less invocations of setup and yields a simpler install
script which consequently has less chance of being repaired to death
by someone ten timezones away
Jon TURNEY writes:
I've applied the uncontroversial part of this patch.
Thank you.
In future, please use the ChangeLog format linked to in [1]. (emacs protip:
C-x 4 a :-))
Noted.
I had a go at rewriting this, but The libgetopt++ CVS module should be
automatically checked out in a
Christopher Faylor writes:
Would you consider rebundling your patch so that it only includes
--remove-packages and --remove-categories options? Those are obviously
missing command-line functionality.
I'll consider anything that makes them more acceptable. BTW, I've just
renamed the
Yaakov (Cygwin/X) writes:
The attached patch finds DLLs in certain directories that may have been
installed via CPAN (Perl), easy_install (Python), pecl (PHP), gem
(Ruby), or R's install.packages() command.
I've pulled the PHP location from this patch for incremental autorebase,
I'll post the
Jason Tishler writes:
They look fine to me too. However, I like Chris' idea of storing the
directories in a separate file. What do others think?
For my incremental autorebase package I've introduced a directory
/etc/rebase/dynpath.d/ — it should contain one file per package that has
Yaakov (Cygwin/X) writes:
I've pulled the PHP location from this patch for incremental autorebase,
I'll post the new version later this week after some testing.
Please leave it in;
There seems to be a misunderstanding, I can't remove something from your
patch obviously. I've used that part
From c06d2094f372ef1426b723231397532c69866390 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Tue, 12 Feb 2013 16:33:40 +0100
Subject: [PATCH 1/3] Allow delete and reinstall from CLI, re-implement install
from CLI
* package_meta.h (DeletePackageOption): Add new CLI option
-p/--remove-packages
From 4343022ae575fc7836cf084797ba02fdc5f04d01 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Tue, 12 Feb 2013 16:42:57 +0100
Subject: [PATCH 2/3] additional option -g/--upgrade-also to upgrade installed
packages in the presence of manual selections from the CLI
* choose.cc (UpgradeAlsoOption
Updated again to read paths to search for additional dynamic objects in
/etc/rebase/dynpath.d/ and dropping content there initially for octave,
perl, php, R, and python2[67].
D=http://cygwin.stromeko.net/release/_incautorebase
${D}/_incautorebase-6-1.tar.bz2
Christopher Faylor writes:
Regarding the autorebase changes, I am not against the idea of implementing
a general purpose mechanism to have setup.exe do something when it notices
certain file patterns being added or deleted. This would move the current
'autodep' functionality from the upset
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]+
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
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
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:
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 status of
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
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
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
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
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
adding LDFLAGS=-shared-libgcc to your configure line.
Oh, I
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 gcc
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
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 still release gcc47, then I would like
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 is ready for release, right
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 that a
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
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
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
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.
--
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 for
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 more
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
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
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 ...
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 to use git master
cygport to build natively
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
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
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 than
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 and
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 they
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 for
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
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, 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
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
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
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
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
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 you please explain
what
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:
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:
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
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
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:
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
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 avoid
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
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
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
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
1 - 100 of 1385 matches
Mail list logo
