testlog.txt

testlog.txt (text/plain; charset=utf-8), 111.23 KB, created by Jonathan Lovelace on 2023-11-04 02:13:40 UTC

Log of Meson test suite run on 2023-11-03T21:40:19.731423

Inherited environment: SANDBOX_MESSAGE_P@TH=/proc/4/fd/2 SLOT=0 SHELL=/bin/bash RUBY_TARGETS='' CFLAGS_x32=-mx32 PORTAGE_INST_UID=0 KERNEL_ABI=amd64 PORTAGE_PYTHONPATH=/usr/lib/python3.11/site-packages QEMU_SOFTMMU_TARGETS='' PORTAGE_FEATURES='assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live candy collision-protect config-protect-if-modified distcc distlocks ebuild-locks fakeroot fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict strict-keepdir test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync warn-on-large-env xattr' COLORTERM=truecolor __E_EXEDESTTREE='' ac_cv_c_undeclared_builtin_options='none needed' ESYSROOT='' XDG_CONFIG_DIRS=/etc/xdg:/usr/share LESS='-R -M --shift 5' SUDO_GID=1000 HISTCONTROL=erasedups ROOTPATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/16/bin:/usr/lib/llvm/15/bin CFLAGS_x86='-m32 -mfpmath=sse' JDK_HOME=/etc/java-config-2/current-system-vm USE_EXPAND_VALUES_KERNEL='Darwin linux SunOS' PORTAGE_PYTHON=/usr/bin/python3.11 PYTHON_SINGLE_TARGET='' __E_DOCDESTTREE='' PROFILE_ONLY_VARIABLES='ARCH ELIBC IUSE_IMPLICIT KERNEL USE_EXPAND_IMPLICIT USE_EXPAND_UNPREFIXED USE_EXPAND_VALUES_ARCH USE_EXPAND_VALUES_ELIBC USE_EXPAND_VALUES_KERNEL' DISTCC_VERBOSE=0 SYMLINK_LIB=no PKG_CONFIG_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/temp/python3.11/pkgconfig SANDBOX_ACTIVE=armedandready USERLAND=GNU CPU_FLAGS_X86='' PKG_TMPDIR=/var/tmp/portage/._unmerge_ LUA_TARGETS='' LDFLAGS_x86='-m elf_i386' MULTILIB_STRICT_DIRS='/lib32 /lib /usr/lib32 /usr/lib /usr/kde/*/lib32 /usr/kde/*/lib /usr/qt/*/lib32 /usr/qt/*/lib /usr/X11R6/lib32 /usr/X11R6/lib' PKGUSE='' LC_ADDRESS=en_US.UTF-8 JAVA_HOME=/etc/java-config-2/current-system-vm TWISTED_DISABLE_WRITING_OF_PLUGIN_CACHE=1 SANDBOX_ON=1 LC_NAME=en_US.UTF-8 IUSE_EFFECTIVE='abi_x86_64 alpha amd64 amd64-linux arm arm64 arm64-macos elibc_Darwin elibc_SunOS elibc_bionic elibc_glibc elibc_mingw elibc_musl elogind hppa ia64 kernel_Darwin kernel_SunOS kernel_linux loong m68k mips ppc ppc-macos ppc64 ppc64-linux prefix prefix-guest prefix-stack riscv s390 sparc systemd test x64-macos x64-solaris x86 x86-linux' BINPKG_FORMAT=xpak EPREFIX='' EBUILD_PHASE_FUNC=src_test CAMERAS='' EPYTHON=python3.11 CURL_SSL='' PORTAGE_IPC_DAEMON=1 EBUILD_PHASE=test IUSE_IMPLICIT='abi_x86_64 prefix prefix-guest prefix-stack' DISTCC_DIR=/var/tmp/.distcc ANT_HOME=/usr/share/ant AMDGPU_TARGETS='' SUDO_COMMAND=/bin/bash PORTAGE_SIGPIPE_STATUS=141 OFFICE_IMPLEMENTATION='' LC_MONETARY=en_US.UTF-8 CBUILD=x86_64-pc-linux-gnu LDFLAGS_amd64='-m elf_x86_64' SUDO_USER=kingjon BINPKG_GPG_VERIFY_BASE_COMMAND='/usr/bin/gpg --verify --batch --no-tty --no-auto-check-trustdb --status-fd 2 [PORTAGE_CONFIG] [SIGNATURE]' DEFAULT_ABI=amd64 GHC_LIBRARY_WAYS='v p dyn' ALSA_CARDS='' ABI_S390='' KERNEL=linux FFLAGS='-O2 -pipe -march=core2 -mtune=generic -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer' EDITOR=/usr/bin/vi ED=/var/tmp/portage/dev-libs/libei-1.1.0/image MULTILIB_STRICT_DENY='64-bit.*shared object' PORTAGE_ARCHLIST='alpha amd64 amd64-linux arm arm-linux arm64 arm64-linux arm64-macos hppa ia64 loong m68k mips ppc ppc-macos ppc64 ppc64-linux riscv riscv-linux s390 sparc x64-macos x64-solaris x86 x86-linux' EBUILD=/usr/portage/dev-libs/libei/libei-1.1.0.ebuild INHERITED=' multiprocessing ninja-utils toolchain-funcs multilib python-utils-r1 meson python-any-r1' OPENMPI_RM='' ADA_TARGET='' EBUILD_MASTER_PID=21 PORTAGE_REPO_NAME=gentoo PWD=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0 PORTAGE_RESTRICT='' PORTAGE_DOCOMPRESS_SIZE_LIMIT=128 LOGNAME=portage EXEOPTIONS=-m0755 DISTCC_SOCKS_PROXY=/var/tmp/portage/.portage.6210.net.sock CTARGET_default=x86_64-pc-linux-gnu DEFINED_PHASES=' compile configure install prepare setup test unpack' LIBDIR_amd64=lib64 DISTCC_TCP_CORK='' SANDBOX_VERBOSE=1 PORTAGE_WORKDIR_MODE=0750 CHECKREQS_ACTION=error PKGDIR=/usr/portage/packages FILESDIR=/var/tmp/portage/dev-libs/libei-1.1.0/files DIROPTIONS=-m0755 MAKEOPTS='-j3 -l4' PORTAGE_CONFIGROOT=/ ENV_UNSET='CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME' PM_EBUILD_HOOK_DIR=/etc/portage/env CXXFLAGS='-O2 -pipe -march=core2 -mtune=generic -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer' PORTAGE_OVERRIDE_EPREFIX='' T=/var/tmp/portage/dev-libs/libei-1.1.0/temp S=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0 P=libei-1.1.0 UNCACHED_ERR_FD='' PAX_MARKINGS=none D=/var/tmp/portage/dev-libs/libei-1.1.0/image A='libei-1.1.0.tar.bz2 munit-fbbdf1467eb0d04a6ee465def2e529e4c87f2118.tar.gz' CATEGORY=dev-libs LDFLAGS_x32='-m elf32_x86_64' LD_PRELOAD=libsandbox.so PYTHON_TARGETS='' CALLIGRA_FEATURES='' LDFLAGS='-Wl,-O1 -Wl,--as-needed' HOME=/var/tmp/portage/dev-libs/libei-1.1.0/homedir LIBREOFFICE_EXTENSIONS='' SSH_ASKPASS=/usr/bin/lxqt-openssh-askpass LANG=en_US.UTF-8 LC_PAPER=en_US.UTF-8 CFLAGS_amd64=-m64 WORKDIR=/var/tmp/portage/dev-libs/libei-1.1.0/work QEMU_USER_TARGETS='' LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=01;05;37;41:mi=01;05;37;41:su=37;41:sg=30;43:ca=00:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.zst=01;31:*.tzst=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.wim=01;31:*.swm=01;31:*.dwm=01;31:*.esd=01;31:*.avif=01;35:*.jpg=01;35:*.jpeg=01;35:*.mjpg=01;35:*.mjpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.webp=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.ogv=01;35:*.ogx=01;35:*.cfg=00;32:*.conf=00;32:*.diff=00;32:*.doc=00;32:*.ini=00;32:*.log=00;32:*.patch=00;32:*.pdf=00;32:*.ps=00;32:*.tex=00;32:*.txt=00;32:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.oga=00;36:*.opus=00;36:*.spx=00;36:*.xspf=00;36:*~=00;90:*#=00;90:*.bak=00;90:*.old=00;90:*.orig=00;90:*.part=00;90:*.rej=00;90:*.swp=00;90:*.tmp=00;90:*.dpkg-dist=00;90:*.dpkg-old=00;90:*.ucf-dist=00;90:*.ucf-new=00;90:*.ucf-old=00;90:*.rpmnew=00;90:*.rpmorig=00;90:*.rpmsave=00;90:' XDG_CURRENT_DESKTOP=MATE INSOPTIONS=-m0644 SANDBOX_LIB=libsandbox.so UWSGI_PLUGINS='' COLUMNS=176 CHOST_x86=i686-pc-linux-gnu BROOT='' PORTAGE_TMPDIR=/var/tmp LINGUAS='en en_US' PORTAGE_COLORMAP='PORTAGE_COLOR_BAD=$'"'"'[31;01m'"'"'
PORTAGE_COLOR_BRACKET=$'"'"'[34;01m'"'"'
PORTAGE_COLOR_ERR=$'"'"'[31;01m'"'"'
PORTAGE_COLOR_GOOD=$'"'"'[32;01m'"'"'
PORTAGE_COLOR_HILITE=$'"'"'[36m'"'"'
PORTAGE_COLOR_INFO=$'"'"'[32m'"'"'
PORTAGE_COLOR_LOG=$'"'"'[32;01m'"'"'
PORTAGE_COLOR_NORMAL=$'"'"'[0m'"'"'
PORTAGE_COLOR_QAWARN=$'"'"'[33m'"'"'
PORTAGE_COLOR_WARN=$'"'"'[33;01m'"'"'' SANDBOX_READ=/:/var/tmp/portage LCD_DEVICES='' BINPKG_GPG_VERIFY_GPG_HOME=/etc/portage/gnupg GCPAN_OVERLAY=/usr/local/portage FEATURES='assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live candy collision-protect config-protect-if-modified distcc distlocks ebuild-locks fakeroot fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch parallel-install pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict strict-keepdir test unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync warn-on-large-env xattr' NETBEANS_MODULES='harness ide java nb javafx profile' TMPDIR=/var/tmp/portage/dev-libs/libei-1.1.0/temp OPENGL_PROFILE=xorg-x11 PORTAGE_BIN_PATH=/usr/lib/portage/python3.11 CPU_FLAGS_PPC='' SANDBOX_METHOD=any DISTCC_FALLBACK=1 OPENMPI_OFED_FEATURES='' DCC_EMAILLOG_WHOM_TO_BLAME='' JAVACC_HOME=/usr/share/javacc/ PORTAGE_INTERNAL_CALLER=1 PORTAGE_COMPRESSION_COMMAND=bzip2 QT_GRAPHICSSYSTEM=raster PVR=1.1.0 PORTAGE_VERBOSE=1 PKG_LOGDIR=/var/tmp/portage/dev-libs/libei-1.1.0/temp/logging READELF=x86_64-pc-linux-gnu-readelf CPU_FLAGS_ARM='' KEYWORDS='~amd64 ~arm ~arm64 ~hppa ~loong ~riscv ~x86' PORTAGE_COMPRESS_EXCLUDE_SUFFIXES='css gif htm[l]? jp[e]?g js pdf png' PORTAGE_BUILD_USER=portage OPENMPI_FABRICS='' NGINX_MODULES_MAIL='' USE_EXPAND_UNPREFIXED=ARCH PORT_LOGDIR=/var/log/portage MOPREFIX=libei CHOST_amd64=x86_64-pc-linux-gnu MOZ_GMP_PATH=/usr/lib64/nsbrowser/plugins/gmp-gmpopenh264/system-installed FFTOOLS='' LLVM_TARGETS='' FETCHCOMMAND_SSH='bash -c "x=\${2#ssh://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; exec rsync --rsh=\"ssh \${port:+-p\${port}} \${3}\" -avP \"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}"' JAVAC=/etc/java-config-2/current-system-vm/bin/javac PORTAGE_PYM_PATH=/usr/lib/python3.11/site-packages FCFLAGS='-O2 -pipe -march=core2 -mtune=generic -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer' ANDROID_HOME=/opt/android-sdk-update-manager STUDIO_JDK=/opt/android-studio/jbr MULTILIB_STRICT_EXEMPT='(perl5|gcc|binutils|eclipse-3|debug|portage|udev|systemd|clang|python-exec|llvm)' LUA_SINGLE_TARGET='' TERM=screen.xterm-256color LC_IDENTIFICATION=en_US.UTF-8 BOOTSTRAP_USE='unicode internal-glib pkg-config split-usr xml python_targets_python3_11 python_single_target_python3_11 multilib hardened pic xtpax -jit -orc' EROOT='' LESSOPEN='|lesspipe %s' ANDROID_SWT=/usr/share/swt-3.7/lib EVCS_UMASK=002 PORTAGE_XATTR_EXCLUDE='btrfs.* security.evm security.ima 	security.selinux system.nfs4_acl user.apache_handler 	user.Beagle.* user.dublincore.* user.mime_encoding user.xdg.*' PORTAGE_LOG_FILE=/var/log/portage/dev-libs:libei-1.1.0:20231104-013952.log NOCOLOR=no PYTHON=/usr/bin/python3.11 PORTAGE_PROPERTIES='' SANDBOX_DEBUG=0 PORTAGE_DEPCACHEDIR=/var/cache/edb/dep L10N='' ARCH=amd64 NGINX_MODULES_HTTP='' MANPAGER=manpager VISUAL=/usr/bin/vi ROOT='' VIDEO_CARDS='' ROS_MESSAGES='' ABI_X86=64 TEMP=/var/tmp/portage/dev-libs/libei-1.1.0/temp BINPKG_GPG_SIGNING_DIGEST=SHA512 USE_EXPAND_VALUES_ARCH='alpha amd64 amd64-linux arm arm64 arm64-macos hppa ia64 loong m68k mips ppc ppc64 ppc64-linux ppc-macos riscv s390 sparc x64-macos x64-solaris x86 x86-linux' LIBDIR_x32=libx32 NPM_CONFIG_GLOBALCONFIG=/etc/npm/npmrc INPUT_DEVICES='' GPG_VERIFY_USER_DROP=nobody SHLVL=1 DISTCC_SAVE_TEMPS=0 DISTDIR=/var/tmp/portage/dev-libs/libei-1.1.0/distdir NM=x86_64-pc-linux-gnu-nm enable_year2038=no PORTAGE_REPOSITORIES='[DEFAULT]
auto-sync = yes
main-repo = gentoo
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
volatile = true

[calculate]
auto-sync = yes
location = /var/lib/layman/calculate
masters = gentoo
priority = 50
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
sync-type = git
sync-uri = https://github.com/gentoo-mirror/calculate.git
volatile = true

[gentoo]
auto-sync = yes
location = /usr/portage
masters = 
priority = -1000
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-path = /usr/share/openpgp-keys/gentoo-release.asc
sync-openpgp-key-refresh = true
sync-openpgp-key-refresh-retry-count = 40
sync-openpgp-key-refresh-retry-delay-exp-base = 2
sync-openpgp-key-refresh-retry-delay-max = 60
sync-openpgp-key-refresh-retry-delay-mult = 4
sync-openpgp-key-refresh-retry-overall-timeout = 1200
sync-openpgp-keyserver = hkps://keys.gentoo.org
sync-rcu = false
sync-type = webrsync
sync-uri = tar+https://mirrors.rit.edu/gentoo/snapshots/portage-latest.tar.xz
volatile = true
sync-webrsync-verify-signature = true

[localoverlay]
auto-sync = yes
location = /usr/local/portage
masters = gentoo lovelace
priority = 0
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
volatile = true

[lovelace]
auto-sync = yes
location = /var/lib/layman/lovelace
masters = gentoo
priority = 50
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
sync-type = git
sync-uri = https://github.com/kingjon3377/lovelace-overlay.git
volatile = true

[menelkir]
auto-sync = yes
location = /var/lib/layman/menelkir
masters = gentoo
priority = 50
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
sync-type = git
sync-uri = https://gitlab.com/menelkir/gentoo-overlay.git
volatile = true

[steam-overlay]
auto-sync = yes
location = /var/lib/layman/steam-overlay
masters = gentoo
priority = 50
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
sync-type = git
sync-uri = https://github.com/anyc/steam-overlay.git
volatile = true

[t2]
auto-sync = yes
location = /var/db/repos/t2
masters = gentoo
strict-misc-digests = true
sync-allow-hardlinks = true
sync-openpgp-key-refresh = true
sync-rcu = false
sync-type = git
sync-uri = https://codeberg.org/vimproved/t2-overlay.git
volatile = false
' APACHE2_MPMS='' PAGER=/usr/bin/less LC_TELEPHONE=en_US.UTF-8 LEX=flex SANDBOX_WRITE=:/dev/console:/dev/fd:/dev/full:/dev/null:/dev/ptmx:/dev/pts/:/dev/pty:/dev/shm:/dev/tts:/dev/tty:/dev/vc/:/dev/zero:/proc/self/fd:/tmp/:/usr/lib/cf:/usr/lib/conftest:/usr/lib32/cf:/usr/lib32/conftest:/usr/lib64/cf:/usr/lib64/conftest:/usr/tmp/:/usr/tmp/cf:/usr/tmp/conftest:/var/tmp/:/var/tmp/.distcc:/var/tmp/portage:/var/tmp/portage/dev-libs/libei-1.1.0/homedir/.bash_history PROFILE_IS_HARDENED=1 CHOST_default=x86_64-pc-linux-gnu DISTCC_SSH='' GPSD_PROTOCOLS='' __E_DESTTREE=/usr LC_MESSAGES=en_US.UTF-8 LC_MEASUREMENT=en_US.UTF-8 XTABLES_ADDONS='' SBCL_HOME=/usr/lib64/sbcl LICENSE=MIT PYTHONDONTWRITEBYTECODE=1 SYSROOT='' VOICEMAIL_STORAGE='' PV=1.1.0 RESUMECOMMAND_SSH='bash -c "x=\${2#ssh://} ; host=\${x%%/*} ; port=\${host##*:} ; host=\${host%:*} ; [[ \${host} = \${port} ]] && port= ; exec rsync --rsh=\"ssh \${port:+-p\${port}} \${3}\" -avP \"\${host}:/\${x#*/}\" \"\$1\"" rsync "${DISTDIR}/${FILE}" "${URI}" "${PORTAGE_SSH_OPTS}"' SANDBOX_LOG=/var/tmp/portage/dev-libs/libei-1.1.0/temp/sandbox.log PR=r0 COLLECTD_PLUGINS='' PN=libei XARGS='xargs -r' __E_INSDESTTREE='' SANE_BACKENDS='' USE_EXPAND_IMPLICIT='ARCH ELIBC KERNEL' PF=libei-1.1.0 USE_EXPAND_VALUES_ELIBC='bionic Darwin glibc mingw musl SunOS' PORTAGE_BASHRC=/etc/portage/bashrc ACCEPT_LICENSE=MIT BUILD_PREFIX=/var/tmp/portage LC_CTYPE=en_US.UTF-8 MERGE_TYPE=source GCC_SPECS='' ABI_MIPS='' GSETTINGS_BACKEND=dconf PORTAGE_SOCKS5_PROXY=/var/tmp/portage/.portage.6210.net.sock PORTAGE_ACTUAL_DISTDIR=/usr/portage/distfiles CCACHE_DISABLE=1 LIBDIR_default=lib DISTCC_ENABLE_DISCREPANCY_EMAIL='' LC_TIME=en_US.UTF-8 SANDBOX_PREDICT=/var/tmp/portage/dev-libs/libei-1.1.0/homedir:/dev/crypto:/var/cache/man:/dev/random:/proc/self/coredump_filter:/dev/random:/proc/self/coredump_filter:/dev/random:/proc/self/coredump_filter:/var/cache/fontconfig:/ LIBOPTIONS=-m0644 GRUB_PLATFORMS='' GPG_VERIFY_GROUP_DROP=nogroup SANDBOX_DENY='' LC_COLLATE=C XDG_DATA_DIRS=/usr/local/share:/usr/share:/etc/eselect/wine/share CHOST=x86_64-pc-linux-gnu BINPKG_GPG_SIGNING_BASE_COMMAND='/usr/bin/flock /run/lock/portage-binpkg-gpg.lock /usr/bin/gpg --sign --armor [PORTAGE_CONFIG]' TMP=/var/tmp/portage/dev-libs/libei-1.1.0/temp PORTAGE_INST_GID=0 PATH=/var/tmp/portage/dev-libs/libei-1.1.0/temp/python3.11/bin:/usr/lib/distcc/bin:/usr/lib/portage/python3.11/ebuild-helpers/xattr:/usr/lib/portage/python3.11/ebuild-helpers:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/usr/lib/llvm/16/bin:/usr/lib/llvm/15/bin:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/etc/eselect/wine/bin SANDBOX_DEBUG_LOG=/var/log/sandbox/sandbox-debug-4.log PORTAGE_BZIP2_COMMAND=bzip2 PORTAGE_BUILDDIR=/var/tmp/portage/dev-libs/libei-1.1.0 CHOST_x32=x86_64-pc-linux-gnux32 NGINX_MODULES_STREAM='' USE='abi_x86_64 amd64 elibc_glibc kernel_linux test' PHP_TARGETS='' POSTGRES_TARGETS='' CFLAGS='-O2 -pipe -march=core2 -mtune=generic -fno-unwind-tables -fno-asynchronous-unwind-tables -fomit-frame-pointer' USE_EXPAND='ABI_MIPS ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS AMDGPU_TARGETS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XTABLES_ADDONS' SANDBOX_BASHRC=/usr/share/sandbox/sandbox.bashrc SUDO_UID=1000 MULTILIB_ABIS='amd64 x86' LV2_PATH=/usr/lib64/lv2 LIBDIR_x86=lib PORTAGE_GID=250 MAIL=/var/mail/root PORTAGE_BUILD_GROUP=portage gl_cv_compiler_check_decl_option=-Werror=implicit-function-declaration APACHE2_MODULES='' ADAFLAGS='-O2 -pipe' ELIBC=glibc EAPI=8 ABI=amd64 SBCL_SOURCE_ROOT=/usr/lib64/sbcl/src ECLASS_DEPTH=0 PORTAGE_BASHRC_FILES=/usr/portage/profiles/default/linux/amd64/17.1/profile.bashrc LC_NUMERIC=en_US.UTF-8 OLDPWD=/var/tmp/portage/dev-libs/libei-1.1.0/empty MONKEYD_PLUGINS='' EMERGE_FROM=ebuild _=/usr/bin/meson 

==================================== 1/10 ====================================
test:         libei / dtdcheck
start time:   01:40:19
duration:     0.02s
result:       exit status 0
command:      MALLOC_PERTURB_=251 /usr/bin/xmllint --dtdvalid /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0/proto/protocol.dtd /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0/proto/protocol.xml
----------------------------------- stdout -----------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<protocol name="ei">

  <copyright>
    Copyright © 2008-2011 Kristian Høgsberg
    Copyright © 2010-2011 Intel Corporation
    Copyright © 2012-2013 Collabora, Ltd.
    Copyright © 2023 Red Hat, Inc.

    Permission is hereby granted, free of charge, to any person
    obtaining a copy of this software and associated documentation files
    (the "Software"), to deal in the Software without restriction,
    including without limitation the rights to use, copy, modify, merge,
    publish, distribute, sublicense, and/or sell copies of the Software,
    and to permit persons to whom the Software is furnished to do so,
    subject to the following conditions:

    The above copyright notice and this permission notice (including the
    next paragraph) shall be included in all copies or substantial
    portions of the Software.

    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
    NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
    BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
    ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
    CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
    SOFTWARE.
  </copyright>

  <interface name="ei_handshake" version="1">
    <description summary="handshake object">
      This is a special interface to setup the client as seen by the EIS
      implementation. The object for this interface has the fixed object
      id 0 and only exists until the connection has been set up, see the
      ei_handshake.connection event.

      The ei_handshake version is 1 until:
      - the EIS implementation sends the interface_version event with
        a version other than 1, and, in response,
      - the client sends the interface_version request with a
        version equal or lower to the EIS implementation version.

      The EIS implementation must send the interface_version event immediately
      once the physical connection has been established.

      Once the ei_connection.connection event has been sent the handshake
      is destroyed by the EIS implementation.
    </description>

    <!-- ei_handshake client requests version 1 -->

    <request name="handshake_version" since="1">
      <description summary="handshake version notification request">
        Notifies the EIS implementation that this client supports the
        given version of the ei_handshake interface. The version number
        must be less than or equal to the version in the
        handshake_version event sent by the EIS implementation when
        the connection was established.

        Immediately after sending this request, the client must assume the negotiated
        version number for the ei_handshake interface and the EIS implementation
        may send events and process requests matching that version.

        This request must be sent exactly once and it must be the first request
        the client sends.
      </description>
      <arg name="version" type="uint32" summary="the interface version"/>
    </request>

    <request name="finish" since="1">
      <description summary="setup completion request">
        Notify the EIS implementation that configuration is complete.

        In the future (and possibly after requiring user interaction),
        the EIS implementation responds by sending the ei_handshake.connection event.
      </description>
    </request>

    <enum name="context_type" since="1">
      <description summary="context type">
        This enum denotes context types for the libei context.

        A context type of receiver is a libei context receiving events
        from the EIS implementation. A context type of sender is a libei context
        sending events to the EIS implementation.
      </description>
      <entry name="receiver" value="1" summary="this client receives events from the EIS implementation"/>
      <entry name="sender" value="2" summary="this client sends events to the EIS implementation"/>
    </enum>

    <request name="context_type" since="1">
      <description summary="context type request">
        Notify the EIS implementation of the type of this context. The context types
        defines whether the client will send events to or receive events from the
        EIS implementation.

        Depending on the context type, certain requests must not be used and some
        events must not be sent by the EIS implementation.

        This request is optional, the default client type is context_type.receiver.
        This request must not be sent more than once and must be sent before
        ei_handshake.finish.
      </description>
      <arg name="context_type" type="uint32" enum="context_type" summary="the client context type"/>
    </request>

    <request name="name" since="1">
      <description summary="context name request">
        Notify the EIS implementation of the client name. The name is a
        human-presentable UTF-8 string and should represent the client name
        as accurately as possible. This name may be presented to the user
        for identification of this client (e.g. to confirm the client has
        permissions to connect).

        There is no requirement for the EIS implementation to use this name. For
        example, where the client is managed through an XDG Desktop Portal an EIS
        implementation would typically use client identification information sent
        by the portal instead.

        This request is optional, the default client name is implementation-defined.
        This request must not be sent more than once and must be sent before
        ei_handshake.finish.
      </description>
      <arg name="name" type="string" summary="the client name"/>
    </request>

    <request name="interface_version" since="1">
      <description summary="interface support notification">
        Notify the EIS implementation that the client supports the
        given named interface with the given maximum version number.

        Future objects created by the EIS implementation will
        use the respective interface version (or any lesser version).

        This request must be sent for the "ei_connection" interface,
        failing to do so will result in the EIS implementation disconnecting
        the client on ei_handshake.finish.

        This request must not be sent for the "ei_handshake" interface, use
        the ei_handshake.handshake_version request instead.

        Note that an EIS implementation may consider some interfaces to
        be required and immediately ei_connection.disconnect a client
        not supporting those interfaces.

        This request must not be sent more than once per interface and must be
        sent before ei_handshake.finish.
      </description>
      <arg name="name" type="string" summary="the interface name"/>
      <arg name="version" type="uint32" summary="the interface version"/>
    </request>

    <!-- ei_handshake events version 1 -->
    <event name="handshake_version" since="1">
      <description summary="handshake version notification event">
        This event is sent exactly once and immediately after connection
        to the EIS implementation.

        In response, the client must send the ei_handshake.handshake_version request
        with any version up to including the version provided in this event.
        See the ei_handshake.handshake_version request for details on what happens next.
      </description>
      <arg name="version" type="uint32" summary="the interface version"/>
    </event>

    <event name="interface_version" since="1">
      <description summary="interface support event">
        Notifies the client that the EIS implementation supports
        the given named interface with the given maximum version number.

        This event must be sent by the EIS implementation for any
        interfaces that supports client-created objects (e.g. "ei_callback")
        before the ei_handshake.connection event.
        The client must not assume those interfaces are supported unless
        and until those versions have been received.

        This request must not be sent for the "ei_handshake" interface, use
        the handshake_version event instead.

        This event may be sent by the EIS implementation for any
        other supported interface (but not necessarily all supported
        interfaces) before the ei_handshake.connection event.
      </description>
      <arg name="name" type="string" summary="the interface name"/>
      <arg name="version" type="uint32" summary="the interface version"/>
    </event>

    <event name="connection" type="destructor" since="1">
      <description summary="the core connection object">
        Provides the client with the connection object that is the top-level
        object for all future requests and events.

        This event is sent exactly once at some unspecified time after the client
        sends the ei_handshake.finish request to the EIS implementation.

        The ei_handshake object will be destroyed by the
        EIS implementation immediately after this event has been sent, a
        client must not attempt to use it after that point.

        The version sent by the EIS implementation is the version of the "ei_connection"
        interface as announced by ei_handshake.interface_version, or any
        lower version.

        The serial number is the start value of the EIS implementation's serial
        number sequence. Clients must not assume any specific value for this
        serial number. Any future serial number in any event is monotonically
        increasing by an unspecified amount.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
      <arg name="connection" type="new_id" interface="ei_connection" summary="the connection object"/>
      <arg name="version" type="uint32" summary="the version of the connection object"/>
    </event>
  </interface>

  <interface name="ei_connection" version="1">
    <description summary="core global object">
      The core connection object. This is the top-level object for any communication
      with the EIS implementation.

      Note that for a client to receive this object, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_connection client requests version 1 -->

    <request name="sync" since="1">
      <description summary="asynchronous roundtrip">
        The sync request asks the EIS implementation to emit the 'done' event
        on the returned ei_callback object. Since requests are
        handled in-order and events are delivered in-order, this can
        be used as a synchronization point to ensure all previous requests and the
        resulting events have been handled.

        The object returned by this request will be destroyed by the
        EIS implementation after the callback is fired and as such the client must not
        attempt to use it after that point.

        The callback_data in the ei_callback.done event is always zero.

        Note that for a client to use this request it must announce
        support for the "ei_callback" interface in ei_handshake.interface_version.
        It is a protocol violation to request sync without having announced the
        "ei_callback" interface and the EIS implementation must disconnect
        the client.
      </description>
      <arg name="callback" type="new_id" interface="ei_callback" summary="callback object for the sync request"/>
      <arg name="version" type="uint32" summary="the interface version"/>
    </request>

    <request name="disconnect" type="destructor" since="1">
      <description summary="disconnection request">
        A request to the EIS implementation that this client should be disconnected.
        This is a courtesy request to allow the EIS implementation to distinquish
        between a client disconnecting on purpose and one disconnecting through the
        socket becoming invalid.

        Immediately after sending this request, the client may destroy the
        ei_connection object and it should close the socket. The EIS implementation
        will treat the connection as already disconnected on receipt and does not
        send the ei_connection.disconnect event in response to this request.
      </description>
    </request>

    <!-- ei_connection events version 1 -->

    <enum name="disconnect_reason" since="1">
      <description summary="disconnection reason">
        A reason why a client was disconnected. This enum is intended to
        provide information to the client on whether it was disconnected as
        part of normal operations or as result of an error on either the client
        or EIS implementation side.

        A nonzero value describes an error, with the generic value "error" (1) reserved
        as fallback.

        This enum may be extended in the future, clients must be able to handle
        values that are not in their supported version of this enum.
      </description>
      <entry name="disconnected" value="0" summary="client was purposely disconnected"/>
      <entry name="error" value="1" summary="an error caused the disconnection"/>
      <entry name="mode" value="2" summary="sender/receiver client sent request for receiver/sender mode"/>
      <entry name="protocol" value="3" summary="client committed a protocol violation"/>
      <entry name="value" value="4" summary="client sent an invalid value"/>
      <entry name="transport" value="5" summary="error on the transport layer"/>
    </enum>

    <event name="disconnected" type="destructor" since="1">
      <description summary="disconnection event">
        This event may be sent by the EIS implementation immediately before
        the client is disconnected. The last_serial argument is set to the last
        serial number used in a request by the client or zero if the client has not
        yet issued a request.

        Where a client is disconnected by EIS on purpose, for example after
        a user interaction, the reason is disconnect_reason.disconnected (i.e. zero)
        and the explanation is NULL.

        Where a client is disconnected due to some invalid request or other
        protocol error, the reason is one of disconnect_reason (i.e. nonzero) and
        explanation may contain a string explaining why. This string is
        intended to help debugging only and is not guaranteed to stay constant.

        The ei_connection object will be destroyed by the
        EIS implementation immediately after this event has been sent, a
        client must not attempt to use it after that point.

        There is no guarantee this event is sent - the connection may be closed
        without a disconnection event.
      </description>
      <arg name="last_serial" type="uint32" summary="the last serial sent by the EIS implementation"/>
      <arg name="reason" type="uint32" enum="disconnect_reason" summary="the reason for being disconnected"/>
      <arg name="explanation" type="string" summary="an explanation for debugging purposes"/>
    </event>

    <event name="seat" since="1">
      <description summary="Seat presence notification">
        Notification that a new seat has been added.

        A seat is a set of input devices that logically belong together.

        This event is only sent if the client announced support for the
        "ei_seat" interface in ei_handshake.interface_version.
        The interface version is equal or less to the client-supported
        version in ei_handshake.interface_version for the "ei_seat"
        interface.
      </description>
      <arg name="seat" type="new_id" interface="ei_seat"/>
      <arg name="version" type="uint32" summary="the interface version"/>
    </event>

    <event name="invalid_object" since="1">
      <description summary="Invalid object in request notification">
        Notification that an object ID used in an earlier request was
        invalid and does not exist.

        This event is sent by the EIS implementation when an object that
        does not exist as seen by the EIS implementation. The protocol is
        asynchronous and this may occur e.g. when the EIS implementation
        destroys an object at the same time as the client requests functionality
        from that object. For example, an EIS implementation may send
        ei_device.destroyed and destroy the device's resources (and protocol object)
        at the same time as the client attempts to ei_device.start_emulating
        on that object.

        It is the client's responsibilty to unwind any state changes done
        to the object since the last successful message.
      </description>
      <arg name="last_serial" type="uint32" summary="the last serial sent by the EIS implementation"/>
      <arg name="invalid_id" type="uint64"/>
    </event>

    <event name="ping" since="1">
      <description summary="ping event">
        The ping event asks the client to emit the 'done' event
        on the provided ei_callback object. Since requests are
        handled in-order and events are delivered in-order, this can
        be used as a synchronization point to ensure all previous requests
        and the resulting events have been handled.

        The object returned by this request must be destroyed by the
        ei client implementation after the callback is fired and as
        such the client must not attempt to use it after that point.

        The callback_data in the resulting ei_pingpong.done request is
        ignored by the EIS implementation.

        Note that for a EIS implementation to use this request the client must
        announce support for this interface in ei_handshake.interface_version. It is
        a protocol violation to send this event to a client without the
        "ei_pingpong" interface.
      </description>
      <arg name="ping" type="new_id" interface="ei_pingpong" summary="callback object for the ping request"/>
      <arg name="version" type="uint32" summary="the version of the callback object"/>
    </event>
  </interface>

  <interface name="ei_callback" version="1">
    <description summary="callback object">
      Interface for ensuring a roundtrip to the EIS implementation.
      Clients can handle the 'done' event to get notified when
      the related request that created the ei_callback object is done.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_callback events version 1 -->

    <event name="done" type="destructor" since="1">
      <description summary="done event">
        Notify the client when the related request is done. Immediately after this event
        the ei_callback object is destroyed by the EIS implementation and as such the
        client must not attempt to use it after that point.
      </description>
      <arg name="callback_data" type="uint64" summary="request-specific data for the callback"/>
    </event>
  </interface>

  <interface name="ei_pingpong" version="1">
    <description summary="callback object">
      Interface for ensuring a roundtrip to the client implementation.
      This interface is identical to ei_callback but is intended for
      the EIS implementation to enforce a roundtrip to the client.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_pingpong client requests version 1 -->

    <request name="done" type="destructor" since="1">
      <description summary="done event">
        Notify the EIS implementation when the related event is done. Immediately after this request
        the ei_pingpong object is destroyed by the client and as such must not be used
        any further.
      </description>
      <arg name="callback_data" type="uint64" summary="request-specific data for the callback"/>
    </request>

    <!-- ei_pingpong events version 1 -->
  </interface>

  <interface name="ei_seat" version="1">
    <description summary="seat object">
      An ei_seat represents a set of input devices that logically belong together. In most
      cases only one seat is present and all input devices on that seat share the same
      pointer and keyboard focus.

      A seat has potential capabilities, a client is expected to bind to those capabilities.
      The EIS implementation then creates logical input devices based on the capabilities the
      client is interested in.

      Immediately after creation of the ei_seat object, the EIS implementation sends a burst
      of events with information about this seat. This burst of events is terminated by the
      ei_seat.done event.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_seat client requests version 1 -->

    <request name="release" since="1">
      <description summary="Seat removal request">
        Notification that the client is no longer interested in this seat.
        The EIS implementation will release any resources related to this seat and
        send the ei_seat.destroyed event once complete.

        Note that releasing a seat does not guarantee another seat becomes available.
        In other words, in most single-seat cases, releasing the seat means the
        connection becomes effectively inert.
      </description>
    </request>

    <request name="bind" since="1">
      <description summary="Seat binding">
        Bind to the bitmask of capabilities given. The bitmask is zero or more of the
        masks representing an interface as provided in the ei_seat.capability event.
        See the ei_seat.capability event documentation for examples.

        Binding masks that are not supported in the ei_device's interface version
        is a client bug and may result in disconnection.

        A client may send this request multiple times to adjust the capabilities it
        is interested in. If previously-bound capabilities are dropped by the client,
        the EIS implementation may ei_device.remove devices that have these capabilities.
      </description>
      <arg name="capabilities" type="uint64" summary="bitmask of the capabilities"/>
    </request>

    <!-- ei_seat events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Seat removal notification">
        This seat has been removed and a client should release all
        associated resources.

        This ei_seat object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="name" since="1">
      <description summary="Seat name notification">
        The name of this seat, if any. This event is optional and sent once immediately
        after object creation.

        It is a protocol violation to send this event after the ei_seat.done event.
      </description>
      <arg name="name" type="string" summary="the seat name"/>
    </event>

    <event name="capability" since="1">
      <description summary="Seat capability notification">
        A notification that this seat supports devices with the given interface.
        The interface is mapped to a bitmask by the EIS implementation.
        A client may then binary OR these bitmasks in ei_seat.bind.
        In response, the EIS implementation may then create device based on those
        bound capabilities.

        For example, an EIS implementation may map "ei_pointer" to 0x1,
        "ei_keyboard" to 0x4 and "ei_touchscreen" to 0x8. A client may then
        ei_seat.bind(0xc) to bind to keyboard and touchscreen but not pointer.
        Note that as shown in this example the set of masks may be sparse.
        The value of the mask is contant for the lifetime of the seat but may differ
        between seats.

        Note that seat capabilities only represent a mask of possible capabilities on
        devices in this seat. A capability that is not available on the seat cannot
        ever be available on any device in this seat. For example, a seat that only has the
        pointer and keyboard capabilities can never have a device with the touchscreen
        capability. It is up to the EIS implementation to decide how many (if any) devices
        with any given capability exist in this seat.

        Only interfaces that the client announced during ei_handshake.interface_version
        can be a seat capability.

        This event is sent multiple times - once per supported interface.
        The set of capabilities is constant for the lifetime of the seat.

        It is a protocol violation to send this event after the ei_seat.done event.
      </description>
      <arg name="mask" type="uint64" summary="the mask representing this capability"/>
      <arg name="interface" type="string" summary="the interface name for this capability"/>
    </event>

    <event name="done" since="1">
      <description summary="Seat setup completion notification">
        Notification that the initial burst of events is complete and
        the client can set up this seat now.

        It is a protocol violation to send this event more than once.
      </description>
    </event>

    <event name="device" since="1">
      <description summary="Device presence notification">
        Notification that a new device has been added.

        This event is only sent if the client announced support for the
        "ei_device" interface in ei_handshake.interface_version.
        The interface version is equal or less to the client-supported
        version in ei_handshake.interface_version for the "ei_device"
        interface.
      </description>
      <arg name="device" type="new_id" interface="ei_device" summary="the new device"/>
      <arg name="version" type="uint32" summary="the interface version"/>
    </event>
  </interface>

  <interface name="ei_device" version="2">
    <description summary="device object">
      An ei_device represents a single logical input devices. Like physical input devices
      an ei_device may have multiple capabilities and may e.g. function as pointer
      and keyboard.

      Depending on the ei_handshake.context_type, an ei_device can
      emulate events via client requests or receive events. It is a protocol violation
      to emulate certain events on a receiver device, or for the EIS implementation
      to send certain events to the device. See the individual request/event documentation
      for details.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_device client requests version 1 -->

    <request name="release" since="1">
      <description summary="Device removal request">
        Notification that the client is no longer interested in this device.

        Note that releasing a device does not guarantee another device becomes available.

        The EIS implementation will release any resources related to this device and
        send the ei_device.destroyed event once complete.
      </description>
    </request>

    <request name="start_emulating" since="1" context-type="sender">
      <description summary="Device start emulating request">
        Notify the EIS implementation that the given device is about to start
        sending events. This should be seen more as a transactional boundary than a
        time-based boundary. The primary use-cases for this are to allow for setup on
        the EIS implementation side and/or UI updates to indicate that a device is
        sending events now and for out-of-band information to sync with a given event
        sequence.

        There is no actual requirement that events start immediately once emulation
        starts and there is no requirement that a client calls ei_device.stop_emulating
        after the most recent events.
        For example, in a remote desktop use-case the client would call
        ei_device.start_emulating once the remote desktop session starts (rather than when
        the device sends events) and ei_device.stop_emulating once the remote desktop
        session stops.

        The sequence number identifies this transaction between start/stop emulating.
        It must go up by at least 1 on each call to ei_device.start_emulating.
        Wraparound must be handled by the EIS implementation but callers must ensure
        that detection of wraparound is possible.

        It is a protocol violation to request ei_device.start_emulating after
        ei_device.start_emulating without an intermediate stop_emulating.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="last_serial" type="uint32" summary="the last serial sent by the EIS implementation"/>
      <arg name="sequence" type="uint32" summary="sequence number to identify this emulation sequence"/>
    </request>

    <request name="stop_emulating" since="1" context-type="sender">
      <description summary="Device start emulating request">
        Notify the EIS implementation that the given device is no longer sending
        events. See ei_device.start_emulating for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="last_serial" type="uint32" summary="the last serial sent by the EIS implementation"/>
    </request>

    <request name="frame" since="1" context-type="sender">
      <description summary="Device frame request">
        Generate a frame event to group the current set of events
        into a logical hardware event. This function must be called after one
        or more events on any of ei_pointer, ei_pointer_absolute,
        ei_scroll, ei_button, ei_keyboard or ei_touchscreen has
        been requested by the EIS implementation.

        The EIS implementation should not process changes to the device state
        until the ei_device.frame event. For example, pressing and releasing
        a key within the same frame is a logical noop.

        The given timestamp applies to all events in the current frame.
        The timestamp must be in microseconds of CLOCK_MONOTONIC.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="last_serial" type="uint32" summary="the last serial sent by the EIS implementation"/>
      <arg name="timestamp" type="uint64" summary="timestamp in microseconds"/>
    </request>

    <!-- ei_device events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Device removal notification">
        This device has been removed and a client should release all
        associated resources.

        This ei_device object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="name" since="1">
      <description summary="device name notification">
        The name of this device, if any. This event is optional and sent once immediately
        after object creation.

        It is a protocol violation to send this event after the ei_device.done event.
      </description>
      <arg name="name" type="string" summary="the device name"/>
    </event>

    <enum name="device_type" since="1">
      <description summary="device type">
        If the device type is ei_device.device_type.virtual, the device is a
        virtual device representing input as applied on the EIS implementation's
        screen. A relative virtual device generates input events in logical pixels,
        an absolute virtual device generates input events in logical pixels on one
        of the device's regions. Virtual devices do not have a ei_device.dimension but
        it may have an ei_device.region.

        If the device type is ei_device.device_type.physical, the device is a
        representation of a physical device as if connected to the EIS
        implementation's host computer. A relative physical device generates input
        events in mm, an absolute physical device generates input events in mm
        within the device's specified physical size. Physical devices do not have
        regions and no ei_device.region events are sent for such devices.
      </description>
      <entry name="virtual" value="1" summary="a virtual device"/>
      <entry name="physical" value="2" summary="representation of a physical device"/>
    </enum>

    <event name="device_type" since="1">
      <description summary="device type notification">
        The device type, one of virtual or physical.

        Devices of type ei_device.device_type.physical are supported only clients of
        type ei_handshake.context_type.receiver.

        This event is sent once immediately after object creation.
        It is a protocol violation to send this event after the ei_device.done event.
      </description>
      <arg name="device_type" type="uint32" enum="device_type" summary="the device type"/>
    </event>

    <event name="dimensions" since="1">
      <description summary="device dimensions notification">
        The device dimensions in mm. This event is optional and sent once immediately
        after object creation.

        This event is only sent for devices of ei_device.device_type.physical.

        It is a protocol violation to send this event after the ei_device.done event.
      </description>
      <arg name="width" type="uint32" summary="the device physical width in mm"/>
      <arg name="height" type="uint32" summary="the device physical height in mm"/>
    </event>

    <event name="region" since="1">
      <description summary="device dimensions notification">
        Notifies the client of one region. The number of regions is constant for a device
        and all regions are announced immediately after object creation.

        A region is rectangular and defined by an x/y offset and a width and a height.
        A region defines the area on an EIS desktop layout that is accessible by
        this device - this region may not be the full area of the desktop.
        Input events may only be sent for points within the regions.

        The use of regions is private to the EIS compositor and coordinates may not
        match the size of the actual desktop. For example, a compositor may set a
        1920x1080 region to represent a 4K monitor and transparently map input
        events into the respective true pixels.

        Absolute devices may have different regions, it is up to the libei client
        to send events through the correct device to target the right pixel. For
        example, a dual-head setup my have two absolute devices, the first with a
        zero offset region spanning the left screen, the second with a nonzero
        offset spanning the right screen.

        The physical scale denotes a constant factor that needs to be applied to
        any relative movement on this region for that movement to match the same
        *physical* movement on another region.

        It is an EIS implementation bug to advertise the absolute pointer capability
        on a device_type.virtual device without advertising an ei_region for this device.

        This event is optional and sent immediately after object creation. Where a device
        has multiple regions, this event is sent once for each region.
        It is a protocol violation to send this event after the ei_device.done event.
      </description>
      <arg name="offset_x" type="uint32" summary="region x offset in logical pixels"/>
      <arg name="offset_y" type="uint32" summary="region y offset in logical pixels"/>
      <arg name="width" type="uint32" summary="region width in logical pixels"/>
      <arg name="hight" type="uint32" summary="region height in logical pixels"/>
      <arg name="scale" type="float" summary="the physical scale for this region"/>
    </event>

    <event name="interface" since="1">
      <description summary="device capability notification">
        Notification that a new device has a sub-interface.

        This event may be sent for the
        - "ei_pointer" interface if the device has the
          ei_device.capabilities.pointer capability
        - "ei_pointer_absolute" interface if the device has the
          ei_device.capabilities.pointer_absolute capability
        - "ei_scroll" interface if the device has the
          ei_device.capabilities.scroll capability
        - "ei_button" interface if the device has the
          ei_device.capabilities.button capability
        - "ei_keyboard" interface if the device has the
          ei_device.capabilities.keyboard capability
        - "ei_touchscreen" interface if the device has the
          ei_device.capabilities.touchscreen capability
        The interface version is equal or less to the client-supported
        version in ei_handshake.interface_version for the respective interface.

        This event is optional and sent immediately after object creation
        and at most once per interface.
        It is a protocol violation to send this event after the ei_device.done event.
      </description>
      <arg name="object" type="new_id" interface_arg="interface_name"/>
      <arg name="interface_name" type="string" summary="the interface name"/>
      <arg name="version" type="uint32" summary="the interface version"/>
    </event>

    <event name="done" since="1">
      <description summary="device setup completion notification">
        Notification that the initial burst of events is complete and
        the client can set up this device now.

        It is a protocol violation to send this event more than once per device.
      </description>
    </event>

    <event name="resumed" since="1">
      <description summary="device resumed notification">
        Notification that the device has been resumed by the EIS implementation
        and (depending on the ei_handshake.context_type) the client may request
        ei_device.start_emulating or the EIS implementation may
        ei_device.start_emulating events.

        It is a client bug to request emulation of events on a device that is
        not resumed. The EIS implementation may silently discard such events.

        A newly advertised device is in the ei_device.paused state.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="paused" since="1">
      <description summary="device paused notification">
        Notification that the device has been paused by the EIS implementation
        and no futher events will be accepted on this device until
        it is resumed again.

        For devices of ei_device_setup.context_type sender, the client thus does
        not need to request ei_device.stop_emulating and may request
        ei_device.start_emulating after a subsequent ei_device.resumed.

        For devices of ei_device_setup.context_type receiver and where
        the EIS implementation did not send a ei_device.stop_emulating
        prior to this event, the device may send a ei_device.start_emulating
        event after a subsequent ei_device.resumed event.

        Pausing a device resets the logical state of the device to neutral.
        This includes:
        - any buttons or keys logically down are released
        - any modifiers logically down are released
        - any touches logically down are released

        It is a client bug to request emulation of events on a device that is
        not resumed. The EIS implementation may silently discard such events.

        A newly advertised device is in the ei_device.paused state.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="start_emulating" since="1" context-type="receiver">
      <description summary="Device start emulating event">
        See the ei_device.start_emulating request for details.

        It is a protocol violation to send this event for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
      <arg name="sequence" type="uint32"/>
    </event>

    <event name="stop_emulating" since="1" context-type="receiver">
      <description summary="Device stop emulating event">
        See the ei_device.stop_emulating request for details.

        It is a protocol violation to send this event for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="frame" since="1" context-type="receiver">
      <description summary="Device frame event">
        See the ei_device.frame request for details.

        It is a protocol violation to send this event for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
      <arg name="timestamp" type="uint64" summary="timestamp in microseconds"/>
    </event>

    <!-- ei_device events version 2 -->

    <event name="region_mapping_id" since="2">
      <description summary="region id notification">
        Notifies the client that the region specified in the next ei_device.region
        event is to be assigned the given mapping_id.

        This ID can be used by the client to identify an external resource that has a
        relationship with this region.
        For example the client may receive a data stream with the video
        data that this region represents. By attaching the same identifier to the data
        stream and this region the EIS implementation can inform the client
        that the video data stream and the region represent paired data.

        This event is optional and sent immediately after object creation but before
        the corresponding ei_device.region event. Where a device has multiple regions,
        this event may be sent zero or one time for each region.
        It is a protocol violation to send this event after the ei_device.done event or
        to send this event without a corresponding following ei_device.region event.
      </description>
      <arg name="mapping_id" type="string" summary="region mapping id"/>
    </event>

  </interface>

  <interface name="ei_pointer" version="1">
    <description summary="pointer object">
      Interface for pointer motion requests and events. This interface
      is available on devices with the ei_device.capability pointer.

      This interface is only provided once per device and where a client
      requests ei_pointer.release the interface does not get re-initialized. An
      EIS implementation may adjust the behavior of the device (including removing
      the device) if the interface is releasd.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_pointer client requests version 1 -->

    <request name="release" since="1">
      <description summary="Pointer removal request">
        Notification that the client is no longer interested in this pointer.
        The EIS implementation will release any resources related to this pointer and
        send the ei_pointer.destroyed event once complete.
      </description>
    </request>

    <request name="motion_relative" since="1" context-type="sender">
      <description summary="Relative motion request">
        Generate a relative motion event on this pointer.

        It is a client bug to send this request more than once
        within the same ei_device.frame.

        It is a client bug to send this request on a device without
        the ei_device.capabilities.pointer capability.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="x" type="float" summary="the x movement in logical pixels"/>
      <arg name="y" type="float" summary="the y movement in logical pixels"/>
    </request>

    <!-- ei_pointer events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Pointer removal notification">
        This object has been removed and a client should release all
        associated resources.

        This object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="motion_relative" since="1" context-type="receiver">
      <description summary="Relative motion event">
        See the ei_pointer.motion_relative request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="x" type="float"/>
      <arg name="y" type="float"/>
    </event>
  </interface>

  <interface name="ei_pointer_absolute" version="1">
    <description summary="absolute pointer object">
      Interface for absolute pointer requests and events. This interface
      is available on devices with the ei_device.capability pointer_absolute.

      This interface is only provided once per device and where a client
      requests ei_pointer_absolute.release the interface does not get
      re-initialized. An EIS implementation may adjust the behavior of the
      device (including removing the device) if the interface is releasd.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_pointer_absolute client requests version 1 -->

    <request name="release" since="1">
      <description summary="Pointer absolute removal request">
        Notification that the client is no longer interested in this object.
        The EIS implementation will release any resources related to this object and
        send the ei_pointer_absolute.destroyed event once complete.
      </description>
    </request>

    <request name="motion_absolute" since="1" context-type="sender">
      <description summary="Absolute motion request">
        Generate an absolute motion event on this pointer. The x/y
        coordinates must be within the device's regions or the event
        is silently discarded.

        It is a client bug to send this request more than once
        within the same ei_device.frame.

        It is a client bug to send this request on a device without
        the ei_device.capabilities.pointer_absolute capability.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="x" type="float" summary="the x position in logical pixels"/>
      <arg name="y" type="float" summary="the y position in logical pixels"/>
    </request>

    <!-- ei_pointer_absolute events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Pointer absolute removal notification">
        This object has been removed and a client should release all
        associated resources.

        This object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="motion_absolute" since="1" context-type="receiver">
      <description summary="Absolute motion event">
        See the ei_pointer_absolute.motion_absolute request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="x" type="float"/>
      <arg name="y" type="float"/>
    </event>
  </interface>

  <interface name="ei_scroll" version="1">
    <description summary="scroll object">
      Interface for scroll requests and events. This interface
      is available on devices with the ei_device.capability scroll.

      This interface is only provided once per device and where a client
      requests ei_scroll.release the interface does not get
      re-initialized. An EIS implementation may adjust the behavior of the
      device (including removing the device) if the interface is releasd.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <request name="release" since="1">
      <description summary="Scroll removal request">
        Notification that the client is no longer interested in this object.
        The EIS implementation will release any resources related to this object and
        send the ei_scroll.destroyed event once complete.
      </description>
    </request>

    <request name="scroll" since="1" context-type="sender">
      <description summary="Scroll request">
        Generate a a smooth (pixel-precise) scroll event on this pointer.
        Clients must not send ei_scroll.scroll_discrete events for the same event,
        the EIS implementation is responsible for emulation of discrete
        scroll events.

        It is a client bug to send this request more than once
        within the same ei_device.frame.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="x" type="float" summary="the x movement in logical pixels"/>
      <arg name="y" type="float" summary="the y movement in logical pixels"/>
    </request>

    <request name="scroll_discrete" since="1" context-type="sender">
      <description summary="Scroll discrete request">
        Generate a a discrete (e.g. wheel) scroll event on this pointer.
        Clients must not send ei_scroll.scroll events for the same event,
        the EIS implementation is responsible for emulation of smooth
        scroll events.

        A discrete scroll event is based logical scroll units (equivalent to one
        mouse wheel click). The value for one scroll unit is 120, a fraction or
        multiple thereof represents a fraction or multiple of a wheel click.

        It is a client bug to send this request more than once
        within the same ei_device.frame.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="x" type="int32" summary="the x movement in fractions or multiples of 120"/>
      <arg name="y" type="int32" summary="the y movement in fractions or multiples of 120"/>
    </request>

    <request name="scroll_stop" since="1" context-type="sender">
      <description summary="Scroll stop request">
        Generate a a scroll stop or cancel event on this pointer.

        A scroll stop event notifies the EIS implementation that the interaction causing a
        scroll motion previously triggered with ei_scroll.scroll or
        ei_scroll.scroll_discrete has stopped. For example, if all
        fingers are lifted off a touchpad, two-finger scrolling has logically
        stopped. The EIS implementation may use this information to e.g. start kinetic scrolling
        previously based on the previous finger speed.

        If is_cancel is nonzero, the event represents a cancellation of the
        current interaction. This indicates that the interaction has stopped to the
        point where further (server-emulated) scroll events from this device are wrong.

        It is a client bug to send this request more than once
        within the same ei_device.frame.

        It is a client bug to send this request for an axis that
        had a a nonzero value in either ei_scroll.scroll or ei_scroll.scroll_discrete
        in the current frame.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="x" type="uint32" summary="nonzero if this axis stopped scrolling"/>
      <arg name="y" type="uint32" summary="nonzero if this axis stopped scrolling"/>
      <arg name="is_cancel" type="uint32" summary="nonzero to indicate this is a cancel event"/>
    </request>

    <!-- ei_scroll events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Scroll removal notification">
        This object has been removed and a client should release all
        associated resources.

        This object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="scroll" since="1" context-type="receiver">
      <description summary="Scroll event">
        See the ei_scroll.scroll request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="x" type="float"/>
      <arg name="y" type="float"/>
    </event>

    <event name="scroll_discrete" since="1" context-type="receiver">
      <description summary="Discrete scroll event">
        See the ei_scroll.scroll_discrete request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="x" type="int32"/>
      <arg name="y" type="int32"/>
    </event>

    <event name="scroll_stop" since="1" context-type="receiver">
      <description summary="Scroll stop event">

        See the ei_scroll.scroll_stop request for details.
        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.
      </description>
      <arg name="x" type="uint32"/>
      <arg name="y" type="uint32"/>
      <arg name="is_cancel" type="uint32"/>
    </event>
  </interface>

  <interface name="ei_button" version="1">
    <description summary="button object">
      Interface for button requests and events. This interface
      is available on devices with the ei_device.capability button.

      This interface is only provided once per device and where a client
      requests ei_button.release the interface does not get
      re-initialized. An EIS implementation may adjust the behavior of the
      device (including removing the device) if the interface is releasd.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <request name="release" since="1">
      <description summary="Button removal request">
        Notification that the client is no longer interested in this object.
        The EIS implementation will release any resources related to this object and
        send the ei_button.destroyed event once complete.
      </description>
    </request>

    <enum name="button_state" since="1">
      <description summary="Button state">
        The logical state of a button.
      </description>
      <entry name="released" value="0" summary="the button is logically up"/>
      <entry name="press" value="1" summary="the button is logically down"/>
    </enum>

    <request name="button" since="1" context-type="sender">
      <description summary="Button state change request">
        Generate a button event on this pointer.

        The button codes must match the defines in linux/input-event-codes.h.

        It is a client bug to send more than one button request for the same button
        within the same ei_device.frame.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="button" type="uint32" summary="button code"/>
      <arg name="state" type="uint32" enum="button_state"/>
    </request>

    <!-- ei_button events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Pointer removal notification">
        This pointer has been removed and a client should release all
        associated resources.

        This ei_scroll object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="button" since="1" context-type="receiver">
      <description summary="Button state change event">
        See the ei_scroll.button request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.

        It is an EIS implementation bug to send more than one button request
        for the same button within the same ei_device.frame.
      </description>
      <arg name="button" type="uint32"/>
      <arg name="state" type="uint32" enum="button_state"/>
    </event>

  </interface>

  <interface name="ei_keyboard" version="1">
    <description summary="keyboard object">
      Interface for keyboard requests and events. This interface
      is available on devices with the ei_device.capability keyboard.

      This interface is only provided once per device and where a client
      requests ei_keyboard.release the interface does not get re-initialized. An
      EIS implementation may adjust the behavior of the device (including removing
      the device) if the interface is releasd.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_keyboard client requests version 1 -->

    <request name="release" since="1">
      <description summary="keyboard removal request">
        Notification that the client is no longer interested in this keyboard.
        The EIS implementation will release any resources related to this keyboard and
        send the ei_keyboard.destroyed event once complete.
      </description>
    </request>

    <enum name="key_state" since="1">
      <description summary="Key state">
        The logical state of a key.
      </description>
      <entry name="released" value="0" summary="the key is logically up"/>
      <entry name="press" value="1" summary="the key is logically down"/>
    </enum>

    <request name="key" since="1" context-type="sender">
      <description summary="Key state change request">
        Generate a key event on this keyboard. If the device has an
        ei_keyboard.keymap, the key code corresponds to that keymap.

        The key codes must match the defines in linux/input-event-codes.h.

        It is a client bug to send more than one key request for the same key
        within the same ei_device.frame.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than sender.
      </description>
      <arg name="key" type="uint32" summary="the key code"/>
      <arg name="state" type="uint32" enum="key_state" summary="logical state of the key"/>
    </request>

    <!-- ei_keyboard events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Keyboard removal notification">
        This keyboard has been removed and a client should release all
        associated resources.

        This ei_keyboard object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <enum name="keymap_type" since="1">
      <description summary="the keymap type">
        The keymap type describes how the keymap in the ei_keyboard.keymap event
        should be parsed.
      </description>
      <entry name="xkb" value="1" summary="a libxkbcommon-compatible XKB keymap"/>
    </enum>

    <event name="keymap" since="1">
      <description summary="keymap notification">
        Notification that this device has a keymap. Future key events must be
        interpreted by the client according to this keymap. For clients
        of ei_handshake.context_type sender it is the client's
        responsibility to send the correct ei_keyboard.key keycodes to
        generate the expected keysym in the EIS implementation.

        The keymap is constant for the lifetime of the device.

        This event provides a file descriptor to the client which can be
        memory-mapped in read-only mode to provide a keyboard mapping
        description. The fd must be mapped with MAP_PRIVATE by
        the recipient, as MAP_SHARED may fail.

        This event is sent immediately after the ei_keyboard object is created
        and before the ei_device.done event. It is a protocol violation to send this
        event after the ei_device.done event.
      </description>
      <arg name="keymap_type" type="uint32" enum="keymap_type" summary="the keymap type"/>
      <arg name="size" type="uint32" summary="the keymap size in bytes"/>
      <arg name="keymap" type="fd" summary="file descriptor to the keymap"/>
    </event>

    <event name="key" since="1" context-type="receiver">
      <description summary="Key state change event">
        See the ei_keyboard.key request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.

        It is a protocol violation to send a key down event in the same
        frame as a key up event for the same key in the same frame.
      </description>
      <arg name="key" type="uint32"/>
      <arg name="state" type="uint32" enum="key_state"/>
    </event>

    <event name="modifiers" since="1">
      <description summary="Modifier change event">
        Notification that the EIS implementation has changed modifier
        states on this device. Future ei_keyboard.key requests must take the
        new modifier state into account.

        A client must assume that all modifiers are lifted when it
        receives an ei_device.paused event. The EIS implementation
        must send this event after ei_device.resumed to notify the client
        of any nonzero modifier state.

        This event does not reqire an ei_device.frame and should
        be processed immediately by the client.

        This event is only sent for devices with an ei_keyboard.keymap.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
      <arg name="depressed" type="uint32" summary="depressed modifiers"/>
      <arg name="locked" type="uint32" summary="locked modifiers"/>
      <arg name="latched" type="uint32" summary="latched modifiers"/>
      <arg name="group" type="uint32" summary="the keyboard group (layout)"/>
    </event>
  </interface>

  <interface name="ei_touchscreen" version="1">
    <description summary="touchscreen object">
      Interface for touchscreen requests and events. This interface
      is available on devices with the ei_device.capability touchscreen.

      This interface is only provided once per device and where a client
      requests ei_touchscreen.release the interface does not get re-initialized. An
      EIS implementation may adjust the behavior of the device (including removing
      the device) if the interface is releasd.

      Note that for a client to receive objects of this type, it must announce
      support for this interface in ei_handshake.interface_version.
    </description>

    <!-- ei_touchscreen client requests version 1 -->

    <request name="release" since="1">
      <description summary="touch removal request">
        Notification that the client is no longer interested in this touch.
        The EIS implementation will release any resources related to this touch and
        send the ei_touch.destroyed event once complete.
      </description>
    </request>

    <request name="down" since="1" context-type="sender">
      <description summary="touch down request">
        Notifies the EIS implementation about a new touch logically down at the
        given coordinates. The touchid is a unique id for this touch. Touchids
        may be re-used after ei_touchscreen.up.

        The x/y coordinates must be within the device's regions or the event and future
        ei_touchscreen.motion events with the same touchid are silently discarded.

        It is a protocol violation to send a touch down in the same
        frame as a touch motion or touch up.
      </description>
      <arg name="touchid" type="uint32" summary="a unique touch id to identify this touch"/>
      <arg name="x" type="float" summary="touch x coordinate in logical pixels"/>
      <arg name="y" type="float" summary="touch y coordinate in logical pixels"/>
    </request>

    <request name="motion" since="1" context-type="sender">
      <description summary="touch motion request">
        Notifies the EIS implementation about an existing touch changing position to
        the given coordinates. The touchid is the unique id for this touch previously
        sent with ei_touchscreen.down.

        The x/y coordinates must be within the device's regions or the event is
        silently discarded.

        It is a protocol violation to send a touch motion in the same
        frame as a touch down or touch up.
      </description>
      <arg name="touchid" type="uint32" summary="a unique touch id to identify this touch"/>
      <arg name="x" type="float" summary="touch x coordinate in logical pixels"/>
      <arg name="y" type="float" summary="touch y coordinate in logical pixels"/>
    </request>

    <request name="up" since="1" context-type="sender">
      <description summary="touch up request">
        Notifies the EIS implementation about an existing touch being logically
        up. The touchid is the unique id for this touch previously
        sent with ei_touchscreen.down.

        The touchid may be re-used after this request.

        It is a protocol violation to send a touch up in the same
        frame as a touch motion or touch down.
      </description>
      <arg name="touchid" type="uint32" summary="a unique touch id to identify this touch"/>
    </request>

    <!-- ei_touchscreen events version 1 -->

    <event name="destroyed" type="destructor" since="1">
      <description summary="Touchscreen removal notification">
        This touch has been removed and a client should release all
        associated resources.

        This ei_touchscreen object will be destroyed by the EIS implementation immmediately after
        after this event is sent and as such the client must not attempt to use
        it after that point.
      </description>
      <arg name="serial" type="uint32" summary="this event's serial number"/>
    </event>

    <event name="down" since="1" context-type="receiver">
      <description summary="touch down request">
        See the ei_touchscreen.down request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.

        It is a protocol violation to send a touch down in the same
        frame as a touch motion or touch up.
      </description>
      <arg name="touchid" type="uint32"/>
      <arg name="x" type="float"/>
      <arg name="y" type="float"/>
    </event>

    <event name="motion" since="1" context-type="receiver">
      <description summary="touch motion request">
        See the ei_touchscreen.motion request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.

        It is a protocol violation to send a touch motion in the same
        frame as a touch down or touch up.
      </description>
      <arg name="touchid" type="uint32"/>
      <arg name="x" type="float"/>
      <arg name="y" type="float"/>
    </event>

    <event name="up" since="1" context-type="receiver">
      <description summary="touch motion request">
        See the ei_touchscreen.up request for details.

        It is a protocol violation to send this request for a client
        of an ei_handshake.context_type other than receiver.

        It is a protocol violation to send a touch up in the same
        frame as a touch motion or touch down.
      </description>
      <arg name="touchid" type="uint32"/>
    </event>
  </interface>
</protocol>
==============================================================================

==================================== 2/10 ====================================
test:         libei / unit-tests-utils
start time:   01:40:19
duration:     0.02s
result:       exit status 0
command:      MALLOC_PERTURB_=86 LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/subprojects/munit /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test/unit-tests-utils --log-visible debug
----------------------------------- stdout -----------------------------------
Running test suite with seed 0xe4e35a3d...
test_bits_mask                       [ OK    ] [ 0.00000317 / 0.00000236 CPU ]
test_bits_flag_8                     [ OK    ] [ 0.00000225 / 0.00000202 CPU ]
test_bits_flag_32                    [ OK    ] [ 0.00000216 / 0.00000197 CPU ]
test_signal_blocker                  [ OK    ] [ 0.00000901 / 0.00000886 CPU ]
test_pass_fd                         [ OK    ] [ 0.00017592 / 0.00017598 CPU ]
test_iobuf_recv_fd                   [ OK    ] [ 0.00006045 / 0.00006043 CPU ]
test_iobuf_append_fd_too_many        [ OK    ] [ 0.00008145 / 0.00008140 CPU ]
test_iobuf_append_fd                 [ OK    ] [ 0.00004563 / 0.00004559 CPU ]
test_iobuf_append_short              [ OK    ] [ 0.00001535 / 0.00001524 CPU ]
test_iobuf_pop                       [ OK    ] [ 0.00001309 / 0.00001298 CPU ]
test_iobuf_prepend_empty_buffer      [ OK    ] [ 0.00001312 / 0.00001298 CPU ]
test_iobuf_append_values             [ OK    ] [ 0.00001376 / 0.00001365 CPU ]
test_iobuf_append_prepend            [ OK    ] [ 0.00002199 / 0.00002161 CPU ]
test_iobuf_take_fd                   [ OK    ] [ 0.00001419 / 0.00001405 CPU ]
test_iobuf_cleanup                   [ OK    ] [ 0.00001309 / 0.00001297 CPU ]
test_iobuf_new                       [ OK    ] [ 0.00001296 / 0.00001286 CPU ]
list_foreach                         [ OK    ] [ 0.00000249 / 0.00000233 CPU ]
list_first_last                      [ OK    ] [ 0.00000236 / 0.00000221 CPU ]
test_list_nth                        [ OK    ] [ 0.00000236 / 0.00000218 CPU ]
test_list_append                     [ OK    ] [ 0.00000235 / 0.00000216 CPU ]
test_list_insert                     [ OK    ] [ 0.00000278 / 0.00000261 CPU ]
test_source_readd                    [ OK    ] [ 0.00002917 / 0.00002907 CPU ]
test_source                          [ OK    ] [ 0.00003503 / 0.00003496 CPU ]
test_sink                            [ OK    ] [ 0.00001971 / 0.00001962 CPU ]
test_strv_from_mem                   [ OK    ] [ 0.00004166 / 0.00004159 CPU ]
test_strlen0                         [ OK    ] [ 0.00000222 / 0.00000205 CPU ]
test_cmdline_as_str                  [ OK    ] [ 0.00013817 / 0.00013824 CPU ]
test_strreplace                      [ OK    ] [ 0.00002541 / 0.00002530 CPU ]
test_strendswith                     [ OK    ] [ 0.00000669 / 0.00000651 CPU ]
test_strstartswith                   [ OK    ] [ 0.00000638 / 0.00000622 CPU ]
test_strstrip                        [ OK    ] [ 0.00001935 / 0.00001924 CPU ]
test_strjoin                         [ OK    ] [ 0.00002117 / 0.00002111 CPU ]
test_kvsplit_double                  [ OK    ] [ 0.00003974 / 0.00003969 CPU ]
test_strsplit                        [ OK    ] [ 0.00002405 / 0.00002392 CPU ]
34 of 34 (100%) tests successful, 0 (0%) test skipped.
==============================================================================

==================================== 3/10 ====================================
test:         libei / unit-tests-ei
start time:   01:40:19
duration:     0.03s
result:       exit status 0
command:      LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/subprojects/munit MALLOC_PERTURB_=19 /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test/unit-tests-ei --log-visible debug
----------------------------------- stdout -----------------------------------
Running test suite with seed 0x884e52a8...
test_brei_send_message               [ OK    ] [ 0.00025824 / 0.00025825 CPU ]
test_brei_marshal_bad_sig            [ OK    ] [ 0.00002622 / 0.00002610 CPU ]
test_brei_marshal                    [ OK    ] [ 0.00001768 / 0.00001762 CPU ]
test_brei_string_proto_length        [ OK    ] [ 0.00000253 / 0.00000234 CPU ]
test_configure_name                  [ OK    ] [ 0.00008860 / 0.00008860 CPU ]
test_init_unref                      [ OK    ] [ 0.00002507 / 0.00002497 CPU ]
test_log_handler                     [ OK    ] [ 0.00007788 / 0.00007787 CPU ]
test_region_convert                  [ OK    ] [ 0.00000242 / 0.00000224 CPU ]
test_region_contains                 [ OK    ] [ 0.00000244 / 0.00000223 CPU ]
test_region_setters                  [ OK    ] [ 0.00001697 / 0.00001687 CPU ]
10 of 10 (100%) tests successful, 0 (0%) test skipped.
==============================================================================

==================================== 4/10 ====================================
test:         libei / unit-tests-eis
start time:   01:40:19
duration:     0.01s
result:       exit status 0
command:      LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/subprojects/munit MALLOC_PERTURB_=160 /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test/unit-tests-eis --log-visible debug
----------------------------------- stdout -----------------------------------
Running test suite with seed 0x7f6d909d...
test_brei_send_message               [ OK    ] [ 0.00026732 / 0.00026615 CPU ]
test_brei_marshal_bad_sig            [ OK    ] [ 0.00002520 / 0.00002510 CPU ]
test_brei_marshal                    [ OK    ] [ 0.00002305 / 0.00002280 CPU ]
test_brei_string_proto_length        [ OK    ] [ 0.00000255 / 0.00000239 CPU ]
test_log_handler                     [ OK    ] [ 0.00009274 / 0.00009277 CPU ]
test_region_contains                 [ OK    ] [ 0.00000213 / 0.00000196 CPU ]
test_region_setters                  [ OK    ] [ 0.00000212 / 0.00000194 CPU ]
7 of 7 (100%) tests successful, 0 (0%) test skipped.
==============================================================================

==================================== 5/10 ====================================
test:         libei / unit-tests-oeffis
start time:   01:40:19
duration:     0.01s
result:       exit status 0
command:      LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/subprojects/munit MALLOC_PERTURB_=165 /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test/unit-tests-oeffis --log-visible debug
----------------------------------- stdout -----------------------------------
Running test suite with seed 0xb1c1e058...
test_failed_connect                  [ OK    ] [ 0.00007583 / 0.00007518 CPU ]
test_init_unref                      [ OK    ] [ 0.00003345 / 0.00003334 CPU ]
2 of 2 (100%) tests successful, 0 (0%) test skipped.
==============================================================================

==================================== 6/10 ====================================
test:         libei / eierpecken
start time:   01:40:19
duration:     0.49s
result:       exit status 0
command:      LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/subprojects/munit:/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/src MALLOC_PERTURB_=233 /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test/eierpecken --log-visible debug
----------------------------------- stdout -----------------------------------
Running test suite with seed 0xd3178a83...
test_passive_ei_flush_frame          [ OK    ] [ 0.00138431 / 0.00107977 CPU ]
test_passive_ei_frame_timestamp      [ OK    ] [ 0.00132335 / 0.00103224 CPU ]
test_passive_ei_device_multitouch    [ OK    ] [ 0.00153096 / 0.00123423 CPU ]
test_passive_ei_device_touch         [ OK    ] [ 0.00239758 / 0.00200242 CPU ]
test_passive_ei_device_scroll_stop_cancel[ OK    ] [ 0.00132130 / 0.00132136 CPU ]
test_passive_ei_device_scroll_cancel [ OK    ] [ 0.00143711 / 0.00143625 CPU ]
test_passive_ei_device_scroll_stop   [ OK    ] [ 0.00138731 / 0.00138654 CPU ]
test_passive_ei_device_scroll_delta  [ OK    ] [ 0.00134092 / 0.00134056 CPU ]
test_passive_ei_device_pointer_abs   [ OK    ] [ 0.00445467 / 0.00177994 CPU ]
test_passive_ei_device_pointer_rel   [ OK    ] [ 0.00139361 / 0.00139335 CPU ]
test_passive_ei_device_keyboard_key  [ OK    ] [ 0.00122480 / 0.00119772 CPU ]
test_passive_ei_device_button_button [ OK    ] [ 0.00130472 / 0.00130419 CPU ]
test_passive_ei_device_stop_emulating_when_removing[ OK    ] [ 0.00118435 / 0.00118396 CPU ]
test_passive_ei_device_start_stop_emulating[ OK    ] [ 0.00116371 / 0.00116308 CPU ]
test_ei_device_remove_no_stop_emulating_event[ OK    ] [ 0.00120330 / 0.00120253 CPU ]
test_ei_flush_frame                  [ OK    ] [ 0.00111542 / 0.00111486 CPU ]
test_ei_buffered_frame               [ OK    ] [ 0.00149760 / 0.00149768 CPU ]
test_ei_no_empty_frames              [ OK    ] [ 0.00718325 / 0.00117286 CPU ]
test_ei_frame_timestamp              [ OK    ] [ 0.00118080 / 0.00118034 CPU ]
test_ei_keyboard_modifiers           [ OK    ] [ 0.00109638 / 0.00109546 CPU ]
test_ei_keymap_set                   [ OK    ] [ 0.00116801 / 0.00116762 CPU ]
test_ei_keymap_invalid               [ OK    ] [ 0.00084784 / 0.00081417 CPU ]
test_ei_device_multitouch            [ OK    ] [ 0.00128109 / 0.00128061 CPU ]
test_ei_device_touch                 [ OK    ] [ 0.00191252 / 0.00191209 CPU ]
test_ei_device_scroll_stop_cancel    [ OK    ] [ 0.00120509 / 0.00120496 CPU ]
test_ei_device_scroll_cancel         [ OK    ] [ 0.00127379 / 0.00127341 CPU ]
test_ei_device_scroll_stop           [ OK    ] [ 0.00130804 / 0.00130725 CPU ]
test_ei_device_scroll                [ OK    ] [ 0.00118742 / 0.00118667 CPU ]
test_ei_device_pointer_abs           [ OK    ] [ 0.00161641 / 0.00161595 CPU ]
test_ei_device_regions_late_add      [ OK    ] [ 0.00095831 / 0.00095803 CPU ]
test_ei_device_regions_ref_unref     [ OK    ] [ 0.00094033 / 0.00094013 CPU ]
test_ei_device_regions               [ OK    ] [ 0.00101965 / 0.00101856 CPU ]
test_ei_device_pointer_rel           [ OK    ] [ 0.00124736 / 0.00121329 CPU ]
test_ei_device_keyboard_key          [ OK    ] [ 0.00275529 / 0.00117882 CPU ]
test_ei_device_button_button         [ OK    ] [ 0.00123936 / 0.00123860 CPU ]
test_ei_device_close                 [ OK    ] [ 0.00164149 / 0.00164121 CPU ]
test_ei_device_add_remove            [ OK    ] [ 0.00104156 / 0.00104130 CPU ]
test_ei_device_never_added           [ OK    ] [ 0.00087737 / 0.00087705 CPU ]
test_ei_device_set_name_multiple_devices[ OK    ] [ 0.00115365 / 0.00115334 CPU ]
test_passive_ei_device_type          [ OK    ] [ 0.00105433 / 0.00105407 CPU ]
test_ei_device_basics                [ OK    ] [ 0.00089437 / 0.00089430 CPU ]
test_ei_seat_bind_unbind_immediately [ OK    ] [ 0.00120110 / 0.00120106 CPU ]
test_ei_seat_bind_unbind_noref       [ OK    ] [ 0.00131831 / 0.00131823 CPU ]
test_ei_seat_bind_unbind             [ OK    ] [ 0.00132618 / 0.00132596 CPU ]
test_xdotool_rel_motion              [ OK    ] [ 0.00109437 / 0.00109404 CPU ]
test_client_is_receiver              [ OK    ] [ 0.00061411 / 0.00061349 CPU ]
test_client_is_sender                [ OK    ] [ 0.00060582 / 0.00060544 CPU ]
test_ei_disconnect_after_unbind_after_received[ OK    ] [ 0.00092308 / 0.00090987 CPU ]
test_ei_disconnect_after_unbind_before_received[ OK    ] [ 0.00263484 / 0.00094508 CPU ]
test_ei_disconnect_self_after_bind_after_received[ OK    ] [ 0.00079245 / 0.00079214 CPU ]
test_ei_disconnect_after_bind_after_received[ OK    ] [ 0.00076771 / 0.00076735 CPU ]
test_ei_disconnect_self_after_bind_before_received[ OK    ] [ 0.00076704 / 0.00076667 CPU ]
test_ei_disconnect_after_bind_before_received[ OK    ] [ 0.00077546 / 0.00077491 CPU ]
test_ei_disconnect_self_after_seat   [ OK    ] [ 0.00084737 / 0.00082570 CPU ]
test_ei_disconnect_after_seat        [ OK    ] [ 0.00086481 / 0.00086445 CPU ]
test_ei_disconnect_self_after_connect[ OK    ] [ 0.00069664 / 0.00069654 CPU ]
test_ei_disconnect_after_connect     [ OK    ] [ 0.00058230 / 0.00058212 CPU ]
test_ei_disconnect_self_immediately  [ OK    ] [ 0.00066900 / 0.00066900 CPU ]
test_ei_disconnect_immediately       [ OK    ] [ 0.00067295 / 0.00067201 CPU ]
test_ei_ref_unref                    [ OK    ] [ 0.00004046 / 0.00003962 CPU ]
eistest_regions                      [ OK    ] [ 0.00119232 / 0.00119199 CPU ]
eistest_device_ignore_paused_device  [ OK    ] [ 0.00210689 / 0.00210642 CPU ]
eistest_device_resume_pause_twice    [ OK    ] [ 0.00144924 / 0.00119296 CPU ]
eistest_cliend_bind_some_caps        [ OK    ] [ 0.00092868 / 0.00087495 CPU ]
eistest_cliend_bind_all_caps         [ OK    ] [ 0.00083138 / 0.00083120 CPU ]
eistest_name                         [ OK    ] [ 0.00058597 / 0.00058553 CPU ]
eistest_ref_unref                    [ OK    ] [ 0.00003628 / 0.00003531 CPU ]
67 of 67 (100%) tests successful, 0 (0%) test skipped.
==============================================================================

==================================== 7/10 ====================================
test:         libei:python / scanner-pytest
start time:   01:40:20
duration:     25.93s
result:       exit status 0
command:      MALLOC_PERTURB_=21 /usr/bin/pytest --verbose --log-level=DEBUG -n auto -k TestScanner
----------------------------------- stdout -----------------------------------
============================================================================= test session starts ==============================================================================
platform linux -- Python 3.11.5, pytest-7.4.2, pluggy-1.3.0 -- /usr/bin/python3.11
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test/.hypothesis/examples')
rootdir: /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/test
plugins: mock-3.11.1, betamax-0.8.1, flaky-3.7.0, time-machine-2.13.0, typeguard-4.1.5, pyfakefs-5.2.4, forked-1.6.0, timeout-2.1.0, subtests-0.11.0, sphinx_pytest-0.2.0, tornasync-0.6.0.post2, console-scripts-1.4.1, pylama-8.4.1, pkgcore-0.12.23, rerunfailures-12.0, xdist-3.3.1, expect-1.1.0, django-4.5.2, xprocess-0.23.0, requests-mock-1.11.0, shutil-1.7.0, hypothesis-6.84.3, datadir-1.4.1, virtualenv-1.7.0, anyio-3.7.1, regressions-2.5.0, trio-0.8.0, freezegun-0.4.2, aiohttp-1.0.5, pytest_param_files-0.6.0, asyncio-0.21.1, httpbin-2.0.0, nbval-0.10.0, services-2.2.1, jaraco.test-5.3.0, httpserver-1.0.8, codeblocks-0.16.1
asyncio: mode=Mode.STRICT
created: 2/2 workers
2 workers [8 items]

scheduling tests via LoadScheduling

test_scanner.py::TestScanner::test_ei_names[eis] 
test_scanner.py::TestScanner::test_ei_names[brei] 
[gw1] [ 12%] PASSED test_scanner.py::TestScanner::test_ei_names[brei] 
test_scanner.py::TestScanner::test_interface_arg[ei] 
[gw0] [ 25%] PASSED test_scanner.py::TestScanner::test_ei_names[eis] 
test_scanner.py::TestScanner::test_ei_names[ei] 
[gw1] [ 37%] PASSED test_scanner.py::TestScanner::test_interface_arg[ei] 
test_scanner.py::TestScanner::test_versione_arg[ei] 
[gw0] [ 50%] PASSED test_scanner.py::TestScanner::test_ei_names[ei] 
test_scanner.py::TestScanner::test_cli_extra_data[yamlfile] 
[gw1] [ 62%] PASSED test_scanner.py::TestScanner::test_versione_arg[ei] 
test_scanner.py::TestScanner::test_cli_extra_data[jsonfile] 
[gw0] [ 75%] PASSED test_scanner.py::TestScanner::test_cli_extra_data[yamlfile] 
[gw1] [ 87%] PASSED test_scanner.py::TestScanner::test_cli_extra_data[jsonfile] 
test_scanner.py::TestScanner::test_cli_extra_data[string] 
[gw0] [100%] PASSED test_scanner.py::TestScanner::test_cli_extra_data[string] Clearing the cache


============================================================================== 8 passed in 17.47s ==============================================================================
pytest-xprocess reminder::Be sure to terminate the started process by running 'pytest --xkill' if you have not explicitly done so in your fixture with 'xprocess.getinfo(<process_name>).terminate()'.
----------------------------------- stderr -----------------------------------
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.01s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
==============================================================================

==================================== 8/10 ====================================
test:         libei:python / python-black
start time:   01:40:46
duration:     1.89s
result:       exit status 0
command:      MALLOC_PERTURB_=32 /usr/bin/black --check /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0 /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0/proto/ei-scanner
----------------------------------- stderr -----------------------------------
All done! ✨ 🍰 ✨
8 files would be left unchanged.
==============================================================================

==================================== 9/10 ====================================
test:         libei:python / oeffis-pytest
start time:   01:40:19
duration:     28.57s
result:       exit status 0
command:      LD_LIBRARY_PATH=/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/src MALLOC_PERTURB_=97 /usr/bin/pytest --verbose --log-level=DEBUG -n auto
----------------------------------- stdout -----------------------------------
============================================================================= test session starts ==============================================================================
platform linux -- Python 3.11.5, pytest-7.4.2, pluggy-1.3.0 -- /usr/bin/python3.11
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0/test/.hypothesis/examples')
rootdir: /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0/test
plugins: mock-3.11.1, betamax-0.8.1, flaky-3.7.0, time-machine-2.13.0, typeguard-4.1.5, pyfakefs-5.2.4, forked-1.6.0, timeout-2.1.0, subtests-0.11.0, sphinx_pytest-0.2.0, tornasync-0.6.0.post2, console-scripts-1.4.1, pylama-8.4.1, pkgcore-0.12.23, rerunfailures-12.0, xdist-3.3.1, expect-1.1.0, django-4.5.2, xprocess-0.23.0, requests-mock-1.11.0, shutil-1.7.0, hypothesis-6.84.3, datadir-1.4.1, virtualenv-1.7.0, anyio-3.7.1, regressions-2.5.0, trio-0.8.0, freezegun-0.4.2, aiohttp-1.0.5, pytest_param_files-0.6.0, asyncio-0.21.1, httpbin-2.0.0, nbval-0.10.0, services-2.2.1, jaraco.test-5.3.0, httpserver-1.0.8, codeblocks-0.16.1
asyncio: mode=Mode.STRICT
created: 2/2 workers
2 workers [6 items]

scheduling tests via LoadScheduling

test_oeffis.py::test_ref_unref 
test_oeffis.py::test_ctx 
[gw0] [ 16%] PASSED test_oeffis.py::test_ref_unref 
test_oeffis.py::test_set_user_data 
[gw0] [ 33%] PASSED test_oeffis.py::test_set_user_data 
[gw1] [ 50%] PASSED test_oeffis.py::test_ctx 
test_oeffis.py::TestOeffis::test_create_session 
test_oeffis.py::test_error_out 
[gw1] [ 66%] PASSED test_oeffis.py::test_error_out 
[gw0] [ 83%] PASSED test_oeffis.py::TestOeffis::test_create_session 
test_oeffis.py::test_version_compare 
[gw0] [100%] PASSED test_oeffis.py::test_version_compare Clearing the cache


======================================================================== 6 passed, 2 skipped in 20.39s =========================================================================
pytest-xprocess reminder::Be sure to terminate the started process by running 'pytest --xkill' if you have not explicitly done so in your fixture with 'xprocess.getinfo(<process_name>).terminate()'.
----------------------------------- stderr -----------------------------------
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
==============================================================================

=================================== 10/10 ====================================
test:         libei:python / protocol-test
start time:   01:40:19
duration:     30.03s
result:       killed by signal 15 SIGTERM
command:      MALLOC_PERTURB_=189 /usr/bin/pytest --verbose --log-level=DEBUG -n auto -k TestEiProtocol
----------------------------------- stdout -----------------------------------
============================================================================= test session starts ==============================================================================
platform linux -- Python 3.11.5, pytest-7.4.2, pluggy-1.3.0 -- /usr/bin/python3.11
cachedir: .pytest_cache
hypothesis profile 'default' -> database=DirectoryBasedExampleDatabase('/var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build/.hypothesis/examples')
rootdir: /var/tmp/portage/dev-libs/libei-1.1.0/work/libei-1.1.0-build
plugins: mock-3.11.1, betamax-0.8.1, flaky-3.7.0, time-machine-2.13.0, typeguard-4.1.5, pyfakefs-5.2.4, forked-1.6.0, timeout-2.1.0, subtests-0.11.0, sphinx_pytest-0.2.0, tornasync-0.6.0.post2, console-scripts-1.4.1, pylama-8.4.1, pkgcore-0.12.23, rerunfailures-12.0, xdist-3.3.1, expect-1.1.0, django-4.5.2, xprocess-0.23.0, requests-mock-1.11.0, shutil-1.7.0, hypothesis-6.84.3, datadir-1.4.1, virtualenv-1.7.0, anyio-3.7.1, regressions-2.5.0, trio-0.8.0, freezegun-0.4.2, aiohttp-1.0.5, pytest_param_files-0.6.0, asyncio-0.21.1, httpbin-2.0.0, nbval-0.10.0, services-2.2.1, jaraco.test-5.3.0, httpserver-1.0.8, codeblocks-0.16.1
asyncio: mode=Mode.STRICT
created: 2/2 workers
2 workers [29 items]

scheduling tests via LoadScheduling

test/test_protocol.py::TestEiProtocol::test_server_sends_version_event_immediately 
test/test_protocol.py::TestEiProtocol::test_send_wrong_context_type 
----------------------------------- stderr -----------------------------------
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.00s - Debugger warning: It seems that frozen modules are being used, which may
0.01s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
0.01s - Debugger warning: It seems that frozen modules are being used, which may
0.00s - make the debugger miss breakpoints. Please pass -Xfrozen_modules=off
0.00s - to python to disable frozen modules.
0.00s - Note: Debugging will proceed. Set PYDEVD_DISABLE_FILE_VALIDATION=1 to disable this validation.
==============================================================================


Summary of Failures:

10/10 libei:python / protocol-test  TIMEOUT        30.03s   killed by signal 15 SIGTERM

Ok:                 9   
Expected Fail:      0   
Fail:               0   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            1