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.

When there is a huge transaction in the undo log, the purge threads
may get stuck in trx_purge_attach_undo_recs() for a long time,
causing the server to hang on a normal shutdown (innodb_fast_shutdown>0).

Apparently the innodb_purge_batch_size does not work correctly, or the
n_pages_handled is not being incremented correctly. We do not fix that
for now, but we will instead check if shutdown has been initiated,
allowing the purge threads to shut down without delays.