There are at least two options that come to mind. One may or may not be possible.
Can you describe the complete details of your value list setup? A screen shot of the appropriate dialog box may be a good way to do that.
One option that I know will work, but which requires great care, is to change your calculation field into a text field with an auto-entered calculation. This field will be indexed, but will no longer update automatically when you modify data in the relatd Zips_spec table. The solution is to use script triggers on any layouts where this data can be modified that perform a script to update this field for any relatd records that match to it. But if you miss even one such spot in your database design, you risk this field not accurately reflecting the related spec data.
The option that may work is to go ahead and specify this unstored calculation field and ignore the warning message. But that only works if specific options for the value list are NOT selected and the resulting value list may not look and function the way that you'd like.
Here's how my value lists are build.
'Zip size' is my first value list which is my conditional valuelist, and 'zip' is my value list in my BOM.
is "size" the unstored calculation field?
If so, unless you are trying to use size as a match field in a relationship, you can ignore the warning message and your value list should still work.
Here's the little known fact on which I am basing this suggestion:
"use values from a field" based value lists must refer to at least one indexed field. But the other field, whether specified for column1 or column 2 does not have to be an indexed field as long as:
It's not the secondary field and "Show values only from second field" is selected.
The unindexed field is not specified in the "sort values using:" setting.