Since commit
7b9fd5d1c9
tsm-client no longer produces working binaries
(discovered with bisection).
Instead, calling the command line client `dsmc`
just produces the error
> error while loading shared libraries: libtsmxerces-depdom.so.28: cannot open shared object file: No such file or directory
Output of `ldd $out/dsmc`
> linux-vdso.so.1 (0x00007ffd89f70000)
> libgsk8ssl_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8ssl_64.so (0x0000791c8eb34000)
> libgsk8iccs_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8iccs_64.so (0x0000791c8e9b7000)
> libgsk8km_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8km_64.so (0x0000791c8e791000)
> libxmlutil-8.1.13.0.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/opt/tivoli/tsm/client/api/bin64/libxmlutil-8.1.13.0.so (0x0000791c8e675000)
> libcrypt.so.1 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libcrypt.so.1 (0x0000791c8e639000)
> libpthread.so.0 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0 (0x0000791c8e619000)
> libdl.so.2 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libdl.so.2 (0x0000791c8e614000)
> libstdc++.so.6 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x0000791c8e43f000)
> libgpfs.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/opt/tivoli/tsm/client/api/bin64/libgpfs.so (0x0000791c8e22a000)
> libdmapi.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/opt/tivoli/tsm/client/api/bin64/libdmapi.so (0x0000791c8e020000)
> librt.so.1 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/librt.so.1 (0x0000791c8e015000)
> libm.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libm.so.6 (0x0000791c8ded4000)
> libgcc_s.so.1 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x0000791c8deba000)
> libc.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6 (0x0000791c8dce5000)
> libgsk8cms_64.so => /nix/store/i21g0x44g336ag8rkx0dgndb9v4w2xhk-tsm-client-8.1.13.3-unwrapped/local/ibm/gsk8_64/lib64/libgsk8cms_64.so (0x0000791c8d78d000)
> /nix/store/4s21k8k7p1mfik0b33r2spq5hq7774k1-glibc-2.33-108/lib/ld-linux-x86-64.so.2 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x0000791c8f074000)
> libtsmxerces-depdom.so.28 => not found
> libtsmxerces-c.so.28 => not found
Output of `ldd $out/lib/libtsmxerces-depdom.so.28`
> linux-vdso.so.1 (0x00007fff69388000)
> libpthread.so.0 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libpthread.so.0 (0x000078f150454000)
> libtsmxerces-c.so.28 => not found
> libstdc++.so.6 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libstdc++.so.6 (0x000078f15027f000)
> libm.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libm.so.6 (0x000078f15013e000)
> libgcc_s.so.1 => /nix/store/ndnqiz3nnifj1blhg9q626xlmkqq1nmh-gcc-10.3.0-lib/lib/libgcc_s.so.1 (0x000078f150124000)
> libc.so.6 => /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib/libc.so.6 (0x000078f14ff4d000)
> /nix/store/qjgj2642srlbr59wwdihnn66sw97ming-glibc-2.33-123/lib64/ld-linux-x86-64.so.2 (0x000078f150601000)
The commit given above rewrote the `autoPatchelfHook`.
The new hook still calls `patchelf` to actually
modify binary files, but the discovery of
shared libraries apparently got changed.
Thorough investigation of all `patchelf` calls in the
old and new autoPatchelfHook showed that all files are
treated equally up the the files
* $out/opt/tivoli/tsm/client/api/bin64/libtsmxerces-depdom.so.28.0
* $out/opt/tivoli/tsm/client/api/bin64/libxmlutil-8.1.13.0.so
where the new autoPatchelf implementation replaced `$out/lib`
with `$out/opt/tivoli/tsm/client/api/bin64` in the rpath.
I failed to see *why* the new algorithm does
that, or if that might be considered a bug.
The `tsm-client` package has some confusing symlink
structure which certainly might confuse `autoPatchelfHook`.
The following ideas to "restore" the old behaviour
of `autoPatchelfHook` failed to produce a working package:
* add "$out" or "${placeholder "out"}" to `runtimeDependencies`
* use `addAutoPatchelfSearchPath` with `$out/lib` or
another so-file-containing directory
The commit at hand fixes the issue by directly adding `$out/lib`
to the rpath of all shared libraries in that directory.
This has to be done *after* `autoPatchelf` got executed.
To accomplish this, we disable auto-calling `autoPatchelf`
(it would run after `postFixup`) and instead call it
manually in `postFixup`, just before we patch the rpath by hand.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: xbstream.c.o:(.bss+0x0): multiple definition of
`datasink_buffer'; ds_buffer.c.o:(.data.rel.local+0x0): first defined here
pydrive is abandoned and has unfixed issues. In particular, Deja Dup
backups (which uses duplicity as backend) to Google Drive fail with
Giving up after 5 attempts. RedirectMissingLocation: Redirected but
the response is missing a Location: header.
More context and pointers are available in the Deja Dup bug tracker:
https://gitlab.gnome.org/World/deja-dup/-/issues/202#note_1306216
It seems that duplicity needs boto instead of boto3.
They apparently have different packages.
I decided to keep both,
as there may be another backend depending on it.
Workaround build failure on -fno-common toolchains like upstream
gcc-10. Otherwise build fails as:
ld: listindex.o:/build/btar-1.1.1/loadindex.h:12: multiple definition of
`ptr'; main.o:/build/btar-1.1.1/loadindex.h:12: first defined here
These derivations use buildDotnetModule, which has had its default
dotnet version changed recently. This patch removes redundantly setting
the SDK/runtime to version 6.
Backport unit test changes from project's master branch to replace
hardcoded /tmp with os.TempDir() calls in Go.
It can now handle /private/tmp/nix-build-{pname}-{version}.drv-0 paths
on Darwin.
- Add the 'gitUpdater' helper function to update git based packages, using the
'genericUpdater' function.
- Rework argument passing to the `list-git-tags' and 'list-archive-two-level-versions' scripts.
- Replace 'genericUpdater' plus 'list-git-tags' by 'gitUpdater'
IBM publishes their IBM Spectrum Protect client
for Linux in two flavors:
* "Linux x86_64 client"
* "Linux x86_64 Ubuntu client"
Up to this commit, nixpkgs used the Ubuntu
flavor to build its `tsm-client` derivation.
However, the history of published archive files in
* https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/client/v8r1/Linux/
* https://public.dhe.ibm.com/storage/tivoli-storage-management/patches/client/v8r1/Linux/
suggests that updates in the fourth level of
the version numbers (e.g. 8.1.13.0 -> 8.1.13.1)
do not get published as Ubuntu flavor.
It order to be able to always use the latest release,
this commit switches to the non-Ubuntu flavor.
The non-Ubuntu archive contains rpm files,
so this commit switches from `ar` to `rpmextract`.
Instead of unpacking all deb files,
the build recipe now unpacks all _but one_ rpm file:
The file `TIVsm-WEBGUI.x86_64.rpm` apparently
contains a plugin that is not included
in the Ubuntu version (see note below).
Comparing the old and the new derivation's output indicates
that this choice minimizes the difference between the results:
The output of the old (Ubuntu flavor) derivation contains:
* `commons-codec-1.6.jar`
* `share/` with changelog and copyright information
for the packages `gskssl64` and `gskcrypt64`
The output of the new (non-Ubuntu flavor) derivation contains:
* `lib64`, symlink to `lib`
* `commons-codec-1.14.jar`
* `opt/tivoli/tsm/license/{api,baclient}/sm/`
with license agreement files in many languages
Besides these differences, the outputs' file names are equal.
Note: I don't know what functionality
`TIVsm-WEBGUI.x86_64.rpm` actually provides.
Unpacking it with the other rpm files makes patchelf complain
about missing X11 libraries, so in order to include it here,
one would likely need to add those to `buildInputs`.
However, as the old (Ubuntu flavor) `tsm-client` package
did not contain this functionality and as I cannot test
or use it in any way, I opted to not include it now.
If we want to include this with a later commit,
we should add another package build option (like `enableGui`)
so that the default `tsm-client` package does not pull in
X11 libraries and its closure size therefore stays small.
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.
Release notes: https://github.com/kopia/kopia/releases/tag/v0.9.8
The module started to depend on Go 1.17:
```
internal/scrubber/scrub_sensitive.go:28:16: sf.IsExported undefined (type reflect.StructField has no field or method IsExported)
note: module requires Go 1.17
```
