Please write an ebuild for mysql-5.5.5 and -9999
There is also 5.5.6 (rc, 13 sep 2010) and 5.5.7 http://dev.mysql.com/doc/refman/5.5/en/news-5-5-6.html My request is related to http://bugs.mysql.com/bug.php?id=56871
Created attachment 248846 [details] mysql-5.5.6_rc.ebuild Based on latest 5.1-ebuild in tree, just adjusted the download filename.
1) I am unable to start it (after brainless etc-update :) ): # /etc/init.d/mysql start * Starting ... * Starting (/etc/mysql/my.cnf) * MySQL NOT started (0) [ !! ] * ERROR: mysql failed to start # du -b /etc/mysql/my.cnf 0 /etc/mysql/my.cnf 2) Works ok, after I get my.cnf from another instance of mysql-5.1.50-r1
5.5.8 is out and it's no longer beta/rc.
Yeah, we know. I hope to start working on an updated cmake version this week.
(In reply to comment #5) > Yeah, we know. > I hope to start working on an updated cmake version this week. Well, and where is it?
I have attached
Created attachment 258535 [details] MySQL 5.5.8 cmake Ebuild
This has been tested to BUILD OKAY using cmake on my amd64 Gentoo system. dnetdb02 ~ # uname -a Linux dnetdb02 2.6.34-gentoo #1 SMP Sun Jun 13 05:46:32 CDT 2010 x86_64 Intel(R) Xeon(R) CPU X5660 @ 2.80GHz GenuineIntel GNU/Linux dnetdb02 ~ # emerge --info Portage 2.1.9.27 (default/linux/amd64/10.0, gcc-4.4.5, glibc-2.12.1-r3, 2.6.34-gentoo x86_64) ================================================================= System uname: Linux-2.6.34-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_X5660_@_2.80GHz-with-gentoo-2.0.1 Timestamp of tree: Fri, 31 Dec 2010 16:00:01 +0000 app-shells/bash: 4.1_p9 dev-lang/python: 2.6.6-r1, 2.7.1, 3.1.3 dev-util/cmake: 2.8.3-r1 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.8 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.4.5, 4.5.2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -msse4 -msse4.1 -msse4.2 -mcx16 -msahf -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=core2 -msse4 -msse4.1 -msse4.2 -mcx16 -msahf -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j25" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 big-tables bzip2 cli cracklib crypt ctype cups curl cxx diskio dri ext4 ftp gd gdbm gpm iconv imap json mmx modules mudflap multilib mysql mysqli ncurses nls nptl nptlonly openmp pam pcre perl pppd python readline reflection session simplexml snmp soap spl sse sse2 ssl sysfs tcpd truetype unicode xml xmlrpc xorg zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY The only caveat was that I had to untar mysql-5.5.8.tar.gz, extract it, rename the mysql-5.5.8 directory to "mysql", re-tar the source, and manually create the ebuild digest for the .tar.gz file. Some further work will need to be done to the ebuild to make it handle the mysql-version number. Thanks.
Another glitch I have found is that the install puts header/include files into /usr/include/ instead of /usr/include/mysql/ Greg
> The only caveat was that I had to untar mysql-5.5.8.tar.gz, extract it, rename > the mysql-5.5.8 directory to "mysql", re-tar the source, and manually create > the ebuild digest for the .tar.gz file. Just adding S="${WORKDIR}/${P}" after inherit is enough to get around this. Just noticed your ebuild doesn't install mysql_install_db, haven't looked deeper into it.
(In reply to comment #8) > Created an attachment (id=258535) [details] > MySQL 5.5.8 cmake Ebuild > Note: this ebuild will implement the admittedly unstable configure -> cmake translation from upstream. They DO NOT recommend using it.
Running fine for me on 2 seperate x64 systems since i posted the ebuild. One of which is a very busy SQL server: dnetdb02 ~ # mysql -uroot -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 9829894 Server version: 5.5.8-debug-log Source distribution Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved. <snip> mysql> \q Bye dnetdb02 ~ # uname -a Linux dnetdb02 2.6.34-gentoo #1 SMP Sun Jun 13 05:46:32 CDT 2010 x86_64 Intel(R) Xeon(R) CPU X5660 @ 2.80GHz GenuineIntel GNU/Linux dnetdb02 ~ #
(In reply to comment #12) > Note: this ebuild will implement the admittedly unstable configure -> cmake > translation from upstream. They DO NOT recommend using it. jmbsvicetto is working on putting proper cmake support in the eclass. If you see the upstream packagers list, migrating to cmake IS recommended actually.
(In reply to comment #14) > (In reply to comment #12) > > Note: this ebuild will implement the admittedly unstable configure -> cmake > > translation from upstream. They DO NOT recommend using it. > jmbsvicetto is working on putting proper cmake support in the eclass. If you > see the upstream packagers list, migrating to cmake IS recommended actually. > I didn't mean any confusion. I was referring to the the user ebuild attached to this bug and it's use of configure. I read somewhere that the new autotools configure script is a hack conversion to cmake.
For me after the upgrade mysql doesn't start. Firstly, there is no "mysqld" in "/usr/sbin". After relinking it doesn't start with no error - just hangs on start. Just wanted to leave feedback :)
Hello! Anybody knows, when mysql-5.5.8.ebuild will be available through the portage tree? I'm really looking forward to install it.
(In reply to comment #8) > Created an attachment (id=258535) [details] > MySQL 5.5.8 cmake Ebuild > The mysql-5.5.8.ebuild doesn't work from the box unfortunately. Found mismatches: 1) As was said above header/include files are installed into /usr/include/instead of /usr/include/mysql/. 2) I add S="${WORKDIR}/${P}" string after inherit string to compile package. 3) Command emerge --config =dev-db/mysql-5.5.8 doesn't work because mysql_install_db installed into /usr/scripts instead of /usr/bin. Also you should call mysql_install_db script from /usr directory to find ./bin/my_print_defaults file. 4) There is no any examples of my.cnf config in the /etc/mysql directory. 5) At the end /etc/init.d/mysqld just doesn't start. Avery time I got "MySQL NOT started (0)". Here is a dump from /var/log/mysql/mysqld.err 110208 14:05:11 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=mysqld-bin' to avoid this problem. InnoDB: The InnoDB memory heap is disabled InnoDB: Mutexes and rw_locks use GCC atomic builtins InnoDB: Compressed tables use zlib 1.2.3 110208 14:05:11 InnoDB: Initializing buffer pool, size = 16.0M 110208 14:05:11 InnoDB: Completed initialization of buffer pool 110208 14:05:11 InnoDB: highest supported file format is Barracuda. 110208 14:05:11 InnoDB: 1.1.4 started; log sequence number 1595916 110208 14:05:11 [ERROR] Aborting 110208 14:05:11 InnoDB: Starting shutdown... 110208 14:05:12 InnoDB: Shutdown completed; log sequence number 1595916 110208 14:05:12 [Note]
Bump. Version 5.5.9 is generally available. Arch Linux already switched to 5.5 (starting with 5.5.9)
Hello, is there an ETA for when the 5.5.9 ebuild will be available in portage? Thanks!
Created attachment 265195 [details] mysql.cmake.eclass This UNOFFICIAL eclass is a supplement to the mysql.eclass in the mysql overlay. It utilizes the cmake-utils eclass. Put this into an overlay with the ebuild below to utilize it. Notes: MySQL upstream has apparently DROPPED support for manually changing index sizes for MyISAM. This eclass will die if the max-idx-128 use flag is set as a consequence. I say dropped because it no longer appears on the MyISAM documentation page nor in the build options. big-tables use flag is no longer looked at since all tables are now "big tables" according the the build instructions. I tried to make all the features and paths standard compared to a 5.1 install. It still may have flaws, but it is the best that I can see. The build log WILL moan about missing autotools related files, but it will build anyway. The QA notice needs to get fixed in the mysql.eclass in the overlay as the ChangeLog is installed properly and EXCEPTIONS-CLIENT is no where to be found
Created attachment 265199 [details] Ebuild for mysql-5.5.9. Pairs with mysql.cmake.eclass This ebuild uses the mysql.cmake.eclass also attached. Notes: pbxt is horribly broken (https://bugs.launchpad.net/pbxt/+bug/719276) in 5.5 and is disabled in the ebuild xtradb seems to have not been split out of the "Percona Server" for 5.5 and I could not get a resource for it, thus disabled. The test suite has changed since 5.1 with no compatibility for the old, split protocols using "emake". I tried to emulate what the 5.1 build did the best I could. The official test method would be "emake test-force", but not sure where the devs would like to take this. Comments and criticism are welcome for my contributions.
Install of your custom ebuild seemed to be fine, however I ran into the following issues. 1) Cannot start Mysql: 110309 8:12:05 [ERROR] Can't open the mysql.plugin table. Please run mysql_upgrade to create it. 110309 8:12:05 InnoDB: The InnoDB memory heap is disabled 110309 8:12:05 InnoDB: Mutexes and rw_locks use GCC atomic builtins 110309 8:12:05 InnoDB: Compressed tables use zlib 1.2.5 110309 8:12:05 InnoDB: Initializing buffer pool, size = 768.0M 110309 8:12:05 InnoDB: Completed initialization of buffer pool 110309 8:12:05 InnoDB: highest supported file format is Barracuda. 110309 8:12:06 InnoDB: Waiting for the background threads to start 110309 8:12:07 InnoDB: 1.1.5 started; log sequence number 1086720461057 110309 8:12:07 [ERROR] Aborting 110309 8:12:07 InnoDB: Starting shutdown... 110309 8:12:08 InnoDB: Shutdown completed; log sequence number 1086720461057 110309 8:12:08 [Note] /usr/sbin/mysqld: Unknown error 1146 2) cannot do mysql_install_db as it doesnt exist other than bzipped inside /usr/share/doc/mysql-5.5.9/scripts/mysql_install_db.bz2 3) ebuild config does not work dnetdb05 lib # ebuild /usr/portage/dev-db/mysql/mysql-5.5.9.ebuild config * MySQL MY_DATADIR is /var/lib/mysql * Moving MY_DATADIR from / to /var/lib/mysql mv: cannot move `/' to `/var/lib/mysql': Device or resource busy * ERROR: dev-db/mysql-5.5.9 failed: * Moving MY_DATADIR failed * * Call stack: * ebuild.sh, line 56: Called pkg_config * ebuild.sh, line 1434: Called mysql_pkg_config * mysql.eclass, line 1262: Called die * The specific snippet of code: * mv --strip-trailing-slashes -T "${old_MY_DATADIR_s}" "${MY_DATADIR_s}" \ * || die "Moving MY_DATADIR failed" * * If you need support, post the output of 'emerge --info =dev-db/mysql-5.5.9', * the complete build log and the output of 'emerge -pqv =dev-db/mysql-5.5.9'. * The complete build log is located at '/var/tmp/portage/dev-db/mysql-5.5.9/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-db/mysql-5.5.9/temp/die.env'. * S: '/var/tmp/portage/dev-db/mysql-5.5.9/work/mysql'
(In reply to comment #23) > Install of your custom ebuild seemed to be fine, however I ran into the > following issues. > > 1) Cannot start Mysql: > > 110309 8:12:05 [ERROR] Can't open the mysql.plugin table. Please run > mysql_upgrade to create it. Try running mysqld with "--skip-grant-tables --skip-networking" options so that mysql_upgrade can be run and then IMMEDIATELY restart mysqld using mysqladmin. This should only be done if a database was previously installed. The specific error involves upgrading from MySQL < 5.1. > 110309 8:12:07 [ERROR] Aborting > > 110309 8:12:07 InnoDB: Starting shutdown... > 110309 8:12:08 InnoDB: Shutdown completed; log sequence number 1086720461057 > 110309 8:12:08 [Note] > /usr/sbin/mysqld: Unknown error 1146 > > 2) cannot do mysql_install_db as it doesnt exist other than bzipped inside > /usr/share/doc/mysql-5.5.9/scripts/mysql_install_db.bz2 Please change in my eclass: -DINSTALL_SCRIPTDIR="share/doc/${PF}/scripts" to -DINSTALL_SCRIPTDIR=bin > > 3) ebuild config does not work > > dnetdb05 lib # ebuild /usr/portage/dev-db/mysql/mysql-5.5.9.ebuild config > * MySQL MY_DATADIR is /var/lib/mysql > * Moving MY_DATADIR from / to /var/lib/mysql > mv: cannot move `/' to `/var/lib/mysql': Device or resource busy This comes from the mysql.eclass in the overlay. It appears as if you have the MY_DATADIR environment variable set to / OR there may be a bug in the overlay's procedures and you should set MY_DATADIR.
dnetdb05 ~ # mysqld --defaults-file=/etc/mysql/my.cnf --skip-grant-tables --skip-networking 110310 8:10:57 [ERROR] Can't find messagefile '/usr/usr/share/mysql/errmsg.sys' Once i copied /usr/share/mysql/english/errmsg.sys to /usr/usr/share/mysql/errmsg.sys mysql started up ok with the following warnings: dnetdb05 ~ # mysqld --defaults-file=/etc/mysql/my.cnf --skip-grant-tables --skip-networking 110310 8:12:00 [ERROR] An old style --language value with language specific part detected: /usr/usr/share/mysql/ 110310 8:12:00 [ERROR] Use --lc-messages-dir without language specific part instead. I was then able to run mysql_upgrade - however i was not upgrading from v5.1 i allready had 5.5 on this server. Its possible the mysql_upgrade hadnt been run since the upgrade from 5.0/5.1 to 5.5 however. I will deploy this upgrade on a second server and test replication for a week and see how it goes.
A bug with mysql > 5.5.6 that I have come accross when combined with PHP: A PHP Error was encountered Severity: Notice Message: unserialize() [function.unserialize]: Error at offset 21628 of 26572 bytes This happens on any pages where unserializing is done. It does not happen with MySQL make/5.5.6, but does with cmake/5.5.9. I am unsure if this is a mysql <5.5.10 bug.
(In reply to comment #25) > dnetdb05 ~ # mysqld --defaults-file=/etc/mysql/my.cnf --skip-grant-tables > --skip-networking > 110310 8:10:57 [ERROR] Can't find messagefile > '/usr/usr/share/mysql/errmsg.sys' > > Once i copied /usr/share/mysql/english/errmsg.sys to > /usr/usr/share/mysql/errmsg.sys mysql started up ok with the following > warnings: > > dnetdb05 ~ # mysqld --defaults-file=/etc/mysql/my.cnf --skip-grant-tables > --skip-networking > 110310 8:12:00 [ERROR] An old style --language value with language specific > part detected: /usr/usr/share/mysql/ > 110310 8:12:00 [ERROR] Use --lc-messages-dir without language specific part > instead. This looks like left over cruft in your my.cnf that might also have contributed to the the first error. Many options have been deprecated or removed from 5.0 -> 5.1 -> 5.5. Please review the documentation as to what is current or contact me directly if you wish help with this.
This ChangeLog entry for mysql-5.5.10 (not yet released) impacts Gentoo's build and some would see it as significant for a cmake build: The DEFAULT_CHARSET and DEFAULT_COLLATION CMake options did not work. (Bug #58991)
Bump. Version 5.5.10 is now GA.
I'm currently working on new eclasses and updated ebuild for mysql-5.5.10. I hope to add it to the overlay before the weekend.
*** Bug 359385 has been marked as a duplicate of this bug. ***
I've committed some initial work to the overlay. It's still a work in progress, though. At the moment mysql builds but I've yet to test if it runs. I'm currently working on tests and then will have to focus on building a shared libmysqld as this is still not fixed on upstream build system.
(In reply to comment #32) > I've committed some initial work to the overlay. It's still a work in progress, > though. > At the moment mysql builds but I've yet to test if it runs. I'm currently > working on tests and then will have to focus on building a shared libmysqld as > this is still not fixed on upstream build system. I've made some progress in the overlay ebuild. I've added a revised patch from the upstream bug and got libmysqld built as a shared lib. I got tests running and only got 6 failures. I still need to add the logic to check what storage engines are available to build.
(In reply to comment #33) > (In reply to comment #32) > > I've committed some initial work to the overlay. It's still a work in progress, > > though. > > At the moment mysql builds but I've yet to test if it runs. I'm currently > > working on tests and then will have to focus on building a shared libmysqld as > > this is still not fixed on upstream build system. > > I've made some progress in the overlay ebuild. I've added a revised patch from > the upstream bug and got libmysqld built as a shared lib. I got tests running > and only got 6 failures. > I still need to add the logic to check what storage engines are available to > build. Any updates it has now been nearly a month? 5.5.11 is now out, and 5.6 is not far away from GA
I'll be bumping to 5.5.11 today. The most important bit missing is the detection of plugins / storage engines. In any case, anyone interested can test the ebuild in the overlay.
I was able to install 5.5.12 today from the overlay and it is working. However, I noticed when I connect using mysql client, it says Server version: 5.5.12-debug-log. How can I compile a version without debugging? I do not have the debug USE flag set.
(In reply to comment #36) > I was able to install 5.5.12 today from the overlay and it is working. > However, I noticed when I connect using mysql client, it says Server version: > 5.5.12-debug-log. > > How can I compile a version without debugging? I do not have the debug USE > flag set. I'm still working on the ebuild / eclass. I'll try to fix this later today.
(In reply to comment #37) > (In reply to comment #36) > > I was able to install 5.5.12 today from the overlay and it is working. > > However, I noticed when I connect using mysql client, it says Server version: > > 5.5.12-debug-log. > > > > How can I compile a version without debugging? I do not have the debug USE > > flag set. > > I'm still working on the ebuild / eclass. I'll try to fix this later today. How is the progress going on this? Thanks.
This has been done, though it got forgotten to close this bug: 14 Jul 2011; Jorge Manuel B. S. Vicetto <jmbsvicetto@gentoo.org> +mysql-5.5.14.ebuild: [dev-db/mysql] Adding mysql-5.5.14 from the overlay.
Reopening, as it's still in package.mask on purpose, until we get more user feedback. Everybody on the CC list, please test it and report back.
Works well here once I ironed out some teething problems with the new binaries. After upgrading the new version of MySQL was complaining about missing index files and was throwing up some odd errors relating to this. Once I downgraded again, did a mysqldump, wiped the database directory, upgraded and then imported the entire database again it seems to have been OK. Since doing the full dump/restore things have been running without any incident.
I upgraded from overlay 5.5.13 to 5.5.14 in portage. It worked fine but I noticed that it is still the debug version (5.5.14-debug-log) although I don't have debug USE flag set.
I have just performed upgrade from 5.1.56 to 5.5.14 without any problems - also DB is working as it did before
mysql-5.5.15 added to the overlay[1]. [1] - http://git.overlays.gentoo.org/gitweb/?p=proj/mysql.git;a=commit;h=99bdd95e70764bf50b56c64caa6d6abfd7412447
Unfortunately upon revdep-rebuild I got following errors: revdep-rebuild * Configuring search environment for revdep-rebuild * Checking reverse dependencies * Packages containing binaries and libraries broken by a package update * will be emerged. * Collecting system binaries and libraries * Generated new 1_files.rr * Collecting complete LD_LIBRARY_PATH * Generated new 2_ldpath.rr * Checking dynamic linking consistency [ 45% ] * broken /usr/lib/apr-util-1/apr_dbd_mysql-1.so (requires libmysqlclient_r.so.16) [ 47% ] * broken /usr/lib/collectd/mysql.so (requires libmysqlclient.so.16) [ 73% ] * broken /usr/lib/perl5/vendor_perl/5.12.3/i686-linux/auto/DBD/mysql/mysql.so (requires libmysqlclient.so.16) * broken /usr/lib/php5.3/apache2/libphp5.so (requires libmysqlclient.so.16) * broken /usr/lib/php5.3/bin/php (requires libmysqlclient.so.16) [ 100% ] * Generated new 3_broken.rr * Assigning files to packages * /usr/lib/apr-util-1/apr_dbd_mysql-1.so -> dev-libs/apr-util * /usr/lib/collectd/mysql.so -> app-admin/collectd * /usr/lib/perl5/vendor_perl/5.12.3/i686-linux/auto/DBD/mysql/mysql.so -> dev-perl/DBD-mysql * /usr/lib/php5.3/apache2/libphp5.so -> dev-lang/php * /usr/lib/php5.3/bin/php -> dev-lang/php * Generated new 4_raw.rr and 4_owners.rr * Cleaning list of packages to rebuild * Generated new 4_pkgs.rr * Assigning packages to ebuilds * Generated new 4_ebuilds.rr * Evaluating package order * Generated new 5_order.rr * All prepared. Starting rebuild emerge --complete-graph=y --oneshot app-admin/collectd:0 dev-lang/php:5.3 dev-libs/apr-util:1 dev-perl/DBD-mysql:0 .......... Calculating dependencies / !!! Problem resolving dependencies for dev-lang/php:5.3 ... done! [ebuild R ] dev-perl/DBD-mysql-4.01.7 [ebuild R ] dev-libs/apr-util-1.3.11 [ebuild R ~] app-admin/collectd-5.0.0-r1 COLLECTD_PLUGINS="-cpu* -cpufreq* -disk* -mysql* -processes* -sensors* -tcpconns*" [ebuild R ] dev-lang/php-5.3.6 USE="-gd*" !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: dev-lang/php:5.3 (dev-lang/php-5.3.6::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (dev-lang/php-5.3.6::gentoo, installed) pulled in by =dev-lang/php-5.3.6[gd] required by (dev-lang/php-5.3.6::gentoo, installed) =dev-lang/php-5.3.6[gd] required by (dev-lang/php-5.3.6::gentoo, ebuild scheduled for merge) !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. * Build finished correctly. Removing temporary files... * You can re-run revdep-rebuild to verify that all libraries and binaries * are fixed. Possible reasons for remaining inconsistencies include: * orphaned files * deep dependencies * packages installed outside of portage's control * specially-evaluated libraries
After update I cannot start Akonadi nor use Amarok collection. Shall I follow some additional steps to be able to?
(In reply to comment #45) > Unfortunately upon revdep-rebuild I got following errors: <snip> > [ebuild R ] dev-lang/php-5.3.6 USE="-gd*" > > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > dev-lang/php:5.3 > > (dev-lang/php-5.3.6::gentoo, ebuild scheduled for merge) pulled in by > (no parents that aren't satisfied by other packages in this slot) > > (dev-lang/php-5.3.6::gentoo, installed) pulled in by > =dev-lang/php-5.3.6[gd] required by (dev-lang/php-5.3.6::gentoo, installed) > =dev-lang/php-5.3.6[gd] required by (dev-lang/php-5.3.6::gentoo, ebuild > scheduled for merge) > > > !!! Enabling --newuse and --update might solve this conflict. > !!! If not, it might help emerge to give a more specific suggestion. This is not a mysql issue but an issue with enabled use flags for php. You should run emerge -uDavN @world and update your use flags to fix this issue.
(In reply to comment #46) > After update I cannot start Akonadi nor use Amarok collection. > > Shall I follow some additional steps to be able to? What errors are you getting and did you emerge akonadi and amarok after updating mysql?
(In reply to comment #48) > (In reply to comment #46) > > After update I cannot start Akonadi nor use Amarok collection. > > > > Shall I follow some additional steps to be able to? > > What errors are you getting and did you emerge akonadi and amarok after > updating mysql? recompiled akonadi: http://pastebin.com/BUPvcLrq amarok indeed worked after recompilation.
(In reply to comment #49) > (In reply to comment #48) > > (In reply to comment #46) > > > After update I cannot start Akonadi nor use Amarok collection. > > > > > > Shall I follow some additional steps to be able to? > > > > What errors are you getting and did you emerge akonadi and amarok after > > updating mysql? > > recompiled akonadi: > > http://pastebin.com/BUPvcLrq Please open a new bug report about this and be sure to include the errors in the bug report and not on a transient paste site.
(In reply to comment #50) > (In reply to comment #49) > > (In reply to comment #48) > > > (In reply to comment #46) > > > > After update I cannot start Akonadi nor use Amarok collection. > > > > > > > > Shall I follow some additional steps to be able to? > > > > > > What errors are you getting and did you emerge akonadi and amarok after > > > updating mysql? > > > > recompiled akonadi: > > > > http://pastebin.com/BUPvcLrq > > Please open a new bug report about this and be sure to include the errors in > the bug report and not on a transient paste site. Done: https://bugs.gentoo.org/show_bug.cgi?id=377555
i 've just installed 5.5.15 from mysql overlay, but i am not able to do 'emerge --config =dev-db/mysql-5.5.15 there is no /usr/bin/mysql_install_db only /usr/share/mysql/scripts/mysql_install_db when trying to do the replace of script inside mysql-v2.eclass, it reports Ready to configure dev-db/mysql-5.5.15? [Yes/No] * Please provide a password for the mysql 'root' user now, in the * MYSQL_ROOT_PASSWORD env var or through the /root/.my.cnf file. * Avoid ["'\_%] characters in the password > * Retype the password > FATAL ERROR: Could not find ./bin/my_print_defaults If you compiled from source, you need to run 'make install' to copy the software into the correct location ready for operation. If you are using a binary release, you must either be at the top level of the extracted archive, or pass the --basedir option pointing to that location. * ERROR: dev-db/mysql-5.5.15 failed (config phase): * Failed to run mysql_install_db. Please review /var/log/mysql/mysqld.err AND /var/tmp/portage/dev-db/mysql-5.5.15/temp/mysql_install_db.log * * Call stack: * ebuild.sh, line 56: Called pkg_config * environment, line 3587: Called mysql-v2_pkg_config * environment, line 3241: Called die * The specific snippet of code: * die "Failed to run mysql_install_db. Please review /var/log/mysql/mysqld.err AND ${TMPDIR}/mysql_install_db.log"; * * If you need support, post the output of 'emerge --info =dev-db/mysql-5.5.15', * the complete build log and the output of 'emerge -pqv =dev-db/mysql-5.5.15'. * This ebuild used the following eclasses from overlays: * /var/lib/layman/mysql/eclass/mysql-v2.eclass * /var/lib/layman/mysql/eclass/mysql-cmake.eclass * /var/lib/layman/mysql/eclass/mysql_fx.eclass * This ebuild is from an overlay named 'mysql': '/var/db/pkg/' * The complete build log is located at '/var/tmp/portage/dev-db/mysql-5.5.15/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-db/mysql-5.5.15/temp/environment'. * S: '/var/tmp/portage/dev-db/mysql-5.5.15/work/mysql-5.5.15' there is no mysqld.err log, because it couldnot run mysql_install_db specific to /usr/share/mysql/scripts/mysql_install_db FATAL ERROR: Could not find ./bin/my_print_defaults If you compiled from source, you need to run 'make install' to copy the software into the correct location ready for operation. If you are using a binary release, you must either be at the top level of the extracted archive, or pass the --basedir option pointing to that location.
update: after creating a script inside /usr/bin by copying the other from /usr/share/mysql/scripts/mysql_install_db and --- /usr/share/mysql/scripts/mysql_install_db 2011-08-04 15:38:46.000000000 +0300 +++ /usr/bin/mysql_install_db 2011-08-04 16:42:24.069003547 +0300 @@ -19,7 +19,7 @@ # # All unrecognized arguments to this script are passed to mysqld. -basedir="" +basedir=/usr/ builddir="" ldata="./data" langdir="" i am able to do /usrb/bin/mysql_install_db and its successfull. but doing emerge --config =dev-db/mysql-5.5.15 it seems that it has the same problem with basedir.. any idea? :/
What is the status of ebuild update? Version 5.5 of MySQL was released a year and a day ago :) maybe it is a good time to put it in Gentoo :)
Guys, please complete the ebuild for MySQL 5.5*, already it's time. I'm an Gentoo evangelist in our company dedicated to web-development and we're waiting for MySQL 5.5 longer than 1,5 year :-( It's unpleasant, that in other distros is MySQL 5.5 already long done. Please ... thank you!
(In reply to comment #55) > Guys, please complete the ebuild for MySQL 5.5*, already it's time. > > I'm an Gentoo evangelist in our company dedicated to web-development and > we're waiting for MySQL 5.5 longer than 1,5 year :-( It's unpleasant, that > in other distros is MySQL 5.5 already long done. > > Please ... thank you! As we've asked before, please provide us some feedback on the masked ebuilds in the tree or in the mysql overlay.
Is it possible to put MySQL in slots? I mean I'm using 5.1.61 here which is fine, since most (if not all) all providers have version 5.1. So, I guess it would be good to bump the version to 5.5, but it would also be better to have 5.1 in slot too.
No, slotted mysql is NOT possible. We tried it years ago, and it broke many more systems because nothing expects the library and binary names to have versions on them.
(In reply to comment #58) > No, slotted mysql is NOT possible. We tried it years ago, and it broke many > more systems because nothing expects the library and binary names to have > versions on them. All right, fair enough. Then, what I would at least expect is that the 5.1 version stays in the tree for some time, even when the 5.5 ebuilds go into testing and stable. Is this too much to ask?
I still have 4.0 in the tree, why do you think I'm going to remove 5.1? Please test the overlays! I've had less than one handful of users give me actual solid reports of it working so I can get it shipping.
I can comment on the 5.5 overlay. We (DesuraNET) use a purely Gentoo-only, bleeding edge-ish layout on about 12 servers including 2 x copies of the very latest MySQL 5.5 ebuilds (5.5.22). Since about 5.5.10 we have been using MySQL ebuilds from both the overlay and sourced from this bug without issue. Our DB server handles around 35k queries per minute (this has been reduced due to memcached recently), and we have not had a single issue! The major issue i forsee about unmasking MySQL 5.5 will be application support of MySQL 5.5, over the stability of MySQL itself. - Greg
I am also running unmasked 5.5 version in webdevelopment environment for months now without a single problem. Also used it on desktop for embedded apps like amarok and everything works for me as expected.
dev-db/mysql-5.5.22 (gentoo portage) I can't create fresh database: # /usr/share/mysql/scripts/mysql_install_db FATAL ERROR: Could not find ./bin/my_print_defaults If you compiled from source, you need to run 'make install' to copy the software into the correct location ready for operation. If you are using a binary release, you must either be at the top level of the extracted archive, or pass the --basedir option pointing to that location.
Should bug #392361 be blocker for this bug?
I've a couple of small mysql servers running inside virtual-server, both geographically replicated (circular, 3 srvs) which are going well from ~4 month. Speaking of version 5.5.18 but can test the latest if needed. Tables are almost all innodb with some myisam. # vserver-stat CTX PROC VSZ RSS userTIME sysTIME UPTIME NAME 3306 36 8.7G 7.6G 1d21h28 18h14m00 120d22h52 db1 3307 41 1.7G 259.5M 2h45m48 33m12s31 120d22h52 db2
No new messages? :-(( Last stable MySQL in packages is version "5.1.62-r1" and newer are hardmasked :-(
(In reply to comment #60) > Please test the overlays! I've had less than one handful of users give me > actual solid reports of it working so I can get it shipping. @Robin: I agree that we need to stress test the overlay. Maybe it's time to make an official call for testers in a blog or forum post or other medium. I think I've nailed down the USE="minimal" issues. I'll work on bug 392361 next to get new installs via emerge --config done. Overall, we may just need minor tweaks from here.
It is dissapointing that this isnt unmasked and further maintained in portage. Ubuntu which is a less aggressively maintained (from a stable/unstable perspective) distro than Gentoo has had MySQL 5.5 in its stable release for 5 months now. I have been using MySQL 5.5 (5.5.27 now) on ~8 Gentoo systems for close to 2 years now with only a few minor issues with ebuilds initially - nowdays extremely stable and no compatibility issues. MySQL 5.6 is going to be GA within the next couple of months - Gentoo needs to get both 5.5 as stable, and ebuilds going for 5.6 so we dont get left behind!
(In reply to comment #68) > It is dissapointing that this isnt unmasked and further maintained in > portage. > > Ubuntu which is a less aggressively maintained (from a stable/unstable > perspective) distro than Gentoo has had MySQL 5.5 in its stable release for > 5 months now. > > I have been using MySQL 5.5 (5.5.27 now) on ~8 Gentoo systems for close to 2 > years now with only a few minor issues with ebuilds initially - nowdays > extremely stable and no compatibility issues. > > MySQL 5.6 is going to be GA within the next couple of months - Gentoo needs > to get both 5.5 as stable, and ebuilds going for 5.6 so we dont get left > behind! I felt the same way as you. To fix it, I've been working with the mysql team submitting patches to get all the bugs squashed. 5.5 is a big jump when it comes to building. autotools -> cmake isn't that simple. Lots of details changed when upstream created the cmake scripts too. I would rather deliver a quality product on a mission critical item then having too many missing things. Personally, I'd never push out MySQL on it's first GA either. Too many little things. All that said, I feel good that we should now make official strides to advertise, seriously test and report the state of the overlay. Once that comes back positive, I believe that mysql team would push for 5.5 series stables.
5.5 is in the main tree now, and out of package.mask. Please test it cautiously.
