Categories
MySQL

MySQL 5.5.19

The packages of MySQL 5.5.19 are now available for Debian 6.0 “Squeeze” on both amd64 and i386 architectures. They fix some annoying issues that Dotdeb users kindly reported :

  • the mysql-common package, in its 5.5.19+ version, “breaks”  mysql-server-5.1 and mysql-client-5.1 (as APT means it – it won’t actually break your server into pieces). Freezing it will prevent any issue (the introduction of unknown configuration variables in their /etc/mysql/my.cnf, for example)
  • the MySQL client now uses the system’s readline library instead of the bundled editline wrapper
  • missing header files and libraries are now included in the appropriate packages

As usual, please read the full Changelog carefully before upgrading.

38 replies on “MySQL 5.5.19”

@Rickard Andersson : the solution is to freeze the mysql-common package to its actual (compatible with MySQL 5.1) version. Then APT won’t to try to uninstall mysql-server anymore.

By Post Author

Hi Guillaume,

I don’t think Mysql 5.1 installation is working. I’m trying to install mysql-server-5.1 from a fresh Debian install using Dotdeb repos, and it installs nothing:

# aptitude install mysql-server-5.1
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 23 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

And, about mysql-common solution, will it work with a fresh install? I mean, it seems to be only a mysql-common version and is for 5.5. If I don’t have a previous version I can’t install MySQL Server, right?

Thanks.

@Jordi : Here is the situation :

– upgrading a MySQL 5.1 server => no problem
– installing a MySQL 5.5 server => no problem
– installing a MySQL 5.1 server from zero => dependency problem, because of the mysql-common package from MySQL 5.5, that

Waiting for my fix, you can install (manually) mysql-common from MySQL 5.1 ( http://packages.dotdeb.org/dists/squeeze/mysql-dfsg-5.1/ ) first, then install mysql-server-5.1 with a regular apt-get or equivalent. It should work.

By Post Author

Ok, thanks for the info.
I already figured out myself the manual installation solution (which I can confirm it works), but I discarted it because I use Puppet, and it just complicate things.

Anyway, I’ll wait for your fix. Thanks again.

Hi,

Yesterday I did an upgrade from Lenny to Squeeze and I run into some problems. There is PHP5.3 and mysql-server 5.5 installed now (due to dotdeb-repository in sources.list).

There are several databases on my vserver and some of them (not every!) are not accessible. I get this kind of error as shown on this page:
http://www.ultimatewebtips.com/php-5-3-complaining-about-insecure-authentication-with-mysql-4-1/

I tried to solve the problem as described at this site although the password length already had been 16. Unfortunately it didn’t help. 🙁
I am not able to use some of my databases (only via mysql shell) but phpmyadmin for example is not working as well.

I also tried to enable/disable ‘old_passwords’ in my.cnf but without success….

Any ideas are really much appreciated. 😉

Thank you!

I forgot to mention that I decided to keep the old configuration files during the upgrade from Lenny to Squeeze.

It’s me again with good news. Don’t blame me but I forgot to “SET old_passwords = 0;”.

Now everything seems to be running well… 🙂

@snf : thanks, I saw that. Is there any critical issue with MySQL 5.5.19 that would force me to package 5.5.20 as soon as possible? If not, you should expect a few days delay 🙂

By Post Author

@Guillaume Plessis: well I saw an error fixed in InnoDB which is very simmilar to what I got just that friday. Changelog says that it should only be applicable for debug builds, but you never know. Anyway thanks for providing packages, debian experimental is still stuck at 5.5.17.

Thanks

@Guillaume Plessis: Just compared sources 5.5.19 vs 5.5.20, the Bug #13358468 seems to be related to my error, can you release .20 ASAP? Thanks in advance

I’m noticing that the 5.5.19 mysql-server pkg requires libmysqlclient16. This is leading to more problems where stuff built against MySQL 5.5 is conflicting with the libmysqlclient16 pkg which seems to require being installed.

i.e.:

Incorrect MySQL client library version! This gem was compiled for 5.5.18 but the client library is 5.1.58.

Shouldn’t the last mysql-server depend on libmysqlclient18?

@Joe Auty : mysql-server 5.5.19 doesn’t depend on any libmysqlclient directly. But libdbi-perl from Debian does, on libmysqlclient16. The thrown message is just a warning, you can ignore it.

Actually, there is a real annoying dependency problem with mysql-common, that prevents MySQL 5.1 to be installed from scratch. I’m working on it and it should be fixed with my MySQL 5.5.20 packages

By Post Author

How can I remove libmysqlclient16 then without removing MySQL 5.5?

# apt-get remove libmysqlclient16
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages will be REMOVED:
libdbd-mysql-perl libmysqlclient16 mysql-client-5.5 mysql-server mysql-server-5.5

and the dotdeb MySQL 5.5 depends on libdbd-mysql-perl?

# apt-get remove libdbd-mysql-perl
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages will be REMOVED:
libdbd-mysql-perl mysql-client-5.5 mysql-server mysql-server-5.5

I’m confused… Why would the Debian made libdbd-mysql-perl depend on the Dotdeb MySQL packages even though when I do an “aptitude show libdbd-mysql-perl” I see:

Depends: libc6 (>= 2.4), libmysqlclient16 (>= 5.1.21-1), perl (>= 5.10.1-13), perlapi-5.10.1, libdbi-perl (>= 1.610.90),
perl-dbdabi-94

What would have to happen in order to get rid of libmysqlclient16? Can I move/rename these libraries manually so that the libmysqlclient18 libraries are used instead?

Sorry, just mostly confused.

libdbd-mysql-perl depends on libmysqlclient16, that is still provided by Dotdeb. If you absolutely want to remove libmysqlclient16 from your system, although there’s no problem having both libmysqlclient16 and libmysqlclient18 installed, feel free to rebuilt any MySQL-linked package (including libdbd-mysql-perl) against libmysqlclient18.

By Post Author

All I want to do is work around these sorts of error messages while using Ruby gems:

Incorrect MySQL client library version! This gem was compiled for 5.5.18 but the client library is 5.1.58.

my thinking was that by getting rid of libmysqlclient16 the 5.1.58 client libraries would be unavailable to gems such as this, and the newer libraries would therefore be used.

Any suggestions as to where I should focus my attention here in solving this problem, if not removing libmysqlclient16? I’m still unclear as to what is going on here with the dependencies, but I’m following up with what you said about how the two libraries can co-exist… Is there an environment variable that can be set to point to libmysqlclient18 or something?

Okay, I think I understand what is going on with the dependencies…

I’m wondering whether it is going to be easier to modify this Debian package, or just install a new version of the Perl/MySQL interface via CPAN… Hmm..

It would be awesome if you guys would distribute a libdbd-mysql-perl with depends libmysqlclient18 (>= 5.5.whatever) 🙂

Just rebuild your mysql ruby extension ( libdbd-mysql-ruby ?) against libmsqylclient18.

apt-get install libmysqlclient-dev (be sure it’s 5.5.x)
apt-get source -b libdbd-mysql-ruby

By Post Author

Nope, doing this will force me to do it for every MySQL-linked package from Squeeze, leading for sure to conflicts, duplicate symbols and segfaults for users with custom configuration.

Avoiding the mysql version warning does not worth it.

By Post Author

Okay, I worked around this by updating some Ruby stuff via RVM. I guess this wasn’t a Dotdeb problem persay, but thanks for bearing with me, it was a learning process for me!

I got a “size mismatch” error, so canceled the installation. It also requested I run mysql_upgrade, which I did. Now it says I’m at 5.1.49. I want the date function on the partitioning, so am interested in 5.5. But I’m not sure it is going to go as planned. I read change logs and don’t see any problems there. My only concern really is with the installer, as I tend to trust completely to others in this regard. The installer is ready, right? What would the size mis-match have been about? Thanks for your efforts!

@John Tinker : just run “apt-get update” or equivalent, depending on your favorite package manager, to update the packages infos (including their size). Then you could install them without any issue.

By Post Author

Well, I actually do still have one problem. On the first machine I was working on, I was stabbing around a bit in the dark, and got a Synaptic process stuck somehow between mysql 5.1 and 5.5, and now on that first machine, I cannot shut the mysql server down because of a password issue. I can access the mysql server otherwise. The other two machines that I upgraded from 5.1 to 5.5 are working fine, no problems. But I wonder if there might be some advice for me regarding the password problem that I am having on the first machine?

Guillaume Plessis, I had already done that, assuming that the value in /etc/mysql/debian.cnf had to be passed into SELECT PASSWORD(“”) in order to get the value to put into mysql.users. I had also used FLUSH PRIVILEDGES afterward.

I can log into mysql as root at the command line. But if I try (as root)
/etc/init.d/mysql stop
it fails.

If I try to turn off the mysql server via mysql-admin, it also fails.

@Guillaume Plessis. Thanks for the suggestions. Finally what worked was:
mysqladmin -u root -p shutdown
Once shutdown, then started again, everything began to behave normally.

I think the take-home here is that (gui) mysql-admin couldn’t do it, but (command line) mysqladmin could.

Comments are closed.