January 2019 - openSUSE Science - openSUSE Mailing Lists

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 03 Jan '19

03 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 03 Jan '19

03 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 03 Jan '19

03 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

2022

2021

2020

2019

2018

2017

openSUSE Science January 2019