Searching full, portable Cygwin package for windows and NOT just the installer

[Ben via cygwin]

When I go to web page

http://cygwin.com/

then I can download CygWin from there (currently the file "setup-x86_64.exe").

Unfortunately this file is just an installer which retrieves in turn several 
other files from Internet and remote servers.

Since I have no overview what is downloaded from which server I distrust such 
installers in general.

I prefer full packages which contains everything needed and can be inspected in 
advance (e.g. by virus scanners) before
actual installation.

99,9% of all software is offered in such a way.

Why use Cygwin such a fishy distribution way?

Is there really no full package to download?

Thank you
Ben

--
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: Spurious pastes

[David Mathog]

On 02-Feb-2018 13:13, David Mathog wrote:

I seem to recall that before this if I highlighted a region in an
xterm window, then moved to another X11 application window, and center
clicked, it would paste the highlighted text.  However, if nothing was
highlighted in the last window, nothing would paste.  My memory may be
faulty on this issue though, as I never paid a lot of attention to it
before it started misbehaving.


That wasn't right, but cut/paste is slightly different between "on the 
console" and "over putty ssh tunnel with X11 Server on Windows".


On an XFCE4 ubuntu system console this is what happens:

1.  type "pwd" into an uxterm window
2.  highlight "pwd" on the line at the preceding prompt, center
click once at the current prompt.  "pwd" is pasted.
Press "enter".
3.  left click once on the still highlighted "pwd", now 2 lines up.
The highlight goes away.  Center click once at the prompt.
"pwd" is still pasted. Press "enter".
4.  With the left mouse button drag across any letter and back
to the original position.  So nothing is highlighted.  This can
be on any text anywhere in the window.  Center click
at the prompt.  Nothing is pasted - the paste buffer is now
empty.

So on the console it is possible to select "nothing".

On the X11 server ssh to the Ubuntu system and it is the same for the 
first 3 steps, but the 4th still pastes "pwd".  The rule seems to be 
"paste buffer can be replaced by anything selected, but not by a select 
operation which ends with nothing highlighted."


On the X11 server ssh to the Centos system, it behaves just like a 
similar connection to the Centos system.


The operations do the same thing when going between two uxterm windows 
on any of these tests.


Which is right?  Is "nothing" a valid thing to load into the paste 
buffer or no?


Is there a standard way to clear this buffer?

Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

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

Re: [PATCH v2 0/3] catgets APIs, gencat tool

[Yaakov Selkowitz]

On 2018-01-19 13:26, Yaakov Selkowitz wrote:
> On 2018-01-19 13:04, Corinna Vinschen wrote:
>> Are you going to provide a catgets deprecation package?
> 
> Yes.
 Done.

-- 
Yaakov



signature.asc
Description: OpenPGP digital signature

Spurious pastes

[David Mathog]

Greetings,

I do most of my work on remote CentOS machines from a Windows box using 
a putty ssh tunnel and Cygwin X Server (1.14.1-1).


In the last few days nedit on those remote machines has been doing 
spurious pastes. That is, whatever is currently in the X11 paste buffer 
(not the program's paste buffer) is ending up dropped into whatever file 
is being edited.  Unclear why they are landing where they do, I have not 
actually seen it happen, just found it when diff indicated these odd 
insertions.  My best guess is that these happen while I am scrolling 
over these regions.  Needless to say, this is really not a good thing.


There have been only two changes recently.

1.  I cleaned my mouse.
2.  yum on 1/27/18 automatically installed on those servers:
 xorg-x11-server-common-1.17.4-16.el6.centos.1.x86_64

To eliminate (1) the mouse was swapped with another one.  Too soon to 
know if that did anything.


Part, maybe the whole issue, seems to be a change in how the X11 paste 
buffer is working.


I seem to recall that before this if I highlighted a region in an xterm 
window, then moved to another X11 application window, and center 
clicked, it would paste the highlighted text.  However, if nothing was 
highlighted in the last window, nothing would paste.  My memory may be 
faulty on this issue though, as I never paid a lot of attention to it 
before it started misbehaving.


Now the paste buffer seems to remember forever the last thing that was 
loaded into it.  This is the X11 paste buffer, not the one in nedit.  
The latter can be cleared by clicking once in any document and doing 
copy.  However, that does not clear the X11 paste buffer, just the 
applications.


In order to minimize these spurious X11 window into nedit pastes I would 
like to be able to clear the X11 paste buffer.  How would one do so?  I 
mean, other than shutting down and restarting the X11 server!


Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

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

Re: setup 2.886 release candidate - please test

[Achim Gratz]

Jon Turney writes:
>> Do you have an idea yet why the last package gets orphaned (or did, if
>
> 'Yet'?  This is the first time I've heard of this!

Right you are.  I thought I had mentioned it already, but forgot since I
can't post from work.

> Is this regression?

Yes.

>> it's already fixed)?  I will need to remove my workaround of placing an
>> empty dummy at the end to try.
>
> I guess you are saying that the last package listed in setup.ini
> appears as orphaned, when you have a re-written setup.ini which only
> contains one version per package?

I've tested that again today.  The last package gets orphaned if there
is only a current section.  I believe that the last section is also not
processed, so in the standard Cygwin installation you'd not be able to
see the previous version of _update-info-dir.

> Which I can easily believe happens, due to the rather weird way that
> the data from a parser reduction is transferred into the package
> database.

All my packages only have a single (curr) version in the rewritten
setup.ini as I have different setup.ini files (or rather directories
they are in) for keeping older states of the installation around.  Some
of the processing seems to be associated with seeing the start of a new
package or a new section as I can make it process the last package
correctly if I either start a dummy package with absolutely no content
(just the "@ packagename" line) or a dummy section (either [prev] or
[test] works, again with no content).



Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITP] neomutt

[Jon Turney]

On 31/01/2018 19:21, Federico Kircheis wrote:

On 01/31/2018 06:55 PM, Jon Turney wrote:

On 30/01/2018 05:56, Federico Kircheis wrote:

On 01/28/2018 03:43 PM, Jon Turney wrote:

On 28/01/2018 11:38, Federico Kircheis wrote:

Name: Federico Kircheis
Package: neomutt


Done


Uploaded.


Please upload a x86 package as well.


I'm sorry, I uploaded it, too.

I thought that the previous upload would have been valid both for x64 
and x86.


I was unsure how to proceed, so I've downloaded a x86 version of cygwin, 
copied the cygport file in a separate directory, and so on.


This is probably the most straightforward way.


Is there a way to update the package for x64 and x86 at once?


You don't need to do this, since the process which receives the uploads 
can tolerate x86 and x86 arriving separately.



Without using ftp directly of course.


If you really want to ensure they are processed at once, I guess you'd 
have to use 'cygport stage' to upload the files for each arch, then 
manually upload !ready files (as described in [1])


But, I can't think of any reasons to bother doing that for a single package.

[1] https://cygwin.com/package-upload.html

Re: setup 2.886 release candidate - please test

[Jon Turney]

On 01/02/2018 20:21, Achim Gratz wrote:

Jon Turney writes:

A new setup release candidate is available at:

   https://cygwin.com/setup/setup-2.886.x86.exe(32 bit version)
   https://cygwin.com/setup/setup-2.886.x86_64.exe (64 bit version)


Locally compiled, but not well tested yet.


Changes compared to 2.885:
- Apply default problem solutions in unattended mode
- Make --include-source work correctly in unattended mode
- Allow parser to accept an empty depends: list (2.885 (only) will
report syntax errors when parsing setup.ini containing these, when the
corresponding change to calm is deployed)


Do you have an idea yet why the last package gets orphaned (or did, if


'Yet'?  This is the first time I've heard of this!

Is this regression?


it's already fixed)?  I will need to remove my workaround of placing an
empty dummy at the end to try.


I guess you are saying that the last package listed in setup.ini appears 
as orphaned, when you have a re-written setup.ini which only contains 
one version per package?


Which I can easily believe happens, due to the rather weird way that the 
data from a parser reduction is transferred into the package database.

Re: How to start Cygwin from outside Cygwin and pass a command to execute?

[Achim Gratz]

Ben via cygwin writes:
> Assume I want to call from Windows my CgyWin and pass a command to execute.

That depends a bit on what kind of environment that command expects, but
it could be as easy as invoking it with the full path.  If it needs a
fully set up an environment you need to start a shell (dash or maybe
bash), perhaps in login mode to source your profile.  Lastly if it needs
a tty you'll want to start all that from mintty.

As others have commented, quoting all these commands correctly so they
are intact at the various stages of expansion can be quite an exercise
to get right, so it will be easier if you can wrap these things into a
script that doesn't need any arguments (or at least none that would need
quoting).


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

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

Re: How to start Cygwin from outside Cygwin and pass a command to execute?

[Brian Inglis]

On 2018-02-02 01:31, Ben via cygwin wrote:
> Assume my CgyWin (on a windows 7) is currently NOT started.
> Assume I want to call from Windows my CgyWin and pass a command to execute.
> Afterwards CygWin should automatically be closed again.
> How can I achieve this?

Cygwin is a DLL providing Unix/POSIX facilities over the underlying Windows OS,
a collection of DLLs providing services using those facilities, and programs
using those services and facilities, following the Unix model of the OS
supporting libraries, services, and drivers, and managing hardware resources.
Cygwin is started when you run any program using those libraries, services, or
facilities.
Add the Cygwin bin directory to PATH in your User environment and you can run
Cygwin programs from the Win-R Run dialogue, any Windows shortcut, Scheduled
Task, Windows console shell: using Windows style exe paths with Unix command
parameters and Unix style file paths; or Cygwin terminal and shell using Unix
style commands.
Some users use Cygwin from the cmd shell, some from Powershell, others from
mintty or other terminals with bash, dash, or another Cygwin shell.

So just run the command from wherever you want; depending on what you want to
happen with the output, you may need a shell to redirect output, or a console
terminal to display output.

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

[ANNOUNCEMENT] Updated: Cygwin 2.10.0-1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin release 2.10.0-1


What's new:
---

- New open(2) flags O_TMPFILE and O_NOATIME.

- scanf/wscanf now handle the POSIX %m modifier.

- scanf now handles the %l[ conversion.

- Improved hostprogs compatibility for cross-compiling the Linux kernel.
  New headers: , .

- Built-in implementation of Stack Smashing Protection compiler feature.
  New APIs: __stack_chk_fail, __stack_chk_guard.

- Built-in implementation of _FORTIFY_SOURCE guards for functions in
  , , , , , ,
  , and .
  New APIs:  __chk_fail, __gets_chk, __memcpy_chk, __memmove_chk, __mempcpy_chk,
  __memset_chk, __snprintf_chk, __sprintf_chk, __stpcpy_chk, __stpncpy_chk,
  __strcat_chk, __strcpy_chk, __strncat_chk, __strncpy_chk, __vsnprintf_chk,
  __vsprintf_chk.

- Built-in implementation of POSIX.1-2001 message catalog support.
  New APIs: catclose, catgets, catopen.  New tool: gencat.

- New APIs: sigtimedwait, wmempcpy.


What changed:
-

- Standard headers no longer use macros to support K C.

- confstr(3) and getconf(1) accept LFS_CFLAGS, LFS_LDFLAGS, etc.

- The __always_inline and __nonnull macros in  are now
  compatible with glibc.

- Feature Test Macros improvements in , , ,
  , and .


Bug Fixes
-

- Fix a problem in unlink on NFS.
  Addresses: Shows up in GAWK testsuite test "testext"

- Fix errno setting bug in posix_fadvise and posix_fallocate.
  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q4/msg00026.html

- Fix two bugs in the limit of large numbers of sockets.
  Addresses: https://cygwin.com/ml/cygwin/2017-11/msg00052.html

- Fix a fork failure with private anonymous mmaps.
  Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00061.html

- Remove a call to fflush from ftell{o}, which may result in wrong offsets.
  Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html

- Fix file pointer computation after short writes on block devices.
  Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html


Have fun,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

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

Updated: Cygwin 2.10.0-1

[Corinna Vinschen]

Hi folks,


I uploaded a new Cygwin release 2.10.0-1


What's new:
---

- New open(2) flags O_TMPFILE and O_NOATIME.

- scanf/wscanf now handle the POSIX %m modifier.

- scanf now handles the %l[ conversion.

- Improved hostprogs compatibility for cross-compiling the Linux kernel.
  New headers: , .

- Built-in implementation of Stack Smashing Protection compiler feature.
  New APIs: __stack_chk_fail, __stack_chk_guard.

- Built-in implementation of _FORTIFY_SOURCE guards for functions in
  , , , , , ,
  , and .
  New APIs:  __chk_fail, __gets_chk, __memcpy_chk, __memmove_chk, __mempcpy_chk,
  __memset_chk, __snprintf_chk, __sprintf_chk, __stpcpy_chk, __stpncpy_chk,
  __strcat_chk, __strcpy_chk, __strncat_chk, __strncpy_chk, __vsnprintf_chk,
  __vsprintf_chk.

- Built-in implementation of POSIX.1-2001 message catalog support.
  New APIs: catclose, catgets, catopen.  New tool: gencat.

- New APIs: sigtimedwait, wmempcpy.


What changed:
-

- Standard headers no longer use macros to support K C.

- confstr(3) and getconf(1) accept LFS_CFLAGS, LFS_LDFLAGS, etc.

- The __always_inline and __nonnull macros in  are now
  compatible with glibc.

- Feature Test Macros improvements in , , ,
  , and .


Bug Fixes
-

- Fix a problem in unlink on NFS.
  Addresses: Shows up in GAWK testsuite test "testext"

- Fix errno setting bug in posix_fadvise and posix_fallocate.
  Addresses: https://cygwin.com/ml/cygwin-patches/2017-q4/msg00026.html

- Fix two bugs in the limit of large numbers of sockets.
  Addresses: https://cygwin.com/ml/cygwin/2017-11/msg00052.html

- Fix a fork failure with private anonymous mmaps.
  Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00061.html

- Remove a call to fflush from ftell{o}, which may result in wrong offsets.
  Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html

- Fix file pointer computation after short writes on block devices.
  Addresses: https://cygwin.com/ml/cygwin/2017-12/msg00151.html


Have fun,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat

[newlib-cygwin] Cygwin: bump version to 2.10.1

[Corinna Vinschen]

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

commit 623d3fdf6b27f5e0f2ec450f691999ad3b40404a
Author: Corinna Vinschen 
Date:   Fri Feb 2 15:32:28 2018 +0100

Cygwin: bump version to 2.10.1

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/include/cygwin/version.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index fa9137d..f08707e 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -11,7 +11,7 @@ details. */
changes to the DLL and is mainly informative in nature. */
 
 #define CYGWIN_VERSION_DLL_MAJOR 2010
-#define CYGWIN_VERSION_DLL_MINOR 0
+#define CYGWIN_VERSION_DLL_MINOR 1
 
 /* Major numbers before CYGWIN_VERSION_DLL_EPOCH are incompatible. */

[newlib-cygwin] Created tag cygwin-2_10_0-release

[Corinna Vinschen]

The signed tag 'cygwin-2_10_0-release' was created pointing to:

 4c73ad6... newlib: drop Cygwin license from sys/select.h

Tagger: Corinna Vinschen 
Date: Fri Feb 2 15:01:12 2018 +0100

ygwin 2.10.0 Release

Re: RPC clnt_create() adress already in use

[PAULUS, Raimund, TI-ABN]

Hi Mark,

it works. Maybe it's the best solution for the problem.

Greetings

Raimund


-Ursprüngliche Nachricht-
Von: cygwin-ow...@cygwin.com [mailto:cygwin-ow...@cygwin.com] Im Auftrag von 
Mark Geisert
Gesendet: Freitag, 2. Februar 2018 09:11
An: cygwin@cygwin.com
Betreff: Re: RPC clnt_create() adress already in use

Mark Geisert wrote:
> Corinna Vinschen wrote:
>> On Jan 31 00:15, Mark Geisert wrote:
>>> PAULUS, Raimund, TI-ABN wrote:
 Hi Mark,

 in my email 
 (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i described 2 
 approaches. I prefer  nr 1.
 Here the part of the source in bindresvport.c:
 [...]
> [...]
>>
>> I'm a bit puzzled here in terms of using your own bindresvport.  
>> Cygwin implements bindresvport{_sa} for quite some time, 2006 or earlier.
>
> Yeesh; I did not know that.  Thanks for pointing that out. So that 
> means there's another possible way to try solving the OP's issue: by 
> using Cygwin's
> bindresvport* in place of the one supplied with libtirpc.
>
> If we see the OP's issue with Cygwin's bindresvport*, I think it makes 
> more sense to patch libtirpc than to change Cygwin's bindresvport*.  
> The crux of OP's issue is that libtirpc's code expects to see 
> EADDRINUSE errors from bind() whereas on Cygwin they aren't often seen until 
> you connect().
>
> I'll look into using Cygwin's bindresvport() in the next day or two.

My testing shows that OP's original issue goes away when libtirpc is compiled 
to use Cygwin's bindresvport() directly rather than using its own version of 
that function.

Raimund, could you try this newest possible solution?  Before the first 
#include in bindresvport.c, add the line
 #ifndef __CYGWIN__
and at the end of the file, add the line
 #endif
Then rebuild your libtirpc and your test programs linking against it, then run 
your tests.  If this proves to solve your original problem then I'll submit a 
patch of libtirpc to the Cygwin package maintainer.

Thank you,

..mark


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

RE: How to start Cygwin from outside Cygwin and pass a command to execute?

[David Allsopp]

Ben via cygwin wrote:
> Assume my CgyWin (on a windows 7) is currently NOT started.
> 
> Assume I want to call from Windows my CgyWin and pass a command to 
> execute.
> 
> Afterwards CygWin should automatically be closed again.
> 
> How can I achieve this?

C:\cygwin\bin\bash.exe -c "command"

You will find that successfully navigating the Command Prompt, Cygwin's and 
"bash -c"'s escaping rules to be entertaining for advanced commands.

You can also achieve similar with mintty.exe -e (which will launch the terminal 
emulator, instead of using an existing console window, or opening a new one). 
Similar fun with escaping unusual commands.

See, for example, 
https://github.com/ocaml/opam/blob/43e4c778/appveyor_build.cmd#L93


David


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

How to start Cygwin from outside Cygwin and pass a command to execute?

[Ben via cygwin]

Assume my CgyWin (on a windows 7) is currently NOT started.

Assume I want to call from Windows my CgyWin and pass a command to execute.

Afterwards CygWin should automatically be closed again.

How can I achieve this?

Ben

--
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: RPC clnt_create() adress already in use

[Mark Geisert]

Mark Geisert wrote:

Corinna Vinschen wrote:

On Jan 31 00:15, Mark Geisert wrote:

PAULUS, Raimund, TI-ABN wrote:

Hi Mark,

in my email (https://sourceware.org/ml/cygwin/2017-12/msg00194.html) i
described 2 approaches. I prefer  nr 1.
Here the part of the source in bindresvport.c:
[...]

[...]


I'm a bit puzzled here in terms of using your own bindresvport.  Cygwin
implements bindresvport{_sa} for quite some time, 2006 or earlier.


Yeesh; I did not know that.  Thanks for pointing that out. So that means there's
another possible way to try solving the OP's issue: by using Cygwin's
bindresvport* in place of the one supplied with libtirpc.

If we see the OP's issue with Cygwin's bindresvport*, I think it makes more
sense to patch libtirpc than to change Cygwin's bindresvport*.  The crux of OP's
issue is that libtirpc's code expects to see EADDRINUSE errors from bind()
whereas on Cygwin they aren't often seen until you connect().

I'll look into using Cygwin's bindresvport() in the next day or two.


My testing shows that OP's original issue goes away when libtirpc is compiled to 
use Cygwin's bindresvport() directly rather than using its own version of that 
function.


Raimund, could you try this newest possible solution?  Before the first #include 
in bindresvport.c, add the line

#ifndef __CYGWIN__
and at the end of the file, add the line
#endif
Then rebuild your libtirpc and your test programs linking against it, then run 
your tests.  If this proves to solve your original problem then I'll submit a 
patch of libtirpc to the Cygwin package maintainer.


Thank you,

..mark


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