into  damien-katzs-computer.local:/Users/dkatz/mysql51

Added libCsup as a mysql library dependency on hpux11.

This means any projects statically linking to our libraries using the HPUX11 compiler will need to add the -lCSup option to their build link options. If they use the mysql_config tool this will happen automatically.

Projects that dynamically link to libmysqlclient will continue to work without any modifications.

Library libCsup is a C++ runtime library needed for yassl support when built with the hpux11 C/C++ compiler. The first attempts to fix this bug were to remove the yassl dependencies on libCsup. We tried removing all pure virtual functions and other hacks, but the dependency remained. The only other options left involve extensive restructuring of the yassl library.
    

internal ones (like those of GROUP BY): fixing the --help text.

  remove unused variable "bit_no"

into  ramayana.hindu.god:/home/tsmith/m/bk/inno/jul24/51

I forgot to check in some new files: lock0priv.h lock0priv.ic lock0iter.c lock0iter.h

into  amd64.(none):/src/bug24732/my51-bug24732

- Required manual merge.

into  amd64.(none):/src/bug24732/my51-bug24732

- Sign executables with MySQL AB security certificate.

Fixes:
- Bug #23710: crash_commit_before fails if innodb_file_per_table=1
- Bug #28254: innodb crash if shutdown during innodb_table_monitor is running
- Bug #28604: innodb_force_recovery restricts data dump
- Bug #29097: fsp_get_available_space_in_free_extents() is capped at 4TB
- Bug #29155: Innodb "Parallel recovery" is not prevented

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/jul24/51

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/jul24/51

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/jul24/50

into  trift2.:/MySQL/M51/push-5.1

into  mysql.com:/home/kent/bk/tmp3/mysql-5.0-build

into  mysql.com:/home/kent/bk/tmp3/mysql-5.1-build

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  moonbone.local:/mnt/gentoo64/work/29898-bug-5.0-opt-mysql

into  trift-lap.none:/MySQL/M51/push-5.1

into  trift-lap.none:/MySQL/M50/push-5.0

into  trift-lap.none:/MySQL/M51/push-5.1

into  mysql.com:/home/ram/work/b28125/b28125.5.0

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.1-build

into  mysql.com:/home/ram/work/b28125/b28125.5.1

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  mysql.com:/home/ram/work/b29923/b29923.5.1

Result adjusted.

into  mysql.com:/home/ram/work/b28125/b28125.5.1

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0.46

into  damien-katzs-computer.local:/Users/dkatz/51

The Item_date_typecast::val_int function doesn't reset null_value flag.
This makes all values that follows the first null value to be treated as nulls
and led to a wrong result.

Now the Item_date_typecast::val_int function correctly sets the null_value flag
for both null and non-null values.