[ITA] ping
just as I built the 64 bit version and it seems to work, with the same limitation of 32 bit counterpart. to download (remove the index.html's) : wget -r -np -nH --cut-dirs=0 \ http://matzeri.altervista.org/x86_64/ping/index.html find x86_64 -name index.html -o -name md5.sum | xargs rm Regards Marco
[PATCH cygport] Make src packages which put files under /usr/src/package-version-release/
From a previous discussion [1] on this subject, it seems to be that if this is
desirable, then source packages should be fixed rather than working around
this in setup.
Attached is a patch to cygport to do exactly that.
I was also going to prepare a patch for http://cygwin.com/setup.html to say
that the source should be installed into /usr/src/package-version-release/,
but that is what the first sentence under Method One already says, and I
don't see anything else to contradict that.
(As an aside, how would a patch to move Method one and Method two to an
archive page be received? It seems to me that they are not relevant to nearly
all new packages)
[1] http://cygwin.com/ml/cygwin-apps/2011-12/msg00022.html
From c1425a51197c3b658fbae32c1dfb57c5b68b1d0f Mon Sep 17 00:00:00 2001
From: Jon TURNEY jon.tur...@dronecode.org.uk
Date: Sat, 19 Apr 2014 14:29:41 +0100
Subject: [PATCH] Put source package contents in a ${PF}/ directory
This makes source packages which, when installed, will place all their files
into /usr/src/${PF}, rather than directly into /usr/src.
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
lib/pkg_pkg.cygpart | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 6a21a42..b3ae33b 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -439,45 +439,50 @@ __pkg_srcpkg() {
echo;
__step Creating source patches;
+ local spkgsrcdir=${spkgdir}/${PF};
+ mkdir -p ${spkgsrcdir};
+
__pkg_diff;
if [ -s ${patchdir}/${cygwin_patchfile} ]
then
- cp ${patchdir}/${cygwin_patchfile} ${spkgdir};
+ cp ${patchdir}/${cygwin_patchfile} ${spkgsrcdir};
fi
if [ -s ${patchdir}/${src_patchfile} ]
then
- cp ${patchdir}/${src_patchfile} ${spkgdir};
+ cp ${patchdir}/${src_patchfile} ${spkgsrcdir};
fi
__step Creating source package;
- cp ${top}/${cygportfile} ${spkgdir};
+ cp ${top}/${cygportfile} ${spkgsrcdir};
for src in ${_src_orig_pkgs} ${_src_orig_patches}
do
- cp ${top}/${src} ${spkgdir};
+ cp ${top}/${src} ${spkgsrcdir};
done
- cd ${spkgdir};
+ cd ${spkgsrcdir};
if __arg_bool SIG
then
if check_prog gpg
then
- __gpg_sign ${spkgdir}/${cygportfile} CYGPORT SCRIPT;
- __gpg_sign ${spkgdir}/${cygwin_patchfile} CYGWIN
PATCH;
+ __gpg_sign ${spkgsrcdir}/${cygportfile} CYGPORT
SCRIPT;
+ __gpg_sign ${spkgsrcdir}/${cygwin_patchfile} CYGWIN
PATCH;
- if [ -f ${spkgdir}/${src_patchfile} ]
+ if [ -f ${spkgsrcdir}/${src_patchfile} ]
then
- __gpg_sign ${spkgdir}/${src_patchfile} SOURCE
PATCH;
+ __gpg_sign ${spkgsrcdir}/${src_patchfile}
SOURCE PATCH;
fi
else
inform gnupg must be installed in order to make
signatures.;
fi
fi
+ cd ${spkgdir};
+
tar Jcvf ${distdir}/${PN}/${PF}-src.tar.xz * || error Source package
creation failed
echo;
}
--
1.8.5.5
running openGL application remotely using ssh -X and cygwin/x ,extension NV-GLX missing on display localhost:10.0
Hello there! I am attempting to run an opengl application remptely to a ubuntu linux machine from my windows 8 machine. To do so I start the cygwin console, call startxwin. Running glxinfo | grep OpenGL returns the vendor of my graphics card, NVIDIA. glxinfo |grep OpenGL OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 580/PCIe/SSE2 OpenGL version string: 1.4 (4.4.0) OpenGL extensions: Then I ssh on the ubuntu machine using -X -C as the parameters. When attempting to start the application the console reads extension NV-GLX missing on display localhost:10.0. Afterwards, the cygwin/X server crashes and I have to restart it.I attached the log from /var/log/Xwin/XWin.0.log Does cygwin/x support running OpenGL applications remotely? Am I missing something? Do I have to install the mesa-utils libraries on the remote machine? Thanks so much! -Octavian XWin.0.log Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
src/winsup/cygwin ChangeLog fhandler_procnet.c ...
CVSROOT:/cvs/src Module name:src Changes by: cori...@sourceware.org 2014-04-24 13:44:23 Modified files: winsup/cygwin : ChangeLog fhandler_procnet.cc fhandler_socket.cc net.cc winsup/cygwin/release: 1.7.30 Log message: * fhandler_socket.cc: On x86_64, define u_long as __ms_u_long before including the windows headers. Explain why. (get_inet_addr): Convert ANY address to LOOPBACK address. Explain why. (fhandler_socket::evaluate_events): Forcibly set SO_ERROR socket option in case a connection attempt failed. Explain why. (fhandler_socket::ioctl): Drop x86_64 re-definition of u_long here. * fhandler_procnet.cc: On x86_64, define u_long as __ms_u_long before including the windows headers. Explain why. * net.cc: Ditto. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.6397r2=1.6398 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_procnet.cc.diff?cvsroot=srcr1=1.20r2=1.21 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/fhandler_socket.cc.diff?cvsroot=srcr1=1.302r2=1.303 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/net.cc.diff?cvsroot=srcr1=1.312r2=1.313 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/release/1.7.30.diff?cvsroot=srcr1=1.4r2=1.5
Re: Fatal error from Cygwin emacs-w32 every day or so
On 4/23/2014 7:56 PM, David Rothenberger wrote: Ken Brown wrote: I've rebuilt emacs-24.3 with the gnutls fix. David and Achim (and anyone else who's been experiencing these crashes), please try the following binary and let me know if it solves the problem: http://sanibeltranquility.com/cygwin/emacs-w32.exe.xz I had been experience pretty frequent emacs-w32 crashes (every few days). Your test binary has resolved the problem for me. I have not had a crash since last Friday except for a repeatable crash from refining a difference with ediff, which I believe is unrelated. Thanks for providing the binary for testing. Thanks for the feedback. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Dup'd sockets lose error information
On Apr 23 17:38, Corinna Vinschen wrote: On Apr 23 16:25, qq qq wrote: The following code is a simplified app that was used to test-connect to local ports 55000+ (none of which were actually listening) and received false-positive connected results because Cygwin's dup() for socket causes SO_ERROR to be lost. Since FD_SETSIZE is only 64 on Cygwin, the app uses dup()'s to lower the descriptors as it checks them for completion. There is no such problem on Linux. Also, strangely that Cygwin does not accept sin_addr as 0 to connect locally (and either localhost or local host IP must be stuffed in there, otherwise resulting in the Cannot assign requested address error). This is Winsock at work. Cygwin doesn't check the AF_INET address when calling Winsock's connect, so Winsock's connect itself seems to have this issue. As for the SO_ERROR value, I have to check. Thanks for the testcase. I've applied a patch which should solve both problems. Cygwin is using socket events to implement select. It turned out that, when using the original socket, the socket event as well as the socket's SO_ERROR value were set correctly. However, when calling select with the dup'ed socket handle, the socket event contained the correct error code, but the SO_ERROR value wasn't set. I added code to write back the error code from the socket event entry to the SO_ERROR socket option and that seems to do the trick. As for connecting or sending to INADDR_ANY or in6addr_any, this simply doesn't work with Winsock. It just returns WSAEADDRNOTAVAIL. I now added a conversion from INADDR_ANY and in6addr_any to INADDR_LOOPBACK and in6addr_loopback in calls to connect, sendto, and sendmsg to emulate the Linux behaviour. Apart from that it turned out that 64 bit Cygwin was suffering from a definition problem of a couple of Winsock types used in the Cygwin socket code. As the (hopefully) only user-visible effect, this led to a broken address output in /proc/net/if_inet6. This is fixed now as well. As for FD_SETSIZE, it's defined as 64 by default, but the user code can override the value by defining FD_SETSIZE to another value prior to including the standard headers. The underlying code does not restrict the file descriptor values to FD_SETSIZE. Please give the today's developer snapshot from http://cygwin.com/snapshots/ a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxei9k_9XHF.pgp Description: PGP signature
Re: cygcheck -p file.exe segmentation fault (x86_64)
On Apr 23 23:25, Doug Henderson wrote: On Wed, Apr 23, 2014 at 9:44 AM, Corinna Vinschen wrote: On Apr 23 09:17, Doug Henderson wrote: I am trying to identify the package containing the strings executable. $ uname -a CYGWIN_NT-6.1 Rover 1.7.29(0.272/5/3) 2014-04-07 13:46 x86_64 Cygwin $ cygcheck -p strings.exe Segmentation fault After installing the binutils package (which contains strings.exe) I still get the segfault. Further testing shows that cygcheck -p regexp segfaults for any target regexp. Strange. I'm getting either $ cygcheck -p strings.exe cygcheck: unable to contact cygwin.com site, InternetOpenUrl() failed: The operation timed out (win32 error 12002) or $ cygcheck -p strings.exe Found 18 matches for strings.exe x86_64/binutils/binutils-2.23.52-5 ... x86_64/mingw64-x86_64-binutils-debuginfo/mingw64-x86_64-binutils-debuginfo-2.24.0.3.85cf705-1 Corinna Sometimes, the first invocation of cygcheck -p strings.exe after starting the cygwin session shows the expected output before the segfault. Subsequent executions only show the segfault. I can't reproduce this, it works for me all the time. Attached is the output (p1.txt) from strace cygcheck -p strings.exe. On at least one occasion, I saw the expected output half way through the exception messages. I do not get a stack dump file, and I can't seem to get anything useful by running with gdb. cygcheck is not a Cygwin application but a native Windows one. It doesn't return lots of usueful info under strace becasue this requires a Cygwin DLL, and cygcheck only loads the cygwin DLL at runtime, but doesn't need any of Cygwin's functionality for -p. The cygwin-debuginfo package adds symbols, this may be a big help debugging this problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpwx7RGyy2d1.pgp Description: PGP signature
Re: rm -f behavior
On Apr 23 16:43, Douglas Coup wrote: I run Cygwin on a Windows 8.1 workstation. I just recently started noticing that the following sequence doesn't work: $ touch dac.txt $ chmod 444 dac.txt $ rm -f dac.txt The rm -f command gets a permission denied error. This just started happening recently, and I'm thinking it's because of an update to Windows. If I do chmod u+w dac.txt before the rm -f command, then the command works. The same sequence executed on a different machine that runs Windows 7 and hasn't been updated in a while works fine. And it used to work fine on my workstation. Is anyone else seeing this behavior? Not me. Are you sure you're using Cygwin's rm and chmod? Could this be related to parent directory permissions? The problem would be in Cygwin if that happens, but I tested this on a fully updated Windows 8.1 in 32 and 64 bit. Does an `strace -o rm.trace rm dac.txt' give a clue in rm.trace? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLsCaf60szo.pgp Description: PGP signature
Re: rm -f behavior
On Apr 24 11:34, Douglas Coup wrote: If I do which rm and which chmod, it shows that both commands resolve to the Cygwin binaries. The attached rm.notworking.trace file is from an rm -f dac.txt command that gets the permission denied error; i.e., when the permissions on the file are 444. Things seem to start going south at entry 34276. Gosh, how many ways to fail does transactional NTFS know? 20 34002 [main] rm 7580 unlink_nt: Trying to delete \??\C:\mydocs\temp\dac.txt, isdir = 0 274 34276 [main] rm 7580 unlink_nt: Opening \??\C:\mydocs\temp\dac.txt for removing R/O failed, status = 0xC0190052 So you're getting a transaction error which isn't covered by the Cygwin DLL yet. The error is STATUS_TRANSACTIONMANAGER_NOT_ONLINE. Whatever this means. How on earth can the TxF manager be not online?!? Unfortunately there's only very sparse information about this status code available. Before I make any changes to Cygwin, I'll try to get some info from the Microsoft side of things... Stay tuned, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpcceKl79v0a.pgp Description: PGP signature
Re: rm -f behavior
On Apr 24 18:36, Corinna Vinschen wrote: On Apr 24 11:34, Douglas Coup wrote: If I do which rm and which chmod, it shows that both commands resolve to the Cygwin binaries. The attached rm.notworking.trace file is from an rm -f dac.txt command that gets the permission denied error; i.e., when the permissions on the file are 444. Things seem to start going south at entry 34276. Gosh, how many ways to fail does transactional NTFS know? 20 34002 [main] rm 7580 unlink_nt: Trying to delete \??\C:\mydocs\temp\dac.txt, isdir = 0 274 34276 [main] rm 7580 unlink_nt: Opening \??\C:\mydocs\temp\dac.txt for removing R/O failed, status = 0xC0190052 So you're getting a transaction error which isn't covered by the Cygwin DLL yet. The error is STATUS_TRANSACTIONMANAGER_NOT_ONLINE. Whatever this means. How on earth can the TxF manager be not online?!? Unfortunately there's only very sparse information about this status code available. Oh, btw., the associated Windows error code is 6719, and the english error message is this: The object specified could not be created or opened, because its associated TransactionManager is not online. The TransactionManager must be brought fully Online by calling RecoverTransactionManager to recover to the end of its LogFile before objects in its Transaction or ResourceManager namespaces can be opened. In addition, errors in writing records to its LogFile can cause a TransactionManager to go offline. Before I make any changes to Cygwin, I'll try to get some info from the Microsoft side of things... http://social.msdn.microsoft.com/Forums/en-US/11bfd4ca-f7b7-45cd-a3bc-2ebce60b734c/ Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpnVlaSfqtXV.pgp Description: PGP signature
default shell
Hi, it's not a big deal, I just wonder what to execute, if I would like to execute user's default shell (defined in /etc/passwd). For example in cmd.exe, ConEmu or Console2. I don't want to hardcode a shell anywhere (in console emulator configuration, some batch file etc.), I just want to auto detect user's default shell and execute it. If it's possible :) Exactly the same what does mintty. Thank you and have a nice day! -- Dawid Ferenzy http://twitter.com/DawidFerenczy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: rm -f behavior
If it's any help, the same type of behavior happens when trying to do cp -f when the target exists and has a permission mask of 444. cp might be trying to do an rm first. Regards, Doug Coup Objective Systems, Inc. REAL WORLD ASN.1 AND XML SOLUTIONS Tel: +1 (484) 875-9841 Fax: +1 (484) 875-9830 Toll-free: (877) 307-6855 (USA only) http://www.obj-sys.com On 4/24/2014 12:36 PM, Corinna Vinschen wrote: On Apr 24 11:34, Douglas Coup wrote: If I do which rm and which chmod, it shows that both commands resolve to the Cygwin binaries. The attached rm.notworking.trace file is from an rm -f dac.txt command that gets the permission denied error; i.e., when the permissions on the file are 444. Things seem to start going south at entry 34276. Gosh, how many ways to fail does transactional NTFS know? 20 34002 [main] rm 7580 unlink_nt: Trying to delete \??\C:\mydocs\temp\dac.txt, isdir = 0 274 34276 [main] rm 7580 unlink_nt: Opening \??\C:\mydocs\temp\dac.txt for removing R/O failed, status = 0xC0190052 So you're getting a transaction error which isn't covered by the Cygwin DLL yet. The error is STATUS_TRANSACTIONMANAGER_NOT_ONLINE. Whatever this means. How on earth can the TxF manager be not online?!? Unfortunately there's only very sparse information about this status code available. Before I make any changes to Cygwin, I'll try to get some info from the Microsoft side of things... Stay tuned, Corinna -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin needs a man-db port
Chris J. Breisch schreef op 2014-04-23 17:18: Chris J. Breisch wrote: Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr. make check on check reports all tests passed, despite what appear to be some failures. The CHANGELOG says that this version should pass all tests on Cygwin. I've just subscribed to the mailing list and will check on whether these failures can be ignored or not. Still, it definitely appears to work better than the version we have now, which only passes 1 test in the test suite. Just to follow-up on this a bit more. I misunderstood the results from check's check. I should learn just to trust the summary results. The tests passed. Libpipeline-1.3.0 seems to work out-of-the-box. Configure with --prefix=/usr. Oddly a make check for libpipeline-1.3.0 doesn't appear to actually do anything. This was not the case for earlier versions of libpipeline. Well, that's one way of getting rid of the test failures, I guess. I must have done something wrong in the build before I sent this. Re-building libpipeline does cause 'make check' to execute the tests. I got one failure. I've talked to the owner of the project, and he's sent me a patch that does eliminate the failure. So I now have a libpipeline where all tests pass under Cygwin. Hi Chris, Would you like to send the patch to me? I still get the shared library warnings when building man-db. I haven't yet investigated that. regards, -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin needs a man-db port
Chris J. Breisch schreef op 2014-04-17 20:32: Erwin Waterlander wrote: Hi, The major linux distributions have switched for their man system to 'man-db' (http://man-db.nongnu.org/) in favour of the classic man. I think that Cygwin should also switch to man-db. man-db is much better in handling man pages in different encoding. Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be ported, because man-db uses it. I have tried to port man-db to Cygwin, but I did not succeed. I got stuck in libpipeline. Did anyone else succeed? Yes. And I agree this is a good idea. Dependencies: gdbm, libpipeline Build dependencies: pkgconfig, check, and the typical build stuff (make, gcc, etc.) As I indicated earlier, I believe the current version of check is not working properly. Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr. make check on check reports all tests passed, despite what appear to be some failures. The CHANGELOG says that this version should pass all tests on Cygwin. I've just subscribed to the mailing list and will check on whether these failures can be ignored or not. Still, it definitely appears to work better than the version we have now, which only passes 1 test in the test suite. Libpipeline-1.3.0 seems to work out-of-the-box. Configure with --prefix=/usr. Oddly a make check for libpipeline-1.3.0 doesn't appear to actually do anything. This was not the case for earlier versions of libpipeline. Well, that's one way of getting rid of the test failures, I guess. Man-db-2.6.7 appears to work out-of-the-box. Configuring man-db is a little harder than the other two. ../man-db-2.6.7/configure --prefix=/usr --disable-setuid --docdir=/usr/share/doc/man-db When I run that I get this error: checking for db1/db.h... no checking ndbm.h usability... no checking ndbm.h presence... no checking for ndbm.h... no configure: error: Fatal: no supported database library/header found If you don't add the --disable-setuid, you'll need to add a man user to your system. If you're not using Corinna's snapshots, you'll need to add the user to /etc/passwd as well. I'm not sure about the --docdir switch. That seemed to be consistent with Cygwin, but an actual package maintainer would be a better source of info on this. A couple of warnings are generated: *** Warning: This system can not link to static lib archive /usr/lib/libpipeline.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. and a similar one for libman.la. I do have shared versions of these libraries, so I'm not sure why the warnings appear. I seem to recall a thread about something similar recently in the Cygwin mailing lists. I may go back and check. Once installed, you'll want to do a 'mandb -c' to create the database. It will report numerous warnings which can generally be ignored. See the manpage on mandb. This takes a while. When new packages are added or updated on your system, you should run 'mandb -c' again. This seems like something that should be part of postinstall. My 32-bit Cygwin install has a lot of gzipped files and the uncompressed versions under /usr/share/man. mandb didn't like that at all. That is probably something I did and not a Cygwin problem. Note that I've done only the most minimal of testing. make check passes for man-db and I've opened a few man pages. They seem to work. Obviously, someone with decision making power should decide if this is something we want to add to Cygwin. My vote is yes, but that's just one vote. Or maybe even zero. I'm not sure I get a vote. :) Also obviously, if the decision is to go forward, these three items need to be packaged up appropriately and a package maintainer assigned. Check is already a Cygwin package, but needs updating. Somehow I have a feeling about who will be nominated for this task. What minimal testing I have done has been on both 32-bit and 64-bit Cygwin 1.7.29. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: ambiguous overload for operator [] on Cygwin_X86-64
On 2014-04-23 22:15, Tatsuro MATSUOKA wrote:
I tried to build wxWidgets-3.0.0 on Cygwin.
For Cygwin x86, the build was successful.
However, on Cygwin x86_64, the build failed at compling a cpp source file
(src/common/appbase.cpp).
./include/wx/filename.h: In static member function 'static wxUniChar
wxFileName::GetPathSeparator(wxPathFormat)':
./include/wx/filename.h:473:43: error: ambiguous overload for 'operator[]'
(operand types are 'wxString' and 'unsigned int')
{ return GetPathSeparators(format)[0u]; }
The code (format)[0u] seemed to be accepted g++-4.8.2 on Cygwin x86_64.
What the difference of g++ between that of Cygwin x86 and that of Cygwin
x86_64?
wxWidgets requires several patches to build and/or run correctly on
Cygwin/X. I haven't looked at 3.0 yet, but for 2.8 this issue is fixed
in my 2.8.12-cygwin64.patch:
http://sourceforge.net/p/cygwin-ports/wxWidgets2.8/
Yaakov
Cygwin/X
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
How LANG environment variable is set?
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I
start mintty. That script contains
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=$(/usr/bin/locale
-uU)
and at command line, '/usr/bin/locale -uU' prints it_IT.UTF-8...
If I start mintty (LANG empty) and the copy/paste the above lang.sh
line, after an ENTER I get
$ echo $LANG
it_IT.UTF-8
It is as if the script was not executed... or not? but surely I am
missing something..
Ciao,
Angelo.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How LANG environment variable is set?
On 04/24/2014 05:13 PM, Angelo Graziosi wrote:
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I start
mintty. That script contains
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=$(/usr/bin/locale -uU)
and at command line, '/usr/bin/locale -uU' prints it_IT.UTF-8...
If I start mintty (LANG empty) and the copy/paste the above lang.sh line,
after an ENTER I get
$ echo $LANG
it_IT.UTF-8
It is as if the script was not executed... or not? but surely I am missing
something..
WJFFM. What's the shell you're running? Are you setting the local and/or
character set in mintty itself? Is '/etc/profile' or any of the other
profile scripts being run? Perhaps cygcheck output would help if you can't
find out where things are going awry.
--
Larry
_
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How LANG environment variable is set?
Angelo Graziosi wrote:
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I
start mintty. That script contains
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=$(/usr/bin/locale -uU)
and at command line, '/usr/bin/locale -uU' prints it_IT.UTF-8...
It looks like /etc/profile sets LC_ALL=C before running the scripts
in /etc/profile.d, then restores it to its original setting. This
prevents LANG getting set by lang.sh.
--
David Rothenberger daver...@acm.org
It's what you learn after you know it all that counts.
-- John Wooden
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin needs a man-db port
waterlan schreef op 2014-04-24 21:43: Chris J. Breisch schreef op 2014-04-17 20:32: Erwin Waterlander wrote: Hi, The major linux distributions have switched for their man system to 'man-db' (http://man-db.nongnu.org/) in favour of the classic man. I think that Cygwin should also switch to man-db. man-db is much better in handling man pages in different encoding. Before man-db, libpipeline (http://libpipeline.nongnu.org/) needs to be ported, because man-db uses it. I have tried to port man-db to Cygwin, but I did not succeed. I got stuck in libpipeline. Did anyone else succeed? Yes. And I agree this is a good idea. Dependencies: gdbm, libpipeline Build dependencies: pkgconfig, check, and the typical build stuff (make, gcc, etc.) As I indicated earlier, I believe the current version of check is not working properly. Check-0.9.12 seems to work out-of-the-box. Configure with --prefix=/usr. make check on check reports all tests passed, despite what appear to be some failures. The CHANGELOG says that this version should pass all tests on Cygwin. I've just subscribed to the mailing list and will check on whether these failures can be ignored or not. Still, it definitely appears to work better than the version we have now, which only passes 1 test in the test suite. Libpipeline-1.3.0 seems to work out-of-the-box. Configure with --prefix=/usr. Oddly a make check for libpipeline-1.3.0 doesn't appear to actually do anything. This was not the case for earlier versions of libpipeline. Well, that's one way of getting rid of the test failures, I guess. Man-db-2.6.7 appears to work out-of-the-box. Configuring man-db is a little harder than the other two. ../man-db-2.6.7/configure --prefix=/usr --disable-setuid --docdir=/usr/share/doc/man-db When I run that I get this error: checking for db1/db.h... no checking ndbm.h usability... no checking ndbm.h presence... no checking for ndbm.h... no configure: error: Fatal: no supported database library/header found I needed to install gdbm-devel and then I could install man-db. If you don't add the --disable-setuid, you'll need to add a man user to your system. If you're not using Corinna's snapshots, you'll need to add the user to /etc/passwd as well. I'm not sure about the --docdir switch. That seemed to be consistent with Cygwin, but an actual package maintainer would be a better source of info on this. A couple of warnings are generated: *** Warning: This system can not link to static lib archive /usr/lib/libpipeline.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. and a similar one for libman.la. I had the same warnings. I do have shared versions of these libraries, so I'm not sure why the warnings appear. I seem to recall a thread about something similar recently in the Cygwin mailing lists. I may go back and check. Once installed, you'll want to do a 'mandb -c' to create the database. It will report numerous warnings which can generally be ignored. See the manpage on mandb. This takes a while. I got a couple of warnings. Not very much. When new packages are added or updated on your system, you should run 'mandb -c' again. This seems like something that should be part of postinstall. I did not do that. As far as I could see man-db worked very well. It displayed UTF-8, Latin-1, and KOI8-R encoded man pages correctly. I only tried 32 bit. I used check 0.9.12 libpipeline 1.3.0 man-db 2.6.7.1 best regards, My 32-bit Cygwin install has a lot of gzipped files and the uncompressed versions under /usr/share/man. mandb didn't like that at all. That is probably something I did and not a Cygwin problem. Note that I've done only the most minimal of testing. make check passes for man-db and I've opened a few man pages. They seem to work. Obviously, someone with decision making power should decide if this is something we want to add to Cygwin. My vote is yes, but that's just one vote. Or maybe even zero. I'm not sure I get a vote. :) Also obviously, if the decision is to go forward, these three items need to be packaged up appropriately and a package maintainer assigned. Check is already a Cygwin package, but needs updating. Somehow I have a feeling about who will be nominated for this task. What minimal testing I have done has been on both 32-bit and 64-bit Cygwin 1.7.29. -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: doxygen-1.8.7-1
The following packages have been updated: - doxygen-1.8.7-1 - doxygen-doxywizard-1.8.7-1 CHANGES: Numerous new features and bug fixes. For the full change log, please see: http://www.doxygen.org/manual/changelog.html#log_1_8_7 DESCRIPTION === Doxygen is a documentation system for C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavours), Fortran, VHDL, PHP, C#, and to some extent D. HOMEPAGE http://www.doxygen.org/ Cheers, Dave. If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How LANG environment variable is set?
On 04/24/2014 05:56 PM, David Rothenberger wrote:
Angelo Graziosi wrote:
I remember that some time ago I had, in mintty,
$ echo $LANG
it_IT.UTF-8
Now LANG is empty ('echo $LANG' prints nothing).
I notice that /etc/profile.d has lang.sh which should set LANG when I
start mintty. That script contains
test -z ${LC_ALL:-${LC_CTYPE:-$LANG}} export LANG=$(/usr/bin/locale -uU)
and at command line, '/usr/bin/locale -uU' prints it_IT.UTF-8...
It looks like /etc/profile sets LC_ALL=C before running the scripts
in /etc/profile.d, then restores it to its original setting. This
prevents LANG getting set by lang.sh.
Good catch. Yes, the latest version of base_files makes this change to
the profile_d() function. Looks like the easiest interim solution is to
downgrade to base_files-4.1-2.
--
Larry
_
A: Yes.
Q: Are you sure?
A: Because it reverses the logical flow of conversation.
Q: Why is top posting annoying in email?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: How LANG environment variable is set?
David Rothenberger wrote: It looks like /etc/profile sets LC_ALL=C before running the scripts in /etc/profile.d, then restores it to its original setting. This prevents LANG getting set by lang.sh. The statement LC_ALL=C has been introduced in /et/profile with the recent upgrade of base-file 4.2 (and indeed I was sure with base-fle 4.1 LANG was correctly set..) So, is this how things should work or we have caught a bug in the new base-file 4.2 release? Ciao, Angelo. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin needs a man-db port
waterlan wrote: I must have done something wrong in the build before I sent this. Re-building libpipeline does cause 'make check' to execute the tests. I got one failure. I've talked to the owner of the project, and he's sent me a patch that does eliminate the failure. So I now have a libpipeline where all tests pass under Cygwin. Hi Chris, Would you like to send the patch to me? It's been committed into git. http://git.savannah.gnu.org/cgit/libpipeline.git/commit/?id=6d04129e3a99c0281cb12098f871a0bc94d08025 I'm also currently waiting on a patch for the one test failure for man-db. -- Chris J. Breisch -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Coverity Scan
Coverity Scan [1] is a commercial (paid for) static analysis tool, but they offer it to Open Source programmes for free. I was having a browse through the list of Open Source programmes using Coverity Scan, and noticed that Cygwin wasn't listed. Would there be any interest in analysing the cygwin1.dll source code on a fairly regular basis? If so, I would be happy to have a go at setting up an analysis job for Cygwin. I would imagine this would be of interest to CGF, Corinna and anyone else who regularly updates the Cygwin source code. Obviously, this is only worth doing if the analysis results are looked at and acted upon. There are some conditions associated with using Coverity Scan [2]. The one thing that jumps out is that our relationship with RedHat might be a stumbling block. We can but ask - the worst that can happen is that they politely decline. There have been a few hints on this list about a possible move from CVS to git. If such a move were on the cards then that should probably happen first - I wouldn't want the nugatory effort of getting this working from CVS only to have to change it almost immediately. Any thoughts? Dave. [1] - https://scan.coverity.com/ [2] - https://scan.coverity.com/faq#how-get-project-included-in-scan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
