Support #17262

Add Linux64bit-3-10-2-12 and Linux64bit-3-18-2-12 declarations of ups

Added by Kenneth Herner over 3 years ago. Updated over 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


We're seeing some 3.10.x and 3.18.x kernels with 2.12 (SL6) glibc combinations on offsite worker nodes these days, and for those experiments that set up UPS itself out of the larsoft repo (DUNE and probably others), I think it makes sense to add these new combinations too. There is of course a workaround via UPS_OVERRIDE, but since Linux64bit+3.10-2.17 is already in the larsoft repo for ups version 5_2_0, I'd argue to add these additional declarations too, since people may forget UPS_OVERRIDE and/or have future builds where they don't need to set it.


#1 Updated by Thomas Junk over 3 years ago

Yes, we would definitely like the ups version 5_2_0 with flavor Linux64bit+3.18-2.12 to be added to the LArSoft CVMFS repo in order to move to OSG workers with newer kernels.

I only see v5_1_7 in /cvmfs/ and not v5_2_0 however, but that version does have a Linux64bit-3-18-2-12 flavor.

From an e-mail from Ken Herner:

So you can either set UPS_OVERRIDE or ask whoever is in charge of the ups versions in larsoft (probably Lynn) to add Linux64bit+3.18-2.12 to the larsoft repo. Since it's already being built for the common repo I would think it's trivial to add it to larsoft.

I am not excited about putting in UPS_OVERRIDE in our setup script, as we may eventually forget about it some day when all of these kernels become old, and the larsoft setup script would need it for people who only setup larsoft anyway.

#2 Updated by Lynn Garren over 3 years ago

I need to make something very clear. A complete release with some odd flavor will not happen. That would require a complete copy of all the tarballs. Also, we expect that flavored tarballs will be built on a machine of that flavor.

ups override has been provided to deal with these sorts of situations. Please use it.

If we need better support for ups override, please ask.

#3 Updated by Lynn Garren over 3 years ago

  • Status changed from New to Feedback

We believe that there is no need for this. Updating ups in /grid/fermiapp/products/common should resolve the problem.

#4 Updated by Kenneth Herner over 3 years ago

I don't think that would completely solve the problem, though, because users who source the UPS setup script from the larsoft repo as opposed to the common repo (and/or don't set up UPS_OVERRIDE) would not pick up the change. The script in the DUNE CVMFS area never looks at the common repo; everything is from larsoft. That said, it would be a good idea to update the /grid/fermiapp (and by extension cvmfs) common repo UPS version to 5.2.

If an experiment has a working SL7 stack, I can understand not wanting to put UPS_OVERRIDE in place right now.

#5 Updated by Joe Boyd over 3 years ago

  • Assignee set to Lynn Garren
  • Priority changed from Normal to Immediate

Hi Lynn,

I sent you email on this. We need this done ASAP so we can continue testing for a rollout of a new gpgrid setup next week.

#6 Updated by Lynn Garren over 3 years ago

We are concerned about potential conflicts. Fortunately, this immediate request does not create a conflict. There is a plan for a better approach: Linux_Flavor_Change_Proposal Unfortunately, there is as yet no new release of ups and the plan has not been publicized.

The declarations are complete on /grid/fermiapp/products/larsoft. They may take a while to show up on cvmfs.

$ ups list -aK+ ups v5_2_0
"ups" "v5_2_0" "Linux64bit+2.6-2.12" "" "current" 
"ups" "v5_2_0" "Darwin64bit+13" "" "current" 
"ups" "v5_2_0" "Darwin64bit+14" "" "current" 
"ups" "v5_2_0" "Linux64bit+2.6-2.5" "" "current" 
"ups" "v5_2_0" "Linux64bit+3.10-2.17" "" "current" 
"ups" "v5_2_0" "Linux64bit+3.10-2.12" "" "current" 
"ups" "v5_2_0" "Linux64bit+3.18-2.12" "" "current" 

#7 Updated by Lynn Garren over 3 years ago

  • Status changed from Feedback to Closed
  • % Done changed from 0 to 100

Also available in: Atom PDF