* Boost 1.85.0-icu77.1-py3.14 => 1.90.0-icu77.1-py3.14 * Update boost 1.90.0-icu77.1-py3.14 binaries * Add x86_64 boost.filelist for 1.90.0-icu77.1-py3.14 * Eigen 3.4.0-1 => 5.0.1 * Rebuild coin 4.0.8 with boost 1.90.0-icu77.1-py3.14 * Rebuild exempi 2.6.6 with boost 1.90.0-icu77.1-py3.14 * Grive 0.5.3-648ff8e-1 => 0.5.3-be52cb2 * Rebuild ledger 3.4.1 with boost 1.90.0-icu77.1-py3.14 * Rebuild libcdr 0.1.8-icu77.1 and librevenge 0.0.5 with boost 1.90.0-icu77.1-py3.14 * Rebuild libwpd 0.10.3 and libwpg 0.3.4 with boost 1.90.0-icu77.1-py3.14 * Build libtorrent 2.0.12 with boost 1.90.0-icu77.1-py3.14 * Rebuild libvisio 0.1.10 with boost 1.90.0-icu77.1-py3.14 * Remove librevenge.filelist for i686 * Build mysql 9.6.0-icu77.1 with boost 1.90.0-icu77.1-py3.14 * Build source_highlight 3.1.9-894cacd-boost1.90 with boost 1.90.0-icu77.1-py3.14 * Rebuild swig 4.4.1, taglib 2.2.1 and tcpflow 1.6.1-8d47b53 with boost 1.90.0-icu77.1-py3.14 --------- Co-authored-by: Satadru Pramanik, DO, MPH, MEng <satadru@gmail.com>
Package Tests
These are simple bash shell scripts that test package binaries, manpages, etc. to make sure they are working correctly and do not generate errors. A test filename has the same name as the package without any extension, should be executable and have at least one line to validate the test(s). It should be placed in a subdirectory with the first letter of the package name. The subdirectory is necessary due to the sheer volume of packages and helps to organize files for manageability. This is similar to the directory structure of the manifest filelists. Keep in mind package tests will fail if the package is not installed.
Running Tests
$ crew check <name> [<name2> <name3> ...]
where <name> is the crew package. If the package test exists, it will run last in the check sequence.
Examples
coreutils:
#!/bin/bash
for b in $(crew files coreutils | grep /usr/local/bin); do $b --version; done
This test is in the c directory.
github_cli:
#!/bin/bash
man gh | cat
gh --version
This test is in the g directory.