Hi, I've updated the mysql-4.0.16.ebuild for MySQL 4.1.0-alpha including redoing the no longer working patches. I didn't redo patches that apply with some fuzz. It works nicely for me - sub-queries finally! WARNING: This software is considered development code in alpha stage, so better don't use in production enviroment! Also be sure to run revdep-rebuild from gentoolkit to rebuild all needed packages for the new libmysqlclient.so.14 (as also noted by the ebuild).
Created attachment 21398 [details] ebuild
Created attachment 21399 [details, diff] updated install-db-sh patch
Created attachment 21400 [details, diff] updated mysqld-safe-sh patch
Nice! I didn't notice this bug. Tried it with 4.1.1 ?
What are you trying to tell me? Or you only wanna know if it also works with 4.1.1? Haven't tried yet...
Can any of the mysql folks comment on the inclusion of this in portage?
Caleb: as the original poster noted: "WARNING: This software is considered development code in alpha stage, so better don't use in production enviroment!" It may go into the tree, but masked via pckage.mask, when one of us gets some time. Last I tried 4.1.0 it didn't even build on my machine (with this ebuild or by hand) If the original poster would care to update the ebuild to be based off the 4.0.17 ebuild and be for 4.1.1 instead, I'll take another stab at it early next week.
Thanks - I may take a stab at it then; just wanted to make sure that it had some interest in making its way to portage, even if it is package.masked.
What's the status of this? Still waiting for the updates ( to be based on 4.0.17 and intended for 4.1.1 )? I'll have a go at it myself if no-one else wants to ( warning: I have very little idea what I'm doing ).
Daniel: go for it, it's so low down I don't think it's even on my priority list anymore.
*** Bug 44420 has been marked as a duplicate of this bug. ***
Hi, currently I am working at a mysql perl-script which uses time depending functions. I am to write a script based logic to evaluate the times or use the new time features of mysql-v4.1. I would prefer to use the new mysql :-) So I was looking, if somebody would already have built an own ebuild, so I got here. As Robin Johnson told that even a manual compile fails, I am currently compiling by hand at my target machine, which might last a couple of hours, because it has only 300MHz (586). In the meantime, I would like to encourage the so far involved developers in keep on working. I will update my comment about the result of my compile.
Hi again, after real 115m26.485s the built succeeded. I have logs of ./configure (with no options) and ./make and can post or send them, if requested. regards, Sascha
I've made a start on an ebuild for 4.1. I've got problems. Most of the patches don't apply, saying they can't find what file to patch. Don't know. First attempt at ebuild :) I've commented out the ones that don't work. I'm currently getting a compile error, which is a little strange as I can compile 4.1 from the source myself. I haven't checked yet whether it is an autoconf / automake / whatever problem - no free time. I'll check out this possibility this weekend ... maybe. The only reason I really want to do this is so I can do a smooth upgrade to 4.1.2 when it comes out ( which it will any day now ). If someone is interested in what I've got so far ( which is not much - seriously, you may be better off without it ) then I'll upload a .tar.bz2 of the overlay directory. Perhaps someone can fix what I broke?
Created attachment 28780 [details] mysql-4.1.1_alpha.ebuild Hello Here is a mysql-4.1.1_alpha.ebuild which is working on my 64bit system. Unpack in /usr/local/portage/dev-db and make an "ebuild mysql-4.1.1_alpha.ebuild digest" as usual. Thomas
Still any work done on this? mysql 4.1.2 is out now.
hanno: you're really really on the ball with the release of 4.1.2. It they haven't even finished building all of the binaries or updated their documentation to say it's out yet, give it a bit, and i'll try it out during the week to see if it's better than the last version that didn't work for me.
Definatly interest in having this available masked, if I don't get subqueries soon I may go insane :)
I tried for hours last night to get mysql-4.1.2_alpha to compile from an ebuild I cluged from the first one above, but nada. Version 4.1.0 above works, all will need Apache & PHP re-compiled. BTW - 4.1.2 is the first version with failover not just replication.
Created attachment 32657 [details] mysql-4.1.2 test ebuild Hello Here is a mysql-4.1.2 test ebuild. Unpack in /usr/local/portage/dev-db. It just compiles with USE=-readline on my computer. Don't know why. Beside of that, everything is working.
Thanks! That was all I needed. (USE="-readline") Here's what the MySQL spec file had in it. Which shows readline? Who knows? ./configure \ $* \ --enable-assembler \ --enable-local-infile \ --with-mysqld-user=%{mysqld_user} \ --with-unix-socket-path=/var/lib/mysql/mysql.sock \ --prefix=/ \ --with-extra-charsets=complex \ --exec-prefix=%{_exec_prefix} \ --libexecdir=%{_sbindir} \ --libdir=%{_libdir} \ --sysconfdir=%{_sysconfdir} \ --datadir=%{_datadir} \ --localstatedir=/var/lib/mysql \ --infodir=%{_infodir} \ --includedir=%{_includedir} \ --mandir=%{_mandir} \ --enable-thread-safe-client \ --with-comment=\"Official MySQL RPM\" \ --with-readline ; # Add this for more debugging support # --with-debug # Add this for MyISAM RAID support: # --with-raid "
About your readline quandary, this is the relevant portion of the ebuild: #readline pair reads backwards on purpose, DONT change it around, Ok? # this is because it refers to the building of a bundled readline # versus the system copy use readline && myconf="${myconf} --without-readline" use readline || myconf="${myconf} --with-readline" When you compile with USE="-readline", then configure uses the bundled version of readline (--with-readline) Hope this helps.
After my "emerge -DU mysql-4.1.2_alpha.ebuild" As part of the follow-through I needed to recompile ntp, libwww, php, mod_php and pure-ftpd (Apache too, just in case). revdep-rebuild puked because it wanted to install a version of php that is no longer in portage. To get all this to work libwww needs compiled before PHP and to do this I had to resort to putting "net-libs/libwww -mysql" (without quotes) into the /etc/portage/package.use file. libwww is getting up in age and GNU.org turned it over to public domain in January so not many updates have happened since 2002. pure-ftpd wouldn't install until I used version 1.0.18 Everything after that updated without a hitch. I did experience some hypersensativity to -distcc & -ccache on new hardware. The speed increase I anticipated has not yet been realized so I've got some tuning to do. Thanks All!
Note: ACCEPT_KEYWORDS and emerge -U is a no-no now... so that is why revdep-rebuild breaks. See http://forums.gentoo.org/viewtopic.php?t=148415 for how to maintain your system. I added -readline to my make.conf, and mysql to package.keywords, and the supplied 4.1.2 compiled, yay :) revdep-rebuild took care of the other dependencies. Great work!
With gcc 3.3.3-r6 I had to apply the gcc-3.3.3-hist_entry.patch The details are here: http://bugs.mysql.com/bug.php?id=3937 Also I had to modify my /usr/include/pthread.h file as specified in: http://bugs.mysql.com/bug.php?id=972 I am uploading the patch and the slightly modified ebuild.
Created attachment 33433 [details, diff] gcc-3.3.3-hist_entry.patch
Created attachment 33434 [details] mysql-4.1.2_alpha.ebuild (with gcc patch line)
I have problem __again__ with LinuxThreads.. :( checking "LinuxThreads"... "Not found" configure: error: This is a linux system and Linuxthreads was not found. On linux Linuxthreads should be used. Please install Linuxthreads (or a new glibc) and try again. See the Installation chapter in the Reference Manual for more information. !!! ERROR: dev-db/mysql-4.1.2_alpha failed. !!! Function econf, Line 365, Exitcode 1 !!! econf failed
MySQL-4.1.3 has been released as *beta* :)
Created attachment 34813 [details, diff] Updated mysql_install_db.sh patch for mysql 4.1.3
Created attachment 34814 [details, diff] Updated mysqld_safe.sh patch for mysql 4.1.3
Created attachment 34815 [details] Test ebuild for mysql 4.1.3 beta Hacked ebuild for 4.1.3. Include the above two patches in files/ Also added nptl and other fixes from the 4.0.20 ebuild. Compiles and works on my machine, YMMV.
The 4.1.3 beta ebuild works like a charm for me. Any way to get this into portage ? (masked or unstable)
One thing I should note: After upgrading, a lot of apps were still looking for libmysqlclient.so.12(*). I had trouble doing a revdep-rebuild too. I found the simplest way to solve the problem was to create a symlink from libmysqlclient.so.12, to libmysqlclient.so.14. I didn't know how to do this in the ebuild... It didn't seem a very graceful solution, anyway. Is there a better one? Furthermore, libwww fails to build at all after upgrading, as it uses obsolete functions apparently removed in 4.1.3. I've created bug 56328 for this, and added a patch.
The symlink seems dangerous. The libraries aren't guaranteed to be BC are they?
I've done some more testing and this does indeed appear to be a rally bad idea. Because of the removed funcitons from libmysqlclient, several packages no longer compile. - Which is why I was having an uphill battle with revdep-rebuild. (See the above comment re: libwww.) In practice, things seem to work with the symlink better than without, *if* you're unable to recompile them because of build errors. I wouldn't be happy relying on it at all, though. What needs to happen, is patches need to be created for the packages that rely on mysql_create_db and mysql_connect, and therefore fail to build against the new lib. So far I've found libwww and tetex that have this problem. There's probably more.
I've created bug 56348 and bug 56356 with patches to support the newer mysql. Now revdep-rebuild compiles everything correctly on my machine. There may be other broken packages that I don't have, however.
The Complete Idiot's Guide to Installing the MySQL 4.1.3 beta ebuild 1) Download "Test ebuild for mysql 4.1.3 beta", save as /usr/local/portage/dev-db/mysql/mysql-4.1.3_beta.ebuild 2) Download "gcc-3.3.3-hist_entry.patch", save as /usr/local/portage/dev-db/mysql/files/gcc-3.3.3-hist_entry.patch 3) Download "Updated mysql_install_db.sh patch for mysql 4.1.3", save as /usr/local/portage/dev-db/mysql/files/mysql-4.1.3-install-db-sh.diff 4) Download "Updated mysqld_safe.sh patch for mysql 4.1.3", save as /usr/local/portage/dev-db/mysql/files/mysql-4.1.3-mysqld-safe-sh.diff 5) copy /usr/portage/dev-db/mysql/files/* to /usr/local/portage/dev-db/mysql/files/ 6) Assuming you have mysql in your package.keywords, yadda yadda, you're finally ready to emerge 4.1.3... :) ---- Unfortunately, 4.1.3 beta didn't work for me (arragh)
I propose adding a 'unicode' USE flag to this ebuild. When set, it will set --with-charset=utf8 in the configure. When not set, it can default to --with-charset=latin1. Of course, it can set other things appropriately, but I'd like to see that one particularly. That is, after all, one of the primary new features in mysql-4.1.
IIRC you can still use utf8 with mysql when using the ebuild. Just run 'mysql --default-character-set=utf8'. You can then cat your UTF8 sql files in quite happily. I use this feature to maintain a database with English, Hebrew, Greek, Finnish, and more, all mixed up. It works fine.
Would it work if I put mysql-4.1.x on a different SLOT than mysql-4.0 so I can run them side by side?
andrei: you'd need to make sure all binaries and directories don't conflict with the 4.0 items, which basically comes down to adding the version into all of their names.
I think that slotting it might be a good idea. Maybe it'd be helpful to install it into /var/mysql41 or something like that, so it can coexist with the 4.0 install?
The ebuild doesn't seem to install /etc/init.d/mysql
And neither mysql_install_db
I've tried again and it installed fine.. sorry about the noise. Only I have to try with less aggresive flags, because it segfaults :(
andrei: could you post up your slotted ebuilds if you created them?
Ugh.. I've created an ebuild with every location that contained mysql replaced with mysql-4.1, but I've undone the changes because the server segfaulted. Unfortunately I didn't save the ebuild with those changes, but it shouldn't be too hard to be done again, but mysql-4.1 is just too fragile right now and it segfaults even with the most restrictive CFLAGS combination :(
4.1.4 has just been released as Gamma! :)
gcc-3.3.3-hist_entry.patch fails against 4.1.4-gamma =C=
> gcc-3.3.3-hist_entry.patch fails against 4.1.4-gamma It seems that it's uneeded. I've compiled it without the patch. gcc-3.3.4
A small note: the phpmyadmin developers are toying with dropping 4.1.x support because they say it's still just too unstable.
Well stability is an issue. I stayed with every version bump for quite awhile and jumped on 4.0.20 when the ebuild was created. After 4 months, dang if I can keep it running for more than 6 days. If 4.1.14/whatever is off on the horizon maybe we can refocus on making 4.0.20 more stable.
> the phpmyadmin developers are toying with > dropping 4.1.x support because they say > it's still just too unstable. No, this is not true. What we dropped was the support for MySQL 4.1.0 and 4.1.1. The current 4.1.4 runs fairly stable on our testing machines is is already supported by phpMyAdmin 2.6.0 RC2.
David.Huff: I haven't see you file any bugs about instability. I've been running mysql-4.0.20* on production machine since it was released without any problems at all.
Alright ... so can we get the ebuild into portage already? It doesn't need to be marked stable, but certainly it is worthy of ~x86 ... what is the point of ~x86 otherwise? Even a hardmask is fine too. I am running 4.1.4-gamma happily on FreeBSD and it has been fairly loaded with a dspam client and it performs as expected without error.
Getting an ebuild would be good. I tracked down my stability issues on 4.0.20 due to system demands (lack of memory). Time to get on to 4.1.*
4.1.7 is released as STABLE :)
Excellent. I would love to see it officially put into Portage (even if hard-masked).
Just wanted to throw in my support for a Portage import too. FWIW. :) Also, one question: MySQL Cluster support has been moved into MySQL Server 4.1-MAX. Max is the version that has "additional features such as the NDB (Cluster) storage engine, the Berkeley DB storage engine, and other features that have not been exhaustively tested or are not required for general usage, such as user-defined functions (UDFs) and BIG_TABLE support." How does Max fit in for Portage users? Currently, if you want MySQL Max, do you run the source version from MySQL, or are there any options for it in Portage?
http://bugs.gentoo.org/show_bug.cgi?id=62582 has an ebuild for 4.1.7 I haven't looked at it, but I thought it might interest others watching this bug. Perhaps someone who has time and knows what they're doing should compare both ebuilds and get the best bits of both? I will *try* to have a look at both over the weekend, but I'm no ebuild expert...
4.1.7 in cvs. *** This bug has been marked as a duplicate of 62582 ***
