On Tue, 2024-04-23 at 21:58 +0530, Vivek Kumbhar via
lists.openembedded.org wrote:
> Upstream-Status: Backport
> https://github.com/rpm-software-management/rpm/commit/96ec957e281220f8e137a2d5eb23b83a6377d556
>
>
Okay, Will correct and send V2.
Thanks,
Vivek
On Fri, Apr 26, 2024 at 1:29 AM Steve Sakoman wrote:
> This patch caused multiple build failures both locally and on the
> autobuilder.
>
> Here is a link to the autobuilder run:
>
>
Hi Michael,
At least at a first read and without running it, this does look like a
reasonable direction. I suspect that anyone else looking at this would
have a lot of questions about why we'd do it this way but given the
various constraints, it does make sense to me.
What we do need to think
This patch caused multiple build failures both locally and on the autobuilder.
Here is a link to the autobuilder run:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6845
Sample error log:
https://errors.yoctoproject.org/Errors/Details/763370/
Steve
On Tue, Apr 23, 2024 at
Hi Ross,
Here is the background of this:
Initially we found this issue, when we are trying to build the Arm FVP for
openbmc, as you can see from the discussion here:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/70070/comment/4a963c24_75b11840/
So thanks to the kind help from Patrick Williams
Hi Ross,
Thank you for your quick response!
That makes sense now.
Regarding your statement:
"That dependency in btrfs-tools might be actually not required, or you
might want to make the recipe depend on python3-native."
May I know if something has to be fixed from the meta-openembedded or
generic
On 25 Apr 2024, at 13:29, Sheng Lean Tan via lists.openembedded.org
wrote:
>
> Hi,
> Good day to openembedded community!
>
> This is my first post - hope this is the right place to ask for help
> regarding a build issue, as refer from here:
>
From: Michael Opdenacker
New oe-selftest and associated "testimage" test to check that generated
package feeds can be used to update the latest image built
by the Yocto Project autobuilder.
Currently, only the "core-image-full-cmdline" image with IPK packages
and the "poky-altcfg" distro is
I did compare a build with this patch in it with the 5.0 rc4 test
report:
http://autobuilder.yocto.io/pub/non-release/20240424-25/testresults/testresult-report.txt
vs
http://autobuilder.yocto.io/pub/releases/yocto-5.0.rc4/testreport.txt
which shows:
gcc | 149932
Hi,
Good day to openembedded community!
This is my first post - hope this is the right place to ask for help
regarding a build issue, as refer from here:
https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017/comment/195b742f_6cf8da09/
Currently, we saw this issue when building this on openBMC
Hi Harish,
On Thu, 2024-04-18 at 03:50 -0700, Sadineni, Harish via
lists.openembedded.org wrote:
> From: Harish Sadineni
>
> while runnig oe-selftest for gcc, testcases that need to be run on
> qemu are not running due to below failures.
> - Executing on ssh: mkdir -p /tmp/runtest.3549641
Hello,
This patch doesn't apply on master anymore because ninja has been updated.
On 04/04/2024 13:16:11+0200, Martin Hundeb?ll wrote:
> Ninja doesn't (yet) support the GNU Make jobserver out of the box, but
> there is a pull request adding that support[1]. Since that pull request
> (and its
Hi
thanks you for the tips. I had to tell the fetcher to unpack into ${S} too:
>
> SRC_URI = "file://Makefile;subdir=${S} \
> file://mymodule_core.c;subdir=${S} \
> file://mymodule.h;subdir=${S} \
> file://mymodule_public.h;subdir=${S} \
> file://mymodule_remote_public.h;subdir=${S} \
> "
>
>
If DROPBEAR_RSAKEY_DIR has already been set before, e.g. by overwriting
the file dropbear.default, the line will still be appended a second time.
DROPBEAR_RSAKEY_DIR="/path/to/dropbear"
DROPBEAR_EXTRA_ARGS="-B"
DROPBEAR_RSAKEY_DIR=/var/lib/dropbear
(Backport of rev:
This causes the following failures:
https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4702/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/106/builds/7874/steps/11/logs/stdio
On 22/04/2024 09:39:21-0500, Joseph Mills wrote:
> Signed-off-by: Joseph
On Thu, 25 Apr 2024 at 07:52, leimaohui via lists.openembedded.org
wrote:
> - After oe_multilib_header on cdefs.h, the path of cdefs-64.h and cdefs-32.h
> in cdefs.h need to be corrected. Please reference to
> https://man.archlinux.org/man/libbsd.7 for details.
I looked at this in a local
16 matches
Mail list logo