https://mariadb.com/kb/en/mariadb-5533a-changelog/
New maintenance release MariaDB 5.5.34 is now available. https://mariadb.com/kb/en/mariadb-5534-changelog/
MariaDB 5.5.34 has just been pushed to the mysql overlay
(In reply to Brian Evans from comment #2) > MariaDB 5.5.34 has just been pushed to the mysql overlay Any news on adding this to main tree? I'm using MariaDB in production, it would be nice to have a new version.
*** Bug 497888 has been marked as a duplicate of this bug. ***
MariaDB 5.5.35 was released on 29 Jan 2014. Release notes https://mariadb.com/kb/en/mariadb-5535-release-notes/
*** Bug 499710 has been marked as a duplicate of this bug. ***
Can we please get 5.5.34 in the overlay back please? It seems 5.5.35 has some serious bugs, that crash the whole server! More at https://mariadb.atlassian.net/browse/MDEV-5611?filter=-4 The MariaDB server at work (5.5.35, Windows though) crashed once today since I upgraded. At home (Linux, 5.5.35 from the overlay) crashed once when I run a query. Crash log (I will report upstream): 140205 15:58:42 [Note] /usr/sbin/mysqld: ready for connections. Version: '5.5.35-MariaDB-log' socket: '/var/run/mysqld/mysqld.sock' port: 0 Source distribution 140205 17:24:25 [ERROR] 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. To report this bug, see http://kb.askmonty.org/en/reporting-bugs 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. Server version: 5.5.35-MariaDB-log key_buffer_size=25165824 read_buffer_size=131072 max_used_connections=1 max_threads=52 thread_count=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 138638 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. Thread pointer: 0x0x7fb8acac1000 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... stack_bottom = 0x7fb8c88afed8 thread_stack 0x48000 /usr/sbin/mysqld(my_print_stacktrace+0x26)[0x9ca0d6] /usr/sbin/mysqld(handle_fatal_signal+0x398)[0x69a458] /lib64/libpthread.so.0(+0xfbb0)[0x7fb8c9cc1bb0] /usr/sbin/mysqld(_ZN10Item_field10fix_fieldsEP3THDPP4Item+0x19e)[0x6b416e] /usr/sbin/mysqld(_ZN9Item_func10fix_fieldsEP3THDPP4Item+0x180)[0x6dddc0] /usr/sbin/mysqld(_Z11setup_condsP3THDP10TABLE_LISTR4ListIS1_EPP4Item+0x1e6)[0x550fa6] /usr/sbin/mysqld(_ZN4JOIN7prepareEPPP4ItemP10TABLE_LISTjS1_jP8st_orderbS7_S1_S7_P13st_select_lexP18st_select_lex_unit+0x394)[0x5bf8f4] /usr/sbin/mysqld(_ZN18st_select_lex_unit7prepareEP3THDP13select_resultm+0x95d)[0x5feced] /usr/sbin/mysqld(_Z21mysql_derived_prepareP3THDP3LEXP10TABLE_LIST+0x235)[0x56dc45] /usr/sbin/mysqld(_Z27mysql_handle_single_derivedP3LEXP10TABLE_LISTj+0xec)[0x56e92c] /usr/sbin/mysqld(_ZN13st_select_lex14handle_derivedEP3LEXj+0x3e)[0x580bce] /usr/sbin/mysqld(_ZN4JOIN7prepareEPPP4ItemP10TABLE_LISTjS1_jP8st_orderbS7_S1_S7_P13st_select_lexP18st_select_lex_unit+0xea)[0x5bf64a] /usr/sbin/mysqld(_Z12mysql_selectP3THDPPP4ItemP10TABLE_LISTjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_select_lex+0x8ec)[0x5c9d5c] /usr/sbin/mysqld(_Z13handle_selectP3THDP3LEXP13select_resultm+0x2cc)[0x5cfabc] /usr/sbin/mysqld[0x58388b] /usr/sbin/mysqld(_Z21mysql_execute_commandP3THD+0x4a02)[0x58d272] /usr/sbin/mysqld(_Z11mysql_parseP3THDPcjP12Parser_state+0x119)[0x58f479] /usr/sbin/mysqld(_Z16dispatch_command19enum_server_commandP3THDPcj+0x135e)[0x59086e] /usr/sbin/mysqld(_Z24do_handle_one_connectionP3THD+0x173)[0x62da93] /usr/sbin/mysqld(handle_one_connection+0x4a)[0x62db6a] /lib64/libpthread.so.0(+0x7fda)[0x7fb8c9cb9fda] /lib64/libc.so.6(clone+0x6d)[0x7fb8c8db99ad] Trying to get some variables. Some pointers may be invalid and cause the dump to abort. Query (0x7fb8a1c14018): is an invalid pointer Connection ID (thread ID): 13 Status: NOT_KILLED Maybe hard mask it?
I reported upstream: https://mariadb.atlassian.net/browse/MDEV-5617
I dropped all the older 5.5 ebuilds as they had open security issues. Since you seem to have hit a serious regression, I'm going to restore 5.5.34 for now.
Done. 16:29 < irker515> proj/mysql: jmbsvicetto dev-db/mariadb/: Restore mysql-5.5.34 per regression reported on bug 490580 by Vasilis Lourdas.
Thank you. I confirmed this behavior in 4 servers so far (2 Gentoo boxes, 1 Debian Wheezy and Windows XP).
5.5.35-r1 with patch which fix this behaviour isn't way to go? Anyway, I'd like to propose to drop mariadb from portage, because it's still 5.5.32 there and users may not notice, that all development is in overlay.
The cause of the issue was the sql mode used in my.cnf (sql_mode=ONLY_FULL_GROUP_BY). Apparently, an earlier commit that went into 5.5.35 caused this regression, while with 5.5.34 there was no issue. The regression has already been fixed and will make it to 5.5.36 which is set for release in 21st. A temporary fix is to remove ONLY_FULL_GROUP_BY from sql_mode. It's ok by me if 5.5.34 is removed again from the tree.
(In reply to David Heidelberger (okias) from comment #12) > 5.5.35-r1 with patch which fix this behaviour isn't way to go? > > Anyway, I'd like to propose to drop mariadb from portage, because it's still > 5.5.32 there and users may not notice, that all development is in overlay. No, we won't remove mariadb from the tree. I haven't bumped it on the tree yet as I've been going over eclass changes that need to be pushed before I can bump it on the tree. (In reply to Vasilis Lourdas from comment #13) > The cause of the issue was the sql mode used in my.cnf > (sql_mode=ONLY_FULL_GROUP_BY). Apparently, an earlier commit that went into > 5.5.35 caused this regression, while with 5.5.34 there was no issue. The > regression has already been fixed and will make it to 5.5.36 which is set > for release in 21st. > > A temporary fix is to remove ONLY_FULL_GROUP_BY from sql_mode. It's ok by me > if 5.5.34 is removed again from the tree. I'll keep it around until 5.5.36 is released.
MariaDB 5.5.36 released into the overlay
Please check Manifest. There's probably something wrong with the checksum: >>> Downloading 'http://ftp-stud.hs-esslingen.de/pub/Mirrors/mariadb/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz' --2014-02-25 17:41:10-- http://ftp-stud.hs-esslingen.de/pub/Mirrors/mariadb/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz Location: http://mirror2.hs-esslingen.de/mariadb/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz [following] --2014-02-25 17:41:10-- http://mirror2.hs-esslingen.de/mariadb/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz Length: 45767693 (44M) [application/octet-stream] Saving to: ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ [...] 2014-02-25 17:41:14 (11,6 MB/s) - ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ saved [45767693/45767693] !!! Fetched file: mariadb-5.5.36.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 45767693 !!! Expected: 45761732 Refetching... File renamed to '/usr/portage/distfiles/mariadb-5.5.36.tar.gz._checksum_failure_.a90a2t' >>> Downloading 'http://mirrors.fe.up.pt/pub/mariadb/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz' --2014-02-25 17:41:14-- http://mirrors.fe.up.pt/pub/mariadb/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz Length: 45767693 (44M) Saving to: ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ [...] 2014-02-25 17:41:16 (23,0 MB/s) - ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ saved [45767693/45767693] !!! Fetched file: mariadb-5.5.36.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 45767693 !!! Expected: 45761732 Refetching... File renamed to '/usr/portage/distfiles/mariadb-5.5.36.tar.gz._checksum_failure_.a90a2t' >>> Downloading 'http://launchpad.net/maria/5.5/ongoing/+download/mariadb-5.5.36.tar.gz' --2014-02-25 17:41:16-- http://launchpad.net/maria/5.5/ongoing/+download/mariadb-5.5.36.tar.gz Length: 45767693 (44M) Saving to: ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ [...] 2014-02-25 17:41:18 (23,3 MB/s) - ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ saved [45767693/45767693] !!! Fetched file: mariadb-5.5.36.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 45767693 !!! Expected: 45761732 Refetching... File renamed to '/usr/portage/distfiles/mariadb-5.5.36.tar.gz._checksum_failure_.a90a2t' >>> Downloading 'http://maria.llarian.net/download/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz' --2014-02-25 17:41:18-- http://maria.llarian.net/download/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz Length: 45767693 (44M) Saving to: ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ [...] 2014-02-25 17:41:20 (23,1 MB/s) - ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ saved [45767693/45767693] !!! Fetched file: mariadb-5.5.36.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 45767693 !!! Expected: 45761732 Refetching... File renamed to '/usr/portage/distfiles/mariadb-5.5.36.tar.gz._checksum_failure_.a90a2t' >>> Downloading 'http://ftp.rediris.es/mirror/MariaDB/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz' --2014-02-25 17:41:21-- http://ftp.rediris.es/mirror/MariaDB/mariadb-5.5.36/kvm-tarbake-jaunty-x86/mariadb-5.5.36.tar.gz Length: 45767693 (44M) Saving to: ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ [...] 2014-02-25 17:41:22 (23,1 MB/s) - ‘/usr/portage/distfiles/mariadb-5.5.36.tar.gz’ saved [45767693/45767693] !!! Fetched file: mariadb-5.5.36.tar.gz VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 45767693 !!! Expected: 45761732 Refetching... File renamed to '/usr/portage/distfiles/mariadb-5.5.36.tar.gz._checksum_failure_.a90a2t' !!! Couldn't download 'mariadb-5.5.36.tar.gz'. Aborting.
How can we fix the broken digest (as end users I mean)? I enter ebuild <ebuild file> manifest or digest, it renames the already downloaded file, downloads it again, tries to verify the file, renames it and downloads it again. Isn't there a way to circumvent this?
(In reply to Vasilis Lourdas from comment #17) > How can we fix the broken digest (as end users I mean)? I enter ebuild > <ebuild file> manifest or digest, it renames the already downloaded file, > downloads it again, tries to verify the file, renames it and downloads it > again. Isn't there a way to circumvent this? Replying to myself... Delete the entry for 5.5.36.tar.gz in Manifest file and issue a ebuild mariadb-5.5.36.ebuild manifest command. Of course, it wouldn't hurt to verify the md5 checksum from the official site for the downloaded tar.gz.
(In reply to Vasilis Lourdas from comment #18) > (In reply to Vasilis Lourdas from comment #17) > > How can we fix the broken digest (as end users I mean)? I enter ebuild > > <ebuild file> manifest or digest, it renames the already downloaded file, > > downloads it again, tries to verify the file, renames it and downloads it > > again. Isn't there a way to circumvent this? > > Replying to myself... Delete the entry for 5.5.36.tar.gz in Manifest file > and issue a > > ebuild mariadb-5.5.36.ebuild manifest > > command. Of course, it wouldn't hurt to verify the md5 checksum from the > official site for the downloaded tar.gz. Fixed.. sorry about that.
Ping! Any progress here?
(In reply to Frank Krömmelbein from comment #20) > Ping! > > Any progress here? You can always install from the overlay, it's been working fine for me since it got bumped there.
(In reply to Vasilis Lourdas from comment #21) > > You can always install from the overlay, it's been working fine for me since > it got bumped there. Nice to hear that this version works fine for you. Just added the overlay, it seems that the embedded useflag now requires also the static-libs useflag for mariadb and the virtual/mysql enabled. Strange... [ebuild U ~] dev-db/mariadb-5.5.36::mysql [5.5.32::gentoo] USE="community embedded pam perl ssl static-libs%* -cluster -debug -extraengine -jemalloc -latin1 -max-idx-128 -minimal -oqgraph -profiling (-selinux) -sphinx -static -systemtap -tcmalloc {-test} -tokudb% (-pbxt%)" 0 kB [ebuild R ~] virtual/mysql-5.5::mysql [5.5::gentoo] USE="embedded static-libs%* -minimal -static" 0 kB1111
> Just added the overlay, it seems that the embedded useflag now requires also > the static-libs useflag for mariadb and the virtual/mysql enabled. Strange... > > [ebuild U ~] dev-db/mariadb-5.5.36::mysql [5.5.32::gentoo] > USE="community embedded pam perl ssl static-libs%* -cluster -debug > -extraengine -jemalloc -latin1 -max-idx-128 -minimal -oqgraph -profiling > (-selinux) -sphinx -static -systemtap -tcmalloc {-test} -tokudb% (-pbxt%)" 0 > kB > [ebuild R ~] virtual/mysql-5.5::mysql [5.5::gentoo] USE="embedded > static-libs%* -minimal -static" 0 kB1111 Not strange at all. The embedded library is a static library. As such, it would be wrong to install it if a user disabled static-libs.
Hi. Do we have any chanse to see the new version in main tree soon? Do you need some help in testing of the version from overlay?
I'd second what others said before, 5.5.32 (latest available on official tree) got a series of bugs that makes it rather unusable.
As I said in a previous comment of mine, use layman to add the mysql overlay and install version 5.5.36 from there. So far it has worked fine for me for two servers. If you worry about the "quality" of the ebuilds there, the ebuilds are from the same developers that finally end up in the main tree.
(In reply to Vasilis Lourdas from comment #26) > As I said in a previous comment of mine, use layman to add the mysql overlay > and install version 5.5.36 from there. So far it has worked fine for me for > two servers. This is not supposed to be the standard or even a long-term solution. We need this package in portage ASAP. It's really a shame to have the package broken in portage but fixed in some overlay which most users do not even know about. So why is this taking so long? Who do I need to poke? Or is it okay if I bump the eclass(es) and ebuild(s)?
(In reply to Lars Wendler (Polynomial-C) from comment #27) > This is not supposed to be the standard or even a long-term solution. We > need this package in portage ASAP. It's really a shame to have the package > broken in portage but fixed in some overlay which most users do not even > know about. > > So why is this taking so long? Who do I need to poke? Or is it okay if I > bump the eclass(es) and ebuild(s)? robbat2 and jmbsvicetto are currently the only members of the mysql herd. I'm trying to join as a third member, but recruiters have a queue atm. There needs to be a new release of the mysql-extras patch set for current overlay ebuilds/eclasses to not need patches from git which is very much preferred.
(In reply to Lars Wendler (Polynomial-C) from comment #27) > (In reply to Vasilis Lourdas from comment #26) > > As I said in a previous comment of mine, use layman to add the mysql overlay > > and install version 5.5.36 from there. So far it has worked fine for me for > > two servers. > > This is not supposed to be the standard or even a long-term solution. We > need this package in portage ASAP. It's really a shame to have the package > broken in portage but fixed in some overlay which most users do not even > know about. Many teams in Gentoo do most of their work in an overlay, so we aren't doing anything "special" for MySQL. > So why is this taking so long? Who do I need to poke? Or is it okay if I > bump the eclass(es) and ebuild(s)? The MySQL team is Robin, me and Brian. We are working on this. Having "random" users and developers making noise here, doesn't help.
5.5.37 is now in the overlay
(In reply to Jorge Manuel B. S. Vicetto from comment #29) > (In reply to Lars Wendler (Polynomial-C) from comment #27) > > (In reply to Vasilis Lourdas from comment #26) > > > As I said in a previous comment of mine, use layman to add the mysql overlay > > > and install version 5.5.36 from there. So far it has worked fine for me for > > > two servers. > > > > This is not supposed to be the standard or even a long-term solution. We > > need this package in portage ASAP. It's really a shame to have the package > > broken in portage but fixed in some overlay which most users do not even > > know about. > > Many teams in Gentoo do most of their work in an overlay, so we aren't doing > anything "special" for MySQL. Yes but usually that work gets moved into portage in a reasonable timeframe which is definitely not the case here. > > So why is this taking so long? Who do I need to poke? Or is it okay if I > > bump the eclass(es) and ebuild(s)? > > The MySQL team is Robin, me and Brian. We are working on this. > Having "random" users and developers making noise here, doesn't help. That noise comes from now two security bugs being open against old mariadb versions being in portage and nothing changed up to now. You failed to put a new maridb version into portage for _seven months_ already. Don't tell me that you had not even one day of time yet to take care of a simple version bump here.
(In reply to Lars Wendler (Polynomial-C) from comment #31) > (In reply to Jorge Manuel B. S. Vicetto from comment #29) > > The MySQL team is Robin, me and Brian. We are working on this. > > Having "random" users and developers making noise here, doesn't help. > > That noise comes from now two security bugs being open against old mariadb > versions being in portage and nothing changed up to now. > You failed to put a new maridb version into portage for _seven months_ > already. Don't tell me that you had not even one day of time yet to take > care of a simple version bump here. No mariadb version in the tree was ever marked stable. Actually no 5.5 ebuild for mariadb or mysql has been marked stable. About the bump, as you seem not to be aware, this isn't a "simple version bump". About my time constraints and my use of my time, your tone doesn't make me feel inclined to reply.
As a random user; is there anything one can assist with? I use the mysql overlay on my dev and staging rigs but would generally like to stick with gentoo-x86 for baking production environments. I've done some minor patches for the overlay previously, but haven't found anything to fix for 5.5.37 as of yet.
23:55 < irker563> gentoo-x86: jmbsvicetto dev-db/mariadb: Add mariadb-5.5.37 from the overlay - thanks to Brian Evans. Done
Thank you
