The tsm-client needs a tsm-server to do anything useful.
Without a server, automated tests can just
check diagnostic outputs for plausibility.
The commit at hand adds two tests:
1.
The command line interface `dsmc` is called,
then it is verified that the program does
* report the correct client version,
* find its configuration file,
* report a connection error.
2.
To check the GUI (and the tsm-client nixos module), we add a
vm test which uses the module to install `tsm-client-withGui`.
To verify that the GUI's basic functionality is present,
we skip over all connection failure related error
messages and open the "Connection Information"
dialog from the main application window.
This dialog presents the node name and the client version;
both are verified by the test.
Note: Our `tsm-client` build recipe consists of two packages:
The "unwrapped" package and the final package.
This commit puts the unwrapped one into the final
package's `passthru` so that tests can access
the original version string that is needed to check
the client version reported by the application.
The TSM command line client `dsmc` should be the
program that is usually invoked from this package.
However, if a user explicitely asks for the
package with GUI support (with `enableGui`,
available in the package `tsm-client-withGui`),
we set the mainProgram to the graphical application `dsmj`
as that's likely what the user is looking for.
Although I'm not sure if `tsm-client` will ever be
subject to cross-compiling, referencing makeWrapper
from native BuildInputs is The Right Thing.
This is a kind of follow-up of
https://github.com/NixOS/nixpkgs/pull/112276
IBM has changed the URL structures of their support web pages.
The commit at hand updates most URLs and
in particular the package update instructions
so they follow the new structure.
It also calculates the source download URL from the
version number, so package updates no longer have to
update the URL in addition to the version string.
The tsm-client package comes in two flavours:
command line only (`tsm-client`) and with a
Java-backed GUI (`tsm-client-withGui`).
To control which package is built,
the build recipe simply used to check if the
`jdk8` package was provided as package input.
This commit changes this mechanism:
The build recipe now accepts the explicit option `enableGui`,
which is set to `false` by default.
As the commit at hand touches the build recipe arguments,
it also changes argument sorting following
https://nixos.org/manual/nixpkgs/stable/#sec-syntax
While testing the new version, I observed that
`dsmc` prints an error "sh: grep: command not found"
when executed with empty PATH.
Apparently, `dsmc` needs `grep` in its PATH.
lvm2 support was broken when lvm2 got
converted to a multiple-output derivation:
https://github.com/NixOS/nixpkgs/pull/93024d3a991d410
The `runtimeDependencies` attribute doesn't specifically
look for a `lib` output, so it uses the main `out` output
which no longer contains the library object files.
Since TSM loads the `libdevmapper.so` library
dynamically (likely with `dlfcn.h` functions),
the breakage couldn't be detected at build time.
The commit at hand simply uses
`getLib` to pick the correct output.
IBM Spectrum Protect (former name: Tivoli Storage Manager)
provides a single point of control for backup and recovery.
This package contains the client software, that is,
a command line client and linkable libraries.
This commit adds two packages to nixpkgs:
The TSM client software contains a Java GUI
that, naturally, requires Java to be installed.
To keep the closure size low, we provide the packages
`tsm-client` and `tsm-client-withGUI`.
The former comes without the Java GUI.
While the product has been renamed, its old name is still
alive in filenames and as package name used by other distros.
