Bug #15516
closedarvados-api-server and arvados-workbench packages dependent on arvados-server
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.
Updated by Ward Vandewege about 5 years ago
- Project changed from 40 to Arvados
- Status changed from New to In Progress
- Assigned To set to Ward Vandewege
Ready for review @ 2522f92cc25e55e57a31af7a59ebdbb066743445 on branch 15516-fix-arvados-server-dependencies
Updated by Ward Vandewege about 5 years ago
- Target version set to 2019-08-14 Sprint
Updated by Ward Vandewege about 5 years ago
Removed unnecessary --force-test call in build/run-build-test-packages-one-target.sh, pushed updated d823e6afbd6a2287469da909f95976da79692e72
Updated by Nico César about 5 years ago
currently running https://ci.curoverse.com/job/build-packages-ubuntu1604/1357/console
Updated by Nico César about 5 years ago
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}
Updated by Ward Vandewege about 5 years ago
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
Updated by Ward Vandewege about 5 years ago
I pushed another bugfix in 2774e45aba64557259fc35155c62988449a8dc72 and ran a successful test on jenkins (but I removed --upload and replaced it with --debug before doing so, and then reverted that): https://ci.curoverse.com/job/build-packages-ubuntu1604/1360/console
Updated by Ward Vandewege about 5 years ago
use of nameref documented in 26c7b3c97876a05ec7427bc2e5270108dcf00b17
Updated by Nico César about 5 years ago
LGTM, we should merge and watch closely a merge. I will also check the expected output with dpkg on subsequent packages.
Updated by Ward Vandewege about 5 years ago
- Status changed from In Progress to Resolved