Re: git alias for "status" not working

2017-05-15 Thread David Dombrowsky
FYI: after the latest cygwin update to git v 2.12.3, this is no longer
a problem.

Setting an alias like "st = status -uno" works as expected.  Many
thanks to the maintainer.

On Mon, May 15, 2017 at 8:54 AM, David Dombrowsky
<6thstreetra...@gmail.com> wrote:
> FYI: after the latest cygwin update to git v 2.12.3, this is no longer
> a problem.
>
> Setting an alias like "st = status -uno" works as expected.  Many
> thanks to the maintainer.
>
> On Mon, Mar 27, 2017 at 3:59 PM, David Dombrowsky
> <6thstreetra...@gmail.com> wrote:
>> On Mon, Mar 27, 2017 at 9:24 AM, cyg Simple  wrote:
 st is also a prefix of "stash".  Maybe it does not like aliases
 that are prefixes of other commands?
>>
>> Without the entry in the config file, `git st` results in the expected
>>
>> git: 'st' is not a git command. See 'git --help'.
>>
>> It's possible there's a string parse error, but using an alias of
>> "stx" doesn't work either.  Nor does 'xyzzy'.
>>
>>> Also check the line endings of the config file.  Make sure they are UNIX
>>> line endings instead of Windows.
>>
>> Yes, they are unix line endings.  I normally use a symlink for
>> ~/.gitconfig, and I also tried with with and without the symlink.
>> Same result.
>>
>> --
>> David Dombrowsky, Senior Software Engineer
>> email: da...@6thstreetradio.org
>> https://www.linkedin.com/in/david-dombrowsky-94334415
>> http://6thstreetradio.org/
>
>
>
> --
> David Dombrowsky, Senior Software Engineer
> email: da...@6thstreetradio.org
> Cell: 518-374-3204
> https://www.linkedin.com/in/david-dombrowsky-94334415
> http://6thstreetradio.org/



-- 
David Dombrowsky, Senior Software Engineer
email: da...@6thstreetradio.org
Cell: 518-374-3204
https://www.linkedin.com/in/david-dombrowsky-94334415
http://6thstreetradio.org/

--
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



PHP zip extension broken with libzip

2017-05-15 Thread Joni Eskelinen
This has been a long standing bug, but i just recently sought out the cause.

The following snippets fails in currently packaged php:
open("test.zip", ZipArchive::CREATE | ZipArchive::OVERWRITE);
$zip->addFromString("foo.txt", "foo");
$zip->close();

With a warning:
Warning: ZipArchive::close(): Renaming temporary file failed: Illegal
seek in /tmp/zip.php on line 5

It appears that the problem lies in libzip. If the extension is built
without `--with-libzip=/usr`, the error doesn't emerge. When libzip is
not available, extension is built with a bundled zip implementation.

To test, navigating into `ext/zip` in php source.

Test with bundled library:
phpize && LDFLAGS='-lpcre' ./configure && make test

Test with libzip:
phpize && LDFLAGS='-lpcre' ./configure --with-libzip=/usr && make test

Latter produces 19 failed tests.

--
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: problem with paste-from-clipboard

2017-05-15 Thread Eric Blake
On 05/12/2017 05:37 PM, Steven Penny wrote:
> On Fri, 12 May 2017 20:50:26, Ladislav DANKO wrote:
>> I have problem with "paste-from-clipboard" in cygwin. In ~/.inputrc
>> file I
>> have just this line: "\e[2~": paste-from-clipboard
> 
> You have left out a critical piece of information here, you have not
> mentioned
> *what* you are trying to paste. Note that current readline is broken
> when using
> code page 65001:
> 
> http://cygwin.com/ml/cygwin/2017-04/msg00176.html
> 
> Current maintainer Eric Blake is refusing to rollback, and refusing to
> fix the
> problem, instead pushing the responsibility of patching this on the user
> base:
> 
> http://cygwin.com/ml/cygwin/2017-04/msg00161.html

You're making it sound like I'm actively trying to hurt you. Rather,
it's a case where it is a problem that doesn't affect me personally, and
I have limited enough spare time as it is, so I haven't yet tried to
reproduce things to see if I can isolate what behavior changed.

I would love help solving the issue.  Absent that help, you'll just have
to wait for me to have time.


-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: setup release candidate - please test

2017-05-15 Thread Ian Lambert via cygwin


On Sun, 5/14/17, Jon Turney <> wrote:

 Subject: Re: setup release candidate - please test
 To: "The Cygwin Mailing List" 
 Cc: "Ian Lambert" <>
 Date: Sunday, May 14, 2017, 9:53 AM
 
 On 08/05/2017 17:19, Ian Lambert
 via cygwin wrote:
 > On May 8, 2017
 7:06:31 AM EDT, Jon Turney  wrote:
 >
 > As reported before, _64 still can't
 make it through my location's
 >
 apparently unusual proxy, although cygwin's wget given
 proxy and
 > password still can. Install
 with local mirror option works ok still.
 > Windows 7 Enterprise SP1.
 
 It's unsurprising that
 2.878 didn't fix this, as it didn't contain any 
 changes intended to.
 
 However, since I had the code open in my
 editor, I took look at this...
 
 Please test.
 
 https://cygwin.com/setup/setup-2.878-3-gf41e2e.x86.exe
 https://cygwin.com/setup/setup-2.878-3-gf41e2e.x86_64.exe
 
 [1] 
 
https://sourceware.org/git/gitweb.cgi?p=cygwin-setup.git;a=shortlog;h=refs/heads/ntlm-proxy-debugging
= = = = 

I didn't expect it to work, but didn't hurt to try it. Thanks for looking at it.

Behavior is still the same - no prompt for a password, and fails to get setup 
(popup message).
I tried both use IE settings, and Use HTTP/FTP proxy with proxy name and port.
Logs are as follows:

$ cat setup.log.full-ie
2017/05/15 11:17:03 Starting cygwin install, version 2.878-3-gf41e2e
2017/05/15 11:17:03 User has NO backup/restore rights
2017/05/15 11:17:03 Current Directory: 
E:\cygwin64-mirror\ftwin\mirrors.kernel.org\sourceware\cygwin
2017/05/15 11:17:03 Could not open Service control manager
2017/05/15 11:17:06 source: network install
2017/05/15 11:17:06 root: E:\cygwin64-3 user
2017/05/15 11:17:07 Selected local directory: 
E:\cygwin64-mirror\ftwin\mirrors.kernel.org\sourceware\cygwin
2017/05/15 11:17:11 net: IE5
Cached mirror list unavailable
Fetching URL: http://cygwin.com/mirrors.lst
2017/05/15 11:17:12 HTTP status 403 fetching http://cygwin.com/mirrors.lst
Defaulting to empty mirror list
2017/05/15 11:17:13 site: http://mirrors.kernel.org/sourceware/cygwin/
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.xz.sig
2017/05/15 11:17:13 HTTP status 403 fetching 
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.xz.sig
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.xz
2017/05/15 11:17:13 HTTP status 403 fetching 
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.xz
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2.sig
2017/05/15 11:17:13 HTTP status 403 fetching 
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2.sig
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2
2017/05/15 11:17:13 HTTP status 403 fetching 
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini.sig
2017/05/15 11:17:13 HTTP status 403 fetching 
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini.sig
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini
2017/05/15 11:17:13 HTTP status 403 fetching 
http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini
2017/05/15 11:17:13 mbox note: Unable to get setup from 

INSTALLED.DB version 3
2017/05/15 11:17:19 Ending cygwin install



$ cat setup.log.full-proxy
2017/05/15 11:11:17 Starting cygwin install, version 2.878-3-gf41e2e
2017/05/15 11:11:17 User has NO backup/restore rights
2017/05/15 11:11:17 Current Directory: 
E:\cygwin64-mirror\ftwin\mirrors.kernel.org\sourceware\cygwin
2017/05/15 11:11:17 Could not open Service control manager
2017/05/15 11:11:23 source: network install
2017/05/15 11:11:25 root: E:\cygwin64-3 user
2017/05/15 11:11:26 Selected local directory: 
E:\cygwin64-mirror\ftwin\mirrors.kernel.org\sourceware\cygwin
2017/05/15 11:11:41 net: Proxy
Cached mirror list unavailable
Fetching URL: http://cygwin.com/mirrors.lst
Defaulting to empty mirror list
2017/05/15 11:13:38 net: Proxy
2017/05/15 11:13:39 site: http://mirrors.kernel.org/sourceware/cygwin/
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.xz.sig
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.xz
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2.sig
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.bz2
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini.sig
Fetching URL: http://mirrors.kernel.org/sourceware/cygwin/x86_64/setup.ini
2017/05/15 11:13:39 mbox note: Unable to get setup from 

INSTALLED.DB version 3
2017/05/15 11:13:44 Ending cygwin install



--
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: Making a package obsolete

2017-05-15 Thread Jon Turney

On 15/05/2017 15:30, Ken Brown wrote:

On 5/14/2017 1:38 PM, Jon Turney wrote:

On 13/05/2017 20:44, Ken Brown wrote:

On 5/13/2017 7:12 AM, Jon Turney wrote:

On 12/05/2017 22:02, Ken Brown wrote:

I have a package that is going to become obsolete, but its contents
will
be distributed among several other packages.  So I can't handle
this by
defining OBSOLETES in any one .cygport file.  Is there a standard
way to
deal with this using cygport, or should I just create the necessary
tarballs and .hint file manually?


I think the best way to do that is to bump your package revision,
change
it's category to _obsolete, make it's contents empty, and make it
depend
on the packages which are replacing it.


Yes, that was my first thought.  But there's no longer a source file for
the obsolete package[1], and cygport complains that SRC_URI must be
defined.  Maybe cygport should be patched to allow an empty SRC_URI when
the category is _obsolete.  Or do you see another way around this?


I would think you can use the same SRC_URI as previously, but set
PKG_CONTENTS="" and PKG_IGNORE="*" ?


You're right, I can do something like that.  I was being overly pedantic
in wanting SRC_URI to be "accurate".  Sorry for the noise.


You can always make an empty tarball called 
texlive-collection-htmlxml-20170515.tar.xz or whatever, and use that for 
SRC_URI.



--
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: setup release candidate - please test

2017-05-15 Thread Jon Turney

On 15/05/2017 16:29, Ian Lambert via cygwin wrote:


On Sun, 5/14/17, Jon Turney <> wrote:

[...]


 However, since I had the code open in my
 editor, I took look at this...

 Please test.

 https://cygwin.com/setup/setup-2.878-3-gf41e2e.x86.exe
 https://cygwin.com/setup/setup-2.878-3-gf41e2e.x86_64.exe

 [1]
 
https://sourceware.org/git/gitweb.cgi?p=cygwin-setup.git;a=shortlog;h=refs/heads/ntlm-proxy-debugging
= = = =

I didn't expect it to work, but didn't hurt to try it. Thanks for looking at it.


Thanks for testing.


Behavior is still the same - no prompt for a password, and fails to get setup 
(popup message).
I tried both use IE settings, and Use HTTP/FTP proxy with proxy name and port.
Logs are as follows:

$ cat setup.log.full-ie

[...]

Fetching URL: http://cygwin.com/mirrors.lst
2017/05/15 11:17:12 HTTP status 403 fetching http://cygwin.com/mirrors.lst


I think that "403 forbidden" means that this request is prohibited by 
the configuration of the proxy, so really you need to contact whoever 
administers it.


Since curl/wget works to fetch the same URLs through that proxy, it 
might be that the user-agent is disallowed, possibly you could test this 
by attempting trying with --user-agent="Cygwin Setup"?



--
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: Making a package obsolete

2017-05-15 Thread Ken Brown

On 5/15/2017 11:56 AM, Jon Turney wrote:

On 15/05/2017 15:30, Ken Brown wrote:

On 5/14/2017 1:38 PM, Jon Turney wrote:

On 13/05/2017 20:44, Ken Brown wrote:

On 5/13/2017 7:12 AM, Jon Turney wrote:

On 12/05/2017 22:02, Ken Brown wrote:

I have a package that is going to become obsolete, but its contents
will
be distributed among several other packages.  So I can't handle
this by
defining OBSOLETES in any one .cygport file.  Is there a standard
way to
deal with this using cygport, or should I just create the necessary
tarballs and .hint file manually?


I think the best way to do that is to bump your package revision,
change
it's category to _obsolete, make it's contents empty, and make it
depend
on the packages which are replacing it.


Yes, that was my first thought.  But there's no longer a source file
for
the obsolete package[1], and cygport complains that SRC_URI must be
defined.  Maybe cygport should be patched to allow an empty SRC_URI
when
the category is _obsolete.  Or do you see another way around this?


I would think you can use the same SRC_URI as previously, but set
PKG_CONTENTS="" and PKG_IGNORE="*" ?


You're right, I can do something like that.  I was being overly pedantic
in wanting SRC_URI to be "accurate".  Sorry for the noise.


You can always make an empty tarball called
texlive-collection-htmlxml-20170515.tar.xz or whatever, and use that for
SRC_URI.


Good idea, thanks.  But it turns out that there's another problem: 
cygport won't actually create an empty binary tarball in this situation.


The relevant code is in pkg_pkg.cygpart around lines 149--163, 
especially this part:


elif (( pkg_count == 1 ))
then
pkg_contents="*"
else
pkg_contents=

We get here if PKG_CONTENTS is unset or empty.  (There's actually no 
test to see if it's set but empty.)  In the situation under discussion, 
this results in pkg_contents="*" followed by a tar error.


Yaakov, shouldn't the user be allowed to explicitly set PKG_CONTENTS 
empty and have cygport honor that, at least for obsolete packages?


Ken

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: problem with paste-from-clipboard

2017-05-15 Thread Steven Penny

On Sat, 13 May 2017 15:11:00, Eric Blake wrote:

You're making it sound like I'm actively trying to hurt you. Rather,
it's a case where it is a problem that doesn't affect me personally, and
I have limited enough spare time as it is, so I haven't yet tried to
reproduce things to see if I can isolate what behavior changed.

I would love help solving the issue.  Absent that help, you'll just have
to wait for me to have time.


But I have helped - in the very post of mine you just quoted, I put this link:

http://cygwin.com/ml/cygwin/2017-04/msg00176.html

that post of mine contains not only the commit in question, but even potentially
the file in question and even possibly the section of the file in question. You
never even responded to that post.


--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3

2017-05-15 Thread Eric Blake
On 04/14/2017 11:33 PM, Steven Penny wrote:
> On Thu, 13 Apr 2017 13:48:04, Eric Blake wrote:

Sorry for my delay in noticing this.

>> Is it still a problem with pselect, where rebuilding with the same
>> configuration as 7.0.1-2 fixes things? I'm really not sure how to even
>> go about debugging this one, and it's not my highest priority at the
>> moment (I've got coreutils 8.27 to build for cygwin, and autoconf 2.70
>> to release upstream).  So any help is welcome.
> 
> Ok. I have not gone through the whole commit, as it is huge:
> 
> http://cygwin.com/ml/cygwin/2017-01/msg00204.html
> 
> but I did find something. Using:
> 
>git checkout readline-7.0-alpha~1
> 
> for the last good commit and:
> 
>git checkout readline-7.0-alpha
> 
> for the first bad commit, I found that the change to the "rl_insert"
> function in
> "text.c" breaks pasting and Alt codes with "chcp.com 65001". Can you
> work with
> this?
> 
> http://git.savannah.gnu.org/cgit/readline.git/tree/text.c?h=readline-7.0-alpha#n891

It's code I'm not familiar with, so I'm adding upstream bug-bash in the
hopes that Chet might have an answer to why this code was changed, and
if he is aware that the change may have broken things on Cygwin.


> 
> 
> --- a/text.c
> +++ b/text.c
> @@ -71,6 +71,8 @@ static int _rl_char_search_callback
> PARAMS((_rl_callback_generic_arg *));
>rl_insert_text.  Text blocks larger than this are divided. */
> #define TEXT_COUNT_MAX1024
> 
> +int _rl_optimize_typeahead = 1;/* rl_insert tries to read typeahead */
> +
> /*  */
> /**/
> /*Insert and Delete*/
> @@ -890,8 +892,42 @@ int
> rl_insert (count, c)
>  int count, c;
> {
> -  return (rl_insert_mode == RL_IM_INSERT ? _rl_insert_char (count, c)
> -   : _rl_overwrite_char (count, c));
> +  int r, n, x;
> +
> +  r = (rl_insert_mode == RL_IM_INSERT) ? _rl_insert_char (count, c) :
> _rl_overwrite_char (count, c);
> +
> +  /* XXX -- attempt to batch-insert pending input that maps to
> self-insert */
> +  x = 0;
> +  n = (unsigned short)-2;
> +  while (_rl_optimize_typeahead &&
> + (RL_ISSTATE (RL_STATE_INPUTPENDING|RL_STATE_MACROINPUT) == 0) &&
> + _rl_pushed_input_available () == 0 &&
> + _rl_input_queued (0) &&
> + (n = rl_read_key ()) > 0 &&
> + _rl_keymap[(unsigned char)n].type == ISFUNC &&
> + _rl_keymap[(unsigned char)n].function == rl_insert)


Looking at JUST this line, I am also reminded that Cygwin dll handling
is weird.  For example, when building bash for Cygwin, I have to add the
following (currently-downstream-only, but maybe I should propose it
upstream) patch to bashline.c:

+#if __CYGWIN__
+#  ifdef __x86_64__
+#define IMP(x) __imp_##x
+#  else
+#define IMP(x) _imp__##x
+#  endif
+#else
+#  define IMP(x) x
+#endif

@@ -498,11 +513,12 @@ initialize_readline ()
   kseq[0] = CTRL('J');
   kseq[1] = '\0';
   func = rl_function_of_keyseq (kseq, emacs_meta_keymap, (int *)NULL);
-  if (func == rl_vi_editing_mode)
+  extern rl_command_func_t *IMP(rl_vi_editing_mode);
+  if (func == rl_vi_editing_mode || func == IMP(rl_vi_editing_mode))
 rl_unbind_key_in_map (CTRL('J'), emacs_meta_keymap);

and similar.  That is, anywhere that bash refers to an exported readline
function pointer, checking for equality on Cygwin works only if I check
both the original function name AND the __imp_rl_* function name, based
on how importing functions works with dlls (perhaps that's a gcc bug
that gcc doesn't automatically perform BOTH checks under the hood when
looking for C function pointer compatibility, but I'm not enough of a
compiler expert to know WHY it is needed, just that it solved issues
that didn't work otherwise).  I wonder if the comparison against
rl_insert is incomplete, and needs to also check against __imp_rl_insert?


> +{
> +  r = (rl_insert_mode == RL_IM_INSERT) ? _rl_insert_char (1, n) :
> _rl_overwrite_char (1, n);
> +  /* _rl_insert_char keeps its own set of pending characters to
> compose a
> + complete multibyte character, and only returns 1 if it sees a
> character
> + that's part of a multibyte character but too short to complete
> one.  We
> + can try to read another character in the hopes that we will get the
> + next one or just punt.  Right now we try to read another character.
> + We don't want to call rl_insert_next if _rl_insert_char has already
> + stored the character in the pending_bytes array because that will
> + result in doubled input. */
> +  n = (unsigned short)-2;
> +  x++;/* count of bytes of typeahead read, currently unused */
> +  if (r == 1)/* read partial multibyte character */
> +continue;
> +  if (rl_done || r != 0)
> +break;
> +}
> +
> +  if (n != (unsigned short)-2)/* -2 = sentinel value for having
> inserted N */
> +r = rl_execute_next (n);

Re: problem with paste-from-clipboard

2017-05-15 Thread Eric Blake
On 05/15/2017 12:09 PM, Steven Penny wrote:
> On Sat, 13 May 2017 15:11:00, Eric Blake wrote:
>> You're making it sound like I'm actively trying to hurt you. Rather,
>> it's a case where it is a problem that doesn't affect me personally, and
>> I have limited enough spare time as it is, so I haven't yet tried to
>> reproduce things to see if I can isolate what behavior changed.
>>
>> I would love help solving the issue.  Absent that help, you'll just have
>> to wait for me to have time.
> 
> But I have helped - in the very post of mine you just quoted, I put this
> link:
> 
> http://cygwin.com/ml/cygwin/2017-04/msg00176.html
> 
> that post of mine contains not only the commit in question, but even
> potentially
> the file in question and even possibly the section of the file in
> question. You
> never even responded to that post.

Probably because I did not even see the post at the time. (While I try
to keep up with Cygwin email, I also get hundreds of other mails per
day, and when Cygwin is limited to my free time, sometimes things slip
through the cracks).  In life, and therefore in open source, it is often
that the squeaky wheel gets the grease; if something isn't getting the
attention you think it deserves, it is not bad to ping the thread to
bring it back to the forefront.

Thanks for the ping. I've now replied to that thread to ask upstream
bash for help in deciphering if Chet, who wrote the code, might be aware
of why it is breaking things.

That said, I still hope to get a closer look at it myself when I have a
nice chunk of time; but the trick is still getting that nice chunk of time.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature


Re: [ANNOUNCEMENT] Updated: libreadline7-7.0.3-3

2017-05-15 Thread Chet Ramey
On 5/15/17 2:19 PM, Eric Blake wrote:

>>git checkout readline-7.0-alpha
>>
>> for the first bad commit, I found that the change to the "rl_insert"
>> function in
>> "text.c" breaks pasting and Alt codes with "chcp.com 65001". Can you
>> work with
>> this?
>>
>> http://git.savannah.gnu.org/cgit/readline.git/tree/text.c?h=readline-7.0-alpha#n891
> 
> It's code I'm not familiar with, so I'm adding upstream bug-bash in the
> hopes that Chet might have an answer to why this code was changed, and
> if he is aware that the change may have broken things on Cygwin.

It was inspired by the discussion starting with

http://lists.gnu.org/archive/html/bug-readline/2015-05/msg7.html

The idea is to optimize pasted input using the assumption that it will be
mostly composed of characters that map to self-insert, and you can batch
read those characters and perform one display update.

The way to test whether or not a character will be inserted into the
editing buffer is to see whether or not it maps directly to self-insert.
If that's the problem, there will have to be a cygwin-specific fix; it
works elsewhere.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/



signature.asc
Description: OpenPGP digital signature


Re: setup release candidate - please test

2017-05-15 Thread Ian Lambert via cygwin


On Mon, 5/15/17, Jon Turney <> wrote:

 Subject: Re: setup release candidate - please test
 To: "The Cygwin Mailing List" 
 Cc: "Ian Lambert" <>
 Date: Monday, May 15, 2017, 12:12 PM
 
 On 15/05/2017 16:29, Ian Lambert
 via cygwin wrote:
 >
 
 > On Sun, 5/14/17, Jon Turney <>
 wrote:
 [...]
 
 I think that "403
 forbidden" means that this request is prohibited by 
 the configuration of the proxy, so really you
 need to contact whoever 
 administers it.
 
 Since curl/wget works to fetch
 the same URLs through that proxy, it 
 might
 be that the user-agent is disallowed, possibly you could
 test this 
 by attempting trying with
 --user-agent="Cygwin Setup"?

= = =

The proxy admins have no interest in helping with this. :)

Indeed, user-agent of Cygwin Setup is a problem:

$ wget --user-agent="Cygwin Setup" 
https://cygwin.com/setup/setup-2.878.x86_64.exe
--2017-05-15 16:33:25--  https://cygwin.com/setup/setup-2.878.x86_64.exe
Resolving our.glorious.proxy... pr.ox.yi.p
Connecting to our.glorious.proxy|pr.ox.yi.p|:port... connected.
Proxy tunneling failed: ForbiddenUnable to establish SSL connection.

$ wget  https://cygwin.com/setup/setup-2.878.x86_64.exe
--2017-05-15 16:33:40--  https://cygwin.com/setup/setup-2.878.x86_64.exe
Resolving our.glorious.proxy... pr.ox.yi.p
Connecting to our.glorious.proxy|pr.ox.yi.p|:port... connected.
Proxy request sent, awaiting response... 200 OK
Length: 907283 (886K) [application/octet-stream]
Saving to: ‘setup-2.878.x86_64.exe’

setup-2.878.x86_64.exe  
100%[>]
 886.02K   764KB/sin 1.2s

2017-05-15 16:33:41 (764 KB/s) - ‘setup-2.878.x86_64.exe’ saved [907283/907283]

--
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: setup release candidate - please test

2017-05-15 Thread Brian Inglis
On 2017-05-15 14:42, Ian Lambert via cygwin wrote:
> On Mon, 5/15/17, Jon Turney wrote:
>  On 15/05/2017 16:29, Ian Lambert via cygwin wrote:
>> On Sun, 5/14/17, Jon Turney wrote:
> I think that "403 forbidden" means that this request is prohibited
> by the configuration of the proxy, so really you need to contact 
> whoever administers it.
>  
> Since curl/wget works to fetch the same URLs through that proxy, it 
> might be that the user-agent is disallowed, possibly you could test
> this by attempting trying with --user-agent="Cygwin Setup"? 
> 
> The proxy admins have no interest in helping with this. :)
> 
> Indeed, user-agent of Cygwin Setup is a problem:
> 
> $ wget --user-agent="Cygwin Setup" 
> https://cygwin.com/setup/setup-2.878.x86_64.exe
> --2017-05-15 16:33:25--  https://cygwin.com/setup/setup-2.878.x86_64.exe
> Resolving our.glorious.proxy... pr.ox.yi.p
> Connecting to our.glorious.proxy|pr.ox.yi.p|:port... connected.
> Proxy tunneling failed: ForbiddenUnable to establish SSL connection.
> 
> $ wget  https://cygwin.com/setup/setup-2.878.x86_64.exe
> --2017-05-15 16:33:40--  https://cygwin.com/setup/setup-2.878.x86_64.exe
> Resolving our.glorious.proxy... pr.ox.yi.p
> Connecting to our.glorious.proxy|pr.ox.yi.p|:port... connected.
> Proxy request sent, awaiting response... 200 OK
> Length: 907283 (886K) [application/octet-stream]
> Saving to: ‘setup-2.878.x86_64.exe’
> 
> setup-2.878.x86_64.exe  
> 100%[>]
>  886.02K   764KB/sin 1.2s
> 
> 2017-05-15 16:33:41 (764 KB/s) - ‘setup-2.878.x86_64.exe’ saved 
> [907283/907283]

Does it work if you try user agent combos of
{Cygwin-Setup,CygwinSetup}/{2.878-3,2.878}?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: Request new buildbot-slave package (FAO Jon Turney)

2017-05-15 Thread Adam Dinwoodie
On 12 May 2017 at 17:00, Jon Turney wrote:
> On 10/05/17 19:01, Jon Turney wrote:
>>
>> On 10/05/2017 18:10, Adam Dinwoodie wrote:
>>>
>>> I see you're the maintainer of buildbot-slave. Would it be possible to
>>> get an updated version of this? The current version packaged for
>>> Cygwin, 0.8.12, was released in April 2015; the latest version, 0.9.6,
>>> was released April 2017.
>>
>>
>> Sure, I'll take a look at doing that.
>
>
> I just uploaded buildbot-worker 0.9.7-1 (note the change in package name).
>
> It's a bit awkward for me to upgrade to a compatible buildbot-master right
> now, so I haven't been able to test it much, so please let me know if there
> are any problems.

Fantastic, thank you!

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple



[ANNOUNCEMENT] Updated: lzip-1.19-1 and lziprecover-1.19-1 (x86/x86_64)

2017-05-15 Thread JonY
Version 1.19-1 of lzip and lziprecover has been uploaded for both 32bit
and 64bit Cygwin.

lzip is an alternative to the bzip2 compressor. lziprecover is
responsible for fixing corrupted lzip compressed files.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there. It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com  cygwin.com

If you need more information on unsubscribing, start reading here:

http://sourceware.org/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.





signature.asc
Description: OpenPGP digital signature


[ANNOUNCEMENT] Updated: orpie 1.5.2-3

2017-05-15 Thread Andrew Schulman
orpie 1.5.2-3 is now available in Cygwin. In this release, orpie has been
rebuilt against the shiny new libgsl19, leaving behind crufty old libgsl0, for
your premium calculating experience. That's it. I recommend that you upgrade.

Orpie is a fullscreen RPN calculator for the console.  Its operation is similar
to that of modern HP calculators, but data entry has been optimized for
efficiency on a PC keyboard.  Features include extensive scientific calculator
functionality, command completion, and a visible interactive stack.

Andrew E. Schulman


***


To update your installation, click on the "Install Cygwin now" link on
the http://cygwin.com/ web page.  This downloads setup.exe to your
system.  Then, run setup and answer all of the questions.

  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com

If you need more information on unsubscribing, start reading here: 

http://cygwin.com/lists.html#subscribe-unsubscribe

Please read *all* of the information on unsubscribing that is available
starting at this URL.

--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple