Mariadb test suite failures on x86_64-linux

DoneSubmitted by Mark H Weaver.
Details
8 participants
  • Arne Babenhauserheide
  • Gábor Boskovits
  • Chris Marusich
  • Giovanni Biscuolo
  • Ludovic Courtès
  • Marius Bakke
  • Mark H Weaver
  • Platoxia
Owner
unassigned
Severity
normal
M
M
Mark H Weaver wrote on 1 May 2019 11:18
(address . bug-guix@gnu.org)
87tveemt19.fsf@netris.org
hydra.gnunet.org has failed to build mariadb on x86_64-linuxtwice in a row:
https://hydra.gnu.org/build/3475081#tabs-buildsteps
The same test failed both times:
Toggle quote (4 lines)> Failure: Failed 1/5075 tests, 99.98% were successful.> > Failing test(s): tokudb_alter_table.hcad_all_add
The same build also failed twice in a row on my Thinkpad X200, and withthe same error each time, although it's a different error than happenson hydra.gnunet.org. On my X200, I get this instead:
Toggle quote (4 lines)> Failure: Failed 1/1091 tests, 99.91% were successful.> > Failing test(s): tokudb_bugs.mdev4533
hydra.gnunet.org successfully built mariadb for i686-linux on its firstattempt:
https://hydra.gnu.org/build/3473640
Here's the coresponding armhf-linux build, which has not yet beenattempted as I write this:
https://hydra.gnu.org/build/3481309
Mark
M
M
Mark H Weaver wrote on 1 May 2019 11:47
(address . 35521@debbugs.gnu.org)
87h8aemrow.fsf@netris.org
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (8 lines)> The same build also failed twice in a row on my Thinkpad X200, and with> the same error each time, although it's a different error than happens> on hydra.gnunet.org. On my X200, I get this instead:>>> Failure: Failed 1/1091 tests, 99.91% were successful.>> >> Failing test(s): tokudb_bugs.mdev4533
and it just failed a third time on my X200, again with the same error.
Mark
P
P
Platoxia wrote on 10 May 2019 03:33
/gnu/store/c46sn2yfllcfi86p8227wvvr1bxssgxj-mariadb-10.1.38.drv - Failing test(s): tokudb_alter_table.hcad_all_add
(name . 35521@debbugs.gnu.org)(address . 35521@debbugs.gnu.org)
OHunmlNoqinTlkUNFHhTmk5rRngcizuLoYiITgquiSsEG77UoGLNUVD-b_hJohAY9HKpas7qsb4OCBQ7XAPYARyrvP0sGrmHQw319sQPZHo=@protonmail.com
This problem persists and is preventing sucessful completion of guix system reconfigure for pre-1.0.0 systems (at least mine which is still at kernel 4.20), not only for those using mariadb but also for anyone using any of the 544 packages that depend on it; as per the command guix graph --type=reverse-package mariadb | grep -c label).
This could, potentially, be fixed by simply adding this test to the list of disabled tests in the package definition:
--- snip ---(add-after 'unpack 'adjust-tests (lambda _ (let ((disabled-tests '(;; These fail because root@hostname == root@localhost in ;; the build environment, causing a user count mismatch. ;; See https://jira.mariadb.org/browse/MDEV-7761. "main.join_cache" "main.explain_non_select" "main.stat_tables_innodb" "roles.acl_statistics"
;; This file contains a time bomb which makes it fail after ;; 2030-12-31. See https://bugs.gnu.org/34351 for details. "main.mysqldump"
;; XXX: Fails sporadically. "innodb_fts.crash_recovery"
;; FIXME: This test fails on i686: ;; -myisampack: Can't create/write to file (Errcode: 17 "File exists") ;; +myisampack: Can't create/write to file (Errcode: 17 "File exists) ;; When running "myisampack --join=foo/t3 foo/t1 foo/t2" ;; (all three tables must exist and be identical) ;; in a loop it produces the same error around 1/240 times. ;; montywi on #maria suggested removing the real_end check in ;; "strings/my_vsnprintf.c" on line 503, yet it still does not ;; reach the ending quote occasionally. Disable it for now. "main.myisampack" ;; FIXME: This test fails on armhf-linux: "mroonga/storage.index_read_multiple_double"))
;; This file contains a list of known-flaky tests for this ;; release. Append our own items. (unstable-tests (open-file "mysql-test/unstable-tests" "a"))) (for-each (lambda (test) (format unstable-tests "~a : ~a\n" test "Disabled in Guix")) disabled-tests) (close-port unstable-tests)--- snip ---
I say "potentially" because after getting this failure I happened to notice that approximately one and a half minutes after beginning the build of /gnu/store/c46sn2yfllcfi86p8227wvvr1bxssgxj-mariadb-10.1.38.drv the kernel throws this message: "traps: cmTC_35af5[27766] trap invalid opcode ip:555555555174 sp:7fffffffcc90 error:0 in cmTC_35af5[555555555000+1000]".
I have retested this several times and confirmed that this occurs each and every time mariadb-10.1.38.drv tries to build and in approximately the same amount of time after starting the build. I say approximately because the closest I could get to a timeframe on this kernel message in relation to the mariadb build is by sending the stdout from guix system reconfigure through logger so that it gets printed with a timestamp to the kernel messages terminal (alt-F12).
Specifically, the message sequence is always as follows, without deviation (other than the cmTC_#), with no related messages in between; as per the command cat /dev/vcs12:
--- snip ---May 9 16:36:35 localhost root cmd: guix system reconfigure: building /gnu/store/c46sn2yfllcfi86p8227wvvr1bxssgxj-mariadb-10.1.38.drv...May 9 16:38:08 localhost vmunix: [ 9169.050496] traps: cmTC_35af5[27766] trap invalid opcode ip:555555555174 sp:7fffffffcc90 error:0 in cmTC_35af5[555555555000+1000]--- snip ---
I really suggest trying to simply add the tokudb_alter_table.hcad_all_add test to the package definition before trying to solve the overall problem, though. Maybe we can get this in for 1.0.1?
I would be willing to do this myself and report the results here but I'm baffled at how to achieve this simple task. Perhaps someone could walk me through it?
C
C
Chris Marusich wrote on 10 Jul 2019 08:18
Re: bug#35521: Mariadb test suite failures on x86_64-linux
(address . 35521@debbugs.gnu.org)
87pnmil8dq.fsf_-_@gmail.com
Hi,
I've been encountering this failure off and on for a few weeks now, andI'd like to help fix it. In short, it seems like non-deterministic testfailures, to me. I think we should gather data and report the issueupstream, and maybe disable the offending tests in the meantime.
Mariadb failed for me earlier today with a different error than the onesobserved in this bug report so far. My error was the following (whenbuilding mariadb 10.1.40 on an x86_64-linux system using Guix 9b2644c):
Failure: Failed 1/1990 tests, 99.95% were successful.
Failing test(s): tokudb_bugs.5733_innodb
The log files in var/log may give you some hint of what went wrong.
If you want to report this error, please read first the documentation at http://dev.mysql.com/doc/mysql/en/mysql-test-suite.html
558 tests were skipped, 169 by the test itself
I kept the failed build directory, but there is no "var" directory to befound there. I guess they meant system logs; I am not sure where suchlogs would go when emitted from within a derivation.
The MySQL website suggested running mysql-test-run.pl with the --forceoption, which I casually tried after invoking ". environment-variables"from the failed build directory; however, it promptly failed because itcould not find 'my_safe_process' - maybe I didn't have everything set upjust so to run the tests manually.
Curiously, on a different x86_64-linux machine, using Guix commit6c83c48 (which is only a few commits ahead of 9b2644c), I was able tobuild mariadb successfully, although I am not sure when I built it(running "guix build mariadb" currently results in quick success for me,so on this machine I probably built or substituted it some time ago).The derivation (without grafts) was identical to the one that failed tobuild on the other machine, which is strange because I would normallyexpect the same derivation to succeed on both machines. For the record,this was the derivation:
$ guix build --no-grafts -d mariadb /gnu/store/9yw33r8r84qrsic7fiq0lqqkbzisv1cj-mariadb-10.1.40.drv
Perhaps these tests fail non-deterministically? Or perhaps they fail ina way that is specific something not isolated from the build process byGuix, such as the kernel, the file system, or the hardware?
I tried to check the status of mariadb in Cuirass. However, I onlyfound the following information:
https://ci.guix.gnu.org/search?query=mariadb-10.1.40
For x86_64-linux, build 1304242 supposedly failed at 10 May 20:32 +0200after about 3 hours of runtime:
https://ci.guix.gnu.org/build/1304242/details
I say "supposedly failed" because I'm not sure why it failed. The buildlog seems to indicate no problems:
https://ci.guix.gnu.org/build/1304242/log/raw
Has Cuirass tried to build mariadb since then? May 10th was a long timeago, and I am surprised there is not another build of it from master.
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (12 lines)> Mark H Weaver <mhw@netris.org> writes:>>> The same build also failed twice in a row on my Thinkpad X200, and with>> the same error each time, although it's a different error than happens>> on hydra.gnunet.org. On my X200, I get this instead:>>>>> Failure: Failed 1/1091 tests, 99.91% were successful.>>> >>> Failing test(s): tokudb_bugs.mdev4533>> and it just failed a third time on my X200, again with the same error.
It seems like the tests may be flaky. The test failure I saw wasdifferent from yours. And in my case, I actually was able to build (orsubstitute) mariadb once. So maybe what we need to do is gather enoughdata to report the problem upstream, to enlist their help?
Platoxia <platoxia@protonmail.com> writes:
Toggle quote (61 lines)> This problem persists and is preventing sucessful completion of guix system reconfigure for pre-1.0.0 systems (at least mine which is still at kernel 4.20), not only for those using mariadb but also for anyone using any of the 544 packages that depend on it; as per the command guix graph --type=reverse-package mariadb | grep -c label).>> This could, potentially, be fixed by simply adding this test to the list of disabled tests in the package definition:>> --- snip ---> (add-after 'unpack 'adjust-tests> (lambda _> (let ((disabled-tests> '(;; These fail because root@hostname == root@localhost in> ;; the build environment, causing a user count mismatch.> ;; See <https://jira.mariadb.org/browse/MDEV-7761>.> "main.join_cache"> "main.explain_non_select"> "main.stat_tables_innodb"> "roles.acl_statistics">> ;; This file contains a time bomb which makes it fail after> ;; 2030-12-31. See <https://bugs.gnu.org/34351> for details.> "main.mysqldump">> ;; XXX: Fails sporadically.> "innodb_fts.crash_recovery">> ;; FIXME: This test fails on i686:> ;; -myisampack: Can't create/write to file (Errcode: 17 "File exists")> ;; +myisampack: Can't create/write to file (Errcode: 17 "File exists)> ;; When running "myisampack --join=foo/t3 foo/t1 foo/t2"> ;; (all three tables must exist and be identical)> ;; in a loop it produces the same error around 1/240 times.> ;; montywi on #maria suggested removing the real_end check in> ;; "strings/my_vsnprintf.c" on line 503, yet it still does not> ;; reach the ending quote occasionally. Disable it for now.> "main.myisampack"> ;; FIXME: This test fails on armhf-linux:> "mroonga/storage.index_read_multiple_double"))>> ;; This file contains a list of known-flaky tests for this> ;; release. Append our own items.> (unstable-tests (open-file "mysql-test/unstable-tests" "a")))> (for-each (lambda (test)> (format unstable-tests "~a : ~a\n"> test "Disabled in Guix"))> disabled-tests)> (close-port unstable-tests)> --- snip --->> I say "potentially" because after getting this failure I happened to notice that approximately one and a half minutes after beginning the build of /gnu/store/c46sn2yfllcfi86p8227wvvr1bxssgxj-mariadb-10.1.38.drv the kernel throws this message: "traps: cmTC_35af5[27766] trap invalid opcode ip:555555555174 sp:7fffffffcc90 error:0 in cmTC_35af5[555555555000+1000]".>> I have retested this several times and confirmed that this occurs each and every time mariadb-10.1.38.drv tries to build and in approximately the same amount of time after starting the build. I say approximately because the closest I could get to a timeframe on this kernel message in relation to the mariadb build is by sending the stdout from guix system reconfigure through logger so that it gets printed with a timestamp to the kernel messages terminal (alt-F12).>> Specifically, the message sequence is always as follows, without deviation (other than the cmTC_#), with no related messages in between; as per the command cat /dev/vcs12:>> --- snip ---> May 9 16:36:35 localhost root cmd: guix system reconfigure: building /gnu/store/c46sn2yfllcfi86p8227wvvr1bxssgxj-mariadb-10.1.38.drv...> May 9 16:38:08 localhost vmunix: [ 9169.050496] traps: cmTC_35af5[27766] trap invalid opcode ip:555555555174 sp:7fffffffcc90 error:0 in cmTC_35af5[555555555000+1000]> --- snip --->> I really suggest trying to simply add the tokudb_alter_table.hcad_all_add test to the package definition before trying to solve the overall problem, though. Maybe we can get this in for 1.0.1?>> I would be willing to do this myself and report the results here but I'm baffled at how to achieve this simple task. Perhaps someone could walk me through it?
I'm not sure about the kernel error. I haven't seen an error like thatmyself. But perhaps this is yet another test which is failingnon-deterministically?
I think we need more data. It would be nice if we could build thisrepeatedly on Cuirass. When the build is 3 hours long, it is difficultto test it on my machine, and I often forget about it by the time it isdone running.
If I get more time, I will try to dig in more. In the meantime, anythoughts about this would be welcome.
-- Chris
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEy/WXVcvn5+/vGD+x3UCaFdgiRp0FAl0lg1EACgkQ3UCaFdgiRp0DZg/+MeOEmURNkPsIrkLyrgjG/okg06VfOkPezht2CnXEwIy+cSjccKN/6l9HeRGUQLEXyqhMNueYGIiMXYGgVixknNIJ97/Twx8qVc+0mrY4h7t2lDif4QXF5ytVIRmOd3eRB/tN5eA3CoNAV/VSsEGvqXpvvfa3XJPvYjKso78WvZP4qGlwyhmPyeBcW77MInNSod7pdpcvy1BceB5vORrAsQmFixrnZb/mb239JyOLq448C7sqC501kt3Q1SS0qVUc1yf1vdRqxyZek5XKSAJaS3Y+EfgZRkpHjzkoSaeLf0kbaz+9DfIqqszky0PtrLSPt5rMqGxsWHni6YzdkNcP8v7As9ZDN60HCH0SdJLBeSQ6R3zrtOd1T2QjCTArMfzyKFQPHe62WdrLYLo4a8NFGKQobbPLJKP5ipnmmGCu1mbhvmi258NkQjul0IXlx6STUzfywwDp1rCXz/nrM0g+FRESxAr2ejOWuhgluxE7xRAaE1qzP5wLC/yXRpndTqkkVu8Qiy3RJMVkvsQvfD8xksNALeSToYX6qoBfaF0brwCTgfcf1g+ktLTaMlK5FnvS4YBg9dtOHOYzzQwiw7gzuEh604eBzC+Mn7Q5B+FBg4p4Q14Ec0s4kO5yHVeQWTLLgUQmMsmbBUd+7sxKyYk8LEqJ9Gkx20Z8MS1x3WV/fCI==9zjG-----END PGP SIGNATURE-----
M
M
Marius Bakke wrote on 10 Jul 2019 19:30
(address . 35521@debbugs.gnu.org)
87wogpn6f7.fsf@devup.no
Chris Marusich <cmmarusich@gmail.com> writes:
Toggle quote (7 lines)> Hi,>> I've been encountering this failure off and on for a few weeks now, and> I'd like to help fix it. In short, it seems like non-deterministic test> failures, to me. I think we should gather data and report the issue> upstream, and maybe disable the offending tests in the meantime.
I agree. I notice many of these failing tests are for the TokuDBbackend, which I doubt anyone is using in Guix anyway.
Here is a patch that disables all tests mentioned in this report. Iwould like to push it to core-updates. Are there others?
Toggle diff (18 lines)diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scmindex 578670e3c1..778c70eed0 100644--- a/gnu/packages/databases.scm+++ b/gnu/packages/databases.scm@@ -704,8 +704,12 @@ Language.") ;; 2030-12-31. See <https://bugs.gnu.org/34351> for details. "main.mysqldump" - ;; XXX: Fails sporadically.+ ;; XXX: These tests may fail on some hardware configurations,+ ;; see <https://bugs.gnu.org/35521> et al. "innodb_fts.crash_recovery"+ "tokudb_alter_table.hcad_all_add"+ "tokudb_bugs.mdev4533"+ "tokudb_bugs.5733_innodb" ;; FIXME: This test fails on i686: ;; -myisampack: Can't create/write to file (Errcode: 17 "File exists")
WDYT?
Note that the latest MariaDB is 10.4.x, and these tests may well befixed in later versions.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0mILwACgkQoqBt8qM6VPrruQgAzi4CtsfhJjbaGHZgq/1NtY5uzZVxzJS9yGIKeJ3/LOwI+XXOyh567e6etJPO5B4I9ItZHeryWtREDIjHDeqwL64yhmnHMcWanoCGHrIptVtJMauxcCJkrqcFdr7wX3tJXbQD5HzydJKkmWS8dlOIPYhSTGP5ohZhMsB2qWdl3LwcHjNcqZohadBzawwoJzzDGqnCOjgj92efdFIR1FxgwdNEXavjoa2j7E1fV2t4hWzE3VhXAMu0OHAr9zUjxm443ltY0D86v+e13rD55wv1tSuKmO6RzLecHn9+besRzMYVC54XtSSdcIjKJOlLlBW03XoksXd9AveBSTe726iH3w===1IaP-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 10 Jul 2019 23:32
(name . Marius Bakke)(address . mbakke@fastmail.com)
87ef2xlgmb.fsf@netris.org
Hi,
Marius Bakke <mbakke@fastmail.com> writes:
Toggle quote (15 lines)> Chris Marusich <cmmarusich@gmail.com> writes:>>> Hi,>>>> I've been encountering this failure off and on for a few weeks now, and>> I'd like to help fix it. In short, it seems like non-deterministic test>> failures, to me. I think we should gather data and report the issue>> upstream, and maybe disable the offending tests in the meantime.>> I agree. I notice many of these failing tests are for the TokuDB> backend, which I doubt anyone is using in Guix anyway.>> Here is a patch that disables all tests mentioned in this report. I> would like to push it to core-updates. Are there others?
I'm concerned by how frequently and casually we simply disable failingtests. What is the utility of running test suites at all, if this ishow we respond?
It makes me wonder how many programs are subtly broken on my Guix systembecause of this widespread practice.
Mark
L
L
Ludovic Courtès wrote on 11 Jul 2019 22:18
(name . Mark H Weaver)(address . mhw@netris.org)
87ftncqq8r.fsf@gnu.org
Hi Mark,
Mark H Weaver <mhw@netris.org> skribis:
Toggle quote (21 lines)> Marius Bakke <mbakke@fastmail.com> writes:>>> Chris Marusich <cmmarusich@gmail.com> writes:>>>>> Hi,>>>>>> I've been encountering this failure off and on for a few weeks now, and>>> I'd like to help fix it. In short, it seems like non-deterministic test>>> failures, to me. I think we should gather data and report the issue>>> upstream, and maybe disable the offending tests in the meantime.>>>> I agree. I notice many of these failing tests are for the TokuDB>> backend, which I doubt anyone is using in Guix anyway.>>>> Here is a patch that disables all tests mentioned in this report. I>> would like to push it to core-updates. Are there others?>> I'm concerned by how frequently and casually we simply disable failing> tests. What is the utility of running test suites at all, if this is> how we respond?
I don’t think anyone is happy with that. The alternative seems to be:keeping an older version that perhaps didn’t have these problems but mayhave known bugs and security issues, or keeping a package that fails tobuild for a possibly long time.
I think disabling specific tests is the least bad of these options. Inthis case, we know that the offending tests relate to a specificbackend, and one can at least assume that potential issues are in thatarea. So I do think that this is an appropriate response.
Of course, in any such case, we should report the issue upstream, evenif we all too well know that non-deterministic test failures are hard toaddress…
Ludo’.
M
M
Marius Bakke wrote on 12 Jul 2019 00:01
(name . Mark H Weaver)(address . mhw@netris.org)
87ims8mds7.fsf@devup.no
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (23 lines)> Hi,>> Marius Bakke <mbakke@fastmail.com> writes:>>> Chris Marusich <cmmarusich@gmail.com> writes:>>>>> Hi,>>>>>> I've been encountering this failure off and on for a few weeks now, and>>> I'd like to help fix it. In short, it seems like non-deterministic test>>> failures, to me. I think we should gather data and report the issue>>> upstream, and maybe disable the offending tests in the meantime.>>>> I agree. I notice many of these failing tests are for the TokuDB>> backend, which I doubt anyone is using in Guix anyway.>>>> Here is a patch that disables all tests mentioned in this report. I>> would like to push it to core-updates. Are there others?>> I'm concerned by how frequently and casually we simply disable failing> tests. What is the utility of running test suites at all, if this is> how we respond?
I had no idea this issue was so widespread until I noticed Berlinsbuilders hit it more often than not. I have not been able to reproducethese failures on my machines. So it was kind of a panic reaction,being the person responsible for running these tests and all.
Looking further into the changes between 10.1.37 and 10.1.38, I noticethe 'tokudb.*' tests were enabled:
https://github.com/MariaDB/server/commit/4c490d6df63695dc97b2c808e59954e6877d3a51
Watching the build on Berlin in real time, I also see that the testoutput grind nearly to a halt while running those.'tokudb.hotindex-insert-2' took 2700439 milliseconds, or 45 minutes, ifI'm reading the test output correctly.
The default test case timeout is 40 minutes (as specified in the Guixpackage), but I'm using 80 for this build (60 was insufficient).
I suspect the problem is that the 'tokudb.*' tests put a lot of strainon the file system, which causes these other tests to fail. It'sinteresting that disabling parallel build was insufficient though.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0nsbgACgkQoqBt8qM6VPp1tgf/UL12EYe5i3V5vTSCL/x3LG51j3EvApLjIUhzcxqbv1p7j9eQlzx+A6vSCy8uqBg8tK15IFIwq+bnzF3AYFUUxNRqzq2M/5LRbNDAavckrgkC1ZrkBJtYd0TQivRV32Jjt0frbqcTols98Ajy5mlQ+M69z7XSW/HdtvYEkJDVmaj5YZAA3Uqu0nq3Cmj0uzRwooQl0S7e0ne+9QIHWSjIqKyE8YqVwA9HZwmZc42p/WPCL2ex6FTgH/iMOc3IHS696tzSc/ctZgmzAC9/EpBD81NXeYc3Z4Njy32WLo4hFuaG3yg7rB4Z8GW9iccI3AqFSDzG8oAcLs3Mrr8QKQlUZg===TgJX-----END PGP SIGNATURE-----
G
G
Giovanni Biscuolo wrote on 12 Jul 2019 10:02
(address . 35521@debbugs.gnu.org)
87blxzu1d6.fsf@roquette.mug.biscuolo.net
Hi all,
for what it counts I
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (2 lines)> Mark H Weaver <mhw@netris.org> skribis:
[...]
Toggle quote (3 lines)>> I'm concerned by how frequently and casually we simply disable failing>> tests.
I disagree here: disabling in Guix tests is _never_ done casually AFAIS(as far as I see) but always ponderated and discussed, like in this case;-)
[...]
Toggle quote (2 lines)> I think disabling specific tests is the least bad of these options.
Also: automated software testing is better than nothing but... who testtests? *Sometime* it happens that tests introduces "collateral testbugs" that have nothing to do with actual software issues, includingsecutiry ones.
So IMHO neither upstream nor us should "blindly obey" to tests anddisable proved unreliable ones :-D
More on this specific issue in my next repy... :-)
[...]
Happy hacking! Gio'
-- Giovanni Biscuolo
Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAl0oPpUACgkQ030Op87MORJZ6A//eSJcDaXg0EVnRkncY6mlGaA383z3PgGM7Pj4ZTb2YYtZp3djpv0rLIHsLm9MnmVPDJfwo02Q083KODYiTMHZHrDo2ItXRGp7dQ4a1g2aTFQEh+V4mtXNY/B6EMEZQx8W7+2bnPC78QHTpMV2MCHQ/iDUeBKP4Zd/rDSmvHYZj9n2ehwVT2zoxjLY8B8gpVJCxkFYSJ31MEjB9D11LeWohAzwW+hUP98tWz7UPFWuP1Qm6F1kubPuVkvdwj1NkEXgviIriy9Tlgur6MXWjIzIkreo1EYK2Nou17fWUHcdi2txF+zVVf38a9OPl1PaGQTYYNj3C3PEEyAMbXN5qnoynXPcQ+rapjc7yCQiYsSwIptnOh4pVcHgom7wrte25SnDbL159dwSfQrcgtX6ykaK+0PMo/Ujejuo0f5gPRnuIJemd1u4ipDUkU2g2yLnVRBJe7dpt4d3HnFviPYL60PnXTFSbCarhHgX8sSEXNgBAvaaMjlJ0REqxuCyQdBrbvBnFwbDwqkpu3/TBpj0RG00FHFCpvRRlip4oc+8AYMAGkI745WCtrDgx5WTJiqtONuObRJ835cCBCUL1qi18DDRPb3wCDP2K/ZgWoW0+GAZGOGWI6NIsiROgytUHz0BYLs1G4xckcroBJX2RGtLWwv2204CS6PgwQKGL+vab840myk==ZVVm-----END PGP SIGNATURE-----
G
G
Giovanni Biscuolo wrote on 12 Jul 2019 10:24
(name . Marius Bakke)(address . mbakke@fastmail.com)
878st3u0d7.fsf@roquette.mug.biscuolo.net
Hi Marius,
Marius Bakke <mbakke@fastmail.com> writes:
[...]
Toggle quote (5 lines)> Looking further into the changes between 10.1.37 and 10.1.38, I notice> the 'tokudb.*' tests were enabled:>> https://github.com/MariaDB/server/commit/4c490d6df63695dc97b2c808e59954e6877d3a51
The very first thing I noticed lookng at that commit is it's subject:"Updated list of unstable tests for 10.1.38 release"
The first comments of that file states:
Toggle snippet (22 lines)# List the test cases which, unlike tests from disabled.def files,# can still be run on the current tree meaningfully, but are known# or suspected to fail sporadically on different reasons.## Most common reasons are either test failures observed in buildbot,# or recent modifications to the tests which make their stability# unknown.## Tests included due to recent modifications are later removed from the# list, if during a certain period they do not fail (and are not# modified again). Tests included due to intermittent failures are# removed when corresponding bug reports are closed.## Separate the test case name and the comment with ':'.## <suitename>.<testcasename> : MDEV-xxxxx - <comment>## '*' wildcard in testcase names is supported.## To use the list, run MTR with --skip-test-list=unstable-tests option.
So *all* those rests _are_ considered unstable upstream.
IMHO they should be *selectively* skipped when they causes buildproblems in Guix, including non-deterministic frequent ones like in thiscase.
Toggle quote (5 lines)> Watching the build on Berlin in real time, I also see that the test> output grind nearly to a halt while running those.> 'tokudb.hotindex-insert-2' took 2700439 milliseconds, or 45 minutes, if> I'm reading the test output correctly.
The same is happening upstream:https://jira.mariadb.org/browse/MDEV-15198https://jira.mariadb.org/browse/MDEV-16040(duplicate of the above)https://jira.mariadb.org/browse/MDEV-15271
That bugs (and all others related to unstable tests) are currentlyunresolved.
HTH! Gio'
-- Giovanni Biscuolo
Xelera IT Infrastructures
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEERcxjuFJYydVfNLI5030Op87MORIFAl0oQ6QACgkQ030Op87MORIhNg/+NqbYZ5uOvNzZgZd2fzYlS0rsmeFRI+MjZzQhuPxFMHdjr4C+hHyTnsPEDIm6pLPWmWtlYJLr7vtOaYNuxF+cgzhbgwOzuON9uUbYORsZ+DFu264IKg5oqP5THD+9Q+m0HU9MkEx35+q308LwpNpuUIVvserjv6OeRTa9jX/nviLgtrj5q1Cmnrskoq+tnjsSYFZ9kGy8SSIeOdsnXE+ChQj6Mp6nN0P4h7ULhf8kym2oPr7ojgV26KuBYsjdgk3q5d697GdhlcG4N17A7A2vFeabUIs+SnXTVKPZt9unXC1mwUAvMwDZsWGLJdi51KywIiFohyZ4UQhaqw3zUuS8lO/H41suOZJPibx0qBqp3I55yZoH5grNUHMvFpeRQuZ4l9MtiEZHxQUf0b+j/JO4JplCnfIChPQXlyqVGGpg+1hS8Dkk7PPiR8/lwhhLK3QgEUlVz0Krh9MenoXh+SNnjOuFTRJnhfzYaDW/Mh9ERbUnwMkiP9en7SKibT+x46m7nHpHUvWfvlzFgZZyFjWlUxKyHKSG3NUtAw55J+bhqeyBUF2mm6mNA7MFOzaIPVDdxHrtKR+KZXYazYEw8qlUkInzwmJLjtuXoauoRKCuN/NI5kvht9vQIBcMmkw+EzvMdIQSH1BJ2rjP3SKbj2hd42nZuc/k6Mv9JRVWuwKUNxo==qw3E-----END PGP SIGNATURE-----
M
M
Marius Bakke wrote on 12 Jul 2019 16:58
(name . Mark H Weaver)(address . mhw@netris.org)
878st3mh93.fsf@devup.no
Marius Bakke <mbakke@fastmail.com> writes:
Toggle quote (47 lines)> Mark H Weaver <mhw@netris.org> writes:>>> Hi,>>>> Marius Bakke <mbakke@fastmail.com> writes:>>>>> Chris Marusich <cmmarusich@gmail.com> writes:>>>>>>> Hi,>>>>>>>> I've been encountering this failure off and on for a few weeks now, and>>>> I'd like to help fix it. In short, it seems like non-deterministic test>>>> failures, to me. I think we should gather data and report the issue>>>> upstream, and maybe disable the offending tests in the meantime.>>>>>> I agree. I notice many of these failing tests are for the TokuDB>>> backend, which I doubt anyone is using in Guix anyway.>>>>>> Here is a patch that disables all tests mentioned in this report. I>>> would like to push it to core-updates. Are there others?>>>> I'm concerned by how frequently and casually we simply disable failing>> tests. What is the utility of running test suites at all, if this is>> how we respond?>> I had no idea this issue was so widespread until I noticed Berlins> builders hit it more often than not. I have not been able to reproduce> these failures on my machines. So it was kind of a panic reaction,> being the person responsible for running these tests and all.>> Looking further into the changes between 10.1.37 and 10.1.38, I notice> the 'tokudb.*' tests were enabled:>> https://github.com/MariaDB/server/commit/4c490d6df63695dc97b2c808e59954e6877d3a51>> Watching the build on Berlin in real time, I also see that the test> output grind nearly to a halt while running those.> 'tokudb.hotindex-insert-2' took 2700439 milliseconds, or 45 minutes, if> I'm reading the test output correctly.>> The default test case timeout is 40 minutes (as specified in the Guix> package), but I'm using 80 for this build (60 was insufficient).>> I suspect the problem is that the 'tokudb.*' tests put a lot of strain> on the file system, which causes these other tests to fail. It's> interesting that disabling parallel build was insufficient though.
Update: Berlin built mariadb twice on core-updates with this patch:
Toggle diff (13 lines)diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scmindex 6bfeaad9a2..64bc0938b6 100644--- a/gnu/packages/databases.scm+++ b/gnu/packages/databases.scm@@ -753,7 +753,7 @@ Language.") (with-directory-excursion "mysql-test" (invoke "./mtr" "--verbose" "--retry=3"- "--testcase-timeout=40"+ "--testcase-timeout=80" "--suite-timeout=600" "--parallel" (number->string (parallel-job-count)) "--skip-test-list=unstable-tests"))
Mark, Chris: Can you try this change with MariaDB 10.1.40 and see if itworks for you?
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0ooCgACgkQoqBt8qM6VPq/FggAtPX7+OrcwlSI12IbUfUqhEZnQrocXIy9okA1Bl5NiV+Hy8k2rfg5/Q1KRqix5TSkPCGLPtQYkW/IIyZiPaJZQuKWpUlphbFlZDQ1vGs2Q4WlbS0gOLJnEV3TEkRaj2rweRsTKel5OPMSKaV3VGTc+TchyRFvhjGfhSrBdokrBD2Z6cSWtf4rhss3rge+11QhSBX3ZIqSghSSTd9GZ1D4XCIEdvUfxK0qoWH1bLhSmTQh/PNV8+wtl1osXmrb8zXNXu1WP2FyaCnPeDS2vOEYBDogT0kDszadxWC0lNXzwxuRfbc4dJVhcI/QSWQXWbvO88PyTjRep6zJ5iu6DjG1fw===RYR1-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 13 Jul 2019 19:29
(name . Marius Bakke)(address . mbakke@fastmail.com)
87d0id4zcz.fsf@netris.org
Hi Marius,
Toggle quote (21 lines)> Update: Berlin built mariadb twice on core-updates with this patch:>> --8<---------------cut here---------------start------------->8---> diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm> index 6bfeaad9a2..64bc0938b6 100644> --- a/gnu/packages/databases.scm> +++ b/gnu/packages/databases.scm> @@ -753,7 +753,7 @@ Language.")> (with-directory-excursion "mysql-test"> (invoke "./mtr" "--verbose"> "--retry=3"> - "--testcase-timeout=40"> + "--testcase-timeout=80"> "--suite-timeout=600"> "--parallel" (number->string (parallel-job-count))> "--skip-test-list=unstable-tests"))> --8<---------------cut here---------------end--------------->8--->> Mark, Chris: Can you try this change with MariaDB 10.1.40 and see if it> works for you?
I tried it, but it made no difference on my Thinkpad X200, which stillfails the same way as before with 10.1.38:
Failing test(s): tokudb_bugs.mdev4533
Anyway, based on Giovanni's observations,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35521#32
I'm now inclined to agree that these are likely to be flaky tests, so Iwithdraw my objections to disabling them, in this specific case.
Having said that, I disagree with Giovanni's dismissal of my concerns ingeneral, here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=35521#29
I will respond to that dismissal in a later message.
Thanks, Mark
M
M
Mark H Weaver wrote on 13 Jul 2019 20:38
(name . Marius Bakke)(address . mbakke@fastmail.com)
877e8l4w5c.fsf@netris.org
Earlier, I wrote:
Toggle quote (8 lines)>> Mark, Chris: Can you try this change with MariaDB 10.1.40 and see if it>> works for you?>> I tried it, but it made no difference on my Thinkpad X200, which still> fails the same way as before with 10.1.38:>> Failing test(s): tokudb_bugs.mdev4533
I should clarify that I tested 10.1.40 this time, and it failed in thesame way that 10.1.38 failed for me before.
Mark
M
M
Marius Bakke wrote on 14 Jul 2019 00:42
(name . Mark H Weaver)(address . mhw@netris.org)
87r26tlfoi.fsf@devup.no
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (28 lines)> Hi Marius,>>> Update: Berlin built mariadb twice on core-updates with this patch:>>>> --8<---------------cut here---------------start------------->8--->> diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scm>> index 6bfeaad9a2..64bc0938b6 100644>> --- a/gnu/packages/databases.scm>> +++ b/gnu/packages/databases.scm>> @@ -753,7 +753,7 @@ Language.")>> (with-directory-excursion "mysql-test">> (invoke "./mtr" "--verbose">> "--retry=3">> - "--testcase-timeout=40">> + "--testcase-timeout=80">> "--suite-timeout=600">> "--parallel" (number->string (parallel-job-count))>> "--skip-test-list=unstable-tests"))>> --8<---------------cut here---------------end--------------->8--->>>> Mark, Chris: Can you try this change with MariaDB 10.1.40 and see if it>> works for you?>> I tried it, but it made no difference on my Thinkpad X200, which still> fails the same way as before with 10.1.38:>> Failing test(s): tokudb_bugs.mdev4533
I was about to push this patch to core-updates:
Toggle diff (26 lines)diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scmindex 6bfeaad9a2..5d256b1af2 100644--- a/gnu/packages/databases.scm+++ b/gnu/packages/databases.scm@@ -706,9 +706,6 @@ Language.") ;; 2030-12-31. See <https://bugs.gnu.org/34351> for details. "main.mysqldump" - ;; XXX: Fails sporadically.- "innodb_fts.crash_recovery"- ;; FIXME: This test fails on i686: ;; -myisampack: Can't create/write to file (Errcode: 17 "File exists") ;; +myisampack: Can't create/write to file (Errcode: 17 "File exists)@@ -753,7 +750,10 @@ Language.") (with-directory-excursion "mysql-test" (invoke "./mtr" "--verbose" "--retry=3"- "--testcase-timeout=40"+ ;; On x86_64 we need a long timeout because of the+ ;; TokuDB engine, whose individual test cases often+ ;; require more than 1 hour to complete on busy hosts.+ "--testcase-timeout=90" "--suite-timeout=600" "--parallel" (number->string (parallel-job-count)) "--skip-test-list=unstable-tests"))
Lo and behold, tokudb_bugs.mdev4533 failed when I tried it on Berlin.
A couple of lines above "Failing test(s):" is the test output:
Toggle snippet (14 lines)CURRENT_TEST: tokudb_bugs.mdev4533 safe_process[29262]: parent_pid: 23338 safe_process[29262]: Started child 29263, terminated: 0 mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8)) ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No space left on device")
The result from queries just before the failure was:DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a INT(11), b CHAR(8)) ENGINE=TokuDB;safe_process[29262]: Got signal 17, child_pid: 29263safe_process[29262]: Killing child: 29263safe_process[29262]: Child exit: 1
Could it be that you don't have enough disk space for this test? Do youhave the log file available still?
Here is the test in question:https://github.com/MariaDB/server/blob/10.1/storage/tokudb/mysql-test/tokudb_bugs/t/mdev4533.test
As a side note, MariaDB is ~30 MiB bigger on x86_64 because of TokuDB.It would be great to move it to a separate output.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0qXl0ACgkQoqBt8qM6VPoAgwgAyAmWPdhPlrD0NdjDrMZ41v/pa2Tq/ZIr9AP0aZRm7wtnB4PFiC/Gtr8m2rR7jyQBwhpHQVEcD44VZomRoAKFp9C/rPKQccyyLHJT5MMSk8zxrk0Syi2Q9vRgXpf9ctrgOApK0Rr5xQm+twpu8OQSqJcFx6/pdqh2tMjHGqbLDcUmqXBFLeH7mzCSjDQbxO4Ft3oFol6o8GT4FnfIYioizopgc9hD+gKeBrEkaXmpcM6eNDU36hFwinTLGhXljfzETvb+ue0TG2a4k2XpBzf8eL5u6CAbLkp6BwG9nDpjNQpf9u/0l1v+B7+sBR2GfMRWYbJI4wm6/T2tM2+D8qo5OA===iAZj-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 14 Jul 2019 04:35
(name . Marius Bakke)(address . mbakke@fastmail.com)
87ef2ts5r5.fsf@netris.org
Hi Marius,
Toggle quote (3 lines)> Could it be that you don't have enough disk space for this test? Do you> have the log file available still?
Yes, I have not only the log file, but also the failed build directory.My log file contains the same error in the 'tokudb_bugs.mdev4533' test:
mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8)) ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No space left on device")
After the build attempt, the failed build directory is ~3.4 GB, and Istill have ~7.4 GB. That seems to imply that I had over 10 GB freebefore starting the build, which sounds about right. I don't have aseparate /tmp partition.
I will make another build attempt, and this time I will watch the diskutilization over time while the test suite is in progress.
I should mention that I'm using Btrfs.
Thanks, Mark
M
M
Mark H Weaver wrote on 14 Jul 2019 06:42
(name . Marius Bakke)(address . mbakke@fastmail.com)
87blxxrzu9.fsf@netris.org
Hello again,
Toggle quote (3 lines)> Could it be that you don't have enough disk space for this test? Do you> have the log file available still?
I made another build attempt on my X200, this time logging the output of"df --si" every 10 seconds. The free space started at ~11 GB free andnever went below 7 GB, but the 'tokudb_bugs.mdev4533' test failed asbefore: "No space left on device" while trying to create the 'test'table.
Mark
A
A
Arne Babenhauserheide wrote on 14 Jul 2019 13:10
(address . bug-guix@gnu.org)
87sgr8x46h.fsf@web.de
Hi Mark,
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (8 lines)> My log file contains the same error in the 'tokudb_bugs.mdev4533' test:>> mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8)) ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No space left on device")>> After the build attempt, the failed build directory is ~3.4 GB, and I> still have ~7.4 GB. That seems to imply that I had over 10 GB free> before starting the build, which sounds about right. I don't have a> separate /tmp partition.
Toggle quote (2 lines)> I should mention that I'm using Btrfs.
I use ext4, but I saw no space left on device errors when running guixlint. Since I had 700GiB free, that does not sound like real missingdisk space, but rather that something else is wrong.
Best wishes,Arne--Unpolitisch seinheißt politisch seinohne es zu merken
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl0rDZkACgkQE++NRSQDw+uWOBAAtWI6FzsRSII26fEwQBtUYkgqExrC/fKDzYkkg7eqSNXQ3O/6jRxXBn6dg3QtrykV7DU3f6OwkaFiSUjMclyebc36Cp77Yshm+424fIis3g96MgKIf7snB5GdvSOXGhqVE4V372LHTa7F3Aj9ENGm/rlXZoIhEQhwJtKfMcJfhrez9ot2JbO17BoXkokjVzAYgZ1vjlTeul86AAo/PZYpWyUMaOdrmcaVtL0tz4WhppTwyN5YNFwfAZtnHnTj43u9IjiwEzjk/XqepA2zg2IruQ2xdVdwbKCrp/PVqhMBrcSbBryoLuEYbqOCU23fZd0ULvS3F9UbzMNdoDezueyNvxPCEyaMRv+83JEKQ5VaYALR6FBZITU98Ehpv8OXst2h+PlUH2MuVpZG6P6AtMPPsygYJuMoMvSB5Ij2HYB9z0/s05wItdyuyH10I4s6FKWgmhDSXzTiOoeGhEAiIBdt2rxJtuuFvkt2GTOSXjsY9gV44vLje/aEtXo9zhuKwXGObPiRRXYxYzhiKbRSW2s3yypH8IwI37UrsgH/kP43DtHKBiHyF3RCuatX+YzKwp3cZkLK3dd0El6bDbTr3CWLP1hbnXJGkoRIJvX9ZI3M/P3t2K2FXE/oR+g/HYkEjke176hBmanrL9SJpILcgv6NEaNv4YxqR7ftLBGZQ9c078uIswQBAQgAHRYhBN0ovebZh1yrzkqLHdzPDbMLwQVIBQJdKw2eAAoJENzPDbMLwQVIwEYD/iRwVL38RbOFF5Fqj/VMLL+O2s7U5zKW4fRSFeOuG405kDPRmqHU8RGHVPriOF04v7FFey+H+Z0HMO03Qimn7JBOnItLgAlePrZihmBRBFXz6OK97SApGZVfUlg9Rt76V2OPk9So/yvJyiz1MVTXNDhUbHEPy7zN+LRHAzEt0ISH=j+/h-----END PGP SIGNATURE-----
G
G
Gábor Boskovits wrote on 14 Jul 2019 17:58
(name . Arne Babenhauserheide)(address . arne_bab@web.de)
CAE4v=pg3JuhHhSg61cM2sk9G6eGxq4SN1em7cQcJuOWM2cvj5Q@mail.gmail.com
Hello,
Arne Babenhauserheide <arne_bab@web.de> ezt írta (idÅ‘pont: 2019. júl. 14.,Vas 13:11):
Toggle quote (10 lines)> Hi Mark,>> Mark H Weaver <mhw@netris.org> writes:> > My log file contains the same error in the 'tokudb_bugs.mdev4533' test:> >> > mysqltest: At line 6: query 'CREATE TABLE t1 (a INT(11), b CHAR(8))> ENGINE=TokuDB' failed: 1005: Can't create table `test`.`t1` (errno: 28 "No> space left on device")>
Could you test using df -i if the file system is not running out of inodes?That is another reason when the no space left on device error is reported.
Toggle quote (19 lines)>> > After the build attempt, the failed build directory is ~3.4 GB, and I> > still have ~7.4 GB. That seems to imply that I had over 10 GB free> > before starting the build, which sounds about right. I don't have a> > separate /tmp partition.> …> > I should mention that I'm using Btrfs.>> I use ext4, but I saw no space left on device errors when running guix> lint. Since I had 700GiB free, that does not sound like real missing> disk space, but rather that something else is wrong.>> Best wishes,> Arne> --> Unpolitisch sein> heißt politisch sein> ohne es zu merken>
Best regards,g_bor
Toggle quote (1 lines)>
Attachment: file
M
M
Marius Bakke wrote on 14 Jul 2019 19:17
(name . Mark H Weaver)(address . mhw@netris.org)
87d0ic7cz6.fsf@devup.no
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (11 lines)> Hello again,>>> Could it be that you don't have enough disk space for this test? Do you>> have the log file available still?>> I made another build attempt on my X200, this time logging the output of> "df --si" every 10 seconds. The free space started at ~11 GB free and> never went below 7 GB, but the 'tokudb_bugs.mdev4533' test failed as> before: "No space left on device" while trying to create the 'test'> table.
Thanks for testing. Out of curiousity I tried to enable TokuDB on myserver:
MariaDB [(none)]> INSTALL PLUGIN tokudb SONAME 'ha_tokudb';ERROR 2006 (HY000): MySQL server has gone away
Ouch.
Unfortunately the Guix service does not seem to enable any kind oflogging, so I haven't dug further. Loading other plugins seems to workthough.
I am currently trying this patch on Berlin:
Toggle diff (33 lines)diff --git a/gnu/packages/databases.scm b/gnu/packages/databases.scmindex 6bfeaad9a2..c17031bb2c 100644--- a/gnu/packages/databases.scm+++ b/gnu/packages/databases.scm@@ -659,6 +659,10 @@ Language.") ;; For now, disable the features that that use libarchive (xtrabackup). "-DWITH_LIBARCHIVE=OFF" + ;; FIXME: Disable the TokuDB engine, because its test suite frequently+ ;; fails, and loading it crashes the server: <https://bugs.gnu.org/35521>.+ "-DTOKUDB_OK=OFF"+ ;; Ensure the system libraries are used. "-DWITH_JEMALLOC=yes" "-DWITH_PCRE=system"@@ -706,9 +710,6 @@ Language.") ;; 2030-12-31. See <https://bugs.gnu.org/34351> for details. "main.mysqldump" - ;; XXX: Fails sporadically.- "innodb_fts.crash_recovery"- ;; FIXME: This test fails on i686: ;; -myisampack: Can't create/write to file (Errcode: 17 "File exists") ;; +myisampack: Can't create/write to file (Errcode: 17 "File exists)@@ -786,7 +787,6 @@ Language.") ("libxml2" ,libxml2) ("ncurses" ,ncurses) ("pcre" ,pcre)- ("snappy" ,snappy) ("xz" ,xz) ("zlib" ,zlib))) (propagated-inputs
WDYT?
There has been some activity around TokuDB in later versions of MariaDB,maybe we can enable it again with 10.4. For now, I think we should justdisable it.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0rY40ACgkQoqBt8qM6VPp6yQgAyfNo15rnVRXpzjKPwFLHL8PoDfIl6zEV3KkjI0m5Z3PpKot+lQR1h+gl0angHzQZ22XBwd3GxMK9mkh575eWagJlxEYygbHHWwiXDfKpLXlMe4qJFnQD4bxYo0iG5iaFYG7Bsv2Zs4IO4pp35jJflzsITM+w/MfiNNrLy1OV8kOMwXi8JkDAtyQvC3DqeuTbm2zOoSAw9CZZQH01vwBPe0PSFLKd0oU1Lor9ybzF7SxzQwjBcFAGsqQvwNEUD3wSvMiTcX0goTtvqzBAZMf9kRq7MsXpckiFSRZi8k+6C8okQzxu7TL9ZpvpvEhF+8Jz9iqve1oj6Gb7h92gaFyHxA===09ft-----END PGP SIGNATURE-----
M
M
Mark H Weaver wrote on 14 Jul 2019 20:34
(name . Marius Bakke)(address . mbakke@fastmail.com)
87a7dgzcr3.fsf@netris.org
Hi Marius,
Marius wrote:
Toggle quote (4 lines)> There has been some activity around TokuDB in later versions of MariaDB,> maybe we can enable it again with 10.4. For now, I think we should just> disable it.
Disabling TokuDB for now sounds like a fine option.Thanks very much for looking into it.
Mark
M
M
Marius Bakke wrote on 14 Jul 2019 23:15
(name . Mark H Weaver)(address . mhw@netris.org)
875zo471xc.fsf@devup.no
Mark H Weaver <mhw@netris.org> writes:
Toggle quote (10 lines)> Hi Marius,>> Marius wrote:>> There has been some activity around TokuDB in later versions of MariaDB,>> maybe we can enable it again with 10.4. For now, I think we should just>> disable it.>> Disabling TokuDB for now sounds like a fine option.> Thanks very much for looking into it.
Done in bba7a77ed9ad826bcdc6d9b8a183d66a23229501.
Thanks for reporting the issue.
Thinking forward, to trim the mariadb package, maybe it's possible tobuild all plugins as separate derivations, and let the user choose aunion when setting up the service.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl0rm38ACgkQoqBt8qM6VPrkxAf9F6aDUmH/ZYOu8LS5PA/uOM/j2ZUjYSesi41Jgn5i2SjqVHAKMoCAn2uKH59nRj8SIt0wOdYKcX4CZyM3iP7afIrWK0bMDPH4rQeMeUloC4qhvan3PyIGb6+SgIiV/Ksq58pK0xX7NGPoFIt0OuY4fFtqiIiiM5O1GDOOTpf8fWY5+WBugHIK+0WRUj9fGFLnBfBMJPtCwvCN1HtVDWg2S11e6JVvxwDrAyaIstoa3FlZTNnMBR6xZbauhuKKg/y2GQGfqUHCSWep42kj2QO/yuTBu5ZoOu5eSOp9+BLeojhWLN9S5NtakQ+7dXNmY9BnrZ7dIytebZKsJkVcqmd6JQ===aOnv-----END PGP SIGNATURE-----
Closed
?
Your comment

This issue is archived.

To comment on this conversation send email to 35521@debbugs.gnu.org