From: Henning Schild <henning.schild@siemens.com>
To: Baurzhan Ismagulov <ibr@radix50.net>
Cc: isar-users@googlegroups.com
Subject: Re: [PATCH] wic-img: use python3.9 in bookworm
Date: Thu, 21 Apr 2022 09:36:22 +0200 [thread overview]
Message-ID: <20220421093622.4f45b7f1@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <YmAy9EewClooOQeR@ilbers.de>
Am Wed, 20 Apr 2022 18:21:08 +0200
schrieb Baurzhan Ismagulov <ibr@radix50.net>:
> On Wed, Apr 20, 2022 at 03:04:48PM +0200, Henning Schild wrote:
> > I wonder why CI did not find that like 30 days ago ... are the
> > bookworm tests allowed to fail, or what is that KFAIL thing?
> >
> > If so, why? and is that still valid?
>
> KFAIL is "known failure" similar to that in GNU development (gdb,
> etc.). Bookworm uses it since its initial introduction because the
> upstream is not stable, so it's still valid IMO.
It is more than valid, with the same argument you could say you would
not want to support it at all. We do product dev on testing so we get
the most out of the stable-phase and can detect problems early enough
for upstream fixes.
> We could convert bookworm to fail (by dropping try-except and calling
> self.perform_build_test() directly); in that case, any upstream
> problems would have to be analyzed quickly, and we might have to wait
> for upstream fixes. For our maintenance work, we'd have to implement
> some support for local KFAIL tagging.
I guess we want to be aware of any upstream problem. That will cause
some friction but hopefully not too much. If concrete issues block isar
dev we could disable for a moment or merge a red pipeline. But running
such expensive CI and ignoring the result is kind of pointless, at
least i do not read CI logs regularly.
Also i think in the old CI we had bullseye without "allowed to fail"
for some time, way before it was stable. And i do not even remember
buster.
I am all for "bookwork has to succeed in CI"! We have several bookworm
layer CIs which found that downstream, now they all need to understand
and try to fix on their own.
> The issue is seen in
> http://ci.isar-build.org:8080/job/isar_next/1328/console (green due
> to KFAIL), but not in earlier runs.
>
> (10/23)
> /build-auto/isar_next/1328/testsuite/citest.py:NoCrossTest.test_nocross_bookworm:
> ERROR: mc:qemui386-bookworm:isar-image-base-1.0-r0 do_wic_image:
> Error executing a python function in...
>
>
> > > --- a/meta/classes/wic-img.bbclass
> > > +++ b/meta/classes/wic-img.bbclass
> > > @@ -192,11 +192,16 @@ generate_wic_image() {
> > > mkdir -p /usr/bin/python3-native/
> > > if [ $(head -1 $(which bmaptool) | grep python3) ];then
> > > ln -fs /usr/bin/python3
> > > /usr/bin/python3-native/python3
> > > + # python 3.10 is too new for our bitbake version
> > > + if [ "$( readlink /usr/bin/python3 )" = "python3.10"
> > > ]; then
> > > + ln -fs /usr/bin/python3.9
> > > /usr/bin/python3-native/python3
>
> Wow, I'd expect they'd have update-alternatives for that, but seems
> they don't.
Even if, it should not be used as long as the buildchroot is used for
building all recipes. Otherwise this step would switch from 3.10 to 3.9
and the next recipe would get 3.9.
>
> > > --- a/meta/conf/distro/debian-bookworm.conf
> > > +++ b/meta/conf/distro/debian-bookworm.conf
> > > @@ -6,6 +6,8 @@ BASE_DISTRO_CODENAME = "bookworm"
> > >
> > > HOST_DISTRO ?= "debian-${BASE_DISTRO_CODENAME}"
> > >
> > > +WIC_IMAGER_INSTALL += "python3.9-distutils"
>
> We've started testing this, but I wonder how this works. When I
> debootstrap bookworm, it picks python3-distutils and installs
> python3.10.
Yes, and you add this one as well ... also pulling in 3.9. You will
have both python versions installed.
> Bitbake 1.50.4 has been picked as the last tagged version before
> overrides syntax change. Please let us know whether bitbake 1.50.5
> works; in that case we wouldn't have to swim against the upstream.
It does work but also needs a wic bump, which also does work. I am
working on that already but am not sure how quick that will be. Maybe i
get it done today.
If you at ilbers want a quick workaround and this one here is
acceptable, please take it and i will revert it with the bumps. While
some people claim that their layers do not build anymore ... which i am
sure is right ... it can not be too pressing given they did not find it
30 days ago when bookworm switched to python 3.10.
It is a thing that would be nice to solve quickly, but not in a hurry.
regards,
Henning
>
> With kind regards,
> Baurzhan.
>
next prev parent reply other threads:[~2022-04-21 7:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 13:02 Henning Schild
2022-04-20 13:04 ` Henning Schild
2022-04-20 16:21 ` Baurzhan Ismagulov
2022-04-21 7:36 ` Henning Schild [this message]
2022-04-20 14:09 ` Henning Schild
2022-04-20 14:20 ` Bezdeka, Florian
2022-04-20 14:20 ` Moessbauer, Felix
2022-04-20 14:23 ` Henning Schild
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=20220421093622.4f45b7f1@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=ibr@radix50.net \
--cc=isar-users@googlegroups.com \
/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