From: Jan Kiszka <jan.kiszka@siemens.com>
To: isar-users <isar-users@googlegroups.com>,
Uladzimir Bely <ubely@ilbers.de>
Subject: sbuild race with sporadic build breakages
Date: Thu, 23 May 2024 19:08:46 +0200 [thread overview]
Message-ID: <187215a1-ff1b-48b4-979f-9b49689a78e7@siemens.com> (raw)
Hi all,
I think I've seen it before but didn't look closer so far:
2024-05-23 15:16:22 - INFO - Log data follows:
2024-05-23 15:16:22 - INFO - | DEBUG: Executing python function sstate_task_prefunc
2024-05-23 15:16:22 - INFO - | DEBUG: Python function sstate_task_prefunc finished
2024-05-23 15:16:22 - INFO - | DEBUG: Executing python function do_dpkg_build
2024-05-23 15:16:22 - INFO - | DEBUG: Executing shell function dpkg_schroot_create_configs
2024-05-23 15:16:22 - INFO - | Creating /etc/schroot/chroot.d/isar-builder-3cef593b-e753-4463-a544-cea3d14532e2-39837
2024-05-23 15:16:22 - INFO - | DEBUG: Shell function dpkg_schroot_create_configs finished
2024-05-23 15:16:22 - INFO - | DEBUG: Executing shell function dpkg_runbuild
2024-05-23 15:16:22 - INFO - | sbuild (Debian sbuild) 0.85.0 (04 January 2023) on runner-czqurwfpg-project-10191315-concurrent-25-hauy0e5m
2024-05-23 15:16:22 - INFO - |
2024-05-23 15:16:22 - INFO - | +==============================================================================+
2024-05-23 15:16:22 - INFO - | | linux-cip-rt 5.10.214-cip46-rt19+r0 (arm64) Thu, 23 May 2024 15:16:21 +0000 |
2024-05-23 15:16:22 - INFO - | +==============================================================================+
2024-05-23 15:16:22 - INFO - |
2024-05-23 15:16:22 - INFO - | Package: linux-cip-rt
2024-05-23 15:16:22 - INFO - | Version: 5.10.214-cip46-rt19+r0
2024-05-23 15:16:22 - INFO - | Source Version: 5.10.214-cip46-rt19+r0
2024-05-23 15:16:22 - INFO - | Distribution: isar
2024-05-23 15:16:22 - INFO - | Machine Architecture: amd64
2024-05-23 15:16:22 - INFO - | Host Architecture: arm64
2024-05-23 15:16:22 - INFO - | Build Architecture: amd64
2024-05-23 15:16:22 - INFO - | Build Profiles: kernel debian nolibcdev cross
2024-05-23 15:16:22 - INFO - | Build Type: binary
2024-05-23 15:16:22 - INFO - |
2024-05-23 15:16:22 - INFO - | E: /etc/schroot/chroot.d/isar-builder-3cef593b-e753-4463-a544-cea3d14532e2-41541: Failed to stat file: No such file or directory
2024-05-23 15:16:22 - INFO - | E: debconf-set-selections failed
2024-05-23 15:16:22 - INFO - | Failed to set up chroot
2024-05-23 15:16:22 - INFO - | E: Error creating chroot session: skipping linux-cip-rt
(https://gitlab.com/cip-project/cip-core/isar-cip-core/-/jobs/6923376323)
So, we are not finding in dpkg_runbuild the schroot we created just
before. Looking at why the the former may look for a different schroot,
this jumped at me:
SBUILD_CHROOT ?= "${DEBDISTRONAME}-${SCHROOT_USER}-${ISAR_BUILD_UUID}-${@os.getpid()}"
We are using some pid of the calling process here, and we assume that
this pid is only taken once (or at least over the same process) so that
there are no difference in SBUILD_CHROOT down the line. But if you look
at the log above, that seems to have happened: the last number is
different.
I'm not yet understanding why the evaluation may happen multiple times
and also why it then only rarely causes this, but I also wonder if we
shouldn't better enforce an immediate, single evaluation of os.getpid to
avoid that risk.
Along this, I wonder why we make all those variables here weak. Is there
really a use case for overwriting them? Not in-tree, apparently.
Jan
--
Siemens AG, Technology
Linux Expert Center
next reply other threads:[~2024-05-23 17:09 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 17:08 Jan Kiszka [this message]
2024-05-24 7:26 ` MOESSBAUER, Felix
2024-05-24 8:08 ` Anton Mikanovich
2024-05-24 8:52 ` Jan Kiszka
2024-05-24 9:30 ` Anton Mikanovich
2024-05-24 10:42 ` Jan Kiszka
2024-05-24 11:55 ` Anton Mikanovich
2024-06-17 7:44 ` Jan Kiszka
2024-06-17 8:32 ` Baurzhan Ismagulov
2024-06-17 12:55 ` Jan Kiszka
2024-06-17 14:12 ` Anton Mikanovich
2024-06-17 14:50 ` Jan Kiszka
2024-06-24 8:00 ` Uladzimir Bely
2024-06-24 9:13 ` Jan Kiszka
2024-09-09 10:53 ` Anton Mikanovich
2024-10-01 7:35 ` 'Jan Kiszka' via isar-users
2024-11-11 9:31 ` 'Jan Kiszka' via isar-users
2024-11-11 10:44 ` Anton Mikanovich
2024-11-11 12:04 ` 'Jan Kiszka' via isar-users
2024-11-11 14:28 ` 'Jan Kiszka' via isar-users
2024-11-11 14:37 ` Anton Mikanovich
2024-11-11 14:52 ` 'Jan Kiszka' via isar-users
2024-11-11 15:17 ` Anton Mikanovich
2024-11-11 15:56 ` 'Jan Kiszka' via isar-users
2024-11-11 17:58 ` 'MOESSBAUER, Felix' via isar-users
2024-11-11 19:48 ` 'Jan Kiszka' via isar-users
2024-11-13 6:51 ` 'MOESSBAUER, Felix' via isar-users
2024-11-13 7:00 ` 'Jan Kiszka' via isar-users
2024-12-05 15:57 ` Anton Mikanovich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=187215a1-ff1b-48b4-979f-9b49689a78e7@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=ubely@ilbers.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox