On Wed, Aug 6, 2008 at 8:27 AM, Dave Korn wrote:
> 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.
>
Thanks for the effort. I understand perfectly, especially after
reading the announcement.
>> 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 now 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.
>
Unfortunately, no. I had no idea anything "special" was going on and
just kept running setup.exe over and over.
>> 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).
>
Yes, I was surprised that I had to redo all the selections again after
canceling.
I guess that this is a special use case that doesn't get tested that
often, i.e., setup.exe works a lot better from one single official
mirror. For example, we shouldn't have to edit the timestamp in
cygwinports' setup.ini just to make setup.exe not try to downgrade
packages. I've now added an extra step when using setup.exe: I go to
Partial view and select Keep and then go back to look for whatever
else I wanted to install.
I'll try to keep the logs and write down steps taken next time I upgrade.
Thanks
--
Luis P Caamano
Atlanta, GA USA
-------------------------------------------------------------------------
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
