OpenMPI stack in danger (Re: Orphaned packages looking for new maintainers)
by Dominik 'Rathann' Mierzejewski
Hi!
On Monday, 25 November 2019 at 10:52, Miro Hrončok wrote:
> The following packages are orphaned and will be retired when they
> are orphaned for six weeks, unless someone adopts them. If you know for sure
> that the package should be retired, please do so now with a proper reason:
> https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
>
> Note: If you received this mail directly you (co)maintain one of the affected
> packages or a package that depends on one. Please adopt the affected package or
> retire your depending package to avoid broken dependencies, otherwise your
> package will be retired when the affected package gets retired.
>
> Request package ownership via releng issues:
> https://pagure.io/releng/issues
>
> Full report available at:
> https://churchyard.fedorapeople.org/orphans-2019-11-25.txt
> grep it for your FAS username and follow the dependency chain.
To save time looking this up, I want to direct the attention of pmix and
openmpi maintainers (Cc'd) to this chain:
munge (orphaned) -> pmix -> openmpi
In short, anything that depends on openmpi is at risk of being retired.
> Package (co)maintainers Status Change
> ================================================================================
[...]
> munge orphan 1 weeks ago
[...]
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
2 years, 10 months
Added scitech_sig to my packages
by Orion Poplawski
I have added the scitech_sig to the following packages of mine. I have
way too many packages and could use the help. Note that some of these
are foundational and have quirks or can be somewhat complex. This is
not meant to scare anyone off from helping! In fact, those are the ones
I most need help with. But start off with PRs instead of just commiting
changes perhaps? I've made a note of some of the issues below.
ast - A Library for Handling World Coordinate Systems in Astronomy
libdap - The C++ DAP2 library from OPeNDAP
bes - Back-end server software framework for OPeNDAP
These are a pair and are generally updated together.
GMT - Generic Mapping Tools
gshhg-gmt-nc4 - Global Self-consistent Hierarchical High-resolution
Geography (GSHHG)
dcw-gmt - Digital Chart of the World (DCW) for GMT
These go together as the others are the datasets used by the first.
g2clib - GRIB2 encoder/decoder and search/indexing routines in C
This uses the package version number for the soname - so all deps must
be rebuilt on each update
gdl - GNU Data Language
hdf - A general purpose library and file format for storing scientific data
hdf5 - A general purpose library and file format for storing scientific data
This is pretty foundational and changes have broken dependendent
packages. Also, you cannot update the version in a stable release - the
library has a version check in it and will not open files if running
with a different version then it was compiled for.
ncl - NCAR Command Language
nco - Suite of programs for manipulating NetCDF/HDF4 files
ncview - A visual browser for netCDF format files
netcdf - Libraries for the Unidata network Common Data Form
This is pretty foundational and changes have broken dependendent
packages. It also is highly dependent on hdf5.
netcdf4-python - Python/numpy interface to netCDF
netcdf-cxx - Legacy netCDF C++ library
netcdf-cxx4 - NetCDF-4 C++ library
netcdf-fortran - Fortran libraries for NetCDF-4
netcdf-perl - Perl extension module for scientific data access via the
netCDF API
octave - A high-level language for numerical computations
Version updates have broken dependent modules/packages so need to be
tested first.
octave-image - Image processing for Octave
octave-io - Input/Output in external formats
octave-ncarray - Access NetCDF files as a multi-dimensional array
octave-netcdf - A MATLAB compatible NetCDF interface for Octave
octave-statistics - Additional statistics functions for Octave
Many of these are inter-dependent and with other octave modules
paraview - Parallel visualization application
This is a very complicated package that takes a long time to build.
It bundles VTK so is similar to that package.
perl-Astro-FITS-CFITSIO - Perl extension for using the cfitsio library
plplot - Library of functions for making scientific plots
This is fairly complicated because it builds bindings for *LOTS* of
different languages. It is used by gdl.
lasi - C++ library for creating Postscript documents
This is a dependency of plplot
vtk - The Visualization Toolkit - A high level 3D visualization library
This fairly complicated and updates can break dependencies
wgrib - Manipulate, inventory and decode GRIB files
wgrib2 - Manipulate, inventory and decode GRIB2 files
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
3 years, 6 months
Octave-mmclab packaging query: loading mex files
by Ankur Sinha
Hiya,
I'm reviewing an octave package[1] that generates an arch specific mex
file. As I understand it, this should go to
/usr/lib64/octave/packages/%{name}-%{version} (%{octpkglibdir}), while
the other noarch files go to
/usr/share/octave/packages/%{name}-%{version} (%{octpkgdir}). This is
the case:
> drwxr-xr-x /usr/lib64/octave/packages/mmclab-1.7.9
> -rwxr-xr-x /usr/lib64/octave/packages/mmclab-1.7.9/mmc.mex
> drwxr-xr-x /usr/share/doc/octave-mmclab
> -rw-r--r-- /usr/share/doc/octave-mmclab/AUTHORS.txt
> -rw-r--r-- /usr/share/doc/octave-mmclab/README.txt
> drwxr-xr-x /usr/share/licenses/octave-mmclab
> -rw-r--r-- /usr/share/licenses/octave-mmclab/LICENSE.txt
> drwxr-xr-x /usr/share/octave/packages/mmclab-1.7.9
> -rw-r--r-- /usr/share/octave/packages/mmclab-1.7.9/besselhprime.m
> -rw-r--r-- /usr/share/octave/packages/mmclab-1.7.9/besseljprime.m
> -rw-r--r-- /usr/share/octave/packages/mmclab-1.7.9/besselyprime.m
> -rw-r--r-- /usr/share/octave/packages/mmclab-1.7.9/cart2sphorigin.m
> ...
However, @fangq (CC'd) reports that the mex file does not load in
Octave[2]. The path() in octave does not return %{octpkglibdir} either
when I check it. Could someone please point out what we're missing here?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1760617
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1760617#c28
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
3 years, 7 months
Scientific Spin marked for retirement
by Ankur Sinha
Hello,
The Scientific spin is marked for removal (please see Ben's e-mail
below). What should we do here?
- is it needed?
- if it is, do we have the resources to keep it going?
At the moment, at least from a NeuroFedora perspective, the Scientific
spin/image isn't a requirement. It's quite general purpose, so we have
our own spin/lab with specialised software that also includes a bunch of
the Scientific packages to help with analysis.
----- Forwarded message from Ben Cotton <bcotton(a)redhat.com> -----
> Date: Mon, 20 Jan 2020 15:23:14 -0500
> From: Ben Cotton <bcotton(a)redhat.com>
> To: devel-announce(a)lists.fedoraproject.org, spins(a)lists.fedoraproject.org
> CC: jvlomax(a)fedoraproject.org
> Subject: [Fedora-spins] Spins marked for retirement
>
> In keeping with FESCo's approval[1] of a keepalive requirement, the
> following Spins and Labs are marked for retirement in Fedora 32 unless
> the maintainer replies to the keepalive request or a new maintainer
> steps up.
>
> 1. Jam Audio[2] (keepalive[3])
> 2. Scientific[4] (keepalive[5])
>
> [1] https://pagure.io/fesco/issue/1972
> [2] https://fedoraproject.org/wiki/Fedora_jam
> [3] https://pagure.io/fedora-project-schedule/issue/159
> [4] https://fedoraproject.org/wiki/Scientific_Spin
> [5] https://pagure.io/fedora-project-schedule/issue/168
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> _______________________________________________
> spins mailing list -- spins(a)lists.fedoraproject.org
> To unsubscribe send an email to spins-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/spins@lists.fedoraproject.org
----- End forwarded message -----
--
Thanks,
Regards,
Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha
Time zone: Europe/London
3 years, 7 months
