It’s worth noting that Red Hat Enterprise Linux (RHEL) 5 has had an update to MySQL in the last month. This naturally means that CentOS 5 also had a similar update. It’s now bumped up to MySQL 5.0.77 (goodbye 5.0.45!; which is what RHEL5 shipped with). This is a moderate security release, so consider updating, if you can afford a mysqld restart.
Read more about the 4 CVE bugs fixed. CentOS followed suit within two weeks.
I’m a big CentOS fan. I think servers these days should either be Ubuntu Servers or CentOS based, and nothing else, if you’re going the Linux route.
CentOS 5.3, on the x86_64 platform, seemed to have an issue where yum would cause a traceback, with file.x86_64 0:4.17-15.el5_3.1. There is a bug open for it, but it apparently doesn’t happen on all systems.
The magic around this is to really just run yum clean all, and then run yum update. What that basically does is it cleans all packages that are cached in the system, as well as removes all header files used for dependency resolution.
I haven’t heard jokes about RPM hell in a long time… I am thinking that its mostly disappeared, and largely this is thanks to dependency resolution provided for by yum.
If you’re using Fedora 10, and are a KDE desktop user, you’ll notice that your latest KDE 4.2 update, requires having a local MySQL server installed. This is due to Akonadi, part of the KDE PIM packages, that now rely on MySQL as a default server, for storing PIM data. Just a few months ago, I mentioned the news that Amarok 2 will also use MySQL as a default database.
Akonadi uses MySQL mainly as a cache, not as a data store. This is something that Debian users will also see. Eventually, anyone with KDE 4.2 will see the requirement to have a MySQL server installed. If you already have a native installation of MySQL provided for by your distribution (maintained by RPM/DPKG), it naturally won’t be installing another copy – it just uses the system-wide version.
Not everyone is happy. Especially those that use netbooks, with limited disk space. Reading Reducing the MySQL 5.1.30 disk footprint by Ronald Bradford might help in that respect – there are ways to reduce up to 25% of the space.
However, from a MySQL perspective, and as a member of the Sun Database Group, I am happy to see the ubiquity of MySQL, on the Linux desktop.
For the technical folk amongst you, its worth looking at the akonadi spec file:
BuildRequires: mysql-devel
BuildRequires: mysql-server
..
# when/if akonadi grows support for other backends, consider splitting
# these similar to how phonon is done currently.
Requires: qt4-mysql
# not *strictly* required, but we need a functional default configuration
Requires(hint): mysql-server
..
%{summary}.
Requires an available instance of mysql server at runtime.
Akonadi can spawn a per-user one automatically if the mysql-server
package is installed on the machine.
See also: %{_sysconfdir}/akonadi/mysql-global.conf
Congratulations to the Debian team for releasing Debian GNU/Linux 5.0 Lenny on Valentine’s Day. This version comes with MySQL 5.0.51a.
I had been pestering Norbert Tretkowski to see when MySQL 5.1 will move from experimental to main, and he told me once Lenny was released. This is because Debian itself needs to make a library transition from libmysqlclient15 to libmysqlclient16, and every package that links to libmysqlclient will need to rebuild against the new version. It couldn’t be done any earlier, and now that Lenny is released, we should start seeing MySQL 5.1 in Debian/unstable, real soon now.
So, if you’re a Debian user, know that you have 5.0.51a in stable (Lenny), 5.0.75 in unstable, and 5.1.31 in experimental.
Recently, I had to futz with an Ubuntu server that was to run mail, web, and database services.
You slowly learn that Ubuntu as a desktop is easy to use, but as a server, its “different”, if you come from a Red Hat based background (especially if you’ve been using Red Hat-based distributions for the last thirteen years or so).
From example, while service httpd start works (well, the equivalent is service apache start), enabling things on boot using chkconfig (I wrote about it a while back) is replaced with update-rc.d.
In fact, if you’re an rpm aficionado, dpkg is a little different. I applaud the Ubuntu folk for creating an article such as Switching to Ubuntu from Red Hat Enterprise Linux or Fedora. Impressive. Switcher guides :)
OpenSolaris needs switcher guides. svcadm/smf is different for someone who’s coming from Linux-land.
So, you want to compile Workbench for Linux, on Fedora 9. You need to install the following packages:
autoconf automake libtool libzip-devel libxml2-devel libsigc++20-devel libglade2-devel gtkmm24-devel mesa-libGLU-devel mysql-libs mysql mysql-devel uuid-devel lua-devel glitz-devel glitz-glx-devel pixman-devel pcre-devel libgnome-devel gtk+-devel pango-devel cairo
I feel I’m being too liberal with dependencies, but I’m not about to strip it, I just want to get it working first :)
You need to have ctemplate and ctemplate-devel installed from updates-testing-newkey (relevant koji build log).
By default, configure.in in Workbench looks for “google-ctemplate”, as opposed to just “ctemplate” as Fedora calls it. You can fix this (easy), or “cheat” – in /usr/local/include you can do sudo ln -s /usr/include/ctemplate google. Take your pick.
Now for the fun. Fedora includes gcc-4.3. Ubuntu ships gcc-4.2. Let’s just say gcc-4.3 got stricter (its C++ header dependency streamlining related). So strict, they have a useful porting to gcc-4.3 guide. Just FYI, I believe OpenSUSE is also shipping a more modern GCC (I expect the next Ubuntu release in the coming month to do the same).
So, start getting used to doing the following in files that lead the compiler to fail:
This will help get rid of error messages like: error: 'memset' was not declared in this scope. This stuff is already fixed in trunk (or the patch is being applied).
You will need to pick up cairo from source. Why? Because --enable-glitz isn’t on by default in the RPM spec file (similar with Ubuntu). The glitz backend is apparently still a release preview and doesn’t fully work yet. (I have spoken to Alfredo, and he says he’s just removed the requirement on glitz in trunk).
Now, once you’ve built cairo with glitz, before running ./autogen.sh, do: export PKGCONFIG_PATH=/usr/local/lib/pkgconfig. Then go ahead and make it.
There are still plenty of warnings that spew by. I have this vague idea that once Workbench for Linux sits on Launchpad, we’ll run a janitorial tree that fixes warnings in the code. A great way to garner community contributions!
Anyway, a lot of this is either fixed or patches will be applied to trunk. I expect a mysql-workbench-5.1.2-alpha out sooner than you think to eclipse 5.1.1-alpha. Again, superb work Alfredo (and MikeZ and the rest of the GUI team).