Re: [OE-core] systemd service@ bug

[Yuta Hayama]

Hi,

On 2023/07/19 16:47, Vyacheslav Yurkov wrote:
> Hey,
> Usually Steve Sakoman cherry-picks patches from master. If it's not the case, 
> it was probably not applied clearly or simply overlooked. You can submit a 
> backport with the branch tag.

Thank you! I understood.

I checked git log and it looked like it usually takes around a month to be
backported, so I will wait until then.


Regards,

Yuta Hayama 

> 
> Vyacheslav
> 
> On 19.07.2023 03:48, Yuta Hayama wrote:
>> Hi,
>>
>> This issue has been fixed in master.
>> https://git.openembedded.org/openembedded-core/commit/?id=d18b939fb08b37380ce95934da38e6522392621c
>>
>> But, yes. This patch has not yet been backported to the any stable branch.
>>
>>
>> I don't know about the maintenance process for the stable branch, but I
>> expect that patch will probably be queued and backported to dunfell in
>> a month or so.
>>
>> Please let me know if anyone knows anything about this. Should we simply
>> wait? Or do I have to submit a backport request?
>>
>>
>> Regards,
>>
>> Yuta Hayama
> 
> 
> 
> 
> 

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

Re: [OE-core] [PATCH v3] qemu: Add qemu-common package

[Yu, Mingli]

Hi Richard,

On 7/19/23 18:08, Richard Purdie wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Wed, 2023-07-19 at 17:39 +0800, Yu, Mingli wrote:

On 7/19/23 17:24, Richard Purdie wrote:


It is relevant, this is because of the dependency that this gets built
and fails. I've seen v4 but didn't have the time to test it yet.


I've still not seen an answer to Ross' question or mine about why we
can't just add a couple of dependencies and resolve things that way.


Sorry for delayed respond!

Have added qemu-common to make qemu as meta package to keep backward
compatibility. For user who install qemu rpm such as
qemu-7.2.0-r0.corei7_64.rpm, it still pull in all of things as before.
For user who cares the rpm size, can just choose to install the needed
qemu arch rpms such as qemu-system-aarch64-7.2.0-r0.corei7_64.rpm.


So why not just add:

RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all"

as I think we've then covered all the options we need?


If just add RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all" by 
default, then how about the user who want only install 
qemu-system-aarch64-7.2.0-r0.corei7_64.rpm still install all qemu 
binaries as qemu-system-aarch64 rdepends on qemu which RRECOMMENDS 
qemu-system-all and 
qemu-user-all(https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db).


So it's better make qemu as meta package to keep backward compatibility 
for user who install qemu can install all qemu binaries as before and 
also can meet the need for user who want just install qemu arm64 
emulation rpm such as 
qemu-system-aarch64-7.2.0-r0.corei7_64.rpm(https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/) 
via adding IMAGE_INSTALL:append = " qemu-system-aarch64" into 
conf/local.conf.


Thanks,



Cheers,

Richard

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

Re: [OE-core] [PATCH] python3-jsonschema: upgrade 4.17.3 -> 4.18.3

[Alexandre Belloni via lists.openembedded.org]

This fails:

https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5489/steps/14/logs/stdio

2023-07-19 16:59:12,999 - oe-selftest - INFO - 
bblayers.BitbakeLayers.test_bitbakelayers_setup (subunit.RemotedTestCase)
2023-07-19 16:59:13,001 - oe-selftest - INFO -  ... FAIL
Stderr:
2023-07-19 16:54:28,044 - oe-selftest - INFO - Adding: "include selftest.inc" 
in 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/conf/local.conf
2023-07-19 16:54:28,044 - oe-selftest - INFO - Adding: "include bblayers.inc" 
in bblayers.conf
2023-07-19 16:59:13,001 - oe-selftest - INFO - 2: 5/42 34/529 (20.90s) (0 
failed) (bblayers.BitbakeLayers.test_bitbakelayers_setup)
2023-07-19 16:59:13,001 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/bblayers.py",
 line 152, in test_bitbakelayers_setup
self.validate_layersjson(jsonfile)
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/bblayers.py",
 line 143, in validate_layersjson
result = runCmd("{} {} -i {} {}".format(python, jsonvalidator, json, 
jsonschema))
 

  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/utils/commands.py",
 line 212, in runCmd
raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % 
(command, result.status, exc_output))
AssertionError: Command 
'/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/tmp/work/x86_64-linux/python3-jsonschema-native/4.18.3-r0/recipe-sysroot-native/usr/bin/nativepython3
 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/tmp/work/x86_64-linux/python3-jsonschema-native/4.18.3-r0/recipe-sysroot-native/usr/bin/jsonschema
 -i 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/meta-selftest/setup-layers.json
 
/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/files/layers.schema.json'
 returned non-zero exit status 1:
Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/tmp/work/x86_64-linux/python3-jsonschema-native/4.18.3-r0/recipe-sysroot-native/usr/bin/jsonschema",
 line 5, in 
from jsonschema.cli import main
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/tmp/work/x86_64-linux/python3-jsonschema-native/4.18.3-r0/recipe-sysroot-native/usr/lib/python3.11/site-packages/jsonschema/__init__.py",
 line 13, in 
from jsonschema._format import FormatChecker
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/tmp/work/x86_64-linux/python3-jsonschema-native/4.18.3-r0/recipe-sysroot-native/usr/lib/python3.11/site-packages/jsonschema/_format.py",
 line 11, in 
from jsonschema.exceptions import FormatError
  File 
"/home/pokybuild/yocto-worker/oe-selftest-fedora/build/build-st-2056592/tmp/work/x86_64-linux/python3-jsonschema-native/4.18.3-r0/recipe-sysroot-native/usr/lib/python3.11/site-packages/jsonschema/exceptions.py",
 line 15, in 
from referencing.exceptions import Unresolvable as _Unresolvable
ModuleNotFoundError: No module named 'referencing'


Please, test your series before sending them out!


On 17/07/2023 17:10:22+0800, wangmy wrote:
> From: Wang Mingyu 
> 
> Changelog:
> =
> -Properly preserve applicable_validators in extended validators.
> -Fix an additional regression with the deprecated
>  jsonschema.RefResolver and pointer resolution.
> -Fix a regression with jsonschema.RefResolver based resolution when used in
>  combination with a custom validation dialect (via 
> jsonschema.validators.create).
> 
> Signed-off-by: Wang Mingyu 
> ---
>  ...ython3-jsonschema_4.17.3.bb => python3-jsonschema_4.18.3.bb} | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-devtools/python/{python3-jsonschema_4.17.3.bb => 
> python3-jsonschema_4.18.3.bb} (93%)
> 
> diff --git a/meta/recipes-devtools/python/python3-jsonschema_4.17.3.bb 
> b/meta/recipes-devtools/python/python3-jsonschema_4.18.3.bb
> similarity index 93%
> rename from meta/recipes-devtools/python/python3-jsonschema_4.17.3.bb
> rename to meta/recipes-devtools/python/python3-jsonschema_4.18.3.bb
> index 24cde3711c..6ce2259f16 100644
> --- a/meta/recipes-devtools/python/python3-jsonschema_4.17.3.bb
> +++ b/meta/recipes-devtools/python/python3-jsonschema_4.18.3.bb
> @@ -4,7 +4,7 @@ LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=7a60a81c146ec25599a3e1dabb8610a8 \
>  file://json/LICENSE;md5=9d4de43111d33570c8fe49b4cb0e01af"
>  
> -SRC_URI[sha256sum] = 
> "0f864437ab8b6076ba6707453ef8f98a6a0d512a80e93f8abdb676f737ecb60d"
> +SRC_URI[sha256sum] = 
> "64b7104d72efe856bea49ca4af37a14a9eba31b40bb7238179f3803130fd34d9"
>  
>  inherit pypi python_hatchling
>  
> -- 
> 

[OE-core] OpenEmbedded Happy Hour July 26 5pm/1700 UTC

[Denys Dmytriyenko]

All,

A friendly reminder - our regular monthly OpenEmbedded Happy Hour is 1 week 
away, on July 26 for Europe/Americas timezones @ 1700/5pm UTC (1pm ET/10am PT)

https://www.openembedded.org/wiki/Calendar
https://www.openembedded.org/wiki/Happy_Hours
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+July+26=20230726T17

-- 
Regards,
Denys Dmytriyenko 
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

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

Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Bruce Ashfield]

On Wed, Jul 19, 2023 at 4:10 PM Petr Gotthard
 wrote:
>
> Thanks Bruce,
>
> > -Original Message-
> > From: Bruce Ashfield 
> > Sent: Wednesday, July 19, 2023 7:44 PM
> > To: Petr Gotthard 
> > Cc: openembedded-core@lists.openembedded.org
> > Subject: Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION
> >
> > Hmm.
> >
> > I explicitly tested this scenario to make sure it worked, since you run 
> > into the
> > same issue when building modules on-target.
> >
> > make-mod-scripts is running out of the same SCM as the main kernel build, 
> > so it
> > should match, and did in my testing (otherwise lttng-modules wouldn't work).
> >
> > Can you send the exact steps, which kernel recipe you are using, etc.
> > That way I can reproduce the problem locally.
> >
>
> I am using an AM335x with meta-ti (latest master). I think that the 
> "beaglebone" might be close enough.
> I did not set any kernel versions explicitly. The KERNEL_LOCALVERSION is set 
> by the meta-ti itself in their setup-defconfig.inc:
> https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-kernel/linux/setup-defconfig.inc

I'm not familiar with what meta-ti's recipes do with respect to kernel
configuration, so I'm only commenting on what I just skimmed from the
link you provided.

Not directly related, but what is going on with .scmversion in that
.inc, will probably break in kernels 6.3+, which is what I'm trying to
head off with the movement of KERNEL_LOCALVERSION/LOCALVERSION to the
base class, it needs to be visible in multiple places.

>
> The kernel is "linux-ti-staging_6.1" with quite standard settings. Recently I 
> did explicitly set
> CONFIG_LOCALVERSION_AUTO=n
> which was "y" by default. With the default "y" setting I was getting a kernel 
> version with two identical suffixes ("6.1.33-g8f7f371be2-g8f7f371be2", 
> whereas the make-mod-scripts used "6.1.33-g8f7f371be2").

Did that only start happening recently ? because with the
localversion_auto and a set .scmversion, that's what I'd expect to
happen (see below).

>
> The out-of-tree modules I am building are using recipes almost identical to 
> the "poky/meta-skeleton/recipes-kernel/hello-mod". Again, no kernel version 
> specified.
>
> I tried to build the lttng-modules and see the same issue: "modinfo 
> lttng-clock.ko" returns
> filename:   
> /home/...-linux-gnueabi/lttng-modules/2.13.9-r0/packages-split/kernel-module-lttng-clock-6.1.33-g8f7f371be2/lib/modules/6.1.33-g8f7f371be2/kernel/lttng-modules/lttng-clock.ko
> vermagic:   6.1.33 SMP mod_unload ARMv7 p2v8
>
> which indicates the vermagic (without the -g sufix) is different to the 
> kernel version (with the sufix).
>

The more globally unset LOCALVERSION will be picked up by the kernel
build (as invoked by the kernel or make-mod-scripts), and yes, will
inhibit scm querying.

The previous method was only working with some good luck (in general,
not related to anything meta-ti is doing).  That configure in meta-ti
is shooting right through the middle and hence why everything is
lining up as the unset LOCALVERSION should actually be getting a "+" ,
but if CONFIG_LOCALVERSION_AUTO is set, it won't actually run the code
that queries the scm, which makes the .scmversion file what is picked
up. It's all rather fragile :)

I'm curious if on-target module builds work on those boards, since as
near as I can tell the versions won't match (as the .scmversion file
isn't captured, so the vermagic will be different).

As a workaround, it should be possible to either set the LOCALVERSION
globally (or duplicate the variable to make-mod-scripts), so it'll be
the same, or it needs LOCALVERSION be completely unset in
make-mod-scripts, so the kernel localversion script won't pick it up
at all (and use the .scm querying to match).

Let me run some tests on a modified 6.1 linux-yocto and get back to
you. I should be able to mock up a similar localversion configuration.
There are options like using a localversion file, but I'd rather avoid
that if possible, since it'll surely break some other use cases, and
would have to be added to the artifacts for on-target/SDK builds, etc.

Bruce

>
> Petr
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

Re: [oe-core][RFC PATCH 0/3] Add packagefeed recipe class

[Charlie Johnston]

Sure! 

Currently to create a feed, users build the packages they want in the feed
and then bitbake package-index. That workflow unfortunately has a number of
limitations, the mains ones being:
- The index creation methods ONLY work on the package deploy directory. If
there are packages that are not meant to be in the feed in the deploy
directory, they will be included in the package index. Additionally, multiple
feeds cannot be built in one command due to this limitation.
- If a package feed depends on another package feed being side-by-side to it
(that is, if packages in Feed A depend on packages in Feed B and users of Feed B
are required to use Feed A) a user would have to manually remove duplicate 
packages
from the deploy directory before making Feed B's index.

These changes instead create a packagefeed class that can be inherited and will
create a feed in the tmp/deploy/feeds/ directory. This allows control 
over
the packages to be included in the feed, as the packages are hardlinked or 
copied
from the deploy directory similar to how feeds are constructed for rootfs 
creation.

I could see reusing the logic from the package_manager, but it would require
changes to allow indices to be created for arbitrary directories (instead of 
being
hardcoded based on package type), and adding some mechanism to 
create_packages_dir
in the package_manager/__init__.py to handle feed creation tasks/feeds being
dependent on other feeds. 

Are there limitations on changing the API of those classes and methods to add
inputs? Alternatively, I could split the overlapping code into a helper method
instead?

Thanks,
Charlie Johnston


On 7/19/23 15:59, Alexander Kanavin wrote:
> Specifically please take a look at,
> ./recipes-core/meta/package-index.bb
> and
> generate_index_files() in lib/oe/package_manager/__init__.py
> 
> I think we should rather extend these instead of adding overlapping
> code which works differently.
> 
> Alex
> 
> On Wed, 19 Jul 2023 at 22:39, Alexander Kanavin via
> lists.openembedded.org 
> wrote:
>>
>> You need to start by describing the use case. What problem does the
>> code solve that existing packagefeed code does not? Can we rather
>> extend the already existing code, its tests, and its documentation, to
>> support that use case?
>>
>> Alex
>>
>>
>> On Wed, 19 Jul 2023 at 22:03, Charlie Johnston  
>> wrote:
>>>
>>> Hello,
>>>
>>> I've been working on a packagefeed.bbclass to allow recipes that define a 
>>> feed. I have a working prototype which has been tested against poky using 
>>> all 3 package types.
>>> This is my first time submitting this type of change, so I'm looking for 
>>> some feedback to cover the gaps in my knowledge.
>>> Are there tests that need to be added for this type of change?
>>> Should this type of recipe class be SSTATE cache enabled?
>>> What documentation changes are necessary for this type of change?
>>>
>>> Thanks,
>>> Charlie Johnston
>>> charlie.johns...@ni.com
>>>
>>>
>>>
>>>
>>>
>>
>> 
>>


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

Re: [oe-core][RFC PATCH 0/3] Add packagefeed recipe class

[Alexander Kanavin]

Specifically please take a look at,
./recipes-core/meta/package-index.bb
and
generate_index_files() in lib/oe/package_manager/__init__.py

I think we should rather extend these instead of adding overlapping
code which works differently.

Alex

On Wed, 19 Jul 2023 at 22:39, Alexander Kanavin via
lists.openembedded.org 
wrote:
>
> You need to start by describing the use case. What problem does the
> code solve that existing packagefeed code does not? Can we rather
> extend the already existing code, its tests, and its documentation, to
> support that use case?
>
> Alex
>
>
> On Wed, 19 Jul 2023 at 22:03, Charlie Johnston  
> wrote:
> >
> > Hello,
> >
> > I've been working on a packagefeed.bbclass to allow recipes that define a 
> > feed. I have a working prototype which has been tested against poky using 
> > all 3 package types.
> > This is my first time submitting this type of change, so I'm looking for 
> > some feedback to cover the gaps in my knowledge.
> > Are there tests that need to be added for this type of change?
> > Should this type of recipe class be SSTATE cache enabled?
> > What documentation changes are necessary for this type of change?
> >
> > Thanks,
> > Charlie Johnston
> > charlie.johns...@ni.com
> >
> >
> >
> >
> >
>
> 
>

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

Re: [OE-core] [PATCH] ptest-runner: Pull in parallel test fixes

[Alexander Kanavin]

No, indeed they're all obsolete. They were added to the ticket today,
so I assumed they're fresh failures. Ignore the revert then, sorry for
hasty blaming.

Alex

On Wed, 19 Jul 2023 at 22:44, Joshua Watt  wrote:
>
> Do you have a recent log of a failure? All the ones in the ticket
> buildbot says are from a month ago (or, maybe that's just a quirk of
> buildbot?)
>
> On Wed, Jul 19, 2023 at 2:35 PM Alexander Kanavin
>  wrote:
> >
> > Which newer commit, in which repo? I believe the latest SRCREV update
> > in oe-core master that landed 12 hours ago or so is what broke things.
> >
> > Alex
> >
> > On Wed, 19 Jul 2023 at 22:32, Joshua Watt  wrote:
> > >
> > > There is a newer commit that was merged to master just today; please
> > > see if that fixes it.
> > >
> > > On Wed, Jul 19, 2023 at 2:26 PM Alexander Kanavin
> > >  wrote:
> > > >
> > > > Unfortunately this seems to once again have regressed glib/codegen
> > > > ptest (the test writes large amounts to stdout):
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15154
> > > >
> > > > I'll send a revert.
> > > >
> > > > Alex
> > > >
> > > > On Mon, 17 Jul 2023 at 16:36, Richard Purdie
> > > >  wrote:
> > > > >
> > > > > Pull in the commits:
> > > > >
> > > > > Change test timeout to be total elapsed time
> > > > > Report if child dies from a signal
> > > > > Recreate pipe for each test
> > > > > Revert "runner: Correctly handle running parallel tests"
> > > > > runner: Correctly handle running parallel tests
> > > > >
> > > > > Signed-off-by: Richard Purdie 
> > > > > ---
> > > > >  meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb 
> > > > > b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > > > index 6f3104499f2..77e2b94f376 100644
> > > > > --- a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > > > +++ b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > > > @@ -7,7 +7,7 @@ HOMEPAGE = 
> > > > > "http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
> > > > >  LICENSE = "GPL-2.0-or-later"
> > > > >  LIC_FILES_CHKSUM = 
> > > > > "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
> > > > >
> > > > > -SRCREV = "8259375d306a8129f6c5d8528314496fc6ae1ca3"
> > > > > +SRCREV = "07d8a676aa962ecc5ec264ec33b0074adf2a8733"
> > > > >  PV .= "+git${SRCPV}"
> > > > >
> > > > >  SRC_URI = 
> > > > > "git://git.yoctoproject.org/ptest-runner2;branch=master;protocol=https
> > > > >  \
> > > > > --
> > > > > 2.39.2
> > > > >
> > > > >
> > > > > 
> > > > >

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

Re: [OE-core] [PATCH] ptest-runner: Pull in parallel test fixes

[Joshua Watt]

Do you have a recent log of a failure? All the ones in the ticket
buildbot says are from a month ago (or, maybe that's just a quirk of
buildbot?)

On Wed, Jul 19, 2023 at 2:35 PM Alexander Kanavin
 wrote:
>
> Which newer commit, in which repo? I believe the latest SRCREV update
> in oe-core master that landed 12 hours ago or so is what broke things.
>
> Alex
>
> On Wed, 19 Jul 2023 at 22:32, Joshua Watt  wrote:
> >
> > There is a newer commit that was merged to master just today; please
> > see if that fixes it.
> >
> > On Wed, Jul 19, 2023 at 2:26 PM Alexander Kanavin
> >  wrote:
> > >
> > > Unfortunately this seems to once again have regressed glib/codegen
> > > ptest (the test writes large amounts to stdout):
> > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15154
> > >
> > > I'll send a revert.
> > >
> > > Alex
> > >
> > > On Mon, 17 Jul 2023 at 16:36, Richard Purdie
> > >  wrote:
> > > >
> > > > Pull in the commits:
> > > >
> > > > Change test timeout to be total elapsed time
> > > > Report if child dies from a signal
> > > > Recreate pipe for each test
> > > > Revert "runner: Correctly handle running parallel tests"
> > > > runner: Correctly handle running parallel tests
> > > >
> > > > Signed-off-by: Richard Purdie 
> > > > ---
> > > >  meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb 
> > > > b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > > index 6f3104499f2..77e2b94f376 100644
> > > > --- a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > > +++ b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > > @@ -7,7 +7,7 @@ HOMEPAGE = 
> > > > "http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
> > > >  LICENSE = "GPL-2.0-or-later"
> > > >  LIC_FILES_CHKSUM = 
> > > > "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
> > > >
> > > > -SRCREV = "8259375d306a8129f6c5d8528314496fc6ae1ca3"
> > > > +SRCREV = "07d8a676aa962ecc5ec264ec33b0074adf2a8733"
> > > >  PV .= "+git${SRCPV}"
> > > >
> > > >  SRC_URI = 
> > > > "git://git.yoctoproject.org/ptest-runner2;branch=master;protocol=https \
> > > > --
> > > > 2.39.2
> > > >
> > > >
> > > > 
> > > >

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

Re: [oe-core][RFC PATCH 0/3] Add packagefeed recipe class

[Alexander Kanavin]

You need to start by describing the use case. What problem does the
code solve that existing packagefeed code does not? Can we rather
extend the already existing code, its tests, and its documentation, to
support that use case?

Alex


On Wed, 19 Jul 2023 at 22:03, Charlie Johnston  wrote:
>
> Hello,
>
> I've been working on a packagefeed.bbclass to allow recipes that define a 
> feed. I have a working prototype which has been tested against poky using all 
> 3 package types.
> This is my first time submitting this type of change, so I'm looking for some 
> feedback to cover the gaps in my knowledge.
> Are there tests that need to be added for this type of change?
> Should this type of recipe class be SSTATE cache enabled?
> What documentation changes are necessary for this type of change?
>
> Thanks,
> Charlie Johnston
> charlie.johns...@ni.com
>
>
>
> 
>

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

Re: [OE-core] [PATCH] ptest-runner: Pull in parallel test fixes

[Alexander Kanavin]

Which newer commit, in which repo? I believe the latest SRCREV update
in oe-core master that landed 12 hours ago or so is what broke things.

Alex

On Wed, 19 Jul 2023 at 22:32, Joshua Watt  wrote:
>
> There is a newer commit that was merged to master just today; please
> see if that fixes it.
>
> On Wed, Jul 19, 2023 at 2:26 PM Alexander Kanavin
>  wrote:
> >
> > Unfortunately this seems to once again have regressed glib/codegen
> > ptest (the test writes large amounts to stdout):
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=15154
> >
> > I'll send a revert.
> >
> > Alex
> >
> > On Mon, 17 Jul 2023 at 16:36, Richard Purdie
> >  wrote:
> > >
> > > Pull in the commits:
> > >
> > > Change test timeout to be total elapsed time
> > > Report if child dies from a signal
> > > Recreate pipe for each test
> > > Revert "runner: Correctly handle running parallel tests"
> > > runner: Correctly handle running parallel tests
> > >
> > > Signed-off-by: Richard Purdie 
> > > ---
> > >  meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb 
> > > b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > index 6f3104499f2..77e2b94f376 100644
> > > --- a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > +++ b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > > @@ -7,7 +7,7 @@ HOMEPAGE = 
> > > "http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
> > >  LICENSE = "GPL-2.0-or-later"
> > >  LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
> > >
> > > -SRCREV = "8259375d306a8129f6c5d8528314496fc6ae1ca3"
> > > +SRCREV = "07d8a676aa962ecc5ec264ec33b0074adf2a8733"
> > >  PV .= "+git${SRCPV}"
> > >
> > >  SRC_URI = 
> > > "git://git.yoctoproject.org/ptest-runner2;branch=master;protocol=https \
> > > --
> > > 2.39.2
> > >
> > >
> > > 
> > >

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

Re: [OE-core] [PATCH] ptest-runner: Pull in parallel test fixes

[Joshua Watt]

There is a newer commit that was merged to master just today; please
see if that fixes it.

On Wed, Jul 19, 2023 at 2:26 PM Alexander Kanavin
 wrote:
>
> Unfortunately this seems to once again have regressed glib/codegen
> ptest (the test writes large amounts to stdout):
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=15154
>
> I'll send a revert.
>
> Alex
>
> On Mon, 17 Jul 2023 at 16:36, Richard Purdie
>  wrote:
> >
> > Pull in the commits:
> >
> > Change test timeout to be total elapsed time
> > Report if child dies from a signal
> > Recreate pipe for each test
> > Revert "runner: Correctly handle running parallel tests"
> > runner: Correctly handle running parallel tests
> >
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb 
> > b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > index 6f3104499f2..77e2b94f376 100644
> > --- a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > +++ b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> > @@ -7,7 +7,7 @@ HOMEPAGE = 
> > "http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
> >  LICENSE = "GPL-2.0-or-later"
> >  LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
> >
> > -SRCREV = "8259375d306a8129f6c5d8528314496fc6ae1ca3"
> > +SRCREV = "07d8a676aa962ecc5ec264ec33b0074adf2a8733"
> >  PV .= "+git${SRCPV}"
> >
> >  SRC_URI = 
> > "git://git.yoctoproject.org/ptest-runner2;branch=master;protocol=https \
> > --
> > 2.39.2
> >
> >
> > 
> >

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

[OE-core] [PATCH] Revert "ptest-runner: Pull in parallel test fixes and output handling"

[Alexander Kanavin]

This has once again regressed glib/codegen test (which writes large amounts to 
stdout).
Further fixing is needed.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb 
b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
index 60918a38927..6f3104499f2 100644
--- a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
+++ b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
@@ -7,7 +7,7 @@ HOMEPAGE = 
"http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
 LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
 
-SRCREV = "4148e75284e443fc8ffaef425c467aa5523528ff"
+SRCREV = "8259375d306a8129f6c5d8528314496fc6ae1ca3"
 PV .= "+git${SRCPV}"
 
 SRC_URI = 
"git://git.yoctoproject.org/ptest-runner2;branch=master;protocol=https \
-- 
2.30.2


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

Re: [OE-core] [PATCH] ptest-runner: Pull in parallel test fixes

[Alexander Kanavin]

Unfortunately this seems to once again have regressed glib/codegen
ptest (the test writes large amounts to stdout):
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15154

I'll send a revert.

Alex

On Mon, 17 Jul 2023 at 16:36, Richard Purdie
 wrote:
>
> Pull in the commits:
>
> Change test timeout to be total elapsed time
> Report if child dies from a signal
> Recreate pipe for each test
> Revert "runner: Correctly handle running parallel tests"
> runner: Correctly handle running parallel tests
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb 
> b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> index 6f3104499f2..77e2b94f376 100644
> --- a/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> +++ b/meta/recipes-support/ptest-runner/ptest-runner_2.4.2.bb
> @@ -7,7 +7,7 @@ HOMEPAGE = 
> "http://git.yoctoproject.org/cgit/cgit.cgi/ptest-runner2/about/;
>  LICENSE = "GPL-2.0-or-later"
>  LIC_FILES_CHKSUM = "file://LICENSE;md5=751419260aa954499f7abaabaa882bbe"
>
> -SRCREV = "8259375d306a8129f6c5d8528314496fc6ae1ca3"
> +SRCREV = "07d8a676aa962ecc5ec264ec33b0074adf2a8733"
>  PV .= "+git${SRCPV}"
>
>  SRC_URI = 
> "git://git.yoctoproject.org/ptest-runner2;branch=master;protocol=https \
> --
> 2.39.2
>
>
> 
>

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

Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Petr Gotthard]

Thanks Bruce,

> -Original Message-
> From: Bruce Ashfield 
> Sent: Wednesday, July 19, 2023 7:44 PM
> To: Petr Gotthard 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION
> 
> Hmm.
> 
> I explicitly tested this scenario to make sure it worked, since you run into 
> the
> same issue when building modules on-target.
> 
> make-mod-scripts is running out of the same SCM as the main kernel build, so 
> it
> should match, and did in my testing (otherwise lttng-modules wouldn't work).
> 
> Can you send the exact steps, which kernel recipe you are using, etc.
> That way I can reproduce the problem locally.
> 

I am using an AM335x with meta-ti (latest master). I think that the 
"beaglebone" might be close enough.
I did not set any kernel versions explicitly. The KERNEL_LOCALVERSION is set by 
the meta-ti itself in their setup-defconfig.inc:
https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/recipes-kernel/linux/setup-defconfig.inc

The kernel is "linux-ti-staging_6.1" with quite standard settings. Recently I 
did explicitly set
CONFIG_LOCALVERSION_AUTO=n
which was "y" by default. With the default "y" setting I was getting a kernel 
version with two identical suffixes ("6.1.33-g8f7f371be2-g8f7f371be2", whereas 
the make-mod-scripts used "6.1.33-g8f7f371be2").

The out-of-tree modules I am building are using recipes almost identical to the 
"poky/meta-skeleton/recipes-kernel/hello-mod". Again, no kernel version 
specified.

I tried to build the lttng-modules and see the same issue: "modinfo 
lttng-clock.ko" returns
filename:   
/home/...-linux-gnueabi/lttng-modules/2.13.9-r0/packages-split/kernel-module-lttng-clock-6.1.33-g8f7f371be2/lib/modules/6.1.33-g8f7f371be2/kernel/lttng-modules/lttng-clock.ko
vermagic:   6.1.33 SMP mod_unload ARMv7 p2v8

which indicates the vermagic (without the -g sufix) is different to the 
kernel version (with the sufix).


Petr


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

ODP: [OE-Core][PATCH v6 1/6] bitbake.conf: add acl and xattr distro native features support

[Piotr Łobacz]

Dear Richard, Alexandre, Alex and all,
this patchset fixes has additional patch which actually fixes these warning 
message:

[log_check] Warning when reading ar archive header: Pathname can't be converted 
from UTF-8 to current locale. (errno=84)

I do not know if it fixes this error:

opkg-build -Z xz -a "--memlimit=5% --threads=8" "" "" nativesdk-xcb-proto-dbg 
/home/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-xcb-proto/1.15.2-r0/deploy-ipks/i686-nativesdk'
 returned non-zero exit status 1

because I was not able to reproduce it... I'm testing it all with our distro 
configuration files and I do not know what may be the differences between our 
distros.
Maybe next autobuild will tell us something more hopefully.

BR
Piotr

Od: Piotr Łobacz 
Wysłane: środa, 19 lipca 2023 21:48
Do: openembedded-core@lists.openembedded.org 

DW: Piotr Łobacz 
Temat: [OE-Core][PATCH v6 1/6] bitbake.conf: add acl and xattr distro native 
features support 
 
Include support for ACLs and extended file attributes for native
builds, by default.

Signed-off-by: Piotr Łobacz 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9625a6fef4..8dd615 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -904,7 +904,7 @@ IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}"
 
 # Native distro features (will always be used for -native, even if they
 # are not enabled for target)
-DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr"
+DISTRO_FEATURES_NATIVE ?= "acl x11 ipv6 xattr"
 DISTRO_FEATURES_NATIVESDK ?= "x11"
 
 # Normally target distro features will not be applied to native builds:
-- 
2.34.1

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

[oe-core][RFC PATCH 3/3] packagefeed.bbclass: Add new bbclass for building feeds.

[Charlie Johnston]

Add a new bbclass that allows building a feed using the
new oe.packagefeed class. This new bbclass inherits
from packagegroup so that there is also a package in the
feed that represents all packages in the feed.

The variable FEED_DEPENDS can be used to specify a feed
that the packagefeed depends on and will be available
side-by-side. This prevents duplicate packages in the
two feeds.

Additionally, there are packagefeed_ bbclasses to
define package type specific configurations.

Signed-off-by: Charlie Johnston 
---
 meta/classes-recipe/packagefeed.bbclass | 16 
 meta/classes-recipe/packagefeed_deb.bbclass |  2 ++
 meta/classes-recipe/packagefeed_ipk.bbclass |  2 ++
 meta/classes-recipe/packagefeed_rpm.bbclass |  2 ++
 4 files changed, 22 insertions(+)
 create mode 100644 meta/classes-recipe/packagefeed.bbclass
 create mode 100644 meta/classes-recipe/packagefeed_deb.bbclass
 create mode 100644 meta/classes-recipe/packagefeed_ipk.bbclass
 create mode 100644 meta/classes-recipe/packagefeed_rpm.bbclass

diff --git a/meta/classes-recipe/packagefeed.bbclass 
b/meta/classes-recipe/packagefeed.bbclass
new file mode 100644
index 00..7dfccbb58b
--- /dev/null
+++ b/meta/classes-recipe/packagefeed.bbclass
@@ -0,0 +1,16 @@
+
+FEED_CLASSES = "packagefeed_${IMAGE_PKGTYPE} packagegroup"
+inherit ${FEED_CLASSES}
+
+FEED_PATH = "${DEPLOY_DIR_FEED}/${PN}"
+FEED_DEPENDS ??= ""
+
+fakeroot python do_packagefeed() {
+from oe.packagefeed import create_packagefeed
+
+create_packagefeed(d)
+}
+addtask packagefeed before do_build
+do_packagefeed[nostamp] = "1"
+do_packagefeed[cleandirs] += "${FEED_PATH}"
+do_packagefeed[rdepends] += "${@' '.join([x + ':do_packagefeed' for x in 
d.getVar('FEED_DEPENDS').split()])}"
diff --git a/meta/classes-recipe/packagefeed_deb.bbclass 
b/meta/classes-recipe/packagefeed_deb.bbclass
new file mode 100644
index 00..6ca5a33e93
--- /dev/null
+++ b/meta/classes-recipe/packagefeed_deb.bbclass
@@ -0,0 +1,2 @@
+do_packagefeed[depends] += "dpkg-native:do_populate_sysroot 
apt-native:do_populate_sysroot"
+do_packagefeed[recrdeptask] += "do_package_write_deb do_package_qa"
diff --git a/meta/classes-recipe/packagefeed_ipk.bbclass 
b/meta/classes-recipe/packagefeed_ipk.bbclass
new file mode 100644
index 00..00ef8a30df
--- /dev/null
+++ b/meta/classes-recipe/packagefeed_ipk.bbclass
@@ -0,0 +1,2 @@
+do_packagefeed[depends] += "opkg-native:do_populate_sysroot"
+do_packagefeed[recrdeptask] += "do_package_write_ipk do_package_qa"
diff --git a/meta/classes-recipe/packagefeed_rpm.bbclass 
b/meta/classes-recipe/packagefeed_rpm.bbclass
new file mode 100644
index 00..862ba99290
--- /dev/null
+++ b/meta/classes-recipe/packagefeed_rpm.bbclass
@@ -0,0 +1,2 @@
+do_packagefeed[depends] += "rpm-native:do_populate_sysroot 
dnf-native:do_populate_sysroot createrepo-c-native:do_populate_sysroot"
+do_packagefeed[recrdeptask] += "do_package_write_rpm do_package_qa"
-- 
2.41.0


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

[oe-core][RFC PATCH 2/3] bitbake.conf: Add new DEPLOY_DIR_FEED variable.

[Charlie Johnston]

This change adds a new variable that defines where
feeds should be created when building a packagefeed.

For now, the location is ${DEPLOY_DIR}/feeds

Signed-off-by: Charlie Johnston 
---
 meta/conf/bitbake.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 8dd615..8c40937e62 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -450,6 +450,7 @@ DEPLOY_DIR_RPM = "${DEPLOY_DIR}/rpm"
 DEPLOY_DIR_DEB = "${DEPLOY_DIR}/deb"
 DEPLOY_DIR_IMAGE ?= "${DEPLOY_DIR}/images/${MACHINE}"
 DEPLOY_DIR_TOOLS = "${DEPLOY_DIR}/tools"
+DEPLOY_DIR_FEED ?= "${DEPLOY_DIR}/feeds/"
 
 PKGDATA_DIR = "${TMPDIR}/pkgdata/${MACHINE}"
 PKGDATA_DIR_SDK = "${TMPDIR}/pkgdata/${SDK_SYS}"
-- 
2.41.0


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

[oe-core][RFC PATCH 1/3] packagefeed: Add new oe.packagefeed classes

[Charlie Johnston]

This change adds the infrastructure to build a
packagefeed to oe. Specifically, packagefeed.py
adds an abstract class and the logic to create a
hardlinked feed directory while the package type
specific classes allow the proper package indexer,
deploy directory, etc to be selected for a build.

The logic to construct the package feed is modified
from similar logic used in oe.package_manager when
constructing a feed for rootfs builds with some minor
differences to allow filtering out packages which may
already be in other feeds.

Signed-off-by: Charlie Johnston 
---
 .../lib/oe/package_manager/deb/packagefeed.py |  14 ++
 .../lib/oe/package_manager/ipk/packagefeed.py |  14 ++
 .../lib/oe/package_manager/rpm/packagefeed.py |  14 ++
 meta/lib/oe/packagefeed.py| 120 ++
 4 files changed, 162 insertions(+)
 create mode 100644 meta/lib/oe/package_manager/deb/packagefeed.py
 create mode 100644 meta/lib/oe/package_manager/ipk/packagefeed.py
 create mode 100644 meta/lib/oe/package_manager/rpm/packagefeed.py
 create mode 100644 meta/lib/oe/packagefeed.py

diff --git a/meta/lib/oe/package_manager/deb/packagefeed.py 
b/meta/lib/oe/package_manager/deb/packagefeed.py
new file mode 100644
index 00..7833cb437a
--- /dev/null
+++ b/meta/lib/oe/package_manager/deb/packagefeed.py
@@ -0,0 +1,14 @@
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+from oe.package_manager.deb import DpkgIndexer
+from oe.packagefeed import Packagefeed, create_feed_dir
+
+class PkgFeed(Packagefeed):
+def __init__(self, d):
+super(PkgFeed, self).__init__(d)
+self.indexer = DpkgIndexer(self.d, self.deploy_dir)
+
+def _create_feed_directory(self):
+create_feed_dir(self.d, self.deploy_dir, 
self.d.getVar('DEPLOY_DIR_DEB'), "package_write_deb", 
self.d.getVar('FEED_DEPENDS'))
diff --git a/meta/lib/oe/package_manager/ipk/packagefeed.py 
b/meta/lib/oe/package_manager/ipk/packagefeed.py
new file mode 100644
index 00..223f6a057e
--- /dev/null
+++ b/meta/lib/oe/package_manager/ipk/packagefeed.py
@@ -0,0 +1,14 @@
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+from oe.package_manager.ipk import OpkgIndexer
+from oe.packagefeed import Packagefeed, create_feed_dir
+
+class PkgFeed(Packagefeed):
+def __init__(self, d):
+super(PkgFeed, self).__init__(d)
+self.indexer = OpkgIndexer(self.d, self.deploy_dir)
+
+def _create_feed_directory(self):
+create_feed_dir(self.d, self.deploy_dir, 
self.d.getVar('DEPLOY_DIR_IPK'), "package_write_ipk", 
self.d.getVar('FEED_DEPENDS'))
diff --git a/meta/lib/oe/package_manager/rpm/packagefeed.py 
b/meta/lib/oe/package_manager/rpm/packagefeed.py
new file mode 100644
index 00..e8da346eca
--- /dev/null
+++ b/meta/lib/oe/package_manager/rpm/packagefeed.py
@@ -0,0 +1,14 @@
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+from oe.package_manager.rpm import RpmIndexer
+from oe.packagefeed import Packagefeed, create_feed_dir
+
+class PkgFeed(Packagefeed):
+def __init__(self, d):
+super(PkgFeed, self).__init__(d)
+self.indexer = RpmIndexer(self.d, self.deploy_dir)
+
+def _create_feed_directory(self):
+create_feed_dir(self.d, self.deploy_dir, 
self.d.getVar('DEPLOY_DIR_RPM'), "package_write_rpm", 
self.d.getVar('FEED_DEPENDS'))
diff --git a/meta/lib/oe/packagefeed.py b/meta/lib/oe/packagefeed.py
new file mode 100644
index 00..3a2deb89e7
--- /dev/null
+++ b/meta/lib/oe/packagefeed.py
@@ -0,0 +1,120 @@
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+from abc import ABCMeta, abstractmethod
+import os
+import oe
+
+class Packagefeed(object, metaclass=ABCMeta):
+"""
+This is an abstract class. Do not instantiate this directly.
+"""
+
+def __init__(self, d):
+self.d = d
+self.deploy_dir = self.d.expand('${DEPLOY_DIR_FEED}/${PN}')
+self.indexer = None
+
+@abstractmethod
+def _create_feed_directory(self):
+pass
+
+def create(self):
+bb.note("## Generate packagefeed with index ###")
+
+self._create_feed_directory()
+
+# call the package indexer create index method
+self.indexer.write_index()
+
+def get_class_for_type(imgtype):
+import importlib
+mod = importlib.import_module('oe.package_manager.' + imgtype + 
'.packagefeed')
+return mod.PkgFeed
+
+def create_packagefeed(d):
+env_bkp = os.environ.copy()
+
+img_type = d.getVar('IMAGE_PKGTYPE')
+
+cls = get_class_for_type(img_type)
+cls(d).create()
+os.environ.clear()
+os.environ.update(env_bkp)
+
+def create_feed_dir(d, subrepo_dir, deploydir, taskname, feed_deps):
+import errno
+
+taskdepdata = d.getVar("BB_TASKDEPDATA", False)
+pn = d.getVar("PN")
+feedtaskname = "packagefeed"
+
+bb.utils.remove(subrepo_dir, recurse=True)
+bb.utils.mkdirhier(subrepo_dir)
+
+feed_pkgdeps = find_task_pkg_deps(pn, taskdepdata, feedtaskname, taskname)
+
+# Find any packages already in feeds 

[oe-core][RFC PATCH 0/3] Add packagefeed recipe class

[Charlie Johnston]

Hello,

I've been working on a packagefeed.bbclass to allow recipes that define a feed. 
I have a working prototype which has been tested against poky using all 3 
package types.
This is my first time submitting this type of change, so I'm looking for some 
feedback to cover the gaps in my knowledge.
Are there tests that need to be added for this type of change?
Should this type of recipe class be SSTATE cache enabled?
What documentation changes are necessary for this type of change?

Thanks,
Charlie Johnston
charlie.johns...@ni.com



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

Re: [OE-Core][PATCH] eudev: Add group sgx to eudev package

[Alex Kiernan]

On Wed, Jul 19, 2023 at 7:48 PM Alex Kiernan via
lists.openembedded.org 
wrote:
>
> On Wed, Jul 19, 2023 at 1:30 PM Alexandre Belloni
>  wrote:
> >
> > Hello,
> >
> > I had a bit of trouble to find this but this causes the following
> > oe-selftest failure:
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/2274/steps/14/logs/stdio
> >
> > 2023-07-18 20:56:16,128 - oe-selftest - INFO - 
> > gdbserver.GdbServerTest.test_gdb_server (subunit.RemotedTestCase)
> > 2023-07-18 20:56:16,129 - oe-selftest - INFO -  ... ERROR
> > Stderr:
> > 2023-07-18 20:32:39,581 - oe-selftest - INFO - Adding: "include 
> > selftest.inc" in 
> > /home/pokybuild/yocto-worker/oe-selftest/build/build-st-836115/conf/local.conf
> > 2023-07-18 20:32:39,582 - oe-selftest - INFO - Adding: "include 
> > bblayers.inc" in bblayers.conf
> > 2023-07-18 20:56:16,129 - oe-selftest - INFO - 14: 7/58 224/529 (269.86s) 
> > (0 failed) (gdbserver.GdbServerTest.test_gdb_server)
> > 2023-07-18 20:56:16,129 - oe-selftest - INFO - 
> > testtools.testresult.real._StringException: Traceback (most recent call 
> > last):
> >   File 
> > "/home/pokybuild/yocto-worker/oe-selftest/build/meta/lib/oeqa/selftest/cases/gdbserver.py",
> >  line 43, in test_gdb_server
> > shutil.unpack_archive(filename, debugfs)
> >   File "/usr/lib64/python3.11/shutil.py", line 1323, in unpack_archive
> > func(filename, extract_dir, **kwargs)
> >   File "/usr/lib64/python3.11/shutil.py", line 1244, in _unpack_tarfile
> > tarobj.extractall(extract_dir, filter=filter)
> >   File "/usr/lib64/python3.11/tarfile.py", line 2257, in extractall
> > self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
> >   File "/usr/lib64/python3.11/tarfile.py", line 2324, in _extract_one
> > self._handle_fatal_error(e)
> >   File "/usr/lib64/python3.11/tarfile.py", line 2320, in _extract_one
> > self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
> >   File "/usr/lib64/python3.11/tarfile.py", line 2403, in _extract_member
> > self.makefile(tarinfo, targetpath)
> >   File "/usr/lib64/python3.11/tarfile.py", line 2448, in makefile
> > with bltn_open(targetpath, "wb") as target:
> >  ^^^
> > PermissionError: [Errno 13] Permission denied: 
> > '/tmp/debugfs-j_xgxhkm/./etc/gshadow'
> >
>
> That's interesting... really not sure why /etc/shadow doesn't trigger
> this failure too (which is in the same set of tarballs). That said
> I've no idea what the fix is, since this looks like collateral damage
> rather than something which this change obviously broke. Will stare at
> it a bit more.
>

If I read the pieces right, we do:

self._setup_dbg_rootfs(['/etc', '/var/lib/rpm',
'/var/cache/dnf', '/var/lib/dnf'])

I assume in order to prime the RPM config, which then copies gshadow
(and the rest of /etc - ignoring that its not using ${sysconfdir}),
which then causes this failure...

Something like:

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 890ba5f03984..a2e81afb4f09 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -162,6 +162,9 @@ class Rootfs(object, metaclass=ABCMeta):
 bb.note("  Install extra debug packages...")
 self.pm.install(extra_debug_pkgs.split(), True)

+sysconfdir = self.image_rootfs + self.d.getVar('sysconfdir')
+shutil.rmtree(sysconfdir)
+
 bb.note("  Rename debug rootfs...")
 try:
 shutil.rmtree(self.image_rootfs + '-dbg')

Would appear sensible, but it feels rather "nuclear" and is way out of
my comfort zone of a proposed change!

> > On 14/07/2023 15:09:55+0100, Alex Kiernan wrote:
> > > Fix startup warning:
> > >
> > >   udevd[171]: specified group 'sgx' unknown
> > >
> > > This mirrors the change in bab455cd9b1b ("systemd: add group sgx to udev
> > > package") for systemd-udev.
> > >
> > > Signed-off-by: Alex Kiernan 
> > > ---
> > >
> > >  meta/recipes-core/udev/eudev_3.2.12.bb | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/meta/recipes-core/udev/eudev_3.2.12.bb 
> > > b/meta/recipes-core/udev/eudev_3.2.12.bb
> > > index 572ccecafd0c..4268bcc2c5de 100644
> > > --- a/meta/recipes-core/udev/eudev_3.2.12.bb
> > > +++ b/meta/recipes-core/udev/eudev_3.2.12.bb
> > > @@ -18,7 +18,7 @@ SRC_URI[sha256sum] = 
> > > "ccdd64ec3c381d3c3ed0e99d2e70d1f62988c7763de89ca7bdffafa5ea
> > >
> > >  GITHUB_BASE_URI = "https://github.com/eudev-project/eudev/releases;
> > >
> > > -inherit autotools update-rc.d qemu pkgconfig features_check manpages 
> > > github-releases
> > > +inherit autotools update-rc.d qemu pkgconfig features_check manpages 
> > > github-releases useradd
> > >
> > >  CONFLICT_DISTRO_FEATURES = "systemd"
> > >
> > > @@ -85,3 +85,6 @@ pkg_postinst:${PN}-hwdb () {
> > >  pkg_prerm:${PN}-hwdb () {
> > >   rm -f $D${sysconfdir}/udev/hwdb.bin
> > >  }
> > > +
> > > +USERADD_PACKAGES = "${PN}"
> > > +GROUPADD_PARAM:${PN} = "-r sgx"
> > > 

[OE-Core][PATCH v6 6/6] opkg: set locale from system environment variables

[Piotr Łobacz]

A C program inherits its locale environment variables when it starts up.
This happens automatically. However, these variables do not automatically
control the locale used by the library functions, because ISO C says that
all programs start by default in the standard ‘C’ locale.

Fixes warnings:
Warning when reading ar archive header: Pathname can't be converted from UTF-8 
to current locale. (errno=84)

Signed-off-by: Piotr Łobacz 
---
 ...le-from-system-environment-variables.patch | 48 +++
 meta/recipes-devtools/opkg/opkg_0.6.1.bb  |  1 +
 2 files changed, 49 insertions(+)
 create mode 100644 
meta/recipes-devtools/opkg/opkg/0003-opkg-set-locale-from-system-environment-variables.patch

diff --git 
a/meta/recipes-devtools/opkg/opkg/0003-opkg-set-locale-from-system-environment-variables.patch
 
b/meta/recipes-devtools/opkg/opkg/0003-opkg-set-locale-from-system-environment-variables.patch
new file mode 100644
index 00..71240ec8fd
--- /dev/null
+++ 
b/meta/recipes-devtools/opkg/opkg/0003-opkg-set-locale-from-system-environment-variables.patch
@@ -0,0 +1,48 @@
+From 712895b1914bf63ee4d669863bfd106814329076 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Piotr=20=C5=81obacz?= 
+Date: Wed, 19 Jul 2023 21:26:09 +0200
+Subject: [PATCH] opkg: set locale from system environment variables
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+A C program inherits its locale environment variables when it starts up.
+This happens automatically. However, these variables do not automatically
+control the locale used by the library functions, because ISO C says that
+all programs start by default in the standard ‘C’ locale.
+
+Fixes warnings:
+Warning when reading ar archive header: Pathname can't be converted from UTF-8 
to current locale. (errno=84)
+
+Upstream-Status: Submitted 
[https://groups.google.com/g/opkg-devel/c/16kgZfJ26mQ]
+
+[1] https://www.gnu.org/software/libc/manual/html_node/Setting-the-Locale.html
+
+Signed-off-by: Piotr Łobacz 
+---
+ src/opkg.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/opkg.c b/src/opkg.c
+index 544c58a..0c729ff 100644
+--- a/src/opkg.c
 b/src/opkg.c
+@@ -27,6 +27,7 @@
+ #include 
+ #include 
+ #include 
++#include 
+ 
+ #include "opkg_conf.h"
+ #include "opkg_cmd.h"
+@@ -408,6 +409,7 @@ int main(int argc, char *argv[])
+ if (opkg_conf_init())
+ goto err0;
+ 
++setlocale(LC_ALL, "");
+ opkg_config->verbosity = NOTICE;
+ 
+ opts = args_parse(argc, argv);
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.1.bb 
b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
index 2cac4af644..c7b8709112 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
@@ -16,6 +16,7 @@ SRC_URI = 
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz
file://opkg.conf \

file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
file://0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch \
+   file://0003-opkg-set-locale-from-system-environment-variables.patch 
\

file://0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
file://0002-Add-options-to-enable-support-for-acl-and-xattr.patch \
file://run-ptest \
-- 
2.34.1


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

[OE-Core][PATCH v6 3/6] package.bbclass: add support for ACLs and xattr

[Piotr Łobacz]

Extend `tar` command, with additional parameters, depending
on choosen package class and target distro features, in order
to support ACLs and xattr.

Currently only `package_ipk` supports fully ACLs and xattr.

Signed-off-by: Piotr Łobacz 
---
 meta/classes-global/package.bbclass | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/classes-global/package.bbclass 
b/meta/classes-global/package.bbclass
index e8055a9cdc..6e5d0dd4dc 100644
--- a/meta/classes-global/package.bbclass
+++ b/meta/classes-global/package.bbclass
@@ -342,8 +342,13 @@ python perform_packagecopy () {
 
 # Start by package population by taking a copy of the installed
 # files to operate on
-# Preserve sparse files and hard links
-cmd = 'tar --exclude=./sysroot-only -cf - -C %s -p -S . | tar -xf - -C %s' 
% (dest, dvar)
+# Preserve sparse files, hard links, ACLs and extended attributes
+# TODO: for the moment only ipk packages are supporting ACLs and extended 
attributes
+# we need to add support for other package systems as well, but that 
doesn't bother
+# tar from creating archives with acl and/or xattr support
+acl = bb.utils.contains('DISTRO_FEATURES', 'acl', '--acls', '', d)
+xattr = bb.utils.contains('DISTRO_FEATURES', 'xattr', '--xattrs', '', d)
+cmd = f'tar {acl} {xattr} --numeric-owner --exclude=./sysroot-only -cf - 
-C {dest} -p -S . | tar {acl} {xattr} -xf - -C {dvar}'
 subprocess.check_output(cmd, shell=True, stderr=subprocess.STDOUT)
 
 # replace RPATHs for the nativesdk binaries, to make them relocatable
-- 
2.34.1


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

[OE-Core][PATCH v6 4/6] opkg-utils: add acl and xattr support

[Piotr Łobacz]

Add support for tar archives created with --acls and/or --xattrs options,
PAX header format.

GNU tar and libarchive already supports ACLs and extended attributes.
We can now add this support as well to opkg-build script in order to use
fsetattr or setcap inside do_install command and end up with a file in
an image with the relevant ACLs and xattrs.

Signed-off-by: Piotr Łobacz 
---
 ...kg-build-Add-acls-and-xattrs-support.patch | 80 +++
 .../opkg-utils/opkg-utils_0.5.0.bb|  1 +
 2 files changed, 81 insertions(+)
 create mode 100644 
meta/recipes-devtools/opkg-utils/opkg-utils/0002-opkg-build-Add-acls-and-xattrs-support.patch

diff --git 
a/meta/recipes-devtools/opkg-utils/opkg-utils/0002-opkg-build-Add-acls-and-xattrs-support.patch
 
b/meta/recipes-devtools/opkg-utils/opkg-utils/0002-opkg-build-Add-acls-and-xattrs-support.patch
new file mode 100644
index 00..a9e5f0e191
--- /dev/null
+++ 
b/meta/recipes-devtools/opkg-utils/opkg-utils/0002-opkg-build-Add-acls-and-xattrs-support.patch
@@ -0,0 +1,80 @@
+From 5664c17923cc1ab9644ef01f549bc8d352dd8868 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Piotr=20=C5=81obacz?= 
+Date: Wed, 5 Jul 2023 10:31:13 +0200
+Subject: [PATCH] opkg-build: Add acls and xattrs support
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add support for tar archives created with --acls and/or --xattrs options,
+PAX header format.
+
+GNU tar and libarchive already supports ACLs and extended attributes.
+We can now add this support as well to opkg-build script in order to use
+fsetattr or setcap inside do_install command and end up with a file in
+an image with the relevant ACLs and xattrs.
+
+Upstream-Status: Accepted 
[https://groups.google.com/g/opkg-devel/c/dYNHrLjDwg8]
+
+[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15097
+[2] https://groups.google.com/g/opkg-devel/c/aEGL7XRXfaA
+
+Signed-off-by: Piotr Łobacz 
+---
+ opkg-build | 15 ++-
+ 1 file changed, 10 insertions(+), 5 deletions(-)
+
+diff --git a/opkg-build b/opkg-build
+index a9e45d4..8d9bcfa 100755
+--- a/opkg-build
 b/opkg-build
+@@ -145,6 +145,7 @@ You probably want to chown these to a system user: " >&2
+ ###
+ # opkg-build "main"
+ ###
++attributesargs=""
+ ogargs=""
+ outer=ar
+ noclean=0
+@@ -166,7 +167,7 @@ compressorargs=""
+ tarformat=""
+ if tar --help 2>&1 | grep -- "--format" > /dev/null;
+ then
+-tarformat="--format=gnu"
++tarformat="--format=posix"
+ fi
+ 
+ compressor_ext() {
+@@ -197,13 +198,17 @@ compressor_ext() {
+ : <<=cut
+ =head1 SYNOPSIS
+ 
+-B [B<-c>] [B<-C>] [B<-Z> I] [B<-a>] [B<-O>] [B<-o> 
I] [B<-g> I] I [I]
++B [B<-A>] [B<-X>] [B<-c>] [B<-C>] [B<-Z> I] [B<-a>] 
[B<-O>] [B<-o> I] [B<-g> I] I 
[I]
+ 
+ =cut
+ 
+-usage="Usage: $0 [-c] [-C] [-Z compressor] [-a compressor_args] [-O] [-o 
owner] [-g group]  []"
+-while getopts "a:cCg:ho:vOZ:" opt; do
++usage="Usage: $0 [-A] [-X] [-c] [-C] [-Z compressor] [-a compressor_args] 
[-O] [-o owner] [-g group]  []"
++while getopts "Aa:cCg:ho:vOXZ:" opt; do
+ case $opt in
++A ) attributesargs="--acls"
++;;
++X ) attributesargs="$attributesargs --xattrs"
++;;
+   o ) owner=$OPTARG
+   ogargs="--owner=$owner"
+   ;;
+@@ -314,7 +319,7 @@ export LANG=C
+ export LC_ALL=C
+ ( cd $pkg_dir/$CONTROL && find . -type f | sort > $tmp_dir/control_list )
+ ( cd $pkg_dir && find . -path ./$CONTROL -prune -o -path . -o -print  | sort 
> $tmp_dir/file_list )
+-( cd $pkg_dir && tar $ogargs $tsortargs --no-recursion $mtime_args -c 
$tarformat -T $tmp_dir/file_list | $compressor $compressorargs > 
$tmp_dir/data.tar.$cext )
++( cd $pkg_dir && tar $attributesargs $ogargs $tsortargs --no-recursion 
$mtime_args -c $tarformat -T $tmp_dir/file_list | $compressor $compressorargs > 
$tmp_dir/data.tar.$cext )
+ ( cd $pkg_dir/$CONTROL && tar $ogargs $tsortargs --no-recursion 
--mtime=@$build_date -c $tarformat -T $tmp_dir/control_list | gzip $zipargs > 
$tmp_dir/control.tar.gz )
+ rm $tmp_dir/file_list
+ rm $tmp_dir/control_list
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb 
b/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb
index b27e3ded33..edf730711e 100644
--- a/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb
+++ b/meta/recipes-devtools/opkg-utils/opkg-utils_0.5.0.bb
@@ -9,6 +9,7 @@ PROVIDES += "${@bb.utils.contains('PACKAGECONFIG', 
'update-alternatives', 'virtu
 
 SRC_URI = "git://git.yoctoproject.org/opkg-utils;protocol=https;branch=master \
file://0001-update-alternatives-correctly-match-priority.patch \
+   file://0002-opkg-build-Add-acls-and-xattrs-support.patch \
"
 SRCREV = "9239541f14a2529b9d01c0a253ab11afa2822dab"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#184597): 
https://lists.openembedded.org/g/openembedded-core/message/184597
Mute This Topic: 

[OE-Core][PATCH v6 5/6] opkg: add options to enable support for acl and xattr

[Piotr Łobacz]

The libarchive library, which is being used by opkg, supports ACLs
and xattr already.

More informations can be read at this link:
https://github.com/libarchive/libarchive/pull/691

Signed-off-by: Piotr Łobacz 
---
 ...-to-enable-support-for-acl-and-xattr.patch | 70 +++
 meta/recipes-devtools/opkg/opkg_0.6.1.bb  |  5 +-
 2 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/opkg/opkg/0002-Add-options-to-enable-support-for-acl-and-xattr.patch

diff --git 
a/meta/recipes-devtools/opkg/opkg/0002-Add-options-to-enable-support-for-acl-and-xattr.patch
 
b/meta/recipes-devtools/opkg/opkg/0002-Add-options-to-enable-support-for-acl-and-xattr.patch
new file mode 100644
index 00..d6cb1d79fb
--- /dev/null
+++ 
b/meta/recipes-devtools/opkg/opkg/0002-Add-options-to-enable-support-for-acl-and-xattr.patch
@@ -0,0 +1,70 @@
+From 1c935e994bd572d9fff436f660ac1a060a434df0 Mon Sep 17 00:00:00 2001
+From: Maciej Liszewski 
+Date: Tue, 4 Jul 2023 22:01:58 +0200
+Subject: [PATCH] Add options to enable support for acl and xattr
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The libarchive library, which is being used by opkg, supports ACLs
+and xattr already.
+
+More informations can be read at this link:
+https://github.com/libarchive/libarchive/pull/691
+
+Upstream-Status: Accepted 
[https://groups.google.com/g/opkg-devel/c/aEGL7XRXfaA]
+
+[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15097
+
+Signed-off-by: Maciej Liszewski 
+Signed-off-by: Piotr Łobacz 
+---
+ configure.ac   | 12 
+ libopkg/opkg_archive.c |  8 
+ 2 files changed, 20 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 389a818..46949cd 100644
+--- a/configure.ac
 b/configure.ac
+@@ -158,6 +158,18 @@ return OPENSSL_VERSION_NUMBER; ],
+   AC_SUBST(OPENSSL_LIBS)
+ fi
+ 
++# check for ACL support
++AC_ARG_WITH([acl], [AS_HELP_STRING([--with-acl], [Enable ACL support])])
++if test "x$with_acl" = "xyes"; then
++  AC_DEFINE([ENABLE_ACL], [1], [Enable ACL support])
++fi
++
++# check for xattr support
++AC_ARG_WITH([xattr], [AS_HELP_STRING([--with-xattr], [Enable xattr support])])
++if test "x$with_xattr" = "xyes"; then
++  AC_DEFINE([ENABLE_XATTR], [1], [Enable xattr support])
++fi
++
+ # check for libsolv solver
+ AC_ARG_WITH(libsolv, AC_HELP_STRING([--with-libsolv], [Use libsolv solver 
support.
+   ]), [], [with_libsolv="no"])
+diff --git a/libopkg/opkg_archive.c b/libopkg/opkg_archive.c
+index 03a4afb..8dd902d 100644
+--- a/libopkg/opkg_archive.c
 b/libopkg/opkg_archive.c
+@@ -912,6 +912,14 @@ struct opkg_ar *ar_open_pkg_data_archive(const char 
*filename)
+ ar->extract_flags = ARCHIVE_EXTRACT_OWNER | ARCHIVE_EXTRACT_PERM |
+ ARCHIVE_EXTRACT_TIME | ARCHIVE_EXTRACT_UNLINK | 
ARCHIVE_EXTRACT_NO_OVERWRITE;
+ 
++#ifdef ENABLE_ACL
++ar->extract_flags |= ARCHIVE_EXTRACT_ACL;
++#endif
++
++#ifdef ENABLE_XATTR
++ar->extract_flags |= ARCHIVE_EXTRACT_FFLAGS | ARCHIVE_EXTRACT_XATTR;
++#endif
++
+ if (opkg_config->ignore_uid)
+ ar->extract_flags &= ~ARCHIVE_EXTRACT_OWNER;
+ 
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/opkg/opkg_0.6.1.bb 
b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
index 4c25fe963a..2cac4af644 100644
--- a/meta/recipes-devtools/opkg/opkg_0.6.1.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.6.1.bb
@@ -17,6 +17,7 @@ SRC_URI = 
"http://downloads.yoctoproject.org/releases/${BPN}/${BPN}-${PV}.tar.gz

file://0001-opkg_conf-create-opkg.lock-in-run-instead-of-var-run.patch \
file://0002-opkg-key-remove-no-options-flag-from-gpg-calls.patch \

file://0001-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
+   file://0002-Add-options-to-enable-support-for-acl-and-xattr.patch \
file://run-ptest \
 "
 
@@ -32,8 +33,10 @@ inherit autotools pkgconfig ptest
 target_localstatedir := "${localstatedir}"
 OPKGLIBDIR ??= "${target_localstatedir}/lib"
 
-PACKAGECONFIG ??= "libsolv"
+PACKAGECONFIG ??= "libsolv ${@bb.utils.filter('DISTRO_FEATURES', 'acl xattr', 
d)}"
 
+PACKAGECONFIG[acl] = "--with-acl,--without-acl"
+PACKAGECONFIG[xattr] = "--with-xattr,--without-xattr"
 PACKAGECONFIG[gpg] = "--enable-gpg,--disable-gpg,\
 gnupg gpgme libgpg-error,\
 ${@ "gnupg" if ("native" in d.getVar("PN")) else "gnupg-gpg"}\
-- 
2.34.1


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

[OE-Core][PATCH v6 2/6] package_ipk.bbclass: add support for ACLs and xattr

[Piotr Łobacz]

Extend OPKGBUILDCMD variable, with additional parameters, depending
on target distro features, in order to support ACLs and xattr.

With fix pushed to the opkg-devel:
https://groups.google.com/g/opkg-devel/c/dYNHrLjDwg8
opkg-build is able to create tar archives with ACLs and xattr.

Signed-off-by: Piotr Łobacz 
---
 meta/classes-global/package_ipk.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-global/package_ipk.bbclass 
b/meta/classes-global/package_ipk.bbclass
index b4b7bc9ac2..5e151be3cd 100644
--- a/meta/classes-global/package_ipk.bbclass
+++ b/meta/classes-global/package_ipk.bbclass
@@ -15,7 +15,7 @@ IPKGCONF_SDK_TARGET = "${WORKDIR}/opkg-sdk-target.conf"
 PKGWRITEDIRIPK = "${WORKDIR}/deploy-ipks"
 
 # Program to be used to build opkg packages
-OPKGBUILDCMD ??= 'opkg-build -Z xz -a "${XZ_DEFAULTS}"'
+OPKGBUILDCMD ??= 'opkg-build -Z xz -a "${XZ_DEFAULTS}" 
"${@bb.utils.contains('DISTRO_FEATURES', 'acl', '-A', '', d)}" 
"${@bb.utils.contains('DISTRO_FEATURES', 'xattr', '-X', '', d)}"'
 
 OPKG_ARGS += "--force_postinstall --prefer-arch-to-version"
 OPKG_ARGS += "${@['', 
'--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
-- 
2.34.1


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

[OE-Core][PATCH v6 1/6] bitbake.conf: add acl and xattr distro native features support

[Piotr Łobacz]

Include support for ACLs and extended file attributes for native
builds, by default.

Signed-off-by: Piotr Łobacz 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 9625a6fef4..8dd615 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -904,7 +904,7 @@ IMAGE_FEATURES += "${EXTRA_IMAGE_FEATURES}"
 
 # Native distro features (will always be used for -native, even if they
 # are not enabled for target)
-DISTRO_FEATURES_NATIVE ?= "x11 ipv6 xattr"
+DISTRO_FEATURES_NATIVE ?= "acl x11 ipv6 xattr"
 DISTRO_FEATURES_NATIVESDK ?= "x11"
 
 # Normally target distro features will not be applied to native builds:
-- 
2.34.1


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

Re: [OE-Core][PATCH] eudev: Add group sgx to eudev package

[Alex Kiernan]

On Wed, Jul 19, 2023 at 1:30 PM Alexandre Belloni
 wrote:
>
> Hello,
>
> I had a bit of trouble to find this but this causes the following
> oe-selftest failure:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/2274/steps/14/logs/stdio
>
> 2023-07-18 20:56:16,128 - oe-selftest - INFO - 
> gdbserver.GdbServerTest.test_gdb_server (subunit.RemotedTestCase)
> 2023-07-18 20:56:16,129 - oe-selftest - INFO -  ... ERROR
> Stderr:
> 2023-07-18 20:32:39,581 - oe-selftest - INFO - Adding: "include selftest.inc" 
> in 
> /home/pokybuild/yocto-worker/oe-selftest/build/build-st-836115/conf/local.conf
> 2023-07-18 20:32:39,582 - oe-selftest - INFO - Adding: "include bblayers.inc" 
> in bblayers.conf
> 2023-07-18 20:56:16,129 - oe-selftest - INFO - 14: 7/58 224/529 (269.86s) (0 
> failed) (gdbserver.GdbServerTest.test_gdb_server)
> 2023-07-18 20:56:16,129 - oe-selftest - INFO - 
> testtools.testresult.real._StringException: Traceback (most recent call last):
>   File 
> "/home/pokybuild/yocto-worker/oe-selftest/build/meta/lib/oeqa/selftest/cases/gdbserver.py",
>  line 43, in test_gdb_server
> shutil.unpack_archive(filename, debugfs)
>   File "/usr/lib64/python3.11/shutil.py", line 1323, in unpack_archive
> func(filename, extract_dir, **kwargs)
>   File "/usr/lib64/python3.11/shutil.py", line 1244, in _unpack_tarfile
> tarobj.extractall(extract_dir, filter=filter)
>   File "/usr/lib64/python3.11/tarfile.py", line 2257, in extractall
> self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
>   File "/usr/lib64/python3.11/tarfile.py", line 2324, in _extract_one
> self._handle_fatal_error(e)
>   File "/usr/lib64/python3.11/tarfile.py", line 2320, in _extract_one
> self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
>   File "/usr/lib64/python3.11/tarfile.py", line 2403, in _extract_member
> self.makefile(tarinfo, targetpath)
>   File "/usr/lib64/python3.11/tarfile.py", line 2448, in makefile
> with bltn_open(targetpath, "wb") as target:
>  ^^^
> PermissionError: [Errno 13] Permission denied: 
> '/tmp/debugfs-j_xgxhkm/./etc/gshadow'
>

That's interesting... really not sure why /etc/shadow doesn't trigger
this failure too (which is in the same set of tarballs). That said
I've no idea what the fix is, since this looks like collateral damage
rather than something which this change obviously broke. Will stare at
it a bit more.

> On 14/07/2023 15:09:55+0100, Alex Kiernan wrote:
> > Fix startup warning:
> >
> >   udevd[171]: specified group 'sgx' unknown
> >
> > This mirrors the change in bab455cd9b1b ("systemd: add group sgx to udev
> > package") for systemd-udev.
> >
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> >  meta/recipes-core/udev/eudev_3.2.12.bb | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/udev/eudev_3.2.12.bb 
> > b/meta/recipes-core/udev/eudev_3.2.12.bb
> > index 572ccecafd0c..4268bcc2c5de 100644
> > --- a/meta/recipes-core/udev/eudev_3.2.12.bb
> > +++ b/meta/recipes-core/udev/eudev_3.2.12.bb
> > @@ -18,7 +18,7 @@ SRC_URI[sha256sum] = 
> > "ccdd64ec3c381d3c3ed0e99d2e70d1f62988c7763de89ca7bdffafa5ea
> >
> >  GITHUB_BASE_URI = "https://github.com/eudev-project/eudev/releases;
> >
> > -inherit autotools update-rc.d qemu pkgconfig features_check manpages 
> > github-releases
> > +inherit autotools update-rc.d qemu pkgconfig features_check manpages 
> > github-releases useradd
> >
> >  CONFLICT_DISTRO_FEATURES = "systemd"
> >
> > @@ -85,3 +85,6 @@ pkg_postinst:${PN}-hwdb () {
> >  pkg_prerm:${PN}-hwdb () {
> >   rm -f $D${sysconfdir}/udev/hwdb.bin
> >  }
> > +
> > +USERADD_PACKAGES = "${PN}"
> > +GROUPADD_PARAM:${PN} = "-r sgx"
> > --
> > 2.39.0
> >
>
> >
> > 
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



--
Alex Kiernan

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

Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Bruce Ashfield]

On Wed, Jul 19, 2023 at 1:44 PM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Wed, Jul 19, 2023 at 1:32 PM Petr Gotthard
>  wrote:
> >
> > Hello,
> > the out-of-tree kernel modules built with latest master have broken 
> > "vermagic" and thus cannot be loaded.
> >
> > The patch 
> > https://git.yoctoproject.org/poky/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786
> > added to meta/classes-recipe/kernel-arch.bbclass:
> > export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
> > so when somebody sets the KERNEL_LOCALVERSION, the kernel is build with 
> > this suffix. So far so good.
> >
> > The problem is that the "make-mod-scripts" doesn't know the 
> > KERNEL_LOCALVERSION, so it does not set the LOCALVERSION.
> > When the LOCALVERSION is not set, one suffix used to build the kernel is 
> > missing, the module "vermagic" doesn't match the kernel and the out-of-tree 
> > modules fail to load.
> > For example, after building the kernel the 
> > "kernel-build-artifacts/include/generated/utsrelease.h" contains 
> > "6.1.33-g8f7f371be2", however after running "make-mod-scripts" it's only 
> > "6.1.33".
> >
>
> Hmm.
>
> I explicitly tested this scenario to make sure it worked, since you
> run into the same issue when building modules on-target.
>
> make-mod-scripts is running out of the same SCM as the main kernel
> build, so it should match, and did in my testing (otherwise
> lttng-modules wouldn't work).

'er wait, I think I see the issue. I have a local change that isn't ready for
submission that changes the way make-mod-scripts build, which may
have masked things. Plus, I'm never letting the SCM information be
automatically picked up into the localversion.

Which goes back to me being interested in your kernel recipe, version,
etc. This is less of an issue with that commit, versus an issue with newer
kernel versions (without that change, you always get a "+" added to the
local version, which ensures that absolutely nothing built out of tree
ever loads).

To answer your other question, we can't really store the SCM version
anywhere else, as it is not always correct when you consider all of the
ways we build kernel modules. That's why I'm inhibiting the localversion
and making sure it is explicitly set.

Bruce


>
> Can you send the exact steps, which kernel recipe you are using, etc.
> That way I can reproduce the problem locally.
>
> Bruce
>
>
> > One solution to this would be to store the KERNEL_LOCALVERSION somewhere 
> > and then restore it by the "make-mod-scripts" to make sure the build 
> > environment is initialized properly. I am just not sure where is the right 
> > storage for this.
> >
> >
> > Petr
> >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

Re: [OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Bruce Ashfield]

On Wed, Jul 19, 2023 at 1:32 PM Petr Gotthard
 wrote:
>
> Hello,
> the out-of-tree kernel modules built with latest master have broken 
> "vermagic" and thus cannot be loaded.
>
> The patch 
> https://git.yoctoproject.org/poky/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786
> added to meta/classes-recipe/kernel-arch.bbclass:
> export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
> so when somebody sets the KERNEL_LOCALVERSION, the kernel is build with this 
> suffix. So far so good.
>
> The problem is that the "make-mod-scripts" doesn't know the 
> KERNEL_LOCALVERSION, so it does not set the LOCALVERSION.
> When the LOCALVERSION is not set, one suffix used to build the kernel is 
> missing, the module "vermagic" doesn't match the kernel and the out-of-tree 
> modules fail to load.
> For example, after building the kernel the 
> "kernel-build-artifacts/include/generated/utsrelease.h" contains 
> "6.1.33-g8f7f371be2", however after running "make-mod-scripts" it's only 
> "6.1.33".
>

Hmm.

I explicitly tested this scenario to make sure it worked, since you
run into the same issue when building modules on-target.

make-mod-scripts is running out of the same SCM as the main kernel
build, so it should match, and did in my testing (otherwise
lttng-modules wouldn't work).

Can you send the exact steps, which kernel recipe you are using, etc.
That way I can reproduce the problem locally.

Bruce


> One solution to this would be to store the KERNEL_LOCALVERSION somewhere and 
> then restore it by the "make-mod-scripts" to make sure the build environment 
> is initialized properly. I am just not sure where is the right storage for 
> this.
>
>
> Petr
>
>
> 
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

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

[OE-core] make-mod-scripts doesn't know KERNEL_LOCALVERSION

[Petr Gotthard]

Hello,
the out-of-tree kernel modules built with latest master have broken "vermagic" 
and thus cannot be loaded.

The patch 
https://git.yoctoproject.org/poky/commit/?id=bb0f9e87700aa40ec8db880ede3c018c1d055786
added to meta/classes-recipe/kernel-arch.bbclass:
export LOCALVERSION ?= "${KERNEL_LOCALVERSION}"
so when somebody sets the KERNEL_LOCALVERSION, the kernel is build with this 
suffix. So far so good.

The problem is that the "make-mod-scripts" doesn't know the 
KERNEL_LOCALVERSION, so it does not set the LOCALVERSION.
When the LOCALVERSION is not set, one suffix used to build the kernel is 
missing, the module "vermagic" doesn't match the kernel and the out-of-tree 
modules fail to load.
For example, after building the kernel the 
"kernel-build-artifacts/include/generated/utsrelease.h" contains 
"6.1.33-g8f7f371be2", however after running "make-mod-scripts" it's only 
"6.1.33".

One solution to this would be to store the KERNEL_LOCALVERSION somewhere and 
then restore it by the "make-mod-scripts" to make sure the build environment is 
initialized properly. I am just not sure where is the right storage for this.


Petr


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

Re: [OE-core] Rust Oe-Selftest implementation V15 Testing

[Richard Purdie]

On Wed, 2023-07-19 at 12:58 +0100, Alex Kiernan wrote:
> On Wed, Jul 19, 2023 at 11:49 AM Richard Purdie
>  wrote:
> > 
> > On Mon, 2023-07-17 at 16:08 +0100, Richard Purdie wrote:
> > > On Mon, 2023-07-17 at 16:34 +0200, Alexandre Belloni wrote:
> > > > Hello,
> > > > 
> > > > I got some feedback from RP:
> > > > 
> > > > http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/testresult-report.txt
> > > > 
> > > > This shows warnings for duplicate tests and he also asks being where the
> > > > qemuarm64 went, both issues being probably related.
> > > 
> > > I had a look and you probably need to add a:
> > > 
> > > @OETestTag("toolchain-user")
> > > @OETestTag("runqemu")
> > > class RustSelfTestBase(RustSelfTestSystemEmulated):
> > > def test_check(self):
> > > self.test_rust()
> > > 
> > > section to the tests to allow the tests to run for the non-IA
> > > architectures that use usermode emulation for the other tests which
> > > rust can't.
> > > 
> > > That then just brings the question of why there are duplicate tests
> > > results being reported. This is where the result for an ID is being
> > > reported more than once. I haven't looked into why that might be
> > > happening.
> > 
> > I really do want to get this rust test suite issue resolved so I went
> > digging into the code to find out what is really going on.
> > 
> > Firstly, the duplicate test results. The issue is that you defined the
> > core class like this:
> > 
> >  class RustSelfTestSystemEmulated(OESelftestTestCase, 
> > OEPTestResultTestCase):
> >  def test_rust
> > 
> > and python unittest has a convention where anything starting "test_" is
> > a test.
> > 
> > This meant that the rust test ran unguarded in all the oe-selftest
> > targets on the autobuilder and not just in the toolchain-system
> > filtered section.
> > 
> > The easiest fix is to drop the RustSelfTestBase class and move the
> > toolchain-system decorator to RustSelfTestSystemEmulated. That will
> > resolve the duplicate test warnings and ensure things run where they
> > should. You could have worked out this issue by finding that there were
> > rust test results in oe-selftest-* testresults.json files, e.g. here:
> > 
> > http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/oe-selftest-centos/oeqa/testresults.json
> > 
> > Moving on, the test result names really don't look good with the
> > "[ui]  " and similar prefixes in the results file. I've patched a tweak
> > in to drop that.
> > 
> > I also noticed that there were no skipped tests being reported in the
> > results. This was due to "SKIP" being used instead of "SKIPPED" which
> > resulttool looks for.
> > 
> > We need to also add the toolchain-user decorator to make sure that the
> > tests run for the "user" architectures since we don't have any user
> > mode rust test equivalent.
> > 
> > I've rolled all these changes into a patch on master-next:
> > 
> > https://git.yoctoproject.org/poky/commit/?h=master-next=46ab84785da15ac156ee0b4a693ce8bb5ccf8c22
> > 
> > which I'll put into testing.
> > 
> > Looking to the future, I have concerns about the ease of maintenance of
> > this huge patch to rust to disable failing tests. I'd propose we change
> > this to a hardcoded list of tests to ignore in the result parsing code
> > which will be easier to maintain in the future.
> > 
> 
> That feels far more maintainable - the scale of the  patch really
> concerned me. Also I guess if it's just a list, then running with
> everything enabled on upgrade to see what passes/fails would be a
> relatively easy option.

I've gone ahead and merged the rust selftest changes since we had a
successful test run on the autobuilder and I think that patch series
has gone on long enough. I pushed my tweaks in a follow up commit.

I'd happily take a patch changing the current patch for the approach
mentioned above as a next step. I appreciate it will mean we need to
tweak the 1.71.0 update but felt getting the tests in was probably the
next logical step.

Cheers,

Richard



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

[OE-core][PATCH] xeyes: upgrade 1.2.0 -> 1.3.0

[Trevor Gamblin]

Use the sha256sum for the .xz archive instead of .bz2 because of
upstream commit bdd57f3. Add SRC_URI_EXT to match.

Changelog:

637b948 (HEAD -> master, tag: xeyes-1.3.0, origin/master, origin/HEAD) xeyes 
1.3.0
6f6c975 Implement multi-ocular support, add biblical example
f30ef4e Print which argument was unknown before giving usage message
e7a54da Add -help & -version options
e38962e gitlab CI: stop requiring Signed-off-by in commits
c060e6d man page: remove out-of-date reference to X(7)
ebbd57a Fix spelling/wording issues
bdd57f3 Build xz tarballs instead of bzip2
700a551 gitlab CI: add a basic build test

Signed-off-by: Trevor Gamblin 
---
 .../xorg-app/{xeyes_1.2.0.bb => xeyes_1.3.0.bb}| 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)
 rename meta/recipes-graphics/xorg-app/{xeyes_1.2.0.bb => xeyes_1.3.0.bb} (77%)

diff --git a/meta/recipes-graphics/xorg-app/xeyes_1.2.0.bb 
b/meta/recipes-graphics/xorg-app/xeyes_1.3.0.bb
similarity index 77%
rename from meta/recipes-graphics/xorg-app/xeyes_1.2.0.bb
rename to meta/recipes-graphics/xorg-app/xeyes_1.3.0.bb
index 73d09f058d..3d1a7063ea 100644
--- a/meta/recipes-graphics/xorg-app/xeyes_1.2.0.bb
+++ b/meta/recipes-graphics/xorg-app/xeyes_1.3.0.bb
@@ -8,6 +8,7 @@ PE = "1"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=3ea51b365051ac32d1813a7dbaa4bfc6"
 
-SRC_URI[sha256sum] = 
"f8a17e23146bef1ab345a1e303c6749e42aaa7bcf4f25428afad41770721b6db"
+SRC_URI_EXT = "xz"
+SRC_URI[sha256sum] = 
"0950c600bf33447e169a539ee6655ef9f36d6cebf2c1be67f7ab55dacb753023"
 
 DEPENDS += "libxau libxt libxext libxmu libxrender libxi"
-- 
2.41.0


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

Re: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro native features support

[Piotr Łobacz]

Ok I have found the root cause for this warning.

I will post it later on and this is another fix to opkg.

BR
Piotr

Od: openembedded-core@lists.openembedded.org 
 w imieniu użytkownika Piotr Łobacz 
via lists.openembedded.org 
Wysłane: Wednesday, July 19, 2023 3:36:42 PM
Do: Richard Purdie ; Alexandre Belloni 

DW: Alex Stewart ; 
openembedded-core@lists.openembedded.org 

Temat: ODP: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro 
native features support

HI all, Hi Richard thx for quick response.
Generally this patch for tar has been already applied to the upstream 
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.savannah.gnu.org%2Fcgit%2Ftar.git%2Fcommit%2F%3Fid%3D5461025569c2d946fb31b79f16f60e923bbd79f9=05%7C01%7Cp.lobacz%40welotec.com%7C4ee44b94eb4d4bf9d55d08db885d34ef%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638253706138546929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IxeRXlnaQ00oluPfxoZaRFlz4DIcZLKQElwYMCrsgus%3D=0
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://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.yoctoproject.org%2Fopkg%2Ftree%2Flibopkg%2Fopkg_archive.c%23n272=05%7C01%7Cp.lobacz%40welotec.com%7C4ee44b94eb4d4bf9d55d08db885d34ef%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638253706138546929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=KqsMAR3VjZyI39KA4W22627MF6RH%2BCswvSAggm4Wi38%3D=0
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 
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.openembedded.org%2Fopenembedded-core%2Ftree%2Fmeta%2Flib%2Foe%2Fpackage_manager%2Fipk%2F__init__.py%23n368=05%7C01%7Cp.lobacz%40welotec.com%7C4ee44b94eb4d4bf9d55d08db885d34ef%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638253706138546929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=B%2BcC8DBiKxR4GJ5lEdEaK3ZSQ7mdip0S%2Fl6VjVT3gCo%3D=0
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 
https://eur04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgit.openembedded.org%2Fopenembedded-core%2Ftree%2Fmeta%2Flib%2Foe%2Fpackage_manager%2Fipk%2F__init__.py%23n366=05%7C01%7Cp.lobacz%40welotec.com%7C4ee44b94eb4d4bf9d55d08db885d34ef%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638253706138546929%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ffBgezGhTHvHaP9iPddoCYk20ZXKRLrN%2FRiTAwSLTcU%3D=0
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 

Re: [OE-core] [RFC 0/1] Add bblock helper script

[Richard Purdie]

Hi,

Thanks for looking at this, I think it could become a really useful and
well used extension to bitbake!

On Wed, 2023-07-19 at 16:27 +0200, Julien Stephan wrote:
> I am currently working on bug #13425 and I would like to post my wip
> script as an RFC to get feedback on it, before going further in the
> development.
> 
> The script `script/bblock` can be used with the following command:
> 
> bblock [list of recipes to lock]
> 
> Here is a summary of what is currently implemented:
> * can lock several recipes at once
> * on first execution bblock will append `require bblock.inc` in
>   `build/conf/auto.conf` (creates `auto.conf` if it doesn't exist)
> * on first execution creates the file `build/conf/bblock.inc` with a
>   dedicated header and:
>- adds SIGGEN_LOCKEDSIGS_TYPES += "t-bblock"
>- adds SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn" to display warning but
>  do not stop the build
> * loops over all recipes to lock and adds entry with latest "do_compile"
>   signature in `conf/bblock.inc`, such as: SIGGEN_LOCKEDSIGS_t-bblock += 
> "bc:do_compile:e233cd793137a92dd575a417a2877e324ce526c4dc4a7db652abb9512f406f1f"
> 
> Limitations:
> * only gets do_compile signature for now as a POC
> * `bblock reset [list of recipes]` not yet implemented
> * no check if a recipe is already locked
> 
> Steps to test the script:
> bitbake bc --> generate a signature for bc's tasks
> bblock bc
> # modify do_compile in bc recipe to force signature change
> bitbake bc --> throws the following warning: `WARNING: The bc:do_compile sig 
> is computed to be 
> 680bd6c291bf88e379e0c405a773cf5f81851e1a52570398cefd0196000ac1ef, but the sig 
> is locked to e233cd793137a92dd575a417a2877e324ce526c4dc4a7db652abb9512f406f1f 
> in SIGGEN_LOCKEDSIGS_t-bblock`

Ideally we should just be able to run bblock bc without any previous
commands and it would lock the file.

We may want to note that some recipes are locked somehow too so the
user realises this if they leave a build and come back to it later,
forgetting what they did (a bit like the -f option leaves a warning on
later builds to remind the user).

To simplify things, I think it would be reasonable to add a bblock.inc
file unconditionally in our core configuration so that it is always
included if present, just to make the tool easier since I think this
will be a common use.

Also, you're going to need to think about package architectures.
Imagine I change MACHINE and then try "bitbake bc", it probably
shouldn't be locked any more, it certainly shouldn't try and match the
previous locked values as in most cases they will be different.

This is why if you do a "bitbake core-image-minimal -S none" and look
at the loacked-sigs.inc file, you'll see sections like:

SIGGEN_LOCKEDSIGS_t-allarch 
SIGGEN_LOCKEDSIGS_t-x86-64 
SIGGEN_LOCKEDSIGS_t-x86-64-v3
SIGGEN_LOCKEDSIGS_t-qemux86-64

and a list of types:

SIGGEN_LOCKEDSIGS_TYPES:qemux86-64 = "t-all t-allarch t-qemux86-64 t-x86-64 
t-x86-64-v3"

This means the locks only apply to specific package architectures,
which allows you to change MACHINE.
> 
> I also have a point I would like to discuss: I only get signature for
> do_compile for the POC but wondering what should I do here:
> * have a set of predefined task to lock, in that case how to choose the
>   tasks?

I think by default bblock would lock all tasks for a recipe? It might
take a task option to allow a specific task to be specified?

> * compute the list of all available tasks for a given recipe and get
>   signature for all? Is there a way to get such list without using
>   `infoil.build_targets(pn, "listtasks", handle_events=True)` as this
>   will start bitbake, takes some time and requires some processing of
>   the output

We may need to add some API to bitbake to get this information. The
task hashes do need a full task graph to compute so it isn't a simple
operation with a cold cache.

> * add an option for the user to specify the task he wants to lock? (this
>   may be useful to add anyway)

Yes, I think that would make sense.

> My branch is available here [1]
> 
> Am I going into the right direction?

I think you've made a good start, yes!

Cheers,

Richard


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

[OE-core] [RFC 0/1] Add bblock helper script

[Julien Stephan]

Hi all,

I am currently working on bug #13425 and I would like to post my wip
script as an RFC to get feedback on it, before going further in the
development.

The script `script/bblock` can be used with the following command:

bblock [list of recipes to lock]

Here is a summary of what is currently implemented:
* can lock several recipes at once
* on first execution bblock will append `require bblock.inc` in
  `build/conf/auto.conf` (creates `auto.conf` if it doesn't exist)
* on first execution creates the file `build/conf/bblock.inc` with a
  dedicated header and:
 - adds SIGGEN_LOCKEDSIGS_TYPES += "t-bblock"
 - adds SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn" to display warning but
   do not stop the build
* loops over all recipes to lock and adds entry with latest "do_compile"
  signature in `conf/bblock.inc`, such as: SIGGEN_LOCKEDSIGS_t-bblock += 
"bc:do_compile:e233cd793137a92dd575a417a2877e324ce526c4dc4a7db652abb9512f406f1f"

Limitations:
* only gets do_compile signature for now as a POC
* `bblock reset [list of recipes]` not yet implemented
* no check if a recipe is already locked

Steps to test the script:
bitbake bc --> generate a signature for bc's tasks
bblock bc
# modify do_compile in bc recipe to force signature change
bitbake bc --> throws the following warning: `WARNING: The bc:do_compile sig is 
computed to be 
680bd6c291bf88e379e0c405a773cf5f81851e1a52570398cefd0196000ac1ef, but the sig 
is locked to e233cd793137a92dd575a417a2877e324ce526c4dc4a7db652abb9512f406f1f 
in SIGGEN_LOCKEDSIGS_t-bblock`

I also have a point I would like to discuss: I only get signature for
do_compile for the POC but wondering what should I do here:
* have a set of predefined task to lock, in that case how to choose the
  tasks?
* compute the list of all available tasks for a given recipe and get
  signature for all? Is there a way to get such list without using
  `infoil.build_targets(pn, "listtasks", handle_events=True)` as this
  will start bitbake, takes some time and requires some processing of
  the output
* add an option for the user to specify the task he wants to lock? (this
  may be useful to add anyway)

My branch is available here [1]

Am I going into the right direction?

Cheers
Julien

[1]: https://git.yoctoproject.org/poky-contrib/commit/?h=jstephan/bblock

Julien Stephan (1):
  scripts/bblock: add a script to lock/unlock recipes

 scripts/bblock | 92 ++
 1 file changed, 92 insertions(+)
 create mode 100755 scripts/bblock

--
2.41.0

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

[OE-core] [RFC 1/1] scripts/bblock: add a script to lock/unlock recipes

[Julien Stephan]

bblock script allows to lock recipes to latest signatures. The idea is
to prevent some recipes to be rebuilt during development. For example
when working on rust recipe, one may not want rust-native to be
rebuilt.

This tool can be used, with proper environment set up, using the following
command:

bblock 

if 's task signatures change it will not be built again and
sstate cache will be used.

[YOCTO #13425]

Signed-off-by: Julien Stephan 
---
 scripts/bblock | 110 +
 1 file changed, 110 insertions(+)
 create mode 100755 scripts/bblock

diff --git a/scripts/bblock b/scripts/bblock
new file mode 100755
index 000..d463ade6212
--- /dev/null
+++ b/scripts/bblock
@@ -0,0 +1,110 @@
+#!/usr/bin/env python3
+# bblock
+# lock/unlock task to latest signature
+#
+# Copyright (c) 2020 BayLibre, SAS
+# Author: Julien Stepahn 
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import os
+import sys
+import logging
+
+scripts_path = os.path.dirname(os.path.realpath(__file__))
+lib_path = scripts_path + "/lib"
+sys.path = sys.path + [lib_path]
+
+import scriptpath
+
+scriptpath.add_bitbake_lib_path()
+
+import bb.tinfoil
+import bb.msg
+
+import argparse_oe
+
+myname = os.path.basename(sys.argv[0])
+logger = bb.msg.logger_create(myname)
+
+
+def find_siginfo(tinfoil, pn, taskname, sigs=None):
+result = None
+tinfoil.set_event_mask(
+[
+"bb.event.FindSigInfoResult",
+"logging.LogRecord",
+"bb.command.CommandCompleted",
+"bb.command.CommandFailed",
+]
+)
+ret = tinfoil.run_command("findSigInfo", pn, taskname, sigs)
+if ret:
+while True:
+event = tinfoil.wait_event(1)
+if event:
+if isinstance(event, bb.command.CommandCompleted):
+break
+elif isinstance(event, bb.command.CommandFailed):
+logger.error(str(event))
+sys.exit(2)
+elif isinstance(event, bb.event.FindSigInfoResult):
+result = event.result
+elif isinstance(event, logging.LogRecord):
+logger.handle(event)
+else:
+logger.error("No result returned from findSigInfo command")
+sys.exit(2)
+return result
+
+
+def main():
+parser = argparse_oe.ArgumentParser(description="Lock and unlock a recipe")
+parser.add_argument("pn", nargs="*", help="Space separated list of recipe 
to lock")
+
+global_args, unparsed_args = parser.parse_known_args()
+
+with bb.tinfoil.Tinfoil() as tinfoil:
+tinfoil.prepare(config_only=True)
+builddir = tinfoil.config_data.getVar("TOPDIR")
+autoconffile = "{builddir}/conf/auto.conf".format(builddir=builddir)
+lockfile = "{builddir}/conf/bblock.inc".format(builddir=builddir)
+with open(lockfile, "a") as lockfile:
+s = ""
+if lockfile.tell() == 0:
+s = "# Generated by bblock\n"
+s += 'SIGGEN_LOCKEDSIGS_TYPES += "t-bblock"\n'
+s += 'SIGGEN_LOCKEDSIGS_TASKSIG_CHECK = "warn"'
+with open(autoconffile, "a") as autoconffile:
+autoconffile.write("require bblock.inc")
+for pn in global_args.pn:
+taskname = "do_compile"
+filedates = find_siginfo(tinfoil, pn, taskname)
+latestfiles = sorted(
+filedates.keys(), key=lambda f: filedates[f], reverse=True
+)
+if not latestfiles:
+logger.error(
+"No sigdata files found matching {pn} 
{taskname}".format(
+pn=pn, taskname=taskname
+)
+)
+sys.exit(1)
+sig = latestfiles[0].split("sigdata.")[1]
+s += "\n"
+s += 'SIGGEN_LOCKEDSIGS_t-bblock += 
"{pn}:{taskname}:{sig}"\n'.format(
+pn=pn, taskname=taskname, sig=sig
+)
+lockfile.write(s)
+
+
+if __name__ == "__main__":
+try:
+ret = main()
+except Exception:
+ret = 1
+import traceback
+
+traceback.print_exc()
+sys.exit(ret)
-- 
2.41.0


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

ODP: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro native features support

[Piotr Łobacz]

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 
Wysłane: środa, 19 lipca 2023 10:37
Do: Piotr Łobacz ; Alexandre Belloni 

DW: Alex Stewart ; 
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 +, 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 

Re: [OE-core] Rust Oe-Selftest implementation V15 Testing

[Sundeep KOKKONDA via lists.openembedded.org]

From: Alex Kiernan 
Sent: 19 July 2023 17:28
To: Richard Purdie 
Cc: Alexandre Belloni ; Shinde, Yash 
; openembedded-core 
; MacLeod, Randy 
; Kokkonda, Sundeep 
; Gowda, Naveen 
Subject: Re: [OE-core] Rust Oe-Selftest implementation V15 Testing

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Wed, Jul 19, 2023 at 11:49 AM Richard Purdie
 wrote:
>
> On Mon, 2023-07-17 at 16:08 +0100, Richard Purdie wrote:
> > On Mon, 2023-07-17 at 16:34 +0200, Alexandre Belloni wrote:
> > > Hello,
> > >
> > > I got some feedback from RP:
> > >
> > > http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/testresult-report.txt
> > >
> > > This shows warnings for duplicate tests and he also asks being where the
> > > qemuarm64 went, both issues being probably related.
> >
> > I had a look and you probably need to add a:
> >
> > @OETestTag("toolchain-user")
> > @OETestTag("runqemu")
> > class RustSelfTestBase(RustSelfTestSystemEmulated):
> > def test_check(self):
> > self.test_rust()
> >
> > section to the tests to allow the tests to run for the non-IA
> > architectures that use usermode emulation for the other tests which
> > rust can't.
> >
> > That then just brings the question of why there are duplicate tests
> > results being reported. This is where the result for an ID is being
> > reported more than once. I haven't looked into why that might be
> > happening.
>
> I really do want to get this rust test suite issue resolved so I went
> digging into the code to find out what is really going on.
>
> Firstly, the duplicate test results. The issue is that you defined the
> core class like this:
>
>  class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
>  def test_rust
>
> and python unittest has a convention where anything starting "test_" is
> a test.
>
> This meant that the rust test ran unguarded in all the oe-selftest
> targets on the autobuilder and not just in the toolchain-system
> filtered section.
>
> The easiest fix is to drop the RustSelfTestBase class and move the
> toolchain-system decorator to RustSelfTestSystemEmulated. That will
> resolve the duplicate test warnings and ensure things run where they
> should. You could have worked out this issue by finding that there were
> rust test results in oe-selftest-* testresults.json files, e.g. here:
>
> http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/oe-selftest-centos/oeqa/testresults.json
>
> Moving on, the test result names really don't look good with the
> "[ui]  " and similar prefixes in the results file. I've patched a tweak
> in to drop that.
>
> I also noticed that there were no skipped tests being reported in the
> results. This was due to "SKIP" being used instead of "SKIPPED" which
> resulttool looks for.
>
> We need to also add the toolchain-user decorator to make sure that the
> tests run for the "user" architectures since we don't have any user
> mode rust test equivalent.
>
> I've rolled all these changes into a patch on master-next:
>
> https://git.yoctoproject.org/poky/commit/?h=master-next=46ab84785da15ac156ee0b4a693ce8bb5ccf8c22
>
> which I'll put into testing.
>
> Looking to the future, I have concerns about the ease of maintenance of
> this huge patch to rust to disable failing tests. I'd propose we change
> this to a hardcoded list of tests to ignore in the result parsing code
> which will be easier to maintain in the future.
>

That feels far more maintainable - the scale of the  patch really
concerned me. Also I guess if it's just a list, then running with
everything enabled on upgrade to see what passes/fails would be a
relatively easy option.

Hello Alex, Hello Richard,

During next rebase to rust 1.71.0 we will update this.



> We may want to take that as a subsequent follow up patch.
>
> Cheers,
>
> Richard
>
> 
>


--
Alex Kiernan

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

Re: [OE-Core][PATCH] eudev: Add group sgx to eudev package

[Alexandre Belloni via lists.openembedded.org]

Hello,

I had a bit of trouble to find this but this causes the following
oe-selftest failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/2274/steps/14/logs/stdio

2023-07-18 20:56:16,128 - oe-selftest - INFO - 
gdbserver.GdbServerTest.test_gdb_server (subunit.RemotedTestCase)
2023-07-18 20:56:16,129 - oe-selftest - INFO -  ... ERROR
Stderr:
2023-07-18 20:32:39,581 - oe-selftest - INFO - Adding: "include selftest.inc" 
in 
/home/pokybuild/yocto-worker/oe-selftest/build/build-st-836115/conf/local.conf
2023-07-18 20:32:39,582 - oe-selftest - INFO - Adding: "include bblayers.inc" 
in bblayers.conf
2023-07-18 20:56:16,129 - oe-selftest - INFO - 14: 7/58 224/529 (269.86s) (0 
failed) (gdbserver.GdbServerTest.test_gdb_server)
2023-07-18 20:56:16,129 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest/build/meta/lib/oeqa/selftest/cases/gdbserver.py",
 line 43, in test_gdb_server
shutil.unpack_archive(filename, debugfs)
  File "/usr/lib64/python3.11/shutil.py", line 1323, in unpack_archive
func(filename, extract_dir, **kwargs)
  File "/usr/lib64/python3.11/shutil.py", line 1244, in _unpack_tarfile
tarobj.extractall(extract_dir, filter=filter)
  File "/usr/lib64/python3.11/tarfile.py", line 2257, in extractall
self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
  File "/usr/lib64/python3.11/tarfile.py", line 2324, in _extract_one
self._handle_fatal_error(e)
  File "/usr/lib64/python3.11/tarfile.py", line 2320, in _extract_one
self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
  File "/usr/lib64/python3.11/tarfile.py", line 2403, in _extract_member
self.makefile(tarinfo, targetpath)
  File "/usr/lib64/python3.11/tarfile.py", line 2448, in makefile
with bltn_open(targetpath, "wb") as target:
 ^^^
PermissionError: [Errno 13] Permission denied: 
'/tmp/debugfs-j_xgxhkm/./etc/gshadow'

On 14/07/2023 15:09:55+0100, Alex Kiernan wrote:
> Fix startup warning:
> 
>   udevd[171]: specified group 'sgx' unknown
> 
> This mirrors the change in bab455cd9b1b ("systemd: add group sgx to udev
> package") for systemd-udev.
> 
> Signed-off-by: Alex Kiernan 
> ---
> 
>  meta/recipes-core/udev/eudev_3.2.12.bb | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/udev/eudev_3.2.12.bb 
> b/meta/recipes-core/udev/eudev_3.2.12.bb
> index 572ccecafd0c..4268bcc2c5de 100644
> --- a/meta/recipes-core/udev/eudev_3.2.12.bb
> +++ b/meta/recipes-core/udev/eudev_3.2.12.bb
> @@ -18,7 +18,7 @@ SRC_URI[sha256sum] = 
> "ccdd64ec3c381d3c3ed0e99d2e70d1f62988c7763de89ca7bdffafa5ea
>  
>  GITHUB_BASE_URI = "https://github.com/eudev-project/eudev/releases;
>  
> -inherit autotools update-rc.d qemu pkgconfig features_check manpages 
> github-releases
> +inherit autotools update-rc.d qemu pkgconfig features_check manpages 
> github-releases useradd
>  
>  CONFLICT_DISTRO_FEATURES = "systemd"
>  
> @@ -85,3 +85,6 @@ pkg_postinst:${PN}-hwdb () {
>  pkg_prerm:${PN}-hwdb () {
>   rm -f $D${sysconfdir}/udev/hwdb.bin
>  }
> +
> +USERADD_PACKAGES = "${PN}"
> +GROUPADD_PARAM:${PN} = "-r sgx"
> -- 
> 2.39.0
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [OE-core][PATCH v9 0/3] CVE-check handling

[Andrej Valek via lists.openembedded.org]

Even better,

So I will make one more rebase, just for "[OE-core][PATCH v9 3/3] cve_check:
convert CVE_CHECK_IGNORE to CVE_STATUS"

Regards,
Andrej

On Wed, 2023-07-19 at 11:16 +, Ross Burton wrote:
> On 19 Jul 2023, at 11:54, Richard Purdie 
> wrote:
> > 
> > On Wed, 2023-07-19 at 10:26 +, Valek, Andrej wrote:
> > > Hello,
> > > 
> > > I would like to ask, what's the status here?
> > 
> > I've asked for some people to help review it and I'm waiting on their
> > feedback. FWIW they did promise "this morning" yesterday so they have
> > around 6 minutes!
> 
> I suspect I was that person :). I have no major objections to the patch now.
> 
> Cheers,
> Ross


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

Re: [OE-core] Rust Oe-Selftest implementation V15 Testing

[Alex Kiernan]

On Wed, Jul 19, 2023 at 11:49 AM Richard Purdie
 wrote:
>
> On Mon, 2023-07-17 at 16:08 +0100, Richard Purdie wrote:
> > On Mon, 2023-07-17 at 16:34 +0200, Alexandre Belloni wrote:
> > > Hello,
> > >
> > > I got some feedback from RP:
> > >
> > > http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/testresult-report.txt
> > >
> > > This shows warnings for duplicate tests and he also asks being where the
> > > qemuarm64 went, both issues being probably related.
> >
> > I had a look and you probably need to add a:
> >
> > @OETestTag("toolchain-user")
> > @OETestTag("runqemu")
> > class RustSelfTestBase(RustSelfTestSystemEmulated):
> > def test_check(self):
> > self.test_rust()
> >
> > section to the tests to allow the tests to run for the non-IA
> > architectures that use usermode emulation for the other tests which
> > rust can't.
> >
> > That then just brings the question of why there are duplicate tests
> > results being reported. This is where the result for an ID is being
> > reported more than once. I haven't looked into why that might be
> > happening.
>
> I really do want to get this rust test suite issue resolved so I went
> digging into the code to find out what is really going on.
>
> Firstly, the duplicate test results. The issue is that you defined the
> core class like this:
>
>  class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
>  def test_rust
>
> and python unittest has a convention where anything starting "test_" is
> a test.
>
> This meant that the rust test ran unguarded in all the oe-selftest
> targets on the autobuilder and not just in the toolchain-system
> filtered section.
>
> The easiest fix is to drop the RustSelfTestBase class and move the
> toolchain-system decorator to RustSelfTestSystemEmulated. That will
> resolve the duplicate test warnings and ensure things run where they
> should. You could have worked out this issue by finding that there were
> rust test results in oe-selftest-* testresults.json files, e.g. here:
>
> http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/oe-selftest-centos/oeqa/testresults.json
>
> Moving on, the test result names really don't look good with the
> "[ui]  " and similar prefixes in the results file. I've patched a tweak
> in to drop that.
>
> I also noticed that there were no skipped tests being reported in the
> results. This was due to "SKIP" being used instead of "SKIPPED" which
> resulttool looks for.
>
> We need to also add the toolchain-user decorator to make sure that the
> tests run for the "user" architectures since we don't have any user
> mode rust test equivalent.
>
> I've rolled all these changes into a patch on master-next:
>
> https://git.yoctoproject.org/poky/commit/?h=master-next=46ab84785da15ac156ee0b4a693ce8bb5ccf8c22
>
> which I'll put into testing.
>
> Looking to the future, I have concerns about the ease of maintenance of
> this huge patch to rust to disable failing tests. I'd propose we change
> this to a hardcoded list of tests to ignore in the result parsing code
> which will be easier to maintain in the future.
>

That feels far more maintainable - the scale of the  patch really
concerned me. Also I guess if it's just a list, then running with
everything enabled on upgrade to see what passes/fails would be a
relatively easy option.


> We may want to take that as a subsequent follow up patch.
>
> Cheers,
>
> Richard
>
> 
>


--
Alex Kiernan

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

Re: [OE-core][PATCH v9 0/3] CVE-check handling

[Ross Burton]

On 19 Jul 2023, at 11:54, Richard Purdie  
wrote:
> 
> On Wed, 2023-07-19 at 10:26 +, Valek, Andrej wrote:
>> Hello,
>> 
>> I would like to ask, what's the status here?
> 
> I've asked for some people to help review it and I'm waiting on their
> feedback. FWIW they did promise "this morning" yesterday so they have
> around 6 minutes!

I suspect I was that person :). I have no major objections to the patch now.

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

Re: [OE-core][PATCH v9 0/3] CVE-check handling

[Richard Purdie]

On Wed, 2023-07-19 at 10:26 +, Valek, Andrej wrote:
> Hello,
> 
> I would like to ask, what's the status here?

I've asked for some people to help review it and I'm waiting on their
feedback. FWIW they did promise "this morning" yesterday so they have
around 6 minutes!

Cheers,

Richard



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

Re: [OE-core] Rust Oe-Selftest implementation V15 Testing

[Richard Purdie]

On Mon, 2023-07-17 at 16:08 +0100, Richard Purdie wrote:
> On Mon, 2023-07-17 at 16:34 +0200, Alexandre Belloni wrote:
> > Hello,
> > 
> > I got some feedback from RP:
> > 
> > http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/testresult-report.txt
> > 
> > This shows warnings for duplicate tests and he also asks being where the
> > qemuarm64 went, both issues being probably related.
> 
> I had a look and you probably need to add a:
> 
> @OETestTag("toolchain-user")
> @OETestTag("runqemu")
> class RustSelfTestBase(RustSelfTestSystemEmulated):
> def test_check(self):
> self.test_rust()
> 
> section to the tests to allow the tests to run for the non-IA
> architectures that use usermode emulation for the other tests which
> rust can't.
> 
> That then just brings the question of why there are duplicate tests
> results being reported. This is where the result for an ID is being
> reported more than once. I haven't looked into why that might be
> happening.

I really do want to get this rust test suite issue resolved so I went
digging into the code to find out what is really going on.

Firstly, the duplicate test results. The issue is that you defined the
core class like this:

 class RustSelfTestSystemEmulated(OESelftestTestCase, OEPTestResultTestCase):
 def test_rust

and python unittest has a convention where anything starting "test_" is
a test.

This meant that the rust test ran unguarded in all the oe-selftest
targets on the autobuilder and not just in the toolchain-system
filtered section.

The easiest fix is to drop the RustSelfTestBase class and move the
toolchain-system decorator to RustSelfTestSystemEmulated. That will
resolve the duplicate test warnings and ensure things run where they
should. You could have worked out this issue by finding that there were
rust test results in oe-selftest-* testresults.json files, e.g. here:

http://autobuilder.yocto.io/pub/non-release/20230716-18/testresults/oe-selftest-centos/oeqa/testresults.json

Moving on, the test result names really don't look good with the 
"[ui]  " and similar prefixes in the results file. I've patched a tweak
in to drop that.

I also noticed that there were no skipped tests being reported in the
results. This was due to "SKIP" being used instead of "SKIPPED" which
resulttool looks for.

We need to also add the toolchain-user decorator to make sure that the
tests run for the "user" architectures since we don't have any user
mode rust test equivalent.

I've rolled all these changes into a patch on master-next:

https://git.yoctoproject.org/poky/commit/?h=master-next=46ab84785da15ac156ee0b4a693ce8bb5ccf8c22

which I'll put into testing.

Looking to the future, I have concerns about the ease of maintenance of
this huge patch to rust to disable failing tests. I'd propose we change
this to a hardcoded list of tests to ignore in the result parsing code
which will be easier to maintain in the future.

We may want to take that as a subsequent follow up patch.

Cheers,

Richard

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

Re: [OE-core][PATCH v9 0/3] CVE-check handling

[Andrej Valek via lists.openembedded.org]

Hello,

I would like to ask, what's the status here?

Regards,
Andrej

On Fri, 2023-06-23 at 13:14 +0200, Andrej Valek wrote:
> After discussion in all parallel threads we proposed following variant which
> covers both expressed requirements to have very small number of different cve
> statuses and also very large number of them at the same time.
> This is a compromise version which maybe is not ideal but deals with
> conflicting responses we got.
> 
> Changes compared to version 8:
>  - moved CVE_CHECK_STATUSMAP into separated cve-check-map.conf file
>   - this will allow to use it without inheriting the cve-check class, like for
> SPDX
> 
> Documentation will be updated in separated repository.
> 
>  meta/classes/cve-check.bbclass    |  81 +++-
>  meta/conf/bitbake.conf    |   1 +
>  meta/conf/cve-check-map.conf  |  28 ++
>  .../distro/include/cve-extra-exclusions.inc   | 371 +-
>  meta/lib/oe/cve_check.py  |  25 ++
>  meta/lib/oeqa/selftest/cases/cve_check.py |  26 +-
>  meta/recipes-bsp/grub/grub2.inc   |   6 +-
>  meta/recipes-connectivity/avahi/avahi_0.8.bb  |   3 +-
>  .../recipes-connectivity/bind/bind_9.18.15.bb |   2 +-
>  .../bluez5/bluez5_5.66.bb |   4 +-
>  .../openssh/openssh_9.3p1.bb  |   9 +-
>  .../openssl/openssl_3.1.1.bb  |   3 +-
>  meta/recipes-core/coreutils/coreutils_9.3.bb  |   4 +-
>  meta/recipes-core/glibc/glibc_2.37.bb |  17 +-
>  meta/recipes-core/libxml/libxml2_2.10.4.bb    |   4 -
>  meta/recipes-core/systemd/systemd_253.3.bb    |   3 -
>  meta/recipes-devtools/cmake/cmake.inc |   4 +-
>  meta/recipes-devtools/flex/flex_2.6.4.bb  |   6 +-
>  meta/recipes-devtools/gcc/gcc-13.1.inc    |   3 +-
>  meta/recipes-devtools/git/git_2.39.3.bb   |   7 -
>  meta/recipes-devtools/jquery/jquery_3.6.3.bb  |   5 +-
>  meta/recipes-devtools/ninja/ninja_1.11.1.bb   |   3 +-
>  .../recipes-devtools/python/python3_3.11.3.bb |  13 +-
>  meta/recipes-devtools/qemu/qemu.inc   |  13 +-
>  meta/recipes-devtools/rsync/rsync_3.2.7.bb    |   3 -
>  meta/recipes-devtools/tcltk/tcl_8.6.13.bb |   4 -
>  meta/recipes-extended/cpio/cpio_2.14.bb   |   3 +-
>  meta/recipes-extended/cups/cups.inc   |  17 +-
>  .../ghostscript/ghostscript_10.01.1.bb    |   3 +-
>  .../iputils/iputils_20221126.bb   |   5 +-
>  .../libtirpc/libtirpc_1.3.3.bb    |   3 +-
>  .../logrotate/logrotate_3.21.0.bb |   5 +-
>  meta/recipes-extended/procps/procps_4.0.3.bb  |   4 -
>  meta/recipes-extended/shadow/shadow_4.13.bb   |   7 +-
>  meta/recipes-extended/unzip/unzip_6.0.bb  |   3 +-
>  .../xinetd/xinetd_2.3.15.4.bb |   2 +-
>  meta/recipes-extended/zip/zip_3.0.bb  |   7 +-
>  .../libnotify/libnotify_0.8.2.bb  |   2 +-
>  meta/recipes-gnome/librsvg/librsvg_2.56.0.bb  |   3 +-
>  meta/recipes-graphics/builder/builder_0.1.bb  |   3 +-
>  .../xorg-xserver/xserver-xorg.inc |  19 +-
>  .../linux/cve-exclusion_6.1.inc   |  11 +-
>  .../libpng/libpng_1.6.39.bb   |   3 +-
>  meta/recipes-multimedia/libtiff/tiff_4.5.0.bb |  10 +-
>  .../libgcrypt/libgcrypt_1.10.2.bb |   4 +-
>  .../recipes-support/libxslt/libxslt_1.1.38.bb |   4 +-
>  meta/recipes-support/lz4/lz4_1.9.4.bb |   3 +-
>  meta/recipes-support/sqlite/sqlite3_3.41.2.bb |   7 -
>  48 files changed, 403 insertions(+), 373 deletions(-)
>  create mode 100644 meta/conf/cve-check-map.conf
> 


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

Re: [OE-core] [PATCH v3] qemu: Add qemu-common package

[Richard Purdie]

On Wed, 2023-07-19 at 17:39 +0800, Yu, Mingli wrote:
> On 7/19/23 17:24, Richard Purdie wrote:
> > > 
> > > It is relevant, this is because of the dependency that this gets built
> > > and fails. I've seen v4 but didn't have the time to test it yet.
> > 
> > I've still not seen an answer to Ross' question or mine about why we
> > can't just add a couple of dependencies and resolve things that way.
> 
> Sorry for delayed respond!
> 
> Have added qemu-common to make qemu as meta package to keep backward 
> compatibility. For user who install qemu rpm such as 
> qemu-7.2.0-r0.corei7_64.rpm, it still pull in all of things as before. 
> For user who cares the rpm size, can just choose to install the needed 
> qemu arch rpms such as qemu-system-aarch64-7.2.0-r0.corei7_64.rpm.

So why not just add:

RRECOMMENDS:${PN} += "${PN}-system-all ${PN}-user-all"

as I think we've then covered all the options we need?

Cheers,

Richard

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

Re: [OE-core] [PATCH v3] qemu: Add qemu-common package

[Yu, Mingli]

Hi Richard and Ross,

On 7/19/23 17:24, Richard Purdie wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Wed, 2023-07-19 at 11:20 +0200, Alexandre Belloni via
lists.openembedded.org wrote:

On 19/07/2023 17:10:37+0800, Yu, Mingli wrote:

Hi Alex,

On 7/17/23 20:46, Alexandre Belloni wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On 17/07/2023 15:10:35+0800, Yu, Mingli wrote:

Hi Alex,

On 7/16/23 19:47, Alexandre Belloni wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hello,

This causes the following meta-mingw error on the AB:

https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio


I didn't find the core-image-mingw-sdktest recipe which I noticed in the
above log, so I cannot reproduce the issue as you mentioned.


As stated above, this is part of meta-mingw:

https://git.yoctoproject.org/meta-mingw/tree/recipes-core/images?h=master-next


Thanks for your pointer!

BTW, the below error which in 
https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio
seems irrelevant to the added nativesdk dependency though I have removed the
nativesdk dependency in 
https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/.


/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:

../obj_s/lib_kernel.o:lib_kernel.c:(.text+0x5c): undefined reference to
`_nc_mingw_tcflush'

/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:

../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0x2c): undefined reference to
`_nc_mingw_tcgetattr'

/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:

../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0xbb): undefined reference to
`_nc_mingw_tcsetattr'



It is relevant, this is because of the dependency that this gets built
and fails. I've seen v4 but didn't have the time to test it yet.


I've still not seen an answer to Ross' question or mine about why we
can't just add a couple of dependencies and resolve things that way.


Sorry for delayed respond!

Have added qemu-common to make qemu as meta package to keep backward 
compatibility. For user who install qemu rpm such as 
qemu-7.2.0-r0.corei7_64.rpm, it still pull in all of things as before. 
For user who cares the rpm size, can just choose to install the needed 
qemu arch rpms such as qemu-system-aarch64-7.2.0-r0.corei7_64.rpm.


Thanks,



Cheers,

Richard

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

Re: [OE-core] [PATCH v3] qemu: Add qemu-common package

[Richard Purdie]

On Wed, 2023-07-19 at 11:20 +0200, Alexandre Belloni via
lists.openembedded.org wrote:
> On 19/07/2023 17:10:37+0800, Yu, Mingli wrote:
> > Hi Alex,
> > 
> > On 7/17/23 20:46, Alexandre Belloni wrote:
> > > CAUTION: This email comes from a non Wind River email account!
> > > Do not click links or open attachments unless you recognize the sender 
> > > and know the content is safe.
> > > 
> > > On 17/07/2023 15:10:35+0800, Yu, Mingli wrote:
> > > > Hi Alex,
> > > > 
> > > > On 7/16/23 19:47, Alexandre Belloni wrote:
> > > > > CAUTION: This email comes from a non Wind River email account!
> > > > > Do not click links or open attachments unless you recognize the 
> > > > > sender and know the content is safe.
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > This causes the following meta-mingw error on the AB:
> > > > > 
> > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio
> > > > 
> > > > I didn't find the core-image-mingw-sdktest recipe which I noticed in the
> > > > above log, so I cannot reproduce the issue as you mentioned.
> > > 
> > > As stated above, this is part of meta-mingw:
> > > 
> > > https://git.yoctoproject.org/meta-mingw/tree/recipes-core/images?h=master-next
> > 
> > Thanks for your pointer!
> > 
> > BTW, the below error which in 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio
> > seems irrelevant to the added nativesdk dependency though I have removed the
> > nativesdk dependency in 
> > https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/.
> > 
> > > /home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:
> > ../obj_s/lib_kernel.o:lib_kernel.c:(.text+0x5c): undefined reference to
> > `_nc_mingw_tcflush'
> > > /home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:
> > ../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0x2c): undefined reference to
> > `_nc_mingw_tcgetattr'
> > > /home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:
> > ../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0xbb): undefined reference to
> > `_nc_mingw_tcsetattr'
> > 
> 
> It is relevant, this is because of the dependency that this gets built
> and fails. I've seen v4 but didn't have the time to test it yet.

I've still not seen an answer to Ross' question or mine about why we
can't just add a couple of dependencies and resolve things that way.

Cheers,

Richard

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

Re: [OE-core] [PATCH v3] qemu: Add qemu-common package

[Alexandre Belloni via lists.openembedded.org]

On 19/07/2023 17:10:37+0800, Yu, Mingli wrote:
> Hi Alex,
> 
> On 7/17/23 20:46, Alexandre Belloni wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and 
> > know the content is safe.
> > 
> > On 17/07/2023 15:10:35+0800, Yu, Mingli wrote:
> > > Hi Alex,
> > > 
> > > On 7/16/23 19:47, Alexandre Belloni wrote:
> > > > CAUTION: This email comes from a non Wind River email account!
> > > > Do not click links or open attachments unless you recognize the sender 
> > > > and know the content is safe.
> > > > 
> > > > Hello,
> > > > 
> > > > This causes the following meta-mingw error on the AB:
> > > > 
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio
> > > 
> > > I didn't find the core-image-mingw-sdktest recipe which I noticed in the
> > > above log, so I cannot reproduce the issue as you mentioned.
> > 
> > As stated above, this is part of meta-mingw:
> > 
> > https://git.yoctoproject.org/meta-mingw/tree/recipes-core/images?h=master-next
> 
> Thanks for your pointer!
> 
> BTW, the below error which in 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio
> seems irrelevant to the added nativesdk dependency though I have removed the
> nativesdk dependency in 
> https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/.
> 
> | 
> /home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:
> ../obj_s/lib_kernel.o:lib_kernel.c:(.text+0x5c): undefined reference to
> `_nc_mingw_tcflush'
> | 
> /home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:
> ../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0x2c): undefined reference to
> `_nc_mingw_tcgetattr'
> | 
> /home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld:
> ../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0xbb): undefined reference to
> `_nc_mingw_tcsetattr'
> 

It is relevant, this is because of the dependency that this gets built
and fails. I've seen v4 but didn't have the time to test it yet.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [OE-core] [PATCH v3] qemu: Add qemu-common package

[Yu, Mingli]

Hi Alex,

On 7/17/23 20:46, Alexandre Belloni wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On 17/07/2023 15:10:35+0800, Yu, Mingli wrote:

Hi Alex,

On 7/16/23 19:47, Alexandre Belloni wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

Hello,

This causes the following meta-mingw error on the AB:

https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio


I didn't find the core-image-mingw-sdktest recipe which I noticed in the
above log, so I cannot reproduce the issue as you mentioned.


As stated above, this is part of meta-mingw:

https://git.yoctoproject.org/meta-mingw/tree/recipes-core/images?h=master-next


Thanks for your pointer!

BTW, the below error which in 
https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/7501/steps/12/logs/stdio 
seems irrelevant to the added nativesdk dependency though I have removed 
the nativesdk dependency in 
https://patchwork.yoctoproject.org/project/oe-core/patch/20230717071114.2734859-1-mingli...@eng.windriver.com/.


| 
/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld: 
../obj_s/lib_kernel.o:lib_kernel.c:(.text+0x5c): undefined reference to 
`_nc_mingw_tcflush'
| 
/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld: 
../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0x2c): undefined reference 
to `_nc_mingw_tcgetattr'
| 
/home/pokybuild/yocto-worker/meta-mingw/build/build/tmp/work/i686-nativesdk-mingw32-w64-mingw32/nativesdk-ncurses/6.4-r0/recipe-sysroot-native/usr/bin/i686-w64-mingw32/../../libexec/i686-w64-mingw32/gcc/i686-w64-mingw32/13.1.1/ld: 
../obj_s/lib_ttyflags.o:lib_ttyflags.c:(.text+0xbb): undefined reference 
to `_nc_mingw_tcsetattr'


Thanks,





Thanks,



This is due to the added native-sdk dependency.

On 10/07/2023 18:32:18+0800, Yu, Mingli wrote:

From: Mingli Yu 

We split the qemu package [1] to add support to make user can install
one qemu arch emulation rpm to ease the concerns who care much about
the rpm size in embedded device.

But for the user who only install the qemu-*.rpm can't do anything
except they install the qemu emulation rpm like qemu-system-x86-64-*.rpm
explicitly.

So add qemu-common package to package all thing into qemu-common when
not split the package, and package only the basic into qemu-common and
other arch related to each qemu arch emulation rpm when split the package
to fix the backward compatibility.

qenu-*.rpm which is meta package rdepends on qemu-common and the available
qemu arch emulation rpm like qemu-system-x86-64-*.rpm and etc.

[1] 
https://git.openembedded.org/openembedded-core/commit/?id=893846ead7ee54d53e9076150cd655e0c8bca5db

Signed-off-by: Mingli Yu 
---
   meta/recipes-devtools/qemu/qemu.inc  | 23 ---
   meta/recipes-devtools/qemu/qemu_8.0.0.bb |  3 ++-
   2 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index a5bdeef66d..94624163d0 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -226,15 +226,18 @@ PACKAGECONFIG[brlapi] = "--enable-brlapi,--disable-brlapi"
   PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack,"
   PACKAGECONFIG[debuginfo] = "--enable-libdw,--disable-libdw,elfutils"

-INSANE_SKIP:${PN} = "arch"
+INSANE_SKIP:${PN}-common = "arch"

   FILES:${PN} += "${datadir}/icons"

   # For user who want to install all arch packages
-PACKAGES =+ "${PN}-system-all ${PN}-user-all"
+PACKAGES =+ "${PN}-common"
+RDEPENDS:${PN} += "${PN}-common"

-ALLOW_EMPTY:${PN}-system-all = "1"
-ALLOW_EMPTY:${PN}-user-all = "1"
+ALLOW_EMPTY:${PN} = "1"
+FILES:${PN} = ""
+
+FILES:${PN}-common = "${bindir}/* ${includedir}/* ${libexecdir}/* ${datadir}/* 
${localstatedir}"

   PACKAGES_DYNAMIC += "^${PN}-user-.*  ^${PN}-system-.*"

@@ -242,15 +245,13 @@ PACKAGESPLITFUNCS =+ "split_qemu_packages"

   python split_qemu_packages () {
   archdir = d.expand('${bindir}/')
-syspackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$', 
'${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True)
-if syspackages:
-d.setVar('RDEPENDS:' + d.getVar('PN') + '-system-all', ' 
'.join(syspackages))
+subpackages = do_split_packages(d, archdir, r'^qemu-system-(.*)$', 
'${PN}-system-%s', 'QEMU full system emulation binaries(%s)' , prepend=True, 
extra_depends='${PN}-common')

-

Re: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro native features support

[Richard Purdie]

On Wed, 2023-07-19 at 07:53 +, 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 (#184569): 
https://lists.openembedded.org/g/openembedded-core/message/184569
Mute This Topic: https://lists.openembedded.org/mt/100231396/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro native features support

[Piotr Łobacz]

Hi Alexandre,
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.

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.

BR
Piotr


Od: Alexandre Belloni 
Wysłane: Tuesday, July 18, 2023 11:05:15 PM
Do: Piotr Łobacz 
DW: Alex Stewart ; 
openembedded-core@lists.openembedded.org 

Temat: Re: ODP: [OE-Core][PATCH v5 1/5] bitbake.conf: add acl and xattr distro 
native features support

On 18/07/2023 08:05:12+, Piotr Łobacz wrote:
> Alexander, this message:
>
> > Alex,
> > from what I'm seeing the issue touches opkg-build command:
> >
> > opkg-build -Z xz -a "--memlimit=5% --threads=8" "" "" 
> > nativesdk-xcb-proto-dbg 
> > /home/pokybuild/yocto-worker/genericx86-64/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-xcb-proto/1.15.2-r0/deploy-ipks/i686-nativesdk'
> >  returned non-zero exit status 1.
> >
> > which causes you an error. This may happen with bad tar hosttools command. 
> > Can you please post me which version is on yocto autobuilder?
>
> > BR
> > Piotr
>
> was meant for you, sorry for the confusion. Can you please verify/check what 
> version of `tar` is being used on the autobuilder? This is really important 
> for me, if we're going to move forward with it, because I have suspicions 
> that it may not support posix or it may not be patched with --acls and 
> --xattrs attributes 
> https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fbug-tar%40gnu.org%2Fmsg06198.html=05%7C01%7Cp.lobacz%40welotec.com%7Cc1ceda9eea4c4969c45408db87d2b6a1%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638253111303120469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=a2OBzWVj%2B2hsqeRdq3s2S9F59GX002Swf%2FyYlO%2B7bZg%3D=0
>

This fails at least on:

fedora38-ty-4: tar (GNU tar) 1.34, has --acls and --xattrs
stream8-ty-1: tar (GNU tar) 1.30, has --acls and --xattrs
rocky9-ty-1: tar (GNU tar) 1.34, has --acls and --xattrs
debian12-ty-1: tar (GNU tar) 1.34, has --acls and --xattrs
ubuntu2204-ty-3: tar (GNU tar) 1.34, has --acls and --xattrs
ubuntu2004-arm-1: tar (GNU tar) 1.30, has --acls and --xattrs
opensuse154-ty-3: tar (GNU tar) 1.34, has --acls and --xattrs
alma9-ty-1: tar (GNU tar) 1.34, has --acls and --xattrs
ubuntu2210-ty-1: tar (GNU tar) 1.34, has --acls and --xattrs
ubuntu2004-ty-1: tar (GNU tar) 1.30, has --acls and --xattrs

Really, the question is more on which host this is working.


--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbootlin.com%2F=05%7C01%7Cp.lobacz%40welotec.com%7Cc1ceda9eea4c4969c45408db87d2b6a1%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638253111303120469%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=yO%2BFc0BrkTVuC4MNNDuNVErK81guyI0J%2FNxkFT6P1so%3D=0

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

Re: [OE-core] systemd service@ bug

[Vyacheslav Yurkov]

Hey,
Usually Steve Sakoman cherry-picks patches from master. If it's not the 
case, it was probably not applied clearly or simply overlooked. You can 
submit a backport with the branch tag.


Vyacheslav

On 19.07.2023 03:48, Yuta Hayama wrote:

Hi,

This issue has been fixed in master.
https://git.openembedded.org/openembedded-core/commit/?id=d18b939fb08b37380ce95934da38e6522392621c

But, yes. This patch has not yet been backported to the any stable branch.


I don't know about the maintenance process for the stable branch, but I
expect that patch will probably be queued and backported to dunfell in
a month or so.

Please let me know if anyone knows anything about this. Should we simply
wait? Or do I have to submit a backport request?


Regards,

Yuta Hayama



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