[PATCH 1/1] Bugfix: add a check for "None" to raise a WicError

[Ulrich Teichert]

Add a check for "None" to raise a WicError because
get_bitbake_var may return "None" if the variable is not available, which
would result in an exception inside os.path.isdir and not to the WicError
exception as intended.

Signed-off-by: Ulrich Teichert <ulrich....@ebs-group.io>

---
scripts/lib/wic/plugins/source/rootfs.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/source/rootfs.py b/scripts/lib/wic/plugins/source/rootfs.py
index e29f3a4c..977ac0d3 100644
--- a/scripts/lib/wic/plugins/source/rootfs.py
+++ b/scripts/lib/wic/plugins/source/rootfs.py
@@ -54,7 +54,7 @@ class RootfsPlugin(SourcePlugin):
return os.path.realpath(rootfs_dir)

image_rootfs_dir = get_bitbake_var("IMAGE_ROOTFS", rootfs_dir)
- if not os.path.isdir(image_rootfs_dir):
+ if image_rootfs_dir == None or not os.path.isdir(image_rootfs_dir):
raise WicError("No valid artifact IMAGE_ROOTFS from image "
"named %s has been found at %s, exiting." %
(rootfs_dir, image_rootfs_dir))
--
2.47.3

Mit
besten Grüßen / Best regards 

Dipl.-Inform.
Ulrich
Teichert
Senior
Software Engineer

T→ +49 431 375938-0
ebs-group.io
_____________________________________

e.bs kumkeo
GmbH

Am
Kiel-Kanal 1

24106
Kiel, Deutschland
Geschäftsführer
→ Michael Leitner, Günter Hagspiel

Registergericht →
Amtsgericht Hamburg

Registernummer → HRB 187712

USt-Idnr.
→ DE449906070

[MOESSBAUER, Felix]

On Wed, 2026-07-15 at 06:41 +0000, 'Ulrich Teichert' via isar-users
wrote:

> Add a check for "None" to raise a WicError because
> get_bitbake_var may return "None" if the variable is not available, which
> would result in an exception inside os.path.isdir and not to the WicError
> exception as intended.

Hi,

did you also send this patch to OE? Changes in the wic plugins that are
not purely isar related have to be accepted by OE first (to avoid that
our plugins diverge up to the point of not being able to update them
anymore).

Felix

> --
> You received this message because you are subscribed to the Google Groups "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to isar-users+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/isar-users/DB9PR08MB744889FBE7B009B67B506A47C3F82%40DB9PR08MB7448.eurprd08.prod.outlook.com.

[Ulrich Teichert]

Hi Felix,

>> Add a check for "None" to raise a WicError because
>> get_bitbake_var may return "None" if the variable is not available, which
>> would result in an exception inside os.path.isdir and not to the WicError
>> exception as intended.

>Hi,
>
>did you also send this patch to OE? Changes in the wic plugins that are
>not purely isar related have to be accepted by OE first (to avoid that
>our plugins diverge up to the point of not being able to update them
>anymore).

No, I wasn't aware of the fact that the rootfs plugin comes from stock OE - but
in that case I'll divert my patch in that direction ;-)

BTW, is there a rule or a list what is from stock OE in Isar and what isn't?

CU,
Uli

[MOESSBAUER, Felix]

On Wed, 2026-07-15 at 09:04 +0000, Ulrich Teichert wrote:
> Hi Felix,
>
> > > Add a check for "None" to raise a WicError because
> > > get_bitbake_var may return "None" if the variable is not available, which
> > > would result in an exception inside os.path.isdir and not to the WicError
> > > exception as intended.
>
> > Hi,
> >
> > did you also send this patch to OE? Changes in the wic plugins that are
> > not purely isar related have to be accepted by OE first (to avoid that
> > our plugins diverge up to the point of not being able to update them
> > anymore).
>
> No, I wasn't aware of the fact that the rootfs plugin comes from stock OE - but
> in that case I'll divert my patch in that direction ;-)

Thanks!

>
> BTW, is there a rule or a list what is from stock OE in Isar and what isn't?

Unfortunately not that I'm aware of.
Some parts like bitbake, oe-libs and the sstate.bbclass are taken as-
is. Other parts like the wic plugins are patched versions of upstream.

I hope this will get better once isar also splits the repo into
upstream bitbake and the isar-core layer (as Yocto already did). But
I'm not sure if and when that will happen.

Maybe the maintainers can say something about this.

Best regards,
Felix

>
> CU,
> Uli

[Anton Mikanovich]

Having bitbake as (for example) submodule is a good approach, but it is not
really possible until we have patches on top of upstream bitbake, like:

da17d920 ("bitbake: Downgrade python requirements")

Which is still needed for Debian Buster compatibility.
We can't even update bitbake version currently because of old Python
version in
Buster, which results in one more patch on top:

34c3cda5 ("bitbake: Remove custom exception backtrace formatting")

So we can get rid of having in-tree Bitbake copy only after dropping Debian
Buster.

[Ulrich Teichert]

Hi,

>On Wed, 2026-07-15 at 09:04 +0000, Ulrich Teichert wrote:
>> Hi Felix,
>>
>> > > Add a check for "None" to raise a WicError because
>> > > get_bitbake_var may return "None" if the variable is not available, which
>> > > would result in an exception inside os.path.isdir and not to the WicError
>> > > exception as intended.
>>
>> > Hi,
>> >
>> > did you also send this patch to OE? Changes in the wic plugins that are
>> > not purely isar related have to be accepted by OE first (to avoid that
>> > our plugins diverge up to the point of not being able to update them
>> > anymore).
>>
>> No, I wasn't aware of the fact that the rootfs plugin comes from stock OE - but
>> in that case I'll divert my patch in that direction ;-)

Well, on OE-core this has been so completely overhauled (inheritance instead of
plugins, include-path hook does not even exist) that my patch doesn't make sense
there... Adopting it into Isar would not make matters worse, I'd say...

CU,
Uli

[MOESSBAUER, Felix]

IMHO we need to rework the imaging to run the bitbake parts only
outside of the chroot. But this requires some non-trivial
refactoring...

Felix

[Jan Kiszka]

Indeed.

As long as buster is in ELTS and Isar has no stable version maintainer
for continue building it, users are kind of forced to update Isar for
receiving bug fixes while then losing support of their target distro
release.

And what is buster today may be trixie the other year.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Anton Mikanovich]

Or maybe run them in chroot of distro version other/newer then Buster...
Running something on host require additional dependencies, which push us
from
Yocto deps concept (minimal tools needed) to Debian one (all the tools
needed).