- openSUSE Science

Re: [opensuse-science] fftw3 and cmake broken
by Alin Marin Elena 30 Aug '19

30 Aug '19

Perfect Christian, I have something but I travel today. I will check it and let you know. Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Fri, 30 Aug 2019 at 11:49, Alin Marin Elena <alinm.elena(a)gmail.com> wrote: > > Perfect Christian, > I have something but I travel today. I will check it and let you know. > > Regards, > Alin > > On Fri, 30 Aug 2019, 11:47 Christian Goll, <cgoll(a)suse.de> wrote: >> >> On 8/29/19 1:14 PM, Alin Marin Elena wrote: >> > Hi, >> > >> > trying to use the provide fftw3 cmake files provided it fails with >> > CMake Error at /usr/lib/hpc/gnu9/fftw3/3.3.8/lib64/cmake/fftw3/FFTW3Config.cmake:13 >> > (include): >> > include could not find load file: >> > >> > /usr/lib/hpc/gnu9/fftw3/3.3.8/lib64/cmake/fftw3/FFTW3LibraryDepends.cmake >> > Call Stack (most recent call first): >> > CMakeLists.txt:7 (find_package) >> > >> > this is due to configure being used to install it. >> > solution 1: use cmake to build it so the autogenerated file is done correcty >> > solution 2: do not package cmake bits since they are broken. >> Hello Alin, >> there is also a solution3 which is a single cmake run to create the >> missing file and package it. Moving the the complete build process to >> cmake may also be possible, but this takes more time and may have side >> effects. >> As I do not have any cmake project with fftw3 dependencies so that I can >> test my solution, can you please point me to one. Or even better, can >> you please checkout the rpms from >> https://build.opensuse.org/project/show/home:mslacken:branches:multimedia:l… >> and see if cmake works there. If yes we can open a bug and push the >> changes to factory. >> >> kind regards, >> Christian -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

Re: [opensuse-science] fftw3 and cmake broken
by Egbert Eich 30 Aug '19

30 Aug '19

Alin, thanks for reporting! We are investigating. Cheers, Egbert. Alin Marin Elena writes: > Hi, > > trying to use the provide fftw3 cmake files provided it fails with > CMake Error at /usr/lib/hpc/gnu9/fftw3/3.3.8/lib64/cmake/fftw3/FFTW3Config.cmake:13 > (include): > include could not find load file: > > /usr/lib/hpc/gnu9/fftw3/3.3.8/lib64/cmake/fftw3/FFTW3LibraryDepends.cmake > Call Stack (most recent call first): > CMakeLists.txt:7 (find_package) > > this is due to configure being used to install it. > solution 1: use cmake to build it so the autogenerated file is done correcty > solution 2: do not package cmake bits since they are broken. > > Regards, > Alin > > Without Questions there are no Answers! > ______________________________________________________________________ > Dr. Alin Marin ELENA > http://alin.elena.space/ > ______________________________________________________________________ > -- > To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org > To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org > -- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] Update Available: MAT File I/O Library
by Thomas Beutlich 24 Jul '19

24 Jul '19

Hi, Matio v1.5.17 is available from https://sourceforge.net/projects/matio/files/matio/1.5.17/ Best regards, Thomas -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] Remove outdated Build Targets on network:cluster for OBS
by Egbert Eich 31 Mar '19

31 Mar '19

Hi folks! to save some build cycles I would like to remove (or at least disable) some outdated build targets for the project network:cluster: Anog these are: SEL_11_SP3 SLE_12_SP1 openSUSE_13.1 openSUSE_13.2 openSUSE_Leap_42.1 openSUSE_Leap_42.2 If they are just disabled, they may be enabled individually per package. Unless I meet strong oppostition I will start disabling them on Tuesday. I've now added SUSE:SLE-15-SP1:GA/standard as a build target. Cheers, Egbert. -- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] Unable to use update-alternatives for libopenblas_openmp
by Chris Coutinho 16 Mar '19

16 Mar '19

Hi all, I think the update-alternatives configuration set up for openblas incorrectly/incompletely overrides an alternative for libblas.so.3. Namely, the libopenblas_pthreads provides an alternative for itself (libopenblas_pthreads.so.0), but then places a link to the more generic openblas library libopenblas.so.0. This overrides the alternatives set up for libblas, and gets picked up by e.g. cmake and its FindBLAS module. In short, here you can see the options available for libblas.so.3, and my override for the openmp version: $ update-alternatives --query libblas.so.3 Name: libblas.so.3 Link: /usr/lib64/libblas.so.3 Status: manual Best: /usr/lib64/blas/libblas.so.3 Value: /usr/lib64/libopenblas_openmp.so.0 Alternative: /usr/lib64/blas/libblas.so.3 Priority: 50 Alternative: /usr/lib64/libopenblas_openmp.so.0 Priority: 20 Alternative: /usr/lib64/libopenblas_pthreads.so.0 Priority: 20 But this value is overriden by libopenblas.so.0 $ ls -l /usr/lib64/*blas* | grep alternative lrwxrwxrwx 1 root root 30 Sep 11 2018 /usr/lib64/libblas.so.3 -> /etc/alternatives/libblas.so.3 lrwxrwxrwx 1 root root 31 Sep 11 2018 /usr/lib64/libcblas.so.3 -> /etc/alternatives/libcblas.so.3 lrwxrwxrwx 1 root root 43 Sep 11 2018 /usr/lib64/libopenblas.so.0 -> /etc/alternatives/libopenblas_pthreads.so.0 CMake will favor libopenblas, which is not necessarily a problem in and of itself, but I am trying to test an openmp application and cmake gets confused. I think this is an issue in how (open)blas is packaged. Ideally, either libblas should point to any available blas implementation (including the various libopenblas options), or blas should point to a generic libopenblas.so.0, which is itself an alternative that points to the available openblas libraries. Right now it's kind of doing both, and they end up conflicting. It would be simple enough to just remove the libopenblas_pthreads alternative and have libblas be in charge of all of them. I would be happy to submit a change if I knew where to look.

2 1

[opensuse-science] Python and MPI
by Stefan Brüns 08 Mar '19

08 Mar '19

Hi everyone, Currently, Python bindings to MPI-using libraries is one of the larger omissions we currently have - these are either not build for the MPI flavors at all, or the serial and MPI flavors are conflicting, as all install into the same prefix. I have had a look around how this can be solved, and think one of the better recipes can be found in https://fedoraproject.org/wiki/Packaging:MPI https://pagure.io/packaging-committee/issue/563 https://src.fedoraproject.org/rpms/openmpi/tree/master This works in the following way: Each MPI flavor (feel free to add e.g. compilers for HPC in your mind) sets 2 environment variables, one for Python2 and one for Python3 (this *could* be extended to more Python variants). Each variable contains the prefix for the MPI specific python prefix. This prefix then *extends* the regular python search path, e.g. for Python3: --- import sys, os; s = os.getenv('MPI_PYTHON3_SITEARCH'); s and (s in sys.path or sys.path.append(s)) --- This stanza is placed in a *.pth file [1] in the regular python prefix and gets loaded automatically. In case MPI_PYTHON*_SITEARCH is not set, this is a no-op. I would like to adopt this scheme for openSUSE/SLE. If this is accepted, there are still a few open points (I will use Python3 and openMPI hereafter, without loss of generality): 1. Prefix to use 2. Additional rpm macros 3. Setting the env variables - modules vs mpi-selector 1. - Regular Python prefix is /usr, with packages living in e.g. /usr/lib64/ python3.7/site-packages. openMPI uses a prefix of /usr/lib64/mpi/gcc/openmpi/ Proposal: MPI specific packages go into /usr/lib64/mpi/gcc/openmpi/lib64/mpi/ gcc/openmpi/ This would only require the typical call to %{pyton_install} to be ammended by a '--prefix /usr/lib64/mpi/gcc/openmpi/' Note - this is different to Fedora which uses %{python_sitearch}/%{flavor} 2. - We need some additional macros here. setup.py adds a suitable path to the prefix, but this is not available currently, we need something like % {python_mpi_sitearch} e.g. for the %files sections. 3. - Our HPC mpi modules would need suitable definitions of the env variables, same for the mpivars.sh scripts. Feedback welcome. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

2 1

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 01 Mar '19

01 Mar '19

Chris Coutinho writes: > Hi Egbert, > > I've fixed all the errors that were mentioned in the log file and > cleaned up some of the rpmlnt output. Now I've submitted the package > for review. Yup. Thanks! I've seen your submission. Will wait until the build is done and take a look. One thing that we may want to address is the inclusion of the libboost. It's a bit ugly to have to define a version. This is bound to break eventually. > Thanks again for your feedback. Sure. Cheers, Egbert. > > Chris. > > On Thu, 28 Feb 2019 at 15:35, Egbert Eich <eich(a)suse.com> wrote: > > > > > > Hi Chris, > > > > Chris Coutinho writes: > > > Hi Egbert, > > > > > > Thanks for you reply and feedback. I made some adjustments to the spec > > > file and removed all the spec files - now I'm stuck at one rpmlint > > > problem keeping me above a badness value of 1000, namely the > > > 'arch-dependent-file-in-usr-share' error. > > > > > > See my project build log for the error I'm talking about. > > > > I'm seeing this: > > [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/1-var-bnds-only/var_bnds_only > > [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/2-linear-constraints/linear_constraints > > [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/3-degen-linear-constraints/degen_linear_constraints > > [...] > > > > I'd assume these files are binaries (ie have the execution flag set). > > These should not be installed in /usr/share. Instead you may want to > > consider to either move the entire structure /usr/share/dakota(/examples) > > to /usr/lib/dakota or at least do this with a subset of the files > > - like the example binaries. > > If there is no option to tell cmake to do this, you can move them > > 'manually' in the spec file afterwards. > > > > [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/librol.so > > [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchoscomm.so > > [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchoscore.so > > [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchosnumerics.so > > [...] > > > > are there also versioned so files of the same name? ie. some > > /usr/lib/librol.so.x.y.z? If so, the unversioned .so is just > > a link and should go to the devel package. > > Another issue might be that shared libraries on x86_64 should > > go to /usr/lib64/ not /usr/lib/. This is happening despite the > > %cmake macro adding these config parameters: > > -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 > > I guess you could either fix how the project uses cmake (and submit the > > patch upstream) or move things manually. > > > > [ 1436s] dakota-examples.x86_64: E: env-script-interpreter (Badness: 9) /usr/share/dakota/examples/parallelism/Case3-EvaluationTiling/OpenMPI/text_book_di_dynamic.py /usr/bin/env python > > [ 1436s] dakota-examples.x86_64: E: env-script-interpreter (Badness: 9) /usr/share/dakota/examples/script_interfaces/Python/rosenbrock_bb.py /usr/bin/env python > > [...] > > > > These things should be easy to fix. For HPC-style packages we have an RPM > > macro for it. > > > > > The binaries rpmlint is complaining about are related to the examples. > > > > Ok. > > > > > In principle, the binaries are specific to the directories they're in > > > - I don't think moving them to /usr/lib/ is really applicable. Any > > > tips? > > > > Why not? The LSB considers /usr/share as shareable among machines > > - even ones with different archiectures. /usr/lib on the other hand > > is considered arch-specific, thus it may contain arch-specific > > binaries as well. > > I haven't looked at the content of these directories, but if they > > contain data etc. that needs to live next to the binaries, you > > would have to put this into /usr/lib as well: there is nothing that > > would prevent you to put arch-independent stuff in there as well. > > > > Cheers, > > Egbert. > > > > > > > > Regards, > > > Chris > > > > > > On Thu, 28 Feb 2019 at 08:34, Egbert Eich <eich(a)suse.com> wrote: > > > > > > > > > > > > Hi Chris, > > > > > > > > Chris Coutinho writes: > > > > > 2. Currently it builds using a simple patch (known by the developers) > > > > > and ignoring all rpmlint warnings/errors. I'm assuming included packages > > > > > shouldn't just ignore all errors. What's the policy for dealing with > > > > > that? > > > > > > > > I've just looked at your package and the rpmlitrc file you've added. > > > > This file will definitely not go past the beam counters and quite a > > > > few things that ought to be fixed. > > > > > > > > These are Nonos and most are easy to fix: > > > > addFilter("dakota.* files-duplicate") > > > > addFilter("dakota.* library-without-ldconfig-postin") > > > > addFilter("dakota.* library-without-ldconfig-postun") > > > > addFilter("dakota.* no-changelogname-tag") > > > > addFilter("dakota.* non-executable-in-bin") > > > > addFilter("dakota.* non-executable-script") > > > > addFilter("dakota.* script-without-shebang") > > > > addFilter("dakota.* zero-length") > > > > addFilter("dakota.* arch-dependent-file-in-usr-share") > > > > addFilter("dakota.* devel-file-in-non-devel-package") > > > > addFilter("dakota.* env-script-interpreter") > > > > addFilter("dakota.* files-duplicated-waste") > > > > > > > > These depend, some might be false positives: > > > > addFilter("dakota.* position-independent-executable-suggested") > > > > addFilter("dakota.* shared-lib-without-dependency-information") > > > > addFilter("dakota.* shlib-policy-missing-suffix") > > > > > > > > I don't remember a single HPC/scientiffic library which doesn't > > > > trigger this - this I just ignore it: > > > > addFilter("dakota.* shared-lib-calls-exit") > > > > > > > > You may want to run: > > > > osc service run format_spec_file > > > > to sanitize your spec file. > > > > > > > > It looks like you've used the spec file from the upstream project. > > > > Unfortunately, spec files from upstream projects are not always > > > > up to the standards required by distributions. > > > > > > > > Cheers, > > > > Egbert. > > > > -- > > > > To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org > > > > To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org > > > > > > > > -- > > Egbert Eich (Res. & Dev.) SUSE LINUX GmbH > > SUSE Labs - Project Manager HPC > > Tel: +49 911-740 53 0 http://www.suse.com > > ----------------------------------------------------------------- > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) > > Maxfeldstraße 5, D90409 Nürnberg, Germany-- > > To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org > > To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org > > -- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 01 Mar '19

01 Mar '19

Hi Chris, Chris Coutinho writes: > Hi Egbert, > > Thanks for you reply and feedback. I made some adjustments to the spec > file and removed all the spec files - now I'm stuck at one rpmlint > problem keeping me above a badness value of 1000, namely the > 'arch-dependent-file-in-usr-share' error. > > See my project build log for the error I'm talking about. I'm seeing this: [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/1-var-bnds-only/var_bnds_only [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/2-linear-constraints/linear_constraints [ 1436s] dakota-examples.x86_64: E: arch-dependent-file-in-usr-share (Badness: 590) /usr/share/dakota/examples/hopspack/3-degen-linear-constraints/degen_linear_constraints [...] I'd assume these files are binaries (ie have the execution flag set). These should not be installed in /usr/share. Instead you may want to consider to either move the entire structure /usr/share/dakota(/examples) to /usr/lib/dakota or at least do this with a subset of the files - like the example binaries. If there is no option to tell cmake to do this, you can move them 'manually' in the spec file afterwards. [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/librol.so [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchoscomm.so [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchoscore.so [ 1436s] dakota.x86_64: E: devel-file-in-non-devel-package (Badness: 50) /usr/lib/libteuchosnumerics.so [...] are there also versioned so files of the same name? ie. some /usr/lib/librol.so.x.y.z? If so, the unversioned .so is just a link and should go to the devel package. Another issue might be that shared libraries on x86_64 should go to /usr/lib64/ not /usr/lib/. This is happening despite the %cmake macro adding these config parameters: -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DCMAKE_INSTALL_LIBDIR:PATH=/usr/lib64 I guess you could either fix how the project uses cmake (and submit the patch upstream) or move things manually. [ 1436s] dakota-examples.x86_64: E: env-script-interpreter (Badness: 9) /usr/share/dakota/examples/parallelism/Case3-EvaluationTiling/OpenMPI/text_book_di_dynamic.py /usr/bin/env python [ 1436s] dakota-examples.x86_64: E: env-script-interpreter (Badness: 9) /usr/share/dakota/examples/script_interfaces/Python/rosenbrock_bb.py /usr/bin/env python [...] These things should be easy to fix. For HPC-style packages we have an RPM macro for it. > The binaries rpmlint is complaining about are related to the examples. Ok. > In principle, the binaries are specific to the directories they're in > - I don't think moving them to /usr/lib/ is really applicable. Any > tips? Why not? The LSB considers /usr/share as shareable among machines - even ones with different archiectures. /usr/lib on the other hand is considered arch-specific, thus it may contain arch-specific binaries as well. I haven't looked at the content of these directories, but if they contain data etc. that needs to live next to the binaries, you would have to put this into /usr/lib as well: there is nothing that would prevent you to put arch-independent stuff in there as well. Cheers, Egbert. > > Regards, > Chris > > On Thu, 28 Feb 2019 at 08:34, Egbert Eich <eich(a)suse.com> wrote: > > > > > > Hi Chris, > > > > Chris Coutinho writes: > > > 2. Currently it builds using a simple patch (known by the developers) > > > and ignoring all rpmlint warnings/errors. I'm assuming included packages > > > shouldn't just ignore all errors. What's the policy for dealing with > > > that? > > > > I've just looked at your package and the rpmlitrc file you've added. > > This file will definitely not go past the beam counters and quite a > > few things that ought to be fixed. > > > > These are Nonos and most are easy to fix: > > addFilter("dakota.* files-duplicate") > > addFilter("dakota.* library-without-ldconfig-postin") > > addFilter("dakota.* library-without-ldconfig-postun") > > addFilter("dakota.* no-changelogname-tag") > > addFilter("dakota.* non-executable-in-bin") > > addFilter("dakota.* non-executable-script") > > addFilter("dakota.* script-without-shebang") > > addFilter("dakota.* zero-length") > > addFilter("dakota.* arch-dependent-file-in-usr-share") > > addFilter("dakota.* devel-file-in-non-devel-package") > > addFilter("dakota.* env-script-interpreter") > > addFilter("dakota.* files-duplicated-waste") > > > > These depend, some might be false positives: > > addFilter("dakota.* position-independent-executable-suggested") > > addFilter("dakota.* shared-lib-without-dependency-information") > > addFilter("dakota.* shlib-policy-missing-suffix") > > > > I don't remember a single HPC/scientiffic library which doesn't > > trigger this - this I just ignore it: > > addFilter("dakota.* shared-lib-calls-exit") > > > > You may want to run: > > osc service run format_spec_file > > to sanitize your spec file. > > > > It looks like you've used the spec file from the upstream project. > > Unfortunately, spec files from upstream projects are not always > > up to the standards required by distributions. > > > > Cheers, > > Egbert. > > -- > > To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org > > To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org > > -- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 28 Feb '19

28 Feb '19

Hi Chris, Chris Coutinho writes: > 2. Currently it builds using a simple patch (known by the developers) > and ignoring all rpmlint warnings/errors. I'm assuming included packages > shouldn't just ignore all errors. What's the policy for dealing with > that? I've just looked at your package and the rpmlitrc file you've added. This file will definitely not go past the beam counters and quite a few things that ought to be fixed. These are Nonos and most are easy to fix: addFilter("dakota.* files-duplicate") addFilter("dakota.* library-without-ldconfig-postin") addFilter("dakota.* library-without-ldconfig-postun") addFilter("dakota.* no-changelogname-tag") addFilter("dakota.* non-executable-in-bin") addFilter("dakota.* non-executable-script") addFilter("dakota.* script-without-shebang") addFilter("dakota.* zero-length") addFilter("dakota.* arch-dependent-file-in-usr-share") addFilter("dakota.* devel-file-in-non-devel-package") addFilter("dakota.* env-script-interpreter") addFilter("dakota.* files-duplicated-waste") These depend, some might be false positives: addFilter("dakota.* position-independent-executable-suggested") addFilter("dakota.* shared-lib-without-dependency-information") addFilter("dakota.* shlib-policy-missing-suffix") I don't remember a single HPC/scientiffic library which doesn't trigger this - this I just ignore it: addFilter("dakota.* shared-lib-calls-exit") You may want to run: osc service run format_spec_file to sanitize your spec file. It looks like you've used the spec file from the upstream project. Unfortunately, spec files from upstream projects are not always up to the standards required by distributions. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-science] New package: DAKOTA
by Egbert Eich 28 Feb '19

28 Feb '19

Hi Chris, Chris Coutinho writes: > Hello OpenSUSE Science, > > DAKOTA is a package developed at Sandia national labs, and used to > orchestrate numerical simulations for optimization and uncertainty > quantification. I've been using it for a while, always needing to build > it from source, and recently learned that I could actually build it on > OBS. Now that it's up there, I thought I would notify you all and > propose including it in the OpenSUSE:Science project. > > https://build.opensuse.org/package/show/home:cbcoutinho/dakota > > I have a couple questions: > > 1. Is the Science project accepting new packages? Yes. Please do 'osc sr science' from within you checked out project. There will be some review to make sure things are ok - especially, if you would like to have it in openSUSE:Factory it is important to stick the the packaging guidelines. > 2. Currently it builds using a simple patch (known by the developers) > and ignoring all rpmlint warnings/errors. I'm assuming included packages > shouldn't just ignore all errors. What's the policy for dealing with > that? Errors are an issue as they will contribute to the badness value. Warnings should be fixed, but we sometimes also see false positives I personally ignore them, you can filter them in an rpmlint script, however, this will draw the attention of the Factory reviewers, so you need to justify each filter rule. > 3. I included Python bindings and MPI by default. Does the Science > project require separate packages (e.g for with/without MPI)? This is up to you. If it can be built without MPI and there may be benefit to do this, you may want to do this as well. These days the preferred method would be to use multibuild and cover everything in a single spec file. https://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.multi… Cheers, Egbert. -- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] New package: DAKOTA
by Chris Coutinho 28 Feb '19

28 Feb '19

Hello OpenSUSE Science, DAKOTA is a package developed at Sandia national labs, and used to orchestrate numerical simulations for optimization and uncertainty quantification. I've been using it for a while, always needing to build it from source, and recently learned that I could actually build it on OBS. Now that it's up there, I thought I would notify you all and propose including it in the OpenSUSE:Science project. https://build.opensuse.org/package/show/home:cbcoutinho/dakota I have a couple questions: 1. Is the Science project accepting new packages? 2. Currently it builds using a simple patch (known by the developers) and ignoring all rpmlint warnings/errors. I'm assuming included packages shouldn't just ignore all errors. What's the policy for dealing with that? 3. I included Python bindings and MPI by default. Does the Science project require separate packages (e.g for with/without MPI)? Thanks, Chris

1 0

Re: [opensuse-science] leap 15.1
by Egbert Eich 27 Feb '19

27 Feb '19

Alin Marin Elena writes: > Hi All, > > with leap 15.1 repos being rolled shall we have one for this > http://download.opensuse.org/repositories/science:/HPC/ > > for the moment there is only one leap15 that may cause confusion. > Yes, IHMO, we should add leap 15.1 there. Nicolas, what do you think? Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

[opensuse-science] leap 15.1
by Alin Marin Elena 27 Feb '19

27 Feb '19

Hi All, with leap 15.1 repos being rolled shall we have one for this http://download.opensuse.org/repositories/science:/HPC/ for the moment there is only one leap15 that may cause confusion. Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] openmpi/libfabric
by Alin Marin Elena 18 Feb '19

18 Feb '19

Dear all, we are affected by this bug too https://bugzilla.redhat.com/show_bug.cgi?id=1408316 any chance for an update. Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 3

Re: [opensuse-science] Please add prefers for MPI variants
by Egbert Eich 15 Jan '19

15 Jan '19

Stefan Brüns writes: > Hi, > > due to the recent MPI cleanup work in science, which has reached Factory > meanwhile, there are a few new choices: > > python3-vtk: python3-vtk python3-vtk-openmpi python3-vtk-openmpi2 > netcdf13: libnetcdf13 libnetcdf13-openmpi libnetcdf13-openmpi2 > > > Please add Prefer's for the non-MPI variants. > > > Note, for netcdf there already is "Prefer: -libnetcdf13-openmpi". There is > also "(+)netcdf11", which no longer exists. This begs the question why the mpi-variants have the same provides as the non-MPI ones (apart from the libs). I do believe we need to fix the libs issue but this should not happen by adding 'Prefer:'s. For netcdf the only overlap I see is in libnetcdf.so.13()(64bit) I agree that this needs to be fixed - I didn't have time to deal with this, yet. > Btw, is there a better way to specify this, especially for versioned > libraries? I'd assume no - you'd have to specify each version separately. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-science] Non-building packages in Science and Education to be removed
by Egbert Eich 14 Jan '19

14 Jan '19

Hi Vojtěch, Vojtěch Zeisek writes: > > Well, my packaging experience is zero. My Linux experience is considerable, > but I'm not programmer. As a biologist, I'd like to see some packages > included. From the original list namely ugene. And some more, of course. I > wonder if I'd be able (by means of skills and time/effort required) to package > software I need for my work (some is not very well written). Well, now I just > compile what I need. > So... If we consider software with simple (or no) dependences, I use to follow > steps in README - (./congifue), make, (make install); is packaging in OBS > significantly more difficult...? > The short answer would be: if all you need to do is just 'configure; make; make install' it is problably not too difficult. The more in-depth answer would be: it depends - there are quite a few guidelines about the installation to be followed and make to sure that 'rpmlint' is reasonably happy, thus files may have to be moved around after a 'make install' - at least if you plan to bring the package into oS:Factory later. Generally, when you pick up an existing package most of the things have been done already - often it just to update the source tarball or fix a build. On most of the guidelines there is pretty good documentation around - like: https://en.opensuse.org/openSUSE:Package_maintainership_guide https://en.opensuse.org/openSUSE:Specfile_guidelines https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros The simplest way to get started is to start with an existing package or use a similar type of package as a guide and only worry about the documentation if there are issues. Of course, you can always ask here (there are other MLs for packaging questions, but they have a lot more traffic). Cheers, Egbert. -- Egbert Eich (Res. & Dev.) SUSE LINUX GmbH SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 http://www.suse.com ----------------------------------------------------------------- SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5, D90409 Nürnberg, Germany-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

3 4

[opensuse-science] Please add prefers for MPI variants
by Stefan Brüns 12 Jan '19

12 Jan '19

Hi, due to the recent MPI cleanup work in science, which has reached Factory meanwhile, there are a few new choices: python3-vtk: python3-vtk python3-vtk-openmpi python3-vtk-openmpi2 netcdf13: libnetcdf13 libnetcdf13-openmpi libnetcdf13-openmpi2 Please add Prefer's for the non-MPI variants. Note, for netcdf there already is "Prefer: -libnetcdf13-openmpi". There is also "(+)netcdf11", which no longer exists. Btw, is there a better way to specify this, especially for versioned libraries? Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

1 0

[opensuse-science] Non-building packages in Science and Education to be removed
by Todd Rme 04 Jan '19

04 Jan '19

Currently there are a large number of unmaintained packages that fail to build in the Science and Education repositories. They haven't been updated in years and fail to build on at least Tumbleweed, and in many cases other releases as well. There was recently a request to remove these. I will deny the requests in order to give people a chance to fix the packages. Anyone interested in any of these packages please fix them in the next 4 weeks. Any packages that are still not working on Monday, January 7 will be removed. Here is a list of failing packages: Education / HeeksART Education / HeeksCAD Education / HeeksCNC Education / MultiplicationStation Education / TuxMathScrabble Education / VUE Education / chemtool Education / fet Education / fpc-cross-i386-linux Education / freeon Education / fzclips Education / galib Education / gnome-chemistry-utils Education / graphthing Education / gtkextra2 Education / italc Education / itext Education / jMemorize Education / k3dsurf Education / kdeedu3 Education / kiwi-config-openSUSE-Edu Education / klogic Education / klogoturtle Education / koctave Education / krecipes Education / kseg Education / ksociograma Education / lenmus Education / lomse Education / moodle3_2 Education / mpqc Education / nanoxml Education / noteedit Education / open-axiom Education / opensuse-education-release Education / php5-pear-xml_parser Education / piklab Education / planets Education / plutimikation Education / release-notes-edu Education / score-reading-trainer Education / skelcd-education-desktop Education / sonic-pi Education / squidguard-blacklists Education / tablix Education / tagainijisho Education / xaralx Education / xlogo science / ASL science / CGM science / OpenVSP science / UGENE science / alberta science / arrayfire science / babel science / boxshade science / clipper science / code_saturne science / coot science / dolfin science / emboss-explorer science / engrid science / forge science / gbench science / glemon science / gnome-chemistry-utils science / ised science / keepnote science / libadjoint science / libmesh science / moab science / molekel science / mshr science / openms science / openvibe science / prank science / pyqpcr science / silo science / slepc science / superlu_dist science / tao science / taucs science / treeviewx science / vrpn science / xdrawchem science / zoltan -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

4 4

[opensuse-science] Re: [opensuse-packaging] Non-building packages in Science and Education to be removed
by Egbert Eich 03 Jan '19

03 Jan '19

Lars, Lars Vogdt writes: > Hi > > On Mon, 10 Dec 2018 10:27:09 -0500 Todd Rme wrote: > > Currently there are a large number of unmaintained packages that fail > > to build in the Science and Education repositories. They haven't been > > updated in years and fail to build on at least Tumbleweed, and in many > > cases other releases as well. > > > > There was recently a request to remove these. I will deny the > > requests in order to give people a chance to fix the packages. Anyone > > interested in any of these packages please fix them in the next 4 > > weeks. Any packages that are still not working on Monday, January 7 > > will be removed. Here is a list of failing packages: > > Can you please explain why you want to delete packages that: > * are already build disabled - and should not harm anything? > * have no other "upstream" than the Education repository? > * are not maintained by you? > > Is this kind of an ego trip that you need to do now, when everybody > else wants to enjoy his vacation? > Lars, this doesn't look like an ego trip - it is more an attempt to sanitize things. Looking at the 'sience' project which it huge cleaning up packages which have not received any attention for years may not be the worst thing to do. Of course it would be a better solution to move these packages to a separate (sub-)repository until someone gets around to fix and move them back. Unfortunately, IHMO osc still doesn't offer this. BTW: regarding: 'everybody else wants to enjoy his vacation' - sure, this is you and me: we do this for work. Some openSUSE contributors do this in their spare time and - surprise - have more spare time available during their vacation. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-science] openMPI mixup in Tumbleweed/Leap 15.x
by Egbert Eich 03 Jan '19

03 Jan '19

Stefan Brüns writes: > On Mittwoch, 2. Januar 2019 22:36:52 CET Egbert Eich wrote: [...] > > This would be a nightmare. > > As I've stated elsewhere already, I believe it would be better if > > packages that are used by the 'naive' user - and especially their > > dependencies - should stay away from using any MPI. > > I don't see the benefit of MPI if you do not specifically set it > > up for your task. I will have to look at vtk - tomorrow probably. > > The "serial" flavor, both in science and Factory, is ok now. > > The openmpi(1) flavor is somewhat broken, as the dependency set for both > openmpi1 and openmpi2 is imcomplete: > > Only available as openmpi1: > - libnetcdf-openmpi, python3-mpi4py I will take care of netcdf - once I've worked out the hdf5 issue. > Only available as openmpi2: > - boost_mpi boost is on my list of packages anyway. I cannot promise when it will happen but I'd be happy to look into this as well. > So we have to fixup the dependencies first. > > I have converted vtk to a multibuild package, see https://build.opensuse.org/ > package/show/home:StefanBruens:branches:science/vtk Cool! > As openmpi2 is seems to available on all supported platforms (even PPC64BE > since 2.1.4, science has 2.1.5), it should be a good default for everything > not buildable with multiple flavors - probably only python. Right. Nicolas also confirmed that this should work, so maybe we should go with this. > For vtk, this would mean adding an openmpi2 flavor to netcdf, and switching > mpi4py to openmpi2. Ok, lemme look into netcdf. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

Re: [opensuse-science] openMPI mixup in Tumbleweed/Leap 15.x
by Egbert Eich 03 Jan '19

03 Jan '19

Stefan Brüns writes: > Several programs will end up with implicitly linking to both versions, as > libnetcdf and hdf5 use openmpi1 and boost_mpi uses openmpi2. One example is > vtk. This would be a nightmare. As I've stated elsewhere already, I believe it would be better if packages that are used by the 'naive' user - and especially their dependencies - should stay away from using any MPI. I don't see the benefit of MPI if you do not specifically set it up for your task. I will have to look at vtk - tomorrow probably. > As both libraries (libmpi.so.12 and libmpi.so.20) export the same symbols for > large parts, this is mayhem waiting to happen. Yes! I seem to recall that there are tricks that can be done with linker flags - but I'm not even sure if they would help in this case. > For SLE, different MPI versions/implementations are supported using the HPC > modules, but for Leap/TW, we should obviously stick with *one* single > canonical version. For Leap we have the same HPC packages available as for SLE. However, these are specifically labled '-hpc' and need to be picked explicitly. They require the use of environment modules - but this should not be a problem as anyone using them will have made a consious choice to use these packages. > Question now, which version to choose? > > Apparently, openmpi2 does not work on all architectures (PPC, PPC64BE) [1], > and is not supported by some software packages [2]. > > Are there any drawbacks for using openmpi1 everywhere in TW/Leap 15.x? Besides the fact that it is unmaintained? We do not provide or support it any more on SLE-15. Right now, openmpi2 is supported there, meaning that all openmpi2 packages on Leap 15(.0) will have the benefit of receiving all the bug fixes we add to SLE. > I have opened a bug report: https://bugzilla.opensuse.org/show_bug.cgi? > id=1118861 Thanks! Cheers, Egbert.-- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1

Re: [opensuse-factory] Re: [opensuse-science] openMPI mixup in Tumbleweed/Leap 15.x
by Egbert Eich 02 Jan '19

02 Jan '19

Alin Marin Elena writes: > Since openmpi is more or less an HPC package... why don't we apply the same strategy with modules as in SLE. that will save work duplication and give extra testing to SLE. > This was my take as well - but this would require the user to use environment modules. This will work only if packages that the 'naive' user will install do not depend on other packages which require MPI. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

Re: [opensuse-science] openMPI mixup in Tumbleweed/Leap 15.x
by Egbert Eich 02 Jan '19

02 Jan '19

Todd Rme writes: > On Sat, Dec 8, 2018 at 2:53 PM Stefan Brüns > <stefan.bruens(a)rwth-aachen.de> wrote: > > > > No matter what we pick, I think it would be a good idea to do what we > do with, say, gcc and llvm/clang, where we have separate "openmpi1", > "openmpi2", and "openmpi3" packages, and have the "openmpi" package > refer to the default version. This would make it easy to change > default versions in the future, or set default versions on a > per-architecture basis. Can we ensure that once the (build)-dependency of the dummy 'openmpi' changes that all the packages that require it will be rebuilt? > As for openmpi 1 vs openmpi 2, the problem with openmpi 1 is that it > is unmaintained [1]. The current version of openmpi is actually > version 4. So using it openmpi 2 as the default comes with all the > problems associated with unmaintained software, especially > network-oriented software. openmpi 2 also adds support for MPI 3.x > features. Yes. > openmpi 2 is supposed to support PPC. If it doesn't that is probably > a bug that should be reported upstream. Unfortunately the linked > request doesn't explain what the problem is. I guess I can try and ask Andreas, the problem is that PPC and PPC64 are fringe platforms that very few people have access to or care about. At SUSE we do support openmpi2 on PPC64le on the enterprise product, but this platform is a totally different ballgame. Thus people from the PPC(64)be community would have to step in here and help. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] Re: [opensuse-factory] openMPI mixup in Tumbleweed/Leap 15.x
by Egbert Eich 02 Jan '19

02 Jan '19

Chris Coutinho writes: > For what it's worth, I use `mpi-selector` to set a system-wide MPI > implementation and then switch between them. This keeps MPI libraries > from clashing when I build software from source. > > I'm not sure if the openSUSE packages use this method, but it works for > packages I build myself really well. Are you building hdf5 and/or netcdf > yourself? Yeah, this is actually the intended approach. The problem comes in if a user installs package 'A' which requires package 'B' which in turn requires openmpi2 (for instance): the user may not even be aware of what MPI is and how it is intended to be used. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

1 0

[opensuse-science] openMPI mixup in Tumbleweed/Leap 15.x
by Stefan Brüns 14 Dec '18

14 Dec '18

Hi, I went through a few packages which have an openMPI dependency or support, and found it quite mixed up: Currently, we have openmpi(1), openmpi2 and openmpi3 in Leap and TW. While openmpi3 is currently unused, openmpi1 and openmpi2 are both used, with similar frequency: https://build.opensuse.org/package/binary/openSUSE:Factory/openmpi2:standar… standard/x86_64/openmpi2-libs-2.1.5-2.1.x86_64.rpm https://build.opensuse.org/package/binary/openSUSE:Factory/openmpi:standard/ standard/x86_64/openmpi-libs-1.10.7-21.1.x86_64.rpm Several programs will end up with implicitly linking to both versions, as libnetcdf and hdf5 use openmpi1 and boost_mpi uses openmpi2. One example is vtk. As both libraries (libmpi.so.12 and libmpi.so.20) export the same symbols for large parts, this is mayhem waiting to happen. For SLE, different MPI versions/implementations are supported using the HPC modules, but for Leap/TW, we should obviously stick with *one* single canonical version. Question now, which version to choose? Apparently, openmpi2 does not work on all architectures (PPC, PPC64BE) [1], and is not supported by some software packages [2]. Are there any drawbacks for using openmpi1 everywhere in TW/Leap 15.x? I have opened a bug report: https://bugzilla.opensuse.org/show_bug.cgi? id=1118861 Kind regards, Stefan [1] "Stay with openmpi(1) also on PPC", boost, 2018-10-01, https:// build.opensuse.org/request/show/639401 [2] "Cntk packages do not support OpenMPI 2+", https://github.com/Microsoft/ CNTK/issues/3197 -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

5 4