[OE-core] [rocko][PATCH] ltp: remove ltp-staticdev package

2017-12-14 Thread Dengke Du
The nm01 testcase runtime depends on a static library, and ltp-staticdev package is entirely pointless, so remove it and add the static libraries to ltp main package and skip the "staticdev" checks. (From OE-Core rev: 002f7b9f038b86b793b8e0558bcd17ad58372767) Signed-off-by: Dengke Du

[OE-core] [PATCH 3/3] maintainers.inc: remove stat recipe

2017-12-14 Thread Yi Zhao
Signed-off-by: Yi Zhao --- meta/conf/distro/include/maintainers.inc | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index 856a6b7..5152729 100644 ---

[OE-core] [PATCH 0/3] remove stat recipe

2017-12-14 Thread Yi Zhao
Yi Zhao (3): hdparm: replace stat with coreutils as runtime dependency stat: remove the recipe maintainers.inc: remove stat recipe meta/conf/distro/include/maintainers.inc | 1 - .../hdparm/hdparm/wiper.sh-fix-stat-path.patch | 38

[OE-core] [PATCH 2/3] stat: remove the recipe

2017-12-14 Thread Yi Zhao
The stat hasn't any update since 2002. All modern Linux distributions use stat from coreutils as default. After replace it with coreutils as runtime dependency in hdparm, it is safe to drop this recipe and move it to meta-oe. Signed-off-by: Yi Zhao ---

[OE-core] [PATCH 1/3] hdparm: replace stat with coreutils as runtime dependency

2017-12-14 Thread Yi Zhao
Currently only hdparm specifies stat as runtime dependency in oe-core. But the stat hasn't any update since 2002. Replace it with coreutils as runtime dependency since coreutils also provides stat program. Then we can drop the stat recipe totally. Also add a patch to fix stat path in wiper.sh.

Re: [OE-core] [PATCH v3] u-boot-fw-utils: Fix broken makefile in v2017.11.

2017-12-14 Thread Otavio Salvador
Yes, it should be backport and the header is to be included in the patch file, not on the commit log On Thu, Dec 14, 2017 at 10:22 PM, Denys Dmytriyenko wrote: > Isn't it "Upstream-Status: Backport [URL]"? > > Also, what were the changes in v2 and v3 of this patch? > > > On Wed,

Re: [OE-core] [PATCH 0/2] Fix build issues with fitimage

2017-12-14 Thread Manjukumar Harthikote Matha
> -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of > Denys Dmytriyenko > Sent: Thursday, December 14, 2017 4:18 PM > To: André Draszik > Cc:

Re: [OE-core] [PATCH v3] u-boot-fw-utils: Fix broken makefile in v2017.11.

2017-12-14 Thread Denys Dmytriyenko
Isn't it "Upstream-Status: Backport [URL]"? Also, what were the changes in v2 and v3 of this patch? On Wed, Dec 13, 2017 at 03:52:29PM +0100, Kristian Amlie wrote: > See the patch for details. This patch has already been applied > upstream, but we need it for v2017.11. > > Upstream-Status:

Re: [OE-core] [PATCH 0/2] Fix build issues with fitimage

2017-12-14 Thread Denys Dmytriyenko
On Thu, Dec 14, 2017 at 11:18:15AM +, André Draszik wrote: > On Wed, 2017-12-13 at 18:23 -0800, Manjukumar Matha wrote: > > While building fitimage with initramfs bundle using INITRAMFS_IMAGE and > > INITRAMFS_IMAGE_BUNDLE = "1", we have few failures > > Nothing against these patches, but

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 07:49 PM, Alexander Kanavin wrote: On 12/14/2017 07:40 PM, Stefan Agner wrote: Oh, I see, well that simplifies it, doesn't it? E.g. # If package managers support postinsts and the package manager is present on the # rootfs, then it will handle postinsts just fine, no

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 07:40 PM, Stefan Agner wrote: Oh, I see, well that simplifies it, doesn't it? E.g. # If package managers support postinsts and the package manager is present on the # rootfs, then it will handle postinsts just fine, no need to deploy scripts again. if

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 18:28, Alexander Kanavin wrote: > On 12/14/2017 07:16 PM, Stefan Agner wrote: > >> Are you sure that rpm has no such facility? Maybe there is some other >> mechanism around... > > You are welcome to find it. rpm does not distinguish between unpacking > and configuring steps, and

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 07:16 PM, Stefan Agner wrote: Are you sure that rpm has no such facility? Maybe there is some other mechanism around... You are welcome to find it. rpm does not distinguish between unpacking and configuring steps, and just does everything in a single installation step. If

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 17:59, Alexander Kanavin wrote: > On 12/14/2017 06:46 PM, Stefan Agner wrote: > >> Suggestion: >> - Still remove systemd opkg service as proposed, since run-postinsts >> gets run with systemd and should/will handle package manager just fine > > Yes. > >> - Change run-postinsts to

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 06:46 PM, Stefan Agner wrote: Suggestion: - Still remove systemd opkg service as proposed, since run-postinsts gets run with systemd and should/will handle package manager just fine Yes. - Change run-postinsts to behave sane: Detect package management by checking

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 16:14, Alexander Kanavin wrote: > On 12/14/2017 04:57 PM, Stefan Agner wrote: >> On 2017-12-14 15:55, Alexander Kanavin wrote: >>> On 12/14/2017 04:41 PM, Stefan Agner wrote: >>> I think removing the Opkg first boot systemd service (as the initial patch does) is the correct

[OE-core] [PATCH] selftest-ed: add a RECIPE_NO_UPDATE_REASON

2017-12-14 Thread Alexander Kanavin
This will avoid AUH looking at it, among other things. Signed-off-by: Alexander Kanavin --- meta-selftest/recipes-test/selftest-ed/selftest-ed_1.14.1.bb | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 04:57 PM, Stefan Agner wrote: On 2017-12-14 15:55, Alexander Kanavin wrote: On 12/14/2017 04:41 PM, Stefan Agner wrote: I think removing the Opkg first boot systemd service (as the initial patch does) is the correct first step. However, it currently still leads to a second copy

[OE-core] [PATCH v2] core/loader.py: fix regex to include all available test cases

2017-12-14 Thread leonardo . sandoval . gonzalez
From: Leonardo Sandoval Some test cases (eSDK.oeSDK*, runtime_test/*) does not match with current regex, fix it accept all. [YOCTO #12385] Signed-off-by: Leonardo Sandoval --- meta/lib/oeqa/core/loader.py

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 15:55, Alexander Kanavin wrote: > On 12/14/2017 04:41 PM, Stefan Agner wrote: > >> I think removing the Opkg first boot systemd service (as the initial >> patch does) is the correct first step. >> >> However, it currently still leads to a second copy of the postinst >> scripts in

Re: [OE-core] Fix for the APIC hangs in qemux86-64

2017-12-14 Thread Bruce Ashfield
On 12/13/2017 07:04 PM, Richard Purdie wrote: On Wed, 2017-12-13 at 19:01 -0500, Bruce Ashfield wrote: On 2017-12-13 9:14 AM, Richard Purdie wrote: On Wed, 2017-12-13 at 09:07 -0500, Bruce Ashfield wrote: On 12/13/2017 09:05 AM, Richard Purdie wrote: On Wed, 2017-12-13 at 08:38 -0500,

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 04:41 PM, Stefan Agner wrote: I think removing the Opkg first boot systemd service (as the initial patch does) is the correct first step. However, it currently still leads to a second copy of the postinst scripts in /etc if package management is enabled. I am pretty sure that

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 15:24, Alexander Kanavin wrote: > On 12/14/2017 03:59 PM, Stefan Agner wrote: > >> That at least contradicts my testing with opkg/ipk. >> >> If /etc/ipk-postinsts is not there and /var/lib/opkg/status is there >> (package management installed), then run-postinst runs "opkg

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 03:59 PM, Stefan Agner wrote: That at least contradicts my testing with opkg/ipk. If /etc/ipk-postinsts is not there and /var/lib/opkg/status is there (package management installed), then run-postinst runs "opkg configure", which takes care of postinsts just fine. Reading the

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 14:52, Alexander Kanavin wrote: > On 12/14/2017 03:11 PM, Stefan Agner wrote: >> >>> I don't think this is correct. Some postinsts are intentionally >>> deferred to first boot, and they need to be run regardless of whether >>> the image supports runtime package management or not. >>

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/14/2017 03:11 PM, Stefan Agner wrote: I don't think this is correct. Some postinsts are intentionally deferred to first boot, and they need to be run regardless of whether the image supports runtime package management or not. Yes I know, the mentioned opkg-keyrings is such a case. If

Re: [OE-core] How to fix file-rdes QA error for /usr/bin/python or /bin/bash?

2017-12-14 Thread Steffen Sledz
On 14.12.2017 14:34, Steffen Sledz wrote: > With rocko some builds are rejected because of the following package QA error > (formerly it was just a warning). > > ERROR: foo-1_gitrAUTOINC+2595b80a79-r17 do_package_qa: QA Issue: > //foo.py contained in package foo requires /usr/bin/python,

Re: [OE-core] How to fix file-rdes QA error for /usr/bin/python?

2017-12-14 Thread Vincent Prince
Steffen, I maybe wrong but foo.py should start with #!/usr/bin/env python instead of #!/usr/bin/python Best regards, Vincent 2017-12-14 14:34 GMT+01:00 Steffen Sledz : > With rocko some builds are rejected because of the following package QA > error (formerly it was

[OE-core] How to fix file-rdes QA error for /usr/bin/python?

2017-12-14 Thread Steffen Sledz
With rocko some builds are rejected because of the following package QA error (formerly it was just a warning). ERROR: foo-1_gitrAUTOINC+2595b80a79-r17 do_package_qa: QA Issue: //foo.py contained in package foo requires /usr/bin/python, but no providers found in RDEPENDS_for? [file-rdeps]

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Stefan Agner
On 2017-12-14 14:10, Alexander Kanavin wrote: > On 12/13/2017 08:29 PM, Stefan Agner wrote: > >> Maybe it needs something like this? >> >> >> runtime_pkgmanage = bb.utils.contains("IMAGE_FEATURES", >> "package-management", >>True, False,

Re: [OE-core] [RFC] opkg: avoid running postinst scripts twice when using systemd

2017-12-14 Thread Alexander Kanavin
On 12/13/2017 08:29 PM, Stefan Agner wrote: Maybe it needs something like this? runtime_pkgmanage = bb.utils.contains("IMAGE_FEATURES", "package-management", True, False, self.d) if delayed_postinsts and not runtime_pkgmanage:

[OE-core] [PATCH] openssl-nativesdk: Fix "can't open config file" warning

2017-12-14 Thread Ovidiu Panait
When SDK is not installed in the default location, openssl will not be able to find the the openssl.cnf config file: "WARNING: can't open config file: /usr/lib/ssl/openssl.cnf" To fix this, we need to provide the environment variable $OPENSSL_CONF pointing to the correct config file

Re: [OE-core] [PATCH 0/2] Fix build issues with fitimage

2017-12-14 Thread André Draszik
On Wed, 2017-12-13 at 18:23 -0800, Manjukumar Matha wrote: > While building fitimage with initramfs bundle using INITRAMFS_IMAGE and > INITRAMFS_IMAGE_BUNDLE = "1", we have few failures Nothing against these patches, but what is the use-case to do that? Why don't you just disable