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
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_guidehttps://en.opensuse.org/openSUSE:Specfile_guidelineshttps://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
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
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
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
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
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
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
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