Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Vlado]

Hi.

One more sugestion: use -e test instead of -r, because Perl -r is not 
allways reliable in mixed Cygwin/Windows environment.


(Cygwin terminal)
$ perl -e "if( -r 
'Cygwin/http%3A%2F%2Fgd.tuwien.ac.at%2Fgnu%2Fcygwin%2F/x86/setup.ini'){print 
'readable'}else{print 'cant read'}"

cant read

$ head 'Cygwin/http%3A%2F%2Fgd.tuwien.ac.at%2Fgnu%2Fcygwin%2F/x86/setup.ini'
# This file is automatically generated.  If you edit it, your
# edits will be discarded next time the file is generated.
# See http://cygwin.com/setup.html for details.
#
release: cygwin
arch: x86
setup-timestamp: 1466876494
setup-version: 2.874

$ getfacl 
'Cygwin/http%3A%2F%2Fgd.tuwien.ac.at%2Fgnu%2Fcygwin%2F/x86/setup.ini'

# file: Cygwin/http%3A%2F%2Fgd.tuwien.ac.at%2Fgnu%2Fcygwin%2F/x86/setup.ini
# owner: POVB+User(1124)
# group: POVB+Group(513)
user::---
group::---
group:SYSTEM:rwx
group:Administrators:rwx
group:VLADOB+Own:rwx
mask:rwx
other:---

$ perl -e "if( -e 
'Cygwin/http%3A%2F%2Fgd.tuwien.ac.at%2Fgnu%2Fcygwin%2F/x86/setup.ini'){print 
'exists'}else{print 'doesnt exists'}"

exists

(Windows Command prompt)
Cygwin\http%3a%2f%2fgd.tuwien.ac.at%2fgnu%2fcygwin%2f> icacls x86\setup.ini
x86\setup.ini NT AUTHORITY\SYSTEM:(I)(F)
  BUILTIN\Administrators:(I)(F)
  VLADOB\Own:(I)(F)

Tail of sub find_setup_ini_file will be:
open my $uname, '-|', 'uname -m' or die "uname -m failed: $!\n";
my $plat = <$uname>;
chomp $plat;
close $uname;

my $setup_path = "$path/$mirror/$plat/setup.ini";
return $setup_path if -e $setup_path;

# If 32-bit Cygwin on 64-bit OS, the above doesn't works
$setup_path = "$path/$mirror/x86/setup.ini";
return $setup_path if -e $setup_path;

# Definitely not found
usage("could not find setup.ini");
}

This works for me.

Vlado

--
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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Vlado]

On 6.7.2016 7:17, Warren Young wrote:

if the mirror was used for both an x86 and x86_64 installation, it always uses 
the x86 setup.ini, regardless of the current architecture.

Good catch!  The script now uses the output of uname -m to select the mirror 
subdirectory.



Hi,

this is not allways right. I still use 32-bit Cygwin on 64-bit Windows.

$ uname -m
i686

$ ls 'Downloads/Cygwin/http%3A%2F%2Fgd.tuwien.ac.at%2Fgnu%2Fcygwin%2F/'
noarch  x86

Vlado

--
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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Warren Young]

On Jul 3, 2016, at 8:02 AM, Ken Brown wrote:
> 
> it doesn't take dependency loops into account

I’ve fixed that using your proposed “Dependency order” solution.  I haven’t 
analyzed the output, but it is a bit longer than the last time, so I assume it 
has saved me from dropping all packages in a loop.

If this is also found to be insufficient, I think I’d have to build the 
dependency graph from setup.ini and learn to walk it, rather than continue with 
this present linear algorithm.

> if the mirror was used for both an x86 and x86_64 installation, it always 
> uses the x86 setup.ini, regardless of the current architecture.

Good catch!  The script now uses the output of uname -m to select the mirror 
subdirectory.




find-cyg-roots
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Warren Young]

On Jul 5, 2016, at 6:11 AM, KARL BOTTS  wrote:
> 
> I have been using 32-bit Cygwin for at least 15
> years, and being without it throws me into a tizzy.

64-bit Cygwin installs in parallel to 32-bit Cygwin, not over the top of it.  
If your 64-bit adventure is a complete failure, your 32-bit installation will 
still be there.

> Are there any gotchas I should know about?

I answered that here:

  http://stackoverflow.com/q/18329233

> Maybe eventually we can get
> your work up on the Cygwin web site?

It’s already there:

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

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Ken Brown]

On 7/5/2016 9:59 AM, Ken Brown wrote:

On 7/3/2016 10:02 AM, Ken Brown wrote:



This script has a couple of problems.  First, it doesn't take dependency
loops into account.  For example, if package p requires q and q requires
p, then both will be marked as non-root.  Second, if the mirror was used
for both an x86 and x86_64 installation, it always uses the x86
setup.ini, regardless of the current architecture.


The second problem is easy to fix.  I think you can fix the first
problem by using the dependency order computed by setup and recorded in
/var/log/setup.log.full:

$ grep "Dependency order" /var/log/setup.log.full
Dependency order of packages: base-cygwin cygwin libdbus1_3 libiconv2
libintl8 libffi6 libpcre1 liblzma5 libgcc1 libstdc++6 terminfo...

You should only mark a package as a non-root if it is required by a
package that occurs later in the list.


Sorry, this isn't quite right, at least if your goal is to produce a 
minimal set of roots.  [It will, however, produce a set of roots that is 
not necessarily minimal.]  To get a minimal set you would have to find 
the strongly-connected components of the dependency graph.  [This is 
what is done internally by setup.exe in order to compute the dependency 
order.]  Then when a package is marked as a non-root, all packages in 
the same component should also be marked as non-root.


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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Ken Brown]

On 7/3/2016 10:02 AM, Ken Brown wrote:

On 7/1/2016 7:38 PM, Warren Young wrote:

On Jul 1, 2016, at 4:40 PM, Warren Young wrote:


I’ve written a script to do that automatically.


I’ve improved the script so that it no longer requires any
parameters.  It finds the last-used setup.ini file and extracts the
list of currently-installed packages, all on its own.


This script has a couple of problems.  First, it doesn't take dependency
loops into account.  For example, if package p requires q and q requires
p, then both will be marked as non-root.  Second, if the mirror was used
for both an x86 and x86_64 installation, it always uses the x86
setup.ini, regardless of the current architecture.


The second problem is easy to fix.  I think you can fix the first 
problem by using the dependency order computed by setup and recorded in 
/var/log/setup.log.full:


$ grep "Dependency order" /var/log/setup.log.full
Dependency order of packages: base-cygwin cygwin libdbus1_3 libiconv2 
libintl8 libffi6 libpcre1 liblzma5 libgcc1 libstdc++6 terminfo...


You should only mark a package as a non-root if it is required by a 
package that occurs later in the list.


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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Achim Gratz]

KARL BOTTS  usa.net> writes:
> I am just a little nervous.  I have been using 32-bit Cygwin for at least 15
> years, and being without it throws me into a tizzy.  (I barely know how to use
> WindowsExplorer.)  Are there any gotchas I should know about?

Here's another way to do it.

http://permalink.gmane.org/gmane.os.cygwin/154766


Regards,
Achim.


--
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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[KARL BOTTS]

Karl Botts>> I use Cygwin32 on Windows-64.

Warren Young> Then you’re artificially making rebase’s job harder.
> The list of 32-bit-only Cygwin packages is tiny these days, and you’ve
just
> rebuilt your Cygwin environment. With my new find-cyg-roots script, you
could
> rebuild your current 32-bit environment under Cygwin 64 quickly. 
> That should prevent the reoccurrence of the rebase problem.


Your recommendation makes total sense.  I will do it soon: not today, but
soon.

I am just a little nervous.  I have been using 32-bit Cygwin for at least 15
years, and being without it throws me into a tizzy.  (I barely know how to use
WindowsExplorer.)  Are there any gotchas I should know about?


Please keep us up to date with your valuable scripting efforts.  I have
checked your script, emails and the followups into revision control, for my
own purposes.  I'll let you know how it goes.  Maybe eventually we can get
your work up on the Cygwin web site?


---
Karl Botts, kdbo...@usa.net


--
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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Ken Brown]

On 7/1/2016 7:38 PM, Warren Young wrote:

On Jul 1, 2016, at 4:40 PM, Warren Young wrote:


I’ve written a script to do that automatically.


I’ve improved the script so that it no longer requires any parameters.  It 
finds the last-used setup.ini file and extracts the list of currently-installed 
packages, all on its own.


This script has a couple of problems.  First, it doesn't take dependency 
loops into account.  For example, if package p requires q and q requires 
p, then both will be marked as non-root.  Second, if the mirror was used 
for both an x86 and x86_64 installation, it always uses the x86 
setup.ini, regardless of the current architecture.


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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Warren Young]

On Jul 1, 2016, at 4:40 PM, Warren Young wrote:
> 
> I’ve written a script to do that automatically.

I’ve improved the script so that it no longer requires any parameters.  It 
finds the last-used setup.ini file and extracts the list of currently-installed 
packages, all on its own.

Thus, calling this script is now as simple as:

$ /path/to/setup*.exe -P $(/path/to/find-cyg-roots) ...




find-cyg-roots
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Warren Young]

On Jul 1, 2016, at 4:12 PM, KARL BOTTS  wrote:
> 
> I use Cygwin32 on Windows-64.

Then you’re artificially making rebase’s job harder.

The list of 32-bit-only Cygwin packages is tiny these days, and you’ve just 
rebuilt your Cygwin environment.  With my new find-cyg-roots script, you could 
rebuild your current 32-bit environment under Cygwin 64 quickly.  

That should prevent the reoccurrence of the rebase problem.

> Windows itself also
> uses lots of 32-bit components even under Win-64.  In fact, VS itself is
> a (very large) 32-bit app.

Both for legacy reasons, neither of which apply to Cygwin.

> 32-bit software runs so smoothly under an opsys running on
> Intel64, is one of the latter's best features.

64-bit software runs on 64-bit CPUs pretty well, too. :)

>> Because Satya Nadella has been in charge for only about two years now.
> 
> You think he's in charge?

Microsoft under Nadella feels a whole lot different than Microsoft under 
Ballmer to me.  Sure he’s steering a large ship, but he *is* moving it.
--
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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Warren Young]

On Jul 1, 2016, at 1:35 PM, Warren Young wrote:
> 
> To clone an existing install using setup.exe:
> 
>  $ /path/to/setup-x86_64 -R 'c:\cygwin-clone' -q -L \
>-P $(tail -n+2 installed.db | cut -f1 -d' ' | tr '\n' ,)

[snip]

> ...you can prune the long list produced by that $() construct way down

I’ve written a script to do that automatically.  (Attached.)

It takes the raw list parsed from installed.db using the scheme above and a 
copy of the setup.ini file downloaded by setup.exe and removes all “non-root” 
packages, being those that will be installed indirectly by some other package 
on that list.

It cut my largest local Cygwin installation’s package list down to about a 
fifth the size spewed out by the command above.

Enjoy!



find-cyg-roots
Description: Binary data
--
Problem reports:   http://cygwin.com/problems.html
FAQ:   http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[KARL BOTTS]

> A VS installation shouldn’t affect the rebase setup of Cygwin.

I'm with you.  But it did.  I am not blaming Cygwin; I am a friend of Cygwin.


>> Eventually, I reinstalled a fresh cygwin

> Did you install all the same things, or a minimal install,

Most of the same packages, but a from-scratch install.  And it is a pretty
light Cygwin: no gcc, no X, no Apache, no databases, no LaTeX...


>> 1) After you do the full rebase, before you even start anything cygwin,
reboot
>> Windows, then start a bash or something. Reboot Windows, early and often,
>> whenever upgrading anything.

> I’ve never had to resort to such voodoo to keep Cygwin going. The
standard
> schedule of reboots due to Patch Tuesday has been sufficient.

I resort to such voodoo to keep Windows going.  Windows is much better than
it used to be, but I still say: whenever you feel nervous about the state of
Windows, reboot it.  You will feel better, even if it doesn't.
Voodoo is not always sufficient: silver crosses and garlic help, too.


BTW: I use Cygwin32 on Windows-64.  I'm happy with that.  Windows itself also
uses lots of 32-bit components even under Win-64.  In fact, VS itself is
a (very large) 32-bit app.  There are good reasons for that, for them and for
us.
Basically, that 32-bit software runs so smoothly under an opsys running on
Intel64,
is one of the latter's best features.


> Cygwin should never cause a Windows box to become unbootable. It simply
> doesn’t get its hooks into the system deeply enough to cause such
trouble,

I concur wholeheartedly: Cygwin is delightfully non-intrusive, given what it
does.
I have never seen Cygwin hose Windows: only the reverse.
MS should take a lesson.  In fact, I think they are trying: they claim that
the
next VS will be "XCOPY deployable", which means what sane software, such as
Cygwin,
has always been.  Mostly, it means they have to rip out all the dependencies
on
the goddamn Registry.  Which will require many thousand kiddy-coder-hours,
methinks.


>> And, it moves DLLs around, even installs more, on the way back up.

> “It” being Windows, or Cygwin?
> If the former, new Windows DLLs shouldn’t interfere with Cygwin DLLs,
unless
> by some wild coincidence there is an overlap in memory load spaces.

"It" being Windows.  That is why you get the screen after
install-stuff-then-reboot,
"Configuring windows, please don't turn off your machine", and so forth.
Among other things, they are delay-replacing DLLs (for which there are
special
Windows syscalls).  Also, they "rebase" lots of DLLs, notably .NET.Framework
parts, to try to optimize load time, by avoiding runtime fixups: they don't
really use PIC code, if at all.  Given all that, it does not seem to me that
some load-address conflicts would be a "wild coincidence".


> Because Satya Nadella has been in charge for only about two years now.

You think he's in charge?  Ha-ha, I bet so did he, when he took the job.
But he is trying to change a corporate culture, without breaking too many
eggs.
Good luck to him.  Heroin might help.
 

---
Karl Botts, kdbo...@usa.net


--
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: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Warren Young]

On Jun 29, 2016, at 6:24 AM, KARL BOTTS  wrote:
> 
> A couple of weeks ago I installed Visual Studio 2015...It is a huge install 
> -- 20GB disk space, more than an hour, a couple of reboots.

In a world where main storage is measured in 100s of MB per second, installing 
20 gigs should not take hours.  (Yes, hours: the recent upgrade to VS 2015 SP3 
took two hours here.)

Maddening.

> After that, I had the now semi-familiar problems with cygwin -- "cannot fork,
> cannot load dlls", that kind of stuff.

A VS installation shouldn’t affect the rebase setup of Cygwin.

Is this a 32-bit system?  If so, and you have lots of Cygwin libraries 
installed, it can starve rebase of suitable library loading points.  That gives 
two obvious solutions: 1) Go 64-bit; or 2) Remove stuff you don’t actually need.

> Eventually, I reinstalled a fresh cygwin

Did you install all the same things, or a minimal install, which you built on 
top of, installing only things you need right now?  If the latter, perhaps the 
actual fix was installing fewer Cygwin-based DLLs, thereby giving rebase more 
freedom to place DLLs.

> 1) After you do the full rebase, before you even start anything cygwin, reboot
> Windows, then start a bash or something.  Reboot Windows, early and often,
> whenever upgrading anything.  This has helped me before.  I suspect that I
> forgot it this last time.  I _suspect_ that had I followed that, I would not
> have had to reinstall cygwin.  Maybe.

I’ve never had to resort to such voodoo to keep Cygwin going.  The standard 
schedule of reboots due to Patch Tuesday has been sufficient.

> 2) I always have cygdrive-prefix set to /

Me, too.

> But when you reinstall cygwin, you must do it again with "mount -c".  And then
> immediately do "mount -m > /etc/fstab", so that it sticks.

You’re doing it the hard way.

After a fresh install, just edit /etc/fstab.  The last line in the stock 
version is:

none /cygdrive cygdrive binary,posix=0,user 0 0

Just change the second field to / and restart Cygwin.

> Then, you should
> patch up the symlinks in /etc/{hosts,services,couple-more}

I’ve never manually done that, primarily because I rarely use such files via 
Cygwin.

You can force Cygwin to fix such things up for you by reinstalling the 
base-files package.  That’s doubtless why my symlinks are in order: some 
upgrade along the line fixed them for me.

> 3) Once you have a cygwin you like, you can _usually_ copy it to other hosts. 
> Use cygwin cp or tar.

rsync -a should also work.

> 4) Keep yourself a list of cygwin packages you know you need,

You don’t need to; Cygwin itself remembers what you have installed.

To clone an existing install using setup.exe:

  $ /path/to/setup-x86_64 -R 'c:\cygwin-clone' -q -L \
-P $(tail -n+2 installed.db | cut -f1 -d' ' | tr '\n' ,)

The installed.db file is copied from the machine whose Cygwin installation you 
want to clone.  It lives in /etc/setup.

If you don’t need many packages, you can prune the long list produced by that 
$() construct way down, so that you install only the “root” packages that cause 
all the others to be installed as dependencies.

> I have had trouble
> with the "setup -P", sometimes, but I think you could get that to work.

I’ve just tested the above command here to create a local clone.  I encountered 
no trouble once I had the command debugged.

> 5) Again, reboot Windows between any steps.

If that is needed after setup.exe exits, setup.exe itself will tell you.  If it 
doesn’t and you get no postinstall script errors, you can safely assume that 
your new Cygwin installation is ready to use.

> you want to know that it _will_ reboot, anyhow.

Cygwin should never cause a Windows box to become unbootable.  It simply 
doesn’t get its hooks into the system deeply enough to cause such trouble,

> And, it moves
> DLLs around, even installs more, on the way back up.

“It” being Windows, or Cygwin?

If the former, new Windows DLLs shouldn’t interfere with Cygwin DLLs, unless by 
some wild coincidence there is an overlap in memory load spaces.  And again, 
that’s solved by either using 64-bit Windows and 64-bit Cygwin or not 
installing so much stuff that conflicts are near-inevitable.

If the latter, Cygwin doesn’t install new things on bootup.  Once setup.exe 
exits, your Cygwin installation should be stable until you fire setup.exe up 
again.

> I still don't understand why MS did not just help cygwin
> get a better installation/maintenance procedure, and fix the damn fork
> problems, instead of going down the UbuntuOnWindows path.

Because Satya Nadella has been in charge for only about two years now.  The 
time to help Cygwin with the fork() problem was about 15 years ago.  Ballmer 
and his predecessors had no interest in helping Windows work with non-Windows 
platforms.  Nadella’s coming along now and bailing like mad, trying to keep the 
ship afloat despite their two major cash cows (Office and Windows) shrinking 
fast in 

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Andrey Repin]

Greetings, KARL BOTTS!

> 2) I always have cygdrive-prefix set to /, so that I can do, e.g. "cd /c".
> But when you reinstall cygwin, you must do it again with "mount -c".  And then
> immediately do "mount -m > /etc/fstab", so that it sticks.  Then, you should
> patch up the symlinks in /etc/{hosts,services,couple-more}; find them with
> readlink.  There are some more in some fonts dir, but I ignore those: don't
> care.

You can supply fstab and nsswitch.conf in advance of a new install, I presume.


-- 
With best regards,
Andrey Repin
Friday, July 1, 2016 09:32:44

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

Re: Anecdotal: Rebase and Visual Studio 2015 and /etc

[Eliot Moss]

On 6/29/2016 8:24 AM, KARL BOTTS wrote:


2) I always have cygdrive-prefix set to /, so that I can do, e.g. "cd /c".
But when you reinstall cygwin, you must do it again with "mount -c".  And then
immediately do "mount -m > /etc/fstab", so that it sticks.  Then, you should
patch up the symlinks in /etc/{hosts,services,couple-more}; find them with
readlink.  There are some more in some fonts dir, but I ignore those: don't
care.


A minor suggestion here:

I have had less trouble by linking individual drives, e.g.,

/c -> /cygdrive/c

This does not get you every one of them, but you can set more
(/d -> /cygdrive/d, etc.) and cover them over time.

May not be for everyone, but setting that prefix to / seems
to be potentially problematic.

More broadly, and this may be something for the cygwin / rebaseall
maintainers, it would have helped me to have clear instructions as
to how to blow away the rebase database so that I can force it to
be rebuilt.  Installations and upgrades do sometimes get me into
rebase issues, and sometimes it seems that rebuilding the database
(and (often) rebooting as well) are needed to fix it.  Having those
instructions in the documentation (man page, etc.) for rebase and
friends would have saved me time figuring it out.  The docs seem
somewhat to pre-date the advent of the rebase database and incremental
rebasing.

Regards -- Eliot Moss

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