fesco

#1904 Rebase `singularity` in EPEL / Fedora to upstream-supported series (2.5.x)
Closed: Fixed Opened by bbockelm.

Closed: Fixed
Reopen Issue

Hi,

I've recently been added as a new maintainer of the singularity package which is utilized at many HPC sites as a solution for providing a container runtime (it's particularly appealing as it does not require a separate daemon runtime and can function on many old kernels, including RHEL6).

The history in Fedora/EPEL is a bit long and sordid; it was added a bit prematurely and the prior maintainer didn't have time to keep apace with upstream. Particularly, it has not kept up with security patches (there have been several this year). Correspondingly, over the last year or so the communities that heavily utilize the package have quit using the Fedora version and switched to other yum/dnf repos. Particularly, the Worldwide LHC Computing Grid (WLCG) launches millions of containers per day on hundreds of thousands of cores but stopped using the EPEL6 / EPEL7 version as it is a year behind in patches. Switching to a more active maintainer team would be an opportunity to bring back these users (and to prevent productive packagers from doing duplicate work).

Long story short, I'd like permission to rebase to singularity-2.5.1 on EPEL6 / EPEL7 / F27 / F28. Here's a concrete BZ ticket requesting this:

https://bugzilla.redhat.com/show_bug.cgi?id=1585618

For singularity-2.5.1 vs 2.2.1, launching and running containers should be backward compatible, as well as the configuration file.

The biggest backward compatibility concern from 2.2.1 is the CLI options for building the container. However, I expect minimal impact here. For example, the version of the Docker API used by 2.2.1 is no longer supported by DockerHub, meaning this functionality is already broken in 2.2.1.

I'm hoping having an active packager on the Fedora side will provide leverage with upstream to pay a closer eye to backward compatibility. However, evaluating and backporting security packages far outstrips the available time. I'd like to request this one-time rebase to allow the distributions to catch up.

Many thanks for your consideration; apologies for the mess.

Brian

In order to allow the user community provide feedback on any backward compatibility / API issues, I have submitted a Bodhi update:

https://bodhi.fedoraproject.org/updates/FEDORA-2018-da87b1e643

Auto-push has been disabled pending resolution of this ticket.

I'm slightly confused why this requires FESCo approval. That might just be me though.

It's always possible I am over-parsing statements, but my reading of the updates policy is that FESCo permission should be requested if a security update has potential backward compatibility issues.

Since it was for a security item, I figured it's a good place to ask for permission rather than forgiveness here.

Let me know; I'd be happy to move forward independently if it's OK!

(edit: reformatted comment due to mail client's mauling of UTF-8 characters and line breaks)
Edited by bbockelm

For EPEL, I recommend asking the EPEL SIG as documented here: https://fedoraproject.org/wiki/EPEL_Updates_Policy#Exceptions

See also: https://fedoraproject.org/wiki/EPEL_incompatible_upgrades_policy

https://fedoraproject.org/wiki/Updates_Policy#Security_fixes does say to open a FESCo ticket for security related backwards incompatible updates, so I think it was appropriate to open this ticket.

+1, thank you for taking care of this. IMHO this does not need to stay private since there are public bug reports and updates.

@till - thanks for the +1. Unfortunately, it doesn't seem possible to upgrade from private to public. Once there are enough votes on the issue I'll summarize things on the corresponding bug reports.

Metadata Update from @till:
- Issue private status set to: False (was: True)

@bbockelm it worked for me by editing the bug's metadata, maybe it was a permission problem.

+1 too

+1 from me. Thanks for being communicative and bringing this to FESCo's attention.

+1 here as well.

Hi - what's the next step to drive this home? I don't know what's considered a quorum for FESCo. (Some of the updates are getting enough karma in Bodhi that I'm feeling ready to push them out.)

Thanks!

Quorum is 5. We're at +4 now. Maybe let's wait for the others to answer, even though I think it's unlikely that all five would be against ;)

+1

@bbockelm go ahead then

Hi all,

Many thanks for your input. I will close out this ticket and push forward on the upgrades.

Brian

Metadata Update from @bbockelm:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

(retroactive +1 from me too, sorry should have included that in my earlier comments.)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.