Bug #15516
closed
arvados-api-server and arvados-workbench packages dependent on arvados-server
Added by Peter Amstutz over 5 years ago.
Updated almost 5 years ago.
Release relationship:
Auto
Description
arvados-api-server and arvados-workbench both have a hard dependency on arvados-server, which they use to read the new arvados config file. When installing or upgrading, arvados-server must be installed or upgraded before arvados-api-server post-install or service startup scripts are run. Base on the pattern of breakage on the dev clusters, this doesn't seem to be happening.
- Project changed from 40 to Arvados
- Status changed from New to In Progress
- Assigned To set to Ward Vandewege
- Target version set to 2019-08-14 Sprint
I see:
00:10:31.428 Error: /tmp/tmp.MuRDh1DKom/bin/arvados-client=/usr/bin/arvados-client: Unable to figure out package name from fpm results:
00:10:31.428
00:10:31.429 {:timestamp=>"2019-08-12T17:54:53.807627+0000", :message=>"Invalid package configuration: Cannot package the path '/tmp/tmp.MuRDh1DKom/bin/arvados-client', does it exist?", :level=>:error}
Nico César wrote:
I see:
00:10:31.428 Error: /tmp/tmp.MuRDh1DKom/bin/arvados-client=/usr/bin/arvados-client: Unable to figure out package name from fpm results:
00:10:31.428
00:10:31.429 {:timestamp=>"2019-08-12T17:54:53.807627+0000", :message=>"Invalid package configuration: Cannot package the path '/tmp/tmp.MuRDh1DKom/bin/arvados-client', does it exist?", :level=>:error}
That was caused by a genuine bug in the new code. The govendor call in calculate_go_package_version() generates STDOUT when it is downloading data (but not when it doesn't have to do anything), and that output was returned with the result of calculate_go_package_version(). Meh, bash, yuck, functions returning data via stdout...
I've switched calculate_go_package_version() to take a variable name as part of its command line, and then set that variable to the output from the function. This uses a bash 4.3+ feature called namerefs. This way, any stdout generated in calculate_go_package_version() won't corrupt the value it returns anymore, which avoids future problems of this type. I've given the get_complete_package_name() function the same treatment.
Fix pushed in 366a2efdd0ac4630f4381f3b47d70ef155ed2df4
LGTM, we should merge and watch closely a merge. I will also check the expected output with dpkg on subsequent packages.
- Status changed from In Progress to Resolved
Also available in: Atom
PDF