RE: setup.exe 2.218.2.8/9 broken

RE: setup.exe 2.218.2.8/9 broken

[Harig, Mark A.]

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
> Sent: Friday, May 17, 2002 1:00 PM
> To: Harig, Mark A.
> Cc: cygwin@cygwin.com
> Subject: Re: setup.exe 2.218.2.8/9 broken
> 
> 
> Harig, Mark A. wrote:
> >>-----Original Message-----
> >>From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
> >>Sent: Thursday, May 16, 2002 11:52 PM
> >>To: John Haggerty
> >>Cc: cygwin@cygwin.com
> >>Subject: Re: setup.exe 2.218.2.8/9 broken
> >>
> > 
> > (text deleted)
> > 
> >>(3) bug #2: minor issues with parsing "buried" setup.ini 
> >>files -- that 
> >>belong to things NOT cygwin-setup.exe-related.  This happens 
> >>only when 
> >>someone says "My local setup directory is HERE" when HERE has 
> >>subdirectories that don't belong to cygwin-setup.  (That's 
> >>bad, don't do 
> >>that: setup's 'local directory' is his own personal 
> playground and he 
> >>doesn't play well with others)
> > 
> > 
> > I hope that this isn't going to be the solution to the problem of
> > setup.exe finding non-setup.exe setup.ini files.  Although 
> I don't think
> > that I will make this mistake again, I expect that it will happen to
> > future users who are not reading this list today.
> 
> Perhaps some explanatory text on the panel where setup asks 
> for "local 
> directory" would be nice.  Something like "This is the cygwin setup 
> program's private cache.  Do not choose a directory with pre-existing 
> contents, unless those contents are the result of an earlier 
> run of this 
> setup program".  Care to provide a patch?
> 
> But no, it's not "the solution".  Chris has already added 
> some code that 
> assists setup in parsing only "proper" setup.ini files and skipping 
> non-setup.exe-related ones.
> 

It's the "do not choose" portion of this solution that I hope setup.exe
would avoid because it isn't paying attention to Murphy's Law.  The way
setup.exe runs now there are (at least) two possible sources of errors:

  1) setup.exe's setup.ini has become corrupted.  This is well handled
by setup.exe with its display of parsing errors.

  2) The user may have selected a Local Package Directory that contains
non-setup.exe setup.ini files.  The message that is reported for this
user error (that is, 'user selected a Local Package Directory that has
non-setup.exe package files in it') is, unfortunately, the same message
as that used to report problem 1, above.

     This can be doubly confusing because a user can run setup.exe
successfully for a long time, and then find that it stops working due to
mysterious parsing errors because s/he has installed some other package
("I'm keeping all of my installations in a single, separate directory
tree").

     So, even if we add the text you suggested telling the user about
the rules for 'Local Package Directory', setup.exe should report the
error better (i.e., not reuse the error processing method of different
kind of error) when the user doesn't follow the rules.

-mark

--
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: setup.exe 2.218.2.8/9 broken

[Jon LaBadie]

On Fri, May 17, 2002 at 02:06:36PM -0400, Harig, Mark A. wrote:
> 
> 
> It's the "do not choose" portion of this solution that I hope setup.exe
> would avoid because it isn't paying attention to Murphy's Law.  The way
> setup.exe runs now there are (at least) two possible sources of errors:
> 
>   1) setup.exe's setup.ini has become corrupted.  This is well handled
> by setup.exe with its display of parsing errors.
> 
>   2) The user may have selected a Local Package Directory that contains
> non-setup.exe setup.ini files.  The message that is reported for this
> user error (that is, 'user selected a Local Package Directory that has
> non-setup.exe package files in it') is, unfortunately, the same message
> as that used to report problem 1, above.

Not being a PC person, are "setup.exe" and "setup.ini" the names used by
convention or is there some Windows requirement for these names.

If convention, could situation 2 be eliminated by adding a "cygwin" id
to the name e.g. setup-cyg.ini.  setup.exe (?setup-cyg.exe?) could look
for the new version preferentially, falling back to the old if not found.

-- 
Jon H. LaBadie                  jcyg@jgcomp.com
 JG Computing
 4455 Province Line Road        (609) 252-0159
 Princeton, NJ  08540-4322      (609) 683-7220 (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/

Re: setup.exe 2.218.2.8/9 broken

[Christopher Faylor]

On Fri, May 17, 2002 at 02:06:36PM -0400, Harig, Mark A. wrote:
>Chuck Wilson wrote:
>>But no, it's not "the solution".  Chris has already added some code
>>that assists setup in parsing only "proper" setup.ini files and
>>skipping non-setup.exe-related ones.
>
>It's the "do not choose" portion of this solution that I hope setup.exe
>would avoid because it isn't paying attention to Murphy's Law.  The way
>setup.exe runs now there are (at least) two possible sources of errors:

IMO, this is an extremely minor issue and one which is easily corrected.

If someone chooses a populated directory to hold their downloaded files
then, well,

<additional observations deleted>

>  2) The user may have selected a Local Package Directory that contains
>non-setup.exe setup.ini files.  The message that is reported for this
>user error (that is, 'user selected a Local Package Directory that has
>non-setup.exe package files in it') is, unfortunately, the same message
>as that used to report problem 1, above.

The user should consider this a valuable learning experience that they
should not be using an existing directory to hold an application's
download files.  This is consistent with the UNIX philsophy of giving
someone enough rope to drown themselves, if they want.

>This can be doubly confusing because a user can run setup.exe
>successfully for a long time, and then find that it stops working due
>to mysterious parsing errors because s/he has installed some other
>package ("I'm keeping all of my installations in a single, separate
>directory tree").
>
>So, even if we add the text you suggested telling the user about the
>rules for 'Local Package Directory', setup.exe should report the error
>better (i.e., not reuse the error processing method of different kind
>of error) when the user doesn't follow the rules.

I don't agree.  However, this is really not worth discussing any
further.  Either someone will provide a patch or they won't.

I'd urge the main setup.exe contributors to continue to work on
important issues and consider this to be extremely low priority if
it actually makes it onto a todo list.

That said, however, if setup.exe is actually *defaulting* to using
an already populated directory, then that is not good.  The default
should be changed.  That should be easy enough to do and easy enough
to confirm.

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: setup.exe 2.218.2.8/9 broken

[Robert Collins]

> -----Original Message-----
> From: Harig, Mark A. [mailto:maharig@idirect.net] 
> Sent: Saturday, May 18, 2002 4:07 AM
> 
> It's the "do not choose" portion of this solution that I hope 
> setup.exe
> would avoid because it isn't paying attention to Murphy's 
> Law.  The way
> setup.exe runs now there are (at least) two possible sources 
> of errors:
> 
>   1) setup.exe's setup.ini has become corrupted.  This is well handled
> by setup.exe with its display of parsing errors.
> 
>   2) The user may have selected a Local Package Directory 
> that contains
> non-setup.exe setup.ini files.  The message that is reported for this
> user error (that is, 'user selected a Local Package Directory that has
> non-setup.exe package files in it') is, unfortunately, the 
> same message
> as that used to report problem 1, above.

This is because setup cannot tell the difference. Can it be taught to
tell the difference? Possibly, but I won't be doing the teaching.
 
>      This can be doubly confusing because a user can run setup.exe
> successfully for a long time, and then find that it stops 
> working due to
> mysterious parsing errors because s/he has installed some 
> other package
> ("I'm keeping all of my installations in a single, separate directory
> tree").

I keep all mine in a single separate directory tree too. This
functionality will never go away. It's keeping setup's 'local package
dir' at a logical node in the tree rather than a leaf that is the
problem.
 
>      So, even if we add the text you suggested telling the user about
> the rules for 'Local Package Directory', setup.exe should report the
> error better (i.e., not reuse the error processing method of different
> kind of error) when the user doesn't follow the rules.

It's the same sort of error to setup. I'll accept a patch that can
-accurately- differentiate between the problems. Don't diff against the
distributed source, diff against CVS for this please, as the HEAD parser
is somewhat...different.

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: setup.exe 2.218.2.8/9 broken

[Robert Collins]

> -----Original Message-----
> From: Jon LaBadie [mailto:jcyg@jgcomp.com] 
> Sent: Saturday, May 18, 2002 4:46 AM

> 
> Not being a PC person, are "setup.exe" and "setup.ini" the 
> names used by convention or is there some Windows requirement 
> for these names.

Convention.
 
> If convention, could situation 2 be eliminated by adding a 
> "cygwin" id to the name e.g. setup-cyg.ini.  setup.exe 
> (?setup-cyg.exe?) could look for the new version 
> preferentially, falling back to the old if not found.

Until a new piece of software - say a cygwin related tool - calls it's
ini files setup-cyg.ini. I see this as an interesting idea, but
fundamentally just a kludge.

The real solution IMO is to
* Rather than default to CWD if there is no stored preferemce default to
CWD + /archive (to catch what could be a common approach of making
c:\cygwin and then running setup from there. This is an approach
'taught' to folk older auto-extracting archive programs).
* When the local package dir is chosen, do a scan for ini files, and if
any parsing errors occur, complain at that point (and not with the
parsing error), rather than when heading into the chooser. This allows
us to say 'The local package dir you have chosen contains setup.exe
specific files that are corrupt or invalid. Please see
http://www.cygwin.com/setup-ug.html for more information'.

Cheers,
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: setup.exe 2.218.2.8/9 broken

[Harig, Mark A.]

> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
> Sent: Thursday, May 16, 2002 11:52 PM
> To: John Haggerty
> Cc: cygwin@cygwin.com
> Subject: Re: setup.exe 2.218.2.8/9 broken
> 
(text deleted)
> 
> (3) bug #2: minor issues with parsing "buried" setup.ini 
> files -- that 
> belong to things NOT cygwin-setup.exe-related.  This happens 
> only when 
> someone says "My local setup directory is HERE" when HERE has 
> subdirectories that don't belong to cygwin-setup.  (That's 
> bad, don't do 
> that: setup's 'local directory' is his own personal playground and he 
> doesn't play well with others)

I hope that this isn't going to be the solution to the problem of
setup.exe finding non-setup.exe setup.ini files.  Although I don't think
that I will make this mistake again, I expect that it will happen to
future users who are not reading this list today.

Also, I'd like to suggest that when setup.exe finds syntax errors in a
setup.ini file, it log those messages in a file so that the messages can
be used in reporting problems with setup.exe.  I've been unable to
cut&paste the text from the windows that list the parsing errors.

-mark

--
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: setup.exe 2.218.2.8/9 broken

[Charles Wilson]

Harig, Mark A. wrote:
>>-----Original Message-----
>>From: Charles Wilson [mailto:cwilson@ece.gatech.edu]
>>Sent: Thursday, May 16, 2002 11:52 PM
>>To: John Haggerty
>>Cc: cygwin@cygwin.com
>>Subject: Re: setup.exe 2.218.2.8/9 broken
>>
> 
> (text deleted)
> 
>>(3) bug #2: minor issues with parsing "buried" setup.ini 
>>files -- that 
>>belong to things NOT cygwin-setup.exe-related.  This happens 
>>only when 
>>someone says "My local setup directory is HERE" when HERE has 
>>subdirectories that don't belong to cygwin-setup.  (That's 
>>bad, don't do 
>>that: setup's 'local directory' is his own personal playground and he 
>>doesn't play well with others)
> 
> 
> I hope that this isn't going to be the solution to the problem of
> setup.exe finding non-setup.exe setup.ini files.  Although I don't think
> that I will make this mistake again, I expect that it will happen to
> future users who are not reading this list today.

Perhaps some explanatory text on the panel where setup asks for "local 
directory" would be nice.  Something like "This is the cygwin setup 
program's private cache.  Do not choose a directory with pre-existing 
contents, unless those contents are the result of an earlier run of this 
setup program".  Care to provide a patch?

But no, it's not "the solution".  Chris has already added some code that 
assists setup in parsing only "proper" setup.ini files and skipping 
non-setup.exe-related ones.

> Also, I'd like to suggest that when setup.exe finds syntax errors in a
> setup.ini file, it log those messages in a file so that the messages can
> be used in reporting problems with setup.exe.  I've been unable to
> cut&paste the text from the windows that list the parsing errors.

Probably a good idea -- but you can also use the "scaper" utility from 
PCMag (ZDnet) to grab text from popup dialogs.

--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: setup.exe 2.218.2.8/9 broken

[Robert Collins]

> -----Original Message-----
> From: Chris Down [mailto:chris@alcor.demon.co.uk] 
> Sent: Friday, May 17, 2002 6:27 PM
> To: 'cygwin@cygwin.com'
> Subject: Re: setup.exe 2.218.2.8/9 broken
> 
> 
> Some info that may help ( or not ).
> 
>  I regularly update my Cygwin installation ( Win2k) and I do 
> not usually 
> get any problems. However I recently updated using 
> setup-2.218.2.9 and the 
> "Download Incomplete" window popped up. After investigating I 
> found that 
> this only occurred if I tried to do an internet install  on the Setup 
> sources. If I omit this everything is fine. I use mirrors.rcn.net for 
> installs. This is repeatable on my set up.
> 
> This may or may not help users.

It will help the developers. Thanks.

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: setup.exe 2.218.2.8/9 broken

[Chris Down]

Some info that may help ( or not ).

 I regularly update my Cygwin installation ( Win2k) and I do not usually 
get any problems. However I recently updated using setup-2.218.2.9 and the 
"Download Incomplete" window popped up. After investigating I found that 
this only occurred if I tried to do an internet install  on the Setup 
sources. If I omit this everything is fine. I use mirrors.rcn.net for 
installs. This is repeatable on my set up.

This may or may not help users.

Regards

Chris Down

E-Mail Chris.Down@tptdesigns.co.uk




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

setup.exe 2.218.2.8/9 broken

[Dockeen]

Preamble:
I don't work at Cygnus, I am just another user.
(Well, maybe less skilled that any other user)

Why I am writing:
I have been upgrading Cygwin essentially daily on my work
and home machines, using the newest setup almost all the
time, and I have almost never seen a failure.  This can NOT be
because of above average skill or intelligence on my part!
Though I too am a physicist, I possess neither.  :-)
I do want to help though.

Now, almost all of my operations with setup have been
incremental installs, in the last two weeks, I have
done only one download to a CD and install on a non-networked,
no Cygwin present (at all, never installed) machine.

What sort of operation are you performing? New full install,
new partial install, install over a deleted older version,
incremental install etc?

Now, in all but one of my recent installs, I have used
"install from the internet", "all users", "unix".

I have a designated directory I let install work with,
c:\xfer\cygtemp, that is where it puts its temporary stuff.
That is the directory where I keep setup.  That is the
directory where I designate in "Select Local Package Directory".
There seem to be some issues with people using their 
c:\cygwin in this role.  Note also that I do not designate
any of the mirror subdirectories that are in my cygtemp
directory.  My connection, I use "Use IE5 Settings".  I 
have always used the mirror ftp://archive.progeny.com ,
if you look in my Cygtemp directory, you will see that there
is only one mirror folder in there.  Note though that I have
done successful incremental installs in which I have deleted
the mirror subdirectory.

This takes me through to the Cygwin Setup menu.  I open
all the categories, and install almost everything.  Ooops,
Wayne, you have been guilty of that omission - I have nearly
all the Cygwin packages installed, even the bloody games,
which are there for no intellegent reason I can tell you.

Now, this procedure works for me, for the use I describe.
It has worked for this machine, which is Win98, and my on-base
machine, which is XP-Pro.  The machine I did the virgin install
on runs Win2000 Pro.

Now, this evening, I did see a failure of the sort you note, because
I messed up and did not download the new .9 version of setup.
This is the only failure I noted.  (I also noted that gsl is
now included, that made my evening, I use it a goodly amount and
have been installing it seperately before)

I hope my experience helps in solving your problem.  I hope
it also encourages you to report the sorts of things I have
told you about my install procedure.  It really helps the guys
in trouble shooting.

Wayne Keen


--
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: setup.exe 2.218.2.8/9 broken

[Christopher Faylor]

On Thu, May 16, 2002 at 09:56:28PM +0600, Dockeen wrote:
>Preamble:
>I don't work at Cygnus, I am just another user.  (Well, maybe less
>skilled that any other user)

Obligatory reply:
Actually, nobody works at Cygnus anymore.

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: setup.exe 2.218.2.8/9 broken

[John Haggerty]

Hi,

Well thanks, that calmed me down.  I have installed cygwin maybe 50
times on different machines, but last night it was my luck to really,
really want to install it on my newly repaired laptop, and I spent maybe
4 hours doing this:

- start:
- Install Cygwin NOW! from www.cygwin.com, copy setup.exe to a local
file (2.218.2.8)
- click through the defaults on the installation gui's, as you describe,
except i) Choose All Install, but Skip all tetex and texmf packages
(needed to prevent a collision with MikTeX), 2) choose local package
directory to be a conveniently named directory
- choose as mirrors sunsite.utk.edu (seems to be mainly dead or
oversubscribed), uiuc.edu, nasa.gov, planetmirror.com (very slow)
- Get to the end (zlib) and get a popup reporting "Download Incomplete"
which seemed to end the installation prematurely
- deleting the failed installation by deleting \cygwin and the cygwin
local package directory, and usually deleting registry keys containing
"Cygnus," as described in the manual
- go back to start:

Since my machine had been sent back for network problems, it seemed
quite likely that it was a new network problem, since Cygwin never gave
me any trouble, hence the loop.

Tonight, I admit I haven't done it ten times yet with 2.218.2.9, so the
failure could have been something else (like not deleting cygwin
completely or whatnot), and I'll pass on the setup.log.full file if it
fails again.

Dockeen wrote:
> 
> Preamble:
> I don't work at Cygnus, I am just another user.
> (Well, maybe less skilled that any other user)
> 
> Why I am writing:
> I have been upgrading Cygwin essentially daily on my work
> and home machines, using the newest setup almost all the
> time, and I have almost never seen a failure.  This can NOT be
> because of above average skill or intelligence on my part!
> Though I too am a physicist, I possess neither.  :-)
> I do want to help though.
> 
> Now, almost all of my operations with setup have been
> incremental installs, in the last two weeks, I have
> done only one download to a CD and install on a non-networked,
> no Cygwin present (at all, never installed) machine.
> 
> What sort of operation are you performing? New full install,
> new partial install, install over a deleted older version,
> incremental install etc?
> 
> Now, in all but one of my recent installs, I have used
> "install from the internet", "all users", "unix".
> 
> I have a designated directory I let install work with,
> c:\xfer\cygtemp, that is where it puts its temporary stuff.
> That is the directory where I keep setup.  That is the
> directory where I designate in "Select Local Package Directory".
> There seem to be some issues with people using their
> c:\cygwin in this role.  Note also that I do not designate
> any of the mirror subdirectories that are in my cygtemp
> directory.  My connection, I use "Use IE5 Settings".  I
> have always used the mirror ftp://archive.progeny.com ,
> if you look in my Cygtemp directory, you will see that there
> is only one mirror folder in there.  Note though that I have
> done successful incremental installs in which I have deleted
> the mirror subdirectory.
> 
> This takes me through to the Cygwin Setup menu.  I open
> all the categories, and install almost everything.  Ooops,
> Wayne, you have been guilty of that omission - I have nearly
> all the Cygwin packages installed, even the bloody games,
> which are there for no intellegent reason I can tell you.
> 
> Now, this procedure works for me, for the use I describe.
> It has worked for this machine, which is Win98, and my on-base
> machine, which is XP-Pro.  The machine I did the virgin install
> on runs Win2000 Pro.
> 
> Now, this evening, I did see a failure of the sort you note, because
> I messed up and did not download the new .9 version of setup.
> This is the only failure I noted.  (I also noted that gsl is
> now included, that made my evening, I use it a goodly amount and
> have been installing it seperately before)
> 
> I hope my experience helps in solving your problem.  I hope
> it also encourages you to report the sorts of things I have
> told you about my install procedure.  It really helps the guys
> in trouble shooting.
> 
> Wayne Keen
> 
> --
> 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/

-- 
John Haggerty
internet: haggerty@bnl.gov
voice/fax: 631 344 2286/4592
http://www.phenix.bnl.gov/~haggerty

--
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: setup.exe 2.218.2.8/9 broken

[David T-G]

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

John, et al --

...and then John Haggerty said...
% 
% Hi,

Hello!


% 
% Well thanks, that calmed me down.  I have installed cygwin maybe 50

I have been amazed at the release frequency of setup.exe, but I don't
understand enough about the structure to have any place thinking that we
should fall back to a stable version and consider all of these releases
to be development only :-)  Watching the various problems that come up
has been quite educational; I'm glad I don't write software for other
people.


% 
% - start:
...
% - Get to the end (zlib) and get a popup reporting "Download Incomplete"
% which seemed to end the installation prematurely

It does, but only for that step.  AFAICT the download is, in fact,
complete.


% - deleting the failed installation by deleting \cygwin and the cygwin
% local package directory, and usually deleting registry keys containing
% "Cygnus," as described in the manual
% - go back to start:

The next time you do this, you can now install from your local directory
instead of from the 'net again, perhaps after moving the ftp site dir's
copy of release up to the setup dir level, with no problem.  I've done
this in my experimentation and hunting for cygintl-1.dll (which, BTW, I
finally got installed on my home machine and, lo, grep now greps and cat
now cats; thanks, all!).


HTH & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) davidtg@justpickone.org * than to live up to them. -- fortune cookie
(work) davidtgwork@justpickone.org
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

setup.exe 2.218.2.8/9 broken

[John Haggerty]

As far as I can see, setup 2.218.2.8 and 2.218.2.9 are still broken, as
described on this list.  

In case it's not clear, you go through an entire download, and the last
thing to be downloaded reports "Download Incomplete" on a popup, and as
far as I can see, you can never correctly install Cygwin.  Like other
correspondents, I've tried several combinations of mirrors and download
styles, and none of them seem to work correctly or completely or at
least without very alarming sounding error messages.  Beats me whether
the post-install script works or not.

If you're going to work on this, could you leave a working version in
place while you do so, and try it before posting it?  Thanks.

-- 
John Haggerty
internet: haggerty@bnl.gov
voice/fax: 631 344 2286/4592
http://www.phenix.bnl.gov/~haggerty

--
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: setup.exe 2.218.2.8/9 broken

[Christopher Faylor]

On Thu, May 16, 2002 at 10:32:04PM -0400, John Haggerty wrote:
>As far as I can see, setup 2.218.2.8 and 2.218.2.9 are still broken, as
>described on this list.  
>
>In case it's not clear, you go through an entire download, and the last
>thing to be downloaded reports "Download Incomplete" on a popup, and as
>far as I can see, you can never correctly install Cygwin.  Like other
>correspondents, I've tried several combinations of mirrors and download
>styles, and none of them seem to work correctly or completely or at
>least without very alarming sounding error messages.  Beats me whether
>the post-install script works or not.
>
>If you're going to work on this, could you leave a working version in
>place while you do so, and try it before posting it?  Thanks.

The current version is working for me and a number of other people.

Don't know how you missed this...

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: setup.exe 2.218.2.8/9 broken

[Charles Wilson]

John Haggerty wrote:

> 
> If you're going to work on this, could you leave a working version in
> place while you do so, and try it before posting it?  Thanks.
> 

Long story:

(1)
In order to allow HEAD testing to go forward with md5sums, there was a 
minor change to the 'stable release' of setup.exe (and to the setup.ini 
format and to the upset script that generates setup.ini) to
   a) put md5sums for each tarball into setup.ini
   b) make the current setup.exe not barf when it saw them

This was a simple change, and was uploaded with little testing or 
fanfare.  BUT, since setup.ini's format changed, it broke all older 
setup.exe's.  This forced everybody to use the most recent 'stable 
release' of setup.exe; many people had been 'hanging back' with old 
obsolete versions.  Perhaps this was impolite of us (and it wasn't 
intended as a "we're gonna force everyone to always ride the bleeding 
edge" thing) -- but it ended up having exactly that effect.

As it happened, the 'most recent stable release' of setup.exe (non-HEAD) 
was teetering on the edge of a number of bugs...and the wider (forced) 
testing made those bugs visible.

(2) bug #1: we ran out of parser stack space when all the new XFree86 
packages were added to the distribution.  This was the source of most of 
the problems over the last week.  Too many packages in setup.ini + not 
enough stack space + RHS recursion(?) == the lex setup.ini parser barfed.

(3) bug #2: minor issues with parsing "buried" setup.ini files -- that 
belong to things NOT cygwin-setup.exe-related.  This happens only when 
someone says "My local setup directory is HERE" when HERE has 
subdirectories that don't belong to cygwin-setup.  (That's bad, don't do 
that: setup's 'local directory' is his own personal playground and he 
doesn't play well with others)
   This is what happens when user-error meets bad filename parsing...and 
since the userbase of the 'most recent stable release' of setup.exe 
expanded drastically overnight, we got hit with lots of reports about 
this problem.

Normally, it is Robert and Chris's policy that unstable development of 
setup.exe happens on the HEAD branch (currently 2.A, A > 218).  Bugfixes 
for the officially released setup.exe happens on a side branch (in this 
case, 2.218.2.X).  Unfortunately, a confluence of events, plus an 
accomodation for HEAD's setup.ini format change, led to serious 
instability in the "stable release" of setup.exe for a while.

Hopefully things are better now...just think of setup-2.218.2.X as linux 
kernel 2.4.X, where X < 9...

--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: setup.exe 2.218.2.8/9 broken

[Alan Dobkin]

Chuck,

Thanks for the excellent summary of events.  I too was wondering 
what happened, since this is the first time I've seen the setup 
program so unstable and re-released so often.  Your explanation 
clears it all up for me now.

Also, FWIW, my problems with setup.exe are all gone now since 
.2.8, and in fact I can finally build from the source now with 
a simple ./configure && make.

Thanks,
Alan

On Thu, 16 May 2002, Charles Wilson wrote:

> John Haggerty wrote:
> 
> > If you're going to work on this, could you leave a working version 
> > in place while you do so, and try it before posting it?  Thanks.
> 
> Long story:
> 
> ...


--
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: setup.exe 2.218.2.8/9 broken

[John Haggerty]

Thanks for the explanation; I won't send my laptop back yet, although
I'm still having problems with "Download Incomplete Retry?" with
2.218.2.9, but by now, I may have screwed up something else (like maybe
HOME has gotten undefined, or such) since I have been installed and
uninstalled maybe 25 times.  I'd send the log file, but I have to get
ssh working first... it's not very illuminating for me.

I have been doing an "All Install," perhaps that still breaks the setup?

Charles Wilson wrote:
> 
> John Haggerty wrote:
> 
> >
> > If you're going to work on this, could you leave a working version in
> > place while you do so, and try it before posting it?  Thanks.
> >
> 
> Long story:
> 
> (1)
> In order to allow HEAD testing to go forward with md5sums, there was a
> minor change to the 'stable release' of setup.exe (and to the setup.ini
> format and to the upset script that generates setup.ini) to
>    a) put md5sums for each tarball into setup.ini
>    b) make the current setup.exe not barf when it saw them
> 
> This was a simple change, and was uploaded with little testing or
> fanfare.  BUT, since setup.ini's format changed, it broke all older
> setup.exe's.  This forced everybody to use the most recent 'stable
> release' of setup.exe; many people had been 'hanging back' with old
> obsolete versions.  Perhaps this was impolite of us (and it wasn't
> intended as a "we're gonna force everyone to always ride the bleeding
> edge" thing) -- but it ended up having exactly that effect.
> 
> As it happened, the 'most recent stable release' of setup.exe (non-HEAD)
> was teetering on the edge of a number of bugs...and the wider (forced)
> testing made those bugs visible.
> 
> (2) bug #1: we ran out of parser stack space when all the new XFree86
> packages were added to the distribution.  This was the source of most of
> the problems over the last week.  Too many packages in setup.ini + not
> enough stack space + RHS recursion(?) == the lex setup.ini parser barfed.
> 
> (3) bug #2: minor issues with parsing "buried" setup.ini files -- that
> belong to things NOT cygwin-setup.exe-related.  This happens only when
> someone says "My local setup directory is HERE" when HERE has
> subdirectories that don't belong to cygwin-setup.  (That's bad, don't do
> that: setup's 'local directory' is his own personal playground and he
> doesn't play well with others)
>    This is what happens when user-error meets bad filename parsing...and
> since the userbase of the 'most recent stable release' of setup.exe
> expanded drastically overnight, we got hit with lots of reports about
> this problem.
> 
> Normally, it is Robert and Chris's policy that unstable development of
> setup.exe happens on the HEAD branch (currently 2.A, A > 218).  Bugfixes
> for the officially released setup.exe happens on a side branch (in this
> case, 2.218.2.X).  Unfortunately, a confluence of events, plus an
> accomodation for HEAD's setup.ini format change, led to serious
> instability in the "stable release" of setup.exe for a while.
> 
> Hopefully things are better now...just think of setup-2.218.2.X as linux
> kernel 2.4.X, where X < 9...
> 
> --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/

-- 
John Haggerty
internet: haggerty@bnl.gov
voice/fax: 631 344 2286/4592
http://www.phenix.bnl.gov/~haggerty

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