cygport-0.9.0 in release-2

cygport-0.9.0 in release-2

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I've just made cygport-0.9.0 available in release-2.  This is the first
release from the post-branch trunk, including the following changes on
top of 0.3.13:

* Runs only on Cygwin 1.7.
* All managed mount code has been removed.
* cygclasses are now installed into ${datadir}/cygport/cygclass.
* gtk2-perl.cygclass: Adapt for Cygwin 1.7 and patches included in
perl-5.10.0-5 and perl-ExtUtils-Depends-0.300-2.

For those following cygport SVN, please note that trunk is now 1.7-only;
1.5 support is being maintained in branches/cygwin-1.5.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkixCUkACgkQpiWmPGlmQSMEmQCfb9XRMm6iY3xt3dN6QnJ5LEO8
KDQAn2/L4UX0u+/URD4LinQPoNE89QKF
=4JQt
-----END PGP SIGNATURE-----

Re: cygport-0.9.0 in release-2

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Yaakov (Cygwin Ports) on 8/24/2008 1:10 AM:
> I've just made cygport-0.9.0 available in release-2.  This is the first
> release from the post-branch trunk, including the following changes on
> top of 0.3.13:

Can we also make this version avoid the broken lndir.exe?

http://cygwin.com/ml/cygwin/2008-06/msg00056.html

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiyn/QACgkQ84KuGfSFAYDt6QCffqcCeuJfG2N42U/dR7G7I5HS
okYAnRgZJVTxAK8khQE2dhR5zhrhNikv
=+yt2
-----END PGP SIGNATURE-----

Re: cygport-0.9.0 in release-2

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eric Blake wrote:
> Can we also make this version avoid the broken lndir.exe?
> 
> http://cygwin.com/ml/cygwin/2008-06/msg00056.html

I rebuilt and tested the X11R7 lndir on 1.7, and unfortunately it seems
to have the same bug.  I would prefer to fix lndir and just use it
exclusively then trying to deal with the workaround.  Could you take a
look at the source (only one .c file) and see if you can help me figure
it out?

http://ftp.sunsite.dk/projects/cygwinports/release/X11/lndir/lndir-1.0.1-1-src.tar.bz2


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiy1SEACgkQpiWmPGlmQSMmzwCgvk5HJWqXvseTPgkZXbG9Ie2c
iVIAoIAgzg5W28t+kT6wR7T79SnjtadU
=mdFC
-----END PGP SIGNATURE-----

Re: cygport-0.9.0 in release-2

[Yaakov (Cygwin Ports)]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Yaakov (Cygwin Ports) wrote:
> I rebuilt and tested the X11R7 lndir on 1.7, and unfortunately it seems
> to have the same bug.  I would prefer to fix lndir and just use it
> exclusively then trying to deal with the workaround.  Could you take a
> look at the source (only one .c file) and see if you can help me figure
> it out?
> 
> http://ftp.sunsite.dk/projects/cygwinports/release/X11/lndir/lndir-1.0.1-1-src.tar.bz2

Based on the description of your problem, what about the attached patch?
 Your test case then works, but:

1) I have no idea what other side effects this may have;
2) Why does Cygwin act differently then every other *NIX here?
3) How many other packages is this behaviour going to affect?


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiy11EACgkQpiWmPGlmQSMjTACg36bx0b+epZXfFlb3F0GSCvgg
tz0AoJq8EeT9r4YjWkTTfLrO4255RPSe
=O57a
-----END PGP SIGNATURE-----

[-- Attachment #2: lndir-1.0.1-1.src.patch --]
[-- Type: text/x-patch, Size: 400 bytes --]

--- origsrc/lndir-1.0.1/lndir.c	2005-11-23 16:33:07.000000000 -0600
+++ src/lndir-1.0.1/lndir.c	2008-08-25 10:55:14.270794700 -0500
@@ -205,8 +205,10 @@
 	    if ((sb.st_mode & S_IFMT) == S_IFDIR)
 #endif
 	    {
+#ifndef __CYGWIN__
 		/* directory */
 		n_dirs--;
+#endif
 		if (dp->d_name[0] == '.' &&
 		    (dp->d_name[1] == '\0' || (dp->d_name[1] == '.' &&
 					       dp->d_name[2] == '\0')))

Re: cygport-0.9.0 in release-2

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eric Blake wrote:
> Other *NIX behave the same way, if they do not populate st_nlink
> to > 1 for directories (for example, I believe this is how Linux handles
> FAT filesystems, so the same lndir bug would be present there).
> Findutils already had to add special-case code to deal with st_nlink==1
> on directories, so it is more than just cygwin that does this, and
> this is a genuine upstream bug in lndir and not just a cygwin artifact.

OK, I'm just a bit surprised that I couldn't find a patch elsewhere for
this issue.

> Look closely at the lndir source code - it is doing an optimization
> where it avoids stat'ting directory entries once n_dirs is down to
> 0; because on file systems where the optimization works, n_dirs
> tells you how many subdirectories to expect, and once you have
> seen them all, all remaining readdir() entries will be non-directories.
> But in the case where st_nlink is too expensive to populate
> correctly (as is the case in cygwin, but also in other *NIX on
> various file systems like FAT), then ALL readdir results need
> stat'ting, since you no longer know if there are any remaining
> subdirs.

OK.

> That works, but I would prefer this (and don't make it conditional
> on cygwin, as it would also fix the bug for other platforms):
> 
> --- lndir.c.orig    2008-08-25 10:12:28.701142400 -0600
> +++ lndir.c    2008-08-25 10:13:20.606395800 -0600
> @@ -182,6 +182,8 @@
>     if (*(p - 1) != '/')
>     *p++ = '/';
>     n_dirs = fs->st_nlink;
> +    if (n_dirs == 1)
> +    n_dirs = INT_MAX;
>     while ((dp = readdir (df))) {
>     if (dp->d_name[strlen(dp->d_name) - 1] == '~')
>         continue;

Thanks, I've just committed xorg/lndir 1.0.1-2 to Ports SVN with this
patch.  I'll get this into release-2 as soon as I can, replacing
xorg-x11-bin-lndir, and make cygport-0.9 rely on it unconditionally.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkiy6gUACgkQpiWmPGlmQSMAHgCcCTmsiY1GjmlQFiF8JKo7tzWG
dfMAn0T4dIbK0rVs4Us76HLaEHzi3Zf8
=pIpm
-----END PGP SIGNATURE-----

Re: cygport-0.9.0 in release-2

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Eric Blake wrote:
> You should probably upload a new version soon; 0.9.0-1 is
> missing files from the binary tarball:

I've just uploaded 0.9.0-2 to release-2 accordingly.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAki0xmgACgkQpiWmPGlmQSNG5ACgzxi5XgKwMx9996VbJ41imLMY
7E8AoI4xTOPLnfw8Xl7V+ve68UtPa3cd
=0vnE
-----END PGP SIGNATURE-----

Re: cygport-0.9.0 in release-2

[Reini Urban]

Yaakov (Cygwin Ports) schrieb:
> Eric Blake wrote:
>> You should probably upload a new version soon; 0.9.0-1 is
>> missing files from the binary tarball:
> 
> I've just uploaded 0.9.0-2 to release-2 accordingly.

Shouldn't this have a major version bump?

* Runs only on Cygwin 1.7.
* All managed mount code has been removed.
* cygclasses are now installed into ${datadir}/cygport/cygclass.

-- 
Reini Urban
http://phpwiki.org/  http://murbreak.at/

Re: cygport-0.9.0 in release-2

[Yaakov (Cygwin Ports)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Reini Urban wrote:
> Shouldn't this have a major version bump?
> 
> * Runs only on Cygwin 1.7.
> * All managed mount code has been removed.
> * cygclasses are now installed into ${datadir}/cygport/cygclass.

That was the justification for jumping from 0.3/0.4 for 1.5 to 0.9
(leading to 1.0) for 1.7.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAki3QlgACgkQpiWmPGlmQSOrQgCfQ6WgPKUGbMXT5cbaabOZDf4Y
pNcAoM+1OZq71hV4+H8yR38lZGVDCemL
=vCqu
-----END PGP SIGNATURE-----