a while back I reported an uninitialized value in Config.pm (not sure
what the context was), but now I'm seeing it again in the code path
added.
...
Preparing to unpack .../libc6_2.41-6_arm64.deb ...
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/Config.pm line 23.
Unpacking libc6:arm64 (2.41-6) ...
...
Setting up libc6:arm64 (2.41-6) ...
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/Config.pm line 23.
Setting up mawk (1.3.4.20250131-1) ...
...
Setting up debconf (1.5.91) ...
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/Config.pm line 23.
Setting up libpam0g:arm64 (1.7.0-3) ...
Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Debconf/Config.pm line 23.
Setting up libpam-modules-bin (1.7.0-3) ...
...
Unpacking libdebconfclient0:arm64 (0.278) ...
Selecting previously unselected package base-passwd.
Preparing to unpack .../base-passwd_3.6.7_arm64.deb ...
Unpacking base-passwd (3.6.7) ...
Selecting previously unselected package init-system-helpers.
...
Setting up base-passwd (3.6.7) ...
...
This is part of mkosi-initrd output. The late configuration of
base-passwd strikes as odd. Looking into the source, the right side of
the concatenation is a bare string, so it likely is the left side
calling getpwuid that produces undef here.
Do you consider that a bug in debconf? An option would be skipping any ~/.debconfrc if neither DEBCONF_SYSTEMRC is set nor getpwuid returns
somethig sensible?
If you consider this unreasonable, we should likely discuss the
semantics of bootstrap e.g. on the debian-cross@l.d.o list before
reaching a conclusion of bugginess in mkosi. The ordering has been a
recurring topic.