From: Priyal Doshi
Signed-off-by: Priyal Doshi
---
meta/recipes-extended/timezone/timezone.inc | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-extended/timezone/timezone.inc
b/meta/recipes-extended/timezone/timezone.inc
index 75f13cf..46bc1b7 100644
---
On 2/21/24 9:06 AM, Paul Barker wrote:
On 21/02/2024 10:57, Ross Burton wrote:
From: Ross Burton
This is a new 64-bit "generic" Arm machine, that expects the hardware to
be SystemReady IR compatible. This is slightly forward-leaning as there's
not a _lot_ of SystemReady hardware in the
Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:
---
Testing patch
/home/patchtest/share/mboxes/v3-1-3-image.bbclass-rootfs-archive-and-deploy-package-database.patch
FAIL: test max line length: Patch line too
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
systemd-sysext can load a raw-image containing usr/ and opt/ folders
to mount them as RO overlay over the rootfs, to "extend" the systems.
This class provides the necessary changes/additions to the enclosed
file-system so that systemd-sysext accepts the extension for "merge"
into the rootfs.
set the package-database of a "lower image" to unpack and build upon
when installing packages for the current image. This way a lean image
will be created, which only holds the packages that are not already
present in the lower image.
An image build such could then be used with overlayfs or
systemd-sysext allows to overlay another image (or multiple) ontop of
a "base-image" = the current rootfs, via the use of overlayfs; to add
tools and features meant for development purposes.
To quote the documentation on systemd-sysext:
" ...addition in order to make debugging/development
archive the package database after the rootfs has been put together as
*rootfs-pkdbfs.tar.gz, and put it into the deploy folder.
This creates a snapshot of the package mangers state at the point in
time when all dependencies have been resolved and installed; which
could be used by "extension
On 2024-02-21 5:08 a.m., Alexander Kanavin via lists.openembedded.org wrote:
On Wed, 21 Feb 2024 at 10:48, Ross Burton wrote:
You _can_ export TMPDIR but that has to be done on a per-recipe/class basis
very carefully as TMPDIR means something else to Bitbake.
The problem is recipes that use
From: Adrian Freihofer
All the regexes throw a warning like this:
WARNING: scripts/lib/recipetool/create_buildsys.py:140:
SyntaxWarning: invalid escape sequence '\s'
proj_re = re.compile('project\s*\(([^)]*)\)', re.IGNORECASE)
Python 3 interprets string literals as Unicode strings,
From: Adrian Freihofer
Python 3 interprets string literals as Unicode strings, and therefore
\s is treated as an escaped Unicode character which is not correct.
Declaring the RegEx pattern as a raw string instead of unicode is
required for Python 3.
Signed-off-by: Adrian Freihofer
From: Adrian Freihofer
Python 3 interprets string literals as Unicode strings, and therefore
\s is treated as an escaped Unicode character which is not correct.
Declaring the RegEx pattern as a raw string instead of unicode is
required for Python 3.
Signed-off-by: Adrian Freihofer
From: Adrian Freihofer
On hosts with git defaulting to main branch the following exception
occures:
File .../buildhistory.py", line 99, in test_compare_dict_blobs_default
blob1 = self.repo.heads.master.commit.tree.blobs[0]
^^
File
From: Adrian Freihofer
Python 3 interprets string literals as Unicode strings, and therefore
\s is treated as an escaped Unicode character which is not correct.
Declaring the RegEx pattern as a raw string instead of unicode is
required for Python 3.
Signed-off-by: Adrian Freihofer
Latest recipetool from master branch generates a pyhton3-meson.bb recipe
while the older version from kirkstone generates a meson.bb. Change the
test to pass with meson.bb.
Signed-off-by: Adrian Freihofer
---
meta/lib/oeqa/selftest/cases/recipetool.py | 4 ++--
1 file changed, 2 insertions(+),
From: Adrian Freihofer
test_recipetool_create_github and test_recipetool_create_github_tarball
fail because the old meson version used by these tests cases does not
run on Python 3.12. The issue is in the dependencies.py which comes with
meson:
ERROR:
From: Ross Burton
recipetool's pyproject.toml parsing needs tomllib (python 3.11+) or
tomli (not a hard dependency), so is prone to failing depending on the
host configuration.
Downgrade the Meson release used for the checks to 0.52.1, which was the
last release before moving to pyproject.toml.
From: Adrian Freihofer
assertEquals is deprecated since Python 2.7:
https://docs.python.org/2/library/unittest.html#deprecated-aliases
It throws errors at least on Python 3.12. Replace it by assertEqual.
Signed-off-by: Adrian Freihofer
Signed-off-by: Richard Purdie
Backported from master:
From: Ross Burton
SafeConfigParser was renamed to ConfigParser in 3.2, and the
SafeConfigParser alias will be removed in 3.12.
Signed-off-by: Ross Burton
Signed-off-by: Alexandre Belloni
Cherry-picked from master: 71b3e7f71727137b4b996cc4160c9cc1581824b8
Signed-off-by: Adrian Freihofer
---
From: Ross Burton
Add support for qmp sockets and defaults to unix:qmp.sock if unspecified
Signed-off-by: Ross Burton
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin
Signed-off-by: Richard Purdie
Backported from master: 380631797f0d63124a8c21efa93ab672dbd79283
Qemu throws many warnings without
From: Trevor Gamblin
When invoking runqemu with Python 3.12, the following warning is
encountered:
|SyntaxWarning: invalid escape sequence '\.'
This is because the interpreter scans the string before it is processed
by the regex module, and it interprets the backslash as part of an
escape
From: Chris Laplante
'imp' was deprecated in Python 3.4 and removed in 3.12. The
piece of importlib we use has been around since 3.3.
Signed-off-by: Chris Laplante
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
Cherry-picked from master:
Changes in comparison to v2:
Fix oe-selftest errors
- https://errors.yoctoproject.org/Errors/Details/753468/
- https://errors.yoctoproject.org/Errors/Details/753470/
by adding one more commit: "oeqa/selftest/recipetool: expect meson.bb"
oe-selftest -a
Required tests failed (successes=502,
From: Paul Gortmaker
[[RFC PATCH] Add genericarm64 MACHINE using upstream defconfig] On 21/02/2024
(Wed 10:57) ross.bur...@arm.com wrote:
> From: Ross Burton
>
> This is a new 64-bit "generic" Arm machine, that expects the hardware to
> be SystemReady IR compatible. This is slightly
This patch remained after bumping from 6.1 to 6.6
Signed-off-by: Khem Raj
---
...cpumap-Make-counter-as-unsigned-ints.patch | 69 ---
1 file changed, 69 deletions(-)
delete mode 100644
meta/recipes-kernel/linux/files/0001-perf-cpumap-Make-counter-as-unsigned-ints.patch
diff
On Wed, 2024-02-21 at 08:15 -0800, Anton Antonov wrote:
> On Wed, Feb 21, 2024 at 03:21 AM, Richard Purdie wrote:
> > I think it comes down to whether the fragments are usable and
> > testable.
> > We have a list of targets we want this new machine to run on so
> > lets
> > start with those,
On Wed, Feb 21, 2024 at 03:21 AM, Richard Purdie wrote:
>
> I think it comes down to whether the fragments are usable and testable.
> We have a list of targets we want this new machine to run on so lets
> start with those, define genericarm64 as that set of fragments combined
> plus the generic
On 21/02/2024 10:57, Ross Burton wrote:
> From: Ross Burton
>
> This is a new 64-bit "generic" Arm machine, that expects the hardware to
> be SystemReady IR compatible. This is slightly forward-leaning as there's
> not a _lot_ of SystemReady hardware in the wild, but most modern boards
> are and
On 21/02/2024 15:12, Enguerrand de Ribaucourt wrote:
On 20/02/2024 10:01, adrian.freiho...@gmail.com wrote:
On Mon, 2024-02-19 at 17:55 +0100, Enguerrand de Ribaucourt wrote:
When launching the debug configuration, the source files from the
debug
rootfs were openened in the editor instead
On 2/16/2024 7:51 AM, Andreas Helbech Kleist wrote:
On Fri, 2024-02-16 at 09:11 +0100, Andreas Helbech Kleist wrote:
On Thu, 2024-02-15 at 19:45 -0600, Ryan Eatmon via
lists.openembedded.org wrote:
On 2/15/2024 7:43 PM, Steve Sakoman wrote:
On Thu, Feb 15, 2024 at 3:20 PM Ryan Eatmon
On 2/16/2024 2:11 AM, Andreas Helbech Kleist wrote:
On Thu, 2024-02-15 at 19:45 -0600, Ryan Eatmon via
lists.openembedded.org wrote:
On 2/15/2024 7:43 PM, Steve Sakoman wrote:
On Thu, Feb 15, 2024 at 3:20 PM Ryan Eatmon wrote:
With this patch in place we are seeing a breakage on our
On 20/02/2024 10:01, adrian.freiho...@gmail.com wrote:
On Mon, 2024-02-19 at 17:55 +0100, Enguerrand de Ribaucourt wrote:
When launching the debug configuration, the source files from the
debug
rootfs were openened in the editor instead of the local workspace
files.
We add an exception to
Hi,
On Wed, Feb 21, 2024 at 03:23:48PM +0200, Mikko Rapeli via
lists.openembedded.org wrote:
> FWIW, we have been using upstream kernel.org aarch64 defconfig plus
> few board specific fragments and few extra features for our testing needs.
> I have been very happy that several major kernel
I should add that if just doing this for qemu is acceptable, I can take
over the task of creating the configuration fragments with what remains
for the week.
Are the MACHINE configs and everything else I need already in OE-core
or available somewhere that I can find ?
Bruce
On Wed, Feb 21, 2024
I'm quite simply a hard NACK on this.
Everyone can feel free to overrule me here, but I won't be able to
maintain this along with the other board that I test each -dev,
variant and -stable bump with.
There are tools, etc, that while gathering dust can help chop up a
config, and that's where we
Hi,
On Wed, Feb 21, 2024 at 11:21:39AM +, Richard Purdie wrote:
> On Wed, 2024-02-21 at 10:57 +, Ross Burton wrote:
> > From: Ross Burton
> >
> > This is a new 64-bit "generic" Arm machine, that expects the hardware to
> > be SystemReady IR compatible. This is slightly forward-leaning
The rust testsuite was redirecting command output to a file, which made it
hard to debug failure cases since the logs were not available to print to
the console.
Rework the code so it uses the existing popen logging and hence allows us
to improve the error logging situation and make debugging
On Wed, 2024-02-21 at 13:30 +0530, Yash Shinde wrote:
>
> The runCmd() returns the 'Result' object containing information about the
> command execution. It has the following attributes:
> result.command = command
> result.status = cmd.status
> result.output = cmd.output
>
On Wed, 2024-02-21 at 10:57 +, Ross Burton wrote:
> From: Ross Burton
>
> This is a new 64-bit "generic" Arm machine, that expects the hardware to
> be SystemReady IR compatible. This is slightly forward-leaning as there's
> not a _lot_ of SystemReady hardware in the wild, but most modern
Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:
---
Testing patch
/home/patchtest/share/mboxes/RFC-Add-genericarm64-MACHINE-using-upstream-defconfig.patch
FAIL: test Signed-off-by presence: Mbox is missing
From: Ross Burton
This is a new 64-bit "generic" Arm machine, that expects the hardware to
be SystemReady IR compatible. This is slightly forward-leaning as there's
not a _lot_ of SystemReady hardware in the wild, but most modern boards
are and the number will only grow. Also, this is the only
On Wed, 21 Feb 2024 at 10:48, Ross Burton wrote:
> You _can_ export TMPDIR but that has to be done on a per-recipe/class basis
> very carefully as TMPDIR means something else to Bitbake.
>
> The problem is recipes that use mktemp to write files and execute them (be it
> shell scripts, or as a
On 21 Feb 2024, at 07:18, ChenQi wrote:
> I just noticed the change. I can't find the V2 in my mailbox, so I'm going to
> reply here.
> I'm a little concerned about forcing such requirement here. It does not seem
> *necessary*.
> As far as I know, the whole oe-core does not need /tmp to be
On 13-02-2024 23:42, Randy MacLeod wrote:
On 2024-02-13 8:04 a.m., yash.shi...@windriver.com wrote:
From: Yash Shinde
The rust oe-selftest output error log doesn't show any information on console
when it fails.
The following changes emit stderr logs in terminal along with re-directing stdout
44 matches
Mail list logo
