I've attached the ebuild I've used to compile mysql 5.0 on my system. In addition, there is a modified php5 eclass supporting mysql and mysqli flags toghether. see http://www.francesco-riosa.com/gentoo/index.html
Created attachment 43332 [details] USE flag change for geometry configure --without-geometry does not compile so removed the relative use flag.
-updated to the latest snapshot -changed source uri --- mysql-5.0.2.ebuild 2004-11-05 13:12:51.000000000 +0100 +++ mysql-5.0.2-r1.ebuild 2004-11-09 17:22:46.788390520 +0100 @@ -4,7 +4,7 @@ inherit eutils gnuconfig #to accomodate -laadeedah releases -NEWP=${P}-alpha-nightly-20041018 +NEWP=${P}-alpha-nightly-20041109 SVER=${PV%.*} #normal releases: @@ -16,7 +16,7 @@ DESCRIPTION="A fast, multi-threaded, multi-user SQL database server" HOMEPAGE="http://www.mysql.com/" -SRC_URI="mirror://mysql/Downloads/${SDIR}/${NEWP}.tar.gz" +SRC_URI="http://downloads.mysql.com/snapshots/mysql-5.0/mysql-5.0.2-alpha-nightly-20041109.tar.gz" LICENSE="GPL-2" SLOT="0"
- upgraded to 20041115 (with some patching) - readded geometry USE flag - added ndb USE flag (it compile but still need testing) as usual at http://www.francesco-riosa.com/gentoo/index.html
night build 20041130 clean compile and run replication as slave silently fail, my fault?
re-synced with 4.1.7 ebuild, version bump (use flag change). initial support of bug #73881
- incompatible change you need to drop mysql database and recreate it (really, it start to respawn very fast with old database) - added logrotate support from 4.1.8 ebuild - look at new db "information_schema" does it came from M$ world ? - workaround for bug #75539
Synced with mysql-4.1.9.ebuild bug#78452 dev-db/mysql symlink vulnerability bug#77805 has been fixed by MySQL current snapshot is alpha-20050122-1327. Updated page im conformity to http://www.gentoo.org/main/en/name-logo.xml
Created attachment 51106 [details] mysql ebuild/eclass This ebuild use versionator.eclass and introduce a mysql.eclass. The bitkeeper sources ebuilds download the main version from mysql mirror system and then the patch from mine (3-4Mb). The most important result is that this ebuild can manage both 4.1 and 5.0 versions with pratically no change in the ebuild code (probably 4.0 too). Pay attention at the pkg_config() function, it doesn't use mysql_install_db anymore. The htmlized version of the ebuild is here http://www.francesco-riosa.com/gentoo/mysql-5.0.3_alpha20050213.ebuild.html The patch versus the best installable in gentoo is http://www.francesco-riosa.com/gentoo/mysql-4-5.ebuild.patch.html Should be nice have an opinion from one developer. regards Francesco Riosa
I have the latest 5.0 ebuild, and federated isnt supported in the ebuild. Might need a use flag federated, but to compile it in, it just needs the "--with-federated-storage-engine" added to the configure.. Great ebuild support, when is the 4.1 stuff gonna be in the tree??
added USEflag "extraengine", it build other storage engines depending on MySQL version
Created attachment 52874 [details] ebuild that can be renamed and used to install mysql-4.1, mysql-5.0 This ebuild alone is not very usefull, to get an overlay visit: http://www.francesco-riosa.com/gentoo/ Theese bugs are related: bug #78452 bug #83011
I've just discovered that my installation of mysql ( 5.0.5-beta-nightly-20050412 ) doesn't include a mysql.proc table. This is required for creating stored procedures. When I try to create stored procedures, I get the error: Table 'mysql.proc' doesn't exist Upon inspecting the mysql database, I have verified this issue: mysql> use mysql; Database changed mysql> show tables; +---------------------------+ | Tables_in_mysql | +---------------------------+ | columns_priv | | db | | func | | help_category | | help_keyword | | help_relation | | help_topic | | host | | procs_priv | | tables_priv | | time_zone | | time_zone_leap_second | | time_zone_name | | time_zone_transition | | time_zone_transition_type | | user | | user_info | +---------------------------+ 17 rows in set (0.01 sec) I would submit a bug directly to the mysql bugzilla page, but I assume they'll tell me I have an incorrect installation procedure, so I thought I'd check here first to see if anyone else has come across the same issue.
hem it's not working from a lot of time here, seems very strange that a so dark bug has not been managed by MySQL ==>> This make me think that it's a bug on how my ebuild manage the compiling. Since I never had time to go deep there is a workaround in nightly ebuilds: # ebuild "${PORTDIR_OVERLAY}/dev-db/mysql/mysql-5.0.5_beta20050412.ebuild" config this will create the databases and ask you for a password. I'm not testing this from one month now, please report if it not work anymore.
Right. Now I can create stored procedures, but all other sp operations result in a server crash, including: DROP PROCEDURE IF EXISTS `procedure_name`; call `procedure_name` (); The mysql client will report that: ERROR 2013 (HY000): Lost connection to MySQL server during query And the mysqld.err log will say something like: 050419 11:35:38 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.5-beta-nightly-20050412-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Still Not g.o Linux mysql-5.0.5_beta20050412 mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=16777216 read_buffer_size=258048 max_used_connections=1 max_connections=100 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0x8b97d70 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... Cannot determine thread, fp=0xb0d0fabc, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x81b69ac 0xffffe420 0x20202020 New value of fp=0x20202020 failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0x8bb47c0 = call sp_tmp_AllStaff('DK') thd->thread_id=1 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. Number of processes running now: 0 050419 11:37:26 mysqld restarted 050419 11:37:26 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... 050419 11:37:26 InnoDB: Starting log scan based on checkpoint at InnoDB: log sequence number 0 341083818. InnoDB: Doing recovery: scanned up to log sequence number 0 341083818 InnoDB: Last MySQL binlog file position 0 39500238, file name ./mysql-bin.000006 050419 11:37:28 InnoDB: Started; log sequence number 0 341083818 050419 11:37:28 [Note] Recovering after a crash using mysql-bin 050419 11:37:28 [Note] Starting crash recovery... 050419 11:37:28 InnoDB: Starting recovery for XA transactions... 050419 11:37:28 InnoDB: 0 transactions in prepared state after recovery 050419 11:37:28 [Note] Crash recovery finished. 050419 11:37:28 InnoDB: Starting recovery for XA transactions... 050419 11:37:28 InnoDB: 0 transactions in prepared state after recovery 050419 11:37:28 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.0.5-beta-nightly-20050412-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 Still Not g.o Linux mysql-5.0.5_beta20050412 Is anyone able to successfully call procedures yet ( from the mysql client )?
i'm closing this for the moment, as the bug itself is outdated, and francesco's slowly bringing in things from his overlay.
