openbmc / openbmc-build-scripts

openbmc-build-scripts

Build script for CI jobs in Jenkins.

openbmc-build-scripts's Issues

Need to include the x86 sdk

I have a repository that tries to include a ipmi-api.h file. That is part of the arm SDK. Using docker it doesn't include that so my compiles fail unless I am in the arm cross compile sdk.

copy at end of build occasionally hangs

See this 1-2 times a day in our CI jobs. Then end of the build-setup.sh, where we're copying the files from the docker container to the mounted filesystem, it just hangs. You have to manually kill the job or it holds up all the other jobs.

Here's an example:

09:12:41 + cp -r /tmp/openbmc/abi_version /tmp/openbmc/buildstats /tmp/openbmc/cache /tmp/openbmc/deploy /tmp/openbmc/hosttools /tmp/openbmc/log /tmp/openbmc/pkgdata /tmp/openbmc/saved_tmpdir /tmp/openbmc/sstate-control /tmp/openbmc/stamps /tmp/openbmc/sysroots /tmp/openbmc/sysroots-components /tmp/openbmc/work /tmp/openbmc/work-shared /var/lib/jenkins-slave/workspace/openbmc-build-gerrit-trigger-meta/distro/ubuntu/label/builder/target/zaius/openbmc/build/tmp
11:23:39 Set build name.
11:23:39 New build name is '#70-Joseph Reynolds'
11:23:39 Build was aborted

Seems like we could def optimize this to only copy of the artifacts we actually need. Maybe provide an option to copy it all, but default to just the image artifacts.

build-unit-test-docker: Permission denied: '/usr/lib/python3.9/__pycache__/__future__.cpython-39.pyc

I recently got a new Ubuntu 20 system and I can't seem to get build-unit-test-docker to build on this system.

System Info:

NAME="Ubuntu"
VERSION="20.04.3 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.3 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
andrewg@ubuntu20:~/Code/openbmc-build-scripts$ uname -a
Linux ubunto20 5.4.0-84-generic #94-Ubuntu SMP Thu Aug 26 20:27:37 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

base: Preparing to unpack .../libpython3.9-minimal_3.9.5-3~21.04_amd64.deb ...
base: Unpacking libpython3.9-minimal:amd64 (3.9.5-3~21.04) ...
base: Selecting previously unselected package libexpat1:amd64.
base: Preparing to unpack .../libexpat1_2.2.10-2_amd64.deb ...
base: Unpacking libexpat1:amd64 (2.2.10-2) ...
base: Selecting previously unselected package python3.9-minimal.
base: Preparing to unpack .../python3.9-minimal_3.9.5-3~21.04_amd64.deb ...
base: Unpacking python3.9-minimal (3.9.5-3~21.04) ...
base: Setting up libpython3.9-minimal:amd64 (3.9.5-3~21.04) ...
base: Setting up libexpat1:amd64 (2.2.10-2) ...
base: Setting up python3.9-minimal (3.9.5-3~21.04) ...
base: Traceback (most recent call last):
base:   File "/usr/lib/python3.9/py_compile.py", line 215, in <module>
base:     sys.exit(main())
base:   File "/usr/lib/python3.9/py_compile.py", line 207, in main
base:     compile(filename, doraise=True)
base:   File "/usr/lib/python3.9/py_compile.py", line 172, in compile
base:     importlib._bootstrap_external._write_atomic(cfile, bytecode, mode)
base:   File "<frozen importlib._bootstrap_external>", line 186, in _write_atomic
base: PermissionError: [Errno 13] Permission denied: '/usr/lib/python3.9/__pycache__/__future__.cpython-39.pyc.140420583859120'
base: dpkg: error processing package python3.9-minimal (--configure):
base:  installed python3.9-minimal package post-installation script subprocess returned error exit status 1
base: Errors were encountered while processing:
base:  python3.9-minimal
base: E: Sub-process /usr/bin/dpkg returned an error code (1)
base: Removing intermediate container 92a5fbc075ed
Traceback (most recent call last):
  File "./scripts/build-unit-test-docker", line 846, in <module>
    Docker.build("base", docker_base_img_name, dockerfile_base)
  File "./scripts/build-unit-test-docker", line 629, in build
    docker.build(
  File "/usr/lib/python3/dist-packages/sh.py", line 1427, in __call__
    return RunningCommand(cmd, call_args, stdin, stdout, stderr)
  File "/usr/lib/python3/dist-packages/sh.py", line 774, in __init__
    self.wait()
  File "/usr/lib/python3/dist-packages/sh.py", line 792, in wait
    self.handle_command_exit_code(exit_code)
  File "/usr/lib/python3/dist-packages/sh.py", line 815, in handle_command_exit_code
    raise exc
sh.ErrorReturnCode_100: 

I've tried a fresh run of the script on my Ubuntu 18 system without issue so I'm not sure what's going on here. The issue looks like https://forums.docker.com/t/bug-on-apt-install-permission-denied/100196 which only seemed to hit certain machines as well.

I've tried a few things like ensuring all packages are up to date, rebooting the machine, and hacking at the script a bit but so far, no dice.

The non-working system is running Docker version 20.10.8. The working system has 20.10.7 but I don't see any obvious changes in the change log. Downleveling may be the next move though.

build-unit-test-docker.sh: Extract specific commits when not using ubuntu package

See discussion in https://gerrit.openbmc-project.xyz/#/c/openbmc/openbmc-build-scripts/+/13220/4/build-unit-test-docker.sh@247

Should make sure we do this for all packages and also we need to stop doing the extract/build in the previous jobs make directory (i.e. go back to $HOME).

build-qemu-rebot-docker.sh needs to add somethings

libsdl2-dev \
libsdl2-2.0-0 \
numactl

run-unit-test-docker.sh: Enable SSH support

There is a need to clone repository via SSH.
When I run script with EXTRA_DOCKER_RUN_ARGS="-v /home/user/.gitconfig:/home/user/.gitconfig -v /home/user/.ssh:/home/user/.ssh",
I have this error message:

/bin/sh: 1: exec: socat: not found
Connection closed by UNKNOWN port 65535
fatal: Could not read from remote repository.

Can I add some EXTRA_DOCKER_RUN_ARGS to install socat?

Missing libsystmed0 (= 245.4-4ubuntu3.1) dependency causes run unit test docker script to failed

Recently, I pulled openbmc-build-scripts (commit: 80d0728) and ran the run-unit-test-docker.sh script, and prompted me that the missing libsystmed0 (= 245.4-4ubuntu3.1) dependency would cause the unit test to run docker The script failed.
I did the following and still failed:
ran the command on my system(ubuntu18.04):

1. sudo docker pull ubuntu:focal
2. sudo docker image prune -a

Error message:

Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Get:2 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Ign:3 http://ddebs.ubuntu.com focal InRelease
Get:4 http://archive.ubuntu.com/ubuntu focal-updates InRelease [107 kB]
Ign:5 http://ddebs.ubuntu.com focal-updates InRelease
Get:6 http://ddebs.ubuntu.com focal Release [40.4 kB]
Get:7 http://security.ubuntu.com/ubuntu focal-security/universe amd64 Packages [36.5 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal-backports InRelease [98.3 kB]
Get:9 http://ddebs.ubuntu.com focal-updates Release [40.5 kB]
Get:10 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages [108 kB]
Get:11 http://ddebs.ubuntu.com focal Release.gpg [819 B]
Get:12 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [180 kB]
Get:13 http://ddebs.ubuntu.com focal-updates Release.gpg [819 B]
Get:14 http://ddebs.ubuntu.com focal/multiverse amd64 Packages [78.2 kB]
Get:15 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages [89.8 kB]
Get:16 http://ddebs.ubuntu.com focal/universe amd64 Packages [5311 kB]
Get:17 http://ddebs.ubuntu.com focal/main amd64 Packages [611 kB]
Get:18 http://ddebs.ubuntu.com focal-updates/universe amd64 Packages [53.1 kB]
Get:19 http://ddebs.ubuntu.com focal-updates/main amd64 Packages [73.1 kB]
Fetched 6935 kB in 1min 16s (91.4 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libsystemd-dev : Depends: libsystemd0 (= 245.4-4ubuntu3.1) but 245.4-4ubuntu3 is to be installed
 systemd : Depends: libsystemd0 (= 245.4-4ubuntu3.1) but 245.4-4ubuntu3 is to be installed
E: Unable to correct problems, you have held broken packages.
The command '/bin/sh -c apt-get update && apt-get install -yy     gcc-10     g++-10     libc6-dbg     libc6-dev     libtool     bison     flex     cmake     python3     python3-dev    python3-yaml     python3-mako     python3-pip     python3-setuptools     python3-git     python3-socks     pkg-config     autoconf     autoconf-archive     libsystemd-dev     systemd     libsystemd0-dbgsym     libssl-dev     libevdev-dev     libevdev2-dbgsym     libjpeg-dev     libpng-dev     ninja-build     sudo     curl     git     dbus     iputils-ping     clang-10     clang-format-10     clang-tidy-10     clang-tools-10     npm     iproute2     libnl-3-dev     libnl-genl-3-dev     libconfig++-dev     libsnmp-dev     valgrind     valgrind-dbg     libpam0g-dev     xxd     libi2c-dev     wget     libldap2-dev     libprotobuf-dev     libperlio-gzip-perl     libjson-perl     protobuf-compiler     libgpiod-dev     device-tree-compiler     cppcheck' returned a non-zero code: 100
++ cleanup
++ local status=100
++ [[ -n /tmp/tmp.TSQHAz25st ]]
++ rm -f /tmp/tmp.TSQHAz25st
++ trap - EXIT ERR
++ exit 100

Looking forward to your reply. thanks.

jenkins artifacts no longer allow or show links in latest LTS release

https://www.jenkins.io/security/advisory/2021-01-13/#SECURITY-1452 was a change by the jenkins team that removes files which are links from the jenkins archival view (i.e. https://jenkins.openbmc.org/job/latest-master/label=docker-builder,target=witherspoon/lastSuccessfulBuild/artifact/openbmc/build/tmp/deploy/images/witherspoon/)

The way our bitbake process works is it generates a timestamped version of the file (i.e. obmc-phosphor-image-witherspoon-20210407025132.ubi.mtd) and then generates a link to that file with a generic name (i.e. obmc-phosphor-image-witherspoon.ubi.mtd)

OpenBMC tooling and documentation assumes that generic file name which is going to be a problem once we upgrade to a jenkins level with this security change.

I think we probably need a jenkins/run-ci-openbmc which runs build-setup.sh as normal and then at the end turns these links into real files. It will burn some extra space in jenkins but it shouldn't be too much of an issue.

Something that searches over all files under the deploy dir, checks if they are a link, does a cp -L of the file to a tmp dir, removes the link, then moves the copied file back into the dir.

get_unit_test_report.py: no longer running correctly

https://jenkins.openbmc.org/job/latest-unit-test-coverage/ is still running but the data is not valid anymore. Everything is either ERROR or SKIPPED for the most part.

The unit test and coverage works fine when run-unit-test-docker.sh is run so my guess is something changed in the output of the unit test framework that is not handled by get_unit_test_report.py

Here's the output under a build/meson-logs/ dir:

build/meson-logs/
coverage.info          coverage.info.raw  coveragereport   meson-log.txt  testlog.junit.xml  testlog-ubasan.json       testlog-ubasan.txt     testlog-valgrind.junit.xml
coverage.info.initial  coverage.info.run  install-log.txt  testlog.json   testlog.txt        testlog-ubasan.junit.xml  testlog-valgrind.json  testlog-valgrind.txt

@lkammath is this something you could help look into?

Build scripts use outdated gcc version

Yocto 2.6 uses gcc8, the build scripts should match

Error parsing reference: "ubuntu:bionic as openbmc-base" is not a valid repository/tag

We're getting this on our x86 based CI machines. It works ok on our POWER based CI system so no idea what's going on yet:

https://openpower.xyz/job/openbmc-repository-ci/

12:26:47 + docker build --network=host -t openbmc/ubuntu-unit-test -
12:26:47 Sending build context to Docker daemon 9.728 kB

12:26:47 Step 1/67 : FROM ubuntu:bionic as openbmc-base
12:26:47 Error parsing reference: "ubuntu:bionic as openbmc-base" is not a valid repository/tag: invalid reference format
12:26:47 ++ cleanup
12:26:47 ++ local status=1
12:26:47 ++ '[' -n /tmp/tmp.3hfpsTLe0x ']'
12:26:47 ++ rm -f /tmp/tmp.3hfpsTLe0x
12:26:47 ++ trap - EXIT ERR
12:26:47 ++ exit 1

Install openssl to test certificate in automation

Install openssl to test certificate in automation

Hostboot hbi symbol file not included in build artifacts

Not all the files needed to debug Hostboot are getting stored in openpower.xyz. I know they want the hbi files. Can you add them. This is the list of all files built in a PNOR BIOS image... It may be best just to save them all...

hbicore.bin.modinfo
hbicore.list.bz2
hbicore.syms
hbotStringFile  
cappucode.bin
firestone.pnor
firestone_update.pnor
rootfs.cpio
rootfs.cpio.xz  
rootfs.tar  
skiboot.lid
skiboot.lid.xz
zImage.epapr

The existing limited set is ... https://openpower.xyz/job/openpower-op-build/distro=ubuntu,target=firestone/lastSuccessfulBuild/artifact/images/

build-unit-test-docker.sh: Enable branch support

When we branch for our first release next February, we'll need this script to support taking a branch as input. Can't just keep building the latest master of the dependent repos when a commit is going into a specific branch.

I'm thinking a 3rd parameter where a branch name could be passed in. The script would then retrieve the latest commit in that branch from each dependent repo instead of head.

Thoughts/Comments @amboar @msbarth @wak-google @pstrinkle ?

Need systemd in the unit test docker

I have a problem that I write a new unit test for bmcweb but this test cannot run via the current CI flow. My unit test focuses on the subscription part of Event Service, so it runs bmcweb app partially and mimics a client to check on the broadcasted test events. However, the HTTP part of bmcweb needs systemd-resolved.service to resolve hostnames and thus further depends on systemd while systemd is not supported in the unit test docker, so is it possible to add systemd in the unit test docker?

Intermittent failures when getting docker ip address in run-qemu-robot-test.sh

I've tried a couple fixes for this but not having much luck. Intermittently, our command to get the IP address of the docker container we launch QEMU in with this command:

   DOCKER_QEMU_IP_ADDR="$(docker inspect $obmc_qemu_docker |  \
                       grep -m 1 "IPAddress\":" | cut -d '"' -f 4)"

Gets this error:

13:50:55 ++ docker run --detach --user root --env HOME=/tmp/openbmc/build --env QEMU_RUN_TIMER=600 --env QEMU_ARCH=ppc64le-linux --env QEMU_BIN=./qemu-system-arm --env MACHINE=romulus --workdir /tmp/openbmc/build --volume /home/fspcibld/master-merge-ubuntu-romulus/openbmc/build:/tmp/openbmc/build --tty openbmc/ubuntu-robot-qemu /tmp/openbmc/build/boot-qemu-test.exp
13:50:56 + obmc_qemu_docker=f6111b5364d51f09f6c149688f385c1398bc9b1e96b328767f8f0738a5d9bd07
13:50:56 + DOCKER_SSH_PORT=22
13:50:56 + DOCKER_HTTPS_PORT=443
13:50:56 + trap '' PIPE
13:50:56 ++ docker inspect f6111b5364d51f09f6c149688f385c1398bc9b1e96b328767f8f0738a5d9bd07
13:50:56 ++ grep -m 1 'IPAddress":'
13:50:56 ++ cut -d '"' -f 4
13:50:56 + DOCKER_QEMU_IP_ADDR=172.17.0.3
13:50:56 + echo 141
13:50:56 141

I'm thinking we just ensure the script handles errors properly and remove the "-e" from the top of run-qemu-robot-test.sh.

sanitizer tests fail on ppc64le

After updating our docker Ubuntu to the latest (hirsute) via 7339515?, we started to see a hard fail on the sanitizer tests in CI on ppc64le machines. The fail looks like this:

[107/107] Linking target libpldmresponder/test/libpldmresponder_bios_config_test
[1-23/23] � pldmd_registration_test                                       0/30s
 1/23 libpldm_base_test                                    OK              0.08s
 2/23 libpldm_bios_test                                    OK              0.08s
 3/23 libpldm_bios_table_test                              OK              0.08s
 4/23 libpldm_fru_test                                     OK              0.08s
 5/23 libpldm_pdr_test                                     OK              0.07s
[6-23/23] � pldmd_registration_test                                       0/30s
 6/23 libpldmresponder_bios_string_attribute_test          FAIL            0.05s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=121 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_string_attribute_test

 7/23 libpldm_platform_test                                OK              0.09s
 8/23 libpldm_utils_test                                   OK              0.08s
 9/23 libpldmresponder_base_test                           FAIL            0.07s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=20 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_base_test

10/23 libpldmresponder_bios_test                           FAIL            0.07s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=2 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_test

11/23 libpldmresponder_bios_attribute_test                 FAIL            0.07s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=191 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_attribute_test

12/23 libpldmresponder_bios_config_test                    FAIL            0.06s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=6 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_config_test

13/23 libpldmresponder_bios_integer_attribute_test         FAIL            0.05s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=19 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_integer_attribute_test

14/23 libpldmresponder_bios_table_test                     FAIL            0.05s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=74 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_table_test

15/23 libpldmresponder_fru_test                            FAIL            0.05s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=158 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_fru_test

16/23 libpldmresponder_bios_enum_attribute_test            FAIL            0.06s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=167 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_bios_enum_attribute_test

[17-23/23] � pldmd_registration_test                                      0/30s
17/23 pldm_utils_test                                      FAIL            0.03s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=76 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/common/test/pldm_utils_test

[18-23/23] � pldmd_registration_test                                      0/30s
18/23 pldmd_instanceid_test                                OK              0.03s
19/23 pldmd_registration_test                              OK              0.03s
20/23 libpldmresponder_pdr_effecter_test                   FAIL            0.04s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=61 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_pdr_effecter_test

21/23 dbus_to_host_effecter_test                           FAIL            0.03s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=215 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/host-bmc/test/dbus_to_host_effecter_test

[22-23/23] � libpldmresponder_pdr_sensor_test                             0/30s
22/23 libpldmresponder_pdr_sensor_test                     FAIL            0.04s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=19 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_pdr_sensor_test

[23/23] � libpldmresponder_platform_test                                  0/30s
23/23 libpldmresponder_platform_test                       FAIL            0.05s   killed by signal 6 SIGABRT
>>> MALLOC_PERTURB_=60 /home/jenkins-op/workspace/CI-MISC/ci-repository-ppc64le/openbmc/pldm/build/libpldmresponder/test/libpldmresponder_platform_test



Ok:                 9   
Expected Fail:      0   
Fail:               14  
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0   

To keep making forward progress, the current plan is to just disable this aspects of the tests on ppc64le.

The ppc64le node is running Ubuntu 18 with the latest docker and runc packages installed for that distro. One thing to try is moving the system up to Ubuntu 20 or even 21.

Install ipmitool to run network IPMI in robot

For enabling external/network IPMI in our CT flow, we need to have IPMItool installed on the docker image which is used for running automation.

Does not collect the tar images

part of openbmc/openbmc@b7bc04b changeset, there has been code delivered to tar the image for the bitbake build but jenkins is not able to collect the tar images.

run-qemu-robot-test.sh no longer passes

Not sure if the strings changed or what, but the expect script is not successfully logging into the QEMU image anymore so the run is not proceeding:

09:23:12 Phosphor OpenBMC (Phosphor OpenBMC Project Reference Distro) 0.1.0 qemuarm ttyAMA0

09:23:12 

09:23:12 qemuarm login: root

09:23:12 + grep -q OPENBMC-READY
09:23:12 + sleep 2
09:23:14 + '[' 0 -gt 0 ']'
09:23:14 + '[' 0 -eq 0 ']'
09:23:14 + echo 'Timed out waiting for QEMU, exiting'

build-unit-test-docker.sh: ppc64le: Latest Ubuntu Noble release fails to build - Cannot change mode to rwxr-xr-x: Operation not permitted

Not sure what's going on yet but the latest Ubuntu Noble release is not working with our ppc64le boxes. While building the container, it spews out errors like this (there are 100's of them, seems to be every directory in the tar file):

boost: tar: boost-1.84.0/libs/thread/test/experimental/parallel/v1: Cannot change mode to rwxr-xr-x: Operation not permitted
boost: tar: boost-1.84.0/libs/thread/test/experimental/parallel/v2: Cannot change mode to rwxr-xr-x: Operation not permitted
boost: tar: boost-1.84.0/libs/thread/test/experimental/parallel: Cannot change mode to rwxr-xr-x: Operation not permitted
boost: tar: boost-1.84.0/libs/thread/test/experimental: Cannot change mode to rwxr-xr-x: Operation not permitted
boost: tar: boost-1.84.0/libs/thread/test/sync/futures/when_all: Cannot change mode to rwxr-xr-x: Operation not permitted
boost: tar: boost-1.84.0/libs/thread/test/sync/futures/future: Cannot change mode to rwxr-xr-x: Operation not permitted

It's not just boost, it seems to be all of the tar files we try to download and install.

I manually started up a container and ran the following and hit the error as well:

curl -L https://github.com/boostorg/boost/releases/download/boost-1.84.0/boost-1.84.0.tar.gz | tar -xzv && cd boost* && ./bootstrap.sh --prefix=/usr/local --with-libraries=context,coroutine,url && ./b2 && ./b2 install --prefix=/usr/local

I tried a variety of different options to tar in regards to permission but none of them helped. I verified the same test works fine with the previous Ubuntu release (mantic) on the same machine. This also works fine on our x86 system.

If I manually try to change the dir permissions using chmod, it works fine after the fact (we're running as root in the container so the permission errors really don't make much sense to me).

Meson dependencies check won't pick list items

openbmc-build-scripts/scripts/unit-test.py

Line 758 in d2176ef

pattern = r"dependency\('([^']*)'.*?\)\n"

The patten fails to match dependencies declared in a list, for example,

some_deps = [
  dependency('lib1'),
  dependency('lib2'),
]

r"dependency\('([^']*)'.*?\),?\n" should fix the problem.

Use of sysroots-uninative for ld-linux-x86-64.so.2 breaks running qemu within docker

The new uninative "feature" in yocto has broken a few different things. See openbmc/openbmc#500 for some commentary.

I've been working on getting QEMU to run within it's own docker container for ease of use / portability. It's working well when I build without the uninative feature, but when we do build with it, we get an error with the QEMU binary. I think it's related to the ldd output showing a required library with a full path, that's not valid within the docker session.

My understanding is the uninative feature should have minimal (if any) impact to us so my plan for now is to just disable it build-setup.sh.

Here's the error output and other debug:
17:48:24 ldd

17:48:24 linux-vdso.so.1 => (0x00007fff9af2b000)

17:48:24 libz.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libz.so.1 (0x00007ff5c02c9000)

17:48:24 libbz2.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libbz2.so.1 (0x00007ff5c00b8000)

17:48:24 libpixman-1.so.0 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libpixman-1.so.0 (0x00007ff5bfe0d000)

17:48:24 libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007ff5bfbff000)

17:48:24 libasound.so.2 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libasound.so.2 (0x00007ff5bf8fa000)

17:48:24 libuuid.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libuuid.so.1 (0x00007ff5bf6f5000)

17:48:24 libSDL-1.2.so.0 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libSDL-1.2.so.0 (0x00007ff5bf495000)

17:48:24 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff5bf277000)

17:48:24 libX11.so.6 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libX11.so.6 (0x00007ff5bef3c000)

17:48:24 libfdt.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libfdt.so.1 (0x00007ff5bed35000)

17:48:24 libglib-2.0.so.0 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/libglib-2.0.so.0 (0x00007ff5bea28000)

17:48:24 librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007ff5be820000)

17:48:24 libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff5be49e000)

17:48:24 libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff5be194000)

17:48:24 libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff5bdf7e000)

17:48:24 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff5bdbb5000)

17:48:24 /var/lib/jenkins/workspace/openbmc-build-gerrit-trigger-multi/distro/ubuntu/target/qemu/openbmc/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x0000556d24c1c000)

17:48:24 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff5bd9b0000)

17:48:24 libXrandr.so.2 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/./libXrandr.so.2 (0x00007ff5bd7a5000)

17:48:24 libXext.so.6 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/./libXext.so.6 (0x00007ff5bd592000)

17:48:24 libxcb.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/./libxcb.so.1 (0x00007ff5bd372000)

17:48:24 libpcre.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/./libpcre.so.1 (0x00007ff5bd12e000)

17:48:24 libXrender.so.1 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/././libXrender.so.1 (0x00007ff5bcf24000)

17:48:24 libXau.so.6 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/././libXau.so.6 (0x00007ff5bcd1f000)

17:48:24 libXdmcp.so.6 => /home/openbmc/./tmp/sysroots/x86_64-linux/usr/bin/../lib/././libXdmcp.so.6 (0x00007ff5bcb19000)

ls -al ./tmp/sysroots/x86_64-linux/usr/bin/qemu-system-arm
17:48:24 -rwxr-xr-x 1 1003 1003 15364880 Aug 11 04:25 ./tmp/sysroots/x86_64-linux/usr/bin/qemu-system-arm

17:48:24 /home/openbmc/boot-qemu.sh: line 17: ./tmp/sysroots/x86_64-linux/usr/bin/qemu-system-arm: No such file or directory

17:48:24
17:48:24 Failure, got EOF'

[Barreleye/Palmetto - build v1.0-89-g5bc571e-dirty ] Unexpected build version suffix

Reference : openbmc/openbmc-test-automation#43

The version has -dirty in the build version..

Example '"v1.0-89-g5bc571e-dirty"'