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]

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

[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

[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

[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: Security advisory: uw-imap - 3 attachments

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Christian Weinberger on 10/14/2005 12:26 AM:
> I could not post to the cygwin applications list via gmane, so I reply
> to the main list. Apologies if this not the way it should be done. 

I don't know why cygwin-apps is registered as a one-way only list on
gmane, but I have also found it is annoying that you can't post there
through gmane.  It would take permission from the list owner for gmane to
change the policy on their mirroring of the list (at least gmane still
respects the subscriber-only posting rules).  However, gmane also has the
annoying property of not allowing file attachments, so you really should
be using a proper email client and not gmane when trying to send attachments.

As for you comments about cygwin applications, they really do belong on
cygwin-apps; I've changed the reply-to accordingly.  Also, attachments are
better received if they are MIME attachments, not uuencoded inline; and
with a text MIME type if they really are text based (the number of mail
clients out there that blindly assume every attachment should be marked
application/octet-stream is unfortunate).

> 
> I´d be glad to assist the maintainer in building a 2004g package for
> cygwin. 

There has been no response from the uw-imap maintainer, at least per
http://sources.redhat.com/ml/cygwin-apps/2005-10/msg00111.html.  If you
are volunteering to maintain it, you will need to respond directly on the
cygwin-apps list.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDT7Px84KuGfSFAYARAsZZAKCQv5IVM86s4JG4E/hy31UqsnLc0gCbBjvV
AaOfRhh14DlGRrgHIOR6XYs=
=FgOe
-END PGP SIGNATURE-

Re: [g-b-s patch] Re: Trial plotutils packages again

[Igor Pechtchanski]

On Thu, 13 Oct 2005, Eric Blake wrote:

> According to Igor Pechtchanski on 10/13/2005 5:36 PM:
>
> > Exactly.  So I'm asking again: *is* this the consensus?  If so, I'll
> > remove that section from the readme template.
>
> You've got my vote - I have to edit the readme file for every release to
> give details about the new release, but not worrying about the file list
> will make that a little less painful (even though g-b-s does provide the
> list option).

Someone tried to fix this so that the README was automatically updated
with the file list.  Given that he hasn't completed the task, you're
right.

> > Agreed.  Eric, if you plan to tweak the above patch, you should probably
> > also mention  as the place to get package
> > content listings.
>
> Done as requested, plus a sample generic-setup.hint:
>
> 2005-10-13  Eric Blake  
>
>   * templates/generic-setup.hint: New file.
>   * templates/generic-readme: Add License, Language.  List date
>   when releases are made.  Remove explicit file listing in favor of
>   instructions on how to reproduce it.
>   * templates/generic-build-script: Fix typo when failing.

Applied, with a slight rewording of the package listing section.  Thanks!

BTW, it might be worth mentioning in generic-setup.hint that even though
setup doesn't currently understand the maintainer: field, it would be
worthwhile to update it anyway (i.e., the setup.hint's sent to cygwin-apps
would contain two comments -- the package and the maintainer).
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: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install

[Igor Pechtchanski]

On Mon, 10 Oct 2005, Dr. Volker Zell wrote:

> > Igor Pechtchanski writes:
>
> > On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
> >> @@ -340,6 +349,7 @@
> >> cp $0.sig ${srcinstdir}/ ; \
> >> fi && \
> >> cd ${srcinstdir} && \
> >> +  tar cvjf ${log_pkg_name} *.LOG && rm *.LOG && \
> >> tar cvjf ${src_pkg} * )
> >> }
> >> finish() {
>
> > One small issue here: would it make sense to list the files explicitly for
> > both "tar" and "rm", instead of just using *.LOG?  Suppose the variable
> > values get changed?
>
> > This would, of course, require some rethinking of the variable values
> > (i.e., the explicit path), or we could just change it to
>
> > +  tar cvjf ${log_pkg_name} ${configurelogfile%%${srcinstdir}/} \
> > +   ${makelogfile%%${srcinstdir}/} ${checklogfile%%${srcinstdir}/} \
> > +   ${installlogfile%%${srcinstdir}/} && \
> > +rm *.LOG ${configurelogfile%%${srcinstdir}/} \
> > + ${makelogfile%%${srcinstdir}/} ${checklogfile%%${srcinstdir}/} \
> > + ${installlogfile%%${srcinstdir}/} && \
>
> > (using bash-isms).
>
> > Comments?
>
> No problem, but this time it's your turn :-) This takes way to long.
> Please check in if nobody else objects.

One thing I didn't notice earlier about either this patch or your original
one is that you removed the second "cd $(topdir)" from prep().  I know it
looks superfluous, but it's there for a reason (so that unpack() can
change directory with impunity -- yes, this happened to me before).

Applied, with that one change removed.  Thanks for the patch.  I'll
address the above *.LOG issue shortly.
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: [g-b-s Patch: next try] Write and save logfiles for configure/make/check/install

[Igor Pechtchanski]

On Fri, 14 Oct 2005, Igor Pechtchanski wrote:

> On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
>
> > > Igor Pechtchanski writes:
> >
> > > On Mon, 10 Oct 2005, Dr. Volker Zell wrote:
> > >> @@ -340,6 +349,7 @@
> > >> cp $0.sig ${srcinstdir}/ ; \
> > >> fi && \
> > >> cd ${srcinstdir} && \
> > >> +  tar cvjf ${log_pkg_name} *.LOG && rm *.LOG && \
> > >> tar cvjf ${src_pkg} * )
> > >> }
> > >> finish() {
> >
> > > One small issue here: would it make sense to list the files
> > > explicitly for both "tar" and "rm", instead of just using *.LOG?
> > > Suppose the variable values get changed?

For the record, I've checked in a fix for this.
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

[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: Security advisory: uw-imap - 3 attachments

[Christopher Faylor]

On Fri, Oct 14, 2005 at 07:34:41AM -0600, Eric Blake wrote:
>According to Christian Weinberger on 10/14/2005 12:26 AM:
>>I could not post to the cygwin applications list via gmane, so I reply
>>to the main list.  Apologies if this not the way it should be done.
>
>I don't know why cygwin-apps is registered as a one-way only list on
>gmane, but I have also found it is annoying that you can't post there
>through gmane.

cygwin-apps is a...  wait for it...  mailing list.  It is a *moderated*
mailing list.  It is moderated for a reason.  Having it moderated for
email and not moderated for anyone who figured out how to use gmane has
already been shown to be a bad idea.  I don't want a back door method
for people to send their bug reports and package requests to this list.

cgf

Re: Security advisory: uw-imap - 3 attachments

[Eric Blake]

> 
> cygwin-apps is a...  wait for it...  mailing list.  It is a *moderated*
> mailing list.  It is moderated for a reason.  Having it moderated for
> email and not moderated for anyone who figured out how to use gmane has
> already been shown to be a bad idea.  I don't want a back door method
> for people to send their bug reports and package requests to this list.

But so is cygwin-patches, and gmane *can* post to cygwin-patches!

gmane requires a legitimate email address before posting, and
therefore gmane will not allow an unsubscribe user to post to
a moderated list.  The difference is whether gmane is set up as
a one-way list (as is cygwin-apps) or a moderated list (as is
cygwin-patches).  All I was asking is that gmane be told that
cygwin-apps can be treated like cygwin-patches, instead of
a one-way list.  But I can also live with the status quo, there
is no need to do this just because I asked if you don't want to.

--
Eric Blake

New pstoedit trial packages and a problem

[James R. Phillips]

Package reviewers: New trial packages for pstoedit, linking to the recently
uploaded plotutils package, are on my server:

ftp://antiskid.homelinux.net/pub/pstoedit/pstoedit-3.42-1-src.tar.bz2
ftp://antiskid.homelinux.net/pub/pstoedit/pstoedit-3.42-1.tar.bz2
ftp://antiskid.homelinux.net/pub/pstoedit/setup.hint

ftp://antiskid.homelinux.net/pub/pstoedit/pstoedit-devel/pstoedit-devel-3.42-1.tar.bz2
ftp://antiskid.homelinux.net/pub/pstoedit/pstoedit-devel/setup.hint

There is a problem though: linking to the newly uploaded libEMF package created
a broken executable, so this is disabled in the trial packages above.

When pstoedit is configured with the flag "--with-emf", it creates the dll file
/usr/lib/pstoedit/cygp2edrvwmf-0.dll.  This seems to be a problematic dll,
which causes pstoedit.exe to fail silently on any invocation.  The odd thing
is, this remains the case, even if pstoedit is reconfigured "--without-emf" and
recompiled and reinstalled, as long as the problematic cygp2edrvwmf-0.dll
remains on the system.

Early in the development cycle, I did install and link to libEMF, successfully,
using a local build of libEMF.  So I don't know what the problem is now, except
it obviously isn't working with the newly uploaded libEMF package.

If someone [Dr. Zell?] could help me figure out what the issue is and fix it
quickly, I'd appreciate the help.  Otherwise I recommend we upload this trial
packaging (assuming it otherwise passes inspection), and use the available
functionality while I try to troubleshoot the libEMF problem.

Thanks,

jrp

Re: Security advisory: uw-imap - 3 attachments

[Christopher Faylor]

On Fri, Oct 14, 2005 at 03:32:44PM +, Eric Blake wrote:
>cgf wrote:
>>cygwin-apps is a...  wait for it...  mailing list.  It is a *moderated*
>>mailing list.  It is moderated for a reason.  Having it moderated for
>>email and not moderated for anyone who figured out how to use gmane has
>>already been shown to be a bad idea.  I don't want a back door method
>>for people to send their bug reports and package requests to this list.
>
>But so is cygwin-patches, and gmane *can* post to cygwin-patches!

1) I didn't know that.

2) cygwin-patches hasn't (yet) been abused by people who send off-topic
email.  If it is abused, then I'll request similar blocking from gmane.

>gmane requires a legitimate email address before posting, and
>therefore gmane will not allow an unsubscribe user to post to
>a moderated list.

A person who registered via gmane to read
gmane.comp.accessibility.vision does not automatically qualify as a
person who should be able to send email to cygwin-apps.

>The difference is whether gmane is set up as a one-way list (as is
>cygwin-apps) or a moderated list (as is cygwin-patches).  All I was
>asking is that gmane be told that cygwin-apps can be treated like
>cygwin-patches, instead of a one-way list.  But I can also live with
>the status quo, there is no need to do this just because I asked if you
>don't want to.

I requested the one-way aspect of this gmane forum and would have taken
more draconian steps on sourceware.org if this option wasn't available.

cgf

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: Security advisory: uw-imap - 3 attachments

[Eric Blake]

> >But so is cygwin-patches, and gmane *can* post to cygwin-patches!
> 
> 1) I didn't know that.
> 
> 2) cygwin-patches hasn't (yet) been abused by people who send off-topic
> email.  If it is abused, then I'll request similar blocking from gmane.
> 
> >gmane requires a legitimate email address before posting, and
> >therefore gmane will not allow an unsubscribe user to post to
> >a moderated list.

gmane requests an address PER list (in other words, registering
to post to gmain.comp.accessibility.vision does not also let you
post to cygwin-apps).  It also asks for your email address, so
on a managed list, your post should only get through if your
email address is already a subscriber to that list.  Therefore,
using gmane to post to cygwin-patches only works if you are
already a subscriber of cygwin-patches.  That was all I was
asking for cygwin-apps, but I see your point of view, and will
live with it, without any further comments on this thread.

> 
> I requested the one-way aspect of this gmane forum and would have taken
> more draconian steps on sourceware.org if this option wasn't available.

--
Eric Blake

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

[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

[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

[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

[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:

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: ".