Supported architectures

[alcir]

Hello. I was trying to package alizams on Fedora. It compiles successfully on x86_64, while it fails on all other architectures (armv7, aarch64, ppc64le, s390x).

At a first glance, the compilation error is here:

fatal error: xmmintrin.h: No such file or directory
   34 | #include <xmmintrin.h>

Packagers more experienced than me stated that xmmintrin.h is an header for SSE CPU instructions. SSE is an x86_64 extension. So the solution could be to "wrap" such includes with

#ifdef __SSE__
#include <xmmintrin.h>
#endif

But the point is: does alizams is supposed to work on architectures other than x86_64?

Thanks.

[issakomi]

Hello,

thank you.

I am not sure about these architectures, they are not tested, never tried, the issue with SSE may be solved with define DISABLE_SIMDMATH.

May be the line can be improved: https://github.com/AlizaMedicalImaging/AlizaMS/blob/a0cafda32e4c591174e3833428a8ea04a035a21c/CMakeLists.txt#L855

BTW, macOS Apple Silicon M1 arm64 works well, but i have done some changes to get it working.

Are arm7 and aarch64 using OpenGL or OpenGLES?

Is is possible to release only x86_64 / x86?

[alcir]

Thank you for your prompt reply.

I am not sure about these architectures, they are not tested, never tried, the issue with SSE may be solved with define DISABLE_SIMDMATH.

I will take a look.

Are arm7 and aarch64 using OpenGL or OpenGLES?

As far as I've seen in another compilation error on aarch64, by switching an "if arm" statement to OpenGL that error has gone. So I think that OpenGL is used.

Is is possible to release only x86_64 / x86?

Yes. I think that I will end up doing that. (My competencies in programming languages are very limited).

[issakomi]

Thank you very much!

Is is possible to release only x86_64 / x86?

Yes. I think that I will end up doing that.

I think it is better now. SSE2 issue is very easy to fix, but i am a little lost about Qt / OpenGL, maybe i shall buy RPi later and try.

There is another point. I have seen that Fedora uses Wayland by default, there are many problems with Qt's Wayland QPA. Debian/Ubuntu also uses Wayland by default now, but for Qt apps QtWayland is not used, only if variable QT_QPA_PLATFORM=wayland is set, by default they use xcb. On Fedora it is different, it is the reason i still release Aliza rpm only with Qt4. Qt5 build works on Fedora without problems with QT_QPA_PLATFORM=xcb, otherwise there is strange issue with transparency and many common Qt's Wayland warnings. It is safe to build with Qt4, even if AlizaMS can be build with Qt5 and Qt6. Qt4 is still available on Fedora 34. I have tried to find a workaround for transparency issue, but without success. i don't think there is a bug on my side, not 100% sure, but i use Qt5 with X11 myself many years with Debian, release Windows version with Qt5, macOS with Qt6 (to support arm64 M1 CPU). No problems, only with Qt's Wayland QPA. If you decide to use Qt4, there is also the cmake option _USE_SYSTEM_GLEWQT4, to switch between included (default) GLEW (statically linked) and distribution's GLEW (dynamically linked). For Qt5/Qt6 builds GLEW is not used at all.

Kind regards

Edit: i have done some changes to avoid SSE2 issue, can not test, but there is also new cmake option USE_FORCE_DISABLE_SIMDMATH (off by default).

[issakomi]

Maybe i have found simple workaround to force xcb platform and avoid QtWayland issues by setting (overriding) the environment variable at the beginning of main function setenv("QT_QPA_PLATFORM", "xcb", 1); Seem to work, but i have to test a little to be sure.

[alcir]

Maybe i have found simple workaround to force xcb platform and avoid QtWayland issues by setting (overriding) the environment variable at the beginning of main function setenv("QT_QPA_PLATFORM", "xcb", 1); Seem to work, but i have to test a little to be sure.

But it is at compile time? Because I remember that before starting an application there was an environment variable to force... Well right now I don't remember. But such variable had something to do with QT and wayland. Maybe it is this one. And you can add it to the .desktop file.

[alcir]

I think it is better now. SSE2 issue is very easy to fix, but i am a little lost about Qt / OpenGL, maybe i shall buy RPi later and try.

Don't bother with that. Having an application that supports x86_64 only is perfectly fine.

[issakomi]

But it is at compile time?

Yes

And you can add it to the .desktop file.

Good idea, it can be Qt argument "-platform" too, the same as variable QT_QPA_PLATFORM, AFAIK. But seems to work now with setenv. Already in master branch. So Qt4 can be avoided, i hope.

[alcir]

Good idea, it can be Qt argument "-platform" too, the same as variable QT_QPA_PLATFORM, AFAIK. But seems to work now with setenv. Already in master branch. So Qt4 can be avoided, i hope.

Thanks. I will try as soon as possible.

[issakomi]

Thank you very much! Please kindly allow me several days to release next version. I am reviewing CMakeLists file and several other things. It would be really nice if there will be Fedora package. BTW, Qt6 is also possible, already works.

[alcir]

i have done some changes to avoid SSE2 issue, can not test, but there is also new cmake option USE_FORCE_DISABLE_SIMDMATH (off by default).

OK. I can confirm that now it builds successfully on armv7 and aarch64. I need to see if the compiled program actually runs. Maybe tomorrow.

[issakomi]

OK. I can confirm that now it builds successfully on armv7 and aarch64. I need to see if the compiled program actually runs. Maybe tomorrow.

Oh, thank you! Interesting. I can imagine, not sure, that on arm OpenGL Core profile might work better. For Qt6 build i set Core profile (i use Qt6 only with macOS currently and macOS supports only Core profile for OpenGL 3+). For Qt5 i don't set anything explicit, it ends up in Compatibility profile (might be better for older systems), maybe i shall add a cmake option to use Core profile with Qt5 too.

[issakomi]

I have updated CMakeLists.txt, put options together for better readability, renamed several options to follow convention, they start now with _ALIZA or _MDCM__ (cmake-gui and cache file sort variables by name). _MDCM were already correct, not changed. Also added _ALIZA_QT5COREGL, off by default(-DALIZA_QT5_COREGL:BOOL=ON to use Core profile for Qt5 build, may be required for arm).

Highly likely there is no need to change anything, default are still applicable, if you have used force-disable SSE/SSE2 (maybe it was required, not sure), the option is named _ALIZA_DISABLESIMDMATH now (-DALIZA_DISABLE_SIMDMATH:BOOL=ON).

If you use system libraries, they didn't change, e.g.

 -DALIZA_QT_VERSION:STRING=5 \
 -DCMAKE_SKIP_RPATH:BOOL=ON \
 -DMDCM_USE_SYSTEM_UUID:BOOL=ON \
 -DMDCM_USE_SYSTEM_ZLIB:BOOL=ON \
 -DMDCM_USE_SYSTEM_OPENJPEG:BOOL=ON \
 -DMDCM_USE_SYSTEM_CHARLS:BOOL=ON

Do you prefer system's libraries? ITK too? Statically linked included libraries and ITK work well, but may be there is policy like on Debian to prefer system's shared libraries always.

I think new release is so far ready, will look a little more at it and publish soon.

Thank you very much!

[alcir]

The compiled program works! Tested on aarch64 (Pinebook Pro).

The only issue is that the buttons are without icons. And some buttons are "invisible": the button sqare appears (without the icon) only when the mouse cursor moves on them.

[issakomi]

Thank you!

The only issue is that the buttons are without icons.

Probably something is wrong with Qt plugin iconengines/libqsvgicon.so or imageformats/libqsvg.so or Qt SVG library (libQt5Svg.so.5 or libQt6Svg.so.6)

[issakomi]

I am thinking about the issue with icons on arm. May be something is wrong with resources in general. Do you see the green logo in "About" widget? It is PNG, so if it is visible the problem is only with SVG.

Edit: Maybe export QT_DEBUG_PLUGINS=1 could be useful.

[alcir]

Do you see the green logo in "About" widget?

Yes

[issakomi]

I remember that i had the issue with empty icons once somehow. Don't remember exactly how. Usually it shouldn't happen, but may happen if Qt can not resolve path for plugins. I don't know does it make sense to work on the problem. It is possible to check qt5-qtsvg / qt6-qtsvg package, check output with export QT_DEBUG_PLUGINS=1, set export QT_PLUGIN_PATH=somepath.

Another possibility is that there is bug in arm Qt build, but it is unlikely, not sure. Workaround would be to generate PNG icons and add an option to cmake to switch at compile time.

[issakomi]

I think the issue could be closed, as we mentioned above it would be better to publish _x8664 package now. I shall try to buy aarch64 hardware and test, probably next year. No idea about other architectures, if there are only old computers with less than 8 GB (or 4 GB at least) RAM, it does make sense for medical imaging, IMHO.

Please open an issue if you have questions or ideas. Thank you very much.

[issakomi]

I have found spec for possible alizams Fedora package

%build
export ITK_DIR=%{_libdir}/cmake/InsightToolkit
%cmake -DCMAKE_BUILD_TYPE:STRING=Release -DALIZA_QT_VERSION:STRING=5 \
  -DMDCM_USE_SYSTEM_ZLIB:BOOL=ON -DMDCM_USE_SYSTEM_OPENJPEG:BOOL=ON \
  -DMDCM_USE_SYSTEM_CHARLS:BOOL=ON -DMDCM_USE_SYSTEM_UUID:BOOL=ON \
  -DUSE_FORCE_CXX14:BOOL=ON \
  -DLIBRARY_OUTPUT_PATH=../../../../../%{_vpath_builddir}/lib
%cmake_build

Just FYI, the option _USE_FORCECXX14 doesn't exist in 1.7.0. It is highly likely not required (was a workaround to avoid warnings with Debian's ITK-4.12). If required, there is the option _ALIZA_CXXSTANDARD, possible values Not set (default), 11, 14, 17, e.g. -DALIZA_CXX_STANDARD:STRING=14.

[issakomi]

%files
%license LICENSE
%doc README.md
%{_bindir}/%{name}
%{_datadir}/applications/%{name}.desktop
%{_datadir}/metainfo/%{name}.appdata.xml
%{_datadir}/icons/hicolor/*/apps/%{name}.png
%{_datadir}/icons/hicolor/*/apps/%{name}.svg
%{_mandir}/man1/%{name}.1*
%{_libdir}/libmdcmjpeg8.so.%{so_ver}*
%{_libdir}/libmdcmjpeg12.so.%{so_ver}*
%{_libdir}/libmdcmjpeg16.so.%{so_ver}*

Files libmdcmjpeg8.so libmdcmjpeg12.so libmdcmjpeg16.so shouldn't exists, there are intermediate .a static libraries, they are linked with executable during build, no need to copy or package, there is no option to build them as shared. Just remove last 3 lines should be fine.

[Tuxino88]

%global alizams_libdir %{_prefix}/lib64/

cp -pr %{_vpath_builddir}/libs/* %{buildroot}/%{alizams_libdir}/

spec file

%global debug_package %{nil} %global alizams_libdir %{_prefix}/lib64/ Name: alizams Version: 1.7.0 Release: 1%{?dist} Summary: Aliza MS DICOM Viewer License: GPLv3 BuildRequires: cmake BuildRequires: g++ BuildRequires: libuuid-devel BuildRequires: zlib-devel BuildRequires: qt5-qtsvg-devel BuildRequires: vxl-devel BuildRequires: openjpeg2-devel >= 2.0 BuildRequires: CharLS-devel BuildRequires: cmake(LIBMINC) BuildRequires: cmake(ITK) BuildRequires: cmake(gdcm) BuildRequires: desktop-file-utils BuildRequires: git Requires: hicolor-icon-theme %description A DICOM viewer. Very fast directory scanner, DICOMDIR. 2D and 3D views with many tools. View uniform and non-uniform series in physical space. Consistently de-identify DICOM. View DICOM metadata. Ultrasound with proper measurement in regions, cine. Scout (localizer) lines. Grayscale softcopy presentation. Structured report. Compressed images. RTSTRUCT contours. Siemens mosaic format. United Imaging Healthcare (UIH) Grid / VFrame format. Elscint ELSCINT1 PMSCT_RLE1 and PMSCT_RGB1 %prep git clone --recurse-submodules https://github.com/AlizaMedicalImaging/AlizaMS.git %build cd AlizaMS export ITK_DIR=%{_libdir}/cmake/InsightToolkit %cmake -DCMAKE_BUILD_TYPE:STRING=Release \ -DALIZA_QT_VERSION:STRING=5 \ -DMDCM_USE_SYSTEM_ZLIB:BOOL=ON \ -DMDCM_USE_SYSTEM_OPENJPEG:BOOL=ON \ -DMDCM_USE_SYSTEM_CHARLS:BOOL=ON \ -DMDCM_USE_SYSTEM_UUID:BOOL=ON \ -DUSE_FORCE_CXX14:BOOL=ON \ -DLIBRARY_OUTPUT_PATH=../../../../../%{_vpath_builddir}/libs %cmake_build %install cd AlizaMS %cmake_install install -d %{buildroot}/%{alizams_libdir}/libs cp -pr %{_vpath_builddir}/libs/* %{buildroot}/%{alizams_libdir}/ %files %{_bindir}/%{name} %{_datadir}/icons/hicolor/*/apps/%{name}.png %{_datadir}/icons/hicolor/*/apps/%{name}.svg %{_datadir}/applications/%{name}.desktop %{_mandir}/man1/%{name}.1* %{alizams_libdir}/libmdcmjpeg12.so %{alizams_libdir}/libmdcmjpeg16.so %{alizams_libdir}/libmdcmjpeg8.so %{alizams_libdir}/libmdcmjpeg12.so.1.2 %{alizams_libdir}/libmdcmjpeg16.so.1.2 %{alizams_libdir}/libmdcmjpeg8.so.1.2

https://copr.fedorainfracloud.org/coprs/tuxino/Blob/build/2872238/

[issakomi]

There is no need to copy any libraries, they are either static (linked during build process) or from system.

[issakomi]

Thank you!

[issakomi]

Processing files: alizams-1.7.0-1.fc35.x86_64
Provides: alizams = 1.7.0-1.fc35 alizams(x86-64) = 1.7.0-1.fc35 application() application(alizams.desktop) libmdcmjpeg12.so.1.2()(64bit) libmdcmjpeg16.so.1.2()(64bit) libmdcmjpeg8.so.1.2()(64bit)

Still don't understand, libmdcmjpeg8/12/16.so don't exist. There is no option to build them as shared in AlizaMS. Or was cmake modified? It were not optimal, may be MDCM will be released as library one day and there will be conflict between AlizaMS and MDCM (in standalone MDCM is possible to build them as shared).

[issakomi]

The issue with empty icons seems to be present on _x8664 too, i have downloaded the Fedora 34 package from the link above and installed on new Fedora 34 in VMware. The SVG problem gone after installing qt5-qtsvg package. So may be aarch64 build is OK.

It would be nice to clarify where mdcmjpeg8/12/16.so are from, i still don't understand, it were better they shouldn't exist. I shall try to reproduce the build little later with Fedora 34 in VMware and post.

Also there is a very minor issue with not existent path for demo data sets, don't know exactly, it were possible to add a small demo data set or set empty path, i shall try.

Thank you very much!

[alcir]

qt5-qtsvg

Indeed. Installing such package, then the icons are visible also on aarch64. Maybe in the aarch64 image it is not installed by default, while in Workstation it is. Thanks.

[alcir]

Or was cmake modified?

You can see what the %cmake macro actually expands to by issuing this command: rpm -E '%cmake'

[issakomi]

You can see what the %cmake macro actually expands to by issuing this command

Thanks, yes, this forces -DBUILD_SHARED_LIBS:BOOL=ON. I shall look what could be done.

  /usr/bin/cmake \
        -S "." \
        -B "x86_64-redhat-linux-gnu" \
        -DCMAKE_C_FLAGS_RELEASE:STRING="-DNDEBUG" \
        -DCMAKE_CXX_FLAGS_RELEASE:STRING="-DNDEBUG" \
        -DCMAKE_Fortran_FLAGS_RELEASE:STRING="-DNDEBUG" \
        -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON \
        -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF \
        -DCMAKE_INSTALL_PREFIX:PATH=/usr \
        -DINCLUDE_INSTALL_DIR:PATH=/usr/include \
        -DLIB_INSTALL_DIR:PATH=/usr/lib64 \
        -DSYSCONF_INSTALL_DIR:PATH=/etc \
        -DSHARE_INSTALL_PREFIX:PATH=/usr/share \
%if "lib64" == "lib64" 
        -DLIB_SUFFIX=64 \
%endif 
        -DBUILD_SHARED_LIBS:BOOL=ON

[issakomi]

Suppressed building mdcmjpeg shared libs, i shall add later the option to use MDCM as library, this will require MDCM package, don't want currently release it, because some stuff from application have to go into the library, it is WIP. Here is updated SPEC file, worked on Fedora 34. I am not sure about line Requires: qt5-qtsvg, does it help with qt5-qtsvg issue or is it correct, please check.

%global debug_package %{nil}

Name:    alizams
Version: 1.7.1
Release: 1%{?dist}
Summary: Aliza MS DICOM Viewer
License: GPLv3
BuildRequires:  cmake
BuildRequires:  g++
BuildRequires:  libuuid-devel
BuildRequires:  zlib-devel
BuildRequires:  qt5-qtsvg-devel
BuildRequires:  openjpeg2-devel >= 2.0
BuildRequires:  CharLS-devel
BuildRequires:  vxl-devel
BuildRequires:  cmake(LIBMINC)
BuildRequires:  cmake(ITK)
BuildRequires:  cmake(gdcm)
BuildRequires:  desktop-file-utils
BuildRequires:  git
Requires:       hicolor-icon-theme
Requires:       qt5-qtsvg

%description
A DICOM viewer. Very fast directory scanner, DICOMDIR. 2D and 3D views with
many tools. View uniform and non-uniform series in physical space.
Consistently de-identify DICOM. View DICOM metadata. Ultrasound with proper
measurement in regions, cine. Scout (localizer) lines. Grayscale softcopy
presentation. Structured report. Compressed images. RTSTRUCT contours.
Siemens mosaic format. United Imaging Healthcare (UIH) Grid / VFrame format.
Elscint ELSCINT1 PMSCT_RLE1 and PMSCT_RGB1

%prep
git clone --recurse-submodules https://github.com/AlizaMedicalImaging/AlizaMS.git

%build
cd AlizaMS

%cmake -DCMAKE_BUILD_TYPE:STRING=Release \
    -DALIZA_QT_VERSION:STRING=5 \
    -DMDCM_USE_SYSTEM_ZLIB:BOOL=ON \
    -DMDCM_USE_SYSTEM_OPENJPEG:BOOL=ON \
    -DMDCM_USE_SYSTEM_CHARLS:BOOL=ON \
    -DMDCM_USE_SYSTEM_UUID:BOOL=ON \
        -DITK_DIR:PATH=%{_libdir}/cmake/InsightToolkit

%cmake_build

%install
cd AlizaMS
%cmake_install

%files

%{_bindir}/%{name}
%{_datadir}/icons/hicolor/*/apps/%{name}.png
%{_datadir}/icons/hicolor/*/apps/%{name}.svg
%{_datadir}/applications/%{name}.desktop
%{_mandir}/man1/%{name}.1*

%changelog

Edit: set version to 1.7.1

[issakomi]

There are rather ugly warnings with GCC 11 from 3rd party code. Don't see real problems. Never seen before, program is tested with Valgrind, Sypopsys coverity tool and other tools, no issues. This code is old and should be very well tested. I shall try to figure out what can i do with the mess...

/home/r/alizams/AlizaMS/b/LinearMath/btAlignedObjectArray.h:223:33: warning: ‘void* __builtin_memset(void*, int, long unsigned int)’ writing between 4 and 8589934592 bytes into a region of size 0 overflows the destination [-Wstringop-overflow=]
  223 |                                 new (&m_data[i]) T(fillData);

[issakomi]

Highly likely the warning in the post above can be ignored. Seem to be a regression in GCC

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92718

I can reproduce test code from the bug on Fedora 34.

Edit: not 100% sure, but unlikely to be a real problem, oh

[issakomi]

I have fixed the warning mentioned above. There was no problem, false alarm.

[issakomi]

Hello,

Also there is a very minor issue with not existent path for demo data sets

FYI, I have added tiny data sets (129 KB uncompressed). This requires one line in %files section of spec file. https://github.com/AlizaMedicalImaging/AlizaMS/blob/2cb1aacb3f10b272ecaf14062e4b02bbe0d8d565/fedora-34/alizams.spec#L60

Edit: Also added screenshot (package/art/alizams_scr1.jpg, 1280x720), maybe useful for package.

[issakomi]

@alcir @Tuxino88 Thank you very much! I really appreciate your work!

I have tested new SRPM package from alciregi.fedorapeople.org/alizams/ on Fedora 35. It works great! Very minor comments to cmake arguments

%cmake -DCMAKE_BUILD_TYPE:STRING=Release -DALIZA_QT_VERSION:STRING=5 \
  -DMDCM_USE_SYSTEM_ZLIB:BOOL=ON -DMDCM_USE_SYSTEM_OPENJPEG:BOOL=ON \
  -DMDCM_USE_SYSTEM_CHARLS:BOOL=ON -DMDCM_USE_SYSTEM_UUID:BOOL=ON \
  -DUSE_FORCE_CXX14:BOOL=ON \
  -DITK_DIR=%{_libdir}/cmake/InsightToolkit \
  -DLIBRARY_OUTPUT_PATH=$(pwd)/%{_vpath_builddir}/lib

• I have seen that -debuginfo package was build too. Maybe -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo could be used instead Release build type? Just an idea, you know more about packaging.
• -DUSE_FORCE_CXX14:BOOL=ON has no effect. Seems to be not required, but if you like to set C++ standard -DALIZA_CXX_STANDARD:STRING=14 can be used instead.
• Not sure -DLIBRARY_OUTPUT_PATH=$(pwd)/%{_vpath_builddir}/lib is required. But seems to work.
• BTW, there is cmake option -DCMAKE_SKIP_RPATH:BOOL=ON to skip rpath, just an idea too.

In appdata.xml

    <screenshot type="default">
      <image>https://lh6.googleusercontent.com/gIyaJlPe0i6ZnjKCt4SlshvHG1b9KItl_4DEShBjXx2d5dHXO7f_vQw-UeobzMysC-2iBAqKf03H1ooobNbTfouXoLAHE2GU6mr3hz55W62NqTGt5mmYnSSG2Cltfr9zVA=w1280</image>
    </screenshot>

The link doesn't work for me: Your client does not have permission to get URL I have added two files: https://github.com/AlizaMedicalImaging/AlizaMS/blob/master/package/art/alizams_scr1.jpg https://github.com/AlizaMedicalImaging/AlizaMS/blob/master/package/art/alizams_scr2.jpg May be they can be used as screenshots (1280x720).

Versions (optional): I have added tag v1.7.1-2 just now. There are several more warnings fixed. So it will be possible to get with git clone -b 'v1.7.1-2' https://github.com/AlizaMedicalImaging/AlizaMS.git or download https://github.com/AlizaMedicalImaging/AlizaMS/archive/refs/tags/v1.7.1-2.tar.gz (downloaded file name is AlizaMS-1.7.1-2.tar.gz). In fact you can also do just simple git clone. I will create development branch and use it till next release for clarity.

Thank you again!

[alcir]

Thank you @issakomi You can view (and comment) the review process here: https://bugzilla.redhat.com/show_bug.cgi?id=2010718

[alcir]

v1.7.1-2

For the records, in version numbers, - is not a well liked character by rpmbuild: the spec file should take care of that. (The - character in RPM world is used to separate the software version from the spec file release). https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning

BTW, there is cmake option -DCMAKE_SKIP_RPATH:BOOL=ON to skip rpath, just an idea too.

Again, I'm not a developer. But does this clash with this guideline? https://docs.fedoraproject.org/en-US/packaging-guidelines/CMake/#_notes

-DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo could be used instead Release build type?

What is the effect of this flag?

Just an idea, you know more about packaging.

Not really :-D

[issakomi]

Thank you.

For the records, in version numbers, - is not a well liked character by rpmbuild

Sure, corrected, tag is v1.7.1 (version is 1.7.1)

[issakomi]

Probably no need to worry about rpath, newer CMake seems to distinguish system paths and don't add them (as your link explains). I have checked the binary. There are no rpath records in alizams from your package: readelf -d /usr/bin/alizams |grep RUNPATH (or maybe RPATH sometimes)

Edit: but there is no harm from -DCMAKE_SKIP_RPATH:BOOL=ON, the policy doesn't like rpath

[issakomi]

There is also no need to worry about build type, i have examined Fedora package build, -g flag appears during compilation and linking. It is already "Release with debug info", probably added by rpmbuild somehow.

Your package is very good! Thank you!

The only minor issue is missing 1st screenshot. Here are files for screenshots(1280x720): https://github.com/AlizaMedicalImaging/AlizaMS/blob/master/package/art/alizams_scr1.jpg https://github.com/AlizaMedicalImaging/AlizaMS/blob/master/package/art/alizams_scr2.jpg

[issakomi]

@alcir Related to discussion on Bugzilla, here is the file with 3rd party licenses https://github.com/AlizaMedicalImaging/AlizaMS/blob/master/debian-10/copyright

Edit: @alcir updated (added Vectormath license) https://raw.githubusercontent.com/AlizaMedicalImaging/AlizaMS/development/debian-10/copyright

[issakomi]

I have commented on Bugzilla and will close this issue, it become long and difficult to read. Please open an issue if there are any questions. Thank you again! I really appreciate your help.

P.S. BTW, there are maybe a very minor issue in metadata.xml file, there are two images in one screenshot section, only the 2nd is visible. But it can be ignored.