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
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
---
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
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
---
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.
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,
> -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:
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:
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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.
>>
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
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,
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
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]
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,
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:
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
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
33 matches
Mail list logo