Raise version number after cloning 5.1.65
Bug #11765218 58157: INNODB LOCKS AN UNMATCHED ROW EVEN THOUGH USING
RBR AND RC

Description: When scanning and locking rows with < or <=, InnoDB locks
the next row even though row based binary logging and read committed
is used.

Solution: In the handler, when the row is identified to fall outside
of the range (as specified in the query predicates), then request the
storage engine to unlock the row (if possible). This is done in
handler::read_range_first() and handler::read_range_next().
Bug#11762052: 54599: BUG IN QUERY PLANNER ON QUERIES WITH
                     "ORDER BY" AND "LIMIT BY" CLAUSE

PROBLEM:
When a 'limit' clause is specified in a query along with
group by and order by, optimizer chooses wrong index
there by examining more number of rows than required.
However without the 'limit' clause, optimizer chooses
the right index.

ANALYSIS:
With respect to the query specified, range optimizer chooses
the first index as there is a range present ( on 'a'). Optimizer
then checks for an index which would give records in sorted
order for the 'group by' clause.

While checking chooses the second index (on 'c,b,a') based on
the 'limit' specified and the selectivity of
'quick_condition_rows' (number of rows present in the range)
in 'test_if_skip_sort_order' function. 
But, it fails to consider that an order by clause on a
different column will result in scanning the entire index and 
hence the estimated number of rows calculated above are 
wrong (which results in choosing the second index).

FIX:
Do not enforce the 'limit' clause in the call to
'test_if_skip_sort_order' if we are creating a temporary
table. Creation of temporary table indicates that there would be
more post-processing and hence will need all the rows.

This fix is backported from 5.6. This problem is fixed in 5.6 as   
part of changes for work log #5558
Bug #12615411 - server side help doesn't work as first statement

Problem description:
Giving "help 'contents'" in the mysql client as a first statement
gives error

Analysis:
In com_server_help() function the "server_cmd" variable was
initialised with buffer->ptr(). And the "server_cmd" variable is not
updated since we are passing "'contents'"(with single quote) so the
buffer->ptr() consists of the previous buffer values and it was sent
to the mysql_real_query() hence we are getting error.

Fix:
We are not initialising the "server_cmd" variable and we are updating
the variable with "server_cmd= cmd_buf" in any of the case i.e with
single quote or without single quote for the contents.
As part of error message improvement, added new error message in case
of "help 'contents'".
Bug #14035452 - MODULARIZE MYSQL_CLIENT_TEST
  Added new minimal client using same framework
  Added internal test using it
  Small changes to top level make/configure/cmake to have it built
Reverting broken configure/make stuff
Fixing wrong copyright. Index.xml was modified in 2005,
while the copyright notice still mentioned 2003.
Bug #13113026 INFORMATION_SCHEMA.INNODB_BUFFER_PAGE_LRUFROM 5.6 BACKPORT

Backporting the WL#5716, "Information schema table for InnoDB 
buffer pool information". Backporting revisions 2876.244.113, 
2876.244.102 from mysql-trunk.

rb://1175 approved by Jimmy Yang. 
Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE

Problem description:
Table 't' created with two colums having compound index on both the 
columns under innodb/myisam engine at remote machine. In the local 
machine same table is created undet the federated engine.
A select having where clause with along 'AND' operation gives wrong 
results on local machine.

Analysis: 
The given query at federated engine is wrongly transformed by 
federated::create_where_from_key() function and the same was sent to 
the remote machine. Hence the local machine is showing wrong results.

Given query "select c1 from t where c1 <= 2 and c2 = 1;"
Query transformed, after ha_federated::create_where_from_key() function is:
SELECT `c1`, `c2` FROM `t` WHERE  (`c1` IS NOT NULL ) AND 
( (`c1` >= 2)  AND  (`c2` <= 1) ) and the same sent to real_query().
In the above the '<=' and '=' conditions were transformed to '>=' and 
'<=' respectively.

ha_federated::create_where_from_key() function behaving as below:
The key_range is having both the start_key and end_key. The start_key 
is used to get "(`c1` IS NOT NULL )" part of the where clause, this 
transformation is correct. The end_key is used to get "( (`c1` >= 2) 
AND  (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') 
are changed as wrong conditions('>=' and '<=').
The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, 
flag = HA_READ_AFTER_KEY}

The store_length is having value '5'. Based on store_length and length 
values the condition values is applied in HA_READ_AFTER_KEY switch case.
The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of 
the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, 
here the '>=' is getting added as a condition instead of '<='.

Fix:
Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all 
parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in 
the if condition.
Backport of Bug#14171740 65562: STRING::SHRINK SHOULD BE A NO-OP WHEN ALLOCED=0
Bug#13741677 MYSQL_SECURE_INSTALLATION DOES NOT
             WORK + SAVES ROOT PASSWORD TO DISK!

The secure installation scripts connect to the
server by storing the password in a temporary
option file. Now, if the script gets killed or
fails for some reason, the removal of the option
file may not take place.

This patch introduces following enhancements :
* (.sh) Made sure that cleanup happens at every
  call to 'exit 1'. This is performed implicitly
  by END{} in pl.in.
* (.pl.in) Added a warning in case unlink fails
  to delete the option/query files.
* (.sh/.pl.in) Added more signals to the signal
  handler list. SIG# 1, 3, 6, 15
Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE

Fix for pb2 test failure.
BUG#13868860 - LIMIT '5' IS EXECUTED WITHOUT ERROR WHEN '5' 
               IS PLACE HOLDER AND USE SERVER-SIDE 

Analysis:
LIMIT always takes nonnegative integer constant values. 

http://dev.mysql.com/doc/refman/5.6/en/select.html

So parsing of value '5' for LIMIT in SELECT fails.

But, within prepared statement, LIMIT parameters can be
specified using '?' markers. Value for the parameter can
be supplied while executing the prepared statement.

Passing string values, float or double value for LIMIT
works well from CLI. Because, while setting the value
for the parameters from the variable list (added using
SET), if the value is for parameter LIMIT then its 
converted to integer value. 

But, when prepared statement is executed from the other
interfaces as J connectors, or C applications etc.
The value for the parameters are sent to the server
with execute command. Each item in log has value and
the data TYPE. So, While setting parameter value
from this log, value is set to all the parameters
with the same data type as passed.
But here logic to convert value to integer type
if its for LIMIT parameter is missing.
Because of this,string '5' is set to LIMIT.
And the same is logged into the binlog file too. 

Fix:
When executing prepared statement having parameter for
CLI it worked fine, as the value set for the parameter
is converted to integer. And this failed in other 
interfaces as J connector,C Applications etc as this 
conversion is missing.

So, as a fix added check while setting value for the
parameters. If the parameter is for LIMIT value then
its converted to integer value.
Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE

Fixed the missing of federated/include folder at the time 
of preparing package distribution, issue happens only in 5.1
Bug#14111180 HANDLE_FATAL_SIGNAL IN PTR_COMPARE_1 / QUEUE_INSERT

Space available for merging was calculated incorrectly.
INSTALL-BINARY placeholder: change invalid URLs (request from Kristofer)
Bug #14099846: EXPORT_SET CRASHES DUE TO OVERALLOCATION OF MEMORY

Backport the fix from 5.6 to 5.1
Base bug number : 11765562
Bug#14068244: INCOMPATIBILITY BETWEEN LIBMYSQLCLIENT/LIBMYSQLCLIENT_R
              AND LIBCRYPTO

Problem: libmysqlclient_r exports symbols from yaSSL library which
         conflict with openSSL symbols. This issue is related to symbols
         used by CURL library and are defined in taocrypt. Taocrypt has
         dummy implementation of these functions. Due to this when a
         program which uses libcurl library functions is compiled using
         libmysqlclient_r and libcurl, it hits segmentation fault in
         execution phase.

Solution: MySQL should not be exporting such symbols. However, these
          functions are not used by MySQL code at all. So avoid compiling
          them in the first place.
Bug#13928675 MYSQL CLIENT COPYRIGHT NOTICE MUST
             SHOW 2012 INSTEAD OF 2011

* Added a new macro to hold the current year :
  COPYRIGHT_NOTICE_CURRENT_YEAR
* Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro
  to take the initial year as parameter and pick
  current year from the above mentioned macro.
BUG#11757312: MYSQLBINLOG DOES NOT ACCEPT INPUT FROM STDIN
WHEN STDIN IS A PIPE
            
Problem: Mysqlbinlog does not accept the input from STDIN when 
STDIN is a pipe. This prevents the users from passing the input file
through a shell pipe.    

Background: The my_seek() function does not check if the file descriptor
passed to it is regular (seekable) file. The check_header() function in
mysqlbinlog calls the my_b_seek() unconditionally and it fails when
the underlying file is a PIPE.  
            
Resolution: We resolve this problem by checking if the underlying file
is a regular file by using my_fstat() before calling my_b_seek(). 
If the underlying file is not seekable we skip the call to my_b_seek()
in check_header().