[OE-core] [PATCH] libusb1: Set CVE_PRODUCT
From: Ricardo Simoes
This commit sets the CVE_PRODUCT variable to "libusb" to match the
product name used in the NIST CPE database [1].
[1]: https://nvd.nist.gov/products/cpe/search
Signed-off-by: Ricardo Simoes
Signed-off-by: Mark Jonas
---
meta/recipes-support/libusb/libusb1_1.0.27.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/libusb/libusb1_1.0.27.bb
b/meta/recipes-support/libusb/libusb1_1.0.27.bb
index f2431d75c8..5bf854f95d 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.27.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.27.bb
@@ -8,6 +8,8 @@ SECTION = "libs"
LICENSE = "LGPL-2.1-or-later"
LIC_FILES_CHKSUM = "file://COPYING;md5=fbc093901857fcd118f065f900982c24"
+CVE_PRODUCT = "libusb"
+
BBCLASSEXTEND = "native nativesdk"
SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/libusb-${PV}.tar.bz2 \
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199438):
https://lists.openembedded.org/g/openembedded-core/message/199438
Mute This Topic: https://lists.openembedded.org/mt/106129930/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 2/2] linux-yocto: Autoload sound driver on QEMU x86
Hi Richard and Bruce,
On Fri, Jan 6, 2023 at 12:27 PM Richard Purdie
wrote:
>
> On Fri, 2023-01-06 at 11:13 +0100, Mark Jonas wrote:
> > Hi Bruce,
> >
> > On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield
> > wrote:
> > >
> > > On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas wrote:
> > > >
> > > > Hi Bruce,
> > > >
> > > > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield
> > > > wrote:
> > > > >
> > > > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas wrote:
> > > > > >
> > > > > > From: Mark Jonas
> > > > > >
> > > > > > If DISTRO_FEATURES includes ALSA then automatically load the
> > > > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches
> > > > > > the
> > > > > > machine configurations conf/machine/qemux86.conf and
> > > > > > qemux86-64.conf.
> > > > > >
> > > > > > Signed-off-by: Mark Jonas
> > > > > > ---
> > > > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +
> > > > > > 1 file changed, 5 insertions(+)
> > > > > >
> > > > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> > > > > > b/meta/recipes-kernel/linux/linux-yocto.inc
> > > > > > index 091003ed82..c8a9b0a1e3 100644
> > > > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc
> > > > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> > > > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = "
> > > > > > ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
> > > > > > KERNEL_FEATURES:append = "
> > > > > > ${@bb.utils.contains('MACHINE_FEATURES', 'numa',
> > > > > > 'features/numa/numa.scc', '', d)}"
> > > > > > KERNEL_FEATURES:append = "
> > > > > > ${@bb.utils.contains('MACHINE_FEATURES', 'vfat', 'cfg/fs/vfat.scc',
> > > > > > '', d)}"
> > > > > >
> > > > > > +# sound driver recommended by conf/machine/qemux86*.conf
> > > > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa",
> > > > > > "snd-intel8x0", "", d)}"
> > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}"
> > > > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}"
> > > > >
> > > > > This gets us most of the way, but if we are going to do this we should
> > > > > complete the job.
> > > > >
> > > > > We really need to make sure there's a configuration fragment that
> > > > > explicitly enables
> > > > > the modules we need (and not count on defaults, or other selects).
> > > > > That would go
> > > > > into the kernel-cache.
> > > > >
> > > > > It would then be something we'd add to the KERNEL_FEATRES triggered
> > > > > off the
> > > > > distro feature. Just like we are doing with numa and vfat that is
> > > > > visible in the
> > > > > context of the patch.
> > > >
> > > > In my understanding this is already the case. See for example
> > > > linux-yocto_5.19.bb which contains the following lines.
> > > >
> > > > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> > > > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
> > > >
> > > > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD
> > > > into the same file where the corresponding configuration fragment is
> > > > added? But that would mean to duplicate the lines over five recipes.
> > > >
> > > > Alternatively I could move the cfg/sound.scc out of the recipes into
> > > > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also
> > > > get it.
> > >
> > > I definitely wasn't clear. Sorry about that, I'm still partially on
> > > holidays and didn't have enough coffee when I wrote that.
> > >
> > > That is close to what I meant. It is one thing to define the options
> > > in our generic sound "buckets" and another to put a specific module
> > > into the autoload.
> > >
> &
Re: [OE-core] [PATCH 2/2] linux-yocto: Autoload sound driver on QEMU x86
Hi Bruce,
On Thu, Jan 5, 2023 at 3:57 PM Bruce Ashfield wrote:
>
> On Thu, Jan 5, 2023 at 8:42 AM Mark Jonas wrote:
> >
> > Hi Bruce,
> >
> > On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield
> > wrote:
> > >
> > > On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas wrote:
> > > >
> > > > From: Mark Jonas
> > > >
> > > > If DISTRO_FEATURES includes ALSA then automatically load the
> > > > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the
> > > > machine configurations conf/machine/qemux86.conf and qemux86-64.conf.
> > > >
> > > > Signed-off-by: Mark Jonas
> > > > ---
> > > > meta/recipes-kernel/linux/linux-yocto.inc | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> > > > b/meta/recipes-kernel/linux/linux-yocto.inc
> > > > index 091003ed82..c8a9b0a1e3 100644
> > > > --- a/meta/recipes-kernel/linux/linux-yocto.inc
> > > > +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> > > > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = "
> > > > ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
> > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES',
> > > > 'numa', 'features/numa/numa.scc', '', d)}"
> > > > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES',
> > > > 'vfat', 'cfg/fs/vfat.scc', '', d)}"
> > > >
> > > > +# sound driver recommended by conf/machine/qemux86*.conf
> > > > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa",
> > > > "snd-intel8x0", "", d)}"
> > > > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}"
> > > > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}"
> > >
> > > This gets us most of the way, but if we are going to do this we should
> > > complete the job.
> > >
> > > We really need to make sure there's a configuration fragment that
> > > explicitly enables
> > > the modules we need (and not count on defaults, or other selects). That
> > > would go
> > > into the kernel-cache.
> > >
> > > It would then be something we'd add to the KERNEL_FEATRES triggered off
> > > the
> > > distro feature. Just like we are doing with numa and vfat that is visible
> > > in the
> > > context of the patch.
> >
> > In my understanding this is already the case. See for example
> > linux-yocto_5.19.bb which contains the following lines.
> >
> > KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
> > KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
> >
> > Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD
> > into the same file where the corresponding configuration fragment is
> > added? But that would mean to duplicate the lines over five recipes.
> >
> > Alternatively I could move the cfg/sound.scc out of the recipes into
> > the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also
> > get it.
>
> I definitely wasn't clear. Sorry about that, I'm still partially on
> holidays and didn't have enough coffee when I wrote that.
>
> That is close to what I meant. It is one thing to define the options
> in our generic sound "buckets" and another to put a specific module
> into the autoload.
>
> If we are going to autoload a module, the option really should be
> pulled out of the generic bucket, and put into something smaller /
> specific to what we are trying to do, and trigger the inclusion of
> that fragment only when the appropriate distro feature is set. The
> machine conf files specifying specific modules isn't ideal, since it
> is largely "aspirational" unless it is coupled with a KERNEL_FEATURE
> that is set based on a machine or distro feature.
I have to admit that I feel a bit lost. I am not really sure I
understood what you meant.
Is the "generic bucket" cfg/sound.scc? But why should we break that
up? A module only ends up in an image if the module is installed. And
the installation is controlled e.g. by MACHINE_EXTRA_RRECOMMENDS in
the machine file.
> If you search the mailing list archives, you'll see me musing about
> how I need to change those unconditional appends of option to qemu, as
> it makes defining a new qemu machine problematic (if the options are
> caus
Re: [OE-core] [PATCH 0/2] Load proper sound drivers for QEMU x86
Hi Richard, On Wed, Jan 4, 2023 at 6:42 PM Richard Purdie wrote: > > On Wed, 2023-01-04 at 13:18 +0100, toer...@gmail.com wrote: > > From: Mark Jonas > > > > The patch series fixes a regression where images built for QEMU x86 and > > x86-64 did not contain sound drivers matching the QEMU device emulation > > configuration. Additionally, the right drivers are now also auto-loaded > > when starting the image. > > > > root@qemux86:~# uname -a > > Linux qemux86 5.19.17-yocto-standard #1 SMP PREEMPT_DYNAMIC Fri Nov 18 > > 21:13:18 UTC 2022 i686 GNU/Linux > > > > root@qemux86:~# lsmod > > Module Size Used by > > bnep 20480 2 > > snd_intel8x0 32768 0 > > snd_ac97_codec114688 1 snd_intel8x0 > > ac97_bus 16384 1 snd_ac97_codec > > snd_pcm86016 2 snd_ac97_codec,snd_intel8x0 > > snd_timer 28672 1 snd_pcm > > snd57344 4 > > snd_ac97_codec,snd_timer,snd_intel8x0,snd_pcm > > soundcore 16384 1 snd > > > > root@qemux86:~# cat /proc/asound/cards > > 0 [I82801AAICH]: ICH - Intel 82801AA-ICH > > Intel 82801AA-ICH with STAC9700,83,84 at irq 10 > > > > Mark Jonas (2): > > conf/machine: Match QEMU x86 sound kernel module > > linux-yocto: Autoload sound driver on QEMU x86 > > > > meta/conf/machine/qemux86-64.conf | 3 ++- > > meta/conf/machine/qemux86.conf| 3 ++- > > meta/recipes-kernel/linux/linux-yocto.inc | 5 + > > 3 files changed, 9 insertions(+), 2 deletions(-) > > These look good, I'm happy to see the patches, thanks! > > As Bruce mentions, a kernel config fragment would be a nice added bonus > to ensure the right config options stay around or error if they're > changed upstream. Quick summary of what I replied to Bruce: The linux-yocto*.bb recipes (except for the tiny) already use a cfg/sound.scc to enable building of sound driver modules. > One thing I've learnt is that the best way to ensure these kinds of > things stay "fixed" once we fix them is to tweak our automated testing > to check them. > > I'm wondering if there is something we could/should add to: > > "bitbake core-image-sato -c testimage" > > to check for the presence of a /proc/asound/cards entry for example? > > The idea here is that now it is working, we'd try and ensure it stays > working! Sounds reasonable. I haven't used automated tests for OE yet so it might take me some time to dig into it. Cheers, Mark -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175545): https://lists.openembedded.org/g/openembedded-core/message/175545 Mute This Topic: https://lists.openembedded.org/mt/96048823/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 2/2] linux-yocto: Autoload sound driver on QEMU x86
Hi Bruce,
On Wed, Jan 4, 2023 at 5:07 PM Bruce Ashfield wrote:
>
> On Wed, Jan 4, 2023 at 7:18 AM Mark Jonas wrote:
> >
> > From: Mark Jonas
> >
> > If DISTRO_FEATURES includes ALSA then automatically load the
> > snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the
> > machine configurations conf/machine/qemux86.conf and qemux86-64.conf.
> >
> > Signed-off-by: Mark Jonas
> > ---
> > meta/recipes-kernel/linux/linux-yocto.inc | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> > b/meta/recipes-kernel/linux/linux-yocto.inc
> > index 091003ed82..c8a9b0a1e3 100644
> > --- a/meta/recipes-kernel/linux/linux-yocto.inc
> > +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> > @@ -37,6 +37,11 @@ KERNEL_FEATURES:append = "
> > ${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
> > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES',
> > 'numa', 'features/numa/numa.scc', '', d)}"
> > KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES',
> > 'vfat', 'cfg/fs/vfat.scc', '', d)}"
> >
> > +# sound driver recommended by conf/machine/qemux86*.conf
> > +ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa",
> > "snd-intel8x0", "", d)}"
> > +KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}"
> > +KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}"
>
> This gets us most of the way, but if we are going to do this we should
> complete the job.
>
> We really need to make sure there's a configuration fragment that
> explicitly enables
> the modules we need (and not count on defaults, or other selects). That would
> go
> into the kernel-cache.
>
> It would then be something we'd add to the KERNEL_FEATRES triggered off the
> distro feature. Just like we are doing with numa and vfat that is visible in
> the
> context of the patch.
In my understanding this is already the case. See for example
linux-yocto_5.19.bb which contains the following lines.
KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
Does that maybe mean I should better add the KERNEL_MODULE_AUTOLOAD
into the same file where the corresponding configuration fragment is
added? But that would mean to duplicate the lines over five recipes.
Alternatively I could move the cfg/sound.scc out of the recipes into
the linux-yocto.inc. But then linux-yocto-tiny_*.bb recipes would also
get it.
Cheers,
Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175526):
https://lists.openembedded.org/g/openembedded-core/message/175526
Mute This Topic: https://lists.openembedded.org/mt/96048827/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 2/2] linux-yocto: Autoload sound driver on QEMU x86
From: Mark Jonas
If DISTRO_FEATURES includes ALSA then automatically load the
snd-intel8x0 kernel module on qemux86 and qemux86-64. This matches the
machine configurations conf/machine/qemux86.conf and qemux86-64.conf.
Signed-off-by: Mark Jonas
---
meta/recipes-kernel/linux/linux-yocto.inc | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
b/meta/recipes-kernel/linux/linux-yocto.inc
index 091003ed82..c8a9b0a1e3 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -37,6 +37,11 @@ KERNEL_FEATURES:append = "
${@bb.utils.contains('MACHINE_FEATURES', 'efi', 'cfg/
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa',
'features/numa/numa.scc', '', d)}"
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat',
'cfg/fs/vfat.scc', '', d)}"
+# sound driver recommended by conf/machine/qemux86*.conf
+ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa",
"snd-intel8x0", "", d)}"
+KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}"
+KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}"
+
# A KMACHINE is the mapping of a yocto $MACHINE to what is built
# by the kernel. This is typically the branch that should be built,
# and it can be specific to the machine or shared
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175471):
https://lists.openembedded.org/g/openembedded-core/message/175471
Mute This Topic: https://lists.openembedded.org/mt/96048827/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 1/2] conf/machine: Match QEMU x86 sound kernel module
From: Mark Jonas In "conf/machine: fix QEMU x86 sound options" b802a5dd the sound devices emulated by QEMU were changed from AC97 (intel8x0) and ES1370 (Soundblaster) to just AC97. Yet, the sound kernel modules added to the file system still matched ES1370. This patch adds the matching snd-intel8x0 kernel module for the emulated AC97 sound card. It removes the unused ES1370 kernel modules. Signed-off-by: Mark Jonas --- meta/conf/machine/qemux86-64.conf | 3 ++- meta/conf/machine/qemux86.conf| 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/conf/machine/qemux86-64.conf b/meta/conf/machine/qemux86-64.conf index 8640867911..e249397d06 100644 --- a/meta/conf/machine/qemux86-64.conf +++ b/meta/conf/machine/qemux86-64.conf @@ -36,7 +36,8 @@ MACHINE_FEATURES += "x86 pci" MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d" -MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370 kernel-module-snd-rawmidi" +# matches QEMU -device AC97 +MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-intel8x0" WKS_FILE ?= "qemux86-directdisk.wks" do_image_wic[depends] += "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot" diff --git a/meta/conf/machine/qemux86.conf b/meta/conf/machine/qemux86.conf index 1e072e1ae2..d61c7816dd 100644 --- a/meta/conf/machine/qemux86.conf +++ b/meta/conf/machine/qemux86.conf @@ -33,7 +33,8 @@ MACHINE_FEATURES += "x86 pci" MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "v86d" -MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370 kernel-module-snd-rawmidi" +# matches QEMU -device AC97 +MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-intel8x0" WKS_FILE ?= "qemux86-directdisk.wks" do_image_wic[depends] += "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175470): https://lists.openembedded.org/g/openembedded-core/message/175470 Mute This Topic: https://lists.openembedded.org/mt/96048826/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 0/2] Load proper sound drivers for QEMU x86
From: Mark Jonas The patch series fixes a regression where images built for QEMU x86 and x86-64 did not contain sound drivers matching the QEMU device emulation configuration. Additionally, the right drivers are now also auto-loaded when starting the image. root@qemux86:~# uname -a Linux qemux86 5.19.17-yocto-standard #1 SMP PREEMPT_DYNAMIC Fri Nov 18 21:13:18 UTC 2022 i686 GNU/Linux root@qemux86:~# lsmod Module Size Used by bnep 20480 2 snd_intel8x0 32768 0 snd_ac97_codec114688 1 snd_intel8x0 ac97_bus 16384 1 snd_ac97_codec snd_pcm86016 2 snd_ac97_codec,snd_intel8x0 snd_timer 28672 1 snd_pcm snd57344 4 snd_ac97_codec,snd_timer,snd_intel8x0,snd_pcm soundcore 16384 1 snd root@qemux86:~# cat /proc/asound/cards 0 [I82801AAICH]: ICH - Intel 82801AA-ICH Intel 82801AA-ICH with STAC9700,83,84 at irq 10 Mark Jonas (2): conf/machine: Match QEMU x86 sound kernel module linux-yocto: Autoload sound driver on QEMU x86 meta/conf/machine/qemux86-64.conf | 3 ++- meta/conf/machine/qemux86.conf| 3 ++- meta/recipes-kernel/linux/linux-yocto.inc | 5 + 3 files changed, 9 insertions(+), 2 deletions(-) -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175469): https://lists.openembedded.org/g/openembedded-core/message/175469 Mute This Topic: https://lists.openembedded.org/mt/96048823/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] Struggling to get QEMU sound working on core-image-base
Hi,
> I have difficulties getting core-image-base and QEMU x86-64 sound
> output working. I do not even get to the point of having a visible
> ALSA sound device.
>
> What part of the puzzle am I missing?
>
> Alternatively, can someone point me to a (simple) YP image where sound
> works with QEMU x86 or x86-64?
>
> I built a core-image-base image from latest YP Poky [dunfell,langdale]
> with the following additions in a default local.conf:
>
> MACHINE = "qemux86-64"
>
> # Load kernel modules matching QEMU audio support
> KERNEL_MODULE_AUTOLOAD += "snd-ens1370"
>
> # Check ALSA cards available
> IMAGE_INSTALL:append = " alsa-utils"
>
> EXTRA_IMAGE_FEATURES += "debug-tweaks"
I was able to solve part of the riddle. Now I am wondering whether I
hit a bug in the meta/conf/machine/qemux86*.conf files.
The conf/machine/qemux86*.conf recommends the installation of the
snd-ens1370 module.
(since
https://git.openembedded.org/openembedded-core/commit/?id=112775995158cf6c504fd6beef345ee446f4f11d)
MACHINE_EXTRA_RRECOMMENDS = "kernel-module-snd-ens1370
kernel-module-snd-rawmidi"
Thus, I assumed that (as suggested by
https://docs.yoctoproject.org/dev-manual/qemu.html) QEMU would create
an ENS1370 device.
- ``audio``: Enables audio in QEMU. The MACHINE option must be either
"qemux86" or "qemux86-64" in order for audio to be enabled.
Additionally, the ``snd_intel8x0`` or ``snd_ens1370`` driver must be
installed in linux guest.
Actually, the sound device in the virtual machine is an Intel 8x0 type.
root@qemux86-64:~# lspci
[..]
00:04.0 Multimedia audio controller: Intel Corporation 82801AA AC'97
Audio Controller (rev 01)
[..]
After installing the snd-intel8x0 module into the image and adding it
to the auto-loaded modules, I can finally see an ALSA card.
IMAGE_INSTALL:append = " kernel-module-snd-intel8x0"
KERNEL_MODULE_AUTOLOAD += "snd-ens1370 snd-intel8x0"
(see https://gitlab.com/toertel/meta-qemusound)
root@qemux86-64:~# cat /proc/asound/cards
0 [I82801AAICH]: ICH - Intel 82801AA-ICH
Intel 82801AA-ICH with STAC9700,83,84 at irq 20
Then, isn't it a bug in the meta/conf/machine/qemux86*.conf files that
(only?) the kernel-module-snd-ens1370 is recommended? Shouldn't the
kernel-module-snd-intel8x0 be recommended (additionally?)?
Staying in line with the Poky QEMU documentation I offer to send a
patch which adds kernel-module-snd-intel8x0 to
MACHINE_EXTRA_RRECOMMENDS of the meta/conf/machine/qemux86*.conf files.
Shouldn't then also linux-yocto.inc be amended such that the
KERNEL_MODULE_AUTOLOAD is set in case it is a qemux86* kernel and the
DISTRO_FEATURES contain alsa?
ALSA_MODULES = "${@bb.utils.contains("DISTRO_FEATURES", "alsa", "
snd-ens1370 snd-intel8x0", "", d)}"
KERNEL_MODULE_AUTOLOAD:qemux86 += "${ALSA_MODULES}"
KERNEL_MODULE_AUTOLOAD:qemux86-64 += "${ALSA_MODULES}"
Cheers,
Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175345):
https://lists.openembedded.org/g/openembedded-core/message/175345
Mute This Topic: https://lists.openembedded.org/mt/96009159/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Struggling to get QEMU sound working on core-image-base
Hi, I have difficulties getting core-image-base and QEMU x86-64 sound output working. I do not even get to the point of having a visible ALSA sound device. What part of the puzzle am I missing? Alternatively, can someone point me to a (simple) YP image where sound works with QEMU x86 or x86-64? I built a core-image-base image from latest YP Poky [dunfell,langdale] with the following additions in a default local.conf: MACHINE = "qemux86-64" # Load kernel modules matching QEMU audio support KERNEL_MODULE_AUTOLOAD += "snd-ens1370" # Check ALSA cards available IMAGE_INSTALL:append = " alsa-utils" EXTRA_IMAGE_FEATURES += "debug-tweaks" Then I start the core-image-base with "runqemu core-image-base kvm serial slirp audio nographic". In the running system I can see that the kernel modules are loaded. root@qemux86-64:~# uname -a Linux qemux86-64 5.19.17-yocto-standard #1 SMP PREEMPT_DYNAMIC Fri Nov 18 21:13:18 UTC 2022 x86_64 GNU/Linux root@qemux86-64:~# lsmod Module Size Used by bnep 20480 2 snd_ens137028672 0 snd_pcm 102400 1 snd_ens1370 snd_timer 32768 1 snd_pcm snd_rawmidi28672 1 snd_ens1370 snd_seq_device 16384 1 snd_rawmidi snd73728 5 snd_seq_device,snd_timer,snd_ens1370,snd_pcm,snd_rawmidi soundcore 16384 1 snd But the /proc/asound/cards is empty and aplay does not find soundcards as well. root@qemux86-64:~# cat /proc/asound/cards --- no soundcards --- root@qemux86-64:~# aplay -l aplay: device_list:275: no soundcards found... For easy reproduction of the problem I created a KAS yaml file. You can find it at https://gitlab.com/toertel/meta-qemusound Thanks in advance, Mark -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#175318): https://lists.openembedded.org/g/openembedded-core/message/175318 Mute This Topic: https://lists.openembedded.org/mt/96009159/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] just want to confirm my understanding of how systemd services get symlinks
Hi Robert,
On Mon, Oct 4, 2021 at 8:02 PM Robert P. J. Day wrote:
>
>
> just had a discussion with a colleague about the proper design of a
> systemd-based service, and my (admittedly sophomore) understanding is
> that, in the service file, there is an [Install] section, which
> contains a "WantedBy" line like:
>
> fubar.service:WantedBy=sysinit.target
>
> upon installation in the image, from systemd.bbclass. the routine
> systemd_postinst() is invoked which (among other things), does this:
>
> if [ "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
> for service in ${SYSTEMD_SERVICE_ESCAPED}; do
> systemctl ${OPTS} enable "$service"
> done
> fi
>
> and my understanding is that it is that call to "systemctl" that
> creates the appropriate symlink so that that service now exists under
> the directory "sysinit.target.wants".
>
> my need for confirmation is based on muh collegaue's pointing at
> some existing systemd-based recipes in some legacy code, which
> manually do the following in do_install_append():
>
> ln -s ${sysconfdir}/systemd/system/fubar.service \
> ${D}/${sysconfdir}/systemd/system/sysinit.target.wants/
>
> i'm pretty sure that that "ln" command is unnecessary as long as the
> service file is defined properly, but now i just want to get that
> confirmed.
>
> rday
>
> p.s. hmm ... i wonder if the original recipe designer was unaware
> of systemd.bbclass and thought he had to do it all manually.
Correct, use an install section and systemd.bbclass and you do not
need to manually link into e.g. sysinit.target.wants. Do not forget to
set SYSTEMD_SERVICE, though.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-classes-systemd
I think using the systemd.bbclass is more robust than the manual link.
Additionally, users of your recipe can use SYSTEMD_AUTO_ENABLE to
disable automatic start of the service during boot.
Cheers,
Mark
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#157041):
https://lists.openembedded.org/g/openembedded-core/message/157041
Mute This Topic: https://lists.openembedded.org/mt/86073990/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] Request to backport KERNEL_DTC_FLAGS to Dunfell
Hi Bruce and Steve, > Von: Bruce Ashfield > On Fri, Jun 4, 2021 at 11:09 AM Steve Sakoman wrote: > > > > On Fri, Jun 4, 2021 at 2:45 AM Jonas Mark (BT-FIR/ENG1-Grb) > > wrote: > > > > > > Hi, > > > > > > We are using DT overlays and have the need to pass the -@ parameter > > > in DTC_FLAGS to Linux' make. The patch > > > > > > "kernel-devicetree: Introduce KERNEL_DTC_FLAGS to pass dtc flags" [cut out web links messed up by Outlook] > > > makes that possible in a nice way. Would it be reasonable to request > backporting of this patch to Dunfell? > > > > This is sort of in the grey area between feature and bug fix. It does > > seem relatively safe, so I would consider taking the patch if there > > are no objections from the community. > > > > Added Bruce to the cc list to get his opinion. > > Good timing, I happened to notice this earlier and was thinking about it. > > While I also wouldn't call it a bug, I agree it is a small/standalone change > that > shouldn't break anything. > > A quick scan of the dunfell tested kernels shows unchanged Makefile handling > of > the option, so there's little risk there. > > I'd say that it would be fine for backport. Can I help with the backport in any way? My colleague Tingquan gave it a try and the patch from Hardknott applies cleanly on Dunfell. The documentation patch for Poky proposed by Quentin does not apply though. But it is just that ref-variables.rst was renamed to variables.rst. > > Bruce > > > > > > We were also wondering what could be an alternative approach for getting > this or a similar functionality. Patching a bbclass using a bbappend is not > possible, is it? > > > > No, there is no equivalent of bbappend for classes. > > > > Other solutions are possible, but taking this patch would be the > > cleanest solution to your problem. Let's see what others think before > > we go there :-) > > > > Steve Cheers, Mark -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#153024): https://lists.openembedded.org/g/openembedded-core/message/153024 Mute This Topic: https://lists.openembedded.org/mt/83307657/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Request to backport KERNEL_DTC_FLAGS to Dunfell
Hi, We are using DT overlays and have the need to pass the -@ parameter in DTC_FLAGS to Linux' make. The patch "kernel-devicetree: Introduce KERNEL_DTC_FLAGS to pass dtc flags" https://git.openembedded.org/openembedded-core/commit/?h=hardknott=063b5de86624a42b0aa784db6dddc7552a6dee7f makes that possible in a nice way. Would it be reasonable to request backporting of this patch to Dunfell? We were also wondering what could be an alternative approach for getting this or a similar functionality. Patching a bbclass using a bbappend is not possible, is it? Cheers, Mark Mark Jonas Building Technologies, Panel Software Fire (BT-FIR/ENG1-Grb) Bosch Sicherheitssysteme GmbH | Postfach 11 11 | 85626 Grasbrunn | GERMANY | www.boschsecurity.com Tel. +49 89 6290-1105 | Telefax +49 89 6290-281105 | mark.jo...@de.bosch.com Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart HRB 23118 Aufsichtsratsvorsitzender: Christian Fischer; Geschäftsführung: Thomas Quante, Andreas Bartz -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#152661): https://lists.openembedded.org/g/openembedded-core/message/152661 Mute This Topic: https://lists.openembedded.org/mt/83307657/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] libsdl2: upgrade to 2.0.14
Hi,
tslib support is often relevant for embedded projects with simple
(resistive) touch screens. Would it make sense to keep the 2.0.12
recipe and offer both in parallel?
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 ---
> .../{libsdl2_2.0.12.bb => libsdl2_2.0.14.bb} | 6 +--
> 3 files changed, 1 insertion(+), 87 deletions(-)
> delete mode 100644
> meta/recipes-graphics/libsdl2/libsdl2/directfb-renderfillrect-fix.patch
> delete mode 100644
> meta/recipes-graphics/libsdl2/libsdl2/directfb-spurious-curly-brace-missing-e.patch
> rename meta/recipes-graphics/libsdl2/{libsdl2_2.0.12.bb =>
> libsdl2_2.0.14.bb} (91%)
>
> diff --git
> a/meta/recipes-graphics/libsdl2/libsdl2/directfb-renderfillrect-fix.patch
> b/meta/recipes-graphics/libsdl2/libsdl2/directfb-renderfillrect-fix.patch
> deleted file mode 100644
> index 83d4f4b1ec..00
> --- a/meta/recipes-graphics/libsdl2/libsdl2/directfb-renderfillrect-fix.patch
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -# HG changeset patch
> -# User Sam Lantinga
> -# Date 1590793369 25200
> -# Node ID a90089f75990e8b07a1dcf931c5f8a580ae343bf
> -# Parent a9b4bd264f3cbedc4f3287b3ec6b32311370ba85
> -Fixed bug 5146 - SDL_RenderFillRect doesn't work in DirectFB
> -
> -Lacky
> -
> -It looks like refactoring of SDL2 internal API has broken SDL_RenderFillRect
> for DirectFB. In new version function SDL_RenderFillRect returns 0, but
> rectangle is not visible.
> -
> -Replacing "count" with "len" in the argument list for SDL_memcpy in
> DirectFB_QueueFillRects fixes problem.
> -
> ---
> -
> -The patch was imported from the libsdl Mercurial repository
> -(https://hg.libsdl.org/SDL) as of changeset id a90089f75990.
> -
> -Upstream-Status: Backport
> -
> -Signed-off-by: Mark Jonas
> -
> -diff -r a9b4bd264f3c -r a90089f75990 src/video/directfb/SDL_DirectFB_render.c
> a/src/video/directfb/SDL_DirectFB_render.c Thu May 21 00:06:09 2020 -0400
> -+++ b/src/video/directfb/SDL_DirectFB_render.c Fri May 29 16:02:49 2020 -0700
> -@@ -626,7 +626,7 @@
> - }
> -
> - cmd->data.draw.count = count;
> --SDL_memcpy(verts, rects, count);
> -+SDL_memcpy(verts, rects, len);
> - return 0;
> - }
> diff --git
> a/meta/recipes-graphics/libsdl2/libsdl2/directfb-spurious-curly-brace-missing-e.patch
>
> b/meta/recipes-graphics/libsdl2/libsdl2/directfb-spurious-curly-brace-missing-e.patch
> deleted file mode 100644
> index aa351a89ba..00
> ---
> a/meta/recipes-graphics/libsdl2/libsdl2/directfb-spurious-curly-brace-missing-e.patch
> +++ /dev/null
> @@ -1,49 +0,0 @@
> -# HG changeset patch
> -# User Fabrice Fontaine
> -# Date 1585069551 25200
> -# Node ID 769f800952179633ec6c3e6bc1bc1d40e401750a
> -# Parent 63387e8920f58f608288f247824ec5f4c286691f
> -src/video/directfb/SDL_DirectFB_render.c: fix build
> -Build with directfb is broken due to a spurious '}' and a missing 'E'
> -since version 2.0.12 and https://hg.libsdl.org/SDL/rev/2d5b5a5ccbfb:
> -
> -/home/buildroot/autobuild/run/instance-2/output-1/build/sdl2-2.0.12/src/video/directfb/SDL_DirectFB_render.c:
> In function 'SetBlendMode':
> -/home/buildroot/autobuild/run/instance-2/output-1/build/sdl2-2.0.12/src/video/directfb/SDL_DirectFB_render.c:202:9:
> error: case label not within a switch statement
> - 202 | case SDL_BLENDMODE_MUL:
> - | ^~~~
> -
> -/home/buildroot/autobuild/run/instance-2/output-1/build/sdl2-2.0.12/src/video/directfb/SDL_DirectFB_render.c:205:67:
> error: 'DSBF_DSTCOLOR' undeclared (first use in this function); did you mean
> 'DSBF_DESTCOLOR'?
> - 205 | SDL_DFB_CHECK(destsurf->SetSrcBlendFunction(destsurf,
> DSBF_DSTCOLOR));
> - |
> ^
> -
> -Fixes:
> - -
> http://autobuild.buildroot.org/results/83ccefee68c2800c0544e6f40fa8bc8ee6b67b77
> -
> -Signed-off-by: Fabrice Fontaine
> -
> ---
> -
> -The patch was imported from the libsdl Mercurial repository
> -(https://hg.libsdl.org/SDL) as of changeset id 769f80095217.
> -
> -Upstream-Status: Backport
> -
> -Signed-off-by: Mark Jonas
> -
> -
> -diff -r 63387e8920f5 -r 769f80095217 src/video/directfb/SDL_DirectFB_render.c
> a/src/video/directfb/SDL_DirectFB_render.c Mon Mar 23 14:10:25 2020 -0700
[OE-core] [PATCH] parted: Make readline dependency optional
Signed-off-by: Mark Jonas
---
meta/recipes-extended/parted/parted_3.3.bb | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-extended/parted/parted_3.3.bb
b/meta/recipes-extended/parted/parted_3.3.bb
index a1fd3ef07b..ce40c04ad4 100644
--- a/meta/recipes-extended/parted/parted_3.3.bb
+++ b/meta/recipes-extended/parted/parted_3.3.bb
@@ -3,7 +3,7 @@ HOMEPAGE = "http://www.gnu.org/software/parted/parted.html;
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=2f31b266d3440dd7ee50f92cf67d8e6c"
SECTION = "console/tools"
-DEPENDS = "ncurses readline util-linux virtual/libiconv"
+DEPENDS = "ncurses util-linux virtual/libiconv"
SRC_URI = "${GNU_MIRROR}/parted/parted-${PV}.tar.xz \
file://no_check.patch \
@@ -22,6 +22,9 @@ EXTRA_OECONF = "--disable-device-mapper"
inherit autotools pkgconfig gettext texinfo ptest
+PACKAGECONFIG ?= "readline"
+PACKAGECONFIG[readline] = "--with-readline,--without-readline,readline"
+
BBCLASSEXTEND = "native nativesdk"
do_compile_ptest() {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#145486):
https://lists.openembedded.org/g/openembedded-core/message/145486
Mute This Topic: https://lists.openembedded.org/mt/78908005/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 V2] libsdl2: Add directfb to PACKAGECONFIG rdepends
PACKAGECONFIG[directfb] already adds directfb to the build dependencies. But the automatically generated runtime dependencies do not add the directfb package to the runtime dependencies. Most likely this happens because libsdl2 does not link against directfb but uses dlopen() or similar. Thus, the runtime dependency to directfb needs to be declared explicitly. Signed-off-by: Mark Jonas --- Changes in v2: - Add directfb as a rdepends instead of a rrecommends. - Rework commit message. meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb index 2ef7d2e5ef..5fa99821c4 100644 --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb @@ -58,7 +58,7 @@ PACKAGECONFIG ??= " \ " PACKAGECONFIG[alsa] = "--enable-alsa --disable-alsatest,--disable-alsa,alsa-lib," PACKAGECONFIG[arm-neon] = "--enable-arm-neon,--disable-arm-neon" -PACKAGECONFIG[directfb] = "--enable-video-directfb,--disable-video-directfb,directfb" +PACKAGECONFIG[directfb] = "--enable-video-directfb,--disable-video-directfb,directfb,directfb" PACKAGECONFIG[gles2] = "--enable-video-opengles,--disable-video-opengles,virtual/libgles2" PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack" PACKAGECONFIG[kmsdrm] = "--enable-video-kmsdrm,--disable-video-kmsdrm,libdrm virtual/libgbm" -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144960): https://lists.openembedded.org/g/openembedded-core/message/144960 Mute This Topic: https://lists.openembedded.org/mt/78484943/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] libsdl2: Add directfb to PACKAGECONFIG rdepends
Hi Richard and Andre, On Tue, Nov 24, 2020 at 4:52 PM Richard Purdie wrote: > On Mon, 2020-11-23 at 11:54 -0800, Andre McCurdy wrote: > > On Mon, Nov 23, 2020 at 11:14 AM Mark Jonas > > wrote: > > > When building libsdl2 with PACKAGECONFIG[directfb] then directfb is > > > added to the DEPENDS. But the automatically generated runtime > > > dependencies do not add the directfb package to the runtime > > > dependencies. Most likely this happens because libsdl2 does not > > > link > > > against directfb but uses dlopen() or similar. Thus, the runtime > > > dependency to directfb needs to be declared explicitly. > > > > > > Here, a runtime recommendation is used to allow ignoring the > > > runtime > > > dependency using NO_RECOMMENDATIONS. > > > > Why would anyone want to ignore the runtime dependency? > > Agreed, that does seem strange. Whichever way this goes, the patch > shortlog needs to match the commit (it says rdepends right now). Thank you for the feedback. I'll send a V2 of the patch. Greetings, Mark -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144957): https://lists.openembedded.org/g/openembedded-core/message/144957 Mute This Topic: https://lists.openembedded.org/mt/78460941/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] libsdl2: Add directfb to PACKAGECONFIG rdepends
When building libsdl2 with PACKAGECONFIG[directfb] then directfb is added to the DEPENDS. But the automatically generated runtime dependencies do not add the directfb package to the runtime dependencies. Most likely this happens because libsdl2 does not link against directfb but uses dlopen() or similar. Thus, the runtime dependency to directfb needs to be declared explicitly. Here, a runtime recommendation is used to allow ignoring the runtime dependency using NO_RECOMMENDATIONS. Signed-off-by: Mark Jonas --- meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb index 2ef7d2e5ef..ae42db2610 100644 --- a/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb +++ b/meta/recipes-graphics/libsdl2/libsdl2_2.0.12.bb @@ -58,7 +58,7 @@ PACKAGECONFIG ??= " \ " PACKAGECONFIG[alsa] = "--enable-alsa --disable-alsatest,--disable-alsa,alsa-lib," PACKAGECONFIG[arm-neon] = "--enable-arm-neon,--disable-arm-neon" -PACKAGECONFIG[directfb] = "--enable-video-directfb,--disable-video-directfb,directfb" +PACKAGECONFIG[directfb] = "--enable-video-directfb,--disable-video-directfb,directfb,,directfb" PACKAGECONFIG[gles2] = "--enable-video-opengles,--disable-video-opengles,virtual/libgles2" PACKAGECONFIG[jack] = "--enable-jack,--disable-jack,jack" PACKAGECONFIG[kmsdrm] = "--enable-video-kmsdrm,--disable-video-kmsdrm,libdrm virtual/libgbm" -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#144938): https://lists.openembedded.org/g/openembedded-core/message/144938 Mute This Topic: https://lists.openembedded.org/mt/78460941/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] libbsd: Remove BSD-4-Clause from main package
libbsd contains a multitude of licenses. For (commercial) projects the
3rd clause of the BSD-4-Clause license can be problematic. But only a
few man pages use this license. This means that the main package
containing the binary library itself is not under BSD-4-Clause ruling.
Signed-off-by: Mark Jonas
---
meta/recipes-support/libbsd/libbsd_0.10.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/libbsd/libbsd_0.10.0.bb
b/meta/recipes-support/libbsd/libbsd_0.10.0.bb
index 3b9ac5a01f..5b32b9af41 100644
--- a/meta/recipes-support/libbsd/libbsd_0.10.0.bb
+++ b/meta/recipes-support/libbsd/libbsd_0.10.0.bb
@@ -27,7 +27,8 @@ HOMEPAGE = "https://libbsd.freedesktop.org/wiki/;
# License: ISC-Original
# License: public-domain
# License: public-domain-Colin-Plumb
-LICENSE = "BSD-4-Clause & ISC & PD"
+LICENSE = "BSD-3-Clause & BSD-4-Clause & ISC & PD"
+LICENSE_${PN} = "BSD-3-Clause & ISC & PD"
LIC_FILES_CHKSUM = "file://COPYING;md5=2120be0173469a06ed185b688e0e1ae0"
SECTION = "libs"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#144532):
https://lists.openembedded.org/g/openembedded-core/message/144532
Mute This Topic: https://lists.openembedded.org/mt/78214400/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 2/2] Map license names PSF and PSFv2 to PSF-2.0
According to SDPX.org "Python License 2.0" is the overall Python license, which is comprised of several licenses. "Python Software Foundation License 2.0" is part of the complete Python license, but is also used independently by some projects. So far the license names PSF and PSFv2 found in LICENSE are mapped to to Python-2.0. This patch maps PSF and PSFv2 to PSF-2.0 und thus corrects the impression that Python-2.0 and PSF-2.0 are synonymous. Signed-off-by: Mark Jonas --- meta/conf/licenses.conf | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf index 751424d1b6..5b309eb385 100644 --- a/meta/conf/licenses.conf +++ b/meta/conf/licenses.conf @@ -45,9 +45,11 @@ SPDXLICENSEMAP[MIT-style] = "MIT" #Openssl variations SPDXLICENSEMAP[openssl] = "OpenSSL" +#PSF variations +SPDXLICENSEMAP[PSF] = "PSF-2.0" +SPDXLICENSEMAP[PSFv2] = "PSF-2.0" + #Python variations -SPDXLICENSEMAP[PSF] = "Python-2.0" -SPDXLICENSEMAP[PSFv2] = "Python-2.0" SPDXLICENSEMAP[Python-2] = "Python-2.0" #Apache variations -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142911): https://lists.openembedded.org/g/openembedded-core/message/142911 Mute This Topic: https://lists.openembedded.org/mt/77202208/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 0/2] Map license names PSF and PSFv2 to PSF-2.0
According to SDPX.org "Python License 2.0" is the overall Python license, which is comprised of several licenses. "Python Software Foundation License 2.0" is part of the complete Python license, but is also used independently by some projects. So far the license names PSF and PSFv2 found in LICENSE are mapped to to Python-2.0. This patch maps PSF and PSFv2 to PSF-2.0 und thus corrects the impression that Python-2.0 and PSF-2.0 are synonymous. Mark Jonas (2): Add license text for PSF-2.0 Map license names PSF and PSFv2 to PSF-2.0 meta/conf/licenses.conf| 6 ++-- meta/files/common-licenses/PSF-2.0 | 49 ++ 2 files changed, 53 insertions(+), 2 deletions(-) create mode 100644 meta/files/common-licenses/PSF-2.0 -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#142909): https://lists.openembedded.org/g/openembedded-core/message/142909 Mute This Topic: https://lists.openembedded.org/mt/77202203/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 1/2] Add license text for PSF-2.0
Signed-off-by: Mark Jonas
---
meta/files/common-licenses/PSF-2.0 | 49 ++
1 file changed, 49 insertions(+)
create mode 100644 meta/files/common-licenses/PSF-2.0
diff --git a/meta/files/common-licenses/PSF-2.0
b/meta/files/common-licenses/PSF-2.0
new file mode 100644
index 00..4e673e93fc
--- /dev/null
+++ b/meta/files/common-licenses/PSF-2.0
@@ -0,0 +1,49 @@
+
+PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2
+
+
+1. This LICENSE AGREEMENT is between the Python Software Foundation
+("PSF"), and the Individual or Organization ("Licensee") accessing and
+otherwise using this software ("Python") in source or binary form and
+its associated documentation.
+
+2. Subject to the terms and conditions of this License Agreement, PSF
+hereby grants Licensee a nonexclusive, royalty-free, world-wide
+license to reproduce, analyze, test, perform and/or display publicly,
+prepare derivative works, distribute, and otherwise use Python
+alone or in any derivative version, provided, however, that PSF's
+License Agreement and PSF's notice of copyright, i.e., "Copyright (c)
+2001, 2002, 2003, 2004, 2005, 2006 Python Software Foundation; All Rights
+Reserved" are retained in Python alone or in any derivative version
+prepared by Licensee.
+
+3. In the event Licensee prepares a derivative work that is based on
+or incorporates Python or any part thereof, and wants to make
+the derivative work available to others as provided herein, then
+Licensee hereby agrees to include in any such work a brief summary of
+the changes made to Python.
+
+4. PSF is making Python available to Licensee on an "AS IS"
+basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR
+IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND
+DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS
+FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT
+INFRINGE ANY THIRD PARTY RIGHTS.
+
+5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON
+FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS
+A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON,
+OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
+
+6. This License Agreement will automatically terminate upon a material
+breach of its terms and conditions.
+
+7. Nothing in this License Agreement shall be deemed to create any
+relationship of agency, partnership, or joint venture between PSF and
+Licensee. This License Agreement does not grant permission to use PSF
+trademarks or trade name in a trademark sense to endorse or promote
+products or services of Licensee, or any third party.
+
+8. By copying, installing or otherwise using Python, Licensee
+agrees to be bound by the terms and conditions of this License
+Agreement.
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#142910):
https://lists.openembedded.org/g/openembedded-core/message/142910
Mute This Topic: https://lists.openembedded.org/mt/77202206/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [meta-oe][PATCH] directfb: fix tslib version check in configure.in
From: Guan Ben
The patch makes sure that the old as well as the new tslib pkg-config
metadata file naming style is handled correctly.
tslib 0.0 to 1.0 created only a tslib-.pc pkg-config metadata
file.
With tslib 1.1 the tslib-.pc phase out was started.
Additionally, the pkg-config metadata file tslib.pc was added.
Since tslib 1.6 the tslib-.pc metadata file is deprecated.
Now, there is only a tslib.pc.
Signed-off-by: Ben Guan
Signed-off-by: Mark Jonas
---
meta-oe/recipes-graphics/directfb/directfb.inc | 1 +
.../directfb/fix-tslib-version-version-check.patch | 20
2 files changed, 21 insertions(+)
create mode 100644
meta-oe/recipes-graphics/directfb/directfb/fix-tslib-version-version-check.patch
diff --git a/meta-oe/recipes-graphics/directfb/directfb.inc
b/meta-oe/recipes-graphics/directfb/directfb.inc
index bd66a28..af07ad7 100644
--- a/meta-oe/recipes-graphics/directfb/directfb.inc
+++ b/meta-oe/recipes-graphics/directfb/directfb.inc
@@ -20,6 +20,7 @@ SRC_URI =
"http://downloads.yoctoproject.org/mirror/sources/DirectFB-${PV}.tar.g
file://union-sigval.patch \
file://use-PTHREAD_MUTEX_RECURSIVE.patch \
file://fix-client-gfx_state-initialisation.patch \
+ file://fix-tslib-version-version-check.patch \
"
S = "${WORKDIR}/DirectFB-${PV}"
diff --git
a/meta-oe/recipes-graphics/directfb/directfb/fix-tslib-version-version-check.patch
b/meta-oe/recipes-graphics/directfb/directfb/fix-tslib-version-version-check.patch
new file mode 100644
index 000..b30db11
--- /dev/null
+++
b/meta-oe/recipes-graphics/directfb/directfb/fix-tslib-version-version-check.patch
@@ -0,0 +1,20 @@
+diff -Nru DirectFB-1.7.7.orig/configure.in DirectFB-1.7.7/configure.in
+--- DirectFB-1.7.7.orig/configure.in 2015-02-10 01:16:46.0 +0800
DirectFB-1.7.7/configure.in2018-06-06 17:19:18.472143103 +0800
+@@ -2459,10 +2459,13 @@
+
+ enable_tslib=no
+ if test "$checkfor_tslib" = "yes"; then
+- PKG_CHECK_MODULES([TSLIB], [tslib-1.0 >= 1.0.0], [enable_tslib=yes],
[enable_tslib=no])
++ PKG_CHECK_MODULES([TSLIB], [tslib >= 1.1], [enable_tslib=yes],
[enable_tslib=no])
+ if test "$enable_tslib" = "no"; then
+- PKG_CHECK_MODULES([TSLIB], [tslib-0.0], [enable_tslib=yes],
[enable_tslib=no
+- AC_MSG_WARN([*** no tslib -- tslib driver will not be built.])])
++PKG_CHECK_MODULES([TSLIB], [tslib-1.0 >= 1.0], [enable_tslib=yes],
[enable_tslib=no])
++if test "$enable_tslib" = "no"; then
++ PKG_CHECK_MODULES([TSLIB], [tslib-0.0], [enable_tslib=yes],
[enable_tslib=no
++AC_MSG_WARN([*** no tslib -- tslib driver will not be built.])])
++fi
+ fi
+ fi
+
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
