Arch Linux User Repository

@MartinDiehl, the AUR package has been orphaned. If you wanted to adopt it and make your proposed changes for the next version (even if you immediately orphan the package again), we would all be grateful. I am happy to test!

If I am in a directory called

/home/m/DAMASK/examples/SpectralMethod/Polycrystal

and execute

/opt/HDFView/3.1.0/hdfview.sh 20grains16x16x16_tensionX.hdf5

to open the file 20grains16x16x16_tensionX.hdf5 which is located in this directory, I get an empty HDFview window.

using

/opt/HDFView/3.1.0/hdfview.sh -root $PWD 20grains16x16x16_tensionX.hdf5

or

/opt/HDFView/3.1.0/hdfview.sh /home/m/DAMASK/examples/SpectralMethod/Polycrystal/20grains16x16x16_tensionX.hdf5

results in the expected behavior. So it seems that the current working directory is not taken into account when using a relative path.

Is the hdfview.sh issue only a problem when the filepath has spaces in it? If so, it's just that there are no quote marks around the argument passing in /usr/bin/hdfview.sh, it needs to be:

/opt/HDFView/3.0.0/hdfview.sh "$@"

This issue is present in the current version. Even if the issue you're seeing is different (sounds like it might be), the above should still be fixed.

Three more comments

1) It is not necessary to have a copy of the JRE (Java runtime environment). I'm not sure whether it is considered good practice, but to me it seems more Arch linux style to use the JRE provided by the system.

2) I think using hdfview instead of hdfview.sh is the better choice

3) Passing the file name to hdfview(.sh) does not work anymore. It requires to explicitly set the root dir to $PWD

Please find an updated version that solves these three issues on https://cloud.martin-diehl.net/index.php/s/CSaHLkb4PayD4NT It also includes a high-res logo (svg)

Hi,

I tried to update the package to 3.1 and found two issues which should probably be tackled upstream. I sent the following message to the HDF group

Dear HDF team,

I am trying to build the hdfviewer from source (this is required to package it for Arch linux, see https://aur.archlinux.org/packages/hdfview) and encountered the two issues:

1) First, recording the symlinks (line 1080ff in build.xml) requires write access to the location where the libraries are located. This is typically in /lib, so most users do not have permission to write there (for good reasons). However, simply removing recording and restoring the symlinks does not cause any harm on my system because the libraries are anyway available system wide.

2) The call to jdeps (line 899ff in build.xml) results in an extremely long list of arguments to the following call of jlink which cannot be handled (too many arguments). Since most of these dependencies are not found (and apparently not needed), adding "<arg value="--ignore-missing-deps" />" resolves this issue.

I think both issues are not very specific too my system and are relevant to other users as well. Please find attached a patched build.xml

best regards,

Martin

In the meantime, the following PKGBUILD including patch resolves the issues: https://cloud.martin-diehl.net/index.php/s/Wbs2D7KPKM7P6YD

Note that JDK 8 does not work anymore (I use 12, but probably already 9 is sufficient)

One of the dependencies, hdf5-java, has had a new release on the AUR, leading to failure with:

Warning! HDF5 library version mismatched error The HDF5 header files used to compile this application do not match the version used by the HDF5 library to which this application is linked. Data corruption or segmentation faults may occur if the application continues. This can happen when an application was compiled by one version of HDF5 but linked with a different version of static or shared HDF5 library.

etc etc.

Rebuilding hdfview fixes it. You might consider bumping the PKGREL to prompt users to rebuild. However, hdf5-openmpi-java on the AUR has not had a version bump yet, so you would need to do it again when that bumps. Also since hdf5 in the arch repos hasn't been updated to 1.10.5 yet, we're currently in an annoying situation where say, h5py from the repos won't work with hdf5-java from the AUR since h5py was compiled with 1.10.4. Annoying that patch releases break hdf5 applications.

@eleftg Please accept my apologies for upsetting you by flagging your package. I personally prefer people to flag the packages I maintain when they believe a change needs to be made.

I know I had some rational thought in my head when I specified =11, but I can't remember it anymore! Removed.

@greyltc: First of all, calm down and refrain from marking a package out-of-date just because you find one of its dependencies absurd and the maintainer is not immediately responsive to your comments. I generally respond very quickly unless on holidays or traveling abroad with limited access.

Secondly, you are right, there is no reason it should depend on the openmpi version, but this is what I exclusively use and it didn't cross my mind to create a minimalist hdf5-java like you did (bravo for that). So I introduced an unnecessary dependency without thinking it through.

Thirdly, avoid forcing the version of openjdk in your PKGBUILD (=11) unless there is a very specific, compelling reason to do so. Just like I ignored all those people out there who do not necessarily use the openmpi variant of hdf5, you tend to ignore all those who still work with java 8 (LTS until Dec 2020) and are happy with it.

Why should this depend on the openmpi version of hdf5? Please change the dependency to hdf5-java.