, Directory:
False
which seemed to indicate that it was trying to read
C:\etc\setup\libncurses-devel.lst.gz when it died.
Searching further, I read the suggestion to just delete a suspected
corrupt *.lst.gz file and retry setup.exe. I did. It installed a lot
of man pages and ran to completion
On 24 February 2008 14:13, Dave Korn wrote:
On 23 February 2008 21:51, Dave Korn wrote:
The solution has two parts then:
And here is part 1.
No comments then? I'll apply it sometime tonight or tomorrow if nobody
objects.
Meanwhile (here's the RFC part), my suggestion for part 2
Dave Korn wrote:
And here is part 1.
No comments then? I'll apply it sometime tonight or tomorrow if nobody
objects.
Well, you labeled it as part 1 and so I mentally said, okay, I'll
take a look at this whenever it's complete.
Meanwhile (here's the RFC part), my suggestion for
On 26 February 2008 13:59, Brian Dessent wrote:
Dave Korn wrote:
And here is part 1.
No comments then? I'll apply it sometime tonight or tomorrow if nobody
objects.
Well, you labeled it as part 1 and so I mentally said, okay, I'll
take a look at this whenever it's complete.
On Tue, 26 Feb 2008, Brian Dessent wrote:
Dave Korn wrote:
And here is part 1.
No comments then? I'll apply it sometime tonight or tomorrow if
nobody objects.
Well, you labeled it as part 1 and so I mentally said, okay, I'll
take a look at this whenever it's complete.
Dave Korn wrote:
Meanwhile, part 1 OK for trunk?
Yes, I think making that dialog modal is good.
Igor Peshansky wrote:
I don't like Dave's proposal either. However, simply disabling the
Cancel button altogether is not the solution -- if the user is unable to
interrupt the installation,
On 26 February 2008 14:55, Igor Peshansky wrote:
The question is: what kind of behavior do we really want in case of
cancellation? If we want setup to stop whatever it's doing (dependences,
etc, aside), but be able to resume at a later point to fix the state of
the system, then Dave's part 1
On 26 February 2008 15:24, Brian Dessent wrote:
Dave Korn wrote:
Meanwhile, part 1 OK for trunk?
Yes, I think making that dialog modal is good.
Thanks, will commit at a convenient moment.
Igor Peshansky wrote:
I don't like Dave's proposal either. However, simply disabling the
confusion, I referred to the
fix for the corrupt lst.gz files as your part 1. There is no question
that both were the right thing to do.
It is a fortuitous side-effect of making them correctly modal that it
becomes slightly trickier to accidentally cancel an installation when
you thought you were
On Tue, 2008-02-26 at 07:24 -0800, Brian Dessent wrote:
To really do this right
(e.g. how MSI can rollback to the starting state midway through a
aborted install) is a tremendous amount of work that I don't think
anyone here is prepared to take on.
FWIW this is why I started porting dpkg to
On 23 February 2008 21:51, Dave Korn wrote:
Yes, I see, the dialog isn't modal and so it allows the 'X' which is
effectively the same as cancelling. The solution has two parts then: 1)
make the pop-up modal so the user can't mess with the app's main window
while answering the question, and
Afternoon all,
After a little more testing, and unless anyone yells, I intend to apply this
patch later tonight to catch the infamous corrupt lst.gz file crash in current
setup.exe.
2008-02-23 Dave Korn [EMAIL PROTECTED]
* cygpackage.cc (cygpackage::getfirstfile): Guard
Dave Korn wrote:
After a little more testing, and unless anyone yells, I intend to apply this
patch later tonight to catch the infamous corrupt lst.gz file crash in current
setup.exe.
Thanks for looking at this, but that's really only solving half of the
problem. The other half is that we
On 23 February 2008 18:50, Brian Dessent wrote:
Thanks for looking at this, but that's really only solving half of the
problem. The other half is that we generate one of these bogus .lst.gz
files while installing a package if the user is prompted to retry an
in-use file and clicks the
On Sat, Feb 23, 2008 at 06:54:19PM -, Dave Korn wrote:
On 23 February 2008 18:50, Brian Dessent wrote:
Thanks for looking at this, but that's really only solving half of the
problem. The other half is that we generate one of these bogus .lst.gz
files while installing a package if the user
On 23 February 2008 18:50, Brian Dessent wrote:
problem. The other half is that we generate one of these bogus .lst.gz
files while installing a package if the user is prompted to retry an
in-use file and clicks the close-X in the dialog instead of chosing
retry or replace.
Need a bit of
On Sat, 23 Feb 2008, Dave Korn wrote:
On 23 February 2008 18:50, Brian Dessent wrote:
problem. The other half is that we generate one of these bogus
.lst.gz files while installing a package if the user is prompted to
retry an in-use file and clicks the close-X in the dialog instead of
On 23 February 2008 21:23, Igor Peshansky wrote:
On Sat, 23 Feb 2008, Dave Korn wrote:
On 23 February 2008 18:50, Brian Dessent wrote:
problem. The other half is that we generate one of these bogus
.lst.gz files while installing a package if the user is prompted to
retry an in-use file
18 matches
Mail list logo
