Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
Hi Nathan, On 08/07/2018 04:59 AM, Nathan Rossi wrote: On 7 August 2018 at 07:16, Jaewon Lee wrote: Hi Nathan, What do you think about adding support for dts include files as well (.dtsi)? Hi Jaewon, Device tree include files already work with the implementation in this patch. The default include path is the same as the path of the dts files, so if you use "/include/ ".dtsi";" (dtc) or "#include " (preprocessor) it will search within the DT_FILES_PATH (which is WORKDIR by default) and then the KERNEL_INCLUDE paths. Though if the dtsi is in another path you can add it to DT_INCLUDE, and it will be searched. If i'm understanding correctly, this flow just supports compiling a dts file that has a plugin tag (it can include dtsi files) in short I can't compile the dtsi file itself to a dtbo Does this cover the support you are after or is there another configuration you would like it to support? Yes for us, if dt overlays are enabled, we don't include a dtsi in the base dts and compile that dtsi separately as a dtbo which is loaded later. so would be great to loop through all dtsi files as well and compile if it has a plugin tag. Your thoughts? Thanks, Jaewon Thanks, Nathan Thanks, Jaewon -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan Rossi Sent: Thursday, August 2, 2018 1:55 AM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class 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
Re: [OE-core] [yocto] Yocto Project changes in progress
hi there, There have been various changes in the project recently which have caused concern for some users and contributors. I wanted to update everyone with the most recent developments. It is worth highlighting the recent news that: * The Yocto Project recently welcomed two new platinum members, Facebook and Arm to the advisory board. See [1] for a full list of the YP members. * Richard Purdie is now being funded by the Yocto Project to continue in his role as the overall project architect. * Nicolas Dechesne (Linaro) has taken over the community manager role from Jefro * Lieu Ta (WindRiver) has taken over the advisory board chairperson role from Jefro * Andreea Volosincu (WindRiver) has taken on the advocacy lead role from Tracey Erway * Discussions about the future governance of the project with a view to modernisation and clarification are now ongoing but are based upon the strong foundations above. As usual, the Yocto Project will attend the ELC-E conference in October, in Edimburgh, and we hope to see you there, so that you can meet all of us! Feel free to reach out to me, if you have any specific questions! [1] https://www.yoctoproject.org/ecosystem/members/ cheers nico On Wed, May 9, 2018 at 5:33 AM Zoran Stojsavljevic wrote: > > Once I (at least I can speak for myself) embarked on this YOCTO ship, > voluntarily, I do not consider leaving it. I like the concept, > although there are problems with it. > > I could not commit too much time to it (since I have another > commitments), but I keep one eye on it, primarily trying to learn, > and, as abilities allow, to help. > > Big IT players' politics is driven primarily by interest. And interest > is changing over Time, due to Global Policies and Economy shifting... > Well! > > Zoran > ___ > > On Tue, May 8, 2018 at 11:20 PM, Jeff Osier-Mixon wrote: > > Many projects function this way. It is one of the strengths of the open > > source process. > > > > I'd be happy to answer any questions. > > > > > > On Mon, May 7, 2018 at 9:53 PM, Zoran Stojsavljevic > > wrote: > >> > >> Very interesting, indeed! Newer knew that Richard (Purdie) is/was > >> INTEL employee!? > >> > >> This announcement gives several (conspiracy?) theories... Some > >> official, some unofficial. ;-) > >> > >> As independent thinker... IMHO. > >> > >> Time Will Tell! > >> > >> Zoran Stojsavljevic > >> ___ > >> > >> On Mon, May 7, 2018 at 11:53 PM, Jeff Osier-Mixon wrote: > >> > Hello everyone. I'd like to briefly address rumors around Richard > >> > Purdie's > >> > transition from Intel to a more neutral position, and Intel's reduction > >> > in > >> > resources for the project. > >> > > >> > We set up the Yocto Project in 2010 through Linux Foundation, with over > >> > 20 > >> > member organizations, so it would function as a true open source project > >> > - > >> > neutral, unbiased, and well distributed. Those things are what make open > >> > source projects less vulnerable to any one person or company. This is > >> > actually a very exciting transitional time for the project, and all > >> > existing > >> > member organizations are fully behind the project. We will let people > >> > know > >> > details as they are available. > >> > > >> > Meanwhile, the 2.5 "Sumo" release is on the way and should be released > >> > soon, > >> > the 2.6 planning process has started in earnest (please participate!), > >> > and > >> > we are excited to see what the future has in store for the project. > >> > > >> > -- > >> > Jeffrey “Jefro” Osier-Mixon, Intel Corporation > >> > Open Source Community Ecosystem Strategist > >> > > >> > > >> > -- > >> > ___ > >> > yocto mailing list > >> > yo...@yoctoproject.org > >> > https://lists.yoctoproject.org/listinfo/yocto > >> > > > > > > > > > > > -- > > Jeffrey “Jefro” Osier-Mixon, Intel Corporation > > Open Source Community Ecosystem Strategist > > > -- > ___ > yocto mailing list > yo...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] remove allarch from recipes which rdepends on TUNE_PKGARCH packages
On 8/7/18 9:56 AM, Richard Purdie wrote: > On Tue, 2018-08-07 at 11:44 +0100, richard.pur...@linuxfoundation.org > wrote: >> On Tue, 2018-08-07 at 17:37 +0800, Kang Kai wrote: >>> On 2018年08月06日 22:51, Mark Hatle wrote: > >> resolvconf -> bash >> weston-init -> weston kbd > > weston RRECOMMENDS weston-init? >>> >>> weston-init install init file which calls weston or weston-launch >>> from >>> package weston and openvt from package kbd. >> >> Agreed. >> >> My worry is that this move effectively makes allarch usesless since >> any >> script using an interpreter will now need to be not allarch since >> most >> interpreters are not allarch. >> >> I'm not sure this is a good move... > > Thinking about this further, we could just disable allarch if multilib > is enabled? That would seem to address most of the issues, not entirely > satisfactorily but enough to make things work... ? Yes, this would resolve some of the concerns. We already know that these allarch SHOULD be identical for all multilibs, so install space should not be an issue, it's only build time concerns. --Mark > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [rocko][PATCH] cryptodev: Fix build errors with v4.13+
On 08/06/2018 08:21 PM, Anuj Mittal wrote:
> From: Daniel Schultz
>
> Without this compiles of 4.13 and later kernels fail.
>
> Backport from https://github.com/cryptodev-linux/cryptodev-linux
> Based on commit f0d69774afb27ffc62bf353465fba145e70cb85a
>
> (From OE-Core rev: 317fd9814653ee22496dda63a02e628e8a16899b)
I just pulled it in.
Thanks
>
> Signed-off-by: Daniel Schultz
> Signed-off-by: Richard Purdie
> Signed-off-by: Anuj Mittal
> ---
> .../cryptodev/cryptodev-module_1.9.bb | 1 +
> ...01-ioctl.c-Fix-build-with-linux-4.13.patch | 49 +++
> 2 files changed, 50 insertions(+)
> create mode 100644
> meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
>
> diff --git a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> index 552eb6abaa..ed6d0ecae9 100644
> --- a/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> +++ b/meta/recipes-kernel/cryptodev/cryptodev-module_1.9.bb
> @@ -9,6 +9,7 @@ DEPENDS += "cryptodev-linux"
>
> SRC_URI += " \
> file://0001-Disable-installing-header-file-provided-by-another-p.patch \
> +file://0001-ioctl.c-Fix-build-with-linux-4.13.patch \
> "
>
> EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_DIR}" PREFIX="${D}"'
> diff --git
> a/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
>
> b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
> new file mode 100644
> index 00..a41efacdd9
> --- /dev/null
> +++
> b/meta/recipes-kernel/cryptodev/files/0001-ioctl.c-Fix-build-with-linux-4.13.patch
> @@ -0,0 +1,49 @@
> +From f0d69774afb27ffc62bf353465fba145e70cb85a Mon Sep 17 00:00:00 2001
> +From: Ricardo Ribalda Delgado
> +Date: Mon, 4 Sep 2017 11:05:08 +0200
> +Subject: [PATCH] ioctl.c: Fix build with linux 4.13
> +
> +git/ioctl.c:1127:3: error: positional initialization of field in 'struct'
> declared with 'designated_init' attribute [-Werror=designated-init]
> + {0, },
> +^
> +note: (near initialization for 'verbosity_ctl_dir[1]')
> +git/ioctl.c:1136:3: error: positional initialization of field in 'struct'
> declared with 'designated_init' attribute [-Werror=designated-init]
> + {0, },
> +^
> +
> +Linux kernel has added -Werror=designated-init around 4.11 (c834f0e8a8b)
> +triggering build errors with gcc 5 and 6 (but not with gcc 4)
> +
> +Upstream-Status: Backport
> +
> +Signed-off-by: Ricardo Ribalda Delgado
> +Signed-off-by: Cristian Stoica
> +---
> + ioctl.c | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/ioctl.c b/ioctl.c
> +index 0385203..8d4a162 100644
> +--- a/ioctl.c
> b/ioctl.c
> +@@ -1124,7 +1124,7 @@ static struct ctl_table verbosity_ctl_dir[] = {
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> +-{0, },
> ++{},
> + };
> +
> + static struct ctl_table verbosity_ctl_root[] = {
> +@@ -1133,7 +1133,7 @@ static struct ctl_table verbosity_ctl_root[] = {
> + .mode = 0555,
> + .child = verbosity_ctl_dir,
> + },
> +-{0, },
> ++{},
> + };
> + static struct ctl_table_header *verbosity_sysctl_header;
> + static int __init init_cryptodev(void)
> +--
> +2.7.4
> +
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] remove allarch from recipes which rdepends on TUNE_PKGARCH packages
On Tue, 2018-08-07 at 11:44 +0100, richard.pur...@linuxfoundation.org wrote: > On Tue, 2018-08-07 at 17:37 +0800, Kang Kai wrote: > > On 2018年08月06日 22:51, Mark Hatle wrote: > > > > > > > > > resolvconf -> bash > > > > > weston-init -> weston kbd > > > > > > > > weston RRECOMMENDS weston-init? > > > > weston-init install init file which calls weston or weston-launch > > from > > package weston and openvt from package kbd. > > Agreed. > > My worry is that this move effectively makes allarch usesless since > any > script using an interpreter will now need to be not allarch since > most > interpreters are not allarch. > > I'm not sure this is a good move... Thinking about this further, we could just disable allarch if multilib is enabled? That would seem to address most of the issues, not entirely satisfactorily but enough to make things work... ? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW32’18
Current Dev Position: YP 2.6 M3. Next Deadline: YP 2.6 M2 Release Target was July 27, 2018 SWAT Team Rotation: · SWAT lead is currently: Armin · SWAT team rotation: Armin -> Maxin on Aug. 10, 2018 · SWAT team rotation: Maxin -> Chen on Aug. 17, 2018 · https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: · YP 2.6 M2 is in QA. See https://wiki.yoctoproject.org/wiki/2.6_QA_Status. It is 99% complete and should complete this week. · YP 2.5.1 is in QA. See https://wiki.yoctoproject.org/wiki/2.5_QA_Status. It just started and is 0% complete. · There was a nasty regression in do_package where hardlinks were not being preserved. This has been fixed and shows up clearly in the performance monitoring charts. A new automated test was added to detect this problem earlier in future. · We’re going to enable oe-selftest parallelism by default on the new autobuilder infrastructure as the critical race issues we had are fixed. · The multiconfig dependencies code merged. · The layerindex library code merged. · The sstate equivalency server work from Joshua/Garmin has review still pending. · The kernel-devsrc rework from Bruce/Windriver is pending patch resubmission. · With 2.5.1 built, stable release work is now focusing on the 2.4 (rocko) series. · There were cmake fixes and improvements to the SDK including the addition of new automated tests to ensure this doesn’t regress. Planned Releases for YP 2.6: · YP 2.6 M2 Build is in QA. · YP 2.6 M2 Release Target was July 27, 2018 · YP 2.6 M3 Build Target is Aug. 27, 2018 · YP 2.6 M3 Release Target is Sept. 7, 2018 · YP 2.6 M4 Build Target is Oct. 1, 2018 · YP 2.6 M4 Release Target is Oct. 26, 2018 Planned upcoming dot releases: · YP 2.5.1 (Sumo) is in QA. · YP 2.4.4 (Rocko) will be targeted after YP 2.6 M4 is done. · YP 2.5.2 (Sumo) will be targeted after YP 2.4.4 is done. Tracking Metrics: · WDD 2590 (last week 2620) (https://wiki.yoctoproject.org/charts/combo.html) · Poky Patch Metrics oTotal patches found: 1608 (last week 1619) oPercentage of patches in the Pending State: 730 (45%) [last week 740 (46%)] Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status https://wiki.yoctoproject.org/wiki/Yocto_2.6_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.6_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!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 •Cell:(208) 244-4460 • Email: stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] sstate: Add sstate usage summary to the build
Currently the user has no indication of how much sstate was already present
or that would be used by the build. This change adds some summary information
so that the user can see how much reuse is occurring. To fully work it
needs some extra information from a recent bitbake commit but this is
optional.
When combined with bitbake --dry-run this feature can be used to check
if sstate would be reused in a build.
[YOCTO #12749]
Signed-off-by: Richard Purdie
---
meta/classes/sstate.bbclass | 12
1 file changed, 12 insertions(+)
diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 350d3107f59..6743becf071 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -892,6 +892,18 @@ def sstate_checkhashes(sq_fn, sq_task, sq_hash, sq_hashfn,
d, siginfo=False):
evdata['found'].append( (sq_fn[task], sq_task[task],
sq_hash[task], sstatefile ) )
bb.event.fire(bb.event.MetadataEvent("MissedSstate", evdata), d)
+# Print some summary statistics about the current task completion and how
much sstate
+# reuse there was. Avoid divide by zero errors.
+total = len(sq_fn)
+currentcount = d.getVar("BB_SETSCENE_STAMPCURRENT_COUNT") or 0
+complete = 0
+if currentcount:
+complete = (len(ret) + currentcount) / (total + currentcount) * 100
+match = 0
+if total:
+match = len(ret) / total * 100
+bb.plain("Sstate summary: Wanted %d Found %d Missed %d Current %d (%d%%
match, %d%% complete)" % (total, len(ret), len(missed), currentcount, match,
complete))
+
if hasattr(bb.parse.siggen, "checkhashes"):
bb.parse.siggen.checkhashes(missed, ret, sq_fn, sq_task, sq_hash,
sq_hashfn, d)
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libusb: Add ptest
On Mon, Aug 6, 2018 at 7:53 PM Burton, Ross wrote:
>
> The upgrade to libusb 1.0.22 happened in *May* so please do try and
> keep up to date with master. In this case git did managed to merge
> anyway, but generally that won't be true.
Thank you for your reply, I fixed my mistake so now my patch is up to
date with master, and I sent the final patch v3.
Thanks,
Maksym
>
> Ross
>
> On 6 August 2018 at 15:16, Maksym Kokhan via Openembedded-core
> wrote:
> > The run-ptest script was added to run existing libusb1 tests and libusb1
> > recipe was changed to add ptest support to that package.
> >
> > Signed-off-by: Maksym Kokhan
> > Reviewed-by: Andrii Bordunov
> > ---
> > meta/recipes-support/libusb/libusb1/run-ptest | 15 +++
> > meta/recipes-support/libusb/libusb1_1.0.21.bb | 11 ++-
> > 2 files changed, 25 insertions(+), 1 deletion(-)
> > create mode 100755 meta/recipes-support/libusb/libusb1/run-ptest
> >
> > diff --git a/meta/recipes-support/libusb/libusb1/run-ptest
> > b/meta/recipes-support/libusb/libusb1/run-ptest
> > new file mode 100755
> > index 000..646a966
> > --- /dev/null
> > +++ b/meta/recipes-support/libusb/libusb1/run-ptest
> > @@ -0,0 +1,15 @@
> > +#!/bin/sh
> > +
> > +echo
> > +echo " libusb1 tests
> > ---"
> > +echo
> > +
> > +./stress | tr '\n' ' ' | \
> > +sed 's/Starting test run: \([a-zA-Z_]*\)\.\.\. \([a-zA-Z_]*\) (.) /\2
> > \1\n/g' | \
> > +sed '$d' | \
> > +sed '{
> > + s/^Success/PASS:/g
> > + s/^Failure/FAIL:/g
> > + s/^Error/FAIL:/g
> > + s/^Skip/SKIP:/g
> > +}'
> > diff --git a/meta/recipes-support/libusb/libusb1_1.0.21.bb
> > b/meta/recipes-support/libusb/libusb1_1.0.21.bb
> > index 1fefd14..56822a6 100644
> > --- a/meta/recipes-support/libusb/libusb1_1.0.21.bb
> > +++ b/meta/recipes-support/libusb/libusb1_1.0.21.bb
> > @@ -10,6 +10,7 @@ BBCLASSEXTEND = "native nativesdk"
> >
> > SRC_URI = "${SOURCEFORGE_MIRROR}/libusb/libusb-${PV}.tar.bz2 \
> > file://no-dll.patch \
> > + file://run-ptest \
> >"
> >
> > SRC_URI[md5sum] = "1da9ea3c27b3858fa85c5f4466003e44"
> > @@ -17,7 +18,7 @@ SRC_URI[sha256sum] =
> > "7dce9cce9a81194b7065ee912bcd55eeffebab694ea403ffb91b67db66
> >
> > S = "${WORKDIR}/libusb-${PV}"
> >
> > -inherit autotools pkgconfig
> > +inherit autotools pkgconfig ptest
> >
> > # Don't configure udev by default since it will cause a circular
> > # dependecy with udev package, which depends on libusb
> > @@ -30,6 +31,14 @@ do_install_append() {
> > fi
> > }
> >
> > +do_compile_ptest() {
> > +oe_runmake -C tests stress
> > +}
> > +
> > +do_install_ptest() {
> > +install -m 755 ${B}/tests/.libs/stress ${D}${PTEST_PATH}
> > +}
> > +
> > FILES_${PN} += "${base_libdir}/*.so.*"
> >
> > FILES_${PN}-dev += "${base_libdir}/*.so ${base_libdir}/*.la"
> > --
> > 2.7.4
> >
> > --
> > ___
> > 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] [PATCH v3] libusb: Add ptest
Add ptest support to libusb package.
Uses existing libusb tests.
Signed-off-by: Maksym Kokhan
Reviewed-by: Andrii Bordunov
---
meta/recipes-support/libusb/libusb1/run-ptest | 15 +++
meta/recipes-support/libusb/libusb1_1.0.22.bb | 11 ++-
2 files changed, 25 insertions(+), 1 deletion(-)
create mode 100755 meta/recipes-support/libusb/libusb1/run-ptest
diff --git a/meta/recipes-support/libusb/libusb1/run-ptest
b/meta/recipes-support/libusb/libusb1/run-ptest
new file mode 100755
index 000..17ab436
--- /dev/null
+++ b/meta/recipes-support/libusb/libusb1/run-ptest
@@ -0,0 +1,15 @@
+#!/bin/sh
+
+echo
+echo " libusb1 tests ---"
+echo
+
+./stress | tr '\n' ' ' | \
+sed 's/Starting test run: \([a-zA-Z_]*\)\.\.\. \([a-zA-Z_]*\) (.) /\2 \1\n/g'
| \
+sed '$d' | \
+sed '{
+ s/^Success/PASS:/g
+ s/^Failure/FAIL:/g
+ s/^Error/FAIL:/g
+ s/^Skip/SKIP:/g
+}'
diff --git a/meta/recipes-support/libusb/libusb1_1.0.22.bb
b/meta/recipes-support/libusb/libusb1_1.0.22.bb
index 766c1c3..3ba1eff 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.22.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.22.bb
@@ -10,6 +10,7 @@ BBCLASSEXTEND = "native nativesdk"
SRC_URI = "${SOURCEFORGE_MIRROR}/libusb/libusb-${PV}.tar.bz2 \
file://no-dll.patch \
+ file://run-ptest \
"
SRC_URI[md5sum] = "466267889daead47674df933cea9cacb"
@@ -17,7 +18,7 @@ SRC_URI[sha256sum] =
"75aeb9d59a4fdb800d329a545c2e6799f732362193b465ea198f2aa275
S = "${WORKDIR}/libusb-${PV}"
-inherit autotools pkgconfig
+inherit autotools pkgconfig ptest
# Don't configure udev by default since it will cause a circular
# dependecy with udev package, which depends on libusb
@@ -30,6 +31,14 @@ do_install_append() {
fi
}
+do_compile_ptest() {
+ oe_runmake -C tests stress
+}
+
+do_install_ptest() {
+ install -m 755 ${B}/tests/.libs/stress ${D}${PTEST_PATH}
+}
+
FILES_${PN} += "${base_libdir}/*.so.*"
FILES_${PN}-dev += "${base_libdir}/*.so ${base_libdir}/*.la"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [sumo][PATCH] alsa-lib: Cleanup packaging
On Tue, 2018-08-07 at 08:40 -0500, Joshua Watt wrote:
> From: Joshua Watt
>
> Cleans up the packaging by moving libasound.so.2 back into the alsa-
> lib
> package which was previously empty.
>
> Previously, it was difficult to create an image that had
> libasound.so.2,
> then create an SDK from that image that had the proper development
> files, because the only way to get libasound.so.2 was to do:
>
> IMAGE_INSTALL += "libasound"
>
> This however caused a problem because all of the development files
> that
> would be desired in the SDK were located in alsa-lib-dev, which
> wouldn't
> be included because alsa-lib wasn't included, and it was impossible
> to
> include alsa-lib because it was an empty package that was culled.
>
> Signed-off-by: Joshua Watt
> Signed-off-by: Richard Purdie
> (cherry picked from commit 30352f3d84344bff8c06625f9674947417f6e8e1)
>
> Change-Id: I2fb065b7e00569ba3a6aac631ac863999455bfb2
Oops. Sorry for the Change-ID... my git commit hooks get the better of
me sometimes :) You can remove this when you apply, or I can push up a
V2 if you prefer.
> ---
> meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb | 13 ++---
> 1 file changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> b/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> index c5bf107e5ee..0f1e2db8d7a 100644
> --- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> +++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
> @@ -19,18 +19,17 @@ EXTRA_OECONF += "${@get_alsa_fpu_setting(bb, d)}
> "
>
> EXTRA_OECONF += "--disable-python"
>
> -PACKAGES =+ "alsa-server libasound alsa-conf alsa-doc"
> -FILES_libasound = "${libdir}/libasound.so.*"
> +PACKAGES =+ "alsa-server alsa-conf alsa-doc"
> FILES_alsa-server = "${bindir}/*"
> FILES_alsa-conf = "${datadir}/alsa/"
>
> -RDEPENDS_libasound = "alsa-conf"
> -
> -# alsa-lib gets automatically added to alsa-lib-dev dependencies,
> but the
> -# alsa-lib package doesn't exist. libasound is the real library
> package.
> -RDEPENDS_${PN}-dev = "libasound"
> +RDEPENDS_${PN}_class-target = "alsa-conf"
>
> # upgrade path
> +RPROVIDES_${PN} = "libasound"
> +RREPLACES_${PN} = "libasound"
> +RCONFLICTS_${PN} = "libasound"
> +
> RPROVIDES_${PN}-dev = "alsa-dev"
> RREPLACES_${PN}-dev = "alsa-dev"
> RCONFLICTS_${PN}-dev = "alsa-dev"
--
Joshua Watt
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [sumo][PATCH] alsa-lib: Cleanup packaging
From: Joshua Watt
Cleans up the packaging by moving libasound.so.2 back into the alsa-lib
package which was previously empty.
Previously, it was difficult to create an image that had libasound.so.2,
then create an SDK from that image that had the proper development
files, because the only way to get libasound.so.2 was to do:
IMAGE_INSTALL += "libasound"
This however caused a problem because all of the development files that
would be desired in the SDK were located in alsa-lib-dev, which wouldn't
be included because alsa-lib wasn't included, and it was impossible to
include alsa-lib because it was an empty package that was culled.
Signed-off-by: Joshua Watt
Signed-off-by: Richard Purdie
(cherry picked from commit 30352f3d84344bff8c06625f9674947417f6e8e1)
Change-Id: I2fb065b7e00569ba3a6aac631ac863999455bfb2
---
meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
b/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
index c5bf107e5ee..0f1e2db8d7a 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.1.5.bb
@@ -19,18 +19,17 @@ EXTRA_OECONF += "${@get_alsa_fpu_setting(bb, d)} "
EXTRA_OECONF += "--disable-python"
-PACKAGES =+ "alsa-server libasound alsa-conf alsa-doc"
-FILES_libasound = "${libdir}/libasound.so.*"
+PACKAGES =+ "alsa-server alsa-conf alsa-doc"
FILES_alsa-server = "${bindir}/*"
FILES_alsa-conf = "${datadir}/alsa/"
-RDEPENDS_libasound = "alsa-conf"
-
-# alsa-lib gets automatically added to alsa-lib-dev dependencies, but the
-# alsa-lib package doesn't exist. libasound is the real library package.
-RDEPENDS_${PN}-dev = "libasound"
+RDEPENDS_${PN}_class-target = "alsa-conf"
# upgrade path
+RPROVIDES_${PN} = "libasound"
+RREPLACES_${PN} = "libasound"
+RCONFLICTS_${PN} = "libasound"
+
RPROVIDES_${PN}-dev = "alsa-dev"
RREPLACES_${PN}-dev = "alsa-dev"
RCONFLICTS_${PN}-dev = "alsa-dev"
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for Add aarch64 SDK machine
== Series Details == Series: Add aarch64 SDK machine Revision: 1 URL : https://patchwork.openembedded.org/series/13415/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * PatchAdd aarch64 SDK machine Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] [PATCH] librepo:1.8.1 -> 1.9.0
On Tue, 2018-08-07 at 17:31 +0800, Hong Liu wrote:
> Upgrade librepo from 1.8.1 to 1.9.0
>
> Signed-off-by: Hong Liu
> ---
> meta/recipes-devtools/librepo/{librepo_1.8.1.bb => librepo_1.9.0.bb}
> | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> rename meta/recipes-devtools/librepo/{librepo_1.8.1.bb =>
> librepo_1.9.0.bb} (93%)
This change causes the build to fail in do_patch with patch rejects...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] Add aarch64 SDK machine
Signed-off-by: Anders Roxell --- meta/conf/machine-sdk/aarch64.conf | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 meta/conf/machine-sdk/aarch64.conf diff --git a/meta/conf/machine-sdk/aarch64.conf b/meta/conf/machine-sdk/aarch64.conf new file mode 100644 index 00..98d8380ecb --- /dev/null +++ b/meta/conf/machine-sdk/aarch64.conf @@ -0,0 +1,2 @@ +SDK_ARCH = "aarch64" +ABIEXTENSION_class-nativesdk = "" -- 2.18.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
On 7 August 2018 at 07:16, Jaewon Lee wrote:
> Hi Nathan,
>
> What do you think about adding support for dts include files as well (.dtsi)?
Hi Jaewon,
Device tree include files already work with the implementation in this
patch. The default include path is the same as the path of the dts
files, so if you use "/include/ ".dtsi";" (dtc) or "#include
" (preprocessor) it will search within the DT_FILES_PATH
(which is WORKDIR by default) and then the KERNEL_INCLUDE paths.
Though if the dtsi is in another path you can add it to DT_INCLUDE,
and it will be searched.
Does this cover the support you are after or is there another
configuration you would like it to support?
Thanks,
Nathan
>
> Thanks,
> Jaewon
>
>
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan
> Rossi
> Sent: Thursday, August 2, 2018 1:55 AM
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source
> compilation class
>
> 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"
> +
>
[OE-core] ✗ patchtest: failure for selftest/package: Fix hardlink test when using sstate
== Series Details == Series: selftest/package: Fix hardlink test when using sstate Revision: 1 URL : https://patchwork.openembedded.org/series/13414/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at be20eb4f4a) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] selftest/package: Fix hardlink test when using sstate
The build target won't cause the package task to run if things were already
built and in sstate. Ensure we run the package task explicitly to ensure
the test works as intended.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/package.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/cases/package.py
b/meta/lib/oeqa/selftest/cases/package.py
index 1e171b5ebef..f288fcafdb4 100644
--- a/meta/lib/oeqa/selftest/cases/package.py
+++ b/meta/lib/oeqa/selftest/cases/package.py
@@ -89,7 +89,7 @@ class VersionOrdering(OESelftestTestCase):
class PackageTests(OESelftestTestCase):
# Verify that a recipe which sets up hardlink files has those preserved
into split packages
def test_preserve_hardlinks(self):
-result = bitbake("selftest-hardlink")
+result = bitbake("selftest-hardlink -c package")
dest = get_bb_var('PKGDEST', 'selftest-hardlink')
bindir = get_bb_var('bindir', 'selftest-hardlink')
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Extract GPL sources
Thanks Ross it works fine now. On Tue, 2018-08-07 at 11:38 +0100, Burton, Ross wrote: > I believe this is fixed in Pyro 2.3.4. > > Ross > > > On 7 August 2018 at 11:15, Fabien Lahoudere > wrote: > > Thanks Ross, > > > > I have an issue when using the archiver: > > > > local.conf: > > > > INHERIT += "archiver" > > ARCHIVER_MODE[src] = "patched" > > COPYLEFT_LICENSE_INCLUDE = 'GPL* LGPL*' > > > > ERROR: gmp-native-6.1.2-r0 do_unpack_and_patch: Command Error: 'quilt > > --quiltrc > > /home/aragua/src/poky/build2/tmp/work/x86_64-linux/gmp-native/6.1.2-r0/archiver-work//recipe- > > sysroot-native/etc/quiltrc push' exited with 0 Output: > > /bin/sh: quilt: command not found > > ERROR: gmp-native-6.1.2-r0 do_unpack_and_patch: Function failed: > > patch_do_patch > > ERROR: Logfile of failure stored in: > > /home/aragua/src/poky/build2/tmp/work/x86_64-linux/gmp- > > native/6.1.2-r0/temp/log.do_unpack_and_patch.8027 > > ERROR: Task (virtual:native:/home/aragua/src/poky/meta/recipes- > > support/gmp/gmp_6.1.2.bb:do_unpack_and_patch) failed with exit code '1' > > > > I tried to drop native from COPYLEFT_RECIPE_TYPES without effect. > > > > Where can I add quilt-native dependency? > > > > For information I use pyro release. Is there any known bug for that release? > > > > Thanks > > > > On Tue, 2018-08-07 at 10:10 +0100, Burton, Ross wrote: > > > Have a look at the archiver class. > > > > > > Ross > > > > > > On 7 August 2018 at 09:29, Fabien Lahoudere > > > wrote: > > > > Hello > > > > > > > > I need to extract all *GPL* sources patched related to an image in > > > > order to publish them. > > > > I want to do it automatically, ie 'bitbake myimage -c > > > > extract-gpl-sources' > > > > Is there a mechanism to do that? > > > > If not do you have any idea how I can implement it? > > > > > > > > Thanks > > > > > > > > -- > > > > Fabien > > > > -- > > > > ___ > > > > yocto mailing list > > > > yo...@yoctoproject.org > > > > https://lists.yoctoproject.org/listinfo/yocto > > > > -- > > Fabien -- Fabien -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V3] musl: Fix dirent struct alignment issue seen on armv5te
On Thu, 2018-08-02 at 11:43 -0700, Khem Raj wrote: > - its a general problem however observed on armv5te based boards in > OE > other arches either have ways to compensate for misaligned access > in hardware > or compiler does not use 8byte alignment > > - fix internal linux headers > > Full logs > https://git.musl-libc.org/cgit/musl/log/?qt=range=9cad27a3dc1a4eb34 > 9b6591e4dc8cc89dce32277..f2c6dbe2442027ed8fe0fa869918e41f495534d8 > > Signed-off-by: Khem Raj > --- > V3: Elaborate commit message > meta/recipes-core/musl/musl_git.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This seems to cause runtime testing failures for qemux86 and qemux86- 64: 4.137] (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory) | [ 4.137] (II) LoadModule: "glx" | [ 4.138] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so | [ 4.147] (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: Error relocating /usr/lib/libGL.so.1: _ITM_deregisterTMCloneTable: initial-exec TLS resolves to dynamic definition in /usr/lib/libGL.so.1 | [ 4.147] (II) UnloadModule: "glx" | [ 4.147] (II) Unloading glx | [ 4.147] (EE) Failed to load module "glx" (loader failed, 7) https://autobuilder.yocto.io/builders/nightly-musl/builds/1208/steps/Running%20Sanity%20Tests/logs/stdio Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] remove allarch from recipes which rdepends on TUNE_PKGARCH packages
On Tue, 2018-08-07 at 17:37 +0800, Kang Kai wrote:
> On 2018年08月06日 22:51, Mark Hatle wrote:
> > On 8/3/18 4:28 PM, richard.pur...@linuxfoundation.org wrote:
> > > On Fri, 2018-08-03 at 09:49 +0800, kai.k...@windriver.com wrote:
> > > > From: Kai Kang
> > > >
> > > > The following allarch packages rdepends on TUNE_PKGARCH
> > > > packages. So
> > > > remove allarch from these recipes.
> > > >
> > > > ca-certificates -> openssl
> > >
> > > Should we reverse this, i.e. have openssl RRECOMMENDS ca-
> > > certificates?
> >
> > I believe this is what other distros do. I think the dependency on
> > ca-certficiates was there because there is a script included that
> > uses OpenSSL
> > to generate the certificates. (Theoretically you can use this
> > script post
> > install to update the certs.)
> >
> > /usr/sbin/update-ca-certificates
> >
> > I suspect the others had similar dependencies.. some included
> > script needed
> > something from another package to run.
> >
> > Not sure if this changes the suggestion though...
> >
> > --Mark
> >
> > > > docbook-xsl-stylesheets -> perl
> > > > font-alias -> font-util
> > > > initramfs-module-setup-live -> udev-extraconf
> > > > initramfs-framework -> ${VIRTUAL-RUNTIME_base-utils} (busybox
> > > > by
> > > > default)
> > > > ppp-dialin -> ppp
> > >
> > > ppp RRECOMMENDS ppp-dialin?
>
> ppp-dialin installs script ppp-dialin which calls /usr/sbin/pppd.
>
>
> > >
> > > > resolvconf -> bash
> > > > weston-init -> weston kbd
> > >
> > > weston RRECOMMENDS weston-init?
>
> weston-init install init file which calls weston or weston-launch
> from
> package weston and openvt from package kbd.
Agreed.
My worry is that this move effectively makes allarch usesless since any
script using an interpreter will now need to be not allarch since most
interpreters are not allarch.
I'm not sure this is a good move...
Cheers,
Richard
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Extract GPL sources
I believe this is fixed in Pyro 2.3.4. Ross On 7 August 2018 at 11:15, Fabien Lahoudere wrote: > Thanks Ross, > > I have an issue when using the archiver: > > local.conf: > > INHERIT += "archiver" > ARCHIVER_MODE[src] = "patched" > COPYLEFT_LICENSE_INCLUDE = 'GPL* LGPL*' > > ERROR: gmp-native-6.1.2-r0 do_unpack_and_patch: Command Error: 'quilt > --quiltrc > /home/aragua/src/poky/build2/tmp/work/x86_64-linux/gmp-native/6.1.2-r0/archiver-work//recipe- > sysroot-native/etc/quiltrc push' exited with 0 Output: > /bin/sh: quilt: command not found > ERROR: gmp-native-6.1.2-r0 do_unpack_and_patch: Function failed: > patch_do_patch > ERROR: Logfile of failure stored in: > /home/aragua/src/poky/build2/tmp/work/x86_64-linux/gmp- > native/6.1.2-r0/temp/log.do_unpack_and_patch.8027 > ERROR: Task (virtual:native:/home/aragua/src/poky/meta/recipes- > support/gmp/gmp_6.1.2.bb:do_unpack_and_patch) failed with exit code '1' > > I tried to drop native from COPYLEFT_RECIPE_TYPES without effect. > > Where can I add quilt-native dependency? > > For information I use pyro release. Is there any known bug for that release? > > Thanks > > On Tue, 2018-08-07 at 10:10 +0100, Burton, Ross wrote: >> Have a look at the archiver class. >> >> Ross >> >> On 7 August 2018 at 09:29, Fabien Lahoudere >> wrote: >> > Hello >> > >> > I need to extract all *GPL* sources patched related to an image in order >> > to publish them. >> > I want to do it automatically, ie 'bitbake myimage -c extract-gpl-sources' >> > Is there a mechanism to do that? >> > If not do you have any idea how I can implement it? >> > >> > Thanks >> > >> > -- >> > Fabien >> > -- >> > ___ >> > yocto mailing list >> > yo...@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto > -- > Fabien -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Extract GPL sources
Thanks Ross, I have an issue when using the archiver: local.conf: INHERIT += "archiver" ARCHIVER_MODE[src] = "patched" COPYLEFT_LICENSE_INCLUDE = 'GPL* LGPL*' ERROR: gmp-native-6.1.2-r0 do_unpack_and_patch: Command Error: 'quilt --quiltrc /home/aragua/src/poky/build2/tmp/work/x86_64-linux/gmp-native/6.1.2-r0/archiver-work//recipe- sysroot-native/etc/quiltrc push' exited with 0 Output: /bin/sh: quilt: command not found ERROR: gmp-native-6.1.2-r0 do_unpack_and_patch: Function failed: patch_do_patch ERROR: Logfile of failure stored in: /home/aragua/src/poky/build2/tmp/work/x86_64-linux/gmp- native/6.1.2-r0/temp/log.do_unpack_and_patch.8027 ERROR: Task (virtual:native:/home/aragua/src/poky/meta/recipes- support/gmp/gmp_6.1.2.bb:do_unpack_and_patch) failed with exit code '1' I tried to drop native from COPYLEFT_RECIPE_TYPES without effect. Where can I add quilt-native dependency? For information I use pyro release. Is there any known bug for that release? Thanks On Tue, 2018-08-07 at 10:10 +0100, Burton, Ross wrote: > Have a look at the archiver class. > > Ross > > On 7 August 2018 at 09:29, Fabien Lahoudere > wrote: > > Hello > > > > I need to extract all *GPL* sources patched related to an image in order to > > publish them. > > I want to do it automatically, ie 'bitbake myimage -c extract-gpl-sources' > > Is there a mechanism to do that? > > If not do you have any idea how I can implement it? > > > > Thanks > > > > -- > > Fabien > > -- > > ___ > > yocto mailing list > > yo...@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto -- Fabien -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] remove allarch from recipes which rdepends on TUNE_PKGARCH packages
On 2018年08月06日 22:51, Mark Hatle wrote:
On 8/3/18 4:28 PM, richard.pur...@linuxfoundation.org wrote:
On Fri, 2018-08-03 at 09:49 +0800, kai.k...@windriver.com wrote:
From: Kai Kang
The following allarch packages rdepends on TUNE_PKGARCH packages. So
remove allarch from these recipes.
ca-certificates -> openssl
Should we reverse this, i.e. have openssl RRECOMMENDS ca-certificates?
I believe this is what other distros do. I think the dependency on
ca-certficiates was there because there is a script included that uses OpenSSL
to generate the certificates. (Theoretically you can use this script post
install to update the certs.)
/usr/sbin/update-ca-certificates
I suspect the others had similar dependencies.. some included script needed
something from another package to run.
Not sure if this changes the suggestion though...
--Mark
docbook-xsl-stylesheets -> perl
font-alias -> font-util
initramfs-module-setup-live -> udev-extraconf
initramfs-framework -> ${VIRTUAL-RUNTIME_base-utils} (busybox by
default)
ppp-dialin -> ppp
ppp RRECOMMENDS ppp-dialin?
ppp-dialin installs script ppp-dialin which calls /usr/sbin/pppd.
resolvconf -> bash
weston-init -> weston kbd
weston RRECOMMENDS weston-init?
weston-init install init file which calls weston or weston-launch from
package weston and openvt from package kbd.
Regards,
Kai
Not really sure about some of these but we should at least consider
it...
Cheers,
Richard
--
Regards,
Neil | Kai Kang
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] createrepo-c:0.10.0 -> 0.11.0
Upgrade createrepo-c from 0.10.0 to 0.11.0
Signed-off-by: Hong Liu
---
meta/recipes-devtools/createrepo-c/createrepo-c_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
b/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
index 9be9f9e..2960811 100644
--- a/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
+++ b/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
@@ -9,8 +9,8 @@ SRC_URI =
"git://github.com/rpm-software-management/createrepo_c \
file://0001-Correctly-install-the-shared-library.patch \
"
-PV = "0.10.0+git${SRCPV}"
-SRCREV = "748891ff8ee524c2d37926c608cd2794f88013f3"
+PV = "0.11.1+git${SRCPV}"
+SRCREV = "434a40babdde57ab405e9a1085a30e9575ea0c92"
S = "${WORKDIR}/git"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] icu:61.1 -> 62.1
1.Upgrade icu from 61.1 to 62.1.
2.0001-i18n-Drop-include-xlocale.h.patch has been merged.
Signed-off-by: Hong Liu
---
.../icu/icu/0001-i18n-Drop-include-xlocale.h.patch | 34 --
.../icu/{icu_61.1.bb => icu_62.1.bb} | 5 ++--
2 files changed, 2 insertions(+), 37 deletions(-)
delete mode 100644
meta/recipes-support/icu/icu/0001-i18n-Drop-include-xlocale.h.patch
rename meta/recipes-support/icu/{icu_61.1.bb => icu_62.1.bb} (80%)
diff --git
a/meta/recipes-support/icu/icu/0001-i18n-Drop-include-xlocale.h.patch
b/meta/recipes-support/icu/icu/0001-i18n-Drop-include-xlocale.h.patch
deleted file mode 100644
index f0c49e1..000
--- a/meta/recipes-support/icu/icu/0001-i18n-Drop-include-xlocale.h.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From d6b57c1b4eb9a24d9d95342a961c93946539c93b Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Sat, 24 Jun 2017 22:52:40 -0700
-Subject: [PATCH 3/4] i18n: Drop include
-
-glibc 2.26 drops this header
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj
-
- source/i18n/digitlst.cpp | 6 +-
- 1 file changed, 1 insertion(+), 5 deletions(-)
-
-diff --git a/source/i18n/digitlst.cpp b/source/i18n/digitlst.cpp
-index 8e86fa7..0bdbb2c 100644
a/i18n/digitlst.cpp
-+++ b/i18n/digitlst.cpp
-@@ -62,11 +62,7 @@
- #endif
-
- #if U_USE_STRTOD_L
--# if U_HAVE_XLOCALE_H
--# include
--# else
--# include
--# endif
-+# include
- #endif
-
- // ***
---
-2.14.2
-
diff --git a/meta/recipes-support/icu/icu_61.1.bb
b/meta/recipes-support/icu/icu_62.1.bb
similarity index 80%
rename from meta/recipes-support/icu/icu_61.1.bb
rename to meta/recipes-support/icu/icu_62.1.bb
index ffaf350..ec9db7d 100644
--- a/meta/recipes-support/icu/icu_61.1.bb
+++ b/meta/recipes-support/icu/icu_62.1.bb
@@ -16,14 +16,13 @@ BASE_SRC_URI =
"http://download.icu-project.org/files/icu4c/${PV}/icu4c-${ICU_PV
SRC_URI = "${BASE_SRC_URI} \
file://icu-pkgdata-large-cmd.patch \
file://fix-install-manx.patch \
- file://0001-i18n-Drop-include-xlocale.h.patch \
"
SRC_URI_append_class-target = "\
file://0001-Disable-LDFLAGSICUDT-for-Linux.patch \
"
-SRC_URI[md5sum] = "68fe38999fef94d622bd6843d43c0615"
-SRC_URI[sha256sum] =
"d007f89ae8a2543a53525c74359b65b36412fa84b3349f1400be6dcf409fafef"
+SRC_URI[md5sum] = "490ad9d920158e0314e10ba74ae9a150"
+SRC_URI[sha256sum] =
"3dd9868d666350dda66a6e305eecde9d479fb70b30d5b55d78a1deffb97d5aa3"
UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)/"
UPSTREAM_CHECK_URI = "http://download.icu-project.org/files/icu4c/;
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] vala:0.40.4 -> 0.40.8
Upgrade vala from 0.40.4 to 0.40.8
Signed-off-by: Hong Liu
---
meta/recipes-devtools/vala/{vala_0.40.4.bb => vala_0.40.8.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/vala/{vala_0.40.4.bb => vala_0.40.8.bb} (64%)
diff --git a/meta/recipes-devtools/vala/vala_0.40.4.bb
b/meta/recipes-devtools/vala/vala_0.40.8.bb
similarity index 64%
rename from meta/recipes-devtools/vala/vala_0.40.4.bb
rename to meta/recipes-devtools/vala/vala_0.40.8.bb
index 7597813..dba9f0d 100644
--- a/meta/recipes-devtools/vala/vala_0.40.4.bb
+++ b/meta/recipes-devtools/vala/vala_0.40.8.bb
@@ -6,5 +6,5 @@ SRC_URI += "
file://0001-git-version-gen-don-t-append-dirty-if-we-re-not-in-g.pa
file://0001-Disable-valadoc.patch \
"
-SRC_URI[md5sum] = "a690209e202be7aa6234aaa4e48fe3fb"
-SRC_URI[sha256sum] =
"379354a2a2f7ee5c4d6e0f5e88b0e32620dcd5f51972baf6d90d9f18eb689198"
+SRC_URI[md5sum] = "3e3177692fb5d81a7b8aaa6b95a30bdd"
+SRC_URI[sha256sum] =
"5c35e087a7054e9f0a514a0c1f1d0a0d7cf68d3e43c1dbeb840f9b0d815c0fa5"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] librepo:1.8.1 -> 1.9.0
Upgrade librepo from 1.8.1 to 1.9.0
Signed-off-by: Hong Liu
---
meta/recipes-devtools/librepo/{librepo_1.8.1.bb => librepo_1.9.0.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-devtools/librepo/{librepo_1.8.1.bb => librepo_1.9.0.bb}
(93%)
diff --git a/meta/recipes-devtools/librepo/librepo_1.8.1.bb
b/meta/recipes-devtools/librepo/librepo_1.9.0.bb
similarity index 93%
rename from meta/recipes-devtools/librepo/librepo_1.8.1.bb
rename to meta/recipes-devtools/librepo/librepo_1.9.0.bb
index 4569885..cebf3c7 100644
--- a/meta/recipes-devtools/librepo/librepo_1.8.1.bb
+++ b/meta/recipes-devtools/librepo/librepo_1.9.0.bb
@@ -7,7 +7,7 @@ SRC_URI = "git://github.com/rpm-software-management/librepo.git
\
file://0004-Set-gpgme-variables-with-pkg-config-not-with-cmake-m.patch \
"
-SRCREV = "7b9b7bf388f3f059529c6f50c40b30919fef30f9"
+SRCREV = "6e939a1f41685755356e1dc881db2890f94e2614"
S = "${WORKDIR}/git"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] [PATCH] npth:1.5 -> 1.6
Upgrade npth from 1.5 to 1.6
Signed-off-by: Hong Liu
---
meta/recipes-support/npth/{npth_1.5.bb => npth_1.6.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-support/npth/{npth_1.5.bb => npth_1.6.bb} (81%)
diff --git a/meta/recipes-support/npth/npth_1.5.bb
b/meta/recipes-support/npth/npth_1.6.bb
similarity index 81%
rename from meta/recipes-support/npth/npth_1.5.bb
rename to meta/recipes-support/npth/npth_1.6.bb
index 8f42a1a..8310efb 100644
--- a/meta/recipes-support/npth/npth_1.5.bb
+++ b/meta/recipes-support/npth/npth_1.6.bb
@@ -10,8 +10,8 @@ SRC_URI = "${GNUPG_MIRROR}/npth/npth-${PV}.tar.bz2 \
file://pkgconfig.patch \
"
-SRC_URI[md5sum] = "9ba2dc4302d2f32c66737c43ed191b1b"
-SRC_URI[sha256sum] =
"294a690c1f537b92ed829d867bee537e46be93fbd60b16c04630fbbfcd9db3c2"
+SRC_URI[md5sum] = "375d1a15ad969f32d25f1a7630929854"
+SRC_URI[sha256sum] =
"1393abd9adcf0762d34798dc34fdcf4d0d22a8410721e76f1e3afcd1daa4e2d1"
BINCONFIG = "${bindir}/npth-config"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [yocto] Extract GPL sources
Have a look at the archiver class. Ross On 7 August 2018 at 09:29, Fabien Lahoudere wrote: > Hello > > I need to extract all *GPL* sources patched related to an image in order to > publish them. > I want to do it automatically, ie 'bitbake myimage -c extract-gpl-sources' > Is there a mechanism to do that? > If not do you have any idea how I can implement it? > > Thanks > > -- > Fabien > -- > ___ > yocto mailing list > yo...@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Extract GPL sources
Hello I need to extract all *GPL* sources patched related to an image in order to publish them. I want to do it automatically, ie 'bitbake myimage -c extract-gpl-sources' Is there a mechanism to do that? If not do you have any idea how I can implement it? Thanks -- Fabien -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] binutils: Upgrade to 2.31 release branch
Hi Khem,
The new binutils may cause build failures with kernel 4.18 (linux-yocto-dev),
arch/x86/Makefile:184: *** Compiler lacks asm-goto support.. Stop.
The line for checking asm goto is in kernel's top Makefile:
# check for 'asm goto'
ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)
$(KBUILD_CFLAGS)), y)
CC_HAVE_ASM_GOTO := 1
KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
KBUILD_AFLAGS += -DCC_HAVE_ASM_GOTO
endif
And in gcc-goto.sh:
cat << "END" | $@ -x c - -c -o /dev/null >/dev/null 2>&1 && echo "y"
int main(void)
{
#if defined(__arm__) || defined(__aarch64__)
/*
* Not related to asm goto, but used by jump label
* and broken on some ARM GCC versions (see GCC Bug 48637).
*/
static struct { int dummy; int state; } tp;
asm (".long %c0" :: "i" ());
#endif
entry:
asm goto ("" entry);
return 0;
}
END
This script reports:
Assembler messages:
Fatal error: The input and output files must be distinct
And it is introduced by binutils' commit:
commit 67f846b59b32f3d704c601669409c2584383fea9
Author: John Darrington
Date: Thu Apr 12 15:07:02 2018 +0100
Stop the assembler from overwriting its output file.
[snip]
+ if (sib.st_ino == sob.st_ino)
+ {
+ /* Don't let as_fatal remove the output file! */
+ out_file_name = NULL;
+ as_fatal (_("The input and output files must be distinct"));
[snip]
I can't reproduce this problem locally, but it can be reproduced in our daily
build. Yocto doesn't have this problem atm since it use linux-yocto (not -dev).
Do you have any suggestions, please ?
// Robert
On 07/18/2018 04:10 AM, Khem Raj wrote:
Signed-off-by: Khem Raj
---
meta/conf/distro/include/tcmode-default.inc |2 +-
.../{binutils-2.30.inc => binutils-2.31.inc} |2 +-
30.bb => binutils-cross-canadian_2.31.bb} |0
...s-cross_2.30.bb => binutils-cross_2.31.bb} |0
...ssdk_2.30.bb => binutils-crosssdk_2.31.bb} |0
...s-crosssdk-Generate-relocatable-SDKs.patch | 12 +-
...o-not-generate-linker-script-directo.patch | 22 +-
...iden-the-regexp-for-SH-architectures.patch | 12 +-
...004-Point-scripts-location-to-libdir.patch | 10 +-
...-RPATH-entry-if-LD_RUN_PATH-is-not-e.patch | 10 +-
.../binutils/0006-Use-libtool-2.4.patch | 2296 +
...-the-armv5e-architecture-to-binutils.patch |8 +-
...stro-compiler-point-to-the-wrong-ins.patch |4 +-
...-system-directories-when-cross-linki.patch | 50 +-
...h-in-libtool-when-sysroot-is-enabled.patch |4 +-
...e-default-emulation-for-mips64-linux.patch | 12 +-
.../0012-Add-support-for-Netlogic-XLP.patch | 80 +-
...ect-assembling-for-ppc-wait-mnemonic.patch | 10 +-
.../0014-Detect-64-bit-MIPS-targets.patch |4 +-
.../0015-sync-with-OE-libtool-changes.patch |4 +-
.../{binutils_2.30.bb => binutils_2.31.bb}|0
21 files changed, 1327 insertions(+), 1215 deletions(-)
rename meta/recipes-devtools/binutils/{binutils-2.30.inc =>
binutils-2.31.inc} (97%)
rename meta/recipes-devtools/binutils/{binutils-cross-canadian_2.30.bb =>
binutils-cross-canadian_2.31.bb} (100%)
rename meta/recipes-devtools/binutils/{binutils-cross_2.30.bb =>
binutils-cross_2.31.bb} (100%)
rename meta/recipes-devtools/binutils/{binutils-crosssdk_2.30.bb =>
binutils-crosssdk_2.31.bb} (100%)
rename meta/recipes-devtools/binutils/{binutils_2.30.bb => binutils_2.31.bb}
(100%)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
