Project

General

Profile

Bug #22368

Cannot do mrbsetenv on OSX with icarus_data

Added by Tracy Usher 2 months ago. Updated about 2 months ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
-
Target version:
-
Start date:
04/12/2019
Due date:
% Done:

100%

Estimated time:
Spent time:
Occurs In:
Experiment:
ICARUS
Co-Assignees:
Duration:

Description

The icarus_data package is, well, a package of various data files... probably it is outdated in the sense that there are meant to be better ways to address the problem it is solving, but it should still be possible to do a setup... As near as I can tell, the problem is that icarus_data itself has no qualifiers AND it doesn't depend on anything. Somehow the following lines in the product_deps file do not get properly parsed on OSX when doing "mrbsetenv":

# We now define allowed qualifiers and the corresponding qualifiers for the depdencies.
# Make a table by adding columns before "notes". 
qualifier     notes   
-nq-        the null qualifier matrix
end_qualifier_list

I get an obscure bash message telling me that it is expecting more information somehow. If I comment those lines out then I get a different message which is probably generated by cet build tools telling me it can't do the setup because it can't determine the qualifier.

I was able to finally get a temporary workaround by creating an artificial dependence on another package (I picked larbatch which seems harmless enough)... so changing the above lines to

# We now define allowed qualifiers and the corresponding qualifiers for the depdencies.
# Make a table by adding columns before "notes". 
qualifier     larbatch        notes   
-nq-        -nq-    the null qualifier matrix
end_qualifier_list

allows mrbsetenv to be happy and I can proceed with the build.

History

#1 Updated by Lynn Garren 2 months ago

  • Status changed from New to Feedback

mrb 3 is stricter about matching products and qualifiers. This is meant to be a good thing. Are you building icarus_data along with icaruscode or by itself? What packages are in your $MRB_SOURCE directory? We need to be able to reproduce the problem.

One workaround is to explicitly setup mrb v2 until we finish investigating.

#2 Updated by Kyle Knoepfel 2 months ago

  • Description updated (diff)

#3 Updated by Kyle Knoepfel 2 months ago

  • Assignee set to Lynn Garren
  • Status changed from Feedback to Assigned

#4 Updated by Lynn Garren 2 months ago

  • Assignee deleted (Lynn Garren)

This is interesting. Within a few minor cleanups, the structure of icarus_data is the same as the structure of larutils. The difference is that icaruscode depends on icarus_data. When building the larsoft product suite, there is no product that depends on larutils and we have no problems with mrbsetenv.

This problem can be reproduced with the instructions below. I have provided a feature branch that reproduces the original problem. It also contains a few minor cleanups.

make a new mrb working directory
cd $MRB_SOURCE
mrb g icaruscode
mrb g icarusutils
mrb g icarus_data
cd icarus_data
git checkout feature/team_investigate_22368
cd $MRB_BUILDDIR
(mrb z if necessary)
mrbsetenv

#5 Updated by Lynn Garren 2 months ago

I should have noted that this problem is not limited to macOS. It is also reproducible on SLF7.

#6 Updated by Christopher Green 2 months ago

  • % Done changed from 0 to 100
  • Assignee set to Christopher Green
  • Status changed from Assigned to Resolved

This problem is resolved with mrb:69b01a8 for mrb v3_01_02.

Despite the workaround being to change the icarus_data ups/product_deps file, the actual problem was with the way mrb v3 was reading the icaruscode ups/product_deps file, which listed icarus_data as a dependency.

One of the changes that came with mrb 3 was the ability to specify -nq- in the third column of a non-only_for_build dependency's product/version table and omit the column from the qualifier matrix table entirely: the table_format should be specified on the product/version table's header line thus:

product   version         <table_format=2>

Unfortunately, when the unqualified dependency was part of the mrb development set, the mrb 2 way of specifying an unqualified non-only_for_build dependency was broken (if the dependency was found as an installed UPS product everything worked).

So, your choices are:

  1. Use mrb 2.
  2. Use mrb 3 >= v3_01_02.
  3. Change the icaruscode ups/product_deps file as described above and use mrb 3.

Note that in all three of your alternatives above, the existing workaround of having an otherwise-unnecessary qualifier table in icarus_data's ups/product_deps file is unnecessary and may be removed.

#7 Updated by Lynn Garren 2 months ago

  • % Done changed from 100 to 0
  • Assignee deleted (Christopher Green)

mrb v3_01_02 is now installed on cvmfs.

#8 Updated by Lynn Garren 2 months ago

  • % Done changed from 0 to 100

#9 Updated by Kyle Knoepfel about 2 months ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF