HI all, Hi Richard thx for quick response.
Generally this patch for tar has been already applied to the upstream 
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=5461025569c2d946fb31b79f16f60e923bbd79f9
Additionally a new version 1.35 has been released which has this fix applied as 
well.

> Are you saying we need to patch tar in order for these patches to work?

Unfortunately yes, but still this error, which occurs on autobuilder should not 
happen, because the patch for ACLs and xattrs only
changes the writing algorithm to the tar file - meaning, when --numeric-owner 
parameter is being used all uid(s)/gid(s) are written
with numbers instead of names.

> WARNING: core-image-sato-1.0-r0 do_rootfs: [log_check] core-image-sato: found 
> 4 warning messages in the logfile:
> [log_check] Warning when reading ar archive header: Pathname can't be 
> converted from UTF-8 to current locale. (errno=84)
> [log_check] Warning when reading ar archive header: Pathname can't be 
> converted from UTF-8 to current locale. (errno=84)
> [log_check] Warning when reading ar archive header: Pathname can't be 
> converted from UTF-8 to current locale. (errno=84)
> [log_check] Warning when reading ar archive header: Pathname can't be 
> converted from UTF-8 to current locale. (errno=84)

This one is also occurring on our side, but I thought that it is irrelevant as 
it's just a warning and everything is working fine. Generally
I have investigated it and it occurs that this error occurs from opkg source 
code https://git.yoctoproject.org/opkg/tree/libopkg/opkg_archive.c#n272
I added a debug code in here like that:

        opkg_msg(NOTICE, "Warning when reading ar archive header: %s (errno=%d) 
LC_CTYPE=%s LC_ALL=%s\n",
                 archive_error_string(ar), archive_errno(ar), 
setlocale(LC_CTYPE, NULL), setlocale(LC_ALL, NULL));

to actually see what are the LC values and it occurred that it is equal C. 
Afterwards my investigations were focused on whom is calling
the opkg command, maybe it is changing somehow locales and this is being 
executed in here 
http://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n368
but to my surprise LC_ALL which is being passed through os.environ is proper 
and equals
LC_ALL: 'en_US.UTF-8'

My guess is that opkg runs fork process to actually install all depends, 
because in log.do_rootfs file from this 
http://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/ipk/__init__.py#n366
line I don't see the whole list of all packages that are being installed.

A stupid fix for that was to set LC_ALL in opkg with:

setlocale(LC_ALL, "en_US.UTF-8");

to check if it fixes the issue and yes it fixes but this is no go.

Question is probably now to Alex does opkg can run fork instances for depends? 
Because I have found that it uses this vfork,
however I dunno if it uses parent's process env variables or it's own. I think 
that this needs further investigations...

BR
Piotr

Od: Richard Purdie <richard.pur...@linuxfoundation.org>
Wysłane: środa, 19 lipca 2023 10:37
Do: Piotr Łobacz <p.lob...@welotec.com>; Alexandre Belloni 
<alexandre.bell...@bootlin.com>
DW: Alex Stewart <alex.stew...@ni.com>; 
openembedded-core@lists.openembedded.org 
<openembedded-core@lists.openembedded.org>
Temat: Re: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro 
native features support

On Wed, 2023-07-19 at 07:53 +0000, Piotr Łobacz wrote:
> I'm running this on docker with ubuntu 22.04 LTS and I have patched
> tar 1.34 with the patch I have given to you. I know that it contains
> these parameters, but they are faulty - meaning the ACLs do not
> preserve uid/gid in tar archive.

Are you saying we need to patch tar in order for these patches to work?

> Nevertheless this concerns me that opkg-build command should not
> fail. Additionally I have tested yesterday running my build without
> acl and xattr in DISTRO_FEATURES and it also worked for me - without
> applaying acls and xattrs to tar archive.
> Generally I need to reproduce your error and it seems to me that
> there is no other option as to re-create exactly the same environment
> on my machine locally, so I could investigate it.
>
> My question is how can we achive it in the simplest way? Does
> autobuilder use a docker for building?Because if so, I could take
> these docker scripts, run them and check what's happening.

The autobuilders are standard installs of various distros. We keep them
matching upstream and the list of installed software minimal.

There are more issues in this patch series. For example there is this
reproducibility issue:

https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/3219/steps/13/logs/stdio

which is saying there were two sets of different ipk packages produced.
These are available here:

http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230718-bn_npkdc/packages/

sadly the automatic diffoscope output wasn't generated.

Worryingly this report suggests the opkg-build change is not
deterministic.

FWIW this is just with the opkg-build change and the bitbake.conf
change, not the other patches.

These two changes alone also cause these warnings:

https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/7436/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/7436/steps/18/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/44/builds/7509/steps/21/logs/stdio

e.g. things like:

WARNING: core-image-sato-1.0-r0 do_rootfs: [log_check] core-image-sato: found 4 
warning messages in the logfile:
[log_check] Warning when reading ar archive header: Pathname can't be converted 
from UTF-8 to current locale. (errno=84)
[log_check] Warning when reading ar archive header: Pathname can't be converted 
from UTF-8 to current locale. (errno=84)
[log_check] Warning when reading ar archive header: Pathname can't be converted 
from UTF-8 to current locale. (errno=84)
[log_check] Warning when reading ar archive header: Pathname can't be converted 
from UTF-8 to current locale. (errno=84)

so there is a further issue to investigate there.

All in all, there are a lot of issues with this patch series :(.

Cheers,

Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184583): 
https://lists.openembedded.org/g/openembedded-core/message/184583
Mute This Topic: https://lists.openembedded.org/mt/100235103/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to