include SHA1/MD5 hash/digest of setup.exe, and use HTTPS
Hello, Please include SHA1/MD5 hash/digest code of "setup.exe" file, on webpage next to "setup.exe" download url-link. so we know for sure, if we have a correct file or not, and someone in middle (MITM) has not changed it. Windows users prefer to verify files rather with sha1/md5 etc, than using asc, as asc verification is more complicated. And also, please distribute the setup.exe, via using a HTTPS based URL/site. So we/users can get it securely (and over encrypted connections) from your site, cygwin.com No need for a paid/purchased SSL/TLS certificate. A self-signed or CAcert or other free cert (various cert providers have free cert for non-profit or open-source developers), is more than enough & suffice. Much much better than using no encryption at all. Does the "setup.exe" connect to Internet/mirror sites using https or SSL/TLS encrypted connections ? if not please, change "setup.exe" codes further, so that at least initial connections while obtaining hash/digest/asc code of other source files are obtained via using SSL/TLS (if that source site supports). You should have or host the hash/digest/asc files of all source files under cygwin.com site. A larger sized source file or binary file can be downloaded via non-https way, ONLY if the hash/digest/asc codes were already obtained through SSL/TLS/HTTPS connection in early. Thanks, Thanks, Thanks. -- Bry8 Star. (Bry8Star). -- 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: associating volume labels with drive letters
On 14/09/2012, at 12:35 AM, Nellis, Kenneth wrote:
> From: Corinna Vinschen
> On Jul 29 15:34, Schwarz, Konrad wrote:
> Can you answer the following question:
>
> Given a volume label, how does one figure out where the
corresponding
> volume has been mounted into the Cygwin namespace?
>
>>> In Linux, you can look up the mount point for device /dev/sdXY
>>> in /proc/mounts or in the output of mount(8). Thus, given
>>> a volume label, you can figure out where to access the files
>>> on the volume.
>>>
>>> How do you do that in Cygwin?
>>
>> ls /cygdrive. Insert the disk. ls /cygdrive again. There's a new
>> directory entry now.
>>
>> Or, open the "Computer" Window on your desktop.
>
> Dredging up an old thread
> (http://sourceware.org/ml/cygwin/2011-07/msg00390.html)...
>
> Regarding Corinna's last suggestion, it seems to me that if
> Windows can associate a volume label with a drive letter,
> there must be a way to script this association, whether
> using Cygwin shell commands directly or indirectly through
> DOS commands.
>
> Using blkid(8), from the util-linux package, I can get a device
> name from a label:
>
> $ blkid -L CRUZER
> /dev/sdc1
>
> Now, if I'm on the right path, how can I associate that
> block-special file with a drive letter or a /cygdrive/x
> path reference?
>
> --Ken Nellis
Hi,
Here is a perl script which I believe should do the trick.
It adds: (for example)
DRIVE="C:"
to the end of the blkid output where the drive letter matches the correct drive
location.
Along the same lines I've also played around with a customised version of
cygwin that allows the mount
command to use UUID's to identify the drive letter instead of hard coding into
fstab. This would be useful
if you wanted specific drives to be mounted to specific locations without
dependence on the drive letter.
I haven't extensively tested this, just quickly put it together to give you the
idea.
cut -
#!/usr/bin/perl
use strict;
use Cwd 'abs_path';
# no buffer
$| = 1;
my %drives;
for (my $i = 0; $i < 26; $i++)
{
my $chr = chr(ord('A') + $i);
my $str = sprintf ("/proc/sys/GLOBAL\?\?/$chr:");
if (-l $str)
{
my $path = abs_path ($str);
$drives{"$path"} = "$chr";
}
}
open (BLKID, "blkid |") or die "Failed: $!";
while ()
{
chomp;
my $line = $_;
my $drive;
# Print the blkid line.
printf ("%s", $line);
# Deal with harddisk case.
if (s|(^/dev/sd)([a-z]*)([0-9]*):.*$|$1$2$3|)
{
# Convert to cygwin device.
my $disk = ord(substr($2, 0, 1)) - ord('a');
if (length($2) == 2)
{
$disk = ($disk + 1) * 26 +
(ord(substr($2, 1, 1)) - ord('a'));
}
my $partition = ord(substr($3, 0, 1)) -
ord('0');
if (length($3) == 2)
{
$partition = ($partition * 10)
+ (ord(substr($3, 1, 1)) - ord('0'));
}
my $path =
abs_path("/proc/sys/Device/harddisk${disk}/partition${partition}");
$drive = $drives{$path};
printf (" DRIVE=\"%s:\"\n", $drive);
}
}
cut -
Cheers,
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: Unwanted texlive invasion
On 25/09/2012 5:20 PM, Ken Brown wrote: [Please don't top-post.] On 9/25/2012 2:10 PM, Wynfield Henman wrote: On Tue, Sep 25, 2012 at 10:07 AM, Ken Brown wrote: On 9/25/2012 11:41 AM, Ryan Johnson wrote: Hi all, I'm trying to upgrade a set of existing cygwin packages, and texlive suddenly wants to install itself, apparently due to a new dependency from gnuplot. Is this really necessary? This dependency is created by cygport. It's of course up to the gnuplot maintainer (Volker Zell) whether or not he wants to override it, but I can explain the rationale. gnuplot installs some files into /usr/share/texmf-dist. To make it possible for tex to find those files, the gnuplot postinstall script runs /usr/bin/mktexlsr. The latter is provided by texlive-collection-basic, so this package is required by gnuplot. Maybe you should just bite the bullet and install texlive. It won't interfere in any way with your native TeX Live installation, as long as you put the bin directory for the latter first in your path. > I don't agree. The solution should not be to install an unnecessary > package and waste space and complicate by having to check order in the > PATH variable. People who install programs that are not provided by Cygwin have to expect to set PATH appropriately, including checking the order of the paths. > It would be better that a.) installation scripts check for the > existence of the necessary commands first and not brute force the > installation or warning that the cygwin port of it be installed. For the issue being discussed in this thread (the gnuplot dependency on texlive-collection-basic), the necessary command *is* /usr/bin/mktexlsr. Running the mktexlsr provided by the native TeX Live distribution will not do the job (which is to make the files installed in /usr/share/texmf-dist accessible to tex). > It may also be desirable, to have setup use a list of packages to NOT > install, regardless of any dependencies. I don't think setup.exe should make it quite that easy for people to circumvent dependencies. But maybe something like the Debian "equivs" facility would be useful (see http://www.tug.org/texlive/debian.html for a discussion of this in the context of TeX Live). I think this really reflects a more general issue, which is how software should treat optional dependencies (e.g. gnuplot's TikZ terminal, or myriad emacs bells and whistles). Options tend to be hardwired in at compile time, with pressure to include support for everything lest some user complain their favorite feature is disabled. If feature checks were performed at runtime, the problem goes away. Files in /usr/share/texmf-dist are a problem under this regime, but really it just shows that TikZ should be a separate package that depends on both texlive and gnuplot; it is essentially a pair of plugins, one for each app. Meanwhile, the workaround is simple enough this time: uninstall gnuplot. Fewer checkboxes to tick in setup.exe, only needs done once, and its .tgz (to compile from scratch) is significantly smaller than the texlive packages, should that become necessary. Ryan -- 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
ssh-host-config seg fault on Vista
Hello,
I have recently setup cygwin sshd on Win7, Win2k3, and Win2k8 no issue.
Run setup, add sshd package, install. Run cygterm as Administrator,
ssh-host-config, setup ssh keys.
However installing cygwin sshd on Vista is running into the following problem:
** Info: Generating /etc/ssh_host_key
/usr/bin/ssh-host-config: line 73: 2464
Segmentation fault (core dumped) /usr/bin/ssh-keygen -t rsa1 -f
${SYSCONFDIR}/ssh_host_key -N '' > /dev/null
*** Warning: Generating /etc/ssh_host_key failed!
*** Info: Generating /etc/ssh_host_rsa_key
/usr/bin/ssh-host-config: line 73: 3808
Segmentation fault (core dumped) /usr/bin/ssh-keygen -t rsa -f
${SYSCONFDIR}/ssh_host_rsa_key -N '' > /dev/null
*** Warning: Generating /etc/ssh_host_key failed!
*** Info: Generating /etc/ssh_host_dsa_key
/usr/bin/ssh-host-config: line 73: 3908
Segmentation fault (core dumped) /usr/bin/ssh-keygen -t dsa -f
${SYSCONFDIR}/ssh_host_dsa_key -N '' > /dev/null
*** Warning: Generating /etc/ssh_host_key failed!
*** Info: Generating /etc/ssh_host_ecdsa_key
/usr/bin/ssh-host-config: line 73: 3340
Segmentation fault (core dumped) /usr/bin/ssh-keygen -t ecdsa -f
${SYSCONFDIR}/ssh_host_ecdsa_key -N '' > /dev/null
*** Warning: Generating /etc/ssh_host_key failed!
In fact any call to ssh-keygen –t rsa fails.
Windows Vista Enterprise SP1 (vmware ESX 4.1 virtual machine, x86, 1g ram)
Cygwin 1.7.16-1
OpenSSH 6.1p1-1
Openssl1.0.1c-2
Any tips?
Thanks
-Nate
ps; Vista is still required for the test environment platform coverage, not my
choice of OS.
--
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: Unwanted texlive invasion
[Please don't top-post.] On 9/25/2012 2:10 PM, Wynfield Henman wrote: On Tue, Sep 25, 2012 at 10:07 AM, Ken Brown wrote: On 9/25/2012 11:41 AM, Ryan Johnson wrote: Hi all, I'm trying to upgrade a set of existing cygwin packages, and texlive suddenly wants to install itself, apparently due to a new dependency from gnuplot. Is this really necessary? This dependency is created by cygport. It's of course up to the gnuplot maintainer (Volker Zell) whether or not he wants to override it, but I can explain the rationale. gnuplot installs some files into /usr/share/texmf-dist. To make it possible for tex to find those files, the gnuplot postinstall script runs /usr/bin/mktexlsr. The latter is provided by texlive-collection-basic, so this package is required by gnuplot. Maybe you should just bite the bullet and install texlive. It won't interfere in any way with your native TeX Live installation, as long as you put the bin directory for the latter first in your path. > I don't agree. The solution should not be to install an unnecessary > package and waste space and complicate by having to check order in the > PATH variable. People who install programs that are not provided by Cygwin have to expect to set PATH appropriately, including checking the order of the paths. > It would be better that a.) installation scripts check for the > existence of the necessary commands first and not brute force the > installation or warning that the cygwin port of it be installed. For the issue being discussed in this thread (the gnuplot dependency on texlive-collection-basic), the necessary command *is* /usr/bin/mktexlsr. Running the mktexlsr provided by the native TeX Live distribution will not do the job (which is to make the files installed in /usr/share/texmf-dist accessible to tex). > It may also be desirable, to have setup use a list of packages to NOT > install, regardless of any dependencies. I don't think setup.exe should make it quite that easy for people to circumvent dependencies. But maybe something like the Debian "equivs" facility would be useful (see http://www.tug.org/texlive/debian.html for a discussion of this in the context of TeX Live). As usual, it's easy to come up with ideas for enhancing setup.exe; but http://cygwin.com/acronyms/#SHTDI 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: No support for sharing unnamed semaphores between processes through shared memory?
Matt Sexton wrote: Hello, I am attempting to port to Cygwin an application that synchronizes between processes using unnamed semaphores in shared memory. Both processes have mapped the shared memory region, one process initialize There's a cygwin process that you have to have running for shared memory that "hosts" or holds on to the shared memory. I think it is the Cygwin cygserver(but don't kill me if I'm wrong)... Something needs to hang around and hold onto that shared memory, or windows will recycle 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: Attn: base-files maintainer? [Was: sshd from user account - env issues]
On 9/19/2012 10:45 PM, Charles Wilson wrote: > On 9/19/2012 1:41 PM, jafa wrote: >> Running SSHD from the user account like this basically works - I can ssh >> into the machine, but the env vars are not quite right. >> >> For example, local bash: >> TEMP=/tmp >> temp=C:\Users\build\AppData\Local\Temp >> TMP=/tmp >> tmp=C:\Users\build\AppData\Local\Temp >> >> SSH session: >> temp= >> TEMP=/tmp >> tmp= >> TMP=/tmp > > Try installing the test version of the base-files package (4.1-2). > There was a thread six months ago or so where it was decided that > setting vars in both upcase and lowercase was a bad idea (breaks .net > applications, for one thing, and confuses many others). This change > was implemented in base-files as a test, but has never been promoted. Windows sets temp and tmp to windows style paths (eg C:\Users\build\AppData\Local\Temp) Cygwin sets TEMP and TMP to cygwin style paths (eg /tmp) Confirming, MSVS fails to compile if both "TMP" and "tmp" are set. The workaround is to unset TEMP and TMP on the line that invokes MSVS. MSVS detects the Windows style "temp" and "tmp" vars and runs ok. Having just one "TMP" var may cause problems... if TMP is set to a cygwin style path MSVS won't work, and if TMP is set to a Windows style path some cygwin apps might not work. The current release implementation works ok - Cygwin apps work without issue and MSVS works as long as you unset TEMP and TMP before invoking. Nick -- 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: Cygwin corrupted taskkill in windows commandline
On Tue, Sep 25, 2012 at 2:32 PM, Hazel wrote: > What is it that's so hard to understand?. > > C:\Windows\system32\cmd.exe Can not execute native functions. > > This is on *XP Pro 32bit* as already stated. Then you have an issue that is not related to Cygwin even though the issue may have begun coincidental to you installing Cygwin. -- Earnie -- https://sites.google.com/site/earnieboyd -- 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: Cygwin corrupted taskkill in windows commandline
What is it that's so hard to understand?. C:\Windows\system32\cmd.exe Can not execute native functions. This is on *XP Pro 32bit* as already stated. -- View this message in context: http://cygwin.1069669.n5.nabble.com/Cygwin-corrupted-windows-commandline-tp92938p93051.html Sent from the Cygwin list mailing list archive at Nabble.com. -- 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: Unwanted texlive invasion
I don't agree. The solution should not be to install an unnecessary package and waste space and complicate by having to check order in the PATH variable. It would be better that a.) installation scripts check for the existence of the necessary commands first and not brute force the installation or warning that the cygwin port of it be installed. It may also be desirable, to have setup use a list of packages to NOT install, regardless of any dependencies. Maintaining that list would be the site's administistrator's task. I also have the problem of setup always trying to install texlive, when I already have the native version, and it's a pain to have to continually go in and select [skip] for each one and the select yes I don't want these, every time I want to update other packages. On Tue, Sep 25, 2012 at 10:07 AM, Ken Brown wrote: > On 9/25/2012 11:41 AM, Ryan Johnson wrote: >> >> Hi all, >> >> I'm trying to upgrade a set of existing cygwin packages, and texlive >> suddenly wants to install itself, apparently due to a new dependency >> from gnuplot. Is this really necessary? > > > This dependency is created by cygport. It's of course up to the gnuplot > maintainer (Volker Zell) whether or not he wants to override it, but I can > explain the rationale. gnuplot installs some files into > /usr/share/texmf-dist. To make it possible for tex to find those files, the > gnuplot postinstall script runs /usr/bin/mktexlsr. The latter is provided > by texlive-collection-basic, so this package is required by gnuplot. > > Maybe you should just bite the bullet and install texlive. It won't > interfere in any way with your native TeX Live installation, as long as you > put the bin directory for the latter first in your path. > > 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 > -- 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: Unwanted texlive invasion
On 9/25/2012 11:41 AM, Ryan Johnson wrote: Hi all, I'm trying to upgrade a set of existing cygwin packages, and texlive suddenly wants to install itself, apparently due to a new dependency from gnuplot. Is this really necessary? This dependency is created by cygport. It's of course up to the gnuplot maintainer (Volker Zell) whether or not he wants to override it, but I can explain the rationale. gnuplot installs some files into /usr/share/texmf-dist. To make it possible for tex to find those files, the gnuplot postinstall script runs /usr/bin/mktexlsr. The latter is provided by texlive-collection-basic, so this package is required by gnuplot. Maybe you should just bite the bullet and install texlive. It won't interfere in any way with your native TeX Live installation, as long as you put the bin directory for the latter first in your path. 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
Unwanted texlive invasion
Hi all, I'm trying to upgrade a set of existing cygwin packages, and texlive suddenly wants to install itself, apparently due to a new dependency from gnuplot. Is this really necessary? Ryan -- 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: mintty: Ctrl-Q does not work?
On 25/09/2012 6:05 AM, Helmut Karlowski wrote: I type cat [some long ascii-file] then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be terminated by closing the window). Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin Can anybody reproduce this? Confirmed with mintty 1.1.1 and the same version of cygwin (w7-64). FWIW, doing it with `find .' rather than `cat' works fine. Regards, Ryan -- 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: mintty: Ctrl-Q does not work?
On 25.09.2012 12:05, Helmut Karlowski wrote: I type cat [some long ascii-file] then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be terminated by closing the window). Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin Can anybody reproduce this? Yes, and it seems to be an issue with cat, not mintty: cat x hangs grep . xworks cat x | grep . works grep . x | cat hangs for seconds repeatedly even without ^S Killing the cat process sometimes works (releasing mintty), sometimes it claims "No such process" although it's in the task table (ps). -- Thomas -- 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: Autocompletion of shell variables
Jovan Grbic wrote: > I have an irk with Cygwin 1.7.16. The problem is that the autocompletion of > shell variables is not functioning if I don't use full windows executable > name of standard linux tool. > > For example. I have variable SERVER=a.b.c.d. When i try > ssh $SER > autocomplete does not work, but with > ssh.exe $SER > autocomplete works. Autocompletion of file system paths works in both cases. A quick bit of experimentation shows this is related to the bash-completion package. If that's installed, you'll see the above behaviour. If it's not installed, everything works as expected. If you don't need it, uninstalling bash-completion appears to be a work-around for me. -- 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: Autocompletion of shell variables
On Tue, Sep 25, 2012 at 8:05 AM, Jovan Grbic wrote: > Hello, > > I have an irk with Cygwin 1.7.16. The problem is that the autocompletion of > shell variables is not functioning if I don't use full windows executable > name of standard linux tool. > > For example. I have variable SERVER=a.b.c.d. When i try > ssh $SER > autocomplete does not work, but with > ssh.exe $SER > autocomplete works. Autocompletion of file system paths works in both cases. > > I'm certain that it functioned like expected in some of my former cygwin > installations. I'm using latest version now. WJFFM. Maybe your ~/.inputrc is the reason? -- Earnie -- https://sites.google.com/site/earnieboyd -- 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
Autocompletion of shell variables
Hello, I have an irk with Cygwin 1.7.16. The problem is that the autocompletion of shell variables is not functioning if I don't use full windows executable name of standard linux tool. For example. I have variable SERVER=a.b.c.d. When i try ssh $SER autocomplete does not work, but with ssh.exe $SER autocomplete works. Autocompletion of file system paths works in both cases. I'm certain that it functioned like expected in some of my former cygwin installations. I'm using latest version now. With Regards, Jovan Grbic -- 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
mintty: Ctrl-Q does not work?
I type cat [some long ascii-file] then Ctrl-S (output stops), then Ctrl-Q (terminal hangs, can only be terminated by closing the window). Using minty 1.1.2 and 1.7.16(0.262/5/3) 2012-07-20 22:55 i686 Cygwin Can anybody reproduce this? -- Helmut Karlowski -- 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: libxml2-2.8.0-1, libxslt-1.1.27-1
Hi Yaakov, On Mon, Sep 24, 2012 at 7:59 PM, Yaakov (Cygwin/X) wrote: > The following packages have been updated for the Cygwin distribution: > > *** libxml2-2.8.0-1 > *** libxml2-devel-2.8.0-1 > *** libxml2-doc-2.8.0-1 > *** libxslt-1.1.27-1 > *** libxslt-devel-1.1.27-1 > *** libxslt-doc-1.1.27-1 > *** python-libxml2-2.8.0-1 > *** python-libxslt-1.1.27-1 > > Libxml2 and Libxslt are the XML and XSLT C libraries developed for GNOME > but widely used outside thereof as well. > > This is an update to the latest upstream releases. 2.8.0 doesn't deserve to be called "latest" anymore :) FTP Listing of /libxml2/ at xmlsoft.org Sep 25 2012 04:28 Link LATEST_LIBXML2 -> libxml2-2.9.0.tar.gz Sep 25 2012 04:28 Link LATEST_LIBXML2_IS_2.9.0 -> libxml2-2.9.0.tar.gz Sep 25 2012 04:28 Link LATEST_LIBXSLT -> libxslt-1.1.27.tar.gz Sep 25 2012 04:28 Link LATEST_LIBXSLT_IS_1.1.27 -> libxslt-1.1.27.tar.gz 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
