Luis P Caamano wrote on 05 August 2008 19:51:
> Dave, thanks for the info. I'm glad you gave us a preview of the -X
> flag because I ended up needing it urgently before you posted the
> announcement. :-)
My apologies for the late timing of the announcement; the release was
somewhat rushed because the guy who discovered it suddenly went and
published his advisory without telling us. One day (24/07) he was asking us
the timeframe for getting the release out, the next (25/07) he's published
it all without waiting for a reply or warning us, in fact he didn't even
make it clear after the fact. We were going to get a certificate and have a
proper Authenticode signature for setup.exe, but felt that he had forced our
hand. Not unsurprisingly, I feel this was a tad premature and clumsy of
him, but what can you do? We just had to rush out the release and document
it after the fact.
> On Tue, Aug 5, 2008 at 12:59 PM, Dave Korn wrote:
>> Luis P Caamano wrote on 05 August 2008 13:40:
>>
>>> Well, it worked this time. I looked at the setup.log.full earlier and
>>> saw something in the ftp greeting from sunsite.dk saying something
>>> about load too high to permit downloads.
>>>
>>> Perhaps that was the issue?
>>
>> Yes, beyond any shadow of a doubt.
>>
> Now I realize this is what started my update nightmare last Thursday.
> I suspect now that the sunsite.dk server load went up and it started
> to refuse downloads. I tried many times and got the same error until
> I finally canceled it.
>
> Unbeknownst to me at the time, I know had a partially installed cygwin
> environment because all that stuff that was uninstalled did not get
> installed back and now I had lost a ton of dependencies.
This /shouldn't/ have happened, because setup is /supposed/ not to start
uninstalling until it's got something new to replace the old version with.
But that of course doesn't mean setup.exe is bug-free!
Have you still got your /var/log/setup.log{,.full} available? It might
help us reconstruct exactly how it went wrong.
> The lesson learned here (or re-learned) is that one should always do
> the "download-only-then-install-from-local-dir" method when using
> cygwinports on top of the official cygwin packages.
It's definitely for the best, but it shouldn't be necessary; that's a
failing on our part. The error-handling paths in setup.exe are the weakest
and least-tested part of the code. (Cancelling out of an install early
counts as 'error-handling' in this context).
Also, the best thing to try when setup.exe goes wrong, before anything
else, is just to run it again, changing nothing and just clicking 'next' all
the way through. Hopefully that'll fix things up 99% of the time.
(Phase-of-moon and good following wind permitting!)
cheers,
DaveK
--
Can't think of a witty .sigline today....
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Cygwin-ports-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
