Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @


From EGIWiki
Jump to navigation Jump to search


  • EGI repositories handover in January 2021: provider moving from IASA to IBERGRID.
    • The handover will be a complex operation due to the complexity of the repository workflows and technologies adopted. Handover preparation started with a regular meeting between IASA and IBERGRID and agreement said handover will occur in the first half of December 2020 in order to avoid the problematic end of year holiday.
    • Last released planned for November 2020.
    • During 2021 repositories will undergo a series of improvements, frontend and backend and a complete review of the procedures and workflows following a CI/CD approach.


  • UMD 4.12.0 regular release scheduled for September: -> RC running integration tests
  • UMD 5 dry run planned for, get the process ready for end of October
  • dedicated update for VOMS on UMD4/CentOS7 as soon as it's released
  • dedicated update for StoRM+BDII on UMD4/C7+SL6 before repo migration




In Verification

  • cream-blah 1.23.0
  • cvmfs 2.7.4
  • egi-cvmfs 2.6.0
  • arc6 6.8.0
  • glite-info-update-endpoints 3.0.2
  • apel-ssm 3.0.0
  • ams-library 0.5.8
  • storm 1.11.18 (1.11.17 and 1.11.16)

Under Staged Rollout


Ready to be Released

  • cvmfs 2.7.3
  • arc6 6.7.0
  • xroot 4.12.3
  • davix 0.7.6
  • gfal2 2.18.1
  • nagios-cream 1.2.5
  • nagios-plugins-egi-notebooks 0.2.4
  • nagios-probe-bdii 1.0.16


In Verification

In Staged Rollout

Ready to be released

Technical Providers - Round table






New version of DPM (1.13.2) available in EPEL

Data management clients

gfal2 2.17.0 pushed to EPEL


New Major version of SOCI in EPEL7-testing (4.0.0). FTS rebuild needed, we are discussing with the maintainer about issues that we found.

We would need to release a new FTS build for C7 when SOCI 4 will be pushed to EPEL stable.


6.8.1 is out in the Nordugrid repo. Not yet in EPEL stable.

ARC 6.8.0 and 6.8.1 is built with xrootd5. If xrootd5 is not yet in epel-stable, then if you have nordugrid-arc-plugins-xrootd installed, you must enable the epel-testing repo.





Xrootd 5.0.2 is available in EPEL testing.

Updates for all packages depending on xrootd built against xrootd 5 are also available in EPEL testing.

Major changes:

  • The old client library libXrdClient has been dropped (replacement: libXrdCl).

Minor changes:

  • The XrdSysDNS class is removed (replacement: XrdNetAddr)
  • XrdPosixXrootd::setDebug() and some other deprecated methods in that class have been dropped.

For EPEL 7 there is an xrootd-compat package providing the old xrootd 4 libraries. It is parallel installable since the sonames have changed. The compat package does not provide any devel subpackages.

Main xrootd update:

GFAL2 built against xrootd 5:

dmlite built against xrootd 5:

No update to xrootd 5 is planned for EPEL 6. The xrootd 4.12.4 update for EPEL 6 is in EPEL stable since September 19:

An xrootd 4.12.5 release is being planned, currently an RC tag exists.





v1.7.3 will be released after StoRM and VOMS releases.


StoRM v1.11.18 released.

Expected roadmap:

  • Release StoRM 1.11.19 with mainly an update for StoRM WebDAV by the end of this week.


Release v3.8.0 NOT yet released.

Tests in progress. Got positive feedback from CERN. Expected release: by 25th of September.

Packages will be released also for CentOS 7.


  • released on 2020-10-09
    • Preview 1.29.0 AppDB info (sl6): ARC 6.8.0 and 6.8.1, BDII 5.5.26, CVMFS 2.7.4, dCache 5.2.31, DMLite/DPM 1.14.0, frontier-squid 4.13.1, glite-info-update-endpoints 3.0.2, lcg-info 1.12.5, STORM 1.11.18
    • Preview 2.29.0 AppDB info (CentOS 7): ARC 6.8.0 and 6.8.1, BDII 5.5.26, CVMFS 2.7.4, dCache 5.2.31, DMLite/DPM 1.14.0, frontier-squid 4.13.1, glite-info-update-endpoints 3.0.2, lcg-info 1.12.5, STORM 1.11.18

UMD on CentOS 8

  • Plan to be defined with
    • Technical Providers
    • WLCG
    • NGIs/sites (there was 1 request so far)
    • UMD team (innovation in the process must be taken into consideration)



ARC finds it problematic that the ARC released in UMD is always so far behind the current newest release. We are considering to stop providing ARC for UMD.

The verification procedure for ARC - does it involve running ARC together with other relevant packages in the release to make sure compatibility is met?