bottlerocket-os / bottlerocket-sdk Goto Github PK
View Code? Open in Web Editor NEWA software development kit for Bottlerocket
License: Other
bottlerocket-sdk's People
Contributors
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
Stargazers
Watchers
Forkers
bcressey iliana heinrichsmythe jdoss shyamalschandra tjkirch jpculp zmrow mycpuorg arnaldo2792 somnusfish devteamcharlie stmcginnis 0x32c2cac3info jpmcb mjsterckx yeazelm markusboehme cbgbt etungsten sumukhballal ginglis13 larvaceabottlerocket-sdk's Issues
Go update requires build changes
Issue or Feature Request:
The kubernetes project now builds with Go 1.21.4. In attempting to update the SDK to use a matching version, it looks like there has been some changes to the Go build process that now result in errors during the build:
=> ERROR [sdk-go 8/9] RUN export GOARCH="${!GOARCH_ARCH}" ; export CC="${TARGET}-gcc" ; export CC_FOR_TARGET="${TARGET}-gcc" ; export CC_FO 23.8s
------
> [sdk-go 8/9] RUN export GOARCH="${!GOARCH_ARCH}" ; export CC="${TARGET}-gcc" ; export CC_FOR_TARGET="${TARGET}-gcc" ; export CC_FOR_${GOOS}_${GOARCH}="${TARGET}-gcc" ; export CXX="${TARGET}-g++" ; export CXX_FOR_TARGET="${TARGET}-g++" ; export CXX_FOR_${GOOS}_${GOARCH}="${TARGET}-g++" ; export GOFLAGS="-mod=vendor" ; go install std cmd && go install -buildmode=pie std cmd:
4.527 # cmd/cgo/internal/test/issue8828
4.527 cgo-gcc-prolog: In function '_cgo_cd757160f43e_Cfunc_foo':
4.527 cgo-gcc-prolog:47:33: warning: unused variable '_cgo_a' [-Wunused-variable]
12.86 # cmd/cgo/internal/test
12.86 In file included from _cgo_export.c:4:
12.86 cgo_thread_lock.go:14:13: error: 'Ctid' defined but not used [-Werror=unused-function]
12.86 cc1: note: unrecognized command-line option '-Wno-unknown-warning-option' may have been intended to silence earlier diagnostics
12.86 cc1: all warnings being treated as errors
------
Dockerfile:489
--------------------
488 | GO111MODULE="auto"
489 | >>> RUN \
490 | >>> export GOARCH="${!GOARCH_ARCH}" ; \
491 | >>> export CC="${TARGET}-gcc" ; \
492 | >>> export CC_FOR_TARGET="${TARGET}-gcc" ; \
493 | >>> export CC_FOR_${GOOS}_${GOARCH}="${TARGET}-gcc" ; \
494 | >>> export CXX="${TARGET}-g++" ; \
495 | >>> export CXX_FOR_TARGET="${TARGET}-g++" ; \
496 | >>> export CXX_FOR_${GOOS}_${GOARCH}="${TARGET}-g++" ; \
497 | >>> export GOFLAGS="-mod=vendor" ; \
498 | >>> go install std cmd && \
499 | >>> go install -buildmode=pie std cmd
500 |
--------------------
ERROR: failed to solve: process "/bin/sh -c export GOARCH=\"${!GOARCH_ARCH}\" ; export CC=\"${TARGET}-gcc\" ; export CC_FOR_TARGET=\"${TARGET}-gcc\" ; export CC_FOR_${GOOS}_${GOARCH}=\"${TARGET}-gcc\" ; export CXX=\"${TARGET}-g++\" ; export CXX_FOR_TARGET=\"${TARGET}-g++\" ; export CXX_FOR_${GOOS}_${GOARCH}=\"${TARGET}-g++\" ; export GOFLAGS=\"-mod=vendor\" ; go install std cmd && go install -buildmode=pie std cmd" did not complete successfully: exit code: 1
make: *** [Makefile:16: sdk] Error 1
It's possible we just need some different build flags, but requires further investigation.
add software to the sdk to support twoliter
Description
Add the following things to the bottlerocket-sdk:
-
cargo make -
cargo deny -
docker(the CLI only, not the daemon) - Bottlerocket's RPM macros
- Bootconfig data files
Definition of Done
When the above items have been added to the SDK.
Depends on:
id: texec_sdk
epic: twoliter_exec
Related to bottlerocket-os/bottlerocket#2669
STEP 80: libunwind build fails
Building fails with the following error when using the devel branch or v0.10.1 tag.
STEP 73: RUN install -p -m 0644 -Dt ${SYSROOT}/usr/share/licenses/musl COPYRIGHT
STEP 74: ARG LLVMVER="9.0.0"
STEP 75: USER builder
STEP 76: WORKDIR /home/builder
STEP 77: COPY ./hashes/libunwind ./hashes
STEP 78: RUN sdk-fetch hashes && tar xf llvm-${LLVMVER}.src.tar.xz && rm llvm-${LLVMVER}.src.tar.xz && mv llvm-${LLVMVER}.src llvm && tar xf libunwind-${LLVMVER}.src.tar.xz && rm libunwind-${LLVMVER}.src.tar.xz && mv libunwind-${LLVMVER}.src libunwind && mkdir libunwind/build
++ awk -F '[ ()]' '/^SHA512 \(/ {
printf "https://cache.bottlerocket.aws/%s/%s/%s\n", $3, $6, $3
}' hashes
+ curl --fail --remote-name-all --remote-time https://cache.bottlerocket.aws/llvm-9.0.0.src.tar.xz/1bb3341e1d231559b948f1505b33c2e2e03989f9b8bbfef0e0cdaff5ac43f85574c9ec5ac53399b914f497d6899425d861411024e8d7e1d1a338c1c6951ac658/llvm-9.0.0.src.tar.xz https://cache.bottlerocket.aws/libunwind-9.0.0.src.tar.xz/55b44439b76638a7c5ea25dd3713a3f6a2d54bcfb7bf34d3388753f0d25be2e843b5f05dc1c0052d7a9cd5a141c6818f4da42bc9174a16d89e819ea262ad5706/libunwind-9.0.0.src.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 31.4M 100 31.4M 0 0 20.2M 0 0:00:01 0:00:01 --:--:-- 20.2M
100 90372 100 90372 0 0 186k 0 --:--:-- --:--:-- --:--:-- 1495k
+ sha512sum --check hashes
llvm-9.0.0.src.tar.xz: OK
libunwind-9.0.0.src.tar.xz: OK
STEP 79: WORKDIR /home/builder/libunwind/build
STEP 80: RUN cmake -DLLVM_PATH=../../llvm -DLIBUNWIND_ENABLE_SHARED=1 -DLIBUNWIND_ENABLE_STATIC=1 -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_C_COMPILER="${TARGET}-gcc" -DCMAKE_C_COMPILER_TARGET="${TARGET}" -DCMAKE_CXX_COMPILER="${TARGET}-g++" -DCMAKE_CXX_COMPILER_TARGET="${TARGET}" -DCMAKE_AR="/usr/bin/${TARGET}-ar" -DCMAKE_RANLIB="/usr/bin/${TARGET}-ranlib" .. && make unwind
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- Check for working C compiler: /usr/bin/x86_64-bottlerocket-linux-gnu-gcc
-- Check for working C compiler: /usr/bin/x86_64-bottlerocket-linux-gnu-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/x86_64-bottlerocket-linux-gnu-g++
-- Check for working CXX compiler: /usr/bin/x86_64-bottlerocket-linux-gnu-g++ -- broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:53 (message):
The C++ compiler
"/usr/bin/x86_64-bottlerocket-linux-gnu-g++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /home/builder/libunwind/build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/gmake cmTC_8142a/fast && /usr/bin/gmake -f CMakeFiles/cmTC_8142a.dir/build.make CMakeFiles/cmTC_8142a.dir/build
gmake[1]: Entering directory '/home/builder/libunwind/build/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_8142a.dir/testCXXCompiler.cxx.o
/usr/bin/x86_64-bottlerocket-linux-gnu-g++ -O2 -g -Wp,-D_GLIBCXX_ASSERTIONS -fstack-clash-protection -o CMakeFiles/cmTC_8142a.dir/testCXXCompiler.cxx.o -c /home/builder/libunwind/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
Linking CXX executable cmTC_8142a
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_8142a.dir/link.txt --verbose=1
/usr/bin/x86_64-bottlerocket-linux-gnu-g++ -O2 -g -Wp,-D_GLIBCXX_ASSERTIONS -fstack-clash-protection -Wl,-z,relro -Wl,-z,now CMakeFiles/cmTC_8142a.dir/testCXXCompiler.cxx.o -o cmTC_8142a
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: warning: libc.so.6, needed by /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1, not found (try using -rpath or -rpath-link)
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `memset@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `strlen@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `realloc@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `calloc@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `dl_iterate_phdr@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `malloc@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `abort@GLIBC_2.2.5'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `memcpy@GLIBC_2.14'
/usr/lib/gcc/x86_64-bottlerocket-linux-gnu/9/../../../../x86_64-bottlerocket-linux-gnu/bin/ld: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/libgcc_s.so.1: undefined reference to `free@GLIBC_2.2.5'
collect2: error: ld returned 1 exit status
gmake[1]: *** [CMakeFiles/cmTC_8142a.dir/build.make:87: cmTC_8142a] Error 1
gmake[1]: Leaving directory '/home/builder/libunwind/build/CMakeFiles/CMakeTmp'
gmake: *** [Makefile:121: cmTC_8142a/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:19 (project)
-- Configuring incomplete, errors occurred!
See also "/home/builder/libunwind/build/CMakeFiles/CMakeOutput.log".
See also "/home/builder/libunwind/build/CMakeFiles/CMakeError.log".
Error: error building at STEP "RUN cmake -DLLVM_PATH=../../llvm -DLIBUNWIND_ENABLE_SHARED=1 -DLIBUNWIND_ENABLE_STATIC=1 -DCMAKE_INSTALL_PREFIX="/usr" -DCMAKE_C_COMPILER="${TARGET}-gcc" -DCMAKE_C_COMPILER_TARGET="${TARGET}" -DCMAKE_CXX_COMPILER="${TARGET}-g++" -DCMAKE_CXX_COMPILER_TARGET="${TARGET}" -DCMAKE_AR="/usr/bin/${TARGET}-ar" -DCMAKE_RANLIB="/usr/bin/${TARGET}-ranlib" .. && make unwind": error while running runtime: exit status 1
make: *** [Makefile:8: bottlerocket-sdk-x86_64-v0.10.2.tar.gz] Error 125
Update musl to 1.2.2
create toolchain archive from SDK
For best results we need out-of-tree kernel modules to be compiled with the same toolchain that we use to build Bottlerocket.
However, since those builds will happen inside a container, it will be awkward to use the SDK if it is also a container. You'd need to install Docker or use ctr to interact with containerd.sock on the host, and mount in the same /usr/src/kernels and /lib/modules paths that are already mounted into host containers.
The full SDK is also rather large and we only need a small part of it - GCC and binutils - to build kernel modules.
A better approach would be to extract the toolchain into a separate archive. That would play nicely with other tools and automation like DKMS.
We'll need to publish the archives somewhere, and also figure out how to match up the host OS with the SDK version so the correct version can be installed.
Document multi-arch build and publish steps
The steps to build the SDK for both host architectures and both target architectures (four builds in all) are complicated. Additionally for use by Bottlerocket we also combine the host architectures into a multi-architecture tag/manifest.
The steps and scripts that we use to do this internally should be more-or-less identical to what anyone else would do if they wanted to build and publish the SDK to their own container image repos. Let's document these steps and include the helper script here.
update Rust to 1.46
ensure mksquashfs has the fragment race fix
We've seen some intermittent failures from mksquashfs and suspect that they'll be fixed by this patch:
https://kernel.googlesource.com/pub/scm/fs/squashfs/squashfs-tools/+/de03266983ceb62e5365aac84fcd3b2fd4d16e6f
Update Fedora base from 30 to 32
Golang 1.14 mlock issue
Issue or Feature Request:
I am trying to build bottlerocket with cargo make, but got below mlock issue. This issue got fixed (or mitigated in go 1.14.1) golang/go#37436.
[cargo-make] INFO - cargo make 0.29.0
[cargo-make] INFO - Build File: Makefile.toml
[cargo-make] INFO - Task: default
[cargo-make] INFO - Profile: development
[cargo-make] INFO - Running Task: empty
[cargo-make] INFO - Running Task: setup
[cargo-make] INFO - Running Task: fetch-sdk
[cargo-make] INFO - Running Task: fetch-sources
[cargo-make] INFO - Running Task: fetch-vendored
runtime: mlock of signal stack failed: 12
runtime: increase the mlock limit (ulimit -l) or
runtime: update your kernel to 5.3.15+, 5.4.2+, or 5.5+
fatal error: mlock failed
runtime stack:
runtime.throw(0xa3b43e, 0xc)
/usr/libexec/go/src/runtime/panic.go:1112 +0x72
runtime.mlockGsignal(0xc000402900)
/usr/libexec/go/src/runtime/os_linux_x86.go:72 +0x107
runtime.mpreinit(0xc000400380)
/usr/libexec/go/src/runtime/os_linux.go:341 +0x78
runtime.mcommoninit(0xc000400380)
/usr/libexec/go/src/runtime/proc.go:630 +0x108
runtime.allocm(0xc00003b000, 0x0, 0x43f200)
/usr/libexec/go/src/runtime/proc.go:1390 +0x14e
runtime.newm(0x0, 0xc00003b000)
/usr/libexec/go/src/runtime/proc.go:1704 +0x39
runtime.startm(0xc00003b000, 0xc000300000)
/usr/libexec/go/src/runtime/proc.go:1869 +0x12a
runtime.handoffp(0xc00003b000)
/usr/libexec/go/src/runtime/proc.go:1896 +0x52
runtime.entersyscallblock_handoff()
/usr/libexec/go/src/runtime/proc.go:3059 +0x30
runtime.systemstack(0x7efbb4000020)
/usr/libexec/go/src/runtime/asm_amd64.s:370 +0x66
runtime.mstart()
/usr/libexec/go/src/runtime/proc.go:1041
Update to Rust 1.49
https://blog.rust-lang.org/2020/11/19/Rust-1.48.html
Perhaps the most interesting change related to our SDK is the move to using ninja by default instead of make, which can improve build time by 35%.
eliminate toolchain container
Image I'm using:
0.34.1
Issue or Feature Request:
To simplify twoliter and its logic for handling SDK images, I'd like to eliminate the separate "toolchain" container and just have the regular SDK come with a toolchain archive for the eventual host architecture.
For example:
- x86_64 / aarch64 - should build a native aarch64 toolchain
- x86_64 / x86_64 - could either build a native toolchain or reuse the cross toolchain
- aarch64 / x86_64 - should also build a native x86_64 toolchain
- aarch64 / aarch64 - could either build a native toolchain or reuse the cross toolchain
This is not supported by Buildroot which is why the current implementation exists.
Unable to use LLVM `15.0.6` in sdk `v0.29` and `15.0.7` in sdk `v0.30`
Image I'm using:
In v0.29 of the sdk, which uses LLVM 15.0.6 and in v0.30 of the sdk which uses LLVM 15.0.7, users found missing symbols:
readelf -a /*-bottlerocket-linux-musl/sys-root/usr/lib/libunwind.a | grep unw_getcontext
# 0.28.0 output
000000000720 00280000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
000000000a5c 00280000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
000000000b28 00280000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
40: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __unw_getcontext
0000000001c4 00240000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
000000000294 00240000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
00000000045c 00240000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
36: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __unw_getcontext
6: 0000000000000000 0 FUNC GLOBAL HIDDEN 1 __unw_getcontext
7: 0000000000000000 0 FUNC WEAK DEFAULT 1 unw_getcontext
# 0.29.0 output
000000000720 00290000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
000000000a4c 00290000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
000000000b18 00290000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
41: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __unw_getcontext
0000000001c4 00250000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
000000000294 00250000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
00000000045c 00250000011b R_AARCH64_CALL26 0000000000000000 __unw_getcontext + 0
37: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND __unw_getcontext
Notice the final two lines are missing in the v0.29 version of the sdk
GLOBAL HIDDEN 1 __unw_getcontext
7: 0000000000000000 0 FUNC WEAK DEFAULT 1 unw_getcontext
(Shout out to @bcressey for getting this figured out!)
Related to #100
Issue or Feature Request:
Investigate what's going on with the newer versions of LLVM and why we are having trouble using them.
[Feature Request] Support building on aarch64 hosts (M6g, etc.)
Image I'm using:
bottlerocket-aws-k8s-1.15-aarch64.img
Issue or Feature Request:
Feature Request: support building on aarch64 hosts.
Attempting to build on an aarch64 host results in a number of "exec format error"s, most likely from docker pulling x86-based images. Using cargo make -e BUILDSYS_ARCH=aarch64 I was able to build an aarch64 img and amiize it from an x86_64 host.
It would be nice to be able build natively on aarch64, especially as part of larger EKS+Bottlerocket on Arm toolchain.
Thanks!
update Go to 1.14
Include Helm and Kubeconform
Issue or Feature Request:
The bottlerocket-update-operator has its own Helm repository. In order to maintain this repository, we use Helm and Kubeconform, both of which currently use binary artifacts from usptream.
I think it might make sense to pull these into the SDK and track updates to them here.
add more cargo macros
Image I'm using:
v0.37.0
Issue or Feature Request:
Add two additional macros that specs can use to refer to artifacts built by cargo:
%_cargo_outdir "${HOME}/.cache/%{__cargo_target}/release"
%_cargo_outdir_static "${HOME}/.cache/.static/%{__cargo_target}/release"
support multiple license file hashes in license-scan
When pulling multiple versions of a dependency that requires a clarify.toml it is possible to get in a situation where the license hash differs between the versions. Since we can only pass one hash per filename, the license check will always fail for one of the two. At a minimum, we should support multiple hashes for a given filename.
add the docker cli
For bottlerocket-os/bottlerocket#2669 we will be mounting the host's docker socket and running docker commands from within the sdk container
restore copyright notice for rust and cargo macros
Since the macros moved into this repo, we need to add this to COPYRIGHT:
=^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^= =^..^=
macros/rust and macros/cargo (used during build) are derived from the Fedora Rust SIG's rust2rpm.
https://pagure.io/fedora-rust/rust2rpm
Copyright (c) 2017 Igor Gnatenko
Provide cargo-deny
We're using cargo-deny in the Makefile.toml for Bottlerocket, but we'd like to be able to lock to a specific version and the SDK seems like a reasonable place to do that.
remove maven and JDK
Image I'm using:
Latest.
Issue or Feature Request:
I'd like to drop these packages once we no longer need them to build the log4j2 hotpatch:
- java-11-openjdk-devel
- maven-clean-plugin
- maven-local
- maven-openjdk11
- maven-shade-plugin
This should make the SDK images a little smaller.
update cargo-deny to 0.9.1+
We're vending cargo-deny in the SDK now, but it's a fairly old version. We should update to the most recent release and make the necessary changes to deny.toml in the OS packages.
why not copy sdk-gnu to scratch
Image I'm using:
latest
Issue or Feature Request:
In bottlerocket-sdk Dockerfile, sdk-gnu build glibc2.32 and the base sdk has glibc of version glibc2.31, why not copy that to the final sdk image๏ผ
update to Buildroot 2021.02
Image I'm using:
v0.15.0
Issue or Feature Request:
I'd like to rebase on the newest release of Buildroot and update to GCC 10.2.
Update buildroot
We're currently on 2019.08.3 and 2020.02 is available.
Move any licenses from `/usr/share/doc` to `/usr/share/licenses`
Issue or Feature Request:
Some licenses are added to the wrong directory of the resulting SDK image (/usr/share/doc instead of /usr/share/licenses). This seems to be caused by certain packages not being updated to use fedora's %license macro e.g. maven-clean-plugin still uses %doc.
We should correct this, possibly upstream if we can.
update to Rust 1.56.1+
Rust 1.56.1 is out with a mitigation for CVE-2021-42574.
libxcrypt build now needs perl-open and perl-FindBin
Image I'm using:
v0.15.0
Issue or Feature Request:
libxcrypt has switched to perl for build scripts in 4.4.18, which means the Bottlerocket build of it fails.
Here's the lead-up to the failure.
#2 [internal] load build definition from Dockerfile
#2 transferring dockerfile:
#2 transferring dockerfile: 97B done
#2 ...
#1 [internal] load .dockerignore
#1 transferring context: 93B done
#1 DONE 1.2s
#2 [internal] load build definition from Dockerfile
#2 DONE 1.7s
#3 resolve image config for docker.io/docker/dockerfile:1.1.3-experimental
#3 DONE 0.0s
#4 docker-image://docker.io/docker/dockerfile:1.1.3-experimental@sha256:888...
#4 CACHED
#6 [sdk 1/1] FROM docker.io/bottlerocket/sdk-x86_64:v0.15.0-x86_64
#6 CACHED
#13 [cache 1/2] COPY --chown=1000:1000 --from=sdk /tmp /cache
#13 CACHED
#15 [variantcache 1/2] COPY --chown=1000:1000 --from=sdk /tmp /variantcache
#15 CACHED
#5 [internal] load metadata for docker.io/bottlerocket/sdk-x86_64:v0.15.0-x...
#5 DONE 0.0s
#8 [internal] load build context
#8 transferring context: 4.80MB 2.0s
#8 transferring context: 13.70MB 3.5s done
#8 DONE 5.4s
#7 [rpmbuild 1/6] WORKDIR /home/builder
#7 CACHED
#9 [rpmbuild 2/6] COPY --chown=builder roles/default.root.json ./rpmbuild/B...
#9 CACHED
#14 [cache 2/2] COPY --chown=1000:1000 .dockerignore /cache/.libxcrypt.x86_6...
#14 DONE 1.6s
#16 [variantcache 2/2] COPY --chown=1000:1000 .dockerignore /variantcache/.l...
#16 DONE 2.1s
#10 [rpmbuild 3/6] COPY ./macros/x86_64 ./macros/shared ./macros/rust ./macr...
#10 DONE 3.4s
#11 [rpmbuild 4/6] RUN rpmdev-setuptree && cat x86_64 shared rust cargo >...
#11 1.198 1125902845
#11 DONE 1.6s
#12 [rpmbuild 5/6] RUN --mount=target=/host ln -s /host/build/rpms/*.rpm...
#12 1.219 Directory walk started
#12 1.219 Directory walk done - 131 packages
#12 1.219 Temporary output repo path: ./rpmbuild/RPMS/.repodata/
#12 1.219 Pool started (with 5 workers)
#12 1.219 Pool finished
#12 1.508 Added repo repo from ./rpmbuild/RPMS
#12 1.567 repo 88 MB/s | 92 kB 00:00
#12 2.225 Dependencies resolved.
#12 2.232 ================================================================================
#12 2.232 Package Arch Version Repo Size
#12 2.232 ================================================================================
#12 2.232 Installing:
#12 2.232 bottlerocket-x86_64-glibc-devel x86_64 2.33-1 repo 2.3 M
#12 2.232 Installing dependencies:
#12 2.232 bottlerocket-x86_64-glibc x86_64 2.33-1 repo 2.1 M
#12 2.232
#12 2.232 Transaction Summary
#12 2.232 ================================================================================
#12 2.232 Install 2 Packages
#12 2.232
#12 2.246 Total size: 4.4 M
#12 2.246 Installed size: 14 M
#12 2.246 Downloading Packages:
#12 2.251 Running transaction check
#12 2.257 Transaction check succeeded.
#12 2.257 Running transaction test
#12 2.294 Transaction test succeeded.
#12 2.299 Running transaction
#12 2.575 Preparing : 1/1
#12 2.620 Installing : bottlerocket-x86_64-glibc-2.33-1.x86_64 1/2
#12 2.856 Installing : bottlerocket-x86_64-glibc-devel-2.33-1.x86_64 2/2
#12 3.617 Verifying : bottlerocket-x86_64-glibc-2.33-1.x86_64 1/2
#12 3.617 Verifying : bottlerocket-x86_64-glibc-devel-2.33-1.x86_64 2/2
#12 3.721
#12 3.721 Installed:
#12 3.721 bottlerocket-x86_64-glibc-2.33-1.x86_64
#12 3.721 bottlerocket-x86_64-glibc-devel-2.33-1.x86_64
#12 3.721
#12 3.721 Complete!
#12 DONE 4.5s
#17 [rpmbuild 6/6] RUN --mount=source=.cargo,target=/home/builder/.cargo ...
#17 2.884 Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.xAjcOi
#17 2.887 + umask 022
#17 2.887 + cd /home/builder/rpmbuild/BUILD
#17 2.887 + cd /home/builder/rpmbuild/BUILD
#17 2.887 + rm -rf libxcrypt-4.4.18
#17 2.895 + /usr/bin/tar -xof -
#17 2.900 + /usr/bin/gzip -dc /home/builder/rpmbuild/SOURCES/libxcrypt-4.4.18.tar.gz
#17 2.973 + STATUS=0
#17 2.973 + '[' 0 -ne 0 ']'
#17 2.973 + cd libxcrypt-4.4.18
#17 2.973 + /usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .
#17 2.975 + ./autogen.sh
#17 2.978 autogen: running: autoreconf -iv -Wall,error
#17 3.412 autoreconf: Entering directory `.'
#17 3.412 autoreconf: configure.ac: not using Gettext
#17 4.413 autoreconf: running: aclocal --warnings=all,error -I build-aux
#17 6.338 autoreconf: configure.ac: tracing
#17 6.938 autoreconf: running: libtoolize --copy
#17 7.433 libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'build-aux'.
#17 7.433 libtoolize: copying file 'build-aux/ltmain.sh'
#17 7.513 libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'build-aux'.
#17 7.513 libtoolize: copying file 'build-aux/libtool.m4'
#17 7.667 libtoolize: copying file 'build-aux/ltoptions.m4'
#17 7.806 libtoolize: copying file 'build-aux/ltsugar.m4'
#17 7.963 libtoolize: copying file 'build-aux/ltversion.m4'
#17 8.127 libtoolize: copying file 'build-aux/lt~obsolete.m4'
#17 10.13 autoreconf: running: /usr/bin/autoconf --warnings=all,error
#17 10.90 autoreconf: running: /usr/bin/autoheader --warnings=all,error
#17 11.14 autoreconf: running: automake --add-missing --copy --no-force --warnings=all,error
#17 12.25 configure.ac:30: installing 'build-aux/compile'
#17 12.26 configure.ac:29: installing 'build-aux/config.guess'
#17 12.27 configure.ac:29: installing 'build-aux/config.sub'
#17 12.27 configure.ac:16: installing 'build-aux/install-sh'
#17 12.27 configure.ac:16: installing 'build-aux/missing'
#17 12.31 Makefile.am: installing './INSTALL'
#17 12.37 Makefile.am: installing 'build-aux/depcomp'
#17 12.58 parallel-tests: installing 'build-aux/test-driver'
#17 12.68 autoreconf: Leaving directory `.'
#17 12.69 + RPM_EC=0
#17 12.69 ++ jobs -p
#17 12.69 + exit 0
#17 12.69 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.hck5dj
#17 12.69 + umask 022
#17 12.69 + cd /home/builder/rpmbuild/BUILD
#17 12.69 + cd libxcrypt-4.4.18
#17 12.69 + CFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-clash-protection -fno-semantic-interposition'
#17 12.69 + export CFLAGS
#17 12.69 + CXXFLAGS='-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-clash-protection -fno-semantic-interposition'
#17 12.69 + export CXXFLAGS
#17 12.69 + LDFLAGS='-Wl,-z,relro -Wl,-z,now'
#17 12.69 + export LDFLAGS
#17 12.69 + PKG_CONFIG_PATH=/x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/pkgconfig
#17 12.69 + export PKG_CONFIG_PATH
#17 12.69 + PKG_CONFIG_ALLOW_CROSS=1
#17 12.69 + export PKG_CONFIG_ALLOW_CROSS
#17 12.70 + ac_cv_func_malloc_0_nonnull=yes
#17 12.70 + ac_cv_func_realloc_0_nonnull=yes
#17 12.70 + ./configure --host=x86_64-bottlerocket-linux-gnu --target=x86_64-bottlerocket-linux-gnu --build=x86_64-redhat-linux-gnu --disable-dependency-tracking --prefix=/x86_64-bottlerocket-linux-gnu/sys-root/usr --exec-prefix=/x86_64-bottlerocket-linux-gnu/sys-root/usr --bindir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/bin --sbindir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/sbin --sysconfdir=/etc --datadir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/share --includedir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/include --libdir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/lib --libexecdir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/share/man --infodir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/share/info --disable-failure-tokens --disable-valgrind --disable-silent-rules --enable-hashes=all --enable-obsolete-api=no --enable-obsolete-api-enosys=no --enable-shared --enable-static --with-pkgconfigdir=/x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/pkgconfig
#17 13.22 checking for a BSD-compatible install... /usr/bin/install -c
#17 13.25 checking whether build environment is sane... yes
#17 13.29 checking for x86_64-bottlerocket-linux-gnu-strip... x86_64-bottlerocket-linux-gnu-strip
#17 13.29 checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
#17 13.29 checking for gawk... gawk
#17 13.29 checking whether make sets $(MAKE)... yes
#17 13.33 checking whether make supports nested variables... yes
#17 13.39 checking build system type... x86_64-redhat-linux-gnu
#17 13.41 checking host system type... x86_64-bottlerocket-linux-gnu
#17 13.43 checking for x86_64-bottlerocket-linux-gnu-gcc... x86_64-bottlerocket-linux-gnu-gcc
#17 13.48 checking whether the C compiler works... yes
#17 13.55 checking for C compiler default output file name... a.out
#17 13.55 checking for suffix of executables...
#17 13.62 checking whether we are cross compiling... yes
#17 13.63 checking for suffix of object files... o
#17 13.68 checking whether we are using the GNU C compiler... yes
#17 13.71 checking whether x86_64-bottlerocket-linux-gnu-gcc accepts -g... yes
#17 13.74 checking for x86_64-bottlerocket-linux-gnu-gcc option to accept ISO C11... none needed
#17 13.83 checking whether x86_64-bottlerocket-linux-gnu-gcc understands -c and -o together... yes
#17 13.90 checking whether make supports the include directive... yes (GNU style)
#17 13.94 checking dependency style of x86_64-bottlerocket-linux-gnu-gcc... none
#17 13.94 checking for x86_64-bottlerocket-linux-gnu-pkg-config... no
#17 13.94 checking for pkg-config... /usr/bin/pkg-config
#17 13.94 configure: WARNING: using cross tools not prefixed with host triplet
#17 13.94 checking pkg-config is at least version 0.9.0... yes
#17 13.95 checking how to run the C preprocessor... x86_64-bottlerocket-linux-gnu-gcc -E
#17 14.09 checking whether make sets $(MAKE)... (cached) yes
#17 14.10 checking whether ln -s works... yes
#17 14.10 checking for perl... /usr/bin/perl
#17 14.10 checking whether /usr/bin/perl is version 5.14.0 or later... yes
#17 14.11 checking for sys/types.h... yes
#17 14.18 checking for sys/stat.h... yes
#17 14.24 checking for strings.h... yes
#17 14.29 checking for inttypes.h... yes
#17 14.36 checking for stdint.h... yes
#17 14.42 checking for unistd.h... yes
#17 14.46 checking for minix/config.h... no
#17 14.53 checking whether it is safe to define __EXTENSIONS__... yes
#17 14.62 checking for special C compiler options needed for large files... no
#17 14.62 checking for _FILE_OFFSET_BITS value needed for large files... no
#17 14.66 checking whether C compiler accepts -Werror=unknown-warning-option... no
#17 14.70 checking whether C compiler accepts -Wall... yes
#17 14.74 checking whether C compiler accepts -Wextra... yes
#17 14.81 checking whether C compiler accepts -Walloc-zero... yes
#17 14.85 checking whether C compiler accepts -Walloca... yes
#17 14.90 checking whether C compiler accepts -Wbad-function-cast... yes
#17 14.95 checking whether C compiler accepts -Wcast-align... yes
#17 15.00 checking whether C compiler accepts -Wcast-qual... yes
#17 15.06 checking whether C compiler accepts -Wconversion... yes
#17 15.12 checking whether C compiler accepts -Wformat=2... yes
#17 15.19 checking whether C compiler accepts -Wformat-overflow=2... yes
#17 15.25 checking whether C compiler accepts -Wformat-signedness... yes
#17 15.30 checking whether C compiler accepts -Wformat-truncation=1... yes
#17 15.34 checking whether C compiler accepts -Wlogical-op... yes
#17 15.38 checking whether C compiler accepts -Wmissing-declarations... yes
#17 15.43 checking whether C compiler accepts -Wmissing-prototypes... yes
#17 15.51 checking whether C compiler accepts -Wnested-externs... yes
#17 15.56 checking whether C compiler accepts -Wnull-dereference... yes
#17 15.62 checking whether C compiler accepts -Wold-style-definition... yes
#17 15.67 checking whether C compiler accepts -Wpointer-arith... yes
#17 15.72 checking whether C compiler accepts -Wrestrict... yes
#17 15.76 checking whether C compiler accepts -Wshadow... yes
#17 15.81 checking whether C compiler accepts -Wstrict-overflow=2... yes
#17 15.85 checking whether C compiler accepts -Wstrict-prototypes... yes
#17 15.94 checking whether C compiler accepts -Wundef... yes
#17 15.99 checking whether C compiler accepts -Wvla... yes
#17 16.03 checking whether C compiler accepts -Wwrite-strings... yes
#17 16.11 checking whether C compiler accepts -Wpedantic... yes
#17 16.18 checking whether C compiler accepts -Werror... yes
#17 16.22 checking whether C compiler accepts -Werror=unknown-warning-option... no
#17 16.26 checking whether C compiler accepts -Wall... no
#17 16.31 checking whether C compiler accepts -Wextra... no
#17 16.37 checking whether C compiler accepts -Walloc-zero... no
#17 16.41 checking whether C compiler accepts -Walloca... no
#17 16.45 checking whether C compiler accepts -Wbad-function-cast... no
#17 16.49 checking whether C compiler accepts -Wcast-align... no
#17 16.53 checking whether C compiler accepts -Wcast-qual... no
#17 16.57 checking whether C compiler accepts -Wconversion... no
#17 16.60 checking whether C compiler accepts -Wformat=2... no
#17 16.66 checking whether C compiler accepts -Wformat-overflow=2... no
#17 16.72 checking whether C compiler accepts -Wformat-signedness... no
#17 16.75 checking whether C compiler accepts -Wformat-truncation=1... no
#17 16.78 checking whether C compiler accepts -Wlogical-op... no
#17 16.82 checking whether C compiler accepts -Wmissing-declarations... no
#17 16.87 checking whether C compiler accepts -Wmissing-prototypes... no
#17 16.93 checking whether C compiler accepts -Wnested-externs... no
#17 16.98 checking whether C compiler accepts -Wnull-dereference... no
#17 17.02 checking whether C compiler accepts -Wold-style-definition... no
#17 17.08 checking whether C compiler accepts -Wpointer-arith... no
#17 17.14 checking whether C compiler accepts -Wrestrict... no
#17 17.19 checking whether C compiler accepts -Wshadow... no
#17 17.25 checking whether C compiler accepts -Wstrict-overflow=2... no
#17 17.29 checking whether C compiler accepts -Wstrict-prototypes... no
#17 17.33 checking whether C compiler accepts -Wundef... no
#17 17.39 checking whether C compiler accepts -Wvla... no
#17 17.43 checking whether C compiler accepts -Wwrite-strings... no
#17 17.49 checking whether C compiler accepts -Wpedantic... no
#17 17.54 checking whether C compiler accepts -Werror... no
#17 17.58 checking how to print strings... printf
#17 17.59 checking for a sed that does not truncate output... /usr/bin/sed
#17 17.61 checking for grep that handles long lines and -e... /usr/bin/grep
#17 17.62 checking for egrep... /usr/bin/grep -E
#17 17.62 checking for fgrep... /usr/bin/grep -F
#17 17.63 checking for ld used by x86_64-bottlerocket-linux-gnu-gcc... /usr/x86_64-bottlerocket-linux-gnu/bin/ld
#17 17.71 checking if the linker (/usr/x86_64-bottlerocket-linux-gnu/bin/ld) is GNU ld... yes
#17 17.72 checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-bottlerocket-linux-gnu-nm -B
#17 17.73 checking the name lister (/usr/bin/x86_64-bottlerocket-linux-gnu-nm -B) interface... BSD nm
#17 17.78 checking the maximum length of command line arguments... 1572864
#17 17.82 checking how to convert x86_64-redhat-linux-gnu file names to x86_64-bottlerocket-linux-gnu format... func_convert_file_noop
#17 17.82 checking how to convert x86_64-redhat-linux-gnu file names to toolchain format... func_convert_file_noop
#17 17.82 checking for /usr/x86_64-bottlerocket-linux-gnu/bin/ld option to reload object files... -r
#17 17.82 checking for x86_64-bottlerocket-linux-gnu-objdump... x86_64-bottlerocket-linux-gnu-objdump
#17 17.82 checking how to recognize dependent libraries... pass_all
#17 17.82 checking for x86_64-bottlerocket-linux-gnu-dlltool... no
#17 17.82 checking for dlltool... no
#17 17.83 checking how to associate runtime and link libraries... printf %s\n
#17 17.83 checking for x86_64-bottlerocket-linux-gnu-ar... x86_64-bottlerocket-linux-gnu-ar
#17 17.83 checking for archiver @FILE support... @
#17 17.87 checking for x86_64-bottlerocket-linux-gnu-strip... (cached) x86_64-bottlerocket-linux-gnu-strip
#17 17.87 checking for x86_64-bottlerocket-linux-gnu-ranlib... x86_64-bottlerocket-linux-gnu-ranlib
#17 17.87 checking command to parse /usr/bin/x86_64-bottlerocket-linux-gnu-nm -B output from x86_64-bottlerocket-linux-gnu-gcc object... ok
#17 18.02 checking for sysroot... no
#17 18.02 checking for a working dd... /usr/bin/dd
#17 18.04 checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
#17 18.08 checking for x86_64-bottlerocket-linux-gnu-mt... no
#17 18.08 checking for mt... no
#17 18.08 checking if : is a manifest tool... no
#17 18.09 checking for dlfcn.h... yes
#17 18.15 checking for objdir... .libs
#17 18.28 checking if x86_64-bottlerocket-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
#17 18.35 checking for x86_64-bottlerocket-linux-gnu-gcc option to produce PIC... -fPIC -DPIC
#17 18.35 checking if x86_64-bottlerocket-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes
#17 18.41 checking if x86_64-bottlerocket-linux-gnu-gcc static flag -static works... yes
#17 18.52 checking if x86_64-bottlerocket-linux-gnu-gcc supports -c -o file.o... yes
#17 18.61 checking if x86_64-bottlerocket-linux-gnu-gcc supports -c -o file.o... (cached) yes
#17 18.61 checking whether the x86_64-bottlerocket-linux-gnu-gcc linker (/usr/x86_64-bottlerocket-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes
#17 18.64 checking whether -lc should be explicitly linked in... no
#17 18.69 checking dynamic linker characteristics... GNU/Linux ld.so
#17 18.81 checking how to hardcode library paths into programs... immediate
#17 18.81 checking whether stripping libraries is possible... yes
#17 18.82 checking if libtool supports shared libraries... yes
#17 18.82 checking whether to build shared libraries... yes
#17 18.82 checking whether to build static libraries... yes
#17 18.82 checking for _ prefix in compiled symbols... no
#17 18.87 checking whether the preprocessor (x86_64-bottlerocket-linux-gnu-gcc -E) supports -dD... yes
#17 18.90 checking for fcntl.h... yes
#17 18.99 checking for stdbool.h... yes
#17 19.07 checking for sys/cdefs.h... yes
#17 19.15 checking for sys/random.h... yes
#17 19.23 checking for sys/syscall.h... yes
#17 19.32 checking for endian.h... yes
#17 19.42 checking for sys/endian.h... no
#17 19.51 checking for sys/param.h... yes
#17 19.59 checking whether sys/cdefs.h defines __BEGIN_DECLS and __END_DECLS... yes
#17 19.63 checking whether sys/cdefs.h defines __THROW... yes
#17 19.66 checking how to control data alignment... _Alignas
#17 19.66 checking how to query data alignment... _Alignof
#17 19.66 checking for max_align_t in stddef.h... yes
#17 19.73 checking for byte order macros... BYTE_ORDER and xxx_ENDIAN
#17 19.77 checking for static_assert in assert.h... yes
#17 19.85 checking for ld --wrap... yes
#17 19.97 checking linker version script flag... --version-script
#17 20.10 checking if version scripts can use complex wildcards... yes
#17 20.17 checking how to make linking fail when undefined symbols remain... -Wl,-z,defs
#17 20.25 checking how to make linking fail when there are text relocations... -Wl,-z,text
#17 20.34 checking how to link with read-only relocations... -Wl,-z,relro
#17 20.42 checking how to link with immediate binding... -Wl,-z,now
#17 20.50 checking whether C compiler accepts -fno-plt... yes
#17 20.55 checking for arc4random_buf... no
#17 20.66 checking for explicit_bzero... yes
#17 20.74 checking for explicit_memset... no
#17 20.84 checking for getentropy... yes
#17 20.93 checking for getrandom... yes
#17 21.00 checking for memset_s... no
#17 21.09 checking for open64... yes
#17 21.18 checking for syscall... yes
Here's the failure:
#17 21.25 checking for Python 3.>=6 with Passlib... not found
#17 21.37 configure: Disabling the "regen-ka-table" target, missing Python requirements.
#17 21.39 Can't locate open.pm in @INC (you may need to install the open module) (@INC contains: /usr/local/lib64/perl5/5.30 /usr/local/share/perl5/5.30 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at ./build-aux/expand-selected-hashes line 20.
#17 21.39 BEGIN failed--compilation aborted at ./build-aux/expand-selected-hashes line 20.
#17 21.39 configure: error: bad value 'all' for --enable-hashes
(Not sure if we care about regen-ka-table, but thought I'd include that snippet too, in case we want to add python passlib.)
I suspect that adding perl-open to the install in Dockerfile would get past that error, but I'm not sure if there are more.
Here's the diff to test the package update.
diff --cc packages/libxcrypt/Cargo.toml
index bef3c5d2,bef3c5d2..33dbfb8c
--- a/packages/libxcrypt/Cargo.toml
+++ b/packages/libxcrypt/Cargo.toml
@@@ -9,8 -9,8 +9,8 @@@ build = "build.rs
path = "pkg.rs"
[[package.metadata.build-package.external-files]]
--url = "https://github.com/besser82/libxcrypt/archive/v4.4.17/libxcrypt-4.4.17.tar.gz"
--sha512 = "94aaba6ccf9b6d1a32f9a571ee32261cecd393d5b8d8c6f18d740dc7bb29ac0fbd381124e7f0d84882559bb634208c08151b3dc05c9138fa0a229c4ba20fb6f7"
++url = "https://github.com/besser82/libxcrypt/archive/v4.4.18/libxcrypt-4.4.18.tar.gz"
++sha512 = "66e3afb32ca27b1b00c21d07f0cd3eb3403ebd1732503376e5f85fa79acf078aa2bac54a8920121b3741cd46a807f4ea176de38c6b5b4611c701dc9e6f8d1490"
[build-dependencies]
glibc = { path = "../glibc" }
diff --cc packages/libxcrypt/libxcrypt.spec
index f3f6f4d9,f3f6f4d9..6155069a
--- a/packages/libxcrypt/libxcrypt.spec
+++ b/packages/libxcrypt/libxcrypt.spec
@@@ -1,5 -1,5 +1,5 @@@
Name: %{_cross_os}libxcrypt
--Version: 4.4.17
++Version: 4.4.18
Release: 1%{?dist}
Summary: Extended crypt library for descrypt, md5crypt, bcrypt, and others
License: LGPL-2.1-or-laterglibc needs to be the same version across the Fedora base image, the SDK, and the OS
Some of our build scripts are built with the Bottlerocket toolchain, but run with the Fedora glibc version in the SDK image. If we try to upgrade glibc in the OS ahead of the SDK, we get symbol version mismatches; if we try to upgrade glibc in the SDK ahead of the Fedora base image, we get symbol version mismatches.
This issue is to track unwinding the dependency of things built with the Bottlerocket toolchain on the particulars of the Fedora glibc.
update Rust to 1.42.0
update Go to 1.15
Update Rust to 1.56
Update Rust to 1.53
Update glibc to 2.31
We updated glibc to 2.31 in bottlerocket-os/bottlerocket#728 so we should update the SDK to match.
Update base image to F36 or greater
Image I'm using: 0.26.0
Issue or Feature Request: Updating dbus-broker in bottlerocket requires a newer meson package than is available in our current F35 base.
To fix this, we should move to a newer base image.
Update to Rust 1.58
Update Rust to 1.45.2
Update Rust to 1.43.1
license-scan: Skip Rust crates not used on platform
Image I'm using:
n/a
Issue or Feature Request:
bottlerocket-license-scan considers and copies in licenses for platform dependencies that don't make sense for Bottlerocket (e.g. Windows, Fuchsia, WebAssembly). It should skip packages that aren't built for any of the supported target toolchains in the SDK.
Improve `bottlerocket-license-scan` handling of `--out-dir`
Image I'm using:
bottlerocket/sdk-x86_64:v0.8
Issue or Feature Request:
Calling bottlerocket-license-scan with --out-dir provided a non-existent directory results in an opaque error (presented as os error 13 - a permissions error). Instead, this command should either:
- Create the directory that the caller provided
- Check the provided inputs (the flag's arg) and fail early with a helpful message.
system directories should be owned by root
Image I'm using:
v0.23.1
Issue or Feature Request:
Spotted this in bottlerocket-os/bottlerocket#1799 (comment) - the SDK has some directories owned by builder that should be owned by root.
[builder@b9e9b9e0f2db /]$ ls -latr / | grep builder
drwxr-xr-x. 3 builder builder 4096 Nov 16 22:58 x86_64-bottlerocket-linux-musl
drwxr-xr-x. 14 builder builder 4096 Nov 16 22:58 usr
drwxr-xr-x. 3 builder builder 4096 Nov 16 23:01 x86_64-bottlerocket-linux-gnu
Align sdk versioning with each bottlerocket-os version for easier coorelation between the two
Image I'm using:
bottlerocket/sdk-x86_64:v0.12.0
Issue or Feature Request:
- The current versioning scheme of
bottlerocket-sdkcontainer images don't align with the versioning scheme of bottlerocket-os e.g. there is no way to say thatbottlerocket/sdk-x86_64:v0.12.0was the base layer for building thebottlerocket-aws-k8s-1.16-x86_64-v1.0.1-2a181156orbottlerocket-aws-k8s-1.16-x86_64-v1.0.0-b0e2bc22AMI - An sdk versioning scheme that has maybe the bottlerocket-os version in it would be more amenable e.g.
bottlerocket/sdk-x86_64:v1.0.0-b0e2bc22. It might be the case that for minor bottlerocket-os versions there is no change needed on the sdk-image but I did still tag those images with bottlerocket-os version in the interest of consistency over duplication.
vend toolchain archive as a container image
Image I'm using:
v0.15.0
Issue or Feature Request:
I'd like to turn the toolchain archive into a container image, so that it's easy to consume it in the same way as the SDK.
Update Go to 1.15.6
https://golang.org/doc/devel/release.html
go1.15.4 (released 2020/11/05) includes fixes to cgo, the compiler, linker, runtime, and the compress/flate, net/http, reflect, and time packages.
go1.15.5 (released 2020/11/12) includes security fixes to the go command and the math/big package.
go1.15.6 (released 2020/12/03) includes fixes to the compiler, linker, runtime, the go command, and the io package.
Missing default `go.env` at `GOROOT` causes failed builds in vanilla build environment
Image I'm using: Any SDK v0.37.0 image; needs Go 1.21
Issue or Feature Request: The SDK is missing the upstream Go release's go.env file at GOROOT, and doesn't deal well with missing defaults for some of these values if they're not explicitly provided by the user. See bottlerocket-os/bottlerocket#3698 for an example.
Update to Rust 1.51
Update to Rust 1.47
update to Go 1.16.3
add cargo make
We plan to use cargo make (at least temporarily) for bottlerocket-os/bottlerocket#2669
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.