automatic BuildRequires for source RPM: for every FILEPATH and
"Have library XXX" cached variable, detect what rpm package it comes from
and add it to the list of dependencies.

That is, the source RPM will BuildRequire all those packages that
were found by cmake when the source RPM was built. Presumably, our
CMakeLists.txt won't check for libraries that aren't needed for a build.

It supports libraries/executables/files found with
  FIND_LIBRARY
  FIND_FILE
  FIND_PROGRAM
  CHECK_LIBRARY_EXISTS

create source RPM cpack-way

when building binary packages, this source rpm will use
same BUILD_CONFIG and WITH_SSL values that were used when
creating the source RPM.

Only do it for a reasonably new cmake, where
source rpms are known to work (3.10.2 is ok, 3.5.2 is not).

And force a shorter CPACK_RPM_BUILD_SOURCE_DIRS_PREFIX so that
a source rpm could be built from a standard location in /usr/src

instead remove internal modules from Requires/Provides

add defensive $ for filenames, don't include .gitattributes
and *.rpm, correct rules for *.gz and *.zip

since long we use a different workaround, our own CPackRPM wrapper

now we can afford it. Fix -Werror errors. Note:
* old gcc is bad at detecting uninit variables, disable it.
* time_t is int or long, cast it for printf's

Fix mariabackup to crash if opening tablespace fails, insitead of
continuing after an error.

In a Ubuntu Xenial build environment, the compiler identified as
g++-5.real (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
seems to be emitting incorrect code for the compilation unit
trx0rec.cc, triggering a bogus-looking AddressSanitizer report
of an invalid read of something in the function trx_undo_rec_get_pars().
This is potentially affecting any larger tests where the InnoDB
purge subsystem is being exercised.

When the optimization level of trx0rec.cc is limited to -O1, no
bogus failure is being reported. With -O2 or -O3, a lot of things
seemed to be inlined in the function, and the disassembly of the
generated code did not make sense to me.

select from I_S

Problem:
========
When applier thread tries to access 'variable_name' of
INFORMATION_SCHEMA.SESSION_VARIABLES table through triggers, it results in an
abnormal exit of slave server.

Analysis:
========
At the time of replication of stored routines and triggers, their associated
security context will be sent by the master. The applier thread on the slave
server will use this information to set the required security context for the
execution of stored routines and triggers. This is achieved as follows.

->The stored routine object has a member named 'm_security_ctx' which holds the
  security context received from master.
->The applier thread's security_ctx is stored into a 'backup' object.

->Set the applier thread's security_ctx to 'm_security_ctx'.

->Upon the completion of stored routine execution restore the original security
  context of applier thread from the backup.

During the above process the 'm_security_ctx' object is not initialized
properly. Hence the 'external_user' of 'm_security_ctx' has invalid value for
this variable and accessing this variable results in abnormal exit of server.

Fix:
===
Invoke the Security_context::init() call from the constructor of stored routine
so that 'm_security_ctx' gets initialized properly.

Item_cond::eval_not_null_tables(): Use Item::eval_const_cond(),
just like Item_cond::fix_fields().

This inconsistency was found while merging to 10.3, where the
Microsoft compiler is configured to report an error for comparing
longlong to bool.

Before MDEV-12113 (MariaDB Server 10.1.25), on shutdown InnoDB would write
the current LSN to the first page of each file of the system tablespace.
This is incompatible with MariaDB's InnoDB table encryption, because
encryption repurposed the field for an encryption key ID and checksum.

buf_page_is_corrupted(): For the InnoDB system tablespace, skip
FIL_PAGE_FILE_FLUSH_LSN when checking if a page is all zero,
because the first page of each file in the system tablespace can
contain nonzero bytes in the field.

By applying 7bd258c4.

unfortunately, the year 2038 problem prevented me from pushing
the deadline even further into the future.

The 'bitmap_dir' has to be closed when no longer needed

Simulate slow statements only for COM_QUERY and COM_STMT_EXECUTE commands,
to exclude mysqld_stmt_prepare() and mysqld_stmt_close() entries from the log,
as they are not relevant for log_slow_debug.test. This simplifies the test.

Fixed issue in logic.

The file will be closed on line 540

swap two lines

Corrected one more "refering" typo.

Tests for MDEV-18892 failed, because of extra 'Prepare' and 'Close stmt'
entries in the output.

Filtering out PS related entries (where it is necessary).

Adding an intermediate volatile variable to avoid using co-processor registers
on some platforms (e.g. 32-bit x86).
This change makes test results stable accross all platforms.

Idea is that many users do not install galera library and do not want
to unnecessary run galera and wsrep suites. Furthermore, failures on
these suites disturb development as buildbot shows red failing column
and causes unnecessary work for those who do not care galera tests.
There will be other way to run these suites on buildbot.