Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.8.0-0.4
On 24/03/2017 19:32, Corinna Vinschen wrote: Hi folks, I uploaded a new Cygwin test release 2.8.0-0.4 This version (hopefully) fixes the concurrency problems in cygserver. This is the only change compared to 2.8.0-0.3. parallel test on postgresql is now working without restrictions on MAX_CONNECTIONS Thanks Marco -- 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: [ANNOUNCEMENT] python3 3.6.1-2 (x86 only)
Hello, On Fri, 24 Mar 2017 13:22:56 -0500 Yaakov Selkowitz wrote: > This release fixes thread allocation issues reported with WoW64 on some > versions of Windows. As this only affects 32-bit Cygwin, the 64-bit build > has not been updated. Thanks for quick fix. I have confirmed the issue has been fixed. However, I have found another prombem related this issue. Python API PyThread_create_key() in the latest release of 64-bit version returns an invalid key value, which is truncated into int size. To confirm this, execute following script: --- from here --- from ctypes import pythonapi key = pythonapi.PyThread_create_key() res1 = pythonapi.PyThread_set_key_value(key, ) res2 = pythonapi.PyThread_get_key_value(key) res3 = pythonapi.PyThread_delete_key(key) print(key,res1,res2,res3) --- to here --- Expected result is: 1 0 0 '1' in the first column can be any other value, but the remaining columns must be '0 0'. However, result of 64-bit version is: 1145600 -1 0 22 This means PyThread_set_key_value(), PyThread_get_key_value() and PyThread_delete_key() fail to access key 1145600. This is because the key value is invalid. It seems that the 64 bit key value is truncated into 32-bit value. To fix this issue as well as the issue on WOW, I have made two patches attached, based on two different ideas. pthread-cygwin-1.patch: The higher part of key value is saved, and only lower part is handed to python API. The key value is recombined with higher part when it handed to cygwin pthread functions. Smaller memory and little bit faster. pthread-cygwin-2.patch: The key value returned by cygwin pthread_key_create() is saved in table, and index of the table is handed to python API as a key. The key value is converted via the table when it handed to cygwin pthread functions. Larger memory but steady operation. I prefer pthread-cygwin-2.patch. What do you think? -- Takashi Yano pthread-cygwin-1.patch Description: Binary data pthread-cygwin-2.patch Description: Binary data -- 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: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3, libreadline-devel-7.0.3-3
On Mon, 13 Feb 2017 13:49:40, "Eric Blake (cygwin)" wrote: A new release of readline, 7.0.3-3, has been uploaded and will soon reach a mirror near you. The previous version is now 7.0.1-2 (which was experimental, but never current; but the only difference from 7.0.1-1 was handling of pselect which is now fixed in cygwin 2.7.0-1). Since we have determined that this: http://cygwin.com/ml/cygwin/2017-02/msg00031.html is a Readline problem (and Bash problem by nature of dependency), I am reposting under the correct thread. The error linked above occurs when UTF-8 (chcp.com 65001) is set. This can be worked around by using "chcp.com 437", but UTF-8 is needed with mingw32 programs: http://cygwin.com/ml/cygwin/2017-03/msg00193.html -- 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: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.8.0-0.4
On 24/03/2017 19:32, Corinna Vinschen wrote: Hi folks, I uploaded a new Cygwin test release 2.8.0-0.4 Lost in transfer ? -- 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
inetutils-server, OpenSP and units install glitches and fixes
Running setup updates and installs in mirror-mode, I had 3 problems. The first
is "fixed." The 2nd is fixed, with a question. The 3rd is still a puzzle.
Setup message:
Package: _/Unknown package
inetutils-server.sh exit code 1
OpenSP.sh exit code 127
/var/log/setup.log.full excerpts:
2017/03/24 09:48:43 running: E:\cygwin64-3\bin\bash.exe --norc --noprofile
"/etc/postinstall/inetutils-server.sh"
*** Warning: The owner and the Administrators need
*** Warning: to have .w. permission to /var/run.
*** Warning: Here are the current permissions and ACLS:
*** Warning: drwxr-xr-x 1 myuser Domain Users 0 Mar 14 17:48 /var/run
*** Warning: # file: /var/run
*** Warning: # owner: myuser
*** Warning: # group: Domain Users
*** Warning: user::rwx
*** Warning: group::r-x
*** Warning: other:r-x
*** Warning:
*** Warning: Please change the user and/or group ownership,
*** Warning: permissions, or ACLs of /var/run.
...
*** ERROR: Problem with /var/run directory. Exiting.
2017/03/24 09:49:28 abnormal exit: exit code=1
=
(1) "Fix:" Finally realized ftp, talk, telnet or uucp aren't needed, and
uninstalled inetutils-server and inetutils. "Common networking clients and
servers" sounded necessary, but apparently not. :D
=
(2)
2017/03/24 09:49:28 running: E:\cygwin64-3\bin\bash.exe --norc --noprofile
"/etc/postinstall/OpenSP.sh"
/etc/postinstall/OpenSP.sh: line 1: /usr/bin/install-catalog: No such file or
directory
2017/03/24 09:49:28 abnormal exit: exit code=127
Fix: installed sgml-common (containing install-catalog). After the above error,
it was not yet installed and not pending. Then installed OpenSP. It was also
not yet installed, and not pending.
Question: These were obviously needed for each other, and needed by other
packages, so why didn't the first install work, and why did they not show up as
pending the next time?
=
(3) "units" converter sounded useful, but install failed with:
2017/03/24 09:51:44 running: E:\cygwin64-3\bin\bash.exe --norc --noprofile
"/etc/postinstall/zp_units_cur.sh"
Error connecting to currency server.
So, this is trying to do:
/etc/postinstall
$ cat zp_units_cur.sh
/usr/bin/find /usr/share/units/currency.units -mtime +0 -exec
/usr/bin/units_cur \;
and units_cur is a python3 script trying to do:
$ grep http /usr/bin/units_cur
currencies =
ET.parse(urllib.request.urlopen('http://rss.timegenie.com/forex.xml')).findall('data')
outstr += '\n\n# Precious metals prices from
http://services.packetizer.com/spotprices/\n\n'
spotprices =
ET.parse(urllib.request.urlopen('http://services.packetizer.com/spotprices/?f=xml'))
And of course this fails behind my proxy, because with --norc and --noprofile,
setup/bash doesn't have the proxy info'.
Questions: Is it kosher for security for an installing package like this to
obtain something from the internet like this, and if so, how can I give it the
proxy info (other than running it with rc and profile)?
On a related note, using not ancient Red Hat 5.6 where the mirror is stored,
tar won't expand the Cygwin packages?
$ tar -xvf units-2.13-1.tar.xz
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Archive contains obsolescent base-64 headers
tar: Read 9640 bytes from units-2.13-1.tar.xz
tar: Error exit delayed from previous errors
$ tar --version
tar (GNU tar) 1.15.1
but tar Packaged by Cygwin (1.29-1) will.
--
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] TEST RELEASE: Cygwin 2.8.0-0.4
Hi folks, I uploaded a new Cygwin test release 2.8.0-0.4 This version (hopefully) fixes the concurrency problems in cygserver. This is the only change compared to 2.8.0-0.3. I'm planning for a release next week. I'm still trying to find the cause for a bug, but either way, I'll release next week. Please test. === What's new: --- - New API: timingsafe_bcmp, timingsafe_memcmp - New API: dladdr What changed: - - cygcheck and strace now always generate output with Unix LF line endings, rather than with DOS/Windows CR LF line endings. - fork now preserves the load order of unrelated dlopen'd modules. - pthread_cond_wait now acts like Linux and BSD: Resume waiting for the condition variable as if it was not interrupted, rather than returning 0. Bug Fixes - - Fix a few problems which are the combined culprit of fork failing when called recursively from a pthread. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00113.html - Fix potential buffer overflow in getrandom. - Fix write(2) return value for writes > 2 GB. - Workaround Windows NUL having the same problem for writes > 4 GB. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00144.html - Fix a potential crash in duplocale. Addresses: https://sourceware.org/ml/newlib/2017/msg00166.html - Fix dlopen/dlclose reference counting to make sure FreeLibrary isn't called too early in forked process. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00220.html - Fix concurrency problems in cygserver. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00218.html === Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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] python3 3.6.1-2 (x86 only)
The following packages have been uploaded to the Cygwin x86 distribution: * python3-3.6.1-2 * python3-devel-3.6.1-2 * python3-test-3.6.1-2 * python3-tkinter-3.6.1-2 * idle3-3.6.1-2 Python is an interpreted, interactive, object-oriented programming language. It incorporates modules, exceptions, dynamic typing, very high level dynamic data types, and classes. Python combines remarkable power with very clear syntax. It has interfaces to many system calls and libraries, as well as to various window systems, and is extensible in C or C++. It is also usable as an extension language for applications that need a programmable interface. This release fixes thread allocation issues reported with WoW64 on some versions of Windows. As this only affects 32-bit Cygwin, the 64-bit build has not been updated. -- Yaakov -- 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] gsl 2.3-2
The following packages have been uploaded to the Cygwin distribution: * gsl-2.3-2 * libgsl19-2.3-2 * libgsl-devel-2.3-2 * mingw64-i686-gsl-2.3-2 * mingw64-x86_64-gsl-2.3-2 The GNU Scientific Library, a collection of numerical routines for scientific computing. The library provides a wide range of mathematical routines such as random number generators, special functions and least-squares fitting. This release should fix the reported issue with . -- Yaakov -- 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: cygserver - Postgres Multiple connection Load Testing - Inifinte Loop
Hi Noah,
thanks for the report and especially the testcase. It took me a while
to debug that, but I think I fixed it now. At least your testcase is
working for me now. It also got faster, albeit always slower than Linux
because of the communication overhead between processes and cygserver.
On Mar 21 02:56, Noah Misch wrote:
> On Tue, Aug 03, 2004 at 12:06:12PM +0200, Corinna Vinschen wrote:
> > On Aug 2 20:33, sarbx-cygwin6...@mailblocks.com wrote:
> > > This time around, cygserver does not eat CPU. But after 5 to 6
> > > concurrent
> > > connections nothing seem to work, looks kind of hung. There is no
> > > activity in the Postgres
> > > log file. Opening a new database connection also hangs. There is no
> > > activity on the machine.
>
> > Any chance to create a simple testcase which uncovers that behaviour
> > without involving a whole database system?
>
> Attached test program reproduces it on Cygwin 2.7.0, Cygwin 1.7.5, and a few
> intermediate versions. The program creates sixteen processes that each
> perform a tight loop over the following:
>
> - select one of four semaphores
> - reduce semaphore's value from 1 to 0 ("lock" it)
> - raise semaphore's value from 0 to 1 ("unlock" it)
>
> On GNU/Linux, AIX, and Solaris, the processes keep busy and finish one million
> lock/unlock cycles apiece in a few minutes. On Cygwin, they hang within a few
> seconds and under one hundred cycles apiece. At that point, cygserver is
> unresponsive to other clients; for example, "strace /bin/true", opening a new
> Cygwin terminal, "cat /proc/sysvipc/sem" and "cygserver -S" all hang. In most
> tests, cygserver was not consuming CPU while unresponsive.
There are two problems here.
- cygserver is using a defined number of threads in a thread pool for
application requests. Every request is added to a request submission
queue and handled by the next free thread in the pool.
The default number of threads in the pool is 10. Each wait for a
semaphore is blocking one thread. If more than the number of threads
in the pool are supposed to wait on a semaphore the pool starves.
Raising the pool size fixes this part, but the situation is still a bit
unsatisfying. You may not know the load and the number of competing
processes in every scenario beforehand, but raising cygservers thread
pool to some really big value doesn't always make sense either.
So what I did now is to allow cygserver to raise the number of worker
threads on demand. That is, if a request is in the queue and all
worker threads are busy, just create a new one.
There's no way yet to drop threads again, but this should be a minor
problem in scenarions which really have a lot of contention.
- The code emulating BSD msleep/wakeup wasn't quite up to speed.
I rewrote a major part of the code to be more robust and faster.
I pushed a patchset now, and uploaded new developer snapshots for
testing to https://cygwin.com/snapshots/
I'm also going to create a 2.8.0-0.4 test release later today.
Please give it a try, and please note that *all* patches affect
cygserver itself, so you have to test the new cygserver in the
first place. The Cygwin DLL is not affected by the changes.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
signature.asc
Description: PGP signature
Re: Volunteer to update GNU Scientific Library package to gsl-2.2?
I'm getting the error message that
"The program can't start because cyggsl-0.dll" is missing from your
computer"
Upon compiling I get the errors:
---_
In file included from /usr/include/gsl/gsl_blas.h:29:0,
from main.C:31:
/usr/include/gsl/gsl_blas_types.h:43:15: error: using typedef-name
'CBLAS_ORDER' after 'enum'
typedef enum CBLAS_ORDER CBLAS_ORDER_t;
^
In file included from /usr/include/gsl/gsl_cblas.h:1:0,
from /usr/include/gsl/gsl_blas_types.h:28,
from /usr/include/gsl/gsl_blas.h:29,
from main.C:31:
/usr/include/cblas.h:25:22: note: 'CBLAS_ORDER' has a previous declaration
here
typedef CBLAS_LAYOUT CBLAS_ORDER; /* this for backward compatibility with
CBLAS_ORDER */
^
In file included from /usr/include/gsl/gsl_blas.h:29:0,
from main.C:31:
/usr/include/gsl/gsl_blas_types.h:44:15: error: using typedef-name
'CBLAS_TRANSPOSE' after 'enum'
typedef enum CBLAS_TRANSPOSE CBLAS_TRANSPOSE_t;
^
In file included from /usr/include/gsl/gsl_cblas.h:1:0,
from /usr/include/gsl/gsl_blas_types.h:28,
from /usr/include/gsl/gsl_blas.h:29,
from main.C:31:
/usr/include/cblas.h:20:69: note: 'CBLAS_TRANSPOSE' has a previous
declaration here
typedef enum {CblasNoTrans=111, CblasTrans=112, CblasConjTrans=113}
CBLAS_TRANSPOSE;
^
In file included from /usr/include/gsl/gsl_blas.h:29:0,
from main.C:31:
/usr/include/gsl/gsl_blas_types.h:45:15: error: using typedef-name
'CBLAS_UPLO' after 'enum'
typedef enum CBLAS_UPLOCBLAS_UPLO_t;
^
In file included from /usr/include/gsl/gsl_cblas.h:1:0,
from /usr/include/gsl/gsl_blas_types.h:28,
from /usr/include/gsl/gsl_blas.h:29,
from main.C:31:
/usr/include/cblas.h:21:47: note: 'CBLAS_UPLO' has a previous declaration
here
typedef enum {CblasUpper=121, CblasLower=122} CBLAS_UPLO;
^
In file included from /usr/include/gsl/gsl_blas.h:29:0,
from main.C:31:
/usr/include/gsl/gsl_blas_types.h:46:15: error: using typedef-name
'CBLAS_DIAG' after 'enum'
typedef enum CBLAS_DIAGCBLAS_DIAG_t;
^
In file included from /usr/include/gsl/gsl_cblas.h:1:0,
from /usr/include/gsl/gsl_blas_types.h:28,
from /usr/include/gsl/gsl_blas.h:29,
from main.C:31:
/usr/include/cblas.h:22:48: note: 'CBLAS_DIAG' has a previous declaration
here
typedef enum {CblasNonUnit=131, CblasUnit=132} CBLAS_DIAG;
^
In file included from /usr/include/gsl/gsl_blas.h:29:0,
from main.C:31:
/usr/include/gsl/gsl_blas_types.h:47:15: error: using typedef-name
'CBLAS_SIDE' after 'enum'
typedef enum CBLAS_SIDECBLAS_SIDE_t;
^
In file included from /usr/include/gsl/gsl_cblas.h:1:0,
from /usr/include/gsl/gsl_blas_types.h:28,
from /usr/include/gsl/gsl_blas.h:29,
from main.C:31:
/usr/include/cblas.h:23:46: note: 'CBLAS_SIDE' has a previous declaration
here
typedef enum {CblasLeft=141, CblasRight=142} CBLAS_SIDE;
--
Any help is appreciated. Thanks.
--
View this message in context:
http://cygwin.1069669.n5.nabble.com/Volunteer-to-update-GNU-Scientific-Library-package-to-gsl-2-2-tp132997p133023.html
Sent from the Cygwin list mailing list archive at Nabble.com.
--
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: Volunteer to update GNU Scientific Library package to gsl-2.2?
Yaakov, this is greatly appreciated! Thank you. -- View this message in context: http://cygwin.1069669.n5.nabble.com/Volunteer-to-update-GNU-Scientific-Library-package-to-gsl-2-2-tp132997p133021.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Volunteer to update GNU Scientific Library package to gsl-2.2?
On Thu, 3/23/17, zab2t wrote: Subject: Volunteer to update GNU Scientific Library package to gsl-2.2? To: cygwin@cygwin.com Date: Thursday, March 23, 2017, 3:08 PM Is there anyone willing to volunteer to update the GNU Scientific Library package to at least version gsl-2.x? Wow, ask and receive! [ANNOUNCEMENT] gsl 2.3-1 From: Yaakov Selkowitz Date: Fri, 24 Mar 2017 01:45:38 -0500 Subject: [ANNOUNCEMENT] gsl 2.3-1 The following packages have been uploaded to the Cygwin distribution: * gsl-2.3-1 https://cygwin.com/ml/cygwin/2017-03/msg00295.html -- 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] emacs 25.2-0.1
The following packages have been uploaded to the Cygwin distribution:
* emacs-25.2-0.1
* emacs-el-25.2-0.1
* emacs-X11-25.2-0.1
* emacs-w32-25.2-0.1
Emacs is a powerful, customizable, self-documenting, modeless text
editor. Emacs contains special code editing features, a scripting
language (elisp), and the capability to read mail, news, and more
without leaving the editor.
This is a build from a release candidate for the upcoming emacs-25.2.
I'm releasing it now rather than waiting for the official upstream
release because a rebuild was needed anyway to fix the problem
reported here:
https://cygwin.com/ml/cygwin/2017-03/msg00280.html
This is mainly a bugfix release, but there are some other changes.
Browse the NEWS file ('C-h n' within emacs) for details.
CYGWIN NOTES
1. The emacs, emacs-w32, and emacs-X11 packages each provide an Emacs
binary. These are emacs-nox.exe, emacs-w32.exe, and emacs-X11.exe,
respectively, in order of increasing priority. The postinstall
scripts use the 'alternatives' system to create a symlink
/usr/bin/emacs that resolves to the highest-priority binary that you
have installed. Thus the command 'emacs' will start emacs-X11.exe if
you've installed the emacs-X11 package; otherwise, it will start
emacs-w32.exe if you've installed emacs-w32; otherwise, it will start
emacs-nox.exe. Similar remarks apply to emacsclient.
If you have installed both emacs-w32 and emacs-X11 and prefer to give
higher priority to emacs-w32, run the script
/usr/bin/set-emacs-default-w32.sh
You can later restore emacs-X11 as the default by running
/usr/bin/set-emacs-default-X11.sh
2. Install emacs-X11 if you want to use the X11 GUI. You can then
type 'emacs&' in an xterm window, and emacs will start in a new
window.
3. Install emacs-w32 if you want to use the native Windows GUI instead
of X11.
4. If you have sshd running and want to be able to run emacs-X11 from
a remote machine, you need to enable X11 forwarding by adding the
following line to /etc/sshd_config:
X11Forwarding yes
You might also need to have the cygserver service running.
5. The script /usr/bin/make-emacs-shortcut can be used to create a
shortcut for starting emacs. See /usr/share/doc/emacs/README.Cygwin
for details.
Ken Brown
Cygwin's Emacs maintainer
--
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
Error after invoking "man grep" (locale-dependent)
Hello,
I observe the following error message after exiting the pager (less) for
"man grep":
> man: command exited with status 127: iconv -c -f UTF-8 -t CP1251//TRANSLIT |
> col -b -p -x | sed -e '/^[[:space:]]*$/{ N; /^[[:space:]]*\n[[:space:]]*$/D;
> }'
The easiest way to reproduce this is to run
> man grep >/dev/null
in a ru_RU.CP1251 environment:
> $ locale
> LANG=ru_RU.CP1251
> LC_CTYPE="ru_RU.CP1251"
> LC_NUMERIC="ru_RU.CP1251"
> LC_TIME="ru_RU.CP1251"
> LC_COLLATE="ru_RU.CP1251"
> LC_MONETARY="ru_RU.CP1251"
> LC_MESSAGES="C"
> LC_ALL=
The same for en_US locale:
> man: command exited with status 127: iconv -c -f UTF-8 -t
> ISO-8859-1//TRANSLIT | col -b -p -x | sed -e '/^[[:space:]]*$/{ N;
> /^[[:space:]]*\n[[:space:]]*$/D; }'
The issue is not reproducible in UTF-8 locales.
grep(1) seems to be the only manual page affected.
Regards,
Andrey.
signature.asc
Description: OpenPGP digital signature
Re: 3-line Emacs window after Gnome updates
On 3/24/2017 7:50 AM, Ken Brown wrote: On 3/23/2017 5:27 PM, Yaakov Selkowitz wrote: Which btw is just wrong; they should have used the gtk_check_version function instead of the GTK_CHECK_VERSION macro. In any case, try rebuilding emacs with libgtk3-devel 3.22. Thanks, Yaakov. I think your diagnosis is correct, and rebuilding fixed the problem. I've uploaded a new release. And I've reported the problem upstream: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23144#78 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: 3-line Emacs window after Gnome updates
On 3/23/2017 5:27 PM, Yaakov Selkowitz wrote: On 2017-03-23 16:02, Ken Brown wrote: Do you have an emacs.geometry setting in your ~/.Xresources? Or any kind of size setting in your emacs initialization files? If not, I guess emacs or X11 has a default. I'll look into the 3-line window and see if I can figure out what's going on. This might be related: http://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-25.1&id=9ca5dbf947a7421d37b3e2d2bc6b8d2c9218bc65 Which btw is just wrong; they should have used the gtk_check_version function instead of the GTK_CHECK_VERSION macro. In any case, try rebuilding emacs with libgtk3-devel 3.22. Thanks, Yaakov. I think your diagnosis is correct, and rebuilding fixed the problem. I've uploaded a new release. 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
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.8.0-0.3
Hi folks, I uploaded a new Cygwin test release 2.8.0-0.3 This version just fixes the output of stray debugging statements I left in the code accidentally. Otherwise it's the same as 2.8.0-0.2 I'm planning for a release next week. I'm still trying to find the cause for a bug, but either way, I'll release next week. Please test. === What's new: --- - New API: timingsafe_bcmp, timingsafe_memcmp - New API: dladdr What changed: - - cygcheck and strace now always generate output with Unix LF line endings, rather than with DOS/Windows CR LF line endings. - fork now preserves the load order of unrelated dlopen'd modules. - pthread_cond_wait now acts like Linux and BSD: Resume waiting for the condition variable as if it was not interrupted, rather than returning 0. Bug Fixes - - Fix a few problems which are the combined culprit of fork failing when called recursively from a pthread. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00113.html - Fix potential buffer overflow in getrandom. - Fix write(2) return value for writes > 2 GB. - Workaround Windows NUL having the same problem for writes > 4 GB. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00144.html - Fix a potential crash in duplocale. Addresses: https://sourceware.org/ml/newlib/2017/msg00166.html - Fix dlopen/dlclose reference counting to make sure FreeLibrary isn't called too early in forked process. Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00220.html === Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- 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: [ANNOUNCEMENT] python3 3.6.1-1
On 2017-03-23 10:47, Takashi Yano wrote: This version of python3 for 32 bit cygwin fails to start on 64 bit Windows 7. Error message is: --- from here --- Fatal Python error: Could not allocate TLS entry Abort (core dumped) --- to here --- Confirmed, and same applies to 8.1, but not 10. Corinna, would it be plausible that TlsAlloc is returning a value in the 0x8000-0x range on 7 and 8.1, but not 10, and why? -- Yaakov -- 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
