Re: Automake 1.4l released

Re: Automake 1.4l released

[Earnie Boyd]

> Subject: RE: Automake 1.4l released
> Date: Tue, 14 Aug 2001 11:13:48 +0200
> From: Bernard Dautrevaux <Dautrevaux@microprocess.com>
> To: 'Tim Van Holder' <tim.van.holder@pandora.be>, Charles Wilson
>      <cwilson@ece.gatech.edu>
> CC: automake@gnu.org, "'cygwin@cygwin.com'" <cygwin@cygwin.com>
> 
-8<-
> 
> > my point was
> > merely that I consider the cygwin/NTFS behaviour unusual, as a file's
> > readonly attribute generally applies to the file, not the metadata
> > kept by the file system for that file.
> 
> I should agree here; ANY case where cygwin is different from traditional
> UNIX practice is disturbing.
> 

Your points are invalid in that this isn't a Cygwin behavior except
through inheritance of the way the OS and file system works.  The point
of all of the autotools is to provide for practical portability.  When
you release a version that breaks that portability then it is a bug in
the release.  Autoconf had to bend over backward to keep current
functionality for portability reasons.  Automake is a sister tool to
Autoconf and should maintain the same effort to maintain portability.

The native shell when using NTFS will exhibit this behavior as well. 
For this reason alone, please, consider Chuck's work around to this
problem.  For other reasons, you are causing a HOALOW for little gain on
the tool side.  The gain for Automake is what, "To test the distribution
for CDROM release"?  At least test to see if `touch'ing a read only file
will cause problems and work around them automagically if it does.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Tom Tromey]

>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:

Earnie> Automake is a sister tool to Autoconf and should maintain the
Earnie> same effort to maintain portability.

That's true.  But we're talking about the capability to run `make
distcheck' on a platform where the semantics are not Unix-like in an
unanticipated way.

I don't have a problem working around bugs in vendor tools.  We do
that all the time in automake.  However, I prefer that free software
be fixed at the source as well.  That is, we might implement a
workaround in automake, but I dislike using that as an excuse to leave
other free tools unfixed.

In this case the Cygwin kernel divergeces from traditional Unix usage
in a subtle way -- on Unix you can use utime() on a `a-w'
(readonly-by-permission) file.  On Cygwin (I'm guessing!) you can't.

I don't know Cygwin very well.  And I certainly wouldn't try to tell
the Cygwin developers what to do.  If this is just an oversight, then
my preference would be to fix it in Cygwin.  If it is fundamental to
Cygwin for some reason, then I would suggest we fix it in `cp'.
Automake probably isn't the only tool that relies on `cp -p'.

Earnie> For other reasons, you are causing a HOALOW for little gain on
Earnie> the tool side.  The gain for Automake is what, "To test the
Earnie> distribution for CDROM release"?

I don't know what "HOALOW" means.

The gain for automake is that we can now test for a real bug which is
easy to accidentally introduce into a distribution.  The `distcheck'
target exists *only* to do testing to make sure the distribution is
correct.  You make it sound like this isn't very important, like we
should simply disable this feature.  Well, I disagree with that.

Earnie> At least test to see if `touch'ing a read only file will cause
Earnie> problems and work around them automagically if it does.

This makes a presumption about the implementation of `touch'.  Some
versions of `touch' are implemented using open()/write().  Those will
fail.

The real question is about the behavior of `cp -p', which really
should not depend on the mode of the source file (provided it is
readable).  Sure, we could test to make sure `cp -p' works.  And we
might, because there is obviously a bug here.  But adding a workaround
to Automake doesn't mean the bug is gone.

Tom

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Christopher Faylor]

On Tue, Aug 14, 2001 at 05:06:00PM -0600, Tom Tromey wrote:
>>>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>
>Earnie> Automake is a sister tool to Autoconf and should maintain the
>Earnie> same effort to maintain portability.
>
>That's true.  But we're talking about the capability to run `make
>distcheck' on a platform where the semantics are not Unix-like in an
>unanticipated way.
>
>I don't have a problem working around bugs in vendor tools.  We do
>that all the time in automake.  However, I prefer that free software
>be fixed at the source as well.  That is, we might implement a
>workaround in automake, but I dislike using that as an excuse to leave
>other free tools unfixed.

I haven't been paying close attention to this topic.

If I can summarize, I think I'm seeing this:

1) New version of automake is released with no Cygwin testing for an
   important feature.  Or, is this mentioned in the release notes?

2) Cygwin people notice and report bug.

3) Cygwin people provide workaround which is rejected.

4) Automake people say "Not a bug.  Fix Cygwin!"

AFAICT, the rationale for this stance is that Cygwin is a free software
project and therefore we should just drop everything and fix "our bug"
if we want automake to work.  Or, possibly, we're supposed to provide
a detailed rationale on why it isn't possible to fix this in Windows.

This seems to ignore the fact that people are using older versions of
Cygwin.  Is it automake policy to tell people to update to newer OS
versions when there are problems with automake that can be traced to
an OS fault?  Or, perhaps a better example would be, Does the automake
group tell people to upgrade their libc.so when an incompatibility is
detected?

If not, then clearly automake needs to include a workaround.

Regardless, in the meantime, we'll investigate whether it is possible to
work around this *Microsoft Windows* behavior.  If it is possible to fix
without a lot of fundamental changes in Cygwin, we'll try to get a fix
into 1.3.3.  That was going to be released in the next couple of weeks.
It looks like this might delay that.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Tom Tromey]

>>>>> "Chris" == Christopher Faylor <cgf@redhat.com> writes:

Chris> 1) New version of automake is released with no Cygwin testing
Chris> for an important feature.

True.  As far as I know nobody ever tried `make distcheck' on Cygwin
before.  In fact this is the first time I've heard of anybody using
Cygwin as their primary maintainer platform for an automake-using
project.

Historically Cygwin has not been an important host platform for
Automake.  That seems to be changing though.

Chris> 3) Cygwin people provide workaround which is rejected.

The original suggestion was "disable the feature".
I'd prefer not to do that.

Chris> AFAICT, the rationale for this stance is that Cygwin is a free
Chris> software project and therefore we should just drop everything
Chris> and fix "our bug" if we want automake to work.

Please don't put words in my mouth.  Of course I don't think you
should drop anything for this problem.  If it is a bug, which I don't
even know for certain, then my preference would be that you prioritize
it along with all the other things that you prioritize.

Chris> Or, possibly, we're supposed to provide a detailed rationale on
Chris> why it isn't possible to fix this in Windows.

Or maybe you could choose not to care that `cp -p' doesn't work.

Chris> This seems to ignore the fact that people are using older
Chris> versions of Cygwin.  Is it automake policy to tell people to
Chris> update to newer OS versions when there are problems with
Chris> automake that can be traced to an OS fault?  Or, perhaps a
Chris> better example would be, Does the automake group tell people to
Chris> upgrade their libc.so when an incompatibility is detected?

Do you really think I would answer yes to any of these?

If I made you angry, then I'm sorry.  I have to say I'm surprised
though.  I thought I made my desire clear in my post.  For instance, I
said I would consider a workaround in automake as well as preferring
that a real fix be made upstream, either in Cygwin or `cp' as
appropriate.  Maybe you prefer otherwise.

Tom

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Christopher Faylor]

On Tue, Aug 14, 2001 at 07:04:11PM -0600, Tom Tromey wrote:
>Chris> 3) Cygwin people provide workaround which is rejected.
>
>The original suggestion was "disable the feature".  I'd prefer not to
>do that.

I thought I saw another workaround which was rejected as being
too slow.

>Chris> AFAICT, the rationale for this stance is that Cygwin is a free
>Chris> software project and therefore we should just drop everything
>Chris> and fix "our bug" if we want automake to work.
>
>Please don't put words in my mouth.  Of course I don't think you
>should drop anything for this problem.  If it is a bug, which I don't
>even know for certain, then my preference would be that you prioritize
>it along with all the other things that you prioritize.
>
>Chris> Or, possibly, we're supposed to provide a detailed rationale on
>Chris> why it isn't possible to fix this in Windows.
>
>Or maybe you could choose not to care that `cp -p' doesn't work.

It actually doesn't work very well on non-NTFS filesystems.  That's
known.  We use what Microsoft provides us and we don't have much
to work with on anything besides NTFS.

We could add code to cygwin which stored permissions in a separate
file on FAT "filesystems" but we've always been reluctant to add
that amount of overhead.  U/WIN does this, though.

Basically, getting 'cp -p' to work on non-NTFS is a lot of work
and no one has shown any interest in doing it.  This hasn't been
a big issue until now, AFAICR.

Apologies if all of this has been mentioned already.

>Chris> This seems to ignore the fact that people are using older
>Chris> versions of Cygwin.  Is it automake policy to tell people to
>Chris> update to newer OS versions when there are problems with
>Chris> automake that can be traced to an OS fault?  Or, perhaps a
>Chris> better example would be, Does the automake group tell people to
>Chris> upgrade their libc.so when an incompatibility is detected?
>
>Do you really think I would answer yes to any of these?

As you are not overly familiar with Cygwin, I'm not very familiar with
automake.  I know that autoconf bends over backwards to accomodate older
OSes.  I don't know what automake does.  I suspected that it would not
be very pragmatic to always say "upgrade" so I was wondering why there
was any discussion about this.

The fact is that cygwin is arguably broken *now*.  It will be broken for
a few weeks at least.

I'm not sure why there would be any hesitation to adding some sort of
workaround in automake.  Isn't that what you would do with any broken
vendor OS?  IMO, it is the only sane thing you can do if you don't want
to spend an annoying amount of time saying "Upgrade your
Cygwin/Solaris/Linux/Whatever."

The other alternative is to document Cygwin's problem and hope that
enough people will read the documentation so that the bug report flow
won't be too high.

>If I made you angry, then I'm sorry.  I have to say I'm surprised
>though.  I thought I made my desire clear in my post.  For instance, I
>said I would consider a workaround in automake as well as preferring
>that a real fix be made upstream, either in Cygwin or `cp' as
>appropriate.  Maybe you prefer otherwise.

I thought I made this same sentiment pretty clear, too.  I think that
automake should include a work around, if possible, and I think that
Cygwin should be fixed, if possible.

I'm sorry that my response came across as angry.  I guess I needed round
of adjective deletion on my email.  That will teach me to send email
while I have a migraine.

We are always interested in fixing UNIX compatibility bugs when they
don't involve excessive amount of kludging, and sometimes even then.
You can consider it a given that if we hear about a problem it is put on
our list of things to fix.  The only time we fix the tools rather than
the DLL is when there seems to be no other way to solve the problem.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Raja R Harinath]

Christopher Faylor <cgf@redhat.com> writes:
[snip]
> As you are not overly familiar with Cygwin, I'm not very familiar with
> automake.  I know that autoconf bends over backwards to accomodate older
> OSes.  

Not really, in the sense you mean.  'autoconf' requires GNU m4 and
perl on the maintainer side -- not really bending over backwards.

It is the generated 'configure' that bends over backwards to
accomodate older/non-traditional OSes.  

> I don't know what automake does.  

'automake' has a similar policy.  The maintainer of a package needs a
reasonable system.  The generated Makefile.in can be used on
older/non-traditiona OSes, as long as the user doesn't invoke any
maintainer rules. 

'make distcheck' is a maintainer rule, since it checks if the
distribution tarball generated is complete.

- hari
-- 
Raja R Harinath ------------------------------ harinath@cs.umn.edu
"When all else fails, read the instructions."      -- Cahn's Axiom
"Our policy is, when in doubt, do the right thing."   -- Roy L Ash

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Christopher Faylor]

On Tue, Aug 14, 2001 at 08:40:18PM -0500, Raja R Harinath wrote:
>Christopher Faylor <cgf@redhat.com> writes:
>[snip]
>>As you are not overly familiar with Cygwin, I'm not very familiar with
>>automake.  I know that autoconf bends over backwards to accomodate
>>older OSes.
>
>Not really, in the sense you mean.  'autoconf' requires GNU m4 and perl
>on the maintainer side -- not really bending over backwards.
>
>It is the generated 'configure' that bends over backwards to accomodate
>older/non-traditional OSes.
>
>>I don't know what automake does.
>
>'automake' has a similar policy.  The maintainer of a package needs a
>reasonable system.  The generated Makefile.in can be used on
>older/non-traditiona OSes, as long as the user doesn't invoke any
>maintainer rules.
>
>'make distcheck' is a maintainer rule, since it checks if the
>distribution tarball generated is complete.

Ok.  I'm really really sorry that I even responded to this thread.  I
really should have done more homework before shooting off my mouth.

I'll let everyone else hash this problem out.  It doesn't sound like
this is a show stopper for either automake or cygwin, anyway.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

Christopher Faylor wrote:

> On Tue, Aug 14, 2001 at 07:04:11PM -0600, Tom Tromey wrote:
> 
>>Chris> 3) Cygwin people provide workaround which is rejected.
>>
>>The original suggestion was "disable the feature".  I'd prefer not to
>>do that.


Well, I guess so.  I didn't really understand the feature; I did not 
realize (although I now understand) that changing the -r--r--r-- to 
-rw-r--r-- is equivalent to disabling the feature.

>>
> 
> I thought I saw another workaround which was rejected as being
> too slow.


Well, there were two.  One was a suggestion for US (cygwin), which was 
to chmod +w ; do the timestamp thing ; chmod -w.  I squashed that one 
because I thought it would slow down EVERY file access and dir listing 
on cygwin.  As it happens, Corinna's suggested patch does exactly this 
-- but only inside the utime() function, AFAICT.  THAT slows down only 
utime(), not everything else

The other suggestion was to basically do ^^^^^^ within the automake 
script/generated Makefile.in's.  I think that got squashed (by not-me) 
because of speed concerns, too.  I think.

>>Chris> AFAICT, the rationale for this stance is that Cygwin is a free
>>Chris> software project and therefore we should just drop everything
>>Chris> and fix "our bug" if we want automake to work.
>>
>>Please don't put words in my mouth.  Of course I don't think you
>>should drop anything for this problem.  If it is a bug, which I don't
>>even know for certain, then my preference would be that you prioritize
>>it along with all the other things that you prioritize.
>>
>>Chris> Or, possibly, we're supposed to provide a detailed rationale on
>>Chris> why it isn't possible to fix this in Windows.
>>
>>Or maybe you could choose not to care that `cp -p' doesn't work.


Well, it does work. It preserves file attributes if possible -- even 
under cygwin.  It's just that it (currently) is not possible to preserve 
those attributes on cygwin in all of the circumstances in which it IS 
possible to do so on linux. (got that?)

Oh yeah -- and it cygwin's cp complains when it isn't possible to 
preserve attributes.  linux's cp doesn't.  Or at least that's the way it 
appears.


> It actually doesn't work very well on non-NTFS filesystems.  That's
> known.  We use what Microsoft provides us and we don't have much
> to work with on anything besides NTFS.
> 
> We could add code to cygwin which stored permissions in a separate
> file on FAT "filesystems" but we've always been reluctant to add
> that amount of overhead.  U/WIN does this, though.


All this, just so a maintainer-mode target works on cygwin+FAT?  I hate 
to be a party pooper, but so what?  Tom's right: cygwin hasn't been a 
popular *maintainer* platform yet -- and for those that WANT to use 
cygwin as a platform for autotool-based project maintainance, is it 
unreasonable to assume that NTFS+ntsec will be used?

Perhaps the automake docs could mention that as a "requirement" on 
cygwin?  *Assuming* we can get the behavior fixed. on cygwin/NTFS. 
which I think Corinna just did.


> Basically, getting 'cp -p' to work on non-NTFS is a lot of work
> and no one has shown any interest in doing it.  This hasn't been
> a big issue until now, AFAICR.


As I said, I still don't think cygwin+automake+FAT+maintainer-mode is a 
big deal.  Possibly not even nativeWin+automake+maintainer-mode (NTFS or 
FAT) -- but that's a decision for the automake folks. 
cygwin+automake+NTFS+maintainer-mode MAY be important; personally, I'd 
like to restrict the discussion to just that narrow interest.


[snip rant about forced upgrades]

 
> The fact is that cygwin is arguably broken *now*.  It will be broken for
> a few weeks at least.


Not really.  See my other message.


> I'm not sure why there would be any hesitation to adding some sort of
> workaround in automake.  Isn't that what you would do with any broken
> vendor OS?  IMO, it is the only sane thing you can do if you don't want
> to spend an annoying amount of time saying "Upgrade your
> Cygwin/Solaris/Linux/Whatever."

> 
> The other alternative is to document Cygwin's problem and hope that
> enough people will read the documentation so that the bug report flow
> won't be too high.


we're talking about a pretty esoteric topic (using automake to maintain 
-- not merely build -- a project on cygwin).  PLUS, even if you DO 
maintain a project using cygwin as your platform, only the distcheck 
target fails.

I think the bug-report rate will probably be pretty low -- EVEN if no 
changes are made to EITHER cygwin OR automake.  However, perhaps a note 
in the automake documentation about maintainer mode, cygwin, and 
requiring NTFS.  (or did I already say that?)

But first, I'd like to fix the problems with cygwin on NTFS!  (But I 
*think* Corinna's utime() change does that...I'll test it in a while)


>>If I made you angry, then I'm sorry.  I have to say I'm surprised
>>though.  I thought I made my desire clear in my post.  For instance, I
>>said I would consider a workaround in automake as well as preferring
>>that a real fix be made upstream, either in Cygwin or `cp' as
>>appropriate.  Maybe you prefer otherwise.
>>
> 
> I thought I made this same sentiment pretty clear, too.  I think that
> automake should include a work around, if possible, and I think that
> Cygwin should be fixed, if possible.


Ah...fix both! Not one or the other!

> We are always interested in fixing UNIX compatibility bugs when they
> don't involve excessive amount of kludging, and sometimes even then.
> You can consider it a given that if we hear about a problem it is put on
> our list of things to fix.  The only time we fix the tools rather than
> the DLL is when there seems to be no other way to solve the problem.


Yeah...what he said.

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

Charles Wilson wrote:

> As it happens, Corinna's suggested patch does exactly this 
> -- but only inside the utime() function, AFAICT.  


Oops.  I've been speed reading too many emails this evening.  In FACT, 
there has not YET been a patch submitted for cygwin.  However, according 
to our resident NTFS security expert, a fix (really a workaround of 
Window's problem) will soon be forthcoming, and requires only:

 > a function [in cygwin1.dll] to set write access for the current user

Or at least, we hope so.  This doesn't change the suggestion that the 
problem be fixed (worked around) in both cygwin AND automake, since 
fixing it only in cygwin would require cygwin-hosted maintainers to:

a) upgrade to latest cygwin (1.3.3)  we hope.
b) use NTFS (not available on W9x/ME)
c) use CYGWIN=ntsec

At the very least, these three requirements should be noted in the 
*automake* documentation somewhere, as they relate to maintainer-mode.


> Perhaps the automake docs could mention that as a "requirement" on 
> cygwin?  *Assuming* we can get the behavior fixed. on cygwin/NTFS. which 
> I think Corinna just did.


Again, I spoke too soon.


> But first, I'd like to fix the problems with cygwin on NTFS!  (But I 
> *think* Corinna's utime() change does that...I'll test it in a while)


And AGAIN.


>> I thought I made this same sentiment pretty clear, too.  I think that
>> automake should include a work around, if possible, and I think that
>> Cygwin should be fixed, if possible.
> 
> Ah...fix both! Not one or the other!

Still think this is a good idea. :-)

However, I agree with Chris Faylor -- none of this is showstopper for 
either cygwin OR automake.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Tim Van Holder]

> Oh yeah -- and it cygwin's cp complains when it isn't possible to 
> preserve attributes.  linux's cp doesn't.  Or at least that's the way it 
> appears.

Just for the record - it DOES complain when appropriate (e.g. when copying
a file from e2fs to vfat/fat (and maybe ntfs too, but I have no ntfs mounts
in my Linux system).

> > It actually doesn't work very well on non-NTFS filesystems.  That's
> > known.  We use what Microsoft provides us and we don't have much
> > to work with on anything besides NTFS.

That's odd though - regular DOS calls (both the standard and LFN APIs)
that set a files timestamp work just fine on read-only files (looking
in the source for utime on DJGPP, there is no code to chmod +w/-w).
Strange that the Windows APIs work differently.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Corinna Vinschen]

On Wed, Aug 15, 2001 at 11:30:26AM +0200, Tim Van Holder wrote:
> > > It actually doesn't work very well on non-NTFS filesystems.  That's
> > > known.  We use what Microsoft provides us and we don't have much
> > > to work with on anything besides NTFS.
> 
> That's odd though - regular DOS calls (both the standard and LFN APIs)
> that set a files timestamp work just fine on read-only files (looking
> in the source for utime on DJGPP, there is no code to chmod +w/-w).
> Strange that the Windows APIs work differently.

That's simply not correctly explained.

The problem is only raised when using NTFS security to get POSIX
compliant file attributes (that's called `ntsec' in Cygwin). It's
no problem on FAT, FAT32 or even on NTFS if `ntsec' isn't used.

MSDN states, that it's neccessary to open a file with GENERIC_WRITE
access to be able to change the timestamps. So far the MSDN.

Actually it's sufficient to have the permission to set the so called
"file attributes" which is Microsofts naming convention for a
specific part of the file's metadata. The timestamps are part of
these "file attributes" Unfortunately that wasn't a known fact
when `utime(s)' was implemented in Cygwin.

I have changed `utime(s)' in the current developers version of Cygwin
a few minutes ago. On NT/W2K it opens the file now claiming only
FILE_WRITE_ATTRIBUTES instead of GENERIC_WRITE as desired access.
That works for a simple reason. Even if the owner has no write
access to the file's data, (s)he always has write access to the
file's attributes, extended attributes and security descriptors
(which altogether are the sum of the file's metadata).


However, that doesn't change the need for automake to care for
Cygwin versions prior to 1.3.3, apparently.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Robert Collins]

On 14 Aug 2001 19:04:11 -0600, Tom Tromey wrote:
> >>>>> "Chris" == Christopher Faylor <cgf@redhat.com> writes:
> 
> Chris> 1) New version of automake is released with no Cygwin testing
> Chris> for an important feature.
> 
> True.  As far as I know nobody ever tried `make distcheck' on Cygwin
> before.  In fact this is the first time I've heard of anybody using
> Cygwin as their primary maintainer platform for an automake-using
> project.

I did 90% of my squid automake conversion (waiting for automake 1.5
before it can be considered for squid-HEAD merging) on cygwin. make
distcheck worked fine with no errors (once other issues with distcheck
were solved - but they weren't cygwin-specific).

I haven't piped up to now, cause I had nothing to offer on this bug...
however for the record:

This cp -p error on (cygwin/ntfs/ntsec on), while interesting, is either
a) new due to changes in cygwin since I did the squid automake stuff (ie
in last 3-4 months)
b) interesting, but not the core reason for distcheck failing.

<snip>

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

Robert Collins wrote:

> On 14 Aug 2001 19:04:11 -0600, Tom Tromey wrote:
>>
>>True.  As far as I know nobody ever tried `make distcheck' on Cygwin
>>before.  In fact this is the first time I've heard of anybody using
>>Cygwin as their primary maintainer platform for an automake-using
>>project.
>>
> 
> I did 90% of my squid automake conversion (waiting for automake 1.5
> before it can be considered for squid-HEAD merging) on cygwin. make
> distcheck worked fine with no errors (once other issues with distcheck
> were solved - but they weren't cygwin-specific).
> 
> I haven't piped up to now, cause I had nothing to offer on this bug...
> however for the record:
> 
> This cp -p error on (cygwin/ntfs/ntsec on), while interesting, is either
> a) new due to changes in cygwin since I did the squid automake stuff (ie
> in last 3-4 months)
> b) interesting, but not the core reason for distcheck failing.

Nope.  It actually seems to be due to a change in automake.  Apparently, 
make distcheck did not previously 'chmod -R a-w'.  At least, that's how 
I interpret Alexandre Duret-Lutz's email on the automake list:

 > chmod -R a-w is done by the distcheck target (not distdir) to
 > make sure a distribution can work even from a read-only
 > filesystem (such as a CDROM).  This test was not done in 1.4.

"This test" being the "remove all write perms and pretend we're on a 
CDROM".  (Sure, 'make distcheck' existed in 1.4, but not with the a-w 
thing).

So, when you were using automake with squid, you still had write perms 
on the files and thus 'cp -p' worked without problems.

Hypothesis: if you built and installed automake-1.4l, and then tried to 
re-autotool your squid source tree, it would fail make distcheck even if 
you use the same cygwin1.dll that you were using 3-4 months ago.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Robert Collins]

On 14 Aug 2001 22:30:48 -0400, Charles Wilson wrote:
> Robert Collins wrote:
> 
> > On 14 Aug 2001 19:04:11 -0600, Tom Tromey wrote:
> >>
> >>True.  As far as I know nobody ever tried `make distcheck' on Cygwin
> >>before.  In fact this is the first time I've heard of anybody using
> >>Cygwin as their primary maintainer platform for an automake-using
> >>project.
> >>
> > 
> > I did 90% of my squid automake conversion (waiting for automake 1.5
> > before it can be considered for squid-HEAD merging) on cygwin. make
> > distcheck worked fine with no errors (once other issues with distcheck
> > were solved - but they weren't cygwin-specific).
> > 
> > I haven't piped up to now, cause I had nothing to offer on this bug...
> > however for the record:
> > 
> > This cp -p error on (cygwin/ntfs/ntsec on), while interesting, is either
> > a) new due to changes in cygwin since I did the squid automake stuff (ie
> > in last 3-4 months)
> > b) interesting, but not the core reason for distcheck failing.
> 
> Nope.  It actually seems to be due to a change in automake.  Apparently, 
> make distcheck did not previously 'chmod -R a-w'.  At least, that's how 
> I interpret Alexandre Duret-Lutz's email on the automake list:
> 
>  > chmod -R a-w is done by the distcheck target (not distdir) to
>  > make sure a distribution can work even from a read-only
>  > filesystem (such as a CDROM).  This test was not done in 1.4.

I never used automake 1.4. I needed the sub-dir objects only available
in CVS HEAD at that time.

> "This test" being the "remove all write perms and pretend we're on a 
> CDROM".  (Sure, 'make distcheck' existed in 1.4, but not with the a-w 
> thing).
> 
> So, when you were using automake with squid, you still had write perms 
> on the files and thus 'cp -p' worked without problems.

If that were true... I wouldn't have had to change where squid extracts
its icons from during a test build.

> Hypothesis: if you built and installed automake-1.4l, and then tried to 
> re-autotool your squid source tree, it would fail make distcheck even if 
> you use the same cygwin1.dll that you were using 3-4 months ago.

See above :]
Rob

> --Chuck
> 
-- 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Tom Tromey]

>>>>> "Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:

Charles> Nope.  It actually seems to be due to a change in automake.
Charles> Apparently, make distcheck did not previously 'chmod -R a-w'.

I looked a bit but due to massive reorganization it is a pain to find
out when this went in.


We rely on `cp -p' in a few places, all in `dist'.  The problem is
most obvious in `distcheck' because it makes the tree read-only when
it is unpacked.  But suppose you use something like CVSREAD and check
out a tree.  Then a file like configure could very well be read-only,
leading to the same problem for a simple `dist'.

I think we could add a check for whether "cp -p works in ." to
AM_INIT_AUTOMAKE and then use the result everywhere.  For this to work
we'd also need to add code to `missing' to handle this case, I think
(code I'm not entirely sure how to write -- ideally it would restore
the original file's permissions once it was done with the copy).

I think our goal should be to support this feature everywhere.  But if
there aren't maintainers who need this in 1.5, I would prefer to file
a PR and leave it until a later release.  If you are such a
maintainer, please speak up.  Charles, are you?

Tom

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released -- show of hands from cygwin/automake maintainers?

[Christopher Faylor]

[This is for the cygwin mailing list]
On Wed, Aug 15, 2001 at 08:28:05PM -0600, Tom Tromey wrote:
>>>>>> "Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
>
>Charles> Nope.  It actually seems to be due to a change in automake.
>Charles> Apparently, make distcheck did not previously 'chmod -R a-w'.
>
>I looked a bit but due to massive reorganization it is a pain to find
>out when this went in.
>
>
>We rely on `cp -p' in a few places, all in `dist'.  The problem is
>most obvious in `distcheck' because it makes the tree read-only when
>it is unpacked.  But suppose you use something like CVSREAD and check
>out a tree.  Then a file like configure could very well be read-only,
>leading to the same problem for a simple `dist'.
>
>I think we could add a check for whether "cp -p works in ." to
>AM_INIT_AUTOMAKE and then use the result everywhere.  For this to work
>we'd also need to add code to `missing' to handle this case, I think
>(code I'm not entirely sure how to write -- ideally it would restore
>the original file's permissions once it was done with the copy).
>
>I think our goal should be to support this feature everywhere.  But if
>there aren't maintainers who need this in 1.5, I would prefer to file
>a PR and leave it until a later release.  If you are such a
>maintainer, please speak up.  Charles, are you?

Can we get a show of hands for people who are actually trying to use
automake as a *maintainer* under cygwin.

I suspect that this is not a big deal and that there is no reason to
force automake people to waste time on Cygwin's irregularities for
this release.

If a bunch of people step forward, however, then, obviously I'm wrong.

Again.

So, is anyone using automake in this capacity?  If you don't know what
I'm talking about then you undoubtedly are not using automake as
a maintainer.

cgf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released -- show of hands from cygwin/automakemaintainers?

[Robert Collins]

On 15 Aug 2001 22:13:48 -0400, Christopher Faylor wrote:
> [This is for the cygwin mailing list]
> On Wed, Aug 15, 2001 at 08:28:05PM -0600, Tom Tromey wrote:
> >>>>>> "Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
> >

> I suspect that this is not a big deal and that there is no reason to
> force automake people to waste time on Cygwin's irregularities for
> this release.
> 
> If a bunch of people step forward, however, then, obviously I'm wrong.

I *was* preparing to maintain squid w/automake (once 1.5 goes gold) on
cygwin, but in the interim I've moved by main PC to Debian, so it
doesn't affect me at all.

An important thing to not:

AFAIK this is a testcase-only failure we're talking about. It *did not*
affect me with cygwin, ntfs, ntsec and automake-HEAD (which had the
chmod -R a-w under discussion.)
	
Chuck - have you tried make distcheck with a trivial package? My wager
is that that will work a-ok.	

> Again.
> 
> So, is anyone using automake in this capacity?  If you don't know what
> I'm talking about then you undoubtedly are not using automake as
> a maintainer.

Not I.

Rob

> 
> cgf
> 
> 
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
> 



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released -- show of hands from cygwin/automake maintainers?

[Charles Wilson]

Robert Collins wrote:


> An important thing to not:
> 
> AFAIK this is a testcase-only failure we're talking about. It *did not*
> affect me with cygwin, ntfs, ntsec and automake-HEAD (which had the
> chmod -R a-w under discussion.)
> 	
> Chuck - have you tried make distcheck with a trivial package? My wager
> is that that will work a-ok.	


No, I haven't.  When I get some time, I'll grab a goatbook example and 
try it.

However:

After building a CVS cygwin with Corinna's fix, Chris's change, and my 
modification (see other threads for details -- I will follow up in them 
with the specifics relative to each topic), I was able to build an 
automake-1.4l (no additional patches) that passed the three failing 
tests, lex3, pr9 and pr87.

On NTFS+ntsec.

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released -- show of hands from cygwin/automake maintainers?

[Charles Wilson]

Christopher Faylor wrote:

> [This is for the cygwin mailing list]
> On Wed, Aug 15, 2001 at 08:28:05PM -0600, Tom Tromey wrote:
> 
>>>>>>>"Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
>>>>>>>
>>Charles> Nope.  It actually seems to be due to a change in automake.
>>Charles> Apparently, make distcheck did not previously 'chmod -R a-w'.
>>
>>I looked a bit but due to massive reorganization it is a pain to find
>>out when this went in.
>>
>>
>>We rely on `cp -p' in a few places, all in `dist'.  The problem is
>>most obvious in `distcheck' because it makes the tree read-only when
>>it is unpacked.  But suppose you use something like CVSREAD and check
>>out a tree.  Then a file like configure could very well be read-only,
>>leading to the same problem for a simple `dist'.
>>
>>I think we could add a check for whether "cp -p works in ." to
>>AM_INIT_AUTOMAKE and then use the result everywhere.  For this to work
>>we'd also need to add code to `missing' to handle this case, I think
>>(code I'm not entirely sure how to write -- ideally it would restore
>>the original file's permissions once it was done with the copy).
>>
>>I think our goal should be to support this feature everywhere.  But if
>>there aren't maintainers who need this in 1.5, I would prefer to file
>>a PR and leave it until a later release.  If you are such a
>>maintainer, please speak up.  Charles, are you?
>>
> 
> Can we get a show of hands for people who are actually trying to use
> automake as a *maintainer* under cygwin.
> 
> I suspect that this is not a big deal and that there is no reason to
> force automake people to waste time on Cygwin's irregularities for
> this release.


I believe that this problem is NOT a showstopper for either cygwin-1.3.3 
or automake-1.5.  However, it's good that you're doing the poll Chris, 
just to be sure.


> So, is anyone using automake in this capacity?  If you don't know what
> I'm talking about then you undoubtedly are not using automake as
> a maintainer.


For the record, I am not. (No need for everybody on the list to write 
"me neither" messages; let's keep this to only positive replies.  I 
replied to the thread mainly for my OTHER paragraph, not this one.)

--Chuck




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.4l released -- show of hands from cygwin/automake maintainers?

[David Carter]

Yes, I use it regularly to maintain software we use internally at my
company. I develop mostly on Win2k/cygwin & deploy to HP/UX.

---
David Carter
david@carter.net


-----Original Message-----
From: cygwin-owner@sources.redhat.com
[ mailto:cygwin-owner@sources.redhat.com ] On Behalf Of Christopher Faylor
Sent: Wednesday, August 15, 2001 10:14 PM
To: cygwin@Cygwin.Com
Subject: Re: Automake 1.4l released -- show of hands from
cygwin/automake maintainers?

[This is for the cygwin mailing list]
On Wed, Aug 15, 2001 at 08:28:05PM -0600, Tom Tromey wrote:
>>>>>> "Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
>
>Charles> Nope.  It actually seems to be due to a change in automake.
>Charles> Apparently, make distcheck did not previously 'chmod -R a-w'.
>
>I looked a bit but due to massive reorganization it is a pain to find
>out when this went in.
>
>
>We rely on `cp -p' in a few places, all in `dist'.  The problem is
>most obvious in `distcheck' because it makes the tree read-only when
>it is unpacked.  But suppose you use something like CVSREAD and check
>out a tree.  Then a file like configure could very well be read-only,
>leading to the same problem for a simple `dist'.
>
>I think we could add a check for whether "cp -p works in ." to
>AM_INIT_AUTOMAKE and then use the result everywhere.  For this to work
>we'd also need to add code to `missing' to handle this case, I think
>(code I'm not entirely sure how to write -- ideally it would restore
>the original file's permissions once it was done with the copy).
>
>I think our goal should be to support this feature everywhere.  But if
>there aren't maintainers who need this in 1.5, I would prefer to file
>a PR and leave it until a later release.  If you are such a
>maintainer, please speak up.  Charles, are you?

Can we get a show of hands for people who are actually trying to use
automake as a *maintainer* under cygwin.

I suspect that this is not a big deal and that there is no reason to
force automake people to waste time on Cygwin's irregularities for
this release.

If a bunch of people step forward, however, then, obviously I'm wrong.

Again.

So, is anyone using automake in this capacity?  If you don't know what
I'm talking about then you undoubtedly are not using automake as
a maintainer.

cgf


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.4l released -- show of hands from cygwin/automake maintainers?

[Norman Vine]

Christopher Faylor writes:
>
>Can we get a show of hands for people who are actually trying to use
>automake as a *maintainer* under cygwin.
>
>I suspect that this is not a big deal and that there is no reason to
>force automake people to waste time on Cygwin's irregularities for
>this release.
>
>If a bunch of people step forward, however, then, obviously I'm wrong.

I am.

But I can live without 'make distcheck'
I can 'make dist' and then manually test it

There is also the SourceForge Linux shell account to use,
and since any project built using Cygwin and needing 
'make dist' has to be OpenSourced,  all such Cygwin Projects
also have this resource :-)

So even though I am a project 'maintainer' 
I see no reason to 'force' the good automake people
to waste time on this.

Cheers

Norman Vine


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Help please

[Jordan Halsey]

I have been running the cygwin tools on Nt for the last year or so and
recently had a major problem and before I re-install the tools I have a few
major worries. 

What seemed to happen is that after a hard crash I got a blinking cursor and
my system refused to recognize my system drive even though the symbios drive
utility could see the drive and verify that all sectors were undamaged but
still unrecognizable as a drive that could be used by my system.  This
immediately made me think of the cygwin tools and how they set mount points.
Due to time constraints I took the machine to my VAR, had a new drive put in
and re-installed NT.  I should also say that the VAR that I use is very pro
and they could do nothing for the data on my drive or explain what happened
just that the drive was inaccessible and that they would have to re-format
the drive. I told them to just leave it alone. The drive is a a 9 gig
barracuda in two 4.5 gig partitions.  Now that I have a new drive as a c:
drive this drive has become my f and g drives f is what was previously used
as my system drive so I reformatted that drive with no problems but left the
g drive untouched with the hopes that there might be a way to recognize the
drive again and retrieve any un-backed up info.  Any advice on how to do
this would be greatly appreciated even if its , no way and I have to
reformat and loose all info.

My other question is, what could possibly have happened that would cause my
drive to be in a stable (no bad blocks or sectors etc) place and yet be
unrecognizable?  Do I run risks such as this in using the cygwin tools on
NT? ( I love these tools and do not want to give them up) Is there something
that I could have done to prevent this?

TIA,


-- 
Jordan Halsey
maya|shake|prman|eias|formZ|ae
Parallax Visuals
http://www.parallaxvisuals.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Help please

[Larry Hall (RFK Partners, Inc)]

At 10:24 AM 8/20/2001, Jordan Halsey wrote:
>I have been running the cygwin tools on Nt for the last year or so and
>recently had a major problem and before I re-install the tools I have a few
>major worries. 
>
>What seemed to happen is that after a hard crash I got a blinking cursor and
>my system refused to recognize my system drive even though the symbios drive
>utility could see the drive and verify that all sectors were undamaged but
>still unrecognizable as a drive that could be used by my system.  This
>immediately made me think of the cygwin tools and how they set mount points.
>Due to time constraints I took the machine to my VAR, had a new drive put in
>and re-installed NT.  I should also say that the VAR that I use is very pro
>and they could do nothing for the data on my drive or explain what happened
>just that the drive was inaccessible and that they would have to re-format
>the drive. I told them to just leave it alone. The drive is a a 9 gig
>barracuda in two 4.5 gig partitions.  Now that I have a new drive as a c:
>drive this drive has become my f and g drives f is what was previously used
>as my system drive so I reformatted that drive with no problems but left the
>g drive untouched with the hopes that there might be a way to recognize the
>drive again and retrieve any un-backed up info.  Any advice on how to do
>this would be greatly appreciated even if its , no way and I have to
>reformat and loose all info.
>
>My other question is, what could possibly have happened that would cause my
>drive to be in a stable (no bad blocks or sectors etc) place and yet be
>unrecognizable?  Do I run risks such as this in using the cygwin tools on
>NT? ( I love these tools and do not want to give them up) Is there something
>that I could have done to prevent this?


Cygwin mount points nor any other Cygwin facility is related to this 
issue.  Whatever the problem is, its related to the drive in question
and not the software on it.



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

any one got latex2html working in cygwin?

[nasser abbasi]

hi; 

I was wondering if anyone got latex2html working ok from cygwin?
I have it installed on windows OK, and have spend 3 hrs trying to get it to work 
from cygwin instead, but still some problems remain, I'll spend more time on it....

thanks,
Nasser

 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.4l released -- show of hands from cygwin/automake maintainers?

[Ronald Landheer]

-- waving my hand --
I am moving most of my software around between Linux, CygWin and DJGPP, and
use Automake for all of them. At the moment, I'm using mostly CygWin, so
yes, I use Automake under CygWin to maintain my software (and yes, I've had
some problems with make distcheck recently, and decided not to support it
for the moment, because I wasn't sure whether the bug was mine or not, and
didn't want to spend too much time finding out)..
I guess when I need a valid distcheck, I'll just move the source to another
platform and bootstrap there.. (for the time being - I'd love a fix of any
known bug, because I don't like bugs)

Greetz!

Ronald

> -----Original Message-----
> From: cygwin-owner@sources.redhat.com
> [ mailto:cygwin-owner@sources.redhat.com]On Behalf Of Christopher Faylor
> Sent: Thursday, August 16, 2001 4:14 AM
> To: cygwin@Cygwin.Com
> Subject: Re: Automake 1.4l released -- show of hands from
> cygwin/automake maintainers?
>
>
> [This is for the cygwin mailing list]
> On Wed, Aug 15, 2001 at 08:28:05PM -0600, Tom Tromey wrote:
> >>>>>> "Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
> >
> >Charles> Nope.  It actually seems to be due to a change in automake.
> >Charles> Apparently, make distcheck did not previously 'chmod -R a-w'.
> >
> >I looked a bit but due to massive reorganization it is a pain to find
> >out when this went in.
> >
> >
> >We rely on `cp -p' in a few places, all in `dist'.  The problem is
> >most obvious in `distcheck' because it makes the tree read-only when
> >it is unpacked.  But suppose you use something like CVSREAD and check
> >out a tree.  Then a file like configure could very well be read-only,
> >leading to the same problem for a simple `dist'.
> >
> >I think we could add a check for whether "cp -p works in ." to
> >AM_INIT_AUTOMAKE and then use the result everywhere.  For this to work
> >we'd also need to add code to `missing' to handle this case, I think
> >(code I'm not entirely sure how to write -- ideally it would restore
> >the original file's permissions once it was done with the copy).
> >
> >I think our goal should be to support this feature everywhere.  But if
> >there aren't maintainers who need this in 1.5, I would prefer to file
> >a PR and leave it until a later release.  If you are such a
> >maintainer, please speak up.  Charles, are you?
>
> Can we get a show of hands for people who are actually trying to use
> automake as a *maintainer* under cygwin.
>
> I suspect that this is not a big deal and that there is no reason to
> force automake people to waste time on Cygwin's irregularities for
> this release.
>
> If a bunch of people step forward, however, then, obviously I'm wrong.
>
> Again.
>
> So, is anyone using automake in this capacity?  If you don't know what
> I'm talking about then you undoubtedly are not using automake as
> a maintainer.
>
> cgf
>
>
> --
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
> Bug reporting:         http://cygwin.com/bugs.html
> Documentation:         http://cygwin.com/docs.html
> FAQ:                   http://cygwin.com/faq/
>


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

Tom Tromey wrote:

>>>>>>"Charles" == Charles Wilson <cwilson@ece.gatech.edu> writes:
>>>>>>
> 
> Charles> Nope.  It actually seems to be due to a change in automake.
> Charles> Apparently, make distcheck did not previously 'chmod -R a-w'.
> 
> I looked a bit but due to massive reorganization it is a pain to find
> out when this went in.
> 
> 
> We rely on `cp -p' in a few places, all in `dist'.  The problem is
> most obvious in `distcheck' because it makes the tree read-only when
> it is unpacked.  But suppose you use something like CVSREAD and check
> out a tree.  Then a file like configure could very well be read-only,
> leading to the same problem for a simple `dist'.
> 
> I think we could add a check for whether "cp -p works in ." to
> AM_INIT_AUTOMAKE and then use the result everywhere.  For this to work
> we'd also need to add code to `missing' to handle this case, I think
> (code I'm not entirely sure how to write -- ideally it would restore
> the original file's permissions once it was done with the copy).
> 
> I think our goal should be to support this feature everywhere.  But if
> there aren't maintainers who need this in 1.5, I would prefer to file
> a PR and leave it until a later release.  If you are such a
> maintainer, please speak up.  Charles, are you?


No, I am not.  None of my (very small) original source contributions are 
autotool'ed <hangs head in shame>.  My interest is in making it easier 
to get a working, autotool/libtool system for building DLL's on cygwin 
"transparently" -- e.g. just like so's on unix.  Then, I can more easily 
port stuff to cygwin; I'm not *really* that concerned about originating 
software on cygwin (although that may be important to other people).

Since robert collin's hacked version of libtool which meets this goal 
requires:

auto-import changes in binutils
   --> completed (a few pending problems, but mostly there)
up-to-date autoconf
   --> 2.52 package for cygwin was released a few weeks ago
automake-1.4i or later
   --> so I've been tracking recent automake development. Hopefully, 
when automake-1.5 is released (and verified to work acceptably on 
cygwin), an official cygwin package will be released soon thereafter.

Therefore I've been meddling (read: I've been a major PITA :-) in the 

developers' mailing lists for those projects recently.


--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

For what it's worth, I have now been able to test a recent change to 
cygwin;s utime() implementation.  After building & installing a new 
cygwin kernel with that change, I then built a new automake from "clean" 
automake-1.4l sources. (that is, no local diffs).

It passed the three pesky tests lex3, pr9, and pr87.  Therefore, today's 
change to cygwin's utime() successfully works around window's 
brokenness, with the following conditions:

1) running on NT or W2K
2) using NTFS
3) CYGWIN variable contains the 'ntsec' flag

I'm now going to go run the whole automake testsuite and make sure there 
are no regressions...

--Chuck




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

Charles Wilson wrote:


> I'm now going to go run the whole automake testsuite and make sure there 
> are no regressions...


Yep, "All 325 tests behaved as expected (3 expected failures)".  So, the 
additions to cygwin's utime() have worked around this problem.  For 
cygwin, NTFS, ntsec.

--Chuck






--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Charles Wilson]

Christopher Faylor wrote:

> On Tue, Aug 14, 2001 at 05:06:00PM -0600, Tom Tromey wrote:
> 
>>>>>>>"Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
>>>>>>>
>>Earnie> Automake is a sister tool to Autoconf and should maintain the
>>Earnie> same effort to maintain portability.
>>
>>That's true.  But we're talking about the capability to run `make
>>distcheck' on a platform where the semantics are not Unix-like in an
>>unanticipated way.
>>
>>I don't have a problem working around bugs in vendor tools.  We do
>>that all the time in automake.  However, I prefer that free software
>>be fixed at the source as well.  That is, we might implement a
>>workaround in automake, but I dislike using that as an excuse to leave
>>other free tools unfixed.


I'm gonna jump back in here before things explode.  I *believe* that a 
workaround to this MSWindows problem was committed to cygwin's utime() 
today.  So that's the 'free software being fixed at the source'.

However, as Earnie pointed out, since this is a problem with MSwindows, 
and not specifically cygwin -- this behavior will show probably show up 
in the other (non-cygwin) windows platforms -- like perhaps native 
cmd.exe.  (Now, I'm not sure if that is even a consideration, since I 
dunno if the autotools are *really* ported to native windows e.g. MSVC, 
or mingw, etc.  That's a topic for you "real" automake people :-).


> 
> I haven't been paying close attention to this topic.
> 
> If I can summarize, I think I'm seeing this:
> 
> 1) New version of automake is released with no Cygwin testing for an
>    important feature.  Or, is this mentioned in the release notes?


Not quite, Chris.  This is a prerelease version of automake.  (yes, 1.5 
is due RSN, but *this* aint it. yet.)  the make distcheck target is a 
new feature that did not exist in automake 1.4 (or even 1.4-pX AFAIK).


> 2) Cygwin people notice and report bug.


okay...


> 3) Cygwin people provide workaround which is rejected.


well, not really.  Since I didn't know what the distcheck was for, I 
suggested changing to '-rw-r--r--' for ALL platforms, not just cygwin.

All I was focused on was that three particular tests failed -- but not 
because of the behavior that those tests were supposed to check (lex3, 
pr9, and pr87).  Those three tests seem to be the only ones that happen 
to exercise the 'make distcheck' target.  Perhaps automake should 
include a specific distcheck test, and NOT call distcheck from lex3, 
pr9, or pr87.

Anyway, I now have learned that distcheck is for testing if the dist 
will work from RO media (like a CDROM), setting perms to -rw-r--r--' 
kinda defeats the purpose.  Especially if we do it for ALL platforms.


> 4) Automake people say "Not a bug.  Fix Cygwin!"


Well, sortof.

 
> AFAICT, the rationale for this stance is that Cygwin is a free software
> project and therefore we should just drop everything and fix "our bug"
> if we want automake to work.  Or, possibly, we're supposed to provide
> a detailed rationale on why it isn't possible to fix this in Windows.


A bit harsh, I think.  OTOH, if "the automake people" are right, it IS 
our bug. (Well, Microsoft's bug.) And we want to act like linux as 
closely as possible, so *if possible* we should try to work around it 
*for cygwin*.

This doesn't fix the problems that *may* show up on other windows-ish 
platforms, but quite frankly that's not OUR (cygwin's) problem. 
However, I raise the issue so that the automake people will be aware of it.


> This seems to ignore the fact that people are using older versions of
> Cygwin.  Is it automake policy to tell people to update to newer OS
> versions when there are problems with automake that can be traced to
> an OS fault?  Or, perhaps a better example would be, Does the automake
> group tell people to upgrade their libc.so when an incompatibility is
> detected?


Well, yeah -- but all this really means is that the 'make distcheck' 
target that is created within an automake'd project's makefiles won't 
work.

E.g:  package foo-1.3.6 is autotool'ed. The maintainer has previously 
run all the autotools and created this 1.3.6 package for release.  I 
download it, and do './configure ; make ; make check ; make install'

It all works.  However, if I try to 'make distcheck' then THAT target 
will fail.  That's if NO changes are made in automake-1.4l or in cygwin.

Wherever this bug gets fixed, it can only make things better -- right 
now they're really pretty good.  Automake isn't "broken" on cygwin. 
It's just that one of the new features doesn't work...yet.


> If not, then clearly automake needs to include a workaround.
> 
> Regardless, in the meantime, we'll investigate whether it is possible to
> work around this *Microsoft Windows* behavior.  If it is possible to fix
> without a lot of fundamental changes in Cygwin, we'll try to get a fix
> into 1.3.3.  That was going to be released in the next couple of weeks.
> It looks like this might delay that.


Urk.  I'm almost sorry I brought it up.  (topic for cygwin-developers 
discussion: skip this problem, release 1.3.3 now, and then release 1.3.4 
soon with whatever fix we come up with?)

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Earnie Boyd]

Tom Tromey wrote:
> 
> >>>>> "Earnie" == Earnie Boyd <earnie_boyd@yahoo.com> writes:
> 
> I don't know Cygwin very well.  And I certainly wouldn't try to tell
> the Cygwin developers what to do.  If this is just an oversight, then
> my preference would be to fix it in Cygwin.  If it is fundamental to
> Cygwin for some reason, then I would suggest we fix it in `cp'.
> Automake probably isn't the only tool that relies on `cp -p'.
> 

See below.

> Earnie> For other reasons, you are causing a HOALOW for little gain on
> Earnie> the tool side.  The gain for Automake is what, "To test the
> Earnie> distribution for CDROM release"?
> 
> I don't know what "HOALOW" means.
> 

hell-of-a-lot-of-work

> The gain for automake is that we can now test for a real bug which is
> easy to accidentally introduce into a distribution.  The `distcheck'
> target exists *only* to do testing to make sure the distribution is
> correct.  You make it sound like this isn't very important, like we
> should simply disable this feature.  Well, I disagree with that.
> 

With your explanation, I disagree also.

> Earnie> At least test to see if `touch'ing a read only file will cause
> Earnie> problems and work around them automagically if it does.
> 
> This makes a presumption about the implementation of `touch'.  Some
> versions of `touch' are implemented using open()/write().  Those will
> fail.
> 
> The real question is about the behavior of `cp -p', which really
> should not depend on the mode of the source file (provided it is
> readable).  Sure, we could test to make sure `cp -p' works.  And we
> might, because there is obviously a bug here.  But adding a workaround
> to Automake doesn't mean the bug is gone.
> 

Thanks for the input.  I have a clearer understanding of the problem and
Corinna has found a fix within Cygwin.  However, I still think that
bugwardability ((tm) Akim Demaille) is appropriate for Automake.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.4l released

[Heribert Dahms]

Hi Corinna,

works always? Even on readonly media?

Bye, Heribert (heribert_dahms@icon-gmbh.de)

> -----Original Message-----
> From:	Corinna Vinschen [SMTP:vinschen@redhat.com]
> Sent:	Wednesday, August 15, 2001 13:06
> To:	Tim Van Holder
> Cc:	cygwin@cygwin.com; automake@gnu.org; cygdev
> Subject:	Re: Automake 1.4l released
> 
	[Heribert]  [snip]

> I have changed `utime(s)' in the current developers version of Cygwin
> a few minutes ago. On NT/W2K it opens the file now claiming only
> FILE_WRITE_ATTRIBUTES instead of GENERIC_WRITE as desired access.
> That works for a simple reason. Even if the owner has no write
> access to the file's data, (s)he always has write access to the
> file's attributes, extended attributes and security descriptors
> (which altogether are the sum of the file's metadata).
> 
	[Heribert]  [snip]


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.4l released

[Corinna Vinschen]

On Wed, Aug 15, 2001 at 10:18:19PM +0200, Heribert Dahms wrote:
> Hi Corinna,
> 
> works always? Even on readonly media?

This question is a joke, isn't it?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.4l released

[Bernard Dautrevaux]

> -----Original Message-----
> From: Tim Van Holder [ mailto:tim.van.holder@pandora.be ]
> Sent: Monday, August 13, 2001 10:44 PM
> To: Charles Wilson
> Cc: automake@gnu.org
> Subject: Re: Automake 1.4l released
> 
> 
> > > So IMHO, cygwin should recognize the "unusual" behaviour 
> of NTFS, and
> > > perhaps internally do 'chmod +w; touch; chmod -w' when 
> changing the
> > > timestamp of a read-only file.
> > 
> > Omygod.  You have NO idea how much overhead the necessary 
> checks would
> > add -- it would slow down file access on cygwin to a crawl.
> 
> Come on - does adding the code below to the utime() function 
> add that much
> overhead?  Getting the attributes should amount to a single 
> system call;
> the same goes for setting them, and that is only needed if 
> the file isn't
> writeable (if the overhead is noticeable, it might be 
> necessary to check
> for NTFS-ness of the target, but I suspect always doing the 
> chmod would
> be less overhead).
> 
>   curr_attr = GetFileAttr ("file");
>   if (!WRITABLE(curr_attr))
>     SetFileAttr ("file", WRITEABLE_ATTR);
>   ...
>   if (!WRITABLE(curr_attr))
>     SetFileAttr ("file", curr_attr);
>     
> (note: function names are mock-ups, but you get the idea)

I'd rather, still using mock-up function names :-) :

	result = TouchFile("file")
	if (result < 0 && errno == EACCESS) {
	   curr_attr = GetFileAttr ("file");
	   if (!WRITABLE(curr_attr)) {
		if (SetFileAttr ("file", WRITEABLE_ATTR)) 
		   result = -1;
	      else {
		   result = TouchFile("file");
	         SetFileAttr ("file", curr_attr);
		}
	   }
	}
	return result;
		
This way I don't see which overhead we will have under CygWin (or any OS
where we will do the same): just one more test if all works OK and some more
work to have it work when it fails erroneously...

> 
> Anyway, this is really something that should be talked over on the
> cygwin mailing list (maybe you could make it a PR?) - 

Agreed; I forward this to cygwin ML, but keep it also on automake as it is
important for the distcheck users to know what happens.

> my point was
> merely that I consider the cygwin/NTFS behaviour unusual, as a file's
> readonly attribute generally applies to the file, not the metadata
> kept by the file system for that file.


I should agree here; ANY case where cygwin is different from traditional
UNIX practice is disturbing.

Regards,

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/