From: Yann Dirson
This currently catches the .clb_blob and .vamrs,rock960.txt, and other
.txt files may come in future upstream releases.
Signed-off-by: Yann Dirson
---
meta/recipes-kernel/linux-firmware/linux-firmware_20210315.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions
Le mer. 31 mars 2021 à 14:41, Bruce Ashfield
a écrit :
>
> On Wed, Mar 31, 2021 at 6:23 AM Yann Dirson
> wrote:
> >
> > Le mar. 30 mars 2021 à 20:41, Yann Dirson via lists.openembedded.org
> > a écrit :
> > >
> > > Hi Bruce,
> > >
>
Le mar. 30 mars 2021 à 20:41, Yann Dirson via lists.openembedded.org
a écrit :
>
> Hi Bruce,
>
> Le mar. 30 mars 2021 à 19:47, Bruce Ashfield
> a écrit :
> >
> > On Tue, Mar 30, 2021 at 1:27 PM Yann Dirson
> > wrote:
> > >
> > > From: Yann D
From: Yann Dirson
Signed-off-by: Yann Dirson
---
meta/classes/kernel-yocto.bbclass | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/classes/kernel-yocto.bbclass
b/meta/classes/kernel-yocto.bbclass
index c6228ad0b8..1ca7ef738f 100644
--- a/meta/classes/kernel
Hi Bruce,
Le mar. 30 mars 2021 à 19:47, Bruce Ashfield
a écrit :
>
> On Tue, Mar 30, 2021 at 1:27 PM Yann Dirson
> wrote:
> >
> > From: Yann Dirson
> >
> > This is not quite enough for the lack of a BSP to stand out clearly to
> > an unsuspecting use
From: Yann Dirson
This is not quite enough for the lack of a BSP to stand out clearly to
an unsuspecting user's eyes, but at least this line in the logs should
help some of us to get a clue:
NOTE: Using kmeta BSP ''
Signed-off-by: Yann Dirson
---
meta/classes/kernel-yo
Le jeu. 25 mars 2021 à 14:44, Yann Dirson via lists.openembedded.org
a écrit :
>
> Hi Alex,
>
> Le mar. 23 mars 2021 à 17:42, Alexander Kanavin
> a écrit :
> >
> > Is it possible to further split the NONCOMMERCIAL_PACKAGECONFIGS into ones
> > that are enabled an
> its better to exclude them from world build in such cases
>
> Signed-off-by: Khem Raj
> Cc: Yann Dirson
> ---
> meta/recipes-multimedia/gstreamer/gst-examples_1.18.4.bb | 2 ++
> meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.18.4.bb | 3 +++
> 2 files changed
" flag, so I'm tempted to not add a
duplicate flag in
ffmpeg (in the same spirit as my patches against gst-libav and mpv).
Would it be
good enough ?
>
>
> Alex
>
> On Tue, 23 Mar 2021 at 17:38, Yann Dirson wrote:
>>
>> From: Yann Dirson
>>
>> The ra
in PACKAGECONFIG itself?
> >
> > Alex
> >
> > On Tue, 23 Mar 2021 at 17:38, Yann Dirson
> > wrote:
> >
> > > From: Yann Dirson
> > >
> > > The rationale here is that if the user can only whitelist "commercial"
> > &
From: Yann Dirson
This flag does not describe the gst-libav package, but ffmpeg instead.
It gets in the way of using finer-grained LICENSE_FLAGS in ffmpeg.
It is above all not needed, the real problem is even more clear without it:
ffmpeg was skipped: because it has a restricted license
From: Yann Dirson
The rationale here is that if the user can only whitelist "commercial"
to use any part of ffmpeg, even it the list of features is carefully
reviewed when switching the whitelisting on, there was nothing to
guard from inadvertently activating a new feature that woul
From: Yann Dirson
--disable-gpl is the upstream default, and using GPL features violates
the license when linking into non-GPL programs.
Enabling it by default breaks user expectations, may cause people to
violate the GPL by mistake.
Signed-off-by: Yann Dirson
---
meta/recipes-multimedia
enable-video-opengl,--disable-video-opengl,virtual/libgl"
> > PACKAGECONFIG[pulseaudio] =
> "--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
> > -PACKAGECONFIG[tslib] =
> "--enable-input-tslib,--disable-input-tslib,tslib"
> > PACKAGECONFI
libsdl upstream
with a patch
restoring the tslib support ? Maybe we could even carry such a patch in
yocto until
upstream does something ? That could be better than just carying an old
version.
> Cheers,
> Mark
>
> On Mon, Feb 1, 2021 at 11:23 AM Yann Dirson
> wrote:
> >
From: Yann Dirson
This version does not support tslib any more, as can be seen by the
failed AUH run.
Originally-by: Romain Roffé
Signed-off-by: Yann Dirson
---
.../libsdl2/directfb-renderfillrect-fix.patch | 33 -
...ectfb-spurious-curly-brace-missing-e.patch | 49
ink about as a
"compiler", would that fit ?
We could then move those files into ${PN}-compiler and leave ${PN} as a
virtual package pulling
-runtime and -compiler.
Does this look correct ?
Le mar. 17 nov. 2020 à 10:24, Richard Purdie <
richard.pur...@linuxfoundation.org>
From: Yann Dirson
This works like:
- yarn-v1-mkbbinc script generates a $PACKAGE.inc bitbake snippet containing
* SRC_URI additions for all dependencies
* YARNLOCK_CHECKSUM for consistency checking
- $PACKAGE.bb uses "require $PACKAGE.inc"
Supports only:
- *.tgz from npm regi
From: Yann Dirson
distutils3-base.bbclass unconditionally adds python3-core to RDEPENDS_${PN},
yuck.
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel
Hi,
Le mar. 17 nov. 2020 à 05:35, Victor Kamensky
a écrit :
> Hi Yann and Richard,
>
> On Fri, Nov 13, 2020 at 5:59 AM Yann Dirson
> wrote:
> >
> > Oh I did not notice, shouldn't we be discussing this on-list ?
>
> Very sorry about this. I did not notice that
From: Yann Dirson
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 89f550c859..74bf7cb35c 100644
--- a/meta/recipes
From: Yann Dirson
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 375e570454..89f550c859 100644
--- a/meta/recipes
From: Yann Dirson
Most of the RDEPENDS part of PACKAGECONFIG[translator] appears to be related to
examples only.
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes
From: Yann Dirson
Note the _class-target qualifier, here to prevent a funky dependency of
systemtap-native on systemtap-native-runtime-native. This possibly hints
to something deeper ?
---
meta/lib/oeqa/selftest/cases/runtime_test.py | 2 +-
meta/recipes-kernel/systemtap/systemtap_git.bb | 9
From: Yann Dirson
The goal of this series is to make it possible to run compiled
systemtap probes on the target without all the tools otherwise
necessary to compile them.
This series also includes unrelated fixes to the systemtap packaging,
on which I stumbled while on the main subject
From: Yann Dirson
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 17 +
1 file changed, 17 insertions(+)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 1c9f2aed16..e98aff1851 100644
--- a/meta/recipes
Le mar. 22 sept. 2020 à 02:41, Bruce Ashfield a
écrit :
> On Mon, Sep 21, 2020 at 6:51 PM Richard Purdie
> wrote:
> >
> > On Mon, 2020-09-21 at 23:23 +0200, Yann Dirson wrote:
> > >
> > >
> > > Le lun. 21 sept. 2020 à 21:46, Richard Purdie <
&
From: Yann Dirson
Newer llvm versions have changed the logic for finding libraries,
which prevents Mesa from building with PACKAGECONFIG[gallium-llvm]:
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=13937
This patch comes from meta-amd, which exhibits one such situation.
Signed-off-by
Le lun. 21 sept. 2020 à 21:46, Richard Purdie <
richard.pur...@linuxfoundation.org> a écrit :
> On Mon, 2020-09-21 at 16:15 +0200, Yann Dirson wrote:
> > From: Yann Dirson
> >
> > ---
> > meta/classes/systemtap.bbclass| 74 +++
From: Yann Dirson
Cross-building a systemtap module requires access to debug information.
---
meta/classes/kernel.bbclass | 4
1 file changed, 4 insertions(+)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 48135b3d41..fd2355bb68 100644
--- a/meta/classes
From: Yann Dirson
The goal of this series is to allow for packages to provide systemtap
probes and get them cross-compiled on the host, shipping only the
minimal runtime in the filesystem.
People willing to build the probes on target can continue to do so
with no changes for some many users
From: Yann Dirson
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 375e570454..89f550c859 100644
--- a/meta/recipes
From: Yann Dirson
Note the _class-target qualifier, here to prevent a funky dependency of
systemtap-native on systemtap-native-runtime-native. This possibly hints
to something deeper ?
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 9 +
1 file changed, 9 insertions(+)
diff --git
From: Yann Dirson
---
meta/classes/systemtap.bbclass| 74 +++
.../systemtap/systemtap-demo_git.bb | 71 ++
2 files changed, 145 insertions(+)
create mode 100644 meta/classes/systemtap.bbclass
create mode 100644 meta/recipes-kernel
From: Yann Dirson
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 89f550c859..74bf7cb35c 100644
--- a/meta/recipes
From: Yann Dirson
Upstream looks for unversionned System.map file in kernel_build_tree,
and if this fails goes for versionned filename in $sysroot/boot/.
OTOH we have a versionned filename in kernel_build_tree.
---
.../systemtap/systemtap-native_git.bb | 6 +
.../systemtap/system
From: Yann Dirson
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 17 +
1 file changed, 17 insertions(+)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes-kernel/systemtap/systemtap_git.bb
index 1c9f2aed16..e98aff1851 100644
--- a/meta/recipes
From: Yann Dirson
Most of the RDEPENDS part of PACKAGECONFIG[translator] appears to be related to
examples only.
---
meta/recipes-kernel/systemtap/systemtap_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.bb
b/meta/recipes
Le ven. 5 juin 2020 à 21:28, Khem Raj a écrit :
>
>
> On 6/5/20 6:10 AM, Yann Dirson wrote:
> > I just got hit by the following dunfell build issue on my debian/testing
> > dev box:
> >
> > argp-fmtstream.c:(.text+0x4ca): undefined reference to `_IO_fwide&#x
Le ven. 5 juin 2020 à 15:11, Yann Dirson via lists.openembedded.org
a écrit :
> I just got hit by the following dunfell build issue on my debian/testing
> dev box:
>
My bad (too many build trees), it is a sumo build.
> argp-fmtstream.c:(.text+0x4ca): undefined reference t
igging I found https://patchwork.openembedded.org/series/20136
whose patch 4
addresses this very problem.
I could not find any discussion about those patches (it's hard to be sure
though, I found the
new mail archive quite impractical).
Are there any reasons why this 2019-09 series is still NEW
From: Yann Dirson
Packages with a runtime dependency on a target package whose name is
changed by the PKG_* mechanism must rebuild when that mapping changes,
but we have no way of tracking this today, so
eg. packagegroup-machine-base ends up with a relationship on a
versioned kernel-image, and
From: Yann Dirson
Packages with a runtime dependency on a target package whose name is
changed by the PKG_* mechanism must rebuild when that mapping changes,
but we have no way of tracking this today, so
eg. packagegroup-machine-base ends up with a relationship on a
versioned kernel-image, and
: make it
so curl-native uses its own certs and not the host ones.
commit fde6fcfaae0021d33e917cae81581dbfdb6618de
Author: Yann Dirson
Date: Mon Jun 24 18:18:06 2019 +0200
curl-native: use a wrapper script to locate cacert
diff --git a/meta-blade/recipes-support/curl/curl_%.bbappend
b/meta
_all_problem_rules(libsolv_solver, problem);
+ opkg_message(ERROR, "\n");
+
+ int solution_count =
solver_solution_count(libsolv_solver->solver,
--
Yann Dirson
Blade / Shadow -- http://shadow.tech
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
From: Yann Dirson
Signed-off-by: Yann Dirson
---
.../mesa/files/0003-Allow-enable-DRI-without-DRI-drivers.patch | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta/recipes-graphics/mesa/files/0003-Allow-enable-DRI-without-DRI-drivers.patch
b/meta/recipes-graphics/mesa
; > > What about using some less confusing default BLUEZ value?
> RDEPENDS_
> > > looks wrong.
> > >
> > > BLUEZ ??= "no-bluetooth"
> > > RDEPENDS_no-bluetooth = ""
> > >
> > >
x27; cause a problem. For all other
> recipes it will remain blank as expected.
>
I guess the problem is more when it is globally set to "", we would anyway
need to handle that
case in addition to our recipe-specific default.
> --Mark
>
> > On Wed, Oct 17, 2018 at 5:4
gt; RDEPENDS_${PN} = " \
> ${@bb.utils.contains('DISTRO_FEATURES', 'bluez5',
> '${BLUEZ5_INSTALL}', "", d)} \
> ${@bb.utils.contains('DISTRO_FEATURES', 'bluez4',
> '${BLUEZ4_INSTALL}', "", d)} \
> "
>
&
ork for cases where it might be used in e.g. RDEPENDS_${PN} :/. Maybe
> inline python appending only either bluez4 or bluez5 alternative here?
>
> On Wed, Oct 17, 2018 at 5:43 PM Yann Dirson
> wrote:
>
>> Yeah, that looks like a better idea.
>>
>> Le mer. 17 oct.
more clear.
>
> On Wed, Oct 17, 2018 at 5:08 PM wrote:
>
>> From: Yann Dirson
>>
>> Otherwise the build fails with:
>>
>> NOTE: Runtime target '${RDEPENDS_}' is unbuildable, removing...
>> Missing or unbuildable dependency chain was: [&#x
From: Yann Dirson
Otherwise the build fails with:
NOTE: Runtime target '${RDEPENDS_}' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['${RDEPENDS_}']
This restores some truth in the "Otherwise install nothing" comment in the
recip
52 matches
Mail list logo
