Version: 1.91 Swarm (beta 2) (using KDE 3.5.2, Kubuntu Package 4:3.5.2-0ubuntu1 dapper) Compiler: Target: i486-linux-gnu OS: Linux (i686) release 2.6.15-13-386 Whenever adept tries to install a package requiring user input (usually asking permission to overwrite a config file), it seems to just give up on the dpkg process, which forces me to run "dpkg --configure -a" manually on the command line. In addition, adept claimed that it had finished running the upgrade even though dpkg obviously never finished installing packages. It seems like adept should have told me that some user input was required or at least let me know that there was a failure I would have to correct manually. This happens pretty much every time I do an upgrade so I'm surprised that I couldn't find an existing bug report for this.. perhaps I have something configured incorrectly or I just missed the existing report?
Well, it should give you a warning. It does here, if dpkg runs into an error. Either way, please try adept manager to upgrade your system, when the installation progressbar appears, hit "show details" and when it finishes, go to view->show last dpkg run and investigate what is the problem with dpkg... It may be i am not catching something with dpkg going wrong. Thanks.
IMHO, the desirable behaviour would be to let the user make the decision that dpkg asks for *in Adept*, i.e., pop up a shell window with dpkg's question and let the user answer it. Or am I missing a reason to drop the user to manually run "dpkg --configure"? In any case, thanks for all the work on this nice program!
I wish this was as easy as it sounds. But it will be worked on after the freeze thaws (considering it's fairly nontrivial, enough to warrant that it would break feature-freeze).
*** This bug has been confirmed by popular vote. ***
*** Bug 130385 has been marked as a duplicate of this bug. ***
I suggest that until this can be fixed the right way, I suggest an interim hack (as this basically makes adept unusable for non-experts in the current state :( ): 1. A interupt option. 2. When this interuption is pressed, a message is displayed that you might need to run dpkg --configure -a on a command prompt. 3. When adept cannot start due to this state, write that you need to run dpkg --configure -a instead of complaining of the lock I leave it up to adept developers to distingush the stale lock case to the need-configure state, but I'm sure it's fairly trivial. Thank you!
Recently, I wanted to install Sun's Java and ran into the same problem(s) as described above. Luckily (after several - *really* - bad words), I found a kind of "cheat": you have to quickly click "Show details" and then make sure no other window gets displayed over Adept's window. When Sun's dialog popped up, I simply clicked into the console window, hit ENTER and it installed the JDK just fine.. :) Anyway, this bug is really annoying due to there are other packages which need user interaction, too..
It just happened to me that user input was requested through an X frontend, which failed due to authentication problems ("connection refused"). It would have probably worked fine if I had done e.g. an `xhost +' before. The fallback to `dialog' was not really usable, as the embedded konsole was plain black and only showed something after I pressed some keys (I hit 'y', 'Return').
Any news? I think this is a showstopper before adding new feature someone should fix bug. Less features that work is better than many that doesn't work very well all. People let's votes for this bug!
Fixed in devel branch (X debconf frontends work as intended).
The problem still occurs in Adept Manager 2.1 using KDE 3.5.10.