Re: cfget-0.18-1 32bit (uploaded soon)

[Jari Aalto]

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

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=eeef72702692fca52610634da32b56241e8083f3

commit eeef72702692fca52610634da32b56241e8083f3
Author: Corinna Vinschen 
Date:   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

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=d735b30eefe2d35d0d2a2d66ac12004662fc1525

commit d735b30eefe2d35d0d2a2d66ac12004662fc1525
Author: Corinna Vinschen 
Date:   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

[Corinna Vinschen]

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

[Csaba Raduly]

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?

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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 ?

[Corinna Vinschen]

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)

[Jon Turney]

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

[Marco Atzeri]

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)

[Marco Atzeri]

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)

[Marco Atzeri]

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

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=26f787261112cc8fe3e445222fba1b81786e9ced

commit 26f787261112cc8fe3e445222fba1b81786e9ced
Author: Corinna Vinschen 
Date:   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)

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=41299df081a0a7edc646caf84d208145624a1d37

commit 41299df081a0a7edc646caf84d208145624a1d37
Author: Corinna Vinschen 
Date:   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

[Corinna Vinschen]

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?

[Andrey Repin]

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)

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=ed3f30cf74640c4ee5a2c0f8d837eabdc51dbc76

commit ed3f30cf74640c4ee5a2c0f8d837eabdc51dbc76
Author: Corinna Vinschen 
Date:   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

[Corinna Vinschen]

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

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=c56dc181f907f8ab6dbcd40b9baf66f80d88468a

commit c56dc181f907f8ab6dbcd40b9baf66f80d88468a
Author: Corinna Vinschen 
Date:   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?

[Corinna Vinschen]

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

[Achim Gratz]

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?

[Yaakov Selkowitz]

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

[Ken Brown]

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

[Steven Penny]

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

[Jan Bruun Andersen]

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

[Andrew Schulman]

> 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

[Brian Neu]

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

[Adam Dinwoodie]

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

[Adam Dinwoodie]

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

[Adam Dinwoodie]

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)

[Jari Aalto]

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

[Adam Dinwoodie]

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

[Jon Turney]

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