package phpmyadmin 4:3.3.10-1 failed to install/upgrade: le sous-processus script post-installation installé a retourné une erreur de sortie d'état 10

I found that:

1) following the instructions at https://bugs.launchpad.net/ubuntu/+source/phpmyadmin/+bug/774980 to set up php5 correctly
and
2) installing phpMyAdmin thru Synaptic Package Manager

installs phpMyAdmin successfully

Looks like something went wrong in dbconfig-common:

Use of uninitialized value $_[1] in join or string at /usr/share/perl5/Debconf/DbDriver/Stack.pm line 111, <GEN0> line 20.
Use of uninitialized value $_[1] in join or string at /usr/share/perl5/Debconf/DbDriver/Stack.pm line 111, <GEN0> line 28.
dbconfig-common: writing config to /etc/dbconfig-common/phpmyadmin.conf

Hmm, looking at the amount of duplicates and the fact that they all fall in the same time frame I wonder if instead this being a bug in dbconfig-common if this wasn't a bug in the software center which is long fixed. I recall that I once had an issue that questions were not appropriately asked in one package manager. It might be the case in all these bugs.

I expect most people don't remember which package manager they were using at the time. However, I think I will consider this bug as being fixed and not really a bug in dbconfig-common.

By the way, I believe (although not sure yet) that the lines above in message #3 are a red harring. I think dbconfig-common sometimes accepts debconf to error out and based on that takes actions. I think these lines are the result of such code.

Also, I don't really think that all the duplicates are really all the same. However, they also lack the information to really debug the issue. I believe that most bugs that have a string like "ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)." to be caused by the package manager not asking the question. Those bugs that have a "YES" there, are probably user errors (i.e. wrong password provided. And yes, I believe that dbconfig-common does not recover properly when that happens (i.e. it should warn the user are retry all actions, but it looks like it doesn't behave the same in the retry as it would in the first successful run. There are plenty of bugs describing that situation.

As I mentioned in my previous comment, I tend to think this issue (which was never a dbconfig-common bug AFAICT) has been solved. It would help if anybody could tell me if they still experience this issue or if they don't. Marking this bug as incomplete until somebody responds.

[Expired for dbconfig-common (Ubuntu) because there has been no activity for 60 days.]