Re: cfget-0.18-1 32bit (uploaded soon)
On 2015-11-05 10:26, Corinna Vinschen wrote: | On Oct 20 12:23, Corinna Vinschen wrote: | > Jari, ping? | > | > On Oct 19 17:54, Marco Atzeri wrote: | > > On 19/10/2015 17:45, Corinna Vinschen wrote: | > > >On Sep 26 11:43, Marco Atzeri wrote: | > > >>Jari, | > > >>any specific reason why there is only a 64 bit version ? | > > >> | > > >>As it seems just a python script, it should work on both arch correct ? | > > > | > > >Did this get resolved? | > > > | > > > | > > >Corinna | > > | > > the 32bit version is still missing Hm, must have slipped through my eyes. I'll take care of it ASAP. Jari signature.asc Description: Digital signature
[newlib-cygwin] Fix iterating over pending signals if a signal doesn't have to be cleared
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=eeef72702692fca52610634da32b56241e8083f3 commit eeef72702692fca52610634da32b56241e8083f3 Author: Corinna VinschenDate: Thu Nov 5 10:09:08 2015 +0100 Fix iterating over pending signals if a signal doesn't have to be cleared * sigproc.cc (pending_signals::clear): Yet another fix to fix the fix. Actually iterate over the list of pending signals even if there's a signal which doesn't have to be cleared. Other than that, revert loop to it's former self as a while loop. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/ChangeLog | 7 +++ winsup/cygwin/sigproc.cc | 11 --- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index b848583..456bcd1 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,3 +1,10 @@ +2015-11-05 Corinna Vinschen + + * sigproc.cc (pending_signals::clear): Yet another fix to fix the fix. + Actually iterate over the list of pending signals even if there's a + signal which doesn't have to be cleared. Other than that, revert loop + to it's former self as a while loop. + 2015-11-04 Corinna Vinschen * globals.cc (ro_u_prlfs): Add trailing NUL. Explain why. diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc index 6a7708f..9810045 100644 --- a/winsup/cygwin/sigproc.cc +++ b/winsup/cygwin/sigproc.cc @@ -402,11 +402,16 @@ sig_clear (int sig) void pending_signals::clear (_cygtls *tls) { - sigpacket *q, *qnext; + sigpacket *q = , *qnext; - for (q = (qnext = q->next); q->next = qnext->next) + while ((qnext = q->next)) if (qnext->sigtls == tls) - qnext->si.si_signo = 0; + { + qnext->si.si_signo = 0; + q->next = qnext->next; + } +else + q = qnext; } /* Clear pending signals of specific thread. Called from _cygtls::remove */
[newlib-cygwin/cygwin-acl] Fix iterating over pending signals if a signal doesn't have to be cleared
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=d735b30eefe2d35d0d2a2d66ac12004662fc1525 commit d735b30eefe2d35d0d2a2d66ac12004662fc1525 Author: Corinna VinschenDate: Thu Nov 5 10:09:08 2015 +0100 Fix iterating over pending signals if a signal doesn't have to be cleared * sigproc.cc (pending_signals::clear): Yet another fix to fix the fix. Actually iterate over the list of pending signals even if there's a signal which doesn't have to be cleared. Other than that, revert loop to it's former self as a while loop. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/ChangeLog | 7 +++ winsup/cygwin/sigproc.cc | 11 --- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index 2946387..a3f7cac 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,3 +1,10 @@ +2015-11-05 Corinna Vinschen + + * sigproc.cc (pending_signals::clear): Yet another fix to fix the fix. + Actually iterate over the list of pending signals even if there's a + signal which doesn't have to be cleared. Other than that, revert loop + to it's former self as a while loop. + 2015-11-04 Corinna Vinschen * globals.cc (ro_u_prlfs): Add trailing NUL. Explain why. diff --git a/winsup/cygwin/sigproc.cc b/winsup/cygwin/sigproc.cc index 6a7708f..9810045 100644 --- a/winsup/cygwin/sigproc.cc +++ b/winsup/cygwin/sigproc.cc @@ -402,11 +402,16 @@ sig_clear (int sig) void pending_signals::clear (_cygtls *tls) { - sigpacket *q, *qnext; + sigpacket *q = , *qnext; - for (q = (qnext = q->next); q->next = qnext->next) + while ((qnext = q->next)) if (qnext->sigtls == tls) - qnext->si.si_signo = 0; + { + qnext->si.si_signo = 0; + q->next = qnext->next; + } +else + q = qnext; } /* Clear pending signals of specific thread. Called from _cygtls::remove */
Re: [ITP] fzf 0.10.8
Hi Adam, On Nov 2 10:37, Adam Dinwoodie wrote: > Folks, > > I'm looking at packaging fzf[0], which is a "fuzzy finder" with shell > and Vim integration. It's not nearly so fast on Cygwin as it is on my > Linux and Mac boxes, sadly (I suspect a combination of it needing to > fall back to Ruby due to Cygwin's lack of Go compiler, plus the standard > Cygwin overheads), but it's still pretty fast, and I've been using it > myself on Cygwin for a couple of weeks, and on my CentOS box for a fair > bit longer. > > The upstream package has an MIT license and is already included by Arch > Linux[1]. The main setup.hint is below, and it's ready to upload as > soon as it's declared GTG; I've uploaded the entire package tree[2] and > Cygport packaging code[3] for reference, too. > > [0]: https://github.com/junegunn/fzf > [1]: https://aur.archlinux.org/packages/fzf/ > [2]: https://tastycake.net/~adam/cygwin/fzf/ > [3]: https://github.com/me-and/Cygwin-fzf/ GTG. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpggbKUmAnNq.pgp Description: PGP signature
Re: Segmentation fault before main
On Wed, Nov 4, 2015 at 10:42 PM, Marco Atzeri wrote: > > > For the archive, I found the culprit in the test code. > Using "%lu" to print int is not a good idea on cygwin 64 bit. That's why we have -Wformat=2 Csaba -- GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++ The Tao of math: The numbers you can count are not the real numbers. Life is complex, with real and imaginary parts. "Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds "People disagree with me. I just ignore them." -- Linus Torvalds -- 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: Error accessing mapped drive >2TB?
On Nov 3 15:18, Warren Young wrote: > On Oct 26, 2015, at 5:15 AM, Corinna Vinschen wrote: > > > > On Oct 23 16:15, Warren Young wrote: > >> On Oct 23, 2015, at 8:30 AM, Jeffrey Altman wrote: > >>> While Apple's design choices do not fit with the expectations of Cygwin > >>> they are not necessarily wrong. > >> > >> So, should I send Apple this code, or not? > >> > >> http://pastebin.com/uZdDZPgi > > > > Wouldn't hurt I guess. They are free to ignore us, of course :} > > I finally got around to writing this up. It’s radar ID 23381990 at > https://bugreport.apple.com/ > > You might want to read it over. I’m not certain I’m describing the > problem clearly or completely. "An Apple ID is required to use this tool." Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpK0FGDBwgCJ.pgp Description: PGP signature
Re: Segmentation fault before main
On Nov 4 22:42, Marco Atzeri wrote: > On 30/10/2015 20:45, Marco Atzeri wrote: > >On 30/10/2015 20:18, Corinna Vinschen wrote: > >>On Oct 30 16:25, Marco Atzeri wrote: > >>>Hi Corinna, > >>> > > > >>>Any help will be really appreciated. > >> > >>Well, it's a stack probe. It's typically called when trying to allocate > >>big datastructures on the stack, e.g. with alloca. Did you try to raise > >>the default stacksize in the executable header (see peflags -x and -X > >>options). There's not much else to work with... > >> > > > For the archive, I found the culprit in the test code. I'm happy to read that. > Using "%lu" to print int is not a good idea on cygwin 64 bit. > > > - bbprintf0(stmt,"%ssize_t %s_countset[%lu] = {", > + bbprintf0(stmt,"%ssize_t %s_countset[%u] = {", > indented(1), > cname(vsym), > rank); ...and you wouldn't even have noticed it on Linux, because it uses the SystemV ABI which passes the first 6 arguments in registers, in contrast to the MS ABI which only passes the first 4 arguments in regs. Thus on Linux you'd have silenty get the benefit of the CPU clearing the upper 32 bits of a register when moving a 32 bit value into it, which doesn't happen when moving a 32 bit argument to the stack. That's one of the interesting side effects of porting an application. Maybe it would make sense to mention this problem in https://cygwin.com/faq/faq.html#faq.programming.64bitporting... > as it could produce > > size_t br_startset[25769803777] = {0} ; > size_t br_countset[25769803777] = {2}; Ouch. > instead of >size_t br_startset[1] = {0} ; >size_t br_countset[1] = {2}; > > > as 25769803777 = 0x00060001 I guess you mean 0x60001 :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHlpzO6EERE.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.6
On Nov 4 22:25, Achim Gratz wrote: > Achim Gratz writes: > > Just confirmed this on another system. If I kill the child, then the > > parent resumes and finishes the test loop alright and it can be > > interrupted again from the shell. The hang happens after the first test > > succeeds in both the parent and child. > > I have just managed to kill the parent (returning the shell prompt) and > have the child complete the test loop output to the terminal. So I > guess the communication ping-pong is somehow buggered up so that pipes > start blocking. Staring into the latest version of my new function to remove pending signals, after having some *more* coffee, it seems pretty clear I screwed this up nicely. What I was missing all the time was to iterate over the list of pending signals if there's a pending signal which doesn't have to be cleared. This case was just missing. Duh! I guess I didn't really cover myself in glory here... I applied yet another patch and uploaded a new developer snapshot (this time *with* the ACL changes) to https://cygwin.com/snapshots/ Can you please give it a try ASAP? Thank you, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp5fzxAcwkor.pgp Description: PGP signature
Re: cfget-0.18-1 32bit ?
Jari? Are you still with us? On Oct 20 12:23, Corinna Vinschen wrote: > Jari, ping? > > On Oct 19 17:54, Marco Atzeri wrote: > > On 19/10/2015 17:45, Corinna Vinschen wrote: > > >On Sep 26 11:43, Marco Atzeri wrote: > > >>Jari, > > >>any specific reason why there is only a 64 bit version ? > > >> > > >>As it seems just a python script, it should work on both arch correct ? > > > > > >Did this get resolved? > > > > > > > > >Corinna > > > > the 32bit version is still missing Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpLZkwUbAUoD.pgp Description: PGP signature
Re: cfget-0.18-1 32bit (uploaded soon)
On 05/11/2015 10:26, Marco Atzeri wrote: On 05/11/2015 10:54, Jari Aalto wrote: On 2015-11-05 10:26, Corinna Vinschen wrote: | On Oct 20 12:23, Corinna Vinschen wrote: | > Jari, ping? | > | > On Oct 19 17:54, Marco Atzeri wrote: | > > On 19/10/2015 17:45, Corinna Vinschen wrote: | > > >On Sep 26 11:43, Marco Atzeri wrote: | > > >>Jari, | > > >>any specific reason why there is only a 64 bit version ? | > > >> | > > >>As it seems just a python script, it should work on both arch correct ? | > > > | > > >Did this get resolved? | > > > | > > > | > > >Corinna | > > | > > the 32bit version is still missing Hm, must have slipped through my eyes. I'll take care of it ASAP. Jari aewm++ 64 bit also, please. You uploaded only aewm++-goodies $ grep aewm++ pkg_arch.txt aewm++ 32 bitJari Aalto aewm++-goodies Both Jari Aalto I noticed that aewm++ 1.1.2-2 packages for both x86 and x86_64 have been sitting in Jari's upload area on sourceware for a while. I'm not sure if that's because he hasn't marked them ready, or some kind of upset bug is happening.
Re: Segmentation fault before main
On 05/11/2015 09:49, Csaba Raduly wrote: On Wed, Nov 4, 2015 at 10:42 PM, Marco Atzeri wrote: For the archive, I found the culprit in the test code. Using "%lu" to print int is not a good idea on cygwin 64 bit. That's why we have -Wformat=2 Csaba Thanks for the suggestion, but it seems not effective for this type of issue. I rebuilt the original code and no additional warning arises. -- 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: cfget-0.18-1 32bit (uploaded soon)
On 05/11/2015 14:12, Jon Turney wrote: On 05/11/2015 10:26, Marco Atzeri wrote: Jari aewm++ 64 bit also, please. You uploaded only aewm++-goodies $ grep aewm++ pkg_arch.txt aewm++ 32 bitJari Aalto aewm++-goodies Both Jari Aalto I noticed that aewm++ 1.1.2-2 packages for both x86 and x86_64 have been sitting in Jari's upload area on sourceware for a while. I'm not sure if that's because he hasn't marked them ready, or some kind of upset bug is happening. The first I suppose, he was a bit busy at that time. Regards Marco
Re: cfget-0.18-1 32bit (uploaded soon)
On 05/11/2015 10:54, Jari Aalto wrote: On 2015-11-05 10:26, Corinna Vinschen wrote: | On Oct 20 12:23, Corinna Vinschen wrote: | > Jari, ping? | > | > On Oct 19 17:54, Marco Atzeri wrote: | > > On 19/10/2015 17:45, Corinna Vinschen wrote: | > > >On Sep 26 11:43, Marco Atzeri wrote: | > > >>Jari, | > > >>any specific reason why there is only a 64 bit version ? | > > >> | > > >>As it seems just a python script, it should work on both arch correct ? | > > > | > > >Did this get resolved? | > > > | > > > | > > >Corinna | > > | > > the 32bit version is still missing Hm, must have slipped through my eyes. I'll take care of it ASAP. Jari aewm++ 64 bit also, please. You uploaded only aewm++-goodies $ grep aewm++ pkg_arch.txt aewm++ 32 bitJari Aalto aewm++-goodies Both Jari Aalto Regards Marco
[newlib-cygwin/cygwin-acl] Fake volume serial number on filesystems not providing it
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=26f787261112cc8fe3e445222fba1b81786e9ced commit 26f787261112cc8fe3e445222fba1b81786e9ced Author: Corinna VinschenDate: Thu Nov 5 18:34:34 2015 +0100 Fake volume serial number on filesystems not providing it * mount.cc (fs_info::update): Fake a serial number on filesystems not providing one. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/ChangeLog | 5 + winsup/cygwin/mount.cc | 30 -- 2 files changed, 33 insertions(+), 2 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index 911262a..24a795c 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,5 +1,10 @@ 2015-11-05 Corinna Vinschen + * mount.cc (fs_info::update): Fake a serial number on filesystems not + providing one. + +2015-11-05 Corinna Vinschen + * fcntl.cc (fcntl64): Don't lock fd table when performing locking. * flock.cc (flock): Ditto. (lockf): Ditto. diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc index 66e8571..c04805b 100644 --- a/winsup/cygwin/mount.cc +++ b/winsup/cygwin/mount.cc @@ -182,8 +182,7 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol) clear (); /* Always caseinsensitive. We really just need access to the drive. */ - InitializeObjectAttributes (, upath, OBJ_CASE_INSENSITIVE, NULL, - NULL); + InitializeObjectAttributes (, upath, OBJ_CASE_INSENSITIVE, NULL, NULL); if (in_vol) vol = in_vol; else @@ -232,6 +231,33 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol) uint32_t hash = 0; if (NT_SUCCESS (status)) { + /* If the FS doesn't return a valid serial number (PrlSF is a candidate), +create reproducible serial number from path. We need this to create +a unique per-drive/share hash. */ + if (ffvi_buf.ffvi.VolumeSerialNumber == 0) + { + UNICODE_STRING path_prefix; + WCHAR *p; + + if (upath->Buffer[5] == L':' && upath->Buffer[6] == L'\\') + p = upath->Buffer + 6; + else + { + /* We're expecting an UNC path. Move p to the backslash after +"\??\UNC\server\share" or the trailing NUL. */ + p = upath->Buffer + 7; /* Skip "\??\UNC" */ + int bs_cnt = 0; + + while (*++p) + if (*p == L'\\') + if (++bs_cnt > 1) + break; + } + RtlInitCountedUnicodeString (_prefix, upath->Buffer, + (p - upath->Buffer) * sizeof (WCHAR)); + ffvi_buf.ffvi.VolumeSerialNumber = hash_path_name ((ino_t) 0, +_prefix); + } fs_info *fsi = fsi_cache.search (_buf.ffvi, hash); if (fsi) {
[newlib-cygwin] Avoid deadlock in flock(2)
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=41299df081a0a7edc646caf84d208145624a1d37 commit 41299df081a0a7edc646caf84d208145624a1d37 Author: Corinna VinschenDate: Thu Nov 5 18:31:36 2015 +0100 Avoid deadlock in flock(2) * fcntl.cc (fcntl64): Don't lock fd table when performing locking. * flock.cc (flock): Ditto. (lockf): Ditto. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/ChangeLog | 6 ++ winsup/cygwin/fcntl.cc | 6 -- winsup/cygwin/flock.cc | 6 +++--- winsup/cygwin/release/2.3.0 | 3 +++ 4 files changed, 16 insertions(+), 5 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index 456bcd1..73b8237 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,5 +1,11 @@ 2015-11-05 Corinna Vinschen + * fcntl.cc (fcntl64): Don't lock fd table when performing locking. + * flock.cc (flock): Ditto. + (lockf): Ditto. + +2015-11-05 Corinna Vinschen + * sigproc.cc (pending_signals::clear): Yet another fix to fix the fix. Actually iterate over the list of pending signals even if there's a signal which doesn't have to be cleared. Other than that, revert loop diff --git a/winsup/cygwin/fcntl.cc b/winsup/cygwin/fcntl.cc index babb064..cb97f68 100644 --- a/winsup/cygwin/fcntl.cc +++ b/winsup/cygwin/fcntl.cc @@ -1,7 +1,7 @@ /* fcntl.cc: fcntl syscall Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2005, 2008, 2009, - 2010, 2011, 2012, 2013, 2014 Red Hat, Inc. + 2010, 2011, 2012, 2013, 2014, 2015 Red Hat, Inc. This file is part of Cygwin. @@ -32,7 +32,9 @@ fcntl64 (int fd, int cmd, ...) { debug_printf ("fcntl(%d, %d, ...)", fd, cmd); - cygheap_fdget cfd (fd, true); + + /* Don't lock the fd table when performing locking calls. */ + cygheap_fdget cfd (fd, cmd < F_GETLK || cmd > F_SETLKW); if (cfd < 0) __leave; diff --git a/winsup/cygwin/flock.cc b/winsup/cygwin/flock.cc index f26a76a..0ac5548 100644 --- a/winsup/cygwin/flock.cc +++ b/winsup/cygwin/flock.cc @@ -1,6 +1,6 @@ /* flock.cc. NT specific implementation of advisory file locking. - Copyright 2003, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Red Hat, Inc. + Copyright 2003, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Red Hat, Inc. This file is part of Cygwin. @@ -1773,7 +1773,7 @@ flock (int fd, int operation) __try { - cygheap_fdget cfd (fd, true); + cygheap_fdget cfd (fd); if (cfd < 0) __leave; @@ -1817,7 +1817,7 @@ lockf (int filedes, int function, off_t size) __try { - cygheap_fdget cfd (filedes, true); + cygheap_fdget cfd (filedes); if (cfd < 0) __leave; diff --git a/winsup/cygwin/release/2.3.0 b/winsup/cygwin/release/2.3.0 index 0ec7d88..737 100644 --- a/winsup/cygwin/release/2.3.0 +++ b/winsup/cygwin/release/2.3.0 @@ -65,3 +65,6 @@ Bug Fixes - Workaround a bug in Windows 10 NLS handling. Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00547.html + +- Avoid unnecessry locking and thus a potential deadlock in flock(2). + Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00095.html
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.6
On Nov 5 18:55, Corinna Vinschen wrote: > On Nov 5 10:24, Corinna Vinschen wrote: > > On Nov 4 22:25, Achim Gratz wrote: > > > Achim Gratz writes: > > > > Just confirmed this on another system. If I kill the child, then the > > > > parent resumes and finishes the test loop alright and it can be > > > > interrupted again from the shell. The hang happens after the first test > > > > succeeds in both the parent and child. > > > > > > I have just managed to kill the parent (returning the shell prompt) and > > > have the child complete the test loop output to the terminal. So I > > > guess the communication ping-pong is somehow buggered up so that pipes > > > start blocking. > > > > Staring into the latest version of my new function to remove pending > > signals, after having some *more* coffee, it seems pretty clear I > > screwed this up nicely. > > > > What I was missing all the time was to iterate over the list of pending > > signals if there's a pending signal which doesn't have to be cleared. > > This case was just missing. Duh! I guess I didn't really cover myself > > in glory here... > > > > I applied yet another patch and uploaded a new developer snapshot > > (this time *with* the ACL changes) to https://cygwin.com/snapshots/ > > > > Can you please give it a try ASAP? > > For the records, I got a testcase from Achim to reproduce the issue > which, incidentally, is still present in that snapshot. It turned out > that the problem Achim was reporting has nothing to do with the new code > clearing pending signals. It was a completely different bug, which just > showed another behaviour due to the signal change. > > In fact what happened was a deadlock when parent and child process > were industriously trying to lock a file using flock(2). This must > have been present for a long time, in fact. > > I (hopefully) fixed the issue and uploaded yet another developer > snapshot to https://cygwin.com/snapshots/ (with ACL changes again). Hang on for a while, I forgot to push the changes upstream before creating the snapshot. Try in half an hour or so. Sorry, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgphQ4Q7oErI5.pgp Description: PGP signature
Re: Compile test ncurses program to run independent of cygwin?
Greetings, Daniel Goldman! > # Found /usr/x86_64-pc-cygwin/sys-root/usr/lib/libncurses.a > # Will this let me compile for dos window? Apparently not. > $ i686-pc-mingw32-gcc -I /usr/x86_64-pc-cygwin/sys-root/usr/include/ > ncurses.c -L /usr/x86_64-pc-cygwin/sys-root/usr/lib/ -lncurses > ... undefined reference to `initscr' > ... more "undefined reference" error messages > > My questions: > 1) Did I make a compile-line syntax error? Is there a variation of the > i686-pc-mingw32-gcc command line so I can use cygwin to compile > ncurses.c to run in dos window, independent of cygwin? I'm no expert, but my first answer would be "yes". You shouldn't use cross-compilers directly, rather, use appropriate GCC switches to specify host and target subsystems. > 2) If not, to compile ncurses.c to run in dos window, independent of > cygwin, do I have to set up the ncurses library myself? > I tried to get an answer from the docs, it seems unclear. -- With best regards, Andrey Repin Thursday, November 5, 2015 20:29:01 Sorry for my terrible english... -- 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
[newlib-cygwin/cygwin-acl] Avoid deadlock in flock(2)
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ed3f30cf74640c4ee5a2c0f8d837eabdc51dbc76 commit ed3f30cf74640c4ee5a2c0f8d837eabdc51dbc76 Author: Corinna VinschenDate: Thu Nov 5 18:31:36 2015 +0100 Avoid deadlock in flock(2) * fcntl.cc (fcntl64): Don't lock fd table when performing locking. * flock.cc (flock): Ditto. (lockf): Ditto. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/ChangeLog | 6 ++ winsup/cygwin/fcntl.cc | 6 -- winsup/cygwin/flock.cc | 6 +++--- winsup/cygwin/release/2.3.0 | 3 +++ 4 files changed, 16 insertions(+), 5 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index a3f7cac..911262a 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,5 +1,11 @@ 2015-11-05 Corinna Vinschen + * fcntl.cc (fcntl64): Don't lock fd table when performing locking. + * flock.cc (flock): Ditto. + (lockf): Ditto. + +2015-11-05 Corinna Vinschen + * sigproc.cc (pending_signals::clear): Yet another fix to fix the fix. Actually iterate over the list of pending signals even if there's a signal which doesn't have to be cleared. Other than that, revert loop diff --git a/winsup/cygwin/fcntl.cc b/winsup/cygwin/fcntl.cc index babb064..cb97f68 100644 --- a/winsup/cygwin/fcntl.cc +++ b/winsup/cygwin/fcntl.cc @@ -1,7 +1,7 @@ /* fcntl.cc: fcntl syscall Copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2005, 2008, 2009, - 2010, 2011, 2012, 2013, 2014 Red Hat, Inc. + 2010, 2011, 2012, 2013, 2014, 2015 Red Hat, Inc. This file is part of Cygwin. @@ -32,7 +32,9 @@ fcntl64 (int fd, int cmd, ...) { debug_printf ("fcntl(%d, %d, ...)", fd, cmd); - cygheap_fdget cfd (fd, true); + + /* Don't lock the fd table when performing locking calls. */ + cygheap_fdget cfd (fd, cmd < F_GETLK || cmd > F_SETLKW); if (cfd < 0) __leave; diff --git a/winsup/cygwin/flock.cc b/winsup/cygwin/flock.cc index f26a76a..0ac5548 100644 --- a/winsup/cygwin/flock.cc +++ b/winsup/cygwin/flock.cc @@ -1,6 +1,6 @@ /* flock.cc. NT specific implementation of advisory file locking. - Copyright 2003, 2008, 2009, 2010, 2011, 2012, 2013, 2014 Red Hat, Inc. + Copyright 2003, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015 Red Hat, Inc. This file is part of Cygwin. @@ -1773,7 +1773,7 @@ flock (int fd, int operation) __try { - cygheap_fdget cfd (fd, true); + cygheap_fdget cfd (fd); if (cfd < 0) __leave; @@ -1817,7 +1817,7 @@ lockf (int filedes, int function, off_t size) __try { - cygheap_fdget cfd (filedes, true); + cygheap_fdget cfd (filedes); if (cfd < 0) __leave; diff --git a/winsup/cygwin/release/2.3.0 b/winsup/cygwin/release/2.3.0 index ceb7790..487ad3e 100644 --- a/winsup/cygwin/release/2.3.0 +++ b/winsup/cygwin/release/2.3.0 @@ -68,3 +68,6 @@ Bug Fixes - Workaround a bug in Windows 10 NLS handling. Addresses: https://cygwin.com/ml/cygwin/2015-10/msg00547.html + +- Avoid unnecessry locking and thus a potential deadlock in flock(2). + Addresses: https://cygwin.com/ml/cygwin/2015-11/msg00095.html
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.6
On Nov 5 10:24, Corinna Vinschen wrote: > On Nov 4 22:25, Achim Gratz wrote: > > Achim Gratz writes: > > > Just confirmed this on another system. If I kill the child, then the > > > parent resumes and finishes the test loop alright and it can be > > > interrupted again from the shell. The hang happens after the first test > > > succeeds in both the parent and child. > > > > I have just managed to kill the parent (returning the shell prompt) and > > have the child complete the test loop output to the terminal. So I > > guess the communication ping-pong is somehow buggered up so that pipes > > start blocking. > > Staring into the latest version of my new function to remove pending > signals, after having some *more* coffee, it seems pretty clear I > screwed this up nicely. > > What I was missing all the time was to iterate over the list of pending > signals if there's a pending signal which doesn't have to be cleared. > This case was just missing. Duh! I guess I didn't really cover myself > in glory here... > > I applied yet another patch and uploaded a new developer snapshot > (this time *with* the ACL changes) to https://cygwin.com/snapshots/ > > Can you please give it a try ASAP? For the records, I got a testcase from Achim to reproduce the issue which, incidentally, is still present in that snapshot. It turned out that the problem Achim was reporting has nothing to do with the new code clearing pending signals. It was a completely different bug, which just showed another behaviour due to the signal change. In fact what happened was a deadlock when parent and child process were industriously trying to lock a file using flock(2). This must have been present for a long time, in fact. I (hopefully) fixed the issue and uploaded yet another developer snapshot to https://cygwin.com/snapshots/ (with ACL changes again). New test release follows soon. Achim, thanks for the report and the testcase. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgp_OroeY7xYH.pgp Description: PGP signature
[newlib-cygwin] Fake volume serial number on filesystems not providing it
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=c56dc181f907f8ab6dbcd40b9baf66f80d88468a commit c56dc181f907f8ab6dbcd40b9baf66f80d88468a Author: Corinna VinschenDate: Thu Nov 5 18:34:34 2015 +0100 Fake volume serial number on filesystems not providing it * mount.cc (fs_info::update): Fake a serial number on filesystems not providing one. Signed-off-by: Corinna Vinschen Diff: --- winsup/cygwin/ChangeLog | 5 + winsup/cygwin/mount.cc | 30 -- 2 files changed, 33 insertions(+), 2 deletions(-) diff --git a/winsup/cygwin/ChangeLog b/winsup/cygwin/ChangeLog index 73b8237..1be11ee 100644 --- a/winsup/cygwin/ChangeLog +++ b/winsup/cygwin/ChangeLog @@ -1,5 +1,10 @@ 2015-11-05 Corinna Vinschen + * mount.cc (fs_info::update): Fake a serial number on filesystems not + providing one. + +2015-11-05 Corinna Vinschen + * fcntl.cc (fcntl64): Don't lock fd table when performing locking. * flock.cc (flock): Ditto. (lockf): Ditto. diff --git a/winsup/cygwin/mount.cc b/winsup/cygwin/mount.cc index 66e8571..c04805b 100644 --- a/winsup/cygwin/mount.cc +++ b/winsup/cygwin/mount.cc @@ -182,8 +182,7 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol) clear (); /* Always caseinsensitive. We really just need access to the drive. */ - InitializeObjectAttributes (, upath, OBJ_CASE_INSENSITIVE, NULL, - NULL); + InitializeObjectAttributes (, upath, OBJ_CASE_INSENSITIVE, NULL, NULL); if (in_vol) vol = in_vol; else @@ -232,6 +231,33 @@ fs_info::update (PUNICODE_STRING upath, HANDLE in_vol) uint32_t hash = 0; if (NT_SUCCESS (status)) { + /* If the FS doesn't return a valid serial number (PrlSF is a candidate), +create reproducible serial number from path. We need this to create +a unique per-drive/share hash. */ + if (ffvi_buf.ffvi.VolumeSerialNumber == 0) + { + UNICODE_STRING path_prefix; + WCHAR *p; + + if (upath->Buffer[5] == L':' && upath->Buffer[6] == L'\\') + p = upath->Buffer + 6; + else + { + /* We're expecting an UNC path. Move p to the backslash after +"\??\UNC\server\share" or the trailing NUL. */ + p = upath->Buffer + 7; /* Skip "\??\UNC" */ + int bs_cnt = 0; + + while (*++p) + if (*p == L'\\') + if (++bs_cnt > 1) + break; + } + RtlInitCountedUnicodeString (_prefix, upath->Buffer, + (p - upath->Buffer) * sizeof (WCHAR)); + ffvi_buf.ffvi.VolumeSerialNumber = hash_path_name ((ino_t) 0, +_prefix); + } fs_info *fsi = fsi_cache.search (_buf.ffvi, hash); if (fsi) {
Re: Compile test ncurses program to run independent of cygwin?
On Nov 5 20:30, Andrey Repin wrote: > Greetings, Daniel Goldman! > > > # Found /usr/x86_64-pc-cygwin/sys-root/usr/lib/libncurses.a > > # Will this let me compile for dos window? Apparently not. > > $ i686-pc-mingw32-gcc \ So you're building for 32 bit mingw > > -I /usr/x86_64-pc-cygwin/sys-root/usr/include/ Pointing the compiler to header files for a Cygwin build, which is a *different* target (i686 vs. x86_64 *and* mingw vs. cygwin)... > > ncurses.c -L /usr/x86_64-pc-cygwin/sys-root/usr/lib/ -lncurses same here > > ... undefined reference to `initscr' > > ... more "undefined reference" error messages ...and that's logical result. Along the same lines you could try to link powerpc-linux ncurses against arm-freebsd binary. That just won't work. What you need is a i686-mingw ncurses. Have a look around on the net or try to build your own. However, it will probably not work correctly in a Cygwin pseudo tty due to lack of the Cygwin compat layer implementing them. > > > > > My questions: > > > 1) Did I make a compile-line syntax error? Is there a variation of the > > i686-pc-mingw32-gcc command line so I can use cygwin to compile > > ncurses.c to run in dos window, independent of cygwin? > > I'm no expert, but my first answer would be "yes". > You shouldn't use cross-compilers directly, rather, use appropriate GCC > switches to specify host and target subsystems. Nope, use cross compilers. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpxXCkiu83mq.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.6
Corinna Vinschen writes: >> I (hopefully) fixed the issue and uploaded yet another developer >> snapshot to https://cygwin.com/snapshots/ (with ACL changes again). > > Hang on for a while, I forgot to push the changes upstream before > creating the snapshot. Try in half an hour or so. CYGWIN_NT-6.3-WOW Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:01 i686 Cygwin CYGWIN_NT-6.3 Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:02 x86_64 Cygwin These two snapshots fix the failures (which as you said had just moved from semi-random to predictable with the changes in signal handling). Thanks! Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- 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: Compile test ncurses program to run independent of cygwin?
On Thu, 2015-11-05 at 18:48 +0100, Corinna Vinschen wrote: > What you need is a i686-mingw ncurses. Have a look around on the net or > try to build your own. There are for both i686- and x86_64-w64-mingw32 in Ports. > However, it will probably not work correctly in a Cygwin pseudo tty due > to lack of the Cygwin compat layer implementing them. It most definitely does not work correctly in mintty, but it works quite well in a cmd window. -- 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: Cygport uploading different files to different arch directorys for noarch packages
On 11/5/2015 5:12 PM, Andrew Schulman wrote: I'm seeing what seems to be some very odd behaviour from Cygport when uploading noarch packages: Cygport uploads all the packages for the 64-bit architecture, but only the main and source packages for 32-bit architecture. Thanks for the troubleshooting and detailed report. This is just weird. The best I can tell is that it's a bug in lftp. For some reason the lftp mirror command isn't working properly within the cygport environment, half of the time. ?? So I suggest you call this problem to the attention of the lftp maintainer. Uh... oops. FWIW, I've seen occasional failures of the lftp mirror command outside of cygport. But I never had a reproducible case. Usually I could just repeat the mirror command and it would work the second time. Ken
Re: [ANNOUNCEMENT] New package: fzf
On Thu, Nov 5, 2015 at 3:15 PM, Adam Dinwoodie wrote: > fzf is a command-line fuzzy finder. These packages provide the core > fuzzy finder, as well as a Vim plugin, Bash and Z shell key bindings and > completion scripts, and Fish key bindings. Serious question, how does this compare to "Z"? http://github.com/rupa/z -- 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.3.0-0.6
I am not sure if this DLL snapshot (cygwin1-20151105-dll) is supposed to fix stuff like this, but I think I remember something about ordering ACL's? Anyway I have this 'bin' directory in my home which shows up with 'Administratörer' (Swedish for Administrators) as the owner. I had hoped it would should me as the owner. Some output: jabba@Luap ~ $ ls -ld bin drwxrwx---+ 1 Administratörer jabba 0 Oct 29 15:42 bin jabba@Luap ~ $ getfacl bin # file: bin # owner: Administratörer # group: jabba user::rwx group::rwx group:SYSTEM:rwx mask:rwx other:--- default:user::rwx default:group::rwx default:group:SYSTEM:rwx default:group:jabba:rwx default:mask:rwx default:other:--- jabba@Luap ~ $ icacls bin bin NT instans\SYSTEM:(OI)(CI)(F) BUILTIN\Administrat▒rer:(OI)(CI)(F) LUAP\jabba:(OI)(CI)(F) Successfully processed 1 files; Failed processing 0 files This is on Windows 10 Pro x64. On 5 November 2015 at 20:18, Achim Gratz <strom...@nexgo.de> wrote: > Corinna Vinschen writes: >>> I (hopefully) fixed the issue and uploaded yet another developer >>> snapshot to https://cygwin.com/snapshots/ (with ACL changes again). >> >> Hang on for a while, I forgot to push the changes upstream before >> creating the snapshot. Try in half an hour or so. > > CYGWIN_NT-6.3-WOW Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:01 i686 Cygwin > CYGWIN_NT-6.3 Cygwin 2.3.0(0.291/5/3) 2015-11-05 18:02 x86_64 Cygwin > > These two snapshots fix the failures (which as you said had just moved > from semi-random to predictable with the changes in signal handling). > Thanks! > > > Regards, > Achim. > -- > +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ > > Factory and User Sound Singles for Waldorf Q+, Q and microQ: > http://Synth.Stromeko.net/Downloads.html#WaldorfSounds > > -- > 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 > -- 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: Cygport uploading different files to different arch directorys for noarch packages
> I'm seeing what seems to be some very odd behaviour from Cygport when > uploading noarch packages: Cygport uploads all the packages for the > 64-bit architecture, but only the main and source packages for 32-bit > architecture. Thanks for the troubleshooting and detailed report. This is just weird. The best I can tell is that it's a bug in lftp. For some reason the lftp mirror command isn't working properly within the cygport environment, half of the time. ?? So I suggest you call this problem to the attention of the lftp maintainer. Uh... oops.
Re: xterm 320-1 won't start with XTerm*faceName set in .Xresources
On 11/2/2015 4:23 PM, Yaakov Selkowitz wrote: Perhaps you are missing your preferred font. What had you specified for XTerm*faceName? BitStream Vera Sans Mono Is there something that I can do to produce more debug information out of xterm as it launches. Honestly, I'm not even sure how to get a list of available fonts. -- 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
New package: fzf
The following pacages have been added to the Cygwin distribution: - fzf - fzf-bash - fzf-bash-completion - fzf-zsh - fzf-zsh-completion - fzf-fish - fzf-vim fzf is a command-line fuzzy finder. These packages provide the core fuzzy finder, as well as a Vim plugin, Bash and Z shell key bindings and completion scripts, and Fish key bindings. See https://github.com/junegunn/fzf for more information.
[ANNOUNCEMENT] New package: fzf
The following pacages have been added to the Cygwin distribution: - fzf - fzf-bash - fzf-bash-completion - fzf-zsh - fzf-zsh-completion - fzf-fish - fzf-vim fzf is a command-line fuzzy finder. These packages provide the core fuzzy finder, as well as a Vim plugin, Bash and Z shell key bindings and completion scripts, and Fish key bindings. See https://github.com/junegunn/fzf for more information. -- 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
Cygport uploading different files to different arch directorys for noarch packages
I'm seeing what seems to be some very odd behaviour from Cygport when uploading noarch packages: Cygport uploads all the packages for the 64-bit architecture, but only the main and source packages for 32-bit architecture. Mostly I'm looking to know whether other people experience the same behaviour when using Cygport to upload noarch packages -- the behaviour I'm seeing is entirely reproducible on my system. I've done some digging, and I'm utterly baffled, so I'm going to post this here in case anyone else has any cunning theories; arguably this is into the realms of an lftp/cygport/bash bug, so if folk want me to take it to the main list, I'm happy to do that too. Here's what I'm seeing (having commented out the !ready line in pkg_upload.cygpart to allow testing, although I've checked both ways and that doesn't make a difference): $ cygport fzf.cygport upload >>> Uploading fzf-0.10.8-1.noarch >>> Running lftp sftp://cygwin:@cygwin.com cd ok, cwd=/x86/release Transferring file `fzf-0.10.8-1-src.tar.xz' Transferring file `fzf-0.10.8-1.tar.xz' Transferring file `setup.hint' cd ok, cwd=/x86_64/release New: 3 files, 0 symlinks 116628 bytes transferred in 1 second (84.4 KiB/s) Transferring file `fzf-0.10.8-1-src.tar.xz' Transferring file `fzf-0.10.8-1.tar.xz' Transferring file `setup.hint' Making directory `fzf-bash' Transferring file `fzf-bash/fzf-bash-0.10.8-1.tar.xz' Transferring file `fzf-bash/setup.hint' Making directory `fzf-bash-completion' Transferring file `fzf-bash-completion/fzf-bash-completion-0.10.8-1.tar.xz' Transferring file `fzf-bash-completion/setup.hint' Making directory `fzf-fish' Transferring file `fzf-fish/fzf-fish-0.10.8-1.tar.xz' Transferring file `fzf-fish/setup.hint' Making directory `fzf-vim' Transferring file `fzf-vim/fzf-vim-0.10.8-1.tar.xz' Transferring file `fzf-vim/setup.hint' Making directory `fzf-zsh' Transferring file `fzf-zsh/fzf-zsh-0.10.8-1.tar.xz' Transferring file `fzf-zsh/setup.hint' Making directory `fzf-zsh-completion' Transferring file `fzf-zsh-completion/fzf-zsh-completion-0.10.8-1.tar.xz' Transferring file `fzf-zsh-completion/setup.hint' Total: 6 directories, 15 files, 0 symlinks New: 15 files, 0 symlinks 129612 bytes transferred in 8 seconds (15.3 KiB/s) Upload complete. Note only three files were uploaded before the cd to /x86_64/release. I've looked at the cygport code, and I can see no way this could happen -- the code for uploading to x86 and x86_64 is the same code on a loop -- and yet it's happening reliably for me. By way of further testing, I hacked the Cygport code to dump the lftp commands to file, then emulated the lftp command from my Bash shell: $ cat upload_commands set cmd:fail-exit on set cmd:interactive on set net:max-retries 1 open sftp://cygwin:@cygwin.com cd /x86/release rm -f fzf/!ready || echo -n mirror -v -eR fzf cd /x86_64/release rm -f fzf/!ready || echo -n mirror -v -eR fzf $ lftp -f <(cat upload_commands) cd ok, cwd=/x86/release Making directory `fzf-bash' Transferring file `fzf-bash/fzf-bash-0.10.8-1.tar.xz' Transferring file `fzf-bash/setup.hint' Making directory `fzf-bash-completion' Transferring file `fzf-bash-completion/fzf-bash-completion-0.10.8-1.tar.xz' Transferring file `fzf-bash-completion/setup.hint' Making directory `fzf-fish' Transferring file `fzf-fish/fzf-fish-0.10.8-1.tar.xz' Transferring file `fzf-fish/setup.hint' Making directory `fzf-vim' Transferring file `fzf-vim/fzf-vim-0.10.8-1.tar.xz' Transferring file `fzf-vim/setup.hint' Making directory `fzf-zsh' Transferring file `fzf-zsh/fzf-zsh-0.10.8-1.tar.xz' Transferring file `fzf-zsh/setup.hint' Making directory `fzf-zsh-completion' Transferring file `fzf-zsh-completion/fzf-zsh-completion-0.10.8-1.tar.xz' Transferring file `fzf-zsh-completion/setup.hint' Total: 6 directories, 15 files, 0 symlinks New: 12 files, 0 symlinks 12984 bytes transferred in 7 seconds (1.8 KiB/s) cd ok, cwd=/x86_64/release Total: 6 directories, 15 files, 0 symlinks So everything works fine there: it correctly finishes the x86 upload I started in Cygport and does nothing for the already completed x86_64 upload. For further testing, I hacked Cygport up some more to write that upload_commands file out, then immediately read from it using the same command as above. This produced the bugged behaviour again, which implies it's definitely something about the Cygport environment that's causing the odd behaviour. As I say, I'm utterly baffled by this. For now I'll just upload the remaining x86 files manually, but I'd love to know what's going on.
Re: cfget-0.18-1 32bit (aewm* uploaded soon)
On 2015-11-05 14:22, Marco Atzeri wrote: | On 05/11/2015 14:12, Jon Turney wrote: | >On 05/11/2015 10:26, Marco Atzeri wrote: | >> | >>aewm++ 64 bit also, please. | >> | >>You uploaded only aewm++-goodies | >> | >>$ grep aewm++ pkg_arch.txt | >>aewm++ 32 bitJari Aalto | >>aewm++-goodies Both Jari Aalto | > | >I noticed that aewm++ 1.1.2-2 packages for both x86 and x86_64 have been | >sitting in Jari's upload area on sourceware for a while. | > | >I'm not sure if that's because he hasn't marked them ready, or some kind | >of upset bug is happening. | > | | The first I suppose, he was a bit busy at that time. I'll check those ASAP, Thanks, Jari
Re: [ITP] fzf 0.10.8
On 5 November 2015 at 10:05, Corinna Vinschen wrote: > Hi Adam, > > On Nov 2 10:37, Adam Dinwoodie wrote: >> Folks, >> >> I'm looking at packaging fzf[0], which is a "fuzzy finder" with shell >> and Vim integration. It's not nearly so fast on Cygwin as it is on my >> Linux and Mac boxes, sadly (I suspect a combination of it needing to >> fall back to Ruby due to Cygwin's lack of Go compiler, plus the standard >> Cygwin overheads), but it's still pretty fast, and I've been using it >> myself on Cygwin for a couple of weeks, and on my CentOS box for a fair >> bit longer. >> >> The upstream package has an MIT license and is already included by Arch >> Linux[1]. The main setup.hint is below, and it's ready to upload as >> soon as it's declared GTG; I've uploaded the entire package tree[2] and >> Cygport packaging code[3] for reference, too. >> >> [0]: https://github.com/junegunn/fzf >> [1]: https://aur.archlinux.org/packages/fzf/ >> [2]: https://tastycake.net/~adam/cygwin/fzf/ >> [3]: https://github.com/me-and/Cygwin-fzf/ > > GTG. Thanks! I'm just in the process of working out how to deal with a bash-completion source ordering issue, then I'll upload and announce. (In case you're interested: bash-completion sources files in its directory apparently in alphabetical order. This means fzf's bash-completion script gets sourced before some things it's supposed to override; I'm trying to find a slightly less fragile way to avoid that than just renaming the script as "-fzf" or similar...) Adam
Re: xfig-3.2.5c-2.x86_64 crashes on save as or export on windows 10
On 02/11/2015 06:17, Yaakov Selkowitz wrote: On Sat, 2015-10-31 at 16:47 +, Jon Turney wrote: On 29/10/2015 19:11, Hans-Georg Scherneck wrote: it crashes on x_86 (i.e. 32 bit version) too, even after re-installing the xorg-server packages. xfig won't show the export window before it crashes. What else can I do? Any step-by-step procedure with xorg-server renewal? Is there an issue with Athena widgets? I'd suggest, as an alternative workaround, with the current server: ln -s /usr/share/X11/fonts/75dpi /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:pri=40 I'm not sure we should recommend this. I agree. It's just a workaround, which also serves to confirm that the issue is font related, until the steps you outline can be taken. It seems that xfig requires the font '*-times-medium-r-normal--16-*' for that dialog, but that is not one of the sizes provided by xorg/font/adobe-*dpi (14 and 17 are the nearest), so we have to allow this font to be scaled (or provide a scalable font which also matches that XLFD) Fedora carries the following patch (among others): http://pkgs.fedoraproject.org/cgit/xfig.git/tree/xfig-3.2.5-urwfonts.patch We currently provide the URW fonts in ghostscript-fonts-std. That should be rebuilt to add a symlink in /etc/X11/fontpath.d, and xfig rebuilt with that patch (and possibly others from that set as well). -- Jon TURNEY Volunteer Cygwin/X X Server 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