| Summary: | =dev-db/mariadb-5.5.40-r1 stabilization | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jorge Manuel B. S. Vicetto <jmbsvicetto> |
| Component: | [OLD] Keywording and Stabilization | Assignee: | Gentoo Linux MySQL bugs team <mysql-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ab4bd, aidar.kamalov, alexander, andrzej.pauli, ap, axiator, bertrand, bug, bugs, cyberbat83, hydrapolic, jdavid.ibp, lorand.kelemen, mrueg, tobias.pal |
| Priority: | Normal | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 429708, 473002, 474802, 474952, 481304, 486682, 512328, 512330 | ||
| Bug Blocks: | |||
|
Description
Jorge Manuel B. S. Vicetto (RETIRED)
2013-06-26 01:46:06 UTC
Hi, Sorry to interfere, this bug and its dependent are two months old already, is there a progress regarding these? I don't see how this bug depends on 474802, should it not be the other way around? Seems like 429708 is resolved for most arch's, can we not stable this bug for those? Agreed, it would be nice to the switch/stabilization move along, and 474802 looks like it has been ready to go for a month now. *** Bug 491158 has been marked as a duplicate of this bug. *** I have an issue with 5.5.32 as it blocks dspam compilation, see bug #491156. Ok, DSPAM compilation issue is an ebuild issue. So, are we far from a stable marked mysql 5.5 ebuild ? Due to bug http://bugs.mysql.com/bug.php?id=69623 I would suggest to not mark as stable version 5.5.32. (In reply to Marcin Mirosław from comment #7) > Due to bug http://bugs.mysql.com/bug.php?id=69623 I would suggest to not > mark as stable version 5.5.32. I've added the info about this bug on the 5.5.33 and 5.6.13 bump bug and added it as a blocker for this bug. What's the status of stabilizing MariaDB? I looked at many depending bugs and saw that some of them depended on newer versions which now exist either in the official tree or the mysql overlay, can't this bug "refresh" status and see what's now missing? The following keyword changes are necessary to proceed: (see "package.accept_keywords" in the portage(5) man page for more details) # required by virtual/mysql-5.5 # required by dev-perl/DBD-mysql-4.20.0 =dev-db/mariadb-5.5.32 ~amd64 # required by dev-db/mariadb-5.5.32 # required by mariadb (argument) =virtual/mysql-5.5 ~amd64 really? 5.5.35+dfsg-0+wheezy1 ... DEBIAN (stable)... Where is exactly problem now? There was times, when Gentoo has cutting edge things, now Gentoo is more conservative than Debian? I have the same thoughts as David. I cannot understand how Debian's stable repository (used by many production servers in the wild) contains a more recent version of MySQL than Gentoo's equivalent. Could we get an update please? MySQL 5.5 went GA in December 2010. I understand that a source-based distro has its own set of issues, but if they cannot be fixed in four years then something isn't right. What is currently blocking MySQL 5.5 from being stabilised (for x86/amd64 at least)? I would like to evaluate the severity of the blocker(s). I forgot to add a comment here yesterday. Now that 5.5.37-r1 is in the tree, I'd appreciate if interested users could test it and report any issues they hit. 5.5.37-r1 is currently the candidate for the first version marked stable. (In reply to Jorge Manuel B. S. Vicetto from comment #12) > I forgot to add a comment here yesterday. > > Now that 5.5.37-r1 is in the tree, I'd appreciate if interested users could > test it and report any issues they hit. 5.5.37-r1 is currently the candidate > for the first version marked stable. Everything's working nicely here so far. I haven't faced any issues. Same here, looks good to me. When we put out a news item about the new stable, we should note that everyone should check the size of their InnoDB file vs the max in my.cnf. The upgrade will automatically inflate the tablespace but if it reaches max, bug 442346 is hit. (In reply to Brian Evans from comment #15) > When we put out a news item about the new stable, we should note that > everyone should check the size of their InnoDB file vs the max in my.cnf. > > The upgrade will automatically inflate the tablespace but if it reaches max, > bug 442346 is hit. Is both mariadb and mysql affected? Or only mysql? (In reply to Jorge Manuel B. S. Vicetto from comment #12) > Now that 5.5.37-r1 is in the tree, I'd appreciate if interested users could > test it and report any issues they hit. 5.5.37-r1 is currently the candidate > for the first version marked stable. I emerged dev-db/mysql-5.5.38 and upgraded without issues on amd64 I'm also used MariaDB from 5.5.32 to 5.5.37 on production x86 server without any issues. And now using 5.5.38 on the new amd64 LAMP server. Stabilization should be also motivated, that for example newer phpmyadmin (version >4.2.25 AFAIR) requires mysql-5.5* Security stable happening in bug 518718 Arches, please test and mark stable. This is the new preferred provider of virtual/mysql which is being stabled in bug 518718. Target keywords: =dev-db/mariadb-5.5.39 alpha amd64 arm ia64 ppc ppc64 sparc x86 Deps on certain arches: @alpha: dev-libs/jemalloc needs completed wrt bug 512330 @ppc,ppc64: dev-util/systemtap needs completed wrt bug 512328 Test instructions : # Official test instructions: # USE='-cluster embedded extraengine perl ssl static-libs community' \ # FEATURES='test userpriv -usersandbox' \ # ebuild mariadb-5.5.39.ebuild \ # digest clean package amd64 done Alpha done by klausman 08 Aug 2014; Tobias Klausmann <klausman@gentoo.org> mariadb-5.5.39.ebuild: Stable on alpha, bug 518718 x86 stable Changing target to dev-db/mariadb-5.5.40 due to bug 525504 ia64, ppc, ppc64, sparc done in bug 525504 arm stable via bug #525504, closing. |