Vadim Tkachenko writes:
> If you can share your Buildbot configuration that would be perfect!
> As for platforms we see demand for Debian/Ubuntu/CentOS both 32bit and
> 64bit. Also quite often are mentioned FreeBSD, MacOS and Windows.
Ok, it's attached. Just let me know if you have any question
Paul McCullagh writes:
> The problem is occurring when running the PBXT test suite from the
> Maria mysql-test directory.
>
> So maybe the problem is that udf_example.so was not built.
That was my thought too, but I checked, and the udf_example.so was
present. And beside, even if it was not, the
Paul McCullagh writes:
> On Apr 6, 2009, at 1:17 PM, Kristian Nielsen wrote:
>> Just let me know if you need more help/information on these failures.
>
> Yes, thanks. I would like to get these fixed.
I have attached a log of running the test suite on my machine. This is an
Ubun
Vadim Tkachenko writes:
> You ask good question re: INNODB_RW_LOCKS_USE_ATOMICS, this is actually
> one of main points of XtraDB to improve scalability on 8CPU+ boxes, so
> we just rely on it.
Yes, understood.
> XtraDB can be built without INNODB_RW_LOCKS_USE_ATOMICS, but effect may
> be opposi
Michael Widenius writes:
> Looked through the patch, and found only one possible thing to comment
> about:
>
> It lookes liked this case is handled, but from the patch/current code
> it was not trivial to be sure.
>
> - We run some tests, one test fails.
> - Test suite fails totally (for example
Michael Widenius writes:
> What I *would* like to change ASAP is that the test file and result
> file is in the same directory so that in 'bzr gcommit' and in 'emacs
> directory' the test and result files comes directly after eachother!
> This has been on the mysqltest TODO for a long time but fo
Michael Widenius writes:
> Hi!
>
>>>>>> "Kristian" == Kristian Nielsen writes:
>
>
>
> Kristian> I am still not sure whether generic (.tar.gz) binaries should be
> build
> Kristian> statically (and to what extend).
>
> The ben
As the MySQL Users's Conference is starting up, Monty and I wanted to have
tarballs with source and binaries available to make it easier for interested
people to try it out.
The plan for future binaries is to have Ourdelta publish them from MariaDB
sources, however due to lack of time this was not
Hi Igor,
I have been trying to figure out the problems you see in the mysql_client_test
test case in the MariaDB 5.1 tree. It has been tricky due to not being able to
reproduce.
Patrick Crews was able to reproduce though, and was helpful enough to file
this bug with some additional info:
htt
Don Kehn writes:
> when compiling on x64 systems (i.e. CentOS & Fedora core 10) and using the
> BUILD/compile-pentium64-max, I'm getting the -lz error "/usr/bin/ld: cannot
> find -lz" and when I simplify the ./comfigure line to a --without-zlib it
Hm, could not reproduce this locally. This was u
I noticed a difference between Bitkeeper and Bzr merges.
In Bitkeeper, merge parents are essentially unordered. The two parents of a
merge are completely equal, and there is no way from the Bitkeeper to history
to say whether one parent was merged into the other or vise versa. The actual
order in
Hi Toby,
Nice (and much needed) cleanup of the Solaris BUILD/* scripts, thanks a lot!
And thanks for the PBXT portability fixes also.
I have a few smaller comments given inline below. The patch should be ok to
be pushed to main after these are resolved.
I suggest you re-commit all of the changes
Don Kehn writes:
> display.c:(.text+0x282): undefined reference to `tputs'
This sounds like you are missing curses development libraries.
On my machine (Ubuntu Hardy), I think they are in the package libncurses5-dev.
Hopefully this will get you one step further.
(Btw, on Ubuntu/Debian, a quic
Toby Thain writes:
>> Just out of curiosity, what is the reason for this requirement?
>
> Path assumptions in the autotools.
>
> $ head `which aclocal`
> #!/usr/local/bin/perl -w
Ah, I see, thanks for the info.
>>> +export warnings c_warnings cxx_warnings base_cxxflags
>>
>> Hm, these actually
Toby Thain writes:
> Maybe separation of variables for the truly platform-independent
> flags (like -g, -O, ...) and the non-portable ones that currently
> assume gcc (-Wxxx) is indicated. Do you have a Windows build system
> yet?
Yes, that would be the correct way, I think. And no, we don't hav
"Oleksandr \"Sanja\" Byelkin" writes:
> Since we switched to bazaar I do it in such way (to reduce merge commit
> size):
>
> 1) bzr branch
> 2) cd
> 3) bzr meerge ../
> 4) build/test
> 5) bzr gcommit
> 6) bzr push (or merge) to (or with) and so on
Yes, I see. I like this way, I think I will
Don Kehn writes:
> This is how I got it to work and there maybe an issue here:
> using the BUILD/compile-pentium64-max, changed the changed the
> extra_configs="$pentium_configs $max_configs $static_link" to
> extra_configs="$pentium_configs $max_configs" (notice the static_link is
> removed). It
again,
- Kristian.
Kristian Nielsen writes:
> Don Kehn writes:
>
>> This is how I got it to work and there maybe an issue here:
>> using the BUILD/compile-pentium64-max, changed the changed the
>> extra_configs="$pentium_configs $max_configs $static_link" to
>>
Kristian Nielsen writes:
> I think there are two issues here.
>
> One is that we are replacing InnoDB with XtraDB in MariaDB. Thus we need
> XtraDB to build and work on all the platforms that MariaDB should work on.
>
> The other is to get good performance/scalability of Xt
Paul McCullagh writes:
> On Apr 6, 2009, at 1:17 PM, Kristian Nielsen wrote:
>> Do you have a plan for merging in subsequent PBXT changes to
>> MariaDB? (I guess
>> you do, just don't know how it works). Would you be in charge of
>> regular
>> merging, or s
Kristian Nielsen writes:
> I suggest you re-commit all of the changes as a single commit (this is
> generally preferred in Maria development), or at least add a good commit
> message (eg. mention fixing the BUILD/ scripts). Also, you should add per-file
> commit messages; one way
Toby Thain writes:
> I have uncommit'd the last 4 of my local commits, but unfortunately
> gcommit is not available to me as I am doing this work on a headless
> server. I am not aware of any way this can be done on the command
> line (I did check #bzr and Google). Do you mind if I omit per-file
Stewart, thanks for providing this procedure!
Nice to know that this method with renaming to common paths and merging can
work.
Paul McCullagh writes:
> So to correct this I will have to redo the integration of PBXT is into
> MariaDB.
Yes, I think we should re-do the merge with this tracking o
Sergey Petrunya writes:
> Grid display (http://askmonty.org/buildbot/grid) is very nice, but it
> would be even nicer if one could display only pushes into one particular
> branch, like in pushbuild. Is it difficult to achieve? If not, can I request
> it from somebody or will need to spend the ef
Paul McCullagh writes:
> I am just trying to merge for the second time into mariadb-5.1-pbxt-
> merge-new, and get the following:
>
> pmc-2:Repositories/maria/mariadb-5.1-pbxt-merge-new] build% bzr merge
> lp:pbxt
> M storage/pbxt/src/cache_xt.cc
> M storage/pbxt/src/ha_pbxt.cc
> M storage
Paul McCullagh writes:
> Looks like this bug was reported already:
>
> https://bugs.launchpad.net/bzr/+bug/364305
Yes, this looks like the same problem.
> The question is: is this a show stopper for us at the moment?
Yes, I think so. I do not want to merge this and run the risk of a corrupted
Kristian Nielsen writes:
> One thing I might try is to re-do the merge in smaller steps. There is a _lot_
> of add/move/delete/patch the same file in the same changeset, and it is clear
> that it is very hard to get all the special cases of this right in the bzr
> code (I would per
Paul McCullagh writes:
> I must say I find it strange that bzr is merging files with .OTHER
> and .BASE endings, because these are temp files which only occur after
> a merge conflict.
My thinking is that these were accidentally added at some point in the
history, and subsequently removed. And w
orks ok).
(Incidentally, this way also makes it possible to correlate the branch history
directly with build history from Buildbot/Pushbuild, something I really missed
in the BitKeeper days).
- Kristian.
Kristian Nielsen writes:
> I noticed a difference between Bitkeeper and Bzr merges.
>
Sergey Petrunya writes:
> [1]. The problem I'm looking at is that for some reason it takes unreasonable
> amounts of time and bandwidth to do any operations on the staging trees. I
> have no idea why, perhaps we're hitting a bug in bazaar's handling of stacked
> branches. Maybe we should switch t
Kristian Nielsen writes:
> No idea, sorry...
Hm, I just remembered something odd on the 6.0 Launchpad tree:
https://code.launchpad.net/~maria-captains/maria/6.0
Repository format: Packs containing knits without subtree support
This is different from our other repositor
Toby Thain writes:
> Well done on finding this. What next - do I need to give you
> permission to commit to my Sol 10 branch?
No need, you can pull it from the branch I just pushed to Launchpad:
lp:~knielsen/maria/plugin_load_fix
- Kristian.
__
Kristian Nielsen writes:
> Following up on this, I just learned about the bzr option
> append_revisions_only that can be set on a branch.
Any opinions on this?
Having thought more on this, I really think we should enable
append_revisions_only.
There are many tools (and people as well
Hi,
There is a query cache related failure seen in Buildbot:
https://askmonty.org/buildbot/builders/hardy-amd64-dbg/builds/35/steps/test/logs/stdio
main.query_cache_28249 [ fail ]
Test ended at 2009-05-21 09:13:10
CURRENT_TEST: main.query_cache_28249
---
/home/ar
There is another test failure visible in Buildbot:
https://askmonty.org/buildbot/builders/gentoo-x86-dbg/builds/13/steps/test/logs/stdio
---
main.show_check [ fail ]
Test ended at 2009-05-22
kniel...@knielsen-hq.org writes:
> #At lp:maria
>
> 2706 kniel...@knielsen-hq.org2009-05-25
> Imported freely distributable documentation from upstream MySQL 5.1.34
> source tarball.
> added:
This commit adds documentation files that are included in the MySQL source
tarballs
Michael Widenius writes:
> K> In this case, Joe will instead have to do this:
>
> K> bzr branch lp:maria # or bzr pull lp:maria into an existing clean
> clone
> K> bzr merge ../branch-with-patch
> K> bzr commit -m"merged with trunk"
> K> bzr push lp:maria
>
> K> Then the resulti
As discussed in previous mails, I have now enabled the append_revisions_only
option in our main Launchpad trees:
lp:maria
lp:maria/5.2
lp:maria/6.0
This email describes how merging must now be done to avoid getting this error
when pushing:
bzr: ERROR: Server sent an unexpected er
Daniel Bartholomew writes:
> Monty> Agree. Until we get a maintiner, I assume Daniel can start looking at
> Monty> these.o
That would be great. I just pushed the imported files to lp:maria.
> for the Knowledgebase. Do you know if it is the installation
> instructions, the man pages, the help t
Sergey Petrunya writes:
> I've got a branch with the code for MWL#17. Could you please add it to what
> BuildBot builds?
Done, it is running a test build now.
I also documented the procedure for this on internal wiki:
https://internal.askmonty.org/internal/index.php/BuildbotSetup#Launchp
Toby Thain writes:
> Toby Thain has proposed merging lp:~qu1j0t3/maria/solaris10-port into
> lp:maria.
> Added build scripts for 32 bit x86 architecture on Solaris. Renamed some
> scripts for consistency. Changed to dynamic linking of libgcc.
> --
> https://code.launchpad.net/~qu1j0t3/maria/s
Michael Widenius writes:
>> "noreply" == noreply writes:
>
> noreply> === modified file 'mysys/my_getopt.c'
> noreply> --- mysys/my_getopt.c2009-04-25 10:05:32 +
> noreply> +++ mysys/my_getopt.c2009-05-20 15:34:34 +
> noreply> @@ -647,7 +647,7 @@
> noreply> retu
Paul Charles Leddy writes:
> FYI, this really helped out getting started:
>
> http://drizzle.org/wiki/Contributing_Code
>
> Is there some way I can add something similar to maria's launchpad site?
Any offer to help with this would certainly be most appreciated! I agree that
something like this
Just to follow up on some IRC discussion on this, I posted the following to
the InnpDB plugin forum (which the webpage suggests for bug reports).
I think it is bad that the create table will work or not depending on zlib
version. However, I also think it is best to let InnoDB fix it. Having a
diff
Kristian Nielsen writes:
> Just to avoid duplicate work, let me just mention that I am now starting to
> look into this issue. I will try to find a good way to make XtraDB
> compile/work on all the platforms/compilers we want to support, and report
> back what I discover.
I g
Kristian Nielsen writes:
> I got some good progress on this. I re-did the merge using the merge-into bzr
> plugin (advise from bzr developers). This should allow us to merge directly
> from the lp:percona-xtradb tree into lp:maria in the future.
I just tested this, and it seems to wo
Hi Serg,
We discussed something like this on IRC some time ago. What do you think of
this change? It keeps the use of GCC stuff for maria/my_atomic disabled, while
still letting other parts (ie. XtraDB) check for GCC intrinsics availability.
- Kristian.
kniel...@knielsen-hq.org writes:
> #At l
Michael Widenius writes:
> knielsen> === modified file 'configure.in'
> knielsen> --- a/configure.in 2009-04-23 13:06:16 +
> knielsen> +++ b/configure.in 2009-06-10 09:13:53 +
> knielsen> @@ -1739,28 +1763,9 @@ case "$with_atomic_ops" in
> knielsen>[Use pthread rwlo
Michael Widenius writes:
> knielsen> === modified file 'mysql-test/r/innodb.result'
> knielsen> --- a/mysql-test/r/innodb.result2009-06-09 15:08:46 +
> knielsen> +++ b/mysql-test/r/innodb.result2009-06-18 12:39:21 +
> knielsen> @@ -1970,7 +1970,7 @@ explain select count(*) from t1
Michael Widenius writes:
> knielsen> +/*
> knielsen> + We initialise the hashes for deadlock detection lazily.
> knielsen> + This greatly helps with performance when lots of mutexes are
> initiased but
> knielsen> + only a few of them are actually used (eg. XtraDB).
> knielsen> +*/
> knielsen
Regarding the XtraDB merge into MariaDB, I am now finally getting ready to
push the merge, after lots of small fixes in different areas.
The code is available in the mariadb-xtradb-merge2 branch:
https://code.launchpad.net/~maria-captains/maria/mariadb-xtradb-merge2
The buildbot testing is h
sa...@askmonty.org writes:
> #At lp:maria
>
> 2712 sa...@askmonty.org 2009-06-25
> Fix of BUG#45632 (http://bugs.mysql.com/bug.php?id=45632) - sharing non
> default debug settings between sessions. This bugfix proposed by Monty.
> modified:
> mysql-test/r/variables_debug
Vadim Tkachenko writes:
> We are about to finalize xtradb-release6, I think it makes sense to push
> this new release.
Yes, that sounds reasonable. Unless there are substantial changes compared to
latest bzr a few days ago, it should be simple to merge it.
> I am trying to incorporate your chan
Hi Toby,
Toby Thain writes:
> On 3-Jun-09, at 12:48 PM, Kristian Nielsen wrote:
>
>> Toby Thain writes:
>>
>>> Toby Thain has proposed merging lp:~qu1j0t3/maria/solaris10-port
>>> into lp:maria.
>>
>>> Added build scripts for 32 bit x86 ar
Vadim Tkachenko writes:
> I made push to
>
> lp:~maria-captains/maria/mariadb-xtradb6-merge
>
> (not proposed for merge yet).
>
> If everything is fine we can merge it to maria.
I am now looking into this.
I have a hard time understanding this merge. It seems you just applied
manually a patch a
raDB 6 release. That is the crucial thing.
- Kristian.
> Kristian Nielsen wrote:
>> Vadim Tkachenko writes:
>>
>>> I made push to
>>>
>>> lp:~maria-captains/maria/mariadb-xtradb6-merge
>>>
>>> (not proposed for merge yet).
>>&
Kristian Nielsen writes:
> Vadim Tkachenko writes:
>
>> Ok, let's try to figure out how to merge it properly :)
>>
>> I tried to include all your changes, but seems failed.
>>
>> Actually all latest changes should be in lp:xtradb.
>
> Hm, we mus
Kristian Nielsen writes:
> lp:~maria-captains/maria/mariadb-xtradb6-merge is missing all of the changes
> outside of storage/xtradb (except one CMakeLists.txt). These missing changes
> should not go in stand-alone xtradb, but are needed in MariaDB.
>
> lp:xtradb does not exist. lp
Vadim Tkachenko writes:
> Kristian,
>
> Now lp:percona-xtradb/release-6 and lp:percona-xtradb
> should be synchronized and be up-to-date.
I still do not see that this is the case :-(
- Last push to lp:percona-xtradb is from June 26, and does not appear
up-to-date with latest XtraDB6 release
Hi Sergey,
I was looking at the many failures we have in the jaunty-x86-valgrind host in
Buildbot ...
I was wondering if you could install the `libc6-dbg' package?
sudo apt-get install libc6-dbg
Assuming it works as in Ubuntu Hardy, this should give proper symbols in the
Valgrind stack trac
Just a remark about adding Valgrind suppressions for problems in system
libraries that we cannot fix.
I see in mysql-test/valgrind.supp a number of suppressions like this:
{
dlclose memory loss from plugin variant 4
Memcheck:Leak
fun:malloc
obj:/lib*/ld-*.so
Ok, XtraDB 6 is now pushed to MariaDB, as a replacement for InnoDB!
Merging was ok. There are a number of conflicts which need to be handled, but
that seems inevitable, and bzr seems to handle things ok (if a bit clunky).
There are no further issues know at the moment.
Thanks for working with me
Michael Widenius writes:
>> "Patrick" == Patrick Galbraith writes:
>
> Patrick> Monty,
> Patrick> I saw your message in IRC - I replied in case you don't see it . I
> want
> Patrick> to get this into the tree soon and am only having a small problem
> right now:
>
> Patrick> [08:06] mont
I have now implemented and installed in our Buildbot enhanced facilities for
dealing with compiler warnings.
We already have a file support-files/compiler_warnings.supp, which I think is
used by PushBuild @ MySQL. The new facilities in our Buildbot uses the same
file to suppress certain warnings t
We are starting to add new features to MariaDB (that are not in MySQL),
including user-visible features.
I think we need to decide now how we will handle keeping documentation for
these new features.
There is an open issue about the MySQL documentation being non-free, and
whether we can do anythi
"Oleksandr \"Sanja\" Byelkin" writes:
> If format is simple we can do it as were doing in early MySQL - every
> developer adds description to the doc then editor fix what he things is
> better. This of course require:
Yes, that is what I have in mind as well.
And actually, I see no reason for n
Henrik Ingo writes:
> If you start writing the docs in a wiki markup, then the natural
> question is, why not use a subsection of AskMonty.org as "the
> repository". You would then have it automatically validated and
Yes.
In this case, we need to do more careful work, as then the documentation
Henrik Ingo writes:
> Now that I think about it, maybe this part of the documentation effort
> could for the time being be done as a diff against the MySQL manual.
> (Which is DocBook?)
Have you checked the implications of the copyright/license issues for this
idea?
- Kristian.
__
Michael Widenius writes:
> Hi!
>
>>>>>> "Kristian" == Kristian Nielsen writes:
>
> Kristian> Sergey Petrunya writes:
>>> I've worked through the list and filed
>>>
>>> MWL#39 Replication tasks
>>>
>&g
Michael Widenius writes:
>>> Note that it would also be very nice to have in the binlog the exact
>>> original statement:
>
> Kristian> Yes. There was actually a customer request for this.
>
> Kristian> I think for this we would actually need a new binlog event type
> Kristian> (Comment_log_event
I read throught the worklogs, did some research, and wrote up a number of
comments.
I am not sure about the best way to proceed, but this is my suggestion.
I have written up in this email all my comments in detail. After any
discussion, I suggest I update the worklogs as per the conclusions (thou
Guestimates (hours), including low-level design, implementation, test cases,
review, post-review fixes, and documentation. Note that without low-level
designs, and with no prior experiences with estimating MariaDB work, these are
little more than wild guesses:
MWL#36:
Option 1: 12+24+5+2+4+2
Paul McCullagh writes:
> Paul McCullagh has proposed merging lp:~paul-mccullagh/maria/maria-pbxt-rc2
> into lp:maria.
>
> Requested reviews:
> Maria-captains (maria-captains)
>
> Updated the PBXT engine to RC2 (lp:pbxt/rc2), version 1.0.08c. All tests in
> the PBXT suite pass.
>
> Note that
Sergey Petrunya writes:
> Buildbot seems to have a wrong idea about the order of bazaar's revision
> numbers. It also shows only last five pushes, and these two issues together
> make it impossible to see the recent status.
>
> The problem can be observed in maria-5.1-table-elimination tree:
> h
Kristian Nielsen writes:
> Also, I think I will write a feature request for Launchpad to include the
> revision ids in the email notifications, so at least the information can be
> made available to the PHP pages.
https://bugs.launchpad.net/launchpad-code/+bug/419057
-
Kristian Nielsen writes:
> Kristian Nielsen writes:
>
>> Also, I think I will write a feature request for Launchpad to include the
>> revision ids in the email notifications, so at least the information can be
>> made available to the PHP pages.
>
> https://bug
Paul McCullagh writes:
> Hi Kristian,
>
> Thanks for the patch!
>
> I will definitely include these changes in the PBXT trunk.
>
> I am happy to accept any changes that allow the code to compile
> without warnings (this is also a requirement for compiling with
> Drizzle).
The other warning I saw
patches at http://www.yassl.com/, so
please let me know if there is some other email address or procedure I should
follow.
Signed-off-by: Kristian Nielsen
diff -u --recursive yassl-1.9.6.orig/include/yassl_int.hpp yassl-1.9.6.new/include/yassl_int.hpp
--- yassl-1.9.6.orig/include/yassl_int.hpp
Sergey Petrunya writes:
> At file:///home/psergey/dev/maria-5.1-table-elim-r11-gcov/
>
>
> revno: 2747
> revision-id: pser...@askmonty.org-20090825150255-46i5gvl2ctd0jcm2
> parent: pser...@askmonty.org-20090825145915-rxwmfczgqe69r5ju
>
Paul McCullagh writes:
> Paul McCullagh has proposed merging lp:~paul-mccullagh/maria/maria-pbxt-rc2
> into lp:maria.
>
> Requested reviews:
> Maria-captains (maria-captains)
>
> Updated the PBXT engine to RC2 (lp:pbxt/rc2), version 1.0.08c. All tests in
> the PBXT suite pass.
>
> Note that
Paul McCullagh writes:
>> mysqltest: At line 3: query 'alter table t1 rename mysqltest.t1'
>> failed: 1025: Error on rename of './test/t1' to './mysqltest/
>> t1' (errno: 16)
>
>
> Occurs because the PBMS code is compiled in.
>
> This can be disabled by commenting out:
>
> #define PBMS_ENABLED
Peter Laursen writes:
> I have a concern that I will ask you all to consider while there is
> time. I think I understand that after MariaDB 5.1 a 5.2 release is
> planned. I think it should not be versioned like that. Problem is that
> there is a MySQL 5.2 tree too (it is basically an early 6.
Kristian Nielsen writes:
> So I will merge this into MariaDB with attached patch to disable PBMS and fix
> test failures.
Ok, so I merged it. But now I have a problem with PBXT crashing sometimes
during shutdown.
To reproduce, run the following command in a build of lp:maria:
mk
Kristian Nielsen writes:
> Ok, so I merged it. But now I have a problem with PBXT crashing sometimes
> during shutdown.
Filed a bug on this on Launchpad:
https://bugs.launchpad.net/maria/+bug/422550
- Kristian.
___
Mailing list:
The issue of static vs. dynamic linking keeps coming up in relation to
building of MariaDB (and MySQL). I thought I would share some thoughts on
this.
There is a tradition for linking statically in MySQL for performance and other
reasons. However, these days there are a number of problems with sta
Kristian Nielsen writes:
> Davi Arnaut writes:
>
>> I've been monitoring the maria-developers list and there are some
>> patches that we would like to gradually incorporate into our
>> branches. For a practical example, i would like to merge into 5.1
>> parts
While the subject of this mail is not quite true yet, I'm happy to announce
progress on this project that Monty and I have been discussing for some time.
Basically, compiler warnings are very useful to catch a number of bugs in our
sources. This has been proven time and time again. However, to do
nore...@launchpad.net writes:
> Merge authors:
> Michael Widenius (monty)
>
> revno: 2726 [merge]
> committer: Michael Widenius
> branch nick: maria
> timestamp: Thu 2009-09-03 17:56:46 +0300
> message:
> Updated documentation files
Hakan Kuecuekyilmaz writes:
> Where do you need some help for our release?
Looking at http://askmonty.org/wiki/index.php/MariaDB_5.1_TODO, seems it is
currently mostly the mysql-5.1.38 merge.
One thing that would be useful is to try some additional testing on top of
what is already in Buildbot,
Sergey Petrunya writes:
> At file:///home/psergey/bzr-new/mysql-5.1-maria-contd2/
>
>
> revno: 2723
> revision-id: pser...@askmonty.org-20090909210657-i1of5o03ymoozwvs
> parent: pser...@askmonty.org-20090908162138-wtd6r54dkcp4hg5a
> com
Sergey Petrunya writes:
> At file:///home/psergey/bzr-new/mysql-5.1-maria-contd2/
>
>
> revno: 2721
> revision-id: pser...@askmonty.org-20090908160458-fglojzacu8inqb9q
> parent: pser...@askmonty.org-20090907205010-tnvi4bomzq2b1eut
> par
Hi Sergey,
Attached patch fixes two more failures in the merge as seen in Buildbot.
The main.innodb failures are two different issues. One I already fixed in
another place in XtraDB, I added a comment to explain better. The other looks
like a merge error, the result file was changed in the merge
act
+# alignment of obtained memory.
--replace_result 512 511
SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_buffer_pool_pages_total';
SELECT variable_value FROM information_schema.global_status WHERE LOWER(variable_name) = 'innodb_page_size'
Sergey Petrunya writes:
> At file:///home/psergey/bzr-new/mysql-5.1-maria-contd3/
>
>
> revno: 2730
> revision-id: pser...@askmonty.org-20090914224548-yho0nxw78vvxd5yi
> parent: kniel...@knielsen-hq.org-20090912073839-2jfav265c8pkm1ae
>
Hi Sergey,
Here is the diff of the extra stuff that Jani and Monty merged, but which is
not included in MySQL-5.1.38.
As can be seen, none of it really matters (except the version number; I'll fix
that to be 5.1.38-maria-beta1).
I suggest we just leave it in place to simplify future merges.
Sti
Hi Sergey,
Here is the diff of the commits that are not yet merged from MySQL 5.1.38
(they are missing from our merge since they were not yet pushed to Launchpad
by the MySQL build team when the merge was done by Jani and Monty).
There is a Windows build one-liner, but don't know if it will help
Sergey Petrunya writes:
> At file:///home/psergey/bzr-new/mysql-5.1-maria-contd4/
>
>
> revno: 2746
> revision-id: pser...@askmonty.org-20090917001350-pyxja2suxylxhez1
> parent: pser...@askmonty.org-20090916190503-kgckwua1roxhonsy
> com
Igor Babaev writes:
> #At lp:maria based on revid:i...@askmonty.org-20090916174301-lzzh1r0khn3dxwvp
>
> 2744 Igor Babaev 2009-09-16
> Fixed a failure of the merge_innodb test on windows.
> modified:
> storage/myisammrg/ha_myisammrg.cc
>
> === modified file 'storage/myisammrg/ha_myisa
Hakan Kuecuekyilmaz writes:
> Kristian,
>
> I have now a rough idea on how to run our make distcheck test.
>
> What I need is a howto about adding tests to buildbot.
>
> In Pushbuild times, BUILD/compile-dist && make dist was run prior
> to all other tests. The machines connected to Pushbuild wou
Hi,
While merging the Percona microsec_process patch (the 5.1 port of the patch is
called acc-pslist), I encountered a problem related to Bug#22047:
http://bugs.mysql.com/bug.php?id=22047
The issue is with the exact behaviour of the TIME column of SHOW FULL
PROCESSLIST and information_schema
801 - 900 of 1032 matches
Mail list logo
