at the same time http://bugs.gentoo.org/show_bug.cgi?id=181686 was closed, mysql released the 5.1.22 release candidate. version bump please, thank you in advance.. Reproducible: Always
Yeah, poke us when final is out, or why exactly do we need this RC stuff?
(In reply to comment #1) > Yeah, poke us when final is out, or why exactly do we need this RC stuff? > this would be a good reason http://krow.livejournal.com/553585.html another one is the fact that it really only needs bumping ... compiles with same useflags as 5.1.21 on am64
(In reply to comment #2) > (In reply to comment #1) > > Yeah, poke us when final is out, or why exactly do we need this RC stuff? > > > > this would be a good reason http://krow.livejournal.com/553585.html > another one is the fact that it really only needs bumping ... compiles with > same useflags as 5.1.21 on am64 > another one ;) i cant compile 5.1.21 version with ~x86 profile it seems that its related to gcc (see http://bugs.mysql.com/bug.php?id=28184) a patch is also added. may be with 5.1.22 they solve the compilation issue with gcc 4.2 thanks :)
(In reply to comment #3) > another one ;) > i cant compile 5.1.21 version with ~x86 profile it seems that its related to > gcc (see http://bugs.mysql.com/bug.php?id=28184) a patch is also added. > may be with 5.1.22 they solve the compilation issue with gcc 4.2 > > thanks :) This isn't solved in vanilla 5.1.22, so I have adjusted patch from mysql list (http://lists.mysql.com/internals/34680 anad http://bugs.mysql.com/bug.php?id=28184) and added it to mysql-extras. tar xjvf /tmp/distfiles/mysql-extras-20070916.tar.bz2 wget 000_index.txt.patch #also disables 3 patches which failed to apply on this version cd mysql-extras-20070916 patch -p1 ../000_index.txt.patch wget 709_all_mysql_gcc-4.2.patch cd .. tar cjvf /tmp/distfiles/gcc-4.2-20070927.tar.bz2 gcc-4.2-20070927 cp mysql-community-5.1.21_beta.ebuild mysql-community-5.1.22_beta.ebuild ebuild mysql-community-5.1.22_beta.ebuild digest I have also repacked and renamed mysql-5.1.22-beta.tar.gz archive (there should be directory mysql-5.1.22-beta in it). Then it can be compilled with gcc-4.2.* and seems fine, but no guarantee (you should check, if you need those 3 disabled patches).
Created attachment 132632 [details, diff] 000_index.txt.patch Add new patch to mysql-extras and disable 3 patches for 5.1.22 and higher.
Created attachment 132633 [details, diff] 709_all_mysql_gcc-4.2.patch Added patch to compile mysql-5.1.22 with gcc-4.2.*
issues with gcc 4.2.x compilation have been solved by upstream along with many security, performance, backwards compatibility and stability issues in mysql 5.1.23-rc. http://dev.mysql.com/doc/refman/5.1/en/news-5-1-23.html
5.1.23 isn't really helpful, due to this bug. Hopefully 5.1.24 will be better. http://bugs.mysql.com/bug.php?id=34655
5.1.24-rc is out! installing with portage fails due to 105_all_mysql_config_cleanup.patch. For the ones who want to test this version, update your /usr/portage/eclass/mysql.eclass to not include the patch ... mysql_src_unpack() { ... mysql_mv_patches rm /var/tmp/portage/dev-db/mysql-community-5.1.24_rc/work/patch/105_all_mysql_config_cleanup.patch epatch ... }
Dear MySQL team, what's your schedule/plan? TIA!
It seems that mysqld from 5.1.24-rc does not support --skip-bdb and --skip-ndbcluster anymore, thus "emerge --config" fails because mysqld fails to start. I removed --skip-ndbcluster and --skip-bdb from mysql_pkg_config() and all went smoothly.
5.1.25 is out and is not a rc package. Also it seems that PHP requires a mysql 5.0, which is weird as it works with 5.1 once I hack away at that dependency.
5.1.26 is the latest 5.1 release: http://dev.mysql.com/doc/refman/5.1/en/news-5-1-x.html
5.1.28 is the latest 5.1 release. a version bump after 11 month of new releases coming would be really appreciated. thanks in advance...
+ a version bump of pbxt from 0.9.8 -> 1.0.05 along the way would be cool http://www.primebase.org/download/index.php
Any status on this? Heck, the ebuild is mostly there. I was able to build 5.1 by copying the mysql.eclass to my local portage tree and removing the extra patches. Built like a champ and am running it now on my system.
There are 2 reasons to have these rc versions: 1. New features are required for a web application my team supports 2. Some of our customers are already using MySQL 5.1 and we need to be able to support it.
I'll be bumping in the tree when 5.1.30 is released. There was some very nasty breakage with collation between 5.1.24 that's finally fixed in 5.1.30. http://dev.mysql.com/doc/refman/5.1/en/news-5-1-30.html http://bugs.mysql.com/bug.php?id=40053
*** Bug 217451 has been marked as a duplicate of this bug. ***
As soon as upstream 5.1.30 comes out, this should be good.
*** Bug 229663 has been marked as a duplicate of this bug. ***
5.1.30 is out
I'm aware that 5.1.30 is out. However it's still in bad bad shape. Even Monty upstream has complaints about it: http://monty-says.blogspot.com/2008/11/oops-we-did-it-again-mysql-51-released.html It certainly ate some of my data when I tested it. Expect it to not be in Portage for another version or two, or even if it is, to remain in package.mask with large warnings.
With all respect I'd like to disagree that it would be in a bad shape. As several people commented on what Monty said, 5.1.30 GA "sucks less than 5.0, if you don't use any new 5.1 only features". Some of the new features (such as partitioning) are not good in Monty's view because parallel queries are not there yet. Actually, partitioning speeds up things on large databases a lot. Some reply examples: http://mysqlha.blogspot.com/2008/12/monty-endorses-mysql-51.html http://scale-out-blog.blogspot.com/2008/12/dont-shy-away-from-mysql-51.html http://fakeamelia.blogspot.com/2008/12/monty-rants-or-yet-another-case-of.html To users: I'd like to ask fellow gentoo users who might be tempted to send here replies such as "yes I agree, give us 5.1 now" to *not* to do it. This post is *not* meant to start a flurry of rants - it wont help anything. To devs: I have been testing mysql 5.1 since 5.1.17 and started using it since 5.1.26 in production on some slaves and since 5.1.30 on about half of our masters. Without any problems sofar. The only ugly thing is that I'd personally much more prefer an official masked ebuild over using an hacked eclass/ebuild. So, if any dev out there will be so kind and update the eclasses/ebuilds he'll make me (and I guess not only me) really happy. Thanks
My most defining test for putting MySQL builds in the tree has been that it passes both of the following: 1. Passes it's own testcases (upstream has been atrociously bad at this, see status2 in 5.0.72 for example) 2. It doesn't eat my data or break my systems. #1 is pretty easy as a start point, seeing if it works. #2 is a lot tougher: - 5.0.70 is the best option for now. - 5.0.72 breaks most of the statistics code out there really badly (I filed upstream bug 41131) - changes to SHOW behaviour as well as the 'Questions' variable. - 5.1.30 crashes within 5 minutes of breaking it up on my systems, I mainly suspect the date expression bug, but there's something else as well, as it's actively corrupted some of my data. Having upstream do sane releases is part of why there has been so long between my 5.0.x bumps, because they haven't passed my personal testing.
Thanks for the explanation :)
*** Bug 249649 has been marked as a duplicate of this bug. ***
I suppose I can live with the explanation, although getting it into portage ~M would be nice, what can we do to install 5.1.30 in the meantime? are there ebuilds somewhere? also, ultimately 5.1 will probably need. CFLAGS="-DPIC -fPIC" CXXFLAGS="-DPIC -fPIC" as amarok 2 requires that.
Created attachment 174936 [details] mysql-extras-20081211.tar.bz2 fixes patch 105 so it applies to mysql 5.1.30 removes patch 709 from attempting to apply to mysql 5.1.30 as it's in upstream.
Created attachment 174937 [details] mysql.eclass fixes mysql bug http://bugs.mysql.com/bug.php?id=39288 by compiling with PIC when using USE="embedded" this fixes amarok 2's problem
Created attachment 174938 [details] mysql-community-5.1.30.ebuild mostly an ebuild bump except that it uses mysql-extras-20081211
I should note that I'm not claiming the above has any kind of stability. but it builds. I have it in http://github.com/xenoterracide/portage/tree/regen2 which is a fork of funtoo. It will probably be in funtoo soon.
*** Bug 252673 has been marked as a duplicate of this bug. ***
(In reply to comment #30) > Created an attachment (id=174937) [edit] > mysql.eclass > You should probably change the download link for pbxt as well since they moved away from SF to launchpad. The new download should be http://www.primebase.org/download/pbxt-${PBXT_VERSION}.tar.gz New version for pbxt targeting MySQL 5.1.30 is 1.0.07-rc
only bumping title: mysql-community-5.1.30 -> mysql-community-5.1.31
*** Bug 259983 has been marked as a duplicate of this bug. ***
Created attachment 183029 [details, diff] patch selections for 5.1.31 patch selections for 5.1.31
I found that my 5.1.30 ebuild bumped worked... also please bump mysql 5.0.77 in both community and not.
Created attachment 183237 [details] mysql.eclass I've added a mirror to my google code project. working out a new mysql-extras for 5.0.77 which will be hosted there.
KATO Kanryu: While I don't mind classic diffs, unified diffs are easier to use. I'll apply shortly, thanks. xenoterracide: 1. please attach changes as unified patches. attaching the entire ebuild again sucks for review. 2. I have already said that I will not accept the CFLAGS changes just appending f/DPIC - there's an explicit bug for developing the patch. 3. If you want to be really useful, how about making variants of the percona patches that apply to the enterprise tree of MySQL 5.0? All: 5.1 will come to Gentoo when the time is right - which is just not yet.
@robbat2 the full ebuild/eclass is more for users who want to test, I know for the longest time I hadn't a clue how to use patch. I don't use patch anyways, I could send you the git patch(s). which include a unified diff. this last one is really just a 1 line diff involving a new url for any mysql-extras I might provide for ebuilds... I imagine that you don't actually want that change in your official ebuild. I'm working on the percona patches, I just haven't gotten there yet, also I've yet to get that familiar with the enterprise, but I'll work on that too. where's the bug on the -fPIC stuff?
(In reply to comment #40) > While I don't mind classic diffs, unified diffs are easier to use. I'll apply > shortly, thanks. What is 'uniffied diffs' means? You means that I need not to report a patch for 000_index.txt? And, I found that mysql-5.1.31 doesn't get configure options of --with-row-based-replication --with-zlib(changed to --with-zlib-dir)
a 'unified diff' is the same as running diff -u which is the the 'standard' definition of 'patch' for open source hackers. and I can't speak for robbat, but I'd dare say he'd appreciate a git patch even more, considering that's how he keeps mysql-extras. also newer versions of extras uses 0000_index.txt
(In reply to comment #43) > a 'unified diff' is the same as running diff -u which is the the 'standard' > definition of 'patch' for open source hackers. Okey, thank you. Hence I'll make patches with 'diff -u'. Currently, I cannot running mysqld. Becource there is some problem for /etc/init.d/mysql, maybe.
version? errors from running /etc/init.d/mysql start? (5.1.31 starts here)
Created attachment 183425 [details, diff] add-percona-5.0.77-b13-patches for the mysql-extras git repository. mysql-community won't actually build with these. I don't know why. Maybe someone else can figure it out.
Created attachment 183428 [details] mysql-community-5.0.77.ebuild this is a working ebuild for the mysql 5.0.77. I've commented out the percona patches in the mysql-extras tarball. for gentoo users install my mysql.eclass in an overlay, and this ebuild. manifest the ebuild and emerge --regen (the eclass changes metadata) and it should be good to go.
xenoterracide: 1. please stop putting 5.0 stuff in this bug. It's for MySQL 5.1. 2. I told you that the binlog-mirroring stuff was broken. 3. You can find the SRPM to see Percona's specfile here: http://www.percona.com/mysql/5.0.77-b13/RPM/rhel5/
sorry didn't realize that a version bump bug could only match one version.
It doesn't have to, but with 50 comments, this bug is getting very long.
um... then fix it? I mean it's only 2 years old? given it started as alpha, beta requests. but 5.1 is GA now for 2+ months and yes I've read what you said about you not wanting to release it yet. But bugs this old you can expect to have a large number of comments. I've opened bug 260574 for mysql 5.0.
Why not put it in the tree and p.mask it ?
(In reply to comment #45) > version? errors from running /etc/init.d/mysql start? (5.1.31 starts here) sorry, that was my mistake. I didn't append use about 'innodb', but my.cnf was described about innodb options. I rebuilt 5.1.31 with innodb, now fixed. I suppose that MySQL5.1 should be unmasked, because that had been released as an authentic production in Nov. 2008
Which eclass/ebuild were you using? Our official ones forcibly include innodb, as requested by upstream.
(In reply to comment #54) > Which eclass/ebuild were you using? Our official ones forcibly include innodb, > as requested by upstream. I'm using about /var/cvsroot/gentoo-x86/eclass/mysql.eclass,v 1.106 2009/02/11 11:29:48 robbat2 I check now the script, --with-innodb is called at configure_40_41_50() , but no called at configure_51() I needed to append use innodb for mysql-5.1
apparently innodb use flag was removed from the 5.0 ebuilds but not the 5.1 ones. as far as the vesion goes... (cvs string) I'm generally too lazy to remove such things. although I personally disagree with the removal of the innodb flag (lacks gentoo nature) it's something that'll need to be updated to be in line with the rest of the mysql packages. I don't honestly think not using innodb is a good idea regardless, I'd rather have a myisam useflag so I can disable that.
robbat2 09/02/28 10:49:50 Modified: mysql.eclass Log: Back in 2006 we updated 4.1 and 5.0 per upstreams request that InnoDB was always build. However 5.1 never got updated, so do it now. Revision Changes Path 1.107 eclass/mysql.eclass file : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/mysql.eclass?rev=1.107&view=markup plain: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/mysql.eclass?rev=1.107&content-type=text/plain diff : http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/mysql.eclass?r1=1.106&r2=1.107
5.1.32 just got released. I'm guessing that just bumping my 5.1.30 ebuild to 5.1.32 will work. however as always mysql-5.1.32.tar.gz has yet to be added to the mirrors. it seems to take 2-3 days after they announce the release to do so... how annoying.
xeno: Several mirrors have it already. http://mysql.mirror.iweb.ca/Downloads/MySQL-5.1/mysql-5.1.32.tar.gz works for me.
just a short notice that mysql 5.1.33 has been released.
*** Bug 266922 has been marked as a duplicate of this bug. ***
Created attachment 189376 [details] mysql.eclass update for 5.1.3x mysql_pkg_config()'s ${options} fixed for 5.1.3x tested with mysql 5.1.32/5.1.34 and amarok 2.0.2/2.0.90 some installation path issues need to be investigated
5.1.34 is out, the 5.1.30 ebuild works for it. There is however some weird innodb bug in 5.1.33 / 5.1.34 which can make some tables crash mysql on a binary upgrade. http://bugs.mysql.com/bug.php?id=44030
(old) news: - 5.1.35 (GA) is out - 5.4.0 (beta) is out (5.4 is 5.1 with performance patches) - mysql changes its release model: it should be faster, have better quailty, be geared towards milestones, etc.. See http://blogs.sun.com/datacharmer/entry/mysql_has_a_new_release Our tree is falling behind. Do the current 5.1 or 5.4 releases still have reasons why not to have at least a pmasked official gentoo ebuild for them? Any particular mysql bug that needs to be resolved? Thanks for the info.
(In reply to comment #64) > (old) news: > - 5.1.35 (GA) is out > - 5.4.0 (beta) is out (5.4 is 5.1 with performance patches) > - mysql changes its release model: it should be faster, have better quailty, be > geared towards milestones, etc.. See > http://blogs.sun.com/datacharmer/entry/mysql_has_a_new_release > > Our tree is falling behind. Do the current 5.1 or 5.4 releases still have > reasons why not to have at least a pmasked official gentoo ebuild for them? Any > particular mysql bug that needs to be resolved? Thanks for the info. > I've tried the latest mysql.eclass and got error about unknown storage "ndb" so I had to remove ndb storage definition: --- mysql.eclass 2009-06-17 14:25:22.000000000 +0300 +++ mysql.eclass.patched 2009-06-12 18:06:43.000000000 +0300 @@ -379,7 +379,7 @@ # like configuration=max-no-ndb if use cluster ; then - plugins="${plugins},ndb,ndbcluster" + plugins="${plugins},ndbcluster" myconf="${myconf} --with-ndb-binlog" fi
Created attachment 194983 [details] server output Anyway, mysql server can not start getting me this output (DEBUG=4 set in /etc/conf.d/mysql) Then I tried to start it manually /usr/sbin/mysqld --user=mysql --basedir=/usr --datadir=/var/lib/mysql --socket=/var/run/mysqld/mysqld.socket 090617 14:50:39 InnoDB: Started; log sequence number 0 46409 090617 14:50:50 [Note] Starting MySQL Cluster Binlog Thread 090617 14:50:50 [Note] Event Scheduler: Loaded 0 events 090617 14:50:50 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.1.35' socket: '/var/run/mysqld/mysqld.socket' port: 3306 Gentoo Linux mysql-community-5.1.35 So i think the problem is in start-stop-daemon stuff If I manually run this command: mars ~ # start-stop-daemon --user mysql:mysql --verbose --start --background --pidfile /var/run/mysqld/mysqld.pid --exec /usr/sbin/mysqld -- --basedir=/usr --datadir=/var/lib/mysql --socket=/var/run/mysqld/mysqld.socket * Detaching to start `/usr/sbin/mysqld'... then nothing happens at all...
Created attachment 194992 [details] patch to init sctipt finally, it seems working with one additional patch
my overlay holds the latest incarnations of mysql-{community,mariadb} the layman file http://ftp.mars.arge.at/pub/overlay/geos_one-overlay.xml the overlay is called go-mysql also corrected the pbxt build (now in tree)
-community is now obsolete. Upstream has re-merged the community codebase with the former enterprise codebase. I intend to issue a package move after we've had a few versions >=5.0.83 in stable, but there is no further need to make new -community ebuilds. fyodor: have used the latest mysql-extras patches? Which ones need porting for 5.1/5.4/6.0, and have you done so? Esp the shared embedded libs patch.
(In reply to comment #69) > -community is now obsolete. Upstream has re-merged the community codebase with > the former enterprise codebase. I intend to issue a package move after we've > had a few versions >=5.0.83 in stable, but there is no further need to make new > -community ebuilds. ok. moving to mysql ebuilds. > > fyodor: have used the latest mysql-extras patches? Which ones need porting for > 5.1/5.4/6.0, and have you done so? Esp the shared embedded libs patch. > I used the latest (seems "semiofficial") extras version 20081211. All patches were applied seamlessly and this is all that I can say at this moment. Could you tell me the exact patch names related to embedded stuff? I see only 202_all_embedded-library-compile-5.0.38.patch
Since 200812, I've had 27 tagged points in the mysql-extras that I tested for releases, broken down into two during Feburary, one in April, and one in July. http://git.overlays.gentoo.org/gitweb/?p=proj/mysql-extras.git;a=tags So, please, do try the very latest ones. embedded-library-compile is the correct patch for the shared embedded libs, it does need porting to 5.1 still I think, I'm not sure about sure official patchset. For any changed/additional patches in there, do notice that the patches moved to a 5 digit prefix, used as follows: 0xxx0 - old patches from before, increment value is generally 10, not 1, to make it easier to insert patches into the sequence. 10xxx - percona base patches (unmodified) 11xxx - percona highperf patches (unmodified) 15xxx - fixes to percona patches specific to Gentoo
http://dev.mysql.com/downloads/mysql/5.1.html#source says 5.1.37 was released meanwhile. (-> update summary)
Is there an overlay available where the ebuild can be tested before it is added to the tree? "mysql-testing" as listed by layman contains nothing useful.
5.1.38 is out ftr http://dev.mysql.com/doc/refman/5.1/en/news-5-1-38.html Sept 1, 2009
FYI, 5.1.39 has been released (4th September 2009): http://dev.mysql.com/doc/refman/5.1/en/news-5-1-39.html
5.1.40 is out. Any ETA? http://dev.mysql.com/doc/refman/5.1/en/news-5-1-40.html
*** Bug 291135 has been marked as a duplicate of this bug. ***
FYI, 5.1.41 has been released (05 November 2009): http://dev.mysql.com/doc/refman/5.1/en/news-5-1-41.html
According to MySQL's lifecycle calendar (http://www.mysql.com/about/legal/lifecycle/#calendar), the "Active Lifecycle" of the 5.0 branch ends in 3 weeks. This means, that with the new year, only the most severe bugs will be addressed and no active development will further occur in the branch. The 5.1 branch is GA for a year now, this bug is more then 2 years old and way too long. Gentoo should have had stable 5.1 ebuilds for long - now its really high time. Could we please move a bit here? Robin, you will be probably the only person who can push this to the tree and knows the current status of the ebuilds/classes/patches attached to this bug. So, please, allow at least the current hardmasked ebuild/eclass/patchset into the tree, let us know what you think what is missing or problematic. There are tons of people subscribed to this bug who, I guess, are willing to help with the ebuilds or with some testing. Thanks, Pavel
We (myself and jmbsvicetto) ARE working on it: http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=summary And the usual changes to the mysql-extras repo of the patches. It fails a bunch of the upstream testsuites still, but it does pass more of my personal tests. If everybody here would try 5.1.39 AND 5.1.41 on there, with the test instructions in the ebuild files, it would be nice to get rid of all all the attachments to this bug that are no longer relevant.
Spotted quickly in 5.1.41: configure: WARNING: unrecognized options: --with-row-based-replication --with-zlib --with-zlib has been renamed to --with-zlib-dir
and that on the start of the merge: QA Notice: EXPORT_FUNCTIONS is called before inherit in mysql.eclass. For compatibility with <=portage-2.1.6.7, only call EXPORT_FUNCTIONS after inherit(s). other then this, why do you even mess with the cmake stuff, its for windows only (if this does have a reason just ignore me :D) for 5.1.39 Failed 3/845 tests, 99.64% were successful. Failing test(s): main.mysql_client_test main.information_schema main.mysql_comments for 5.1.41 Failed 3/865 tests, 99.65% were successful. Failing test(s): main.mysql_client_test main.information_schema main.mysql_comments
(In reply to comment #81) > Spotted quickly in 5.1.41: > configure: WARNING: unrecognized options: --with-row-based-replication > --with-zlib > > --with-zlib has been renamed to --with-zlib-dir > --with-row-based-replication has been removed in 5.1.6 (http://dev.mysql.com/doc/refman/5.1/en/configure-options.html)
(In reply to comment #82) > for 5.1.39 > Failed 3/845 tests, 99.64% were successful. > > for 5.1.41 > Failed 3/865 tests, 99.65% were successful. > > Failing test(s): main.mysql_client_test main.information_schema > main.mysql_comments > These tests fail because they expect USE=latin1. Upstream still leaves latin1/latin1_swedish_ci as the defaults. Gentoo testing wants utf8 (with the -latin1 default) which breaks the 3 tests above. I've tried both -latin1 (with the results above) and +latin1 (all tests passed).
(In reply to comment #83) > (In reply to comment #81) > > Spotted quickly in 5.1.41: > > configure: WARNING: unrecognized options: --with-row-based-replication > > --with-zlib > > > > --with-zlib has been renamed to --with-zlib-dir > > > > --with-row-based-replication has been removed in 5.1.6 > (http://dev.mysql.com/doc/refman/5.1/en/configure-options.html) > In addition, --without-row-based-replication was removed in 5.1.14 for USE=minimal
I do not think that the 01010_all_bootstrap_no_plugin.patch is required anymore since Gentoo Bug 158777 points to MySQL bug 24270. MySQL bug 24270 was fixed with 5.1.15. http://bugs.mysql.com/bug.php?id=24270
2 tests are also affected by http://bugs.mysql.com/bug.php?id=35485 This occurs when a wildcard DNS resolves for invalid_hostname and not_existing_host i.e. `host invalid_hostname` && `host not_existing_host` do not return NXDOMAIN The MariaDB project has a fix for this: http://bazaar.launchpad.net/~maria-captains/maria/5.1/revision/2737.1.15
mysql 5.5.0-m2 released.
configure observations: With the new plugin architecture in 5.1 (at least in >=5.1.39), plugins listed as dynamic in `./configure --help` will always be built as a .so unless specifically disabled with --without-plugin-PLUGINNAME. Other requirements, such as no library in the case of ibmidb2, may also disable it. Really, --with-plugins= are for those to be statically linked instead of generating a .so if possible 3rd party storage engines can be picked up by ./configure if they are unpacked into ${S}/storage before running eautoreconf. Special build areas may not be needed. Example: copying oqgraph/engine of the oqgraph plugin from openquery.com was pulled in by mysql configure. I am not an autotools expert so some may still need this. I couldn't get pbxt to be recognized for instance.
(In reply to comment #89) > configure observations: > > With the new plugin architecture in 5.1 (at least in >=5.1.39), plugins listed > as dynamic in `./configure --help` will always be built as a .so unless > specifically disabled with --without-plugin-PLUGINNAME. Other requirements, > such as no library in the case of ibmidb2, may also disable it. Really, > --with-plugins= are for those to be statically linked instead of generating a > .so if possible > > 3rd party storage engines can be picked up by ./configure if they are unpacked > into ${S}/storage before running eautoreconf. Special build areas may not be > needed. Example: copying oqgraph/engine of the oqgraph plugin from > openquery.com was pulled in by mysql configure. > I am not an autotools expert so some may still need this. I couldn't get pbxt > to be recognized for instance. > my mysql overlay goes that way http://linamh.mars.arge.at/wiki/mysql it already includes the following storage engines "pbxt revision soliddb xtradb innodb filesystem sphinx spider" innodb replaces the provided innodb with the upstream version xtradb replaces the provided innodb with the upstream version you cant activate both at the same time the whole thing is a modified mysql.eclass and new variable in the ebuild for adding the supported storage engine the downside of this approach is, it requires that the plug-in must be repackaged.
I know the devs working in the overlay are quite busy, so this is a request more than anything. The official overlay shows that PBXT is sourced from sourceforge. PBXT has left sourceforge in favor of launchpad https://launchpad.net/pbxt All future releases will be found there. Currently they are at 1.0.10c-rc. Comment #34 seems to show the more reliable URL at this time.
As per http://www.mysql.com/about/legal/lifecycle/#calendar , MySQL 5.0 has started it's EOL cycle. Only S1 bugs and security fixes will be considered. All other bugs would seem to be punted. I would love to see 5.1 come to Gentoo with 5.0 slowly being left behind upstream. Especially if the MariaDB flavor (askmonty.org), that actively listens to the community and supports stable 3rd party patches and projects (including Percona, XtraDB, and PBXT), could be included.
5.1 series available package.masked in the main tree now. Scheduled for package.unmask on 2010/02/08 00:00UTC. Only 5.1.39 has XtraDB support for now. XtraDB for 5.1.42 fails to configure/compile (uncomment at the top and you'll see). 5.1.43 is there too, but no extras available from other upstreams yet. PBXT is only available for 5.1.41 upstream, not integrated into our ebuilds. Hopefully BOTH Percona and PBXT update for 5.1.43 soon, and we can integrate those. geos_one: Can you please rebase your changes on the latest mysql.eclass and mysql-5.1.43 ebuild? Also, please run the entire testsuite FEATURES=test, if it's not passing, find out why the tests are failing, so we can see if they need to be disabled or fixed. The 5.1.* I've placed in the tree DO pass nearly every test. Those that I've disabled in the ebuild are noted with why they get disabled, and I'll be taking those items up with upstream within the next month. Re 5.4/MariaDB/Drizzle: Please open a new bug for each of those. I suggest also basing your work on the latest eclass and ebuilds. Maria + 5.4 should be fairly easy, Drizzle I'm not so sure about.
Drizzle is already in the tree, I'm co-maintaining it. Right now I'm swamped with work but expect major improvements to the ebuild in March.
the (In reply to comment #93) > geos_one: > Can you please rebase your changes on the latest mysql.eclass and mysql-5.1.43 > ebuild? Also, please run the entire testsuite FEATURES=test, if it's not > passing, find out why the tests are failing, so we can see if they need to be > disabled or fixed. The 5.1.* I've placed in the tree DO pass nearly every test. > Those that I've disabled in the ebuild are noted with why they get disabled, > and I'll be taking those items up with upstream within the next month. the eclass and the ebuild are now up-to-date but as i mentioned earlier this is only a "hack" the testsuite passes exept to of the included engines (the tests are not aware of plugins or try to load the so from the wrong location, pbxt is also not in the test to many changes to the std tests; but i am working on it)
I don't know if this should be commented here, but I've just read about that the Percona patches have been released for mysql-5.1 http://www.mysqlperformanceblog.com/2010/02/09/introducing-percona-patches-for-5-1/