stage1: update coreos image to 1097.0.0

[lucab]

This is needed for a recent enough version of libseccomp (2.3.0), with support for
new syscalls (eg. getrandom).

[jonboulle]

Nice catch. LGTM on green.

Luca Bruno notifications@github.com schrieb am Do., 7. Juli 2016, 19:36:

This is needed for a recent enough version of libseccomp (2.3.0), with
support for

new syscalls (eg. getrandom).

You can view, comment on, or merge this pull request online at:

#2884
Commit Summary

• stage1: update coreos image to 1097.0.0

File Changes

• M stage1/usr_from_coreos/coreos-common.mk
  https://github.com/coreos/rkt/pull/2884/files#diff-0 (2)

Patch Links:

• https://github.com/coreos/rkt/pull/2884.patch
• https://github.com/coreos/rkt/pull/2884.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#2884, or mute the thread
https://github.com/notifications/unsubscribe/ACewNzis9fSGQDSuxyreWiZE-nUV6OA2ks5qTTkmgaJpZM4JHUjp
.

[lucab]

It would be a good idea to re-push it as soon as jenkins is back to see if it introduces regressions.

[s-urbaniak]

Semaphore failed with

Files listed in /home/runner/rkt/builds/build-rkt-kvm/build-rkt-1.10.0+git/tmp/usr_from_kvm/cbu/manifest.txt are missing from /home/runner/rkt/builds/build-rkt-kvm/build-rkt-1.10.0+git/tmp/coreos-common/usr.squashfs:
lib64/libgcrypt.so.20.0.3
lib64/libseccomp.so.2.1.1

[lucab]

@s-urbaniak yes, I also need to double check arm64 now as they have different versions and we don't have any CI to cover us on that 😞. I guess it will slip to tomorrow.

[glevand]

@lucab For now it should be enough that the travis arm64 build is ok. That will detect if versions of existing dependencies have changed.

I don't think it would be too too difficult to setup a CI loop running rkt in qemu for arm64, but I guess it would take some work to get the actual rkt tests to support arm64.

[lucab]

For now it should be enough that the travis arm64 build is ok. That will detect if versions of existing dependencies have changed.

I'm not sure I've correctly understood this. My concern is that travis only builds [host, fly] flavors, so I don't see how it can spot changed libraries in coreos. For a real example, with this alpha update on aarch64 there is a libgcrypt.so.11.8.3 to libgcrypt.so.20.0.5 bump which I just spotted manually, and travis is not saying anything about that.

[lucab]

PTAL. It should be fine now on both amd64/arm64.

[iaguis]

PTAL. It should be fine now on both amd64/arm64.

How did you check arm64?

[lucab]

How did you check arm64?

squashfs inspection and ldd on a private box. Not the whole testsuite, if you were asking about that.

[iaguis]

squashfs inspection and ldd on a private box. Not the whole testsuite, if you were asking about that.

Yep, thanks!

[iaguis]

LGTM on green.

[jonboulle]

@lucab perhaps I'm missing something dumb but shouldn't the libseccomp shared objects be there for arm too?

[lucab]

@jonboulle yes it should, but it looks like there is no libseccomp.so in current coreos release (it is not present in current squashfs root). This also explains why libseccomp is currently not on the install list for arm64 stage1-coreos.