David Rothenberger daveroth at acm.org writes:
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages.
After some more investigations, this is because the dynamic linker seems to use
the libraries installed on the system rather than
marco atzeri marco.atzeri at gmail.com writes:
a solution for testing is to add the new directory as first in the PATH.
I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps wrong. It may also be that
the Ruby and Perl
Steven Hartland writes:
Just been trying the 5.14.2 that's was available in setup.exe as of
6th June 2012 and the dependencies for LWP are quite broken.
I have recompiled all Perl modules in perl_vendor as separate packages
due to (among other things) problems with LWP.
Although this may be
Steven Hartland writes:
I have recompiled all Perl modules in perl_vendor as separate packages
due to (among other things) problems with LWP.
Cool looking forward to it the new update :)
I don't think that Reini will switch from perl_vendor to unbundled
module packages, at least not for this
Steven Hartland writes:
Unfortunately the current perl_vendor install is so broken cpan
won't allow you to fix it with simple install unless you know
the exact missing modules and just breaks in some very strange
and random ways. Like missing protocol for ftp in LWP
I suggested to use
Reini Urban rurban at x-ray.at writes:
perl has now been updated from 5.10.1-5 to 5.14.2-3.
Thank you.
There seems to be a minor packaging error:
/usr/lib/perl5/5.14/i686-cygwin-threads-64int/CORE/cygperl5_14_2.dll
is a symbolic link pointing to
/usr/bin/cygperl5_14_2.dll
but this file
Keith Lindsay writes:
When I attempt to run latex on a simple .tex file (attached), I get
the following error message:
$ latex polynom.tex
This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Cygwin)
restricted \write18 enabled.
---! /var/lib/texmf/web2c/pdftex/latex.fmt doesn't
marco atzeri marco.atzeri at gmail.com writes:
octave-forge-20120714-1
In the directory
/usr/lib/octave/packages/nan-2.5.5/i686-pc-cygwin-api-v48+/
several *.mex.exe files have been installed. Apparently, these are actually
DLL, not EXE files (at least that's what file and peflags claim they
marco atzeri marco.atzeri at gmail.com writes:
.mex are dll not exe files.
[...]
I will look on what caused the change, as temporary workaround
remove/copy the *.mex.exe to *.mex files.
Thank you for the clarification. I'll see to prepare a patch to include these
in rebaseall.
Regards,
Ken Brown writes:
On 7/20/2012 2:01 AM, Fergus wrote:
1. Currently, having recently upgraded, I can't use latex:
$ latex a8.tex
This is pdfTeX, Version 3.1415926-2.4-1.40.13 (TeX Live 2012/Cygwin)
restricted \write18 enabled.
---! /var/lib/texmf/web2c/pdftex/latex.fmt doesn't match
Ken Brown writes:
There is no latex.exe in the Cygwin distribution.
Sorry if I had been unclear: I had a .exe file where there should have
been a symlink. I was not trying to imply that Cygwin shipped with it.
I have no idea why some people are having this problem. No one
reporting the
Franz Häuslschmid writes:
I observed, that org-mode started to behave strangely. Especially the
function
`org-clock-in' fails with following output to the *Messages* buffer:
find-library-name: Can't find library org
What more information could I provide to solve that issue?
You need
The following maxima session encounters an EACCESS error that I can't
make sense of:
(%i1) m: genmatrix (lambda([i,j], i+j-1), 3, 3)$
(%i2) write_data(m, /dev/stdout)$
Maxima encountered a Lisp error:
UNIX error 13 (EACCES): Permission denied
Automatically continuing.
To enable the Lisp
Corinna Vinschen corinna-cygwin at cygwin.com writes:
And here something goes wrong. If I call `echo foo /dev/stdout' in
bash, the above normalize_posix_path calls already handle the path
/proc/196/fd/1, not just /proc/196/fd as lisp does.
Thanks for having a look, that got me one step
Corinna Vinschen writes:
If you can nail that down to the actual calls and decisions clisp is
doing, it might help to find the cause.
I'm trying to, but it seems I still miss some dependencies to actually
build clisp with debug information. Unfortunately the build is
structured in a way that
Reini Urban writes:
But note that clisp already should come with debug info.
Where to look for it? I'm assuming that I need to step into the open
function from the lisp open call via gdb to see where the trailing
/1 gets stripped of from the file name pointed to by the symlink, so
I'd need to
I still can't build clisp, after several installations for devel packages I'm
stuck with missing libgdi...
Anyway, to get the symlink out of the picture I traced clisp again pointing it
directly to /proc/pid/fd/1:
49 1464915185 [main] lisp 5804 time: 1343386196 = time(0)
156 1464915341
Ryan Johnson writes:
It can be argued that emacs-auctex should not pull in texlive.
The only official TeX available in Cygwin is TeXlive and setup doesn't
support recommends, so...
It makes sense that gtk-doc needs dblatex, *if* the former is used to
create/update documentation rather than
Aaron Schneider writes:
Since a lot of people are having issues because 'perl_vendor' is not
installed when should, wouldn't be better to set perl_vendor as a
mandatory dependency of perl so just everyone gets it installed? I
guess package size won't be an issue.
No, please don't — I have
Ken Brown writes:
The good news: I haven't seen a repeat of that old crash so
far. Unfortunately, I'm finding that emacs is unstable: The emacs
window (running under X) simply disappears after 12-24 hours. This
may not have anything to do with the most recent changes. I haven't
yet tested
Christopher Faylor writes:
Just to be clear: Is this with the recent snapshot?
Yes, this is with the 2012-08-01 snapshot.
I ask because one other I see something similar seemed to come from
1.7.16.
I'm almost always running a snapshot, but I can back it out to vanilla
Cygwin or any other
Reini Urban writes:
Please don't spread fud. Self-compiled cpan packages are always
favored over vendor packages. See your @INC.
I really meant packages, of the Cygwin variant (I've got cygport
definitions for all of them and posted a link to them over in
cygwin-apps). Managing dependencies
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes:
Thanks. I think I see the problem but I won't be able to get to it tonight.
Based on that information, I went back to the July 29th snapshot and it is
holding up good so far. I checked my logs and I had the snapshot from
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes:
So, if you haven't already, we'd appreciate having people try out the
latest snapshot at: http://cygwin.com/snapshots/ .
The August 3rd snapshot looks good so far in my testing.
Regards,
Achim.
--
Problem reports:
Warren Young writes:
I think I've given Achim Gratz enough time to try and fix the bug
resulting from his build option changes.
I cannot fix something that I can't even reproduce. I can however
reproduce the bug that led to and fixed by those changes. As said
before, if someone has an idea
I'm at the August 7th snapshot now and Emacs just died on me with this message:
Connection lost to X server `:0.0'
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
The X server is
Achim Gratz Stromeko at NexGo.DE writes:
The X server is still running as well as a number of other X applications.
Something's wrong here with the new snapshot and signal handling / job control
in conjunction with X and the newest snapshot... this morning the shell
proclaimed (I left it running
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes:
You mention generic signal handling rather than sigwaitinfo so I don't
know if there are other issues. It doesn't seem like much would work if
signal handling was completely broken, though.
With the latest snapshot
Christopher Faylor writes:
deadbeef PING Statistics
2 packets transmitted, 0 packets received, 100.0% packet loss
Ping doesn't time out after only two packets. It sure looks like CTRL-C
worked
above.
Maybe ping got indeed interrupted, but I didn't get the shell prompt
back for
Daniel Colascione dancol at dancol.org writes:
It works for me in bash. I don't have tcsh installed, but I don't see
why SIGINT would work differently there.
Yes, it works in bash for me, too. Tcsh does something that apparently breaks
with the new snapshot, but since I don't get any error
Christopher Faylor writes:
You're not really giving us much to go on.
I don't have anything else, these are the only two (small) issues I've
seen after installation of the latest snapshot.
A defunct process doesn't mean that something is not properly
terminated. Is this also a tcsh shell
Christopher Faylor writes:
...and those are the kind of details which allows us to at least make
educated guesses about problems. Showing a defunct ps listing, not so
much...
You know this, but a defunct listing means that a process terminated,
but wasn't reaped by it's parent process.
Christopher Faylor writes:
I killed make because I forgot to add a variable definition on the
command line. Only later did I find it left that zombie git process
that should have been terminated with it (I know it was associated with
that particular make invocation by its start time).
So you
Ken Brown kbrown at cornell.edu writes:
Please test it and report any problems to the Cygwin mailing list. It
would be especially helpful if you would look at /var/log/setup.log.full
after installing it, and make sure there are no errors involving updmap.
I've only now been able to check
Ken Brown kbrown at cornell.edu writes:
I would have expected
updmap-sys --syncwithtrees
(which is in the texlive-collection-basic postinstall script) to get rid
of those messages. Maybe those messages were produced earlier in the
postinstall process. Please try running `updmap-sys'
Warren Young warren at etr-usa.com writes:
I haven't heard peep one from either side about this release on this
list. (For contrast, I've gotten several positive responses in my
answer to the question about this on Stack Overflow[1].)
Sorry, I've been swamped with other stuff...
Silence =
Achim Gratz Stromeko at NexGo.DE writes:
With the latest snapshot (2012-08-07), pinging a dead machine (i.e. has a DNS
entry but doesn't answer) from tcsh in mintty, I can't Ctrl-C ping and have to
wait until it finally times out.
# ping deadbeef
PING deadbeef (xx.xx.xx.xx): 56 data bytes
Achim Gratz Stromeko at NexGo.DE writes:
This is still happening with the 2012-08-16 19:31:57 UTC snapshot.
And now I see that all that killing business has left some tcsh processes in
task manager with a size of 60k (much too small for both tcsh and ping) that ps
in Cygwin doesn't show. I
Daniel Colascione writes:
More odd behavior under the 2012-08-16 snapshot:
1) Start vim
2) Hit C-z
3) Run fg
4) Observe that vim doesn't reappear. Rather, nothing happens, until...
5) C-c
6) vim now redisplays and accepts input
I can confirm this behaviour.
Regards,
Achim.
--
+[Q+
Christopher Faylor writes:
I should have asked this before: I don't think anyone has made it
clear if they are running the cygwin ping or the Windows one. I've
been assuming Cygwin. Is that correct?
Cygwin's ping. I've removed any remnants of Windows' PATH from all
Cygwin startup scripts...
The 20120817 snapshot is holding up good so far in my testing. Fingers
crossed... :-)
Regards,
Achim.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:
Wynfield Henman wynfield at gmail.com writes:
This results in: PANIC: unprotected error in call to Lua API
(zlib library version does not match -
header: 1.2.5, library: 1.2.7)
Reinstall zlib and install zlib-devel. If that doesn't help, check where the
zlib.h header
I'm removing the Windows PATH in my startup scripts since there's nothing in
there that I think should be accessible from Cygwin.
For (t)csh this is easy enough to do with dropping a script into /etc/profile.d
that gets executed first, but there's no such provision for sh and the ilk since
PATH
Eric Blake eblake at redhat.com writes:
Unfortunately, at least your windows system dll directory has to be on
PATH, or cygwin1.dll will fail to load, so blindly removing ALL windows
paths from PATH is wrong.
At that point cygwin1.dll is already loaded and so far I haven't seen anything
not
Eric Blake writes:
Sorry, POSIX requires that to leave LC_ALL set after the function
call,
Interesting. Where is that specified?
which is not what you want (bash behaves differently according to
whether it was started as bash or sh).
OK, it wasn't the same as the original invocation anyway
Eric Blake writes:
Interesting. Where is that specified?
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
When a function is executed, it shall have the syntax-error and
variable-assignment properties described for special built-in utilities
in the
David Sastre Medina writes:
All three changes will be available in the next release (profile_d
modification taken from your last version in this thread).
Thanks.
Thank you. If you'd rather have a complete patch, let me know and I'll
post it or send it to you via email, as you prefer.
Wynfield Henman writes:
I reinstalled all cygwin zlib modules and the problem persisted. The
only zlib I found was the cygwin installed one. Since it is POSIX
compliant and TeXLive installs with it it shouldn't be a problem, I
should think. But, there is one due to, pdftex I think.
The
David Sastre Medina writes:
I'm having this on github now for easier handling.
Check https://github.com/dsastrem/base-files.git
Ah, nice. Everythings OK, thank you.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Waldorf Blofeld:
Daniel Colascione writes:
People execute Windows programs using Cygwin all the time. With this
change, basic things like cmd and notepad will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default startup scripts.
The
Christopher Faylor writes:
If we are changing a longstanding behavior then I agree with Daniel that
this is a bad idea. You're just asking for people to be confused.
Again, I'm not arguing for changing the default. In fact, as long as
ORIGINAL_PATH stays available it might even still be added
Andrey Repin writes:
Greetings, Achim Gratz!
People execute Windows programs using Cygwin all the time. With this
change, basic things like cmd and notepad will fail to work.
Working with Windows programs is the *point* of Cygwin. I really don't
think this change should go into the default
Christopher Faylor writes:
I'll just reiterate what Daniel said again: We can't make things like
cmd or notepad stop working. That would be a disaster.
Yes, and nobody proposed otherwise.
I wasn't really following the discussion, and don't really want to check
stuff out in git to see what's
Ken Brown writes:
I don't see anything in those scripts that would explain this. I just
ran them manually on my system, and the times (in minutes) were 14,
3, 2.5, 2.5, and 7. So I can't think of any explanation except that
something on your system (anti-virus or other BLODA?) was
332ae09f97895197b09793488652a114b1adfa44 Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@stromeko.de
Date: Sat, 25 Aug 2012 08:19:12 +0200
Subject: [PATCH 1/3] Protect ORIGINAL_PATH and control behaviour by
CYGWIN_NOWINPATH
* etc/defaults/etc/profile: Protect an existing ORIGINAL_PATH
variable. Strip windows
Achim Gratz writes:
[...]
Hit send too soon... here's the patch set again without the typos.
From 8a930eb8adc4d9364ea0d6c8f63be448c539b448 Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@stromeko.de
Date: Sat, 25 Aug 2012 08:19:12 +0200
Subject: [PATCH 1/3] Protect ORIGINAL_PATH and control
Aharon Robbins writes:
I've come to the conclusion that it is indeed BLODA. The box in
question is my Corporate IT Laptop With All The Mandated Software and
I can't disable anti-virus or any of the other stuff (like the automatic
screensaver) lest the sky fall and cats start mating with dogs
Now that X11 works again without crashing and I've found a font that looks OK
I'm running into a problem again that (I think) has existed for much longer:
When I start emacs from a shell window outside the X11 session (e.g. the same
mintty that I ran startxwin in) and then iconify emacs-X11
Ken Brown kbrown at cornell.edu writes:
I can't reproduce this on my system. I'm running 64-bit Windows 7,
emacs-24.2-1, the latest Cygwin snapshot (2012-08-27), and the test
version of the X server (1.13.0-1). Here's what I tried:
Same setup as mine except 32-bit Win7/Enterprise.
1.
Ken Brown kbrown at cornell.edu writes:
Still no problem. I'm using only bash, not tcsh. But I gather that
you're having problems with both.
Hmm. I'll have to try another time after a reboot with just bash alone to rule
out any interference. I have a dual core machine (no hyperthreading)
I'm re-packaging the perl module DBI::Dumper as a Cygwin package for internal
distribution and the debuginfo package is not produced. This is because
/usr/src/debug stays empty, while the .dll.dbg file is produced. I can't figure
out what's keeping the source information from being extracted,
Yaakov (Cygwin/X) writes:
The C extension included in DBI::Dumper is precompiled by Inline::C
rather than the usual MakeMaker-controlled XS-C-dll dance, so the
usual means of getting debuginfo (via the OPTIMIZE Makefile variable)
doesn't work. AFAICS the solution would have to be
Ken Brown kbrown at cornell.edu writes:
This dependency is created by cygport. It's of course up to the gnuplot
maintainer (Volker Zell) whether or not he wants to override it, but I
can explain the rationale.
[...]
Until someone ports zypper or aptitude to Cygwin which can deal with soft
Hi Yaakov,
several Perl distributions have chosen to put the actual archives in a
subdirectory (e.g. Inline::Files). So far I've dealt with those by editing
SRC_URI after inherit perl, but I'd like something more straigtforward. I
propose that CPAN_AUTHOR should optionally include this
Fergus writes:
Another trick/ fix/ workaround would be to go into
/etc/setup/installed.db and edit it to show you've got texlive
texlive-20120628-1.tar.bz2 0 and maybe texlive-collection-basic
texlive-collection-basic-20120628-2.tar.bz2 0 (even though you
haven't). There may be others but it
LMH writes:
I don't see pax in the package manager under archive, so I did a
search and found a thread about this, but it was from 2004. I need to
do some copy operations on files with names containing some characters
that annoy bash, so pax would be helpful.
Jari Aalto has issued an ITP for
Reini Urban writes:
Just for easier understanding:
How would that look like for e.g.
A/AM/AMBS/Inline/Inline-Files-0.68.tar.gz
NAME=Inline-Files
inherit perl
CPAN_AUTHOR=AMBS/Inline
Yes, exactly.
Looks a bit weird.
Well, that's the author's choice…. Looks much less wierd to me than
GrahamC writes:
dd bs=512 if=/dev/sdg of=/dev/null
^^^
This is the raw device.
dd bs=512 if=/dev/sdh1 of=/dev/null
This is the first partition (or fs if unpartitioned) on that device. It
obviously cannot be larger than the device unless there's
Adam Kessel writes:
I also tried a brand new install into a new directory with default
settings, both of 1.7 and legacy 1.5. Still no difference (1.5 is
actually even slower).
I've had a similar problem about a year ago. The symptom was that each
command from Cygwin would make lsass.exe max
Reini Urban writes:
Looks a bit weird. Don't we have a better field for this cpan quirks?
Like a new CPAN_DIR which defaults to CPAN_AUTHOR?
I've just added an alternative configuration variable CPAN_DIR that
records just the directory component and sent the patch (together with a
few more to
Kete Foy writes:
If you could package the new Org-mode version of 7.9.2 like Debian
does, I think it would fix this problem, and I would appreciate it.
Ken packages Emacs releases, including whatever version of Org that
comes with it. Debian does exactly the same, btw (Sebastien Delafond
Larry Hall (Cygwin reply-to-list-only-lh at cygwin.com writes:
As soon as I disable unattended mode (remove the --quiet-mode switch),
if I just take all the default settings in the installer GUI and click
the Next button a lot, the installation completes just fine.
Which is why I said the
Björn Kautler writes:
I'm having a problem with https requests to
https://www.geocaching.com; in perl.
This has nothing to do with Cygwin, the same error happens on Linux:
$ perl -e 'use LWP::Simple;' -e '($r=get(https://www.geocaching.com;)) or
print $!\n$@\n;print $r\n;'
Connection reset by
Ken Brown writes:
When you say the buffer is tied to an svn repository, do you mean
you're using emacs as your commit editor as in the following report?
I'm seeing the same thing with magit, FWIW. You do something to a vc
file, Emacs decides it needs to ask Git for the status (or you try some
I've installed the cygwin-debuginfo package (and reinstalled cygwin to be sure),
but GDB tells me this:
warning: the debug information found in /usr/bin/cygwin1.dbg does not match
/usr/bin/cygwin1.dll (CRC mismatch).
whenever I try to load the symbols for the cygwin1.dll. Is that to be expected
marco atzeri writes:
you have an old or different version in /usr/bin
try removing /usr/bin/cygwin1.dbg
That must be some leftover from a snapshot installation then. Thanks.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Waldorf MIDI Implementation
a second vote for principle in four months. (The
other being Corinna's.) Add to that the original Achim Gratz vote for
Unix mode, which carries more weight since it was accompanied by an
actual example of problems.
FWIW, I think Yaakov is more immediately concerned about the additional
API
Ken Brown kbrown at cornell.edu writes:
Thanks to the efforts of Daniel Colascione, there is also a new package
*** emacs-w32-24.2.90-1,
again a test release, for users who want to use the native Windows GUI
for display.
Great stuff. Many thanks to Daniel and you for providing this.
Ken Brown kbrown at cornell.edu writes:
M-x xterm-mouse-mode
Thank you, this works great -- need to hack my .emacs a bit to do this
automatically.
I'm not sure what you mean by without Gtk. Do you want some other X
toolkit, such as Lucid or Motif? Or no X toolkit? What would be the
Jim Reisert AD1C writes:
When I start my X server, I see one dbus-daemon.exe process running.
As soon as I start emacs the first time, there is a second
dbus-daemon.exe as well as a dbus-launch.exe.
Emacs must see the DBUS_SESSION_BUS_ADDRESS environment variable that
tells it how to connect
Ken Brown kbrown at cornell.edu writes:
Thanks to the efforts of Daniel Colascione, there is also a new package
*** emacs-w32-24.2.90-1,
again a test release, for users who want to use the native Windows GUI
for display.
I've encountered only one problem so far:
If I start
Ken Brown writes:
emacs-w32 shouldn't require dbus-daemon, as far as I know. This
sounds like a bug. Could you give me a specific recipe for
reproducing the problem?
Just make sure Cygwin has cleanly terminated, then open a mintty (I use
tcsh if that has a bearing on this bug) and start
Ken Brown writes:
I'm not sure about the dbus-launch issue, since I always use bash.
But here's the output I get from `dbus-launch --csh-syntax':
setenv DBUS_SESSION_BUS_ADDRESS
unix:path=/tmp/dbus-wCGlBfQgo6,guid=f3e1dad82fc7ce9eff209b93';
set DBUS_SESSION_BUS_PID=5020;
What's the
Daniel Colascione writes:
Open another mintty and try to kill the hanging emacs process from it.
Works fine for me, albeit using kill -9, not regular kill. What
exactly do you see?
The kill command (with -KILL or any other signal) never returns until I
terminate emacs from task manager. I
Daniel Colascione writes:
Under Cygwin, the variable system-type will be 'cygwin; under Windows,
it will be 'windows-nt. You can perform conditional initialization as
follows:
(cond ((eq system-type 'cygwin) (cygwin-specific-initialization))
((eq system-type 'windows-nt)
Daniel Colascione dancol at dancol.org writes:
I need to keep the emacs-w32 and emacs-gtk under cygwin apart and AFAIK
they both get reported as 'cygwin. So I was looking for a way to know
this other than by looking at the build string.
Ah. You want (window-system) then.
Thanks. Now,
Ken Brown kbrown at cornell.edu writes:
Emacs will *try* to autolaunch a D-Bus session if it doesn't find one,
but this feature is broken in the emacs-24 branch (and the problem is
not Cygwin-specific). This is Emacs bug #8855. It's been fixed in the
trunk, but the fix is complicated and
Ken Brown writes:
I think it's time to take this to the emacs list. I've just filed a
bug report (bug#13112) in order to focus the discussion.
Thanks, I'll follow up there if necessary.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Samples for the
Jonas J Linde writes:
I saw in some other thread that there was a problem when emacs tries to
use dbus and it isn't started in advance. The new emacs seems to handle
that a bit differently.
That discussion went a bit further on emacs-bugs. To summarize:
It turned out that dbus was a red
Warren Young writes:
I guess I shouldn't have moved this discussion to Cygwin-Apps, since
it's been greeted by crickets for the past 10 days. So to repost:
I've downloaded the test packages and been reviewing the patches, but
just being back at work from the holidays I couldn't spend much time
Could the README please be updated to reflect some changes:
Instead of gcc-mingw-g++ (pulls in a lot of old cruft and then doesn't work) the
package mingw-gcc-g++ should be installed. Also, please mention that
libgetopt++ from CVS should be installed directly in the setup directory.
Lastly, the
Corinna Vinschen writes:
You could provide a patch, that would be the easieast way to
update the docs.
Will do once John Turney's most recent change gets checked in since it
obsoletes some part of my local changes.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk
David Stacey writes:
I've done some more testing, but with little success. I ran the
Subversion built-in tests on sqlite3-3.7.15-1 without Warren's patch,
and again on sqlite3-3.7.13-1 with the new patch applied. In both
cases, the Subversion tests plodded along nicely and then froze after
The latest snapshot and Emacs-24.2.90 do not like each other, I've rolled back
to the 2013-01-18 snapshot:
(1001)~ # strace emacs-nox
4 4 [main] emacs-nox (5948)
**
132 136 [main] emacs-nox (5948) Program name:
Christopher Faylor cgf-use-the-mailinglist-please at cygwin.com writes:
On Tue, Jan 22, 2013 at 03:34:55PM +, Achim Gratz wrote:
The latest snapshot and Emacs-24.2.90 do not like each other, I've rolled
back
to the 2013-01-18 snapshot:
This should be fixed in the upcoming snapshot
David Stacey writes:
Forgive my naive understanding of this, but I gather that rebaseall
allocates a portion of memory for each Cygwin dll. Presumably, this
bucket of memory is finite, so is it possible that Cygwin could ever
grow to a size where it effectively runs out of rebasing address
These two packages should exist according to the package list, but their
corresponding directories are empty. I have the 4.5.3 versions installed, but
the rest of Qt is already at 4.8.4. Could someone please check whether the
directories should be deleted (there doesn't seem to be any package
Alan writes:
$ chmod +x /usr/bin/latex
$ ls -l /usr/bin/latex
-rw-r--r-- 1 curtis None 21 Jan 25 20:04 /usr/bin/latex
I can't change the permissions. How do I fix this?
Does mounting that drive someplace else with the noacl option help?
If so, then your network admins have configured the
I'm seeing strange behaviour from lftp scripts that use external commands; lftp
forks, but then hangs and needs to be killed. This is only happening from
mintty, but not when lftp gets started from CMD:
sh -c PATH=/bin lftp -c '\!echo bla'
Tracing lftp in mintty yields the following after the
Achim Gratz Stromeko at NexGo.DE writes:
I'm seeing strange behaviour from lftp scripts that use external commands
Git apparently has similar problems when it is started from Emacs (via magit).
Regards,
Achim.
--
Problem reports: http://cygwin.com/problems.html
FAQ
101 - 200 of 4234 matches
Mail list logo
