CI: Use Docker container from crops:yocto/ubuntu-16

[okartau]

Signed-off-by: Olev Kartau olev.kartau@intel.com

[okartau]

when building in Ubuntu-14.04 container, build fails with "let: not f ound"
points to real issue?

Waiting for generation of signing key refkit-development-signing@key...
/srv/jenkins/workspace/ci-2017-07-01_14-30-15-build-1852/build/tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-gateway/1.0-r0/temp/run.do_generate_signing_keys.35867: 134: /srv/jenkins/workspace/ci-2017-07-01_14-30-15-build-1852/build/tmp-glibc/work/intel_corei7_64-refkit-linux/refkit-image-gateway/1.0-r0/temp/run.do_generate_signing_keys.35867: let: not found

[okartau]

let is bashism, and Ubuntu uses dash, right

[pohly]

@mythi, @klihub: Instead of fixing the bash dependency in refkit-signing-keys.bbclass I think we should get rid of it entirely and replace the mechanism with pre-generated keys + script for manually creating them, as suggested before. Do you agree? @klihub, can you prepare a PR for that?

[mythi]

On Mon, Jul 3, 2017 at 10:05 AM, Patrick Ohly wrote: @mythi <https://github.com/mythi>, @klihub <https://github.com/klihub>: Instead of fixing the bash dependency in refkit-signing-keys.bbclass I think we should get rid of it entirely and replace the mechanism with pre-generated keys + script for manually creating them, as suggested before. Do you agree? @klihub <https://github.com/klihub>, can you prepare a PR for that?

Makes sense, +1 from me. This would be aligned with what we're doing with other keys too.

[okartau]

switching to Ubuntu-16.04 base from crops

[okartau]

note that CI build of this does not complete, but remains hanging until aborted manually

[pohly]

sstate was again not used, Could it be that proxy settings aren't right for the internal sstate mirror under Ubuntu?

On Mon, 2017-07-10 at 11:58 -0700, okartau wrote: note that CI build of this does not complete, but remains hanging until aborted manually

Are you sure it was hanging? It was running a slow selftest (refkit_license_check.LicensingTest.test_check_computervision_licensing, suffers from lack of parallelism) but seems to have made steady progress on that right until it was aborted.

[okartau]

hm, perhaps I was too quick to abort. But two previous builds of this PR had run for 14 h amd 9.5 h without reaching end, so I made guess this has hanged (after 5.5h.) We can give it one more run and wait really long if needed.

[okartau]

About sstate: I checked connectivity while next build was running, seems OK.
I verified that in attached-to-docker-session shell using wget, I can read files from sstate.
Another cross-check: refkit server http log has entries that this builder was doing many HEAD operations and result was 200:
example:

10.237.71.144 - - [10/Jul/2017:20:25:47 +0300] "HEAD /download/bb-cache/sstate/fa/sstate%3Agnu-efi%3Acorei7-64-refkit-linux%3A3.0.5%3Ar0%3Acorei7-64%3A3%3Afaef5002cfad1f1a9222e16a4d89c335_package.tgz HTTP/1.1" 200 - "-" "Python-urllib/3.4"

Seems, bitbake can check presence get sstate files, also wget, but for some reason does not use those files.

[okartau]

I have now contradicting results about builder accessing sstate_mirror over http.
Two jobs running today morning of this PR, and both builders did not make any requests to http server,
based on server apache logs.
Again, I cross checked, atached process to docker container, that wget of sstate dir works (and gets logged in apache access log)

[okartau]

test this please, unrelated nftables error

[okartau]

test this please