Test uses a popen module that starts tarantool process in background mode. Tarantool process started in background mode forks a new process and closes a parent, after that popen loses a PID of the started process and `ph:kill()` and `ph:terminate()` doesn't work anymore. It leads to non-terminated tarantool processes after running the test. Patch fixes that by running `kill` using os.execute with a PID of tarantool process written to a pid file. Follows up #6128 NO_CHANGELOG=fix test NO_DOC=fix test

The created packages can be found in the job artifacts. NO_DOC=ci NO_TEST=ci NO_CHANGELOG=ci Co-authored-by: Yaroslav Lobankov <y.lobankov@tarantool.org>

This target is a wrapper on the command to build DEB and RPM packages with a statically compiled Tarantool binary inside. It just runs the `./static-build/make_packages.sh` script with the properly defined VERSION env variable. Example of usage: $ make -f .pack.mk package-static NO_DOC=make NO_TEST=make NO_CHANGELOG=make

This patch adds facility to make DEB and RPM packages with a statically compiled Tarantool binary inside. The build is performed in a Docker container, using PackPack docker image (centos-7) and CPack. The packpack/packpack:centos-7 image has all the necessary dependencies for building Tarantool and quite old glibc 2.17 which theoretically provides compatibility of the created packages with any distro where glibc >= 2.17. The build can be run with the command below: $ VERSION=3.0.0 ./static-build/make_packages.sh In the `static_build` directory, there will be the following packages: tarantool_3.0.0-1_amd64.deb tarantool-dev_3.0.0-1_amd64.deb tarantool-3.0.0-1.x86_64.rpm tarantool-devel-3.0.0-1.x86_64.rpm `tarantool_3.0.0-1_amd64.deb`, `tarantool-3.0.0-1.x86_64.rpm` are packages with the Tarantool server binary inside. `tarantool-dev_3.0.0-1_amd64.deb`, `tarantool-devel-3.0.0-1.x86_64.rpm` are packages with the Tarantool server development files inside. NO_DOC=build NO_TEST=build Co-authored-by: Yaroslav Lobankov <y.lobankov@tarantool.org>

Introduce `box.tuple.format` object, a Lua wrapper around tuple format: these objects own a tuple format, which is almost equivalent to `space:format`, except for check constraints and foreign key constraints being disabled (though they appear to be present for compatibility with `space:format`). Add an option table argument to `box.tuple.new` with 'format' option, allowing to create formatted spaceless tuples. Closes #4693 @TarantoolBot document Title: Formats for standalone tuples and `box_tuple_new_vararg` compat opt A new box.tuple.format library was added, with a tuple format constructor (`new`) and a tuple format validator (`is`). New tuple format objects (userdata) were added, which can be used with the same format clause as for the `space:format` method (except that check constraints and foreign keys are disabled for them): NO_WRAP ```lua f = box.tuple.format.new(box.space._space:format()) f = box.tuple.format.new{{name = 'field1', type = 'string', is_nullable = true, nullable_action = 'none', collation = 'unicode_uk_s2', default = 'UPPER("string")', constraint = {ck = 'box.schema.user.info'}, foreign_key = {fk = {space = '_space', field = 'name'}}}, {name = 'field2', nullable_action = 'ignore', foreign_key = {fk = {space = '_space', field = 1}}}} ``` NO_WRAP Format objects have several introspection methods: `:pairs`, `:ipairs`, `totable`, and also have a `__serialize` metamethod — these methods return the original (i.e., user-provided) format clause. `:pairs` is an alias to `ipairs` (since the format clause is an array by nature), and the `totable` method is an alias to the `__serialize` metamethod, which returns an array of field definitions. Format objects also have a `:tostring` method, which simply returns a "box.tuple.format" literal. The standalone tuple constructor, `box.tuple.new` was extended with an options parameter which currently has one available option, `format` (default value is `nil`, i.e., no format). The format option is either a tuple format object previously created using `box.tuple.format.new` or a format clause. Examples of standalone tuple creation with formats: NO_WRAP ```lua box.tuple.new({1}, {format = {{name = 'field', type = 'number'}}}) box.tuple.new({1}, {format = {{'field', type = 'number'}}}) box.tuple.new({1}, {format = {{'field', 'number'}}}) f = box.tuple.format.new({{name = 'field', type = 'number'}}) box.tuple.new({}, {format = f}) box.tuple.new({1}, {format = f}) box.tuple.new({'str'}, {format = f}) -- error: Tuple field 1 (field) type does not match one required by operation: expected number, got string box.tuple.new({'str'}, {format = f}) ``` NO_WRAP See also the design document https://www.notion.so/tarantool/Schemafull-IPROTO-cc315ad6bdd641dea66ad854992d8cbf?pvs=4#a33e2d7418d249679969e5f21ef2832c A new `box_tuple_new_vararg` compatibility option was introduced: a new page needs to be created for it (https://tarantool.io/compat/box_tuple_new_vararg) This option controls whether `box.tuple.new` should interpret an argument list as an array of tuple fields (i.e., vararg, old behaviour), or as a value plus a tuple format (new default behaviour). The value can be either a scalar, an array or a box tuple. The old behaviour does not allow creating formatted standalone tuples. Old behaviour examples: ```lua box.tuple.new(1) box.tuple.new{1} box.tuple.new(1, 2, 3) box.tuple.new{1, 2, 3} -- This won't create a formatted tuple: the format option will become the -- second tuple field. box.tuple.new({1, 2, 3}, {format = box.tuple.format.new{{'field'}}}) ``` New behaviour examples: ```lua box.tuple.new(1) box.tuple.new(1, {format = box.tuple.format.new{{'field'}}}) box.tuple.new{1} box.tuple.new({1}, {format = box.tuple.format.new{{'field'}}}) box.tuple.new(1, 2, 3) -- error box.tuple.new(1, 2, 3, {format = box.tuple.format.new{{'field'}}}) -- error box.tuple.new{1, 2, 3} box.tuple.new({1, 2, 3}, {format = box.tuple.format.new{{'field'}}}) ``` See also the design document https://www.notion.so/tarantool/Schemafull-IPROTO-cc315ad6bdd641dea66ad854992d8cbf?pvs=4#6f74f0c70005463b8438830edd1a0117.