[Patch] Setup: Warn about dropped mirrors. (was: Re: Multiple pending setup patches)

[Bas van Gompel]

Op Wed, 19 Oct 2005 17:17:15 -0400 (EDT) schreef Igor Pechtchanski
in slinky.cs.nyu.edu>:
:  On Tue, 18 Oct 2005, Bas Buzz van Gompel wrote:
:
: > Op Tue, 18 Oct 2005 01:35:12 -0400 (EDT) schreef Igor Pechtchanski:
: > :  On Tue, 18 Oct 2005, Buzz wrote:
: >
: > : > Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski:
: > [Mirror manually added or stale.]

: > :  b) the cached mirror-list is overwritten every time a successful
: > :  connection is established with sourceware.org,
: >
: > That could change. (Or the stale mirrors might get appended.)
:
:  SHTDI.  PTC.

I did. I took this approach.

[...]
: > If there's interest, I'm willing to look into the source. (It may take
: > me a while. The last time I looked at it is way back.)
:
:  There's always interest for setup improvements.  But, as I said before,
:  I've given it some thought, and it's my opinion that this information
:  belongs in last-mirror rather than mirror-list.  You are, of course,
:  welcome to take any approach you deem necessary.

I didn't add the info to last-mirror, because that would make for more
needlesly complicated code (IMO). I do add a comment to the newly
written mirrors-lst file, though.


ChangeLog-entry: (please fix the .)

2005-11-02  Bas van Gompel  bavag.tmfweb.nl>

* res.rc (IDD_DROPPED): New dialog.
* resource.h (IDD_DROPPED): New dialog-id.
(IDC_DROP_MIRRORS, IDC_DROP_NOWARN): New control-ids.
* site.cc (site_list_type::init, site_list_type::site_list_type):
Change to four parameter form.
(load_site_list): New function, broken out of get_site_list.
Support four-parameter site_list_type.
(get_site_list): Break out load_site_list. Move reading cache
forward. Don't write new cache. Set flags to record cache state.
Load both all_site_list and cached_site_list.
(SiteSetting::registerSavedSite): Use four-parameter site_list_type.
(drop_proc, check_dropped_mirrors, save_cache_file): New functions.
(SitePage::OnNext): Check for dropped mirrors and save cache as
appropriate.
* site.h (site_list_type::init, site_list_type::site_list_type):
Change to four parameter form.
(site_list_type): Add servername, continent and location members.


Index: setup/res.rc
===
RCS file: /cvs/cygwin-apps/setup/res.rc,v
retrieving revision 2.67
diff -u -p -r2.67 res.rc
--- setup/res.rc9 Sep 2005 19:52:51 -   2.67
+++ setup/res.rc2 Nov 2005 20:10:16 -
@@ -356,6 +356,32 @@ BEGIN
 
 END
 
+IDD_DROPPED DIALOG DISCARDABLE  0, 0, 317, 142
+STYLE DS_MODALFRAME | DS_CENTER | WS_POPUP | WS_CAPTION | WS_SYSMENU
+CAPTION "Cygwin Setup - Use dropped mirrors?"
+FONT 8, "MS Shell Dlg"
+BEGIN
+LTEXT   "Warning:",IDC_STATIC,7,8,40,8
+LTEXT   "One or more mirrors you have selected is/are not on the"
+"list of official Cygwin mirrors any more. "
+"It/They may be out of date or missing some packages.\n"
+"This affects the following mirror(s):",
+IDC_STATIC,47,8,263,32
+EDITTEXTIDC_DROP_MIRRORS,7,40,303,40,WS_VSCROLL | WS_HSCROLL |
+ES_LEFT | ES_MULTILINE | ES_READONLY | ES_AUTOHSCROLL |
+ES_AUTOVSCROLL
+LTEXT   "If you experience installation problems consider trying "
+"official mirrors only.\n\n"
+"Do you want to continue, using this/these mirror(s)?",
+IDC_STATIC,7,88,303,24
+CONTROL "&Don't warn me about this/these mirror(s) again",
+IDC_DROP_NOWARN,"Button",BS_AUTOCHECKBOX | WS_TABSTOP,
+7,120,213,15
+PUSHBUTTON  "&Yes",IDYES,220,120,45,15
+DEFPUSHBUTTON   "&No",IDNO,265,120,45,15
+
+END
+
 /
 //
 // Manifest
Index: setup/resource.h
===
RCS file: /cvs/cygwin-apps/setup/resource.h,v
retrieving revision 2.32
diff -u -p -r2.32 resource.h
--- setup/resource.h9 Sep 2005 19:52:51 -   2.32
+++ setup/resource.h2 Nov 2005 20:10:17 -
@@ -55,6 +55,7 @@
 #define IDD_VIRUS 218
 #define IDD_DESKTOP   219
 #define IDD_PREREQ220
+#define IDD_DROPPED   221
 
 // Bitmaps
 
@@ -152,3 +153,5 @@
 #define IDC_PREREQ_TEXT   576
 #define IDC_PREREQ_EDIT   577
 #define IDC_PREREQ_CHECK  578
+#define IDC_DROP_MIRRORS  579
+#define IDC_DROP_NOWARN   580
Index: setup/site.cc
===
RCS file: /cvs/cygwin-apps/setup/site.cc,v
retrieving revision 2.40
diff -u -p -r2.40 site.cc
--- 

RE: Multiple pending setup patches

[Jan Schormann]

On Friday, October 14, 2005 Igor wrote:

> > On Oct 14 03:30, Brian Dessent wrote:
> > > 
> > > What I had in mind was something like this:
> > > 
> > > -
> > > Warning: The mirror you have selected is not on the list
> > >  of official Cygwin mirrors.  It may be out of date
> > >  or missing some packages.  If you experience
> > >  installation problems consider trying an official   
> > > mirror. 
> > > 
> > >  [X]   Don't show this again
> > > 
> > > [ OK ]
> > > -
> 
> FWIW, I was thinking more of a command-line option to turn it off,
> rather than a user-changeable setting...
>   Igor

*Please* provide a command-line switch. We're using a local, modified
mirror for unattended installations here ...

Thanks for everything,
Jan.

Re: Multiple pending setup patches

[Igor Pechtchanski]

On Tue, 18 Oct 2005, Bas Buzz van Gompel wrote:

> Op Tue, 18 Oct 2005 01:35:12 -0400 (EDT) schreef Igor Pechtchanski:
> :  On Tue, 18 Oct 2005, Buzz wrote:
>
> : > Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski:
> [Mirror manually added or stale.]
>
> : > :  You are assuming that the format of the last-mirror file is fixed and
> : > :  won't change.  We could keep the fact that the user typed in the mirror
> : > :  URL as opposed to clicking on one of the official ones...
> : > : Igor
>
> : > Would it not be possible to use the cached mirror-list to
> : > differentiate the two cases? (Only warn if a mirror is used which is
> : > in cache but not in new list. Keep the old mirror in the cache if
> : > the user wants to be warned again.)
>
> : > (I know, SHTDI.)
>
> :  a) the cached mirror-list was only introduced recently,
>
> I suggest using it. Your point?

That's one of the reasons it hasn't been done yet.

> :  b) the cached mirror-list is overwritten every time a successful
> :  connection is established with sourceware.org,
>
> That could change. (Or the stale mirrors might get appended.)

SHTDI.  PTC.

> :  c) this kind of information belongs in last-mirror, IMO, and
>
> That is also an option. Adding a ``stale''-flag there, if the user
> wants to be warned again, should work.
>
> Still, one could use the cached mirror-list to determine when an
> official mirror went stale since last connection.

SHTDI.  PTC.

> :  d) you said it: SHTDI.
>
> If there's interest, I'm willing to look into the source. (It may take
> me a while. The last time I looked at it is way back.)

There's always interest for setup improvements.  But, as I said before,
I've given it some thought, and it's my opinion that this information
belongs in last-mirror rather than mirror-list.  You are, of course,
welcome to take any approach you deem necessary.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

Re: Multiple pending setup patches

[Buzz]

Op Tue, 18 Oct 2005 01:35:12 -0400 (EDT) schreef Igor Pechtchanski
in <[EMAIL PROTECTED]>:
:  On Tue, 18 Oct 2005, Buzz wrote:

: > Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski:
[Mirror manually added or stale.]

: > :  You are assuming that the format of the last-mirror file is fixed and
: > :  won't change.  We could keep the fact that the user typed in the mirror
: > :  URL as opposed to clicking on one of the official ones...
: > :   Igor

: > Would it not be possible to use the cached mirror-list to
: > differentiate the two cases? (Only warn if a mirror is used which is
: > in cache but not in new list. Keep the old mirror in the cache if
: > the user wants to be warned again.)

: > (I know, SHTDI.)

:  a) the cached mirror-list was only introduced recently,

I suggest using it. Your point?

:  b) the cached mirror-list is overwritten every time a successful
:  connection is established with sourceware.org,

That could change. (Or the stale mirrors might get appended.)

:  c) this kind of information belongs in last-mirror, IMO, and

That is also an option. Adding a ``stale''-flag there, if the user
wants to be warned again, should work.

Still, one could use the cached mirror-list to determine when an
official mirror went stale since last connection.

:  d) you said it: SHTDI.

If there's interest, I'm willing to look into the source. (It may take
me a while. The last time I looked at it is way back.)


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   //   really is |   and false bits entirely.| mail for
  ) |  |  //a 72 by 4 +---+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."| me. 4^re

Re: Multiple pending setup patches

[Igor Pechtchanski]

On Tue, 18 Oct 2005, Buzz wrote:

> Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski:
> :  On Fri, 14 Oct 2005, Brian Dessent wrote:
> :
> : > Brian Dessent wrote:
> : >
> : >> Except, from the standpoint of setup there is no way to distinguish the
> : >> following two scenarios:
> : >
> : > That is, unless you meant "mirror that was manually added *this
> : > session*", whereas I was interpreting it to be "user manually entered a
> : > non-official mirror at some point in the past and continues to use it
> : > each time they run setup."  So we could in fact detect if the user typed
> : > or pasted something into the edit box and not prompt; but if they then
> : > ran setup again and didn't make any changes they would get the prompt
> : > because at that point setup cannot differentiate anymore.
> :
> :  Brian,
> :
> :  You are assuming that the format of the last-mirror file is fixed and
> :  won't change.  We could keep the fact that the user typed in the mirror
> :  URL as opposed to clicking on one of the official ones...
> : Igor
>
> Would it not be possible to use the cached mirror-list to
> differentiate the two cases? (Only warn if a mirror is used which is
> in cache but not in new list. Keep the old mirror in the cache if
> the user wants to be warned again.)
>
> (I know, SHTDI.)

a) the cached mirror-list was only introduced recently,
b) the cached mirror-list is overwritten every time a successful
connection is established with sourceware.org,
c) this kind of information belongs in last-mirror, IMO, and
d) you said it: SHTDI.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

Re: Multiple pending setup patches

[Buzz]

Op Sun, 16 Oct 2005 17:30:34 -0400 (EDT) schreef Igor Pechtchanski
in <[EMAIL PROTECTED]>:
:  On Fri, 14 Oct 2005, Brian Dessent wrote:
:
: > Brian Dessent wrote:
: >
: >> Except, from the standpoint of setup there is no way to distinguish the
: >> following two scenarios:
: >
: > That is, unless you meant "mirror that was manually added *this
: > session*", whereas I was interpreting it to be "user manually entered a
: > non-official mirror at some point in the past and continues to use it
: > each time they run setup."  So we could in fact detect if the user typed
: > or pasted something into the edit box and not prompt; but if they then
: > ran setup again and didn't make any changes they would get the prompt
: > because at that point setup cannot differentiate anymore.
:
:  Brian,
:
:  You are assuming that the format of the last-mirror file is fixed and
:  won't change.  We could keep the fact that the user typed in the mirror
:  URL as opposed to clicking on one of the official ones...
:   Igor

Would it not be possible to use the cached mirror-list to
differentiate the two cases? (Only warn if a mirror is used which is
in cache but not in new list. Keep the old mirror in the cache if
the user wants to be warned again.)

(I know, SHTDI.)


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   //   really is |   and false bits entirely.| mail for
  ) |  |  //a 72 by 4 +---+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."| me. 4^re

RE: Multiple pending setup patches

[Robb, Sam]

> > I'm thinking an asterisk after the name (with
> > dialog text explaining its meaning), since using color 
> becomes confusing
> > when you also have the selected/not-selected color distinction.
> 
> If the warning color were red, you could make the selected 
> color white 
> on red instead of the Windows default.
> 
> The best reason I can think of to avoid using color is that you'd 
> probably have to write a custom paint routine.  That's a bit of work. 
> If you choose this path, something more obvious than an 
> asterisk would 
> be better.  For instance, prefix it with "NON-OFFICIAL: ".

Not to mention that using color to indicate state makes things
harder on those individuals who are color blind, or who depend
on using a screen reader to access GUI apps like setup.exe.

There was some discussion about setup.exe and screen readers a
while back.  I can't find anything to say otherwise, but it seems
as if the setup developers (Igor, in particular) were trying to
correct "features" in setup.exe that made it difficult to use
with screen readers.  It would be kind of silly to update the
package selection mechanism to be screen-reader friendly while
introducing another feature that wasn't.

-Samrobb
 

Re: Multiple pending setup patches

[Igor Pechtchanski]

On Fri, 14 Oct 2005, Brian Dessent wrote:

> Brian Dessent wrote:
>
> > Except, from the standpoint of setup there is no way to distinguish the
> > following two scenarios:
>
> That is, unless you meant "mirror that was manually added *this
> session*", whereas I was interpreting it to be "user manually entered a
> non-official mirror at some point in the past and continues to use it
> each time they run setup."  So we could in fact detect if the user typed
> or pasted something into the edit box and not prompt; but if they then
> ran setup again and didn't make any changes they would get the prompt
> because at that point setup cannot differentiate anymore.

Brian,

You are assuming that the format of the last-mirror file is fixed and
won't change.  We could keep the fact that the user typed in the mirror
URL as opposed to clicking on one of the official ones...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

Re: Multiple pending setup patches

[Warren Young]

Brian Dessent wrote:

There can be
at most only one mirror URL in the dialog that is not official: 


Ah.  I didn't know that limitation.


I'm thinking an asterisk after the name (with
dialog text explaining its meaning), since using color becomes confusing
when you also have the selected/not-selected color distinction.


If the warning color were red, you could make the selected color white 
on red instead of the Windows default.


The best reason I can think of to avoid using color is that you'd 
probably have to write a custom paint routine.  That's a bit of work. 
If you choose this path, something more obvious than an asterisk would 
be better.  For instance, prefix it with "NON-OFFICIAL: ".

Re: Multiple pending setup patches

[Brian Dessent]

Warren Young wrote:

> The the mirror list could show nonstandard mirrors in a different color.

But every mirror in the mirrors.lst is an official mirror.  There can be
at most only one mirror URL in the dialog that is not official: the one
that the user has just typed in, or the one that was used the last time
setup was run.  Since that URL is selected by default, it's already in a
different color than the rest.

But I do see your point.  I'm now thinking maybe setup could do
something similar -- I'm thinking an asterisk after the name (with
dialog text explaining its meaning), since using color becomes confusing
when you also have the selected/not-selected color distinction.

Brian

Re: Multiple pending setup patches

[Warren Young]

Brian Dessent wrote:

Except, from the standpoint of setup there is no way to distinguish the
following two scenarios:

A) User knowingly uses local company mirror, or uses a non-official
mirror to install non-official packages.

B) 2 years ago, user chose a mirror located on a ISDN line in Outer
Mongolia that was current at the time, but which later stopped mirroring


The the mirror list could show nonstandard mirrors in a different color.

For case A, this would visually indicate that it isn't an official 
mirror, and you use it at your own risk.


For case B, what you'd see is that suddenly your default mirror changes 
color.  Then if they complain on the mailing list, the first question 
would be "did your mirror turn red?" (to pick a random color).


This could be done either along with Chris's "don't bug me again" dialog 
box, or without it.


One problem with the dialog box alone is that someone could click the 
"don't bug me" box without really thinking about the message.  Then 6 
months later when their out-of-date mirror starts causing serious 
problems for them, they've forgotten about the choice they made, and 
post to the list.  Having a continuing indication that they're using a 
nonstandard mirror would ameliorate this.


If you do add Chris's dialog box, it needs to be a per-connection 
setting.  The user's willingness to tolerate one nonstandard mirror 
doesn't imply that they don't care about this status for all of them.  I 
can imagine a person having one nonstandard mirror who also uses other 
official mirrors from time to time for various purposes.  The most 
common case would be having a package-specific mirror, plus a favorite 
mirror for Cygwin itself.  If their favorite official Cygwin mirror gets 
dropped from the list, setup.exe should still tell them about it, even 
though they once told it to ignore another nonstandard mirror.

Re: Multiple pending setup patches

[David Rothenberger]

On 10/14/2005 5:15 PM, Brian Dessent wrote:

I like the idea of "Don't show this again" option because it's a
standard dialog item that people are familiar with, and it makes it easy
for them to acknowledge that they might be doing something wrong but
they don't want to be pestered about it every time they run setup.  But
I'll also add a commandline switch.


Could the dialog list the mirror(s) that are not on the official list?

I have an official mirror select as well as my own repository for 
locally-patched packages. Thus, I will always get this dialog. It would 
be nice if I could tell from the dialog whether it's complaining just 
about my own repository or also about the official mirror.


--
David Rothenbergerspammer? -> [EMAIL PROTECTED]
GPG/PGP: 0x7F67E734, C233 365A 25EF 2C5F C8E1 43DF B44F BA26 7F67 E734

The days are all empty and the nights are unreal.

Re: Multiple pending setup patches

[Brian Dessent]

Brian Dessent wrote:

> Except, from the standpoint of setup there is no way to distinguish the
> following two scenarios:

That is, unless you meant "mirror that was manually added *this
session*", whereas I was interpreting it to be "user manually entered a
non-official mirror at some point in the past and continues to use it
each time they run setup."  So we could in fact detect if the user typed
or pasted something into the edit box and not prompt; but if they then
ran setup again and didn't make any changes they would get the prompt
because at that point setup cannot differentiate anymore.

Brian

Re: Multiple pending setup patches

[Brian Dessent]

Corinna Vinschen wrote:

> To reiterate, I think that it makes sense to differ between a
> *manually added* mirror and a chosen mirror from the official mirror
> list, which is just dead or comatose or something.
> 
> Manually added mirrors are usually either company mirrors or in some
> other way under control of the user so there should be no need to
> hint the user that a manually added mirror is not in the list of
> official mirrors.
> 
> This is pretty different from the situation which the above dialog would
> be about to solve or soothe.  Just an extra single bit of information
> would help a lot.
> 
> Except for the manually added mirror situation, I'm all for the dialog
> and/or a CLI switch.

Except, from the standpoint of setup there is no way to distinguish the
following two scenarios:

A) User knowingly uses local company mirror, or uses a non-official
mirror to install non-official packages.

B) 2 years ago, user chose a mirror located on a ISDN line in Outer
Mongolia that was current at the time, but which later stopped mirroring
cygwin.com and was removed from mirrors.lst.  But because setup
remembers the last used mirror, it's still in the list as the default
selection and the user just keeps on trying to use it because he just
presses Next each time.

In either case, setup has no way of knowing the intent.  A manually
added mirror looks just the same as one that was once on the official
list but no longer is.

I like the idea of "Don't show this again" option because it's a
standard dialog item that people are familiar with, and it makes it easy
for them to acknowledge that they might be doing something wrong but
they don't want to be pestered about it every time they run setup.  But
I'll also add a commandline switch.

Brian

Re: Multiple pending setup patches

[Corinna Vinschen]

On Oct 14 10:44, Christopher Faylor wrote:
> On Fri, Oct 14, 2005 at 09:19:01AM -0400, Igor Pechtchanski wrote:
> >On Fri, 14 Oct 2005, Corinna Vinschen wrote:
> >> On Oct 14 03:30, Brian Dessent wrote:
> >> > Corinna Vinschen wrote:
> >> > > > I suppose that this would have to be defeatable for people who want 
> >> > > > to
> >> > > > use setup.exe for in-house mirrors but I'm not too worried about 
> >> > > > that.
> >> > >
> >> > > Ouch, I am.  It should be possible to switch this off, or setup should
> >> > > differ between a mirror from the list, which just isn't available right
> >> > > now, and a mirror which has been added manually.
> >> >
> >> > What I had in mind was something like this:
> >> >
> >> > -
> >> > Warning: The mirror you have selected is not on the list
> >> >  of official Cygwin mirrors.  It may be out of date
> >> >  or missing some packages.  If you experience
> >> >  installation problems consider trying an official
> >> >  mirror.
> >> >
> >> >  [X]   Don't show this again
> >> >
> >> > [ OK ]
> >> > -
> >>
> >> That's it.
> >
> >FWIW, I was thinking more of a command-line option to turn it off, rather
> >than a user-changeable setting...
> 
> Maybe both would be needed.  I like the "Don't show this again" part of the
> option.
> 
> IMO, this "out of date mirror" problem is probably percolating to the top of
> the apparent bugs that people see in setup.exe.

It just occured to me that my reply was a bit too relaxed.

To reiterate, I think that it makes sense to differ between a
*manually added* mirror and a chosen mirror from the official mirror
list, which is just dead or comatose or something.

Manually added mirrors are usually either company mirrors or in some
other way under control of the user so there should be no need to
hint the user that a manually added mirror is not in the list of
official mirrors.

This is pretty different from the situation which the above dialog would
be about to solve or soothe.  Just an extra single bit of information
would help a lot.

Except for the manually added mirror situation, I'm all for the dialog
and/or a CLI switch.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

Re: Multiple pending setup patches

[Christopher Faylor]

On Fri, Oct 14, 2005 at 09:19:01AM -0400, Igor Pechtchanski wrote:
>On Fri, 14 Oct 2005, Corinna Vinschen wrote:
>
>> On Oct 14 03:30, Brian Dessent wrote:
>> > Corinna Vinschen wrote:
>> >
>> > > > Is there any way that my proposal of adding a check to see if the 
>> > > > currently
>> > > > selected mirror is in the list of mirrors and issuing a pop-up warning 
>> > > > if
>> > > > not, could be implemented?
>> > > >
>> > > > I suppose that this would have to be defeatable for people who want to
>> > > > use setup.exe for in-house mirrors but I'm not too worried about that.
>> > >
>> > > Ouch, I am.  It should be possible to switch this off, or setup should
>> > > differ between a mirror from the list, which just isn't available right
>> > > now, and a mirror which has been added manually.
>> >
>> > What I had in mind was something like this:
>> >
>> > -
>> > Warning: The mirror you have selected is not on the list
>> >  of official Cygwin mirrors.  It may be out of date
>> >  or missing some packages.  If you experience
>> >  installation problems consider trying an official
>> >  mirror.
>> >
>> >  [X]   Don't show this again
>> >
>> > [ OK ]
>> > -
>>
>> That's it.
>
>FWIW, I was thinking more of a command-line option to turn it off, rather
>than a user-changeable setting...

Maybe both would be needed.  I like the "Don't show this again" part of the
option.

IMO, this "out of date mirror" problem is probably percolating to the top of
the apparent bugs that people see in setup.exe.

cgf

Re: Multiple pending setup patches

[Igor Pechtchanski]

On Fri, 14 Oct 2005, Corinna Vinschen wrote:

> On Oct 14 03:30, Brian Dessent wrote:
> > Corinna Vinschen wrote:
> >
> > > > Is there any way that my proposal of adding a check to see if the 
> > > > currently
> > > > selected mirror is in the list of mirrors and issuing a pop-up warning 
> > > > if
> > > > not, could be implemented?
> > > >
> > > > I suppose that this would have to be defeatable for people who want to
> > > > use setup.exe for in-house mirrors but I'm not too worried about that.
> > >
> > > Ouch, I am.  It should be possible to switch this off, or setup should
> > > differ between a mirror from the list, which just isn't available right
> > > now, and a mirror which has been added manually.
> >
> > What I had in mind was something like this:
> >
> > -
> > Warning: The mirror you have selected is not on the list
> >  of official Cygwin mirrors.  It may be out of date
> >  or missing some packages.  If you experience
> >  installation problems consider trying an official
> >  mirror.
> >
> >  [X]   Don't show this again
> >
> > [ OK ]
> > -
>
> That's it.

FWIW, I was thinking more of a command-line option to turn it off, rather
than a user-changeable setting...
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

Re: Multiple pending setup patches

[Igor Pechtchanski]

On Thu, 13 Oct 2005, Brian Dessent wrote:

> Igor Pechtchanski wrote:
>
> > Technically, these packages *do* require bash, and coreutils, and possibly
> > others, so automatic dependency detection is hard (we don't want to have
> > setup parse shell scripts).  Perhaps we should augment the "depends"
> > function of the g-b-s to also look at the postinstall script and find
> > packages for all commands invoked in it?
>
> Well hopefully, most (or all) of the coreutils commands will be plain
> binaries in /usr/bin, and not hard links or anything that requires
> fiddling from a postinstall.  In other words, coreutils should be
> functional as soon as it's unpacked, so it doesn't really matter if
> package foo runs its postinstall before coreutils.  In fact it doesn't
> even look like coreutils currently has a postinstall.

Right.  But it may later.  Some other things used in postinstall may
already have their own postinstall scripts.  If we don't get the
dependencies correct now, it might make it harder in the future.

> Even still, because of the fact that it's in many "requires" lists
> coreutils is going to always be near the top of the "dependency sorted
> order list" anyway.  I have a feeling that bash and coreutils will tend
> to "bubble up" to the top of it regardless, even if there are some cases
> where the explicit dependency in some packages is not spelled out.

That is certainly true.  Perhaps we ought to have setup add both bash and
coreutils to dependencies of packages with postinstalls...  But then, what
about sed, or tar?

> > * io_stream.cc (io_stream::open): Better log message on error.
> > (io_stream::mkpath_p,io_stream::remove,io_stream::mklink): Ditto.
> > (io_stream::move,io_stream::exists): Ditto.
>
> Looks fine, go ahead.  Better error messages are alwasy good.  :-)
> Though I wonder if all those repeated throws should be a macro or inline
> instead...

Makes sense.  I've committed a variant that uses a macro.
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DA

RE: Multiple pending setup patches

[Morrison, John]

> From: Corinna Vinschen [mailto:[EMAIL PROTECTED]
> On Oct 14 03:30, Brian Dessent wrote:
> > Corinna Vinschen wrote:
> > 
> > > > Is there any way that my proposal of adding a check to see if the
currently
> > > > selected mirror is in the list of mirrors and issuing a pop-up
warning if
> > > > not, could be implemented?
> > > >
> > > > I suppose that this would have to be defeatable for people who want
to
> > > > use setup.exe for in-house mirrors but I'm not too worried about
that.
> > > 
> > > Ouch, I am.  It should be possible to switch this off, or setup should
> > > differ between a mirror from the list, which just isn't available
right
> > > now, and a mirror which has been added manually.
> > 
> > What I had in mind was something like this:
> > 
> > -
> > Warning: The mirror you have selected is not on the list
> >  of official Cygwin mirrors.  It may be out of date
> >  or missing some packages.  If you experience
> >  installation problems consider trying an official
> >  mirror.
> > 
> >  [X]   Don't show this again
> > 
> > [ OK ]
> > -
> 
> That's it.

How about highlighting them in a different colour in the "Available
Downloads
Site" list box? (I know you shouldn't rely on colour to indicate things, but
in
addition to that message...)

Oh.  How do you switch the message back on?  How about a switch/button
underneath the user url to either list the user urls or enable the message
again?

J.



==
Information in this e-mail and any attachments are confidential, and may not be 
copied or used by anyone other than the addressee, nor disclosed to any third 
party without our permission. There is no intention to create any legally 
binding contract or other binding commitment through the use of this electronic 
communication unless it is issued in accordance with the Experian Limited 
standard terms and conditions of purchase or other express written agreement 
between Experian Limited and the recipient Experian Limited (registration 
number 653331) Registered office: Talbot House, Talbot Street, Nottingham NG80 
1TH

Although Experian has taken reasonable steps to ensure that this communication 
and any attachments are free from computer virus, you are advised to take your 
own steps to ensure that they are actually virus free.

Re: Multiple pending setup patches

[Corinna Vinschen]

On Oct 14 03:30, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > > Is there any way that my proposal of adding a check to see if the 
> > > currently
> > > selected mirror is in the list of mirrors and issuing a pop-up warning if
> > > not, could be implemented?
> > >
> > > I suppose that this would have to be defeatable for people who want to
> > > use setup.exe for in-house mirrors but I'm not too worried about that.
> > 
> > Ouch, I am.  It should be possible to switch this off, or setup should
> > differ between a mirror from the list, which just isn't available right
> > now, and a mirror which has been added manually.
> 
> What I had in mind was something like this:
> 
> -
> Warning: The mirror you have selected is not on the list
>  of official Cygwin mirrors.  It may be out of date
>  or missing some packages.  If you experience
>  installation problems consider trying an official
>  mirror.
> 
>  [X]   Don't show this again
> 
> [ OK ]
> -

That's it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

Re: Multiple pending setup patches

[Brian Dessent]

Corinna Vinschen wrote:

> > Is there any way that my proposal of adding a check to see if the currently
> > selected mirror is in the list of mirrors and issuing a pop-up warning if
> > not, could be implemented?
> >
> > I suppose that this would have to be defeatable for people who want to
> > use setup.exe for in-house mirrors but I'm not too worried about that.
> 
> Ouch, I am.  It should be possible to switch this off, or setup should
> differ between a mirror from the list, which just isn't available right
> now, and a mirror which has been added manually.

What I had in mind was something like this:

-
Warning: The mirror you have selected is not on the list
 of official Cygwin mirrors.  It may be out of date
 or missing some packages.  If you experience
 installation problems consider trying an official
 mirror.

 [X]   Don't show this again

[ OK ]
-

Re: Multiple pending setup patches

[Corinna Vinschen]

On Oct 13 22:19, Christopher Faylor wrote:
> Is there any way that my proposal of adding a check to see if the currently
> selected mirror is in the list of mirrors and issuing a pop-up warning if
> not, could be implemented?
> 
> I suppose that this would have to be defeatable for people who want to
> use setup.exe for in-house mirrors but I'm not too worried about that.

Ouch, I am.  It should be possible to switch this off, or setup should
differ between a mirror from the list, which just isn't available right
now, and a mirror which has been added manually.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat, Inc.

Re: Multiple pending setup patches

[Brian Dessent]

Igor Pechtchanski wrote:

> Technically, these packages *do* require bash, and coreutils, and possibly
> others, so automatic dependency detection is hard (we don't want to have
> setup parse shell scripts).  Perhaps we should augment the "depends"
> function of the g-b-s to also look at the postinstall script and find
> packages for all commands invoked in it?

Well hopefully, most (or all) of the coreutils commands will be plain
binaries in /usr/bin, and not hard links or anything that requires
fiddling from a postinstall.  In other words, coreutils should be
functional as soon as it's unpacked, so it doesn't really matter if
package foo runs its postinstall before coreutils.  In fact it doesn't
even look like coreutils currently has a postinstall.

Even still, because of the fact that it's in many "requires" lists
coreutils is going to always be near the top of the "dependency sorted
order list" anyway.  I have a feeling that bash and coreutils will tend
to "bubble up" to the top of it regardless, even if there are some cases
where the explicit dependency in some packages is not spelled out.

> * io_stream.cc (io_stream::open): Better log message on error.
> (io_stream::mkpath_p,io_stream::remove,io_stream::mklink): Ditto.
> (io_stream::move,io_stream::exists): Ditto.

Looks fine, go ahead.  Better error messages are alwasy good.  :-) 
Though I wonder if all those repeated throws should be a macro or inline
instead...

Brian

Re: Multiple pending setup patches

[Igor Pechtchanski]

On Thu, 13 Oct 2005, Brian Dessent wrote:

> Igor, I'm very thankful to have patches from you, and I appreciate that
> you're contributing.  I seriously need to work on being more timely
> about this.

It's okay, I just wanted to make sure they didn't get lost in the noise...
I've applied the patches.  Actually, one of them turned out to be stale,
as I've added a bit more functionality afterwards and forgot to resubmit
the patch, so I applied a new version, since the change was minor.

> > 
> > (GTG: )
>
> I suppose this is OK too.  The only reservation I have is that it
> imposes a new requirement on all package maintainers: that if your
> package contains a postinstall script you must include bash in the
> "requires" line.  That is something that I think many packagers will get
> wrong.  It's non-obvious because both bash and ash are in category Base
> and can be assumed to exist on any system.  It might be better if setup
> could figure this out on its own -- when unpacking the package if it
> sees a .sh file in /etc/postinstall, it should add bash to the
> dependencies if not there already.  But that's probably a bit overkill.

I suppose it's possible to insert a package dependency on bash when any
postinstall script is detected in that package.  This would cause bash to
come first when postinstall scripts are ordered.  But that's not enough --
see below.

> On the other hand, accidently omitting this dependency is probably no
> worse than the current situation where the scripts are run in
> alphabetical filename order.

Agreed.

> So, go ahead.
>
> Maybe we should update the setup.html page to explicitly state this.
> And it would be nice if we could run a quick script against the package
> repository to check if there are currently any packages with postinstall
> scripts that don't have bash on their requires line.

Technically, these packages *do* require bash, and coreutils, and possibly
others, so automatic dependency detection is hard (we don't want to have
setup parse shell scripts).  Perhaps we should augment the "depends"
function of the g-b-s to also look at the postinstall script and find
packages for all commands invoked in it?

> > 
>
> OK.

I have another "error message improvement" patch in my local tree
(attached).  Here's the ChangeLog entry, but I'm hoping I'll be the one
applying the patch if it's approved.  Let me know what you think.

==
2005-10-14  Igor Pechtchanski  <[EMAIL PROTECTED]>

* io_stream.cc (io_stream::open): Better log message on error.
(io_stream::mkpath_p,io_stream::remove,io_stream::mklink): Ditto.
(io_stream::move,io_stream::exists): Ditto.
==

> [snip]
> Go ahead and commit those.  And again, thanks.

You're welcome.

> I have been wanting to release a new setup with these and the other
> minor fixes that have gone into it since the last release.  However,
> there are two things I'd like to resolve first:
>
> 1. This time we should do a release candidate, and advertise its
> availability on the main list.  With the last release there was a whole
> flood of bug reports, which tells me that hardly anyone reads
> cygwin-apps closely enough to tun test releases announced there.

FWIW, I've hosted an alpha version of setup-2.513 on my web site, and had
quite a few downloads (about 20, with no complaints so far).

> 2. I'd like to really fix this "package validation error" thing
> [snip]

Yes, that looks like a tricky one...  Good luck!
Igor
-- 
http://cs.nyu.edu/~pechtcha/
  |\  _,,,---,,_[EMAIL PROTECTED]
ZZZzz /,`.-'`'-.  ;-;;,_[EMAIL PROTECTED]
 |,4-  ) )-,_. ,\ (  `'-'   Igor Pechtchanski, Ph.D.
'---''(_/--'  `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. /DAIndex: io_stream.cc
===
RCS file: /cvs/cygwin-apps/setup/io_stream.cc,v
retrieving revision 2.17
diff -u -p -r2.17 io_stream.cc
--- io_stream.cc5 May 2005 22:48:35 -   2.17
+++ io_stream.cc14 Oct 2005 04:55:53 -
@@ -99,7 +99,8 @@ io_stream::open (String const &name, Str
 {
   IOStreamProvider const *p = findProvider (name);
   if (!p)
-throw new invalid_argument ("URL Scheme not registered!");
+throw new invalid_argument ((String("URL Scheme for '")+
+name+"' not registered!").c_str());
   io_stream *rv = p->open (&name.c_str()[p->key.size()], mode);
   if (!rv->error ())
 return rv;
@@ -112,7 

Re: Multiple pending setup patches

[Christopher Faylor]

On Thu, Oct 13, 2005 at 02:12:14PM -0700, Brian Dessent wrote:
>Igor, I'm very thankful to have patches from you, and I appreciate that
>you're contributing.  I seriously need to work on being more timely
>about this.
>
>Igor Pechtchanski wrote:
>
>> Here's a list of setup patches I submitted in September:
>> 
>> 
>
>This looks OK.  The solution I had in mind was to connect once to get
>the setup.bz2, then disconnect, and create a new connection after
>package selection.  But your method is much simpler.
>
>> 
>> (GTG: )
>
>I suppose this is OK too.  The only reservation I have is that it
>imposes a new requirement on all package maintainers: that if your
>package contains a postinstall script you must include bash in the
>"requires" line.  That is something that I think many packagers will get
>wrong.  It's non-obvious because both bash and ash are in category Base
>and can be assumed to exist on any system.  It might be better if setup
>could figure this out on its own -- when unpacking the package if it
>sees a .sh file in /etc/postinstall, it should add bash to the
>dependencies if not there already.  But that's probably a bit overkill.

I don't think it's overkill at all.  Anything we can do to lighten the
load is good.  It would also be nice to check for #!/bin/sh or #!/bin/bash.

>I have been wanting to release a new setup with these and the other
>minor fixes that have gone into it since the last release.  However,
>there are two things I'd like to resolve first:

Is there any way that my proposal of adding a check to see if the currently
selected mirror is in the list of mirrors and issuing a pop-up warning if
not, could be implemented?

I suppose that this would have to be defeatable for people who want to
use setup.exe for in-house mirrors but I'm not too worried about that.
If people don't like this feature they can build their own version of
setup.exe.

cgf

Re: Multiple pending setup patches

[Brian Dessent]

Brian Dessent wrote:

> Go ahead and commit those.  And again, thanks.

I meant to add:

Please add a couple of lines to the CHANGES file to describe the
bugfixes / new features.  What I'm aiming for here is to have something
that is not as terse as the ChangeLog that summarizes changes in plain
English, which can be copied and pasted into release announcements.  If
we don't keep up with it, then somebody has to go back and sift through
all the commits.  It also makes it easier for someone to quickly look at
CVS and see what has been fixed since the last release.

Brian

Re: Multiple pending setup patches

[Brian Dessent]

Igor, I'm very thankful to have patches from you, and I appreciate that
you're contributing.  I seriously need to work on being more timely
about this.

Igor Pechtchanski wrote:

> Here's a list of setup patches I submitted in September:
> 
> 

This looks OK.  The solution I had in mind was to connect once to get
the setup.bz2, then disconnect, and create a new connection after
package selection.  But your method is much simpler.

> 
> (GTG: )

I suppose this is OK too.  The only reservation I have is that it
imposes a new requirement on all package maintainers: that if your
package contains a postinstall script you must include bash in the
"requires" line.  That is something that I think many packagers will get
wrong.  It's non-obvious because both bash and ash are in category Base
and can be assumed to exist on any system.  It might be better if setup
could figure this out on its own -- when unpacking the package if it
sees a .sh file in /etc/postinstall, it should add bash to the
dependencies if not there already.  But that's probably a bit overkill.

On the other hand, accidently omitting this dependency is probably no
worse than the current situation where the scripts are run in
alphabetical filename order.  So, go ahead.

Maybe we should update the setup.html page to explicitly state this. 
And it would be nice if we could run a quick script against the package
repository to check if there are currently any packages with postinstall
scripts that don't have bash on their requires line.

> 

OK.

> 

OK.

> 

OK.

> Some of them are rather important.  A big collective PING on all of them.

Go ahead and commit those.  And again, thanks.

I have been wanting to release a new setup with these and the other
minor fixes that have gone into it since the last release.  However,
there are two things I'd like to resolve first:

1. This time we should do a release candidate, and advertise its
availability on the main list.  With the last release there was a whole
flood of bug reports, which tells me that hardly anyone reads
cygwin-apps closely enough to tun test releases announced there.

2. I'd like to really fix this "package validation error" thing.  It's
certainly easy enough just to disable the error such that if the size of
the file on disk doesn't match that of setup.ini, it's just silently
ignored.  But since this validation code is used in all the various
install methods, this could also lead to the following scenario: User
selects "install from internet", connection closes early on one package
causing a truncated file, package validation code sees it as invalid and
silently pretends the package isn't there, and that package is simply
not installed.  If that package happened to be something like "cygwin"
or "libintl3" or another package required by many things, it will result
in a very borked installation.  A similar scenario exists if you do
"Download with installing" and then later "Install from local directory"
where one of the packages was truncated during the download phase.  At
some point a package with invalid size needs to either generate an
error, or cause a redownload.

I'm not even sure if the above scenarios are possible, because I haven't
checked.  My point is just that we can't just go disabling checks, we
need to make sure that if packages on disk are borked that we deal with
it in some way that doesn't cause a borked Cygwin installation
afterwards.

Brian