* (No subject)
@ 2011-08-27 3:26 Joel A Fernandes
2011-08-27 7:07 ` Koen Kooi
0 siblings, 1 reply; 26+ messages in thread
From: Joel A Fernandes @ 2011-08-27 3:26 UTC (permalink / raw)
To: openembedded-core
v2 Changes:
Addressing Koen's feedback on patches
* Added a PR to all recipes
* Changed meta-ti in subject to meta-oe
Patches in the series:
[PATCH v2 meta-oe 1/4] gedit: Imported from OE classic
[PATCH v2 meta-oe 2/4] gtksourceview: Imported from OE classic
[PATCH v2 meta-oe 3/4] libgnomecups: Imported from OE Classic
[PATCH v2 meta-oe 4/4] libgnomeprint: Imported from OE classic
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
[not found] <4a795deb3789430487146a8425c1c337@DLEE74.ent.ti.com>
@ 2011-08-27 4:38 ` Joel A Fernandes
2011-08-27 7:11 ` Koen Kooi
0 siblings, 1 reply; 26+ messages in thread
From: Joel A Fernandes @ 2011-08-27 4:38 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Fri, Aug 26, 2011 at 10:26 PM, Fernandes, Joel A <joelagnel@ti.com> wrote:
> v2 Changes:
> Addressing Koen's feedback on patches
> * Added a PR to all recipes
I thought you meant the PR when you said "Which version", didn't know
you were talking about the LICENSE versions.
Anyway, Can we leave the PRs I put into patches 2/4 and 4/4 in?
Also, is it necessary to update LICENSE versions or can we leave it as
is, as I've seen many recipes in oe-core that have it without a
version number.
thanks,
Joel
> * Changed meta-ti in subject to meta-oe
>
> Patches in the series:
>
> [PATCH v2 meta-oe 1/4] gedit: Imported from OE classic
> [PATCH v2 meta-oe 2/4] gtksourceview: Imported from OE classic
> [PATCH v2 meta-oe 3/4] libgnomecups: Imported from OE Classic
> [PATCH v2 meta-oe 4/4] libgnomeprint: Imported from OE classic
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2011-08-27 3:26 Joel A Fernandes
@ 2011-08-27 7:07 ` Koen Kooi
0 siblings, 0 replies; 26+ messages in thread
From: Koen Kooi @ 2011-08-27 7:07 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 aug. 2011, om 05:26 heeft Joel A Fernandes het volgende geschreven:
> v2 Changes:
> Addressing Koen's feedback on patches
> * Added a PR to all recipes
> * Changed meta-ti in subject to meta-oe
>
> Patches in the series:
>
> [PATCH v2 meta-oe 1/4] gedit: Imported from OE classic
> [PATCH v2 meta-oe 2/4] gtksourceview: Imported from OE classic
> [PATCH v2 meta-oe 3/4] libgnomecups: Imported from OE Classic
> [PATCH v2 meta-oe 4/4] libgnomeprint: Imported from OE classic
Same feedback as for Noors series:
1) drop PR = r*
2) RDEPENDS_${PN} is sorted with FILES_*, so don't put it next to DEPENDS
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2011-08-27 4:38 ` Joel A Fernandes
@ 2011-08-27 7:11 ` Koen Kooi
0 siblings, 0 replies; 26+ messages in thread
From: Koen Kooi @ 2011-08-27 7:11 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
Op 27 aug. 2011, om 06:38 heeft Joel A Fernandes het volgende geschreven:
> On Fri, Aug 26, 2011 at 10:26 PM, Fernandes, Joel A <joelagnel@ti.com> wrote:
>> v2 Changes:
>> Addressing Koen's feedback on patches
>> * Added a PR to all recipes
>
> I thought you meant the PR when you said "Which version", didn't know
> you were talking about the LICENSE versions.
>
> Anyway, Can we leave the PRs I put into patches 2/4 and 4/4 in?
No
> Also, is it necessary to update LICENSE versions
Working for a big corporation, do you really need to ask that?
> or can we leave it as
> is, as I've seen many recipes in oe-core that have it without a
> version number.
The fact that OE-core has 83 recipes with a wrong LICENSE doesn't give meta-oe the excuse to drop the ball.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2012-02-21 22:33 Andrei Gherzan
0 siblings, 0 replies; 26+ messages in thread
From: Andrei Gherzan @ 2012-02-21 22:33 UTC (permalink / raw)
To: openembedded-core
Add Upstream-Status in patch file.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2012-06-21 21:36 Andreas Müller
0 siblings, 0 replies; 26+ messages in thread
From: Andreas Müller @ 2012-06-21 21:36 UTC (permalink / raw)
To: openembedded-devel, openembedded-core
after updating all my repos (angstrom+few extra layers) I get
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-kernel/linux/linux-yocto_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/dhcp/dhcp_4.2.3-P2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-ti/recipes-bsp/formfactor/formfactor_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-multimedia/mplayer/mplayer2_git.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer2_git.bbappend
/home/Superandy/data/oe-core/sources/meta-angstrom/recipes-core/update-rc.d/update-rc.d_0.7.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-bsp/x-load/x-load_git.bbappend
/home/Superandy/data/oe-core/sources/meta-gumstix/recipes-bsp/x-load/x-load_git.bbappend
/home/Superandy/data/oe-core/sources/meta-angstrom/recipes-extended/zypper/zypper_git.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-runtime_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-qt/qt4/qt4-x11-free_4.8.1.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-qt/qt4/qt4-x11-free_4.8.1.bbappend
/home/Superandy/data/oe-core/sources/meta-kde/recipes-misc-support/qt4-x11-free_4.8.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-bsp/alsa-state/alsa-state.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-bsp/alsa-state/alsa-state.bbappend
/home/Superandy/data/oe-core/sources/meta-ti/recipes-bsp/alsa-state/alsa-state.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-graphics/tslib/tslib_git.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/openssh/openssh_6.0p1.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/kexecboot/kexecboot-klibc_git.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-gnome/tasks/task-core-sdk-gmae.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk-intermediate_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-kernel/linux/linux-yocto_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-qt/tasks/task-qte-toolchain-target.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-qt/qt4/qt4-embedded_4.8.1.bbappend
/home/Superandy/data/oe-core/sources/meta-angstrom/recipes-core/base-files/base-files_3.0.14.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-core/base-files/base-files_3.0.14.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/base-files/base-files_3.0.14.bbappend
/home/Superandy/data/oe-core/sources/meta-kde/recipes-misc-support/qt4-native_4.8.1.bbappend
/home/Superandy/data/oe-core/sources/meta-ti/recipes-core/netbase/netbase_4.47.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-extended/lighttpd/lighttpd_1.4.30.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-multimedia/gstreamer/gst-ffmpeg_0.10.13.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/drm/libdrm_2.4.34.bbappend
/home/Superandy/data/oe-core/sources/meta-gumstix/recipes-bsp/powervr-drivers/omap3-sgx-modules_4.05.00.03.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-core/dropbear/dropbear_2012.55.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-multimedia/mplayer/mplayer-common.bbappend
/home/Superandy/data/oe-core/sources/meta-freescale/recipes-bsp/u-boot/u-boot_git.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-core/tasks/task-core-tools-profile.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-sugarbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fishriver/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-jasperforest/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-n450/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-htc/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-ti/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-extended/cronie/cronie_1.4.8.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-core/initscripts/initscripts_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/initscripts/initscripts_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-core/initscripts/initscripts_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-gnome/gtk+/gtk-update-icon-cache-runonce.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-extended/polkit/polkit_0.104.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-canadian_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bbappend
/home/Superandy/data/oe-core/sources/meta-gumstix/recipes-kernel/linux/linux_3.0.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-kernel/linux/linux-yocto-tiny-kexecboot_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/meta-emenlow/recipes-gnome/tasks/task-core-standalone-gmae-sdk-target.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/tasks/task-base.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/kexecboot/kexecboot_git.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-core/systemd/systemd-machine-units_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-core/systemd/systemd-machine-units_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-gnome/recipes-gnome/gtk+/gtk+_2.24.8.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-connectivity/connman/connman_0.79.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-palm/recipes-support/lvm2/lvm2_2.02.85.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-graphics/mesa/mesa-dri_7.11.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk-initial_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-browser/recipes-support/nspr/nspr_4.8.9.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-graphics/xorg-lib/pixman_0.25.2.bbappend
/home/Superandy/data/oe-core/sources/meta-angstrom/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-openmoko/recipes-navigation/gpsd/gpsd_3.4.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-bsp/keymaps/keymaps_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-smartphone/meta-nokia/recipes-bsp/keymaps/keymaps_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-bsp/keymaps/keymaps_1.0.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/meta-oe/recipes-core/busybox/busybox_1.19.4.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-intermediate_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-intel/common/recipes-kernel/linux-firmware/linux-firmware_git.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-crosssdk_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/gcc-cross-initial_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-gumstix/recipes-kernel/linux/linux-mainline_3.2.bbappend
/home/Superandy/data/oe-core/sources/meta-openembedded/toolchain-layer/recipes-devtools/gcc/libgcc_4.6.bbappend
/home/Superandy/data/oe-core/sources/meta-handheld/recipes-core/udev/udev_164.bbappend
Strange: many recipes are available. Anybody else with similar experience?
Andreas
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2012-07-03 21:08 Mikhail Boiko
0 siblings, 0 replies; 26+ messages in thread
From: Mikhail Boiko @ 2012-07-03 21:08 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
From 86ad9569e30de537451fe0a4731ef57d92810d28 Mon Sep 17 00:00:00 2001
From: Mikhail Boiko <mikhailboiko85@gmail.com>
Date: Wed, 4 Jul 2012 00:03:17 +0300
Subject: [PATCH] Additional CMake include search path
Specify additional include search path for CMake via build-in
CMAKE_INCLUDE_PATH variable.
For example, to add freetype2 include dir you should add this line to you
receipe
OECMAKE_INCLUDE_PATH_append = "${STAGING_INCDIR}/freetype2"
Signed-off-by: Mikhail Boiko <mikhailboiko85@gmail.com>
---
meta/classes/cmake.bbclass | 3 +++
1 file changed, 3 insertions(+)
diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index eda45dd..2f90e36 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -65,6 +65,9 @@ set( CMAKE_MODULE_PATH ${STAGING_DATADIR}/cmake/Modules/ )
# add for non /usr/lib libdir, e.g. /usr/lib64
set( CMAKE_LIBRARY_PATH ${libdir} ${base_libdir})
+# additional cmake include search path
+set( CMAKE_INCLUDE_PATH ${OECMAKE_INCLUDE_PATH} )
+
EOF
}
--
1.7.9.5
[-- Attachment #2: Type: text/html, Size: 1490 bytes --]
^ permalink raw reply related [flat|nested] 26+ messages in thread
* (No subject)
@ 2012-07-17 16:16 Ross Burton
0 siblings, 0 replies; 26+ messages in thread
From: Ross Burton @ 2012-07-17 16:16 UTC (permalink / raw)
To: openembedded-core
Two patches to follow up Andrei Gherzan's connman series. The first applies
to master, the second only applies on his branch.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2012-08-05 19:48 Javier Martinez Canillas
2012-08-06 14:59 ` Richard Purdie
0 siblings, 1 reply; 26+ messages in thread
From: Javier Martinez Canillas @ 2012-08-05 19:48 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
The OpenEmbedded User Manual list the variables that should be used to
control the directories into which files are installed.
It says that is a poor practice to specify hardcoded paths instead of
using these variables, yet there are many recipes that don't use it.
This is second version of a big patch-set that does a cleanup and replace
the hardcoded paths used on these recipes with the build system variables.
I tried to be as careful as possible to do the proper replacement but
since I could introduce regressions I split the changes in 30 different
patches so it could be git bisectable in case of messing a recipe.
Also, the patches increment the recipes PR since the a distro config can
set the variables to a different value.
Changes since v1:
- Bump recipes PR as suggested by Otavio Salvador and Khem Raj
- Squash ${base_bindir} and ${sysconfdir} changes for xinetd and lsb
recipes so the PR number gets incremented only once.
The patch-set consist of the following patches:
[PATCH v2 01/28] xinetd: use ${sbindir} and ${sysconfdir} instead of
[PATCH v2 02/28] alsa-state: use ${sbindir} instead of /usr/sbin for
[PATCH v2 03/28] lsbsetup: use ${bindir} instead of /usr/bin for
[PATCH v2 04/28] sudo: use ${bindir} and ${sysconfdir} instead of
[PATCH v2 05/28] lsbtest: use ${bindir} instead of /usr/bin for
[PATCH v2 06/28] cronie: use variables instead of hardcoded paths
[PATCH v2 07/28] useradd-example: use ${datadir} instead of
[PATCH v2 08/28] ubootchart: use variables instead of hardcoded
[PATCH v2 09/28] xkeyboard-config: use ${datadir} instead of
[PATCH v2 10/28] systemtap: use ${datadir} instead of /usr/share for
[PATCH v2 11/28] lsb: use ${base_bindir} and ${sysconfdir} instead
[PATCH v2 12/28] mingetty: use ${base_sbindir} instead of /sbin for
[PATCH v2 13/28] external-sourcery: use ${prefix} and ${libdir}
[PATCH v2 14/28] rpm: use ${localstatedir} and ${libdir} instead of
[PATCH v2 15/28] at: use ${base_sbindir} instead of /sbin for
[PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and
[PATCH v2 17/28] linux-firware: use ${base_libdir} instead of /lib
[PATCH v2 18/28] openssh: use ${localstatedir} instead of /var for
[PATCH v2 19/28] libpam: use ${localstatedir} and ${sysconfdir}
[PATCH v2 20/28] x11-common: use ${sysconfdir} instead of /etc for
[PATCH v2 21/28] builder: use ${sysconfdir} instead of /etc for
[PATCH v2 22/28] xserver-nodm-init: use ${sysconfdir} instead of
[PATCH v2 23/28] lsbinitscripts: use ${sysconfdir} instead of /etc
[PATCH v2 24/28] usbinit: use ${sysconfdir} instead of /etc for
[PATCH v2 25/28] qemu-config: use ${sysconfdir} instead of /etc for
[PATCH v2 26/28] rsync: use ${sysconfdir} instead of /etc for
[PATCH v2 27/28] chkconfig: use ${sysconfdir} instead of /etc for
[PATCH v2 28/28] man: use ${sysconfdir} instead of /etc for
Best regards,
Javier
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2012-08-05 19:48 Javier Martinez Canillas
@ 2012-08-06 14:59 ` Richard Purdie
0 siblings, 0 replies; 26+ messages in thread
From: Richard Purdie @ 2012-08-06 14:59 UTC (permalink / raw)
To: Javier Martinez Canillas; +Cc: openembedded-core
On Sun, 2012-08-05 at 21:48 +0200, Javier Martinez Canillas wrote:
> The OpenEmbedded User Manual list the variables that should be used to
> control the directories into which files are installed.
>
> It says that is a poor practice to specify hardcoded paths instead of
> using these variables, yet there are many recipes that don't use it.
>
> This is second version of a big patch-set that does a cleanup and replace
> the hardcoded paths used on these recipes with the build system variables.
>
> I tried to be as careful as possible to do the proper replacement but
> since I could introduce regressions I split the changes in 30 different
> patches so it could be git bisectable in case of messing a recipe.
>
> Also, the patches increment the recipes PR since the a distro config can
> set the variables to a different value.
>
> Changes since v1:
>
> - Bump recipes PR as suggested by Otavio Salvador and Khem Raj
> - Squash ${base_bindir} and ${sysconfdir} changes for xinetd and lsb
> recipes so the PR number gets incremented only once.
>
> The patch-set consist of the following patches:
>
> [PATCH v2 01/28] xinetd: use ${sbindir} and ${sysconfdir} instead of
> [PATCH v2 02/28] alsa-state: use ${sbindir} instead of /usr/sbin for
> [PATCH v2 03/28] lsbsetup: use ${bindir} instead of /usr/bin for
> [PATCH v2 04/28] sudo: use ${bindir} and ${sysconfdir} instead of
> [PATCH v2 05/28] lsbtest: use ${bindir} instead of /usr/bin for
> [PATCH v2 06/28] cronie: use variables instead of hardcoded paths
> [PATCH v2 07/28] useradd-example: use ${datadir} instead of
> [PATCH v2 08/28] ubootchart: use variables instead of hardcoded
> [PATCH v2 09/28] xkeyboard-config: use ${datadir} instead of
> [PATCH v2 10/28] systemtap: use ${datadir} instead of /usr/share for
> [PATCH v2 11/28] lsb: use ${base_bindir} and ${sysconfdir} instead
> [PATCH v2 12/28] mingetty: use ${base_sbindir} instead of /sbin for
> [PATCH v2 13/28] external-sourcery: use ${prefix} and ${libdir}
> [PATCH v2 14/28] rpm: use ${localstatedir} and ${libdir} instead of
> [PATCH v2 15/28] at: use ${base_sbindir} instead of /sbin for
> [PATCH v2 16/28] kernel.bbclass: use ${base_libdir} and
> [PATCH v2 17/28] linux-firware: use ${base_libdir} instead of /lib
> [PATCH v2 18/28] openssh: use ${localstatedir} instead of /var for
> [PATCH v2 19/28] libpam: use ${localstatedir} and ${sysconfdir}
> [PATCH v2 20/28] x11-common: use ${sysconfdir} instead of /etc for
> [PATCH v2 21/28] builder: use ${sysconfdir} instead of /etc for
> [PATCH v2 22/28] xserver-nodm-init: use ${sysconfdir} instead of
> [PATCH v2 23/28] lsbinitscripts: use ${sysconfdir} instead of /etc
> [PATCH v2 24/28] usbinit: use ${sysconfdir} instead of /etc for
> [PATCH v2 25/28] qemu-config: use ${sysconfdir} instead of /etc for
> [PATCH v2 26/28] rsync: use ${sysconfdir} instead of /etc for
> [PATCH v2 27/28] chkconfig: use ${sysconfdir} instead of /etc for
> [PATCH v2 28/28] man: use ${sysconfdir} instead of /etc for
Thanks for these, I merged most of them apart from external-sourcery
which Chris commented on, the at recipe which I found a better fix for
which removed the lines in question and the rpm change which I want to
check something out related to it first.
Cheers,
Richard
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2012-12-06 9:49 Lukas Bulwahn
0 siblings, 0 replies; 26+ messages in thread
From: Lukas Bulwahn @ 2012-12-06 9:49 UTC (permalink / raw)
To: openembedded-core
I was trying to create a minimal core image with python-setuptools and noticed that the python-setuptools recipe does not work.
The reason is that during do_install, it creates shell scripts that refer to python-native instead of python.
The attached patch tries to solve this issue. Another minimal example thta shows this issue can be found at https://gist.github.com/4223250.
Lukas Bulwahn
BMW Car IT GmbH
From Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de> # This line is ignored.
From: Lukas Bulwahn <lukas.bulwahn@oss.bmw-carit.de>
Subject:
In-Reply-To:
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2013-01-21 10:49 Mike Looijmans
2013-01-21 11:26 ` Richard Purdie
0 siblings, 1 reply; 26+ messages in thread
From: Mike Looijmans @ 2013-01-21 10:49 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
This mail bounced so the v2 patch overtook it...
>> From: Mike Looijmans <mike.looijmans@topic.nl>
>>
>> Multicore embedded systems are getting more and more common.
>>
>> Remove "--disable-openmp" from the GCC configuration options and
>> always build libgomp. This only creates a "bigger" compiler but
>> has no effect on the compiled binaries that don't use openmp.
>>
>> Tested a clean build on mips32el and arm7a, no problems encountered.
>>
>> Autoconf will not detect OpenMP after this change, because it will
>> build and run a target binary on the build system. In order to use
>> OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
>> ---
>> meta/recipes-devtools/gcc/gcc-4.7.inc | 9 +++------
>> .../recipes-devtools/gcc/gcc-configure-runtime.inc | 4 +---
>> .../recipes-devtools/gcc/gcc-cross-canadian_4.7.bb | 2 +-
>> 3 files changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc
>> b/meta/recipes-devtools/gcc/gcc-4.7.inc
>> index 08a0103..a7aa4a4 100644
>> --- a/meta/recipes-devtools/gcc/gcc-4.7.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
>> @@ -88,7 +88,6 @@ JAVA = ""
>> EXTRA_OECONF_BASE = " --enable-lto \
>> --enable-libssp \
>> --disable-bootstrap \
>> - --disable-libgomp \
>> --disable-libmudflap \
>> --with-system-zlib \
>> --with-linker-hash-style=${LINKER_HASH_STYLE} \
>> @@ -99,7 +98,6 @@ EXTRA_OECONF_BASE = " --enable-lto \
>> --enable-cheaders=c_global "
>>
>> EXTRA_OECONF_INITIAL = "--disable-libmudflap \
>> - --disable-libgomp \
>> --disable-libssp \
>> --disable-libquadmath \
>> --with-system-zlib \
>> @@ -108,7 +106,6 @@ EXTRA_OECONF_INITIAL = "--disable-libmudflap \
>> --enable-decimal-float=no"
>>
>> EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap \
>> - --disable-libgomp \
>> --disable-libquadmath \
>> --with-system-zlib \
>> --disable-lto \
>
>
> I nearly took this however you still want this disabled in the
> INITIAL/INTERMEDIATE versions, you're just wasting compile time there sa
> nothing would use it.
I don't see the harm in allowing OpenMP usage in build tools (e.g. image
processing on the build machine), but if it gets the patch through
sooner, I'll happily remove it. I tend to run unit tests on my build
system, using OE's compiler version, so it's nice if both host and build
compilers accept the same options.
>
>> @@ -117,9 +114,9 @@ EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap \
>>
>> EXTRA_OECONF_append_libc-uclibc = " --disable-decimal-float "
>>
>> -EXTRA_OECONF_PATHS = " \
>> - --with-gxx-include-dir=${STAGING_DIR_TARGET}${target_includedir}/c++ \
>> - --with-sysroot=${STAGING_DIR_TARGET} \
>> +EXTRA_OECONF_PATHS = " \
>> + --with-gxx-include-dir=${STAGING_DIR_TARGET}${target_includedir}/c++ \
>> + --with-sysroot=${STAGING_DIR_TARGET} \
>
>
> What changed here?
Excellent question, I haven't got the faintest clue why GIT added this.
I'll fix it.
>
>> --with-build-sysroot=${STAGING_DIR_TARGET}"
>>
>> do_configure_prepend () {
>> diff --git a/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> b/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> index d40383c..1c9155f 100644
>> --- a/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-configure-runtime.inc
>> @@ -7,9 +7,7 @@ EXTRA_OECONF_PATHS = " \
>> --with-sysroot=${STAGING_DIR_TARGET} \
>> --with-build-sysroot=${STAGING_DIR_TARGET}"
>>
>> -RUNTIMETARGET = "libssp libstdc++-v3"
>> -RUNTIMETARGET_append_powerpc = " libgomp"
>> -RUNTIMETARGET_append_powerpc64 = " libgomp"
>> +RUNTIMETARGET = "libssp libstdc++-v3 libgomp"
>> # ?
>> # libiberty
>> # libmudflap
>> diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> index 53c4632..6c048c0 100644
>> --- a/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
>> @@ -13,7 +13,7 @@ SYSTEMLIBS = "${target_base_libdir}/"
>> SYSTEMLIBS1 = "${target_libdir}/"
>>
>> EXTRA_OECONF += "--disable-libunwind-exceptions --disable-libssp \
>> - --disable-libgomp --disable-libmudflap \
>> + --disable-libmudflap \
>
>
> Again, I'm wondering if you mean this here. The library would have been
> built as part of the target build? Does the library need gcc support as
> well as its presence?
>
Same motivation as above actually, I see no harm in allowing it. Again,
I'll remove it for quickness, I'm quite eager to see OpenMP support in OE.
I'll post a much smaller V2 patch.
Mike
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) - (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl
Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.
The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2013-01-21 10:49 (No subject) Mike Looijmans
@ 2013-01-21 11:26 ` Richard Purdie
0 siblings, 0 replies; 26+ messages in thread
From: Richard Purdie @ 2013-01-21 11:26 UTC (permalink / raw)
To: Mike Looijmans; +Cc: openembedded-core@lists.openembedded.org
On Mon, 2013-01-21 at 10:49 +0000, Mike Looijmans wrote:
> This mail bounced so the v2 patch overtook it...
>
> >> From: Mike Looijmans <mike.looijmans@topic.nl>
> >>
> >> Multicore embedded systems are getting more and more common.
> >>
> >> Remove "--disable-openmp" from the GCC configuration options and
> >> always build libgomp. This only creates a "bigger" compiler but
> >> has no effect on the compiled binaries that don't use openmp.
> >>
> >> Tested a clean build on mips32el and arm7a, no problems encountered.
> >>
> >> Autoconf will not detect OpenMP after this change, because it will
> >> build and run a target binary on the build system. In order to use
> >> OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
> >> ---
> >> meta/recipes-devtools/gcc/gcc-4.7.inc | 9 +++------
> >> .../recipes-devtools/gcc/gcc-configure-runtime.inc | 4 +---
> >> .../recipes-devtools/gcc/gcc-cross-canadian_4.7.bb | 2 +-
> >> 3 files changed, 5 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> b/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> index 08a0103..a7aa4a4 100644
> >> --- a/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> +++ b/meta/recipes-devtools/gcc/gcc-4.7.inc
> >> @@ -88,7 +88,6 @@ JAVA = ""
> >> EXTRA_OECONF_BASE = " --enable-lto \
> >> --enable-libssp \
> >> --disable-bootstrap \
> >> - --disable-libgomp \
> >> --disable-libmudflap \
> >> --with-system-zlib \
> >> --with-linker-hash-style=${LINKER_HASH_STYLE} \
> >> @@ -99,7 +98,6 @@ EXTRA_OECONF_BASE = " --enable-lto \
> >> --enable-cheaders=c_global "
> >>
> >> EXTRA_OECONF_INITIAL = "--disable-libmudflap \
> >> - --disable-libgomp \
> >> --disable-libssp \
> >> --disable-libquadmath \
> >> --with-system-zlib \
> >> @@ -108,7 +106,6 @@ EXTRA_OECONF_INITIAL = "--disable-libmudflap \
> >> --enable-decimal-float=no"
> >>
> >> EXTRA_OECONF_INTERMEDIATE = "--disable-libmudflap \
> >> - --disable-libgomp \
> >> --disable-libquadmath \
> >> --with-system-zlib \
> >> --disable-lto \
> >
> >
> > I nearly took this however you still want this disabled in the
> > INITIAL/INTERMEDIATE versions, you're just wasting compile time there sa
> > nothing would use it.
>
> I don't see the harm in allowing OpenMP usage in build tools (e.g. image
> processing on the build machine), but if it gets the patch through
> sooner, I'll happily remove it. I tend to run unit tests on my build
> system, using OE's compiler version, so it's nice if both host and build
> compilers accept the same options.
The initial/intermediate compiles are only used to build libc and the
final "proper" cross compiler. Since none of these use or benefit from
libgomp, its simply wasting build time having this enabled there.
I'm ok with enabling things where there is a use for them but I also
perfer having an efficient build process where we can. This is why there
are various things disabled above for initial/intermediate.
> >> b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
> >> index 53c4632..6c048c0 100644
> >> --- a/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
> >> +++ b/meta/recipes-devtools/gcc/gcc-cross-canadian_4.7.bb
> >> @@ -13,7 +13,7 @@ SYSTEMLIBS = "${target_base_libdir}/"
> >> SYSTEMLIBS1 = "${target_libdir}/"
> >>
> >> EXTRA_OECONF += "--disable-libunwind-exceptions --disable-libssp \
> >> - --disable-libgomp --disable-libmudflap \
> >> + --disable-libmudflap \
> >
> >
> > Again, I'm wondering if you mean this here. The library would have been
> > built as part of the target build? Does the library need gcc support as
> > well as its presence?
> >
>
> Same motivation as above actually, I see no harm in allowing it. Again,
> I'll remove it for quickness, I'm quite eager to see OpenMP support in OE.
It leads to inconsistencies with other libraries and behaviour so I'm
happier with this being left disabled here, unless someone can point me
at a good reason why we should enable it.
> I'll post a much smaller V2 patch.
Thanks. This will likely go in after M3. I don't fancy changing the
compiler this close to the M3 build (feature freeze for M3 was
yesterday). I will queue it in master-next for now.
Cheers,
Richard
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2013-01-23 15:12 Belal, Awais
0 siblings, 0 replies; 26+ messages in thread
From: Belal, Awais @ 2013-01-23 15:12 UTC (permalink / raw)
To: Openembedded-core@lists.openembedded.org
[-- Attachment #1.1: Type: text/plain, Size: 693 bytes --]
Hi Guys,
I have a question regarding openssl. The openssl.inc file under the poky package creates a -misc package which is not directly installed unless either put in RDPENEDS or RRECOMMENDS. This package (-misc) contains the openssl configuration file which is required while generating certificates on the target otherwise the command says:
WARNING: can't open config file: /usr/lib/ssl/openssl.cnf
Unable to load config info from /usr/lib/ssl/openssl.cnf
In an older version of the recipe attached here, the correct method is being (this is my understanding) to get that file in on the target while installing.
Any guidance here would be much appreciated.
BR,
Awais Belal
[-- Attachment #1.2: Type: text/html, Size: 1513 bytes --]
[-- Attachment #2: openssl.inc --]
[-- Type: application/octet-stream, Size: 3372 bytes --]
DESCRIPTION = "Secure Socket Layer (SSL) binary and related cryptographic tools."
HOMEPAGE = "http://www.openssl.org/"
LICENSE = "openssl"
SECTION = "libs/network"
SRC_URI = "http://www.openssl.org/source/openssl-${PV}.tar.gz;name=src"
S = "${WORKDIR}/openssl-${PV}"
inherit siteinfo
INC_PR = "r14"
AR_append = " r"
CFLAG = "${@base_conditional('SITEINFO_ENDIANNESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)} \
-DTERMIO ${FULL_OPTIMIZATION} -Wall"
# -02 does not work on mipsel: ssh hangs when it tries to read /dev/urandom
CFLAG_mtx-1 := "${@'${CFLAG}'.replace('-O2', '')}"
CFLAG_mtx-2 := "${@'${CFLAG}'.replace('-O2', '')}"
export DIRS = "crypto ssl apps"
export EX_LIBS = "-lgcc -ldl"
export AS = "${CC} -c"
PACKAGES =+ "libcrypto libssl ${PN}-misc openssl-conf"
FILES_libcrypto = "${libdir}/libcrypto.so.*"
FILES_libssl = "${libdir}/libssl.so.*"
FILES_${PN}-misc = "${libdir}/ssl/misc"
# Add the openssl.cnf file to the openssl-conf package. Make the libcrypto
# package RRECOMMENDS on this package. This will enable the configuration
# file to be installed for both the base openssl package and the libcrypto
# package since the base openssl package depends on the libcrypto package.
FILES_openssl-conf = "${libdir}/ssl/openssl.cnf"
CONFFILES_openssl-conf = "${libdir}/ssl/openssl.cnf"
RRECOMMENDS_libcrypto += "openssl-conf"
do_configure_prepend_darwin () {
sed -i -e '/version-script=openssl\.ld/d' Configure
}
do_configure () {
cd util
perl perlpath.pl ${bindir}
cd ..
ln -sf apps/openssl.pod crypto/crypto.pod ssl/ssl.pod doc/
os=${HOST_OS}
if [ `echo $os | grep -q linux; echo $?` -eq 0 ]; then
os=linux
fi
target="$os-${HOST_ARCH}"
case $target in
linux-arm)
target=linux-elf-arm
;;
linux-armeb)
target=linux-elf-armeb
;;
linux-sh3)
target=debian-sh3
;;
linux-sh4)
target=debian-sh4
;;
linux-i486)
target=debian-i386-i486
;;
linux-i586 | linux-viac3)
target=debian-i386-i586
;;
linux-i686)
target=debian-i386-i686/cmov
;;
linux-mips)
target=debian-mips
;;
linux-mipsel)
target=debian-mipsel
;;
linux-powerpc)
target=linux-ppc
;;
linux-powerpc64)
target=linux-ppc64
;;
linux-supersparc)
target=linux-sparcv8
;;
linux-sparc)
target=linux-sparcv8
;;
darwin-i386)
target=darwin-i386-cc
;;
esac
# inject machine-specific flags
sed -i -e "s|^\(\"$target\",\s*\"[^:]\+\):\([^:]\+\)|\1:${CFLAG}|g" Configure
useprefix=${prefix}
if [ "x$useprefix" = "x" ]; then
useprefix=/
fi
perl ./Configure ${EXTRA_OECONF} shared --prefix=$useprefix --openssldir=${libdir}/ssl $target
eval "${@base_contains('DISTRO_FEATURES', 'largefile', '', 'sed -i -e "/_FILE_OFFSET_BITS/,/#endif/d" ${S}/crypto/bio/bss_file.c', d)}"
eval "${@base_contains('DISTRO_FEATURES', 'ipv6', '', 'sed -i -e "/AF_INET6/,/break/d" ${S}/crypto/bio/bss_dgram.c', d)}"
}
do_compile () {
oe_runmake
}
do_install () {
oe_runmake INSTALL_PREFIX="${D}" install
# On x86_64, move lib/* to lib64
if [ "${libdir}" != "${prefix}/lib" ]
then
install -d ${D}${libdir} ${D}${libdir}/pkgconfig
mv ${D}${prefix}/lib/lib* ${D}${libdir}
mv ${D}${prefix}/lib/pkgconfig/*.pc ${D}${libdir}/pkgconfig
fi
oe_libinstall -so libcrypto ${D}${libdir}
oe_libinstall -so libssl ${D}${libdir}
install -d ${D}${includedir}
cp -L -R include/openssl ${D}${includedir}
}
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2014-07-16 3:26 Shan Hai
0 siblings, 0 replies; 26+ messages in thread
From: Shan Hai @ 2014-07-16 3:26 UTC (permalink / raw)
To: openembedded-core
Fix grub bug #36755 by cherry picking a patch from grub upstream.
The bug is reported at "http://savannah.gnu.org/bugs/?36755"
Thanks
Shan Hai
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2016-07-22 10:35 Amarnath Valluri
0 siblings, 0 replies; 26+ messages in thread
From: Amarnath Valluri @ 2016-07-22 10:35 UTC (permalink / raw)
To: openembedded-core
As discussed offline with Joshua, Updated the patch to make the stateless
user home folder as build config option(--disable-stateless-home).
---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2017-05-07 1:33 [PATCH] openssh: Atomically generate host keys Joshua Watt
@ 2017-05-09 2:24 ` Joshua Watt
0 siblings, 0 replies; 26+ messages in thread
From: Joshua Watt @ 2017-05-09 2:24 UTC (permalink / raw)
To: openembedded-core
No need to create a directory name "644"
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2017-11-27 16:20 Volker Vogelhuber
0 siblings, 0 replies; 26+ messages in thread
From: Volker Vogelhuber @ 2017-11-27 16:20 UTC (permalink / raw)
To: openembedded-core
I currently have an image with six different partitions. See the
following partition configuration:
># bootloader
>part /boot/EFI --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk mmcblk --fstype=vfat --label boot --active --align 1024 --size 20 --overhead-factor=1.0 --uuid="1EFC2AC2-449B-6ABB-AA63-7EA004446DF1"
>
>#--use-uuid
># primary / recovery image
>part / --source rootfs --rootfs-dir=image --exclude-path opt/something/ opt/else/ opt/somemore/ --ondisk mmcblk --fstype=ext4 --label primary_rootfs --align 1024 --size 768 --overhead-factor=1.0 --uuid="2779D408-1362-AEF5-AEB1-00BF5674C065"
>part /recovery --source rootfs --rootfs-dir=image-recovery --ondisk mmcblk --fstype=ext4 --label recovery_rootfs --align 1024 --size 640 --overhead-factor=1.0 --uuid="528B6F25-5143-47B3-8D12-391820EAF1CF"
>
># additional partitions
>part /opt/something --source rootfs --rootfs-dir=image --rootfs-subdir=opt/something --ondisk mmcblk --fstype=ext4 --label persist --align 1024 --size 64 --overhead-factor=1.0 --use-uuid
>part /opt/else --source rootfs --rootfs-dir=image --rootfs-subdir=opt/else --ondisk mmcblk --fstype=ext4 --label de --align 1024 --size 256 --overhead-factor=1.0 --use-uuid
>part /opt/somemore --source rootfs --rootfs-dir=image --rootfs-subdir=opt/somemore --ondisk mmcblk --fstype=ext4 --label data --align 1024 --size 1700 --overhead-factor=1.0 --use-uuid
>
>bootloader --timeout=0 --ptable gpt --configfile="disk.cfg"
My problem is now that if I use the wic -e option to specify an image
name as rootfs-dir I can not extract subdirectories from the rootfs
to different partitions. Or at least I didn't found out a way.
That's why I added a rootfs-subdir option to wic that allows appending
a rootfs dir to the one received by IMAGE_ROOTFS. I read something
about spliting should be done on recipe level
(https://lists.yoctoproject.org/pipermail/yocto/2016-March/029301.html),
but I couldn't figure out how that should be done and that patch seems
much easier for me.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2018-05-03 19:55 taborskikrzysztof
0 siblings, 0 replies; 26+ messages in thread
From: taborskikrzysztof @ 2018-05-03 19:55 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 31 bytes --]
Wysłano z telefonu Samsung
[-- Attachment #2: Type: text/html, Size: 286 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
@ 2018-08-02 8:44 Nathan Rossi
0 siblings, 0 replies; 26+ messages in thread
From: Nathan Rossi @ 2018-08-02 8:44 UTC (permalink / raw)
To: openembedded-core; +Cc: Martin Hundebøll
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 8415 bytes --]
,
Manjukumar Harthikote Matha <manjukumar.harthikote-matha@xilinx.com>
Subject:
[PATCH] devicetree.bbclass: User/BSP device tree source compilation class
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
This bbclass implements the device tree compilation for user provided
device trees. In order to use this class, it should be inherited in a
BSP recipe which provides the sources. The default setup enables
inclusion of kernel device tree sources (though can be disabled by the
recipe by overriding DT_INCLUDE or KERNEL_INCLUDE).
This provides an additional mechanism for BSPs to provide device trees
and device tree overlays for their target machines. Whilst still
enabling access to the kernel device trees for base SoC includes and
headers.
This approach to providing device trees has benefits for certain use
cases over patching the device trees into the kernel source.
* device trees are separated from kernel source, allows for selection of
kernel and or kernel versions without needing to explicitly patch the
kernel (or appending to the kernel recipes).
* providing device trees from separate sources, from the layer,
generated by the recipe or other recipes.
This class also implements some additional features that are not
available in the kernel-devicetree flow. This includes population of
device tree blobs into the sysroot which allows for other recipes to
consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree
overlay compilation and customizing DTC compilation args (boot
cpu/padding/etc.).
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Acked-by: Martin Hundebøll <mnhu@prevas.dk>
---
In addition to this patch I have written some documentation for the
Yocto BSP guide that covers details about both methods.
The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly
like this class for some time. It has been very useful for out-of-kernel
device tree compilation as well as for a mechanism so that users of
Xilinx SoCs can provide their customizations (FPGA devices) and board
specific configuration. This compilation flow also makes sense for other
BSPs, which is the reason for creating this bbclass for common shared
use by other BSPs.
Examples of this classes usage can be seen for meta-xilinx:
https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb
---
meta/classes/devicetree.bbclass | 140 ++++++++++++++++++++++++++++++++
1 file changed, 140 insertions(+)
create mode 100644 meta/classes/devicetree.bbclass
diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass
new file mode 100644
index 0000000000..dbc83f2a1d
--- /dev/null
+++ b/meta/classes/devicetree.bbclass
@@ -0,0 +1,140 @@
+# This bbclass implements device tree compliation for user provided device tree
+# sources. The compilation of the device tree sources is the same as the kernel
+# device tree compilation process, this includes being able to include sources
+# from the kernel such as soc dtsi files or header files such as gpio.h. In
+# addition to device trees this bbclass also handles compilation of device tree
+# overlays.
+#
+# The output of this class behaves similar to how kernel-devicetree.bbclass
+# operates in that the output files are installed into /boot/devicetree.
+# However this class on purpose separates the deployed device trees into the
+# 'devicetree' subdirectory. This prevents clashes with the kernel-devicetree
+# output. Additionally the device trees are populated into the sysroot for
+# access via the sysroot from within other recipes.
+
+SECTION ?= "bsp"
+
+# The default inclusion of kernel device tree includes and headers means that
+# device trees built with them are at least GPLv2 (and in some cases dual
+# licensed). Default to GPLv2 if the recipe does not specify a license.
+LICENSE ?= "GPLv2"
+LIC_FILES_CHKSUM ?= "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS += "dtc-native"
+
+inherit deploy kernel-arch
+
+COMPATIBLE_MACHINE ?= "^$"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+SYSROOT_DIRS += "/boot/devicetree"
+FILES_${PN} = "/boot/devicetree/*.dtb /boot/devicetree/*.dtbo"
+
+S = "${WORKDIR}"
+B = "${WORKDIR}/build"
+
+# Default kernel includes, these represent what are normally used for in-kernel
+# sources.
+KERNEL_INCLUDE ??= " \
+ ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
+ ${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \
+ ${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
+ "
+
+DT_INCLUDE[doc] = "Search paths to be made available to both the device tree compiler and preprocessor for inclusion."
+DT_INCLUDE ?= "${DT_FILES_PATH} ${KERNEL_INCLUDE}"
+DT_FILES_PATH[doc] = "Defaults to source directory, can be used to select dts files that are not in source (e.g. generated)."
+DT_FILES_PATH ?= "${S}"
+
+DT_PADDING_SIZE[doc] = "Size of padding on the device tree blob, used as extra space typically for additional properties during boot."
+DT_PADDING_SIZE ??= "0x3000"
+DT_RESERVED_MAP[doc] = "Number of reserved map entires."
+DT_RESERVED_MAP ??= "8"
+DT_BOOT_CPU[doc] = "The boot cpu, defaults to 0"
+DT_BOOT_CPU ??= "0"
+
+DTC_FLAGS ?= "-R ${DT_RESERVED_MAP} -p ${DT_PADDING_SIZE} -b ${DT_BOOT_CPU}"
+DTC_PPFLAGS ?= "-nostdinc -undef -D__DTS__ -x assembler-with-cpp"
+DTC_OFLAGS ?= "-@ -H epapr"
+
+python () {
+ if d.getVar("KERNEL_INCLUDE"):
+ # auto add dependency on kernel tree, but only if kernel include paths
+ # are specified.
+ d.appendVarFlag("do_compile", "depends", " virtual/kernel:do_configure")
+}
+
+def expand_includes(varname, d):
+ import glob
+ includes = set()
+ # expand all includes with glob
+ for i in (d.getVar(varname) or "").split():
+ for g in glob.glob(i):
+ if os.path.isdir(g): # only add directories to include path
+ includes.add(g)
+ return includes
+
+def devicetree_source_is_overlay(path):
+ # determine if a dts file is an overlay by checking if it uses "/plugin/;"
+ with open(path, "r") as f:
+ for i in f:
+ if i.startswith("/plugin/;"):
+ return True
+ return False
+
+def devicetree_compile(dtspath, includes, d):
+ import subprocess
+ dts = os.path.basename(dtspath)
+ dtname = os.path.splitext(dts)[0]
+ bb.note("Processing {0} [{1}]".format(dtname, dts))
+
+ # preprocess
+ ppargs = d.getVar("BUILD_CPP").split()
+ ppargs += (d.getVar("DTC_PPFLAGS") or "").split()
+ for i in includes:
+ ppargs.append("-I{0}".format(i))
+ ppargs += ["-o", "{0}.pp".format(dts), dtspath]
+ bb.note("Running {0}".format(" ".join(ppargs)))
+ subprocess.run(ppargs, check = True)
+
+ # determine if the file is an overlay or not (using the preprocessed file)
+ isoverlay = devicetree_source_is_overlay("{0}.pp".format(dts))
+
+ # compile
+ dtcargs = ["dtc"] + (d.getVar("DTC_FLAGS") or "").split()
+ if isoverlay:
+ dtcargs += (d.getVar("DTC_OFLAGS") or "").split()
+ for i in includes:
+ dtcargs += ["-i", i]
+ dtcargs += ["-o", "{0}.{1}".format(dtname, "dtbo" if isoverlay else "dtb")]
+ dtcargs += ["-I", "dts", "-O", "dtb", "{0}.pp".format(dts)]
+ bb.note("Running {0}".format(" ".join(dtcargs)))
+ subprocess.run(dtcargs, check = True)
+
+python devicetree_do_compile() {
+ includes = expand_includes("DT_INCLUDE", d)
+ listpath = d.getVar("DT_FILES_PATH")
+ for dts in os.listdir(listpath):
+ if not dts.endswith(".dts"):
+ continue # skip non-.dts files
+ dtspath = os.path.join(listpath, dts)
+ devicetree_compile(dtspath, includes, d)
+}
+
+devicetree_do_install() {
+ for DTB_FILE in `ls *.dtb *.dtbo`; do
+ install -Dm 0644 ${B}/${DTB_FILE} ${D}/boot/devicetree/${DTB_FILE}
+ done
+}
+
+devicetree_do_deploy() {
+ for DTB_FILE in `ls *.dtb *.dtbo`; do
+ install -Dm 0644 ${B}/${DTB_FILE} ${DEPLOYDIR}/devicetree/${DTB_FILE}
+ done
+}
+addtask deploy before do_build after do_install
+
+EXPORT_FUNCTIONS do_compile do_install do_deploy
+
--
2.18.0
^ permalink raw reply related [flat|nested] 26+ messages in thread
* (No subject)
@ 2018-10-04 13:29 Angelo Dureghello
2018-10-04 13:55 ` Burton, Ross
0 siblings, 1 reply; 26+ messages in thread
From: Angelo Dureghello @ 2018-10-04 13:29 UTC (permalink / raw)
To: openembedded-core
This patch serie adds initial support for m68k architecture.
A Linux kernel build has been tested successfully using a local
meta layer, or kernel-yocto.
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2018-10-04 13:29 Angelo Dureghello
@ 2018-10-04 13:55 ` Burton, Ross
2018-10-04 15:00 ` Andrea Adami
2018-10-04 15:08 ` Angelo Dureghello
0 siblings, 2 replies; 26+ messages in thread
From: Burton, Ross @ 2018-10-04 13:55 UTC (permalink / raw)
To: angelo; +Cc: OE-core
I'm curious: the data sheet for the processor you mention in 4/4 says
that it ha 64K of RAM. Are there other processors in the range, or
have you done incredible things?
Ross
On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello <angelo@sysam.it> wrote:
>
>
> This patch serie adds initial support for m68k architecture.
> A Linux kernel build has been tested successfully using a local
> meta layer, or kernel-yocto.
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2018-10-04 13:55 ` Burton, Ross
@ 2018-10-04 15:00 ` Andrea Adami
2018-10-04 15:08 ` Angelo Dureghello
1 sibling, 0 replies; 26+ messages in thread
From: Andrea Adami @ 2018-10-04 15:00 UTC (permalink / raw)
To: Burton, Ross; +Cc: Patches and discussions about the oe-core layer, angelo
On Thu, Oct 4, 2018 at 3:55 PM Burton, Ross <ross.burton@intel.com> wrote:
>
> I'm curious: the data sheet for the processor you mention in 4/4 says
> that it ha 64K of RAM. Are there other processors in the range, or
> have you done incredible things?
>
> Ross
Heh,
64K is the internal sram..
There is a sdram controller DDR2 and a 32bit FlexBus bus for ROM/RAM
so I bet there is more...
Cheers
Andrea
P.S. I will notice right now an old m68k acker...
>On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello <angelo@sysam.it> wrote:
> >
> >
> > This patch serie adds initial support for m68k architecture.
> > A Linux kernel build has been tested successfully using a local
> > meta layer, or kernel-yocto.
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2018-10-04 13:55 ` Burton, Ross
2018-10-04 15:00 ` Andrea Adami
@ 2018-10-04 15:08 ` Angelo Dureghello
1 sibling, 0 replies; 26+ messages in thread
From: Angelo Dureghello @ 2018-10-04 15:08 UTC (permalink / raw)
To: Burton, Ross; +Cc: OE-core
Hi Burton,
On Thu, Oct 04, 2018 at 02:55:37PM +0100, Burton, Ross wrote:
> I'm curious: the data sheet for the processor you mention in 4/4 says
> that it ha 64K of RAM. Are there other processors in the range, or
> have you done incredible things?
>
64KB is the internal static ram (SRAM), that's commonly 4 to 64K
for this family (i.e. some recent arm reachs 512K).
Then there is the built-in SDRAM/DDR2 controller :)
where i connect 128MB of DDR2(SDRAM), but other boards may have more.
Linux runs fine in ColdFire family from a long time. Initially only
non-MMU uClinux, now also the mainline kernel with MMU enabled.
Regards,
Angelo
> Ross
> On Thu, 4 Oct 2018 at 14:30, Angelo Dureghello <angelo@sysam.it> wrote:
> >
> >
> > This patch serie adds initial support for m68k architecture.
> > A Linux kernel build has been tested successfully using a local
> > meta layer, or kernel-yocto.
> > --
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
^ permalink raw reply [flat|nested] 26+ messages in thread
* (No subject)
2019-02-05 21:52 [PATCH] wpa_supplicant: Changed systemd template units Richard Purdie
@ 2019-02-07 14:48 ` Joshua DeWeese
0 siblings, 0 replies; 26+ messages in thread
From: Joshua DeWeese @ 2019-02-07 14:48 UTC (permalink / raw)
To: richard.purdie, openembedded-core; +Cc: Joshua DeWeese
Here it is, updated to work with wpa-supplicant_2.6.bb.
-- >8 --
From 12d39342b00a1ad5536b105e23b9ea732bba5489 Mon Sep 17 00:00:00 2001
From: Joshua DeWeese <jdeweese@hennypenny.com>
Date: Tue, 5 Feb 2019 10:08:37 -0500
Subject: [PATCH] wpa_supplicant: Changed systemd template units
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#WantedBy=
When building root filesystems with any of the wpa_supplicant systemd
template service files enabled (current default is to have them disabled) the
systemd-native-fake script would not process the line:
Alias=multi-user.target.wants/wpa_supplicant@%i.service
appropriately due the the use of "%i."
According to the systemd documentation "WantedBy=foo.service in a service
bar.service is mostly equivalent to Alias=foo.service.wants/bar.service in
the same file." However, this is not really the intended purpose of install
Aliases.
All lines of the form:
Alias=multi-user.target.wants/*%i.service
Were replaced with the following lines:
WantedBy=multi-user.target
Signed-off-by: Joshua DeWeese <jdeweese@hennypenny.com>
---
...place-systemd-install-Alias-with-WantedBy.patch | 52 ++++++++++++++++++++++
.../wpa-supplicant/wpa-supplicant_2.6.bb | 1 +
2 files changed, 53 insertions(+)
create mode 100644 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch
new file mode 100644
index 0000000000..a476cf040e
--- /dev/null
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-replace-systemd-install-Alias-with-WantedBy.patch
@@ -0,0 +1,52 @@
+From 94c401733a5a3d294cc412671166e6adfb409f53 Mon Sep 17 00:00:00 2001
+From: Joshua DeWeese <jdeweese@hennypenny.com>
+Date: Wed, 30 Jan 2019 16:19:47 -0500
+Subject: [PATCH] replace systemd install Alias with WantedBy
+
+According to the systemd documentation "WantedBy=foo.service in a
+service bar.service is mostly equivalent to
+Alias=foo.service.wants/bar.service in the same file." However,
+this is not really the intended purpose of install Aliases.
+
+Upstream-Status: Submitted [hostap@lists.infradead.org]
+
+Signed-off-by: Joshua DeWeese <jdeweese@hennypenny.com>
+---
+ wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in | 2 +-
+ wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in | 2 +-
+ wpa_supplicant/systemd/wpa_supplicant.service.arg.in | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in b/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in
+index 03ac507..da69a87 100644
+--- a/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in
++++ b/wpa_supplicant/systemd/wpa_supplicant-nl80211.service.arg.in
+@@ -12,4 +12,4 @@ Type=simple
+ ExecStart=@BINDIR@/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-nl80211-%I.conf -Dnl80211 -i%I
+
+ [Install]
+-Alias=multi-user.target.wants/wpa_supplicant-nl80211@%i.service
++WantedBy=multi-user.target
+diff --git a/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in b/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in
+index c8a744d..ca3054b 100644
+--- a/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in
++++ b/wpa_supplicant/systemd/wpa_supplicant-wired.service.arg.in
+@@ -12,4 +12,4 @@ Type=simple
+ ExecStart=@BINDIR@/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-wired-%I.conf -Dwired -i%I
+
+ [Install]
+-Alias=multi-user.target.wants/wpa_supplicant-wired@%i.service
++WantedBy=multi-user.target
+diff --git a/wpa_supplicant/systemd/wpa_supplicant.service.arg.in b/wpa_supplicant/systemd/wpa_supplicant.service.arg.in
+index 7788b38..55d2b9c 100644
+--- a/wpa_supplicant/systemd/wpa_supplicant.service.arg.in
++++ b/wpa_supplicant/systemd/wpa_supplicant.service.arg.in
+@@ -12,4 +12,4 @@ Type=simple
+ ExecStart=@BINDIR@/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I
+
+ [Install]
+-Alias=multi-user.target.wants/wpa_supplicant@%i.service
++WantedBy=multi-user.target
+--
+2.7.4
+
diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
index aa4c4c2da0..c92ed4ab93 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.6.bb
@@ -33,6 +33,7 @@ SRC_URI = "http://w1.fi/releases/wpa_supplicant-${PV}.tar.gz \
file://key-replay-cve-multiple7.patch \
file://key-replay-cve-multiple8.patch \
file://wpa_supplicant-CVE-2018-14526.patch \
+ file://0001-replace-systemd-install-Alias-with-WantedBy.patch \
"
SRC_URI[md5sum] = "091569eb4440b7d7f2b4276dbfc03c3c"
SRC_URI[sha256sum] = "b4936d34c4e6cdd44954beba74296d964bc2c9668ecaa5255e499636fe2b1450"
--
2.11.0
^ permalink raw reply related [flat|nested] 26+ messages in thread
* (No subject)
@ 2019-09-30 15:50 Stephen K Jolley
0 siblings, 0 replies; 26+ messages in thread
From: Stephen K Jolley @ 2019-09-30 15:50 UTC (permalink / raw)
To: openembedded-core, yocto
[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]
All,
The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means
people can find them. They're being listed on the triage page under the
appropriate heading:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project. If anyone can help,
please take ownership of the bug and send patches! If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.
Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 309
unassigned or newcomer bugs.
We're hoping people may be able to spare some time now and again to help
out with these. Bugs are split into two types, "true bugs" where things
don't work as they should and "enhancements" which are features we'd want
to add to the system. There are also roughly four different "priority"
classes right now, “2.8”, “2.9’, "2.99" and "Future", the more
pressing/urgent issues being in "2.8" and then “2.9”.
Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp.pm@gmail.com)
an e-mail with the bug number you would like and I will assign it to you
(please make sure you have a Bugzilla account). The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs
--
Thanks,
*Stephen K. Jolley*
*Yocto Project Program Manager*
*7867 SW Bayberry Dr., Beaverton, OR 97007*
( *Cell*: (208) 244-4460
* *Email*: *s
<stephen.k.jolley@intel.com>jolley.yp.pm@gmail.com <jolley.yp.pm@gmail.com>*
[-- Attachment #2: Type: text/html, Size: 6589 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2019-09-30 15:50 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-21 10:49 (No subject) Mike Looijmans
2013-01-21 11:26 ` Richard Purdie
-- strict thread matches above, loose matches on Subject: below --
2019-09-30 15:50 Stephen K Jolley
2019-02-05 21:52 [PATCH] wpa_supplicant: Changed systemd template units Richard Purdie
2019-02-07 14:48 ` (No subject) Joshua DeWeese
2018-10-04 13:29 Angelo Dureghello
2018-10-04 13:55 ` Burton, Ross
2018-10-04 15:00 ` Andrea Adami
2018-10-04 15:08 ` Angelo Dureghello
2018-08-02 8:44 Nathan Rossi
2018-05-03 19:55 taborskikrzysztof
2017-11-27 16:20 Volker Vogelhuber
2017-05-07 1:33 [PATCH] openssh: Atomically generate host keys Joshua Watt
2017-05-09 2:24 ` (No subject) Joshua Watt
2016-07-22 10:35 Amarnath Valluri
2014-07-16 3:26 Shan Hai
2013-01-23 15:12 Belal, Awais
2012-12-06 9:49 Lukas Bulwahn
2012-08-05 19:48 Javier Martinez Canillas
2012-08-06 14:59 ` Richard Purdie
2012-07-17 16:16 Ross Burton
2012-07-03 21:08 Mikhail Boiko
2012-06-21 21:36 Andreas Müller
2012-02-21 22:33 Andrei Gherzan
[not found] <4a795deb3789430487146a8425c1c337@DLEE74.ent.ti.com>
2011-08-27 4:38 ` Joel A Fernandes
2011-08-27 7:11 ` Koen Kooi
2011-08-27 3:26 Joel A Fernandes
2011-08-27 7:07 ` Koen Kooi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox