[OE-core] (no subject)

[Stephen K Jolley]

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...@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
jolley.yp...@gmail.com *
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[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 
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 
---
 ...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 00..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 
+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 [hos...@lists.infradead.org]
+
+Signed-off-by: Joshua DeWeese 
+---
+ 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

-- 

Re: [OE-core] (no subject)

[Angelo Dureghello]

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  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

Re: [OE-core] (no subject)

[Andrea Adami]

On Thu, Oct 4, 2018 at 3:55 PM 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?
>
> 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  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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] (no subject)

[Burton, Ross]

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  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

[OE-core] (no subject)

[Angelo Dureghello]

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

[OE-core] (no subject)

[Nathan Rossi]

,
 Manjukumar Harthikote Matha 
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 
Acked-by: Martin Hundebøll 
---
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 00..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 

[OE-core] (no subject)

[taborskikrzysztof]

Wysłano z telefonu Samsung-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] Subject: Yocto Project Status WW10’18

[Burton, Ross]

On 5 March 2018 at 16:30, akuster808  wrote:

>
>- Performance metrics indicate that a recent merge has caused a
>slowdown in build times.
>
> Is this data publicly available?
>

https://lists.yoctoproject.org/pipermail/yocto-perf/2018-March/thread.html

The HTML mails are much more readable...

The raw data is in the wiki somewhere but I can't recall where right now.


>
>- Flood of last-minute upgrades continuing to be reviewed and merged
>if low-impact.
>
>
> Is there a cut off on package upgrades?
>

Strictly speaking,  weeks ago.  If an upgrade appears safe it might well
sneak in now.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [yocto] Subject: Yocto Project Status WW10’18

[akuster808]

On 03/05/2018 08:03 AM, Jordan, Robin L wrote:
>
> Subject: Yocto Project Status WW10’18
>
>  
>
> Current Dev Position: YP 2.5 M3 final close out.
>
> Next Deadline: YP 2.5 M3 cut off was 2/19/18
>
> *** FEATURE FREEZE for 2.5 has passed ***
>
>  
>
> SWAT team rotation: Rebecca -> Cal on March 9, 2018
>
> SWAT team rotation: Cal -> Armin on March 16, 2018
>
> https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
>
>  
>
> Key Status/Updates:
>
>   * YP 2.5 M2 was released February 27.
>   o This milestone release includes CVE fixes and 60 recipe
> upgrades*. * It incorporates security fixes**with upgrades to
> gcc and kernels to all current stable versions.  Headline
> changes include reproducibility improvements, gettext build
> performance, image generation, and cmake using Ninja by
> default.  This release added gobject-introspection tests to
> testimage, integrated support for the Meson build system,
> Python build/packaging refactoring, and redesigned postinstall
> script handling.
>   * YP 2.2.3 was released February 27.
>   o A total of**97 CVE fixes** and other fixes to work with GCC 7
> on newer host OSs.
>   o We have committed to a 2.2.4 release to integrate all
> remaining security fixes.
>   * YP 2.4.2 RC2 came out of QA today (report at
> 
> https://wiki.yoctoproject.org/wiki/WW10_-_2018-03-05-_Full_Test_Cycle_-_2.4.2_rc2)
>
>   * YP 2.5 M3 is in final feature freeze. Reviewing last week’s
> required features:
>   o 2.27 glibc upgrade has been merged. This meant making SDK
> changes so they’re all ~50M larger now thanks to the need to
> ship locales. However the same underlying code could be reused
> to generate locale archives in images, which will make those
> smaller.
>   o kernel-devsrc size reduction: the blocking issue has been
> resolved so waiting for an updated patch.
>   o pseudo upgrade has been merged which should solve many issues,
> and Peter is investigating the long-standing host
> contamination issue.
>   o Still need to resolve the multilib SDK patch series.
>   o Package feed filtering has been merged.
>   o Image EFI configuration rework under review now.
>   * Performance metrics indicate that a recent merge has caused a
> slowdown in build times.
>
Is this data publicly available?

>   *  It is suspected that the glibc upgrade is the cause of this
> although help would be appreciated to verify this.
>   * Flood of last-minute upgrades continuing to be reviewed and merged
> if low-impact.
>

Is there a cut off on package upgrades?

>  *
>   * Go upgrade/improvements are under review, possibly we’ll ship both
> Go 1.9.4 and 1.10 in 2.5 but do plan to drop 1.9.4 from master as
> soon as 1.10 doesn’t present compatibility problems.
>   * We’re continuing to work on the autobuilder changes and for
> various reasons (inc. changes in people).  We would be in much
> better shape to switch to the new codebase before release, rather
> than waiting until early 2.6 to pick this work up again by which
> time we’d have lost people and context. If we are to switch, we
> need to build M3 with the new infrastructure. We plan to make this
> switch for M3.
>
>  
>
> Planned upcoming dot releases:
>
> YP 2.3.4 (Pyro) will be built when we figure out gcc backports.
>

yocto-linux 4.10 still needs updating.

> YP 2.2.4 (Morty) will be built when we figure out gcc backports.
>
kernel 4.8 has a pull request
kernel 4.1 pull request sent that includes  spectre changes and some
general fixes.

- armin

> YP 2.4.3 (Roko) is planned for post YP 2.5.
>
>  
>
> Key YP 2.5 Dates are:
>
> YP 2.5 M3 is in feature freeze.  See status above.
>
> YP 2.5 M3 was scheduled for release 3/2/18
>
> YP 2.5 M4 cut off of 4/2/18
>
> YP 2.5 M4 release of 4/27/18
>
>  
>
> Tracking Metrics:
>
>     WDD 2663 (last week 2646)
>
> (https://wiki.yoctoproject.org/charts/combo.html)
>
>  
>
> Key Status Links for YP:
>
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule
>
> https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features
>
>  
>
> The Status reports are now stored on the wiki at:
> https://wiki.yoctoproject.org/wiki/Weekly_Status
>
>  
>
> [If anyone has suggestions for other information you’d like to see on
> this weekly status update, let us know!]
>
>  
>
>
>

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Volker Vogelhuber]

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.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Joshua Watt]

No need to create a directory name "644"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Amarnath Valluri]

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.

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Shan Hai]

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
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Belal, Awais]

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


openssl.inc
Description: openssl.inc
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Mike Looijmans]

This mail bounced so the v2 patch overtook it...

 From: Mike Looijmans mike.looijm...@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: 

Re: [OE-core] (no subject)

[Richard Purdie]

On Mon, 2013-01-21 at 10:49 +, Mike Looijmans wrote:
 This mail bounced so the v2 patch overtook it...
 
  From: Mike Looijmans mike.looijm...@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


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Lukas Bulwahn]

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.bulw...@oss.bmw-carit.de # This line is ignored.
From: Lukas Bulwahn lukas.bulw...@oss.bmw-carit.de
Subject: 
In-Reply-To: 


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] (no subject)

[Richard Purdie]

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


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Javier Martinez Canillas]

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

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Ross Burton]

Two patches to follow up Andrei Gherzan's connman series.  The first applies
to master, the second only applies on his branch.


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Mikhail Boiko]

From 86ad9569e30de537451fe0a4731ef57d92810d28 Mon Sep 17 00:00:00 2001
From: Mikhail Boiko mikhailboik...@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 mikhailboik...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] (no subject)

[Andreas Müller]

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
  

[OE-core] (no subject)

[Andrei Gherzan]

Add Upstream-Status in patch file.


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] (no subject)

[Joel A Fernandes]

On Fri, Aug 26, 2011 at 10:26 PM, Fernandes, Joel A joelag...@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


___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core