- openSUSE Science

Re: Project wide OpenMPI ABI breakage for SLE/Leap 15
by Egbert Eich 26 Oct '23

26 Oct '23

Hi Nicolas, Nicolas Morey writes: > On 10/26/23 19:01, Egbert Eich wrote: > > Stefan Brüns writes: > > > Hi, > > > > > > the recent removal of OpenMPI 1/2/3 from the science project has broken the > > > ABI. > > > > > > On SLE/LEAP 15, "openmpi" always meant OpenMPI 1, while suddenly it has become > > > OpenMPI 4. Anyone using packages from the science project will end up with > > > packages which are linked to either openmpi1 or openmpi4, and an application > > > may pull in both at the same time - obviously not a good idea. > > > > > > So, can this please be fixed ASAP, before too many users are hit by this? > > > > Ok, I see the problem now. Leap has inherited from earlier versions all > > outdated openmpi1 packages which were denoted as 'openmpi'. Other than > > SLE, Leap does not drop any packages, so recycling the term 'openmpi' > > for the default OpenMPI version causes havoc. > > So even if we denote the default OpenMPI version for *build* purposes, > > it should never be be used for package naming and dependencies - here the > > explicit version should always be specified (or 'openmpi' for OpenMPI v1). > > @Nicolas, could you look into this? > > > > Cheers, > > Egbert. > > > There is no "openmpi" package. > There is a "Provides: openmpi- %{version}" for the package that is the current default (right now openmpi4). On a Leap 15.4 I get: zypper search openmpi | grep " openmpi " [...] | mpitests-openmpi | MPI Benchmarks and tests for openmpi | package | openmpi | A powerful implementation of MPI | package | openmpi-debuginfo | Debug information for package openmpi | package | openmpi-debugsource | Debug sources for package openmpi > As stated in my other email, this has been the case for over 4 years ! > The right way to build against the default openMPI version is what is done in hpx: > - BuildRequires: openmpi-macros-devel > - Use %{openmpi_requires} and %{openmpi_devel_requires} in right packages to force a dependency to the right version (not just a libmpi.so.XX one) > - %{setup_openmpi} in the %build/%install section to setup the openMPI path/ld_library_path and so on Yes, this is true - for the future, but not the past - you cannot change the past. The past is what'son Leap 15.n - anything that was shipped since Leap 15.0. Example (on Leap 15.4): zypper info --requires parallel-netcdf-openmpi-devel [...] Requires : [3] parallel-netcdf-devel-data openmpi-devel libpnetcdf1-openmpi = 1.7.0 Here, you have an unversioned dependency to openmpi-devel. > If there are (not _multibuild) packages that do not use these macros, they > should be changed to use them. For this to happen, you will have to rebuild a considerable portion of the packages you no longer want to deal with. If Leap 15.6 will acquire your packages, you will see a lot of conflicts from these old packages. > I thought I caught all of them when openmpi1 was renamed in Factory but there may be some non Factory one that I missed and luckily kept working since them. Factory may be fine if everything has been rebuilt with your macros. Leap still contains packages that pre-date your fixes. SLE may be Ok because we hopefully do not ship these old packages any more. Cheers, Egbert.

2 1

Re: Project wide OpenMPI ABI breakage for SLE/Leap 15
by Egbert Eich 26 Oct '23

26 Oct '23

Stefan Brüns writes: > Hi, > > the recent removal of OpenMPI 1/2/3 from the science project has broken the > ABI. > > On SLE/LEAP 15, "openmpi" always meant OpenMPI 1, while suddenly it has become > OpenMPI 4. Anyone using packages from the science project will end up with > packages which are linked to either openmpi1 or openmpi4, and an application > may pull in both at the same time - obviously not a good idea. > > So, can this please be fixed ASAP, before too many users are hit by this? Ok, I see the problem now. Leap has inherited from earlier versions all outdated openmpi1 packages which were denoted as 'openmpi'. Other than SLE, Leap does not drop any packages, so recycling the term 'openmpi' for the default OpenMPI version causes havoc. So even if we denote the default OpenMPI version for *build* purposes, it should never be be used for package naming and dependencies - here the explicit version should always be specified (or 'openmpi' for OpenMPI v1). @Nicolas, could you look into this? Cheers, Egbert.

2 1

Project wide OpenMPI ABI breakage for SLE/Leap 15
by Stefan Brüns 26 Oct '23

26 Oct '23

Hi, the recent removal of OpenMPI 1/2/3 from the science project has broken the ABI. On SLE/LEAP 15, "openmpi" always meant OpenMPI 1, while suddenly it has become OpenMPI 4. Anyone using packages from the science project will end up with packages which are linked to either openmpi1 or openmpi4, and an application may pull in both at the same time - obviously not a good idea. So, can this please be fixed ASAP, before too many users are hit by this? Regards, Stefan

2 1

Mass addition of python packages
by Stefan Brüns 08 Aug '23

08 Aug '23

During the last two days, there was a mass addition of linked package from devel:languages:python to the science project. I think it is quite bad this was neither discussed nor announced here. I also think this is plain wrong: 1. d:l:p is not meant as a base project for other projects, but as a devel project 2. in case it was meant to fill in some missing packages for Leap 15, d:l:p:backports would have been a better choice 3. The packages from d:l:p often require a python > 3.6, so many won't build on Leap anyway 4. For Tumbleweed, linking and rebuilding the packages from d:l:p is rather pointless and wasteful - we get more rebuilds, and longer rebuilds Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019

1 0

Leave
by Slawomir Siejka 31 Jul '22

31 Jul '22

Empty Message

1 0

Re: Unannounced change of shlib-policy-name-error rpmlint strictness on TW
by Stefan Brüns 14 Jul '22

14 Jul '22

On Donnerstag, 14. Juli 2022 14:34:27 CEST Richard Biener wrote: > On Thu, 14 Jul 2022, Stefan Brüns wrote: > > Hi, > > > > a few days ago any violation of shlib-policy-name-error has become a fatal > > error. > > > > This is especially problematic for many packages in the science > > repository, > > when packages are built as flavors for e.g. openmpi2/3/4, and the library > > packages carry a corresponding suffix. E.g.: > > > > libhdf5-103-openmpi4.x86_64: E: shlib-policy-name-error (Badness: 10000) > > SONAME: libhdf5.so.103 > > (/usr/lib64/mpi/gcc/openmpi4/lib64/libhdf5.so.103.3.1), expected package > > suffix: 103 > > > > This is a case not covered by https://en.opensuse.org/ > > openSUSE:Shared_library_packaging_policy > > > > Can this please be reverted until the policy has been extended to cover > > these cases? Preferably, rpmlint learns to understand this pattern. > > The policy wasn't originally supposed to apply to shared libraries > that do not reside in the default runpath which means > /usr/lib*/$package/... should have been excempted. Possibly the > implementation doesn't reflect that or the implementation > is too narrow? > > IIRC there's also a whitelist(?) - the GCC package excempts itself > via rpmlintrc filtering the check ... > > Richard. In the current code I can not find such a generic exemption. Of course one can add an exemption via rpmlintrc. I would prefer not do so: 1. There are probably about 50 source packages in science alone affected by this. 2. Each rpmlintrc entry bears the risk of hiding actual packaging errors. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019

1 0

Unannounced change of shlib-policy-name-error rpmlint strictness on TW
by Stefan Brüns 14 Jul '22

14 Jul '22

Hi, a few days ago any violation of shlib-policy-name-error has become a fatal error. This is especially problematic for many packages in the science repository, when packages are built as flavors for e.g. openmpi2/3/4, and the library packages carry a corresponding suffix. E.g.: libhdf5-103-openmpi4.x86_64: E: shlib-policy-name-error (Badness: 10000) SONAME: libhdf5.so.103 (/usr/lib64/mpi/gcc/openmpi4/lib64/libhdf5.so.103.3.1), expected package suffix: 103 This is a case not covered by https://en.opensuse.org/ openSUSE:Shared_library_packaging_policy Can this please be reverted until the policy has been extended to cover these cases? Preferably, rpmlint learns to understand this pattern. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

1 0

Re: RFC: Proper automatic library dependencies for MPI/serial flavors
by Egbert Eich 05 Jul '22

05 Jul '22

Hi Stefan, Stefan Brüns writes: > Hi everyone, > > we have a reocurring problem with multiple providers of libraries built as > serial and openMPI(1-4)/MVAPICH/... flavors. > > Currently, both the serial and e.g. openMPI4 flavors provide the exact same > resolvables, e.g. "libsundials_sunlinsolklu.so.4.2.0()(64bit)" [1]. This is > then manually fixed up on a case-by-case basis by manually specifying the > default package. > > Fedora solves this problem by adding the MPI flavor to the resolvable, e.g. > "libfoo.so()(64bit)(openmpi-x86_64)". For details, see [2][3]. > > I would propose for (open)SUSE to follow this notation, and finally get rid > of the manual workarounds. Indeed, this problem is not new and I believe we've talked about this some years ago already. We had the same with HPC packages as well, we 'solved' it by replacing the dependency generator by one that would ignore any dependencies pointing into the HPC directories (/usr/lib/hpc) and adding dependencies manually. I had the plan to resolve it the way you've suggested adding more 'attribute tags' do the dependency to specify it with greater detail. This of course wasn't the real solution, just a workaround. I never found time to do the real solution. So indeed, if Fedora has a solution for this already (at least for the MPI problem, for HPC packages there are further challanges), we should take this into consideration. Thanks for picking this up again! Cheers, Egbert. > > Kind regards, Stefan > > > [1] https://build.opensuse.org/package/binary/science/sundials:openmpi4/ > openSUSE_Tumbleweed/x86_64/libsundials4-openmpi4-6.2.0-19.1.x86_64.rpm > > [2] https://fedoraproject.org/wiki/Changes/RpmMPIReqProv > [3] https://packages.fedoraproject.org/pkgs/rpm-mpi-hooks/rpm-mpi-hooks/ > index.html > -- Egbert Eich (Res. & Dev.) SUSE Labs - Architect HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Ivo Totev (HRB 36809, AG Nürnberg)

1 0

RFC: Proper automatic library dependencies for MPI/serial flavors
by Stefan Brüns 05 Jul '22

05 Jul '22

Hi everyone, we have a reocurring problem with multiple providers of libraries built as serial and openMPI(1-4)/MVAPICH/... flavors. Currently, both the serial and e.g. openMPI4 flavors provide the exact same resolvables, e.g. "libsundials_sunlinsolklu.so.4.2.0()(64bit)" [1]. This is then manually fixed up on a case-by-case basis by manually specifying the default package. Fedora solves this problem by adding the MPI flavor to the resolvable, e.g. "libfoo.so()(64bit)(openmpi-x86_64)". For details, see [2][3]. I would propose for (open)SUSE to follow this notation, and finally get rid of the manual workarounds. Kind regards, Stefan [1] https://build.opensuse.org/package/binary/science/sundials:openmpi4/ openSUSE_Tumbleweed/x86_64/libsundials4-openmpi4-6.2.0-19.1.x86_64.rpm [2] https://fedoraproject.org/wiki/Changes/RpmMPIReqProv [3] https://packages.fedoraproject.org/pkgs/rpm-mpi-hooks/rpm-mpi-hooks/ index.html

1 0

Re: openblas setup screwed in science project
by Egbert Eich 05 May '22

05 May '22

Atri Bhattacharya writes: > On Wed, 2022-05-04 at 14:19 +0200, Stefan Brüns wrote: > > > > Hi Egbert, > > > > Another problem with openblas is the missing .baselibs configuration > > for 32bit > > packages. Some time ago it was still there, but then went missing > > without a > > mention in the changelog. This breaks at least arpack-ng. > > > > At least for TW, i586 (actully, somthing like P4) is still supported, > > and for > > any library package still working on i586 we should also have the > > baselibs > > configuration (IMHO). > > > > > > Related to this, I am trying to restore the baselibs.conf to openblas, > see WIP at > <https://build.opensuse.org/package/show/home:badshah400:branches:science/op… > >. That's fine, especially since you are creating it dynamically ;) You may have to specify the library files by hand as lib(64)?/ contains only links. The real libraries live in lib(64)?/openblas-<flavor>. Cheers, Egbert. > > Optionally, I made an sr to obs://science/arpack-ng to disable the - > 32bit bi-arch package generation in > <https://build.opensuse.org/request/show/974867> > but feel free to decide whether to decline this and accept the changes > to openblas (in a future sr) instead. > > Best wishes, > > > -- > Atri Bhattacharya -- Egbert Eich (Res. & Dev.) SUSE Labs - Architect HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Ivo Totev (HRB 36809, AG Nürnberg)

2 1

Re: openblas setup screwed in science project
by Egbert Eich 04 May '22

04 May '22

Hi Stefan, Stefan Brüns writes: > On Freitag, 8. April 2022 16:08:01 CEST Stefan Brüns wrote: > > Hi, > > > > someone has apparently disabled *all* builds for openblas. > > > > Whats the reason for this? > > > > As openblas 0.3.20 was never built inside science, we now have 0.3.20 in > > Factory and 0.3.17 (binary packages) in science. This causes a lot of > > unresolvables, as OBS tries to use openblas 0.3.17 from science. > > > > Kind regards, > > > > Stefan > > Hi Egbert, > > as you are the de-facto maintainer of openblas, can you shed some light here? > > Another problem with openblas is the missing .baselibs configuration for 32bit > packages. Some time ago it was still there, but then went missing without a > mention in the changelog. This breaks at least arpack-ng. > > At least for TW, i586 (actully, somthing like P4) is still supported, and for > any library package still working on i586 we should also have the baselibs > configuration (IMHO). I'm not aware that I've thrown these out. On the packages I've worked on, I've converted the static baselibs.conf files to static ones as there was no good way to use static baselibs.conf file for all the different flavors - moreover, I don't want these 32bit binaries for HPC anyway. I've looked back, the version where I've claimed I added these, did not have it. Going further back I wasn't able to find any static baselibs.conf either, which makes me believe there was never any. I personally do not care for 32-bit libraries, neither professionally nor personally - at least for openblas. I had my fair share of openblas - the upgrade to 0.3.20 gave me some grief - and I do not want to invest any more time on topics that are of no interest for me. If you feel like a baselibs.conf setup is useful and want to create one *and* maintain it, please feel free. There were some breakages introduced thru my changes - which I've hopefully rectified, they had nothing to do with a missing baselibs.conf. These issues should disappear from Factory as the fix has been accepted last night. I have no idea who disabled build of openblas in science. It wasn't me - at least not intentionally. On the bright sight, switching between netlib-lapack and openblas should be possible, now. Cheers, Egbert. > > Kind regards, > > Stefan > > -- > Stefan Brüns / Bergstraße 21 / 52062 Aachen > home: +49 241 53809034 mobile: +49 151 50412019 > -- Egbert Eich (Res. & Dev.) SUSE Labs - Architect HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Ivo Totev (HRB 36809, AG Nürnberg)

1 0

openblas setup screwed in science project
by Stefan Brüns 04 May '22

04 May '22

Hi, someone has apparently disabled *all* builds for openblas. Whats the reason for this? As openblas 0.3.20 was never built inside science, we now have 0.3.20 in Factory and 0.3.17 (binary packages) in science. This causes a lot of unresolvables, as OBS tries to use openblas 0.3.17 from science. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

2 2

Some new scientific packages for molecular biology
by Vojtěch Zeisek 26 Nov '21

26 Nov '21

Hi, I decided not to be that much lazy and when I need to compile some software (mostly for molecular biology, genetics, ...), I package it. So far it is in https://build.opensuse.org/project/show/home:vojtaeus but I think it could be useful to submit them to https://build.opensuse.org/project/show/science but I'm still bit beginner with packaging (and biologist, not programmer), so I'm not sure if I follow all best-practice guidelines and so... Anyway, can I just do such a "mass submission" of my packages into science? Is there any special procedure? Any review? I suppose I'm then maintainer of the packages, but not of whole science repository...? There are still issues with some packages I don't know how to solve now: https://build.opensuse.org/package/show/home:vojtaeus/bamtools - I'm not sure if I'm correctly handling shared library and don't really get why it works for TW, but fails for 15.2 and 15.3... Similarly I fail with BEAGLE library (not in OBS), which should add extra support for MrBayes. https://build.opensuse.org/package/show/home:vojtaeus/bandage - I wonder if it fails for 15.2 due to "ERROR: No sufficient Category definition" and "Errors in installed desktop file detected.". Is this so different comparing to 15.3 and TW? Hint in build log doesn't really help me... :-/ I was also bit confused when looking into various Qt applications by diversity of usage of BuildRequires tags, but I hope I package it correctly... :-) https://build.opensuse.org/package/show/home:vojtaeus/bwa - I don't really get why it fails for i586 TW, but it's probably unimportant. ;-) https://build.opensuse.org/package/show/home:vojtaeus/seaview - I wonder if failures for 15.2 and 15.3 are due to errors in desktop file (which works for TW). Also, it is supposed to deliver HTML help file, which I think I package correctly (well, lines 48 and 49 of spec file can be probably dropped, the don't do what I was hoping for), but it fails to find it. Interestingly, when I packaged the RPM locally with this spec file, it can find the help, but not when I do it in OBS... I have also list of things in Java, Maven, bazel, and more which I'd like to add. Especially with thinks like IGV, GATK or Picard I don't really have any idea, how to compile it... We'll see :-) So can I just submit what I have into science, or am I supposed to undergo some sophisticated procedure? :-) Yours, V. -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/

1 0

Re: [opensuse-science] openmpi3 pulled as dep
by Egbert Eich 22 Oct '20

22 Oct '20

Hi Nicolas! Nicolas Morey-Chaisemartin writes: > > > Le 10/22/20 à 10:57 AM, Egbert Eich a écrit : > > > > Hi Nicolas, > > > > Nicolas Morey-Chaisemartin writes: > > > > > > > > > Is this available or all MPI flavors? If so, we could just do a: > > BuildRequires: %{mpi}-macros-devel > > > > No it's only for openmpi* packages at the moment. Ok, if you can fix this for mpich and mvapich we can integrate this into more packages. I'd be easier if we were able to do things the same way for all MPI flavors. > > The define of %mpi should be avaiable to the build dependency > > script as it doesn't depend on other macro packages. > > If this is the case I will make adjustments when visiting packages > > again. > > > > > It'll provide the macros: > > > %setup_openmpi # (Load the orpper mpivars.sh) > > > %openmpi_requires # ( Add the right Requires:..... for the openmpi package) > > > %openmpi_devel_requires # same but for devel packages) > > > > > > Also for using the "default" version of openmpi (currently openmpi2), you can juste BuildRequires: openmpi-macros-devel. > > > It'll pull the macros from the default version so there is no need to specify which one and it can be changed more easily when we decide to go to openmpi 3 or 4 by default. > > > > Right. Ok, this should work as well - if 'openmpi' stands for > > 'openmpi-default' instead of 'openmpi1' it'd be fine. Right. > It does. That's the reason openmpi was renamed to openmpi1 > > We will > > build for openmpi2 twice then: once for 'default' and once for > > it explicitly and we don't build for openmpi1 at all. But maybe > > people don't care any more ... > > > > You probably don't need that. The default flavor is mostly for package which don't really care which one they use (stuff like boost and other core libs) but you need all of them to use the same one. > It was introduced as there was a huge mess of some libs building against openmpi1, some against openmpi2 so the stack wasn't working. > Package like lapack where the pick of flavor might matter should build against all, not necesseraly against the default one. Yes. I would think for many of the packages in science this is true. With multibuild this will be quite easy - one does not necessarily need all the HPC stuff with full environment module support. 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

1 0

Re: [opensuse-science] openmpi3 pulled as dep
by Egbert Eich 22 Oct '20

22 Oct '20

Hi Nicolas, Nicolas Morey-Chaisemartin writes: > > > Le 10/21/20 à 9:58 AM, Nicolas Morey-Chaisemartin a écrit : > > > > > > Le 10/21/20 à 9:35 AM, Egbert Eich a écrit : > >> > >> Hi Alin, > >> > >> please specify what system you are using (Leap<version>, Tumbleweed ...). > >> It seems you are mixing HPC (openmpi4-gnu-hpc-devel) and non-HPC packages. > >> Moreover, there is no scalapack-openmpi4 (not even among the non-HPC > >> packages). > >> > >> There is a bit of a problem with MPI depenendencies with non-HPC packages. > >> It seems like both openmpi3 and 4 provide libmpi.so.40()(64bit). > >> @Nicolas - is this correct? > > > > Yes they do. > > But in theory, packages depending on a specific MPI version like this should > > require the right openmpi, not just the libmpi.so Yes, this is what we do for the HPC versions. We even strip these 'generic' library dependencies from the list using our own dependency generator. > > WHich lapack does not seem to be doing/ > > BuildRequires: %{mpi_flavor}%{?mpi_ext}-devel > > > > It's only a BuildRequires but a > > Requires: %{mpi_flavor}%{?mpi_ext}-libs is also needed. > > Scratch some of that (it works but there is a newer/better way) > openmpi* packages were cleaned up some time back. > What should be done for all openmpi (at least non hpc) dependant packages is: > BuildRequires: openmpi<N>-macros-devel Ok. Is this available or all MPI flavors? If so, we could just do a: BuildRequires: %{mpi}-macros-devel The define of %mpi should be avaiable to the build dependency script as it doesn't depend on other macro packages. If this is the case I will make adjustments when visiting packages again. > It'll provide the macros: > %setup_openmpi # (Load the orpper mpivars.sh) > %openmpi_requires # ( Add the right Requires:..... for the openmpi package) > %openmpi_devel_requires # same but for devel packages) > > Also for using the "default" version of openmpi (currently openmpi2), you can juste BuildRequires: openmpi-macros-devel. > It'll pull the macros from the default version so there is no need to specify which one and it can be changed more easily when we decide to go to openmpi 3 or 4 by default. Right. Ok, this should work as well - if 'openmpi' stands for 'openmpi-default' instead of 'openmpi1' it'd be fine. We will build for openmpi2 twice then: once for 'default' and once for it explicitly and we don't build for openmpi1 at all. But maybe people don't care any more ... Thanks! Cheers, Egbert. > > Nicolas > > > > > > > Nicolas > > > >> > >> For the HPC variants this has been fixed. > >> If both openmpi3 and openmpi4 provide the libmpi.so.4 ABI, then you > >> will have to install openmpi4-libs explicitly, I'm afraid - or use > >> the HPC variant of scalapack. > >> > >> Cheers, > >> Egbert. > >> > >> Alin Marin Elena writes: > >> > Hi. > >> > > >> > I try to install openmpi4 but somehow openmpi3 is pulled see below. > >> > > >> > drFaustroll@circassia:~> sudo zypper in scalapack-openmpi4 > >> > openmpi4-gnu-hpc-devel > >> > Problem retrieving files from 'oneAPI'. > >> > Permission to access > >> > 'https://yum.repos.intel.com/oneapi/media.1/media' denied. > >> > Please see the above error message for a hint. > >> > Warning: Skipping repository 'oneAPI' because of the above error. > >> > Some of the repositories have not been refreshed because of an error. > >> > Loading repository data... > >> > Reading installed packages... > >> > 'scalapack-openmpi4' not found in package names. Trying capabilities. > >> > Resolving package dependencies... > >> > > >> > The following 31 NEW packages are going to be installed: > >> > gcc-c++ gnu-compilers-hpc gnu-compilers-hpc-devel infiniband-diags > >> > libfabric1 libibmad5 libibnetdisc5 libibumad3 libinfinipath4 > >> > libopenmpi_4_0_5-gnu-hpc > >> > libpsm2-2 libpsm_infinipath1 libscalapack2-openmpi4 libucm0 libucp0 > >> > libucs0 libuct0 lua53 lua53-luafilesystem lua53-luaposix lua53-luaterm > >> > lua-lmod > >> > mpi-selector openmpi3 openmpi3-libs openmpi_4_0_5-gnu-hpc > >> > openmpi_4_0_5-gnu-hpc-devel openmpi4-config openmpi4-gnu-hpc-devel > >> > rdma-core-devel rsocket > >> > > >> > The following recommended package was automatically selected: > >> > openmpi4-config > >> > > >> > 31 new packages to install. > >> > > >> > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- 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] openmpi3 pulled as dep
by Egbert Eich 21 Oct '20

21 Oct '20

Hi Alin, please specify what system you are using (Leap<version>, Tumbleweed ...). It seems you are mixing HPC (openmpi4-gnu-hpc-devel) and non-HPC packages. Moreover, there is no scalapack-openmpi4 (not even among the non-HPC packages). There is a bit of a problem with MPI depenendencies with non-HPC packages. It seems like both openmpi3 and 4 provide libmpi.so.40()(64bit). @Nicolas - is this correct? For the HPC variants this has been fixed. If both openmpi3 and openmpi4 provide the libmpi.so.4 ABI, then you will have to install openmpi4-libs explicitly, I'm afraid - or use the HPC variant of scalapack. Cheers, Egbert. Alin Marin Elena writes: > Hi. > > I try to install openmpi4 but somehow openmpi3 is pulled see below. > > drFaustroll@circassia:~> sudo zypper in scalapack-openmpi4 > openmpi4-gnu-hpc-devel > Problem retrieving files from 'oneAPI'. > Permission to access > 'https://yum.repos.intel.com/oneapi/media.1/media' denied. > Please see the above error message for a hint. > Warning: Skipping repository 'oneAPI' because of the above error. > Some of the repositories have not been refreshed because of an error. > Loading repository data... > Reading installed packages... > 'scalapack-openmpi4' not found in package names. Trying capabilities. > Resolving package dependencies... > > The following 31 NEW packages are going to be installed: > gcc-c++ gnu-compilers-hpc gnu-compilers-hpc-devel infiniband-diags > libfabric1 libibmad5 libibnetdisc5 libibumad3 libinfinipath4 > libopenmpi_4_0_5-gnu-hpc > libpsm2-2 libpsm_infinipath1 libscalapack2-openmpi4 libucm0 libucp0 > libucs0 libuct0 lua53 lua53-luafilesystem lua53-luaposix lua53-luaterm > lua-lmod > mpi-selector openmpi3 openmpi3-libs openmpi_4_0_5-gnu-hpc > openmpi_4_0_5-gnu-hpc-devel openmpi4-config openmpi4-gnu-hpc-devel > rdma-core-devel rsocket > > The following recommended package was automatically selected: > openmpi4-config > > 31 new packages to install. > > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

3 3

[opensuse-science] openmpi3 pulled as dep
by Alin Marin Elena 21 Oct '20

21 Oct '20

Hi. I try to install openmpi4 but somehow openmpi3 is pulled see below. drFaustroll@circassia:~> sudo zypper in scalapack-openmpi4 openmpi4-gnu-hpc-devel Problem retrieving files from 'oneAPI'. Permission to access 'https://yum.repos.intel.com/oneapi/media.1/media' denied. Please see the above error message for a hint. Warning: Skipping repository 'oneAPI' because of the above error. Some of the repositories have not been refreshed because of an error. Loading repository data... Reading installed packages... 'scalapack-openmpi4' not found in package names. Trying capabilities. Resolving package dependencies... The following 31 NEW packages are going to be installed: gcc-c++ gnu-compilers-hpc gnu-compilers-hpc-devel infiniband-diags libfabric1 libibmad5 libibnetdisc5 libibumad3 libinfinipath4 libopenmpi_4_0_5-gnu-hpc libpsm2-2 libpsm_infinipath1 libscalapack2-openmpi4 libucm0 libucp0 libucs0 libuct0 lua53 lua53-luafilesystem lua53-luaposix lua53-luaterm lua-lmod mpi-selector openmpi3 openmpi3-libs openmpi_4_0_5-gnu-hpc openmpi_4_0_5-gnu-hpc-devel openmpi4-config openmpi4-gnu-hpc-devel rdma-core-devel rsocket The following recommended package was automatically selected: openmpi4-config 31 new packages to install. 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] Re: Change Leap/SLE Build Targets from *:GA to *:Update
by Egbert Eich 14 Sep '20

14 Sep '20

Adrian Schröter writes: > On Montag, 14. September 2020, 11:34:26 CEST Egbert Eich wrote: > > > > Hi! > > > > I would like to change the Leap and SLE build targets of project 'science' > > from *:GA to *:Update for Leap 15.0/SLE-15 and later versions/service packs. > > > > This allows packages to be based on new or fixed packages which have > > been updated after the release. > > > > Are there any objections to this? > > question is why this is needed at build time, since the packages in :Update > are supposed to be fully backward compatible at runtime at least. Apart from issues that we have discovered and fixed since. It doesn't happen often and should not happen but I remember cases - especially around building. > Are you sure you do not hide some other issue by that? Also, new packages are not available in :GA. Cheers, Egbert. > > -- > > Adrian Schroeter <adrian(a)suse.de> > Build Infrastructure Project Manager > > SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany > (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer > > > -- Egbert Eich (Res. & Dev.) SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- 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] Change Leap/SLE Build Targets from *:GA to *:Update
by Egbert Eich 14 Sep '20

14 Sep '20

Hi! I would like to change the Leap and SLE build targets of project 'science' from *:GA to *:Update for Leap 15.0/SLE-15 and later versions/service packs. This allows packages to be based on new or fixed packages which have been updated after the release. Are there any objections to this? Cheers, Egbert. -- Egbert Eich (Res. & Dev.) SUSE Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- 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 4
by Egbert Eich 20 Jul '20

20 Jul '20

Hi Alin, sorry, I was extremely busy - even over the weekend. So it took me a while. Alin Marin Elena writes: > Hi, > > I fail miserable for fftw3 > https://build.opensuse.org/package/show/home:ealin:branches:multimedia:libs… > for a reason seems to still use openmpi3... and I do not see the error. > > can anyone have a look and pinpoint the issue please? I've found typo in the spec file which was not at all related to your changes. If you don't mind I will fix this and add your patch to my changes. Thanks for pointing out this issue! Cheers, Egbert. > > > Alin > Without Questions there are no Answers! > ______________________________________________________________________ > Dr. Alin Marin ELENA > http://alin.elena.space/ > ______________________________________________________________________ > > On Tue, 23 Jun 2020 at 19:39, Egbert Eich <eich(a)suse.com> wrote: > > > > > > Hi Alin, > > > > Alin Marin Elena writes: > > > Hi, > > > > > > I see openmpi 4 is nicely in the science and hpc packages but nothing > > > else seems to be built against it. > > > > > > Is there any reason why we do not build against openmpi4? > > > > Well, mostly time, I'd guess - thing with higher priority. > > > > As sonn as I find time, I will do it - unless someone beats > > me to it ;) > > > > Cheers, > > Egbert. > > > > > > > > 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 Labs - Project Manager HPC > > Tel: +49 911-740 53 0 https://www.suse.com > > ----------------------------------------------------------------------- > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg > > Geschaeftsfuehrer: Felix Imendoerffer > > (HRB 36809, AG Nürnberg) > > -- > > To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org > > To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org > > > -- > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- 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 4
by Egbert Eich 16 Jul '20

16 Jul '20

Alin Marin Elena writes: > Hi, > > added openmp4 to scalapack > sr 821233 > > there are some failures due to -fallow-argument-mismatch being applied > to versions of gcc that do not support it. > Thanks! Unfortunately, a changelog entry was missing. I've caught this too late. I've added a note the the changelog together another fix I was going to make. 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 4
by Egbert Eich 16 Jul '20

16 Jul '20

Hi Alin, Alin Marin Elena writes: > Hi, > > I see openmpi 4 is nicely in the science and hpc packages but nothing > else seems to be built against it. > > Is there any reason why we do not build against openmpi4? Well, mostly time, I'd guess - thing with higher priority. As sonn as I find time, I will do it - unless someone beats me to it ;) Cheers, Egbert. > > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 2

Re: [opensuse-science] openmpi 4
by Egbert Eich 16 Jul '20

16 Jul '20

Hi Alin, Alin Marin Elena writes: > got this one rejected... and i fail to see any comment > > https://build.opensuse.org/request/show/816818 > There actually is one: ----------------------------- badshah400 wrote 7 days ago Thanks for the sr. However, this: %if !0%{?is_opensuse} && 0%{?sle_version:1} && 0%{?sle_version} < 150200 && 0%{?suse_version} == 1500 %define DisOMPI4 ExclusiveArch: do_not_build %endif seems to not disable build for Leap, if that is the intention (gauging from the .changes entry). The -openmpi4 builds for Leap are unresolvable rather than excluded. ----------------------------- To fix this, you may want to - remove !0%{?is_opensuse} - change 0%{?sle_version} < 150200 to 150300 ^^^^^^ Sorry, I missed this! Thanks, Cheers, Egbert. > Alin > > Without Questions there are no Answers! > ______________________________________________________________________ > Dr. Alin Marin ELENA > http://alin.elena.space/ > ______________________________________________________________________ > > On Tue, 23 Jun 2020 at 20:08, Egbert Eich <eich(a)suse.com> wrote: > > > > > > Hi! > > > > Alin Marin Elena writes: > > > I can start looking into it if you point me to the dev repos to branch > > > from them. > > > > Thanks for the offer! > > > > Most relevant libraries would be in this project: > > https://build.opensuse.org/project/show/science > > The following packages in there use MPI and are > > 'environment module aware': > > scalapach > > petsc > > hdf5 > > netcdf > > netcdf-fortran > > adios > > mumps > > scotch > > hypre > > trilinos > > > > There are a few packages from other projects: > > > > multimedia:libs fftw3 > > science:HPC mpiP > > science:HPC imb > > > > > > > as far as I remember we shall just add one more option in a config file. > > > > Yes, almost. > > The job is fairly straight forward, not to say boring: > > you'd probably duplicate the openmpi3 setup in the spec file > > and _multibuild file. > > Some spec files may have macros to individually disable openmpi > > versions - you may want to duplicate these for openmpi4 as well, > > probably. > > > > If you want me to review, you may want to start with one and I will look > > it over once you've submitted it. > > > > Thanks! > > > > Cheers, > > Egbert. > > > > > > > > Regards, > > > Alin > > > > > > Without Questions there are no Answers! > > > ______________________________________________________________________ > > > Dr. Alin Marin ELENA > > > http://alin.elena.space/ > > > ______________________________________________________________________ > > > > > > On Tue, 23 Jun 2020 at 19:39, Egbert Eich <eich(a)suse.com> wrote: > > > > > > > > > > > > Hi Alin, > > > > > > > > Alin Marin Elena writes: > > > > > Hi, > > > > > > > > > > I see openmpi 4 is nicely in the science and hpc packages but nothing > > > > > else seems to be built against it. > > > > > > > > > > Is there any reason why we do not build against openmpi4? > > > > > > > > Well, mostly time, I'd guess - thing with higher priority. > > > > > > > > As sonn as I find time, I will do it - unless someone beats > > > > me to it ;) > > > > > > > > Cheers, > > > > Egbert. > > > > > > > > > > > > > > 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 Labs - Project Manager HPC > > > > Tel: +49 911-740 53 0 https://www.suse.com > > > > ----------------------------------------------------------------------- > > > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg > > > > Geschaeftsfuehrer: Felix Imendoerffer > > > > (HRB 36809, AG Nürnberg) > > > > -- > > > > 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 Labs - Project Manager HPC > > Tel: +49 911-740 53 0 https://www.suse.com > > ----------------------------------------------------------------------- > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg > > Geschaeftsfuehrer: Felix Imendoerffer > > (HRB 36809, AG Nürnberg) > > -- > > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- 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 4
by Egbert Eich 01 Jul '20

01 Jul '20

Hi! Alin Marin Elena writes: > I can start looking into it if you point me to the dev repos to branch > from them. Thanks for the offer! Most relevant libraries would be in this project: https://build.opensuse.org/project/show/science The following packages in there use MPI and are 'environment module aware': scalapach petsc hdf5 netcdf netcdf-fortran adios mumps scotch hypre trilinos There are a few packages from other projects: multimedia:libs fftw3 science:HPC mpiP science:HPC imb > as far as I remember we shall just add one more option in a config file. Yes, almost. The job is fairly straight forward, not to say boring: you'd probably duplicate the openmpi3 setup in the spec file and _multibuild file. Some spec files may have macros to individually disable openmpi versions - you may want to duplicate these for openmpi4 as well, probably. If you want me to review, you may want to start with one and I will look it over once you've submitted it. Thanks! Cheers, Egbert. > > Regards, > Alin > > Without Questions there are no Answers! > ______________________________________________________________________ > Dr. Alin Marin ELENA > http://alin.elena.space/ > ______________________________________________________________________ > > On Tue, 23 Jun 2020 at 19:39, Egbert Eich <eich(a)suse.com> wrote: > > > > > > Hi Alin, > > > > Alin Marin Elena writes: > > > Hi, > > > > > > I see openmpi 4 is nicely in the science and hpc packages but nothing > > > else seems to be built against it. > > > > > > Is there any reason why we do not build against openmpi4? > > > > Well, mostly time, I'd guess - thing with higher priority. > > > > As sonn as I find time, I will do it - unless someone beats > > me to it ;) > > > > Cheers, > > Egbert. > > > > > > > > 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 Labs - Project Manager HPC > > Tel: +49 911-740 53 0 https://www.suse.com > > ----------------------------------------------------------------------- > > SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg > > Geschaeftsfuehrer: Felix Imendoerffer > > (HRB 36809, AG Nürnberg) > > -- > > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 2

Re: [opensuse-science] fftw3 wrong module dep on gnu-10
by Egbert Eich 24 Jun '20

24 Jun '20

Alin Marin Elena writes: > Hi, > > fftw3 provides the wrong dep on tumbleweed > > rpm -ql libfftw3_3_3_8-gnu-hpc > .... > /usr/share/lmod/moduledeps/gnu-9/fftw3 > /usr/share/lmod/moduledeps/gnu-9/fftw3/.version.3.3.8 > /usr/share/lmod/moduledeps/gnu-9/fftw3/3.3.8 > > I looked in multimedia:fftw3 but i fail to see any issue, i wonder if > there is a macro going astray. Are you referring to that this still is using gcc9 although we have gcc10 in TW already? There was likely an issue with a dependency somewhere so that gcc10 version has not been built yet. This should be ok now - fftw3 has built with gcc10 in oS:Factory: https://build.opensuse.org/package/show/openSUSE:Factory/fftw3 The library package from there correctly has: ... /usr/share/lmod/moduledeps/gnu-10/fftw3 /usr/share/lmod/moduledeps/gnu-10/fftw3/.version.3.3.8 /usr/share/lmod/moduledeps/gnu-10/fftw3/3.3.8 ... So the next TW update should have this fixed. Cheers, Egbert. > > 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 Labs - Project Manager HPC Tel: +49 911-740 53 0 https://www.suse.com ----------------------------------------------------------------------- SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg Geschaeftsfuehrer: Felix Imendoerffer (HRB 36809, AG Nürnberg) -- To unsubscribe, e-mail: opensuse-science+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-science+owner(a)opensuse.org

2 1